RFC 4734
Definition of Events for Modem, Fax, and Text Telephony Signals
3. Strategies for Handling Fax and Modem Signals
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. 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. 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. 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.
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. 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. 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.4. Example of V.8 Negotiation
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: o simultaneous transmission of events and retransmitted events using RFC 2198 [2] redundancy; o simultaneous transmission of events, retransmitted events, and voice-band data covering the same content using RFC 2198 redundancy. 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
event packetization interval is 30 ms, a reasonable compromise between packet volume and buffering delay, particularly for V.21 events. 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. +------------+------------------------------------------------------+ | 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. | | | |
| 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. |
| | | | 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. | | | |
| 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. |
| | |
| . . . | . . . |
+------------+------------------------------------------------------+
Table 9: Events for Example V.8 Scenario
4.1. Simultaneous Transmission of Events and Retransmitted Events Using RFC 2198 Redundancy
Negotiation of the transmission mode being described in this section would use SDP similar to the following: 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 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. 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. 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.
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 ...) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /ANSam block (second retransmission) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event = 35 |1|R| volume | duration = 533 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ First 7 bits of JM (="1111111" in V.21 high channel) (first retransmission) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event = 40 |1|R| volume | duration = 27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / (5 similar events, durations 27,26,27,27,26 respectively) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event = 40 |1|R| volume | duration = 27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next 9 bits of JM (="111000000" in V.21 high channel) (new content) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Packet Contents, Redundant Events Only
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.4.2. Simultaneous Transmission of Events and Voice-Band Data Using RFC 2198 Redundancy
Negotiation of the transmission mode being described in this section would use SDP similar to the following: 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 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. Figure 2 shows the detailed packet content for the same sample point as in the previous figure, but including the G.711 content.
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 ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ANSam block (second retransmission)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel)
(first retransmission)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next 9 bits of JM (="111000000" in V.21 high channel)
(new content)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
30 ms of G.711-encoded voice-band data (240 samples) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sample 1 | Sample 2 | Sample 3 | Sample 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / . . . / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sample 237 | Sample 238 | Sample 239 | Sample 240 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Packet Contents with Voice-Band Data Combined with Events5. Security Considerations
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: o confidentiality violations and password sniffing; o hijacking of data sessions through message insertion; o modification of the transmitted content through man-in-the-middle attacks; o denial of service by means of message insertion, deletion, and modification aimed at interference with the application protocol. 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. 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
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. Note that the appropriate method of key distribution for SRTP may vary with the specific application. In some deployments, it may be preferable to use other means to provide protection equivalent to that provided by SRTP.6. IANA Considerations
This document adds the events in Table 10 to the registry established by RFC 4733 [5]. +-------+--------------------------------------------+--------------+ | 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 | | | | | |
| 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 | | | | | |
| 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. | | +-------+--------------------------------------------+--------------+ Table 10: Data-Related Additions to RFC 4733 Telephony Event Registry7. Acknowledgements
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. 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.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [5] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006. [6] International Telecommunication Union, "Echo suppressors", ITU-T Recommendation G.164, November 1988. [7] International Telecommunication Union, "Echo cancellers", ITU-T Recommendation G.165, March 1993. [8] International Telecommunication Union, "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, July 2003. [9] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network", ITU-T Recommendation V.8, November 2000. [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. [11] International Telecommunication Union, "Operational and interworking requirements for {DCEs operating in the text telephone mode", ITU-T Recommendation V.18, November 2000. See also Recommendation V.18 Amendment 1, Nov. 2002.
[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. [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. See also Corrigendum 1 to Recommendation V.25, Jul. 2001. [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. [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.8.2. Informative References
[16] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [17] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005. [18] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. [19] International Telecommunication Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988. [20] International Telecommunication Union, "Terminal for low bit- rate multimedia communication", ITU-T Recommendation H.324, March 2002. [21] International Telecommunication Union, "Procedures for real- time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003.
[22] International Telecommunication Union, "International interworking for videotex services", ITU-T Recommendation T.101, November 1994. [23] International Telecommunication Union, "Data protocols for multimedia conferencing", ITU-T Recommendation T.120, July 1996. [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. [25] International Telecommunication Union, "600/1200-baud modem standardized for use in the general switched telephone network", ITU-T Recommendation V.23, November 1988. [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. [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. [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. [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. [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. [31] International Telecommunication Union, "Enhancements to Recommendation V.90", ITU-T Recommendation V.92, November 2000.
[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. [33] International Telecommunication Union, "Procedures for supporting voice-band data over IP networks", ITU-T Recommendation V.152, January 2005. [34] Telecommunications Industry Association, "A Frequency Shift Keyed Modem for Use on the Public Switched Telephone Network", ANSI TIA- 825-A-2003, April 2003.Authors' Addresses
Henning Schulzrinne Columbia U. Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 US EMail: schulzrinne@cs.columbia.edu Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada EMail: taylor@nortel.com
Full Copyright Statement Copyright (C) The IETF Trust (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. 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. 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. 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. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.