[asterisk-dev] Adding an option to the Dial app in 1.4

Matthew Nicholson mnicholson at digium.com
Mon Nov 2 15:33:30 CST 2009


On Mon, 2009-11-02 at 18:52 +0100, Olle E. Johansson wrote:
> 2 nov 2009 kl. 18.40 skrev Matthew Nicholson:
> 
> > I would like some thoughts on my dial-caller-answer1.diff patch on  
> > issue
> > 15936 (https://issues.asterisk.org/view.php?id=15936).  That patch  
> > adds
> > an option to the dial command to answer the calling channel when the
> > called channel is answered.  That behavior is useful in situations  
> > where
> > the the macro option or announce option is used.  In order to fix the
> > reporter's issue, an option like this (in addition to some other
> > changes), needs to be added to the dial command.
> >
> > I would like to know your general thoughts on the issue and my  
> > purposed
> > solution, and whether or not this option should be added to the Dial
> > application in asterisk 1.4.
> >
> 
> I see the problem based on billing, but the behaviour of the call will  
> be strange.
> If we answer the incoming call and do *nothing* while waiting for the  
> outbound
> channel to go through whatever happens (macro, announcements, jingles)
> that will be very weird for the caller in some cases.
> 
> Also, the documentation has to be very clear that this is not about  
> general
> cases, as everyone will set that option for every call if we do. By  
> default,
> we DO send answer to the caller when the callee answers. Always,
> unless you've added delay by using dial() options. This should be called
> something like "premature answer" or "indicate answer" or something
> better...
> 
> The current documentation doesn't do a good job here:
> 
> +"    a    - Answer the calling channel when the called channel  
> answers.  This\n"
> +"           can be used to answer the calling channel before playing  
> an\n"
> +"           announcement with the A() option.\n"
> 
> Reading this, everyone will set the 'a' option on every call, because  
> what you
> describe here is exactly what they want...

Ok.  I will improve this.

> This is a new feature, even though something required by the reporter,  
> but I am hesitating about merging it in 1.4.

I am also hesitant.  I don't expect this feature to introduce any bugs
though, so I am not completely against merging it.

-- 
Matthew Nicholson
Digium, Inc. | Software Developer




More information about the asterisk-dev mailing list