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

[Anthony Holloway]

A little more context with some CLI output.

Here I am trying to kill some calls and then proving I cannot bind control,
because of this one call leg still up.

2921(conf-voi-serv)#do show sip-ua calls summ
Total SIP call legs:50, User Agent Client:25, User Agent Server:25
2921(conf-voi-serv)# sip
2921(conf-serv-sip)#  call service stop
2921(conf-serv-sip)#do show sip-ua calls summ
Total SIP call legs:2, User Agent Client:1, User Agent Server:1
2921(conf-serv-sip)#exit
2921(conf-voi-serv)#shutdown forced
2921(conf-voi-serv)#do show sip-ua calls summ
Total SIP call legs:2, User Agent Client:1, User Agent Server:1
2921(conf-voi-serv)#dial-peer voice 1100 voip
2921(config-dial-peer)# voice-class sip bind control source-interface
Loopback1
There are active sip calls
The bind command change will not take effect

Interestingly, when I do a "show call active voice brief" right now, there
are no calls active.  So, I'm going to guess this is SIP OPTIONS causing a
call leg to stay up.

2921#show call active voice | in
PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
2921#

Which is even worse than an actual call, because now I have to shutdown all
the voip dial-peers, or remove OPTIONS from them at least.

2921(conf-voi-serv)#dial-peer voice 1100 voip
2921(config-dial-peer)# shut
2921(config-dial-peer)#dial-peer voice 1200 voip
2921(config-dial-peer)# shut
2921(config-dial-peer)#dial-peer voice 2100 voip
2921(config-dial-peer)# shut
2921(config-dial-peer)#dial-peer voice 2200 voip
2921(config-dial-peer)# shut
2921(config-dial-peer)#do sh sip-ua calls summ
Total SIP call legs:2, User Agent Client:1, User Agent Server:1
2921(config-dial-peer)#

Nope.  That didn't do it either.  I guess I just have to wait it out.

On Tue, Sep 5, 2017 at 4: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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170906/b46e798d/attachment.html>