Subject: RE: [Megaco] Audio Server - Digits

From: CHATRAS Bruno FTRD/DAC/ISS <[email-masked]>
Date: Mon, 8 Oct 2001 22:38:27 +0200

If we follow this kind of approach, the current specification can be further
simplified because variable types such as "time" and "date" do no need
subtypes any longer. Moreover, the reference to the NPA format for "Digits"
(in section 2.2.3) is not consistent with this approach. 

I'm not sure that this is the right approach anyway. Unlike call progress
tones, the format used to speak digits may need to be selected on a per call
basis. In the context of mobility services, it might be necessary to request
an MG located in a given country to speak digits according to the format
used in the calling party's home country.

We have two options:

- Consistently follow, throughout the whole document, the approach that we
have (deliberately?) used for tones and simplify the current draft. 

- Extend the syntax of the digit subtype to support other format than the
NPA format.

The second option looks more flexible to me.

> -----Message d'origine-----
> De : Troy Cauble [mailto:[email-masked]]
> Envoyé : lundi 8 octobre 2001 22:10
> À : Tom-PT Taylor
> Cc : 'CHATRAS Bruno FTRD/DAC/ISS'; [email-masked]'
> Objet : Re: [Megaco] Audio Server - Digits
> 
> 
> 
> 
> The Call Progress Tones Generator package specifies
> things like "busy tone" and "dial tone".  It doesn't
> specify what these are, presumably because they vary
> from country to country.  Even the referenced ITU-T 
> document, E.180, only specifies really wide, *recommended* 
> characteristics.
> 
> I always assumed this was deliberate.  Who wants a bunch of
> packages with busy_germany and busy_france?  Let the MG decide
> what "busy tone" means.
> 
> Wouldn't this same approach, general protocol - specific
> implementation, apply here too?
> 
> -troy
> 
> 
> > Tom-PT Taylor wrote:
> > 
> > This is definitiely interesting.  What do other people 
> think: is there a
> > general requirement to speak a string of digits as a series 
> of N-digit
> > numbers?
> > 
> > -----Original Message-----
> > From: CHATRAS Bruno FTRD/DAC/ISS
> > [mailto:[email-masked]]
> > Sent: Monday, October 01, 2001 6:13 AM
> > To: [email-masked]'
> > Subject: [Megaco] Audio Server - Digits
> > 
> > Tom,
> > 
> > I have question about the use of the variable type "Digits" 
> in H.248 Annex
> > M.1. I assume that this variable type is intended to be used for
> > representing telephone numbers in variable announcements. 
> However, I don't
> > understand how to use it in countries (e.g.; France) where 
> telephone numbers
> > digits are not spoken one by one.
> > 
> > In France (and possibly is some other countries), 
> 6137360961 (the example
> > given in H.248 Annex M.1) would be spoken as "Sixty one, 
> thirty seven,
> > thirty six, zero night, sixty one".
> > 
> > It seems that we need a new subtype value for supporting 
> this kind of
> > format. More generally, I think that the subtype should 
> allow to specify the
> > number of digits to be spoken as a single number.
> > 
> > cadence =       "gen" /                 ; One by one, no pause
> >                 "nadn" /                ; One by one, North American
> > DIrectory Number format.
> >                 "group:" 1*DIGIT                ; Digits 
> are spoken by
> > group, with a pause between each group.
> > 
> > Any views ?
> > 
> > Regards,
> > Bruno
> > 
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: Troy Cauble <[email-masked]>
Date: Thu, 11 Oct 2001 11:52:49 -0400

Technically, per-call behavior COULD be useful to call 
progress tones too.

When I call France from the US using the PSTN I hear French
call progress tones.  IF your goal is to emulate the PSTN,
you'd need per-call progress tones.  (In this sense, it's
exactly the same as the M.1 digit reading.)

I have no strong opinion on which way to go with Annex M.1.
Consider this post and my previous one in this thread
observational.

-troy