[cisco-voip] SIP Fail over

Thu Dec 20 12:53:12 EST 2018

Not sure what kind of code you're working with but if its modern, you could try server groups. Here is a snippet from one of mine (using AT&T admitidly), sanitized for the NSA ...

voice class server-group 100
 ipv4 12.x.x.x preference 1
 ipv4 12.x.x.x preference 2
 ipv4 12.x.x.x preference 3
 ipv4 12.x.x.x preference 1
 description PSTN SIGNALING PEERS
!
voice class server-group 200
 ipv4 10.x.x.x preference 3
 ipv4 10.x.x.x preference 1
 ipv4 10.x.x.x preference 2
 description CUCM SIGNALING PEERS
!
voice class sip-options-keepalive 100
 description PSTN HEARTBEAT
!
voice class sip-options-keepalive 200
 description CCM HEARTBEAT
!
{ .. other config .. }

dial-peer voice 100 voip
 description INGRESS/EGRESS WITH PSTN
 translation-profile outgoing PLUS1_STRIP
 huntstop
 destination-pattern A
 session protocol sipv2
 session server-group 100
 destination dpg 200
 incoming uri via PSTN
 voice-class codec 1
 voice-class sip options-ping 60
 voice-class sip profiles 100
 voice-class sip options-keepalive profile 100
 voice-class sip bind control source-interface XXXX
 voice-class sip bind media source-interface XXXX
 dtmf-relay rtp-nte sip-notify
 no vad
!
dial-peer voice 200 voip
 description INGRESS/EGRESS WITH CUCM
 translation-profile outgoing PLUS1_STRIP
 huntstop
 destination-pattern A
 session protocol sipv2
 session server-group 200
 destination dpg 100
 incoming uri via CUCM
 voice-class codec 1
 voice-class sip profiles 200
 voice-class sip options-keepalive profile 200
 voice-class sip bind control source-interface XXXX
 voice-class sip bind media source-interface XXXX
 dtmf-relay rtp-nte sip-notify
 no vad
!

Thanks,

Ryan

________________________________
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Sent: Thursday, December 20, 2018 12:46 PM
To: NateCCIE
Cc: Ryan Huff; Erik Anderson; cisco-voip voyp list
Subject: Re: [cisco-voip] SIP Fail over

Agreed, but it would be terrible if they stated they don't support it, you bother them with OPTIONS, and then they black list you.  Just be careful and get written approval, is all I'm saying.

On Thu, Dec 20, 2018 at 11:44 AM NateCCIE <nateccie at gmail.com<mailto:nateccie at gmail.com>> wrote:

When you say level3 does not support options ping, do you mean they won’t ping you for failover, or they don’t allow you to send it to them?  Only two messages and the lack of any response will busy the endpoint, anything else if good enough for CUBE.

[cid:167ccb998e34cff311]

From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> On Behalf Of Ryan Huff
Sent: Thursday, December 20, 2018 10:35 AM
To: Erik Anderson <erik.anderson.85 at gmail.com<mailto:erik.anderson.85 at gmail.com>>; cisco-voip voyp list <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: Re: [cisco-voip] SIP Fail over

Couldn't you just use voice class sip options/keepalives to mark when the ITSP is down, so CUCM marks the trunk out of service and fails to the next route group member immediately (ideally, your secondary CUBE)? Seems like thats a more natural way of doing it versus using IP SLAs...

Thanks,

- Ryan

________________________________

From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> on behalf of Erik Anderson <erik.anderson.85 at gmail.com<mailto:erik.anderson.85 at gmail.com>>
Sent: Thursday, December 20, 2018 12:03 PM
To: cisco-voip voyp list
Subject: [cisco-voip] SIP Fail over

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<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C98ff5afcff2d4fc72c9208d666a32825%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809248267412528&sdata=ewI%2FZZIuvSBncKe2cGId8eXr3WIrCLkJx4XL4C%2FkuPk%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181220/e640cd80/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 25345 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181220/e640cd80/attachment.png>