Subject: [AVT] I-D Action:draft-ietf-avt-rtp-g719-04.txt

From: [email-masked]
Date: Mon, 17 Nov 2008 15:30:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title           : RTP Payload format for G.719
	Author(s)       : M. Westerlund, I. Johansson
	Filename        : draft-ietf-avt-rtp-g719-04.txt
	Pages           : 28
	Date            : 2008-11-17

This document specifies the payload format for packetization of the
G.719 full-band codec encoded audio signals into the Real-time
Transport Protocol (RTP).  The payload format supports transmission
of multiple channels, multiple frames per payload, and interleaving.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g719-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Nov 2008 18:21:16 -0600

Hi,

The updates are quite minimal in this version but are to address two
comments from Cullen in his AD review.

The first is the talk in section 10.1 first paragraph:

   In order to ensure confidentiality of the encoded audio, all audio
   data bits MUST be encrypted.  There is less need to encrypt the
   payload header or the table of contents since they only carry
   information about the frame type.  This information could also be
   useful to a third party, for example, for quality monitoring.
   However, as there currently don't exist any mechanism supporting
   differential protection, this behavior isn't expected to be supported
   and requirement of the audio data will be what governs the protection
   of the RTP payload.

>From the sentence starting with "However" is new and was written to
clarify that we aren't really expecting anyone to support this minor detail.

The second change is related to the congestion control section. Cullen
raised correctly that we where not particular clear on the congestion
issues when using redundancy. That has resulted in the following text:

   "If
   forward error correction (FEC) is used, the amount of FEC-induced
   redundancy needs to be regulated such that the use of FEC itself does
   not cause a congestion problem.  In other words a sender SHALL NOT
   increase the total bit-rate when adding redundancy in response to
   packet loss, and needs instead to adjust it down in accordance to the
   congestion control algorithm being run.  Thus when adding redundancy
   the media bit-rate will generally be needed to reduced to free up the
   bit-rate that is used for redundancy."

The first sentence existed the rest i new.

If you have any comments about this we will take this as IETF last call
comments.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt