Subject: Re: [Sip] GRUU Mechanism I-D

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 16:51:23 -0500

Brett Tate wrote:
> 
> Most of the current dialog reuse issues could be 
> resolved by a new header which indicates a
> real call-id and a parameter which indicates
> that this is a request to establish a new 
> call/subscription/... on this dialog.  

I'm not clear what that helps.

> A new response is also needed to indicate that 
> I am aware of this dialog however I am not aware
> of the call/subscription/... associated with
> the request (a 481 which doesn't release the 
> dialog).

When would this be used? Perhaps if a NOTIFY was received for which no 
corresponding subscription is known? I agree that is a potential 
problem, and a suitable error code would be helpful. AFAIK that is the 
only case where such a problem can arise.

> To avoid some complexities, potentially we could
> also restrict the number of calls sharing a
> dialog to be 1 at any given time.  Or potentially
> we could add a statement that a call cannot be
> originated on an already established dialog.

As things stand there can only be one call on a dialog at a time. The 
only action that could establish a new one (an INVITE) will be 
interpretted as a reINVITE for the existing call.

In theory you could establish a dialog with an invite, share it with a 
SUBSCRIBE, terminate the first call with a BYE, and then create a new 
call (with another INVITE) sharing the dialog with the subscription.

A rational use of this capability escapes me at the moment, but once the 
mechanisms are there to support sharing at all this kind of capability 
more or less comes for free, so why worry about it?

The use of GRUUs certainly provides an alternative to sharing of dialogs 
for certain applications. I think it makes sense to just permit them to 
coexist and see how things evolve.

	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: "Brett Tate" <[email-masked]>
Date: Wed, 5 Nov 2003 19:23:09 -0500

> I'm not clear what that helps.

A and B both know about a subscription dialog.
A thinks that a call is currently active on the
dialog; B does not.  A sends a re-invite for
the call; B rings the phone since it does not
know if it was an invite or re-invite.

> When would this be used? 
> Perhaps if a NOTIFY was received for which no 
> corresponding subscription is known? I agree 
> that is a potential problem, and a suitable 
> error code would be helpful. AFAIK that is the 

A and B both know about a subscription dialog.
A thinks that a call is currently active on the
dialog; B does not.  A sends a re-invite/update 
for the call; B uses the response code to inform
that the call is not active.  A can now choose
to send an INVITE to request the re-establishment
of the call still on the subscription dialog.

> As things stand there can only be one call on 
> a dialog at a time. The only action that could 
> establish a new one (an INVITE) will be 
> In theory you could establish a dialog with 
> an invite, share it with a SUBSCRIBE, terminate the 
> first call with a BYE, and then create a new 
> A rational use of this capability escapes me

I am sure that someone will define an event
package that allows calls to be 
established/re-established 
sharing the subscription's dialog.

> at the moment, but once the mechanisms are there 
> to support sharing at all this kind of capability 

Mainly so A can distinguish a received re-invite 
from invite when A recently sent a BYE or lost
awareness of the call but not the dialog.

However I guess that it would not be that common
if UPDATE is used to refresh the Session-Expires
stuff.   And I guess a retry-after response could 
be used for an invite received in proximity of 
sending bye.

> The use of GRUUs certainly provides an alternative 
> to sharing of dialogs for certain applications. 
> I think it makes sense to just permit them to 

I agree.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Nov 2003 15:30:21 -0500

> of the call still on the subscription dialog.

OK, I see. Taking both of your comments above - your goal is to 
distinguish "call refresh" from "new call" and "subscription refresh" 
from "new subscription".

It isn't really needed for subscriptions (or for REFER) because there 
are already unique event ids that distinguish them.

But for the call there is indeed ambiguity - you can only have one call 
at a time, but in race conditions there could be confusion about whether 
an INVITE is or is not a reINVITE. I'm sure we can find some relatively 
simple way to resolve that.

> sharing the subscription's dialog.

Why does anything need to be defined in an event package for this?

AFAIK it is quite ok today to establish a dialog via a SUBSCRIBE, and 
then send an INVITE within that dialog to establish a new call.

The question is whether this is a *useful* capability.

I guess one good example of a use would be when subscribing to the 
dialog package. If you saw a call that you wanted to affect - perhaps 
join - then it makes perfect sense to send the INVITE thru the same dialog.

Of course this is also the exact use case that GRUUs render unnecessary.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 6 Nov 2003 16:44:54 -0500

> OK, I see. Taking both of your comments above - 
> your goal is to distinguish "call refresh" from 
> "new call" 

Yes.

> and "subscription refresh" from "new subscription".

Actually it is being able to reject a notify with a cause
code that reflects that I am aware of the dialog but
not the subscription.  No response code indicates known
dialog but unknown subscription/call.

> But for the call there is indeed ambiguity - 
> you can only have one call at a time, but in race 
> conditions there could be confusion about whether 
> an INVITE is or is not a reINVITE. I'm sure we 
> can find some relatively simple way to resolve that.

I agree.

> Why does anything need to be defined in an 

I was mainly indicating that nobody has yet
submitted a draft/rfc indicating such functionality.
However I am sure that somebody will start
defining call-me-back-over-this-dialog type
subscription events.

> AFAIK it is quite ok today to establish a dialog 
> via a SUBSCRIBE, and then send an INVITE within 
> that dialog to establish a new call.

Yes.  However many products would reject the invite
unless it has meaning associated with the subscription.

> I guess one good example of a use would be when 
> subscribing to the dialog package. If you saw a 
> call that you wanted to affect - perhaps 

Agreed.  

That was why I was trying to either:

1) Resolve the issues of 
   originating/re-originating a call 
   over a subscription's dialog.

2) Or mention that such functionality 
   is not approved by the working group
   because GRUU must be used instead.

I prefer option 1 since it will take time to
get the GRUU solution approved for RFC 
and widely deployed.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Nov 2003 17:11:41 -0500

> unless it has meaning associated with the subscription.

Well, you are probably right about that, though there is no particular 
reason why that ought to be the case.

While it is probably outside the scope of the IETF, it seems plausible 
to me that a request arriving within an existing dialog ought to 
accepted if the exact same request would have been accepted in a new 
dialog. In addition, there MAY be cases where a request in a dialog 
might be accepted with less restrictions if in an existing dialog than 
if received in a new one.

Clearly, if interop problems arise due to differences in authorization 
policies, then the mechanism isn't useful. In that sense using separate 
dialogs and GRUUs may be easier. But that approach will probably also 
have problems of some sort - perhaps around who can use a GRUU or what 
for, GRUU lifetime, etc.

	Paul