[asterisk-bugs] [JIRA] (ASTERISK-29300) Asterisk does not change SSRC when changing between bridges during call
Joshua C. Colp (JIRA)
noreply at issues.asterisk.org
Thu Feb 18 04:13:15 CST 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253850#comment-253850 ]
Joshua C. Colp commented on ASTERISK-29300:
-------------------------------------------
We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis.
Thanks!
[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
Also a full debug would be useful for this. The previous behavior is not something I've seen, and I don't see any previous code that would strictly do that kind of stuff so seeing what is going on with the debug level in the old and new version would be helpful as well.
> 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
> 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)
More information about the asterisk-bugs
mailing list