Will the SIP provider remain nameless in this thread? ;) On Thu, Mar 15, 2018 at 10:58 AM Ed Leatherman <ealeather...@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-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 <ealeather...@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 <ealeather...@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-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 <ealeather...@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-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 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 <ealeather...@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@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 >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ed Leatherman >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Ed Leatherman >>>> >>> >>> >>> >>> -- >>> 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