Subject: Re: Announcement Package

From: CHATRAS Bruno FTRD/DAC/ISS <[email-masked]>
Date: Thu, 2 Nov 2000 14:39:27 +0100

I agree, one call always extend the package. The danger is that each vendor
extends this package with its own definitions.

I have noticed that there is a similar situation with the "Tone Detection
Package". However, in this case, Annex E also defines a "standard" extended
package (Call Progress Tones Detection package") to ensure that the most
commonly used tones are coded the same way.

I think we should do the same for the announcements (i.e. add a "standard"
extended package in Annex K).

> -----Message d'origine-----
> De : Christian Groves [mailto:[email-masked]]
> Envoyé : mercredi 1 novembre 2000 00:22
> À : CHATRAS Bruno FTRD/DAC/ISS
> Cc : [email-masked]
> Objet : Re: Announcement Package
> 
> 
> G'Day Bruno,
> 
> As defacto editor for this (the 2 that started with it have moved on
> from their companies) I think the reason for the loose 
> specification was
> to allow for a very Generic / Flexible announcement server
> functionality. ie, we didn't want to specify in a package that price,
> date etc is included when all the announcement server does in your
> implementation is to say "busy".
> 
> You can always extend the package definition to include values for the
> parameters. 
> ie. IN_Generic_Announcement_Server Package
> extends Generic Announcement_Server
> Additional values: data, telephone number
> 
> Cheers, Christian
> 
> CHATRAS Bruno FTRD/DAC/ISS wrote:
> > 
> > Hi,
> > 
> > I have a question about the use of specific parameters in 
> announcements
> > (Generic Announcement Package). The "Specific parameters 
> intepretation"
> > parameter is currently defined a an enumerated type. 
> However the possible
> > values for this enumaration are specified as "any". Hence, 
> there is no
> > standard solution for the encoding of the most commonly 
> used types of
> > variables (date, telephone number, ...). Does it mean that 
> this capability
> > (variable announcements) will always require additional 
> specifications
> > before being used between MGs and MGCs from different vendors ?
> > 
> > One possible approach to ease interoperability would have 
> been to define a
> > coding for the most commonly used types of parameters. For example:
> > Specific parameters interpretation
> >         ParameterID:    spi (0x0005)
> >         Type: enumeration
> >         Possible values are: "telephone" (0x00), "date" 
> (0x01),"time"
> > (0x02),"price" (0x03), others
> >                                 "telephone" represents a 
> telephone number as
> > a string of hexadecimal digits.
> >                                 "date" represents a date as 
> a string of
> > hexadecimal digits in the format YYMMDD
> >                                 "time" represents a time as 
> a string of
> > hexadecimal digits in the format HHMMSS
> > 
> >                          "price" represents a price in 
> 1/100 of currency
> > units.
> > 
> > Is there any reason why this was not specified like that ?
> > 
> > Note: There is no reference to the "price" variable in the 
> list of examples
> > provided in the "procedures" section. However thist type of 
> variable has
> > become widely used with prepaid services.
>