CUCM / CUBE - Codec change when call is transferred

TONY SMITH · ‎09-06-2019

Hi,

This installation is CUCM 11.5 with SIP trunk to CUBE then to ITSP. CUCM->CUBE is delayed offer, everything else is EO. CUBE has a transcoder registered with CUCM and included in MRGL of both trunk and phone. In general this doesn't get used as the codecs are matched end to end.

The issue I'm looking at just now is calls which fail when they're transferred, and it appears to be caused by an anomaly in codec selection. The sequence goes as follows ..

(1) Incoming Invite/SDP offers G711a (and a number of other codecs)
(2) CUBE passes this onto CUCM with same codec choice
(3) CUCM sends OK/SDP connects specifying G711a. 
Call put on hold as part of transfer process ..
(4) CUCM send re-invite with a=inactive, CUBE responds with Trying, OK etc
Call transfer committed, original caller connected to new end point ..
(5) CUCM sends new re-invite, Delayed Offer
(6) CUBE sends OK/SDP, offers all codecs defined on the dial peer, not just those in the original call
(7) CUCM sends ACK/SDP specifying G711u and also a=sendonly

Clearly a (7) there's now a codec mismatch between the ITSP/CUBE leg using G711a and CUBE/CUCM using G711u. What I'd like to understand is what's happening at (6). When the call first connected the CUBE only offered the codecs listed by the ITSP initial invite. Any comments welcome. Meanwhile I've worked around the issue by removing G711u from the codec class. Not ideal because this ITSP offers G711u and G722 for calls that originate on the same platform.

Rajan · ‎09-09-2019

Hi Tony,

"a=sendonly" usually will be sent for MOH during transfer and since you have the same codec specified throughout the call path, I think this is negotiated for the call leg involving MOH device and not for the actual call. you can check these configuration.

HTH
Rajan
Pls rate all useful posts by clicking the star below

TONY SMITH · ‎09-09-2019

That's correct, with the workaround in place the "a=sendonly" applies only to the MOH stage, replaced by two-way in the final Invite when the transferred call connects.

I'm coming round to thinking that this is buggy behaviour on the part of the CUBE. Another reason for thinking this is that when I changed the CUCM facing dial peer to use the same named "voice-class codec" as the ITSP facing DP, in that configuration the CUBE started to passthrough the mid-call signalling instead of handling it locally.