UC500 behind SA500 occaisional outbound audio is dropped...rtp ports?

Unanswered Question
Mar 2nd, 2010

Hey guys,

I'm working on a system for a client that is similar to most of the configurations that we do including a load balancing SA520 in front of a UC500.  I have it configured to pass SIP and VPN traffic through the SA500 to the UC500, but I ran across a really strange thing the other day.  I generally test inbound and outbound calls by calling my cell phone (Verizon).  I happened to call a normal terrestrial number and didn't get any audio on subsequent calls.  The person on the other end called me back and audio worked fine.  At this point, it appeared as though I had a problem in my configuration, so I started trying all sorts of different phone numbers to check the UC500/SA500 configuration.  What I came up with, is this:

Equipment configuration: SA520 - UC540 - ESW520FE - ESW540FEwithPoE

Handsets: SPA502G and 7925 wifi phones

SIP Trunk provider: Nexvortex

Codec preference 1: G729r8

Codec prefernece 2: G711ulaw

1. All calls inbound and outbound work to Verizon and ATT cell phones (didn't try Sprint or other providers)

2. Calls will USUALLY work from this customer's site to our corporate office (which has a UC520 and is making use of PSTN lines from local telco Centurylink)

3. Occaisionally audio will drop when calling our corporate office

4. Calls will ALWAYS drop when I call my wife's office

5. Calls will ALWAYS drop when I call the customer's office in South Carolina's State IT department

The State IT department Office has an Avaya IP PBX

Our corporate office is employing a Cisco UC520 IP PBX

Not sure what my wife's office is using

To troubleshoot the problem, I removed the SA520, changed the WAN IP address of the UC540, DNS info, added NAT and Firewall, and ALL calls work perfectly.  It appears as though the problem somehow exists within the SA520 configuration, but I'm having trouble figuring out exactly where the problem lies.

I do a little CLI configuration to change codec preference, configure the transcoder for G729 for AA and VM, to reuse 5060 for SIP invites, and to change the rate at which SIP registration takes place.  Otherwise, everything is built with CCA 2.2.1.

I have the SBCS working on this, but so far, no luck.  Can anybody tell what I'm missing here?  It appears to be SA520 related, but I am unsure about where else to go from here.  I would greatly appreciate any suggestions that anybody might have.



P.S.  Here are some logs from a connected call with failed audio.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
vibhan Wed, 03/03/2010 - 16:38

Hi Seth,

    I can see one thing in the logs that can be causing the problem if the SP is not using the correct "c" contact header to send the RTP. Currently UC500 is sending 2 contact headers.

  Can you apply this on UC500 and try the call again with SA500 in front of UC500. This will force the UC500 to send only 1 header-


voice class sip-profiles 1
request ANY sdp-header Connection-Info remove
response ANY sdp-header Connection-Info remove

voice service voip
  sip-profiles 1


A similar issue was also discussed in this post -


sethschmautz Wed, 03/03/2010 - 23:48

Hi Vibhan,

This solution fixed our problem right away.  Can you shed a little more light on why this problem would be so intermittent on some systems, intermittent on other PBXes (our corporate PBX), and not an issue on others (calls to cell phones)?  I very much appreciate your help with this, as this addressed our need perfectly.



vibhan Thu, 03/04/2010 - 10:54

Hi Seth,

   As Maulik mentioned in the other post,  this issue is also caused by the SP side not being RFC3261 compliant as the RFC clearly states that the SIP end points must honor the 2nd c= line over the 1st c= line in the SDP (1st and 2nd are with respect to the position in the SDP).

   So in your case if the SIP call is terminated by a PBX or a SP that is not RFC3261 compliant you will see the problem. For SP or PBX that is RFC 3261 compliant you would not see this problem.



sethschmautz Thu, 03/04/2010 - 11:06


This makes great sense, and as I was thinking about it this morning, it may not even be our SP that is causing the problem (please feel free to correct my thinking if I am wrong here, I am learning a lot about SIP through these exchanges). Unlike a lot of scenarios, our clientelle are using Enterprise satellite connections so that they can remain mobile and communicate from anywhere.  The Satellite ISP offers voice, but is is ridiculously expensive.  NexVortex does more signalling than actual call termination.  So outbound calls may not even be routed through a NexVortex softswitch.  Instead, NexVortex signals where the IP traffic ought to go and it is terminated by a different softswitch from a different provider.  Depending on where you are calling to, your mileage may vary on whether the SP for that area is RFC compliant or not.  This is why some calls (say to a cell phone provider like ATT or Verizon) would always work.  There is more pressure to be RFC compliant because of their size.

I will log this information and add it to my general template.  Curiously, this only shows up when the UC500 is behind another NATing device like the SR500 or the SA500.  Is this because one "c" header (excuse my terminology if incorrect) is from the UC500 and the other is from the SA500?

Thanks again.  Wish I could buy you a beer.  That problem was driving me crazy.


vibhan Thu, 03/04/2010 - 15:20

Hi Seth,

   You don't see this issue when you have only UC500( with NAT on UC500, no SA500) because UC500 NAT is translating both "c" headers from Internal IPs to external IPs. So it doesn't matter if the other end is RFC compliant or not as they would be fine using either "c" header. You can see this in if you look at SIP messages on UC500 with NAT enabled without using SA500.

   In case there is a SR520 or SA500 connected to the WAN of UC500, the NAT translations are done by them and they are translating one  "c" header which is correct as per RFC, but causing issues with non compliant SPs or PBXs.



JP Rike Tue, 07/12/2011 - 18:52

Has this solution continued to work for you Seth? I am having some of the same issues now with NexVortex.

- JP

JP Rike Wed, 07/13/2011 - 15:27


Thanks for the response. I am starting to learn that the SA is a bit of trouble. Going through our running config more with Cisco, we have already applied:

request ANY sdp-header Connection-Info remove

response ANY sdp-header Connection-Info remove

I just need to take out the SA now, however, i need NAT. The UCs we have tried to configure NAT on do not like it. That is one of the upsides of the SA. Now, we are looking at the ASA. Thoughts? Have you tried the ASA in your deployments? Any NAT issues on the UC for you?


sethschmautz Wed, 07/13/2011 - 16:35

Hi JP,

Were you using the SA mostly for the load balancing or just to have an edge device outside of the UC?  NAT has always worked very well for us on the UCs, and it's usually a pretty quick and easy change to reconfigure the UC for NAT.  What issues are you having with NAT?

As for the ASA5505, we're going to roll our first one out to replace an SA520 next week.  I'll let you know how it goes, but I think it can't be worse. :-)  The SR520 is also a decent router.  Might be worth looking into. 


JP Rike Wed, 07/13/2011 - 16:49


I am sitting here with an SR right now doing the configuration on that. That might solve some problems.

We were using the SA as an edge device. The idea was to use it for load balancing however that has not always worked as described. Although the device continues to get better with each firmware release.

For NAT are you using CLI or CCA? We have been going round and round using CCA to configure the NAT and everything looks good in the config however, it does not work. Thoughts? It should work like a charm.

We just ordered an ASA5505 and it will be here tomorrow. Hopefully that will solve any other issues. We will let you know how that goes.

- JP

JP Rike Wed, 07/20/2011 - 14:05


Here are some updates.

For now, the ASA is still in the box and we are still using the SA.

-The UC has been configured to allowed to allow IPs for SIP and RTP Traffic. We and Cisco removed the CCA ACL.

-The SA has been configured to allow only the IPs of the SIP Signaling Server and the IPs of the RTP traffic to pass directly through to the UC.

-We have upgraded all the firmware on the SPA phones. We use skinny for everything however, it was a suggested by another discussion in the forum to do this and Cisco found the case that said it helped.

-The SA is still doing all the NATing.

Everything we have done has tremendously helped the situation.

However, we ran into an issue today where we did not have the media IPs configured on the SA, and the calls were dropped. Funny enough, they were calling into a WebEx meeting. We will make the exceptions for those media IPs later today to see if it helps.

From this and other situations, I am starting to wonder if the SA does not like to pass a range of port traffic through the firewall using a range of "all IPs". It will however pass IPs that are "named" with a range of ports pretty much flawlessly.

From talking with Cisco today, we were hearing problems of the ASA not fully passing the "c" headers through. We will be testing it in our Lab within the next few days. I would rather not make a client site the "lab" if at all possible.

- JP

JP Rike Sat, 07/23/2011 - 19:42


The problem has crept back up again. The clients users have been quiet until this past Friday. The dropped calls are back however, the static is gone.

We will be going ahead and trying the use of the ASA next week. Darn, I thought we were almost there with the SA....It just needs to allow all media IPs to pass or anything with a 5060 port to pass.

I was also noticing in our config that even though we deleted the CCA Access List that it still shows up on our config:

access-list 2 permit x.x.x.x (SIP 1)


access-list 2 remark SDM_ACL Category=1

access-list 2 permit x.x.x.x (SIP 2)

access-list 2 permit x.x.x.x (Media IP)

access-list 2 permit x.x.x.x (Media IP)

access-list 2 permit x.x.x.x (Media IP)

access-list 2 permit x.x.x.x (Media IP)

access-list 2 deny   any

My thinking is, that those lists should be gone. And the UC should allow anything, especially since the SA is blocking everything to prevent toll fraud.)


sethschmautz Mon, 08/01/2011 - 10:36

Hi JP,

Sorry for the delay in replying to you, but we had a big project due, and a trip out of town that followed immediately after.

I never experienced dropped calls with the SA520 in front of the UC540.  We did experience a few different things though:

1. No audio on calls to specific PBXes.  The solution in this case was to remove the C headers as shown above.

2. Choppy audio.  The solution in this case was to dedicate more of the WAN bandwidth to the voice calls.

By "dropped calls", are you saying that your calls will go through (inbound and outbound), and you'll be able to communicate for a short time before the calls being dropped?

Our ASA rollout ended up working just fine.  We had some struggles at one point, but a few changes to our configuration and we were able to failover properly and block SIP traffic on one of the WAN ports (we have a very specific application), while allowing SIP to work properly on the other WAN port.



JP Rike Tue, 08/02/2011 - 20:25


After your succesful rollout, we are going to roll out the ASA on a customer this week.

The customer with the SA is still using it but we are planning to switch them over to the ASA as well, saying all of this, the sitsuation improved with configs we made on the SA and on the UC. I just have a  gut felling that we might be better on the ASA for now with the UC deployments and wait for a few more maintence releases on the SA. I will just miss the GUI and the ease of use and the easy learning curve for the interns.

The issues we are running into now are echos and static on internal calls and intercoms. Saying this, this is only with the SPA phones (with the newest firmware). All of our phones are SPA phones. The one user (receptionist) with a 7900 series phone has never complained about her phone once and we al know she is on the phone the most.

I had another customer that originally wanted the UC300 with SPA phones but later decided they wanted to upgrade and get the UC500. After that upgrade all of the users wanted bigger screens and have now decided to go with 7900 series phones. That customer could have not been happier with that the decision, and so are the end users. They say that call quality has much improved with the new 7900 series phones.

I just applied the new SWP to a customer tonight. I wonder if that will help any. The new CCA is spot on.

- JP

JP Rike Wed, 08/03/2011 - 13:46


I am going to the ASA tonight if I can't get the UC to NAT. I dropped 4 calls myself today all to different people. The SA is back to doing it's old thing...

I guess while I am doing it, I might as well update the UC to 8.2.0.

- JP


This Discussion