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

From: "Arjun Roychowdhury" <[email-masked]>
Date: Tue, 29 Jul 2003 14:11:31 -0400

quick questions:

1. Why does the peer need to know a URI is a GRUU or not ? (stated both in 
Adam's mail below as well as REQ-8 in the draft).
If a UA that is handing out its URI wants to be globally reachable, why 
cannot it just make sure its URI is a GRUU for that dialog or 
the required scope of life ?

2. In the definition of 'instance-routing' of the draft, it states 
'when a call is made to a GRUU, the routing logic is much more static. It
has to cause the call to be delivered to a very specific UA instance.'

I am confused by the definition of 'much more static'. As of today, given 
a URI a proxy applies some routing logic. At the least,
it would simply forward it based on the incoming URI or it may decide to 
apply some 'service logic'. If it did apply a service logic,
(eg say, CPL) the outgoing URI depends on the script. So,

        2.1) Is this GRUU addition going to add another angle to how 
proxies are supposed to route ? 
        2.2) Is this GRUU additon going to force proxies not to recognize 
a 'new type' of URI for which it may need to apply special
        (maybe limited) routing logic ?

In short, my concern is what this addition does for intermediary routers 
and servers and if at all its possible to push the complexity
of all this to the endpoints making the intermediaries unaware of the type 
of the SIP uri. (GRUU or not).

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860 

Jonathan Rosenberg <[email-masked]>
Sent by: [email-masked]
07/29/2003 01:32 PM

        To:     Adam Roach <[email-masked]>
        cc:     "[email-masked]'" <[email-masked]>
        Subject:        [Sipping] Re: Comment on GRUU requirements

Two points to make here:

First, I am not sure that we actually want to place the GRUU in the 
contact header field. If we do that, we end up with double record 
routing and the elimination of end-to-end signaling once the call is 
set up. What I mean by double record-routing is this. Lets say A calls 
B. B's proxy record-routes. The INVITE gets to B. B inserts a GRUU in 
the Contact in the 200 OK. Now, when A does a re-INVITE, it goes to 
B's proxy (due to the record-route), and then AGAIN to a proxy 
(possibly a different one) because of the GRUU in the r-uri.

I think we need to think of a GRUU as an AOR, its just that its an AOR 
that routes to a specific device instance. Contact header field should 
be used as its currently used - the URI to reach this device within 
the context of this dialog.

Secondly, that said, I do agree we need to hand out GRUUs. I don't 
think its a URI parameter. I think that it would be contextual. We 
definitely need to be able to hand them out between peers in a dialog, 
in which case a new header could be used to carry them. They could 
also be embedded in web pages, in which case the context is the 
surrounding anchor text, meant for human consumption.

To facilitate further discussion, I've written up a brief requirements 
document on GRUU. I added some requrements to distribute GRUUs between 
peers in a dialog. Until it appears in the archives, you can pick it 
up at:

http://www.jdrosen.net/papers/draft-ietf-sipping-gruu-reqs-00.txt
http://www.jdrosen.net/papers/draft-ietf-sipping-gruu-reqs-00.html

Thanks,
Jonathan R.

Adam Roach wrote:

> While thinking about some of the applications for which
> GRUUs would be useful, it occurred to me that many of
> them work (or at least, work better) if a GRUU can be
> identified as such by simple examination.
> 
> For example, let's say I send an INVITE message and
> receive a 200 response containing:
> 
>   Contact: <sip:ABC.dskia99s8a77dll=[email-masked]>
> 
> If I want to be able to send an out-of-dialog request that
> I want to go to the same device that my INVITE went to,
> I don't know whether I can do so. On the other hand, if
> I can look for a URI parameter that indicates that the
> URI has GRUU properties:
> 
>   Contact: <sip:ABC.dskia99s8a77dll=[email-masked];gruu>
> 
> ...then I *know* that sending a request to it will arrive
> at the appropriate device, even if it's not in the same
> dialog.
> 
> I would like to see a requirement added along the lines
> of:
> 
>   REQ xx: It must be possible for any recipient of a URI
>   to determine by examination whether it is a GRUU.
> 
> /a
> 

-- 
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

_______________________________________________
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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2003 12:22:20 -0400

inline.

> the required scope of life ?

I think Adam has addressed this, but let me give my take.

When a peer wants to send a request to a UA out of a dialog, it needs 
to know what URI to use. Does it use the Contact header from the peer? 
  To/From? Well, it should use the GRUU wherever it gets put, and if 
there is not a gruu, it needs to use one of the tricks that Alan has 
documented in his transfer draft. So, the processing at the peer needs 
to make a decision on the approach based on whether it has a GRUU or 
not, and thus it needs to know.

> has to cause the call to be delivered to a very specific UA instance.'

Yes.

> proxies are supposed to route ? 

No. Its merely a subset of whats already possible today. You can 
already have a URI that is globally routable and routes to a specific 
next hop URI that represents a device.

>         (maybe limited) routing logic ?

No. Its just another URI. It just so happens that the services 
associated with it are not as broad as they may be with some other 
URIs. But, the services that can be attached to it are just a subset 
of a what a proxy already does.

Generally speaking, proxies need to understand what services need to 
be offered to URIs under their administratiev domain. Not all services 
can be randomly applied to all URIs. Policy and authorization will 
dicate which URIs can have which services. For example, if a user has 
not paid for call forwarding, they may not be allowed to have a call 
forwarding script/service associated with their AOR. A GRUU is no 
different. Its a URI in that domain associated with a subset of the 
overall services.

> of the SIP uri. (GRUU or not).

No, thats bad. The proxies NEED to know. That is the entire premise 
behind the leasing approach. They need to know since otherwise routing 
is unreliable. They need to know since you may WANT to have services 
associated with GRUUs (i.e., applying call blocking services to GRUUs 
as well).

-Jonathan R.