Rule #1 is likely correct. Possibly #2...
pcap everything. The disappearing packets leave your network, so they either: - get dropped in the transit networks - get dropped in the customer network You'll likely find something on the client network that is breaking things. Probably something that is supposed to "help." As for Rules #1 - #3, you also need to take into account Rule #0: ------------------------------------------------- It's actually an issue on the customer's network, but as a VoIP provider, you need to test their network better than their IT staff in order to show them the issue. Once you show them the issue, you likely need to fix it as well, because their staff would have fixed it if they understood the problem. Once you've fixed *their* issue that was causing problems with your service -- it will all work as intended. All without a change to your VoIP system. ...And they'll tell people that they like your service, but there are problems every once in a while, but you eventually fix things if they hound you enough. ------------------------------------------------- On Fri, Dec 04, 2020 at 09:47:18AM -0600, Lewis Bergman wrote: > You forgot Rule #3, It is the ISP's fault. > > On Fri, Dec 4, 2020 at 9:32 AM Ken Hohhof <af...@kwisp.com> wrote: > > > I thought the rules of troubleshooting VoIP were: > > > > Rule #1: It's a NAT or ALG problem > > Rule #2: Refer to Rule #1 > > > > -----Original Message----- > > From: AF <af-boun...@af.afmug.com> On Behalf Of Nate Burke > > Sent: Friday, December 4, 2020 8:43 AM > > To: AnimalFarm Microwave Users Group <af@af.afmug.com> > > Subject: Re: [AFMUG] Offnet SIP and Multi-homing > > > > I use Grandstream, and BLF is Broken when trying to use SIP over TCP. > > I've never had a NAT problem before. I was just checking the other Offnet > > phones that I have, and through sheer happenstance, those handsets all > > coming in and leaving on the same transit provider. > > > > Interesting is that the Grandstream Softphone client on my cell phone works > > fine, it's only the Grandstream handsets that are the problem. I'm guessing > > they are setting the call up in 2 different ways, and one is affected while > > the other is not. I haven't done enough packetcaptures to see if there is > > a > > difference between the packet streams. > > > > > > > > On 12/4/2020 8:07 AM, Adam Moffett wrote: > > > Is there a reason not to use SIP over TCP? > > > > > > I think in the past I thought retransmits were irrelevant in a > > > realtime app, but the latency is low enough sometimes now that maybe > > > it would actually help. And TCP seems to traverse NAT more easily. > > > > > > > > > On 12/3/2020 6:18 PM, Nate Burke wrote: > > >> I'm trying to track down a strange Issue I'm having, and wondering if > > >> anyone has run into something similar. > > >> > > >> I have a couple customers that I let take phone handsets home, the > > >> Grandstream PBX is at our office. It seems that if the SIP traffic > > >> comes in one upstream, but leaves another upstream, really weird > > >> things happen. > > >> > > >> The Phone registers to the PBX just fine, and can receive calls all > > >> day long, it just cannot make calls. If I take a /24 and force it to > > >> enter and leave the network via the same provider, then everything > > >> works fine. Those of you that have multiple diverse paths, have you > > >> seen something like this? The Call in UDP Mode fails, the call in > > >> TCP mode will succeed. > > >> > > >> This only appears to be an issue with the handset talking to the PBX. > > >> All of our Sip Trunk traffic (Voip Innovations) works just fine. For > > >> some reason the handset SIP re-invite never makes it back to the > > >> handset when multi-homing is in place. > > >> > > >> > > >> > > > > > > > > > -- > > AF mailing list > > AF@af.afmug.com > > http://af.afmug.com/mailman/listinfo/af_af.afmug.com > > > > > > > > -- > > AF mailing list > > AF@af.afmug.com > > http://af.afmug.com/mailman/listinfo/af_af.afmug.com > > > > > -- > Lewis Bergman > 325-439-0533 Cell > -- > AF mailing list > AF@af.afmug.com > http://af.afmug.com/mailman/listinfo/af_af.afmug.com -- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
