Blocking Mid-Call Signaling from CUCM SIP Trunk

[toormehdi]

Hi there, 

Lately, we have had many customers complain about intermittent call drops for external call transfers, no music on hold, and at times no audio at a resume on the SIP trunk we have from an ITSP. The problem would sometimes surface with certain carriers the call is terminating on. Mostly Cellular networks.  Essentially these are stemming from non-compliance or slightly different implementation of RFCs in the SIP stack on the network nodes along the path or the terminating endpoint. Classical a=inactive issue or choosing an undesirable SDP/codec when CUCM sent delayed offer mid-call invites. We even have ITSP telling us that Cisco's CUCM is very chatty and along the path, there could be other carriers putting a threshold on how many mid-call re-invites can be sent in a given timeframe. Exceeding those thresholds can result in the forced cancellation of the SIP session.

I understand that Cisco CUBE or other SBCs can do mid-call signaling block/consumption to prevent these to be forwarded to the ITSP/PSTN. But then I also read about allowing those re-invites when media change occurs such as change in connection IP, codec, or escalation to video/fax.

Assuming that there will never be any video on these PSTN SIP trunks, nor there would be any requirement for T.38 switchover as well that the SBC will always be in flow-through mode (i.e. we aren't going to be ever exchanging networks/IP routes with our ITSP), is it safe to say, that we just completely shut off any mid-call invites going to the other side (i.e PSTN) of CUBE/SBC

Do I need to worry about any mid-call invites which must make through to the other side on the PSTN, which otherwise are really between UC components (CUCM, CCX, CUC, phones, MOH, SBC interface facing the phones/server) ? I would appreciate your  thoughts. I am sure many have come across mid-call invite challenges which aren't going to go away any time soon as SIP continues to undergo change/development.

Also if do agree that these mid-call invites towards the PSTN serve no good purpose, do we continue to bother about some of the other parameters in CUCM SIP profile like (send send-recv in SDP) or duplex streaming for MOH etc.

Thanks for your input.

[mparra.fusionet]

Hi @toormehdi I don’t think you need to worry for the simplest set up you describe, so stopping that signaling  from being relayed is okay.

About the SIP profile settings I think those are useful certain scenarios, Duplex for MOH for call recording, since the audio is 2 ways instead 1 way, you can still hear your customer complaining or saying something key while MoH is played to them.

The send SDP parameters on the profile alter that default behavior of making the audio 1 one way (hence all the re-invites) as it is the default way MOH is handled by CUCM. I believe that is the recommended way  to do that by the SIP RFC.

The link below shows how to remove the miscall signaling if there is no change in SDP, which is a more sensible approach to only do this mid call sip re-invites when necessary, hence other do agree with you
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/213843-troubleshoot-session-refresh-on-cube.html