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

From: Gordon Ledgard <[email-masked]>
Date: Fri, 22 Aug 2003 13:56:06 -0400

I'm rather inclined to agree with Dean. 

I think the parameter amounts to a cheap trick for the sake of
fixing what amounts to an archaic database problem... Is the user in some
IP network domain, or does this call need to be forwarded to some
phone network gateway? And as he points out, it does so poorly.

Gordon

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, August 22, 2003 12:45 PM
To: 'Robert Sparks'; [email-masked]
Subject: RE: [Sip] SIPIT Interop problem with ;user=phone

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

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

_______________________________________________
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 22 Aug 2003 14:16:10 -0400

The original idea was to deal with the (rare) problem that a number 
could be both a local user name and a telephone number, to be handed to 
a gateway. Since the demise of CompuServe addresses, all-numeric user 
identifiers have become rare, so this original motivation seems to have 
faded.

However, we should not look at 2806 too closely. 2806 has a fundamental 
flaw in that it confuses dial strings and telephone numbers as 
identifiers. 2806bis is supposed to clean this up; it only supports 
telephone numbers as identifiers.

Any user string is subject to the interpretation of the domain 
identified by the part after the @, so it is unclear that marking it as 
a phone number (or dial string) helps much, except for the unlikely case 
mentioned above.

Therefore, I suggest that there are two possibilities:

(libertarian) The ;user=phone is treated as a noise word and has no 
semantic significance. It is strictly up to the proxy or other recipient 
of a request to route certain user name strings to certain places, be 
those named users or gateways. Anything from dial strings to 2806bis 
numbers are fine and not subject to standardization, but rather only 
local convention. This does not allow including dialing vanity phone 
numbers, for example, but I doubt we want to encourage

sip:[email-masked]

(conservative) The ;user=X is used to proscribe the syntax and meaning 
of the user part, with three possibilities: a single registered user (no 
  parameter), a dial string (would need a new designation and reference 
to a standard, e.g., draft-allocchio-gstn-05.txt now in the RFC editor 
queue) or a 2806bis string. The recipient can do a syntax check and 
reject 2806bis user parts that look fishy.

Since a recipient can tell, by looking at the user part, whether this is 
a dial string or a global telephone number (global number starts with +) 
and by looking at the ;phone-context whether it is a local phone number 
(has one) or a dial string (no +, no phone-context), it is unclear that 
the user designation adds much value.

Henning