Re: [cisco-voip] Route Dial-Peer Based On Response

[Nick Barnett]

In my scenario, I have an srv record setup with 4 ccm nodes, 1 and 2 are
equal weight and preferred, 3 and 4 have equal weights but are higher
weighted than the 1/2 pair.  ccm1 and 2 are at a main data center, ccm 3
and 4 are at a remote DC. I want calls load balanced to 1 and 2, and in the
case those are unavailable, load balance between 3 and 4.  This works as
expected and is a great alternative to having 4 different (unneeded) dial
peers.

The problem came to light when I added keepalive to this DP. everything is
fine and dandy when 1/2 are available, but in testing failover (acl on an
uplink to block comm to 1/2), the keepalive took the DP out of service.
Perhaps there are timers that could be shortened or extended to provide a
different response, but I decided I didn't really need keepalive when using
SRV in this manner.

On Thu, Jul 21, 2016 at 2:31 PM, NateCCIE  wrote:

> I have only used SRV destination a little bit, but my CVP friends use them
> extensively.  I have never seen the option ping with SRV records act
> differently than I would have expected.
>
> Do you have experiences where the whole dialpeer went down and other
> members of the SRV were still accessable?
>
> Sent from my iPhone
>
> On Jul 21, 2016, at 9:11 AM, Nick Barnett  wrote:
>
> That may work fine based on how the SRV and options pings are
> configured... but if you are counting on an SRV record to point to another
> CCM sub when the primary is down (etc...), options pings will likely take
> the whole DP down when a single host in the SRV goes unreachable.
>
> On Wed, Jul 20, 2016 at 6:12 PM, Erick Bergquist 
> wrote:
>
>> You could also look at adding keep alive (options ping) to the dial peers
>> and call manager sip trunk with options mentioned above.
>>
>> Do you mind sharing the tcl script?
>>
>> Erick
>>
>>
>> On Wednesday, July 20, 2016, Pawlowski, Adam  wrote:
>>
>>> Nathan,
>>>
>>>
>>>
>>> Thanks, this looks to be exactly what I’m looking for,
>>> this way I don’t convey the wrong message. It doesn’t seem like I can have
>>> more than one option other than hunt or don’t hunt, and it seems to be
>>> proper to let the telephony provider handle it. Cool. Thanks again.
>>>
>>>
>>>
>>> Adam
>>>
>>>
>>>
>>> *From:* Nathan Richardson [mailto:nrichard...@gci.com]
>>> *Sent:* Wednesday, July 20, 2016 12:34 PM
>>> *To:* Pawlowski, Adam; 'cisco-voip@puck.nether.net'
>>> *Subject:* RE: Route Dial-Peer Based On Response
>>>
>>>
>>>
>>> One thing that may help is to configure the “voice hunt” settings. For
>>> example, you could put in “no voice hunt temp-fail” which would make the
>>> router stop routing if it receives a cause code 41 from the CM so it would
>>> skip your TCL script in that scenario and should send that code back to
>>> your ITSP. It may even work to combine “no voice hunt all” with “voice hunt
>>> unassigned-number” or something like that.
>>>
>>>
>>>
>>>
>>> http://www.cisco.com/en/US/docs/ios/12_3t/voice/command/reference/vrht_v2_ps5207_TSD_Products_Command_Reference_Chapter.html#wp1190281
>>>
>>>
>>>
>>> -Nathan Richardson
>>>
>>>
>>>
>>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On
>>> Behalf Of *Pawlowski, Adam
>>> *Sent:* Wednesday, July 20, 2016 5:33 AM
>>> *To:* 'cisco-voip@puck.nether.net' 
>>> *Subject:* [cisco-voip] Route Dial-Peer Based On Response
>>>
>>>
>>>
>>> [External Email]
>>>
>>> Hey all,
>>>
>>>
>>>
>>> I’ve set up our CUBE routers to try and be a bit more
>>> slick, so I am making use of e164 pattern maps, dial peer groups, and DNS
>>> SRV lookups for redundancy/randomization. All that actually seems to be
>>> working rather well. I have a requirement to make any inactive/unallocated
>>> number in my UCM play a custome intercept. I did this, at least for now, by
>>> setting up a secondary dial peer that matches with a higher preference than
>>> my UCM peer, and it plays an announcement with a TCL script.
>>>
>>>
>>>
>>> I’d like to set this up so that if the UCM peer is down,
>>> or if it receives some other code indicating a temporary failure, etc, I
>>> either would like to bypass this peer so the code goes back to the ITSP, or
>>> I can play a message saying something about technical difficulties, etc.
>>> I’m not sure it’s possible to do this? The other way of doing this would be
>>> to have the UCM itself with a translation or something to roll to an
>>> audiotext mailbox, which is how we do this today, but it requires either
>>> that we maintain translations for all numbers, or a generic one that will
>>> answer to all extensions queried at the system which I don’t want to do
>>> either.
>>>
>>>
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Adam Pawlowski
>>>
>>> SUNY Buffalo NCS
>>>
>>>
>>>
>>
>> ___
>> cisco-voip mailing list
>> 

Re: [cisco-voip] Route Dial-Peer Based On Response

[Nick Barnett]

That may work fine based on how the SRV and options pings are configured...
but if you are counting on an SRV record to point to another CCM sub when
the primary is down (etc...), options pings will likely take the whole DP
down when a single host in the SRV goes unreachable.

On Wed, Jul 20, 2016 at 6:12 PM, Erick Bergquist  wrote:

> You could also look at adding keep alive (options ping) to the dial peers
> and call manager sip trunk with options mentioned above.
>
> Do you mind sharing the tcl script?
>
> Erick
>
>
> On Wednesday, July 20, 2016, Pawlowski, Adam  wrote:
>
>> Nathan,
>>
>>
>>
>> Thanks, this looks to be exactly what I’m looking for,
>> this way I don’t convey the wrong message. It doesn’t seem like I can have
>> more than one option other than hunt or don’t hunt, and it seems to be
>> proper to let the telephony provider handle it. Cool. Thanks again.
>>
>>
>>
>> Adam
>>
>>
>>
>> *From:* Nathan Richardson [mailto:nrichard...@gci.com]
>> *Sent:* Wednesday, July 20, 2016 12:34 PM
>> *To:* Pawlowski, Adam; 'cisco-voip@puck.nether.net'
>> *Subject:* RE: Route Dial-Peer Based On Response
>>
>>
>>
>> One thing that may help is to configure the “voice hunt” settings. For
>> example, you could put in “no voice hunt temp-fail” which would make the
>> router stop routing if it receives a cause code 41 from the CM so it would
>> skip your TCL script in that scenario and should send that code back to
>> your ITSP. It may even work to combine “no voice hunt all” with “voice hunt
>> unassigned-number” or something like that.
>>
>>
>>
>>
>> http://www.cisco.com/en/US/docs/ios/12_3t/voice/command/reference/vrht_v2_ps5207_TSD_Products_Command_Reference_Chapter.html#wp1190281
>>
>>
>>
>> -Nathan Richardson
>>
>>
>>
>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On
>> Behalf Of *Pawlowski, Adam
>> *Sent:* Wednesday, July 20, 2016 5:33 AM
>> *To:* 'cisco-voip@puck.nether.net' 
>> *Subject:* [cisco-voip] Route Dial-Peer Based On Response
>>
>>
>>
>> [External Email]
>>
>> Hey all,
>>
>>
>>
>> I’ve set up our CUBE routers to try and be a bit more
>> slick, so I am making use of e164 pattern maps, dial peer groups, and DNS
>> SRV lookups for redundancy/randomization. All that actually seems to be
>> working rather well. I have a requirement to make any inactive/unallocated
>> number in my UCM play a custome intercept. I did this, at least for now, by
>> setting up a secondary dial peer that matches with a higher preference than
>> my UCM peer, and it plays an announcement with a TCL script.
>>
>>
>>
>> I’d like to set this up so that if the UCM peer is down,
>> or if it receives some other code indicating a temporary failure, etc, I
>> either would like to bypass this peer so the code goes back to the ITSP, or
>> I can play a message saying something about technical difficulties, etc.
>> I’m not sure it’s possible to do this? The other way of doing this would be
>> to have the UCM itself with a translation or something to roll to an
>> audiotext mailbox, which is how we do this today, but it requires either
>> that we maintain translations for all numbers, or a generic one that will
>> answer to all extensions queried at the system which I don’t want to do
>> either.
>>
>>
>>
>> Any thoughts?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Adam Pawlowski
>>
>> SUNY Buffalo NCS
>>
>>
>>
>
> ___
> 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