[cisco-voip] session target dns

Ed Leatherman ealeatherman at gmail.com
Thu Mar 15 12:50:35 EDT 2018 

I'm not going to explicitly call them out but its in debug snippet from
previous post :)

It's a regional SP, in their defense they have been willing to work with me
on it.

On Thu, Mar 15, 2018 at 12:41 PM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> Will the SIP provider remain nameless in this thread?  ;)
>
> On Thu, Mar 15, 2018 at 10:58 AM Ed Leatherman <ealeatherman at gmail.com>
> wrote:
>
>> I get the impression that im the first customer on these new sbc's.
>>
>> On Thu, Mar 15, 2018, 11:12 AM Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>>> Wow.  So you pointed out a flaw in the provider network.  Presumably,
>>> they were hosting other customers with the same setup; so how in the world
>>> was it working for the others?  Or maybe you are the beta tester?
>>>
>>> On Thu, Mar 15, 2018 at 9:54 AM Ed Leatherman <ealeatherman at gmail.com>
>>> wrote:
>>>
>>>> Follow-up for posterity..
>>>>
>>>> I had a feeling this was the case but got some confirmation from TAC:
>>>> "This is working as designed when this is an incoming call, the reason
>>>> why it works that way is because on the incoming leg the call comes from 1
>>>> specific IP address, and if CUBE does a DNS query for SRV it might resolve
>>>> a different IP address than the one where INVITE is coming from and might
>>>> cause inbound calls to fail. Instead, if CUBE does DNS query for A record
>>>> it will resolve one specific IP address."
>>>>
>>>>
>>>> The service provider changed their SBC to send an IP address in the
>>>> Contact field URI which resolved the issue.
>>>>
>>>>
>>>> Ed
>>>>
>>>> On Thu, Mar 8, 2018 at 2:16 PM, Ed Leatherman <ealeatherman at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ed Leatherman
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>


-- 
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180315/4af9126b/attachment.html>

More information about the cisco-voip mailing list