RFC 5244
Definition of Events for Channel-Oriented Telephony Signalling
Definition of Events for Channel-Oriented Telephony Signalling 📞✨
Okay bestie, this one is RFC 5244, and it's giving "phone calls but make it packets" 💖. It's a Standards Track document from June 2008, written by Henry Schulzrinne (Columbia University) and Tom Taylor (Nortel) for the Network Working Group. It updates RFC 4733, which is the one that set up the telephony event RTP payload stuff. Ngl, that's the whole relationship 🫶.
Status of This Memo 📋
Okay so this is the boring-but-important bit 🙈. It says this document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. Check the current edition of "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited 🌸.
Abstract 🦋
So the vibe here is that this memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling, specifically when they're carried in the telephony event RTP payload 🎀. It supersedes and adds to the original event code assignments for this in Section 3.14 of RFC 2833. Appendix A of RFC 4733 says some of the RFC 2833 events got deprecated because their specs were ambiguous, erroneous, or redundant. 💀
Here's the tea ☕. The change from Section 3.14 of RFC 2833 is so big that implementations of this document are only fully backward compatible with RFC 2833 implementations in the case of full ABCD-bit signalling. Not all of them, just that one case 😭. This document expands and improves the coverage of signalling systems compared to RFC 2833, so it's a glow-up 💅✨.
Table of Contents 🗂️
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Terminology ................................................3
2. Event Definitions ...............................................4
2.1. Signalling System No. 5 ....................................6
2.1.1. Signalling System No. 5 Line Signals ................6
2.1.2. Signalling System No. 5 Register Signals ............7
2.2. Signalling System R1 and North American MF .................8
2.2.1. Signalling System R1 Line Signals ...................8
2.2.2. Signalling System R1 Register Signals ...............8
2.3. Signalling System R2 ......................................10
2.3.1. Signalling System R2 Line Signals ..................10
2.3.2. Signalling System R2 Register Signals ..............10
2.4. ABCD Transitional Signalling for Digital Trunks ...........12
2.5. Continuity Tones ..........................................14
2.6. Trunk Unavailable Event ...................................14
2.7. Metering Pulse Event ......................................15
3. Congestion Considerations ......................................15
4. Security Considerations ........................................16
5. IANA Considerations ............................................17
6. Acknowledgements ...............................................20
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................211. Introduction ✨
1.1. Overview 🌈
Okay so this document takes the telephony events from RFC 4733 [4] and extends them to cover signalling events that can show up on a circuit in the telephone network 📞. Most of these map to signals in one of several channel-associated signalling systems that are still being used in the PSTN, which is giving legacy but make it work 💜.
Trunks (or circuits) in the PSTN are the media paths between telephone switches 🔌. People developed a bunch of protocols over the years that use tones and electrical conditions on individual trunks to set up calls. The events in this document support an application where that PSTN signalling gets carried between two gateways instead of being signalled in the IP network. This is called the "RTP trunk" application 🦋.
In the "RTP trunk" application, RTP replaces a normal circuit-switched trunk between two nodes. This is super relevant in a phone network that's still mostly circuit-switched 👑. Each end of the RTP trunk encodes audio channels into the right encoding, like G.723.1 [13] or G.729 [14]. But here's the drama 😭: that encoding process destroys in-band signalling info carried in the least-significant bit (that's the "robbed bit signalling" part), and it can also mess with in-band signalling tones, like the MF (multi-frequency) digit tones 💀.
In a typical setup, the gateways can swap roles from one call to the next. They must be capable of either sending or receiving each implemented signal in Table 1 🔥. Yes, it's a must, no cap.
This document defines events for four different signalling systems 🍓. Three of them are based on exchanging multi-frequency tones. The fourth one only works on digital trunks and uses low-order bits stolen from the encoded media. On top of that, this document defines tone events for tasks like continuity testing of the media path 🧚.
Implementors are warned that the descriptions of signalling systems given below are incomplete. They're there to give context to the related event definitions, but they skip lots of details that matter for implementation. Read this part as the vibe check, not the full spec 🙈.
1.2. Terminology 💅
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [1]. They tell you the requirement levels for compliant implementations 🫶.
Besides the abbreviations defined below for specific events, this document also uses these:
KP Key Pulse
MF Multi-frequency
PSTN Public Switched (circuit) Telephone Network
RTP Real-time Transport Protocol [2]
ST Start2. Event Definitions 🎀
Okay, Table 1 lists every event defined in this document 💖. The thing to remember is that, as Table 8 (Appendix A) of RFC 4733 [4] says, some of the RFC 2833 [11] event codes are deprecated now because their specs were ambiguous, erroneous, or redundant 💀. The degree of change from Section 3.14 of RFC 2833 means implementations of this document are only fully backward compatible with RFC 2833 implementations in the case of full ABCD-bit signalling. It expands and improves the coverage of signalling systems, so it's giving upgrade energy ✨.
Also, the IANA registry for telephony event codes was set up by RFC 4733, not by RFC 2833 🧾. So event code assignments originally made in RFC 2833 only show up in the registry if they were reaffirmed in RFC 4733 or in an update to RFC 4733, like this document 🌸.
+---------------------+------------+-------------+--------+---------+
| Event | Frequency | Event Code | Event | Volume? |
| | (Hz) | | Type | |
+---------------------+------------+-------------+--------+---------+
| MF 0...9 | (Table 2) | 128...137 | tone | yes |
| | | | | |
| MF Code 11 (SS No. | 700+1700 | 123 | tone | yes |
| 5) or KP3P/ST3P | | | | |
| (R1) | | | | |
| | | | | |
| MF KP (SS No. 5) or | 1100+1700 | 124 | tone | yes |
| KP1 (R1) | | | | |
| | | | | |
| MF KP2 (SS No. 5) | 1300+1700 | 125 | tone | yes |
| or KP2P/ST2P (R1) | | | | |
| | | | | |
| MF ST (SS No. 5 and | 1500+1700 | 126 | tone | yes |
| R1) | | | | |
| | | | | |
| MF Code 12 (SS No. | 900+1700 | 127 | tone | yes |
| 5) or KP'/STP (R1) | | | | |
| | | | | |
| ABCD signalling | N/A | 144...159 | state | no |
| | | | | |
| AB signalling (C, D | N/A | 208...211 | state | no |
| unused) | | | | |
| | | | | |
| A bit signalling | N/A | 206...207 | state | no |
| (B, C, D unused) | | | | |
| | | | | |
| Continuity | 2000 | 121 | tone | yes |
| check-tone | | | | |
| | | | | |
| Continuity | 1780 | 122 | tone | yes |
| verify-tone | | | | |
| | | | | |
| Metering pulse | N/A | 174 | other | no |
| | | | | |
| Trunk unavailable | N/A | 175 | other | no |
| | | | | |
| MFC Forward 1...15 | (Table 4) | 176...190 | tone | yes |
| | | | | |
| MFC Backward 1...15 | (Table 5) | 191...205 | tone | yes |
+---------------------+------------+-------------+--------+---------+
Table 1: Trunk Signalling Events2.1. Signalling System No. 5 🔢
Okay so Signalling System No. 5 (SS No. 5) is defined in ITU-T Recommendations Q.140 through Q.180 [5] 📚. It has two systems of signals. "Line" signalling is for acquiring and releasing the trunk, and "register" signalling passes digits forward from one switch to the next. Two systems, one vibe, lowkey iconic 👑🌟.
2.1.1. Signalling System No. 5 Line Signals 📞✨
okay so SS No. 5 line signalling is all about tones 🎀 It uses two frequencies, 2400 Hz and 2600 Hz. Most signals use just one tone at a time, but the Clear-forward and Release-guard use both together. 🙈 This is lowkey genius, because carried media content could accidentally duplicate one of those frequencies and drop the call, so the double tone keeps things safe. The specific signal a tone means depends on the stage of call set-up where it shows up 🦋
No events are defined for No. 5 line signalling. 💅 Implementations MAY still use the AB bit events from Section 2.4 (shown in Table 1) to pass SS No. 5 line signals along. If they do that, they MUST use these mappings, which are based on an underlying mapping where A=0 means a 2400 Hz signal is present and B=0 means a 2600 Hz signal is present in the indicated direction:
- both 2400 and 2600 Hz present: event code 208;
- 2400 Hz present: event code 210;
- 2600 Hz present: event code 209;
- neither signal present: event code 211.
The initial event report for each signal SHOULD be generated as soon as the signal is recognized 🔥 and in any case no later than the recognition time given in ITU-T Recommendation Q.141, Table 1 (so 40 ms for "seizing" and "proceed-to-send", and 125 ms for everything else). After that first report, the packetization interval SHOULD be picked with reliable transmission as the top priority 🫶 Also, the receiver has to supply its own volume values when it turns these events back into tones. Plus, the receiver MAY extend the playout of "seizing" until it has received the first report of a KP event (more on that below). That way it has better control over the gap between the end of the seizing signal and the start of KP playout 🧚
The KP has to be sent beginning 80 +/- 20 ms after the SS No. 5 "seizing" signal has stopped. ⏱️💖
2.1.2. Signalling System No. 5 Register Signals 🌈
No. 5 register signalling uses pairs of tones to send digits, plus signals that frame them 👑 The tone combinations and their signals are in Table 2. All signals except KP1 and KP2 last 55 ms. KP1 and KP2 last 100 ms. Inter-signal pauses are always 55 ms. ⭐
Upper Frequency (Hz)
+-----------------+---------+---------+---------+---------+---------+
| Lower Frequency | 900 | 1100 | 1300 | 1500 | 1700 |
| (Hz) | | | | | |
+-----------------+---------+---------+---------+---------+---------+
| 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | Code 11 |
| | | | | | |
| 900 | | Digit 3 | Digit 5 | Digit 8 | Code 12 |
| | | | | | |
| 1100 | | | Digit 6 | Digit 9 | KP1 |
| | | | | | |
| 1300 | | | | Digit 0 | KP2 |
| | | | | | |
| 1500 | | | | | ST |
+-----------------+---------+---------+---------+---------+---------+
Table 2: SS No. 5 Register SignalsThe KP signals mark the start of digit signalling 🎀 KP1 means the call is expected to end up in a national network served by the switch the signalling is going to. KP2 means the call is expected to pass through that switch on its way to another international exchange 🌸 The end of digit signalling is marked by ST ✨ A Code 11 or Code 12 that comes after a country code (and maybe one more digit) means the call should be sent to an operator position in the destination country 💅 A Code 12 can then be followed by more digits that pick out a particular operator to route the call to 💜
Implementations using the telephone-events payload to carry SS No. 5 register signalling MUST use these events from Table 1 to convey the register signals in Table 2 🦋
- event code 128 to convey Digit 0;
- event codes 129-137 to convey Digits 1 through 9, respectively;
- event code 123 to convey Code 11;
- event code 124 to convey KP1;
- event code 125 to convey KP2;
- event code 126 to convey ST;
- event code 127 to convey Code 12.
The sending implementation SHOULD send an initial event report for the KP signals as soon as they are recognized 🔥 and it MUST send an event report for all of these signals once they have finished 🫶
2.2. Signalling System R1 and North American MF 🇺🇸🎀
Signalling System R1 is mainly used in North America, and so is the more common variant just called "MF" 💅 R1 is defined in ITU-T Recommendations Q.310-Q.332 [6], and MF is defined in [9] 📚
Just like SS No. 5, R1/MF has both line and register signals 🌈 The line signals (not counting Busy and Reorder) are implemented on analog trunks by applying a 2600 Hz tone, and on digital trunks by using ABCD signalling. How you read the line signals depends on state, same as with SS No. 5 💜
2.2.1. Signalling System R1 Line Signals ✨
Following Table 1/Q.311, implementations MAY use the A bit events from Section 2.4 (shown in Table 1) to pass along R1 line signals 🦋 If they do, they MUST use these mappings. They're based on an underlying mapping where A=0 means a 2600 Hz signal is present in the indicated direction, and A=1 means that signal is absent:
- 2600 Hz present: event code 206;
- no signal present: event code 207.
2.2.2. Signalling System R1 Register Signals 🧚
R1 has room for 15 codes in forward inter-register signals, but no backward inter-register signals 😭 Each code or digit gets sent as a tone pair from a set of 6 frequencies. The R1 register signals are KP, ST, and the digits "0" through "9". The frequencies for these are in Table 3. These frequencies match the similarly named SS No. 5 register signals, except that KP uses the frequency combination that KP1 uses in SS No. 5 🌸 Table 3 also shows the extra signals used in North American practice: KP', KP2P, KP3P, STP or ST', ST2P, and ST3P [9] 💖
Upper Frequency (Hz)
+------------+---------+---------+---------+---------+--------------+
| Lower | 900 | 1100 | 1300 | 1500 | 1700 |
| Frequency | | | | | |
| (Hz) | | | | | |
+------------+---------+---------+---------+---------+--------------+
| 700 | Digit 1 | Digit 2 | Digit 4 | Digit 7 | KP3P or ST3P |
| | | | | | |
| 900 | | Digit 3 | Digit 5 | Digit 8 | KP' or STP |
| | | | | | |
| 1100 | | | Digit 6 | Digit 9 | KP |
| | | | | | |
| 1300 | | | | Digit 0 | KP2P or ST2P |
| | | | | | |
| 1500 | | | | | ST |
+------------+---------+---------+---------+---------+--------------+
Table 3: R1/MF Register SignalsImplementations using the telephone-events payload to carry North American R1 register signalling MUST use these events from Table 1 to convey the register signals in Table 3 🎀
- event code 128 to convey Digit 0;
- event codes 129-137 to convey Digits 1 through 9, respectively;
- event code 123 to convey KP3P or ST3P;
- event code 124 to convey KP;
- event code 125 to convey KP2P or ST2P;
- event code 126 to convey ST;
- event code 127 to convey KP' or STP.
Just like with the original telephony signals, the receiver reads codes 123, 125, and 127 as KPx or STx signals based on where they sit in the signalling sequence. 🙈💅
Unlike SS No. 5, R1 gives a big tolerance for when register signalling can start after the start-dialling line signal is recognized 🦋 So sending implementations MAY wait to send a KP event report until the KP has finished 🌈
2.3. Signalling System R2 🌸
The International Signalling System R2 is described in ITU-T Recommendations Q.400-Q.490 [7], but there are a bunch of national variants 🌍 R2 line signals are continuous, out-of-band, link by link, and channel associated. R2 (inter)register signals are multi-frequency, compelled, in-band, end-to-end, and also channel associated ✨
2.3.1. Signalling System R2 Line Signals 💜
R2 line signals may be analog, one-bit digital using the A bit in the 16th channel, or digital using both A and B bits. 🎀 Implementations MAY use the A bit or AB bit events from Section 2.4 (shown in Table 1) to pass these signals along. If they do, they MUST use these mappings:
- For the analog R2 line signals in Table 1 of ITU-T Recommendation Q.411, implementations MUST map as follows. The mapping is based on an underlying mapping of A bit = 0 when tone is present. 🔥
- event code 206 (Table 1) is used to indicate the Q.411 "tone-on" condition;
- event code 207 (Table 1), is used to indicate the Q.411 "tone-off" condition.
- The digital R2 line signals in ITU-T Recommendation Q.421 are carried in two bits, A and B. The mapping between A and B bit values and event codes SHALL be the same in both directions and SHALL follow the principles for A and B bit mapping specified in Section 2.4 🫶 iykyk, consistency is everything 👑
2.3.2. Signalling System R2 Register Signals
okay so in R2 the convo starts when the outgoing exchange sends a line "seizing" signal 📞✨. After that line "seizing" signal (plus the "seizing acknowledgment" signal in R2D, if that's in play), everything continues with MF register signals 💅. ITU-T Recommendation Q.441 sorts the forward MF register signals (the upper frequencies) into Groups I and II, and the backward ones (the lower frequencies) into Groups A and B 🎀. The groups matter for what info they carry and where they're allowed to show up in the sequence, so it's not just vibes 🫶.
R2 tones are combos of two out of six frequencies. National versions can drop down to 10 signals (two out of five frequencies) or 6 signals (two out of four frequencies) 🌈.
R2 register signalling is a compelled tone signalling protocol 🔥. That means one tone keeps playing until an "acknowledgment or directive for the next tone" shows up and tells it to stop. A forward R2 register signal gets acknowledged by a backward signal, and a backward signal gets acknowledged by the end of the forward signal 🦋. In the exceptional cases described in ITU-T Rec. Q.442, the downstream entity can send backward signals on its own instead of answering a specific forward signal. wild, I know 💀.
Here's the flow again, bestie: the sequence starts at the outgoing exchange with a forward Group I signal ✨. The first forward signal is usually the first digit of the called number. The incoming exchange usually replies with a backward Group A-1, which basically means "send me the next digit of the called number" 🧚.
The tones have meaning, but the meaning changes depending on where they land in the signalling, and it can also depend on the country 🌸. So to avoid an unmanageable pile of events, this document just gives you a way to indicate the 15 forward and 15 backward MF R2 tones (event codes 176-190 and 191-205, respectively, see Table 1) 💜. The frequency pairs are in Table 4 and Table 5.
⚠️ Quick heads up: a naive way of relaying R2 inter-register signals onward can lead to call setup times that are way too long and timeouts, especially when the call goes through several exchanges plus a gateway before it terminates 😭. There are a few ways to speed up the transfer across a relay point. In the worst case, the relay point has to act as an exchange, terminating the signalling on one side and reoriginating the call on the other 🙈.
Upper Frequency (Hz)
+----------------------+-------+-------+-------+--------+--------+
| Lower Frequency (Hz) | 1500 | 1620 | 1740 | 1860 | 1980 |
+----------------------+-------+-------+-------+--------+--------+
| 1380 | Fwd 1 | Fwd 2 | Fwd 4 | Fwd 7 | Fwd 11 |
| | | | | | |
| 1500 | | Fwd 3 | Fwd 5 | Fwd 8 | Fwd 12 |
| | | | | | |
| 1620 | | | Fwd 6 | Fwd 9 | Fwd 13 |
| | | | | | |
| 1740 | | | | Fwd 10 | Fwd 14 |
| | | | | | |
| 1860 | | | | | Fwd 15 |
+----------------------+-------+-------+-------+--------+--------+
Table 4: R2 Forward Register Signals
Upper Frequency (Hz)
+-----------------+---------+---------+---------+---------+---------+
| Lower Frequency | 1140 | 1020 | 900 | 780 | 660 |
| (Hz) | | | | | |
+-----------------+---------+---------+---------+---------+---------+
| 1020 | Bkwd 1 | | | | |
| | | | | | |
| 900 | Bkwd 2 | Bkwd 3 | | | |
| | | | | | |
| 780 | Bkwd 4 | Bkwd 5 | Bkwd 6 | | |
| | | | | | |
| 660 | Bkwd 7 | Bkwd 8 | Bkwd 9 | Bkwd 10 | |
| | | | | | |
| 540 | Bkwd 11 | Bkwd 12 | Bkwd 13 | Bkwd 14 | Bkwd 15 |
+-----------------+---------+---------+---------+---------+---------+
Table 5: R2 Backward Register Signals2.4. ABCD Transitional Signalling for Digital Trunks
ABCD is a 4-bit signalling system used on digital trunks, where A, B, C, and D are the names of the individual bits 🌷. Signalling can be 16-state (all four bits used), 4-state (A and B bits used), or 2-state (A-bit only used) 💖. ABCD signalling events are all mutually exclusive states, so the most recent state transition decides what the current state is ✨.
When you're using Extended Super Frame (ESF) T1 framing, signalling info is sent as robbed bits in frames 6, 12, 18, and 24 🎀. A D4 superframe only transmits 4-state signalling with A and B bits. On the Conference of European Postal and Telecommunications (CEPT) E1 frame, all signalling rides in timeslot 16, and two channels of 16-state (ABCD) signalling are sent per frame 🌈. ITU-T Recommendation G.704 [10] has all the details on where the ABCD bits go in the different framing setups 📖.
ABCD signals mean different things depending on the application 🦋. One example of a specification for ABCD signalling codes is T1.403.02 [16], which reflects North American practice for "loop" signalling, as opposed to the trunk signalling we talked about in earlier sections 💅.
Since ABCD info is a state rather than a changing signal, implementations SHOULD use the following triple-redundancy mechanism 🫶. It's similar to the one in ITU-T Rec. I.366.2 [15], Annex L. When a transition happens, the same ABCD info gets sent 3 times at 5 ms intervals. If another transition happens during that window, the process keeps going. After a period of no change, the ABCD info gets sent every 5 seconds 🍓.
The 16 possible states are represented by event codes 144 to 159, in order, as shown in Table 1 🧚. Implementations using these event codes MUST map them to and from the ABCD info based on these principles:
- State numbers come from the subset of ABCD bits being used, treated as one binary number where the A bit is the high-order bit 🔥.
- State numbers map to event codes in order of increasing value. So state number 0 maps to event code 144, ..., and state number 15 maps to event code 159 👑.
If only the A and B bits are being used, the mapping to event codes shall be as follows:
- A=0, B=0 maps to event code 208;
- A=0, B=1 maps to event code 209;
- A=1, B=0 maps to event code 210;
- A=1, B=1 maps to event code 211;
Finally, if only the A bit is used:
- A = 0 maps to event code 206;
- A = 1 maps to event code 207;
Separate event codes are assigned to A-bit and AB-bit signalling because, as Rec. G.704 [10] points out, when the B, C, and D bits are unused, their default values differ between transmission systems 🙈. By only specifying codes for the bits that are used, this memo lets the receiving gateway fill in the remaining bits based on local configuration 💜.
2.5. Continuity Tones
Continuity tones are used to test circuit continuity during call setup 🔌. There are two basic procedures. In international practice, clause 7 of ITU-T Recommendation Q.724 [8] describes a procedure for four-wire trunk circuits, where a single 2000 +/- 20 Hz check-tone is sent from the initiating telephone switch. The remote switch sets up a loopback, and the continuity check passes if the sending switch can detect the tone on the return path ✨. Clause 8 of Q.724 covers the procedure for two-wire trunk circuits. That one involves two tones: a 2000 Hz tone sent in the forward direction and a 1780 +/- 20 Hz tone sent back in response 🎀.
Fun fact: implementations often send a slightly different check-tone, like 2010 Hz, because 2000 Hz has some undesirable aliasing properties 🌈.
If implementations use the telephone-events payload type to propagate continuity check-tones, they MUST map these tones to event codes as follows 🦋:
- For four-wire continuity testing, the 2000 Hz check-tone is mapped to event code 121.
- For two-wire continuity testing, the initial 2000 Hz check-tone Hz tone is mapped to event code 121. The 1780 Hz continuity verify-tone is mapped to event code 122.
2.6. Trunk Unavailable Event
This event tells you the trunk is unavailable for service 🚫. The length of the downtime goes in the duration field, and that field should be set to a value that gives adequate granularity for describing downtime 🕐. A value of 1 second is RECOMMENDED ⏱️. When the trunk becomes unavailable, this event is sent with the same timestamp three times at 20 ms intervals. If the trunk is still unavailable when the indicated duration runs out, the event gets retransmitted, preferably with the same redundancy scheme 🔁.
Unavailability can come from a failure or an administrative action 🛠️. This event is used in a stateless way to sync trunk unavailability between equipment connected through provisioned RTP trunks 💫. It also saves bandwidth: you don't have to send a continuous stream of RTP packets with a fixed payload for the whole downtime, which is what you'd need in certain E1-based applications 😌. In T1-based applications, trunk conditioning via the ABCD transitional events can be used instead 🍒.
2.7. Metering Pulse Event
The metering pulse event can be used to transmit meter pulsing for billing purposes 💸. For background info, one possible reference is http://www.seg.co.uk/telecomm/automat3.htm 🔗. Since a metering pulse is a discrete event, each metering pulse event report MUST have both the 'M' and 'E' bits set 💅. Meter pulsing is normally sent out-of-band while the conversation is in progress, so senders MUST therefore be prepared to transmit both the telephone-event and audio payload types at the same time 🎶. Metering pulse events MUST be retransmitted as recommended in Section 2.5.1.4 of RFC 4733 [4] 🔁. 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 ⭐.
3. Congestion Considerations ✨
okay so how well this stuff handles congestion depends on which signalling system you're using 🫶 and it's different for line signals vs register signals 💅
ngl the signals in this doc are pretty chill about longer durations 🦋 so when things get congested, the sender can stretch out the reporting interval for the tones. on the receiving end, if a tone is playing and an under-run happens because packets got delayed or lost 😭, the move is to keep playing the tone until the next packet shows up. cutting a tone off early, with or without resuming it, can make the call setup attempt fail 💀, while extended playout just makes setup take longer. it's giving patience 🌸
register signalling for S.S. No. 5 and R1/MF is the strict one tho ⏱️ both the tone signals and the silent gaps between them have specified durations with tolerances of around 5 to 10 ms. the individual tones run about two to three packetization intervals (55/68 ms, with the initial KP lasting 100 ms). the big thing is that the receiver knows which signal to play at any given moment. it matters way less that it gets timely notice of when each tone ends 🙈 honestly, the receiver should play out the sequence with the durations the signalling standard specifies, not whatever durations got reported 🎀
so for these vibes: once a register signal has been reliably identified, the sender should send a report of that tone ✨ then give an update within 5 ms for reliability, and no more updates until the end of the tone gets reported 💖
a bigger playout buffer at the receiver during register signalling = more reliability 🫧 but that comes with more call setup time, so you gotta weigh it 🧚
4. Security Considerations 🔥
okay this part is SERIOUS bestie 😭 the event codes in this doc are tied straight to setting up, billing, and tearing down phone calls. so, using the terminology from RFC 3552 [12], they're open to threats against both communications and system security 💀 the attacks we need to watch out for are:
- confidentiality violations (monitoring of calling and called numbers);
- establishment of unauthorized telephone connections through message insertion;
- hijacking of telephone connections through message insertion or man-in-the-middle modification of messages;
- denial of service to individual telephone calls through message insertion, modification, deletion, or delay.
these can be prevented with the right confidentiality, authentication, or integrity protection 🔐 if you need any of those, then Secure Real-time Transport Protocol (SRTP) [3] SHOULD be used with automated key management 👑
additional security considerations are described in RFC 4733 [4] 🦋
5. IANA Considerations ✨
okay so this is the part where we tell IANA exactly which event codes are ours 🎀 this doc defines the codes in Table 6, and they're getting added to the telephone-event registry that RFC 4733 [4] set up. every single one of them points back to this document as its reference, so if someone asks where they came from, it's giving this doc 💅
+------------+-----------------------------------------+-----------+
| Event Code | Event Name | Reference |
+------------+-----------------------------------------+-----------+
| 121 | Continuity check-tone | [RFC5244] |
| | | |
| 122 | Continuity verify-tone | [RFC5244] |
| | | |
| 123 | MF Code 11 (SS No. 5) or KP3P/ST3P (R1) | [RFC5244] |
| | | |
| 124 | MF KP (SS No. 5) or KP1 (R1) | [RFC5244] |
| | | |
| 125 | MF KP2 (SS No. 5) or KP2P/ST2P (R1) | [RFC5244] |
| | | |
| 126 | MF ST (SS No. 5 and R1) | [RFC5244] |
| | | |
| 127 | MF Code 12 (SS No. 5) or KP'/STP (R1) | [RFC5244] |
| | | |
| 128 | SS No. 5 or R1 digit "0" | [RFC5244] |
| | | |
| 129 | SS No. 5 or R1 digit "1" | [RFC5244] |
| | | |
| 130 | SS No. 5 or R1 digit "2" | [RFC5244] |
| | | |
| 131 | SS No. 5 or R1 digit "3" | [RFC5244] |
| | | |
| 132 | SS No. 5 or R1 digit "4" | [RFC5244] |
| | | |
| 133 | SS No. 5 or R1 digit "5" | [RFC5244] |
| | | |
| 134 | SS No. 5 or R1 digit "6" | [RFC5244] |
| | | |
| 135 | SS No. 5 or R1 digit "7" | [RFC5244] |
| | | |
| 136 | SS No. 5 or R1 digit "8" | [RFC5244] |
| | | |
| 137 | SS No. 5 or R1 digit "9" | [RFC5244] |
| | | |
| 144 | ABCD signalling state '0000' | [RFC5244] |
| | | |
| 145 | ABCD signalling state '0001' | [RFC5244] |
| | | |
| 146 | ABCD signalling state '0010' | [RFC5244] |
| | | |
| 147 | ABCD signalling state '0011' | [RFC5244] |
| | | |
| 148 | ABCD signalling state '0100' | [RFC5244] |
| | | |
| 149 | ABCD signalling state '0101' | [RFC5244] |
| | | |
| 150 | ABCD signalling state '0110' | [RFC5244] |
| | | |
| 151 | ABCD signalling state '0111' | [RFC5244] |
| | | |
| 152 | ABCD signalling state '1000' | [RFC5244] |
| | | |
| 153 | ABCD signalling state '1001' | [RFC5244] |
| | | |
| 154 | ABCD signalling state '1010' | [RFC5244] |
| | | |
| 155 | ABCD signalling state '1011' | [RFC5244] |
| | | |
| 156 | ABCD signalling state '1100' | [RFC5244] |
| | | |
| 157 | ABCD signalling state '1101' | [RFC5244] |
| | | |
| 158 | ABCD signalling state '1110' | [RFC5244] |
| | | |
| 159 | ABCD signalling state '1111' | [RFC5244] |
| | | |
| 174 | Metering pulse | [RFC5244] |
| | | |
| 175 | Trunk unavailable | [RFC5244] |
| | | |
| 176 | MFC forward signal 1 | [RFC5244] |
| | | |
| 177 | MFC forward signal 2 | [RFC5244] |
| | | |
| 178 | MFC forward signal 3 | [RFC5244] |
| | | |
| 179 | MFC forward signal 4 | [RFC5244] |
| | | |
| 180 | MFC forward signal 5 | [RFC5244] |
| | | |
| 181 | MFC forward signal 6 | [RFC5244] |
| | | |
| 182 | MFC forward signal 7 | [RFC5244] |
| | | |
| 183 | MFC forward signal 8 | [RFC5244] |
| | | |
| 184 | MFC forward signal 9 | [RFC5244] |
| | | |
| 185 | MFC forward signal 10 | [RFC5244] |
| | | |
| 186 | MFC forward signal 11 | [RFC5244] |
| | | |
| 187 | MFC forward signal 12 | [RFC5244] |
| | | |
| 188 | MFC forward signal 13 | [RFC5244] |
| | | |
| 189 | MFC forward signal 14 | [RFC5244] |
| | | |
| 190 | MFC forward signal 15 | [RFC5244] |
| | | |
| 191 | MFC backward signal 1 | [RFC5244] |
| | | |
| 192 | MFC backward signal 2 | [RFC5244] |
| | | |
| 193 | MFC backward signal 3 | [RFC5244] |
| | | |
| 194 | MFC backward signal 4 | [RFC5244] |
| | | |
| 195 | MFC backward signal 5 | [RFC5244] |
| | | |
| 196 | MFC backward signal 6 | [RFC5244] |
| | | |
| 197 | MFC backward signal 7 | [RFC5244] |
| | | |
| 198 | MFC backward signal 8 | [RFC5244] |
| | | |
| 199 | MFC backward signal 9 | [RFC5244] |
| | | |
| 200 | MFC backward signal 10 | [RFC5244] |
| | | |
| 201 | MFC backward signal 11 | [RFC5244] |
| | | |
| 202 | MFC backward signal 12 | [RFC5244] |
| | | |
| 203 | MFC backward signal 13 | [RFC5244] |
| | | |
| 204 | MFC backward signal 14 | [RFC5244] |
| | | |
| 205 | MFC backward signal 15 | [RFC5244] |
| | | |
| 206 | A bit signalling state '0' | [RFC5244] |
| | | |
| 207 | A bit signalling state '1' | [RFC5244] |
| | | |
| 208 | AB bit signalling state '00' | [RFC5244] |
| | | |
| 209 | AB bit signalling state '01' | [RFC5244] |
| | | |
| 210 | AB bit signalling state '10' | [RFC5244] |
| | | |
| 211 | AB bit signalling state '11' | [RFC5244] |
+------------+-----------------------------------------+-----------+
Table 6: Channel-Oriented Signalling Events in the
Audio/Telephone-Event Event Code Registry6. Acknowledgements ✨
big shoutout time 🫶 the full list of thank-yous for RFC 2833 lives in RFC 4733 [4], but for this doc the Editor says these people contributed directly: Flemming Andreasen, Rex Coldren, Bill Foster, Alfred Hoenes, Rajesh Kumar, Aleksandar Lebl, Zarko Markov, Oren Peleg, Moshe Samoha, Adrian Soncodi, and Yaakov Stein. Steve Norreys and Roni Even also gave useful review comments 💜 literally the dream team 👑
7. References 📚
7.1. Normative References
Okay bestie, these are the receipts 🧾 Normative references are the stuff the spec leans on so hard that you literally can't skip them 💅
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [4] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
- [5] International Telecommunication Union, "Specifications for signalling system no. 5", ITU-T Recommendation Q.140-Q.180, November 1988.
- [6] International Telecommunication Union, "Specifications of Signalling System R1", ITU-T Recommendation Q.310-Q.332, November 1988.
- [7] International Telecommunication Union, "Specifications of Signalling System R2", ITU-T Recommendation Q.400-Q.490, November 1988.
- [8] International Telecommunication Union, "Telephone user part signalling procedures", ITU-T Recommendation Q.724, November 1988.
- [9] Telcordia Technologies, "LSSGR: signalling for Analog Interfaces", Generic Requirement GR-506, June 1996.
- [10] International Telecommunication Union, "Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s hierarchical levels", ITU-T Recommendation G.704, October 1998.
7.2. Informative References
Now the extra reading 📚 These ones are super useful for context, but the spec doesn't depend on them to work 🌸
- [11] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
- [12] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
- [13] International Telecommunication Union, "Speech coders : Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996.
- [14] International Telecommunication Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
- [15] International Telecommunication Union, "AAL type 2 service specific convergence sublayer for trunking", ITU-T Recommendation I.366.2, February 1999.
- [16] ANSI/T1, "Network and Customer Installation Interfaces -- DS1 Robbed-Bit signalling State Definitions", American National Standard for Telecommunications T1.403.02-1999, May 1999.
Authors' Addresses ✨
Here's who wrote this 🫶 Henning and Tom, the brains behind it, with their contact info below 💜
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
CA
EMail: tom.taylor@rogers.comFull Copyright Statement 💖
Legal stuff, but it's important, so here it is word for word 💅 The copyright belongs to the IETF Trust, and the disclaimer is below:
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
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 🦋
Last bit, the IPR stuff 🌈 Here's the official wording so nothing gets lost in translation:
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.📦 where this page comes from
- ietf: rfc5244 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms