DHCP Option 66 for remote D40 sets config

[BJYoung]

Scenario --

Switchvox AA305 at a primary site 10.10.23.10
3 other remote sites also on the 10.10.x.x network via dedicated voice MPLS/VLAN
The Digium D Series Set data sheet lists DHCP Option 66 as an Auto-Provisioning method

How can I get the remote D sets to point to the 10.10.23.10 SV Server to download their config files?
Does anyone know the Switchvox config server URL that the sets point to?

[hiltonmw]

For Polycom phones it was:
http://IP.OF.YOUR.SWITCHVOX/PC

Might be the same for the D series phones, but not sure.

[brucexx]

no it is just the ip address of the phone system. I provisioned one of these and they do not use the "/pc" directory - just a side note if you configure Polycom phones this has to be lowercase "/pc" and NOT uppercase "/PC"

With option 66 you need to refer to your DHCP server documentation each DHCP will have different method of assigning option 66. Then you need to make sure that the phone is set up to option 66 as well they should by default at least Polycoms are...

[BJYoung]

Yeah, I tried the [switchvox ip address]/pc trick first, but I'm guessing the 'pc' stands for 'Polycom Config'

Brucexx -- There is no setting that I could find on the D set for Option 66. Only Menu options under Admin Settings are:

Network Settings
DHCP
Static

VLAN Settings
LLDP
Manual
None

If you select Manual, it just gives you VLAN ID and VLAN QOS options. How'd you do it?


Thanks

[hiltonmw]

upon further reflection - i'm pretty sure you don't need option 66 for the digium handsets, as they use mDNS to search for your switchvox on the same subnet as your phones. Or, you can manually configure them. As a note Digium also specifies: your network must be capable of forwarding multicast requests. So perhaps the key to this problem is there - making sure that your "other side" network is receiving these mDNS requests and broadcasts properly

[BJYoung]

HMW --

Thanks for the mDNS update. Getting Multicast to propagate across the routed MPLS can be done, but not Broadcast. I'll have my network guys fart around with it this week and see what we can get to work.

If not, we'll have to unbox 175 sets, manually discover/config them, rebox 'em, label them for site, user and extension. That's a lot of time lost - here's hoping we can get around it.

--Brian

[BJYoung]

For anyone who was following this thread, let me save you some time and give you two ways to discover sets on a remote subnet;

Forget DHCP Option 66
Take advantage of the very slick and often overlooked new Phone Assignment Options in SV Admin under Setup>Digium Phones in SMB 5.5

Example situation is when you have remote D sets on a different subnet as your Switchvox server
In our case we have two AA305s serving a 200+ local and remote users over 7 sites via MPLS WAN
We have all TCP/UDP ports open as this is a private, voice-only MPLS

Least efficient;
Crack open every D set box, discover the set locally to the Switchvox, box it back up, label it for the specific user. When you deploy the set, it will try to discover the Switchvox locally, give up, and then ask you if you want it to run on it's last configuration. Say YES and it will download it's last config file from across the WAN - because part of what it memorized was the SV server's static IP address on the remote subnet.

Most efficient;
Just build the extension profiles in SV, use the super-efficient new Bulk-Import tool if there are a lot of them, and drag the sets out to the remote sites. When you deploy the set, it will try to discover the Switchvox locally, give up, and give you a SETTINGs option in the LCD. Choose menu option 1, DIGIUM CONFIGURATION SERVER - then just enter the Switchvox's remote IP manually. You can skip the PORT entry, it will default to 5062. Then hit GO. As soon as it finds Switchvox, it'll ask what extension profile you want the set to download. Dial the EXTENSION number, press ENTER, dial the VM passcode, press ENTER, and shazam, it will config the set. Literally takes 60 seconds more than deploying the sets locally, and you don't have to fart around with Option 66.

--BJYoung

[ultimatewombat]

BJYoung - Excellent post of most useful information - if only Digium would have bothered to write any sensible documentation what-so-ever about the new Digium phones and features and administration of such, I would not have had such fun on a 400+ Digium handset rollout a few weeks before your post!

Thank you kindly for your input, book-marked for the next one!


Note to Digium - put out some PROPER documentation on this regarding Switchvox - and update the Admin Help Manuals for the latest version (help page for 'Phone Networks' is still a 404!)

[barrangatan]

Great post BJYoung. I will also just add that when the Digium phones are used with a Switchvox system, Option 66 is actually not recommended. Nevermind that when using Option 66, you'll need to build the phone configs separately and make them available on a HTTP or FTP server for downloads; The Option 66 method essentially bypasses the Digium Phone Configuration Server running on the Switchvox system, and will result in a loss in functionalities. For example: a phone that is *not* configured via the Digium Phone Configuration Server will have trouble using all the phone apps (Queues, Parked Calls, Status), and when a change is made on the PBX Admin or User Portal (eg changing the line label), the phone will not be notified of the change and download a new config file that include the new changes.

Think of it this way: If you are using Option 66 to configure your Digium phones to use with a Switchvox system, it's as if you're not using the Phone Feature Packs when configuring a Polycom phone - more work, and diminished functionalities.

[brucexx]

hi - did anybody provision any remote phones with option 66. It might be easy on a local network but for remote network option 66 should work.

I thought that the ASCII would be sip:proxy@<local ip of your pbx> this is at least what it says on the screen when you put the ip manually when it loads configuration - but it does not work this way.

[troab]

This particular need is a pet peeve of mine, and I see some misinformation / misunderstanding among posts on this thread.

A) The two methods bjyoung mentions are perfectly valid processes, but do involve manually entering information on the handset itself, which quite frankly, should not be necessary and in larger installs across multiple sites becomes time intensive for something that should be able to be done automatically.

B) Using option 66 is like NOT using phone feature packs - UNTRUE.
Options 66 simply tells the handset where to go. We use it with Polycoms all the time on multi-site installations because when the handset is on a remote subnet (routed in the clear - no nat) it is unable to detect the Switchvox and needs to be told where to go. From there on forward the phone downloads its config file and other info from the Switchvox utilizing the phone feature packs and provisioning.

C) Even on local single building networks, we often have a data vlan and a voice vlan. The Digium Phone Networks is great - IF somebody tells the phone where to go first. However if you boot up the phone untagged in the data vlan, it will have no way to read those beautiful phone network configs without sombody keying info directly into the handset.
Note - You could use LLDP for this - but not every switch supports LLDP not every network design.

D) I am by no means a multicast expert, but I thought maybe there might be something to the idea of setting up multicast for mDNS so that remote sites. After an hour or so of a crash course I discovered and verified through multiple sources that multicast group addresses in the 224.0.0.0 to 224.0.0.255 range are restricted and reserved - routers are not to forward these packets beyond the local subnet. MDNS is 224.0.0.251.
Google it up and you'll see alot of network engineers complaining about Apple/Bonjour. Apparently Bonjour/mDNS is all good and finme for tiny single-subnet networks, but really falls apart on anything even moderately complex.
Unless I'm missing something major, I'm not convinced mDNS was a great choice.... but like I said, I'm no multicast expert.

From: http://en.wikipedia.org/wiki/Multicast_address

Addresses in the range 224.0.0.0 to 224.0.0.255 are individually assigned by IANA and designated for multicasting on the local subnetwork only. For example, the Routing Information Protocol (RIPv2) uses 224.0.0.9, Open Shortest Path First (OSPF) uses 224.0.0.5 & 224.0.0.6, and Zeroconf mDNS uses 224.0.0.251. Routers must not forward these messages outside the subnet in which they originate.

In short: supporting DHCP 66 as a means of telling the handset where to find the Switchvox when it is not immediately available be of tremendous value. In truth, I think I would actually prefer a custom DHCP option since 66 is often used by other devices (including Polycoms). This could allow a handset to be unboxed and plugged in anywhere on the WAN (including over VPN's) and because it would be able to automatically retrieve the "Phone Network Configurations" there would be no need for manual configuration - especially if this is combined with Digium's new feature to manually enter or import the MAC address <> Extension mapping.

EDIT: Oh and by the way, despite how it might sounds, I really do like the Digium phones and sell them almost exclusively now. I just want a way for my techs to be more efficient in deployments.

[Nathan Fowler]

Hopefully everyone in this thread is set to receive e-mail updates.

In the new firmware (1.1.3) DHCP Option 66 is now available for use when provisioning Digium phones on other subnets. It works a lot better than my solution.

Digium Phone Provisioning from the Wiki. Scroll down to the "DPMA and Switchvox Configuration when Multicast is Not Available" section.

My now irrelevant solution:
We were going to deploy phones in a few remote subnets. Since the particular mDNS address that the phones used for provisioning could not be routed and from what I knew about using the Digium Phone Module for Asterisk (DPMA) I figured out a way to use Avahi (which is what the DPMA used also) to hand our mDNS provisioning information to those remote subnets. Using a linux system at the remote site we loaded the Avahi daemon and a file called switchvox.service to the "services" directory with the following information:

Code: Select all

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
        <name replace-wildcards="no">Switchvox</name>
        <service>
                <type>_digiumproxy._udp</type>
                <txt-record>sipURL=sip:proxy@192.168.1.2:5062</txt-record>
                <txt-record>serviceType=switchvox</txt-record>
                <txt-record>org.freedesktop.Avahi.cookie=3956038598</txt-record>
        </service>
</service-group>

Replace 192.168.1.2 with the IP address of your Switchvox server and now your phones would boot and grab its configuration just as if it was on the local subnet.

DHCP Option 66 is a much more elegant solution since it requires zero hardware at the remote sites (assuming you already have a DHCP server in place).