sipml5 icon indicating copy to clipboard operation
sipml5 copied to clipboard

SDP. plan-b end, only unified plan

Open albertius661 opened this issue 3 years ago • 9 comments

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.

albertius661 avatar Nov 01 '21 10:11 albertius661

Me too..

clks001 avatar Nov 02 '21 08:11 clks001

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

surfrock66 avatar Jan 04 '22 01:01 surfrock66

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.

albertius661 avatar Feb 21 '22 18:02 albertius661

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.

surfrock66 avatar Feb 21 '22 18:02 surfrock66

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:[email protected]: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.

albertius661 avatar Feb 24 '22 16:02 albertius661

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.

surfrock66 avatar Feb 24 '22 17:02 surfrock66

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 avatar Feb 25 '22 10:02 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.

albertius661 avatar Feb 25 '22 11:02 albertius661

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.

surfrock66 avatar Feb 25 '22 16:02 surfrock66