On Mon, Aug 17, 2009 at 7:20 PM, Damian Krzeminski<[email protected]> wrote: > M. Ranganathan wrote: >> Hello >> >> 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 >> > > > If this is to feel like RESTful interface the URL should suggest that you > have a virtual collection of calls with PUT or POST adding a call and GET > retrieving its status.
POST cannot work apparently -- Zimbra does not support it. We have only HTTP GET and HTTP PUT. This is Fire and Forget style of third party call control - exactly the same as we had in sipxconfig. It uses REFER. Once it sends the REFER, it is out of the call setup path. Hence once you set up the call, you only have GET to query the status of the ongoing call setup ( via NOTIFY that the caller will send to the call setup agent). The CALL object is really just a "Call SETUP object". You really cannot do anything with that object other than query status during call setup - i.e. ask questions such as "was this call setup successful". If something more sophisticated is needed ( like the third party call controller that uses only INVITE and no REFER ) and stays in the call path, I would like to hear about that now. I can add that if needed. > > PUT something/something/something/call > GET something/something/something/call > > > This URLs look like you have a matrix of callers and callees. Is it really > needed? In the general form yes. You can have a trusted agent set up call between untrusted parties. I suppose in most (all?) use cases, some things get repeated in the URL path. > > >> (The CallController, like any good superbeast, will run on port 6666 >> and I am not giving up that port - sorry Woof! ) > > It's not like I am jealous or anything but I hope that call controller will > run on whatever port sipXconfig will tell it to run. But of course! sipXconfig is the master of data. ( I know you are after that cool port :-) ) > >> >> 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. > > If that's the case it would be better if you used POST to create a call. > POST can return a unique URL for a call that people can use to GET the call > setup status. I am not sure how: > > https://domain:6666/callcontroller/caller/callee?pin=xxxx > > can be made unique enough to check for the call setup status. There would be some simplifying assumptions- i.e. you can have only one call ongoing between caller and callee. Remember that we are only checking if the call setup worked or not. HTTP POST is not possible - Zimbra does not support it. This leaves us with HTTP GET and HTTP PUT. HTTP GET was considered to be objectionable because of semantics (not withstanding the fact that HTTP itself is really meant for web page retrieval and we are using it for a style of RPC - so this whole thing is semantically flawed). HTTP PUT is not set up to return a URL. So how do we proceed ? HTTP PUT followed by HTTP GET. The same resource is used in both cases and is used to query a call setup between two users. Clearly there are some issues of concurrency. This would allow only a single call setup at a time between two users. > >> >> Any comments? Ask for changes now before I code it all up. >> > > The PIN as a parameter is rather unconventional. Is this a user PIN? If so > why do we need to pass it at all? Authorization (whatever method you > choose) should be done independently from parameters. You would not need to pass a pin if you were calling from a sipx service ( such as sipxconfig ). It will use secure HTTP connection and offer the same level of security that you currently have with xmlrpc over HTTP ( which does the same thing ). The pin is meant for external users ( not in the sipx domain) . It is available as a pintoken in validusers.xml. It is used for authentication when you log in today. Note that this is the clear text pin being passed in a secure connection as a http parameter. If we do not want to support such use cases, I can remove the pin and restrict usage of sipxcallcontroller to only to sipx services. But I am curious - how would you go about passing the pin and what authentication scheme would you suggest? Thanks for your comments! Ranga > > D. > > _______________________________________________ > 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/ > -- 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/
