Subject: [Sipping] How to process a Second BYE with different Via Branch but with same Cseq.

From: [email-masked]
Date: Wed, 11 Jul 2007 13:21:55 +0530

Hi,
  I have a query regarding the following testcase 

Test specification - ETSI TS 102 027-2 V3.1.1 (2004-11)
TPId: SIP_CC_TE_CR_V_022
Status: Mandatory
Ref: RFC 3261 [1] sections 17.2.3, 17.2.2, 12.2.1.1 and 15.1.2.
Purpose: Ensure that the IUT, having already answer to a BYE request, on 
receipt of a BYE request, before
timer J fires, including a Via header set with a different branch 
parameter but with the Request-
URI, To tag, From tag, Call-ID and CSeq identical as in the first BYE 
request, repeats its last
response.

Is the above test case and the expected behavior correct?
Should the above test case be stated as "with the same branch parameter"?

IMO, after sending a 200OK for the first BYE the UAS closes the dialog but 

the transaction as the stack should still remain till the Timer J fires. 
The intent of 
Timer J is to send the previous response (the same 200OK) in case a 
retransmitted BYE is received. 

Please comment on the above observation and the test case.

Thanks and Regards,
 Preethi..
------------------------------------------------------------------------------
Preethi Sadasivan,
Software Engineer,
ARICENT ,
Bangalore.
tel: +91-80-41069118
------------------------------------------------------------------------------

***********************  Aricent-Private   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 11 Jul 2007 09:00:32 -0400

With the current wording concerning the change of Via branch, the
testcase is not correct since the BYE is forking/merging within the
dialog which is being released.  Thus the situation can lead to a 482 if
the merge is detected; the 482 is discussed within
draft-ietf-sipping-dialogusage.  Among the other possible responses are
481, 500, and 200.  However if the 200 is sent, it is not repeating the
last response as the testcase claims since the response's Via would be
different.
 
Yes; the testcase should indicate that the Via be the same if it is
trying to trigger a repeat of the last response.

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Wednesday, July 11, 2007 3:52 AM
	To: [email-masked]
	Subject: [Sipping] How to process a Second BYE with different
Via Branch butwith same Cseq.

	
	Hi, 
	
	Test specification - ETSI TS 102 027-2 V3.1.1 (2004-11) 
	TPId: SIP_CC_TE_CR_V_022 
	Status: Mandatory 
	Ref: RFC 3261 [1] sections 17.2.3, 17.2.2, 12.2.1.1 and 15.1.2. 
	Purpose: Ensure that the IUT, having already answer to a BYE
request, on receipt of a BYE request, before 
	timer J fires, including a Via header set with a different
branch parameter but with the Request- 
	URI, To tag, From tag, Call-ID and CSeq identical as in the
first BYE request, repeats its last 
	response. 
	
	Is the above test case and the expected behavior correct? 
	Should the above test case be stated as "with the same branch
parameter"?
	
	IMO, after sending a 200OK for the first BYE the UAS closes the
dialog but 
	the transaction as the stack should still remain till the Timer
J fires. The intent of 
	Timer J is to send the previous response (the same 200OK) in
case a 
	retransmitted BYE is received. 

	Thanks and Regards,
	Preethi..
	
------------------------------------------------------------------------
------
	Preethi Sadasivan,
	Software Engineer,
	ARICENT ,
	Bangalore.
	tel: +91-80-41069118
	
------------------------------------------------------------------------
------

	***********************  Aricent-Private
*********************** 
"DISCLAIMER: This message is proprietary to Aricent and is intended
solely for the use of 
the individual to whom it is addressed. It may contain privileged or
confidential information and should not be 
circulated or used for any purpose other than for what it is intended.
If you have received this message in error, 
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of
this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by
this email including damage from virus."

---

From: [email-masked]
Date: Wed, 11 Jul 2007 23:26:29 -0400

This is rather nasty...

This situation can happen within a dialog, because by RFC 3263, the
UAC can attempt to send a BYE to the UAS by more than one transport,
and for each transport/address/etc. combination that it tries, it must
use a different branch value.  (RFC 3263, section 4.3).

So one possible scenario is:

UAC sends BYE to UAS via UDP using branch1
UAS receives BYE/branch1, sends 200
200 response is lost
UAC re-sends BYE to UAS via TCP using branch2
UAS receives BYE/branch2

Unfortunately, RFC 3261 specifies that transaction matching is done on
the branch parameter, so the UAS will not treat the second BYE as
being a re-send of the first one.

It seems to me that perhaps RFC 3263 should be edited, to have the
same branch value used for request re-sends with different protocols.

Dale