Makes sense Loren. Thanks for clarifying. And by ping group, do you mean using voice class sip-options-keepalive
On Mon, Mar 5, 2018 at 1:51 PM Loren Hillukka <lchillu...@hotmail.com> wrote: > Local dns srv allowed priority and weight, whereas server-group only > allowed priority, that I recall. Granted, you don't usually need weight, > but some customers desired that option. > Either can be used, and server-groups do add some benefits (can see better > up/down status, etc). Lately I have moved to using server-groups and it > does cover most needs as well. > Don't remember any issues With TTL but then again I only recall one > customer that pointed the DNS lookup to a central DNS server, and it broke > when they had some AD activity going on that impacted DNS lookups and thus > the call center. After that we decided to help customers protect themselves > and we always implemented local dns srv on the gw. Combining that with > options ping (and use ping group if you have multiple dial-peers pointed to > the same SIP endpoint!) really made failover/redundancy nice and quick. > > Loren > > On Mar 5, 2018, at 1:31 PM, Anthony Holloway < > avholloway+cisco-v...@gmail.com> wrote: > > Loren, > > Just out of curiosity, why didn't you just use session server groups? > Based on the config you shared, it looks like it would achieve the same > thing, but with less config, and not adding in the DNS stack within IOS. > > Ed, > > *Note, you cannot use DNS in server groups, so it's one or the other. > > I also think it's important to know that the IOS code is written such that > it will look for SRV records first, and then fallback to looking for an A > (host) record once the DNS timeouts. > > E.g., > > You enter "session target dns:collab.domain.com" > > IOS looks for _sip._udp.collab.domain.com SRV record first, timesout, > then looks for collab.domain.com host record second. > > *Note that the outgoing session transport on IOS is UDP by default, unless > you change it to TCP with the command "session transport tcp" at the "voice > service voip" level, or at the dial-peer level. So, having a _sip._tcp SRV > record on your CUBE would create a confusing scenario. Contrast this with > the incoming connection, which can be either. However, SRV records, like > Loren is showing, are for outbound connection establishments. > > I have not done an extensive amount of testing here, but I would be > curious to know if IOS handles the TTL for the DNS record correctly, or if > it queries DNS for every setup like how that one defect was hitting CUCM > SIP trunks for a while there. I looked for "TTL" in the CVP Config guide, > but it didn't say. > > On Mon, Mar 5, 2018 at 11:19 AM Loren Hillukka <lchillu...@hotmail.com> > wrote: > >> You can have your gw query your DNS server, and you have to add SRV >> records to your central DNS server (like with the jabber entries required >> to get jabber sign-in to work). >> >> Here’s the example of doing local DNS to static entries on the gateway >> itself, from the CVP 10 config guide. CVP is where I first started doing >> dns srv on the local gateway, as I preferred breaking the call center >> myself instead of having the AD/DNS teams do it for me without me knowing >> ;-) >> >> =========== >> >> You can also configure the Gateway statically instead of using DNS. The >> following example shows how both the A and SRV type records could be >> configured: >> >> ip host cvp4cc2.cisco.com 10.4.33.132 >> >> ip host cvp4cc3.cisco.com 10.4.33.133 >> >> ip host cvp4cc1.cisco.com 10.4.33.131 >> >> For SIP/TCP: >> >> ip host _sip._tcp.cvp.cisco.com srv 50 50 5060 <50%2050%205060> >> cvp4cc3.cisco.com >> >> ip host _sip._tcp.cvp.cisco.com srv 50 50 5060 <50%2050%205060> >> cvp4cc2.cisco.com >> >> ip host _sip._tcp.cvp.cisco.com srv 50 50 5060 <50%2050%205060> >> cvp4cc1.cisco.com >> >> For SIP/UDP: >> >> ip host _sip._udp.cvp.cisco.com srv 50 50 5060 <50%2050%205060> >> cvp4cc3.cisco.com >> >> ip host _sip._udp.cvp.cisco.com srv 50 50 5060 <50%2050%205060> >> cvp4cc2.cisco.com >> >> ip host _sip._udp.cvp.cisco.com srv 50 50 5060 <50%2050%205060> >> cvp4cc1.cisco.com >> >> ============ >> >> Then your dial-peer would have session target dns:cvp.cisco.com which >> would point to the SRV record, which would use the weight/priority values >> to choose the final host, and resolve the selected host to an IP using the >> normal "ip host name x.x.x.x" entry >> >> >> Loren >> >> On Mar 5, 2018, at 10:15 AM, Ed Leatherman <ealeather...@gmail.com> >> wrote: >> >> Hi everyone, >> >> Hopefully a quick question - in a dial-peer on CUBE (16.3.5) how does >> session target dns: resolve to an IP? I've never used DNS as target before >> for this. >> >> Does CUBE just do a query for the A record by default, or does it do a >> SRV query by default? I have a SIP provider that wants to start using SRV >> for their SBC(s) and I'm researching how to setup my end in IOS. If it >> doesn't query SRV default, where do I toggle that behavior? >> >> The command reference just says "Configures the host device housing the >> domain name system (DNS) server that resolves the name of the dial peer to >> receive calls." >> >> I've found the knob to tell it what SRV format to use in the sip-ua >> section. >> >> Thanks! >> >> >> >> -- >> Ed Leatherman >> >> _______________________________________________ >> 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