Mikael Bjerkeland wrote: > ons, 30.05.2007 kl. 00.34 +0900, skrev ObjM2: > >> On May 29, 2007, at 11:32 PM, Max CtRiX wrote: >> >> >>> Chan_sofia will need more parameters that will give more flexibility, >>> >> this is why we have (and probably want to keep) peer dialing where >> you can pull any number of additional parameters from the peer >> definition without overloading the Dial() command syntax. >> >> >>> b) the TECH of the channel (SIP/ZAP/MISDN) which is NOT needed by >>> Dial() itself but is needed by the core (to call the appropriate >>> channel >>> driver) >>> >> this is the channel type which is not needed as a separate argument >> in the case of >> >> 1) URI dialing, because the URI scheme determines the channel-type >> >> for example, a URI that starts with "sip://" will always be passed to >> a SIP channel >> >> 2) GROUP dialing, because the information is already contained in the >> ring-group definition's destination list >> >> for example, a destination defined as ( ZAP, ch1, 0, 60 ) in a ring- >> group will always be passed to a ZAP channel >> >> >> >>> c) the channel specific arguments like sip uri, sip peer, zap >>> extensio, zap group etcc. >>> >>> 2) data for a) can be schematized, data for b) and c) cannot be really >>> schematized in an appropriate way. >>> >> All the more reason to treat cases #1 (URI dialing), #2 (Peer >> dialing) and #3 (mult-ring group dialing) separate, each one with its >> own argument list. >> >> >> >>> After all it's not something that >>> Dial() should take care of. >>> >>> 3) b) and c) shound't even be a problem of Dial(). >>> it's a whole thing that the CORE must take care of. >>> >>> Dial as an application cannot and must not take care of those data. >>> >> As I had mentioned in the last paragraph of my post: This is not a >> discussion how Dial should be implemented. It is a discussion of how >> the argument list of the future Dial() command should be passed to >> whatever implements the functionality of establishing a call. >> >> In any event, the Dial() command will need to map its arguments to >> whatever it is that implements the dialing functionality, wherever >> that functionality resides. In other words, we are talking about >> argument passing, not argument processing. >> >> In line with the change towards comma-separated-only argument lists >> and argv style argument passing, the Dial() syntax will have to be >> changed, its single multi-argument string broken down into individual >> arguments and passed one by one. That is, unless you want to treat it >> as the oddball case which should not use comma-separated argument >> lists, which should not use argv style argument parsing. Is that what >> you want? >> >> >> As for how Dial() should be implemented (not this discussion), in my >> mind, there should not even be a dial application in the first place. >> Instead, the dialplan should have a built-in Dial() command whose >> only purpose is to map the arguments to a (new) call origination API >> in the core. Since this will be a C API, it is only natural that one >> would rather use argv style argument passing to pass it the arguments. >> >> rgds >> benjk >> _______________________________________________ >> Callweaver-dev mailing list >> [email protected] >> http://lists.callweaver.org/mailman/listinfo/callweaver-dev >> > > > 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? > The current t38gateway app was only ever intended as a test bed to debug the T.38 engine.
Steve _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
