Subject: RE: [Sipping] User=Phone/DialString and Pause and Wait

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Nov 2003 12:03:57 -0500

The problem I have with your nit is that I'm big on interoperability.
I think it's important.

Interoperability tends to suffer when you have two ways to do something
and both are optional.  In this case, I think there is so little value
in putting a dialstring in a tel uri or user=phone uri that we should 
just deprecate it.

I think specifications are all about "fine semantic points".  
Specifications strive to be precise.  If the tel uri bis draft is not 
precise enough for you that dialstrings are out of scope, then we should 
make it more precise.

I don't want a UA vendor implementing user=dialstring only to have
a proxy that assumes user=phone.  I really think MUST IMPLEMENT for
both is silly.

I do recognize that the same sequence of digits can be a dial string,
and a local phone number within the "same" context.  That doesn't make 
them the same thing, especially when the recipient doesn't know what he has.
That is why consensus came down to using user=dialstring when you have
a dialstring, and user=phone when you have a phone number.  That way,
a proxy that understands dialstrings can translate, and proxies that 
understand only phone numbers can route appropriately.  Explicit, rather 
than implicit was the reason cited by those in favor of user=dialstring.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 26, 2003 10:31 AM
> To: Rosen, Brian
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [Sipping] User=Phone/DialString and Pause and Wait
> 
> 
> 
> 
> Rosen, Brian wrote:
> > 
> >>>We all agreed that a tel uri, which is also convertible to 
> a sip uri
> >>>with the user=phone convention, remained a way to express 
> >>>local or global phone numbers, and not dial strings.
> >>
> >>I wouldn't go quite that far. While we agreed that the sip uri with 
> >>user=dialstring may be used to represent dial strings, I 
> >>>don't believe that eliminates the option of using a tel: 
> uri with a local 
> >>>number and a context.
> > 
> > I don't understand your concern.
> > What we agreed was that a local or a global number was expressable
> > as either a tel uri, or a sip uri with user=phone interchangeably.
> > So a tel uri can be used for a local number, and a sip uri with
> > user=phone can be used for a local number.
> 
> agreed.
> 
> > We confirmed that a tel uri cannot be used with a dial 
> string, and we
> > decided that a sip uri with user=phone cannot be used with 
> a dial string.
> 
> I think you overstate the case. I think we agreed to define a 
> new value 
> "dialstring" that MAY be used with the user= parameter of a 
> sip uri. And 
> it MAY be used to represent a dialstring.
> 
> It remains demonstrably the case that a dialstring *can* also be 
> represented as a tel uri with a local number and context, as has been 
> discussed ad nauseum on this list. Of course "can" isn't the same as 
> MAY. But AFAIK we *didn't* decide that it MUST NOT.
> 
> Which approach is used should really be a local matter 
> between the phone 
> and the proxy. It depends both on the features and configurability of 
> the phone, and on the translation capabilities of the proxy.
> 
> I know you will argue that the definition of the tel uri says 
> it can't 
> be used for dial strings. But this still comes down to a fine 
> semantic 
> point of whether what is being represented is a dial string or a 
> particular form of local number that is closely related to what was 
> dialed. The distinction is purely in point of view, so either 
> conclusion 
> is valid.
> 
> This really is a nit - it perhaps falls into the realm of 
> best practice.
> 
> 	Paul
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Nov 2003 13:48:50 -0500

Brian,

I agree that interoperability is important. In the end, unless the phone 
does the entire job of translation there must be some coordination 
between what the phone does and what some proxy downstream does.

To make that work amounts to having at least a minimal dialplan in the 
phone. Minimally this amounts to some substitution rules involving the 
dialstring and some constants configured in the phone.

I gather you have in mind that the phone should have a rule of the form

	url = "sip:" dialstring "@" proxy-address ";user=dialstring"

But that only works when there are no special cases. To support 
dialplans in the phone, it is likely to need to handle a series of 
templates. Often the template of last resort may want to defer to a 
downstream node to sort things out. The template for that could be 
equivalent to the above, but needn't be - it can just as easily make a 
local number with a special context.

We've already discussed reasons why the simple scheme you like has 
problems - like when phones desiring different dialplan expansion share 
a proxy.

It may be more fruitful to explore in more detail what kinds of 
standardized provisioning support ought to be required in phones. I hope 
that is what is most important to you - that it is possible to provision 
any sip phone to work properly with any proxy.

	Paul