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. > - 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.) > - 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
