Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Mar 2006 15:06:33 -0600

I guess I'll be the dissenter here...

I really do not see why we need this draft. I think it will do much more
harm than good.

It will dissuade people from implementing "real" tel uris.

I have not seen any convincing evidence that using "pauses" in dialling
is something 
SIP should do.

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 21 Mar 2006 16:59:04 -0500

It deals with reality.  Phones don't (always) do dial plan interpretation.
We have no way to know if it's been done.  The problem isn't a tel uri, the
problem is sip:nnn@domain;user=phone.  It's NOT a phone number, it's a dial
string.  The only way to implement real tel uri's is to force all phones to
do all dial plan interpretation.  That just isn't going to happen in my
lifetime I think.

I don't care about the pauses; I could lose them.  They are also reality,
however.  It's what the phone has in a speed dial to get to, for example, an
existing voicemail system.  You can say forklift upgrade to a SIP based VM,
but that's not reality.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Mar 2006 17:53:15 -0500

Brian Rosen wrote:
> string. 

I think Brian and I agree on the issues here, but I want to pick on the 
description. In the case of both a tel uri or sip:nnn@domain;user=phone, 
it is *supposed* to be a phone number. Neither of these is supposed to 
contain a dial string. The problem is that both of these are known to be 
used, improperly, to contain dial strings.

> The only way to implement real tel uri's is to force all phones to

Well, its hard for me to guess on your health issues, but I think there 
is a pretty good chance that all voip phones will do this in *my* 
lifetime. I do agree that they don't all do it today, and we probably 
need to accomodate that.

In my experience a more severe problem is cases when the dialstring 
contains both the target address *and* some special function (e.g. star 
code) that needs to be taken into account along with the target address. 
While there are many ways to deal with this if you have good dial plan 
processing in the phone, it still seems that there is often a desire to 
leave both of these things encoded in the URI. This requires a way to 
represent dial strings.

	Paul