<div dir="ltr">In our case we are not using 5060. The issue seems exclusive to VZ.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 2:43 PM Jared Mauch <<a href="mailto:jared@puck.nether.net">jared@puck.nether.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">This matches my experience with running SIP on networks. Slowly over the years it became more unreliable as “helper” ALGs were in the path. <div><br></div><div>Eventually we moved some devices off 5060 to alleviate the problem. <br><br><div id="gmail-m_7458334884069151370AppleMailSignature" dir="ltr">Sent from my iCar</div><div dir="ltr"><br>On May 13, 2019, at 2:32 PM, Dovid Bender <<a href="mailto:dovid@telecurve.com" target="_blank">dovid@telecurve.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">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.<div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 1:04 PM Dovid Bender <<a href="mailto:dovid@telecurve.com" target="_blank">dovid@telecurve.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Good ol UDP encrypted.<div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 12:49 PM Brielle Bruns <<a href="mailto:bruns@2mbit.com" target="_blank">bruns@2mbit.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 5/13/2019 10:20 AM, Dovid Bender wrote:<br>
> Thought of that. Customers have their own CPE's. So far the only thing <br>
> mutual here is that it's NTT -> VZ. Here is what I found so far looking <br>
> at two Polycom phones using non standard ports (e.g. not 5060)<br>
> 1) PhoneA tries to register multiple extensions and for each request we <br>
> send a 401. We expect to get back a REGISTER request with a no-once but <br>
> we don't. This happens for a while and then magically it starts working.<br>
> 2) PhoneB tries to register the time time as PhoneA and has no issues.<br>
> <br>
> At first I thought it was something possibly with the SIP call-ID but I <br>
> ruled that out since in the same SIP DIALOG it was not working then it <br>
> started. Also the seems to be per phone each phone is behind NAT and the <br>
> traffic is coming from a different NAT'd port. Seems like there is some <br>
> device in the middle that is randomly dropping traffic on specific sessions.<br>
<br>
<br>
Are you using TLS encrypted SIP or just plain ol' cleartext?<br>
<br>
If its encrypted, I'd look at possibly there being a MTU/MSS issue <br>
somewhere along the path possibly?<br>
<br>
<br>
-- <br>
Brielle Bruns<br>
The Summit Open Source Development Group<br>
<a href="http://www.sosdg.org" rel="noreferrer" target="_blank">http://www.sosdg.org</a>    /     <a href="http://www.ahbl.org" rel="noreferrer" target="_blank">http://www.ahbl.org</a><br>
</blockquote></div>
</blockquote></div>
</div></blockquote></div></div></blockquote></div>