Re: [cisco-voip] session target dns

[Ed Leatherman]

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-v...@gmail.com> wrote:

> Will the SIP provider remain nameless in this thread?  ;)
>
> On Thu, Mar 15, 2018 at 10:58 AM Ed Leatherman 
> 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-v...@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 
>>> 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 
 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//SIP/Info/
> info/8192/sip_dns_type_a__query: DNS query for peer.isc.lumos.net
> and type:1
> 022211: Mar  8 13:44:04 est: //-1//SIP/Error/
> sip_dns_type_a_query:
>  TYPE A query failed for peer.isc.lumos.net
> 022212: Mar  8 13:44:04 est: //-1//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-v...@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 
>> 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-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, 

Re: [cisco-voip] session target dns

[Anthony Holloway]

Will the SIP provider remain nameless in this thread?  ;)

On Thu, Mar 15, 2018 at 10:58 AM Ed Leatherman 
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-v...@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 
>> 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 
>>> 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//SIP/Info/info/8192/sip_dns_type_a__query: DNS query
 for peer.isc.lumos.net and type:1
 022211: Mar  8 13:44:04 est:
 //-1//SIP/Error/sip_dns_type_a_query:
  TYPE A query failed for peer.isc.lumos.net
 022212: Mar  8 13:44:04 est:
 //-1//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-v...@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 
> 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-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.

Re: [cisco-voip] session target dns

[Ed Leatherman]

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-v...@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 
> 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 
>> 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//SIP/Info/info/8192/sip_dns_type_a__query: DNS query
>>> for peer.isc.lumos.net and type:1
>>> 022211: Mar  8 13:44:04 est:
>>> //-1//SIP/Error/sip_dns_type_a_query:
>>>  TYPE A query failed for peer.isc.lumos.net
>>> 022212: Mar  8 13:44:04 est: //-1//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-v...@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 
 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-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 

Re: [cisco-voip] session target dns

[Anthony Holloway]

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 
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 
> 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//SIP/Info/info/8192/sip_dns_type_a__query: DNS query
>> for peer.isc.lumos.net and type:1
>> 022211: Mar  8 13:44:04 est:
>> //-1//SIP/Error/sip_dns_type_a_query:
>>  TYPE A query failed for peer.isc.lumos.net
>> 022212: Mar  8 13:44:04 est: //-1//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-v...@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 
>>> 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-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, 

Re: [cisco-voip] session target dns

[Ed Leatherman]

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 
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//SIP/Info/
> info/8192/sip_dns_type_a__query: DNS query for peer.isc.lumos.net and
> type:1
> 022211: Mar  8 13:44:04 est: //-1//SIP/Error/
> sip_dns_type_a_query:
>  TYPE A query failed for peer.isc.lumos.net
> 022212: Mar  8 13:44:04 est: //-1//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-v...@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 
>> 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-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 

Re: [cisco-voip] session target dns

[Ed Leatherman]

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//SIP/Info/info/8192/sip_dns_type_a__query: DNS query
for peer.isc.lumos.net and type:1
022211: Mar  8 13:44:04 est:
//-1//SIP/Error/sip_dns_type_a_query:
 TYPE A query failed for peer.isc.lumos.net
022212: Mar  8 13:44:04 est: //-1//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-v...@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 
> 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-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 
>>> 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
 

Re: [cisco-voip] session target dns

[Anthony Holloway]

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  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-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 
>> 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 
>>> 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
>>> 

Re: [cisco-voip] session target dns

[Ed Leatherman]

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 Leathe

Re: [cisco-voip] session target dns

[Ryan Huff]

Good morning Ed,

Just thought I’d toss this out there to be aware of; 
CsCuy96398<https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy96398?referring_site=cisco_cli_analyzer>
 (DNS query delay). While your 16.3.5 version is not listed as a known affected 
release, its also not specifically listed as a known fixed release. The good 
news is that 16.3.1 is listed as a known fixed release, so your 16.3.5 likely 
has the fix baked in (but who really knows when it comes to IOS bugs). I’d just 
keep it in the back of your mind if you have to tshoot .

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<mailto:ealeather...@gmail.com>
Sent: Tuesday, March 6, 2018 7:31 AM
To: Anthony Holloway<mailto:avholloway+cisco-v...@gmail.com>
Cc: Cisco VOIP<mailto: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<mailto: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<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 
<lchillu...@hotmail.com<mailto: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<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 _si

Re: [cisco-voip] session target dns

[Ed Leatherman]

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 
> 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 
>> 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
>> 

Re: [cisco-voip] session target dns

[Anthony Holloway]

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 
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 
> 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 
>> 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 

Re: [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 
> 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 
> 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 
> 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 

Re: [cisco-voip] session target dns

[Anthony Holloway]

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 
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  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

Re: [cisco-voip] session target dns

[Loren Hillukka]

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 
> 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