[asterisk-dev] Proposed change to how accountcode is propagated to other channels.

[Richard Mudgett]

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.
However, a side effect of this is it will overwrite any accountcode set by
the SIP channel driver configuration for the SIP/200 channel with the
accountcode from the Local;2 channel.  Without any dialplan manipulation,
all channels in this call would have the same accountcode.  I believe this
is the basis for the ASTERISK-17954 [1] issue.

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.

I want to change the behavior slightly.  I want to make the outgoing
channel get the accountcode of the initiating channel _only_ if the
outgoing channel doesn't already have an accountcode set.

The most visible effect the change would have is if the channel driver
automatically set the accountcode on channel creation.  In the example
above if SIP/100 and SIP/200 are created with their own accountcode from
the SIP channel driver configuration, the SIP/200 accountcode would not
get overwritten by the SIP/100 accountcode and you would not need to use
dialplan to set it back.  Of course the converse is that dialplan would
need to be used to propagate the SIP/100 accountcode to SIP/200.

How should the accountcode value be propagated to other channels?

Is there any reason the proposed change should not be made other than it
has always been done that way?

Richard

[1] https://issues.asterisk.org/jira/browse/ASTERISK-17954
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140603/7aa4d085/attachment-0001.html>