Subject: RE: [Iptel] comments on rfc2806bis

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 4 Dec 2002 14:35:57 -0500

Sorry, I'm think we're off the deep end.

What is the goal here?

I thought it was how you ginned up a URI from a phone number.
I was having enough trouble when we punted dial strings; 
that's what the simplest UA needs to do - send a dial string.  
Everything else is useless if all you have is a box with a 
handset and a 10 key pad.  But okay, we ignore that one for 
now.

I don't see the difference between a "local number" and the
(0) example.  It's not a dial string, it's a number that is
interpreted within a context (the exchange where the call 
is made from in this case).  In the most typical environment, 
the caller doesn't know that, only the GW knows that.  
You HAVE to send the (0) or a full E.164, or the gateway 
won't know what to do.  What is a moderately complex UA to do?  
Either it has to have rules that always expand to a full E.164, 
or it has to send the (0).

I think the distinction between the global number and anything 
else is useful, and I'd like to keep it.  I think everything 
else (including dial strings btw) is a local number that is 
expressed within some context. If I dial 9-011-44-7810-23437 
that's a LOCAL NUMBER, expressed in a local context, in this case, 
the PBX at Marconi in Warrendale.  If I dial (0) 90 32 / 69 12 34 
that's a local number in a context. There is no difference 
between those and 6826, which has the SAME context as the first 
example above.  If we are willing to define contexts and 
parameters like extension, then we can deal with (0) and even 
dial strings exactly the same way.  Again, I AM willing
to punt on dial strings for now, I just wanted to make the point 
that they are just local numbers within some defined context.

Then we get to pretty-printing.  Seems to me you are in for a 
penny... on pretty printing - you either preserve the formatting 
from the source or you don't.  Substituting "-" or "." for " " is 
not preserving formatting.  If we want to preserve formatting, 
which I do, then we allow (escaped) spaces.  If we don't, then 
we should eliminate visual separators entirely.

What I really want to do is to look at the "real" problem.
Seems to me that in web pages, AORs and the like, there is little
benefit in anything but a global number without pretty printing.
To me, those are easy.  I think any gateway should be able to
deal with a global number, as should any UA. 

The hard part is how real phones talk to real gateways through real
proxy servers.   I think we should make this version of the RFC
work for most cases of that.  If we must ignore dial strings, okay,
but we can't ignore things like phone numbers in contact lists,
callerId and phone books (directories).  All of those have local 
numbers in contexts.  That is what they send, that is what they 
expect to receive, and the tel: URI should handle that gracefully.
To me, that includes preservation of formatting.

This has been a great source of incompatibility between 
implementations; sipphones send one thing, gateways expect another 
is the classic. We need to specify how these things work.

In my implementation, the proxy servers translate between what 
the UA sends and what the gateway expects.  We use regular expressions 
to create dialing plans and translate those plans to whatever the 
gateways are connected to.  Works fine as long as you can send any 
kind of phone number, and the context of where that number came from, 
to the proxy.  The biggest source of trouble is when a contact in a
contact list gets sent from a roaming user.  If, for example,
I have a contact in my contact list for the guy that sits next to me
in Warrendale that is 4823, and I log into a sipphone in the U.K,
and then push my speed dial button for that guy, I want his phone to
ring.  That is not hard, as long as the contact is interpreted in
the domain I wrote it in, which is my "home" domain.  All I have to
do is to get the local (i.e. UK) proxy server to know what domain it is.

We need a reasonable syntax for this, and a reasonable naming
convention for domains.  I WANT to send the (0), and I want to have 
all the formatting in the URIs.  I need to have the context the number
came from.  Then, I can do whatever translation is needed,
find the right gateway, etc.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2002 11:24 AM
> To: Rosen, Brian
> Cc: 'Jonathan Rosenberg'; [email-masked]
> Subject: Re: [Iptel] comments on rfc2806bis
> 
> 
> Since there's no agreed-upon semantic distinction between 
> space, ., () 
> and -, I don't think we need to support spaces. 
> +44-11-22-33-4567 will 
> work just as well. I suspect you'll also see +44.11.22.33.4567 and 
> humans will easily deal with either. The (0) issue, indicating 
> optionality, does not arise in E.164 numbers.
> 
> Rosen, Brian wrote:
> > It's very hard (we've tried) to build a "pretty printer" that takes
> > an arbitrary number and displays it pleasantly on callerId.  
> > It's pretty easy to preserve what was sent.  I want to do that. 
> 
> We're in agreement on that. The separators, any of them, are 
> enough to 
> render numbers in a way that people can more easily read and 
> transcribe 
> them, compared to a longish string of digits.
> 
> > 
> > Confusing things even more, the business card in front of 
> me displays
> > a number like:
> > +49 (0) 90 32 / 69 12 64
> > 
> > Slash is on you sep list, right?
> > 
> > Then, what do we do about that pesky (0)?
> 
> You don't worry about it - it's not part of the E.164 number 
> and we long 
> ago agreed that we would not deal with whatever dial prefixes 
> are needed 
> to dial, say, long-distance numbers. It would simply be
> 
> +49-9032-691264
> 
> or
> 
> +49(9032)691264
> 
> 
> > It's one of those context thingies, right?
> 
> No. Please, please, let's not go there again. We've had a 
> month of that 
> discussion and I'd rather not rehash it.
> 
> > This guy is in my contact database that way.
> > If I dial the number, I know how to deal with the zero.  
> > However, we don't want to build into the UA the mechanism 
> to translate
> > depending on where you are.  That means a proxy does it, or
> > probably the terminating gateway.  So, I probably send the 
> zero, but do
> 
> Whoever actually dials needs to know how E.164 numbers become dial 
> strings. That's not terribly hard, since that entity only needs to 
> detect how local the number is (same country? same area 
> code?) and know 
> its local dialing rules (11-digit dialing? 10-digit dialing? 7-digit 
> dialing? Add 0 or 1 or 011?)
> 
> The draft talks about this at some length.
> 
> I gather some systems (ISDN?) even allow E.164 numbers directly or at 
> least allow uniform national dialing without worrying about 
> whether an 
> area code is needed or not.
> 
> > I need to send context info.  I suspect not, but we should think
> > about it.  
> > 
> 
_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 05 Dec 2002 13:14:18 -0500

While I don't claim to follow all of your remarks below, let me try to 
summarize what I see as consensus positions within the working group:

- We emphasize globally unique identifiers assigned within the PSTN 
(roughly equivalent to the set of E.164-conformant numbers) that are 
unique everywhere, but may not be reachable from all places. The 
document calls these global numbers.

- In many cases, these identifiers are never dialed, but are used for 
identification or lookup only.

- If they are dialed, we assume that the device connected to a PSTN line 
or trunk is the only one that truly knows what digits need to be emitted 
to reach the intended destination successfully. One could argue that 
this functionality could be split into two parts, but since the dialing 
process is actually a multi-state process (with timers, waiting for 
certain network conditions and tones, etc.), it is not clear that this 
can successfully be done without writing a Turing-complete language (or 
at least a state-transition language) or re-inventing MGCP or Megaco. 
Modem AT dial strings come close, but they require a fair amount of 
external configuration, such as the type of dial-tone expected (e.g., 
stutter dial-tone) and timers, so this is only modestly helpful. It is 
well known that AT dial strings are brittle for anything but the most 
trivial cases since they cannot deal with error cases or anything more 
complicated than a simple second dial tone and fixed-length waits. (Try 
creating a dial-string when calling card numbers are involved...)

Given the global identifier nature of URI/URNs, I doubt that it is 
useful to encode dial strings as such. To me, this seems like encoding 
the egress gateway or local proxy server in a HTTP URI or the outbound 
SMTP MTA in a mailto URI.

- Local numbers are escape hatches in cases where a terminal does not 
have a global number. They are strongly discouraged; e.g., they would 
not be needed for normal cases where a business has DID or extensions. 
They would only be needed for private dialing plans. They are made 
globally unique by the addition of the phone-context parameter. The 
phone-context parameter has only two functions: ensuring global 
uniqueness across tel URIs and detecting whether the URI scope is 
identical to the local scope.

In particular, in the terminology of the document, local numbers are 
*not* what is actually dialed. (I believe this is where I'm losing 
Brian's discussion thread.)

- Since URIs are meant to be human-readable, it is appropriate to add 
visual separators that are semantically invisible. All such separators 
are equivalent and roughly the same as white space in programming 
languages ("syntactic sugar"), which also comes in several flavors (SP, 
HT, LF).

- We haven't quite decided whether service numbers need special treatment.

I hope this helps.

Henning