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 tsv-dir@xxxxxxxx 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/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf