RFC 8888

RTP Control Protocol (RTCP) Feedback for Congestion Control

📅 published January 2021, from ietf

Part 1 of 4: RFC 8888, RTP Control Protocol (RTCP) Feedback for Congestion Control 🎀

okay bestie, let's get into it 💖 this one is from the IETF, and it's the Standards Track doc (aka the real deal, not just a suggestion 💅). It's by Z. Sarker (Ericsson AB), C. Perkins (University of Glasgow), V. Singh (callstats.io), and M. Ramalho (AcousticComms). It was published in January 2021 and it's ISSN 2070-1721. It doesn't obsolete or update anything, so no drama there ✨

The whole point of this doc is giving congestion control the detailed feedback it's been begging for 🦋 Right now, RTP gets basic reports (SR and RR packets) that just don't have enough detail for good congestion control. So this RFC defines an RTCP feedback message that lets the receiver send back the stuff the sender needs, and the sender runs the congestion control. Sender-based, periodt 👑

Here's the status and copyright stuff, all there and all tea 🍓

Status of This Memo

This is an Internet Standards Track document 🌸

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Want more info on Internet Standards? Check out Section 2 of RFC 7841 ✨

Info on the current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc8888 🫶

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date. Read them carefully, bestie, they're your rights and restrictions 🙈 If you pull Code Components out of this doc, they have to include Simplified BSD License text (Section 4.e of the Trust Legal Provisions), and they come with no warranty, as described in that license 🔥

Table of Contents

1.  Introduction
2.  Terminology
3.  RTCP Feedback for Congestion Control
  3.1.  RTCP Congestion Control Feedback Report
4.  Feedback Frequency and Overhead
5.  Response to Loss of Feedback Packets
6.  SDP Signaling
7.  Relationship to RFC 6679
8.  Design Rationale
9.  IANA Considerations
10. Security Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🦋

okay so real-time stuff like video calls usually runs on the Real-time Transport Protocol (RTP) [RFC3550] over UDP 📞 RTP doesn't guarantee Quality of Service, reliability, or timely delivery, and it's kinda counting on the transport underneath to handle that. UDP definitely doesn't, so, yikes 💀

RTCP [RFC3550] is the sidekick here 🧚 It lets the receiver regularly send transport and media quality numbers back to the sender, and the sender can use those to run congestion control. The problem is that, without standard messages for this, algorithm designers each made their own proprietary RTCP messages with only the bits their design needed. So the different congestion control designs can't talk to each other, and that's giving "two people speaking different languages at the same party" 😭 Algorithms need room to evolve and need to be interoperable, so a generic congestion control feedback format is highly desirable 🌈

So this memo specifies one common RTCP feedback packet format for unicast RTP congestion control 🎀 It's meant to work for Network-Assisted Dynamic Adaptation (NADA) [RFC8698], Self-Clocked Rate Adaptation for Multimedia (SCReAM) [RFC8298], Google Congestion Control [Google-GCC], and Shared Bottleneck Detection [RFC8382], and hopefully future RTP congestion control algorithms too 🫶

2. Terminology 🌸

Here's the key word situation 💅 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here ✨

Also, the terminology defined in [RFC3550], [RFC4585], and [RFC5506] applies 🧚

3. RTCP Feedback for Congestion Control 💖

Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control [Google-GCC], and Shared Bottleneck Detection [RFC8382], the following per-RTP packet congestion control feedback info has been determined to be necessary 👑

RTP Sequence Number: The receiver needs to feed the sequence numbers of received RTP packets back to the sender, so the sender knows which packets arrived and which got lost 📦 Packet loss is a congestion signal that loads of algorithms use, so this one is a must-have 🔥

Packet Arrival Time: The receiver also needs to feed back the arrival time of each RTP packet 🕰️ Packet delay and/or delay variation (jitter) is a congestion signal some algorithms use, so yeah, it matters 💜

Packet Explicit Congestion Notification (ECN) Marking: If ECN [RFC3168] [RFC6679] is used, the receiver has to feed back the 2-bit ECN mark on each received RTP packet 🦋 That mark says whether it's not-ECT, ECT(0), ECT(1), or ECN Congestion Experienced (ECN-CE). (ECT stands for "ECN-Capable Transport," just so you know 🌈) If the path is ECN capable, the sender can use the ECN-CE info as a congestion control signal 💅

Every RTP flow is identified by its Synchronization Source (SSRC) identifier 🎀 So the RTCP feedback format needs to group its reports by SSRC, with one report block per received SSRC 🍓

Real talk though, host operating system (OS) process interruptions can happen at the worst possible times 😭 So recording RTP send times at the sender, and the matching arrival times at the receiver, has to be done with deliberate care 🙈 OS interruptions can take a big chunk of time compared to the precision you want in one-way delay estimates. Specifically, the send time has to be recorded at the last opportunity before the RTP packet goes out at the sender, and the arrival time has to be recorded at the earliest available opportunity at the receiver ⭐

Part 1 of 4. Parts 2 to 4 are coming up next, so stay tuned, bestie 🌈

3.1. RTCP Congestion Control Feedback Report

okay so the congestion control feedback can ride along in a regular scheduled RTCP report 📅, or it can go out as an RTP/AVPF early feedback packet ⚡. if it's sent early, it MAY be sent in a non-compound RTCP packet [RFC5506], as long as the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] is the one being used 🎀

no matter how it gets there, the feedback is a Transport-Layer Feedback Message (RTCP packet type 205) 🦋. here's the layout, bestie 👇

   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| FMT=11  |   PT = 205    |          length               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 SSRC of RTCP packet sender                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   SSRC of 1st RTP Stream                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          begin_seq            |          num_reports          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R|ECN|  Arrival time offset    | ...                           .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                                                               .
  .                                                               .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   SSRC of nth RTP Stream                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          begin_seq            |          num_reports          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R|ECN|  Arrival time offset    | ...                           |
  .                                                               .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Report Timestamp (32 bits)                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: RTCP Congestion Control Feedback Packet Format

the first 8 octets are a standard RTCP header 🧁. PT=205 and FMT=11 tell you it's a congestion control feedback packet, and the SSRC is set to the one belonging to whoever sent the RTCP packet 🫶.

okay now this part is so cute: [RFC4585] says the RTCP header has to be followed by the SSRC of the RTP flow being reported on 💜 (see Section 6.1 of [RFC4585]). so the header is followed by a report block for each SSRC that has sent RTP packets to you, and then a Report Timestamp at the very end ✨.

each report block starts with the SSRC of the received RTP stream it's talking about 🌸. after that, you get one 16-bit packet metric block for every RTP packet whose sequence number falls in the range begin_seq to begin_seq+num_reports, inclusive. the math is done modulo 65536 so sequence number wrap-around doesn't break anything 🔄. if the number of 16-bit packet metric blocks isn't a multiple of two, then 16 bits of zero padding MUST be added after the last packet metric block, so the end lines up with the next 32-bit boundary 🧸. the value of num_reports MAY be 0, which just means there are no packet metric blocks for that SSRC 🫧. and a report block MUST NOT include more than 16384 packet metric blocks, because it MUST NOT report on more than one quarter of the sequence number space in a single report 🙅‍♀️. no hogging the whole sequence space, bestie.

now each 16-bit packet metric block is made of the R, ECN, and ATO fields, and they work like this:

Received (R, 1 bit): this is a boolean for whether the packet was received 📬. a 0 means the packet hasn't been received yet, and then the next 15 bits (ECN and ATO) are also set to 0 and MUST be ignored 🙈. a 1 means it was received, so you need to parse the rest of the bits in the block 💅.

ECN (2 bits): this is the echoed ECN mark of the packet 🦋. these bits are set to 00 if the packet wasn't received or if ECN isn't being used at all 🤍.

Arrival time offset (ATO, 13 bits): this is when the RTP packet showed up at the receiver, written as an offset before the time in the Report Timestamp (RTS) field of this report ⏰. the ATO is measured in units of 1/1024 seconds, which is picked so the offsets come out exact against the RTS field 🔢. so an ATO of 512 means the packet arrived exactly half a second before the RTS instant 🌗. if the measured value is bigger than 8189/1024 seconds (the one that gets coded as 0x1FFD), then 0x1FFE MUST be reported to flag an over-range measurement 📈💀. and if the measurement isn't available, or the packet arrived after the RTS time, then 0x1FFF MUST be reported for that packet 🚫.

the whole report packet wraps up with the Report Timestamp field (RTS, 32 bits) 🕰️. this is the time instant the packet is reporting on, and it's the reference point for all those arrival time offsets 🎯. its value comes from the same clock used for the NTP timestamp field in RTCP Sender Report (SR) packets 🕐. it's formatted as the middle 32 bits of an NTP format timestamp, as described in Section 4 of [RFC3550] 📚.

okay the rules for how reports get sent are next, and there are a few 🎀. RTCP Congestion Control Feedback Packets SHOULD include a report block for every active SSRC 💜. the sequence number ranges in consecutive reports for one SSRC are usually contiguous, but overlapping reports MAY be sent, and they NEED to be sent when RTP packets get reordered across the edge between two reports 🔀. wait, careful, the original doesn't say NEED: it says "need to be sent", so I'll keep it lowercase here: and they need to be sent when RTP packets get reordered across the boundary between consecutive reports 🔀. and if a packet was reported as received in one report, it MUST also be reported as received in any later overlapping report that covers its sequence number range 🔒. if you send overlapping ranges, newer feedback can update any data from earlier reports for packets that show up in both 🆙.

RTCP Congestion Control Feedback Packets can get big if they're sent infrequently compared to the number of RTP data packets 🐘. if one is too big to fit in the path MTU, its sender SHOULD split it into multiple feedback packets 🧩. the RTCP reporting interval SHOULD be picked so feedback goes out often enough that each packet is small enough to fit in the path MTU 📏. ([RTCP-Multimedia-Feedback] talks about how to pick the reporting interval, and specs for RTP congestion control algorithms can give guidance too 💡.)

if the same RTP packet arrives more than once, the arrival time of the first copy MUST be reported 🥇. and if any copy of the duplicated packet is ECN-CE marked, then an ECN-CE mark MUST be reported for that packet 🚩. otherwise, you report the ECN mark of the first copy that showed up 🎟️.

if no packets come in from an SSRC during a reporting interval, a report block MAY be sent with begin_seq set to the highest sequence number previously received from that SSRC and num_reports set to 0 🫥. or you can just skip it entirely 🤷‍♀️. the matching Sender Report / Receiver Report (SR/RR) packet will have a non-increased extended highest sequence number received field, which tells the sender that nothing came in 📭. it's just easier for processing if that info is in the congestion control feedback reports too 🧠.

last thing, and it's super important 🚨: a report block saying certain RTP packets were lost is NOT a request to retransmit them 🙅‍♀️. the receiver might decide to retransmit those packets if a retransmission payload format has been negotiated, but nothing requires it to do so 💌.

4. Feedback Frequency and Overhead ✨

okay so there's a trade-off here, bestie ⚖️. faster and more accurate reporting costs you more overhead, and you've gotta balance the two 🎀. [RTCP-Multimedia-Feedback] digs into this trade-off, suggests good RTCP feedback rates, and explains how to set things like the RTCP bandwidth fraction so the reporting block from this memo gets used well 📊. specs for RTP congestion control algorithms can give guidance here too 💡.

it's generally understood that congestion control algorithms work better with more frequent feedback 🏃‍♀️. BUT, RTCP bandwidth and transmission rules put an upper limit on how often the feedback messages can go from the RTP receiver to the RTP sender 🧱. in lots of cases, sending feedback once per frame is the upper bound before the overhead gets excessive 😵‍💫. that does depend on the media rate, though, and high-rate media flows might need more frequent feedback [RTCP-Multimedia-Feedback] 🎬. [feedback-requirements] also showed that some candidate congestion control algorithms can run with less frequent feedback, using a feedback interval range of 50-200 ms 🐢. so applications need to negotiate a suitable congestion control feedback interval at session setup time 🤝, based on the congestion control algorithm they picked, the expected media bitrate, and how much feedback overhead they can handle 🧮.

5. Response to Loss of Feedback Packets 💅

okay so, like all RTCP packets, RTCP Congestion Control Feedback Packets might get lost 😬. every RTP congestion control algorithm MUST specify how it responds to the loss of feedback packets 📋.

here's the tricky part: RTCP packets don't have a sequence number, so you have to infer loss from how long it's been since the last feedback packet ⏳. if only one congestion control feedback packet is lost, a sensible response is to assume congestion stayed roughly the same as in the previous report 😌. but if multiple consecutive feedback packets are lost, the media sender SHOULD rapidly reduce its sending rate 📉, because that most likely means a path failure 🚧. the RTP circuit breaker specification [RFC8083] gives more guidance on this 🔌✨.

Part 2 of 4 done, bestie! 🦋

6. SDP Signaling ✨

okay so this section is all about how two peers agree on using this feedback in SDP 🎀 A new ack feedback parameter, ccfb, gets defined for the a=rtcp-fb: SDP extension. It's what says "hey, we're using the RTP Congestion Control Feedback Packet format from Section 3." The ABNF [RFC5234] for this parameter extension is:

rtcp-fb-ack-param = <See Section 4.2 of [RFC4585]>
rtcp-fb-ack-param =/ ccfb-par
ccfb-par          = SP "ccfb"

The payload type used with ccfb feedback MUST be the wildcard type (*) 💜 This means the congestion control feedback goes out for every payload type in the session, including any Forward Error Correction (FEC) and retransmission payload types. So no payload type gets left out, bestie 🫶 Here's what the SDP attribute ends up looking like:

a=rtcp-fb:* ack ccfb

The offer/answer rules for these SDP feedback parameters live in Section 4.2 of the RTP/AVPF profile [RFC4585] 📖

Now here's the drama 🍿 An SDP offer might say it supports this congestion control feedback mechanism AND one or more other congestion control feedback mechanisms that basically do the same job. In that case, the answering party SHOULD include only one of the offered congestion control feedback mechanisms in its answer, so no double-dipping. If a later offer comes in with the same set of congestion control feedback mechanisms, the generated answer SHOULD choose the same mechanism as the original answer wherever that's possible. Consistency is everything 💅

When the SDP BUNDLE extension [RFC8843] is used for multiplexing, the a=rtcp-fb: attribute has multiplexing category IDENTICAL-PER-PT [RFC8859] ✨

7. Relationship to RFC 6679 🦋

okay so ECN with RTP is covered in [RFC6679], and that spec explains how to negotiate ECN with RTP. It also defines an RTCP ECN Feedback Packet to carry ECN feedback reports. To negotiate ECN, it uses the SDP a=ecn-capable-rtp: attribute. To negotiate the RTCP ECN Feedback Packets, it uses the a=rtcp-fb: attribute with the nack parameter ecn 🌸

Here's the tea 🫖 The RTCP ECN Feedback Packet is NOT useful when ECN is used with the RTP Congestion Control Feedback Packet from this memo, because it gives you duplicate info. So when congestion control feedback is being used with RTP and ECN, the SDP offer generated MUST include an a=ecn-capable-rtp: attribute to negotiate ECN support. It also MUST include an a=rtcp-fb: attribute with the ack parameter ccfb, to say the RTP Congestion Control Feedback Packet can be used. The a=rtcp-fb: attribute MAY also include the nack parameter ecn, to show the RTCP ECN Feedback Packet is supported too. And if an SDP offer signals support for BOTH the RTP Congestion Control Feedback Packets and the RTCP ECN Feedback Packet, the answering party SHOULD signal support for only one of those formats in its SDP answer. That way you don't send duplicate feedback 🙈

When using ECN with RTP, the guidelines in Section 7.2 of [RFC6679] MUST be followed to start using ECN in an RTP session. The guidelines in Section 7.3 of [RFC6679] about ongoing ECN use inside an RTP session MUST also be followed, with one exception: feedback goes out using the RTCP Congestion Control Feedback Packets from this memo instead of RTP ECN Feedback Packets. Same deal for Section 7.4 of [RFC6679], which is about detecting failures. That MUST be followed too, except the needed info comes from the RTCP Congestion Control Feedback Packets rather than RTP ECN Feedback Packets 🔥

8. Design Rationale 🧠

okay so the main job of RTCP SR/RR packets is reporting stats on how RTP packets were received 📊 Their reception report blocks carry observed jitter, fractional packet loss, and cumulative packet loss. The original plan was that this info could power congestion control, but experience showed it's NOT enough for that 😭 An efficient congestion control algorithm needs finer-grained, per-packet reception quality info to react well, and that's exactly what the feedback format in this memo gives you ✨

Several other RTCP extensions also give more detailed feedback than SR/RR packets, so let's check them out 👀

  • TMMBR: The codec control messages for the RTP/AVPF profile [RFC5104] include a Temporary Maximum Media Stream Bit Rate Request (TMMBR) message. It conveys a temporary maximum bitrate limit from a receiver of RTP packets back to their sender. TMMBR was never meant to replace congestion control, but it's been used for receiver-based congestion control when the session bandwidth is high enough to send TMMBR messages often, especially with non-compound RTCP packets [RFC5506]. That approach makes the receiver watch its reception, figure out the level of congestion, and recommend a maximum bitrate that suits the currently available bandwidth on the path. It also assumes the RTP sender can and will respect that bitrate. This is the OPPOSITE of the sender-based congestion control approach suggested in this memo, so TMMBR can't convey the info needed for sender-based congestion control. Still, TMMBR could be seen as a complementary mechanism that tells the sender the receiver's current view of an acceptable maximum bitrate. Mechanisms that convey the receiver's estimate of the maximum available bitrate give similar feedback 🌈
  • RTCP Extended Reports (XRs): Lots of RTCP XR blocks have been defined to report details on packet loss, arrival times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. You CAN stack several XR blocks into one compound RTCP packet to get the detailed loss, arrival time, and ECN marking info needed for good sender-based congestion control. The catch? The result has high overhead in both bandwidth and complexity, because you have to stack multiple reports 🫠
  • Transport-wide Congestion Control: The format in this memo gives individual feedback on each SSRC. The alternative is to add a header extension to each RTP packet, containing a single, transport-wide, packet sequence number. Then the receiver sends RTCP reports giving feedback on those extra sequence numbers [RTP-Ext-for-CC]. This makes each RTP packet 8 octets bigger because of the header extension, but it shrinks the RTCP feedback packets, and it can simplify the rate calculation at the sender if the sender keeps one rate limit that applies to ALL RTP packets, regardless of SSRC. On the flip side, transport-wide feedback makes it harder to adapt the sending rate or respond to lost packets based on per-SSRC reception and loss patterns. For example, you can't do differential rate control and repair for audio and video flows if you don't know which packets from each flow got lost. Transport-wide feedback is also less of a natural fit with the wider RTP framework, which leans heavily on per-SSRC sequence numbers and feedback 💜

Considering all this, the authors believe it's appropriate to design a NEW RTCP feedback mechanism to convey info for sender-based congestion control algorithms. The new congestion control feedback RTCP packet described in Section 3 is that mechanism 🎀

9. IANA Considerations 📋

The IANA registered one new RTP/AVPF Transport-Layer Feedback Message in the "FMT Values for RTPFB Payload Types" table [RFC4585], as defined in Section 3.1:

Name:         CCFB
Long name:    RTP Congestion Control Feedback
Value:        11
Reference:    RFC 8888

The IANA also registered one new SDP rtcp-fb attribute ack parameter, ccfb, in the SDP '"ack" and "nack" Attribute Values' registry:

Value name:   ccfb
Long name:    Congestion Control Feedback
Usable with:  ack
Mux:          IDENTICAL-PER-PT
Reference:    RFC 8888

10. Security Considerations 🔐

Let's get serious for a sec 🥺 The security considerations of the RTP specification [RFC3550], the applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), and the RTP congestion control algorithm being used (e.g., [RFC8698], [RFC8298], [Google-GCC], or [RFC8382]) all apply.

A receiver that intentionally generates inaccurate RTCP congestion control feedback reports might be able to trick the sender into sending at a greater rate than the path can support. That causes congestion on the path. This scenario hurts the quality of experience for that receiver, and it can cause denial of service to other traffic sharing the path plus excessively increased resource usage at the media sender. Since RTP is an unreliable transport, a sender can intentionally drop a packet, leaving a gap in the RTP sequence number space without causing serious harm. Why? To check that the receiver is correctly reporting losses. (This needs to be done with care and some awareness of the media data being sent, to limit impact on the user experience.) 🙃

An on-path attacker that can modify RTCP Congestion Control Feedback Packets can change the reports to trick the sender into sending at either an excessively high or excessively low rate, leading to denial of service. The secure RTCP profile [RFC3711] can be used to authenticate RTCP packets to protect against this attack. 🚨

An off-path attacker that can spoof RTCP Congestion Control Feedback Packets can similarly trick a sender into sending at an incorrect rate, leading to denial of service. This attack is difficult, since the attacker needs to guess the SSRC and sequence number in addition to the destination transport address. As with on-path attacks, the secure RTCP profile [RFC3711] can be used to authenticate RTCP packets to protect against this attack. 🛡️

11. References 📚

11.1. Normative References

okay bestie, these are the must-read sources the spec leans on so you can't skip them 📚💅

11.2. Informative References

these ones are the extra reading for the curious 🤓🌸 they give background and context, they're not required to get the spec

Acknowledgements 🫶

this doc came out of a design team chat in the RTP Media Congestion Avoidance Techniques (RMCAT) Working Group 💖 the authors wanna give a huge thank you to David Hayes, Stefan Holmer, Randell Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable feedback. the girls who helped make it better, iconic behaviour 👑✨

Authors' Addresses 💌

Zaheduzzaman Sarker

Ericsson AB
Torshamnsgatan 23
SE-164 83 Stockholm
Sweden

Phone: +46 10 717 37 43
Email: zaheduzzaman.sarker@ericsson.com

Colin Perkins

University of Glasgow
School of Computing Science
Glasgow
G12 8QQ
United Kingdom

Email: csp@csperkins.org

Varun Singh

CALLSTATS I/O Oy
Annankatu 31-33 C 42
FI-00100 Helsinki
Finland

Email: varun.singh@iki.fi
URI:   https://www.callstats.io/

Michael A. Ramalho

AcousticComms Consulting
6310 Watercrest Way Unit 203
Lakewood Ranch, FL 34202-5122
United States of America

Phone: +1 732 832 9723
Email: mar42@cornell.edu
URI:   http://ramalho.webhop.info/

and that's the whole spec, bestie 🌈🦋 we did it!! 🧚

📦 where this page comes from