[asterisk-dev] Proposed changes to accountcode in CDRs

[Brian Degenhardt]

Grey Man <greymanvoip at gmail.com>
> On Thu, May 8, 2008 at 6:08 PM, Brian Degenhardt <bmd at digium.com> wrote:
> >
> >  Let's put aside the complete issue of CDRs for a moment though and
> >  focus specifically on accountcodes.  Can you see any problem with not
> >  implicitly transfering the accountcode from one channel to another
> >  when a bridge occurs?
> 
> Yes I would see that as a problem. I would think the accountcode
> should always be promulgated to both the channels in the bridge. It
> would be a problem if a CDR for a call ended up without an
> accountcode. However this is not something that is a problem at the
> moment so I'm not sure where this issue has come from?

The trouble I'm having is if two different accountcodes call each
other.  In my view, each channel should retain their own accountcode.
My proposed change would not enable a CDR to lose it's accountcode, it
would just prevent the first leg's accountcode from implicitly
overwriting the owners of future legs.  For example, if I called you,
and then blind transfered you to Atis, and then you blind transfered
Atis to Russell, that last CDR post would have my accountcode, even
though I had nothing to do with the call.  However, if we repeated
that practice, but used assisted transfers, it would behave
differently.  I'm proposing to normalize on the behavior of the
assisted transfers.

> > I agree 100%.  This is exactly the reason I'm asking the list to
> > examine these design changes to the behavior of accountcode before making
> > them.  I'd love your feedback on this change.
> 
> There were cases in the Asterisk 1.0.x days where the accountcode
> would not get set on an authenticated call. I never really narrowed
> down why and I don't know if the behaviour is still there. The
> consequence was that we explicitly set the accountcode for each
> channel based on the channel name (we use the channel name to pare teh
> authenticated username and look up the accountcode). I think it would
> be controversial behaviour if you are talking about changing the
> accountcode on a channel without an explicit dialplan command being
> used, say in response to a transfer condition or such. If that's what
> the suggestion is?

Actually, the suggestion is completely the opposite.  I'm proposing to
*not* change the accountcode implicitly, as it is done today in
app_dial when a bridge completes.  If you are already explicitly
setting the accountcode in the dialplan, this change should not affect
you at all.

cheers
-bmd