[要約] RFC 7088は、音楽を保留中に提供するためのセッション開始プロトコル（SIP）サービスの例を提供しています。このRFCの目的は、SIPベースの音楽保留サービスの実装と相互運用性を向上させることです。
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.
「保留音」は、ビジネス電話システムの購入者が最も望んでいる電話システムの機能の1つです。保留音とは、通話の一方の通話に「保留中」の通話がある場合、その通話者の電話が、もう一方の通話者に聞こえるオーディオストリーム（多くの場合、音楽）を提供することを意味します。 SIPのアーキテクチャ上の特徴により、完全に標準に準拠した方法で保留音を実装することは困難です。このドキュメントで説明する保留音の実装は完全に効果的であり、標準に準拠しており、以前に文書化された方法よりも多くの利点があります。特に、RFC 5359のセクション2.3で説明されている保留音の方法よりも、特異なユーザーインターフェース効果を生み出す可能性が低く、認証を実行するシステムで機能する可能性が高くなります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
保留音を実装する現在のすべての方法は相互に相互運用します。つまり、コール内の2つのユーザーエージェントは、どちらかの方法が両方のユーザーエージェントによって使用されたかのように、同じ機能で保留音を実装するために異なる方法を使用できます。したがって、電話システム内のさまざまなユーザーエージェントがさまざまな保留音方法を使用した場合、または単一のユーザーエージェントがさまざまな通話内または1つの通話内のさまざまな時間にさまざまな方法を使用した場合でも、機能は失われません。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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）のre-INVITEを実行してホールド状態を確立するときに、セッション記述プロトコル（SDP）を提供しないことです。 [RFC4566]オファー[RFC3264] [RFC6337]により、リモートUAがSDPオファーを提供するように強制されます。次に、実行中のUAはリモートUAの2xx応答からオファーSDPを抽出し、それを外部メディアソースへの新しいINVITEのオファーSDPとして使用します。したがって、外部メディアソースは、リモートUAに直接メディアを提供するように指示されます。メディアソースの応答SDPは、re-INVITEへのACKでリモート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は、SDPなしのre-INVITEをリモートUAに送信します。これにより、リモートUAは2xx応答でSDPオファーを提供します。 re-INVITEの連絡先ヘッダーには、通話を保留にしていることを示す「+ 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は2xxをre-INVITEに送信し、独自のリスニングアドレス/ポートを提供するSDPオファーを含みます。リモートUAがsip.rendering機能パラメーターを理解している場合、オファーは、メディアの方向性を「recvonly」（「保留中」の逆）または「非アクティブ」として指定することにより、メディアを送信しないことを示す場合があります。しかし、リモート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はこのオファーを使用して、設定された保留音（MOH）ソースに送信する最初のINVITEのオファーSDPを導出します。このリクエストのSDPは、特に提供されたリスニングアドレス/ポートとペイロードタイプ番号に関して、前のステップでリモートUAによって返されたSDPから主にコピーされます。ただし、メディアの方向性は、必要に応じて「recvonly」または「inactive」に制限されます。実行中のUAは、「o =」行を変更する必要がある場合があります。さらに、RTPペイロードタイプ番号の割り当てを制御するために、「a = rtpmap」行を追加する必要がある場合があります（セクション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ソースは2xx応答をINVITEに送信します。これには、メディアソースアドレスをリスニングアドレス/ポートとして含める必要がある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.
慣例により、UAは宣言されたRTPリスニングポートをRTP送信元ポートとしても使用します[RFC4961]。応答SDPはリモートUAに到達するため、MOHメディアの送信元のアドレス/ポートを通知し、リモートUAが送信元アドレスに基づいてメディアパケットをフィルタリングする場合、リモートUAがMOHメディアを無視することを防止します。この機能では、MOHソースがRTPを受信していなくても、SDP応答に「c =」行に送信アドレスを含める必要があります。
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回答をre-INVITEのACK内のSDP回答としてリモート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. re-INVITEのContactヘッダーのsip.rendering機能パラメーターと、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は2つのダイアログ（1つはリモートUA、もう1つは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にre-INVITEを送信します。 re-INVITEのContactヘッダーには、「+ sip.rendering = "no"」フィールドパラメータが含まれていません。 （値が「yes」または「unknown」のsip.renderingフィールドパラメーターが含まれる場合があります。または、フィールドパラメーターが省略される場合があります。）したがって、このre-INVITEは、ダイアログの保留状態を（実行側で）削除します。 。 （提供された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がre-INVITEに2xx応答を送信すると、実行中のUAはダイアログでBYE要求をMOHソースに送信します。
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 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がリモートUAです。これは、この手法を説明するメッセージフローの1つにすぎないことに注意してください。これらの操作の多くのバリエーションは、該当する規格で許可されています。
Alice Bob Music Source
Alice Bob音楽ソース
Alice establishes the call:
アリスはコールを確立します：
| | |
| INVITE F1 | |
|--------------->| |
| 180 Ringing F2 | |
|<---------------| |
| 200 OK F3 | |
|<---------------| |
| ACK F4 | |
|--------------->| |
| RTP | |
|<==============>| |
| | |
Bob places Alice on hold, compelling Alice's UA to provide SDP:
ボブはアリスを保留にし、アリスのUAにSDPの提供を強制します。
| | |
| INVITE F5 | |
| (no SDP) | |
|<---------------| |
| 200 OK F6 | |
| (SDP offer) | |
|--------------->| |
| | |
Bob's UA initiates music on hold:
BobのUAが保留音を開始します。
| | |
| | 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:
ボブのUAは、ミュージックソースのアドレス/ポートを含むSDP回答を提供します。
| | |
| 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 | |
|<==============>| |
| | |
The normal media session between Alice and Bob is resumed.
アリスとボブの間の通常のメディアセッションが再開されます。
/* Alice calls Bob. */
F1 INVITE Alice -> Bob
F1 INVITEアリス->ボブ
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
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
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]
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アリス->ボブ
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. */
/* The re-INVITE contains no SDP, thus compelling Alice's UA
to provide an offer. */
F5 INVITE Bob -> Alice
F5 INVITEボブ->アリス
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. */
F6 200 OK Alice -> Bob
F6 200 OKアリス->ボブ
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
/* Bob's UA initiates music on hold. */
/* This INVITE contains Alice's offer, but with the media
direction set to "reverse hold", receive-only. */
F7 INVITE Bob -> Music Source
F7 INVITE 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]
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
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
F9 ACK Bob -> Music Source
F9 ACKボブ->音楽ソース
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. */
F10 ACK Bob -> Alice
F10 ACKボブ->アリス
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
/* Bob picks up the call by sending a re-INVITE to Alice. */
F11 INVITE Bob -> Alice
F11 INVITEボブ->アリス
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
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]
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ボブ->アリス
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
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
/* 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またはそのContactヘッダーの機能パラメーターを変更する要求を送信できます。これは、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.
re-INVITEの一般的な理由は、リモートUAがダイアログを保留にすることを望んでいる場合です。また、このケースをサポートする必要があるため、実装は、以下に説明するように、保留状態の間にINVITEとUPDATEを処理する必要があります。
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 =」行を変更する必要があります。実行中のUAはリモートUAからメディアをレンダリングしないため、「active」を「recvonly」に、「sendonly」を「inactive」に変更することにより、方向性属性を制限する必要がある場合があります。 （すべてのパススルー方向性属性が「非アクティブ」の場合、セクション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は、リモートUAとのダイアログを指定するReplacesヘッダーを含むINVITE要求を受信できるように準備する必要があります。実行中のUAがこの新しいダイアログを保留状態で作成する場合、MOHソースを使用してMOHを取得する新しいダイアログを作成します。実行中のUAは、INVITEがReplacesで作成したダイアログ内でSDPをネゴシエートし、オファーを新しいMOHダイアログに渡す（INVITEにオファーが含まれている場合）、またはオファーのないINVITEを使用して新しいMOHダイアログを作成する（INVITEが含まれていない場合）オファーが含まれています）。
Continuing the example of Section 2.3, the executing UA receives an INVITE with Replaces that contains an offer:
セクション2.3の例を続けると、実行中のUAは、オファーを含むReplacesを含むINVITEを受け取ります。
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.)
（たとえば、アリスはキャロルを呼び出し、キャロルにREFERを送信することで有人転送を開始し、キャロルがボブに置換付きのINVITEを送信するようにします。）
Bob receives INVITE with Replaces from Carol:
Bobは、CarolからReplacesを含むINVITEを受け取ります。
| | | |
| | | 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:
ボブは前のダイアログをアリスで終了します：
| | | |
| BYE | | |
| From: Bob | | |
| To: Alice | | |
|<---------------| | |
| 200 OK | | |
| From: Bob | | |
| To: Alice | | |
|--------------->| | |
| | | |
Bob terminates the MOH dialog for the dialog with Alice:
ボブはアリスとのダイアログのMOHダイアログを終了します。
| | | |
| | 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は、オファーを取得するためにオファーのないINVITE（またはオファーのないre-INVITE）をMOHソースに送信し、INVITEでそのオファーを参照ターゲットに使用することによってネゴシエートされます。
Similar processing is used for an out-of-dialog REFER whose Target-Dialog header refers to the dialog with the remote UA.
同様の処理は、Target-DialogヘッダーがリモートUAとのダイアログを参照するダイアログ外のREFERにも使用されます。
Continuing the example of Section 2.3, the executing UA receives an INVITE with Replaces that contains an offer: Alice Bob Music Source Carol
セクション2.3の例を続けると、実行中のUAは、オファーを含むReplacesを含むINVITEを受け取ります。AliceBob Music Source Carol
(For example, Alice initiates an unattended transfer of the call to Carol by sending a REFER to Bob.)
（たとえば、アリスはボファーにREFERを送信することにより、キャロルへの無人転送を開始します。）
Bob receives REFER from Alice:
ボブはアリスからREFERを受け取ります。
| | | |
| 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
| | |================>|
| | | |
Bob terminates the previous dialog with 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ソースがre-INVITEまたはUPDATE要求を送信することは可能であり、実行中のUAは、リモートUAからの要求と同様の方法でそうすることをサポートできます。ただし、MOHソースが実行中のUAと同じ管理ドメイン内にある場合、実行中のUAは、MOHソースがそのような要求を行わない（または必要としない）ことを知っている可能性があるため、そのような要求に失敗応答で応答できます。リクエストを通過させる必要性を回避します。 403（Forbidden）応答はこの目的に適しています。[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.
ただし、Interactive Connectivity Establishment（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ソースは、実行中のUAが元のダイアログ内の回答としてリモートUAに提示するSDP回答を生成します。 [RFC3264]のセクション6.1（最後）は、RTPのいずれかの方向で使用されるペイロードタイプ番号が、RTPの受信者によって送信されるSDPで指定されたものであることを指定しているため、基本機能ではこれは問題になりません。したがって、MOHソースは、リモートUAから（最終的に）受信したオファーSDPで指定されたペイロードタイプ番号を使用して、RTPをリモートUAに送信します。
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のSHOULDレベルの要件を利用することで、ペイロードタイプルールに厳密に準拠する手法を構築できます。「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がINVITEを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によって以前に別のメディアフォーマットに使用されていた場合、ダミーメディアフォーマットを記述するように書き換えられます。 （複数のペイロードタイプ番号が同じメディアフォーマットを参照する可能性があるため、1つのダミーメディアフォーマット名を多くのペイロードタイプ番号に使用できます。）ペイロードタイプ番号は、削除されたメディアフォーマットを説明するために追加されます。そのメディアフォーマットの実行中の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からのre-INVITEは、MOHサーバーが過去のオファーで受信するペイロードタイプ番号がその使用に対して完全に予約されているわけではないため（送信されていないため）、同様の変更が必要です。 MOHサーバーによるSDPの場合）、現在の回答でそれらを使用することに対するSHOULDレベルの禁止もありません（現在のオファーには表示されないため）。
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.
アリスはフォーマットXとYをサポートしています。
Bob supports formats X and Z.
ボブはフォーマットXおよびZをサポートしています。
Music Source supports formats Y and Z.
Music Sourceはフォーマット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 INVITEアリス->ボブ
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
F3 200 OK Bob -> Alice
F3 200 OKボブ->アリス
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
F6 200 OK Alice -> Bob
F6 200 OKアリス->ボブ
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
F7 INVITE Bob -> Music Source
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
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]
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とは異なる回答を提供する機会を持っているため、オファーなしのUPDATEまたはre-INVITEを送信する必要があります。他のリモート要素に簡単に伝達できませんでした。）
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オファーが「送信専用」または「非アクティブ」の場合、音楽ソースへのINVITEまたはre-INVITEでのSDPオファーのメディアストリームの方向性は「非アクティブ」になる可能性があります。通常、これは、リモート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がこの最適化を使用する場合、方向性が「非アクティブ」で独自のRTP / RTCPポートを使用してSDP応答自体を作成し、その応答をリモート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が方向性「アクティブ」または「recvonly」でre-INVITEを送信できるように準備する必要があります。その場合、実行中の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 elaborations that the executing UA may implement to achieve specific effects.
ダイアログに関係するSDPのいずれかに複数のメディアストリーム（複数の「m =」行）が存在する場合があります。 SDPが操作されると、各メディア記述（それぞれ "m ="行で始まる）は、他のメディアストリームの操作とはほぼ無関係に、単一のメディアストリームについて上記のように操作されます。しかし、実行中の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サーバーのURIに変更しないことが望ましいです。
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であまり使用されないダイアログ外のREFERを使用する必要がありません。元のダイアログの送信元URIも連絡先URIもリモートUAに正しくルーティングされない可能性があるため、ダイアログ外のREFERは正しくルーティングされない可能性があります。また、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）無関係なSDPを変更して、既に確立されているSDPシーケンス内で送信できるようにSIP要素を変更する必要がない（[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のUAがそれぞれ次のメディアフォーマットをサポートするとします。
Alice supports formats X and Y.
アリスはフォーマットXとYをサポートしています。
Bob supports formats X and Z.
ボブはフォーマットXおよびZをサポートしています。
Music Source supports formats Y and Z.
Music Sourceはフォーマット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. アリスはボブに電話します：アリスは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. ボブはアリスを保留にします：アリス（ボブ経由）はXとY（F6とF7）を提供します。音楽ソース（ボブ経由）はY（F8およびF10）に応答します。
3. Bob takes Alice off hold: Bob offers X and Z (F11). Alice answers X (F12).
3. ボブがアリスを保留にする：ボブは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).
交換2で、フォーマットXのみが現在使用されているため、Xのみを提供する必要があるとアリスが想定した場合、交換は失敗します。交換3では、当時どちらも使用されていなくても、ボブはフォーマットXとZを提供します（ボブはメディアストリームに関与していないため）。
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.
多くのUAは、REFERを受信してから、刺激されたINVITEへの最終応答を受信するまでの間に、ブラインド転送を処理している間にMOHを提供します。このプロセスには、（1）元のダイアログのセッション、（2）MOHサーバーとのセッション、および（3）新しいダイアログのセッションの3つのメディアソース間のユーザーインターフェイスの切り替えが含まれます。また、正しく処理する必要のあるいくつかの競合状態も伴います。 UAが連続したユーザーエージェント（B2BUA）であり、その "反対側"が別のUAとの単一のダイアログを維持している場合、メディアソースの切り替えごとに、反対側のダイアログ内でre-INVITEトランザクションが発生する可能性があります。 re-INVITEには時間がかかり、正しく順序付けされる必要があるため（[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に通知する必要があります。元のダイアログの一部であるシグナリング情報は、実行中のUAからサーバーへのパスに沿って送信されるため、MOHサーバーの選択には注意が必要です。実行中の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。これを可能にするために、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 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.
一部のUAは、メディアのセキュリティ対策として発信元のアドレスに基づいて着信RTPをフィルタリングし、リモートSDPに示されていないアドレスから発信されたRTPパケットの内容をRTP宛先アドレスとしてレンダリングすることを拒否します。元のダイアログのリモートUAはこの形式のメディアフィルタリングを使用する場合があり、実行中のUAがSDPを更新してリモートUAに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を介してメディアのソースアドレスを確実に通知されます。これにより、そのようなUAは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]は、ICEネゴシエーションを許可するために、実行中のUAがre-INVITE / UPDATEを通過する必要性を指摘し、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].
ダイアログ/セッションタイマー（セクション2.9）を議論する必要性がRifaat Shekh-Yusef [SHEKH-YUSEF]によって指摘されました。
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.
SecDirのレビューで、Stephen Kentは、セキュリティに関する考慮事項で、MOHサーバーによるSIPおよびSDPセキュリティ機能の使用について議論すべきであると指摘しました。
Numerous improvements to the text were due to reviewers, including Rifaat Shekh-Yusef and Richard Barnes.
テキストの多くの改善は、Rifaat Shekh-Yusefと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、「Session Initiation Protocol（SIP）in Session Initiation Protocol（SIP）」、RFC 4028、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：Session Description Protocol」、RFC 4566、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）のINVITEで開始されるダイアログイベントパッケージ」、RFC 4235、2005年11月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]ウィング、D。、「対称RTP / RTP制御プロトコル（RTCP）」、BCP 131、RFC 4961、2007年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。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年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、「Session Initiation Protocol Service Examples」、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]奥村S.、澤田T.、およびP.キジバット、「オファー/アンサーモデルのセッション開始プロトコル（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。、「件名：[Sipping] RE：ID Action：draft-worley-service-example-00.txt」、IETF Sippingメーリングリストへのメッセージ、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：[Sipping] ID ACTION：draft-ietf-sipping-service-examples-11.txt」、IETF Sippingメーリングリストへのメッセージ、2006年10月、<http： //www1.ietf.org/ mail-archive / 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-implementors] draft-worley-service-example-02」、sip-implementorsメーリングリストへのメッセージ、2008年9月、<http：//lists.cs。 columbia.edu/pipermail/sip-implementors/ 2008-September / 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 / current / 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-implementors] draft-worley-service-example-02」、sip-implementorsメーリングリストへのメッセージ、2009年3月、<http：//lists.cs.columbia。 edu / pipermail / sip-implementors / 2009-March / 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]ジョンストン、A。、スパークス、R。、カニンガム、C。、ドノバン、S。、およびK.サマーズ、「Session Initiation Protocol Service Examples」、Work in Progress、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：[Sipping] ID ACTION：draft-ietf-sipping-service-examples-11.txt」、IETF Sippingメーリングリストへのメッセージ、2006年10月、<http：//www1.ietf .org / mail-archive / 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 Internet Services、Inc. 738 Main St. Waltham、MA 02451 US
Phone: +1 781 647 9199
EMail: worley@ariadne.com