Stefan Sayer writes:
> 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,
about "side effects", i just want to make it clear that i didn't propose
overloading SBCDialog::onInvite, onCancel, stopCall, etc. methods, but
(if needed) having corresponding methods in feature (prepaid, call_control,
etc) classes and calling them in SBCDialog methods.
for example, if prepaid or call_control feature is enabled, SBC.cpp creates
corresponding object. then SBCDialog::stopCall() that currently is
implemented lke this
void SBCDialog::stopCall() {
if (m_state == BB_Connected) {
stopPrepaidAccounting();
stopCallTimer();
}
decCallControlCalls();
terminateOtherLeg();
terminateLeg();
}
would be implemented like this:
void SBCDialog::stopCall() {
if (PrepaidObject != NULL) PrepaidObject.stopCall();
if (CallControlObject != NULL) CallControlObject.stopCall();
terminateOtherLeg();
terminateLeg();
}
prepaid stopCall method would then contain
if (m_state == BB_Connected) {
stopPrepaidAccounting();
stopCallTimer();
}
and call control stopCall method would contain:
decCallControlCalls();
hopefully your api is as simple.
-- juha
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
