On Thu, Aug 09, 2018 at 10:57:36AM -0700, Calvin Ellison wrote:
> Alex, what has been your experience with tunnel based solutions? Our choice
> seems to be IPSec VPN on existing gear or spending some cash on an SRTP-RTP
> "transcoder".
I personally find IPSec way too complicated. My preference
> On Aug 9, 2018, at 9:47 PM, Brandon Martin
> wrote:
>
> On 08/09/2018 04:46 AM, Alex Balashov wrote:
>> Yes, but until and unless your upstream supply chain is doing TLS and
>> you can provide end-to-end security, it's a pointless waste of time.
>
> There's also an argument to be made
On 08/09/2018 04:46 AM, Alex Balashov wrote:
Yes, but until and unless your upstream supply chain is doing TLS and
you can provide end-to-end security, it's a pointless waste of time.
There's also an argument to be made that I haven't seen brought up for
protecting SIP registration
The "but look at them" argument never tasted good to me.
Someone has to break rank and do it right first or it never gets better.
There is also the point that intra-org communications can be end-to-end
guarenteed. That resonates strongly.
On 8/9/2018 1:46 AM, Alex Balashov wrote:
Yes, but
On the security side...there's reality and there's perception. I go
through HIPAA/PCI compliance docs all the time, and they ask things about
encryption or secure/dedicated connections. I can say "no, but" or I
can just say "yes." Our HIPPA-covered clients are all on MPLS to us so we
can
Alex, what has been your experience with tunnel based solutions? Our choice
seems to be IPSec VPN on existing gear or spending some cash on an SRTP-RTP
"transcoder".
Regards,
*Calvin Ellison*
Voice Operations Engineer
calvin.elli...@voxox.com
+1 (213) 285-0555
Yes, but until and unless your upstream supply chain is doing TLS and
you can provide end-to-end security, it's a pointless waste of time.
My customers have numerous customers who "require" "encryption" and
"security", and this is provided to them on the "Last Mile" SIP trunk.
But as soon as it
I used to follow the same logic but recently have shifted. I now
wholeheartedly follow the encrypt everywhere stance. Too many industries
have compliance regulations where VoIP got the exemption because of
grandfathered PSTN focused laws, but just because you CAN go plaintext
doesnt make it
Agree with everything Ryan said, with the caveat that TLS for TLS's sake is, in
my own humble opinion, a terrible idea from a troubleshooting and general
complexity perspective. Use where absolutely necessary and nowhere else.
On August 8, 2018 7:37:13 PM EDT, Ryan Delgrosso
wrote:
>OK so to
OK so to expand on my previous smug-ness
Upsides:
* No more signaling nat issues. Literally zero. If you want to be
super-sneaky run your edge over TLS port 443 and most things wont
touch you.
* No retransmission's or registration avalanches. They simply cannot
happen since you need
Step 1: Move everything to TCP (or better yet TLS).
Step 2: Use LetsEncrypt for free perpetual certificates.
Step 3: Profit (and smug superiority over UDP based competitors battling
nat issues).
On 8/8/2018 10:43 AM, Carlos Alvarez wrote:
Do most of you have the phones authenticate
On Wed, Aug 08, 2018 at 12:39:17PM -0700, Carlos Alvarez wrote:
> So those of you using TCP, are you also using TLS?
For some customers who require it, it's done, though as we both know,
it's silly since you can only provide encryption on the last mile.
But no, SIP-TLS is a whole different
So those of you using TCP, are you also using TLS?
On Wed, Aug 8, 2018 at 12:36 PM Alex Balashov
wrote:
> On Wed, Aug 08, 2018 at 12:21:09PM -0700, Carlos Alvarez wrote:
>
> > So...who else on the list uses TCP and has any comments about it?
>
> We are not an ITSP and are Polycom-only with a
On Wed, Aug 08, 2018 at 12:21:09PM -0700, Carlos Alvarez wrote:
> So...who else on the list uses TCP and has any comments about it?
We are not an ITSP and are Polycom-only with a trivial number of
endpoints, but we do use it and it works just fine.
However, we have numerous customers, some of
TCP is definitely the way to go nowadays. We use TCP on Grandstreams all
the time, especially on their ATAs. Speaking of which, switching from
UDP to TCP will reduce your customers' support calls dramatically.
I don't know the current status over there, but 2 years ago RingCentral
moved to TCP as
It has, but it wasn't that long ago that people were still having
challenges. Our preferred phone vendor, Grandstream, still generally
advises against it.
So...who else on the list uses TCP and has any comments about it?
On Wed, Aug 8, 2018 at 11:12 AM Alex Balashov
wrote:
> That has changed
That has changed greatly since 2005.
On August 8, 2018 2:07:50 PM EDT, Carlos Alvarez wrote:
>That's a change I've never investigated. Or more precisely, haven't
>investigated since the days when the advice for doing it was "good
>luck!!"
>
>
>On Wed, Aug 8, 2018 at 11:00 AM Alex Balashov
>
That's a change I've never investigated. Or more precisely, haven't
investigated since the days when the advice for doing it was "good luck!!"
On Wed, Aug 8, 2018 at 11:00 AM Alex Balashov
wrote:
> I would have to agree with Calvin. Just use TCP.
>
> On August 8, 2018 1:58:47 PM EDT, Calvin
I've seen similar issues with Polycom phones, the fix was to set
voIpProt.SIP.strictUserValidation to "1". I don't use any other
brands, so I don't know about others.
On 08/08/2018 01:43 PM, Carlos Alvarez wrote:
Do most of you have the phones authenticate incoming calls? We haven't
been,
I would have to agree with Calvin. Just use TCP.
On August 8, 2018 1:58:47 PM EDT, Calvin Ellison
wrote:
>Using TCP or TLS would avoid open NAT issue, and can cure some naughty
>SIP
>ALG issues as well, assuming you want to tolerate the overhead.
>
>For UDP, we've used both Digest and Source
Using TCP or TLS would avoid open NAT issue, and can cure some naughty SIP
ALG issues as well, assuming you want to tolerate the overhead.
For UDP, we've used both Digest and Source request validation with Polycom
devices. Source validation is probably the easiest route, assuming the UA
doesn't
You're right, most phones have both options also. However I'm not sure how
the "same server" is applied for a phone behind NAT. Would the phone
actually know where the call came from? I've never tried it.
Alex, it does work fine with Asterisk, at least on a small scale test. But
the fear of
That would depend on the sending UA's ability to answer such challenges, unless
you're referring to some setting to white-list IPs or restrict sources to
previously called endpoints.
On August 8, 2018 1:43:45 PM EDT, Carlos Alvarez wrote:
>Do most of you have the phones authenticate incoming
Do most of you have the phones authenticate incoming calls? We haven't
been, but occasionally find a router that has unfiltered full cone NAT
(Cisco) or that puts one phone on 5060 with no filtering by IP. The result
is that the phone will start ringing at random as script kiddies hit the IP
and
24 matches
Mail list logo
