[cisco-voip] SIP Fail over

Thu Dec 20 12:56:56 EST 2018

Erik,

That's an interesting insight.  It kind of sounds like you think ICMP Ping
and SIP OPTIONS Ping are related, but they are completely different.

Just because you cannot ICMP Ping the SIP Peer at L3, doesn't mean you
cannot OPTIONs them.

Am I understanding your thought process correctly?

On Thu, Dec 20, 2018 at 11:53 AM Ryan Huff <ryanhuff at outlook.com> wrote:

>
>
> Thanks,
>
> Ryan Huff, CCDP, CCNP
> Cisco Certified Network and Design Professional
>
> ------------------------------
> *From:* Ryan Huff <ryanhuff at outlook.com>
> *Sent:* Thursday, December 20, 2018 12:46 PM
> *To:* Erik Anderson
> *Subject:* Re: [cisco-voip] SIP Fail over
>
> 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 Huff, CCDP, CCNP
> Cisco Certified Network and Design Professional
>
> ------------------------------
> *From:* Erik Anderson <erik.anderson.85 at gmail.com>
> *Sent:* Thursday, December 20, 2018 12:37 PM
> *To:* Ryan Huff
> *Subject:* Re: [cisco-voip] SIP Fail over
>
> Ryan,
>
> Level 3 does not support options ping. If i try to ping the call control
> IP it will always fail. There is a separate pingable address, but I didnt
> think i could configure the options ping to use any address other than the
> target.
>
> On Thu, Dec 20, 2018 at 11:34 AM Ryan Huff <ryanhuff at outlook.com> wrote:
>
> 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> on behalf of Erik
> Anderson <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.
>
>
>
> --
> Erik Anderson
> _______________________________________________
> 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/d72021df/attachment.html>