CUCM/CUBE - Codec Mismatch when transfer to MOH

TONY SMITH · ‎01-15-2020

Hi,

This is an issue I came across on an existing configuration. The end user said it had only recently started happening, I can't see why that would be unless the ITSP had changed. The fault sequence that I found was ..

(1) Incoming calls offers G711a or G729 codecs (m=audio 12222 RTP/AVP 8 18 101)

(2) Call offered to CUCM with same codecs, connects as G711a

(3) When call is put on hold CUCM first sends a Re-Invite with G711a and a=inactive

(4) Quickly followed by another Re-Invite from CUCM, this time it's Delayed Offer

(5) CUBE sends OK offering G711u, G711a and G729. (m=audio 13238 RTP/AVP 0 8 18 101)

(6) CUCM chooses G711u

(7) CUBE drops the call

In the meantime I've worked around the issue by removing G711u from the codec lists on the dial peers, as I see no indication that the ITSP ever wants or offers it. Now the MOH connects correctly with G711a at the CUBE and a transcoder inserted.

However I am concerned that the issue would reappear if a call ever connects as G729. It seems the CUBE is going to offer all configured codecs at step (5) above, rather than just the codec actually in use.

Doing some tests on my system it appears that setting codec transparent on the CUCM facing dial peer may be the solution. With that configured and using the same sequence the CUBE offers only G711a the codec in use, when it transfers to MOH in step (5). I've further checked by forcing the CUBE/CUCM leg to G729 and in that case the CUBE again offers the codec in use, G729 in step (5).

Downside of transparent is that outgoing calls offer all of CUCM's codecs out to the ITSP. Is that likely to cause a problem? Or is there a better way to resolve the underlying issue (other than forcing MTP for everything)? Ideally I'd want to combine "transparent" with some sort of filter, but that doesn't seem to be a possibility.

Thanks, Tony S

Elliot Dierksen · ‎01-16-2020

If the problem is specific to MoH, the problem may be that the IP voice streaming media service is sending the audio as "sendonly". I have had to do SIP profiles in CUBE to change that to "sendrecv" when the INVITE goes to the ITSP. You might be able to filter codecs with a SIP profile in CUBE, I haven't done that before.

TONY SMITH · ‎01-17-2020

@Elliot Dierksen wrote:
If the problem is specific to MoH, the problem may be that the IP voice streaming media service is sending the audio as "sendonly".

The MOH connection is indeed sendonly, but I can't see how that could be influencing anything. The re-invite is delayed offer, meaning that the CUBE has already offered the wrong codec in it's OK before the ACK from CUCM specifies sendonly. Even with a profile re-writing that header it would be too late to avoid the codec mismatch.

You might be able to filter codecs with a SIP profile in CUBE, I haven't done that before.

Are you referring to my concern about codec transparent meaning the CUBE offers all the many CUCM codecs to the ITSP, not just the two that the ITSP supports? If so then I guess that might be possible, I could have a play around with profiles. I would have a slight worry that might mean the CUBE "thinks" it's offering some particular codec and doesn't realise that I've stripped that particular one back out.

Elliot Dierksen · ‎01-17-2020

If the CUBE is involved in the codec negotiation, you can specify to preserve codecs in mid-call signaling (either globally or at the dial peer level). I have seen ITSP's drop a call when the codecs match, but the CUBE specifies "sendonly".

If the CUBE isn't involved in the codec selection, it isn't keeping track. I am guessing that SIP profiles could modify the SDP even if the codec is transparent, but I don't know that for sure.

TONY SMITH · ‎01-17-2020

@Elliot Dierksen wrote:
If the CUBE is involved in the codec negotiation, you can specify to preserve codecs in mid-call signaling (either globally or at the dial peer level). I have seen ITSP's drop a call when the codecs match, but the CUBE specifies "sendonly".

Could I ask you to remind me of the configuration option to preserve codecs?

In my installations we don't pass through mid-call signalling from CUCM->ITSP. The initial hold (a=inactive) and the transfer to MOH (a=sendonly) are signalled only between CUCM and CUBE. So in this case the ITSP does not receive that a=sendonly header.

I did have a try passing through, but this particular ITSP dropped the call if the passed through SDP tried to change codec.

The problem really is the CUBE offering anything other than the established codec during these transactions.