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? Mikael _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
