[asterisk-dev] Re: why 'o' (preserve original callerid) is not default in app_dial.c ?

[Tony Mountifield]

In article <45481689.9050304 at digium.com>,
Russell Bryant <russell at digium.com> wrote:
> Luigi Rizzo wrote:
> > For first, i do not understand the reason for setting
> > the callerid in the ast_channel to the one of the _called_ extension;
> > the information is already in cid_rdnis.
> > On the other hand, if 'o' is not the default, there must be a
> > good reason, and this must be the most useful case ?
> 
> Previously, the CallerID information from the calling channel was copied to the 
> called channel.  This is no longer the default behavior, but is available 
> through the use of the 'o' option.
> 
> Now, the default CallerID number for the called channel is that of the extension 
> that was called.  This may not be the best thing, but it is certainly more 
> correct than the CallerID of the calling channel.  RDNIS will not always be set, 
> so we can't rely on that.  However, it may be an even better choice than the 
> called extension when it is available.
> 
> That was at least the reasoning when these changes occurred ...
> 
> > But what is really confusing to me is that this change occurs after the
> > invocation of ast_call(), which means that the manager events
> > will report different information from what you see eg in the channel
> > driver when it responds to the ast_call (and possibly stores the
> > state from the channel itself).
> 
> This sounds like it could be a bug to me.  I would think processing this option 
> would come after the call to ast_request(), but before ast_call().  However, I 
> have a feeling that not many people use the 'o' option, so that could be why it 
> was never reported.

I don't think it is a bug. It took me a while to understand the reasoning
behind these changes, but I think I did in the end:

a) When making a call using Dial, the caller-ID from the incoming channel
is still copied to the outgoing channel (i.e. between ast_request() and
ast_dial()), so that when the destination phone rings, it correctly displays
the phone number of the original caller. This has always been the case since
before the 'o' option was introduced. If the processing of the "not-'o'" was
moved to before ast_call(), the called party's phone would show their own
number when the phone was ringing, which would be a bit daft!

b) Once the call has been answered, the called channel is just another
channel in Asterisk. The new behaviour, which is inhibited by the 'o'
options, is at that point to change the channel's caller-ID to be that
of the called device. The reasoning, I believe, is that then every
answered channel's caller-ID will reflect the extension that is on that
channel.  This may be even more important if the called channel is then
put into the dialplan using Redirect (ast_async_goto) and could place calls
of its own.

So I think the current behaviour is correct and well thought out. What
is probably missing is somewhere within the source tree that the rationale
behind such decisions could be recorded when they are made, especially if
they are counter-intuitive at first glance.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org