Subject: Re: [AVT] RE: draft-ietf-avt-evrc-04.txt

From: Stephen Casner <[email-masked]>
Date: Mon, 2 Jul 2001 19:22:01 -0700 (PDT)

I think there may be some confusion here regarding the meaning of
"talkspurt".  The M bit is intended to be set on the first packet
after a period when frames/packets were intentionally not
transmitted.  This is normally at the end of a period of silence.

For applications where a frame is transmitted for every frame time,
even when some frames convey silence (either with a full-size frame or
a reduced-size frame), the M bit would never be set.  Therefore Pete
need not be concerned.

I agree with Colin that it is wrong to assume that the EVRC codec
would only be used in applications where a frame is transmitted in
every frame time.  It could just as easily be used in other
applications that are more interested in saving packets and therefore
allow the noise frame to be repeated by the receiver.  Like some day
in the distant future when we are ready to really make a generational
step in cellular telephony instead of asymptotically approaching it.

							-- Steve

On Thu, 28 Jun 2001, Colin Perkins wrote:

> --> "Adam Li" writes:
> >Hi,
> >
> >Would it be allright to incorporate the paragraph from Peter into the draft
> >(with MAY changed to SHOULD as below)? Or should we put in some text to
> >discuss the circumstance of header compression which we have been trying to
> >avoid so far? Your comment is very apprecated.
>
> I think it should explain the circumstances when you may not want to use
> the M bit - right now the text implies that it won't ever be used.
>
> Colin
>
>
>
>
>
> >Adam
> >
> >"Although the sender SHOULD set the Marker bits in the RTP header to signal
> >the beginning of a talk spurt, it is not required to do so. EVRC codecs
> >generate data continuously and do not perform silence suppression.  Instead
> >EVRC encodes the noise components of the silence and outputs corresponding
> >16-bit frames. Receivers may detect silence, if necessary, by looking for a
> >sequence of 16-bit frames."
> >
> >
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[email-masked]]
> >> Sent: Wednesday, June 20, 2001 2:34 PM
> >> To: Pete McCann
> >> Cc: Adam Li; [email-masked]
> >> Subject: Re: draft-ietf-avt-evrc-04.txt
> >>
> >>
> >> MUST is not useful anyway, since the receiver always has to be
> >> able to cope
> >> with the absence of the M bit (e.g. if packet loss happens).
> >> Colin
> >>
> >> --> Pete McCann writes:
> >> >
> >> >Hi, Colin,
> >> >
> >> >I think my latest suggestion to Adam was the following:
> >> >
> >> >"Although the sender MAY set the Marker bits in the RTP header to
> >> > signal the beginning of a talk spurt, it is not required to do so.
> >> > EVRC codecs generate data continuously and do not perform silence
> >> > suppression.  Instead EVRC encodes the noise components of the
> >> > silence and outputs corresponding 16-bit frames.  Receivers may
> >> > detect silence, if necessary, by looking for a sequence of 16-bit
> >> > frames."
> >> >
> >> >So I think we are debating the difference between a SHOULD and a MAY.
> >> >I would not be too upset with SHOULD as long as we do not go all the
> >> >way to MUST.
> >> >
> >> >-Pete
> >> >
> >> >Colin Perkins <[email-masked]> (CP) writes:
> >> >
> >> >CP> Only if your compression is unaware of the media (if the
> >> compression is
> >> >CP> aware, it can reconstruct the M bit with zero overhead).
> >> >
> >> >CP> However, the main issue is that not all uses of EVRC will be
> >> over such
> >> >CP> constrained channels. It would be better for the draft to be
> >> consistent
> >> >CP> with the other payload formats, saying that you SHOULD set the marker
> >> >CP> on the first packet of a talkspurt, and explain the
> >> circumstances where
> >> >CP> this is undesirable.
> >> >
> >> >CP> Colin
> >> >
> >>
> >>
> >
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >[email-masked]
> >http://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> http://www.ietf.org/mailman/listinfo/avt

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

---

From: "Adam Li" <[email-masked]>
Date: Mon, 2 Jul 2001 23:52:06 -0700

Thank you very much for the clarification, Steve.

Maybe we could simply drop the sentences in the draft on the M-bit, and
imply that M bits should be be set as sepcified in RFC 1889? If the sender
keeps transmitting the codec frames, the M bit will never be set.

Please let me know what you think. Thanks,

Adam

> From: Stephen Casner [mailto:[email-masked]]
> Sent: Monday, July 02, 2001 7:22 PM
> To: Colin Perkins
> Cc: Adam Li; Pete McCann; Ietf-Avt
> Subject: Re: [AVT] RE: draft-ietf-avt-evrc-04.txt
>
>

---

From: Stephen Casner <[email-masked]>
Date: Thu, 5 Jul 2001 15:43:32 -0700 (PDT)

Adam,

> Thank you very much for the clarification, Steve.

It seems that the introduction of the phrase "or comfort noise
packets" in Section 4.1 of draft-ietf-avt-profile-new served to reduce
clarity rather than enhance it.  I will try to make that paragraph
more clear.

> keeps transmitting the codec frames, the M bit will never be set.

Yes, I think that would be best.  Rather than "imply", you could state
explictly that the M bit should set as specified in the applicable RTP
profile, for example, RFC 1890.  In fact, both 1890 and profile-new
say that the M bit is set to zero if silence is not suppressed ("MUST"
in profile-new).
							-- Steve

---

From: Pete McCann <[email-masked]>
Date: Mon, 9 Jul 2001 18:03:31 -0500 (CDT)

Hi,

This approach is fine with me - I would like to keep the extra
clarification sentence, for example:

    The M bit should be set as specified in RFC 1890.  Note that if
    the sender does not suppress silence (i.e., sends a frame on
    every 20 millisecond interval) the M bit will always be zero.

-Pete

Stephen Casner <[email-masked]> (SC) writes:

SC> Adam,
>> Thank you very much for the clarification, Steve.

SC> It seems that the introduction of the phrase "or comfort noise
SC> packets" in Section 4.1 of draft-ietf-avt-profile-new served to reduce
SC> clarity rather than enhance it.  I will try to make that paragraph
SC> more clear.

>> keeps transmitting the codec frames, the M bit will never be set.

SC> Yes, I think that would be best.  Rather than "imply", you could state
SC> explictly that the M bit should set as specified in the applicable RTP
SC> profile, for example, RFC 1890.  In fact, both 1890 and profile-new
SC> say that the M bit is set to zero if silence is not suppressed ("MUST"
SC> in profile-new).
SC> 							-- Steve

---

From: Stephen Casner <[email-masked]>
Date: Tue, 10 Jul 2001 00:33:03 -0700 (PDT)

>     every 20 millisecond interval) the M bit will always be zero.

Fine, except that the payload format may be used with profiles other
than RFC 1890 in the future.  To add this generality, I suggest:

    The M bit should be set as specified in the applicable RTP
    profile, for example, RFC 1890.  Note that RFC 1890 specifies that
    if the sender does not suppress silence (i.e., sends a frame on
    every 20 millisecond interval) the M bit will always be zero.

							-- Steve