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

From: "Paul D.Smith" <[email-masked]>
Date: Mon, 17 Jan 2005 13:53:38 -0000

Robert, Rohan,

I have not noticed any response to my concerns about the effects of the
aims of the dialog package (i.e. 481 means dialog gone) on call
stability, as expressed below.

Can I press you to either confirm that I have legitimate concerns or
indicate if I'm off-base and the circumstances I have mentioned
will never arise.

Thanks,
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: Paul D.Smith 
Sent: 13 December 2004 12:48
To: SIP Public Folder (E-mail)
Subject: RE: [Sip] FW: [Sipping] I-D
ACTION:draft-ietf-sipping-dialog-package-05.txt

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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Jan 2005 12:32:57 -0600

Paul -

Response inline:

> rather it is a transaction or subscription specific error.

A subscription _is_ a usage in a dialog.
In both of these cases, the dialog should be destroyed.

I think you are thinking that if you are working along happily with
a dialog with identifier A and a message shows up with identifier B
then dialog A gets destroyed - this is clearly not the case.

What these requirement cover is when Element 1 thinks it is in
a dialog with Element 2, and Element 2 disagrees (for whatever reason).
The 481 is the response that lets Element 1 know that things are in 
trouble,
and they are in trouble at the dialog level.

> an errant PRACK or NOTIFY probably has no affect on their call.

A PRACK with dialog identifers B will never affect the dialog with 
identifier A.
There is no "probably" here.

>   And if

Have I seen where you misunderstood the intent? All these requirements
indicate that an element receiving a 481 with dialog identifier B treats
dialog B as terminated. This says nothing about any other dialogs that
are in play at that endpoint.

If I haven't understood your concern yet, try again - preferably 
showing an
example call-flow where you see a problem.

> contribute to poor perception of SIP hardware as dialogs fail

I disagree. This is something we've tested heavily at SIPIts. Existing
equipment is following the specifications, and the effect on the 
applications
is correct.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Jan 2005 19:48:22 -0500

> A subscription _is_ a usage in a dialog.

One of potentially several usages.

> In both of these cases, the dialog should be destroyed.

Why? That might break another usage.

Each usage has its own way of timing out, etc. anyway.
It makes much more sense to me to simply destroy the corresponding 
usage. If there are then no usages, the dialog can be destroyed.

Of course I know you will bring up that multiple usages per dialog is 
evil, but there are still use cases for them.

> and they are in trouble at the dialog level.

Yes, but it is rooted in the fact that 3261 created the concept of 
multiple usages per dialog, but mostly pretends that they aren't there.

There is clearly a difference between:
- I don't recognize this dialog id
- I don't recognize this subscription on this dialog id

But there is only one status for them both, and no contextual way to 
tell which is the intended meaning.

> There is no "probably" here.

I thought the intended case was a prack within the same dialog.
In this case, PRACK is only meaningful in the context of an invite 
usage. So one might assume that getting an errant one implies something 
is wrong with your peer in the invite usage. So I can see killing the 
invite usage.

But if there is another usage sharing the same dialog, then while they 
are related (or else they wouldn't be sharing a dialog), they may not 
need to be fate shared in this case.

> If I haven't understood your concern yet, try again - preferably showing an

OK, how about this:

- A calls B (which perhaps is a conference focus)
   this creates a dialog, and an invite usage.

- within that dialog, A sends a REFER to B, to bring somebody
   else into the call. This creates an implicit subscription
   (usage) in the same dialog.

- B starts sending NOTIFYs to A with refer status.

- The refer completes and B sends A a final notify,
   terminating the subscription.

- A sends a 200 for the final notify. It also destroys
   the usage. (But the dialog remains for the invite.)

- The 200 is lost in the network.

- Eventually, B times out the 200 and retransmits the
   NOTIFY.

- A gets the NOTIFY, but has no corresponding usage, so
   responds with a 481.

- When B gets the 481 it destroys the complete dialog,
   taking down the call. WRONG!

> equipment is following the specifications, and the effect on the 

Well, maybe not every corner case.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Jan 2005 19:12:39 -0600

> Why? That might break another usage.

Because the _DIALOG STATE_ is no longer there on the
peer you touched. Things like CSeq are not there anymore.
Any other usage is already broken.

> usage. If there are then no usages, the dialog can be destroyed.
CSeq.
Remote target
Local target

Do I need to go on?

> usage. So one might assume that getting an errant one implies 
> something is wrong with your peer in the invite usage. So I can see 
> killing the invite usage.
>
A went non-standard on your second sentence. The
transaction will have to complete before it removes
the usage (the NOTIFY might get a 401 for example).
> - A gets the NOTIFY, but has no corresponding usage, so
A is broken.
>   taking down the call. WRONG!
No - B has no way to know that what it saw was because A
was broken, so it needs to behave as if A legitimately didn't
find that dialog state.

Can you create an example where one party hasn't
violated the protocol and terminating the dialog is
the wrong thing to do?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jan 2005 12:03:42 -0500

Robert,

I agree Paul Smith's reply to this message. I also want to respond to 
your comments. To avoid further nested quoting I am starting from your 
reply other than his.

	Paul

> Any other usage is already broken.

This may be the fundamental difference here. You think this response 
means that the dialog state is gone. But the descriptions of the use 
cases when this status may be used include cases when the dialog state 
need not be gone. It is an ambituity in the use of the error code.

Paul Smith's proposed change would resolve this. There may be other 
possible resolutions.

>> usage. If there are then no usages, the dialog can be destroyed.

No. In the case being discussed those should all remain valid.

> the usage (the NOTIFY might get a 401 for example).

You lost me here. A *received* the NOTIFY, and sent the 200 response, so 
there will be no 401 response. The transaction remains for a time in 
order to swollow retransmissions, but I don't think that has any impact 
on the destruction of the subscription. Quoting from 3265:

    3.2.4. Subscriber NOTIFY Behavior

    If the "Subscription-State" value is "terminated", the subscriber
    should consider the subscription terminated.

    3.3.4. Dialog creation and termination

    A subscription is destroyed when a notifier sends a NOTIFY request
    with a "Subscription-State" of "terminated".

Note, the above sounds like it is written from the POV of the notifier. 
There is no corresponding description for the subscriber. In the absence 
of anything to the contrary, I believe this is also applicable to the 
subscriber upon receiving the NOTIFY. Continuing:

    If a subscription's destruction leaves no other application state
    associated with the dialog, the dialog terminates.  The destruction
    of other application state (such as that created by an INVITE) will
    not terminate the dialog if a subscription is still associated with
    that dialog.

       Note that the above behavior means that a dialog created with an
       INVITE does not necessarily terminate upon receipt of a BYE.
       Similarly, in the case that several subscriptions are associated
       with a single dialog, the dialog does not terminate until all the
       subscriptions in it are destroyed.

I see nothing here about waiting for a transaction to fade away.

>> - A gets the NOTIFY, but has no corresponding usage, so

We disagree here. Can you point me to something that demonstrates this?

Note, I think there are similar issues around BYE. When do I consider 
the invite usage gone? When I receive the BYE and send a 200 to it? Or 
later, when the transaction state machine for the BYE finally goes away? 
I think most people will believe it is when the BYE is received or the 
200 response is sent for it.

> was broken, so it needs to behave as if A legitimately didn't

Or didn't find the subscribe usage. The ambiguity in the meaning of 481 
is the root problem here.

> violated the protocol and terminating the dialog is

If you don't accept the above, and can convince me that it is really a 
violation, then I don't know if I can come up with one. (I thought I was 
doing good to come up with this one.)

That doesn't alter the basic fact that there is ambiguity in the meaning 
of 481. It is at least plausible to argue that a bug in one usage 
shouldn't unnecessarily cause other usages to fail. But I realize this 
isn't the strongest of cases.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 18 Jan 2005 12:29:47 -0600

> You lost me here. A *received* the NOTIFY, and sent the 200 response, 
> so there will be no 401 response. The transaction remains for a time 
> in order to swollow retransmissions, but I don't think that has any 
> impact on the destruction of the subscription. Quoting from 3265:

The retransmission you have two steps below (where B retransmits the 
NOTIFY) happens during this time you just mentioned.
The transaction is still around specifically to send that 200 again 
when B retransmits the NOTIFY. If A sends a 481 in this
time, it has violated protocol. It's sent two different final responses 
to the SAME TRANSACTION.

> Note, the above sounds like it is written from the POV of the 
> notifier. There is no corresponding description for the subscriber. In 
> the absence of anything to the contrary, I believe this is also 
> applicable to the subscriber upon receiving the NOTIFY. Continuing:
>

Did above.

> later, when the transaction state machine for the BYE finally goes 
> away? I think most people will believe it is when the BYE is received 
> or the 200 response is sent for it.
>
> Or didn't find the subscribe usage. The ambiguity in the meaning of 
> 481 is the root problem here.
>
> violation, then I don't know if I can come up with one. (I thought I 
> was doing good to come up with this one.)
>
> That doesn't alter the basic fact that there is ambiguity in the 
> meaning of 481. It is at least plausible to argue that a bug in one 
> usage shouldn't unnecessarily cause other usages to fail. But I 
> realize this isn't the strongest of cases.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 18 Jan 2005 11:17:40 -0800

Paul,

Just responding to your example.

> - B starts sending NOTIFYs to A with refer status.

Paul, I'm assuming that A responds to these with a 200, so the dialog 
gets setup correctly....

[ There is potentially an issue if B sends a NOTIFY and A does not want 
to this subscription any longer.  A could send a 481 to terminate the 
usage (the implicit subscription).  Does this also terminate the 
dialog?  ]

> - A gets the NOTIFY, but has no corresponding usage, so

This will never happen in a compliant implementation. If B is merely 
retransmitting the NOTIFY, the CSeq will be the same as the previous 
NOTIFY, and a compliant implementation of A will resend the previously 
sent response (in this case the 200).  This retransmission (handled by 
the transaction layer) does not affect A's view of the state of the 
usage or the dialog (in the TU).  A's local state already reflects that 
the usage is terminated.

thanks,
-rohan

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jan 2005 14:47:54 -0500

> Paul, I'm assuming that A responds to these with a 200, so the dialog 

Right. I left that out as unnecessary detail.

> usage (the implicit subscription).  Does this also terminate the dialog?  ]

That is a really good question. Yet another case entangled in the 
overloading of the 481 response.

This may be the "valid" use case for Robert, since I now see why my 
example was invalid.

> usage or the dialog (in the TU).  A's local state already reflects that 

Yes. I get it now.

So I didn't succeed in finding a *valid* use case that exhibits the problem.

Yours above may be one - it too is debatable.

If no valid use case can be found, then the urgency of the problem goes 
way down. I think it is still a problem, but maybe not one that we can 
justify fixing.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Jan 2005 14:20:22 -0600

>> NOTIFY, and a compliant implementation of A will resend the 
>> previously sent response (in this case the 200).  This retransmission 
>> (handled by the transaction layer) does not affect A's view of the 
>> state of the usage or the dialog (in the TU).  A's local state 
>> already reflects that the usage is terminated.
>
> Yes. I get it now.
>
> If no valid use case can be found, then the urgency of the problem 
> goes way down. I think it is still a problem, but maybe not one that 
> we can justify fixing.
>
> 	

Well, the case as Paul Smith raised it and as I think I understood it 
still stands.

If somebody commits a minor protocol infraction in a dialog with me, am 
I required to shoot the whole dialog? If so, then nobody else going to 
be able to talk to all those devices that send unsolicited NOTIFY 
transactions. Which might or might not be a good thing, depending on 
your customer requirements.

It would seem more robust to have some sort of final response that says 
"Your in-dialog request was inappropriate in the current context as I 
understand it and is being ignored. Perhaps you should see a 
therapist."

Of course, If there was such a response, people would use it to reply 
to most of my email. So maybe it's not such a good idea after all ;-).

--
Dean