Movatterモバイル変換

Internet Engineering Task Force (IETF)                      J. RosenbergRequest for Comments: 5688                                         SkypeCategory: Standards Track                                   January 2010ISSN: 2070-1721A Session Initiation Protocol (SIP) Media Feature Tag for MIMEApplication SubtypesAbstract   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 it provides insufficient granularity as a   capability.  This specification allows a UA to indicate which   application subtypes the agent supports.Status of This Memo   This is an Internet Standards Track document.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Further information on   Internet Standards is available inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc5688.Copyright Notice   Copyright (c) 2010 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.  Code Components extracted from this document mustRosenberg                   Standards Track                     [Page 1]

RFC 5688                Application Subtype Tag             January 2010   include Simplified BSD License text as described in Section 4.e of   the Trust Legal Provisions and are provided without warranty as   described in the Simplified BSD License.   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.Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .22.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .33.  sip.app-subtype Media Feature Tag . . . . . . . . . . . . . . .34.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . .45.  Security Considerations . . . . . . . . . . . . . . . . . . . .56.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .57.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .67.1.  Normative References  . . . . . . . . . . . . . . . . . . .67.2.  Informative References  . . . . . . . . . . . . . . . . . .71.  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 inRFC 3840 describe some of the   basic characteristics of user agents, including whether or not they   are automata (the sip.automata tag), their class (the sip.class tag),Rosenberg                   Standards Track                     [Page 2]

RFC 5688                Application Subtype Tag             January 2010   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 capabilities, including the schemes   supported by the agent (sip.schemes), the methods (sip.methods), and   the event packages (sip.events) [RFC3265].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 subtype needs to be   indicated as well.   To remedy this, this specification defines a new media feature tag   that indicates which application subtypes 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 inRFC 2119 [RFC2119].3.  sip.app-subtype Media Feature Tag   The 'sip.app-subtype' media feature tag is of type token with a case-   insensitive equality relationship.  Its value can be any registered   or private MIME application subtype compliant to the subtype-nameRosenberg                   Standards Track                     [Page 3]

RFC 5688                Application Subtype Tag             January 2010   grammar defined in [RFC4288].  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   subtype is supported if the user agent would be capable of processing   a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that   contained that subtype 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 User Agent Client (UAC) to be   connected to a User Agent Server (UAS) that can support or cannot   support, respectively, streaming using that application subtype.   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].   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 subtype.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 participate in application media sessions utilizing exchange of   objects of type "application/example".Rosenberg                   Standards Track                     [Page 4]

RFC 5688                Application Subtype Tag             January 2010   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 that 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 inRFC 3840, and those considerations apply here as well.   Applications that 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 inRFC 3840 [RFC3840].Rosenberg                   Standards Track                     [Page 5]

RFC 5688                Application Subtype Tag             January 2010   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 subtypes supported by the agent for      purposes of streaming media.   Values appropriate for use with this feature tag:  Token (equality      relationship).   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 5688   Security Considerations:  Security considerations for this media      feature tag are discussed inSection 5 of RFC 5688.7.  References7.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.   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and              Registration Procedures",BCP 13,RFC 4288, December 2005.   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session              Description Protocol",RFC 4566, July 2006.Rosenberg                   Standards Track                     [Page 6]

RFC 5688                Application Subtype Tag             January 20107.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.Author's Address   Jonathan Rosenberg   Skype   Monmouth, NJ   USA   EMail: jdrosen@jdrosen.net   URI:http://www.jdrosen.netRosenberg                   Standards Track                     [Page 7]