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
[email protected]
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
