Subject: Re: [IPTEL] Comments on RFC2806bis

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 12 May 2002 15:34:43 -0400

Sorry for the delay in responding to these comments. I've updated the 
draft and will submit it shortly. Until it appears in the archives, you 
can find it at 
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-03.txt
and
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-03.ps 
(with changebars for non-trivial changes).

[email-masked] wrote:

> 2. In the 7th paragraph (beginning "The approach pursued...") Extensions of a 
> PBX can be specified if they are a part of the global number (i.e., when DID 
> is used). Propose that the words "when direct inward dialing is not used" be 
> added after "PBX".

Added.

> 
> 5.1.2 Maybe it would be helpful to emphasize that, while the uri format does 
> not support alphabetic characters, it is expected that the user agent would 
> support entry of such characters by the user and translation based on some 
> standard.
> 
> The mapping of alphabetic characters to numeric digits is in fact 
> standardized in E.161 as well as in American National Standard T1.703-1995 
> (R1999). However, it is still a good idea to not use this mapping as a basis 
> for the uri. It is suggested that this final sentence be: "The URI format 
> does not support this since the mapping of alphabetic characters to nurmeric 
> digits is not completely uniform internationally, although there are 
> standards addressing this mapping."

Noted.

> 
> It is unclear why the second paragraph states that "F is currently not used." 
> and "These do not designate the fourth column of the DTMF tone matrix." The 
> term "Terminal number" is not the usual one used. These statements lead to 
> confusion. In fact, ISUP defines the additional six values as "code 11, code 
> 12, ST, and 3 spares", not A-F. It uses the "1111" or "F" value. As shown in 
> the ABNF, the digits of the global-number are limited to 0-9. While the 
> digits of the local-number are shown as HEXDIGIT, it is unknown where this 
> would be used for a tel:uri. It is suggested that this paragraph be reworded 
> to: "Since called and calling party numbers are encoded in BCD in ISUP, this 
> allows for six additional values per digit, sometimes represented as the HEX 
> characters A through F. However, in accordance with E.164, they may not be 
> included in global numbers. Their use in local numbers is not defined, but is 
> not prohibited."

Added your wording and cleaned up the BNF. Lawrence, please indicate 
whether restriction to local digits is acceptable and if not, how this 
related to E.164.

> 
> 5.1.3 In the first paragraph, the phrase "if the client is properly 
> configured" should be deleted. International numbers themselves are 
> unambiguous. It is unrelated to the "configuration" of "the client".

Gone.

> 
> In the second paragraph, it is unclear why the second sentence states that 
> "some numbers may work from several networks but not from the whole world; 
> these SHOULD be written in international form". Since it follows the first 
> sentence, it is presumed to be referring to "local numbers". It is impossible 
> to write a local number (which does not work everywhere) in "international 
> form".

Cut-and-paste... Gone.

> 
> 7.3 3rd paragraph: It is unknown why "/" is mentioned here as a possible 
> character separator. In fact, in E.123, the "/" means something else. This 
> mention here may confuse people.

The whole paragraph seems to be more confusing than helpful, so I 
ditched it.

> 
> 7.4 While this section is interesting, it has nothing to do with the subject 
> of the document and should be deleted. It might confuse someone into thinking 
> that it has some impact on the uri.

Same remnant of the old draft. History.

> 
> 7.5 To avoid confusion, the number 00123456789 in the example should not be 
> referred to as a "local phone number". This sentence should say: "Tel URIs 
> should, in general, not contain the local dialing prefixes such as the "00" 
> in 00123456789..."
> 
> It might also be helpful here to mention that, according to E.164, the "+" in 
> the writing of the international number actually means that an international 
> prefix is required ("00" in this example).

Rephrased.

> 
> 8. The last example in this section should show a valid E.164 number with a 
> valid US area code, even though the number/letters displayed may contain 
> extraneous characters to spell a word, as is the common practice (at least in 
> the US). I would expect that an implementation might discard a uri that it 
> knows to be incorrect, such as one beginning with +1 that is not followed by 
> exactly 10 digits. (Not required to do this, but it might.) The example 
> should be:
> 
>     a href="tel:+17034383785">1-703-IETF-RULZ-OK</a
> 
> (Of course, the above needs the angle brackets at the beginning and end. Does 
> anyone know how to get AOL to stop turning my examples of html into hidden 
> HTML tags?)

I changed the reference.

> 
> References: FED-STD-1037C should be replaced by ANSI T1.523-2001, 
> Telecommunications Glossary, which replaced it.
> 
> Mike Pierce
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 May 2002 13:14:47 -0400

I've changed things so that all digit strings can contain hex digits. 
This seems simplest and least likely to cause future problems. In 
general, I don't think syntactic checking of phone numbers buys much, 
given that most syntactically legal random numbers are probably not valid.

Yu, James wrote:
> I agree that it is better to use hex digits also for global-number so that
> there is no need to modify the RFC if E.164 is changed.   Allowing hex
> digits does not mean all numbers are valid.  Even if we only allow decimal
> digits for country codes, those country code values, if not yet assigned by
> ITU-T, are invalid.  Suggest to use hex digits and let the node decide
> whether a number/prefix is valid or not for routing.
>

---

From: "Crizza, Roberto" <[email-masked]>
Date: Tue, 21 May 2002 14:09:34 -0500

I agree
Here we dial the carrier selection, if we don't handle these numbers they
will not routing to right path.

Roberto Crizza -   CCDA			
EDS Brazil - CI - Telecomunicacoes
I. Solutions  - DowNet Project
Phone.: 55 11 3471-4536 (8-893- )
Fax.:      55 11 3471-4557 (8-893- )
Cell.:      55 11 9531-9695 
email.:    [email-masked]

Flemming wrote:
>
>Take another example where I as a consumer actually dial a particular
carrier
>selection code as part of my call, but by default, all my calls are handled
by
>another carrier. I don't see how you will route this call correctly without
a
>guarantee that at least one entity in the forwarding path understands the
>extension (not to mention the fact that routing can be rather inefficient
if
>preceeding hops routed the call incorrectly because they didn't understand
the
>extensions).
>
>In other words, I don't see how these parameters can be optional. If you
are
>concerned about lack of implementation support, then perhaps the best way
to
>address that is by including the extensions in 2806bis, since they 
>do seem to be
>a prerequisite for a generally useful tel-URI.
>
To which I reply:
  It can be used in SIP, but it can also be used in a static form 
(e.g. DNS NAPTR
content). In the latter case, it may be in the public ENUM space, or it
might
be stored within a Service provider's private space.

I do not believe that a rn or cic parameter is a prerequisite for all these
cases - Indeed, for the static (DNS) cases one may or may not need this
parameterisation at all.

I agree with James that it cannot be mandatory (i.e. "use this or fail").
For example, looking at the SIP case, a recipient of a SIP dialog may or
may not have a trust relationship with the sender of this information.
If they do not then they are at liberty to do another dip themselves.
Thus a mandatory "do or die" is not appropriate, IMHO.

My DSL router/FW/SIPproxy/Registrar box at home sure doesn't understand
this parameter. Then again, when I outcall with this kind of URI there
WILL be some external outbound proxy and/or gateway in line, and whilst
understanding this parameter by *that* box may be required (for regulatory
reasons ?), I'd be really unhappy if my home box were to be declared
non-standard because it cannot understand nor act on a cic value but
instead passes it downstream.

For both these reasons, I belive that this is a stand-alone extension, and
is NOT a core part of RFC2806bis. Note that we lost the 'tsp=' parameter as
well in the bis process; that would also be a stand-alone extension.

all the best,
   Lawrence

-- 
[email-masked]: +44 1794 833666::<my opinions>:
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 21 May 2002 21:14:02 -0400

"Yu, James" wrote:

> > >
> >
> > But what if the call never arrives at a PSTN gateway or
> > SIP server that
> > understand these extensions ?
> >
>
> [JY]  The node at least has the phone number for routing decision.  If it
> does not know how to route based on a phone number, the call then fails.
> But it does, the call will continue.

OK - I'll buy that for the "rn" parameter.

>
> >
> > But again, what if the call does not arrive at such a
> > node ? You seem to be
> > arguing on the precise of assuming that if entity A does not
> > support these
> > parameters, then probably some other entity B will, and hence
> > everyting will
> > work OK. I don't find this convincing.
>
> [JY] Same as above, the call will fail if the next node does not even know
> how to route based on the phone number.  At least the call has a higher
> chance to survive if we allow it to continue with the downstream node.  The
> call will never be set up if any node in the call path will drop the call
> because it does not understand "rn" or "cic."
>

Maybe so, but as far as I can tell, it gets routed incorrectly here. Let's say I
dial 1010321+0 to reach an alternate IXC operator. 2806bis explains, that I
shall not put the dial-string in the tel-URI, but rather the telephone number,
which in this case is "0". The CIC is "0321", so my tel-URI becomes something
like "tel:0;cic=+10321". Now, if nobody understands the CIC parameter, the call
ends up at the presubscribed IXC operator, and not the alternate operator. That
doesn't seem right.

>
> >
> > Take another example where I as a consumer actually dial a
> > particular carrier
> > selection code as part of my call, but by default, all my
> > calls are handled by
> > another carrier. I don't see how you will route this call
> > correctly without a
> > extension (not to mention the fact that routing can be rather
> > inefficient if
> > preceeding hops routed the call incorrectly because they
> > didn't understand the
> > extensions).
>
> If a caller (SIP UA) can put in the "cic" to specify the carrier to use and
> if the outbound SIP proxy server (assume that it is operated by a service
> provider) does not understand the "cic," I don't see how that service
> provider can support this type of "dialing."
>

That is my point. If what you are trying to do is support telephone numbers,
then you need to support carrier selection, and hence it cannot be optional.

>
> I can see that when "cic" is not popularly supported by many nodes, it is
> likely that "cic" (if received in the response to the database query) may be
> mapped to a host associated with that "cic" so that "cic" is not carried in
> the tel or sip URL.  Or the carriers can set their routing tables so that
> the next node understands "cic."

That sounds like fixing the sympton, not the problem IMO. If this is what you
envision, then the limitations and pitfalls shold be pointed out clearly. As it
stands now, the CIC parameter is useless as far as I can tell (since you can't
depend on it), and we should rather simply require mapping such a selection to
an appropriate domain name and then use SIP-URIs instead of tel-URIs. Am I
missing something here ?

-- Flemming

---

From: [email-masked]
Date: Wed, 22 May 2002 14:40:38 EDT

In a message dated 5/22/02 1:06:10 PM Eastern Daylight Time, [email-masked] 
writes:

> Strictly, the old code is blocked at the International Gateway Exchange.
> Thus it can be written as a valid E.164 number; it is just blocked from
> International origination. Both versions are unambiguous, it's just that
> one is not routable from some origination points.
> 
> +43-22-123456 - is this an E.164 number?
> +43-1-123456 - is this an E.164 number?
> If these are dialled from within Austria, they should terminate at the same
> 'phone. If you try to dial the first variant outside Austria, it's blocked.
> 

I haven't been to Vienna lately, but am confused by this example. If the same 
phone can be reached by two different numbers, is this because they are in 
the middle of a change in dialing plan? If the two numbers are represented as 
shown above, then that explicitly means that both can be dialed from 
anywhere. Why would the "22" variant be blocked?

Mike

---

From: [email-masked]
Date: Thu, 23 May 2002 15:43:14 EDT

In a message dated 5/23/02 1:04:55 PM Eastern Daylight Time, [email-masked] 
writes:

> 
> OK, I admit it - I mistyped the code - the old code is 222, not 22. 
> Sorry about that.
> 

Yes, the 222 helps to clarify the issue - one of changing a numbering plan 
which we do a lot. So there is a period of time in which either number may be 
dialed and the call gets through. I still don't see the point of saying that 
it is allowed inside the country and blocked from outside. The period for 
allowing both to be routed should be the same for all originating points.

On the other hand, concerning the issue of too many numbers (more than 15 
now). I suspect that the reason that Vienna changed from 222 to 1 was to 
avoid the previous limit of 12, not the new 15 digit limit. I'm sure that no 
number would be assigned in Vienna which exceeds that limit (7 using the 222 
city code) until after the allowable dual dialing period. After that, the 222 
should no longer be used to route even within Austria due to the probable 
limit on the length of the digit string.

Mike