Whats the ideal way to prevent SIP Re-invite options when CUC transfers calls

[sam saeed]

ITSP SIP->SIP TRUNK>CUBE>SIP TRUNK>CUCM>SCCP TRUNK>CUC AA

I have been having a one-way audio issue when the originating call is from an outbound caller intiates a transfer through the Auto Attendant. I took a look at the debug ccsip messages and see that the CUCM is sending a re-invite to the SIP provider once CUC transfers the call back to CUCM. Which ends up as the CUCM sending an inactive sdp status back to the provider and the providre replying with an OK still in an inactive state. I know that this call flow is not correct as the call transfers should not need to be handled with the provider.

I did some reading and I found by configuring MTP on the IOS CUBE it should consume the re-invite.

I also found an article that mentioned using this method when using a 3rd party SIP PBX passing through CUBE which used these commands:

sip
        midcall-signaling block
        <blocks all midcall media from passing through>
        or
        midcall-signaling passthru media-change
         <if any dsp transcoding is done then a dsp may be used only sends video or fax media>

 no supplementary-service sip refer
supplementary-service media-renegotiate

Which from my understanding can be used to consume and/or block the re-invite from the CUCM. This is my first deployment with a CUCM platform so I am not 100% sure which is the best way to take to address the re-invite issue. I know I had a similar issue with CME when AA in CUE transfers. This issue was resolved with the command:

no supplementary-service sip refer

Is this a common problem with CUBE,CUCM,SIP trunk deployments? Which method is traditionally used for CUCM, CUBE, Sip trunk deployments?

Thanks

[Ayodeji Okanlawon]

Ahah I like the sound of holy grail!! :)

Dont forget to give it some stars!!

[Yorick Petey]

Hi Ayodeji,

I read carefully all your troubleshooting and explanations, and I agree with Sam, I'm not confident with the midcall consumption as Cisco clearly states that it should be used only as last resort.

For example, the RTP-SRTP supplementary services are noted as "not supported" when the passthrough media change is applied: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-midcall-reinvite.html#GUID-46736E71-CA26-4A1C-B927-4FCD80D82851

I've not tested yet, but if you enable TLS/SRTP with your ITSP, and use RTP internally, it could cause issues. Have you already configured this kind of setup?

On the other hand, the solution of Sam to combien sip-profile change in CUBE and enabling the "send sendrecv" in CUCM could trigger other issues as well, as it could insert a MTP on the CUCM side, which is never a good thing (T.38?). Sam, have you experienced issues with your setup?

Too bad that we have to play so much with parameters when SIP was planned to be the new "standard".

Great post btw, excellent pieces of information here, thanks a lot guys!

[R0g22]

1. You are correct for the fact that passthrough media change is not supported with RTP-SRTP supp services. With these scenario, yes you will have issues.
SRTP-RTP interop is usually done using a transcoder on a ISR-G2 and natively withouth any transcoders on ISR-4k. These are inserted dynamically and/or deleted, modified as and when needed.

2. For faxes, MTP might cause issues. If a MTP has to allocate and there is no way around it, you need to enable "codec passthrough". For cucm software MTP, there was a new "pass through" parameter added starting 9.1 I believe. You can check that under service parameters >> IPVMA. That value is set to True by default so you should not face issues.

[Yorick Petey]

Thanks Nipun for confirmation of my findings, really appreciated!
For the moment I'll let the passthrough media change apart, as we want to enable SRTP.
But I keep your comments preciously for the "codec passthrough" aspect.
The CUBE will be used for multi-tenant providers and private PBX interco, so I try to stay away any CUCM customization for one ITSP. The minimum the SIP Trunk and global configs are customized, the maximum I keep flexibility for other setups using the same CUBE.
The ITSP is Twilio and we are very surprised to see that default mid-call behavior is not well managed. In a Hold/Transfer scenario, the SDP inactive sent by CUCM/CUBE is not "appreciated" apparently, cause they respond with a inactive as well and the call fails.

[R0g22]

Yeah. There are some interop issues with the way CUCM handles hold/transfer scenarios and the usual fix is to just re-write SDP attributes with a SIP profile.

For the pass through thing, you can utilize IOS MTP resources on the CUBE itself. It does support "codec passthrough". Any how it makes more sense to utilize a local resource on the remote site rather on CUCM remotely.