Cyber mega demo with Chrome unified-plan



I’m trying to get a minimal example of the Cyber mega phone ( working with Asterisk 16. So far, everything works as expected with my test setup:
Firefox desktop <=> Firefox Android
Chrome desktop <=> Firefox Android
Firefox desktop <=> Chrome Android
Chrome desktop <=> Chrome Android

Both audio and video start almost instantly in all cases. Chrome still has plan-b sdp set as the default. There was a small issue in the demo though: the isChrome check failed, which prevented the demo to work in Chrome(ium). The sdp-interop part seems to be required, otherwise the demo keeps on waiting for video.

After fixing this, I wanted to translate this JSSIP/sdp-interop example to SIP.js, but it is not clear to me how sdp-interop/JSSIP originator translates to SIP.js. I first tried to apply sdp-interop in a modifier(, but that didn’t work out. I don’t know exactly which sdp message(s) to adjust(no originator as in JSSIP). Couldn’t get this to work, so my next try was to force unified-plan sdp from chrome://flags. My thought was that Chrome would then behave similar to Firefox and all i would need to do is to apply data.sdp.replace(/actpass/g, 'active');. I checked with Firefox, and this line seems to be mandatory as well. Without it, the video won’t start playing.

So, I adjusted the Cyber mega demo to act as if Chrome was Firefox. Too bad, I get exactly the same result as leaving out the Firefox sdp modification or Chrome sdp modification; the video channel just won’t start. Sometimes, the video starts playing one-sided after a couple of minutes.

My questions:

  • Is Chrome with unified-plan as WebRTC client tested and expected to work with Asterisk 15/16 without using sdp-interop?
  • What is the sdp modification data.sdp.replace(/actpass/g, 'active'); part for, why is it only required for Firefox?
  • How would I need to apply sdp-interop to SIP.js in case Chrome with unified-plan is a no-go?


Chrome with unified-plan has not yet been tested or confirmed working for anyone.
The SDP modification is required as Firefox has a bug where it does not properly implement the DTLS-SRTP specification, expecting the wrong setup attribute. The line fixes it and allows negotiation to occur.
I’ve never touched SIP.js but at its core the code needs to call sdp-interop to convert unified to plan B before giving it to Chrome, and then converting plan B to unified for SDP from Chrome. That’s what has to happen - but as I said I have no experience with SIP.js so I don’t know the details.


Alright thanks for explaining! For now I’ll try to adapt SIP.js to work with sdp-interop and see if I can learn some more things about the sdp format in the meanwhile. I’ll add a link to the working code ( in case I manage to get sdp-interop working with SIP.js.


Got the same result now with SIP.js. StreamEcho, video conference and video call work between Chrome using SIP.js In case anyone wants to accomplish the same:
This gist shows a custom SessionDescriptionHandler that uses sdp-interop-sl to manually change the sdp. The only parts that needs to be changed start with interop.

Next issue I’m trying to tackle is to restore the video streams after an on-hold. A reinvite shouldn’t be a problem for recreating the video streams should it? I’m seeing the same tracks being re-added after on-hold, but they don’t start to play. I’ll dive a bit deeper into that. Wondering if this would also works for a transfer…


I haven’t dealt with re-invites like that in quite awhile so I don’t know the implications within the browser. Behavior can change version to version.