SIP J. Rosenberg
Internet-Draft Cisco
Intended status: Standards Track November 12, 2007
Expires: May 15, 2008
A Session Initiation Protocol (SIP) Media Feature Tag for MIME
Application Sub-Types
draft-rosenberg-sip-app-media-tag-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The caller preferences specification for the Session Initiation
Protocol (SIP) allows a caller to express preferences that the call
be routed to a User Agent (UA) with particular capabilities.
Similarly, a specification exists to allow a UA to indicate its
capabilities in a registration. Amongst those capabilities are the
type of media streams the agent supports, described as top-level MIME
types. The 'application' MIME type is used to describe a broad range
Rosenberg Expires May 15, 2008 [Page 1]
Internet-Draft Application Sub-Type Tag November 2007
of stream types, and provides insufficient granularity as a
capability. This specification allows a UA to indicate which
application sub-types the agent supports.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. sip.app-subtype Media Feature Tag . . . . . . . . . . . . . . . 4
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Rosenberg Expires May 15, 2008 [Page 2]
Internet-Draft Application Sub-Type Tag November 2007
1. Introduction
The caller preferences specification [RFC3841] for the Session
Initiation Protocol (SIP) [RFC3261] allows a user to express
preferences for the routing of SIP requests. These preferences are
expressed as a set of desired capabilities and characteristics of a
receiving agent. When a user agent registers to the SIP network, it
includes, as part of its registration, its own capabilities and
characteristics [RFC3840]. These capabilities are stored as part of
the registration, and then made available to the proxy in the
network. When a request arrives at the proxy with caller
preferences, the preferences in the request are compared with the
supported characteristics and capabilities stored in the
registrations, and the result is used to select the target user
agents for the request.
RFC 3840 makes use of media feature tags [RFC2506]. Each tag has a
name and a type. The tags defined in RFC 3840 describe some of the
basic characteristics of user agents, including whether they are
automata or not (the sip.automata tag), their class (the sip.class
tag), whether they support media in one or both directions (the
sip.duplex), and whether they are a conference focus (sip.isfocus).
These tags also include SIP protocol capabilities, including the
schemes supported by the agent (sip.schemes), the methods
(sip.methods), and the event packages [RFC3265] (sip.events).
RFC 3840 also defines media feature tags for multimedia stream types.
There is a media feature tag defined for each top-level media type -
sip.audio for audio streams, sip.video for video streams, and so on.
The primary use case for this is to correctly deliver multimedia
sessions to the user agent that supports that media type. Consider a
caller on a videophone that wants to have a video call with another
user. That user has two devices - a mobile phone that only supports
audio, and a videophone. We'd like to deliver the videophone call to
the videophone as a first priority, and only 'ring' the mobile device
for an audio-only call if the user is not present on the videophone.
RFC 3840 defines media feature tags for each and every top-level
media type, including 'application'. This media type covers an
extremely broad range of subtypes - multiplayer games of all sorts,
shared whiteboards and application sharing, and so on. With audio
and video, where there is often a common codec supported by agents
(i.e., a common subtype). Consequently, if a caller wants an audio
session, routing the request to any user agent that supports audio is
likely to result in successful communications. However, with
application streams, just routing a request to an agent that supports
*some* application stream isn't useful; application streams for
different applications are wildly different. Consequently, the
Rosenberg Expires May 15, 2008 [Page 3]
Internet-Draft Application Sub-Type Tag November 2007
application media feature tag does not provide sufficient granularity
for call preferences. The specific application sub-type needs to be
indicated as well.
To remedy this, this specification defines a new media feature tag
that indicates which application sub-types are supported by the agent
for streaming. The name of this media feature tag is 'sip.app-
subtype'.
2. Terminology
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 [RFC2119].
3. sip.app-subtype Media Feature Tag
The 'sip.app-subtype' media feature tag is of type token with a case-
sensitive equality relationship. Its value can be any registered or
private MIME application sub-type. When included in the Contact
header field of a REGISTER request, an agent SHOULD include all
application subtypes that it can support as streaming formats. An
application sub-type is supported if the user agent would be capable
of processing an Session Description Protocol (SDP) [RFC4566] offer
[RFC3264] that contained that sub-type as a format in the m-line of
the SDP.
When included in the Accept-Contact or Reject-Contact header field,
it indicates a desire on the part of a UAC to be connected to a UAS
which can support, or cannot support respectively, streaming using
that application sub-type.
It is important to note that this media feature tag is only
indicating the streaming media types that a user agent is capable of
supporting. It says nothing about the functionality provided by the
user agent itself, or the MIME types that the agent can send or
receive in SIP messages or emails. For example, let us assume that a
SIP user agent is capable of supporting a chess game. The game is
played by each user sending chess moves as binary objects over UDP
between a pair of user agents. Those objects have a MIME type of
"application/example". When a UA includes the sip.app-subtype media
feature tag in a Contact header field with a value of "example", it
means that the UA can handle a SIP INVITE that contained an SDP with
an application media line and format of "example". It does not mean
that the SIP user agent is a chess application, or that the user
agent can accept SIP requests that include bodies of type
Rosenberg Expires May 15, 2008 [Page 4]
Internet-Draft Application Sub-Type Tag November 2007
"application/example". To indicate that a user agent can accept SIP
requests that include bodies of type "application/example", the agent
would utilize the "type" media feature tag as defined in [RFC3840].
A consequence of this is that, as new streaming media type formats
are defined (such as game stream formats, whiteboard session formats,
and so on, they SHOULD be defined using the SDP application stream,
and utilize a MIME application sub-type.
4. Example
The following is an example SIP REGISTER message fragment indicating
usage of this media feature tag. The REGISTER indicates that the UA
can particiate in application media sessions utilizing exchange of
objects of type "application/example".
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
;+sip.app-subtype="example"
Such a registration indicates that an INVITE of the following form:
INVITE sip:Y@example.com SIP/2.0
To: sip:Y@example.com
Content-Type: application/sdp
Content-Length: ...
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
c=IN IP4 192.0.1.2
t=0 0
m=audio 49170 RTP/AVP 0
m=application 8493 udp example
Rosenberg Expires May 15, 2008 [Page 5]
Internet-Draft Application Sub-Type Tag November 2007
would be accepted by the UA. The SDP in the INVITE indicates an
audio session and an application session which runs over UDP and
exchanges "application/example" object formats.
5. Security Considerations
When present in a REGISTER request, this media feature tag gives
information on the set of supported application media streams. It is
possible that this information is sensitive, providing insight into
the capabilities of a product. These considerations are already
discussed in RFC 3840, and those considerations apply here as well.
Applications which utilize this media feature tag SHOULD provide a
means for ensuring its integrity. Similarly, the media feature tag
should only be trusted as valid when it comes from the user or user
agent described by the feature tag. As a result, mechanisms for
conveying the feature tag SHOULD provide a mechanism for guaranteeing
authenticity.
6. IANA Considerations
This specification adds a new media feature tag to the SIP Media
Feature Tag Registration Tree defined in RFC 3840 [RFC3840].
Media feature tag name: sip.app-subtype
ASN.1 Identifier: 1.3.6.1.8.4.22
Summary of the media feature indicated by this tag: This feature tag
indicates the MIME application sub-types supported by the agent
for purposes of streaming media.
Values appropriate for use with this feature tag: Token.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Routing a call to a phone that can support
a multiplayer game.
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]]
Rosenberg Expires May 15, 2008 [Page 6]
Internet-Draft Application Sub-Type Tag November 2007
Security Considerations: Security considerations for this media
feature tag are discussed in Section 5 of RFC XXXX . [[Note to
IANA: Please replace XXXX with the RFC number of this
specification.]]
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
7.2. Informative References
[RFC3261] 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.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999.
Rosenberg Expires May 15, 2008 [Page 7]
Internet-Draft Application Sub-Type Tag November 2007
Author's Address
Jonathan Rosenberg
Cisco
Edison, NJ
US
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires May 15, 2008 [Page 8]
Internet-Draft Application Sub-Type Tag November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rosenberg Expires May 15, 2008 [Page 9]