CVP static routes

rafi.imran · ‎04-07-2009

I wanted to have two sip routes pointing to each call manager at sideA and sideB

Ipphones register with primary CM if the primary is down they register with secondary CM.

i have two sip static routes

7>172.25.243.42 (primary CM)

7>172.25.64.42 (secondray CM)

When the primary CM is down, I get a reserved state in CTI desktop and the call does not get transferred.

How to handle redundancy using sip static routes???

geoff · ‎04-07-2009

That's basically the correct technique. If the static routes are in CVP, there is a SIP trunk from CUCM to CVP; if the static routes are in the SIP Proxy, there is a SIP trunk from CUCM to the Proxy. If there is more than 1 of either of these devices, you need more than 1 trunk.

If the agent is going reserved, that implies that the correct label is being given to CVP through the PG. Say it's 71234. So CVP has to resolve it and you have a static route for 7> to the two subscribers. You do need to set the number of retries on INVITE to 1 (so it doesn't keep INVITING the down CUCM) and flips to the other one.

The normal way to solve this is to use the CVP diagnostic servlet and turn on DEBUG on the SIP service and on the Dynasoft library - this will give you the complete SIP messages. Follow these through and see what's being returned on the INVITE. If it's a 503 (resource unavailable) then you have a misconfiguration in CUCM with respect to the resources the trunk is in and the resources the phone is in.

So examine the SIP messages in their gory detail and see what they say.

Regards,

Geoff

rafi.imran · ‎04-07-2009

sip retry invite is set to 6 by default in CUCM.

You are saying changing this to 1 should resolve the problem.

Is this the only way to handle redundancy

in static routes pointing to 2 CMs.

will it have any major impact anywhere...

geoff · ‎04-08-2009

Look at the SIP messages as I instructed. What do you see?

Regards,

Geoff

rafi.imran · ‎04-09-2009

I shall do that..

but the retry invite config has to be done only at CM level. am i right???

rafi.imran · ‎04-09-2009

I had enabled the sip debug and have attached the logs.

10.111.64.11 is the first static route CM

10.111.1.12 is the second static route CM

I dont find 10.111.1.12 being called at all when 10.111.64.11 is down..

geoff · ‎04-09-2009

Is that a genuine trace file from CVP with absolutely no editing? Have you added some comments and changed some lines? Messages seem to be on incorrect lines.

There are way too many SIP messages for what should be a simple call. Messages seem to be triplicated. Why?

INVITE sip:3092300@10.111.64.8:5060 SIP/2.0

SIP/2.0 100 Trying

INVITE sip:7777777732@10.111.64.6;transport=udp SIP/2.0

SIP/2.0 100 Trying

SIP/2.0 200 OK

SIP/2.0 200 Ok

ACK sip:10.111.64.8:5060;transport=udp SIP/2.0

ACK sip:7777777732@10.111.64.6:5060 SIP/2.0

BYE sip:7777777732@10.111.64.6:5060 SIP/2.0

INVITE sip:91919191@10.111.64.6;transport=udp SIP/2.0

SIP/2.0 100 Trying

SIP/2.0 200 OK

INVITE sip:1243092521@10.111.64.6:5060 SIP/2.0

SIP/2.0 100 Trying

SIP/2.0 200 OK

SIP/2.0 100 Trying

SIP/2.0 200 OK

SIP/2.0 100 Trying

SIP/2.0 200 OK

ACK sip:91919191@10.111.64.6:5060 SIP/2.0

ACK sip:1243092521@10.111.64.6:5060 SIP/2.0

INVITE sip:3000@10.111.64.11;transport=udp SIP/2.0

SIP/2.0 200 OK

BYE sip:10.111.64.8:5060;transport=udp SIP/2.0

SIP/2.0 200 Ok

Regards,

Geoff

rafi.imran · ‎04-09-2009

Its a genuine file.

10.111.64.11 is the CM

10.111.64.8 is the CVP

10.111.1.12 is the secondary CM to which this call should have pointed but theres no request found in the log..