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

[NateCCIE]

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/f771ab0f/attachment.html>