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

From: Stephen Casner <[email-masked]>
Date: Wed, 27 Aug 2003 08:28:28 -0700 (PDT)

On Wed, 27 Aug 2003, Oren Peleg wrote:

> Yet, if a CN is present you can distinguish between silence or
> unknown state of the session connection & you can use a CNG to give
> better QoS to the listener.  Your point is well taken - Off course
> the receiver SHOULD be robust, but still, In a Coder point of view,
> (I am not sure this working group is the right address, but still
> ..) there is the G711 Appendix II which defines silence
> compression. Or should I ask, when stopping the packet sending due
> to silence, what is the standard used for doing so?

None other than RFC 3551.

                                                        -- Steve

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

---

From: "Oren Peleg" <[email-masked]>
Date: Wed, 27 Aug 2003 10:33:40 +0300

Yet, if a CN is present you can distinguish between silence or unknown state of the session connection & you can use a CNG to give better QoS to the listener.  Your point is well taken - Off course the receiver SHOULD be robust, but still, In a Coder point of view, (I am not sure this working group is the right address, but still ..) there is the G711 Appendix II which defines silence compression. Or should I ask, when stopping the packet sending due to silence, what is the standard used for doing so?

Thanks,

Oren P.

-----Original Message-----
From: Stephen Casner [mailto:[email-masked]]
Sent: Tuesday, August 26, 2003 11:27 PM
To: Henning Schulzrinne
Cc: Oren Peleg; [email-masked]
Subject: Re: Question on 4.1 section of RFC3551

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