Voice Droping in DSL branches - I am Stucking !!!!!!!

Answered Question
Oct 23rd, 2008

Dear all,

We have full cisco unified communication enviroment, and everything is running smooth in the head office, but we have two remotes branches one is 1 Mbps DSL connection and the other is 1 Mbps WiMaX connection, we have one ip phones in the first site and 4 in the second one. We are suffering from voice droping in the calls between the head office and the remote sites and between the remote site with external PSTN.

We dont have any special traffic in our remote sites, they are only around 5 PCs and one IP phone in the firs site and 3 PCs and 4 IP phones in the second site.

Please we are suffering from this problem!! any body can help us??

Thanks & Best Regards,

I have this problem too.
0 votes
Correct Answer by l.mourits about 7 years 11 months ago

Hi, Sorry, I've been busy. ACL looks fine. That leaves the configuration of network regions and locations. How did you configure these? What codec is used? What bandwidth do you allow?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
sebastiandm Thu, 10/23/2008 - 02:58


How does your call routing work ? Are your calls coming on the remote sites locally and breaking out across the WAN or going back out locally. What type of pstn circuit do you have FXO/E1/T1...

eemara949 Fri, 10/24/2008 - 02:09

Hi my dear,

I dont think that the calls breaking out across the WAN because the ping is working fine from the HQ and remote site across the WAN.

We have E1 PSTN ciruit.

Appreciate your support

l.mourits Fri, 10/24/2008 - 03:59

Let's see if I understand your environment first (as I'm sure others will wonder as well).

So you have a CCM cluster in the head office, and two branch offices connected via DSL to the head office. Then the phones in the branch office register to the CCM cluster and transport voice signaling and voice bearer traffic over the wan (bearer traffic for both internal as external calls, since you do not have PSTN on the branch office, in other words, if they dial out they leave out the PSTN in the head office). Correct?

Couple if questions:

How did you implement the VPNs between the offices? I would expect DMVPN like solution. If so, did you ensure the MTU sizings are correct?

What codec are you using between the region locations? Recommended is G729a for WAN links.

How did you configure your QoS on the WAN links (i.g. what queing method are you using, how do you gaurantee bandwidth, et cetera)?

If you happen to have no answer to any of the above questions, I think you need to start reading up about voice over encrypted WAN links, and voice engineering in general.



robertdm1973 Fri, 10/24/2008 - 12:36


I have a similar problem where calls dropped on WAN link. Using the CCAPI debug, here's what showing on the log. What does cause code=38 stands for?

*Oct 24 18:15:32.472: //175/C8E86EA280B0/CCAPI/cc_api_call_disconnect_done:

Disposition=0, Interface=0x653EB79C, Tag=0x0, Call Id=175,

Call Entry(Disconnect Cause=38, Voice Class Cause Code=0, Retry Count=0)

CHRIS CHARLEBOIS Fri, 10/24/2008 - 12:57

Cause 38, I beleive, is a generic bad connection failure. Unfortunately, not very descriptive but it basically means that there was too much delay/jitter/lost packets/etc.

l.mourits Sat, 10/25/2008 - 06:30

Similar to the other issue of the topic starter, the same questions arive if you see a generic code about bad network connectivity:

How are your WAN links provisioned (MPLS network, DMVPN over DSL, leased lines?????)

How did you implement QoS. How are you marking traffic? How do you handle bandwidh admission control? What did you do to ensure bandwidth guarantees?

If you don't know the answer to this, you probably should be better of not routing calls over the wan.

(ps. excuse me being cinical here, but I have seen too many people trying to implement voice over IP without QoS, and it always fails sooner or later)

robertdm1973 Sun, 10/26/2008 - 13:47

If the WAN link do not support QOS, what's the best work-around to eliminate dropped calls?

Ours is an L2L VPN over a public Internet, both with big pipes (DS3).


l.mourits Wed, 11/05/2008 - 14:41

If your wan link does not supporting QoS you should not even consider routing voice over it, is the one and only correct answer to this question.

But, if you have a DS3 your routing platform is probably a 3800 series or similar and you should be able to at least configure the correct priority queues. You could limit the bandwidth per class. If that is not an option, your second best is probably to implement car on your router (committed access rate).



eemara949 Sat, 10/25/2008 - 23:31

Dear Leo,

Correct as you said, we have the same enviroment.

we did NOT implement VPNs between the offices.

QoS already configured as following:"

class-map match-any VOIP

match access-group name MOA



policy-map QOS

class VOIP

priority percent 60

set ip precedence 5

class class-default



kindly advice

l.mourits Sun, 10/26/2008 - 00:57


K, setting priority and precedence is one thing, bandwidth admission control is the second item.

If I had to do such install, I would limit the class to a specific amount of bandwidth (number of simultaneous calls * 30kbps), and use region/location configs in CCM to select the correct codec and control bandwidth.



l.mourits Sun, 10/26/2008 - 09:02

ps. can you post your access-list (MOA) as it may contain clues about your problem?



eemara949 Sun, 10/26/2008 - 14:38

this is my access list MOA

Extended IP access list MOA

10 permit tcp any any eq 1720

20 permit udp any any eq 5060

30 permit udp any any eq 2427

40 permit tcp any any eq 2428

50 permit tcp any any eq 2000 2002 (168311 matches)

60 permit tcp any any eq 5060

Correct Answer
l.mourits Tue, 11/04/2008 - 02:01

Hi, Sorry, I've been busy. ACL looks fine. That leaves the configuration of network regions and locations. How did you configure these? What codec is used? What bandwidth do you allow?

eemara949 Tue, 11/04/2008 - 02:04

The codec for the Loacl sites is G.711 and for remote is G.729 and BW is default.

l.mourits Wed, 11/05/2008 - 14:33

Couple of things to check/consider:

First, ensure you actually associated the policy to the interface(s).

Next, check to see if it may be related to an ip cef bug by disabling ip cef oif it is enabled on your router (you would not be the first to run into ip cef bugs).

Then, limit the bandwidth in the region setup to max. 4 calls (since you only have 4 phones on the branch location there is really no need to put it to unlimited (the default)).

Why would you put your priority percentage to 60%on a 1Mbps call if you have max. 4 calls? If you are using G.729a your real need is appr. 108kbps and not 600kbps.

This is based on 20ms samples (50 pps) for G729 + 7 bytes L2 overhead for your wan link per packet. If you use VPN you may need to increase. Check you bandwidth calculation.

Ensure you are actually running G.729a over the WAN (packet trace/snif) and not G.711

Last but ot least, I am kinda puzzled with how you connection actually looks like. You stated in your original post it is DSL but you're not doing any VPN. Does this mean you have some sort of private IP line running over DSL? I can not imagine someone sending VoIP traffic directly over the Internet without encrypting.

And one hing I have to say: Keep in mind that the forum is not an official support channel. It is best effort, people willing to help out. So posting multiple replies as a reminder is not a good practice. If your issue is that urgent you may just open up a case with Cisco TAC or your partner/reseller and they will assyst you if you have a contract with them.



Marwan ALshawi Wed, 11/05/2008 - 14:08

Hi there

in your ACL for LLQ i can not see any RTP in the ACL

which is the main palyer to give priority to voice traffic

u need a line in ur ACL looks like the following :

permit udp any any range 16384 32767

this way u will include RTP traffic

or if are using NBAR u could use an other method like

make ur calss map like

class-map match-any voice

match access-group [uracl name]

match protocol rtp

good luck

if helpful Rate


This Discussion