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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Sep 2003 10:53:56 -0400

What part of:

"Dial strings are beyond the scope of this document."

is not clear?

cf draft-ietf-iptel-rfc2806bis-02

   There are at least two ways one can envision making a telephone
   connection. In the first approach, a URI contains the dial string,
   which is then passed to an entity that can reproduce the actions
   ...

   Another approach has the URI specify the telephone number, which can
   be either globally unique or only be valid within a local context.
   ... The document below assumes the second model.  

I think it is crystal clear that a 2806bis compliant UA cannot
put a dial string in a tel uri.  That was the intention.
The folks in iptel who wrote that seemed quite clear that dial strings
were a quagmire that they didn't want to walk in, and they defined
a tel uri as not containing a dial string.

That's okay, but we need a way to pass a dial string, and know
it's a dial string, in a sip uri.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2003 10:15 AM
> To: Rosen, Brian
> Cc: Adam Roach; [email-masked]
> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> 
> Rosen, Brian wrote:
> >> > > 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.
> 
> 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.
> 
> >>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. 
> 
> 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 numeric username and a phone number or dial string.
> 
> 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.
> 
> >>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.
> 
> I agree with you that it is generally a bad idea to form a 
> sip url from 
> a dial string without including user=phone.
> 
> >>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.
> 
> Didn't mean anything special by patch. Use "insert" if you prefer.
> 
> >>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 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.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> I don't see that routable uri and telephone-subscriber 
> representation of 
> the userpart are mutually exclusive.
> 
> >>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.
> 
> 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.
> 
> >>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
> 
> Lets see what others think. I believe there is a real problem 
> that this 
> fixes.
> 
> >>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
> 
> 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.
> 
> >>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
> 
> Why can't I do this as a tel url, or as a sip url with user=phone?
> 
> > 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).
> 
> I'm not asking it to *be* a dial string, only to contain one. 
> Where do 
> you see this forbidden?
> 
> 	Paul
> 
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Sep 2003 13:21:28 -0400

> "Dial strings are beyond the scope of this document."

To me, "out of scope" is different than "can't be used for". (It is akin 
to the off-label use of drugs - for purposes other than what they are 
marketed for.)

So, if I can describe a phone context in which dial strings can be 
considered to be phone numbers, then I can encode dial strings that way.

If necessary, we could write a separate draft that explicitly describes 
doing so. I don't think it is necessary - it is up to the phone to 
decide how to map dial strings into numbers. If it happens to do so by 
simply attaching a phone context to the dial string then that is its 
business.

This is just a degenerate case of the phone containing a dial plan.

> put a dial string in a tel uri. 

Can you describe to me what sorts of transformations to the dial string 
are acceptable for inclusion in a tel uri, vs those that are not?

Apparently you think the null transformation isn't acceptable. What if I 
put a "." in front of the dial string? Would that make you feel better?

 > That was the intention.

Local numbers with contexts are also a quagmire that they did walk into. 
What I am suggesting simply leverages that in what I am arguing is a 
compliant way.

> it's a dial string, in a sip uri.

What I am suggesting requires no changes, and allows those who need to 
know with a way to distinguish dial strings.

	Paul

P.S. What I am suggesting requires use of a phone-context within which a 
valid dial string has an unambiguous meaning. But this can always be 
accomplished. If need be, the UAC can use its own FQDN as the 
phone-context, so that everything including its own private speed dial 
numbers have unique definitions. So I might have something like:

	INVITE tel:*3;phone-context=myphone.acme.com
	To: tel:*3;phone-context=myphone.acme.com
	From: sip:[email-masked]
	Route: sip:proxy.acme.com;lr

This would go off to proxy.acme.com, which would apply the dial plan for 
myphone.acme.com. It would look up my private definition for *3 and 
substitute it.