Subject: [Sipping] 480 mid usage

From: Robert Sparks <[email-masked]>
Date: Wed, 2 Feb 2005 15:01:43 -0600

I'm scrubbing the dialog usage draft for a refresh, and will likely 
post several questions to try
to close some of the open issues in it. Here's the first:

The meaning of 480 Temporarily Unavailable is pretty clear for requests
outside of a dialog. For mid-dialog requests, there's some ambiguity as 
to
what it means, particularly if there are multiple usages.

Consider an endpoint that has an invite-usage and a subscribe-usage
in the same dialog. The invite usage gets placed on hold and the peer
presses a do-not-disturb button. This endpoint issues a re-INVITE to
come off hold, and that gets rejected with a 480/Retry-After. We can 
argue
that this has some meaning for the Invite usage, but what does it mean
for the subscribe usage? Does it mean not to try to refresh the 
subscription
until the retry after passes?

I see three alternatives:

1) Restrict the semantics of 480 to the usage. A 480 to one usage (such
     as the invite-usage above) has no meaning to any other usage. All 
usages
     continue to exist.
        Downsides:
           - you may have to wait until the Retry-After
             expires to have a successful BYE transaction in an 
invite-usage.
           - not clear what to do if there is no retry-after

2) Scope the effect of the 480 to the dialog. All usages must wait for 
the
      Retry-after to pass before trying new requests.
        Downsides: same as 1) plus potentially causing subscriptions to 
not
                               be refreshable when they should be.

3) Declare that a mid-usage 480 ends the dialog and any usages, using
      the same arguments as for 404 or 410 (the RURI in this request is a
      Contact provided for the usage - such a response means this 
resource
      is not good now, so there's no point in keeping a usage against it 
around.
      It's not clear what retry-after would mean in this scenario.

The -00 draft recommended 3). No one has commented on this one, but
it has similar nature to the 481 discussion we had, so I'm thinking of 
changing
the recommendation to reflect 1).

Thoughts? Can anyone see any backwards compatibility issues with such
a clarification?

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: Wed, 02 Feb 2005 18:23:11 -0500

I prefer (1).

	Paul

Robert Sparks wrote:
> I'm scrubbing the dialog usage draft for a refresh, and will likely post 
> several questions to try
> outside of a dialog. For mid-dialog requests, there's some ambiguity as to
> come off hold, and that gets rejected with a 480/Retry-After. We can argue
> 2) Scope the effect of the 480 to the dialog. All usages must wait for the
>        Downsides: same as 1) plus potentially causing subscriptions to not
>      Contact provided for the usage - such a response means this resource

---

From: "Mike Hammer" <[email-masked]>
Date: Thu, 3 Feb 2005 10:13:39 -0500

Robert,

In the case of a Subscribe, you might want to give the recipient a little
bit of credit for some application intelligence.  If it sets a Retry-After
longer than the subscription will last, then it effectively is suggesting
that the subscription end.  With no Retry-After, the originator still has
the opportunity to keep it going.

In the case of re-INVITEs, could you consider the case of multimedia where
there may be an audio path up, but one side wants to add video.  It sends
the INVITE, but the other side has it disabled and thus says not available,
but also provides an idiot light to the user saying someone is trying to
establish video connection and you have it blocked.  In a case, like that
you want the behavior that the re-INVITE fails, but not the audio dialog.
Or, is there another 4xx code used for that?

Mike

   >-----Original Message-----
   >From: [email-masked] 
   >[mailto:[email-masked]] On Behalf Of Robert Sparks
   >Sent: Wednesday, February 02, 2005 4:02 PM
   >To: sipping WG
   >Subject: [Sipping] 480 mid usage
   >
   >I'm scrubbing the dialog usage draft for a refresh, and 
   >will likely post several questions to try to close some of 
   >the open issues in it. Here's the first:
   >
   >The meaning of 480 Temporarily Unavailable is pretty clear 
   >for requests outside of a dialog. For mid-dialog requests, 
   >there's some ambiguity as to what it means, particularly if 
   >there are multiple usages.
   >
   >Consider an endpoint that has an invite-usage and a 
   >subscribe-usage in the same dialog. The invite usage gets 
   >placed on hold and the peer presses a do-not-disturb 
   >button. This endpoint issues a re-INVITE to come off hold, 
   >and that gets rejected with a 480/Retry-After. We can argue 
   >that this has some meaning for the Invite usage, but what 
   >does it mean for the subscribe usage? Does it mean not to 
   >try to refresh the subscription until the retry after passes?
   >
   >     as the invite-usage above) has no meaning to any other 
   >usage. All usages
   >     continue to exist.
   >        Downsides:
   >             expires to have a successful BYE transaction 
   >in an invite-usage.
   >      is not good now, so there's no point in keeping a 
   >usage against it around.
   >The -00 draft recommended 3). No one has commented on this 
   >one, but it has similar nature to the 481 discussion we 
   >had, so I'm thinking of changing the recommendation to reflect 1).
   >
   >Thoughts? Can anyone see any backwards compatibility issues 
   >with such a clarification?
   >
   >RjS
   >
   >
   >
   >Use [email-masked] for questions on 
   >current sip Use [email-masked] for new developments of core SIP
   >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Feb 2005 12:39:57 -0500

> establish video connection and you have it blocked. 

I am a fan of this kind of behavior - refuse to add the media because it 
is currently disabled, but indicate to your user that the peer is 
interested in using it. It allows the involvement of the users in 
approving the addition of media without requiring revinvites that alert. 
(which cause other problems.)

> In a case, like that

The reinvite doesn't have to fail. When the offer with the video 
arrives, the reinvite can succeed, but with the video refused.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Feb 2005 21:31:12 -0600

Robert Sparks wrote:
> I'm scrubbing the dialog usage draft for a refresh, and will 
> likely post several questions to try to close some of the 
> open issues in it. Here's the first:
> 
[...]
> 1) Restrict the semantics of 480 to the usage.
> 2) Scope the effect of the 480 to the dialog. 
> 3) Declare that a mid-usage 480 ends the dialog and any usages
[...]
> Thoughts? Can anyone see any backwards compatibility issues with such

Robert:

I prefer (1).  But some more observations follow:

> 1) Restrict the semantics of 480 to the usage. A 480 to one 
> usage (such as the invite-usage above) has no meaning to any other 
> usage. All usages continue to exist.
>        Downsides:
>             expires to have a successful BYE transaction in 
>             an invite-usage.

Hobbling the BYE in this manner I don't understand.  It seems
that there are two levels of semantics: dialog usage
and within the dialog usage, method specific (I know it gets
convoluted, but bear with me and read on).

First, let me include the scenario you had in mind:

> that this has some meaning for the Invite usage, ...

In the particular scenario you outlined, it would make the
most sense if the 480 was applicable to the INVITE method
only (within the invite-usage).  Assume that the far end
hangs up while I have the D-n-D button pressed; in such
a case, when my UA receives the BYE, sending a 480 seems
incongruent.  What is the UAC going to do on getting a
480?  Not hang up?  Clearly, the far end user has hung up
so no point in maintaing dialog state and call state.  It
seems best if my UA, on getting the BYE, sends a 200 OK
and hangs up.  When I (as a user of the UA) press the
D-n-D button again, I will get a dialtone (and summarize
that the far end hung up).

So, it would seem that sending a 480 to BYE (or a CANCEL,
come to think of it) within the invite-usage makes less sense.
However, responding with a 480 to a re-INVITE makes
some sense.

>           - not clear what to do if there is no retry-after

We could specify one of two extremes, or something in between.
For the extremes, we could never send the request if there
is no Retry-after, or send it every time we get the 480 (none
of these are good, however).  Or, we could use T1*64 as the
default interval to use for re-sending the request if there
is no Retry-after.  I am partial to the T1*64 option.

Thanks,

- vijay