To further confuse this discussion...
IMO only the *owner* of a sip uri (someone responsible for the domain)
has any business interpretting the user part. I guess this could be
extended to others who are aware of the specific policies of the owner.
For all others it should be opaque. So only the owner should care
whether user=phone is present or how it should be interpreted.
In most cases it should probably be irrelevant whether user=phone is
present or not. If the domain uses both phone numbers and other
identifiers for the user part, the form of the other identifiers is
usually constrained so that they are all distinct from phone numbers.
(E.g. they must contain some non-phone-number character.)
*In principle* I suppose a domain *could* assign numeric identifiers
that are indistinguishable from phone numbers, and use the user=
parameter to distinguish them. But this seems like a really bad idea.
For one thing, 3261 requires that the location service be indexed by the
URI with any parameters removed. So you can't have separate entries in
the location service for uris that differ only by the user= parameter.
So while in principle you could treat them as separate, one one could be
registered. (The other would need to be configured.)
My bottom line here is that which specific URIs are valid for a
particular domain should be specified by the domain owner. Nobody else
should question it, within the constraints of the URI syntax.
Thanks,
Paul
On 2/3/13 10:32 AM, Brett Tate wrote:
>> Without a specific spec or a RFC, its hard to
>> tell who is right and who should change.
>
> My understanding of RFC 3261 (and RFC 2543) is that user=phone indicates that
> the user portion can be decoded as a telephone-subscriber. However, RFC 3261
> is too vague concerning the topic. It indicates to set user=phone when
> adding telephone-subscriber without explicitly indicating that it is the only
> use of user=phone.
>
> Thus some vendors interpret user=phone as though it doesn't imply that the
> user can be decoded as a telephone-subscriber. However, I disagree with this
> interpretation because it means that nothing indicates that the user portion
> can be decoded as telephone-subscriber. Since "user URI parameter exists to
> distinguish telephone numbers from user names that happen to look like
> telephone numbers", I find it strange to include user=phone to indicate that
> "anonymous" or "" are telephone numbers.
>
> RFC 3261 section 19.1.1:
>
> "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."
>
>> ----- Original Message -----
>> From: Brett Tate <[email protected]>
>> To: Vivek Singla <[email protected]>; "Sip-
>> [email protected]" <Sip-
>> [email protected]>
>> Cc:
>> Sent: Friday, February 1, 2013 12:57 PM
>> Subject: RE: [Sip-implementors] Any RFC reference for "user=phone" in
>> case of an Anonymous From header
>>
>> Unfortunately, RFC 3261 is underspecified concerning the user=phone
>> topic and sipcore doesn't seem to want to fix the issue. Thus do
>> whatever you want. :)
>>
>> The following link is to one of the replies that I received concerning
>> the topic.
>>
>> http://www.ietf.org/mail-archive/web/sipcore/current/msg01784.html
>>
>>
>> Some vendors will not like receiving a user=phone when the user portion
>> of sip-uri is missing or does not decode as a telephone-subscriber per
>> RFC 3966 (or RFC 2806).
>>
>> Anonymous examples can be found within RFC 3261, RFC 3323, and RFC
>> 3325. They do not include user=phone.
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
