[Sipping] Re: Semi Regular Examples draft

Miki HASEBE <hasebe.miki@rdc.east.ntt.co.jp> Mon, 28 March 2005 08:16 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20263 for <sipping-web-archive@ietf.org>; Mon, 28 Mar 2005 03:16:41 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFpWt-0002Mp-VM for sipping-web-archive@ietf.org; Mon, 28 Mar 2005 03:23:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFpLa-0006qZ-Le; Mon, 28 Mar 2005 03:11:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFpLX-0006qU-7p for sipping@megatron.ietf.org; Mon, 28 Mar 2005 03:11:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19796 for <sipping@ietf.org>; Mon, 28 Mar 2005 03:11:36 -0500 (EST)
Received: from eastmail2.ntt-east.co.jp ([202.229.5.45] helo=evx2.enoc.east.ntt.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFpRz-000298-01 for sipping@ietf.org; Mon, 28 Mar 2005 03:18:19 -0500
Received: from emix1.enoc.east.ntt.co.jp by evx2.enoc.east.ntt.co.jp with ESMTP id j2S8At122032; Mon, 28 Mar 2005 17:10:55 +0900 (JST)
Received: from cip11.noc.east.ntt.co.jp by emix1.enoc.east.ntt.co.jp with ESMTP id j2S8AtN09561; Mon, 28 Mar 2005 17:10:55 +0900 (JST)
Received: from 10.162.251.24 ([10.8.52.77]) by cip11.noc.east.ntt.co.jp (MOS 3.4.6-GR) with SMTP id BDQ12068; Mon, 28 Mar 2005 17:10:54 +0900 (JST)
Message-Id: <200503280810.BDQ12068@cip11.noc.east.ntt.co.jp>
Date: Mon, 28 Mar 2005 17:12:39 +0900
From: Miki HASEBE <hasebe.miki@rdc.east.ntt.co.jp>
X-Mailer: EdMax Ver2.85.5F
MIME-Version: 1.0
To: Malleswara Rao Ankem <malleshavn@gmail.com>
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3fe6b8640503230132545d118e@mail.gmail.com>
References: <3fe6b8640503230132545d118e@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Cc: sipping@ietf.org, sip-implementors@cs.columbia.edu, koshiko@ceres.ocn.ne.jp
Subject: [Sipping] Re: Semi Regular Examples draft
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>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit

Hi Malleswara,

Thank you for the comment.
I understood the meaning which you pointed out and I think my understanding
is same of you.
These are my understandings from section 15.1.1 of RFC3261.
1) The session is terminated by the BYE message sending out.
2) The dialog is terminated by receiving the response to the BYE message
   or a timeout
I explain with a figure, such as below:

   Alice                     Bob
     |                        |
     |   Both Way RTP Media   |
     |<======================>|
     |                        |
     |         BYE F1         |
     |<-----------------------| Session is terminated
     |                        |
     |         200 F2         |
     |----------------------->| Dialog is terminated. BYE-transaction is 
     |                        | "Completed" , timer K starts.
     |                        |

According to this general sequence, after BYE transmission,a client is
considered to hold a dialog until it receives response message or
timer K expires.

When once BYE message is sent, the dialog must be terminated finally.
In other words, from description of RFC3261, I think that the end of a 
dialog is promised to terminate by transmission of BYE message.
But it is thought that the dialog does not terminate immediately, the
dialog terminate by receiving a response message or timer K expires.

Therefore we should need a consideration about the case when a client
receives any messages after a dialog complited. is reserved by BYE
message until a dialog is completed.

For example, the sequence which is needed consideration is reception
of the REFER signal.
It is shown in 2.4 of a semi-regular draft.
When receiving signals, such as REFER which effects on a dialog, after
a BYE message transmitted, I think it reasonable to answer so that a
dialog may not exist.

I want to add a description as discussed above about disappearance of a
dialog to a description of section 2.4 of a semi-regular draft.

Please point out, if I misunderstood RFC3261.
Let me know if you have any other comments to this proposal.

Thank you very much for your cooperaqtions.

Miki Hasebe,


---------------------------------------------------------
Miki HASEBE
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 4768
E-mail: hasebe.miki@rdc.east.ntt.co.jp
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
---------------------------------------------------------

_______________________________________________
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