On Wed, Sep 9, 2009 at 5:36 PM, M. Ranganathan <[email protected]> wrote:
> > > 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 > > Martin, Were you perhaps referring to : http://track.sipfoundry.org/browse/XX-4737 Thanks > -- > M. Ranganathan > > -- 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/
