Definition of Events for Channel-Oriented Telephony Signalling
updates
- rfc-4733 — RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
Extracted elements (29)
R2 register signalling events carry raw tone numbers (MFC Forward 1–15, Backward 1–15) rather than semantic signal names because tone meanings vary by country and call stage. Using semantic names would require an unmanageable number of distinct events.
Separate event codes are assigned for A-bit (206–207) and AB-bit (208–211) signalling even though AB-bit subsumes A-bit, because per ITU-T G.704 the default values of unused B, C, and D bits differ between transmission systems. Specifying codes for only the used bits lets the receiving gateway fill in remaining bits per local configuration.
The trunk unavailable event (code 175) is used statelessly rather than sending a continuous RTP stream, avoiding unnecessary bandwidth consumption during downtime. In T1 applications, trunk conditioning via ABCD transitional events can serve the same purpose.
Implementations of RFC 5244 will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. The degree of change from RFC 2833 Section 3.14 is otherwise substantial because some RFC 2833 event codes were deprecated as ambiguous, erroneous, or redundant.
Implementations often send a 2010 Hz check-tone rather than exactly 2000 Hz due to undesirable aliasing properties of 2000 Hz; the continuity check specification allows ±20 Hz tolerance.
Naive relay of R2 inter-register signals may result in unacceptably long call setup times and timeouts when a call passes through several exchanges and a gateway. In the worst case, the relay point must act as a terminating exchange on one side and reoriginate the call on the other.
The IANA registry for telephony event codes was established by RFC 4733, not RFC 2833. Event code assignments originally made in RFC 2833 appear in the registry only if reaffirmed in RFC 4733 or an update such as RFC 5244.
Each metering pulse event report MUST have both the 'M' and 'E' bits set. Senders MUST be prepared to transmit both telephone-event and audio payload types simultaneously, since meter pulsing normally occurs during conversation.
For ABCD signalling, implementations SHOULD use triple-redundancy: at the time of a transition, the same ABCD information is sent 3 times at an interval of 5 ms, with continuous sending if another transition occurs. After a stable period, ABCD information is sent every 5 seconds.
For R2 digital line signals (Q.421), the mapping between A and B bit values and event codes SHALL be the same in both directions and SHALL follow the A and B bit mapping principles specified in Section 2.4.
For SS No. 5 register signalling, the sending implementation SHOULD send an initial event report for KP signals as soon as they are recognized, and MUST send an event report for all signals as soon as they have completed.
For the SS No. 5 'seizing' line signal, the initial event report SHOULD be generated as soon as the signal is recognized and in any case no later than the recognition time per ITU-T Q.141 Table 1 (40 ms for seizing/proceed-to-send, 125 ms for all others).
If confidentiality, authentication, or integrity protection are needed for telephony signalling events, SRTP SHOULD be used with automated key management.
If implementations use AB bit events to propagate SS No. 5 line signals, they MUST use the specified mappings: both 2400+2600 Hz → code 208, 2400 Hz only → code 210, 2600 Hz only → code 209, neither → code 211.
If implementations use the telephone-events payload to propagate continuity check-tones, they MUST map the 2000 Hz check-tone to event code 121 and the 1780 Hz verify-tone (two-wire procedure) to event code 122.
Implementations using event codes for ABCD signalling MUST map them to/from ABCD information by: (1) deriving state numbers from ABCD bits as a binary number with A as high-order bit, and (2) mapping state numbers to event codes in order of increasing value (state 0 → code 144, state 15 → code 159).
Implementations using the telephone-events payload to carry R1 register signalling MUST use the specified event code mappings (codes 123–128 and 129–137) to convey the register signals shown in Table 3.
Metering pulse events MUST be retransmitted as recommended in Section 2.5.1.4 of RFC 4733. It is RECOMMENDED that the retransmission interval be the lesser of 50 ms and the pulsing rate, but no less than the audio packetization rate.
AB bit signalling (C and D bits unused) uses event codes 208–211 representing states A=0/B=0, A=0/B=1, A=1/B=0, A=1/B=1 respectively. A-bit-only signalling uses event codes 206 (A=0) and 207 (A=1). Both are state-type events with no volume.
ABCD 16-state transitional signalling for digital trunks is represented by event codes 144–159, where the event code equals 144 plus the numeric value of the ABCD bits treated as a 4-bit binary number with A as the high-order bit. These are state-type events with no volume.
Continuity check-tone (2000 Hz, event code 121) and continuity verify-tone (1780 Hz, event code 122) are tone-type events with volume, used for circuit continuity testing during call setup per ITU-T Q.724.
Metering pulse event (event code 174) is an 'other'-type event with no volume, used to transmit meter pulsing for billing. Each event report must have both the 'M' and 'E' bits set, since a metering pulse is a discrete event.
MF digit tones for SS No. 5 and R1 are assigned event codes 128 (digit 0) through 137 (digit 9), with volume. These are tone-type events using two-frequency combinations as defined in Tables 2 and 3.
MF special signals (KP, ST, Code 11/12) shared between SS No. 5 and R1/MF are assigned event codes 123–127: code 123 = MF Code 11/KP3P/ST3P, 124 = MF KP/KP1, 125 = MF KP2/KP2P/ST2P, 126 = MF ST, 127 = MF Code 12/KP'/STP. All are tone-type with volume.
R2 MFC forward register signals 1–15 are assigned event codes 176–190, and R2 MFC backward register signals 1–15 are assigned event codes 191–205. Frequency pairs for all 15 forward and 15 backward signals are defined in Tables 4 and 5 respectively.
Trunk unavailable event (event code 175) is an 'other'-type event with no volume; the duration field indicates the length of downtime, with a recommended granularity of 1 second. Used to synchronize trunk unavailability between gateways connected through provisioned RTP trunks.
RFC 5244 adds event codes 121–137, 144–159, 174–175, 176–205, and 206–211 to the Audio/Telephone-Event Event Code Registry established by RFC 4733. These codes cover MF tones, ABCD signalling states, continuity tones, metering pulse, trunk unavailable, R2 MFC forward/backward signals, and A/AB-bit signalling states.
Telephony signalling events relate directly to setup, billing, and takedown of calls, making them subject to confidentiality violations (monitoring of called/calling numbers), unauthorized call establishment, call hijacking via message insertion or man-in-the-middle, and denial of service via message insertion, modification, deletion, or delay.
ABCD transitional signalling defines 16 mutually exclusive states (event codes 144–159). On a state transition, the same ABCD information is sent 3 times at 5 ms intervals (triple-redundancy per ITU-T I.366.2 Annex L); if no change occurs, ABCD information is then sent every 5 seconds as a keepalive.