If the original BYE had a magic cookie, then a second BYE _without_ it is a new transaction (the language in 3261 doesn't say this explicitly, but it is assumed that a UAC would not send one BYE with a magic cookie, and a retransmission without). Additionally, since we compare the topmost Via in the 2543 tid case, changing the branch param between the two BYEs will also cause the match to fail. This test case is incorrect.

Best regards,
Byron Campen


Not sure the purpose is the "Purpose" list in the test case or for 2543
test?

 But the [Ref] listed in the test case is reference to RFC3261.

And for RFC2543(not bis02 afterwards) server, it didn't check the Via for
the request matching transaction at all.

Lavis

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 26, 2007 5:24 AM
To: [email protected]
Subject: Re: [Sip] Query about test case in [ETSI TS 102 027-2 V4.1.1
(2006-07)]

   From: Lavis Chow <[EMAIL PROTECTED]>

Purpose: Ensure that the IUT in a server BYE Proceeding state, on receipt
of
   a BYE request, including a Via header set with a different branch
parameter
without the magic cookie "z9hG4bK" but with the Request-URI, To tag, From
   tag, Call-ID, CSeq and top Via header identical as in the first BYE
request,
   repeats its last response.

Since "z9hG4bK" is not to be present, it may be testing RFC 2543 behavior.
Does this test make sense in that light?

Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip

This e-mail and its attachments contain confidential information from
HUAWEI, which
is intended only for the person or entity whose address is listed above. Any
use of the
information contained herein in any way (including, but not limited to,
total or partial
disclosure, reproduction, or dissemination) by persons other than the
intended
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by
phone or email immediately and delete it!




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to