Asterisk
  1. Asterisk
  2. ASTERISK-20238

Registering SIP user from JavaScript sipML5 client fails when random ".invalid" domain sent in Contact header

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: 11.0.0-beta1
    • Target Release Version/s: None
    • Component/s: None
    • Security Level: None
    • Labels:
      None

      Description

      According to the spec, the JavaScript SIP client should send a random ".invalid" domain in the Contact header, since the JavaScript implementation has no way to determine the IP address or the port to send.

      It seems that the Asterisk server should instead use the existing port 8088 to send WebSocket responses back to the client; however, the end result is a 400 Bad Request.

      If I send my hard-coded IP address, I see a 200 OK message. I've also tried seeing the nat=no setting in sip.conf.

        Issue Links

          Activity

          Hide
          James Mortensen added a comment - - edited

          I've attached the DEBUG information from a call attempt. I can register with nat=yes option and the nat=yes, force_rport options. However, the call attempt from sipML5 results in a 488 Status code.

          It sounds like it could be an encoding problem, but I'm not 100% sure.

          Show
          James Mortensen added a comment - - edited I've attached the DEBUG information from a call attempt. I can register with nat=yes option and the nat=yes, force_rport options. However, the call attempt from sipML5 results in a 488 Status code. It sounds like it could be an encoding problem, but I'm not 100% sure.
          Hide
          Joshua Colp added a comment -

          I've fixed the underlying issue here in subversion for 11 as of revision 371482 and trunk as of revision 371483. One other thing you will need is "avpf=yes" in the entry in sip.conf for the client. Putting this all together though still has things not working properly. Unfortunately while the Chrome team have made progress in further conforming to the official ICE specification they still have a little ways to go. The produced SDP is now close enough to what it should be to be parsed by us, but the actual outgoing packets to Chrome are ignored by it. It doesn't even return an error.

          Additionally I will be working on documenting things on the wiki.

          Show
          Joshua Colp added a comment - I've fixed the underlying issue here in subversion for 11 as of revision 371482 and trunk as of revision 371483. One other thing you will need is "avpf=yes" in the entry in sip.conf for the client. Putting this all together though still has things not working properly. Unfortunately while the Chrome team have made progress in further conforming to the official ICE specification they still have a little ways to go. The produced SDP is now close enough to what it should be to be parsed by us, but the actual outgoing packets to Chrome are ignored by it. It doesn't even return an error. Additionally I will be working on documenting things on the wiki.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development