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
- [Sipping] How to process a Second BYE with differ… Preethi.Sadasivan
- RE: [Sipping] How to process a Second BYE with di… Brett Tate
- Re: [Sipping] How to process a Second BYE with di… Dale.Worley