Damian wrote:
...
> May it's time reconsider the idea or reusing
> auto-provisioning groups (and extend/buiod sipXconfig
> auto-provisioning instead of building a parallel system). In
> that way admins can configure patterns for new devices
> reusing entire sipXconfig machinery. And all changes and
> updates to plug-ins will be picked up automatically.
Yes, I'm starting to see that in many ways it would make sense for
Auto-Provision to reside in sipXconfig. We should indeed consider
moving it there at some point.
But in moving it I would like clarity on how it would interact with the
existing sipXconfig machinery. i.e. A clean delineation between the
two. (I am reluctant to combine it with the existing Device Discovery
functionality.)
The initial Auto-Provision functionality should be checked in shortly,
and I think is fairly easy to understand. There are three main classes:
Configuration, Servlet, and Queue. The roles of the first two are
self-explanatory at this point. The Queue class is where the Servlet
thread enqueues the data for a detected phone. An internal Queue thread
then takes this data and makes the REST API request to sipXconfig.
> I'd really like to end up with a system that can be enhanced
> for various protocols and devices. I feel - possibly unfairly
> - that this feature hijacks us into Polycom territory.
I don't think Auto-Provisioning hijacks us into Polycom-only territory.
It could easily handle Snom phones if it owned port 80, which I think it
should at some point.
It could easily handle CounterPath Bria, both provisioning and
auto-provisioning.
We're in process of adding the Nortel IP 12x0 phones. It will require
some phone firmware changes, but they are relatively simple:
1. If there is a failure to TFTP retrieve "SIP<<<MAC>>>.xml", then
phone should attempt to retrieve "SIPdefault.xml". If it succeeds, then
treat the XML contents normally.
2. In processing the XML, add a new "redirect" node. For example, a
short XML file could be:
<?xml version="1.0" encoding="ISO-8859-1"?>
<redirect>http://master.fun.pm:8185</redirect>
Upon receiving a re-direct, the phone would again attempt to load
its MAC config file, but use this value instead of the existing
"Provisioning URL" value. (Don't store this value as the new
"Provisioning URL", just use it and discard it.)
3. In making HTTP requests, put the specific model of the phone in
the User-Agent header. i.e. Use 1210, 1220, or 1230 instead of "12x0".
-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/
