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

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.

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

Reply via email to