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

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-29300:
-------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

> 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: Asterisk Team
>            Severity: Major
>         Attachments: example_asterisk_16.16.png, example_asterisk_16.8.png
>
>
> This is a regression bug, it was 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)