Subject: Re: [AVT] RTP No-Op and AVP Feedback

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Nov 2005 19:50:18 -0800

Dan,

On 14 Oct 2005, at 17:11, Dan Wing wrote:
...
>>  o  For unicast sessions, the reduced value MAY be used by
>>     participants that are not active data senders as well,
>>     and the delay before sending the initial compound RTCP
>>     packet MAY be zero.
>
> the authors consider it appropriate for RTP No-Op's "Request Early
> RTCP" bit to allow unicast sessions which support RTP No-Op in offer /
> answer to send RTCP reports immediately upon receipt of a No-Op packet
> with the "Request Early RTCP" bit set.  We need to adhere to section
> 6.2 of RFC3550 and the rules of whatever profile we're using, but we'd
> like to remove the requirement that No-Op can only use AVPF.
>
> Any comments on this direction?

You need to be careful to avoid implosion, in case the session has  
many members. This can occur even if you have a unicast connection,  
since you might be talking to an RTP translator, so something like  
the AVPF timing rules is needed.

Colin

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 07 Nov 2005 14:03:15 -0500

> the AVPF timing rules is needed.

Fair enough. So if we add careful wording to that effect, we can then 
use RTP No-Op with with RTP profiles other than *AVPF, e.g. RTP/AVP or 
RTP/SAVP ?

-- Flemming

---

From: Colin Perkins <[email-masked]>
Date: Mon, 7 Nov 2005 18:19:44 -0800

On 7 Nov 2005, at 11:03, Flemming Andreasen wrote:
>> You need to be careful to avoid implosion, in case the session  
>> has  many members. This can occur even if you have a unicast  
>> connection,  since you might be talking to an RTP translator, so  
>> something like  the AVPF timing rules is needed.
>
> Fair enough. So if we add careful wording to that effect, we can  
> then use RTP No-Op with with RTP profiles other than *AVPF, e.g.  
> RTP/AVP or RTP/SAVP ?

Why would you want to? The wording would need to be copied verbatim  
from AVPF, so why not just use AVPF?

Colin

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 07 Nov 2005 22:44:17 -0500

Colin Perkins wrote:

>>> many members. This can occur even if you have a unicast  

Two reasons:
1. We don't need all the capabilities of AVPF, just the RTCP feedback 
scheduling rules.
2. Current limitations with use of SDP and SIP which effectively 
prevents us from offering and negotiating use of one of several possible 
profiles. We don't have that same problem with multiple payload types 
within a single RTP profile.

-- Flemming

---

From: Joerg Ott <[email-masked]>
Date: Thu, 10 Nov 2005 01:28:04 +0200

> 1. We don't need all the capabilities of AVPF, just the RTCP feedback 

Please elaborate on all the other capabilities you would get -- aka
have to implement -- and surely not need.

> within a single RTP profile.

We have gone through the issue of alternate profiles repeatedly in
MMUSIC.  I am surprised to see this coming up as a counter-argument.

Here is some text from sdp-new-25 that should allow you doing so
(this came up from some text in the offer-answer-examples quite
a while ago):

       The combination of ports specified in "m=" lines and IP addresses
       specified in "c=" lines MUST comply with the following rules for
       RTP-based media streams (other protocols SHOULD define similar
       rules):

       1.  If two media sessions have the same transport address (i.e.
           identical IP address and port numbers), the associated payload
           types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be in
           conflict, i.e. the same payload type MUST NOT be mapped to
           different media types.

       2.  If two media sessions have the same transport address, they
           MUST use compatible media (e.g. both audio or both video).

       3.  If two media sessions have the same transport address, they
           SHOULD operate under the same RTP profile.  The sessions MAY
           use two different RTP profiles only if those profiles are
           specifically designed to be compatible.

       4.  If two media sessions have the same RTP transport address,
           they MUST also use the same RTCP address and vice versa.

       Two media sessions with the same transport address indicate
       alternatives for the same media stream, i.e. all profiles, media
       types, and payload types provided in any of the "m=" lines are
       valid.

I would also like to point out that you may want to signal explicitly
certain conditions such as redefined RTCP timing rules rather than
deciding on the fly when switching payload types.

Joerg

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 10 Nov 2005 15:19:38 -0500

> have to implement -- and surely not need.
The feedback messages and rules for when to include them (or not). The 
only thing from AVPF we need here is the RTCP timing and scheduling 
considerations that enable us to operate in immediate feedback mode and 
hence generate an RTCP report packet when requested (subject to AVPF 
rules).

>> prevents us from offering and negotiating use of one of several 
>> possible profiles. We don't have that same problem with multiple 
>> payload types within a single RTP profile.
>
>
The issue comes up regularly and we have yet to properly document (and 
probably even agree) a solution on how to deal with it (multipart MIME, 
grouping, other alternatives), so this should not come as a surprise (I 
know your opinion on this, but unfortunately, it doesn't solve the real 
problems we are faced with in practice).

> (this came up from some text in the offer-answer-examples quite

Indeed it did, more specifically in Vienna (2003). From the minutes:

<quote>
Alan Johnston presented the changes to the document: in particular, an
example for asymmetric use of a codec has been added.  This is to be
achieved using two distinct m= lines with the same port number, one
indicating "sendonly", the other "recvonly".  The proposed behavior
caused some discussion: it was felt that the mechanism was
underspecified and that (therefore) m= lines with the same port would
be a bad idea.  Yet, the right approach to achieve the desired
behavior seemed unclear.  Gonzalo Camarillo pointed out that the
RFC3388 provided a similar example, but with an explicit grouping
(which is not present in this draft).  The applicability of RFC3388 to
this problem was discussed further.  Orit Levin pointed out that the
intention clearly is to use RFC 3388 but the question is what happens
to the endpoints that don't support RFC 3388.  Gonzalo argued that
this is already defined in RFC 3388.  The chairs stated that they
would like to see the asymmetric codec behavior with two m= line
properly specified in a document.  The present offer/answer examples
draft is meant to be illustrative; the example should be kept in place
(with added grouping) but the normative text for this behavior needs
to be someplace else.  Flemming Andreasen suggested to specify part of
this practice in the revised SDP.
</quote>

>       types, and payload types provided in any of the "m=" lines are
As I noted in a (currently unanswered) posting to the MMUSIC list on 
10/19, there are numerous problems with this text and I believe it is 
counter to previous consensus in this area, but we should probably 
continue that part of the discussion on the MMUSIC list. Once we have 
settled that, we can then continue discussing how it does or does not 
help with the current RTP No-Op AVPF problem.

> deciding on the fly when switching payload types.
Whether it is signaled by use of the string "RTP/AVPF", "RTP/SAVPF" or 
some other AVPF profile variant or by inclusion of a payload type with a 
corresponding rtpmap indicating "no-op" seems immaterial - it is 
explicit in either case. RTP No-Op essentially says to provide the 
immediate feedback if so allowed by RTCP rules (as defined by AVPF) - it 
doesn't actually those timing rules on the fly (however I think we are 
getting into a semantics game here).

-- Flemming