M. Ranganathan wrote: > 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. >
I guess I just did not understand the URL. Do you mind publishing an example (curl call or something similar) of what the client would have to send to establish the call. >> >>> (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? It should be authenticated as any other HTTP service: using BASIC or DIGEST authentication (or using SSL peer authentication). Passing PIN token as a parameter amounts to creating your own proprietary authentication scheme. 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/
