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.
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. Well, the quick answer would be: put the 100rel stuff in AmSession. Which I actually did. But then, I have some further requirements: a reply to a request (PRACK) arrived, and I need to consume it immediately, rather then call any AmSession inheritor; this would mean I need to no longer call ::onSipReply(); but this calling is decided in the AmSipDialog::updateStatus(), so I don't have the control in AmSession. Another answer might be to extend the AmSipDialogEventHandler API, to allow for tearing down a session; but I'd find this obfuscating. Any hints on this? 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.) Sorry if overlooking smth. obvsious. Thanks, Bogdan. On 08/10/10 00:30, Bogdan Pintea wrote: > > > On 08/02/10 23:40, Vladimir Broz wrote: > >> I tried to test PRACK implementation. My configuration is very simple - >> just the "ann_b2b" application (no outbound proxy, just R-URI >> application parameter). I send request with R-URI: >> sip:[email protected]:5060;app=ann_b2b. I tried also ";app=sst_b2b" >> but with the same result: >> >> The incoming INVITE request contains Require: 100rel and Supported: >> 100rel headers. But when SEMS receives and parse this request, it aborts >> with "[#b6a1ab90/27483] [onSipRequest, AmSession.cpp:708] ERROR: BUG: >> unexpected value `2' for '100rel' switch". >> >> In the sems.conf I use parameter "100rel=require". > > This should be fixed now. Thanks for raising it. > >> When the >> "100rel=supported" is used, no PRACK is generated to the 180 response on >> the second leg - response from UAS (no trace attached :( ). >> > > Yeah, this is true, but a proper fix needs be discussed. > > There would be two topics: > > 1. Where to place the insertion of "Supported/Required: 100rel". > Right now, this is done in AmSession::send(Re)Invite(); however, some > apps (like ann_b2b) calls directly AmSipDialog::sendRequest("INVITE", > ...), bypassing the insertion. > Now, since sendRequest() calls AmSession::onSendRequest(), a workaround > would be to place here a check (like > if (method == "INVITE") {insert S/R: 100rel} > ), but it wouldn't be too elegant (since there are already sendXXX() > class methods for different XXX SIP methods -- all apps should maybe use > those?). > > 2. where to do the interception of 100rel support in the 1xx replies to > INVITE (and send the PRACK based on that). > Right now, this is done in AmSession::onSipReply(). The bad thing about > it is that when the reply to PRACK comes, this reply can not be > intercepted and "dropped" here, also in this method. > This means that it goes all the way through the onReplies and can > generate some troubles for some apps, like ann_b2b, which incorrectly > mistakes it as a reply to the original INVITE and generates upstream > reINVITEs w/o SDP first and then w/ SDP, once the 200 OK for the INVITE > actually arrives. > > A solution would maybe be to add a reply code to AmSession::onSipReply() > and stop processing when false is returned. > > > What do you guys think? > > Cheers, > Bogdan. _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
