In our case we are not using 5060. The issue seems exclusive to VZ.

On Mon, May 13, 2019 at 2:43 PM Jared Mauch <ja...@puck.nether.net> wrote:

> This matches my experience with running SIP on networks. Slowly over the
> years it became more unreliable as “helper” ALGs were in the path.
>
> Eventually we moved some devices off 5060 to alleviate the problem.
>
> Sent from my iCar
>
> On May 13, 2019, at 2:32 PM, Dovid Bender <do...@telecurve.com> wrote:
>
> FYI: More than one person reached out to me off list. The issue is clearly
> with VZ. Traces by the others were done and NTT was not in the mix. The
> only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY
> area.
>
>
>
> On Mon, May 13, 2019 at 1:04 PM Dovid Bender <do...@telecurve.com> wrote:
>
>> Good ol UDP encrypted.
>>
>>
>>
>> On Mon, May 13, 2019 at 12:49 PM Brielle Bruns <br...@2mbit.com> wrote:
>>
>>>
>>> On 5/13/2019 10:20 AM, Dovid Bender wrote:
>>> > Thought of that. Customers have their own CPE's. So far the only thing
>>> > mutual here is that it's NTT -> VZ. Here is what I found so far
>>> looking
>>> > at two Polycom phones using non standard ports (e.g. not 5060)
>>> > 1) PhoneA tries to register multiple extensions and for each request
>>> we
>>> > send a 401. We expect to get back a REGISTER request with a no-once
>>> but
>>> > we don't. This happens for a while and then magically it starts
>>> working.
>>> > 2) PhoneB tries to register the time time as PhoneA and has no issues.
>>> >
>>> > At first I thought it was something possibly with the SIP call-ID but
>>> I
>>> > ruled that out since in the same SIP DIALOG it was not working then it
>>> > started. Also the seems to be per phone each phone is behind NAT and
>>> the
>>> > traffic is coming from a different NAT'd port. Seems like there is
>>> some
>>> > device in the middle that is randomly dropping traffic on specific
>>> sessions.
>>>
>>>
>>> Are you using TLS encrypted SIP or just plain ol' cleartext?
>>>
>>> If its encrypted, I'd look at possibly there being a MTU/MSS issue
>>> somewhere along the path possibly?
>>>
>>>
>>> --
>>> Brielle Bruns
>>> The Summit Open Source Development Group
>>> http://www.sosdg.org    /     http://www.ahbl.org
>>>
>>

Reply via email to