Network Working Group S. Donovan
Request for Comments: 4028 J. Rosenberg
Category: Standards Track Cisco Systems
April 2005
セッション開始プロトコル(SIP)におけるセッションタイマー
Session Timers in the Session Initiation Protocol (SIP)
本文書の位置付け
この文書は、インターネットコミュニティのためのインターネット標準化過程
プロトコルを規定するものであり、改善のための議論や提案を依頼するもの
である。標準化の段階や、プロトコルの位置付けについては、最新版の
"Internet Official Protocol Standards" (STD 1)を参照されたい。この文書
の配信は無制限である。
著作権表記
Copyright (C) The Internet Society (2005).
概要
本文書では、セッション開始プロトコル(Session Initiation Protocol/SIP)
の拡張を定義する。この拡張を使用すると、re-INVITEまたはUPDATEリクエス
トによってSIPセッションを定期的に更新することができるようになる。ま
た、更新によって、ユーザーエージェントとプロキシの双方がSIPセッション
がアクティブかどうかを判断できるようになる。この拡張では2つの新規ヘッ
ダーフィールドを定義する。セッションの生存時間を伝達するSession-
Expires、およびセッションタイマーに許容される最小値を伝達するMin-SEで
ある。
Donovan & Rosenberg Standards Track [Page 1]
RFC 4028 Session Timer April 2005
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. 操作の概要 . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Session-Expiresヘッダーフィールドの定義 . . . . . . . . . . 6
5. Min-SEヘッダーフィールドの定義 . . . . . . . . . . . . . . . 8
6. 422応答コードの定義 . . . . . . . . . . . . . . . . . . . . 8
7. UACの動作 . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. 最初のセッション更新リクエストの生成 . . . . . . . . . 9
7.2. 2xx応答の処理 . . . . . . . . . . . . . . . . . . . . 9
7.3. 422応答の処理 . . . . . . . . . . . . . . . . . . . . 11
7.4. 2回目以降のセッション更新リクエストの生成 . . . . . . 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. Min-SEとSession-ExpiresヘッダーフィールドのIANA登録 . 19
12.2. 422(Session Interval Too Small)応答コードのIANA登録 . 20
12.3. 「timer」オプションタグのIANA登録 . . . . . . . . . . 20
13. コールフロー例 . . . . . . . . . . . . . . . . . . . . . . . 20
14. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
15. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . 25
15.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . 26
著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . 27
1. はじめに
セッション開始プロトコル(SIP)[2]では、確立したセッションに対するキープ
アライブの仕組みが定義されていない。ユーザーエージェントは、セッション
特有の仕組みを使用してセッションがタイムアウトしたかどうかを判断できる
可能性があるが、プロキシにはできない。そのため、コールステートフルプロ
キシは、セッションがまだアクティブかどうかを常に判断できるわけではな
い。たとえば、セッション終了時にユーザーエージェントがBYEメッセージ送
信に失敗した場合や、ネットワークの問題でBYEメッセージが失われた場合
に、コールステートフルプロキシは、セッションがいつ終了したかがわからな
い。この場合、コールステートフルプロキシはコールステートを保持し続け、
Donovan & Rosenberg Standards Track [Page 2]
RFC 4028 Session Timer April 2005
コールステート情報の適用をいつ止めるかを判断する方法がない。
この問題を解決するために、この拡張ではSIPセッションのためのキープアラ
イブの仕組みを定義する。UAは、定期的にre-INVITEまたはUPDATE[3]リクエス
ト(セッション更新リクエストと呼ばれる)を送信して、セッションをアライブ
の状態に保つ。セッション更新リクエストの間隔は、本文書で定義されるネゴ
シエーションの仕組みによって決定される。その間隔にセッション更新リクエ
ストを受け取らない場合、セッションは終了したとみなされる。両側のUAが
BYEを送ると想定されており、また、コールステートフルプロキシは、その呼
の任意ステートを削除できる。
この更新の仕組みには、別の用途もある。ユーザーエージェントは、コールス
テートフルプロキシサーバーの場合と同じ理由で、セッションがアクティブか
どうかを判断したい場合がある。SIPレベルの仕組みを使用しなくても、ユー
ザーエージェントでこの判断が可能である。オーディオセッションの場合、定
期的なRTCPパケットが存続(liveness)を示すものとして機能する[5]。ただ
し、SIPセッションが存続する印と、特定セッションの詳細とを分けるのが望
ましい。
また、セッションタイマーの別の用途は、SIP Network Address Translator
(NAT)Application Level Gateway (ALG)の構築[6]に記載されている。NATに組
み込まれたALGは、呼の継続期間(duration)中は、ステートを保持する必要が
ある。このステートは最終的に削除されなければならない。ステート削除のト
リガをBYEに依存すると、信頼性の問題とは別に、DoS攻撃(denial of service
attack)の原因になる可能性もある。
本文書では、セッション有効期限(session expiration)の仕組みを定義する
SIP拡張を提示する。re-INVITEまたはUPDATEを使用して定期的に更新すること
で、セッションがアクティブに保たれる。ダイアログの参加者2人のうち、い
ずれかがこの拡張を理解していれば、この拡張はSIPとの下位互換性がある。2
つの新規ヘッダーフィールド(Session-ExpiresとMin-SE)、および1つの新規応
答コード(422)が定義される。Session-Expiresはセッションの継続期間を伝達
し、Min-SEはセッション有効期限として許容される最小値を伝達する。422応
答コードは、セッションタイマーの継続期間が短かすぎることを示す。
2. 用語
本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、
「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、
「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119[1]に記載されるとおり
に解釈されるべきであり、準拠のためのSIPの実装レベルを示すものである。
Donovan & Rosenberg Standards Track [Page 3]
RFC 4028 Session Timer April 2005
さらに、以下の用語を定義する。
セッション間隔(Session Interval): 1ダイアログで、セッションがタイムア
ウトしたとみなされるまでにセッション更新リクエスト間に生じる可能性
のある最大時間。セッション間隔は、本文書で定義されるSession-Expires
ヘッダーフィールドで伝達される。UASは、送信するセッション更新リクエ
ストに対する2xx応答のSession-Expiresヘッダーフィールドからこの値を
取得する。プロキシとUACは、受け取るセッション更新リクエストに対する
2xx応答のSession-Expiresヘッダーフィールドからこの値を確定する。
ミニマムタイマー(Minimum Timer): ダイアログ中のリクエストの処理負荷を
抑えるために、すべての要素(プロキシ、UAC、UAS)は、セッション間隔に
ついて希望の最小値を設定することができる。この値はミニマムタイマー
と呼ばれる。
セッション有効期限(Session Expiration): この期限までにセッション更新
トランザクションが成功しない場合、要素はセッションがタイムアウトし
たとみなす。
セッション更新リクエスト(Session Refresh Request): 本仕様の規則に従っ
て処理されるINVITEまたはUPDATEリクエスト。リクエストによって2xx応答
が生成されると、セッション有効期限は、現在の時間に応答から取得した
セッション間隔を足した時間まで延ばされる。セッション更新リクエスト
は、[2]のセクション6で定義されているターゲット更新リクエスト(ダイア
ログのリモートターゲットを更新できるリクエスト)と混同されるものでは
ない。
初回セッション更新リクエスト(Initial Session Refresh Request): 特定の
Call-ID値で送信される最初のセッション更新リクエスト。
後続セッション更新リクエスト(Subsequent Session Refresh Request): 初回
セッション更新リクエストの後に、特定のCall-ID値で送信されるセッショ
ン更新リクエスト。
更新(Refresh): セッション更新リクエストと同様。
3. 操作の概要
このセクションでは、拡張の操作について概要を説明する。このセクションの
性質はチュートリアルであり、規範と見なすべきではない。
この拡張には、ダイアログ内で1個のUAのみが対応する場合でも動作するとい
う特徴がある。処理手順は、4つの場合(UACが対応、UACが対応しない、UASが
対応、UASが対応しない)を操作する方法で異なる。話を単純にするために、
このセクションでは、UACとUASの両側がこの拡張に対応する場合、という基本
Donovan & Rosenberg Standards Track [Page 4]
RFC 4028 Session Timer April 2005
的な操作について解説する。
UACはINVITEを送信することで開始される。このINVITEには、この拡張への対
応を示すオプションタグ「timer」付きのSupportedヘッダーフィールドが含ま
れる。
このリクエストは複数プロキシを経由する。その個々のプロキシが、セッショ
ンタイマーの確立に関連する可能性がある。各プロキシは、Session-Expires
ヘッダーフィールドとMin-SEヘッダーフィールドがリクエストにない場合、リ
クエストに挿入することができる。また、後述のように、既存のSession-
ExpiresとMin-SEのヘッダーフィールド値を変更することができる。
Min-SEヘッダーフィールドによって、セッション更新間隔の下限が決まる。つ
まり、このリクエストをサービスするプロキシが要求できる最短の更新頻度が
決定される。このヘッダーフィールドの目的は、悪意のあるプロキシが、隣接
するプロキシを過負荷にする目的で任意の短い更新間隔を設定できないように
することである。リクエストを処理する各プロキシは、この下限を上げる(更
新間隔を長くする)ことはできるが、下げることはできない。
Session-Expiresヘッダーフィールドによって、セッション更新間隔の上限が
決まる。つまり、リクエストが処理された後に、セッションステートフルなプ
ロキシがこのセッションのステートを保持する必要がある期間が決定される。
このリクエストをサービスするプロキシはいずれも、この値を低くすることは
できるが、Min-SEヘッダーフィールドで指定された値よりも低くすることはで
きない。
あるプロキシでSession-Expiresの間隔が短すぎる場合(つまり、プロキシで指
定するMin-SEの値よりも低い場合)、プロキシは422応答でそのリクエストを拒
否する。その応答には、Min-SEヘッダーフィールドが含まれ、プロキシの希望
する最小セッション間隔が指定される。次から、UACは、そのMin-SEヘッダー
フィールドをリクエストに含めて再試行する。ヘッダーフィールドには、それ
までに受け取ったすべての422応答のうち、最大のMin-SEヘッダーフィールド
値が含まれる。このようにして、ミニマムタイマーはパス上のプロキシすべて
の制約に合致する。
INVITE/422のやり取りを数度繰り返した後、リクエストは最終的にUASへ到達
する。UASは、プロキシのようにセッション間隔の値を調整でき、調整する場
合は、2xx応答のSession-Expiresヘッダーフィールドに最終のセッション間隔
を含める。また、Session-Expiresヘッダーフィールドには「refresher」パラ
メータが含まれる。これは、更新を実行している側のUA(現在UACであるUA、ま
たは現在UASであるUA)を示す。2xx応答がプロキシの連鎖を戻って行くとき
に、各プロキシは最終のセッション間隔を確認できるが、変更はできない。
Donovan & Rosenberg Standards Track [Page 5]
RFC 4028 Session Timer April 2005
応答のSession-Expiresヘッダーフィールドから、両側のUAは、セッションタ
イマーについて、アクティブであること、期限切れになるタイミング、更新者
を確認できる。期限切れ前のある時点でアクティブな更新側(refresher)が、
セッション更新リクエスト(re-INVITEまたはUPDATE[3]リクエスト)を生成す
る。更新側は、セッション更新リクエストに対する応答を受け取らなかった場
合、BYEを送信してセッションを停止する。同様に、相手側がセッション期限
切れ前にセッション更新リクエストを受け取らなかった場合、相手側がBYEを
送信する。
セッションが確立される度に1度送信される更新リクエストは、上記のよう
に、最初のリクエストと同様に処理される。これは、セッション更新リクエス
トが成功すると、希望通りにセッションが延長されることを意味する。
この拡張では、一方のUAのみが対応する場合を考慮に入れているため、この基
本フローには収まらない複雑な部分がある。複雑な部分のひとつは、UASが拡
張に対応していない場合に、プロキシが応答にSession-Expiresヘッダー
フィールドを挿入する必要が出てくる可能性がある、ということである。更新
側の役割のネゴシエーションは、この能力にも影響される。つまり、どの参加
者が拡張に対応するかが考慮される。
セッションタイマーが更新するのはセッションであり、セッションを確立する
ために使用されるダイアログではない、という点は注意すべきである。当然な
がら、この2つは関連している。セッションが期限切れになると、BYEが送信さ
れる。これによって、セッションと、通常はダイアログも停止される。
4. Session-Expiresヘッダーフィールドの定義
Session-Expiresヘッダーフィールドでは、SIPセッションのセッション間隔が
伝達される。このヘッダーフィールドは、INVITEまたはUPDATEに対する2xx応
答と同様に、INVITEまたはUPDATEリクエストにのみ含まれる。SIPのExpires
ヘッダーフィールドと同様に、このヘッダーフィールドには差分時間(delta-
time)が含まれる。
Session-Expiresヘッダーフィールドの絶対最小値は、90秒である。この値
は、SIPトランザクションがタイムアウトする場合に取られる継続期間の2倍よ
りもやや多い。これによって、UAは、セッション間隔の半ばで、余裕を持って
更新を試行できる。また、このトランザクションは、セッションが期限切れに
なる前に正常に完了できる。ただし、Session-Expiresヘッダーフィールドの
値としては、1800 秒(30分)が推奨される[RECOMMENDED]。言い替えると、SIP
エンティティは、90 秒より長い継続期間のSession-Expiresヘッダーフィール
ド値であれば、処理できるように準備しなければならない[MUST]が、Session-
Expiresヘッダーフィールドを挿入するエンティティは、30分未満の値を選択
するべきではない[SHOULD NOT]。
Donovan & Rosenberg Standards Track [Page 6]
RFC 4028 Session Timer April 2005
セッション間隔を短くすると、ネットワークに悪影響を与える可能性がある。
メッセージトラフィックが過剰になり、ユーザーエージェントとプロキシサー
バーの双方に影響を及ぼす結果となる。両側のユーザーエージェントが同時に
re-INVITEまたはUPDATEを送信するときに発生する「にらみ合い(glare)」の可
能性が大きくなる。セッションタイマーの主な目的は、SIP要素にステートを
時間切れにする手段を提示することなので、通常、極度に小さな値は必要とさ
れない。30分という値は、通話の95%がこの継続期間よりも短いので選択され
た。ただし、30分という最小値は、MUSTではなくSHOULDと記載されている。そ
の理由は、この数値は、ネットワーク帯域、ネットワークの待ち時間
(latencies)、演算能力、利用可能メモリ、ネットワークトポロジー、さらに
当然ながらアプリケーションの実装方法など、多くのネットワーク的要因に
よって異なるためである。いずれにせよ、SIPは電話の通話だけではなく、
どのようなセッションでもセットアップできる。本文書の発行時点では、30分
が適切と思われる。技術の進歩によっては、5年後には数値が大きすぎること
になる可能性もある。
Session-Expiresヘッダーフィールドのデフォルト値は未定義である。つま
り、Session-Expiresヘッダーフィールドがない場合、本仕様で定義されるメ
カニズムを使用するセッションの有効期限はないということである。本仕様で
は、ローカルで構成されるタイマーなど、適用可能な他のメカニズムは定義さ
れていない、ということに注意。
Session-Expiresヘッダーフィールドの構文は以下の通り。
The syntax of the Session-Expires header field is as follows:
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
短縮形の文字「x」はSession-Expiresに予約されているため、注意すること。
delta-secondsとgeneric-paramのBNFはRFC 3261 [2]のセクション25で定義さ
れている。
Donovan & Rosenberg Standards Track [Page 7]
RFC 4028 Session Timer April 2005
表1は、Session-ExpiresヘッダーとMin-SEヘッダーフィールドのために、[2]
の表2と表3を拡張したものである。「PRA」列はPRACKメソッド[7]、「UPD」は
UPDATEメソッド [3]、「SUB」はSUBSCRIBEメソッド [8]、「NOT」はNOTIFYメ
ソッド [8]を示す。
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
| 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 | - | - |
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
表1: Session-ExpiresとMin-SEヘッダーフィールド
5. Min-SEヘッダーフィールドの定義
Min-SEヘッダーフィールドは、セッション間隔の最小値を差分秒(delta-
seconds)単位で示す。INVITEまたはUPDATEリクエストで使用されるときは、そ
のセッションで使用できるセッション間隔の最小値を示す。リクエストまたは
応答で提示する場合、その値は90秒未満にしてはならない。
このヘッダーフィールドが存在しない場合、デフォルト値は90秒である。
422応答コードが含まれる応答以外で、Min-SEヘッダーフィールドを使用して
はならない[MUST NOT]。これは、サーバーが許容するセッション間隔の最小値
を示す。
Min-SEヘッダーフィールドの構文は以下の通り。
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
6. 422応答コードの定義
この拡張では、422(Session Interval Too Small/セッション間隔が短すぎる)
応答コードを取り入れる。この応答コードは、サーバーのミニマムタイマーよ
りも継続期間が短いSession-Expiresヘッダーフィールドがリクエストに含ま
れる場合に、UASまたはプロキシによって生成される。422応答には、そのサー
バーのミニマムタイマーを持つMin-SEヘッダーフィールドを含めなければなら
ない[MUST]。
Donovan & Rosenberg Standards Track [Page 8]
RFC 4028 Session Timer April 2005
7. UACの動作
7.1. 最初のセッション更新リクエストの生成
本文書で定義されるセッションタイマー拡張に対応するUACは、各リクエスト
(Ackを除く)にSupportedヘッダーフィールドを含め、オプションタグ
「timer」[2]を列挙しなければならない[MUST]。UACがこのセッションにセッ
ションタイマーを使用することを要求していない場合でも、そうしなければな
らない[MUST]。
UACは、リクエストに値が「timer」のRequireヘッダーフィールドを含めて、
UASがセッションに参加するにはセッションタイマーに対応しなければならな
いことを示してもよい[MAY]。これはUACがUASに更新を実行するように要求し
ているのではなく、単にUASがこの拡張に対応することを要求しているだけで
ある。さらに、UACは、リクエストに値が「timer」のProxy-Requireヘッダー
フィールドを含めて、プロキシがリクエストを正しく処理するには、セッショ
ンタイマーに対応しなければならないことを示してもよい[MAY]。ただし、UAC
がRequireまたはProxy-Requireを使用することは推奨されない
[NOT RECOMMENDED]。必要ないのは、UACのみがこの拡張に対応している場合で
も拡張は機能するためである。「timer」が指定されているSupportedヘッダー
は、RequireやProxy-Requireヘッダーフィールドに「timer」が指定された場
合でも、そのままにしなければならない[MUST]。
UACは、最初のINVITEリクエストにMin-SEヘッダーフィールドを含めてもよい
[MAY]。
UACは、セッションにセッションタイマーが適用されることを望む場合、最初
のセッション更新リクエストにSession-Expiresヘッダーフィールドを含めて
もよい[MAY]。このヘッダーフィールドの値は、UACが希望するセッション間隔
を示す。Min-SEヘッダーを最初のセッション更新リクエストに含める場合、
Session-Expiresの値は、Min-SE内の値以上でなければならない[MUST]。
UACは、更新を実行したい場合、値「uac」のrefresherパラメータを含めても
よい[MAY]。ただし、下記のネゴシエーションの仕組みで選択できるように、
このパラメータを省略することが推奨される[RECOMMENDED]。
7.2. 2xx応答の処理
セッションタイマーでは、UAがステートを生成および維持できる必要がある。
このステートには、セッション間隔、セッション有効期限、更新側のアイデン
ティティが含まれる。このステートは、セッションがネゴシエートしてきたダ
イアログと関連づけられる。
Donovan & Rosenberg Standards Track [Page 9]
RFC 4028 Session Timer April 2005
セッション更新リクエストに対する2xx応答では、Requireヘッダーフィールド
に値「timer」が含まれる場合と、含まれない場合がある。含まれる場合、UAC
は、応答を処理するためにSession-Expiresヘッダーフィールドを確認しなけ
ればならない[MUST]。
応答のRequireヘッダーフィールドに値「timer」が指定される場合、Session-
Expiresヘッダーフィールドは常に存在する。UACは、たとえリクエストに
Session-Expiresヘッダーフィールドがなくても、応答で受け取れるように準
備しなければならない[MUST]。「refresher」パラメータはSession-Expires
ヘッダーフィールドで指定され、誰が更新を実行するかを示す。UACは、この
パラメータの値に更新側のアイデンティティを設定しなければならない
[MUST]。パラメータに値「uac」が含まれる場合、UACが更新を実行する。UAC
がセッションタイマーを要求した(したがってリクエストにSession-Expires
ヘッダーフィールドを含めた)が、2xx応答にRequireもSession-Expiresもな
かった、という可能性はある。このようなことは、UASがセッションタイマー
拡張に対応せず、UACのみがセッションタイマーを要求した(プロキシは要求し
なかった)場合に起こる。このような場合でも、UACがセッションタイマーを
(純粋に自身の利益のために)使用したい場合、UACが実行しなければならな
い。実行するには、UACは、Session-Expiresヘッダーが2xx応答にあり、その
値がリクエストのものと同じだがrefresherパラメータは「uac」であるかのよ
うに、この仕様で定義される手順に従う。
2xx応答にSession-Expiresヘッダーフィールドが含まれていなかった場合、
セッション有効期限はない。この場合、更新が送信される必要はない。
Session-Expiresが含まれない2xxは、最初のセッション更新リクエストと、後
続セッション更新リクエストのいずれに対しても送信される可能性がある。こ
れは、Session-Expiresヘッダーフィールドなしの応答を受け取ることによっ
て、セッションタイマーがダイアログ中に「停止(turned-off)」される可能性
がある、ということを意味する。
UACは、セッションのセッション間隔を、ダイアログのセッション更新リクエ
ストに対する最新の2xx応答に含まれるSession-Expiresヘッダーフィールドの
差分時間(delta-time)値として記憶している。1個のINVITEの結果として確立
した異なるダイアログ上で異なるセッション間隔がある(あるいはセッション
間隔がまったくない)ことは、明確に許容されている。また、UACは、UAC自身
と相手のどちらがセッションの更新側かについても記憶する。
UACが更新を実行しなければならない場合、UACはそのセッションのセッション
有効期限を計算する。セッション有効期限は、そのダイアログ上のセッション
更新リクエストに対する最後の2xx応答の受信時間に、そのセッションのセッ
ション間隔を足した時間である。UAがセッション有効期限の後もセッションを
継続したい場合、セッション有効期限の前に更新を生成しなければならない
[MUST]。この更新は、セッション間隔の半分が経過した時点で送信することが
Donovan & Rosenberg Standards Track [Page 10]
RFC 4028 Session Timer April 2005
推奨される[RECOMMENDED]。更新の別の手順については、セクション10に記載
されている。
同様に、セッションの更新以外の目的でre-INVITEまたはUPDATEリクエストが
ダイアログ内で送信された場合も、セッションを更新する効果がある。また、
その処理は、本仕様で定義される手順に従う。
7.3. 422応答の処理
セッション更新リクエストに対する応答が422(Session IntervalTooSmall)応
答メッセージである場合、UACはリクエストを再試行してもよい[MAY]。再試行
の手順はセクション7.4に記載されている。この新規のリクエストによって新
規のトランザクションが構成される。また、この新規のリクエストは、前のリ
クエストのCall-ID、To、Fromと同じ値を持つべき[SHOULD]だが、CSeqは、前
のものよりも1大きい新規のシーケンス番号を含めるべきである。
7.4. 2回目以降のセッション更新リクエストの生成
最初のセッション更新リクエストで使用されるSupported、Require、Proxy-
Requireの値を使用しなければならない[MUST]。
UACが、同じダイアログで以前のセッション更新リクエストに対して422応答を
受け取ったことがある場合、または、同じダイアログでMin-SEヘッダーフィー
ルドを含むセッション更新リクエストを受け取ったことがある場合、UACはそ
のダイアログのセッション更新リクエストにMin-SEヘッダーフィールドを挿入
しなければならない[MUST]。同様に、まだダイアログが確立されていない場合
に、UACが同じCall-IDを持つ以前のINVITEリクエストに対して422応答を受け
取ったことがあれば、UACはINVITEリクエストにMin-SEヘッダーフィールドを
挿入しなければならない[MUST]。
セッション更新リクエストで指定されるMin-SEヘッダーフィールドの値は、ダ
イアログが確立されている場合は、同じダイアログにおいて、すべての422応
答で返されたMin-SEヘッダーフィールド値、またはセッション更新リクエスト
で受け取ったMin-SEヘッダーフィールド値のうち、最大値でなければならない
[MUST]。ダイアログが確立されていない場合、Min-SEヘッダーフィールドの値
は、同じCall-IDを持つINVITEリクエストに対するすべての422応答で返された
Min-SE値の最大値が設定される。この規則の結果として、ダイアログが確立さ
れると、Min-SEの最大値が事実上「クリア」され、その時点から、プロキシパ
スにあるプロキシからの値のみが使用されることになる。
UACは、最小セッション間隔について自身の見解を持ってもよい。その際に、
上記の値が小さすぎる場合、UACは値を増やしてもよい[MAY]。
Donovan & Rosenberg Standards Track [Page 11]
RFC 4028 Session Timer April 2005
アクティブなセッションタイマーを持つダイアログ内で送信されたセッション
更新リクエストには、Session-Expiresヘッダーフィールドが存在すべきであ
る[SHOULD]。提示する場合は、Min-SEヘッダーフィールドの最大値(提示しな
い場合の初期値は90)、および現在のセッション間隔と等値にすべきである
[SHOULD]。Session-Expiresヘッダーフィールドをこの値にすることで、DoS攻
撃をある程度防ぐことができる(セクション11参照)。そのため、UAは、(例外
的だが)ダイアログ中にセッション間隔を変更するのが不適切な場合にのみ、
このSHOULD指定を無視すべきである。
最初のセッション更新リクエストではない場合、リクエストを送信する要素が
現在更新を実行しているときは、refresherパラメータを「uac」に、そうでは
なく、相手が更新を実行しているときは「uas」と設定することが推奨される
[RECOMMENDED]。こうすると、更新側の役割は更新ごとには変わらない。ただ
し、明示的に役割を変更したい場合は、相手側がセッションタイマーに対応し
ていることがわかっていれば、「uas」の値を使用してもよい[MAY]。相手が対
応しているかどうかは、相手からSupportedヘッダーフィールドに値「timer」
が指定されたリクエストを受信することで判断できる。役割を選択し直したい
場合は、パラメータを省略してもよい[MAY]。
セッション更新のために生成されたre-INVITEは通常のre-INVITEであり、セッ
ション更新のために生成されたUPDATEも通常のUPDATEである。相手がUPDATEメ
ソッドに対応していることをUACがわかっている場合、re-INVITEではなく
UPDATEを使用することが推奨される[RECOMMENDED]。UPDATEへに対応している
ことは、相手から値「UPDATE」を含むAllowヘッダーフィールドを受け取る
か、ダイアログ中のOPTIONSリクエストによってわかる。UPDATEリクエストに
はオファー [4]を含めないことが推奨される[RECOMMENDED]が、re-INVITEの場
合は、たとえセッションの詳細に変更がなくても、含めるべきであ
る[SHOULD]。その場合、オファーでは、変更されていないことと示さなければ
ならない[MUST]。これは、SDPの場合、相手に対する以前のSDPメッセージと同
じ値を最初のフィールドに含めることによって実行される。セッション更新リ
クエストの結果として交換される応答にも同様のことが言える。変更がなかっ
た場合は、それを示さなければならない[MUST]。
8. プロキシの動作
セッションタイマーは、主にコールステートフルプロキシサーバー(つまり、
確立したコールステートとダイアログステートを維持するサーバー)を対象と
している。ただし、ステートフルプロキシサーバー(つまり、トランザクショ
ンステートを認識するが、コールステートまたはダイアログステートを保持し
ないサーバー)は、本文書に記載される規則にも従ってよい[MAY]。ステートレ
スプロキシは、セッションタイマーの要求を試行してはならない[MUST NOT]。
セッションタイマーを要求するプロキシは、record-routeしなければ更新を受
け取ることがないので、record-routeするべきである[SHOULD]。
Donovan & Rosenberg Standards Track [Page 12]
RFC 4028 Session Timer April 2005
プロキシ処理規則として、プロキシがリクエストと応答間の情報を記憶
しておく必要があるが、ステートフルプロキシは除外される。
8.1. リクエストの処理
リクエストの処理方法は、すべてのセッション更新リクエストと同様である。
セッションにセッションタイマーを要求するために、プロキシは、セッション
に対するセッション更新リクエストにSession-Expiresヘッダーフィールドが
存在することを確認する。プロキシは、転送する(forward)リクエストに
Session-Expiresヘッダーフィールドが存在しなければ、転送前に挿入しても
よい[MAY]。このSession-Expiresヘッダーフィールドには、プロキシの希望す
る任意の有効期限を含めてもよいが、リクエストにMin-SEヘッダーフィールド
があれば、その値よりも短い継続期間を指定することはできない。プロキシ
は、ヘッダーフィールド値にrefresherパラメータを含めてはならない
[MUST NOT]。
リクエストにSession-Expiresヘッダーフィールドが存在していた場合、プロ
キシはその値を減少させてもよい[MAY]が、リクエストにMin-SEヘッダー
フィールドがあれば、その値よりも短い継続期間に設定してはならない
[MUST NOT]。Session-Expiresヘッダーフィールドの値がMin-SEヘッダー
フィールドの値以上の場合(Min-SEヘッダーフィールドが提示されないときの
初期値は90秒)、プロキシはSession-Expiresヘッダーフィールドの値を増やし
てはならない[MUST NOT]。Session-Expiresヘッダーフィールドの値がMin-SE
ヘッダーフィールドの値未満の場合(おそらく、後述のようにプロキシがMin-
SEヘッダーフィールドの値を増やしたため)、プロキシは、Session-Expires
ヘッダーフィールドの値をMin-SEヘッダーフィールドと同じになるように増や
さなければならない[MUST]。プロキシは、Session-Expiresヘッダーフィール
ドに「refresher」パラメータの値を挿入したり、パラメータの値を修正して
はならない[MUST NOT]。
リクエストのSupportedヘッダーフィールドに値「timer」が指定されている場
合、Session-Expiresヘッダーフィールドのセッション間隔がプロキシのロー
カルポリシーで定義されている最小間隔未満であれば、そのINVITEリクエスト
を422(Seesion Interval Too Small)応答で拒否してもよい[MAY]。422応答を
送信する場合、プロキシは、自身の最小間隔値を指定したMin-SEヘッダー
フィールドを含めなければならない[MUST]。この最小値は、90秒未満にしては
ならない[MUST NOT]。
リクエストでセッションタイマーへの対応が示されていないが、リクエストに
含まれるセッション間隔が短すぎる場合、結果として呼が失敗することになる
ため、プロキシはそのリクエストを拒否することはできない。そうではなく、
プロキシは、自身の最小間隔を指定したMin-SEヘッダーフィールドを挿入する
べきである[SHOULD]。Min-SEヘッダーフィールドがすでに存在する場合、プロ
キシは、自身の最小間隔までその値を増やすべきである[SHOULD](ただし、減
らしてはならない[MUST NOT])。その後、前述のように、プロキシはMin-SE
ヘッダーフィールドの値と等しくなるようにSession-Expiresヘッダーフィー
Donovan & Rosenberg Standards Track [Page 13]
RFC 4028 Session Timer April 2005
ルド値を増やさなければならない[MUST]。プロキシされるリクエストの
Supportedヘッダーフィールドに、値「timer」が指定されている場合、プロキ
シは、そのリクエストにMin-SEヘッダーフィールドを挿入したり、またはその
リクエストに含まれる既存のヘッダーフィールド値を修正してはならない
[MUST NOT]。これは、ある種のDoS攻撃を防ぐために必要であり、詳しくは
セクション11で説明される。
プロキシがセッションタイマーを要求している(したがって、おそらくSession
-Expiresヘッダーフィールドを挿入したか、減らした)と仮定すると、プロキ
シは、セッションタイマーを使用していることを記憶し、また、プロキシした
リクエストのSession-Expiresヘッダーフィールド値も記憶しなければならな
い[MUST]。これはトランザクションの継続期間中は記憶されていなければなら
ない[MUST]。
プロキシは、トランザクションの継続期間中、リクエストのSupportedヘッ
ダーに値「timer」が指定されていたかどうかを記憶していなければならない
[MUST]。リクエストのSupportedヘッダーフィールドに値「timer」が指定され
ていなかった場合、プロキシは、リクエストに値「timer」が指定された
Requireヘッダーフィールドを挿入してもよい[MAY]。ただし、これは推奨され
ない[NOT RECOMMENDED]。理由は、プロキシがセッションに対してセッション
タイマーを強要できるようになるためである。リクエストにSupportedヘッ
ダーフィールドがある場合、Requireヘッダーフィールドは不要である。この
場合、プロキシは、そのセッションにセッションタイマーが使用される可能性
があることを確認する。
8.2. 応答の処理
リクエストに対する最終応答が届くと、プロキシが検査する。
プロキシは、(プロキシするリクエストにSession-Expiresヘッダーフィールド
を挿入したり、既存のヘッダーフィールドを修正したり、確認してそのまま受
け入れたことによって)リクエストでセッションにセッションタイマーを要求
したことを記憶しているが、応答にSession-Expiresヘッダーフィールドが含
まれていなかった場合、UASがセッションタイマーに対応しなかったことを示
す。UACもセッションタイマーに対応しなかったことをプロキシが記憶してい
る場合、プロキシは、通常通り、応答をアップストリームに転送する。この
セッションにはセッション有効期限がない。ただし、UACがセッションタイ
マーに対応していたことをプロキシが記憶している場合、別の処理が必要であ
る。
応答にSession-ExpiresまたはRequireヘッダーフィールドがないことから、プ
ロキシは、応答を受け取るプロキシのうち、自身がセッションタイマーを認識
する最初のプロキシであることが判断できる。このプロキシは、転送したリク
エストで記憶しておいた値を応答のSession-Expiresヘッダーフィールドに指
定しなければならない[MUST]。また、「refresher」パラメータの値を「uac」
に設定しなければならない[MUST]。プロキシは、応答のすべてのRequireヘッ
Donovan & Rosenberg Standards Track [Page 14]
RFC 4028 Session Timer April 2005
ダーフィールドに「timer」オプションタグを追加しなければならない
[MUST]。また、Requireヘッダーフィールドが存在しなかった場合、アップス
トリームに転送する前にその値でRequireヘッダーフィールドを追加しなけれ
ばならない[MUST]。
受け取った応答にSession-Expiresヘッダーフィールドが含まれる場合、応答
の修正は必要ない。
いかなる場合でも、プロキシがアップストリームに転送した2xx応答にSession
-Expiresヘッダーが含まれる場合、その値は、その応答に関連付けられるセッ
ションのセッション間隔を表す。プロキシは、2xx応答がアップストリームに
転送された時間にセッション間隔を足したものをセッション有効期限として計
算する。このセッション有効期限によって、そのセッションの既存のセッショ
ン有効期限は更新されなければならない[MUST]。アップストリームに転送され
た2xx応答のSession-Expiresヘッダーフィールドには、refresherパラメータ
が存在する。また、refresherには、どちらのUAが更新を実行するかが示され
る。1つのINVITEに対して複数の2xx応答が存在し、個々の応答が異なるダイア
ログを示す可能性がある。結果として、各ダイアログに関連付けられたセッ
ションごとにセッション有効期限が1つずつという、複数のセッション有効期
限が存在することになる。
プロキシは、受け取った応答にSession-Expiresヘッダーフィールドが存在す
る場合、その値をアップストリームに転送する前に修正してはならない[MUST
NOT]。
8.3. セッション有効期限:
現在の時間がセッションのセッション有効期限と同時か超過している場合、プ
ロキシは関連するコールステートを削除してもよく[MAY]、その呼に関連付け
られているすべてのリソースを解放してもよい[MAY]。UAとは異なり、プロキ
シはBYEを送ってはならない[MUST NOT]。
9. UASの動作
UASは、リクエストのパス上のUACまたはプロキシから送信されたセッションタ
イマーの要求に対しては、応答しなければならない。あるいは、セッションタ
イマーを使用されるようにUASが要求してもよい。
受信リクエストで、Supportedヘッダーフィールドに値「timer」が指定され、
Session-Expiresヘッダーフィールドが含まれる場合、Session-Expiresヘッ
ダーフィールドのセッション間隔がUASのローカルポリシーで定義されている
最小間隔よりも短ければ、UASは422(Session Interval Too Small)応答で
INVITEリクエストを拒否しても良い[MAY]。UASは、422応答を送信するとき
に、自身の最小間隔値を指定したMin-SEヘッダーフィールドを含めなければな
らない[MUST]。この最小間隔は、90秒未満にしてはならない[MUST NOT]。
UASは、リクエストを受け入れたい場合、Session-Expiresヘッダーフィールド
の値をリクエストから2xx応答へコピーする。
Donovan & Rosenberg Standards Track [Page 15]
RFC 4028 Session Timer April 2005
UASの応答では、この値を減らしてもよい[MAY]が、リクエストにMin-SEヘッダ
ーフィールドが存在する場合、その値よりも短い継続期間に設定してはならな
い[MUST NOT]。Min-SEヘッダーフィールドがない場合、UASはこの値を減らし
てもよい[MAY]が、90秒よりも短い継続期間に設定してはならない[MUST NOT]。
UASは、Session-Expiresヘッダーフィールドの値を増やしてはならない
[MUST NOT]。
受信リクエストで、Supportedヘッダーフィールドに値「timer」は指定されて
いるが、Session-Expiresヘッダーが含まれない場合、UASは、タイマーには対
応しているが、対応することは要求していないことを示す。UASは、2xx応答に
Session-Expiresヘッダーフィールドを含めることでセッションタイマーを要
求することができる。リクエストのMin-SEヘッダーフィールドに値が指定され
ている場合、Session-Expiresヘッダーフィールドの値は、Min-SEヘッダー
フィールド値よりも短い継続期間に設定してはならない[MUST NOT]。
UASは、2xx応答のSession-Expiresヘッダーフィールドにrefresherパラメータ
値を設定しなければならない[MUST]。この値には、ダイアログの更新を誰が実
行するかを指定する。値は、リクエストで指定されているこのパラメータ値
と、UACがセッションタイマー拡張に対応しているかどうかに基づく。リクエ
ストのSupportedヘッダーフィールドに「timer」オプションタグが指定された
場合、UACはこの拡張に対応している。表2で応答中の値がどのように設定され
るかを定義する。2列目の「none」という値は、そのリクエストにrefresherパ
ラメータがないことを意味する。3列目の「NA」という値は、プロトコルが許
容していないため、その組み合わせを使用すべきではないことを意味する。
UACのサポート リクエストの 応答の
refresherパラメータ refresherパラメータ
---------------------------------------------------------
N なし uas
N uac 適用なし
N uas 適用なし
Y なし uas または uac
Y uac uac
Y uas uas
表2: UASの動作
表3の4行目では、UACとUASの双方がセッションタイマー拡張に対応し、また、
UACが更新を実行する側を選択していない場合について記載している]。この場
合、UASとUACのどちらが更新を実行するのかをUASが決定できる。ただし、表
に記載されているように、UAC自身が更新側になることを選択した場合、UASは
それを無効にすることはできない。
2xx応答に含まれるSession-Expiresヘッダーフィールドのrefresherパラメー
タが値「uac」である場合、UASは値「timer」を指定したRequireヘッダー
フィールドを応答に含めなければならない[MUST]。これは、更新を実行するの
Donovan & Rosenberg Standards Track [Page 16]
RFC 4028 Session Timer April 2005
はUACであり、UACに値を知らせるように応答を処理する必要があるためであ
る。2xx応答のrefresherパラメータに値「uas」が指定され、リクエストの
Supportedヘッダーフィールドに値「timer」が指定された場合、UASは応答の
Requireヘッダーフィールドに値「timer」を指定すべきである[SHOULD]。この
場合、UACは更新を行わないが、更新の受け取りを止める場合、UACはBYEを送
信することになっている。UACがBYEを送信しなくても呼は成功するため、この
Requireの挿入は、MUSTというよりもSHOULDである。
UACと同様に、UASはセッションタイマーのステートを格納する。このステート
には、セッション間隔、セッション有効期限、更新側のアイデンティティが含
まれる。ステートは、セッションを確立するために使用されるダイアログに結
合される。セッション間隔は、ダイアログ上のセッション更新リクエストに対
する最新の2xx応答に含まれる、Session-Expiresヘッダーフィールドの差分時
間値に設定される。また、自身と相手側のどちらがそのダイアログで更新側か
についても記憶する。この情報は、そのダイアログのセッション更新リクエス
トに対する最新の2xx応答の、refresherパラメータ値に基づく。最新の2xx応
答にSession-Expiresヘッダーフィールドがない場合、セッション有効期限は
なく、更新を実行する必要はない。
UASがセッションを更新しなければならない場合、セッション有効期限を計算
する。セッション有効期限は、そのダイアログ上のセッション更新リクエスト
に対する最後の2xx応答の送信時間に、セッション間隔を足した時間である。
UAがセッション有効期限の後もセッションを継続したい場合、セッション有効
期限の前に更新を生成しなければならない[MUST]。この更新は、セッション間
隔の半分が経過した時点で送信することが推奨される[RECOMMENDED]。更新の
別の手順については、セクション10に記載されている。
10. 更新の実行
更新を生成する側は、セクション7で定義されているUACの手順に従って生成す
る。セッション有効期限を延長する方法は、セッション更新リクエストに対す
る2xx応答のみであることに注意。これは、UAが更新を試みて、現在のセッ
ション間隔よりもはるかに大きい値のMin-SEヘッダーフィールドが指定された
422応答を受け取る可能性がある、ということを意味する。セッション更新リ
クエストに現在のセッション間隔よりもはるかに大きいSession-Expires値が
指定される場合でも、UAは、セッション有効期限(これは変更されていない)の
前にセッション更新リクエストを送信する必要がある。
セッション更新リクエストのトランザクションがタイムアウトするか、408応
答または481応答が生成される場合、UACは、RFC 3261[2]のセクション12.2.1.
2の規則に従って、BYEを送信する。セッション更新リクエストで2xx応答が生
成されず(結果的にセッションが更新されず)、408または481以外の応答を受信
Donovan & Rosenberg Standards Track [Page 17]
RFC 4028 Session Timer April 2005
した場合、UACは、その応答コード固有の規則に従い、また可能であれば再試
行すべきである[SHOULD]。たとえば、応答が401の場合、UACは新しい資格情報
(credentials)でリクエストを再試行する。ただし、サーバーから同じエラー
応答が返ってくる場合、UACはリクエストの再試行を続けるべきではない
[SHOULD NOT]。
同様に、更新を実行しない側は、セッション有効期限前にセッション更新リク
エストが届かない場合、セッション有効期限の少し前に、BYEを送信してセッ
ションを停止するべきである[SHOULD]。32秒とセッション間隔の1/3のうち、
小さい値の方が推奨される[RECOMMENDED]。
ファイアウォールとNAT ALGは、セッションの有効期限後にSIPトラフィックが
通過すること許容しない可能性がある。これが、期限切れ前にBYEを送信する
理由である。
11. セキュリティの考慮事項
セッションタイマーによって、プロキシまたはUA要素は、選択した頻度で更新
を送信するように、準拠UAに対して強制できるようになった。また、大幅な増
幅特性を利用してDoS攻撃が行われる可能性も生じた。こうした攻撃は、「部
外者」(通過時にメッセージを変更しようとする要素)、または「内部者」(正
規にリクエストのパス上にいるが、危害を加えようとしている要素)によって
行われる。幸い、いずれの場合もこの仕様で適切に対応できる。
11.1. 内部的な攻撃
ここでは、不良(rogue)プロキシまたはUAがDoS攻撃を行う可能性について紹介
する。一方で、この仕様の仕組みによって、その発生を防ぐ。
まず最初に、UASに対して高頻度で更新を生成するように強制しようとしてい
る不良UACの場合を検討する。この攻撃を実行するために、UACは、INVITEの
Session-Expiresヘッダーフィールドに、短い継続期間と、「uas」の
refresherパラメータを指定する。また、そのリクエストにはSupportedヘッ
ダーフィールドが指定されたと仮定する。この短いタイマーを受け入れない
UASまたはプロキシは、リクエストを422応答で拒否することによって、攻撃を
防ぐことができる。Supportedヘッダーフィールドが存在しない場合、プロキ
シは転送する前にMin-SEヘッダーフィールドをリクエストに挿入する。最終的
に、UASは、パス上のすべての要素が受け入れ可能な最小値よりも短いセッ
ションタイマーを選択しない。これによっても、攻撃が防がれる。
次に、UACに対して高頻度で更新を生成するように強制しようとしている不良
UASの場合を検討する。この場合、UACはセッションタイマーに対応している必
要がある。最初のINVITEが不良UASに到達し、UASは非常に短いセッション間隔
Donovan & Rosenberg Standards Track [Page 18]
RFC 4028 Session Timer April 2005
が指定された2xxを返す。UACはこのタイマーを使用して直ちに更新を送信す
る。セクション7.4では、UACに対して、現在のセッション間隔をリクエストの
Session-Expiresヘッダーフィールドにコピーするように要求している。これ
によって、プロキシは現在の値を確認することができる。プロキシはこのリク
エストを拒否し、より長い最小値が指定されたMin-SEを提示する。この値は、
UACで使用される。プロキシがそのリクエストを拒否せず、Min-SEヘッダー
フィールドを指定したリクエストをプロキシした場合は、攻撃は可能である、
ということに注意。UASは、2xx応答に含まれるこのヘッダーフィールドを破棄
し、UACに高頻度のリクエスト生成し続けるように強制する可能性がある。
同様に、不良プロキシは、シグナリングパス上にとどまって、すべてのリクエ
ストと応答を確認できない場合、UACまたはUASに対して更新を生成するように
強制できない。
11.2. 外部からの攻撃
通過中のリクエストと応答を監視および修正可能な要素は、高頻度のセッショ
ン更新を強制することができる。これを防ぐには、リクエストと応答をメッ
セージの整合性(integrity)で保護する必要がある。セッションタイマーの
ヘッダーフィールドはエンドツーエンドではなく、プロキシによって操作され
るため、SIPのS/MIME機能はこの用途には適さない。そうではなく、ホップバ
イホップの仕組みを使用して、整合性を保護する必要がある。したがって、
Session-Expiresヘッダーフィールド、または値「timer」のSupportedヘッ
ダーフィールドが指定されたリクエストを送信する要素が、TLSを使用して保
護することが推奨される[RECOMMENDED]。セキュリティが各ホップに適用され
た場合にのみ、適切に保護されるため、この拡張と併せてSIPS URIスキームを
使用することが推奨される[RECOMMENDED]。これは、セッションタイマーを
record-routeおよびリクエストするプロキシは、SIPS URIを使用してrecord-
routeすべきである[SHOULD]ということを意味する。リクエストまたは応答に
Session-Expiresヘッダーフィールドを挿入するUAは、SIPS URIのContact URI
を含めるべきである[SHOULD]。
12. IANA条項
この拡張では、2個の新規ヘッダーフィールド、1個の新規応答コード、1個の
新規オプションタグを定義する。SIP [2]には、IANAの登録手順が定義されて
いる。
12.1. Min-SEとSession-ExpiresヘッダーフィールドのIANA登録
Min-SEヘッダーフィールドについての登録は以下の通り。
RFC番号: RFC 4028
ヘッダー名: Min-SE
短縮形: なし
Donovan & Rosenberg Standards Track [Page 19]
RFC 4028 Session Timer April 2005
Session-Expiresヘッダーフィールドについての登録は以下の通り。
RFC番号: RFC 4028
ヘッダー名: Session-Expires
短縮形: x
12.2. 422(Session Interval Too Small)応答コードのIANA登録
422(Session Interval Too Small)応答コードについての登録は以下の通り。
応答コード: 422
デフォルトの理由フレーズ: Session Interval Too Small
RFC番号: RFC 4028
12.3. 「timer」オプションタグのIANA登録
「timer」オプションタグについての登録は以下の通り。
名前: timer
説明: このオプションタグは、セッションタイマー拡張に対応するためのもの
である。リクエストまたは応答のSupportedヘッダーフィールドに含める
と、そのUAがこの仕様に沿って更新を実行可能であることを示す。リクエ
ストのRequireヘッダーフィールドに含めると、UASは、リクエストを処理
するには、セッションタイマー拡張を理解する必要がある、ということを
意味する。応答のRequireヘッダーフィールドに含めると、UACは、応答の
Session-Expiresヘッダーフィールドを確認し、それに沿って処理しなけれ
ばならない、ということを意味する。
13. コールフロー例
セッションタイマーのフロー例
Alice Proxy P1 Proxy P2 Bob
|(1) INVITE | | |
|SE: 50 | | |
|----------->| | |
|(2) 422 | | |
|MSE: 3600 | | |
|<-----------| | |
|(3) ACK | | |
|----------->| | |
|(4) INVITE | | |
|SE:3600 | | |
|MSE:3600 | | |
|----------->| | |
Donovan & Rosenberg Standards Track [Page 20]
RFC 4028 Session Timer April 2005
| |(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 | |
| |<------------------------|
Donovan & Rosenberg Standards Track [Page 21]
RFC 4028 Session Timer April 2005
|(21) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
| |(22) BYE | |
| |<------------------------|
|(23) BYE | | |
|<-----------| | |
| |(24) 408 | |
| |------------------------>|
図1: セッションタイマーのフロー例
図1は、セッションタイマーを利用したコールフロー例を示す。この例では、
UACとUASの両方がセッションタイマー拡張に対応している。UACのAliceが生成
する最初の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
(AliceのSDPは示されない)
このリクエストは、Aliceがセッションタイマーに対応し、50秒ごとにセッ
ション更新するように要求していることを示す。これは最初のプロキシ(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
Donovan & Rosenberg Standards Track [Page 22]
RFC 4028 Session Timer April 2005
この応答には、3600という値の指定されたMin-SEヘッダーフィールドが含まれ
る。それから、Aliceはリクエストを再試行する。今回は、リクエストにMin-
SEヘッダーフィールドが含まれている。これは、Aliceは同じ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
(AliceのSDPは示されない)
プロキシP1はrecord-routeする。受け入れ可能なセッション間隔になったの
で、リクエストをP2へ転送する(メッセージ5)。だが、セッション間隔は、P2
に設定されている最小値の4000未満である。そのため、P2は422応答コードで
リクエストを拒否し(メッセージ6)、さらに4000という値を指定したMin-SE
ヘッダーフィールドを含める。もう一度、AliceはINVITEを再試行する。送信
するINVITEのMin-SEヘッダーフィールドは、Aliceがそれまでに受け取ったす
べての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
(AliceのSDPは示されない)
Donovan & Rosenberg Standards Track [Page 23]
RFC 4028 Session Timer April 2005
P1はもう一度record-routeするが、P2は行わない(通常、このようなことは発
生しない。おそらく、セッションタイマーを要求した場合、後続のリクエスト
をrecord-routeする)。UASはリクエストを受け取る。UASは、リクエストの
Session-Expiresヘッダーフィールドを応答にコピーし、値「uac」の
refresherパラメータを追加する。この200 OKは、逆にAliceに対して転送され
る。Aliceが受信する応答(メッセージ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
(BobのSDPは示されない)
AliceはACKを生成し(メッセージ16)、P1を経由してBobへルートされる。Alice
が更新側なので、約2000秒後、AliceはUPDATEリクエストを送信してセッショ
ンを更新する。このリクエストは確立したダイアログの一部であり、Aliceは
そのダイアログ上で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>
Donovan & Rosenberg Standards Track [Page 24]
RFC 4028 Session Timer April 2005
これはP1経由でBobに転送される。Bobは、200 OKを生成する。この応答には
Session-Expiresヘッダーフィールドをコピーしている。これはP1経由でAlice
に到達する。Aliceが受信する応答(メッセージ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>
その後間もなく、AliceのUAはクラッシュする。結果的に、彼女はいつまでも
セッション更新リクエストを送信しない。3968秒後、Bobはタイムアウトにな
り、BYEリクエスト(メッセージ22)を送信する。これはP1へ送信される。P1は
それを配信しようとするが失敗する(AliceのUAがクラッシュしたため)。その
後、P1はBobへ408(Request Timeout)を返す。
14. 謝辞
この研究へのBrett Tateの貢献に感謝したい。Brian Rosenが本文書の編集を
仕上げた。
15. 参考文献
15.1. 規範となる参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[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.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
Donovan & Rosenberg Standards Track [Page 25]
RFC 4028 Session Timer April 2005
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.
[6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
著者の連絡先
Steve Donovan
Cisco Systems, Inc.
2200 E. President George Bush Turnpike
Richardson, Texas 75082
US
EMail: srd@cisco.com
Jonathan Rosenberg
Cisco Systems, Inc.
600 Lanidex Plaza
Parsippany, NJ 07054
US
EMail: jdrosen@cisco.com
Donovan & Rosenberg Standards Track [Page 26]
RFC 4028 Session Timer April 2005
完全な著作権表示
Copyright (C) The Internet Society (2005).
本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に
記載されている例外に従い、著者はすべての権利を持つ。
本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿
者が代表となる組織、または寄稿者を後援する組織(存在する場合)、インター
ネット協会およびIETFは、この情報がいかなる権利も侵害していないという保
証、商用利用および特定目的への適合性への保証を含め、また、これらだけに
限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。
知的財産権
IETFは、本文書で記述される技術の実装または使用に関して要求される、知的
所有権または他の諸権利の有効性または範囲に関して、またはこのような権利
下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解
を持たない。このような権利を確認する独自の取り組みを行ったことも示さな
い。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載され
ている。
IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン
スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま
たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について
は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ
る。
IETFは、この規格を実装するために必要とされる技術の範囲にある可能性があ
る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権
について、すべての関連団体に対して配慮するよう依頼している。情報につい
ては、IETFの ietf-ipr@ietf.org まで連絡されたい。
謝辞
RFC編集職務のための資金は、現在、インターネット協会によって提供されて
いる。
-----------------------------------------------------------------------
本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの
です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ
し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの
ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に
再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ
せてご利用ください。
2005年
-----------------------------------------------------------------------
Donovan & Rosenberg Standards Track [Page 27]