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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Nov 2003 14:10:35 -0500

Your example does not show a phone context, which it should.
You should always have a context for user=dialstring.
I actually propose that you MUST use a context with user=dialstring.
You need a context for user=phone when you don't a global number.

If your UA implementation does not support dialstring to number
translation (ie downloadable digitmap/regexp), then I propose
that you have a configurable/discoverable context, and the rule
is that you take all the digits, slap the sip: in the front,
your local outgoing proxy in the back, with user=dialstring and
phone=context=<whatever> and send it.

There is no "last resort". it's what a dumb phone always does.

I think that covers all cases of dumb phones.  It might also covers
a case you suggest, which would be an incomplete digitmap that
needed an escape clause.  Digitmap capable phones need more work,
and I agree we need to standardize that, and we both are aware
of the efforts to do that.

None of this is pushback to the argument that user=phone is only
appropriate when the userpart is the address of a terminal (ie
phone number).  I do want a simple rule - if you don't understand 
what the string of digits is, it's a dialstring and send user=dialstring.  
If you can, translate the dialstring to a phone number and send 
user=phone (or tel uri).  There is no third case that I know of.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 26, 2003 1:49 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: [Sipping] User=Phone/DialString and Pause and Wait
> 
> 
> 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
> 
> Rosen, Brian wrote:
> > 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
> > 
> > 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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 15:17:50 -0500

> You should always have a context for user=dialstring.

OK, I didn't know you intended that requirement. That makes things 
simpler and more clearcut, because it one more piece of 
configurable/discoverable data that even dumb phones need.

> phone=context=<whatever> and send it.

OK, that is what I thought you had in mind except for the addition of 
the context.

> There is no "last resort". it's what a dumb phone always does.

The way I am thinking of it is that a phone with a dialplan may 
ultimately need an "else" clause. A dumb phone is just a degenerate case 
of that, where the else clause is all there is. It would be nice to be 
consistent in that way between dumb and smart phones.

> of the efforts to do that.

It would also be very sensible for the translation that is used by dumb 
phones is of exactly the same form as one entry in a dial map for a 
smart phone. Rather than using the transformation you mention above on 
each dialstring, it would be straightforward to say that a single 
template is either configured, or is created from discoverable data. If 
you can discover a context to use with dialstrings you can just as well 
discover a template.

> user=phone (or tel uri).  There is no third case that I know of.

Suppose I had a dial plan that said:

	translate all numbers that start with "8"
	to "tel:" + dialstring + ";phone-context=dial.cisco.com"

I think that should be ok with you. Now instead, suppose I made the rule:

	translate all numbers that start with "0"..."9","*","#"
	to "tel:" + dialstring + ";phone-context=dial.cisco.com"

	translate all other numbers to
	"sip:" + dialstring + ";phone-context=dial.cisco.com"
	       + "@cisco.com;user=dialstring"

Is that still ok with you? Why not?

Its my system, my dial plan, my definition of the "dial.cisco.com" 
phone-context, so I don't see what you have to complain about. You say I 
can only use user=phone (or tel:) when the address is that of a 
terminal. But I get to decide what the addresses of terminals are. I say 
I am using my dialplan to translate dial strings into addresses of 
terminals - it just happens that my terminal addresses look remarkably 
similar to dialstrings.

Of course the last rule isn't needed any more because it can never be 
reached. So my complete dialplan is just:

	translate all numbers that start with "0"..."9","*","#"
	to "tel:" + dialstring + ";phone-context=dial.cisco.com"

What am I doing wrong here?

	Paul