One remote location calling into our help desk is reporting many instances of one way audio when an agent retrieves the call. The remote location is on some traditional PBX and not part of the CallManager domain, so they come in thru on PRIs to a 3875 running 12.3(11)T.
What debugs should be enabled to capture this behavior? I don't have any debug level traces enabled, so there isn't anything of value to look thru.
some good ones are 'debug voip rtp' and 'debug cch323 rtp'. ('debug voip rtcp' has some helpful info as well . it does show lost packets for the current call, last call and total lost)
also, you can 'debug isdn q931' to get layer3 info on the PRI, tx/rx commands, etc.
if all else fails, a 'debug ip packet' to view all inbound & outbound packets to see all packets. (will be CPU intensive depending on the amount of traffic the router handles so maybe off-hours is best)
see this link for more one way voice troubleshooting:
well, you have a one way audio problem. one way audio is the result of some specific functionality, or lack thereof, and should be troubleshoot...ed as described in the 'troubleshooting oneWay audio' guide.
once your ipcc script and crs ivr do their job and the call is connected between the caller and the agent, the rtp stream is between only those two endpoints. (usually an ipPhone to ipPhone or ipPhone to gateway)
it is this stream that either fails to send or fails to be received that induces oneWay audio.
do the debugs provided not show you the rtp stream, direction and sourceIP? use this for starters as well as the others if needed, as well as following the steps outlined and you should be able to track down your problem.
also, don't forget to verify the network is not dropping the packets if that could be the case. say you had multiple paths and your send is not the same as the return path and there's an acl blocking one of the paths...just thinking out loud here...
now, if this is "oneWay audio" due to the ivr not being able to play/send the message, then this could be a CRS issue and troubleshooting is required and can be started with the link below:
Due to the high volume of calls into the gateway that services the CRS server, and the intermittent nature of the behavior - I have been unable to gather any router debugs. With that said, I don't believe the problem is with the router because the only reports of this behavior are from callers traversing thru the gateway to the CRS queues. The thousand some odd calls per day thru the gateway have not revealed any one way audio issues except for those destined for the CRS queues. It is always the agent who cannot be heard by the PSTN caller. The call is terminated by the agent, which prompts the originator of the call to make another call that is successful.
Although the router hasn't been eliminated from the trouble, it isn't the most readily available element to retrieve data. There must be some debugs aboard CRS that will point me in an appropriate direction.
I have hundreds of remote offices with traditional PBX's (this one is a Definity Prologic) and is the only site reporting this behavior.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...