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

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

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

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 7 Dec 2004 10:45:53 -0800

Paul,

In SIP each dialog has a pair of peers.  They each maintain local  
dialog state and they maintain their idea of the remote dialog state.   
While SIP goes to great lengths to encourage that the my view of my  
peer's state and my peer's view of his or her state are the consistent  
most of the time. However, in the absence of globally synchronized  
clocks, it is impossible to make this state consistent *all* of the  
time. Necessarily, there are periods of time (which are typically short  
in ordinary operational environments) during which each peer has a  
different view of the network state.  For example I am in a stable call  
with Alice.  Her dialog state is active and my dialog state is active.   
Now I send a BYE.  My dialog state is terminated, but her dialog state  
is still active until she receives my BYE.  This is a feature.

Now we move to the problem at hand.  I send a mid-dialog request and  
receive a 481 response.  My peer clearly believes that the dialog is  
terminated. I will immediately send a BYE to alert any proxies in the  
path that the call is over.  The question is whether I now represent my  
state using the dialog package as active or terminated.

I can mark my state as terminated and immediately send a BYE and any  
notifications about this change more or less simultaneously.  As I  
describe below, I don't see any contradiction with RFC 3261, and this  
seems a reasonable and practical way to implement the event package.

Alternatively, I could leave the state as active after I receive the  
481 until I send the BYE. There are several problems with this:
- there is nothing I could possibly do, nor any message I could receive  
that would cause me to still consider the dialog truly active.
- representing the state as active is disingenuous.  The other end  
already considers the dialog over, and I am about to tell any proxys in  
the path that I consider the dialog terminated as well.  If a new  
SUBSCRIBE arrives before I send the BYE, I would tell the subscriber  
about a call that is effectively gone.
- If I transition to terminated by sending a BYE, then the reason would  
be "local-bye" instead of "error" or "timeout", which represents a loss  
of useful information.
- since I should send the BYE immediately, when the transition occurs  
is rather academic.  Even if I wait until I send the BYE to change the  
state, a NOTIFY advertising this change could still arrive at a  
subscriber before the BYE arrives at the first proxy (the first BYE  
could be retransmitted).

Additional comments on the relevant sections in 3261 below...

>    associated with it.  See Section 15 for details.

this statement does not prevent other methods of terminating a session  
(notably CANCEL, or receiving a 6xx class response to the initial  
INVITE).

>    transaction would inform the TU about the timeout.)

this statement clearly says that a mid-dialog 481 or 408 terminates the  
dialog.

Why this is a SHOULD instead of a MUST is something I do not know, and  
I suspect this is a bug in the spec.  I personally cannot think of what  
an implementor might do instead.  I believe the SHOULD might actually  
apply to the fact that you SHOULD send a BYE, but if there are no  
intervening proxies, there is no reason to do so.

>       For INVITE initiated dialogs, terminating the dialog consists of

this is an informative statement (all indented statements in 3261 are  
informative).

3261 should probably be more explicit as to why you should send a BYE  
when you think the dialog is already terminated (so proxies can be  
informed of this if they care).  However there is already a bug filed  
on the spec about clarifying the difference between terminating a usage  
of a dialog and the dialog itself. Indeed, per Robert Sparks's  
discussion about dialog usages, if I have a session started with  
INVITE, and then add a subscription with a REFER, do I need to also  
terminate the subscription usage of the dialog by sending a BYE and a  
NOTIFY Subscription-State: terminated?

> a second, compliant to this draft.

I do not believe that there are two concepts of dialog state.  I think  
you are having confusion around an informative statement in RFC3261  
which is unclear.

thanks,
-rohan

> I therefore believe this should be
> resolved quickly and look forward to reading your response.
>
> Regards,
> Paul D Smith
> Network Protocols Group
> Date: December 7, 2004 4:52:03 PST
> To: Subject:
>
>
>
> <ATT79302.txt>
>
> <ATT79303.txt>