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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Sep 2003 08:35:27 -0400

>  > > It used to be that you could do the same in a tel uri, but we
>  > > "fixed" that.
>  >
>  > ...meaning that, if we were to do nothing but rev 3261 with
>  > updated references, using bare, unscoped digit strings with
>  > "user=phone" would automatically become deprecated.
> 
> How did we break it? Even in 2806 a uri like <tel:1234> was 
> illegal - it 
> required a phone-context parameter.
We "broke" it by explicitly declaring in 2806bis that the number
could NOT be a dial string.  You would always have a context with
a dial string, the dial string passers were never unhappy requiring
a context in a tel uri.

> 
> AFAIK, the wording in 2543 and all its successors has always 
> suggested 
> that IF you transform from tel to sip you should add user=phone. But 
> they have never stated the converse - that if you have a uri of form 
> <sip:[email-masked];user=phone> then the nnn should conform to 2806.
I've never understood that user=phone was intended for tel to sip uri
conversion.  It was always supposed to be the differentiator between
a numeric username and a phone number or dial string.

> 
> As a result, normal dial strings have been representable as sip uris 
> *without* user=phone.
Well, I agree that they can be representable, but then if you don't
mark the uri as a dial string you re-introduce the problem of confusing 
a dial string with a user name, and your expansion below, pointing out 
that dial strings are not necessarily numeric makes this a worse problem.

> 
> Meanwhile, on this discussion as a whole, I think the real problem is 
> when the UAC has a dial string and doesn't know the dial plan itself. 
> The suggestion seems to be to patch it into a sip url and let 
> some proxy 
> fix it. For instance, maybe I dial 1234, and my UAC turns this into
> 
> 	INVITE sip:[email-masked]
> 	To: sip:[email-masked]
> 	...
I'm not sure why you would use the word "patch", but yes, lots and lots
of phones do this, and are going to do this.

> 
> Then maybe myproxy turns this into:
> 
> 	INVITE: sip:[email-masked];user=phone
> 	To: sip:[email-masked]
Well, I'm arguing that this is wrong, or at least we need to be
able to differentiate between a phone number and a dial string,
which user=phone COULD be used for (although I'm not sure that's
the best answer).  

I would really prefer that this example be wrong.
If the proxy knows how to expand a dial string to a phone number,
but does not understand how to route phone numbers, then it would
convert the dial string to a tel uri, and route that.  Presumably,
a downstream proxy would understand how to turn the tel uri into
a routable sip uri, perhaps by an enum dip.

If the proxy knew how to convert a phone number to a routable uri,
then it would do so, and it would NOT have a user=phone on the uri.
I would argue that it would be preferable to mark such a uri that
it was indeed a translated phone number, so that no more processing
was done by any further downstream proxies.

> 
> and maybe that becomes:
> 
> 	INVITE: sip:[email-masked]
> 	To: sip:[email-masked]
This would be the result of converting a phone number to a routable
sip uri, by enum for example, as above.

> 
> So things have worked - the call got where it should go.
> 
> BUT, sometimes the UAS might care where the call was originally 
> addressed. For instance it might want to recognize when it 
> has received 
> redirected calls (calls not addressed "To" it) and do the 
> alerting in a 
> different manner.
> 
> Trouble is, done this way the To address is meaningless to 
> anyone except 
> the caller. Unless you know the dialplan of the caller it is 
> just junk. 
> Worse, it might even disclose information about you that you 
> might not 
> want disclosed - like whether you have a speed dial number 
> defined for 
> this number.
> 
> The obvious solution to this is for the dial plan to be 
> implemented in 
> the UAC. Then the result of expanding the number via the 
> dialplan can be 
> included in both the To and request uris.
I agree that it is a good solution, and I want it to be possible
to have this occur.  The result would be a tel uri, unless you
want the phone to do the enum dip.

> 
> If the UAC is too feeble to do that, then ideally the UAC 
> would have its 
> local proxy do the expansion and then use that in both the To and 
> request URIs. Having the proxy return the translation in a 
> 3xx is almost 
> the right thing. There are two issues with that:
> 
> - how does proxy know to return 3xx rather than proxy?
>    This is solvable via Request-Disposition from callerprefs.
> 
> - how does the UAC know to replace both the request uri AND 
> the To uri?
>    This is a problem - normally on a 3xx the To should not be changed.
>    Maybe a solution would be to define a new 3xx code that means
>    exactly this.
Seems like a good idea

> 
> Regarding usefulness of user=phone:
> 
> I agree it is largely a matter of whether you think there can be a 
> conflict between "regular" usernames and telephone numbers or 
> dial strings.
Yes, I think all three are different, and need to be disambiguated

> 
> This doesn't seem to be too much of a problem with 2806 conformant 
> numbers, because they either start with + or contain 
> ";phone-context". 
Anything with a tel uri is a phone number, by definition.

> But it could be a problem for arbitrary dial strings. Remember that 
> phone numbers (and presumably dial strings) are permitted to contain 
> more than just digits. They can contain ".-()*#ABCDpw". So 
> things like 
> "BAD", "A-DABA" or "A.B.C.D" might be valid dial strings. I am not 
> comfortable saying that nothing that might be a valid dial 
> string can be 
>   assigned as a valid username.
It's more complicated than that, because when you are finished translating
a phone number into a routable uri, you may very well have a numeric
username.  For example, you may translate to a string that is the
set of digits to be dialed by a gateway such a string is not a dial string,
it is not a phone number, and is not a "username", although it functionally
works like a username.

> 
> The best solution to me is for the UAC to be configured to 
> always turn 
> dial strings into some kind of valid telephone-subscriber 
> string. If it 
> can't turn it into a global-phone-number, then it should turn 
> it into a 
> local-phone-number, using some configured phone-context. When 
> there is 
> no better solution, it can simply paste a phone-context onto 
> the end of 
> the dial string.
You can't send such a thing in a tel uri.  You can send it in
a username part of a sip uri, but I think it should be marked
as a dial string

> 
> Once this is done, it must turn this into a URL. It can make 
> a tel: url 
> trivially. Or it can make a sip or sips url with user=phone 
> by supplying 
> a configured domain name. Of these, I prefer tel, because using sip 
> doesn't seem to add anything and it further constrains where and how 
> transformations can be made. (Phone-context in a tel can be 
> translated 
> by anybody that understands it, but in a sip url can only be 
> translated 
> by a server that is responsible for the domain.)
No, the wording of 2806 bis explicitly forbids the number to be
a dial string.  It has to be a phone number (in the context).

> 
> Proxies that want to can still handle dial strings in sip 
> urls without 
> user=phone for backward compatibility with old phones. But as long as 
> they do there will be the possibility of conflict with 
> usernames. They 
> could always limit this problem by restricting the kinds of 
> dial strings 
> they will accept.
We need to more positively disambiguate the circumstances.

Brian 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Sep 2003 10:15:04 -0400

> a dial string, the dial string passers were never unhappy requiring

I'm afraid I don't find the added prohibition you do.

I agree that the body of the tel url can't *be* a dial string, but I see 
no prohibition against it *containing* a dial string.

It is all a matter of context. I think of the numbers I dial as phone 
numbers within the particular context my service provider provides. So I 
certainly don't see anything wrong with

	tel:1234;phone-context=mycontext.acme.com
	tel:911;phone-context=mycontext.acme.com
or even
	tel:*69;phone-context=mycontext.acme.com

Certainly these are valid according to the syntax of 2806bis. And they 
should be valid according to the semantics as well as long as the 
context is appropriately defined.

> conversion. 

Well, maybe not. But clearly a lot of people do, including me. Section 
19.1.6 of 3261 is pretty clear:

    When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the
    entire telephone-subscriber portion of the tel URL, including any
    parameters, is placed into the userinfo part of the SIP or SIPS URI.

    Thus, tel:+358-555-1234567;postd=pp22 becomes

       sip:+358-555-1234567;postd=[email-masked];user=phone
    ...

 > It was always supposed to be the differentiator between

A little more than that.

Section 19.1.1 includes the following:

          The set of valid telephone-subscriber strings is a subset of
          valid user strings.  The user URI parameter exists to
          distinguish telephone numbers from user names that happen to
          look like telephone numbers.  If the user string contains a
          telephone number formatted as a telephone-subscriber, the user
          parameter value "phone" SHOULD be present.  Even without this
          parameter, recipients of SIP and SIPS URIs MAY interpret the
          pre-@ part as a telephone number if local restrictions on the
          name space for user name allow it.

This clearly says that strings conforming to telephone-subscriber in 
2806 can be used as the userpart of a sip url and SHOULD be 
disambiguated from user names by including user=phone.

If a dial string can be encoded as a telephone-subscriber then this applies.

> that dial strings are not necessarily numeric makes this a worse problem.

I agree with you that it is generally a bad idea to form a sip url from 
a dial string without including user=phone.

> of phones do this, and are going to do this.

Didn't mean anything special by patch. Use "insert" if you prefer.

> which user=phone COULD be used for (although I'm not sure that's

I agree that it should be possible to disambiguate between a dial string 
and a phone number.

In the example above this is possible because the dial string was in a 
sip url without user=phone, and the phone number was in a sip url with 
user=phone.

But that still has the problem of ambiguity between dial string and 
username in the sip url.

My solution to that is for both dial strings and phone numbers to be 
represented as 2806 telephone-subscribers. (In either tel urls or sip 
urls with user=phone.) These can be disambiguated from one another by 
using different forms of telephone-subscriber, in a variety of ways:

- dial strings should always have a phone-context. In really dumb phones
   this can be a single statically configured value. In smarter phones
   there might be partial dial plans in the phone that yield different
   contexts.

- the proxy that understands and translates the dial plan context
   could always general global numbers with no context, which would
   certainly disambiguate them. Or it could generate local urls
   with a different context. Or the translation could be stable,
   with the output of translation being itself a valid dial string.
   All of these approaches are workable.

> a routable sip uri, perhaps by an enum dip.

In general I think this is a good approach. But I think there is 
flexibility in permitting the sip;user=phone representation as well.

For instance, one proxy may want to insert a domain so that the call can 
be routed (perhaps multiple hops) according to that domain, and then at 
the end reach a device (e.g. gateway) that needs the 
telephone-subscriber representation.

> was done by any further downstream proxies.

I don't see that routable uri and telephone-subscriber representation of 
the userpart are mutually exclusive.

> want the phone to do the enum dip.

I agree that in general this would be a tel: uri. But conversion to a 
sip uri containing the telephone-subscriber part, some domain name, and 
user=phone *could* be done by the phone or some downstream proxy. This 
would have to be a matter of local configuration, and assumes a 
relationship between the device doing the conversion and the domain of 
the resulting url.

I find lots of people wanting to do this. One argument is to limit the 
set of devices that must understand how to deal with tel: uris. While I 
personally don't see a lot of benefit to this I don't see it as a battle 
worth fighting.

>>   Maybe a solution would be to define a new 3xx code that means

Lets see what others think. I believe there is a real problem that this 
fixes.

> Yes, I think all three are different, and need to be disambiguated

As stated above, I think they can all be disambiguated:

- regular usernames use sip or sips urls without user=phone
- both telephone numbers and dial strings use either tel urls
   or sip/sips urls with user=phone
- dial strings always have a phone-context, with the particular
   phone context having semantics that specify how to expand the
   dial string into a phone number.
- phone numbers are either global or else have a phone context
   with appropriate semantics for identification of the intended device.

This requires knowledge of the context to distinguish between a phone 
number and a dial string, but that isn't a problem to me.

> a username part of a sip uri, but I think it should be marked

Why can't I do this as a tel url, or as a sip url with user=phone?

> a dial string.  It has to be a phone number (in the context).

I'm not asking it to *be* a dial string, only to contain one. Where do 
you see this forbidden?

	Paul