Jump to content

Grandstream 2160 revisited


Recommended Posts

We have deployed Grandstream 2160 for testing in our office. We are provisioning the phones from our Vodia server version 5.5.0. I am using the latest templates provided with Vodia version 5.5.0 and the latest beta firmware version 1.0.7.95 on the 2160.

 

One of the main problems we are having is call parking. I can setup buttons for call parking that work. When a call is parked the button changes from green to red to indicate a call is parked. After some time maybe a few hours or a day when you park a call the call is parked but the button does not change color.

 

I am not sure if this is a Vodia problem or a Grandstrean problem.

 

Has anybody deployed Grandstream 2160 phones in a production environment that are working with reliable call parking.

Link to comment
Share on other sites

The overall problem with the buttons is that it (today) is based on "dialog state", a RFC that originally designed for SIP proxy activity detection. It is subscription-based, and if that subscription gets shaky for example because of registration instability, so does the LED.

 

There have been numerous RFC being written over the past ten years for all sorts of existing and non-existing problems. Maybe we have overlooked the RFC that addresses the simple problem of turning a LED on or off, but just can't find it.

Link to comment
Share on other sites

Are you saying you think it is a problem with the phone or with the PBX or both?

 

What sort of troubleshooting should be done to determine where the issue lies?

 

We would really like to use the GXP2160. We deploy mostly Snom 7xx series due the the integration with the Vodia PBX. The Snom provisioning works well, they are stable and have most of the features we need. The Grandstream phones look WAY better than the Snoms. Most of the features on the Grandstreams work. The biggest problem with the Grandstreams is the buttons.

Link to comment
Share on other sites

This is a general problem of the SIP protocol. With the snoms we were using a "hack" that is not using any RFC. What you could do is monitor how stable the registration is, e.g. send an email out every time the registration changes with the phone. There is a setting for that in the extension registration tab. You can also see in the domain how long the phones are registered; those registrations should in theory be the uptime of the PBX or the time since the phone booted last time. If they are shorter, there is a problem. You can compare the times of the Grandstream phones with the snom phones or other phones. For example, we were not able to keep a Yealink phone registered on TCP for more than 24 hours even in the LAN, until they fixed something in their firmware and now it seems to be rock solid.

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...