Hi Support Community
We have had reports on one of our CUBE SIP gateways / trunks of voice quality issues. We reported this to our service provider who have advised they have done thorough checks and they cant find any issues and believe the issue is on our side.
We have been investigating and have come across something we are not sure on - when we do a show sip-ua calls on an active call the Media Dest IP Addr:Port highlighted in the below example is actually referencing another voice gateway ( MGCP ) registered on our CUCM cluster. We have checked and cannot see any reference on the CUBE gateway to this address. We also have another CUBE gateway with a similar setup and this also seems to do the same, the Dest IP Addr:Port references another gateway that isnt related to it.
Can anyone explain why we would be seeing this ?
Total SIP call legs:4, User Agent Client:2, User Agent Server:2
SIP UAC CALL INFO
SIP Call ID : 20682A5D-42FB11E4-A8E0FE7C-3AB7F2@172.23.255.99
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Calling Number : xxxxxxxxxxxxxxxxxxx
Called Number : xxxxxxxxxxxxxxxxxx
Bit Flags : 0xC04018 0x100 0x80
CC Call ID : 61122
Source IP Address (Sig ): 172.23.255.99
Destn SIP Req Addr:Port : [172.20.44.104]:5060
Destn SIP Resp Addr:Port: [172.20.44.104]:5060
Destination Name : 172.20.44.104
Number of Media Streams : 1
Number of Active Streams: 1
RTP Fork Object : 0x0
Media Mode : flow-through
Media Stream 1
State of the stream : STREAM_ACTIVE
Stream Call ID : 61122
Stream Type : voice+dtmf (1)
Stream Media Addr Type : 1
Negotiated Codec : g711alaw (160 bytes)
Codec Payload Type : 8
Negotiated Dtmf-relay : rtp-nte
Dtmf-relay Payload Type : 101
QoS ID : -1
Local QoS Strength : BestEffort
Negotiated QoS Strength : BestEffort
Negotiated QoS Direction : None
Local QoS Status : None
Media Source IP Addr:Port: [172.23.255.99]:31544
Media Dest IP Addr:Port : [172.20.255.249]:16762
Thanks, Carl Ratcliffe
Solved! Go to Solution.
I would look to see if you have transcoder or MTP's configured on those devices. The negotiated codec is G711alaw which may be causing issues. Also I would make sure you are not requiring an MTP anywhere in the call flow.
Definitely on the right path here. That other gateway might be doing some transcoding or using some media resources for the call, however, it may not be the reason for the bad quality.
A few more things:
-You can use the web interface of the IP phone having the issue by going to http://x.x.x.x and looking at the call statistics (Stream 1) while on the call. You will be able to find the MOS score, and more importantly dropped/discarded packets. RTP packets have a sequence number so your phone knows when packets are getting dropped, which would result on bad quality.
-Make sure vad is disabled.
Note: I had this issue with 8831 phones and it ended up being a bug on the device, however, call quality issues can be due to a ton of things and you should still narrow it down as much as possible.
Hi both and thanks for your responses.
I have taken a look at both trunks on CUCM and they both have "Media Termination Point Required" ticked. We are using CUCM 8.6.2 by the way. So could this be an issue and the reason for the media destination IP address ? If so what scenarios would you tick and untick this ?
I have also checked the media resources for each trunk and they both do have access to the gateway IP addresses seen in the logs as hardware transcoders, they are both lower priority though in the media resource group list so not sure why it would be using them over other available registered transcoders ?
Thanks, Carl Ratcliffe
You could tell if the gateway is indeed transcoding by using the "show sccp connections" on it. It will show the endpoints it's transcoding for. I honestly do not think this is the root cause of your issue, MTPs are used for several things, it could be that your environment is configured for RSVP.
Regardless, I recommend you place a call and retrieve the statistics through the web interface that way we can see what the phone is seeing and go from there.
Having phone audio travel to a remote router for MTP/transcoding can absolutely be the cause of poor audio if that router is across a WAN. You are basically sending it across that connection twice.
I never require MTP on trunks and have never run across a compelling reason to. Before you turn it off I would reccomend that you fix the codec issue. Find out what the provider supports and make sure your regions are configured properly in CUCM.
If you have the proper resources as a higher ppriority in your MRGL, it may be selecting the wrong one because it needs a resource that can support G711alaw. If you have multiple resources in your MRG, order does not matter. It will round robin through them.
Hi and thanks for the response. I think you are spot on with the fact that the phone is traveling to a remote location and this could be the cause of the poor audio quality. The remote location is actually another country with a 50ms RTT. As i mentioned though this location is a lower priority media resource ( 3rd in the list ) but i will certainly check the higher priority resources can support G711ALAW as we usually use ULAW.
The region is ok as we allow G711 right across our regions as we have the available bandwidth.
Looking further into this our voice class codec config doesnt include g711alaw but i have now noticed we force this on the dial-peer ( see below and confirmed this is defintley being used for the call ) so if the region allows g711 and the sip provider are sending g711alaw why is a media resource being invoked ?
I have also attached the debug ccsip all.
dial-peer voice 201 voip
description ## Primary CUCM ##
session protocol sipv2
session target ipv4:172.21.44.100
no voice-class sip pass-thru content sdp
ip qos dscp cs3 signaling
Hi and thanks for your response. I have placed a test call and checked the remote gateway that is referenced and the local gateway certainly is invoking this for xcode.
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED
0 7 26.3.7 UP 1 USED xcode 1 0x33F9F 1555 1689
0 7 26.3.7 UP 1 USED xcode 1 0x33FA0 1683 1555
Total number of DSPFARM DSP channel(s) 1
I remove Media Termination Point Required and the xcode is no longer invoked, i cannot really test call quality until staff are back in the office after the weekend.
So my question is what scenario would you need to Media Termination Point Required ticked, im assuming this is something to do with when the provider is not sending the codec preference in the early offer SDP ?
The SIP profile of the trunk in question also has ticked Early Offer support for voice and video calls (insert MTP if needed) , should this be ticked or unticked and in what scenario would you use this and are the 2 settings related to each other in terms of functionality ?
Thanks, Carl Ratcliffe
If you have an MTP setup as a trusted relay point, you may want all calls to terminate there. Also using an MTP can sometimes resolve issues with transfers.
As for the early offer setting, it used to be where an MTP was required for every early offer call. That is not the case anymore. An MTP is still needed under certain circumstances if you are interworking with H323. I would make sure that the provider is not requiring early offer before changing that setting. To be safe, I would turn it off to ensure an MTP is never needed.
Hi and thanks for your response. The provider does use early offer and we can see this in the debug messages. Good news is removing the require MTP setting seems to have fixed the voice quality issue.
One last query, when early offer is used does this need to be configured on each leg, so for example if i have a call from CUCM to SIP Provider via the CUBE and the CUCM SIP trunk is configured for early offer do i then need to also configure early offer forced on the inbound and outbound dial peer ( or enable globally ).
Thanks, Carl Ratcliffe
You can have CUBE force early offer or you can just let it pass the capabilities of the provider onto CUCM so that it can be negotiated.
I spoke to a TAC engineer a few weeks ago who told me that forcing early offer through CUBE is not typically used any more.
Thanks Frank , i will take a look at the phone and see if its dropping packets. Im keen to get to the bottom of the media resources though as it very well could be something to do with this or just that the SIP trunks / gateways are not setup correct anyway.
When i debug i can see the SDP sent from the provider as the below :
o=Sonus_UAC 27506 31925 IN IP4 172.22.216.222
s=SIP Media Capabilities
c=IN IP4 172.22.216.196
m=audio 5076 RTP/AVP 18 8 2 100
But the gateway only has the following configured :
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
But it negotiates to G711alaw :
Preferred Codec : g711alaw, bytes :160
Preferred DTMF relay : rtp-nte
Preferred NTE payload : 100
Early Media : No
Delayed Media : No
Bridge Done : No
New Media : No
DSP DNLD Reqd : No
So im assuming something is a miss here ?