<div dir="ltr"><div class="gmail_default" style="color:rgb(102,0,0)">As an update, the following plan is being implemented (resulting from a combination of comments on app-dev and on reviewboard):</div><div class="gmail_default" style="color:rgb(102,0,0)">
<br></div><div class="gmail_default" style="color:rgb(102,0,0)">For each object type (channels, bridge, playback, recording, snoop) there will be a:</div><div class="gmail_default" style="color:rgb(102,0,0)"><br></div><div class="gmail_default" style="color:rgb(102,0,0)">
POST /objecttype/specifiedid</div><div class="gmail_default" style="color:rgb(102,0,0)"><br></div><div class="gmail_default" style="color:rgb(102,0,0)">operation that will create the object with that ID. The</div><div class="gmail_default" style="color:rgb(102,0,0)">
<br></div><div class="gmail_default" style="color:rgb(102,0,0)">POST /objecttype </div><div class="gmail_default" style="color:rgb(102,0,0)"><br></div><div class="gmail_default" style="color:rgb(102,0,0)">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).</div>
<div class="gmail_default" style="color:rgb(102,0,0)"><br></div><div class="gmail_default" style="color:rgb(102,0,0)">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).</div>
<div class="gmail_default" style="color:rgb(102,0,0)"><br></div><div class="gmail_default" style="color:rgb(102,0,0)">The AMI implementation of channel origination matches ARI except that there is one origination method with two optional parameters, ChannelId and OtherChannelId.</div>
<div class="gmail_default" style="color:rgb(102,0,0)"><br></div><div class="gmail_default" style="color:rgb(102,0,0)">Also: in both AMI and ARI, the otherChannelId value is ignored if channelId is not specified.</div><div class="gmail_default" style="color:rgb(102,0,0)">
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 11:06 AM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Feb 21, 2014 at 2:45 PM, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:<br>
> On Fri, Feb 21, 2014 at 12:04 PM, Richard Mudgett <<a href="mailto:rmudgett@digium.com">rmudgett@digium.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Fri, Feb 21, 2014 at 10:56 AM, Scott Griepentrog<br>
>> <<a href="mailto:sgriepentrog@digium.com">sgriepentrog@digium.com</a>> wrote:<br>
>>><br>
>>> Hi all-<br>
>>><br>
>>> I'm working on the ability to set the uniqueid on channel creation via ami<br>
>>> and ari, and I've run into a quandary:<br>
>>><br>
>>> When Asterisk dials over chan_local, it creates a LOCAL/something;1<br>
>>> channel, and another LOCAL/something;2 channel to handle the other end of<br>
>>> the call. If I'm specifying the uniqueid when I originate the call, I would<br>
>>> presume it would be set to the ;1 channel, as that's the one I'm actually<br>
>>> talking to. But should there be something identifiable (rather than the<br>
>>> standard 012345678.123 uniqueid format) on the ;2 channel? For example, if<br>
>>> I create the ;1 channel as 'MyCustomId', would it be useful to have the<br>
>>> uniqueid of the ;2 channel be 'MyCustomId;2' ?<br>
>>><br>
>>> Although it's probably not a good idea, it's not technically impossible to<br>
>>> set the same 'MyCustomId' to both channels. Any other ideas on how best to<br>
>>> handle this?<br>
>><br>
>><br>
>> It is definitely not a good idea to have both the ;1 and ;2 channels to have<br>
>> the same uniqueid.<br>
>> They are different channels and if you look up a channel by uniqueid you<br>
>> won't know which<br>
>> local channel you will get.<br>
>><br>
>> Pretty much the choices you have are:<br>
>> 1) Give ;1 the requested id and let the ;2 generate its own id.<br>
>><br>
>> 2) Give ;1 the requested id and give the ;2 the same id with an appended ;2<br>
>> or some other differentiator that lets the two channels be associated by a<br>
>> similar id.<br>
>><br>
>> 3) Give ;1 the requested id and give the ;2 an extra given id by the<br>
>> requester. This option has the drawback of requiring the user to pass two<br>
>> ids when creating a local channel.<br>
>><br>
><br>
> I'd be very interested to hear more opinions on this one - but my<br>
> inclination is either option (2) or option (3).<br>
<br>
</div></div>Ben Langfeld and I talked briefly about this in #adhearsion, and he<br>
had the suggestion of doing Option 3 and falling back to Option 2.<br>
Below is what this may look like from an API perspective:<br>
<br>
AMI:<br>
<br>
Originate a Local channel to extension foo@bar, with the other Local<br>
channel half being placed in yackity@bar. The first Local channel half<br>
would receive the channel ID of my-poorly-named-id-1, while the second<br>
Local channel half would receive the channel ID of<br>
my-poorly-named-id-2.<br>
<br>
Action: Originate<br>
Channel: Local/foo@bar<br>
Exten: yackity<br>
Context: bar<br>
Priority: 1<br>
Async: True<br>
ChannelId: my-poorly-named-id-1<br>
OtherChannelId: my-poorly-named-id-2<br>
<br>
----<br>
<br>
Originate a SIP channel to endpoint foo, and execute the dialplan at<br>
yackity@bar. The channel would receive the channel ID of<br>
my-poorly-named-id-1, while the second the channel ID of<br>
my-poorly-named-id-2 would simply be ignored.<br>
<br>
Action: Originate<br>
Channel: SIP/foo<br>
Exten: yackity<br>
Context: bar<br>
Priority: 1<br>
Async: True<br>
ChannelId: my-poorly-named-id-1<br>
OtherChannelId: my-poorly-named-id-2 ; IGNORED<br>
<br>
----<br>
<br>
ARI:<br>
<br>
Originate a Local channel to extension foo@bar, with the other Local<br>
channel half being placed in a Stasis application. The first Local<br>
channel half would receive the channel ID of my-poorly-named-id-1,<br>
while the second Local channel half would receive the channel ID of<br>
my-poorly-named-id-2.<br>
<br>
POST /channels/?endpoint=Local/foo@bar&app=Stasis&appArgs=do_stuff&channelId=my-poorly-named-id-1&otherChannelId=my-pooly-named-id-2<br>
<br>
----<br>
<br>
Originate a Local channel to extension foo@bar, with the other Local<br>
channel half being placed in a Stasis application. The first Local<br>
channel half would receive the channel ID of my-poorly-named-id-1,<br>
while the second Local channel half would receive the channel ID of<br>
my-poorly-named-id-1;2. Note that this falls back to Option 2, since<br>
it needs to give the channel a unique ID still.<br>
<br>
POST /channels/?endpoint=Local/foo@bar&app=Stasis&appArgs=do_stuff&channelId=my-poorly-named-id-1<br>
<br>
----<br>
<br>
Thoughts?<br>
<div class="HOEnZb"><div class="h5"><br>
Matt<br>
<br>
--<br>
Matthew Jordan<br>
Digium, Inc. | Engineering Manager<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br>
<br>
_______________________________________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><img alt="Digium logo" src="https://my.digium.com/images/graphics/digium_RGB_signature.gif" width="288" height="50" style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><div>
Scott Griepentrog<br>Digium, Inc · Software Developer<br>445 Jan Davis Drive NW · Huntsville, AL 35806 · US<br>direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029<br>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> · <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br>
</div></div>
</div>