[asterisk-bugs] [JIRA] (ASTERISK-29300) Asterisk does not change SSRC when changing between bridges during call

[Sebastian Damm (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253860#comment-253860 ] 

Sebastian Damm commented on ASTERISK-29300:
-------------------------------------------

Actually yes, this fixes the issue. And it looks like I was wrong. 16.9 still works fine, but 16.10 was broken. After reverting the mentioned patch, 16.10 works as expected. And 16.16 does as well.

Sorry for mentioning the wrong change as a cause. And thanks for finding the right one.

> Asterisk does not change SSRC when changing between bridges during call
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-29300
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29300
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_native_rtp, Bridges/bridge_simple, Bridges/bridge_softmix
>    Affects Versions: 16.9.0, 18.2.0
>            Reporter: Sebastian Damm
>            Assignee: Sebastian Damm
>            Severity: Major
>         Attachments: debug_log_16.16_29300.txt, debug_log_16.8_29300.txt, example_asterisk_16.16.png, example_asterisk_16.8.png
>
>
> This is a regression bug, it was possibly introduced by the change from ASTERISK-28733. When switching between bridges during the call, Asterisk must change the SSRC, too. Until 16.8 it did, after this change it doesn't anymore.
> In our case, a call starts using native bridge. It just passes the SSRC and sequence number from A to B and vice versa. Then MixMonitor is triggered, forcing Asterisk to switch to simple bridge. In Asterisk 16.8 this lead to a new SSRC and new sequence numbers. In Asterisk 16.9 and up, Asterisk starts using its own sequence numbers, sets a marker bit on the first RTP packet, but does not change the SSRC anymore. Depending on the sequence numbers generated by Asterisk, this can lead to immediate audio loss (when Asterisk seq < other client seq) or audio loss as soon as the call switches back to native bridge (when Asterisk seq > other client seq).
> The change in behavior can be seen in Wireshark, see the two screenshots attached. Scenario is the same: two clients on my machine call each other, through Asterisk. In-call, MixMon gets engaged and disengaged multiple times. I have filtered for only rtp packets with marker bit set.
> One hint for reproduction: Even though you can see the fault in Wireshark also on UDP calls, the audio drops appear only with TLS clients.



--
This message was sent by Atlassian JIRA
(v6.2#6252)