Subject: RE: [Sip] RE: wording in the dialog package on mid-dialog requests

From: "Paul D.Smith" <[email-masked]>
Date: Thu, 17 Feb 2005 14:40:13 -0000

Rohan, Paul K., David,

I believe I now understand what you are intending and I think we can close
this thread.  I do have a couple of comments below which will hopefully be
helpful in completing this thread.

I think the comments from Rohan and Paul K. (below) have clarified my
confusion.  As Paul K. points out (and I'm not too good about this myself!),
we need to be very clear on the use of "dialog" and "dialog-usage".  As I
understand it now, draft-ietf-sipping-dialog-package is about "dialog-usage"
and _not_ dialogs.  We therefore must clarify this including changing the
title of the RFC/draft so that this is explicit.

However this does raise the question of how we define a "dialog-usage". The
best document I have found thus far is "Multiple Dialog Usages in the
Session Initiation Protocol", draft-sparks-sipping-dialogusage-00.
Unfortunately this contains the following text.

   A dialog comes into existence with the creation of the first usage,
   and continues to exist until the last usage is terminated (reference
   counting).  Unfortunately, many of the usage management aspects of
   SIP, such as authentication, were originally designed with the
   implicit assumption that there was one usage per dialog.  The
   resulting mechanisms have mixed effects, some influencing the usage,
   and some influencing the entire dialog.

...and...

  401 Unauthorized ,407 Proxy Authentication Required: This request,
      not the subscription or dialog, is being challenged.  The usages
      and dialog are not terminated.

The first paragraph is clearly not consistent with the current proposal
for draft-ietf-sipping-dialog-package since it is allowing a dialog-usage
to terminated _but_ the dialog still exists to allow a challenged BYE to
be sent.

Similarly, the second paragraph contravenes the assertion that the
dialog-usage terminates on sending the BYE and has terminated _before_
the 401/407 response is received.

As I'm sure you realise, I'm happy with the definitions given in
draft-sparks-sipping-dialogusage-00 as this was the basis for my
previous comments.

However I appreciate that this is _not_ the current thinking of the WG.
Can I therefore ask that someone takes the task to clarify/change the
definition of a dialog-usage, its lifetime and states?  I believe this
MUST be done in parallel with the current work
on draft-ietf-sipping-dialog-package, otherwise this draft will continue
to be inconsistent with published definitions of dialog-usage.

One suggestion that might be useful is to consider a new state for
dialog-usage known as "terminating".  This is a half-way house between
"active" and "terminated" and has the following properties.

- Any attempt to send a dialog-usage request within that dialog-usage
  fails _except_ for the dialog-usage terminating request [1] (and in
  the same direction as the original dialog-usage terminating request).
- The dialog-usage terminating request may be resent (actually a new
  request in strict SIP terms), for example to take account of
  a challenge being received.
- Once the dialog-usage terminating request has completed (success, 481,
  408, or an application determined retry limit has been reached (for
  example the application may choose to resend a BYE once after a 486
  response), then the dialog-usage enters terminated state.

This would be consistent with existing definitions of the dialog-usage
whilst still allowing the draft-ietf-sipping-dialog-package to indicate
"this dialog-usage" is ending.

Thanks for your patience is discussing this issue.  Hopefully this thread
will be a useful reference for the future.

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

Rohan Mahy wrote:
> 
> Hi Paul,
> 
> BYE is unique in that when my UA sends a BYE, it is done with the usage. 
> If the peer challenges the BYE, my UA will of course try to 
> automatically resend the BYE with the appropriate credentials, but this 
> does not impact my view of the state of the usage.  I am done with it.  
> Nothing you can do will bring the usage back from the dead.  The 
> challenge may increase the amount of time my peer thinks the usage is 
> alive when I think it is dead, and that is perfectly fine.

I'm perfectly fine with that as long as as:
- we are talking about the *usage*, not the *dialog*
- its ok to keep trying to get that BYE through

> thanks,
> -rohan

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Feb 2005 10:19:50 -0500

Paul D,

Good summary. I pretty much agree with it. Just a couple of points inline.

	Paul K.

> title of the RFC/draft so that this is explicit.

I've been trying to get the *package name* changed for months. (Probably 
years by now.) But I have more or less given up, and would be satisfied 
if there was sufficient text in the draft explaining that what it means 
is somewhat different than what one might conclude from the terms used.

That package isn't about dialogs, and it isn't about dialog-usages in 
general either. It is about 'invite-dialog-usage'.

The same UA may have a bunch of subscriptions, both incoming and 
outgoing, that are dialog usages. But those will never be reflected in 
the content of the 'dialog' package.

>   the same direction as the original dialog-usage terminating request).

Probably need to be more lenient here. A BYE could be sent, but be 
challenged. Before a successful retry is completed, a BYE could arrive 
from the other end. I think this should be answered, and terminate the 
dialog usage.