kcnd

UPDATE: For those who may need to setup BLF on Grandstream phones (f/w version 1.1.6.46) with pbxnsip version 3 software, these settings will work properly: 1) In pbxnsip on the extensions general tab, set the "watch calls for these extensions..." to "*" (an asterik) - this is required to "turn on" dialogs - without this, dialogs will not register. 2) On the Grandstream phone under the account tab, enter the account's extension in the "eventlist BLF URI" field - do not enter the domain, just the extension used in pbxnsip for that account 3) On the Grandstream phone under the basic tab, for each key to setup select "eventlist BLF" for the type and enter the extension along with the account from #1 above This will cause a single dialog registration to record in pbxnsip for the BLF eventlist extension number and the BLF keys will light correctly. This took quite a long time to figure out since version 2 of pbxnsip worked with Grandstream phones by simply selecting the normal BLF selection on the Grandstream phone (no changes were required in pbxnsip, and each BLF key would register a dialog in pbxnsip. Version 3 has somehow changed this so only the eventlist scenario will work. When trying the standard BLF selection, the "dialing" and "in-call" status would display but the key would never reset to "idle".

After doing more testing it appears there is an error in the "Watch calls..." feature of the pbxnsip. The Grandstream phones, configured properly for BLF, work fine, however, pbxnsip does not set the BLF properly. To get any BLF to work, the pbxnsip web interface option of "Watch the calls of the following extensions (* for all):" must be set with something entered in it. Then the phones will register the dialog entries for each BLF, but the phones are receiving only the "off-hook" and "in-call" status - they do not receive the "on-hook" (green) status. The "Watch calls" field can contain an "*", a valid extension or an invalid extension like 999 that is not setup in the system to trigger the dialog registrations for all BLF keys set on the phone. Even if the "Watch calls" field is set to only one extension, the phone will register all dialogs and all BLF indicators will act as described above. In version 2, the "Watch call" field defaulted to all extensions, so no special setup was required for the extension to handle BLF. If the phone was configure properly for BLF, it would work. Based on all I've seen, something is not working properly with the "Watch call" code in pbxnsip. Can something be done to fix this? Our users are getting quite frustrated as this has been an issue for 4 months since we changed from version 2 to version 3. Thanks for your help!

I don't believe this is an appropirate place to discuss the Grandstream appliance.

We using Grandstream GXP-2000, GXP-2010 and GXP-2020 sip phones (with latest firmware version 1.1.6.46) with pbxnsip version 3.3.1.3177 and have them configured to use BLF keys. The pbxnsip extension setting for monitoring other extensions is set to * so it monitors all (never had to set this in pbxnsip version 2). The phones register with pbxnsip and also register the dialog entries for each BLF key fine. The BLF lamps will flash red when a monitored phone is calling and will change to solid red when in a call. However, the BLF lights will never change to green when the call ends. In fact, the BLF lamps will not light green even when the phone is first rebooted and we wait to see if the dialog registration picks up the status of idle extensions. Note that the phone BLF lamps work fine when connected to a Grandstream PBX appliance and the phones diagnostic test show all BLF lamps are good. Also, these same phones worked fine with pbxnsip version 2 software. I'm aware that the BLF process in version 3 was changed, but apparently this change is not compatible or has some issue with GXP phones. IS there some way you can test the GXP phones with the latest pbxnsip software and figure out how to get the BLF lights working again? I've been unsuccessful at trying many different configuration options with the phones and pbxnsip. Is there some configuration that needs to be specifically set now for BLF to work with GXP phones? Thanks!

Issues discovered with 3.1.2.3120 Using this version, calls coming into an ACD/IVR account will not accept DTMF entry (using a Grandstream 4108 FXO for trunking). The last version that worked is 3.1.1.3101 which is what we have had to go back to. DTMF works fine for eveyhting else - just the ACD/IVR will not work. Issues discovered with 3.1 - any version Changes made to the handling of BLF notifaction to phones does not work with Grandstream phones (firmware 1.1.6.44 - latest release - or any earlier release). This always worked fine with version 2 software. BLF lamps will not work at all unless an * is placed in the extensions "Watch calls of the following extensions" and then the lamps will light with an initial status but never update again - i..e they light red or flashing red but never chnge status again. These same phones will work with version 2 software fine. Option to turn off cell phone linkage Is there an option in version 3 to turn off the cell phone linkage that detects a caller coming into the system via their cell phone and prompting different than the stadnard in-bound call paths? Thanks for your help!

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

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.

Never tried to use recording - in the demo or after receiving the license. I assume our 50 user license does not include recording since the general set up page does include the fields for setting the record star codes. We use Grandstream phones which do not have a record button. Are there other settings that I may need to turn off for recording a call? (possibley just in the INI file?) I've looked all through our settings and could not find anyhting that would turn this off. There is a recroding duration which is currently set to 1800. Thanks again for the help.

We are using ver. 2.1.3 and are running into an issue with voice mail recordings. Sometimes, when a call is transfered to an extension to allow the caller to levae a voice mial, the voice mail includes the entire call - from the time the call was answered, through the transfer and including the callers voice mail message. This is occurs randomly. Is there something that cna be done to prevent this? Maybe a setting we've missed? Note that the upgrade to ver. 2.1.3 was done by replacing the pbxctlr file - are there any setting in teh INI file we need to make sure are updated for the new version? We were hesitant to run a full install - not sure if the full install would keep all the current settings. If a full install would help cure the issue above, we can try that. Is there anyhting special we need to watch for on a version install over a previous verion? Thanks for your help.

We are using GXP-2000 and GXP-2020 (f/w: 1.1.5.15) phones with pbxnsip (2.1.2.2292) and have run into an issue that has been occuring sporadiaclly in version 2.x of pbxnsip. Every so often, when a person answers a call, the caller cannot hear the the person on the GXP, but the GXP user can hear the caller. Hanging up and having the caller re-call then works. This is in-frequent and tough to troubleshoot. We use the 711 codec on all devices and these extensions are connected to the same network as the server with pbxnsip. Another similar issue is that sometimes when a GXP user tries to place a call, nothing will happen. Hanging up and trying again will work. The phones are registered correctly and I cannot find any lost packets or other issues on the network. The only thing I suspect is that the pbxnsip server has a local netowrk connection and a connection to the DMZ for allowing ourside phones to connect. Since there does not appear to be any controls in pbxnsip for the dual netowrk connections, is it possible pbxnsip is getting confused with the dual network connections? I've dissabled the DMZ connection for now to see if this still occurs. Any ideas?

We are using GXP-2000 and GXP-2020 (f/w: 1.1.5.15) phones with pbxnsip (2.1.2.2292) and have run into an issue that just started ocurring after upgrading to the 2.1.2 version. When the receptionist transfers a call to another extension, the next call that comes to the receptionist also rings the phone from the last transfer. The receptionist uses a GXP-2000 phone and the typical transfer is to a GXP-2020. Any ideas?

From our limited experience so far, having 42 extensions, 64 accounts, a 7 line PSTN gateway trunk and a SIP trunk, and running about 200+ calls per day, pbxnsip will do fine with a strong server and network behind it. The main thing to insure is to have good phones - the phones will make or break the user experience - if they genereate echo (becuase of speakerphone quality) or have issues using pbxnsip features, then the user community will losse confidence in the system. Another key to watch for is the gateway - make sure it is rock solid and configured properly to any PSTN lines - we had a tough time at first getting the line termination and gain worked out to minimize echo and jitter. I concur with Yori's findings as well. We have been using Grandstream devices (phones and gateway) and while we've been able to get the gateway to stabilze, the phones (GXP-2020 series and GXP-2000 series) are causing much trouble with echo (speakerphone issues). We went this way based on initial testing and price/performcne, but after "real" use, the performance is not there - yet. We are now beginning the process of testing other phones - at a higher price point. Hope this helps....

Paging is now working with relaease 2108 - I'm not sure what changed, but all is well now. I did not have to apply a new ringtones.xml file. No issues came up from using 2108 under a normal business day on Friday, so it appears to be stable at this point. Have not had any more issues with DTMF and some of the echo issues we were experiencing have gone away (still have other echo issues related ot he phone devices, but pbxnsip appears to be clean). ALso, some feedback on performance: we are using a server with two dual-core Xeon 3 Ghz processors, 4 GB RAM and 1GB NIC with Windows Server 2003 R2. One of the eight virutal processors is dedicated to pbxnsip via affinity control. Under typicall business office call loading, we see no more than 5% CPU utilization and 15% network utilization (several hundered calls per day with 25 key uesrs and 35 total users; 7 PSTN lines via a gateway with as many as 5 in use at any one time). Even under unicast paging of 25 phones, the CPU utilization doesn't spike higher than 15%. Seems release 2108 is quite efficient.

We are currently using Grandstream GXP-2020 and GXP-2000 phones, firmware version 1.1.4.22. Back several versions of pbxnsip (don't have a note of which earlier version), the paging would work, however, the source phone just kept ringing. The source phone ringing is now fixed, just having an issue with the audio. I'll be doing more testing to see if I can find anything more specific. In the mean time, if you can point out anything specific to look for, I can do that as well. Since the phones work for Intercom, I would suspect this to be something with pbxnsip.

Results of testing 2.1.0.2107 (so far): - DTMF issue fixed on all lines - works with RFC2833 correctly - Paging still does not work: all paged phones answer and wait; source phone is ready but no audio is sent; when source hangs up, all phones hang up (we really need this one fixed) - Log file clears fine - No other issues noticed at this time - will have heavier use tomorrow. What can we do to get the paging fixed? Thanks for the quick resolution to issue as they arise!