SIPPING J. Van Dyke
Internet-Draft E. Burger (Ed.)
Expires: July 28, 2003 A. Spitzer
SnowShore Networks, Inc.
January 27, 2003
Basic Network Media Services with SIP
draft-burger-sipping-netann-04
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 28, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
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
Van Dyke, et al. Expires July 28, 2003 [Page 1]
Internet-Draft SIP Media Services January 2003
protocol interface between Application Servers, which provide
application services to SIP-based networks, and Media Servers, which
provide the basic media processing building blocks.
Conventions used in this document
RFC2119 [1] provides the interpretations for the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Announcement Service . . . . . . . . . . . . . . . . . . . . 6
3.1 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Established Call Announcement . . . . . . . . . . . . . . . 8
3.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Early Media Announcement . . . . . . . . . . . . . . . . . . 9
3.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 10
4. Prompt and Collect Service . . . . . . . . . . . . . . . . . 13
4.1 Formal Syntax for Prompt and Collect Service . . . . . . . . 13
5. Conference Service . . . . . . . . . . . . . . . . . . . . . 15
5.1 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 17
6. The User Part . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
Normative References . . . . . . . . . . . . . . . . . . . . 23
Informative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . 26
Van Dyke, et al. Expires July 28, 2003 [Page 2]
Internet-Draft SIP Media Services January 2003
1. Overview
In SIP-based media networks (RFC3261 [2]), 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.
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, or combinations of the above.
In some situations, one must play the announcement without providing
an answer indication. In others, one must play the announcement
after completing call setup. This document describes how to provide
such announcements in a SIP-based network.
Media mixing is the act of mixing different RTP streams, as described
in RFC1889 [8]. Note that the service described here will suffice
for simple mixing of media for a basic conferencing service. One can
create a complete conferencing service using this basic building
block. However, this service does not address the interesting
application-level issues such as floor control for conferencing, etc.
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 [9] or MSCML [10].
Van Dyke, et al. Expires July 28, 2003 [Page 3]
Internet-Draft SIP Media Services January 2003
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. Media servers do
not have a concept of a user. Thus we use the user address, or the
left-hand-side of the URI, as a service indicator.
Note that the set of services is small, well defined, and well
contained. The section The User Part (Section 6) discusses the
issues with using a fixed set of user-space names.
For per-service security, the media server MAY use any of the
security protocols described in RFC3261 [2].
The media server MAY issue 401 challenges for authentication.
The media server, upon receiving the 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 RFC3261 [2], 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 %3C).
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=values.
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.
Van Dyke, et al. Expires July 28, 2003 [Page 4]
Internet-Draft SIP Media Services January 2003
If the media server can perform the requested service, it does so,
following the processing steps described in the service definition
document (see IANA Considerations (Section 8)).
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. RFC3261 [2] 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.
Van Dyke, et al. Expires July 28, 2003 [Page 5]
Internet-Draft SIP Media Services January 2003
3. Announcement Service
A network announcement is the delivery of an audio resource, such as
a prompt file, to a terminal device.
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 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 prompt and issues a BYE
to the requesting device.
In replicating and expanding on the existing telephone network, there
is a need to play announcements during call setup. That is, the
network delivers media to the caller before the setup completes.
Network operators need this capability to provide informational
network announcements, such as "The person you are trying to reach is
unavailable. Good Bye." or "We are sorry, but all circuits are busy.
Please try your call again later. Good Bye."
Note that simply redirecting the caller to a media server, with the
media server issuing a 200 OK response, is not appropriate. The call
has not completed successfully. To support the appropriate paradigm,
the media server issues a 100 TRYING response, followed immediately
by a 183 SESSION PROGRESS response with SDP. This enables the media
server to send early media to the caller. The media server sends the
requested audio. After playing the audio, the media server issues a
487 REQUEST TERMINATED response code to the requesting device.
If the media server does not support announcements, it MUST respond
with the 488 NOT ACCEPTABLE HERE response code.
If the media server supports announcements, but it cannot find the
referenced URI, it MUST respond with the 404 NOT FOUND response code.
If the media server receives an INVITE for the announcement service
without a "play=" parameter, it MUST respond with the 404 NOT FOUND
response code, as there is no default value for the announcement
service.
If there is an error retrieving the announcement, the media server
Van Dyke, et al. Expires July 28, 2003 [Page 6]
Internet-Draft SIP Media Services January 2003
MUST respond with a 404 NOT FOUND response code. 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 audio resource or announcement sequence to be
played.
early Specifies whether early media treatment is desired.
repeat Specifies how many times the media server should repeat the
announcement or sequence named by the "play=" parameter.
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 country variant of the announcement
sequence named in the "play=" parameter. The language is defined
as a two letter code per ISO 639-1 [3]. The country variant is
also defined as a two letter code per ISO 3166-1 [4]. These
elements are concatenated with a single underbar (%x5F) character.
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.
The "play=" parameter is mandatory and MUST be present. All other
parameters are OPTIONAL.
NOTE: Some encodings are not self-describing. The current
implementation relies on filename extension conventions for
determining the media type.
Van Dyke, et al. Expires July 28, 2003 [Page 7]
Internet-Draft SIP Media Services January 2003
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"; \
early=yes
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.
As described above, the "early=" parameter determines whether the
media server plays the prompt after call setup or as early media.
The default value for the "early=" parameter MUST BE "yes". That is,
the default action is for the media server to play the prompt before
establishing the call. We envision that that this service will be
most commonly used for network announcements which require early
media, hence that is the default behavior.
3.2 Established Call Announcement
3.2.1 Description
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.
The proxy issues an INVITE to the media server, requesting the
appropriate prompt to play coded in the play= parameter. The INVITE
MUST contain the parameter "early=no" to invoke the Established Call
Prompting service. The media server responds with 200 OK. The proxy
sends a 200 OK to the caller. The caller then issues an ACK. The
proxy then issues an ACK to the media server.
With the call setup, 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.
Van Dyke, et al. Expires July 28, 2003 [Page 8]
Internet-Draft SIP Media Services January 2003
3.2.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 Early Media Announcement
3.3.1 Description
The caller issues an INVITE to the serving SIP Proxy. Normally, the
SIP Proxy would complete the call to the requested destination.
However, if the destination is not available, the proxy will request
a media server to play an audio prompt to the caller. The proxy
responds with a 100 TRYING.
The proxy issues an INVITE to the media server, requesting the
appropriate prompt to play. The INVITE MAY contain the parameter
"early=yes" or omit the "early=" parameter to invoke the Early Media
Prompting service. The media server responds with 100 TRYING
followed by 183 SESSION PROGRESS. At that point, the media server
sends the announcement to the caller. RFC3261 [2] describes the 183
SESSION PROGRESS result code.
As stated above, if the Media Server cannot fetch the URI in the
"play=" parameter, the Media Server will reply with a 404 NOT FOUND,
possibly with an explanation of the failure in the Warning: header.
Otherwise, after the media server completes the streaming of the
prompt, it MUST send a 487 REQUEST TERMINATED to the Proxy.
Van Dyke, et al. Expires July 28, 2003 [Page 9]
Internet-Draft SIP Media Services January 2003
Note: When the early media service is used the requester is
implicitly asking the media server to cancel the transaction as soon
as the announcement is played. Since 487 is associated with an
explicit CANCEL request it is appropriate for this use as well.
The proxy sends the appropriate error response to the caller. That
could be 487 or any other appropriate code reflective of the failure
situation.
3.3.2 Protocol Diagram
Caller Proxy Media Server
| INVITE | |
|----------------------->| INVITE |
| 100 TRYING |----------------------->|
|<-----------------------| 100 TRYING |
| |<-----------------------|
| | 183 SESSION PROGRESS |
| 183 SESSION PROGRESS |<-----------------------|
|<-----------------------| |
| | |
| Play Announcement (RTP) |
|<================================================|
| | 487 REQUEST TERMINATED |
| 487 REQUEST TERMINATED |<-----------------------|
|<-----------------------| |
| ACK | ACK |
|----------------------->|----------------------->|
| | |
3.4 Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC2234 [5].
ANNC-URL = "sip:" annc-ind "@" hostport
annc-parameters
annc-ind = "annc"
annc-parameters = ";" play-param [ ";" early-param ]
[ ";" content-param ]
[ ";" delay-param]
[ ";" duration-param ]
[ ";" repeat-param ]
[ ";" locale-param ]
Van Dyke, et al. Expires July 28, 2003 [Page 10]
Internet-Draft SIP Media Services January 2003
[ ";" variable-params ]
play-param = "play=" prompt-url
early-param = "early=" ( "yes" | "no" )
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
locale-param = "locale=" locale-value
locale-value = 2ALPHA %x5F 2ALPHA
variable-params = param-name "=" variable-value
param-name = "param" DIGIT ; e.g "param1"
variable-value = 1*(ALPHA | DIGIT)
The MIME-type is the MIME [6] content type for the announcement, such
as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on.
To date, none of the IETF audio MIME registrations have parameters.
Vendor-specific registrations, such as audio/x-wav, do have
parameters. However, they are not strictly needed for prompt
fetching.
On the other hand, the prevalence of parameters may change in the
future. In addition, existing video registrations have parameters,
such as 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.
Van Dyke, et al. Expires July 28, 2003 [Page 11]
Internet-Draft SIP Media Services January 2003
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 2-letter language code as specified in
ISO 639-1 [3] and a 2-letter country code specified in ISO 3166-1 [4]
separated by a single underbar (%x5Fh) character.
The definition of hostport is as specified by RFC3261 [2].
The syntax of prompt-url consists of a URL scheme as specified by
RFC2396 [7] or a special token indicating a provisioned announcement
sequence. We expect the URL to be one of the following schemes.
o http
o ftp
o file (referencing a local or NFS (RFC3010 [11])
o nfs (RFC2224 [12])
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.
Van Dyke, et al. Expires July 28, 2003 [Page 12]
Internet-Draft SIP Media Services January 2003
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.
4.1 Formal Syntax for Prompt and Collect Service
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC2234 [5].
DIALOG-URL = "sip:" dialog-ind "@" hostport
dialog-parameters
dialog-ind = "dialog"
dialog-parameters = ";" dialog-param [ vxml-parameters ]
dialog-param = "voicexml=" dialog-url
vxml-parameters = vxml-param [ vxml-parameters ]
vxml-param = ";" vxml-keyword "=" vxml-value
vxml-keyword = token
vxml-value = token
The dialog-url is the URI of the VoiceXML script. If present, other
parameters get passed to the VoiceXML interpreter session with the
assigned vxml-keyword vxml-value pairs. Note that all vxml-keywords
MUST have values. The media server presents the parameters as
environment variables in the connection object. Specifically, the
parameter appears in the connection.sip tree.
If the Media Server does not support the passing of keyword-value
pairs to the VoiceXML interpreter session, it MUST ignore the
Van Dyke, et al. Expires July 28, 2003 [Page 13]
Internet-Draft SIP Media Services January 2003
parameters.
Van Dyke, et al. Expires July 28, 2003 [Page 14]
Internet-Draft SIP Media Services January 2003
5. Conference Service
One identifies mixing sessions through their SIP request URIs. To
create a mixing session, one sends an INVITE to a request URI that
represents the session. If the URI does not already exist on the
media server and the requested resources are available, the media
server creates a new mixing session. If there is an existing URI for
the session, then the media server interprets it as a request for the
new session to join the existing session. The form of the SIP
request URI for conferencing is:
sip:conf=uniqueIdentifier@mediaserver.example.net
The left-hand side of the request URI is actually the username of the
request in the request URI and the To header. The host portion of
the URI identifies a particular media server. The "conf=" portion of
the user part conveys to the media server that this is a request for
the mixing service. The uniqueIdentifier can be any value that is
compliant with the SIP URI specification. It is the responsibility
of the conference control application to ensure the identifier is
unique within the scope of any potential conflict.
It is worth noting that the conference URI shared between the
application and media provides enhanced security, as the SIP control
interface does not have to be exposed to participants. It also
allows the assignment of a specific media server to be delayed as
long as possible, thereby simplifying resource management.
One can add additional legs to the conference by INVITEing them to
the above mentioned request URI. Conversely, one can remove legs by
issuing a BYE in the corresponding dialog. The mixing session, and
thus the conference-specific request URI, remains active so long as
there is at least one SIP dialog associated with the given request
URI.
5.1 Protocol Diagram
This diagram shows the establishment of a three-way conference.
This section is informative.
P1 P2 P3 Application Server Media Server
| | | | |
| INVITE sip:public-conf@as.c.net | |
|---------------------------------->| INVITE sip:conf=123@ms.c.net
| | | |------------------>|
| | | | 200 OK |
| 200 OK | |<------------------|
|<----------------------------------| |
Van Dyke, et al. Expires July 28, 2003 [Page 15]
Internet-Draft SIP Media Services January 2003
| | | RTP w/ P1 | |
|<=====================================================>|
| | | | |
| INVITE sip:public-conf@as.c.net | |
| |-------------------------->| INVITE sip:conf=123@ms.c.net
| | | |------------------>|
| | | | 200 OK |
| | 200 OK | |<------------------|
| |<--------------------------| |
| | | | |
| | | RTP w/ P1+P2-P2 | |
| |<=============================================>|
| | | RTP w/ P1+P2-P1 | |
|<=====================================================>|
| | | | |
| INVITE sip:public-conf@as.c.net | |
| | |----------------->| INVITE sip:conf=123@ms.c.net
| | | |------------------>|
| | | | 200 OK |
| | | 200 OK |<------------------|
| | |<-----------------| |
| | | | |
| | | RTP w/ P1+P2+P3-P3 |
| | |<====================================>|
| | | RTP w/ P1+P2+P3-P2 |
| |<=============================================>|
| | | RTP w/ P1+P2+P3-P1 |
|<=====================================================>|
| | | | |
| | | | |
Note that the above call flow does not show any 100 TRYING messages
that would typically flow from the Application Server to the UAC's,
nor does it show the ACK's from the UAC's to the Application Server
or from the Application Server to the Media Server.
Each leg can drop out either under the supervision of the UAC by the
UAC sending a BYE or under the supervision of the Application Server
by the Application Server issuing a BYE. In either case, the
Application Server will either issue a BYE on behalf of the UAC or
issue it directly to the Media Server, corresponding to the
respective disconnect case.
It is left as a trivial exercise to the reader for how the
Application Server can mute legs, create side conferences, and so
forth.
Note that the Application Server is a server to the participants
Van Dyke, et al. Expires July 28, 2003 [Page 16]
Internet-Draft SIP Media Services January 2003
(UAC's). However, the Application Server is a client for mixing
services to the Media Server.
5.2 Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC2234 [5].
CONF-URL = "sip:" conf-ind "=" instance-id "@" hostport
conf-ind = "conf"
instance-id = token
Van Dyke, et al. Expires July 28, 2003 [Page 17]
Internet-Draft SIP Media Services January 2003
6. The User Part
There has been considerable debate about the wisdom of using fixed
user parts in a request URI. The most common objection is that the
user part should be opaque and a local matter. The other objection
is that using a fixed user part removes those specified user
addresses from the user address space.
We will address the latter issue first. The common example is the
Postmaster address defined by RFC2821 [13]. The objection is that by
using the Postmaster token for something special, one removes that
token for anyone. Thus, the Postmaster General of the United States,
for example, cannot have the mail address Postmaster@usps.gov. One
may debate whether this is a significant limitation, however.
One may point out that "annc", for example, has the potential for
more conflict than Postmaster. This is true. However, one cannot
confuse the namespace at a Media Server with the namespace for an
organization.
For example, let us take the case where a network offers services for
"Ann Charles". She likes to use the name "annc", and thus she would
like to use "sip:annc@provider.net". We offer that there is
ABSOLUTELY NO NAME COLLISION WHATSOEVER. Why is this so? This is so
because sip:annc@provider.net will resolve to the specific user at a
specific device for Ann. As an example, provider.net's SIP Proxy
Server can resolve sip:annc@provider.net to
annc@anns-phone.provider.net . One directs requests for the media
service annc directly to the Media Server, e.g.,
sip:annc@ms21.ap.provider.net . Moreover, by definition, Ann
Charles, or anything other than the announcement service, will NEVER
be directly on the Media Server. If that were not true, no phone in
the world could use the user part "eburger", as eburger is a reserved
user part in the SnowShore domain.
The most important thing to note about this convention is that the
left-hand side of the request URI is opaque to the network. The only
network elements that need to know about the convention are the Media
Server and client.
Some have proposed that such naming be a pure matter of local
convention. For example, the thesis of the informational RFC3087
[14] is that you can address services using a request URI. However,
some have taken the examples in the document to an extreme. Namely,
that the only way to address services is via arbitrary, opaque, long
user parts. It is possible to provision the service names, rather
than fixed names. While this can work in a closed network, where the
Application Servers and Media Servers are in the same administrative
Van Dyke, et al. Expires July 28, 2003 [Page 18]
Internet-Draft SIP Media Services January 2003
domain, this does not work across domains. This is because the
client of the media service has to know the local name for each
service / domain pair. This is particularly onerous for situations
where there is an ad hoc relationship between the application and the
media service. Without a well-known relationship between service and
service address, how would the client locate the service?
One very important result of using the user part as the service
descriptor is that we can use all of the standard SIP machinery,
without modification. For example, Media Servers with different
capabilities can SIP Register their capabilities as users. For
example, a mixing-only device will register the "conf" user, while a
multi-purpose Media Server will register all of the users. Note that
this is why the URI to play is a parameter. Doing otherwise would
overburden a normal SIP proxy or redirect server. Likewise, this
scheme lets us leverage the standard SIP proxy behavior of using an
intelligent redirect server or proxy server to provide high-available
services. For example, two Media Servers can register with a SIP
redirect server for the annc user. If one of the Media Servers
fails, the registration will expire and all requests for the
announcement service ("calls to the annc user") get sent to the
surviving Media Server.
Van Dyke, et al. Expires July 28, 2003 [Page 19]
Internet-Draft SIP Media Services January 2003
7. Security Considerations
Untrusted network elements could use the protocol described here for
providing information services. Many extant billing arrangements are
for completed calls. Successful call completion occurs with a 2xx
result code. This can be an issue for the early media announcement
service, and service providers should plan their network service
offerings accordingly.
Exposing network services with well-known addresses may not be
desirable. In this case, the Media Server should offer local policy,
e.g., only accept requests from authorized clients. Barring that,
one can use a SIP Proxy to enforce the local policy.
Van Dyke, et al. Expires July 28, 2003 [Page 20]
Internet-Draft SIP Media Services January 2003
8. IANA Considerations
Because of great consternation about whether or not there would be a
generic application name space, it was decided that we would not
establish an IANA registry.
Van Dyke, et al. Expires July 28, 2003 [Page 21]
Internet-Draft SIP Media Services January 2003
9. Acknowledgements
We would like to thank Kevin Summers and Ravindra Kabre of Sonus
Networks for their constructive comments, as well as Jonathan
Rosenberg of Dynamicsoft and Tim Melanchuk for their encouragement.
In addition, the discussion at the Las Vegas Interim Workgroup
Meeting in 2002 was invaluable for clearing up the issues surrounding
the left-hand-side of the request URI. Pete Danielson from Lucent
provided an excellent review of the -00 draft.
The authors would like to give a special thanks to Walter O'Connor
for doing most of the implementations.
Van Dyke, et al. Expires July 28, 2003 [Page 22]
Internet-Draft SIP Media Services January 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] ISO, "Codes for the representation of names of languages -- Part
1: Alpha-2 code", ISO 639-1, July 2002.
[4] ISO, "Codes for the representation of names of countries and
their subdivisions -- Part 1: Country codes", ISO 3166-1,
October 1997.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[6] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, September
1993.
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
Van Dyke, et al. Expires July 28, 2003 [Page 23]
Internet-Draft SIP Media Services January 2003
Informative References
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[9] World Wide Web Consortium, "Voice Extensible Markup Language
(VoiceXML) Version 2.0", W3C Working Draft , April 2002,
<http://www.w3.org/TR/voicexml20/>.
[10] Burger, E., Van Dyke, J. and A. Spitzer, "SnowShore Media
Server Control Markup Language and Protocol",
draft-vandyke-mscml-00 (work in progress), November 2002.
[11] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
3010, December 2000.
[12] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[13] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[14] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
[15] Charlton, N., Gasson, M., Gybels, G., Spanner, M. and A. van
Wijk, "User Requirements for the Session Initiation Protocol
(SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
Individuals", RFC 3351, August 2002.
Authors' Addresses
Jeff Van Dyke
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
EMail: jvandyke@snowshore.com
Van Dyke, et al. Expires July 28, 2003 [Page 24]
Internet-Draft SIP Media Services January 2003
Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
EMail: e.burger@ieee.org
Andy Spitzer
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
EMail: woof@snowshore.com
Van Dyke, et al. Expires July 28, 2003 [Page 25]
Internet-Draft SIP Media Services January 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Van Dyke, et al. Expires July 28, 2003 [Page 26]
Internet-Draft SIP Media Services January 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
SnowShore Networks, Inc. is a member of the Internet Society.
Van Dyke, et al. Expires July 28, 2003 [Page 27]
