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
