[asterisk-app-dev] Question on implementation of "assigned" uniqueid when creating channels.

Scott Griepentrog sgriepentrog at digium.com
Mon Mar 3 13:47:58 CST 2014


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 at digium.com> wrote:

> On Fri, Feb 21, 2014 at 2:45 PM, Matthew Jordan <mjordan at digium.com>
> wrote:
> > On Fri, Feb 21, 2014 at 12:04 PM, Richard Mudgett <rmudgett at digium.com>
> wrote:
> >>
> >>
> >>
> >> On Fri, Feb 21, 2014 at 10:56 AM, Scott Griepentrog
> >> <sgriepentrog at digium.com> 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 at bar, with the other Local
> channel half being placed in yackity at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>



-- 
[image: Digium logo]
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140303/b7398c84/attachment.html>


More information about the asterisk-app-dev mailing list