On 16.11.10 22:00, Stefan Sayer wrote:
Bogdan Pintea wrote:
Wouldn't it be cleaner to keep the logic invoked in AmSession::process()
local to AmSession and invoke AmSipDialog::updateStatus() from within
AmSession? After all, there is a AmSession::dlg member, so, I'd be
inclined to expect the AmSipDialog "later" in the event flow.
My understanding is the AmSession keeps the session related things,
while AmSipDialog is just a repository for the "dialog" things (id's,
tags, cseqs, dialog state machine transitions etc.)
actually, now I also think it makes sense to process all SIP related
stuff in AmSipDialog first - actually this is where the SIP processing
happens. Then, if something changes that is interesting for the
application, the AmSipDialog calls the proper AmSession event handler.
A drawback with this is that it is indeed more complicated to deeply
control SIP stuff from within the application (AmSession) before it is
processed by the SIP layer.
As 100rel is really a SIP feature, I think that the proper solution
would actually be to move the code into AmSipDialog. If there is
something where the application could want to interfere with the
default processing (or needs to be notified of what is going on with
100rel), then the handler interface should be extended.
Exactly.
In fact, in the offer_answer branch, parts of the 100rel handling is
already in AmSipDialog. Maybe we should make an effort on this branch to
be mergeable soon, so that we do not re-implement everything twice. (the
merge gets more gorry as well, by the way...)
Cheers
Raphael.
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
