Summary:	ASTERISK-19388: Make it possible to put any connected call on hold, not just bridged ones
Reporter:	Birger "WIMPy" Harzenetter (wimpy)	Labels:
Date Opened:	2012-02-20 03:16:35.000-0600	Date Closed:	2012-03-02 12:37:19.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:		Frequency of Occurrence
Related Issues:
Environment:	DAHDI channel in NT-mode	Attachments:	( 0) sig_pri-hold.patch
Description:	I have lived under the impressin that DAHDI doesn't support HOLD so far. Now after digging the source I found out that this was due to a minor misfeature that caused my testing to fail. I always used a MOH extension on my test box, but sig_pri only allows bridged calls to be put on hold. While it makes sense to not allow a call to be held unless connected, it should not be neccessary to be bridged.
Comments:	By: Birger "WIMPy" Harzenetter (wimpy) 2012-02-21 12:12:59.366-0600 I need to add that this patch leads to another misfeature. As Asterisk doesn't have a concept of disconnected calls, it will be possible to put these on hold as well. By: Richard Mudgett (rmudgett) 2012-02-22 21:17:08.845-0600 While putting an application on hold is odd but arguably acceptable, Asterisk *will* crash if the held call is subsequently transferred because there is no bridged channel. By: Birger "WIMPy" Harzenetter (wimpy) 2012-02-23 04:58:36.218-0600 Maybe putting an application on hold is not that interesting in itself, it it in order to be able to transfer it (or the other way round). e.g. to log someone in to some application once, without giving them the PIN. But I can report that your prediction did not come true. Asterisk did not crash. The transfer actually works just perfect. By: Richard Mudgett (rmudgett) 2012-02-23 09:38:21.182-0600 Well, guess I programmed the transfer code for ISDN better than I remembered. :)  The code will need to be reviewed to see if there are other pitfalls to removing the limitation. By: Richard Mudgett (rmudgett) 2012-02-23 09:43:45.878-0600 I should add you could always transfer a bridged call to an application by putting the bridged call on hold and then transferring it to the application. By: Birger "WIMPy" Harzenetter (wimpy) 2012-02-23 12:56:45.164-0600 Your last comment made me think that I don't really know which call is transferred to which. It might not depend on the currently active channel. So I tried starting the calls in either order, by changing back again to the first call or not before transferring and with three different brands of phones. But it always worked. So it wasn't just luck. You must have done it right. :-)