Internet DRAFT - draft-burger-sipping-msuri
draft-burger-sipping-msuri
Network Working Group J. Van Dyke
Internet Draft E. Burger
Document: draft-burger-sipping-msuri-01.txt SnowShore Networks, Inc.
Category: Standards Track November 21, 2001
Expires: May 2002
SIP URI Conventions for Media Servers
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Discussion of this document is on the SIPPING discussion list. The
SIPPING list is at <mailto:sipping-request@ietf.org>.
1. Abstract
Application Servers, SIP Proxies, and SoftSwitches (a.k.a. Media
Gateway Controllers) act as SIP [2] User Agents to control the media
processing capabilities of media servers. The SIP Request URI
identifies the desired service and provides a context for the media
server to interpret the SIP message. This document describes a
standard SIP addressing mechanism to address specific services.
Because of SIP's flexibility, the existing protocol accommodates
these services. This document proposes a standard URI scheme for
important media services such as announcements and conferencing.
Van Dyke Draft û Expires 5/21/02 1
SIP Media Server URI Conventions November 2001
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [3].
FORMATTING NOTE: Notes, such at this one, provide additional,
nonessential information that the reader may skip without missing
anything essential. The primary purpose of these non-essential
notes is to convey information about the rationale of this document,
or to place this document in the proper historical or evolutionary
context. Readers whose sole purpose is to construct a conformant
implementation may skip such information. However, it may be of use
to those who wish to understand why we made certain design choices.
Table of Contents
1. Abstract...........................................................1
2. Conventions used in this document..................................2
3. Overview...........................................................2
4. Service Definition.................................................3
5. Service Indicators and URI Signatures..............................3
6. Operation..........................................................4
7. Formal Syntax......................................................5
8. Security Considerations............................................5
9. IANA Considerations................................................5
10. Examples..........................................................6
10.1. Announcement....................................................6
10.2. Conference......................................................7
11. References........................................................7
12. Changes Made in Version 01........................................8
13. Acknowledgments...................................................8
14. Author's Addresses................................................8
3. Overview
Media servers are devices that perform media processing on real-time
packet media. Examples of such processing are tone detection and
generation, packet recording (usually with transcoding), packet
playing (usually with transcoding - also known as prompting), and
mixing (also known as conferencing).
These services are of general utility to a wide array of SIP UA's
including application servers, softswitches and proxy servers. In
addition, the behaviors and semantics of these services are well
understood. For these reasons, it is both desirable and possible to
create standard SIP interfaces for these services.
Van Dyke Expires 5/21/2002 2
SIP Media Server URI Conventions November 2001
4. Service Definition
A service is a set of related media processing features with a well-
defined set of properties. The defining properties of a service are
its SIP URI signature, the MIME types it accepts and any
SUBSCRIBE/NOTIFY [4] event packages it supports. The SIP URI
signature consists of the service indicator, instance ID and any
associated URI parameters.
Services MUST have a unique SIP URI signature. Services MAY offer
support for MIME types other than "application/sdp" and
SUBSCRIBE/NOTIFY event packages if required to implement service
features.
In the context of SIP control of media servers, we take advantage of
the fact that the standard SIP URI has a user part [2]. Media
processing services may be thought of as user automatons that
participate in SIP sessions. It naturally follows that the user
address, or the left-hand-side of the URI, should be utilized as a
service indicator.
Media servers commonly offer multiple services at a single host
address. Use of the user part as a service indicator enables
service consumers to direct their requests without ambiguity. It
has the added benefit of enabling media services to register their
availability with SIP Registrars just as any "real" SIP user would.
This maintains consistency and provides enhanced flexibility in the
deployment of media services in the network.
For per-service security, the media server MAY use any of the
security protocols described in [2].
Following [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.
5. Service Indicators and URI Signatures
The service indicator is the concatenation of the service name and
an optional service instance identifier, separated by an equal sign.
The service name MAY be modified by an optional service namespace.
There has been much discussion about the potential for confusion if
media services URIs are not readily distinguishable from other types
of SIP UA's. The use of a service namespace provides a mechanism to
unambiguously identify standard interfaces while not constraining
the development of private or experimental services.
Van Dyke Expires 5/21/2002 3
SIP Media Server URI Conventions November 2001
It is proposed that standard services, such as the announcement and
conferencing services described here, be registered with IANA using
the "org.iana" service namespace.
Service developers MAY use a service namespace other than "org.iana"
for private or experimental services.
Per [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 in [2] 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 as set out in [2]. An equal sign, US-ASCII %3D, MUST
separate the service indicator from the unique identifier.
Note that since the service indicator is case insensitive per [2],
the service instance identifier is also case insensitive.
6. Operation
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 (see IANA Considerations, below).
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. [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
Van Dyke Expires 5/21/2002 4
SIP Media Server URI Conventions November 2001
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.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [6].
SERVICE-URL = "sip:" [srvc-namespace] srvc-ind "@" hostport
url-parameters [headers]
srvc-namespace = ("org.iana" "." | 1*nmspc-part)
nmspc-part = 1*(ALPHA | DIGIT) "."
srvc-ind = srvc-name [ "=" instanceId ]
srvc-name = "annc" | "conf" | token
instanceId = token
Section 2 of [2] defines the elements hostport and token. See the
IANA Considerations section for procedures for adding new service
indicators.
8. Security Considerations
The security issues are the same as for SIP [2], as the media server
is simply a SIP User Agent.
9. IANA Considerations
This document describes an extensible set of SIP Media Server
Service Indicator types. To promote interoperability and coherent
interpretations of different types, we need a central repository for
well-known service indicator types.
IANA will create a repository for service indicator types called
"SIP Media Server Service Indicator Types". Following the policies
outlined in [7], this repository is "Specification Required by RFC."
The documents [8] and [10] describe the initial values for the
repository. For reference, the values are as follows.
NOTE: Drafts describing service indicators for conferencing,
transcoding and IVR are currently being developed.
Van Dyke Expires 5/21/2002 5
SIP Media Server URI Conventions November 2001
SIP Media Server Service Indicator Types
========================================
Value Meaning Reference
----- -------------- ---------
Parameter Values
----------- ------
annc Announcement Service draft-burger-sipping-netann-01.txt
play= URI or provisioned sequence identifier
early= ( "yes" | "no" )
repeat= Integer, number of repetitions
delay= Integer, delay between repetitions
duration= Integer, max. prompt duration
locale= Language and country codes
param[n]= Variable values to be substituted in
a sequence
conf Conference Service
<none>
10. Examples
These examples are informative. For the normative definitions of
the given services, see the referenced documents.
NOTE: The line wrapping (backslash, CRLF, and spacing before
continued lines) in the examples is for readability purposes only.
10.1. Announcement
The document [8] fully specifies the announcement service. In
brief, the announcement service can play a prompt as early media or
after the establishment of a connection.
The announcement service indicator is "annc". The service has
several associated parameters that control the content and delivery
of the announcement.
In the following example, the media server at ms2.carrier.net
retrieves an audio file using HTTP [9] from the server
prompts.carrier.net and plays it as early media.
sip:annc@ms2.carrier.net; \
play="http://prompts.carrier.net/audio/allcircuitsbusy.g711";
\
early=yes
Van Dyke Expires 5/21/2002 6
SIP Media Server URI Conventions November 2001
10.2. Conference
The conference service creates a conference upon the first instance
of a unique service instance identifier. The media server places
subsequent requests with the same service instance identifier into a
conference.
The conference service indicator is "conf". There are no parameters
for the conference service.
In the following example, the media server at ms2.carrier.net
creates (or places into conference) the stream associated with the
SDP in the INVITE to the conference identified by the identifier
"q4unfcqdscQS".
sip:conf=q4unfcqdscQS@ms2.carrier.net
NOTE: A draft describing the conference service in detail is in
progress.
11. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP:
Session Initiation Protocol", draft-ietf-sip-rfc2543bis-03.txt,
May 2001, work in progress.
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
4 Roach, A., "SIP-Specific Event Notification, "draft-ietf-sip-
events-01.txt, November 2001, work in progress.
6 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
7 Alvestrand, H. and Narten, T., "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
8 O'Connor, W., Burger, E., "Network Announcements with SIP",
draft-burger-sipping-netann-01.txt, November 2001, work in
progress.
9 Fielding, R., Gettys, D., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and Berners-Lee, T., "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
Van Dyke Expires 5/21/2002 7
12. Changes Made in Version 01
o Added additional explanatory text to explain motivations for
use of service indicators and benefits of the proposed format.
o Updated description of the announcement service to be
consistent with draft-burger-sipping-netann-01.txt.
o Proposed an option for implementing a namespace for service
indicators.
13. Acknowledgments
We would like to offer our thanks to Jonathan Rosenberg of
dynamicsoft for his constructive comments.
14. Author's Addresses
Jeff Van Dyke
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
Phone: +1 978/367-8405
Email: jvandyke@snowshore.com
Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
Phone: +1 978/367-8403
Email: eburger@snowshore.com
Van Dyke Draft û Expires 5/21/02 8
SIP Media Server URI Conventions November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 assigns. 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 HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
The Internet Society currently provides funding for the RFC Editor
function.
Van Dyke Expires 5/21/2002 9
