Subject: RE: [Sipping] Brian's Comments on draft-mahy-sipping-user-equals-

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 28 Oct 2003 15:07:03 -0500

> > The introduction must define dial strings, and differentiate them
> > from local phone numbers.
> 
> I think this is the crux of the disagreement.  I don't think it is 
> possible to give a rigorous definition of what is a dial string and 
> what is a local number.  I invite you to describe an 
> algorithm you can 
> use to determine which is which.  If you can then I'll incorporate it 
> in the draft, but I am skeptical that such a distinction is testable 
> any more than the distinction between "erotic art" and "pornography".
A dial string is a series of digits, and */# characters entered 
directly or indirectly by a user.  They are interpreted in a local 
dial plan, to a local or global number, or a service invocation.  
A local number is an address of an endpoint in a locally defined 
numbering scheme.  It is often the case that a local number is the 
same series of digits in that domain's dial plan, but it is rarely 
true that there is a one to one correspondence, and many dialing 
strings may be translated to global numbers, while others may be 
translated to local numbers, or they may not be addresses of 
endpoints at all -- they can be service invocation indicators. 

> 
> >  It should introduce the idea that a
> > proxy in the listed domain of a dial string must translate 
> to a global
> > or local number, and that some phones will do this translation
> > themselves while others will not.
> >
> > Section 5 inadequately deals with dial strings.  Dial 
> strings are not
> > local numbers, and must be translated to local numbers.  One must
> > disambiguate dial strings from local numbers because it is possible 
> > that
> > they collide.  Such a differentiation is also useful to know when
> > translation has been completed.
> 
> i don't think they can collide because they are in different contexts
Only if you define them separately, and explicitly deal with establishing
separate contexts, as has been proposed.  The text is not explicit
about that.

> 
> > It has been proposed to use separate contexts for dial strings and
> > local numbers.  I generally don't like this idea, but it can be made
> > to work.  It would be best if there was some kind of naming 
> convention
> > to differentiate, but this is not strictly necessary.
> >
> > What is necessary is text in a document:
> > 	1. Saying that dial strings aren't local numbers
> > 	2. Permitting dial strings in a sip uri, with a dial 
> string context.
> > 		Note: if you wish to permit a dial string in a 
> tel uri, then
> >                  the language in 2806bis must be modified, IMO.
> > 	3. Explicitly defining the use of E/F
> > 	4. Illustrating the use of separate contexts for dial strings
> > 	5. Discussing the provisioning implications of having two
> > 		local contexts, one for phones with translation and
> > 		another for phones without translation
> 
> I thought I covered this last one a bit in the draft. A phone that 
> doesn't know its context can just use *itself* as the context.  That 
> requires no configuration.  A phone that has a digit map obviously 
> needs to be configured with it, so explicitly setting the target 
> context or domain (or both) should be no problem IMO.
While I can imagine that many systems would work with "self"
It's not going to work in the general case, because the interpreter
of the digits may be handling multiple domains.

Also, do you think we should leave it ambiguous whether a phone with
a digitmap translates dialstrings to local numbers (ie tel uris) or to
user@domain, where domain might be numeric?  I didn't like the
"context or domain (or both)" part of the statement above.  Too many
options, too many chances for proxy servers to assume something a UA
doesn't assume.

....snip....
> > We also should define a way to express a dial string with 
> pauses and 
> > waits.
> > They are pretty useful. They are dialable in many gateways.  We need
> > a way to send such a string.  Again, we need text, and 
> again, we could
> > use a separate context for such strings.
No comment here?  We need something, somewhere about this.

_______________________________________________
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