[asterisk-bugs] [JIRA] (ASTERISK-19716) Don't validate Contact URI hostpart when nat=yes

[Walter Doekes (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-19716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199164#comment-199164 ] 

Walter Doekes edited comment on ASTERISK-19716 at 11/2/12 2:59 AM:
-------------------------------------------------------------------

I think I might have fixed this, at least for in-dialog requests (to the Contact):

http://lists.digium.com/pipermail/asterisk-commits/2012-October/057327.html

In trunk only though.


There's another one: the Via sent-by header gets a resolve attempt too. Not necessary either.

Are there other places where the contact gets resolved/verified?
                
      was (Author: wdoekes):
    I think I might have fixed this, at least for the re-invite bit:

http://lists.digium.com/pipermail/asterisk-commits/2012-October/057327.html

In trunk only though.


There's another one: the Via sent-by header gets a resolve attempt too. Not necessary either.
                  
> Don't validate Contact URI hostpart when nat=yes
> ------------------------------------------------
>
>                 Key: ASTERISK-19716
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19716
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 1.8.11.0
>            Reporter: Iñaki Baz Castillo
>            Severity: Minor
>
> 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 at 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 (google.com?).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira