On Mon, Jul 20, 2009 at 9:12 AM, Damian Krzeminski<[email protected]> wrote: > Peter Fowler wrote: >> >> As part of my Personal Assistant work I need the ability to initiate a >> call between two parties. >> >> Currently there is a REST API (URL) for making a call from a SipX user >> target SIP address as follows >> >> _https://username:password@<domain_name:8443/sipxconfig/rest/call/<target_ >> <https://username:password@<domain_name:8443/sipxconfig/rest/call/<target>> >> >> Where target can be a digit string (eg. 200) or a SIP address. The >> source of the call is the >> SIP address of the user <username>. Ie. The user's desktop phone is >> called then a refer is done to transfer the call >> the target. >> >> I would like to generalize/extend this URL in a backwards compatible way >> as follows >> >> _https://username:password@<domain_name:8443/sipxconfig/rest/call/<target>?source=<source_ >> <https://username:password@<domain_name:8443/sipxconfig/rest/call/<target>?source=<source>> >> > > Makes sense. > >> >> Where <source> is a SIP address. >> >> The source is called first then a refer is done to the target. In this >> way if the user is not at his her desk >> And has indicated to the client software where he/she is then the client >> software can perform the >> appropriate click to call. Eg. >> >> _https://200:[email protected]:8443/sipxconfig/rest/call/JohnSmith?source=PeterCellPhone_ >> >> >> Will result in a call to my cell phone then a refer of that call to >> JohnSmith URI. >> >> To prevent toll fraud, all call operations would need to be performed >> with the credentials of the call initiator (200 in this example) >> > > Permission to call a number is not the same as a permission to initiate the > call from it. IOW - the fact that I can call woof does not mean that I > should be able to make woof call Kevin. > We might need a slightly more elaborate permission scheme to support > something like this, ideas?
Relocating the third party controller in a commons package makes a lot of sense. I do not think it should be necessary to run sipxconfig to do third party call control. One would need to have access to the user database to retrieve passwords. I think this does not need any new permission scheme. I believe this is already enforced. If you call Woof and send Woof a REFER then Woof does an INIVITE which will be challenged in the current scheme of things. I would be glad to volunteer for the task of stripping out and repackaging the third party call controller ( i.e. rewriting it as needed ) but perhaps if somebody else would like to tinker with JAIN-SIP, I would be happy to assist that person do so given that I am openfiring away at the moment. Ranga > > >> To ensure calling permissions are enforced. >> >> This generalization would be in keeping with the spirit of XX-5532. >> >> If the feedback favorable enough I will add a note to XX-5532. > > Open a new issue. I'll probably close XX-5532 and start opening separate > issues with request for a particular APIs. > > Damian > > _______________________________________________ > 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/
