On Apr 10, 2008, at 6:00 PM, Paul Kyzivat wrote: > > > 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.
It MAY have no significance. If the UAS or proxy (not registrar!) node has access to telephony routing information (such as TRIP), then its policy MAY be to treat a user=phone URI differently by applying a different routing policy, e.g. by picking a route from TRIP. > > > 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. Of course, the UAS or proxy with telephony routing information MAY choose to apply such to a numeric looking request even without a user=phone. Knowing when to do telephony routing and when to do more SIP-like routing (RFC 3263, etc.) is a real challenge. We missed a bet by not making user=phone or tel: mandatory here. > > > 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. It seems to me that a routing proxy could reroute the request based on numeric interpretation, and that it might choose to do numeric interpretation based on the user=phone. > > > 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. Yep. > > > 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. If it were used consistently within an organizational topology, I maintain that it could have utility at rerouting proxies. On the other hand, I think we should have just used tel: for all these cases. It's much cleaner. -- Dean _______________________________________________ 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
