Web RTC Client in Free PBX 6.12.65 with Asterisk 13

General Help
1

I should start by saying that I don’t claim any particular knowledge of the intricacy of web services or asterisk – hence the post. Additionally I completely understand that Web RTC is a technology in rapid evolution, with both servers and browsers constantly changing their implementations. For all of those reasons I have realistic expectations of getting this to work with Free PBX in the wild. That having been said I would be delighted if I were able to make this work and in deference to those who work so hard on FreePBX I thought I would give it a go. I would be grateful for comments and guidance on the following points. Im pretty sure Im way off the mark on most of them and would be happy to be set straight.

Note that quotes added to urls to prevent them appearing in post as links.

Current configuration – Latest version of FreePBX distro, 64 bit running paravirtualised on a XenServer. All SIP / IAX and other functionality working very well – including trunk and endpoint access outside the firewall.

External connectivity is via a Sonicwall UTM device with persistent NAT but with all other packet manipulation turned off.

Goal – to successfully implement user Web RTC clients for users in the FreePBX UCP accessed on the public (WAN) side of the firewall.

Current Status – All other functionality of the UCP is working on the Internet side accessed via sip.mydomain.com:81 but the Web RTC phone does not connnect. Looking at the Javascript console this appears to be a Cross-Origin Request Blocking issue – the error occurs when trying to access the URL for the web services – in my case sip.mydomain.com:8080/ws

Some observations and questions

Out of the box the latest build (+ updates) of Free PBX appears to have the web services server (http) listening on port 8088. The requests made by the UCP Web RTC client appear to be to port 8001. I have therefore changed the listening port of the micro web server to 8001. Has this been noticed by anyone else?

Secondly I understand that to satisfy the Same Origin Policy rules the request has to come from exactly the same domain as the resource being accessed – including the protocol, host and port.

It appears that this is not being satisfied by my interned based web browser clients. Both Firefox and Chrome report being unable to access the resource. This seems reasonable because the source of the request is ‘http://sip.mydomain.com:81’ and the resource is on the asterisk server at ‘http://sip.mydomain.com:8001’ - ie the port number is different.

This seems by design – the UCP is on port 81. So my question is – do I need to apply CORS (Cross Origin Resource Sharing) headers to the httpd server that provides the web services on Asterisk / FreePBX? I have tried adding Access-Control-Allow-Origin: ‘http://sip.mydomain.com:81’ but this does not seem to make any difference.

I would like to make progress with this but I am mindful that there might be a great deal of work going on in the background and a lot of these issues might be known about.

If anyone has any information or advice that would influence my decision to persevere with this I would be very grateful. If I haven’t made any elementary mistakes I might need to wait until further releases of browser and Web RTC clients emerge.

Thanks in advance for feedback and to those working on the code for a very exciting project.

2

You don’t need any CORS to get WebRTC to work unless it’s trying to access a different address than what you are using in the browser. But without seeing any actual error message I am going to say the two are not related. The WebRTC client detects (automatically) whatever port you have defined in Advanced Settings for “HTTP Bind Port”. For our master Schmooze server that is 8088. So you shouldn’t have had to change anything unless you are doing something manually. 8088 is the default as well so it appears you already were or had changed something and that could be breaking other things moving forward.

I would say these are only issues on/with your setup. First try to reset your http.conf settings in /etc/asterisk you should let FreePBX control this file and you shouldn’t have anything in _custom files for http as well.

3

Thanks Andrew - that’s reassuring. I’m going to reset all the httpd settings as you suggest and then see if that resolves the issues. Regards, Geoff.

4

Andrew - understand that you might not want to get too drawn into this given the fragile nature of Web RTC behind NAT but I get the following error message even when http.conf and other ports reset.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ‘http://mycomain.com:8001/socket.io …’

Even through the request is coming from the same domain.

Incidentally I cant find anywhere in FreePBX / Asterisk where a STUN server is specified - I was wondering if that might be the issue?

By way of an update - this is cerrtainly something to do with RTP streaming - I’m now able to connect to the web sockets port in Chrome and Asterisk correctly dials out but no media at all and Im seeing this error:
GET ‘http://mydomain.com:8001/socket.io/?token=db14bec9ff14c97dd0e5118e3ef250aa&EIO=3&transport=polling&t=1416355373733-21 net::ERR_CONNECTION_REFUSED’

I wondered if this was an error in the way I had created the certificates or a simple password problem, but Im not sure that I understand the authentication process sufficiently to debug this - NAT certainly complicates everything!

5

The “socket.io” messages have nothing to do with WebRTC. It’s actually a websocket client where as we have not released the server part. You’re getting those messages because you don’t have the server portion installed. This has nothing to do with RTP/WebRTC/Dialing/Audio.

I need to work on disabling those messages but have not gotten around to it yet, as they are meaningless.

6

Thanks - I see. If I weed those out I will see what I’m left with. I notice that there does not seem to be a STUN server specified in any of the configuration files (although there may be in the Web RTC client - I dont know where to look). ICE is enabled in the peer definition for the WebRTC user account but I get an ICE failure message in the browser client when trying to connect. I feel like Im floundering around a bit here :smile:

7

If you are still get ICE failures then you should look in SIP Settings to make sure you haven’t put icesupport=no there somewhere. Or look in sip.conf or sip_additional.conf or sip_custom.conf. STUN doesn’t really matter until you get ICE support working… then again I would have to see the error as Im guessing.

Of note, in most browsers if a STUN server is not defined the browser will use it’s defaults, such as google will use google STUN servers if one is not defined and you are using Chrome so a STUN server doesn’t need to be set.

8

Andrew - thanks for your amazing help with this - I feel like Im learning loads (which I know isnt the goal but it helps!).

It turns out that buried under other error messages was this:

Uncaught CONFIGURATION_ERROR: Invalid value "sip:@mydomain.com" for parameter “uri”

I would have thought that this should be:

[email protected] - or in my case [email protected]

Is there a parameter or config file I can look at to see why the client is getting sip@ rather than 992000@ ?

I think Im getting warm but … :smile:

9

Just one more thing in case it is significant / useful. In the latest FreePBX User management GUI I have noticed that the ‘Enable Web RTC Phone’ setting is ‘sticky’. If I link the User account to a specific extension the ‘Enable RTC Phone Option’ shows as selected. Attempting to turn it off and then saving does not change the status of the setting. Im not sure if this switch configures the Web RTC client for that user - but perhaps its not being triggered?

10

Can anyone help me with where I might look for the configuration that is generated for the Web RTC phone in the context of what I have posted above?

11

Hi Skydoc.

I’ve been a little busy with working on some cool stuff for FreePBX 13 right now so I haven’t gotten to take a look at UCP and other weirdities that you have reported. I’m about to jump right back into that right now though so let me look into that and try to help.

12

Ok so in 12.0.0beta5 I fixed the ability to be able to delete or disable webrtc.

Here is what I advise you do. Uninstall webrtc so that it will delete anything it finds that could be bad relating to it. Then reinstall and set it up again. There was an issue that could have also prevented webrtc from being able to remove itself as an extension when being disabled that I also fixed.

I tested both the “experimental” and “non experimental” hold support using Asterisk 13 and Chrome 39.0.2171.62 beta. Both tested worked flawlessly when dialing *43

13

Andrew - quite understand! I greatly appreciate any time that you have spent on this, it has helped enormously.
I have done as you suggested and uninstalled the module and installed 12.0.0beta5. As you say enabling and disabling Web RTC phone works fine as does extension removal.
All the Web RTC functionality works perfectly for Web clients inside the network (ie on the same subnet) but from outside the firewall I get all the functionality but no media (ie silent calls in both directions). I have enabled all the ports I can think of in the firewall and made sure Im not doing anythig weird with the packets in the firewalls NAT handling all to no avail. I notice that the Web RTC created extensions (99700 for example) have nat=no in their definition. Could that be the problem here?
Let me know if Im being helpful or not …

14

Nat mode doesnt matter in a WebRTC setup. You could change it if you wish but I doubt it’ll make a difference.

Of note when I test I am going through nat to the external server, im not local

15

Andrew, thanks.
I think that I might have made an elementary mistake. Every time I have to set up port forwarding and NAT to an asterisk box I have to re learn everything I thought I knew. NAT can be so frustrating.
I have set the hostname of the actual box to the FQDN associated with the external IP address. I have also used this name in the servers certificates. I think this would have been fine if the box had a direct connection to the Internet but it is in fact behind a NATed firewall.
I’m guessing that this causes all manner of issues when routing although external trunks seem fine.
Am I right in assuming that I should make the hostname of the box something completely different and use that name in the certificates and then rely upon NAT and ICE to sort out the media routing? Am I correct in assuming that my current setup is fundamentally incorrect? Thanks!

16

Sorry if double posting occurs. Mobile browsers!

17

The hostname in the certificate shouldn’t matter at all. If the certificate was bad you wouldn’t be able to connect, your issue is only one way audio.

18

Hi Andrew
Just an update (and another question - sorry). I have finally decided to roll up my sleeves and try and solve this with the help of Wireshark.

  1. Both the asterisk server and the Web RTC browser client are behind different NAT boxes.
  2. Initially the client was seeing Binding requests only from the asterisk servers local address and was trying to reply to that address. I added a stun server into rtp_custom.conf and now the binding requests come from both the internal and external IP (non route-able and route-able addresses). So I figure that the WebRTC client should respond to both.
  3. The IP address sent by the Web RTC client is non route-able - which Im assuming is wrong - shouldn’t the Web RTC client be doing NAT?
  4. My firewall sees all these packets and is passing them to the asterisk box.

As I see it NAT traversal is ok at the asterisk box end but not at the Web RTC client end - but frankly I have a great deal of admiration for anyone who understands all this stuff - its making my head spin!

Any ideas if this is the right way of looking at things?

Regards …

19

Andrew, thanks.
I think that I might have made an elementary mistake. Every time I have to set up port forwarding and NAT to an asterisk box I have to re learn everything I thought I knew. NAT can be so frustrating.
I have set the host and of the actual box to the FQDN associated with the external IP address. I have also used this name in the servers certificates. I think this would have been fine if the box had a direct connection to the Internet but it is in fact behind a NATed firewall.
I’m guessing that this causes all manner of issues when routing although external trunks seem fine.
Am I right in assuming that I should make the hostname of the box something completely different and use that name in the certificates and then rely upon NAT and ICE to sort out the media routing? Am I correct in assuming that my current setup is fundamentally incorrect? Thanks!

Geoff.

On 21 Nov 2014, at 17:22, Andrew Nagy <[email protected]mailto:[email protected]> wrote:

[http://cdn.discourse.org/freepbx/user_avatar/community.freepbx.org/tm1000/45/3128.png] tm1000http://community.freepbx.org/users/tm1000
November 21
[http://community.freepbx.org/letter_avatar/skydoc/40/2.png]Skydoc:

have nat=no in their definition

Nat mode doesnt matter in a WebRTC setup. You could change it if you wish but I doubt it’ll make a difference.

Of note when I test I am going through nat to the external server, im not local

To respond, reply to this email or visit Web RTC Client in Free PBX 6.12.65 with Asterisk 13 in your browser.