'Re: [Sip-implementors] Any RFC reference for "user=phone" in case of an Anonymous From header'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] Any RFC reference for "user=phone" in case of an Anonymous From header
From:       Paul Kyzivat <pkyzivat () alum ! mit ! edu>
Date:       2013-02-04 19:03:07
Message-ID: 511005EB.2030403 () alum ! mit ! edu
[Download RAW message or body]

On 2/4/13 1:13 PM, Vivek Singla wrote:
> Thanks Brett and Paul, appreciate your comments on this.
> 
> So if we leave it to the domain, what happens when there has to be interoperability \
> between 2 different domains.
> Domain A says to interpret user=phone, strictly only for the numeric numbers in \
> user part of URI. Domain B says its ok to include user=phone in case of a \
> non-numeric user part. 
> B sends A an Invite, like in my example with user=phone and with "Anonymous" or \
> with "JohnDoe".

To clarify, are you talking about a case like the following where the 
questionable use is in the From header?

INVITE sip:usera@A.com
From: <sip:anonymous@B.com;user=phone>;tag=123
To: <sip:usera@A.com>;tag=456
Contact: <sip:something@B.com>

Or is it in the contact header too, where that might be the objection:

INVITE sip:usera@A.com
From: <sip:anonymous@B.com;user=phone>;tag=123
To: <sip:usera@A.com>;tag=456
Contact: <sip:anonymous@B.com;user=phone>

I only ask to psych out the thinking behind the objection.
In either of these cases, IMO domain A has no business objecting to how 
B forms *its* URIs.

*Conceivably* domain A might be trying to look up the From header in 
some authorization database of authorized callers. But in that case, if 
it doesn't like this, it should at worst decide the caller is not 
authorized.

Another possibility is that Domain A is trying to decide how to render 
the caller id, and wants to format it nicely as a phone number (with 
familiar punctuation, etc.) if it is a phone number. If so, this is a 
harsh response.

This is a gray area. The specs aren't explicit enough to definitively 
rule either A or B as in the wrong.

If the goal is to maximize interop, then that is achieved by following 
Postel's law, so both sides should change - A should be more tolerant, 
and B should stop using user=phone in this questionable case. Either one 
of those changes would permit interop.

In practice, the party who has the least negotiating power, or the one 
that has the most easily changed implementation, will be the one to change.

	Thanks,
	Paul


> Vivek.
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> To: sip-implementors@lists.cs.columbia.edu
> Cc:
> Sent: Sunday, February 3, 2013 1:40 PM
> Subject: Re: [Sip-implementors] Any RFC reference for "user=phone" in case of an \
> Anonymous From header 
> 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 <brett@broadsoft.com>
> > > To: Vivek Singla <vivsingla@yahoo.com>; "Sip-
> > > implementors@lists.cs.columbia.edu" <Sip-
> > > implementors@lists.cs.columbia.edu>
> > > 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
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> > 
> 
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
> 

_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic