Network Working Group E. Burger, Ed.
Request for Comments: 4240 J. Van Dyke
Category: Informational A. Spitzer
Brooktrout Technology, Inc.
December 2005
Network Working Group E. Burger, Ed.
Request for Comments: 4240 J. Van Dyke
Category: Informational A. Spitzer
Brooktrout Technology, Inc.
December 2005
Basic Network Media Services with SIP
基于SIP的基本网络媒体服务
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.
在基于SIP的网络中，需要提供基本的网络媒体服务。这些服务包括网络公告、用户交互和会议服务。这些服务是基本的构建块，人们可以从中构建有趣的应用程序。为了在提供这些构建块的服务器（也称为媒体服务器）和应用程序开发人员之间实现互操作性，需要能够以定义良好的方式定位和调用此类服务。
This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.
本文档描述了一种机制，用于在向基于SIP的网络提供应用程序服务的应用程序服务器和提供基本媒体处理构建块的媒体服务器之间提供可互操作的接口。
Table of Contents
目录
1. Overview ........................................................2
1.1. Conventions Used in This Document ..........................3
2. Mechanism .......................................................3
3. Announcement Service ............................................5
3.1. Operation ..................................................8
3.2. Protocol Diagram ...........................................9
3.3. Formal Syntax ..............................................9
4. Prompt and Collect Service .....................................11
4.1. Formal Syntax for Prompt and Collect Service ..............12
5. Conference Service .............................................13
5.1. Protocol Diagram ..........................................14
5.2. Formal Syntax .............................................16
6. IANA Considerations ............................................17
7. The User Part ..................................................17
8. Security Considerations ........................................20
9. Contributors ...................................................20
10. Acknowledgements ..............................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................22
1. Overview ........................................................2
1.1. Conventions Used in This Document ..........................3
2. Mechanism .......................................................3
3. Announcement Service ............................................5
3.1. Operation ..................................................8
3.2. Protocol Diagram ...........................................9
3.3. Formal Syntax ..............................................9
4. Prompt and Collect Service .....................................11
4.1. Formal Syntax for Prompt and Collect Service ..............12
5. Conference Service .............................................13
5.1. Protocol Diagram ..........................................14
5.2. Formal Syntax .............................................16
6. IANA Considerations ............................................17
7. The User Part ..................................................17
8. Security Considerations ........................................20
9. Contributors ...................................................20
10. Acknowledgements ..............................................20
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................22
In SIP-based media networks (RFC 3261 [10]), there is a need to provide basic network media services. Such services include playing announcements, initiating a media mixing session (conference), and prompting and collecting information with a user.
在基于SIP的媒体网络（RFC 3261[10]）中，需要提供基本的网络媒体服务。这些服务包括播放公告、启动媒体混合会话（会议）、提示用户并收集信息。
These services are basic in nature, are few in number, and fundamentally have not changed in 25 years of enhanced telephony services. Moreover, given their elemental nature, one would not expect them to change in the future.
这些服务本质上是基本的，数量很少，而且在增强的电话服务的25年中基本上没有改变。此外，鉴于它们的基本性质，人们不会期望它们在未来发生变化。
Multifunction media servers provide network media services to clients using server protocols such as SIP, often in conjunction with markup languages such as VoiceXML [20] and MSCML [21]. This document describes how to identify to a multifunction media server what sort of session the client is requesting, without modifying the SIP protocol.
多功能媒体服务器使用服务器协议（如SIP）向客户端提供网络媒体服务，通常与标记语言（如VoiceXML[20]和MSCML[21]）结合使用。本文档描述了如何在不修改SIP协议的情况下，向多功能媒体服务器识别客户端请求的会话类型。
It is critically important to note that the mechanism described here in no way modifies the SIP protocol, the meaning, or definition of a SIP Request URI, or does it put any restrictions, in any way, on devices that do not implement this convention.
重要的是要注意，此处描述的机制不会修改SIP协议、SIP请求URI的含义或定义，也不会以任何方式对未实现此约定的设备施加任何限制。
Announcements are media played to the user. Announcements can be static media files, media files generated in real-time, media streams generated in real-time, multimedia objects, or combinations of the above.
公告是向用户播放的媒体。公告可以是静态媒体文件、实时生成的媒体文件、实时生成的媒体流、多媒体对象或上述内容的组合。
Media mixing is the act of mixing different RTP streams, as described in RFC 3550 [13]. Note that the service described here suffices for simple mixing of media for a basic conferencing service. This service does not address enhanced conferencing services, such as floor control, gain control, muting, subconferences, etc. MSCML [21] addresses enhanced conferencing. However, that is beyond the scope of this document. Interested readers should read conferencing-framework [22] for details on the IETF SIP conferencing framework.
介质混合是混合不同RTP流的行为，如RFC 3550[13]所述。请注意，这里描述的服务足以简单地混合基本会议服务的介质。此服务不处理增强型会议服务，如楼层控制、增益控制、静音、子会议等。MSCML[21]处理增强型会议。但是，这超出了本文件的范围。感兴趣的读者应阅读会议框架[22]，了解IETF SIP会议框架的详细信息。
Prompt and collect is where the server prompts the user for some information, as in an announcement, and then collects the user's response. This can be a one-step interaction, for example by playing an announcement, "Please enter your pass code", followed by collecting a string of digits. It can also be a more complex interaction, specified, for example, by VoiceXML [20] or MSCML [21].
Prompt and collect是服务器向用户提示某些信息（如在公告中）的地方，然后收集用户的响应。这可以是一个单步交互，例如播放一条公告，“请输入您的密码”，然后收集一串数字。它也可以是更复杂的交互，例如由VoiceXML[20]或MSCML[21]指定。
RFC 2119 [6] the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
RFC 2119[6]本文件中对关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”的解释。
In the context of SIP control of media servers, we take advantage of the fact that the standard SIP URI has a user part. Multifunction media servers do not have users. Thus we use the user address, or the left-hand-side of the URI, as a service indicator.
在媒体服务器的SIP控制上下文中，我们利用了标准SIPURI具有用户部分这一事实。多功能媒体服务器没有用户。因此，我们使用用户地址或URI的左侧作为服务指示符。
The use of the user part of the SIP Request URI has a number of useful properties:
SIP请求URI的用户部分的使用具有许多有用的属性：
o There is no change to core SIP. o Only devices that choose to conform to this standard have to implement it. o This document only applies to multifunction SIP-controlled media servers. o This document has no impact on non-multifunction SIP-controlled media servers. o The mechanism described in this document has absolutely no impact on SIP devices other than media servers.
o 核心SIP没有变化。o只有选择符合本标准的设备才能实施本标准。o本文件仅适用于多功能SIP控制的媒体服务器。o本文件不影响非多功能SIP控制的媒体服务器。o本文档中描述的机制对媒体服务器以外的SIP设备绝对没有影响。
The last bullet point is crucial. In particular, the user part convention described here places absolutely no restrictions on any SIP user agent, proxy, back-to-back user agent (B2BUA), or any future device. The user parts defined here only apply to multifunction media servers that chose to implement the convention. With the exception of a conforming media server, these user names and conventions have no impact on the user part namespace. They do not restrict the use of these user names at devices other than a multifunction media server.
最后一点至关重要。特别地，这里描述的用户部分约定对任何SIP用户代理、代理、背靠背用户代理（B2BUA）或任何未来设备绝对没有限制。此处定义的用户部件仅适用于选择实施该约定的多功能媒体服务器。除一致性介质服务器外，这些用户名和约定对用户部件名称空间没有影响。它们不限制在多功能媒体服务器以外的设备上使用这些用户名。
Note that the set of services is small, well defined, and well contained. The section The User Part (Section 7) discusses the issues with using a fixed set of user-space names.
请注意，服务集很小、定义良好且包含良好。“用户部分”一节（第7节）讨论了使用一组固定的用户空间名称的问题。
For per-service security, the media server SHOULD use the security protocols described in RFC 3261 [10].
对于每服务安全性，媒体服务器应使用RFC 3261[10]中描述的安全协议。
The media server MAY issue 401 challenges for authentication. The media server SHOULD support the sips: scheme for the announcement service. The media server MUST support the sips: scheme for the dialog and conference services. The level of authentication to require for each service is a matter of local policy.
媒体服务器可能发出401个身份验证挑战。媒体服务器应支持公告服务的sips:scheme。媒体服务器必须支持对话和会议服务的sips:scheme。每个服务所需的身份验证级别取决于本地策略。
The media server, upon receiving an INVITE, notes the service indicator. Depending on the service indicator, the media server will either honor the request or return a failure response code.
媒体服务器在收到邀请后会记录服务指示器。根据服务指示器的不同，媒体服务器将接受请求或返回故障响应代码。
The service indicator is the concatenation of the service name and an optional service instance identifier, separated by an equal sign.
服务指示符是服务名称和可选服务实例标识符的串联，由等号分隔。
Per RFC 3261 [10], 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 %3D).
根据RFC 3261[10]，服务指示器不区分大小写。服务名称必须来自设置的字母数字字符加破折号（US-ASCII%2C）。服务名称不得包含等号（US-ASCII%3D）。
The service name MAY have long- and short-forms, as SIP does for headers.
服务名称可以有长格式和短格式，就像SIP对标头所做的那样。
A given service indicator MAY have an associated set of parameters. Such parameters MUST follow the convention set out for SIP URI parameters. That is, a semi-colon separated list of keyword=value pairs.
给定的服务指示器可能有一组相关的参数。此类参数必须遵循为SIP URI参数设置的约定。也就是说，关键字=值对的分号分隔列表。
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. An equal sign, US-ASCII %3D, MUST separate the service indicator from the unique identifier.
唯一标识符必须符合SIPURI的合法用户部分的规则。必须使用等号US-ASCII%3D将服务指示器与唯一标识符分开。
Note that since the service indicator is case insensitive, the service instance identifier is also case insensitive.
请注意，由于服务指示符不区分大小写，因此服务实例标识符也不区分大小写。
The requesting client issues a SIP INVITE to the media server, specifying the requested service and any appropriate parameters.
请求客户端向媒体服务器发出SIP INVITE，指定请求的服务和任何适当的参数。
If the media server can perform the requested service, it does so, following the processing steps described in the service definition document.
如果媒体服务器可以执行请求的服务，则会按照服务定义文档中描述的处理步骤执行。
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. RFC 3261 [10] describes the 488 and 606 response codes.
如果媒体服务器无法执行请求的服务或无法识别服务指示器，则必须使用响应代码488进行响应，此处不接受。这是适当的，因为488指的是URI的用户部分的问题。此外，606是不合适的，因为一些其他媒体服务器可能能够满足该请求。RFC 3261[10]描述了488和606响应代码。
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 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.
某些服务需要唯一标识符。大多数服务会在第一次邀请时自动创建具有给定标识符的服务实例。但是，如果服务需要现有的服务实例，并且媒体服务器上不存在此类服务实例，则媒体服务器必须使用未找到的响应代码404进行响应。这是适当的，因为服务本身存在于媒体服务器上，但特定的服务实例不存在。这就好像用户不在家一样。
A network announcement is the delivery of a multimedia resource, such as a prompt file, to a terminal device. Note the multimedia resource may be any multimedia object that the media server supports. This service can play a single object with multiple streams, such as a video and audio prompt. However, this service cannot play multiple objects on the same SIP dialog.
网络公告是将多媒体资源（如提示文件）传送到终端设备。注：多媒体资源可以是媒体服务器支持的任何多媒体对象。此服务可以播放具有多个流的单个对象，例如视频和音频提示。但是，此服务不能在同一个SIP对话框上播放多个对象。
There are two types of network announcements. The differentiating characteristic between the two types is whether the network fully sets up the SIP dialog before playing the announcement. The analog in the Public Switched Telephone Network (PSTN) is whether answer supervision is supplied (i.e., does the announcement server answer the call prior to delivering the announcement?).
有两种类型的网络公告。这两种类型之间的区别特征在于网络是否在播放公告之前完全设置了SIP对话。公共交换电话网（PSTN）中的模拟是是否提供应答监控（即，公告服务器是否在发布公告之前应答呼叫？）。
Playing an announcement after call setup is straightforward. First, the requesting device issues an INVITE to the media server requesting the announcement service. The media server negotiates the SDP and responds with a 200 OK. After receiving the ACK from the requesting device, the media server plays the requested object and issues a BYE to the requesting device.
在呼叫设置后播放公告非常简单。首先，请求设备向请求公告服务的媒体服务器发出邀请。媒体服务器协商SDP并以200 OK作为响应。从请求设备接收到ACK后，媒体服务器播放请求的对象并向请求设备发出BYE。
If the media server supports announcements, but it cannot find the referenced URI, it MUST respond with the 404 response code and SHOULD send the reason phrase "Announcement content not found".
如果媒体服务器支持公告，但找不到引用的URI，则必须使用404响应代码进行响应，并应发送原因短语“未找到公告内容”。
If the media server receives an INVITE for the announcement service without a "play=" parameter, it MUST respond with the response code 400 and SHOULD send the reason phrase "Mandatory play parameter missing".
如果媒体服务器收到通知服务的邀请，但没有“play=”参数，则必须使用响应代码400进行响应，并应发送原因短语“Mandatory play parameter missing”。
If there is an error retrieving the announcement, the media server MUST respond with a 400 response code and SHOULD send the reason phrase "Announcement content could not be retrieved". In addition the media server SHOULD include a Warning header with appropriate explanatory text explaining what failed.
如果检索公告时出错，媒体服务器必须使用400响应代码进行响应，并应发送原因短语“无法检索公告内容”。此外，媒体服务器应包括一个警告标题，并带有适当的解释文本，解释失败的原因。
The Request URI fully describes the announcement service through the use of the user part of the address and additional URI parameters. The user portion of the address, "annc", specifies the announcement service on the media server. The service has several associated URI parameters that control the content and delivery of the announcement.
请求URI通过使用地址的用户部分和附加的URI参数来完全描述公告服务。地址的用户部分“annc”指定媒体服务器上的公告服务。该服务具有多个关联的URI参数，这些参数控制公告的内容和传递。
These parameters are described below:
这些参数描述如下：
play Specifies the resource or announcement sequence to be played.
播放指定要播放的资源或公告序列。
repeat Specifies how many times the media server should repeat the announcement or sequence named by the "play=" parameter. The value "forever" means the repeat should be effectively unbounded. In this case, it is RECOMMENDED the media server implements some local policy, such as limiting what "forever" means, to ensure errant clients do not create a denial of service attack.
repeat指定媒体服务器应重复“play=”参数指定的公告或序列的次数。值“forever”意味着重复应该有效地无限制。在这种情况下，建议媒体服务器实施一些本地策略，例如限制“永远”的含义，以确保出错的客户端不会创建拒绝服务攻击。
delay Specifies a delay interval between announcement repetitions. The delay is measured in milliseconds.
延迟指定重复公告之间的延迟间隔。延迟以毫秒为单位。
duration Specifies the maximum duration of the announcement. The media server will discontinue the announcement and end the call if the
duration指定公告的最长持续时间。如果出现以下情况，媒体服务器将停止广播并结束通话：
maximum duration has been reached. The duration is measured in milliseconds.
已达到最大持续时间。持续时间以毫秒为单位。
locale Specifies the language and optionally country variant of the announcement sequence named in the "play=" parameter. RFC 3066 [9] specifies the locale tag. The locale tag is usually a two- or three-letter code per ISO 639-1 [11]. The country variant is also often a two-letter code per ISO 3166-1 [12]. These elements are concatenated with a single under bar (%x5F) character, such as "en_CA". If only the language is specified, such as locale=en, the choice of country variant is an implementation matter. Implementations SHOULD provide the best possible match between the requested locale and the available languages in the event the media server cannot honor the locale request precisely. For example, if the request has locale=ca_FR, but the media server only has fr_FR available, the media server should use the fr_FR variant. Implementations SHOULD provide a default locale to use if no language variants are available.
locale指定“play=”参数中命名的公告序列的语言和可选国家变量。RFC 3066[9]指定区域设置标记。根据ISO 639-1[11]，区域设置标记通常是两个或三个字母的代码。根据ISO 3166-1[12]，国家变体通常也是两个字母的代码。这些元素由单个条下（%x5F）字符连接，例如“en_CA”。如果只指定语言，例如locale=en，则选择国家/地区变量是一个实现问题。在媒体服务器无法准确响应区域设置请求的情况下，实现应在请求的区域设置和可用语言之间提供最佳匹配。例如，如果请求的locale=ca\u FR，但媒体服务器只有FR\u FR可用，则媒体服务器应使用FR\u FR变量。如果没有可用的语言变体，实现应该提供一个默认的语言环境。
param[n] Provides a mechanism for passing values that are to be substituted into an announcement sequence. Up to 9 parameters ("param1=" through "param9=") may be specified. The mechanics of announcement sequences are beyond the scope of this document.
param[n]提供了一种机制，用于将要替换的值传递到公告序列中。最多可以指定9个参数（“param1=”到“param9=”）。公告序列的机制超出了本文档的范围。
extension Provides a mechanism for extending the parameter set. If the media server receives an extension it does not understand, it MUST silently ignore the extension parameter and value.
扩展提供了扩展参数集的机制。如果媒体服务器接收到它不理解的扩展，它必须默默地忽略扩展参数和值。
The "play=" parameter is mandatory and MUST be present. All other parameters are OPTIONAL.
“play=”参数是必需的，必须存在。所有其他参数都是可选的。
NOTE: Some encodings are not self-describing. Thus, the implementation relies on filename extension conventions for determining the media type.
注意：某些编码不是自描述的。因此，实现依赖于文件名扩展约定来确定媒体类型。
Note that RFC 3261 [10] implies that proxies are supposed to pass parameters through unchanged. However, be aware that non-conforming proxies may strip Request-URI parameters. That said, given the likely scenarios for the mechanisms presented in this document, this should not be an issue. Most likely, the proxy inserting the parameters is the last proxy before the media server. If the service provider deploys a proxy for load balancing or service location purposes, the service provider should ensure that its choice of proxy preserves parameters.
请注意，RFC 3261[10]意味着代理应该在未更改的情况下传递参数。但是，请注意，不一致的代理可能会删除请求URI参数。也就是说，鉴于本文件中提出的机制可能出现的情况，这不应成为一个问题。插入参数的代理很可能是媒体服务器之前的最后一个代理。如果服务提供商出于负载平衡或服务位置的目的部署代理，则服务提供商应确保其代理选择保留参数。
The form of the SIP Request URI for announcements is as follows. Note that the backslash, CRLF, and spacing before the "play=" in the example is for readability purposes only.
公告的SIP请求URI的形式如下所示。请注意，示例中“play=”之前的反斜杠、CRLF和间距仅用于可读性目的。
sip:annc@ms2.example.net; \
play=http://audio.example.net/allcircuitsbusy.g711
sip:annc@ms2.example.net; \
play=http://audio.example.net/allcircuitsbusy.g711
sip:annc@ms2.example.net; \
play=file://fileserver.example.net//geminii/yourHoroscope.wav
sip:annc@ms2.example.net; \
play=file://fileserver.example.net//geminii/yourHoroscope.wav
The scenarios below assume there is a SIP Proxy, application server, or media gateway controller between the caller and the media server. However, the announcement service works as described below even if the caller invokes the service directly. We chose to discuss the proxy case, as it will be the most common case.
下面的场景假设调用方和媒体服务器之间存在SIP代理、应用程序服务器或媒体网关控制器。但是，即使调用者直接调用该服务，公告服务的工作方式如下所述。我们选择讨论代理案件，因为这将是最常见的案件。
The caller issues an INVITE to the serving SIP Proxy. The SIP Proxy determines what audio prompt to play to the caller. The proxy responds to the caller with 100 TRYING.
调用者向服务SIP代理发出邀请。SIP代理确定要向调用者播放的音频提示。代理以100次重试响应调用方。
It is important to note that the mechanism described here in no way modifies the behavior of SIP [10]. In particular, this convention does not modify SDP negotiation [18].
需要注意的是，这里描述的机制绝不会修改SIP的行为[10]。特别是，本公约不修改SDP协商[18]。
The proxy issues an INVITE to the media server, requesting the appropriate prompt to play coded in the play= parameter. The media server responds with 200 OK. The proxy relays the 200 OK to the caller. The caller then issues an ACK. The proxy then relays the ACK to the media server.
代理向媒体服务器发出邀请，请求播放参数play=中编码的相应提示。媒体服务器以200 OK响应。代理将200 OK转发给调用者。然后调用者发出确认。然后，代理将ACK中继到媒体服务器。
With the call established, the media server plays the requested prompt. When the media server completes the play of the prompt, it issues a BYE to the proxy. The proxy then issues a BYE to the caller.
呼叫建立后，媒体服务器将播放请求的提示。媒体服务器播放完提示后，会向代理发出“再见”。然后代理向调用者发出再见。
Caller Proxy Media Server
| INVITE | |
|----------------------->| INVITE |
| 100 TRYING |----------------------->|
|<-----------------------| 200 OK |
| 200 OK |<-----------------------|
|<-----------------------| |
| ACK | |
|----------------------->| ACK |
| |----------------------->|
| | |
| Play Announcement (RTP) |
|<================================================|
| | |
| | BYE |
| BYE |<-----------------------|
|<-----------------------| |
| 200 OK | |
|----------------------->| 200 OK |
| |----------------------->|
| | |
Caller Proxy Media Server
| INVITE | |
|----------------------->| INVITE |
| 100 TRYING |----------------------->|
|<-----------------------| 200 OK |
| 200 OK |<-----------------------|
|<-----------------------| |
| ACK | |
|----------------------->| ACK |
| |----------------------->|
| | |
| Play Announcement (RTP) |
|<================================================|
| | |
| | BYE |
| BYE |<-----------------------|
|<-----------------------| |
| 200 OK | |
|----------------------->| 200 OK |
| |----------------------->|
| | |
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
以下语法规范使用RFC 4234[7]中所述的增广巴科斯诺尔形式（BNF）。
ANNC-URL = sip-ind annc-ind "@" hostport annc-parameters uri-parameters
ANNC-URL=sip ind ANNC ind“@”主机端口ANNC参数uri参数
sip-ind = "sip:" / "sips:"
annc-ind = "annc"
sip-ind = "sip:" / "sips:"
annc-ind = "annc"
annc-parameters = ";" play-param [ ";" content-param ]
[ ";" delay-param]
[ ";" duration-param ]
[ ";" repeat-param ]
[ ";" locale-param ]
[ ";" variable-params ]
[ ";" extension-params ]
annc-parameters = ";" play-param [ ";" content-param ]
[ ";" delay-param]
[ ";" duration-param ]
[ ";" repeat-param ]
[ ";" locale-param ]
[ ";" variable-params ]
[ ";" extension-params ]
play-param = "play=" prompt-url
play param=“play=”提示url
content-param = "content-type=" MIME-type
content param=“content type=”MIME类型
delay-param = "delay=" delay-value
delay param=“delay=”延迟值
delay-value = 1*DIGIT
delay-value = 1*DIGIT
duration-param = "duration=" duration-value
duration param=“duration=”持续时间值
duration-value = 1*DIGIT
duration-value = 1*DIGIT
repeat-param = "repeat=" repeat-value
repeat param=“repeat=”重复值
repeat-value = 1*DIGIT / "forever"
repeat-value = 1*DIGIT / "forever"
locale-param = "locale=" token
; per RFC 3066, usually
; ISO639-1_ISO3166-1
; e.g., en, en_US, en_UK, etc.
locale-param = "locale=" token
; per RFC 3066, usually
; ISO639-1_ISO3166-1
; e.g., en, en_US, en_UK, etc.
variable-params = param-name "=" variable-value
变量参数=参数名称“=”变量值
param-name = "param" DIGIT ; e.g., "param1"
param name=“param”数字；e、 g.“参数1”
variable-value = 1*(ALPHA / DIGIT)
variable-value = 1*(ALPHA / DIGIT)
extension-params = extension-param [ ";" extension-params ]
扩展参数=扩展参数[“；”扩展参数]
extension-param = token "=" token
扩展参数=令牌“=”令牌
"uri-parameters" is the SIP Request-URI parameter list as described in RFC 3261 [10]. All parameters of the Request URI are part of the URI matching algorithm.
“uri参数”是RFC 3261[10]中描述的SIP请求uri参数列表。请求URI的所有参数都是URI匹配算法的一部分。
The MIME-type is the MIME [1] [2] [3] [4] [5] content type for the announcement, such as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on.
MIME类型是公告的MIME[1][2][3][4][5]内容类型，如音频/基本、音频/G729、音频/mpeg、视频/mpeg等。
A number of MIME registrations, which could be used here, have parameters, for instance, video/DV. To accommodate this, and retain compatibility with the SIP URI structure, the MIME-type parameter separator (semicolon, %3b) and value separator (equal, %d3) MUST be escaped. For example:
这里可以使用的许多MIME注册都有参数，例如video/DV。为了适应这种情况并保持与SIPURI结构的兼容性，必须转义MIME类型参数分隔符（分号，%3b）和值分隔符（相等，%d3）。例如：
sip:annc@ms.example.net; \
play=file://fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg%3bencode%d3314M-25/625-50
sip:annc@ms.example.net; \
play=file://fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg%3bencode%d3314M-25/625-50
The locale-value consists of a tag as specified in RFC 3066 [9].
区域设置值由RFC 3066[9]中指定的标记组成。
The definition of hostport is as specified by RFC 3261 [10].
主机端口的定义由RFC 3261[10]规定。
The syntax of prompt-url consists of a URL scheme as specified by RFC 3986 [8] or a special token indicating a provisioned announcement sequence. For example, the URL scheme MAY include any of the following.
提示url的语法由RFC 3986[8]指定的url方案或指示已设置公告序列的特殊令牌组成。例如，URL方案可以包括以下任一项。
o http/https o ftp o file (referencing a local or NFS (RFC 3530 [16]) object) o nfs (RFC 2224 [14])
o http/https o ftp o文件（引用本地或NFS（RFC 3530[16]）对象）o NFS（RFC 2224[14]）
If a provisioned announcement sequence is to be played, the value of prompt-url will have the following form:
如果要播放已设置的公告序列，则提示url的值将具有以下形式：
prompt-url = "/provisioned/" announcement-id
prompt-url = "/provisioned/" announcement-id
announcement-id = 1*(ALPHA / DIGIT)
announcement-id = 1*(ALPHA / DIGIT)
Note that the scheme "/provisioned/" was chosen because of a hesitation to register a "provisioned:" URI scheme.
请注意，之所以选择方案“/provisioned/”，是因为注册“provisioned:”URI方案时犹豫。
This document is strictly focused on the SIP interface for the announcement service and, as such, does not detail how announcement sequences are provisioned or defined.
本文档严格关注公告服务的SIP接口，因此，没有详细说明如何提供或定义公告序列。
Note that the media type of the object the prompt-url refers to can be most anything, including audio file formats, text file formats, or URI lists. See the Prompt and Collect Service (Section 4) section for more on this topic.
请注意，提示url所指对象的媒体类型可以是任何内容，包括音频文件格式、文本文件格式或URI列表。有关此主题的更多信息，请参阅“提示和付费服务”（第4节）部分。
This service is also known as a voice dialog. It establishes an aural dialog with the user.
此服务也称为语音对话。它与用户建立听觉对话。
The dialog service follows the model of the announcement service. However, the service indicator is "dialog". The dialog service takes a parameter, voicexml=, indicating the URI of the VoiceXML script to execute.
对话服务遵循公告服务的模式。但是，服务指示器为“对话框”。对话服务接受一个参数voicexml=，表示要执行的voicexml脚本的URI。
sip:dialog@mediaserver.example.net; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
sip:dialog@mediaserver.example.net; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
A Media Server MAY accept additional SIP request URI parameters and deliver them to the VoiceXML interpreter session as session variables.
媒体服务器可以接受附加的SIP请求URI参数，并将其作为会话变量传递给VoiceXML解释器会话。
Although not good VoiceXML programming practice, VoiceXML scripts might contain sensitive information, such as a user's pass code in a
虽然不是很好的VoiceXML编程实践，但VoiceXML脚本可能包含敏感信息，例如用户在应用程序中的密码
DTMF grammar. Thus, the media server MUST support the https scheme for the voicexml parameter for secure fetching of scripts. Likewise, dynamic grammars often do have user-identifying information. As such, the VoiceXML browser implementation on the media server MUST support https fetching of grammars and subsequent documents.
双音多频语法。因此，媒体服务器必须支持voicexml参数的https方案，以便安全获取脚本。类似地，动态语法通常具有用户标识信息。因此，媒体服务器上的VoiceXML浏览器实现必须支持语法和后续文档的https获取。
Returned information often is sensitive. For example, the information could be financial information or instructions. Thus, the media server MUST support https posting of results.
返回的信息通常是敏感的。例如，信息可以是财务信息或说明。因此，媒体服务器必须支持https发布结果。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
以下语法规范使用RFC 4234[7]中所述的增广巴科斯诺尔形式（BNF）。
DIALOG-URL = sip-ind dialog-ind "@" hostport dialog-parameters
DIALOG-URL=sip ind DIALOG ind“@”主机端口对话框参数
sip-ind = "sip:" / "sips:"
dialog-ind = "dialog"
sip-ind = "sip:" / "sips:"
dialog-ind = "dialog"
dialog-parameters = ";" dialog-param [ vxml-parameters ] [ uri-parameters ]
dialog parameters=“；”对话框参数[vxml参数][uri参数]
dialog-param = "voicexml=" vxml-url
dialog param=“voicexml=”vxml url
vxml-parameters = vxml-param [ vxml-parameters ]
vxml参数=vxml参数[vxml参数]
vxml-param = ";" vxml-keyword "=" vxml-value
vxml-param = ";" vxml-keyword "=" vxml-value
vxml-keyword = token
vxml-keyword = token
vxml-value = token
vxml-value = token
The vxml-url is the URI of the VoiceXML script. If present, other parameters get passed to the VoiceXML interpreter session with the assigned vxml-keyword vxml-value pairs. Note that all vxml-keywords MUST have values.
vxml url是VoiceXML脚本的URI。如果存在，其他参数将通过指定的vxml关键字vxml值对传递到VoiceXML解释器会话。请注意，所有vxml关键字都必须有值。
If there is a vxml-keyword without a corresponding vxml-value, the media server MUST reject the request with a 400 BAD REQUEST response code. In addition, the media server MUST state "Missing VXML Value" in the reason phrase.
如果存在没有相应vxml值的vxml关键字，则媒体服务器必须使用400错误请求响应代码拒绝该请求。此外，媒体服务器必须在原因短语中声明“缺少VXML值”。
The media server presents the parameters as environment variables in the connection object. Specifically, the parameter appears in the connection.sip tree.
媒体服务器在连接对象中将参数作为环境变量显示。具体而言，参数显示在connection.sip树中。
If the Media Server does not support the passing of keyword-value pairs to the VoiceXML interpreter session, it MUST ignore the parameters.
如果媒体服务器不支持向VoiceXML解释器会话传递关键字-值对，则必须忽略这些参数。
"uri-parameters" is the SIP Request-URI parameter list as described in RFC 3261 [10]. All parameters in the parameter list, whether they come from uri-parameters or from vxml-keyworks, are part of the URI matching algorithm.
“uri参数”是RFC 3261[10]中描述的SIP请求uri参数列表。参数列表中的所有参数，无论是来自uri参数还是来自vxml keyworks，都是uri匹配算法的一部分。
One identifies mixing sessions through their SIP request URIs. To create a mixing session, one sends an INVITE to a request URI that represents the session. If the URI does not already exist on the media server and the requested resources are available, the media server creates a new mixing session. If there is an existing URI for the session, then the media server interprets it as a request for the new session to join the existing session. The form of the SIP request URI for conferencing is:
一种是通过SIP请求URI识别混合会话。要创建混合会话，需要向表示会话的请求URI发送邀请。如果URI在媒体服务器上不存在，并且请求的资源可用，则媒体服务器将创建一个新的混合会话。如果会话存在现有URI，则媒体服务器将其解释为新会话加入现有会话的请求。用于会议的SIP请求URI的形式为：
sip:conf=uniqueIdentifier@mediaserver.example.net
sip:conf=uniqueIdentifier@mediaserver.example.net
The left-hand side of the request URI is actually the username of the request in the request URI and the To header. The host portion of the URI identifies a particular media server. The "conf" user name conveys to the media server that this is a request for the mixing service. The uniqueIdentifier can be any value that is compliant with the SIP URI specification. It is the responsibility of the conference control application to ensure the identifier is unique within the scope of any potential conflict.
请求URI的左侧实际上是请求URI和To头中请求的用户名。URI的主机部分标识特定的媒体服务器。“conf”用户名向媒体服务器传达这是对混合服务的请求。uniqueIdentifier可以是符合SIPURI规范的任何值。会议控制应用程序负责确保标识符在任何潜在冲突范围内唯一。
In the terminology of the conferencing framework [22], this URI convention tells the media server that the application server is requesting it to act as a Focus. The conf-id value identifies the particular focus instance.
在会议框架[22]的术语中，这个URI约定告诉媒体服务器应用服务器请求它充当焦点。conf id值标识特定的焦点实例。
As a focus in the conferencing framework, the media server MUST support the ";isfocus" parameter in the Request URI. Note, however, that the presence or absence of the ";isfocus" parameter has no protocol impact at the media server.
作为会议框架中的焦点，媒体服务器必须支持请求URI中的“isfocus”参数。但是，请注意，“isfocus”参数的存在或不存在对媒体服务器的协议没有影响。
It is worth noting that the conference URI shared between the application and media servers provides enhanced security, as the SIP control interface does not have to be exposed to participants. It also allows the assignment of a specific media server to be delayed as long as possible, thereby simplifying resource management.
值得注意的是，应用程序和媒体服务器之间共享的会议URI提供了增强的安全性，因为SIP控制接口不必向参与者公开。它还允许尽可能长时间延迟指定特定媒体服务器，从而简化资源管理。
One can add additional legs to the conference by INVITEing them to the above-mentioned request URI. Per the matching rules of RFC 3261 [10], the conf-id parameter is part of the matching string.
通过邀请他们加入上述请求URI，可以为会议添加额外的分支。根据RFC 3261[10]的匹配规则，conf id参数是匹配字符串的一部分。
Conversely, one can remove legs by issuing a BYE in the corresponding dialog. The mixing session, and thus the conference-specific request URI, remains active so long as there is at least one SIP dialog associated with the given request URI.
相反，可以通过在相应的对话框中发出BYE来移除支腿。只要存在与给定请求URI相关联的至少一个SIP对话，混合会话以及会议特定请求URI就保持活动。
If the Request-URI has "conf" as the user part, but does not have a conf-id parameter, the media server MUST respond with a 404 NOT FOUND.
如果请求URI的用户部分为“conf”，但没有conf id参数，则媒体服务器必须以404 not FOUND响应。
NOTE: The media server could create a unique conference instance and return the conf-id string to the User Agent Clinet (UAC) if there is no conf-id present. However, such an operation may have other operational issues, such as permissions and billing. Thus an application server or proxy is a better place to do such an operation. Moreover, such action would make the media server into a Conference Factory in the terminology of conference-framework [22]. That is not the appropriate behavior for a media server.
注意：如果没有conf id，媒体服务器可以创建一个唯一的会议实例，并将conf id字符串返回给用户代理Clinet（UAC）。但是，此类操作可能存在其他操作问题，例如权限和计费。因此，应用服务器或代理是执行此类操作的更好地方。此外，这样的操作将使媒体服务器成为会议框架术语中的会议工厂[22]。这不是媒体服务器的适当行为。
Since some conference use cases, such as business conferencing, have billing implications, the media server SHOULD authenticate the application server or proxy. At a minimum, the media server MUST implement sips:.
由于某些会议用例（如业务会议）具有计费含义，因此媒体服务器应验证应用程序服务器或代理。媒体服务器至少必须实现sips:。
This diagram shows the establishment of a three-way conference. This section is informative. It is only one method of establishing a conference. This example shows a simple back-to-back user agent.
此图显示了三方会议的建立。本节内容丰富。这只是召开会议的一种方法。此示例显示了一个简单的背靠背用户代理。
The conference-framework [22] describes additional parameters and behaviors of the Application Server. For example, the first INVITE from P1 to the Application Server would include the ";isfocus" parameter; the Application Server would act as a Conference Factory; and so on. However, none of that protocol machinery has an impact on the operation of the Application Server to Media Server interface, which is the focus of this protocol document.
会议框架[22]描述了应用服务器的其他参数和行为。例如，从P1到应用服务器的第一个邀请将包括“isfocus”参数；应用服务器将充当会议工厂；等等但是，这些协议机制都不会影响应用程序服务器到媒体服务器接口的操作，这是本协议文档的重点。
P1 P2 P3 Application Server Media Server
| | | | |
| INVITE sip:public-conf@as.example.net |
|---------------------------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| 200 OK | |<------------------|
|<----------------------------------| |
| ACK | | | |
|---------------------------------->| ACK |
| | | |------------------>|
| | | RTP w/ P1 | |
|<=====================================================>|
| | | | |
| INVITE sip:public-conf@as.example.net |
| |-------------------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| | 200 OK | |<------------------|
| |<--------------------------| |
| | ACK | | |
| |-------------------------->| ACK |
| | | |------------------>|
| | | | |
| | | RTP w/ P1+P2-P2 | |
| |<=============================================>|
| | | RTP w/ P1+P2-P1 | |
|<=====================================================>|
| | | | |
| INVITE sip:public-conf@as.example.net |
| | |----------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| | | 200 OK |<------------------|
| | |<-----------------| |
| | | ACK | |
| | |----------------->| ACK |
| | | |------------------>|
| | | | |
| | | RTP w/ P1+P2+P3-P3 |
| | |<====================================>|
| | | RTP w/ P1+P2+P3-P2 |
| |<=============================================>|
| | | RTP w/ P1+P2+P3-P1 |
|<=====================================================>|
P1 P2 P3 Application Server Media Server
| | | | |
| INVITE sip:public-conf@as.example.net |
|---------------------------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| 200 OK | |<------------------|
|<----------------------------------| |
| ACK | | | |
|---------------------------------->| ACK |
| | | |------------------>|
| | | RTP w/ P1 | |
|<=====================================================>|
| | | | |
| INVITE sip:public-conf@as.example.net |
| |-------------------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| | 200 OK | |<------------------|
| |<--------------------------| |
| | ACK | | |
| |-------------------------->| ACK |
| | | |------------------>|
| | | | |
| | | RTP w/ P1+P2-P2 | |
| |<=============================================>|
| | | RTP w/ P1+P2-P1 | |
|<=====================================================>|
| | | | |
| INVITE sip:public-conf@as.example.net |
| | |----------------->| |
| | | INVITE sip:conf=123@ms.example.net |
| | | |------------------>|
| | | | 200 OK |
| | | 200 OK |<------------------|
| | |<-----------------| |
| | | ACK | |
| | |----------------->| ACK |
| | | |------------------>|
| | | | |
| | | RTP w/ P1+P2+P3-P3 |
| | |<====================================>|
| | | RTP w/ P1+P2+P3-P2 |
| |<=============================================>|
| | | RTP w/ P1+P2+P3-P1 |
|<=====================================================>|
| | | | |
| | | | |
| | | | |
| | | | |
Using the terminology of conference-framework [22], the Application Server is the Conference Factory, and the Media Server is the Conference Focus.
使用会议框架[22]的术语，应用服务器是会议工厂，媒体服务器是会议焦点。
Note that the above call flow does not show any 100 TRYING messages that would typically flow from the Application Server to the UACs; nor does it show the ACKs from the UACs to the Application Server or from the Application Server to the Media Server.
注意，上面的调用流没有显示通常从应用服务器流向UACs的任何100条尝试消息；它也不显示从UACs到应用服务器或从应用服务器到媒体服务器的ACK。
Each leg can drop out either under the supervision of the UAC, by the UAC sending a BYE, or under the supervision of the Application Server, by the Application Server issuing a BYE. In either case, the Application Server will either issue a BYE on behalf of the UAC or issue it directly to the Media Server, corresponding to the respective disconnect case.
每个分支都可以在UAC的监督下退出（UAC发送BYE），或者在应用服务器的监督下退出（应用服务器发出BYE）。在任何一种情况下，应用服务器都将代表UAC发出BYE或直接向媒体服务器发出BYE，这与相应的断开连接情况相对应。
It is left as a trivial exercise to the reader for how the Application Server can mute legs, create side conferences, and so forth.
对于应用服务器如何使腿部静音、创建侧边会议等等，读者可以将其作为一个简单的练习。
Note that the Application Server is a server to the participants (UACs). However, the Application Server is a client for mixing services to the Media Server.
请注意，应用程序服务器是参与者的服务器（UAC）。但是，应用服务器是将服务混合到媒体服务器的客户端。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [7].
以下语法规范使用RFC 4234[7]中所述的增广巴科斯诺尔形式（BNF）。
CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport [ uri-parameters ]
CONF-URL=sip ind CONF ind“=”实例id“@”主机端口[uri参数]
sip-ind = "sip:" / "sips:"
sip-ind = "sip:" / "sips:"
conf-ind = "conf"
conf-ind = "conf"
instance-id = token
instance-id = token
"uri-parameters" is the SIP Request-URI parameter list as described in RFC 3261 [10]. All parameters in the parameter list are part of the URI matching algorithm.
“uri参数”是RFC 3261[10]中描述的SIP请求uri参数列表。参数列表中的所有参数都是URI匹配算法的一部分。
The IANA has registered the following parameters in the SIP/SIPS URI Parameters registry, following the specification required policy of RFC 3969 [19]:
IANA已按照RFC 3969[19]的规范要求策略，在SIP/SIPS URI参数注册表中注册了以下参数：
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
play no RFC 4240
repeat no RFC 4240
delay no RFC 4240
duration no RFC 4240
locale no RFC 4240
param[n] no RFC 4240
extension no RFC 4240
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
play no RFC 4240
repeat no RFC 4240
delay no RFC 4240
duration no RFC 4240
locale no RFC 4240
param[n] no RFC 4240
extension no RFC 4240
There has been considerable discussion about the wisdom of using fixed user parts in a request URI. The most common objection is that the user part should be opaque and a local matter. The other objection is that using a fixed user part removes those specified user addresses from the user address space.
关于在请求URI中使用固定用户部件是否明智，已经有相当多的讨论。最常见的反对意见是用户部分应该是不透明的，并且是局部的。另一个反对意见是，使用固定用户部分会从用户地址空间中删除那些指定的用户地址。
We address the latter issue first. The common example is the Postmaster address defined by RFC 2821 [15]. The objection is that by using the Postmaster token for something special, one removes that token for anyone. Thus, the Postmaster General of the United States, for example, cannot have the mail address Postmaster@usps.gov. However, one may debate whether this is a significant limitation.
我们首先处理后一个问题。常见的例子是RFC 2821[15]定义的邮政局长地址。反对意见是，通过使用邮政局长代币来做一些特殊的事情，你可以为任何人移除该代币。因此，例如，美国邮政总局局长就不能拥有邮件地址Postmaster@usps.gov. 然而，人们可能会争论这是否是一个重大限制。
This document explicitly addresses this issue. The user names described in the text (namely annc, ivr, dialog, and conf) are available for whatever local use a given SIP user agent or proxy wishes for them. What this document does is give special meaning for these user names at media servers that implement this specification. If a media server chooses not to implement this specification, nothing breaks. If a user wishes to use one of the user names described in this document at their SIP user agent, nothing breaks and their user agent will work as expected.
本文件明确阐述了这一问题。文本中描述的用户名（即annc、ivr、dialog和conf）可用于给定SIP用户代理或代理希望使用的任何本地用途。本文档的作用是为实现本规范的媒体服务器上的这些用户名赋予特殊含义。如果媒体服务器选择不实施此规范，则不会有任何中断。如果用户希望在其SIP用户代理中使用本文档中描述的用户名之一，则不会出现任何中断，并且其用户代理将按预期工作。
The key point is, one cannot confuse the namespace at a Media Server with the namespace for an organization. For example, let us take the case where a network offers services for "Ann Charles". She likes to use the name "annc", and thus she would like to use "sip:annc@example.net". We offer there is ABSOLUTELY NO NAME COLLISION WHATSOEVER. Why is this so? This is so because sip:annc@example.net will resolve to the specific user at a specific
关键是，不能将媒体服务器上的名称空间与组织的名称空间混淆。例如，让我们以网络为“Ann Charles”提供服务为例。她喜欢使用名称“annc”，因此她想使用“sip:annc@example.net". 我们提供的服务绝对没有任何名称冲突。为什么会这样？这是因为sip：annc@example.net将在特定时间解析到特定用户
device for Ann. As an example, example.net's SIP Proxy Server resolves sip:annc@example.net to annc@anns-phone.example.net. Conversely, one directs requests for the media service annc directly to the Media Server, e.g., sip:annc@ms21.ap.example.net. Moreover, by definition, requests for Ann Charles, or anything other than the announcement service, will NEVER be directly sent to the Media Server. If that were not true, no phone in the world could use the user part "eburger", as eburger is a reserved user part in the Brooktrout domain. Clearly, this is not the case.
安的设备。例如，example.net的SIP代理服务器解析SIP：annc@example.net到annc@anns-phone.example.net。相反，将对媒体服务annc的请求直接定向到媒体服务器，例如sip：annc@ms21.ap.example.net. 此外，根据定义，对Ann Charles或公告服务以外的任何内容的请求都不会直接发送到媒体服务器。如果这不是真的，世界上没有手机可以使用用户部分“eburger”，因为eburger是Brooktrout域中的保留用户部分。显然，情况并非如此。
If one wishes to make their media server accessible to the global Internet, but retain one of the Media Server-specific user names in the domain, a SIP Proxy can easily translate whatever opaque name one chooses to the Media Server-specific user name. For example, if a domain wishes to offer services for the above mentioned Ann Charles at sip:annc@example.com, they can offer the announcement service at sip:my-special-announcement-service@example.com. The former address, sip:annc@example.com, would resolve to the actual device where annc resides. The latter would resolve to the media server announcement server address, sip:annc@mediaserver.example.com, as an example. Note that this convention makes it easier to provision this service. With a fixed mapping at the multifunction media server, there are less provisioning data elements to get wrong.
如果希望使其媒体服务器可访问全球互联网，但在域中保留一个媒体服务器特定的用户名，SIP代理可以轻松地将选择的任何不透明名称转换为媒体服务器特定的用户名。例如，如果域希望在sip为上述用户提供服务：annc@example.com，他们可以在sip:my special announcement提供公告服务-service@example.com. 前地址sip：annc@example.com，将解析为annc所在的实际设备。后者将解析为媒体服务器公告服务器地址sip:annc@mediaserver.example.com，作为例子。请注意，此约定使提供此服务更容易。使用多功能媒体服务器上的固定映射，可减少出错的供应数据元素。
Here is another way of looking at this issue. Unix reserves the special user "root". Just about all Unix machines have a user root, who has an address "root@a-specific-machine.example.com", where "a-specific-machine" is the fully-qualified domain name (FQDN) of a particular instance of a machine. There are very well-defined semantics for the "root" user.
这是看待这个问题的另一种方式。Unix保留特殊用户“root”。几乎所有Unix机器都有一个用户root，用户root有一个地址“root@a-specific machine.example.com”，其中“a-specific-machine”是计算机特定实例的完全限定域名（FQDN）。“root”用户有非常明确的语义。
Even though most every Unix machine has a "root" user, often there is no mapping for a "root" user in a domain, such as "root@example.com". Conversely, there is no restriction on creating an MX record for "root@example.com". That choice is fully up to the administrative authority for the domain.
尽管大多数Unix机器都有一个“root”用户，但域中通常没有“root”用户的映射，例如root@example.com". 相反，对于为“”创建MX记录没有任何限制root@example.com". 这一选择完全取决于域的管理当局。
The "users" proposed by this document, "annc", "conf", and "dialog" are all users at a Media Server, just as the "root", "bin", and "nobody" users are "users" at a Unix host.
本文档提出的“用户”、“annc”、“conf”和“dialog”都是媒体服务器上的用户，正如“root”、“bin”和“nobody”用户是Unix主机上的“用户”。
After much discussion, with input from the W3C URI work group, we
considered obfuscating the user name by prepending "__sip-" to the
user name. However, as explained above, this obfuscation is not
necessary. There is a fundamental difference between a user name at
a device and a user name at an MX record (SMTP) or Address-of-Record
(SIP). Again, there is no possibility that the name on the device
may "leak out" into the SIP routing network.
After much discussion, with input from the W3C URI work group, we
considered obfuscating the user name by prepending "__sip-" to the
user name. However, as explained above, this obfuscation is not
necessary. There is a fundamental difference between a user name at
a device and a user name at an MX record (SMTP) or Address-of-Record
(SIP). Again, there is no possibility that the name on the device
may "leak out" into the SIP routing network.
The most important thing to note about this convention is that the left-hand side of the request URI is opaque to the network. The only network elements that need to know about the convention are the Media Server and client. Even proxies doing mapping resolution, as in the example above for public announcement services, do not need to be aware of the convention. The convention is purely a matter of provisioning.
关于这个约定，需要注意的最重要的一点是，请求URI的左侧对网络是不透明的。唯一需要了解约定的网络元素是媒体服务器和客户端。即使是执行映射解析的代理，如上面的公共公告服务示例所示，也不需要了解该约定。该公约纯粹是一个规定问题。
Some have proposed that such naming be a pure matter of local convention. For example, the thesis of the informational RFC RFC 3087 [17] is that you can address services using a request URI. However, some have taken the examples in the document to an extreme. Namely, that the only way to address services is via arbitrary, opaque, long user parts. Clearly, it is possible to provision the service names, rather than fixed names. While this can work in a closed network, where the Application Servers and Media Servers are in the same administrative domain, this does not work across domains, such as in the Internet. This is because the client of the media service has to know the local name for each service / domain pair. This is particularly onerous for situations where there is an ad hoc relationship between the application and the media service. Without a well-known relationship between service and service address, how would the client locate the service?
有些人提出，这种命名纯粹是当地习俗的问题。例如，信息RFC RFC 3087[17]的论点是，您可以使用请求URI来寻址服务。然而，有些人把文件中的例子带到了极端。也就是说，处理服务的唯一方法是通过任意、不透明、长用户部分。显然，可以提供服务名称，而不是固定名称。虽然这可以在封闭的网络中工作，其中应用程序服务器和媒体服务器位于同一管理域中，但这不能跨域工作，例如在Internet中。这是因为媒体服务的客户端必须知道每个服务/域对的本地名称。对于应用程序和媒体服务之间存在特殊关系的情况，这尤其繁重。如果服务和服务地址之间没有众所周知的关系，客户端将如何定位服务？
One very important result of using the user part as the service descriptor is that we can use all of the standard SIP machinery, without modification. For example, Media Servers with different capabilities can SIP Register their capabilities as users. For example, a VoiceXML-only device will register the "dialog" user, while a multi-purpose Media Server will register all of the users. Note that this is why the URI to play is a parameter. Doing otherwise would overburden a normal SIP proxy or redirect server. Conversely, having the conference ID be part of the user part gives an indication that requests get routed similarly (as opposed to requiring a Globally Routable User Agent URI (GRUU), which would restrict routing to the same device).
使用用户部分作为服务描述符的一个非常重要的结果是，我们可以使用所有标准SIP机制，而无需修改。例如，具有不同功能的媒体服务器可以将其功能注册为用户。例如，仅VoiceXML设备将注册“对话”用户，而多用途媒体服务器将注册所有用户。请注意，这就是为什么要播放的URI是一个参数。否则会使正常的SIP代理或重定向服务器负担过重。相反，将会议ID作为用户部分的一部分给出了请求以类似方式路由的指示（与要求全局可路由的用户代理URI（GRUU）相反，GRUU将限制路由到同一设备）。
Likewise, this scheme lets us leverage the standard SIP proxy behavior of using an intelligent redirect server or proxy server to provide high-available services. For example, two Media Servers can register with a SIP redirect server for the annc user. If one of the Media Servers fails, the registration will expire and all requests for the announcement service ("calls to the annc user") will get sent to the surviving Media Server.
同样，此方案允许我们利用标准SIP代理行为，即使用智能重定向服务器或代理服务器来提供高可用性服务。例如，两台媒体服务器可以向annc用户的SIP重定向服务器注册。如果其中一台媒体服务器出现故障，注册将过期，所有对公告服务的请求（“对annc用户的呼叫”）将被发送到幸存的媒体服务器。
Exposing network services with well-known addresses may not be desirable. The Media Server SHOULD authenticate and authorize requesting endpoints per local policy.
使用已知地址公开网络服务可能不可取。媒体服务器应根据本地策略对请求的端点进行身份验证和授权。
Some interactions in this document result in the transfer of confidential information. Moreover, many of the interactions require integrity protection. Thus, the Media Server MUST implement the sips: scheme. In addition, application developers are RECOMMENDED to use the security services offered by the Media Server to ensure the integrity and confidentiality of their user's data, as appropriate.
本文件中的某些交互导致机密信息的转移。此外，许多交互需要完整性保护。因此，媒体服务器必须实现sips:scheme。此外，建议应用程序开发人员酌情使用媒体服务器提供的安全服务，以确保其用户数据的完整性和机密性。
Untrusted network elements could use the convention described here for providing information services. Many extant billing arrangements are for completed calls. Successful call completion occurs with a 2xx result code. This can be an issue for the early media announcement service. This is one of the reasons why the early media announcement service is deprecated.
不受信任的网络元素可以使用此处描述的约定来提供信息服务。许多现存的计费安排都是针对已完成的呼叫。成功完成调用时，会显示2xx结果代码。这可能是早期媒体公告服务的一个问题。这就是早期媒体公告服务不受欢迎的原因之一。
Services such as repeating an announcement forever create the possibility for denial of service attacks. The media server SHOULD have local policies to deal with this, such as time-limiting how long "forever" is, analyzing where multiple requests come from, implementing white-lists for such a service, and so on.
诸如永远重复公告之类的服务可能会造成拒绝服务攻击。媒体服务器应该有本地策略来处理这个问题，例如限制“永久”的时间长度、分析多个请求来自何处、为这样的服务实现白名单等等。
Jeff Van Dyke and Andy Spitzer of SnowShore did just about all of the work developing netann, in conjunction with many application developers, media server manufacturers, and service providers, some of whom are listed in the Acknowledgements section. All I did was do the theory and write it up. That also means all of the mistakes are mine, as well.
SnowShore的杰夫·范·戴克（Jeff Van Dyke）和安迪·斯皮策（Andy Spitzer）与许多应用程序开发人员、媒体服务器制造商和服务提供商一起完成了开发netann的所有工作，其中一些人在致谢部分列出。我所做的只是做理论并把它写下来。这也意味着所有的错误都是我的。
We would like to thank Kevin Summers and Ravindra Kabre of Sonus Networks for their constructive comments, as well as Jonathan Rosenberg of Dynamicsoft and Tim Melanchuk of Convedia for their encouragement. In addition, the discussion at the Las Vegas Interim Workgroup Meeting in 2002 was invaluable for clearing up the issues surrounding the left-hand-side of the request URI. Christer Holmberg helped tune the language of the multimedia announcement service. Orit Levin from Radvision gave a close read on the most recent version of the document. Pete Danielsen from Lucent has consistently provided excellent reviews of the many different versions of this document.
我们要感谢Sonus Networks的凯文·萨默斯（Kevin Summers）和拉文德拉·卡布雷（Ravindra Kabre）的建设性评论，以及Dynamicsoft的乔纳森·罗森伯格（Jonathan Rosenberg）和Convedia的蒂姆·梅兰楚克（Tim Melanchuk）的鼓励。此外，2002年拉斯维加斯临时工作组会议上的讨论对于澄清围绕请求URI左侧的问题是非常宝贵的。克里斯特·霍姆伯格帮助调整了多媒体公告服务的语言。来自Radvision的Orit Levin仔细阅读了该文件的最新版本。朗讯公司的皮特·丹尼尔森（Pete Danielsen）一直对本文件的许多不同版本进行出色的评论。
Pascal Jalet provided the theoretical underpinning and David Rio provided the experimental evidence for why the conference identifier belongs in the user part of the request-URI.
Pascal Jalet提供了理论基础，David Rio提供了实验证据，证明会议标识符为什么属于请求URI的用户部分。
I am particularly indebted to Alan Johnston for his review of this document and ensuring its conformance with the SIP conference control work in the IETF.
我特别感谢Alan Johnston对本文件的审查，并确保其符合IETF中的SIP会议控制工作。
Mary Barnes, as usual, found the holes and showed how to fix them.
玛丽·巴恩斯像往常一样，发现了这些洞，并展示了如何修复它们。
The authors would like to give a special thanks to Walter O'Connor for doing much of the initial implementation.
作者要特别感谢Walter O'Connor为最初的实现做了大量工作。
Note that at the time of this writing, there are 7 known independent server implementations that are interoperable with 23 known client implementations. Our apologies if we did not count your implementation.
请注意，在撰写本文时，有7个已知的独立服务器实现可与23个已知的客户端实现互操作。如果我们没有计算您的实施，我们深表歉意。
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[2] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[3] Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[4] Freed，N.，Klensin，J.，和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[5] Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[7] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[8] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[9] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[9] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[10] 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.
[10] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[11] International Organization for Standardization, "Codes for the representation of names of languages -- Part 1: Alpha-2 code", ISO Standard 639-1, July 2002.
[11] 国际标准化组织，“语言名称表示代码——第1部分：Alpha-2代码”，ISO标准639-12002年7月。
[12] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166-1, October 1997.
[12] 国际标准化组织，“国家及其分支机构名称表示代码——第1部分：国家代码”，ISO标准3166-11997年10月。
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[13] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[14] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[14] Callaghan，B.，“NFS URL方案”，RFC2224，1997年10月。
[15] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[15] 《简单邮件传输协议》，RFC 28212001年4月。
[16] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[16] Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“网络文件系统（NFS）版本4协议”，RFC 3530，2003年4月。
[17] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[17] Campbell，B.和R.Sparks，“使用SIP请求URI控制服务上下文”，RFC3087，2001年4月。
[18] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[18] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[19] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[19] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[20] Burnett, D., Hunt, A., McGlashan, S., Porter, B., Lucas, B., Ferrans, J., Rehor, K., Carter, J., Danielsen, P., and S. Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C REC REC-voicexml20-20040316, March 2004.
[20] Burnett，D.，Hunt，A.，McGrashan，S.，Porter，B.，Lucas，B.，Ferrans，J.，Rehor，K.，Carter，J.，Danielsen，P.，和S.Tryphonas，“语音可扩展标记语言（VoiceXML）2.0版”，W3C REC REC-voicexml20-20040316，2004年3月。
[21] Van Dyke, J., Burger, E., Ed., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", Work in Progress, December 2004.
[21] Van Dyke，J.，Burger，E.，Ed.，和A.Spitzer，“媒体服务器控制标记语言（MSCML）和协议”，正在进行的工作，2004年12月。
[22] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, October 2004.
[22] Rosenberg，J.，“具有会话启动协议的会议框架”，正在进行的工作，2004年10月。
Authors' Addresses
作者地址
Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
Eric Burger Brooktrout Technology，Inc.18 Keewaydin Dr.Salem，NH 03079美国
EMail: eburger@brooktrout.com
EMail: eburger@brooktrout.com
Jeff Van Dyke Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
Jeff Van Dyke Brooktrout Technology，Inc.18 Keewaydin Dr.Salem，NH 03079美国
EMail: jvandyke@brooktrout.com
EMail: jvandyke@brooktrout.com
Andy Spitzer Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA
Andy Spitzer Brooktrout Technology，Inc.18 Keewaydin Dr.Salem，NH 03079美国
EMail: woof@brooktrout.com
EMail: woof@brooktrout.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。