Showing results for 
Search instead for 
Did you mean: 

Blocking Mid-Call Signaling from CUCM SIP Trunk

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.

Recognize Your Peers
Content for Community-Ad