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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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:[email protected]] >>> Sent: Wednesday, July 20, 2016 12:34 PM >>> To: Pawlowski, Adam; '[email protected]' >>> 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:[email protected]] On Behalf Of >>> Pawlowski, Adam >>> Sent: Wednesday, July 20, 2016 5:33 AM >>> To: '[email protected]' <[email protected]> >>> 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 >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
