Subject: RE: [Sipping] Re: Comment on GRUU requirements

From: Adam Roach <[email-masked]>
Date: Wed, 13 Aug 2003 12:55:47 -0500

Rohan Mahy [mailto:[email-masked]] writes:

> Most of the SIP phones I see at SIPit support 
> completing a transfer using a REFER with a
> Replaces header embedded in the Refer-To. 
> The Refer-To URI is always set to the Contact
> URI of the appropriate UA.

And this will continue to work as well as it does today.
Newer, GRUU aware clients will simply exhibit an additional
robustness.

It seems a bit misguided to do things in a suboptimal way
just to try to fix currently deployed clients.

/a

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Wed, 13 Aug 2003 14:45:41 -0700

and Jonathan wrote:
>>> I don't think we have so much of either of these deployed that this 
>>> cannot change.
>> I disagree.  Most of the SIP phones I see at SIPit support completing 
>> a transfer using a REFER with a Replaces header embedded in the 
>> Refer-To.  The Refer-To URI is always set to the Contact URI of the 
>> appropriate UA.
>
> Well, we have here the standard problem here of having implementations 
> of long-running drafts, and then deciding down the road that something 
> needs to change.
>
> I think we want a non-GRUU in the Contact header (to avoid spirals 
> through proxies, and needless load when the proxy doesnt intend to 
> record-route), but we want a GRUU for attended-transfer. I would 
> propose to use a separate header to identify GRUUs. Existing phones 
> will work as they currently do, and when two phones both support GRUU, 
> you get more reliable service. I recognize that putting the GRUU in 
> the contact would mean only one of the phones needs to support it 
> (clearly better), but the cost of this is a long-term situation that 
> we don't want.
>
> -Jonathan R.

Hi,

I think both of you are ignoring the "generality before efficiency" 
principle.  Putting the GRUU in the Contact header always works, and in 
most deployments where it is needed (middlebox traversal), you WILL 
need to travel through the same set of proxies for nearly every request 
anyhow. With the increased deployment of TLS and SIPS we will 
increasingly have dialogs for which all or none of the requests are 
proxied.

We are talking about interop with thousands of UAs which have 
implemented Proposed Standard level RFCs (SIP and Refer) and an 
long-lived, stable I-D that has completed WGLC and was submitted to the 
IESG (Replaces)`.  We are not talking about random drafts that very few 
have implemented. To be convinced that it is worth adding a new GRUU 
header, I would at least like to see some plausible use cases that are 
common enough for us to be worrying about.  Maybe the right way to look 
at this is to put the GRUU in the Contact, UNLESS you can tell that 
your peer understands the special significance of GRUUs.

Also, where this extension is most needed, you need the right 2 out of 
3 to support the extension.  (This isn't just any two of three.  If Bob 
supports the GRUU extension, but Carol does not, Alice still cannot 
cause a transfer to occur in the appropriate direction.)

Starting with the classic Alice, Bob, and Carol actors.

Alice and Bob have an existing dialog.
Alice and Carol have an existing dialog.
Alice wants Bob to talk to Carol, and will REFER Bob to INVITE Carol 
replacing the dialog between Alice and Carol.

Carol needs a GRUU; if the GRUU is conveyed in a separate header Alice 
and Carol both need to support the GRUU extension for the Refer-To 
header to be set properly.

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Aug 2003 08:53:58 -0400

inline.

Rohan Mahy wrote:

> principle.

I don't think that is the tradeoff here. Given a clean slate, it is 
clear that a new header would be used. The argument for contact header 
is just to facilitate introduction of GRUU. Thus, its more of the 
"backwards compatible vs. right thing" kind of debate.

> Putting the GRUU in the Contact header always works, and in 
> most deployments where it is needed (middlebox traversal), you WILL need 
> to travel through the same set of proxies for nearly every request 

A few responses here. Firstly, your comments above would seem to imply 
that a UA wouldn't always put the GRUU in the Contact header - that it 
would do so only in situations where it was needed. The problem is, 
the UA can't know when its needed. It would be needed if someone else 
wants to transfer a call to it, or subscribe to its dialog package. 
Since the UA can't know that ahead of time, for it to work, we need to 
specify that all UAs should always use GRUUs all the time. If the GRUU 
is placed in the Contact header, this would mean the end of e2e sip 
signaling, PERIOD.

Even if you assume a proxy needs to be on the path, a proxy then is 
faced with an impossible decision. When it receives a request, does 
the proxy need to record route (if the downstream UA is using a GRUU) 
or not (if it isn't). It doesn't know what the downstream UA can do at 
this point. So, it can't make a correct decision. Existing proxies 
wouldn't even know about this decision. The result would be that, 
where proxies record-route and the downstream UA uses a GRUU, requests 
will spiral or take extra hops on every call. This results in 
decreased overall performance in the network and increased call setup 
times.

> have implemented.

These drafts are standardized, yes, but their usage for assisted call 
transfer (which is what we are talking about here) has clearly been 
changing and is still an I-D. Nothing in the specs you mention tells 
people to extract the Refer-To URI from the Contact header of the peer.

> To be convinced that it is worth adding a new GRUU 
> at this is to put the GRUU in the Contact, UNLESS you can tell that your 
> peer understands the special significance of GRUUs.

Hopefully my explanation above describes the problems with putting 
GRUU in contacts. Even if you knew that all of your peers supported 
Contact headers, putting one in would have the problems described above.

IMHO, the GRUU is a lot like the Reply-To URI. Its a URI that provides 
an additional means of communication in the future, outside of the 
current dialog. Just as the Reply-To URI is indicated with a header, 
so to is the GRUU indicated with a header.

> 
> Also, where this extension is most needed, you need the right 2 out of 3 
> to support the extension.  (This isn't just any two of three.  If Bob 

Yes, I agree with this. I agree its not optimal. With what I am 
proposing, things will work as well as they do today, no worse, no 
better, if Alice and Bob don't support GRUUs.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Aug 2003 12:12:47 -0400

Jonathan Rosenberg wrote:
> current dialog. Just as the Reply-To URI is indicated with a header, so 
> to is the GRUU indicated with a header.

This is an interesting analogy, and perhaps a good one.

But Reply-To suffers from underspecification - AFAIK the circumstances 
under which a UA should extract the value from a Refer-To and insert 
them in some other request are entirely unspecified. As a result, the 
Refer-To header is currently pretty much unusable.

If we are to go with a separate header for GRUUs, then we need to do a 
much better job of defining when it should be used.

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 15 Aug 2003 10:43:25 -0700

On Friday, August 15, 2003, at 05:53 AM, Jonathan Rosenberg wrote:

>>>>> I don't think we have so much of either of these deployed that 
>>>>> this cannot change.
>>>>
>>>> I disagree.  Most of the SIP phones I see at SIPit support 
>>>> completing a transfer using a REFER with a Replaces header embedded 
>>>> in the Refer-To.  The Refer-To URI is always set to the Contact URI 
>>>> of the appropriate UA.
>>>
>>>
>>> Well, we have here the standard problem here of having 
>>> implementations of long-running drafts, and then deciding down the 
>>> road that something needs to change.
>>>
>>> will work as they currently do, and when two phones both support 
>>> GRUU, you get more reliable service. I recognize that putting the 
>>> GRUU in the contact would mean only one of the phones needs to 
>>> support it (clearly better), but the cost of this is a long-term 
>>> situation that we don't want.
>>>
>>> -Jonathan R.
>> Hi,
>> Putting the GRUU in the Contact header always works, and in most 
>> deployments where it is needed (middlebox traversal), you WILL need 

AFAIK, there are two cases only.  You either a) can self-generate GRUUs 
(no server leasing) in which case you use these as your Contact 
addresses, or b) you need to lease GRUUs and put them somewhere.  
Clearly, e2e signaling still works just fine in case a).   My position 
is that e2e signaling is only rarely used in practice in case b), and 
that with TLS/SIPS that this will become even less of an option.

IMO this is just modeling the real partition that is occurring among IP 
hosts.  There are full-fledged Internet hosts which can make use of the 
e2e principle (case a) and all the other IP hosts which are stuck 
behind middleboxes with "fogged up windows" (case b).  I believe my 
comments merely reflect that (unfortunate) reality.

> decreased overall performance in the network and increased call setup 

In practice, this is not very complicated.  If the proxy needs to 
record route for application purposes then it will record route 
according to that policy (no change).  If the proxy is configured to 
record route for middlebox traversal purposes then it is trivial for it 
to check if the request-URI "host is me" before adding record route.  
This has always been a good idea, we just have an additional motivation 
for that check now.

>> long-lived, stable I-D that has completed WGLC and was submitted to 
>> the IESG (Replaces)`.  We are not talking about random drafts that 
>> very few have implemented.
>
> people to extract the Refer-To URI from the Contact header of the > peer.

This usage has not significantly changed in almost the last two years. 
(The caller preferences solution was abandoned almost immediately 
because it had much worse backward compatibility problems.) If you want 
any sort of useful distributed call control (not just transfer, but all 
the services you could build conferencing, replaces, join, and the 
dialog package) you need to have a URI that reaches the same SIP UA for 
all dialogs which are related to the target dialog. If you use the 
rigid definition of Contact as only valid in a dialog, then the Contact 
header is effectively useless (it can't stand alone without the route 
set) except where the Contact URI happens to be a GRUU of the style in 
case a).  In fact we already have a precedent (in the REGISTER method) 
that a Contact should be valid for more than one dialog.  So why don't 
we formalize this convention and state that what you place in the 
Contact header for a dialog MUST be a GRUU and how you get one is up to 
you.

>> To be convinced that it is worth adding a new GRUU header, I would at 
>> least like to see some plausible use cases that are common enough for 
>> us to be worrying about.  Maybe the right way to look at this is to 
>> put the GRUU in the Contact, UNLESS you can tell that your peer 
>> understands the special significance of GRUUs.
>

again, you haven't described a "problem" that is any different from 
best current practice. most implementations *already* use the URI from 
the Contact in the Refer-To header (and in other places outside of a 
single dialog).

> so to is the GRUU indicated with a header.

Then what is the use of having a Contact header?  By redefining the 
Contact header clearly we do not cause any harm.  Implementations which 
do not put GRUUs in Contacts will be just as broken as they are today 
but no more so, and a bunch of things will just work nicely that didn't 
before.

>> Also, where this extension is most needed, you need the right 2 out 
>> of 3 to support the extension.  (This isn't just any two of three.  
>> If Bob supports the GRUU extension, but Carol does not, Alice still 
>> cannot cause a transfer to occur in the appropriate direction.)
>> Carol needs a GRUU; if the GRUU is conveyed in a separate header 
>> Alice and Carol both need to support the GRUU extension for the 
>> Refer-To header to be set properly.
>

Right, and with what I am proposing they will sometimes work even 
better than that.

thanks,
-rohan

---

From: Sean Olson <[email-masked]>
Date: Fri, 15 Aug 2003 15:49:36 -0700 (PDT)

I have to agree with Rohan. I don't understand the
purpose of NOT placing the GRUU in the Contact: header
if possible. Whether or not this GRUU ties into a
proxy is up for debate, but in practice I believe it
will be the rule rather than the exception. Similar
(but not identical) to the fact that a registrar is
not absolutely necessary to use SIP but it sure makes
things easier in practice.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com