RFC5194 日本語訳
5194 Framework for Real-Time Text over IP Using the Session InitiationProtocol (SIP). A. van Wijk, Ed., G. Gybels, Ed.. June 2008. (Format: TXT=68636 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. van Wijk, Ed. Request for Comments: 5194 G. Gybels, Ed. Category: Informational June 2008
作業部会のA.バンウェイク、エドをネットワークでつないでください。Commentsのために以下を要求してください。 エド5194G.Gybels、カテゴリ: 情報の2008年6月
Framework for Real-Time Text over IP Using
the Session Initiation Protocol (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.
このドキュメントは、リアルタイムのText過剰IP(ToIP)のために必須の条件をリストアップして、Session Initiationプロトコル(SIP)とレアル-時間Transportプロトコル(RTP)に基づくすべての必要な機能の実装のためにフレームワークを定義します。 これは、Public Switched Telephone Network(PSTN)と他のネットワークのText過剰IPと既存のテキスト電話の間に織り込むのを含んでいます。
van Wijk & Gybels Informational [Page 1] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[1ページ]RFC5194Framework
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
1. 序論…3 2. 範囲…4 3. 用語…4 4. 定義…4 5. 要件…6 5.1. ToIPのための一般要件…6 5.2. ToIPのための要件を詳しく述べます…8 5.2.1. セッションセットアップとコントロール要件…9 5.2.2. 要件を輸送してください…10 5.2.3. コード変換サービス要件…10 5.2.4. プレゼンテーションとユーザは要件を制御します…11 5.2.5. 要件を織り込みます…13 5.2.5.1. 要件を織り込むPSTN…13 5.2.5.2. セル織り込む要件…14 5.2.5.3. 要件を織り込むインスタントメッセージング…14 6. 実装フレームワーク…15 6.1. 一般実装フレームワーク…15 6.2. 詳細な実装フレームワーク…15 6.2.1. セッション制御とセットアップ…15 6.2.1.1. プレセッションセットアップ…15 6.2.1.2. セッション交渉…16 6.2.2. 輸送…17 6.2.3. コード変換サービス…18 6.2.4. プレゼンテーションとユーザコントロールは機能します…18 6.2.4.1. 進歩と状態情報…18 6.2.4.2. 警告します。18 6.2.4.3. テキストプレゼンテーション…19 6.2.4.4. ストレージをファイルしてください…19 6.2.5. 織り込むことは機能します…19 6.2.5.1. PSTNの織り込むこと…20 6.2.5.2. モバイル織り込むこと…22 6.2.5.2.1. セル「利得がありません」…22 6.2.5.2.2. セルテキスト電話モデム(CTM)…22 6.2.5.2.3. セル「Baudotモード」…22 6.2.5.2.4. モバイルデータはモードを向けます…23 6.2.5.2.5. モバイルToIP…23 6.2.5.3. インスタントメッセージングの織り込むこと…23 6.2.5.4. 多機能組み合わせゲートウェイ…24 6.2.5.5. 文字コードコード変換…25 7. Implementersとサービスプロバイダーには、より遠い推薦…25 7.1. 緊急サービスへのアクセス…25 7.2. ホームゲートウェイかアナログティーエー…25 7.3. ユーザの移動性…26
van Wijk & Gybels Informational [Page 2] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[2ページ]RFC5194Framework
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
7.4. ファイアウォールとNATs…26 7.5. サービスの品質…26 8. セキュリティ問題…26 9. 貢献者…27 10. 参照…27 10.1. 標準の参照…27 10.2. 有益な参照…29
1. Introduction
1. 序論
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.
何年間も、リアルタイムのテキストは会話の、そして、対話的な対話のための同様の方法で音声電話技術がどう使用されているかへのユーザの間の媒体として使用中です。 そのような対話的なテキストはInstant Messagingのようなメッセージングと準インタラクティブソリューションとそうしたくないか、またはそうしたがっていないユーザに同等な会話の経験を提供するという点において異なっていて、使用は声です。 したがって、それは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.
このドキュメントはText過剰IPソリューションが(ToIP)であると実装するのにどう既存のIETFプロトコルを使用できるかを説明します。 したがって、このドキュメントは、1セットの既存のコンポーネントとプロトコルを使用する方法を説明して、そんなに結果として起こる構造に要件と規則を供給します(それが「フレームワーク」と呼ばれる理由です)、その用語の一般的に受け入れられた辞書の定義に合って。
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フレームワークは、Voice-over-IP(VoIP)、Video過剰IP、およびMultimedia過剰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.
Session Initiationプロトコル(SIP)[2]は特にMultimediaコミュニケーションとVoice-over-IP(VoIP)のコントロールのための選択のプロトコルです。 それはすべての必要なコントロールを提供します、そして、合図がToIPフレームワークに必要です。
van Wijk & Gybels Informational [Page 3] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[3ページ]RFC5194Framework
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].
レアル-時間Transportプロトコル(RTP)[3]はリアルタイムのデータ伝送のための選択のプロトコルです、そして、リアルタイムのテキストペイロードの使用はRFC4103[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]を含んでいて。
2. Scope
2. 範囲
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の実装のためのフレームワークを定義するか、またはマルチメディアサービスの一部としてそうします、Total Conversation[5]を含んでいて。 それが提供される、:
a. requirements for real-time text;
リアルタイムのテキストのためのa.要件。
b. requirements for ToIP interworking;
ToIPの織り込むb.要件。
c. description of ToIP implementation using SIP and RTP;
c. SIPとRTPを使用するToIP実装の記述。
d. description of ToIP interworking with other text services.
d. 他のテキストでサービスを織り込むToIPの記述。
3. Terminology
3. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[6]について説明して、対応する実装のために要件レベルを示すとき本書では解釈されることであるべきですか?
4. Definitions
4. 定義
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レベルでは、これはRFC3550[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.
半二重: 一度に、メディアを一方向に送ることができるだけですか、または両方の方向による情報を送る試みをするなら、提示されたメディアに誤りを取り入れるかもしれません。
van Wijk & Gybels Informational [Page 4] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[4ページ]RFC5194Framework
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].
リアルタイムのテキスト: キャラクタごとの会話のサービスにおける使用のためのファッションにおける、テキストのリアルタイムの送信と、そして、しばしば声のベースの会話のサービスに同等なテキストとした用語。 Recommendation F.700[21]、会話のテキストはマルチメディアサービスのためにITU-T Frameworkで定義されます。
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の間のテキスト輸送メソッドか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].)
会話を合計してください: 共同利用できる規格に応じてビデオ、リアルタイムのテキスト、および声でリアルタイムの会話を提供するマルチメディアサービス。 すべてのメディアストリームがリアルタイムで、流れます。 (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.
コード変換サービス: サービスは、第三者Userエージェントで「移-コード」1が別のものに流れるのを前提としました。 人間のオペレータ、自動化された方法、または両方のメソッドの組み合わせでコード変換ができます。 このドキュメントの中では、用語は特に異なったタイプのメディアの間の変換に適用します。 テキストリレーサービスはリアルタイムのテキストとオーディオの間で変換されるコード変換サービスの例です。
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のための代替の名称として北アメリカでしばしば使用されています。 また、DeafのためにTDD、Telecommunication Deviceと呼ばれます。
van Wijk & Gybels Informational [Page 5] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[5ページ]RFC5194Framework
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 Enhanced二世セル(モバイル)の3G Third二世世代のセル(モバイル)のATA Analog Telephone Adaptor CDMA符号分割多重アクセス方式CLI Calling線Identification CTM Cellular Text Telephone Modem ENUM E; 164 国際DNS(RFC3761を見る)のTransportプロトコルSDP Session記述プロトコルGSM汎欧州デジタルセルラーシステムISDN Integrated Services Digital Network ITU-T Telecommunications Union-テレコミュニケーションStandardisation Sector NAT Network Address Translation PSTN Public Switched Telephone Network RTPレアル-時間SIP Sessionでの数のストレージ; インターネットプロトコルの上のインターネットプロトコルURI Uniform Resource Identifier UTF-8 UCS/ユニコードTransformation Format-8VCO/HCO Voice Carry Over/公聴会Carry Over VoIP Voiceの上のDeaf TDMA Time事業部Multiple Access TTY Analog textphone(テレタイプ)ToIPレアル-時間Textのための開始プロトコルSRTP SecureレアルTime TransportプロトコルTDD Telecommunication Device
5. Requirements
5. 要件
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で説明されたフレームワークは声のベースの電話のテキスト同等物であるリアルタイムのテキストベースの会話のサービスを定義します。 このセクションはフレームワークが会うように設計されているという要件とそれが提供するべきである機能性について説明します。
5.1. General Requirements for ToIP
5.1. ToIPのための一般要件
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.
RFC3351[22]の要件からToIPのためのどんなフレームワークも得なければなりません。 基本的な要件は聴覚障害の、そして、耳が遠くて、スピーチによって損なわれて、主流のユーザが音声電話技術と同等物として利用できるリアルタイムのテキストベースの会話のサービスを提供するのに標準化された道で提供しなければならないということです。
van Wijk & Gybels Informational [Page 6] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[6ページ]RFC5194Framework
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.
リアルタイムのテキストの会話がメールやInstant Messagingのような他のテキストベースの通信とかなり異なっているのを理解しているのは重要です。 リアルタイムのテキストの会話はそれが入られるのでキャラクタによるテキストキャラクタの遺伝を提供することによって、同等なモードを声の会話に提供します、密接に会話に続くことができて、その即座の相互作用が起こるように。
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.
モバイルネットワークに関するメールかメッセージング、またはインスタントメッセージングのような非ストリーミングのシステムがその機能性を提供できないように、システムを保存して、進めてください。 特に、彼らは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.
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]で定義されるようにTotal Conversationの役に立つ部分集合です。 総Conversationは関係者に会話の間、同時間かモードを切り換えることによって、コミュニケーションの複数のモードを使用させます、例えば、リアルタイムのテキストとオーディオの間で。
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;
- テキスト、そして/または、スピーチを実装するために、録音は法的な目的、明快、または柔軟性のための(例えば、テキストドキュメンテーション/録音)を修理します。
van Wijk & Gybels Informational [Page 7] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[7ページ]RFC5194Framework
- 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ユーザを召集したいか、数人のユーザにかかわる会議の話し合いに参加したいか、開始したいか、または参加したがっているかもしれません、Total Conversationセッションのように。
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.
多点のリアルタイムのテキストのための共通したシナリオは多くの関係者と共に電話をする会議です。 Implementersは例えば、異なった関係者のテキストを表す異なった色を使用できたか、または各関係者のために別々の窓かレンダリング領域を作成できました。
5.2. Detailed Requirements for ToIP
5.2. ToIPのための詳細な要件
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(実装Framework)は既存のプロトコルとテクニックを使用することによってこれらの要件に基づくToIPを実装する方法を説明します。
The requirements are organized under the following headings:
要件は以下の見出しの下で組織化されます:
- session setup and session control;
- セッションセットアップとセッション制御。
- transport;
- 輸送。
- use of transcoding services;
- コード変換サービスの使用。
- presentation and user control;
- プレゼンテーションとユーザコントロール。
- interworking.
- 織り込みます。
van Wijk & Gybels Informational [Page 8] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[8ページ]RFC5194Framework
5.2.1. Session Setup and Control Requirements
5.2.1. セッションセットアップとコントロール要件
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: それ、SHOULD、どんなモード(本物時間テキスト、声、ビデオ)でも会話かモードの組み合わせを始めるのにおいて、可能であってください。
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: SHOULDがユーザが示した代替手段へ後ろへ下がる能力で各方向へのコミュニケーションの最もよく使われる方法をユーザを指定させるシステムは許容できます。
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: 規制のために、ユーザがリアルタイムのテキストとオーディオの同時の使用を要求して、それがユーザがその人の好みとして指定したことであり、これがネットワークで可能でないなら、システムSHOULDはテキストのみコミュニケーションを確立しようとします。
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: 様式のセッションセットアップと交渉で、ユーザは、使用されるためにリアルタイムのテキストの言語を指定できなければなりません。 (すなわち、使用される手話を指定するために会話のビデオ部分に同様の機能性を提供するのは、RECOMMENDEDです。)
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: 確かであるところでは、セッション・サービスがセッションのオーディオメディア部分に利用可能である、また、同じセッションのリアルタイムのテキストメディア部分にこれらの機能をサポートしなければなりません。 例えば、呼び出し転送はセッションのときにすべてのメディアに影響しなければなりません。
van Wijk & Gybels Informational [Page 9] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[9ページ]RFC5194Framework
5.2.2. Transport Requirements
5.2.2. 輸送要件
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]にアクセスするのにしばしば使用されるでしょう。 リレーサービス、およびユーザからユーザとのダイレクト会話では、彼らに入った後にできるだけ早くテキストキャラクタを送るのは重要です。 バッファリングが完了しているかもしれない間、効率、遅れSHOULDを改良するには、最小量に保たれてください。 特に、テキストの全体の系列のバッファリングはキャラクタ遅れ必要条件を満たさないでしょう。
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.Aまで、最大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: 端末のSHALLからのリアルタイムのテキスト伝送が入られるようにキャラクタであるごとに実行される、または小さいところで分類されるので、キャラクタ、キャラクタは全く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: それがどこで可能であるか、そして、損失か不正である、輸送SHOULDの間のリアルタイムのテキストでは、検出されてください。そうすれば、ユーザは知識があるべきです。
R15: Transport of real-time text SHOULD be as robust as possible, so as to minimize loss of characters.
R15: 輸送、リアルタイムのテキストSHOULDでは、キャラクタの損失を最小にするためにできるだけ強健であってください。
R16: It SHOULD be possible to send and receive real-time text simultaneously.
R16: SHOULDは発信するのにおいて可能であり、リアルタイムで状態で受信します。それ、同時のテキスト。
5.2.3. Transcoding Service Requirements
5.2.3. コード変換サービス要件
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.
異なった関係者のUserエージェントが、IPの上に、あるメディアタイプ、例えばT.140を提供するだけである1人のUserエージェントをサポートする彼らの能力の間には、不一致があるのを示すなら、ユーザはRFC4103[4]、およびオーディオを支えるだけであるもう片方で説明されるようにコード変換サービスを呼び出したがっているかもしれません。
Some users may indicate their preferred modality to be audio while others may indicate real-time text. In this case, transcoding
ユーザの中には彼らの都合のよい様式がオーディオが他のものである間、リアルタイムのテキストを示すかもしれないということであることを示す人もいるかもしれません。 この場合コード変換
van Wijk & Gybels Informational [Page 10] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[10ページ]RFC5194Framework
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].
RFC3351[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: 接続におけるコード変換サービスを持っているユーザの知覚が有の直接効果に制限されて、テキストリレーサービスの追加か取り外し、および変化の効果が続けることのようになったべきであった後にSHOULDが続けている終わりの関係者のコミュニケーション。
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: セッションをセットアップするとき、ユーザがサービスが要求したリレー(例えば、テキストへのスピーチかスピーチへのテキスト)のタイプを指定するのは、可能であるに違いありません。 一種のリレーSHOULDの仕様は言語特許説明書の作成書を含んでいます。
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: それ、SHOULD、都合のよいリレーサービスにセッションを発送するのにおいて、ユーザが通常、使用されるそれより別の領域かネットワークからのセッションを呼び出しても、可能であってください。
R24: It is RECOMMENDED that ToIP implementations make the invocation and use of relay services as easy as possible.
R24: ToIP実装でリレーサービスの実施と使用ができるだけ簡単になるのは、RECOMMENDEDです。
5.2.4. Presentation and User Control Requirements
5.2.4. プレゼンテーションとユーザコントロール要件
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.
ユーザはそうセッションの状態に関する疑問で決しているべきではありません、ユーザがオーディオの、または、視覚の指示を利用できないでも。 例えば、耳と目が不自由な個人は触覚の指摘を使用できました。
van Wijk & Gybels Informational [Page 11] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[11ページ]RFC5194Framework
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: リアルタイムのテキストが他のメディアに関連して使用されるところでは、User Interfaceを通したユーザコントロール機能の暴露は、メディアであるとサポートされたすべてのために同等な方法でする必要があります。 例えば、ユーザがオーディオの、または、視覚の、または、触覚のプロンプトの間で選択するのにおいてそれが可能であるに違いありませんか、またはすべてを供給しなければなりません。
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: 利用可能であるなら、セッション招待が答えられるユーザBEFOREに適当なフォームに明確に起因するパーティー(例えば、URIかCalling線Identification(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: このSHOULDはToIPにかかわるセッション招待状がいつPublic Switched Telephone Network(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: リアルタイムのテキストが呼び出しの間利用可能であるときに、指示SHOULDをユーザに与えて、それが呼び出しで呼び出されないでも、セットアップしてください(例えば、声、そして/または、ビデオだけが初めは、いつ使用されますか)。
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 SHOULDのシステムは電話ネットワークで留守番電話に同等な留守番電話機能をサポートします。
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のキャラクタのメッセージストレージであるとサポートしなければなりません。 システムが1メッセージあたり最大16000のキャラクタに関する少なくとも20の入力メッセージのストレージをサポートするのは、RECOMMENDEDです。
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: 留守番電話が活性であるときに、ユーザ警告SHOULDはまだ行われています。 ユーザSHOULDがこれが提供されるところで自動答え進歩をモニターできて、ユーザSHOULDは留守番電話手順のどんなステージの間も、介入するのが許容されていて、セッションを制御します。
van Wijk & Gybels Informational [Page 12] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[12ページ]RFC5194Framework
R35: It SHOULD be possible to save the text portion of a conversation.
R35: それ、SHOULD、会話のテキスト部分を節約するのにおいて、可能であってください。
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: プレゼンテーション、会話SHOULDでは、ユーザが容易にテキストのどんな当然のことの部分であるとも生成されたどのパーティーを特定できるかような方法でしてください。
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 SHOULDはITU-T T.140[8]の指定されるとしてのセッションの間の復帰改行や、消去や、警告などのキャラクタを扱います。
5.2.5. Interworking Requirements
5.2.5. 要件を織り込みます。
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 SHOULDは他のネットワーク、例えば、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サービスSHOULDは様式の交互の、または、同時の使用のための機能性をサポートします。
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サービスSHOULDは、伝送速度は呼び出しセットアップの遅れと中の違いを取扱って、半二重サービスで織り込むメカニズムをバッファリングしながら、提供します。
5.2.5.1. PSTN Interworking Requirements
5.2.5.1. 要件を織り込むPSTN
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: PSTNと共にレガシーテキストが電話デバイスであると織り込んで、ToIPサービスは提供されなければなりません。
van Wijk & Gybels Informational [Page 13] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[13ページ]RFC5194Framework
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)る」と呼ばれます。)
5.2.5.2. Cellular Interworking Requirements
5.2.5.2. セル織り込む要件
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) Cellular Text Telephony Modem(CTM)ソリューション[7]、両方が米国に「Baudotモード」をまとめてソリューションと呼びました。
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: モバイルテキストで会話がサービスであると織り込むSHOULDが提供するToIPサービス。
5.2.5.3. Instant Messaging Interworking Requirements
5.2.5.3. 要件を織り込むインスタントメッセージング
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].
多くの人々が、インターネットを通ってテキストを使用することで交信するのにInstant Messagingを使用します。 通常、即時のMessagingはそのままで流れるよりむしろToIPによって使用されたテキストのブロックを移します。 通常、特定の動作はトランスミッションを起動するためにユーザによって必要とされます、ENTERキーか発信ボタンを押すのなどように。 そういうものとして、それはToIPへの交換ではありません。 特に、聴覚障害のものを含むリアルタイムの会話のために需要を満たしません、耳が遠く、スピーチはRFC3351[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: Instant Messagingと共にサービスを織り込んで、ToIPサービスは提供されるかもしれません。
van Wijk & Gybels Informational [Page 14] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[14ページ]RFC5194Framework
6. Implementation Framework
6. 実装フレームワーク
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.
このセクションは、条件を満たすToIPのために実装フレームワークについて説明して、セクション5を始められるように機能性を提供します。 ここに提示されたフレームワークは声のベースの会話のサービスにIPネットワークで既に一般的に使用される既存の規格を使用します。
6.1. General Implementation Framework
6.1. 一般実装フレームワーク
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].
このフレームワークはセットアップするためにSession Initiationプロトコル(SIP)[2]の使用を指定します、コントロール、そして、ToIPユーザの間の接続の下側への裂け目が、メディアである間、[3] RFC4103[4]で説明されるようにレアル-時間Transportプロトコル(RTP)を使用することで輸送されます。
RFC 4504 describes how to implement support for real-time text in SIP telephony devices [23].
RFC4504はSIP電話デバイス[23]のリアルタイムのテキストのサポートを実装する方法を説明します。
6.2. Detailed Implementation Framework
6.2. 詳細な実装フレームワーク
6.2.1. Session Control and Setup
6.2.1. セッション制御とセットアップ
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人以上の関係者とのリアルタイムのテキストの会話とことによるとビデオやオーディオのような他のメディアを含むのにセットアップするためのSession Initiationプロトコル(SIP)[2]、制御、および終わりセッションを使用しなければなりません。 セッションについて説明するのにSIPで使用されるSession記述プロトコル(SDP)は、セッションの属性を言い表して、1セットのコンパチブルメディアタイプを交渉するのに使用されます。
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のテクニックの応用でも会話セッションをセットアップする能力を提供できます。
6.2.1.1. Pre-Session Setup
6.2.1.1. プレセッションセットアップ
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:
ユーザは登録時間コミュニケーションの媒体としてリアルタイムのテキストを使用する必要性を述べることができます。 2つの状況が、プレセッションセットアップ環境で考えられる必要があります:
van Wijk & Gybels Informational [Page 15] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[15ページ]RFC5194Framework
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.
a。 ユーザー選択: ユーザが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、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ヘッダー(例えば、Contact)[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 Userエージェントによって扱われる必要であるかどうかを示す明確なルールを定式化できます。
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サーバが入って来るセッションを扱うのは、RECOMMENDEDです。 また、SIPサーバはコミュニケーション(例えば、コード変換サーバのToIPの使用)のためにToIP政策ルールを実施できます。
6.2.1.2. Session Negotiations
6.2.1.2. セッション交渉
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
SIP[2]で使用されるSession記述プロトコル(SDP)は媒体としてセッションセットアップでリアルタイムのテキストを示す能力を提供します。 RFC4103[4]はToIPのサポートにRTPペイロードタイプ「テキスト/赤」と「テキスト/t140」を使用します。(SIP INVITE、OKとSIP/200/ACKメディア交渉の一部としてSDPでToIPを示すことができます)。 コネ
van Wijk & Gybels Informational [Page 16] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[16ページ]RFC5194Framework
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の申し出/答えモデル[12]を使用できます、コード変換サーバの高められたセッション交渉[28、29、13]の使用を含んでいて。
6.2.2. Transport
6.2.2. 輸送
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サービスは、関係者の間のリアルタイムのテキストの輸送のためのRFC4103[4]の仕様通りにレアル-時間Transportプロトコル(RTP)が[3]であるとサポートしなければなりません。
RFC 4103 describes the transmission of T.140 [8] real-time text on IP networks.
RFC4103は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.
国際的な人物の使用を可能にして、セット、トランスミッションはUTF-8が[14]であったならリアルタイムのテキストの会話のためにSHALLをフォーマットします、ITU-T T.140によると。
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].
リアルタイムのテキストがトランスミッションの後にそこでなくなるように検出される、SHOULD、T.140 Addendum1[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.
冗長メソッド、RFC4103[4]SHOULDに、使用されて、リアルタイムのテキスト伝送の信頼性をかなり増強してください。 したがって、2世代を費やす冗長レベルは、強く非常に信頼できる結果を与えて、あります。RECOMMENDED。
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].
送付者、受信機、またはネットワーク(混雑)、通信速度SHOULDの能力を超えているのを避けるには、キャラクタにおいて、または、最高率がRFC4103[4]で指定したデフォルトである1秒あたり30のキャラクタの下で保たれてください。 RFC4103[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
テキスト11000RTP/AVP100 98m=a=rtpmap: 98t140/1000 a=rtpmap: 100赤/1000a=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セッション制御環境で定義されたリアルタイムのテキストのこの単一のコード化とトランスミッション体系を持っていることによって、相互運用性の機会は最適化されています。 しかしながら、もっともな理由が存在しているなら、適切な交渉を導入しますが、デフォルトと後退輸送の両方としてRFC4103[4]輸送を使用しなければならなければ、T.140のコード化されたテキストに他の移送機構を提供して、使用するかもしれません。
van Wijk & Gybels Informational [Page 17] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[17ページ]RFC5194Framework
6.2.3. Transcoding Services
6.2.3. コード変換サービス
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実装SHOULDはこのコード変換フレームワークをサポートします。
6.2.4. Presentation and User Control Functions
6.2.4. プレゼンテーションとユーザコントロール機能
6.2.4.1. Progress and Status Information
6.2.4.1. 進歩と状態情報
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.
セッション進歩情報SHOULDは、できるだけ多くのユーザがそれを理解できるように、簡単な言語を使用します。 使用、専門用語かあいまいな用語SHOULDでは、避けられてください。 テキスト情報がセッション進歩情報を象徴するのにアイコンと共に使用されるのは、RECOMMENDEDです。
In summary, it SHOULD be possible to observe indicators about:
概要でそれ、SHOULD、以下に関してインディケータを観測するのにおいて、可能であってください。
- 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
- タイプされて伝えられたリアルタイムのテキスト
6.2.4.2. Alerting
6.2.4.2. 警告
For users who cannot use the audible alerter for incoming sessions, it is RECOMMENDED to include a tactile, as well as a visual, indicator.
入って来るセッションに聞きとれるalerterを使用できないユーザにとってそれは触覚であることでaを含むRECOMMENDEDです、展示と同様に、インディケータ。
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.
警告オプションの中に、UserエージェントのUser Interfaceによる警告とUserエージェントが主なUserエージェントと同じ記録係に登録した特定の警告があります。
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個の導体の間の接触閉鎖です。
van Wijk & Gybels Informational [Page 18] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[18ページ]RFC5194Framework
6.2.4.3. Text Presentation
6.2.4.3. テキスト提示
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は、ユーザがテキストの会話のディスプレイで容易に異なったスピーカーを見分けることができなければならないと述べます。 これは色を使用し終わることができました、テキスト(異なったディスプレイ領域のすなわち、入って来るリアルタイムのテキストと外向的なリアルタイムのテキスト)、バンドにおける、パーティーに関する識別子、またはこれらのテクニックのどれかの組み合わせが置かれて。
6.2.4.4. File Storage
6.2.4.4. ファイル記憶装置
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システムでテキストが会話であると保存することができることを勧めます。 このSHOULD、標準ファイル形式を使用し終わってください。 例えば: タイムスタンプ、パーティー名(または、アドレス)、および会話テキストを含むXHTML形式[15]におけるUTF-8テキストファイル。
6.2.5. Interworking Functions
6.2.5. 機能を織り込みます。
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.
半二重と全二重プロトコルと、そして、異なったデータ信号速度を持っているプロトコルの間のInteroperationはテキストバッファリングを必要とするかもしれません。 何らかの知性が、半二重モードで作動するとき、いつ方向を変えるかを決定するのに必要でしょう。 半二重操作は「ユーザ」レベル(すなわち、ユーザは互いに知らせなければならない)において、または、「プロトコル」レベル(ゲートウェイを指示に送り返さなければならないところ)において識別に要求されるかもしれません。 しかしながら、特別な注意は、可能な限り良いリアルタイムの性能を提供するために取られる必要があります。
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のキャラクタで受信するために適応するためにdimensionedされて、4まで1秒あたり6つのキャラクタを伝わるバッファリング方式SHOULDが(すなわち、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ユーザが同時にオーディオとテキストの両方を伝えるなら、闘争は起こることができます。 そのような状況で、テキスト伝送SHOULDには先行があるので、テキストは伝えられますが、オーディオは無くなっています。
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と他の用紙の間のゲートウェイで行われる必要があるかもしれません。
van Wijk & Gybels Informational [Page 19] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[19ページ]RFC5194Framework
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のUserエージェントは面があるとき、これらのテキストゲートウェイが作動します。 呼び出しの間のゲートウェイの能力はゲートウェイを使用している端末の呼び出し能力で決定するでしょう。 例えば、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。 ウェブで電話をして、ここで説明されたメソッドの1つを使用します。
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。 ENUMアドレス分析と数は計画されています。
j. Number or address analysis leads to a gateway for all PSTN calls.
j。 数かアドレス分析がすべてのPSTN呼び出しのためのゲートウェイに通じます。
6.2.5.1. PSTN Interworking
6.2.5.1. 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]に記録されました。(また、V.18は異なったテキストプロトコルのためにモデム検出系列を定義します)。 たまには、ユーザ動作によって、モデムタイプ確認はかなりの時間がかかるかもしれません。
van Wijk & Gybels Informational [Page 20] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[20ページ]RFC5194Framework
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への「移-コード」の入って来るアナログ信号に必要です。 初めはゲートウェイが位置している領域で使用されるアナログのテキスト電話プロトコルを仮定するテキスト電話ゲートウェイはモデム能力交換時間を短縮できます。 例えば、米国では、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]規格を使用しなければなりません。 テキストゲートウェイは、SIP UserエージェントとしてIP側に務めて、RFC4103がリアルタイムのテキスト輸送であるとサポートしなければなりません。
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分裂スクリーンを使用するかもしれませんが、多くが低テキスト伝送速度(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
それはToIPユーザが、その人がアナログのテキスト電話に接続されるのを知るのが、重要である理由です。 セッション記述[9]SHOULDが指示を含んでいる、それ、呼び出しのためのもう片方の終点
van Wijk & Gybels Informational [Page 21] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[21ページ]RFC5194Framework
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.
PSTN textphone(例えば、ATAを通してテキストゲートウェイを通して接続される)はそうですか? これは、textphoneユーザが呼び出しの間に取る正式な回転に慣れるかもしれないことを意味します。
6.2.5.2. Mobile Interworking
6.2.5.2. モバイル織り込むこと
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.
以下のセクションはモバイルテキスト電話がどう支えられるかを説明します。
6.2.5.2.1. Cellular "No-gain"
6.2.5.2.1. セル「利得がありません」
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.
技術を輸送する「利得がありません」テキスト電話は特に、変更されたEnhanced Full Rate(EFR)[17]を使用します、そして、テキスト電話を提供するのに使用される移動体端末のEnhanced Variable Rate(EVR)[18]スピーチボコーダは呼びます。 それは、声の間を行き来して、テキストが("VCO/HCO")であると全二重操作を前提として、サポートします。 それはテキスト電話のCDMA、TDMAのモバイル技術、および米国Baudot(すなわち、45ビット/s)タイプに捧げられます。
6.2.5.2.2. Cellular Text Telephone Modem (CTM)
6.2.5.2.2. セルテキスト電話モデム(CTM)
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キャラクタ/秒のときに多くの音声コーデックで運ぶことができるモデム信号を使用することでテキスト電話キャラクタの輸送を提供して、損失を変える色あせとセルに打ち勝つのに非常に余分なコード化のテクニックを使用する技術から独立しているモデム技術です。
6.2.5.2.3. Cellular "Baudot mode"
6.2.5.2.3. セル「Baudotモード」
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.
今期はTTYsを携帯電話に作動して、固定系列TTYとコミュニケートする携帯電話モードに、しばしばセル端末の供給者によって使用されます。 したがって、Baudot-タイプtextphonesに適用されると、それは「利得がありません」とCTMソリューションのための一般名です。
van Wijk & Gybels Informational [Page 22] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[22ページ]RFC5194Framework
6.2.5.2.4. Mobile Data Channel Mode
6.2.5.2.4. モバイルデータ・チャンネルモード
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 textphonesを相互運用性に提供します。
6.2.5.2.5. Mobile ToIP
6.2.5.2.5. モバイルToIP
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第三世代サービスにおいて、ToIPサポートは3G TS26.235[19]で説明されます。
6.2.5.3. Instant Messaging Interworking
6.2.5.3. インスタントメッセージングの織り込むこと
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.
テキストゲートウェイは、Instant MessagingシステムとToIPの間でソリューションを織り込むのを許容するのに使用されるかもしれません。 Instant MessagingがToIPのようにキャラクタの連続した流れの上でというよりむしろテキストのブロックに基づいているので、ゲートウェイは2つの形式の間の「移-コード」が基づかなければなりません。 Instant Messagingと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のキャラクタより長くなります、バッファリングされたテキストSHOULD。いつ、ToIP側からどんな非英数字のキャラクタも受け取るとすぐに、Instant Messaging側に送られるか。
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側、復帰を含むそのポイントに起きていているバッファリングされた性格、そして/または、改行文字、SHOULDから、Instant Messaging側に送られてください。
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。 そのポイントSHOULDまでToIP側が活動していなくて少なくとも5秒間、すべてバッファリングされたテキストであるときには、Instant Messaging側に送られてください。
e. Text Gateways must be capable of maintaining the real-time
performance for ToIP while providing the interworking services.
e。 テキストGatewaysはサービスを織り込むのに提供している間、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
テキスト入力の進歩でアップデートして、セッションの間両方のユーザが絶えずそうであることはRECOMMENDEDです。 多くのInstant Messagingプロトコルが、ユーザが中で相手にタイプしているのを示します。
van Wijk & Gybels Informational [Page 23] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[23ページ]RFC5194Framework
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.
会話。 キャラクタが受け取られ始めるか、時または会話の始めにInstant Messaging側に合図して、そのようなInstant Messagingプロトコルと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側では、Instant Messageに書くインディケータがInstant Messagingプロトコルが1つを提供するところに存在していなければなりません。 「例えば、リアルタイムのテキストユーザは見るかもしれません。」 . . 返答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.
テキストゲートウェイはInstant MessagingとToIPを接続できますが、最も良いソリューションはインスタントメッセージングとToIP電話のためのユーザインタフェースとユーザーコミュニティが非常に同様であるという事実を利用することです。 結局、Instant Messaging(SIMPLE)とToIPには、キャラクタ入力、キャラクタディスプレイ、インターネットの接続性、およびSIPスタックは同じである場合があります。 したがって、ユーザは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.
したがって、これで説明されるようにInstant Messaging SHOULD道具ToIPを実装するデバイスがそれを記録する、 より多くの全文通信サービス、提供できます。
6.2.5.4. Multi-Functional Combination Gateways
6.2.5.4. 多機能組み合わせゲートウェイ
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とサポートでInstant Messagingと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:
組み合わせゲートウェイはそれらのサポートしているテキストベースの機能のすべての間の織り込むことを提供するかもしれません。 例えば、Instant MessagingとToIPの両方をサポートするPSTNと共に織り込むモデムを持っているテキストゲートウェイは機能を織り込みながら、以下をサポートするかもしれません:
- PSTN text telephony to ToIP
- ToIPへのPSTNテキスト電話
- PSTN text telephony to Instant Messaging
- Instant MessagingへのPSTNテキスト電話
- Instant Messaging to ToIP
- ToIPへのインスタントメッセージング
van Wijk & Gybels Informational [Page 24] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[24ページ]RFC5194Framework
6.2.5.5. Character Set Transcoding
6.2.5.5. 文字コードコード変換
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はISO10646文字集合を利用します。 ほとんどの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の間のコード変換であるときに、7ビットのコードの国家の異形に特別の配慮を与えなければなりません、国民性がISO10646でコードスペースを異なったコードに写像していて。 使用されるべき国家の異形は、ユーザが1呼び出しあたり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.
7ビットのキャラクタコードでT.140のなくなったテキストのT.140修正1で指定されたインディケータは表すことができません。 なくなったテキストSHOULDには、いてください。したがって、インディケータ、'このキャラクタが存在するレガシーテキスト電話の(アポストロフィ)キャラクタ'に、移コード化しました。 'キャラクタが存在しないレガシーシステムのために. (終止符)キャラクタSHOULD、代わりに使用されてください、'
7. Further Recommendations for Implementers and Service Providers
7. Implementersとサービスプロバイダーのためのさらなる推薦
7.1. Access to Emergency Services
7.1. 緊急サービスへのアクセス
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.
リアルタイムのテキストが国のためのコミュニケーションであるとサポートする認識された緊急電話番号のどれかが呼ばれるとき、セルワイヤレスのパケットで切り換えられたサービスがあるテキストゲートウェイはリアルタイムのテキスト呼び出しを非常時のサービスプロバイダーに発送できなければなりません。
7.2. Home Gateways or Analog Terminal Adapters
7.2. ホームゲートウェイかアナログのティーエー
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デバイスSHOULDにSIPベースのIPコミュニケーションとRJ-11コネクタを使用するアナログのターミナルアダプタ(ATA)がレガシーPSTNテキスト電話[23]の接続を可能にします。
van Wijk & Gybels Informational [Page 25] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[25ページ]RFC5194Framework
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.
声のセッションのために相互運用性を提供するとき、これらのアダプターSHOULDは同様の方法でRFC4103[4]に応じてT.140が輸送されているSIPベースのToIPからの/にV.18モデムの機能性、声の取り扱いの機能性、および変換機能を含んでいます。
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能力は宣言されません、メソッド。コード変換サーバSHALLを呼び出すには、使用されてください。 そのような何かサーバが利用可能でないなら、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.
以下に注意してください。 そのようなアナログのターミナルアダプタがテキストゲートウェイとしてRFC4103[4]を使用して、その結果、機能するのが好ましいです。 音声チャンネルの上にtextphone信号を送るのは可能なフィルタリング、圧縮、およびパケット損失のために終点の間で望ましくありません。 これはtextphonesが互いに接続しないのさえキャラクタの損失をもたらすことができます。
7.3. User Mobility
7.3. ユーザの移動性
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 UserエージェントSHOULDは、移動性問題を解決するのに他のSIP Userエージェントと同じメカニズムを使用します。 ユーザが基本的なユーザの移動性を可能にするのにSIP記録係によって決議されたSIPアドレスを使用するのは、RECOMMENDEDです。 さらなるメカニズムは3G IPマルチメディア・システムのためのすべてのセッションタイプのために定義されます。
7.4. Firewalls and NATs
7.4. ファイアウォールとNATs
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に適用されなければなりません。
7.5. Quality of Service
7.5. サービスの質
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.
Service(QoS)メカニズムのQualityが使用されているところでは、リアルタイムのテキストストリームは、性能必要条件を満たすことができて、リアルタイムのテキスト小川が比較で「非-好意的」に削り取られないように、適切なQoSの特性を混雑している状況における声の性能に割り当てられるべきです。
8. Security Considerations
8. セキュリティ問題
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,
ユーザ秘密性とプライバシーは、SIP[2]で説明されるように会われる必要があります。 例えば、公聴会かスピーチ損傷に従って、何も当たり前の方法的に、ToIPユーザが人であるかもしれないという事実を明らかにするべきではありません。 その人の公聴会かスピーチ損傷を公共にするのは、ToIPユーザ次第です。 コード変換サーバが使用されているなら
van Wijk & Gybels Informational [Page 26] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[26ページ]RFC5194Framework
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].
このSHOULD、できるだけ透明であってください。 しかしながら、ユーザがSDPの現在の属性に基づいて損なわれた公聴会かスピーチであるかもしれないことを明察するのはまだ可能であるかもしれません、意志がまた、主流のユーザが、ToIPを使用するのを選ぶかもしれないということですが。 暗号化SHOULDは終わらせる終わりで使用されるか、またはホップで跳びます。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ユーザが考えるかもしれないケースを考えるのはコード変換サーバがそうしなければなりません。
9. Contributors
9. 貢献者
The following people contributed to this document: Willem Dijkstra, Barry Dingle, Gunnar Hellstrom, Radhika R. Roy, Henry Sinnreich, and Gregg C. Vanderheiden.
以下の人々はこのドキュメントに貢献しました: ウィレム・ダイクストラ、バリトンサックス峡谷、グナー・ヘルストリョーム、Radhika 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作業部会の製品です。 トム・テイラー(ノーテル)は、このドキュメントの構造と中身に独立している評論家として務めて、かなり貢献しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[1] ブラドナー、S.、エド、「IETF技術による知的所有権」、BCP79、RFC3979、3月2005日
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] 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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[4] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[4] ヘルストリョームとG.とP.ジョーンズ、「テキストの会話のためのRTP有効搭載量」、RFC4103、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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
van Wijk & Gybels Informational [Page 27] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[27ページ]RFC5194Framework
[7] 3GPP TS 26.226, "Cellular Text Telephone Modem Description"
(CTM).
[7]3GPP t26.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:」 「セッション記述プロトコル」、RFC4566、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、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[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、「セッション開始プロトコル(一口)のための訪問者好み」、RFC3841、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、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] キャマリロ、G.、Burger、E.、Schulzrinne、H.、およびA.はウェイクをバンに積みます、「セッション開始プロトコル(一口)のコード変換サービス実施は第三者呼び出しコントロール(3pcc)を使用し」て、RFC4117、2005年6月。
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[14]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変換形式
[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]、「XHTML1.0:」 広げることができるハイパーテキストマークアップランゲージ: XMLのHTML4のReformulation、1インチ、 http://www.w3.org/TR/xhtml1 で利用可能なW3C推薦。
[16] ITU-T Recommendation V.18, "Operational and Interworking
Requirements for DCEs operating in Text Telephone Mode",
November 2000.
[16] ITU-T Recommendation V.18、「操作上、Text Telephone Modeで作動するDCEsのためのInterworking Requirements、」、11月2000日
[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/、-、823-A、「TIA/EIA-136-410 Enhanced Full Rate Speech CodecへのTTY/TDD Extension、(必須がTIA/EIA/に関連して使用した、-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/、-127-2にである「広帯域普及のスペクトルデジタル・システム、付加物2のために変動金利コーデック、スピーチサービスオプション3を機能アップしました」。
[19] "IP Multimedia default codecs", 3GPP TS 26.235
[19] 「IP Multimediaデフォルトコーデック」、3GPP TS26.235
van Wijk & Gybels Informational [Page 28] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[28ページ]RFC5194Framework
[20] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
2004年の[20]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[21] ITU-T Recommendation F.700, "Framework Recommendation for
Multimedia Services", November 2000.
[21] ITU-T推薦F.700、「マルチメディアサービスのためのフレームワーク推薦」、2000年11月。
10.2. Informative References
10.2. 有益な参照
[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.、Spanner、M.、およびA.はウェイク、「聴覚障害の、そして、耳が遠くてスピーチによって損なわれた個人を支持したセッション開始プロトコル(一口)のためのユーザ要件」をバンに積みます、RFC3351、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と、「一口電話デバイス要件と構成」(RFC4504)は2006にそうするかもしれません。
[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)」を設けます。 「電気通信のためのガイドラインはテキスト電話のためのサービスをリレーします。」 2000年6月のTR101 806。
[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] 国際電気通信連合(ITU)、「複式のモデムが司令官における使用のために標準化した300のbpsが電話網を切り換えました」。 1988年11月のITU-T推薦V.21。
[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)、「司令官における使用のために標準化された600/1200ボーのモデムは電話網を切り換えました」、ITU-T Recommendation V.23、1988年11月。
[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.、「一口カンフェレンス・ブリッジコード変換モデル」が進歩、2006年1月に働いています。
van Wijk & Gybels Informational [Page 29] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[29ページ]RFC5194Framework
Authors' Addresses
作者のアドレス
Guido Gybels Department of New Technologies RNID, 19-23 Featherstone Street London EC1Y 8SL, UK
19-23 新技術RNID、フェザーストン・通りロンドン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
Tel+44-20-7294 3713Txt+44-20-7296 8001Ext3713はファックスで8069年の+44-20-7296メールを送ります: guido.gybels@rnid.org.uk http://www.ictrnid.org.uk
Arnoud A. T. van Wijk Real-Time Text Taskforce (R3TF)
Arnoud A.T.バンウェイクレアル-時間Text Taskforce(R3TF)
EMail: arnoud@realtimetext.org http://www.realtimetext.org
メール: arnoud@realtimetext.org http://www.realtimetext.org
van Wijk & Gybels Informational [Page 30] RFC 5194 Framework for TOIP using SIP June 2008
2008年6月にSIPを使用するTOIPのためのバンウェイクとGybels Informational[30ページ]RFC5194Framework
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
van Wijk & Gybels Informational [Page 31]
バンウェイクとGybels Informational[31ページ]
一覧
スポンサーリンク
