Request for Comments: 4240 J. Van Dyke
Category: Informational A. Spitzer
Brooktrout Technology, Inc.
December 2005
Basic Network Media Services with SIP
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In SIP-based networks, there is a need to provide basic network media
services. Such services include network announcements, user
interaction, and conferencing services. These services are basic
building blocks, from which one can construct interesting
applications. In order to have interoperability between servers
offering these building blocks (also known as Media Servers) and
application developers, one needs to be able to locate and invoke
such services in a well defined manner.
This document describes a mechanism for providing an interoperable
interface between Application Servers, which provide application
services to SIP-based networks, and Media Servers, which provide the
basic media processing building blocks.
Table of Contents
1. Overview ........................................................2
1.1. Conventions Used in This Document ..........................3
2. Mechanism .......................................................3
3. Announcement Service ............................................5
3.1. Operation ..................................................8
3.2. Protocol Diagram ...........................................9
3.3. Formal Syntax ..............................................9
4. Prompt and Collect Service .....................................11
4.1. Formal Syntax for Prompt and Collect Service ..............12
5. Conference Service .............................................13
5.1. Protocol Diagram ..........................................14
5.2. Formal Syntax .............................................16
6. IANA Considerations ............................................17
7. The User Part ..................................................17
8. Security Considerations ........................................20
9. Contributors ...................................................20
10. Acknowledgements ..............................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................22
1. Overview
In SIP-based media networks (RFC 3261 [10]), there is a need to
provide basic network media services. Such services include playing
announcements, initiating a media mixing session (conference), and
prompting and collecting information with a user.
These services are basic in nature, are few in number, and
fundamentally have not changed in 25 years of enhanced telephony
services. Moreover, given their elemental nature, one would not
expect them to change in the future.
Multifunction media servers provide network media services to clients
using server protocols such as SIP, often in conjunction with markup
languages such as VoiceXML [20] and MSCML [21]. This document
describes how to identify to a multifunction media server what sort
of session the client is requesting, without modifying the SIP
protocol.
It is critically important to note that the mechanism described here
in no way modifies the SIP protocol, the meaning, or definition of a
SIP Request URI, or does it put any restrictions, in any way, on
devices that do not implement this convention.
Announcements are media played to the user. Announcements can be
static media files, media files generated in real-time, media streams
generated in real-time, multimedia objects, or combinations of the
above.
Media mixing is the act of mixing different RTP streams, as described
in RFC 3550 [13]. Note that the service described here suffices for
simple mixing of media for a basic conferencing service. This
service does not address enhanced conferencing services, such as
floor control, gain control, muting, subconferences, etc. MSCML [21]
addresses enhanced conferencing. However, that is beyond the scope
of this document. Interested readers should read conferencing-
framework [22] for details on the IETF SIP conferencing framework.
Prompt and collect is where the server prompts the user for some
information, as in an announcement, and then collects the user’s
response. This can be a one-step interaction, for example by playing
an announcement, "Please enter your pass code", followed by
collecting a string of digits. It can also be a more complex
interaction, specified, for example, by VoiceXML [20] or MSCML [21].
1.1. Conventions Used in This Document
RFC 2119 [6] the interpretations for the key words "MUST", "MUST
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
2. Mechanism
In the context of SIP control of media servers, we take advantage of
the fact that the standard SIP URI has a user part. Multifunction
media servers do not have users. Thus we use the user address, or
the left-hand-side of the URI, as a service indicator.
The use of the user part of the SIP Request URI has a number of
useful properties:
o There is no change to core SIP.
o Only devices that choose to conform to this standard have to
implement it.
o This document only applies to multifunction SIP-controlled media
servers.
o This document has no impact on non-multifunction SIP-controlled
media servers.
o The mechanism described in this document has absolutely no impact
on SIP devices other than media servers.
The last bullet point is crucial. In particular, the user part
convention described here places absolutely no restrictions on any
SIP user agent, proxy, back-to-back user agent (B2BUA), or any future
device. The user parts defined here only apply to multifunction
media servers that chose to implement the convention. With the
exception of a conforming media server, these user names and
conventions have no impact on the user part namespace. They do not
restrict the use of these user names at devices other than a
multifunction media server.
Note that the set of services is small, well defined, and well
contained. The section The User Part (Section 7) discusses the
issues with using a fixed set of user-space names.
For per-service security, the media server SHOULD use the security
protocols described in RFC 3261 [10].
The media server MAY issue 401 challenges for authentication. The
media server SHOULD support the sips: scheme for the announcement
service. The media server MUST support the sips: scheme for the
dialog and conference services. The level of authentication to
require for each service is a matter of local policy.
The media server, upon receiving an INVITE, notes the service
indicator. Depending on the service indicator, the media server will
either honor the request or return a failure response code.
The service indicator is the concatenation of the service name and an
optional service instance identifier, separated by an equal sign.
Per RFC 3261 [10], the service indicator is case insensitive. The
service name MUST be from the set alphanumeric characters plus dash
(US-ASCII %2C). The service name MUST NOT include an equal sign
(US-ASCII %3D).
The service name MAY have long- and short-forms, as SIP does for
headers.
A given service indicator MAY have an associated set of parameters.
Such parameters MUST follow the convention set out for SIP URI
parameters. That is, a semi-colon separated list of keyword=value
pairs.
Certain services may have an association with a unique service
instance on the media server. For example, a given media server can
host multiple, separate conference sessions. To identify unique
service instances, a unique identifier modifies the service name.
The unique identifier MUST meet the rules for a legal user part of a
SIP URI. An equal sign, US-ASCII %3D, MUST separate the service
indicator from the unique identifier.
Note that since the service indicator is case insensitive, the
service instance identifier is also case insensitive.
The requesting client issues a SIP INVITE to the media server,
specifying the requested service and any appropriate parameters.
If the media server can perform the requested service, it does so,
following the processing steps described in the service definition
document.
If the media server cannot perform the requested service or does not
recognize the service indicator, it MUST respond with the response
code 488 NOT ACCEPTABLE HERE. This is appropriate, as 488 refers to
a problem with the user part of the URI. Moreover, 606 is not
appropriate, as some other media server may be able to satisfy the
request. RFC 3261 [10] describes the 488 and 606 response codes.
Some services require a unique identifier. Most services
automatically create a service instance upon the first INVITE with
the given identifier. However, if a service requires an existing
service instance, and no such service instance exists on the media
server, the media server MUST respond with the response code 404 NOT
FOUND. This is appropriate as the service itself exists on the media
server, but the particular service instance does not. It is as if
the user was not home.
3. Announcement Service
A network announcement is the delivery of a multimedia resource, such
as a prompt file, to a terminal device. Note the multimedia resource
may be any multimedia object that the media server supports. This
service can play a single object with multiple streams, such as a
video and audio prompt. However, this service cannot play multiple
objects on the same SIP dialog.
There are two types of network announcements. The differentiating
characteristic between the two types is whether the network fully
sets up the SIP dialog before playing the announcement. The analog
in the Public Switched Telephone Network (PSTN) is whether answer
supervision is supplied (i.e., does the announcement server answer
the call prior to delivering the announcement?).
Playing an announcement after call setup is straightforward. First,
the requesting device issues an INVITE to the media server requesting
the announcement service. The media server negotiates the SDP and
responds with a 200 OK. After receiving the ACK from the requesting
device, the media server plays the requested object and issues a BYE
to the requesting device.
If the media server supports announcements, but it cannot find the
referenced URI, it MUST respond with the 404 response code and SHOULD
send the reason phrase "Announcement content not found".
If the media server receives an INVITE for the announcement service
without a "play=" parameter, it MUST respond with the response code
400 and SHOULD send the reason phrase "Mandatory play parameter
missing".
If there is an error retrieving the announcement, the media server
MUST respond with a 400 response code and SHOULD send the reason
phrase "Announcement content could not be retrieved". In addition
the media server SHOULD include a Warning header with appropriate
explanatory text explaining what failed.
The Request URI fully describes the announcement service through the
use of the user part of the address and additional URI parameters.
The user portion of the address, "annc", specifies the announcement
service on the media server. The service has several associated URI
parameters that control the content and delivery of the announcement.
These parameters are described below:
play
Specifies the resource or announcement sequence to be played.
repeat
Specifies how many times the media server should repeat the
announcement or sequence named by the "play=" parameter. The
value "forever" means the repeat should be effectively unbounded.
In this case, it is RECOMMENDED the media server implements some
local policy, such as limiting what "forever" means, to ensure
errant clients do not create a denial of service attack.
delay
Specifies a delay interval between announcement repetitions. The
delay is measured in milliseconds.
duration
Specifies the maximum duration of the announcement. The media
server will discontinue the announcement and end the call if the
maximum duration has been reached. The duration is measured in
milliseconds.
locale
Specifies the language and optionally country variant of the
announcement sequence named in the "play=" parameter. RFC 3066
[9] specifies the locale tag. The locale tag is usually a two- or
three-letter code per ISO 639-1 [11]. The country variant is also
often a two-letter code per ISO 3166-1 [12]. These elements are
concatenated with a single under bar (%x5F) character, such as
"en_CA". If only the language is specified, such as locale=en,
the choice of country variant is an implementation matter.
Implementations SHOULD provide the best possible match between the
requested locale and the available languages in the event the
media server cannot honor the locale request precisely. For
example, if the request has locale=ca_FR, but the media server
only has fr_FR available, the media server should use the fr_FR
variant. Implementations SHOULD provide a default locale to use
if no language variants are available.
param[n]
Provides a mechanism for passing values that are to be substituted
into an announcement sequence. Up to 9 parameters ("param1="
through "param9=") may be specified. The mechanics of
announcement sequences are beyond the scope of this document.
extension
Provides a mechanism for extending the parameter set. If the
media server receives an extension it does not understand, it MUST
silently ignore the extension parameter and value.
The "play=" parameter is mandatory and MUST be present. All other
parameters are OPTIONAL.
NOTE: Some encodings are not self-describing. Thus, the
implementation relies on filename extension conventions for
determining the media type.
Note that RFC 3261 [10] implies that proxies are supposed to pass
parameters through unchanged. However, be aware that non-conforming
proxies may strip Request-URI parameters. That said, given the
likely scenarios for the mechanisms presented in this document, this
should not be an issue. Most likely, the proxy inserting the
parameters is the last proxy before the media server. If the service
provider deploys a proxy for load balancing or service location
purposes, the service provider should ensure that its choice of proxy
preserves parameters.
The form of the SIP Request URI for announcements is as follows.
Note that the backslash, CRLF, and spacing before the "play=" in the
example is for readability purposes only.
sip:annc@ms2.example.net; \
play=http://audio.example.net/allcircuitsbusy.g711
sip:annc@ms2.example.net; \
play=file://fileserver.example.net//geminii/yourHoroscope.wav
3.1. Operation
The scenarios below assume there is a SIP Proxy, application server,
or media gateway controller between the caller and the media server.
However, the announcement service works as described below even if
the caller invokes the service directly. We chose to discuss the
proxy case, as it will be the most common case.
The caller issues an INVITE to the serving SIP Proxy. The SIP Proxy
determines what audio prompt to play to the caller. The proxy
responds to the caller with 100 TRYING.
It is important to note that the mechanism described here in no way
modifies the behavior of SIP [10]. In particular, this convention
does not modify SDP negotiation [18].
The proxy issues an INVITE to the media server, requesting the
appropriate prompt to play coded in the play= parameter. The media
server responds with 200 OK. The proxy relays the 200 OK to the
caller. The caller then issues an ACK. The proxy then relays the
ACK to the media server.
With the call established, the media server plays the requested
prompt. When the media server completes the play of the prompt, it
issues a BYE to the proxy. The proxy then issues a BYE to the
caller.
3.2. Protocol Diagram
Caller Proxy Media Server
| INVITE | |
|----------------------->| INVITE |
| 100 TRYING |----------------------->|
|<-----------------------| 200 OK |
| 200 OK |<-----------------------|
|<-----------------------| |
| ACK | |
|----------------------->| ACK |
| |----------------------->|
| | |
| Play Announcement (RTP) |
|<================================================|
| | |
| | BYE |
| BYE |<-----------------------|
|<-----------------------| |
| 200 OK | |
|----------------------->| 200 OK |
| |----------------------->|
| | |
3.3. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 4234 [7].
ANNC-URL = sip-ind annc-ind "@" hostport
annc-parameters uri-parameters
sip-ind = "sip:" / "sips:"
annc-ind = "annc"
annc-parameters = ";" play-param [ ";" content-param ]
[ ";" delay-param]
[ ";" duration-param ]
[ ";" repeat-param ]
[ ";" locale-param ]
[ ";" variable-params ]
[ ";" extension-params ]
play-param = "play=" prompt-url
content-param = "content-type=" MIME-type
delay-param = "delay=" delay-value
delay-value = 1*DIGIT
duration-param = "duration=" duration-value
duration-value = 1*DIGIT
repeat-param = "repeat=" repeat-value
repeat-value = 1*DIGIT / "forever"
locale-param = "locale=" token
; per RFC 3066, usually
; ISO639-1_ISO3166-1
; e.g., en, en_US, en_UK, etc.
variable-params = param-name "=" variable-value
param-name = "param" DIGIT ; e.g., "param1"
variable-value = 1*(ALPHA / DIGIT)
extension-params = extension-param [ ";" extension-params ]
extension-param = token "=" token
"uri-parameters" is the SIP Request-URI parameter list as described
in RFC 3261 [10]. All parameters of the Request URI are part of the
URI matching algorithm.
The MIME-type is the MIME [1] [2] [3] [4] [5] content type for the
announcement, such as audio/basic, audio/G729, audio/mpeg,
video/mpeg, and so on.
A number of MIME registrations, which could be used here, have
parameters, for instance, video/DV. To accommodate this, and retain
compatibility with the SIP URI structure, the MIME-type parameter
separator (semicolon, %3b) and value separator (equal, %d3) MUST be
escaped. For example:
sip:annc@ms.example.net; \
play=file://fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg%3bencode%d3314M-25/625-50
The locale-value consists of a tag as specified in RFC 3066 [9].
The definition of hostport is as specified by RFC 3261 [10].
The syntax of prompt-url consists of a URL scheme as specified by RFC
3986 [8] or a special token indicating a provisioned announcement
sequence. For example, the URL scheme MAY include any of the
following.
o http/https
o ftp
o file (referencing a local or NFS (RFC 3530 [16]) object)
o nfs (RFC 2224 [14])
If a provisioned announcement sequence is to be played, the value of
prompt-url will have the following form:
prompt-url = "/provisioned/" announcement-id
announcement-id = 1*(ALPHA / DIGIT)
Note that the scheme "/provisioned/" was chosen because of a
hesitation to register a "provisioned:" URI scheme.
This document is strictly focused on the SIP interface for the
announcement service and, as such, does not detail how announcement
sequences are provisioned or defined.
Note that the media type of the object the prompt-url refers to can
be most anything, including audio file formats, text file formats, or
URI lists. See the Prompt and Collect Service (Section 4) section
for more on this topic.
4. Prompt and Collect Service
This service is also known as a voice dialog. It establishes an
aural dialog with the user.
The dialog service follows the model of the announcement service.
However, the service indicator is "dialog". The dialog service takes
a parameter, voicexml=, indicating the URI of the VoiceXML script to
execute.
sip:dialog@mediaserver.example.net; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
A Media Server MAY accept additional SIP request URI parameters and
deliver them to the VoiceXML interpreter session as session
variables.
Although not good VoiceXML programming practice, VoiceXML scripts
might contain sensitive information, such as a user’s pass code in a
DTMF grammar. Thus, the media server MUST support the https scheme
for the voicexml parameter for secure fetching of scripts. Likewise,
dynamic grammars often do have user-identifying information. As
such, the VoiceXML browser implementation on the media server MUST