SDP. plan-b end, only unified plan

[albertius661]

Hello. Does anyone have a solution to get it to work with sdp on the unified plan? Chrome in its beta version (Version 95.0.4638.69 (Official Build) (64 bits)) no longer accepts plan-b Thanks.

[clks001]

Me too..

[surfrock66]

We fixed this in our fork, please see this commit. Because we're so far downstream I haven't applied a pull request, but the fix works: https://github.com/L1kMakes/sipml5-ng/commit/f0432ecd1dd36036755b653b7cdf386adf69c7be

[albertius661]

Hello. Thanks for the reply. This is not working for me. I can establish a call with the unified plan, but after hold resume does not work. We know that it is not our configuration (kamailio and Asterisk) because jssi works correctly.

Can there be any solution? Can we help in any way?

Thank you very much.

[surfrock66]

This a bit of a pain (I left my previous job where I was working on this and had to batch a ton of changes in 1 big commit). We found and fixed the bug, it's in this commit:

https://github.com/L1kMakes/sipml5-ng/commit/6fd731d57e79fb2e07e2fc84f216a1d4fd63ef21

If you scroll down it's in this file: src/tinyMEDIA/src/tmedia_session_jsep.js

It's in line 450. Basically the WebRTC functionality for "addTrack" changed to creating an additional RTPSender, rather than just appending a track. You have to switch to the "replaceTrack" method, which is async. We have it working, but the way we batched our commits we can't really push to upstream.

[albertius661]

Thank you very much for the information. Hold/ Resume is working but an unknown error has appeared, I think related to ragel...

Failed to parse header: From: 10121\sip:10121@webrtc1578965.domain.es:443\;tag=u4vFvLgd2yiMIptinb5l tsk_utils_log_error @ SIPml-api.js:4513 tsip_header_NameAddr.Parse @ SIPml-api.js:21126 tsip_header_parse @ SIPml-api.js:51974 tsip_message_parser_execute @ SIPml-api.js:11066 tsip_message.Parse @ SIPml-api.js:11148

Any ideas? Thank you very much.

[surfrock66]

Not sure; what is that tag? Do you know what info is being sent for the user/callerID? That's in the header, and I see "NameAddr.Parse" is part of the error.

[albertius661]

Thanks for the quick reply. It has worked for us to comment display_name When display_name has a value, when called, the From header contains the id number, not the name. For example: display_name: "Albert" - From header = 1234<sip:1234 (This gives an error because it does not have quotes " (it is not a string) also, the id appears instead of the name) // display_name: "Albert" - From header = <sip:1234 // this works fine

Thank you very much.

[albertius661]

Hello again. Now I have noticed that in Chrome the hold/Resume works correctly. But n Firefox 97.0.1 (64-bit) has no audio when Resume. In Firefox console everything perfect, in kamailio and Asterisk console everything perfect. Any ideas? Thank you very much.

[surfrock66]

Hmm, not sure. It could be around the way the webRTC stream reattaches, but it worked in our tests; the interesting thing is the changes to webRTC we made in that patch came from Mozilla's API documentation.

I'm no longer with the org I was developing this at, so testing is a little trickier. I would want to add a breakpoint to that bit of the api, and inspect the objects to make sure there's only 1 Sender and see what the track id's are.