Thanks Ryan

 (but who really knows when it comes to IOS bugs). +1



Here is the bug condition:
>
>
>
> *Upon start-up/reboot the DNS process doesn't initiate a query till around
> 18 minutes after the boot up. This long delay results in hostname
> configured features (ex:NTP servers) not being used till this process is
> complete. Even when doing this time the DNS server is reachable.*
>
>
>
> Thanks,
>
>
>
> Ryan
>
> *From: *Ed Leatherman <ealeather...@gmail.com>
> *Sent: *Tuesday, March 6, 2018 7:31 AM
> *To: *Anthony Holloway <avholloway+cisco-v...@gmail.com>
> *Cc: *Cisco VOIP <cisco-voip@puck.nether.net>
> *Subject: *Re: [cisco-voip] session target dns
>
>
>
> Thanks Anthony, That was spot on what I was trying to figure out. I've
> been using server-groups up until now (and will continue on the CUCM facing
> side), the service provider is forcing the change on the side facing them.
>
>
>
> Loren: That's an interesting idea to lock in the host resolution on the
> CUBE itself, but in this case I think it might set me up for an outage if
> the service provider changes their IP Addressing. Maybe I can get them to
> commit to telling me before they change those..
>
>
>
> On Mon, Mar 5, 2018 at 2: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 5060cvp4cc3.cisco.com
>
> ip host _sip._tcp.cvp.cisco.com srv 50 50 5060cvp4cc2.cisco.com
>
> ip host _sip._tcp.cvp.cisco.com srv 50 50 5060cvp4cc1.cisco.com
>
> For SIP/UDP:
>
> ip host _sip._udp.cvp.cisco.com srv 50 50 5060cvp4cc3.cisco.com
>
> ip host _sip._udp.cvp.cisco.com srv 50 50 5060cvp4cc2.cisco.com
>
> ip host _sip._udp.cvp.cisco.com srv 50 50 5060cvp4cc1.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
>
>
>
>
>
> --
>
> Ed Leatherman
>
>
>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to