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

"Brett Tate" <brett@broadsoft.com> Wed, 11 July 2007 13:00 UTC

Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8bo7-0008Ad-Jr; Wed, 11 Jul 2007 09:00:39 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1I8bo5-0008AV-3y for sipping-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:00:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8bo4-0008AN-Px for sipping@ietf.org; Wed, 11 Jul 2007 09:00:36 -0400
Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8bo0-0007L6-BO for sipping@ietf.org; Wed, 11 Jul 2007 09:00:36 -0400
Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:00:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sipping] How to process a Second BYE with different Via Branch butwith same Cseq.
Date: Wed, 11 Jul 2007 09:00:32 -0400
Message-ID: <BBE61D1553D8A34F812FF87377B2935F010668DA@ATL1VEXC020.usdom003.tco.tc>
In-Reply-To: <OF2965E640.822E8CB3-ON65257315.002A6A08-65257315.002B981E@flextronicssoftware.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] How to process a Second BYE with different Via Branch butwith same Cseq.
Thread-Index: AcfDkAiukiaxIwp5Sx2zs3JA+/7QdQAJtptA
From: Brett Tate <brett@broadsoft.com>
To: Preethi.Sadasivan@aricent.com, sipping@ietf.org
X-OriginalArrivalTime: 11 Jul 2007 13:00:17.0670 (UTC) FILETIME=[6E17C260:01C7C3BB]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665
Cc:
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0506912963=="
Errors-To: sipping-bounces@ietf.org

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: Preethi.Sadasivan@aricent.com
[mailto:Preethi.Sadasivan@aricent.com] 
	Sent: Wednesday, July 11, 2007 3:52 AM
	To: sipping@ietf.org
	Subject: [Sipping] How to process a Second BYE with different
Via Branch butwith same Cseq.
	
	

	
	
	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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP