[asterisk-dev] Defining a call under the new bridging architecture

[Mark Michelson]

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.