12-10-2011 07:49 PM - edited 03-11-2019 03:01 PM
I have to be missiong something small in my config.
If I upgrade my ASA 5510 which I am routing and NATing off of, from 8.4.1 to 8.4.2.8, SIP stops. All phones go dead.
If I roll bck to 8.4.1, SIP comes up.,... Go bck to 8.4(2)8 nd SIP goes down.....
This is without mking any config changes.
I have looked at it so long, I must be overlooking something simple, simple, simple...
Solved! Go to Solution.
12-11-2011 05:08 AM
Hello Jazzeyb,
I am 95 % sure that you are hitting a known bug, the problem with Sip on this version is that the Embedded Ip address ( You can see it on a capture) does not get translated, unfortunetly there is no solution yet, the bug is still open, the only workaround would be to do a downgrade,
I will keep you posted on this and will provide you the Bug ID on Monday.
Please rate helpful posts.
Have a great day,
Juliio!!
12-11-2011 04:25 AM
Have you ensured that the relevant configuration is unchanged when you upgrade to 8.4.2.8?
Do you see any change in configuration specific to SIP Inspection after upgrade?
When you are on 8.4.2.8 do you see any drops in "show service-policy inpsect sip". Pl share the output of same at the time of issue.
Is this traffic over a VPN tunnel?
12-11-2011 04:42 AM
Also, is your VOIP server internal or external (internet)?
As you have mentioned all phones go dead, i understand the phones are not even registering to the server, right?
12-11-2011 05:08 AM
Hello Jazzeyb,
I am 95 % sure that you are hitting a known bug, the problem with Sip on this version is that the Embedded Ip address ( You can see it on a capture) does not get translated, unfortunetly there is no solution yet, the bug is still open, the only workaround would be to do a downgrade,
I will keep you posted on this and will provide you the Bug ID on Monday.
Please rate helpful posts.
Have a great day,
Juliio!!
12-11-2011 03:18 PM
Have spent sIx hours in past 24 w/ Cisco TAC and they have a tin of caps as have I but can't figure out why there is a denial of SIP from inside outside and outside inside to/from sip providers three IP addresses. Have created new access lists, new access groups to allow all 3 ip's in & out, increased timeout, bypassed IPS, have both sip UDP & tcp allowed in/out, specified inspection to approve any any for all sip protocols in/out to/from Lync & mediation and nada.
To answer another question, yes I'm certain config doesn't change... I reloaded tge same running config from a bkup just to make sure.....
What I see in the logs coming in/out is the call does make it all the way through the SSM to the ASA..
What happens there is the head scratcher...
SiP even though allowed and even though I've specified it to push through inspection On ASA side is denied based on inspection rule...
I also tried using another one of my (unused) public IPs for only SIP thinking that maulybe there was a core conflict with multiple services NATd to the same public IP but that also did nothing.
On topology I only have a single location so I'm using my 5510 to route as well...
Have 1 IIS web server l, SQL, (ports clised except to obe vendor and am allowing via access list by their IP and ipsec,) Exchange, Lync, Ironport, Endpoint and everything else is 80/80...
Everything is on Server 08r2 w/ exception of web server and two boxes ( one stand-alone & one VM on hyper-v) I am running Server8 for Microsoft TAP engineering / validation airlift. Neither of those are attached to UC/UM at all...
I'm using dynect from dyndns for outside network web services and just piggybacking on time Warner metro e for internal (no physical DNS server)
When I look at caps everything is identical in the tcp and UDP trace even on sip except for the denial...
Which caps/logs would 'y'all like to see and I'll post em when I get home....
Is there a link to bug notes Jullio? Is it sip specific? Any possibility of it being just a name/cosmetic big I can force a work around to?
I recall when Asa first was released I had to specify port 25 allow instead of being able to simply say allow smtp .. That took 2 weeks but it allowed for a work around so whatever I can do/try I'm willing!! Someone may wanna tell TAC if it's a bug because after 6 hours yesterday they are saying there's not a bug... :)
Thanks all!!!!
12-11-2011 03:22 PM
Oops .. Sorry.. Re-read saw you will send me ID tomorrow... Was just too excited to jump to the point when I saw the replies... Have gOne through 3 engineers over 5 days on this issue & when I saw "bug" I think I started doing a jig..... :) no I will not post a video of that... :) haha
12-11-2011 06:17 PM
Hello Jazz,
Lol, as soon as I get into my desktop tomorrow morning I would send you the bug ID you are hitting, but yes, its a sip issue on that particular version, the problem as I said before the embedded IP address on the SIP invite or SIP ack does not get natted.
I will keep you informed.
Please rate helpful posts.
Julio
12-12-2011 01:15 PM
Do you think it could have just been a fluke that it was working in 8.4.1? ( I was running .1 at time of original implementation...)
12-12-2011 02:10 PM
Hello Jazz,
Dificult to say, It should not have worked on that version, but reading your description seems like its is an issue with the SIP inspection.
Is it possible that you could go to 8.4.1 and get the following information
a) Debug sip ha b) show sip
c) capture asp-drop type asp-drop all buffer 200000
d) show capture asp | include xxxx(phone)
And then go to 8.4.2(8) and get the same information but first clear the capture asp-dropa) Debug sip ha b) show sip
c) capture asp-drop type asp-drop all buffer 200000
d) show capture asp | include xxxx(phone)
Regards,
Julio
12-12-2011 09:34 AM
Hello,
This is the one I am talking about, as you can see the first time this was seeing was on 8.4.1
http://tools.cisco.com/squish/3DF8e
And here is the brief description:
After upgrading to ASA software SIP trunk flowing through the ASA doesn't work anymore.
The root cause of this issue seems to be that the SIP inspection and translation of IP addresses within the SIP header doesn't work correctly.
I think this is the right issue you are facing and the only workaround is a regresion of the version.
Please rate helpful posts,
Julio
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide