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
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
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
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..
>
>
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 SR
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 look
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
: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
> *Sent: *Tuesday, March 6, 2018 7:31 AM
> *To: *Anthony Holloway
> *Cc: *Cisco VOIP
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 tr
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
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 u
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 mov
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.
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
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
15 matches
Mail list logo
