RFC3960 日本語訳

Network Working Group                                       G. Camarillo
Request for Comments: 3960                                      Ericsson
Category: Informational                                   H. Schulzrinne
                                                     Columbia University
                                                           December 2004

コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 3960年のエリクソンカテゴリ: 情報のH.Schulzrinneコロンビア大学2004年12月

                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).

Copyright(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.

このドキュメントはSession Initiationプロトコル(SIP)で2つのモデルを使用することで早めのメディアを経営する方法を説明します: ゲートウェイモデルとアプリケーション・サーバーはモデル化されます。 また、それは呼出音世代のためのローカルの方針を定義する際にものが考えるために必要とする入力について説明します。

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 一口. . . . . . . . . . . . . . . . . 3 3へのセッション設立。 ゲートウェイモデル。 . . . . . . . . . . . . . . . . . . . . . . 4 3.1. 分岐。 . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. トーン世代に電話をします。 . . . . . . . . . . . . . . . . 5 3.3. 早めのメディアインディケータの欠如。 . . . . . . . . . . 7 3.4. ゲートウェイモデル. . . . . . . . . . . 8 4の適用性。 アプリケーション・サーバーモデル. . . . . . . . . . . . . . . . . 8 4.1。 バンドにおけるセッション進歩情報対バンドの外 9 5. 注意深いインフォメーションヘッダーフィールド。 . . . . . . . . . . . . . . . . . . . 9 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 9 7. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 10 8. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1。 引用規格. . . . . . . . . . . . . . . . . . 11 8.2。 有益な参照. . . . . . . . . . . . . . . . . 11作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 12の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 13

Camarillo & Schulzrinne      Informational                      [Page 1]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[1ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

1.  Introduction

1. 序論

   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.

早めのメディアはメディア(例えば、オーディオとビデオ)を示します、すなわち、以前交換して、特定のセッションが呼ばれたユーザによって受け入れられます。 対話の中では、早めのメディアはUserエージェントServer(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.

RFC3261[1])は、非常に簡単な早めのメディアがメカニズムであるとサポートするだけです。基本のSIP仕様、(これらの簡単なメカニズムには、分岐とセキュリティに関連して、ほとんどのアプリケーションの要件を満たさない多くの問題があります。 このドキュメントは、RFC3261[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.

本書では説明された両方の早めのメディアモデルはRFC3261[1]で指定されたものより上級ですが、ゲートウェイモデルはまだ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-インフォメーションヘッダーフィールドの間の相互作用について論じます。

   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].

“SHALL"、「NOT」が「必須NOT」というキーワード“MUST"が、「必要でした」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[9]で説明されるように本書では解釈されることであるべきですか?

Camarillo & Schulzrinne      Informational                      [Page 2]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[2ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

2.  Session Establishment in SIP

2. 一口へのセッション設立

   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]を使用します。 ユーザエージェントのひとり(申出人)は申し出と呼ばれるセッション記述を準備します。 別のセッション記述が答えと呼ばれている状態で、もう片方のユーザエージェント(answerer)は応じます。 この両用握手で、両方のユーザエージェントは、セッションパラメタでメディアを交換するのに使用されるのに同意できます。

   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に起こるとき、メディア切り取りは避けられません。 呼ばれたユーザは同時に、(OK)が送られる200を話し始めますが、UserエージェントClient(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.

他方では、メディア切り取りは最も一般的な申し出/答え交換(申し出があるINVITEと答えがある200(OK))に現れません。 申し出を送るとすぐに、UACsは入って来るメディア向けの資料セットをプレーする準備ができています、始める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

別の形式のメディア切り取り(早めのメディアに関連しない)は訪問者から訪問される人への方向に現れます。 訪問される人が回復して、話し始めるとき、UASは答えと共に200(OK)応答を送ります、最初のメディア向けの資料セットと平行して。 最初のメディアです。

Camarillo & Schulzrinne      Informational                      [Page 3]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[3ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

   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.

パケットは答えの前にUACに到着します、そして、訪問者は話し始めます、そして、UASからの200(OK)応答が到着するまで、UACはメディアを送ることができません。

3.  The Gateway Model

3. ゲートウェイモデル

   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、およびUPDATEsの申し出/答え交換を使用することで早めのメディアセッションを管理するのから成ります。

   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で説明されるように分岐することの面前でゲートウェイモデルは真剣に制限されます。 したがって、Userエージェント(UA)が早くて通常のメディアを見分けることができないときだけ、使用は許容できます、セクション3.4で説明されるように。 いかなる他の状況(UAsの大部分)でも、セクション4で説明されたアプリケーション・サーバーモデルの使用は代わりに強く推薦されます。

3.1.  Forking

3.1. 分岐します。

   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手順に従って、INVITEで初期の申し出を送るとすぐに、UACはどんな入って来るメディアとも対戦する準備ができています。 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、メディア承認、またはメディア暗号化が必要である)におけるUAsは、メディア切り取りを避けるのに前提条件を使用します。

   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がいくつかの暫定的な応答における申し出の異なったUASsと異なった答えを受けるとき、これは起こります。 UACは帯域幅制限と早めのメディアセッション選択に対処しなければなりません。

Camarillo & Schulzrinne      Informational                      [Page 4]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[4ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

   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が異なったUASsから早めのメディアを受け取るなら、それは、ユーザにそれを提示する必要があります。 早めのメディアがオーディオから成るなら、同時にいくつかのオーディオストリームをユーザにプレーするのは混乱させられているかもしれません。 他方では、同時に、他のメディアタイプ(例えば、ビデオ)をユーザに提示できます。 例えば、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が帯域幅を制限したなら同時にユーザに上演されられることができるそれは同時に、すべての異なったUASsから早めのメディアを受け取ることができないでしょう。 したがって、何回も、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早めの対話でメディア向けの資料セットを関連させることさえできません。 したがって、UACsは手当たりしだいに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にUPDATEを「非-無言」に送らせて、メディアセッション(UACの代わりに)は逆方向に切り取られるメディアを避けません、そして、それは可能な競合条件を引き起こします。

3.2.  Ringing Tone Generation

3.2. 呼出音世代

   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

この同質はSIPユーザエージェントの中で見つけられません。 SIPユーザエージェントは、異なった能力、異なったユーザインタフェースを持って、全くオーディオにかかわらないセッションを証明するのに使用されるかもしれません。 これのために、SIP UAがセッション設立の進歩の情報をユーザに提供する方法はローカルの方針の問題です。 例えば、グラフィカルユーザインタフェイス(GUI)があるUAは、選ぶかもしれません。

Camarillo & Schulzrinne      Informational                      [Page 5]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[5ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

   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.

訪問される人が警告されていたらスクリーンにメッセージを表示してください、別のUAは、電話の画像が代わりに鳴るのを示すのを選ぶかもしれませんが。 多くのSIP UAsが、PSTN電話のユーザーインタフェースを模倣するのを選びます。 訪問される人が警告されているとき、彼らは呼出音を訪問者に提供します。 UASからユーザのために早めのメディアがないのと同じくらい長い間局所的にトーンを鳴らすUACが生成するべきであるそのようなものを受け取ります。 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が早めのメディアを送ることができますか(非常に簡単なUASsはそれをします)、またはそれは早めのメディアを送るという少しも意志なしで信頼できる暫定的な応答における答えを送ることができます(前提条件が使用されているとき、これはそうです)。 したがって、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 Userエージェント(UA)は以下のローカルの政策を実施できました:

      1. Unless a 180 (Ringing) response is received, never generate
         local ringing.

1. 180(鳴る)応答が受け取られていない場合、地方の鳴ることを決して生成しないでください。

      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.

3. 180(鳴る)が受け取られていて、入って来るメディア向けの資料セットがあれば、それらをプレーしてください、そして、地方の鳴ることを生成しないでください。

         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

一目で、そのような方針は分解しているUAs(すなわち、メディアゲートウェイコントローラとメディアゲートウェイ)で実装するのが難しく見えるかもしれませんが、この方針はどんなUAも実装しなければならないセクション2で説明されたものと同じです。 すなわちどんなUAも入って来るのにふるまうはずです。

Camarillo & Schulzrinne      Informational                      [Page 6]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[6ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

   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.

メディア向けの資料セット(それが実行されていたなら、地方の呼出音世代を止める)、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 UAsの特定の部分集合がコンベンションで同じローカルの方針を使用するかもしれないことに注意してください。 SIP UAsのそのような部分集合に関する例は、「すべてのPSTN/SIPゲートウェイ」か「あらゆる3GPP IMS(第3Generation Partnership ProjectインターネットMultimedia System)端末」であるかもしれません。 しかしながら、このドキュメントの範囲の外にSIPデバイスのそのようなグループが使用するかもしれない特定の共通政策を定義するのがあります。

3.3.  Absence of an Early Media Indicator

3.3. 早めのメディアインディケータの欠如

   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合図とメディア経路の間の疎結合である1つの重要な理由。 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が早めのメディアを送るつもりですが、すぐそれができない状況があります。 例えば、Interactive Connectivity特権階級(ICE)[6]を使用するUAsは、メディアを交換できる前にNAT(STUN)メッセージを通してUDPプロトコルの数個のSimple Traversalsを交換する必要があるかもしれません。 この状況で、早めのメディアインディケータは、UACがこの間に地方の呼出音を生成するのを妨げるでしょう。 しかしながら、早めのメディアがUACに到着していない間、ユーザはリモート・ユーザーが警告されているのを意識していないでしょう、180(鳴る)を受け取りましたが。 したがって、より良いソリューションは早いメディア向けの資料セットをUASからUACに送ることができるまで地方の呼出音を適用するだろうことです。 このソリューションはどんな早めのメディアインディケータも必要としません。

Camarillo & Schulzrinne      Informational                      [Page 7]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[7ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

      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の地方の呼出音から早めのメディアまでの移行が起こることに注意してください。 1UASが180(鳴る)応答を送ります、そして、後で、別のUASは早めのメディアを送り始めます。

3.4.  Applicability of the Gateway Model

3.4. ゲートウェイモデルの適用性

   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見解から、回路はメディアの連続した源です。

4.  The Application Server Model

4. アプリケーション・サーバーモデル

   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])では、前場のオプションタグを使用することで、定義されます。 この道、UASsは彼らが早めのメディア(前場の気質タイプ)への申し出/答え交換を通常のメディア(セッション気質タイプ)から別々に保つことができるのを知っています。

   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.

早く発信して、送付の通常のメディアに、中古の人が、分岐の場合で切り取られるメディアを避けるのを助けるより異なった申し出/を使用するメディアは交換に答えます。 オリジナルのINVITEを受け入れるときメディアを運ぶセッションに音を消さないで、UACは早めのメディアのために新しい申し出に拒絶するか、または音を消すことができます。 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.

また、早めのメディアへの別々の申し出/答え交換を持っているのは、UACsが、地方の鳴ることが生成されるべきであるかどうか決めるのを助けます。 新しい前場が確立されて、その前場が少なくともオーディオストリームを含んでいるなら、UACは、入って来る早めのメディアがあると仮定できます、そして、次に、それは地方の鳴ることを生成するのを避けることができます。

Camarillo & Schulzrinne      Informational                      [Page 8]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[8ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

      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と対話するのにネットワークにおけるどんなアプリケーション・サーバーとも同じメカニズムを使用します。

4.1.  In-Band Versus Out-of-Band Session Progress Information

4.1. バンドにおけるセッション進歩情報対バンドの外

   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が、どの早めのメディアセッションが音を消されるか、そして、どれがユーザに提供されるかを選ばなければならないことに注意してください。 この選択をUAsには、より簡単にするように、セッションに不可欠でない情報が早めのメディアを使用することで伝えられないことが強く勧められます。 例えば、UAsは、特別な呼出音を送るのに早めのメディアを使用するはずがありません。 ステータスコードとSIPの理由句はセッション設立の進歩に関して既にリモート・ユーザーに知らせることができます、早めのメディアに関連している問題を被らないで。

5.  Alert-Info Header Field

5. 注意深いインフォメーションヘッダーフィールド

   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-インフォメーションヘッダーフィールドで、UACへの呼出音などの内容を鳴らす代替手段を指定します。 地方の鳴るのが発生しているといけないので、このヘッダーフィールドは、どのトーンがプレーされるべきであるかをUACに言いますが、それは、いつ地方の鳴ることを生成するかをUACに言いません。 UACは両方のモデルにおける呼出音世代のために上で説明された規則に従うはずです。 それらの規則に従った後にUACが、地方の鳴ることをプレーすると決めるなら、それは、それを生成するのにAlert-インフォメーションヘッダーフィールドを使用できます。

6.  Security Considerations

6. セキュリティ問題

   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]を使用します。 ユーザエージェント(UAs)はセッション記述を生成します。(それは、SIPメッセージに彼らが同輩にメディアを受け取って、それを送りたがっている輸送アドレス(すなわち、IPアドレスとポート)を含みます)。 メディア向けの資料セットがこの輸送アドレスに到着するとき、UAは、セッション記述を運ぶSIPメッセージの受信機から来ると仮定します。 それにもかかわらず、攻撃者は、SIPメッセージのコンテンツへのアクセスを得て、セッション記述に含まれた輸送アドレスにパケットを送るのを試みるかもしれません。 この状況を防ぐために、UAs SHOULDは彼らのセッション記述(例えば、S/MIMEを使用する)を暗号化します。

Camarillo & Schulzrinne      Informational                      [Page 9]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[9ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

   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によって使用された輸送アドレスを推測して、そのアドレスにメディア向けの資料セットを送ろうとするかもしれません。 そのような輸送アドレスを推測するのは多くのUAsがいつも同じ初期のメディアポートを拾うので見えるかもしれないより時々簡単です。 この状況を防ぐために、UAs SHOULDはSecure Realtime Transportプロトコル(SRTP)[7]などのメディアレベル認証機構を使用します。 さらに、彼らのコミュニケーションが秘密のSHOULDであることを保ちたがっているUAsがメディアレベル暗号化メカニズムを使用します。(e.g、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 SHOULDはセッション記述(ただ、メディアを受け取る意欲について確かめる)で輸送アドレスの所有者を受け取っていて握手に従事しています。 接続指向のトランスポート・プロトコルを使用するか、終わりから終わりへのファッションで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の「料金詐欺」のフォームと同等物)は、何人かのオペレータが早くて通常のメディアに適用する異なった充電方針を利用するのを試みます。 UAsがただで早めのメディアを交換するのが許容されていますが、定期的なメディアセッションの対価を支払わなければならないとき、凶暴なUAsは双方向の早めのメディアセッションを確立して、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).

他方では、いくつかのアプリケーション・サーバー(例えば、Interactive Voice Responseシステム)が、訪問者(例えば、テレホンカードの暗証番号コード)から情報を得るのに双方向の早めのメディアを使用します。 それで、私たちは、オペレータが双方向の早めのメディアを禁じることを勧めません。 代わりに、オペレータはあまりに長い間続く早めのメディア交換を請求するか、またはメディアレベル(オペレータの方針によると)でそれらを止める療法を考えるべきです。

7.  Acknowledgments

7. 承認

   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、Christer Holmberg、ビル・マーシャル、フランソアAudet、ジョンHearty、アダム・ローチ、エリックBurger、Rohanマーイ、およびアリソン・マンキンは役に立つコメントと提案を提供しました。

Camarillo & Schulzrinne      Informational                     [Page 10]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[10ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [2] Camarillo, G., "The Early Session Disposition Type for the
       Session Initiation Protocol (SIP)", RFC 3959, December 2004.

2004年12月の[2] キャマリロ、G.、「セッション開始プロトコル(一口)のための前場の気質タイプ」RFC3959。

   [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
       Session Description Protocol (SDP)", RFC 3264, June 2002.

[3] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。

8.2.  Informative References

8.2. 有益な参照

   [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
       Responses in Session Initiation Protocol (SIP)", RFC 3262, June
       2002.

[4] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。

   [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
       Method", RFC 3311, October 2002.

[5] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、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)縦断のための方法論」、進行中のWork、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.

2004年の[7]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。

   [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.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。

   [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[9] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Camarillo & Schulzrinne      Informational                     [Page 11]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[11ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

Authors' Addresses

作者のアドレス

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland

ゴンサロキャマリロエリクソンは合図研究研究室を進めました。 フィン-02420Jorvasフィンランド

   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

コンピュータサイエンスColumbia University1214アムステルダムアベニューのヘニングSchulzrinne部、ニューヨーク、ニューヨーク10027の米国のM.C.0401

   EMail:  schulzrinne@cs.columbia.edu

メール: schulzrinne@cs.columbia.edu

Camarillo & Schulzrinne      Informational                     [Page 12]

RFC 3960        Early Media and Ringing Tone Generation    December 2004

キャマリロ、Schulzrinneの情報[12ページ]のRFC3960の早めのメディア、および呼出音世代2004年12月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Camarillo & Schulzrinne      Informational                     [Page 13]

キャマリロとSchulzrinne情報です。[13ページ]