Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5688 Skype
Category: Standards Track January 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5688 Skype
Category: Standards Track January 2010
ISSN: 2070-1721
A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes
MIME应用程序子类型的会话启动协议（SIP）媒体功能标签
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 it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports.
会话发起协议（SIP）的呼叫者偏好规范允许呼叫者表示将呼叫路由到具有特定功能的用户代理（UA）的偏好。类似地，存在允许UA在注册中指示其能力的规范。这些功能包括代理支持的媒体流类型，称为顶级MIME类型。“应用程序”MIME类型用于描述范围广泛的流类型，它提供的粒度不够作为一种功能。此规范允许UA指示代理支持哪些应用程序子类型。
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 in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5688.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5688.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 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 must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. sip.app-subtype Media Feature Tag . . . . . . . . . . . . . . . 3
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. sip.app-subtype Media Feature Tag . . . . . . . . . . . . . . . 3
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
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.
会话发起协议（SIP）[RFC3261]的呼叫方首选项规范[RFC3841]允许用户表示SIP请求路由的首选项。这些首选项表示为接收代理的一组期望功能和特征。当用户代理注册到SIP网络时，作为注册的一部分，它包括自己的能力和特征[RFC3840]。这些功能作为注册的一部分存储，然后提供给网络中的代理。当带有调用者首选项的请求到达代理时，将请求中的首选项与注册中存储的支持的特征和功能进行比较，并使用结果为请求选择目标用户代理。
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 or not they are automata (the sip.automata tag), their class (the sip.class tag),
RFC 3840使用媒体功能标签[RFC2506]。每个标记都有一个名称和一个类型。RFC 3840中定义的标记描述了用户代理的一些基本特征，包括它们是否是自动机（sip.automata标记）、它们的类（sip.class标记），
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].
它们是否支持一个或两个方向的媒体（sip.duplex），以及它们是否是会议焦点（sip.isfocus）。这些标记还包括SIP功能，包括代理支持的方案（SIP.schemes）、方法（SIP.methods）和事件包（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.
RFC3840还为多媒体流类型定义了媒体功能标签。有一个为每种顶级媒体类型定义的媒体功能标签——sip.audio用于音频流，sip.video用于视频流，等等。这方面的主要用例是将多媒体会话正确地传递给支持该媒体类型的用户代理。考虑视频电话上的来电者想与另一个用户进行视频通话。该用户有两个设备——一个只支持音频的移动电话和一个视频电话。我们希望将可视电话呼叫作为第一优先事项发送到可视电话，并且如果用户不在可视电话上，则只“响铃”移动设备进行音频通话。
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.
RFC 3840为每个顶级媒体类型定义媒体功能标签，包括“应用程序”。这种媒体类型涵盖了极其广泛的子类型——各种多人游戏、共享白板和应用程序共享，等等。对于音频和视频，通常有代理支持的通用编解码器（即，通用子类型）。因此，如果调用者想要音频会话，则将请求路由到支持音频的任何用户代理可能会导致通信成功。然而，对于应用程序流，仅仅将请求路由到支持*某些*应用程序流的代理是没有用的；不同应用程序的应用程序流差别很大。因此，应用程序媒体功能标签没有为调用首选项提供足够的粒度。还需要指出特定的应用程序子类型。
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'.
为了解决这一问题，本规范定义了一个新的媒体功能标签，用于指示代理支持哪些应用程序子类型进行流式处理。此媒体功能标签的名称为“sip.app子类型”。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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-name
“sip.app subtype”媒体功能标记的类型为token，具有不区分大小写的相等关系。其值可以是与子类型名称兼容的任何已注册或私有MIME应用程序子类型
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.
[RFC4288]中定义的语法。当包含在注册请求的Contact header字段中时，代理应该包括它可以支持作为流格式的所有应用程序子类型。如果用户代理能够处理会话描述协议（SDP）[RFC4566]提供[RFC3264]，该协议将该子类型作为SDP的m行格式包含，则支持应用程序子类型。
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.
当包含在“接受联系人”或“拒绝联系人”标题字段中时，它表示用户代理客户端（UAC）希望连接到用户代理服务器（UAS），该服务器可以支持或不支持使用该应用程序子类型的流。
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].
请务必注意，此媒体功能标签仅指示用户代理能够支持的流媒体类型。它没有说明用户代理本身提供的功能或代理可以在SIP消息或电子邮件中发送或接收的MIME类型。例如，假设SIP用户代理能够支持象棋游戏。该游戏由每个用户通过UDP在一对用户代理之间发送象棋移动作为二进制对象来进行。这些对象的MIME类型为“application/example”。当UA在联系人标头字段中包含值为“example”的sip.app-subtype媒体功能标签时，这意味着UA可以处理包含SDP的sip INVITE，其应用媒体行和格式为“example”。这并不意味着SIP用户代理是chess应用程序，或者用户代理可以接受包含类型为“application/example”的主体的SIP请求。为了指示用户代理可以接受包括“应用程序/示例”类型主体的SIP请求，该代理将利用[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.
这样做的结果是，在定义新的流媒体类型格式（如游戏流格式、白板会话格式等）时，应使用SDP应用程序流定义它们，并使用MIME应用程序子类型。
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".
下面是一个示例SIP REGISTER消息片段，指示此媒体功能标签的使用。寄存器表明UA可以利用“应用程序/示例”类型对象的交换来参与应用程序媒体会话。
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"
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: ...
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
v=0 o=jdoe 2890844526 IP4 10.47.16.5中的2890842807 c=IP4 192.0.1.2中的t=0 0 m=audio 49170 RTP/AVP 0 m=application 8493 udp示例
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.
将被UA接受。INVITE中的SDP表示通过UDP运行的音频会话和应用程序会话，并交换“应用程序/示例”对象格式。
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 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.
当出现在注册请求中时，此媒体功能标签提供有关支持的应用程序媒体流集的信息。这些信息可能是敏感的，可以提供对产品功能的洞察。RFC 3840中已经讨论了这些注意事项，这些注意事项也适用于此处。使用此媒体功能标签的应用程序应提供确保其完整性的方法。类似地，只有当媒体功能标签来自功能标签描述的用户或用户代理时，才应将其视为有效。因此，传递特征标签的机制应该提供一种保证真实性的机制。
This specification adds a new media feature tag to the SIP Media Feature Tag Registration Tree defined in RFC 3840 [RFC3840].
本规范向RFC 3840[RFC3840]中定义的SIP媒体功能标签注册树添加新的媒体功能标签。
Media feature tag name: sip.app-subtype
媒体功能标签名称：sip.app-subtype
ASN.1 Identifier: 1.3.6.1.8.4.24
ASN.1标识符：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.
此标记指示的媒体功能摘要：此功能标记指示代理支持的用于流媒体的MIME应用程序子类型。
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.
该特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述诸如电话或PDA之类的设备的能力。
Examples of typical use: Routing a call to a phone that can support a multiplayer game.
典型用途示例：将呼叫路由到支持多人游戏的手机。
Related standards or documents: RFC 5688
相关标准或文件：RFC 5688
Security Considerations: Security considerations for this media feature tag are discussed in Section 5 of RFC 5688.
安全注意事项：RFC 5688第5节讨论了此媒体功能标签的安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC2506]Holtman，K.，Mutz，A.，和T.Hardie，“媒体功能标签注册程序”，BCP 31，RFC 2506，1999年3月。
Author's Address
作者地址
Jonathan Rosenberg Skype Monmouth, NJ USA
Jonathan Rosenberg Skype Monmouth，美国新泽西州
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net