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
