PJSIP WebRTC Websocket url

Hello there !

Is there a way to change the “/ws” sub-directory for WebRTC (PJSIP-pjproject) ?

We are using asterisk behind a web proxy and there is some conflits with /ws url…

Thanks for your help !

No, there is not. It is a fixed value in code.

How can you have a conflict tho?
If you have another websocket app on the same box as the asterisk box, you will not be able to host it off the same port in any case, so if Asterisk is whatever OTHER service you run will have to be on another port first, before its running of another subdirectory.

I have many times used a proxy before Asterisk as the Websocket termination endpoint, you need to reverse proxy that back to the asterisk box, and there you specify the port (8080) and subdirectory (/ws).

Mostly I end the TLS on the proxy and then reverse the connection as HTTP back to the Asterisk Mini Host service. (This way you are not fiddling with certificates on the Asterisk box).

If you have conflicts there, yes, change the port it’s on in http.conf

1 Like

Hello thanks for your reply !

“Mostly I end the TLS on the proxy and then reverse the connection as HTTP back to the Asterisk Mini Host service. (This way you are not fiddling with certificates on the Asterisk box).” It’s what I do if I want to access to our device remotely. But I’ve to access to the device localy by local address IP… That means reverse proxy is not possible… Our application is using /ws url for our own websocket, asterisk is using the same. So what I would like to do is to forward websocket on “[my.local.ip.address]:(80/443)/customurlpath” to asterisk that listens on a random port (8888 or whatever)

But if you say that it’s not possible to customize Asterisk RTC url I will find an another way. Do you know if I set as connection URL “[my.local.ip.address]/ws?service=asterisk” in my RTC client would work or Asterisk is listening strict url “/ws”?

That said it would make sense that asterisk can listen to any “UPGRADE HTTP request” that is addressed to it. Is there a technical reason for “/ws”?

A couple of ways to look at this…
You would probably expose the two applications that offer websocket connections on two different TCP ports. Asterisk http.conf allows you to change this port easily, I assume the same for you own application. (From what I know two different applications cannot occupy the same TCP port, at startup the first application will occupy the port, and the second will fail. From what I recall, if Asterisk is second to load, it fails only the http module, and is other wise running.) This would immediately separate your two applications on the same box as follows: <= Asterisk Http Service <= Other Websocket application

Another approach: IP binding
You can bind more than one IP to the NIC, and then bind the two applications to the two IP addresses. From your response you don’t require these services to be publicly available, so again with local ip addresses on the same box you could have: <= Asterisk Http Service (with TLS enabled) <= Other Websocket application (also with TLS if you want)

As you can see by this its got nothing to do with the /ws sub-directory in either situation. There really is hardly ever a need to be able to change the /ws directory, and probably why its hard coded.

Thanks for your answer… I think you don’t get the problem.

I’m using two kind of connection on our device.
1: Remotly with reverse proxy wss://hostename.test.ch/ws (it’s not possible for use to access directly to the port ( 8080 in your example)). We have a complexe network based on 7 server.
2: Localy by his IP address…

In any case we cannot bind a secondary ip address. The only way we have to forward correctly the asterisk request is to change “/ws” url. On our device we’re proxying a lot of websocket. Each service are using a specific websocket url… We only have one entry point (:80 or :443) . I will try with “/ws&service=asterisk” hope this can work… With that I’m able to proxy websocket correctly…

Ok found a solution by changing url in the proxy /asterisk:80 => /ws:8080. don’t know why I didn’t think of it before. Sorry and thanks for your support!

This is what InnovateAsterisk was referring to in his responses :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.