Summary:	ASTERISK-01768: Problem between ChanIsAvail and app_dial
Reporter:	tekati (tekati)	Labels:
Date Opened:	2004-06-05 11:07:36	Date Closed:	2008-01-15 14:57:20.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_chanisavail.diff
Description:	Using the very latest CVS and easy to duplicate. A striped down call out extensions.conf entry. Where Zap/2 and Zap/1 are both X100P outside analog lines exten => _NXXXXXX,1,ChanIsAvail(Zap/2&Zap/1) exten => _NXXXXXX,2,Dial(${AVAILCHAN}/${EXTEN}) exten => _NXXXXXX,3,Congestion exten => _NXXXXXX,102,Congestion On a normal call this produces the following output on the console.    -- Starting simple switch on 'Zap/4-1'    -- Executing ChanIsAvail("Zap/4-1", "Zap/2&Zap/1") in new stack    -- Hungup 'Zap/2-1'    -- Executing Dial("Zap/4-1", "Zap/2-1/XXXXXXX") in new stack Jun  5 08:36:55 NOTICE[1217669936]: app_dial.c:674 dial_exec: Unable to create channel of type 'Zap'  == Everyone is busy at this time    -- Executing Congestion("Zap/4-1", "") in new stack  == Spawn extension (fxo-line2-out, XXXXXXX, 3) exited non-zero on 'Zap/4-1'    -- Hungup 'Zap/4-1' If you change the extensions.conf entry to: exten => _NXXXXXX,1,Dial(Zap/2-1/${EXTEN}) exten => _NXXXXXX,2,Congestion exten => _NXXXXXX,101,Congestion The call goes through just fine.  This output shows the Zap/2-1/3038415 which is what the ChanIsAvail puts out for some reason and thus why you are seeing the warning line.  But I wanted to show it this way so there would be no confusion that the 2-1 instead of just 2 would be causing this issue.  Using just Zap/2/XXXXXXX clears that line out.    -- Starting simple switch on 'Zap/4-1'    -- Executing Dial("Zap/4-1", "Zap/2-1/XXXXXXX") in new stack Jun  5 08:42:04 WARNING[1217669936]: chan_zap.c:6117 zt_request: Unknown option '-' in '2-1/XXXXXXX'    -- Called 2-1/XXXXXXX XXXXXXX of course was substituted for a actual phone number.  I live in California which only requires 7 digits to a local number. It appears to be a issue with the ChanIsAvail maybe taking too long to hang up the channel for the app_dial application or that the app_dial application does not wait long enough.  Not sure really.  All I can tell you is that my last CVS update worked fine and that was from probably about a month ago.
Comments:	By: Mark Spencer (markster) 2004-06-05 13:41:16 If you want to use a specific channel use Zap/2/foo not Zap/2-1/foo.  When placing a call you cannot use a "-" in the name of the channel.   However, I've updated app_chanisavail to give you ${AVAILORIGCHAN} which is the original incantation that led to the available channel - in CVS head.  In general you should be using zap groups and not trying this nonsense with app_chanisavail: zapata.conf: group=1 channel => 1 channel => 2 extensions.conf: exten => foo,1,Dial(Zap/g1/bar) By: tekati (tekati) 2004-06-06 10:41:23 Problem still exists.  Everytime you use the original extension configuration you get a busy context back from the app_dial.  If you remove the ChanIsAvail it goes through just fine.  It appears the ChanIsAvail checks the channel by opening it and seeing if it can then closing the channel.  It appears this not happening fast enough for the app_dial application.  The ChanIsAvail does the correct job and returns the proper Zap channel but the app_dial just can not use it when it trys for some reason. I do thank you for adding the AVAILORIGCHAN as well.  It does truncate the Zap though and where it sould return Zap/2 it returns /2 but I and others will appreciate the new variable.  The Zap/2-1 is not the issue it gives you a warning only and I was able to live with that. By: tekati (tekati) 2004-06-06 11:42:08 I know the diff I have submitted is probably all wrong for the fix but I thought I would pass it along anyway.  It works on my end even though I am sure it is much easier to make work then what I have done.  If I was a real programmer I would understand why it is happening in the first place.  I know it has something to do with using the pointer and that the original code actually modified the pointer but still I have no clue. Even after this patch the exact same thing still happens and exists.    -- Starting simple switch on 'Zap/4-1'    -- Executing ChanIsAvail("Zap/4-1", "Zap/2&Zap/1") in new stack    -- Hungup 'Zap/2-1'    -- Executing Dial("Zap/4-1", "Zap/2/XXXXXXX") in new stack Jun  6 09:11:36 NOTICE[1217669936]: app_dial.c:981 dial_exec: Unable to create channel of type 'Zap'  == Everyone is busy at this time    -- Executing Congestion("Zap/4-1", "") in new stack I am sure that you are correct and that I can do a simple group config but this should still function anyway.  I just stumbled across this method before I have had a chance to try to work it with groups. By: tekati (tekati) 2004-06-06 11:54:49 I added a simple Wait,2 between the ChanIsAvail and the Dial extension and that works as well so it is some sort of timing issue or too much time to actually hang up a channel.  If I change that Wait,2 to Wait,1 that is not enough wait time and I still have the issue. For clarification here are the new extensions.conf entries. Does not work. exten => _NXXXXXX,1,ChanIsAvail(Zap/2&Zap/1) exten => _NXXXXXX,2,Dial(${AVAILORIGCHAN}/${EXTEN}) exten => _NXXXXXX,3,Congestion exten => _NXXXXXX,102,Congestion Does work. exten => _NXXXXXX,1,ChanIsAvail(Zap/2&Zap/1) exten => _NXXXXXX,2,Wait(2) exten => _NXXXXXX,3,Dial(${AVAILORIGCHAN}/${EXTEN}) exten => _NXXXXXX,4,Congestion exten => _NXXXXXX,103,Congestion edited on: 06-06-04 11:44 By: Brian West (bkw918) 2004-06-06 12:16:06 the only question is WHY ARE YOU NOT USING GROUPS?  You do realize that chan_zap can find the channel that isn't in use and make a call without all this drama! bkw By: Digium Subversion (svnbot) 2008-01-15 14:57:20.000-0600 Repository: asterisk Revision: 3149 U   trunk/apps/app_chanisavail.c ------------------------------------------------------------------------ r3149 | markster | 2008-01-15 14:57:19 -0600 (Tue, 15 Jan 2008) | 2 lines Add ${AVAILORIGCHAN} with original channel name (bug ASTERISK-1768) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3149