2009/1/16 Pekka Pessi <ppe...@gmail.com>:
> 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.
I agree with you that the TO header field from original request should be
used...
Maybe I am not understanding correctly the ETSI tests. What do you think?
SIP_CC_OE_CE_V_017
Ref: RFC 3261 [1] sections 12.2.1.1, 13.2.2.4, figure 5 and 17.1.1.3.
Purpose: Ensure that the IUT when an INVITE client transaction is in the
Calling state, on receipt of a
Success (200 OK) response sends an ACK request with the To header
set *to the same value as in
the received final response*.
SIP_CC_OE_CR_V_001
Ref: RFC 3261 [1] sections 12.2.1.1 and 15.
Purpose: Ensure that the IUT, once a dialog has been established, to release
it sends a BYE request with a
*To header set to the same value as in the last received final
response*.
SIP_CC_OE_CR_V_002
Ref: RFC 3261 [1] sections 12.2.1.1 and 15.
Purpose: Ensure that the IUT, once a dialog has been established with a
final response in which the TAG in
the To header was omitted, to release it sends a BYE request *with
an identical To header without
TAG value*.
>
>>>>> - 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
