Internet Engineering Task Force (IETF) D. Worley
Request for Comments: 7088 Ariadne
Category: Informational February 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Worley
Request for Comments: 7088 Ariadne
Category: Informational February 2014
ISSN: 2070-1721
Session Initiation Protocol Service Example -- Music on Hold
会话启动协议服务示例--音乐保留
Abstract
摘要
"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems. Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards-compliant. The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music-on-hold method described in Section 2.3 of RFC 5359.
“暂停播放音乐”是电话系统的一项功能，是商务电话系统购买者最想要的功能之一。音乐保留是指当通话一方的通话处于“保留”状态时，该方的电话会提供音频流（通常是音乐）供另一方收听。SIP的体系结构特征使得以完全符合标准的方式实现暂挂音乐变得困难。本文档中描述的音乐暂停的实施是完全有效的，符合标准，并且与之前记录的方法相比具有许多优势。特别是，与RFC 5359第2.3节中描述的音乐等待方法相比，它不太可能产生特殊的用户界面效果，更可能在执行身份验证的系统中工作。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7088.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7088.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Requirements Language ......................................4
2. Technique .......................................................4
2.1. Placing a Call on Hold and Establishing an External
Media Stream ...............................................5
2.2. Taking a Call off Hold and Terminating the External
Media Stream ...............................................6
2.3. Example Message Flow .......................................6
2.4. Receiving Re-INVITE and UPDATE from the Remote UA .........17
2.5. Receiving INVITE with Replaces ............................17
2.6. Receiving REFER from the Remote UA ........................19
2.7. Receiving Re-INVITE and UPDATE from the
Music-on-Hold Source ......................................21
2.8. Handling Payload Type Numbers .............................22
2.8.1. Analysis ...........................................22
2.8.2. Solution to the Problem ............................23
2.8.3. Example of the Solution ............................24
2.9. Dialog/Session Timers .....................................28
2.10. When the Media Stream Directionality is "inactive" .......28
2.11. Multiple Media Streams ...................................28
3. Advantages .....................................................29
4. Caveats ........................................................30
4.1. Offering All Available Media Formats ......................30
4.2. Handling Re-INVITES in a B2BUA ............................31
5. Security Considerations ........................................31
5.1. Network Security ..........................................31
5.2. SIP (Signaling) Security ..................................32
5.3. RTP (Media) Security ......................................32
5.4. Media Filtering ...........................................32
6. Acknowledgments ................................................33
7. References .....................................................34
7.1. Normative References ......................................34
7.2. Informative References ....................................34
1. Introduction ....................................................4
1.1. Requirements Language ......................................4
2. Technique .......................................................4
2.1. Placing a Call on Hold and Establishing an External
Media Stream ...............................................5
2.2. Taking a Call off Hold and Terminating the External
Media Stream ...............................................6
2.3. Example Message Flow .......................................6
2.4. Receiving Re-INVITE and UPDATE from the Remote UA .........17
2.5. Receiving INVITE with Replaces ............................17
2.6. Receiving REFER from the Remote UA ........................19
2.7. Receiving Re-INVITE and UPDATE from the
Music-on-Hold Source ......................................21
2.8. Handling Payload Type Numbers .............................22
2.8.1. Analysis ...........................................22
2.8.2. Solution to the Problem ............................23
2.8.3. Example of the Solution ............................24
2.9. Dialog/Session Timers .....................................28
2.10. When the Media Stream Directionality is "inactive" .......28
2.11. Multiple Media Streams ...................................28
3. Advantages .....................................................29
4. Caveats ........................................................30
4.1. Offering All Available Media Formats ......................30
4.2. Handling Re-INVITES in a B2BUA ............................31
5. Security Considerations ........................................31
5.1. Network Security ..........................................31
5.2. SIP (Signaling) Security ..................................32
5.3. RTP (Media) Security ......................................32
5.4. Media Filtering ...........................................32
6. Acknowledgments ................................................33
7. References .....................................................34
7.1. Normative References ......................................34
7.2. Informative References ....................................34
Within systems based on SIP [RFC3261], it is desirable to be able to provide features that are similar to those provided by traditional telephony systems. A frequently requested feature is "music on hold": with this feature, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party.
在基于SIP[RFC3261]的系统中，希望能够提供与传统电话系统提供的功能相似的功能。一个经常请求的功能是“音乐保持”：使用此功能，当通话一方的通话处于“保持”状态时，该方的电话会提供一个音频流（通常是音乐）供另一方听到。
Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards-compliant. The purpose of this document is to describe a method that is reasonably simple yet fully effective and standards-compliant. This method has significant advantages over other methods now in use, as described in Section 3.
SIP的体系结构特征使得以完全符合标准的方式实现暂挂音乐变得困难。本文件旨在描述一种合理简单但完全有效且符合标准的方法。如第3节所述，与目前使用的其他方法相比，该方法具有显著优势。
All current methods of implementing music on hold interoperate with each other, in that the two user agents in a call can use different methods for implementing music on hold with the same functionality as if either of the methods was used by both user agents. Thus, there is no loss of functionality if different music-on-hold methods are used by different user agents within a telephone system or if a single user agent uses different methods within different calls or at different times within one call.
所有当前实现音乐保留的方法都是互操作的，因为调用中的两个用户代理可以使用不同的方法来实现具有相同功能的音乐保留，就像两个用户代理都使用了其中一个方法一样。因此，如果电话系统中的不同用户代理使用不同的音乐保持方法，或者如果单个用户代理在不同呼叫中或在一个呼叫中的不同时间使用不同的方法，则不会丢失功能。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The essence of the technique is that when the executing user agent (UA) (the user's UA) performs a re-INVITE of the remote UA (the other user's UA) to establish the hold state, it provides no Session Description Protocol (SDP) [RFC4566] offer [RFC3264] [RFC6337], thus compelling the remote UA to provide an SDP offer. The executing UA then extracts the offer SDP from the remote UA's 2xx response and uses that as the offer SDP in a new INVITE to the external media source. The external media source is thus directed to provide media directly to the remote UA. The media source's answer SDP is returned to the remote UA in the ACK to the re-INVITE.
该技术的实质是，当执行用户代理（UA）（用户的UA）执行远程UA（另一用户的UA）的重新邀请以建立保持状态时，它不提供会话描述协议（SDP）[RFC4566]提供[RFC3264][RFC6337]，从而迫使远程UA提供SDP提供。然后，执行UA从远程UA的2xx响应中提取要约SDP，并将其用作对外部媒体源的新邀请中的要约SDP。因此，外部媒体源被定向为直接向远程UA提供媒体。媒体源的应答SDP在重新邀请的确认中返回给远程UA。
1. The executing user instructs the executing UA to put the dialog on hold.
1. 执行用户指示执行UA暂停对话。
2. The executing UA sends a re-INVITE without SDP to the remote UA, which forces the remote UA to provide an SDP offer in its 2xx response. The Contact header of the re-INVITE includes the '+sip.rendering="no"' field parameter to indicate that it is putting the call on hold ([RFC4235], Section 5.2).
2. 执行UA向远程UA发送不带SDP的重新邀请，这迫使远程UA在其2xx响应中提供SDP报价。重新邀请的联系人标头包含“+sip.rendering=“no”字段参数，以指示其正在暂停呼叫（[RFC4235]，第5.2节）。
3. The remote UA sends a 2xx to the re-INVITE and includes an SDP offer giving its own listening address/port. If the remote UA understands the sip.rendering feature parameter, the offer may indicate that it will not send media by specifying the media directionalities as "recvonly" (the reverse of "on hold") or "inactive". But the remote UA may offer to send media.
3. 远程UA向re INVITE发送一个2xx，并包含一个SDP提供，提供其自己的侦听地址/端口。如果远程UA理解sip.rendering特性参数，则要约可以通过将媒体方向指定为“recvonly”（与“on hold”相反）或“inactive”来指示其将不发送媒体。但是远程UA可以提供发送媒体。
4. The executing UA uses this offer to derive the offer SDP of an initial INVITE that it sends to the configured music-on-hold (MOH) source. The SDP in this request is largely copied from the SDP returned by the remote UA in the previous step, particularly regarding the provided listening address/port and payload type numbers. But the media directionalities are restricted to "recvonly" or "inactive" as appropriate. The executing UA may want or need to change the "o=" line. In addition, some "a=rtpmap" lines may need to be added to control the assignment of RTP payload type numbers (Section 2.8).
4. 执行UA使用该要约来派生初始邀请的要约SDP，该初始邀请发送到已配置的保留音乐（MOH）源。此请求中的SDP主要是从远程UA在上一步骤中返回的SDP复制的，特别是关于提供的侦听地址/端口和有效负载类型号。但媒体方向性被限制为“仅接收”或“不活动”。执行UA可能希望或需要更改“o=”行。此外，可能需要添加一些“a=rtpmap”行，以控制RTP有效负载类型编号的分配（第2.8节）。
5. The MOH source sends a 2xx response to the INVITE, which contains an SDP answer that should include its media source address as its listening address/port. This SDP must necessarily specify "sendonly" or "inactive" as the directionality for all media streams [RFC3264].
5. MOH源向INVITE发送2xx响应，其中包含SDP应答，该应答应包括其媒体源地址作为其侦听地址/端口。此SDP必须指定“sendonly”或“inactive”作为所有媒体流的方向性[RFC3264]。
Although this address/port should receive no RTP, the specified port determines the port for receiving the RTP Control Protocol (RTCP) (and conventionally, for sending RTCP [RFC4961]).
尽管此地址/端口不应接收RTP，但指定的端口确定用于接收RTP控制协议（RTCP）的端口（通常用于发送RTCP[RFC4961]）。
By convention, UAs use their declared RTP listening ports as their RTP source ports as well [RFC4961]. The answer SDP will reach the remote UA, thus informing it of the address/port from which the MOH media will come and presumably preventing the remote UA from ignoring the MOH media if the remote UA filters media packets based on the source address. This functionality requires the SDP answer to contain the sending address in the "c=" line, even though the MOH source does not receive RTP.
按照惯例，UAs也将其声明的RTP侦听端口用作其RTP源端口[RFC4961]。应答SDP将到达远程UA，从而通知其MOH媒体将来自的地址/端口，并且如果远程UA基于源地址过滤媒体包，则可能防止远程UA忽略MOH媒体。此功能要求SDP应答在“c=”行中包含发送地址，即使MOH源未接收RTP。
6. The executing UA sends this SDP answer as its SDP answer in the ACK for the re-INVITE to the remote UA. The "o=" line in the answer must be modified to be within the sequence of "o=" lines previously generated by the executing UA in the dialog. Any dynamic payload type number assignments that have been created in the answer must be recorded in the state of the original dialog.
6. 正在执行的UA将此SDP应答作为其SDP应答发送到ACK中，以便重新邀请远程UA。答案中的“o=”行必须修改为在对话框中执行UA先前生成的“o=”行序列内。在应答中创建的任何动态有效负载类型编号分配必须记录在原始对话框的状态中。
7. Due to the sip.rendering feature parameter in the Contact header of the re-INVITE and the media directionality in the SDP answer contained in the ACK, the on-hold state of the dialog is established (at the executing end).
7. 由于重新邀请的联系人标头中的sip.rendering feature参数以及ACK中包含的SDP应答中的媒体方向性，因此建立了对话框的保持状态（在执行端）。
8. After this point, the MOH source generates RTP containing the music-on-hold media and sends it directly to the listening address/port of the remote UA. The executing UA maintains two dialogs (one to the remote UA, one to the MOH source) but does not see or handle the MOH RTP.
8. 在此之后，MOH源生成包含音乐保留媒体的RTP，并将其直接发送到远程UA的侦听地址/端口。执行UA维护两个对话框（一个到远程UA，一个到MOH源），但不查看或处理MOH RTP。
1. The executing user instructs the executing UA to take the dialog off hold.
1. 执行用户指示执行UA停止对话。
2. The executing UA sends a re-INVITE to the remote UA with SDP that requests to receive media. The Contact header of the re-INVITE does not include the '+sip.rendering="no"' field parameter. (It may contain a sip.rendering field parameter with value "yes" or "unknown", or it may omit the field parameter.) Thus, this re-INVITE removes the on-hold state of the dialog (at the executing end). (Note that the version in "o=" line of the offered SDP must account for the SDP versions that were passed through from the MOH source. Also note that any payload type numbers that were assigned in SDP provided by the MOH source must be respected.)
2. 执行UA使用请求接收媒体的SDP向远程UA发送重新邀请。重新邀请的联系人标头不包括“+sip.rendering=“no”字段参数。（它可能包含值为“yes”或“unknown”的sip.rendering字段参数，也可能忽略字段参数。）因此，此重新邀请将删除对话框的保留状态（在执行端）。（请注意，提供的SDP的“o=”行中的版本必须说明从MOH来源传递的SDP版本。还请注意，必须遵守MOH来源提供的SDP中分配的任何有效负载类型编号。）
3. When the remote UA sends a 2xx response to the re-INVITE, the executing UA sends a BYE request in the dialog to the MOH source.
3. 当远程UA向重新邀请发送2xx响应时，执行UA在对话框中向MOH源发送BYE请求。
4. After this point, the MOH source does not generate RTP and ordinary RTP flow is reestablished in the original dialog.
4. 在这一点之后，MOH震源不会生成RTP，普通RTP流将在原始对话框中重新建立。
This section shows a message flow that is an example of this technique. The scenario is as follows. Alice establishes a call with Bob. Bob then places the call on hold, with music on hold provided from an external source. Bob then takes the call off hold. In this scenario, Bob's user agent is the executing UA, while Alice's
本节显示了作为此技术示例的消息流。情况如下。爱丽丝与鲍勃建立了联系。然后，Bob将呼叫挂起，并从外部来源提供音乐挂起。然后鲍勃把电话挂断。在这个场景中，Bob的用户代理是执行UA，而Alice的用户代理是执行UA
UA is the remote UA. Note that this is just one possible message flow that illustrates this technique; numerous variations on these operations are allowed by the applicable standards.
UA是远程UA。请注意，这只是说明此技术的一个可能的消息流；适用标准允许对这些操作进行多种变更。
Alice Bob Music Source
Alice Bob音乐源
Alice establishes the call:
Alice建立呼叫：
| | |
| INVITE F1 | |
|--------------->| |
| 180 Ringing F2 | |
|<---------------| |
| 200 OK F3 | |
|<---------------| |
| ACK F4 | |
|--------------->| |
| RTP | |
|<==============>| |
| | |
| | |
| INVITE F1 | |
|--------------->| |
| 180 Ringing F2 | |
|<---------------| |
| 200 OK F3 | |
|<---------------| |
| ACK F4 | |
|--------------->| |
| RTP | |
|<==============>| |
| | |
Bob places Alice on hold, compelling Alice's UA to provide SDP:
Bob暂停Alice，迫使Alice的UA提供SDP：
| | |
| INVITE F5 | |
| (no SDP) | |
|<---------------| |
| 200 OK F6 | |
| (SDP offer) | |
|--------------->| |
| | |
| | |
| INVITE F5 | |
| (no SDP) | |
|<---------------| |
| 200 OK F6 | |
| (SDP offer) | |
|--------------->| |
| | |
Bob's UA initiates music on hold:
鲍勃的UA发起暂停音乐：
| | |
| | INVITE F7 |
| | (SDP offer, |
| | rev. hold) |
| |------------->|
| | 200 OK F8 |
| | (SDP answer, |
| | hold) |
| |<-------------|
| | ACK F9 |
| |------------->|
| | |
| | |
| | INVITE F7 |
| | (SDP offer, |
| | rev. hold) |
| |------------->|
| | 200 OK F8 |
| | (SDP answer, |
| | hold) |
| |<-------------|
| | ACK F9 |
| |------------->|
| | |
Bob's UA provides an SDP answer containing the address/port of Music Source:
Bob的UA提供包含音乐源地址/端口的SDP应答：
| | |
| ACK F10 | |
| (SDP answer, | |
| hold) | |
|<---------------| |
| no RTP | |
|<..............>| |
| Music-on-hold RTP |
|<==============================|
| | |
| | |
| ACK F10 | |
| (SDP answer, | |
| hold) | |
|<---------------| |
| no RTP | |
|<..............>| |
| Music-on-hold RTP |
|<==============================|
| | |
The music on hold is active.
暂停的音乐处于活动状态。
Bob takes Alice off hold:
鲍勃让艾丽丝停下来：
| | |
| INVITE F11 | |
| (SDP offer) | |
|<---------------| |
| 200 OK F12 | |
| (SDP answer) | |
|--------------->| |
| ACK F13 | |
|<---------------| |
| | BYE F14 |
| |------------->|
| | 200 F15 |
| |<-------------|
| RTP | |
|<==============>| |
| | |
| | |
| INVITE F11 | |
| (SDP offer) | |
|<---------------| |
| 200 OK F12 | |
| (SDP answer) | |
|--------------->| |
| ACK F13 | |
|<---------------| |
| | BYE F14 |
| |------------->|
| | 200 F15 |
| |<-------------|
| RTP | |
|<==============>| |
| | |
The normal media session between Alice and Bob is resumed.
Alice和Bob之间的正常媒体会话将恢复。
/* Alice calls Bob. */
/* Alice calls Bob. */
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Content-Length: 0
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
ACK sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bfd
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 ACK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
ACK sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bfd
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 ACK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
/* Bob places Alice on hold. */
/* Bob places Alice on hold. */
/* The re-INVITE contains no SDP, thus compelling Alice's UA
to provide an offer. */
/* The re-INVITE contains no SDP, thus compelling Alice's UA
to provide an offer. */
F5 INVITE Bob -> Alice
F5邀请Bob->Alice
INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 INVITE
Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 INVITE
Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
/* Alice's UA provides an SDP offer.
Since it does not know that it is being put on hold,
the offer is the same as the original offer and describes
bidirectional media. */
/* Alice's UA provides an SDP offer.
Since it does not know that it is being put on hold,
the offer is the same as the original offer and describes
bidirectional media. */
F6 200 OK Alice -> Bob
F6 200 OK Alice->Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=active
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=active
/* Bob's UA initiates music on hold. */
/* Bob's UA initiates music on hold. */
/* This INVITE contains Alice's offer, but with the media
direction set to "reverse hold", receive-only. */
/* This INVITE contains Alice's offer, but with the media
direction set to "reverse hold", receive-only. */
F7 INVITE Bob -> Music Source
F7邀请Bob->音乐源
INVITE sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>
Call-ID: 4802029847@biloxi.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
INVITE sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>
Call-ID: 4802029847@biloxi.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844534 2890844534 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
v=0
o=bob 2890844534 2890844534 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
F8 200 OK Music Source -> Bob
F8 200 OK音乐源->鲍勃
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
;received=192.0.2.105
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
Contact: <sips:music@source.example.com>;automaton
;+sip.byeless;+sip.rendering="no"
CSeq: 1 INVITE
Content-Length: [omitted]
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
;received=192.0.2.105
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
Contact: <sips:music@source.example.com>;automaton
;+sip.byeless;+sip.rendering="no"
CSeq: 1 INVITE
Content-Length: [omitted]
v=0
o=MusicSource 2890844576 2890844576 IN IP4 source.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
v=0
o=MusicSource 2890844576 2890844576 IN IP4 source.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
F9 ACK Bob -> Music Source
F9确认鲍勃->音乐源
ACK sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS source.example.com:5061
;branch=z9hG4bK74bT6
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Max-Forwards: 70
Call-ID: 4802029847@biloxi.example.com
CSeq: 1 ACK
Content-Length: 0
ACK sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS source.example.com:5061
;branch=z9hG4bK74bT6
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Max-Forwards: 70
Call-ID: 4802029847@biloxi.example.com
CSeq: 1 ACK
Content-Length: 0
/* Bob's UA now sends the ACK that completes the re-INVITE
to Alice and completes the SDP offer/answer.
The ACK contains the SDP received from Music Source and thus
contains the address/port from which Music Source will send media,
and implies the address/port that Music
Source will use to send/receive RTCP. */
/* Bob's UA now sends the ACK that completes the re-INVITE
to Alice and completes the SDP offer/answer.
The ACK contains the SDP received from Music Source and thus
contains the address/port from which Music Source will send media,
and implies the address/port that Music
Source will use to send/receive RTCP. */
F10 ACK Bob -> Alice
F10确认鲍勃->爱丽丝
ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKq874b
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 ACK
Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: [omitted]
ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKq874b
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 ACK
Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844528 IN IP4 biloxi.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
v=0
o=bob 2890844527 2890844528 IN IP4 biloxi.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Bob picks up the call by sending a re-INVITE to Alice. */
/* Bob picks up the call by sending a re-INVITE to Alice. */
F11 INVITE Bob -> Alice
F11邀请鲍勃->爱丽丝
INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844529 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=bob 2890844527 2890844529 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F12 200 OK Alice -> Bob
F12 200 OK Alice->Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844527 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=alice 2890844526 2890844527 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F13 ACK Bob -> Alice
F13确认鲍勃->爱丽丝
ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKq874b
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 ACK
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKq874b
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 ACK
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
F14 BYE Bob -> Music Source
F14再见鲍勃->音乐源
BYE sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK74rf
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
CSeq: 2 BYE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Length: [omitted]
BYE sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK74rf
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
CSeq: 2 BYE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Length: [omitted]
F15 200 OK Music Source -> Bob
F15 200 OK音乐源->鲍勃
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74rf
;received=192.0.2.103
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
Contact: <sips:music@source.example.com>;automaton
;+sip.byeless;+sip.rendering="no"
CSeq: 2 BYE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74rf
;received=192.0.2.103
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
Contact: <sips:music@source.example.com>;automaton
;+sip.byeless;+sip.rendering="no"
CSeq: 2 BYE
Content-Length: 0
/* Normal media session between Alice and Bob is resumed. */
/* Normal media session between Alice and Bob is resumed. */
While the call is on hold, the remote UA can send a request to modify the SDP or the feature parameters of its Contact header. This can be done with either an INVITE or UPDATE method, both of which have much the same effect in regard to MOH.
呼叫处于等待状态时，远程UA可以发送请求，以修改SDP或其联系人标头的特征参数。这可以通过INVITE或UPDATE方法来实现，这两种方法对MOH的效果几乎相同。
A common reason for a re-INVITE is when the remote UA desires to put the dialog on hold on its end. And because of the need to support this case, an implementation must process INVITEs and UPDATEs during the on-hold state as described below.
重新邀请的一个常见原因是远程UA希望在其端暂停对话。由于需要支持这种情况，实现必须在保持状态期间处理邀请和更新，如下所述。
The executing UA handles these requests by echoing requests and responses: an incoming request from the remote UA causes the executing UA to send a similar request to the MOH source, and an incoming response from the MOH source causes the executing UA to send a similar response to the remote UA. In all cases, SDP offers or answers that are received are added as bodies to the stimulated request or response to the other UA.
执行UA通过回显请求和响应来处理这些请求：来自远程UA的传入请求导致执行UA向MOH源发送类似的请求，来自MOH源的传入响应导致执行UA向远程UA发送类似的响应。在所有情况下，收到的SDP报价或答复都作为主体添加到对其他UA的刺激请求或响应中。
The passed-through SDP will usually need its "o=" line modified. The directionality attributes may need to be restricted by changing "active" to "recvonly" and "sendonly" to "inactive", as the executing UA will not render media from the remote UA. (If all passed-through directionality attributes are "inactive", the optimization described in Section 2.10 may be applied.) In regard to payload type numbers, since the mapping has already been established within the MOH dialog, "a=rtpmap" lines need not be added.
通过的SDP通常需要修改其“o=”行。方向性属性可能需要通过将“active”更改为“recvonly”并将“sendnonly”更改为“inactive”来限制，因为执行UA不会呈现来自远程UA的媒体。（如果所有通过方向性属性均为“非活动”，则可采用第2.10节中所述的优化。）对于有效载荷类型编号，由于已在MOH对话框中建立映射，因此无需添加“a=rtpmap”行。
The executing UA must be prepared to receive an INVITE request with a Replaces header that specifies the dialog with the remote UA. If the executing UA wants to create this new dialog in the on-hold state, it creates a new dialog with the MOH source to obtain MOH. The executing UA negotiates the SDP within the dialog created by the INVITE with Replaces by passing the offer through to the new MOH dialog (if the INVITE contains an offer) or by creating the new MOH dialog with an offerless INVITE (if the INVITE does not contain an offer).
正在执行的UA必须准备好接收INVITE请求，该请求具有指定与远程UA对话的Replaces标头。如果执行UA希望在保留状态下创建此新对话框，它将使用MOH源创建一个新对话框以获取MOH。执行UA通过将要约传递给新的MOH对话框（如果邀请中包含要约）或通过创建新的MOH对话框（如果邀请中不包含要约），在由邀请创建的对话框内用替换协商SDP。
Continuing the example of Section 2.3, the executing UA receives an INVITE with Replaces that contains an offer:
继续第2.3节的示例，执行UA收到一个邀请，其中包含一个报价：
Alice Bob Music Source Carol
艾丽丝·鲍勃音乐来源卡罗尔
(For example, Alice has called Carol and initiates an attended transfer by sending a REFER to Carol, causing Carol to send an INVITE with Replaces to Bob.)
（例如，Alice打电话给Carol，并通过发送“转介给Carol”来启动有人值守的转接，从而使Carol向Bob发送一个带有替换项的邀请。）
Bob receives INVITE with Replaces from Carol:
Bob收到Carol的邀请并替换：
| | | |
| | | INVITE/Replaces |
| | | From: Carol |
| | | To: Bob |
| | | (SDP offer) |
| |<-------------------------------|
| | INVITE | |
| | From: Bob | |
| | To: Music Source |
| | (SDP offer, | |
| | rev. hold) | |
| |------------->| |
| | 200 OK | |
| | From: Bob | |
| | To: Music Source |
| | (SDP answer, | |
| | hold) | |
| |<-------------| |
| | ACK | |
| | From: Bob | |
| | To: Music Source |
| |------------->| |
| | | 200 OK |
| | | From: Carol |
| | | To: Bob |
| | | (SDP answer, |
| | | hold) |
| |------------------------------->|
| | | ACK |
| | | From: Carol |
| | | To: Bob |
| |<-------------------------------|
| | | Music-on-hold RTP
| | |================>|
| | | |
| | | |
| | | INVITE/Replaces |
| | | From: Carol |
| | | To: Bob |
| | | (SDP offer) |
| |<-------------------------------|
| | INVITE | |
| | From: Bob | |
| | To: Music Source |
| | (SDP offer, | |
| | rev. hold) | |
| |------------->| |
| | 200 OK | |
| | From: Bob | |
| | To: Music Source |
| | (SDP answer, | |
| | hold) | |
| |<-------------| |
| | ACK | |
| | From: Bob | |
| | To: Music Source |
| |------------->| |
| | | 200 OK |
| | | From: Carol |
| | | To: Bob |
| | | (SDP answer, |
| | | hold) |
| |------------------------------->|
| | | ACK |
| | | From: Carol |
| | | To: Bob |
| |<-------------------------------|
| | | Music-on-hold RTP
| | |================>|
| | | |
Bob terminates the previous dialog with Alice:
Bob终止与Alice的上一个对话框：
| | | |
| BYE | | |
| From: Bob | | |
| To: Alice | | |
|<---------------| | |
| 200 OK | | |
| From: Bob | | |
| To: Alice | | |
|--------------->| | |
| | | |
| | | |
| BYE | | |
| From: Bob | | |
| To: Alice | | |
|<---------------| | |
| 200 OK | | |
| From: Bob | | |
| To: Alice | | |
|--------------->| | |
| | | |
Bob terminates the MOH dialog for the dialog with Alice:
Bob终止与Alice对话的MOH对话：
| | | |
| | BYE | |
| | From: Bob | |
| | To: Music Source |
| |------------->| |
| | 200 OK | |
| | From: Music Source |
| | To: Bob | |
| |<-------------| |
| | | |
| | | |
| | BYE | |
| | From: Bob | |
| | To: Music Source |
| |------------->| |
| | 200 OK | |
| | From: Music Source |
| | To: Bob | |
| |<-------------| |
| | | |
The new session continues on hold, between Bob and Carol.
Bob和Carol之间的新会议继续暂停。
The executing UA must be prepared to receive a REFER request within the dialog with the remote UA. The SDP within the dialog created by the REFER is negotiated by sending an offerless INVITE (or offerless re-INVITE) to the MOH source to obtain an offer and then using that offer in the INVITE to the refer target.
执行UA必须准备好在与远程UA的对话中接收REFER请求。通过向卫生部来源发送无要约邀请（或无要约再邀请）以获得要约，然后在邀请中使用该要约来协商由REFER创建的对话框中的SDP，以获得要约。
Similar processing is used for an out-of-dialog REFER whose Target-Dialog header refers to the dialog with the remote UA.
类似的处理用于对话外引用，其目标对话头引用与远程UA的对话。
Continuing the example of Section 2.3, the executing UA receives an INVITE with Replaces that contains an offer:
继续第2.3节的示例，执行UA收到一个邀请，其中包含一个报价：
Alice Bob Music Source Carol
艾丽丝·鲍勃音乐来源卡罗尔
(For example, Alice initiates an unattended transfer of the call to Carol by sending a REFER to Bob.)
（例如，Alice通过发送refere-to-Bob来发起无人值守的呼叫转接。）
Bob receives REFER from Alice:
Bob收到Alice的推荐信：
| | | |
| REFER | | |
| From: Bob | | |
| To: Alice | | |
| Refer-To: Carol| | |
|--------------->| | |
| | re-INVITE | |
| | From: Bob | |
| | To: Music Source |
| | (no SDP) | |
| |------------->| |
| | 200 OK | |
| | From: Bob | |
| | To: Music Source |
| | (SDP offer, | |
| | hold) | |
| |<-------------| |
| | | INVITE |
| | | From: Bob |
| | | To: Carol |
| | | (SDP offer, |
| | | hold) |
| |------------------------------->|
| | | 200 OK |
| | | From: Bob |
| | | To: Carol |
| | | (SDP answer, |
| | | rev. hold) |
| |------------------------------->|
| | ACK | |
| | From: Bob | |
| | To: Music Source |
| | (SDP answer, | |
| | rev. hold) | |
| |------------->| |
| | | ACK |
| | | From: Bob |
| | | To: Carol |
| |------------------------------->|
| | | |
| REFER | | |
| From: Bob | | |
| To: Alice | | |
| Refer-To: Carol| | |
|--------------->| | |
| | re-INVITE | |
| | From: Bob | |
| | To: Music Source |
| | (no SDP) | |
| |------------->| |
| | 200 OK | |
| | From: Bob | |
| | To: Music Source |
| | (SDP offer, | |
| | hold) | |
| |<-------------| |
| | | INVITE |
| | | From: Bob |
| | | To: Carol |
| | | (SDP offer, |
| | | hold) |
| |------------------------------->|
| | | 200 OK |
| | | From: Bob |
| | | To: Carol |
| | | (SDP answer, |
| | | rev. hold) |
| |------------------------------->|
| | ACK | |
| | From: Bob | |
| | To: Music Source |
| | (SDP answer, | |
| | rev. hold) | |
| |------------->| |
| | | ACK |
| | | From: Bob |
| | | To: Carol |
| |------------------------------->|
| | | Music-on-hold RTP
| | |================>|
| | | |
| | | Music-on-hold RTP
| | |================>|
| | | |
Bob terminates the previous dialog with Alice:
Bob终止与Alice的上一个对话框：
| | | |
| BYE | | |
| From: Bob | | |
| To: Alice | | |
|<---------------| | |
| 200 OK | | |
| From: Bob | | |
| To: Alice | | |
|--------------->| | |
| | | |
| | | |
| BYE | | |
| From: Bob | | |
| To: Alice | | |
|<---------------| | |
| 200 OK | | |
| From: Bob | | |
| To: Alice | | |
|--------------->| | |
| | | |
It is possible for the MOH source to send a re-INVITE or UPDATE request, and the executing UA can support doing so in similar manner as requests from the remote UA. However, if the MOH source is within the same administrative domain as the executing UA, the executing UA may have knowledge that the MOH source will not (or need not) make such requests and so can respond to any such request with a failure response, avoiding the need to pass the request through. The 403 (Forbidden) response is suitable for this purpose because [RFC3261] specifies that this response indicates "the request SHOULD NOT be repeated".
MOH源可以发送重新邀请或更新请求，并且执行UA可以支持以与来自远程UA的请求类似的方式这样做。然而，如果MOH源与执行UA位于同一管理域内，则执行UA可能知道MOH源不会（或不需要）发出此类请求，因此可以使用失败响应响应任何此类请求，从而避免通过请求的需要。403（禁止）响应适用于此目的，因为[RFC3261]指定此响应表示“不应重复请求”。
However, in an environment in which Interactive Connectivity Establishment (ICE) [RFC5245] is supported, the MOH source may need to send requests as part of ICE negotiation with the remote UA. Hence, in environments that support ICE, the executing UA must be able to pass through requests from the MOH source as well as requests from the remote UA.
然而，在支持交互式连接建立（ICE）[RFC5245]的环境中，MOH源可能需要发送请求，作为与远程UA的ICE协商的一部分。因此，在支持ICE的环境中，执行UA必须能够通过来自MOH源的请求以及来自远程UA的请求。
Again, as SDP is passed through, its "o=" line will need to be modified. In some cases, the directionality attributes will need to be restricted.
同样，在传递SDP时，需要修改其“o=”行。在某些情况下，需要限制方向性属性。
In this technique, the MOH source generates an SDP answer that the executing UA presents to the remote UA as an answer within the original dialog. In basic functionality, this presents no problem, because [RFC3264], Section 6.1 (at the very end) specifies that the payload type numbers used in either direction of RTP are the ones specified in the SDP sent by the recipient of the RTP. Thus, the MOH source will send RTP to the remote UA using the payload type numbers specified in the offer SDP it received (ultimately) from the remote UA.
在这种技术中，MOH源生成SDP应答，执行UA将该应答作为原始对话框中的应答呈现给远程UA。在基本功能中，这不存在问题，因为[RFC3264]第6.1节（在最后）规定RTP任一方向上使用的有效负载类型编号是RTP接收方发送的SDP中指定的编号。因此，MOH源将使用从远程UA接收（最终）的报价SDP中指定的有效负载类型号向远程UA发送RTP。
But strict compliance to [RFC3264], Section 8.3.2 requires that payload type numbers used in SDP may only duplicate the payload type numbers used in any previous SDP sent in the same direction if the payload type numbers represent the same media format (codec) as they did previously. However, the MOH source has no knowledge of the payload type numbers previously used in the original dialog, and it may accidentally specify a different media format for a previously used payload type number in its answer (or in a subsequently generated INVITE or UPDATE). This would cause no problem with media decoding, as it cannot send any format that was not in the remote UA's offer, but it would violate [RFC3264].
但严格遵守[RFC3264]，第8.3.2节要求，SDP中使用的有效负载类型编号只能与任何先前以相同方向发送的SDP中使用的有效负载类型编号重复，前提是有效负载类型编号表示与先前相同的媒体格式（编解码器）。但是，MOH源不知道先前在原始对话框中使用的有效负载类型编号，并且可能会在其回答中（或在随后生成的INVITE或UPDATE中）意外地为先前使用的有效负载类型编号指定不同的媒体格式。这不会导致媒体解码出现问题，因为它无法发送任何不在远程UA报价中的格式，但会违反[RFC3264]。
Strictly speaking, it is impossible to avoid this problem because the generator of a first answer in its dialog can choose the payload numbers independently of the payload numbers in the offer, and the MOH server believes that its answer is first in the dialog. Thus, the only absolute solution is to have the executing UA rewrite the SDP that passes through it to reassign payload type numbers, which would also require it to rewrite the payload type numbers in the RTP packets -- a very undesirable solution.
严格来说，无法避免此问题，因为对话框中第一个答案的生成器可以独立于报价中的有效负载编号选择有效负载编号，并且MOH服务器认为其答案是对话框中的第一个答案。因此，唯一绝对的解决方案是让执行UA重写通过它的SDP以重新分配有效负载类型号，这也需要它重写RTP数据包中的有效负载类型号——这是一个非常不理想的解决方案。
The difficulty solving this problem (and similar problems in other situations) argues that strict adherence should not be required to the rule that payload type numbers not be reused for different codecs.
解决这个问题（以及其他情况下的类似问题）的困难在于，不应严格遵守有效负载类型编号不能用于不同编解码器的规则。
If an implementation of this technique were to interact with a remote UA that requires strict compliance to [RFC3264], the remote UA might reject the SDP provided by the MOH server. (In Section 2.3, this SDP is in message F10.) As a result, the MOH session will not be established, and the call will remain in its initial state. Implementors that wish to avoid this situation need to implement the solution in Section 2.8.2.
如果该技术的实现与要求严格遵守[RFC3264]的远程UA交互，则远程UA可能拒绝MOH服务器提供的SDP。（在第2.3节中，此SDP在消息F10中。）因此，MOH会话将不会建立，呼叫将保持在其初始状态。希望避免这种情况的实施者需要实施第2.8.2节中的解决方案。
We can construct a technique that will strictly adhere to the payload type rule by exploiting a SHOULD-level requirement in [RFC3264], Section 6.1: "In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer". Or rather, we exploit the "implied requirement" that if a specific payload number in the offer is used for a particular codec, then the answer should not use that payload number for a different codec. If the MOH source obeys this restriction, the executing UA can modify the offer SDP to "reserve" all payload type numbers that have ever been offered by the executing UA to prevent the MOH source from using them for different media formats.
我们可以通过利用[RFC3264]第6.1节中的“应”级别要求来构建一种严格遵守有效负载类型规则的技术：“在RTP的情况下，如果某个特定编解码器在报价中引用了特定的有效负载类型编号，那么在应答中该编解码器应使用相同的有效负载类型编号”。或者更确切地说，我们利用“隐含要求”，即如果报价中的特定有效载荷编号用于特定编解码器，则答案不应将该有效载荷编号用于不同的编解码器。如果MOH源遵守此限制，则执行UA可以修改要约SDP以“保留”执行UA曾经提供的所有有效负载类型编号，以防止MOH源将其用于不同的媒体格式。
When the executing UA is composing the INVITE to the MOH source, it compiles a list of all the (dynamically assigned) payload type numbers and associated media formats that have been used by it (or by MOH sources on its behalf) in the original dialog. (The executing UA must maintain a list of all previously used payload type numbers anyway, in order to comply with [RFC3264].)
当执行UA编写对MOH源的邀请时，它将编译一个列表，其中列出它（或代表它的MOH源）在原始对话框中使用的所有（动态分配的）有效负载类型号和相关媒体格式。（执行UA必须保留所有先前使用的有效负载类型编号列表，以符合[RFC3264]。）
Any payload type number that is present in the offer but has been used previously by the executing UA in the original dialog for a different media format is rewritten to describe a dummy media format. (One dummy media format name can be used for many payload type numbers as multiple payload type numbers can refer to the same media format.) A payload type number is added to describe the deleted media format, the number being either previously unused or previously used by the executing UA for that media format.
报价中存在的任何有效负载类型编号，但执行UA之前在原始对话框中使用过不同媒体格式的有效负载类型编号，将被重写以描述虚拟媒体格式。（一个虚拟媒体格式名称可用于多个有效负载类型编号，因为多个有效负载类型编号可引用相同的媒体格式。）添加有效负载类型编号以描述已删除的媒体格式，该编号以前未使用或执行UA以前使用该媒体格式。
Any further payload type numbers that have been used by the executing UA in the original dialog but that are not mapped to a media format in the current offer are then mapped to a dummy media format.
执行UA在原始对话框中使用但未映射到当前报价中的媒体格式的任何其他有效负载类型号随后映射到虚拟媒体格式。
The result is that the modified offer SDP:
结果是修改后的报价SDP：
1. offers the same set of media formats (ignoring dummies) as the original offer SDP (though possibly with different payload type numbers),
1. 提供与原始产品SDP相同的一组媒体格式（忽略假人）（尽管可能具有不同的有效负载类型编号），
2. associates every payload type number either with a dummy media format or with the media format that the executing UA has previously used it for, and
2. 将每个有效负载类型编号与虚拟媒体格式或执行UA先前使用的媒体格式相关联，以及
3. provides a (real or dummy) media format for every payload type number that the executing UA has previously used.
3. 为执行UA先前使用的每个有效负载类型号提供（实或伪）媒体格式。
These properties are sufficient to force an MOH server that obeys the implied requirement to generate an answer that is a correct answer to the original offer and is also compatible with previous SDP from the executing UA.
这些属性足以迫使遵守隐含要求的MOH服务器生成对原始报价的正确答复，并且与执行UA先前的SDP兼容。
Note that any re-INVITEs from the remote UA that the executing UA passes through to the MOH server require similar modification, as payload type numbers that the MOH server receives in past offers are not absolutely reserved against its use (as they have not been sent in SDP by the MOH server) nor is there a SHOULD-level proscription against using them in the current answer (as they do not appear in the current offer).
请注意，执行UA传递给MOH服务器的远程UA的任何重新邀请都需要进行类似的修改，因为MOH服务器在过去的报价中收到的有效负载类型号并不是绝对禁止其使用的（因为MOH服务器没有在SDP中发送）在当前的答复中也没有禁止使用它们的规定（因为它们没有出现在当前的报价中）。
This should provide an adequate solution to the problems with payload type numbers, as it will fail only if (1) the remote UA is particular that other UAs follow the rule about not redefining payload type numbers, and (2) the MOH server does not follow the implied requirement of [RFC3264], Section 6.1.
这应该为有效载荷类型编号问题提供充分的解决方案，因为只有在以下情况下，该解决方案才会失败：（1）远程UA特别要求其他UA遵守关于不重新定义有效载荷类型编号的规则；（2）MOH服务器不遵守[RFC3264]第6.1节的隐含要求。
Let us show how this process works by modifying the example of Section 2.3 with this specific assignment of supported codecs:
让我们通过修改第2.3节的示例来说明此过程是如何工作的，具体指定了支持的编解码器：
Alice supports formats X and Y.
Alice支持X和Y格式。
Bob supports formats X and Z.
Bob支持格式X和Z。
Music Source supports formats Y and Z.
音乐源支持Y和Z格式。
In this case, the SDP exchanges are:
在这种情况下，SDP交换是：
F1 offers X and Y, F3 answers X and Z. (Only X can be used.)
F1提供X和Y，F3回答X和Z。（只能使用X。）
F6 offers X and Y, but F7 offers X, Y, and a place-holder to block use of type 92.
F6提供X和Y，但F7提供X、Y和一个占位符来阻止92型的使用。
F8/F10 answers Y.
F8/F10回答Y。
The messages that are changed from Section 2.3 are:
第2.3节中更改的信息包括：
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 90 91
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 90 91
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 90 92
a=rtpmap:90 X/8000
a=rtpmap:92 Z/8000
v=0
o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 90 92
a=rtpmap:90 X/8000
a=rtpmap:92 Z/8000
F6 200 OK Alice -> Bob
F6 200 OK Alice->Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 90 91
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
a=active
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 90 91
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
a=active
F7 INVITE Bob -> Music Source
F7邀请Bob->音乐源
INVITE sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>
Call-ID: 4802029847@biloxi.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
INVITE sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>
Call-ID: 4802029847@biloxi.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844534 2890844534 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 90 91 92
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
a=rtpmap:92 x-reserved/8000
a=recvonly
v=0
o=bob 2890844534 2890844534 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 90 91 92
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
a=rtpmap:92 x-reserved/8000
a=recvonly
F8 200 OK Music Source -> Bob
F8 200 OK音乐源->鲍勃
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
;received=192.0.2.105
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
Contact: <sips:music@source.example.com>;automaton
;+sip.byeless;+sip.rendering="no"
CSeq: 1 INVITE
Content-Length: [omitted]
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
;received=192.0.2.105
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
Contact: <sips:music@source.example.com>;automaton
;+sip.byeless;+sip.rendering="no"
CSeq: 1 INVITE
Content-Length: [omitted]
v=0
o=MusicSource 2890844576 2890844576 IN IP4 source.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 91
a=rtpmap:91 Y/8000
a=sendonly
v=0
o=MusicSource 2890844576 2890844576 IN IP4 source.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 91
a=rtpmap:91 Y/8000
a=sendonly
The executing UA may discover that either the remote UA or the MOH source wishes to use dialog/session liveness timers [RFC4028]. Since the timers verify the liveness of dialogs, not sessions (despite the terminology of [RFC4028]), the executing UA can support the timers on each dialog (to the remote UA and to the MOH source) independently. (If the executing UA becomes obliged to initiate a refresh transaction, it must send an offerless UPDATE or re-INVITE, as if it sends an offer, the remote element has the opportunity to provide an answer that is different from its previous SDP, which could not easily be conveyed to the other remote element.)
执行UA可能会发现远程UA或MOH源希望使用对话/会话活跃度计时器[RFC4028]。由于计时器验证对话的活跃性，而不是会话（尽管有[RFC4028]的术语），执行UA可以独立地支持每个对话上的计时器（到远程UA和到MOH源）。（如果执行UA有义务发起刷新事务，它必须发送无报价更新或重新邀请，就像它发送报价一样，远程元素有机会提供不同于其先前SDP的答案，该答案不容易传递给其他远程元素。）
The directionality of the media stream in the SDP offer in an INVITE or re-INVITE to the music source can be "inactive" if the SDP offer from the remote UA was "sendonly" or "inactive". Generally, this happens when the remote UA also has put the call on hold and provided a directionality of "sendonly". In this situation, the executing UA can omit establishing the dialog with the music source (or can terminate the existing dialog with the music source).
如果来自远程UA的SDP提供为“sendonly”或“inactive”，则在对音乐源的邀请或重新邀请中，SDP提供中的媒体流的方向性可以是“inactive”。通常，当远程UA也将呼叫挂起并提供方向性“sendonly”时，会发生这种情况。在这种情况下，执行UA可以省略与音乐源建立对话（或者可以终止与音乐源的现有对话）。
If the executing UA uses this optimization, it creates the SDP answer itself, with directionality "inactive" and using its own RTP/RTCP ports, and returns that answer to the remote UA.
如果执行UA使用此优化，它将创建SDP应答本身，方向性为“非活动”，并使用自己的RTP/RTCP端口，然后将该应答返回给远程UA。
The executing UA must be prepared for the remote UA to send a re-INVITE with directionality "active" or "recvonly", in which case the executing UA must initiate a dialog with the music source, as described above.
执行UA必须准备好让远程UA发送方向性为“active”或“recvonly”的重新邀请，在这种情况下，执行UA必须发起与音乐源的对话，如上所述。
There may be multiple media streams (multiple "m=" lines) in any of the SDPs involved in the dialogs. As the SDPs are manipulated, each media description (each starting with an "m=" line) is manipulated as described above for a single media stream, largely independently of the manipulation of the other media streams. But there are some
对话框中涉及的任何SDP中可能有多个媒体流（多个“m=”行）。当操作sdp时，每个媒体描述（每个描述以“m=”行开始）如上所述针对单个媒体流进行操作，基本上独立于其他媒体流的操作。但也有一些
elaborations that the executing UA may implement to achieve specific effects.
执行UA为实现特定效果而可能实施的详细说明。
If the executing UA desires to present only certain media types as on-hold media, when passing the offer SDP through, it can reject any particular media streams by setting the port number in the "m=" line to zero [RFC3264]. This ensures that the answer SDP will also have a rejection for that "m=" line.
如果执行UA希望仅将某些媒体类型显示为保留媒体，则在通过要约SDP时，它可以通过将“m=”行中的端口号设置为零[RFC3264]来拒绝任何特定媒体流。这将确保应答SDP也会拒绝该“m=”行。
If the executing UA wishes to provide its own on-hold media for a particular "m=" line, it can do so by providing the answer information for that "m=" line. The executing UA may decide to do this when the offer SDP is received (by modifying the "m=" line to rejected state when sending it to the music source) or upon receiving the answer from the music source and discovering that the "m=" line has been rejected.
如果执行UA希望为特定“m=”行提供其自己的保留媒体，则可以通过提供该“m=”行的应答信息来实现。执行UA可在接收到要约SDP时（通过将“m=”行发送到音乐源时将其修改为拒绝状态）或在接收到来自音乐源的应答并发现“m=”行已被拒绝时，决定这样做。
The executing UA may not want to pass a rejected "m=" line from the music source to the remote UA (when the remote UA provided a non-rejected "m=" line) and may instead provide an answer with directionality "inactive" (and specifying its own RTP/RTCP ports).
执行UA可能不希望将被拒绝的“m=”行从音乐源传递到远程UA（当远程UA提供了未被拒绝的“m=”行时），而是可以提供方向性为“非活动”的应答（并指定其自己的RTP/RTCP端口）。
This technique for providing music on hold has advantages over other methods now in use, including:
与目前正在使用的其他方法相比，这种提供暂挂音乐的技术具有优势，包括：
1. The original dialog is not transferred to another UA, so the "remote endpoint URI" displayed by the remote endpoint's user interface and dialog event package [RFC4235] does not change during the call, as contrasted to the method in [RFC5359], Section 2.3. This URI is usually displayed to the user as the name and number of the other party on the call, and it is desirable for it not to change to that of the MOH server.
1. 原始对话框不会传输到另一个UA，因此远程端点的用户界面和对话框事件包[RFC4235]显示的“远程端点URI”在调用期间不会改变，与[RFC5359]第2.3节中的方法不同。该URI通常显示给用户作为通话中另一方的名称和号码，并且希望它不会更改为MOH服务器的名称和号码。
2. Compared to [RFC5359], this method does not require use of an out-of-dialog REFER, which is not otherwise used much in SIP. Out-of-dialog REFERs may not be routed correctly, since neither the From nor Contact URI of the original dialog may route correctly to the remote UA. Also, out-of-dialog requests to UA URIs may not be handled correctly by authorization mechanisms.
2. 与[RFC5359]相比，此方法不需要使用对话框外引用，否则在SIP中使用不多。由于原始对话框的“发件人”或“联系人”URI都无法正确路由到远程UA，因此“对话外”引用可能无法正确路由。此外，授权机制可能无法正确处理对UA URI的对话外请求。
3. The music-on-hold media are sent directly from the music-on-hold source to the remote UA, rather than being relayed through the executing UA. This reduces the computational load on the executing UA and can reduce the load on the network (by eliminating "hairpinning" of the media through the link serving the executing UA).
3. 音乐保留媒体直接从音乐保留源发送到远程UA，而不是通过执行UA中继。这减少了执行UA上的计算负载，并且可以减少网络上的负载（通过消除通过服务于执行UA的链路的媒体的“发夹”）。
4. The remote UA sees, in the incoming SDP, the address/port that the MOH source will send MOH media from (assuming that the MOH source follows the convention of sending its media from its advertised media-listening address/port). Thus, the remote UA will render the MOH media even if it is filtering incoming media based on originating address as a media security measure.
4. 远程UA在传入SDP中看到MOH源将从中发送MOH媒体的地址/端口（假设MOH源遵循从其播发的媒体侦听地址/端口发送其媒体的约定）。因此，远程UA将呈现MOH介质，即使它根据原始地址过滤传入介质作为介质安全措施。
5. The technique requires relatively simple manipulation of SDP; in particular, (1) it does not require a SIP element to modify unrelated SDP to be acceptable to be sent within an already established sequence of SDP (a problem with [SIP-SERV-EX], Section 2.3), and (2) it does not require converting an SDP answer into an SDP offer (which was a problem with the initial draft version of this document, as well as with [SIP-SERV-EX]).
5. 该技术需要相对简单的SDP操作；具体而言，（1）不要求SIP元素修改不相关的SDP，使其能够在已经建立的SDP序列内发送（SIP-SERV-EX的问题，第2.3节），并且（2）不要求将SDP应答转换为SDP要约（这是本文件初稿以及[SIP-SERV-EX]的一个问题）。
Unnecessary failures can happen if SDP offerers do not always offer all media formats that they support. Doing so is considered best practice ([RFC6337], Sections 5.1 and 5.3), but some SIP elements offer only formats that have already been in use in the dialog.
如果SDP提供商不总是提供其支持的所有媒体格式，则可能会发生不必要的故障。这样做被认为是最佳实践（[RFC6337]，第5.1和5.3节），但一些SIP元素只提供对话框中已经使用过的格式。
An example of how omitting media formats in an offer can lead to failure is as follows. Suppose that the UAs in Section 2.3 each support the following media formats:
在报价中省略媒体格式会导致失败的示例如下。假设第2.3节中的UAs都支持以下媒体格式：
Alice supports formats X and Y.
Alice支持X和Y格式。
Bob supports formats X and Z.
Bob支持格式X和Z。
Music Source supports formats Y and Z.
音乐源支持Y和Z格式。
In this case, the SDP exchanges are:
在这种情况下，SDP交换是：
1. Alice calls Bob: Alice offers X and Y (message F1). Bob answers X (F3).
1. Alice给Bob打电话：Alice提供X和Y（消息F1）。鲍勃回答X（F3）。
2. Bob puts Alice on hold: Alice (via Bob) offers X and Y (F6 and F7). Music Source (via Bob) answers Y (F8 and F10).
2. Bob暂停Alice：Alice（通过Bob）提供X和Y（F6和F7）。音乐源（通过Bob）回答Y（F8和F10）。
3. Bob takes Alice off hold: Bob offers X and Z (F11). Alice answers X (F12).
3. Bob让Alice停止等待：Bob提供X和Z（F11）。爱丽丝回答X（F12）。
Note that in exchange 2, if Alice assumes that because only format X is currently in use that she should offer only X, the exchange fails. In exchange 3, Bob offers formats X and Z, even though neither is in use at the time (because Bob is not involved in the media streams).
注意，在Exchange2中，如果Alice认为由于当前只使用格式X，所以她应该只提供X，则交换失败。在exchange 3中，Bob提供了格式X和Z，尽管当时两者都没有使用（因为Bob不参与媒体流）。
Many UAs provide MOH in the interval during which it is processing a blind transfer, between receiving the REFER and receiving the final response to the stimulated INVITE. This process involves switching the user's interface between three media sources: (1) the session of the original dialog, (2) the session with the MOH server, and (3) the session of the new dialog. It also involves a number of race conditions that must be handled correctly. If the UA is a back-to-back user agent (B2BUA) whose "other side" is maintaining a single dialog with another UA, each switching of media sources potentially causes a re-INVITE transaction within the other-side dialog. Since re-INVITEs take time and must be sequenced correctly ([RFC3261], Section 14), such a B2BUA must allow the events on each side to be non-synchronous and must coordinate them correctly. Failing to do so will lead to "glare" errors (491 or 500), leaving the other-side UA not rendering the correct session.
许多UAs在接收REFER和接收受激INVITE的最终响应之间处理盲传输的时间间隔内提供MOH。此过程涉及在三个媒体源之间切换用户界面：（1）原始对话框的会话，（2）与MOH服务器的会话，以及（3）新对话框的会话。它还涉及一些必须正确处理的比赛条件。如果UA是一个背对背的用户代理（B2BUA），其“另一方”正在与另一UA保持一个对话，则媒体源的每次切换都可能导致另一方对话中的重新邀请事务。由于重新邀请需要时间，并且必须正确排序（[RFC3261]，第14节），这样的B2BUA必须允许每侧的事件是非同步的，并且必须正确地协调它们。否则将导致“眩光”错误（491或500），导致另一方UA无法呈现正确的会话。
Some mechanism outside the scope of this document must inform the executing UA of the MOH server that it should use. Care must be exercised in selecting the MOH server, because signaling information that is part of the original dialog will be transmitted along the path from the executing UA to the server. If the path between the executing UA and the server is not entirely contained within every network domain that contains the executing UA, the signaling between the UA and the server may be protected by different network security than is applied to the original dialog.
本文件范围之外的某些机制必须通知MOH服务器的执行UA，以便其使用。在选择MOH服务器时必须小心，因为作为原始对话框一部分的信令信息将沿着从执行UA到服务器的路径传输。如果执行UA和服务器之间的路径不完全包含在包含执行UA的每个网络域中，则UA和服务器之间的信令可以通过不同于应用于原始对话框的网络安全性来保护。
Care must also be exercised because media information that is part of the original dialog will be transmitted along the path between the remote UA and the server. If the path between the remote UA and the server does not pass through the same network domains as the path between the remote UA and the executing UA, the media between the UA and the server may be protected by different network security than is applied to the original dialog.
还必须小心，因为作为原始对话框一部分的媒体信息将沿着远程UA和服务器之间的路径传输。如果远程UA和服务器之间的路径没有通过与远程UA和执行UA之间的路径相同的网络域，则UA和服务器之间的媒体可能受到不同于应用于原始对话框的网络安全性的保护。
These requirements may be satisfied by selecting an MOH server that is in the same administrative and network domain as the executing UA and whose path to all external addresses is the same as the UA's path to those addresses.
可通过选择与执行UA位于同一管理和网络域中且其到所有外部地址的路径与UA到这些地址的路径相同的MOH服务器来满足这些要求。
The executing UA and the MOH server will usually be within the same administrative domain, and the SIP signaling path between them will lie entirely within that domain. In this case, the administrator of the domain should configure the UA and server to apply to the dialog between them a level of security that is appropriate for the administrative domain.
执行UA和MOH服务器通常位于同一管理域内，它们之间的SIP信令路径将完全位于该域内。在这种情况下，域的管理员应配置UA和服务器，以便将适用于管理域的安全级别应用于它们之间的对话框。
If the executing UA and the MOH server are not within the same administrative domain, the SIP signaling between them should be at least as secure as the SIP signaling between the executing UA and the remote UA. Thus, the MOH server should support all of the SIP security facilities that are supported by the executing UA, and the executing UA should use in its dialog with the MOH server all SIP security facilities that are used in its dialog with the remote UA.
如果执行UA和MOH服务器不在同一管理域内，则它们之间的SIP信令应至少与执行UA和远程UA之间的SIP信令一样安全。因此，MOH服务器应支持执行UA支持的所有SIP安全设施，并且执行UA应在其与MOH服务器的对话中使用其与远程UA的对话中使用的所有SIP安全设施。
The RTP for the MOH media will pass directly between the MOH server and the remote UA and thus may pass outside the administrative domain of the executing UA. While it is uncommon for the contents of the MOH media to be sensitive (and the remote UA will not usually be generating RTP when it is on hold), the MOH RTP should be at least as secure as the RTP between the executing UA and the remote UA. In order to make this possible, the MOH server should support all of the RTP security facilities that are supported by the executing UA.
MOH介质的RTP将直接在MOH服务器和远程UA之间传递，因此可能会在执行UA的管理域之外传递。虽然MOH媒体的内容不太敏感（远程UA在保持状态时通常不会生成RTP），但MOH RTP至少应与执行UA和远程UA之间的RTP一样安全。为了实现这一点，MOH服务器应支持执行UA支持的所有RTP安全设施。
It is possible that the remote UA and the MOH server support an RTP security facility that the executing UA does not support and that it is desirable to use this facility for the MOH RTP. To enable doing so, the executing UA should pass the SDP between the remote UA and the MOH server completely, not omitting elements that it does not understand.
远程UA和MOH服务器可能支持执行UA不支持的RTP安全设施，并且希望将该设施用于MOH RTP。为了实现这一点，执行UA应该在远程UA和MOH服务器之间完全传递SDP，而不忽略它不理解的元素。
Some UAs filter incoming RTP based on the address of origin as a media security measure, refusing to render the contents of RTP packets that originate from an address that is not shown in the remote SDP as an RTP destination address. The remote UA in the original dialog may use this form of media filtering, and if the executing UA does not update the SDP to inform the remote UA of the
一些UAs基于源地址过滤传入RTP作为媒体安全措施，拒绝将源于远程SDP中未显示为RTP目标地址的地址的RTP数据包的内容呈现为RTP目标地址。原始对话框中的远程UA可以使用这种形式的媒体过滤，并且如果执行UA不更新SDP以通知远程UA该消息
source address of the MOH media, the remote UA may not render the MOH media. Note that the executing UA has no means for detecting that the remote UA uses media filtering, so the executing UA must assume that any remote UA uses media filtering.
MOH介质的源地址，远程UA可能不会呈现MOH介质。注意，执行UA没有检测远程UA使用媒体过滤的手段，因此执行UA必须假设任何远程UA使用媒体过滤。
The technique described in this document ensures that any UA that should render MOH media will be informed of the source address of the media via the SDP that it receives. This allows such UAs to filter media without interfering with MOH operation.
本文件中描述的技术可确保任何应提供MOH介质的UA将通过其接收的SDP被告知介质的源地址。这允许此类UAs在不干扰MOH操作的情况下过滤介质。
The original version of this proposal was derived from Section 2.3 of [SIP-SERV-EX] and the similar implementation of MOH in the snom UA. Significant improvements to the sequence of operations, allowing improvements to the SDP handling, were suggested by Venkatesh [VENKATESH].
本提案的原始版本源自[SIP-SERV-EX]第2.3节以及snom UA中MOH的类似实施。Venkatesh[Venkatesh]建议对操作顺序进行重大改进，从而改进SDP处理。
John Elwell [ELWELL] pointed out the need for the executing UA to pass through re-INVITEs/UPDATEs in order to allow ICE negotiation, suggested mentioning the role of RTCP listening ports, suggested the possibility of omitting the dialog to the music source if the directionality would be "inactive", and pointed out that if there are multiple media streams, the executing UA may want to select which streams receive MOH.
John Elwell[Elwell]指出，执行UA需要通过重新邀请/更新，以允许ICE协商，建议提及RTCP监听端口的作用，建议如果方向性为“非活动”，则可以省略与音乐源的对话，并且指出，如果存在多个媒体流，则执行UA可能想要选择哪些流接收MOH。
Paul Kyzivat [KYZIVAT-1] [KYZIVAT-2] pointed out the difficulties regarding reuse of payload type numbers and considerations that could be used to avoid those difficulties, leading to the writing of Section 2.8.
Paul Kyzivat[Kyzivat-1][Kyzivat-2]指出了重复使用有效负载类型编号的困难，以及可用于避免这些困难的注意事项，从而编写了第2.8节。
Paul Kyzivat suggested adding Section 4.1 showing why offerers should always include all supported formats.
Paul Kyzivat建议添加第4.1节，说明为什么报价人应始终包括所有支持的格式。
M. Ranganathan pointed out the difficulties experienced by a B2BUA (Section 4.2) due to the multiple changes of media source.
M.Ranganathan指出了B2BUA（第4.2节）由于媒体来源的多重变化而遇到的困难。
Section 4.1 was significantly clarified based on advice from Attila Sipos [SIPOS].
第4.1节根据Attila Sipos【Sipos】的建议进行了重大澄清。
The need to discuss dialog/session timers (Section 2.9) was pointed out by Rifaat Shekh-Yusef [SHEKH-YUSEF].
Rifaat Shekh-Yusef[Shekh-Yusef]指出需要讨论对话/会话计时器（第2.9节）。
Robert Sparks clarified the purpose of the "Best Current Practice" status, leading to revising the intended status of this document to "Informational".
Robert Sparks阐明了“当前最佳实践”状态的目的，从而将本文件的预期状态修改为“信息性”。
In his SecDir review, Stephen Kent pointed out that the Security Considerations should discuss the use of SIP and SDP security features by the MOH server.
斯蒂芬·肯特（Stephen Kent）在他的SecDir评论中指出，安全考虑因素应讨论卫生部服务器使用SIP和SDP安全功能的问题。
Numerous improvements to the text were due to reviewers, including Rifaat Shekh-Yusef and Richard Barnes.
对文本的许多改进都归功于评论家，包括里法特·谢赫·尤塞夫和理查德·巴恩斯。
[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月。
[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月。
[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月。
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4028]Donovan，S.和J.Rosenberg，“会话启动协议（SIP）中的会话计时器”，RFC4028，2005年4月。
[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月。
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC4235]Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 4235，2005年11月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]Wing，D，“对称RTP/RTP控制协议（RTCP）”，BCP 131，RFC 49612007年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359]Johnston，A.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，2008年10月。
[RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session Initiation Protocol (SIP) Usage of the Offer/Answer Model", RFC 6337, August 2011.
[RFC6337]Okumura，S.，Sawada，T.，和P.Kyzivat，“提供/应答模型的会话启动协议（SIP）使用”，RFC 6337，2011年8月。
[ELWELL] Elwell, J., "Subject: [Sipping] RE: I-D Action:draft-worley-service-example-00.txt", message to the IETF Sipping mailing list, November 2007, <http://www1.ietf.org/mail-archive/web/sipping/current/msg14678.html>.
[ELWELL]ELWELL，J.，“主题：[啜饮]RE:I-D行动：draft-worley-service-example-00.txt”，给IETF啜饮邮件列表的信息，2007年11月<http://www1.ietf.org/mail-archive/web/sipping/current/msg14678.html>.
[KYZIVAT-1] Kyzivat, P., "Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-11.txt", message to the IETF Sipping mailing list, October 2006, <http://www1.ietf.org/ mail-archive/web/sipping/current/msg12181.html>.
[KYZIVAT-1]KYZIVAT，P.，“主题：Re:[啜饮]I-D行动：draft-ietf-啜饮-service-examples-11.txt”，致ietf啜饮邮件列表的信息，2006年10月<http://www1.ietf.org/ 邮件存档/web/sipping/current/msg12181.html>。
[KYZIVAT-2] Kyzivat, P., "Subject: [Sip-implementors] draft-worley-service-example-02", message to the sip-implementors mailing list, September 2008, <http://lists.cs.columbia.edu/pipermail/sip-implementors/ 2008-September/020394.html>.
[KYZIVAT-2]KYZIVAT，P.，“主题：[Sip实施者]草稿-worley-service-example-02”，致Sip实施者邮件列表的信息，2008年9月<http://lists.cs.columbia.edu/pipermail/sip-implementors/ 2008年9月/020394.html>。
[SHEKH-YUSEF] Shekh-Yusef, R., "Subject: [sipcore] draft-worley-service-example-03", message to the IETF Sipcore mailing list, July 2009, <http://www.ietf.org/mail-archive/web/sipcore/ current/msg00580.html>.
[SHEKH-YUSEF]SHEKH-YUSEF，R.，“主题：[sipcore]draft-worley-service-example-03”，发送给IETF sipcore邮件列表的信息，2009年7月<http://www.ietf.org/mail-archive/web/sipcore/ 当前/msg00580.html>。
[SIPOS] Sipos, A., "Subject: [Sip-implementors] draft-worley-service-example-02", message to the sip-implementors mailing list, March 2009, <http://lists.cs.columbia.edu/ pipermail/sip-implementors/2009-March/021970.html>.
[SIPOS]SIPOS，A.，“主题：[Sip实施者]草稿-worley-service-example-02”，致Sip实施者邮件列表的信息，2009年3月<http://lists.cs.columbia.edu/ pipermail/sip implementors/2009年3月/021970.html>。
[SIP-SERV-EX] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", Work in Progress, October 2006.
[SIP-SERV-EX]Johnston，A.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，正在进行的工作，2006年10月。
[VENKATESH] Venkatesh, "Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-service-examples-11.txt", message to the IETF Sipping mailing list, October 2006, <http://www1.ietf.org/ mail-archive/web/sipping/current/msg12180.html>.
[VENKATESH]VENKATESH，“主题：Re:[啜饮]I-D行动：draft-ietf-啜饮服务-examples-11.txt”，致ietf啜饮邮件列表的信息，2006年10月<http://www1.ietf.org/ 邮件存档/web/sipping/current/msg12180.html>。
Author's Address
作者地址
Dale R. Worley Ariadne Internet Services, Inc. 738 Main St. Waltham, MA 02451 US
Dale R.Worley Ariadne互联网服务有限公司，地址：美国马萨诸塞州圣沃尔瑟姆大街738号，邮编：02451
Phone: +1 781 647 9199
EMail: worley@ariadne.com
Phone: +1 781 647 9199
EMail: worley@ariadne.com