Subject: [Sipping] DialogUsage: Clarity for 481

From: Robert Sparks <[email-masked]>
Date: Tue, 22 Nov 2005 16:31:33 -0600

The dialogusage draft asks if we need a separate response code
for "This usage doesn't exist" vs "This dialog doesn't exist". This is
motivated by the ongoing confusion around whether 481 to, say,
a NOTIFY terminates just the subscription or the dialog that contains
the subscription. It has been argued that 3261 and 3265 contradict
each other on this point.

I see two paths forward:

Option A:
    Keep the current recommendation in this draft that a 481 means
    the dialog state is gone - all usages are terminated. Start work in
    SIP to standardize a response that means "This usage is not found,
    but there's a dialog here that's still good".

Option B:
    Assert that 481 means only the usage is not found and start working
    on changing existing implementations to line up with that assertion.

With either option we would also need to start work on a normative
document updating 3261,3265 and possibly things like the dialog-event
package to amend the text that can be interpreted as contradictory.

I've long championed Option A, but am willing to consider adopting
the position of Option B if nobody presents a use-case where B would
break an existing application/deployment.

Here's the worst I can think of right now (I may be forgetting  
something):
If you have implementation A designed as if Option A had been taken,
and implementation B designed as if Option B had been taken, and
B has two subscriptions to A in the same dialog and A returns a 481
to one of those subscriptions, then until B generates traffic on the  
other
subscription (a resubscribe), B will think it's in a subscription and A
will think it's not. This is an ugly edge, but I don't think it's one  
we're
seeing in the real world.

The only real-world impacting case I can think of is if A and B above
are in an INVITE dialog and A issues a REFER. Later B sends a NOTIFY
to A that gets 481ed. A will tear down the call where B didn't intend  
to.
(This is part of why we didn't recommend 481ing a NOTIFY as a way
  to get out of an implicit subscription early). Given that we are  
putting
pressure on moving away from in-dialog REFERs anyhow, we could
choose to live with the current level of confusion in the implementation
base and concentrate on asking new implementations to do the right  
thing.

Can anyone think of other cases with more real impact that would argue
against B?

RjS

_______________________________________________
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, 22 Nov 2005 18:11:31 -0500

Good summary. I think you covered the interesting cases.

I am in favor of Option B.

	Paul

Robert Sparks wrote:
> Here's the worst I can think of right now (I may be forgetting  something):
> to one of those subscriptions, then until B generates traffic on the  other
> to A that gets 481ed. A will tear down the call where B didn't intend  to.
>  to get out of an implicit subscription early). Given that we are  putting
> base and concentrate on asking new implementations to do the right  thing.
>

---

From: Kannan <[email-masked]>
Date: Wed, 23 Nov 2005 16:30:28 +0530

This is not a use-case that breaks option B,but I think it is somthing worth 
mentioning.

I think that the 481 semantics and the multiple dialog-usage are tightly 
coupled. If we were to choose option B, we are implicitly giving a 
'go-ahead' to multiple dialog-usages. Otherwise, for a single dialog usage, 
both the interpretations would result in the session and the associated 
dialog being teared down.

With a single dialog usage, a dialog that is still good without the 
associated usage would not be of much use. In fact, this interpretation of 
481 might actually lead to these 'orphaned' dialogs, if nobody keeps track 
of the different usages associated  with the dialog. I guess we are indeed 
assuming that such associations would be maintained by the usages, for cases 
where a BYE is sent on a dialog which is shared by a subscription usage.  In 
these, we rely on the dialog-usage to take down the dialog.

An ideal thing would be to make the dialog autonomous like the transaction, 
and let it mind its own business irrespective of the usage, though it may be 
too much now to ask for.

-Kannan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Nov 2005 08:44:43 -0500

Kannan wrote:
> This is not a use-case that breaks option B,but I think it is somthing 
> worth mentioning.
> 
> 'go-ahead' to multiple dialog-usages. Otherwise, for a single dialog 
> usage, both the interpretations would result in the session and the 
> associated dialog being teared down.
> 
> associated usage would not be of much use. In fact, this interpretation 
> of 481 might actually lead to these 'orphaned' dialogs, if nobody keeps 
> track of the different usages associated  with the dialog. I guess we 
> are indeed assuming that such associations would be maintained by the 
> usages, for cases where a BYE is sent on a dialog which is shared by a 
> subscription usage.  In these, we rely on the dialog-usage to take down 
> the dialog.

A dialog is expected to go away when all its usages go away. (I.e. based 
on reference counting.) I think this is stated explicitly somewhere. If 
not, then it is at least implied.

Dialogs state only exists in the UAs. They need to keep track of dialog 
usages, so it should be no big deal to do this correctly.

	Paul

> An ideal thing would be to make the dialog autonomous like the 
> transaction, and let it mind its own business irrespective of the usage, 
> though it may be too much now to ask for.
> 
> -Kannan
>

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 23 Nov 2005 17:21:39 +0100

I am in favour of A here for 2 reasons:

- I have implemented it that way.
- SIP stacks in general stop at the dialog layer. Any applications 
using that stack can be easily be modified, but modifying the stack 
itself will be difficult, especially if you dont have control over the 
stack you are using.

Thanks,
Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Nov 2005 13:22:34 -0500

> - I have implemented it that way.

:-) Well, that must settle it!

> - SIP stacks in general stop at the dialog layer.

That is quite a sweeping generalization. Do you have data to confirm 
that? I know of at least one that explicitly supports dialog usages.

> Any applications using 
> that stack can be easily be modified, but modifying the stack itself 
> will be difficult, especially if you dont have control over the stack 
> you are using.

The problem remains. A request arrives at the stack. There is indeed a 
dialog for it, so the stack is happy and passes the request to the 
application. The application can find no dialog usage for this request, 
but has other dialog usages for the same dialog. You want it to destroy 
all the dialog usages in this case?

	Paul