RE: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

"Magnus Westerlund (EAB)" <Magnus.Westerlund@era.ericsson.se> Tue, 25 February 2003 18:09 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08943 for <avt-archive@odin.ietf.org>; Tue, 25 Feb 2003 13:09:05 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PIIBO18756 for avt-archive@odin.ietf.org; Tue, 25 Feb 2003 13:18:11 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIHDp18696; Tue, 25 Feb 2003 13:17:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIFkp18636 for <avt@optimus.ietf.org>; Tue, 25 Feb 2003 13:15:46 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08861 for <avt@ietf.org>; Tue, 25 Feb 2003 13:06:08 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PIA1Ye006082; Tue, 25 Feb 2003 19:10:01 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <FD4HHBHY>; Tue, 25 Feb 2003 19:09:56 +0100
Message-ID: <034BEFD03799D411A59F00508BDF754602BF4174@esealnt448.al.sw.ericsson.se>
From: "Magnus Westerlund (EAB)" <Magnus.Westerlund@era.ericsson.se>
To: 'Alan Clark ' <alan@telchemy.com>, ''Timur Friedman' ' <timur.friedman@lip6.fr>
Cc: "'avt@ietf.org '" <avt@ietf.org>
Subject: RE: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt
Date: Tue, 25 Feb 2003 19:05:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1PIFlp18637
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi Alan,

My comment is that the XR does not need to consider all applications, only what is necessary in relation to the XR format. From my perspective it seems that my proposed attrbiutes for the XR report is covering this. 

To my knowledge the necessary signalling is in place for all other types of RTCP reporting. The AVPF defines SDP attribute that allows control of the usage of the formats within that proposal. So I don´t think arguing that it is a general problem would lessen the need for SDP attributes in regards to XR formats. 

By supporting SDP you support the basic signalling that are currenlty in use by the most common real-time media applications using RTP/RTCP. SIP uses SDP, RTSP uses SDP. 

So my view is still that providing the basic SDP functionality outlined in my initial mail we have all functionality currently needed. 

Best Regards

Magnus Westerlund


-----Original Message-----
From: Alan Clark
To: 'Timur Friedman'; Magnus Westerlund (EAB)
Cc: avt@ietf.org
Sent: 24.02.2003 20:27
Subject: RE: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt


Magnus' suggestion of providing a means for signalling to indicate that
RTP
XR reports are required, the type and frequency of report, is a useful
one.
I would suggest however that:

(i) This would be useful for a variety of different feedback mechanisms
-
including RTP XR, RTCP and potentially others

(ii) There may be other protocols than SDP that would be more
appropriate
for negotiating feedback in different applications.

These would both seem to suggest that it may be preferable to develop
such
functionality but to keep it independent from RTP XR.  We should also
review
the RTP XR draft to ensure that it is amenable to being negotiated.

The new draft could cover the following:-

- general framework for real time feedback
- reference to available report types
  - RTCP
  - RTP XR
  - video?
  - .....
- protocol independent model for report negotiation
- specific protocol implementations
  - SDP
  - SIP?
  - H.xxx?
  -

As Magnus comments, there are applications such as streaming which have
particular requirements.  We need to consider other applications such as
conferencing, multicast, broadcast.... to see what would make sense
(e.g. in
a broadcast application would you still want to negotiate feedback with
a
sample population of receivers?).  Trying to cover the range of
potential
applications within the RTP XR draft could make it overly complicated.

Regards

Alan Clark
Telchemy

-----Original Message-----
From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Timur
Friedman
Sent: Monday, February 24, 2003 1:44 PM
To: 'Magnus Westerlund'
Cc: avt@ietf.org
Subject: RE : RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt


Hello Magnus,

> I think that signaling is fundamental enough to this draft that it
> warrants to put it in directly. I would also not like to delay this
> draft. I would like to see it submitted to the IESG before May. I
think
> that is still possible, especially if you would add this functionality
> in a update that you can submit before mondays cut-off date. You can
> take my text and rework it into suitable text for your draft. Then we
> can have a healthy discussion on this in San Francisco. Then after the
> meeting update the draft if any comments has been given. The have a WG
> last call in early April. There is no need to either ask or have WG
last
> calls in relations to meetings. It might even be better as people will
> have more time to read the document.

There is no question in my mind that it would be a plus to specify SDP
signalling for RTP XR reports.  Of course until the precise form is
settled, there is nothing to stop applications from experimenting with
different signalling approaches.

My hesitation is whether the signalling text that you suggest is settled
enough to paste into the document between now and the Monday deadline.
We should really solicit the opinions of others on the list.  Have a
number of people experienced in the issues surrounding signalling had a
chance to go over the text and say that it is solid in its present form?

Regards,

Timur

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt