Summary:	ASTERISK-02166: [report + patch] Forwarding issue with multiple dial targets
Reporter:	cursor_software (cursor_software)	Labels:
Date Opened:	2004-08-01 02:10:51	Date Closed:	2008-01-15 15:05:44.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) subchannels.unidiff
Description:	1. We will be dialling two phones as follows:    Dial(SIP/111&SIP/222) 2. Forward 222 to 333 using the phone's interface, i.e. CFwdAll in the Cisco 7960. 3. Busy out 333 (the target for 222s forward). 4. Dial the phones, as shown above. You'd expect 111 to ring even though 333 is busy, but the busy returned by the forwarded extension tears down the whole dial attempt. The Dial() returns busy, even though extension 111 was available. This is all assuming that there is no call waiting in force, of course.  The 333 extension wouldn't be busy if call waiting was switched on. ****** ADDITIONAL INFORMATION ****** Sorry - no patches yet.  I'm trying to find the problem, but thought I should report it on the off-chance that someone would know where to focus.
Comments:	By: cursor_software (cursor_software) 2004-08-01 04:20:42 Channels can now be marked as "sub-channels".  If a sub-channel fails then that doesn't affect the master channel. The patch needs some further tests to make sure I didn't mess anything up.  Particularly, it needs to be confirmed that only sub-channels are marked as such, and all ordinary channels initialise the new "ast_channel.subchannel" member to zero.  I'm pretty sure I've found the place that everyone calls to initialise a channel [ast_request()], but I'm equally sure that someone else will be better equipped to confirm this. There may be a better way to do this, but this seemed like the obvious choice.  Well, obvious after a few hours of debugging, anyway. :-) By: cursor_software (cursor_software) 2004-08-04 12:41:39 The patch I posted doesn't work, so don't use it!  I only tested to see if the forward-to phone would ring, and it does.  As soon as the forward-to phone answers, the call is torn down on a bogus busy. It turns out that there's no need for "sub-channels" at all and the whole issue revolves around a simple bug. Please contact me directly if you want the patch (kevin@cursor.biz). By: Mark Spencer (markster) 2004-08-04 13:08:19 Can you send a trace?  I can't see how this should be happening. By: cursor_software (cursor_software) 2004-08-04 13:44:54 What do you mean by a trace?  An asterisk -vvvvvvd doesn't show any clues. While debugging this, I filled the app_dial with debug messages so that I could trace the flow through the code.  That allowed me to find what I think is the solution (it works), but I've since removed all of the debug messages.  Sorry about that. Have you been able to verify that the problem exists on your setup, using the steps outlined above? Can you please remove the file attached to this bug report.  It doesn't work and people may try it without reading this entire thread.  If you give me the go-ahead, I'll upload the new patch.  Until then, I'll respect your request to not upload patches. By: Mark Spencer (markster) 2004-08-04 15:03:27 asterisk -vvvvvd with "sip debug" turned on would probably be the best place to start.  Also, please be sure you have "debug" in your "console" entry of /etc/asterisk/logger.conf so we actually see the debug. By: patrickdk (patrickdk) 2004-08-04 20:32:21 My guess, though not remotely how it might be done. phone 222 is accepting the call, so asterisk thinks it made a connection, then phone 222 is trying to forward that call to 333 and it fails. Have to check the udp trace of the sip connection to be sure, but that seems to be how my sip phones are doing it, haven't check for sure though. I have noticed if one phone happens to have callforward enabled on it, it would always answer the call according to the cdr logs. Using the snom200's here. By: cursor_software (cursor_software) 2004-08-04 21:14:33 Sorry, I haven't had the time to pull this back apart.  I may have some more time later. What happens is this (from memory): * Phone 111 connects ok and "is ringing". * Phone 222 returns a 302 "Moved Temporarily" due to the forward. * Asterisk builds up a "Local" channel to 333, via the dialplan and calls. * Extension 333 is "406 Busy here" (assuming it is and the there is no call waiting to prevent this). * The "Local" channel dialler returns -1 to prevent further dialplan activity, such as a connection to voicemail. * The original channel sees the -1 response and tears down the call.  After all, the -1 could mean anything and so it should be fatal. * The call, which included the available 111 extension is torn down altogether, rather than simply dropping the busy "Local" channel and waiting on 111. I hope this helps. By: cloos (cloos) 2004-08-05 02:47:02 I've seen this same issue over IAX to IAX->PSTN providers.  If one of the target PSTN lines is busy there was (empiricly) a 50-50 chance or so that the caller would get a busy vs the non-busy phone ringing. (Incidentlty, it did work better to route the calls via different IAX->PSTN providers.  Queue also worked better.) By: cursor_software (cursor_software) 2004-08-05 03:09:05 This problem is reproducible regardless of the source of the call.  I had previously tested with the source (caller) being a POTS (Zap) line and with the source being a local (SIP) phone - same problem in both cases.  I don't have any local IAX2 phones to use as a test target extension, although I did test using an incoming IAX2 line as the source and got an identical result. The issue has more to do with the handling of the SIP forward, although it's not a SIP problem;  It's an app_dial problem, related to the creation of on-the-fly "Local" channels and the way they're torn down when a busy is detected. It would be nice to see a report from someone other than me who can verify the problem on an independent setup.  The instructions in the original report should be all that's required to set that up. By: Mark Spencer (markster) 2004-08-05 18:00:44 Out of curiousity, if you enable "Promiscuous redirect" does the problem remain? By: cursor_software (cursor_software) 2004-08-05 23:29:22 If "promiscuous redirect" is enabled then the problem clears, but you get another problem in its place. With promiscredir and Dial(SIP/111&SIP/222):    * A divert on 222 to 333 will tear down the connection if 333 is busy.    * Both phones will ring (as expected) if there are no busies. Without promisredir and Dial(SIP/222):    * A divert on 222 to 333 will always fail, even though only one extension was requested in the original dial. I ignored promisredir when it was introduced (because of this) but perhaps a better solution to this bug report would be to fix up promisredir and use that. By: cursor_software (cursor_software) 2004-08-06 03:32:20 Just to clarify the "you get another problem in its place" statement... With promiscredir switched off, a redirect to 3333 would create a new "Local" channel and so would go via the dialplan. With promiscredir switched on, a redirect to 3333 would try 'sip:3333@example.com:5060' and so would raise a "Loop detected" SIP response from the local server. Promiscredir switched on only allows redirects to non-local addresses and promiscredir switched off only allows redirects to local addresses.  With this in mind, I decided it was best to leave promiscredir switched off when it was first introduced. A directive that defines the local host/domain name would allow the promiscredir to handle both cases when switched on, although this would not help this current bug report. By: Olle Johansson (oej) 2004-08-14 16:29:49 I would love to see a full "asterisk -vvvvdr" and SIP DEBUG turned on output in a text file. It would help me try to understand this scenario. The "loop detected" is a dilemma. I wish I could find a way to do a hairpin SIP call and remove that error message. By: Mark Spencer (markster) 2004-08-19 14:52:01 SIP does not support the ability to hairpin.  IAX2 does support that concept however. By: Mark Spencer (markster) 2004-08-25 01:25:40 Fixed the documentation in sip.conf.sample to explain this problem. By: Digium Subversion (svnbot) 2008-01-15 15:05:44.000-0600 Repository: asterisk Revision: 3652 U   trunk/configs/sip.conf.sample ------------------------------------------------------------------------ r3652 | markster | 2008-01-15 15:05:44 -0600 (Tue, 15 Jan 2008) | 2 lines Document caveats of promiscredir (bug ASTERISK-2166) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3652