[cisco-voip] SIP Fail over

[Anthony Holloway]

Since you don't have OPTIONS enabled on the outside to the ITSP, it's more
than likely just taking a really long time to fail.  You shouldn't need
IPSLA to shutdown your dial-peers.

If you're using the default timers and retries on CUBE, then it takes
something like 30 seconds of dead air before CUCM will receive a message
back from CUBE that the call failed to progress, and let CUCM use the next
member of the route.

Can you produce a SIP dialog of a failed call for us, and hang on the line
for upwards of 45 seconds.

Default retries on CUBE is 6, and the timer starts at 500ms, doubling each
time.

Try 1 = 500ms = Total Time 500ms
Try 2 = 1000ms = Total Time 1500ms (1.5s)
Try 3 = 2000ms = Total Time 3500ms (3.5s)
Try 4 = 4000ms = Total Time 7500ms (7.5s)
Try 5 = 8000ms = Total Time 15500ms (15.5s)
Try 6 = 16000ms = Total Time 31500ms (31.5s)


On Thu, Dec 20, 2018 at 11:08 AM Erik Anderson <erik.anderson.85 at gmail.com>
wrote:

> Morning Folks,
>
> We have implemented a new SIP solution with Level 3 and found that we have
> outbound calling failover issues. When a CUBE loses its ability to talk to
> its Level 3 Peer, but can still talk to CUCM outbound calls will still
> connect to the CUBE, but fail connecting to Level 3. In turn CUCM still
> thinks the call is connected since the CUCM SIP trunk remains up to the
> CUBE.
>
>
>
> Architecture Notes:
>
>
>
> 4 Locations with 1 CUBE Each
>
> 4 CUCM SIP Trunks with each connecting to one of the 4 CUBEs
>
> 4 CUCM Route Groups with Various CUBE/SIP Trunks assigned a Distribution
> Algorithm of Top Down
>
> Each CUBE has 2 SIP Peers
>
> Each CUBE can only talk to its respective SIP peer via its local Level 3
> Transport to reduce call control latency by not allowing it to use the
> DMVPN backup network
>
> Level 3 does not support SIP Options Ping
>
> CUCM Trunks have SIP Options Ping enabled
>
>
>
> Call Flows:
>
>
>
> Working Flow:
>
>
>
> Phone ----> SLRG ----> Route Group Member #1 ----> CUBE SIP TRUNK ---->
> CUBE ----> Level 3 Transport ----> Level 3 SIP Peer #1/#2 ----> Call
> Completes
>
>
>
>
>
> CUBE Failure:
>
>
>
> Phone ----> SLRG ---->
>
>          Route Group Member #1 ----> CUBE SIP TRUNK --X--> CUBE (CUCM Cant
> Reach CUBE)
>
>
>
>         CUCM Routes Call to Next Route Group Member
>
>
>
>                               Route Group Member #2 ----> CUBE SIP TRUNK
> ----> CUBE ----> Level 3 Transport ----> Level 3 SIP Peer #1/#2 ----> Call
> Completes
>
>
>
> Level 3 Transport Failure/SIP Server Failure:
>
>
>
> Phone ----> SLRG ---->
>
>          Route Group Member #1 ----> CUBE SIP TRUNK ----> CUBE --X-->
> Level 3 Transport (CUBE Cant Reach Level 3 SIP Server)
>
>
>
>         CUCM Thinks Call Connects since the CUBE accepts the call, Phone
> gets dead air, never tries the next RG Member
>
>
>
>
>
> My idea to fix this is to use an IPSLA to ping the pingable address on the
> Level 3 SIP Servers. If both address are unreachable then shutdown the CUCM
> Dial-Peers. This doesn’t sounds like the best way of fixing it, but it
> should work.
>
>
>
> If any has any other better ideas please let me know.
> --
> Erik Anderson
> Telecom Manager
> Some Random Corp.
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181220/41054bd3/attachment.html>