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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Sep 2003 18:00:38 -0400

Adam Roach 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.

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.

As a result, normal dial strings have been representable as sip uris 
*without* 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]
	...

Then maybe myproxy turns this into:

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

and maybe that becomes:

	INVITE: sip:[email-masked]
	To: sip:[email-masked]

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.

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.

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.

This doesn't seem to be too much of a problem with 2806 conformant 
numbers, because they either start with + or contain ";phone-context". 
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.

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.

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.)

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.

	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

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 3 Sep 2003 19:55:20 -0400

> required a phone-context parameter.

RFC 2806 does not require it; section 2.5.2
lists it at SHOULD strength.

And RFC 3398 section 12 mentions the following:
"
   When the '+' sign is not present, but a 
   telephone number is represented by the user 
   portion of the URI, the SIP URI SHOULD
   contain the optional ';user=phone' parameter; e.g.,

   To: sip:[email-masked];user=phone
"

And because there are many deployments that
followed the SHOULD of RFC 3398 instead of
the SHOULD of RFC 2806, it is going to be
a pain to start interworking with devices that
intend to return a 400 response because of the 
MUST mentioned in 2806bis.

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 12 Sep 2003 11:18:16 -0700

I agree with all of Paul's comments except one inline...

On Tuesday, September 2, 2003, at 03:00 PM, Paul Kyzivat wrote:

> How did we break it? Even in 2806 a uri like <tel:1234> was illegal - 
> it required a phone-context parameter.
>
> 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
>
> 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 UAC. Then the result of expanding the number via the dialplan can 
> be included in both the To and request uris.
>
> 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:
>
> comfortable saying that nothing that might be a valid dial string can 
> be  assigned as a valid username.
>
> 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.
>
> 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.)

While I do not object to sending tel URIs to SIP proxies, I believe I 
already articulated some reasons why you might want to use sip or sips 
instead.

1) want to use SIPS
2) want to route the call to a specific domain that is not the domain 
of your first hop proxy.
3) want to invoke a loose router for services like transcoding or call 
history logging that have different tel URI handling rules than you 
want to use.

thanks,
-r

> could always limit this problem by restricting the kinds of dial 
> strings they will accept.
>
> 	Paul
>
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 16 Sep 2003 09:01:15 -0500

> already articulated some reasons why you might want to use sip or sips 

Agreed!

> history logging that have different tel URI handling rules than you 

Both 2 and 3 can be solved by pushing or preloading routes.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 16 Sep 2003 09:27:19 -0700

> Both 2 and 3 can be solved by pushing or preloading routes.

OK, I was being sloppy.  Looking at several options.

A.
	INVITE tel:+14085264000 SIP/2.0
	Route: <sip:transcoders.com;lr>

A is not so good, because you have no control over what transcoders.com 
does with tel URLs  (It might reject them, or send you a big bill).

B.

	INVITE tel:+14085264000 SIP/2.0
	Route: <sip:transcoders.com;lr>, <sip:mci.com;lr>

B would probably work, but seems much more cumbersome than C.  In 
addition, transcoders.com might forward all calls toward mci.com 
through some other domain (att.com) which might just take the tel URL 
and process it itself.

C.

	INVITE sip:[email-masked];user=phone SIP/2.0
	Route: <sip:transcoders.com;lr>

C is explicit, it works, and it contains no extra info.

thanks,
-rohan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Sep 2003 09:26:32 -0400

...
> 2) want to route the call to a specific domain that is not the domain of 
> your first hop proxy.
> history logging that have different tel URI handling rules than you want 
> to use.

I prefer tel: unless there is some compelling reason to do otherwise. 
The above may be compelling.

In those cases, I think it is probably better to form the tel: url 
first, put it in the To header, then translate to sip or sips to achieve 
intended result and put that in the request url. In effect, the phone is 
then acting as its own intelligent first hop proxy doing this translation.

Doing it that way gives the recipient the best chance of representing 
the intended address.

Of course there will be situations where other treatment is needed, so 
there is no one best answer here - just best practice.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Sep 2003 17:13:38 -0400

I think Rohan and I might be in violent agreement.

The example he gives below (c) is an excellent reason why a proxy (or 
UAC) might want to translate a tel: url into a sip url.

I would however argue that in general, and in the absence of some other 
motivation to the contrary, I would *start* with the tel: format, and at 
least put it into the To header. Then, either immediately within the 
UAC, or someplace further downstream in a proxy, this might get 
translated to a sip url, so that the routing can be more explicitly 
controlled, as in Rohan's example.

I believe the strongest argument for bypassing the tel: format from the 
beginning is security - the need to use sips.

Maybe we need tels: so we can have security without having to bind the 
semantics of the number to a particular domain. :-)

	Paul

Rohan Mahy wrote:
> addition, transcoders.com might forward all calls toward mci.com through 
> some other domain (att.com) which might just take the tel URL and 
> process it itself.
> 
> C.
>