Following my recent post about the SoundPoint phones, I thought I’d dig some more and refine them.

Customising the Tones

First off, let’s make them sound Aussie.

With a bit of digging, I was able to customise the dial, busy and ringback tones and cadences. In the process of testing this config I found I couldn’t get Lync to send me a busy signal (SIP 486) – the best I could get was SIP 480 (Temporarily Unavailable). So I added a “reorder” section to the config – just so I could hear what the busy tone sounds like.

Here’s what you need to add to LyncSharedExample.cfg. Tweak as necessary, or to revise for other markets.

<tone>
<tone.chord>
<tone.chord.callProg>
<tone.chord.callProg.busyTone>
<tone.chord.callProg.busyTone.freq tone.chord.callProg.busyTone.freq.1="425" tone.chord.callProg.busyTone.freq.2="425" />
<tone.chord.callProg.busyTone.level tone.chord.callProg.busyTone.level.1="-20" tone.chord.callProg.busyTone.level.2="-20" />
<tone.chord.callProg.busyTone.onDur tone.chord.callProg.busyTone.onDur="0" />
<tone.chord.callProg.busyTone.offDur tone.chord.callProg.busyTone.offDur="0" />
<tone.chord.callProg.busyTone.repeat tone.chord.callProg.busyTone.repeat="1" />
</tone.chord.callProg.busyTone>
<tone.chord.callProg.reorder>
<tone.chord.callProg.reorder.freq tone.chord.callProg.reorder.freq.1="425" tone.chord.callProg.reorder.freq.2="425" />
<tone.chord.callProg.reorder.level tone.chord.callProg.reorder.level.1="-20" tone.chord.callProg.reorder.level.2="-20" />
<tone.chord.callProg.reorder.onDur tone.chord.callProg.reorder.onDur="0" />
<tone.chord.callProg.reorder.offDur tone.chord.callProg.reorder.offDur="0" />
<tone.chord.callProg.reorder.repeat tone.chord.callProg.reorder.repeat="1" />
</tone.chord.callProg.reorder>
<tone.chord.callProg.dialTone>
<tone.chord.callProg.dialTone.freq tone.chord.callProg.dialTone.freq.1="400" tone.chord.callProg.dialTone.freq.2="425" />
<tone.chord.callProg.dialTone.level tone.chord.callProg.dialTone.level.1="-12" tone.chord.callProg.dialTone.level.2="-12" />
</tone.chord.callProg.dialTone>
<tone.chord.callProg.ringback>
<tone.chord.callProg.ringback.freq tone.chord.callProg.ringback.freq.1="450" tone.chord.callProg.ringback.freq.2="400" />
<tone.chord.callProg.ringback.level tone.chord.callProg.ringback.level.1="-20" tone.chord.callProg.ringback.level.2="-20" />
<tone.chord.callProg.ringback.onDur tone.chord.callProg.ringback.onDur="0" />
<tone.chord.callProg.ringback.offDur tone.chord.callProg.ringback.offDur="0" />
<tone.chord.callProg.ringback.repeat tone.chord.callProg.ringback.repeat="1" />
</tone.chord.callProg.ringback>
</tone.chord.callProg>
</tone.chord>
</tone>
<se>
<se.pat>
<se.pat.callProg>
<se.pat.callProg.ringback>
<se.pat.callProg.ringback.inst se.pat.callProg.ringback.inst.1.type="silence" se.pat.callProg.ringback.inst.1.value="200" se.pat.callProg.ringback.inst.2.param="400" se.pat.callProg.ringback.inst.2.type="chord" se.pat.callProg.ringback.inst.2.value="ringback" se.pat.callProg.ringback.inst.3.type="silence" se.pat.callProg.ringback.inst.3.value="200" se.pat.callProg.ringback.inst.4.param="400" se.pat.callProg.ringback.inst.4.type="chord" se.pat.callProg.ringback.inst.4.value="ringback" se.pat.callProg.ringback.inst.5.type="silence" se.pat.callProg.ringback.inst.5.value="1800" se.pat.callProg.ringback.inst.6.type="branch" se.pat.callProg.ringback.inst.6.value="-4" />
</se.pat.callProg.ringback>
<se.pat.callProg.busyTone>
<se.pat.callProg.busyTone.inst se.pat.callProg.busyTone.inst.1.type="silence" se.pat.callProg.busyTone.inst.1.value="375" se.pat.callProg.busyTone.inst.2.param="375" se.pat.callProg.busyTone.inst.2.type="chord" se.pat.callProg.busyTone.inst.2.value="busyTone" se.pat.callProg.busyTone.inst.3.type="branch" se.pat.callProg.busyTone.inst.3.value="-2" />
</se.pat.callProg.busyTone>
<se.pat.callProg.reorder>
<se.pat.callProg.reorder.inst se.pat.callProg.reorder.inst.1.type="silence" se.pat.callProg.reorder.inst.1.value="375" se.pat.callProg.reorder.inst.2.param="375" se.pat.callProg.reorder.inst.2.type="chord" se.pat.callProg.reorder.inst.2.value="reorder" se.pat.callProg.reorder.inst.3.type="branch" se.pat.callProg.reorder.inst.3.value="-2" />
</se.pat.callProg.reorder>
</se.pat.callProg>
</se.pat>
</se>

References:
1. This post on the Polycom VoIP FAQ
2. Some banter with the Polycom moderator here
3. The Aussie standard tone frequencies & cadences
4. And finally, the key to getting it all working on this Voxilla forum post – you need to Branch to Silence, not to a Chord.

Daylight Saving

Now let’s set daylight saving time (aka “DST”). The Aries phones prompt you to manually specify the time zone, but the SoundPoints are clever enough to pull the offset from DHCP (scope option 2). Alas, daylight saving we need to hard-code into the phone’s config file.

I’d like to have automated this through some intelligent use of the phone’s IP Address, but alas, no can do. Instead, you need to glue the relevant bit of code into the “phone-<MacAddress>.cfg” file. So I guess what makes sense here is that you create a template for the states that use DST, and omit this for the rest. Alternatively I guess you might add a local FTP server in each site/state and use DHCP to point to the appropriate server. (If you think of a better way, please let me know!!)

Thankfully here in Oz all of the states that do the DST thing do it on the same date, so that reduces the pain all ‘round. (DST reference for Oz). Accordingly, there’s only the 1 config we need to bother with:

NSW, VIC, ACT, TAS, SA & Broken Hill:

We advance on the First Sunday in October each year at 2am, and revert at 3am (DST time) on the First Sunday in April.

<tcpIpApp>
<tcpIpApp.sntp>
<tcpIpApp.sntp.address tcpIpApp.sntp.address.overrideDHCP="0"></tcpIpApp.sntp.address>
<tcpIpApp.sntp.daylightSavings tcpIpApp.sntp.daylightSavings.enable="1" tcpIpApp.sntp.daylightSavings.fixedDayEnable="0">
<tcpIpApp.sntp.daylightSavings.start tcpIpApp.sntp.daylightSavings.start.date="1" tcpIpApp.sntp.daylightSavings.start.dayOfWeek="1" tcpIpApp.sntp.daylightSavings.start.month="10" tcpIpApp.sntp.daylightSavings.start.time="2">
<tcpIpApp.sntp.daylightSavings.start.dayOfWeek tcpIpApp.sntp.daylightSavings.start.dayOfWeek.lastInMonth="0"></tcpIpApp.sntp.daylightSavings.start.dayOfWeek>
</tcpIpApp.sntp.daylightSavings.start>
<tcpIpApp.sntp.daylightSavings.stop tcpIpApp.sntp.daylightSavings.stop.date="1" tcpIpApp.sntp.daylightSavings.stop.dayOfWeek="1" tcpIpApp.sntp.daylightSavings.stop.month="4" tcpIpApp.sntp.daylightSavings.stop.time="3">
<tcpIpApp.sntp.daylightSavings.stop.dayOfWeek tcpIpApp.sntp.daylightSavings.stop.dayOfWeek.lastInMonth="0"></tcpIpApp.sntp.daylightSavings.stop.dayOfWeek>
</tcpIpApp.sntp.daylightSavings.stop>
</tcpIpApp.sntp.daylightSavings>
<tcpIpApp.sntp.gmtOffset tcpIpApp.sntp.gmtOffset.overrideDHCP="0" tcpIpApp.sntp.gmtOffset="36000" tcpIpApp.sntp.resyncPeriod="3600"></tcpIpApp.sntp.gmtOffset>
</tcpIpApp.sntp>
</tcpIpApp>

I’ve included the last line just in case you want to override the DHCP Scope Option 2 with a locally-held offset – although in this example it’s set to 0, so still relying on the DHCP server for the offset and ignoring the file’s value of 36000.

The final attribute there (resyncPeriod) is how often the phone will check the time from the DHCP server. Every hour (3600) might be a little extreme: the Polycom PDF chose a value of 86400 (24 hours).

Here’s a prettier view of what this growing config file looks like now:

NT, WA & QLD:

n/a. You can strip the settings shown above, or alternatively, simply leave them there but disable them with “.enable=0”.
This sample shows DST values present but *disabled*. We’re still relying on the NTP server nominated by DHCP, but we’re adding a manual time offset instead of whatever might be offered by DHCP in its Option 2.

<tcpIpApp>
<tcpIpApp.sntp>
<tcpIpApp.sntp.address tcpIpApp.sntp.address="yourTimeServer.contoso.com" tcpIpApp.sntp.address.overrideDHCP="0"></tcpIpApp.sntp.address>
<tcpIpApp.sntp.daylightSavings tcpIpApp.sntp.daylightSavings.enable="0" tcpIpApp.sntp.daylightSavings.fixedDayEnable="0">
<tcpIpApp.sntp.daylightSavings.start tcpIpApp.sntp.daylightSavings.start.date="1" tcpIpApp.sntp.daylightSavings.start.dayOfWeek="1" tcpIpApp.sntp.daylightSavings.start.month="10" tcpIpApp.sntp.daylightSavings.start.time="2">
<tcpIpApp.sntp.daylightSavings.start.dayOfWeek tcpIpApp.sntp.daylightSavings.start.dayOfWeek.lastInMonth="0"></tcpIpApp.sntp.daylightSavings.start.dayOfWeek>
</tcpIpApp.sntp.daylightSavings.start>
<tcpIpApp.sntp.daylightSavings.stop tcpIpApp.sntp.daylightSavings.stop.date="1" tcpIpApp.sntp.daylightSavings.stop.dayOfWeek="1" tcpIpApp.sntp.daylightSavings.stop.month="4" tcpIpApp.sntp.daylightSavings.stop.time="3">
<tcpIpApp.sntp.daylightSavings.stop.dayOfWeek tcpIpApp.sntp.daylightSavings.stop.dayOfWeek.lastInMonth="0"></tcpIpApp.sntp.daylightSavings.stop.dayOfWeek>
</tcpIpApp.sntp.daylightSavings.stop>
</tcpIpApp.sntp.daylightSavings>
<tcpIpApp.sntp.gmtOffset tcpIpApp.sntp.gmtOffset.overrideDHCP="1" tcpIpApp.sntp.gmtOffset="36000" tcpIpApp.sntp.resyncPeriod="3600"></tcpIpApp.sntp.gmtOffset>
</tcpIpApp.sntp>
</tcpIpApp>

Done.

Testing DST with a Windows 2008 R2 DHCP server

BTW, whilst I’m obliged to place a “caveat emptor” warning on the above, the config *was* tested working against a DHCP server I mocked up in the lab and took forward to October 7th 2012 and April 7th 2013 and back several times. I found initially that Windows wouldn’t revert at 3am on the appointed morning. It seems that it needs to go through the transition from 1:59 to 2am first, and then at 3 it would behave as expected. (Here’s a quick NTP how-to if you want to do your own testing).

HOTLINE!

Sorry – Hotlining excites me. Don’t know why. Here we now have a “Lync” phone that can be made to Hotline – to automatically call a preconfigured number when it goes off-hook. (And for the benefit of Google, I’ll refer to the alternate name of Private Line Automatic Ring-Down or PLAR).

It’s pretty simple to do. If you’re working with my earlier config, it’s as easy as adding the below text to the “phone-<macAddress>.cfg” file.

<call>
<call.autoOffHook call.autoOffHook.1.contact=”<APhoneNumberGoesHere>” call.autoOffHook.1.enabled=”0″></call.autoOffHook>
</call>

Here’s what my sample one now looks like, pre-set to call my mobile when-ever it goes off-hook. Note that you now have to add the Dial Plan’s simple name to the end of the contact to be dialled (if it’s a phone number). It seems that when you enable hotline, the phone no longer looks at the “dialplan.1.digitmap” we used in the LyncSharedExample.cfg file to build the outgoing number.

So in this example, the “call.autoOffHook.1.contact” is set to “0270001234;phone-context=simplename” – and for the benefit of my international readers, that’s a vanilla Aussie number with area code & local number, which will require normalisation, hence the need for the Dial Plan’s simple name glued on as a suffix.

Summary

The more I dig, the more I’m impressed by the SoundPoint family. I have perhaps 1 or 2 more posts on the subject to come, and I anxiously await the new firmware release – due at the end of Aug 2012 (which at the time of writing was almost a month ago). :-(

Oct 17th, 2012: It’s here! The new software (4.0.3F) has landed. Early-adopters can download it from here.