I get the impression that im the first customer on these new sbc's. <br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 15, 2018, 11:12 AM Anthony Holloway <<a href="mailto:avholloway%2Bcisco-voip@gmail.com">avholloway+cisco-voip@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 15, 2018 at 9:54 AM Ed Leatherman <<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Follow-up for posterity..<div><br></div><div>I had a feeling this was the case but got some confirmation from TAC:</div><div>"<span style="color:navy;font-family:Arial,sans-serif;font-size:10.5pt">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."</span><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:navy"><br></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:navy">The service provider changed their SBC to send an IP address in the Contact field URI which resolved the issue.</span></p></div></div><div dir="ltr"><div><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:navy"><br></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt"><font color="#000080" face="Arial, sans-serif"><span style="font-size:14px">Ed</span></font></p>
</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 8, 2018 at 2:16 PM, Ed Leatherman <span dir="ltr"><<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Follow-up to this SRV/CUBE topic..</div><div><br></div><div>Outbound calls work fine with this setup (after I enabled ip domain-lookup ;-) ) </div><div><br></div><div>For inbound calls, the service provider is using the hostname for the SRV record (<a href="http://peer.isc.lumos.net" target="_blank">peer.isc.lumos.net</a>) in the contact field of the invite. Apparently, CUBE only does an A record lookup on that field?</div><div><br></div><div>022206: Mar 8 13:44:04 est: //25051/829EEEDD9B28/SIP/Info/verbose/4608/sipSPIProcessContactInfo: Previous Hop <a href="http://peer.isc.lumos.net:5060" target="_blank">peer.isc.lumos.net:5060</a><br></div><div>...</div><div><div>022210: Mar 8 13:44:04 est: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for <a href="http://peer.isc.lumos.net" target="_blank">peer.isc.lumos.net</a> and type:1</div><div>022211: Mar 8 13:44:04 est: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query: </div><div> TYPE A query failed for <a href="http://peer.isc.lumos.net" target="_blank">peer.isc.lumos.net</a></div><div>022212: Mar 8 13:44:04 est: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail: </div><div> DNS Query for <a href="http://peer.isc.lumos.net" target="_blank">peer.isc.lumos.net</a> failed</div></div><div><br></div><div>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?</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><div><div class="m_480089932995836908m_7537315143580840889h5"><br><div class="gmail_quote">On Tue, Mar 6, 2018 at 2:25 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<div><br></div><div>1) They control which peers you send traffic to via DNS updates</div><div><br></div><div>2) They receive the proper/expected host portion in your traffic to them<br><div><br></div><div>For all intents and purposes, the inclusion of a name in the host portion of a SIP URI is separate from the DNS query.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><div class="m_480089932995836908m_7537315143580840889m_-2454188920765263407h5"><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 6, 2018 at 6:30 AM Ed Leatherman <<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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..</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 5, 2018 at 2:31 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Loren,</div><div><br></div><div>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.</div><div><br></div><div>Ed,</div><div><br></div><div>*Note, you cannot use DNS in server groups, so it's one or the other.</div><div><br></div>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.<div><br></div><div>E.g.,</div><div><br></div><div>You enter "session target dns:<a href="http://collab.domain.com" target="_blank">collab.domain.com</a>"</div><div><br></div><div>IOS looks for _sip._<a href="http://udp.collab.domain.com" target="_blank">udp.collab.domain.com</a> SRV record first, timesout, then looks for <a href="http://collab.domain.com" target="_blank">collab.domain.com</a> host record second.</div><div><br></div><div>*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.</div><div><br></div><div>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.</div></div><div class="m_480089932995836908m_7537315143580840889m_-2454188920765263407m_534846325580873314m_-8738070843334119272HOEnZb"><div class="m_480089932995836908m_7537315143580840889m_-2454188920765263407m_534846325580873314m_-8738070843334119272h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 5, 2018 at 11:19 AM Loren Hillukka <<a href="mailto:lchillukka@hotmail.com" target="_blank">lchillukka@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt"><span style="background-color:rgba(255,255,255,0)">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). </span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt"><span style="background-color:rgba(255,255,255,0)">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 ;-)<u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt"><span style="background-color:rgba(255,255,255,0)">===========</span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">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: <u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host <a href="http://cvp4cc2.cisco.com/" dir="ltr" target="_blank">cvp4cc2.cisco.com</a> 10.4.33.132<u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host <a href="http://cvp4cc3.cisco.com/" dir="ltr" target="_blank">cvp4cc3.cisco.com</a> 10.4.33.133<u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host <a href="http://cvp4cc1.cisco.com/" dir="ltr" target="_blank">cvp4cc1.cisco.com</a> 10.4.33.131<u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">For SIP/TCP:<u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host _sip._<a href="http://tcp.cvp.cisco.com/" dir="ltr" target="_blank">tcp.cvp.cisco.com</a> srv <a href="tel:50%2050%205060" dir="ltr" target="_blank">50
50 5060</a><a href="http://cvp4cc3.cisco.com/" dir="ltr" target="_blank">cvp4cc3.cisco.com</a><u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host _sip._<a href="http://tcp.cvp.cisco.com/" dir="ltr" target="_blank">tcp.cvp.cisco.com</a> srv <a href="tel:50%2050%205060" dir="ltr" target="_blank">50
50 5060</a><a href="http://cvp4cc2.cisco.com/" dir="ltr" target="_blank">cvp4cc2.cisco.com</a><u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host _sip._<a href="http://tcp.cvp.cisco.com/" dir="ltr" target="_blank">tcp.cvp.cisco.com</a> srv <a href="tel:50%2050%205060" dir="ltr" target="_blank">50
50 5060</a><a href="http://cvp4cc1.cisco.com/" dir="ltr" target="_blank">cvp4cc1.cisco.com</a><u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">For SIP/UDP:<u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host _sip._<a href="http://udp.cvp.cisco.com/" dir="ltr" target="_blank">udp.cvp.cisco.com</a> srv <a href="tel:50%2050%205060" dir="ltr" target="_blank">50
50 5060</a><a href="http://cvp4cc3.cisco.com/" dir="ltr" target="_blank">cvp4cc3.cisco.com</a><u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host _sip._<a href="http://udp.cvp.cisco.com/" dir="ltr" target="_blank">udp.cvp.cisco.com</a> srv <a href="tel:50%2050%205060" dir="ltr" target="_blank">50
50 5060</a><a href="http://cvp4cc2.cisco.com/" dir="ltr" target="_blank">cvp4cc2.cisco.com</a><u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;line-height:16.5pt"><span style="background-color:rgba(255,255,255,0)">ip host _sip._<a href="http://udp.cvp.cisco.com/" dir="ltr" target="_blank">udp.cvp.cisco.com</a> srv <a href="tel:50%2050%205060" dir="ltr" target="_blank">50
50 5060</a><a href="http://cvp4cc1.cisco.com/" dir="ltr" target="_blank">cvp4cc1.cisco.com</a><u></u><u></u></span></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt"><u></u> ============<u></u></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt"><span style="background-color:rgba(255,255,255,0)">Then your dial-peer would have session target dns:<a href="http://cvp.cisco.com/" dir="ltr" target="_blank">cvp.cisco.com</a> 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</span></p></div></div><div dir="auto"><div>
<div id="m_480089932995836908m_7537315143580840889m_-2454188920765263407m_534846325580873314m_-8738070843334119272m_5713967320667381579m_-7009208758299197112AppleMailSignature"><br>
</div>
<div id="m_480089932995836908m_7537315143580840889m_-2454188920765263407m_534846325580873314m_-8738070843334119272m_5713967320667381579m_-7009208758299197112AppleMailSignature"><br>
</div>
Loren<br>
</div></div><div dir="auto">
<div><br>
On Mar 5, 2018, at 10:15 AM, Ed Leatherman <<a href="mailto:ealeatherman@gmail.com" target="_blank">ealeatherman@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Hi everyone,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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."</div>
<div><br>
</div>
<div>I've found the knob to tell it what SRV format to use in the sip-ua section. </div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div><br clear="all">
<div><br>
</div>
-- <br>
<div class="m_480089932995836908m_7537315143580840889m_-2454188920765263407m_534846325580873314m_-8738070843334119272m_5713967320667381579m_-7009208758299197112gmail_signature" data-smartmail="gmail_signature">Ed Leatherman<br>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>cisco-voip mailing list</span><br>
<span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br>
<span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br>
</div>
</blockquote>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div class="m_480089932995836908m_7537315143580840889m_-2454188920765263407m_534846325580873314m_-8738070843334119272gmail_signature" data-smartmail="gmail_signature">Ed Leatherman<br></div>
</div></blockquote></div></div></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="m_480089932995836908m_7537315143580840889HOEnZb"><font color="#888888">-- <br><div class="m_480089932995836908m_7537315143580840889m_-2454188920765263407gmail_signature" data-smartmail="gmail_signature">Ed Leatherman<br></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_480089932995836908m_7537315143580840889gmail_signature" data-smartmail="gmail_signature">Ed Leatherman<br></div>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div>
</blockquote></div>