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:48Date Closed:2011-06-07 14:05:08
Versions:Frequency of
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


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
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