voice gateway sip command while doing fail over test

[jaheshkhan]

client is planning to do fail over test for voice gateway. previously they were having PRI line. now they have SIP trunk.

they are planning to conduct failover test. they have two voice gateways . one will have priority to send call second one will have priority to receive call. this will be handled by ISP.

they will reload the voice gateeway and then try to make external calls and receiving call during that time.

what command we need to execute for SIP trunk during this operation? show sip-ua ? 

what are all the SIP troubleshooting command required during this activity? show commands and debug commands needed

[Flavio Miranda]

Sorry, wrong post.

[jaheshkhan]

i didnt understand what you are saying? i didnt request this scenario here.

 actually whom are you answering.

my question is about show and debug commands for SIP trunk. 

previously for PRI we used, debug isdn q931 and show voice call status

is show voice call status still valid for sip?

[Roger Kallberg]

Do a debug ccsip message and show call active voice brief to see the calls on the gateway.

An easier way to test this than reloading the router might be to change the route to the SP so that this traffic is sent to NULL or make temporary changes to the ACL that you should have assigned to the outgoing interface that is pointing to the SP so that it does not allow the traffic to get through.

[Flavio Miranda]

Sorry mate, I copy and past on the wrong post.

[Nithin Eluvathingal]

Debug CCSIP messages will show the calls, you can alos use debug voice ccapi inout.  Btw "one will have priority to send call second one will have priority to receive call. this will be handled by ISP." this is not true as the outgoing call priority is set by you.

Instead of restarting the router, go with option @Roger Kallberg  mentioned.

[Scott Leport]

Hi,

I've never personally done it this way, but you could stop the SIP service on the primary CUBE itself. As long as your outbound and inbound failover is configured correctly, then all calls should use the secondary CUBE / SIP service etc purely because the SIP service isn't enabled on your primary.

However, I have used a combo of a static route to null0, shut down of interface facing the ITSP and one or two other methods. It really depends on what it is you want to achieve.

As others have said, use the debug ccsip message command and that will show you which Signaling endpoint your communicating with on the ITSP side. If your failover is working, hopefully it will be the secondary!

Also the "show call active voice brief" will show you which media servers of the ITSP's your communicating with (hopefully the secondary). Alternatively, a "show call history voice brief" will show the same info for previously active calls which have been cleared.

[Elliot Dierksen]

I would say that the "call service stop" in the "sip" section of "voice service voip" would be my recommended method to do this kind of testing. As long as you omit the trailing keyword "force", it won't impact active calls. That will make your testing less disruptive.