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
