Hi all,

Damian and I were discussing this on Friday.  We both think it's the
best way for sipXprovision to use sipXconfig's phone config generation
capabilities.

I originally assumed it would be preferable to retrieve all the config
files in a single REST request.  But Polycoms do an HTTP GET for each
file, so there should be one REST request for each file.  (sipXprovision
could only make use of multiple files in the REST response if it
persisted the content between Polycom HTTP GET requests.)

So given that there will be one REST request per config file, does this
make sense?

   /phone/{phoneId}/profile/{name} - GET

Where the body of the HTTP response would be the configuration file
verbatim.  

ID would be the "phone_id" field of the same name from DB, likely
available from phone.getBeanId().  (See
http://list.sipfoundry.org/archive/sipx-dev/msg19801.html )


Note that each configuration file name is unique not only within the
phone, but also within system.  A /phone/profile/{name} resource URI
would be possible.  But sipXconfig would need to know how to extract the
serial number from every form of configuration file, which doesn't sound
practical.

So given that the REST client will be specifying the Phone ID, the REST
API must have a way for it to be discovered.  Perhaps:

- /phone?serialNumber={serialNumber} GET to query for a phone by serial
number.  Example response XML body:
      <phone>
          <phoneId>4</phoneId>
          <serialNumber>0004f21ed0d3</serialNumber>
          <model>polycom650</model>
          <description>Some text...</description>
       </phone>

- /phone POST must return the ID, regardless of whether the Phone was
just created or already existed.  This would be in an XML body, the same
as above.  

- /phone/{phoneId} GET should return the same XML body as above.
(sipXprovision won't need this GET, but it seems useful to have for
consistency.)


Thoughts?


-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/

Reply via email to