|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:30||Date Closed:|
|Versions:||18.104.22.168 13.18.4||Frequency of|
|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).
|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.