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,
Solved! Go to Solution.
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...
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
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.
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)
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.
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)
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).
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).
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
priority percent 60
set ip precedence 5
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.
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
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.
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
if helpful Rate