Subject: [AVT] Draft-ietf-avt-rtcp-feedback-00.txt - Use of RTP profiles

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jul 2001 13:50:20 +0200

Hi,

Good that this draft finally appeared. I have comments regarding rather
different aspects of the draft, therefore I will write several emails:

One of the major issues I believe is the usage of the RTP profiles. So
far there has only been one profile, namely the Audio and Video Profile
(AVP) which defines behavior of RTP regarding handling of video and
audio. But currently there is at least two new profiles (feedback and
Secure RTP) under discussion and more seem to be on the way. In the
feedback draft they have suggested that this profile should be based on
AVP and be named AVPF in short. These new profiles are different in some
ways from AVP. Both feedback and SRTP defines extended capabilities of
RTP/RTCP, which are  not closely related to any media class or type.

First how should you combine all these profiles? One solution which I
don't think is a good one or flexible at all is to give each combination
a new name. It would require that you have at least the following names
for AVP, feedback and SRTP: AVP, SRTP(Only security profile), AVPS,
AVPF, AVPFS(Secure audio video profile with RTCP feedback). This will
exploded as more profiles are created.

Secondly should this draft be based on AVP at all? I think it should be
defined as a stand alone profile so you can use it with out the baggage
of AVP. If some of the payload specific formats require AVP write it in
for just that payload format specific feedback, not the entire
framework. This would allow it to be more easily used in or togheter
with future profiles.

My suggestion for a solution to this problem of combining profiles is
the following. Make profiles as stand alone as possible if they are not
obvious extensions of existing profiles. Allow in SDP the possibility to
easy express combinations of profiles. For this it would be good it you
could write a SDP media line like this.
m=audio 49120 RTP/AVP/RFB/SRT 97
This would mean: Use RTP with the AVP, RTCP feedback (RFB) and Secure
RTP (SRT) profiles.

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: "Anders Klemets" <[email-masked]>
Date: Thu, 19 Jul 2001 13:31:15 -0700

I have some additional comments regarding the new "RTP/AVPF" profile:
The way the SDP syntax is defined in this Draft, makes it difficult to
deploy the feedback mechanism in scenarios where not all participants
support RTP/AVPF. 

The "m=audio 0 RTP/AVPF 0" notation will probably cause receivers that
do not recognize "AVPF" to skip that media entry in the SDP.
Unfortunately, SDP does not have a way to negotiate capabilities.  So
there may be no way for a receiver to find out that the same media is
available using a different RTP profile, or to request that a different
RTP profile be used.

When a session is multicasted, it might be desireable to prohibit the
participation of receivers that do not understand the AVPF profile.
Such receivers could get confused by the Early/Immediate RTCP packets.

However, in a unicast scenario, such as when RTSP is used, there is no
problem if the server understands AVPF while the client does not.  But
if an RTSP client encounters "RTP/AVPF" in an SDP description, there is
no standardized way for it to tell the RTSP server to send it a new SDP
description that uses "RTP/AVP" instead.

So, it would be good if the SDP syntax in this document could be revised
so that AVPF could be used 
without requiring SDPng-style capability negotiation.

The first change that one could make would be to relax the use of the
text in section 3.7.2.1 to allow a unicast receiver to send feedback
packets even if the RTP profile has not been specified as "AVPF", as
long as the sender indicates through some other means that it knows how
to parse feedback packets.  For example, the presence of the "rtcp-fb"
SDP attribute could be used as an indication that the sender is willing
to accept Feedback packets, even though the "m=" line did not say
"RTP/AVPF".

However, the use of the "rtcp-fb" SDP attribute is another problem with
this Draft.  The Draft specifies that multiple "a=fmtp" attributes can
be specified for the same payload type.  (One of the attributes could
look like this: "a=fmtp:96 rtcp-fb nack".)  Even though this is
syntactically correct, it is possible that there are SDP parsers out
there that do not expect more than one "a=fmtp" specification per
payload type.  These parsers could fail in strange ways if there are
multiple "a=fmtp" for the same payload type.

A solution that is more likely to work with deployed SDP parsers would
use a new SDP attribute to express the same thing that the Draft wants
to use "a=fmtp" for.
For example, a new attribute could be used like this:  "a=rtcp-fb:96
nack"
This is guarateed not to cause any problems with already deployed SDP
systems.

Anders