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 <natec...@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 <nicksbarn...@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 <erick...@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 <aj...@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: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' <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 > >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
