Subject: 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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Dec 2004 09:00:15 -0500

inline.

	Paul Kyzivat

>       For INVITE initiated dialogs, terminating the dialog consists of

In the case of 481 responses, I have always assumed that the recipient 
should interpret this as meaning the dialog is already gone. (If you 
have already received a 481 response, what is the point of sending a 
BYE? It will simply get another 481 response.)

The exception here would be if you got a 481 response to a CANCEL or a 
PRACK, which could simply mean there was no matching transaction rather 
than dialog.

That logic doesn't necessarily extend to 408, since that could reflect a 
transient condition.

> -------------------------------------------------------------------------
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> -------------------------------------------------------------------------
> In order to maintain computing infrastructure integrity, Cisco Systems
> Enterprise Messaging Services and InfoSec teams have set a mail policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is prohibited 
> by this policy. The attachment has been removed from this message and 
> copied to quarantine by our systems. It will be held in quarantine for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email or 
> notifications from anti-virus systems. We will clearly mark a seperation
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
> 
> For further reference information about viruses and email antivirus 
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the full 
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html 
> 
> * This unique quarantine identifier: iB7DAW1C021076
> 
> If the matter is urgent, you may follow up by calling one of the below 
> referenced numbers. Please make every effort to provide the above 
> requested information via the support web tool prior to calling as it 
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc
> 
> 
> ------------------------------------------------------------------------
> 
> Date:
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Dec 2004 10:21:35 -0600

Paul -

The text you quote from 3261 looks pretty specific to me
and agrees with what Rohan writes.

There's more - please look at
draft-sparks-sipping-dialogusage-00 for a some discussion
of what 408 and 481 do to usages.

RjS

On Dec 7, 2004, at 6:52 AM, Paul D.Smith wrote:

> Date: December 7, 2004 6:52:48 AM CST
> To: Subject:
>
>
>
> <ATT79302.txt>
>
>
> <ATT79303.txt>_______________________________________________
> 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 new developments on the application of sip

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 7 Dec 2004 20:05:47 +0100

> and agrees with what Rohan writes.

Its look pretty specific to me also, but to what Paul Smith said.

"If the response for a request within a dialog is a 481

       sending a BYE."

This clearly says what Paul is stating.

Hisham

---

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Dec 2004 13:31:44 -0600

Then we should file a bug against that text in 3261.

I dug though this pretty hard when putting together the dialogusage  
draft.
I'll go through again and find the other parts of the text that support  
the
dialog being gone with the response (though it may be later in the  
week).

While I can see some potential issues with 408, 481 is really  
cut-and-dried.
A BYE will not gain you anything but another failed transaction.

RjS

On Dec 7, 2004, at 1:05 PM, Hisham Khartabil wrote:

>>> Subject: [Sipping] I-D  
>>> You can also visit  
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce