A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Sub-Types
draft-rosenberg-sip-app-media-tag-03

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

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 January 30, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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 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
2.  Terminology
3.  sip.app-subtype Media Feature Tag
4.  Example
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address

1.  Introduction

The caller preferences specification [RFC3841] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.) for the Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.). 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] (Holtman, K., Mutz, A., and T. Hardie, “Media Feature Tag Registration Procedure,” March 1999.). 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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) (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 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) offer [RFC3264] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) 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 "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] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.).

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

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] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.).

Media feature tag name:

sip.app-subtype

ASN.1 Identifier:

1.3.6.1.8.4.24

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.]]

Security Considerations:

Security considerations for this media feature tag are discussed in Section 5 (Security Considerations) of RFC XXXX . [[Note to IANA: Please replace XXXX with the RFC number of this specification.]]

7.  References

7.1. Normative References

7.2. Informative References

Author's Address