Subject: Re: [Sip] GRUU and Mid-Dialog Requests

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 10 Aug 2006 16:10:33 +0200

> subsequent (in-dialog) requests are already sent to a specific UA
> instance by virtue of the Contact header and the Record-Route for the
> dialog. 

I agree that in-dialog requests are already "sent to a specific UA by 
virtue of Contact". However, my understanding is that Record-Route headers 
are "only" required for the GRUU draft because GRUU are advertised in the 
Contact header fields, and not because of a use-case related requirement.

> The point of GRUU is to allow out-of-dialog requests to target a
> "specific instance" in the same way that in-dialog requests do. 
> No more, no less.

The point is that additional processing is needed by the current draft in 
home proxies. To remove this (not-needed?) burden, one could imagine other 
ways to advertise the GRUU (e.g. a Contact-Gruu header field) instead of 
advertising it in the Contact header field (e.g. in a 200 of INVITE). The 
remote user-agent would use this other way for initial requests (e.g. if it 
wants to send a SUBSCRIBE), without impacting the routing of mid-dialog 
requests in home proxies.

I'm sorry to bring this discussion so late, I just realize this lately.

>> Other minor comments:
>> 
>> p11: in the properties that a GRUU must exhibit, add that the host 
>> part of the URI must be equal to the host of the registrar that owns
>> the GRUU.

> I don't agree that is a requirement. It could be a different host 
> part that maps to the same IP, or a different host part that maps 
> to a different IP but the same server, or it could map to a 
> different server with access to the same location server.

Ok, agreed. However, maybe just rephrase my first proposal by indicating 
that the host part of the GRUU must be under the responsability of the 
domain that creates the GRUU. 

_______________________________________________
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, 10 Aug 2006 10:31:33 -0400

> requests in home proxies.

What you (I think) are suggesting was considered long ago. But it was 
discarded for a variety of reasons. Jonathan can probably dredge them 
out of his memory better than I can.

In any case, no matter how it is done, when a UA doesn't have an address 
of its own with the gruu property, then it will need to get one from 
some server elsewhere. That server will then have to take action every 
time that gruu is used. At best you could avoid a small amount of work 
on in-dialog requests. But chances are the home proxy would still have 
to record-route, because in-dialog requests would have to transit some 
box that has addressability to the UA.

	Paul

---

From: [email-masked]
Date: Sun, 20 Aug 2006 14:35:23 -0400

From: "Xavier Marjou" <[email-masked]>

That system has advantages, but unfortunately, it also doesn't solve
the real-world problems.

The commonest example that we've been running into with our SIP PBX
(open source: sipX, http://www.sipfoundry.org, commercial: SIPxchange,
http://www.pingtel.com) is this:

    Caller Alice in domain A establishes a dialog with Callee Bob in
    domain B.  The INVITE carries Contact: [email-masked].

    Bob's UA considers this URI, <[email-masked]>, to be the "remote
    target" of the dialog and publishes it as such in its dialog event
    package.

    Brian in domain B wishes to execute a 3rd-party call control operation
    on the dialog (e.g., "picking up" the call ringing on Bob's UA), so
    his UA subscribes to Bob's dialog event package, extracts the "remote
    target" element, and uses it to contact Alice's UA.

The problem that arises is that Brian and Alice are in different
domains, and it is crucial that <[email-masked]> -- the Contact in the
original INVITE -- be a GRUU.

If we were to create an alternative header for carrying Alice's GRUU,
we would need to modify Alice's UA (to obtain the GRUU and put it into
the Contact-GRUU header), modify Bob's UA (to extract the Contact-GRUU
header and put it into the dialog event package as a "remote GRUU"
element), and modify Brian's UA (to extract the "remote GRUU" element
from the dialog event package).

The current proposal only requires modifying Alice's UA.  Also, given
that most UA contact addresses aren't globally routable, the home
proxy for domain A is probably already record-routed into the dialog,
so the extra processing involved is only the GRUU lookup, not an extra
transmission hop.

Remember, what I am describing above is what we already see in the
field at our users'/customers' sites, not a hypothetical.

Dale