Jump to content

Known Issues with 2.1.6.2448


ap_6200
 Share

Recommended Posts

Generally. Or it means people have gotten numb to posting issues. I want to make sure. ;-)

 

Okay, we found an issue... If the PBX calls a phone that is reacting a little bit slow on UDP transport layer, it does not cancel that call later (for example in a hunt group). This could lead to a lot of phones ringing. It is fixed in 2449. Unfortunately, we at this point have only Windows and SuSE Linux, the other versions will follow soon as the servers are up again.

Link to comment
Share on other sites

  • 2 weeks later...

We have been using 2.1.6.2448 in a 49 user system across multiple offices (over VPN) succesfully. (Grandstream 2000 and 2020 phones.)

 

One issue we have just uncovered is with email alerts for missed calls. A caller that abandons a call before going to voice mail will generate an email for the extension. If the caller leaves a voice mail, an email will also be generated. However, if the caller abandons the call during the prompts to leave a voice mail, no email is gnerated.

 

We are just getting ready to try the Grandstream 1.1.6.16 firmware (have been on 1.1.5.15 for a while now). There has been some flakiness with the phones, but I beleive the new firmware will cure most of this. The quality and stability has gotten much better. Still not as happy as we'd like to be with the FXO interface quality, but that is not a pbxnsip issue.

 

One interesting note is that the system uses a number of paging groups, but it is quite awesome to watch a page-all execute (40+ phones all get paged at once) and it works great.

 

Also had to cure a perception prblem of echo with the users. They would call from office to office and say there was echo when, in fact, the anaolg to digital to analog conversion delays casued latency between the offices. When they closed their doors, all was fine... just some of the fun with using a VoIP system with users that are used to analog systems.

 

I just implemented 2.1.6.2450 tonight, so we will see what comes of that firmware upgrade... I'm trusting it will be rock solid...! An issue we always have when upgrading is getting everything to sync back up. For example, the very first phone call that is made, does not connect. But after the firswt, all works fine. Same is true for using the FXO - I always have to restart the FXO and do one call (which fails) before the calls work. I'm not sure why this happens, but I just go through the same upgrade routine each time.

Link to comment
Share on other sites

Seems this is more of a "experience post" as opposed to posting an issue, how about posting some details on the VPN setups? Are you also pushing DATA across the VPN? is it encapsulated along with the voice? Are you using any QOS or other packet prioritization with the VPN or on the GRE packets? You said firmware upgrade, this makes it sound as if your on the CS410 platform with Firmware as opposed to a server platform. Issues like echo perception etc, can exist with analog lines and reducing the handset volumes is step 1.

Link to comment
Share on other sites

The post was meant to share issues while also helping people get some semblance of conext around usage.

 

The VPN is setup using IPSEC connections between routers. All routers are D-Link with the main server side router using a 30Mbps down / 15 Mbps up fiber Internet connection. All other connections use standard Internet connectivty available in the location (i.e. cable with speeds of 10Mbps down / 2 Mbps up or DSL with speeds of 3Mbps down / 786Kbps up). All VPN tunnels are used for both data and VoIP traffic as well as all WIndowsd domain controll traffic (DNS, AD, etc.). One connection uses a 54Mbps 802.11g wireless connection to hop over a parking lot.

 

QoS is not currently used due to issues with successful configuration - we are still working on this. VoIP has not been suffering at normal priority, so this has not been a huge issue. The network configuration is quite efficient using all Netgear smart switch devices, typically having an end device travel through a local 10/100 Mbps with PoE switch to the router then to the main router and through a backbone GB swtich. Local users connect via 10/100 Mbps switches with PoE and these swithces connect to the GB backbone switch. All servers connect to the GB backbone switch.

 

My mistake in calling the server software "firmware". We are, in fact, using a Windows Server 2003 R2 server running pbxnsip. The server is a quad core Xeon based system with 4GB of RAM and 1TB of SATA disk in RAID 5 configuration. The server connects to the network over a teamed 2GB netowrk connection using a pair of Intel 1GB NICs. The team terminates in the GB backbone samrt switch. One key was making sure pbxnsip was assigned affinity to its own CPU and making sure all other system processes were prevented from using this core (i.e. anti-virus, SQL, or other system tasks are prevented from using the pbxnsip core). The pbxnsip software runs at an average 10% CPU ustilization except when paging which drives utilization up to 50 to 90% for a brief moment.

 

Hope this helps

Link to comment
Share on other sites

WOW - Seems you've engineered a all inclusive server for your environment. Why was PBXnSIP not considered for a seperate box? It really doesn't need much in the way of processing. Our largest deployment is now 50+ users running for over a year with a PRI gateway averaging 40,000 minutes per month and 3,000 calls daily. This has been running on a AMD 3100 1GB ram Windows XP server with the best luxury being a 3WARE raid disk controller.

details listed in http://forum.pbxnsip.com/index.php?showtopic=599

Link to comment
Share on other sites

The pbxnsip software runs at an average 10% CPU ustilization except when paging which drives utilization up to 50 to 90% for a brief moment.

 

 

 

This is an interesting observation, and may explain one of my servers that continually "spikes", as one of my customers do a lot of paging, with multiple end-stations...

 

PBXnSIP, have you ever noticed this situation, and is there anything that can be done to lower the utilization?

Link to comment
Share on other sites

PBXnSIP, have you ever noticed this situation, and is there anything that can be done to lower the utilization?

 

Seems I remember this post on paging http://forum.pbxnsip.com/index.php?showtopic=197

 

Technically speaking though in every environment you are going to have things requiring more processor power than others. So long as it's not affecting quality I'd be inclined to accept utilization spikes in VoIP just as we do with other servers. If I had a client doing paging to a large number of deskset phones, I'd be pushing them to do overhead speakers in the general area of the phones. (Cubicles etc.)

Link to comment
Share on other sites

PBXnSIP, have you ever noticed this situation, and is there anything that can be done to lower the utilization?

 

Sure, unicast paging is a CPU- and bandwidth-killer. That's why we offer also multicast paging.

 

I would say keep the unicast groups smaller than 10 extensions, preferrably smaller than 5. Otherwise you are just stressing the system so much that ongoing calls might suffer.

Link to comment
Share on other sites

Sure, unicast paging is a CPU- and bandwidth-killer. That's why we offer also multicast paging.

 

I would say keep the unicast groups smaller than 10 extensions, preferrably smaller than 5. Otherwise you are just stressing the system so much that ongoing calls might suffer.

 

 

Do you know if multicast works with Polycoms? I have about 20 extension in a paging group (unicast) triggered from a linksys pap2t in a nursing home - lots of paging.

Link to comment
Share on other sites

Are overhead speakers an option?

 

http://www.cyberdata.net make a full line of SIP addressable paging systems.

 

Historically the TDM market have limited paging groups within a phone systems as the system only had a few internal intercom channels and limits on how many paging groups and extension counts. You'll find your mileage varies on those systems. but a VoIP system shouldn't be expected to overcom all limitations in older systems.

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.

 Share

×
×
  • Create New...