Subject: [Sip] SIPIT Interop problem with ;user=phone

From: Robert Sparks <[email-masked]>
Date: 22 Aug 2003 10:10:55 -0400

I've seen a few interoperability failures at SIPIT 13 revolving
around the use of ;user=phone in sip URIs.

We have some implementations assuming that the presence of ;user=phone
means that the first part of the userinfo portion of the URI MUST
be formatted as a telephone-subscriber. Asking around, I've found
that many people believe this is the case, but the spec does not
support this claim. In fact, all the specification says is
that if the userinfo portion is formatted as a telephone-subscriber
then the URI SHOULD also contain ;user=phone.

So, is this an oversight? Are we allowing URIs with ;user=phone
but a non telephone-subscriber formatted userinfo part on purpose?

Those with code making the above assumption fail to interoperate
with devices that gather an arbitrary number of digits and
just slap ;user=phone in the URI when creating a request.
For example:

<sip:[email-masked];user=phone>

They reject this as a malformed URI since 15 doesn't parse per
telephone-subscriber. Is this being too strict? Should they
try to interpret this as a "number that has meaning in their
local scope"? It certainly isn't safe to pretend the ;user=phone
wasn't there and try to interpret "15" as a username. What's
the right thing for them to do?

A companion question is should a UA arbitrarily hang ;user=phone
off a digit string it collects from its user, or should it 
transform that string into a telephone-subscriber formatted
number?

Both questions have clear answers if we explicitly add that
if ;user=phone is present in a URI then the userinfo part
MUST be formatted as a telephone-subscriber. Would anyone
object to adding this requirement?

RjS

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 22 Aug 2003 11:45:01 -0500

> A companion question is should a UA arbitrarily hang 
> ;user=phone off a digit string it collects from its user, or 
> should it 
> transform that string into a telephone-subscriber formatted number?
> 

The problem is that the syntax of telephone-subscriber doesn't actually
allow conveying all sorts of stuff that one might actually want to use a
digit strings in private dialing networks that actually talk to phones.

My suggestion is to deprecate user=phone entirely. It's a silly hack that,
as far as I can tell, just complicates implementations and URI comparison
with little actual value in return.

--
Dean

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 22 Aug 2003 13:49:04 -0400

> So, is this an oversight? Are we allowing 
> URIs with ;user=phone but a non telephone-subscriber 
> formatted userinfo part on purpose?
> 
> telephone-subscriber. Is this being too strict?

RFC 2806 has inconsistent statements concerning
local phone numbers.  Section 2.5.2 only uses
a SHOULD strength concerning adding an area-specifier
to local numbers.  However section 2.2 mentions 
that local numbers always have an area-specifier.

RFC 3398 section 12 mentions the following:
"
   When the '+' sign is not present, but a 
   telephone number is represented by the user 
   portion of the URI, the SIP URI SHOULD
   contain the optional ';user=phone' parameter; e.g.,

   To: sip:[email-masked];user=phone
"

> Should they try to interpret this as a 
> "number that has meaning in their
> local scope"?

The user=phone only indicates how to
decode the user portion of the sip-uri.
It has no furthur meaning.
 
> It certainly isn't safe to pretend 
> the ;user=phone
> wasn't there and try to interpret "15" as a 
> username. What's the right thing for them to do?

My understanding is that the
user=phone only indicates how to
decode the user portion of the sip-uri.

Assuming that we are not going to start
rejecting messages compliant with rfc3398
and reasonably compliant with rfc2806,
the right thing to do is to act based
upon policies associated with calling party
and the request-uri.  However I agree that
care should be taken to avoid having
non-E164 telephone-digit usernames for 
a hostname which also gets populated in the
request-uri host of a dialed call.

> off a digit string it collects from its user, 
> or should it transform that string into a 
> telephone-subscriber formatted number?

Many products trying to comply with
rfc3398 arbitrarily add ";user=phone".

> Both questions have clear answers if we 
> explicitly add that if ;user=phone is present 
> in a URI then the userinfo part
> MUST be formatted as a telephone-subscriber. 
> Would anyone object to adding this requirement?

It depends upon which telephone-subscriber RFC/draft 
interpretation is used.  The telephone-subscriber
definition and its SHOULDs/MUSTs significantly
changes between rfc2806 and rfc2806bis-02.

If "sip:[email-masked];user=phone"
is considered invalid, I object.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Aug 2003 13:09:54 -0700

More than one person has suggested that we should use tel URL (ala 2806bis
not 2806) for telephone numbers, local PBX numbers, 800 etc and we should
use sip for sip AORs. This clears up an incredible amount of weirdly
specified comparison issues that are poorly implemented. At first glance it
looks like it would cause lots of backwards compatibility problems but it
might be worth looking at how bad they would be. The current situation has a
lot of problems that are somewhat swept under the rug.

One comment I would like to add is that in the SIP messages that flow over
the wire, we do need both telephone number and SIP AOR. We do not need
dialed digits instructions - the user interfaces of UA might use these but
the protocol does not need them.

Cullen

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 24 Aug 2003 08:27:15 -0700

Hi Folks,

To tie Cullen's comments more concretely to the discussion, I have 
always interpreted the semantics of ;user=phone to mean that the user 
part has been converted from a tel URL but that someone wants this tel 
URL to be handled in the context of a particular SIP domain.

If a SIP UA just collects a string of digits "1234" (this is not a tel 
URL), slaps on the domain name of their proxy, and then sends these 
digits there without interpretation, then you just end up with an 
ordinary SIP URI (user=ip):

	sip:[email-masked]

however, I think it is much more useful for the UA to generate a tel 
URL here instead:

	tel:1234;phone-context=+14085551111

Note that both of these are correctly scoped.  tel:1234 is illegal, as 
should be sip:[email-masked];user=phone (IMO).

Why not deprecate ;user=phone entirely?  Aside from backwards 
compatibility, there is actually a very good reason. Since tel: URIs 
don't have a domain portion, there is no way for me to send a tel URL 
through a loose-routed service and still convey which domain I would 
like the tel URI to be handled in.

So lets say that I send this INVITE

INVITE tel:+14085268570 SIP/2.0
Route: <sip:transcoders.org;lr>
...

transcoders.org will either reject the request or send it to whatever 
PSTN gateway it feels like using.  I would like to the INVITE to go to 
a specific provider out of a list of several of these, but I do not 
want to negotiate the specific user-part naming convention with each 
one:

INVITE sip:[email-masked];user=phone SIP/2.0
Route: <sip:transcoders.org;lr>

Likewise I can use SIPS to go to a different provider:

INVITE sips:[email-masked];user=phone SIP/2.0

Continuing on in this vein, say I REFER Jiri (in Europe) to call Adam's 
cell phone (in Texas).  It would be much nicer to provide this Refer-To 
URI:

sips:[email-masked];user=phone   (a tel URL 
addressed to a particular SIP UA)

instead of:

tel:+19991234567

(since Jiri may need to discover such a gateway, or be billed for an 
International PSTN call when he has a perfectly good Internet he can 
use instead for the "expensive" part of the call).

So, I think the ;user=phone is in fact very useful (even if only as a 
standardized convention).  If it is used at all I think the user part 
MUST be a valid global-number or local-number with ;phone-context 
paramter, if user=phone is in the SIP URI.

thanks,
-rohan