[cisco-voip] CUBE Binding Control on Dial-Peer With Active Calls

[Anthony Holloway]

I have a bone to pick with the people who wrote the code for IOS and how it
doesn't let you bind control on a net new dial-peer, which has no active
calls going through it, although, there are active calls on the CUBE as a
whole.

So, here's the deal.  I was trying to setup a new dial-peer for a specific
outgoing phone number to test some config changes.  I copied the normal
outgoing PSTN dial-peer to the ITSP, changed the destination-pattern to the
number I was testing with, and when I pasted it in to the CUBE, the old
"Bind will not take affect, there are active calls." error message popped
up.

A "show sip-ua calls summary" confirmed plenty of call legs active on the
CUBE.

So, my next thing was to kill all active calls on the CUBE, which I have
done in the past with this:

voice service voip
 shutdown forced
!

However, after initiating that command, there were still some, but less,
active legs showing on the CUBE.  I waited a good 2 minutes or so for call
legs to clear, but some small amount just stayed active

I then had to further shutdown SIP like this:

voice service voip
 sip
  call service stop
!

When finally, the rest of the calls cleared and I was able to bind control
on my new dial-peer.

I then reverse those two commands to get back up and running.

voice service voip
 no shutdown forced
 sip
  no call service stop
!

This was on a 2900 ISR running 15.5(3)M5.

Three questions:

1) What could possibly be the decision process to decide that we cannot
bind control on net new dial-peers on CUBE while there are active calls.
Doesn't make any sense to me.  So, if you have a CUBE that processes phones
calls 24/7, you have to drop all active calls to add any new dial-peers
(albeit ones requiring control binding)?  That seems pretty weak.  I feel
like I should have seen this coming, considering how many CUBEs I've
configured over the years, but unfortunately, this one surprised me.

2) Why didn't the shutdown forced command clear all of the sip legs,
despite me having done this, on this very gateway even, in the past?  Are
some legs not considered "calls" and therefore are not impacted by the
gateway shutdown?

3) Outside of waiting until all calls are inactive, or dropping all calls,
how would you handle this type of scenario?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170905/3fb041bd/attachment.html>