TSV review of draft-ietf-sipping-rtcp-summary-08

[Colin Perkins <[e-mail]>]

I've reviewed this document as part of the transport area  
directorate's ongoing effort to review key IETF documents. These  
comments were written primarily for the transport area directors, but  
are copied to the document's authors for their information and to  
allow them to address any issues raised. The authors should consider  
this review together with any other last-call comments they receive.  
Please always CC [e-mail] if you reply to or forward this  
review.

This document defines a SIP event package to enable reporting some  
RTCP XR metrics, in particular those deemed relevant to some classes  
of VoIP application.  The metrics reported are a subset of those  
defined in RFC 3611, plus some extensions. This is a potentially  
useful specification, but I believe there are a number of problems  
with the way it interacts with RTP which I recommend be addressed  
before publication.

The applicability statement (section 1.1) references the list of RTP  
topologies in RFC 5117, and states that only the first (point-to- 
point) sessions is relevant to this document. The Usage Scenarios  
(section 1.2) and the rest of the document contradict this, discussing  
point-to-point sessions, conference calls using a central conferencing  
server, and multicast VoIP calls using SSM. RTP is inherently a group  
communication protocol, and this document needs to properly consider  
the full range of topologies defined in RFC 5117.

A large number of parameters are defined in Section 4.6:

The PayloadType parameter states that "IANA registered values SHOULD  
be used where possible", but the IANA registry only applies to the RTP/ 
AVP profile, and has been closed to new registrations for several  
years now. The implication of this document is that the payload type  
is sufficient to identify the codec, but this is not the case, and for  
this reason RFC 3551 recommends the use of media subtype names instead.

The PayloadDesc parameter is defined to provide a text description for  
the codec. It is stated that "The abbreviated standard name for the  
codec SHOULD be used (for example "G.729A")". The IETF has a standard  
namespace for codecs, in the form of media subtypes, registered  
according to RFC 4855. I believe it would be a mistake to introduce  
another, ill-defined, namespace in this document, rather than using  
the standard media type names as used for all other RTP-related  
documents.

Several parameters are defined relating to frame-based codecs (e.g.  
FrameDuration, FrameOctets, and FramesPerPacket). However, not all RTP  
audio payload types are frame based (see RFC 3551, section 4.3). It is  
not clear how sample based codecs are handled.

The FmtpOptions parameter is defined to convey "FMTP options from  
SDP". These options are parameters of media subtypes, and don't make  
sense unless the PayloadDesc is specified as a media subtype (and  
don't make any sense if just PayloadType is specified, since they're  
related to a media subtype name, not a payload type).

The MetricType parameter is ill-defined. What do the values specified  
refer to, and how are new values to be registered?

The LocalAddr and RemoteAddr parameters assume that STUN is used as a  
NAT traversal mechanism, if one is needed. While I agree with the  
principle of reporting the address on the "outside" of the NAT, STUN  
is not always available.

Section 4.6.2.9.5 expresses interarrival jitter as defined in RFC 3550  
in milliseconds, but RFC 3550 specifies it in RTP timestamp units.

Nit: In the last sentence of the introduction, "Real-Time Control  
Protocol" should be "RTP Control Protocol".

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