Internet DRAFT - draft-cromwell-navdec-media-req
draft-cromwell-navdec-media-req
Internet Engineering Task Force D. Cromwell
INTERNET DRAFT M. Durling
File: draft-cromwell-navdec-media-req-00.txt Nortel Networks
Date: November 1998
Requirements For Control Of A Media Services Function
<draft-cromwell-navdec-media-req-00.txt>
Status of this Document
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document describes the functional requirements for protocol used
by a call processing agent in a packet network to control an media
services function located in the same packet network or at the inter-
face of the packet network and the traditional telephone network. The
primary focus of the protocol is on audio, however the protocol could
be extended in the future to support other media streams such as
video.
The protocol provides the standard audio operations of play audio,
collect DTMF, and record speech. It supports direct references to
simple audio as well as indirect references to simple and complex
audio. It provides multi-language audio variables, interruptibility
of audio, digit buffer control, special key sequences, and support
for reprompting during data collection.
Cromwell, Durling expires May 1999 [Page 1]
INTERNET DRAFT Media Services Control November 1998
The approach used in specifying protocol functionality was to look at
several existing protocols currently in use in the telephone network,
taking the best concepts from each and attempting to avoid any limi-
tations. The following protocols were examined: ITU CS1-R [2], Nor-
tel Extended CS1-R [3], Bellcore GR-1129 [4], and Bellcore SR-3511
[5]. The protocol described in this document provides at a minimum a
superset of the functionality of these protocols.
Cromwell, Durling expires May 1999 [Page 2]
INTERNET DRAFT Media Services Control November 1998
Table of Contents
1. Notation
2. Segments
2.1. Terminology
2.2. Segment Types
3. Variables
3.1. Specification
3.2. Inflection
3.3. Variable Types
3.4. Date
3.5. Digits
3.6. Duration
3.7. Money
3.8. Month
3.9. Number
3.10. Silence
3.11. String
3.12. Text
3.13. Time
3.14. Tone
3.15. Weekday
4. Operations
4.1. Play Operation
4.1.1. Announcements
4.1.2. Iterations
4.1.3. Duration
4.1.4. Speed
4.1.5. Volume
4.1.6. Optional Parameters
4.1.7. Return Values
4.1.8. Examples
4.2. Play Collect Operation
4.2.1. Announcements
4.2.2. Speed
4.2.3. Volume
4.2.4. Interruptibility
4.2.5. Digit Buffer Control
4.2.6. Pattern Matching
4.2.7. Timers
4.2.8. Key Definitions
4.2.9. Number Of Attempts
4.2.10. Optional Parameters
4.2.11. Return Values
4.2.12. Examples
4.3. Play Record Operation
Cromwell, Durling expires May 1999 [Page 3]
INTERNET DRAFT Media Services Control November 1998
4.3.1. Announcements
4.3.2. Speed
4.3.3. Volume
4.3.4. Interruptibility
4.3.5. Digit Buffer Control
4.3.6. Timers
4.3.7. Key Definitions
4.3.8. Optional Parameters
4.3.9. Return Values
4.3.10. Examples
5. Other Requirements
5.1. Invoke Application
5.2. Audio Management
6. Open Issues
7. Implementation
8. References
9. Author's Address
Notation
Protocol operations are represented in this document by pseudo code.
These representations are not intended to imply an actual implementa-
tion syntax and are for purposes of illustration only.
1. Segments
1.1. Terminology
A discrete unit of playable speech can be classified as a fragment, a
segment, or an announcement. A fragment is the smallest unit and
typically consists of one or more phonemes, e.g. "\w\, the first
sound in "welcome." A segment can be either composed of a series of
fragments or defined atomically and typically consists of one or more
words, e.g. "Welcome" or "Welcome to." An announcement is composed
of one or more segments and typically embodies a complete logical
expression, e.g. "Welcome to Bell South's Automated Directory Assis-
tance Service." It is possible for an announcement to be defined as
a single segment. In this document "announcement" is a logical con-
cept while "segment" refers to actual audio.
Media operations supported by the protocol should reference announce-
ments. Announcements should be specifiable either as a sequence of
segment id's given as a parameter to a media output operation or as a
sequence of segment id's provisioned in data and referenced by a
Cromwell, Durling expires May 1999 [Page 4]
INTERNET DRAFT Media Services Control November 1998
single identifier. This identifier can be used as a parameter to a
media output operation. Allowing both parameter driven and data
driven specification of announcements provides application designers
a great deal of flexibility when choosing an application and provi-
sioning model.
In practice however, the majority of references made by a call pro-
cessing agent will likely be to a single segment which is a logically
complete pre-recorded announcement, e.g. play(27), where segment 27
points to a recording of "Please enter your card number after the
tone...<tone>"
1.2. Segment Types
The protocol should support following segment types:
RECORDING: A reference by unique id to a single piece of pro-
visioned audio.
TEXT: A reference to a block of text to be converted to speech
or to be displayed on a device. Reference may be by unique id
to a block of provisioned text or by direct specification of
text in a parameter.
SILENCE: A specification of a length of silence to be played in
units of 100 milliseconds.
TONE: The specification of a tone to be played by algorithmic
generation. Most tones however will probably be recorded, not
generated. Exact specification of this segment type is tbd.
VARIABLE: The specification of a multilanguage voice variable
by type, subtype, language, and value. Specification of vari-
ables is considered in more detail in a subsequent section of
this document.
COMPOSITE: A reference by unique id to a provisioned sequence of
mixed recording, text, silence, tone, variable, or composite
segments.
Recursive definition of composite segments should be allowed.
For example composite A could have as one of its elements compo-
site B which has as one of its elements composite C. However
this feature should be used with caution give the additional
complexity it introduces.
Direct or transitive definition of a composite segment in terms
Cromwell, Durling expires May 1999 [Page 5]
INTERNET DRAFT Media Services Control November 1998
of itself must not be permitted, e.g. composite A having as one
of its elements composite B, which has as one of its elements
composite A.
2. Variables
2.1. Specification
Variables should be specified by type, subtype, language, and value.
Subtype is a refinement of type. For example the variable type Money
might have an associated range of subtypes such as Dollar, Rupee,
Dinar, etc. Not all variables require a subtype, and for these vari-
ables the subtype parameter should be set to null.
ISO standard 639, Code For The Representation Of Names Of Languages
[6], lists the names of many languages and should be used as a start-
ing point in defining the range of available languages. A small
excerpt from ISO 639 follows:
_________________
|Code | Language |
|_____|__________|
| cs | Czech |
| cy | Welsh |
| da | Danish |
|_____|__________|
Note that ISO 639 is not a complete list. For example the standard
includes Chinese but does not mention the Mandarin or Cantonese
dialects.
In some cases it may be desirable to play an announcement with an
embedded variable without playing the variable itself. If the value
for a variable is NULL, the variable must not be played.
2.2. Inflection
Specification of inflection is beyond the scope of this protocol,
however a media services function should support rising, flat, and
falling inflections as appropriate.
Cromwell, Durling expires May 1999 [Page 6]
INTERNET DRAFT Media Services Control November 1998
2.3. Variable Types
The protocol should support the following multilanguage voice vari-
ables and should be extensible to support additional variable types.
A list of supported variables follows:
______________________________
|Type | Subtype |
|_________|___________________|
|DATE | none |
| | |
|_________|___________________|
|DIGITS | GENERIC |
| | NORTH AMERICAN DN |
|_________|___________________|
|DURATION | none |
| | |
|_________|___________________|
| | |
|MONEY | currency_type |
|_________|___________________|
|MONTH | none |
| | |
|_________|___________________|
|NUMBER | CARDINAL |
| | ORDINAL |
|_________|___________________|
|SILENCE | none |
| | |
|_________|___________________|
|STRING | none |
|_________|___________________|
|TEXT | DISPLAY |
| | SPEECH |
| | |
|_________|___________________|
|TIME | TWELVEHOUR |
| | TWENTYFOURHOUR |
|_________|___________________|
|TONE | none |
|_________|___________________|
|WEEKDAY | none |
|_________|___________________|
Cromwell, Durling expires May 1999 [Page 7]
INTERNET DRAFT Media Services Control November 1998
2.4. Date
Speaks a date. For example "101598" is spoken as "October fifteenth
nineteen ninety eight."
2.5. Digits
Speaks a string of digits one at a time. If the subtype is North
American DN, the format of which is NPA-NXX-XXXX, the digits are spo-
ken with appropriate pauses between the NPA and NXX and between the
NXX and XXXX. If the subtype is generic, the digits are spoken no
pauses.
2.6. Duration
Duration is specified in seconds and is spoken in one or more units
of time as appropriate, e.g. "3661" is spoken as "One hour, one
minute, and one second."
2.7. Money
Money is specified in the smallest units of a given currency and is
spoken in one or more units of currency as appropriate, e.g. "110" in
U.S. Dollars would be spoken "one dollar and ten cents." The list of
currency specified in ISO 4217, Currency And Funds Code List [7],
should be used as a starting point in defining the currency subtype.
A small excerpt from ISO 4217 follows:
__________________________________________________________
|Alpha-code | Numeric-code | Currency | Entity |
|___________|______________|__________|___________________|
|GQE | 226 | Ekwele | Equatorial Guinea |
|GRD | 300 | Drachma | Greece |
|GTQ | 320 | Quetzal | Guatemala |
|___________|______________|__________|___________________|
2.8. Month
Speaks the specified month, e.g. "October."
Cromwell, Durling expires May 1999 [Page 8]
INTERNET DRAFT Media Services Control November 1998
2.9. Number
Speaks a number in cardinal form or in ordinal form. For example,
"100" is spoken as "one hundred" in cardinal form and "one hundredth"
in ordinal form.
2.10. Silence
Plays a specified period of silence. Specification is in 100 mil-
lisecond units.
2.11. String
Speaks each character of a string, e.g. "a34bc" is spoken "A, three,
four, b, c."
2.12. Text
Produces the specified text as speech or displays it on a device.
2.13. Time
Speaks a time (specified in twenty four hour format) in either twelve
hour format or twenty four hour format. For example "1700" is spoken
as "Five pm" in twelve hour format or as "Seventeen hundred hours" in
twenty four hour format.
2.14. Tone
Plays an algorithmically generated tone, specification of which is
tbd. Probably most applications will use prerecorded tones.
2.15. Weekday
Speaks the day of the week, e.g. "Monday."
3. Operations
This section describes the functional requirements for a set of media
control operations. Three operations are defined: play, play col-
lect, and play record. Specification of endpoint, port, or channel
Cromwell, Durling expires May 1999 [Page 9]
INTERNET DRAFT Media Services Control November 1998
on a per operation basis is not a protocol requirement, however it
may be required in particular implementations.
3.1. Play Operation
The play operation should play an announcement in situations where
there is no need for interaction with the user. Because there is no
need to monitor the incoming media stream this operation is an effi-
cient mechanism for treatments, informational announcements, etc.
The play operation should specified as follows:
3.1.1. Announcements
The play operation should play an ordered sequence of one or more
segments of the following types: recording, text, silence, tone,
variable, and composite.
3.1.2. Iterations
The protocol should support specification of the maximum number of
times an announcement is to be played. It should be possible to
specify that an announcement be repeated forever, and it should also
be possible to specify a interval of silence (in 100 millisecond
units) to be inserted between announcement plays. If the number of
iterations is not specified, it should be assumed to be one (i.e. a
single play). If the inter-announcement interval is not specified,
it should be assumed to be one second.
3.1.3. Duration
The protocol should support specification of the maximum amount of
time (in 100 millisecond units) allowed to play and possibly replay
an announcement. It should be possible to specify that an announce-
ment be played forever. If duration is specified, it should take
precedence over iteration and interval. For example, if a 10 second
announcement is to be played 5 times with 2 seconds of silence
between plays, the total playing time would be 58 seconds. However,
if duration is set to 29, the announcement will only be played for 29
seconds, i.e. the entire announcement will be played twice but the
third play will be terminated after 5 seconds.
Cromwell, Durling expires May 1999 [Page 10]
INTERNET DRAFT Media Services Control November 1998
3.1.4. Speed
The relative playback speed of the announcement should be specifiable
as a percentage variation from the normal playback speed. This ini-
tial setting should apply to the entire playing of the announcement
and should not be changeable. The normal playback speed and the
range of change allowed is implementation dependent.
3.1.5. Volume
The relative playback level of an announcement. should be specifiable
as an percentage variation from the normal playback level. This ini-
tial setting should apply to the entire playing of the announcement
and should not be changeable. The normal volume and the amount of
change allowed is implementation dependent.
3.1.6. Optional Parameters
All parameters to the play operation except the announcement parame-
ter are optional. Certain parameters default to reasonable values.
This allows the call agent to specify only the minimum set of parame-
ters it needs in a given situation. If an announcement is not speci-
fied an error will be returned to the call agent. The defaults are:
_______________________
|Parameter | Default |
|___________|__________|
|Iterations | 1 |
| Interval | 1 second |
|___________|__________|
3.1.7. Return Values
In addition to a return code that describes the outcome of a play
operation, the following information is returned:
The interrupting key sequence, if any.
If an announcement was interrupted, the length of the portion of
the announcement that was played before the interrupt.
Cromwell, Durling expires May 1999 [Page 11]
INTERNET DRAFT Media Services Control November 1998
3.1.8. Examples
Assume the following syntax:
__________________________________________________________________
| |
| play(announcement,iterations,interval,duration,speed,volume) |
|________________________________________________________________|
Play a single recording, text, or composite segment:
______________________
| |
| play(segment(5)) |
|____________________|
Play a sequence of three segments:
____________________________________________
| |
| play(segment(5),segment(6),segment(7)) |
|__________________________________________|
Play three seconds of silence:
_______________________
| |
| play(silence(30)) |
|_____________________|
Play text as speech:
___________________________
| |
| play(speech("hello")) |
|_________________________|
Display text on a device:
____________________________
| |
| play(display("hello")) |
|__________________________|
Play "Eleven dollars and fifty three cents" in English:
Cromwell, Durling expires May 1999 [Page 12]
INTERNET DRAFT Media Services Control November 1998
_________________________________________________
| |
| play(variable(MONEY,USDOLLARS,ENGLISH,1153) |
|_______________________________________________|
Specification of a variable without a subtype:
_______________________________________
| |
| play(variable(DIGITS,,HINDI,1234) |
|_____________________________________|
Play a segment followed by 1 second of silence, followed by "one,
two, three, four in Hindi, followed by another segment:
_______________________________________________________________________
| |
| play(segment(45),silence(10),variable(DIGITS,,HINDI,segment(543)) |
|_____________________________________________________________________|
The same operation as above. The sequence of segment, variable,
silence, and segment is defined in data as segment 37:
__________________________________________
| |
| play(segment(37),DIGITS,,HINDI,1234) |
|________________________________________|
Play an announcement 10% faster than normal speed and 5% softer than
normal volume:
____________________________________________
| |
| play(segment(7),speed(+10),volume(-5)) |
|__________________________________________|
Play an announcement three times with two seconds of silence between
plays:
__________________________________________________
| |
| play(segment(98),iterations(3),interval(20)) |
|________________________________________________|
The same operation as above only the operation is terminated after
twenty seconds:
Cromwell, Durling expires May 1999 [Page 13]
INTERNET DRAFT Media Services Control November 1998
________________________________________________________________
| |
| play(segment(98),iterations(3),interval(20),duration(200)) |
|______________________________________________________________|
3.2. Play Collect Operation
The play collect operation should play a prompt and collect DTMF
digits. If no digits are entered or an invalid digit pattern is
entered, the user may be reprompted and given another chance to enter
the correct digits. The play collect operation should be specified
as follows:
3.2.1. Announcements
The play collect operation should optionally play one or more
announcements, each consisting of an ordered sequence of one or more
segments of the following types: recording, text, silence, tone,
variable, and composite. All play collect announcements are optional
and some default to other announcements if they are not specified.
For example if the user fails to enter any digits the no digits
reprompt is played. If the no digits reprompt is undefined then the
reprompt is played. If the reprompt is undefined then the initial
prompt is played, and if the initial prompt is not defined then no
announcement is played.
This concept of cascading defaults allows the level of audio customi-
zation to decay gracefully all the way back to a single announcement
for all errors and means that applications are not forced to specify
any more announcement functionality that they need. The following
announcements should be supported for the play collect command.
Default relationships are indicated by indentation.
Cromwell, Durling expires May 1999 [Page 14]
INTERNET DRAFT Media Services Control November 1998
INITIAL PROMPT - If the initial prompt is not specified, digit
collection should begin immediately.
REPROMPT - Played after the user has made an error; asks
the user to try again. Should default to Initial prompt if
not set.
NO DIGITS REPROMPT - Played when the user has not
entered any digits. Should default to Reprompt if not
set.
FAILURE ANNOUNCEMENT - Played when the all data entry attempts
have failed.
SUCCESS ANNOUNCEMENT - Played when the operation has succeeded.
3.2.2. Speed
The relative playback speed of the announcement should be specifiable
as a percentage variation from the normal playback speed. This ini-
tial setting should apply to the playing of all announcements associ-
ated with a particular play collect operation. The normal playback
speed and the range of change allowed is implementation dependent.
3.2.3. Volume
The relative playback level of an announcement. should be specifiable
as an percentage variation from the normal playback level. This ini-
tial setting should apply to the playing of all announcements associ-
ated with a particular play collect. The normal volume and the
amount of change allowed is implementation dependent.
3.2.4. Interruptibility
The play collect operation should support interruptibility by DTMF.
A prompt is interruptible if it stops playing when the user presses a
DTMF key; if it is non-interruptible it continues to play. Interrup-
tibility should be specifiable in a protocol command on a per segment
basis.
3.2.5. Digit Buffer Control
The protocol should support the ability to clear the digit buffer
prior to playing the initial prompt. The default should be to not
Cromwell, Durling expires May 1999 [Page 15]
INTERNET DRAFT Media Services Control November 1998
clear the buffer. By default the buffer should always be cleared fol-
lowing the playing of an uninterruptible segment and before playing a
reprompt in response to invalid input.
3.2.6. Pattern Matching
The protocol should support specification of the maximum and minimum
number of digits to collect. It should support digit pattern match-
ing using extended regular expressions as supported by the Rogue Wave
Class Library [8], which supports a subset of the POSIX.2 standard
[9] for regular expressions.
3.2.7. Timers
The protocol should support the following event timers for the play
collect operation:
FIRST DIGIT - The amount of time allowed for the user to enter
the first digit. Specified in units of 100 milliseconds.
INTER DIGIT - The amount of time allowed for the user to enter
each subsequent digit. Specified units of 100 milliseconds
seconds.
EXTRA DIGIT - The amount of time to wait for a user to enter a
digit once the maximum expected amount of digits have been
entered. Specified in units of 100 milliseconds. Typically
this timer is used to wait for a terminating key in applications
where a specific key has been defined to terminate input.
This timer addresses the "# key ambiguity problem." If the
application is expecting 5 digits terminated by the # key, but
the digits are valid even if not terminated by the # key, if the
digits are sent to the call processing agent as soon as the
fifth key is entered, the # key when and if it is received is
ambiguious since it could be interpreted as a terminating key
for the digits entered previously or as something else.
3.2.8. Key Definitions
The protocol should support the following keys: 0-9,#,*,A,B,C, and D
and should provide the ability to specify the semantics of keys
received during the play collect operation as defined below. Defined
keys are processed in the following order of precedence from highest
to lowest: command keys, playcontrol keys, startinput keys, and
Cromwell, Durling expires May 1999 [Page 16]
INTERNET DRAFT Media Services Control November 1998
endinput keys. Any keys not defined should be collected.
COMMAND KEY - A key followed by a sequence of zero or more keys
that has one of the following meanings:
RESTART - Discard any digits collected, replay the prompt,
and resume collection.
REINPUT - Discard any digits collected and resume
collection.
RETURN - Terminate the current operation and any queued
operations and return the terminating key sequence to the
call processing agent.
PLAYCONTROL KEY - A key that is valid only while an announcement
is playing and has one of the following meanings. Play control
keys are never collected.
POSITION - Stop playing the current announcement and resume
playing at another position within the announcement. A play
control key can be defined to resume playing at one of the
following positions: the beginning of the first, last,
previous, next, or the current segment of the announcement.
If the announcement consists of a single segment, the first
and previous positions are equivalent to the beginning of
the announcement. The last and next positions are
equivalent to the end of the announcement.
STOP - Terminate playback of the announcement.
STARTINPUT KEYS - A set of one or more keys that are acceptable
as the first digit collected. It should be possible to specify
for each key whether interrupts a playing announcement is
ignored during a playing announcement.
ENDINPUT KEY - A key that signals the end of user input. It
should be posible to specify whether or not this key is included
in the collected digits.
The protocol should support specification of the maximum number of
times a user may use a restart key to restart the operation or use a
reinput key to re-attempt DTMF entry.
3.2.9. Number Of Attempts
The protocol should support specification of the number of times the
Cromwell, Durling expires May 1999 [Page 17]
INTERNET DRAFT Media Services Control November 1998
user can attempt to make a valid entry.
3.2.10. Optional Parameters
All parameters to the play collect operation are optional. Certain
parameters default to reasonable values. This allows the call agent
to specify only the mimimum set of parameters it needs in a given
situation. The defaults are:
________________________________
| Parameter | Default |
|___________________|___________|
| Iterations | 1 |
| Interval | 1 second |
| Clear DTMF | false |
|First digit timer | 5 seconds |
| Interdigit timer | 3 seconds |
| Start input key | 0-9 |
| End input key | # |
|Number of attempts | 1 |
|___________________|___________|
3.2.11. Return Value
In addition to a return code that describes the outcome of a play
collect operation, the following information is returned:
The interrupting key sequence, if any.
If an announcement was interrupted, the length of the portion of
the announcement that was played before the interrupt.
The number of attempts it took the user to enter a valid
sequence of DTMF keys.
The digits that were collected.
Cromwell, Durling expires May 1999 [Page 18]
INTERNET DRAFT Media Services Control November 1998
3.2.12. Examples
Assume the following syntax:
__________________________________________________________________________
| |
| play_collect(prompt_block,timer_block,key_block,pattern_block,speed, |
| volume,cleardigits,attempts) |
| |
| prompt_block = (initial_prompt,reprompt,no_digits_reprompt, |
| success_announcement,failure_announcement) |
| |
| timer_block = (first_digit,inter_digit,extra_digit) |
| |
| key_block = (command_block,playcontrol_block,startinput,endinput) |
| |
| pattern_block = (min_digits,max_digits,pattern) |
| |
|________________________________________________________________________|
Clear the digit buffer before initial prompt, play 5% faster than
normal speed, 2 percent less than normal volume, and give the user
three attempts to enter some valid data:
___________________________________________________________________________
| |
| play_collect(prompt_block,timer_block,key_block,speed(+5),volume(-2), |
| cleardigits(TRUE),attempts(3)) |
|_________________________________________________________________________|
Prompt block with only an initial prompt defined:
_________________________________________
| |
| prompt_block = (initial_prompt(87)) |
|_______________________________________|
Prompt block with all prompts defined:
______________________________________________________________________
| |
| prompt_block = (initial_prompt(87),reprompt(5), |
| no_digits_reprompt(419),failure_announcement(9), |
| success_announcement(18)) |
|____________________________________________________________________|
Cromwell, Durling expires May 1999 [Page 19]
INTERNET DRAFT Media Services Control November 1998
Timer block with first_digit timer set to 3 seconds and the
inter_digit timer set to 2 seconds:
___________________________________________________
| |
| timer_block = (first_digit(3),inter_digit(2)) |
|_________________________________________________|
Pattern block specifying collection of 1 to 4 digits:
___________________________________________________
| |
| pattern_block = (min_digits(1),max_digits(4)) |
|_________________________________________________|
Pattern block specifying collection of 2 digits where the first digit
is 3,4, or 5 and the second digit is any digit except 5, 6, or 7.
________________________________________________________________________
| |
| pattern_block = (min_digits(1),max_digits(2),pattern([3-5][^567])) |
|______________________________________________________________________|
Key block specifying a set of digits that are valid as the first
digit of input and also specifying that hese keys will interrupt the
current announcement. Specification of a key to end input. This key
is not included in any digits collected.
_________________________________________________________________
| |
| key_block = (command_block,playcontrol_block, |
| startinput(0-9,INTERRUPT),endinput(#,EXCLUDE)) |
|_______________________________________________________________|
Command_block specifying a restart key sequence and a return key
sequence:
____________________________________________________
| |
| command_block = ((*,76,RESTART),(*,83,RETURN)) |
|__________________________________________________|
3.3. Play Record Operation
The play record operation should play a prompt and records user
speech. If the user does not speak, the user may be reprompted and
given another chance to record. The play record operation is speci-
fied as follows:
Cromwell, Durling expires May 1999 [Page 20]
INTERNET DRAFT Media Services Control November 1998
3.3.1. Announcements
The play record operation should optionally play one or more
announcements, each consisting of an ordered sequence of one or more
segments of the following types: recording, text, silence, tone,
variable, and composite. All play record announcements are optional
and some default to other announcements if they are not specified.
For example if the user does not speak the no speech reprompt is
played. If the no speech reprompt is undefined then the reprompt is
played. If the reprompt is undefined then the initial prompt is
played, and if the initial prompt is not defined then no announcement
is played.
This concept of cascading defaults allows the level of audio customi-
zation to decay gracefully all the way back to a single announcement
for all errors and means that applications are not forced to specify
any more announcement functionality that they need. The following
announcements should be supported for the play record command.
Default relationships are indicated by indentation.
INITIAL PROMPT - If the initial prompt is not specified, digit
collection should begin immediately.
REPROMPT - Played after the user has made an error; asks
the user to try again. Should default to Initial prompt if
not set.
NO SPEECH REPROMPT - Played when the user has not
spoken. Should default to Reprompt if not set.
FAILURE ANNOUNCEMENT - Played when the all data entry attempts
have failed.
SUCCESS ANNOUNCEMENT - Played when the operation has succeeded.
3.3.2. Speed
The relative playback speed of the announcement should be specifiable
as a percentage variation from the normal playback speed. This ini-
tial setting should apply to all announcements associated with a par-
ticular play record operation. The normal playback speed and the
range of change allowed is implementation dependent.
Cromwell, Durling expires May 1999 [Page 21]
INTERNET DRAFT Media Services Control November 1998
3.3.3. Volume
The relative playback level of an announcement. should be specifiable
as an percentage variation from the normal playback level. This ini-
tial setting should apply to all announcements associated with a par-
ticular play record operation. The normal volume and the amount of
change allowed is implementation dependent.
3.3.4. Interruptibility
The play record operation should support interruptibility by DTMF. A
prompt is interruptible if it stops playing when the user presses a
DTMF key; if it is non-interruptible it continues to play. Interrup-
tibility is specifiable in a protocol command on a per segment basis.
3.3.5. Digit Buffer Control
The protocol should support the ability to clear the digit buffer
prior to playing the initial prompt. The default should be to not
clear the buffer. By default the digit buffer should always be
cleared following the playing of an uninterruptible segment, before
playing a reprompt in response to invalid input, and before beginning
a recording.
3.3.6. Timers
The protocol should support the following event timers for the play
record operation:
PRE-SPEECH - The amount of time to wait for the user to
initially speak. Specified in units of 100 milliseconds.
POST-SPEECH - The amount of silence necessary after the end of
the last speech segment for the recording to be considered
complete. Specified in units of 100 milliseconds.
TOTAL RECORDING LENGTH - The maximum allowable length of the
recording not including pre or post speech silence. Specified
in units of 100 milliseconds.
3.3.7. Key Definitions
The protocol should support the following keys: 0-9,#,*,A,B,C, and D
and should provide the ability to specify the semantics of keys
Cromwell, Durling expires May 1999 [Page 22]
INTERNET DRAFT Media Services Control November 1998
received during the play record operation as defined below. Defined
keys are processed in the following order of precedence from highest
to lowest: command keys, playcontrol keys, and endinput key.
COMMAND KEY - A key followed by a sequence of zero or more keys
that has one of the following meanings:
RESTART - Discard any recording in progress, replay the
prompt, and resume collection.
REINPUT - Discard any recording in progress and resume
collection.
RETURN - Terminate the current operation and any queued
operations and return the terminating key sequence to the
call processing agent.
PLAYCONTROL KEY - A key that is valid only while an announcement
is playing and has one of the following meanings. Play control
keys are never collected.
POSITION - Stop playing the current announcement and resume
playing at another position within the announcement. A play
control key can be defined to resume playing at one of the
following positions: the beginning of the first, last,
previous, next, or the current segment of the announcement.
If the announcement consists of a single segment, the first
and previous positions are equivalent to the beginning of
the announcement. The last and next positions are
equivalent to the end of the announcement.
STOP - Terminate playback of the announcement.
ENDINPUT KEY - A key that signals the end of user input. It
should be posible to specify whether or not this key is included
in the collected digits.
The protocol should support specification of the maximum number of
times a user may use a restart key to restart the operation or use a
reinput key to re-attempt recording.
3.3.8. Optional Parameters
All parameters to the play record operation are optional. Certain
parameters should default to reasonable values. This allows the call
agent to specify only the mimimum set of parameters it needs in a
given situation. The defaults are:
Cromwell, Durling expires May 1999 [Page 23]
INTERNET DRAFT Media Services Control November 1998
________________________________
| Parameter | Default |
|___________________|___________|
| Iterations | 1 |
| Interval | 1 second |
| Clear DTMF | false |
| Pre speech timer | 3 seconds |
|Post speech timer | 2 seconds |
| Start input key | 0-9 |
| End input key | # |
|Number of attempts | 1 |
|___________________|___________|
3.3.9. Return Values
In addition to a return code that describes the outcome of a play
record operation, the following information is returned:
The interrupting key sequence, if any.
If an announcement was interrupted, the length of the portion of
the announcement that was played before the interrupt.
The number of attempts it took the user to make a recording.
A reference to any recording that was made.
Cromwell, Durling expires May 1999 [Page 24]
INTERNET DRAFT Media Services Control November 1998
3.3.10. Examples
Assume the following syntax:
___________________________________________________________________
| |
| play_record(prompt_block,timer_block,key_block,speed,volume, |
| cleardigits,attempts) |
| |
| prompt_block = (initial_prompt,reprompt,no_speech_reprompt, |
| success_announcement,failure_announcement) |
| |
| timer_block = (pre_speech,post_speech,total_recording_length) |
| |
| key_block = (command_block,playcontrol_block,endinput) |
|_________________________________________________________________|
Clear digit buffer before initial prompt, play all announcements at
5% faster than normal speed, 2 percent less than normal volume, and
give the user only one attempt to make a recording:
__________________________________________________________________________
| |
| play_record(prompt_block,timer_block,key_block,speed(+5),volume(-2), |
| cleardigits(TRUE),attempts(1)) |
|________________________________________________________________________|
Specify an initial prompt and a reprompt:
______________________________________________
| |
| prompt_block = (initial(3),reprompt(45)) |
|____________________________________________|
Specify prespeech timer of 5 seconds and interword timer of 2
seconds:
_______________________________________________
| |
| timer_block = (prespeech(5),interword(2)) |
|_____________________________________________|
Cromwell, Durling expires May 1999 [Page 25]
INTERNET DRAFT Media Services Control November 1998
4. Other Requirements
This section describes other functional requirements related to media
control. These operations do not necessarily directly map to actual
commands in a protocol implementation.
4.1. Invoke Application
The protocol should support invocation of a custom application resid-
ing on the media services function by application id and accompanying
unstructured data block.
4.2. Audio Management
Audio recordings are temporary by default and exist only for the life
of the call. The protocol should provide the capability to change at
call time the status of a piece of audio from temporary to permanent
or from permanent to temporary.
5. Open Issues
The following issues are unresolved:
1. Support for voice recognition.
2. Specification of a dynamically generated TONE segment.
6. Implementation
Some systems may not be capable of supporting the entire protocol.
Implementations of a subset of the protocol should make every attempt
to remain logically consistent.
Cromwell, Durling expires May 1999 [Page 26]
INTERNET DRAFT Media Services Control November 1998
7. References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] ITU Recommendation Q.1218, "INAP Protocol For Support Of
Capability Set 1", April-May, 1995.
[3] Nortel CS1-R Extensions Specification, internal Nortel
document.
[4] Bellcore GR-1129-CORE, "AINGR: Switch-Intelligent
Peripheral Interface (IPI)", Issue 3, September 1977.
[5] Bellcore SR-3511, "ISCP-IP Interface Specification", Issue
2, Version 5.0, January 1997.
[6] ISO 639, "Code For The Representation Of Names Of
Languages", 1998.
[7] ISO 4217, "Currency And Funds Code List", 1981.
[8] Tools.h++ Class Reference Version 7, Rouge Wave Software
Inc., 1996.
[9] ANSI/IEEE Standard 1003.2 (Portable Operating System
Interface), Version D11.2, September 1991.
8. Author's Address
David Cromwell
Nortel Networks
Box 13010
Research Triangle Park, NC 27709
Phone: (919) 992-1373
email: cromwell@nortel.ca
Michael Durling
Nortel Networks
Box 13010
Research Triangle Park, NC 27709
Cromwell, Durling expires May 1999 [Page 27]
