DarkKnight
-
Posts
15 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by DarkKnight
-
-
It could be a race condition with the loading from the file system. Especially when you have a network-mounted file system, it could be that the loading is too slow and that somehow leads to a stall in the playback procedure.
If you have a lab setup, send a email to support with the indication of your OS. It is definivively worth trying out the 3.5 build.
-----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 think the black-list would be appropriate? That would work for calls into an extension. For calls to other accounts, you could think about using a IVR node and do from-based routing.
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).
-
was there a fix?
im facing kinda same issue
i have the hunt group stage 1: 101 and 102 for 20 seconds
final stage: (800)555-1212
when someone calls into that office, the calls are on a hunt group for 20 seconds, then it goes to a autp attendant, then when they select an option from 1-0 it goes into another hunt group which works fine untill it has to get to the final stage, which i set stage 1 to be for 20 seconds then after 20 seconds the call just ends, it doesnt transfer to the extern number i entered inthe field for final stage
---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
-
Memory does not scare me in this case. It is just that the data collection of moer than 1000 CDR (lets say, 40000) takes a while during which the PBX would not process and new incoming calls. Now think about that call center which is working practically only at night, there we would have a problem.
If everybody is sleeping at this time, there is no problem.
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.
Have you seen any detrimental effects of increasing this limit? How was the value of '1000' determined?Thanks in advance.
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
-
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
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
-
Actually I set the mode of the Service Flag account to Manual and toggled the status of it between Clear and Set manually by calling it. The result is still the same.
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
-
When I hear "static" the first thing that comes to my mind is SRTP trouble. Is there a crypro heder in the SDP? If you can still hear the real audio it is not SRTP.
The PBX itself is "pure digital" and does not introduce noise into the RTP stream. Does it make a difference what you are calling? Maybe there is a audio loop if you are talking to something in the room or in the office.
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
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.
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.
No Ringback On Extension-to-Extension Calls
in Polycom Phones
Posted
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.