Subject: Re: URL user parameter

From: Sean Olson <[email-masked]>
Date: Sun, 20 Jun 1999 15:09:16 -0500 (CDT)

> 
> I agree with Jonathan about the original meaning of the user=phone tag.
> I have always assumed that it really only expresses a caller preference:
> 
> My phone number happens to be 617-738-7225. This truly identifies a
> particular pair of copper wires which lead into my home. However, it is
> possible that I might wish to use this number as my SIP alias, so that
> when someone tries to "call" the number 617-738-7225, it is not my phone
> which rings, but some other device (depending on the logic installed
> in various SIP servers). How can the caller express the sentiment "Please
> invite the *phone device* 617-738-7225, not the *user alias* 617-38-7225?
> 
> The caller does this by adding the "user=phone" parameter to the URL.
> 
> As Jonathan said, there is no guarantee that this will result in a phone
> ringing, nor does this really affect interoperability. 
> 

The semantics you propose are interesting but I don't think this is the
proper solution. The user=phone tag always seemed more of a parser hint.

Assuming you are dealing with a SIP IP Phone, you might be able to address
the phone directly (or not depending on NAT, firewalls, etc.)

Otherwise, what you seem to want is to indicate something like
"user=literal", meaning that the user part of the Request-URI can not be 
re-written by any intermediate proxy/gateway. This of course could extend
beyond just your traditional black phone. 

Perhaps this could become a new "Request-dispostion:" header value 
"user-rewrite/no-user-rewrite" in the SIP Caller Preferences I-D.

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 20 Jun 1999 23:51:36 -0400

> proper solution. The user=phone tag always seemed more of a parser hint.

Right.

If you want to call a phone number, what you may actually want is to
include a phone URL in the SIP invite. Unless you know the gateway
address right off the bat, this is really the only sensible way to
address a phone. So:

INVITE tel:5551212 SIP/2.0
....

would be sent from the UA, presumably to a locally configured proxy (no
name to look up in DNS). The proxy might run GLP, and thus allow it to
determine that the next hop SIP server towards a gateway to reach this
number is gateway2.company.com. So, the proxied request looks like:

INVITE sip:[email-masked];user=phone
...

where the user=phone is a parser hint.

> "user-rewrite/no-user-rewrite" in the SIP Caller Preferences I-D.

Actually, there was once a Request-disposition token called
"do-not-forward". This isn't in the current caller preferences draft. I
think it got axed because its near impossible to tell the difference
between forwarding and a local name translation. Also, it sort of
evolved into the "proxy-feature" token, which can either be proxy or
redirect.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Scott Petrack <[email-masked]>
Date: Mon, 21 Jun 1999 08:17:02 -0400 (EDT)

> > proper solution. The user=phone tag always seemed more of a parser hint.

Well, please put a sentence into the next version of SIP to make this
clear. I know several people who are silly enough to think that 
"user=phone" means that the destination user is a phone, rather
than that the user field inside the userinfo part of the SIP-URL is a
phone number. 

More important, it's hard for me to understand why I would want to 
"hint" to the parser that it's a phone number unless I also wanted to 
"hint" that the phone refers to, uh, a phone. Somehow, I thought that's
what it means to be a phone number -- it means that it's a number that
refers to a phone. Obviously I'm missing some fine distinction here.

> where the user=phone is a parser hint.

I'm used to these fine distinctions from Talmud discussions, but not from
application protocols:

1) If the UAC sends the INVITE to sip:5551212;user=phone this would give 
the parser a hint that 5551212 is a phone number, right? Well, given this
hint, the local proxy is likely to say "hmm, what do I do to connect to 
a phone number? Guess I better find a gateway." On the other hand, if the
INVITE came to "tel:5551212", a clever proxy would say "well, he wants to
invite the telephone, but my logic says that invites to a phone are always 
sent to an rtsp voicemail recorder (or whatever). 
So I don't see much of a
difference between the trying to INVITE tel:5551212 and
sip:5551212;user=phone. In both cases the local proxy i understands via
some hint that 551212 is a phone number, and in both cases the local proxy
can choose to route the call anyway it wants.

2) When the local proxy figures out the right gateway and proxies the
INVITE to the gateway, surely the gateway doesn't need the "hint" that 
5551212 is a phone number. It's a PSTN gateway, and it was sent the number
for that purpose. So putting the "user=phone" tag in for the remote 
gateway seems not very useful.

I am uncomfortable using "tel:" sometimes and "user=phone" at other times.
What happens if there are 5 proxies along the way?
At what point does the magical SIP system providentially
change the "hint" from being "tel:" before the number to "user=phone"
after the number? Why not just say that "user=phone" is what is always
used to mean "this is a parser hint that the user field is a phone number,
and putting it there means that the sender wants the parser (and the
server behind it) to know that it's a phone number."

It's not a big deal, but it does seem like splitting hairs to me to say
"for this case you need 'user=phone' but for that case you need 'tel:'".

Scott

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Jun 1999 17:57:31 -0400

The user parameter is simply a hint. It was put there just in case some
gateway (say, Compuserve) had both a phone number and user id that
looked similar. 

To amplify what was said earlier: You may well start out with
INVITE tel:12125551212
To: tel:12125551212

(note: no gateway given, somebody else makes the decision)

and then the proxy transforms this to
INVITE sip:[email-masked]
To: tel:12125551212

whether this gateway requires the 'user' parameter is a local issue.
Generally, I don't think that deriving semantic differentiation is a
good idea, so that almost all gateways should work the same whether this
is 

INVITE sip:1...@...com;user=phone

or

INVITE sip:1...@....com

However, CompuServe may return an 'ambiguous' error if it can't tell
whether this is a phone number or a local user identifier. (After all,
phone numbers can contain commas, just like compuserve email addresses.)

Any disagreements with spelling out these rules as follows:

1) If the user-id is recognizable by the server as a phone number and
the 'user' parameter is either missing or has the value 'phone', the
server either finds a gateway and forwards or proxies the request there
or performs the gateway operation itself. (Note: Not all servers will be
able to forward calls to a PSTN gateway [but for a small fee to the
authors of the SIP spec, we will include the name of your company's
gateway as the default here].)

2) If the user-id has a 'user' parameter of 'ip', the gateway MUST NOT
attempt to interpret the user id as a phone number. (Obviously...)

3) If the 'user' element can be either a phone number of a local user
identifier and the 'user' parameter is not given, the server returns 485
(Ambiguous).

4) Servers copying the phone number from tel: URIs to the user part of
SIP URIs SHOULD add the 'user=phone' parameter to avoid ambiguity.

This is basically indicated in the current text, except in reverse, in
that the server MAY interpret a number as a phone number even it is not
labeled as such. The above basically strengthens this as a bit.

While most phone numbers can be easily recognized, you can construct
weird phone numbers (like wp5677), which look like valid Columbia email
addresses.