[Asterisk-Dev] [LONG] Call holding and native bridging with ast_h323

[Kiel Hedjam]

Hi all,

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
a patch.

I implemented inside the driver some H245 methods such as:
 - H245CallHolding
 - H245CallWakeUp
 - H245CallRetreiving

H245CallHolding
---------------

A call is put on hold state by closing logical channels using H245
protocol, but the connection remains up.

H245CallWakeUp
--------------

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

                             (2) MasterSlaveDet
                                   procedure
                                 <===========>
                   
                            (3) OpenLogicalChannel
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


H245CallRetreiving
------------------

We apply rtp infos retreived from both calls to each other inside
OLCAck.


 PBX                                                   remote EP


                   (5) OpenLogicalChannelAck 
                       -------------------->          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
H245RetreiveCall)

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

regards,

-- 
Kiel