Lost Registration While Sleeping


#21

@Marcin

Hi,

Just to clarify account 1 is to a UCM on local network using UDP? Could you please provide us the debug file? Maintenance->System Diagnosis->Debug->One click debugging (check all except packet capture). We will check the syslog first. Then we would like you to run packet capture on the device and then stop the capture when the problem occurs.

Thanks


#22

I have been away from the office for the last three days on a go-live, back in today and phone showing both accounts registered. It has been sat on the cradle all the time I was away. I have still not experienced the de-registration issue. Not much help sorry to say.


#23

Sorry to say I just re-experienced the phone losing registration on account 2 while sleeping and not on the charger base, :slightly_frowning_face:


#24

as I mentioned in the flatest firmware thread, it’s been happening here again on or off the charger base, multiple times a day :frowning:


#25

Yes same network. 2 acocunt is 2 UCM same network. It it totally not network fault.

I also notice 1 more: it never happens if handset is on cradle.

Capture: Well you notice that i do not know when account stop ?
Current debug: debugInfo_20180709083016.tar (899.5 KB)


#26

Ok, let be more precise.

  1. Account register immediate if you even try to login it via web. So logs are not really possible in state of no login.
  2. My second handset show exact same behaviour, until now it does not have problem because it was on cradle.

Logs:
debugInfo_20180709111501.tar (944 KB)
20180709111439.zip (3.8 KB)

extra > syslog on debug with sip log gathered on my PC (better then capture i think).
syslog.zip (11.6 KB)


#27

For extra security yes, but sometimes these are not options either due to upstream provider or endpoints not supporting these options easily.


#28

@Marcin

The first file “debugInfo_20180709083016.tar” did not contain any syslog. The second file “debugInfo_20180709111501.tar” contained a short syslog. I can see that the log in syslog.zip match up to the second file. Could you please clarify if the “syslog.zip” file was captured when the issue occurred? There is just over an hour of syslog only. From Jul 9 10:08:30 to Jul 9 11:15:03. You may have turned on syslog a bit late. The .pcap was too short to be useful. Could you please provide us a device configuration for reference as well? (Maintenance->Upgrade->Config->Download device config)


#29

@drostoker

Could you guys set syslog on your device to debug:
image

Then when the issue occurs provide the debug package for your device as well as the device configuration? An approx time of occurrence would be great as well.

@wa4zlw

I know we messed with the NAT traversal to help with your situation. Could you try “NAT NO” setting? If you could not register please try to port forward or setup static NAT. If you could provide another pcap trace or debug package that would be helpful.

Thanks


#30

@GS.Rick hi rick,…i believe my WP800 has those SYSLOG settings as default from the factory.

I won’t be back home till week from Friday. What is happening is the phone registers but drops out. I’m using same firewall rules for years with minor tweaks to ports to extend the SIP or RTP to allow it to be used.

Thanks leon


#31

Syslog file is from start of unit till problem occurs and little longer.

If you log to HTTP of unit it will register immediate. So you cannot catch log with WP800 tools. It is simple not possible.So all debug etc are on working all units just when i sported problem with account on UCM…

That’s why i added extra syslog.


#32

@Marcin

Ok we will send your syslog and debug package for review. Please send me your device configuration so we can review that as well. Also I’m not sure what you mean by “If you log to HTTP of unit it will register immediate.” Does this mean it will remain unregistered until you try to access web UI? Or it means the device lose registration but recovers very fast?

@wa4zlw

Please update when you have chance to test new settings. Provide new debug if it occurs again.

@drostoker

I believe we already addressed the issue of losing registration during sleep. Could you please provide a debug package and device configuration?


#33

@GS.Rick everytie I have looked after reboot there is no debug file. Also, as I reported earlier, the one click debug seems to disappear across reboots

I’ll try and get it when I can thanks


#34

Unregistered until you start web. No need login, just seeing page start re register process (not sure, it will be in syslog). Setting via private, but there is nothing but basic configuration.

Ok today i was able to generate file during process. HTTP login do not triger login. Only when i lit up screen.
files sent via private with config file.


#35

@Marcin

From your description it sounds like lost registration during sleep. Thanks for the files. Just to confirm, it is happening only for account 1? Also I see you have set the NTP server the same as the SIP server for account 1. Is the SIP server also providing NTP?


#36

Yes only 1 account always.
NTP ? i use ip as server not name.


#37

@marcin @gsrick was asking if your ntp server is the same IP as your SIP server as he is seeing that configured

leon


#38

It is UCM, so yes it is same. But NTP in this have no meaning as i do not use any names for which i need NTP.
If problem is related to NTP then both account will have same problem. I really doubt that GS program 2 account with any significant difference.


#39

I have the same issue with only the first SIP-Account registered to a UCM. Default configuration, only SIP-account is set.
It occurs after some days not using it, just standing in standby on the base. I doesn’t matter, if it’s the first firmware or the latest.

The only not standard-thing is, that we some times disconnect the base from power-supply to charge a mobile phone.


#40

@Marcin

We have identified some idle related registration issues per your debug package and the development team is looking into it. The NTP issue is unrelated and yes UCM can be used as NTP server.

@cuinthesnow

Please attach your debug file as well and we can send it for analysis. Please do make sure syslog is set to debug mode first and let the issue reoccur before downloading the package.