Subject: [AVT] Questions Re:draft-ietf-avt-rtp-cn-04.txt

From: [email-masked]
Date: Wed, 24 Oct 2001 12:32:56 +0200

Hi Robert,

A couple of quick questions about the draft:

 - The static payload type value of 13 is different from the value 19 
specified in earlier draft revisions of RFC1890 for CN, though the payload 
format is compatible as you mention.  Was there a particular reason for 
the static payload type value change? (the mailing list archives don't 
seem to go back far enough to the time of your original draft 00).

 - I heard about implementations that use PCMA or PCMU payload type for 
CN, and makes a voice/CN decision based on payload length.  Reading your 
draft this goes against the SHOULD words, and also could run into real 
problems if ever the CN length got up to about 40 (even though I doubt 
this will ever happen).  I just wanted verify that this is not the way to 
do things, and see if anyone on the list would speak up and defend it.

Thanks,
Michael.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 24 Oct 2001 11:08:45 -0400

>seem to go back far enough to the time of your original draft 00).

We moved the mailing list, but the archives of the old list are still
available at ftp://ftp.es.net/pub/mail-archive/rem-conf

Cheers,
Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: "Robert Zopf" <[email-masked]>
Date: Wed, 31 Oct 2001 20:07:40 -0500

Michael,

The payload type value did flip flop as you mention.  However, I cannot
remember the history behind why.  I think Stephen or Colin could answer.  By
the time I wrote the first draft, the value was 13.

Regarding alternate solutions to comfort noise, I would imagine there were
many different schemes to overcome the inability to transfer anything but
energy.  Many of these schemes may be capable of delivering quality
equivalent to that capable with the draft.  The difference being those
schemes are proprietary and are incompatible with each other (in general).
Using one of these schemes with another vendor will result in unpredictable
quality at the far end.

Rob.

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
  Sent: Wednesday, October 24, 2001 6:33 AM
  To: [email-masked]
  Cc: [email-masked]
  Subject: [AVT] Questions Re:draft-ietf-avt-rtp-cn-04.txt

  Hi Robert,

   - The static payload type value of 13 is different from the value 19
specified in earlier draft revisions of RFC1890 for CN, though the payload
format is compatible as you mention.  Was there a particular reason for the
static payload type value change? (the mailing list archives don't seem to
go back far enough to the time of your original draft 00).

   - I heard about implementations that use PCMA or PCMU payload type for
CN, and makes a voice/CN decision based on payload length.  Reading your
draft this goes against the SHOULD words, and also could run into real
problems if ever the CN length got up to about 40 (even though I doubt this
will ever happen).  I just wanted verify that this is not the way to do
things, and see if anyone on the list would speak up and defend it.

  Thanks,
  Michael.