[asterisk-dev] Call priority and Dial()

2006-09-05 Thread Andrew Kohlsmith
I've opened up bug 7882: http://bugs.digium.com/view.php?id=7882

Now seeing as (as far as I can tell) it involves adding a variable to the 
channel structure, I'd like to get some input from the developers before I 
put a lot of blood, sweat and tears into solving this particular issue.

I know that messing around with ast_channel can only be done when all other 
options are evaluated; that's what this thread has been started for.

Essentially what I am trying to do is allow Dial() to terminate a 
lower-priority call in order to place a higher-priority one if and only if 
there are no available channels.  This can currently be done in a hackish way 
with an AGI or perhaps even the Manager interface, but race conditions 
abound.  If I can put this in app_dial I can eliminate a lot of headaches.

Another way to achieve this would be to create a set of dialplan functions 
which would allow the dialplan to snoop the channel variables of *any* 
channel in the system.  However the security implications of this aren't to 
be taken lightly, and the race conditions still exist.

My theoretical way of doing this WITHOUT playing with app_dial is to use a 
channel variable and a global dialplan variable, a dialer macro which is used 
for ALL outgoing calls, and an AGI:  [macro-dialout] checks to see if the 
global variable ${EMERGENCY_MODE} is set and if so, does not allow any 
outgoing calls unless the channel variable ${EMERGENCY_CALL} is set.  An 
emergency call sets ${EMERGENCY_CALL} before Macro(dialout,911) is executed.  
The macro sets ${EMERGENCY_MODE} if ${EMERGENCY_CALL} is set, and 
ChanIsAvail()s the normal outgoing channel set (think Zap/g1 for example).  
If a channel is available, it places the call.  If a channel is NOT 
available, the AGI must scan all of the channels that it would normally place 
an emergency call through and if ${EMERGENCY_CALL} is not set, soft hangup 
the channel and dial the emergency call.

${EMERGENCY_MODE} needs to be UN-set at some point to allow more calls once 
the emergency call is in-progress, but it cannot be set until AFTER the 
Dial() is done to prevent a race condition (when the soft hung-up channel is 
freed but another non-emergency call steals the channel) -- that's what the 
${EMERGENCY_MODE} global variable is for, but it's a little brutal...

Thoughts?

-A.
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev


Re: [asterisk-dev] Call priority and Dial()

2006-09-05 Thread Andrew Kohlsmith
I forgot to mention what I was planning on adding to app_dial.  :-)

What I'm suggesting is adding a call priority field to ast_channel.  This 
field would default to a value of -1 (no priority), and the dial flag R(x) 
would be added to app_dial, which would set the priority for the new call leg 
to 'x'.

If app_dial cannot locate a free channel in its list of technologies to dial 
out of, it would search the list in exactly the same order that it does now, 
this time looking for the first channel that has a lower priority than 'x'.  
The first matching channel would then be soft hung-up, and Dial() would do 
its normal job using this newly freed channel.  If no channels with a lower 
priority than 'x' are found, Dial() would return CHANUNAVAIL or CONGESTION as 
usual.

I can already see someone wanting the option of playing a sound file to the 
channel (and its bridge peer) before hanging up, and a delay would also be 
required for analog (and some digital) Zaptel channels to allow this to work 
correctly.

Further, I can see people wanting to be able to set a default priority for a 
given channel technology, so hooks in the various technology-specific files 
may be a good idea (defaultprio=5 or something).  This is all blowing up the 
original scope significantly though; I'm not suggesting doing all of this at 
once, but rather only being aware that it may be desired and not coding so 
tightly that it becomes problematic later.

-A.
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev