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

Thu Jul 21 17:45:26 EDT 2016

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 <nateccie at gmail.com> 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 <nicksbarnett at gmail.com> 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 <erickbee at gmail.com>
> 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 <ajp26 at buffalo.edu> 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:nrichardson at gci.com]
>>> *Sent:* Wednesday, July 20, 2016 12:34 PM
>>> *To:* Pawlowski, Adam; 'cisco-voip at 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-bounces at puck.nether.net] *On
>>> Behalf Of *Pawlowski, Adam
>>> *Sent:* Wednesday, July 20, 2016 5:33 AM
>>> *To:* 'cisco-voip at puck.nether.net' <cisco-voip at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160721/5fcd2f42/attachment.html>