On Mon, Mar 3, 2014 at 2:47 PM, Scott Griepentrog <sgriepentrog@xxxxxxxxxx> wrote: > > As an update, the following plan is being implemented (resulting from a combination of comments on app-dev and on reviewboard): > > For each object type (channels, bridge, playback, recording, snoop) there will be a: > > POST /objecttype/specifiedid > > operation that will create the object with that ID. The > > POST /objecttype > > will also create the object, but will use the previously existing unique id creation method. It will also have the optional objectId query parameter to allow it to be specified (since there are already two methods defined in the code, and it makes reusing existing libraries more convenient by adding a param instead of changing the URI processing). > > For the channels object type, there is a query parameter otherChannelId which provides the name for the second channel when originating with a Local channel. If otherChannelId is not specified, but a uniqueid for the first channel is given, the second channel will be assigned the same value with a ;2 suffix (matching the channel name convention). > > The AMI implementation of channel origination matches ARI except that there is one origination method with two optional parameters, ChannelId and OtherChannelId. > > Also: in both AMI and ARI, the otherChannelId value is ignored if channelId is not specified. > +1 -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger@xxxxxxxxxxxxxx | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
