RTP Payload Format for a 64 kbit/s Transparent Call
draft-ietf-avt-rtp-clearmode-05

AD Review comments (during Last Call on 04 draft):

First, it would be nice to know, as it was also mentioned during the AVT
list discussion, what pwe3 draft is talking about nx64 clearmode?

Next, I reviewed the clearmode draft and it seems reasonable to go ahead
with its Last Call, but during the Last Call period the following
issues should be addressed:

1.

   Voice over IP (VoIP) media gateways need to carry all data streams
   generated by analog or integrated services digital network (ISDN)
   terminals via an IP network.

   ISDN wideband speech terminals do not rely on a voice data
   processing, like echo cancellation or dual tone multifrequency (DTMF)
   detection, within a VoIP media gateway.  Moreover, ISDN data
   terminals e.g. will produce data streams that are not compatible with
   a non-linear encoding as is used for voice.

This introduction is written somewhat tersely, and it's confusing.  Could
the second paragraph be expanded as follows?

    ISDN wideband speech terminals in particular within VoIP media gateways
    do not perform voice data processing, such as echo cancellation or dual
    tone multifrequency (DTMF) detection.  Moreover, ISDN terminals also
    produce data streams that are not compatible with a non-linear encoding,
    such as is used for voice on non-ISDN VoIP terminals.

What's confusing here:  is the application ISDN -> IP Trunk -> ISDN, or
is it ISDN -> IP PhoneNet.  I think the text must describes the former,
just not clearly enough.   So the first paragraph needs a rewrite too.
Maybe something like:

    One important application of VoIP media gateways is to carry many
    data streams generated by analog or ISDN terminals through IP network
    trunks to other media gateways.

    ISDN wideband speech terminals in particular within VoIP media gateways
    do not perform voice data processing, such as echo cancellation or dual
    tone multifrequency (DTMF) detection.  Moreover, ISDN terminals also
    produce data streams that are not compatible with a non-linear encoding,
    such as is used for voice on non-ISDN VoIP terminals.

Also missing:  a reference to a document describing media gateways/ISDN
applications.  Maybe an Informative reference to an MGCP package?  It doesn't
look like there's an obvious MEGACO reference for this.  Jon?

2.

What reason is there to permit known-larger-than-MTU packets?
The reassembly or loss hit from fragmentation would be damaging,
especially if timing recovery is a goal.  MTU is a poor guide in many
cases too, given tunnels, SRTP and IPSec, all of which may reduce the
effective MTU in ways the sender is blind to.  It seems much wiser to
make a MUST for this, and also to reflect the MTU problem:

What's there now:

   The number of samples SHOULD be less than the path maximum
   transmission unit (MTU) minus combined packet header length.

Suggestion:

   The number of samples MUST be less than the path maximum
   transmission unit (MTU) minus combined packet header length.
   If the environment is expected to have tunnels or security
   encapsulation as part of operation, the number of samples SHOULD
   be reduced to allow for the extra header space used for those.

3.

In the Security Considerations,

   Confidentiality of the media streams is achieved by encryption.

Make this a reference to SRTP.

I'll leave the security area to give thorough review to the discussion of
denail of service avoidance - though I wonder if the assessment asks the right
questions.  Packet-level auth - AH - yes, that may be difficult.  But
ESP in authentication mode, which would cover the RTP headers, can be very
fast, and it would serve the same purposes.

4.

Boilerplates - when you revise at the end of Last Call (depending on what
you make of these AD comments, and others you may get), you should update the
copyright and ipr officialese to the new ones from
draft-ietf-ipr-submission-rights-08.txt, which was approved a few months
back, so now we ADs are letting people know.  Here are the new boilerplates:

"By submitting
this Internet-Draft, I certify that any applicable patent or other IPR
claims of which I am aware have been disclosed, and any of which I
become aware will be disclosed, in accordance with
draft-ietf-ipr-submission-rights-08.txt."   (instead of Section 9)


and

"Copyright (C) The Internet Society (year). This document is subject
to the rights, licenses and restrictions contained in RFC XXXX
(draft-ietf-ipr-submission-rights-08.txt) and except as set forth
therein, the authors retain all their rights."  (instead of Section 10)