Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtcphr-02.txt

From: Colin Perkins <[email-masked]>
Date: Sun, 2 Dec 2007 08:19:57 -0800

On 19 Nov 2007, at 19:15, [email-masked] 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 Working  
> Group of the IETF.
>
> 	Title		: RTCP HR - High Resolution VoIP Metrics Report Blocks
> 	Author(s)	: A. Clark, et al.
> 	Filename	: draft-ietf-avt-rtcphr-02.txt
> 	Pages		: 0
> 	Date		: 2007-11-19
> 	
> This document defines extensions to the RTCP XR extended report
>    packet type blocks to support Voice over IP (VoIP) monitoring
>    for services that require higher resolution or more detailed
>    metrics than those supported by RFC3611 [3].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcphr-02.txt

This draft seems to conflate three different things: new RTCP XR  
report blocks, discussion of RTCP operation through translators, and  
SDP attributes to signal RTCP profiles. To allow progress to be made  
on the less controversial parts of this work, I would strongly  
recommend that these issues be considered in three separate drafts.

On the subject of new RTCP XR report blocks, there are a number of  
issues:

1) Section 3.3.3 defines a dead connection detection mechanism, but  
standard RTCP RR packets can be used for this purpose.

2) Section 3.3 notes that for sample based codecs, frames are defined  
as "an RTP frame", but doesn't define what this (non-standard) term  
means (neither RFC 3550 nor RFC 3551 define this term).

3) Section 3.8.4 references an "RFC 3550 payload type" and the IANA  
registry of static payload types. RFC 3550 doesn't define a payload  
type namespace, and the IANA registry of RTP payload types has been  
obsolete for a decade now. An RTP payload type is only meaningful  
when tied to signalling, but this draft doesn't appear to reference  
how that is done.

4) Undefined "vendor extension" fields are not appropriate here.

In general, there seems to be no obvious reasoning behind the  
inclusion or exclusion of particular fields. Considerably more  
motivation, rationale, and justification is needed, discussing both  
VoIP telephony and wider applications of these extensions.

On the subject of RTCP use with translators, I'm not sure it's  
appropriate for an RTCP extension to define changes to the operation  
of RTP translators and mixers (since it cannot know the environment  
in which the RTCP extension may be deployed). Drafts giving guidance  
on how RTP translators and/or mixers can be used in particular  
environments are welcome (we have one in progress), but should be  
separate from the definition of RTCP report blocks, which are of more  
general use.

The signalling of "profiles" of RTCP use is extremely in this draft  
is of great concern. Dynamic allocation of RTCP packet type numbers  
through SDP attributes goes against existing practice, and the means  
to indicate that RTCP should not be used conflicts with current  
practice. No justification for these changes is given, and they do  
not seem desirable. I would strongly urge a rethink of this approach.  
However, if you wish to continue, the appropriate home is a separate  
draft, not a draft defining new RTCP report blocks.

-- 
Colin Perkins
http://csperkins.org/

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

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 3 Dec 2007 11:49:04 -0500

Colin

>This draft seems to conflate three different things: new RTCP XR report
blocks, discussion of RTCP operation through translators, and SDP attributes
to signal RTCP profiles. To allow progress to be made on the less
controversial parts of this work, I would strongly recommend that these
issues be considered in three separate drafts.

Rajesh Kumar and colleagues proposed this for "one way voice" detection -
I'll let Rajesh (or colleagues) respond on this point 

>2) Section 3.3 notes that for sample based codecs, frames are defined as
"an RTP frame", but doesn't define what this (non-standard) term means
(neither RFC 3550 nor RFC 3551 define this term).

Ok - this should be "RTP Packet"

>3) Section 3.8.4 references an "RFC 3550 payload type" and the IANA
registry of static payload types. RFC 3550 doesn't define a payload type
namespace, and the IANA registry of RTP payload types has been obsolete for
a decade now. An RTP payload type is only meaningful when tied to
signalling, but this draft doesn't appear to reference how that is done.

My impression was that there is always an RTP payload type identified
however this may be a default type as defined in RFC3551 or a dynamically
assigned type negotiated through SDP. Given that there may be multiple
payload types defined for use in an RTP Session and the endpoint can change
codec at any time, it appears to be useful to know the payload type being
used at the point that the report was generated.

>4) Undefined "vendor extension" fields are not appropriate here.

I'll let Rajesh comment on that point.

>In general, there seems to be no obvious reasoning behind the inclusion or
exclusion of particular fields. Considerably more motivation, rationale, and
justification is needed, discussing both VoIP telephony and wider
applications of these extensions.

Ok - we can add more text to discuss why particular fields are used - this
is certainly fairly easy to do in the context of VoIP however some guidance
would be useful in dealing with the wider applications.

>On the subject of RTCP use with translators, I'm not sure it's appropriate
for an RTCP extension to define changes to the operation of RTP translators
and mixers (since it cannot know the environment in which the RTCP extension
may be deployed). Drafts giving guidance on how RTP translators and/or
mixers can be used in particular environments are welcome (we have one in
progress), but should be separate from the definition of RTCP report blocks,
which are of more general use.

>The signalling of "profiles" of RTCP use is extremely in this draft is of
great concern. Dynamic allocation of RTCP packet type numbers through SDP
attributes goes against existing practice, and the means to indicate that
RTCP should not be used conflicts with current practice. No justification
for these changes is given, and they do not seem desirable. I would strongly
urge a rethink of this approach.  
However, if you wish to continue, the appropriate home is a separate draft,
not a draft defining new RTCP report blocks.

I'll let Geoff Hunt respond on these two points.

Regards

Alan

--
Colin Perkins
http://csperkins.org/

---

From: <[email-masked]>
Date: Mon, 3 Dec 2007 18:15:16 -0000

Colin, Alan, All,

On the subject of the two point below, about translator behaviour, and
profiles...

1) on the inclusion in the RTCP HR draft of proposals for RTCP behaviour
of translators and SDP control, we split the informational section
(which was in the last RTCP HR draft -01) out into
draft-hunt-avt-rtcptrans which is intended for Informational. As the
RTCP HR draft was a week later than rtcptrans, some later thinking (!)
did go into rtcphr which could be moved into rtcptrans. Problem is,
though, for any real set of metrics such as RTCP HR, some behaviour
needs to be defined normatively so can't be achieved by reference to the
rtcptrans draft (unless rtcptrans grows some normative aspects). Hope we
can cover this in the session today.

2) the text in Section 7.1 specifically about selection of the base RTCP
XR report block number "mmm" by SDP is a hang-over from an earlier draft
(we could check which one it first appeared in). It is not part of the
(new) proposal for control of RTCP HR using registered profiles. I think
it's wrong. The block types should be static IANA registrations in the
"RTCP XR Block Type Registry".

3) on the more general question of defining and registering profiles to
guide reporting behaviour, it's a way of using SDP in an economical way
to control potentially complex behaviours of RTP systems. I'm not aware
of any fundamental reasons why it's a bad thing to do, but if there are
any, then we'll have to find a better alternative. What is current
practice on how to indicate that RTCP should not be used? Perhaps we can
find a means to make the profile-based approach consistent with this
practice. Again, hope we can cover this during the session this
afternoon.

Regards
Geoff

>-----Original Message-----
>From: Alan Clark [mailto:[email-masked]] 
>Sent: 03 December 2007 16:49
>To: 'Colin Perkins'; 'AVT WG'
>Cc: [email-masked]; Hunt,RG,Geoff,DMM R
>Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtcphr-02.txt 

>>appropriate
for an RTCP extension to define changes to the operation of RTP
translators and mixers (since it cannot know the environment in which
the RTCP extension may be deployed). Drafts giving guidance on how RTP
translators and/or mixers can be used in particular environments are
welcome (we have one in progress), but should be separate from the
definition of RTCP report blocks, which are of more general use.

>>The signalling of "profiles" of RTCP use is extremely in this draft is

>>of
great concern. Dynamic allocation of RTCP packet type numbers through
SDP attributes goes against existing practice, and the means to indicate
that RTCP should not be used conflicts with current practice. No
justification for these changes is given, and they do not seem
desirable. I would strongly urge a rethink of this approach.  
However, if you wish to continue, the appropriate home is a separate
draft, not a draft defining new RTCP report blocks.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Dec 2007 18:12:13 +0000

On 3 Dec 2007, at 18:15, <[email-masked]> <[email-masked]> wrote:
...
> "RTCP XR Block Type Registry".

I agree they should be static registrations.

> practice. Again, hope we can cover this during the session this

I though the current practice was to set the RTCP bandwidth to zero,  
using the SDP b=RR: and b=RS: lines? (RFC 3556)

-- 
Colin Perkins
http://csperkins.org/