RFC 5761

Multiplexing RTP Data and Control Packets on a Single Port

📅 published April 2010, from ietf

Multiplexing RTP Data and Control Packets on a Single Port 🎀

RFC 5761 ✨ is an IETF Standards Track document from April 2010 (ISSN 2070-1721), written by C. Perkins (University of Glasgow) and M. Westerlund (Ericsson). It's a total main character doc because it updates two older RFCs:

Okay bestie, this one is all about running RTP data and RTCP control packets on one single UDP port 🧚, instead of splitting them across two. 💅

Abstract

So the abstract is basically the tea ☕: this memo talks about the issues that pop up when you squish RTP data packets and RTP Control Protocol (RTCP) packets onto one UDP port. It updates RFC 3550 and RFC 3551 to say when that kind of multiplexing is cool and when it totally isn't 🙅‍♀️, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions 📡.

Status of This Memo

This is an Internet Standards Track document. 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 💜

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5761. 🔥

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🫶

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 📜

Table of Contents

1. Introduction ....................................................3
2. Background ......................................................3
3. Terminology .....................................................4
4. Distinguishable RTP and RTCP Packets ............................4
5. Multiplexing RTP and RTCP on a Single Port ......................6
   5.1. Unicast Sessions ...........................................6
        5.1.1. SDP Signalling ......................................6
        5.1.2. Interactions with SIP Forking .......................7
        5.1.3. Interactions with ICE ...............................7
        5.1.4. Interactions with Header Compression ................8
   5.2. Any Source Multicast Sessions ..............................9
   5.3. Source-Specific Multicast Sessions .........................9
6. Multiplexing, Bandwidth, and Quality of Service ................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
   10.1. Normative References .....................................11
   10.2. Informative References ...................................12

1. Introduction ✨

Okay so, the Real-time Transport Protocol (RTP) [1] has two parts: a data transfer protocol and an associated control protocol called RTCP. Historically, RTP and RTCP have each been run on their own separate UDP ports. 🎀 Now that Network Address Port Translation (NAPT) [14] is everywhere 🌍, that setup has become a real problem, because keeping track of multiple NAT bindings can be costly 💸. It also makes firewall admin messier, since you have to open multiple ports just to let RTP traffic through 🙃.

So this memo looks at how the RTP and RTCP flows for a single media type can share one port. The goal is easier NAT traversal and simpler firewall admin, and it also covers when this kind of multiplexing is actually appropriate 🦋. Multiplexing several types of media (like audio and video) onto a single port is not covered here, but check out Section 5.2 of [1] if you want that tea 🍵.

This memo is structured as follows 🗺️: Section 2 talks about the design choices that led to using separate ports and how well those choices still fit today's networks. Section 3 covers terminology, and Section 4 covers how to tell multiplexed packets apart. Then Section 5 is where the real stuff lives: when and how RTP and RTCP should be multiplexed, and how to signal multiplexed sessions. Section 6 covers quality of service and bandwidth, and we wrap up with security considerations in Section 7 and IANA considerations in Section 8 💅.

This memo updates Section 11 of [1]. 👑

2. Background 🌷

An RTP session is made up of data packets and periodic control (RTCP) packets. RTCP packets are assumed to use "the same distribution mechanism as the data packets", and the "underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP" [1]. So multiplexing was handed off to the underlying transport protocol instead of being built into RTP itself, for three main reasons 🧠:

  1. Simplicity 🧸: An RTP implementation gets simpler when RTP and RTCP demultiplexing moves down to the transport layer, since the implementation doesn't need to worry about separating data and control packets. That lets the implementation be structured in a very natural way, with a clean separation of data and control planes.
  2. Efficiency ⚡: Following the principle of integrated layer processing [15], an implementation runs more efficiently when demultiplexing happens in one place (for example, by UDP port) than when it's split across multiple layers of the stack (for example, by UDP port and then by packet type).
  3. To enable third-party monitors 👀: Unicast voice-over-IP has always been part of the picture, but RTP was also designed to support loosely coupled multicast conferences [16] and very large-scale multicast streaming media applications, like the so-called triple-play IP television (IPTV) service 📺. So the design of RTP lets RTCP packets be multicast using a separate IP multicast group and UDP port from the data packets. This doesn't just let session participants get reception-quality feedback. It also enables third-party monitors that listen to reception quality without ever touching the data packets 🕵️‍♀️. The idea was to give multicast sessions manageability without giving up privacy 🔐.

While these design choices are a great fit for many uses of RTP, they cause problems in some cases 😬. A lot of RTP deployments don't use IP multicast, and with Network Address Translation (NAT) getting more common, the simplicity of multiplexing at the transport layer has turned into a liability, since it requires complex signalling to open multiple NAT pinholes 🥲. In environments like these, it's desirable to have an alternative to demultiplexing RTP and RTCP using separate UDP ports. Instead, you use just a single UDP port and demultiplex inside the application 💖.

This memo provides that alternative by multiplexing RTP and RTCP packets on a single UDP port, distinguished by the RTP payload type and RTCP packet type values. Yes, it pushes some extra work onto the RTP implementation, but in exchange you get simpler NAT traversal. Worth it, honestly 💅✨.

3. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 🫶

4. Distinguishable RTP and RTCP Packets 🦋

When RTP and RTCP packets are multiplexed onto a single port, the RTCP packet type field sits in the same position in the packet as the combination of the RTP marker (M) bit and the RTP payload type (PT). 🎯 That field can tell RTP and RTCP packets apart, but only if two restrictions are followed:

  1. The RTP payload type values used are distinct from the RTCP packet types used.
  2. For each RTP payload type (PT), PT+128 is distinct from the RTCP packet types used.

The first constraint blocks a direct conflict between an RTP payload type and an RTCP packet type. The second constraint blocks a conflict between an RTP data packet with the marker bit set and an RTCP packet. 🙌

These are the conflicts between RTP and RTCP packet types that are known so far 🚨:

  • RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and NACK packets defined in the original "RTP Payload Format for H.261 Video Streams" [3] (which was obsoleted by [17]).
  • RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE, and APP packets defined in the RTP specification [1].
  • RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB packets defined in the RTP/AVPF profile [4].
  • RTP payload type 79 conflicts with RTCP Extended Report (XR) [5] packets.
  • RTP payload type 80 conflicts with Receiver Summary Information (RSI) packets defined in "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [6].

New RTCP packet types may get registered in the future, and that will shrink the pool of RTP payload types that are still available when you multiplex RTP and RTCP onto a single port 😩. To keep this multiplexing working, future RTCP packet type assignments SHOULD be made after the current assignments in the range 209-223, then in the range 194-199, so that only the RTP payload types in the range 64-95 are blocked. RTCP packet types in the ranges 1-191 and 224-254 SHOULD only be used when other values have been exhausted. 🧩

Given all these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for choosing RTP payload type values, with the additional restriction that payload type values in the range 64-95 MUST NOT be used. 🚫 Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. 🌈 Values below 64 MAY be used if that isn't enough, and in that case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first. 💜

Note: Since Section 6.1 of [1] specifies that all RTCP packets MUST be sent as compound packets beginning with a Sender Report (SR) or a Receiver Report (RR) packet, one might wonder why RTP payload types other than 72 and 73 are prohibited when multiplexing RTP and RTCP. This is done to support [18], which allows the use of non-compound RTCP packets in some circumstances. 🙈

5. Multiplexing RTP and RTCP on a Single Port 🦋

okay so how you multiplex RTP and RTCP on one port depends on whether the session is unicast or multicast 💅 and if it's multicast, it also depends on whether it's Any Source Multicast (ASM) or Source-Specific Multicast (SSM) 🌸

5.1. Unicast Sessions

it's totally fine to squish RTP and RTCP packets onto a single UDP port to make NAT traversal easier for unicast sessions ✨ as long as the RTP payload types in the session follow the rules in Section 4, AND multiplexing gets signalled ahead of time 🫶 the next bits show how these multiplexed sessions can be signalled with the Session Initiation Protocol (SIP) using the offer/answer model 💜

5.1.1. SDP Signalling

when the Session Description Protocol (SDP) [8] is used to negotiate RTP sessions under the offer/answer model [9], the a=rtcp-mux attribute (see Section 8) basically says "hey, I'd love to multiplex RTP and RTCP onto one port" 🎀 the initial SDP offer MUST include this attribute at the media level to request multiplexing of RTP and RTCP on a single port. here's an example:

v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux

this offer is a unicast voice-over-IP session using the RTP/AVP profile with iLBC coding 🌈 the answerer is asked to send both RTP and RTCP to port 49170 on the IPv6 address 2001:DB8::211:24ff:fea3:7a2e.

if the answerer wants to multiplex RTP and RTCP onto a single port, it MUST include a media-level a=rtcp-mux attribute in the answer. the RTP payload types used in the answer MUST conform to the rules in Section 4 🍓

if the answer doesn't contain an a=rtcp-mux attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port 🙈 instead, it should send and receive RTCP on a port allocated under the usual port-selection rules (either the port pair, or a signalled port if the a=rtcp: attribute [10] is also included). this happens when you're talking to a peer that doesn't understand the a=rtcp-mux attribute.

when SDP is used declaratively, the presence of an a=rtcp-mux attribute means the sender will multiplex RTP and RTCP on the same port. the receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to include the RTCP bandwidth 💅

5.1.2. Interactions with SIP Forking

when you use SIP with a forking proxy, one INVITE request might get multiple 200 (OK) responses 😭 if RTP and RTCP multiplexing is offered in that INVITE, it's important to know that some answerers may support multiplexed RTP and RTCP, and some won't. this means the offerer has to listen for RTCP on both the RTP port and the usual RTCP port, and send RTCP on both ports, unless the branches of the call that support multiplexing get re-negotiated to use separate RTP and RTCP ports 🔥

5.1.3. Interactions with ICE

it's pretty common to use the Interactive Connectivity Establishment (ICE) [19] methodology to set up RTP sessions when Network Address Translation (NAT) devices or other middleboxes are involved ✨ if RTP and RTCP go on separate ports, the RTP media stream has two components in ICE (one for RTP and one for RTCP), with connectivity checks done for each component. if RTP and RTCP are multiplexed on the same port, some of these connectivity checks can be skipped, which cuts down on ICE overhead 🦋

if you want both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an a=rtcp-mux attribute to show that RTP and RTCP multiplexing is wanted, and MUST contain a=candidate: lines for both RTP and RTCP, along with an a=rtcp: line that gives a fallback port for RTCP in case the answerer doesn't support RTP and RTCP multiplexing. this MUST be done for each media where RTP and RTCP multiplexing is wanted 💖

if the answerer wants to multiplex RTP and RTCP on a single port, it MUST generate an answer containing an a=rtcp-mux attribute and a single a=candidate: line for the RTP port (so no candidate for RTCP) for each media where it wants RTP and RTCP multiplexing. the answerer then does connectivity checks for that media as if the offer had only one candidate for RTP 🧚 if the answerer doesn't want to multiplex RTP and RTCP on a single port, it MUST NOT include the a=rtcp-mux attribute in its answer, and it MUST perform connectivity checks for all offered candidates in the usual way.

when the offerer gets the answer, it looks for the a=rtcp-mux line for each media where multiplexing was offered. if it's there, connectivity checks go ahead as if only a single candidate (for RTP) was offered, and multiplexing gets used once the session is up 🌸 if the a=rtcp-mux line isn't there, the session continues with connectivity checks using both RTP and RTCP candidates, and eventually a session is established with RTP and RTCP on separate ports (as signalled by the a=rtcp: attribute).

5.1.4. Interactions with Header Compression

multiplexing RTP and RTCP packets onto a single port can hurt header compression schemes, like Compressed RTP (CRTP) [20] and RObust Header Compression (ROHC) [21] [22] 💀 header compression works by spotting patterns of change in the RTP headers of consecutive packets, so it can send a little note saying "this packet changed the expected way" instead of the full header every time. that can save a ton of bandwidth if flows behave uniformly 🍓

the RTCP packets mixed in with the RTP data packets can mess up those patterns of change, and that can seriously reduce header compression efficiency 😭 how much it messes things up depends on the header compression algorithm and on how flows get classified. a well-designed classifier should be able to split RTP and RTCP multiplexed on the same port into different compression contexts, using the payload type field, so the effect on the compression ratio stays small. a classifier that only assigns compression contexts based on IP addresses and UDP ports won't perform well 🙅‍♀️ implementations of header compression will probably need updates to support RTP and RTCP multiplexed on the same port efficiently.

this effect can be especially big in places, like some wireless telephony systems, that count on header compression to squeeze media into a limited-capacity channel 🥺 think carefully about the implications of multiplexing RTP and RTCP before using it in those environments.

5.2. Any Source Multicast Sessions

NAT traversal is less of a problem for Any Source Multicast (ASM) RTP sessions than for unicast RTP sessions, and the benefit of using separate ports for RTP and RTCP is bigger because it lets third-party RTCP-only monitors work 👑 so RTP and RTCP packets SHOULD NOT be multiplexed onto a single port when using ASM RTP sessions, and they SHOULD instead use separate ports and multicast groups ✨

5.3. Source-Specific Multicast Sessions

RTP sessions running over Source-Specific Multicast (SSM) send RTCP packets from the source to receivers over the multicast channel, but they use a separate unicast feedback mechanism [6] to send RTCP from the receivers back to the source. the source either reflects the RTCP packets to the group or sends aggregate summary reports 🧚

following the terminology of [6], we spot three RTP/RTCP flows in an SSM session 🦋

  1. RTP and RTCP flows between the media sender and the distribution source. in lots of scenarios, the media sender and distribution source are in the same place, so multiplexing isn't a concern 🌈 if they're connected by a unicast connection, the rules in Section 5.1 of this memo apply to that connection. if they're connected by an Any Source Multicast connection, the rules in Section 5.2 apply. if they're connected by a Source-Specific Multicast connection, the RTP and RTCP packets MAY be multiplexed on a single port, as long as this is signalled (using a=rtcp-mux if using SDP) 💜
  2. RTP and RTCP sent from the distribution source to the receivers. the distribution source MAY multiplex RTP and RTCP onto a single port to ease NAT traversal issues on the forward SSM path, though doing so may get in the way of third-party monitoring devices if the session uses the simple feedback model 🫶 when using SDP, the multiplexing SHOULD be signalled using the a=rtcp-mux attribute.
  3. RTCP sent from receivers to the distribution source. this is an RTCP-only path, so multiplexing isn't a concern 🎀

multiplexing RTP and RTCP packets on a single port in an SSM session has the potential to interact with header compression, as described in Section 5.1.4 🌸

6. Multiplexing, Bandwidth, and Quality of Service 👑

multiplexing RTP and RTCP has implications for the Quality of Service (QoS) mechanism that handles flows determined by a three or five tuple (protocol, port, and address for source and/or destination) 💅 when they're multiplexed, the RTCP flow gets merged with the RTP flow, so the RTCP bandwidth requirement needs to be considered when making QoS reservations for the combined RTP and RTCP flow. still, from an RTCP perspective it's great to get the same treatment for RTCP packets as for RTP, since that gives more accurate statistics for the measurements RTCP does ✨

the bandwidth a multiplexed stream needs is the session bandwidth of the RTP stream plus the bandwidth used by RTCP 🧮 in the usual case, the RTP session bandwidth is signalled in the SDP b=AS: line (or b=TIAS: [11]), and RTCP traffic is capped at 5% of that value. so any QoS reservation SHOULD be made for 105% of the b=AS: value 🦋 if a non-standard RTCP bandwidth fraction is used, signalled by the SDP b=RR: and/or b=RS: lines [12], then any QoS reservation SHOULD be made for bandwidth equal to (AS + RS + RR), taking the RS and RR values from the SDP answer 🥹

7. Security Considerations 🔐

okay bestie, security time, and this part is lowkey serious 🫶 Multiplexing RTP and RTCP is not believed to bring in any new security considerations ✨ The big known issues are the integrity and authentication of the signalling used to set up the multiplexing, plus the integrity, authentication, and confidentiality of the actual RTP and RTCP traffic 🔥 The security considerations in the RTP specification [1], any applicable RTP profile (for example [7]), and the payload format(s) all still apply 💅

If you're using the Secure Real-time Transport Protocol (SRTP) [13] together with multiplexed RTP and RTCP, then multiplexing MUST be done below the SRTP layer 🎀 Here's how it goes: the sender makes SRTP and SRTCP packets the usual way, using their separate cryptographic contexts, and then multiplexes them onto a single port right before they're sent 🦋 On the receiving end, the cryptographic context is derived from the synchronization source (SSRC), the destination network address, and the destination transport port number, the usual way, but augmented with the RTP payload type and RTCP packet type so SRTP and SRTCP can be demultiplexed according to the rules in Section 4 of this memo 🧚 Once they've been demultiplexed, the cryptographic processing happens the usual way ✨

8. IANA Considerations 📋

Following the guidelines in [8], IANA has registered one new SDP attribute 💖

  • Contact name/email: authors of RFC 5761
  • Attribute name: rtcp-mux
  • Long-form attribute name: RTP and RTCP multiplexed on one port
  • Type of attribute: media level
  • Subject to charset: no

This attribute is used to signal that RTP and RTCP traffic should be multiplexed on a single port (see Section 5 of this memo) 🌸 It's a property attribute, so it doesn't take a value 🍓

The rules for assigning RTP RTCP Control Packet Types in the RTP Parameters registry got an update too 👑 When assigning RTP RTCP Control Packet types, IANA is requested to assign unused values from the range 200-223 where possible 🦋 If that range is fully occupied, values from the range 194-199 may be used, and then values from the ranges 1-191 and 224-254 🫶 The point of all this is better header validity checking: RTCP packets get checked more reliably against RTP packets or other unrelated packets 🔥 The values 0 and 255 are avoided too, since all-zeros and all-ones are common values, so checking against random packets is better that way 💀

9. Acknowledgements 🫶

Big thank-yous to Steve Casner, Joerg Ott, Christer Holmberg, Gunnar Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson, Dave Singer, Kevin Johns, and David Black for their comments on this memo 💜 This work was supported in part by the UK Engineering and Physical Sciences Research Council 🌈

10. References 📚

10.1. Normative References

[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3] Turletti, T., "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.

[4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.

[5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.

[6] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.

[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.

[11] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.

[12] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.

[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

10.2. Informative References

[14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

[15] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings of ACM SIGCOMM 1990, September 1990.

[16] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM SIGCOMM Computer Communication Review, Volume 22, Number 3, July 1992.

[17] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006.

[18] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.

[19] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.

[20] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.

[21] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.

[22] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.

Authors' Addresses 🦋

Colin Perkins
University of Glasgow
Department of Computing Science
Glasgow  G12 8QQ
UK

EMail: csp@csperkins.org


Magnus Westerlund
Ericsson
Farogatan 6
Stockholm  SE-164 80
Sweden

EMail: magnus.westerlund@ericsson.com
📦 where this page comes from