Vodia PBX Posted September 14, 2007 Author Report Posted September 14, 2007 The Explicit Remote Party ID now is just a straight, simple DID number. I you leave it empty, it automatically takes the old content "$f $a PREFIX$u DID". That means if you define the first alias it will present it. Quote
jag Posted September 14, 2007 Report Posted September 14, 2007 We need to use the facility of $2 from the second user parameter. Are you saying we can't use this anymore. AND What about the $2 in the INVITE, is this a BUG? Quote
jag Posted September 14, 2007 Report Posted September 14, 2007 The Explicit Remote Party ID now is just a straight, simple DID number. I you leave it empty, it automatically takes the old content "$f $a PREFIX$u DID". That means if you define the first alias it will present it. How do you get round the problem where we use a global trunk AND all DIDs on one domain need to be the same? You can only have 1 tel:ALIAS on the system? This is standard stuff for some companies, however in an ITSP configuration we may need the facility of allowing all (or some) DIDS to be presented as 1 DID only. Quote
joeh Posted September 18, 2007 Report Posted September 18, 2007 How Beta is this? We have a customer prone to the *87 stealing calls from their colleagues. Is it worth upgrading? Or will we be prone to more problems? Quote
Vodia PBX Posted September 18, 2007 Author Report Posted September 18, 2007 We are still testing and finding issues. So for production the latest and the greatest is still 2.0.3.1715. The latest Windows build of the day is 2.1.0.2105 (http://www.pbxnsip.com/download/pbxctrl-2.1.0.2105.exe), if you like you can try this one out and help exposing it more to the real world. We are running it already, but still have one or two tickets open that we want to close before releasing it. Once we are through with 2.1 QA, one thing is sure: This will be a great release addressing many features requests (TAPI, email spooling, G.722 and Re-INVITE, multiple mailbox messages, ...) and fixing several issues that we had in 2.0.3. Quote
joeh Posted September 18, 2007 Report Posted September 18, 2007 Once we are through with 2.1 QA, one thing is sure: This will be a great release addressing many features requests (TAPI, email spooling, G.722 and Re-INVITE, multiple mailbox messages, ...) and fixing several issues that we had in 2.0.3.. We are running it already, but still have one or two tickets open that we want to close before releasing it. I think I will take the chance! Is there a possibility you can let me know what the outstanding tickets are so I can make a risk assessment. For example, If they are issues relating to IVR\Agent-Groups, these are things the customer doesn't use so great. If they are related to call transfers, registrations, trunks etc - then that is a different thing altogether. Quote
kcnd Posted September 18, 2007 Report Posted September 18, 2007 The last Windows build available on download is 2.1.0.2103 - could you please post 2.1.0.2105 for testing? Thanks! Does 2105 fix the ACK issue for paging? Quote
Vodia PBX Posted September 18, 2007 Author Report Posted September 18, 2007 The last Windows build available on download is 2.1.0.2103 - could you please post 2.1.0.2105 for testing? Thanks! Sorry, should be there now. Does 2105 fix the ACK issue for paging? I think so. Outstanding issues (top of my head) are: (1) Some strange stuff with the mailbox when you enter the wrongpin the MB starts recording itself (?!). (2) CO-line monitoring seems to be fixed, but need to verify. (3) There is still a case where T.38 does not work (properly?) Quote
kcnd Posted September 19, 2007 Report Posted September 19, 2007 Sorry, should be there now.I think so. Outstanding issues (top of my head) are: (1) Some strange stuff with the mailbox when you enter the wrongpin the MB starts recording itself (?!). (2) CO-line monitoring seems to be fixed, but need to verify. (3) There is still a case where T.38 does not work (properly?) We are now using 2.1.0.2105 - and are testing various fixes for issues. What we found so far is: - Paging: the ACK now works to stop the source phone from ringing, however, there is no audio - still seems to be something wrong with the way pbxnsip responds to the source preventing the source from continuing (paged phones are working fine). - Previous one-way audio on multi-registered UAs is fixed. - CO line monitoring - still appears to not work (using a BLF setup - if trying to speed dialing to co6, does give error=not found, but there is no status of line) - Have problem with trunk that is set to use RFC2833 DTMF causing tones to repeat twice after initial tone. Not sure if this is a gateway (GXW-4108) issue or pbxnsip. Have to set trunk DTMF to use both in-band and SIP-info to work properly. All phones are configed to use RFC2833. Hope this helps.... Quote
joeh Posted September 19, 2007 Report Posted September 19, 2007 Bug report. I was viewing the logfile via the web interface, seleced 'Clear Log File' and the system crashed. It was logging 1000 lines, Level 9. Windows Event Log reported; Faulting application pbxctrl.exe, version 0.0.0.0, faulting module pbxctrl.exe, version 0.0.0.0, fault address 0x0016c030. This is the 2105 Version, Windows XP. Quote
kcnd Posted September 19, 2007 Report Posted September 19, 2007 V 2.1.0.2105 RFC2833 Issue There is an issue that appears on all outbound trunks (SIP registered or PSTN) when using RFC2833 DTMF with pbxnsip. The DTMF tones are repeated twice after the initial tone. For a PSTN gateway, the workaround is to use in-band and SIP-info, however, some external callers using VoIP circuits are having issues using the in-bound ACD - the DTMF is not always reliable. On a SIP registered VoIP trunk, there are no settings to control the DTMF, so we are dependent on the RFC2833 usage (my asusmption is that pbxnsip is using this method for a VoIP trunk circuit). No DTMF are receive on in-bound VoIP trunks. Any thoughts? Quote
Vodia PBX Posted September 19, 2007 Author Report Posted September 19, 2007 Faulting application pbxctrl.exe, version 0.0.0.0, faulting module pbxctrl.exe, version 0.0.0.0, fault address 0x0016c030. Yea, we changed something to make logging faster (and avoid locking out other threads), and the clear log was overlooked. Should be fixed in the next. Thanks for reporting! Quote
Vodia PBX Posted September 20, 2007 Author Report Posted September 20, 2007 Today we made another version. There was a problem with the RTP pass through and the keeping of the SSRC and the packet numbers. Fingers crossed this topic can be closed now. Maybe it was also the reason why people were reporting DTMF problems. http://www.pbxnsip.com/download/pbxctrl-2.1.0.2107.exe Quote
joeh Posted September 20, 2007 Report Posted September 20, 2007 Yea, we changed something to make logging faster (and avoid locking out other threads), and the clear log was overlooked. Should be fixed in the next. Thanks for reporting! ... Today we made another version Are the log bits fixed in this? Also customer with *87 issues reported they've picked up a calls and got silence... Whether that is because they were too slow (or should they receive a 404?) Quote
Vodia PBX Posted September 20, 2007 Author Report Posted September 20, 2007 Are the log bits fixed in this? Also customer with *87 issues reported they've picked up a calls and got silence... Whether that is because they were too slow (or should they receive a 404?) The clear log is fixed. *87 must always result in audio, if there is no pickup available then there should a IVR annoucement. Quote
kcnd Posted September 21, 2007 Report Posted September 21, 2007 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! Quote
Vodia PBX Posted September 21, 2007 Author Report Posted September 21, 2007 Well the paging stuff seems to depend on the phone type (and possible software version). What phones are you using? Quote
kcnd Posted September 21, 2007 Report Posted September 21, 2007 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. Quote
Vodia PBX Posted September 21, 2007 Author Report Posted September 21, 2007 Well the Alert-Info header is controlled by a XML file (see below). Maybe it needs to be tweaked for the GS again. But most of the phones now understand this way of Alert-Info. If you change the file, you can now re-load it through the web interface (admin/config?) to that you don't have to restart the service. <?xml version="1.0"?> <ringtones> <tone name="custom1"> <vendor ua="Polycom.*" type="alert-info">Custom 1</vendor> <vendor type="alert-info"><http://127.0.0.1/Bellcore-dr4></vendor> </tone> <tone name="custom2"> <vendor ua="Polycom.*" type="alert-info">Custom 2</vendor> <vendor type="alert-info"><http://127.0.0.1/Bellcore-dr4></vendor> </tone> <tone name="custom3"> <vendor ua="Polycom.*" type="alert-info">Custom 3</vendor> <vendor type="alert-info"><http://127.0.0.1/Bellcore-dr4></vendor> </tone> <tone name="custom4"> <vendor ua="Polycom.*" type="alert-info">Custom 4</vendor> <vendor type="alert-info"><http://127.0.0.1/Bellcore-dr4></vendor> </tone> <tone name="internal" type="internal"> <vendor ua="Polycom.*" type="alert-info">Internal</vendor> <vendor type="alert-info"><http://127.0.0.1/Bellcore-dr2></vendor> </tone> <tone name="external" type="external"> <vendor ua="Polycom.*" type="alert-info">External</vendor> <vendor><http://127.0.0.1/Bellcore-dr3></vendor> </tone> <tone name="intercom" type="intercom"> <vendor ua="Polycom.*" type="alert-info">Auto Answer</vendor> <vendor ua="Cisco-CP79.*">auto-answer=0</vendor> <vendor type="call-info"><{from-uri}>;answer-after=0</vendor> </tone> </ringtones> Quote
Kristan Posted September 24, 2007 Report Posted September 24, 2007 Just trying this RC now - auto provisioning of our Polycom IP 550 worked fine (once it was set to TFTP), but our snom360's aren't having it. Packet capture shows it pulling a file via TFTP, but the contents of it tell it to go to https://serverIP:443/provisioning/snom_3xx_...address>.xml. The phone then goes off to http://10.6.0.25/snom360/snom360-firmware.htm, gets a 302 and dies. Any ideas? Quote
isaac Posted September 24, 2007 Report Posted September 24, 2007 Loaded 2.1.0.2108 on CS410.... 1. Inband DTMF detection does not seems to be working. We are using G711u. Inband detection enabled in settings and we verified phone is correctly sending inband tones. 2. Is G729 pass thru working with CS410? Thanks. Isaac Quote
Kristan Posted September 24, 2007 Report Posted September 24, 2007 Also, the soundpoint IP 550's support G722. It looks like it's being sent as the prefered codec in the invite, but the RTP gets sent as G711.. I've not had a propper chance to look at it yet but is there anything special that needs to be done to get it working? Quote
Vodia PBX Posted September 24, 2007 Author Report Posted September 24, 2007 Inband: If you don't have to, then don't use inband. Especially on the embedded system, it cost a lot of performance to analyze the audio streams. G729 pass through. Well, it might be possible to pass G729 through, but the big problem is what happens if someone hits the hold button or parks the call. The PBX then is not able to render audio... Therefore, G729 is still still a problem. G722 is possible there, but you must edit the pbx.xml file and add the codec to the preference list (codec number is 9). We did some tests with the codec, tests show that it works-however it really has limited value as the preferred PSTN termination is FXO and that is quite the opposite of wideband audio. Quote
isaac Posted September 24, 2007 Report Posted September 24, 2007 I have no choice but to use inband unless we can get G729 support! Carrier can only support G711/inband. Inband was working on previous versions so something changed on newer version. Inband: If you don't have to, then don't use inband. Especially on the embedded system, it cost a lot of performance to analyze the audio streams. G729 pass through. Well, it might be possible to pass G729 through, but the big problem is what happens if someone hits the hold button or parks the call. The PBX then is not able to render audio... Therefore, G729 is still still a problem. G722 is possible there, but you must edit the pbx.xml file and add the codec to the preference list (codec number is 9). We did some tests with the codec, tests show that it works-however it really has limited value as the preferred PSTN termination is FXO and that is quite the opposite of wideband audio. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.