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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Dec 2003 10:09:26 -0500

> > 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.
> 
> 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.
If you are proposing that a dumb phone is just a smart phone with a
default translation rule, then I don't see a problem as long as the
default rule is as I suggest (sip: in the front, user=dialstring and
phone-context in the back.

> 
> > 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.
> 
> 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?
The problem that I have with this is that a dialstring starting
with pound or star is not (at least usually) a phone number.
They are usually service invocations.  You rarely route such
a number to a terminal without a fair amount of processing.
The text states that they are possible characters in a local
phone number, so the syntax is permitted by the draft, but
in most cases you are using the tel uri to carry a dialstring,
which the draft says is out of scope.

So, I claim that you have extended the tel uri.  It's okay to have
a phone that does this, as well as your proxy implements the same
extension.  I don't know of any document that would describe such
an extension, and I don't want to support creating one.

Nevertheless, if that's what the administrator wants to happen,
and both ends can handle it, I wouldn't say that it's wrong.

> 
> 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.
I would say that your proxy would be going above and beyond the
minimal definition of routing a sip uri that has user=phone, but
I wouldn't want to prohibit it.  What I would want to "prohibit"
is a requirement that any phone that didn't have a digitmap be able
to send such a string.

> 
> 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?
Nothing, as long as your proxy can do this.  Not all proxies will.
Of course, not all proxies will process user=dialstring either.
The key issue for me is that dumb phones always process user
keypresses into user=dialstring+phone-context, and that is the one
way to get dialstring processing done.  If you happen to have a
proxy that can also process a dialstring that has user=phone, fine,
but the only phones that are going to do that are phones that have
digitmaps, and administrators who create a digitmap that does your
example for a proxy that implements things beyond the spec.

You could just as well have a digitmap that said:
	translate all numbers that start with "0".."9","*","#"
	to "sip:dialstring" + dialstring + "@cisco.com"
As long as your proxy can process a sip uri that looks like that,
then it's going to work.  Some proxies might work fine with that,
because they have regexp processing, and the regexp can handle
the example I gave.  No problem.  

I don't want to see your example, or mine for that matter, in any
standards document.

Brian

_______________________________________________
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: Tue, 02 Dec 2003 11:44:50 -0500

Brian,

I don't have any major disagreements with what you say below, though I 
think I would still spin it or explain it somewhat differently. I think 
this is ultimately coming down to how you configure phones - especially 
dumb phones - and how dumb a dumb phone is.

I imagine we can safely say that there aren't yet any phones that 
generate uris containing user=dialstring, so we are only talking about 
phones that are yet to be built, or at least new software loads for 
existing phones. And practically speaking, for awhile now there will 
probably be little market for phones that *always* generate uris with 
user=dialstring, because they won't work with older systems. So we are 
probably talking about phones that can be configured with that part of 
the translation. So I think even the dumbest of phones that can do any 
of this will probably be smart enough to do more than you expect from a 
dumb phone.

It may be that the best thing would be to standardize the configuration 
of dialplans in a phone, with the possibility that the dialplan could be 
as simple as a single mapping for all dialstrings, with the proxy 
expected to do the rest.

	Paul