Subject: Re: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URI for Telepho...

From: [email-masked]
Date: Wed, 25 Jun 2003 12:30:58 EDT

In a message dated 6/24/2003 5:32:39 PM Eastern Standard Time, 
[email-masked] writes:

> >  (Francois Audet had written)
> > 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'.
> 

This distinction has been giving people fits for years in various signaling 
systems. It seems to me that the difference is that the other 4 DTMF "digits" 
(A, B, C, and D defined in Q.23) are part of a dial string. Various signaling 
systems like ISUP define BCD-encoded digits (we represent as A-F) as possible 
parts of a destination number. (The alphabetic characters represented by the 
letters associated with numbers, which is what the first paragraph of Section 
5.1.2 addresses, causes even more confusion. The second paragraph, talking about 
the BCD coding in ISUP, causes additional confusion being part of this same 
section as "alphabetic characters" and should be moved, since they are two, 
very different things.)

I don't understand your statement above about "legal Q.23 letter A and an 
illegal DTMF A". They are the same thing.

The result of Q.23 and E.164 is that the extra 4 "digits" on a DTMF keypad 
can be used only for local subscriber signaling and maybe for end-to-end 
signaling (not seen by the network). As an example, a military systems could use the 
extra 4 DTMF keys to indicate precedence level as a part of the subscriber 
signaling, but these would not be carried in the ISUP signaling as "digits". ISUP 
might use its extra 6 Hex values for internal network functions that do not 
relate to any subscriber signaling. There is a clear separation today between 
subscriber signaling and internal network signaling.

The problem here is caused by trying to define some "neutral", general 
purpose signaling element (tel:uri) which does not make the distinction between 
subscriber dialing, internal network signaling, and pure end-to-end signaling. The 
"local" format seems to be allowing these extra 6 values, while the transport 
of a "dial string" would need to carry the extra 4 codes defined in Q.23. I'm 
still not clear on how the * and # on the DTMF keypad are carried when the 
tel-uri is being used. The draft states that "dial strings are beyond the scope 
of this document", but then it seems to attempt to support raw dial strings by 
showing how dial strings like "911" are coded. The implication of this is 
that any series of key strokes by the user could be coded in a similar fashion - 
i.e. - a "dial string".

I believe there needs to be a very specific decision on whether or not the 
tel:uri needs to include "dial strings" or if its only purpose is to carry what 
the draft defines as "address of record". If it is to not include "dial 
strings", then codes to indicate the extra 4 DTMF keys as well as the * and # do not 
need to be considered. However, then I would not know what to do with local 
dialing that in fact uses * and #.

Mike Pierce

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Jun 2003 12:55:06 -0400

> 
> This distinction has been giving people fits for years in various 
> signaling systems. It seems to me that the difference is that the other 
> 4 DTMF "digits" (A, B, C, and D defined in Q.23) are part of a dial 
> string. Various signaling systems like ISUP define BCD-encoded digits 
> (we represent as A-F) as possible parts of a destination number. (The 
> alphabetic characters represented by the letters associated with 
> numbers, which is what the first paragraph of Section 5.1.2 addresses, 
> causes even more confusion. The second paragraph, talking about the BCD 
> coding in ISUP, causes additional confusion being part of this same 
> section as "alphabetic characters" and should be moved, since they are 
> two, very different things.)

Good point; I created a new subsection.

> 
> I don't understand your statement above about "legal Q.23 letter A and 
> an illegal DTMF A". They are the same thing.

That's what I thought. I understood Francois that they are somehow 
separable.

> 
> The result of Q.23 and E.164 is that the extra 4 "digits" on a DTMF 
> keypad can be used only for local subscriber signaling and maybe for 
> end-to-end signaling (not seen by the network). As an example, a 
> military systems could use the extra 4 DTMF keys to indicate precedence 
> level as a part of the subscriber signaling, but these would not be 

This would be 'dial strings', not identifiers, so they'd never show up 
in a tel URI.

> carried in the ISUP signaling as "digits". ISUP might use its extra 6 
> Hex values for internal network functions that do not relate to any 
> subscriber signaling. There is a clear separation today between 
> purpose signaling element (tel:uri) which does not make the distinction 
> between subscriber dialing, internal network signaling, and pure 
> end-to-end signaling. The "local" format seems to be allowing these 
> extra 6 values, while the transport of a "dial string" would need to 
> carry the extra 4 codes defined in Q.23. I'm still not clear on how the 
> * and # on the DTMF keypad are carried when the tel-uri is being used. 

There seem to be two possibilities: treat them as identifiers within a 
local dial plan or disallow them altogether. I don't see principal 
problem with treating them as part of things that can appear in a local 
number, i.e., with appropriate qualification. What would break if we do 
this?

> The draft states that "dial strings are beyond the scope of this 
> document", but then it seems to attempt to support raw dial strings by 
> showing how dial strings like "911" are coded. The implication of this 
> is that any series of key strokes by the user could be coded in a 
> similar fashion - i.e. - a "dial string".

911 is not a dial string in my view. It's an identifier (that happens to 
resolve to different endpoints, but that's immaterial).

> 
> I believe there needs to be a very specific decision on whether or not 
> the tel:uri needs to include "dial strings" or if its only purpose is to 
> carry what the draft defines as "address of record". If it is to not 
> include "dial strings", then codes to indicate the extra 4 DTMF keys as 
> well as the * and # do not need to be considered. However, then I would 
> not know what to do with local dialing that in fact uses * and #.
> 
> Mike Pierce

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

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 25 Jun 2003 18:28:54 +0100

At 12:30 pm -0400 25/6/03, [email-masked] wrote:
<snip>
>I believe there needs to be a very specific decision on whether or 
>not the tel:uri needs to include "dial strings" or if its only 
>purpose is to carry what the draft defines as "address of record". 
>If it is to not include "dial strings", then codes to indicate the 
>extra 4 DTMF keys as well as the * and # do not need to be 
>considered. However, then I would not know what to do with local 

Hi Mike, folks,
   there was a clear decision - the draft states it - tel: is NOT 
dealing with dial strings.
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.