Skip to main content

Port Mapping between Unicast and Multicast RTP Sessions
draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    avtcore mailing list <avt@ietf.org>,
    avtcore chair <avtcore-chairs@tools.ietf.org>
Subject: Protocol Action: 'Port Mapping Between Unicast and Multicast RTP Sessions' to Proposed Standard (draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt)

The IESG has approved the following document:
- 'Port Mapping Between Unicast and Multicast RTP Sessions'
  (draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt) as a Proposed
Standard

This document is the product of the Audio/Video Transport Core
Maintenance Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/


Ballot Text

Technical Summary

This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services. The
solution provides protection against denial-of-service or packet
amplification attacks that could be used to cause one or more RTP
packets to be sent to a victim client.

Working Group Summary

This document was discussed heavily in the AVT working group before
moving to AVTCORE. There was a discussion if to use a token or cookie 
for the solution. The initial solution was based on a cookie but after a 
technical discussion in IETF78 and mailing list call for consensus the 
token based solution was selected. There was a consensus to use this approach.

Document Quality

This document received a high level of working group review over two
last calls. Detailed reviews were received from several working group
participants. Magnus Westerlund and Colin Perkins provided particularly
extensive review comments.

RFC Editor Note