Summary:	ASTERISK-12933: [patch] Answer() doesn't when the state is Dialing
Reporter:	Matthias Urlichs (smurfix)	Labels:
Date Opened:	2008-10-18 13:40:42	Date Closed:	2008-12-09 16:24:22.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	PBX/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dial.patch
Description:	When a channel is in Dialing state, Answer() now does zilch, nada, nothing. YOu need to call Ringing() before Answer(). That's a too-easy mistake to make. I'm attaching a patch.
Comments:	By: Leif Madsen (lmadsen) 2008-10-21 09:31:17 This issue looks to be pretty straight forward. I've assign to putnopvut for now (I typed that as putnopbut like 3 times before I got it right...) in the hopes this issue can be quickly evaluated the resolved. Just reassign if that is not the case. Thanks! By: Mark Michelson (mmichelson) 2008-10-21 17:17:59 It does seem relatively straightforward, and the patch is most likely right, the problem is that since I don't know much about chan_dahdi, I don't know what AST_STATE_DIALING actually means. Unfortunately, like most of the time, the comment in channel.h doesn't really help since it does not tell if the state applies to outbound or inbound channels and is otherwise vague. I asked about it in the #asterisk-dev IRC chat as well but did not get an answer. blitzrage: I can either try asking about that state on IRC again or you can assign this to someone who is more familiar with chan_dahdi since this issue applies only to Dahdi channels. By: Mark Michelson (mmichelson) 2008-10-21 17:35:34 There's something else I'm curious about here. smurfix, you used the word "now" in your description, which makes it sound like Answer previously worked in the AST_STATE_DIALING state, but that it does not now. Am I interpreting this correctly? If so, what version of Asterisk did this work in? By: Matthias Urlichs (smurfix) 2008-10-21 20:07:42 That "now" was a mistake on my part, sorry. Anyway, as far as I know, AST_STATE_DIALING is what the channel is set to when you have a call that's not ringing yet. (There seems to be no other state that fits this description.) Looking closer at the code, it seems that AST_STATE_DIALING is used on outgoing calls only, and what I actually want for incoming calls is AST_STATE_PRERING. In that case, my patch should simply be changed appropriately. I don't know what chan_dahdi did or does either; I'm actually working on an external channel (chan_lcr, the interface between Asterisk and the Linux Call Router, which supports the new mISDN code that's in the kernel starting with 2.6.27). I'm using DAHDI for analog cards only, which don't have that state. By: Matthias Urlichs (smurfix) 2008-10-21 20:14:05 While you're investigating that, it seems that the answer code in channel.c has both    case AST_STATE_RINGING: and    case AST_STATE_RING: From what I see, the first state is for outgoing calls only and thus probably incorrect here (unless some channel uses AST_STATE_RINGING incorrectly). Personally, for Trunk I'd recommend globally renaming these states (_IN_RING and _OUT_RING, for instance), so that it's more obvious whether a state only applies to incoming or outgoing calls. By: Mark Michelson (mmichelson) 2008-12-09 16:24:21.000-0600 Since this is an issue which happens only with an external channel driver, it seems wrong for the behavior of the core to change to match the driver. I'm closing this issue for now. Regarding your concerns for the names of the various states to represent ringing, I would recommend bringing the topic up on the asterisk-dev mailing list since many more eyes would see the suggestion and be able to respond.