[asterisk-bugs] [JIRA] (ASTERISK-22692) Native RTP (p2p) bridge is not torn down during transition to soft mix

[Matt Jordan (JIRA)]

Matt Jordan created ASTERISK-22692:
--------------------------------------

             Summary: Native RTP (p2p) bridge is not torn down during transition to soft mix
                 Key: ASTERISK-22692
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22692
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Bridges/bridge_native_rtp
    Affects Versions: 12.0.0-beta1
         Environment: Asterisk branch 12 r400672
            Reporter: John Bigelow
            Assignee: Kinsey Moore


With two SIP or PJSIP channels (directmedia is disabled) in a bridge (native rtp/p2p) and then a non SIP channel (Announcer in this case) is placed into the bridge (changing it to soft mix), the native RTP bridge is still active. This results in two interleaved RTP streams being sent to each of the two phones which comes out the speaker/handset as very distorted.

Devices involved:
* Asterisk - 10.24.18.161
* Phone A (phone_A) - 10.24.19.97
* Phone B (phone_B) - 10.24.18.165

Steps performed:
1. Dialed into Stasis() app from two phones
2. Created a bridge via ARI (being a simple bridge)
3. Added phone_A to bridge via ARI (still a simple bridge)
4. Played a sound file to the bridge via ARI. Audio sounded fine.
5. Added phone_B to the bridge via ARI (changing it to a native_rtp bridge)
6. Audio between phones sounded fine.
7. Played a sound file to the bridge via ARI. Audio coming out of both phones was distorted.

Packet capture analysis:

RTP streams when channel of phone_A & phone_B are sitting in *Stasis() app and not in a bridge*:
* Synchronization Source identifier: 0x77981F70 (2006458224)
** Flow: 10.24.19.97 -> 10.24.18.161
* Synchronization Source identifier: 0x92A6BCA5 (2460400805)
** Flow: 10.24.18.165 -> 10.24.18.161

RTP stream when channel of phone_A was placed into the *simple bridge* and sound file was played to the bridge:
* Synchronization Source identifier: 0x3E1192BF (1041339071)
** Flow: 10.24.18.161 -> 10.24.19.97

RTP streams after channel of phone_B enters the bridge and it transitions to *native RTP*:
* Synchronization Source identifier: 0x77981F70 (2006458224)
** Flow: 10.24.19.97 -> 10.24.18.161
** Flow: 10.24.18.161 -> 10.24.18.165
* Synchronization Source identifier: 0x92A6BCA5 (2460400805)
** Flow: 10.24.18.165 -> 10.24.18.161
** Flow: 10.24.18.161 -> 10.24.19.97

RTP streams for the two SIP channels after bridge transitions to *soft mix*:
* Synchronization Source identifier: 0x77981F70 (2006458224)
** Flow: 10.24.19.97 -> 10.24.18.161
** Flow: 10.24.18.161 -> 10.24.18.165
* Synchronization Source identifier: 0x92A6BCA5 (2460400805)
** Flow: 10.24.18.165 -> 10.24.18.161
** Flow: 10.24.18.161 -> 10.24.19.97
* Synchronization Source identifier: 0x7CB85663 (2092455523)
** Flow: 10.24.18.161 -> 10.24.19.97
* Synchronization Source identifier: 0x1A0BF3D9 (436990937) -- SSRC changed - was 0x3E1192BF (1041339071)
** Flow: 10.24.18.161 -> 10.24.18.165

The streams above are the native RTP (p2p) streams along with two other streams where the 0x1A0BF3D9 stream is the 0x3E1192BF stream but with a new SSRC as shown in the log. I'm not sure if the 0x7CB85663 stream appears to be newly created but I'm not positive about this. So each phone ends up receiving two streams while in a soft mix bridge.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira