| Summary: | ASTERISK-02175: [post-1.0] [patch] h323-to-h323 and h323-to-mgcp native bridging | ||
| Reporter: | kiel (kiel) | Labels: | |
| Date Opened: | 2004-08-02 10:04:48 | Date Closed: | 2011-06-07 14:05:08 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) native_bridge.diff | |
| Description: | Done on CVS-HEAD-08/02/04-16:08:20 This patch provide basic h323-to-h323 and h323-to-mgcp native bridging functionalities. I needed to change ast_rtp_bridge() a little bit, so that some "virtual" functions have to be defined in channels driver. (I didn't touch chan_sip and others) Many things have to be discussed,tested and of course improved. So don't hesitate to make any remarks. My internship ends the 20th and I won't be able to maintain or correct the patch after that. NB: this patch reimplements bug ASTERISK-2085 feature, so if you plan to commit only ASTERISK-2085 first, I'll manage to produce an integrable patch according to the CVS snapshot. If you plan to commit both features I'll remove bug ASTERISK-2085 ****** ADDITIONAL INFORMATION ****** Test context: (-> means "calls") - ohphone, gnomemeeting -> ohphone, gnomemeeting - ohphone, gnomemeeting -> tiptel innovaphone 200 (h323) - ohphone, gnomemeeting -> swissvoice ip10s (mgcp) no gatekeeper | ||
| Comments: | By: Mark Spencer (markster) 2004-08-02 11:44:43 So I have to ask, obviously, why the need for the new functions? By: kiel (kiel) 2004-08-02 14:27:21 Due to h245. As I explained in asterisk-dev ML, to perform bridging I use h245 messages. First close logical channels and then make the peer respawn a transmitter channel. But we don't know before receiving peer's OpenLogicalChannel what will be his receiving transport (ip and port) As a consequence, an h323 bridging process has to be performed in two steps 1/ call shutting, and waking (prepare_rtp_peer()) - we retreive both peer's media transport so that we know where to make each other stream to. 2/ Actual bridging (named set_rtp_peer_restart()) - As we know receiving transports of both peer we can tell them where to start streaming MGCP doesn't change the receiving port when modifying a connection (so does SIP a think), that's why prepare_rtp_peer() should merely return true within SIP and MGCP implementations By: twisted (twisted) 2004-08-20 13:26:55 Closed per kiel | ||