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

Erick Bergquist erickbee at gmail.com
Tue Sep 5 18:32:10 EDT 2017


I've had issues with the shutdown forced command not ending calls before
also.

The dial peer bind control is annoying...

If the router isn't doing routing/etc a reboot with the shutdown or stop
command in place would end the calls and keep sip inactive until the
changes were in place.



On Tue, Sep 5, 2017 at 3:44 PM Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> 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.
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170905/c31ba80e/attachment.html>


More information about the cisco-voip mailing list