Jump to content

Snom One Mini Registration Errors


Dale

Recommended Posts

I have a Snom One Mini running 4.5.1.1107

 

I observe that about once per hour when the PBX is operating and registered I get email notices saying that the trunk registration has timed out followed by a successful registration email after a 60 second timeout. Sometimes I go for a number of hours without the warning and sometimes I get three warnings within 15 minutes.

 

Upon investigation I found that the trunk did not timeout. I looked carefully at the SIP logs and discovered that this happens whenever the UDP "Trying" message gets out of sequence from the "OK" message. That is, the REGISTER message is sent by the PBX to the SIP ISP, and the replies from the ISP come back first with an "SIP 200 OK" and then with the "SIP 100 TRYING". This seems to happen because of a route change in the internet between my PBX and my SIP ISP. It seems to me that the PBX should not complain about this event since the order of UDP traffic is not guaranteed by the Internet protocol. I think that the PBX should just ignore a "Trying" message that it is not expecting. Is there a way I can fix this so the PBX does not think that for 60 seconds the trunk is not registered?

 

I've run a number of tests on my link and no packet loss is occurring.

 

The emails I get from the PBX are shown below:

 

First:

Trunk Vitelity Gateway (2) changed to "408 Request Timeout"

(Registration failed, retry after 60 seconds). This is a notification email. Do not reply.

 

Always followed 60 seconds later by:

Trunk Vitelity Gateway (2) changed to "200 OK" (Refresh interval 30 seconds). This is a notification email. Do not reply.

Link to comment
Share on other sites

Yea this is a known problem. We have added a proper solution in version 5; if you cannot upgrade the reason for the problem might help you. The problem can occur if you have a registration interval that is too short. Then the old REGISTER transaction is still in the PBX while the new one is already being sent out. That messes things up as responses for the old transaction are coming in. If you can, try making the registration longer and hopefully keep the SIP UDP ports still open on the firewall.

Link to comment
Share on other sites

I really cannot afford the upgrade price just to fix a bug. My registration duration is set to one hour, but the keep alive time is set to blank which seems to default to 30 seconds. Which of these do you suggest I change to a longer value? What value do you suggest? Is there a way I can get this fixed for my version? This is really killing my customer.

Link to comment
Share on other sites

Per RFC the registrar set the registration duration, no matter what the client proposes. Probably your registrar sets it to 30 seconds, which is not unusual. 30 is actually a little unfortunate because the SIP transaction expires after 32 seconds. The setting overrides that; maybe just try to put a 40 there; that might solve your problem without having to charge your customer a fortune for the upgrade.

Link to comment
Share on other sites

I observe that the REGISTER message sent by the PBX seems to occur every keep alive time. When you say to try "putting 40 there" are you suggesting 40 be tried for the proposed registration duration or the keep alive time? When I change the keep alive time to be 40, I see the REGISTER messages every 40 seconds.

 

But my original observation was that the problem occurs only when the "Trying" message gets out of sequence due to a route change affecting the UDP packets. How would the timeout affect out of sequence packet processing?

Link to comment
Share on other sites

Put the 40 into the keep-alive time. Sorry for not being very clear...

 

The point is that the Trying of the next message could interfere with the previous request. Hopefully if you set the interval to 40 seconds the problem is a lot less visible, if not gone completely.

 

But I do encourage you and everybody to send an email when the trunk status changes. This is a very important sign how stable the setup us. If you don't get any warnings, you can be sure that the PBX is not missing a single beat, as it should be.

Link to comment
Share on other sites

I changed the timeout to 40 seconds. It actually seemed slightly worse with that value rather than the default 30 seconds. I get, on average, about one timeout per trunk per hour. With two trunks that is 48 emails per day....not very practical to leave the email status change warnings turned on. I'm thinking that perhaps I could get around the problem by configuring my VOIP provider to send INVITES to my public IP and not use registration. To do that I need to get the routing for the different numbers working in the PBX.

Link to comment
Share on other sites

:unsure:

 

One more thing that you can try. DNS is another problem zone for keeping trunks stable. We had a case recently where the DNS server was down and the trunk also because offline because of this. Can you use the IP address of the DNS name? Maybe the DNS records TTL are another complication in this game and using the IP address may help to rule this out.

Link to comment
Share on other sites

Thanks for your suggestion regarding DNS. However, even when I enter the IP address I get the same problem. I really think that this is a bug in the SNOM ONE code. Here is why. Even when the web page for the trunk status says "408 Request timeout..." the registration continues to be valid on the VOIP provider and I can successfully complete incoming calls to the trunk. I think the SNOM ONE code is getting confused by the out of sequence "100 Trying" message and declaring the timeout when, in fact, no timeout has occurred from the VIOP provider's perspective.

Link to comment
Share on other sites

Your are right regarding the overlapping. The 408 code is being set even though the SIP registrar might still have a valid registration. I don't agree on the 100 Trying though. That message just stops the message repetition, but it not considered a message that changes the registration status itself.

 

It would be great if the service provider as a similar feature that measures when the registration gets lost -- on their end. Maybe the whole problem then looks much less problematic and snom ONE actually sends a lot of false/early alarms.

Link to comment
Share on other sites

I did not think to look at this earlier, but I can see from the Service Providers logs and web site that registration is not really being lost. When I looked at this in detail and when I tried calls while the PBX was reporting being in the 408 state, I found the service provider did not think that the registration had been dropped and incoming calls still completed. So you are right, the problem is not as serious as it originally seemed to be. The system will be going into operation soon and the service provider does send an email whenever a call is attempted that fails because the PBX is not registered, so soon I will see how real the problem is.

 

My fall back plan if calls really are dropped is to try to configure the system without registration, where the service provider sends the calls to my static, public IP.

 

Regarding the 100 Trying message, from watching the logs I notice that I only get the 408 email when the 100 Trying message comes immediately (within the same second or two) after the 200 OK. That is, the 100 Trying has gotten out of sequence. It seems that this event confuses this version of the Snom One code (4.5.1.1107).

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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.

×
×
  • Create New...