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? > 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/
