Hey all,

I'm butting heads with an unfamilliar behavior with NAT and a cisco 7206 router [NPE 300, IOS 12.4(25e)]. The 7206 is acting as the gateway for our SIP softswitch's subnet and is NAT'ing traffic between subnets for that device. In general, things are working just fine, but we're running into an issue when some devices perform a SIP reinvite pursuant to a transfered call -- our softswitch rejects the re-invite with a 401 Unauthorized.

At first we thought that this was an issue with the PBX, since when examining traffic from the PBX we discovered that the "response" line in the authorization digest doesn't seem to match the hashed digest output. Deeper investigation ultimately revealed that the digest output is getting altered by the 7206 during NAT.

Here's an example of what I'm talking about -- in this scenario I've used hypothetical subnets and phone numbers, but the results are accurate. User 9876543210 (SIP secret 9876543210) on a PBX at IP address 2.2.2.2 calls phone number 1234567890 at the softswitch with public IP 1.1.1.1, this IP address living on the 7206:


PBX Sends:
------------
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK-1c7c1e-d36a
To: <sip:[email protected]:5060>;isup-oli=00;tag=softswitch.example.com+1+27e844+4abe1223
From: <sip:[email protected]>;tag=21c35-7c1a-d35a
CSeq: 17846 INVITE
Call-ID: [email protected]
Date: Tue, 12 Jul 2011 16:53:50 GMT
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
Accept: application/sdp
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
Supported: replaces, 100rel
User-Agent: device
Authorization: Digest username="9876543210",realm="softswitch.example.com",uri="sip:[email protected]:5060",cnonce="abcdef",nonce="zyxwvut",nc=00000001,response="16d53156babf25cae86e6ce5788f225f",qop=a uth,algorithm=MD5
Content-Type: application/sdp
Content-Length: 196

v=0
o=- 1310489626 1310489628 IN IP4 2.2.2.2
s=Call
c=IN IP4 2.2.2.2
t=0 0
m=audio 15162 RTP/AVP 0 96
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
-----------


The 7206 NAT's the traffic and forwards it on to the softswitch:

Softswitch Receives:
-----------
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK-1c7c1e-d36a
To: <sip:[email protected]:5060>;isup-oli=00;tag=softswitch.example.com+1+27e844+4abe1223
From: <sip:[email protected]>;tag=21c35-7c1a-d35a
CSeq: 17846 INVITE
Call-ID: [email protected]
Date: Tue, 12 Jul 2011 16:53:50 GMT
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
Accept: application/sdp
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
Supported: replaces, 100rel
User-Agent: device
Authorization: Digest username="9876543210",realm="softswitch.example.com",uri="sip:[email protected]:5060",cnonce="abcdef",nonce="zyxwvut",nc=00000001,response="16d53156babf25cae86e6ce5788f225f",qop=a uth,algorithm=MD5
Content-Type: application/sdp
Content-Length: 196

v=0
o=- 1310489626 1310489628 IN IP4 2.2.2.2
s=Call
c=IN IP4 2.2.2.2
t=0 0
m=audio 15162 RTP/AVP 0 96
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
-----------


Note how the 7206 has altered the URI in the digest. This makes the response invalid because the hashed response hasn't been updated to take that new data into account, resuting in a 401 Unauthorized.

Any ideas why this occurs? The digest should under no circumstances be altered... Feels like a bug, but I can't find a reference to it.

Thanks!