RFC4411 日本語訳
4411 Extending the Session Initiation Protocol (SIP) Reason Header forPreemption Events. J. Polk. February 2006. (Format: TXT=49260 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Polk Request for Comments: 4411 Cisco Systems Category: Standards Track February 2006
コメントを求めるワーキンググループJ.ポークの要求をネットワークでつないでください: 4411年のシスコシステムズカテゴリ: 標準化過程2006年2月
Extending the Session Initiation Protocol (SIP)
Reason Header for Preemption Events
先取りイベントのためにセッション開始プロトコル(一口)理由ヘッダーを広げています。
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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred.
このドキュメントは、セッション先取りイベントの結果、Resource ReSerVationプロトコル(RSVP)かNext Stepsなどの予約ベースのプロトコルにSignaling(NSIS)にかかわるネットワークにおけるユーザエージェント(UA)かどこかのどちらかのBYE Method Requestに含まれるようにSession Initiationプロトコル(SIP)理由HeaderにIANA Registration拡張子を提案します。 このドキュメントは、パケット経路に失敗するルータを扱うのを試みません。 代わりに、それは、慎重な裂け目がUAsの間の流れの下であると扱って、起こったことのしるしで終えられたUA(s)に知らせます。
Polk Standards Track [Page 1] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Access Preemption Events ........................................4
2.1. Effects of Preemption at the User Agent ....................6
2.2. Reason Header Requirements for Access Preemption Events ....6
3. Network Preemption Events .......................................7
3.1. Reason Header Requirements for Network Preemption Events ..10
4. Including a Hybrid Infrastructure ..............................10
4.1. Hybrid Infrastructure Requirements ........................11
5. Preemption Reason Header Cause Codes and Semantics .............11
5.1. Access Preemption Event Reason Code .......................12
5.1.1. Access Preemption Event Call Flow ..................12
5.2. Network Preemption Events Reason Code .....................14
5.2.1. Network Preemption Event Call Flow .................15
5.3. Generic Preemption Event Reason Code ......................16
5.4. Non-IP Preemption Event Reason Code .......................16
5.4.1. Non-IP Preemption Event Call Flow ..................17
6. Security Considerations ........................................17
7. IANA Considerations ............................................17
7.1. "Preemption" Namespace Registry ...........................18
7.2. Default Reason-Text IANA Registry for the SIP
Reason Header .............................................20
8. Contributions ..................................................20
9. Acknowledgements ...............................................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................21
1. 序論…2 1.1. このドキュメントで中古のコンベンション…4 2. 先取りイベントにアクセスしてください…4 2.1. ユーザエージェントでの先取りの効果…6 2.2. アクセス先取りイベントのためのヘッダー要件を推論してください…6 3. 先取りイベントをネットワークでつないでください…7 3.1. ネットワーク先取りイベントのためのヘッダー要件を推論してください。10 4. ハイブリッドインフラストラクチャを含んでいます…10 4.1. ハイブリッドインフラストラクチャ要件…11 5. 先取り理由ヘッダー原因コードと意味論…11 5.1. 先取りイベント理由コードにアクセスしてください…12 5.1.1. 先取りイベント呼び出し流動にアクセスしてください…12 5.2. ネットワーク先取りイベントはコードを推論します…14 5.2.1. 先取りイベント呼び出し流動をネットワークでつないでください…15 5.3. ジェネリック先取りイベント理由コード…16 5.4. 非IP先取りイベント理由コード…16 5.4.1. 非IP先取りイベント呼び出し流動…17 6. セキュリティ問題…17 7. IANA問題…17 7.1. 「先取り」名前空間登録…18 7.2. 一口理由ヘッダーのためのデフォルト理由テキストIANA登録…20 8. 貢献…20 9. 承認…20 10. 参照…21 10.1. 標準の参照…21 10.2. 有益な参照…21
1. Introduction
1. 序論
With the introduction of the SIP Resource-Priority (R-P) header [4], there became the possibility of sessions being torn down for (scarce) resource reasons, meaning there weren't enough resources for a particular session to continue. Certain domains will implement this mechanism where resources may become constrained either at the user agent (UA) or at congested router interfaces where more important sessions are to be completed at the expense of less important sessions. Which sessions are more or less important than others will not be discussed here. What is proposed here is a SIP [2] extension to synchronize SIP elements as to why a preemption event occurred and which type of preemption event occurred, as viewed by the element that performed the preemption of a session.
SIP Resource-優先権(R-P)ヘッダー[4]の挿入でそこ、特定のセッションが続けているリソースが十分なかったことを意味して、(不十分)のリソース理由で取りこわされるセッションの可能性になりました。 ある一定のドメインはリソースが混雑しているルータインタフェースでユーザエージェント(UA)において、または、それほど重要でないセッションを犠牲にして完成されるより重要なセッションがことである強制的になるかもしれないこのメカニズムを実装するでしょう。 ここでどのセッションが他のものより多少重要であるか議論しないでしょう。 ここで提案されることは先取りイベントがなぜ起こったか、そして、どのタイプの先取りイベントが起こったかに関してSIP要素を同期させるSIP[2]拡大です、セッションの先取りを実行した要素によって見られるように。
The SIP Reason Header is an application layer feedback mechanism to synchronize SIP elements of events; the particular event explained here deals with preemption of a session. Q.850 [5] provides an
SIP Reason HeaderはイベントのSIP要素を同期させる応用層フィードバック・メカニズムです。 ここで説明された特定のイベントはセッションの先取りに対処します。 Q.850[5]は提供します。
Polk Standards Track [Page 2] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[2ページ]。
indication for preemption (cause=8) and for preemption "circuit reserved for reuse" (cause=9). Q.850 Cause=9 does not apply to IP, as IP has no concept of circuits. Some domains wish to differentiate appropriate IP reasons for preemption of sessions and to indicate topologically where the preemption event occurred. No other means exists today to give feedback as to why a session was torn down on preemption grounds.
先取り(原因=8)と「回路は再利用のために予約した」先取り(原因=9)のための指示。 IPに回路の概念が全くないとき、Q.850原因=9はIPに適用されません。 IPは適切な差別化するという何らかのドメイン願望が、セッションの先取り、先取りイベントがどこに起こったかを位相的に示すために推論します。 他の手段は、全く今日、セッションが先取りの根拠で取りこわされた理由に関してフィードバックするために存在しません。
In the event that a session is terminated for a specific reason that can (or should) be shared with SIP Servers and UAs sharing dialog, the Reason Header [1] was created to be included in the BYE Request. This was not the only Method for this new Header; [1] also discusses the CANCEL Method usage.
セッションがSIP Serversと(or should)を共有できて、対話を共有するUAs、Reason Header[1]がBYE Requestに含まれるように作成された特定の理由で終えられる場合。 これはこの新しいHeaderのための唯一のMethodではありませんでした。 また、[1]はキャンセルMethod用法について議論します。
This document will define two use cases in which new preemption Reason values are necessary:
このドキュメントはどの新しい先取りReason値が必要であるかで使用がケースに入れる2を定義するでしょう:
Access Preemption Event - This is when a UA receives a new SIP
session request message with a valid R-P value that is
higher than the one associated with the currently active
session at that UA. The UA must discontinue the existing
session in order to accept the new one (according to local
policy of some domains).
アクセスPreemption Event--これはUAがものがおまけに現在活発なセッションにUAを関連づけたより高い有効なR-P値で新しいSIPセッション要求メッセージを受け取る時です。 UAは、新しい方を受け入れる(いくつかのドメインのローカルの方針によると)ために既存のセッションを中止しなければなりません。
Network Preemption Event - This is when a network element - such
as a router - reaches capacity on a particular interface and
has the ability to statefully choose which session(s) will
remain active when a new session/reservation is signaled for
under the parameters outlined in SIP Preconditions per [3]
that would otherwise overload that interface (perhaps
adversely affecting all sessions). In this case, the router
must terminate one or more reservations of lower priority in
order to allow this higher priority reservation access to
the requested amount of bandwidth (according to local policy
of some domains).
ネットワークPreemption Event--これは、特定のインタフェースのルータなどのネットワーク要素が容量に達する時であり、1そうでなければそのインタフェースを積みすぎる[3]あたりのSIP Preconditionsに概説されたパラメタの下で新しいセッション/予約が合図されるとき、セッションがどれのためにアクティブなままで残るかをstatefullyに選ぶ能力を持っています(恐らくすべてのセッションに悪影響を与えて)。 この場合、ルータは、要求された量の帯域幅(いくつかのドメインのローカルの方針によると)へのこのより高い優先権予約アクセスを許すために低優先度の1つ以上の予約を終えなければなりません。
This document will cover the semantics for these two cases and request IANA registration of the new protocol value "Preemption" for the Reason Header field, with 4 cause values for the above preemption conditions. Additionally, this document will create a new IANA Registry for reason-text strings that are not currently defined through existing SIP Response codes or Q.850 cause codes. This new Registry will be useful for future protocols used by the SIP Reason header.
このドキュメントは、Reason Header分野にこれらの2つのケースのために意味論をカバーしていて、新しいプロトコル値の「先取り」のIANA登録を要求するでしょう、上記の先取り状態のための4つの原因値で。 さらに、このドキュメントは現在既存のSIP ResponseコードかQ.850原因コードを通して定義されない理由テキスト文字列のための新しいIANA Registryを作成するでしょう。 この新しいRegistryはSIP Reasonヘッダーによって使用された将来のプロトコルの役に立ちます。
This document will emphasize an existing SIP RFC [3] as the starting point for network preemption events. RFC 3312 set rules surrounding SIP interaction using a reservation protocol for QoS preconditions,
このドキュメントはネットワーク先取りイベントのための出発点として既存のSIP RFC[3]を強調するでしょう。 RFC3312は、QoS前提条件に予約プロトコルを使用することでSIP相互作用を囲みながら、決まりを定めます。
Polk Standards Track [Page 3] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[3ページ]。
using RSVP as the example protocol. That effort did not preclude other preconditions or future protocol work from becoming a means of preconditions. NSIS is a new reservation protocol effort that specifies a preemption operation similar to RSVP's ResvErr message involving the NSIS NOTIFY message in [8] with a Transient error code 0x04000005 (Resources Pre-empted).
例のプロトコルとしてRSVPを使用します。 その取り組みは、前提条件の手段になるので、他の前提条件か今後のプロトコル仕事を排除しませんでした。 NSISはTransientエラーコード0x04000005(リソースPre-empted)でNSIS NOTIFYメッセージに[8]にかかわるRSVPのResvErrメッセージと同様の先取り操作を指定する新しい予約プロトコル取り組みです。
Note that SIP itself does not cause RSVP or NSIS reservation signaling to start or end. That operation is part of a separate API within each UA.
SIP自身が、RSVPかNSIS予約シグナリングが始まるか、または終わることを引き起こさないことに注意してください。 その操作は各UAの中の別々のAPIの一部です。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [6].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[6]で説明されるように本書では解釈されることであるべきですか?
2. Access Preemption Events
2. アクセス先取りイベント
As mentioned previously, Access Preemption Events (APE) occur at the user agent. It does not matter which UA in a unicast or multicast session this happens to (the UAC or UAS of a session). If local policy dictates in a particular domain rules regarding the functionality of a UA, there must be a means by which that UA (not the user) informs the other UA(s) why a session was just torn down prematurely. The appropriate mechanism is the BYE Method. The user of the other far side UA will not understand why that session "just went away" without there being a means of informing the UA of what occurred (if this event was purposeful). Through this type of indication to the preempted UA, it can indicate to the user of that device appropriately.
既述のとおり、Access Preemption Events(APE)はユーザエージェントに起こります。 これがユニキャストかマルチキャストセッションにおけるどのUAに起こるかが(セッションのUACかUAS)重要ではありません。 ローカルの方針が命令するなら、特定のドメインでは、セッションが早まってただ取りこわされた理由は、そのUA(ユーザでない)がもう片方を知らせる手段がUA(s)であったに違いないならUAの機能性をそこに見なしながら、統治されています。 適切な手段はBYE Methodです。 もう片方の反対側のUAのユーザは、そのセッションがなぜ何が起こったかについてUAに知らせる手段(このイベントが故意であったなら)であるのでそこなしで「ただ、遠ざかったか」を理解しないでしょう。 先取りされたUAへのこのタイプのしるしで、それはそのユーザに適切にデバイスを示すことができます。
The rules within a domain surrounding the UA to be informed can be different from the rules for informing the user. Local policy should determine if the user should be informed of the specific reason. This indication in SIP will provide a means for the UA to react in a locally determined way, if appropriate (play a certain tone or tone sequence, point towards a special announcement uri, cause the UA's visual display to do something, etc.).
知識があるためにUAを囲むドメインの中の規則はユーザに知らせるための規則と異なっている場合があります。 ローカルの方針は、ユーザが特定の理由において知識があるべきであるかどうか決定するべきです。 SIPのこの指示はUAが局所的に決定している方法で反応する手段を提供するでしょう、適切であるなら(あるトーンをプレーしてください。さもないと、UAの視覚ディスプレイは調子連鎖、特別な発表uriに向かったポイントで何かなどをします)。
Figure 1 illustrates the scenario. UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher is this domain, and the namespace element is not necessary for this discussion).
図1はシナリオを例証します。 UA1は3のResource PriorityレベルとのセッションにUA2を招待します(レベル1と2は、より高いのが、このドメインであるということです、そして、名前空間要素はこの議論に必要ではありません)。
Polk Standards Track [Page 4] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[4ページ]。
UA1 UA2 UA3
| | |
| INVITE (R-P:3) | |
|----------------------->| |
| 200 OK | |
|<-----------------------| |
| ACK | |
|----------------------->| |
| RTP | |
|<======================>| |
| | INVITE (R-P:2) |
| |<------------------------|
| BYE (Reason : ? ) | |
|<-----------------------| |
| | 200 OK |
| |------------------------>|
| 200 OK | |
|----------------------->| |
| | ACK |
| |<------------------------|
| | RTP |
| |<=======================>|
| | |
UA1 UA2 UA3| | | | (R-P: 3)を招待してください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ACK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| RTP| | |<===========>|、|、|、| (R-P: 2)を招待してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| さようなら(理由:?) | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| RTP| | |<============>|、|、|、|
Figure 1. Access Preemption with obscure Reason
図1。 不鮮明なReasonとアクセスPreemption
After the session between UA1 and UA2 is established, UA3 invites UA2 to a new session with an R-P of 2 (a higher priority than the current session between UA1 and UA2). Local policy within this domain dictates that UA2 must preempt all existing calls of lower priority in order to accept a higher priority call.
UA1とUA2とのセッションが確立された後に、UA3は2(UA1とUA2との現在のセッションより高い優先度)のR-Pとの新しいセッションにUA2を招待します。 このドメインの中のローカルの方針は、UA2が、より高い優先権呼び出しを受け入れるために低優先度のすべての既存の呼び出しを先取りしなければならないと決めます。
What Reason value could be inserted above to mean "preemption" at a UA? There are several choices: 410 "Gone", 480 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service Unavailable". The use of any of these here is questionable because the session is already established. It is further complicated if there needs to be a difference in the Reason value for an Access versus a Network Preemption Event (which is a requirement here). The limits of Q.850 [5] have been stated previously in this document.
UAで「先取り」を意味するためにどんなReason値を上に挿入できますか? いくつかの選択があります: 410 「行く」「一時入手できません、な」480、486 「ここで忙しい」、そして、および「サービス入手できません、な」503。 セッションが既に確立されるので、ここのこれらのどれかの使用は疑わしいです。 AccessのためのReason値の違い対Network Preemption Event(ここの要件である)があるのが必要であるなら、さらに複雑です。 Q.850[5]の限界は以前に、本書では述べられます。
It should be possible to configure UAs receiving a preemption indication to indicate to the user that no particular type of preemption occurred. There are some domains that might prefer their users to remain unaware of the specifics of network behavior. This should not ever prevent a known preemption indication from being sent in a BYE from a UA.
先取りのどんな特定のタイプも起こらなかったのをユーザに示すために先取り指示を受けるUAsを構成するのは可能であるべきです。 彼らのユーザがネットワークの振舞いの詳細に気づかないままであることを好むかもしれないいくつかのドメインがあります。 これは、知られている先取り指示がBYEでUAから送られるのを防ぐべきではありません。
Polk Standards Track [Page 5] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[5ページ]。
2.1. Effects of Preemption at the User Agent
2.1. ユーザエージェントでの先取りの効果
If 2 UAs are in a session and one UA must preempt that session to accept another session, a BYE Method message is the appropriate mechanism to perform this task. However, taking this a step further, if a UA is the common point of a 3-way (or more) ad hoc conference and must preempt all sessions in that conference due to receipt of a higher-priority session request (that this UA must accept), then a BYE message must be sent to all UAs in that ad hoc conference.
セッションのときに、2UAsがあって、1UAが別のセッションを受け入れるためにそのセッションを先取りしなければならないなら、BYE Methodメッセージはこのタスクを実行する適切な手段です。 しかしながら、これをさらに前進させて、UAが3ウェイ(さらに)の臨時の会議と必須の一般的なポイントであるなら、より高い優先度セッション要求の領収書によるその会議におけるすべてのセッションを先取りしてください、(このUAは受け入れなければなりません)、そして、その臨時の会議でBYEメッセージをすべてのUAsに送らなければなりません。
2.2. Reason Header Requirements for Access Preemption Events
2.2. アクセス先取りイベントのための理由ヘッダー要件
The following is a list of requirements for adding an appropriate Reason value for an Access Preemption Event (APE) as described above and shown in Figure 1:
↓これはAccess Preemption Event(APE)のために上で説明されて、図1に示されるように適切なReason価値を高めるための要件のリストです:
APE_REQ#1 - create a means by which one UA can inform another UA
(within the same active session) that the active
session between the two devices is being purposely
preempted at one UA for a higher-priority session
request from another UA.
APE_REQ#1--別のUAからUAが、2台のデバイスの間の活発なセッションが、より高い優先度セッション要求のために1UAでわざわざ先取りされていることを別のUA(同じ活発なセッション中の)に知らせることができる手段を作成してください。
APE_REQ#2 - create a means by which all relevant SIP elements can
be informed of this Access Preemption Event to a
specific session.
APE_REQ#2--このAccess Preemption Eventについて特定のセッションまですべての関連SIP要素を知らすことができる手段を作成してください。
For example: perhaps SIP Servers that have incorporated a Record- Route header into that session set up need to be informed of this occurrence.
例えば: 恐らく、Recordルートヘッダーをセットアップされたそのセッションに組み入れたSIP Serversは、この発生において知識がある必要があります。
APE_REQ#3 - create a means of informing all participants in an ad
hoc conference that the primary UA (the mixer) has
preempted the conference by accepting a higher-
priority session request.
APE_REQ#3--臨時の会議でプライマリUA(ミキサー)が、より高い優先権セッション要求を受け入れることによって会議を先取りしたことをすべての関係者に知らせる手段を作成してください。
APE_REQ#4 - create a separate indication for the access preemption
event than the one used for a Network Preemption Event
(described in the next section) in the session BYE
message.
APE_REQ#4--Network Preemption EventにセッションBYEメッセージで使用される(次のセクションで、説明されます)ものよりアクセス先取りイベントのための別々の指示を作成してください。
APE_REQ#5 - create a means to generate a specific indication of a
preemption event at the user agent to inform all
relevant SIP entities, yet have the ability to
generalize this indication (based on local policy) to
the receiving UA such that this UA cannot display more
information than the domain wants the user to see.
APE_REQ#5--すべての関連SIP実体を知らせるためにユーザエージェントで先取りイベントの特異的な適応を生成する手段を作成してください、そして、しかし、このUAがドメインが、ユーザが見る必要があるより多くの情報を表示できないように、この指示(ローカルの方針に基づいている)を受信UAに一般化する能力を持ってください。
Polk Standards Track [Page 6] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[6ページ]。
3. Network Preemption Events
3. ネットワーク先取りイベント
Network Preemption Events (NPE) are instances in which an intermediate router between SIP user agents preempts one or more sessions at one of its interfaces to place a higher-priority session through that interface. Within RSVP, there exists a means to execute this functionality per [7]: ResvErr messages, which travel downstream towards appropriate receivers. The ResvErr message has the ability to carry within it a code indicating why a reservation is being torn down. The ResvErr does not travel upstream to the other UA. This document proposes that a SIP message be generated to synchronize all relevant SIP elements to this preemption event, including the upstream UA. Creating another Reason value describing that a network element preempted the session is necessary in certain domains.
ネットワークPreemption Events(NPE)はSIPユーザエージェントの間の中間的ルータがそのインタフェースを通して、より高い優先度セッションを置くためにインタフェースの1つの1つ以上のセッションを先取りするインスタンスです。 RSVPの中では、この1[7]あたりの機能性を実行する手段は存在しています: ResvErrメッセージ、適切な受信機に向かったどの旅行川下。 ResvErrメッセージには、それの中で予約がなぜ取りこわされているかを示すコードを運ぶ能力があります。 ResvErrは上流へもう片方のUAに旅行しません。 このドキュメントは、SIPメッセージがすべての関連SIP要素をこの先取りイベントと同期させるように生成されるよう提案します、上流のUAを含んでいて。 ネットワーク要素がセッションを先取りしたと説明する別のReason値を作成するのが、ある一定のドメインで必要です。
Figures 2 and 3 illustrate a network preemption scenario with RSVP. NSIS, not shown in examples here, can be imagined from [8] with a NOTIFY error message indicating that a reservation has been preempted with the Transient ERROR_SPEC 0x04000005. SIP behavior will be identical using either reservation protocol.
数字2と3はネットワーク先取りシナリオにRSVPを入れます。 NOTIFYエラーメッセージが、予約がTransient ERROR_SPEC0x04000005と共に先取りされたのを示していて、[8]からここに例に示されなかったNSISは想像できます。 SIPの振舞いはどちらの予約プロトコルも使用するのにおいて同じになるでしょう。
UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher in this domain) and is accepted. This SIP signaling translated the Resource Priority value to an appropriate RSVP priority level for that flow. The link between Router 1 and Router 2 became saturated with this session reservation between UA1 and UA2 (in this example).
UA1を3(このドメインでは、レベル1と2は、より高い)のResource PriorityレベルとのセッションにUA2を招待して、受け入れます。 このSIPシグナリングはその流れのために適切なRSVP優先順位にResource Priority値を翻訳しました。 Router1とRouter2とのリンクはUA1とUA2(この例の)の間には、このセッションの予約がある状態で飽和するようになりました。
UA1 UA2
\ /
\ /
+--------+ +--------+
| | | |
| RTR1 | | RTR2 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
UA3 UA4
UA1 UA2\/\/+--------+ +--------+ | | | | | RTR1| | RTR2| | Int7-------Int5| | | | | +--------+ +--------+/\/\UA3 UA4
Figure 2. Network Diagram Scenario A
図2。 ネットワーク図シナリオA
After the session between UA1 and UA2 is established, UA3 invites UA4 to a new session with a Resource Priority level of 2 (a higher priority than the current reservation between UA1 and UA2). Again, the priority value within the Resource-Priority header of this INVITE is translated into an appropriate RSVP priority (that is also higher
UA1とUA2とのセッションが確立された後に、UA3は2(UA1とUA2の間の現在の予約より高い優先度)のResource Priorityレベルとの新しいセッションにUA4を招待します。 一方、このINVITEのResource-優先権ヘッダーの中の優先順位の値が適切なRSVP優先に翻訳される、(また、それも、より高いです。
Polk Standards Track [Page 7] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[7ページ]。
in relative priority to the UA1_UA2 session/RSVP flow). When this second, higher-priority session is signaled, one Path message goes from UA3 to UA4, resulting in the RESV message going from UA4 back to UA3. Because this link between the two routers is at capacity (at Int7 in Figure 5), Router 1 will (in this example) make the decision or will communicate with another network entity that will make the decision to preempt lower-priority BW to ensure that this higher- priority session reservation is completed. A ResvErr message is sent to UA2. The result is that UA2 will know that there has been a preemption event in a router (because the ResvErr message has a error code within it, stating "preemption"). At this point, UA1 will not know anything of this preemption. If there are any SIP Proxies between UAs 1 and 2 (perhaps that inserted a Record-Route Header), each will also need to be informed as to why this reservation was torn down.
UA1_UA2セッション/RSVP流動のコネ相対的な優先権) より高い優先度セッションがこの秒に合図されるとき、1つのPathメッセージがUA3からUA4まで行きます、UA4からUA3まで行くRESVメッセージをもたらして。 2つのルータの間のこのリンクが容量(図5のInt7の)であるので、Router1は決定をするか(この例で)、またはこのより高い優先権セッションの予約が終了しているのを保証するために、低優先度を先取りするという決定をBWにする別のネットワーク実体で交信するでしょう。 ResvErrメッセージをUA2に送ります。 結果がUA2が、ルータには先取りイベントがあったのを知るということである、(それの中にエラーコードを持って、「先取り」を述べるResvErrメッセージ) ここに、UA1はこの先取りについて何も知らないでしょう。 また、UAs1と2の間には、何かSIP Proxiesがあると(恐らく、それはRecord-ルートHeaderを挿入しました)、それぞれが、この予約が取りこわされた理由に関して知識がある必要があるでしょう。
Figure 3 shows the call flow with Router 2 from Figure 2 included at the RSVP layer sending the ResvErr message. A complete call flow including all UAs and Routers is not shown here for diagram complexity reasons. The complete signaling between UA3 and UA4 is also not included.
ResvErrメッセージを送りながらRSVP層に図2からのRouter2がある呼び出し流動を含んでいて、図3は目立っています。 すべてのUAsとRoutersを含む完全な呼び出し流動はダイヤグラムの複雑さ理由にここに示されません。 また、UA3とUA4の間の完全なシグナリングは含まれていません。
Polk Standards Track [Page 8] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[8ページ]。
UA1 Rtr2 UA2
| | |
| INVITE with QoS Preconditions (R-P:3) |
|------------------------------------------------->|
| ******************************************** |
| * - QoS Preconditions established UA1-UA2 * |
| * - SIP signaling continues... * |
| ******************************************** |
| 200 OK |
|<-------------------------------------------------|
| ACK |
|------------------------------------------------->|
| RTP |
|<================================================>|
| ******************************************** |
| * -UA3 sends INV with QoS Preconditions * |
| * to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 in Figure 2 must preempt * |
| * reservation between UA1 & UA2 * |
| * ****************************************** |
| |
| | ResvErr |
| |------------------------>|
| | |
| |
| BYE (Reason : ? ) |
|<-------------------------------------------------|
| 200 OK |
|------------------------------------------------->|
| |
UA1 Rtr2 UA2| | | | QoSと共に前提条件(R-P: 3)を招待してください。| |------------------------------------------------->| | ******************************************** | | * - QoS PreconditionsはUA1-UA2*を設立しました。| | * - SIPシグナリングは続きます… * | | ******************************************** | | 200 OK| |<-------------------------------------------------| | ACK| |------------------------------------------------->| | RTP| |<========================>|、| ******************************************** | | * -UA3はQoS Preconditions*とINVを送ります。| | * RP: 2があるUA4に。 * | | * -予約セットアップはUA3*の間に起こります。| | * そして、UA4*| | * -図2のルータ2は*を先取りしなければなりません。| | * UA1とUA2*の間の予約| | * ****************************************** | | | | | ResvErr| | |------------------------>| | | | | | | さようなら(理由:?) | |<-------------------------------------------------| | 200 OK| |------------------------------------------------->| | |
Figure 3. Network Preemption with obscure Reason
図3。 不鮮明なReasonとネットワークPreemption
What Reason value could be inserted above to mean "preemption at a router interface"? There are several choices: 410 "Gone", 480 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service Unavailable". The use of any of these here is questionable because the session is already established. It is further complicated if there needs to be a difference between the Reason value for an Access Preemption Event versus a Network Preemption Event. The limits of Q.850 [5] have already been stated previously, showing there is nothing in that spec to indicate a problem in an IP network.
「ルータインタフェースでの先取り」を意味するためにどんなReason値を上に挿入できますか? いくつかの選択があります: 410 「行く」「一時入手できません、な」480、486 「ここで忙しい」、そして、および「サービス入手できません、な」503。 セッションが既に確立されるので、ここのこれらのどれかの使用は疑わしいです。 違いがあるのが必要であるなら、Access Preemption EventのためのReason値では、対Network Preemption Event間複雑な状態で、より遠いです。 Q.850[5]の限界は以前に既に述べられます、IPネットワークで問題を示すためにその仕様には何もないのを示して。
To state that all preemptions are equal is possible, but will not provide adequate information. Therefore, another Reason Header value is necessary to differentiate the APE from the NPE.
すべての先取りが等しいと述べるのが、可能ですが、適切な情報を提供しないでしょう。 したがって、別のReason Header値が、NPEとAPEを区別するのに必要です。
Polk Standards Track [Page 9] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取りイベントのためにRFC4411一口理由ヘッダーの跡をつけます[9ページ]。
3.1. Reason Header Requirements for Network Preemption Events
3.1. ネットワーク先取りイベントのための理由ヘッダー要件
The following are the requirements for the appropriate SIP signaling in reaction to a Network Preemption Event (NPE):
↓これはNetwork Preemption Event(NPE)への反応で合図する適切なSIPのための要件です:
NPE_REQ#1 - create a means of informing the far-end UA that a
Network Preemption Event has occurred in an
intermediate router.
NPE_REQ#1--Network Preemption Eventが中間的ルータで起こったことを遠端UAに知らせる手段を作成してください。
NPE_REQ#2 - create a means by which all relevant SIP elements can
be informed of a Network Preemption Event to a
specific session.
NPE_REQ#2--Network Preemption Eventについて特定のセッションまですべての関連SIP要素を知らすことができる手段を作成してください。
For example: perhaps SIP Servers have incorporated a Record-Route header into that session set up.
例えば: 恐らく、SIP ServersはRecord-ルートヘッダーをセットアップされたそのセッションに組み入れました。
NPE_REQ#3 - create a means of informing all participants in an ad
hoc conference that the primary UA (the mixer) has
been preempted by a Network Preemption Event.
NPE_REQ#3--臨時の会議でプライマリUA(ミキサー)がNetwork Preemption Eventによって先取りされたことをすべての関係者に知らせる手段を作成してください。
NPE_REQ#4 - create a separate description of the Network
Preemption Event relative to an Access Preemption
Event in SIP.
NPE_REQ#4--SIPのAccess Preemption Eventに比例してNetwork Preemption Eventの別々の記述を作成してください。
4. Including a Hybrid Infrastructure
4. ハイブリッドインフラストラクチャを含んでいます。
If User 1 is in a non-IP portion of infrastructure (using a TDM phone) in a session with a UA through a SIP gateway, and if the TDM portion had the ability to preempt the session and indicate to the SIP gateway when it did such a preemption, the SIP GW would need to be able to convey this preemption event into the SIP portion of this session just as if User 1 were a UA in the session. Below is a diagram of this:
SIPゲートウェイを通してUser1がUAとのセッションのときにインフラストラクチャの非IP部分にあって(TDM電話を使用します)、TDM部分にセッションを先取りして、それがいつそのような先取りをしたかをSIPゲートウェイに示す能力があるなら、SIP GWは、まるでまさしくUser1がセッションでUAであるかのようにこのセッションのSIP部分にこの先取りイベントを伝えることができる必要があるでしょうに。 以下に、このダイヤグラムはあります:
**************************
* TDM network *
* +---------+
* User 1 | |
* O ==========>| SIP GW1 |================> UA2
* /|\ ^ | | |
* / \ | +---------+ |
* | * |
**********|*************** | |
| | Preemption |
Preemption ---------> |--------------------->|
Event Indication
************************** * TDMネットワーク**+---------+ *ユーザ1| | * O==========>| 一口GW1|================>UA2*/|\ ^ | | | * / \ | +---------+ | * | * | **********|*************** | | | | 先取り| 先取り--------->|--------------------->| イベント指示
Figure 4. TDM/IP Preemption Event
図4。 TDM/IP先取りイベント
Polk Standards Track [Page 10] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[10ページ]。
4.1. Hybrid Infrastructure Requirements
4.1. ハイブリッドインフラストラクチャ要件
The following are the requirements unique to the topology involving both IP infrastructure and TDM (or non-IP) infrastructure.
↓これはIPインフラストラクチャとTDM(または、非IP)インフラストラクチャの両方にかかわるトポロジーにユニークな要件です。
HYB_REQ#1 - create a means of informing the far-end UA in a dialog
through a SIP gateway with a non-IP phone that the TDM
portion of the session indicated to the SIP gateway
that a preemption event terminated the session.
HYB_REQ#1--非IP電話があるSIPゲートウェイを通した対話でセッションのTDM部分が、先取り出来事がセッションを終えたのをSIPゲートウェイに示したことを遠端UAに知らせる手段を作成してください。
HYB_REQ#2 - create a means of identifying this preemption event
uniquely with respect to an access preemption and
network preemption event.
HYB_REQ#2--アクセス先取りとネットワーク先取りイベントに関して唯一この先取り出来事を特定する手段を作成してください。
5. Preemption Reason Header Cause Codes and Semantics
5. 先取り理由ヘッダー原因コードと意味論
This document defines the following new protocol value for the protocol field of the Reason header field in RFC 3326 [1]:
このドキュメントはRFC3326[1]で以下の新しいプロトコル値をReasonヘッダーフィールドのプロトコル分野と定義します:
Preemption: The cause parameter contains a preemption cause code.
先取り: 原因パラメタは先取り原因コードを含んでいます。
We define the following preemption cause codes:
私たちは以下の先取り原因コードを定義します:
Value Default Text Description
値のデフォルトテキスト記述
1 UA Preemption The session has been preempted by a UA.
1UA Preemption、セッションはUAによって先取りされました。
2 Reserved Resources The session preemption has been
Preempted initiated within the network via a
purposeful RSVP preemption occurrence,
and not a link error.
2はResourcesを予約しました。セッション先取りはリンク誤りではなく、故意のRSVP先取り発生を通してネットワークの中で開始されたPreemptedです。
3 Generic Preemption This is a limited-use preemption
indication to be used on the final leg
to the preempted UA to generalize the
event.
3 一般的なPreemption Thisは出来事を一般化するのに最終的な脚の上で先取りされたUAに使用されるべき限られた使用先取り指示です。
4 Non-IP Preemption The session preemption has occurred in
a non-IP portion of the infrastructure,
and this is the Reason cause code given
by the SIP Gateway.
4非IP Preemption、セッション先取りはインフラストラクチャの非IP部分に起こって、これはSIPゲートウェイによって与えられたReason原因コードです。
Example syntax for the above preemption types are as follows:
上の先取りのための例の構文が、タイプする以下の通りです:
Reason: preemption ;cause=1 ;text="UA Preemption"
Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
Reason: preemption ;cause=3 ;text="Generic Preemption"
Reason: preemption ;cause=4 ;text="Non-IP Preemption"
理由: 先取り; 原因=1; テキストは"UA Preemption"Reasonと等しいです: 先取り; 原因=2; テキストは「予約されたResources Preempted」Reasonと等しいです: 先取り; 原因=3; テキストは「一般的なPreemption」Reasonと等しいです: 先取り; =4を引き起こしてください; テキストは「非IP Preemption」と等しいです。
Polk Standards Track [Page 11] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[11ページ]。
Sections 5.1, 5.2, 5.3, and 5.4 provide use cases and extended definitions for the above four cause codes with message flow diagrams.
セクション5.1、5.2、5.3、および5.4 メッセージフローチャートと共に4つの上の原因コードのためのケースと拡張定義を使用に供給してください。
5.1. Access Preemption Event Reason Code
5.1. アクセス先取りイベント理由コード
A more elaborate description of the Access Preemption Event cause=1 is as follows:
Access Preemption Event原因=1の、より入念な記述は以下の通りです:
A user agent in a session has purposely preempted a session and is
informing the far-end user agent, or user agents (if part of a
conference), and SIP Proxies (if stateful of the session's
transactions)
セッションにおけるユーザエージェントは、わざわざセッションを先取りして、遠端ユーザエージェント、またはユーザエージェントに知らせて(会議の一部であるなら)、SIP Proxiesです。(セッションの取引のstatefulであるなら)
An example usage of this header value would be:
このヘッダー価値の例の用法は以下の通りでしょう。
Reason: preemption ;cause=1 ;text="UA Preemption"
理由: 先取り; =1を引き起こしてください; テキストは"UA Preemption"と等しいです。
5.1.1. Access Preemption Event Call Flow
5.1.1. アクセス先取りイベント呼び出し流動
Figure 5 replicates the call flow from Figure 1, but with an appropriate Reason value indication that was proposed in Section 4.1, above:
図5は図1からの呼び出し流動を模写しますが、適切なReasonと共に、以下の上でセクション4.1で提案された指示を評価してください。
Polk Standards Track [Page 12] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[12ページ]。
UA1 UA2 UA3
| | |
| INVITE (R-P:3) | |
|---------------------------------->| |
| 200 OK | |
|<----------------------------------| |
| ACK | |
|---------------------------------->| |
| RTP | |
|<=================================>| |
| | INVITE (R-P:2) |
| |<-------------------|
| BYE (Reason: Preemption ; | |
| cause=1 ;text="UA Preemption") | |
|<----------------------------------| |
| | 200 OK |
| |------------------->|
| 200 OK | |
|---------------------------------->| |
| | ACK |
| |<-------------------|
| | RTP |
| |<==================>|
| | |
UA1 UA2 UA3| | | | (R-P: 3)を招待してください。| | |---------------------------------->| | | 200 OK| | |<----------------------------------| | | ACK| | |---------------------------------->| | | RTP| | |<=================>|、|、|、| (R-P: 2)を招待してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| BYE推論してください: 先取り| | | 原因=1、(テキストは"UA Preemption"と等しいです)| | |<----------------------------------| | | | 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 200 OK| | |---------------------------------->| | | | ACK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| RTP| | |<=========>|、|、|、|
Figure 5. Access Preemption with Reason: UA Preemption
図5。 理由との先取りにアクセスしてください: UA先取り
UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher in this domain). After the session between UA1 and UA2 is established, UA3 invites UA2 to a new session with an R-P of 2 (a higher priority than the current session to UA1). Local policy within this domain dictates that UA2 must preempt all existing calls of lower priority in order to accept a higher-priority call.
UA1は3のResource PriorityレベルとのセッションにUA2を招待します(このドメインでは、レベル1と2は、より高いです)。 UA1とUA2とのセッションが確立された後に、UA3は2(UA1への現在のセッションより高い優先度)のR-Pとの新しいセッションにUA2を招待します。 このドメインの中のローカルの方針は、UA2が、より高い優先度呼び出しを受け入れるために低優先度のすべての既存の呼び出しを先取りしなければならないと決めます。
UA2 sends a BYE Request message with a Reason header with a value of UA Preemption. This will inform the far-end UA (UA1) and all relevant SIP elements (for example, SIP Proxies). The cause code is unique to what is proposed in the RSVP Preemption Event for differentiation purposes.
UA2はUA Preemptionの値があるReasonヘッダーと共にBYE Requestメッセージを送ります。 これは遠端UA(UA1)とすべての関連SIP要素(例えば、SIP Proxies)を知らせるでしょう。 原因コードは分化目的のためにRSVP Preemption Eventで提案されることにユニークです。
Polk Standards Track [Page 13] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[13ページ]。
5.2. Network Preemption Events Reason Code
5.2. ネットワーク先取りイベントはコードを推論します。
A more elaborate description of the Reserved Resources Preempted Event cause=2 is as follows:
Reserved Resources Preempted Event原因=2の、より入念な記述は以下の通りです:
A router has preempted a reservation flow and generated a
reservation error message: a ResvErr traveling downstream in RSVP,
and a NOTIFY in NSIS. The UA receiving the preemption error
message generates a BYE request towards the far-side UA with a
Reason Header with this value indicating that somewhere between
two or more UAs, a router has administratively preempted this
session.
ルータは、予約流動を先取りして、予約エラーメッセージを発生させました: RSVPを川下に旅行するResvErr、およびNSISのNOTIFY。 先取りエラーメッセージを受け取るUAはこの値が、2UAsの間のどこかでは、ルータが行政上このセッションを先取りしたのを示しているReason Headerと共に反対側のUAに向かってBYE要求を発生させます。
An example usage of this header value would be:
このヘッダー価値の例の用法は以下の通りでしょう。
Reason: Preemption :cause=2 ;text="Reserved Resources Preempted"
理由: 先取り: 原因=2; 「予約されたリソースは先取りした」テキスト=
Polk Standards Track [Page 14] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[14ページ]。
5.2.1. Network Preemption Event Call Flow
5.2.1. ネットワーク先取りイベント呼び出し流動
Figure 6 replicates the call flow from Figure 5, but with an appropriate Reason value indication that was proposed in Section 4.2, above.
図6は図5からの呼び出し流動を模写しますが、上で適切なReasonと共に、セクション4.2で提案された指示を評価してください。
UA1 Rtr2 UA2
| | |
| INVITE with QoS Preconditions (R-P:3) |
|---------------------------------------------------->|
| ******************************************** |
| * - QoS Preconditions established UA1-UA2 * |
| * - SIP signaling continues... * |
| ******************************************** |
| 200 OK |
|<----------------------------------------------------|
| ACK |
|---------------------------------------------------->|
| RTP |
|<===================================================>|
| ******************************************** |
| * -UA3 sends INV with QoS Preconditions * |
| * to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 in Figure 2 must preempt * |
| * reservation between UA1 & UA2 * |
| * ********************************************* |
| |
| | ResvErr |
| |------------------------>|
| | |
| |
| BYE (Reason : Preemption ;cause=2 ; |
| text="Reserved Resources Preempted") |
|<----------------------------------------------------|
| 200 OK |
|---------------------------------------------------->|
| |
UA1 Rtr2 UA2| | | | QoSと共に前提条件(R-P: 3)を招待してください。| |---------------------------------------------------->| | ******************************************** | | * - QoS PreconditionsはUA1-UA2*を設立しました。| | * - SIPシグナリングは続きます… * | | ******************************************** | | 200 OK| |<----------------------------------------------------| | ACK| |---------------------------------------------------->| | RTP| |<==========================>|、| ******************************************** | | * -UA3はQoS Preconditions*とINVを送ります。| | * RP: 2があるUA4に。 * | | * -予約セットアップはUA3*の間に起こります。| | * そして、UA4*| | * -図2のルータ2は*を先取りしなければなりません。| | * UA1とUA2*の間の予約| | * ********************************************* | | | | | ResvErr| | |------------------------>| | | | | | | さようなら(理由: 先取り(原因=2)| | 「予約されたリソースは先取りした」テキスト=)| |<----------------------------------------------------| | 200 OK| |---------------------------------------------------->| | |
Figure 6. Network Preemption with "Reserved Resources Preempted"
図6。 「先取りされた予約されたリソース」とのネットワーク先取り
Above is the call flow with Router 2 from Figure 2 included at the RSVP layer sending the Resv messages. A complete call flow including all UAs and Routers is not included for diagram complexity reasons. The signaling between UA3 and UA4 is also not included.
上に、Resvメッセージを送りながらRSVP層に図2からのRouter2がある流れを含んでいて、呼び出しがあります。 すべてのUAsとRoutersを含む完全な呼び出し流動はダイヤグラムの複雑さ理由で含まれていません。 また、UA3とUA4の間のシグナリングは含まれていません。
Polk Standards Track [Page 15] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[15ページ]。
Upon receipt of the ResvErr message with the preemption error code, UA2 can now appropriately inform UA1 why this event occurred. This BYE message will also inform all relevant SIP elements, synchronizing them. The cause value is unique to that proposed in Section 4.1 for Access Preemption Events for differentiation purposes.
先取りエラーコードがあるResvErrメッセージを受け取り次第、UA2は、現在、この出来事がなぜ起こったかを適切にUA1に知らせることができます。 また、それらを連動させて、このBYEメッセージはすべての関連SIP要素を知らせるでしょう。 原因値は分化目的のためにAccess Preemption Eventsのためにセクション4.1で提案されたそれにユニークです。
5.3. Generic Preemption Event Reason Code
5.3. 一般的な先取りイベント理由コード
A more elaborate description of the Generic Preemption Event cause=3 is as follows:
Generic Preemption Event原因=3の、より入念な記述は以下の通りです:
This cause code is for infrastructures that do not wish to provide
the preempted UA with a more precise reason than just
"preemption". It is possible that UAs will have code that will
indicate the type of preemption event that is contained in the
Reason header, and certain domains have expressed this as not
being optimal, and wanted to generalize the indication. This MUST
NOT be the initial indication within these domains, as valuable
traffic analysis and other NM applications will be generalized as
well. If this cause value is to be implemented, it SHOULD only be
done at the final SIP Proxy in such a way that the cause value
indicating which type of preemption event actually occurred is
changed to this generalized preemption indication to be received
by the preempted UA.
この原因コードはまさしく「先取り」より正確な理由を先取りされたUAに提供したがっていないインフラストラクチャのためのものです。 UAsには最適でなく、指示を一般化して欲しいのでドメインがこれを言い表したのをReasonヘッダーに含まれて、確信している先取り出来事のタイプを示すコードがあるのは、可能です。 これはこれらのドメインの中の初期の指示であるはずがありません、貴重なトラヒック分析と他のニューメキシコアプリケーションがまた、広められるとき。 値はこの原因であるなら実行されることであり、それはSHOULDです。単に先取りされたUAによって受け取られるようにどのタイプの先取り出来事が実際に起こったかがこれに変わるのを示す原因値が先取り指示を一般化したような方法で最終的なSIP Proxyにしてください。
An example usage of this header value would be:
このヘッダー価値の例の用法は以下の通りでしょう。
Reason: preemption ;cause=3 ;text="Generic Preemption"
理由: 先取り; =3を引き起こしてください; テキストは「一般的なPreemption」と等しいです。
5.4. Non-IP Preemption Event Reason Code
5.4. 非IP先取りイベント理由コード
A more elaborate description of the Non-IP Preemption Event cause=4 is as follows:
Non-IP Preemption Event原因=4の、より入念な記述は以下の通りです:
A session exists in a hybrid IP/non-IP infrastructure and the
preemption event occurs in the non-IP portion, and was indicated
by that portion that this call termination was due to preemption.
This is the indication that would be generated by a SIP Gateway
towards the SIP UA that is being preempted, traversing whichever
SIP Proxies are involved in session signaling (a question of
server state).
セッションがハイブリッド非IP/IPインフラストラクチャで存在していて、先取り出来事は、非IP部分に起こって、この呼び出し終了が先取りのためであったその部分によって示されました。 これはSIPゲートウェイによって先取りされているSIP UAに向かって発生する指示です、セッションシグナリング(サーバ状態の問題)にかかわるSIP Proxiesを横断して。
An example usage of this header value would be:
このヘッダー価値の例の用法は以下の通りでしょう。
Reason: preemption ;cause=4 ;text="Non-IP Preemption"
理由: 先取り; =4を引き起こしてください; テキストは「非IP Preemption」と等しいです。
Polk Standards Track [Page 16] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[16ページ]。
5.4.1. Non-IP Preemption Event Call Flow
5.4.1. 非IP先取りイベント呼び出し流動
Figure 7 is a simple call flow diagram of the Non-IP Preemption Event.
図7はNon-IP Preemption Eventの簡単な呼び出しフローチャートです。
............
UA1 SIP GW1 . User3 .
| | . .
| INVITE (R-P:1) | . .
|-------------------------------------->| . Non-IP .
| 200 OK | . .
|<--------------------------------------| . Network .
| ACK | . .
|-------------------------------------->| . .
| RTP | . .
|<=====================================>| . .
| | . .
| BYE (Reason: Preemption ; |<==Preemption Indication
| cause=4 ;text="Non-IP Preemption") | . .
|<--------------------------------------| . .
| | ............
............ UA1はGW1User3をちびちび飲みます。| | . . | (R-P: 1)を招待してください。| . . |-------------------------------------->| . 非IPです。| 200 OK| . . |<--------------------------------------| . ネットワークでつなぎます。| ACK| . . |-------------------------------------->| . . | RTP| . . |<===================>| . . | | . . | BYE(推論してください: 先取り| <=Preemption Indication| =4を引き起こしてください; テキストは「非IP Preemption」と等しいです)| . . |<--------------------------------------| . . | | ............
Figure 7. Non-IP Preemption Flow
図7。 非IP先取り流動
In this case, UA1 signals User3 to a session. Once established, there is a preemption event in the non-IP portion of the session/call, and the TDM portion has the ability to inform the SIP GW of this type of event. This non-IP signal can be translated into SIP signaling (into the BYE session termination message). Within this BYE, there should be a Reason header indicating such an event to synchronize all SIP elements.
この場合、UA1はセッションまでUser3に合図します。 いったん設立されると、先取り出来事がセッション/呼び出しの非IP部分にあります、そして、TDM部分には、このタイプの出来事についてSIP GWに知らせる能力があります。 SIPシグナリング(BYEセッション終了メッセージへの)にこの非IP信号を翻訳できます。 このBYEの中に、すべてのSIP要素を同期させるようにそのような出来事を示すReasonヘッダーがあるべきです。
6. Security Considerations
6. セキュリティ問題
Eavesdropping on this header field should not prevent proper operation of the SIP protocol, although some domains utilizing this mechanism for notifying and synchronizing SIP elements will likely want the integrity to be assured. It is therefore RECOMMENDED that integrity protection be applied when using this header to prevent unwanted changes to the field and snooping of the messages. The accepted choices for providing integrity protection in SIP are TLS and S/MIME.
このヘッダーフィールドを立ち聞きする場合、SIPプロトコルの適切な操作は防がれるべきではありません、SIP要素に通知して、同期させるのにこのメカニズムを利用するいくつかのドメインがおそらく保全を保証して欲しくなるでしょうが。 したがって、その分野への求められていない変化を防ぐのにこのヘッダーを使用して、メッセージについて詮索するとき、保全保護が適用されるのは、RECOMMENDEDです。 保全保護をSIPに供給するための受け入れられた選択は、TLSとS/MIMEです。
7. IANA Considerations
7. IANA問題
This document adds to one existing IANA Registry and creates one new Registry. The existing IANA Registry for the SIP Reason Header is as follows:
このドキュメントは、1既存のIANA Registryに加えて、1新しいRegistryを作成します。 SIP Reason Headerのための既存のIANA Registryは以下の通りです:
Polk Standards Track [Page 17] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[17ページ]。
Protocol Value Protocol Cause Reference -------------- -------------- --------- SIP Status code RFC 3261 Q.850 Cause value in decimal ITU-T Q.850
プロトコル値のプロトコル原因参照-------------- -------------- --------- 10進ITU-T Q.850のSIP StatusコードRFC3261Q.850 Cause価値
This document adds to that Registry with the following entry (including the '*' comment):
このドキュメントは以下のエントリーがあるそのRegistryに加えます('*'コメントを含んでいて):
Protocol Value Protocol Cause Reference -------------- -------------- --------- Preemption Cause value in decimal* RFC 4411
プロトコル値のプロトコル原因参照-------------- -------------- --------- 小数*RFC4411の先取りCause価値
* See the separate "Preemption" Registry for default reason-text
strings.
* デフォルト理由テキスト文字列に関して別々の「先取り」Registryを見てください。
The cause values created by the Preemption Protocol namespace in this document are defined in Section 7.1. Each cause value has a Reason- text string as a general description of what the cause value is for. This is shown for the existing Reason header in Section 2 of RFC 3326. Before this document, the Reason-text was taken from the SIP Response code string from all SIP Response codes, or the default description from Q.850 cause codes. Currently, there is no place to register new reason-text strings other than from those two sources. Because this document defines a new Reason header protocol namespace, a new IANA Registry is created in Section 7.2 just for this and future Reason header protocol namespaces (other than SIP Response codes or Q.850 cause values) to register their respective general descriptive text strings. These text strings are non-binding and merely the default for human understanding, but they are deemed important enough to have their own Registry.
Preemptionプロトコル名前空間によって作成された原因値はセクション7.1で本書では定義されます。 それぞれの原因値には、原因値があることに関する概説としてReasonテキスト文字列があります。 これはRFC3326のセクション2における既存のReasonヘッダーのために示されます。 このドキュメントの前に、SIP Responseコード列からすべてのSIP Responseコード、またはデフォルト記述からQ.850原因コードからReason-テキストを取りました。 現在、それらの2つのソース以外の新しい理由テキスト文字列を登録する場所が全くありません。 このドキュメントが新しいReasonヘッダープロトコル名前空間を定義するので、ただこれと将来のReasonヘッダープロトコル名前空間(SIP ResponseコードかQ.850原因値を除いた)がそれらのそれぞれの一般的な説明文ストリングを登録するように、新しいIANA Registryはセクション7.2で作成されます。 これらのテキスト文字列は拘束力がなく、人間のための単にデフォルトは分かっています、しかし、それらはそれら自身のRegistryを持つことができるくらい重要であると考えられます。
7.1. "Preemption" Namespace Registry
7.1. 「先取り」名前空間登録
RFC 4411 creates the new SIP "Reason Header" [1] protocol namespace: "Preemption", with 4 defined cause codes:
RFC4411は新しいSIP「理由ヘッダー」[1]プロトコル名前空間を作成します: 4がある「先取り」は原因コードを定義しました:
In instances where this namespace is used to indicate preemption
at a UA, the following syntax shall be used (the reason-text is a
default string; it is not mandatory, and may be different):
この名前空間がUAで先取りを示すのに使用される例では、以下の構文は使用されるものとします(理由テキストはデフォルトストリングです; それは、義務的でなく、異なっているかもしれません):
Reason: preemption ;cause=1 ;text="UA Preemption"
理由: 先取り; =1を引き起こしてください; テキストは"UA Preemption"と等しいです。
Section 5.1 of this document describes in detail the semantics
of this cause code.
このドキュメントのセクション5.1は詳細にこの原因コードの意味論について説明します。
The default text above is part of a new IANA Registry for
default text strings for any new protocol namespace cause code.
See Section 7.2 for details.
上のデフォルトテキストはどんな新しいプロトコル名前空間原因コードのためのデフォルトテキスト文字列のための新しいIANA Registryの一部です。 詳細に関してセクション7.2を見てください。
Polk Standards Track [Page 18] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[18ページ]。
In instances where this namespace is used to indicate preemption
because an RSVP ResvErr message was received at a SIP UA, the
following syntax shall be used (the reason-text is a default
string; it is not mandatory, and may be different):
この名前空間がSIP UAにRSVP ResvErrメッセージを受け取ったので先取りを示すのに使用される例では、以下の構文は使用されるものとします(理由テキストはデフォルトストリングです; それは、義務的でなく、異なっているかもしれません):
Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
理由: 先取り; =2を引き起こしてください; テキスト=は「Resources Preemptedを予約しました」。
Section 5.2 of this document describes in detail the semantics
of this cause code.
このドキュメントのセクション5.2は詳細にこの原因コードの意味論について説明します。
The default text above is part of a new IANA Registry for
default text strings for any new protocol namespace cause code.
See section 7.2 for details.
上のデフォルトテキストはどんな新しいプロトコル名前空間原因コードのためのデフォルトテキスト文字列のための新しいIANA Registryの一部です。 詳細に関してセクション7.2を見てください。
In instances where this namespace is used to indicate a
generalized preemption event to the destination UA from a Proxy
that modifies the Reason value only during this last SIP hop, the
following syntax shall be used (the reason-text is a default
string; it is not mandatory, and may be different):
この名前空間が最後にこれだけの間にReason値を変更するProxyから目的地UAへの一般化された先取り出来事を示すのに使用されるSIPが飛び越す例では、以下の構文は使用されるものとします(理由テキストはデフォルトストリングです; それは、義務的でなく、異なっているかもしれません):
Reason: preemption ;cause=3 ;text="Generic Preemption"
理由: 先取り; =3を引き起こしてください; テキストは「一般的なPreemption」と等しいです。
Section 5.3 of this document describes in detail the semantics
of this cause code.
このドキュメントのセクション5.3は詳細にこの原因コードの意味論について説明します。
The default text above is part of a new IANA Registry for
default text strings for any new protocol namespace cause code.
See Section 7.2 for details.
上のデフォルトテキストはどんな新しいプロトコル名前空間原因コードのためのデフォルトテキスト文字列のための新しいIANA Registryの一部です。 詳細に関してセクション7.2を見てください。
In instances where this namespace is used to indicate preemption
from a non-IP portion of a call leg, a SIP Gateway shall use the
following syntax to inform the SIP infrastructure of this event
(the reason-text is a default string; it is not mandatory, and may
be different):
この名前空間が呼び出し脚の非IP部分から先取りを示すのに使用される例では、SIPゲートウェイはこの出来事のSIPインフラストラクチャを知らせるのに以下の構文を使用するものとします(理由テキストはデフォルトストリングです; それは、義務的でなく、異なっているかもしれません):
Reason: preemption ;cause=4 ;text=" Non-IP Preemption"
理由: 「先取り; =4を引き起こしてください; テキストは」 Non-IP Preemptionと等しいです」
Section 5.4 of this document describes in detail the semantics
of this cause code.
このドキュメントのセクション5.4は詳細にこの原因コードの意味論について説明します。
The default text above is part of a new IANA Registry for
default text strings for any new protocol namespace cause code.
See Section 7.2 for details.
上のデフォルトテキストはどんな新しいプロトコル名前空間原因コードのためのデフォルトテキスト文字列のための新しいIANA Registryの一部です。 詳細に関してセクション7.2を見てください。
Additional definitions of the preemption namespace and its cause codes MUST be defined in Standards Track documents.
Standards Trackドキュメントで先取り名前空間の追加定義とその原因コードを定義しなければなりません。
Polk Standards Track [Page 19] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[19ページ]。
7.2. Default Reason-Text IANA Registry for the SIP Reason Header
7.2. 一口理由ヘッダーのためのデフォルト理由テキストIANA登録
Below is a new IANA Registry for SIP Reason Header reason-text strings, associated with their respective protocol type and Reason- param cause values. Per RFC 3326, the Reason-text string is a quoted default string with only human understandability meant. These strings can be changed by local policy.
以下に、SIP Reason Header理由テキスト文字列のための新しいIANA Registryがあります、それらのそれぞれのプロトコルタイプとReason- param原因値に関連しています。 RFC3326あたり、Reason-テキスト文字列は人間の理解性だけが意味されている1個の引用されたデフォルトストリングです。 ローカルの方針でこれらのストリングを変えることができます。
Reason-
Protocol param Reason-Text Reference
-------- ------- ------------ ---------
Preemption Cause=1 UA Preemption RFC 4411
Preemption Cause=2 Reserved Resources RFC 4411
Preempted
Preemption Cause=3 Generic Preemption RFC 4411
Preemption Cause=4 Non-IP Preemption RFC 4411
理由プロトコルparam Reason-テキストReference-------- ------- ------------ --------- 4411年の1先取り原因=UAの先取りRFC先取り原因=2は4非IP先取り4411年のリソースRFC4411の先取りされた先取り原因=3の一般的な先取りRFC先取り原因=RFC4411を予約しました。
8. Contributions
8. 貢献
The following individuals contributed to this effort:
以下の個人はこの努力に貢献しました:
Subhasri Dhesikan
Gonzalo Camarillo
Dave Oran
Subhasri Dhesikanゴンサロ・キャマリロデーヴ・オラン
The author thanks these individuals greatly for their aid in this effort.
作者はこの努力における彼らの援助についてこれらの個人に大いに感謝します。
9. Acknowledgements
9. 承認
To Haluk Keskiner for providing a valued sanity check. To Dean Willis, Rohan Mahy, and Allison Mankin for their belief in and backing of this effort. To Adam Roach and Arun Kumar for helpful comments to this document.
評価された健全度チェックを提供するためのHaluk Keskinerに。 それらのこの努力の信念と支援のためのディーン・ウィリス、Rohanマーイ、およびアリソン・マンキンに。 このドキュメントへの役に立つコメントのためのアダム・ローチとアルンクマーに。
Thanks to Mike Pierce for helpful comments and catching a flaw in this spec late in the process (before it was too late).
役に立つコメントと遅く、この仕様に過程でマイク・ピアスに欠点を捕らえてくださってありがとうございます(遅くなり過ぎる前に)。
Polk Standards Track [Page 20] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[20ページ]。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
[1]Schulzrinne、H.、オラン、D.、およびG.キャマリロ、「セッション開始プロトコル(一口)のための理由ヘッダーフィールド」、RFC3326(2002年12月)。
[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] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002.
[3] キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」、RFC3312(2002年10月)。
[4] Schulzrinne, H. and J. Polk, "Communications Resource-Priority
Header in the Session Initiation Protocol (SIP)", RFC 4412,
February 2006.
[4]SchulzrinneとH.とJ.ポーク、「セッション開始プロトコル(一口)のコミュニケーションリソース優先権ヘッダー」、RFC4412、2006年2月。
[5] ITU-T Recommendation Q.850 (1993)
[5] ITU-T推薦Q.850(1993)
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[7] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
10.2. Informative References
10.2. 有益な参照
[8] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, "NSLP
for Quality-of-Service signalling", Work in Progress, September
2005.
[8] J.方法、G.Karagiannis、A.マクドナルド、S.バンデンボッシュ、「サービスのQuality合図のためのNSLP」、Progress、2005年9月のWork。
Author Information
作者情報
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームスM.ポークシスコシステムズ2200の東社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
EMail: jmpolk@cisco.com
メール: jmpolk@cisco.com
Polk Standards Track [Page 21] RFC 4411 SIP Reason Header for Preemption Events February 2006
ポークStandardsは2006年2月に先取り出来事のためにRFC4411一口理由ヘッダーの跡をつけます[21ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Polk Standards Track [Page 22]
ポーク標準化過程[22ページ]
一覧
スポンサーリンク
