Subject: URL user parameter

From: John Hearty <[email-masked]>
Date: Fri, 18 Jun 1999 12:11 -0500 (CDT)

Jonathan,

 In discussions with Cisco personel, we ran into some questions about
the user parameter in a URL.  We had supplied some examples using this
parameter.  They noted that going into the bakeoff they had included
it in their URLs, but most others had not, and you had told them it
should not be present, so they removed it.  Section 2 of the RFC clearly
allows user=phone for calls from pstn gateways, and only makes mention
that "... without this parameter, recipients of SIP URLs MAY interpret
the pre- @ part as a phone number if local restrictions on the name
space for user name allow it."

 Can you help me understand what recommendations may have been made
during the bakeoff regarding this issue?  I am trying to understand
if we should be asking for it to be included, and Cisco is concerned
about interoperability.  It seems to remove any possible ambiguity
about the source of the URL, and I don't understand why recommendations
may have been made to remove it.  Is this a misunderstanding?

John Hearty
MCI Worldcom

---

From: Shail Bhatnagar <[email-masked]>
Date: Fri, 18 Jun 1999 16:22:33 -0400

John, We referred to the URL in the Request-URI not the URL in the
From/To. 

Shail

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Jun 1999 00:26:30 -0400

> space for user name allow it."

The original purpose of this tag, as I recall, was to allow a server to
determine if the BNF for the user portion of the SIP URL was that of
telephone-subscriber, or just a generic token. It seemed reasonable that
a server might want to know in order to properly route the call. When
user=phone, the user portion is a phone number, formatted as
telephone-subscriber. However, a server can be configured to route in
any way, and thus it could interpret (if so configured) the user portion
of the URL as a phone number, even if this tag didn't indicate that it
was a number. 

So, for example, consider the following URL's:

sip:+1-212-555-1212:[email-masked];user=phone
sip:[email-masked]

The first has the user=phone parameter, so the server (in this case, a
gateway UAS it seems) knows to interpret the user portion of the URL
(+1-212-555-1212) according to telephone-subscriber. In the second case,
there is no user parameter. However, since the server is a gateway, its
perfectly reasonable for it to try to look up 1212 in its databases as a
phone number to determine how to treat it. 

Now, I admit I don't recall telling the Cisco folks to remove it from
the Request-URI at the bakeoff. I found no mention of the issue in the
notes we took at the bakeoff. But, it was a hectic two days and I may
have said this. There was general confusion about what parameters were
allowed in the Request-URI. At some point, I think we believed none of
them should really be permitted. I have recently become less sure about
that, and think nearly all should be permitted. 

However, the user param does seem a definite candidate for inclusion in
the Request-URI. Since its helpful for servers to make routing
decisions, and these decisions are usually based on the Request-URI and
not the To field, I believe its reasonable to allow it in the request
URI. It is certainly not mandatory to do so - i.e., if a UAC dials a
phone number, it doesn't have to be present. I don't think its absence
would affect interoperability at all, since interpretation of the user
portion is always according to local namespace, which can be configured
in any way desired.

-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: Sun, 20 Jun 1999 11:18:05 -0400 (EDT)

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. 

Here is an analogy to show how natural and useful this parameter is:

When I use the call-forward service, all calls to the number 617-738-7225
make some other phone ring. Alas, there is no way for the caller to
express the preference "please call 617-738-7225, and annul all fancy
dancy logic if possible -- just ring the *real* device addressed by that
phone number." 

This service would be very complicated to do in the PSTN, and the user
interface would be a nightmare. But more than once I wished I had such
a service.

All this note is doing is saying that the tag is useful, despite the fact
that it does not guarantee that a phone is going to ring when it is used.

Scott