I will try changing the invites for sure. <div>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? <div>
<br><br><div class="gmail_quote">On Mon, Nov 23, 2009 at 3:03 PM, Chris Ward (chrward) <span dir="ltr"><<a href="mailto:chrward@cisco.com">chrward@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I would set the retries for INVITES down to 1 or 2. Also, are
you using TCP or UDP?</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">-Chris</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Ted Nugent
[mailto:<a href="mailto:tednugent73@gmail.com" target="_blank">tednugent73@gmail.com</a>] <br>
<b>Sent:</b> Monday, November 23, 2009 3:00 PM<br>
<b>To:</b> Chris Ward (chrward)<br>
<b>Cc:</b> Cisco VoIPoE List<br>
<b>Subject:</b> Re: [cisco-voip] SIP Trunk Redundancy</span></p>
</div><div><div></div><div class="h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Mark</p>
</div>
<div>
<p class="MsoNormal">Unfortunately there's not CUBE so no Dialpeers to make
changes on, any other ideas short of going with CUBE?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Chris</p>
</div>
<p class="MsoNormal">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?</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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?</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">Timer Invite Expires (seconds) = 180</p>
</div>
<div>
<p class="MsoNormal">Timer Register Delta (seconds) = 5</p>
</div>
<div>
<p class="MsoNormal">Timer Register Expires (seconds) = 3600</p>
</div>
<div>
<p class="MsoNormal">Timer T1 (msec) = 500</p>
</div>
<div>
<p class="MsoNormal">Timer T2 (msec) = 4000</p>
</div>
<div>
<p class="MsoNormal">Retry INVITE = 6 </p>
</div>
<div>
<p class="MsoNormal">Retry Non-INVITE = 10</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Mon, Nov 23, 2009 at 2:21 PM, Chris Ward (chrward) <<a href="mailto:chrward@cisco.com" target="_blank">chrward@cisco.com</a>> wrote:</p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">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.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">-Chris</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> <a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>
[mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>]
<b>On Behalf Of </b>Ted Nugent<br>
<b>Sent:</b> Monday, November 23, 2009 2:14 PM<br>
<b>To:</b> Cisco VoIPoE List<br>
<b>Subject:</b> [cisco-voip] SIP Trunk Redundancy</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. </p>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br></div></div>