On Wed, Sep 9, 2009 at 4:53 PM, Martin Steinmann <[email protected]>wrote:
> > > > >On Wed, Sep 9, 2009 at 12:45 PM, Scott Lawrence < > [email protected]> wrote: > > >On Wed, 2009-09-09 at 01:30 -0400, M. Ranganathan wrote: > >> > >> Hello! > >> > >> Here is the description of the sipx rest service container that > >> Raymond and I worked on and that I just checked into SVN. The > >> description is a bit sketchy at the moment but I would value your > >> thoughts and ideas on the following: > >> > >> http://sipx-wiki.calivia.com/index.php/SIPXRest_Service_container > >> > >> The third party call controller now runs as a sipXrest service plugin. > >> For those who are using it, here is what you have to do : > >> > >> make all install in the following directories (in that order ) : > >> > >> sipXrest > >> > >> sipXcallController > >> > >> Then edit sipXrest/sipxrest.xml > >> > >> Copy it over to etc/sipxpbx > >> > >> Star the SipXrest container using > >> > >> sh sipxrest.sh from the build directory. SipXconfig support for all of > >> this has been requested in a JIRA issue. > >> > >> In addition to the third party call controller, a call watcher service > >> and a CDR service ( written by Raymond ) will be running in this > >> service container. > >> > >> I encourage you to think of light weight services that can be housed > >> in this container and that can play a part in integration of sipx with > >> the world at large. > > >The part I'm struggling with is why we would want to put REST interfaces > >into a process that doesn't have the data the interface needs. > > > > >For example, why put a REST interface for CDR data into anything but the > >call resolver? > > > > > > >One argument for a central point of integration could be ease of > administration. Thus we would have a single process to manage / administer > (i.e. the REST server and >the ports that it uses ) that external > processes (outside the sipx domain) need to interact with. Thus far it has > been sipxconfig that served this purpose for both signaling >and > administration. We can now have one more process - sipXrest that performs > this function for signaling services. > > > >Ranga > > > > Would that develop into a REST based “CTI” interface that we can make > richer over time? Having a central point would mean that if you want to > access this from outside the enterprise, you only have to configure the > firewall to route requests to one point as opposed to potentially many > different servers. > > --martin > > > I fear to answer in the affirmative without knowing what exactly this means but these are dangerous times so here it goes - "Yes we can!" If you could point me at specifics about what you would like to see, that would be a good start to do some thinking. Ranga -- M. Ranganathan
_______________________________________________ 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/
