cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1639
Views
5
Helpful
8
Replies

Intercluster SIP Trunk - Which side invokes transcoding?

j.a.m.e.s
Level 3
Level 3

All,

I have read that the device requiring the higher codec is responsible for invoking the transcoder. Is this also true for intercluster SIP trunks (with "MTP required" unchecked)?

 

I have the following scenario:

 

G711a_Only -> SIP Trunk -> CM_Cluster_A -> SIP Trunk -> CM_Cluster_B -> Phone_in_G729_region

 

The region settings on the SIP Trunk configured on CM A and CM B allow up to G711, but the phone attached to cluster B is in a region that only permits G729. I believe it is the responsibility of the leftmost SIP Trunk (nearest the G711a device) to invoke a transcoder, but I would appreciate some guidance on this.

 

Many thanks

 

James.

 

1 Accepted Solution

Accepted Solutions

I don't think there's any media resource negotiation between the two clusters, so in a sense you have to treat them as two separate systems.  Do all your calls over the ICT use G.729?

LTI transcoding on the CUBE will be separate still, not visible to CUCM and wholly dependent on whether the CUBE sees mismatched call legs.  So for example it will only be invoked if the ITSP->CUBE leg and CUBE->CUCM use different codecs.

View solution in original post

8 Replies 8

jferris1979
Level 1
Level 1

I think it depends on what device is calling.  I found the following:

 

The following list gives intercluster MTP/transcoding details:

  • Outbound intercluster calls will use an MTP/transcoding resource from the Cisco Unified Communications Manager from which the call originates.

  • Inbound intercluster call will use the MTP/resource from the Cisco Unified Communications Manager that terminates the inbound intercluster trunk.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmsys/CUCM_BK_C5565591_00_cucm-system-guide-91/CUCM_BK_C5565591_00_cucm-system-guide-91_chapter_011101.html#CUCM_RF_I2EF6DD8_00

 

Also I believe that in your situation with one site set to 729 only, a transcoder should not be required.  If a device supports 711 it automatically supports the lower codec also so the 711 phone should negotiate down to 729 once it sees 729 is the only codec offered in the SDP.  

Thank you for replying and apologies it has taken so long to respond.

 

I'm not sure the system guide provides an answer here - "Outbound intercluster calls" and "Inbound intercluster calls" is confusing terminology - but I think it is referring to CM nodes within a cluster rather than "which cluster is responsible for invoking the Transcoder?"

 

I should have pointed out in my description that the source of the call in my scenario is an ITSP which only supports G711alaw and is connected to a CUBE. So the call flow which fails is:

 

G711a_Only_ITSP -> CUBE -> SIP Trunk -> CM_Cluster_A -> SIP Trunk -> CM_Cluster_B -> Phone_in_G729_region

I have added universal transcoders to the CUBE and both the trunks on CM_Cluster_A (using SCCP mode for the trunks and LTI mode for the CUBE). The call still fails, so I'm going to collect traces and raise a TAC case.

 

Incidentally, the call in the reverse direction (i.e. initiated by the Phone_in_G729_region) succeeds and invoked LTI transcoding on the CUBE.

 

It would be useful to know how this is meant to work.

I don't think there's any media resource negotiation between the two clusters, so in a sense you have to treat them as two separate systems.  Do all your calls over the ICT use G.729?

LTI transcoding on the CUBE will be separate still, not visible to CUCM and wholly dependent on whether the CUBE sees mismatched call legs.  So for example it will only be invoked if the ITSP->CUBE leg and CUBE->CUCM use different codecs.

It all sounds a bit less sophisticated than I had hoped.

 

After adding in the LTI and SCCP transcoders on the source cluster/CUBE (i.e. the G711alaw  side), what I can see is the INVITE arrives from the ITSP with G711 EO. At the remote cluster, the call is sent to a G729 region (we only use G729 for certain regions attached to the remote cluster). The remote phone has access to universal transcoders, but the ICT does not. 

 

What I see on the far end cluster is:

 

49456491.005 |18:36:51.036 |AppInfo |!!ERROR!! -MediaManager-(1983415)::disconnOnResourceAllocationFailure, ERROR disconnOnResourceAllocationFailure - fails to allocate MTP/XCoder,connCount=2
[...] SIP/2.0 503 Service Unavailable [...] Reason: Q.850;cause=47

It's a shame that the CUBE or source Call Manager can't use the Q.850 response to try invoking a transcoder, but maybe this is just too late in the flow as the INVITE was EO? Would DO help with this scenario?

 

I guess what we can learn from the above is that the cluster which is unable to accommodate the EO INVITE is the cluster which must invoke the transcoder.

Looking at what's happening at the far end cluster I guess (you haven't said) but I guess the call is offered over the ICT as G711.  So the ICT at the far end gets an incoming Invite offering only G711, but the call routes to a region that should be G729.  In that case it is the ICT that will look for the transcoder - so should have an MRGL that includes at least one.

Using delayed offer on the ICT might help, depending on how the other call legs are configured.  And we're assuming your Region settings are consistent.

Hi Tony,

Yes, the source cluster is sending an EO SDP with only G711alaw:

! Received on far-end cluster, which has a receiving phone in a G729-only region:INVITE sip:8123456789@10.x.x.x:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.0.1:5060;branch=z9hG4bK724e8242fbbbc8e
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=227842455~84f841dc-5fc9-4273-84f6-8a3176aa3df0-39999405
To: <sip:8123456789@10.x.x.x>
Date: Tue, 03 Sep 2019 17:36:47 GMT
Call-ID: 66022700-d6e1a4af-6ebf55e-24427117@x.x.x.x
[...]
Content-Type: application/sdp
Content-Length: 241
v=0
o=CiscoSystemsCCM-SIP 227842455 1 IN IP4 x.x.x.x
s=SIP Call
c=IN IP4 10.27.136.226
b=TIAS:64000
b=AS:64
t=0 0
m=audio 24940 RTP/AVP 8 101
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Out of interest, how does Call Manager know to invoke the transcoder on the ICT rather attempting to use the MRGL on the g729 phone? This is the smart choice because the phone's transcoder is in a remote branch (across a BW constrained WAN link), but I'd be interested to understand the logic.

 

Also, is there any way to ask CUBE to convert EO-to-DO? I can see there is a DO-to-EO option, but not the reverse.

 

Regards

 

James.

 


Out of interest, how does Call Manager know to invoke the transcoder on the ICT rather attempting to use the MRGL on the g729 phone? This is the smart choice because the phone's transcoder is in a remote branch (across a BW constrained WAN link), but I'd be interested to understand the logic.

My understanding is that the MRGL of the higher bandwidth end is searched first.  That make logical sense as you'd expect a device's MRGL to list resources near or easily accessible, so this would minimise the distance that the high bandwidth stream covers.  It wouldn't make any sense sending it as G711 all the way to the remote site, then transcoding after it's crossed the low bandwidth link.

I haven't found a way to make the CUBE convert EO to DO, it may exist but when I was looking for that option I ended up using a different solution.  In the installations I've worked on DO is normally used because CUCM only allows a single codec in Early Offer (unless that's something else I've missed!).  That limit doesn't exist with the CUBE so it can put out EO with all possible codec's listed.

I think, but without trying it, that DO on your ICT will be the best solution if you want to avoid transcoding or MTPs.  That way codecs will be negotiated end-to-end and if the far end phone wants G729 then that's what it will be all the way.  If your ITSP call didn't offer G729 then LTI will deal with that.

By the way, I don't think EO is limited to a single voice codec unless "MTP required" is checked on the trunk (SRND note for v11).

 

Anyway, this certainly helped explain that the far end cluster had to locate the transcoder due to EO,  the search logic for a transcoder within a cluster and an alternative strategy using DO, so thank you for your help.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: