SIP: Remove first VIA from the INVITE, or how to force BYE to send to the second VIA?

[Roman Rodichev]

Our ASA NATs both source and destination for incoming SIP messages (including inspection). We need to NAT source for a specific reason that is outside of this post. Calls are then forwarded to internal CUBE gateway and then to the media server. Calls are working, but SIP BYE messages never get to the right NAT IP on the ASA. Instead CUBE sends BYE messages to the original Public IP address. ASA doesn't know what to do with it and drops it. Calls stay connected, not good.

In the original SIP INVITE before it hits ASA, there are two VIA header fields, containing two public IP addresses (something that comes from the SIP Provider and that I can't control). It appears that ASA "fixes up" only the second VIA field and translates it to the internal IP address.

Here's the original:

And here it is the after outside NAT inspection is completed:

There are ABSOLUTELY NO other references to the 64.2.142.90 IP in this SIP invite. The only two are that first VIA and that Record-Route.

Later when call is disconnected by the internal media server it sends BYE to CUBE, and CUBE sends BYE to the 64.2.142.90. I want it to send BYE to 10.0.0.174. 10.0.0.22 is CUBE.

Does anyone know if it sends it to that Record-Route IP or to the first VIA IP? I have a feeling it's the first VIA IP.

1. If it sends it to VIA, the question is how do I tell CUBE to send it to the second VIA, or how do I tell CUBE (or ASA) to remove the first VIA from the original INVITE?

2. If it sends it to Record-Route IP, the question is how do I tell CUBE or ASA to remove it from the original INVITE?

Thanks!

UPDATE: TAC says that CUBE sends traffic to the Record-Route IP. So that means my problem is with ASA which should outside NAT that IP during inspection, but it doesn't. Need to find a solution:

1. Bug fix in ASA so that it starts to NAT Record-Route during inspection

2. There are no manual SIP message translations allowed in the ASA as far as I know

3. Force CUBE to delete, ignore, change Record-Route

[Alexander Maroukian]

Hi Roman,

Did you try SIP header modification for the record-route? I am not sure if it will change the destination of the packet itself in the current case but you can apply it to outgoing SIP headers on CUBE. Please check the following link:

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080982499.shtml#conf

HTH,

Alex

[Roman Rodichev]

I actually just got off the phone with Scott from TAC ASA team, they suggested to use Outside NAT instead of PAT and it solved the problem.

As you said, CUBE only modifies outgoing SIP headers, but in my case it already received the "incorrect" SIP header and was using public IP in the incoming Record-Route to send BYE messages to.

The problem was on the ASA, I thought it should be translating Record-Route IP just like it was translating other fields. The reason why it wasn't translating Record-Route IP is because it was just IP address without a port specified (default UDP 5060). When it's just IP without port then you can't use Outside PAT to translate it during inspection. It has to be Outside one-to-one NAT. Once I changed it from Outside PAT to Outside NAT, ASA started translating Record-Route, and it solved my issue with the BYE messages.

Instead of this:

object network obj-10.0.0.174

host 10.0.0.174

object network obj-any

nat (outside,inside) dynamic obj-10.0.0.174

I'm now doing this:

object network obj-range

range 10.2.0.1 10.3.255.255

object network obj-any

nat (outside,inside) dynamic obj-range

This fixed actually solved some other problems I was having with some calls not connecting.

[Alexander Maroukian]

Nice solution with the ASA. Rated!