Jump to content

Recommended Posts

Posted

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.

  • Replies 70
  • Created
  • Last Reply

Top Posters In This Topic

Posted

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?

Posted
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.

Posted

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.

Posted
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.

Posted
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?)

Posted
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....

Posted

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.

Posted

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?

Posted
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!

Posted
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?)

Posted
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.

Posted

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!

Posted

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.

Posted

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>

Posted

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?

Posted

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

Posted

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?

Posted

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.

Posted

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.

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...