Hi,

Below is a short description of our solution proposal for this issue :
- sipXconfig database should have a new table representing the 
discovered devices. One typical entry will contain the MAC address, the 
IP and the vendor. The MAC address will be the primary key of the table.
- a new manager will be created being responsible with the discovered 
devices table management (updating, creating, retrieving, etc.).
- the device discovery page will retrieve the devices from the database 
using the newly created manager. There will be no other modifications. 
The page will still be filtering the devices shown (only the devices 
which are not saved in the database as a phone or gateway will be 
displayed) and the user will be able to save the devices in the database 
after selecting the corresponding models.
- a new web service will be hosted on sipXconfig , service responsible 
for updating the discovered devices table in sipXconfig database with 
new informations. This service will expose an update method which takes 
an array of devices as a parameter and puts them into the database using 
the newly created manager.

This was the server-side part (from the web service point of view).

As for the client-side part, the discover facility will be able to 
connect to the newly created web service and invoke methods to update 
the devices in the database.
I think the discover facility should not be responsible for checking if 
the devices discovered are already in the database, instead it should 
only be responsible with sending a list with the devices, and the web 
service will insert the new devices, and update the old ones. For this 
reason i believe we need the web service to publish only one method 
(something like: update(<discovered devices array>) ). What do you think 
? do we need other supplementary methods ?


Please share your thoughts on our approach of the subject.

Thanks,
Bogdan
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to