draft-ietf-avt-ports-for-ucast-mcast-rtp-02.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-03.txt 
AVT A. Begen AVT A. Begen
Internet-Draft B. VerSteeg Internet-Draft D. Wing
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: November 20, 2010 May 19, 2010 Expires: May 22, 2011 T. VanCaenegem
Alcatel-Lucent
November 18, 2010
Port Mapping Between Unicast and Multicast RTP Sessions Token-Based Port Mapping Between Unicast and Multicast RTP Sessions
draft-ietf-avt-ports-for-ucast-mcast-rtp-02 draft-ietf-avt-ports-for-ucast-mcast-rtp-03
Abstract Abstract
This document presents a port mapping solution that allows RTP This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services. The in RTP applications using both unicast and multicast services
solution requires multiplexing RTP and RTCP on a single port on both (almost) without the need for retrieving pre-authorization.
endpoints in the unicast session.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 20, 2010. This Internet-Draft will expire on May 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6
3.1. Steps for Establishing a Unicast Session . . . . . . . . . 8 3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 6
3.2. Implications of NATs . . . . . . . . . . . . . . . . . . . 9 3.2. Unicast Session Establishment . . . . . . . . . . . . . . 6
3.3. Message Flows . . . . . . . . . . . . . . . . . . . . . . 10 4. The portmapping-req Attribute . . . . . . . . . . . . . . . . 11
3.4. Keeping the NAT Binding(s) Alive . . . . . . . . . . . . . 12 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. SDP Description . . . . . . . . . . . . . . . . . . . . . 12 5.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 13
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13
4.1. PortMappingRequest (PMReq) . . . . . . . . . . . . . . . . 14 5.3. Token Verification . . . . . . . . . . . . . . . . . . . . 14
4.2. PortMappingResponse (PMRes) . . . . . . . . . . . . . . . 15 6. Procedures for Token Construction . . . . . . . . . . . . . . 15
5. Procedures for Cookie Construction . . . . . . . . . . . . . . 16 7. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 19
7.1. Registration of FMT Values . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Contributors and Acknowledgments . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.2. Registration of FMT Values . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 11.3. SFMT Values for Port Mapping Messages Registry . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 11.4. RAMS Response Code Space Registry . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
In (any-source or source-specific) multicast RTP applications, In (any-source or source-specific) multicast RTP applications,
destination ports, i.e., the ports on which the multicast receivers destination ports, i.e., the ports on which the multicast receivers
receive the RTP and RTCP packets, are defined declaratively. In receive the RTP and RTCP packets, are defined declaratively. In
other words, the receivers cannot choose their receive ports and the other words, the receivers cannot choose their receive ports and the
sender(s) use the pre-defined ports. sender(s) use the pre-defined ports.
In unicast RTP applications, the receiving end needs to choose its In unicast RTP applications, the receiving end needs to choose its
skipping to change at page 6, line 5 skipping to change at page 6, line 5
In the remainder of this document, we refer to the RTP endpoints that In the remainder of this document, we refer to the RTP endpoints that
serve other RTP endpoints over a unicast session as the Servers. The serve other RTP endpoints over a unicast session as the Servers. The
receiving RTP endpoints are referred to as Clients. receiving RTP endpoints are referred to as Clients.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Port Mapping 3. Token-Based Port Mapping
We present the details of the port mapping solution in the context of Token-based Port Mapping consists of two steps: (i) Token request
an illustrative example. and retrieval, and (ii) unicast session establishment. These are
described below.
Consider an SSM distribution network where a distribution source 3.1. Token Request and Retrieval
multicasts RTP packets to a large number of clients, and one or more
retransmission servers function as feedback targets to collect This first step is required to be completed only once. Once a Token
unicast RTCP feedback from these clients [RFC5760]. The is retrieved from a particular server, it can be used for all the
retransmission servers also join the primary multicast session to unicast sessions the client will be running with this particular
receive the multicast packets and cache them for a certain time server. By default, Tokens are server specific. However, the client
period. When a client detects missing packets in the primary can use the same Token to communicate with different servers if these
multicast session, it requests a retransmission from one of the servers are provided with the same key used to generate the Token.
The Token becomes invalid if client's public IP address changes or
when the server expires the Token. In these cases, the client has to
request a new Token.
The Token is essentially an opaque encapsulation that conveys
client's IP address information (as seen by the server) using a
reversible transform only known to the server. When a request is
received, the server creates a Token for this particular client, and
sends it back to the client. Later, when the client wants to
establish a unicast session, the Token will be validated by the
server, making sure that the IP address information matches. This is
effective against DoS attacks, e.g., an attacker cannot simply spoof
another client's IP address and start a unicast transmission towards
random clients.
3.2. Unicast Session Establishment
We illustrate the second step with an example. Consider an SSM
distribution network where a distribution source multicasts RTP
packets to a large number of clients, and one or more retransmission
servers function as feedback targets to collect unicast RTCP feedback
from these clients [RFC5760]. The retransmission servers also join
the multicast session to receive the multicast packets and cache them
for a certain time period. When a client detects missing packets in
the multicast session, it requests a retransmission from one of the
retransmission servers by using an RTCP NACK message [RFC4585]. The retransmission servers by using an RTCP NACK message [RFC4585]. The
retransmission server pulls the requested packet(s) out of the cache retransmission server pulls the requested packet(s) out of the cache
and retransmits them to the requesting client. and retransmits them to the requesting client [RFC4588].
The pertaining RTP and RTCP flows are sketched in Figure 2. Between The pertaining RTP and RTCP flows are sketched in Figure 2. Between
the client and server, there may be one or more NAT devices the client and server, there can be one or more Network Address Port
[RFC4787]. Translators (NAPT - hereafter simply called NAT) devices [RFC4787].
-------------- --- ---------- -------------- --- ----------
| |-------------------------------| |-->|P1 | | |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | | | | | | | |
| Distribution | ---------------- | | | | | Distribution | ---------------- | | | |
| Source | | | | | | | | Source | | | | | | |
| |---->|P1 | | | | | | |---->|P1 | | | | |
| |.-.->|P2 | | | | | | |.-.->|P2 | | | | |
| | | | | | | | | | | | | | | |
-------------- | P3|<.=.=.=.| |=.=|*c1 | -------------- | P3|<.=.=.=.| |=.=|*c0 |
| P3|<~~~~~~~| |~~~|*c1 | | P3|<~~~~~~~| |~~~|*c1 |
PRIMARY MULTICAST | | | | | | MULTICAST RTP | | | | | |
RTP SESSION with | | | | | | SESSION with | | | | | |
UNICAST FEEDBACK | | | N | | | UNICAST FEEDBACK | | | N | | |
| Retransmission | | A | | Client | | Retransmission | | A | | Client |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| Server | | T | | | | Server | | T | | |
| | | | | |
PORT MAPPING | PT|<~~~~~~~| |~~>|*cT |
| | | | | |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| | | | | |
AUXILIARY UNICAST | | | | | | AUXILIARY UNICAST | | | | | |
RTP SESSION | P4|<~~~~~~~| |~~>|*c2 | RTP SESSION | | | | | |
| P4|........| |..>|*c2 | | P3|........| |..>|*c1 |
| P4|<.=.=.=.| |=.>|*c2 | | P3|=.=.=.=.| |=.>|*c1 |
| P4|<.=.=.=.| |=.=|*c2 |
| | | | | | | | | | | |
---------------- --- ---------- ---------------- --- ----------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages (if any) ~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 2: Example scenario showing an SSM distribution with support Figure 2: Example scenario showing an SSM distribution with support
for retransmissions from a server for retransmissions from a server
In this figure, we have the following multicast and unicast ports: In this figure, we have the following multicast and unicast ports:
o Ports P1 and P2 denote the destination RTP and RTCP ports in the o Ports P1 and P2 denote the destination RTP and RTCP ports in the
primary multicast session, respectively. The clients listen to multicast session, respectively. The clients listen to these
these ports to receive the multicast RTP and RTCP packets. Ports ports to receive the multicast RTP and RTCP packets. Ports P1 and
P1 and P2 are defined declaratively. P2 are defined declaratively.
o Port P3 denotes the RTCP port on the feedback target running on o Port P3 denotes the RTCP port on the feedback target running on
the retransmission server to collect the RTCP feedback messages, the retransmission server to collect the RTCP feedback messages,
and RTCP receiver and extended reports from the clients in the and RTCP receiver and extended reports from the clients in the
primary multicast session. Port P3 is defined declaratively. multicast session. This is also the port that the retransmission
server uses to send the RTP packets and RTCP sender reports in the
unicast session. Port P3 is defined declaratively.
o Port P4 denotes the port on the retransmission server used for the o Port P4 denotes the RTCP port on the retransmission server used to
unicast session. The server multiplexes RTP and RTCP traffic on collect the RTCP receiver and extended reports for the unicast
this single port [RFC5761] in the unicast session. Port P4 is session. Port P4 is defined declaratively and MUST be different
defined declaratively and MUST be different from port P3. from port P3.
o Ports *c1 and *c2 are chosen by the client. *c1 denotes the port o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the
on the client used to send the unicast RTCP feedback in the port on the client used to send the RTCP reports for the multicast
primary multicast session. *c2 denotes the port on the client used session. *c1 denotes the port on the client used to send the
in the unicast session. The client multiplexes RTP and RTCP unicast RTCP feedback messages in the multicast session and to
traffic on this single port [RFC5761] in the unicast session. receive the RTP packets and RTCP sender reports in the unicast
Ports c1 and c2 do not have to be different ports. session. *c2 denotes the port on the client used to send the RTCP
receiver and extended reports in the unicast session. Ports c0,
c1 and c2 MAY be the same port or different ports. However, there
are two advantages of using the same port for both c0 and c1:
Once the unicast session is established, the server needs to remember 1. Some NATs only keep bindings active when a packet goes from
the public IP address and public port of the client as part of the the inside to the outside of the NAT (See REQ-6 of Section 4.3
session state information. The public ports of the client are of [RFC4787]). When the retransmission server sends unicast
denoted by c1' and c2'. packets for a long period of time, this can exceed that
timeout. If c0=c1, the occasional (periodic) RTCP receiver
reports sent from port c0 (for the multicast session) will
ensure the NAT does not time out the public port associated
with the incoming unicast traffic to port c1.
2. Having c0=c1 conserves NAT port bindings.
Thus, it is strongly RECOMMENDED that the client uses the same
port for c0 and c1.
o Ports PT and cT denote the ports through which the Token request
and retrieval occur at the server and client sides, respectively.
Port PT is declared on a per unicast session basis, although its
value MAY be the same for all unicast sessions sourced by the
server. This way, a Token once requested and retrieved by a
client from port PT remains valid across different unicast
sessions. Port PT MAY be equal to port P3. Port cT MAY also be
equal to ports c0 and c1.
In addition to the ports, we use the following notation: In addition to the ports, we use the following notation:
o DS: IP address of the distribution source o DS: IP address of the distribution source
o G: Destination multicast address o G: Destination multicast address
o S: IP address of the retransmission server o S: IP address of the retransmission server
o C: IP address of the client o C: IP address of the client
o C': Public IP address of the client (as seen by the server) o C': Public IP address of the client (as seen by the server)
We assume that the information declaratively defined is available as We assume that the information declaratively defined is available as
part of the session description information and is provided to the part of the session description information and is provided to the
clients. The Session Description Protocol (SDP) [RFC4566] and other clients. The Session Description Protocol (SDP) [RFC4566] and other
session description methods can be used for this purpose. session description methods can be used for this purpose.
3.1. Steps for Establishing a Unicast Session The following steps summarize the Token-based solution:
The steps to establish a unicast session are provided below:
1. The client ascertains server address (S) and port numbers (P3 and 1. The client ascertains server address (S) and port numbers (P3 and
P4) from the session description. P4) from the session description.
2. The client determines its port numbers (*c1 and *c2). 2. The client determines its port numbers (*c0, *c1 and *c2).
3. The client sends a message to the server via a new RTCP message,
called PortMappingRequest. This message MUST be sent from port
c2 to port P4. The server learns client's public IP address (C')
and its public RTP/RTCP port (c2') from the received message.
4. The server generates an opaque encapsulation (called Cookie) that
conveys client's addressing information using a reversible
transform only known to the server.
5. The server sends the Cookie back to the client using a new RTCP
message, called PortMappingResponse. This message MUST be sent
from port P4 to port c2'.
6. The client includes the Cookie when necessary in the subsequent 3. If the client does not have a valid Token:
messages sent to the server. Note that the unicast session is
not established during the steps required to retrieve a Cookie
from the server. The unicast session is only established after
the server has received a feedback message (along with a valid
Cookie) from the client for which it needs to react by sending
unicast data (See Figure 3). Until a unicast session is
established, neither the server nor the client needs to send RTCP
reports for the unicast session.
7. Normal flows ensue, with the server using the addressing A. The client first sends a message to the server via a new RTCP
encapsulated in the opaque Cookie. The client is responsible for message, called Port Mapping Request to port PT. This
keeping the NAT binding alive for the duration of the unicast message is sent from port cT on the client side. The server
session. learns client's public IP address (C') from the received
message. The client can send this message anytime it wants
(e.g., during initialization), and does not normally ever
need to re-send this message (See Section 7).
3.2. Implications of NATs B. The server generates an opaque encapsulation (i.e., the
Token) that conveys client's IP address information using a
reversible transform only known to the server. For details,
see Section 6.
There may be one or more NAT devices between the client and server. C. The server sends the Token back to the client using a new
Without an external mechanism such as STUN [RFC5389], the client RTCP message, called Port Mapping Response. This message
cannot determine whether there are any NATs between itself and the MUST be sent from port PT to port cT.
server. Such NAT devices would block all incoming traffic unless the
client sent traffic of the same transport protocol to the server
first. Thus, the client has always to assume that there is at least
one NAT device and send periodic packets to keep the NAT binding
alive [I-D.ietf-avt-app-rtp-keepalive]. Since the client multiplexes
RTP and RTCP on a single port, it has to keep a single NAT binding
alive for each unicast session. See Section 3.4 for further details.
If the NAT device fails for some reason and then restarts, the public 4. The client provides the Token to the server using a new RTCP
IP address and/or port assigned to a particular client may change. message, called Token Verification, whenever the client sends an
This will invalidate the previously acquired cookies and may result RTCP feedback message for triggering or controlling a unicast
in a failure in the unicast session. Upon detecting the failure, the session. Note that the unicast session is only established after
client must acquire new cookies. Applications using this method must the server has received a feedback message (along with a valid
be aware of the potential temporary interruptions. Token) from the client for which it needs to react by sending
unicast data. Until a unicast session is established, neither
the server nor the client needs to send RTCP reports for the
unicast session.
The NAT device may have endpoint-independent mappings [RFC4787], 5. Normal flows ensue as shown in Figure 2. Note that in the
meaning that it assigns the same public IP address and port for the unicast session the RTP and RTCP packets MUST be multiplexed on
packets sent from the same internal IP address and port, even when the (same) port c1. If the client uses the same port for both c0
the client is talking to different destinations. Oppositely, the NAT and c1, the RTCP reports sent for the multicast session keep the
device may have endpoint-dependent mappings in which case the public P3->c1(=c0) binding alive. If the client uses different ports
IP address and port of the outgoing packets may differ when they are for c0 and c1, the client needs to periodically send an explicit
sent to different destinations. In practice, however, it is a keep-alive message [I-D.ietf-avt-app-rtp-keepalive] to keep the
difficult task to determine the type of a NAT device P3->c1 binding alive during the lifetime of the unicast session
[I-D.ietf-behave-nat-behavior-discovery]. if the unicast session's lifetime is likely to exceed the NAT's
timeout value.
3.3. Message Flows 4. The portmapping-req Attribute
Figure 3 shows the message flows, where each message is appended with This new SDP attribute is used declaratively to indicate the port for
the (Source Address, Source Port, Destination Address, Destination obtaining a Token. Its presence indicates that a Token MUST be
Port) information. The optional messages are indicated in included in the feedback messages sent to the server triggering or
parentheses and they may or may not be present in certain scenarios. controlling a unicast session.
------------ ---------------- ------ The formal description of the 'portmapping-req' attribute is defined
|Distribution| | Retransmission | | | by the following ABNF [RFC5234] syntax:
| Source | | Server | |Client|
| (DS) | | (S) | | (C) |
------------ ---------------- ------
| | - |
| | | | |
(DS,*,G,P1)|--->|------- (RTP Multicast) -------->| |-->|
(DS,*,G,P2)|.-.>|.-.-.-. (RTCP Multicast) -.-.-.->| |-->|
| | | |
| | | |
|<=.= (RTCP Receiver Reports) .=.=| |<..|(C,c1,S,P3)
| (for the multicast session) | | |
: | | :
: | | :
: | | :
: | | :
|<~~~~~ PortMappingRequest ~~~~~~~| |<~~|(C,c2,S,P4)
| |N| |
(S,P4,C',c2')|~~~~~~ PortMappingResponse ~~~~~>|A|~~>|
| (Cookie) |T| |
| | | |
|<~~~~ RTCP NACK with Cookie ~~~~~| |<~~|(C,c1,S,P3)
| | | |
|*********************************|*|***|
|* UNICAST SESSION ESTABLISHED | | *|
|*********************************|*|***|
| | | |
(S,P4,C',c2')|...... RTP Retransmissions .....>| |..>|
| | | |
| | | |
|<=.=. RTCP Receiver Reports =.=.=| |<..|(C,c2,S,P4)
| (for the unicast session) | | |
| | | |
(S,P4,C',c2')|=.=.=. RTCP Sender Reports =.=.=>| |..>|
| (for the unicast session) | | |
| | | |
-
-------> Multicast RTP Flow portmapping-req-attribute = "a=portmapping-req:" port CRLF
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow
Figure 3: Message flows for establishing a unicast session Here, 'port' is defined as specified in Section 9 of [RFC4566]. The
'portmapping-req' attribute is used as a session-level or media-level
attribute.
In the example above, the compound RTCP packet carrying the NACK 5. Message Formats
message also carries the Cookie since the server must know which port
the client is expecting to receive the RTP retransmission packet(s)
and RTCP sender reports on. If an RTCP message from the client will
not trigger any transmission from the server (e.g., RTCP receiver and
extended reports), it does not have to include the Cookie.
3.4. Keeping the NAT Binding(s) Alive This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between a server and a client for the
purpose of Token-based port mapping. Three RTCP messages are
defined:
Editor's note: We need to determine the best option to keep the NAT 1. Port Mapping Request
bindings alive [I-D.ietf-avt-app-rtp-keepalive].
Editor's note: Are RTCP receiver/extended reports enough to keep the 2. Port Mapping Response
binding alive? No, keep-alive messages need to be sent after the
request is made and until the cookie is no longer needed and the
client does not start sending RTCP reports until the unicast session
is actually established which might happen a long time after the
cookie is requested.
3.5. SDP Description 3. Token Verification
The SDP describing the scenario given in Figure 2 can be written as: These are all payload-independent RTCP feedback messages with a
common format defined in Section 6.1 of [RFC4585], also sketched in
Figure 3.
v=0 0 1 2 3
o=ali 1122334455 1122334466 IN IP4 nack.example.com 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
s=Local Retransmissions +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
t=0 0 |V=2|P| FMT | PT | length |
a=group:FID 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a=rtcp-unicast:rsi | SSRC of packet sender |
m=video 41000 RTP/AVPF 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
i=Primary Multicast Stream | SSRC of media source |
c=IN IP4 233.252.0.2/255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 : Feedback Control Information (FCI) :
a=rtpmap:98 MP2T/90000 : :
a=multicast-rtcp:42000
a=rtcp:43000 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=mid:1
m=video 51000 RTP/AVPF 99
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux
a=fmtp:99 apt=98; rtx-time=5000
a=mid:2
Figure 4: SDP describing an SSM distribution with support for Figure 3: The common packet format for the RTCP feedback messages
retransmissions from a local server
In this SDP, the source stream is multicast from a distribution Each feedback message has a fixed-length field for version, padding,
source (with a source IP address of 198.51.100.1) to the multicast feedback message type (FMT), packet type (PT), length, SSRC of packet
destination address of 233.252.0.2 (G) and port 41000 (P1). The sender, SSRC of media source as well as a variable-length field for
associated RTCP packets are multicast in the same group to port 42000 feedback control information (FCI).
(P2). A retransmission server including feedback target
functionality with an IP address of 192.0.2.1 (S) and port of 43000
(P3) is specified with the 'rtcp' attribute. The server uses port
51000 (P4) for the unicast sessions.
4. Message Formats In the new messages defined in this section, the PT field is set to
RTPFB (205) and the FMT field is set to Port Mapping (7). Individual
Port Mapping messages are identified by a sub-field called Sub
Feedback Message Type (SFMT). Any Reserved field SHALL be set to
zero and ignored.
Editor's note: Should we stick with 4585 packet format? Following the rules specified in [RFC3550], all integer fields in the
messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian.
Unless otherwise stated, numeric constants are in decimal (base 10).
Editor's note: Must the client use the same SSRC (and the same but 5.1. Port Mapping Request
unique CNAME) both in the multicast and unicast sessions so the
reports received in two sessions can be linked?
The common packet format for the RTCP feedback messages is defined in The Port Mapping Request message is identified by SFMT=1. This
Section 6.1 of [RFC4585]. A feedback message has a fixed-length message is a unicast feedback message transmitted by the client to a
field for version, padding, feedback message type (FMT), payload type dedicated server port to request a Token. In the Port Mapping
(PT), length, SSRC of packet sender, SSRC of media sender as well as Request message, the client MUST set both the packet sender SSRC and
a variable-length field for feedback control information (FCI). media source SSRC fields to its own SSRC since the Port Mapping
Request message is not necessarily linked to any specific media
source. The FCI field has the structure depicted in Figure 4.
In the PortMappingRequest and PortMappingResponse messages, the PT 0 1 2 3
field is set to RTPFB (205), and the respective FMT fields are set to 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
PMReq (7) and PMRes (8). Depending on the specific scenario, it may +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
be desirable to send these messages in a reduced-size RTCP packet | SFMT=1 | Reserved |
[RFC5506]. However, unless support for [RFC5506] has been signaled, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
compound RTCP packets MUST be used by following [RFC3550] rules. | Random |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Editor's note: Should the server always respond to the PMReq message Figure 4: The FCI field of Port Mapping Request message
as soon as possible? If the request is rejected, the server could
send a PMRes message with the Cookie field empty.
Following the rules specified in [RFC3550], all integer fields in the o Random Nonce (64 bits): Mandatory field that contains a random
messages defined below are carried in network-byte order, that is, nonce value generated by the client following the procedures of
most significant byte (octet) first, also known as big-endian. [RFC4086]. This nonce MUST be taken into account by the server
Unless otherwise noted, numeric constants are in decimal (base 10). when generating a Token for the client to enable better security
Any Reserved field SHALL be set to zero and ignored. for clients that share the same IP address. If the Port Mapping
Request message is transmitted multiple times for redundancy
reasons, the random nonce value MUST remain the same in these
duplicated messages.
4.1. PortMappingRequest (PMReq) 5.2. Port Mapping Response
Editor's note: How do we set the media sender SSRC field in the The Port Mapping Response message is identified by SFMT=2. This
following message? The suggested approach is to use client's SSRC in message is sent by the server and delivers the Token to the client.
both packet sender and media sender SSRC fields. In the Port Mapping Response message, the packet sender SSRC and
media sender SSRC fields are both set to the client's SSRC since the
Port Mapping Response message is not necessarily linked to any
specific media source. The FCI field has the structure depicted in
Figure 5.
0 1 2 3 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 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=7 | PT=205 | Length | | SFMT=2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source | : Token :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Random Number | | Expiry Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Syntax for the PortMappingRequest (PMReq) message Figure 5: FCI field syntax for the Port Mapping Response message
4.2. PortMappingResponse (PMRes) o Token (128 bits): Mandatory element that contains the Token
generated by the server.
The PortMappingResponse message is used by the server to send a o Expiry Time (32 bits): Mandatory element that contains the expiry
Cookie to the client, and by the client to include a Cookie in the time of the Token. The expiry time is expressed in seconds from
RTCP packets as necessary. We might need to rename this message. the time the Token was generated. An expiry time of zero
indicates that the accompanying Token is not valid.
Editor's note: How do we set the packet sender SSRC and media sender 5.3. Token Verification
SSRC fields in the following message? Are they application specific
(e.g., retransmissions, RAMS, etc.)? See the earlier editor's note. The Token Verification message is identified by SFMT=3. This message
contains the Token and MUST accompany any other RTCP feedback message
sent by the client to trigger or control a unicast session. Examples
include the RAMS-R and RAMS-T messages
[I-D.ietf-avt-rapid-acquisition-for-rtp] as well as the NACK messages
[RFC4585]. In the Token Verification message, the client MUST set
both the packet sender SSRC and media source SSRC fields to its own
SSRC since the media source SSRC may not be known. The client MUST
NOT send a Token Verification message with a Token that has expired.
The FCI field has the structure depicted in Figure 6.
0 1 2 3 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 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=8 | PT=205 | Length | | SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie : : Token :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax for the PortMappingResponse (PMRes) message Figure 6: FCI field syntax for the Token Verification message
Editor's note: What else do we need to transmit in the PMRes o Token (128 bits): Mandatory element that contains the Token
message? In particular, should the server indicate the expiration previously acquired by the client.
date for the Cookie?
5. Procedures for Cookie Construction 6. Procedures for Token Construction
Editor's notes: Editor's notes:
The Cookie may contain The Token SHOULD be calculated by the server by taking into account:
o A 32-bit value randomly generated by the client [RFC4086]
o Client's IP address and port. Note that the PMReq and NACK o Client's IP address as seen by the server
messages are sent from different client ports (and maybe from
different public IP addresses as well), thus the server cannot use
this information to check whether a cookie is used by the true
owner of that cookie.
o Client's CNAME o The nonce generated by the client and inserted in the Port Mapping
Request message
o A timestamp to protect against replay attacks (Should the server o A timestamp to protect against replay attacks
tell the client about the expiration date so that the client may
request a new cookie before the current one expires?)
o HMAC [RFC2104] of the above information (where only the server o HMAC [RFC2104] of the above information (where only the server
knows the HMAC secret) knows the HMAC secret)
The server conveys the expiration time in the clear to the client in
the Port Mapping Response message. Thus, the client can request a
new Token before the current one expires.
Details are TBC. Details are TBC.
6. Security Considerations 7. Validating Tokens
Editor's notes: Upon receipt of an RTCP feedback message along with the Token
Verification message that contains a Token, the server MUST validate
the Token. The server considers a Token valid if the source IP
address of the RTCP feedback message matches the IP address in the
Token and the Token has not expired yet.
o Cookie expiration via timestamping. This could be important for The IP address is encoded into the Token by the server, using an
clients behind the same NAT (The clients may still generate the algorithm known only to the server. This, combined with the
same random number) expiration time provides protection against DoS attacks so that a
client using a certain IP address cannot cause one or more RTP
packets to be sent to another client with a different IP address.
o Stealing cookies. Can CNAME be used to avoid this for the clients When the server detects that the Token is invalid, it SHOULD NOT
behind the same NAT? silently discard client's message since this adds an undesired delay.
Instead, it is RECOMMENDED that applications define an application-
specific error response. In applications that have not defined an
error response, the server MUST reply back to the client with a Port
Mapping Response message (that goes from port P3 on the server to
port c1 on the client) where the Token field carries the invalid
Token sent by the client and the Expiry Time field is set to zero
(indicating that the Token is invalid).
o Modifying cookies. Can somebody manipulate the cookies to For applications using [I-D.ietf-avt-rapid-acquisition-for-rtp], this
redirect the traffic? draft defines a new 4xx-level response code in the RAMS Response Code
Space Registry.
7. IANA Considerations 8. SDP Example
The declarative SDP describing the scenario given in Figure 2 is
written as:
v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1
a=rtpmap:98 MP2T/90000s
a=multicast-rtcp:41500 ; Note 1
a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2
a=rtcp-fb:98 nack ; Note 2
a=mid:1
m=video 42000 RTP/AVPF 99 ; Note 3
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux ; Note 4
a=rtcp:42500 ; Note 5
a=fmtp:99 apt=98; rtx-time=5000
a=portmapping-req:30000 ; Note 6
a=mid:2
Figure 7: SDP describing an SSM distribution with support for
retransmissions from a local server
In this description, we highlight the following notes:
Note 1: The source stream is multicast from a distribution source
with a source IP address of 198.51.100.1 (DS) to the multicast
destination address of 233.252.0.2 (G) and port 41000 (P1). The
associated RTCP packets are multicast in the same group to port 41500
(P2).
Note 2: A retransmission server including feedback target
functionality with an IP address of 192.0.2.1 (S) and port of 42000
(P3) is specified with the 'rtcp' attribute. The feedback
functionality is enabled for the RTP stream with payload type 98
through the 'rtcp-fb' attribute [RFC4585].
Note 3: The port specified in the second "m" line (for the unicast
stream) does not mean anything in this scenario as the client does
not send any RTP traffic back to the server.
Note 4: The server multiplexes RTP and RTCP packets on the same port
(c1 in Figure 2).
Note 5: The server uses port 42500 (P4) for the unicast sessions.
Note 6: The "a=portmapping-req" line indicates that a Token needs to
be retrieved first before a unicast session associated to the
multicast session can be established and that the Port Mapping
Request message needs to be sent to port 30000 (PT).
9. Address Pooling NATs
Large-scale NAT (LSN) devices have a pool of public IPv4 addresses
and map internal hosts to one of those public IPv4 addresses. As
long as an internal host maintains an active mapping in the NAT, the
same IPv4 address is assigned to new connections. However, once all
of the host's mappings have been deleted (e.g., because of timeout),
it is possible that a new connection from that same host will be
assigned a different IPv4 address from the pool. When that occurs,
the Token will be considered invalid by the server, causing an
additional round trip for the client to acquire a fresh Token.
Any traffic from the host which traverses the NAT will prevent this
problem. As the host is sending RTCP receiver reports at least every
5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is
receiving, those RTCP messages will be sufficient to prevent this
problem.
10. Security Considerations
The Token, which is generated based on a client's IP address and
expiration date, provides protection against denial-of-service (DoS)
attacks. An attacker using a certain IP address cannot cause one or
more RTP packets to be sent to a victim client who has a different IP
address. However, if the attacker acquires a valid Token for a
victim and can spoof the victim's source address, this approach
becomes vulnerable to replay attacks.
Multicast is deployed on managed networks - not the Internet. These
managed networks will choose to enable network ingress filtering
[RFC2827] or not. If ingress filtering is enabled on a network, an
attacker attacker cannot spoof a victim's IP address to use a Token
to initiate an attack against a victim. However, if ingress
filtering is not enabled on a network, an attacker could obtain a
Token and spoof the victim's address, causing traffic to flood the
victim. On such a network, the server can reduce the time period for
such an attack by expiring a Token in a short period of time. In the
extreme case, the server can expire the Token immediately after its
first use. An expired Token forces a round trip from the client to
the server.
11. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
7.1. Registration of FMT Values 11.1. Registration of SDP Attributes
Within the RTPFB range, the following format (FMT) values are This document registers a new attribute name in SDP.
SDP Attribute ("att-field"):
Attribute name: portmapping-req
Long form: Port for requesting Token
Type of name: att-field
Type of attribute: Either session or media level
Subject to charset: No
Purpose: See this document
Reference: [RFCXXXX]
Values: See this document
11.2. Registration of FMT Values
Within the RTPFB range, the following format (FMT) value is
registered: registered:
Name: PMReq Name: Port Mapping
Long name: Port Mapping Request Long name: Port Mapping Between Unicast and Multicast RTP Sessions
Value: 7 Value: 7
Reference: [RFCXXXX] Reference: [RFCXXXX]
Name: PMRes 11.3. SFMT Values for Port Mapping Messages Registry
Long name: Port Mapping Response
Value: 8
Reference: [RFCXXXX]
8. Contributors and Acknowledgments This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for Port
Mapping messages. The registry is called the SFMT Values for Port
Mapping Messages Registry. This registry is to be managed by the
IANA according to the Specification Required policy of [RFC5226].
Many individuals in the AVT and MMUSIC WGs have contributed to this The length of the SFMT field in the Port Mapping messages is a single
work, reviewed earlier versions of this specification and provided octet, allowing 256 values. The registry is initialized with the
feedback. The authors thank each of them. following entries:
9. References Value Name Reference
----- -------------------------------------------------- -------------
0 Reserved [RFCXXXX]
1 Port Mapping Request [RFCXXXX]
2 Port Mapping Response [RFCXXXX]
3 Token Verification [RFCXXXX]
4-254 Assignable - Specification Required
255 Reserved [RFCXXXX]
9.1. Normative References The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value needs to contain the
following information:
o Contact information of the one doing the registration, including
at least name, address, and email.
o A detailed description of what the new SFMT represents and how it
shall be interpreted.
11.4. RAMS Response Code Space Registry
This document adds the following entry to the RAMS Response Code
Space Registry.
Code Description Reference
----- -------------------------------------------------- -------------
405 Invalid Token [RFCXXXX]
This response code is used when the Token included by the RTP_Rx in
the RAMS-R message is invalid.
12. Acknowledgments
The approach presented in this document came out after discussions
with various individuals in the AVT and MMUSIC WGs, and the breakout
session held in the Anaheim meeting. We thank each of these
individuals.
13. References
13.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Control Packets on a Single Port", RFC 5761, April 2010. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-avt-app-rtp-keepalive] [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Marjou, X. and A. Sollaud, "Application Mechanism for Requirements for Security", BCP 106, RFC 4086, June 2005.
maintaining alive the Network Address Translator (NAT)
mappings associated to RTP flows.",
draft-ietf-avt-app-rtp-keepalive-07 (work in progress),
December 2009.
9.2. Informative References 13.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-09 (work in
progress), April 2010.
[I-D.ietf-behave-nat-behavior-discovery]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", draft-ietf-behave-nat-behavior-discovery-08
(work in progress), September 2009.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-16 (work in
progress), October 2010.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [I-D.ietf-avt-app-rtp-keepalive]
"Session Traversal Utilities for NAT (STUN)", RFC 5389, Marjou, X. and A. Sollaud, "Application Mechanism for
October 2008. keeping alive the Network Address Translator (NAT)
mappings associated to RTP flows.",
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size draft-ietf-avt-app-rtp-keepalive-09 (work in progress),
Real-Time Transport Control Protocol (RTCP): Opportunities September 2010.
and Consequences", RFC 5506, April 2009.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses Authors' Addresses
Ali Begen Ali Begen
Cisco Cisco
181 Bay Street 181 Bay Street
Toronto, ON M5J 2T3 Toronto, ON M5J 2T3
CANADA Canada
Email: abegen@cisco.com Email: abegen@cisco.com
Bill VerSteeg Dan Wing
Cisco Cisco Systems, Inc.
5030 Sugarloaf Parkway 170 West Tasman Dr.
Lawrenceville, GA 30044 San Jose, CA 95134
USA USA
Email: billvs@cisco.com Email: dwing@cisco.com
Tom VanCaenegem
Alcatel-Lucent
Copernicuslaan 50
Antwerpen, 2018
Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.com
 End of changes. 93 change blocks. 
345 lines changed or deleted 506 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/