We are running UCCX 7.1 (SR5), UCM 18.104.22.168085-1, 4 Voice Gateways 12.4(19b) .
We have been experiencing some calls into our call center that when answered by our CSR's there is one way audio. This happens only on a handful of the calls but has happened enough to raise the attention of the supervisors in the call center.
Our CSR's mainly use IP Communicators 7.06 and it appears to only affect those users within our Call center as other users throughout the company have not complained about one way voice issues. For the most part everyone else also uses hard-phones.
We also have another business unit that has a seperate call center and their calls terminate on seperate Voice Gateways and they have not complained about one-way voice issues.
I have a few questions:
Could UCCX be playing a role in the one-way audio since it seems to be only occuring in our Call Center? From the responses I have received from TAC they are stating that this is not a UCCX issue and most likely a voice gateway issue. The group here that handles Call Manager and the voice gateway's are suspicious of TAC's statement that this is never UCCX causing one-way voice issues. The customer from what we can deduce can navigate the options in the script just fine it is only when they are connected to a rep that they experience one way audio.
Are softphones (IP Communicator) more susceptible to network issues than hardphones since it is only affecting softphones from what we can tell?
We have redistributed our PRI's so that the calls which were coming in mainly on Voice Gateway 1 are no terminating to Voice Gateway 4 and the issue is still there. What is the best course of action to help determine what is causing the one-way voice on these calls? Any guidance would be appreciated on how to troubleshoot this issue.
Did you ever find a solution to this problem that you were having in your call center? We seem to be having the EXACT same issue. We only get one-way audio on about 2-6 calls out of 1000+ calls a day. If you have any suggestions I would be very grateful!
We've since moved on to another ACD / IVR platform (with its own set of issues) - that was over 3 years ago but believe this particular one-way audio issue was firewall related. Your best bet unfortunately is going to try to get a packet capture when it happens.... :(
We have not as of yet. I have been working with Cisco TAC for some time now (3 months) We have tried many different things I will list some of the things that we have tried in hopes that one of these might be a solution for you. Next I am going to do a packet capture straight from our CUBE router and send those logs into TAC for them to look at. Before this I have been running a syslog server and recording the debug out puts from these commands
Debug voip ccapi inout
Debug ccsip mess
debug voip rtp session named-event
and then sending those outputs to the TAC agent.
Here are some of the things that we have tried so far.
Voice serv voip
midcall-signaling passthru media-change
Whenever you make a call through a CUBE you would have 2 legs, one external and one internal.
With the midcall-signal passthrough media-change command, the CUBE will be able to reply to any message sent by either the internal or the external leg, but it won’t relay those messages to the other leg, this means the following:
If the external leg sends a reinvite, the CUBE will reply to the messages as per the RFC but will not pass it to the internal leg, unless the media was changed.
If the internal leg sends a reinvite, the CUBE will reply to the messages as per the RFC but will not pass it to the external leg, unless the media was changed.
With the midcall signal block command, the CUBE will respond to any message sent by the external or the internal leg as per the RFC, but will not pass it even if the media changed (for this command to work properly you need to configure a transcoder LTI).\
Having said that, you could run one command (if you configure the block after configuring the passthrough, the passthrough will be removed).
The TAC agent while looking at the debugs saw that for all the no audio calls the "...media IP being used by the CUCM belongs to the CUBE, which means that the CUCM is invoking a MTP."
We had MTP invoked on our SIP trunk for all calls, so I unchecked the 'Media Termination Point Required' box and ran some test to make sure nothing was broken.
He also saw on our CUBE config that "...dial peer 200 is configured has a voice class configured to force RTP-NTE, however, the DTMF relay method is KPML."
so it looked like this
dial-peer voice 200 voip description ** UCM02 SIP PEER ** session protocol sipv2 session target ipv4:10.2.21.11 destination e164-pattern-map 200 incoming called-number 9T voice-class codec 1 voice-class sip asymmetric payload full voice-class sip dtmf-relay force rtp-nte voice-class sip early-offer forced voice-class sip bind control source-interface GigabitEthernet0/0 voice-class sip bind media source-interface GigabitEthernet0/0 dtmf-relay sip-kpml fax-relay ecm disable fax rate 14400 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none ip qos dscp cs3 signaling no vad
He had me run these commands to change the dtmf-relay.
dial-peer voice 200 voip
no dtmf-relay sip-kpml
I did some test calls to make sure DTMF was still working and then monitored the GW.
Unfortunately none of these things have worked for us thus far, but it did clean up our SIP responses to our ITSP. But some of these have worked for others in the past, so I hope this information will be helpful to you in some way. As soon as we find a solution for this problem that works for us, I will be sure to update my post asap. Good luck!
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...