[cisco-voip] session target dns

[Loren Hillukka]

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-voip at gmail.com<mailto:avholloway+cisco-voip at 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<http://collab.domain.com>"

IOS looks for _sip._udp.collab.domain.com<http://udp.collab.domain.com> SRV record first, timesout, then looks for collab.domain.com<http://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 <lchillukka at hotmail.com<mailto:lchillukka at 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<http://cvp4cc2.cisco.com/> 10.4.33.132
ip host cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/> 10.4.33.133
ip host cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/> 10.4.33.131
For SIP/TCP:
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 5060<tel:50%2050%205060>cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/>
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 5060<tel:50%2050%205060>cvp4cc2.cisco.com<http://cvp4cc2.cisco.com/>
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 5060<tel:50%2050%205060>cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/>
For SIP/UDP:
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 5060<tel:50%2050%205060>cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/>
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 5060<tel:50%2050%205060>cvp4cc2.cisco.com<http://cvp4cc2.cisco.com/>
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 5060<tel:50%2050%205060>cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/>
 ============
Then your dial-peer would have session target dns:cvp.cisco.com<http://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 <ealeatherman at gmail.com<mailto:ealeatherman at 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 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/20180305/12445102/attachment.html>