Lost calls and registrations


#41

Hi,

Yes what we saw the in logs was that the TCP repeatedly failed to receive certain network packets which caused the TCP stack to re-establish connection. The reconnection part failed somehow and still being investigated. My guess is that this is unlikely to happen if you have a strong connection to the AP. We are attempting to reproduce the issue in a weak signal area.

Thanks


#42

Hi folks…timelines random…sometimes fast sometimes slow.

Happens when in basement or on same floor as my AP at home.Happens in hotel here as well but seems not as often?

Leon


#43

This week, we just stopped testing in UDP mode and started testing in TCP mode. But we haven’t upgraded from v14 yet. We’ll be doing that today, and then we can test a similar scenario. We have multiple floors, SSIDs, and businesses in our office area.


#44

Just adding some info but I still have not experienced this issue since the handset went live. So far all working great, no drops or de-registrations despite moving around the building.


#45

@wa4zlw

Has this issue reoccurred on v1.0.1.5?

Thanks


#46

@GS.Rick GM Yes can’t test at hotel :frowning:


#47

Hi @GS.Rick – I found a way to test at hotel I use the hotspot on my fone at least until you guys fix it.
I;m headed back home this afternoon, FYI.

I see you’re provided some test builds. ANything I can play with? Have you sorted out the problem I’m having?

thanks leon


#48

@wa4zlw

We do have another test build that addresses the lost registration issue but its a build that’s quite ahead of current release and not as stable. I could share with you and others as long as there’s an understanding that this build is experimental.

Thanks


#49

I just found that while my phone says it is registered to my ITSP, voip.ms, the ITSP shows that it is not registered.

Rebooting the phone restored the registration on both.


#50

@drostoker

Do you have syslog enabled on your phone? We do want to see a debug log of this type of issue. Also I could send you a test build to try for this issue and see if it’s addressed as well.

Thanks


#51

Sorry, I do not have a SYSLOG server.


#52

Hi,

No you don’t need a syslog server. I’m referring to the below setting:

image

If it is already set to debug when the issue happened, please extract a debug package for us:

image

Thanks


#53

Sorry, it was not in Debug. I set it to Debut andI will be able to do so if I see this again,.


#54

I do not have a WP as of yet, but did look at a couple of traces. What I noticed is that the device is telling the backwoods PBX to use various ports as a CONTACT. In one case it is 38205, another is 39439, another is 41950 and 59027 and so it goes.

I saw where a call was made, but still no response from backwoods. I see subscribes made and what is interesting is that the subscribe is made from the WP and so is the 200OK, there is no response from backwoods.

I assume you have random ports enabled. You mentioned that you have specific rules for the WG router and am uncertain how it is set and how it may react to the random ports. To me, the issue is that the phone is sending the requests, but for whatever reason the contact info is using a local IP and a random port.

and

for the audio.

Normally, I would expect to see a NAT IP so the remote backwoods SIP server would know where to reach the WP via a public IP.

I did not notice a “good” capture where all is working, so I have nothing to compare against, but suspect that the provider is using the IP seen at the initial registration and then upon subsequent messages sees the variations and starts to react to the message as if it were a re-INVITE.

For testing, you might want to try and disable the random port and use one for which the WG router is specifically forwarding and then input a NAT IP so that the WP messaging will always refer to the same public IP where it is located.


#55

interesting 10.195.50.66 is the WP800. i dont remember when that capture was taken. I could have taken it on the LAN NOT WAN side of the Watchguard firewall.


#56

Perhaps some time ago, but regardless, the IP should reflect the public NAT IP whether taken from the LAN or the WAN side. This was from an WP generated INVITE on an attempted call, but the REGISTER also reflects same CONTACT (private) IP.


#57

I’m running a test version so if I see the same issue I will get new captures


#58

ok it’s already dead…just rebooted and no coredump no way to download a debug file. Again set to start one-click debugging

leon


#59

@GS.Rick I sent you the pcap privately from last night

leon


#60

@wa4zlw

Replied to your PM. @lpneblett brings up a good point we noticed before in your traces. We suggest to disable “use random port” feature on your WP800:

image

That way your WP800 will keep to using 5060 and 5062 for (account 1 and 2) respectively. If your seeing multiple bindings for your registration this is likely the cause and you may have to clear or refresh those bindings on the PBX.

On the topic of whether the device should show its NAT IP or private IP, this is actually debatable. I have see the device work with private IP in the contact in most cases. This is because the other end usually see the packet was sent from another public IP and sometimes even indicated in the VIA of the SIP. Sometimes when the packet comes back the router or gateway doesn’t know how to reach the endpoint. In these cases we recommend to setup port forwarding or static NAT.

Thanks