There is also a way I think you can force things to not behave that way, which is to add “proxy_media” to your bridge creation alongside “mixing”. ie: “mixing,proxy_media”
That should force it through the core and the resulting RTP stream won’t be as preserved as much from an RTP header perspective, but it may make it more tolerable for whatever is on the other side.
That’s not the official meaning. It simply means that this is a good place to adjust the length of the jitter buffer. A different stream should have a different SSRC. Quite a few years, where I was working, we found that some PABXes needed an actual SSRC change, so we added code to do that, although some other brands didn’t like it, so we had to make it conditional.
@david551 Yes, it’s an absolute mess.
Asterisk 18 is the exact same setup. Local bridging, ulaw, etc… No changes to the endpoint.
I added proxy_media and it didnt make a difference. We are actually using proxy_media, my test cli app didnt have it so an oversight on my part.
I’ve got nothing else to add then at this time. From what you’ve provided, the packet capture shows the media being forwarded.
So looks like its the SSRC changing. In v18 with the same stasis app, the ssrc does not change but in v22/23 it changes. Webrtc handles the change seamlessly but we have devices that do not.
We are stuck on v18 until this is resolved.
On v22 and 23 when playing media to the bridge, it will change the ssrc when removing/adding channels. If I dont play media to the bridge, when removing and adding channels it doesnt change the ssrc.
Any thoughts on a workaround? It would require quite a bit of a rework and I dont know if its feasible with all of use cases.
Nothing springs to mind.
[bug]: no audio when media source changed during the call · Issue #927 · asterisk/asterisk · GitHub is likely the issue and linked PR that would have done it
The code was subsequently changed so it’s not done if bundle is enabled, so enabling that would stop the SSRC from changing though would expand the SDP some. I think things would still work, though haven’t tested.
Would this be classified as a bug since some devices dont support a ssrc change?
We use webrtc in some scenarios. However in most cases we do not.
Based on reading looks like enabling bundling is tied to webrtc explicitly. That wouldnt work for our use cases.
It’s not tied to WebRTC explicitly. It’s a separate configuration option[1] and is still negotiated. You can file an issue, but there’s no guarantee on when/if it would get looked into.