On Mon, 2009-08-17 at 14:58 -0400, M. Ranganathan wrote: > After the scrum this morning and further discussions with Robert, I am > revising some things with the call controller ( already): > > 1. http PUT will create the call. The URL format will be > https://domain:6666/callcontroller/method/agent/caller/callee?pin=xxxx > > (The CallController, like any good superbeast, will run on port 6666 > and I am not giving up that port - sorry Woof! ) > > 2. http GET will query about the call setup status. The URL format will be > > https://domain:6666/callcontroller/caller/callee?pin=xxxx > > The status will only be returned for the call setup. This is a "fire > and forget" type of call controller. It uses REFER. The status will > be kept around only for the call setup time. i.e. it will disappear > when the Dialog that created the status is terminated.
We need some way to distinguish several calls from the same caller to the same callee. This sounds sort of academic, but SIP went through some evolution before people realized that it must handle multiple calls between two endpoints in a fully generalized way. Just think about two users requesting a call between the same two endpoints... Fortunately, this is straightforward to do in REST: We set up a URL that denotes the collection of calls between caller and callee: http://host-port/.../caller/callee (omitting a number of elements that serve orthogonal purposes). We create a call by "POST http://host-port/.../caller/callee";, which returns information about the call, including the URI of the call, let's say http://host-port/.../caller/callee/xyzzy or http://host-port/.../xyzzy1234pqrs. Then we can retrieve the status of the call by "GET http://host-port/.../caller/callee/xyzzy";. This is fully RESTful by the authority of http://en.wikipedia.org/wiki/Representational_State_Transfer. Ranga tells us that Zimbra does not support POST, which is kinda strange if it wants to support REST. But checking back with Wikipedia gives a solution: A member resource can be created by doing a PUT to an invented member resource URI: "PUT http://host-port/.../caller/callee/xyzzy";. Then the server uses the first parts of the path to create the call, and uses the last part of the path as the name of the new call. Of course, this requires that the clients can generate non-colliding names, but random strings with sufficient entropy will suffice. Dale _______________________________________________ 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/
