Summary:ASTERISK-19716: Don't validate Contact URI hostpart when nat=yes
Reporter:Iñaki Baz Castillo (ibc)Labels:
Date Opened:2012-04-12 10:26:30Date Closed:
Versions: 13.18.4 Frequency of
is related toASTERISK-20238 Registering SIP user from JavaScript sipML5 client fails when random ".invalid" domain sent in Contact header
Description: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 (google.com?).
Comments:By: Iñaki Baz Castillo (ibc) 2012-11-01 15:47:51.834-0500

Hi, is there any update for this issue?

By: Walter Doekes (wdoekes) 2012-11-02 02:48:14.331-0500

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


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?

By: Iñaki Baz Castillo (ibc) 2012-11-27 11:37:38.763-0600

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.