I am currently researching the new Digium phones and how they would receive provisioning. I am reading up on their DPMA module and how it works. this method looks slick, but there could be a chance that this only works in STE, and then only when the phones reside on the same network. It appears it registers itself as an Avahi/mDNS service for discovery.
I have already found one glitch in an example config and am waiting on a callback from one of their software engineers. Apparently digium doesnt know how to read the RFC for Alert-Info headers any better than trixbox does. The value of the Alert-Info is supposed to be nested inside of left-angle and right-angle quotes < > . For example, out of the box, polycom uses the value Ring Answer for their ring-then-answer setting. Therefore the dialplan would appear as
SipAddHeader(Alert-Info: < Ring Answer >)
the problem is that trixbox and other programmers always did it without the brackets, and phones generally accepted this. However, routers that depend on libosip2 will drop these packets. that means routers such as siproxd, or opensips, or SER or these others, when in use, will simply not pass the request to the phone since it violated the RFC. I discovered this problem about 3 yrs ago when I started experimenting with siproxd.
so right now there are 2
so right now there are 2 methods of provisioning the phones.. one is the classic XML template based system via FTP that we know all too well.
the second is the new DPMA module provided by digium that provisions the phones over sip.
Pro's of the DPMA module:
- allows for more features on the phone including visual voicemail and viewing all parked calls in all the parkinglots
- virtual hot desking; a feature exists allowing you to select the identity and enter a pin and the phone downloads the configs for that 'phone' allowing you to sit at any desk and keep your extension and other settings.
- supposedly, in the future, the ability exists to write your own apps for the DPMA so things like forwarding or logging into a queue can be done from the phone but actually manipulate settings in asterisk instead of the old way
- reconfiguration of phones from a single CLI command
Con's of the DPMA module:
- right now any customization to ring tones, making the Alert-Info compatible with thirdlane, adding extra Alert-Info's, customizing ring tones, etc. all must be done in the XML method. Hopefully in time these will move into the DPMA but they currently dont exist.
- everything is managed in a single file like sip.cfg which means that the existing phone configuration system is not compatible with the res_digium_phones.conf file structure. A whole new design would have to be created or you would have to edit the fire manually.
- due to the design of hot desking and especially the parking application, there is simply no way the DPMA would be compatible with MTE. This is an STE only enhancement at this time. Imagine seeing every parking lot with other customer names and being able to unpark them and do all sorts of malicious things.
- the current dynamic dialplan used by the DPMA assumed everyone ran extensions.conf as autofallthrough=yes. Thirdlane does not. I have made dialplan workaround for this and have submitted the feedback to digium so hopefully a more permanent fix will exist but at least the workaround exists.
- the DPMA module requires you to manually do an SVN checkout of 1.8-digiumphones branch of asterisk which means those without the skill to compile/install asterisk will need to hire assistance.
Pros of the XML method:
- easy to integrate into existing thirdlane phone provisioning system
- customizable options and settings allowing features to match the way thirdlane currently sends them to devices
Cons of the XML method:
- special applications such as visual voicemail do not exist, voicemail button simply dials *98 just like all the other phones
interesting characteristics of the phones..
- currently each registration takes up only 1 linekey on the phone. There currently is no option to have the other linekeys share the registration so that additional calls arrive on those buttons. This could change in the future but this is a current behavior
- there is no physical hookflash button, its magnetic and activates when you place the handset back on the receiver. The only time this will be noticed is when you start to dial and realize you screwed up and want to press the hookflash quickly to intiate a new dialing sequence.
- even though the D70 will support 10 pages of 10 buttons (100) its limited to 40 BLF keys so the remaining 60 would have to be speed-dial.
- the base bracket has two angles to support a low angle and high angle of the device. The low angle is exactly the same angle polycom uses for their base. The high angle is much more cisco phone oriented.
- wallmount brackets are all separate purchases. there is no device whose bracket supports wall-mount natively unlike the IP321/331/335
- there is an undocumented Electronic HookSwitch (EHS) port in the back that is identical to the one on the polycom phones. Hopefully this means that cordless remote headsets can answer calls with a touch of the button.
TFTP is not among its listed
TFTP is not among its listed transport methods when you look at its manual option from the list..
i know my option 66 in dhcp had to be changed to
ftp://PlcmSpIp:PlcmSpIp@ip.of.your.server
so that both polycom and the digium phones could use FTP provisioning
you could try a tftp:// url method to see if it worked but only FTP, HTTP, HTTPS were among the list under manual configuration.
Did you have to do something special for the BLF.
Can't seem to get the BLF Working on these phones.
Did you have to do something special for the BLF.
I just delivered it by FTP to my phone.
I just created a contacts xml file and delivered it by FTP to my phone. Why would you say that FTP will not work? and that does not answer my BLF question.
When we originally bought the
When we originally bought the phone we had issues getting the BLF to work. We've opened up a ticket with Digium and after working with their engineer for couple of days (we've even sent them our configs) they've notified us that contacts XML cannot be served via FTP at this particular time and suggested we try HTTP instead. As soon as we did that BLF started working. We're still serving the main config file via FTP but contacts and logo goes over HTTP.
I can go ahead and send you our configs if you'd like. Just let me know your email address.
I'm excited to give these phones a shot when they get released. I'm curious as to how long do you think it would take for these phones to be added to TL with a provisioning script? Best of Luck Erik! :)