[test-results] [Bamboo] Asterisk > Asterisk Unit Tests > #808 has FAILED (4 tests failed, no failures were new). Change made by Matt Jordan.

[Bamboo]

-----------------------------------------------------------------------
Asterisk > Asterisk Unit Tests > #808 failed.
-----------------------------------------------------------------------
This build occurred because it is a dependant of AST-ATRUNKFULLBUILD-836.
2/2 jobs failed, with 4 failing tests, no failures were new.

https://bamboo.asterisk.org/bamboo/browse/AST-ATRUNKUNIT-808/

---------------------
Currently Responsible
---------------------

Corey Farrell (Automatically assigned)
John Bigelow (Automatically assigned)
Richard Mudgett (Automatically assigned)



--------------
Failing Jobs
--------------
  - CentOS 6 32-Bit Unit Testing (Unit Testing): 2 of 457 tests failed.
  - CentOS 6 64-Bit Unit Testing (Unit Testing): 2 of 457 tests failed.



--------------
Code Changes
--------------
Matt Jordan (427584):

>bridge_native_rtp: Fix T.38 issues with remote bridges
>
>After r425242 the fax/sip/directmedia_reinvite_t38 test started failing due to
>the surviving channel not being re-INVITEd back from T.38 to audio. This patch
>fixes that bug - a deeper explanation of what happened follows.
>
>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, prior to r425242, 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, as the UDPTPL
>stack must be in the media path. As such, this patch does not modify that
>part of the code.
>
>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.
>
>Review: https://reviewboard.asterisk.org/r/4157/
>........
>
>Merged revisions 427582 from http://svn.asterisk.org/svn/asterisk/branches/12
>........
>
>Merged revisions 427583 from http://svn.asterisk.org/svn/asterisk/branches/13
>



--------------
Tests
--------------
Existing Test Failures (4)
   - AsteriskUnitTests: /res/parking/dynamic parking variables
   - AsteriskUnitTests: /channels/features/test features channel dtmf
   - AsteriskUnitTests: /res/parking/dynamic parking variables
   - AsteriskUnitTests: /channels/features/test features channel dtmf

--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20141109/67323399/attachment-0001.html>