WebRTC support

I am able to reproduce and fix this bug.

It appears that during my earlier testing of the client I still had the “hacked” jssip lib in place. @tm1000, perhaps you did/do, too?

With a fresh update of the modules and the stock jssip lib (0.7.23) I get the same error as artfulhacker. The reason is that the webrtc client registers with a contact containing “;transport=ws” at the end and Asterisk still needs to see that “;transport=wss” (not standard; see Asterisk bug mentioned elsewhere) or it tries to make contact using the unencrypted method. So Asterisk sends OPTIONS packets and calls to the client using the wrong method and deduces “UNREACHABLE.”

The workaround is to replace ‘ws’ with ‘wss’ on line 20429 of admin/modules/webrtc/ucp/assets/jssiplibs/jssip-0.7.23.js. I did so on my machine and it works again.

I did not hack the client library. If I did then it would be in the repo. It works fine without me hacking it and thus I am weary of doing so.

for jssip they have in the advanced option to add the “wss” hack, I thought I tried that yesterday but let me give it a shot just manually changing the file like you did.

this is very easy to reproduce, we purchased a brand new hosted freepbx box last night, ran all the upgrades and converted to asterisk 13. used the lets encrypt cert and added a single extension, enabled webrtc. disabled the firewall module and now we see the same thing.

I don’t understand how we are getting different results. Can you do the same sip debug that artfulhacker did and compare?

very strange, I tested it with the “hack_via_ws” checked on try it, same result. i am going to manually modify the file like you did and see what happens

1 Like

Yeah, that’s not the fix. It’s not about the “Via” header, it’s about the Contact: header used in registration.

that did it for me too!

how did you come to knowing to make that change? they might need another “asterisk only wss hack” since it looks like on github this file only has ‘ws’ but you are 100% correct, changing that to ‘wss’ fixed it instantly.

It’s this bug, which still exists in Asterisk: https://issues.asterisk.org/jira/browse/ASTERISK-24330

Other WebRTC clients with less pedantic developers have adjusted their code to work around Asterisk’s bug, but the jssip devs aren’t going for it. So either Asterisk devs acknowledge and fix the bug or you have to adjust the client to suit Asterisk.

Linked from that bug, here is an example where the OnSIP WebRTC client developers agreed to hack their client to deal with Asterisk: https://github.com/onsip/SIP.js/issues/97

1 Like

@tm1000 if you are interested in trying an alternative library that appears to be designed to work more smoothly with Asterisk, the OnSIP library is nearly API-compatible. I haven’t tried it, but it looks easy enough to work in. http://sipjs.com/guides/convert-to-sipjs/

this is great, we are going to get our system working with SIP.js and just manually create the extensions in freepbx. love the UCP and logins but for us we only need them to have the single extension and not have access to the UCP. With that said, as soon as I get a bare bones example of it working I would be happy to share the code.

The onsip library is great and I’ve previously talked to the developers over email but it’s not a simple conversion for the webrtc module. Its more complex because the hard fork of onsip is in the middle of where I’m at with jssip. Meaning the newer functionality I have with jssip (like hold and transfers) won’t line up at all with onsip. Anyways I usually recommend people use onsip when doing new projects involving webrtc which I’ve said over twitter in the past.

And while the jssip developers might not be as cooperative they are trying to enforce the webrtc rfcs which they’ve had input on. You have to give them credit for that.

That said I’ll have another look and see what can be done.

Also still not sure why I don’t need this hack but I have had little time to work on anything webrtc related.

Patches welcome if anyone gets to it before I do

if you’re able to verify, here is the pull request: https://github.com/FreePBX/webrtc/pull/2
I love what you have done in the UCP so far, depending on how progress goes with our project Ill keep you updated.

25,297 additions, 25,297 deletions not shown because the diff is too large. Please use a local Git client to view these changes.

It looks like you changed the ENTIRE file - possibly your editor changed some whitespace? I’ll comment on that, but we can’t accept that pull request.

wth… so I thought I would be slick and try githubs new “edit file” feature…
using the normal client now to make that change. thanks for catching that!

1 Like

Much better!

Published as webrtc v13.0.23

At some point I’d like to get onsip’s implementation working.

1 Like

you mentioned “transfer” is that option currently in production for the UCP? Does the extension need a setting enabled? I am looking into building HOLD and TRANSFER code right now with sipjs.

Hold is already in there. Transfer you can do by simulating the feature code from the system. Call waiting can be done by going on hold then switching the audio streams.

1 Like

In webrtc v13.0.25 I switched to the SIP.js driver. I tested pretty throughly but probably missed a few things.

2 Likes