DarkKnight

All manners of Polycom phone models, using the latest firmware. This is NOT a Polycom issue: we have all manners of Polycom phones also running on pbxNsip Version 3.1.0.3031 (Linux) & Version 3.2.0.3143 (Linux) with *little-to-no instances* of this problem. Listing the Polycom models used would be wasting everyone's time and taking this issue in the exact wrong direction, and wasting more time, instead of focusing on what in these newer builds was broken.

-----The OS is Red Hat EL5. We do not run NFS, so if you mean a remotely mounted disk array--- no that is not our environment. If you mean a hosted environment, then yes that is what we have. Can you get me that 3.5 build, please?

We found a bug in the current version 3.4.0.3201 (Linux) that a significant amount of Extension-to-Extension calls on the same domain will not give ringback to the originating Extension (all the originating party hears is dead air, so the originating party has no idea what has happened to the call). In every case the destination Extension successfully rings and can pickup the Extension-to-Extension call, and the call then proceeds as normal. We have made Wireshark captures of normal calls with ringback to the originating Extension and calls where the ringback fails to be made to the originating extension. The captures show to be exactly the same. We tested the current version 3.4.0.3201 (Linux) and previous versions for this issue and found the following Extension-to-Extension ringback failure rates: Version 3.1.0.3031 (Linux) ---5% Version 3.2.0.3143 (Linux) ---3% Version 3.3.1.3177 (Linux) ---37% Version 3.4.0.3201 (Linux) ---24% This needs to work RELIABLY, this is something that has not been a problem in previous versions, yet somehow when "new" versions come out, functions that have always worked in previous versions are broken.

I read your very careful words of this reply: So you are saying the black list ONLY functions for direct-dialed calls that are sent *directly* (from the trunk) to the Extension, _ONLY_? What about inbound calls to Hunt Groups? .... This is *VERY* troubling if the black list does NOT function for inbound calls to Hunt Groups. Can you add this as a feature so the Black List functions for the Hunt Groups, Auto-Attendants, and Agent Groups as well, PLEASE? It's very silly not to have the Black List function as a global feature as many businesses use these other objects (Hunt Groups, Auto-Attendants, and Agent Groups) to answer inbound calls, and this leaves them literally defenseless against someone who wants to harass them, intentionally or unintentionally (FAX machine set to call the wrong number).

---Yes, for me, jag's reply worked, which was: This sounds like you have reached the max number of redirects allowed. This is a feature to stop run-away calls from looping and looping. To fix this.... Stop the service Go to the Working Directory of the PBX Edit pbx.xml Look for the XML setting max_loop Change it to the required value Start the service. That should do it. ----My version had the "max_loop" default value set at 10, and I changed it to 15, and that has worked ever since, for even more complicated scenarios than what you described. ----Oh yeah, just so you know, in your scenario, you cannot put a external telephone number in at the final stage....it does not work that way. Instead, you have to put in an Extension number that has been set to have your external telephone number in the "Call Forward All Calls To:" field (under the Redirection tab) for that Extension you're using as the "Redirection Extension." Hope this helps.

I have searched high and low, but have yet to find this information in the wiki or anywhere: Can anyone please definitively explain what the Agent Group CDR statistics *mean*? I'm really amazed that nowhere in this forum or wiki they are defined. They are not intuitive, and statistics without any defined meanings behind them are completely useless. It's a waste of time to try to guess what these things mean. Specifically, I am using version 3.2.0.3144 (Win32), and the stats for Agent Groups are shown to be: Time / From / To / Agent / "Waiting Time" / "Ring Time" / "Talk Time" / "(Hold Time)" I and I am sure many other people would like to know, once and for all, what these mean: "Waiting Time" "Ring Time" "Talk Time" "(Hold Time)" I need to know from what "Point A" event occurs to start when this is timed to what "Point B" event. Not knowing their definitions leave many questions unanswered; For Example: "Waiting Time" --- Is this the total time it takes for a call to reach a agent, or just the time waiting on hold? If it's the time waiting on hold, then what does the "hold time" mean? "Ring Time" ---- Is this total time for rings for the entire call, or just when they got to the queue, or what? "Talk Time" ---- Is this measured from what milestones? Entering the queue, or just talking with an agent only, or what? "(Hold Time)" --- Hold time from when? Is this when the AGENT puts the caller on hold, or how long the Caller has been in the queue, or what? As you can see, with no definitions out there for these stats, they're just numbers. Thanks in advance!

I'm using version 2.1.14.2498 (Linux) and 2.1.6.2450 (Win32), and have found a possible bug: If you have a Hunt Group's final stage kick to a Auto-Attendant, and then choose a Direct Destination choice off that Auto-Attendant to direct you to a 2nd Hunt Group, the 2nd Hunt Group seems to work, except the call is disconnected before it reaches the Final Stage of the 2nd Hunt Group (in this case just a General VM box - i.e., an Extension with a Voicemail box but no phone registered on it). We have tried several ways around this, but get the same result on both versions. Has anyone else experienced this? Any workaround for it? Is there planning to be a patch made for it in version 3.0 or later? Thanks in advance! DK

Unfortunately, a couple of my Customers do a large volume of calls at night (the majority of their calls over 1000), so I suppose there will be problems. Those Customers individually do not reach the 10,000 call mark per day, however. So is this feature going to be "fixed" in version 3.0?

QUOTE(pbxnsip @ Feb 9 2008, 03:48 AM) <{POST_SNAPBACK}> 2.1.6 already has a setting called "cdr_email_size" (invisible global setting in pbx.xml) - see http://wiki.pbxnsip.com/index.php/Global_Configuration_File. Check out http://www.pbxnsip.com/protect/pbxctrl-2.1.6.2441.exe if you like. Hey, I've got several Customers chomping at the bit to have this feature increased beyond 1000 also since they have a high volume of calls and are very unhappy when the report they get is only for the last 1000 calls. If it does cause detrimental effects to increase the number beyond 1000, like it takes up more of the server's memory until it is finally generated at midnight each night, I would think you already have the tools you need to set it up so that the server emails the CDR (and clears the memory that it was occupying) every time it reaches 1000 in a calendar day, and then goes until it reaches 1000 again and emails that list, and so on, and repeats the process for however many thousand calls per day until it reaches midnight. If memory is a problem, wouldn't that be a sensible solution? Please comment on this issue. As always, thanks in advance! DK

Speaking of which, I have had 2 Customers now that have found this feature themselves through the Web Interface and want this feature to function properly (right now it does not function at all). Can someone please reply on this issue? Any timeline on when we can expect this to be patched? Thanks! DK

I second that emotion; my time is correct, and I even tried setting the hours to GMT times on a lark, but the result is the same: The cell phone is called no matter what time frames I enter into for the Service Flag on the Redirection screen in an individual Extension. I'm using 2.1.12.2489 (Linux). DK

Hi, I am using Version 2.1.12.2489 (Linux) and I have found a VM-to-Email Email Timestamp Bug. The bug is in the timestamp of the "Sent:" field of the VM-to-Email Email you receive from Pbx-n-Sip, the time is set to GMT (Greenwich Mean Time) and ignores the "General: Timezone:" setting on the Admin System Settings page. The timestamp accessed through the web interface or through the phone itself is correct and unaffected. And, of course, you have your mail program's report on when the email was received, but seeing the email come from 5 hours in the future without annotation of GMT makes you do a double-take. (I'm in Central Time Zone.) I would rather it just show the correct time. I was able to double-check this by using an older version. Is this a known bug? Will this be addressed in the next release? Also, why would this be handled with no problems in earlier versions but somehow become an issue an more "advanced version" -- I thought this fundamental and "old hat" part of things was held down tight already.... or when you make advances you "blow up the code" (including things that WORKED normally) in order to do so? Please let me know what has happened with this one. Thanks! DK

Hi, I am using version 2.1.11.2484, and I think I have found a bug when trying to transfer (move) a voicemail from one extension to another ( hitting 6 while in voicemail ). When you have extension numbers of different lengths in the same domain, it pbxnsip appears to default to only allow transfer (move) of a voicemail to extensions of the shortest length if there is a extension that matches that is of that shorter extension length. For example, for 3-digit extensions, I can transfer (move) voicemail from one 3-digit extension to another 3-digit extension. Likewise I can transfer (move) voicemail from one 4-digit extension to another 4-digit extension. However, when I have a domain of 3-digit and 4-digit extensions, when you try to transfer (move) a voicemail from either a 3-digit or 4-digit extension to a 4-digit extension, pbxnsip takes the first 3 digits if they match an extension number and then asks you if you want to send the mail to that extension and doesn't give you the opportunity to put in the 4th digit. For instance, if you have an Extension 250 and Extensions 2500 through 2509 on the same domain, you can never transfer (move) a voicemail to Extensions 2500 through 2509 from any extension, since the server matches for Extension 250 before you have a chance to put in the 4th digit. Is this a known bug? Are there any workarounds? I have scoured this board for it before I posted, but if it is mentioned, it is well-hidden, kind of like this bug being well-hidden, if that's what it is. I appreciate your input ahead of time! Thanks! DK

It does not follow any pattern; it has happened on cell phones, land lines, phones with hard-wired handsets, speakerphones, cordless phones, anything, from as best I can tell.

Hey, I've got a Polycom Soundstation IP 4000 (the triangular conferencing phone) running Application version 2.2.0.0047 being used with pbxnsip version 1.5.1.6 . The problem I'm coming across is on calls that are inbound or outbound, local-land-line, long-distance-land-line, or cell, after 4-5 minutes (but sometimes longer), the call on the other end with this Polycom 4000 will be overwhelmed by static that grows gradually to be so loud that the static becomes louder than the normal audio, and the call becomes unusable after that point. The issue is not constant, but does not occur on other Polycom 501 phones I'm using (using Application version 1.6.5 or 1.6.7) on the same domain on that 1.5.1.6 pbxnsip box. It's not as if the normal audio is cut out or lost or otherwise garbled or dropped, it's that the static just becomes louder than the audio of the conversation. Is this a potential compatibility issue between a Polycom Soundstation IP 4000 Application version 2.2.0.0047 being used with pbxnsip version 1.5.1.6 or is there something else going on? Thanks! DK