RFC3311 日本語訳
3311 The Session Initiation Protocol (SIP) UPDATE Method. J.Rosenberg. October 2002. (Format: TXT=28125 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 3311 dynamicsoft Category: Standards Track September 2002
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3311dynamicsoft Category: 標準化過程2002年9月
The Session Initiation Protocol (SIP) UPDATE Method
セッション開始プロトコル(一口)アップデートメソッド
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.
この仕様はSession Initiationプロトコル(SIP)のために新しいUPDATEメソッドを定義します。 UPDATEはクライアントがセッション(メディアストリームとそれらのコーデックのセットなどの)のパラメタをアップデートするのを許容しますが、対話の状態に影響力を全く持っていません。 その意味で、再INVITEに似ていますが、初期のINVITEを完成する前に再INVITEと異なって、それを送ることができます。 これで、それは非常に早めの対話の中でセッションパラメタをアップデートすることの役に立つようになります。
Rosenberg Standards Track [Page 1] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[1ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
Table of Contents
目次
1 Introduction .............................................. 2 2 Terminology ............................................... 3 3 Overview of Operation ..................................... 3 4 Determining Support for this Extension .................... 3 5 UPDATE Handling ........................................... 4 5.1 Sending an UPDATE ......................................... 4 5.2 Receiving an UPDATE ....................................... 5 5.3 Processing the UPDATE Response ............................ 6 6 Proxy Behavior ............................................ 7 7 Definition of the UPDATE method ........................... 7 8 Example Call Flow ......................................... 7 9 Security Considerations ................................... 11 10 IANA Considerations ....................................... 11 11 Notice Regarding Intellectual Property Rights ............. 11 12 Normative References ...................................... 11 13 Acknowledgements .......................................... 12 14 Author's Address .......................................... 12 15 Full Copyright Statement .................................. 13
1つの序論… 2 2用語… 操作の3 3概要… このExtensionのための3 4決定Support… 3 5は取り扱いをアップデートします… 4 5.1 アップデートを送ります… 4 5.2 アップデートを受けます… 5 5.3 アップデート応答を処理します… 6 6プロキシの振舞い… UPDATEメソッドの7 7定義… 7 8例の呼び出し流動… 7 9のセキュリティ問題… 11 10のIANA問題… 11 11に知的所有権に関して気付きます… 11 12の引用規格… 11 13の承認… 12 14作者のアドレス… 12 15の完全な著作権宣言文… 13
1 Introduction
1つの序論
The Session Initiation Protocol (SIP) [1] defines the INVITE method for the initiation and modification of sessions. However, this method actually affects two important pieces of state. It impacts the session (the media streams SIP sets up) and also the dialog (the state that SIP itself defines). While this is reasonable in many cases, there are important scenarios in which this coupling causes complications.
Session Initiationプロトコル(SIP)[1]はセッションの開始と変更のためのINVITEメソッドを定義します。 しかしながら、このメソッドは実際に2つの重要な状態に影響します。 それはセッション(SIPが上にメディアストリームを設定していて)と対話(SIP自身が定義する状態)にも影響を与えます。 これは多くの場合妥当ですが、このカップリングが複雑さを引き起こす重要なシナリオがあります。
The primary difficulty is when aspects of the session need to be modified before the initial INVITE has been answered. An example of this situation is "early media", a condition where the session is established, for the purpose of conveying progress of the call, but before the INVITE itself is accepted. It is important that either caller or callee be able to modify the characteristics of that session (putting the early media on hold, for example), before the call is answered. However, a re-INVITE cannot be used for this purpose, because the re-INVITE has an impact on the state of the dialog, in addition to the session.
プライマリ困難はセッションの局面が初期のINVITEが答えられる前に変更される必要がある時です。 INVITE自身を受け入れる前にこの状況に関する例は「早めのメディア」、しかし、呼び出しの進歩を運ぶ目的のためのセッションが確立される状態です。 訪問者か訪問される人のどちらかがそのセッション(例えば、早めのメディアを保留にする)の特性を変更できるのは、重要です、呼び出しが答えられる前に。 しかしながら、このために再INVITEを使用できません、再INVITEが対話の状態に影響を与えるので、セッションに加えて。
As a result, a solution is needed that allows the caller or callee to provide updated session information before a final response to the initial INVITE request is generated. The UPDATE method, defined here, fulfills that need. It can be sent by a UA within a dialog (early or confirmed) to update session parameters without impacting the dialog state itself.
その結果、初期のINVITE要求への最終的な応答が発生している前に訪問者か訪問される人がアップデートされたセッション情報を提供できるソリューションが必要です。 ここで定義されたUPDATEメソッドはその必要性を実現させます。 UAは、対話状態自体に影響を与えないでセッションパラメタをアップデートするために対話(早いか確認された)の中でそれを送ることができます。
Rosenberg Standards Track [Page 2] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[2ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
2 Terminology
2 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[2]ということであり、対応する一口実装のために要件レベルを示すべきであるかをさせましょう。
3 Overview of Operation
操作の3概要
Operation of this extension is straightforward. The caller begins with an INVITE transaction, which proceeds normally. Once a dialog is established, either early or confirmed, the caller can generate an UPDATE method that contains an SDP offer [3] for the purposes of updating the session. The response to the UPDATE method contains the answer. Similarly, once a dialog is established, the callee can send an UPDATE with an offer, and the caller places its answer in the 2xx to the UPDATE. The Allow header field is used to indicate support for the UPDATE method. There are additional constraints on when UPDATE can be used, based on the restrictions of the offer/answer model.
この拡大の操作は簡単です。 訪問者はINVITEトランザクションで始めます。(通常、それは、続きます)。 対話がいったん早く確立されるか、または確認されると、訪問者は、UPDATEがセッションをアップデートする目的のためのSDP申し出[3]を含むメソッドであると生成することができます。 UPDATEメソッドへの応答は答えを含んでいます。 同様に、対話がいったん確立されると、訪問される人は申し出、および訪問者場所があるUPDATEにUPDATEへの2xxの答えを送ることができます。 Allowヘッダーフィールドは、UPDATEメソッドのサポートを示すのに使用されます。 申し出/答えモデルの制限に基づいてUPDATEを使用できる時追加規制があります。
4 Determining Support for this Extension
4 このExtensionのためにSupportを決定すること。
The initiation of a session operates as specified in RFC 3261 [1]. However, a UAC compliant to this specification SHOULD also include an Allow header field in the INVITE request, listing the method UPDATE, to indicate its ability to receive an UPDATE request.
セッションの開始はRFC3261[1]で指定されるように働いています。 しかしながら、また、この仕様SHOULDに言いなりになっているUACはINVITE要求にAllowヘッダーフィールドを含んでいます、UPDATE要求を受け取る性能を示すためにメソッドUPDATEを記載して。
When a UAS compliant to this specification receives an INVITE request for a new dialog, and generates a reliable provisional response containing SDP, that response SHOULD contain an Allow header field that lists the UPDATE method. This informs the caller that the callee is capable of receiving an UPDATE request at any time. An unreliable provisional response MAY contain an Allow header field listing the UPDATE method, and a 2xx response SHOULD contain an Allow header field listing the UPDATE method.
この仕様に言いなりになっているUASが新しい対話を求めるINVITE要求を受け取って、SDPを含む信頼できる暫定的な応答を生成するとき、その応答SHOULDはUPDATEメソッドを記載するAllowヘッダーフィールドを含んでいます。 これは、訪問される人がいつでもUPDATE要求を受け取ることができることを訪問者に知らせます。 頼り無い暫定的な応答はUPDATEメソッドを記載するAllowヘッダーフィールドを含むかもしれません、そして、2xx応答SHOULDはUPDATEメソッドを記載するAllowヘッダーフィールドを含んでいます。
Responses are processed normally as per RFC 3261 [1], and in the case of reliable provisional responses, according to [4]. It is important to note that a reliable provisional response will always create an early dialog at the UAC. Creation of this dialog is necessary in order to receive UPDATE requests from the callee.
通常、応答はRFC3261[1]、および[4]に従った信頼できる暫定的な応答の場合で処理されます。 信頼できる暫定的な応答がいつも早めの対話をUACに作成することに注意するのは重要です。 この対話の作成が、訪問される人からUPDATE要求を受け取るのに必要です。
If the response contains an Allow header field containing the value "UPDATE", the UAC knows that the callee supports UPDATE, and the UAC is allowed to follow the procedures of Section 5.1.
応答が値の「アップデート」を含むAllowヘッダーフィールドを含んでいるなら、UACは、訪問される人がアップデートをサポートするのを知っています、そして、UACはセクション5.1の手順に従うことができます。
Rosenberg Standards Track [Page 3] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[3ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
5 UPDATE Handling
5 アップデート取り扱い
5.1 Sending an UPDATE
5.1 アップデートを送ること。
The UPDATE request is constructed as would any other request within an existing dialog, as described in Section 12.2.1 of RFC 3261. It MAY be sent for both early and confirmed dialogs, and MAY be sent by either caller or callee. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE.
UPDATE要求はいかなる他の要求であるだろうというののようにも既存の対話の中で構成されます、.1セクション12.2RFC3261で説明されるように。 それを両方のために早く送って、対話を確認して、訪問者か訪問される人のどちらかは送るかもしれません。 確認された対話でUPDATEを使用できますが、再INVITEが代わりに使用されるのは、RECOMMENDEDです。 これはユーザ承認の可能性を除外して、UPDATEが、すぐに答えられる必要があるからです。 そのような承認は、頻繁に必要であり、再INVITEで可能です。
The UAC MAY add optional headers for the UPDATE request, as defined in Tables 1 and 2.
UAC MAYはUPDATE要求のためにTables1と2で定義されるように任意のヘッダーを加えます。
UPDATE is a target refresh request. As specified in RFC 3261 [1], this means that it can update the remote target of a dialog. If a UA uses an UPDATE request or response to modify the remote target while an INVITE transaction is in progress, and it is a UAS for that INVITE transaction, it MUST place the same value into the Contact header field of the 2xx to the INVITE that it placed into the UPDATE request or response.
UPDATEによる目標が要求をリフレッシュするということです。 RFC3261[1]で指定されるように、これは、対話のリモート目標をアップデートできることを意味します。 INVITEトランザクションが進行していますが、UAがリモート目標を変更するのにUPDATE要求か応答を使用して、そのINVITEトランザクションのためのUASであるなら、それはそれがUPDATE要求か応答に置いたINVITEへの2xxのContactヘッダーフィールドに同じ値を置かなければなりません。
The rules for inclusion of offers and answers in SIP messages as defined in Section 13.2.1 of RFC 3261 still apply. These rules exist to guarantee a consistent view of the session state. This means that, for the caller:
.1セクション13.2RFC3261で定義されるSIPメッセージにおける申し出と答えの包含のための規則はまだ適用されています。 これらの規則は、セッション状態の一貫した視点を保証するために存在しています。 これは訪問者のためにそれを意味します:
o If the UPDATE is being sent before completion of the initial
INVITE transaction, and the initial INVITE contained an offer,
the UPDATE can contain an offer if the callee generated an
answer in a reliable provisional response, and the caller has
received answers to any other offers it sent in either PRACK or
UPDATE, and has generated answers for any offers it received in
an UPDATE from the callee.
o 初期のINVITEトランザクションの完成の前にUPDATEを送って、初期のINVITEが申し出を含んだなら、訪問される人が信頼できる暫定的な応答における答えを生成したならUPDATEが申し出を含むことができて、訪問者は、それがPRACKかUPDATEのどちらかで送るいかなる他の申し出の答えも受けて、それがUPDATEで訪問される人から受けたどんな申し出のための答えも生成しました。
o If the UPDATE is being sent before completion of the initial
INVITE transaction, and the initial INVITE did not contain an
offer, the UPDATE can contain an offer if the callee generated
an offer in a reliable provisional response, and the UAC
generated an answer in the corresponding PRACK. Of course, it
can't send an UPDATE if it has not received answers to any
other offers it sent in either PRACK or UPDATE, or has not
generated answers for any other offers it received in an UPDATE
from the callee.
o 訪問される人は申し出が信頼できる暫定的な応答で生成されて、対応するPRACKで答えであると生成されたUACを生成されて、初期のINVITEトランザクションの完成の前にUPDATEを送って、初期のINVITEが申し出を含まなかったなら、UPDATEは申し出を含むことができます。 もちろん、それがPRACKかUPDATEのどちらかで送ったいかなる他の申し出の答えも受けていないか、またはそれがUPDATEで訪問される人から受けたいかなる他の申し出のための答えも生成していないなら、それはUPDATEを送ることができません。
Rosenberg Standards Track [Page 4] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[4ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
o If the UPDATE is being sent after the completion of the initial
INVITE transaction, it cannot contain an offer if the caller
has generated or received offers in a re-INVITE or UPDATE which
have not been answered.
o 初期のINVITEトランザクションの完成の後にUPDATEを送るなら、訪問者が再INVITEかUPDATEの答えられていない申し出を生成するか、または受けたなら、それは申し出を含むことができません。
and for the callee:
そして、訪問される人のために:
o If the UPDATE is being sent before the completion of the INVITE
transaction, and the initial INVITE contained an offer, the
UPDATE cannot be sent with an offer unless the callee has
generated an answer in a reliable provisional response, has
received a PRACK for that reliable provisional response, has
not received any requests (PRACK or UPDATE) with offers that it
has not answered, and has not sent any UPDATE requests
containing offers that have not been answered.
o INVITEトランザクションの完成の前にUPDATEを送って、初期のINVITEが申し出を含んだなら、訪問される人が信頼できる暫定的な応答で答えを生成して、その信頼できる暫定的な応答のためにPRACKを受けて、それが答えていない申し出でまだ、要求(PRACKかUPDATE)を受け取っていなくて、答えられていない申し出を含むどんなUPDATE要求も送った場合、申し出と共にUPDATEを送ることができません。
o If the UPDATE is being sent before completion of the INVITE
transaction, and the initial INVITE did not contain an offer,
the UPDATE cannot be sent with an offer unless the callee has
sent an offer in a reliable provisional response, received an
answer in a PRACK, and has not received any UPDATE requests
with offers that it has not answered, and has not sent any
UPDATE requests containing offers that have not been answered.
o INVITEトランザクションの完成の前にUPDATEを送って、訪問される人が信頼できる暫定的な応答で申し出を送って、PRACKで答えを受けて、答えていなくて、また答えられていない申し出を含むどんなUPDATE要求も送らないという申し出によるどんなUPDATE要求も受け取って、初期のINVITEが申し出を含まなかったなら、申し出と共にUPDATEを送ることができません。
o If the UPDATE is being sent after the completion of the initial
INVITE transaction, it cannot be sent with an offer if the
callee has generated or received offers in a re-INVITE or
UPDATE which have not been answered.
o 初期のINVITEトランザクションの完成の後にUPDATEを送るなら、訪問される人が再INVITEかUPDATEの答えられていない申し出を生成するか、または受けたなら、申し出と共にそれを送ることができません。
5.2 Receiving an UPDATE
5.2 アップデートを受けること。
The UPDATE is processed as any other mid-dialog target refresh request, as described in Section 12.2.2 of RFC 3261 [1]. If the request is generally acceptable, processing continues as described below. This processing is nearly identical to that of Section 14.2 of RFC 3261 [1], but generalized for the case of UPDATE.
いかなる他の中間の対話目標も要求をリフレッシュするとき、UPDATEは.2セクション12.2RFC3261[1]で説明されるように処理されます。 要求が一般に許容できるなら、処理は以下で説明されるように続きます。 この処理は、RFC3261[1]のセクション14.2のものとほとんど同じですが、UPDATEに関するケースのために一般化されています。
A UAS that receives an UPDATE before it has generated a final response to a previous UPDATE on the same dialog MUST return a 500 response to the new UPDATE, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds.
同じ対話で前のUPDATEへの最終的な応答を生成する前にUPDATEを受けるUASは新しいUPDATEへの500応答を返さなければならなくて、手当たりしだいに選ばれた値がある後のRetryヘッダーフィールドを0〜10秒含まなければなりません。
If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST
UPDATEが受け取られているなら、それは申し出を含んでいます、そして、UASはそれがまだ答えを受けていない申し出(UPDATE、PRACKまたはINVITEの)を生成しました、そして、UAS MUSTは491応答でUPDATEを拒絶します。 同様に、UPDATEが受け取られているなら、それは申し出を含んでいます、そして、UASはそれがまだ答えを生成していない申し出(UPDATE、PRACK、またはINVITEの)を受けました、UAS MUST
Rosenberg Standards Track [Page 5] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[5ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds.
500応答でUPDATEを拒絶して、手当たりしだいに選ばれた値がある後のRetryヘッダーフィールドを0〜10秒含まなければなりません。
If a UA receives an UPDATE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly and generate an answer in the 2xx response. However, unlike a re-INVITE, the UPDATE MUST be responded to promptly, and therefore the user cannot generally be prompted to approve the session changes. If the UAS cannot change the session parameters without prompting the user, it SHOULD reject the request with a 504 response. If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response for the UPDATE. This response SHOULD include a Warning header field.
UAが既存の対話のためにUPDATEを受けるなら、それは、それが変化したかどうかを見るためにセッション記述におけるどんなバージョン識別子かバージョン識別子が全くないときのセッション記述の内容もチェックしなければなりません。 セッション記述が変化したなら、UAS MUSTはそれに従って、セッションパラメタを調整して、2xx応答における答えを生成します。 しかしながら、再INVITEと異なってUPDATE MUST、至急、応答してください。そうすれば、したがって、一般に、ユーザがセッション変化を承認するようにうながすことができません。 ユーザをうながさないで、UASであるならセッションパラメタを変えることができません、それ。SHOULDは504応答で要求を拒絶します。 新しいセッション記述が許容できないなら、UASは、UPDATEのために488(Acceptable Hereでない)応答を返すことによって、それを拒絶できます。 この応答SHOULDはWarningヘッダーフィールドを含んでいます。
5.3 Processing the UPDATE Response
5.3 アップデート応答を処理すること。
Processing of the UPDATE response at the UAC follows the rules in Section 12.2.1.2 of RFC 3261 [1] for a target refresh request. Once that processing is complete, it continues as specified below. This processing is nearly identical to the processing of Section 14.1 of RFC 3261 [1], but generalized for UPDATE.
UACのUPDATE応答の処理は目標のための.2RFC3261[1]が要求をリフレッシュするというセクション12.2.1における規則に従います。 それは、以下で指定されるとしてかつて、その処理が完全であり続けています。 この処理は、RFC3261[1]のセクション14.1の処理とほとんど同じですが、UPDATEのために一般化されています。
If a UA receives a non-2xx final response to a UPDATE, the session parameters MUST remain unchanged, as if no UPDATE had been issued. Note that, as stated in Section 12.2.1 of RFC 3261 [1], if the non- 2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is received for the UPDATE (that is, a timeout is returned by the UPDATE client transaction), the UAC will terminate the dialog.
UAがUPDATEへの非2xxの最終的な応答を受けるなら、セッションパラメタは変わりがあってはいけません、まるでUPDATEが全く発行されていないかのように。 UPDATE(UPDATEクライアントトランザクションはすなわち、タイムアウトを返す)のために、(呼び出し/トランザクションDoes Not Exist)にもかかわらず、408(Timeoutを要求する)にもかかわらず、応答が非2xxの最終的な応答が481であるなら.1セクション12.2RFC3261[1]で述べられているように全くそうでないというメモを受け取って、UACは対話を終えるでしょう。
If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer with a value T chosen as follows:
aであるなら、UACはUPDATEへの491応答を受けて、それは値Tが以下の通り選ばれているSHOULDスタートaタイマです:
1. If the UAC is the owner of the Call-ID of the dialog ID
(meaning it generated the value), T has a randomly chosen value
between 2.1 and 4 seconds in units of 10 ms.
1. UACが対話IDのCall-IDの所有者(それを意味すると、値は生成した)であるなら、Tはユニットの10原稿に手当たりしだいに選ばれた値を2.1〜4秒持っています。
2. If the UAC is not the owner of the Call-ID of the dialog ID, T
has a randomly chosen value between 0 and 2 seconds in units of
10 ms.
2. UACが対話IDのCall-IDの所有者でないなら、Tはユニットの10原稿に手当たりしだいに選ばれた値を0〜2秒持っています。
When the timer fires, the UAC SHOULD attempt the UPDATE once more, if it still desires for that session modification to take place. For example, if the call was already hung up with a BYE, the UPDATE would not take place.
タイマが撃たれると、UAC SHOULDはもう一度UPDATEを試みます、そのセッション変更が行われることをまだ望んでいるなら。 例えば、呼び出しがBYEと共に既に掛けられるなら、UPDATEは行われないでしょうに。
Rosenberg Standards Track [Page 6] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[6ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
6 Proxy Behavior
6 プロキシの振舞い
Proxy processing of the UPDATE request is identical to any other non-INVITE request.
UPDATE要求のプロキシ処理はいかなる他の非INVITE要求とも同じです。
7 Definition of the UPDATE method
7 UPDATEメソッドの定義
The semantics of the UPDATE method are described in detail above. This extension adds another value to the Method BNF described in RFC 3261:
UPDATEメソッドの意味論は上で詳細に説明されます。 この拡大はRFC3261で説明されたMethod BNFに別の価値を高めます:
UPDATEm = %x55.50.44.41.54.45 ; UPDATE in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm / UPDATEm
/ extension-method
UPDATEm=%x55.50.44.41.54.45。 上限MethodのUPDATEは拡大INVITEm/ACKm/OPTIONSm/BYEm/CANCELm/REGISTERm/UPDATEm/メソッドと等しいです。
Table 1 extends Table 2 of RFC 3261 for the UPDATE method.
テーブル1はUPDATEメソッドのためにRFC3261のTable2を広げています。
Table 2 updates Table 3 of RFC 3261 for the UPDATE method.
テーブル2はUPDATEメソッドのためにRFC3261のTable3をアップデートします。
8 Example Call Flow
8 例の呼び出し流動
This section presents an example call flow using the UPDATE method. The flow is shown in Figure 1. The caller sends an initial INVITE (1) which contains an offer. The callee generates a 180 response (2) with an answer to that offer. With the completion of an offer/answer exchange, the session is established, although the dialog is still in the early state. The caller generates a PRACK (3) to acknowledge the 180, and the PRACK is answered with a 200 OK (4). The caller decides to update some aspect of the session - to put it on hold, for example. So, they generate an UPDATE request (5) with a new offer. This offer is answered in the 200 response to the UPDATE (6). Shortly thereafter, the callee decides to update some aspect of the session, so it generates an UPDATE request (7) with an offer, and the answer is sent in the 200 response (8). Finally, the callee answers the call, resulting in a 200 OK response to the INVITE (9), and then an ACK (10). Neither the 200 OK to the INVITE, nor the ACK, will contain SDP.
このセクションは、UPDATEメソッドを使用することで例の呼び出し流動を提示します。 流れは図1に示されます。 訪問者は申し出を含む初期のINVITE(1)を送ります。 訪問される人は、その申し出の答えで180応答が(2)であると生成します。 申し出/答え交換の完成で、対話がまだ早めの状態にありますが、セッションは確立されます。 訪問者は180を承認するためにPRACK(3)を生成します、そして、PRACKは200OK(4)で答えられます。 訪問者は、セッションの何らかの局面をアップデートすると決めます--それを置くには、例えば成立してください。 それで、彼らは、新しい申し出でUPDATEが要求(5)であると生成します。 UPDATE(6)への200応答でこの申し出に答えます。 その後まもなく、訪問される人は、セッションの何らかの局面をアップデートすると決めます、そして、したがって、それは、申し出でUPDATEが要求(7)であると生成します、そして、200応答(8)で答えを送ります。 最終的に、訪問される人は電話口に出ます、INVITE(9)への200OK応答をもたらして、次に、ACK(10)をもたらして。 200がINVITEに承認しないどちらも、およびACKはSDPを含むでしょう。
Rosenberg Standards Track [Page 7] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[7ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
Header field where proxy UPDATE
____________________________________________
Accept R o
Accept 2xx o
Accept 415 c
Accept-Encoding R o
Accept-Encoding 2xx o
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx o
Accept-Language 415 c
Alert-Info -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Allow-Events (1) -
Authentication-Info 2xx o
Authorization R o
Call-ID c r m
Call-Info ar o
Contact R m
Contact 1xx o
Contact 2xx m
Contact 3xx d o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length ar t
Content-Type *
CSeq c r m
Date a o
Error-Info 300-699 a o
Event (1) -
Expires -
From c r m
In-Reply-To -
Max-Forwards R amr m
Min-Expires -
MIME-Version o
Organization ar o
ヘッダーフィールドどこプロキシUPDATE____________________________________________ Acceptをコード化しているAcceptをコード化しているAcceptをコード化しているR Accept 2xx o Accept415c o R o2xx oのR o Accept-言語2xx415c Accept-言語o Accept-言語415c Alert-インフォメーションを受け入れてください--R o Allow 2xx o Allow r oにAllow405m Allow-イベント(1)を許容してください--認証インフォメーション2xx o Authorization R o Call-ID c r m Call-インフォメーションはo Contactをarします; Contentをコード化しているR m Contact 1xx○Contact 2xx m Contact 3xx d○Contact485のo o Content-言語oのo Content-気質Content-長さはtコンテントタイプ*CSeq c r m Date a o Error-インフォメーション300-699a o Event(1)をarします--c r mから期限が切れる、Inが答える、--R amr mがMin吐き出すマックス-フォワード--MIMEバージョンo Organization ar o
Table 1: Summary of header fields, A--O ; (1) defined in [5].
テーブル1: A--ヘッダーフィールドの概要、O。 (1) [5]では、定義されます。
Rosenberg Standards Track [Page 8] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[8ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
Header field where proxy UPDATE
____________________________________________________
Priority -
Proxy-Authenticate 407 ar m
Proxy-Authenticate 401 ar o
Proxy-Authorization R dr o
Proxy-Require R ar o
RAck R -
Record-Route R ar o
Record-Route 2xx,18x mr o
Reply-To -
Require ar c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R adr c
RSeq - -
Server r o
Subject - -
Subscription-State (1) -
Supported R o
Supported 2xx o
Timestamp o
To c r m
Unsupported 420 m
User-Agent o
Via R amr m
Via rc dr m
Warning r o
WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o
ヘッダーフィールドどこプロキシUPDATE____________________________________________________ 優先権--407ar mをプロキシで認証するのはR dr oがProxy必要とする401ar o Proxy-承認R ar o RAck R--記録的なルートR ar o Record-ルート2xxをProxy認証します、18x mr o、Reply、-、--ar c後のRetry4044億1348万486o50万503o600,603o Route R adr c RSeqを必要としてください--To c r m Unsupported420m User-エージェントo Via R amr m Via rc dr m Warning r oが401ar mにWWW認証するR o Supported 2xx o Timestamp○であるとサポートされて(購読州の(1))(サーバr o Subject)、407ar oをWWW認証してください
Table 2: Summary of header fields, P--Z.
テーブル2: P--ヘッダーフィールドの概要、Z。
Rosenberg Standards Track [Page 9] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[9ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
Caller Callee
| |
| |
|(1) INVITE with offer 1 |
|---------------------------->|
| |
| |
|(2) 180 with answer 1 |
|<----------------------------|
| |
| |
|(3) PRACK |
|---------------------------->|
| |
| |
|(4) 200 PRACK |
|<----------------------------|
| |
| |
|(5) UPDATE with offer 2 |
|---------------------------->|
| |
| |
|(6) 200 UPDATE with answer 2 |
|<----------------------------|
| |
| |
|(7) UPDATE with offer 3 |
|<----------------------------|
| |
| |
|(8) 200 UPDATE with answer 3 |
|---------------------------->|
| |
| |
|(9) 200 INVITE |
|<----------------------------|
| |
| |
|(10) ACK |
|---------------------------->|
| |
| |
| |
| |
訪問者訪問される人| | | | |(1) 申し出1があるINVITE| |---------------------------->| | | | | |(2) 180 答え1で| |<----------------------------| | | | | |(3) PRACK| |---------------------------->| | | | | |(4) 200 PRACK| |<----------------------------| | | | | |(5) 申し出2があるUPDATE| |---------------------------->| | | | | |(6) 200 答え2があるUPDATE| |<----------------------------| | | | | |(7) 申し出3があるUPDATE| |<----------------------------| | | | | |(8) 200 答え3があるUPDATE| |---------------------------->| | | | | |(9) 200 招待| |<----------------------------| | | | | |(10) ACK| |---------------------------->| | | | | | | | |
Figure 1: UPDATE Call Flow
図1: アップデート呼び出し流動
Rosenberg Standards Track [Page 10] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[10ページ]RFC3311はアップデートメソッド2002年9月にちびちび飲みます。
9 Security Considerations
9 セキュリティ問題
The security considerations for UPDATE are identical to those for re-INVITE. It is important that the UPDATE be integrity protected and authenticated as coming from the same source as the entity on the other end of the dialog. RFC 3261 [1] discusses security mechanisms for achieving these functions.
再INVITEに、UPDATEのためのセキュリティ問題はそれらと同じです。 UPDATEが対話のもう一方の端で実体と同じソースから来ると保護されて、認証された保全であることは重要です。 [1]がこれらの機能を獲得しながらセキュリティー対策について議論するRFC3261年。
10 IANA Considerations
10 IANA問題
As per Section 27.4 of RFC 3261 [1], this specification serves as a registration for the SIP UPDATE request method. The information to be added to the registry is:
RFC3261[1]のセクション27.4に従って、この仕様はSIP UPDATE要求メソッドのための登録として機能します。 登録に加えられるべき情報は以下の通りです。
RFC 3311: This specification serves as the RFC for registering
the UPDATE request method.
RFC3311: UPDATEを登録するためのRFCがメソッドを要求するとき、この仕様は役立ちます。
Method Name: UPDATE
メソッド名: アップデート
Reason Phrase: Not applicable.
句を推論してください: 適切でない。
11 Notice Regarding Intellectual Property Rights
11 知的所有権に関する通知
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
12 Normative References
12 標準の参照
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[4] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
Rosenberg Standards Track [Page 11] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[11ページ]RFC3311はアップデート方法2002年9月にちびちび飲みます。
13 Acknowledgements
13の承認
The author would like to thank Jo Hornsby, Markus Isomaki, Rohan Mahy, and Bob Penfield for their comments.
作者は彼らのコメントについてジョウ・ホーンスビー、マーカスIsomaki、Rohanマーイ、およびボブ・ペンフィールドに感謝したがっています。
14 Author's Address
14作者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Rosenberg Standards Track [Page 12] RFC 3311 SIP UPDATE Method September 2002
ローゼンバーグ標準化過程[12ページ]RFC3311はアップデート方法2002年9月にちびちび飲みます。
15 Full Copyright Statement
15 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg Standards Track [Page 13]
ローゼンバーグ標準化過程[13ページ]
一覧
スポンサーリンク
