[cisco-voip] SIP Fail over

Thu Dec 20 17:35:19 EST 2018

I have never seen that done before.  I like it!

Just be careful hard coding your stratum to a value of 2 all the time.
Instead it should be a relative value, higher than your reference clock.
Or if you do want a one-size-fits-all stratum, 14 maybe
<http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.5.>
?

Thanks for sharing that tip Ryan!

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

> I like ntp master 2 as a fallback, to allow synchronization with the local
> device clock in a DR/Outage scenario where I fail sync to the actual
> reference clock
>
> Sent from my iPhone
>
> On Dec 20, 2018, at 14:51, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
> It's very interesting to me the kinds of things people take for granted
> and go a long time without ever being corrected, simply because the people
> who know these things, think it's common knowledge.
>
> For example, I had a conversation with a senior collab person once, who
> didn't know that region bit rate settings were a ceiling, and that a lower
> bit rate could be negotiated.
>
> And as another example, Engineers who put *ntp master* on a router
> because they think this makes the router an NTP server.
>
> And as one last example, Engineers who use the ^ symbol at the beginning
> of a Dial Peer destination pattern, not knowing that destination patterns
> are left justified implicitly.  Or alternatively, don't use the $ at the
> end, effectively creating a "begins with" clause, when an "is exactly"
> clause is desired.
>
> Someone should start a thread titled: What is something you found out that
> you were wrong about for a long time?
>
> On Thu, Dec 20, 2018 at 1:14 PM 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://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C10a7704d902d47a4bb2b08d666b49661%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809323128783040&sdata=GxQXEHhlPK1yANdvpNcSsoGGyv%2FCvHq5MUsKEzfp44w%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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C10a7704d902d47a4bb2b08d666b49661%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809323128783040&sdata=17O3Cmyk3YUU3%2BGHikJFBfRgYxm9DsF6Yng75i%2FeCAM%3D&reserved=0>
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C10a7704d902d47a4bb2b08d666b49661%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636809323128783040&sdata=17O3Cmyk3YUU3%2BGHikJFBfRgYxm9DsF6Yng75i%2FeCAM%3D&reserved=0>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20181220/b82c23f1/attachment.html>