Request rejected because IP doesn't match (NAT)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Do a capabilities exchange where NAT comes into play.
2.
3.

What is the expected output? What do you see instead?
I have contacts registered, but because of NAT, the contact addresses don't 
match the actual IP of the device (as it sees it, since it's in private IP 
space...192.168...). When the client registers, we recognize the public 
IP:port, and record that against the contact. When the registrar receives a 
lookup request, it redirects to the public IP (since it can't route to the 
private IP). When the client gets the request (initially an OPTIONS) it 
complains that the IP in the Request-URI doesn't match with the registered 
contact. During the registration, the received and rport parameters are updated 
in the client-inserted Via header.

04-06 17:53:33.423: V/[RCS][ImsServiceDispatcher](2420): Request-URI IP doesn't 
match with registered contact: reject the request

I don't know if this is as per RFC 3261, or if the client should recognize the 
external IP as returned in the received and rport parameters.

What version of the product are you using? On what operating system?
2.4.1. I don't think we encountered this before, although we did make some 
updates recently that may have caused this to pop up now.

Please provide any additional information below.

Original issue reported on code.google.com by iiaGa...@gmail.com on 6 Apr 2012 at 9:01

[GoogleCodeExporter]

We added this additional checking in the request line to be sure that an 
incoming request on the IP address corresponds to the registered contact. This 
has been requested by Telco where are platform sending request to an old IP 
address (reused by another client), this happdns when devices don t unregister 
properly after having lost their connectivity. But if there is a problem of NAT 
we should replace this checking by another one. Can you propose a patch for 
this?

Original comment by jmauffret@gmail.com on 7 Apr 2012 at 6:34

• Changed state: Started

[GoogleCodeExporter]

A solution may be to check the IMPU instead of an IP address?

Original comment by jmauffret@gmail.com on 7 Apr 2012 at 6:47

[GoogleCodeExporter]

Or can both the internal IP and the "received:rport" combination also be 
considered as valid?

Original comment by iiaGa...@gmail.com on 7 Apr 2012 at 2:01

[GoogleCodeExporter]

Is anything else expected from me? If so, what? If not, is there a plan in 
place to address this scenario?

Original comment by iiaGa...@gmail.com on 7 May 2012 at 7:58

[GoogleCodeExporter]

I hesitate to do the modification because we are in production. Nevertheless 
can you send me a trace (with REGISTER + INVITE) to have a better overview of 
your network platform.

Original comment by jmauffret@gmail.com on 11 May 2012 at 8:20

[GoogleCodeExporter]

Here is the registration for a device behind a NAT. At this point the proxy has 
already filled in the received and rport parameters. The device thinks it's at 
24.34.154.95:5060, but we see it as 74.198.164.223:43875 (and pass that back in 
the Contact header):

REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 192.168.38.241:7050;branch=z9hG4bK7811.1b99a202.0,SIP/2.0/UDP 
25.34.154.95:5060;branch=z9hG4bK136e20d8f7b4f7234b5b86e3a59b48aa373039;received=
74.198.164.223;rport=43875
Route: <sip:24.224.135.226:7050;lr;transport=UDP>
Max-Forwards: 69
Call-ID: jaZWRdTcAA@25.34.154.95
From: <sip:+15554412865@domain.com>;tag=LfZWRdTfAA
To: <sip:+15554412865@domain.com>
CSeq: 2 REGISTER
Contact: 
<sip:25.34.154.95:5060>;+g.3gpp.app_ref="urn%3Aurn-7%3A3gpp-application.ims.iari
.gsma-is";+g.3gpp.cs-voice;+g.oma.sip-im;+sip.instance="<urn:uuid:cbda4ae9-cdd5-
3e89-8e3b-4e6b13f7631a>"
Expires: 1800
Allow: INVITE,UPDATE,ACK,CANCEL,BYE,NOTIFY,OPTIONS,MESSAGE,REFER
Authorization: Digest 
username="+15554412865@domain.com",uri="sip:domain.com",algorithm=MD5,realm="dom
ain.com",nonce="4fb25b570a081b3de53a7e27ae3d517716154a26",response="67331caca894
f0072ca57117a077d422",opaque="00453323533243
5434ffac663e",nc=00000001,qop=auth,cnonce="1337099651951"
Supported: path, gruu
User-Agent: IM-client/OMA1.0 OrangeLabs-RCS-client/2.4.1
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.38.241:7050;branch=z9hG4bK7811.1b99a202.0,SIP/2.0/UDP 
25.34.154.95:5060;branch=z9hG4bK136e20d8f7b4f7234b5b86e3a59b48aa373039;received=
74.198.164.223;rport=43875
Call-ID: jaZWRdTcAA@25.34.154.95
From: <sip:+15554412865@domain.com>;tag=LfZWRdTfAA
To: <sip:+15554412865@domain.com>;tag=nyoDrgOec4KzEjcA
CSeq: 2 REGISTER
Contact: <sip:74.198.164.223:43875>;expires=180
Content-Length: 0
P-Associated-URI: <sip:+15554412865@domain.com>

Next, an OPTIONS is sent for a capability request to the registered contact:

OPTIONS sip:74.198.164.223:43875 SIP/2.0
Via: SIP/2.0/UDP 192.168.38.241:5064;branch=z9hG4bKlcTUu6WuNykVxUeB
Route: <sip:74.198.164.223:43875>
Max-Forwards: 70
Call-Id: 7682-5nZxU38oVMW1mO0y
From: <sip:+15554017536@domain.com>;tag=3aXGjraHFPxwVF4U
To: <tel:+15554412865>
CSeq: 1 OPTIONS
Contact: 
<sip:192.168.38.241:5064>;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.i
ari.rcse.im,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft"
Accept: application/sdp
Accept-Contact: 
*;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im,urn%3Aurn-7%
3A3gpp-application.ims.iari.rcse.ft"
Allow: INVITE,UPDATE,ACK,CANCEL,BYE,NOTIFY,OPTIONS,MESSAGE,REFER,SUBSCRIBE
User-Agent: <redacted>
Content-Length: 0
P-Preferred-Identity: <sip:+15554017536@domain.com>

And we get a 404 back:

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 192.168.38.241:5064;branch=z9hG4bKlcTUu6WuNykVxUeB
Call-ID: 7682-5nZxU38oVMW1mO0y
From: <sip:+15554017536@domain.com>;tag=3aXGjraHFPxwVF4U
To: <tel:+15554412865>;tag=F4gWRdTgAA
CSeq: 1 OPTIONS
Content-Length: 0

I hope that helps. 

Original comment by iiaGa...@gmail.com on 15 May 2012 at 4:42

[GoogleCodeExporter]

I would like to propose a fix for this condition, which also improves the check 
for non-NAT'ed environment. It parses the incoming URI and checks the host (and 
host/port for NAT'ed environment) using equals() instead of contains(). I have 
tried it in both environments and it seems to be working.

Original comment by ngrigor...@gmail.com on 6 Jun 2012 at 5:44

Attachments:

• android-rcse-trunk-nat-traversal-addr-fix-jun6.diff

[GoogleCodeExporter]

I think there's a similar issue specifically for NOTIFYs when subscribing to 
presence or watcherinfo. In that case the SUBSCRIBE contains a Contact that 
includes a domain name instead of an IP. Sending a NOTIFY with the Request-URI 
to the Contact exactly as it was received in the SUBSCRIBE results in a 404. 
But so does setting the R-URI's host part to the local IP:port or the NATed 
IP:port. All result in 404's.

Original comment by iiaGa...@gmail.com on 3 Oct 2012 at 10:05

[GoogleCodeExporter]

I see that this is listed as Fixed in release 2.4.12. Is that correct?

Original comment by iiaGa...@gmail.com on 4 Jan 2013 at 5:39

[GoogleCodeExporter]

Yes you are right. Now we test the username of the To URI instead of an IP 
address.

Original comment by jmauffret@gmail.com on 4 Jan 2013 at 7:49

• Changed state: Fixed