Hi Bogdan,
Bogdan Pintea wrote:
Hi guys,
I'm having some difficulties to understand the new architecture of
events processing. More specifically, I find it a bit strange to have
the AmSession::process() function call, through the AmSip*Event()
functions the AmSession::dlg::updateStatus() functions.
I think that this was the most effective code obfuscation possible... ;)
but the reason for it is, I think, that at some time in the future,
the AmSession should just be the *application* logic, and this should
make it possible to move a SIP dialog (=a SIP call) from one to
another application, or also possibly to manage several SIP calls with
one app logic instance.
The pain I have from this mis-understanding: with the 100rel, I need to
check some dialog sanity conditions (like 100rel is "required", but some
INVITE is missing support for it) and break the call (=the session) if
this is not met. For this, I'd need access AmSession::setStopped(), but
all I have is the API allowed by the AmSipDialogEventHandler.
can't you throw an AmSession::Exception? this should reply with the
error code and stop the session properly.
Well, the quick answer would be: put the 100rel stuff in AmSession.
I was just at this moment wondering about it. Shouldn't actually this
stuff be in AmSipDialog?
Stefan
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
