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
