2009/1/16 Paulo Pizarro <paulo.piza...@gmail.com>: > Hi Pekka, > > 2009/1/15 Pekka Pessi <ppe...@gmail.com>: >> 2009/1/14 Paulo Pizarro <paulo.piza...@gmail.com>: >>> I found problems in the following tests : >>> >>> - SIP_CC_OE_CE_V_017, SIP_CC_OE_CR_V_001, SIP_CC_OE_CR_V_002 >>> ETSI requests that the TO header in the ACK/BYE messages are exactly >>> the same as the one found in the final response (200 OK). Sofia only >>> preserves the tag param nowadays. The RFC 3261 says: >>> >>> 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. >> >>> - 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 ... :) > >> >>> - SIP_CC_OE_CE_V_019: >>> >>> That's the famous hairy bug in fork handling... :-) >>> >>> Let me try analyse the Record-Route problem. It seems to be a NTA >>> problem, right? >> >> Mixed one; once set, nta does not allow route to be changed. >> >> -- >> 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
