----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3601/#review12855 -----------------------------------------------------------
Ship it! Ship It! - Matt Jordan On July 21, 2014, 5:19 p.m., rmudgett wrote: > > ----------------------------------------------------------- > 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. > > > Bugs: AFS-65 > https://issues.asterisk.org/jira/browse/AFS-65 > > > Repository: Asterisk > > > Description > ------- > > 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 > ----- > > /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 > ------- > > * 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
