Subject: [AVT] Re: Question on 4.1 section of RFC3551

From: Stephen Casner <[email-masked]>
Date: Tue, 26 Aug 2003 13:27:14 -0700 (PDT)

On Tue, 26 Aug 2003, Henning Schulzrinne wrote:

> For example, in a conference bridge, it would be counterproductive to
> send CN packets for all but the active speaker(s). Also, IETF specs
> aren't product sales and training manuals - it is not the IETF's job to
> tell people that engineering systems without CN is generally a bad idea.
> Sending CN is not required for interoperability, so being too
> prescriptive doesn't seem helpful here.

I agree with Henning's sentiments here.  To go further, I would say
that the receiver SHOULD be prepared to work well even if CN is not
received, because it is always possible that the CN packet may be lost
even if it was sent.

Many miles were logged on the MBone tools (vat, RAT, NeVoT and
friends) with no CN.  You may choose to discount these as not be of
service grade, but they worked properly without requiring CN.  When we
have multicast sessions from the IETF meeting with hundreds of
participants, we were glad that those hundreds of participants weren't
sending CN all the time.  Yet at any point that any one of them wanted
to say something back to the session, the communication path was
ready.

                                                        -- Steve

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

---

From: "Oren Peleg" <[email-masked]>
Date: Tue, 26 Aug 2003 15:57:10 +0300

Hi,

At 4.1 section of the RFC3551 it is written:
"Some payload formats (see Sections 4.5.3 and 4.5.6) 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."
Shouldnt it be mentioned that a CN packet (of any format) SHOULD be used on silence detection?
There is a reference to "applications which send either no packets or occasional comfort- noise packets during silence" Since G711 AppendixII specify CN for G711 (and even recommend using in other coders without Built-in Silence compression), What kind of application is it that does not send any packet during Silence? isnt it contradicts the above section which suggests that the RFC3389 is a valid option for payload format who does not have CN capabilities?
Thanks,

Oren Peleg

Work phone No. : 03 - 5394167
Home phone No. : 03 - 5335913
Cell phone No. : 055 - 669613
Email : [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Aug 2003 09:08:38 -0400

Oren Peleg wrote:

> "Some payload formats (see Sections 4.5.3 and 4.5.6) 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."
> 
> There is a reference to "applications which send either no packets or 
> occasional comfort- noise packets during silence" Since G711 AppendixII 
> specify CN for G711 (and even recommend using in other coders without 
> Built-in Silence compression), What kind of application is it that does 
> not send any packet during Silence? isnt it contradicts the above 
> section which suggests that the RFC3389 is a valid option for payload 
> format who does not have CN capabilities?
> 
> Thanks,
> 
> Oren Peleg
>