Re: [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-v...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

[Bill Talley]

Only thing I can think of regarding #1 is if the new dial peer changes the 
binding of an existing call as the result of a subsequent sip update message?

No comment re: #2

Re: #3 I've done it the exact same way you mentioned.

Sent from a mobile device with very tiny touchscreen input keys. Please excude 
my typtos.

> On Sep 5, 2017, at 4:44 PM, Anthony Holloway 
>  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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[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.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip