draft-ietf-avt-ports-for-ucast-mcast-rtp-01.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-02.txt 
AVT A. Begen AVT A. Begen
Internet-Draft B. VerSteeg Internet-Draft B. VerSteeg
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: October 14, 2010 April 12, 2010 Expires: November 20, 2010 May 19, 2010
Port Mapping Between Unicast and Multicast RTP Sessions Port Mapping Between Unicast and Multicast RTP Sessions
draft-ietf-avt-ports-for-ucast-mcast-rtp-01 draft-ietf-avt-ports-for-ucast-mcast-rtp-02
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 receive ports for an auxiliary unicast receivers to choose their own ports for an auxiliary unicast session
session in RTP applications using both unicast and multicast in RTP applications using both unicast and multicast services. The
services. The solution requires multiplexing RTP and RTCP on a solution requires multiplexing RTP and RTCP on a single port on both
single port on both endpoints in the unicast session. 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 October 14, 2010. This Internet-Draft will expire on November 20, 2010.
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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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. Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Steps for Establishing a Unicast Session . . . . . . . . . 8 3.1. Steps for Establishing a Unicast Session . . . . . . . . . 8
3.2. Implications of NATs . . . . . . . . . . . . . . . . . . . 9 3.2. Implications of NATs . . . . . . . . . . . . . . . . . . . 9
3.3. Message Flows . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Message Flows . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Keeping the NAT Binding(s) Alive . . . . . . . . . . . . . 11 3.4. Keeping the NAT Binding(s) Alive . . . . . . . . . . . . . 12
3.5. SDP Description . . . . . . . . . . . . . . . . . . . . . 11 3.5. SDP Description . . . . . . . . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. PortMappingRequest (PMReq) . . . . . . . . . . . . . . . . 13 4.1. PortMappingRequest (PMReq) . . . . . . . . . . . . . . . . 14
4.2. PortMappingResponse (PMRes) . . . . . . . . . . . . . . . 14 4.2. PortMappingResponse (PMRes) . . . . . . . . . . . . . . . 15
5. Procedures for Cookie Construction . . . . . . . . . . . . . . 15 5. Procedures for Cookie Construction . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Registration of FMT Values . . . . . . . . . . . . . . . . 17 7.1. Registration of FMT Values . . . . . . . . . . . . . . . . 18
8. Contributors and Acknowledgments . . . . . . . . . . . . . . . 18 8. Contributors and Acknowledgments . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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
receive ports for RTP and RTCP since these ports are local resources ports for RTP and RTCP since these ports are local resources and only
and only the receiving end can determine which ports are available to the receiving end can determine which ports are available to use.
use. The receiving may convey its request to the sending end through The receiving may convey its request to the sending end through
different ways, one of which is the Offer/Answer Model [RFC3264] for different ways, one of which is the Offer/Answer Model [RFC3264] for
the Session Description Protocol (SDP) [RFC4566]. However, the the Session Description Protocol (SDP) [RFC4566]. However, the
Offer/Answer Model requires offer/answer exchange(s) between the Offer/Answer Model requires offer/answer exchange(s) between the
endpoints, and the resulting delay may not be desirable in delay- endpoints, and the resulting delay may not be desirable in delay-
sensitive real-time applications. Furthermore, the Offer/Answer sensitive real-time applications. Furthermore, the Offer/Answer
Model may be burdensome for the endpoints that are concurrently Model may be burdensome for the endpoints that are concurrently
running a large number of unicast sessions with other endpoints. running a large number of unicast sessions with other endpoints.
In this specification, we consider an RTP application that uses one In this specification, we consider an RTP application that uses one
or more unicast and multicast RTP sessions together. While the or more unicast and multicast RTP sessions together. While the
skipping to change at page 3, line 49 skipping to change at page 3, line 49
Another scenario is where a receiver wants to rapidly acquire a new Another scenario is where a receiver wants to rapidly acquire a new
primary multicast RTP session and receives one or more RTP burst primary multicast RTP session and receives one or more RTP burst
packets over a unicast session before joining the SSM session packets over a unicast session before joining the SSM session
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in
applications where some part of the content is distributed through applications where some part of the content is distributed through
multicast while the receivers get additional and/or auxiliary content multicast while the receivers get additional and/or auxiliary content
through one or more unicast connections, as sketched in Figure 1. through one or more unicast connections, as sketched in Figure 1.
In this document, we discuss this problem and introduce a solution In this document, we discuss this problem and introduce a solution
that we refer to as Port Mapping. This solution allows receivers to that we refer to as Port Mapping. This solution allows receivers to
choose their desired RTP and RTCP receive ports for every unicast choose their desired UDP ports for RTP and RTCP in every unicast
session when they are running RTP applications using both unicast and session when they are running RTP applications using both unicast and
multicast services. multicast services, and offer/answer exchange is not available. This
solution is not applicable in cases where TCP is used as the
transport protocol in the unicast sessions. For such scenarios,
refer to [RFC4145].
----------- -----------
| Unicast |................ | Unicast |................
| Source |............. : | Source |............. :
| (Server) | : : | (Server) | : :
----------- : : ----------- : :
v v v v
----------- ---------- ----------- ----------- ---------- -----------
| Multicast |------->| Router |---------->|Client RTP | | Multicast |------->| Router |---------->|Client RTP |
| Source | | |..........>|Application| | Source | | |..........>|Application|
skipping to change at page 7, line 16 skipping to change at page 7, line 16
| |-------------------------------| |-->|P1 | | |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | | | | | | | |
| Distribution | ---------------- | | | | | Distribution | ---------------- | | | |
| Source | | | | | | | | Source | | | | | | |
| |---->|P1 | | | | | | |---->|P1 | | | | |
| |.-.->|P2 | | | | | | |.-.->|P2 | | | | |
| | | | | | | | | | | | | | | |
-------------- | P3|<.=.=.=.| |=.=|*c1 | -------------- | P3|<.=.=.=.| |=.=|*c1 |
| P3|<~~~~~~~| |~~~|*c1 | | P3|<~~~~~~~| |~~~|*c1 |
| | | N | | | PRIMARY MULTICAST | | | | | |
RTP SESSION with | | | | | |
UNICAST FEEDBACK | | | N | | |
| Retransmission | | A | | Client | | Retransmission | | A | | Client |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| Server | | T | | | | Server | | T | | |
| | | | | | AUXILIARY UNICAST | | | | | |
RTP SESSION | P4|<~~~~~~~| |~~>|*c2 |
| P4|........| |..>|*c2 | | P4|........| |..>|*c2 |
| P4|<.=.=.=.| |=.>|*c2 | | P4|<.=.=.=.| |=.>|*c2 |
| | | | | | | | | | | |
---------------- --- ---------- ---------------- --- ----------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP Feedback Messages (if any)
.......> 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 primary multicast session, respectively. The clients listen to
these ports to receive the multicast RTP and RTCP packets. Ports these ports to receive the multicast RTP and RTCP packets. Ports
P1 and P2 are defined declaratively. P1 and 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 RTP 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. primary multicast session. Port P3 is defined declaratively.
o Port P4 denotes the port on the retransmission server used for the o Port P4 denotes the port on the retransmission server used for the
unicast session. The server multiplexes RTP and RTCP traffic on unicast session. The server multiplexes RTP and RTCP traffic on
this single port [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast this single port [RFC5761] in the unicast session. Port P4 is
session. Port P4 is defined declaratively. defined declaratively and MUST be different from port P3.
o Ports *c1 and *c2 are chosen by the client. *c1 denotes the port o Ports *c1 and *c2 are chosen by the client. *c1 denotes the port
on the client used to send the unicast RTCP feedback in the on the client used to send the unicast RTCP feedback in the
primary multicast session. *c2 denotes the port on the client used primary multicast session. *c2 denotes the port on the client used
in the unicast session. The client muxes RTP and RTCP traffic on in the unicast session. The client multiplexes RTP and RTCP
this single port [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast traffic on this single port [RFC5761] in the unicast session.
session. Ports c1 and c2 do not have to be different ports. Ports c1 and c2 do not have to be different ports.
Once the unicast session is established, the server needs to remember Once the unicast session is established, the server needs to remember
the public IP address and public port of the client as part of the the public IP address and public port of the client as part of the
session state information. The public ports of the client are session state information. The public ports of the client are
denoted by c1' and c2'. denoted by c1' and c2'.
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
skipping to change at page 8, line 41 skipping to change at page 8, line 43
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 3.1. Steps for Establishing a Unicast Session
The steps to establish a unicast session are provided below: 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 receive port numbers (*c1 and *c2). 2. The client determines its port numbers (*c1 and *c2).
3. The client sends a message to the server via a new RTCP message, 3. The client sends a message to the server via a new RTCP message,
called PortMappingRequest. This message MUST be sent from port called PortMappingRequest. This message MUST be sent from port
c2 to port P4. The server learns client's public IP address (C') c2 to port P4. The server learns client's public IP address (C')
and its public RTP/RTCP port (c2') from the received message. and its public RTP/RTCP port (c2') from the received message.
4. The server generates an opaque encapsulation (called Cookie) that 4. The server generates an opaque encapsulation (called Cookie) that
conveys client's addressing information using a reversible conveys client's addressing information using a reversible
transform only known to the server. transform only known to the server.
5. The server sends the Cookie back to the client using a new RTCP 5. The server sends the Cookie back to the client using a new RTCP
message, called PortMappingResponse. This message MUST be sent message, called PortMappingResponse. This message MUST be sent
from port P4 to port c2'. from port P4 to port c2'.
6. The client includes the Cookie when necessary in the subsequent 6. The client includes the Cookie when necessary in the subsequent
messages sent to the server. 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 7. Normal flows ensue, with the server using the addressing
encapsulated in the opaque Cookie. The client is responsible for encapsulated in the opaque Cookie. The client is responsible for
keeping the NAT binding alive for the duration of the unicast keeping the NAT binding alive for the duration of the unicast
session. session.
3.2. Implications of NATs 3.2. Implications of NATs
There may be one or more NAT devices between the client and server. There may be one or more NAT devices between the client and server.
Without an external mechanism such as STUN [RFC5389], the client Without an external mechanism such as STUN [RFC5389], the client
skipping to change at page 9, line 51 skipping to change at page 10, line 11
device may have endpoint-dependent mappings in which case the public device may have endpoint-dependent mappings in which case the public
IP address and port of the outgoing packets may differ when they are IP address and port of the outgoing packets may differ when they are
sent to different destinations. In practice, however, it is a sent to different destinations. In practice, however, it is a
difficult task to determine the type of a NAT device difficult task to determine the type of a NAT device
[I-D.ietf-behave-nat-behavior-discovery]. [I-D.ietf-behave-nat-behavior-discovery].
3.3. Message Flows 3.3. Message Flows
Figure 3 shows the message flows, where each message is appended with Figure 3 shows the message flows, where each message is appended with
the (Source Address, Source Port, Destination Address, Destination the (Source Address, Source Port, Destination Address, Destination
Port) information. Port) information. The optional messages are indicated in
parentheses and they may or may not be present in certain scenarios.
------------ ---------------- ------ ------------ ---------------- ------
|Distribution| | Retransmission | | | |Distribution| | Retransmission | | |
| Source | | Server | |Client| | Source | | Server | |Client|
| (DS) | | (S) | | (C) | | (DS) | | (S) | | (C) |
------------ ---------------- ------ ------------ ---------------- ------
| | - | | | - |
| | | | | | | | | |
(DS,*,G,P1)|--->|-------- RTP Multicast --------->| |-->| (DS,*,G,P1)|--->|------- (RTP Multicast) -------->| |-->|
(DS,*,G,P2)|.-.>|.-.-.-.- RTCP Multicast .-.-.-.->| |-->| (DS,*,G,P2)|.-.>|.-.-.-. (RTCP Multicast) -.-.-.->| |-->|
| | | | | | | |
| | | | | | | |
|<=.=. RTCP Receiver Reports =.=.=| |<..|(C,c1,S,P3) |<=.= (RTCP Receiver Reports) .=.=| |<..|(C,c1,S,P3)
| (for the multicast session) | | | | (for the multicast session) | | |
: | | : : | | :
: | | : : | | :
: | | : : | | :
: | | : : | | :
|<~~~~~ PortMappingRequest ~~~~~~~| |<~~|(C,c2,S,P4) |<~~~~~ PortMappingRequest ~~~~~~~| |<~~|(C,c2,S,P4)
| |N| | | |N| |
(S,P4,C',c2')|~~~~~~ PortMappingResponse ~~~~~>|A|~~>| (S,P4,C',c2')|~~~~~~ PortMappingResponse ~~~~~>|A|~~>|
| (Cookie) |T| | | (Cookie) |T| |
| | | | | | | |
skipping to change at page 11, line 18 skipping to change at page 12, line 18
and RTCP sender reports on. If an RTCP message from the client will 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 not trigger any transmission from the server (e.g., RTCP receiver and
extended reports), it does not have to include the Cookie. extended reports), it does not have to include the Cookie.
3.4. Keeping the NAT Binding(s) Alive 3.4. Keeping the NAT Binding(s) Alive
Editor's note: We need to determine the best option to keep the NAT Editor's note: We need to determine the best option to keep the NAT
bindings alive [I-D.ietf-avt-app-rtp-keepalive]. bindings alive [I-D.ietf-avt-app-rtp-keepalive].
Editor's note: Are RTCP receiver/extended reports enough to keep the Editor's note: Are RTCP receiver/extended reports enough to keep the
binding alive? 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
TBD. 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.5. SDP Description
The SDP describing the scenario given in Figure 2 can be written as: The SDP describing the scenario given in Figure 2 can be written as:
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions s=Local Retransmissions
t=0 0 t=0 0
a=group:FID 1 2 a=group:FID 1 2
skipping to change at page 13, line 7 skipping to change at page 14, line 7
source (with a source IP address of 198.51.100.1) to the multicast source (with a source IP address of 198.51.100.1) to the multicast
destination address of 233.252.0.2 (G) and port 41000 (P1). The destination address of 233.252.0.2 (G) and port 41000 (P1). The
associated RTCP packets are multicast in the same group to port 42000 associated RTCP packets are multicast in the same group to port 42000
(P2). A retransmission server including feedback target (P2). A retransmission server including feedback target
functionality with an IP address of 192.0.2.1 (S) and port of 43000 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 (P3) is specified with the 'rtcp' attribute. The server uses port
51000 (P4) for the unicast sessions. 51000 (P4) for the unicast sessions.
4. Message Formats 4. Message Formats
Editor's note: Should we stick with 4585 packet format?
Editor's note: Must the client use the same SSRC (and the same but
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 common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. A feedback message has a fixed-length Section 6.1 of [RFC4585]. A feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media sender as well as (PT), length, SSRC of packet sender, SSRC of media sender as well as
a variable-length field for feedback control information (FCI). a variable-length field for feedback control information (FCI).
In the PortMappingRequest and PortMappingResponse messages, the PT In the PortMappingRequest and PortMappingResponse messages, the PT
field is set to RTPFB (205), and the respective FMT fields are set to field is set to RTPFB (205), and the respective FMT fields are set to
PMReq (7) and PMRes (8). Depending on the specific scenario, it may PMReq (7) and PMRes (8). Depending on the specific scenario, it may
be desirable to send these messages in a reduced-size RTCP packet be desirable to send these messages in a reduced-size RTCP packet
[RFC5506]. However, unless support for [RFC5506] has been signaled, [RFC5506]. However, unless support for [RFC5506] has been signaled,
compound RTCP packets MUST be used by following [RFC3550] rules. compound RTCP packets MUST be used by following [RFC3550] rules.
Editor's note: Should the server always respond to the PMReq message Editor's note: Should the server always respond to the PMReq message
as soon as possible? 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 Following the rules specified in [RFC3550], all integer fields in the
messages defined below are carried in network-byte order, that is, messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian. most significant byte (octet) first, also known as big-endian.
Unless otherwise noted, numeric constants are in decimal (base 10). Unless otherwise noted, numeric constants are in decimal (base 10).
Any Reserved field SHALL be set to zero and ignored. Any Reserved field SHALL be set to zero and ignored.
4.1. PortMappingRequest (PMReq) 4.1. PortMappingRequest (PMReq)
Editor's note: How do we set the media source SSRC field in the Editor's note: How do we set the media sender SSRC field in the
following message? Is it application specific (e.g., following message? The suggested approach is to use client's SSRC in
retransmissions, RAMS, etc.)? both packet sender and media sender SSRC fields.
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 | |V=2|P| FMT=7 | PT=205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source | | SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Random Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Syntax for the PortMappingRequest (PMReq) message Figure 5: Syntax for the PortMappingRequest (PMReq) message
Editor's note: What else do we need to transmit in the PMReq
message?
4.2. PortMappingResponse (PMRes) 4.2. PortMappingResponse (PMRes)
Editor's note: How do we set the packet sender SSRC and media source The PortMappingResponse message is used by the server to send a
Cookie to the client, and by the client to include a Cookie in the
RTCP packets as necessary. We might need to rename this message.
Editor's note: How do we set the packet sender SSRC and media sender
SSRC fields in the following message? Are they application specific SSRC fields in the following message? Are they application specific
(e.g., retransmissions, RAMS, etc.)? (e.g., retransmissions, RAMS, etc.)? See the earlier editor's note.
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 | |V=2|P| FMT=8 | PT=205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source | | SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Cookie : : Cookie :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax for the PortMappingResponse (PMRes) message Figure 6: Syntax for the PortMappingResponse (PMRes) message
Editor's note: What else do we need to transmit in the PMRes Editor's note: What else do we need to transmit in the PMRes
message? message? In particular, should the server indicate the expiration
date for the Cookie?
5. Procedures for Cookie Construction 5. Procedures for Cookie Construction
Editor's notes: Editor's notes:
The Cookie may contain The Cookie may contain
o A 32-bit value randomly generated by the client [RFC4086] 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 and port. Note that the PMReq and NACK
messages are sent from different client ports (and maybe from messages are sent from different client ports (and maybe from
different public IP addresses as well), thus the server cannot use different public IP addresses as well), thus the server cannot use
this information to check whether a cookie is used by the true this information to check whether a cookie is used by the true
owner of that cookie) owner of that cookie.
o Client's CNAME o Client's CNAME
o A timestamp to protect against replay attacks (Should the server o A timestamp to protect against replay attacks (Should the server
tell the client about the expiration date so that the client may tell the client about the expiration date so that the client may
request a new cookie before the current one expires?) 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)
skipping to change at page 17, line 13 skipping to change at page 18, line 13
redirect the traffic? redirect the traffic?
7. IANA Considerations 7. 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
170 West Tasman Drive
San Jose, CA 95134 USA
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 7.1. Registration of FMT Values
Within the RTPFB range, the following format (FMT) values are Within the RTPFB range, the following format (FMT) values are
registered: registered:
Name: PMReq Name: PMReq
Long name: Port Mapping Request Long name: Port Mapping Request
skipping to change at page 19, line 28 skipping to change at page 20, line 28
[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.
[I-D.ietf-avt-rtp-and-rtcp-mux] [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[I-D.ietf-avt-app-rtp-keepalive] [I-D.ietf-avt-app-rtp-keepalive]
Marjou, X. and A. Sollaud, "Application Mechanism for Marjou, X. and A. Sollaud, "Application Mechanism for
maintaining alive the Network Address Translator (NAT) maintaining alive the Network Address Translator (NAT)
mappings associated to RTP flows.", mappings associated to RTP flows.",
draft-ietf-avt-app-rtp-keepalive-07 (work in progress), draft-ietf-avt-app-rtp-keepalive-07 (work in progress),
December 2009. December 2009.
9.2. Informative References 9.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] [I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions", Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-08 (work in draft-ietf-avt-rapid-acquisition-for-rtp-09 (work in
progress), March 2010. progress), April 2010.
[I-D.ietf-behave-nat-behavior-discovery] [I-D.ietf-behave-nat-behavior-discovery]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", draft-ietf-behave-nat-behavior-discovery-08 Using STUN", draft-ietf-behave-nat-behavior-discovery-08
(work in progress), September 2009. (work in progress), September 2009.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[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, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
skipping to change at page 21, line 9 skipping to change at page 22, line 9
Requirements for Security", BCP 106, RFC 4086, June 2005. 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.
Authors' Addresses Authors' Addresses
Ali Begen Ali Begen
Cisco Cisco
170 West Tasman Drive 181 Bay Street
San Jose, CA 95134 Toronto, ON M5J 2T3
USA CANADA
Email: abegen@cisco.com Email: abegen@cisco.com
Bill VerSteeg Bill VerSteeg
Cisco Cisco
5030 Sugarloaf Parkway 5030 Sugarloaf Parkway
Lawrenceville, GA 30044 Lawrenceville, GA 30044
USA USA
Email: billvs@cisco.com Email: billvs@cisco.com
 End of changes. 36 change blocks. 
70 lines changed or deleted 96 lines changed or added

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