voipguy

bump

Hi, I'm using version 4.0.1.3438 centos. I created a service flag account called 800. I set the hours Monday to Sunday from 09:00 - 17:00 (tried using am/pm time like manual states but it doesn't work) and looked and the service flag was in the clear state. In my Agent Group account 600 (sales queue) under the Night Service: section I set the Service Flag Account to 800 and the Night Service number: to 250 #L (that was entered like 250 space #L) account 250 is just a general voicemail box. During normal business hours 9am to 5pm the #L option should send calls to the 250 account if there are no agents logged in...it doesn't work. When no agents are logged in and someone enters the sales queue they just sit there forever. Is this a bug in version 4.0.1.3438? Thanks

Not sure but if your running the Centos version of PBXNSIP maybe you could try the latest version 4.0.1.3438, it fixed a few things for me. http://pbxnsip.com/protect/pbxctrl-centos5-4.0.1.3438

Hi pbx support, This is great!!! I tested it and it works PERFECTLY!!!! Thanks.....this solves our call block billing problem and gives us more options/control over how PBXNSIP operates. Thanks

Version 4.0.1.3438 fixed this bug. Works great now. Only thing left is to increase the redirect time limit from 5 minutes to 5, 6, 7, 8, 9, 10 etc. Thanks

Thanks for the quick response. This new version also fixed a couple other bugs. Thanks

Thanks. Hope it's released soon, my employee is loosing her mind with no agent recovery time. What about the below item? Is there anyway you can make the times larger in the drop down boxes from a max of 5 minutes to 5,6,7,8,9,10 or greater? "We would like to use the "If the caller already waited longer then (s)..." then redirect them to destination X but again the max setting is 5 minutes and if a caller is in the queue for only 5 minutes we don't want to send them to the general voice mail box.....maybe 8 or 10 minutes of waiting in the queue then we would bump them into the general mail box."

Hi pbxnsip, That would be great if you guys could pass the *67......very important for companies using your Hosted version. I personally don't require any other * codes to be passed on to the dial plan but maybe don't limit it to just *67. Maybe make your code work so if it gets a * code see if it matches a * code in the domains feature code list and if no match then send the * code to the dial plan. Of course this only applies to * codes from *61 up to *99 as I think you currently reserve *00 to *60 for speed dial numbers. We don't want to mess with the speed dials. Thanks

Hi, We are using PBXNSIP version 4.0.1.3433 centos. I created a manual service flag called 800. When I pickup my SNOM 370 phone and press 800 and then hit the check mark button I don't hear any confirmation that it should play telling me it's set or not set. I know it did set it because I can see in my list of accounts in the web interface that it is set. In my logs I see it tried to play a wave file but I didn't hear anything and yes the wave file is there in the proper directory and I did play it myself to make sure. [7] 2010/03/11 18:16:19: Set packet length to 20 [6] 2010/03/11 18:16:19: Sending RTP for 3c27f4b91dec-zcptmcfl2g3b#4d696bb7a7 to 192.168.1.21:51614 [8] 2010/03/11 18:16:19: Call state for call object 318: connected [8] 2010/03/11 18:16:19: CSTA: leg=536, inbound=true, Calling=224@mysite.com, Called=800@mysite.com, State=connected, call id = [3c27f4b91dec-zcptmcfl2g3b#4d696bb7a7] [8] 2010/03/11 18:16:19: Play audio_en/bi_night_off.wav [5] 2010/03/11 18:16:19: Not setting dialog state of non-existing call port (call-id=) [9] 2010/03/11 18:16:21: SIP Rx tls:myipaddress:56585: Is this a bug in version 4? Thanks

Hi, We are using PBXNSIP version 4.0.1.3433 centos. The Call barge In *81 and Teach Mode *82 are not working. I can do *81 or *82 and the extension but the audio is all static and you can't make out what they are saying. I can do Call Listen In *83 and I can hear the two parties talking perfectly clear. Is this a bug in version 4 or a setting I have wrong? We are using SNOM 370 phones. We are also doing call recording in the Sales Queue where the two parties are talking. Thanks

Hi, We are using PBXNSIP version 4.0.1.3433 on Centos. When I pickup my SNOM 370 and dial a number I hear about 6 rings (30 seconds) and then the call gets disconnected and I see on my display a message "Request time out" and I hear a fast busy signal. I believe it's PBXNSIP that is sending the disconnect request. It's not my SIP proxy server or my termination provider. I also made a test call from a Linksys 2102 adapter with the same results so that tells me it's not the SNOM 370 phone. Is this a bug in version 4 or a setting I'm missing somewhere? Thanks

Hi, We are using PBXNSIP version 4.01.3433. We have an Agent group setup called Sales Queue with only 1 agent logged into the que. We have the Agent recovery time set to 60 seconds and the Gap between annoucements set at 30 seconds. When the agent takes a call from the Sales queue and finishes talking and hangs up the phone her phone instantly rings again with a new caller - shouldn't the Agent recovery setting give the agent 60 seconds to finish entering her notes into her CRM? Is this a bug in version 4.01.3433 or is there another setting I'm missing? Don't know if this matters but in the section called "When a call approaches the head of the queue" I have nothing set in any of the 3 boxes - the reason is because there are no other agents to move or bump the caller to a different area - even if there was the max setting in the drop down box is only 300 seconds which is only 5 minutes - that's too short - we should be able to make it what ever we want 5, 6, 7 8 minutes etc. We would like to use the "If the caller already waited longer then (s)..." then redirect them to destination X but again the max setting is 5 minutes and if a caller is in the queue for only 5 minutes we don't want to send them to the general voice mail box.....maybe 8 or 10 minutes of waiting in the queue then we would bump them into the general mail box. Thanks

Hi pbxnsip, Passing *67 along with the telephone number has no effect on my neighbor, other office users or anyone else on the PBX. It's a one time per call block per user. It has nothing to do with the trunk or turning one thing on or turning one thing off. Here's an example: If I want to call my friend Jeff at 1-416-638-1234 but I don't want him to see my caller id name and number show up on his phone then I have to block my number, to do this I would pickup my SNOM 370 phone and dial one complete string *6714166381234 PBXNSIP would then send that complete dial string to the dial plan and then the dial plan sends that complete string to the trunk and then to my own SIP proxy server, my sip proxy server sees the prefix as *67 so before it dials my friend Jeff it will change my outgoing name and number to Private Name Private Number and then it will dial 1-416-638-1234 and on Jeff's call display phone it will show Private Name Private Number. Now that's if PBXNSIP would allow me to pass the *67 to the dial plan but right now it doesn't allow that. We don't want PBXNSIP to do the call blocking, we want our own sip proxy to do it - why? - so when a call comes from PBXNSIP into our sip proxy we can see the caller id and then we know who to bill for that call, if PBXNSIP blocks the call then it comes into our sip proxy as anonymous and we won't know who to bill for that call.

Hi pbx support, Yes, please look into allowing * codes that are not configured/matched in the domains feature code list to be forwarded to the dial plan. We are using the hosted version and here are two reasons why this would benefit us and others. 1. We send all our calls to our sip proxy server that bills each call. Right now if a customer does *67 PBXNSIP blocks the call and our sip proxy doesn't know who to bill because we can't see the caller id. Now if PBXNSIP would just pass the *67 along with the number the customer dialed then our proxy server will see who the incomming call is from and know to block that customers out going name and number when we dial the destination number. 2. With the current PSTN world when a customer does *67 it only blocks the name and number for that one call - this is what customers are used to. With PBXNSIP when you do *67 it blocks all calls forever until the customer dials *68 to unblock calls. This confuses customers and causes calls to customer service which wastes our time explaining to the customer that they have to dial *68 after the call to unblock their number. I know you included a domain option to reset all blocked numbers at midnight because of this issue. This problem wouldn't exist if we did *67 on a per call basis like the PSTN world does. If a customer wants his number blocked all the time then we would just give him a dial plan that does *67 for him on every call. It would be great if this feature could make it into ver 4. Thanks

Hi pbxnsip, It's not a simple workaround. You have to think of the bigger picture. We are using the Hosted version of PBXNSIP. We want PSTN customers to switch over to the VoIP world and the PSTN customers are used to dialing *67 to block their number. *67 is nationally known as the call block code. Since PBXNSIP doesn't block the # key from being sent to the dial plan a better temporary workaround is #67 For two more reason why it would be better for the Hosted provider to control the *67 code see my next post. I see in the new Admin manual released March 8th that you "fixed" the manual on page 130/131 so it now tells you you can't send the * code.

lol....I don't think the manual needs to be fixed, I think the issue of how PBXNSIP handles * feature codes needs to be fixed. So your response indicates I am reading the manual correctly and this should work, even the PBXNSIP "Show test area" box in the dial plan screen which allows you to test your dial plan strings also works for the Pattern:\*([0-9]*)@.* replacement: sip:*\1@\d;user=phone but you think the manual needs to be fixed? Can you at least forward this bug, issue, feature request or whatever you want to call it to your coding department?

Hi pbxnsip, No, you were clear. We understand that you were trying to tell us you can't pass numbers to the dialplan if they start with a "*". The problem I have is that your own manual states you can pass numbers to the dialplan that start with a "*" symbol. For some reason the screen shot of the image I posted yesterday wont open in your forum. At the bottom of page 130 of your new manual the title is: Sending Star Codes on a Trunk "Sending Star Codes on a Trunk" "In this case, you need to use extended regular expressions: Pattern:\*([0-9]*)@.* replacement: sip:*\1@\d;user=phone The pattern matches patterns that start with a star symbol followed by any number of digits. The replacement then inserts the star again and puts the dialed number after the star." (Of course that pattern captures all * codes but we would change it so it would only capture the *67 code.) Am I reading that wrong? Even in the dial plans test area when the user enters *674166381234 on the phone/pattern side the replacement shows the correct output *674166381234 If I'm reading the manual correct then this is a bug. Also, do you not think this is a design bug? Meaning why would PBXNSIP force us to not be allowed to capture * codes on a users phone, especially with a PBXNSIP hosted edition. I know PBXNSIP uses * codes for special things like speed dials from *00 to *60 and then *61 to *99 for feature codes. But the system should be smart enough to check if the user entered *67 and *67 is not used in the feature list because I removed it then proceed to the dial plan part of the program.

Hi pbxnsip, I think this is a design bug? Your own manual on page 130/131 states the pattern can START with a star * symbol and the replacement can also contain a star symbol. See attached screen shot. I put in what your manual states: Pattern \*([0-9]*)@.* replacement sip:*\1@\d;user=phone Then in the "Show Test Area" box I inputted *674166381234 and the output box showed sip:*674166381234@d;user=phone which is what we expect and want. I then made a test call with my SNOM 370 and in my call logs it shows a 3 second call to *674166381234 but the call was never made - instead I hear the PBXNSIP voice stating this feature is not available at this time. I made sure my feature code *67 was removed before doing the tests. The reason we want to send *67 to our own sip proxy is so that we can see the incomming caller id of our customer to bill him (we bill via our sip proxu and not by PBXNSIP logs) and then when we send the call to our terminating provider we change the out going display to Private Number. This way our customers can still use the nationally known *67 call block feature code. I think this is a BIG bug in the design.