On Tue, Aug 18, 2009 at 9:21 AM, Damian Krzeminski<[email protected]> wrote: > 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.
We have three entities : agent, caller and callee. If you want the call controller to masquerade as 201 from sipxconfig and establish a call from 201 to 202 here is the syntax. echo "Initiating a call between 201 and 202 as 201" curl -k -T curlcommand.sh https://sipxtest.sipxtest.net:6666/callcontroller/refer/201/201/202 sleep 20 echo "Query call setup progress for call between 201 and 202 as 201" curl -k https://sipxtest.sipxtest.net:6666/callcontroller/refer/201/201/202 The refer is there because I am not sure if we want to support other things (such as INVITE initiated third party call control ) > > >>> >>>> (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/ > -- 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/
