Review Board 1.7.16


accountcode: Slightly change accountcode propagation.

Review Request #3601 - Created June 6, 2014 and submitted

rmudgett
trunk
AFS-65
Reviewers
asterisk-dev
Asterisk
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.
* 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.
/branches/12/UPGRADE.txt
Diff Revision 3 Diff Revision 4
[20] 18 lines
[+20]
19
=== UPGRADE-10.txt  -- Upgrade info for 1.8 to 10
19
=== UPGRADE-10.txt  -- Upgrade info for 1.8 to 10
20
=== UPGRADE-11.txt  -- Upgrade info for 10 to 11
20
=== UPGRADE-11.txt  -- Upgrade info for 10 to 11
21
===
21
===
22
===========================================================
22
===========================================================
23

    
   
23

   
24
From 12.3.1 to 12.4.0:
24
From 12.4.0 to 12.5.0:
25

    
   
25

   
26
 - The accountcode propagation is now consistently propagated to outgoing
26
 - Added functional peeraccount support.  Except for Queue, the

    
   
27
   accountcode propagation is now consistently propagated to outgoing
27
   channels before dialing.  The channel accountcode can change from its
28
   channels before dialing.  The channel accountcode can change from its
28
   original non-empty value on channel creation for the following specific
29
   original non-empty value on channel creation for the following specific
29
   reasons.  One, dialplan sets it using CHANNEL(accountcode).  Two, an
30
   reasons.  One, dialplan sets it using CHANNEL(accountcode).  Two, an
30
   originate method that can specify an accountcode value.  Three, the
31
   originate method that can specify an accountcode value.  Three, the
31
   calling channel propagates its peeraccount or accountcode to the
32
   calling channel propagates its peeraccount or accountcode to the
32
   outgoing channel's accountcode before dialing.  The change has two
33
   outgoing channel's accountcode before dialing.  The change has two
33
   visible effects.  One, local channels now cross accountcode and
34
   visible effects.  One, local channels now cross accountcode and
34
   peeraccount across the special bridge between the ;1 and ;2 channels
35
   peeraccount across the special bridge between the ;1 and ;2 channels
35
   just like channels between normal bridges.  Two, the CHANNEL(peeraccount)
36
   just like channels between normal bridges.  Two, the
36
   value now can be set before Dial, FollowMe, and Queue to set the
37
   CHANNEL(peeraccount) value can now be set before Dial and FollowMe to
37
   accountcode on the outgoing channel(s).  For Queue this now includes
38
   set the accountcode on the outgoing channel(s).
38
   local channel members where the accountcodes are propagated early
39

   
39
   enough to be useful on the ;2 channel.
40
   For Queue, an outgoing channel's non-empty accountcode will not change

    
   
41
   unless explicitly set by CHANNEL(accountcode).  The change has three

    
   
42
   visible effects.  One, local channels now cross accountcode and

    
   
43
   peeraccount across the special bridge between the ;1 and ;2 channels

    
   
44
   just like channels between normal bridges.  Two, the queue member will

    
   
45
   get an accountcode if it doesn't have one and one is available from the

    
   
46
   calling channel's peeraccount or accountcode.  Three, accountcode

    
   
47
   propagation includes local channel members where the accountcodes are

    
   
48
   propagated early enough to be available on the ;2 channel.

    
   
49

   

    
   
50
From 12.3.2 to 12.4.0:
40

    
   
51

   
41
 - The safe_asterisk script was previously not installed on top of an existing
52
 - The safe_asterisk script was previously not installed on top of an existing
42
   version. This caused bug-fixes in that script not to be deployed. If your
53
   version. This caused bug-fixes in that script not to be deployed. If your
43
   safe_asterisk script is customized, be sure to keep your changes. Custom
54
   safe_asterisk script is customized, be sure to keep your changes. Custom
44
   values for variables should be created in *.sh file(s) inside
55
   values for variables should be created in *.sh file(s) inside
45
   ASTETCDIR/startup.d/. See ASTERISK-21965.
56
   ASTETCDIR/startup.d/. See ASTERISK-21965.
46

    
   
57

   
47
 - Changed a log message in safe_asterisk and the $NOTIFY mail subject. If
58
 - Changed a log message in safe_asterisk and the $NOTIFY mail subject. If
48
   you use tools to parse either of them, update your parse functions
59
   you use tools to parse either of them, update your parse functions
49
   accordingly. The changed strings are:
60
   accordingly. The changed strings are:
50
   - "Exited on signal $EXITSIGNAL" => "Asterisk exited on signal $EXITSIGNAL."
61
   - "Exited on signal $EXITSIGNAL" => "Asterisk exited on signal $EXITSIGNAL."
51
   - "Asterisk Died" => "Asterisk on $MACHINE died (sig $EXITSIGNAL)"
62
   - "Asterisk Died" => "Asterisk on $MACHINE died (sig $EXITSIGNAL)"
52

    
   
63

   
53
 - Added a compatibility option for ari, chan_sip, and chan_pjsip
64
AMI:
54
   'websocket_write_timeout'. When a websocket connection exists where Asterisk
65
 - The AMI version has been changed from 2.3.0 to 2.4.0. This is to reflect
55
   writes a substantial amount of data to the connected client, and the connected
66
   the backwards compatible changes listed in the CHANGES file.
56
   client is slow to process the received data, the socket may be disconnected.
67

   
57
   In such cases, it may be necessary to adjust this value. Default is 100 ms.
68
ARI:

    
   
69
 - Added a compatibility option 'websocket_write_timeout'.  When a websocket

    
   
70
   connection exists where Asterisk writes a substantial amount of data to

    
   
71
   the connected client, and the connected client is slow to process the

    
   
72
   received data, the socket may be disconnected.  In such cases, it may be

    
   
73
   necessary to adjust this value.

    
   
74
   Default is 100 ms.

    
   
75

   

    
   
76
 - The ARI version has been changed from 1.3.0 to 1.4.0. This is to reflect

    
   
77
   the backwards compatible changes listed in the CHANGES file.

    
   
78

   

    
   
79
chan_dahdi:

    
   
80
 - Added the inband_on_setup_ack compatibility option to chan_dahdi.conf to

    
   
81
   deal with switches that don't send an inband progress indication in the

    
   
82
   SETUP ACKNOWLEDGE message.

    
   
83

   

    
   
84
chan_pjsip:

    
   
85
 - Added a compatibility option 'websocket_write_timeout'.  When a websocket

    
   
86
   connection exists where Asterisk writes a substantial amount of data to

    
   
87
   the connected client, and the connected client is slow to process the

    
   
88
   received data, the socket may be disconnected.  In such cases, it may be

    
   
89
   necessary to adjust this value.

    
   
90
   Default is 100 ms.
58

    
   
91

   
59
 - Added a 'force_avp' option to chan_pjsip which will force the usage of
92
 - Added a 'force_avp' option to chan_pjsip which will force the usage of
60
   'RTP/AVP', 'RTP/AVPF', 'RTP/SAVP', or 'RTP/SAVPF' as the media transport type
93
   'RTP/AVP', 'RTP/AVPF', 'RTP/SAVP', or 'RTP/SAVPF' as the media transport type
61
   in SDP offers depending on settings, even when DTLS is used for media
94
   in SDP offers depending on settings, even when DTLS is used for media
62
   encryption.
95
   encryption.
63

    
   
96

   
64
 - Added a 'media_use_received_transport' option to chan_pjsip which will
97
 - Added a 'media_use_received_transport' option to chan_pjsip which will
65
   cause the SDP answer to use the media transport as received in the SDP
98
   cause the SDP answer to use the media transport as received in the SDP
66
   offer.
99
   offer.
67

    
   
100

   

    
   
101
chan_sip:

    
   
102
 - Added a compatibility option 'websocket_write_timeout'.  When a websocket

    
   
103
   connection exists where Asterisk writes a substantial amount of data to

    
   
104
   the connected client, and the connected client is slow to process the

    
   
105
   received data, the socket may be disconnected.  In such cases, it may be

    
   
106
   necessary to adjust this value.

    
   
107
   Default is 100 ms.

    
   
108

   
68
 - Added a 'force_avp' option for chan_sip. When enabled this option will
109
 - Added a 'force_avp' option for chan_sip. When enabled this option will
69
   cause the media transport in the offer or answer SDP to be 'RTP/AVP',
110
   cause the media transport in the offer or answer SDP to be 'RTP/AVP',
70
   'RTP/AVPF', 'RTP/SAVP', or 'RTP/SAVPF' even if a DTLS stream has been
111
   'RTP/AVPF', 'RTP/SAVP', or 'RTP/SAVPF' even if a DTLS stream has been
71
   configured. This option can be set to improve interoperability with WebRTC
112
   configured. This option can be set to improve interoperability with WebRTC
72
   clients that don't use the RFC defined transport for DTLS.
113
   clients that don't use the RFC defined transport for DTLS.
[+20] [20] 7 lines
[+20]
80

    
   
121

   
81
 - A 'dtlsfingerprint' option has been added to chan_sip which allows the
122
 - A 'dtlsfingerprint' option has been added to chan_sip which allows the
82
   hash to be specified for the DTLS fingerprint placed in SDP. Supported
123
   hash to be specified for the DTLS fingerprint placed in SDP. Supported
83
   values are 'sha-1' and 'sha-256' with 'sha-256' being the default.
124
   values are 'sha-1' and 'sha-256' with 'sha-256' being the default.
84

    
   
125

   

    
   
126
HTTP:

    
   
127
 - Added support for persistent HTTP connections.  To enable persistent

    
   
128
   HTTP connections configure the keep alive time between HTTP requests.  The

    
   
129
   keep alive time between HTTP requests is configured in http.conf with the

    
   
130
   session_keep_alive parameter.

    
   
131

   
85
From 12.3.0 to 12.3.1:
132
From 12.3.0 to 12.3.1:
86

    
   
133

   
87
 - MixMonitor AMI actions now require users to have authorization classes.
134
 - MixMonitor AMI actions now require users to have authorization classes.
88
   * MixMonitor - system
135
   * MixMonitor - system
89
   * MixMonitorMute - call or system
136
   * MixMonitorMute - call or system
[+20] [20] 676 lines
/branches/12/apps/app_dial.c
Diff Revision 3 Diff Revision 4
 
/branches/12/apps/app_followme.c
Diff Revision 3 Diff Revision 4
 
/branches/12/apps/app_queue.c
Diff Revision 3 Diff Revision 4
 
/branches/12/include/asterisk/bridge_channel.h
Diff Revision 3 Diff Revision 4 - File Reverted
 
/branches/12/include/asterisk/channel.h
Diff Revision 3 Diff Revision 4
 
/branches/12/main/bridge.c
Diff Revision 3 Diff Revision 4
 
/branches/12/main/bridge_basic.c
Diff Revision 3 Diff Revision 4
 
/branches/12/main/bridge_channel.c
Diff Revision 3 Diff Revision 4 - File Reverted
 
/branches/12/main/cel.c
Diff Revision 3 Diff Revision 4
 
/branches/12/main/channel.c
Diff Revision 3 Diff Revision 4
 
/branches/12/main/core_unreal.c
Diff Revision 3 Diff Revision 4
 
/branches/12/main/dial.c
Diff Revision 3 Diff Revision 4
 
/branches/12/main/pbx.c
Diff Revision 3 Diff Revision 4
 
/branches/12/res/parking/parking_bridge_features.c
Diff Revision 3 Diff Revision 4
 
  1. /branches/12/UPGRADE.txt: Loading...
  2. /branches/12/apps/app_dial.c: Loading...
  3. /branches/12/apps/app_followme.c: Loading...
  4. /branches/12/apps/app_queue.c: Loading...
  5. /branches/12/include/asterisk/bridge_channel.h: Loading...
  6. /branches/12/include/asterisk/channel.h: Loading...
  7. /branches/12/main/bridge.c: Loading...
  8. /branches/12/main/bridge_basic.c: Loading...
  9. /branches/12/main/bridge_channel.c: Loading...
  10. /branches/12/main/cel.c: Loading...
  11. /branches/12/main/channel.c: Loading...
  12. /branches/12/main/core_unreal.c: Loading...
  13. /branches/12/main/dial.c: Loading...
  14. /branches/12/main/pbx.c: Loading...
  15. /branches/12/res/parking/parking_bridge_features.c: Loading...

https://reviewboard.asterisk.org/ runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to asteriskteam@digium.com.