I get the impression that im the first customer on these new sbc's. On Thu, Mar 15, 2018, 11:12 AM Anthony Holloway < [email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 < >>> [email protected]> 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 <[email protected]> >>>> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cisco-voip mailing list >>>>>>> [email protected] >>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ed Leatherman >>>>> >>>> >>> >>> >>> -- >>> Ed Leatherman >>> >> >> >> >> -- >> Ed Leatherman >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
