[asterisk-dev] [Code Review] 4157: bridge_native_rtp: Fix T.38 directmedia fax test by always asking the remote peers to update themselves on native bridge stop

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4157/
-----------------------------------------------------------

(Updated Nov. 8, 2014, 6 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers and Joshua Colp.


Changes
-------

Committed in revision 427582


Repository: Asterisk


Description
-------

When Josh merged his "please stop lying to me bridging layer" patch, the fax/sip/directmedia_reinvite_t38 test started failing. After some investigation, we figured out why.

When two RTP channels are in a native bridge, the bridging layer will investigate each via the get_rtp_info glue callback. This callback returns the native bridge preference of the channel *at that moment in time* (that part is key). At different points during the bridging, the native bridging layer will inform the RTP capable channels of the status of the bridge via the update_peer glue callback.

In a T.38 scenario with audio direct media, the sequence of events will often look like the following:
 * SIP/A and SIP/B both have audio and enter a native bridge
 * Asterisk re-INVITEs audio between SIP/A and SIP/B directly (via an update_peer callback)
 * SIP/A sends a re-INVITE to T.38, which causes Asterisk to send a re-INVITE to T.38 to SIP/B. Assuming everyone 200 OKs the process, the UDPTL stack receives UDPTL packets in Asterisk from both endpoints. From the perspective of the channels, we are now in a local bridge for T.38, even though we are technically still in a remote bridge in bridge_native_rtp. (YAY!)
 * When one side hangs up, bridge_native_rtp is told to stop bridging. It then re-evaluates the channels and asks them how they are bridged - and since T.38 is enabled, they reply with a Local bridge (which is correct), but is wrong because the audio portion is still technically in a remote bridge
 * Asterisk releases the surviving channel, whose audio is *not* re-INVITED back to Asterisk as bridge_native_rtp incorrectly assumes that it was in a local bridge

Ironically, this used to work mostly due to a fluke in the bridging layer.

The purpose of the get_rtp_info callback shouldn't be modified: it should tell the bridging layer what kind of bridge the channel prefers at that moment in time. If you have T.38 enabled, that *must* be a local bridge (since direct media + T.38 is a path of craziness that I don't want to contemplate. This is what you get when you embed an antiquated PSTN-based protocol into an unreliable UDP stream. Blech). As such, I didn't change that callback.

However, we have to tell the channels to re-evaluate themselves when they come out of a native bridge, since we can no longer trust the get_rtp_info callbacks when the native bridge is being stopped. Something else may have changed in the channels, and they may now be lying to us. As such, this patch makes it so that we unilaterally tell the channels that they are no longer bridged via the update_peer callback. This is actually what the channels expect anyway: code in both chan_sip and chan_pjsip's callbacks look at the T.38 state and - if they were in T.38 - send a re-INVITE to get the audio back to Asterisk.


Diffs
-----

  /branches/12/bridges/bridge_native_rtp.c 427539 

Diff: https://reviewboard.asterisk.org/r/4157/diff/


Testing
-------

SIP and PJSIP tests pass (at least, the ones that should be passing).

The fax/sip/directmedia_reinvite_t38 test now passes, as audio is now re-INVITED back to Asterisk for the surviving channel.


Thanks,

Matt Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141109/8e03109b/attachment.html>