Network Working Group G. Camarillo
Request for Comments: 3960 Ericsson
Category: Informational H. Schulzrinne
Columbia University
December 2004
Early Media and Ringing Tone Generation
in the Session Initiation Protocol (SIP)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation.
ゲートウェイモデルとアプリケーション・サーバ・モデル：この文書では、二つのモデルを使用してセッション開始プロトコル（SIP）で初期メディアを管理する方法について説明します。また、1は、音源を鳴らすためのローカルポリシーを定義する際に考慮する必要があるの入力について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Session Establishment in SIP . . . . . . . . . . . . . . . . . 3
3. The Gateway Model. . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Forking. . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Ringing Tone Generation. . . . . . . . . . . . . . . . . 5
3.3. Absence of an Early Media Indicator. . . . . . . . . . . 7
3.4. Applicability of the Gateway Model . . . . . . . . . . . 8
4. The Application Server Model . . . . . . . . . . . . . . . . . 8
4.1. In-Band Versus Out-of-Band Session Progress Information. 9
5. Alert-Info Header Field. . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user. Within a dialog, early media occurs from the moment the initial INVITE is sent until the User Agent Server (UAS) generates a final response. It may be unidirectional or bidirectional, and can be generated by the caller, the callee, or both. Typical examples of early media generated by the callee are ringing tone and announcements (e.g., queuing status). Early media generated by the caller typically consists of voice commands or dual tone multi-frequency (DTMF) tones to drive interactive voice response (IVR) systems.
アーリーメディアは、特定のセッションが呼び出され、ユーザによって受理される前に交換されるメディア（例えば、オーディオ及びビデオ）を指します。ダイアログ内では、初期メディアは、初期にはユーザエージェントサーバ（UAS）まで送信されたINVITE瞬間から発生し、最終的な応答を生成します。これは、一方向または双方向であってもよく、発呼者、被呼者、またはその両方によって発生させることができます。被呼者によって生成されたアーリーメディアの代表例としては、トーンおよびアナウンス（例えば、ステータスをキューイングし）鳴っています。発呼者により生成されたアーリーメディアは、典型的には、対話型音声応答（IVR）システムを駆動するための音声コマンドまたはデュアルトーン多重周波数（DTMF）トーンから成ります。
The basic SIP specification (RFC 3261 [1]) only supports very simple early media mechanisms. These simple mechanisms have a number of problems which relate to forking and security, and do not satisfy the requirements of most applications. This document goes beyond the mechanisms defined in RFC 3261 [1] and describes two models of early media implementations using SIP: the gateway model and the application server model.
基本SIP仕様（RFC 3261 [1]）だけの非常にシンプルな初期メディア・メカニズムをサポートしています。これらの単純なメカニズムはフォークとセキュリティに関連する多くの問題があり、ほとんどのアプリケーションの要件を満たしていません。この文書は、RFC 3261で定義されたメカニズムを超えた[1]とSIPを使用してアーリーメディア実装の二つのモデルについて説明：ゲートウェイモデルとアプリケーション・サーバ・モデルを。
Although both early media models described in this document are superior to the one specified in RFC 3261 [1], the gateway model still presents a set of issues. In particular, the gateway model does not work well with forking. Nevertheless, the gateway model is needed because some SIP entities (in particular, some gateways) cannot implement the application server model.
この文書で説明両方の初期メディアのモデルはRFC 3261で指定されたものよりも優れていますが、[1]、ゲートウェイモデルは、まだ問題のセットを提示します。具体的には、ゲートウェイモデルはフォークでうまく動作しません。 （具体的には、いくつかのゲートウェイ）いくつかのSIPエンティティは、アプリケーション・サーバー・モデルを実装することはできませんので、それにもかかわらず、ゲートウェイモデルが必要とされています。
The application server model addresses some of the issues present in the gateway model. This model uses the early-session disposition type, which is specified in [2].
アプリケーション・サーバ・モデルは、ゲートウェイモデルに存在する問題の一部に対処しています。このモデルは、[2]で指定されたアーリーセッション気質タイプを使用します。
The remainder of this document is organized as follows: Section 2 describes the offer/answer model in the absence of early media, and Section 3 introduces the gateway model. In this model, the early media session is established using the early dialog established by the original INVITE. Sections 3.1, 3.2, and 3.4 describe the limitations of the gateway model and the scenarios where it is appropriate to use this model. Section 4 introduces the application server model, which, as stated previously, resolves some of the issues present in the gateway model. Section 5 discusses the interactions between the Alert-Info header field in both early media models.
このドキュメントの残りは以下の通り構成されています。第2節では、初期メディアが存在しない場合にオファー/アンサーモデルを説明し、3章では、ゲートウェイモデルを導入しています。このモデルでは、初期メディアセッションはオリジナルのINVITEによって確立された初期のダイアログを使用して確立されています。セクション3.1、3.2、3.4、ゲートウェイ・モデルの制限と、このモデルを使用することが適切であるシナリオを説明しています。セクション4は、前述のように、ゲートウェイモデルに存在する問題の一部を解決し、アプリケーション・サーバ・モデルを導入します。第5節では、両方の初期メディアモデルでAlert-Infoヘッダーフィールド間の相互作用について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [9].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT" "SHALL"、この文書では、 "SHOULD"、 "推奨" "NOTべきで"、 "MAY"、および "任意の" にあります[9]に記載のように解釈されます。
Before presenting both early media models, we will briefly summarize how session establishment works in SIP. This will let us keep separate features that are intrinsic to SIP (e.g., media being played before the 200 (OK) to avoid media clipping) from early media operations.
セッション確立はSIPでどのように機能するかを早期メディアモデルの両方を提示する前に、我々は簡単に要約します。これは、初期のメディア操作から（例えば、メディアがメディアクリッピングを避けるために200（OK）の前に再生されている）私たちは、SIPに固有の個別の機能を維持できるようになります。
SIP [1] uses the offer/answer model [3] to negotiate session parameters. One of the user agents - the offerer - prepares a session description that is called the offer. The other user agent - the answerer - responds with another session description called the answer. This two-way handshake allows both user agents to agree upon the session parameters to be used to exchange media.
SIPは、[1]〜[3]のセッションパラメータをネゴシエートするオファー/アンサーモデルを使用します。オファー側 - - ユーザエージェントの一つが提供呼ばれるセッション記述を準備します。他のユーザーエージェント - 回答は - その答えと呼ばれる別のセッション記述で応答します。この2ウェイハンドシェイクは、両方のユーザーエージェントはメディアを交換するために使用されるセッションパラメータに同意することができます。
The offer/answer model decouples the offer/answer exchange from the messages used to transport the session descriptions. For example, the offer can be sent in an INVITE request and the answer can arrive in the 200 (OK) response for that INVITE, or, alternatively, the offer can be sent in the 200 (OK) for an empty INVITE and the answer can be sent in the ACK. When reliable provisional responses [4] and UPDATE requests [5] are used, there are many more possible ways to exchange offers and answers.
オファー/アンサーモデルは、セッション記述を輸送するために使用されるメッセージからのオファー/アンサー交換を切り離します。例えば、オファーがINVITEリクエストで送信することができ、答えはそれがINVITE、または、代替的に、オファーは、空の200（OK）で送信することができるINVITEと回答200（OK）応答に到着することができACKに送信することができます。信頼性のある暫定応答[4]、[5] UPDATE要求が使用されている場合は、オファーとアンサーを交換するために、より多くの可能な方法があります。
Media clipping occurs when the user (or the machine generating media) believes that the media session is already established, but the establishment process has not finished yet. The user starts speaking (i.e., generating media) and the first few syllables or even the first few words are lost.
ユーザー（またはマシンを生成メディア）は、メディアセッションがすでに確立されていると考えていますが、確立プロセスはまだ完了していないときのメディアクリッピングが発生します。ユーザが（すなわち、メディアの生成）話しを開始し、最初のいくつかの音節あるいは最初のいくつかの単語が失われます。
When the offer/answer exchange takes place in the 200 (OK) response and in the ACK, media clipping is unavoidable. The called user starts speaking at the same time the 200 (OK) is sent, but the UAS cannot send any media until the answer from the User Agent Client (UAC) arrives in the ACK.
オファー/アンサー交換は、200（OK）応答およびACKで行われた場合、メディア・クリッピングが避けられません。呼ばれるユーザーは、同時に200（OK）で講演を開始送られますが、ユーザエージェントクライアント（UAC）からの答えがACKに到着するまで、UASは、任意のメディアを送信することはできません。
On the other hand, media clipping does not appear in the most common offer/answer exchange (an INVITE with an offer and a 200 (OK) with an answer). UACs are ready to play incoming media packets as soon as they send an offer, because they cannot count on the reception of the 200 (OK) to start playing out media for the caller; SIP signalling and media packets typically traverse different paths, and so, media packets may arrive before the 200 (OK) response.
一方、メディア・クリッピングは（答えを提供し、200（OK）でINVITE）は、最も一般的なオファー/アンサー交換には表示されません。彼らは、発信者のためのメディアの再生を開始するために200（OK）の受信に数えることができないので求めるUACは、できるだけ早く彼らは申し出を送るよう、着信メディアパケットを再生する準備が整いました。 SIPシグナリングとメディアパケットは、一般的に異なるパスを横断し、したがって、メディアパケットは、200（OK）応答の前に到着することができます。
Another form of media clipping (not related to early media either) occurs in the caller-to-callee direction. When the callee picks up and starts speaking, the UAS sends a 200 (OK) response with an answer, in parallel with the first media packets. If the first media packets arrive at the UAC before the answer and the caller starts speaking, the UAC cannot send media until the 200 (OK) response from the UAS arrives.
メディアクリップの別の形態（初期メディアに関係ないか）発信者から被呼者の方向に発生します。呼び出し先が拾って話す起動すると、UASは最初のメディアパケットと並行して、答えを持つ200（OK）応答を送信します。最初のメディアパケットが答えの前にUACに到着すると、発信者が話しを開始した場合はUASから200（OK）応答が到着するまで、UACはメディアを送信することはできません。
SIP uses the offer/answer model to negotiate session parameters (as described in Section 2). An offer/answer exchange that takes place before a final response for the INVITE is sent establishes an "early" media session. Early media sessions terminate when a final response for the INVITE is sent. If the final response is a 200 (OK), the early media session transitions to a regular media session. If the final response is a non-200 class final response, the early media session is simply terminated.
SIPは、（第2節で説明したように）セッションパラメータをネゴシエートするオファー/アンサーモデルを使用します。 INVITEのための最終応答が送信される前に行われるオファー/アンサー交換は、「早期」メディアセッションを確立します。 INVITEのための最終的な応答が送信されたときに初期メディアセッションが終了します。最終的な応答は、通常のメディアセッションに200（OK）、初期メディアセッションの移行である場合。最終応答が非200クラス最終応答である場合は、初期メディアセッションは、単純に終了します。
Not surprisingly, media exchanged within an early media session is referred to as early media. The gateway model consists of managing early media sessions using offer/answer exchanges in reliable provisional responses, PRACKs, and UPDATEs.
驚くことではないが、メディアは早くもメディアと呼ばれる初期のメディアセッション内で交換しました。ゲートウェイモデルは、信頼性の高い暫定応答、PRACKs、およびアップデートでオファー/アンサー交換を使用して、初期メディアセッションを管理で構成されています。
The gateway model is seriously limited in the presence of forking, as described in Section 3.1. Therefore, its use is only acceptable when the User Agent (UA) cannot distinguish between early and regular media, as described in Section 3.4. In any other situation (the majority of UAs), use of the application server model described in Section 4 is strongly recommended instead.
セクション3.1で説明したように、ゲートウェイモデルは真剣に、フォークの存在下で制限されています。したがって、その使用は、セクション3.4で説明したようにユーザーエージェント（UA）は、早期に通常のメディアを区別できない場合にのみ許容されます。他のどのような状況（UASの大多数）では、第4節で記述されたアプリケーション・サーバモデルの使用を強く代わりに推奨されます。
In the absence of forking, assuming that the initial INVITE contains an offer, the gateway model does not introduce media clipping. Following normal SIP procedures, the UAC is ready to play any incoming media as soon as it sends the initial offer in the INVITE. The UAS sends the answer in a reliable provisional response and can send media as soon as there is media to send. Even if the first media packets arrive at the UAC before the 1xx response, the UAC will play them.
初期の申し出が含まれているINVITEと仮定して、フォークがない場合には、ゲートウェイモデルは、メディア・クリッピングを導入しません。通常のSIPの手続に従い、UACは、INVITEで最初のオファーを送信するとすぐにすべての着信メディアを再生する準備ができています。 UASは信頼性のある暫定応答で答えを送信し、送信するためにメディアがあるとすぐにメディアを送信することができます。最初のメディアパケットがの1xx応答の前にUACに到着した場合でも、UACは、それらを再生します。
Note that, in some situations, the UAC needs to receive the answer before being able to play any media. UAs in such a situation (e.g., QoS, media authorization, or media encryption is required) use preconditions to avoid media clipping.
いくつかの状況では、UACは、任意のメディアを再生できるようになる前に、答えを受信する必要がある、ということに注意してください。このような状況でのUA（例えば、QoSの、メディアの承認、またはメディア暗号化が必要とされる）メディア・クリッピングを避けるために、前提条件を使用しています。
On the other hand, if the INVITE forks, the gateway model may introduce media clipping. This happens when the UAC receives different answers to its offer in several provisional responses from different UASs. The UAC has to deal with bandwidth limitations and early media session selection.
一方、INVITEフォーク場合、ゲートウェイモデルは、メディアクリップを導入することができます。 UACが異なるのUASからのいくつかの暫定応答でその申し出に異なる答えを受信したときに発生します。 UACは、帯域幅の制限と初期メディアセッションの選択に対処する必要があります。
If the UAC receives early media from different UASs, it needs to present it to the user. If the early media consists of audio, playing several audio streams to the user at the same time may be confusing. On the other hand, other media types (e.g., video) can be presented to the user at the same time. For example, the UAC can build a mosaic with the different inputs.
UACが異なるのUASから初期メディアを受信した場合、それはそれをユーザに提示する必要があります。初期メディアがオーディオで構成されている場合は、同時にユーザーに複数のオーディオストリームを再生すると混乱を招くことがあります。一方、他のメディアタイプ（例えば、ビデオ）が同時にユーザに提示することができます。たとえば、UACは、異なる入力でモザイクを構築することができます。
However, even with media types that can be played at the same time to the user, if the UAC has limited bandwidth, it will not be able to receive early media from all the different UASs at the same time. Therefore, many times, the UAC needs to choose a single early media session and "mute" those sending UPDATE requests.
しかし、UACは、限られた帯域幅を持っている場合、ユーザーに同時に再生できるメディアの種類と、同時に、すべて異なるのUASからの早期のメディアを受信することができません。そのため、何度も、UACは、単一の初期メディアセッションを選択する必要があり、それらの送信UPDATE要求を「ミュート」。
It is difficult to decide which early media sessions carry more important information from the caller's perspective. In fact, in some scenarios, the UA cannot even correlate media packets with their particular SIP early dialog. Therefore, UACs typically pick one early dialog randomly and mute the rest.
初期メディアセッションが呼び出し側の視点からより多くの重要な情報を伝えるかを決定することは困難です。実際には、いくつかのシナリオでは、UAも自分の特定のSIP早期ダイアログとメディアパケットを関連付けることができません。したがって、求めるUACは一般的に、ランダムに1つの初期のダイアログを選び、残りをミュート。
If one of the early media sessions that was muted transitions to a regular media session (i.e., the UAS sends a 2xx response), media clipping is likely. The UAC typically sends an UPDATE with a new offer (upon reception of the 200 (OK) for the INVITE) to unmute the media session. The UAS cannot send any media until it receives the offer from the UAC. Therefore, if the caller starts speaking before the offer from the UAC is received, his words will get lost.
通常のメディアセッションにミュートに遷移した初期メディアセッションの1つは、（すなわち、UASは2xx応答を送信）した場合、メディア・クリッピングがありそうです。 UACは、通常、メディアセッションのミュートを解除する（INVITEのための200（OKの受信時））、新たなオファーを含むUPDATEを送信します。それはUACからのオファーを受けるまで、UASは、任意のメディアを送信することはできません。呼び出し側がUACからのオファーが受信される前に話して開始した場合そのため、彼の言葉は失われます。
Having the UAS send the UPDATE to unmute the media session (instead of the UAC) does not avoid media clipping in the backward direction and it causes possible race conditions.
UASは、（代わりにUACの）メディアセッションのミュートを解除するには、UPDATEを送る持つことは、逆方向にメディアクリッピングを回避し、それが可能な競合状態が発生していません。
In the PSTN, telephone switches typically play ringing tones for the caller, indicating that the callee is being alerted. When, where, and how these ringing tones are generated has been standardized (i.e., the local exchange of the callee generates a standardized ringing tone while the callee is being alerted). It makes sense for a standardized approach to provide this type of feedback for the user in a homogeneous environment such as the PSTN, where all the terminals have a similar user interface.
PSTNは、電話スイッチは、典型的には、被呼者が警告されていることを示す、呼び出し元に対する着信音を再生します。いつ、どこで、どのようにこれらの着信音が生成されるが（被呼者が警告されている間、すなわち、被呼者のローカル交換が標準化された着信音を生成する）標準化されています。標準化されたアプローチは、すべての端末が同様のユーザーインターフェースを有するPSTNなどの均質な環境でユーザのためのフィードバックのこのタイプを提供することは理にかなっています。
This homogeneity is not found among SIP user agents. SIP user agents have different capabilities, different user interfaces, and may be used to establish sessions that do not involve audio at all. Because of this, the way a SIP UA provides the user with information about the progress of session establishment is a matter of local policy. For example, a UA with a Graphical User Interface (GUI) may choose to display a message on the screen when the callee is being alerted, while another UA may choose to show a picture of a phone ringing instead. Many SIP UAs choose to imitate the user interface of the PSTN phones. They provide a ringing tone to the caller when the callee is being alerted. Such a UAC is supposed to generate ringing tones locally for its user as long as no early media is received from the UAS. If the UAS generates early media (e.g., an announcement or a special ringing tone), the UAC is supposed to play it rather than generate the ringing tone locally.
この均質性は、SIPユーザエージェントの間では見られません。 SIPユーザエージェントは異なる機能、異なるユーザインタフェースを持っている、とのすべてのオーディオ関係のないセッションを確立するために使用することができます。このため、SIP UAは、セッション確立の進捗状況についての情報をユーザーに提供する方法は、ローカルポリシーの問題です。別のUAはなくリンギング電話の画像を表示することを選択するかもしれないが、例えば、グラフィカルユーザインタフェース（GUI）とのUAが、被呼者が警告されて画面上にメッセージを表示することを選択することができます。多くのSIP UAは、PSTN電話のユーザインターフェイスを模倣するように選択します。彼らは、呼び出し先が警告されている呼び出し側に着信音を提供します。このようなUACは限り何の早期メディアがUASから受信されないように、そのユーザーのためにローカルに着信音を生成することになっています。 UASが初期メディア（例えば、告知や特別な呼び出し音）を生成した場合、UACはそれを再生するのではなく、ローカルに着信音を生成することになっています。
The problem is that, sometimes, it is not an easy task for a UAC to know whether it will be receiving early media or it should generate local ringing. A UAS can send early media without using reliable provisional responses (very simple UASs do that) or it can send an answer in a reliable provisional response without any intention of sending early media (this is the case when preconditions are used). Therefore, by only looking at the SIP signalling, a UAC cannot be sure whether or not there will be early media for a particular session. The UAC needs to check if media packets are arriving at a given moment.
問題は、UACは、それが初期メディアを受信するかどうかを知るためにか、それはローカル呼び出し音を生成する必要がありますため、時には、それは簡単な作業ではありません、ということです。 UASは信頼性のある暫定応答を使用せずに初期メディアを送信することができます（非常にシンプルなのUASがあることを行う）、または、それは（これは前提条件が使用されている場合である）初期メディアを送信する任意の意図せずに信頼性のある暫定応答で答えを送信することができます。したがって、唯一のSIPシグナリングを見ることで、UACは、特定のセッションのための初期メディアがあるでしょうかどうかを確認することはできません。 UACは、メディアパケットは、与えられた瞬間に到着しているかどうかを確認する必要があります。
An implementation could even choose to look at the contents of the media packets, since they could carry only silence or comfort noise.
彼らは唯一の沈黙や快適雑音を運ぶことができるので、実装はしても、メディアパケットの内容を見て選択することができます。
With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS ("Plain Old Telephone Service")-like SIP User Agent (UA) could implement the following local policy:
このことを念頭に、UACはローカル呼び出し音生成に関するローカルポリシーを開発する必要があります。例えば、POTS（「旧来の電話サービス」） - SIPユーザーエージェント（UA）などは、以下のローカルポリシーを実装できます。
1. Unless a 180 (Ringing) response is received, never generate local ringing.
180（リンギング）応答が受信されない限り1は、ローカルの呼び出し音を発生することはありません。
2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.
2.ローカルリンギングを生成する、180（リンギング）が受信されているが、着信メディアパケットが存在しない場合。
3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.
180（リンギング）を受信した着信メディアパケットがあり、それらを再生し、地元のリンギングが発生していない場合3.。
Note that a 180 (Ringing) response means that the callee is being alerted, and a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session.
180（リンギング）応答が被呼者が警告され、そして被呼者が警告されている場合、UASは関係なく、初期メディアセッションの状態を、そのような応答を送信する必要があることを意味することに留意されたいです。
At first sight, such a policy may look difficult to implement in decomposed UAs (i.e., media gateway controller and media gateway), but this policy is the same as the one described in Section 2, which must be implemented by any UA. That is, any UA should play incoming media packets (and stop local ringing tone generation if it was being performed) in order to avoid media clipping, even if the 200 (OK) response has not arrived. So, the tools to implement this early media policy are already available to any UA that uses SIP.
一見、そのようなポリシーは、分解のUA（すなわち、メディアゲートウェイコントローラ及びメディアゲートウェイ）に実装することが困難に見えるかもしれないが、このポリシーは、任意のUAによって実装されなければならない第2節で説明したものと同じです。つまり、任意のUAは、着信メディアパケットを再生する（そしてそれが実行された場合は、ローカル呼び出し音の生成を停止）200（OK）応答が到着していない場合でも、メディア・クリッピングを避けるために必要があります。だから、この初期のメディアポリシーを実装するためのツールがすでにSIPを使用するすべてのUAにご利用いただけます。
Note that, while it is not desirable to standardize a common local policy to be followed by every SIP UA, a particular subset of more or less homogeneous SIP UAs could use the same local policy by convention. Examples of such subsets of SIP UAs may be "all the PSTN/SIP gateways" or "every 3GPP IMS (Third Generation Partnership Project Internet Multimedia System) terminal". However, defining the particular common policy that such groups of SIP devices may use is outside the scope of this document.
すべてのSIP UAに、SIP UAが慣例によって同じローカルポリシーを使用することができ、多かれ少なかれ均質の特定のサブセットが追従すべき共通のローカルポリシーを標準化することは望ましくないが、なお。 SIPのUAのそのようなサブセットの例には、「すべてのPSTN / SIPゲートウェイ」または「すべての3GPP IMS（第3世代パートナーシッププロジェクトインターネットマルチメディアシステム）端末」であってもよいです。しかしながら、SIPデバイスのような基が使用できること、特定の共通のポリシーを定義することは、この文書の範囲外です。
SIP, as opposed to other signalling protocols, does not provide an early media indicator. That is, there is no information about the presence or absence of early media in SIP. Such an indicator could be potentially used to avoid the generation of local ringing tone by the UAC when UAS intends to provide an in-band ringing tone or some type of announcement. However, in the majority of the cases, such an indicator would be of little use due to the way SIP works.
SIPは、他のシグナリングプロトコルとは対照的に、初期メディアインジケータを提供していません。それは、SIPにおける初期メディアの存在または不在に関する情報がない、です。このような指標は、潜在的にUASは、帯域内着信音やアナウンスのいくつかの種類を提供しようとするときUACによってローカル呼び出し音の生成を回避するために使用することができます。しかし、ほとんどの場合、そのような指標が原因SIPが動作する方法にはほとんど使用であろう。
One important reason limiting the benefit of a potential early media indicator is the loose coupling between SIP signalling and the media path. SIP signalling traverses a different path than the media. The media path is typically optimized to reduce the end-to-end delay (e.g., minimum number of intermediaries), while the SIP signalling path typically traverses a number of proxies providing different services for the session. Hence, it is very likely that the media packets with early media reach the UAC before any SIP message that could contain an early media indicator.
潜在的な初期メディアインジケータのベネフィットを制限一つの重要な理由は、SIPシグナリングとメディアパス間の疎結合です。 SIPシグナリングがメディアとは異なるパスを横断します。 SIPシグナリング経路は、典型的には、セッションごとに異なるサービスを提供するプロキシの数を横断しながら、メディアパスは、典型的には、エンドツーエンド遅延（例えば、仲介者の最小数）を低減するように最適化されています。したがって、初期メディアとメディアパケットは、初期メディアインジケータが含まれている可能性のあるSIPメッセージの前にUACに達する可能性が非常に高いです。
Nevertheless, sometimes SIP responses arrive at the UAC before any media packet. There are situations in which the UAS intends to send early media but cannot do it straight away. For example, UAs using Interactive Connectivity Establishment (ICE) [6] may need to exchange several Simple Traversals of the UDP Protocol through NAT (STUN) messages before being able to exchange media. In this situation, an early media indicator would keep the UAC from generating a local ringing tone during this time. However, while the early media is not arriving at the UAC, the user would not be aware that the remote user is being alerted, even though a 180 (Ringing) had been received. Therefore, a better solution would be to apply a local ringing tone until the early media packets could be sent from the UAS to the UAC. This solution does not require any early media indicator.
それにもかかわらず、時々SIP応答は、任意のメディアパケットの前にUACに到着します。 UASが初期メディアを送信しようが、すぐにそれを行うことができない状況があります。例えば、インタラクティブ接続確立（ICE）を使用して、UAは、[6]メディアを交換することができる前に、NAT（STUN）メッセージを介してUDPプロトコルのいくつかの単純な全検索を交換する必要があるかもしれません。このような状況では、初期メディアインジケータは、この期間中のローカル呼び出し音を発生させるからUACを続けるだろう。初期メディアがUACに到着していない間しかし、ユーザーはリモートユーザーが180（リンギング）を受信していたにも関わらず、警告されていることを認識していないでしょう。そのため、よりよい解決策は、初期のメディアパケットがUACにUASから送ることができるまで、地元の呼出音を適用することであろう。このソリューションは、任意の初期メディアインジケータを必要としません。
Note that migrations from local ringing tone to early media at the UAC happen in the presence of forking as well; one UAS sends a 180 (Ringing) response, and later, another UAS starts sending early media.
UACの初期メディアへのローカル呼出音からの移行は同様にフォークの存在下で起こることに注意してください。 1 UASは180（リンギング）応答を送信し、以降、別のUASが初期メディアの送信を開始します。
Section 3 described some of the limitations of the gateway model. It produces media clipping in forking scenarios and requires media detection to generate local ringing properly. These issues are addressed by the application server model, described in Section 4, which is the recommended way of generating early media that is not continuous with the regular media generated during the session.
セクション3は、ゲートウェイモデルの制限のいくつかを記載しました。これは、フォークのシナリオでメディアクリップを生成し、適切ローカル呼び出し音を生成するメディア検出が必要です。これらの問題は、セッション中に発生した通常のメディアと連続していない初期メディアを生成する推奨される方法です第4章で説明したアプリケーション・サーバ・モデル、によって対処されています。
The gateway model is, therefore, acceptable in situations where the UA cannot distinguish between early media and regular media. A PSTN gateway is an example of this type of situation. The PSTN gateway receives media from the PSTN over a circuit, and sends it to the IP network. The gateway is not aware of the contents of the media, and it does not exactly know when the transition from early to regular media takes place. From the PSTN perspective, the circuit is a continuous source of media.
ゲートウェイモデルは、したがって、UAは初期メディアと通常のメディアを区別することができない状況では許容可能です。 PSTNゲートウェイは、この種の状況の一例です。 PSTNゲートウェイは、回路上PSTNからメディアを受信し、IPネットワークに送信します。ゲートウェイは、メディアの内容を認識していない、早期からの定期的なメディアへの移行が行われるとき、それは正確に知りません。 PSTNの観点から、回路は、媒体の連続的供給源です。
The application server model consists of having the UAS behave as an application server to establish early media sessions with the UAC. The UAC indicates support for the early-session disposition type (defined in [2]) using the early-session option tag. This way, UASs know that they can keep offer/answer exchanges for early media (early-session disposition type) separate from regular media (session disposition type).
アプリケーション・サーバ・モデルでは、UASは、UACと初期メディアセッションを確立するために、アプリケーションサーバーとして振る舞う持つから構成されています。 UACは、初期セッションのオプションタグを使用して（[2]で定義された）初期セッション気質タイプのサポートを示しています。このように、のUASは（初期セッション気質タイプ）通常のメディア（セッション気質タイプ）とは別に、彼らは早期メディアのオファー/アンサー交換を保つことができることを知っています。
Sending early media using a different offer/answer exchange than the one used for sending regular media helps avoid media clipping in cases of forking. The UAC can reject or mute new offers for early media without muting the sessions that will carry media when the original INVITE is accepted. The UAC can give priority to media received over the latter sessions. This way, the application server model transitions from early to regular media at the right moment.
通常のメディアを送信するために使用されるものとは別のオファー/アンサー交換を使用して、初期メディアを送信すると、フォークの例では、メディアのクリッピングを回避するのに役立ちます。 UACは、元がINVITEたときにメディアを運ぶセッションをミュートすることなく、初期メディアのための新たなオファーを拒否したりミュートすることができ受け入れられています。 UACは、後者のセッションを介して受信したメディアに優先順位を与えることができます。この方法では、通常のメディアへの早期からのアプリケーション・サーバー・モデルの遷移右現時点では。
Having a separate offer/answer exchange for early media also helps UACs decide whether or not local ringing should be generated. If a new early session is established and that early session contains at least an audio stream, the UAC can assume that there will be incoming early media and it can then avoid generating local ringing.
初期メディア用に別のオファー/アンサー交換を持つことも求めるUACがローカルリンギングが生成する必要があるかどうかを決定するのに役立ちます。新しい初期のセッションが確立され、その初期のセッションは、少なくともオーディオストリームが含まれている場合は、UACは、入ってくる初期メディアが存在することを想定することができ、それがその後、地元のリンギングの発生を回避することができます。
An alternative model would include the addition of a new stream, with an "early media" label, to the original session between the UAC and the UAS using an UPDATE instead of establishing a new early session. We have chosen to establish a new early session to be coherent with the mechanism used by application servers that are NOT co-located with the UAS. This way, the UAS uses the same mechanism as any application server in the network to interact with the UAC.
代替モデルは、UACとUASとの間に元のセッションはUPDATEを使用する代わりに、新たな早期のセッションを確立するには、「初期メディア」ラベルで、新しいストリームの追加が含まれるであろう。私たちはUASと同じ場所に配置されませんアプリケーションサーバによって使用されるメカニズムとコヒーレントであることを新たに早期のセッションを確立することを選択しました。このように、UASは、UACと対話するために、ネットワーク内の任意のアプリケーション・サーバーと同じメカニズムを使用しています。
Note that, even when the application server model is used, a UA will have to choose which early media sessions are muted and which ones are rendered to the user. In order to make this choice easier for UAs, it is strongly recommended that information that is not essential for the session not be transmitted using early media. For instance, UAs should not use early media to send special ringing tones. The status code and the reason phrase in SIP can already inform the remote user about the progress of session establishment, without incurring the problems associated with early media.
アプリケーション・サーバ・モデルを使用した場合でも、UAは、初期メディアセッションがミュートされ、どれがユーザーにレンダリングされるかを選択する必要があります、ということに注意してください。 UAのためのこの選択を容易にするためには、強くセッションが初期メディアを使用して送信されないために必須ではない、その情報を推奨します。例えば、UAは特別な着信音を送信するために、早期のメディアを使用しないでください。 SIPでのステータスコードと理由句は、すでに初期のメディアに関連する問題を招くことなく、セッション確立の進捗状況についてのリモートユーザに知らせることができます。
The Alert-Info header field allows specifying an alternative ringing content, such as ringing tone, to the UAC. This header field tells the UAC which tone should be played in case local ringing is generated, but it does not tell the UAC when to generate local ringing. A UAC should follow the rules described above for ringing tone generation in both models. If, after following those rules, the UAC decides to play local ringing, it can then use the Alert-Info header field to generate it.
Alert-Infoヘッダーフィールドは、UACに、トーンを鳴らすように、代替的なリンギングのコンテンツを指定することを可能にします。このヘッダーフィールドは、ローカルリンギングが発生した場合に再生されるべき音UACを伝えますが、ローカル呼び出し音を生成する際には、UACを教えてくれありません。 UACは、両方のモデルで音源を鳴らすために、上記の規則に従ってください。 、これらのルールに従った後、UACはローカル呼び出し音を再生することを決定した場合、それはそれを生成するために、Alert-Infoヘッダーフィールドを使用することができます。
SIP uses the offer/answer model [3] to establish early sessions in both the gateway and the application server models. User Agents (UAs) generate a session description, which contains the transport address (i.e., IP address plus port) where they want to receive media, and send it to their peer in a SIP message. When media packets arrive at this transport address, the UA assumes that they come from the receiver of the SIP message carrying the session description. Nevertheless, attackers may attempt to gain access to the contents of the SIP message and send packets to the transport address contained in the session description. To prevent this situation, UAs SHOULD encrypt their session descriptions (e.g., using S/MIME).
SIPは、[3]ゲートウェイとアプリケーション・サーバ・モデルの両方で早期のセッションを確立するためにオファー/アンサーモデルを使用しています。ユーザーエージェント（UAは）彼らはメディアを受信するトランスポートアドレス（すなわち、IPアドレスに加えてポート）を含むセッション記述を生成し、SIPメッセージの中で自分のピアに送信します。メディアパケットがこのトランスポートアドレスに到着すると、UAは、それらがセッション記述を搬送するSIPメッセージの受信機から来ることを想定しています。それにもかかわらず、攻撃者は、SIPメッセージの内容にアクセスし、セッション記述に含まれるトランスポート・アドレスにパケットを送信しようとすることができます。このような状況を防ぐために、UAはそのセッション記述（例えば、使用してS / MIME）を暗号化する必要があります。
Still, even if a UA encrypts its session descriptions, an attacker may try to guess the transport address used by the UA and send media packets to that address. Guessing such a transport address is sometimes easier than it may seem because many UAs always pick up the same initial media port. To prevent this situation, UAs SHOULD use media-level authentication mechanisms such as the Secure Realtime Transport Protocol (SRTP)[7]. In addition, UAs that wish to keep their communications confidential SHOULD use media-level encryption mechanisms (e.g, SRTP [7]).
それでも、UAは、そのセッション記述を暗号化した場合でも、攻撃者は、UAが使用するトランスポート・アドレスを推測し、そのアドレスにメディアパケットを送信しようとするかもしれません。多くのUAが常に同じ初期メディアポートを拾うため、このようなトランスポート・アドレスを推測することは、思われるかもしれないよりも、時には簡単です。このような状況を防ぐために、UAがそのようなセキュアリアルタイムトランスポートプロトコル（SRTP）などのメディアレベルの認証メカニズムを使用するべきである[7]。また、機密それらの通信を維持することを望むUAがメディアレベルの暗号化メカニズムを使用すべきである（例えば、SRTP [7]）。
Attackers may attempt to make a UA send media to a victim as part of a DoS attack. This can be done by sending a session description with the victim's transport address to the UA. To prevent this attack, the UA SHOULD engage in a handshake with the owner of the transport address received in a session description (just verifying willingness to receive media) before sending a large amount of data to the transport address. This check can be performed by using a connection oriented transport protocol, by using STUN [8] in an end-to-end fashion, or by the key exchange in SRTP [7].
攻撃者は、UAは、DoS攻撃の一環として、被害者にメディアを送信するために試みることができます。これは、UAに被害者のトランスポートアドレスでセッション記述を送信することにより行うことができます。この攻撃を防ぐために、UAは、セッション記述において受信されたトランスポートアドレスの所有者とのハンドシェイクに関与すべきであるトランスポートアドレスに大量のデータを送信する前に（ちょうどメディアを受信する意思を確認します）。このチェックは、[8]、エンドツーエンド方式で、またはSRTPにおける鍵交換[7]でSTUNを使用することにより、接続指向のトランスポートプロトコルを使用して行うことができます。
In any event, note that the previous security considerations are not early media specific, but apply to the usage of the offer/answer model in SIP to establish sessions in general.
いずれにせよ、以前のセキュリティの考慮事項は、初期メディア固有のものではありませんのでご注意、一般的には、セッションを確立するSIPにおけるオファー/アンサーモデルの使用に適用されます。
Additionally, an early media-specific risk (roughly speaking, equivalent to forms of "toll fraud" in the PSTN) attempts to exploit the different charging policies some operators apply to early and regular media. When UAs are allowed to exchange early media for free, but are required to pay for regular media sessions, rogue UAs may try to establish a bidirectional early media session and never send a 200 (OK) response for the INVITE.
さらに、（PSTNにおける「料金詐欺」の形態と同等大まかに言えば、）早期メディア固有のリスクは、一部の事業者が早期に通常のメディアに適用されます異なる充電方針を悪用しようとします。 UAが無料で初期メディアを交換することが許可されていますが、通常のメディアセッションのために支払うように要求された場合、不正なUAは双方向の初期メディアセッションを確立しようとすると、INVITEのための200（OK）応答を送信しないことがあります。
On the other hand, some application servers (e.g., Interactive Voice Response systems) use bidirectional early media to obtain information from the callers (e.g., the PIN code of a calling card). So, we do not recommend that operators disallow bidirectional early media. Instead, operators should consider a remedy of charging early media exchanges that last too long, or stopping them at the media level (according to the operator's policy).
一方、いくつかのアプリケーション・サーバー（例えば、対話型音声応答システム）は、発信者（例えば、コーリングカードのPINコード）から情報を得るために、双方向の初期メディアを使用しています。だから、私たちは、事業者が双方向の初期メディアを禁止することをお勧めしません。代わりに、オペレータは、あまりにも長くは続か初期メディアの交換を充電、または（オペレータのポリシーに従って）メディアレベルでそれらを停止する救済策を検討すべきです。
Jon Peterson provided useful ideas on the separation between the gateway model and the application server model.
ジョンピーターソンは、ゲートウェイモデルとアプリケーション・サーバ・モデルとの間の分離に有用なアイデアを提供しました。
Paul Kyzivat, Christer Holmberg, Bill Marshall, Francois Audet, John Hearty, Adam Roach, Eric Burger, Rohan Mahy, and Allison Mankin provided useful comments and suggestions.
ポール・Kyzivat、クリステルHolmbergの、ビル・マーシャル、フランソワAudet、ジョン・ハーティ、アダムローチ、エリック・バーガー、ローハンマーイ、およびアリソンマンキンは有益なコメントや提案を提供しました。
[1] 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.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[2]カマリロ、G.、 "セッション開始プロトコルのための初期セッション処分タイプ（SIP）"、RFC 3959、2004年12月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[3]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[4]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[5]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[6] Rosenberg, J., "Interactive connectivity establishment (ICE): a methodology for network address translator (NAT) traversal for the session initiation protocol (SIP)", Work in progress, July 2003.
[6]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：セッション開始プロトコル（SIP）のためのネットワークアドレス変換（NAT）トラバーサルのための方法」進歩、2003年7月に、ワーク。
[7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[7] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[8] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[8]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイを、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロ・カマリロエリクソン高度なシグナリング研究所。 FIN-02420 Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。