Adding D765 to Auto-provisioning and PnP

[bencrosby]

Hi, I have modified the following files;

 

pnp.xml

 

added between snom_760 and snom_mp sections:

  <file name="snom_D765.xml" encoding="xml">
    <pattern>snomD765-############.htm</pattern>
    <prefix>true</prefix>
    <macpos>8</macpos>
    <vendor>snom</vendor>
    <anonymous>true</anonymous>
    <protocol>tftp,http,https</protocol>
    <pnp-vendor>snom</pnp-vendor>
    <pnp-model>snomD765</pnp-model>
    <pnp-version>^[78]</pnp-version>
    <pnp-content-type>application/url</pnp-content-type>
    <pnp-url>{https-url}/snomD765-{mac}.htm</pnp-url>
  </file>

snom_3xx_fs.xml:

<?xml version="1.0" encoding="utf-8"?>
<firmware-settings>{if_parm model snom300}
  <firmware perm="RW">http://downloads.snom.com/fw/snom300-8.7.3.25.9-SIP-f.bin</firmware>{fi_parm model snom300}{if_parm model snom320}
  <firmware perm="RW">http://downloads.snom.com/fw/snom320-8.7.3.25.9-SIP-f.bin</firmware>{fi_parm model snom320}{if_parm model snom360}
  <firmware perm="RW">http://downloads.snom.com/fw/snom360-8.7.3.25.9-SIP-f.bin</firmware>{fi_parm model snom360}{if_parm model snom370}
  <firmware perm="RW">http://downloads.snom.com/fw/snom370-8.7.3.25.9-SIP-f.bin</firmware>{fi_parm model snom370}{if_parm model snom820}
  <firmware perm="RW">http://downloads.snom.com/fw/snom820-8.7.3.25.9-SIP-r.bin</firmware>{fi_parm model snom820}{if_parm model snom821}
  <firmware perm="RW">http://downloads.snom.com/fw/snom821-8.7.3.25.9-SIP-r.bin</firmware>{fi_parm model snom821}{if_parm model snom870}
  <firmware perm="RW">http://downloads.snom.com/fw/snom870-8.7.3.25.9-SIP-r.bin</firmware>{fi_parm model snom870}{if_parm model snom710}
  <firmware perm="RW">http://downloads.snom.com/fw/snom710-8.7.3.25.9-SIP-r.bin</firmware>{fi_parm model snom710}{if_parm model snom715}
  <firmware perm="RW">http://downloads.snom.com/fw/snom715-8.7.5.28-SIP-r.bin</firmware>{fi_parm model snom715}{if_parm model snom720}
  <firmware perm="RW">http://downloads.snom.com/fw/snom760-8.7.5.28-SIP-r.bin</firmware>{fi_parm model snom720}{if_parm model snom760}
  <firmware perm="RW">http://downloads.snom.com/fw/snom760-8.7.5.28-SIP-r.bin</firmware>{fi_parm model snom760}{if_parm model snomD765}
  <firmware perm="RW">http://downloads.snom.com/fw/snomD765-8.7.5.28-SIP-r.bin</firmware>{fi_parm model snomD765}{if_parm model snom_mp}
  <firmware perm="RW">http://downloads.snom.com/fw/snomMP-8.7.3.25.9-SIP-r.bin</firmware>{fi_parm model snom_mp}{if_parm model snom_pa}
  <firmware perm="RW">http://downloads.snom.com/fw/snomPA1-8.7.3.25.9-SIP-f.bin</firmware>{fi_parm model snom_pa}
</firmware-settings>

snom_3xx_fw.xml:

<?xml version="1.0" encoding="utf-8"?>
<phone-settings>{if_parm model snom300}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom300</firmware_status>{fi_parm model snom300}{if_parm model snom320}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom320</firmware_status>{fi_parm model snom320}{if_parm model snom360}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom360</firmware_status>{fi_parm model snom360}{if_parm model snom370}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom370</firmware_status>{fi_parm model snom370}{if_parm model snom820}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom820</firmware_status>{fi_parm model snom820}{if_parm model snom821}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom821</firmware_status>{fi_parm model snom821}{if_parm model snom870}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom870</firmware_status>{fi_parm model snom870}{if_parm model snom710}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom710</firmware_status>{fi_parm model snom710}{if_parm model snom715}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom715</firmware_status>{fi_parm model snom715}{if_parm model snom720}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom720</firmware_status>{fi_parm model snom720}{if_parm model snom760}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom760</firmware_status>{fi_parm model snom760}{if_parm model snomD765}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snomD765</firmware_status>{fi_parm model snomD765}{if_parm model snom_mp}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom_mp</firmware_status>{fi_parm model snom_mp}{if_parm model snom_pa}
  <firmware_status perm="RW">{https-url}/snom_3xx_fs-{mac}.xml?model=snom_pa</firmware_status>{fi_parm model snom_pa}
</phone-settings>

Now, my questions, how do I create a new template file: "snom_D765.xml" ? There doesn't appear to be a way to add a new configuration template that doesn't exist.

 

Thanks.

Ben

[Vodia PBX]

We have already worked on this, for some OS we have a 5.3.0a ready. We have also addressed the problem that there are so many models now that we have grouped them a little bit better. What OS do you have?

[ahennis@voicespring.net]

Is there an 5.3.0a for Centos 6?

[bencrosby]

I'm running 5.3.0 on a Vodia Mini - if you have a 5.3.0a available, please could you post a link to it ?

 

Thanks

[Vodia PBX]

We have CentOS64 and Win64, and also builds for Debian64, and FreeBSD64. We have also a version for the snom ONE mini (the one in the snom plastic). We will make more builds on Monday as those other devices are not virtualized and need to be physically powered up first. Please keep in mind that this is still not a "release" version, which means that there can be some open issues and that you have to check on vodia.com/mplan if your license key is recent enough to the upgrade.

[bencrosby]

I have a mini PBX premium 20. This is the one based on the beaglebone black. Nowhere on the data sheet or website could I find reference to having to buy maintenance plans for this device.

 

If 5.3.0a will not be available under my current license, then back to my original question. How do I create or add new template files to the server to be served when referenced as I have done above. All existing templates are in a drop down list. How do I add a new one ?

 

Thank you.

[Vodia PBX]

If you have the beaglebone back, you should be covered by the maintenance plan. Check the vodia.com/mplan site.

 

If that does not work, what I would do is to change the pnp.xml and "hijack" the 760 pattern and the snom_3xx_fw for change the link for the software build. You would loose the possibility to have provision 760 at the same time, but these two changes are minimal and should get the job done.

 

We tried to add a 765 parallel to the 760, but things get really complicated and we gave up on this strategy. Grouping the devices reduces the number of files and makes it easier to deal with the next devices that snom has already lined up.

[bencrosby]

Hmm, unfortunately, I have both 760's and 765's. I will hijack one of the other phones I guess. It would still be good to be able to add custom.xml configuration files to the server. I don't see an easy way to do this, short of adding a web server onto the beaglebone on a different port, and referencing files from it's webroot. That seems to be an excessively complex solution.

 

One other example that came to mind.... rather than sending each phone to snom to get it's new firmware file, I would rather host the file on the PBX and allow the phones to download from the PBX. I have no problem loading the firmware to the PBX using sftp, but then need to present it over https.

[voipguy]

 

 

Now, my questions, how do I create a new template file: "snom_D765.xml" ? There doesn't appear to be a way to add a new configuration template that doesn't exist.

 

Place the "snom_D765.xml" file in the PBX \ html directory. If the html directory doesn't exist then create it. That's how it was done in the ver 4.5 days, let me know if it works.

 

 

 

One other example that came to mind.... rather than sending each phone to snom to get it's new firmware file, I would rather host the file on the PBX and allow the phones to download from the PBX.

 

I think you can upload the snom firmware files to the PBX \ tftp directory, if it doesn't exist then create it.

[Vodia PBX]

Regarding providing the firmware itself in the tftp folder we tried that in the snom days... But it was an ungrateful task. The situation today is that some phone providers do not allow including the firmware legally in the PBX itself. So we left the firmware topic largely to the devices, and so far only few people have complained about it. One lesson regarding firmware that we have learned is "never change a running system" and no matter how much you test a firmware, there are always surprises waiting for you. In other words unless there is a reason to change the firmware, don't touch it.

[bencrosby]

 

Place the "snom_D765.xml" file in the PBX \ html directory. If the html directory doesn't exist then create it. That's how it was done in the ver 4.5 days, let me know if it works.

 

 

I think you can upload the snom firmware files to the PBX \ tftp directory, if it doesn't exist then create it.

 

Thanks. Under V5, there is a /pbx/webpages directory, but files put there are not accessible to the phones via the provisioning - at least as far as I could determine.

 

And for the firmware, I actually need to put those into the web directory too. The phones all go to snom's website to pull their firmware directly. That means I have 11 phones that all pulled ~30MB for their upgrades, rather than me just doing it once - it's very minor, but annoying in a country where we pay for internet bandwidth.

[voipguy]

You didn't follow my instructions.

 

I said "Place the "snom_D765.xml" file in the PBX \ html directory. If the html directory doesn't exist then create it."

 

Both ver 4 and ver 5 have the /webpages directory, I never said place it in the /webpages directory.

 

For the firmware files place them in the tftp directory and you can also place the firmware files in the /html directory and test to see if the phones will pull the firmware from the PBX tftp or html directories after you tell the PBX what path to get the firmware files from.

[Vodia PBX]

So 5.3.0a should be available for all minis now.

[bencrosby]

So 5.3.0a should be available for all minis now.

Thanks, installing it now.

 

Ben

[bencrosby]

You didn't follow my instructions.

 

You're right. I didn't. My bad. Thanks for the clarification.

 

Sadly creating the /pbx/html directory and putting the files there didn't work either.

 

Thanks for the advice though.

[bencrosby]

So 5.3.0a should be available for all minis now.

 

I confirm the successful provisioning of a D765 on 5.3.0a, same process as 760...

 

I have a few comments on the build;

 

IMHO, snom_760_phone.xml contains a few mistakes;

 

1) template file contains;

 

<ignore_security_warning perm="RW">on</ignore_security_warning>

<ignore_security_warning>on</ignore_security_warning>

 

Both entries in file (redundant)

 

2) <codec_priority_list idx="{lc}" perm="RW">pcmu,pcma,gsm,g722,g726-32,g729,telephone-event</codec_priority_list>

 

This doesn't match snom default priority list: g722, pcmu, pcma, gsm, g726-32, aal2-g726-32, amr-0, amrwb-0, g729, telephone-event, and results in the de-prioritisation of g722 wideband codec.

 

3) Setting under domains / advanced / general settings / emergency numbers is not being carried through to phone parameter <keyboard_lock_emergency perm="RW">VALIDVALUE</keyboard_lock_emergency>

 

4) <tone_scheme perm="RW">{enum domain lang_tones USA au=AUS at=AUT ch=CHN dk=DNK fr=FRA de=GER uk=GBR in=IND it=ITA jp=JPN mx=MEX nl=NLD no=NOR nz=NZL sp=ESP sw=SWE ch=SWI}</tone_scheme>

 

This doesn't match domains / advanced / general settings / tone language (only English in list) - Where is the correct tone scheme set in the PBX UI ? e.g. "AU"

 

5) Similarly, ( sorry, these are my overrides, I can't recall the default) where are these two values set in the UI ? All my languages are English, but that's not enough to turn off US date format and US number format on the phone.

 

<time_24_format perm="RW">on</time_24_format>

<date_us_format perm="RW">off</date_us_format>

 

6) Snom configuration parameter <dialnumber_us_format perm="RW">off</dialnumber_us_format> should be enabled for non-US locations. I have Europe 3-digit extensions set under domain / advanced settings / general / provisioning parameters / default PnP dial plan scheme.

 

Still playing with the build, will let you know if I find others.

Thanks !

[Vodia PBX]

Thanks, this is excellent feedback.

 

1) yea it should really make it clear that the phone should not put that security warning on the screen. Anyway, 1x is enough. We'll change that.

 

2) The codec preference on the phone has only limited impact on what codec is actually selected. The PBX will always use it's own setting to determine the codec in the negotiation process. At the end of the day this helps keeping the SDP attachment shorter, which is important if the phone should use UDP where the MTU is typically 1492 bytes. The phones may propose more codecs, but the PBX does not support them. A side note on G722 and other high quality codecs: The problem is that most of the (important) calls eventually end up in the PSTN, where pcmu and pcma are still the prevalent codecs. When you use a G.722 codec to talk to the PSTN, it will eventually get transcoded down to G.711. Unfortunately every information transformation from one format to another reduces the quality of the call, the codecs can not "invent" information (at least not those codecs we are talking about here), that is why it is better to focus on G.711 as the primary codec and use high compressing codecs when bandwidth is a problem. We experienced this problem first hand when we happily started using G.722 and customers complained about damped call quality, which at first puzzled us but later when you think about it made sense.

 

3) Good catch, especially because the default on the phone goes very far across all sorts of countries. However it also means that PBX admins need to pay more attention to this setting. We'll add that.

 

4) The tones are those two digits after the "audio_" in the file system. By default it is USA if nothing else was found. Which one is missing?

 

5) The problem is that we need to "guess" if users should use 12 or 24 hour format and how they want the date. We could use the country code which works well for the rest of the world, the problem is Canada. Looking at https://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada it seems to be fine to use the same notation like in the US. So:

 

<time_24_format perm="RW">{enum domain country_code on 1=off}</time_24_format>

<date_us_format perm="RW">{enum domain country_code off 1=on}</date_us_format>

6) That problem is related. I think that <dialnumber_us_format perm="RW">{enum domain country_code off 1=on}</dialnumber_us_format> should properly solve that problem. It assumes that the admin set the country code.

[bencrosby]

2) The codec preference on the phone has only limited impact on what codec is actually selected. The PBX will always use it's own setting to determine the codec in the negotiation process. At the end of the day this helps keeping the SDP attachment shorter, which is important if the phone should use UDP where the MTU is typically 1492 bytes. The phones may propose more codecs, but the PBX does not support them. A side note on G722 and other high quality codecs: The problem is that most of the (important) calls eventually end up in the PSTN, where pcmu and pcma are still the prevalent codecs. When you use a G.722 codec to talk to the PSTN, it will eventually get transcoded down to G.711. Unfortunately every information transformation from one format to another reduces the quality of the call, the codecs can not "invent" information (at least not those codecs we are talking about here), that is why it is better to focus on G.711 as the primary codec and use high compressing codecs when bandwidth is a problem. We experienced this problem first hand when we happily started using G.722 and customers complained about damped call quality, which at first puzzled us but later when you think about it made sense.

 

 

Yup, I agree in theory. In practice the internal HD option should be negotiated as a priority for internal calls, and g.711 / PCMA should end up being used externally - *unless* you have a SIP trunk provider who is doing G.722 and interconnecting to telcos at G.722. At least in Australia, the national Telco has wideband deployed throughout their network, including AMR-WB / G722.2 for the Cellular network.

 

Personally, I would cut the codec list down to G722, PCMU and PCMA.

 

Ps - region codes should select PCMA for EU, Asia and Australia, and PCMU for the USA - that could be done automagically too.... ($0.02)

 

Interesting debate anyway.

 

 

4) The tones are those two digits after the "audio_" in the file system. By default it is USA if nothing else was found. Which one is missing?

 

 

Sorry, I wasn't clear here. I'm not sure if any languages are missing. You appear to be enumerating au=AUS correctly. That setting doesn't make its way into the phone config at;

 

<tone_scheme perm="RW">{enum domain lang_tones USA au=AUS at=AUT ch=CHN dk=DNK fr=FRA de=GER uk=GBR in=IND it=ITA jp=JPN mx=MEX nl=NLD no=NOR nz=NZL sp=ESP sw=SWE ch=SWI}</tone_scheme>

 

So my question is what UI setting will result in the correct enum to au=AUS for this part of the configuration? Settings / General / System Administration / General / Default Tone Language only has "English" in my drop down. I assume this is where the tone list should reside ?

 

5) The problem is that we need to "guess" if users should use 12 or 24 hour format and how they want the date. We could use the country code which works well for the rest of the world, the problem is Canada. Looking at https://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada it seems to be fine to use the same notation like in the US. So:

 

<time_24_format perm="RW">{enum domain country_code on 1=off}</time_24_format>

<date_us_format perm="RW">{enum domain country_code off 1=on}</date_us_format>

 

 

You could add a global 12h / 24h radio button under timezone at Settings / General / System Administration / General /

Or a domain based 12h / 24h under Domain / Advanced / General Settings / Advanced / just after Timezone

 

My domain country code is set to 61, so your proposed change would work fine in my environment.

 

6) That problem is related. I think that <dialnumber_us_format perm="RW">{enum domain country_code off 1=on}</dialnumber_us_format> should properly solve that problem. It assumes that the admin set the country code.

 

Yup, that would work fine.

 

Thanks

[Vodia PBX]

With the codec topic, of course we tried to have G.722 internally and G.711 outside. However the problem was the attended transfer: Call from A (trunk) comes in to B, B calls C, then transfers the call to C, where we ended up with transcoding... Ok we could try to re-invite and negotiate another codec and I even believe we do that. However what we have learned is that companies make their money with good sounding internal calls (who cares if the employees can talk high def ), what mostly counts is as-good-as impossible communication with clients.

 

Transcoding between ulaw and alaw is loss-less, and it does not take much CPU; this is not a big problem.

 

We included Australia simply because we have good business down there and want to make it possible to have the phone render Australian tones.