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

From: "Stastny Richard" <[email-masked]>
Date: Fri, 22 Aug 2003 22:53:25 +0200

We should not confuse sip: URIs with tel: URIs (as Henning said, in 2806bis mode).
 
I disagree with Cullen that dial strings exist only at the user
interface of the UA, they exist between the UA and the server interpreting
the sip URI also.
 
First, a user on an UA like an IP phone or ATA may be able to enter
a fullsip: URI by breaking his fingers, normally is is entering a number 
like 55555 and the IP phone is translating it to [email-masked],
or he is entering something like 139355555 or **7476691291, which
is not translated to a tel: URI, because the IP phone does not know
the dialing plan in use by the server, it is submitted as [email-masked].
A IP phone is also not able to decide if a sip: URI or a Tel:URI should be used, only the
server can do this ( a IP phone may even be attached to more then one server at a time)
 
But, we do not need user=phone, because again the IP phone has no idea whats going on.
it is the server which first may check if this thing is a user or an alias, and if not, if 
it is something fitting in his dialing plan. This is done simply from left to right, looking
at the characters. If the server is able to interpret this, it may normalize this to something
meaningfull (e.g. [email-masked] is translated to [email-masked]),
 
**74666912891 may even be translated one day to tel:+17476691291 or
sip:[email-masked] ;-)
 
If the server cannot parse this it tells the user unknown number or whatever.
 
I do not really know where the problem is, but I also agree that ;user=phone is
useless.
 
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Cullen Jennings [mailto:[email-masked]] 
	Gesendet: Fr 22.08.2003 22:09 
	An: Robert Sparks; [email-masked] 
	Cc: 
	Betreff: Re: [Sip] SIPIT Interop problem with ;user=phone

	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

	On 8/22/03 7:10, "Robert Sparks" <[email-masked]> wrote:
	
	> 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
	>

	_______________________________________________
	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

����X��X��m����5��_��?�������+-�w��ȩN��+-����u�ޖ�fz{h~�^r��H�Ϯ�hr�T��"�)��鞞�+���[�n&�v�讫��ب��'r��z{l��,zȩ�)���_������ׯzZ)������橦X�jب���

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 23 Aug 2003 11:20:34 +0100

Hi Folks,
   OK, we have votes for and against ';user=phone', as well as votes 
for Robert's
original clarification on the use of ';user=phone'.

Christer points out that telephone-subscriber syntax may have a 
"gotcha" in that
visual separators may be changed. IMHO the answer to that one is "Don't do it".
With that rule, will deprecating the parameter make any difference? 
Compuserve is
no longer an issue, so unless we introduce confusion in new systems, 
it's redundant.

However, now we drift away from syntax (the original reason we had 
';user=phone')
and towards interpretation. As Richard points out, most existing hard 
phones are
a pain in the fingers to triple tap out a textual sip: URI, hence we 
tend to use
numerical userparts. These are sent over the wire as sip: URIs, however, not as
tel: URIs. They are valid SIP identities, and are processed in the 
"standard" way.
They just happen to consist of numbers.

Now...if the UAC is going to send out a tel: URI, then this is different.
As Henning points out, a tel: URI is more akin to a URN, and it does not have a
deterministic session and IP protocol. A recipient UAS might interpret this
as specifying that the UAC wants a breakout to the GSTN, or equally 
that they are
just using this syntax for "a system that uses E.164 numbers 
natively", and really
wanted the SIP protocol to be used for transactions (hey, it's inside a SIP
message after all). However... interpretation is internal to the recipient, so
it seems to me that it's not part of the protocol over the wire, but is instead
part of a device specification => not this WG's problem.

Personally, I'd dearly love a specification stating that '00' as the first
characters of a destination string should be converted into a '+' as that's
what my body memory assumes, but that's NOT a protocol issue, IMHO. It's only
a matter of interpretation within an end system.

Q: Whether or not a SIP UAS can process a received sip: or tel: URI without
rejecting the URI type; isn't this (at most) a SIPPING issue, and only exists
at all due to the ambiguity of the protocol associated (or not) with the tel:
URI?
Seems to me it's not a problem for the SIP WG, in the same way that
interpretation of number plans or the intent of a numerical userpart is
not a problem. Am I missing something?

all the best,
   Lawrence

At 10:53 pm +0200 22/8/03, Stastny Richard wrote:
>In response to Cullen's earlier:

-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.