headers
internet-drafts | 6 Feb 13:45
Picon
Favicon

[AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-10.txt


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

	Title           : RTCP Extension for Third-party Loss Report
	Author(s)       : Qin Wu
                          Frank Xia
                          Roni Even
	Filename        : draft-ietf-avtcore-feedback-supression-rtp-10.txt
	Pages           : 17
	Date            : 2012-02-06

   In a large RTP session using the RTCP feedback mechanism defined in
   RFC 4585, a feedback target may experience transient overload if some
   event causes a large number of receivers to send feedback at once.
   This overload is usually avoided by ensuring that feedback reports
   are forwarded to all receivers, allowing them to avoid sending
   duplicate feedback reports.  However, there are cases where it is not
   recommended to forward feedback reports, and this may allow feedback
   implosion.  This memo discusses these cases and defines a new RTCP
   third-party loss report that can be used to inform receivers that the
   feedback target is aware of some loss event, allowing them to
   suppress feedback.  Associated SDP signalling is also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-10.txt

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

Permalink | Reply | 0 comments |
headers
internet-drafts | 10 Feb 02:57
Picon
Favicon

[AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-11.txt


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

	Title           : RTCP Extension for Third-party Loss Report
	Author(s)       : Qin Wu
                          Frank Xia
                          Roni Even
	Filename        : draft-ietf-avtcore-feedback-supression-rtp-11.txt
	Pages           : 17
	Date            : 2012-02-09

   In a large RTP session using the RTCP feedback mechanism defined in
   RFC 4585, a feedback target may experience transient overload if some
   event causes a large number of receivers to send feedback at once.
   This overload is usually avoided by ensuring that feedback reports
   are forwarded to all receivers, allowing them to avoid sending
   duplicate feedback reports.  However, there are cases where it is not
   recommended to forward feedback reports, and this may allow feedback
   implosion.  This memo discusses these cases and defines a new RTCP
   third-party loss report that can be used to inform receivers that the
   feedback target is aware of some loss event, allowing them to
   suppress feedback.  Associated SDP signalling is also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-11.txt

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

Permalink | Reply | 0 comments |
headers
Qin Wu | 10 Feb 03:08
Favicon

[AVTCORE] Fw: I-D Action: draft-ietf-avtcore-feedback-supression-rtp-11.txt

On 10 February 2012, at 9:57 AM, Internet-Drafts <at> ietf.org wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
> 
> Title           : RTCP Extension for Third-party Loss Report
> Author(s)       : Qin Wu
>                          Frank Xia
>                          Roni Even
> Filename        : draft-ietf-avtcore-feedback-supression-rtp-11.txt
> Pages           : 17
> Date            : 2012-02-09
> 
>   In a large RTP session using the RTCP feedback mechanism defined in
>   RFC 4585, a feedback target may experience transient overload if some
>   event causes a large number of receivers to send feedback at once.
>   This overload is usually avoided by ensuring that feedback reports
>   are forwarded to all receivers, allowing them to avoid sending
>   duplicate feedback reports.  However, there are cases where it is not
>   recommended to forward feedback reports, and this may allow feedback
>   implosion.  This memo discusses these cases and defines a new RTCP
>   third-party loss report that can be used to inform receivers that the
>   feedback target is aware of some loss event, allowing them to
>   suppress feedback.  Associated SDP signalling is also defined.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-11.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 15 Feb 14:57
Picon
Favicon

[AVTCORE] Comments on draft-ietf-avtcore-monarch-09

Hi,

As a WG chair I got the request to start a WG last call on this
document. I have been a bit slow to get to this, but when I looked at
the document before starting the WG last call I think the document isn't
really ready for a WG last call. Thus instead I request that the WG
helps develop the document to be ready for WG last call.

The main issue I see with this document is focused on section 3 which is
intended to provide an overview of the monitoring architecture for RTP.
I see a number of issues with this section and especially figure 1.

1. Figure one fails to place third party monitor in relation to any of
the packet flows. I think they belong on the RTP/RTCP paths between the
sender, intermediate and the receiver.

2. I think the document needs to discuss a bit about how the information
flows from the different nodes to the management systems. There is an
arrow 5 from the RTP sender to the management system. First of all I
think this arrow should be separated from the other 5. In addition I
think there should exist arrows from the Third party monitor, the
monitor in the intermediate and receiver directly to the management
systems. And these arrows could be RTCP information being forward in
real-time. However, they could also be other solutions.

3. In general I think 3.1 should discuss what exist already for
monitoring which there is no discussion. Like the RTP MIB. I can also
see other solutions like using IPfix to capture a packet flow and then
process using an RTP and RTCP receiver.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Magnus Westerlund | 16 Feb 09:35
Picon
Favicon

Re: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09)

Hi,

I have reviewed the changes you have done. I think they are ok, except
for the one below.

On 2012-01-30 10:03, Qin Wu wrote:

> 1. Section 4.2:
> 
> Synchronization source (SSRC):32 bits
> 
>       The SSRC value of the media source that is requested to send a
>       decoder refresh point or that is indicated that it lost
>       synchronization with the video stream.
> 
> I think this definition is wrong. Shouldn't it be the SSRC for who's
> media stream the media sender is already aware of an expressed need for
> taking action that a PLI or FIR reqiests of this SSRC?
> 
> I don't think the above is the right text for the spec, but I just
> trying to express what the right type of definition would be.
> 
> [Qin]: Agree. How about changing the text as:
> "
> Section 4.2:
> 
>    Synchronization source (SSRC):32 bits
> 
>       The SSRC value of the media source that has already been aware the
>       receiver lost synchronization with the video stream and signal to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Qin Wu | 16 Feb 10:59
Favicon

[AVTCORE] 答复: WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09)

Hi,Magnus:
The proposed change looks good to me, 
I will impement this in the update. Thank you very much.

Regards!
-Qin
________________________________________
发件人: avt-bounces <at> ietf.org [avt-bounces <at> ietf.org] 代表 Magnus Westerlund [magnus.westerlund <at> ericsson.com]
发送时间: 2012年2月16日 16:35
到: Qin Wu
Cc: avt <at> ietf.org; draft-ietf-avtcore-feedback-supression-rtp <at> tools.ietf.org
主题: Re: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09)

Hi,

I have reviewed the changes you have done. I think they are ok, except
for the one below.

On 2012-01-30 10:03, Qin Wu wrote:

> 1. Section 4.2:
>
> Synchronization source (SSRC):32 bits
>
>       The SSRC value of the media source that is requested to send a
>       decoder refresh point or that is indicated that it lost
>       synchronization with the video stream.
>
> I think this definition is wrong. Shouldn't it be the SSRC for who's
> media stream the media sender is already aware of an expressed need for
(Continue reading)

Permalink | Reply | 2 comments |
headers
Magnus Westerlund | 17 Feb 10:34
Picon
Favicon

[AVTCORE] Questions regarding EKT (draft-ietf-avt-srtp-ekt-03)

Authors, WG,

I have reviewed the EKT draft and have a number of high level comments
and questions about this draft. Please consider this as individual
input, not as WG chair.

I have done this review from the perspective of checking if two
different use cases are possible to realize using EKT. The two use cases
are:

A) Centralized conferencing using a RTP transport translator. Example
would be 4 end-points establishing unicast traffic session to the
translator. On each of these DTLS-SRTP would be used for keying and all
nodes support EKT. The goal is that the transport translator should be
able to forward all RTP and RTCP packets from one participant to all the
other without any processing related to security (SRTP). I assume the
translator supports DTLS-SRTP and the signalling helps ensure that the
conference participants agree on a single KEK and SPI set.

B) A WEBRTC endpoint Alice (using DTLS-SRTP + EKT in this case) uses a
media gateway (MGW) (DTLS+SRTP and EKT support) to connect to a SDESC
keyed SRTP legacy end-point Bob. The goal is that the MGW should not
need to perform any SRTP or SRTCP operations beyond injecting Bob's key
using EKT to Alice. This is basically the use case described in Appendix
A in the draft.

From my review I have the following issues with the current definition
of EKT or at least the description. I do not rule out that I have missed
something in the description.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Magnus Westerlund | 17 Feb 11:47
Picon
Favicon

Re: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-06.txt

WG,

We authors have now submitted a new version of the draft. It contains
text proposal for the two outstanding issues and some few minor
editorial changes. Please review these proposals and provide us feedback
within 2 weeks. I hope the responsible WG chair will progress these
documents unless there is no feedback after these 2 weeks. If you have
reviewed the changes and think they are fine, please provide that
feedback also.

Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-ecn-for-rtp-06

Cheers

Magnus Westerlund
(as author)

On 2012-02-17 11:39, internet-drafts <at> ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
> 
> 	Title           : Explicit Congestion Notification (ECN) for RTP over UDP
> 	Author(s)       : Magnus Westerlund
>                           Ingemar Johansson
>                           Colin Perkins
>                           Piers O'Hanlon
>                           Ken Carlberg
> 	Filename        : draft-ietf-avtcore-ecn-for-rtp-06.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roni Even | 17 Feb 14:09
Picon

[AVTCORE] WGLC on Encryption of Header Extensions in SRTP

Hi,

I would like to start a WGLC on  Encryption of Header Extensions in the Secure  Real-Time Transport  Protocol (SRTP) in http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-01

 

This is the abstract of the draft:

 

"The Secure Real-Time Transport Protocol (SRTP) provides  authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets.  However, RTP header extensions may  carry sensitive information for which participants in multimedia  sessions want confidentiality.  This document provides a mechanism,  extending the mechanisms of SRTP, to selectively encrypt RTP header  extensions in SRTP."

 

 

Please send any comments  by March 8th .

 

Thanks

Roni Even

 

 

_______________________________________________
Audio/Video Transport Core Maintenance
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 2 comments |
headers
Woo-Hwan Kim | 22 Feb 06:32
Picon

[AVTCORE] Request for review: The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)

AVT experts,


Let me make a request for review 
on the draft " The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) ".


Any comments would be appreciated.


---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: 2012/2/22
Subject: New Version Notification for draft-nsri-avtcore-aria-srtp-00.txt
To: whkim5 <at> ensec.re.kr
Cc: ds_kwon <at> ensec.re.kr, whkim5 <at> ensec.re.kr, dongchan <at> ensec.re.kr, jhpark <at> ensec.re.kr, jklee <at> ensec.re.kr


A new version of I-D, draft-nsri-avtcore-aria-srtp-00.txt has been successfully submitted by Woo-Hwan Kim and posted to the IETF repository.

Filename:        draft-nsri-avtcore-aria-srtp
Revision:        00
Title:           The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)
Creation date:   2012-02-22
WG ID:           Individual Submission
Number of pages: 10

Abstract:
  This document describes the use of the ARIA block cipher algorithm
  within the Secure Real-time Transport Protocol (SRTP) for providing
  confidentiality for the Real-time Transport Protocol (RTP) traffic
  and for the control traffic for RTP, the Real-time Transport Control
  Protocol (RTCP).  It details three modes of operation (CTR, CCM, GCM)
  and a SRTP Key Derivation Function for ARIA.




The IETF Secretariat

_______________________________________________
Audio/Video Transport Core Maintenance
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |

Gmane