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

From: "Paul D.Smith" <[email-masked]>
Date: Mon, 13 Dec 2004 12:48:12 -0000

Robert, Rohan,

Having given this some more thought, I think I understand where you are
coming from, although I believe we are at risk of creating more problems
for SIP interoperability and, more importantly, the stability of calls
established with SIP devices.

RFC3261, section 12.2.1 states the following.

   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.

This is a reasonable statement.  In this case a 481 means "there is no
dialog" and clearly we expect this to be a permanent state.  Whether we
class the dialog as terminated before, or after, the BYE is a minor issue.

However, RFCs 3262 and 3265 have changed the use of 481 status codes.
RFC3262 states:

   If a PRACK request is received by the UA core that does not match any
   unacknowledged reliable provisional response, the UAS MUST respond to
   the PRACK with a 481 response.

RFC3265 states:

                              Designers of such mechanisms are also
   warned to make a distinction between sending a NOTIFY message to a
   subscriber who is aware of the subscription, and sending a NOTIFY
   message to an unsuspecting node.  The latter behavior is invalid, and
   MUST receive a "481 Subscription does not exist" response (unless
   some other 400- or 500-class error code is more applicable), as
   described in section 3.2.4.                                   

In both of these, the 481 is _NOT_ indicating that the dialog is flawed,
rather it is a transaction or subscription specific error.

Now consider my user, busily talking on their SIP phone.  The arrival of
an errant PRACK or NOTIFY probably has no affect on their call.  And if
it does, then they are in a position to determine this and terminated the
dialog.  But the combination of RFC3261, and your assertion that 481 must
mean "dialog is terminated" results in their call being dropped, despite
there really being no reason why it should.

I hope this has got across my concerns regarding "481 means terminated
dialog".  I appreciate that at least some of this might be tidied up in
later versions of specifications, but SIP hardware is already using the
current specifications, and will not adopt new behaviour for some time.
Until that time, having all 481 responses cause dialogs to end will
contribute to poor perception of SIP hardware as dialogs fail
unnecessarily.

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: Robert Sparks [mailto:[email-masked]]
Sent: 07 December 2004 19:32
To: SIP Public Folder (E-mail)
Subject: Re: [Sip] FW: [Sipping] I-D
ACTION:draft-ietf-sipping-dialog-package-05.txt

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:

>
> On Dec 7, 2004, at 5:21 PM, Robert Sparks wrote:
>
>> Paul -
>>
>> The text you quote from 3261 looks pretty specific to me
>> 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
>    (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."
>
> This clearly says what Paul is stating.
>
> Hisham
>
>>
>> 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:
>>
>>> 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: 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 questions on current sip
>>> Use [email-masked] for new developments on the application of sip
>>
>>
>> _______________________________________________
>> 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
>>

_______________________________________________
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