[Home]

Summary:ASTERISK-24308: Call IDs in Asterisk 12: Planning
Reporter:Jonathan Rose (jrose)Labels:
Date Opened:2014-09-08 12:03:57Date Closed:2017-12-17 15:41:51.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Core/Bridging Core/Channels Core/Logging
Versions:SVN 12.6.0 13.0.0-beta1 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Attachments:
Description:Call IDs have decayed somewhat since their initial release in Asterisk 11, largely on account of the new bridging architecture. This task is to plot out expected behavior for Call IDs in Asterisk 12+, to define the concept of a call for this purpose so that we can more readily identify if/when this feature goes off the rails in the future, and to plan a series of tests for ideal call ID behavior.



Note: I filed this as a regression bug on account of the following use case:

1. SIP/A calls SIP/B -- they each start with C-00000000
2. SIP/A starts attended transfer of SIP/B to SIP/C -- SIP/A (separate channel) is in a call with SIP/C with C-00000001
3. SIP/A completes transfer, SIP/B and SIP/C are now in a call but each have the same call IDs from before (SIP/B is C-00000000 and SIP/C is C-00000001)

In Asterisk 11, the call ID for SIP/B and SIP/C would be unified as C-00000001. Taking C-00000001 may or may not be the ideal behavior, but the fact that they should have the same call ID once they are bridged together is more or less certain.
Comments:By: Jonathan Rose (jrose) 2014-09-08 14:01:45.293-0500

I've determined that in the above case that B taking on C-00000001 is most likely the correct behavior in the bridging model as well since it joined C's bridge and not vice-versa. So if the effort is completed to the current spec, the 11 behavior for this transfer scenario should stand.