Lost calls and registrations


#21

This is beta, you suppose to find bugs.
If there is TCP problem or other then find it.

Log have way to much OPTION then it should and if you have problem with packets then TCP is worse in this scenario as it is dependant of confirming packets.


#22

GM - please don’t argue TCP vs UDP; as mitch said it should work.

THe phone locks up quite often and this time I had the SOP OPTIONS DISABLED. When this ha[ppens the phone is unpingable. The HS keyboard is still active so you only can do a power off or reboot. This is a show stopper


#23

It never happens for me.
Maybe there is a problem with TCP, i set one account on TCP and will check.


#24

happened faster this time…attached pcap two accounts phone unpingable

BWW-T30-201805290928.zip (2.1 MB)


#25

It’s dead again…no pcap


#26

Hi,

@wa4zlw Thanks for the captures. We reviewed the trace and in the failure situation we noticed the device is not getting a reply for the register packets. We see 200ok from the device for OPTIONS but we don’t see those OPTIONS packet coming to the device. Are you using UCM as the SIP server? We will try to mimic the setup and see if we can reproduce the issue as well.

It seems that in the failure condition, the device becomes unresponsive and likely suffered a crash. After this happens could you reboot the device and after boot up provide us a one click debug package as well? On the web UI, go to Maintenance->System Diagnosis->One-click debugging->check everything except capture trace->press capture->press list->download the zip and attach here.


#27

I’m back in king of prussia but I have the phone with me let me see what I can do

looks like I can’t do any of this from HS :frowning:
may take me a day or so to lash something up at the hotel here since there is no way to login to the portal :frowning:
ldz


#28

It was asked earlier what pbx I am using. I am using Asterisk (freebx) / IncrediblePBX or 3cx. Don’t assume folks are using the GS UCM.

THanks leon


#29

Hi,

We will note this in our testing to reproduce the issue.

Thanks


#30

I’ll be home on friday evening so this weekend I will see if I can get it to lock up and do a debug. BTW the keyboard is still active at least to reboot it haven’t investigated past that


#31

@wa4zlw

We suspect the drop in registration is caused by SIP OPTIONS keep alive feature. If the signal is poor in the basement (v1.0.0.16 seems to cut off connectivity around -75db) there’s a chance SIP OPTIONS will fail to get the proper response and the account will unregister. The cause of handset becoming unpingable or unresponsive is still being investigated. From our understanding, when the handset becomes unreachable bringing it closer to the AP did not help in reconnecting or establishing connection at all? Also what’s the WiFi signal reading on the handset when this happens?

Thanks


#32

HI Rick…it happens with SIP OPTIONS DISABLED. It happens upstairs in the next room. THere is no signal level just EXCELLENT and full bars (that’s why we need a readout of the actual RF level).

-75 dBm it cuts off thats a show stopper.

start --> capture nothing seems to happen?

List --> displays directory listing, there is NO Zip file; TARs and a PCAP

Under Core Dump, if you hover over the (?) check the spelling programme is UK spelling for program; needs space between default and setting

should core dump be enabled? I enabled it and rebooted. I also deleted all the debug files.

debugInfo_20180602103044.zip (8.6 MB)

leon


#33

here’s another capture…OPTIONS set OFF

debugInfo_20180603093427.zip (1.0 MB)


#34

another capture happened quicker this time

BWW-T30-20180603-0957.zip (71.1 KB)

after this reboot while I was trying to get into the GUI it crashed again

heres the debug file after the second crash

debugInfo_20180603105342.zip (1.0 MB)


#35

I do not have any problem with TCP.
Maybe your test unit firmware is broken ? If possible try downgrade and upgrade handset again.


#36

Just to throw something into the pot I still have not experienced this issue with lost calls and de-registrations. Trying my hardest though.


#37

I switched on TCP as well. For what it’s worth, I’m running kamailio to Asterisk.


#38

@wz4zlw

Thanks for the captures. The debug package is indeed a .tar not .zip. Could you also provide an export of your phone’s configuration for us to review? (Maintenance->Upgrade->Config File->Download device configuration.) After you enabled the core dump did you see any dumps generated? If there are some files in the core dump list, please download those as well.


#39

Hi Rick.,…I’ll see what I can do at the hotel. May take a day or so hopefully.
dunno if the core dump got generated or enabled. will see what I can do

thanks leon


#40

Hi guys - what were the timelines for the freeze? As of now I’ve been running TCP for a day. Maybe it’s a case where a missed reply / part of the protocol causes the lockup due to the phone presuming TCP would recover that? I’m not sure how easy that would be to simulate…
Lets say mine isn’t freezing because I don’t have any packet loss (just a guess) - but I’m not talking about packet loss between phone and proxy - I’m talking deeper - between phone and proxy TCP itself would recover / retranmit the lost response Rick was referring to.

Consider:
PBX ----(udp)—PROXY—(tcp)—PHONE
In this scenario a problem betwen PBX and PROXY or a problem ON PROXY could cause a response to be missed. If the phone can’t handle out of order messages or missed messages in TCP mode it could point to a problem deeper in the TCP stack (because while it’s certainly a problem it shouldn’t freeze the phone) - but it “feels” like the phone might be blocking on the missed reply - that would make sense?

Just a few thoughts - I’ll stay in TCP mode - no ill effects for me so far.

Cheers,

m