[asterisk-dev] 2 Feature request

[Jacob.E.Miles at L-3Com.com]

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Matthew
Jordan
Sent: Sunday, January 20, 2013 7:50 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] 2 Feature request

On 01/17/2013 02:02 PM, Jacob.E.Miles at L-3Com.com wrote:
> *_Feature Request #1_*
> 
> Add LinkedID to AMI Events, using the LinkedID to group channels that 
> are in the same call is very useful except for the fact that the 
> LinkedID is not sent in any of the AMI Events that I could find 
> (Asterisk 1.8.13.0).  It would be very beneficial to have this key 
> piece of information to be sent.
> 
>  
> 
> *_Feature Request #2_*
> 
> Set the LinkedIDs for all participants of a Conference to match. 
> LinkedIDs are the easiest way of knowing which channels are linked 
> together and so setting the LinkedIDs for the participants of a 
> Conference only makes sense.
> 

Correct me if I'm wrong, but it sounds like what you're requesting is
the ability to have some identifier that tells you what all parties are
talking together.

The AMI specification proposal on the wiki [1] does this, but does so
through the concept of a Bridge identifier. Channels are known to be
passing frames between each other when they enter the same Bridge
(denoted by a BridgeEnter event) and are known to no longer be passing
frames when they leave a Bridge (denoted by a BridgeLeave event).
Bridges have their own unique identifier that identify for their own
lifetime. This extends from two party bridges to conference bridges.

AMI clients can use the BridgeUniqueid to know which channels are
talking together.

The concept of a LinkedID that is independent of bridge state for this
purpose is doable, but runs into some questions that have to be answered
when you consider transfer operations or bridging scenarios more complex
than two party bridges.

Say we have Channel A who calls Channel B. Maybe we assign a default
LinkedID to Channel A in its Newchannel event (even though it isn't
linked yet) because we assume it will eventually be bridged. Note that
if we don't do this, we'll have to send some event when Channel A is
bridged with some other channel - what event that is we'll have to
define if we go down that road, so let's assume we have it on inbound
channel creation. We call Channel B - it inherits the LinkedID from
Channel A. So far so good.

Channel B blind transfers itself off to another extension. Does it keep
the LinkedID? If so, how do we know that it isn't talking to Channel A?
Does it simply drop it? If so, what event is this communicated on? Does
an AMI client infer the lack of a LinkedID to mean that Channel B is no
longer talking to Channel A? If so, that means that on every event
received for a Channel, where previously a LinkedID existed, an AMI
client has to look to see if a LinkedID is gone and update its concept
of bridging appropriately.

Consider conference scenarios. Three inbound channels are created -
Channel A, B, and C - and are all created independently. Each have a
LinkedID assigned to them, as we don't know at the time of their
creation whether or not they will be dialing someone or not. Each join
the same ConfBridge. Which LinkedID wins? What event do we use to notify
clients that a LinkedID was changed?

It's certainly possible to use a LinkedID, but treating Bridges as a
first class object means that this information is well defined and
conveyed explicitly when channels interact with other channels in any
scenario. I think this meets the intent of your feature request, but
does so in a way that handles complex bridging scenarios.

[1] https://wiki.asterisk.org/wiki/display/AST/AMI+1.4+Specification

------------------------------------------------------------------------
------------------------------------------------

Yes, I am looking for some identifier that tells me what parties are
connected/talking together.  The BridgeUniqueid does look to fit that
bill, as long as it is a value that is maintained and sent with
ChannelUpdate Events.  This is the Event that I currently key off of for
all my channel information.  To get things working for now with Asterisk
1.8.X I have gone through the code and added the existing LinkedID
variable to the list of key/value pairs sent in the ChannelUpdate Event
and it is working so far for all simple calls including transfers.  The
only issue I have with my approach is with Conferences (MeetMe) in which
case each participant has a different LinkedID.  So I made another small
change in that when a Channel Joins a MeetMe I set its LinkedID to that
of the MeetMe (Psuedo/DAHDI) channel.  This so far has met all the needs
that I have found so far.  I was just trying to look to the future and
get something like what I already have working implemented so that I did
not have to maintain a separate code base.

As AMI 1.4 looks to be releasing with Asterisk 12 so it doesn't look
like it is something I can get tested and working until its released
towards the end of the year.  Which is little help for the near future.
Adding the existing LinkedID to the ChannelUpdate Event is a minor
change at best and in my opinion something that could be added to the
current releases.  If not, I will maintain my own code mods until AMI
1.4 is release with Asterisk 12 and then make the adjustments needed to
use the BridgeUniqueid value.

Jacob