[cisco-voip] SIP Fail over

[Erik Anderson]

Afternoon Gents,

Changing the Retry Timer and Retry Counter on the SIP-UA fixed the issue.
With it set to 200 with 3 retries it takes about 3 seconds to connect a
call after dialing the number. Granted about a second and half of that is
connecting to the Cell Phone that I was calling.

On Thu, Dec 20, 2018 at 1:22 PM Ryan Huff <ryanhuff at outlook.com> wrote:

> A SIP ping is really just a SIP OPTIONS message (and a resulting far end
> ACK), designed to advertise capabilities and available options, but more
> often used as a method to validate the existence of a SIP path.
>
> Sent from my iPhone
>
> On Dec 20, 2018, at 14:14, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>
>
> I’ll be honest. I didn’t know there was a difference.
>
> I’m guessing a SIP trunk to a third party app that is reported as down due
> to to sip option ping really is down and not some silly networking issue
> where an icmp ping was failing.
>
> This is good to know.
>
> And the last thing I will learn this year. ;)
>
>
>
> *-sent from mobile device-*
>
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio at uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs
> <https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C038a1b1d9b1542f2e34508d666af51fa%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809300508883617&sdata=2vz8v5U4SXwGr2pu%2FvitHMPF4%2FYL%2FXiv4TzxWp%2Fh%2B4U%3D&reserved=0> |
> @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Dec 20, 2018, at 1:01 PM, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
> 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
>> <https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C038a1b1d9b1542f2e34508d666af51fa%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809300508883617&sdata=phZotBeXLJFkGhgFF8kNfZ0HzhTTuAtfC5egCtFtw%2FM%3D&reserved=0>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C038a1b1d9b1542f2e34508d666af51fa%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809300508883617&sdata=phZotBeXLJFkGhgFF8kNfZ0HzhTTuAtfC5egCtFtw%2FM%3D&reserved=0>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>


-- 
Erik Anderson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181220/0c9bcdb2/attachment.html>