[asterisk-dev] 2 Feature request

[Matthew Jordan]

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

-- 
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