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

From: "Paul D.Smith" <[email-masked]>
Date: Tue, 18 Jan 2005 15:37:04 -0000

Robert,

I have added comments in-line below but first a comment about
SIPits and SIP software in general.  It seems that one of our
disconnects is that you, quite rightly, point out that partner
implementations shouldn't <insert protocol misbehavior of your
choice here>.  You then use this to argue that my software
must therefore act in one specific manner based on this
assumption that the partner will play nice.

Unfortunately, one of the things we hit often is partner
implementations that are far from perfect and do all manner
of bizarre things.  Whilst we always point these out to our
customers, we have to bow to their response that "we don't
care what implementation X does, why can't you just keep the
call up"?

Now proving that most implementations at SIPits "play nice"
does not mean that the real world is nice.  Many
implementations never seem to go to SIPits and even different
software levels of implementations that do, don't always get
things right.  This means that our implementation has to
be as resilient as possible against bad SIP.

I believe Jon Postel said "be conservative in what you send,
and liberal in what you receive".  I interpret this as
"obey the protocol when you send, but don't be surprised if
other don't".  I still don't agree that a blanket 481
means "the dialog has gone" because that is not what
the definitions in RFCs 3262 and 3265 say.  They have
mangled the definition of 481 to relate to transactions
and subscriptions respectively.

OK, so where does this leave us?  I think we should progress as
follows.

1. 481 should not be used to indicate "what was this errant
   PRACK for"?  A new status code should be defined meaning
   "the dialog was there but I have no outstanding reliable
   provisional response - your PRACK is in error".  RFC3262
   must be amended accordingly.  This new status code does
   not cause the dialog to end.

2. 481 should not be used to indicate "this NOTIFY was within
   a valid dialog but I know nothing about this subscription".
   A new status code should be defined for this.  RFC3265 must
   be amended accordingly.  This new status code does not
   cause the dialog to end.

3. 481 means one thing, and one thing only.  The dialog is not
   known and as far as everyone is concerned, it no longer
   exists.

For a period of time, 481s may be sent in error and may cause
the odd call to be lost but we will live with this.  Long term
we have a single, clear meaning of 481 and we can get back to
more interesting aspects of the protocol.

Does this sound like a reasonable way forward?  If so, I
believe the next step raise this through more specific
postings to the WG for further discussion with a view to
getting the final decision possible raised in BUGZILLA.

Do you agree?

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: 18 January 2005 01:14
To: SIP Public Folder (E-mail)
Subject: Re: [Sip] FW: [Sipping] I-D
ACTION:draft-ietf-sipping-dialog-package-05.txt

On Jan 17, 2005, at 6:48 PM, Paul Kyzivat wrote:

>
>
> Robert Sparks wrote:
>> On Jan 17, 2005, at 7:53 AM, Paul D.Smith wrote:
>
>>> 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.
>> 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.

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.

[PDS] What is wrong with CSeq?  The previous request failed but
so what?  My next reINVITE etc. simply increments the CSeq and
on the dialog goes.

>
> 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.
CSeq.
Remote target
Local target

Do I need to go on?

>
> Of course I know you will bring up that multiple usages per dialog is 
> evil, but there are still use cases for them.
>
>> 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.
>
> 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.
>
>>> 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.
>> A PRACK with dialog identifers B will never affect the dialog with 
>> identifier A.
>> 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.
>
>>>   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.
>> 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.
>
> 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.)
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).

[PDS] I assume that this is because A should maintain 
the transaction for a period which allows B to
retransmit NOTIFYs.  Surely though network interactions
might allow a late NOTIFY to arrive after A has given
up waiting?  Legitimately, A will now send a 481 meaning
"no such subcription", but the dialog is perfectly healthy.

>
> - 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.
A is broken.
>
> - When B gets the 481 it destroys the complete dialog,
>   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.

[PDS] As above, RFC3265 has changed the meaning of 481. It
states there is no subscription, not there is no dialog.

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

>
>>> 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.
>> 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.
>
> Well, maybe not every corner case.
>
> 	Paul

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Tue, 18 Jan 2005 12:21:48 -0600

You know that I am a strong champion of Postel's Maxim -
its a major point we drive home carefully at every SIPIt and
is the cornerstone of the open source work I'm involved in.

Everyone must work hard to be liberal in what they receive.
However, you also have to be aware of the line past which
not following the protocol yourself will do more damage.
This is a place where it will.

Building new protocol, as you suggest below, might be
warranted (I respond more favorably for your point on
SUBSCRIBE than I do on PRACK because I can think
of corner cases (network race conditions) where things
following protocol can get into this condition. I'm not
yet convinced that ignoring a PRACK to a provisional
response you didn't send is a sane thing to do.

There is definitely need for clarification through multiple
drafts, and I will make the appropriate bugzilla entries.

Other comments inline.

> and subscriptions respectively.

I completely disagree with your interpretation of 3262 and
3265. Looking at the path you are pointing at below, there
may be semantics you would _like_ to have that those don't
ask for.

>    known and as far as everyone is concerned, it no longer
Nuance -
The 481 means the recipient of the request doesn't know the dialog,
and the sender should stop talking to the recipient about it.

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 19 Jan 2005 15:37:51 +0100

Robert,

I agree with you here, but you need to consider the dialog stateful 
intermediaries in the case that an endpoint no longer knows about a 
dialog and sends a 481. Should the dialog stateful intermediaries 
terminate that dialog abnormally or should they wait for the BYE coming 
from the originator. I suggest the former. Any statistics on what 
current dialog stateful proxy implementations do?

Regards,
Hisham