> 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.
I should mention that I have not actually had time to check to see if some of the issue I brought up in my privious post have been fixed in Callweaver as apposed to Asterisk. I wanted to give my 2 cents on this before my office closed for the weekend and we want to do test a number of things out on Callweaver. Michael Cargile Explido Software USA Inc. www.explido.us _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
