One-Way Audio Issue

[tim.moomaw]

Hello All,

We are running UCCX 7.1 (SR5), UCM 7.1.5.34085-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.

[acampbell]

Hi,

One way transmission with VOIP is almost always caused by an IP routing issue.

Your gateway must be able to have full both way IP connectivity with every end point that it

is supposed to be able to RTP with. Like all the ip phones, IP-Comm , unity , CUCM etc

Can you make sure that you have bound a single interface for your VOIP protocol.

Eg

H323

!

int fas 0/0

ip address 10.10.10.10 255.255.255.0

h323-gateway voip bind srcaddr 10.10.10.10

!

SIP

!

voice service voip

sip

bind all source-interface fa0/0

!

MGCP

!

mgcp bind control source-interface FastEthernet 0/0

mgcp bind media source-interface FastEthernet 0/0

!

There is a possiblity that is is your IP Comm software is hitting a bug

HTH

Alex

Please rate useful posts

[woody1848]

Tim,

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!

Thanks,

Woody

[tim.moomaw]

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.... :( 

[woody1848]

Our port that is connected to our SIP provider is outward facing and does not have a firewall in between.  Our next step is a packet capture.  Thank you for the quick response, I appreciate it!

Thanks,

Woody

P.S. When we find the cause and solution to this issue I will be sure to document it here for future generations.  :)

[Ben Haverstock]

Woody, did you ever determine the cause?  We are having the same issue.  but it's only on 2-3 calls a day and only on calls through UCCX. It has been nearly impossible to diagnose.

Thanks!

[woody1848]

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.

Midcall-signaling

Conf t

Voice serv voip

Sip

midcall-signaling passthru media-change 

Explanation

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).

Good article - http://canadianitprofessionals.com/sip-call-hold-transfer-conference-failure/

Cisco docs - http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_proto/configuration/15-2mt/cube-midcall-reinvite.html

SIP Profiles

Conf t

Voice calls sip-profiles 1

request ANY sip-header Allow-Header modify ", UPDATE" ""

response ANY sip-header Allow-Header modify ", UPDATE" ""

This command removes the 'UPDATE' value from the 'Request' SIP header.

More info on SIP Profiles if you wanted - http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/105624-cube-sip-normalization.html

Rel1xx

Voice serv voip

Sip

rel1xx supported 100rel

Informative article - http://www.ucguerrilla.com/2014/02/dealing-with-provisional-response-and.html

MTP

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

dtmf-relay rtp-nte

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!

Thanks,

Woody

[Ben Haverstock]

Thanks Woody,

I am in the middle of a TAC case with this right now and I will verify our CUBE config based on your info and run that by TAC as well.

Today, we are setting up traces for UCM and the CUBE gw.  If we come across anything interesting, I will post it for you.

Thanks!

Ben