SIP Trunk with CUBE and MTP for Transfers

[glenn.martindell]

Hello All,

I've setup a few SIP trunks with CUBE over the past few years and am a little confused on the transfer issues.   Whenever I have had issues with blind or consulted transfer, I always check MTP required on the SIP trunk and that has always corrected my issue.   There are more than a few posts that suggest this is a viable solution and I have always thought this was the correct fix for transfer issues.   I have been told recently by several TAC engineers that this is not the correct fix on a SIP trunk and this really is only putting a band-aid on the issue.   I know MTPs are typically required for DTMF mismatches, but I've always thought of them as a type of media demarcation point that more easily allow media redirection (such as with hold and transfer) and supplementary services for H323.   Assuming what TAC has told me is correct, what causes transfer issues on SIP trunks (or CUBE), what is the correct fix and why does requiring an MTP typically appear to resolve the problem?

Thanks in advance,

Glenn

[Jonathan Schulenberg]

I owe whichever TAC engineer told you that a beer! They are absolutely correct: MTP is almost always bad design. MTPs also introduce their own issues / bugs, make troubleshooting more difficult, and do not scale well.

MTP covers up the problem because CUBE doesn’t see mid-call state changes (eg no reINVITE for hold/resume, transfer/conference, etc). As far as CUBE is concerned media capabilities never change for the duration of the call.

Call transfer on CUBE isn’t normally a problem. SIP would never have won out over H.323 if it couldn’t perform such a basic call function well. A debug ccsip message trace will tell you a lot about what went wrong and who perceived there to be a problem. One of the many advantages of SIP is that it was modeled after HTTP, including plain-text readability unlike H.323 hex decode.

If I were to take a shot-in-the-dark: is the DN involved in the transfer configured for call recording? If yes, what model phones, firmware level, and codec is negotiated on the phone for each leg of the transfer? This can cause issues if the negotiated codec is not supported by the recording server. Using an MTP could mask this issue by lacking support for the wideband codec in the first place.

As for DTMF, CUBE will interwork from RFC2833 to SIP KPML for the devices that only support OOB without needing an MTP. All you need to do is offer both capabilities on the dial-peers between CUCM and CUBE: dtmf-relay rtp-nte sip-kpml.

[glenn.martindell]

Hi Jonathan, thanks for the response.

All of that makes sense, I guess I'm a little confused as to why transfers (particularily consulted transfers) tend to be so problematic with SIP and CUBE and why most people (myself included) think that adding MTP is an acceptable solution.  Perhaps left over from H323 days?   Is there a common setting most of us are missing in our SIP configs that that cause issues with transfer?

Thanks,

Glenn

[Jonathan Schulenberg]

I can only speculate to the first question: people are short on time and MTPs alleviate the pain. Figuring out why, and whether that was the best solution, would require more effort.

SIP transfers just has not been an issue I see, certainly not often. I'm not disputing your experience, only that I have no silver bullet answer to it. If you can reproduce the problem and get a debug output I could take a look though.