[cisco-voip] SIP Trunk Redundancy

[Ted Nugent]

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/70785d78/attachment.html>