[asterisk-bugs] [JIRA] (ASTERISK-29300) res_rtp_asterisk: When native local bridging the remote SSRC becomes permanent

[Sebastian Damm (JIRA)]

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

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

This fixes the behavior. But Asterisk now behaves differently to reverting your patch from ASTERISK-28773. After reverting the patch (and up to Asterisk 16.9), Asterisk would generate exactly one SSRC for simple bridge. Then it would switch between b-client SSRC in native bridge mode and its own SSRC in simple bridge. 

Your patch makes Asterisk generate a new SSRC every time the call leaves native bridge. Technically, this is totally okay, but for debugging purposes the former version was nicer. In a trace from yesterday, I had exactly two streams with the same IP/port combination, in the new one, I had 6 of them because I toggled between native and simple bridge a few times.

> res_rtp_asterisk: When native local bridging the remote SSRC becomes permanent
> ------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29300
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29300
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 16.10.0, 18.2.0
>            Reporter: Sebastian Damm
>            Assignee: Unassigned
>            Severity: Major
>              Labels: patch
>         Attachments: 0084_change_ssrc_on_p2p_stop.patch, 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)