Jump to content

voipguy

Members
  • Posts

    293
  • Joined

  • Last visited

Everything posted by voipguy

  1. I loaded ver 4.0.1.3475 which is a big jump from 4.0.1.3452 but I don't see anything different in any of the screens. Can you tell us what's new or fixed so we can test it? You guys are doing a great job.
  2. I loaded the latest ver 4.0.1.3475 but this bug still exists. We need this fixed ASAP - we run a hosted service and our end users login to the web interface and click on the feature list to see what codes enable different features - this bug is not loading the *?? code beside the name of the feature - it's just blank - even though when I login as admin and look at the domain feature codes the *?? is beside the feature name. This alos broke the listing of feature codes when you use PAC - click on the Feature Codes button and it doesn't display any of the feature names except for "Agent logged in: *64" but it lists all the *?? codes - just no feature names to the left. Thanks
  3. Hi pbxnsip, Ok so *601 is the 3 digit code that PBXNSIP uses to grab a call....the numbers behind the *601(call number) is the actual call that we are trying to grab...I can confirm 100% that the call we are trying to grab is still there waiting to be grabbed but this is a bug - we get a not found message on our phone and we can see the person is still waiting in the queue because the led is still flashing and we can also see via the web status that the caller is still there. We try to press the flashing led button again and we see our phone tries the same thing *601(call number) but we get a not found. Once the *601 bug is fixed - where it actual works and grabs the caller waiting when you press the flashiing LED then the chances of this second problem you described happening would be very few if any. Meaning when the led is flashing which means the caller is waiting and I go to press that led button the caller would have to hangup a split second before I finish pressing the led button for that caller to not be in the PBXNSIP system anymore and then the *601(call number) would be passed to the dial plan and return with the not found message. I think if you get the *601 working that nobody would even notice the second problem because it probably wouldn't happen or not happen that often. Thanks
  4. Loaded ver 4.0.1.3456 and this bug is now fixed. Thanks
  5. Loaded ver 4.0.1.3456 and this bug still exists. SNOM 370 button number 9 is programmed as an agent group with the value 600 which is the Sales Q....when the led flashes that means a caller is waiting in the sales q - my agent picks up her snom 370 and then presses the flashing led button and the call should come to her - it doesn't - she gets a message on her phone - "not found *60134" What does *60134 mean? probably the *60 is the PBXNSIP internal code that is used to grab the call and the numbers after it 134 is the ID or current call in the system - so if another caller is waiting it will be 135 and so on. It looks like PBXNSIP is trying to pass the *60 and the 134 to the dial plan which returns not found - I think this bug was introuduced when the source code was changed to allow passing * star codes to the dial plan. I thought *00 to *60 is used for speed dial numbers? PBXNSIP - please test this and confirm it's a bug. Thanks
  6. I'm now using the new version 4.0.1.3456 but the above problem hasn't been fixed yet.
  7. PBXNSIP - can you try my above example? I believe it's a bug and should be fixed. Thanks
  8. Please have extension 40 make an external call to the PSTN world and talk to someone.....now look in the extension 40 call recording sub directory and you should see 2 wave files for that call - 1 marked with a i and one with a o. I'm also using codec G729 and I know your test system is G711 - please set it to G729 just so it's same as my test. Thanks
  9. Hi pbxnsip, I think we went way off track with this post. This post is to report a specfic NEW bug in version 4.0.1.3452. This is not 2 users in my system with call recording turned on calling each other which would make 2 recorded wave files. I have 1 person with recording turned on and people from the outside/PSTN world that call my employee - now with this version for that 1 incomming call it is making 2 wave file recordings for the 1 incomming call and marks 1 wave file as inbound and marks the other wave file as outbound. I think when someone takes the time to test beta software and reports bugs and gives details that PBXNSIP should test the call setup and see if can duplicate the bug - then we know if it's a bug or not. But posting back and forth for a week doesn't prove anything - you have to test the described call setup and see if you can duplicate the bug. I went back to ver 4.0.1.3446 3 hours after I noticed the duplicate call recordings - now it's not recording 2 wave files for each call. Maybe it's just a glitch in my system but one way to prove if it's a bug or not is for PBXNSIP to test it. Thanks
  10. Can you explain that a little bit more? I don't understand but would like to fix this ASAP. Thanks
  11. We were using the last publically posted version 4.0.1.3446. Rate table? where's the rate table located?
  12. That doesn't make any sence? Your either making an outbound call or your receiving an inbound call - the bug is 2 recordings for the same exact call wether it was an inbound call or an outbound call. Soon as we went back to ver 4.0.1.3446 the problem went away - we never changed any other settings - we only went from 4.0.1.3452 back to 4.0.1.3446 and now it only has 1 recording for each call. Here are my call recording settings: 1. Domain = record no calls for anything - that's the default 2. Sales Queue - Record incomming calls to agent group = On 3. For extension 332: Record incoming calls to extension: On Record outgoing calls to internal numbers: default Record outgoing calls to external numbers: ON Record outgoing calls to emergency numbers: default When I use ver 4.0.1.3452 I can see in the sub folder for extension 332 that there are 2 call recordings for each call - an inbound and an outboud and the call recording audio is identical in both wave files - and the person did not make or recieve 2 calls.
  13. Hi, We are using version 4.0.1.3452, hosted pro +, centos, G729 codec. Today we went from 4.0.1.3446 to the new 4.0.1.3452 and now every call is being recorded twice. We have call recording turned on for certain extensions, q's and now we can see in the file system 2 wave files for every call being recorded - one wave file shows i for inbound and the duplicate call recording wave file has a o in the file name for outbound - we listened to many of the wave files and they are duplicate call recordings. For right now we are going back to version 4.0.1.3446. Can you confirm this is a bug? Thanks
  14. I'm now using the latest and greatest 4.0.1.3452 but didn't notice anything new in it? I looked at all the screens....can you let us know so we can test it? Thanks
  15. Is there a quick fix until you sync them? We are running the hosted version and don't want our customers to see the orig PBXNSIP name/logo. Thanks
  16. Hi mattlandis, We know about the *87 but that's not what were trying to do. We have a specfic extension or agent group programmed into a button on our snom phone....when it flashes we should be able to press it and the call comes to our phone - it doesn't work.
  17. Hi pbxnsip, There's no sip aware firewall. I think this is a bug in version 4.0.1.3446.....just give it a try and see if you get the same results. I think this bug is because of the change in your code when you allowed * feature codes to be passed to the dial plan (it's a great feature - please don't remove it). When I press the SNOM370 programmed button it dials a * code for us to pickup that call - the code it's trying to dial is *60 and then the call number which I think is 4 digits, the *60 must be the PBXNSIP "special" internal * code to pick up these calls from programmed buttons on SNOM phones or other voip phones - the problem is PBXNSIP passes the *60(4 digit call number) to the dial plan and then to my proxy server...I can see in my proxy server logs it's trying to dial *60(and 4 digit call number). It's hard to describe and I find myself repeating it but basicaly since you changed your program source code to allow us to pass user * codes from the users phone to the dial plan if that * code is not listed in the feature code list for that domain. So *60 is not in the feature code list so PBXNSIP thinks it should pass the *60(plus 4 digit call number) to the dial plan but in fact *60 must be PBXNSIP's special internal code that allows a programmed button in a snom or voip phone to pickup a ringing ect or a call from the agent group if you have a button programmed to monitor a agent group. Give it a try and I think you'll end up with the same result. 1. Program a button in a SNOM phone as an Agent Group. 2. Make sure all your permissions are set properly. 3. Have someone call the Q so you can see the Snom Agent Group LED flash. 4. Now pickup your hand set and press the programmed Agent Group LED....you will see in your display *604digit number - the 4 or 5 digit number is the current call number in the system. After pressing the Agent Group LED button PBXNSIP should connect the person that's in the Q to your phone - but it doesn't. PBXNSIP will pass the full *604digit call number to the dial plan and your phone might say not found - I'm using a proxy server so PBXNSIP passes the *604digit call number to my proxy server and my proxy server reports back to PBXNSIP not found because *604digit number is not a telephone number. All of the above is just my guess on the possible reason for this bug if it's even a bug. pbxnsip - please try it and let us know. Thanks
  18. Hi pbxnsip, I think you might have misunderstood my post. Any version before 4.0.1.3446 such as ver 4.0.1.3442 or 4.0.1.3438 lists all the feature codes in the end users web screen under lists under feature codes....soon as I went from 4.0.1.3442 to 4.0.1.3446 the name of the feature is there in the list but the * code is not displayed beside it....the feature or * code is not new - they have been in the feature list going back to ver 3.4. I think this is a bug that was created in ver 4.0.1.3446 - take a look for yourself...login as a end user and look at your feature list - you will be missing some * codes - even though they are present when you login as admin you can see they are all there.
  19. Hi, Were using ver 4.0.1.3446 hosted pro +, G729, centos 64 bit I noticed with version 4.0.1.3446 that when a user logs in then clicks on Lists, then clicks on features codes it will display the feature codes but now it's missing a few codes. When I login as admin and check the feature code list for that domain the codes are there - only when you login as a user do some of the codes disappear. Missing feature codes: 1. Call return 2. Hot desking 3. Forward calls to domain accounts 4. Send voicemails deactivate 5. Agent logout 6. Record off key On a side note can your remove the words (e.g. *12) and (e.g. *13) from the right of Record On key: and Record Off Key: it's just confusing people - we don't use *12 or *13 for the record on/off feature - we use what the manual states *93 and *94 but I can see our customers are trying to use *12 and *13 per the log files - even though to the right we have *93 and *94 as the code to use. Thanks,
  20. Hi, Were using ver 4.0.1.3446 hosted pro +, G729, centos 64 bit We setup our buttons on the SNOM370. We have button 7 setup as monitor extension - it works - we can see it flash/go solid etc...in the manual it states if that LED is flashing fast then that means a call is comming in on that extension and you can press the button to take/intercept the call - it doesn't work. When I press that button I see in my display *601875 bad request...same thing with button 8 - we have it setup as Agent group - when it flashes I press the button and it shows in my display *601878....I guess the last 4 digits after *60 must be the call number as it keeps increasing. I have all the permissions setup correct - can you test on your end and let me know if it's a bug in ver 4? Thanks
×
×
  • Create New...