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

[Ballot comment]
In response to Allison's request for a relevant media gateway reference, I've always liked the RFC2719 definitions of the terms and the depicted architecture. I'd probably reference that, rather than something specific to MGCP or Megaco.

On the draft, well, the mind does boggle a bit at the need for clear-channel ISDN to be encapsulated over RTP. It would be like, say, encapsulating IP over MIME, or something silly like that. I agree with Ted's suspicion that this is difficult to differentiate from application/octet-stream, especially given that clear-channel is not meant to be converted back into audible sounds.

[Ballot discuss]
Fundamentally, I'm wondering why this is considered "audio/clearmode".  If I understand
this correctly, this is packetized ISDN data.  I understand that this will eventually be
used by the ISDN speach terminals and so will become audible sounds at some point,
but it seems like the treatment they really want is closer to "application/octet-stream"
with specific parameters.  I'm not suggesting they use "application/octet-stream", but
I am bit concerned that this mime type isn't a good fit.  Can we discuss this briefly on
the call?

[Ballot discuss]
The Security Considerations section says:
  >
  > Confidentiality of the media streams is achieved by encryption.
  >
  This is obviously correct, but it would be more helpful to say what security
  protocol ought to be used.  I suspect SRTP, but I am not sure since a MIME
  type is also registered.  Are there cases where S/MIME can be used?  Also,
  where do the keys come from to perform the encryption?

[Ballot comment]
Allison's comment seems to indicate that there were a number of technical
issues with the -04 version that should have been resolved during
IETF Last Call, but the -04 version seems to be on our agenda for evaluation.  Should we be waiting for an -05?

[Ballot discuss]
The 2nd paragraph of the Security Considerations is not sufficient.
  What protocol is to be used, STRP?  If so, then say it and provide a
  reference.  Where do the keys come from to perform the encryption?

[Ballot comment]
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)