[cisco-voip] cisco-voip Digest, Vol 173, Issue 3

Ed Leatherman ealeatherman at gmail.com
Tue Mar 6 08:25:00 EST 2018


Thanks for the tip!
Q
On Mon, Mar 5, 2018, 3:58 PM Loren Hillukka <lchillukka at hotmail.com> wrote:

> Nice tips Adam. The failovers to active endpoints was a pain.  That retry
> invites 2 was a must - the default was 6.
>
> Loren
>
> > On Mar 5, 2018, at 1:14 PM, Pawlowski, Adam <ajp26 at buffalo.edu> wrote:
> >
> > Ed,
> >
> > Caveat on all this that I set this up a year or two ago so I could be
> wrong on some parts:
> >
> > This does DNS SRV lookup I believe first, then A. As long as you're in
> an IOS version that supports SRV as that appeared somewhere in 15 I
> believe. We are running 15.(4)3 M2.
> >
> > I set up a number of SRV records to point at my UCM cluster, for
> example, and then have the dial-peer set to:
> >
> > session target dns:prod-all.cmgroup.subzone.zone.internal
> >
> > I don't see that I have specified "session transport tcp" in this router
> but this is a _SIP._TCP SRV record and it is up and running.
> >
> > I will say that you want to be careful with using this with the
> busyout/options ping. In my experience when it pulls the various SRV hosts,
> with respect to preference and weight, it will pick the one it should be
> using at any given point in time but it will not test all UCM nodes. It
> could be possible to busyout the group if multiple failures were to occur
> for some reason, even if other hosts are up, based on how IOS handles the
> responses to this. I sort of recall watching it, and test #1 may go to subA
> which fails, but then test #2 goes to subB so you're good. If you'd set the
> weighting different you could knock the peer offline.
> >
> > I think.
> >
> > I know that in response to this behavior I did add this configuration to
> my sip user agent configuration:
> >
> > sip-ua
> > retry invite 2
> > timers trying 100
> > !
> >
> > This was to cause the router to try again (perhaps to a different peer)
> if it failed to get anywhere with one. The defaults were too long for the
> call to fail out to a particular peer before exceeding network timers and
> losing the call.
> >
> > Best,
> >
> > Adam Pawlowski
> > SUNYAB NCS
> >
> > _______________________________________________
> > 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/20180306/f24c8beb/attachment.html>


More information about the cisco-voip mailing list