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 < [email protected]> wrote: > Will the SIP provider remain nameless in this thread? ;) > > On Thu, Mar 15, 2018 at 10:58 AM Ed Leatherman <[email protected]> > 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 < >> [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 >>>> >>> -- Ed Leatherman
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
