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

Thu Jul 21 15:38:49 EDT 2016

Sorry I haven’t replied back to the group sooner, I’ve been working on a number of other items the last few days.

I wanted to answer this as I saw it flash by before I became sidetracked again.

If you use the options keepalive under the peer, it appears to choose a destination to send the SIP options message to. It will send the message to the same peer more than once, so I don’t know if it is randomly choosing the same one multiple times, or if it only chooses a new primary target every so often. All I have had experience with at the moment is that the far end peer was one that the SIP trunk wasn’t active on (UCM) and it was replying back with a service unavailable message. With enough of these in a row, the whole dial peer busies out. It does not attempt to reach other members immediately.

I probably should test this to see if it will attempt to poll another peer if the connection (TCP) fails. It probably will not. In this case, I would have to rely on the SRV itself and the invite and setup timers to handle the case of trying to have redundancy, and nix the options ping as not mixing with using SRV records.

I have it in my head that using, say, 4 hosts under the service records will allow the router to try another if setup fails (and this works, after the timers expire). Setting four peers to priority 0 does not, it fails and hunts for the next matching peer or priority. I set it up this way to avoid n^2 number of peers per matching destination, and to achieve some sort of ‘poor man’s load balancing’ even if that isn’t really required.

Adam

From: NateCCIE [mailto:nateccie at gmail.com]
Sent: Thursday, July 21, 2016 3:32 PM
To: Nick Barnett
Cc: Erick Bergquist; cisco-voip at puck.nether.net; Pawlowski, Adam
Subject: Re: [cisco-voip] Route Dial-Peer Based On Response

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto: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/6a8e2421/attachment.html>