Juha,
whether the code resides in it's own source files or is combined in
sbc.cpp does not make a great difference (at some point this code may
be split up in several files).
providing a DI api from sbc module to logic modules is definitely
overkill.
additionally, it is in some cases not easily possible to correctly
combine the logic of several logic modules if there is a low level
hooks API (onOtherReply, onCancel etc).
therefore, I will generalize the prepaid API as i sketched before that
it has the possibility to
- drop call
- refuse call with code, reason
- start call and set timer
which will be enough that you can have call_control and prepaid in
their own modules. This works fine through a DI api, where sbc module
calls the logic modules at the appropriate places. I like this
approach better, because the API is clear and you don't get any
side-effects.
Stefan
o Juha Heinanen on 09/19/2011 07:21 AM:
stefan,
you asked about the api stuff.
i don't know anything about c++ programming, but i would imagine that it
would be possible define for each feature that can be enabled its own
class in its own .cpp/.h files in sbc source directory so that object of
that class has access to call profile, call state, and message fields,
such as callid, uris, etc.
each such would then provide methods for SBC.cpp to call, such as
onInvite, onOtherReply, onCancel, stopCall, etc. that way, for example,
prepaid class could make in its onInvite method a di call with whatever
params it wished, whereas onInvite of call_control class would not make
such call, but just do its stuff locally. similarly, stopCall method of
prepaid class would test if call is in connected state, before doing its
stuff, whereas call_control stopCall method would so its stuff no matter
what the call state is. if a feature is enabled, SBC.cpp would just
create an object of the corresponding feature class and call its methods
at appropriate places.
this kind of api would make SBC.cpp cleaner, because it would not
contain any logic of the enabled features.
-- juha
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
