bkml ha scritto:
> 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 ...
[Cut]
Imho it's still the wrong angle.
You can't do assumptions that won't be true in the future (and probably
even now).
Chan_sofia will need more parameters that will give more flexibility,
so, mypoint of view is:
1) Dial() requires 3 kinds of arguments:
a) it's own parameters, like timeout, and all that stuff
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)
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. 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.
4) if you want to be more schematic, then use something like
Dial ("tT", "TECH1/parameters","TECH2/more_parameters",[...more channels])
from the 2nd argument to the nth one, it's the core that should take
care of them. Not dial.
MAx
_______________________________________________
Callweaver-dev mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-dev