RFC4734 日本語訳
4734 Definition of Events for Modem, Fax, and Text Telephony Signals.H. Schulzrinne, T. Taylor. December 2006. (Format: TXT=116810 bytes) (Obsoletes RFC2833) (Updates RFC4733) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne Request for Comments: 4734 Columbia U. Obsoletes: 2833 T. Taylor Updates: 4733 Nortel Category: Standards Track December 2006
Network Working Group H. Schulzrinne Request for Comments: 4734 Columbia U. Obsoletes: 2833 T. Taylor Updates: 4733 Nortel Category: Standards Track December 2006
Definition of Events for Modem, Fax, and Text Telephony Signals
Definition of Events for Modem, Fax, and Text Telephony Signals
Status of This Memo
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The IETF Trust (2006).
Copyright (C) The IETF Trust (2006).
Abstract
Abstract
This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833.
This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833.
Schulzrinne & Taylor Standards Track [Page 1] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 1] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Table of Contents
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Overview ...................................................3
2. Definitions of Events for Control of Data, Fax, and Text
Telephony Sessions ..............................................5
2.1. V.8 bis Events .............................................5
2.1.1. Handling of Congestion ..............................9
2.2. V.21 Events ...............................................10
2.2.1. Handling of Congestion .............................11
2.3. V.8 Events ................................................12
2.3.1. Handling of Congestion .............................15
2.4. V.25 Events ...............................................15
2.4.1. Handling of Congestion .............................17
2.5. V.32/V.32bis Events .......................................18
2.5.1. Handling of Congestion .............................19
2.6. T.30 Events ...............................................19
2.6.1. Handling of Congestion .............................23
2.7. Events for Text Telephony .................................23
2.7.1. Signal Format Indicators for Text Telephony ........23
2.7.2. Use of Events with V.18 Modems .....................27
2.8. A Generic Indicator .......................................28
3. Strategies for Handling Fax and Modem Signals ..................29
4. Example of V.8 Negotiation .....................................30
4.1. Simultaneous Transmission of Events and
Retransmitted Events Using RFC 2198 Redundancy ............35
4.2. Simultaneous Transmission of Events and Voice-Band
Data Using RFC 2198 Redundancy ............................37
5. Security Considerations ........................................39
6. IANA Considerations ............................................40
7. Acknowledgements ...............................................42
8. References .....................................................43
8.1. Normative References ......................................43
8.2. Informative References ....................................44
1. Introduction ....................................................3 1.1. Terminology ................................................3 1.2. Overview ...................................................3 2. Definitions of Events for Control of Data, Fax, and Text Telephony Sessions ..............................................5 2.1. V.8 bis Events .............................................5 2.1.1. Handling of Congestion ..............................9 2.2. V.21 Events ...............................................10 2.2.1. Handling of Congestion .............................11 2.3. V.8 Events ................................................12 2.3.1. Handling of Congestion .............................15 2.4. V.25 Events ...............................................15 2.4.1. Handling of Congestion .............................17 2.5. V.32/V.32bis Events .......................................18 2.5.1. Handling of Congestion .............................19 2.6. T.30 Events ...............................................19 2.6.1. Handling of Congestion .............................23 2.7. Events for Text Telephony .................................23 2.7.1. Signal Format Indicators for Text Telephony ........23 2.7.2. Use of Events with V.18 Modems .....................27 2.8. A Generic Indicator .......................................28 3. Strategies for Handling Fax and Modem Signals ..................29 4. Example of V.8 Negotiation .....................................30 4.1. Simultaneous Transmission of Events and Retransmitted Events Using RFC 2198 Redundancy ............35 4.2. Simultaneous Transmission of Events and Voice-Band Data Using RFC 2198 Redundancy ............................37 5. Security Considerations ........................................39 6. IANA Considerations ............................................40 7. Acknowledgements ...............................................42 8. References .....................................................43 8.1. Normative References ......................................43 8.2. Informative References ....................................44
Schulzrinne & Taylor Standards Track [Page 2] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 2] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
1. Introduction
1. Introduction
1.1. Terminology
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
In addition to those defined for specific events, this document uses the following abbreviations:
In addition to those defined for specific events, this document uses the following abbreviations:
Fax facsimile
Fax facsimile
HDLC High-level Data Link Control
HDLC High-level Data Link Control
PSTN Public Switched (circuit) Telephone Network
PSTN Public Switched (circuit) Telephone Network
1.2. Overview
1.2. Overview
This document extends the set of telephony events defined within the framework of RFC 4733 [5] to include the control events and tones that can appear on a subscriber line serving a fax machine, a modem, or a text telephony device. The events are organized into several groups, corresponding to the ITU-T Recommendation in which they are defined. Their purpose is to support negotiation, start-up and takedown of fax, modem, or text telephony sessions and transitions between operating modes. The actual fax, modem, and text payload is typically carried by other payload types (e.g., V.150.1 [32] modem relay, voice-band data as formalized in ITU-T Rec. V.152 [33], Clearmode [17] for digital data, T.38 [21] for fax, or RFC 4103 [18] for character-mode text).
This document extends the set of telephony events defined within the framework of RFC 4733 [5] to include the control events and tones that can appear on a subscriber line serving a fax machine, a modem, or a text telephony device. The events are organized into several groups, corresponding to the ITU-T Recommendation in which they are defined. Their purpose is to support negotiation, start-up and takedown of fax, modem, or text telephony sessions and transitions between operating modes. The actual fax, modem, and text payload is typically carried by other payload types (e.g., V.150.1 [32] modem relay, voice-band data as formalized in ITU-T Rec. V.152 [33], Clearmode [17] for digital data, T.38 [21] for fax, or RFC 4103 [18] for character-mode text).
NOTE: implementers SHOULD NOT rely on the descriptions of the various modem protocols described below without consulting the original references (generally ITU-T Recommendations). The descriptions are provided in this document to give a context for the use of the events defined here. They frequently omit important details needed for implementation.
NOTE: implementers SHOULD NOT rely on the descriptions of the various modem protocols described below without consulting the original references (generally ITU-T Recommendations). The descriptions are provided in this document to give a context for the use of the events defined here. They frequently omit important details needed for implementation.
The typical application of these events is to allow the Internet to serve as a bridge between terminals operating on the PSTN. This application is characterized as follows:
The typical application of these events is to allow the Internet to serve as a bridge between terminals operating on the PSTN. This application is characterized as follows:
o each gateway will act both as sender and as receiver;
o each gateway will act both as sender and as receiver;
o time constraints apply to the exchange of signals, making the
early identification and reporting of events desirable so that
receiver playout can proceed in a timely fashion;
o time constraints apply to the exchange of signals, making the early identification and reporting of events desirable so that receiver playout can proceed in a timely fashion;
Schulzrinne & Taylor Standards Track [Page 3] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 3] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
o the receiver must play out events in their proper order;
o the receiver must play out events in their proper order;
o transfer of the events must be reliable. Applications will vary
in their ability to recover from missing events.
o transfer of the events must be reliable. Applications will vary in their ability to recover from missing events.
In some cases, an implementation may simply ignore certain events, such as fax tones, that do not make sense in a particular environment. Section 2.4.1 of RFC 4733 [5] specifies how an implementation can use the Session Description Protocol (SDP) "fmtp" parameter within an SDP description [4] to indicate which events it is prepared to handle.
In some cases, an implementation may simply ignore certain events, such as fax tones, that do not make sense in a particular environment. Section 2.4.1 of RFC 4733 [5] specifies how an implementation can use the Session Description Protocol (SDP) "fmtp" parameter within an SDP description [4] to indicate which events it is prepared to handle.
Regardless of which events they support, implementations MUST be prepared to send and receive data signals using payload types other than telephone-event, simultaneously with the use of the latter. This is discussed further in Section 3.
Regardless of which events they support, implementations MUST be prepared to send and receive data signals using payload types other than telephone-event, simultaneously with the use of the latter. This is discussed further in Section 3.
In many cases, continuity of playout is critical. In principle, this is achieved through buffering at the receiving end. It is generally desirable to minimize such buffering to reduce round-trip response times. Maintenance of a constant packetization interval at the sending end while reporting events is helpful for this purpose.
In many cases, continuity of playout is critical. In principle, this is achieved through buffering at the receiving end. It is generally desirable to minimize such buffering to reduce round-trip response times. Maintenance of a constant packetization interval at the sending end while reporting events is helpful for this purpose.
A further word on time constraints is in order. Time constraints governing the duration of tones do not pose a problem when using the telephone-event payload type: the payload specifies the duration and the receiving gateway can play out the tones accordingly. Problems occur when time constraints are specified for the duration of silence between tones. A silent period of "at least x ms" is not a problem -- event notifications can be received late, but they can still be played out at their specified durations.
A further word on time constraints is in order. Time constraints governing the duration of tones do not pose a problem when using the telephone-event payload type: the payload specifies the duration and the receiving gateway can play out the tones accordingly. Problems occur when time constraints are specified for the duration of silence between tones. A silent period of "at least x ms" is not a problem -- event notifications can be received late, but they can still be played out at their specified durations.
The problem occurs if silence must last for a specific duration or at most some specific period. The most general constraint of the latter type has to do with the operation of echo suppressors (ITU-T Rec. G.164 [6]) and echo cancellers (ITU-T Rec. G.165 [7]). These devices may re-activate after as little as 100 ms of no signal on the line. As a result, in any situation where echo suppressors or cancellers must be disabled for signalling to work, tone events must be reported quickly enough to ensure that these devices do not become re-enabled.
The problem occurs if silence must last for a specific duration or at most some specific period. The most general constraint of the latter type has to do with the operation of echo suppressors (ITU-T Rec. G.164 [6]) and echo cancellers (ITU-T Rec. G.165 [7]). These devices may re-activate after as little as 100 ms of no signal on the line. As a result, in any situation where echo suppressors or cancellers must be disabled for signalling to work, tone events must be reported quickly enough to ensure that these devices do not become re-enabled.
Schulzrinne & Taylor Standards Track [Page 4] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 4] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
2. Definitions of Events for Control of Data, Fax, and Text Telephony
Sessions
2. Definitions of Events for Control of Data, Fax, and Text Telephony Sessions
2.1. V.8 bis Events
2.1. V.8 bis Events
Recommendation V.8 bis [10] is a general procedure for two endpoints to establish each other's capabilities and to transition between different operating modes, both at call startup and after the call has been established. It supports many of the same terminals as V.8 [9] (Section 2.3 below), but allows more detailed parameter negotiation. It lacks support for some of the older V-series modems defined in V.8, but adds capabilities for simultaneous or alternating voice and data, H.324 [20] multilink, and T.120 [23] conferencing.
Recommendation V.8 bis [10] is a general procedure for two endpoints to establish each other's capabilities and to transition between different operating modes, both at call startup and after the call has been established. It supports many of the same terminals as V.8 [9] (Section 2.3 below), but allows more detailed parameter negotiation. It lacks support for some of the older V-series modems defined in V.8, but adds capabilities for simultaneous or alternating voice and data, H.324 [20] multilink, and T.120 [23] conferencing.
Following V.8 bis capability negotiations, if the terminals have negotiated a modem-based operating mode, they initiate the actual modem session using either V.8, a truncated version of V.8 (preferred), or V.25 start-up. V.25 is described in Section 2.4.
Following V.8 bis capability negotiations, if the terminals have negotiated a modem-based operating mode, they initiate the actual modem session using either V.8, a truncated version of V.8 (preferred), or V.25 start-up. V.25 is described in Section 2.4.
V.8 bis distinguishes between "signals" and "messages". The V.8 bis signals -- ESi/ESr, MRe/MRd, and CRe/CRd -- consist of tones, as described in the next few paragraphs. The V.8 bis messages -- MS, CL, CLR, ACK(1), ACK(2), NAK(1), NAK(2), NACK(3), and NACK(4) -- consist of sequences of bits transported over V.21 [12] modulation.
V.8 bis distinguishes between "signals" and "messages". The V.8 bis signals -- ESi/ESr, MRe/MRd, and CRe/CRd -- consist of tones, as described in the next few paragraphs. The V.8 bis messages -- MS, CL, CLR, ACK(1), ACK(2), NAK(1), NAK(2), NACK(3), and NACK(4) -- consist of sequences of bits transported over V.21 [12] modulation.
Signals are intended to be comprehensible at the receiver even in the presence of voice content. They consist of two tone segments. The first segment consists of a dual-frequency tone held for 400 ms, and has the function of preparing the receiver and any in-line echo suppressor or canceller for what follows. The specific frequencies depend only on whether the signal is from the initiator or the responder in a transaction. When using the telephone-event payload, the V8bISeg and V8bRSeg events in Table 1 represent the first segment of any V.8 bis signal in the initiating and responding case, respectively.
Signals are intended to be comprehensible at the receiver even in the presence of voice content. They consist of two tone segments. The first segment consists of a dual-frequency tone held for 400 ms, and has the function of preparing the receiver and any in-line echo suppressor or canceller for what follows. The specific frequencies depend only on whether the signal is from the initiator or the responder in a transaction. When using the telephone-event payload, the V8bISeg and V8bRSeg events in Table 1 represent the first segment of any V.8 bis signal in the initiating and responding case, respectively.
The complete V.8 bis strategy for dealing with echo suppressors or
cancellers is described in Rec. V.8 bis Appendix III. The only
silent period constraints imposed are of the "at least" type,
posing no difficulties for the use of the telephone-event payload.
The complete V.8 bis strategy for dealing with echo suppressors or cancellers is described in Rec. V.8 bis Appendix III. The only silent period constraints imposed are of the "at least" type, posing no difficulties for the use of the telephone-event payload.
The second segment follows immediately after the first, and is a single tone held for 100 ms. The frequency used indicates the specific signal of the six signals defined. When using the telephone-event payload, the second segment of a V.8 bis signal is represented by the applicable event: CRdSeg, CReSeg, MRdSeg, MReSeg,
The second segment follows immediately after the first, and is a single tone held for 100 ms. The frequency used indicates the specific signal of the six signals defined. When using the telephone-event payload, the second segment of a V.8 bis signal is represented by the applicable event: CRdSeg, CReSeg, MRdSeg, MReSeg,
Schulzrinne & Taylor Standards Track [Page 5] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 5] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
ESiSeg, or ESrSeg, as defined in Table 1. ESiSeg and ESrSeg use the same frequencies as V.21 low and high channel '1' bits, respectively (see Table 2), and are therefore assigned the same event codes.
ESiSeg, or ESrSeg, as defined in Table 1. ESiSeg and ESrSeg use the same frequencies as V.21 low and high channel '1' bits, respectively (see Table 2), and are therefore assigned the same event codes.
V.8 bis messages use V.21 [12] frequency-shift signalling to transfer message content. V.21 is described in the next section. V.8 bis uses V.21 in half-duplex mode at 300 bits/s, with the lower channel assigned to the initiator and the upper channel to the responder.
V.8 bis messages use V.21 [12] frequency-shift signalling to transfer message content. V.21 is described in the next section. V.8 bis uses V.21 in half-duplex mode at 300 bits/s, with the lower channel assigned to the initiator and the upper channel to the responder.
Each V.8 bis message is preceded by a 100-ms preamble of continuous V.21 marking frequency except if it was immediately preceded by an ESi or ESr signal (the second segment of which is that same V.21 marking frequency). The sender SHALL NOT report this preamble tone using the ESiSeg or ESrSeg events; these are to be used only for the V.8 bis signals to which they pertain.
Each V.8 bis message is preceded by a 100-ms preamble of continuous V.21 marking frequency except if it was immediately preceded by an ESi or ESr signal (the second segment of which is that same V.21 marking frequency). The sender SHALL NOT report this preamble tone using the ESiSeg or ESrSeg events; these are to be used only for the V.8 bis signals to which they pertain.
Spelling this out, continuous V.21 marking tone immediately
following V8bISeg and V8bRSeg is reported as ESiSeg or ESrSeg,
respectively. Continuous V.21 marking tone occurring in any other
context, and particularly after CRdSeg, CReSeg, MRdSeg, or MReSeg,
is reported by other means such as a different payload type or
using the V.21 '1' bit events defined in Section 2.2.
Spelling this out, continuous V.21 marking tone immediately following V8bISeg and V8bRSeg is reported as ESiSeg or ESrSeg, respectively. Continuous V.21 marking tone occurring in any other context, and particularly after CRdSeg, CReSeg, MRdSeg, or MReSeg, is reported by other means such as a different payload type or using the V.21 '1' bit events defined in Section 2.2.
No events are defined for V.8 bis messages, but a brief description follows.
No events are defined for V.8 bis messages, but a brief description follows.
o the V.8 bis CL message describes the sending terminal's
capabilities;
o the V.8 bis CL message describes the sending terminal's capabilities;
o the CLR message also describes capabilities, but indicates that
the sender wants to receive a CL in return;
o the CLR message also describes capabilities, but indicates that the sender wants to receive a CL in return;
o the MS establishes a particular operating mode;
o the MS establishes a particular operating mode;
o the ACK and NAK messages are used to terminate the message
transactions.
o the ACK and NAK messages are used to terminate the message transactions.
The V.8 bis messages are organized as a sequence of octets. The first two to five octets are HDLC flags (0x7E). Then comes a message type identifier (four bits), a V.8 bis version identifier (four bits), zero to two more octets of identifying information, followed by zero or more information field parameters in the form of bit maps. An individual bit map is one to five octets in length. Up to 64 octets of non-standard information may also be present. The information fields are followed by a checksum and one to three HDLC flags. Because of limits on the size of any one information field, V.8 bis defines segmentation procedures. Excess data is sent in an additional message, but only after prompting from the receiving end.
The V.8 bis messages are organized as a sequence of octets. The first two to five octets are HDLC flags (0x7E). Then comes a message type identifier (four bits), a V.8 bis version identifier (four bits), zero to two more octets of identifying information, followed by zero or more information field parameters in the form of bit maps. An individual bit map is one to five octets in length. Up to 64 octets of non-standard information may also be present. The information fields are followed by a checksum and one to three HDLC flags. Because of limits on the size of any one information field, V.8 bis defines segmentation procedures. Excess data is sent in an additional message, but only after prompting from the receiving end.
Schulzrinne & Taylor Standards Track [Page 6] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 6] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Applications supporting V.8 bis signalling using the telephone-event payload MAY transfer V.8 bis messages in the form of sequences of bits, using the V.21 bit events defined in the next section. If they do so, the transmitted information MUST include the complete contents of the message: the initial HDLC flags, the information field, the checksum, and the terminating HDLC flags.
Applications supporting V.8 bis signalling using the telephone-event payload MAY transfer V.8 bis messages in the form of sequences of bits, using the V.21 bit events defined in the next section. If they do so, the transmitted information MUST include the complete contents of the message: the initial HDLC flags, the information field, the checksum, and the terminating HDLC flags.
Transmission MUST also include the extra '0' bits added according to the procedures of Rec. V.8 bis, clause 7.2.8, to prevent false recognition of HDLC flags at the receiver. Implementers should note that these extra '0' bits mean that in general V.8 bis messages as transmitted on the wire will not come out to an even multiple of octets. Sending implementations MAY choose to vary the packetization interval to include exactly one octet of information plus any extra '0' bits inserted into that octet; the resulting variation will be insignificant compared with the amount of buffering required to guard against network delays in delivery of packets to the receiver (see below).
Transmission MUST also include the extra '0' bits added according to the procedures of Rec. V.8 bis, clause 7.2.8, to prevent false recognition of HDLC flags at the receiver. Implementers should note that these extra '0' bits mean that in general V.8 bis messages as transmitted on the wire will not come out to an even multiple of octets. Sending implementations MAY choose to vary the packetization interval to include exactly one octet of information plus any extra '0' bits inserted into that octet; the resulting variation will be insignificant compared with the amount of buffering required to guard against network delays in delivery of packets to the receiver (see below).
One reason for reporting the V.21 bits exactly as presented on the
wire is to match the corresponding content if it is also carried
by other means, such as voice-band data.
One reason for reporting the V.21 bits exactly as presented on the wire is to match the corresponding content if it is also carried by other means, such as voice-band data.
The power levels of the V.8 bis and V.21 signals are subject to national regulation. Thus, it seems suitable to model V.8 bis events as tones for which the volumes SHOULD be specified by the sender. If the receiver is rendering the V.8 bis tones as audio content for onward transmission, the receiver MAY use the volumes contained in the event reports, or MAY modify the volumes to match downstream national requirements.
The power levels of the V.8 bis and V.21 signals are subject to national regulation. Thus, it seems suitable to model V.8 bis events as tones for which the volumes SHOULD be specified by the sender. If the receiver is rendering the V.8 bis tones as audio content for onward transmission, the receiver MAY use the volumes contained in the event reports, or MAY modify the volumes to match downstream national requirements.
Table 1 summarizes the event codes defined for V.8 bis signalling in this document. The individual events are described following the table. Each event begins when the beginning of the tone segment is detected and ends when the tone is no longer detected.
Table 1 summarizes the event codes defined for V.8 bis signalling in this document. The individual events are described following the table. Each event begins when the beginning of the tone segment is detected and ends when the tone is no longer detected.
Schulzrinne & Taylor Standards Track [Page 7] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 7] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
+---------+-------------+-----------+------------+------+---------+
| Event | Freq. (Hz) | Dur. (ms) | Event Code | Type | Volume? |
+---------+-------------+-----------+------------+------+---------+
| ESiSeg | 980 | 100 | 38 | tone | yes |
| | | | | | |
| ESrSeg | 1650 | 100 | 40 | tone | yes |
| | | | | | |
| CRdSeg | 1900 | 100 | 23 | tone | yes |
| | | | | | |
| CReSeg | 400 | 100 | 24 | tone | yes |
| | | | | | |
| MRdSeg | 1150 | 100 | 25 | tone | yes |
| | | | | | |
| MReSeg | 650 | 100 | 26 | tone | yes |
| | | | | | |
| V8bISeg | 1375 + 2002 | 400 | 28 | tone | yes |
| | | | | | |
| V8bRSeg | 1529 + 2225 | 400 | 29 | tone | yes |
+---------+-------------+-----------+------------+------+---------+
+---------+-------------+-----------+------------+------+---------+ | Event | Freq. (Hz) | Dur. (ms) | Event Code | Type | Volume? | +---------+-------------+-----------+------------+------+---------+ | ESiSeg | 980 | 100 | 38 | tone | yes | | | | | | | | | ESrSeg | 1650 | 100 | 40 | tone | yes | | | | | | | | | CRdSeg | 1900 | 100 | 23 | tone | yes | | | | | | | | | CReSeg | 400 | 100 | 24 | tone | yes | | | | | | | | | MRdSeg | 1150 | 100 | 25 | tone | yes | | | | | | | | | MReSeg | 650 | 100 | 26 | tone | yes | | | | | | | | | V8bISeg | 1375 + 2002 | 400 | 28 | tone | yes | | | | | | | | | V8bRSeg | 1529 + 2225 | 400 | 29 | tone | yes | +---------+-------------+-----------+------------+------+---------+
Table 1: Events for V.8 bis Signals
Table 1: Events for V.8 bis Signals
ESiSeg:
ESiSeg:
The second segment of a V.8 bis initiating Escape Signal (ESi).
The complete ESi signal is represented by events V8bISeg followed
by ESiSeg. ESi will be followed by an MS, CL, or CLR message from
the same terminal. A 1.5-s silent interval may come between the
ESi signal and the transmission of the MS, CL, or CLR message to
accommodate network echo suppressors.
The second segment of a V.8 bis initiating Escape Signal (ESi). The complete ESi signal is represented by events V8bISeg followed by ESiSeg. ESi will be followed by an MS, CL, or CLR message from the same terminal. A 1.5-s silent interval may come between the ESi signal and the transmission of the MS, CL, or CLR message to accommodate network echo suppressors.
ESrSeg:
ESrSeg:
The second segment of a V.8 bis responding Escape Signal (ESr).
The complete ESr signal is represented by events V8bRSeg followed
by ESrSeg. ESr is always sent by the calling terminal in response
to an MRe or CRe from an automatic answering station. It will be
followed by an MS, CL, or CLR message. The ESr signal turns off
any announcement being generated by the automatic answering
station.
The second segment of a V.8 bis responding Escape Signal (ESr). The complete ESr signal is represented by events V8bRSeg followed by ESrSeg. ESr is always sent by the calling terminal in response to an MRe or CRe from an automatic answering station. It will be followed by an MS, CL, or CLR message. The ESr signal turns off any announcement being generated by the automatic answering station.
CRdSeg:
CRdSeg:
The second segment of a V.8 bis Capabilities Request signal (CRd).
The first segment of the CRd signal is represented either by
V8bISeg or V8bRSeg, depending on context. The other end will
return a capabilities list (CL or CLR message).
The second segment of a V.8 bis Capabilities Request signal (CRd). The first segment of the CRd signal is represented either by V8bISeg or V8bRSeg, depending on context. The other end will return a capabilities list (CL or CLR message).
Schulzrinne & Taylor Standards Track [Page 8] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 8] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
CReSeg:
CReSeg:
The second segment of a V.8 bis Capabilities Request signal (CRe)
initiated by an automatic answering terminal. The complete CRe
signal is represented by events V8bISeg followed by CReSeg. The
calling terminal will respond with a CRd signal or a CL or CLR
message.
The second segment of a V.8 bis Capabilities Request signal (CRe) initiated by an automatic answering terminal. The complete CRe signal is represented by events V8bISeg followed by CReSeg. The calling terminal will respond with a CRd signal or a CL or CLR message.
MRdSeg:
MRdSeg:
The second segment of a V.8 bis Mode Request signal (MRd). The
first segment of the MRd signal is represented either by V8bISeg
or V8bRSeg, depending on context. The other end will return a CRd
signal or an MS message.
The second segment of a V.8 bis Mode Request signal (MRd). The first segment of the MRd signal is represented either by V8bISeg or V8bRSeg, depending on context. The other end will return a CRd signal or an MS message.
MReSeg:
MReSeg:
The second segment of a V.8 bis Mode Request signal (MRe)
initiated by an automatic answering terminal. The complete MRe
signal is represented by events V8bISeg followed by MReSeg. The
calling terminal will respond with an MRd or CRd signal or an MS
message.
The second segment of a V.8 bis Mode Request signal (MRe) initiated by an automatic answering terminal. The complete MRe signal is represented by events V8bISeg followed by MReSeg. The calling terminal will respond with an MRd or CRd signal or an MS message.
V8bISeg:
V8bISeg:
The first segment of an initiating V.8 bis signal, which may be
one of ESi, CRd, CRe, MRd, or MRe.
The first segment of an initiating V.8 bis signal, which may be one of ESi, CRd, CRe, MRd, or MRe.
V8bRSeg:
V8bRSeg:
The first segment of a responding V.8 bis signal, which may be one
of ESr, CRd, or MRd.
The first segment of a responding V.8 bis signal, which may be one of ESr, CRd, or MRd.
2.1.1. Handling of Congestion
2.1.1. Handling of Congestion
V.8 bis implementations are unlikely to tolerate gaps or extensions in playout times due to congestion-caused packet delay. At a minimum, the current transaction is liable to be reset when these defects in playout occur. As a result, careful management of the playout buffer is required at the receiver to increase robustness in the face of possible lost or delayed packets. The playout algorithm should also be such as not to cause event playout to exceed the nominal duration of the event.
V.8 bis implementations are unlikely to tolerate gaps or extensions in playout times due to congestion-caused packet delay. At a minimum, the current transaction is liable to be reset when these defects in playout occur. As a result, careful management of the playout buffer is required at the receiver to increase robustness in the face of possible lost or delayed packets. The playout algorithm should also be such as not to cause event playout to exceed the nominal duration of the event.
V.8 bis does not appear to offer opportunities for dynamic adaptation to congestion through manipulation of the packetization interval.
V.8 bis does not appear to offer opportunities for dynamic adaptation to congestion through manipulation of the packetization interval.
Schulzrinne & Taylor Standards Track [Page 9] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 9] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
2.2. V.21 Events
2.2. V.21 Events
V.21 [12] is a modem protocol offering data transmission at a maximum rate of 300 bits/s. Two channels are defined, supporting full duplex data transmission if required. The low channel uses frequencies 980 Hz for '1' (mark) and 1180 Hz for '0' (space); the high channel uses frequencies 1650 Hz for '1' and 1850 Hz for '0'. The modem can operate synchronously or asynchronously.
V.21 [12] is a modem protocol offering data transmission at a maximum rate of 300 bits/s. Two channels are defined, supporting full duplex data transmission if required. The low channel uses frequencies 980 Hz for '1' (mark) and 1180 Hz for '0' (space); the high channel uses frequencies 1650 Hz for '1' and 1850 Hz for '0'. The modem can operate synchronously or asynchronously.
V.21 is used by other protocols (e.g., V.8 bis, V.18, T.30) for transmission of control data, and is also used in its own right between text terminals. The V.21 events are summarized in Table 2.
V.21 is used by other protocols (e.g., V.8 bis, V.18, T.30) for transmission of control data, and is also used in its own right between text terminals. The V.21 events are summarized in Table 2.
Sending implementations SHOULD report a completed event for every bit transmitted (i.e., rather than at transitions between '0' and '1'). Bit events are assumed to begin and end with the clock interval for the event, neglecting the rise and fall times between bit transitions. Thus, it is important for a gateway to determine the actual bit rate in use before beginning to report V.21 events.
Sending implementations SHOULD report a completed event for every bit transmitted (i.e., rather than at transitions between '0' and '1'). Bit events are assumed to begin and end with the clock interval for the event, neglecting the rise and fall times between bit transitions. Thus, it is important for a gateway to determine the actual bit rate in use before beginning to report V.21 events.
Sometimes determination of the bit rate is not immediately
possible, as in the case of the 100-ms training signal at V.21
mark frequency used before V.8 bis messages. Transmission of a
single longer-duration V.21 event is reasonable under these
circumstances and should not cause any difficulties at the
receiving end.
Sometimes determination of the bit rate is not immediately possible, as in the case of the 100-ms training signal at V.21 mark frequency used before V.8 bis messages. Transmission of a single longer-duration V.21 event is reasonable under these circumstances and should not cause any difficulties at the receiving end.
Implementations SHOULD pack multiple events into one packet, using the procedures of Section 2.5.1.5 of RFC 4733 [5]. Eight to ten bits is a reasonable packetization interval.
Implementations SHOULD pack multiple events into one packet, using the procedures of Section 2.5.1.5 of RFC 4733 [5]. Eight to ten bits is a reasonable packetization interval.
Reliable transmission of V.21 events is important, to prevent data corruption. Reporting an event per bit rather than per transition increases reporting redundancy and thus reporting reliability, since each event completion is transmitted three times as described in Section 2.5.1.4 of RFC 4733 [5]. To reduce the number of packets required for reporting, implementations SHOULD carry the retransmitted events using RFC 2198 [2] redundancy encoding. This is illustrated in the example in Section 4.1.
Reliable transmission of V.21 events is important, to prevent data corruption. Reporting an event per bit rather than per transition increases reporting redundancy and thus reporting reliability, since each event completion is transmitted three times as described in Section 2.5.1.4 of RFC 4733 [5]. To reduce the number of packets required for reporting, implementations SHOULD carry the retransmitted events using RFC 2198 [2] redundancy encoding. This is illustrated in the example in Section 4.1.
The time to transmit one V.21 bit at the nominal rate of 300 bits/s is 3.33 ms, or 26.67 timestamp units at the default 8000-Hz sampling rate for the telephone-event payload type. Because this duration is not an integral number of timestamp units, accurate reporting of the beginning of the event and the event duration is impossible. Sending gateways SHOULD round V.21 event starting times to the nearest whole timestamp unit.
The time to transmit one V.21 bit at the nominal rate of 300 bits/s is 3.33 ms, or 26.67 timestamp units at the default 8000-Hz sampling rate for the telephone-event payload type. Because this duration is not an integral number of timestamp units, accurate reporting of the beginning of the event and the event duration is impossible. Sending gateways SHOULD round V.21 event starting times to the nearest whole timestamp unit.
Schulzrinne & Taylor Standards Track [Page 10] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinne & Taylor Standards Track [Page 10] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
When sending multiple consecutive V.21 events in a succession of packets, the sending gateway MUST ensure that individual event durations reported do not cause the last event of one packet to overlap with the first event of the next, taking into account the respective initial event timestamps. To accomplish this, the sending gateway MUST derive the individual event durations as the succession of differences between the event starting times (so that, at 8000 Hz, every third event has reported duration 26 units, the remainder 27 units).
When sending multiple consecutive V.21 events in a succession of packets, the sending gateway MUST ensure that individual event durations reported do not cause the last event of one packet to overlap with the first event of the next, taking into account the respective initial event timestamps. To accomplish this, the sending gateway MUST derive the individual event durations as the succession of differences between the event starting times (so that, at 8000 Hz, every third event has reported duration 26 units, the remainder 27 units).
Where a receiving gateway recognizes that a packet reports a consecutive series of V.21 bit events, it SHOULD play them out at a uniform rate despite the possible one-timestamp-unit discrepancies in their reported spacing and duration.
Where a receiving gateway recognizes that a packet reports a consecutive series of V.21 bit events, it SHOULD play them out at a uniform rate despite the possible one-timestamp-unit discrepancies in their reported spacing and duration.
+--------------------+----------------+------------+------+---------+ | Event | Frequency (Hz) | Event Code | Type | Volume? | +--------------------+----------------+------------+------+---------+ | V.21 channel 1, | 1180 | 37 | tone | yes | | '0' bit | | | | | | | | | | | | V.21 channel 1, | 980 | 38 | tone | yes | | '1' bit | | | | | | | | | | | | V.21 channel 2, | 1850 | 39 | tone | yes | | '0' bit | | | | | | | | | | | | V.21 channel 2, | 1650 | 40 | tone | yes | | '1' bit | | | | | +--------------------+----------------+------------+------+---------+
+--------------------+----------------+------------+------+---------+ | 出来事| 頻度(Hz)| イベントコード| タイプ| ボリューム? | +--------------------+----------------+------------+------+---------+ | V.21は1を向けます。| 1180 | 37 | トーン| はい| | '0'ビット| | | | | | | | | | | | V.21は1を向けます。| 980 | 38 | トーン| はい| | '1'ビット| | | | | | | | | | | | V.21は2を向けます。| 1850 | 39 | トーン| はい| | '0'ビット| | | | | | | | | | | | V.21は2を向けます。| 1650 | 40 | トーン| はい| | '1'ビット| | | | | +--------------------+----------------+------------+------+---------+
Table 2: Events for V.21 Signals
テーブル2: V.21信号のための出来事
Implementations that choose to transmit V.21 content using a different payload type may wish to use one of the indicator events defined in Table 7 to alert the receiver to the nature of the content. It is not expected that an implementation will send both one of these indicator events and the V.21 bit events defined above for the same content.
異なったペイロードタイプを使用することでV.21内容を伝えるのを選ぶ実現は内容の本質に受信機を警告するためにTable7で定義されたインディケータイベントの1つを使用したがっているかもしれません。 実現がこれらのインディケータイベントの1つとV.21ビットの両方に同じ内容のために上で定義された出来事を送らないと予想されます。
2.2.1. Handling of Congestion
2.2.1. 混雑の取り扱い
The duration of V.21 bits cannot be extended from its nominal value (which depends on the transmission rate). The playout algorithm at the receiver should take this constraint into account when compensating for the delay or loss of packets due to congestion.
額面価格(通信速度による)からV.21ビットの持続時間を広げることができません。 混雑のためパケットの遅れか損失を補うとき、受信機の再生アルゴリズムはこの規制を考慮に入れるべきです。
Schulzrinne & Taylor Standards Track [Page 11] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[11ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
Other congestion-related considerations depend on the specific application for which the V.21 bit events are being used.
他の混雑関連の問題はV.21ビット出来事が使用されている特定のアプリケーションによります。
2.3. V.8 Events
2.3. V.8出来事
V.8 [9] is an older general negotiation and control protocol, supporting startup for the following terminals: H.324 [20] multimedia, V.18 [11] text, T.101 [22] videotext, T.30 [8] send or receive fax, and a long list of V-series modems including V.34 [28], V.90 [29], V.91 [30], and V.92 [31]. In contrast to V.8 bis [10], in V.8 only the calling terminal can determine the operating mode.
以下の端末のための始動を支持して、V.8[9]は、より古い一般的な交渉と制御プロトコルです: H.324[20]マルチメディア、V.18[11]テキスト、T.101[22]ビデオテキスト、T.30[8]はファックス、およびV.34[28]、V.90[29]、V.91[30]、およびV.92[31]を含むV-シリーズモデムに関する長い一覧表を送るか、または受け止めます。 [10] V.8と対照して、V.8だけでは、2回、呼ぶ端末はオペレーティング・モードを決定できます。
V.8 does not use the same terminology as V.8 bis. Rather, it defines four signals that consist of bits transferred by V.21 [12] at 300 bits/s: the call indicator signal (CI), the call menu signal (CM), the CM terminator (CJ), and the joint menu signal (JM). In addition, it uses tones defined in V.25 [13] and T.30 [8] (described below), and one tone (ANSam) defined in V.8 itself. The calling terminal sends using the V.21 low channel; the answering terminal uses the high channel.
V.8は2回V.8と同じ用語を使用しません。 むしろ、300ビット/sでV.21[12]によって移されたビットから成る4つの信号を定義します: コールインジケータ信号(CI)、呼び出しメニュー信号(CM)、CMターミネータ(CJ)、および共同メニューは(JM)を示します。 さらに、それはV.25[13]とT.30[8]で定義されたトーン(以下で、説明される)、およびV.8自身で定義された1つのトーン(ANSam)を使用します。 呼ぶ端末はV.21の低いチャンネルを使用することで発信します。 回答端末は高いチャンネルを使用します。
The basic protocol sequence is subject to a number of variations to accommodate different terminal types. A pure V.8 sequence is as follows:
基本プロトコル系列は異なった端末のタイプに対応する多くの変化を被りやすいです。 純粋なV.8系列は以下の通りです:
1. After an initial period of silence, the calling terminal
transmits the V.8 CI signal. It repeats CI at least three times,
continuing with occasional pauses until it detects ANSam tone.
The CI indicates whether the calling terminal wants to function
as H.324, V.18, T.30 send, T.30 receive, or a V-series modem.
1. 原初期の沈黙の後に、呼ぶ端末はV.8 CI信号を送信します。 ANSamトーンを検出するまで時々のくぎりを続行して、それは少なくとも3回CIを繰り返します。 T.30が、CIが、H.324、V.18として機能する呼ぶことの端末の必需品であり、T.30が発信するかどうかを示すのを受ける、または、V-シリーズモデム。
2. The answering terminal transmits ANSam after detecting CI. ANSam
will disable any G.164 [6] echo suppressors on the circuit after
400 ms and any G.165 [7] echo cancellers after one second of
ANSam playout.
2. CIを検出した後に、回答端末はANSamを伝えます。 ANSamは1秒のANSam再生の後に400msとどんなG.165[7]エコーキャンセラーの後のサーキットの上のどんなG.164[6]エコーサプレッサも損傷するでしょう。
3. On detecting ANSam, the calling terminal pauses at least half a
second, then begins transmitting CM to indicate detailed
capabilities within the chosen mode.
3. ANSamを検出すると、呼ぶ端末は、少なくとも半分の2番目をポーズして、次に、選ばれたモードの中に詳細な能力を示すためにCMを伝え始めます。
4. After detecting at least two identical sequences of CM, the
answering terminal begins to transmit JM, indicating its own
capabilities (or offering an alternative terminal type if it
cannot support the one requested).
4. CMの少なくとも2つの同じ系列を検出した後に、回答端末はJMを伝え始めます、それ自身の能力を示して(要求されたものを支持できないなら代替の端末のタイプを提供して)。
Schulzrinne & Taylor Standards Track [Page 12] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[12ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
5. After detecting at least two identical sequences of JM, the
calling terminal completes the current octet of CM, then
transmits CJ to acknowledge the JM signal. It pauses exactly 75
ms, then starts operating in the selected mode.
5. その時は、JMが合図すると認めるためにJMの少なくとも2つの同じ系列を検出した後に呼ぶ端末がCMの現在の八重奏を終了するとCJを伝えます。 それは、ちょうど75msをポーズして、次に、選択されたモードで作動し始めます。
6. The answering terminal transmits JM until it has detected CJ. At
that point, it stops transmitting JM immediately, pauses exactly
75 ms, then starts operating in the selected mode.
6. CJを検出するまで、回答端末はJMを伝えます。 その時、それは、すぐにJMを伝えるのを止めて、ちょうど75msをポーズして、次に、選択されたモードで作動し始めます。
The CI, CM, and JM signals all consist of a fixed sequence of ten '1' bits followed by a signal-dependent pattern of ten synchronization bits, followed by one or more octets of variable information. Each octet is preceded by a '0' start bit and followed by a '1' stop bit. The combination of the synchronization pattern and V.21 channel uniquely identifies the message type. The CJ signal consists of three successive octets of all zeros with stop and start bits but without the preceding '1's and synchronizing pattern of the other signals.
CI、CM、およびJM信号は'1'ビットが可変情報の1つ以上の八重奏があとに続いた10同期ビットの信号依存するパターンを続けた10の固定系列からすべて成ります。 各八重奏に'0'スタートビットが先行して、'1'ストップビットはあとに続いています。 同期パターンとV.21チャンネルの組み合わせは唯一メッセージタイプを特定します。 CJ信号は停止とスタートビットにもかかわらず、'1と他の信号のパターンを同期すること'なしで前のすべてのゼロの3つの連続した八重奏から成ります。
Applications MAY report each instance of a CM, JM, and CJ signal, respectively, as a series of V.21 bit events (Section 2.2), or may use another payload type to carry this information. Applications supporting V.8 signalling using the telephone-event payload MAY report the synchronization part of the CI signal (ten '1's followed by '00000 00001') both as a series of V.21 bit events and, when it has been recognized, as a single CI event.
V.21のシリーズが出来事(セクション2.2)に噛み付くか、またはこの情報を運ぶのに別のペイロードタイプを使用するとき、アプリケーションはそれぞれCM、JM、およびCJ信号の各例を報告するかもしれません。 アプリケーションがともにV.21のシリーズとしてのCI信号('が1'00000 00001'続いた10)の同期部分が出来事に噛み付いたという電話イベントペイロード5月のレポートを使用することでV.8合図を支持して、それが認識されたときにはaとして、CIを選抜してください、出来事、'
Note that the CI event covers only the synchronization part of the
CI signal. The remaining call function octet and its start and
stop bits need to be transmitted also, either as a series of V.21
bit events or in some other payload format. Presumably, the
calling end gateway will use the same format for the CM and CJ
signals.
CI出来事がCI信号の同期部分だけを覆うことに注意してください。 その残っている呼び出し機能八重奏、始め、およびストップビットは、また、一連のV.21ビット出来事かある他のペイロード形式で伝えられる必要があります。 おそらく、呼んでいる終わりのゲートウェイはCMとCJ信号に同じ形式を使用するでしょう。
The overlapping nature of V.8 signalling means that there is no risk of silence exceeding 100 ms once ANSam has disabled any echo control circuitry. However, the 75-ms pause before entering operation in the selected data mode will require both the calling and the answering gateways to recognize the completion of CJ, so they can change from playout of telephone-event to playout of the data-bearing payload after the 75-ms period.
V.8合図の重なっている自然は、ANSamがいったんどんなエコー制御回路も損傷すると沈黙が100msを超えているというリスクが全くないことを意味します。 しかしながら、選択されたデータモードに操作を入れる前の75-msくぎりがCJの完成を認識するために呼ぶのと回答ゲートウェイの両方を必要とするので、データを持つペイロードの再生によってそれらは75-msの期間の後に変化できます。
Schulzrinne & Taylor Standards Track [Page 13] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[13ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
+--------+----------------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+--------+----------------------+------------+------+---------+
| ANSam | 2100 x 15 | 34 | tone | yes |
| | | | | |
| /ANSam | 2100 x 15 phase rev. | 35 | tone | yes |
| | | | | |
| CI | (V.21 bits) | 53 | tone | yes |
+--------+----------------------+------------+------+---------+
+--------+----------------------+------------+------+---------+ | 出来事| 頻度(Hz)| イベントコード| タイプ| ボリューム? | +--------+----------------------+------------+------+---------+ | ANSam| 2100x15| 34 | トーン| はい| | | | | | | | /ANSam| 2100x15は回転の位相を合わせます。 | 35 | トーン| はい| | | | | | | | CI| (V.21ビット) | 53 | トーン| はい| +--------+----------------------+------------+------+---------+
Table 3: Events for V.8 Signals
テーブル3: V.8信号のための出来事
ANSam:
ANSam:
The modified answer tone ANSam consists of a sinewave signal at
2100 Hz, amplitude-modulated by a sine wave at 15 Hz. The
beginning of the event is at the beginning of the tone. The end
of the event is at the sooner of the ending of the tone or the
occurrence of a phase reversal (marking the beginning of a /ANSam
event). Phase reversals are used to disable echo cancellation; if
they are being applied, they occur at 450-ms intervals.
変更された答えトーンANSamは15Hzでの正弦波による2100年にHzであって、振幅によって調節された正弦波信号から成ります。 トーンの始めに、出来事の始まりがあります。 出来事の終わりがトーンの結末かフェーズ反転の発生(/ANSam出来事の始まりを示す)について、より早さにあります。 フェーズ反転はエコーキャンセルを無効にするのに使用されます。 適用されているなら、450-ms間隔を置いて、それらは起こります。
An ANSam event packet SHOULD NOT be sent until it is possible to
discriminate between an ANSam event and an ANS event (see V.25
events, below).
ANSamイベントパケットSHOULD NOT、ANSam出来事とANS出来事を区別するのが可能になるまで(以下でV.25出来事を見てください)、送ってください。
The modulated envelope for the ANSam tone ranges in amplitude
between 0.8 and 1.2 times its average amplitude. The average
transmitted power is governed by national regulations. Thus, it
makes sense to indicate the volume of the signal.
ANSamトーンのための調節された封筒は平均した振幅の0.8〜1.2倍振幅のねらいを定めます。 平均した伝えられたパワーは国家規制で決定されます。 したがって、それは信号の量を示す意味になります。
/ANSam:
/ANSam:
/ANSam reports the same physical signal as ANSam, but is reported
following the first phase reversal in that signal. It begins with
the phase reversal and ends at the end of the tone. The receiver
of /ANSam MUST reverse the phase of the tone at the beginning of
playout of /ANSam and every 450 ms thereafter until the end of the
tone is reached.
/ANSamはANSamと同じ物理的信号を報告しますが、その信号における第1段階反転に続いて、報告されます。 それは、フェーズ反転で始まって、トーンの終わりで終わります。 トーンの端に達するまで、/ANSamの受信機はその後、/ANSamと450ms毎の再生の始めにおけるトーンのフェーズを逆にしなければなりません。
CI:
CI:
CI reports the occurrence of the V.21 bit pattern '11111 11111
00000 00001' indicating the beginning of a V.8 CI signal. The
event begins at the beginning of the first bit and ends at the end
of the last one. This event MUST NOT be reported except in a
context where a V.8 CI signal might be expected (i.e., at the
calling end during call setup). Note that if the calling modem
CIはV.8 CI信号の始まりを示すV.21ビット・パターン'11111 11111 00000 00001'の発生を報告します。 出来事は、最初のビットの始めに始まって、最後のものの終わりで終わります。 V.8 CI信号が予想されるかもしれない(すなわち、呼び出しセットアップの間の呼ぶ終わりに)文脈以外に、この出来事を報告してはいけません。 呼ぶモデムであるならそれに注意してください。
Schulzrinne & Taylor Standards Track [Page 14] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[14ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
sends the CI signal at all, it will typically repeat the signal
several times.
全く、信号を何度か通常繰り返すというCI信号を送ります。
It is expected that the CI event will be most useful when the
modem content is being transmitted primarily using another payload
type. The event acts as a commentary on that content, allowing
the receiver to recognize that V.8 signalling is in progress.
モデム内容が主として伝えられているとき、CI出来事が別のペイロードタイプを使用することで最も役に立つと予想されます。 V.8合図が進行していると認めるために受信機を許容して、出来事は論評としてその内容に機能します。
2.3.1. Handling of Congestion
2.3.1. 混雑の取り扱い
The tolerances built into V.8 suggest that it may be mostly robust in the face of packet losses or delays. Playout of ANSam and /ANSam can be extended for multiple packetization periods without harm, provided that phase reversals occur on schedule at 450-ms intervals during playout of the latter.
V.8が組み込まれた寛容は、それがパケット損失か遅れに直面してほとんど強健であるかもしれないと示唆します。 複数のpacketizationの期間、害がなくてANSamと/ANSamの再生を広げることができます、フェーズ反転が後者の再生の間、スケジュール通りに450-ms間隔を置いて起これば。
To increase robustness of transmission of the V.21-based signals, sending applications using the V.21 events SHOULD include an integral number of octets, including start and stop bits, in each packet. The presence of start and stop bits provides some hope that receiving implementations can withstand unavoidable gaps in playout between octets. When a message is being repeated (as is possible for CI, CM, and JM), an even stronger robustness measure would be for the receiver to retain a copy of the message when it is first received, and when a packet is delayed or lost to continue playing out the current message instance and commence a new repetition as if packets had continued to arrive on schedule.
V.21ベースの信号の伝達の丈夫さを増加させるように、V.21イベントSHOULDを使用する送付アプリケーションは整数の八重奏を含んでいます、始めとストップビットを含んでいて、各パケットで。 始めとストップビットの存在は八重奏の間で実現を受けると避けられないギャップに耐えることができるという何らかの希望を再生に提供します。 メッセージが繰り返されている、(CI、CM、およびJMに可能である、)、さらに強い丈夫さ測定は現在のメッセージ例を展開し続けて、まるでパケットがずっとスケジュール通りに到着したかのように新しい反復を始めるためにパケットを最初にそれを受け取って、遅らせるか、または失うとき、受信機がメッセージのコピーを保有するだろうことです。
2.4. V.25 Events
2.4. V.25出来事
V.25 [13] is a start-up protocol predating V.8 [9] and V.8 bis [10]. It specifies the exchange of two tone signals: CT and ANS.
V.25[13]は2回V.8[9]とV.8より前に起こる始動プロトコルです。[10]。 それはツートンカラーの信号の交換を指定します: コネチカットとANS。
CT (calling tone) consists of a series of interrupted bursts of 1300-Hz tone, on for a duration of not less than 0.5 s and not more than 0.7 s and off for a duration of not less than 1.5 s and not more than 2.0 s. [13]. Modems not starting with the V.8 CI signal often use this tone.
コネチカット(トーンと呼ぶ)は少なくとも0.5秒間と、より0.7秒間の持続時間にオンで少なくとも1.5秒間と、より2.0秒間の持続時間に、オフな1300Hzのトーンの一連の中断している炸裂から成ります。 [13]. V.8 CI信号から始まらないモデムがしばしばこのトーンを使用します。
ANS (Answer tone) is a 2100-Hz tone used to disable echo suppression for data transmission [13], [8]. For fax machines, Recommendation T.30 [8] refers to this tone as called terminal identification (CED) answer tone. ANS differs from V.8 ANSam in that, unlike the latter, it has constant amplitude.
ANS(答えトーン)はデータ伝送[13]、[8]のためのエコー抑圧を無効にするのに使用される2100Hzのトーンです。 端末の識別(CED)答えトーンと呼ばれるようにファックス装置について、Recommendation T.30[8]はこのトーンを参照します。 ANSは後者と異なってそれには一定振幅があるという点においてV.8 ANSamと異なっています。
V.25 specifically includes procedures for disabling echo suppressors as defined by ITU-T Rec. G.164 [6]. However, G.164 echo suppressors have now for the most part been replaced by G.165 [7] echo
V.25は明確にITU-T Recによって定義されるようにエコーサプレッサを損傷するための手順を含んでいます。 G.164[6]。 しかしながら、現在、G.164エコーサプレッサをG.165[7]エコーにだいたい取り替えました。
Schulzrinne & Taylor Standards Track [Page 15] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[15ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
cancellers, which require phase reversals in the disabling tone (see ANSam above). As a result, Recommendation V.25 was modified in July 2001 to say that phase reversal in the ANS tone is required if echo cancellers are to be disabled.
除去器。(その除去器は無能にするトーン(ANSamが上であることを見る)におけるフェーズ反転を必要とします)。 その結果、Recommendation V.25は、2001年7月にエコーキャンセラーは障害があるつもりであるならANSトーンにおけるフェーズ反転が必要であると言うように変更されました。
One possible V.25 sequence is as follows:
1つの可能なV.25系列は以下の通りです:
1. The calling terminal starts generating CT as soon as the call is
connected.
1. 呼び出しが接続されているとすぐに、呼ぶ端末はコネチカットを発生させ始めます。
2. The called terminal waits in silence for 1.8 to 2.5 s after
answer, then begins to transmit ANS continuously. If echo
cancellers are on the line, the phase of the ANS signal is
reversed every 450 ms. ANS will not reach the calling terminal
until the echo control equipment has been disabled. Since this
takes about a second, it can only happen in the gap between one
burst of CT and the next.
2. 呼ばれた端末は、1.8のために答えの何2.5秒間も後まで黙って待って、次に、絶え間なくANSを伝え始めます。 エコーキャンセラーが危ういなら、ANS信号のフェーズは逆にされて、エコー制御装置が無能にされるまであらゆる450原稿ANSが呼ぶ端末に届かないということです。 これがおよそ1秒かかるので、それはコネチカットの1回の炸裂と次のギャップで起こることができるだけです。
3. Following detection of ANS, the calling terminal may stop
generating CT immediately or wait until the end of the current
burst to stop. In any event, it must wait at least 400 ms (at
least 1 s if phase reversal of ANS is being used to disable echo
cancellers) after stopping CT before it can generate the calling
station response tone. This tone is modem-specific, not
specified in V.25.
3. ANSの検出に続いて、電流の端が止まるためにはち切れるまで、呼ぶ端末は、すぐにコネチカットを発生させるのを止めるか、または待つかもしれません。 とにかく、それは起呼端末応答トーンを発生させることができる前にコネチカットを止めた後の待少なくとも400ちms(少なくとも、1秒間はANSのフェーズ反転であるならエコーキャンセラーを無能にするために費やされている)がそうしなければなりません。 このトーンはV.25で指定されているのではなく、モデム特有です。
4. The called terminal plays out ANS for 2.6 to 4.0 seconds or until
it has detected calling station response for 100 ms. It waits
55-95 ms (nominal 75 ms) in silence. (Note that the upper limit
of 95 ms is rather close to the point at which echo control may
reestablish itself.) If the reason for ANS termination was
timeout rather than detection of calling station response, the
called terminal begins to play out ANS again to maintain
disabling of echo control until the calling station responds.
4. 呼ばれた端末が2.6〜4.0秒間、ANSを終えるか、または100のための起呼端末応答を検出するまで、原稿Itは55-95 黙っているms(名目上の75ms)を待っています。 (むしろエコー制御がそれ自体を復職させるかもしれないポイントの近くに95msの上限があることに注意してください。) ANS終了の理由が起呼端末応答の検出よりむしろタイムアウトであったなら、呼ばれた端末は、起呼端末が応じるまでエコー制御を無能にすることを維持するために再びANSを終え始めます。
The events defined for V.25 signalling are shown in Table 4.
V.25合図のために定義された出来事はTable4に示されます。
+-------------------+----------------+------------+------+---------+ | Event | Frequency (Hz) | Event Code | Type | Volume? | +-------------------+----------------+------------+------+---------+ | Answer tone (ANS) | 2100 | 32 | tone | yes | | | | | | | | /ANS | 2100 ph. rev. | 33 | tone | yes | | | | | | | | CT | 1300 | 49 | tone | yes | +-------------------+----------------+------------+------+---------+
+-------------------+----------------+------------+------+---------+ | 出来事| 頻度(Hz)| イベントコード| タイプ| ボリューム? | +-------------------+----------------+------------+------+---------+ | 答えトーン(ANS)| 2100 | 32 | トーン| はい| | | | | | | | /ANS| 2100ph回転。 | 33 | トーン| はい| | | | | | | | コネチカット| 1300 | 49 | トーン| はい| +-------------------+----------------+------------+------+---------+
Table 4: Events for V.25 Signals
テーブル4: V.25信号のための出来事
Schulzrinne & Taylor Standards Track [Page 16] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[16ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
ANS:
ANS:
The beginning of the event is at the beginning of the 2100-Hz
tone. The end of the event is at the sooner of the ending of the
tone or the occurrence of a phase reversal (marking the beginning
of a /ANS event).
2100Hzのトーンの始めに、出来事の始まりがあります。 出来事の終わりがトーンの結末かフェーズ反転の発生(/ANS出来事の始まりを示す)について、より早さにあります。
An initial ANS event packet SHOULD NOT be sent until it is
possible to discriminate between an ANS event and an ANSam event
(see V.8 events, above).
ANSイベントパケットSHOULD NOTに頭文字をつけてください。ANS出来事とANSam出来事を区別するのが可能になるまで(V.8出来事を見てください、上です)、送ってください。
/ANS:
/ANS:
/ANS reports the same physical signal as ANS, but is reported
following the first phase reversal in that signal. It begins with
the phase reversal and ends at the end of the tone. The receiver
of /ANS MUST reverse the phase of the tone at the beginning of
playout of /ANS and every 450 ms thereafter until the end of the
tone is reached.
/ANSはANSと同じ物理的信号を報告しますが、その信号における第1段階反転に続いて、報告されます。 それは、フェーズ反転で始まって、トーンの終わりで終わります。 トーンの端に達するまで、/ANS MUSTの受信機はその後、/ANSと450ms毎の再生の始めにおけるトーンのフェーズを逆にします。
CT:
コネチカット:
The beginning of the CT event is at the beginning of an individual
burst of the 1300-Hz tone. The end of the event is at the end of
that tone burst. The gateway at the calling end SHOULD use a
packetization interval smaller than the nominal duration of a CT
burst, to ensure that CT playout at the called end precedes the
sending of ANS from that end.
1300Hzのトーンの個々の炸裂の始めに、コネチカット出来事の始まりがあります。 そのトーン・バーストの終わりに、出来事の終わりがあります。 SHOULDがコネチカットの名目上の持続時間がはち切れたより小さくpacketization間隔を費やす呼ぶ終わりのゲートウェイ、呼ばれた終わりにそのコネチカット再生を確実にするのはその終わりからANSの発信に先行します。
2.4.1. Handling of Congestion
2.4.1. 混雑の取り扱い
The V.25 sequence appears to be robust in the face of lost or delayed packets, provided that the receiver continues to play out any tone it is in the process of playing until more packets are received. The receiver must play out the phase transitions for /ANS on schedule, at 450-ms intervals, even if updates of the /ANS event have been delayed. It also appears to be possible for the sender to temporarily increase the packetization interval to reduce packet volumes when congestion is encountered. The one risk is that extended playout proceeds past the actual end of the tone (as determined retroactively), and the receiver is forced to continue imposing an additional playout buffering lag in order to meet the constraint on maximum duration of the nominal 75-ms silent period following tone playout.
V.25系列は無くなっているか遅れたパケットに直面して強健であるように見えて、受信機が、どんなトーンも終え続けていれば、より多くのパケットが受け取られているまでプレーすることの途中にそれはあります。 受信機はスケジュール通りの/ANSのために相転移を終えなければなりません、450-ms間隔で、/ANS出来事のアップデートを遅らせても。 また、送付者が混雑が遭遇するとき、パケットボリュームを減少させるためにpacketization間隔を一時増加させるのが、可能であるように見えます。 1つのリスクは拡張再生がトーンの実際の終わりを過ぎて続くという(遡及して決定するように)ことです、そして、受信機はやむを得ず名目上の75-ms沈黙期次のトーン再生の最大の持続時間で規制を満たすために立ち遅れをバッファリングする追加再生を課し続けています。
Schulzrinne & Taylor Standards Track [Page 17] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[17ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
2.5. V.32/V.32bis Events
2.5. V.32/V.32bis出来事
ITU-T Recommendation V.32 [14] is a modem using phase-shift keying with quadrature amplitude modification. It operates on a carrier at 1800 Hz, modulated at 2400 symbols/s. The basic data rates for V.32 are 4800 and 9600 bits/s. V.32bis [15] extends the data rates up to 14,400 bits/s. Most or all existing deployments are V.32bis, typically in support of point-of-sale terminals and the like.
ITU-T Recommendation V.32[14]は矩振幅変更によるフェーズシフトの合わせることを使用するモデムです。 それは2400シンボル/sで調節された1800Hzでキャリヤーを経営しています。 V.32の基礎データレートは4800と9600ビット/sです。 V.32bis[15]はデータ信号速度を1万4400ビット/sまで広げています。 大部分かすべての既存の展開が通常売場専用端末と同様のものを支持したV.32bisです。
One reason V.32bis is still used is because of its relatively rapid start-up sequence, particularly on leased lines. Operating over the public telephone network, the start-up begins as follows:
比較的急速な起動順序と、特に専用線の上にV.32bisがまだ使用されている1つの理由があります。 公衆電話ネットワークの上で作動して、始動は以下の通り始まります:
a. the answering end begins with the V.25 answering procedure (1.8
to 2.5 s of silence followed by continuous ANS tone to a maximum
of 3.3 s, with possible phase reversals to disable echo
cancelling equipment);
V.25が手順に答えていてa.回答終わりが始まる、(2.5秒間の沈黙への1.8が連続したANSトーンで続いた、最大設備を取り消しながらエコーを無能にする可能なフェーズ反転がある3.3秒間、)、。
b. the calling end waits in silence until it has detected ANS for
1 s;
1秒間ANSを検出するまで呼ぶ終わりが黙って待つb.。
c. the calling end begins to transmit a V.32/V.32bis pattern
designated AA, i.e., a series of '0000' bit sequences transmitted
at 4800 bits/s;
c. 呼ぶ終わりはAAに指定されたV.32/V.32bisパターンを伝え始めます、4800ビット/sで伝えられたすなわち一連の'0000'ビットの系列。
d. upon detecting the AA pattern for at least 100 ms, the called
modem is silent for 75 +/- 20 ms, then responds with an AC
pattern, which is a series of '0011' bit sequences transmitted at
4800 bits/s.
噛み付いている系列は、4800ビット/sで'd. 少なくとも100msのためにAAパターンを検出するとき、呼ばれたモデムは、75+/-20msに静かであり、次に、0011年のシリーズである交流パターンで反応します'と伝えました。
The difference in leased line operation is that the calling modem starts the session by sending AA. After that, the called modem responds with AC, and the rest of the sequence is unchanged.
専用線操作の違いは呼ぶモデムがAAを送ることによってセッションを始めるということです。 その後に、呼ばれたモデムは西暦で反応します、そして、系列の残りは変わりがありません。
In support of V.32/V.32bis operation, Table 5 defines two events, V32AA and V32AC.
V.32/V.32bis操作を支持して、Table5は2回の出来事、V32AA、およびV32ACを定義します。
+----------------+------------------+------------+------+---------+
| Event | Bit Pattern | Event Code | Type | Volume? |
+----------------+------------------+------------+------+---------+
| V32AA | b'0000' repeated | 63 | tone | yes |
| | | | | |
| V32AC | b'0011' repeated | 27 | tone | yes |
+----------------+------------------+------------+------+---------+
+----------------+------------------+------------+------+---------+ | 出来事| ビット・パターン| イベントコード| タイプ| ボリューム? | +----------------+------------------+------------+------+---------+ | V32AA| b'0000'は繰り返されました。| 63 | トーン| はい| | | | | | | | V32AC| 'b0011年'は繰り返されました。| 27 | トーン| はい| +----------------+------------------+------------+------+---------+
Table 5: Events for V.32/V.32bis Signals
テーブル5: V.32/V.32bis信号のための出来事
Schulzrinne & Taylor Standards Track [Page 18] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[18ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
V32AA:
V32AA:
Indicates that the AA calling pattern of a V.32/V.32bis terminal
has been detected.
V.32/V.32bisのパターンが端末であると言うAAが検出されたのを示します。
V32AC:
V32AC:
Indicates that the AC answering pattern of a V.32/V.32bis terminal
has been detected.
V.32/V.32bis端末の交流回答パターンが検出されたのを示します。
Each of these two events begins at the beginning of its pattern, and ends nominally when the pattern stops being received. Following the sending of either of these events the session may continue using V.150.1 modem relay [32] or Clearmode [17] as negotiated or configured in advance. To help make the transition as quickly as possible, the V32AA or V32AC event SHOULD be reported as soon as the corresponding pattern is detected. It seems likely that the implementation will be transmitting the event reports simultaneously with the same data in an alternate form, typically using RFC 2198 [2] redundancy.
それぞれのこれらの2回の出来事が、パターンの始めに始まって、パターンが、受け取られるのを止めると、名目上は終わります。 これらの出来事のどちらかの発信に続いて、セッションは、[17] あらかじめ交渉されるか、または構成されるようにV.150.1モデムリレー[32]かClearmodeを使用し続けるかもしれません。 助けるために、できるだけはやく変遷をしてください、V32AA、V32ACイベントSHOULD、対応するパターンが検出されるとすぐに、報告されてください。 実現は同時に交互のフォームで同じデータでイベントレポートを伝えそうでしょう、RFC2198[2]冗長を通常使用して。
2.5.1. Handling of Congestion
2.5.1. 混雑の取り扱い
The primary issue raised by congestion is the loss or undue delay of the initial report. Once the receiver is aware that an AA or AC pattern has been detected, further reports are of no interest. The actual duration of the AC pattern may be as short as 27 ms. On this basis, the appropriate sender behavior may be to send at least three packets reporting the event using normal event updates and end of event retransmission behavior and a fairly short packetization interval (20-30 ms).
混雑で提起された第一の問題は、初期のレポートの損失か不当な遅延です。 受信機がいったんAAか交流パターンが検出されたのを意識するようになると、さらなるレポートは全くおもしろくはありません。 少なくとも3つのパケットに27原稿Onとして出来事を急に報告させるようにこの基礎、適切な送付者の振舞いがことであるかもしれない交流パターンの実際の持続時間が、通常のイベントアップデート、イベント「再-トランスミッション」の振舞いの終わり、およびかなり短いpacketization間隔(20-30 ms)を費やすことであるかもしれません。
2.6. T.30 Events
2.6. T.30出来事
ITU-T Recommendation T.30 [8] defines the procedures used by Group III fax terminals. The pre-message procedures for which the events of this section are defined are used to identify terminal capabilities at each end and negotiate operating mode. Post-message procedures are also included, to handle cases such as multiple document transmission. Fax terminals support a wide variety of protocol stacks, so T.30 has a number of options for control protocols and sequences.
ITU-T Recommendation T.30[8]はGroup IIIファックス端末によって用いられた手順を定義します。 このセクションの出来事が定義されるプレメッセージ手順は、各端のときに端末の能力を特定して、オペレーティング・モードを交渉するのに用いられます。 また、ポストメッセージ手順は、複数のドキュメントトランスミッションなどのケースを扱うために含まれています。 ファックスで、T.30には制御プロトコルと系列のための多くのオプションがあるようにさまざまなプロトコル・スタックを端末サポートに送ってください。
T.30 defines two tone signals used at the beginning of a call. The CNG signal is sent by the calling terminal. It is a pure 1100-Hz tone played in bursts: 0.5 s on, 3 s off. It continues until timeout
T.30は呼び出しの始めに使用されたツートンカラーの信号を定義します。 呼ぶ端末はCNG信号を送ります。 それは炸裂でプレーされた純粋な1100Hzのトーンです: オンで、オフさ3秒間の0.5秒間。 それはタイムアウトまで続きます。
Schulzrinne & Taylor Standards Track [Page 19] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[19ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
or until the calling terminal detects a response. Its primary purpose is to let human operators at the called end know that a fax terminal has been activated at the calling end.
または、呼ぶまで、端末は応答を検出します。 第一の目的は呼ばれた終わりの人間のオペレータにファックス端末が呼ぶ終わりに動いたのを知らせることです。
The called terminal waits in silence for at least 200 ms. It then may return CED tone (which is physically identical to V.25 ANS), or else V.8 ANSam if it has V.8 capability. If called and calling terminals both support V.8, the called terminal will detect CI or more likely CM in response to its ANSam and will continue with V.8 negotiation. Otherwise, the called terminal stops transmitting CED after 2.6 to 4 seconds, waits 75 +/- 20 ms in silence, then enters the T.30 negotiation phase.
それにV.8能力があるなら、呼ばれた端末は少なくとも次に原稿ItがCEDトーン(肉体的にV.25 ANSと同じである)、またはV.8 ANSamを返すかもしれない200のために黙って待っています。 呼ばれて、端末と呼ぶなら両方がV.8を支持して、呼ばれた端末は、ANSamに対応してCIかおそらくCMを検出して、V.8交渉を続行するでしょう。 さもなければ、呼ばれた端末は、2.6〜4秒以降CEDを伝えるのを止めて、黙っている75+/-20msを待っていて、次に、T.30交渉フェーズに入れます。
In the T.30 negotiation phase the terminals exchange binary messages using V.21 signals, high channel frequencies only, at 300 bits/s. Each message is preceded by a one-second (nominal) preamble consisting entirely of HDLC flag octets (0x7E). This flag has the function of preparing echo control equipment for the message that follows.
T.30交渉フェーズでは、端末は、300ビット/sでV.21信号、高いチャンネル周波数だけを使用することで2進のメッセージを交換します。 HDLC旗の八重奏(0x7E)から完全に成る2分の1の(名目上)の序文は各メッセージに先行します。 この旗には、従うメッセージのためにエコー制御装置を準備する機能があります。
The pre-transfer messages exchanged using the V.21 coding are:
V.21コード化を使用することで交換されたプレ転送メッセージは以下の通りです。
Digital Identification Signal (DIS):
デジタル識別信号(けなします):
Characterizes the standard ITU-T capabilities of the called
terminal. This is always the first message sent.
呼ばれた端末の標準のITU-T能力を特徴付けます。 いつもこれは送られた最初のメッセージです。
Digital Transmit Command (DTC):
デジタル伝えコマンド(DTC):
A possible response to the DIS signal by the calling terminal. It
requests the called terminal to be the transmitter of the fax
content.
呼ぶ端末のそばのDIS信号への可能な応答。 それは、ファックス内容の送信機であるよう呼ばれた端末に要求します。
Digital Command Signal (DCS):
デジタル指令信号(DCS):
A command message sent by the transmitting terminal to indicate
the options to be used in the transmission and request that the
other end prepare to receive fax content. This is sent by the
calling end if it will transmit, or by the called end in response
to a DTC from the calling end. It is followed by a training
signal, also sent by the transmitting terminal.
伝える端末によって送られた、トランスミッションに使用されて、他が終わるよう要求するオプションが、ファックス内容を受け取るのを準備するのを示したコマンドメッセージ。 伝わるか、または呼ぶことで呼ぶ終わりからのDTCに対応して終わるなら、呼ぶ終わりまでにこれを送ります。 それをトレーニング信号が支えていて、また、伝える端末は送ります。
Confirmation To Receive (CFR):
受け取る確認(CFR):
A digital response confirming that the entire pre-message
procedure including training has been completed and the message
transmissions may commence.
訓練するのを含む全体のプレメッセージ手順が完了したと確認するデジタル応答とメッセージ送信は始まるかもしれません。
Schulzrinne & Taylor Standards Track [Page 20] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[20ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
Each message may consist of multiple frames bounded by HDLC flags. The messages are organized as a series of octets, but like V.8 bis, T.30 calls for the insertion of extra '0' bits to prevent spurious recognition of HDLC flags.
各メッセージはHDLC旗によって境界がある複数のフレームから成るかもしれません。 メッセージは一連の八重奏として組織化されますが、V.8のように、2回、T.30は、余分な'0'ビットの挿入がHDLC旗の偽りの認識を防ぐように求めます。
T.30 also provides for the transmission of control messages after document transmission has completed (e.g., to support transmission of multiple documents). The transition to and from the modem used for document transmission (V.17 [24], V.27ter [26], V.29 [27], V.34 [28]) is preceded by 75 ms (nominal) of silence).
また、T.30はトランスミッションが完成した(例えば複数のドキュメントの伝達を支持する)ドキュメントの後にコントロールメッセージの伝達に備えます。 使用モデムとドキュメントトランスミッション(V.17[24]、V.27ter[26]、V.29[27]、V.34[28])は沈黙で(名目上)で75msによって先行されている)のための使用モデムからの変遷。
Applications supporting T.30 signalling using the telephone-event payload MAY report the preamble preceding each message both as a series of V.21 bit events and, when it has been recognized, as a single V.21 preamble event. The T.30 control message following the preamble MAY be reported in the form of a sequence of V.21 bit events or using some other payload type. If transmitted as bit events, the transmitted information MUST include the complete contents of the message: the initial HDLC flags, the information field, the checksum, the terminating HDLC flags, and the extra '0' bits added to prevent false recognition of HDLC flags at the receiver. Implementers should note that these extra '0' bits mean that in general T.30 messages as transmitted on the wire will not come out to an even multiple of octets.
電話イベントペイロードを使用することでT.30合図を支持するアプリケーションは一連のV.21ビット出来事として両方の、各メッセージに先行する序文を報告するかもしれません、そして、それが認識されたときにはaとして、V.21を選抜してください。序文イベント。 序文に従うT.30コントロールメッセージは、V.21ビット出来事の系列の形で報告されるか、またはある他のペイロードタイプを使用しているかもしれません。 噛み付いている出来事として伝えられるなら、伝達情報量はメッセージの完全なコンテンツを含まなければなりません: 初期のHDLCは弛みます、と情報フィールド、チェックサム、HDLCが旗を揚げさせる終わり、および余分な'0'ビットは受信機でHDLC旗の誤認を防ぐために言い足しました。Implementersは、これらの余分な'0'ビットが、一般に、ワイヤの上に送られるT.30メッセージが八重奏の同等の倍数まで出て来ないことを意味することに注意するはずです。
The training signal sent by the transmitting terminal after DCS consists of a steady string of V.21 high channel zeros (1850-Hz tone) for 1.5 s. Since the bit rate (nominally 300 bits/s) should have been clearly established when processing the preceding signalling, it is natural that if the telephony-event payload type is being used, this training signal will also be sent as a series of V.21 bit events at that bit rate. However, if the sending gateway is capable of recognizing the transition from the end of the DCS to the start of training, it MAY report the training signal as a single extended V.21 (high channel) '0' event.
DCSがV.21の高いチャンネルのしっかりとしているストリングから成った後に伝える端末によって送られたトレーニング信号は1.5秒間、(1850Hzのトーン)のゼロに合っています。 ビット伝送速度、(また、電話イベントペイロードタイプを使用していると、一連のV.21ビット出来事としてそのビット伝送速度でこのトレーニング信号を送るのは前の合図を処理するとき、名目上は、300ビット/s)が明確に設立されるべきであったのが当然です。 しかしながら、送付ゲートウェイがDCSの端から変遷をトレーニングの始まりまで認識できるなら、シングルがV.21(高いチャンネル)'0'出来事を広げているのに従って、それはトレーニング信号を報告するかもしれません。
The events defined for T.30 signalling are shown in Table 6. The CED and /CED events represent exactly the same tone signals as V.25 ANS and /ANS, and are given the same codepoints; they are reproduced here only for convenience.
T.30合図のために定義された出来事はTable6に示されます。 CEDと/CED出来事は、まさにV.25 ANSと/ANSと同じトーン信号を表して、同じcodepointsを与えます。 それらは便宜のためだけにここで再生します。
Schulzrinne & Taylor Standards Track [Page 21] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[21ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
+--------------------+----------------+------------+------+---------+ | Event | Frequency (Hz) | Event Code | Type | Volume? | +--------------------+----------------+------------+------+---------+ | CED (Called tone) | 2100 | 32 | tone | yes | | | | | | | | /CED | 2100 ph. rev. | 33 | tone | yes | | | | | | | | CNG (Calling tone) | 1100 | 36 | tone | yes | | | | | | | | V.21 preamble flag | (V.21 bits) | 54 | tone | yes | +--------------------+----------------+------------+------+---------+
+--------------------+----------------+------------+------+---------+ | 出来事| 頻度(Hz)| イベントコード| タイプ| ボリューム? | +--------------------+----------------+------------+------+---------+ | CED(トーンと呼ばれます)| 2100 | 32 | トーン| はい| | | | | | | | /CED| 2100ph回転。 | 33 | トーン| はい| | | | | | | | CNG(トーンと呼びます)| 1100 | 36 | トーン| はい| | | | | | | | V.21序文旗| (V.21ビット) | 54 | トーン| はい| +--------------------+----------------+------------+------+---------+
Table 6: Events for T.30 Signals
テーブル6: T.30信号のための出来事
CED:
CED:
The beginning of the event is at the beginning of the 2100-Hz
tone. The end of the event is at the sooner of the ending of the
tone or the occurrence of a phase reversal (marking the beginning
of a /CED event).
2100Hzのトーンの始めに、出来事の始まりがあります。 出来事の終わりがトーンの結末かフェーズ反転の発生(/CED出来事の始まりを示す)について、より早さにあります。
An initial CED event packet SHOULD NOT be sent until it is
possible to discriminate between a CED event and an ANSam event
(see V.8 events, above).
CEDイベントパケットSHOULD NOTに頭文字をつけてください。CED出来事とANSam出来事を区別するのが可能になるまで(V.8出来事を見てください、上です)、送ってください。
/CED:
/CED:
/CED reports the same physical signal as CED, but is reported
following the first phase reversal in that signal. It begins with
the phase reversal and ends at the end of the tone. The receiver
of /CED MUST reverse the phase of the tone at the beginning of
playout of /CED and every 450 ms thereafter until the end of the
tone is reached.
/CEDはCEDと同じ物理的信号を報告しますが、その信号における第1段階反転に続いて、報告されます。 それは、フェーズ反転で始まって、トーンの終わりで終わります。 トーンの端に達するまで、/CED MUSTの受信機はその後、/CEDと450ms毎の再生の始めにおけるトーンのフェーズを逆にします。
CNG:
CNG:
The beginning of the CNG event is at the beginning of an
individual burst of the 1100-Hz tone. The end of the event is at
the end of that tone burst.
1100Hzのトーンの個々の炸裂の始めに、CNG出来事の始まりがあります。 そのトーン・バーストの終わりに、出来事の終わりがあります。
V.21 preamble flag:
V.21序文旗:
This event begins with the first V.21 bits transmitted after a
period of silence. It ends when a pattern of V.21 bits other than
an HDLC flag is observed. This means that the V.21 preamble event
absorbs the initial HDLC flags of the following message.
最初のV.21ビットが沈黙の期間の後に伝えられている状態で、この出来事は始まります。 HDLC旗以外のV.21ビットのパターンが観測されるとき、それは終わります。 これは、V.21序文イベントが以下のメッセージの初期のHDLC旗を吸収することを意味します。
Schulzrinne & Taylor Standards Track [Page 22] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[22ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
It is expected that the V.21 preamble flag event will be most
useful when the modem content is being transmitted primarily using
another payload type. The event acts as a commentary on that
content, allowing the receiver to prepare itself to transition to
fax mode.
モデム内容が主として伝えられているとき、V.21序文旗のイベントが別のペイロードタイプを使用することで最も役に立つと予想されます。 受信機がファックスでモードを送るために変遷に準備するのを許容して、出来事は論評としてその内容に機能します。
2.6.1. Handling of Congestion
2.6.1. 混雑の取り扱い
T.30 appears to be an intermediate case in terms of its vulnerability to congestion. Tone playout in the face of packet delay or loss is subject to the same considerations as for V.25 (see Section 2.4.1). Similarly, the receiver may extend playout of the preamble event while waiting for further reports. However, gaps or extended playout of the V.21 sequences are not feasible. This means, as with V.8 bis, that the receiver must manage its playout buffer appropriately to increase robustness in the face of congestion.
T.30は、混雑への脆弱性に関する中間的ケースであるように見えます。 パケット遅れか損失に直面してトーン再生はV.25のように同じ問題を受けることがあります(セクション2.4.1を見てください)。 同様に、受信機はさらなるレポートを待っている間、序文イベントの再生を広げるかもしれません。 しかしながら、V.21系列のギャップか拡張再生が可能ではありません。 これがV.8のように2回意味する、受信機は、混雑に直面して丈夫さを増加させるように適切に再生バッファを管理しなければなりません。
2.7. Events for Text Telephony
2.7. テキスト電話のための出来事
2.7.1. Signal Format Indicators for Text Telephony
2.7.1. テキスト電話のための信号形式インディケータ
Legacy text telephony uses a wide variety of terminals, with different standards favored in different parts of the world. Going forward, the vision is that new terminals will work directly into the packet network and be based on RFC 4103 [18] packetization of character data. In anticipation of this migration, it is RECOMMENDED that text carried in the PSTN by legacy modem protocols be converted to RFC 4103 packets at the sending gateway.
遺産テキスト電話は世界のいろいろな地方で支持される異なった規格と共にさまざまな端末を使用します。 進んでいて、ビジョンは新しい端末が直接パケット網に取り組んで、キャラクタデータのRFC4103[18]packetizationに基づいているということです。 この移動を予測して、PSTNで遺産モデムプロトコルによって運ばれたテキストが送付ゲートウェイのRFC4103パケットに変換されるのは、RECOMMENDEDです。
During a transitional period, however, gateways of a lesser capability may be able to recognize the nature of incoming content, but may only be able to encode it as voice-band data on the packet side. In such circumstances, it will help to optimize processing of the signal at the receiving end if that end receives an indication of the nature of the voice-encoded data signals. The events defined in this section provide such indications, and MAY be used in conjunction with ITU-T Recommendation V.152 [33], as one example, to carry the content as voice-band data.
過渡的な期間、しかしながら、より少ない能力のゲートウェイは、入って来る内容の本質を認識できますが、パケットに関する音声帯域データに面があるとき、それをコード化できるだけであるかもしれません。 そのような事情では、その終わりが声でコード化されたデータ信号の本質のしるしを受けると、それは、犠牲者に信号の処理を最適化するのを助けるでしょう。 このセクションで定義された出来事は、そのような指摘を提供して、音声帯域データとして内容を運ぶのに1つの例としてITU-T Recommendation V.152[33]に関連して使用されるかもしれません。
Implementers should take note of an additional class of text terminals not considered in the events below. These terminals use dual tone multi-frequency (DTMF) tones to encode and exchange signals. This application is described in RFC 4733 [5], Section 3.1, in conjunction with the registration of DTMF events.
Implementersは以下の出来事で考えられなかった追加クラスのテキスト端末に注目するはずです。 これらの端末はコード化する二元的なトーン多重周波数(DTMF)トーンと交換信号を使用します。 このアプリケーションはRFC4733[5]、セクション3.1でDTMF出来事の登録に関連して説明されます。
Schulzrinne & Taylor Standards Track [Page 23] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[23ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
The events shown in Table 7 correspond to signals coming from the following modem types:
Table7に示された出来事は以下のモデムタイプから来る信号に対応しています:
o Baudot [34], a five bit character encoding nominally operating at
45.45 or 50 bits/s with frequencies 1800 Hz = '0', 1400 Hz = '1';
o Baudot[34]、名目上は1800Hzの頻度で45.45か50ビット/sでの作動をコード化する5ビットのキャラクタは'0'、1400Hz='1'と等しいです。
o EDT, which is V.21 [12] operating at 110 bits/s in half-duplex
mode (lower channel only); characters are 7-bit IA5 plus initial
start bit, trailing parity bit, and two stop bits;
o 東部夏時間、半分のデュプレックスモード(低いチャンネル専用)における110ビット/sで作動するV.21[12]であるもの。 キャラクタは、7ビットのIA5と、初期のスタートビットと、引きずっているパリティビットと、2つのストップビットです。
o Bell 103 mode (documented in Recommendation V.18 Annex D), which
is structurally similar to V.21, but uses different frequencies:
lower channel, 1070 Hz = '0', 1270 Hz = '1'; upper channel, 2025
Hz = '0', 2225 Hz = '1'; characters are US ASCII framed by one
start bit, one trailing parity bit, and one stop bit;
o ベル103モード(Recommendation V.18 Annex Dに記録されます):(構造的にV.21と同様ですが、それは、異なった頻度を使用します)。 1070Hzの低いチャンネルは'0'、1270Hz='1'と等しいです。 2025Hzの上側のチャンネルは'0'、2225Hz='1'と等しいです。 キャラクタは1つのスタートビット、1つの引きずっているパリティビット、および1つのストップビットによって縁どられた米国ASCIIです。
o V.23 [25] based videotex, in Minitel and Prestel versions. V.23
offers a forward channel operating at 1200 bits/s if possible
(2100 Hz = '0', 1300 Hz = '1') or otherwise at 600 bits/s (1700 Hz
= '0', 1300 Hz = '1'), and a 75 bits/s backward channel, which is
transmitting 390 Hz (continuous '1's) except when '0' is to be
transmitted (450 Hz);
o V.23[25]はミニテルにおけるビデオテックスとプレステルバージョンを基礎づけました。 V.23はできれば(2100Hzは'0'、1300Hz='1'と等しい)かそうでなければ、600ビット/s(1700Hzは'0'、1300Hz='1'と等しい)で1200ビット/sで働いている順方向通信路、および75ビット/sの逆方向通信路を提供します。('0は'伝えられる(450Hz)ことである'時を除いて、その逆方向通信路は、390Hz(連続した'1)伝わっています)。
o a non-V.18 text terminal using V.21 [12] at 300 bits/s.
Characters are 7-bit national (e.g., US ASCII) with a start bit,
parity, and one stop bit.
o 300ビット/sでV.21[12]を使用する非V.18テキスト端末。 キャラクターは、ぎくっとして噛み付かれた、7ビットの同胞(例えば、米国ASCII)と、同等と、あるストップビットです。
Schulzrinne & Taylor Standards Track [Page 24] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[24ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
+----------+-----------+----------------+---------+-------+---------+ | Event | Bit Rate | Frequency (Hz) | Event | Type | Volume? | | | bits/s | | Code | | | +----------+-----------+----------------+---------+-------+---------+ | ANS2225 | N/A | 2225 | 52 | tone | yes | | | | | | | | | V21L110 | 110 | 980/1180 | 55 | other | no | | | | | | | | | V21L300 | 300 | 980/1180 | 30 | other | no | | | | | | | | | V21H300 | 300 | 1650/1850 | 31 | other | no | | | | | | | | | B103L300 | 300 | 1070/1270 | 56 | other | no | | | | | | | | | V23Main | 600/1200 | 1700-2100/1300 | 57 | other | no | | | | | | | | | V23Back | 75 | 450/390 | 58 | other | no | | | | | | | | | Baud4545 | 45.45 | 1800/1400 | 59 | other | no | | | | | | | | | Baud50 | 50 | 1800/1400 | 60 | other | no | | | | | | | | | XCIMark | 1200 | 2100/1300 | 62 | tone | yes | +----------+-----------+----------------+---------+-------+---------+
+----------+-----------+----------------+---------+-------+---------+ | 出来事| ビット伝送速度| 頻度(Hz)| 出来事| タイプ| ボリューム? | | | ビット/s| | コード| | | +----------+-----------+----------------+---------+-------+---------+ | ANS2225| なし| 2225 | 52 | トーン| はい| | | | | | | | | V21L110| 110 | 980/1180 | 55 | 他| いいえ| | | | | | | | | V21L300| 300 | 980/1180 | 30 | 他| いいえ| | | | | | | | | V21H300| 300 | 1650/1850 | 31 | 他| いいえ| | | | | | | | | B103L300| 300 | 1070/1270 | 56 | 他| いいえ| | | | | | | | | V23Main| 600/1200 | 1700-2100/1300 | 57 | 他| いいえ| | | | | | | | | V23Back| 75 | 450/390 | 58 | 他| いいえ| | | | | | | | | Baud4545| 45.45 | 1800/1400 | 59 | 他| いいえ| | | | | | | | | Baud50| 50 | 1800/1400 | 60 | 他| いいえ| | | | | | | | | XCIMark| 1200 | 2100/1300 | 62 | トーン| はい| +----------+-----------+----------------+---------+-------+---------+
Table 7: Indicators for Text Telephony
テーブル7: テキスト電話のためのインディケータ
ANS2225:
ANS2225:
indicates that a 2225-Hz answer tone has been detected. This is a
pure tone with no amplitude modulation and no semantics attached
to phase reversals, if there are any. The sender SHOULD report
the beginning of the event when the tone is detected. The sender
MAY send updates as the tone continues, and MUST report the end of
the event when the tone ceases. The tone concerned is generated
by a Bell 103-type modem in answer mode. This event MUST NOT be
reported outside of the startup context (i.e., on the answering
side at the beginning of a call).
2225Hzの答えトーンが検出されたのを示します。 いずれかあれば、これは振幅変調がなくて意味論が全く反転の位相を合わせるために付けられていない純音です。 送付者SHOULDはトーンが検出される出来事の始まりを報告します。 送付者は、トーンが続くようにアップデートを送るかもしれなくて、トーンがやむ出来事の終わりを報告しなければなりません。 関するトーンはベルの103タイプのモデムでアンサーモードで発生します。 始動文脈(すなわち、呼び出しの始めの回答側の)の外でこの出来事を報告してはいけません。
V21L110:
V21L110:
indicates that the sender has detected V.21 modulation operating
in the lower channel at 110 bits/s. Note that it may take some
time to distinguish between 300 bits/s and 110 bits/s operation.
It is expected that implementations will not transmit both this
event and individual V.21 bit events for the same content.
送付者が、V.21変調が110ビット/sの低いチャンネルで作動するのを検出したのを示します。 300ビット/sを見分けるいつかの時間と110ビット/sの操作がかかるかもしれないことに注意してください。 実現が同じ内容のためにこの出来事と個々のV.21ビット出来事の両方を伝えないと予想されます。
Schulzrinne & Taylor Standards Track [Page 25] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[25ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
V21L300:
V21L300:
indicates that the sender has detected V.21 modulation operating
in the lower channel at 300 bits/s. Note that it may take some
time to distinguish between 300 bits/s and 110 bits/s operation.
It is expected that implementations will not transmit both this
event and individual V.21 bit events for the same content.
送付者が、V.21変調が300ビット/sの低いチャンネルで作動するのを検出したのを示します。 300ビット/sを見分けるいつかの時間と110ビット/sの操作がかかるかもしれないことに注意してください。 実現が同じ内容のためにこの出来事と個々のV.21ビット出来事の両方を伝えないと予想されます。
V21H300:
V21H300:
indicates that the sender has detected V.21 modulation operating
in the upper channel at 300 bits/s. It is expected that
implementations will not transmit both this event and individual
V.21 bit events for the same content.
送付者が、V.21変調が300ビット/sの上側のチャンネルで作動するのを検出したのを示します。 実現が同じ内容のためにこの出来事と個々のV.21ビット出来事の両方を伝えないと予想されます。
B103L300:
B103L300:
indicates that the sending device has detected Bell 103 class
modulation operating in the low channel at 300 bits/s.
送付装置が、ベルの103クラス変調が300ビット/sの低いチャンネルで作動するのを検出したのを示します。
V23Main:
V23Main:
indicates that the sending device has detected V.23 modulation
operating in the high-speed channel. As described below, this
indicator may alternate with the XCIMark indication.
送付装置が、V.23変調が高速チャンネルで作動するのを検出したのを示します。 以下で説明されるように、このインディケータはXCIMark指示と交替するかもしれません。
V23Back:
V23Back:
indicates that the sending device has detected V.23 modulation
operating in the 75 bit/s back-channel.
送付装置が、V.23変調が戻っている75ビット/sのチャンネルで作動するのを検出したのを示します。
Baud4545:
Baud4545:
indicates that the sending device has detected Baudot modulation
operating at 45.45 bits/s.
送付装置が、Baudot変調が45.45ビット/sで作動するのを検出したのを示します。
Baud50:
Baud50:
indicates that the sending device has detected Baudot modulation
operating at 50 bits/s.
送付装置が、Baudot変調が50ビット/sで作動するのを検出したのを示します。
XCIMark:
XCIMark:
Indicates that the sending device has detected the specific bit
pattern (0) 1111 1111(1)(0)1111 1111(1) sent at 1200 bits/s using
V.23 upper-channel modulation, following a period of V.23 main
channel "mark" (1300 Hz).
V.23の主なチャンネル「マーク」(1300Hz)の期間に続いて、送付装置がV.23上側のチャンネル変調を使用することで1200ビット/sで送られた特定のビット・パターン(0)1111 1111(1)(0)1111 1111(1)を検出したのを示します。
Schulzrinne & Taylor Standards Track [Page 26] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[26ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
It is assumed in all cases that the event reports described here are being transmitted in addition to another media encoding, typically G.711 [19] voice-band data, reporting the same information. A natural method to do this is to combine the voice-band data with event reports in an RFC 2198 [2] redundancy payload.
すべての場合で通常、ここで説明されたイベントレポートが別のメディアコード化に加えて伝えられるG.711[19]音声帯域データであると思われます、同じ情報を報告して。 これをする自然な方法はRFC2198[2]冗長ペイロードでのイベントレポートに音声帯域データを結合することです。
The handling of ANS2225 has been indicated above. Since it is a specific tone, it can be handled like any other tone event.
ANS2225の取り扱いは上で示されました。 それが特定のトーンであるので、いかなる他のトーン出来事のようにもそれを扱うことができます。
For all of the other indicators, the sender SHOULD generate an initial event report as soon as the nature of the audio content has been recognized. For reliability, the initial event report SHOULD be retransmitted twice at short intervals. (20 ms is a suggested value, although the packetization period of the associated media may be sufficient.) The sender MAY continue to send additional reports of the same indicator event, although these have little value once the receiver has adjusted itself to the type of content it is receiving.
他のインディケータのすべてに関しては、オーディオ内容の本質が認識されるとすぐに、送付者SHOULDは初期のイベントレポートを作ります。 信頼性、初期の出来事が、SHOULDが二度しばしば再送されると報告するので。 (関連メディアのpacketizationの期間は十分であるかもしれませんが、20msは提案された値です。) 送付者は、同じインディケータイベントの追加レポートを送り続けるかもしれません、これらには、受信機がいったんそれが受け取っている内容のタイプに順応すると、値がほとんどありませんが。
If the nature of the content changes (e.g., because it is coming from a V.18 terminal in the probing stage), the sender MUST send an event report for the new content type as soon as it is recognized. If the sender has been sending updates for the previous indicator, it SHOULD report the end of that previous indicator event along with the beginning of the new one.
内容の本質が変化するなら(例えば、調べ段階のV.18端末から来る予定であるので)、それが認識されるとすぐに、送付者は新しい満足しているタイプへのイベントレポートを送らなければなりません。 送付者は前のインディケータのためのアップデートを送って、それは新しい方の始まりに伴うその前のインディケータイベントの終わりのSHOULDレポートです。
2.7.1.1. Handling of Congestion
2.7.1.1. 混雑の取り扱い
In the face of packet loss or delay, it is appropriate for the receiver to continue to play out the ANS2225 event until further packets are received. For the other events, the issue is loss of the initial event report rather than maintenance of playout continuity. The advice on retransmission of these other events already given above is sufficient to deal with packet loss or delay due to congestion.
パケット損失か遅れに直面して、受信機が、一層のパケットが受け取られているまでANS2225出来事を展開し続けているのは、適切です。 他の出来事に関しては、問題は再生の連続の維持よりむしろ初期のイベントレポートの損失です。 既に上に与えられたこれらの他の出来事の「再-トランスミッション」に関するアドバイスは、混雑のためパケット損失か遅れに対処するために十分です。
2.7.2. Use of Events with V.18 Modems
2.7.2. V.18モデムがある出来事の使用
ITU-T Recommendation V.18 [11] defines a terminal for text conversation, possibly in combination with voice. V.18 is intended to interoperate with a variety of legacy text terminals, so its start-up sequence can consist of a series of stimuli designed to determine what is at the other end. Two V.18 terminals talking to each other will use V.8 to negotiate startup and continue at the physical level with V.21 at 300 bits/s carrying 7-bit characters bounded by start and stop bits.
ITU-T Recommendation V.18[11]はことによると声と組み合わせてテキストの会話のために端末を定義します。 V.18がさまざまな遺産テキスト端末で共同利用することを意図するので、起動順序はもう一方の端のときに、何があるかを決定するように設計された一連の刺激から成ることができます。 互いに話す2台のV.18端末が、V.21と共に300ビット/sで物理的なレベルで始動を交渉して、続くのに始めによって境界がある7ビットのキャラクタとストップビットを運びながら、V.8を使用するでしょう。
Schulzrinne & Taylor Standards Track [Page 27] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[27ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
The V.18 terminal is also designed to interoperate with the text modems listed in the previous sub-section. The startup sequences for all these different terminal types are naturally quite different. The V.18 initial startup sequence specifically addresses itself to V.8-capable terminals and V.21 terminals and, by the combination of signals, to V.23 videotex terminals. During the initial startup sequence, the V.18 terminal listens for frequency responses characterizing the other terminal types. If it does not make contact in the preliminary step, it probes for each type specifically. By the nature of the application, V.18 has been designed to provide an extremely robust startup capability.
また、V.18端末は、テキストモデムが前の小区分で記載されている状態で共同利用するように設計されています。 これらのすべての異なった端末のタイプのための始動系列は自然に全く異なっています。 V.18の初期の始動系列は明確にV.8できる端末とV.21端末と、そして、信号の組み合わせによるV.23ビデオテックス端末にそれ自体を記述します。 初期の始動系列の間、V.18端末は他の端末のタイプについて描写する周波数特性の聞こうとします。 予備のステップにおける接触を作らないなら、それは各タイプのために明確に調べられます。 アプリケーションの本質で、V.18は、非常に強健な始動能力を提供するように設計されます。
The handling of the V.18 XCI signal is a specific case of the procedures described in the previous section. XCI is a signal transmitted in high-band V.23 modulation to stimulate V.23 terminals to respond and to allow detection of V.18 capabilities in a DCE. The 3-second XCI signal uses the V.23 upper channel having periods of "mark" (i.e., 1300 Hz) alternating with the XCIMark pattern. The full definition is found in V.18, Section 3.13. The sender SHOULD indicate V23Main during the transmission of the "mark" portion of XCI, and change the indication to XCIMark when that pattern is detected.
V.18 XCI信号の取り扱いは前項で説明された手順の特定のケースです。 XCIは応じて、DCEでのV.18能力の検出を許すためにV.23端末を刺激するためにハイ・バンドV.23変調で送信された信号です。 3秒のXCI信号はXCIMarkパターンがある「マーク」(すなわち、1300Hz)交替の期間を持っているV.23の上側のチャンネルを使用します。 完全な定義はV.18、セクション3.13で見つけられます。 送付者SHOULDはXCIの「マーク」一部の送信の間、V23Mainを示して、そのパターンが検出されるとき、指示をXCIMarkに変えます。
2.8. A Generic Indicator
2.8. 一般的なインディケータ
Numerous proprietary modem protocols exist, as well as standardized protocols not identified above. Table 8 defines a single indicator event that may be used to identify modem content when a more specific event is unavailable. Typically, this would be sent in combination with another payload type, for example, voice-band data as specified by ITU-T Recommendation V.152 [33].
多数の独占モデムプロトコルは、存在して、上で特定されなかったプロトコルを標準化しました。 テーブル8は、より特定の出来事が入手できないときに、モデム内容を特定するのに使用されるかもしれない単一のインディケータイベントを定義します。 通常、別のペイロードタイプ、例えば、ITU-T Recommendation V.152[33]による指定されるとしての音声帯域データと組み合わせてこれを送るでしょう。
As with the indicators in the previous section, the sender SHOULD generate an initial event report as soon as the nature of the audio content has been recognized. For reliability, the initial event report SHOULD be retransmitted twice at short intervals. (20 ms is a suggested value, although the packetization period of the associated media may be sufficient.) The sender MAY continue to send additional reports of the VBDGen event, although these have little value once the receiver has adjusted itself to the type of content it is receiving.
前項のインディケータのように、オーディオ内容の本質が認識されるとすぐに、送付者SHOULDは初期のイベントレポートを作ります。 信頼性、初期の出来事が、SHOULDが二度しばしば再送されると報告するので。 (関連メディアのpacketizationの期間は十分であるかもしれませんが、20msは提案された値です。) 送付者は、VBDGen出来事の追加レポートを送り続けるかもしれません、これらには、受信機がいったんそれが受け取っている内容のタイプに順応すると、値がほとんどありませんが。
Schulzrinne & Taylor Standards Track [Page 28] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[28ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
+--------+---------------+------------+-----------+-------+---------+ | Event | Bit Rate | Frequency | Event | Type | Volume? | | | bits/s | (Hz) | Code | | | +--------+---------------+------------+-----------+-------+---------+ | VBDGen | Variable | Variable | 61 | other | no | +--------+---------------+------------+-----------+-------+---------+
+--------+---------------+------------+-----------+-------+---------+ | 出来事| ビット伝送速度| 頻度| 出来事| タイプ| ボリューム? | | | ビット/s| (Hz) | コード| | | +--------+---------------+------------+-----------+-------+---------+ | VBDGen| 変数| 変数| 61 | 他| いいえ| +--------+---------------+------------+-----------+-------+---------+
Table 8: Generic Modem Signal Indicator
テーブル8: 一般的なモデム信号インディケータ
VBDGen:
VBDGen:
indicates that the sender has detected tone patterns indicating
the operation of some form of modem. This indicator SHOULD NOT be
sent if a more specific event is available.
送付者が、トーンパターンが何らかの形式のモデムの操作を必要とするのを検出したのを示します。 このインディケータSHOULD NOT、 より特定の出来事が利用可能であるなら、送ってください。
3. Strategies for Handling Fax and Modem Signals
3. 取り扱いファックスとモデム信号のための戦略
As described in Section 1.2, the typical data application involves a pair of gateways interposed between two terminals, where the terminals are in the PSTN. The gateways are likely to be serving a mixture of voice and data traffic, and need to adopt payload types appropriate to the media flows as they occur. If voice compression is in use for voice calls, this means that the gateways need the flexibility to switch to other payload types when data streams are recognized.
セクション1.2で説明されるように、典型的なデータアプリケーションは端末がPSTNにある2台の端末の間で挿入された1組のゲートウェイにかかわります。 ゲートウェイは、声とデータ通信量の混合物に役立っていそうであって、起こるとき、メディア流れに適切なペイロードタイプを採用する必要があります。 音声通話に、声の圧縮が使用中であるなら、これは、データ・ストリームが認識されるとき、ゲートウェイが、柔軟性が他のペイロードタイプに切り替わる必要を意味します。
Within the established IETF framework, this implies that the gateways must negotiate the potential payloads (voice, telephone-event, tones, voice-band data, T.38 fax [21], and possibly RFC 4103 [18] text and Clearmode [17] octet streams) as separate payload types. From a timing point of view, this is most easily done at the beginning of a call, but results in an over-allocation of resources at the gateways and in the intervening network.
確立したIETF枠組みの中では、これは、別々のペイロードにタイプされるようにゲートウェイが潜在的ペイロード(声、電話出来事、トーン、音声帯域データ、T.38ファックス[21]、ことによると4103年のRFC[18]テキスト、およびClearmode[17]八重奏の流れ)を交渉しなければならないのを含意します。 タイミング観点から、これは、呼び出しの始めに最も容易にしますが、ゲートウェイにおいて介入しているネットワークでリソースの過剰配分をもたらします。
One alternative is to use named events to buy time while out-of-band signals are exchanged to update to the new payload type applicable to the session. Thanks to the events defined in this document, this is a viable approach for sessions beginning with V.8, V.8 bis, T.30, or V.25 control sequences.
バンドの外でセッションに適切な新しいペイロードタイプへのアップデートと信号を交換している間、時間を稼ぐように出来事という使用には1つの選択肢があります。 本書では定義された出来事のおかげで、これはV.8、V.8と共に2回始まるセッションのための実行可能なアプローチです、T.30、または、V.25が系列を制御します。
Named data-related events also allow gateways to optimize their operation when data signals are received in a relatively general form. One example is the use of V.8-related events to deduce that the voice-band data being sent in a G.711 payload comes from a higher-speed modem and therefore requires disabling of echo cancellers.
また、命名されたデータ関連の出来事で、比較的一般的なフォームでデータ信号を受信するとき、ゲートウェイは彼らの操作を最適化できます。 1つの例はG.711ペイロードで送られる音声帯域データが、より高い速度モデムから来て、したがって、エコーキャンセラーが無能にされるのを必要とすると推論するV.8関連の出来事の使用です。
Schulzrinne & Taylor Standards Track [Page 29] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[29ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
All of the control procedures described in the sub-sections of Section 2 eventually give way to data content. As mentioned above, this content will be carried by other payload types. Receiving gateways MUST be prepared to switch to the other payload type within the time constraints associated with the respective applications. (For several of the procedures documented above, the sender provides 75 ms of silence between the initial control signalling and the sending of data content.) In some cases (V.8 bis [10], T.30 [8]), further control signalling may happen after the call has been established.
結局セクション2の小区分で説明されたコントロール手順のすべてがデータ内容に屈します。 以上のように、この内容は他のペイロードタイプによって運ばれるでしょう。 それぞれのアプリケーションに関連している時間規制の中でもう片方のペイロードタイプに切り替わるようにゲートウェイを受けるのを準備しなければなりません。 (上に記録されたいくつかの手順のために、送付者は初期のコントロール合図とデータ内容の送付の間の沈黙の75msを提供します。) いくつかの場合、(V.8、[10] T.30[8])、呼び出しが確立された後に2回、一層のコントロール合図は起こるかもしれません。
A possible strategy is to send both the telephone-event and the data payload in an RFC 2198 [2] redundancy arrangement. The receiving gateway then propagates the data payload whenever no event is in progress. For this to work, the data payload and events (when present) MUST cover exactly the same content over the same time period; otherwise, spurious events will be detected downstream. An example of this mode of operation is shown below.
可能な戦略はRFC2198[2]冗長アレンジメントで電話出来事とデータペイロードの両方を送ることです。 出来事が全く進行していないときはいつも、そして受信ゲートウェイはデータペイロードを伝播します。 これが働くように、データペイロードと出来事(存在しているとき)は同じ期間、まさに同じ内容をカバーしなければなりません。 さもなければ、偽りのイベントは川下に検出されるでしょう。 この運転モードに関する例は以下に示されます。
Note that there are a number of cases where no control sequence will precede the data content. This is true, for example, for a number of legacy text terminal types. In such instances, the events defined in Section 2.7 in particular MAY be sent to help the remote gateway optimize its handling of the alternative payload.
件数がどんな制御配列もデータ内容に先行しないところにあることに注意してください。 多くの遺産テキスト端末タイプに、例えば、これは本当です。 そういった場合には、リモートゲートウェイが代替のペイロードの取り扱いを最適化するのを助けるために特にセクション2.7で定義された出来事を送るかもしれません。
4. Example of V.8 Negotiation
4. V.8交渉に関する例
This section presents an example of the use of the event codes defined in Section 2. The basic scenario is the startup sequence for duplex V.34 modem operation. It is assumed that once the initial V.8 sequence is complete, the gateways will enter into voice-band data operation using G.711 encoding to transmit the modem signals. The basic packet sequence is indicated in Table 9. Sample packets are then shown in detail for two variants on event transmission strategy:
このセクションはセクション2で定義されたイベントコードの使用に関する例を提示します。 基本的なシナリオは重複のV.34モデム操作のための始動系列です。 初期のV.8系列がいったん完全になるとゲートウェイがモデム信号を送信するのにG.711コード化を使用する音声帯域データ操作に入ると思われます。 基本的なパケット系列はTable9で示されます。 次に、見本小包は2つの異形のためにイベントトランスミッション戦略で詳細に見せられます:
o simultaneous transmission of events and retransmitted events using
RFC 2198 [2] redundancy;
o RFC2198[2]冗長を使用する出来事と再送された出来事の両方向同時伝送。
o simultaneous transmission of events, retransmitted events, and
voice-band data covering the same content using RFC 2198
redundancy.
o 出来事、再送された出来事、および2198年のRFC冗長を使用することで同じ内容に関する音声帯域データの両方向同時伝送。
For simplicity and semi-realism, the times shown for the example scenario assume a fixed lag at each gateway of 20 ms between the packet side of the gateway and the local user equipment and vice versa (i.e., minimum of 40 ms between packet received and packet sent specifically in response to the received packet). A propagation delay of 5 ms is assumed between gateways. It is assumed that the
簡単さと準リアリズムのために、例のシナリオのために示された回はゲートウェイのパケット側面とローカルのユーザ設備の間で20msの各ゲートウェイで逆もまた同様(すなわち、特に容認されたパケットに対応して送られた受け取られたパケットとパケットの間の40msの最小限)に固定立ち遅れを仮定します。 5msの伝播遅延はゲートウェイの間で想定されます。 それが想定される、それ
Schulzrinne & Taylor Standards Track [Page 30] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[30ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
event packetization interval is 30 ms, a reasonable compromise between packet volume and buffering delay, particularly for V.21 events.
イベントpacketization間隔は30ms、パケットボリュームと遅れをバッファリングして、特にV.21出来事のための合理的な妥協です。
At the basic V.8 protocol level, the table assumes that the answering modem waits 0.2 s (200 ms) from the beginning of the call to start transmitting ANSam. The calling modem waits 1 s (1000 ms) from the time it begins to receive ANSam until it begins to send the V.8 CM signal. Both modems wait 75 ms from the time they finish sending and receiving CJ, respectively, until they begin sending V.34 modem signals.
基本的なV.8プロトコルレベルでは、テーブルは、回答モデムが呼び出しの始まりからの始めへの0.2秒間(200ms)ANSamを伝えながら待つと仮定します。 呼ぶモデムは1秒間、それがV.8 CM信号を送り始めるまでANSamを受け取り始める時から待っています(1000ms)。 彼らがCJを送って、受け終える時からの両方のモデム待ち75ms、それぞれ、彼らが発信し始めるまで、V.34モデムは合図します。
+------------+------------------------------------------------------+ | Time (ms) | Event | +------------+------------------------------------------------------+ | 220.0 | The called gateway detects the start of ANSam from | | | its end. | | | | | 250.0 | The called gateway sends out the first ANSam event | | | packet. M bit is set, timestamp is ts0 + 1760 | | | (where ts0 is the timestamp value at the start of | | | the call). The initial ANSam event continues until | | | a phase shift is detected at 670.0 ms (see below). | | | Up to this time, the called gateway sends out | | | further ANSam event updates, with the same initial | | | timestamp, M bit off, and cumulative duration | | | increasing by 240 units each time. | | | | | 255.0 | The calling gateway receives the first ANSam event | | | report and begins playout of ANSam tone at its end. | | | | | 275.0 | The calling terminal receives the beginning of ANSam | | | tone and starts its timer. It will begin sending | | | the CM signal 1 s later (at 1275.0 ms into the | | | call). | | | | | 670.0 | The called gateway detects a phase shift in the | | | incoming signal, marking a change from ANSam to | | | /ANSam. This happens to coincide with the end of a | | | packetization interval. For the sake of the | | | example, assume that the called gateway does not | | | detect this in time for the event report it sends | | | out. | | | |
+------------+------------------------------------------------------+ | 時間(ms)| 出来事| +------------+------------------------------------------------------+ | 220.0 | 呼ぶゲートウェイがANSamの始まりを検出する| | | その終わり。 | | | | | 250.0 | 呼ばれたゲートウェイは最初のANSam出来事を出します。| | | パケット。 Mビットは設定されて、タイムスタンプはts0+1760です。| | | (ts0が|始まり| | 呼び出しでタイムスタンプ値であるところ。) 初期のANSam出来事は続きます。| | | フェーズシフトは670.0msに検出されます(以下を見てください)。 | | | これまで、呼ばれたゲートウェイは出されます。| | | 同じくらいが初期であることのさらなるANSamイベントアップデート| | | タイムスタンプ、食いちぎられたM、および累積している持続時間| | | 240ユニットで、その都度、増加します。 | | | | | 255.0 | 呼ぶゲートウェイは最初のANSam出来事を受けます。| | | 終わりにANSamトーンの再生を報告して、始めます。 | | | | | 275.0 | 呼ぶ端末はANSamの始まりを受けます。| | | 調子を変えてください。そうすれば、始めはタイマに調子を変えさせます。 それは発信し始めるでしょう。| | | 何1秒間も後のCM信号、(1275.0がmsする、| | | 呼び出し、) | | | | | 670.0 | 呼ばれたゲートウェイはフェーズシフトを検出します。| | | 入って来る信号、aがANSamから変化するマーク| | | /ANSam。 これはたまたまaの終わりと同時に起こります。| | | packetization間隔。 for the sake of| | | 例、呼ばれたゲートウェイがそうしないと仮定してください。| | | それが送るイベントレポートに間に合うようにこれを検出してください。| | | 出かける。 | | | |
Schulzrinne & Taylor Standards Track [Page 31] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[31ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
| 700.0 | The called gateway issues its next-scheduled event | | | report packet, indicating an initial report for | | | /ANSam (M bit set, timestamp ts0 + 5360, duration | | | 240 timestamp units). The packet also carries the | | | first retransmission of the final ANSam report, | | | total duration 3600 units, this time with the E bit | | | set. | | | | | 1295.0 | The calling gateway begins to receive the CM signal | | | from the calling modem. | | | | | 1325.0 | The calling gateway sends a packet containing the | | | first 9 bits of the CM signal. | | | | | 1445.0 | The calling gateway sends out a packet containing | | | the last 4 bits of the first CM signal, plus the | | | first 5 bits of the next repetition of that signal. | | | CM bits will continue to be transmitted from the | | | calling gateway until 2015.0 ms (see below), for a | | | total of 24 packets. (The final packet also carries | | | the beginning of the CJ signal.) | | | | | 1596.7 | The called gateway completes playout of the final | | | bit of the second occurrence of the CM signal. | | | | | 1636.7 | The called gateway detects end of /ANSam (and | | | beginning of JM) from the called modem. The next | | | packet is not yet due to go out. | | | | | 1660.0 | The called gateway sends out a packet combining the | | | final /ANSam event report (E bit set and total | | | duration 533 timestamp units) with the first 7 bits | | | of the JM signal. The M bit for the packet is set | | | and the packet timestamp is ts0 + 12560 (the start | | | of the now-discontinued /ANSam event). | | | | | 1690.0 | The called gateway sends out a packet containing the | | | next nine bits of JM signal. The M bit is set and | | | the timestamp is ts0 + 13280 (beginning of the first | | | bit in the packet). JM will continue to be | | | transmitted until 2170.0 ms (see below), for a total | | | of 18 packets (plus two for final retransmissions). | | | | | 1938.3 | The calling gateway completes playout of the final | | | packet of the second occurrence of the JM signal. | | | | | 1995.0 | The calling gateway begins to receive the initial | | | bits of the CJ signal. |
| 700.0 | 呼ばれたゲートウェイは次に予定されている出来事を発行します。| | | イニシャルが届け出るのを示して、パケットを報告してください。| | | /ANSam(持続時間| | | セット、タイムスタンプts0+5360、240タイムスタンプユニット噛み付かれたM)。 また、パケットは運ばれます。| | | 最初に、最終的なANSamレポートの「再-トランスミッション」| | | 3600ユニットと、今回、Eビットで持続時間を合計してください。| | | セットしてください。 | | | | | 1295.0 | 呼ぶゲートウェイはCM信号を受け取り始めます。| | | 呼ぶモデムから。 | | | | | 1325.0 | 呼ぶゲートウェイで、パケットは含みます。| | | まず最初に、CMの9ビットは合図します。 | | | | | 1445.0 | 呼ぶゲートウェイはパケット含有を出します。| | | 最初のCMのベスト4ビットはそのうえ、合図します。| | | まず最初に、次のその反復の5ビットは合図します。 | | | 伝えられますCMビットが、続ける。| | | aのために2015.0までのゲートウェイをms(以下を見る)と呼びます。| | | 24のパケットの合計。 (また、最終的なパケットは|運びます||CJ信号の始まり) | | | | | 1596.7 | 呼ばれたゲートウェイは決勝の再生を完成します。| | | CM信号の2番目の発生のビット。 | | | | | 1636.7 | 呼ばれたゲートウェイは呼ばれたモデムから/ANSam(|||そして、JMの始まり)の端を検出します。 次| | | パケットはまだ出かけていることになっていません。 | | | | | 1660.0 | 呼ばれたゲートウェイはパケット結合を出します。| | | 最初の7ビットがある決勝/ANSamイベントレポート(Eはセットと合計| | | 持続時間に533タイムスタンプユニット噛み付きました)| | | JMでは、合図してください。 パケットのために噛み付かれたMは設定されます。| | | そして、パケットタイムスタンプがts0+12560である、(始め|、|、|、現在中止された/ANSam出来事) | | | | | 1690.0 | 呼ばれたゲートウェイはパケット含有を出します。| | | JMの次の9ビットは合図します。 そしてMビットが設定される。| | | タイムスタンプはts0+13280(1つの番目ものの始まり| | | パケットのビット)です。 JMは、続けるでしょう。| | | 合計のために2170.0ms(以下を見る)まで伝えられます。| | | 18のパケット(最終的な「再-トランスミッション」のためのプラスtwo)について。 | | | | | 1938.3 | 呼ぶゲートウェイは決勝の再生を完成します。| | | JM信号の2番目の発生のパケット。 | | | | | 1995.0 | 呼ぶゲートウェイは初期を受け始めます。| | | CJのビットは合図します。 |
Schulzrinne & Taylor Standards Track [Page 32] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[32ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
| | | | 2015.0 | The calling gateway sends a packet containing the | | | final 3 bits of the first decad of a CM signal and | | | first 6 bits of a CJ signal. | | | | | 2095.0 | The calling gateway receives the last bit of the CJ | | | signal. A period of silence lasting 75-ms begins at | | | the called end. It is not yet time to send out an | | | event report. | | | | | 2105.0 | The calling gateway sends out a packet containing | | | the final 6 bits of the CJ signal. | | | | | 2130.0 | The called gateway finishes playing out the last CJ | | | signal bit sent to it. | | | | | 2135.0 | The calling gateway sends a packet containing no new | | | events, but retransmissions of the last 15 bits of | | | the CJ signal (in two generations). | | | | | 2165.0 | The calling gateway sends out a packet containing no | | | new events, but retransmissions of the final 6 bits | | | of the CJ signal. | | | | | 2170.0 | The called gateway sends out the last packet | | | containing bits of the JM signal (except for | | | retransmissions). Note that according to the V.8 | | | specification these bits do not in general complete | | | a JM signal or even an "octet" of that signal | | | (although they happen to do so in this example). A | | | 75 ms period of silence begins at the called end. | | | | | 2170.0 | The calling gateway begins to receive V.34 | | | signalling from the called modem. | | | | | 2175.0 | The calling gateway finishes playing out the last JM | | | signal bit sent to it. | | | | | 2195.0 | The calling gateway sends out a first packet of V.34 | | | signalling as voice-band data (PCMU). Timestamp is | | | ts0 + 17360 and M bit is set to indicate the | | | beginning of content after silence. The packet | | | contains 200 8-bit samples. Packetization interval | | | is shown here as continuing to be 30 ms. It could | | | be less, but MUST NOT be more because that would | | | make the silent period too long. | | | |
| | | | 2015.0 | 呼ぶゲートウェイで、パケットは含みます。| | | そしてCMの最初のdecadの最終的な3ビットが合図する。| | | まず最初に、CJの6ビットは合図します。 | | | | | 2095.0 | 呼ぶゲートウェイはCJの最後のビットを受けます。| | | 合図してください。 75-msが始まる沈黙持続の期間| | | 呼ばれた終わり。 しかし、もう出すべき時間ではありません。| | | イベントレポート。 | | | | | 2105.0 | 呼ぶゲートウェイはパケット含有を出します。| | | CJの最終的な6ビットは合図します。 | | | | | 2130.0 | 呼ばれたゲートウェイは、最後のCJを終え終えます。| | | 信号ビットはそれに発信しました。 | | | | | 2135.0 | 呼ぶゲートウェイは新しい状態でいいえを含むパケットを送ります。| | | しかし、出来事、最後の15ビットの「再-トランスミッション」| | | CJは合図します(2世代で)。 | | | | | 2165.0 | 呼ぶゲートウェイはいいえを含むパケットを出します。| | | しかし、新しい出来事、最終的な6ビットの「再-トランスミッション」| | | CJでは、合図してください。 | | | | | 2170.0 | 呼ばれたゲートウェイは最後のパケットを出します。| | | JM信号(| | | 「再-トランスミッション」を除いた)のビットを含んでいます。 V.8に従って、それに注意してください。| | | 一般に、これらのビットが完成しない仕様| | | その信号のJM信号か「八重奏」さえ| | | (彼らはこの例でたまたまそうしますが。) A| | | 沈黙の75msの期間は呼ばれた終わりに始まります。 | | | | | 2170.0 | 呼ぶゲートウェイはV.34を受け取り始めます。| | | 呼ばれたモデムから、合図します。 | | | | | 2175.0 | 呼ぶゲートウェイは、最後のJMを終え終えます。| | | 信号ビットはそれに発信しました。 | | | | | 2195.0 | 呼ぶゲートウェイはV.34の最初のパケットを出します。| | | 音声帯域データ(PCMU)として、合図します。 タイムスタンプはそうです。| | | ts0+17360とMビットが示すように設定されます。| | | 沈黙の後の内容の始まり。 パケット| | | 200個の8ビットのサンプルを含んでいます。 Packetization間隔| | | ずっと30であるとしてここに原稿Itがそうすることができたのが示されます。| | | それは少ないでしょう、したがって、より多くであるはずがないのを除いて、より少なくいてください。| | | 沈黙期を長くし過ぎてください。 | | | |
Schulzrinne & Taylor Standards Track [Page 33] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[33ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
| 2200.0 | The called gateway sends a packet containing no new | | | events, but retransmissions of the last 18 bits of | | | the JM signal (in two generations). | | | | | 2225.0 | The calling gateway sends out the second packet of | | | V.34 signalling as voice-band data (PCMU). | | | Timestamp is ts0 + 17560 and M bit is not set. The | | | packet contains 240 8-bit samples. | | | | | 2230.0 | The called gateway sends out a packet containing no | | | new events, but retransmissions of the final 9 bits | | | of the JM signal. | | | | | 2245.0 | The called gateway begins to receive V.34 signalling | | | from the called modem. | | | | | 2255.0 | The calling gateway sends out a third packet of V.34 | | | signalling as voice-band data (PCMU). Timestamp is | | | ts0 + 17800 and M bit is not set. The packet | | | contains 240 8-bit samples. | | | | | 2260.0 | The called gateway sends out a first packet of V.34 | | | signalling as voice-band data (PCMU). Timestamp is | | | ts0 + 17960 and M bit is set to indicate the | | | beginning of content after silence. The packet | | | contains 120 samples. Packetization interval is | | | shown here as continuing to be 30 ms. It could be | | | less, but MUST NOT be more because that would make | | | the silent period too long. | | | | | . . . | . . . | +------------+------------------------------------------------------+
| 2200.0 | 呼ばれたゲートウェイは新しい状態でいいえを含むパケットを送ります。| | | しかし、出来事、最後の18ビットの「再-トランスミッション」| | | JMは合図します(2世代で)。 | | | | | 2225.0 | ゲートウェイが2番目のパケットから発信する呼ぶこと| | | 音声帯域データ(PCMU)として合図するV.34。 | | | タイムスタンプは噛み付かれたts0+17560とMが用意ができていないということです。 The| | | パケットは240個の8ビットのサンプルを含んでいます。 | | | | | 2230.0 | 呼ばれたゲートウェイはいいえを含むパケットを出します。| | | しかし、新しい出来事、最終的な9ビットの「再-トランスミッション」| | | JMでは、合図してください。 | | | | | 2245.0 | 呼ばれたゲートウェイはV.34合図を受け始めます。| | | 呼ばれたモデムから。 | | | | | 2255.0 | 呼ぶゲートウェイはV.34の3番目のパケットを出します。| | | 音声帯域データ(PCMU)として、合図します。 タイムスタンプはそうです。| | | 噛み付かれたts0+17800とMは用意ができていません。 パケット| | | 240個の8ビットのサンプルを含んでいます。 | | | | | 2260.0 | 呼ばれたゲートウェイはV.34の最初のパケットを出します。| | | 音声帯域データ(PCMU)として、合図します。 タイムスタンプはそうです。| | | ts0+17960とMビットが示すように設定されます。| | | 沈黙の後の内容の始まり。 パケット| | | 120個のサンプルを含んでいます。 Packetization間隔はそうです。| | | ずっと30であるとしてここに原稿Itがそうであるかもしれないことが示されます。| | | それは利かせるでしょう、したがって、より多くであるはずがないことの以下| | | 沈黙期も切望します。 | | | | | . . . | . . . | +------------+------------------------------------------------------+
Table 9: Events for Example V.8 Scenario
テーブル9: 出来事、例えば、V.8シナリオ
Schulzrinne & Taylor Standards Track [Page 34] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[34ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
4.1. Simultaneous Transmission of Events and Retransmitted Events Using
RFC 2198 Redundancy
4.1. RFC2198冗長を使用する出来事と再送された出来事の両方向同時伝送
Negotiation of the transmission mode being described in this section would use SDP similar to the following:
このセクションで説明される転送方式の交渉は以下と同様のSDPを使用するでしょう:
m=audio 12343 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12345 RTP/AVP 100 101
a=rtpmap:100 red/8000/1
a=fmtp:100 101/101/101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68
m=オーディオの12343RTP/AVP99a=rtpmap: 99pcmu/8000m=オーディオの12345RTP/AVP100 101a=rtpmap: 100赤/8000/1a=fmtp: 100 101/101/101a=rtpmap: 101電話出来事/8000a=fmtp: 101 0-15、32-41、43、46、48-49、52-68
This indicates two media streams, the first for G.711 (i.e., voice or voice-band data), the second for triply-redundant telephone events. As RFC 2198 notes, it is also possible for the sender to send telephone-event payloads without redundancy in the second stream, although the redundant form is the primary transmission mode. (It would be reasonable to send the interim ANSam reports without redundancy.) The set of telephone events supported includes the DTMF events (not relevant in this example), and all of the data events defined in this document. In fact, only event codes 34-35 and 37-40 are used in the example.
これは2つのメディアの流れ、G.711(すなわち、声か音声帯域データ)のための1番目、三重に余分な電話出来事のための2番目を示します。 また、RFC2198注意として、送付者が冗長なしで2番目の流れで電話イベントペイロードを送るのも、可能です、余分なフォームは第一の転送方式ですが。 (冗長なしで中間ANSamレポートを送るのは妥当でしょう。) 出来事が支えた電話のセットはDTMF出来事(この例で関連していない)、および本書では定義されたデータイベントのすべてを含んでいます。 イベントコードだけが例で34-35に37-40に使用されます。
For the purpose of illustrating the use of RFC 2198 redundancy as well as showing the basic composition of the event reports, the second packet reporting JM signal bits (sent by the called gateway at 1690.0 ms) seems to be a good choice. This packet will also carry the second retransmission of the final /ANSam event report and the first retransmission of the initial 7 bits of the JM signal. The detailed content of the packet is shown in Figure 1. To see the contents of the successive generations more clearly, they are presented as if they were aligned on successive 32-bit boundaries. In fact, they are all offset by one octet, following on consecutively from the RFC 2198 header.
RFC2198冗長の使用を例証して、イベントレポートの基本的な構成を示している目的のために、JM信号ビット(1690.0msで呼ばれたゲートウェイのそばで発信する)を報告する2番目のパケットは良い選択であるように思えます。 また、このパケットは決勝/ANSamイベントレポートの2番目の「再-トランスミッション」とJM信号の初期の7ビットの最初の「再-トランスミッション」を運ぶでしょう。 パケットの詳細な内容は図1に示されます。 より明確に連続した世代のコンテンツを見るために、それらはまるで連続した32ビットの境界で並べられるかのように提示されます。 事実上、それらはすべて、連続してRFC2198ヘッダーからのある八重奏、以下のそばの進行中のオフセットです。
The M bit is set in the RTP header for the packet, as required for the coding of multiple events in the primary block of data. In fact, RFC 2198 implies that this is the correct behavior, but does not say so explicitly. The E bit is set for every event. It is possible that it would not be set for the final event in the primary block.
Mビットはデータの第一のブロックの複数の出来事のコード化のために必要に応じてRTPヘッダーにパケットに設定されます。 事実上、RFC2198は、これが正しい振舞いですが、それほど明らかに言わないのを含意します。 Eビットはあらゆる出来事に設定されます。 それが第一のブロックの最終的な出来事に設定されないのは、可能です。
Schulzrinne & Taylor Standards Track [Page 35] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[35ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |1| PT=100 | sequence number = seq0 + 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp = ts0 + 13280 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 720 | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 267 | block length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| block PT=101| (begin block for /ANSam ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0|1| PT=100| 一連番号=seq0+48| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ=ts0+13280| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 太平洋標準時のブロック=101| タイムスタンプは=720を相殺しました。| ブロック長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 太平洋標準時のブロック=101| タイムスタンプは=267を相殺しました。| ブロック長=28| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 太平洋標準時のブロック=101| (/ANSamのためにブロックを始めてください…) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ANSam block (second retransmission)
/ANSamブロック(2番目の「再-トランスミッション」)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事=35|1|R| ボリューム| 持続時間=533| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel)
(first retransmission)
最初に、JM(V.21の高いチャンネルによる=「1111111」)の7ビット(最初に、「再-トランスミッション」)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事=40|1|R| ボリューム| 持続時間=27| 同様..出来事..持続時間..それぞれ| 出来事=40|1|R| ボリューム| 持続時間=27| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next 9 bits of JM (="111000000" in V.21 high channel)
(new content)
JM(V.21の高いチャンネルによる=「111000000」)の次の9ビット(新しい内容)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (7 similar events, codes 40,40,39,39,39,39,39 and /
/ durations 26,27,27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 39 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事=40|1|R| ボリューム| 持続時間=27| 同様..出来事..コード..持続時間..それぞれ| 出来事=39|1|R| ボリューム| 持続時間=27| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet Contents, Redundant Events Only
図1: パケットコンテンツ、余分な出来事専用
Schulzrinne & Taylor Standards Track [Page 36] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[36ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
Since all of the events in the above packet are consecutive and adjacent, it would have been permissible according to the telephone- event payload specification to carry them as a simple event payload without the RFC 2198 header. The advantage of the latter is that the receiving gateway can skip over the retransmitted events when processing the packet, unless it needs them.
上のパケットの出来事のすべてが連続していて隣接しているので、電話イベントペイロード仕様通りに、簡単なイベントペイロードとして2198年のRFCヘッダーなしでそれらを運ぶのは許されていたでしょう。 後者の利点はパケットを処理するとき、受信ゲートウェイが再送された出来事を飛ばすことができるということです、それらを必要としない場合。
4.2. Simultaneous Transmission of Events and Voice-Band Data Using RFC
2198 Redundancy
4.2. 出来事とRFC2198冗長を使用する音声帯域データの両方向同時伝送
Negotiation of the transmission mode being described in this section would use SDP similar to the following:
このセクションで説明される転送方式の交渉は以下と同様のSDPを使用するでしょう:
m=audio 12343 RTP/AVP 99 100 101
a=rtpmap:99 red/8000/1
a=fmtp:99 100/101/101/101
a=rtpmap:100 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68
mがオーディオの12343RTP/AVPと等しい、99、100 101a=rtpmap、: 99 赤/8000/1a=fmtp: 99 100/101/101/101a=rtpmap: 100 pcmu/8000a=rtpmap: 101 電話出来事/8000a=fmtp: 101 0-15 32-41 43 46 48-49、52-68
This indicates one media stream, with G.711 (i.e., voice or voice- band data) as the primary content, along with three blocks of telephone events. RFC 2198 requires that the more voluminous representation (i.e., the G.711) be the primary one. The most recent block of events covers the same time period as the voice-band data. The other two streams provide the first and second retransmissions of the events as in the previous example. Because G.711 is the primary content, the M bit for the packets will in general not be set, except after periods of silence.
これは1つのメディアの流れを示します、第一の内容としてのG.711(すなわち、声か声のバンドデータ)と共に、3ブロックの電話出来事と共に。 RFC2198は、多量以上の表現(すなわち、G.711)が第一のものであることを必要とします。 出来事の最新のブロックは音声帯域データと同じ期間をカバーしています。 他の2つの流れが前の例のように出来事の1番目と2番目の「再-トランスミッション」を提供します。 G.711が第一の内容であるので、一般に、パケットのために噛み付かれたMは設定されないでしょう、沈黙の期間の後を除いて。
Figure 2 shows the detailed packet content for the same sample point as in the previous figure, but including the G.711 content.
図2は前の図にもかかわらず、含むのにおけるG.711内容と同じサンプルポイント詳細なパケット含有量を示しています。
Schulzrinne & Taylor Standards Track [Page 37] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[37ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |0| PT=99 | sequence number = seq0 + 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp = ts0 + 13280 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 720 | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 267 | block length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 0 | block length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| block PT=100| (begin block for /ANSam ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0|0| PT=99| 一連番号=seq0+48| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ=ts0+13280| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 太平洋標準時のブロック=101| タイムスタンプは=720を相殺しました。| ブロック長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 太平洋標準時のブロック=101| タイムスタンプは=267を相殺しました。| ブロック長=28| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 太平洋標準時のブロック=101| タイムスタンプは=0を相殺しました。| ブロック長=36| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 太平洋標準時のブロック=100| (/ANSamのためにブロックを始めてください…) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ANSam block (second retransmission)
/ANSamブロック(2番目の「再-トランスミッション」)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事=35|1|R| ボリューム| 持続時間=533| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel)
(first retransmission)
最初に、JM(V.21の高いチャンネルによる=「1111111」)の7ビット(最初に、「再-トランスミッション」)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事=40|1|R| ボリューム| 持続時間=27| 同様..出来事..持続時間..それぞれ| 出来事=40|1|R| ボリューム| 持続時間=27| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next 9 bits of JM (="111000000" in V.21 high channel)
(new content)
JM(V.21の高いチャンネルによる=「111000000」)の次の9ビット(新しい内容)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (7 similar events, codes 40,40,39,39,39,39,39 and /
/ durations 26,27,27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 39 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出来事=40|1|R| ボリューム| 持続時間=27| 同様..出来事..コード..持続時間..それぞれ| 出来事=39|1|R| ボリューム| 持続時間=27| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Schulzrinne & Taylor Standards Track [Page 38] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[38ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
30 ms of G.711-encoded voice-band data (240 samples)
30 G.711によってコード化された音声帯域データのms(240個のサンプル)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 1 | Sample 2 | Sample 3 | Sample 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ . . . /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 237 | Sample 238 | Sample 239 | Sample 240 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サンプル1| サンプル2| サンプル3| サンプル4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / . . . / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サンプル237| サンプル238| サンプル239| サンプル240| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Packet Contents with Voice-Band Data Combined with Events
図2: 音声帯域データが出来事に結合されているパケットコンテンツ
5. Security Considerations
5. セキュリティ問題
The V.21 bit events defined in this document may be used to transmit user-sensitive data. This could include initial log-on sequences and application-level protocol exchanges as well as user content. As a result, such a usage of V.21 bit events entails, in the terminology of [16], threats to both communications and system security. The attacks of concern are:
出来事が定義したV.21ビットは、ユーザ極秘データを伝えるのに本書では使用されるかもしれません。 これはユーザ内容と同様に初期のログオン系列とアプリケーションレベルプロトコル交換を含むかもしれません。 その結果、V.21ビット出来事のそのような用法は[16]の用語でコミュニケーションとシステムセキュリティの両方への脅威を伴います。 関心の攻撃は以下の通りです。
o confidentiality violations and password sniffing;
o 秘密性違反とパスワードのかぐこと。
o hijacking of data sessions through message insertion;
o メッセージ挿入によるデータセッションのハイジャック。
o modification of the transmitted content through man-in-the-middle
attacks;
o 介入者攻撃による伝えられた内容の変更。
o denial of service by means of message insertion, deletion, and
modification aimed at interference with the application protocol.
o メッセージ挿入、削除、および変更によるサービスの否定はアプリケーション・プロトコルの干渉を目的としました。
To prevent these attacks, the transmission of V.21 bit events MUST be given confidentiality protection. Message authentication and the protection of message integrity MUST also be provided. These address the threats posed by message insertion and modification. With these measures in place, RTP sequence numbers and the redundancy provided by the RFC 4733 procedures for transmission of events add protection against and some resiliency in the face of message deletion.
これらの攻撃、V.21ビットのトランスミッションを防ぐために、秘密性保護を出来事に与えなければなりません。 また、通報認証とメッセージの保全の保護を提供しなければなりません。 これらはメッセージ挿入と変更で引き起こされた脅威を記述します。 適所にあるこれらの測定、RTP一連番号、出来事のトランスミッションのための4733の手順が保護を加えるRFCによって提供された冗長、およびメッセージ削除に直面して何らかの弾性で。
The other events defined in this document (and V.21 bit events within control sequences) are used only for the setup and control of sessions between data terminals or fax devices. While disclosure of these events would not expose user-sensitive data, it can potentially expose capabilities of the user equipment that could be exploited by attacks in the PSTN domain. Thus, confidentiality protection SHOULD be provided. The primary threat is denial of service, through injection of inappropriate signals at vulnerable points in the control sequence or through alteration or blocking of enough event
本書では(V.21は制御配列の中で出来事に噛み付いた)定義された他の出来事はデータ端末かファックス装置の間のセッションのセットアップとコントロールにだけ使用されます。 これらの出来事の公開がユーザ極秘データを露出していないだろうという間、それは潜在的にPSTNドメインでの攻撃で利用できるだろうユーザ設備の能力を露出できます。 その結果、秘密性保護SHOULD、提供してください。 第一の脅威は、制御配列の損傷を受けやすい箇所の不適当な信号の注射を通した、または、変更を通したサービスの否定か十分な出来事のブロッキングです。
Schulzrinne & Taylor Standards Track [Page 39] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[39ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
packets to disrupt that sequence. To meet the injection threat, message authentication and integrity protection MUST be provided.
その系列を混乱させるパケット。 注射の脅威、通報認証、および保全保護を満たすのを提供しなければなりません。
The Secure Real-time Transport Protocol (SRTP) [3] meets the requirements for protection of confidentiality, message integrity, and message authentication described above. It SHOULD therefore be used to protect media streams containing the events described in this document.
Secureレアル-時間Transportプロトコル(SRTP)[3]は上で説明された秘密性、メッセージの保全、および通報認証の保護のために条件を満たします。 それ、SHOULD、したがって、使用されて、本書では説明された出来事を含むメディアの流れを保護してください。
Note that the appropriate method of key distribution for SRTP may
vary with the specific application.
特定のアプリケーションに従ってSRTPに、主要な分配の適切な方法が異なるかもしれないことに注意してください。
In some deployments, it may be preferable to use other means to
provide protection equivalent to that provided by SRTP.
いくつかの展開では、SRTPによって提供されたそれに同等な保護を提供する他の手段を使用するのは望ましいかもしれません。
6. IANA Considerations
6. IANA問題
This document adds the events in Table 10 to the registry established by RFC 4733 [5].
このドキュメントはRFC4733[5]によって確立された登録にTable10の出来事を加えます。
+-------+--------------------------------------------+--------------+ | Event | Event Name | Reference | | Code | | | +-------+--------------------------------------------+--------------+ | 23 | CRdSeg: second segment of V.8 bis CRd | RFC 4734 | | | signal | | | | | | | 24 | CReSeg: second segment of V.8 bis CRe | RFC 4734 | | | signal | | | | | | | 25 | MRdSeg: second segment of V.8 bis MRd | RFC 4734 | | | signal | | | | | | | 26 | MReSeg: second segment of V.8 bis MRe | RFC 4734 | | | signal | | | | | | | 27 | V32AC: A pattern of bits modulated at 4800 | RFC 4734 | | | bits/s, emitted by a V.32/V.32bis | | | | answering terminal upon detection of the | | | | AA pattern. | | | | | | | 28 | V8bISeg: first segment of initiating V.8 | RFC 4734 | | | bis signal | | | | | | | 29 | V8bRSeg: first segment of responding V.8 | RFC 4734 | | | bis signal | | | | | |
+-------+--------------------------------------------+--------------+ | 出来事| イベント名| 参照| | コード| | | +-------+--------------------------------------------+--------------+ | 23 | CRdSeg: 2回V.8のセグメントを後援してください、CRd| RFC4734| | | 信号| | | | | | | 24 | CReSeg: 2回V.8のセグメントを後援してください、CRe| RFC4734| | | 信号| | | | | | | 25 | MRdSeg: 2回V.8のセグメントを後援してください、MRd| RFC4734| | | 信号| | | | | | | 26 | MReSeg: 2回V.8のセグメントを後援してください、MRe| RFC4734| | | 信号| | | | | | | 27 | V32AC: 4800年に調節されたビットのパターン| RFC4734| | | V.32/V.32bisによって放たれたビット/s| | | | 検出での端末に答えます。| | | | AAは型に基づいて作ります。 | | | | | | | 28 | V8bISeg: V.8を開始する最初のセグメント| RFC4734| | | 2回合図してください。| | | | | | | 29 | V8bRSeg: V.8を反応させる最初のセグメント| RFC4734| | | 2回合図してください。| | | | | |
Schulzrinne & Taylor Standards Track [Page 40] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[40ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
| 30 | V21L300: 300 bits/s low channel V.21 | RFC 4734 | | | indication | | | | | | | 31 | V21H300: 300 bits/s high channel V.21 | RFC 4734 | | | indication | | | | | | | 32 | ANS (V.25 Answer tone). Also known as CED | RFC 4734 | | | (T.30 Called tone). | | | | | | | 33 | /ANS (V.25 Answer tone after phase shift). | RFC 4734 | | | Also known as /CED (T.30 Called tone after | | | | phase shift) | | | | | | | 34 | ANSam (V.8 amplitude modified Answer tone) | RFC 4734 | | | | | | 35 | /ANSam (V.8 amplitude modified Answer tone | RFC 4734 | | | after phase shift) | | | | | | | 36 | CNG (T.30 Calling tone) | RFC 4734 | | | | | | 37 | V.21 channel 1 (low channel), '0' bit | RFC 4734 | | | | | | 38 | V.21 channel 1, '1' bit. Also used for | RFC 4734 | | | ESiSeg (second segment of V.8 bis ESi | | | | signal). | | | | | | | 39 | V.21 channel 2, '0' bit | RFC 4734 | | | | | | 40 | V.21 channel 2, '1' bit. Also used for | RFC 4734 | | | ESrSeg (second segment of V.8 bis ESr | | | | signal). | | | | | | | 49 | CT (V.25 Calling Tone) | RFC 4734 | | | | | | 52 | ANS2225: 2225-Hz indication for text | RFC 4734 | | | telephony | | | | | | | 53 | CI (V.8 Call Indicator signal preamble) | RFC 4734 | | | | | | 54 | V.21 preamble flag (T.30) | RFC 4734 | | | | | | 55 | V21L110: 110 bits/s V.21 indication for | RFC 4734 | | | text telephony | | | | | | | 56 | B103L300: Bell 103 low channel indication | RFC 4734 | | | for text telephony | | | | | |
| 30 | V21L300: 低い300ビット/sのチャンネルV.21| RFC4734| | | 指示| | | | | | | 31 | V21H300: 300高さビット/sのチャンネルV.21| RFC4734| | | 指示| | | | | | | 32 | ANS(V.25 Answerは調子を変えます)。 また、CEDとして、知られています。| RFC4734| | | (トーンと呼ばれるT.30。) | | | | | | | 33 | /ANS(V.25 Answerはフェーズシフトの後に調子を変えます)。 | RFC4734| | | (T.30 Calledは||次々と調子を変えさせます| | フェーズシフト)また、/CEDとして知られていて、| | | | | | | 34 | ANSam(V.8振幅の変更されたAnswerは調子を変えます)| RFC4734| | | | | | 35 | /ANSam(変更されたAnswerが調子を変えさせるV.8振幅| RFC4734| | | 後フェーズのシフト)| | | | | | | 36 | CNG(T.30 Callingは調子を変えます)| RFC4734| | | | | | 37 | V.21チャンネル1(低いチャンネル)、'0'は噛み付きました。| RFC4734| | | | | | 38 | V.21チャンネル1、'1'は噛み付きました。 また、使用されています。| RFC4734| | | ESiSeg、(2回V.8のセグメントを後援してください、ESi| | | | 信号、) | | | | | | | 39 | V.21チャンネル2、'0'は噛み付きました。| RFC4734| | | | | | 40 | V.21チャンネル2、'1'は噛み付きました。 また、使用されています。| RFC4734| | | ESrSeg、(2回V.8のセグメントを後援してください、ESr| | | | 信号、) | | | | | | | 49 | コネチカット(トーンと呼ぶV.25)| RFC4734| | | | | | 52 | ANS2225: テキストのための2225Hzの指示| RFC4734| | | 電話| | | | | | | 53 | CI(V.8 Call Indicator信号序文)| RFC4734| | | | | | 54 | V.21序文旗(T.30)| RFC4734| | | | | | 55 | V21L110: 110ビット/sのV.21指示| RFC4734| | | テキスト電話| | | | | | | 56 | B103L300: ベル103の低いチャンネル指示| RFC4734| | | テキスト電話のために| | | | | |
Schulzrinne & Taylor Standards Track [Page 41] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[41ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
| 57 | V23Main: V.23 main channel indication for | RFC 4734 | | | text telephony | | | | | | | 58 | V23Back: V.23 back channel indication for | RFC 4734 | | | text telephony | | | | | | | 59 | Baud4545: 45.45 bits/s Baudot indication | RFC 4734 | | | for text telephony | | | | | | | 60 | Baud50: 50 bits/s Baudot indication for | RFC 4734 | | | text telephony | | | | | | | 61 | VBDGen: Tone patterns indicative of use of | RFC 4734 | | | an unidentified modem type | | | | | | | 62 | XCIMark: A pattern of bits modulated in | RFC 4734 | | | the V.23 main channel, emitted by a V.18 | | | | calling terminal. | | | | | | | 63 | V32AA: A pattern of bits modulated at 4800 | RFC 4734 | | | bits/s, emitted by a V.32/V.23bis calling | | | | terminal. | | +-------+--------------------------------------------+--------------+
| 57 | V23Main: V.23メインは指示を向けます。| RFC4734| | | テキスト電話| | | | | | | 58 | V23Back: V.23はチャンネル指示を支持します。| RFC4734| | | テキスト電話| | | | | | | 59 | Baud4545: 45.45 ビット/s Baudot指示| RFC4734| | | テキスト電話のために| | | | | | | 60 | Baud50: 50ビット/sのBaudot指示| RFC4734| | | テキスト電話| | | | | | | 61 | VBDGen: トーンは役に立った状態で暗示を型に基づいて作ります。| RFC4734| | | 未確認のモデムタイプ| | | | | | | 62 | XCIMark: 変調されたビットのパターン| RFC4734| | | V.18によって放たれたV.23のメインチャンネル| | | | 端末と呼びます。 | | | | | | | 63 | V32AA: 4800年に調節されたビットのパターン| RFC4734| | | V.32/V.23bisの呼ぶことで放たれたビット/s| | | | 端末。 | | +-------+--------------------------------------------+--------------+
Table 10: Data-Related Additions to RFC 4733 Telephony Event Registry
テーブル10: RFC4733電話イベント登録へのデータ関連の追加
7. Acknowledgements
7. 承認
Scott Petrack was the original author of RFC 2833. Henning Schulzrinne later loaned his expertise to complete the document, but Scott must be credited with the energy behind the idea of a compact encoding of tones over IP.
スコットPetrackはRFC2833の原作者でした。 ヘニングSchulzrinneは後でドキュメントを完成するために彼の専門的技術を貸与しましたが、IPの上にトーンのコンパクトなコード化の考えの後ろにスコットにエネルギーについて貸し方に記入しなければなりません。
Gunnar Hellstrom and Keith Chu provided particularly useful comments helping to shape the present document. Amiram Allouche and Ido Benda drew the authors' attention to the value of including events for V.32/V.32bis in the document, and Yaakov Stein confirmed details of operation of this modem.
グナー・ヘルストリョームとキース・チュウは現在のドキュメントを形成するのを助ける特に役に立つコメントを提供しました。 Amiram AlloucheとIdoベンダはドキュメントのV.32/V.32bisのために出来事を含む値に作者の注意を引きつけました、そして、Yaakovシタインはこのモデムの操作の詳細を確認しました。
Schulzrinne & Taylor Standards Track [Page 42] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[42ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP
Payload for Redundant Audio Data", RFC 2198, September 1997.
[2] パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ-ガルシア、A.、およびS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(1997年9月)。
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
2004年の[3]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[5] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits,
Telephony Tones, and Telephony Signals", RFC 4733, December
2006.
[5]SchulzrinneとH.とT.テイラー、「DTMFケタ、電話トーン、および電話信号のためのRTP有効搭載量」、RFC4733、2006年12月。
[6] International Telecommunication Union, "Echo suppressors",
ITU-T Recommendation G.164, November 1988.
[6]国際電気通信連合、「エコーサプレッサ」、ITU-T Recommendation G.164、1988年11月。
[7] International Telecommunication Union, "Echo cancellers", ITU-T
Recommendation G.165, March 1993.
[7]国際電気通信連合、「エコーキャンセラー」、ITU-T Recommendation G.165、1993年3月。
[8] International Telecommunication Union, "Procedures for document
facsimile transmission in the general switched telephone
network", ITU-T Recommendation T.30, July 2003.
[8]国際電気通信連合、「一般的な切り換えられた電話網におけるドキュメントファクシミリ伝送のための手順」、ITU-T Recommendation T.30、2003年7月。
[9] International Telecommunication Union, "Procedures for starting
sessions of data transmission over the public switched
telephone network", ITU-T Recommendation V.8, November 2000.
[9] 国際電気通信連合、「公衆の上でデータ伝送のセッションを始めるための手順は電話網を切り換えました」、ITU-T Recommendation V.8、2000年11月。
[10] International Telecommunication Union, "Procedures for the
identification and selection of common modes of operation
between data circuit-terminating equipments (DCEs) and between
data terminal equipments (DTEs) over the public switched
telephone network and on leased point-to-point telephone-type
circuits", ITU-T Recommendation V.8 bis, November 2000.
[10] 国際電気通信連合、「公衆電話交換網の上と、そして、賃貸されたポイントツーポイントにおけるサーキットを終えるデータ機器(DCEs)とデータ端末装置の間の一般的な運転モード(DTEs)の識別と品揃えのための手順はサーキットを電話でタイプします」、ITU-T Recommendation V.8。2回、2000年11月。
[11] International Telecommunication Union, "Operational and
interworking requirements for {DCEs operating in the text
telephone mode", ITU-T Recommendation V.18, November 2000.
[11] 国際電気通信連合、「操作上と織り込む要件、テキストで作動するDCEsがモードに電話をする、」、ITU-T Recommendation V.18(2000年11月)
See also Recommendation V.18 Amendment 1, Nov. 2002.
また、Recommendation V.18 Amendment1、2002年11月を見てください。
Schulzrinne & Taylor Standards Track [Page 43] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[43ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
[12] International Telecommunication Union, "300 bits per second
duplex modem standardized for use in the general switched
telephone network", ITU-T Recommendation V.21, November 1988.
[12] 国際電気通信連合、「複式のモデムが司令官における使用のために標準化した300のbpsが電話網を切り換えました」、ITU-T Recommendation V.21、1988年11月。
[13] International Telecommunication Union, "Automatic answering
equipment and general procedures for automatic calling
equipment on the general switched telephone network including
procedures for disabling of echo control devices for both
manually and automatically established calls", ITU-T
Recommendation V.25, October 1996.
[13] 国際電気通信連合、「手動的で自動的に両方のためのエコー制御装置を無能にする手順を含む一般的な切り換えられた電話網の自動呼び出し装置のための自動応答装置と基本手順は呼び出しを確立しました」、ITU-T Recommendation V.25、1996年10月。
See also Corrigendum 1 to Recommendation V.25, Jul. 2001.
また、Recommendation V.25、2001年7月までのCorrigendum1を見てください。
[14] International Telecommunication Union, "A family of 2-wire,
duplex modems operating at data signalling rates of up to 9600
bit/s for use on the general switched telephone network and on
leased telephone-type circuits", ITU-T Recommendation V.32,
March 1993.
[14] 国際電気通信連合、「2ワイヤの家族、一般的な切り換えられた電話網における使用において9600ビット/sに候補になっていてオンのデータ合図速度で作動する複式のモデムは電話タイプサーキットを賃貸しました」、ITU-T Recommendation V.32、1993年3月。
[15] International Telecommunication Union, "A duplex modem
operating at data signalling rates of up to 14 400 bit/s for
use on the general switched telephone network and on leased
point-to-point 2-wire telephone-type circuits", ITU-T
Recommendation V.32bis, February 1991.
[15] 国際電気通信連合、「司令官における使用のために最大14のデータ合図速度で400ビット/sを操作する複式のモデムは電話網と賃貸された二地点間2有線電話タイプサーキットを切り換えました」、ITU-T Recommendation V.32bis、1991年2月。
8.2. Informative References
8.2. 有益な参照
[16] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
[16] レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[17] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent
Call", RFC 4040, April 2005.
[17]Kreuter、R.、「64kbit/s Transparent CallのためのRTP有効搭載量Format」、RFC4040、2005年4月。
[18] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[18] ヘルストリョームとG.とP.ジョーンズ、「テキストの会話のためのRTP有効搭載量」、RFC4103、2005年6月。
[19] International Telecommunication Union, "Pulse code modulation
(PCM) of voice frequencies", ITU-T Recommendation G.711,
November 1988.
[19] 国際電気通信連合、「音声周波数のパルス符号変調(PCM)」、ITU-T Recommendation G.711、1988年11月。
[20] International Telecommunication Union, "Terminal for low bit-
rate multimedia communication", ITU-T Recommendation H.324,
March 2002.
[20] 国際電気通信連合、「低いビットレートマルチメディア通信のための端末」、ITU-T Recommendation H.324、2002年3月。
[21] International Telecommunication Union, "Procedures for real-
time Group 3 facsimile communication over IP networks", ITU-T
Recommendation T.38, July 2003.
[21]国際電気通信連合、ITU-T Recommendation T.38、2003年7月「Group3がIPネットワークの上でコミュニケーションを電送するリアルタイムのための手順」
Schulzrinne & Taylor Standards Track [Page 44] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[44ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
[22] International Telecommunication Union, "International
interworking for videotex services", ITU-T
Recommendation T.101, November 1994.
[22] 国際電気通信連合、「ビデオテックスサービスのための国際織り込む」ITU-T Recommendation T.101、1994年11月。
[23] International Telecommunication Union, "Data protocols for
multimedia conferencing", ITU-T Recommendation T.120,
July 1996.
[23]国際電気通信連合、「マルチメディア会議のためのデータプロトコル」、ITU-T Recommendation T.120、1996年7月。
[24] International Telecommunication Union, "A 2-wire modem for
facsimile applications with rates up to 14 400 bit/s", ITU-T
Recommendation V.17, February 1991.
[24]国際電気通信連合、「レート最大14 400ビット/sとのファクシミリアプリケーションのための2ワイヤのモデム」、ITU-T Recommendation V.17(1991年2月)。
[25] International Telecommunication Union, "600/1200-baud modem
standardized for use in the general switched telephone
network", ITU-T Recommendation V.23, November 1988.
[25] 国際電気通信連合、「一般的な切り換えられた電話網における使用のために標準化された600/1200ボーのモデム」、ITU-T Recommendation V.23、1988年11月。
[26] International Telecommunication Union, "4800/2400 bits per
second modem standardized for use in the general switched
telephone network", ITU-T Recommendation V.27ter,
November 1988.
[26] 国際電気通信連合、「モデムが司令官における使用のために標準化した4800/2400のbpsが電話網を切り換えました」、ITU-T Recommendation V.27ter、1988年11月。
[27] International Telecommunication Union, "9600 bits per second
modem standardized for use on point-to-point 4-wire leased
telephone-type circuits", ITU-T Recommendation V.29,
November 1988.
[27] 国際電気通信連合、「モデムが二地点間4ワイヤにおける使用のために標準化した9600のbpsが電話タイプサーキットを賃貸しました」、ITU-T Recommendation V.29、1988年11月。
[28] International Telecommunication Union, "A modem operating at
data signalling rates of up to 33 600 bit/s for use on the
general switched telephone network and on leased point-to-point
2-wire telephone-type circuits", ITU-T Recommendation V.34,
February 1998.
[28] 国際電気通信連合、「司令官における使用のために最大33のデータ合図速度で600ビット/sを操作するモデムは電話網と賃貸された二地点間2有線電話タイプサーキットを切り換えました」、ITU-T Recommendation V.34、1998年2月。
[29] International Telecommunication Union, "A digital modem and
analogue modem pair for use on the Public Switched Telephone
Network (PSTN) at data signalling rates of up to 56 000 bit/s
downstream and up to 33 600 bit/s upstream", ITU-T
Recommendation V.90, September 1998.
[29] 国際電気通信連合、「デジタル・モデムとアナログモデムはデータにおける川下で最大56のレートに000ビット/s合図している、最大33のPublic Switched Telephone Network(PSTN)における使用のために上流へ600ビット/s対にします」、ITU-T Recommendation V.90、1998年9月。
[30] International Telecommunication Union, "A digital modem
operating at data signalling rates of up to 64 000 bit/s for
use on a 4-wire circuit switched connection and on leased
point-to-point 4-wire digital circuits", ITU-T
Recommendation V.91, May 1999.
[30] 国際電気通信連合、「4有線回路における使用のために最大64のデータ合図速度で000ビット/sを操作するデジタル・モデムは接続と賃貸された二地点間4ワイヤのディジタル回路を切り換えました」、ITU-T Recommendation V.91、1999年5月。
[31] International Telecommunication Union, "Enhancements to
Recommendation V.90", ITU-T Recommendation V.92, November 2000.
[31]国際電気通信連合、「推薦V.90"、ITU-T推薦V.92、2000年11月までの増進。」
Schulzrinne & Taylor Standards Track [Page 45] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[45ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
[32] International Telecommunication Union, "Modem-over-IP networks:
Procedures for the end-to-end connection of V-series DCEs",
ITU-T Recommendation V.150.1, January 2003.
[32] 国際電気通信連合、「モデム過剰IPは以下をネットワークでつなぎます」。 「終わりから終わりとのV-シリーズDCEsの接続のための手順」、ITU-T Recommendation V.150.1、2003年1月。
[33] International Telecommunication Union, "Procedures for
supporting voice-band data over IP networks", ITU-T
Recommendation V.152, January 2005.
[33]国際電気通信連合、「IPネットワークの上で音声帯域データを支持するための手順」、ITU-T Recommendation V.152、2005年1月。
[34] Telecommunications Industry Association, "A Frequency Shift
Keyed Modem for Use on the Public Switched Telephone Network",
ANSI TIA- 825-A-2003, April 2003.
[34]電気通信産業連盟、「公衆電話交換網における使用のための振動数シフトの合わせられたモデム」、ANSI TIA825-A-2003(2003年4月)。
Authors' Addresses
作者のアドレス
Henning Schulzrinne Columbia U. Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 US
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinneコロンビアU.部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada
トム・テイラーノーテル1852ロレーヌAveオンタリオK1H 6Z8オタワ(カナダ)
EMail: taylor@nortel.com
メール: taylor@nortel.com
Schulzrinne & Taylor Standards Track [Page 46] RFC 4734 Modem, Fax, and Text Telephony Events December 2006
Schulzrinneとテイラー標準化過程[46ページ]の4734年のRFCモデム、ファックス、およびテキスト電話イベント2006年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Schulzrinne & Taylor Standards Track [Page 47]
Schulzrinneとテイラー標準化過程[47ページ]
一覧
スポンサーリンク
