On 09/05/2014 05:50 PM, Jonathan Rose wrote:
So a little bit of background before I jump into this...
In Asterisk 11, I worked on a feature known as call identifier logging.
https://wiki.asterisk.org/wiki/display/AST/Call+Identifier+Logging
It's a somewhat clingy concept where channels are tagged with a unique
identity (unique within a single system anyway) and then as things
become involved with that call, the ID gets spread around between
multiple channels and multiple threads and anything logged by a thread
bound to a call ID will display the value of that call ID in the log
message ('[C-0000000a]' for instance).
For the most part this worked well in spite of complexities like
transfers and masquerades, but as of Asterisk 12 the new bridging
model came into play and some behaviors have changed a little and some
have regressed. SIP attended transfers for instance used to result in
both the transferee and the transfer target receiving a separate call
ID from the original call started by the transferer. Now the transfer
target just gets moved into the transferee's bridge and they both end
up with disjoint call IDs.
Technically, the above behavior isn't necessarily wrong. In the above
example, the transferer did actually start a second call with the
transfer target and simply put the transfer target into the same
bridge as the transferee. Neither of them really started a new call
from their perspective, but clearly that isn't a satisfactory result
because they are in a call together. It stands to reason that they
should be represented as being involved in the same call at that
point. But which call are they in? The whole thing is a Ship of
Theseus paradox and we need to decide what happens as parts start
falling off the ship.
https://wiki.asterisk.org/wiki/display/AST/Call+IDs+in+Asterisk+12+and+beyond
I've been drafting a wiki page to describe exactly what should
constitute a call within Asterisk. I've arrived at one fairly basic
definition. A call is a line of communication within Asterisk. This
means that channels independently communicating with Asterisk (such as
through an IVR or a PBX application like voicemail) are in their own
calls. When two or more channels become bridged together (in a way
that they begin to communicate), then those channels are now involved
in the same call. In order to resolve which call they should be
considered involved with, we need a set of propagation rules to
determine which call IDs should win when new lines of communication
start. This wiki page is concerned with determining what those rules
should be and with exploring the potential edge cases that come about
when the picture becomes more complicated than just a simple
multiparty bridge.
If anyone has any suggestions about either the definition of a call or
about the rules for call ID propagation, please review this wiki
article and respond either in the wiki comments or to this mailing
list post.
I had a read of this, and the only rule on there that I disagreed with was:
>Channel C1 leaves bridge B1 which owns X1. C1 is the last remaining
channel in the bridge when it leaves:
>C1 takes ownership of X1. The bridge remains affiliated with X1, but
should be disposed of shortly.
Mainly, the "but should be disposed of shortly" was what I disagreed
with here. This happens to be the case for bridges that are created by
app_dial or app_queue, but does not work well for things like Stasis
bridges. Stasis bridges are created and destroyed based on the
application's needs. For something like a conferencing app, it's
possible that the Stasis application will create a mixing bridge, and
then use that same bridge for multiple conference calls. Since the
bridge does not get disposed of after the last channel has left, the
bridge remains affiliated with its current call ID. Based on entering
rules, this means that all calls that use this bridge will end up
reusing the same call ID.
I think that the rule I cited should be amended such that C1 takes
ownership of X1 and the bridge becomes unaffiliated with any call ID.
Other than that the basic rules look good to me.
For unreal/local channels, I didn't quite understand the trouble you
were trying to communicate with the bullet point about the call ID
associated with the ;1 half of a local channel being the winning one. It
may help to provide a more concrete scenario with channel and bridge
names (and potentially even a diagram) that illustrates the problem.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev