On Wed, Aug 19, 2009 at 4:01 PM, Dale Worley<[email protected]> wrote: > 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
I agree we need this level of distinction if we want to do INVITE style of third part call control a-la RFC3275. In this case, perhaps it would suffice to return error for the second call attempt if there are two concurrent call attempts ( after all the agent can try again and besides we have no long term state information about the state of any call in progress -- all we have is the state of the ongoing call setup attempt). 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/
