Re: [cisco-voip] SIP Fail over

[Ryan Huff]

I have got to stop sending these damn things from my phone ... "CCM pub happily 
at S3 and the cluster subs then at an S4. Works great actually." Now you can 
dump an S1 server right on CCM to get an S2 to CCM, but I'd never recommend 
doing that for a variety of reasons.

Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: cisco-voip  on behalf of Ryan Huff 

Sent: Thursday, December 20, 2018 6:40 PM
To: Anthony Holloway
Cc: voyp list, cisco-voip
Subject: Re: [cisco-voip] SIP Fail over

Additionally, I’m not suggesting that ntp master x, is a valid way to serve NTP 
to UCOS in a production sense, because as Anthony stated, the local clock 
really isn’t a true NTPv4 server.

What I am saying is that in a DR/outage scenario, can be used to keep cluster 
communications ... etc in sync, until you can sync to real NTP severs again.

Ideally, you are monitoring “things” in the network and are aware of the NTP 
sync outage, or other event that caused the NTP sync outage (carrier failure 
... etc).

However, as Anthony also mentioned, you must do the due diligence to make sure 
the local clock remains a fallback, and is only promoted from association to 
synchronization, if needed.

Sent from my iPhone

On Dec 20, 2018, at 18:17, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Corrected sentence:

“CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 
and cluster subs at S4...”

Sent from my iPhone

On Dec 20, 2018, at 18:12, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 
and cluster subs at S3...

Alternatively, if your router syncs to an S1, and CCM Pub subsequently sync’ed 
to said router, you’ll find the CCM pub happily at S2 and the cluster subs then 
at an S3. Works great actually.

Sent from my iPhone

On Dec 20, 2018, at 18:05, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

Nate,

Good point.  Might be hard to finesse a fake stratum into the master command, 
without accidentally messing with the selection process.  Stratum number isn't 
the only criteria, and the process seems to be pretty complex.

Looks like we might not be able to have our cake and eat it too.

You must be referring to the following sentence from the CUCM 
SRND:

"Cisco highly recommends configuring the publisher to point to a Stratum-1, 
Stratum-2, or Stratum-3 NTP server to ensure that the cluster time is 
synchronized with an external time source."







On Thu, Dec 20, 2018 at 4:46 PM NateCCIE 
mailto:natec...@gmail.com>> wrote:
I think the lowest cucm will use is a 3?

Sent from my iPhone

On Dec 20, 2018, at 3:35 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

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?

Thanks for sharing that tip Ryan!



On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff 
mailto:ryanh...@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 
mailto:avholloway+cisco-v...@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 

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

Additionally, I’m not suggesting that ntp master x, is a valid way to serve NTP 
to UCOS in a production sense, because as Anthony stated, the local clock 
really isn’t a true NTPv4 server.

What I am saying is that in a DR/outage scenario, can be used to keep cluster 
communications ... etc in sync, until you can sync to real NTP severs again.

Ideally, you are monitoring “things” in the network and are aware of the NTP 
sync outage, or other event that caused the NTP sync outage (carrier failure 
... etc).

However, as Anthony also mentioned, you must do the due diligence to make sure 
the local clock remains a fallback, and is only promoted from association to 
synchronization, if needed.

Sent from my iPhone

On Dec 20, 2018, at 18:17, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Corrected sentence:

“CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 
and cluster subs at S4...”

Sent from my iPhone

On Dec 20, 2018, at 18:12, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 
and cluster subs at S3...

Alternatively, if your router syncs to an S1, and CCM Pub subsequently sync’ed 
to said router, you’ll find the CCM pub happily at S2 and the cluster subs then 
at an S3. Works great actually.

Sent from my iPhone

On Dec 20, 2018, at 18:05, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

Nate,

Good point.  Might be hard to finesse a fake stratum into the master command, 
without accidentally messing with the selection process.  Stratum number isn't 
the only criteria, and the process seems to be pretty complex.

Looks like we might not be able to have our cake and eat it too.

You must be referring to the following sentence from the CUCM 
SRND:

"Cisco highly recommends configuring the publisher to point to a Stratum-1, 
Stratum-2, or Stratum-3 NTP server to ensure that the cluster time is 
synchronized with an external time source."







On Thu, Dec 20, 2018 at 4:46 PM NateCCIE 
mailto:natec...@gmail.com>> wrote:
I think the lowest cucm will use is a 3?

Sent from my iPhone

On Dec 20, 2018, at 3:35 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

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?

Thanks for sharing that tip Ryan!



On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff 
mailto:ryanh...@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 
mailto:avholloway+cisco-v...@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 
mailto:le...@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 | 

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

Corrected sentence:

“CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 
and cluster subs at S4...”

Sent from my iPhone

On Dec 20, 2018, at 18:12, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 
and cluster subs at S3...

Alternatively, if your router syncs to an S1, and CCM Pub subsequently sync’ed 
to said router, you’ll find the CCM pub happily at S2 and the cluster subs then 
at an S3. Works great actually.

Sent from my iPhone

On Dec 20, 2018, at 18:05, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

Nate,

Good point.  Might be hard to finesse a fake stratum into the master command, 
without accidentally messing with the selection process.  Stratum number isn't 
the only criteria, and the process seems to be pretty complex.

Looks like we might not be able to have our cake and eat it too.

You must be referring to the following sentence from the CUCM 
SRND:

"Cisco highly recommends configuring the publisher to point to a Stratum-1, 
Stratum-2, or Stratum-3 NTP server to ensure that the cluster time is 
synchronized with an external time source."







On Thu, Dec 20, 2018 at 4:46 PM NateCCIE 
mailto:natec...@gmail.com>> wrote:
I think the lowest cucm will use is a 3?

Sent from my iPhone

On Dec 20, 2018, at 3:35 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

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?

Thanks for sharing that tip Ryan!



On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff 
mailto:ryanh...@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 
mailto:avholloway+cisco-v...@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 
mailto:le...@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 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 20, 2018, at 1:01 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@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 

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

CCM syncs to a local ntp master set at 2 just fine; yields the CCM pub at S3 
and cluster subs at S3...

Alternatively, if your router syncs to an S1, and CCM Pub subsequently sync’ed 
to said router, you’ll find the CCM pub happily at S2 and the cluster subs then 
at an S3. Works great actually.

Sent from my iPhone

On Dec 20, 2018, at 18:05, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

Nate,

Good point.  Might be hard to finesse a fake stratum into the master command, 
without accidentally messing with the selection process.  Stratum number isn't 
the only criteria, and the process seems to be pretty complex.

Looks like we might not be able to have our cake and eat it too.

You must be referring to the following sentence from the CUCM 
SRND:

"Cisco highly recommends configuring the publisher to point to a Stratum-1, 
Stratum-2, or Stratum-3 NTP server to ensure that the cluster time is 
synchronized with an external time source."







On Thu, Dec 20, 2018 at 4:46 PM NateCCIE 
mailto:natec...@gmail.com>> wrote:
I think the lowest cucm will use is a 3?

Sent from my iPhone

On Dec 20, 2018, at 3:35 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

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?

Thanks for sharing that tip Ryan!



On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff 
mailto:ryanh...@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 
mailto:avholloway+cisco-v...@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 
mailto:le...@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 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 20, 2018, at 1:01 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@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 
mailto:ryanh...@outlook.com>> wrote:

Re: [cisco-voip] SIP Fail over

[Anthony Holloway]

Nate,

Good point.  Might be hard to finesse a fake stratum into the master
command, without accidentally messing with the selection process.  Stratum
number isn't the only criteria, and the process seems to be pretty complex.

Looks like we might not be able to have our cake and eat it too.

You must be referring to the following sentence from the CUCM SRND

:

"Cisco highly recommends configuring the publisher to point to a Stratum-1,
Stratum-2, or Stratum-3 NTP server to ensure that the cluster time is
synchronized with an external time source."







On Thu, Dec 20, 2018 at 4:46 PM NateCCIE  wrote:

> I think the lowest cucm will use is a 3?
>
> Sent from my iPhone
>
> On Dec 20, 2018, at 3:35 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 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
> 
> ?
>
> Thanks for sharing that tip Ryan!
>
>
>
> On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff  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-v...@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  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> | le...@uoguelph.ca
>>>
>>>
>>>
>>> www.uoguelph.ca/ccs
>>> 
>>>  |
>>> @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-v...@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  wrote:
>>>


 Thanks,

 Ryan Huff, CCDP, CCNP
 Cisco Certified Network and Design Professional

 --
 *From:* Ryan Huff 
 *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
 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 

Re: [cisco-voip] SIP Fail over

[NateCCIE]

I think the lowest cucm will use is a 3?

Sent from my iPhone

> On Dec 20, 2018, at 3:35 PM, Anthony Holloway 
>  wrote:
> 
> 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?
> 
> Thanks for sharing that tip Ryan!
> 
> 
> 
>> On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff  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 
>>  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  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 | le...@uoguelph.ca
  
 www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
  
 
 
 On Dec 20, 2018, at 1:01 PM, Anthony Holloway 
  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  wrote:
>> 
>> 
>> Thanks,
>> 
>> Ryan Huff, CCDP, CCNP
>> Cisco Certified Network and Design Professional
>> 
>> From: Ryan Huff 
>> 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 
>> 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 
>>  voice-class sip bind media source-interface 
>>  dtmf-relay rtp-nte sip-notify
>>  no vad
>> !
>> dial-peer voice 200 voip
>>  description INGRESS/EGRESS WITH CUCM
>>  translation-profile outgoing PLUS1_STRIP
>>  huntstop
>>  

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

I usually use 2, because I try to always sync  the router/device.. directly to 
a cesium clock, so 2 is less in that case, by one hop. However, you are correct 
in that the static stratum should be higher, so it doesn’t take priority :).

Sent from my iPhone

On Dec 20, 2018, at 17:35, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

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?

Thanks for sharing that tip Ryan!



On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff 
mailto:ryanh...@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 
mailto:avholloway+cisco-v...@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 
mailto:le...@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 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 20, 2018, at 1:01 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@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 
mailto:ryanh...@outlook.com>> wrote:


Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Ryan Huff mailto:ryanh...@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 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

Re: [cisco-voip] SIP Fail over

[Anthony Holloway]

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

?

Thanks for sharing that tip Ryan!



On Thu, Dec 20, 2018 at 3:52 PM Ryan Huff  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-v...@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  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> | le...@uoguelph.ca
>>
>>
>>
>> www.uoguelph.ca/ccs
>> 
>>  |
>> @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-v...@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  wrote:
>>
>>>
>>>
>>> Thanks,
>>>
>>> Ryan Huff, CCDP, CCNP
>>> Cisco Certified Network and Design Professional
>>>
>>> --
>>> *From:* Ryan Huff 
>>> *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
>>> 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 

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

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 
mailto:avholloway+cisco-v...@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 
mailto:le...@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 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 20, 2018, at 1:01 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@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 
mailto:ryanh...@outlook.com>> wrote:


Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Ryan Huff mailto:ryanh...@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 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 
 voice-class sip bind media source-interface 
 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 
 voice-class sip bind media source-interface 
 dtmf-relay rtp-nte sip-notify
 no vad
!

Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Erik Anderson 
mailto:erik.anderson...@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 

Re: [cisco-voip] SIP Fail over

[Anthony Holloway]

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  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> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @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-v...@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  wrote:
>
>>
>>
>> Thanks,
>>
>> Ryan Huff, CCDP, CCNP
>> Cisco Certified Network and Design Professional
>>
>> --
>> *From:* Ryan Huff 
>> *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
>> 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  *
>>
>> * voice-class sip bind media source-interface  *
>>
>> * 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  *
>>
>> * voice-class sip bind media source-interface  *
>>
>> * dtmf-relay rtp-nte sip-notify *
>> * no vad*
>> *!*
>>
>> Thanks,
>>
>> Ryan Huff, CCDP, CCNP
>> Cisco Certified Network and Design Professional
>>
>> --
>> *From:* Erik Anderson 
>> *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 

Re: [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  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  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> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs
> 
>  |
> @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-v...@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  wrote:
>
>>
>>
>> Thanks,
>>
>> Ryan Huff, CCDP, CCNP
>> Cisco Certified Network and Design Professional
>>
>> --
>> *From:* Ryan Huff 
>> *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
>> 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  *
>>
>> * voice-class sip bind media source-interface  *
>>
>> * 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  *
>>
>> * voice-class sip bind media source-interface  *
>>
>> * dtmf-relay rtp-nte sip-notify *
>> * no vad*
>> *!*
>>
>> Thanks,
>>
>> Ryan Huff, CCDP, CCNP
>> Cisco Certified Network and Design Professional
>>
>> --
>> *From:* Erik Anderson 
>> *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 

Re: [cisco-voip] SIP Fail over

[Kent Roberts]

Might try the option pings anyway on the cube, the cube might still honor the 
response as the end point is up.

   

> On Dec 20, 2018, at 10:03 AM, Erik Anderson  
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

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 
mailto:le...@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 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs
 | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 20, 2018, at 1:01 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@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 
mailto:ryanh...@outlook.com>> wrote:


Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Ryan Huff mailto:ryanh...@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 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 
 voice-class sip bind media source-interface 
 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 
 voice-class sip bind media source-interface 
 dtmf-relay rtp-nte sip-notify
 no vad
!

Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Erik Anderson 
mailto:erik.anderson...@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 
mailto:ryanh...@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 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Erik Anderson 
mailto:erik.anderson...@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 

Re: [cisco-voip] SIP Fail over

[Lelio Fulgenzi]

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 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 20, 2018, at 1:01 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@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 
mailto:ryanh...@outlook.com>> wrote:


Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Ryan Huff mailto:ryanh...@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 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 
 voice-class sip bind media source-interface 
 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 
 voice-class sip bind media source-interface 
 dtmf-relay rtp-nte sip-notify
 no vad
!

Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Erik Anderson 
mailto:erik.anderson...@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 
mailto:ryanh...@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 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Erik Anderson 
mailto:erik.anderson...@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 

Re: [cisco-voip] SIP Fail over

[Anthony Holloway]

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  wrote:

>
>
> Thanks,
>
> Ryan Huff, CCDP, CCNP
> Cisco Certified Network and Design Professional
>
> --
> *From:* Ryan Huff 
> *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
> 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  *
>
> * voice-class sip bind media source-interface  *
>
> * 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  *
>
> * voice-class sip bind media source-interface  *
>
> * dtmf-relay rtp-nte sip-notify *
> * no vad*
> *!*
>
> Thanks,
>
> Ryan Huff, CCDP, CCNP
> Cisco Certified Network and Design Professional
>
> --
> *From:* Erik Anderson 
> *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  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  on behalf of Erik
> Anderson 
> *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 

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

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 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 
 voice-class sip bind media source-interface 
 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 
 voice-class sip bind media source-interface 
 dtmf-relay rtp-nte sip-notify
 no vad
!


Thanks,

Ryan


From: Anthony Holloway 
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 
mailto:natec...@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 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Ryan Huff
Sent: Thursday, December 20, 2018 10:35 AM
To: Erik Anderson 
mailto:erik.anderson...@gmail.com>>; cisco-voip 
voyp list mailto:cisco-voip@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 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Erik Anderson 
mailto:erik.anderson...@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 

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

Yep, I missed that line ... apologies...

Thanks,

Ryan


From: Anthony Holloway 
Sent: Thursday, December 20, 2018 12:37 PM
To: Ryan Huff
Cc: Erik Anderson; cisco-voip voyp list
Subject: Re: [cisco-voip] SIP Fail over

He did mention that L3 does not support OPTIONS.  But yes, OPTIONs is the 
better solution.

On Thu, Dec 20, 2018 at 11:36 AM Ryan Huff 
mailto:ryanh...@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 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Erik Anderson 
mailto:erik.anderson...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Ryan Huff 
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 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 
 voice-class sip bind media source-interface 
 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 
 voice-class sip bind media source-interface 
 dtmf-relay rtp-nte sip-notify
 no vad
!

Thanks,

Ryan Huff, CCDP, CCNP
Cisco Certified Network and Design Professional


From: Erik Anderson 
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 
mailto:ryanh...@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 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Erik Anderson 
mailto:erik.anderson...@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.

Re: [cisco-voip] SIP Fail over

[Anthony Holloway]

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  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.
>
>
>
>
>
> *From:* cisco-voip  *On Behalf Of *Ryan
> Huff
> *Sent:* Thursday, December 20, 2018 10:35 AM
> *To:* Erik Anderson ; cisco-voip voyp list <
> cisco-voip@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  on behalf of Erik
> Anderson 
> *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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] SIP Fail over

[Anthony Holloway]

He did mention that L3 does not support OPTIONS.  But yes, OPTIONs is the
better solution.

On Thu, Dec 20, 2018 at 11:36 AM Ryan Huff  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  on behalf of Erik
> Anderson 
> *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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] SIP Fail over

[NateCCIE]

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.

 



 

From: cisco-voip  On Behalf Of Ryan Huff
Sent: Thursday, December 20, 2018 10:35 AM
To: Erik Anderson ; cisco-voip voyp list

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 mailto:cisco-voip-boun...@puck.nether.net> > on behalf of Erik Anderson
mailto:erik.anderson...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] SIP Fail over

[Ryan Huff]

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  on behalf of Erik 
Anderson 
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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [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 
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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] SIP Fail over

[Erik Anderson]

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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip