2009/1/16 Paulo Pizarro <paulo.piza...@gmail.com>: >>>> 17.1.1.3: ... The To header field in the ACK MUST equal the To header >>>> field in the >>>> response being acknowledged, and therefore will usually differ from >>>> the To header field in the original request by the addition of the >>>> tag parameter. >>> >>> This refers to ACK to 3XX/4XX/5XX/6XX? Looks like we have a bug there, >>> I've pushed the fix to darcs. > > Not only, but to the 2xx response too. All next requests (ACK/BYE/etc) > within this dialog must have the same TO header that this final > response. This is done for backwards compatibility with RFC 2543 for > dialog identification. According with the third paragraph in 12.2.1.1.
I think 12.2.1.1. talks about original request, not about final response to initial request? 12.1.2 talsk about setting remote URI from To header field; however, it does not say whether to use To header field from response or from request. 12.1.1.1 then mentions that for 2543-compatibility To header field from original request should be used. >>>> - SIP_CC_OE_CE_V_041: >>>> >>>> A second final response 2XX with a different Record-Route in the same >>>> INVITE transaction should change the Route header of the resent ACK. >>>> Sofia ignores the second Record-Route header and re sends the ACK >>>> exactly as the first one. >>> >>> I think the second paragraph in 13.2.2.4 refers to early dialogs; the >>> route set should not change after first 2XX to that dialog. (The >>> wording says otherwise, however.) >> >> I agree with you, it's right that the route set should not change >> after first 2xx to that dialog. >> A second final response 2XX with a different Record-Route in the same >> INVITE transaction only makes sense in the fork scenarios. >> I made a new test with a fork scenario, and sofia did not sent the >> second ACK with the new route set for the new dialog. It seems like >> the hairy fork bug :) >> >> So, Is it possible to help you to fix this fork bug? Or it is not >> advisable ... :) We need more rigorous testing, having those ETSI cases as check test cases (see check_nua.c) would make me confident. Of course, if you are not afraid sharp shards of fragile C code, you can have a peek inside NUA internals... -- Pekka.Pessi mail at nokia.com ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
