On 11/16/10 21:49, Stefan Sayer wrote: >> 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.
Mmm, well, thing is that if it's an INVITE, I need to stop the session. If a re-INVITE, just to reject it (and keep the session). Now, I could signal this in the Exception (smth. like 1=keep session, 0=kill it), but then I'd spread the 100rel logic in both classes, which would be a hack. > > >> >> 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? That's what I've started, but don't know how to do it "cleanly". Well, for now, I could then extend the AmSipDialogEventHandler (with session tearing down functionality), till the clear separation between the two (AmSession <-> AmSipDialog) is delivered. What do you think? Bogdan. > > Stefan > _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
