RFC3545 日本語訳
3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, PacketLoss and Reordering. T. Koren, S. Casner, J. Geevarghese, B.Thompson, P. Ruddy. July 2003. (Format: TXT=48278 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Koren
Request for Comments: 3545 Cisco Systems
Category: Standards Track S. Casner
Packet Design
J. Geevarghese
Motorola India Electronics Ltd.
B. Thompson
P. Ruddy
Cisco Systems
July 2003
コメントを求めるワーキンググループT.コーレンの要求をネットワークでつないでください: 3545年のシスコシステムズカテゴリ: 血色のよい標準化過程のB.トンプソンP.シスコシステムズS.CasnerパケットデザインJ.Geevargheseモトローラインドエレクトロニクス株式会社2003年7月
Enhanced Compressed RTP (CRTP) for Links with High Delay,
Packet Loss and Reordering
高い遅れ、パケット損失、およびReorderingとのリンクへの高められた圧縮されたRTP(CRTP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays.
ポイントがパケット損失と長時間の遅延とのリンクを指すように、このドキュメントはヘッダー圧縮技術について説明します。 IP/UDP/RTPヘッダー圧縮は、RFC2508でそれがCompressedレアル-時間Transportプロトコル(CRTP)に基づいていると説明しました。 CRTPはそのようなリンクの上によく振る舞いません: 文脈不正と長時間の遅延のためパケット損失結果、文脈が修理される前にずっと多くのパケットが捨てられます。 そのようなリンクの上にCRTPの動きを修正するために、プロトコルへのいくつかの拡大がここで指定されます。 拡大は、コンプレッサーが減圧装置で文脈をアップデートする方法を変えることによって文脈不正を抑えることを目指します: アップデートは、完全で特異な文脈パラメタに繰り返されて、アップデートを含んでいます。 これらの拡大で、CRTPはパケット損失、パケット再命令、および長時間の遅延とのリンクの上によく振る舞います。
Koren, et al. Standards Track [Page 1] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[1ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
Table of Contents
目次
1. Introduction ................................................. 2
1.1. CRTP Operation ......................................... 4
1.2. How do contexts get corrupted? ......................... 4
1.3. Preventing context corruption .......................... 5
1.4. Specification of Requirements .......................... 5
2. Enhanced CRTP ................................................ 5
2.1. Extended COMPRESSED_UDP packet ......................... 6
2.2. CRTP Headers Checksum .................................. 11
2.3. Achieving robust operation ............................. 13
2.3.1. Examples ....................................... 15
3. Negotiating usage of enhanced-CRTP ........................... 18
4. Security Considerations ...................................... 18
5. Acknowledgements ............................................. 19
6. References ................................................... 19
6.1. Normative References ................................... 19
6.2. Informative References ................................. 20
7. Intellectual Property Rights Notice .......................... 20
8. Authors' Addresses ........................................... 21
9. Full Copyright Statement ..................................... 22
1. 序論… 2 1.1. CRTP操作… 4 1.2. 文脈はどのように崩壊しますか? ......................... 4 1.3. 文脈不正を防ぎます… 5 1.4. 要件の仕様… 5 2. CRTPを高めます… 5 2.1. COMPRESSED_UDPパケットを広げています… 6 2.2. CRTPヘッダーチェックサム… 11 2.3. 体力を要している操作を達成します… 13 2.3.1. 例… 15 3. 高められたCRTPの使用法を交渉します… 18 4. セキュリティ問題… 18 5. 承認… 19 6. 参照… 19 6.1. 標準の参照… 19 6.2. 有益な参照… 20 7. 知的所有権に気付きます… 20 8. 作者のアドレス… 21 9. 完全な著作権宣言文… 22
1. Introduction
1. 序論
RTP header compression (CRTP) as described in RFC 2508 was designed to reduce the header overhead of IP/UDP/RTP datagrams by compressing the three headers. The IP/UDP/RTP headers are compressed to 2-4 bytes most of the time.
RFC2508で説明されるRTPヘッダー圧縮(CRTP)は、3個のヘッダーを圧縮することによってIP/UDP/RTPデータグラムのヘッダーオーバーヘッドを下げるように設計されました。 IP/UDP/RTPヘッダーはたいてい2-4バイトに圧縮されます。
CRTP was designed for reliable point to point links with short delays. It does not perform well over links with high rate of packet loss, packet reordering and long delays.
信頼できるポイントが少し遅れとのリンクを指すように、CRTPは設計されました。 それは高い率のパケット損失、パケット再命令、および長時間の遅延とのリンクの上によく振る舞いません。
An example of such a link is a PPP session that is tunneled using an IP level tunneling protocol such as L2TP. Packets within the tunnel are carried by an IP network and hence may get lost and reordered. The longer the tunnel, the longer the round trip time.
そのようなリンクに関する例はL2TPなどのIPの平らなトンネリングプロトコルを使用することでトンネルを堀られるPPPセッションです。 トンネルの中のパケットは、IPネットワークによって運ばれて、失われていて、したがって、再命令されるかもしれません。 トンネルが長ければ長いほど、周遊旅行時間は、より長いです。
Another example is an IP network that uses layer 2 technologies such as ATM and Frame Relay for the access portion of the network. Layer 2 transport networks such as ATM and Frame Relay behave like point to point serial links in that they do not reorder packets. In addition, Frame Relay and ATM virtual circuits used as IP access technologies often have a low bit rate associated with them. These virtual circuits differ from low speed serial links in that they may span a larger physical distance than a point to point serial link. Speed of light delays within the layer 2 transport network will result in higher round trip delays between the endpoints of the circuit. In
別の例はネットワークのアクセス一部にATMやFrame Relayなどの層の2技術を使用するIPネットワークです。 どんな追加注文にもパケットをしないので、ATMやFrame Relayなどの層2の転送ネットワークはポイント・ツー・ポイントのように連続のリンクを振る舞わせます。 さらに、Frame RelayとIPアクセス技術として使用されるATMの仮想のサーキットはしばしばそれらに関連している低ビット伝送速度を持っています。 これらの仮想のサーキットは連続のリンクを指すためにポイントより大きい物理的な距離を測るかもしれないという点において低速シリーズリンクと異なっています。 層2の転送ネットワークの中の光速遅れはサーキットの終点の間の、より高い周遊旅行遅れをもたらすでしょう。 コネ
Koren, et al. Standards Track [Page 2] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[2ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
addition, congestion within the layer 2 transport network may result in an effective drop rate for the virtual circuit which is significantly higher than error rates typically experienced on point to point serial links.
添加、層2の転送ネットワークの中の混雑は誤り率がポイント・ツー・ポイントで連続のリンクに通常なったよりかなり高い仮想のサーキットの有効な低下率をもたらすかもしれません。
It may be desirable to extend existing CRTP implementations for use also over IP tunnels and other virtual circuits, where packet losses, reordering, and long delays are common characteristics. To address these scenarios, this document defines modifications and extensions to CRTP to increase robustness to both packet loss and misordering between the compressor and the decompressor. This is achieved by repeating updates and allowing the sending of absolute (uncompressed) values in addition to delta values for selected context parameters. Although these new mechanisms impose some additional overhead, the overall compression is still substantial. The enhanced CRTP, as defined in this document, is thus suitable for many applications in the scenarios discussed above, e.g., tunneling and other virtual circuits.
パケット損失、再命令、および長時間の遅延が共通する特徴であるIPトンネルと他の仮想のサーキットの上にも使用のための既存のCRTP実現を広げるのは望ましいかもしれません。 これらのシナリオを記述するなら、このドキュメントは、パケット損失とコンプレッサーと減圧装置の間でmisorderingする両方に丈夫さを増加させるように変更と拡大をCRTPと定義します。 これは、アップデートを繰り返して、選択された文脈パラメタのためのデルタ値に加えた絶対(解凍される)の値の発信を許すことによって、達成されます。 これらの新しいメカニズムですが、何らかの追加オーバーヘッドを課してください、そして、総合的な圧縮はまだ実質的です。 その結果、本書では定義される高められたCRTPは上で議論したシナリオにおける多くのアプリケーションに適しています、例えば、トンネルの、そして、他の仮想のサーキット。
RFC 3095 defines another RTP header compression scheme called Robust Header Compression [ROHC]. ROHC was developed with wireless links as the main target, and introduced new compression mechanisms with the primary objective to achieve the combination of robustness against packet loss and maximal compression efficiency. ROHC is expected to be the preferred compression mechanism over links where compression efficiency is important. However, ROHC was designed with the same link assumptions as CRTP, e.g., that the compression scheme should not have to tolerate misordering of compressed packets between the compressor and decompressor, which may occur when packets are carried in an IP tunnel across multiple hops.
RFC3095はRobust Header Compression[ROHC]と呼ばれる別のRTPヘッダー圧縮技術を定義します。 ROHCは、パケット損失と最大限度の圧縮効率に対して丈夫さの組み合わせを達成するために主要目標として無線のリンクで開発されて、主目的で新しい圧縮機構を紹介しました。 ROHCは圧縮効率が重要であるリンクの上の都合のよい圧縮機構であると予想されます。 しかしながら、ROHCは例えば、圧縮技術が、パケットが複数のホップの向こう側にIPトンネルで運ばれるとき現れるかもしれないコンプレッサーと減圧装置の間の圧縮されたパケットをmisorderingするのを許容する必要はないはずであるというCRTPと同じリンク仮定で設計されました。
At some time in the future, enhancements may be defined for ROHC to allow it to perform well in the presence of misordering of compressed packets. The result might be more efficient than the compression protocol specified in this document. However, there are many environments for which the enhanced CRTP defined here may be the preferred choice. In particular, for those environments where CRTP is already implemented, the additional effort required to implement the extensions defined here is expected to be small. There are also cases where the implementation simplicity of this enhanced CRTP relative to ROHC is more important than the performance advantages of ROHC.
いつかこれから先、増進は、圧縮されたパケットをmisorderingすることの面前でROHCがよく振る舞わせるために定義されるかもしれません。 結果は圧縮プロトコルが本書では指定したより効率的であるかもしれません。 しかしながら、ここで定義された高められたCRTPが都合のよい選択であるかもしれない多くの環境があります。 CRTPが既に実行されるそれらの環境において、特に、ここで定義された拡大を実行するのに必要である追加努力が小さいと予想されます。 ケースもROHCに比例したこの高められたCRTPの実現の簡単さがROHCの性能利点より重要であるところにあります。
Koren, et al. Standards Track [Page 3] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[3ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
1.1. CRTP Operation
1.1. CRTP操作
During compression of an RTP stream, a session context is defined. For each context, the session state is established and shared between the compressor and the decompressor. Once the context state is established, compressed packets may be sent.
RTPの流れの圧縮の間、セッション文脈は定義されます。 各文脈に関しては、セッション状態は、コンプレッサーと減圧装置の間で設置されて、共有されます。 いったん文脈状態を設置すると、圧縮されたパケットを送るかもしれません。
The context state consists of the full IP/UDP/RTP headers, a few first order differential values, a link sequence number, a generation number and a delta encoding table.
文脈状態は完全なIP/UDP/RTPヘッダーから成ります、といくつかが最初に、特異な値、リンク一連番号、世代番号、およびテーブルをコード化するデルタを注文します。
The headers part of the context is set by the FULL_HEADER packet that always starts a compression session. The first order differential values (delta values) are set by sending COMPRESSED_RTP packets that include updates to the delta values.
文脈のヘッダー部分はいつも圧縮セッションを始めるFULL_HEADERパケットによって設定されます。 最初のオーダーデフ装置値(デルタ値)は、デルタ値にアップデートを含んでいるパケットをCOMPRESSED_RTPに送ることによって、設定されます。
The context state must be synchronized between compressor and decompressor for successful decompression to take place. If the context gets out of sync, the decompressor is not able to restore the compressed headers accurately. The decompressor invalidates the context and sends a CONTEXT_STATE packet to the compressor indicating that the context has been corrupted. To resume compression, the compressor must re-establish the context.
文脈状態は、うまくいっている減圧が行われるためにコンプレッサーと減圧装置の間で同期しなければなりません。 文脈が同期するようにならないなら、減圧装置は正確に圧縮されたヘッダーを返すことができません。 減圧装置は、文脈が腐敗しているのを示すコンプレッサーに、文脈を無効にして、CONTEXT_州パケットを送ります。 圧縮を再開するために、コンプレッサーは文脈を復職させなければなりません。
During the time the context is corrupted, the decompressor discards all the packets received for that context. Since the context repair mechanism in CRTP involves feedback from the decompressor, context repair takes at least as much time as the round trip time of the link. If the round trip time of the link is long, and especially if the link bandwidth is high, many packets will be discarded before the context is repaired. On such links it is desirable to minimize context invalidation.
文脈が崩壊する時、減圧装置はその文脈のために受け取られたすべてのパケットを捨てます。 CRTPの文脈修理メカニズムが減圧装置からフィードバックにかかわるので、文脈修理は少なくともリンクの周遊旅行時間と同じくらい多くの時間がかかります。 リンクの周遊旅行時間が長く、特にリンク帯域幅が高いなら、文脈が修理される前に多くのパケットが捨てられるでしょう。 そのようなリンクでは、文脈無効にするのを最小にするのは望ましいです。
1.2. How do contexts get corrupted?
1.2. 文脈はどのように崩壊しますか?
As long as the fields in the combined IP/UDP/RTP headers change as expected for the sequence of packets in a session, those headers can be compressed, and the decompressor can fully restore the compressed headers using the context state. When the headers don't change as expected it's necessary to update some of the full or the delta values of the context. For example, the RTP timestamp is expected to increment by delta RTP timestamp (dT). If silence suppression is used, packets are not sent during silence periods. Then when voice activity resumes, packets are sent again, but the RTP timestamp is incremented by a large value and not by dT. In this case an update must be sent.
結合したIP/UDP/RTPヘッダーの分野がセッションにおける、パケットの系列のために予想されるように変化する限り、それらのヘッダーを圧縮できます、そして、減圧装置は文脈状態を使用することで圧縮されたヘッダーを完全に返すことができます。 ヘッダーが予想されるように変化しないとき、それは、完全のいくつかをアップデートするのに必要であって、文脈のデルタ値です。 例えば、RTPタイムスタンプがデルタRTPタイムスタンプで(dT)を増加すると予想されます。 沈黙抑圧が使用されているなら、パケットは沈黙の期間、送られません。 次に、声の活動が再開するとき、再びパケットを送りますが、dTで増加するのではなく、大きい値でRTPタイムスタンプを増加します。 この場合、アップデートを送らなければなりません。
Koren, et al. Standards Track [Page 4] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[4ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
If a packet that includes an update to some context state values is lost, the state at the decompressor is not updated. The shared state is now different at the compressor and decompressor. When the next packet arrives at the decompressor, the decompressor will fail to restore the compressed headers accurately since the context state at the decompressor is different than the state at the compressor.
いくつかの文脈州の値にアップデートを含んでいるパケットが無くなるなら、減圧装置における状態をアップデートしません。 共有された状態は現在、コンプレッサーと減圧装置において異なっています。 次のパケットが減圧装置に到着する場合、減圧装置における文脈状態がコンプレッサーで状態と異なっているので、減圧装置は正確に圧縮されたヘッダーを返さないでしょう。
1.3. Preventing context corruption
1.3. 文脈不正を防ぎます。
Note that the decompressor fails not when a packet is lost, but when the next compressed packet arrives. If the next packet happens to include the same context update as in the lost packet, the context at the decompressor may be updated successfully and decompression may continue uninterrupted. If the lost packet included an update to a delta field such as the delta RTP timestamp (dT), the next packet can't compensate for the loss since the update of a delta value is relative to the previous packet which was lost. But if the update is for an absolute value such as the full RTP timestamp or the RTP payload type, this update can be repeated in the next packet independently of the lost packet. Hence it is useful to be able to update the absolute values of the context.
次の圧縮されたパケットが到着すると減圧装置がパケットが無くなると失敗するのではなく、失敗することに注意してください。 次のパケットが無くなっているパケットのようにたまたま同じ文脈最新版を含んでいるなら、首尾よく減圧装置における文脈をアップデートするかもしれません、そして、減圧は続くかもしれません。とぎれません。 無くなっているパケットがデルタRTPタイムスタンプ(dT)などのデルタ分野にアップデートを含めたなら、デルタ値のアップデートが失われた前のパケットに比例しているので、次のパケットは損失を補うことができません。 しかし、アップデートが完全なRTPタイムスタンプかRTPペイロードタイプなどの絶対値のためのものであるなら、無くなっているパケットの如何にかかわらず次のパケットでこのアップデートを繰り返すことができます。 したがって、文脈の絶対値をアップデートできるのは役に立ちます。
The next chapter describes several extensions to CRTP that add the capability to selectively update absolute values of the context, rather than sending a FULL_HEADER packet, in addition to the existing updates of the delta values. This enhanced version of CRTP is intended to minimize context invalidation and thus improve the performance over lossy links with a long round trip time.
次の章はFULL_HEADERパケットを送るより選択的にむしろ文脈の絶対値をアップデートする能力を加えるCRTPにいくつかの拡大について説明します、デルタ値の既存のアップデートに加えて。 CRTPのこの高められたバージョンは、文脈無効にするのを最小にして、その結果、損失性リンクの上の長い周遊旅行時間がある性能を向上させることを意図します。
1.4. Specification of Requirements
1.4. 要件の仕様
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Enhanced CRTP
2. 高められたCRTP
This chapter specifies the changes in this enhanced version of CRTP. They are:
本章はCRTPのこの高められたバージョンにおける変化を指定します。 それらは以下の通りです。
- Extensions to the COMPRESSED_UDP packet to allow updating the
differential RTP values in the decompressor context and to
selectively update the absolute IPv4 ID and the following RTP
values: sequence number, timestamp, payload type, CSRC count and
CSRC list. This allows context sync to be maintained even with
some packet loss.
- 減圧装置文脈の特異なRTP値をアップデートするのを許容して、選択的に絶対IPv4IDをアップデートするCOMPRESSED_UDPパケットへの拡大と以下のRTP値: 一連番号、タイムスタンプ、ペイロードタイプ、CSRCカウント、およびCSRCは記載します。 これは、文脈の同時性がいくらかのパケット損失があっても維持されるのを許容します。
Koren, et al. Standards Track [Page 5] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[5ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
- A "headers checksum" to be inserted by the compressor and removed
by the decompressor when the UDP checksum is not present so that
validation of the decompressed headers is still possible. This
allows the decompressor to verify that context sync has not been
lost after a packet loss.
- UDPチェックサムであるときに、コンプレッサーによって挿入された、減圧装置によって取り除かれるべき「ヘッダーチェックサム」が存在していないので、減圧されたヘッダーの合法化はまだ可能です。 これで、減圧装置は、文脈の同時性がパケット損失の後に失われていないことを確かめることができます。
An algorithm is then described to use these changes with repeated updates to achieve robust operation over links with packet loss and long delay.
そして、アルゴリズムは、パケット損失と長時間の遅延とのリンクの上に体力を要している操作を達成するのに繰り返されたアップデートがあるこれらの変化を使用するために説明されます。
2.1. Extended COMPRESSED_UDP packet
2.1. 拡張COMPRESSED_UDPパケット
It is possible to accommodate some packet loss between the compressor and decompressor using the "twice" algorithm in RFC 2508 so long as the context remains in sync. In that algorithm, the delta values are added to the previous context twice (or more) to effect the change that would have occurred if the missing packets had arrived. The result is verified with the UDP checksum. Keeping the context in sync requires reliably communicating both the absolute value and the delta value whenever the delta value changes. For many environments, sufficient reliability can be achieved by repeating the update with each of several successive packets.
コンプレッサーと減圧装置の間にいくらかのパケット損失を収容するのは、文脈が同時性に残っている限り、RFC2508の「二度」というアルゴリズムを使用することで可能です。 そのアルゴリズムで、デルタ値は、なくなったパケットが到着したなら起こった変化に作用するように前の文脈に二度(さらに)追加されます。 結果はUDPチェックサムで確かめられます。 同時性における文脈を保つのは、デルタ値が変化するときはいつも、絶対値とデルタ値の両方を確かに伝えるのを必要とします。 多くの環境において、それぞれのいくつかの連続したパケットでアップデートを繰り返すことによって、十分な信頼性を獲得できます。
The COMPRESSED_UDP packet satisfies the need to communicate the absolute values of the differential RTP fields, but it is specified in RFC 2508 to reset the delta RTP timestamp. That limitation can be removed with the following simple change: RFC 2508 describes the format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except that the M, S and T bits are always 0 and the corresponding delta fields are never included. This enhanced version of CRTP changes that specification to say that the T bit MAY be nonzero to indicate that the delta RTP timestamp is included explicitly rather than being reset to zero.
COMPRESSED_UDPパケットは特異なRTP分野の絶対値を伝える需要を満たしますが、それは、デルタRTPタイムスタンプをリセットするためにRFC2508で指定されます。 以下の簡単な変化でその制限を取り除くことができます: RFC2508はいつもM、S、およびTビットが0であり、対応するデルタ分野が決して含まれていないのを除いて、COMPRESSED_RTPと同じであるとしてCOMPRESSED_UDPの書式を記述します。 CRTPのこの高められたバージョンは、TビットがデルタRTPタイムスタンプが明らかにゼロにリセットされるよりむしろ含まれているのを示すためには非零であるかもしれないと言うためにその仕様を変えます。
A second change adds another byte of flag bits to the COMPRESSED_UDP packet to allow only selected individual uncompressed fields of the RTP header to be included in the packet rather than carrying the full RTP header as part of the UDP data. The additional flags do increase computational complexity somewhat, but the corresponding increase in bit efficiency is important when the differential field updates are communicated multiple times in successive COMPRESSED_UDP packets. With this change, there are flag bits to indicate inclusion of both delta values and absolute values, so the flag nomenclature is changed. The original S, T, I bits which indicate the inclusion of deltas are renamed dS, dT, dI, and the inclusion of absolute values is indicated by S, T, I. The M bit is absolute as before. A new
2番目の変化は、許容するCOMPRESSED_UDPパケットへのフラグビットのもう1バイトが、RTPヘッダーの個々の解凍された分野がUDPデータの一部として完全なRTPヘッダーを運ぶよりパケットにむしろ含まれているのを選択しただけであると言い足します。 追加旗は計算量をいくらか増加させますが、特異な分野アップデートが連続したCOMPRESSED_UDPパケットで複数の回伝えられるとき、噛み付いている効率の対応する増加は重要です。 デルタ値と絶対値の両方の包含を示すためにフラグビットがあるので、この変化をもって、旗の用語体系を変えます。 オリジナルS、T、デルタの包含を示すIビットがdSに改名されます、dT、dI、そして、絶対値の包含はSによって示されます、T、I.。Mビットは従来と同様絶対です。 A新しいです。
Koren, et al. Standards Track [Page 6] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[6ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
flag P indicates inclusion of the absolute RTP payload type value and another flag C indicates the inclusion of the CSRC count. When C=1, an additional byte is added following the two flag bytes to include the absolute value of the four-bit CC field in the RTP header.
旗Pは、絶対RTPペイロードタイプ価値と別の旗Cの包含がCSRCカウントの包含を示すのを示します。 C=1であるときに、RTPヘッダーの4ビットのCC分野の絶対値を含む2つのフラグバイトに従って、追加バイトは加えられます。
The last of the three changes to the COMPRESSED_UDP packet deals with updating the IPv4 ID field. For this field, the COMPRESSED_UDP packet as specified in RFC 2508 can already convey a new value for the delta IPv4 ID, but not the absolute value which is only conveyed by the FULL_HEADER packet. Therefore, a new flag I is added to the COMPRESSED_UDP packet to indicate inclusion of the absolute IPv4 ID value. The I flag replaces the dS flag which is not needed in the COMPRESSED_UDP packet since the delta RTP sequence number always remains 1 in the decompressor context and hence does not need to be updated. Note that IPv6 does not have an IP ID field, so when compressing IPv6 packets both the I and the dI flags are always set to 0.
3つのものの最終はIPv4ID分野をアップデートするとのCOMPRESSED_UDPパケット取引に変化します。 この分野に、RFC2508の指定されるとしてのCOMPRESSED_UDPパケットは絶対値ではなく、FULL_HEADERパケットによって運ばれるだけであるIPv4IDデルタのために既に新しい値を伝えることができます。 したがって、新しい旗Iは、絶対IPv4ID価値の包含を示すためにCOMPRESSED_UDPパケットに加えられます。 I旗はデルタRTP一連番号が減圧装置文脈にいつも1のままで残るのでCOMPRESSED_UDPパケットで必要でなく、したがってアップデートする必要はないdS旗を置き換えます。 IPv6パケットを圧縮するとき、IとdI旗の両方がいつも0に設定されるためにIPv6にはIP ID分野がないことに注意してください。
The format of the flags/sequence byte for the original COMPRESSED_UDP packet is shown here for reference:
オリジナルのCOMPRESSED_UDPパケットのための旗/系列バイトの書式は参照のためにここに示されます:
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 |dI | link sequence |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 |ディ| リンク系列| +---+---+---+---+---+---+---+---+
The new definition of the flags/sequence byte plus an extension flags byte for the COMPRESSED_UDP packet is as follows, where the new F flag indicates the inclusion of the extension flags byte:
COMPRESSED_UDPパケットは以下の通りので、旗/系列バイトの新しい定義と拡大はバイトに旗を揚げさせます、新しいF旗が、拡大の包含がバイトに旗を揚げさせるのを示すところで:
+---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: M : S : T : P : C : 0 : 0 : 0 : (if F = 1)
+...+...+...+...+...+...+...+...+
+---+---+---+---+---+---+---+---+ | F| I|dT|ディ| リンク系列| +---+---+---+---+---+---+---+---+ : M: S: T: P: C: 0 : 0 : 0 : (F=1であるなら) +...+...+...+...+...+...+...+...+
dI = delta IPv4 ID dT = delta RTP timestamp I = absolute IPv4 ID F = additional flags byte M = marker bit S = absolute RTP sequence number T = absolute RTP timestamp P = RTP payload type C = CSRC count CID = Context ID
デルタIPv4ID dT=デルタRTP dI=タイムスタンプの絶対IPv4私=ID Fは追加旗のContext CSRCカウントRTPペイロード絶対RTP絶対RTPマーカーバイトM=ビットS=一連番号T=タイムスタンプP=タイプC=CID=IDと等しいです。
Koren, et al. Standards Track [Page 7] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[7ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
When F=0, there is only one flags byte, and the only available flags are: dI, dT and I. In this case the packet includes the full RTP header. As in RFC 2508, if dI=0, the decompressor does not change deltaI. If dT=0, the decompressor sets deltaT to 0.
F=0であるときに、1旗のバイトしかありません、そして、唯一の利用可能な旗は以下の通りです。 dI、dT、およびパケットが含むI.In本件、完全なRTPヘッダー。 RFC2508のように、減圧装置はdI=0であるなら、deltaIを変えません。 dT=0であるなら、減圧装置は0にdeltaTを設定します。
When C=1, an additional byte is added following the two flag bytes. This byte includes the CC, the count of CSRC identifiers, in its lower 4 bits:
C=1であるときに、2つのフラグバイトに従って、追加バイトは加えられます。 このバイトはCC、低級4ビットにおける、CSRC識別子のカウントを含んでいます:
+---+---+---+---+---+---+---+---+
| F | I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: M : S : T : P : C : 0 : 0 : 0 : (if F = 1)
+...+...+...+...+...+...+...+...+
: 0 : 0 : 0 : 0 : CC : (if C = 1)
+...+...+...+...+...............+
+---+---+---+---+---+---+---+---+ | F| I|dT|ディ| リンク系列| +---+---+---+---+---+---+---+---+ : M: S: T: P: C: 0 : 0 : 0 : (F=1であるなら) +...+...+...+...+...+...+...+...+ : 0 : 0 : 0 : 0 : CC: (C=1であるなら) +...+...+...+...+...............+
The bits marked "0" in the second flag byte and the CC byte SHOULD be set to zero by the sender and SHOULD be ignored by the receiver.
「2番目のフラグバイトとCCバイトにおける0インチは、送付者によってゼロに設定されるべきであり、受信機によって無視されるべきです」であるとマークされたビット。
Koren, et al. Standards Track [Page 8] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[8ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
Some example packet formats will illustrate the use of the new flags. First, when F=0, the "traditional" COMPRESSED_UDP packet which carries the full RTP header as part of the UDP data:
いくつかの例のパケット・フォーマットが新しい旗の使用を例証するでしょう。 Fであることの1番目は0、UDPデータの一部として完全なRTPヘッダーを運ぶ「伝統的な」COMPRESSED_UDPパケットと等しいです:
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
|F=0| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if dI = 1)
+...............................+
: delta RTP timestamp : (if dT = 1)
+...............................+
: :
+ IPv4 ID + (if I = 1)
: :
+...............................+
| UDP data |
: (uncompressed RTP header) :
0 1 2 3 4 5 6 7 +...............................+ : セッション文脈IDのmsb: (16ビットのCidであるなら) +-------------------------------+ | セッション文脈IDのlsb| +---+---+---+---+---+---+---+---+ |F=0| I|dT|ディ| リンク系列| +---+---+---+---+---+---+---+---+ : : + UDPチェックサム+(文脈の非零であるなら): : +...............................+ : : + 「無作為」の分野+(要約されるなら): : +...............................+ : デルタIPv4ID: (ディ=1であるなら) +...............................+ : デルタRTPタイムスタンプ: (dT=1であるなら) +...............................+ : : + IPv4ID+(私=1であるなら): : +...............................+ | UDPデータ| : (解凍されたRTPヘッダー) :
When F=1, there is an additional flags byte and the available flags are: dI, dT, I, M, S, T, P, C. If C=1, there is an additional byte that includes the number of CSRC identifiers. When F=1, the packet does not include the full RTP header, but includes selected fields from the RTP header as specified by the flags. As in RFC 2508, if dI=0 the decompressor does not change deltaI. However, in contrast to RFC 2508, if dT=0 the decompressor KEEPS THE CURRENT deltaT in the context (DOES NOT set deltaT to 0).
F=1であるときに、追加旗のバイトがあります、そして、利用可能な旗は以下の通りです。 dI、dT、私、M、S、T、P(C.If C=1)がCSRC識別子の数を含んでいる追加バイトあります。 F=1であるときに、パケットは、完全なRTPヘッダーを含んでいませんが、指定されるとしての旗によるRTPヘッダーからの選択された分野を含んでいます。 RFC2508のように、減圧装置はdI=0であるならdeltaIを変えません。 しかしながら、RFC2508と対照して文脈(0へのDOES NOTの設定deltaT)のdT=0減圧装置KEEPS THE CURRENT deltaTであるなら。
An enhanced COMPRESSED_UDP packet is similar in contents and behavior to a COMPRESSED_RTP packet, but it has more flag bits, some of which correspond to absolute values for RTP header fields.
それには、高められたCOMPRESSED_UDPパケットはCOMPRESSED_RTPパケットへのコンテンツと振舞いにおいて同様ですが、より多くのフラグビットがあります。その或るものはRTPヘッダーフィールドのための絶対値に対応します。
Koren, et al. Standards Track [Page 9] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[9ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
COMPRESSED_UDP with individual RTP fields, when F=1:
F=1であることの個々のRTP分野があるCOMPRESSED_UDP
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
|F=1| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+
| M | S | T | P | C | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
: 0 : 0 : 0 : 0 : CC : (if C = 1)
+...+...+...+...+...............+
: :
+ UDP checksum + (if nonzero in context)
: :
+...............................+
: :
: "RANDOM" fields : (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if dI = 1)
+...............................+
: delta RTP timestamp : (if dT = 1)
+...............................+
: :
+ IPv4 ID + (if I = 1)
: :
+...............................+
: :
+ RTP sequence number + (if S = 1)
: :
+...............................+
: :
+ +
: :
+ RTP timestamp + (if T = 1)
: :
+ +
: :
+...............................+
: RTP payload type : (if P = 1)
+...............................+
: :
: CSRC list : (if CC > 0)
: :
+...............................+
0 1 2 3 4 5 6 7 +...............................+ : セッション文脈IDのmsb: (16ビットのCidであるなら) +-------------------------------+ | セッション文脈IDのlsb| +---+---+---+---+---+---+---+---+ |F=1| I|dT|ディ| リンク系列| +---+---+---+---+---+---+---+---+ | M| S| T| P| C| 0 | 0 | 0 | +---+---+---+---+---+---+---+---+ : 0 : 0 : 0 : 0 : CC: (C=1であるなら) +...+...+...+...+...............+ : : + UDPチェックサム+(文脈の非零であるなら): : +...............................+ : : : "RANDOM"分野: (要約されるなら) : : +...............................+ : デルタIPv4ID: (ディ=1であるなら) +...............................+ : デルタRTPタイムスタンプ: (dT=1であるなら) +...............................+ : : + IPv4ID+(私=1であるなら): : +...............................+ : : + RTP一連番号+(S=1であるなら): : +...............................+ : : + + : : + RTPタイムスタンプ+(T=1であるなら): : + + : : +...............................+ : RTPペイロードタイプ: (P=1であるなら) +...............................+ : : : CSRCは記載します: (CC>0であるなら) : : +...............................+
Koren, et al. Standards Track [Page 10] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
コーレン、他 標準化過程[10ページ]RFC3545は2003年7月に圧縮されたRTP(CRTP)を高めました。
: : : RTP header extension : (if X set in context) : : +-------------------------------+ | | / RTP data / / / | | +-------------------------------+ : padding : (if P set in context) +...............................+
: : : RTPヘッダー拡張子: (Xが状況内においてセットしたなら) : : +-------------------------------+ | | /RTPデータ///| | +-------------------------------+ : 詰め物: (Pが状況内においてセットしたなら) +...............................+
Usage for the enhanced COMPRESSED_UDP packet:
高められたCOMPRESSED_UDPパケットのための用法:
It is useful for the compressor to periodically refresh the state of the decompressor to avoid having the decompressor send CONTEXT_STATE messages in the case of unrecoverable packet loss. Using the flags F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the context parameters.
コンプレッサーが減圧装置に復しないパケット損失の場合でCONTEXT_州にメッセージを送らせるのを避けるために定期的に減圧装置の状態をリフレッシュするのは、役に立ちます。 0とI=1、dI=1、旗F=dT=1を使用して、COMPRESSED_UDPパケットはすべての文脈パラメタをリフレッシュします。
When compression is done over a lossy link with a long round trip delay, we want to minimize context invalidation. If the delta values are changing frequently, the context might get invalidated often. In such cases the compressor MAY choose to always send absolute values and never delta values, using COMPRESSED_UDP packets with the flags F=1, and any of S, T, I as necessary.
長い周遊旅行遅れとの損失性リンクの上に圧縮すると、文脈無効にするのを最小にしたいと思います。 デルタ値が頻繁に変化するなら、文脈はしばしば無効にされるかもしれません。 そのような場合コンプレッサーは、いつも絶対値、決してデルタ値でなく、旗FがあるCOMPRESSED_UDPパケットを使用する=1、およびSのどれか、T、必要に応じて私を送るのを選ぶかもしれません。
2.2. CRTP Headers Checksum
2.2. CRTPヘッダーチェックサム
RFC 2508, in Section 3.3.5, describes how the UDP checksum may be used to validate header reconstruction periodically or when the "twice" algorithm is used. When a UDP checksum is not present (has value zero) in a stream, such validation would not be possible. To cover that case, this enhanced CRTP provides an option whereby the compressor MAY replace the null UDP checksum with a 16-bit headers checksum (HDRCKSUM) which is subsequently removed by the decompressor after validation. Note that this option is never used with IPv6 since a null UDP checksum is not allowed.
RFC 2508, in Section 3.3.5, describes how the UDP checksum may be used to validate header reconstruction periodically or when the "twice" algorithm is used. When a UDP checksum is not present (has value zero) in a stream, such validation would not be possible. To cover that case, this enhanced CRTP provides an option whereby the compressor MAY replace the null UDP checksum with a 16-bit headers checksum (HDRCKSUM) which is subsequently removed by the decompressor after validation. Note that this option is never used with IPv6 since a null UDP checksum is not allowed.
A new flag C in the FULL_HEADER packet, as specified below, indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in that context will have HDRCKSUM inserted. The compressor MAY set the C flag when UDP packet carried in the FULL_HEADER packet originally contained a checksum value of zero. If the C flag is set, the FULL_HEADER packet itself MUST also have the HDRCKSUM inserted. If a packet in the same stream subsequently arrives at the compressor with a UDP checksum present, then a new FULL_HEADER packet MUST be sent with the flag cleared to re-establish the context.
A new flag C in the FULL_HEADER packet, as specified below, indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP packets sent in that context will have HDRCKSUM inserted. The compressor MAY set the C flag when UDP packet carried in the FULL_HEADER packet originally contained a checksum value of zero. If the C flag is set, the FULL_HEADER packet itself MUST also have the HDRCKSUM inserted. If a packet in the same stream subsequently arrives at the compressor with a UDP checksum present, then a new FULL_HEADER packet MUST be sent with the flag cleared to re-establish the context.
Koren, et al. Standards Track [Page 11] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 11] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
The HDRCKSUM is calculated in the same way as a UDP checksum except that it does not cover all of the UDP data. That is, the HDRCKSUM is the 16-bit one's complement of the one's complement sum of the pseudo-IP header (as defined for UDP), the UDP header, the first 12 bytes of the UDP data which are assumed to hold the fixed part of an RTP header, and the CSRC list. The extended part of the RTP header beyond the CSRC list and the RTP data will not be included in the HDRCKSUM. The HDRCKSUM is placed in the COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would have been. The decompressor MUST zero out the UDP checksum field in the reconstructed packets.
The HDRCKSUM is calculated in the same way as a UDP checksum except that it does not cover all of the UDP data. That is, the HDRCKSUM is the 16-bit one's complement of the one's complement sum of the pseudo-IP header (as defined for UDP), the UDP header, the first 12 bytes of the UDP data which are assumed to hold the fixed part of an RTP header, and the CSRC list. The extended part of the RTP header beyond the CSRC list and the RTP data will not be included in the HDRCKSUM. The HDRCKSUM is placed in the COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would have been. The decompressor MUST zero out the UDP checksum field in the reconstructed packets.
For a non-RTP context, there may be fewer than 12 UDP data bytes present. The IP and UDP headers can still be compressed into a COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated over the pseudo-IP header, the UDP header, and the UDP data bytes that are present. If the number of data bytes is odd, then a zero padding byte is appended for the purpose of calculating the checksum, but not transmitted.
For a non-RTP context, there may be fewer than 12 UDP data bytes present. The IP and UDP headers can still be compressed into a COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated over the pseudo-IP header, the UDP header, and the UDP data bytes that are present. If the number of data bytes is odd, then a zero padding byte is appended for the purpose of calculating the checksum, but not transmitted.
The HDRCKSUM does not validate the RTP data. If the link layer is configured to deliver packets without checking for errors, then errors in the RTP data will not be detected. Over such links, the compressor SHOULD add the HDRCKSUM if a UDP checksum is not present, and the decompressor SHOULD validate each reconstructed packet to make sure that at least the headers are correct. This ensures that the packet will be delivered to the right destination. If only HDRCKSUM is available, the RTP data will be delivered even if it includes errors. This might be a desirable feature for applications that can tolerate errors in the RTP data. The same holds for the extended part of the RTP header beyond the CSRC list.
The HDRCKSUM does not validate the RTP data. If the link layer is configured to deliver packets without checking for errors, then errors in the RTP data will not be detected. Over such links, the compressor SHOULD add the HDRCKSUM if a UDP checksum is not present, and the decompressor SHOULD validate each reconstructed packet to make sure that at least the headers are correct. This ensures that the packet will be delivered to the right destination. If only HDRCKSUM is available, the RTP data will be delivered even if it includes errors. This might be a desirable feature for applications that can tolerate errors in the RTP data. The same holds for the extended part of the RTP header beyond the CSRC list.
Here is the format of the FULL_HEADER length fields with the new flag C to indicate that a header checksum will be added in COMPRESSED_UDP and COMPRESSED_RTP packets:
Here is the format of the FULL_HEADER length fields with the new flag C to indicate that a header checksum will be added in COMPRESSED_UDP and COMPRESSED_RTP packets:
For 8-bit context ID:
For 8-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Generation| CID | First length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Generation| CID | First length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |C| seq | Second length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |C| seq | Second length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
Koren, et al. Standards Track [Page 12] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 12] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
For 16-bit context ID:
For 16-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Generation| 0 |C| seq | First length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Generation| 0 |C| seq | First length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID | Second length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID | Second length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3. Achieving robust operation
2.3. Achieving robust operation
Enhanced CRTP achieves robust operation by sending changes multiple times to keep the compressor and decompressor in sync. This method is characterized by a number "N" that represents the quality of the link between the hosts. What it means is that the probability of more than N adjacent packets getting lost on this link is small. For every change in a full value or a delta value, if the compressor includes the change in N+1 consecutive packets, then the decompressor can keep its context state in sync with the compressor using the "twice" algorithm so long as no more than N adjacent packets are lost.
Enhanced CRTP achieves robust operation by sending changes multiple times to keep the compressor and decompressor in sync. This method is characterized by a number "N" that represents the quality of the link between the hosts. What it means is that the probability of more than N adjacent packets getting lost on this link is small. For every change in a full value or a delta value, if the compressor includes the change in N+1 consecutive packets, then the decompressor can keep its context state in sync with the compressor using the "twice" algorithm so long as no more than N adjacent packets are lost.
Since updates are repeated in N+1 packets, if at least one of these N+1 update packets is received by the decompressor, both the full and delta values in the context at the decompressor will get updated and its context will stay synchronized with the context at the compressor. We can conclude that as long as less than N+1 adjacent packets are lost, the context at the decompressor is guaranteed to be synchronized with the context at the compressor, and use of the "twice" algorithm to recover from packet loss will successfully update the context and restore the compressed packets.
Since updates are repeated in N+1 packets, if at least one of these N+1 update packets is received by the decompressor, both the full and delta values in the context at the decompressor will get updated and its context will stay synchronized with the context at the compressor. We can conclude that as long as less than N+1 adjacent packets are lost, the context at the decompressor is guaranteed to be synchronized with the context at the compressor, and use of the "twice" algorithm to recover from packet loss will successfully update the context and restore the compressed packets.
The link sequence number cycles in 16 packets, so it's not always clear how many packets were lost. For example, if the previous link sequence number was 5 and the current number is 4, one possibility is that 15 packets were lost, but another possibility is that due to misordering packet 5 arrived before packet 4 and they are really adjacent. If there is an interpretation of the link sequence numbers that could be a gap of less than N+1, the "twice" algorithm may be applied that many times and verified with the UDP checksum (or the HDRCKSUM).
The link sequence number cycles in 16 packets, so it's not always clear how many packets were lost. For example, if the previous link sequence number was 5 and the current number is 4, one possibility is that 15 packets were lost, but another possibility is that due to misordering packet 5 arrived before packet 4 and they are really adjacent. If there is an interpretation of the link sequence numbers that could be a gap of less than N+1, the "twice" algorithm may be applied that many times and verified with the UDP checksum (or the HDRCKSUM).
When more than N packets are lost, all of the repetitions of an update might have been lost. The context state may then be different at the compressor and decompressor. The decompressor can still try to recover by making one or more guesses for how many packets were lost and then applying the "twice" algorithm that many times.
When more than N packets are lost, all of the repetitions of an update might have been lost. The context state may then be different at the compressor and decompressor. The decompressor can still try to recover by making one or more guesses for how many packets were lost and then applying the "twice" algorithm that many times.
Koren, et al. Standards Track [Page 13] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 13] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
However, since the IPv4 ID field is not included in the checksum, this does not validate the IPv4 ID.
However, since the IPv4 ID field is not included in the checksum, this does not validate the IPv4 ID.
The conclusion is that for IPv4 if more than N packets were lost, the decompressor SHOULD NOT try to recover using the "twice" algorithm and instead SHOULD invalidate the context and send a CONTEXT_STATE packet. In IPv6 the decompressor MAY always try to recover from packet loss by using the "twice" algorithm and verifying the result with the UDP checksum.
The conclusion is that for IPv4 if more than N packets were lost, the decompressor SHOULD NOT try to recover using the "twice" algorithm and instead SHOULD invalidate the context and send a CONTEXT_STATE packet. In IPv6 the decompressor MAY always try to recover from packet loss by using the "twice" algorithm and verifying the result with the UDP checksum.
It is up to the implementation to derive an appropriate N for a link. The value is maintained independently for each context and is not required to be the same for all contexts. When compressing a new stream, the compressor sets a value of N for that context and sends N+1 FULL_HEADER packets. The compressor MUST also repeat each subsequent COMPRESSED_UDP update N+1 times. The value of N may be changed for an existing context by sending a new sequence of FULL_HEADER packets.
It is up to the implementation to derive an appropriate N for a link. The value is maintained independently for each context and is not required to be the same for all contexts. When compressing a new stream, the compressor sets a value of N for that context and sends N+1 FULL_HEADER packets. The compressor MUST also repeat each subsequent COMPRESSED_UDP update N+1 times. The value of N may be changed for an existing context by sending a new sequence of FULL_HEADER packets.
The decompressor learns the value of N by counting the number of times the FULL_HEADER packet is repeated and storing the resulting value in the corresponding context. If some of the FULL_HEADER packets are lost, the decompressor may still be able to determine the correct value of N by observing the change in the 4-bit sequence number carried in the FULL_HEADER packets. Any inaccuracy in the counting will lead the decompressor to assume a smaller value of N than the compressor is sending. This is safe in that the only negative consequence is that the decompressor might send a CONTEXT_STATE packet when it was not really necessary to do so. In response, the compressor will send FULL_HEADER packets again, providing another opportunity for the decompressor to count the correct N.
The decompressor learns the value of N by counting the number of times the FULL_HEADER packet is repeated and storing the resulting value in the corresponding context. If some of the FULL_HEADER packets are lost, the decompressor may still be able to determine the correct value of N by observing the change in the 4-bit sequence number carried in the FULL_HEADER packets. Any inaccuracy in the counting will lead the decompressor to assume a smaller value of N than the compressor is sending. This is safe in that the only negative consequence is that the decompressor might send a CONTEXT_STATE packet when it was not really necessary to do so. In response, the compressor will send FULL_HEADER packets again, providing another opportunity for the decompressor to count the correct N.
The sending of FULL_HEADER packets is also triggered by a change in one of the fields held constant in the context, such as the IP TOS. If such a change should occur while the compressor is in the middle of sending the N+1 FULL_HEADER packets, then the compressor MUST send N+1 FULL_HEADER packets after making the change. This could cause the decompressor to receive more than N+1 FULL_HEADER packets in a row with the result that it assumes a larger value for N than is correct. That could lead to an undetected loss of context synchronization. Therefore, the compressor MUST change the "generation" number in the context and in the FULL_HEADER packet when it begins sending the sequence of N+1 FULL_HEADER packets so the decompressor can detect the new sequence. For IPv4, this is a change in behavior relative to RFC 2508.
The sending of FULL_HEADER packets is also triggered by a change in one of the fields held constant in the context, such as the IP TOS. If such a change should occur while the compressor is in the middle of sending the N+1 FULL_HEADER packets, then the compressor MUST send N+1 FULL_HEADER packets after making the change. This could cause the decompressor to receive more than N+1 FULL_HEADER packets in a row with the result that it assumes a larger value for N than is correct. That could lead to an undetected loss of context synchronization. Therefore, the compressor MUST change the "generation" number in the context and in the FULL_HEADER packet when it begins sending the sequence of N+1 FULL_HEADER packets so the decompressor can detect the new sequence. For IPv4, this is a change in behavior relative to RFC 2508.
Koren, et al. Standards Track [Page 14] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 14] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the same sequence number for each context) to provide a similar measure of robustness against packet loss. Here N can be the largest N of all contexts included in the CONTEXT_STATE packet, or any number the decompressor finds necessary in order to ensure robustness.
CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the same sequence number for each context) to provide a similar measure of robustness against packet loss. Here N can be the largest N of all contexts included in the CONTEXT_STATE packet, or any number the decompressor finds necessary in order to ensure robustness.
2.3.1. Examples
2.3.1. Examples
Here are some examples to demonstrate the robust operation of enhanced CRTP using N+1 repetitions of updates. In this stream the audio codec sends a sample every 10 milliseconds. The first talkspurt is 1 second long. Then there are 2 seconds of silence, then another talkspurt. We also assume in this first example that the IPv4 ID field does not increment at a constant rate because the host is generating other uncorrelated traffic streams at the same time and therefore the delta IPv4 ID changes for each packet.
Here are some examples to demonstrate the robust operation of enhanced CRTP using N+1 repetitions of updates. In this stream the audio codec sends a sample every 10 milliseconds. The first talkspurt is 1 second long. Then there are 2 seconds of silence, then another talkspurt. We also assume in this first example that the IPv4 ID field does not increment at a constant rate because the host is generating other uncorrelated traffic streams at the same time and therefore the delta IPv4 ID changes for each packet.
In these examples, we will use some short notations:
In these examples, we will use some short notations:
FH FULL_HEADER
CR COMPRESSED_RTP
CU COMPRESSED_UDP
FH FULL_HEADER CR COMPRESSED_RTP CU COMPRESSED_UDP
When operating on a link with low loss, we can just use COMPRESSED_RTP packets in the basic CRTP method specified in RFC 2508. We might have the following packet sequence:
When operating on a link with low loss, we can just use COMPRESSED_RTP packets in the basic CRTP method specified in RFC 2508. We might have the following packet sequence:
seq Time pkt updates and comments
# type
1 10 FH
2 20 CR dI dT=10
3 30 CR dI
4 40 CR dI
...
100 1000 CR dI
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dI dT=10 3 30 CR dI 4 40 CR dI ... 100 1000 CR dI
101 3010 CR dI dT=2010
102 3020 CR dI dT=10
103 3030 CR dI
104 3040 CR dI
...
101 3010 CR dI dT=2010 102 3020 CR dI dT=10 103 3030 CR dI 104 3040 CR dI ...
In the above sequence, if a packet is lost we cannot recover ("twice"
will not work due to the unpredictable IPv4 ID) and the context must
be invalidated.
In the above sequence, if a packet is lost we cannot recover ("twice" will not work due to the unpredictable IPv4 ID) and the context must be invalidated.
Koren, et al. Standards Track [Page 15] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 15] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Here is the same example using the enhanced CRTP method specified in this document, when N=2. Note that the compressor only sends the absolute IPv4 ID (I) and not the delta IPv4 ID (dI).
Here is the same example using the enhanced CRTP method specified in this document, when N=2. Note that the compressor only sends the absolute IPv4 ID (I) and not the delta IPv4 ID (dI).
seq Time pkt CU flags updates and comments
# type F I dT dI M S T P
1 10 FH
2 20 FH repeat constant fields
3 30 FH repeat constant fields
4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10
5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT
6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT
7 70 CU 1 1 0 0 M 0 0 0 I
8 80 CU 1 1 0 0 M 0 0 0 I
...
100 1000 CU 1 1 0 0 M 0 0 0 I
seq Time pkt CU flags updates and comments # type F I dT dI M S T P 1 10 FH 2 20 FH repeat constant fields 3 30 FH repeat constant fields 4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10 5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT 6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT 7 70 CU 1 1 0 0 M 0 0 0 I 8 80 CU 1 1 0 0 M 0 0 0 I ... 100 1000 CU 1 1 0 0 M 0 0 0 I
101 3010 CU 1 1 0 0 M 0 1 0 I T=3010 T changed, keep deltas
102 3020 CU 1 1 0 0 M 0 1 0 I T=3020 repeat updated T
103 3030 CU 1 1 0 0 M 0 1 0 I T=3030 repeat updated T
104 3040 CU 1 1 0 0 M 0 0 0 I
105 3050 CU 1 1 0 0 M 0 0 0 I
...
101 3010 CU 1 1 0 0 M 0 1 0 I T=3010 T changed, keep deltas 102 3020 CU 1 1 0 0 M 0 1 0 I T=3020 repeat updated T 103 3030 CU 1 1 0 0 M 0 1 0 I T=3030 repeat updated T 104 3040 CU 1 1 0 0 M 0 0 0 I 105 3050 CU 1 1 0 0 M 0 0 0 I ...
This second example is the same sequence, but assuming the delta IP ID is constant. First the basic CRTP for a lossless link:
This second example is the same sequence, but assuming the delta IP ID is constant. First the basic CRTP for a lossless link:
seq Time pkt updates and comments
# type
1 10 FH
2 20 CR dI dT=10
3 30 CR
4 40 CR
...
100 1000 CR
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dI dT=10 3 30 CR 4 40 CR ... 100 1000 CR
101 3010 CR dT=2010
102 3020 CR dT=10
103 3030 CR
104 3040 CR
...
101 3010 CR dT=2010 102 3020 CR dT=10 103 3030 CR 104 3040 CR ...
Koren, et al. Standards Track [Page 16] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 16] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
For the equivalent sequence in enhanced CRTP, the more efficient COMPRESSED_RTP packet can still be used once the deltas are all established:
For the equivalent sequence in enhanced CRTP, the more efficient COMPRESSED_RTP packet can still be used once the deltas are all established:
seq Time pkt CU flags updates and comments
# type F I dT dI M S T P
1 10 FH
2 20 FH repeat constant fields
3 30 FH repeat constant fields
4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10
5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates
6 60 CU 1 1 1 1 M 0 1 0 I dI T=60 dT=10 repeat updates
7 70 CR
8 80 CR
...
100 1000 CR
seq Time pkt CU flags updates and comments # type F I dT dI M S T P 1 10 FH 2 20 FH repeat constant fields 3 30 FH repeat constant fields 4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10 5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates 6 60 CU 1 1 1 1 M 0 1 0 I dI T=60 dT=10 repeat updates 7 70 CR 8 80 CR ... 100 1000 CR
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas
102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T
103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T
104 3040 CR
105 3050 CR
...
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 104 3040 CR 105 3050 CR ...
Here is the second example when using IPv6. First the basic CRTP for a lossless link:
Here is the second example when using IPv6. First the basic CRTP for a lossless link:
seq Time pkt updates and comments
# type
1 10 FH
2 20 CR dT=10
3 30 CR
4 40 CR
...
100 1000 CR
seq Time pkt updates and comments # type 1 10 FH 2 20 CR dT=10 3 30 CR 4 40 CR ... 100 1000 CR
101 3010 CR dT=2010
102 3020 CR dT=10
103 3030 CR
104 3040 CR
...
101 3010 CR dT=2010 102 3020 CR dT=10 103 3030 CR 104 3040 CR ...
Koren, et al. Standards Track [Page 17] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 17] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
For the equivalent sequence in enhanced CRTP, the more efficient COMPRESSED_RTP packet can still be used once the deltas are all established:
For the equivalent sequence in enhanced CRTP, the more efficient COMPRESSED_RTP packet can still be used once the deltas are all established:
seq Time pkt CU flags updates and comments
# type F I dT dI M S T P
1 10 FH
2 20 FH repeat constant fields
3 30 FH repeat constant fields
4 40 CU 1 0 1 0 M 0 1 0 T=40 dT=10
5 50 CU 1 0 1 0 M 0 1 0 T=50 dT=10 repeat updates
6 60 CU 1 0 1 0 M 0 1 0 T=60 dT=10 repeat updates
7 70 CR
8 80 CR
...
100 1000 CR
seq Time pkt CU flags updates and comments # type F I dT dI M S T P 1 10 FH 2 20 FH repeat constant fields 3 30 FH repeat constant fields 4 40 CU 1 0 1 0 M 0 1 0 T=40 dT=10 5 50 CU 1 0 1 0 M 0 1 0 T=50 dT=10 repeat updates 6 60 CU 1 0 1 0 M 0 1 0 T=60 dT=10 repeat updates 7 70 CR 8 80 CR ... 100 1000 CR
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas
102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T
103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T
104 3040 CR
105 3050 CR
...
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 104 3040 CR 105 3050 CR ...
3. Negotiating usage of enhanced-CRTP
3. Negotiating usage of enhanced-CRTP
The use of IP/UDP/RTP compression (CRTP) over a particular link is a function of the link-layer protocol. It is expected that negotiation of the use of CRTP will be defined separately for each link layer.
The use of IP/UDP/RTP compression (CRTP) over a particular link is a function of the link-layer protocol. It is expected that negotiation of the use of CRTP will be defined separately for each link layer.
For link layers that already have defined a negotiation for the use of CRTP as specified in RFC 2508, an extension to that negotiation will be required to indicate use of the enhanced CRTP defined in this document since the syntax of the existing packet formats has been extended.
For link layers that already have defined a negotiation for the use of CRTP as specified in RFC 2508, an extension to that negotiation will be required to indicate use of the enhanced CRTP defined in this document since the syntax of the existing packet formats has been extended.
4. Security Considerations
4. Security Considerations
Because encryption eliminates the redundancy that this compression scheme tries to exploit, there is some inducement to forego encryption in order to achieve operation over a low-bandwidth link. However, for those cases where encryption of data and not headers is satisfactory, RTP does specify an alternative encryption method in which only the RTP payload is encrypted and the headers are left in the clear [SRTP]. That would allow compression to still be applied.
Because encryption eliminates the redundancy that this compression scheme tries to exploit, there is some inducement to forego encryption in order to achieve operation over a low-bandwidth link. However, for those cases where encryption of data and not headers is satisfactory, RTP does specify an alternative encryption method in which only the RTP payload is encrypted and the headers are left in the clear [SRTP]. That would allow compression to still be applied.
Koren, et al. Standards Track [Page 18] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 18] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
A malfunctioning or malicious compressor could cause the decompressor to reconstitute packets that do not match the original packets but still have valid IP, UDP and RTP headers and possibly even valid UDP check-sums. Such corruption may be detected with end-to-end authentication and integrity mechanisms which will not be affected by the compression. Constant portions of authentication headers will be compressed as described in [IPHCOMP].
A malfunctioning or malicious compressor could cause the decompressor to reconstitute packets that do not match the original packets but still have valid IP, UDP and RTP headers and possibly even valid UDP check-sums. Such corruption may be detected with end-to-end authentication and integrity mechanisms which will not be affected by the compression. Constant portions of authentication headers will be compressed as described in [IPHCOMP].
No authentication is performed on the CONTEXT_STATE control packet sent by this protocol. An attacker with access to the link between the decompressor and compressor could inject false CONTEXT_STATE packets and cause compression efficiency to be reduced, probably resulting in congestion on the link. However, an attacker with access to the link could also disrupt the traffic in many other ways.
No authentication is performed on the CONTEXT_STATE control packet sent by this protocol. An attacker with access to the link between the decompressor and compressor could inject false CONTEXT_STATE packets and cause compression efficiency to be reduced, probably resulting in congestion on the link. However, an attacker with access to the link could also disrupt the traffic in many other ways.
A potential denial-of-service threat exists when using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decompress and cause the receiver to be overloaded and degrading processing of other streams. However, this compression does not exhibit any significant non-uniformity.
A potential denial-of-service threat exists when using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decompress and cause the receiver to be overloaded and degrading processing of other streams. However, this compression does not exhibit any significant non-uniformity.
5. Acknowledgements
5. Acknowledgements
The authors would like to thank Van Jacobson, co-author of RFC 2508, and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and Stephen Pink. The authors would also like to thank Dana Blair, Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, Andrew Johnson, and Dan Wing.
The authors would like to thank Van Jacobson, co-author of RFC 2508, and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and Stephen Pink. The authors would also like to thank Dana Blair, Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, Mallik Tatipamula, Mike Thomas, Alex Tweedly, Herb Wildfeuer, Andrew Johnson, and Dan Wing.
6. References
6. References
6.1. Normative References
6.1. Normative References
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[IPHCOMP] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[IPHCOMP] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[IPCPHC] Koren, T., Casner, S. and C. Bormann, "IP Header
Compression over PPP", RFC 3544, July 2003.
[IPCPHC] Koren, T., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 3544, July 2003.
[KEYW] Bradner, S. "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYW] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Koren, et al. Standards Track [Page 19] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 19] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
6.2. Informative References
6.2. Informative References
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
T., Yoshimura, T. and H. Zheng, "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed", RFC 3095, July 2001.
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[SRTP] Baugher, M., McGrew, D., Carrara, E., Naslund, M. and K.
Norrman, "The Secure Real-time Transport Protocol", Work in
Progress.
[SRTP] Baugher, M., McGrew, D., Carrara, E., Naslund, M. and K. Norrman, "The Secure Real-time Transport Protocol", Work in Progress.
7. Intellectual Property Rights Notice
7. Intellectual Property Rights Notice
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Koren, et al. Standards Track [Page 20] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 20] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
8. Authors' Addresses
8. Authors' Addresses
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
EMail: tmima@cisco.com
EMail: tmima@cisco.com
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 USA
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 USA
EMail: casner@acm.org
EMail: casner@acm.org
John Geevarghese Motorola India Electronics Ltd. No. 33 A Ulsoor Road Bangalore, India
John Geevarghese Motorola India Electronics Ltd. No. 33 A Ulsoor Road Bangalore, India
EMail: geevjohn@hotmail.com
EMail: geevjohn@hotmail.com
Bruce Thompson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Bruce Thompson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
EMail: brucet@cisco.com
EMail: brucet@cisco.com
Patrick Ruddy Cisco Systems, Inc. 3rd Floor 96 Commercial Street Leith, Edinburgh EH6 6LX Scotland
Patrick Ruddy Cisco Systems, Inc. 3rd Floor 96 Commercial Street Leith, Edinburgh EH6 6LX Scotland
EMail: pruddy@cisco.com
EMail: pruddy@cisco.com
Koren, et al. Standards Track [Page 21] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
Koren, et al. Standards Track [Page 21] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003
9. Full Copyright Statement
9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Koren, et al. Standards Track [Page 22]
Koren, et al. Standards Track [Page 22]
一覧
スポンサーリンク
