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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]