Websockets On Asterisk 11 And SipML5

Home » Asterisk Tips » Websockets On Asterisk 11 And SipML5
Asterisk Tips 9 Comments

In order to set up a user in Asterisk so that It can register via sipml5, on Asterisk 11. In the sip.conf entry for the account you are trying to register as place the following:



;allow=all ; Allow codecs in order of preference


Now, modify the sipml5 library so that the URL looks like this: ws://example.org:8088/ws (with the /ws at the end, as instructed). In order to get sure that the 8088 port is open, and that Asterisk is actually listening for WebSockets traffic, remember to enable the http.conf module:




9 thoughts on - Websockets On Asterisk 11 And SipML5

  • Look to see if the /ws is showing in an “http show status”

    *CLI> http show status HTTP Server Status:
    Server Enabled and Bound to

    Enabled URI’s:
    /httpstatus => Asterisk HTTP General Status
    /phoneprov/… => Asterisk HTTP Phone Provisioning Tool
    /amanager => HTML Manager Event Interface w/Digest authentication
    /uploads => HTTP POST mapping
    /arawman => Raw HTTP Manager Event Interface w/Digest authentication
    /manager => HTML Manager Event Interface
    /rawman => Raw HTTP Manager Event Interface
    /static/… => Asterisk HTTP Static Delivery
    /amxml => XML Manager Event Interface w/Digest authentication
    /mxml => XML Manager Event Interface
    /ws => Asterisk HTTP WebSocket

    Enabled Redirects:
    / => /static/admin.html

  • Andrew Latham gmail.com> writes:

    Hi Michael,

    I apologize. It looks like the patch did fix the crash. I had two instances of Asterisk running, discovered after running “ps -C asterisk u”. One must have been the previous instance, before applying the patch and recompiling.

    While the server isn’t crashing anymore, I’m still getting the 400 Bad Request and the 401 Unauthorized when trying to login. From what I hear, this could be something that needs to be modified in the sipML5 library itself. Thus, I’ll see what I can find. If anyone knows why I’m getting the unauthorized and bad requests, please let me know. I’ll update the mailing list as well.

    Thanks again!

  • Hi James, after applying the patch, I got the 400 bad request message as well… This seems to be related to the sipml5 client (same issue with sip-js)
    generating a wrong request. Take a look at the contact header in the REGISTER message.

    I was not able to fix the js code to generate the correct request… In fact it should look like this (sip:user@local-ip:local-port)

    regards, Sven

    2012/8/14 James Mortensen

  • mailsvb gmail.com> writes:

    generating a wrong request. Take a look at the contact header in the REGISTER
    message. it should look like this (sip:user local-ip:local-port)

    Hi Sven,

    I know this doesn’t fix the sipML5 problem, but I changed line 145 of tsip_transport.js in the sipML5 library from

    return “df7jal23ls0d.invalid”;


    return “10.x.x.x”;

    where 10.x.x.x is the local IP where I’m trying to register from. I am getting a 200 OK from the Asterisk server and am able to connect to it, but I can’t make any calls yet.

    I’ll continue looking at the sipML5 code and will post an update if I get anywhere.

    Thanks again!

  • James Mortensen a-cti.com> writes:

    getting make

    Hi Sven,

    According to the developer of sipML5, the problem is that Asterisk 11 doesn’t fully support SIP over WebSockets, which means that the problem is not necessarily in the sipML5 codebase.

    See the Doubango thread here, as well as the spec Mamadou cites:

    He cited the spec, which indicates that the client is supposed to send
    “df7jal23ls0d.invalid” as the domain name, since the client side doesn’t really know what to send.

    The main difference I see between the SIP messages in the spec and my SIP
    messages is this line:

    I have:

    Supported: path

    Whereas the spec has:

    Supported: path, outbound, gruu

    Anyone know what these do exactly and whether or not sipML5 needs to send outbound and gruu?

    Thank you, James

  • Hi James,

    I’ve trimmed the thread down, well, completely. ^_^

    From looking at your information and reading the code it looks as though there is a case where this may occur if certain NAT options are enabled. This is certainly a bug as the code should just not execute when WebSocket is involved. For an immediate fix you can set nat=no in the entry in sip.conf. This should change the result and would also explain why this has not been seen by others.

  • Joshua Colp digium.com> writes:

    Hi Joshua,

    I’m still getting the same result. Here is what I have in my sip.conf:


  • James Mortensen wrote:

    I apparently flipped a bit mentally. Try nat=yes for kicks. Otherwise place this info on the issue if not already there and I shall attempt to get to it when I can for a deeper inspection.