> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 10 April 2008 15:46 > To: Elwell, John > Cc: [EMAIL PROTECTED]; [email protected] > Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases > > > > Elwell, John wrote: > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >> Behalf Of [EMAIL PROTECTED] > >> Sent: 09 April 2008 03:31 > >> To: [email protected] > >> Subject: Re: [Sip] E.164 - who owns it > >> > >> > >> From: "Dan Wing" <[EMAIL PROTECTED]> > >> > >> If those URIs included ";user=phone", there is a transitive > >> relationship between the SIP URI and the TEL URI. Without > >> ";user=phone", I agree that no meaning is supposed to > be applied > >> to the user-part (the part to the left of the "@"). > >> > >> True. In that case, we have SIP URIs which are essentially aliases > >> for tel URIs. But in that case, any signing should be of the > >> fundamental tel URI, which then obviates the problem with > an SBC that > >> translates one alias-URI into another. > > [JRE] But what about other parameters on the right hand side. For > > example, is > > tel:+123456789 > > an alias for: > > sip:[EMAIL PROTECTED];user=phone;gr=abd76gd6 ? > > > > I don't think so. > > > > And is: > > sip:[EMAIL PROTECTED];user=phone; > > an alias for: > > sip:[EMAIL PROTECTED];user=phone;gr=abd76gd6 ? > > > > I don't think so > > > > 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.
> 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
