Subject: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telephone C alls

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Jun 2003 17:29:28 -0400

Francois Audet wrote:

Thank you much for your extensive comments. I'll only comment on the 
more major changes, just in case somebody wants to jump in.

> ----------
> 
> 1)  (Editorial) Title: I believe the title should be "The tel URI for 
> Telephone
>     Numbers" instead of "The tel URI for Telephone Calls" since a URI 
> does not
>     imply that there is a call.

Agreed.

> 11) Page 6 (Editorial)
>     Change "Their" to "their" in section 5 title.

Nope, says "Words into Type" :-)

> 
> 12) Page 7
>     Section 5.1.2 does not describe what to do with non-numeric DTMF 
> digits (A, B
>     C and D). This is NOT the same as the ISUP BCD-encoded A-F digits. 
> Those
>     digits are defined in ITU-T Q.23. I would imagine that we want to 
> prohibit
>     their use in a URI.

Since those DTMF digits would be dial string, I tend to agree, although 
I don't know how you'd tell the difference in URI between a 'legal' Q.23 
letter A and an illegal DTMF 'A'.

> 18) Page 15 (Minor)
>     The description of Proxy translation encourages people to use URIs
>     like "sip:[email-masked]" and let the proxy "deal" with it. I tought
>     this is exactly what we did NOT want to encourage people to do since
>     it assumes a uniform dialing plan accross a whole proxy. This would 
> force
>     the service providers to deploy as many proxies as there are
>     dialing plans which is very undesireable.
>     Rather, I would encourage people to use a phone-context (in a tel URI
>     or prefereably a SIP URI) that identifies the dialing context
>     explicitely. For example, it could be as follows: 
> tel:1234;phone-context=
>     munich.example.com (or 
> sip:1234;phone-context=[email-masked];
>     user=phone).
>     With this approach, the service provider could assign a 
> phone-context per
>     dialing plan and not require one proxy per dialing plan. A large number
>     of phones could be deployed, for example, in the Munich office by 
> having
>     all the phones preconfigured with the 
> phone-context=munich.example.com (of
>     course it could also be manually configured).
>     I fear that if we leave it as is, the phone manufactures will take 
> the easy
>     way out and NOT allow for configuration of the phone-context which will
>     not make for easy deployment, especially when multiple regional 
> offices with
>     different dialing plans are supported.
> 

I tried to reword the section to address this concern, which I share.

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 25 Jun 2003 01:10:09 +0100

Hi Henning, François, folks,
At 5:29 pm -0400 24/6/03, Henning Schulzrinne wrote:
>Francois Audet wrote (on 25/04/03, in HTML) a review of 2806-08.
>

OK, here goes...referring back to the pints made in François' original review:

2)   final sub-point: Perhaps "resource associated with a telephone 
number" might
      be less easily confused with telephone numbers as a resource? 
(I've read too
      many SG2//SPAN//... documents :).

7)  I disagree. The program on my PC knows the context in which it works; if I
     select a number from my address book it will detect where this involves
     a call external to the ISPBX and will process this to include the "public
     escape digit", in our case "9". This is passed via ISDN signalling to the
     ISPBX from the ISDN phone that is in turn driven by the program. This is
     a dialer application, as it DOES have to deal with dialing plans - my
     address book doesn't, and the phone doesn't. I think that this is an
     immediate counter-example, so I'd suggest that it is left as is in -08.

8)  I took the parenthetical clause to mean DID or MSN/partial number or
     sub-addressing service. Whilst we COULD spell out all of the options,
     the use of "DID" (DDI over here) to encompass all of these services
     seems better, IMHO.

9)  Oops - what was this section meant to cover?

10) Big point:: If this is the sense of the group, then I'll live with it.
     However, I don't like it at all, as it is perfectly possible to identify
     a number of contexts in which an address resolves to the same termination
     point (usually to a call centre somewhere in India). Programming the same
     drop point for the "same" number used in different countries/contexts does
     happen, so whilst this is by no means always the case, this doesn't mean
     that it never happens. Multiple contexts can be valid for a given number,
     IMHO, so I don't think we should ban them.

12) I agree with you both - I don't see how we can avoid prohibiting ISUP
     non-decadic signals (useful for some private systems) whilst blocking
     the non-decadic dialed digits, so I guess we have to leave it as is -
     I take the last sentence to discourage their use anyway.

13) That's why it's a SHOULD rather than a MUST; how does this proposed
     additional text help? Please can we leave this as is (it has been
     through enough iterations already :).

14) Big Point redux:: I disagree, for the same reasons given for (10) above.

17) only if we want a circular reference :)

18) Absolutely agree with this - unfortunately, it clashes with 
reality right now :(

Perhaps we should put in a sentence to clarify that:

     "This basic approach is can be onerous, in that the OBP may 
maintain a number
     of different contexts, and so may be forced to add a 
phone-context appropriate
     to the private number plan associated with the call to any tel: 
URI it generates,
     interpreting this based either on the identity of the originating 
phone user
     and the number they specify in the call".

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Jun 2003 21:41:32 -0400

Conroy, Lawrence (SMTP) wrote:

>      be less easily confused with telephone numbers as a resource? (I've 
> read too

where? "resources identified by a phone number" seems clear enough.

>     immediate counter-example, so I'd suggest that it is left as is in -08.

Please look at the wording of 
http://www1.cs.columbia.edu/sip/drafts/draft-ietf-iptel-rfc2806bis-01.txt 
to see if this is acceptable.

>     the use of "DID" (DDI over here) to encompass all of these services

I've simply omitted this since 'tel' does support extensions and 
sub-addresses. Again, please see the new text.

> 9)  Oops - what was this section meant to cover?

What's now in the tel-for-SIP appendix.

>     IMHO, so I don't think we should ban them.

The perception was that it would be tedious to identify all the contexts 
and that in some circumstances, it would be better to designate a new 
context that encompasses several individual ones. I'm agnostic on this 
one, but this has to be resolved one way or the other. I'm having a hard 
time seeing where such multiple contexts would appear.  They clearly 
won't appear in the phone-puts-numbers-in-URI case. A web page or 
directory seem about the only case, and seem rare even there. Even if 
the number is the same, listing a few instances like

dial tel:1234;context=+1 in the UA
dial tel:1234;context=+49 in Germany

seems good enough.

In most cases, it seems that the number, while valid in multiple 
contexts, only needs to be made unambiguous by labeling it with one.

>     I take the last sentence to discourage their use anyway.

I don't think they are going to be common and the people that really, 
really need them will hopefully know what to do with them.

> 17) only if we want a circular reference :)

RFC 3261 does explain the syntax.

> 
> 18) Absolutely agree with this - unfortunately, it clashes with reality 
> right now :(
> 
>     "This basic approach is can be onerous, in that the OBP may maintain 
> a number
>     of different contexts, and so may be forced to add a phone-context 
> appropriate
>     to the private number plan associated with the call to any tel: URI 
> it generates,

Please see new text and suggest improvements if necessary.