CUBE SIP Gateway - Media Dest IP Addr:Port

[Carl Ratcliffe]

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
Call 1
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

[Jeremy Guillory]

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.

[Francisco Granados]

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.

Thanks,

Frank

[Carl Ratcliffe]

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

[Francisco Granados]

Hi Carl,

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.

Thanks,

Frank

[Jeremy Guillory]

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.

[Carl Ratcliffe]

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.

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:8 PCMA/8000

a=rtpmap:2 G726-32/8000

dial-peer voice 201 voip
 description ## Primary CUCM ##
 destination-pattern 307....
 session protocol sipv2
 session target ipv4:172.21.44.100
 no voice-class sip pass-thru content sdp
 dtmf-relay rtp-nte
 codec g711alaw
 ip qos dscp cs3 signaling
 no vad

Thanks, Carl

[Jeremy Guillory · Accepted solution]

It is because MTP Required is selected on the trunk.

It also may be invoking a transcoder though. 

[Carl Ratcliffe]

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

[Jeremy Guillory]

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.

[Carl Ratcliffe]

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

[Jeremy Guillory]

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.   

[Carl Ratcliffe]

When you say pass it onto cucm to negotiate do you mean using the below command so sdp is passed on untouched ? pass-thru content sdp Thanks, Carl Ratcliffe

[Jeremy Guillory]

No, the default configuration should allow CUCM to receive early offer messages from the provider.

[Carl Ratcliffe]

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

t=0 0

m=audio 5076 RTP/AVP 18 8 2 100

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:8 PCMA/8000

a=rtpmap:2 G726-32/8000

a=rtpmap:100 telephone-event/8000

a=fmtp:100 0-15

a=sendrecv

a=ptime:20

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 ?

Thanks, Carl