RFC4028 日本語訳
4028 Session Timers in the Session Initiation Protocol (SIP). S.Donovan, J. Rosenberg. April 2005. (Format: TXT=65363 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Donovan
Request for Comments: 4028 J. Rosenberg
Category: Standards Track Cisco Systems
April 2005
コメントを求めるワーキンググループS.ドノヴァン要求をネットワークでつないでください: 4028年のJ.ローゼンバーグカテゴリ: 標準化過程シスコシステムズ2005年4月
Session Timers in the Session Initiation Protocol (SIP)
セッション開始プロトコルのセッションタイマ(一口)
Status of This 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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer.
このドキュメントはSession Initiationプロトコル(SIP)と拡大を定義します。 この拡張子は周期的にaを考慮します。再INVITEかUPDATE要求でSIPセッションをリフレッシュしてください。 リフレッシュしてください。ユーザエージェントとプロキシの両方が、SIPセッションがまだ活発であるかどうかと決心しているのを許容します。 拡大は2つの新しいヘッダーフィールドを定義します: セッションで期限が切れる、セッションタイマのために値が許容された最小限を伝えるセッション、およびMin-SEの生涯を伝える。
Donovan & Rosenberg Standards Track [Page 1] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. Session-Expires Header Field Definition . . . . . . . . . . 6
5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8
6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8
7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Generating an Initial Session Refresh Request . . . . 9
7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9
7.3. Processing a 422 Response . . . . . . . . . . . . . . 11
7.4. Generating Subsequent Session Refresh Requests . . . . 11
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Processing of Requests . . . . . . . . . . . . . . . . 13
8.2. Processing of Responses . . . . . . . . . . . . . . . 14
8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15
9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . 18
11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18
11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12.1. IANA Registration of Min-SE and Session-Expires
Header Fields . . . . . . . . . . . . . . . . . . . . 19
12.2. IANA Registration of the 422 (Session Interval Too
Small) Response Code . . . . . . . . . . . . . . . . . 20
12.3. IANA Registration of the 'timer' Option Tag . . . . . 20
13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . 3 3。 操作. . . . . . . . . . . . . . . . . . . 4 4の概観。 ヘッダーフィールド定義. . . . . . . . . . 6 5をセッションで吐き出します。 分-SEヘッダーフィールド定義. . . . . . . . . . . . . . . 8 6。 422 応答コード定義. . . . . . . . . . . . . . . . 8 7。 UACの振舞い. . . . . . . . . . . . . . . . . . . . . . . . 9 7.1。 初期のセッションを発生させて、要求. . . . 9 7.2をリフレッシュしてください。 2xx応答. . . . . . . . . . . . . . 9 7.3を処理します。 422応答. . . . . . . . . . . . . . 11 7.4を処理します。 その後のセッションを発生させて、要求. . . . 11 8をリフレッシュしてください。 プロキシの振舞い. . . . . . . . . . . . . . . . . . . . . . . 12 8.1。 要求. . . . . . . . . . . . . . . . 13 8.2の処理。 応答. . . . . . . . . . . . . . . 14 8.3の処理。 セッション満了. . . . . . . . . . . . . . . . . . 15 9。 UASの振舞い. . . . . . . . . . . . . . . . . . . . . . . . 15 10。 実行は.17 11をリフレッシュします。 セキュリティ問題. . . . . . . . . . . . . . . . . . 18 11.1。 中では、.18 11.2が攻撃されます。 外では、.19 12が攻撃されます。 IANA問題. . . . . . . . . . . . . . . . . . . . 19 12.1。 分-SEのIANA登録、ヘッダーフィールド. . . . . . . . . . . . . . . . . . . . 19 12.2をセッションで吐き出します。 422のもののIANA登録、(セッション間隔、あまりに小さい)、応答コード. . . . . . . . . . . . . . . . . 20 12.3 'タイマ'オプションタグ. . . . . 20 13のIANA登録。 例の呼び出し流動. . . . . . . . . . . . . . . . . . . . . 20 14。 承認. . . . . . . . . . . . . . . . . . . . . . 25 15。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 25 15.1。 引用規格. . . . . . . . . . . . . . . . . 25 15.2。 有益な参照. . . . . . . . . . . . . . . . 26作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . 26 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
1. 序論
The Session Initiation Protocol (SIP) [2] does not define a keepalive mechanism for the sessions it establishes. Although the user agents may be able to determine whether the session has timed out by using session specific mechanisms, proxies will not be able to do so. The result is that call stateful proxies will not always be able to determine whether a session is still active. For instance, when a user agent fails to send a BYE message at the end of a session, or when the BYE message gets lost due to network problems, a call stateful proxy will not know when the session has ended. In this situation, the call stateful proxy will retain state for the call and
Session Initiationプロトコル(SIP)[2]はそれが確立するセッションのためにkeepaliveメカニズムを定義しません。 ユーザエージェントは、セッションがセッションの特定のメカニズムを使用することによって時間があるかどうか決定できるかもしれませんが、プロキシはそうすることができないでしょう。 結果は呼び出しstatefulプロキシが、セッションがまだ活発であるかどうかいつも決定できるというわけではないということです。 例えば、ユーザエージェントがセッション、またはBYEメッセージがネットワーク問題のため失せるという場合にBYEメッセージを終わりに送らない場合、呼び出しstatefulプロキシは、セッションがいつ終わったかを知らないでしょう。 そしてこの状況で、呼び出しstatefulプロキシが呼び出しのための状態を保有する。
Donovan & Rosenberg Standards Track [Page 2] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[2ページ]。
has no method to determine when the call state information no longer applies.
呼び出し状態情報がいつもう適用されないかを決定する方法を全く持っていません。
To resolve this problem, this extension defines a keepalive mechanism for SIP sessions. UAs send periodic re-INVITE or UPDATE [3] requests (referred to as session refresh requests) to keep the session alive. The interval for the session refresh requests is determined through a negotiation mechanism defined here. If a session refresh request is not received before the interval passes, the session is considered terminated. Both UAs are supposed to send a BYE, and call stateful proxies can remove any state for the call.
この問題を解決するために、この拡大はSIPセッションのためにkeepaliveメカニズムを定義します。 UAsはセッションを生かすという要求(セッションに言及されて、要求をリフレッシュする)を周期的な再INVITEかUPDATE[3]に送ります。 セッションが要求をリフレッシュするので、間隔はここで定義された交渉メカニズムを通して決定します。 セッションがリフレッシュするなら、要求は間隔パスの前に受け取られないで、セッションは終えられると考えられます。 両方のUAsはBYEを送るべきです、そして、呼び出しstatefulプロキシは呼び出しのためにどんな状態も取り除くことができます。
This refresh mechanism has additional applications. A user agent would like to determine whether the session is still active for the same reasons a call stateful proxy server would. This determination can be made at a user agent without the use of SIP level mechanisms; for audio sessions, periodic RTCP packets serve as an indication of liveness [5]. However, it is desirable to separate indications of SIP session liveness from the details of the particular session.
これはメカニズムをリフレッシュします。追加アプリケーションを持っています。 ユーザエージェントは、セッションが呼び出しstatefulプロキシサーバがそうする同じ理由でまだ活発であるかどうかと決心したがっています。 ユーザエージェントでSIPの平らなメカニズムの使用なしでこの決断をすることができます。 オーディオセッションのために、周期的なRTCPパケットは活性[5]のしるしとして機能します。 しかしながら、特定のセッションの詳細とSIPセッション活性のしるしを切り離すのは望ましいです。
Another application of the session timer is in the construction of a SIP Network Address Translator (NAT) Application Level Gateway (ALG) [6]. The ALG embedded in a NAT will need to maintain state for the duration of a call. This state must eventually be removed. Relying on a BYE to trigger the removal of state, besides being unreliable, introduces a potential denial of service attack.
SIP Network Address Translator(NAT)アプリケーションLevelゲートウェイ(ALG)[6]の構造にはセッションタイマの別の利用があります。 NATに埋め込まれたALGは、呼び出しの持続時間のために状態を維持する必要があるでしょう。 結局、この状態を取り除かなければなりません。 さらに頼り無くて、状態の取り外しの引き金となるようにBYEを当てにすると、サービス攻撃の潜在的否定は導入されます。
This document provides an extension to SIP that defines a session expiration mechanism. Periodic refreshes, through re-INVITEs or UPDATEs, are used to keep the session active. The extension is sufficiently backward compatible with SIP that it works as long as either one of the two participants in a dialog understands the extension. Two new header fields (Session-Expires and Min-SE) and a new response code (422) are defined. Session-Expires conveys the duration of the session, and Min-SE conveys the minimum allowed value for the session expiration. The 422 response code indicates that the session timer duration was too small.
このドキュメントはセッション満了メカニズムを定義するSIPに拡大を供給します。 周期的である、再INVITEsかUPDATEsを通してリフレッシュして、セッションが能動態であることを保つのに使用されます。 拡大は対話の2人の関係者のどちらかが拡大を理解している限り、それが扱うSIPと互換性があった状態で十分後方です。 2の新しいヘッダーがさばく、(セッションで期限が切れる、Min-SE、)、a新しい応答コード(422)は定義されます。 セッションで期限が切れる、セッションの持続時間を伝える、Min-SEはセッション満了のために値が許容された最小限を伝えます。 422応答コードは、セッションタイマ持続時間が小さ過ぎたのを示します。
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 RFC 2119 [1] and indicate requirement levels for compliant SIP implementations.
'このドキュメント、キーワード'MUST'では、RFCで2119[1]について説明して、対応するSIP実現のために要件レベルを示すとき、NOTと、'''REQUIRED'、'SHALL'、'SHALL NOT'、'SHOULD'、'SHOULD NOT'、'RECOMMENDED'、'5月'、およびOPTIONAL'を解釈することになっていなければなりませんか?
Donovan & Rosenberg Standards Track [Page 3] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[3ページ]。
Additionally, we define the following terms:
さらに、私たちは次の用語を定義します:
Session Interval: The maximum amount of time that can occur between
session refresh requests in a dialog before the session will be
considered timed out. The session interval is conveyed in the
Session-Expires header field, which is defined here. The UAS
obtains this value from the Session-Expires header field in a 2xx
response to a session refresh request that it sends. Proxies and
UACs determine this value from the Session-Expires header field in
a 2xx response to a session refresh request that they receive.
セッション間隔: セッションが外で調節されていると考えられる前にそれがセッションの間に起こることができる最大の時間に対話における要求をリフレッシュしてください。 セッション間隔が運ばれる、ヘッダーフィールドをSession吐き出します。(それは、ここで定義されます)。 UASがこの値を得る、Session期限が切れる、セッションへのa2xx応答におけるヘッダーフィールドは発信するという要求をリフレッシュします。 プロキシとUACsがこの値を決定する、Session期限が切れる、セッションへのa2xx応答におけるヘッダーフィールドは彼らが受信するという要求をリフレッシュします。
Minimum Timer: Because of the processing load of mid-dialog requests,
all elements (proxy, UAC, UAS) can have a configured minimum value
for the session interval that they are willing to accept. This
value is called the minimum timer.
最小のタイマ: 中間の対話要求の処理負荷のために、すべての要素(プロキシ(UAC)UAS)が彼らが受け入れても構わないと思っているセッション間隔の間、構成された最小値を持つことができます。 この値は最小のタイマと呼ばれます。
Session Expiration: The time at which an element will consider the
session timed out, if no successful session refresh transaction
occurs beforehand.
セッション満了: 要素がセッションを考える時は外で調節されて、どんなうまくいっているセッションもリフレッシュしないなら、取引はあらかじめ、起こります。
Session Refresh Request: An INVITE or UPDATE request processed
according to the rules of this specification. If the request
generates a 2xx response, the session expiration is increased to
the current time plus the session interval obtained from the
response. A session refresh request is not to be confused with a
target refresh request, defined in Section 6 of [2], which is a
request that can update the remote target of a dialog.
セッションは要求をリフレッシュします: この仕様の規則に従って、INVITEかUPDATE要求が処理されました。 要求が2xx応答を発生させるなら、セッション満了は応答から得られた現在の時間とセッション間隔に増加します。 目標に混乱していないのが要求をリフレッシュするということであり、対話のリモート目標をアップデートできる要求である[2]のセクション6で定義されて、セッションは要求をリフレッシュします。
Initial Session Refresh Request: The first session refresh request
sent with a particular Call-ID value.
初期のセッションは要求をリフレッシュします: 最初のセッションは特定のCall-ID値と共に送られた要求をリフレッシュします。
Subsequent Session Refresh Request: Any session refresh request sent
with a particular Call-ID after the initial session refresh
request.
その後のセッションは要求をリフレッシュします: どんなセッションも初期のセッションが要求をリフレッシュした後に特定のCall-IDと共に送られた要求をリフレッシュします。
Refresh: Same as a session refresh request.
リフレッシュします: セッションと同じことは要求をリフレッシュします。
3. Overview of Operation
3. 操作の概観
This section provides a brief overview of the operation of the extension. It is tutorial in nature and should not be considered normative.
このセクションは拡大の操作の簡潔な概観を提供します。 それを現実に家庭教師であり、規範的であると考えるべきではありません。
This extension has the property that it works even when only one UA in a dialog supports it. The processing steps differ for handling each of the four cases (the UAC does or doesn't support it, and the UAS does or doesn't support it). For simplicity's sake, this section
この拡大には、対話における1UAだけがそれを支持すると、それが扱う特性があります。 処理ステップはそれぞれ4つのケースの取り扱いのために異なります(UACがするか、またはそれを支持しないで、UASはするか、またはそれを支持しません)。 簡単さの酒、このセクションに
Donovan & Rosenberg Standards Track [Page 4] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[4ページ]。
will describe basic operation in the case where both sides support the extension.
両側が拡大を支持する場合で基本的な操作について説明するでしょう。
A UAC starts by sending an INVITE. This includes a Supported header field with the option tag 'timer', indicating support for this extension.
UACは、INVITEを送ることによって、始まります。 この拡大のサポートを示して、これはオプションタグ'タイマ'があるSupportedヘッダーフィールドを含んでいます。
This request passes through proxies, any one of which may have an interest in establishing a session timer. Each proxy can insert a Session-Expires header field and a Min-SE header field into the request (if none is already there) or alter the value of existing Session-Expires and Min-SE header fields as described below.
この要求はプロキシ、それの1つがセッションタイマを設立するのに関心を持っているかもしれないいずれも通り抜けます。 aが存在しながら要求(なにも既にそこにないなら)へのヘッダーフィールドとMin-SEヘッダーフィールドをSession吐き出すか、または値を変更するそれぞれのプロキシ缶の差し込みはSession呼吸が絶えます、そして、Min-SEヘッダーは説明されるとして下をさばきます。
The Min-SE header field establishes the lower bound for the session refresh interval; i.e., the fastest rate any proxy servicing this request will be allowed to require. The purpose of this header field is to prevent hostile proxies from setting arbitrarily short refresh intervals so that their neighbors are overloaded. Each proxy processing the request can raise this lower bound (increase the period between refreshes) but is not allowed to lower it.
セッションのために縛られて、ヘッダーフィールドが、より低く設立するMin-SEは間隔をリフレッシュします。 すなわち、この要求を修理するどんなプロキシも必要であることができる中で最も速いレート。 このヘッダーフィールドの目的は敵対的なプロキシが任意に急にセットするのを防ぐために、間隔をリフレッシュしてください。そうすれば、彼らの隣人が積みすぎられるということです。 要求を処理する各プロキシは、この下界(増加は間の期間にリフレッシュする)を上げることができますが、それを下ろすことができません。
The Session-Expires header field establishes the upper bound for the session refresh interval; i.e., the time period after processing a request for which any session-stateful proxy must retain its state for this session. Any proxy servicing this request can lower this value, but it is not allowed to decrease it below the value specified in the Min-SE header field.
Session期限が切れる、セッションが間隔をリフレッシュするので、ヘッダーフィールドは上限を確立します。 すなわち、要求を処理した後のどんなセッション-statefulプロキシもそうしなければならない期間に、このセッションのために状態を保有してください。 この要求を修理するどんなプロキシもこの値を下げることができますが、それはそれをMin-SEヘッダーフィールドで指定された値より下であるまで減少させることができません。
If the Session-Expires interval is too low for a proxy (i.e., lower than the value of Min-SE that the proxy would wish to assert), the proxy rejects the request with a 422 response. That response contains a Min-SE header field identifying the minimum session interval it is willing to support. The UAC will try again, this time including the Min-SE header field in the request. The header field contains the largest Min-SE header field it observed in all 422 responses previously received. This way, the minimum timer meets the constraints of all proxies along the path.
間隔をSession吐き出す、プロキシには低過ぎます(すなわち、プロキシが断言したがっているMin-SEの値より低い)、プロキシは422応答で要求を拒絶します。 その応答はそれが支持しても構わないと思っている最小のセッション間隔を特定するMin-SEヘッダーフィールドを含んでいます。 UACは再び、この時に要求にMin-SEヘッダーフィールドを含んでみるでしょう。 ヘッダーフィールドは以前に受けられたすべての422の応答で観測した中で最も大きいMin-SEヘッダーフィールドを含んでいます。 このように、最小のタイマは経路に沿ったすべてのプロキシの規制を満たします。
After several INVITE/422 iterations, the request eventually arrives at the UAS. The UAS can adjust the value of the session interval as if it were a proxy; when done, it places the final session interval into the Session-Expires header field in a 2xx response. The Session-Expires header field also contains a 'refresher' parameter, which indicates who is doing the refreshing -- the UA that is currently the UAC, or the UA that is currently the UAS. As the 2xx response travels back through the proxy chain, each proxy can observe the final session interval but can't change it.
いくつかのINVITE/422繰り返しの後に、要求は結局、UASに到着します。 UASはまるでそれがプロキシであるかのようにセッション間隔の値を調整できます。 していて、いつまで最後のセッション間隔を置くか、2xx応答におけるヘッダーフィールドをSession吐き出します。 Session期限が切れる、また、ヘッダーフィールドはだれがリフレッシュしているかを示す'酒'パラメタを含んでいます--現在UACであるUA、または現在UASであるUA。 2xx応答がプロキシチェーンを通って移動するのに従って、各プロキシは、最後のセッション間隔を観測できますが、それを変えることができません。
Donovan & Rosenberg Standards Track [Page 5] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[5ページ]。
From the Session-Expires header field in the response, both UAs know that a session timer is active, when it will expire, and who is refreshing. At some point before the expiration, the currently active refresher generates a session refresh request, which is a re-INVITE or UPDATE [3] request. If the refresher never gets a response to that session refresh request, it sends a BYE to terminate the session. Similarly, if the other side never gets the session refresh request before the session expires, it sends a BYE.
Session期限が切れる、応答におけるヘッダーフィールド、両方のUAsは期限が切れるとき、セッションタイマがアクティブであり、だれが壮快であるかを知っています。 満了、現在アクティブな酒がセッションを発生させる前の何らかのポイントでは、要求をリフレッシュしてください。(それは、再INVITEかUPDATE[3]要求です)。 酒がそのセッションへの応答を決して得ないなら、要求をリフレッシュしてください、そして、それは、セッションを終えるためにBYEを送ります。 反対側がセッションを決して得ないなら、セッションが期限が切れる前に同様に、要求をリフレッシュしてください、そして、それはBYEを送ります。
The refresh requests sent once the session is established are processed identically to the initial requests, as described above. This means that a successful session refresh request will extend the session, as desired.
セッションがいったん確立される後送られた要求をリフレッシュしてください。同様に説明されるとして上で初期の要求に処理されます。 うまくいっているセッションがリフレッシュするこの手段は、望まれているように会期を延長するために望むよう要求します。
The extension introduces additional complications beyond this basic flow to support cases where only one of the UAs supports it. One such complication is that a proxy may need to insert the Session-Expires header field into the response, in the event that the UAS doesn't support the extension. The negotiation of the role of refresher is also affected by this capability; it takes into consideration which participants support the extension.
拡大はUAsの唯一のひとりがそれを支持するサポートケースにこの基本的な流れを超えた追加複雑さを紹介します。 そのような複雑さの1つがaプロキシが差し込みに必要とするかもしれないということである、UASが拡大を支持しない場合、応答へのヘッダーフィールドをSession吐き出します。 また、酒の役割の交渉はこの能力で影響を受けます。 それはそれの関係者が拡大を支持する考慮を連れていきます。
Note that the session timer refreshes the session, not the dialog used to establish the session. Of course, the two are related. If the session expires, a BYE is sent, which terminates the session and, generally, the dialog.
セッションタイマがセッションを証明するのに使用される対話ではなく、セッションをリフレッシュすることに注意してください。 もちろん、2は関係づけられます。 セッションが期限が切れるなら、BYE(セッションと一般に対話を終える)を送ります。
4. Session-Expires Header Field Definition
4. ヘッダーフィールド定義をセッションで吐き出します。
The Session-Expires header field conveys the session interval for a SIP session. It is placed only in INVITE or UPDATE requests, as well as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires header field, it contains a delta-time.
分野がセッション間隔を運ぶヘッダーをSession吐き出す、SIPセッション。 それはINVITEかUPDATE要求だけ、およびINVITEかUPDATEへのどんな2xx応答にも置かれます。 SIP Expiresヘッダーフィールドのように、それはデルタ時間を含んでいます。
The absolute minimum for the Session-Expires header field is 90 seconds. This value represents a bit more than twice the duration that a SIP transaction can take in the event of a timeout. This allows sufficient time for a UA to attempt a refresh at the halfpoint of the session interval, and for that transaction to complete normally before the session expires. However, 1800 seconds (30 minutes) is RECOMMENDED as the value for the Session-Expires header field. In other words, SIP entities MUST be prepared to handle Session-Expires header field values of any duration greater than 90 seconds, but entities that insert the Session-Expires header field SHOULD NOT choose values of less than 30 minutes.
絶対最小値、ヘッダーフィールドをSession吐き出す、90秒はそうです。 この値はSIP取引がタイムアウトの場合、取ることができる持続時間の2倍余りを表します。 これはaを試みるa UAがセッション間隔のhalfpointでリフレッシュして、セッションが期限が切れる前に通常、完了するその取引のための十分な時間を許容します。 しかしながら、1800秒(30分)が値としてRECOMMENDEDである、ヘッダーフィールドをSession吐き出します。 言い換えれば、扱うように実体を準備しなければならないSIPが90秒以上のどんな持続時間のヘッダーフィールド値もSession吐き出して、唯一の実体がその差し込みである、SHOULD NOTが30分未満の値を選ぶヘッダーフィールドをSession吐き出します。
Donovan & Rosenberg Standards Track [Page 6] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[6ページ]。
Small session intervals can be destructive to the network. They cause excessive messaging traffic that affects both user agents and proxy servers. They increase the possibility of 'glare' that can occur when both user agents send a re-INVITE or UPDATE at the same time. Since the primary purpose of the session timer is to provide a means to time out state in SIP elements, very small values won't generally be needed. 30 minutes was chosen because 95% of phone calls are shorter than this duration. However, the 30 minute minimum is listed as a SHOULD, and not as a MUST, since the exact value for this number is dependent on many network factors, including network bandwidths and latencies, computing power, memory availability, network topology, and, of course, the application scenario. After all, SIP can set up any kind of session, not just a phone call. At the time of publication of this document, 30 minutes seems appropriate. Advances in technologies may result in the number being excessively large five years in the future.
小さいセッション間隔はネットワークに破壊的である場合があります。 彼らはユーザエージェントとプロキシサーバの両方に影響する過度のメッセージング交通を引き起こします。 それらは両方のユーザエージェントが同時に再INVITEかUPDATEを送るとき起こることができる'ギラギラと眩しい光'の可能性を増加させます。 セッションタイマの第一の目的がSIP要素のタイムアウト状態に手段を提供することであるので、一般に、非常に小さい値は必要でないでしょう。 95%の電話がこの持続時間より短いので、30分は選ばれました。 しかしながら、aがそうしなければならない正確な値として記載されているのではなく、この数が多くのネットワーク要素に依存しているので、30分の最小限はSHOULDとして記載されています、ネットワーク回線容量と潜在を含んでいて、パワー、メモリの有用性、ネットワーク形態、およびもちろんアプリケーションシナリオを計算して。 結局、SIPは電話だけではなく、どんな種類のセッションもセットアップできます。 このドキュメントの公表時点で、30分は適切に見えます。 技術における進歩は将来5年間過度に大きい数をもたらすかもしれません。
The default value of the Session-Expires header field is undefined. This means that the absence of the Session-Expires header field implies no expiration of the session, using the mechanism defined in this specification. Note that other mechanisms not defined in this specification, such as locally configured timers, may apply.
デフォルト値、ヘッダーフィールドをSession吐き出す、未定義です。 これがそれを意味する、不在、セッションの満了を全く含意しないで、この仕様に基づき定義されたメカニズムを使用することでヘッダーフィールドをSession吐き出します。 この仕様に基づき定義されなかった局所的に構成されたタイマなどの他のメカニズムが適用されるかもしれないことに注意してください。
The syntax of the Session-Expires header field is as follows:
構文、ヘッダーフィールドをSession吐き出す、以下の通りです:
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
ジェネリック-param酒-param==(/「x」を「セッションで吐き出す」)HCOLONデルタ秒*(SEMI se-params)se-params=酒-param/「酒」EQUALをセッションで吐き出します。("uas"/"uac")
Note that a compact form, the letter x, has been reserved for Session-Expires. The BNF for delta-seconds and generic-param is defined in Section 25 of RFC 3261 [2].
コンパクト形(文字x)が予約された注意はSession期限が切れます。 デルタ秒とジェネリック-paramのためのBNFはRFC3261[2]のセクション25で定義されます。
Table 1 is an extension of Tables 2 and 3 in [2] for the Session-Expires and Min-SE header fields. The column 'PRA' is for the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8].
テーブル1が[2]でのTables2と3の拡大である、Session期限が切れる、そして、Min-SEヘッダーフィールド。 'PRACKに関して、方法[7]、'UPD'はUPDATE方法[3]のためのものです、'SUBということです'というコラム'PRAがいる、登録、方法[8]、および'NOT'はNOTIFY方法[8]のためのそうです。
Donovan & Rosenberg Standards Track [Page 7] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[7ページ]。
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - | +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ | ヘッダー|どこ|プロキシ|ACK|さようなら|缶|INV|選んでください。|レッジ|PRA|UPD|潜水艦|NOT| +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ |セッションで期限が切れます。| R| amr| - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |セッションで期限が切れます。| 2xx| ar| - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |分-SE| R| amr| - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |分-SE| 422 | | - | - | - | m| - | - | - | m| - | - | +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
Table 1: Session-Expires and Min-SE Header Fields
テーブル1: セッションで期限が切れる、分-SEヘッダーフィールド
5. Min-SE Header Field Definition
5. 分-SEヘッダーフィールド定義
The Min-SE header field indicates the minimum value for the session interval, in units of delta-seconds. When used in an INVITE or UPDATE request, it indicates the smallest value of the session interval that can be used for that session. When present in a request or response, its value MUST NOT be less than 90 seconds.
Min-SEヘッダーフィールドはユニットのデルタ秒にセッション間隔の間、最小値を示します。 INVITEかUPDATE要求で使用されると、それはそのセッションのために費やすことができるセッション間隔の最も小さい値を示します。 要求か応答で存在しているとき、値は90秒未満であるはずがありません。
When the header field is not present, its default value for is 90 seconds.
いつの間、ヘッダーフィールドがプレゼント、デフォルト値でないか、90秒はそうです。
The Min-SE header field MUST NOT be used in responses except for those with a 422 response code. It indicates the minimum value of the session interval that the server is willing to accept.
422応答コードでそれら以外の応答にMin-SEヘッダーフィールドを使用してはいけません。 それはサーバが受け入れても構わないと思っているセッション間隔の最小値を示します。
The syntax of the Min-SE header field is as follows:
Min-SEヘッダーフィールドの構文は以下の通りです:
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
分-SEは「分-SE」HCOLONデルタ秒*と等しいです。(SEMIジェネリック-param)
6. 422 Response Code Definition
6. 422 応答コード定義
This extension introduces the 422 (Session Interval Too Small) response code. It is generated by a UAS or proxy when a request contains a Session-Expires header field with a duration below the minimum timer for the server. The 422 response MUST contain a Min-SE header field with the minimum timer for that server.
この拡大は422(セッションInterval Too Small)応答コードを紹介します。 それがUASによって発生するか、または要求がaを含んでいると、プロキシはサーバのための最小のタイマの下に持続時間があるヘッダーフィールドをSession吐き出します。422応答はそのサーバのための最小のタイマがあるMin-SEヘッダーフィールドを含まなければなりません。
Donovan & Rosenberg Standards Track [Page 8] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[8ページ]。
7. UAC Behavior
7. UACの振舞い
7.1. Generating an Initial Session Refresh Request
7.1. 初期のセッションを発生させて、要求をリフレッシュしてください。
A UAC that supports the session timer extension defined here MUST include a Supported header field in each request (except ACK), listing the option tag 'timer' [2]. It MUST do so even if the UAC is not requesting usage of the session timer for this session.
ここで定義されたセッションタイマ延期を支持するUACは各要求(ACKを除いた)にSupportedヘッダーフィールドを含まなければなりません、オプションタグ'タイマ'[2]を記載して。 UACがこのセッションのためのセッションタイマの使用法を要求していなくても、それはそうしなければなりません。
The UAC MAY include a Require header field in the request with the value 'timer' to indicate that the UAS must support the session timer to participate in the session. This does not mean that the UAC is requiring the UAS to perform the refreshes, only that it is requiring the UAS to support the extension. In addition, the UAC MAY include a Proxy-Require header field in the request with the value 'timer' to indicate that proxies must support the session timer in order to correctly process the request. However, usage of either Require or Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, since the extension works even when only the UAC supports the extension. The Supported header field containing 'timer' MUST still be included, even if the Require or Proxy-Require header fields are present containing 'timer'.
UAC MAYは、UASがセッションのときに参加するためにセッションタイマを支えなければならないのを示すために値の'タイマ'による要求にRequireヘッダーフィールドを含んでいます。 これが、UACが、UASが働くのを必要としていることを意味しない、リフレッシュする、拡大を支持するのがUASを必要としているだけです。 さらに、UAC MAYはaを含んでいます。値の'タイマ'による要求におけるヘッダーフィールドが、プロキシが正しく要求を処理するためにセッションタイマを支えなければならないのを示すのをProxy必要であってください。 しかしながら、Requireの使用法、UACによるProxy必要である、NOT RECOMMENDEDはそうです。 UACだけが拡大を支持すると拡大が働くので、それらは必要ではありません。 ヘッダーをProxy必要としてください。または、まだ'タイマ'を含むSupportedヘッダーフィールドを含まなければならない、Require、'タイマ'を含んでいて、分野は存在しています。
A UAC MAY include the Min-SE header field in the initial INVITE request.
UAC MAYは初期のINVITE要求にMin-SEヘッダーフィールドを含んでいます。
A UAC MAY include a Session-Expires header field in an initial session refresh request if it wants a session timer applied to the session. The value of this header field indicates the session interval desired by the UAC. If a Min-SE header is included in the initial session refresh request, the value of the Session-Expires MUST be greater than or equal to the value in Min-SE.
aは初期のセッションにおける分野がリフレッシュするヘッダーをSession吐き出します。A UAC MAYが含んでいる、セッションタイマをセッションに適用して欲しいなら、要求します。 このヘッダーフィールドの値はUACによって望まれていたセッション間隔を示します。 Min-SEヘッダーが初期のセッションが要求、値をリフレッシュする含まれているコネである、Session期限が切れる、より多くのでなければならないMin-SEの値。
The UAC MAY include the refresher parameter with value 'uac' if it wants to perform the refreshes. However, it is RECOMMENDED that the parameter be omitted so that it can be selected by the negotiation mechanisms described below.
働きたいならUAC MAYが値の'uac'がある酒のパラメタを含んでいる、リフレッシュします。 しかしながら、以下で説明された交渉メカニズムがそれを選択できるようにパラメタが省略されるのは、RECOMMENDEDです。
7.2. Processing a 2xx Response
7.2. 2xx応答を処理します。
The session timer requires a UA to create and maintain state. This state includes the session interval, the session expiration, and the identity of the refresher. This state is associated with the dialog on which the session has been negotiated.
セッションタイマは、UAが状態を創設して、維持するのを必要とします。 この州はセッション間隔、セッション満了、および酒のアイデンティティを含めます。 この状態はセッションが交渉された対話に関連しています。
Donovan & Rosenberg Standards Track [Page 9] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[9ページ]。
When a 2xx response to a session refresh request arrives, it may or may not contain a Require header field with the value 'timer'. If it does, the UAC MUST look for the Session-Expires header field to process the response.
セッションへの2xx応答がリフレッシュするとき、要求は到着して、それは値の'タイマ'があるRequireヘッダーフィールドを含むかもしれません。 そうするなら、UAC MUSTが見る、応答を処理するヘッダーフィールドをSession吐き出します。
If there was a Require header field in the response with the value 'timer', the Session-Expires header field will always be present. UACs MUST be prepared to receive a Session-Expires header field in a response, even if none were present in the request. The 'refresher' parameter will be present in the Session-Expires header field, indicating who will perform the refreshes. The UAC MUST set the identity of the refresher to the value of this parameter. If the parameter contains the value 'uac', the UAC will perform them. It is possible that the UAC requested the session timer (and thus included a Session-Expires header field in the request) and that there was no Require or Session-Expires header field in the 2xx response. This will happen when the UAS doesn't support the session timer extension and only the UAC has asked for a session timer (no proxies have requested it). In this case, if the UAC still wishes to use the session timer (which is purely for its benefit alone), it has to perform them. To do this, the UAC follows the procedures defined in this specification as if the Session-Expires header field were in the 2xx response, and its value was the same as that in the request, but with a refresher parameter of 'uac'.
値の'タイマ'による応答にRequireヘッダーフィールドがあったなら分野がいつもそうするヘッダーをSession吐き出す、存在してください。 UACsによる受信するように準備されて、aは応答におけるヘッダーフィールドをSession吐き出します、なにも要求に存在していなかったとしてもことでなければなりません。 '酒'パラメタが現在、ヘッダーフィールドをSession吐き出す、だれが働くかを示す、リフレッシュします。 UAC MUSTはこのパラメタの値に酒のアイデンティティを設定します。 パラメタが値の'uac'を含んでいると、UACはそれらを実行するでしょう。 2xx応答におけるヘッダーフィールドがUACがセッションタイマを要求して(このようにして含まれていて、aは要求におけるヘッダーフィールドをSession吐き出します)、RequireでなかったSession期限が切れるのが、可能です。 UASがセッションタイマ延期を支持しないで、UACだけがセッションタイマを求めたとき(どんなプロキシもそれを要求していません)、これは起こるでしょう。 この場合、UACがまだ、セッションタイマ(単独で純粋な利益のためのものである)を使用していたいと思うなら、それはそれらを実行しなければなりません。 これをするために、UACがこの仕様に基づき定義された手順に従う、Session期限が切れる、ヘッダーフィールドが2xx応答中であり、値は、要求におけるそれと同じでしたが、'uac'の酒のパラメタで同じでした。
If the 2xx response did not contain a Session-Expires header field, there is no session expiration. In this case, no refreshes need to be sent. A 2xx without a Session-Expires can come for both initial and subsequent session refresh requests. This means that the session timer can be 'turned-off' in mid dialog by receiving a response without a Session-Expires header field.
2xx応答が含まなかった、aはヘッダーフィールドをSession吐き出して、セッション満了が全くありません。 この場合、いいえは送られるべき必要性をリフレッシュします。 aのない2xxはともに初期で取りに来られた缶をSession吐き出します、そして、その後のセッションは要求をリフレッシュします。 これが、中間の対話で応答を受けることによってセッションタイマを'オフにすることができること'を意味する、aはヘッダーフィールドをSession吐き出します。
The UAC remembers the session interval for a session as the value of the delta-time from the Session-Expires header field in the most recent 2xx response to a session refresh request on a dialog. It is explicitly allowed for there to be differing session intervals (or none at all) on differing dialogs established as a result of a single INVITE. The UAC also remembers whether it or its peer is the refresher on for the session.
UACがデルタ現代の値としてのセッションのためのセッション間隔を覚えている、aへのセッションが要求をリフレッシュする最新の2xx応答におけるヘッダーフィールドをSession吐き出す、対話。 それは、独身のINVITEの結果、確立された異なった対話の異なったセッション間隔(または、全くなにも)になるように明らかにそこを考慮されます。 また、UACは、それかその同輩がセッションのためにオンな酒であるかどうかを覚えています。
If the UAC must perform the refreshes, it computes the session expiration for that session. The session expiration is the time of reception of the last 2xx response to a session refresh request on that dialog plus the session interval for that session. If the UA seeks to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is
UACが働かなければならない、リフレッシュする、それはそのセッションのためにセッション満了を計算します。 セッション満了はセッションへの最後の2xx応答のレセプションの時間がそのセッションのためにその対話とセッション間隔に関する要求をリフレッシュするということです。 UAがセッション満了を超えてセッションを続行しようとするなら、それは発生しなければなりません。aはセッション満了の前にリフレッシュします。 それはそうです。
Donovan & Rosenberg Standards Track [Page 10] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[10ページ]。
RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10.
これはリフレッシュします。RECOMMENDED、それ、セッション間隔が持っている半分がいったん経過すると、送ります。 これがリフレッシュするので、追加手順はセクション10で説明されます。
Similarly, a re-INVITE or UPDATE request sent within a dialog for purposes other than session refreshes will also have the effect of refreshing the session, and its processing will follow the procedures defined in this specification.
また、同様に、再INVITEか送って、中では、セッション以外の目的のための対話がリフレッシュするというUPDATE要求には、セッションをリフレッシュするという効果があるでしょう、そして、処理がこの仕様に基づき定義された手順に従うでしょう。
7.3. Processing a 422 Response
7.3. 422応答を処理します。
If the response to a session refresh request is a 422 (Session Interval Too Small) response message, then the UAC MAY retry the request. The procedures for retrying are described in Section 7.4. This new request constitutes a new transaction and SHOULD have the same value as the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous.
セッションへの応答がリフレッシュするなら要求が422(セッションInterval Too Small)応答メッセージである、そして、UAC MAYは要求を再試行します。 再試行するための手順はセクション7.4で説明されます。 この新しい要求は新しい取引を構成します、そして、SHOULDには、前の要求のCall-ID、To、およびFromと同じ値がありますが、CSeqは前であるより高く1である新しい一連番号を含むはずです。
7.4. Generating Subsequent Session Refresh Requests
7.4. その後のセッションを発生させて、要求をリフレッシュしてください。
The values of Supported, Require, and Proxy-Require used in the initial Session refresh request MUST be used.
初期Sessionがリフレッシュする中古のコネをProxy必要としてください。そして、Supportedの値、Require、要求を使用しなければなりません。
The UAC MUST insert the Min-SE header field into a session refresh request for a particular dialog if it has ever received a 422 response to a previous session refresh request on the same dialog, or if it has received a session refresh request on that dialog that contained a Min-SE header field. Similarly, if no dialog has been established yet, a UAC MUST insert the Min-SE header field into an INVITE request if it has ever received a 422 response to a previous INVITE request with the same Call-ID.
セッションまでのMin-SEヘッダーフィールドがリフレッシュするUAC MUST差し込みが、特定の対話のために今までに前のセッションへの422応答を受けたことがあるなら同じ対話に関する要求をリフレッシュするよう要求するか、または受信したなら、セッションはMin-SEヘッダーフィールドを含んだその対話に関する要求をリフレッシュします。 同様に、今までに、同じCall-IDとの前のINVITE要求への422応答を受けたことがあって、対話が全くまだ確立されていないなら、UAC MUSTはMin-SEヘッダーフィールドをINVITE要求に挿入します。
The value of the Min-SE header field present in a session refresh request MUST be the largest value among all Min-SE header field values returned in all 422 responses or received in session refresh requests, on the same dialog, if a dialog has been established. If no dialog has been established, the Min-SE header field value is set to the largest value among all Min-SE header field values returned in all 422 responses for an INVITE request with the same Call-ID. A result of this rule is that the maximum value of the Min-SE is effectively 'cleared' once the dialog is established, and from that point on, only the values from proxies known to be on the proxy path will end up being used.
セッションの現在のMin-SEヘッダーフィールドの値はすべての422の応答で返されたかセッションのときに受け取られていている値がリフレッシュするすべてのMin-SEヘッダーフィールドの中の最も大きい値が要求でなければならなかったなら要求をリフレッシュします、同じ対話で、対話が確立されたなら。 対話が全く確立されていないなら、Min-SEヘッダーフィールド価値は同じCall-IDとのINVITE要求のためにすべての422の応答で返されたすべてのMin-SEヘッダーフィールド値の中の最も大きい値へのセットです。 この規則の結果は対話がいったん確立されると事実上、Min-SEの最大値が'クリアされ'て、そのポイントから、結局プロキシ道にあるのが知られているプロキシからの値だけによって使用されるということです。
The UAC may have its own opinions about the minimum session interval. In that case, if the value above is too small, the UAC MAY increase it.
UACには、最小のセッション間隔頃に、それ自身の意見があるかもしれません。 その場合、上の値が小さ過ぎるなら、UAC MAYはそれを増加させます。
Donovan & Rosenberg Standards Track [Page 11] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[11ページ]。
In a session refresh request sent within a dialog with an active session timer, the Session-Expires header field SHOULD be present. When present, it SHOULD be equal to the maximum of the Min-SE header field (recall that its default value when not present is 90 seconds) and the current session interval. Inclusion of the Session-Expires header field with this value avoids certain denial-of-service attacks, as documented in Section 11. As such, a UA should only ignore the SHOULD in unusual and singular cases where it is desirable to change the session interval mid-dialog.
セッションのときに対話の中でアクティブなセッションタイマで送られた要求をリフレッシュしてください、ヘッダー分野SHOULDをSession吐き出す、存在してください。 存在しているときそれ、SHOULD、Min-SEヘッダーフィールド(存在していないとき、デフォルト値が90秒であると思い出す)と現在のセッション間隔の最大と等しくいてください。 包含、この値がある分野が記録されるとしてのあるサービス不能攻撃を避けるヘッダーをSession吐き出す、セクション11 そういうものとして、UAはセッションの間隔の中間の対話を変えるのが望ましい珍しくてまれな場合でSHOULDを無視するだけであるはずです。
If the session refresh request is not the initial one, it is RECOMMENDED that the refresher parameter be set to 'uac' if the element sending the request is currently performing refreshes, and to 'uas' if its peer is performing the refreshes. This way, the role of refresher does not change on each refresh. However, if it wishes to explicitly change the roles, it MAY use a value of 'uas' if it knows that the other side supports the session timer. It could know this by having received a request from its peer with a Supported header field containing the value 'timer'. If it seeks to reselect the roles, it MAY omit the parameter.
セッションがリフレッシュするなら要求が初期のものでない、要求が現在実行している要素発信がリフレッシュして、'uas'にそうするなら同輩が働いているなら酒のパラメタが'uacする'ように設定されるのが、RECOMMENDEDである、リフレッシュします。 この道、酒の役割はそれぞれで変化しません。リフレッシュしてください。 しかしながら、明らかに役割を変えたいなら、反対側がセッションタイマを支えるのを知っているなら、それは'uas'の値を使用するかもしれません。 それは、Supportedヘッダーフィールドが値の'タイマ'を含んでいる同輩から要求を受け取ったことによって、これを知るかもしれません。 reselectに役割を求めるなら、それはパラメタを省略するかもしれません。
A re-INVITE generated to refresh the session is a normal re-INVITE, and an UPDATE generated to refresh a session is a normal UPDATE. If a UAC knows that its peer supports the UPDATE method, it is RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can make this determination if it has seen an Allow header field from its peer with the value 'UPDATE', or through a mid-dialog OPTIONS request. It is RECOMMENDED that the UPDATE request not contain an offer [4], but a re-INVITE SHOULD contain one, even if the details of the session have not changed. In that case, the offer MUST indicate that it has not changed. In the case of SDP, this is accomplished by including the same value for the origin field as did previous SDP messages to its peer. The same is true for an answer exchanged as a result of a session refresh request; if it has not changed, that MUST be indicated.
セッションをリフレッシュするために発生する再INVITEは正常な再INVITEです、そして、セッションをリフレッシュするために発生するUPDATEは正常なUPDATEです。 UACが、同輩がUPDATE方法を支持するのを知っているなら、UPDATEが再INVITEの代わりに使用されるのは、RECOMMENDEDです。 UAは値の'UPDATE'、または、OPTIONSが要求する中間の対話を通して同輩からAllowヘッダーフィールドを見たならこの決断をすることができます。 申し出[4]を含んでいるのではなく、含んでいるUPDATEが再INVITE SHOULDを要求するRECOMMENDEDは1つを含んでいます、セッションの詳細が変化していなくてもことです。 その場合、申し出は、それが変化していないのを示さなければなりません。 SDPの場合では、これは、同輩への前のSDPメッセージのように起源分野に同じ値を含んでいることによって、達成されます。 セッションの結果が要求をリフレッシュするので交換された答えに、同じくらいは本当です。 変化していないなら、それを示さなければなりません。
8. Proxy Behavior
8. プロキシの振舞い
Session timers are mostly of interest to call stateful proxy servers (that is, to servers that maintain the state of calls and dialogs established through them). However, a stateful proxy server (that is, a server which is aware of transaction state but does not retain call or dialog state) MAY also follow the rules described here. Stateless proxies MUST NOT attempt to request session timers. Proxies that ask for session timers SHOULD record-route, as they won't receive refreshes if they don't.
セッションタイマは、statefulプロキシサーバ(すなわち、呼び出しの状態を維持するサーバとそれらを通して確立された対話への)と呼ぶためにほとんど興味があります。 しかしながら、また、statefulプロキシサーバ(すなわち、取引状態を知っていますが、呼び出しか対話状態を保有しないサーバ)はここで説明された規則に従うかもしれません。 国がないプロキシは、セッションタイマを要求するのを試みてはいけません。 リフレッシュしないなら、SHOULDが記録して発送するセッションタイマ受信しないとき、尋ねるプロキシがリフレッシュします。
Donovan & Rosenberg Standards Track [Page 12] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[12ページ]。
The proxy processing rules require the proxy to remember
information between the request and response, ruling out stateless
proxies.
プロキシ処理規則は、国がないプロキシを除外して、プロキシが要求と応答の間の情報を覚えているのを必要とします。
8.1. Processing of Requests
8.1. 要求の処理
Processing of requests is identical for all session refresh requests.
すべてのセッションが要求をリフレッシュするので、要求の処理は同じです。
To request a session timer for a session, a proxy makes sure that a Session-Expires header field is present in a session refresh request for that session. A proxy MAY insert a Session-Expires header field in the request before forwarding it if none was present in the request. This Session-Expires header field may contain any desired expiration time the proxy would like, but not with a duration lower than the value in the Min-SE header field in the request, if it is present. The proxy MUST NOT include a refresher parameter in the header field value.
セッション、aプロキシ造のためにセッションタイマを要求するために、aがヘッダーフィールドをSession吐き出すのを確信しているのは、セッションにおけるプレゼントがそのセッションを求める要求をリフレッシュするということです。 プロキシはaを挿入するかもしれません。なにも要求に存在していなかったならそれを進める前の要求におけるヘッダーフィールドをSession吐き出します。 これは分野がプロキシが必要とする必要な満了何時でも含んでいますが、持続時間が値より低い状態で含むかもしれないというわけではないMin-SEヘッダーが要求でさばくヘッダーをSession吐き出します、それが存在しているなら。 プロキシはヘッダーフィールド値で酒のパラメタを入れてはいけません。
If the request already had a Session-Expires header field, the proxy MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present. If the value of the Session-Expires header field is greater than or equal to the value in the Min-SE header field (recall that the default is 90 seconds when the Min-SE header field is not present), the proxy MUST NOT increase the value of the Session-Expires header field. If the value of the Session-Expires header field is lower than the value of the Min-SE header field (possibly because the proxy increased the value of the Min-SE header field, as described below), the proxy MUST increase the value of the Session-Expires header field to make it equal to Min-SE header field value. The proxy MUST NOT insert or modify the value of the 'refresher' parameter in the Session-Expires header field.
要求が既にそうするならaがヘッダーフィールドをSession吐き出して、プロキシは、値を減少させるかもしれませんが、要求におけるMin-SEヘッダーフィールドにおける値より低持続時間にそれを設定してはいけません、それが存在しているなら。 値である、Session期限が切れる、ヘッダーフィールドがMin-SEヘッダーの値が(Min-SEヘッダーフィールドが存在していないときの90秒のデフォルトがそうであるリコール)をよりさばくということである、プロキシが値を増加させてはいけない、ヘッダーフィールドをSession吐き出します。 値である、Session期限が切れる、ヘッダーフィールドがMin-SEヘッダーフィールドの値より低い(ことによるとプロキシが以下で説明されるようにMin-SEヘッダーフィールドの値を増加させたので)、プロキシが値を増加させなければならない、それをMin-SEヘッダーフィールド価値と等しくするヘッダーフィールドをSession吐き出します。 プロキシが中で'酒'パラメタの値を挿入してはいけませんし、また変更してはいけない、ヘッダーフィールドをSession吐き出します。
If the request contains a Supported header field with a value 'timer', the proxy MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the proxy's local policy. When sending the 422 response, the proxy MUST include a Min-SE header field with the value of its minimum interval. That minimum MUST NOT be lower than 90 seconds.
要求が値の'タイマ'があるSupportedヘッダーフィールドを含んでいるなら、中に422(セッションInterval Too Small)応答がセッション間隔であるならある状態でプロキシがINVITE要求を拒絶するかもしれない、Session期限が切れる、ヘッダーフィールドはプロキシのローカルの方針で定義された最小間隔より小さいです。 422応答を送るとき、プロキシは最小間隔の値があるMin-SEヘッダーフィールドを入れなければなりません。 その最小限は90秒より低いはずがありません。
If the request doesn't indicate support for the session timer but contains a session interval that is too small, the proxy cannot usefully reject the request, as this would result in a call failure. Rather, the proxy SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the proxy SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The proxy MUST then increase the Session-Expires
要求がセッションタイマのサポートを示しませんが、小さ過ぎるセッション間隔を含んでいるなら、プロキシは有効に要求を拒絶できません、これが呼び出し失敗をもたらしているだろうという間。 むしろ、プロキシSHOULDは最小間隔を含むMin-SEヘッダーフィールドを挿入します。 Min-SEヘッダーフィールドが既に存在しているなら、プロキシSHOULDは最小間隔に値を増加させます(しかし、減少してはいけません)。 次に、プロキシが増加しなければならない、Session期限が切れます。
Donovan & Rosenberg Standards Track [Page 13] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[13ページ]。
header field value to be equal to the value in the Min-SE header field, as described above. A proxy MUST NOT insert a Min-SE header field or modify the value of an existing header field in a proxied request if that request contains a Supported header field with the value 'timer'. This is needed to protect against certain denial of service attacks, described in Section 11.
Min-SEヘッダーフィールドにおける値と等しい上で説明されるとしてのヘッダーフィールド値。 その要求が値の'タイマ'があるSupportedヘッダーフィールドを含んでいるなら、プロキシは、Min-SEヘッダーフィールドを挿入してはいけませんし、またproxied要求における、既存のヘッダーフィールドの値を変更してはいけません。 これが、セクション11で説明されたあるサービス不能攻撃から守るのに必要です。
Assuming that the proxy has requested a session timer (and thus has possibly inserted the Session-Expires header field or reduced it), the proxy MUST remember that it is using a session timer, and also remember the value of the Session-Expires header field from the proxied request. This MUST be remembered for the duration of the transaction.
プロキシがセッションタイマを要求したと仮定する、(その結果ことによると挿入されていた状態でヘッダーフィールドをSession吐き出すか、またはそれを減少させる、)、プロキシがそれがセッションタイマを使用しているのを覚えていて、また、値を覚えていなければならない、proxied要求からのヘッダーフィールドをSession吐き出します。 取引の持続時間のためにこれを覚えていなければなりません。
The proxy MUST remember, for the duration of the transaction, whether the request contained the Supported header field with the value 'timer'. If the request did not contain a Supported header field with the value 'timer', the proxy MAY insert a Require header field with the value 'timer' into the request. However, this is NOT RECOMMENDED. This allows the proxy to insist on a session timer for the session. This header field is not needed if a Supported header field was in the request; in this case, the proxy would already be sure the session timer can be used for the session.
プロキシは覚えていなければなりません、取引の持続時間のために、要求が値の'タイマ'があるSupportedヘッダーフィールドを含んだか否かに関係なく。 要求が値の'タイマ'があるSupportedヘッダーフィールドを含まなかったなら、プロキシは値の'タイマ'でRequireヘッダーフィールドを要求に挿入するかもしれません。 しかしながら、これはNOT RECOMMENDEDです。 これで、プロキシはセッションのためのセッションタイマを強要できます。 Supportedヘッダーフィールドが要求にあったなら、このヘッダーフィールドは必要ではありません。 この場合、プロキシはセッションにセッションタイマを使用できるのを既に確信しているでしょう。
8.2. Processing of Responses
8.2. 応答の処理
When the final response to the request arrives, it is examined by the proxy.
要求への最終的な応答が到着すると、それはプロキシによって調べられます。
If the response does not contain a Session-Expires header field but the proxy remembers that it requested a session timer in the request (by inserting, modifying, or examining and accepting the Session-Expires header field in the proxied request), this means that the UAS did not support the session timer. If the proxy remembers that the UAC did not support the session timer either, the proxy forwards the response upstream normally. There is no session expiration for this session. If, however, the proxy remembers that the UAC did support the session timer, additional processing is needed.
応答が含んでいない、aがヘッダーフィールドをSession吐き出しますが、プロキシが、それが要求でセッションタイマを要求したのを覚えている、(挿入するか、変更するか、調べて、または受け入れる、proxied要求におけるヘッダーフィールドをSession吐き出す、)、これは、UASがセッションタイマを支えなかったことを意味します。 プロキシが、UACがセッションタイマを支えなかったのを覚えているなら、通常、プロキシは応答上流を進めます。 セッション満了が全くこのセッションの間、ありません。 しかしながら、プロキシが、UACがセッションタイマを支えたのを覚えているなら、追加処理が必要です。
Because there is no Session-Expires or Require header field in the response, the proxy knows that it is the first session-timer-aware proxy to receive the response. This proxy MUST insert a Session-Expires header field into the response with the value it remembered from the forwarded request. It MUST set the value of the 'refresher' parameter to 'uac'. The proxy MUST add the 'timer'
いいえがあるのでSession呼吸が絶えるか、または応答におけるRequireヘッダーフィールド、プロキシが、それが1番目であることを知っている、セッションタイマ意識する、応答を受けるプロキシ。 このプロキシはaを挿入しなければなりません。それが転送された要求から覚えていた値がある応答へのヘッダーフィールドをSession吐き出します。 それは'酒'パラメタの値を'uac'に設定しなければなりません。 プロキシは'タイマ'を加えなければなりません。
Donovan & Rosenberg Standards Track [Page 14] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[14ページ]。
option tag to any Require header field in the response, and if none was present, add the Require header field with that value before forwarding it upstream.
応答であってなにも存在していなかったかどうかのどんなRequireヘッダーフィールドへのオプションタグも上流へそれを進める前のその値でRequireヘッダーフィールドを加えます。
If the received response contains a Session-Expires header field, no modification of the response is needed.
容認された応答が含んでいる、aはヘッダーフィールドをSession吐き出して、応答の変更は全く必要ではありません。
In all cases, if the 2xx response forwarded upstream by the proxy contains a Session-Expires header field, its value represents the session interval for the session associated with that response. The proxy computes the session expiration as the time when the 2xx response is forwarded upstream, plus the session interval. This session expiration MUST update any existing session expiration for the session. The refresher parameter in the Session-Expires header field in the 2xx response forwarded upstream will be present, and it indicates which UA is performing the refreshes. There can be multiple 2xx responses to a single INVITE, each representing a different dialog, resulting in multiple session expirations, one for each session associated with each dialog.
すべての場合では、応答が2xxであるならプロキシで上流を進めた、含有、aはヘッダーフィールドをSession吐き出して、値はその応答に関連しているセッションのためにセッション間隔を表します。 プロキシは2xx応答が上流へ進められる時、およびセッション間隔としてセッション満了を計算します。 このセッション満了はセッションのためにどんな既存のセッション満了もアップデートしなければなりません。 中の酒のパラメタ、Session期限が切れる、上流へ進められた2xx応答におけるヘッダーフィールドが存在して、どのUAが働いているかを示す、リフレッシュします。 独身のINVITEへの複数の2xx応答があることができます、それぞれ異なった対話を表して、複数のセッション満期(各対話に関連しているそれぞれのセッションあたり1つ)になって
The proxy MUST NOT modify the value of the Session-Expires header field received in the response (assuming one was present) before forwarding it upstream.
プロキシが値を変更してはいけない、上流へそれを進める前に応答(1つが存在していたと仮定する)で受け取られたヘッダーフィールドをSession吐き出します。
8.3. Session Expiration
8.3. セッション満了
When the current time equals or passes the session expiration for a session, the proxy MAY remove associated call state, and MAY free any resources associated with the call. Unlike the UA, it MUST NOT send a BYE.
現在の時間がセッションのためにセッション満了を等しい、または通過するとき、プロキシは、関連呼び出し状態を取り除いて、呼び出しに関連しているどんなリソースも解放するかもしれません。 UAと異なって、それはBYEを送ってはいけません。
9. UAS Behavior
9. UASの振舞い
The UAS must respond to a request for a session timer by the UAC or a proxy in the path of the request, or it may request that a session timer be used itself.
UASが要求の経路でUACかプロキシでセッションタイマを求める要求に応じなければならない、さもなければ、それはセッションタイマがそれ自体で使用されるよう要求するかもしれません。
If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy. When sending the 422 response, the UAS MUST include a Min-SE header field with the value of its minimum interval. This minimum interval MUST NOT be lower than 90 seconds.
入って来る要求が値の'タイマ'とSession ExpiresヘッダーフィールドがあるSupportedヘッダーフィールドを含んでいるなら、中に422(セッションInterval Too Small)応答がセッション間隔であるならある状態でUAS MAYがINVITE要求を拒絶する、Session期限が切れる、ヘッダーフィールドはUASのローカルの方針で定義された最小間隔より小さいです。 422応答を送るとき、UAS MUSTは最小間隔の値があるMin-SEヘッダーフィールドを含んでいます。 この最小間隔は90秒より低いはずがありません。
If the UAS wishes to accept the request, it copies the value of the Session-Expires header field from the request into the 2xx response.
UASが要請を受け入れたいなら、値をコピーする、2xx応答への要求からのヘッダーフィールドをSession吐き出します。
Donovan & Rosenberg Standards Track [Page 15] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[15ページ]。
The UAS response MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present; otherwise the UAS MAY reduce its value but MUST NOT set it to a duration lower than 90 seconds. The UAS MUST NOT increase the value of the Session-Expires header field.
UAS応答は、値を減少させるかもしれませんが、要求におけるMin-SEヘッダーフィールドにおける値より低持続時間にそれを設定してはいけません、それが存在しているなら。 さもなければ、UAS MAYは値を減少させますが、90秒より低持続時間にそれを設定してはいけません。 UAS MUST NOTが値を増加させる、ヘッダーフィールドをSession吐き出します。
If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present.
入って来る要求が値の'タイマ'があるa Supportedヘッダーフィールドを含んでいますが、する、含んでいない、aはヘッダーをSession吐き出して、それは、UASがタイマのサポートを示していますが、1つを要求していないことを意味します。 UASは2XX応答で包含でセッションタイマを要求するかもしれません。aはヘッダーフィールドをSession吐き出します。 要求におけるMin-SEヘッダーフィールドで値より低く持続時間に値を設定してはいけません、それが存在しているなら。
The UAS MUST set the value of the refresher parameter in the Session-Expires header field in the 2xx response. This value specifies who will perform refreshes for the dialog. The value is based on the value of this parameter in the request, and on whether the UAC supports the session timer extension. The UAC supports the extension if the 'timer' option tag was present in a Supported header field in the request. Table 2 defines how the value in the response is set. A value of 'none' in the 2nd column means that there was no refresher parameter in the request. A value of 'NA' in the third column means that this particular combination shouldn't happen, as it is disallowed by the protocol.
UAS MUSTが酒のパラメタの値をはめ込む、2xx応答におけるヘッダーフィールドをSession吐き出します。 この値は、だれが働くかを指定します。対話のために、リフレッシュします。 値は、要求における、このパラメタの値に基づいていて、UACがセッションタイマ延期を支持するかどうかに関してそうします。 'タイマ'オプションタグが要求におけるSupportedヘッダーフィールドで存在していたなら、UACは拡大を支持します。 テーブル2は応答における値がどう設定されるかを定義します。 第2コラムの'なにも'の値は、要求には酒のパラメタが全くなかったことを意味します。 第3コラムの'NA'の値は、この特定の組み合わせが起こるべきでないことを意味します、それがプロトコルによって禁じられるとき。
UAC supports? refresher parameter refresher parameter
in request in response
-------------------------------------------------------
N none uas
N uac NA
N uas NA
Y none uas or uac
Y uac uac
Y uas uas
UACサポート?応答における要求における酒のパラメタ酒のパラメタ------------------------------------------------------- N、なにもN uac NA N uas NA Yのuasでないなにもuac Y uac uac Y uas uasをuasしません。
Table 2: UAS Behavior
テーブル2: UASの振舞い
The fourth row of Table 2 describes a case where both the UAC and UAS support the session timer extension, and where the UAC did not select who will perform refreshes. This allows the UAS to decide whether it or the UAC will perform the refreshes. However, as the table indicates, the UAS cannot override the UAC's choice of refresher, if it made one.
Table2の4番目の列はUACとUASの両方がセッションタイマ延期を支持するケースについて説明します、そして、UACが、どこでだれが働くかを選択しなかったかがリフレッシュします。 UASが、これでそれかUACが働くかどうか決めることができる、リフレッシュします。 しかしながら、テーブルが示すように、グループの一人となったなら、UASは酒のUACの選択をくつがえすことができません。
If the refresher parameter in the Session-Expires header field in the 2xx response has a value of 'uac', the UAS MUST place a Require header field into the response with the value 'timer'. This is
中の酒のパラメタである、aが2xx応答における分野で評価する'uac'(値の'タイマ'による応答へのUAS MUST場所a Requireヘッダーフィールド)のヘッダーをSession吐き出します。 これはそうです。
Donovan & Rosenberg Standards Track [Page 16] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[16ページ]。
because the uac is performing refreshes and the response has to be processed for the UAC to know this. If the refresher parameter in the 2xx response has a value of 'uas' and the Supported header field in the request contained the value 'timer', the UAS SHOULD place a Require header field into the response with the value 'timer'. In this case, the UAC is not refreshing, but it is supposed to send a BYE if it never receives a refresh. Since the call will still succeed without the UAC sending a BYE, insertion of the Require is a SHOULD here, and not a MUST.
uacがそうので、実行はリフレッシュします、そして、UACがこれを知るように、応答は処理されなければなりません。 2xx応答における酒のパラメタには'uas'の値があって、要求におけるSupportedヘッダーフィールドが値の'タイマ'を含んだなら、UAS SHOULDは値の'タイマ'でRequireヘッダーフィールドを応答に置きます。 この場合、UACはリフレッシュしていませんが、発信するために、aを決して受けないならa BYEがリフレッシュすると思われます。 それでも、UACがBYEを送らないで呼び出しが成功するので、Requireの挿入はここのSHOULDです、そして、どんなaもSHOULDであってはいけないこと。
Just like the UAC, the UAS stores state for the session timer. This state includes the session interval, the session expiration, and the identity of the refresher. This state is bound to the dialog used to set up the session. The session interval is set to the value of the delta-time from the Session-Expires header field in the most recent 2xx response to a session refresh request on that dialog. It also remembers whether it or its peer is the refresher on the dialog, based on the value of the refresher parameter from the most recent 2xx response to a session refresh request on that dialog. If the most recent 2xx response had no Session-Expires header field, there is no session expiration, and no refreshes have to be performed.
まさしくUACのように、UASはセッションタイマのために状態を格納します。 この州はセッション間隔、セッション満了、および酒のアイデンティティを含めます。 この状態はセッションをセットアップするのに使用される対話に縛られます。 セッション間隔がデルタ現代の値に設定される、aへのセッションが要求をリフレッシュする最新の2xx応答におけるヘッダーフィールドをSession吐き出す、その対話。 また、それは、それかその同輩が対話の酒であるか否かに関係なく、セッションへの最新の2xx応答からの酒のパラメタの値に基づいてその対話に関する要求をリフレッシュするように覚えています。 最新の2xx応答がそうしたなら、いいえはヘッダーフィールドをSession吐き出します、そして、セッション満了が全くありません、そして、いいえはリフレッシュします。実行されなければなりません。
If the UAS must refresh the session, it computes the session expiration. The session expiration is the time of transmission of the last 2xx response to a session refresh request on that dialog plus the session interval. If UA wishes to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10.
UASがセッションをリフレッシュしなければならないなら、それはセッション満了を計算します。 セッション満了はセッションへの最後の2xx応答の送信の時間がその対話とセッション間隔に関する要求をリフレッシュするということです。 UAがセッション満了を超えてセッションを続行したいなら、それは発生しなければなりません。aはセッション満了の前にリフレッシュします。 これがリフレッシュするのは、RECOMMENDEDです。セッション間隔が持っている半分がいったん経過すると、送ります。 これがリフレッシュするので、追加手順はセクション10で説明されます。
10. Performing Refreshes
10. 実行はリフレッシュします。
The side generating a refresh does so according to the UAC procedures defined in Section 7. Note that only a 2xx response to a session refresh request extends the session expiration. This means that a UA could attempt a refresh and receive a 422 response with a Min-SE header field that contains a value much larger than the current session interval. The UA will still have to send a session refresh request before the session expiration (which has not changed), even though this request will contain a value of the Session-Expires that is much larger than the current session interval.
セクション7で定義されたUAC手順によると、aを発生させるとリフレッシュする側はそうします。 セッションへの2xx応答だけが要求をリフレッシュするというメモはセッション満了を広げています。 これは、UAが試みることができたことを意味します。aは、現在のセッション間隔よりはるかに大きい値を含むMin-SEヘッダーフィールドで、422応答をリフレッシュして、受けます。 それでも、UAはセッション満了(変化していない)の前にセッションがリフレッシュするaに要求を送らなければならないでしょう、意志が値を含むこの要求ですがSession期限が切れる、それは現在のセッション間隔よりはるかに大きいです。
If the session refresh request transaction times out or generates a 408 or 481 response, then the UAC sends a BYE request as per Section 12.2.1.2 of RFC 3261 [2]. If the session refresh request does not generate a 2xx response (and, as a result, the session is not refreshed), and a response other than 408 or 481 is received, the UAC
セッションが外で要求取引回数をリフレッシュするか、または408か481応答を発生させるなら、UACはセクション12.2.1に従ってBYE要求に.2RFC3261[2]を送ります。 セッションがリフレッシュするなら、要求は2xx応答を発生させません、そして、(その結果、セッションは壮快ではありません)408か481以外の応答は受け取られています、UAC
Donovan & Rosenberg Standards Track [Page 17] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[17ページ]。
SHOULD follow the rules specific to that response code and retry if possible. For example, if the response is a 401, the UAC would retry the request with new credentials. However, the UAC SHOULD NOT continuously retry the request if the server indicates the same error response.
SHOULDはその応答コードに特定の規則に従って、できれば、再試行します。 例えば、応答が401であるなら、UACは新しい信任状で要求を再試行するでしょう。 しかしながら、サーバが同じ誤り応答を示すなら、UAC SHOULD NOTは絶え間なく要求を再試行します。
Similarly, if the side not performing refreshes does not receive a session refresh request before the session expiration, it SHOULD send a BYE to terminate the session, slightly before the session expiration. The minimum of 32 seconds and one third of the session interval is RECOMMENDED.
実行でないのがリフレッシュする側が受信しないなら、同様に、セッションはセッション満了の前に要求をリフレッシュします、それ。SHOULDはセッションを終えるためにBYEを送ります、セッション満了のわずかに前に。 32秒の最小限とセッション間隔の1/3はRECOMMENDEDです。
Firewalls and NAT ALGs may be very unforgiving about allowing SIP
traffic to pass after the expiration time of the session. This is
why the BYE should be sent before the expiration.
SIP交通がセッションの満了時間の後に通り過ぎるのを許容することに関してファイアウォールとNAT ALGsは非常に容赦ないかもしれません。 これはBYEが満了の前に送られるべきである理由です。
11. Security Considerations
11. セキュリティ問題
The session timer introduces the capability of a proxy or UA element to force compliant UAs to send refreshes at a rate of the element's choosing. This introduces the possibility of denial-of-service attacks with significant amplification properties. These attacks can be launched from 'outsiders' (elements that attempt to modify messages in transit) or by 'insiders' (elements that are legitimately in the request path but are intent on doing harm). Fortunately, both cases are adequately handled by this specification.
セッションタイマがプロキシの能力を導入するか、または言いなりになっているUAsに送らせるUA要素は要素の選ぶことのレートでリフレッシュします。 これは重要な増幅の特性によるサービス不能攻撃の可能性を導入します。 '部外者'(トランジットにおけるメッセージを変更するのを試みる要素)か'インサイダー'がこれらの攻撃に着手できる、(中の合法的にそうである要素、経路を要求してくださいが、意図が危害を加えるのにおいてオンである、) 幸い、両方のケースはこの仕様で適切に扱われます。
11.1. Inside Attacks
11.1. 攻撃で
This introduces the possibility of rogue proxies or UAs introducing denial-of-service attacks. However, the mechanisms in this specification prevent that from happening.
これは凶暴なプロキシかUAsがサービス不能攻撃を導入する可能性を導入します。 しかしながら、この仕様によるメカニズムによって、それは起こることができません。
First, consider the case of a rogue UAC that wishes to force a UAS to generate refreshes at a rapid rate. To do so, it inserts a Session-Expires header field into an INVITE with a low duration and a refresher parameter equal to uas. Assume it places a Supported header field into the request. The UAS or any proxy that objects to this low timer will reject the request with a 422, thereby preventing the attack. If no Supported header field was present, the proxies will insert a Min-SE header field into the request before forwarding it. As a result, the UAS will not choose a session timer lower than the minimum allowed by all elements on the path. This too prevents the attack.
まず最初に、UASがそうしたがっているUACによってやむを得ず発生させる悪党のケースが急ピッチでリフレッシュすると考えてください。 そのように、それに差し込みをするために、aは低持続時間とuasと等しい酒のパラメタがあるINVITEへのヘッダーフィールドをSession吐き出します。 Supportedヘッダーフィールドを要求に置くと仮定してください。 UASかこの低いタイマに反対するどんなプロキシも422で要求を拒絶するでしょう、その結果、攻撃を防ぎます。 どんなSupportedヘッダーフィールドも存在していなかったなら、それを進める前に、プロキシはMin-SEヘッダーフィールドを要求に挿入するでしょう。 その結果、UASは経路のすべての要素によって許容された最小限より低いセッションタイマを選ばないでしょう。 これも攻撃を防ぎます。
Next, consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS,
次に、UACがそうしたがっているUASによってやむを得ず発生させる悪党のケースが急ピッチでリフレッシュすると考えてください。 その場合、UACはセッションタイマを支えなければなりません。 初期のINVITEは凶暴なUASに到着します。
Donovan & Rosenberg Standards Track [Page 18] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[18ページ]。
which returns a 2xx with a very small session interval. The UAC uses this timer and quickly sends a refresh. Section 7.4 requires that the UAC copy the current session interval into the Session-Expires header field in the request. This enables the proxies to see the current value. The proxies will reject this request and provide a Min-SE with a higher minimum, which the UAC will then use. Note, that if the proxies did not reject the request, but rather proxied the request with a Min-SE header field, an attack would still be possible. The UAS could discard this header field in a 2xx response and force the UAC to continue to generate rapid requests.
非常に小さいセッション間隔がある2xxを返します。 UACはこのタイマを使用して、すばやくaを送ります。リフレッシュしてください。 UACが現在のセッション間隔をコピーする7.4が必要とするセクション、要求におけるヘッダーフィールドをSession吐き出します。 これは、プロキシが現行価値を見るのを可能にします。 プロキシは、この要求を拒絶して、より高い最小限をMin-SEに提供するでしょう。(次に、UACはそれを使用するでしょう)。 プロキシが要求を拒絶しませんでしたが、Min-SEヘッダーフィールドでむしろ要求をproxiedするなら、攻撃がまだ可能であるだろうというメモ。 UASによって、2xx応答でこのヘッダーフィールドを捨てて、UACは、急速な要求をやむを得ず発生させ続けることができました。
In a similar fashion, a rogue proxy cannot force either the UAC or UAS to generate refreshes unless the proxy remains on the signaling path and sees every request and response.
同様に、プロキシがUACかUASのどちらかに強制的に発生させることができない悪党は、プロキシがシグナリング経路に留まっていない場合リフレッシュして、あらゆる要求と応答を見ます。
11.2. Outside Attacks
11.2. 攻撃の外で
An element that can observe and modify a request or response in transit can force rapid session refreshes. To prevent this, requests and responses have to be protected by message integrity. Since the session timer header fields are not end-to-end and are manipulated by proxies, the SIP S/MIME capabilities are not suitable for this task. Rather, integrity has to be protected by using hop-by-hop mechanisms. As a result, it is RECOMMENDED that an element send a request with a Session-Expires header field or a Supported header field with the value 'timer' by using TLS. As adequate protection is obtained only if security is applied on each hop, it is RECOMMENDED that the SIPS URI scheme be used in conjunction with this extension. This means that proxies that record-route and request session timer SHOULD record-route with a SIPS URI. A UA that inserts a Session-Expires header into a request or response SHOULD include a Contact URI that is a SIPS URI.
急速なセッションがリフレッシュするトランジット缶の力で要求か応答を観測して、変更できる要素。 これを防ぐために、要求と応答はメッセージの保全によって保護されなければなりません。 セッションタイマヘッダーフィールドが終わらせないどんな終わりでありも、プロキシによって操られるので、SIP S/MIME能力はこのタスクに適していません。 むしろ、保全は、ホップごとのメカニズムを使用することによって、保護されなければなりません。その結果、要素がaとの要求を送るRECOMMENDEDがTLSを使用するのによる値の'タイマ'があるヘッダーフィールドかSupportedヘッダーフィールドをSession吐き出すということです。 各ホップでセキュリティを適用する場合にだけ適切な保護を得るとき、SIPS URI計画がこの拡大に関連して使用されるのは、RECOMMENDEDです。 プロキシのその記録的なルートと要求セッションタイマSHOULDがSIPS URIと共に記録して発送するこの手段。 aはヘッダーをSession吐き出します。UA、それが挿入する、要求か応答に、SHOULDはSIPS URIであるContact URIを含めます。
12. IANA Considerations
12. IANA問題
This extension defines two new header fields, a new response code, and a new option tag. SIP [2] defines IANA procedures for registering these.
この拡大は2つの新しいヘッダーフィールド、新しい応答コード、および新しいオプションタグを定義します。 SIP[2]はこれらを登録するためのIANA手順を定義します。
12.1. IANA Registration of Min-SE and Session-Expires Header Fields
12.1. 分-SEのIANA登録、ヘッダーフィールドをセッションで吐き出します。
The following is the registration for the Min-SE header field:
↓これはMin-SEヘッダーフィールドのための登録です:
RFC Number: RFC 4028 Header Name: Min-SE Compact Form: none
RFC番号: RFC4028ヘッダー名: 分-SEコンパクト形: なし
Donovan & Rosenberg Standards Track [Page 19] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[19ページ]。
The following is the registration for the Session-Expires header field:
↓これが登録である、ヘッダーフィールドをSession吐き出します:
RFC Number: RFC 4028 Header Name: Session-Expires Compact Form: x
RFC番号: RFC4028ヘッダー名: コンパクト形をセッションで吐き出します: x
12.2. IANA Registration of the 422 (Session Interval Too Small)
Response Code
12.2. 422のもののIANA登録、(セッション間隔、あまりに小さい)、応答コード
The following is the registration for the 422 (Session Interval Too Small) response code:
↓これは422(セッションInterval Too Small)応答コードのための登録です:
Response Code: 422 Default Reason Phrase: Session Interval Too Small RFC Number: RFC 4028
応答コード: 422デフォルト理由句: セッション間隔の小さ過ぎるRFCは以下に付番します。 RFC4028
12.3. IANA Registration of the 'timer' Option Tag
12.3. 'タイマ'オプションタグのIANA登録
The following is the registration for the 'timer' option tag:
↓これは'タイマ'オプションタグのための登録です:
Name: timer
Description: This option tag is for support of the session timer
extension. Inclusion in a Supported header field in a request or
response indicates that the UA can perform refreshes according to
that specification. Inclusion in a Require header in a request
means that the UAS must understand the session timer extension to
process the request. Inclusion in a Require header field in a
response indicates that the UAC must look for the Session-Expires
header field in the response and process it accordingly.
以下を命名してください。 タイマ記述: このオプションタグはセッションタイマ延期のサポートのためのものです。 要求か応答における分野が示すSupportedヘッダーでのUAが実行できる包含はその仕様通りにリフレッシュします。 要求におけるRequireヘッダーでの包含は、UASが、セッションタイマ延期が要求を処理するのを理解しなければならないことを意味します。 中の応答が示すRequireヘッダーフィールドでのUACが探さなければならない包含、応答におけるヘッダーフィールドをSession吐き出して、それに従って、それを処理します。
13. Example Call Flow
13. 例の呼び出し流動
Example Session Timer Flow
例のセッションタイマ流動
Alice Proxy P1 Proxy P2 Bob
|(1) INVITE | | |
|SE: 50 | | |
|----------->| | |
|(2) 422 | | |
|MSE: 3600 | | |
|<-----------| | |
|(3) ACK | | |
|----------->| | |
|(4) INVITE | | |
|SE:3600 | | |
|MSE:3600 | | |
|----------->| | |
アリスプロキシP1プロキシP2ボブ|(1) 招待| | | |SE: 50 | | | |、-、-、-、-、-、-、-、-、-、--、>|、|、| |(2) 422 | | | |MSE: 3600 | | | | <、-、-、-、-、-、-、-、-、-、--、|、|、| |(3) ACK| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、| |(4) 招待| | | |SE: 3600| | | |MSE: 3600| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、|
Donovan & Rosenberg Standards Track [Page 20] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[20ページ]。
| |(5) INVITE | |
| |SE:3600 | |
| |MSE:3600 | |
| |----------->| |
| |(6) 422 | |
| |MSE:4000 | |
| |<-----------| |
| |(7) ACK | |
| |----------->| |
|(8) 422 | | |
|MSE:4000 | | |
|<-----------| | |
|(9) ACK | | |
|----------->| | |
|(10) INVITE | | |
|SE:4000 | | |
|MSE:4000 | | |
|----------->| | |
| |(11) INVITE | |
| |SE:4000 | |
| |MSE:4000 | |
| |----------->| |
| | |(12) INVITE |
| | |SE:4000 |
| | |MSE:4000 |
| | |----------->|
| | |(13) 200 OK |
| | |SE:4000 |
| | |<-----------|
| |(14) 200 OK | |
| |SE:4000 | |
| |<-----------| |
|(15) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
|(16) ACK | | |
|----------->| | |
| |(17) ACK | |
| |------------------------>|
|(18) UPDATE | | |
|SE:4000 | | |
|----------->| | |
| |(19) UPDATE | |
| |SE:4000 | |
| |------------------------>|
| |(20) 200 OK | |
| |SE:4000 | |
| |<------------------------|
| |(5) 招待| | | |SE: 3600| | | |MSE: 3600| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、| |(6) 422 | | | |MSE: 4000| | | | <、-、-、-、-、-、-、-、-、-、--、|、|、| |(7) ACK| | | |、-、-、-、-、-、-、-、-、-、--、>|、| |(8) 422 | | | |MSE: 4000| | | | <、-、-、-、-、-、-、-、-、-、--、|、|、| |(9) ACK| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、| |(10) 招待| | | |SE: 4000| | | |MSE: 4000| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(11) 招待| | | |SE: 4000| | | |MSE: 4000| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(12) 招待| | | |SE: 4000| | | |MSE: 4000| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、| |(13) 200 OK| | | |SE: 4000| | | | <、-、-、-、-、-、-、-、-、-、--、|、| |(14) 200 OK| | | |SE: 4000| | | | <、-、-、-、-、-、-、-、-、-、--、|、| |(15) 200 OK| | | |SE: 4000| | | | <、-、-、-、-、-、-、-、-、-、--、|、|、| |(16) ACK| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(17) ACK| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(18) アップデート| | | |SE: 4000| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(19) アップデート| | | |SE: 4000| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(20) 200 OK| | | |SE: 4000| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|
Donovan & Rosenberg Standards Track [Page 21] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[21ページ]。
|(21) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
| |(22) BYE | |
| |<------------------------|
|(23) BYE | | |
|<-----------| | |
| |(24) 408 | |
| |------------------------>|
| 200が承認する(21)| | | |SE: 4000| | | | <、-、-、-、-、-、-、-、-、-、--、|、|、|、| |(22) さようなら| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(23) さようなら| | | | <、-、-、-、-、-、-、-、-、-、--、|、|、|、| |(24) 408 | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|
Figure 1: Example Session Timer Flow
図1: 例のセッションタイマ流動
Figure 1 gives an example of a call flow that makes use of the session timer. In this example, both the UAC and UAS support the session timer extension. The initial INVITE request generated by the UAC, Alice (message 1), might look like this:
図1はセッションタイマを利用する呼び出し流動に関する例を出します。 この例では、UACとUASの両方がセッションタイマ延期を支持します。 UACによって発生した初期のINVITE要求(アリス(メッセージ1))はこれに似るかもしれません:
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142
INVITE一口: bob@biloxi.example.com SIP/2.0Via: 一口/2.0/TLS pc33.atlanta.example.com; z9hG4bKnashds8が支えたブランチ=: タイマはSession期限が切れます: 50 マックス-フォワード: 70 To: ボブ<一口: bob@biloxi.example.com 、gt;、From: アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 接触を招いてください: <一口: alice@pc33.atlanta.example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 142
(Alice's SDP not shown)
(見せられなかったアリスのSDP)
This request indicates that Alice supports the session timer, and is requesting session refreshes every 50 seconds. This arrives at the first proxy, P1. This session interval is below the minimum allowed value of 3600. So P1 rejects the request with a 422 (message 2):
この要求は、アリスがセッションタイマを支えるのを示して、セッションが50秒毎にリフレッシュするよう要求しています。 これは第1代プロキシ、P1に到着します。 このセッション間隔が3600年の値が許容された最小限の下にあります。 それで、P1は422(メッセージ2)で要求を拒絶します:
SIP/2.0 422 Session Interval Too Small
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Min-SE: 3600
To: Bob <sips:bob@biloxi.example.com>;tag=9a8kz
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
以下を通ってあまりに小さく/2.0 422セッション間隔をちびちび飲んでください。 一口/2.0/TLS pc33.atlanta.example.com; ブランチ=z9hG4bKnashds8;容認された=192.0.2.1分-SE: 3600 To: ボブ<一口: bob@biloxi.example.com 、gt;、;=9a8kz From:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 招待
Donovan & Rosenberg Standards Track [Page 22] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[22ページ]。
This response contains a Min-SE header field with the value 3600. Alice then retries the request. This time, the request contains a Min-SE header, as Alice has received a 422 for other INVITE requests with the same Call-ID. The new request (message 4) might look like this:
この応答は値3600があるMin-SEヘッダーフィールドを含んでいます。 そして、アリスは要求を再試行します。 今回、要求はMin-SEヘッダーを含みます、アリスが同じCall-IDとの他のINVITE要求のために422を受け取ったとき。 新しい要求(メッセージ4)はこれに似るかもしれません:
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142
INVITE一口: bob@biloxi.example.com SIP/2.0Via: 一口/2.0/TLS pc33.atlanta.example.com; z9hG4bKnashds9が支えたブランチ=: タイマはSession期限が切れます: 3600分-SE: 前方へ3600最大: 70 To: ボブ<一口: bob@biloxi.example.com 、gt;、From: アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314160 接触を招いてください: <一口: alice@pc33.atlanta.example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 142
(Alice's SDP not shown)
(見せられなかったアリスのSDP)
Proxy P1 record-routes. Since the session interval is now acceptable to it, it forwards the request to P2 (message 5). However, the session interval is below its minimum configured amount of 4000. So it rejects the request with a 422 response code (message 6) and includes a Min-SE header field with the value of 4000. Once more, Alice retries the INVITE. This time, the Min-SE header field in her INVITE is the maximum of all Min-SE she has received (3600 and 4000). Message 10 might look like this:
プロキシのP1の記録的なルート。 セッション間隔が現在それに許容できるので、それはP2(メッセージ5)に要求を転送します。 しかしながら、セッション間隔が最小の構成された量の4000の下にあります。 それで、それは、422応答コード(メッセージ6)で要求を拒絶して、4000年の値でMin-SEヘッダーフィールドを含んでいます。 もう一度、アリスはINVITEを再試行します。 今回、彼女のINVITEのMin-SEヘッダーフィールドは最大です。すべてのMin-SEでは、彼女は(3600と4000)を受けました。 メッセージ10はこれに似るかもしれません:
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Supported: timer Session-Expires: 4000 Min-SE: 4000 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142
INVITE一口: bob@biloxi.example.com SIP/2.0Via: 一口/2.0/TLS pc33.atlanta.example.com; z9hG4bKnashds10が支えたブランチ=: タイマはSession期限が切れます: 4000分-SE: 前方へ4000最大: 70 To: ボブ<一口: bob@biloxi.example.com 、gt;、From: アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314161 接触を招いてください: <一口: alice@pc33.atlanta.example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 142
(Alice's SDP not shown)
(見せられなかったアリスのSDP)
Donovan & Rosenberg Standards Track [Page 23] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[23ページ]。
P1 record-routes once again, but P2 does not (this wouldn't normally happen; presumably, if it asked for session timer, it would record-route the subsequent request). The UAS receives the request. It copies the Session-Expires header from the request to the response and adds a refresher parameter with value 'uac'. This 200 OK is forwarded back to Alice. The response she receives (message 15) might look like this:
もう一度、P2だけがそうしないP1の記録的なルート(通常、これは起こらないでしょう; おそらく、セッションタイマを求めるなら、その後の要求を記録して発送するでしょうに)。 UASは要求を受け取ります。 そして、コピーする、ヘッダーをSession吐き出す、要求から応答、値の'uac'で酒のパラメタを加えます。 この200OKをアリスに転送して戻します。 彼女が受ける応答(メッセージ15)はこれに似るかもしれません:
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
;received=192.0.2.1
Require: timer
Supported: timer
Record-Route: sips:p1.atlanta.example.com;lr
Session-Expires: 4000;refresher=uac
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sips:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 142
以下を通って一口/2.0 200OK 一口/2.0/TLS pc33.atlanta.example.com; ブランチはz9hG4bKnashds10と等しいです; .1が必要とする=192.0.2を受け取ります: タイマSupported: タイマRecord-ルート: 一口: p1.atlanta.example.com; lr Session期限が切れます: 4000; 酒=のuac To: ボブ<一口: bob@biloxi.example.com 、gt;、;=9as888nd From:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314161 接触を招いてください: <一口: bob@192.0.2.4 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 142
(Bob's SDP not shown)
(見せられなかったボブのSDP)
Alice generates an ACK (message 16), which is routed through P1 and then to Bob. Since Alice is the refresher, around 2000 seconds later Alice sends an UPDATE request to refresh the session. Because this request is part of an established dialog and Alice has not received any 422 responses or requests on that dialog, there is no Min-SE header field in her request (message 18):
アリスはACK(メッセージ16)を発生させます。(ACKはP1を通してそして、ボブに発送されます)。 以来、アリスは酒、後のアリスがセッションをリフレッシュするというUPDATE要求を送るおよそ2000秒です。 まだこの要求が確立した対話の一部であり、アリスがその対話に関する422の応答か要求を受け取っていないので、彼女の要求(メッセージ18)にはMin-SEヘッダーフィールドが全くありません:
UPDATE sips:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 Route: sips:p1.atlanta.example.com;lr Supported: timer Session-Expires: 4000;refresher=uac Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314162 UPDATE Contact: <sips:alice@pc33.atlanta.example.com>
UPDATE一口: bob@192.0.2.4 SIP/2.0Via: 一口/2.0/TLS pc33.atlanta.example.com; ブランチ=z9hG4bKnashds12は以下を発送します。 一口: p1.atlanta.example.com; lr Supported、: タイマはSession期限が切れます: 4000; 酒は前方へuacマックスと等しいです: 70 To: ボブ<一口: bob@biloxi.example.com 、gt;、;=9as888nd From:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314162 接触をアップデートしてください: <一口: alice@pc33.atlanta.example.com 、gt。
Donovan & Rosenberg Standards Track [Page 24] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[24ページ]。
This is forwarded through P1 to Bob. Bob generates a 200 OK, copying the Session-Expires header field into the response. This is forwarded through P1 and arrives at Alice. The response she receives (message 21) might look like this:
P1を通してこれをボブに送ります。 ボブが200OK、コピーを発生させる、応答へのヘッダーフィールドをSession吐き出します。 これは、P1を通して送られて、アリスに到着します。 彼女が受ける応答(メッセージ21)はこれに似るかもしれません:
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
;received=192.0.2.1
Require: timer
Session-Expires: 4000;refresher=uac
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact: <sips:bob@192.0.2.4>
以下を通って一口/2.0 200OK 一口/2.0/TLS pc33.atlanta.example.com; ブランチはz9hG4bKnashds12と等しいです; .1が必要とする=192.0.2を受け取ります: タイマはSession期限が切れます: 4000; 酒=のuac To: ボブ<一口: bob@biloxi.example.com 、gt;、;=9as888nd From:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314162 接触をアップデートしてください: <一口: bob@192.0.2.4 、gt。
Shortly afterward, Alice's UA crashes. As a result, she never sends a session refresh request. 3968 seconds later, Bob times out and sends a BYE request (message 22). This is sent to P1. P1 attempts to deliver it but fails (because Alice's UA has crashed). P1 then returns a 408 (Request Timeout) to Bob.
その後まもなく、アリスのUAはクラッシュします。 その結果、彼女はセッションがリフレッシュするaに要求を決して送りません。 3968 外でボブ時間より後半を後援して、BYE要求(メッセージ22)を送ります。 これをP1に送ります。 P1はそれを届けるのを試みますが、失敗します(アリスのUAがクラッシュしたので)。 そして、P1は408(Timeoutを要求する)をボブに返します。
14. Acknowledgements
14. 承認
The authors wish to thank Brett Tate for his contributions to this work. Brian Rosen completed the editing of the document.
作者はこの仕事への彼の貢献についてブレット・テイトに感謝したがっています。 ブライアン・ローゼンはドキュメントの編集を終了しました。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] 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.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[3] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、2002年10月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
Donovan & Rosenberg Standards Track [Page 25] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[25ページ]。
15.2. Informative References
15.2. 有益な参照
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[5]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[6]SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[7] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[8] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
Authors' Addresses
作者のアドレス
Steve Donovan Cisco Systems, Inc. 2200 E. President George Bush Turnpike Richardson, Texas 75082 US
スティーブドノヴァンシスコシステムズInc.2200E.社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
EMail: srd@cisco.com
メール: srd@cisco.com
Jonathan Rosenberg Cisco Systems, Inc. 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステムズInc.600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
EMail: jdrosen@cisco.com
メール: jdrosen@cisco.com
Donovan & Rosenberg Standards Track [Page 26] RFC 4028 Session Timer April 2005
ドノヴァンとローゼンバーグStandardsはセッションタイマ2005年4月にRFC4028を追跡します[26ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Donovan & Rosenberg Standards Track [Page 27]
ドノヴァンとローゼンバーグ標準化過程[27ページ]
一覧
スポンサーリンク
