ETSI TS 103 161-19 V1.1.1 (2011-10)

Technical Specification
Access, Terminals, Transmission and Multiplexing (ATTM);
Integrated Broadband Cable and Television Networks;
IPCablecom 1.5;
Part 19: IPCablecom Audio Server Protocol Specification -
MGCP option
2 ETSI TS 103 161-19 V1.1.1 (2011-10)

Reference
DTS/ATTM-003011-19
Keywords
access, broadband, cable, IP, multimedia, PSTN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 161-19 V1.1.1 (2011-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 7
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definitions and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 9
4 Void . 10
5 Technical Overview . 10
5.1 Architectural Requirements . 10
5.1.1 Call Destination . 11
5.1.2 Media Formats . 11
5.1.3 Security . 11
5.1.4 Operational Support Syste ms . 11
5.2 Announcement Definitions . 11
5.2.1 Tones . 11
5.2.2 Fixed-content Announcements . 11
5.2.3 Variable Content Announcements . 11
5.2.4 Interactive Announcements . 11
5.2.5 Naming Conventions for Endpoint Identifiers . 11
5.3 Interfaces . 12
6 Ann-1 Interface: CMS-MTA and MGC-MG . 13
6.1 CMS-MTA Interface . 13
6.1.1 Announcement List . 13
6.2 MGC-MG Interface . 14
7 Ann-2 interface: MPC-MP . 14
7.1 Introduction . 14
7.2 Audio Package Concepts . 14
7.2.1 Understanding Audio Segments . 15
7.2.2 Segment Identifiers . 15
7.2.3 Segment Life . 15
7.2.4 Nested Sets And Sequences . 16
7.2.5 Sequence Example . 16
7.2.6 Set Example . 16
7.2.7 Set With Nested Sequence Example . 17
7.3 Base Audio Package . 17
7.3.1 Abstract . 17
7.3.2 Events . 17
7.3.3 Signal Interactions . 18
7.3.4 Parameters. 18
7.3.5 Type-ahead . 21
7.3.6 Return Parameters . 22
7.3.7 Segment Descriptors . 24
7.3.8 Variable Syntax . 24
7.3.9 Variable Definitions . 25
7.3.10 Timers . 26
7.3.11 Examples . 27
7.4 Advanced Audio Package . 28
7.4.1 Abstract . 28
7.4.2 Sets. 28
ETSI
4 ETSI TS 103 161-19 V1.1.1 (2011-10)
7.4.3 Selectors . 29
7.4.4 Selector Encoding . 29
7.4.5 Variable Order . 30
7.4.6 Overrides . 30
7.4.7 Parameters. 30
7.4.8 Return Codes . 30
7.4.9 Examples . 30
7.5 Overview . 31
7.5.1 Speech Recognition Extensions to the BAU package . 31
7.5.2 Signal Interactions . 32
7.5.3 Parameters. 32
7.5.4 Type-ahead . 34
7.5.5 Return Parameters . 34
7.5.6 Grammar Descriptors . 35
7.5.7 Examples . 35
7.6 Formal Syntax Description . 36
Annex A (informative): Call Flow for Network Announcement . 42
A.1 Call Flow Details . 43
Annex B (informative): Call Flow for MTA-stored Announcement . 55
B.1 Call Flow Details . 55
Annex C (informative): Bibliography . 58
History . 59

ETSI
5 ETSI TS 103 161-19 V1.1.1 (2011-10)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Access, Terminals, Transmission
and Multiplexing (ATTM).
The present document is part 19 of a multi-part IPCablecom 1.5 deliverable covering the Digital Broadband Cable
Access to the Public Telecommunications Network; IP Multimedia Time Critical Services, as identified below:
Part 1: "Overview";
Part 2: "Architectural framework for the delivery of time critical services over Cable Television Networks using
Cable Modems";
Part 3: "Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television
Networks using Cable Modems";
Part 4: "Network Call Signalling Protocol";
Part 5: "Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks
using Cable Modems";
Part 6: "Event Message Specification";
Part 7: "Media Terminal Adapter (MTA Management Information Base (MIB)";
Part 8: "Network Call Signalling (NCS) MIB Requirements";
Part 9: "Security";
Part 10: "Management Information Base (MIB) Framework";
Part 11: "Media terminal adapter (MTA) device provisioning";
Part 12: "Management Event Mechanism";
Part 13: "Trunking Gateway Control Protocol - MGCP option";
Part 14: "Embedded MTA Analog Interface and Powering Specification"
Part 15: "Analog Trunking for PBX Specification";
Part 16: "Signalling for Call Management Server";
Part 17: "CMS Subscriber Provisioning Specification";
Part 18: "Media Terminal Adapter Extension MIB";
Part 19: "IPCablecom Audio Server Protocol Specification - MGCP option";
Part 20: "Management Event MIB Specification";
ETSI
6 ETSI TS 103 161-19 V1.1.1 (2011-10)
Part 21: "Signalling Extension MIB Specification".
NOTE 1: Additional parts may be proposed and will be added to the list in future versions.
NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future
enhancements.
ETSI
7 ETSI TS 103 161-19 V1.1.1 (2011-10)
1 Scope
The present document describes the architecture and protocols that are required for playing announcements in Voice-
over-IP (VoIP) IPCablecom networks. Announcements are typically needed for calls that do not complete. Additionally,
they may be used to provide enhanced information services to the caller. Different carrier service feature sets require
different announcement sets and announcement formats.
Announcements can be as basic as fixed-content announcements (e.g. all circuits busy) or as complex as those provided
by intelligent Interactive Voice Response (IVR) systems. The IPCablecom service model requires that all
announcements be provisioned and signalled in a standard manner for all supported call features and use case scenarios.
The present document defines a set of signalling protocols that are used to provide announcement services within a
cable network. For one of these protocols - the IPCablecom Network Call Signalling (NCS) protocol [i.3] - the present
document defines two new event packages:
• a Base Audio Package;
• an Advanced Audio Package.
NOTE: There may be cases where audio server implementations are based on protocols other than that specified
in the present document. If other protocols are implemented, those implementations will adhere to
IPCablecom-specified architectural and functional requirements, such as security and Quality of Service
(QoS), and the required features/capabilities to support interoperability. A variety of such protocols
exists, including protocols such as INAP, ITU-T Recommendation H.248 [i.9] and others.
Call
Embedded MTA
Announcement Server
Management
Cable
Server
MTA Announcement Controller
Modem
(CMS )
(ANC)
HFC access
Announcement Player
network CMTS
(AN P)
(DOCSIS)
Signalling
Gateway
(SG)
Managed IP Network
Media
PSTN
Gateway
Controller
(MGC)
Media
HFC access
Gateway
CMTS
network
(MG)
(DOCSIS)
Key Distribution Server (KDC)
Embedded MTA
Provisioning Server
Cable
DHCP Servers
MTA
Modem OSS
DNS Servers
Backoffice
TFTP or HTTP Servers
SYSLOG Server
Record Keeping Server (RKS)
Figure 1: IPCablecom Network Component Reference Model
Announcement Servers, also known as Audio Servers are network components that manage and play informational
tones and messages in response to events that occur in the network. Most announcements are media streams that
originate from servers in the network. Some simple tones and short announcements can also reside at the MTA and in
the MG.
ETSI
8 ETSI TS 103 161-19 V1.1.1 (2011-10)
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 161-6: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5; Part 6: Event Message
Specification".
[2] IETF RFC 3435: "Media Gateway Control Protocol (MGCP)", January 2003. .
[3] ETSI TS 103 161-3: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5; Part 3: Audio Codec Requirements
for the Provision of Bi-Directional Audio Service over Cable Television Networks using Cable
Modems".
[4] ETSI TS 103 161-9: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5; Part 9: Security".
[5] W3C Recommendation: "Speech Recognition Grammar Specification Version 1.0", Hunt,
McGlashan, March 2004.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 103 161-13: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5; Part 13: Trunking Gateway Control
Protocol - MGCP option".
[i.2] ETSI TS 103 161-4: "Access, Terminals, Transmission and Multiplexing (ATTM); Integrated
Broadband Cable and Television Networks; IPCablecom 1.5; Part 4: Network Call Signalling
Protocol".
[i.3] IETF RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax", August 1998.
[i.4] IETF RFC 2234: "Augmented BNF for Syntax Specifications: ABNF", November 1997.
[i.5] ISO 639-2: "Code For The Representation Of Names Of Languages".
[i.6] ISO 4217: "Codes for the Representation of Currencies and Funds".
[i.7] ISO 8601: "Data elements and interchange formats -- Information interchange -- Representation of
dates and times".
[i.8] Sun Microsystems: "Java Speech Grammar Format Specification", [JSGF], October 1998.
[i.9] ITU-T Recommendation H.248: "Implementors' Guide for the ITU-T H.248 Recommendation
series".
ETSI
9 ETSI TS 103 161-19 V1.1.1 (2011-10)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
announcement server: also known as audio servers, Announcement Servers are network components that manage and
play informational tones and messages in response to events that occur in the network
NOTE: Most announcements are media streams that originate from servers in the network. Some simple tones
and short announcements can also reside at the MTA and in the MG.
service ID: 14-bit number assigned by a CMTS to identify an upstream virtual circuit
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAU Advanced Audio Server
ABNF Augmented Backus Naur Form
ACK Acknowledgement
ANC Announcement Controller
ANP Announcement Player
ASP Audio Server Protocol
ASR Automatic Speech Recognition
BAU Basic Audio Server
BNF Backus Naur Form
CMS Call Management Server
CMTS Cable Modem Termination System
CPU Central Processing Unit
CRCX Create Connection
DC Digits Collected
DLCX Delete Connection
DN Domain Name
DSA Downstream Service Authorization
DSAREQ Downstream Authorization Request
DSARSP Downstream Authorization Request
DTMF Dual Tone Multi-Frequency
EDT Extra Digit Timer
EM Event Message
E-MTA Embedded MTA
FDT First Digit Timer
H.248 An ITU-T/IETF protocol for media gateway control
ICT Interdigit Critical Timer
IDT Interdigit Timer
IN Higher Layer Information Channel
INAP Intelligent Network Application Part
IP Internet Protocol
ISO International Standardization Organisation
IVR Interactive Voice Response
JSGF Java Speech Grammar Format Specification
LCR Last Call Received
MDCX Modify Connection
MG Media Gateway
MGC Media Gateway Controller
MGC/MG Media Player Controller/Media Gateway
MGC-MG Media Player Controller/Media Gateway
MGCP Media Gateway Control Protocol
MIB Management Information Base
ETSI
10 ETSI TS 103 161-19 V1.1.1 (2011-10)
MP Media Player
MPC Media Player Controller
MPC-MP Media Player Controller - Media Player
MTA Media Terminal Adapter
NCS Network-based Call Signalling
NPA Numbering Plan Administration
NTFY Notify
OK Okay
PASS PacketCable Audio Server Specification
PBX Private Branch Exchange
PCMU Pulse Code Modulation Mu-law
PIN Personal Identification Number
PL Packet Loss
PSTN Public Switched Telephone Network
RADIUS Remote Access Dial In User Service
RC Response Code
RFC Request for Comment
RKS Record Keeping Server
RQNT Request for Notification
RTP Real-Time Protocol
SDP Session Description Protocol
S-MTA Stand-alone MTA
SPR Speech Recognition Package
TGCP Trunking Gateway Control Protocol
UDP User Datagram Protocol
UGS Unsolicited Grant Service
URI Universal Resource Identifier
VoIP Voice-over-IP
VSA Vector Signal Analyser
4 Void
5 Technical Overview
The present document defines a suite of signalling protocols for providing announcement and media services in an
IPCablecom network. This clause:
• defines the architectural requirements for providing IPCablecom announcement and media services;
• defines and categorizes announcement and media types;
• defines the components and their roles in the IPCablecom audio server architecture; and
• describes the signalling and media interfaces.
5.1 Architectural Requirements
The architectural requirements and assumptions for providing Audio and Media Services for a IPCablecom Network are
listed below. These requirements are based upon the specifications and technical reports that define the IPCablecom
architecture.
ETSI
11 ETSI TS 103 161-19 V1.1.1 (2011-10)
5.1.1 Call Destination
The Audio Server Specification must define how announcements are provided for IPCablecom on-net to off-net and on-
net to on-net calls.
NOTE: Announcements for off-net to on-net calls will usually be handled by the PSTN as a result of SS7 clearing
messages. However when appropriate, they also may be played from the IPCablecom Media Gateway
(MG).
5.1.2 Media Formats
A Media Player must be able to generate the required announcements in any of the code formats required by the
IPCablecom Codec specification [3].
5.1.3 Security
Audio shall be signalled and played in a secure manner. Media Player Controllers and Media Players shall support the
security protocols defined in the IPCablecom Security specification [4].
5.1.4 Operational Support Systems
Media Player Controllers shall support the IPCablecom billing and event message protocols as defined in [1], as
applicable to the applications they support. No requirement has been identified for support of event reporting by the
Media Player.
5.2 Announcement Definitions
Announcements can be divided into four distinct categories: tones, fixed-content, variable content, and interactive
announcements.
5.2.1 Tones
Includes tones such as reorder, busy and ring back. See [i.2] and [i.1] for details.
5.2.2 Fixed-content Announcements
Fixed-content Announcements consist of audio messages with fixed-content that require no user interaction. For
example, "Your call did not go through. Please hang up and try your call again."
5.2.3 Variable Content Announcements
Variable Content Announcements are messages that contain a customizing parameter(s) yet require no user interaction.
For example, "The number you have dialled, 321-9876, has been changed. The new number is 321-6789."
5.2.4 Interactive Announcements
Interactive Announcements are announcements that require user interaction, DTMF (Dual Tone Multi-Frequency) or
IVR. For example, "The number you have dialled, 541-321-9876, has been changed. The new number is 541-321-6789.
To be connected to the new number, at a cost of thirty-five cents, please press 1."
5.2.5 Naming Conventions for Endpoint Identifiers
A flat name space for endpoints is used, with audio ports indicated by the prefix aud and the port number,
e.g. aud/12@audio-server-3.whatever.net. Wildcards ($, *) may be used in place of the port numbers in accordance with
standard NCS rules for wild card use.
ETSI
12 ETSI TS 103 161-19 V1.1.1 (2011-10)
Systems that support announcements only (i.e. no digit collection, no recording, and no speech recognition ability) may
use the prefix ann instead of aud.
Some systems may use one additional level in the naming scheme to support the identification of specific cards. In this
case the naming would look like aud//@audio-server-3.whatever.net.
5.3 Interfaces
The IPCablecom Audio Server Specification defines a set of interfaces between the components responsible for
providing audio services. Figure 12 illustrates the interfaces between these components. Only where an interface is
exposed is it expected to meet IPCablecom specification requirements.
Media Gateway
PSTN
(MG)
Ann-1
Media Gateway
Ann-4
Controller
(MGC)
Ann-3
Audio Server (AS)
Media Player
Controller
MTA Ann-1 CMS Ann-3
(MPC)
Ann-2
Media Player
Ann-4
(MP)
Figure 2: IPCablecom Audio Server Components and Interfaces
ETSI
13 ETSI TS 103 161-19 V1.1.1 (2011-10)
6 Ann-1 Interface: CMS-MTA and MGC-MG
The CMS-MTA and MGC-MG announcement interfaces are implemented by the Legacy Audio Package of the
NCS/TGCP protocol, which provides the playback of tones and fixed-content announcements to the end-users.
6.1 CMS-MTA Interface
Each MTA in the network may store a predefined set of simple announcements locally. When an announcement is
needed, the CMS will decide if it should instruct the MTA to play a local announcement or set up a connection between
the MTA and a Network MP and have the announcement played over the network. Playing simple announcements from
the MTA saves network resources.
The MTA may store announcements in either static or dynamic memory. If announcements are stored in dynamic
memory then the announcements will not be available until the MTA has accessed them from the network.
These simple announcements will require only a small amount of storage on the MTA. The table below illustrates the
storage requirements for such announcements. The example uses an average announcement time of 10 seconds.
Table 1: MP Storage
Number of Announcement Encoding bytes/second Bytes required
Announcements Length (seconds)
11 10 2 000 (G.728) 220 K
11 10 8 000 (PCMU/PCMA) 880 K
MTAs require the ability to be updated dynamically with announcements so that the same MTA can move from service
provider to service provider without requiring complete firmware upgrades. This capability is for further study and will
need to be worked jointly with the IPCablecom architecture, security and provisioning teams.
6.1.1 Announcement List
The MTA may store and play a defined set of announcements for common network situations. These announcements
may be played using the Announcement Server Package defined in RFC 3435 [2], using URI (Universal Resource
Identifiers) to identify the announcements. Cached versions of all announcement URIs should be refreshed every time
the MTA connects to the network. Other methods of propagating new announcements to MTAs, for instance while the
MTA remains in service, are for further study. The second column of the table below is a list of some announcements
that may be supported in the MTA. The first column contains wording that may be used.
Table 2: Sample Announcements
Sample Announcement Name
Your call cannot be completed as dialled. Please check the number and dial again. Vacant Code
You must first dial a one or zero when calling this number. Please hang up and try your call again. Dial One or Zero
You must first dial a one when calling this number. Please hang up and try your call again. Dial One First
It is not necessary to dial a one when calling this number. Please hang up and try your call again. No Dial One
If you'd like to make a call, please hang up and try again. If you need help, hang up and dial the
No Digits
operator.
Your call cannot be completed as dialled. Please read the instruction card or call your operator for
Assisted Dialling
assistance.
Your call did not go through. Please try your call again. Reorder
All circuits are busy now. Please try your call later. No Circuit
Due to facility trouble in the area you are calling, your call cannot be completed at this time. Please
Domestic Facility
try your call later.
The party you are calling has declined to receive this call. Please try your call again with caller ID Unidentified Call
enabled. Reject
Thank you for using [carrier's name]. Branding

ETSI
14 ETSI TS 103 161-19 V1.1.1 (2011-10)
6.2 MGC-MG Interface
The MG announcement interface (Ann-1) allows for the MGC to request the MG play fixed-content announcements to
PSTN end-users. The MGC/MG announcement interface package does not specify any standard announcements to be
stored locally in the MG. All announcements are provisioned dynamically and are referenced accordingly.
This MG announcement provisioning capability is for further study and will need to be worked jointly with the
IPCablecom architecture, security, and provisioning teams.
7 Ann-2 interface: MPC-MP
7.1 Introduction
An MP (Media Player) is a shared resource in the IPCablecom Network that can be instructed to provide media services
to an end-user or terminal. These services include streaming fixed-content, variable content and interactive
announcements to IPCablecom subscribers. For example, the MP is responsible for playing prompts and collecting
digits when charging a call to a calling card.
The MP is controlled by an external element, the MPC (Media Player Controller). The MPC-MP Interface defines a two
new NCS announcement packages used to control the Media Player. The Base Audio Package provides a standard set of
IVR functions such as Play, PlayCollect, and PlayRecord. The Advanced Audio Package is a superset of the Base
Audio Package and provides additional capabilities.
The MP is responsible for managing its own resources. When accepting a request, the MP shall make sure that the
required resources are available before accepting the request. When a single session involves multiple requests to the
Media Player, the MP may experience a shortage of resources preventing it from accepting one given request belonging
to that session. In this case, the MP user (i.e. the MPC) is responsible for re-sending the request or terminating the
end-user session elegantly.
7.2 Audio Package Concepts
The Base and Advanced Audio Packages support both simple and complex audio structures. A simple audio structure
might be a single announcement such as "Welcome to Bell South's Automated Directory Assistance Service." A more
complex audio structure might consist of an announcement followed by voice variable followed by another
announcement, for example "There are thirty seven minutes remaining on your prepaid calling card," where "There are"
is a prompt, the number of minutes is a voice variable, and "minutes remaining on your prepaid calling card" is another
prompt.
It is also possible to define complex audio structures that are qualified by user defined selectors such as language, audio
file format, gender, accent, customer, or voice talent. For instance, if the above example were qualified by language and
accent selectors, it would be possible to play "There are thirty seven minutes remaining on your prepaid calling card" in
English spoken with a southern accent or in English spoken with a mid-western accent, providing that the audio to
support this had been provisioned.
There are two methods of specifying complex audio. The first is to directly reference the individual components. This
requires a complete description of each component to be specified via the protocol. The second method is to provision
the components on the Audio Server as a single entity and to export a reference to that entity to the call agent. In this
case, only the reference (plus any dynamic data required, such as a variable data) is passed via the protocol, and no
specification of individual components is necessary.
These packages provide significant functionality most of which is controlled via protocol parameters. Most parameters
are optional, and where ever possible default to reasonable values. An audio application that references to complex
provisioned audio structures can specify audio events using a minimum of syntax by taking advantage of parameter
optionality and parameter defaults.
ETSI
15 ETSI TS 103 161-19 V1.1.1 (2011-10)
7.2.1 Understanding Audio Segments
An audio segment is a reference that resolves to one or more audio recordings. There are four types of audio segments:
Physical: A physical segment is the simplest type of segment, a single recording. The recording could be a single word,
such as "one", or an extended block of speech, such as "Our office is closed at this time. Please call back during normal
business hours." Every physical segment is assigned a unique URI (Universal Resource Identifier) which among other
things can be a hierarchical name, or a simple name or number.
Sequence: A sequence is a provisioned ordered list of audio segments. Every sequence is assigned a unique URI. A
sequence can contain any of the four segment types (physical segments, other sequences, sets, and variables). On
playback a sequence identifier is resolved to an ordered list of physical segments which are played in order.
Set: A set is a provisioned collection of semantically related audio segments and an associated selector. Each set is
assigned a unique URI. A set can contain physical segments, sequences, other sets, or variables. At runtime the value of
the selector is used to determine which element of the set is played.
Individual selector types are not defined in the syntax (except for the pre-defined language selector) and are instead
defined by the provisioner. A provisioner could define one or more of the following selector types: language, accent,
gender, accent, customer, or day of the week. For each selector type, the provisioner must define a range of valid
values. The provisioner may also choose to define a default value. At runtime if a selector value is not supplied the
default value is used.
Variable: A voice variable represents a single semantic concept (such as date or number) and dynamically produces the
appropriate speech based on information supplied at runtime. Each provisioned voice variable is assigned a unique URI.
For example, if an application needs to play a date, rather than telling the AudioServer to play each individual
component of the date (e.g. "March" "twenty" "second" "nineteen" "ninety" "nine"), it can specify a voice variable of
type date with value "19990322". The variable then assembles and plays the component audio needed to speak the date.
Specification of variables is considered in more detail in a later clause of the present document.
7.2.2 Segment Identifiers
Provisioned segments and segments recorded at runtime are identified by URIs as defined in RFC 2396, [i.3] Uniform
Resource Identifiers: Generic Syntax.
A URI can be a simple name or it can be a URL. Three URL schemes are allowed: the file: scheme, the ftp:scheme, and
the http: scheme. The file: scheme is used for audio local to the Audio Server. The ftp: scheme is used for audio remote
to the Audio Server. The http: scheme can be used for audio local to the Audio Server using the http://localhost
convention or audio remote to the Audio Server. All audio references that require parameters encoded in the URL
(e.g. set selectors) shall use the http: scheme. The following table shows some of the possibilities.
Table 3: Example URIs
Reference to local audio (flat file):
S: pa(an=file://welcome)
Reference to local audio (flat file):
S: pa(an=file://12354)
Reference to local audio:
S: pa(an=file://audio/xyztel/welcome)
Reference to remote audio:
S: pa(an=http://audio/xyztel/welcome)

7.2.3 Segment Life
Physical segments may be provisioned or they may be recorded during the course of a call. A physical segment
recorded during the course of a call can be either transient or persistent. A transient physical segment lasts only for the
duration of the call during which it was recorded. A persistent physical segment lasts beyond the duration of the call
during which it was recorded.
ETSI
16 ETSI TS 103 161-19 V1.1.1 (2011-10)
7.2.4 Nested Sets And Sequences
Nested definition of both sets and sequences is allowed, i.e. it is legal to define a set of sets or a sequence of sequences.
In addition, audio structures may also be specified by intermixing sets and sequences, and it is possible to specify a set
of sequences or a sequence containing one or more set elements. Direct or transitive definition of a set or segment in
terms of itself is not allowed.
Nesting of sets and sequences should be restricted to two or three levels.
7.2.5 Sequence Example
In the following example, a provisioner has provisioned one physical segment and two variable segments and has
provisioned a sequence, http:/mysegment, which is an ordered list of the three segments. The sequence when played
speaks the following: "Today's date is ."

Figure 3: Sequence Example
7.2.6 Set Example
To support an application which plays a particular piece of audio in either Arabic, Welsh, or Tibetan, a provisioner
could define a set with the pre-defined selector, "lang", and would use define three of the possible values for that
selector, "ara", "cym", and "tib". The provisioner would provision three audio segments, one in each language, and
would associate the Arabic segment with the "ara" selector value, etc. The provisioner also could define a default value
of the selector when no selector value is supplied, "ara" for instance. The entire set would be assigned a unique URI.
At runtime a reference to the set with the selector set to "cym" would result in the Welsh version of the prompt being
played. A reference to the set with no selector would result in the Arabic version of the prompt being played since
English has been set as the default selector value.
http://audio/my-multi-lang-segment
ARA        CYM        TIB
http://audio/my-arabian-segment http://audio/my-welsh-segment http://audio/my-tibetan-segment

Figure 4: Set Example
ETSI
17 ETSI TS 103 161-19 V1.1.1 (2011-10)
7.2.7 Set With Nested Sequence Example
In this example, the provisioner has provisioned three physical segments, one in Arabic, one in Welsh, and one in
Tibetan, and the provisioner has also provisioned three date variables. Using these six segments the provisioner has
provisioned three sequences, each consisting of a physical segment followed by a date variable. Finally the provisioner
has provisioned a set consisting of the three sequences and with language as the set selector.
At runtime a reference to the set with the selector set to "ara" and a variable value of "20001015" would result in the
th
following being played in Arabic: "Today's date is October 15 , 2000."
http://audio/my-multi- lang-segment
ARA        CYM        TIB
http://audio/my- arabian-sequence http://audio/my-welsh-sequence http://audio/my- tibetan-sequence
1             2       1             2      1             2
http://audio/ ara/ Date http://audio /cym/ Date http://audio /tib/ Date
date-is-segment Variable date-is-segment V
...