[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