[Asterisk-Dev] [LONG] Call holding and native bridging with ast_h323
kiel at kikal.org
Fri Jul 16 03:38:43 MST 2004
I first needed to implement native bridging within the ast_h323 driver.
This means to me splitting rtp streams to prevent them from passing
throught the PBX.
It was necessary to use H245 instead of H450 because of obvious
implementation reasons. The way I proceeded implies some changes inside
rtp.c (ast_rtp_bridge function) that's why I'm asking before submitting
I implemented inside the driver some H245 methods such as:
A call is put on hold state by closing logical channels using H245
protocol, but the connection remains up.
A Call is Waking up when we renegociate (from the pbx endpoint) the
opening of logicalChannels. The negociation is proceeded this way:
PBX remote EP
(1) TermCapSet Exchange
Opening T-channel => -----------------> Opening R-Channel
(3') OLCack |
Starting Transmitter <= <---------------- <---
(4) OpenLogicalChannel Opening T-Channel
Opening R-Channel <----------------
---> Interruption (not sending Ack Yet)
Informing PBX about remote's media channel parameters
Here we do the same with the other call we want to wake up
We apply rtp infos retreived from both calls to each other inside
PBX remote EP
--------------------> Starting T-Chan
with customized media channel
parameters pointing on the other peer
to be bridged with
As you can see this implies inserting 3 hooks inside ast_rtp_brigde().
Previously, the "virtual" process forced both peers to be prepared to
bridge in one trip.
1/ set_rtp_peer(first peer)
2/ set_rtp_peer(second peer)
=> then the loop follows
No communication was possible and we had to foresee rtp parameters,
which is impossible with H323 endpoints (the determination is made
while opening R-Channel)
I may be wrong but I think that the only way we can
retreive the new listening rtp port of the peer we want to redirect is
to deduce it from the corresponding OLC (or better the OLCAck that
follows the R-Channel opening but it's not possible if both pdu's have
been encoded into the same PPER stream).
That's why I had to interrupt the exchange procedure on receiving the OLC
pdu. The consequence, toward ast_rtp_bridge, looks like this:
struc sockaddr_in _a0, _a1; //used to store new rtp datas
1/ prepare_rtp_peer(c0, &_a0)
2/ prepare_rtp_peer(c1, &_a1)
and then the retreiving procedure (implemented inside chan_h323 with
3/ restart_rtp_peer(c0, &_a1)
4/ restart_rtp_peer(c1, &_a0)
Dividing the work this way I think we can avoid corrupting other drivers
by simply returning 0 (or an equivalent obviously) for prepare_rtp_peer()
in their native implementation.
Another developpement could be to split rtp streams beetween foreign
rtp/rtcp stack based protocols (h323/mgcp, h323/sip).
I only worked with ohphone and tiptel innovaphone 200 as endpoints,
on asterisk-0.9.0 tar.gz version, without testing the consequences
of multiple calls and load increase.
Any comment is welcome, if you think that it's an interessting feature
to be committed I will go on to produce a more integrable patch (many
things have to be "pulished" for the moment).
More information about the asterisk-dev