Subject: [Sip] FW: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt

From: "Paul D.Smith" <[email-masked]>
Date: Tue, 7 Dec 2004 12:52:51 -0000

Apologies - this e-mail should have gone to the SIPPING WG!

Paul DS.

-----Original Message-----
From: Paul D.Smith 
Sent: 07 December 2004 12:52
To: SIP Public Folder (E-mail)
Subject: RE: [Sipping] I-D
ACTION:draft-ietf-sipping-dialog-package-05.txt

Rohan,

As per my earlier post to the group, I have to disagree with your
assertion that a 408 or 481 failure of _any_ mid-dialog request
terminates the dialog (section 3.7.1 of this draft).

  "Once in the confirmed state, the call is active.  It can transition
   to the terminated state if the UAC sends a BYE or receives a BYE
   (corresponding to the "local-bye" and "remote-bye" events as
   appropriate), if a mid-dialog request generates a 481 or 408 response
   (corresponding to the "error" event), or a mid-dialog request
   generates no response (corresponding to the "timeout" event)."

RFC3261 is quite clear in distinguishing between BYE requests and other
requests.  The failure of a non-BYE request does not cause a dialog to
terminate although it should be taken as a prompt to the UA to end the
dialog
by sending a BYE.  To put it another way, non-BYE requests are not dialog
terminating, regardless of the status code of any resulting response.

If you believe this is not the case, can you please explain the meaning of
the following sections of RFC3261.

12.3 Termination of a Dialog

   Independent of the method, if a request outside of a dialog generates
   a non-2xx final response, any early dialogs created through
   provisional responses to that request are terminated.  The mechanism
   for terminating confirmed dialogs is method specific.  In this
   specification, the BYE method terminates a session and the dialog
   associated with it.  See Section 15 for details.

12.2.1.2 Processing the Responses

   ...

   If the response for a request within a dialog is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
   SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog if
   no response at all is received for the request (the client
   transaction would inform the TU about the timeout.)

      For INVITE initiated dialogs, terminating the dialog consists of
      sending a BYE.

I believe this is a serious issue because it potentially means that there
would be two concepts of the state of a dialog, one RFC3261 compliant and
a second, compliant to this draft.  I therefore believe this should be
resolved quickly and look forward to readong your response.

Regards,
Paul D Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: [email-masked] 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 23 November 2004 21:11
To: SIP Public Folder (E-mail)
Subject: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Session Initiation Proposal Investigation
Working Group of the IETF.

	Title		: An INVITE Inititiated Dialog Event Package for the
                          Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg, et al.
	Filename	: draft-ietf-sipping-dialog-package-05.txt
	Pages		: 39
	Date		: 2004-11-23
	
This document defines a dialog event package for the SIP Events
architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another
user, an receive notifications about the changes in state of INVITE
initiated dialogs that the user is involved in.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-dialog-package-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-dialog-package-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Tue, 7 Dec 2004 12:52:48 -0000

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