Cyber mega demo with Chrome unified-plan

Asterisk Asterisk WebRTC
#1

Hello!

I’m trying to get a minimal example of the Cyber mega phone (https://github.com/asterisk/cyber_mega_phone_2k/) 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(https://sipjs.com/api/0.11.0/sessionDescriptionHandler/#modifiers), 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?
#2

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.

#3

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 (https://github.com/garage11/ca11) in case I manage to get sdp-interop working with SIP.js.

#4

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…

#5

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.

#6

Ran into the same issue, added a PR to fix Chrome detection: https://github.com/asterisk/cyber_mega_phone_2k/pull/2

#7

Fyi: Latest SIP.js with Asterisk 17.3 work fine with unified-plan and Chrome

#8

Working on a simple JavaScript SIP client myself, I encountered the issue again. The browser sends:

a=group:BUNDLE 0 1
a=mid:0
a=mid:1

Asterisk returns:

a=group:BUNDLE audio-0 video-1
a=mid:audio-0
a=mid:video-1

Where it should return something similar as the browser instead, resulting in the exception:
Failed to set remote answer sdp: The order of m-lines in answer doesn’t match order in offer. Rejecting answer.

Adding Content-Type: application/sdp to the INVITE solved it for me.

1 Like