Fundamental problem is I can't get the SIP trunk to register, however we can recieve calls and have two way voice, so we are 90%+ there.
My question relates to how the SIP processing works on the ASA.
What we have is a UC540 behind an ASA5505 connected to the internet via a 887VA and an FTTC connection. The ASA is doing static NAT between the inside address of the UC540 and a spare public IP on the outside of the ASA. SIP inspection is turned on at the ASA.
With this SIP trunk, authentication is provided by IP address rather than user/password (I have other UC540's running using the user/password method and ASA/887VA).
Doing a SIP trace on the UC540 I see repeated attempts to REGISTER.... but no replies. I have not yet determined if the message is reaching the SIP provider, or the reply not being recieved at our end (The second option seeming unlikely as incomming calls do reach us).
001265: Aug 27 15:20:31.583: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
I appreciate that we're 7 months down the line now, but I, too, am trying to connect to Gamma over a SIP trunk.
Our ASA 5510 is doing Static NAT of our public IP address to our internal server IP address, and we've configured SIP Inspection so that all of the headers get NAT'd, too.
Inbound calls work great - all of the headers in the SIP INVITE (and other messages) are NAT'd correctly, so inspection is doing a bang-up job.
However, outbound (from us to Gamma) we were running 8.4.6 release and none of the headers were being inspected and NAT'd (i.e. To: From: P-Asserted-ID, Contact, Via). After upgrading to 8.4.7 every header EXCEPT From: are NAT'd correctly in both directions. So, my big problem now is how to get the From: IP address converted from Private to Public IP and why does the ASA do every other damn field and not this one?
I wrote a SIP normalization script for the CUCM to change the Private IP in the from header to our Public IP address and guess what? The ASA decides to NAT it back to the internal address before sending it out!!!!!!!!!!
So, any help from anyone with similar issue would be massively welcome!
I opened a TAC case and Cisco eventually decided that it was a bug (CSCuo23892). We were sent an engineering pre-release to use in the meantime but it has been integrated into the main branch now so you shouldn't hit the same issue with a newer version of the software.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...