Jump to content
Vodia PBX forum
andrewgroup

Phones will not register until a PBX reboot

Recommended Posts

On the two release versions immediately prior to release 4.2.1.4025 we've experienced at least 4 occasions where phones will not properly register until the PBX is rebooted.

I've read the release notes on the newer versions including the 4.3 release, but I see no mention of a bug fix related to phones being registered.

 

We are happy to upgrade to the latest, but would like to know if the condition I speak of has been seen and addressed in ..4025 or the 4.3 release?

 

To help, just prior to a reboot, we've captured a TCPDUMP file from a specific phone IP address and attempted a re-register

 

after the PBX reboot, we captured the same successful file...

 

reviewing these in Wireshark, they look amazingly similar, but someone with a lot more experience may be able to determine the issue, and perhaps this might indicate a potential bug...

 

On one PBX the failure occurred after about 45 days of uptime..... and 700 calls....

Lots of available space plus no logging going on...

 

Any advice is appreciated....

 

 

A scheduled reboot once per week would be helpful, but I understand CRON is not in the PBX OS.... any suggestions for a weekly scheduled reboot?

Share this post


Link to post
Share on other sites

This is something we're facing since a few months too, and have already a ticket regarding this going on. With the early 4.3.5xxx versions this was almost fixed, haven't checked the release version yet.

 

Until, Snom was not able to fix it officially, they were able to reprduce it, but came not up with solution yet (at least it hasn't been communicated to us yet).

Share this post


Link to post
Share on other sites

That issue was fixed as part of some changes we did in the media subsystem rework sometime before .4025. I am really surprised that was never mentioned in the release notes. We will check with ticket system and ask the team update the release notes.

Share this post


Link to post
Share on other sites

Really, We've seen this occur recently on both 4.2.0.3966 and the attached files are from release 4.2.0.3981 taken yesterday.

 

The attached files are TCPDUMP captures from the PBX watching a specific HOST (Phone that doesn't register)

 

The file named failed was taken before the PBX restart and captures the attempt by the phone to re-register...

 

The file named good is the same capture, after the PBX was restarted.

 

No other changes were made on the network, the phone was not restarted,

 

The captures look surprisingly similar, but one fails to register, the other is a success.

 

 

 

 

That issue was fixed as part of some changes we did in the media subsystem rework sometime before .4025. I am really surprised that was never mentioned in the release notes. We will check with ticket system and ask the team update the release notes.

cpas-failed.zip

Share this post


Link to post
Share on other sites

That issue was fixed as part of some changes we did in the media subsystem rework sometime before .4025. I am really surprised that was never mentioned in the release notes. We will check with ticket system and ask the team update the release notes.

 

Well, but I can confirm that it still exists in current 4.3.5xxx versions too (I just haven't tested the recent 4.3.5020), see Ticket 20110901226 for more information.

Share this post


Link to post
Share on other sites

Well, but I can confirm that it still exists in current 4.3.5xxx versions too (I just haven't tested the recent 4.3.5020), see Ticket 20110901226 for more information.

 

That ticket talks about "Sometimes snomeOne is not replying to multicast-subscribe". I assume that is different from what "andrewgroup" is talking about here.

 

Anyways,

The packets 10 & 11 in the "good" show that the registration was successful.

The packets 12 & 13 in the "failed" show that the registration was successful.

 

Was the capture taken on the PBX interface?

Share this post


Link to post
Share on other sites

That ticket talks about "Sometimes snomeOne is not replying to multicast-subscribe". I assume that is different from what "andrewgroup" is talking about here.

 

I had the same problem with multicast subscribe so I switched it to http client register and haven't had a problem since. One thing to note is under multicast subscribe, TLS and TCP would quit working for me but UDP would still work.

Share this post


Link to post
Share on other sites

That ticket talks about "Sometimes snomeOne is not replying to multicast-subscribe". I assume that is different from what "andrewgroup" is talking about here.

 

Anyways,

The packets 10 & 11 in the "good" show that the registration was successful.

The packets 12 & 13 in the "failed" show that the registration was successful.

 

Was the capture taken on the PBX interface?

 

 

YES,

 

 

I think the TCPDUMP command was'

 

tcpdump -i eth2 -s -o host 192.168.1.101 -vvv -w \home\failed

Share this post


Link to post
Share on other sites

for all practical purposes it appeared to me the registration was a success. But the phones and PBX showed otherwise. Immediately after a restart, I duplicated the capture progress form the same phone that had not been restarted of changed. It may take a few weeks for this to occur again, and considering this particular client, I won't have much time to play around, but if you think a specific piece of information may help isolate the issue, give me the scripts, commands to execute and I'll be glad to do that... We have two clients that are experiencing the issue.

 

 

One phone remained registered out of 6, but I did not reboot it to see if it would re-register.... (perhaps some weird snom phone setting is to blame, that's on all other phones...

 

 

 

 

 

That ticket talks about "Sometimes snomeOne is not replying to multicast-subscribe". I assume that is different from what "andrewgroup" is talking about here.

 

Anyways,

The packets 10 & 11 in the "good" show that the registration was successful.

The packets 12 & 13 in the "failed" show that the registration was successful.

 

Was the capture taken on the PBX interface?

Share this post


Link to post
Share on other sites

IF this is the case, what can we do to help determine the cause and obtain a potential fix?

 

Do you know of a way to force a REBOOT on CS410's Weekly, until such a solution or option can be addressed?

 

On a personal note, I'm willing to scrap all CS410's now in the field in clients at my expense and replace them with Sheeva plugs if that results in a more stable environment to run the PBX Software.

 

 

 

This maybe an issue in the Ethernet interface on CS410 only.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...