[要約] RFC 5194は、SIPを使用したIP上のリアルタイムテキストのためのフレームワークを提供しています。その目的は、テキストベースのコミュニケーションをリアルタイムでサポートし、通信のアクセシビリティを向上させることです。
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)
セッション開始プロトコル（SIP）を使用したIP上のリアルタイムテキストのフレームワーク
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）に基づいて、必要なすべての関数の実装のフレームワークを定義します。これには、公開された電話ネットワーク（PSTN）およびその他のネットワークでのText-Over-IPと既存のテキストテレフォニーとの相互作用が含まれます。
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.
伝統的に、聴覚障害者、懸命な、音声障害のある人々は、リアルタイム、会話、テキストの最も多作なユーザーの1人ですが、その対話性のために、主流のユーザーの間でも人気になりつつあります。リアルタイムのテキスト会話は、ビデオや声などの他の会話メディアと組み合わせることができます。
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）環境と互換性があるように特別に設計されています。このTOIPフレームワークは、RFC3351 [22]に記載されているように、聴覚障害、困難、音声障害のあるユーザーの高レベルのユーザー要件にも基づいており、互換性があります。また、主流のユーザーのリアルタイムテキスト要件を満たしています。
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].
このドキュメントでは、ToIPを単独で、または統合されたマルチメディアサービスの一部として、Total Conversation [5]のいずれかで使用するフレームワークを定義しています。
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:
このドキュメントでは、レアルタイムTOIPの実装のフレームワークを定義します。それは次のことを提供します：
a. requirements for real-time text;
a. リアルタイムテキストの要件。
b. requirements for ToIP interworking;
b. Interworkingの要件。
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.
キーワード「必須」、「しない」、「必須」、「shall」、「shall」、「obs "of"、 "not"、 "becommended"、 "becommented"、 "may"、 "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.
Cellular：ワイヤレスアクセスを持ち、非常に大きな地理的領域で音声とデータサービスをサポートできる通信ネットワーク。モバイルとも呼ばれます。
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.
半分デュプレックス：メディアは一度に一方向にのみ送信できます。または、両方向に情報を送信しようとすると、提示されたメディアにエラーが導入される場合があります。
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とBaudotまたはITU-T V.21テキストテレフォニーの間で、PSTNのテキストテレフォニーをトランスコードする関数。
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.
テキストフォン：「テキスト電話」も。アナログ伝送を使用したエンドツーエンドのリアルタイムテキスト通信を可能にする端子デバイス。世界中にさまざまなPSTNテキストフォンプロトコルが存在します。多くの場合、テキスト電話は音声電話と組み合わせることができ、通話でテキストと音声の同時または交互の使用のための音声通信機能を含めることができます。
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.
テキストテレフォニー：アナログテキスト電話サービス。
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].)
合計会話：ビデオ、リアルタイムのテキスト、音声でリアルタイムの会話を提供するマルチメディアサービスと相互運用可能な標準に応じて。すべてのメディアストリームはリアルタイムで流れます。（ITU-T F.703、「マルチメディア会話サービス」[5]を参照してください。）
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：もともと、「テレタイプ」の略語。多くの場合、北米ではテキスト電話またはテキスト電話の代替指定として使用されます。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世代セルラー（モバイル）2.5G強化された第2世代セルラー（モバイル）3G第三世代セルラー（モバイル）ATAアナログ電話アダプターCDMAコード分割複数のアクセスCLI通話ライン識別CTMセルラーテキスト電話モデム列RFC3761）を参照してくださいモバイルコミュニケーションのためのGSMグローバルシステムISDN統合サービスデジタルネットワークITU-T International Telecommunications Union-Telecommunications Standardization Standardization Standeration Standeration Nat NetworkアドレスPSTNパブリックスイッチネットワークRTPリアルタイムトランスポートプロトコルSDPセッション説明プロトコルSIPセッション開始プロトコルSRTP聴覚障害のあるTDMAタイムディビジョンのための時間輸送プロトコルTDDテレコミュー化デバイスマルチアクセスTTYアナログテキストポンド（TELETYPEWRITER）TOIP INTERNTERT PROTOCOL URI UNIORITリソース識別子UTF-8 UCS/UNICODE TRASKINGRATION FORMAT-8 VCO/HCO音声キャリーオーバー/ヒアリングインターネットプロトコルを介してVoip Voiceをキャリーします
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は、Voiceによって提供されるものと会話性の観点から同等の機能を提供する必要があります。それを達成するために、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.
e. リアルタイムテキストサービスがいつでも利用できることを確認してください。
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:
耳が聞こえない、困難な、主流のユーザーは、さまざまな理由でサービスを呼び出す場合があります。
- 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：最大遅延要件を満たすことができるように、各文字の入力後すぐにキャラクターを送信する必要があります。1秒のエンドツーエンドの遅延時間は良いと見なされますが、ユーザーは300msまでの短い遅延をメモして評価します。最大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ミリ秒以上遅れないようにします。
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：リアルタイムのテキストを生成するスピーチツーテキストの方法だけでなく、高速な人間のタイピングをサポートするのに十分な速度で文字を送信することが可能である必要があります。1秒あたり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 [4]で説明されているように、1人のユーザーエージェントがIPよりもT.140のみを提供し、もう1つはサポートしているものしかサポートしていない場合オーディオ、ユーザーはトランスコーディングサービスを呼び出すことをお勧めします。
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：利用可能な場合、セッションの招待状が回答される前に、ユーザーに適した形式でユーザーに明確に提出する必要があります。
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：TOIPは、ITU-T T.140 [8]で指定されているセッション中に、新しいライン、消去、アラートなどの文字を処理する必要があります。
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レガシーテキストテレフォニーサービスと相互作用する場合、テキストと音声機能が交互にサポートされる場合があります。（「Voice Carry over（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.
テキストテレフォニーデータを転送する代替手段は、Cellularを介した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.
このセクションでは、要件を満たし、セクション5に記載されている機能を提供するTOIPの実装フレームワークについて説明します。ここで説明するフレームワークは、IPネットワーク上の音声ベースの会話サービスにすでに一般的に使用されている既存の標準を使用します。
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].
このフレームワークは、セッション開始プロトコル（SIP）[2]の使用を指定して、記載されているように、メディアがリアルタイムトランスポートプロトコル（RTP）[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サービスは、セッション開始プロトコル（SIP）[2]を使用して、1人以上の参加者とのリアルタイムテキスト会話のためのセッション、制御、および終了し、ビデオやオーディオなどの他のメディアを含める必要があります。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. ユーザー設定のサーバーサポート：TOIPサービスをサポートするSIPサーバーには、セッションを受け入れるか拒否するために、リアルタイムテキストのユーザー設定を呼び出すことに機能する必要があります。行われたアクションは、セッション前のセットアップ登録の一部として定義された呼び出されたユーザー設定に基づいています。たとえば、ユーザーが別のパーティから呼び出され、トランスコーディングサーバーが必要であると判断された場合、セッションは再監督するか、それに応じて処理する必要があります。
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の場合、通信当事者の一方または両方が、セッションセットアップで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のためのトランスコーディングサーバーの使用）。
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].
SIP [2]で使用されるセッション説明プロトコル（SDP）は、セッションセットアップのメディアとしてリアルタイムテキストを示す機能を提供します。RFC 4103 [4]は、RTPペイロードタイプ「Text/Red」および「Text/T140」を使用して、SIP Invite、OK、およびSIP/ACKメディアの一部としてSDPで示すことができます。交渉。さらに、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サービスは、参加者間のリアルタイムテキストの輸送について、RFC 4103 [4]の仕様に従って、リアルタイムトランスポートプロトコル（RTP）[3]をサポートする必要があります。
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 [4]で指定されているデフォルトの最大レートである送信速度を1秒あたり30文字以下に保持する必要があります。RFC 4103 [4]で指定されている「CPS」パラメーターを介して、必要に応じてより低いレートを交渉することができます。
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
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.
受信セッションにAudible Alerterを使用できないユーザーの場合、視覚的なインジケータだけでなく、触覚を含めることをお勧めします。
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).
バッファリングスキームは、毎秒30文字で受信するように調整し、毎秒6文字で最大4分間（つまり、3000文字未満）送信するように調整する必要があります。
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テキスト電話に接続するために、他のコーディング形式へのテキストのトランスコードと他のコーディング形式との間のゲートウェイと他の形式のテキスト会話の間のゲートウェイで行われる必要がある場合があります。
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 Interworkingには、テキストゲートウェイを呼び出す方法が必要です。これらのテキストゲートウェイは、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.
e. すべての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
g. 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).
h. 独自の電話番号および/またはSIPアドレスを備えたテキストゲートウェイ（これには、ゲートウェイとのユーザーのやり取りが必要です）。
i. ENUM address analysis and number plan.
i. 列挙アドレス分析と数値計画。
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.
アナログテキストの非互換性を解決するには、テキスト電話ゲートウェイが、着信アナログ信号をT.140にトランスコードし、その逆にする必要があります。モデム機能交換時間は、最初にゲートウェイがある地域で使用されているアナログテキスト電話プロトコルを想定して、テキスト電話ゲートウェイによって短縮できます。たとえば、米国では、Baudot [25]が初期プロトコルとして試される可能性があります。Baudotの交渉が失敗した場合、完全な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]、Baudot [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]は、ネイティブテキストテレフォニー方法を提供し、さらに現在のプロトコルとの相互作用を定義しています。インターワーキングモードでは、古いプロトコルの1つを認識し、必要に応じてその伝送方法に戻ります。
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を使用すると、リアルタイムのテキストを同時に受信して送信し、スプリット画面に表示されますが、多くのアナログテキスト電話では、ユーザーが交代する必要があります。これは、多くのテキスト電話が厳密に半二重動作しているためです。一度にテキストを送信できるのは1つだけです。ユーザーは厳格なターンテイキングルールを適用します。
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分割画面も使用できますが、ほとんどすべてのテキスト電話は制限された文字セットを使用し、多くは低いテキスト送信速度（1秒あたり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 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.
そのため、TOIPユーザーがアナログテキスト電話に接続していることを知ることが重要です。セッションの説明[9]には、呼び出しの他のエンドポイントがPSTNテキスト電話（たとえば、ATAまたはテキストゲートウェイを介して接続）であることを示すことを示している必要があります。これは、テキストフォンユーザーが通話中に正式なターンテイクに使用される可能性があることを意味します。
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は、Cellular Wireless Packet-Switchedサービスでサポートされる場合があります。インターネットにインターフェイスします。
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.
「No-Gain」テキスト電話輸送テクノロジーは、テキストテレフォニーコールを提供するために使用されるモバイルターミナルで、特別に変更された強化されたフルレート（EFR）[17]および変動レート（EVR）[18]音声ボコーダーを使用します。完全な二重操作を提供し、音声とテキスト（「VCO/HCO」）を交互にサポートします。これは、CDMAおよびTDMAモバイルテクノロジーと、米国ボード（つまり、45ビット/s）タイプのテキスト電話に専念しています。
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と通信できるようにするセルラー電話モードのために、携帯電話端子サプライヤーによってよく使用されます。したがって、これは、ボード型テキストに適用された場合の「無ゲイン」と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ビット/sのデータレートは、2Gモバイルネットワークでサポートされています。ゲートウェイは、PSTNテキストとの相互運用性を提供します。
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のような文字の連続ストリームではなく、テキストのブロックに基づいているため、ゲートウェイは2つの形式の間にトランスコードする必要があります。インスタントメッセージングとTOIPの間のインターワーキングのためのテキストゲートウェイは、リアルタイムテキストとテキストメッセージングのさまざまな会話形式を橋渡しするための手順を適用する必要があります。以下のアドバイスは、メッセージングゲートウェイを介した電話で両当事者のユーザーエクスペリエンスを改善する可能性があります。
a. Concatenate individual characters originating at the ToIP side into blocks of text.
a. TOIP側で生まれた個々の文字をテキストのブロックに連結します。
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. TOIP側が少なくとも5秒間アイドル状態になった場合、そのポイントまでのすべてのバッファリングされたテキストは、インスタントメッセージング側に送信する必要があります。
e. Text Gateways must be capable of maintaining the real-time performance for ToIP while providing the interworking services.
e. テキストゲートウェイは、インターワーキングサービスを提供しながら、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.
TOIP側では、インスタントメッセージングプロトコルがそれを提供する場合、インスタントメッセージを書き込むインジケーターが存在する必要があります。たとえば、リアルタイムのテキストユーザーには、「。。。」と返信するのを待っている。」と、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スタックは、インスタントメッセージング（シンプル）および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:
コンビネーションゲートウェイは、サポートされているテキストベースの機能のすべての間でインターワーキングを提供できます。たとえば、PSTNとインターワークするモデムがあり、インスタントメッセージングとTOIPの両方をサポートするモデムを備えたテキストゲートウェイは、次のインターワーキング機能をサポートできます。
- PSTN text telephony to ToIP
- PSTNテキストテレフォニーへのToIP
- PSTN text telephony to Instant Messaging
- インスタントメッセージングへのPSTNテキストテレフォニー
- Instant Messaging to 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テキストは、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の間をトランスコードする場合、7ビットコードの全国的なバリエーションに特別な考慮事項を与えなければならず、国家文字はISO 10646コードスペースの異なるコードにマッピングします。使用される国家バリアントは、ユーザーが1コールごとに選択できるか、ゲートウェイの全国的なデフォルトとして構成することができます。
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ビット文字コードで表現することはできません。したがって、欠落したテキストの指標は、このキャラクターが存在するレガシーテキスト電話システムの「（アポストロフィ）文字にトランスコードする必要があります。「キャラクターが存在しないレガシーシステムの場合」（フルストップ）代わりに文字を使用する必要があります。
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 [4]に従って輸送されたT.140を使用して、v.18モデム機能、音声処理機能、およびSIPベースのToIPでの変換機能を含める必要があります。
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機能が宛先エンドポイント（エンドポイント端子またはエンドポイントのネットワークのテキストゲートウェイによって）によって宣言されない場合、トランスコーディングサーバーを呼び出す方法を使用します。そのようなサーバーが利用できない場合、テキストフォンからの信号は、高品質のサービスを備えた音声チャネルに送信される場合があります。
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.
注：このようなアナログ端子アダプターは、船内でRFC 4103 [4]を使用し、テキストゲートウェイとして機能することが推奨されます。音声チャネル上でテキスト電話信号を送信することは、エンドポイント間のフィルタリングと圧縮の可能性とパケットの損失のために望ましくありません。これにより、テキストフォンの会話でキャラクターが喪失したり、テキストフォンが互いに接続したりすることもできなくなります。
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ユーザーは、聴覚または言語障害を一般に公開することです。トランスコーディングサーバーが使用されている場合、これは可能な限り透過的でなければなりません。ただし、主流のユーザーも使用することを選択する可能性があるという意図は、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.
TOIPユーザーがトランスコーディングサーバーが必要になる可能性がある場合を考慮して、サービス拒否（DOS）攻撃に対する保護を提供する必要があります。
The following people contributed to this document: Willem Dijkstra, Barry Dingle, Gunnar Hellstrom, Radhika R. Roy, Henry Sinnreich, and Gregg C. Vanderheiden.
次の人々がこの文書に貢献しました：ウィレム・ディクストラ、バリー・ディングル、グンナー・ヘルストロム、ラディカ・R・ロイ、ヘンリー・シン・レイヒ、グレッグ・C・ヴァンダーハイデン。
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.
内部のコンテンツと概念は、すすりながらワーキンググループの製品です。Tom Taylor（Nortel）は独立したレビュアーとして行動し、この文書の構造と内容に大きく貢献しました。
[1] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[1] Bradner、S.、ed。、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[4] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[4] Hellstrom、G。およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、2005年6月。
[5] ITU-T Recommendation F.703,"Multimedia Conversational Services", November 2000.
[5]
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[11] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[11] Rosenberg、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[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] Camarillo、G.、Burger、E.、Schulzrinne、H。、およびA. Van Wijk、「サードパーティコールコントロール（3PCC）を使用したセッション開始プロトコル（SIP）のトランスコーディングサービスの呼び出し」、RFC 4117、2005年6月。
[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、「テキスト電話モードで動作するDCEの運用およびインターワーキング要件」、2000年11月。
[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.、McGrew、D.、Naslund、M.、Carrara、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] Charlton、N.、Gasson、M.、Gybels、G.、Spanner、M。、およびA. Van Wijk、「聴覚障害、聴覚障害、言語障害者をサポートするセッション開始プロトコル（SIP）のユーザー要件"、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.、ed。、Lass、S。、およびC. Stredicke、「SIP Telephony Device要件と構成」、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ビット/s 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] International Telecommunication Union（ITU）、「一般的な切り替えの電話ネットワークで使用するために標準化された1秒あたり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] International Telecommunication Union（ITU）、「一般的な切り替えの電話網で使用するために標準化された600/1200-ボーモデム」、ITU-T勧告V.23、1988年11月。
[28] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol", Work in Progress, May 2006.
[28] Camarillo、G。、「セッション開始プロトコルを使用したトランスコーディングのフレームワーク」、2006年5月、進行中の作業。
[29] Camarillo, G., "The SIP Conference Bridge Transcoding Model", Work in Progress, January 2006.
[29] Camarillo、G。、「The SIP Conference Bridge Transcoding Model」、2006年1月、進行中の作業。
Authors' Addresses
著者のアドレス
Guido Gybels Department of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK
Guido Gybels New Technologies Rnid、19-23 Featherstone Street London EC1Y 8SL、英国
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
Tel 44-20-7294 3713 TXT 44-20-7296 8001 EXT 3713 FAX 44-20-7296 8069メール：guido.gybels@rnid.org.uk http://www.ictrnid.org.uk
Arnoud A. T. van Wijk Real-Time Text Taskforce (R3TF)
Arnoud A. T. Van Wijkリアルタイムテキストタスクフォース（R3TF）
EMail: arnoud@realtimetext.org
http://www.realtimetext.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。