Elwell, John wrote:
[snip]
>>> And is:
>>> sip:[EMAIL PROTECTED];user=phone;gr=abd76gd6
>>> an alias for:
>>> sip:[EMAIL PROTECTED];user=phone;gr=abd76gd6 ?
>>> Possibly, assuming by routing the first one to provider.net it
>>> eventually gets changed to the latter and routed accordingly.
>>>
>>> You might ask whether these are valid examples. I believe they are,
>>> because the GRUU draft says just add a gr parameter to the
>> AoR, and I
>>> believe the user=phone parameter is part of the AoR in this case.
>> IMO it is a little fuzzy whether URI parameters are actually
>> part of an
>> AOR. When adding or looking up a URI in a location service,
>> it is first
>> canonicalized by removing all URI parameters, including the "user"
>> parameter. As a result, both
>>
>> sip:[EMAIL PROTECTED];user=phone
>> sip:[EMAIL PROTECTED]
>>
>> will route to the same place.
> [JRE] Really? I always thought the purpose of the user=phone parameter
> was to distinguish telephone number URIs from other URIs that happen to
> look like phone numbers. With the assertion you make above, the
> user=phone parameter would serve no purpose.
At one point I thought that too - that the user= parameter defined
alternative namespaces for the user part of the uri, within the same
domain. But then the relevant portions of 3261 were pointed out to me,
which contradicted that idea:
3261 Section 10.3:
5. The registrar extracts the address-of-record from the To header
field of the request. If the address-of-record is not valid
for the domain in the Request-URI, the registrar MUST send a
404 (Not Found) response and skip the remaining steps. The URI
MUST then be converted to a canonical form. To do that, all
URI parameters MUST be removed (including the user-param), and
any escaped characters MUST be converted to their unescaped
form. The result serves as an index into the list of bindings.
3261 Section 16.5
... When accessing the
location service constructed by a registrar, the Request-URI MUST
first be canonicalized as described in Section 10.3 before being used
as an index. The output of these mechanisms is used to construct the
target set.
The end result is that the user= parameter really has no significance.
Section 19.1.1 says:
The set of valid telephone-subscriber strings is a subset of
valid user strings. The user URI parameter exists to
distinguish telephone numbers from user names that happen to
look like telephone numbers. If the user string contains a
telephone number formatted as a telephone-subscriber, the user
parameter value "phone" SHOULD be present. Even without this
parameter, recipients of SIP and SIPS URIs MAY interpret the
pre-@ part as a telephone number if local restrictions on the
name space for user name allow it.
Based on the above, its not that a given domain can have the same string
represent a telephone number *and* something else. It can only do one or
the other for any given string. The parameter is only an informative
qualifier regarding which it is. But I don't know who it is supposed to
be informing. The servers running within the domain presumably already
know this.
Section 16.5 (Re proxies) says:
If the domain of the Request-URI indicates a domain this element is
not responsible for, the Request-URI MUST be placed into the target
set as the only target, and the element MUST proceed to the task of
Request Forwarding (Section 16.6).
There are many circumstances in which a proxy might receive a
request for a domain it is not responsible for. A firewall proxy
handling outgoing calls (the way HTTP proxies handle outgoing
requests) is an example of where this is likely to occur.
Section 16.6 then gives the steps for request forwarding. In this case
these don't change the R-URI since the target is the same as the old
R-URI. The only way the parameters or the user portion of the R-URI can
enter in here is in adding extra headers to the request, notably
including Route headers. So the fact that this includes what seems to be
a phone number could result in a Route header whose value depends on
that phone number. But that just results in visiting added intermediate
stops, not what the final destination is.
So, the only remaining way for this parameter to influence anything is
in a UAS.
Section 8.2.2.1 says:
However, the Request-URI identifies the UAS that is to process the
request. If the Request-URI uses a scheme not supported by the UAS,
it SHOULD reject the request with a 416 (Unsupported URI Scheme)
response. If the Request-URI does not identify an address that the
UAS is willing to accept requests for, it SHOULD reject the request
with a 404 (Not Found) response.
Apparently the UAS only must be *willing* to process the URI - there is
no requirement that it *be responsible* for the domain of the R-URI. IMO
that is a mistake, but it seems to be the normative justification for SBCs.
So, a UAS that is willing may receive a request for any old domain. And
then I guess it is free to use the user= parameter to decide that the
user part of the URI is in tel format, and it then may decide to
generate a *different* request to some other destination that it thinks
is responsible for the phone number, and link the two requests.
So apparently that is the value of the user parameter.
Paul
>> Its not entirely clear to me
>> whether the
>> gruu is to be constructed with the canonicalized URI or the original
>> one. But there seems to be nothing to prevent you from
>> registering once
>> using user=phone, and another time omitting it, or using user=ip. And
>> you would get the same location service entry in both cases.
> [JRE] That wasn't really the point I was getting at. My concern is that
> if user=phone can be part of a GRUU, and if SBCs see this in a
> Request-URI and think "oh, it's a telephone number", they might convert
> it to a tel URI, or change the domain part in the SIP URI and somehow
> contrive to drop the gr parameter. In such cases the GRUU will be
> corrupted and will not work.
>
>
>>
>>> Of course, you wouldn't have a GRUU in a From header field,
>> so this is
>>> perhaps not relevant to the RFC 4474 discussion (hence the change of
>>> thread name), but it is germane to the issue of how a
>> Request URI can
>>> change as it is routed through intermediaries.
>> I think the bottom line is that we can't just toss out the
>> term "alias"
>> as something that is well defined. I think that A can be an
>> alias for B
>> for one purpose, but not be an alias for B for some other purpose.
>>
>> In this discussion, I think two From-URIs might sometimes be
>> considered
>> aliases of one another if they result in the same callerid display to
>> the recipient, or if calls to both reach the same destination.
> [JRE] That might be so, but in the Request-URI it seems to be much more
> of a concern. Can anyone shed any light on what SBCs might do if a
> Request URI contains both user=phone and gr=xxxx parameters? Hadriel?
>
> John
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
