Recently there has been agreement that dialplan applications should
have comma-delimited argument lists so that a general parsing
algorithm can be used to obtain all arguments and pass them on as an
array in much the same way the C main() function gets its arguments
from the shell.
At present, dialplan apps are passed their arguments as one single
string and they need to parse that string to obtain their arguments.
This is not only error prone and inefficient but it also has led to
inconsistent syntax with various different delimiters being used.
In the majority of cases conversion to a comma-delimited-only
argument list should be very straightforward. The Dial() command
appears to be the problem case because it has such an overblown
syntax with a large variety of delimiters and cases where the
argument string is ambiguous.
Some people have argued that such problem cases should be left alone
for now and looked at when the time is right. Fair enough. However,
if the syntax of the argument list of a future Dial() command is
going to change (relative to the present one), then this syntax
should be known BEFORE any work on a new general argument parsing
algorithm starts, just to make sure the developer of the algorithm is
not painting him or herself into a corner. Therefore, I suggest that
the argument list syntax for the future Dial() command should be
discussed and defined now, even if the new Dial() command is not
going to be implemented any time soon. This post intends to start the
discussion.
One of the major problems with the present Dial() command is that it
tries to do be all things to all people.
The main two dialing methods employed by Dial() are ...
1) dialing a destination targeting a peer definition from which to
obtain the actual destination parameters
2) dialing a destination directly by addressing a URI without
consulting any peer definition
which leads to ambiguity (ie. "SIP/[EMAIL PROTECTED]" can be either a URI
or a peer dial) and is very difficult to reconcile if at all possible.
The complexity of Dial() is further increased and the task to
simplify parameter passing further made difficult by
3) dialing multiple destinations at once where the first one to pick
up will be connected
One idea has been to turn everything into a URI and devise a unified
URI scheme that includes both #1 and #2. However, due to the great
flexibility of SIP URIs it is almost impossible to add something to
it that isn't already legal in a SIP URI in order to denote non-URI
destinations. At the very least, non-URI dial strings will become
complex and thus cumbersome. In my view a knock-out argument against
this approach.
I have therefore been looking at a different angle. I thought "how
about pretending that #1, #2 and #3 are three totally different
issues, then solving each one isolated from the other two?". Some
experimentation led to the following ...
#1 - URI dialing
DialURI("sip://[EMAIL PROTECTED]", 60, r)
#2 - Peer dialing
DialPeer(SIP, bar.baz, foo, 60, r)
DialPeer(ZAP, g1, 012345678, 60, r) or
DialPeer(ZAP, ch1, 012345678, 60, r)
// same without a destination number ...
DialPeer(ZAP, ch1, , 60, r) or
DialPeer(ZAP, ch1, "", 60, r) or
DialPeer(ZAP, ch1, none, 60, r)
#3 - dialing multiple destinations at once
// define a ring group -- note: this could also be pulled from a
database
RingGroup = {
name = Foobar;
dest1 = ( URI, "sip://[EMAIL PROTECTED]", 0, 60 ); // starts @ 0
secs, ring for 60 secs
dest2 = ( ZAP, channel1, 012345678, 30, 30); // starts @ 30
secs, ring for 30 secs
};
// dial the ring group
DialGroup(Foobar, r);
For syntactic sugar one could then merge these three separate
commands into a single Dial() command using the first argument to
determine the three different modes ...
#1 - Dial(URI, "sip://[EMAIL PROTECTED]", 60, r)
#2 - Dial(SIP, bar.baz, foo, 60, r)
#3 - Dial(GROUP, Foobar, r)
The formal syntax for the resulting argument list would then be:
dial-argument-list = URI-arglist | peer-arglist | group-arglist
URI-arglist = "URI" "," uri-string [ "," duration [ "," options ] ]
peer-arglist = channel-type "," peer-name "," id [ "," duration [ ","
options ] ]
channel-type = "H323" | "IAX" | "SIP" | "UNICALL" | "ZAP" etc etc
group-arglist = "GROUP" "," ring-group-name [ "," options ]
Please note that this only discusses how arguments should be passed
to whatever will constitute the Dial() command in the future. It is
not a discussion how the actual dialing process would or should be
implemented.
rgds
benjk
_______________________________________________
Callweaver-dev mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-dev
