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 >>> >>
