<div>Mark</div><div>Unfortunately there's not CUBE so no Dialpeers to make changes on, any other ideas short of going with CUBE?</div><div><br></div><div>Chris</div>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?<div>
<br></div><div>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?<br>
<div><br></div><div><div>Timer Invite Expires (seconds) = 180</div><div>Timer Register Delta (seconds) = 5</div><div>Timer Register Expires (seconds) = 3600</div><div>Timer T1 (msec) = 500</div><div>Timer T2 (msec) = 4000</div>
<div>Retry INVITE = 6 </div><div>Retry Non-INVITE = 10</div><div><br></div><br><div class="gmail_quote">On Mon, Nov 23, 2009 at 2:21 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">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 class="im">
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span>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. </span></p>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<span></span></p>
</div>
</div>
</div></div>
</div>
</blockquote></div><br></div></div>