Hi all, Just to preface this, XX-5838 has been parked for now.
There are other phone provisioning requirements still to be investigated, so I don't think it makes sense to implement XX-5838 at this point. Scott wrote: > On Wed, 2009-06-17 at 16:32 -0400, Paul Mossman wrote: > > I wrote: > > > While looking into XX-5417 I did some prototyping and > thinking about > > > how to get where we eventually want to be. > > > That is to have phones load their configuration over > HTTPS, and with > > > authentication. A rough draft proposal is below. > > > > I'm going to try and squeeze this into 4.2, under XX-5838: Add > > provisioning of phones with HTTPS and authentication. > > > > Focus will be on the following phones: > > - Bria Professional > > - SNOM > > - LG-Nortel 68xx > > - Nortel IP 12x0 > > - Polycom SoundPoint IP > > > > My plan is to decommission the current SNOM provisioning URL, so > > existing deployments will need to manually reconfigure each > phone upon > > upgrade. > > Isn't there some way we could redirect the old URLs to the new one? We could maintain the old URL. Probably as an alias configured in the web server, or even a symbolic link on the hard drive. > > I also hope to add a new CounterPath Bria provisioning URL: > > https://<server>/<serial#> This will be more secure (no VM > PIN sent > > in cleartext). It will also allow a single account to use multiple > > Bria profiles, which is not currently possible. But this > URL can't be > > put into DHCP, so we'll maintain the current URL too. > > Is there no way to put some additional path into that URL? > https://<server>/profile/bria/<serial#> or something? Certainly. Though I was thinking the shorter the better. The main factor is that if you aren't using DHCP Option 66, then you have to manually enter this URL many times. This is a challenge on Polycoms, where you must use the phone keypad. My goal was to make it not worse than today, where you only need to enter the IP address. I was also planning to maximize the number of different phones that could be handled with the same DHCP Option 66 value. Alberto wrote: > What are your plan here for Snoms? As you already know Snom > use option dhcp 66 and 67. > Updating the Snom plug-in I found this as a partial limit in > what I'd like to do. > Option 66 is a URL but it cannot contain a path Option 67 is > the settings file name but CAN contain a path To make it clearer: > Snom will work with this: > 66: http://example.org:8090 > 67: /phone/profile/docroot/{mac}.xml Here's what this would have been for a SNOM using HTTPS: 66: https://example.org 67: {mac}.xml > What I'm proposing is: unify http and tftp directory in a > unique provisioning directory and add four configurable > switch in sipxconfig to enable/disable tftp, ftp, http, https > provisioning of the same unique directory. More services Yes, except that when using HTTPS you still need to have an HTTP server for Polycoms to use for their BootROM and to load the sipXecs CA certificate. So TFTP, FTP, and HTTPS docroots would all be the same directory. SNOM profiles would start getting put here, so they could start using HTTPS. The new HTTP docroot would have Polycom BootROM and the sipXecs CA certificate. But it would also have a copy of the generated SNOM profiles, so they could continue using HTTP. Also for more background, here's how you would've loaded the default sipXecs CA cert on a Polycom: - Navigate Menu - 3 - 2 - 456 (password) - "Enter" softkey - 1 - 3 - 1 - 1 - at the "Enter URL:http://"; prompt, enter for example "47.134.207.100/1". Press the * key for dot, and the # key 3 times for slash. - "Enter" softkey - "Accept" softkey I've put a link to this thread in the JIRA, for when the issue is re-visited. Thank you all for the feedback. -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
