Subject: [Sip] Propogating URI parameters end to end

From: Manjunath Bangalore <[email-masked]>
Date: Mon, 10 May 2004 14:29:30 -0700

Hi,

Consider a case where a  SIP UA initiates a request (Ex: INVITE), 
wherein the Request URI contains some user-defined URI parameters that 
are to meant to be understood by the eventual UA terminating the request 
-  Example:

INVITE [email-masked]; end_user_param=foo

How do we ensure that the user-defined URI parameter accompanying the 
Request-URI is propogated to the terminating UA?

With a read of RFC 3261, I see in Sec 16.5, that when the request lands 
on the Proxy that is responsible for the domain in the Request-URI,  one 
of the ways it can generate a target set is by doing a lookup using a 
Location Service, Ex: A SIP Registrar. Before a lookup is done, the 
Request-URI is required to be canonicalized, and during this process, 
any URI parameters are dropped when contructing an index for the lookup. 
While this canonicalization makes sense for the purpose of the location 
service lookup, before the INVITE is forwarded to the URI returned by 
the Location service, wouldn't it be right to append the original URI 
parameters to it,  in order to preserve them.

On a related note, the GRUU draft requires a Proxy in a target domain to 
pass the "grid" URI parameter(grid=foo) that is received alongside the 
Request-URI.

Unless I am missing something, are there any issues with adding a 
statement to RFC 3261, that explicitly states that any URI parameters 
present in the Request-URI must be forwarded.

Thanks,
-Manjax

_______________________________________________
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: Mon, 10 May 2004 18:10:20 -0400

Manjax,

Yes, this came up regarding the handling of GRUU. As things stand with 
3261, you can't expect the parameters to be propagated. Extra 
requirements were added to the GRUU draft to ensure that the grid 
parameter is propagated.

I suppose a change could be made to 3261 to require propagating 
parameters in general, but it isn't entirely clear that this would 
always be the right thing to do. It is also not always possible, because 
the contacts that the proxy translates to needn't be sip URIs. For other 
kinds there is no guarantee that parameters are supported at all, or if 
so that propagating sip uri parameters would be the right thing to do.

This is one of the problems I have with using a uri parameter for 
referencing uri lists in the exploder drafts.

I am inclined to leave things as they are - assuming that the parameter 
must have meaning to the owner of the address it is attached to. If the 
meaning of one or more parameters extends to propagating them to some 
derived address then fine, but that isn't a general mechanism.

	Paul

---

From: Manjunath Bangalore <[email-masked]>
Date: Mon, 10 May 2004 22:11:37 -0700

Paul,

Thanks for the response

In the light of this, would allowing use of user-defined URI parameters 
accompanying the Request-URI serve any purpose at all?

-Manjax

Paul Kyzivat wrote:

> always be the right thing to do. It is also not always possible, 
> because the contacts that the proxy translates to needn't be sip URIs. 
> For other kinds there is no guarantee that parameters are supported at 
> all, or if so that propagating sip uri parameters would be the right 
> thing to do.
>
> I am inclined to leave things as they are - assuming that the 
> parameter must have meaning to the owner of the address it is attached 
> to. If the meaning of one or more parameters extends to propagating 
> them to some derived address then fine, but that isn't a general 
> mechanism.
>
>     Paul
>
>> wherein the Request URI contains some user-defined URI parameters 
>> that are to meant to be understood by the eventual UA terminating the 
>> request -  Example:
>>
>> With a read of RFC 3261, I see in Sec 16.5, that when the request 
>> lands on the Proxy that is responsible for the domain in the 
>> Request-URI,  one of the ways it can generate a target set is by 
>> doing a lookup using a Location Service, Ex: A SIP Registrar. Before 
>> a lookup is done, the Request-URI is required to be canonicalized, 
>> and during this process, any URI parameters are dropped when 
>> contructing an index for the lookup. While this canonicalization 
>> makes sense for the purpose of the location service lookup, before 
>> the INVITE is forwarded to the URI returned by the Location service, 
>> wouldn't it be right to append the original URI parameters to it,  in 
>> order to preserve them.
>>
>> On a related note, the GRUU draft requires a Proxy in a target domain 
>> to pass the "grid" URI parameter(grid=foo) that is received alongside 
>> the Request-URI.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2004 12:08:10 -0400

> accompanying the Request-URI serve any purpose at all?

Depends on what you mean by "user defined". I presume you just mean "not 
defined by IETF" or something like that.

Such a parameter is fine for communicating something from the UAC to the 
  server responsible for the URI it is attached to. In the case of AORs 
that are managed by proxies and registrars, it is the proxy that is 
responsible for the AOR. So a parameter that is intended for consumption 
by that proxy is appropriate. The communication is between the UAC and 
the proxy, but not the UAS.

A parameter intended for consumption by an endpoint could be loaded in a 
contact address and registered to an AOR. Then, any request addressed to 
that AOR, when relayed to that particular registered contact, would 
contain the parameter that was registered. In that case it is a means of 
communication between the UAS and the proxy/registrar, but not the UAC.

It is when intending to communication info from the UAC to the UAS via a 
proxy that the uri parameter is not helpful.

	Paul