On Fri, 2007-06-01 at 09:24 +0900, bkml wrote: > On May 31, 2007, at 3:54 PM, Mikael Bjerkeland wrote: > > > We also need to incorporate the functionality of the current > > T38Gateway > > application in our new dial application so we can do both fax and > > voice > > in the same app. This should be taken into consideration when > > designing > > a new Dial app. Perhaps this change is a milestone for the project? > > As previously stated, the aim here is to clean up (and simplify) the > argument list of the Dial() command. Steve Underwood assured me that > there are no additional arguments required for T.38. > > Also, please note that it is by no means certain that the future Dial > () command will be implemented as an application. As has been pointed > out, the facility of originating calls is such a basic service, it > ought to reside in the core of the server and it should be exposed as > a proper C API. Now, once all the dialing is being done within the > core, what is there left to be done within a dial application? The > only thing that remains is the passing of arguments to the API > residing in the core. Yet what is the point of having an application > if it doesn't really do anything? I therefore believe that Dial() > should be a built-in command whose only purpose should be to pass > arguments to an API in the core. > > Some have pointed out that it may be desirable to be able to override > Dial() with a custom application. Fair enough. However, that alone is > still not a good reason to make the default command an application. > It would make more sense to allow the overriding of built-in commands > with custom applications. > > rgds > benjk > _______________________________________________ > Callweaver-dev mailing list > [email protected] > http://lists.callweaver.org/mailman/listinfo/callweaver-dev
First off I would like to say hello to everyone on the list as we have just found the joys of Callweaver after pulling our hair out with some of the major instablities and problems of Asterisk. One of which has to do with this very topic: We would actually really like the dial command split up into 3 seperate parts. One to get the channel. One to actually dial on the channel. One to do the progress on the channel. These could be build into the core. This would be sanonamous with picking up the phone, dialing the number, and listening to the results. Three separate actions that are currently lumped into one command with little ablity to seperate them out. Once this is done we could have 4 applications that go along with this. One being a generic dial command that would allow anyone to simply place a call with one command with all of the options that could apply. Then the other three would coincide with each part and have options specifically for those parts. Our reasoning behind this has to do with the fact that the implementation of channels from provider to provider and geographic location to location varies quite widely. For instance we have a customer who has Quest PRI lines that deliver analog progress on quite a number of calls, and getting them to change this is like pulling teeth. PRI lines currently do not use analog progress (or atleast in Asterisk) and in civilized countries they do not need it, however dealing with most US providers they do. Same thing applies for SIP. Now by splitting dialing into multiple applications would mean that we can make sure that we actually have a channel before we dial on it which is currently not garenteed, atleast not on PRIs. For example we have been using Asterisk for setting up dialers with Vicidial. When Vicidial places a call it assumes that a channel is availible if it is not in use. This is not always the case if you are using funny PRI lines in the US. Splitting up the channel management and the dial would allow to check if a channel is availible before trying to dial on it. Currently we just get a bunch of congestion messages in a row. These messages currently do not provide much information. Wether it is a real congestion or if the channels were not release on the switch in time. This is not just interesting for predictive dialing but also for any application with multiple targets, line rollovers, or other features. If we put those three parts in the core and create a dial application to use those we could easily add new smarter dialing features within the application, or create special or alternative dial applications. The other thing is that there are good reasons for most of the option that the dial command has. They are for dealing with the various technologies. There are other things that could be greately improved with this however. Currently in order for the Dial command to do proper tone detection in Asterisk you have to use the option t or T (both enable transfer) otherwise other tones are ignored even in functions where they should not be ignored. This is not only STUPID but also a security risk as I don't necessarily want people to be able to transfer. Michael Cargile Explido Software USA Inc. www.explido.us _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
