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

[Iñaki Baz Castillo (JIRA)]

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

Iñaki Baz Castillo commented on ASTERISK-19716:
-----------------------------------------------

Sorry for the late response, I didn't get notified about your comment.

Via sent-by should be 100% ignored always. If Via sent-by contains a domain or an IP different from the source addres, then Asterisk should add a ";received=REAL_SOURCE_IP" to the top Via in responses to that SIP request, that's all. The address in the sent-by set by the peer should be just used for sending responses in case of error when sending to the original IP (exotic RFC 3261 feature that nobody implements and that never works in the real world full of NAT).

So I hope Asterisk does not resolve Via sent-by, never.

                
> 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