cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1010
Views
0
Helpful
5
Replies

SIP NAT Call-ID problem

youcharley
Level 1
Level 1

We recently faced a sip NAT issue. and I would like to get some insights for this problem.

call flow:

Avaya phone system >> telco IPBE device >> ISP

telco IPBE is doing the SIP NAT.

The call coming into the telco IPBE device:

from LAN.png

The invite is from 10.203.16.13, call-ID shows ip from 10.203.18.12. Once pass through IPBE deivce, the outbound traffic towards ISP shows:

out WAN.png

The invite ip from 10.203.16.13 natted to 172.27.4.5, and the call-id ip from 10.203.18.12 natted to 172.27.4.1. Up to here, everything is fine.

However, the return packet back to customer LAN shows:

back LAN.png

As you can see, the return packet towards customer LAN, the invite header shows the original private ip: 10.203.16.13, however, the call-id still showing the natted ip: 172.27.4.1.  This cause the issue.

Is this looks like router bug that unable to un-nat the packet back to LAN for the call-id?

Thanks for your advice here.

 

5 Replies 5

R0g22
Cisco Employee
Cisco Employee
A couple of things from this -

1. This is not a SIP INVITE that you are looking at. Look at the Request URI. This is a OPTIONS message.

2. Next, the record-route header shows just a proxy in the path that wants to stay in the path for all the transactions related to this dialog. This does not mean that the packet originated from that IP.

3. I am not sure if the call-ID @ip NAT will affect anything or not but if the device doing a NAT does a L7 packet re-write from private to public, it should do a re-write back from public to private when the responses need to be forwarded into the private network.

Now two questions -

What issue do you see because of the call-ID header IP ? Also, what device is this doing the NAT ? Is this a Cisco box ? Platform/IOS etc ?

Thanks for the reply Nipun.

Yes, it's Cisco router doing the NAT.

Platform: ASR1000

IOS: asr1001x-universalk9.03.16.01a.S.155-3.S1a-ext.SPA.bin

And can you also answer the other questions that I posted ?

The problem is that the call is not able to establish. The return packet from IPBE back to customer Avaya shows '500 Server Internal Error'.

Customer did the packet capture on their Avaya device, and they confirmed the call-id ip address is not showing correctly once inbound to their device.

Did you check my response to your original post ? The message that you are highlighting is not a INVITE. It is a OPTIONS.
Next, the OPTIONS that was send was already rejected with a 500. This is the same OPTIONS that you see as being NAT'ed correctly. I am still not sure what am I missing here.