cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8050
Views
0
Helpful
5
Replies

CUBE "midcall-signaling passthru" Clarifications

TONY SMITH
Spotlight
Spotlight

Hi,

I wonder if someone could clarify a couple of points.   

(1) What is the effect of the configuration line "midcall-signaling passthru" on it's own, not followed by any further options.  Is that any different to removing the line altogether?

(2) We need selective mid-call signalling pass through, so will be applying settings at the dial peer level rather than globally.  In this case is the configuration applied to the inbound dial peer on which the mid-call signalling is being received, or on the outbound dial peer on which it would (or would not) be transmitted?

Thanks,  Tony S

5 Replies 5

Thanks for the response.  I've been through those two links and neither make any reference to "midcall-signalling passthru" except with the addition of "media-change".  I don't think either indicate whether the dial-peer specific application takes affect on the inbound or outbound call leg either.  

To be clear this is is currently configured ...

 sip
  bind media source-interface GigabitEthernet0/0
  outbound-proxy dns:xxxxxxxx
  midcall-signaling passthru
  sip-profiles 100

Not "midcall-signalling passthru media-change" which gives different behaviour.

"

I've just had the opportunity to run some tests and as far as I can determine the answers appear to be ...

Adding "midcall-signaling passthru" has no detectable effect

Applying "voice-class sip midcall-signaling passthru media-change" on a given dial peer has effect on calls received on that dial peer, but not on those transmitted.  In other words to "consume" midcall signalling from CUCM, but pass it through from the ITSP the command should go on the CUCM inbound dial peer.

The command 'midcall-signaling passthru media-change' is to stop the interoperability and sip timer re-invite issues toward ISP, right? 

I can't remember the details of which re-Invite types it passes and which it does not.  I suppose it essentially means it only passes them through if the change is significant enough to need it.  I've had to add the configuration to prevent a fluffy of re-Invites when a call is being placed on hold or transferred.  Without this option set these were all being passed on to the ITSP even though the changes were not really relevant, and since we were looking at a performance issue it made sense to filter these out.

Conversely I came across a scenario where this setting was messing up calls to two particular destinations.  In these cases the calls initially connected as "a=inactive", and the setting meant that the subsequent "a=sendrcv" wasn't being passed through to CUCM.  Meaning no audio.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: