1. Asterisk
  2. ASTERISK-19716

Don't validate Contact URI hostpart when nat=yes


    • Type: Improvement Improvement
    • Status: Open
    • Severity: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s:, 13.18.4
    • Target Release Version/s: None
    • Security Level: None
    • Labels:
    • Regression:


      Asterisk 1.8 validates the host in the Contact URI of a REGISTER/INVITE. Such a URI host must be a valid IP address or a resolvable hostname (via DNS A/AAAA) for Asterisk to accept the request. This is not a real requirement in RFC 3261.

      This validation makes sense for the case in which such a URI will be used for routing requests to the peer, but it makes no sense at all (it's useless) when the peer is configured with nat=yes (so the Contact URI is ignored and instead the real source IP:port used for sending outgoing requests to the peer).

      The problem is that it avoids some cases in which the SIP client sets a non resolvable domain in its Contact URI (for example "sip:alice@idsukjdsf.invalid;transport=ws"), which is expected to occur in SIP over WebSocket access due to the fact that JavaScript running in web browsers doesn't know the source IP:port from which the WebSocket connection has been made. In these cases, using a .invalid domain (RFC 2606) seems much more ellegant than inventing a random IP or using a resolvable domain (

        Issue Links

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.


          Iñaki Baz Castillo created issue -
          Matt Jordan made changes -
          Field Original Value New Value
          Status Triage [ 10000 ] Open [ 1 ]
          Matt Jordan made changes -
          Link This issue is the original version of this clone: ASTERISK-19741 [ ASTERISK-19741 ]
          Richard Mudgett made changes -
          Link This issue is related to ASTERISK-20238 [ ASTERISK-20238 ]
          Joshua Colp made changes -
          Affects Version/s 13.18.4 [ 13983 ]


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


              • Created: