RFC5049 日本語訳
5049 Applying Signaling Compression (SigComp) to the SessionInitiation Protocol (SIP). C. Bormann, Z. Liu, R. Price, G.Camarillo, Ed.. December 2007. (Format: TXT=47891 bytes) (Updates RFC3486) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Bormann
Request for Comments: 5049 Universitaet Bremen TZI
Category: Standards Track Z. Liu
Nokia Research Center
R. Price
EADS Defence and Security Systems Limited
G. Camarillo, Ed.
Ericsson
December 2007
コメントを求めるワーキンググループC.ボルマンの要求をネットワークでつないでください: 5049年のUniversitaetブレーメンTZIカテゴリ: 標準化過程Z.リュウノキアのリサーチセンターR.価格イーズディフェンスとセキュリティシステムはエリクソン2007年12月にG.キャマリロ(エド)を制限しました。
Applying Signaling Compression (SigComp)
to the Session Initiation Protocol (SIP)
圧縮(SigComp)にセッション開始プロトコルに合図しながら、適用します。(一口)
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary.
このドキュメントはTCPの上でSignaling Compression(SigComp)がSigCompパラメタ、コンパートメント、および国家管理のSession Initiationプロトコルに適用された(SIP)デフォルトなどのように最小の値であるときに適用されるいくつかの詳細、およびSigCompに関するいくつかの問題について説明します。 SIPとの使用のためのSigCompのどんな実装もこのドキュメントとSigComp、および追加、サポートでSIPとSession記述プロトコル(SDP)の静的な辞書を従わせなければなりません。
Bormann, et al. Standards Track [Page 1] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[1ページ]RFC5049
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Compliance with This Specification ..............................3
4. Minimum Values of SigComp Parameters for SIP/SigComp ............3
4.1. decompression_memory_size (DMS) for SIP/SigComp ............4
4.2. state_memory_size (SMS) for SIP/SigComp ....................4
4.3. cycles_per_bit (CPB) for SIP/SigComp .......................5
4.4. SigComp_version (SV) for SIP/SigComp .......................5
4.5. locally available state (LAS) for SIP/SigComp ..............5
5. Delimiting SIP Messages and SigComp Messages on the Same Port ...5
6. Continuous Mode over TCP ........................................6
7. Too-Large SIP Messages ..........................................7
8. SIP Retransmissions .............................................7
9. Compartment and State Management for SIP/SigComp ................7
9.1. Remote Application Identification ..........................8
9.2. Identifier Comparison Rules ...............................10
9.3. Compartment Opening and Closure ...........................11
9.4. Lack of a Compartment .....................................13
10. Recommendations for Network Administrators ....................13
11. Private Agreements ............................................14
12. Backwards Compatibility .......................................14
13. Interactions with Transport Layer Security (TLS) ..............14
14. Example .......................................................15
15. Security Considerations .......................................17
16. IANA Considerations ...........................................17
17. Acknowledgements ..............................................17
18. References ....................................................18
18.1. Normative References .....................................18
18.2. Informative References ...................................19
1. 序論…3 2. 用語…3 3. この仕様への承諾…3 4. 一口/SigCompのためのSigCompパラメタの最小の値…SIP/SigCompのための3 4.1減圧_メモリ_サイズ(DMS)…4 4.2 SIP/SigCompのために、_メモリ_サイズ(SMS)を述べてください…4 1_あたりの4.3サイクルの_はSIP/SigCompのために(CPB)に噛み付きました…5 4.4. 一口/SigCompのためのSigComp_バージョン(SV)…5 SIP/SigCompのための4.5の局所的に利用可能な状態(LAS)…5 5. 一口メッセージとSigCompメッセージを同じポートに区切ります…5 6. TCPの上の連続したモード…6 7. また、大きい一口メッセージ…7 8. Retransmissionsをちびちび飲んでください…7 9. 一口/SigCompのためのコンパートメントと国家管理…7 9.1. リモートアプリケーション識別…8 9.2. 識別子比較は統治されます…10 9.3. コンパートメント始まりと閉鎖…11 9.4. コンパートメントの不足…13 10. ネットワーク管理者のための推薦…13 11. 個人的な協定…14 12. 遅れている互換性…14 13. 輸送との相互作用はセキュリティ(TLS)を層にします…14 14. 例…15 15. セキュリティ問題…17 16. IANA問題…17 17. 承認…17 18. 参照…18 18.1. 標準の参照…18 18.2. 有益な参照…19
Bormann, et al. Standards Track [Page 2] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[2ページ]RFC5049
1. Introduction
1. 序論
SigComp [RFC3320] is a solution for compressing messages generated by application protocols. Although its primary driver is to compress SIP [RFC3261] messages, the solution itself has been intentionally designed to be application agnostic so that it can be applied to any application protocol; this is denoted as ANY/SigComp. Consequently, many application-dependent specifics are left out of the base standard. It is intended that a separate specification be used to describe those specifics when SigComp is applied to a particular application protocol.
SigComp[RFC3320]は、アプリケーション・プロトコルによって生成されたメッセージを圧縮するためのソリューションです。 プライマリドライバーはSIP[RFC3261]メッセージを圧縮することになっていますが、ソリューション自体はどんなアプリケーション・プロトコルにもそれを適用できるためのアプリケーション不可知論者になるように故意に設計されています。 これはどんな/SigCompとしても指示されます。 その結果、多くのアプリケーション依存する詳細がベース規格から外されます。 別々の仕様がSigCompが特定用途プロトコルに適用されるとき、それらの詳細について説明するのに使用されることを意図します。
This document binds SigComp and SIP; this is denoted as SIP/SigComp.
このドキュメントはSigCompとSIPを縛ります。 これはSIP/SigCompとして指示されます。
2. Terminology
2. 用語
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 RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Compliance with This Specification
3. この仕様への承諾
Any SigComp implementation that is used for the compression of SIP messages MUST conform to this document, as well as to [RFC3320]. Additionally, it must support the SIP/SDP static dictionary, as specified in [RFC3485], and the mechanism for discovering SigComp support at the SIP layer, as specified in [RFC3486].
SIPメッセージの要約に使用されるどんなSigComp実装もこのドキュメントに従わなければなりません、よく[RFC3320]のように。 さらに、SIP/SDPの静的な辞書をサポートしなければなりません、[RFC3485]、およびメカニズムでSIP層でSigCompサポートを発見するのに指定されるように、[RFC3486]で指定されるように。
4. Minimum Values of SigComp Parameters for SIP/SigComp
4. 一口/SigCompのためのSigCompパラメタの最小の値
In order to support a wide range of capabilities among endpoints implementing SigComp, SigComp defines a few parameters to describe SigComp behavior (see Section 3.3 of [RFC3320]). For each parameter, [RFC3320] specifies a minimum value that any SigComp endpoint MUST support for ANY/SigComp. Those minimum values were determined with the consideration of all imaginable devices in which SigComp may be implemented. Scalability was also considered as a key factor.
SigCompを実装しながら終点の中でさまざまな能力をサポートして、SigCompは、SigCompの振舞いについて説明するためにいくつかのパラメタを定義します([RFC3320]のセクション3.3を見てください)。 各パラメタとして、[RFC3320]はどんなSigComp終点もどんな/SigCompのためにもサポートしなければならない最小値を指定します。 それらの最小の値はSigCompが実装されるかもしれないすべての想像可能なデバイスの考慮に決定していました。 また、スケーラビリティは主要因であるとみなされました。
However, some of the minimum values specified in [RFC3320] are too small to allow good performance for SIP message compression. Therefore, they are increased for SIP/SigComp as specified in the following sections. For completeness, those parameters that are the same for SIP/SigComp as they are for ANY/SigComp are also listed.
しかしながら、SIPメッセージ圧縮には、[RFC3320]で指定された最小の値のいくつかが望ましい市場成果を許容できないくらい小さいです。 したがって、それらは以下のセクションの指定されるとしてのSIP/SigCompのために増強されます。 また、完全性において、それらがどんな/SigCompのためのものであっても、それらのSIP/SigCompに、同じパラメタはリストアップされています。
The new minimum values are specific to SIP/SigComp and, thus, do not apply to any other application protocols. A SIP/SigComp endpoint MAY offer additional resources over and above the minimum values
新しい最小の値は、SIP/SigCompに特定であり、その結果、いかなる他のアプリケーション・プロトコルにも適用されません。 SIP/SigComp終点は追加リソースを値の上と最小の値より上まで提供するかもしれません。
Bormann, et al. Standards Track [Page 3] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[3ページ]RFC5049
specified in this document if available; these resources can be advertised to remote endpoints as described in Section 9.4.9 of [RFC3320].
このドキュメントで指定されますが、利用可能。 .9セクション9.4[RFC3320]で説明されるように遠く離れた終点にこれらのリソースの広告を出すことができます。
4.1. decompression_memory_size (DMS) for SIP/SigComp
4.1. SIP/SigCompのための減圧_メモリ_サイズ(DMS)
Minimum value for ANY/SigComp: 2048 bytes, as specified in Section 3.3.1 of [RFC3320].
どんな/SigCompのための最小値も: .1セクション3.3[RFC3320]で指定されるような2048バイト。
Minimum value for SIP/SigComp: 8192 bytes.
SIP/SigCompのための最小値: 8192バイト。
Reason: a DMS of 2048 bytes is too small for SIP message compression as it seriously limits the compression ratio and even makes compression impossible for certain messages. For example, the condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R + 2*S + 128 < DMS (each term is described below). Therefore, if DMS is too small, at least one of C, B, R, or S will be severely restricted. On the other hand, DMS is memory that is only temporarily needed during decompression of a SigComp message (the memory can be reclaimed when the message has been decompressed). Therefore, a requirement of 8 KB should not cause any problems for an endpoint that already implements SIP, SigComp, and applications that use SIP.
理由: 真剣に圧縮比を制限して、圧縮をあるメッセージに不可能にするときさえ、SIPメッセージ圧縮には、2048バイトのDMSは小さ過ぎます。 例えば、状態はSigCompのためにUDP手段の上に[RFC3320]でセットしました: + 2*S+128C+2*B+R<DMS(各用語は以下で説明されます)。 したがって、DMSが小さ過ぎるなら、少なくともC、B、R、またはSの1つは厳しく制限されるでしょう。 他方では、DMSはSigCompメッセージの減圧の間一時必要であるだけであるメモリ(メッセージが減圧されたとき、メモリを取り戻すことができる)です。 したがって、8KBの要件は既にSIPを使用するSIP、SigComp、およびアプリケーションを実装する終点にどんな問題も引き起こすべきではありません。
C size of compressed application message, depending on R
B size of bytecode. Note: two copies -- one as part of the
SigComp message and one in UDVM (Universal Decompressor Virtual
Machine) memory.
R size of circular buffer in UDVM memory
S any additional state uploaded other than that created from the
content of the circular buffer at the end of decompression
(similar to B, two copies of S are needed)
128 the smallest address in UDVM memory to copy bytecode to
バイトコードのR Bサイズに依存する圧縮されたアプリケーションメッセージのCサイズ。 以下に注意してください。 コピー2部--SigCompメッセージの一部としての1とUDVM(普遍的なDecompressor Virtual Machine)メモリの1。 それを除いて、どんな追加州もアップロードしたUDVMメモリSの円形のバッファのRサイズは減圧(Bと同様です、Sのコピー2部が必要である)128の終わりの円形のバッファの中身からバイトコードをコピーするUDVMメモリで最も小さいアドレスを作成しました。
4.2. state_memory_size (SMS) for SIP/SigComp
4.2. SIP/SigCompのための状態_メモリ_サイズ(SMS)
Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in Section 3.3.1 of [RFC3320].
どんな/SigCompのための最小値も: 0 .1セクション3.3[RFC3320]で指定されるようなバイトでない。
Minimum value for SIP/SigComp: 2048 bytes.
SIP/SigCompのための最小値: 2048バイト。
Reason: a non-zero SMS allows an endpoint to upload a state in the first SIP message sent to a remote endpoint without the uncertainty of whether the remote endpoint will have enough memory to store such a state. A non-zero SMS obviously requires the SIP/SigComp implementation to keep state. Based on the observation that there is little gain from stateless SigComp compression, the assumption is that purely stateless SIP implementations are unlikely to provide a
理由: 非ゼロSMSは終点に遠く離れた終点にはそのような状態を保存できるくらいの記憶力があるかどうかに関する不確実性なしで遠く離れた終点に送られた最初のSIPメッセージで状態をアップロードさせます。 非ゼロSMSは、状態を維持するために明らかにSIP/SigComp実装を必要とします。 状態がないSigComp圧縮からの利得がほとんどないという観測に基づいて、仮定は純粋に状態がないSIP実装がaを提供しそうにないということです。
Bormann, et al. Standards Track [Page 4] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[4ページ]RFC5049
SigComp function. Stateful implementations should have little problem to keep 2K additional state for each compartment (see Section 9).
SigCompは機能します。 Stateful実装には、2Kが追加状態であることを各コンパートメントに保つ問題がほとんどあるべきではありません(セクション9を見てください)。
Note: SMS is a parameter that applies to each individual compartment. An endpoint MAY offer different SMS values for different compartments as long as the SMS value is not less than 2048 bytes.
以下に注意してください。 SMSはそれぞれの個々のコンパートメントに適用されるパラメタです。 終点はSMS値が少なくとも2048バイトである限り、異なったコンパートメントのために異なったSMS値を提供するかもしれません。
4.3. cycles_per_bit (CPB) for SIP/SigComp
4.3. SIP/SigCompのための_ビット(CPB)あたりのサイクル_
Minimum value for ANY/SigComp: 16, as specified in Section 3.3.1 of [RFC3320].
どんな/SigCompのための最小値も: 16 .1セクション3.3[RFC3320]で指定されるように。
Minimum value for SIP/SigComp: 16 (same as above).
SIP/SigCompのための最小値: 16 (以下同文。)
4.4. SigComp_version (SV) for SIP/SigComp
4.4. SigComp_バージョン(SV) 一口/SigCompのために
For ANY/SigComp: 0x01, as specified in Section 3.3.2 of [RFC3320].
どんな/SigCompのためにも: 0×01 .2セクション3.3[RFC3320]で指定されるように。
For SIP/SigComp: >= 0x02 (at least SigComp + NACK).
一口/SigCompのために: >= 0×02 (少なくともSigComp+ナック。)
Note that this implies that the provisions of [RFC4077] apply. That is, decompression failures result in SigComp NACK messages sent back to the originating compressor. It also implies that the compressor need not make use of the methods detailed in Section 2.4 of [RFC4077] (Detecting Support for NACK); for example, it can use optimistic compression methods right from the outset.
これが、[RFC4077]に関する条項が適用されるのを含意することに注意してください。 すなわち、SigCompナックメッセージの減圧失敗結果は起因するコンプレッサーを送り返しました。 また、それは、コンプレッサーが[RFC4077]のセクション2.4で詳細なメソッドを利用する必要はないのを含意します(ナックのためにSupportを検出して)。 例えば、それはまさしく着手から楽観的な圧縮方法を使用できます。
4.5. locally available state (LAS) for SIP/SigComp
4.5. SIP/SigCompのための局所的に利用可能な状態(LAS)
Minimum LAS for ANY/SigComp: none, see Section 3.3.3 of [RFC3320].
どんな/SigCompのための最小のLASも: なにもに、.3セクション3.3[RFC3320]を見てください。
Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined in [RFC3485].
一口/SigCompのための最小のLAS: [RFC3485]で定義されるSIP/SDPの静的な辞書。
Note that, since support for the static SIP/SDP dictionary is mandatory, it does not need to be advertised.
静的なSIP/SDP辞書のサポートが義務的であるので広告を出す必要はないことに注意してください。
5. Delimiting SIP Messages and SigComp Messages on the Same Port
5. 一口メッセージとSigCompメッセージを同じポートに区切ります。
In order to limit the number of ports required by a SigComp-aware endpoint, it is possible to allow both SigComp messages and 'vanilla' SIP messages (i.e., uncompressed SIP messages with no SigComp header) to arrive on the same port.
SigComp意識している終点によって必要とされたポートの数を制限するために、SigCompメッセージと'バニラ'SIPメッセージ(すなわち、SigCompヘッダーなしでSIPメッセージを解凍する)の両方が同じポートの上で到着するのを許容するのは可能です。
For a message-based transport such as UDP or Stream Control Transmission Protocol (SCTP), distinguishing between SigComp and non-SigComp messages can be done per message. The receiving endpoint
UDPかStream Control Transmissionプロトコル(SCTP)などのメッセージベースの輸送において、メッセージ単位でSigCompと非SigCompメッセージを見分けることができます。 受信終点
Bormann, et al. Standards Track [Page 5] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[5ページ]RFC5049
checks the first octet of the UDP/SCTP payload to determine whether the message has been compressed using SigComp. If the MSBs (Most Significant Bits) of the octet are "11111", then the message is considered to be a SigComp message and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the message is assumed to be an uncompressed SIP message, and it is passed directly to the application with no further effect on the SigComp layer.
SigCompを使用することでメッセージを圧縮してあるかどうか決定するUDP/SCTPペイロードの最初の八重奏をチェックします。 八重奏のMSBs(ほとんどのSignificant Bits)が「11111」であるなら、メッセージは、SigCompメッセージであると考えられて、[RFC3320]に従って分析されます。 八重奏のMSBsが他の値を取るなら、メッセージは解凍されたSIPメッセージであると思われます、そして、それはSigComp層へのさらなる効果なしで直接アプリケーションに通過されます。
For a stream-based transport such as TCP, distinguishing between SigComp and non-SigComp messages has to be done per connection. The receiving endpoint checks the first octet of the TCP data stream to determine whether the stream has been compressed using SigComp. If the MSBs of the octet are "11111", then the stream is considered to contain SigComp messages and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the stream is assumed to contain uncompressed SIP messages, and it is passed directly to the application with no further effect on the SigComp layer. Note that SigComp message delimiters MUST NOT be used if the stream contains uncompressed SIP messages.
TCPなどのストリームベースの輸送において、SigCompと非SigCompメッセージは接続単位で見分けられなければなりません。 受信終点はSigCompを使用することでストリームを圧縮してあるかどうか決定するTCPデータ・ストリームの最初の八重奏をチェックします。 八重奏のMSBsが「11111」であるなら、ストリームは、SigCompメッセージを含むと考えられて、[RFC3320]に従って分析されます。 八重奏のMSBsが他の値を取るならストリームが解凍されたSIPメッセージを含むと思われて、それはSigComp層へのさらなる効果なしで直接アプリケーションに通過されます。 ストリームが解凍されたSIPメッセージを含んでいるならSigCompメッセージデリミタを使用してはいけないことに注意してください。
Applications MUST NOT mix SIP messages and SigComp messages on a single TCP connection. If the TCP connection is used to carry SigComp messages, then all messages sent over the connection MUST have a SigComp header and be delimited by the use of 0xFFFF, as described in [RFC3320].
アプリケーションはSIPメッセージとSigCompメッセージを単独のTCP接続に混ぜてはいけません。 TCP接続がSigCompメッセージを伝えるのに使用されるなら、接続の上に送られたすべてのメッセージは、SigCompヘッダーがあって、0xFFFFの使用で区切らなければなりません、[RFC3320]で説明されるように。
Section 11 of [RFC4896] details a simple set of bytecodes, intended to be "well-known", that implement a null decompression algorithm. These bytecodes effectively allow SigComp peers to send selected SigComp messages with uncompressed data. If a SIP implementation has reason to send both compressed and uncompressed SIP messages on a single TCP connection, the compressor can be instructed to use these bytecodes to send uncompressed SIP messages that are also valid SigComp messages.
[RFC4896]のセクション11はヌル減圧アルゴリズムを実装する「よく知られること」を意図する簡単なセットのバイトコードを詳しく述べます。 これらのバイトコードで、事実上、SigComp同輩は解凍されたデータがある選択されたSigCompメッセージを送ることができます。 SIP実装に圧縮されて解凍の両方にされたSIPメッセージを単独のTCP接続に送る理由があるなら、コンプレッサーがまた、有効な解凍されたSIPメッセージにSigCompメッセージを送るのにこれらのバイトコードを使用するよう命令できます。
6. Continuous Mode over TCP
6. TCPの上の連続モード
Continuous Mode is a special feature of SigComp, which is designed to improve the overall compression ratio for long-lived connections. Its use requires pre-agreement between the SigComp compressor and decompressor. Continuous mode is not used with SIP/SigComp.
連続したModeはSigCompの特徴です。(SigCompは、長命の接続のために総合的な圧縮比を改良するように設計されています)。 使用はSigCompコンプレッサーと減圧装置とのプレ協定を必要とします。 連続モードはSIP/SigCompと共に使用されません。
Reason: continuous mode requires the transport itself to provide a certain level of protection against denial-of-service attacks. TCP alone is not considered to provide enough protection.
理由: 連続モードは、サービス不能攻撃に対するあるレベルの保護を提供するために輸送自体を必要とします。 TCPだけが十分な保護を提供すると考えられません。
Bormann, et al. Standards Track [Page 6] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[6ページ]RFC5049
7. Too-Large SIP Messages
7. また、大きい一口メッセージ
SigComp does not support the compression of messages larger than 64k. Therefore, if a SIP application sending compressed SIP messages to another SIP application over a transport connection (e.g., a TCP connection) needs to send a SIP message larger than 64k, the SIP application MUST NOT send the message over the same TCP connection. The SIP application SHOULD send the message over a different transport connection (to do this, the SIP application may need to establish a new transport connection).
SigCompは64kより大きいメッセージの要約をサポートしません。 したがって、輸送接続(例えば、TCP接続)の上で圧縮されたSIPメッセージを別のSIPアプリケーションに送るSIPアプリケーションが、64kより大きいSIPメッセージを送る必要があるなら、SIPアプリケーションは同じTCP接続の上にメッセージを送ってはいけません。 SIPアプリケーションSHOULDは異なった輸送接続の上にメッセージを送ります(これをするために、SIPアプリケーションは、新しい輸送接続を確立する必要があるかもしれません)。
8. SIP Retransmissions
8. 一口Retransmissions
When SIP messages are retransmitted, they need to be re-compressed, taking into account any SigComp states that may have been created or invalidated since the previous transmission. Implementations MUST NOT cache the result of compressing the message and retransmit such a cached result.
SIPメッセージが再送されるとき、再圧縮されているのが必要です、前のトランスミッション以来、作成されるか、または無効にされているどんなSigComp州も考慮に入れて。 実装は、メッセージを圧縮するという結果をキャッシュして、そのようなキャッシュされた結果を再送してはいけません。
The reason for this behavior is that it is impossible to know whether the failure causing the retransmission occurred on the message being retransmitted or on the response to that message. If the response was lost, any state changes effected by the first instance of the retransmitted message would already have taken place. If these state changes removed a state that the previously transmitted message relied upon, then retransmission of the same compressed message would lead to a decompression failure.
この振舞いの理由は「再-トランスミッション」を引き起こす失敗が再送されるメッセージかそのメッセージへの応答のときに起こったかどうかを知るのが不可能であるということです。 応答が失われたなら、再送されたメッセージの最初のインスタンスで作用するどんな州の変化も既に起こったでしょう。 これらの州の変化が以前に伝えられたメッセージが当てにした状態を取り除くなら、同じ圧縮されたメッセージの「再-トランスミッション」は減圧失敗に通じるでしょうに。
Note that a SIP retransmission may be caused by the original message or its response being lost by a decompression failure. In this case, a NACK will have been sent by the decompressor to the compressor, which may use the information in this NACK message to adjust its compression parameters. Note that, on an unreliable transport, such a NACK message may still be lost, so if a compressor used some form of optimistic compression, it MAY want to switch to a method less likely to cause any form of decompression failure when compressing a SIP retransmission.
SIP retransmissionが減圧失敗によって失われているオリジナルのメッセージかその応答で引き起こされるかもしれないことに注意してください。 この場合、減圧装置はナックをコンプレッサーに送ってしまうでしょう。(それは、圧縮パラメタを調整するこのナックメッセージの情報を使用するかもしれません)。 コンプレッサーが何らかの形式の楽観的な圧縮を使用したなら、SIP retransmissionを圧縮するとき、どんなフォームの減圧失敗もより引き起こしそうにないメソッドに切り替わりたがっているかもしれないようにそのようなナックメッセージが頼り無い輸送のときにまだ失われているかもしれないことに注意してください。
9. Compartment and State Management for SIP/SigComp
9. 一口/SigCompのためのコンパートメントと国家管理
An application exchanging compressed traffic with a remote application has a compartment that contains state information needed to compress outgoing messages and to decompress incoming messages. To increase the compression efficiency, the application must assign distinct compartments to distinct remote applications.
リモートアプリケーションと圧縮されたトラフィックを交換するアプリケーションは情報が送信されるメッセージを圧縮して、入力メッセージを減圧する必要があった状態を含むコンパートメントを持っています。 圧縮効率を増強するために、アプリケーションは異なったリモートアプリケーションに異なったコンパートメントを割り当てなければなりません。
Bormann, et al. Standards Track [Page 7] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[7ページ]RFC5049
9.1. Remote Application Identification
9.1. リモートアプリケーション識別
SIP/SigComp applications identify remote applications by their SIP/ SigComp identifiers. Each SIP/SigComp application MUST have a SIP/ SigComp identifier URN (Uniform Resource Name) that uniquely identifies the application. Usage of a URN provides a persistent and unique name for the SIP/SigComp identifier. It also provides an easy way to guarantee uniqueness. This URN MUST be persistent as long as the application stores compartment state related to other SIP/SigComp applications.
SIP/SigCompアプリケーションはそれらのSIP/ SigComp識別子でリモートアプリケーションを特定します。 それぞれのSIP/SigCompアプリケーションには、唯一アプリケーションを特定するSIP/ SigComp識別子URN(一定のResource Name)がなければなりません。 URNの使用法は永続的でユニークな名前をSIP/SigComp識別子に提供します。 また、それはユニークさを保証する簡単な方法を提供します。 このURN MUST、アプリケーションが他のSIP/SigCompアプリケーションに関連するコンパートメント州を保存する限り、永続的であってください。
A SIP/SigComp application SHOULD use a UUID (Universally Unique IDentifier) URN as its SIP/SigComp identifier, due to the difficulties in equality comparisons for other kinds of URNs. The UUID URN [RFC4122] allows for non-centralized computation of a URN based on time, unique names (such as a Media Access Control (MAC) address), or a random number generator. If a URN scheme other than UUID is used, the URN MUST be selected such that the application can be certain that no other SIP/SigComp application would choose the same URN value.
A SIP/SigCompアプリケーションSHOULDがUUIDを使用する、(一般に、Unique IDentifier) SIP/SigComp識別子(URNsの他の種類のための平等比較における困難への支払われるべきもの)としてのURN UUID URN[RFC4122]は時間、ユニークな名前(メディアAccess Control(MAC)アドレスなどの)、または乱数発生器に基づくURNの非集結された計算を考慮します。 使用されるUUID、URN MUST以外のURN体系がアプリケーションがいいえを確信している場合があるくらいの選択されたそのようなものであるなら、他のSIP/SigCompアプリケーションは同じURN値を選ぶでしょう。
Note that the definition of SIP/SigComp identifier is similar to the definition of instance identifier in [OUTBOUND]. One difference is that instance identifiers are only required to be unique within their AoR (Address of Record) while SIP/SigComp identifiers are required to be globally unique.
SIP/SigComp識別子の定義が[OUTBOUND]とのインスタンス識別子の定義と同様であることに注意してください。 1つの違いはインスタンス識別子がSIP/SigComp識別子がグローバルに特有になるのに必要である間、それらのAoR(Recordのアドレス)の中で特有になるのに必要であるだけであるということです。
Even if instance identifiers are only required to be unique within their AoR, devices may choose to generate globally unique instance identifiers. A device with a globally unique instance identifier SHOULD use its instance identifier as its SIP/SigComp identifier.
インスタンス識別子がそれらのAoRの中で特有になるのに必要であるだけであっても、デバイスは、グローバルにユニークなインスタンス識別子を生成するのを選ぶかもしれません。 グローバルにユニークなインスタンス識別子SHOULDがあるデバイスはSIP/SigComp識別子としてインスタンス識別子を使用します。
Note: Using the same value for an entity's instance and
SIP/SigComp identifiers improves the compression ratio of header
fields that carry both identifiers (e.g., a Contact header field
in a REGISTER request).
以下に注意してください。 実体のインスタンスとSIP/SigComp識別子に同じ値を使用すると、両方の識別子(例えば、REGISTER要求におけるContactヘッダーフィールド)を運ぶヘッダーフィールドの圧縮比は改良されます。
Server farms that share SIP/SigComp state across servers MUST use the same SIP/SigComp identifier for all their servers.
サーバの向こう側にSIP/SigComp状態を共有するサーバー・ファームはそれらのすべてのサーバに同じSIP/SigComp識別子を使用しなければなりません。
SIP/SigComp identifiers are carried in the 'sigcomp-id' SIP URI (Uniform Resource Identifier) or Via header field parameter. The 'sigcomp-id' SIP URI parameter is a 'uri-parameter', as defined by the SIP ABNF (Augmented Backus-Naur Form, Section 25.1 of [RFC3261]). The following is its ABNF [RFC4234]:
SIP/SigComp識別子は'sigcomp-イド'SIP URI(Uniform Resource Identifier)かViaヘッダーフィールドパラメタで運ばれます。 'sigcomp-イド'SIP URIパラメタは'uri-パラメタ'です、SIP ABNF(BN記法、[RFC3261]のセクション25.1を増大させる)によって定義されるように。 ↓これはABNF[RFC4234]です:
uri-sip-sigcomp-id = "sigcomp-id=" 1*paramchar
uri一口sigcompイド=「sigcompイド=」1*paramchar
Bormann, et al. Standards Track [Page 8] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[8ページ]RFC5049
The SIP URI 'sigcomp-id' parameter MUST contain a URN [RFC2141].
SIP URI'sigcomp-イド'パラメタはURN[RFC2141]を含まなければなりません。
The Via 'sigcomp-id' parameter is a 'via-extension', as defined by the SIP ABNF (Section 25.1 of [RFC3261]). The following is its ABNF [RFC4234]:
Via'sigcomp-イド'パラメタがそうである、'拡大'、SIP ABNF([RFC3261]のセクション25.1)によって定義されるように。 ↓これはABNF[RFC4234]です:
via-sip-sigcomp-id = "sigcomp-id" EQUAL
LDQUOT *( qdtext / quoted-pair ) RDQUOT
一口sigcompイドで、「sigcomp-イド」EQUAL LDQUOT*(引用されたqdtext/組の)RDQUOTと等しいです。
The Via 'sigcomp-id' parameter MUST contain a URN [RFC2141].
Via'sigcomp-イド'パラメタはURN[RFC2141]を含まなければなりません。
The following is an example of a 'sigcomp-id' SIP URI parameter:
↓これは'sigcomp-イド'SIP URIパラメタに関する例です:
sigcomp-id=urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128
sigcompイド=つぼ:uuid:0C67446E- F1A1-11D9-94D3-000A95A0E128
The following is an example of a Via header field with a 'sigcomp-id' parameter:
↓これは'sigcomp-イド'パラメタがあるViaヘッダーフィールドに関する例です:
Via: SIP/2.0/UDP server1.example.com:5060
;branch=z9hG4bK87a7
;comp=sigcomp
;sigcomp-id="urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128"
以下を通って SIP/2.0/UDP server1.example.com: 5060; ブランチ=z9hG4bK87a7; コンピュータはsigcompと等しいです; sigcomp-イドは「つぼ:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128」と等しいです。
The following is an example of a REGISTER request that carries 'sigcomp-id' parameters in a Via entry and in the Contact header field. Additionally, it also carries a '+sip.instance' Contact header field parameter.
運ばれるREGISTER要求に関する例が'sigcomp-イド'であるというViaエントリーとContactヘッダーフィールドにおける以下のパラメタ。 'また、さらに、それは'+ sip.instance'Contactヘッダーフィールドパラメタを運びます。
REGISTER sip:example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav;
rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473"
From: "Joe User" <sip:2145550500@example.net>;tag=6to4gh7t5j
To: "Joe User" <sip:2145550500@example.net>
Call-ID: 3c26700c1adb-lu1lz5ri5orr
CSeq: 215196 REGISTER
Max-Forwards: 70
Contact: <sip:2145550500@192.0.2.247:2078;
sigcomp-id=urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>;
q=1.0; expires=3600;
+sip.instance="<urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>"
Content-Length: 0
REGISTER一口: example.net SIP/2.0Via: 一口/2.0/UDP192.0.2.247: 2078; ブランチはz9hG4bK-et736vsjiravと等しいです。 rport; sigcompイド=「つぼ:uuid:2e5fdc76-00be-4314-8202-1116fa82a473」From: 「ジョーUser」<一口: 2145550500@example.net 、gt;、;=6to4gh7t5j To:にタグ付けをしてください 「ジョーUser」<一口: 2145550500@example.net 、gt;、呼び出しID: 3c26700c1adb-lu1lz5ri5orr CSeq: 215196 前方へマックスを登録してください: 70 接触: <一口: 2145550500@192.0.2.247 :2078。 sigcomp-イドはつぼ:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>と等しいです。 q=1.0。 =3600を吐き出します。 + sip.instanceは「<つぼ:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>」コンテンツの長さと等しいです: 0
SIP messages are matched with remote application identifiers as follows:
リモートアプリケーション識別子は以下の通りでSIPメッセージは合わせられています:
Outgoing requests: the remote application identifier is the SIP/
SigComp identifier of the URI to which the request is sent. If
the URI does not contain a SIP/SigComp identifier, the remote
送信する要求: リモートアプリケーション識別子は要求が送られるURIに関するSIP/ SigComp識別子です。 URIがSIP/SigComp識別子、リモートを含んでいないなら
Bormann, et al. Standards Track [Page 9] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[9ページ]RFC5049
application identifier is the IP address plus port of the datagram
carrying the request for connectionless transport protocols, and
the transport connection (e.g., a TCP connection) carrying the
request for connection-oriented transport protocols (this is to
support legacy SIP/SigComp applications).
アプリケーション識別子は、IPアドレスと、コネクションレスなトランスポート・プロトコルを求める要求を運ぶデータグラムのポートと、接続指向のトランスポート・プロトコルを求める要求を載せている輸送接続(例えば、TCP接続)(これはレガシーSIP/SigCompアプリケーションをサポートするためのものである)です。
Incoming responses: the remote application identifier is the same as
that of the previously sent request that initiated the transaction
to which the response belongs.
入って来る応答: リモートアプリケーション識別子は応答が属するトランザクションを開始した以前に送られた要求のものと同じです。
Incoming requests: the remote application identifier is the SIP/
SigComp identifier of the top-most Via entry. If the Via header
field does not contain a SIP/SigComp identifier, the remote
application identifier is the source IP address plus port of the
datagram carrying the request for connectionless transport
protocols, and the transport connection (e.g., a TCP connection)
carrying the request for connection-oriented transport protocols
(this is to support legacy SIP/SigComp applications).
入って来る要求: リモートアプリケーション識別子は最も先端Viaエントリーに関するSIP/ SigComp識別子です。 ViaヘッダーフィールドがSIP/SigComp識別子を含んでいないなら、リモートアプリケーション識別子は、ソースIPアドレスと、コネクションレスなトランスポート・プロトコルを求める要求を運ぶデータグラムのポートと、接続指向のトランスポート・プロトコルを求める要求を載せている輸送接続(例えば、TCP接続)(これはレガシーSIP/SigCompアプリケーションをサポートするためのものである)です。
Outgoing responses: the remote application identifier is the same as
that of the previously received request that initiated the
transaction to which the response belongs. Note that, due to
standard SIP Via header field processing, this identifier will be
present in the top-most Via entry in such responses (as long as it
was present in the top-most Via entry of the previously received
request).
外向的な応答: リモートアプリケーション識別子は応答が属するトランザクションを開始した以前に受信された要求のものと同じです。 この識別子が標準のSIP Viaヘッダーフィールド処理のためにそのような応答における最も先端Viaエントリーに存在することに注意してください(それが以前に受信された要求の最も先端Viaエントリーに存在していた限り)。
A SIP/SigComp application placing its URI with the 'comp=sigcomp' parameter in a header field MUST add a 'sigcomp-id' parameter with its SIP/SigComp identifier to that URI.
ヘッダーフィールドで'コンピュータ=sigcomp'パラメタにURIを置くSIP/SigCompアプリケーションはSIP/SigComp識別子で'sigcomp-イド'パラメタをそのURIに加えなければなりません。
A SIP/SigComp application generating its own Via entry containing the 'comp=sigcomp' parameter MUST add a 'sigcomp-id' parameter with its SIP/SigComp identifier to that Via entry.
それ自身のViaが'コンピュータ=sigcomp'パラメタを含むエントリーであると生成するSIP/SigCompアプリケーションはSIP/SigComp識別子で'sigcomp-イド'パラメタをそのViaエントリーに加えなければなりません。
A given remote application identifier is mapped to a particular SigComp compartment ID following the rules given in Section 9.3.
セクション9.3で与えられた規則に従って、与えられたリモートアプリケーション識別子は特定のSigCompコンパートメントIDに写像されます。
9.2. Identifier Comparison Rules
9.2. 識別子比較規則
Equality comparisons between SIP/SigComp identifiers are performed using the rules for URN equality that are specific to the scheme in the URN. If the element performing the comparisons does not understand the URN scheme, it performs the comparisons using the lexical equality rules defined in RFC 2141 [RFC2141]. Lexical equality may result in two URNs being considered unequal when they are actually equal. In this specific usage of URNs, the only element that provides the URN is the SIP/SigComp application identified by
SIP/SigComp識別子での平等比較は、URNでURN平等のための体系に特定の規則を使用することで実行されます。 比較を実行する要素がURN体系を理解していないなら、それは、RFC2141[RFC2141]で定義された語彙平等規則を使用することで比較を実行します。 語彙平等は彼らが実際に等しいときに不平等であると考えられる2URNsをもたらすかもしれません。 URNsのこの特定の使用法で、URNを提供する唯一の要素が特定されたSIP/SigCompアプリケーションです。
Bormann, et al. Standards Track [Page 10] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[10ページ]RFC5049
that URN. As a result, the SIP/SigComp application SHOULD provide lexically equivalent URNs in each registration it generates. This is likely to be normal behavior in any case; applications are not likely to modify the value of their SIP/SigComp identifiers so that they remain functionally equivalent yet lexicographically different from previous identifiers.
そのURN。 その結果、SIP/SigCompアプリケーションSHOULDはそれが生成する各登録に辞書的に同等なURNsを提供します。 これはどのような場合でも正常な行動である傾向があります。 アプリケーションがそれらのSIP/SigComp識別子の値を変更しそうにないので、それらは機能上同等ですが、前の識別子と辞書編集に異なったままで残っています。
9.3. Compartment Opening and Closure
9.3. コンパートメント始まりと閉鎖
SIP applications need to know when to open a new compartment and when to close it. The lifetime of SIP/SigComp compartments is linked to registration state. Compartments are opened at SIP registration time and are typically closed when the registration expires or is canceled.
SIPアプリケーションは、いつ新しいコンパートメントを開くか、そして、いつそれを閉じるかを知る必要があります。 SIP/SigCompコンパートメントの寿命は登録状態にリンクされます。 コンパートメントは、SIP登録時間で開かれて、登録が期限が切れるか、または中止されるとき、通常閉じられます。
Note: Linking the lifetime of SIP/SigComp compartments to
registration state limits the applicability of this specification.
In particular, SIP user agents that do not register but, for
example, only handle PUBLISH or SUBSCRIBE/NOTIFY transactions are
not able create SIP/SigComp compartments following this
specification. Previous revisions of this specification also
defined compartments valid during a SIP transaction or a SIP
dialog. Those compartments covered all possible SIP entities,
including those that do not handle REGISTER transactions.
However, it was decided to eliminate those types of compartments
because the complexity they introduced (e.g., edge proxy servers
were required to keep dialog state) was higher than the benefits
they brought in most deployment scenarios.
以下に注意してください。 SIP/SigCompコンパートメントの生涯を登録にリンクして、州はこの仕様の適用性を制限します。 登録、レジスタではなく、例えば、唯一のハンドルPUBLISHか/NOTIFYにトランザクションをするSIPユーザエージェントは特に、できません。この仕様に従って、SIP/SigCompコンパートメントを作成してください。 また、この仕様の前の改正はSIPトランザクションかSIP対話の間、有効なコンパートメントを定義しました。 それらのコンパートメントはREGISTERトランザクションを扱わないものを含むすべての可能なSIP実体をカバーしました。 しかしながら、それらが導入した(例えば縁のプロキシサーバが対話状態を維持するのに必要でした)複雑さが利益より高かったのでコンパートメントのそういったタイプの人を排除するために、ほとんどの展開シナリオを持って入ったと決められました。
Usually, any states created during the lifetime of a compartment will be "logically" deleted when the compartment is closed. As described in Section 6.2 of [RFC3320], a logical deletion can become a physical deletion only when no compartment continues to exist that created the (same) state.
コンパートメントが閉じられるとき、通常、コンパートメントの生涯創設されたどんな州も「論理的に」削除されるでしょう。 [RFC3320]のセクション6.2で説明されるように、論理的な削除はコンパートメントが全く存続しないときのだけ(同じ)の状態を創設した物理的な削除になることができます。
A SigComp endpoint may offer to keep a state created upon request from a SigComp peer endpoint beyond the default lifetime of a compartment (i.e., beyond the duration of its associated registration). This may be used to improve compression efficiency of subsequent SIP messages generated by the same remote application at the SigComp peer endpoint. To indicate that such state will continue to be available, the SigComp endpoint can inform its peer SigComp endpoint by announcing the (partial) state ID in the returned SigComp parameters at the end of the registration that was supposed to limit the lifetime of the SigComp state. That signals the state will be maintained. The mandatory support for the SigComp Negative
SigComp終点はコンパートメント(すなわち、関連登録の持続時間を超えた)の生涯を州が要求のときにデフォルトを超えてSigComp同輩終点から作成した生活費に提供するかもしれません。 これは、SigComp同輩終点の同じリモートアプリケーションで生成されたその後のSIPメッセージの圧縮効率を高めるのに使用されるかもしれません。 そのような州がずっと利用可能であることを示すために、SigComp終点はSigComp状態の生涯を制限するべきであった登録の終わりの返されたSigCompパラメタの(部分的)の州のIDを発表することによって、同輩SigComp終点を知らせることができます。 状態がそうする信号は維持されます。 SigComp Negativeの義務的なサポート
Bormann, et al. Standards Track [Page 11] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[11ページ]RFC5049
Acknowledgement (NACK) Mechanism [RFC4077] in SIP/SigComp ensures that it is possible to recover from synchronization errors regarding compartment lifetimes.
SIP/SigCompの承認(ナック)メカニズム[RFC4077]は、コンパートメント生涯に関して同期誤りから克服するのが可能であることを確実にします。
As an operational concern, bugs in the compartment management implementation are likely to lead to sporadic, hard-to-diagnose failures. Decompressors may therefore want to cache old state and, if still available, allow access while logging diagnostic information. Both compressors and decompressors use the SigComp Negative Acknowledgement (NACK) Mechanism [RFC4077] to recover from situations where such old state may no longer be available.
操作上の関心として、コンパートメント管理実装におけるバグは過疎と、診断しにくい失敗に通じそうです。 減圧装置は、古い状態をキャッシュして、したがって、まだ利用可能であるなら、診断情報を登録している間、アクセスを許したがっているかもしれません。 コンプレッサーと減圧装置の両方が、そのような古い状態がもう利用可能でないかもしれない状況から回復するのに、SigComp Negative Acknowledgement(ナック)メカニズム[RFC4077]を使用します。
A REGISTER transaction causes an application to open a new compartment to be valid for the duration of the registration established by the REGISTER transaction.
REGISTERトランザクションで、アプリケーションは、REGISTERトランザクションによって確立された登録の持続時間に有効になるように新しいコンパートメントを開きます。
A SIP application that needs to send a compressed SIP REGISTER (i.e., a user agent generating a REGISTER or a proxy server relaying one to its next hop) SHOULD open a compartment for the request's remote application identifier. A SIP application that receives a compressed SIP REGISTER (i.e., the registrar or a proxy relaying the REGISTER to its next-hop) SHOULD open a compartment for the request's remote application identifier.
圧縮されたSIP REGISTER(すなわち、REGISTERを生成するユーザエージェントか次のホップに1つをリレーするプロキシサーバ)SHOULDを送る必要があるSIPアプリケーションは要求のリモートアプリケーション識別子のためにコンパートメントを開きます。 圧縮されたSIP REGISTER(次のホップにREGISTERをリレーするすなわち、記録係かプロキシ)SHOULDを受けるSIPアプリケーションは要求のリモートアプリケーション識別子のためにコンパートメントを開きます。
These compartments MAY be closed if the REGISTER request is responded with a non-2xx final response, or when the registration expires or is canceled. However, applications MAY also choose to keep these compartments open for a longer period of time, as discussed previously. For a given successful registration, applications SHOULD NOT close their associated compartments until the registration is over.
登録がREGISTER要求が非2xxの最終的な応答で反応するか、期限が切れるか、または中止されるとき、これらのコンパートメントは閉じられるかもしれません。 しかしながら、また、アプリケーションは、以前に議論するように、より長い期間の間、これらのコンパートメントを開くように保つのを選ぶかもしれません。 与えられたうまくいっている登録のために、登録が終わるまで、アプリケーションSHOULD NOTはそれらの関連コンパートメントを閉じます。
Note: A SIP network can be configured so that regular SIP traffic
to and from a user agent traverses a different set of proxies than
the initial REGISTER transaction. The path the REGISTER
transaction follows is typically determined by configuration data.
The path subsequent requests traverse is determined by the Path
[RFC3327] and the Service-Route [RFC3308] header fields in the
REGISTER transaction and by the Record-Route and the Route header
fields in dialog-creating transactions. Previous revisions of
this document supported the use of different paths for different
types of traffic. However, for simplicity reasons, this document
now assumes that networks using compression will be configured so
that subsequent requests follow the same path as the initial
REGISTER transaction in order to achieve the best possible
compression. Section 10 provides network administrators with
recommendations so that they can configure the networks properly.
以下に注意してください。 SIPネットワークを構成できるので、エージェントとユーザエージェントからの通常のSIPトラフィックは初期のREGISTERトランザクションより異なったプロキシを横断します。 REGISTERトランザクションが続く経路はコンフィギュレーション・データで通常決定しています。 その後の要求が横断する経路は、REGISTERトランザクションとRecord-ルートによるPath[RFC3327]とService-ルートによって決定している[RFC3308]ヘッダーフィールドと対話を作成するトランザクションでRouteヘッダーフィールドです。 このドキュメントの前の改正は異なった経路の異なったタイプのトラフィックの使用をサポートしました。 しかしながら、簡単さ理由で、このドキュメントは、現在、圧縮を使用するネットワークが構成されるのでその後の要求が可能な限り良い圧縮を達成するために初期のREGISTERトランザクションと同じ経路に続くと仮定します。 セクション10は、適切にネットワークを構成できるように、ネットワーク管理者に推薦を提供します。
Bormann, et al. Standards Track [Page 12] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[12ページ]RFC5049
If, following the rules above, a SIP application is supposed to open a compartment for a remote application identifier for which it already has a compartment (e.g., the SIP application registers towards a second registrar using the same edge proxy server as for its registration towards its first registrar), the SIP application MUST use the already existing compartment. That is, the SIP application MUST NOT open a new compartment.
上の規則に従って、SIPアプリケーションがそれが既に、コンパートメント(例えば、登録のように最初の記録係に向かって同じ縁のプロキシサーバを使用している2番目の記録係に向かったSIPアプリケーションレジスタ)を持っているリモートアプリケーション識別子のためにコンパートメントを開くべきであるなら、SIPアプリケーションは既に既存のコンパートメントを使用しなければなりません。 すなわち、SIPアプリケーションは新しいコンパートメントを開いてはいけません。
9.4. Lack of a Compartment
9.4. コンパートメントの不足
The use of stateless compression (i.e., compression without a compartment) is not typically worthwhile and may even result in message expansion. Therefore, if a SIP application does not have a compartment for a message it needs to send, it MAY choose not to compress it even in the presence of the 'comp=sigcomp' parameter. Section 5 describes how a SIP application can send compressed and uncompressed messages over the same TCP connection. Note that RFC 3486 [RFC3486] states the following:
状態がない圧縮(すなわち、コンパートメントのない圧縮)の使用は、通常の価値がなくて、メッセージ拡張をもたらしさえするかもしれません。 したがって、SIPアプリケーションにそれが送る必要があるメッセージのためのコンパートメントがないなら、それは、'コンピュータ=sigcomp'パラメタがあるときさえそれを圧縮しないのを選ぶかもしれません。 セクション5はアプリケーションが送ることができるSIPが同じTCP接続の上でどうメッセージを圧縮して、解凍したかを説明します。 RFC3486[RFC3486]が以下を述べることに注意してください:
"If the next-hop URI contains the parameter comp=sigcomp, the
client SHOULD compress the request using SigComp".
「次のホップURIがパラメタコンピュータ=sigcompを含んでいるなら、クライアントSHOULDはSigCompを使用することで要求を圧縮します。」
Experience since RFC 3486 [RFC3486] was written has shown that stateless compression is, in most cases, not worthwhile. That is why it is not recommended to use it any longer.
RFC3486[RFC3486]が書かれて以来、経験は、多くの場合、状態がない圧縮価値がないのを示しています。 それはそれがもうそれを使用することは勧められない理由です。
10. Recommendations for Network Administrators
10. ネットワーク管理者のための推薦
Network administrators can configure their networks so that the compression efficiency achieved is increased. The following recommendations help network administrators perform their task.
ネットワーク管理者が彼らのネットワークを構成できるので、効率が実現した圧縮は増強されます。 以下の推薦は、ネットワーク管理者が彼らのタスクを実行するのを助けます。
For a given user agent, the route sets for incoming requests (created by a Path header field) and for outgoing requests (created by a Service-Route header field) are typically the same. However, registrars can, if they wish, insert proxies in the latter route that do not appear in the former route and vice versa. It is RECOMMENDED that registrars are configured so that proxies performing SigComp compression appear in both routes.
与えられたユーザエージェントにとって、入って来る要求(Pathヘッダーフィールドで、作成される)と送信する要求(Service-ルートヘッダーフィールドで、作成される)のためのルートセットは通常同じです。 しかしながら、彼らが願うなら、記録係は前のルートに逆もまた同様に現れない後者のルートによるプロキシを挿入できます。 記録係が構成されるのが、RECOMMENDEDであるので、SigComp圧縮を実行しているプロキシが両方のルートに現れます。
The routes described previously apply to requests sent outside a dialog. Requests inside a dialog follow a route constructed using Record-Route header fields. It is RECOMMENDED that the proxies performing SigComp that are in the route for requests outside a dialog are configured to place themselves (by inserting themselves in the Record-Route header fields) in the routes used for requests inside dialogs.
以前に説明されたルートは対話の外で送られた要求に適用されます。 対話における要求はRecord-ルートヘッダーフィールドを使用することで構成されたルートに従います。 対話の外で要求のためのルートにあるSigCompを実行しているプロキシが自分たち(Record-ルートヘッダーフィールドに自分たちを挿入するのによる)を要求に対話に使用されるルートに置くために構成されるのは、RECOMMENDEDです。
Bormann, et al. Standards Track [Page 13] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[13ページ]RFC5049
When a user agent's registration expires, proxy servers performing compression may close their associated SIP/SigComp compartment. If the user agent is involved in a dialog that was established before the registration expired, subsequent requests within the dialog may not be compressed any longer. In order to avoid this situation, it is RECOMMENDED that user agents are registered as long as they are involved in a dialog.
ユーザエージェントの登録が期限が切れると、圧縮を実行するプロキシサーバはそれらの関連SIP/SigCompコンパートメントを閉じるかもしれません。 ユーザエージェントが登録が期限が切れる前に確立された対話にかかわるなら、対話の中のその後の要求はもう圧縮されないかもしれません。 この状況を避けるために、彼らが対話にかかわる限り、ユーザエージェントが登録されているのは、RECOMMENDEDです。
11. Private Agreements
11. 個人的な協定
SIP/SigComp implementations that are subject to private agreements MAY deviate from this specification, if the private agreements unambiguously specify so. Plausible candidates for such deviations include:
したがって、個人的な協定が明白に指定するなら、個人的な協定を受けることがあるSIP/SigComp実装はこの仕様から逸れるかもしれません。 そのような逸脱のもっともらしい候補は:
o Minimum values (Section 4). o Use of continuous mode (Section 6). o Compartment definition (Section 9).
o 最小の値(セクション4)連続モード(セクション6)o Compartment定義(セクション9)のo Use。
12. Backwards Compatibility
12. 遅れている互換性
SigComp has a number of parameters that can be configured per endpoint. This document specifies a profile for SigComp when used for SIP compression that further constrains the range that some of these parameters may take. Examples of this are Decompressor Memory Size, State Memory Size, and SigComp Version (support for NACK). Additionally, this document specifies how SIP/SigComp applications should perform compartment mapping.
SigCompには、終点単位で構成できる多くのパラメタがあります。 さらに、これらのパラメタのいくつかが取るかもしれない範囲を抑制するSIP圧縮に使用されると、このドキュメントはSigCompのためのプロフィールを指定します。 この例は、Decompressor Memory Sizeと、州Memory Sizeと、SigCompバージョン(ナックのサポート)です。 さらに、このドキュメントはSIP/SigCompアプリケーションがどうコンパートメントマッピングを実行するべきであるかを指定します。
When this document was written, there were already a few existing SIP/SigComp deployments. The rules in this document have been designed to maximize interoperability with those legacy SIP/SigComp implementations. Nevertheless, implementers should be aware that legacy SIP/SigComp implementations may not conform to this specification. Examples of problems with legacy applications would be smaller DMS than mandated in this document, lack of NACK support, or a different compartment mapping.
このドキュメントが書かれたとき、既に、いくつかの既存のSIP/SigComp展開がありました。 規則は、それらのレガシーSIP/SigComp実装で相互運用性を最大にするように本書では設計されています。 それにもかかわらず、implementersはレガシーSIP/SigComp実装がこの仕様に従わないかもしれないのを意識しているべきです。 レガシーアプリケーションに関する問題に関する例は、本書では強制されるより小さいDMS、ナックのサポートの不足、または異なったコンパートメントマッピングでしょう。
13. Interactions with Transport Layer Security (TLS)
13. トランスポート層セキュリティとの相互作用(TLS)
Endpoints exchanging SIP traffic over a TLS [RFC4346] connection can use the compression provided by TLS. Two endpoints exchanging SIP/ SigComp traffic over a TLS connection that provides compression need to first compress the SIP messages using SigComp and then pass them to the TLS layer, which will compress them again. When receiving data, the processing order is reversed.
TLS[RFC4346]接続の上とSIPトラフィックを交換する終点はTLSによって提供された圧縮を使用できます。 圧縮を提供するTLS接続の上とSIP/ SigCompトラフィックを交換する2つの終点が、最初にSigCompを使用することでSIPメッセージを圧縮するのが必要であり、次に、TLS層にそれらを通過します。(それは、再び彼らを圧縮するでしょう)。 データを受け取るとき、処理命令は逆にされます。
Bormann, et al. Standards Track [Page 14] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[14ページ]RFC5049
However, compressing messages this way twice does not typically bring significant gains. Once a message is compressed using SigComp, TLS is not usually able to compress it further. Therefore, TLS will normally only be able to compress SigComp code sent between compressor and decompressor. Since the gain of having SigComp code compressed should be minimal in most cases, it is NOT RECOMMENDED to use TLS compression when SigComp compression is being used.
しかしながら、このようにメッセージを二度圧縮するのは重要な利得を通常もたらしません。 メッセージがSigCompを使用することでいったん圧縮されると、通常、TLSはさらにそれを圧縮できません。 したがって、通常、TLSはコンプレッサーと減圧装置の間に送られたSigCompコードを圧縮できるだけでしょう。 SigCompコードを圧縮させる獲得が多くの場合最小限であるべきであるので、それはSigComp圧縮が使用されているときTLS圧縮を使用するNOT RECOMMENDEDです。
14. Example
14. 例
Figure 1 shows an example message flow where the user agent and the outbound proxy exchange compressed SIP traffic. Compressed messages are marked with a (c).
図1は、ユーザエージェントと外国行きのプロキシ交換がSIPトラフィックをどこに圧縮したかを例のメッセージ流動に示します。 圧縮されたメッセージは(c)でマークされます。
User Agent Outbound Proxy Registrar
ユーザのエージェントの外国行きのプロキシ記録係
|(1) REGISTER (c) | |
|---------------->| |
| |(2) REGISTER |
| |---------------->|
| |(3) 200 OK |
| |<----------------|
|(4) 200 OK (c) | |
|<----------------| |
|(5) INVITE (c) | |
|---------------->| |
| |(6) INVITE |
| |------------------------------>
| |(7) 200 OK |
| |<------------------------------
|(8) 200 OK (c) | |
|<----------------| |
|(9) ACK (c) | |
|---------------->| |
| |(10) ACK |
| |------------------------------>
|(11) BYE (c) | |
|---------------->| |
| |(12) BYE |
| |------------------------------>
| |(13) 200 OK |
| |<------------------------------
|(14) 200 OK (c) | |
|<----------------| |
| (1) (c)を登録してください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(2) レジスタ| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(3) 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(4) 200 OK(c)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(5) (c)を招待してください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(6) 招待| | |------------------------------> | |(7) 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- |(8) 200 OK(c)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(9) ACK(c)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(10) ACK| | |------------------------------>|、(11) さようなら(c)。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(12) さようなら| | |------------------------------> | |(13) 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- |(14) 200 OK(c)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 1: Example Message Flow
図1: 例のメッセージ流動
Bormann, et al. Standards Track [Page 15] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[15ページ]RFC5049
The user agent in Figure 1 is initially configured (e.g., using the SIP configuration framework [CONFIG]) with the URI of its outbound proxy. That URI contains the outbound proxy's SIP/SigComp identifier, referred to as 'Outbound-id', in a 'sigcomp-id' parameter.
図1のユーザエージェントは初めは、外国行きのプロキシのURIによって構成されます(例えば、SIP構成フレームワーク[CONFIG]を使用します)。 そのURIは'sigcomp-イド'パラメタに'外国行きのイド'と呼ばれた外国行きのプロキシのSIP/SigComp識別子を含んでいます。
When the user agent sends an initial REGISTER request (1) to the outbound proxy's URI, the user agent opens a new compartment for 'Outbound-id'. This compartment will be valid for the duration of the registration, at least.
ユーザエージェントが初期のREGISTER要求(1)を外国行きのプロキシのURIに送るとき、ユーザエージェントは'外国行きのイド'に新しいコンパートメントを開けます。 このコンパートメントは少なくとも登録の持続時間に有効になるでしょう。
On receiving this REGISTER request (1), the outbound proxy opens a new compartment for the SIP/SigComp identifier that appears in the 'sigcomp-id' parameter of the top-most Via entry. This identifier, which is the user agent's SIP/SigComp identifier, is referred to as 'UA-id'. The compartment opened by the outbound proxy will be valid for the duration of the registration, at least. The outbound proxy adds a Path header field with its own URI, which contains the 'Outbound-id' SIP/SigComp identifier, to the REGISTER request and relays it to the registrar (2).
このREGISTER要求(1)を受け取ると、外国行きのプロキシは最も先端Viaエントリーの'sigcomp-イド'パラメタに現れるSIP/SigComp識別子に新しいコンパートメントを開けます。 この識別子(ユーザエージェントのSIP/SigComp識別子である)は'UA-イド'と呼ばれます。 外国行きのプロキシによって開かれたコンパートメントは少なくとも登録の持続時間に有効になるでしょう。 外国行きのプロキシは、それ自身のURIでPathヘッダーフィールドをREGISTER要求に追加して、記録係(2)にそれをリレーします。(URIは'外国行きのイド'SIP/SigComp識別子を含みます)。
When the registrar receives the REGISTER request (2), it constructs the route future incoming requests (to the user agent) will follow using the Contact and the Path header fields. Future incoming requests will traverse the outbound proxy before reaching the user agent.
記録係がREGISTER要求(2)を受け取るとき、それは、ContactとPathヘッダーフィールドを使用することで今後の入って来る要求(ユーザエージェントへの)が従うルートを構成します。 ユーザエージェントに届く前に、今後の入って来る要求は外国行きのプロキシを横断するでしょう。
The registrar also constructs the route future outgoing requests (from the user agent) will follow and places it in a Service-Route header field in a 200 (OK) response (3). Future outgoing requests will always traverse the outbound proxy. The registrar has ensured that the outbound proxy performing compression handles both incoming and outgoing requests.
記録係は、また、今後の送信する要求(ユーザエージェントからの)が従うルートを構成して、200(OK)応答(3)でService-ルートヘッダーフィールドにそれを置きます。 今後の送信する要求はいつも外国行きのプロキシを横断するでしょう。 記録係は、圧縮を実行している外国行きのプロキシが両方の送受信の要求を扱うのを保証しました。
When the outbound proxy receives a 200 (OK) response (3), it inspects the top-most Via entry. This entry's SIP/SigComp identifier 'UA-id' matches that of the compartment created before. Therefore, the outbound proxy uses that compartment to compress it and relay it to the user agent.
外国行きのプロキシが200(OK)応答(3)を受けるとき、それは最も先端Viaエントリーを点検します。 'UA-イド'というこのエントリーのSIP/SigComp識別子は以前作成されたコンパートメントのものに合っています。 したがって、外国行きのプロキシは、ユーザエージェントにそれを圧縮して、それをリレーするのにそのコンパートメントを使用します。
On receiving the 200 (OK) response (4), the user agent stores the Service-Route header field in order to use it to send future outgoing requests. The Service-Route header field contains the outbound proxy's URI, which contains the 'Outbound-id' SIP/SigComp identifier.
200(OK)応答(4)を受けると、ユーザエージェントは、今後の送信する要求を送るのにそれを使用するためにService-ルートヘッダーフィールドを保存します。 Service-ルートヘッダーフィールドは外国行きのプロキシのURIを含んでいます。(それは、'外国行きのイド'SIP/SigComp識別子を含みます)。
At a later point, the user agent needs to send an INVITE request (5). According to the Service-Route header field received previously, the user agent sends the INVITE request (5) to the outbound proxy's URI.
後のポイントでは、ユーザエージェントは、INVITE要求(5)を送る必要があります。 以前に受け取られたService-ルートヘッダーフィールドによると、ユーザエージェントはINVITE要求(5)を外国行きのプロキシのURIに送ります。
Bormann, et al. Standards Track [Page 16] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[16ページ]RFC5049
Since this URI's SIP/SigComp identifier 'Outbound-id' matches that of the compartment created before, this compartment is used to compress the INVITE request.
'外国行きのイド'というこのURIのSIP/SigComp識別子が以前作成されたコンパートメントのものに合っているので、このコンパートメントはINVITE要求を圧縮するのに使用されます。
On receiving the INVITE request (5), the outbound proxy Record Routes and relays the INVITE request (6) forward. The outbound proxy Record Routes to ensure that all SIP messages related to this new dialog are routed through the outbound proxy.
受信のときに、INVITEは(5)、外国行きのプロキシRecord Routes、およびINVITEが(6) 前方に要求するリレーを要求します。 すべてのSIPメッセージがこの新しい対話に関連したのを保証する外国行きのプロキシRecord Routesは外国行きのプロキシを通して発送されます。
Finally, the dialog is terminated by a BYE transaction (11) that also traverses the outbound proxy.
最終的に、対話はまた、外国行きのプロキシを横断するBYEトランザクション(11)によって終えられます。
15. Security Considerations
15. セキュリティ問題
The same security considerations as described in [RFC3320] apply to this document. Note that keeping SigComp states longer than the duration of a SIP dialog should not pose new security risks because the state has been allowed to be created in the first place.
[RFC3320]で説明されるのと同じセキュリティ問題はこのドキュメントに適用されます。 状態が第一に作成できたのでSIP対話の持続時間が新しいセキュリティ危険を引き起こすべきでないより長い間SigComp州を維持して、それに注意してください。
16. IANA Considerations
16. IANA問題
The IANA has registered the 'sigcomp-id' Via header field parameter, which is defined in Section 9.1, under the Header Field Parameters and Parameter Values subregistry within the SIP Parameters registry:
IANAはセクション9.1で定義される'sigcomp-イド'Viaヘッダーフィールドパラメタを示しました、SIP Parameters登録の中のHeader Field ParametersとParameter Values subregistryの下で:
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Via sigcomp-id No [RFC5049]
事前に定義されたヘッダーフィールドパラメタ名は参照を評価します。---------------------------- --------------- --------- --------- sigcomp-イドノーで[RFC5049]
The IANA has registered the 'sigcomp-id' SIP URI parameter, which is defined in Section 9.1, under the SIP/SIPS URI Parameters subregistry within the SIP Parameters registry:
IANAはセクション9.1で定義される'sigcomp-イド'SIP URIパラメタを示しました、SIP Parameters登録の中のSIP/SIPS URI Parameters subregistryの下で:
Parameter Name Predefined Values Reference -------------- ----------------- --------- sigcomp-id No [RFC5049]
事前に定義されたパラメタ名は参照を評価します。-------------- ----------------- --------- sigcomp-イドノー[RFC5049]
17. Acknowledgements
17. 承認
The authors would like to thank the following people for their comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West, Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, Juergen Schoenwaelder, and Tuukka Karvonen. Abigail Surtees and Adam Roach performed thorough reviews of this document.
作者は彼らのコメントと提案について以下の人々に感謝したがっています: ジャンChristoffersson(ヨルク・オット)は西洋、ペッカPessi、ロバートSugar、ジョナサン・ローゼンバーグ、ロバート・スパークス、ユルゲンSchoenwaelder、およびTuukka Karvonenをマークします。 アビゲール・サーティーズとアダム・ローチはこのドキュメントの徹底的なレビューを実行しました。
Bormann, et al. Standards Track [Page 17] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[17ページ]RFC5049
18. References
18. 参照
18.1. Normative References
18.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]モウツ(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[RFC3261] 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.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer
Two Tunneling Protocol (L2TP) Differentiated Services
Extension", RFC 3308, November 2002.
[RFC3308] カルフーン、P.、羅、W.、マクファーソン、D.、およびK.ピアス、「層Twoのトンネリングプロトコル(L2TP)はサービス拡大を差別化しました」、RFC3308、2002年11月。
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z., and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003.
[RFC3320] 価格、R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、リュウ、Z.、およびJ.ローゼンバーグ、「シグナリング圧縮(SigComp)」、RFC3320(2003年1月)。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002.
[RFC3327]ウィリス、D.とB.Hoeneisen、「非隣接している接触を登録するためのセッション開始プロトコル(一口)拡大ヘッダーフィールド」RFC3327(2002年12月)。
[RFC3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.
Roach, "The Session Initiation Protocol (SIP) and Session
Description Protocol (SDP) Static Dictionary for Signaling
Compression (SigComp)", RFC 3485, February 2003.
[RFC3485]ガルシア-マーチン、M.、ボルマン、C.、オット、J.、価格、R.、およびA.ローチ、「セッション開始プロトコル(一口)とセッション記述はシグナリング圧縮(SigComp)のために(SDP)静的な辞書について議定書の中で述べます」、RFC3485、2003年2月。
[RFC3486] Camarillo, G., "Compressing the Session Initiation
Protocol (SIP)", RFC 3486, February 2003.
[RFC3486] キャマリロ、G.、「セッション開始プロトコル(一口)を圧縮します」、RFC3486、2003年2月。
[RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for
Signaling Compression", RFC 4077, May 2005.
[RFC4077]ローチ(A.、「シグナリング圧縮のための否定的承認メカニズム」、RFC4077)は2005がそうするかもしれません。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFC4122] リーチ、P.、食事、M.、およびR.ザルツ、「一般にユニークな識別子(UUID)つぼの名前空間」、RFC4122、2005年7月。
[RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[RFC4234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
Bormann, et al. Standards Track [Page 18] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[18ページ]RFC5049
[RFC4896] Surtees, A., West, M., and A. Roach, "Signaling
Compression (SigComp) Corrections and Clarifications", RFC
4896, June 2007.
[RFC4896] サーティーズ、A.、西洋、M.、およびA.ローチ、「圧縮(SigComp)修正と明確化に合図します」、RFC4896、2007年6月。
18.2. Informative References
18.2. 有益な参照
[CONFIG] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Work in
Progress, June 2007.
「セッション開始プロトコルユーザエージェントプロフィール配送のためのフレームワーク」という[コンフィグ]のピートリー、D.、およびS.Channabasappaは進行中(2007年6月)で働いています。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
Work in Progress, March 2007.
[外国行き]のジョニングス、C.、およびR.マーイ、「クライアントを管理すると、セッション開始プロトコル(一口)のコネクションズは開始しました」、処理中の作業、2007年3月。
Bormann, et al. Standards Track [Page 19] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[19ページ]RFC5049
Authors' Addresses
作者のアドレス
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany
カルステンボルマンUniversitaetブレーメンTZI Postfach330440ブレーメンD-28334ドイツ
Phone: +49 421 218 63921 Fax: +49 421 218 7000 EMail: cabo@tzi.org
以下に電話をしてください。 +49 421 218、63921Fax: +49 7000年の421 218メール: cabo@tzi.org
Zhigang Liu Nokia Research Center 955 Page Mill Road Palo Alto, CA 94304 USA
ZhigangリュウノキアResearch Center955ページ工場Roadカリフォルニア94304パロアルト(米国)
Phone: +1 650 796 4578 EMail: zhigang.c.liu@nokia.com
以下に電話をしてください。 +1 4578年の650 796メール: zhigang.c.liu@nokia.com
Richard Price EADS Defence and Security Systems Limited Meadows Road Queensway Meadows Newport, Gwent NP19 4SS
リチャード価格イーズディフェンスとセキュリティシステムは道路クウィーンズ・ウェイ・Meadowsニューポート、草地グウェントNP19 4SSを制限しました。
Phone: +44 (0)1633 637874 EMail: richard.price@eads.com
以下に電話をしてください。 +44 (0) 1633 637874はメールされます: richard.price@eads.com
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・キャマリロ(エディタ)エリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Bormann, et al. Standards Track [Page 20] RFC 5049 Applying SigComp to SIP December 2007
ボルマン、他 2007年12月にSigCompを一口に適用する標準化過程[20ページ]RFC5049
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を扱ってください。
Bormann, et al. Standards Track [Page 21]
ボルマン、他 標準化過程[21ページ]
一覧
スポンサーリンク
