On Jun 2, 2007, at 12:07 AM, Michael Cargile wrote: > 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.
What you describe there is a work around to deal with the shortcomings of the current core and its (virtually non-existent) API. The whole dial application as it stands now is a hack to work around the lack of a call origination service in the core. Splitting it up won't change that. Many if not most of the other applications are hacks to work around the lack of one service or another in the core. We shouldn't let our imagination be limited by this fact. We don't need more of the same, we need less of it. What we need is services in the core with an API. > 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. Whilst the issue you are raising there is valid, this is not something you should seek to address at the dialplan level. Different signaling methods are best handled via proper abstraction, that is in lower abstraction layers inside the core (or in a library called from within the core). At the dialplan level we should never have to worry about any of these details. > 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 has nothing to do with the dial command at all. The reason you don't get such feedback is that Asterisk mostly doesn't provide proper feedback. The vast majority of non-success cases is foolishly mapped to "congestion". Again, this needs to be fixed in the core, not in the dialplan nor in any dialplan application. > 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 If you move call origination into the core, then you will no longer need any application to do the work. All you need is an interface for the dialplan writer to pass in arguments. Thus, you need a dial command that collects the arguments in the dialplan and map them to API calls provided by the core, finally pass the return code back from the core to the dialplan. If you need an application to do part of the work (other than passing args and return code), it means you haven't designed the API properly. If we are to move call origination into the core, we may as well do it properly and make sure that all the work is done in the core, not just some of it. Otherwise we will soon end up with the same mess we have now. > 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. Tone detection doesn't belong into the dial command regardless of how Dial() is implemented. Collecting and passing on arguments to tell the core what options you want to enable for your call is of course a necessity but the actual handling of those features which are being enabled should be done in the core (or libraries called from within the core). Whether you specify option arguments within the argument list of the dial command itself, or whether you use a separate command to set defaults to be used when you originate a call is a matter of preference, but the two styles are not mutually exclusive. For example, one may do this ... Dial( destination, 60 , rT ) or one may do something like this instead ... SetDialTimeout( 60 ) SetDialOptions( rT ) Dial( destination ) However, some of what is at present called options are misnomers. They are complex features which require their own arguments and adding them into the options argument is one of the most ridiculous things one could possibly do because it amounts to nesting arguments within arguments. Last year we had discussed how to add a call origination service (and API) to the core and some preliminary work on its API came out of that. This API distinguishes between options which are simple on/off switches and actions which are hooks to trigger the execution of user definable action sequences during call origination within the core. The call actions API (http://www.callweaver.org/browse/callweaver/ branches/benjk/call_actions.h) defines the following ... 1) targets no target, calling party, called party, both parties; 2) triggers when initiated, when answered, when ready to bridge, when bridged, when hangup requested, when hung up; 3) actions log, announce caller ID/max duration/etc, confirm to connect, verify PIN, play recording/music, read/send DTMF, hang up; The API then provides a mechanism to chain actions into action sequences and schedule such sequences on a call using the triggers and an optional delay, further specifying the target and optional parameters (ie. text to be read out or a file to be played). With this approach, you can construct features from atomic actions and pass them as parameters to the API rather than having to hack the source code. Even in the event that you want to construct a feature which requires an atomic action that the API doesn't know yet, it is far easier (and less error prone) to add a new action to the core (and API) than messing about with dial_app. The way this would be used in the dialplan is likely to employ additional commands to define action sequences because a) most of those sequences will be reusable and b) it would simply overwhelm the argument list of the dial command. Yet, the important things to note is that a) features constructed this way will live in the core and not in an application and b) you still only need a single dial command to initiate a call. This may serve as an example how you can reduce complexity by taking a more generic approach, yet gain flexibility. rgds benjk _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
