Subject: Re: MEGACO Requirements for Voice Enabled Gateways

From: David Cromwell <[email-masked]>
Date: Mon, 11 Oct 1999 16:22:06 -0400

> As promised, here is the revised IVR/ARF section proposal .
>
> 11.2.9.  Audio Resource Function
>
> The Audio Resource Function (ARF) consists of a number of functional
> modules
> which can be deployed on an Audio Server or on a gateway, for example
> on a line gateway.  Such a gateway is known as an Audio Enabled Gateway
> (AEF).
> The following modules have been identified:
>
>    Play Audio
>    DTMF Collect
>    Record Audio
>    Audio Conferencing
>    Speaker Verification
>    Voice Recognition
>
> Other modules may be added as required.  A scripting requirement for the
> ARF
> would involve ARF-controlling extensions to basic scripting packages.
>
> To support an Audio Server or Media Gateway that implements one or more
> Audio
> Resource Function modules, the Protocol must do the following for each
> module
> it supports.
>
> 11.2.9.1 Play Audio Module
>
> a.   Be able to provide the following basic operation:
>
> -    request an ARF MG to play an announcement.
>
> b.   Be able to specify these play characteristics:
>
> -    Play volume
>
> -    Play speed
>
> -    Play iterations
>
> -    Interval between play iterations
>
> -    Play duration
>
> c.   Provide a base set of voice variables including date, digits, dura-
>      tion, money, month, number, silence, string, display text, text to
>      voice, time, generated tone, and weekday.  Given a variable type
>      and value, the IVR MG must dynamically assemble the phrases
>      required for its playback.  For example, given a type of "US
>      Currency" and a value of "1995," the IVR MG should play "Nineteen
>      dollars and ninty-five cents."
>
> d.   Using the terminology that a segment is a discrete unit of playable
>      speech, support these types of segments:
>
> -    A provisioned recording.
>
> -    A block of text to be converted to speech.
>
> -     A block of text to be displayed on a device.
>
> -    A length of silence to be played.
>
> -    An algorithmically generated tone.
>
> -    A voice variable, specified by type and value.  Given a variable
>      type and value, the IVR would dynamically assemble the phrases
>      required for its playback.
>
> -    A provisioned sequence of segments, referenced by a single unique
>      id.
>
> -    A provisioned set of segments, referenced by unique id and a selec-
>      tor specifying a particular segment in the set.
>
> e.   Provide two different methods of audio specification:
>
> -    Direct specification of the audio components to be played by speci-
>      fying the sequence of segments in the command itself.
>
> -    Indirect specification of the audio components to be played by
>      reference to a single identifier that resolves to a provisioned
>      sequence of audio segments.
>
> The terminology of sequence and set can be used with segments.
>
> A sequence is a provisioned sequence of one or more audio segments. Com-
> ponent segments are not necessarily all of the same type.  Every
> sequence is assigned a unique segment id.  On playback, a sequence id
> reference is deconstructed into its individual parts, each of which is
> played in order.
>
> A set is a provisioned collection of audio segments with an associated
> selector. On playback, the selector value is resolved to a particular
> set element. Selector types need not be defined in the protocol itself,
> but may be defined by the user.  Some examples of selector types that a
> user might define are: language, codec, audio file format, gender,
> accent, customer, and voice talent.
>
> f.   Using the above set and sequence terminology, provide for the fol-
>      lowing uses of segments:
>
> -    Sequences of heterogeneous segments
>
> -    Nesting of sequences
>
> -    Nesting of sets.
>
> -    Nesting of sets with in sequences and sequences within sets.
>
> -    Use of set selectors to implement properties such as language,
>      codec, audio format, voice talent, customer, gender, accent, etc.
>
> The Protocol need not support the following:
>
> g.   While inflection  (rising, flat, and falling) must be supported by
>      the IVR MG, specification of inflection is outside the scope of
>      this protocol.
>
> h.   Be able to support an IVR unit that provides text-based and/or
>      web-based prompts instead of audio-based prompts.
>
>
> 11.2.9.1 DTMF Collect Module
>
> The DTMF Collect Module must support all of the requirements in the Play
> Module
> in addition to the following requirements:
>
> a.   Be able to provide the following basic operation:
>
> -    request an Audio Server or AEG MG to play an announcement and then
>      collect DTMF
>
> b.   Be able to specify these event collection characteristics:
>
> -    The number of attempts to give the user to enter a valid DTMF pat-
>      tern.
>
> c.   With respect to digit timers, allow the specification of:
>
> -    Time allowed to enter the first digit.
>
> -    Time allowed for user to enter each digit subsequent to the first
>      digit.
>
> -    Time allowed for user to enter a digit once the maximum expected
>      number of digits has been entered.
>
> d.   To be able to allow multiple prompt operations for digit collection
>      and voice recording, provide the following types of prompts:
>
> -    Initial Prompt
>
> -    Reprompt
>
> -    Error prompt
>
> -    Failure announcement
>
> -    Success announcement.
>
> e.   To allow digit pattern matching, allow the specification of:
>
> -     maximum number of digits to collect.
>
> -     minimum number of digits to collect.
>
> -    a digit pattern using a regular expression.
>
> f.   To allow digit buffer control, allow the specification of:
>
> -    Ability to clear digit buffer prior to playing initial prompt
>      (default is not to clear buffer).
>
> -    Default clearing of buffer following playing of uninterruptible
>      announcement segment.
>
> -    Default clearing of buffer before playing a re-prompt in response
>      to previous invalid input.
>
> g.   Allow the specification of definable key sequences for digit
>      collection to:
>
> -    Discard collected digits in progress, replay the prompt,
>      and resume digit collection.
>
> -    Discard collected digits in progress and resume digit
>      collection.
>
> -    Terminate the current operation and return the terminating key
>      sequence to the MGC.
>
> h.   Provide a way to ask the ARF MG to support the following definable
>      keys for digit collection and recording. These keys would then be
>      able to be acted upon by the ARF MG:
>
> -    A key to terminate playing of an announcement in progress.
>
> -    A set of one or more keys that can be accepted as the first digit
>      to be collected.
>
> -    A key that signals the end of user input.  The key may or may not be
>      returned to the MGC along with the input already collected.
>
> -    Keys to stop playing the current announcement and resume playing at
>      the beginning of the first segment of the announcement, last seg-
>      ment of the announcement, previous segment of the announcement,
>      next segment of the announcement, or the current announcement seg-
>      ment.
> 11.2.9.1 Record Audio Module
>
> The Record Module must support all of the requirements in the Play Module
> as
> in addition to the following requirements:
>
> a.   Be able to provide the following basic operation:
>
> -    request an Audio Server or AEG MG to play an announcement and then
> record
>      voice.
>
> b.   Be able to specify these event collection characteristics:
>
> -    The number of attempts to give the user to make a recording.
>
> c.   With respect to recording timers, allow the specification of:
>
> -    Time to wait for the user to initially speak.
>
> -    The amount of silence necessary following the last speech segment
>      for the recording to be considered complete.
>
> -    The maximum allowable length of the recording  (not including pre-
>      and post- speech silence).
>
> d.   To be able to allow multiple prompt operations for digit collection
>      and voice recording, provide the following types of prompts:
>
> -    Initial Prompt
>
> -    Reprompt
>
> -    Error prompt
>
> -    Failure announcement
>
> -    Success announcement.
>
>
> e.   Allow the specification of definable key sequences for digit
>      recording to:
>
> -    Discard recording in progress, replay the prompt, and resume
> recording.
>
> -    Discard recording in progress and resume recording.
>
> -    Terminate the current operation and return the terminating key
>      sequence to the MGC.
>
> f.   Provide a way to ask the ARF MG to support the following definable
>      keys for recording. These keys would then be able to be acted upon by
>
>      the ARF MG:
>
> -    A key to terminate playing of an announcement in progress.
>
> -    A key that signals the end of user input.  The key may or may not be
>      returned to the MGC along with the input already collected.
>
> -    Keys to stop playing the current announcement and resume playing at
>      the beginning of the first segment of the announcement, last seg-
>      ment of the announcement, previous segment of the announcement,
>      next segment of the announcement, or the current announcement seg-
>      ment.
>
> g.   While audio prompts are usually provisioned in IVR MGs, support
>      changing the provisioned prompts in a voice session rather than a
>      data session.  In particular, with respect to audio management:
>
> -    A method to replace provisioned audio with audio recorded during a
>      call. The newly recorded audio must be accessible using the iden-
>      tifier of the audio it replaces.
>
> -    A method to revert from replaced audio to the original provisioned
>      audio.
>
> -    A method to take audio recorded during a call and store it such
>      that it is accessible to the current call only through its own
>      newly created unique identifier.
>
> -    A method to take audio recorded during a call and store it such
>      that it is accessible to any subsequent call through its own newly
>      created identifier.
>
>
> 11.2.9.1 Audio Conferencing Module
>
> The protocol must support:
>
> a.   a mechanism to create multi-point conferences of audio only and
>      multimedia conferences in the MG.
>
> b.   audio mixing; mixing multiple audio streams into a new composite
>      audio stream
>
> c.   audio switching; selection of incoming audio stream to be sent out
>      to all conference participants.
>
> d.   additional requirements to be defined.
>
>
> 11.2.9.1 Speaker Verification Module
>
> The protocol must support:
>
> a.   requirements to be defined.
>
>
> 11.2.9.1 Voice Recognition Module
>
> The protocol must support:
>
> a.   requirements to be defined.
>
>
> 11.2.10.  Multipoint Control Units
>
> (This section is unchanged.  The MCU needs to be able to do audio
> conferencing
> in the context of multimedia conferencing.)
>
> --
> [email-masked]
> Nortel Networks
> ESN:            351-8870
> 35 Davis Dr
> Public:    919-991-8870
> RTP, NC 27709
>
> -----Original Message-----
> From: Cromwell, David [NCRTP:B933:EXCH]
> Sent: Thursday, October 07, 1999 3:08 PM
> To:   [email-masked]'
> Subject:      Re: MEGACO Requirements for Voice Enabled Gateways
>
> I agree that requirements for Voice Enabled Gateways is something we've
> overlooked, and the VEG proposal introduces some important new
> requirements, Speaker Verification for example.
>
> For a protocol requirements document though, the proposed wording seems to
> me to in places speculate too much about specific architectures and to be
> lacking in functional detail in other places.  Since there is a very large
> overlap between the requirements for a VEG and the requirements documented
> for IVR in Section 11.2.9,  I propose that Section 11.2.9 be
> restructured/reorganized into separate functional modules for DTMF
> Collection, Voice Recording, Voice Recognition, Conferencing, etc. rather
> than have a separate section for VEG requirements.  Modules could be
> added, e.g. for Speaker Verification, as the functional requirements
> become clearer.  An Audio Server would probably implement a large number
> of these modules whereas a VEG might fewer modules.
>
> While the term IVR has been useful because it is well understood as a
> specific set of functions (play, collect, record), I'd like to suggest a
> broader term, perhaps Audio Resource Function (ARF), which would cover
> things like audio conferencing as well as what we traditionally think of
> as IVR.  I also suggest the name Audio Enhanced Gateway (AEG) or Audio
> Resource Gateway (ARG) rather than Voice Enhanced Gateway(VEG) for the
> same reasons.
>
> I'll come up with a proposal in the next day or so for a revised IVR/ARF
> section which will include requirements from the VEG proposal and which
> will incorporate the audio conferencing requirements in Section 11.2.10 on
> the grounds that audio conferencing will likely be implemented on Audio
> Servers long before multimedia conferencing is widely implemented.
>
> Comments are interspersed below.
>
> David
> --
> [email-masked]
> Nortel Networks
> ESN:            351-8870
> 35 Davis Dr
> Public:    919-991-8870
> RTP, NC 27709
>
>
>  Michael A. Ramalho writes:
>
>       >Megacoers,
>
>       >As the MEGACO requirement document nears last-call, it occurred to
> me
>       >that Voice Enabled Gateways (VEGs) were not included in the
> requirements.
>
> Agreed!
>
>       >A Voice Enabled Gateway (VEG) is a MG that typically utilizes the
> DSPs in
>       >the gateways to perform particular signal processing related task.
> For example,
>       >speaker verification, speech/audio recognition and speech/audio
> feature extraction
>       >can be performed on the DSP resources typically found in MGs.
> Although VEGs
>       >can be deployed in stand-alone units (as virtually all are today)
> they can be
>       >implemented a normal voice MG that has VEG capabilities for a
> subset of its ports.
>
> The protocol should be independent of a particular architecture.
>
>       >While Voice Enabled Gateways have some overlap to the IRV system
> requirements
>       >in Section 11.2.9, they have some additional requirements as well.
> For example, a
>       >speaker identification task might require the ability to download
> speaker templates
>       >during mid-call.
>
> Downloading of templates mid-call is specific to speaker recognition and
> would be part of the Speaker Recognition module.  Additional requirements
> that do not overlap with the IVR requirements can be handled with separate
> modules.
>
>       >I believe that VEGs can easily be handled as an extension of the
> MEGACO protocol
>       >via a VEG package.
>
> Agreed that they can be handled as an extension of the MEGACO protocol.
>
>       >I have suggested the following words for inclusion in the MEGACO
> requirements
>       >if no one has objection to it's inclusion.
>
>       >Please feel free to comment on the VEG proposal or to suggest a
> better description.
>       >I'd like to hear from you.
>
>       >Regards,
>
>       >Michael Ramalho
>
>       >****PROPOSED REQUIREMENTS WORDING********
>
>       >11.2.X Voice Enabled Gateway (VEG) Support
>
>       >A Voice Enabled Gateway (VEG) is a MG that utilizes processing
> resources in the
>       >gateways to perform particular auditory signal processing related
> tasks. For example,
>       >speaker verification, speech/audio recognition and speech/audio
> feature extraction can
>       >be performed on the DSP resources typically found in MGs. These
> specialized signal
>       >processing tasks will likely require application specific programs
> executing in the MG
>       >and a mechanism for signaling between these programs and other
> network servers that
>       >support VEGs.
>
>       >A VEG can be implemented as a normal voice MG that has VEG
> capabilities for a
>       >subset of its ports (i.e., the VEG should not be thought of as a
> stand-alone function,
>       >as most IVRs are today). The ability to dynamically download
> particular parameters
>       >during mid-call is a VEG requirement (e.g., speaker templates for
> speaker identification).
>       >As some VEGs functions are yet to be deployed or even implemented,
> a full set of
>       >requirements is not available at this time..
>
>       >Like the IVR Unit described in Section 11.2.9, it is envisioned
> that a scripting
>       >requirement for the VEG would involve VEG-controlling extensions to
> basic scripting
>       >packages.
>
>       >To support the MGs functioning as VEGs, the protocol must:
>
>       >a.     Allow VEG scripting similar to the scripting requirements of
> the IVR Unit (Section 11.2.9).
>
> Agreed.
>
>       >b.     Allow download of VEG-specific applications programs.
>
>       This goes a quite bit beyond scripting.  I would argue that binary
> executables should be resident on the node where they will be executed and
> not downloaded on the fly.  I would also make the argument that
> application code belongs on the gatekeeper, not the gateway.  In any event
> whether or not we allow this is a question for the protocol as a whole and
> not just the Audio Resource Function part.
>
>       >c.     Allow mid-call download of VEG specific parameters.
>
> As part of a specific functional module, as required.
>
>       >d.     Allow specialized signaling from the VEG applications to the
> VEG supporting servers.
>
> Maybe this is desirable, but I don't see that this is a requirement on the
> MEGACO protocol which is strictly a gatekeeper to gateway, client server
> protocol.
>
>       >****END PROPOSED REQUIREMENTS WORDING********
>       >Michael A. Ramalho, Ph.D.
>       >Cisco Systems
>       >Wall Township, NJ
>       >Office email: [email-masked]
>       >Personal email: [email-masked]
>       >Office: +1.732.449.5762
>       >Cell: +1.732.809.0188 <-NEW!
>
>
>

---

From: David Cromwell <[email-masked]>
Date: Mon, 11 Oct 1999 15:04:12 -0400

> [<DC>]  The original email I sent Friday bounced.  I'll be posting the
> revised section shortly.
>
> >As the MEGACO requirement document nears last-call, it occurred to me
> >that Voice Enabled Gateways (VEGs) were not included in the requirements.
>
> Agreed!
>
> >A Voice Enabled Gateway (VEG) is a MG that typically utilizes the DSPs in
> >the gateways to perform particular signal processing related task. For
> example,
> >speaker verification, speech/audio recognition and speech/audio feature
> extraction
> >can be performed on the DSP resources typically found in MGs. Although
> VEGs
> >can be deployed in stand-alone units (as virtually all are today) they
> can be
> >implemented a normal voice MG that has VEG capabilities for a subset of
> its ports.
>
> >in Section 11.2.9, they have some additional requirements as well. For
> example, a
> >speaker identification task might require the ability to download speaker
> templates
> >during mid-call.
>
> >I believe that VEGs can easily be handled as an extension of the MEGACO
> protocol
> >via a VEG package.
>
> >Please feel free to comment on the VEG proposal or to suggest a better
> description.
> >A Voice Enabled Gateway (VEG) is a MG that utilizes processing resources
> in the
> >gateways to perform particular auditory signal processing related tasks.
> For example,
> >speaker verification, speech/audio recognition and speech/audio feature
> extraction can
> >and a mechanism for signaling between these programs and other network
> servers that
> >support VEGs.
>
> >A VEG can be implemented as a normal voice MG that has VEG capabilities
> for a
> >as most IVRs are today). The ability to dynamically download particular
> parameters
> >during mid-call is a VEG requirement (e.g., speaker templates for speaker
> identification).
> >As some VEGs functions are yet to be deployed or even implemented, a full
> set of
> >Like the IVR Unit described in Section 11.2.9, it is envisioned that a
> scripting
> >requirement for the VEG would involve VEG-controlling extensions to basic
> scripting
> >packages.
>
> >a.   Allow VEG scripting similar to the scripting requirements of the IVR
> Unit (Section 11.2.9).
>
> Agreed.
>
> >d.   Allow specialized signaling from the VEG applications to the VEG
> supporting servers.
>

---

From: David Cromwell <[email-masked]>
Date: Mon, 11 Oct 1999 10:55:27 -0400

---

From: David Cromwell <[email-masked]>
Date: Mon, 11 Oct 1999 11:03:50 -0400

As promised, here is the revised IVR/ARF section.

The Audio Resource Function (ARF) consists of a number of functional modules
which can be deployed on an Audio Server or on a gateway, for example
on a line gateway.  Such a gateway is known as an Audio Enabled Gateway
(AEF).
The following modules have been identified:

   Play Audio
   DTMF Collect
   Record Audio
   Audio Conferencing
   Speaker Verification
   Voice Recognition

Other modules may be added as required.  A scripting requirement for the ARF

-    Play volume

-    Play speed

-    Play iterations

-    Play duration

-    Nesting of sequences

-    Nesting of sets.

-    Initial Prompt

-    Reprompt

-    Error prompt

-    Failure announcement

-    Success announcement.

The Record Module must support all of the requirements in the Play Module as

-    Initial Prompt

-    Reprompt

-    Error prompt

-    Failure announcement

-    Success announcement.

-    Discard recording in progress, replay the prompt, and resume recording.

--
[email-masked]                                          Nortel
Networks
ESN:            351-8870
35 Davis Dr
Public:    919-991-8870
RTP, NC 27709

>               >the gateways to perform particular signal processing
> related task. For example,
>               >speaker verification, speech/audio recognition and
> speech/audio feature extraction
>               >can be performed on the DSP resources typically found in
> MGs. Although VEGs
>               >can be deployed in stand-alone units (as virtually all are
> today) they can be
>               >implemented a normal voice MG that has VEG capabilities for
> a subset of its ports.
>
>               >While Voice Enabled Gateways have some overlap to the IRV
> system requirements
>               >in Section 11.2.9, they have some additional requirements
> as well. For example, a
>               >speaker identification task might require the ability to
> download speaker templates
>               >during mid-call.
>
>               >I believe that VEGs can easily be handled as an extension
> of the MEGACO protocol
>               >via a VEG package.
>
>               >I have suggested the following words for inclusion in the
> MEGACO requirements
>               >Please feel free to comment on the VEG proposal or to
> suggest a better description.
>               >A Voice Enabled Gateway (VEG) is a MG that utilizes
> processing resources in the
>               >gateways to perform particular auditory signal processing
> related tasks. For example,
>               >speaker verification, speech/audio recognition and
> speech/audio feature extraction can
>               >be performed on the DSP resources typically found in MGs.
> These specialized signal
>               >processing tasks will likely require application specific
> programs executing in the MG
>               >and a mechanism for signaling between these programs and
> other network servers that
>               >support VEGs.
>
>               >subset of its ports (i.e., the VEG should not be thought of
> as a stand-alone function,
>               >as most IVRs are today). The ability to dynamically
> download particular parameters
>               >during mid-call is a VEG requirement (e.g., speaker
> templates for speaker identification).
>               >As some VEGs functions are yet to be deployed or even
> implemented, a full set of
>               >Like the IVR Unit described in Section 11.2.9, it is
> envisioned that a scripting
>               >requirement for the VEG would involve VEG-controlling
> extensions to basic scripting
>               >packages.
>
>               >a.     Allow VEG scripting similar to the scripting
> requirements of the IVR Unit (Section 11.2.9).
>
> Agreed.
>
>               >d.     Allow specialized signaling from the VEG
> applications to the VEG supporting servers.
>

---

From: David Cromwell <[email-masked]>
Date: Tue, 12 Oct 1999 14:51:00 -0400

> Resource Gateway (ARG) rather than Voice Enhanced Gateway(VEG) for the
What follows is an alternate proposal for a revised section 11.2.9.  The
opening paragraph notes that the IVR/ARF functionality could be implemented
on an Audio Server or a Voice Enabled Gateway, but does not go into any
further architectural specifics.  I've also the audio conferencing
requirements in Section 11.2.10 on the grounds that audio conferencing will
likely be implemented on Audio Servers long before multimedia conferencing
is widely implemented.

> David
****************************************************************************
***********************

   Play Audio
   DTMF Collect
   Record Audio
   Audio Conferencing
   Speaker Verification
   Voice Recognition

-    Play volume

-    Play speed

-    Play iterations

-    Play duration

-    Nesting of sequences

-    Nesting of sets.

-    Initial Prompt

-    Reprompt

-    Error prompt

-    Failure announcement

-    Success announcement.

-    Initial Prompt

-    Reprompt

-    Error prompt

-    Failure announcement

-    Success announcement.

****************************************************************************
***********************

---

From: Nancy-M Greene <[email-masked]>
Date: Wed, 13 Oct 1999 13:08:00 -0400

There has been some discussion on the proposed 11.2.9 section which I will
summarize here (you can find it in draft-ietf-megaco-protocol-07.txt).
Basically, it  did not capture the  feature extraction requirement proposed
in Michael Ramalho's VEG msg.

As David says, section 11.2.9 was renamed Audio Resource Function, and
reorganized in draft-ietf-megaco-protocol-07.txt to describe requirements
for these modules:
Play Audio
DTMF Collect
Record Audio
Audio Conferencing

Draft reqs-07 also has two new modules :
Speaker Verification, and
Voice Recognition (Need to rename this Speech/Audio Recognition)

And we missed out Michael Ramalho's requirement for feature extraction. I
could add the following modules:
Auditory Feature Extraction, and
Auditory Feature Recognition.

My question is: what do we put for requirements for these last 4? Do we
leave them blank? Or should we group them together and say the following in
section 11.2.9 just before 11.2.9.1 :

"With this organization of the Audio Resource Function, new modules could be
added to cover Speaker Verification, Speech/Audio Recognition, Auditory
Feature Extraction, and Auditory Feature Recognition. When requirements are
clearer for these modules, they may be added at a later date."

Then we would remove sections 11.2.9.5 and 11.2.9.6.

Nancy

--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

---

From: Nancy-M Greene <[email-masked]>
Date: Tue, 12 Oct 1999 22:27:59 -0500

Nancy