Get ready for 3.0

[Vodia PBX]

We are getting ready for the next major release - 3.0. The image seems to be pretty stable now, the next action item missing is the release notes and then updating the Wiki. For those who can't wait and want to get the latest and greatest you are welcome to grab the Windows build at:

 

http://pbxnsip.com/protect/pbxctrl-3.0.0.2994.exe

 

The license keys for version 2 also work on version 3. When doing an upgrade, it is a good opportunity to make a backup of the 2.0 directory, just in case that you decide to roll back. The upgrade itself should work automatically.

 

Important things to consider when doing the upgrade (so far):

• The tel:alias semantics has changed. Tel:alias is only used for inbound calls, and only if the trunk is marked as a "global" trunk (that was a security fix that we also applied to version 2.14). For outbound caller-ID representation, we added a field ANI that can be assigned on account basis.
  
• We will post other important upgrade issues here as we find them.
  

[R. Baltzer]

Hi,

 

I have installed the 3.0.0.2994 version and it looks like my language settings are not working anymore for the snom phones.

I had placed the files Snom_gui_lang.xml and Snom_web_lang.xml into the html directory and the gui_lang_NL.xml together with the web_lang_NL.xml files into the html\snom subdirectory. After resetting the snom phones they now are comming back with the english language.

 

Any ideas how to fix this?

 

Kind regards,

 

Rene.

[Vodia PBX]

I have installed the 3.0.0.2994 version and it looks like my language settings are not working anymore for the snom phones.

I had placed the files Snom_gui_lang.xml and Snom_web_lang.xml into the html directory and the gui_lang_NL.xml together with the web_lang_NL.xml files into the html\snom subdirectory. After resetting the snom phones they now are comming back with the english language.

 

Two things... The first thing is that obviously something was broken and the language provisioning for snom wasn't working out of the box (that should be fixed in the next build).

 

The other thing is that the automatic provisioning works only for languages that are available as web interface languages. That might be insufficient. Maybe we have to introduce a PnP parameter for this (though I really like the idea of controlling that through the vendor-independent language settings for the account).

[hosted]

What is the ANI field for in the hunt group?

 

also, can you add a beep when you intercom/page someone? people have been complaining about not being alerted.

[Vodia PBX]

What is the ANI field for in the hunt group?

That's when the hunt group redirects a call to the outside world. Depending on the on the caller-ID presentation, you need that.

 

also, can you add a beep when you intercom/page someone? people have been complaining about not being alerted.

 

IMHO that is clearly the job of the phone.

[R. Baltzer]

Two things... The first thing is that obviously something was broken and the language provisioning for snom wasn't working out of the box (that should be fixed in the next build).

 

The other thing is that the automatic provisioning works only for languages that are available as web interface languages. That might be insufficient. Maybe we have to introduce a PnP parameter for this (though I really like the idea of controlling that through the vendor-independent language settings for the account).

 

 

Ok, then I will wait for the next build......for us it is important to provide the phones with the dutch language.

 

Kind regards,

 

Rene.

[hosted]

IMHO that is clearly the job of the phone.

 

It seems easier and much more efficient if the PBX did this. Simply playing a beep instead of having to fittle with fifty different phone types.

[jag]

[*]The tel:alias semantics has changed. Tel:alias is only used for inbound calls, and only if the trunk is marked as a "global" trunk (that was a security fix that we also applied to version 2.14). For outbound caller-ID representation, we added a field ANI that can be assigned on account basis.

 

Currently on a hosted server, extensions may call each other in different domains by using the TEL:alias. So domain2.com has a TEL:alias of 123456789, user in domains1.com dials 123456789, the call goes to the extension in domain2.com (it remains on-net and is classed as an internal call).

 

Does this security fix prevent this current functionality from working?

 

ANI....

 

The old logic for Caller-id was as follows:

 

Present Caller-id of a redirected call

Present the value set in paramenter 2

Present the TEL:alias

 

Does the ANI functionality over rule the 'old' TEL:alias functionality?

Does the first two stages continue to be used?

[Vodia PBX]

Currently on a hosted server, extensions may call each other in different domains by using the TEL:alias. So domain2.com has a TEL:alias of 123456789, user in domains1.com dials 123456789, the call goes to the extension in domain2.com (it remains on-net and is classed as an internal call).

 

Does this security fix prevent this current functionality from working?

 

In a hosted environment, you cannot assume that a tel:alias is on a specific server. There is usually a server farm, and then you must resolve the name by using a trunk anyway. tel:-alias matching makes sense only for inbound calls that come from a global trunk.

[jag]

In a hosted environment, you cannot assume that a tel:alias is on a specific server. There is usually a server farm, and then you must resolve the name by using a trunk anyway. tel:-alias matching makes sense only for inbound calls that come from a global trunk.

 

That will break backward compatability with the product deployed in the field now. This is how currently it works, you allowed for domain to domain calling in V2 and now customers will not be able to do that as of V3.

 

Can you answer the ANI question please?

[Vodia PBX]

That will break backward compatability with the product deployed in the field now. This is how currently it works, you allowed for domain to domain calling in V2 and now customers will not be able to do that as of V3.

 

Well, as said above in a server farm you cannot assume that a specific domain is physically on the same server. If that was possible in 2.0, then call it a bug.

 

Needless to say, it caused a lot of problems to have one call in two domains.

 

Can you answer the ANI question please?

 

We have to document the ANI topic on the Wiki, answering that question here is the wrong place.

[jlumby]

The version of 3.0.0.2997 posted on the PBXnSIP web site for download to the CS410 is not in english. Is there a setting I am missing?

[Vodia PBX]

The version of 3.0.0.2997 posted on the PBXnSIP web site for download to the CS410 is not in english. Is there a setting I am missing?

 

Ehh. Yepp, little problem (you can improve your Dutch with that version). Go for 3.0.0.2998.

[olecoot]

I have a small issue

 

I downloaded what I thought was version 2.1.14.2498.exe on Friday morning (08-22-2008) for a normal upgrade. This was the full exe, not the pbxctl upgrade. I went through the normal routine of installation and was asked to reboot. I couldn't do that because it is a hosted environment and getting close to business hours. The restart of the server (Windows 2003 Enterprise) was scheduled for this morning (Sunday 8-24-2008).

 

Imagine my surprise when bingo! there is version 3.0!!!!!!! I double checked the exe thinking I downloaded the wrong one but it is labeled 2.1.14.2498.exe. How did this happen?? We do not like to deploy a new version unless it is fully tested on our test server. Now I have an untested version of PBXnSIP in the field.

 

What type of issues am I to expect if I attempt to downgrade?

 

In the future, disable the download page until all of the links are correct and tested.

[Vodia PBX]

I have a small issue

 

I downloaded what I thought was version 2.1.14.2498.exe on Friday morning (08-22-2008) for a normal upgrade. This was the full exe, not the pbxctl upgrade. I went through the normal routine of installation and was asked to reboot. I couldn't do that because it is a hosted environment and getting close to business hours. The restart of the server (Windows 2003 Enterprise) was scheduled for this morning (Sunday 8-24-2008).

 

Imagine my surprise when bingo! there is version 3.0!!!!!!! I double checked the exe thinking I downloaded the wrong one but it is labeled 2.1.14.2498.exe. How did this happen?? We do not like to deploy a new version unless it is fully tested on our test server. Now I have an untested version of PBXnSIP in the field.

 

What type of issues am I to expect if I attempt to downgrade?

 

In the future, disable the download page until all of the links are correct and tested.

 

There was obviously something wrong in the deployment process. The installer is the same between 2 and 3, seems something got mixed up. I suggest to make a backup of the directory and perform a manual down-grade to 2.1.14. The downgrade should work seamless, I cannot think about anything that would cause an issue.

 

We replaced the installer. should be the right one now (I verified it!).

[olecoot]

Fair enough! Thank you.

 

I receive these email messages "Source address for sip:102@<somedomain>.com has changed to udp:<ipaddress>:6702" How do I disable the email alerts without disabling other alerts and emails that I receive as admin?

 

Thanks in advance

[Vodia PBX]

Fair enough! Thank you.

 

I receive these email messages "Source address for sip:102@<somedomain>.com has changed to udp:<ipaddress>:6702" How do I disable the email alerts without disabling other alerts and emails that I receive as admin?

 

Well first of all this is a event that you should check. Typically it is a sign that the extension is behind a router that is not suitable for SIP.

 

In 2.1 the only way you can get rid of these messages is to use a rule on your email client that moves them to the trash can. We added flags in 3.0 where you can select what messages you want to receive.

[olecoot]

Well first of all this is a event that you should check. Typically it is a sign that the extension is behind a router that is not suitable for SIP.

 

In 2.1 the only way you can get rid of these messages is to use a rule on your email client that moves them to the trash can. We added flags in 3.0 where you can select what messages you want to receive.

 

 

Where are the flags located?

[Vodia PBX]

Where are the flags located?

 

Ehh.... they are hidden, but available. Check the pbx.xml file for names starting with "email_". You can change them in the pbx.xml file (which would require a restart) or use the trick in http://wiki.pbxnsip.com/index.php/Global_Configuration_File.

[olecoot]

Ehh.... they are hidden, but available. Check the pbx.xml file for names starting with "email_". You can change them in the pbx.xml file (which would require a restart) or use the trick in http://wiki.pbxnsip.com/index.php/Global_Configuration_File.

 

Okay, I found the email_ settings in the xml file but which one specifically will turn off these alerts: "Source address for sip:" and still allow me to receive the CPU stats that are sent out nightly?

 

Thanks

[Vodia PBX]

Okay, I found the email_ settings in the xml file but which one specifically will turn off these alerts: "Source address for sip:" and still allow me to receive the CPU stats that are sent out nightly?

 

That would be "email_address_change".

[olecoot]

That would be "email_address_change".

 

This is the server that inadvertently got upgraded. Is there a chance that the variable to which you refer is not there?

[MichaelW]

I know you had mentioned you were still working on the documentation, is that all set at this point? Do you have a timeframe when the release notes will be - well released?

 

Thanks,

[olecoot]

This is the server that inadvertently got upgraded. Is there a chance that the variable to which you refer is not there?

 

 

After checking several of our servers:

 

Windows 2003 servers (ver 2.1.6.2450)

Upgraded to 3.x - pbx.xml does not have the email_<variables> added.

 

Linux servers (pbxctrl-rhes4-2.1.14.2498)

Upgraded to 3.x - pbx.xml has the email_<variables> added

 

Can I add the variables manually to the xml file?

[Vodia PBX]

After checking several of our servers:

 

Windows 2003 servers (ver 2.1.6.2450)

Upgraded to 3.x - pbx.xml does not have the email_<variables> added.

 

Linux servers (pbxctrl-rhes4-2.1.14.2498)

Upgraded to 3.x - pbx.xml has the email_<variables> added

 

Can I add the variables manually to the xml file?

 

I would not manually add them. Just change a global setting from the web interface, this will rewrite the pbx.xml file. Then either edit it there (need restart) or use the web interface to change it (described on the wiki page I mentioned above).