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

Re: [AVT] Profile: Silence suppression is allowed by default



I think this addition is great. I have seen this issue come up all the time. Some comments on the wording inline:

Stephen Casner wrote:

To make this more explicit, I added the following paragraphs at the
beginning of Section 4.1 in the A/V profile:

Since the ability to suppress silence is one of the primary
motivations for using packets to transmit voice, the RTP header
carries both a sequence number and a timestamp to allow a receiver to
distinguish between lost packets and periods of time when no data was
transmitted. Discontiguous transmission (silence suppression) MAY be
used with any audio payload format. Receivers MUST accept silence
suppression unless its use is restricted by signaling specified
elsewhere.
Since silence suppression is just the absence of packets, its not clear what it means to "accept" it.

(Even if the transmitter does not suppress silence, the
   receiver must be prepared to handle periods when no data is present
   since packets may be lost.)
This sentence and the previous appear contradictory to me. The previous says that you won't need to handle silence suppression if signaling says its not in use, but this sentence says you need it anyway.

I would propose the last two sentences be replaced with:

Receivers MUST be prepared to handle the absence of packets for an arbitrary period of time in order to accomodate silence suppression at the sender. This applies even if silence suppression is not in use (which can be known to the receiver through signaling, outside the scope of this specification), because packet loss cannot be distinguished from silence suppression.


   Some payload formats define a "silence insertion descriptor" or
   "comfort noise" frame to specify parameters for artificial noise that
   may be generated during a period of silence to approximate the
   background noise at the source.  For other payload formats, a generic
   Comfort Noise (CN) payload format is specified in RFC 3389 [9].  When
   the CN payload format is used with another payload format, different
   values in the RTP payload type field distinguish comfort-noise
   packets from those of the selected payload format.
I assume [9] is an informative reference, not normative.

In addition, I added the following first sentence in the four places
where the sentences similar to the second one appear in G723 and G729*:

   Receivers MUST accept comfort noise frames if restriction of their
   use has not been signaled.  The MIME registration for G729 in
   RFC YYYY [7] specifies a parameter that MAY be used with MIME or SDP
   to restrict the use of comfort noise frames.
Presumably RFC YYYY [7] will be at proposed. The above text seems to me to provide a normative reference to that specification. A draft standard cannot have a normative reference to a proposed standard.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt