[cisco-voip] SIP Trunk Redundancy

Chris Ward (chrward) chrward at cisco.com
Mon Nov 23 15:29:06 EST 2009


If it were TCP it might be fast as the TCP connection would time out
much faster. For UDP, let's start with just reducing the number of
retries. The SIP Profile may not do this as I recall, the SIP profile is
used primarily for SIP end points. There are SIP CCM Service parameters
that should cover this. Perhaps in the service window you can try both.

 

-Chris

 

From: Ted Nugent [mailto:tednugent73 at gmail.com] 
Sent: Monday, November 23, 2009 3:20 PM
To: Chris Ward (chrward)
Cc: Cisco VoIPoE List
Subject: Re: [cisco-voip] SIP Trunk Redundancy

 

I will try changing the invites for sure. 

I noticed that they are using a custom security profile and I just found
out that the provider is currently only accepting UDP for outgoing.
Apparently they had issues when they first set this up and the only way
they could get it working was to lock in the security profile with
outgoing UDP. Think this might be part of the problem? 

 

On Mon, Nov 23, 2009 at 3:03 PM, Chris Ward (chrward)
<chrward at cisco.com> wrote:

I would set the retries for INVITES down to 1 or 2. Also, are you using
TCP or UDP?

 

-Chris

 

From: Ted Nugent [mailto:tednugent73 at gmail.com] 
Sent: Monday, November 23, 2009 3:00 PM
To: Chris Ward (chrward)
Cc: Cisco VoIPoE List
Subject: Re: [cisco-voip] SIP Trunk Redundancy

 

Mark

Unfortunately there's not CUBE so no Dialpeers to make changes on, any
other ideas short of going with CUBE?

 

Chris

I'll try and pull some traces when we can test again, they have a funky
maintenance window so its hard to test anything except late at night.
When they first noticed this and got us engaged they said the sites
primary SIP routers power supply died and it never rolled to the next
SIP Trunk, they were able to physically reorder the routelist members to
get outbound calls working on the next RG in the RL but it appears to
not to be rerouting on its own? Is there an option I'm not seeing to
enable trunk failover or something like that?

 

Here are the current timers under the profile and what the defaults are
set to but if it didn't FO in well over an hour I'm thinking something
else might be at work here. Any thoughts as to which one specifically
I'm looking at so I can go in with a game plan?

 

Timer Invite Expires (seconds)  = 180

Timer Register Delta (seconds)  = 5

Timer Register Expires (seconds)  = 3600

Timer T1 (msec)  = 500

Timer T2 (msec)  = 4000

Retry INVITE  = 6 

Retry Non-INVITE  = 10

 

 

On Mon, Nov 23, 2009 at 2:21 PM, Chris Ward (chrward)
<chrward at cisco.com> wrote:

You would need to look at the traces to verify, but it may just be the
time it takes to failover. You probably need to mess with the SIP
profiles and timers to get the trunks to failover in a timely manner. I
think by default it may take 15+ seconds (depends on # of retires and
time between retries) for a SIP trunk call to failover to the next
member of a route group.

 

-Chris

 

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ted Nugent
Sent: Monday, November 23, 2009 2:14 PM
To: Cisco VoIPoE List
Subject: [cisco-voip] SIP Trunk Redundancy

 

I'm working with a client that has 3 sites where the PRIs were replaced
by SIP trunks. Everything appears to be running fine with the exception
of outbound trunk redundancy. The appear to have just removed the PRIs
from the existing RGs and replaced them with the SIP trunks. The problem
is that if a SIP trunk goes down its not rerouting to the next trunk,
they are just getting dead air. I'm assuming that this is similar to the
issue seen with H323 trunks and why a gatekeeper would be needed for
this but what are the options for SIP? I can probably get by with using
Locations CAC for FO if the trunks fills but not sure about if it
actually goes down and CUCM can determine that. CUCM 7.12 and no CUBE. 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091123/9e785070/attachment.html>


More information about the cisco-voip mailing list