[要約] RFC 3960は、SIPにおける早期メディアと呼び出し音の生成に関する仕様です。このRFCの目的は、SIPセッション中に早期メディアや呼び出し音を適切に処理するためのガイドラインを提供することです。
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)
セッション開始プロトコル (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.
このドキュメントでは、ゲートウェイ モデルとアプリケーション サーバー モデルの 2 つのモデルを使用してセッション開始プロトコル (SIP) の初期メディアを管理する方法について説明します。また、着信音生成のローカル ポリシーを定義する際に考慮する必要がある入力についても説明します。
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.
初期メディアとは、特定のセッションが呼び出されたユーザーによって受け入れられる前に交換されるメディア (オーディオやビデオなど) を指します。ダイアログ内では、最初の INVITE が送信された瞬間からユーザー エージェント サーバー (UAS) が最終応答を生成するまで、初期メディアが発生します。これは一方向または双方向の場合があり、呼び出し元、呼び出し先、またはその両方によって生成されます。着信者によって生成される初期メディアの典型的な例は、着信音やアナウンス (キューイング ステータスなど) です。発信者によって生成される初期のメディアは通常、音声コマンドまたは自動音声応答 (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 を使用した初期のメディア実装の 2 つのモデル、ゲートウェイ モデルとアプリケーション サーバー モデルについて説明します。
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].
この文書内のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきです」、「すべきではありません」、「推奨」、「してもよい」、および「任意」は次のとおりです。[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 でセッションの確立がどのように機能するかを簡単に要約します。これにより、SIP に固有の機能 (メディアのクリッピングを避けるために 200 (OK) より前にメディアが再生されるなど) を初期のメディア操作から分離したままにすることができます。
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] を使用してセッション パラメーターをネゴシエートします。ユーザー エージェントの 1 つであるオファー側は、オファーと呼ばれるセッション記述を準備します。もう一方のユーザー エージェント (アンサー側) は、アンサーと呼ばれる別のセッション記述で応答します。この双方向ハンドシェイクにより、両方のユーザー エージェントがメディアの交換に使用するセッション パラメータに同意することができます。
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] と UPDATE リクエスト [5] を使用すると、オファーと回答を交換する方法がさらに多くなります。
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) の送信と同時に話し始めますが、UAS はユーザー エージェント クライアント (UAC) からの応答が ACK で到着するまでメディアを送信できません。
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.
一方、メディア クリッピングは、最も一般的なオファーと回答の交換 (オファーを含む INVITE、および回答を含む 200 (OK)) には表示されません。UAC は、発信者に対するメディアの再生を開始するために 200 (OK) の受信を当てにできないため、オファーを送信するとすぐに受信メディア パケットを再生する準備ができています。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 に到着し、発信者が話し始める場合、UAC は UAS から 200 (OK) 応答が到着するまでメディアを送信できません。
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.
当然のことですが、初期メディア セッション内で交換されるメディアは初期メディアと呼ばれます。ゲートウェイ モデルは、信頼できる暫定応答、PRACK、および UPDATE でのオファー/アンサー交換を使用した初期メディア セッションの管理で構成されます。
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) が初期メディアと通常メディアを区別できない場合にのみ許容されます。その他の状況 (大多数の UA) では、代わりにセクション 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 が応答を受信する必要があることに注意してください。このような状況（たとえば、QoS、メディア認証、またはメディア暗号化が必要な場合）の UA は、前提条件を使用してメディア クリッピングを回避します。
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 を送信し、メディア セッションのミュートを解除します。UAS は、UAC からオファーを受信するまでメディアを送信できません。したがって、発信者が 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.
(UAC ではなく) UAS に 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 がセッション確立の進行状況に関する情報をユーザーに提供する方法は、ローカル ポリシーの問題になります。たとえば、グラフィカル ユーザー インターフェイス (GUI) を備えた UA は、着信者が警告を受けているときに画面にメッセージを表示することを選択できますが、別の 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 (「Plain Old Telephone Service」) のような SIP ユーザー エージェント (UA) は、次のローカル ポリシーを実装できます。
1. Unless a 180 (Ringing) response is received, never generate local ringing.
1. 180 (Ringing) 応答を受信しない限り、ローカル呼び出しを決して発生させないでください。
2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.
2. 180 (Ringing) を受信したが、着信メディア パケットがない場合は、ローカル リンギングを生成します。
3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.
3. 180 (Ringing) が受信され、着信メディア パケットがある場合は、それらを再生し、ローカル リンギングを生成しません。
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 (Ringing) 応答は、着信者が警告を受けていることを意味し、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 (メディア ゲートウェイ コントローラーとメディア ゲートウェイ) で実装するのが難しいように見えるかもしれませんが、このポリシーはセクション 2 で説明したものと同じであり、どの UA でも実装する必要があります。つまり、200 (OK) 応答が到着していない場合でも、メディア クリッピングを回避するために、UA は受信メディア パケットを再生する必要があります (ローカル呼び出し音の生成が実行されている場合は停止します)。したがって、この初期メディア ポリシーを実装するツールは、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 (Third Generation Partnership Project Internet Multimedia System) 端末」が挙げられます。ただし、そのような 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.
潜在的な初期メディア インジケーターの利点を制限する重要な理由の 1 つは、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) [6] を使用する UA は、メディアを交換できるようになる前に、NAT (STUN) メッセージを介して UDP プロトコルの単純なトラバーサルを複数回交換する必要がある場合があります。この状況では、初期のメディア インジケーターにより、この期間中 UAC がローカル呼び出し音を生成することがなくなります。ただし、初期メディアが UAC に到着していない間は、たとえ 180 (Ringing) を受信していても、ユーザーはリモート ユーザーに警告を受けていることに気づきません。したがって、より良い解決策は、初期のメディア パケットが UAS から UAC に送信されるまで、ローカルの呼び出し音を適用することです。このソリューションには初期メディア インジケーターは必要ありません。
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 (Ringing) 応答を送信し、その後、別の 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.
代替モデルには、新しい初期セッションを確立する代わりに、UPDATE を使用して、「初期メディア」ラベルが付いた新しいストリームを UAC と UAS の間の元のセッションに追加することが含まれます。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 は Secure Realtime Transport Protocol (SRTP)[7] などのメディアレベルの認証メカニズムを使用すべきです (SHOULD)。さらに、通信の機密性を維持したい UA は、メディアレベルの暗号化メカニズム (例: SRTP [7]) を使用する必要があります (SHOULD)。
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].
攻撃者は、DoS 攻撃の一環として、UA にメディアを被害者に送信させようとする可能性があります。これは、被害者のトランスポート アドレスを含むセッション記述を UA に送信することで実行できます。この攻撃を防ぐために、UA は、トランスポート アドレスに大量のデータを送信する前に、セッション記述で受信したトランスポート アドレスの所有者とハンドシェイクを行う必要があります (メディアを受信する意思を確認するだけです)。このチェックは、コネクション指向トランスポート プロトコルを使用するか、エンドツーエンド方式で STUN [8] を使用するか、SRTP [7] の鍵交換によって実行できます。
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.
Jon Peterson は、ゲートウェイ モデルとアプリケーション サーバー モデルの分離に関する有益なアイデアを提供しました。
Paul Kyzivat, Christer Holmberg, Bill Marshall, Francois Audet, John Hearty, Adam Roach, Eric Burger, Rohan Mahy, and Allison Mankin provided useful comments and suggestions.
Paul Kyzivat、Christer Holmberg、Bill Marshall、Francois Audet、John Hearty、Adam Roach、Eric Burger、Rohan Mahy、Allison Mankin が有益なコメントと提案を提供してくれました。
[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] Rosenberg, J.、Schulzrinne, H.、Camarillo, G.、Johnston, A.、Peterson, J.、Sparks, R.、Handley, M.、および E. Schooler、「SIP: セッション開始プロトコル」、RFC 3261、2002年6月。
[2] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[2] Camarillo, 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] Rosenberg, J. および H. Schulzrinne、「セッション記述プロトコル (SDP) を使用したオファー/アンサー モデル」、RFC 3264、2002 年 6 月。
[4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[4] Rosenberg, J. および H. Schulzrinne、「セッション開始プロトコル (SIP) における暫定応答の信頼性」、RFC 3262、2002 年 6 月。
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[5] Rosenberg, J.、「セッション開始プロトコル (SIP) UPDATE メソッド」、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] Rosenberg, 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.、McGrew, D.、Naslund, M.、Carrara, 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] Rosenberg, J.、Weinberger, J.、Huitema, C.、および R. Mahy、「STUN - ネットワーク アドレス トランスレータ (NAT) を介したユーザー データグラム プロトコル (UDP) の単純なトラバーサル」、RFC 3489、2003 年 3 月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
Authors' Addresses
著者の住所
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロ・カマリロ・エリクソン先端信号研究研究所FIN-02420 ジョルバス フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
Henning Schulzrinne Dep. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。