<div>I've had issues with the shutdown forced command not ending calls before also. </div><div><br></div><div>The dial peer bind control is annoying...</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br><div class="gmail_quote"><div>On Tue, Sep 5, 2017 at 3:44 PM Anthony Holloway <<a href="mailto:avholloway%2Bcisco-voip@gmail.com">avholloway+cisco-voip@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.<div><br></div><div>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.</div><div><br></div><div>A "show sip-ua calls summary" confirmed plenty of call legs active on the CUBE.<br></div><div><br></div><div>So, my next thing was to kill all active calls on the CUBE, which I have done in the past with this:<br></div><div><br></div><div>voice service voip</div><div> shutdown forced</div><div>!</div><div><br></div><div>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</div><div><br></div><div>I then had to further shutdown SIP like this:</div><div><br></div><div>voice service voip</div><div> sip</div><div>  call service stop</div><div>!</div><div><br></div><div>When finally, the rest of the calls cleared and I was able to bind control on my new dial-peer.<br></div><div><br></div><div>I then reverse those two commands to get back up and running.</div><div><br></div><div><div>voice service voip</div><div> no shutdown forced</div><div> sip</div><div>  no call service stop</div><div>!</div></div><div><br></div><div>This was on a 2900 ISR running 15.5(3)M5.</div><div><br></div><div>Three questions:</div><div><br></div><div>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.<br></div><div><br></div><div>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?</div><div><br></div><div>3) Outside of waiting until all calls are inactive, or dropping all calls, how would you handle this type of scenario?</div><div><br></div><div>Thanks.</div></div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div></div>