----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3601/ -----------------------------------------------------------
(Updated July 21, 2014, 5:19 p.m.) Review request for Asterisk Developers. Changes ------- Tweak CHANGES queue accountcode propagation description. Bugs: AFS-65 https://issues.asterisk.org/jira/browse/AFS-65 Repository: Asterisk Description (updated) ------- Accountcode propagation: The current behavior is to simply set the accountcode of an outgoing channel to the accountcode of the channel initiating the call. It was done this way a long time ago to allow the accountcode set on the SIP/100 channel to be propagated to a local channel so the dialplan execution on the Local;2 channel would have the SIP/100 accountcode available. SIP/100 -> Local;1/Local;2 -> SIP/200 Propagating the SIP/100 accountcode to the local channels is very useful. Without any dialplan manipulation, all channels in this call would have the same accountcode. Using dialplan, you can set a different accountcode on the SIP/200 channel either by setting the accountcode on the Local;2 channel or by the Dial application's b(pre-dial), M(macro) or U(gosub) options, or by the FollowMe application's b(pre-dial) option, or by the Queue application's macro or gosub options. Before Asterisk v12, the altered accountcode on SIP/200 will remain until the local channels optimize out and the accountcode would change to the SIP/100 accountcode. Asterisk v1.8 attempted to add peeraccount support but ultimately had to punt on the support. The peeraccount support was rendered useless because of how the CDR code needed to unconditionally force the caller's accountcode onto the peer channel's accountcode. The CEL events were thus intentionally made to always use the channel's accountcode as the peeraccount value. With the arrival of Asterisk v12, the situation has improved somewhat so peeraccount support can be made to work. Using the indicated example, the the accountcode values become as follows when the peeraccount is set on SIP/100 before calling SIP/200: SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200 acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200 peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100 If a channel already has an accountcode it can only change by the following explicit user actions: 1) A channel originate method that can specify an accountcode to use. 2) The calling channel propagating its non-empty peeraccount or its non-empty accountcode if the peeraccount was empty to the outgoing channel's accountcode before initiating the dial. e.g., Dial and FollowMe. The exception to this propagation method is Queue. Queue will only propagate peeraccounts this way only if the outgoing channel does not have an accountcode. 3) Dialplan using CHANNEL(accountcode). 4) Dialplan using CHANNEL(peeraccount) on the other end of a local channel pair. If a channel does not have an accountcode it can get one from the following places: 1) The channel driver's configuration at channel creation. 2) Explicit user action as already indicated. 3) Entering a basic or stasis-mixing bridge from a peer channel's peeraccount value. You can specify the accountcode for an outgoing channel by setting the CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue applications. Queue adds the wrinkle that it will not overwrite an existing accountcode on the outgoing channel with the calling channels values. Accountcode and peeraccount values propagate to an outgoing channel before dialing. Accountcodes also propagate when channels enter or leave a basic or stasis-mixing bridge. The peeraccount value only makes sense for mixing bridges with two channels; it is meaningless otherwise. * Made peeraccount functional by changing accountcode propagation as described above. * Fixed CEL extracting the wrong ie value for the peeraccount. This was done intentionally in Asterisk v1.8 when that version had to punt on peeraccount. * Fixed a few places dealing with accountcodes that were reading from channels without the lock held. Diffs (updated) ----- /trunk/res/parking/parking_bridge_features.c 419127 /trunk/main/pbx.c 419127 /trunk/main/dial.c 419127 /trunk/main/core_unreal.c 419127 /trunk/main/channel.c 419127 /trunk/main/cel.c 419127 /trunk/main/bridge_basic.c 419127 /trunk/main/bridge.c 419127 /trunk/include/asterisk/channel.h 419127 /trunk/apps/app_queue.c 419127 /trunk/apps/app_followme.c 419127 /trunk/apps/app_dial.c 419127 /trunk/UPGRADE.txt 419127 /trunk/CHANGES 419127 Diff: https://reviewboard.asterisk.org/r/3601/diff/ Testing (updated) ------- * Ran tests from https://reviewboard.asterisk.org/r/3832/ all tests tagged with accountcode pass. * Set the accountcode on the calling channel and let the channel driver supply or not the accountcode for the outgoing channel. The acccountcode on the calling channel forces itself on the outgoing channel. This is the same as previous behavior. * Set the accountcode and peeraccount code on the calling channel and let the channel driver supply or not the acccountcode for the outgoing channel. The outgoing channel's accountcode and peeraccount got the calling channel's peeraccount and accountcode values respectively. * Let dialplan set accountcodes on channels and performed a DTMF attended transfer to create a three party bridge. When the transferrer channel left the three party bridge, the remaining two channels got the peeraccount updated to the other party. Unfortunately, you only see the updated peeraccount values in the CEL log when the channels leave the bridge. Throughout each of these tests, the CEL log had the expected peeraccount value. Some interpolation is needed in the CEL log for complicated accountcode manipulation because there aren't enough events to indicate when the account codes change. Note the peeraccount value is meaningless if the bridge does not contain two parties. Thanks, rmudgett
-- _____________________________________________________________________ -- 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