[cisco-voip] session target dns
Ed Leatherman
ealeatherman at gmail.com
Thu Mar 8 14:16:01 EST 2018
Follow-up to this SRV/CUBE topic..
Outbound calls work fine with this setup (after I enabled ip domain-lookup
;-) )
For inbound calls, the service provider is using the hostname for the SRV
record (peer.isc.lumos.net) in the contact field of the invite. Apparently,
CUBE only does an A record lookup on that field?
022206: Mar 8 13:44:04 est:
//25051/829EEEDD9B28/SIP/Info/verbose/4608/sipSPIProcessContactInfo:
Previous Hop peer.isc.lumos.net:5060
...
022210: Mar 8 13:44:04 est:
//-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query
for peer.isc.lumos.net and type:1
022211: Mar 8 13:44:04 est:
//-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query:
TYPE A query failed for peer.isc.lumos.net
022212: Mar 8 13:44:04 est: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail:
DNS Query for peer.isc.lumos.net failed
CUBE is basically shutting down the call saying it can't resolve the
contact field. If I put a local host entry for that name using their
currently active SBC, inbound calls work. Shouldn't CUBE be doing a SRV
lookup here, or should the service provider send me an hostname instead of
an SRV in this field?
On Tue, Mar 6, 2018 at 2:25 PM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:
> Just so you know, they're not going to know if you use SRV records or not,
> or host records for that matter. They probably only care about two things:
>
> 1) They control which peers you send traffic to via DNS updates
>
> 2) They receive the proper/expected host portion in your traffic to them
>
> For all intents and purposes, the inclusion of a name in the host portion
> of a SIP URI is separate from the DNS query.
>
> The fact that you point your system at a name (or IP for that matter) and
> that it then becomes the RHS of the URI is nice, but not required.
>
> Therefore, if you ask them to commit to telling you about IP address
> changes completely negates their desire to use SRV records. Just say'n.
>
> On Tue, Mar 6, 2018 at 6:30 AM Ed Leatherman <ealeatherman at gmail.com>
> wrote:
>
>> 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-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"
>>>
>>> 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 <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 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 <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
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>
>>
>>
>> --
>> Ed Leatherman
>>
>
--
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180308/8f95ad37/attachment.html>
More information about the cisco-voip
mailing list