Re: Question on implementation of "assigned" uniqueid when creating channels.

[Scott Griepentrog <sgriepentrog@xxxxxxxxxx>]

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.

On Tue, Feb 25, 2014 at 11:06 AM, Matthew Jordan <mjordan@xxxxxxxxxx> wrote:

On Fri, Feb 21, 2014 at 2:45 PM, Matthew Jordan <mjordan@xxxxxxxxxx> wrote:
> On Fri, Feb 21, 2014 at 12:04 PM, Richard Mudgett <rmudgett@xxxxxxxxxx> wrote:
>>
>>
>>
>> On Fri, Feb 21, 2014 at 10:56 AM, Scott Griepentrog
>> <sgriepentrog@xxxxxxxxxx> wrote:
>>>
>>> Hi all-
>>>
>>> I'm working on the ability to set the uniqueid on channel creation via ami
>>> and ari, and I've run into a quandary:
>>>
>>> When Asterisk dials over chan_local, it creates a LOCAL/something;1
>>> channel, and another LOCAL/something;2 channel to handle the other end of
>>> the call.  If I'm specifying the uniqueid when I originate the call, I would
>>> presume it would be set to the ;1 channel, as that's the one I'm actually
>>> talking to.  But should there be something identifiable (rather than the
>>> standard 012345678.123 uniqueid format) on the ;2 channel?  For example, if
>>> I create the ;1 channel as 'MyCustomId', would it be useful to have the
>>> uniqueid of the ;2 channel be 'MyCustomId;2' ?
>>>
>>> Although it's probably not a good idea, it's not technically impossible to
>>> set the same 'MyCustomId' to both channels.  Any other ideas on how best to
>>> handle this?
>>
>>
>> It is definitely not a good idea to have both the ;1 and ;2 channels to have
>> the same uniqueid.
>> They are different channels and if you look up a channel by uniqueid you
>> won't know which
>> local channel you will get.
>>
>> Pretty much the choices you have are:
>> 1) Give ;1 the requested id and let the ;2 generate its own id.
>>
>> 2) Give ;1 the requested id and give the ;2 the same id with an appended ;2
>> or some other differentiator that lets the two channels be associated by a
>> similar id.
>>
>> 3) Give ;1 the requested id and give the ;2 an extra given id by the
>> requester.  This option has the drawback of requiring the user to pass two
>> ids when creating a local channel.
>>
>
> I'd be very interested to hear more opinions on this one - but my
> inclination is either option (2) or option (3).

Ben Langfeld and I talked briefly about this in #adhearsion, and he
had the suggestion of doing Option 3 and falling back to Option 2.
Below is what this may look like from an API perspective:

AMI:

Originate a Local channel to extension foo@bar, with the other Local
channel half being placed in yackity@bar. The first Local channel half
would receive the channel ID of my-poorly-named-id-1, while the second
Local channel half would receive the channel ID of
my-poorly-named-id-2.

Action: Originate
Channel: Local/foo@bar
Exten: yackity
Context: bar
Priority: 1
Async: True
ChannelId: my-poorly-named-id-1
OtherChannelId: my-poorly-named-id-2

----

Originate a SIP channel to endpoint foo, and execute the dialplan at
yackity@bar. The channel would receive the channel ID of
my-poorly-named-id-1, while the second the channel ID of
my-poorly-named-id-2 would simply be ignored.

Action: Originate
Channel: SIP/foo
Exten: yackity
Context: bar
Priority: 1
Async: True
ChannelId: my-poorly-named-id-1
OtherChannelId: my-poorly-named-id-2 ; IGNORED

----

ARI:

Originate a Local channel to extension foo@bar, with the other Local
channel half being placed in a Stasis application. The first Local
channel half would receive the channel ID of my-poorly-named-id-1,
while the second Local channel half would receive the channel ID of
my-poorly-named-id-2.

POST /channels/?endpoint=Local/foo@bar&app=Stasis&appArgs=do_stuff&channelId=my-poorly-named-id-1&otherChannelId=my-pooly-named-id-2

----

Originate a Local channel to extension foo@bar, with the other Local
channel half being placed in a Stasis application. The first Local
channel half would receive the channel ID of my-poorly-named-id-1,
while the second Local channel half would receive the channel ID of
my-poorly-named-id-1;2. Note that this falls back to Option 2, since
it needs to give the channel a unique ID still.

POST /channels/?endpoint=Local/foo@bar&app=Stasis&appArgs=do_stuff&channelId=my-poorly-named-id-1

----

Thoughts?

Matt

--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

--

Scott Griepentrog
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
Check us out at: http://digium.com · http://asterisk.org

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev