Network Working Group A. van Wijk, Ed.
Request for Comments: 5194 G. Gybels, Ed.
Category: Informational June 2008
Framework for Real-Time Text over IP Using
the Session Initiation Protocol (SIP)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks.
この文書では、リアルタイムのテキスト・オーバーIP（TOIP）のために不可欠な要件を示していますし、セッション開始プロトコル（SIP）とリアルタイムトランスポートプロトコル（RTP）に基づいて、すべての必要な機能を実装するためのフレームワークを定義します。これは、公共上のテキスト・オーバーIPおよび既存のテキスト電話は電話網（PSTN）と他のネットワークを交換間のインターワーキングを含んでいます。
Table of Contents
目次
1. Introduction ....................................................3
2. Scope ...........................................................4
3. Terminology .....................................................4
4. Definitions .....................................................4
5. Requirements ....................................................6
5.1. General Requirements for ToIP ..............................6
5.2. Detailed Requirements for ToIP .............................8
5.2.1. Session Setup and Control Requirements ..............9
5.2.2. Transport Requirements .............................10
5.2.3. Transcoding Service Requirements ...................10
5.2.4. Presentation and User Control Requirements .........11
5.2.5. Interworking Requirements ..........................13
5.2.5.1. PSTN Interworking Requirements ............13
5.2.5.2. Cellular Interworking Requirements ........14
5.2.5.3. Instant Messaging Interworking
Requirements ..............................14
6. Implementation Framework .......................................15
6.1. General Implementation Framework ..........................15
6.2. Detailed Implementation Framework .........................15
6.2.1. Session Control and Setup ..........................15
6.2.1.1. Pre-Session Setup .........................15
6.2.1.2. Session Negotiations ......................16
6.2.2. Transport ..........................................17
6.2.3. Transcoding Services ...............................18
6.2.4. Presentation and User Control Functions ............18
6.2.4.1. Progress and Status Information ...........18
6.2.4.2. Alerting ..................................18
6.2.4.3. Text Presentation .........................19
6.2.4.4. File Storage ..............................19
6.2.5. Interworking Functions .............................19
6.2.5.1. PSTN Interworking .........................20
6.2.5.2. Mobile Interworking .......................22
6.2.5.2.1. Cellular "No-gain" .............22
6.2.5.2.2. Cellular Text Telephone
Modem (CTM) ....................22
6.2.5.2.3. Cellular "Baudot mode" .........22
6.2.5.2.4. Mobile Data Channel Mode .......23
6.2.5.2.5. Mobile ToIP ....................23
6.2.5.3. Instant Messaging Interworking ............23
6.2.5.4. Multi-Functional Combination Gateways .....24
6.2.5.5. Character Set Transcoding .................25
7. Further Recommendations for Implementers and Service
Providers ......................................................25
7.1. Access to Emergency Services ..............................25
7.2. Home Gateways or Analog Terminal Adapters .................25
7.3. User Mobility .............................................26
7.4. Firewalls and NATs ........................................26
7.5. Quality of Service ........................................26
8. Security Considerations ........................................26
9. Contributors ...................................................27
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................29
For many years, real-time text has been in use as a medium for conversational, interactive dialogue between users in a similar way to how voice telephony is used. Such interactive text is different from messaging and semi-interactive solutions like Instant Messaging in that it offers an equivalent conversational experience to users who cannot, or do not wish to, use voice. It therefore meets a different set of requirements from other text-based solutions already available on IP networks.
長年にわたり、リアルタイムのテキストは、音声電話が使用されている方法と同じように、ユーザー間の会話、対話的な対話のための媒体として使用されています。このような対話型のテキストは、それは誰がすることはできません、または、音声を使用したくないユーザーに同等な会話体験を提供することで、インスタントメッセージングなどのメッセージングおよび半インタラクティブソリューションとは異なります。したがって、IPネットワーク上ですでに利用可能な他のテキストベースのソリューションからの要件の異なるセットを満たしています。
Traditionally, deaf, hard-of-hearing, and speech-impaired people are amongst the most prolific users of real-time, conversational, text but, because of its interactivity, it is becoming popular amongst mainstream users as well. Real-time text conversation can be combined with other conversational media like video or voice.
伝統的に、聴覚障害者、難聴の、音声障害者は、リアルタイムの最も多作のユーザーの間で会話、テキストですが、そのための対話のために、それは同様に、主流のユーザーの間で人気が高まっています。リアルタイムのテキストの会話は、映像や音声などの他の会話のメディアと組み合わせることができます。
This document describes how existing IETF protocols can be used to implement a Text-over-IP solution (ToIP). Therefore, this document describes how to use a set of existing components and protocols and provides the requirements and rules for that resulting structure, which is why it is called a "framework", fitting commonly accepted dictionary definitions of that term.
この文書では、既存のIETFプロトコルは、テキスト・オーバーIPソリューション（TOIP）を実装するために使用する方法について説明します。したがって、この文書は、既存のコンポーネント及びプロトコルのセットを使用する方法について説明し、それがその用語の一般に認められた辞書の定義を当てはめ、「フレームワーク」と呼ばれる理由である、その結果として得られる構造の要件とルールを提供します。
This ToIP framework is specifically designed to be compatible with Voice-over-IP (VoIP), Video-over-IP, and Multimedia-over-IP (MoIP) environments. This ToIP framework also builds upon, and is compatible with, the high-level user requirements of deaf, hard-of-hearing and speech-impaired users as described in RFC3351 [22]. It also meets real-time text requirements of mainstream users.
このTOIPフレームワークは、特にボイスオーバーIP（VoIP）の、ビデオオーバーIPと互換性を持つように設計されており、マルチメディアオーバーIP（のMoIP）環境れています。 RFC3351 [22]に記載されているように、このTOIPフレームワークは、ハード・オブ・聴覚と音声障害者、上に構築し、聴覚障害者の高レベルのユーザ要件と互換性があります。また、主流のユーザーのリアルタイムのテキストの要件を満たしています。
ToIP also offers an IP equivalent of analog text telephony services as used by deaf, hard-of-hearing, speech-impaired, and mainstream users.
聴覚障害者、難聴の、音声障害、およびメインストリームのユーザーによって使用されるようTOIPは、アナログのテキスト電話サービスのIP相当を提供しています。
The Session Initiation Protocol (SIP) [2] is the protocol of choice for control of Multimedia communications and Voice-over-IP (VoIP) in particular. It offers all the necessary control and signalling required for the ToIP framework.
セッション開始プロトコル（SIP）[2]マルチメディア通信、特にボイスオーバーIP（VoIP）の制御のための選択のプロトコルです。これは、TOIPフレームワークに必要なすべての必要な制御およびシグナリングを提供しています。
The Real-Time Transport Protocol (RTP) [3] is the protocol of choice for real-time data transmission, and its use for real-time text payloads is described in RFC 4103 [4].
リアルタイムトランスポートプロトコル（RTP）[3]リアルタイムデータ伝送のための選択のプロトコルであり、リアルタイムのテキストペイロードのためのその使用は、RFC 4103に記載されている[4]。
This document defines a framework for ToIP to be used either by itself or as part of integrated, multi-media services, including Total Conversation [5].
この文書では、全会話[5]を含む、単独で、または統合された、マルチメディアサービスの一部として使用するTOIPのためのフレームワークを定義します。
This document defines a framework for the implementation of real-time ToIP, either stand-alone or as a part of multimedia services, including Total Conversation [5]. It provides the:
この文書では、いずれかのスタンドアローン又は総会話[5]を含むマルチメディアサービスの一部として、リアルタイムTOIPの実装のためのフレームワークを定義します。それは提供しています。
a. requirements for real-time text;
A。リアルタイムのテキストのための要件。
b. requirements for ToIP interworking;
B。 TOIPのインターワーキングのための要件。
c. description of ToIP implementation using SIP and RTP;
C。 SIPおよびRTPを使用して、TOIP実装の説明。
d. description of ToIP interworking with other text services.
D。他のテキストサービスとTOIPインターワーキングの説明。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6] and indicate requirement levels for compliant implementations.
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「本書ではRFC 2119に記載されるように解釈されるべきである[6]および対応する実装の要求レベルを示します。
Audio bridging: a function of an audio media bridge server, gateway, or relay service that sends to each destination the combination of audio from all participants in a conference, excluding the participant(s) at that destination. At the RTP level, this is an instance of the mixer function as defined in RFC 3550 [3].
オーディオブリッジング：オーディオメディアブリッジサーバの機能、ゲートウェイ、またはその先の参加者（複数可）を除く、会議のすべての参加者から各宛先へのオーディオの組み合わせを送信した中継サービス。 RTPレベルでは、これは、RFC 3550で定義されているミキサ関数のインスタンスである[3]。
Cellular: a telecommunication network that has wireless access and can support voice and data services over very large geographical areas. Also called Mobile.
携帯電話：ワイヤレスアクセスを持っており、非常に大規模な地理的領域上で音声およびデータサービスをサポートすることができ、通信ネットワーク。また、モバイルと呼ばれます。
Full duplex: media is sent independently in both directions.
全二重：メディアは両方向に独立して送信されます。
Half duplex: media can only be sent in one direction at a time, or if an attempt to send information in both directions is made, errors may be introduced into the presented media.
半二重：メディアは、一度に1つの方向に送信することができ、または両方の方向に情報を送信しようとする試みがなされた場合、エラーが提示されたメディアに導入することができます。
Interactive text: another term for real-time text, as defined below.
対話型テキスト：リアルタイムのテキストのための別の用語、以下に定義します。
Real-time text: a term for real-time transmission of text in a character-by-character fashion for use in conversational services, often as a text equivalent to voice-based conversational services. Conversational text is defined in the ITU-T Framework for multimedia services, Recommendation F.700 [21].
リアルタイムテキスト：会話型サービスで使用する文字単位でのファッションのテキストのリアルタイム伝送のための用語、多くの場合、テキスト相当するとして、音声ベースの会話型サービス。会話テキストは、マルチメディアサービスのためのITU-Tフレームワークに勧告F.700 [21]に定義されています。
Text gateway: a function that transcodes between different forms of text transport methods, e.g., between ToIP in IP networks and Baudot or ITU-T V.21 text telephony in the PSTN.
テキストゲートウェイ：テキスト転送方式の異なる形態間でトランスコード機能、例えば、IPネットワークでTOIPとPSTNにボドーまたはITU-T V.21テキスト電話の間です。
Textphone: also "text telephone". A terminal device that allows end-to-end real-time text communication using analog transmission. A variety of PSTN textphone protocols exists world-wide. A textphone can often be combined with a voice telephone, or include voice communication functions for simultaneous or alternating use of text and voice in a call.
Textphone：また、「テキスト電話」。アナログ伝送を使用して、エンドツーエンドのリアルタイムテキスト通信を可能とする端末装置。 PSTNのtextphoneのさまざまなプロトコルは、世界的な存在します。 textphoneは、多くの場合、音声電話と組み合わせて、またはコールのテキストと音声の同時または交互の使用のために音声通信機能を含むことができます。
Text bridging: a function of the text media bridge server, gateway (including transcoding gateways), or relay service analogous to that of audio bridging as defined above, except that text is the medium of conversation.
テキストブリッジング：テキスト・メディア・ブリッジ・サーバの機能は、（トランスコーディングゲートウェイを含む）ゲートウェイ、またはオーディオブリッジと同様のリレーサービスは、そのテキストが会話の媒体である以外は、上記のように定義されます。
Text relay service: a third-party or intermediary that enables communications between deaf, hard-of-hearing, and speech-impaired people and voice telephone users by translating between voice and real-time text in a call.
ハード・オブ・聴覚、音声障害者と音声電話ユーザーが通話中の音声およびリアルタイムのテキストの間で変換することによって、聴覚障害者との間の通信を可能にするサードパーティや仲介：テキストリレーサービス。
Text telephony: analog textphone service.
テキスト電話：アナログtextphoneサービス。
Total Conversation: a multimedia service offering real-time conversation in video, real-time text and voice according to interoperable standards. All media streams flow in real time. (See ITU-T F.703, "Multimedia conversational services" [5].)
合計会話：相互運用可能な標準によると、ビデオ、リアルタイムのテキストや音声でリアルタイムの会話を提供するマルチメディアサービス。すべてのメディアストリームをリアルタイムに流れます。 （[5] ITU-T F.703、 "マルチメディア会話サービス" を参照。）
Transcoding service: a service provided by a third-party User Agent that transcodes one stream into another. Transcoding can be done by human operators, in an automated manner, or by a combination of both methods. Within this document, the term particularly applies to conversion between different types of media. A text relay service is an example of a transcoding service that converts between real-time text and audio.
トランスコーディングサービス：別に一つのストリームをトランスコードし、サードパーティのユーザーエージェントによって提供されるサービス。トランスコーディングは、自動化された方法で、または両方の方法の組み合わせにより、人間のオペレータによって行うことができます。この文書の中では、この用語は、特に、異なるタイプのメディア間の変換に適用されます。テキストリレーサービスは、リアルタイムのテキストと音声との間の変換、トランスコーディングサービスの一例です。
TTY: originally, an abbreviation for "teletype". Often used in North America as an alternative designation for a text telephone or textphone. Also called TDD, Telecommunication Device for the Deaf.
TTY：もともと、「テレタイプ」の略称。多くの場合、テキスト電話やtextphoneための代替名称として、北米で使用されます。またTDD、聴覚障害者のための通信装置と呼ばれます。
Video relay service: a service that enables communications between deaf and hard-of-hearing people and hearing persons with voice telephones by translating between sign language and spoken language in a call.
ビデオリレーサービス：聴覚障害者や難聴の人と通話中に手話と音声言語の間で変換することによって、音声電話を持つ人を聞い間の通信を可能にするサービス。
Acronyms:
略語：
2G Second generation cellular (mobile) 2.5G Enhanced second generation cellular (mobile) 3G Third generation cellular (mobile) ATA Analog Telephone Adaptor CDMA Code Division Multiple Access CLI Calling Line Identification CTM Cellular Text Telephone Modem ENUM E.164 number storage in DNS (see RFC3761) GSM Global System for Mobile Communications ISDN Integrated Services Digital Network ITU-T International Telecommunications Union-Telecommunications Standardisation Sector NAT Network Address Translation PSTN Public Switched Telephone Network RTP Real-Time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure Real Time Transport Protocol TDD Telecommunication Device for the Deaf TDMA Time Division Multiple Access TTY Analog textphone (Teletypewriter) ToIP Real-time Text over Internet Protocol URI Uniform Resource Identifier UTF-8 UCS/Unicode Transformation Format-8 VCO/HCO Voice Carry Over/Hearing Carry Over VoIP Voice over Internet Protocol
2G第二世代携帯電話（モバイル）2.5Gの強化第二世代携帯（モバイル）3G第三世代携帯電話（モバイル）DNSにおけるラインの識別CTMセルラーテキスト電話モデムENUM E.164番号記憶を呼び出すATAアナログ電話アダプタCDMA符号分割多元接続のCLI（ ）RFC3761を参照してくださいGSMグローバルシステムモバイルコミュニケーションズISDN統合サービスデジタル網ITU-T国際電気通信連合・電気通信標準化部門NATネットワーク用のアドレス変換PSTN公衆交換電話網RTPリアルタイムトランスポートプロトコルSDPセッション記述プロトコルSIPセッション開始プロトコルSRTPセキュアリアルタイム交換しましたインターネットプロトコルURIユニフォームリソース識別子UTF-8 UCS /ユニコード変換フォーマット-8 VCO / HCO声がキャリーオーバー/聴覚を超えるろうTDMA時分割多重アクセスTTYアナログtextphone（テレックス）TOIPリアルタイムテキストのための時間トランスポートプロトコルTDD通信装置インターネット・プロトコル上のVoIP音声キャリーオーバー
The framework described in Section 6 defines a real-time text-based conversational service that is the text equivalent of voice-based telephony. This section describes the requirements that the framework is designed to meet and the functionality it should offer.
セクション6に記載のフレームワークは、音声ベースのテレフォニーのテキスト等価物であるリアルタイムのテキストベースの対話サービスを定義します。このセクションでは、フレームワークを満たすように設計されて要件とそれが提供すべき機能について説明します。
Any framework for ToIP must be derived from the requirements of RFC 3351 [22]. A basic requirement is that it must provide a standardized way for offering real-time text-based conversational services that can be used as an equivalent to voice telephony by deaf, hard-of-hearing, speech-impaired, and mainstream users.
TOIPのための任意のフレームワークは、RFC 3351 [22]の要件に由来しなければなりません。基本的な要件は、それが難聴の聴覚障害者、発話障害、およびメインストリームのユーザーが電話を音声に相当するものとして使用することができ、リアルタイムのテキストベースの会話のサービスを提供するための標準的な方法を提供しなければならないということです。
It is important to understand that real-time text conversations are significantly different from other text-based communications like email or Instant Messaging. Real-time text conversations deliver an equivalent mode to voice conversations by providing transmission of text character by character as it is entered, so that the conversation can be followed closely and that immediate interaction takes place.
リアルタイムのテキストの会話は、電子メールやインスタントメッセージングなどの他のテキストベースの通信とは大きく異なっていることを理解することが重要です。リアルタイムのテキストの会話は、会話が密接に続き、即時相互作用が起こることができるように、それは、入力されたように、文字によるテキスト文字の伝送を提供することで、会話を音声に同等のモードを提供します。
Store-and-forward systems like email or messaging on mobile networks, or non-streaming systems like instant messaging, are unable to provide that functionality. In particular, they do not allow for smooth communication through a Text Relay Service.
モバイルネットワーク、またはインスタントメッセージングなどの非ストリーミングシステム上の電子メールやメッセージングなどのストアアンドフォワードシステムは、その機能を提供することはできません。特に、それらは、テキストリレーサービスを通じて円滑なコミュニケーションを可能にするものではありません。
In order to make ToIP the text equivalent of voice services, ToIP needs to offer equivalent features in terms of conversationality to those provided by voice. To achieve that, ToIP needs to:
TOIP音声サービスのテキストと同等にするために、TOIPは、音声によって提供されたものにconversationalityの面で同等の機能を提供する必要があります。それを達成するために、TOIPをする必要があります。
a. offer real-time transport and presentation of the conversation;
A。会話のリアルタイムの輸送とプレゼンテーションを提供します。
b. provide simultaneous transmission in both directions;
B。両方向の同時送信を提供すること。
c. support both point-to-point and multipoint communication;
C。両方のポイントツーポイントおよびマルチポイント通信をサポートします。
d. allow other media, like audio and video, to be used in conjunction with ToIP;
D。可能にする他のメディアは、オーディオとビデオのように、TOIPと組み合わせて使用します。
e. ensure that the real-time text service is always available.
電子。リアルタイムのテキストサービスが常に利用可能であることを確認してください。
Real-time text is a useful subset of Total Conversation as defined in ITU-T F.703 [5]. Total Conversation allows participants to use multiple modes of communication during the conversation, either at the same time or by switching between modes, e.g., between real-time text and audio.
ITU-T F.703 [5]で定義されるように、リアルタイムのテキストは、全会話の有用なサブセットです。総会話参加者が同時にまたはリアルタイムのテキストとオーディオとの間、例えば、モードの切り替えのいずれかにより、会話の間の通信の複数のモードを使用することを可能にします。
Deaf, hard-of-hearing, and mainstream users may invoke ToIP services for many different reasons:
難聴の聴覚障害者、および主流のユーザーが、さまざまな理由でTOIPサービスを呼び出すことができます。
- because they are in a noisy environment, e.g., in a machine room of a factory where listening is difficult;
- 彼らは、ノイズの多い環境では、例えば、リスニングが困難である工場の機械室にあるからです。
- because they are busy with another call and want to participate in two calls at the same time;
- 彼らは別のコールでビジーで、同時に2つのコールに参加したいので。
- for implementing text and/or speech recording services (e.g., text documentation/audio recording) for legal purposes, for clarity, or for flexibility;
- 法的な目的のために、明確にするため、または柔軟性のためのテキストおよび/または音声録音サービス（例えば、テキストドキュメント/音声記録）を実現するために、
- to overcome language barriers through speech translation and/or transcoding services;
- 音声翻訳および/またはトランスコーディングサービスを通じて、言語の壁を克服するため、
- because of hearing loss, deafness, or tinnitus as a result of the aging process or for any other reason, creating a need to replace or complement voice with real-time text in conversational sessions.
- なぜなら、老化プロセスの結果として、あるいはその他の理由損失、難聴、耳鳴りや聴力を交換したり、会話セッションでリアルタイムのテキストと音声を補完する必要性を作成します。
In many of the above examples, real-time text may accompany speech. The text could be displayed side by side, or in a manner similar to subtitling in broadcasting environments, or in any other suitable manner. This could occur with users who are hard of hearing and also for mixed media calls with both hearing and deaf people participating in the call.
上記の例の多くでは、リアルタイムのテキストは、音声を伴うことがあります。テキストを並べて表示することができる、又は類似の方法で放送環境で字幕する、または任意の他の適切な方法です。これは、難聴ともコールに参加両方聞くと耳が聞こえない人とのメディアミックスコールにあるユーザーと発生する可能性があります。
A ToIP user may wish to call another ToIP user, join a conference session involving several users, or initiate or join a multimedia session, such as a Total Conversation session.
TOIPのユーザーは、このようなトータル会話セッションとして、別のTOIPのユーザーを呼び出す複数のユーザーを含む会議セッションに参加する、または開始したり、マルチメディアセッションに参加することを望むかもしれません。
A common scenario for multipoint real-time text is conference calling with many participants. Implementers could, for example, use different colours to render different participants' text, or could create separate windows or rendering areas for each participant.
多リアルタイムのテキストのための一般的なシナリオは、多くの参加者との会議通話です。実装者は、例えば、異なる参加者のテキストをレンダリングするために異なる色を使用することができ、または各参加者のために別のウィンドウまたはレンダリング領域を作成することができます。
The following sections list individual requirements for ToIP. Each requirement has been given a unique identifier (R1, R2, etc.). Section 6 (Implementation Framework) describes how to implement ToIP based on these requirements by using existing protocols and techniques.
次のセクションでは、TOIPのための個々の要件をリストアップ。各要求は、一意の識別子（R1、R2、等）を与えられています。第6節（実装フレームワーク）は、既存のプロトコルおよび技術を使用して、これらの要件に基づいてTOIPを実装する方法について説明します。
The requirements are organized under the following headings:
要件は、次の項目で構成されています。
- session setup and session control;
- セッションの設定とセッション制御。
- transport;
- 輸送;
- use of transcoding services;
- トランスコーディングサービスを使用します。
- presentation and user control;
- プレゼンテーションとユーザーコントロール。
- interworking.
- インターワーキング。
Conversations could be started using a mode other than real-time text. Simultaneous or alternating voice and real-time text is used by a large number of people who can send voice but must receive text (due to a hearing impairment), or who can hear but must send text (due to a speech impairment).
会話はリアルタイムのテキスト以外のモードを使用して開始することができます。同時または交互音声およびリアルタイムのテキストは、音声を送信することができますが（による聴覚障害への）テキスト、または誰が聞くことができますが（言語障害のために）テキストを送信する必要がありますを受けなければならない多数の人々によって使用されます。
R1: It SHOULD be possible to start conversations in any mode (real-time text, voice, video) or combination of modes.
R1：どのモード（リアルタイムのテキスト、音声、ビデオ）またはモードの組み合わせで会話を始めることが可能であるべきです。
R2: It MUST be possible for the users to switch to real-time text, or add real-time text as an additional modality, during the conversation.
R2：ユーザーがリアルタイムのテキストに切り替えるか、会話中に、追加のモダリティとしてリアルタイムのテキストを追加することが可能でなければなりません。
R3: Systems supporting ToIP MUST allow users to select any of the supported conversation modes at any time, including in mid-conversation.
R3：TOIPをサポートするシステムでは、ユーザーが半ば会話に含め、いつでもサポート会話モードのいずれかを選択することができるようにしなければなりません。
R4: Systems SHOULD allow the user to specify a preferred mode of communication in each direction, with the ability to fall back to alternatives that the user has indicated are acceptable.
R4は：システムは、ユーザが許容可能で示された代替にフォールバックする能力を、各方向の通信の好ましいモードを指定できるようにする必要があります。
R5: If the user requests simultaneous use of real-time text and audio, and this is not possible because of constraints in the network, the system SHOULD try to establish text-only communication if that is what the user has specified as his/her preference.
R5：ユーザーはリアルタイムのテキストと音声の同時使用を要求し、これが原因でネットワーク内の制約のために不可能である場合、そのユーザーが彼/彼女のように指定したものである場合、システムは、テキストのみの通信を確立しようとする必要があります好み。
R6: If the user has expressed a preference for real-time text, establishment of a connection including real-time text MUST have priority over other outcomes of the session setup.
R6：ユーザーはリアルタイムのテキストのための好みを表明している場合は、リアルタイムのテキストを含むコネクションの確立は、セッションセットアップの他の成果の上に優先権を持っていなければなりません。
R7: It MUST be possible to use real-time text in conferences both as a medium of discussion between individual participants (for example, for sidebar discussions in real-time text while listening to the main conference audio) and for central support of the conference with real-time text interpretation of speech.
R7：個々の参加者の間で議論の媒体として（例えば、メイン会議の音声を聞きながらリアルタイムテキストでサイドバーの議論のために）、会議の中心的支援のために、両方の会議では、リアルタイムのテキストを使用することが可能でなければなりません音声のリアルタイムテキスト解釈と。
R8: Session setup and negotiation of modalities MUST allow users to specify the language of the real-time text to be used. (It is RECOMMENDED that similar functionality be provided for the video part of the conversation, i.e., to specify the sign language being used).
R8：モダリティのセッションセットアップとネゴシエーションは、ユーザーが使用するリアルタイムテキストの言語を指定することができなければなりません。 （使用されている手話を指定するために、すなわち、同様の機能は、会話のビデオ部分のために提供されることが推奨されます）。
R9: Where certain session services are available for the audio media part of a session, these functions MUST also be supported for the real-time text media part of the same session. For example, call transfer must act on all media in the session.
R9：特定のセッションサービスがセッションのオーディオメディアパートで使用可能な、これらの機能は、同じセッションのリアルタイムテキストメディアの一部のためにサポートしなければなりません。例えば、コール転送は、セッション内のすべてのメディアに基づいて行動しなければなりません。
ToIP will often be used to access a relay service [24], allowing real-time text users to communicate with voice users. With relay services, as well as in direct user-to-user conversation, it is crucial that text characters are sent as soon as possible after they are entered. While buffering may be done to improve efficiency, the delays SHOULD be kept minimal. In particular, buffering of whole lines of text will not meet character delay requirements.
TOIPは、多くの場合、リアルタイムのテキスト、ユーザーが音声ユーザーと通信できるように、リレーサービス[24]をアクセスするために使用されます。リレーサービスでは、だけでなく、ユーザ対ユーザの直接の会話の中で、彼らが入力された後にテキスト文字はできるだけ早く送信されることが重要です。バッファリングは、効率を改善するために行うことができますが、遅延が最小限に保たれるべきです。具体的には、テキストの行全体のバッファリングは、キャラクタ遅延要件を満たしていません。
R10: Characters must be transmitted soon after entry of each character so that the maximum delay requirement can be met. An end-to-end delay time of one second is regarded as good, while users note and appreciate shorter delays, down to 300ms. A delay of up to two seconds is possible to use.
R10：最大遅延要件を満たすことができるように、文字は、各文字の入力後すぐに送信されなければなりません。ユーザーがダウン300msのに、短い遅延に注意し、感謝しながら、1秒のエンドツーエンドの遅延時間は、良いと考えています。最大2つの秒の遅延が使用することが可能です。
R11: Real-time text transmission from a terminal SHALL be performed character by character as entered, or in small groups of characters, so that no character is delayed from entry to transmission by more than 300 milliseconds.
R11：入力されたとして、何の文字が300ミリ秒以上でエントリーからの送信に遅れないように、端末からリアルタイムのテキスト送信は、文字ずつ行われるものとする（SHALL）、または文字の小グループで。
R12: It MUST be possible to transmit characters at a rate sufficient to support fast human typing as well as speech-to-text methods of generating real-time text. A rate of 30 characters per second is regarded as sufficient.
R12：速い人タイピングだけでなく、リアルタイムのテキストを生成する音声テキストのメソッドをサポートするのに十分な速度で文字を伝送することが可能でなければなりません。毎秒30文字の速度が十分であるとみなされます。
R13: A ToIP service MUST be able to deal with international character sets.
R13：TOIPサービスは、国際文字セットに対処できなければなりません。
R14: Where it is possible, loss or corruption of real-time text during transport SHOULD be detected and the user should be informed.
R14：それは可能であるが、輸送中のリアルタイムテキストの消失や破損を検出する必要があり、ユーザーに通知しなければなりません。
R15: Transport of real-time text SHOULD be as robust as possible, so as to minimize loss of characters.
R15：文字の損失を最小にするように、リアルタイムのテキストの輸送は、可能な限り堅牢であるべきです。
R16: It SHOULD be possible to send and receive real-time text simultaneously.
R16：同時にリアルタイムでテキストを送受信することが可能なはずです。
If the User Agents of different participants indicate that there is an incompatibility between their capabilities to support certain media types, e.g., one User Agent only offering T.140 over IP, as described in RFC 4103 [4], and the other one only supporting audio, the user might want to invoke a transcoding service.
別の参加者のユーザエージェントは、特定のメディアタイプをサポートするために、それらの機能間の非互換性があることを示している場合は、RFC 4103で説明したように例えば、1ユーザエージェントは、[4]、IP上でT.140を提供し、そして他の一つはのみサポートオーディオ、ユーザーは、トランスコーディングサービスを起動することがあります。
Some users may indicate their preferred modality to be audio while others may indicate real-time text. In this case, transcoding services might be needed for text-to-speech (TTS) and speech-to-text (STT). Other examples of possible scenarios for including a relay service in the conversation are: text bridging after conversion from speech, audio bridging after conversion from real-time text, etc.
他の人がリアルタイムのテキストを示している可能性がありながら、一部のユーザーがオーディオであることを好みのモダリティを示すことがあります。この場合、トランスコーディングサービスは、音声に変換テキスト（TTS）と音声テキスト（STT）のために必要になることがあります。会話の中でリレーサービスを含むための可能なシナリオの他の例は以下のとおりです。など、リアルタイムのテキストから、変換後の音声、オーディオブリッジからの変換後のテキストブリッジ
A number of requirements, motivations, and implementation guidelines for relay service invocation can be found in RFC 3351 [22].
要件、動機、及び中継サービス呼び出しの実装ガイドラインの数は、RFC 3351 [22]に見出すことができます。
R17: It MUST be possible for users to invoke a transcoding service where such service is available.
R17：ユーザーは、このようなサービスが利用可能なトランスコーディングサービスを起動することが可能でなければなりません。
R18: It MUST be possible for users to indicate their preferred modality (e.g., ToIP).
R18：ユーザーが好ましいモダリティ（例えば、TOIP）を指示することが可能でなければなりません。
R19: It MUST be possible to negotiate the requirements for transcoding services in real time in the process of setting up a call.
R19：呼を設定する過程でリアルタイムにトランスコーディングサービスのための要件を交渉することは可能でなければなりません。
R20: It MUST be possible to negotiate the requirements for transcoding services in mid-call, for the immediate addition of those services to the call.
R20：呼び出しにこれらのサービスの即時追加のために、通話中にトランスコーディングサービスのための要件を交渉することは可能でなければなりません。
R21: Communication between the end participants SHOULD continue after the addition or removal of a text relay service, and the effect of the change should be limited in the users' perception to the direct effect of having or not having the transcoding service in the connection.
R21：最後の参加者との間の通信は、テキストリレーサービスの追加または削除後も継続すべきである、と変化の影響があるか、接続にトランスコーディングサービスを持っていないの直接的な影響に、ユーザーの感覚に限定されるべきです。
R22: When setting up a session, it MUST be possible for a user to specify the type of relay service requested (e.g., speech to text or text to speech). The specification of a type of relay SHOULD include a language specifier.
R22は：セッションを設定する場合、ユーザが要求した中継サービス（例えば、音声がテキストまたはテキスト音声にする）の種類を指定することが可能でなければなりません。リレーの種類の指定は言語指定子を含むべきです。
R23: It SHOULD be possible to route the session to a preferred relay service even if the user invokes the session from another region or network than that usually used.
R23：これは、ユーザーが通常使用されるもの以外の領域またはネットワークからセッションを起動しても好適リレーサービスにルーティングセッションをすることができるはずです。
R24: It is RECOMMENDED that ToIP implementations make the invocation and use of relay services as easy as possible.
R24：それはTOIPの実装は、できるだけ簡単に起動し、リレーサービスを利用することが推奨されます。
A user should never be in doubt about the status of the session, even if the user is unable to make use of the audio or visual indication. For example, tactile indications could be used by deaf-blind individuals.
ユーザは、音声や視覚的な表示を利用することができない場合でも、セッションの状態について疑問になることはありません。例えば、触覚表示は聴覚障害者、盲個人によって使用することができます。
R25: User Agents for ToIP services MUST have alerting methods (e.g., for incoming sessions) that can be used by deaf and hard-of-hearing people or provide a range of alternative, but equivalent, alerting methods that can be selected by all users, regardless of their abilities.
R25：TOIPサービスのためのユーザエージェントは（着信セッション用など、）メソッドを警告していなければなら聴覚障害者や難聴の人々によって使用されるか、または代替が、同等の範囲を提供することができ、すべてのユーザーが選択することができる方法を警告関係なく、自分の能力の。
R26: Where real-time text is used in conjunction with other media, exposure of user control functions through the User Interface needs to be done in an equivalent manner for all supported media. For example, it must be possible for the user to select between audio, visual, or tactile prompts, or all must be supplied.
R26：リアルタイムのテキストは、他のメディアと組み合わせて使用される場合、ユーザインターフェースを介してユーザ制御機能の露出がサポートされているすべてのメディアのための同等の方法で行われる必要があります。例えば、ユーザーは、オーディオ・ビジュアル、または触覚のプロンプトの間で選択することが可能でなければならない、またはすべてが供給されなければなりません。
R27: If available, identification of the originating party (e.g., in the form of a URI or a Calling Line Identification (CLI)) MUST be clearly presented to the user in a form suitable for the user BEFORE the session invitation is answered.
R27は：セッション招待が回答される前に、可能な場合は、発信側の識別（例えば、URIまたは回線コーリング識別（CLI）の形で）明確にユーザーに適した形式でユーザに提示しなければなりません。
R28: When a session invitation involving ToIP originates from a Public Switched Telephone Network (PSTN) text telephone (e.g., transcoded via a text gateway), this SHOULD be indicated to the user. The ToIP client MAY adjust the presentation of the real-time text to the user as a consequence.
R28は：TOIPを含むセッション招待電話網（PSTN）テキスト電話公衆交換由来する場合（例えば、テキスト・ゲートウェイを介してトランスコードされた）、このことはユーザに示されるべきです。 TOIPクライアントは、結果としてユーザーにリアルタイムのテキストの表示を調整することができます。
R29: An indication SHOULD be given to the user when real-time text is available during the call, even if it is not invoked at call setup (e.g., when only voice and/or video is used initially).
R29：リアルタイムのテキストは、それがコールセットアップ（例えば、音声のみ、および/またはビデオを最初に使用した場合）で呼び出されていない場合でも、通話中に利用可能になったときの表示は、ユーザーに与えられるべきです。
R30: The user MUST be informed of any change in modalities.
R30：ユーザーは、モダリティの変化を通知する必要があります。
R31: Users MUST be presented with appropriate session progress information at all times.
R31：ユーザーは、すべての回で適切なセッションの進行状況の情報を提供しなければなりません。
R32: Systems for ToIP SHOULD support an answering machine function, equivalent to answering machines on telephony networks.
R32：TOIPのためのシステムは、テレフォニーネットワーク上のマシンに答えると同等の留守番電話機能をサポートすべきです。
R33: If an answering machine function is supported, it MUST support at least 160 characters for the greeting message. It MUST support incoming text message storage of a minimum of 4096 characters, although systems MAY support much larger storage. It is RECOMMENDED that systems support storage of at least 20 incoming messages of up to 16000 characters per message.
R33は：留守番電話機能がサポートされている場合は、グリーティングメッセージのために少なくとも160個の文字をサポートしなければなりません。システムは、はるかに大きなストレージをサポートするかもしれないがそれは、4096文字以上の、着信テキストメッセージの保存をサポートしなければなりません。システムがメッセージあたり最大16000文字の少なくとも20の受信メッセージの格納をサポートすることが推奨されます。
R34: When the answering machine is activated, user alerting SHOULD still take place. The user SHOULD be allowed to monitor the auto-answer progress, and where this is provided, the user SHOULD be allowed to intervene during any stage of the answering machine procedure and take control of the session.
R34：留守番電話が作動すると、ユーザーの警告はまだ行われるべきです。ユーザは、自動応答の進行をモニターするために許可する必要があり、これが設けられている場合、ユーザは、留守番手順の任意の段階で介入し、セッションの制御を取ることを許容されるべきです。
R35: It SHOULD be possible to save the text portion of a conversation.
R35：会話のテキスト部分を保存することが可能です。
R36: The presentation of the conversation SHOULD be done in such a way that users can easily identify which party generated any given portion of text.
R36：会話のプレゼンテーションは、ユーザーが簡単にテキストの任意の部分を生成したパーティーを識別できるような方法で行われるべきです。
R37: ToIP SHOULD handle characters such as new line, erasure, and alerting during a session as specified in ITU-T T.140 [8].
R37：ITU-T T.140 [8]で指定されるようTOIPは、セッション中にそのような新しいライン、消去、および警告などの文字を処理します。
There is a range of existing real-time text services. There is also a range of network technologies that could support real-time text services.
既存のリアルタイムテキストサービスの範囲があります。リアルタイムのテキストサービスをサポートできるネットワーク技術の範囲もあります。
Real-time/interactive texting facilities exist already in various forms and on various networks. In the PSTN, they are commonly referred to as text telephony.
リアルタイム/インタラクティブテキストメッセージの施設は、様々な形で、様々なネットワーク上で既に存在しています。 PSTNでは、それらは一般的にテキストテレフォニーと呼ばれています。
Text gateways are used for converting between different protocols for text conversation. They can be used between networks or within networks where different transport technologies are used.
テキストゲートウェイは、テキストの会話のための異なるプロトコル間の変換のために使用されています。彼らは、ネットワーク間、または異なるトランスポート技術が使用されているネットワーク内で使用することができます。
R38: ToIP SHOULD provide interoperability with text conversation features in other networks, for instance the PSTN.
R38：TOIPは、例えばPSTNのために、他のネットワーク内のテキスト会話機能との相互運用性を提供する必要があります。
R39: When communicating via a gateway to other networks and protocols, the ToIP service SHOULD support the functionality for alternating or simultaneous use of modalities as offered by the interworking network.
R39：他のネットワークとプロトコルにゲートウェイを介して通信するときのインターワーキングのネットワークによって提供されるように、TOIPサービスは、モダリティの交互または同時に使用するための機能をサポートしなければなりません。
R40: Calling party identification information, such as CLI, MUST be passed by gateways and converted to an appropriate form, if required.
R40は：CLIなどのパーティの識別情報を、呼び出し、ゲートウェイによって渡さなければなりません、そして、必要に応じて、適切な形式に変換します。
R41: When interworking with other networks and services, the ToIP service SHOULD provide buffering mechanisms to deal with delays in call setup and with differences in transmission speeds, and/or to interwork with half-duplex services.
R41：他のネットワークやサービスと相互作用すると、TOIPサービスは、コールセットアップ中と伝送速度の違いで遅延に対処するためのバッファリングメカニズムを提供すべき、および/または半二重のサービスと相互作用します。
Analog text telephony is used in many countries, mainly by deaf, hard-of-hearing and speech-impaired individuals.
アナログのテキスト電話は主にハードの聴力聴覚障害者、および音声障害者で、多くの国で使用されています。
R42: ToIP services MUST provide interworking with PSTN legacy text telephony devices.
R42：TOIPサービスは、PSTNのレガシーテキストテレフォニーデバイスとのインターワーキングを提供しなければなりません。
R43: When interworking with PSTN legacy text telephony services, alternating text and voice function MAY be supported. (Called "voice carry over (VCO) and hearing carry over (HCO)").
R43：テキストと音声機能を交互に、PSTNのレガシーテキストの電話サービスと相互作用がサポートされるかもしれません。 （いわゆる "）の声が持ち越さ（VCO）と聴力は（HCOをキャリーオーバー"）。
As mobile communications have been adopted widely, various solutions for real-time texting while on the move were developed. ToIP services should provide interworking with such services as well.
モバイル通信が広く採用されているように、移動中にリアルタイムのテキストメッセージのための種々の解決策が開発されました。 TOIPサービスは、同様にこのようなサービスとのインターワーキングを提供する必要があります。
Alternative means of transferring the text telephony data have been developed when TTY services over cellular were mandated by the FCC in the USA. They are the a) "No-gain" codec solution, and b) the Cellular Text Telephony Modem (CTM) solution [7], both collectively called "Baudot mode" solution in the USA.
携帯オーバーTTYサービスは、米国のFCCによって義務付けられたとき、テキストテレフォニーデータを転送する代替手段が開発されています。彼らは、A）「いいえゲイン」コーデック溶液、及び米国におけるB）セルラーテキスト電話モデム（CTM）溶液[7]、両方の総称「ボドーモード」溶液です。
The GSM and 3G standards from 3GPP make use of the CTM modem in the voice channel for text telephony. However, implementations also exist that use the data channel to provide such functionality. Interworking with these solutions should be done using text gateways that set up the data channel connection at the GSM side and provide ToIP at the other side.
3GPPからGSMおよび3G規格は、テキストテレフォニーのための音声チャネルでのCTMモデムを利用します。しかし、実装はまた、そのような機能を提供するデータ・チャネルを使用すること存在します。これらのソリューションと連動は、GSM側のデータチャネル接続を設定し、他側にTOIPを提供するテキストゲートウェイを使用して行われるべきです。
R44: a ToIP service SHOULD provide interworking with mobile text conversation services.
R44：TOIPサービスは、モバイルテキスト会話サービスとのインターワーキングを提供する必要があります。
Many people use Instant Messaging to communicate via the Internet using text. Instant Messaging usually transfers blocks of text rather than streaming as is used by ToIP. Usually a specific action is required by the user to activate transmission, such as pressing the ENTER key or a send button. As such, it is not a replacement for ToIP; in particular, it does not meet the needs for real-time conversations including those of deaf, hard-of-hearing, and speech-impaired users as defined in RFC 3351 [22]. It is less suitable for communications through a relay service [24].
多くの人々は、テキストを使用してインターネットを介して通信するためにインスタントメッセージングを使用しています。インスタントメッセージングは、通常、むしろTOIPで使用されるストリーミングよりも、テキストのブロックを転送します。通常、特定のアクションは、Enterキーまたは送信ボタンを押すと、送信をアクティブにするためにユーザが必要とされます。このように、それはTOIPに代わるものではありません。 RFC 3351 [22]で定義されるように、特に、それは、ハードの-聴覚、音声障害のあるユーザー、聴覚障害者を含めたリアルタイムの会話のためのニーズを満たしていません。これは、中継サービス[24]を介した通信のためにあまり適していません。
The streaming nature of ToIP provides a more direct conversational user experience and, when given the choice, users may prefer ToIP.
TOIPのストリーミング性質は、より直接的な会話のユーザーエクスペリエンスを提供し、選択肢が与えられたとき、ユーザーはTOIPを好むかもしれません。
R45: a ToIP service MAY provide interworking with Instant Messaging services.
R45：TOIPサービスは、インスタントメッセージングサービスとのインターワーキングを提供することができます。
This section describes an implementation framework for ToIP that meets the requirements and offers the functionality as set out in Section 5. The framework presented here uses existing standards that are already commonly used for voice-based conversational services on IP networks.
このセクションでは、要件を満たし、ここで紹介するフレームワークがすでに一般的にIPネットワーク上で音声ベースの会話のサービスのために使用されている既存の標準を使用して第5節に記載されたような機能を提供していますTOIPのための実施体制について説明します。
This framework specifies the use of the Session Initiation Protocol (SIP) [2] to set up, control, and tear down the connections between ToIP users whilst the media is transported using the Real-Time Transport Protocol (RTP) [3] as described in RFC 4103 [4].
このフレームワークは、[2]、コントロールを設定し、メディアはリアルタイムトランスポートプロトコル（RTP）を使用して搬送されながら、TOIPユーザー間の接続を切断するセッション開始プロトコル（SIP）の使用を指定する[3]記載のようにRFC 4103 [4]。
RFC 4504 describes how to implement support for real-time text in SIP telephony devices [23].
RFC 4504は、SIPテレフォニーデバイスで、リアルタイムのテキスト[23]のサポートを実装する方法について説明します。
ToIP services MUST use the Session Initiation Protocol (SIP) [2] for setting up, controlling, and terminating sessions for real-time text conversation with one or more participants and possibly including other media like video or audio. The Session Description Protocol (SDP) used in SIP to describe the session is used to express the attributes of the session and to negotiate a set of compatible media types.
TOIPサービスは、設定制御、およびビデオまたはオーディオのような他の媒体を含む、場合によっては1つまたは複数の参加者として、リアルタイムのテキストの会話のセッションを終了するための[2]セッション開始プロトコル（SIP）を使用する必要があります。セッションを記述するためにSIPで使用されるセッション記述プロトコル（SDP）は、セッションの属性を表現するために、互換性のあるメディアタイプのセットをネゴシエートするために使用されます。
SIP [2] allows participants to negotiate all media, including real-time text conversation [4]. ToIP services can provide the ability to set up conversation sessions from any location as well as provision for privacy and security through the application of standard SIP techniques.
SIPは、[2]参加者は、リアルタイムのテキストの会話[4]を含むすべてのメディアを、交渉することができます。 TOIPサービスは、任意の場所だけでなく、標準のSIP技術のアプリケーションを介してプライバシーとセキュリティのための引当金から会話セッションを設定する能力を提供することができます。
The requirements of the user to be reached at a consistent address and to store preferences for evaluation at session setup are met by pre-session setup actions. That includes storing of registration information in the SIP registrar to provide information about how a user can be contacted. This will allow sessions to be set up rapidly and with proper routing and addressing.
ユーザーの要件に一貫性のあるアドレスに到達すると、セッションセットアップでの評価のための環境設定を保存するためには、事前にセッションセットアップアクションによって満たされています。すなわち、ユーザは、接触させることができる方法に関する情報を提供するために、SIPレジストラに登録情報の格納を含みます。これは、セッションが迅速かつ適切なルーティングとアドレスで設定できるようになります。
The need to use real-time text as a medium of communications can be expressed by users during registration time. Two situations need to be considered in the pre-session setup environment: a. User Preferences: It MUST be possible for a user to indicate a preference for real-time text by registering that preference with a SIP server that is part of the ToIP service.
コミュニケーションの媒体としてリアルタイムのテキストを使用する必要性は、登録時にユーザーによって表現することができます。 2つの状況は、プリセッションセットアップ環境の中で検討する必要があります。ユーザー設定：ユーザーがTOIPサービスの一部であるSIPサーバとその優先順位を登録することで、リアルタイムのテキストのための好みを示すすることが可能でなければなりません。
b. Server Support of User Preferences: SIP servers that support ToIP services MUST have the capability to act on calling user preferences for real-time text in order to accept or reject the session. The actions taken can be based on the called users preferences defined as part of the pre-session setup registration. For example, if the user is called by another party, and it is determined that a transcoding server is needed, the session should be re-directed or otherwise handled accordingly.
B。ユーザー設定のサーバーのサポート：SIPサーバTOIPサービスをサポートセッションを受け入れるか拒否するために、リアルタイムのテキストのためのユーザー設定を呼び出すに作用する能力を持たなければなりません。取られた行動は、プリセッションセットアップ登録の一部として定義と呼ばれるユーザの嗜好に基づくことができます。ユーザが別の当事者によって呼び出され、トランスコーディングサーバが必要であると判定された場合、例えば、セッションを再指向又はそうでなければそれに応じて取り扱わなければなりません。
The ability to include a transcoding service MUST NOT require user registration in any specific SIP registrar, but MAY require authorisation of the SIP registrar to invoke the service.
トランスコーディングサービスを含める機能は、特定のSIPレジストラにユーザー登録を要求することはできませんが、サービスを呼び出すために、SIPレジストラの承認が必要な場合があります。
A point-to-point session takes place between two parties. For ToIP, one or both of the communicating parties will indicate real-time text as a possible or preferred medium for conversation using SIP in the session setup.
ポイントツーポイントセッションでは、2者間で行われます。 TOIPのために、1または通信当事者の両方がセッションセットアップにSIPを使用して、会話のための可能な又は好ましい媒体としてリアルタイムのテキストを示します。
The following features MAY be implemented to facilitate the session establishment using ToIP:
次の機能は、TOIPを使用してセッションの確立を促進するために実施することができます。
a. Caller Preferences: SIP headers (e.g., Contact) [10] can be used to show that real-time text is the medium of choice for communications.
A。発信者の設定：SIPヘッダ（例えば、接触）[10]は、リアルタイム・テキストは、通信のための選択の媒体であることを示すために使用することができます。
b. Called Party Preferences [11]: The called party being passive can formulate a clear rule indicating how a session should be handled, either using real-time text as a preferred medium or not, and whether this session needs to be handled by a designated SIP proxy or the SIP User Agent.
B。着信側の設定[11]：被呼者は、セッションがどのように処理すべきかを示す明確なルールを策定することができ、受動的であること、のいずれかの好適な媒体やないなどのリアルタイムテキストを使用して、このセッションは、指定されたSIPによって処理する必要があるかどうかプロキシまたはSIPユーザーエージェント。
c. SIP Server Support for User Preferences: It is RECOMMENDED that SIP servers also handle the incoming sessions in accordance with preferences expressed for real-time text. The SIP server can also enforce ToIP policy rules for communications (e.g., use of the transcoding server for ToIP).
C。ユーザー設定のためのSIPサーバのサポート：SIPサーバは、リアルタイムのテキストのための表現好みに応じて、着信セッションを扱うことが推奨されます。 SIPサーバは、通信のためTOIPポリシールールを適用することができる（例えば、TOIPのためのトランスコーディングサーバを使用します）。
The Session Description Protocol (SDP) used in SIP [2] provides the capabilities to indicate real-time text as a medium in the session setup. RFC 4103 [4] uses the RTP payload types "text/red" and "text/t140" for support of ToIP, which can be indicated in the SDP as a part of the SIP INVITE, OK, and SIP/200/ACK media negotiations. In addition, SIP's offer/answer model [12] can also be used in conjunction with other capabilities, including the use of a transcoding server for enhanced session negotiations [28,29,13].
[2]はSIPで使用されるセッション記述プロトコル（SDP）は、セッションセットアップ中に媒体としてリアルタイムのテキストを示すための機能を提供します。 RFC 4103 [4] OK、INVITE SIPの一部として、SDPに示すことができるRTPペイロードタイプ「テキスト/赤」とTOIPのサポートのために、「テキスト/ T140」を使用し、SIP / 200 / ACKメディア交渉。また、SIPのオファー/アンサーモデル[12]はまた、強化されたセッション交渉[28,29,13]のためのトランスコーディング・サーバの使用を含む、他の機能と組み合わせて使用することができます。
ToIP services MUST support the Real-Time Transport Protocol (RTP) [3] according to the specification of RFC 4103 [4] for the transport of real-time text between participants.
TOIPサービスは、[4]、参加者間のリアルタイムテキストの輸送のための[3] RFC 4103の仕様に応じてリアルタイムトランスポートプロトコル（RTP）をサポートしなければなりません。
RFC 4103 describes the transmission of T.140 [8] real-time text on IP networks.
RFC 4103は、IPネットワーク上でT.140 [8]リアルタイムテキストの送信を説明します。
In order to enable the use of international character sets, the transmission format for real-time text conversation SHALL be UTF-8 [14], in accordance with ITU-T T.140.
国際文字セットの使用を可能にするために、リアルタイムのテキストの会話のための伝送フォーマットは、ITU-T T.140に従って、UTF-8 [14]でなければなりません。
If real-time text is detected to be missing after transmission, there SHOULD be a "text loss" indication in the real-time text as specified in T.140 Addendum 1 [8].
リアルタイムのテキストを送信した後に欠落することが検出された場合T.140補遺1で指定されるように、リアルタイムのテキストに「テキスト損失」の表示があるべきである[8]。
The redundancy method of RFC 4103 [4] SHOULD be used to significantly increase the reliability of the real-time text transmission. A redundancy level using 2 generations gives very reliable results and is therefore strongly RECOMMENDED.
RFC 4103 [4]の冗長化方法を大幅リアルタイムテキスト伝送の信頼性を高めるために使用されるべきです。 2つの世代を使用して冗長レベルは、非常に信頼性の高い結果を提供しますので、強くお勧めします。
In order to avoid exceeding the capabilities of the sender, receiver, or network (congestion), the transmission rate SHOULD be kept at or below 30 characters per second, which is the default maximum rate specified in RFC 4103 [4]. Lower rates MAY be negotiated when needed through the "cps" parameter as specified in RFC 4103 [4].
送信側、受信機、又はネットワーク（輻輳）の能力を超えないようにするために、伝送速度は、RFC 4103で指定されたデフォルトの最大レートで毎秒30の文字、またはその下に維持されるべきである[4]。 「CPS」パラメータを使用して、必要なときにRFC 4103に指定されている低金利は交渉されるかもしれない[4]。
Real-time text capability is announced in SDP by a declaration similar to this example:
リアルタイムのテキスト機能は、次の例のように宣言によってSDPに発表されています。
m=text 11000 RTP/AVP 100 98 a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=fmtp:100 98/98/98
M =テキスト11000 RTP / AVP 100 98 = rtpmap：98 T140 / 1000 = rtpmap：100赤/ 1000 =のfmtp：100 98/98/98
By having this single coding and transmission scheme for real-time text defined in the SIP session control environment, the opportunity for interoperability is optimized. However, if good reasons exist, other transport mechanisms MAY be offered and used for the T.140- coded text, provided that proper negotiation is introduced, but the RFC 4103 [4] transport MUST be used as both the default and the fallback transport.
SIPセッション制御環境で定義されたリアルタイムのテキストのために、この単一の符号化及び伝送方式を有することにより、相互運用性のための機会が最適化されています。正当な理由が存在する場合は、他のトランスポート機構が提供され、T.140-符号化されたテキストのために使用されてもよく、適切なネゴシエーションが導入されることを条件とするが、RFC 4103 [4]トランスポートはデフォルトおよび代替輸送の両方として使用する必要があります。
Invocation of a transcoding service MAY happen automatically when the session is being set up based on any valid indication or negotiation of supported or preferred media types. A transcoding framework document using SIP [28] describes invoking relay services, where the relay acts as a conference bridge or uses the third-party control mechanism. ToIP implementations SHOULD support this transcoding framework.
トランスコーディングサービスの呼び出しは、セッションがサポートまたは優先メディアタイプのいずれかの有効な徴候や交渉に基づいて設定されているときに自動的に発生する可能性があります。 SIPを使用して、トランスコーディング・フレームワークドキュメント[28]について説明リレーが会議ブリッジとして作用するか、サードパーティの制御機構を使用する場合、中継サービスを呼び出します。 TOIPの実装は、このトランスコーディング・フレームワークをサポートする必要があります。
Session progress information SHOULD use simple language so that as many users as possible can understand it. The use of jargon or ambiguous terminology SHOULD be avoided. It is RECOMMENDED that text information be used together with icons to symbolise the session progress information.
できるだけ多くのユーザーがそれを理解できるように、セッションの進行情報は、単純な言語を使用すべきです。専門用語やあいまいな用語の使用は避けるべきです。テキスト情報は、セッションの進捗情報を象徴するアイコンと一緒に使用することをお勧めします。
In summary, it SHOULD be possible to observe indicators about:
要約すると、についての指標を観察することが可能であるべきです：
- Incoming session
- 着信セッション
- Availability of real-time text, voice, and video channels
- リアルタイムテキスト、音声、およびビデオチャンネルの可用性
- Session progress
- セッションの進行状況
- Incoming real-time text
- 着信リアルタイムテキスト
- Any loss in incoming real-time text
- 入ってくるリアルタイムのテキスト内の任意の損失
- Typed and transmitted real-time text
- 型付きと送信リアルタイムテキスト
For users who cannot use the audible alerter for incoming sessions, it is RECOMMENDED to include a tactile, as well as a visual, indicator.
着信セッションのための可聴アラータを使用できないユーザーのために、触覚だけでなく、視覚的なインジケータを含めることをお勧めします。
Among the alerting options are alerting by the User Agent's User Interface and specific alerting User Agents registered to the same registrar as the main User Agent.
警告オプションの中でユーザーエージェントのユーザーインターフェイスとメインユーザーエージェントと同じレジストラに登録された特定の警告ユーザエージェントでアラート状態になっています。
It should be noted that external alerting systems exist and one common interface for triggering the alerting action is a contact closure between two conductors.
外部警報システムが存在し、警告アクションをトリガするための1つの共通インタフェースは、2つの導体間の接点閉鎖であることに留意すべきです。
Requirement R32 states that, in the display of text conversations, users must be able to distinguish easily between different speakers. This could be done using color, positioning of the text (i.e., incoming real-time text and outgoing real-time text in different display areas), in-band identifiers of the parties, or a combination of any of these techniques.
要件R32は、テキストの会話の表示には、ユーザーが別のスピーカー間を容易に区別することができなければならない、と述べています。これは、色、テキストの位置（すなわち、着信リアルタイムのテキストとは異なる表示領域に発信リアルタイム・テキスト）、当事者のインバンド識別子、またはこれらの技術の任意の組み合わせを用いて行うことができます。
Requirement R31 recommends that ToIP systems allow the user to save text conversations. This SHOULD be done using a standard file format. For example: a UTF-8 text file in XHTML format [15], including timestamps, party names (or addresses), and the conversation text.
要件R31はTOIPシステムは、ユーザーがテキストの会話を保存することができますことをお勧めします。これは、標準のファイルフォーマットを使用して行われるべきです。たとえば、次のようにタイムスタンプ、パーティ名（またはアドレス）、及び会話テキストを含むXHTML形式[15]、でUTF-8のテキストファイル。
A number of systems for real-time text conversation already exist as well as a number of message-oriented text communication systems. Interoperability is of interest between ToIP and some of these systems.
リアルタイムのテキストの会話のためのシステムの数は、既にメッセージ指向テキスト通信システムの数と同様に存在します。相互運用性は、TOIPと、これらのシステムの一部との間に重要です。
Interoperation of half-duplex and full-duplex protocols, and between protocols that have different data rates, may require text buffering. Some intelligence will be needed to determine when to change direction when operating in half-duplex mode. Identification may be required of half-duplex operation either at the "user" level (i.e., users must inform each other) or at the "protocol" level (where an indication must be sent back to the gateway). However, special care needs to be taken to provide the best possible real-time performance.
半二重および全二重プロトコルの相互運用、および異なるデータ・レートを持つプロトコルの間で、テキストのバッファリングが必要な場合があります。半二重モードで動作しているときに方向を変更する場合、いくつかの知性が決定するのに必要とされるであろう。識別は、「ユーザ」レベル（すなわち、ユーザがお互いに通知しなければならない）で、または（指示がゲートウェイに返送されなければならない）「プロトコル」レベルのいずれか半二重動作が要求されてもよいです。しかし、特別なケアは、可能な限り最高のリアルタイム性能を提供するために取られる必要があります。
Buffering schemes SHOULD be dimensioned to adjust for receiving at 30 characters per second and transmitting at 6 characters per second for up to 4 minutes (i.e., less than 3000 characters).
バッファリングスキームは、1秒間に30文字で受信し、最大4分（すなわち、未満3000文字）が毎秒6つの文字で送信を調整するために寸法決めされるべきです。
When converting between simultaneous voice and text on the IP side, and alternating voice and text on the other side of a gateway, a conflict can occur if the IP user transmits both audio and text at the same time. In such situations, text transmission SHOULD have precedence, so that while text is transmitted, audio is lost.
IP側で同時音声とテキストとの間の変換、およびゲートウェイの反対側に音声およびテキストを交互にするときIPユーザーが同時に音声及びテキストの両方を送信する場合、競合が発生する可能性があります。テキストが送信されている間、オーディオが失われたように、このような状況では、テキストの送信は、優先順位を持つべきです。
Transcoding of text to and from other coding formats may need to take place in gateways between ToIP and other forms of text conversation, for example, to connect to a PSTN text telephone.
他の符号化フォーマットへとからのテキストのトランスコーディングは、PSTNテキスト電話に接続するために、例えば、TOIPとテキストの会話の他の形態の間のゲートウェイで場所を取る必要があるかもしれません。
Session setup through gateways to other networks may require the use of specially formatted addresses or other mechanisms for invoking those gateways.
他のネットワークへのゲートウェイを介して、セッションセットアップは、これらのゲートウェイを呼び出すために特別にフォーマットされたアドレス又は他の機構の使用を必要とし得ます。
ToIP interworking requires a method to invoke a text gateway. These text gateways act as User Agents at the IP side. The capabilities of the gateway during the call will be determined by the call capabilities of the terminal that is using the gateway. For example, a PSTN textphone is generally only able to receive voice and real-time text, so the gateway will only allow ToIP and audio.
TOIPインターワーキングは、テキストゲートウェイを起動する方法を必要とします。これらのテキスト・ゲートウェイは、IP側でユーザエージェントとして機能します。通話中ゲートウェイの機能は、ゲートウェイを使用している端末の呼出能力によって決定されるであろう。例えば、PSTNのtextphoneは、一般的に、音声およびリアルタイムテキストを受信することしかできなので、ゲートウェイはのみTOIPとオーディオが可能になります。
Examples of possible scenarios for invocation of the text gateway are:
テキストゲートウェイの呼び出しのための可能なシナリオの例としては、以下のとおりです。
a. PSTN textphone users dial a prefix number before dialing out.
A。 PSTNのtextphoneユーザーがダイヤルアウトする前にプレフィックス番号をダイヤルします。
b. Separate real-time text subscriptions, linked to the phone number or terminal identifier/ IP address.
B。電話番号や端末識別子/ IPアドレスにリンクされている個別のリアルタイムテキストサブスクリプション、。
c. Real-time text capability indicators.
C。リアルタイムテキスト機能指標。
d. Real-time text preference indicators.
D。リアルタイムのテキスト優先指標。
e. Listen for V.18 modem modulation text activity in all PSTN calls and routing of the call to an appropriate gateway.
電子。すべてのPSTNコールおよび適切なゲートウェイへのコールのルーティングにV.18モデム変調テキスト活性をリッスン。
f. Call transfer request by the called user.
F。ユーザーによる転送要求を呼び出します。
g. Placing a call via the Web, and using one of the methods described here
グラム。 Web経由で電話をかけて、ここで説明する方法のいずれかを使用して
h. A text gateway with its own telephone number and/or SIP address (this requires user interaction with the gateway to place a call).
時間。独自の電話番号および/またはSIPアドレスを持つテキストゲートウェイは、（これは、電話をかけるためのゲートウェイとユーザとの対話が必要です）。
i. ENUM address analysis and number plan.
私。 ENUMアドレス分析と番号計画。
j. Number or address analysis leads to a gateway for all PSTN calls.
J。番号またはアドレス解析は、すべてのPSTN通話のためのゲートウェイにつながります。
Analog text telephony is cumbersome because of incompatible national implementations where interworking was never considered. A large number of these implementations have been documented in ITU-T V.18 [16], which also defines the modem detection sequences for the different text protocols. In rare cases, the modem type identification may take considerable time, depending on user actions.
アナログテキストテレフォニーためのインターワーキングは考慮されなかった、互換性のない国家の実装の面倒です。これらの実装の多くは、異なるテキストプロトコルのモデム検出シーケンスを定義するITU-T V.18 [16]に記載されています。まれに、モデムタイプの識別は、ユーザのアクションに応じて、かなりの時間がかかる場合があります。
To resolve analog textphone incompatibilities, text telephone gateways are needed to transcode incoming analog signals into T.140 and vice versa. The modem capability exchange time can be reduced by the text telephone gateways initially assuming the analog text telephone protocol used in the region where the gateway is located. For example, in the USA, Baudot [25] might be tried as the initial protocol. If negotiation for Baudot fails, the full V.18 modem capability exchange will take place. In the UK, ITU-T V.21 [26] might be the first choice.
アナログtextphoneの非互換性を解決するために、テキスト電話ゲートウェイはT.140及びその逆に入ってくるアナログ信号をトランスコードするために必要とされます。モデム能力交換時間は、最初にゲートウェイが配置されている領域で使用されるアナログのテキスト電話プロトコルを想定テキスト電話ゲートウェイによって低減することができます。例えば、米国では、ボドー[25]最初のプロトコルとして試されるかもしれません。ボドーのための交渉が失敗した場合、完全なV.18モデム能力交換が行われます。英国では、ITU-T V.21 [26]は最初の選択肢かもしれません。
In particular, transmission of real-time text on PSTN networks takes place using a variety of codings and modulations, including ITU-T V.21 [26], Baudot [25], dual-tone multi-frequency (DTMF), V.23 [27], and others. Many difficulties have arisen as a result of this variety in text telephony protocols and the ITU-T V.18 [16] standard was developed to address some of these issues.
具体的には、PSTNネットワーク上のリアルタイム・テキストの送信は、ITU-T V.21など、コーディング及び変調のさまざまな方法を使って行われ[26]、ボドー[25]、デュアルトーン多重周波数（DTMF）、V. 23 [27]、などが挙げられます。多くの困難がテキストテレフォニープロトコルとITU-T V.18 [16]標準では、この多様性の結果として生じたこれらの問題の一部に対処するために開発されました。
ITU-T V.18 [16] offers a native text telephony method, plus it defines interworking with current protocols. In the interworking mode, it will recognise one of the older protocols and fall back to that transmission method when required.
ITU-T V.18 [16]はネイティブテキストテレフォニー方法を提供しています、それに加えて、現在のプロトコルでインターワーキングを定義します。インターワーキングモードでは、古いプロトコルの一つを認識し、必要なときにその伝送方式にフォールバック。
Text gateways MUST use the ITU-T V.18 [16] standard at the PSTN side. A text gateway MUST act as a SIP User Agent on the IP side and support RFC 4103 real-time text transport.
テキストゲートウェイは、PSTN側のITU-T V.18 [16]標準を使用しなければなりません。テキストゲートウェイは、IP側のSIPユーザエージェントとして機能し、RFC 4103、リアルタイムのテキスト転送をサポートしなければなりません。
While ToIP allows receiving and sending real-time text simultaneously and is displayed on a split screen, many analog text telephones require users to take turns typing. This is because many text telephones operate strictly half duplex. Only one can transmit text at a time. The users apply strict turn-taking rules.
TOIPを同時にリアルタイムでテキストを受信し、送信することが可能と分割画面に表示されている間、多くのアナログのテキスト電話はターンタイピングを取るために、ユーザーが必要となります。多くのテキスト電話は厳密に半二重で動作するためです。一方のみが一度にテキストを送信することができます。ユーザーは、厳密なターン取っルールを適用します。
There are several text telephones which communicate in full duplex, but merge transmitted text and received text in the same line in the same display window. Here too the users apply strict turn taking rules.
が全二重で通信する複数のテキスト電話であるが、送信されたテキストをマージし、同じ表示窓に同じ行のテキストを受け取りました。ここでもユーザーがルールを取っ厳しいターンを適用します。
Native V.18 text telephones support full duplex and separate display from reception and transmission so that the full duplex capability can be used fully. Such devices could use the ToIP split screen as well, but almost all text telephones use a restricted character set and many use low text transmission speeds (4 to 7 characters per second).
全二重の能力を完全に使用できるようにネイティブV.18テキスト電話は受信と送信から全二重と別個のディスプレイをサポートします。このようなデバイスは、同様にTOIPの分割画面を使用することができますが、ほとんどすべてのテキストの電話が制限された文字セットと多くの利用が低いテキスト伝送速度（毎秒4〜7文字）を使用します。
That is why it is important for the ToIP user to know that he or she is connected with an analog text telephone. The session description [9] SHOULD contain an indication that the other endpoint for the call
TOIPのユーザーは、彼または彼女はアナログのテキスト電話が接続されていることを知ることが重要である理由です。セッション記述は、[9]の指示を含むべきであることをコールするための他のエンドポイント
is a PSTN textphone (e.g., connected via an ATA or through a text gateway). This means that the textphone user may be used to formal turn taking during the call.
（例えば、ATAを介して、またはテキストゲートウェイを介して接続されている）のPSTN textphoneあります。これはtextphoneユーザーが通話中に正式なターン撮影に使用することができることを意味します。
Mobile wireless (or cellular) circuit switched connections provide a digital real-time transport service for voice or data. The access technologies include GSM, CDMA, TDMA, iDen, and various 3G technologies, as well as WiFi or WiMAX.
モバイルワイヤレス（またはセルラー）回路は、接続が音声またはデータのデジタルリアルタイムトランスポート・サービスを提供する切り替え。アクセス技術は、GSM、CDMA、TDMA、IDEN、および様々な3G技術、並びにWiFiまたはWiMAXのが挙げられます。
ToIP may be supported over the cellular wireless packet-switched service. It interfaces to the Internet.
TOIPは、セルラー無線パケット交換サービスを介してサポートすることができます。これは、インターネットへのインタフェース。
The following sections describe how mobile text telephony is supported.
次のセクションでは、サポートされていますどのように携帯電話のテキスト電話について説明します。
The "No-gain" text telephone transporting technology uses specially modified Enhanced Full Rate (EFR) [17] and Enhanced Variable Rate (EVR) [18] speech vocoders in mobile terminals used to provide a text telephony call. It provides full duplex operation and supports alternating between voice and text ("VCO/HCO"). It is dedicated to CDMA and TDMA mobile technologies and the US Baudot (i.e., 45 bit/s) type of text telephones.
「ノー・ゲイン」テキスト電話の輸送技術は、テキストテレフォニーコールを提供するために使用される携帯端末で特別に変更拡張フルレート（EFR）[17]と拡張可変レート（EVR）[18]スピーチボコーダを使用しています。これは、全二重動作を提供し、音声とテキスト（「VCO / HCO」）との間で交互にサポートしています。これは、CDMAとTDMAモバイル技術とテキスト電話の米国ボドー（すなわち、45ビット/秒）タイプ専用です。
CTM [7] is a technology-independent modem technology that provides the transport of text telephone characters at up to 10 characters/sec using modem signals that can be carried by many voice codecs and uses a highly redundant encoding technique to overcome the fading and cell changing losses.
CTMは、[7]多くの音声コーデックによって実施することができるモデム信号を使用して最大10文字/秒でテキスト電話の文字の輸送を提供する技術に依存しないモデム技術であり、フェージング、細胞を克服するために、冗長性の高い符号化技術を使用し損失を変えます。
This term is often used by cellular terminal suppliers for a cellular phone mode that allows TTYs to operate into a cellular phone and to communicate with a fixed-line TTY. Thus it is a common name for the "No-Gain" and the CTM solutions when applied to the Baudot-type textphones.
この用語は、しばしば、TTYの携帯電話に動作し、固定回線TTYと通信することを可能にする携帯電話モードの携帯端末サプライヤによって使用されます。したがって、「いいえゲイン」とボドー型textphonesに適用されるCTMソリューションのための共通の名前です。
Many mobile terminals allow the use of the circuit-switched data channel to transfer data in real time. Data rates of 9600 bit/s are usually supported on the 2G mobile network. Gateways provide interoperability with PSTN textphones.
多くのモバイル端末は、回線交換データチャネルの使用は、リアルタイムでデータを転送することができます。 9600ビット/秒のデータ転送速度が通常の2Gモバイルネットワーク上でサポートされています。ゲートウェイは、PSTNのtextphonesとの相互運用性を提供します。
ToIP could be supported over mobile wireless packet-switched services that interface to the Internet. For 3GPP 3G services, ToIP support is described in 3G TS 26.235 [19].
TOIPは、インターネットへのインタフェースの移動無線パケット交換サービスを介してサポートすることができます。 3GPP 3Gサービスのために、TOIPのサポートは、3G TS 26.235 [19]に記載されています。
Text gateways MAY be used to allow interworking between Instant Messaging systems and ToIP solutions. Because Instant Messaging is based on blocks of text, rather than on a continuous stream of characters like ToIP, gateways MUST transcode between the two formats. Text gateways for interworking between Instant Messaging and ToIP MUST apply a procedure for bridging the different conversational formats of real-time text versus text messaging. The following advice may improve user experience for both parties in a call through a messaging gateway.
テキストゲートウェイは、インスタントメッセージングシステムとTOIPソリューション間のインターワーキングを可能にするために使用されます。インスタントメッセージングは、テキストのブロックではなく、TOIPのような文字の連続ストリームに基づいているため、ゲートウェイは二つのフォーマット間でトランスコードしなければなりません。インスタントメッセージングとTOIP間のインターワーキングのためのテキスト・ゲートウェイは、テキストメッセージング対リアルタイムテキストの異なる会話形式を橋渡しするための手順を適用しなければなりません。以下のアドバイスは、メッセージングゲートウェイを介して通話中に、両当事者のユーザーエクスペリエンスを向上させることができます。
a. Concatenate individual characters originating at the ToIP side into blocks of text.
A。テキストのブロックに上側に由来する個々の文字を連結します。
b. When the length of the concatenated message becomes longer than 50 characters, the buffered text SHOULD be transmitted to the Instant Messaging side as soon as any non-alphanumerical character is received from the ToIP side.
B。連結メッセージの長さが50文字を超えるになると、バッファリングされたテキストは、すぐに任意の非英数字の文字がTOIP側から受信されるインスタントメッセージング側に送信すべき。
c. When a new line indicator is received from the ToIP side, the buffered characters up to that point, including the carriage return and/or line-feed characters, SHOULD be transmitted to the Instant Messaging side.
C。新しいラインインジケータはTOIP側から受信した場合、キャリッジリターンおよび/または改行文字を含むその時点までの緩衝文字は、インスタントメッセージング側に送信すべき。
d. When the ToIP side has been idle for at least 5 seconds, all buffered text up to that point SHOULD be transmitted to the Instant Messaging side.
D。 TOP側は、少なくとも5秒間アイドル状態になっている場合は、その時点までのすべてのバッファリングされたテキストは、Instant Messaging側に送信すべき。
e. Text Gateways must be capable of maintaining the real-time performance for ToIP while providing the interworking services.
電子。テキストゲートウェイは、インターワーキングサービスを提供しながら、TOIPのためのリアルタイム性能を維持することが可能でなければなりません。
It is RECOMMENDED that during the session, both users be constantly updated on the progress of the text input. Many Instant Messaging protocols signal that a user is typing to the other party in the conversation. Text gateways between such Instant Messaging protocols and ToIP MUST provide this signalling to the Instant Messaging side when characters start being received, or at the beginning of the conversation.
セッション中に、両方のユーザーが常にテキスト入力の進展に更新することをお勧めします。多くのインスタントメッセージングプロトコルは、ユーザーが会話中に相手に入力されていることを知らせます。そのようなインスタントメッセージングプロトコル間とTOIPテキストゲートウェイは、文字が受信されて起動したときにインスタントメッセージング側にこのシグナリングを提供し、または会話の冒頭にしなければなりません。
At the ToIP side, an indicator of writing the Instant Message MUST be present where the Instant Messaging protocol provides one. For example, the real-time text user MAY see ". . . waiting for replying IM. . . " and when 5 seconds have passed another . (dot) can be shown.
インスタントメッセージングプロトコルが1つを提供する場合TOIP側に、インスタントメッセージの書き込みの指標が存在しなければなりません。例えば、リアルタイムのテキストユーザーが見ることができる「。。。。。IMの返信を待っている」と5秒は別のものを合格したとき。 （ドット）を示すことができます。
Those solutions will reduce the difficulties between streaming and blocked text services.
これらのソリューションは、ストリーミングとブロックされたテキストサービスとの難しさを軽減します。
Even though the text gateway can connect Instant Messaging and ToIP, the best solution is to take advantage of the fact that the user interfaces and the user communities for instant messaging and ToIP telephony are very similar. After all, the character input, character display, Internet connectivity, and SIP stack can be the same for Instant Messaging (SIMPLE) and ToIP. Thus, the user may simply use different applications for ToIP and text messaging in the same terminal.
テキストゲートウェイは、インスタントメッセージングとTOIPを接続することができるにもかかわらず、最善の解決策は、ユーザインタフェースおよびインスタントメッセージングとTOIPテレフォニーのためのユーザコミュニティは非常に似ているという事実を利用することです。結局のところ、文字入力、文字表示、インターネット接続、およびSIPスタックは、インスタントメッセージング（SIMPLE）とTOIPで同じにすることができます。したがって、ユーザは単に同一の端末でTOIPとテキストメッセージングのためのさまざまなアプリケーションを使用してもよいです。
Devices that implement Instant Messaging SHOULD implement ToIP as described in this document so that a more complete text communication service can be provided.
この文書で説明するように、より完全なテキスト通信サービスを提供できるように、インスタントメッセージングを実装するデバイスは、TOIPを実装する必要があります。
In practice, many interworking gateways will be implemented as gateways that combine different functions. As such, a text gateway could be built to have modems to interwork with the PSTN and support both Instant Messaging as well as ToIP. Such interworking functions are called combination gateways.
実際には、多くのインターワーキング・ゲートウェイは、異なる機能を組み合わせるゲートウェイとして実装されます。そのため、テキストゲートウェイは、PSTNと相互作用し、インスタントメッセージングなどTOIPの両方をサポートするために、モデムを持っているように構築することができます。このようなインターワーキング機能を組み合わせゲートウェイと呼ばれています。
Combination gateways could provide interworking between all of their supported text-based functions. For example, a text gateway that has modems to interwork with the PSTN and that support both Instant Messaging and ToIP could support the following interworking functions:
組み合わせゲートウェイは、彼らのサポートテキストベースのすべての機能間のインターワーキングを提供することができます。たとえば、インスタントメッセージングとTOIPの両方PSTNおよびその支援と相互作用するモデムを持っているテキストゲートウェイは、次のインターワーキング機能をサポートできます。
- PSTN text telephony to ToIP
- TOIPにPSTNテキスト電話
- PSTN text telephony to Instant Messaging
- インスタントメッセージングへのPSTNテキスト電話
- Instant Messaging to ToIP
- TOIPのインスタントメッセージング
Gateways between the ToIP network and other networks MAY need to transcode text streams. ToIP makes use of the ISO 10646 character set. Most PSTN textphones use a 7-bit character set, or a character set that is converted to a 7-bit character set by the V.18 modem.
TOIPネットワークと他のネットワーク間のゲートウェイは、テキストストリームをトランスコードする必要があるかもしれません。 TOIPは、ISO 10646文字セットを使用します。ほとんどのPSTNのtextphonesは7ビットの文字セット、またはV.18モデムで設定された7ビットの文字に変換された文字セットを使用します。
When transcoding between character sets and T.140 in gateways, special consideration MUST be given to the national variants of the 7-bit codes, with national characters mapping into different codes in the ISO 10646 code space. The national variant to be used could be selectable by the user on a per-call basis, or be configured as a national default for the gateway.
ゲートウェイでの文字セットとT.140間でトランスコードする場合、特別な考慮事項は、ISO 10646コード空間内の異なるコードに国別文字マッピングで、7ビットコードの国民の変種に与えられなければなりません。使用する国家変異体は、コールごとにユーザによって選択可能であり、又はゲートウェイの国家デフォルトとして設定すること。
The indicator of missing text in T.140, specified in T.140 amendment 1, cannot be represented in the 7-bit character codes. Therefore the indicator of missing text SHOULD be transcoded to the ' (apostrophe) character in legacy text telephone systems, where this character exists. For legacy systems where the ' character does not exist, the . (full stop) character SHOULD be used instead.
T.140改正1で指定されたT.140で欠落テキストのインジケータは、7ビットの文字コードで表現することができません。したがって、不足しているテキストのインジケータは、この文字が存在するレガシーテキスト電話システムにおける '（アポストロフィ）文字にトランスコードされるべきである（SHOULD）。 '文字が存在しないレガシーシステムの場合、。 （フルストップ）の文字を代わりに使用してください。
It must be possible to place an emergency call using ToIP and it must be possible to use a relay service in such a call. The emergency service provided to users utilising the real-time text medium must be equivalent to the emergency service provided to users utilising speech or other media.
TOIPを使用して緊急コールを配置することが可能でなければならず、そのような呼び出しでリレーサービスを使用することが可能でなければなりません。リアルタイムのテキスト媒体を利用し、ユーザーに提供される緊急サービスは、音声または他のメディアを利用し、ユーザーに提供される緊急サービスと同等でなければなりません。
A text gateway must be able to route real-time text calls to emergency service providers when any of the recognised emergency numbers that support text communications for the country or region are called, e.g., "911" in the USA and "112" in Europe. Routing real-time text calls to emergency services may require the use of a transcoding service.
テキストゲートウェイは、国または地域のためのテキスト通信をサポートして認識し、緊急番号のいずれかが呼び出されたときにテキストが緊急サービスプロバイダーへのコールをルーティングリアルタイムにできる必要があります例えば、米国では「911」と「112」、ヨーロッパで。緊急サービスへのリアルタイムのテキストコールをルーティングは、トランスコーディングサービスを使用する必要があります。
A text gateway with cellular wireless packet-switched services must be able to route real-time text calls to emergency service providers when any of the recognized emergency numbers that support real-time text communication for the country is called.
国のリアルタイムテキスト通信をサポートして認識し、緊急番号のいずれかが呼び出されたときに、セルラー無線パケット交換サービス付きテキストゲートウェイは、緊急サービスプロバイダーへのルートのリアルタイムテキストコールにできなければなりません。
Analog terminal adapters (ATA) using SIP-based IP communication and RJ-11 connectors for connecting traditional PSTN devices SHOULD enable connection of legacy PSTN text telephones [23].
従来のPSTNデバイスを接続するためのSIPベースのIP通信、およびRJ-11コネクタを使用してアナログ端末アダプタ（ATA）はレガシーPSTNテキスト電話の接続を可能にするべきである[23]。
These adapters SHOULD contain V.18 modem functionality, voice handling functionality, and conversion functions to/from SIP-based ToIP with T.140 transported according to RFC 4103 [4], in a similar way as it provides interoperability for voice sessions.
これらのアダプタは、RFC 4103に従って搬送T.140とSIPベースTOIPからの/ V.18モデム機能、音声処理機能、および変換関数を含むべきである[4]、それが音声セッションのための相互運用性を提供するのと同様の方法です。
If a session is set up and text/t140 capability is not declared by the destination endpoint (by the endpoint terminal or the text gateway in the network at the endpoint), a method for invoking a transcoding server SHALL be used. If no such server is available, the signals from the textphone MAY be transmitted in the voice channel as audio with a high quality of service.
セッションが設定され、テキスト/ T140能力は（エンドポイント端末またはエンドポイントのネットワーク内のテキストゲートウェイによって）宛先エンドポイントによって宣言されていない場合、トランスコーディングサーバを呼び出すための方法を使用しなければなりません。そのようなサーバが利用できない場合、textphoneからの信号は、高品質のサービスとオーディオなどの音声チャネルで送信されてもよいです。
NOTE: It is preferred that such analog terminal adaptors do use RFC 4103 [4] on board and thus act as a text gateway. Sending textphone signals over the voice channel is undesirable due to possible filtering and compression and packet loss between the endpoints. This can result in character loss in the textphone conversation or even not allowing the textphones to connect to each other.
注：このようなアナログ端末アダプタボードの[4] RFC 4103を使用し、したがって、テキスト・ゲートウェイとして働くないことが好ましいです。音声チャネルを介しtextphone信号を送信することは可能フィルタと圧縮とエンドポイント間のパケット損失は望ましくありません。これはtextphoneの会話の中で、あるいはtextphonesが相互に接続できるようにない文字の損失につながることができます。
ToIP User Agents SHOULD use the same mechanisms as other SIP User Agents to resolve mobility issues. It is RECOMMENDED that users use a SIP address, resolved by a SIP registrar, to enable basic user mobility. Further mechanisms are defined for all session types for 3G IP multimedia systems.
TOIPユーザエージェントは、モビリティの問題を解決するために、他のSIPユーザーエージェントと同じメカニズムを使用すべきです。ユーザーは、基本的なユーザのモビリティを可能にするために、SIPレジストラによって解決SIPアドレスを、使用することをお勧めします。さらに、メカニズムは、3G IPマルチメディアシステムのためのすべてのセッションタイプのために定義されています。
ToIP uses the same signalling and transport protocols as VoIP. Hence, the same firewall and NAT solutions and network functionality that apply to VoIP MUST also apply to ToIP.
TOIPは、VoIPと同じシグナリングおよびトランスポートプロトコルを使用しています。したがって、VoIPのに適用されるのと同じファイアウォールやNATソリューションやネットワーク機能もTOIPに適用する必要があります。
Where Quality of Service (QoS) mechanisms are used, the real-time text streams should be assigned appropriate QoS characteristics, so that the performance requirements can be met and the real-time text stream is not degraded unfavourably in comparison to voice performance in congested situations.
サービス品質（QoS）のメカニズムが使用されている場合は性能要件を満たすことができると、リアルタイムのテキストストリームは混雑でパフォーマンスを音声と比較して不利に劣化しないように、リアルタイムのテキストストリームは、適切なQoS特性を割り当てる必要があります状況。
User confidentiality and privacy need to be met as described in SIP [2]. For example, nothing should reveal in an obvious way the fact that the ToIP user might be a person with a hearing or speech impairment. It is up to the ToIP user to make his or her hearing or speech impairment public. If a transcoding server is being used, this SHOULD be as transparent as possible. However, it might still be possible to discern that a user might be hearing or speech impaired based on the attributes present in SDP, although the intention is that mainstream users might also choose to use ToIP. Encryption SHOULD be used on an end-to-end or hop-by-hop basis as described in SIP [2] and SRTP [20].
SIP [2]で説明したように、ユーザーの機密性とプライバシーの必要が満たされます。例えば、何も明らかな方法でTOIPのユーザーは聴力や発話障害を持つ人であるかもしれないという事実を明らかにしてはなりません。それは彼または彼女の聴覚や言語障害を公開するTOIPユーザー次第です。トランスコーディングサーバが使用されている場合、これは可能な限り透明であるべきです。意図が主流のユーザもTOIPを使用することを選択するかもしれないということですが、しかし、まだ、ユーザーがSDPに存在する属性に基づいて、聴覚やスピーチ損なわれる可能性があることを識別することは可能かもしれません。暗号化SIPに記載されているように、エンドエンドまたはホップバイホップに基づいて使用されるべきである[2]、SRTP [20]。
Authentication MUST be provided for users in addition to message integrity and access control.
認証は、メッセージの整合性とアクセス制御に加えて、ユーザーに提供されなければなりません。
Protection against Denial-of-Service (DoS) attacks needs to be provided, considering the case that the ToIP users might need transcoding servers.
サービス拒否（DoS）攻撃に対する保護はTOIPのユーザーがトランスコードサーバを必要とするかもしれない場合を考えると、提供される必要があります。
The following people contributed to this document: Willem Dijkstra, Barry Dingle, Gunnar Hellstrom, Radhika R. Roy, Henry Sinnreich, and Gregg C. Vanderheiden.
次の人は、この文書に貢献：ウィレム・ダイクストラ、バリー・ディングル、グンナー・ヘルストローム、ラディカ・R.ロイ、ヘンリーSinnreich、とグレッグC. Vanderheiden。
The content and concepts within are a product of the SIPPING Working Group. Tom Taylor (Nortel) acted as independent reviewer and contributed significantly to the structure and content of this document.
内のコンテンツと概念はSIPPING作業部会の製品です。トム・テイラー（ノーテル）は、独立したレビューを務め、このドキュメントの構造と内容に大きく貢献しました。
[1] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[1]ブラドナーの、S.、エド。、 "IETF技術の知的財産権"、BCP 79、RFC 3979、2005年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[4] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[4]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のためのRTPペイロード"、RFC 4103、2005年6月。
[5] ITU-T Recommendation F.703,"Multimedia Conversational Services", November 2000.
[5] ITU-T勧告F.703、 "マルチメディア会話サービス" を、2000年11月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] 3GPP TS 26.226, "Cellular Text Telephone Modem Description" (CTM).
[7] 3GPP TS 26.226、 "セルラーテキスト電話モデム説明"（CTM）。
[8] ITU-T Recommendation T.140, "Protocol for Multimedia Application Text Conversation" (February 1998) and Addendum 1 (February 2000).
[8] ITU-T勧告T.140、 "マルチメディアアプリケーションのテキストの会話のためのプロトコル"（1998年2月）および補遺1（2000年2月）。
[9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[9]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[10]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[11] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[11]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、 "セッション開始プロトコル（SIP）のための発呼者が設定"、RFC 3841、2004年8月。
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[12]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[13] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", RFC 4117, June 2005.
[13]キャマリロ、G.、バーガー、E.、Schulzrinneと、H.、および "セッション開始プロトコルにおけるトランスコーディングサービス呼び出し（SIP）を使用して第三者呼制御（3PCC）" A.ヴァンWijk、RFC 4117年6月2005。
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[14] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[15] "XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", W3C Recommendation, Available at http://www.w3.org/TR/xhtml1.
[15] "XHTML 1.0：拡張可能ハイパーテキストマークアップ言語：XML 1.0でのHTML 4の再定式化"、W3C勧告、http://www.w3.org/TR/xhtml1で利用可能。
[16] ITU-T Recommendation V.18, "Operational and Interworking Requirements for DCEs operating in Text Telephone Mode", November 2000.
[16] ITU-T勧告V.18、2000年11月「テキスト電話モードで動作しているのDCEの運用とインターワーキング要件」。
[17] TIA/EIA/IS-823-A, "TTY/TDD Extension to TIA/EIA-136-410 Enhanced Full Rate Speech Codec (must used in conjunction with TIA/EIA/IS-840)"
[17] TIA / EIA / IS-823-A、 "TTY / TDD拡張TIAの/ EIA-136から410まで拡張フルレート音声コーデックは（TIA / EIAと一緒に使用しなければならない/ IS-840）"
[18] TIA/EIA/IS-127-2, "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems, Addendum 2."
[18] TIA / EIAは/ IS-127-2、「拡張可変レートコーデック、広帯域スペクトラム拡散デジタルシステムのための音声サービスオプション3、付録2」
[19] "IP Multimedia default codecs", 3GPP TS 26.235
[19] "IPマルチメディア・デフォルト・コーデック"、3GPP TS 26.235
[20] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[20] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[21] ITU-T Recommendation F.700, "Framework Recommendation for Multimedia Services", November 2000.
[21] ITU-T勧告F.700、 "マルチメディアサービスのためのフレームワーク勧告"、2000年11月。
[22] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.
[22]チャールトン、N.、Gasson、M.、Gybels、G.、スパナ、M.、およびA.バンWijk、「セッション開始プロトコル（SIP）のためのユーザ要件ろう、難聴や音声のサポートに-impaired個人」、RFC 3351、2002年8月。
[23] Sinnreich, H., Ed., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006.
[23] Sinnreich、H.、エド。、ラス、S.、およびC. Stredicke、 "SIPテレフォニーデバイスの要件と構成"、RFC 4504、2006年5月。
[24] European Telecommunications Standards Institute (ETSI), "Human Factors (HF); Guidelines for Telecommunication Relay Services for Text Telephones". TR 101 806, June 2000.
[24]欧州電気通信標準化機構（ETSI）、「ヒューマンファクター（HF）;テキスト電話用通信リレーサービスのためのガイドライン」。 TR 101 806、2000年6月。
[25] TIA/EIA/825 "A Frequency Shift Keyed Modem for Use on the Public Switched Telephone Network." (The specification for 45.45 and 50 bit/s TTY modems.)
[25] TIA / EIA / 825「公共の使用のための周波数シフトキー付きモデム交換電話網。」 （45.45及び50ビット/秒TTYモデムの仕様。）
[26] International Telecommunication Union (ITU), "300 bits per second duplex modem standardized for use in the general switched telephone network". ITU-T Recommendation V.21, November 1988.
[26]国際電気通信連合（ITU）、「第二の二本鎖あたりの300ビットは、一般的に使用するための標準モデムは、電話網」。 ITU-T勧告V.21、1988年11月。
[27] International Telecommunication Union (ITU), "600/1200-baud modem standardized for use in the general switched telephone network", ITU-T Recommendation V.23, November 1988.
[27]国際電気通信連合（ITU）、1988年11月、ITU-T勧告V.23 "一般的に使用するために標準化1200分の600ボーモデム交換電話網"。
[28] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol", Work in Progress, May 2006.
[28]カマリロ、G.、「セッション開始プロトコルとトランスコーディングのための枠組み」進行中、仕事、2006年5月。
[29] Camarillo, G., "The SIP Conference Bridge Transcoding Model", Work in Progress, January 2006.
[29]カマリロ、G.、 "SIP Conference Bridgeのトランスコーディングモデル"、進歩、2006年1月の作業。
Authors' Addresses
著者のアドレス
Guido Gybels Department of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK
新技術RNID、19-23フェザーストーンストリートロンドンEC1Y 8SL、英国のグイドGybels部門
Tel +44-20-7294 3713 Txt +44-20-7296 8001 Ext 3713 Fax +44-20-7296 8069 EMail: guido.gybels@rnid.org.uk http://www.ictrnid.org.uk
電話+ 44-20-7294 3713 txtが+ 44-20-7296 8001内線3713ファックス+ 44-20-7296 8069 Eメール：guido.gybels@rnid.org.uk http://www.ictrnid.org.uk
Arnoud A. T. van Wijk Real-Time Text Taskforce (R3TF)
Arnoud A. T.バンWijkリアルタイムテキストタスクフォース（R3TF）
EMail: arnoud@realtimetext.org http://www.realtimetext.org
メールアドレス：arnoud@realtimetext.org http://www.realtimetext.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。