Subject: RE: [AVT] Question on Rate Reduction bit in EVRC RTP payload format

From: Pete McCann <[email-masked]>
Date: Fri, 7 Sep 2001 11:00:19 -0500

Kirti,

Answers below...

Kirti Gupta writes:
 > Hello All,
 > 
 > Thanks for your replies. However, I still have some questions in the light 
 > of what has been said in your emails.
 > 
 > 1. It seems that the reason for having the "D" bit (in band signalling) is 
 > that it is useful only for
 > -Point-to-point full duplex conversation (as stated in the draft).
 > But out of band signalling will still have to be used for all other scenarios.
 >
 > -When there us low latency between two gateways (as stated in Nikolai' reply)
 > And the reason for using the D bit is to be able to create room for 
 > signalling to reduce latency in an air interface. There seems to be a
 > contradiction here?

No contradiction, you might just not have understood the usage
scenario.  In my example, there was an RTP stream running from BSC to
gateway.  The EVRC vocoder is running in the gateway.  The BSC has
some signaling traffic it needs to send to the mobile node, so it
needs to rate-reduce the EVRC stream.  It does so by setting the D bit
in the next frame sent to the gateway.

 > 2.Also, since this is an IETF draft defining the transport of EVRC vocoder 
 > frames in an RTP packet, this means that this "signalling" will work only 
 > for an EVRC payload, and not any other kind of payload being carried in an 
 > RTP packet. However, if there is indeed a need of such a signalling 
 > mechanism, should it not be more generic (maybe included in  RTCP) and not 
 > be defined only for a particular vocoder payload? That again leads us to 
 > out of band signalling common for all scenarios.

It is only for EVRC because the capability to reduce the rate in this
particular way (by dropping to 1/2 rate) is unique to EVRC.  There may
be other codecs capable of reduced rate as well, but the specific
mechanism for requesting it may be different because there may be more
options.

 > 3. I agree with Pete that the draft is not (and should not be) designed 
 > only for support of 3GPP2 packet data architecture. Isn't it a layering 
 > violation for a packet being sent over an IP network be carrying some 
 > signalling bits only useful for an air interface?

This is the IETF, so the draft should support any usage scenario for
EVRC-in-RTP, including the gateway approach that I outlined.  Right
now it is carrying a signal to the vocoder to change its behavior,
which logically is part of RTP.

 > 4. Lastly, even though the rate reduction bit comes from a process that is 
 > scheduling packets on a per-frame basis, it seems to be extra overhead for 
 > the packet to be carrying multiple bits over the IP-network since the 
 > sender still makes the decision based on only one bit (the "D" bit of the 
 > last/youngest frame).

Yes, there is one bit per frame dedicated to this purpose, but it's
not such a big overhead, especially considering that over a wireless
link we will likely be using the header-free frame format.  The bit
per frame is necessary to get the lowest possible latency between the
request and the actual rate reduction.

-Pete

 > Thanks,
 > Kirti
 > 
 > 
 > >Hi, Nikolai,
 > >
 > >This draft is not only in support of the 3GPP2 packet data
 > >architecture (where IP/UDP/RTP runs all the way to the terminal); it
 > >also must support EVRC in RTP wherever it is being carried.  For
 > >example, there might be a legacy circuit mobile connected to a gateway
 > >at a BSC, which is in turn connected to a remote vocoder via an IP
 > >network.  Here EVRC-in-RTP is being used between the BSC and the
 > >vocoder.  Let's say the BSC has some (legacy, circuit) signaling that
 > >needs to be sent to the mobile.  It must slow down the vocoder so that
 > >there is room to send such signaling.  In this case, the D bit can be
 > >used for this purpose, and will behave much better than
 > >blank-and-burst or waiting passively for a low-rate frame, especially
 > >if there is a long train of signaling data waiting to go out to the
 > >terminal.
 > >
 > >The 'D' bit will generally not be used over an air interface, because
 > >it would require the terminal to know in advance that there was incoming
 > >signaling from the network, which in general is not possible.
 > >
 > >Kirti, to answer your questions: logically, the 'D' bit is generated
 > >per-frame because the rate reduction request comes from a process that
 > >is scheduling traffic on a per-frame basis.  The sender should respect
 > >the setting of the 'D' bit on the last or "youngest" frame received
 > >(which should hopefully be clear from the text).  We wanted to keep it
 > >in-band because there is a need for very quick response time from the
 > >sender, and out-of-band signaling was likely to be too slow and
 > >asynchronous.
 > >
 > >-Pete
 > >
 > >Nikolai Leung writes:
 > >  > At 01:09 AM 8/29/2001 -0700, Adam Li wrote:
 > >  > >Hi, Kirti,
 > >  > >
 > >  > >Thanks for the questions. About the Rate Reduction "D" bit, as currently
 > >  > >specified in the draft, is designed to be "per frame" signal I suppose.
 > >  > >
 > >  > >The inclusion of the "D" has been discussed once. Peter suggested 
 > > keeping
 > >  > >the "D" bit in Type 1 format for the following reasons:
 > >  > >
 > >  > >"There are some usage cases involving RTP running between two gateways,
 > >  > >where the latency between the two is low enough to make the R bit 
 > > useful.
 > >  > >In this case RTP does not run over the air, but there is an air 
 > > interface
 > >  > >connected to one of the gateways, and there is sometimes a need to
 > >  > >multiplex signaling in a dim-and-burst fashion. I am hearing from some
 > >  > >people that blank-and-burst, or waiting for a sub-rate frame, may not be
 > >  > >acceptable from a speech quality perspective."
 > >  >
 > >  > I agree that there may be a need to reduce the source code rate to allow
 > >  > for dim & burst signalling over the air interface.  However, in order to
 > >  > use the R-bit for this purpose requires that the gateway knows that 
 > > blank &
 > >  > burst signalling is to be sent on the air interface.  In a 3GPP2 network
 > >  > this is not the case: the BSC handles the signalling traffic while the
 > >  > PDSN/gateway is not aware of BSC forward link signalling load
 > >  > requirements.  Did you have other networks in mind?
 > >  >
 > >  > -Nik
 > >  >
 > >  >
 > >  > >Maybe Peter can further elaborate on more details of the application
 > >  > >scenarios.
 > >  > >
 > >  > >Adam
 > >  > >-----Original Message-----
 > >  > >From: [email-masked] [mailto:[email-masked]]On Behalf Of 
 > > Kirti Gupta
 > >  > >Sent: Tuesday, August 28, 2001 3:46 PM
 > >  > >To: [email-masked]
 > >  > >Subject: [AVT] Question on Rate Reduction bit in EVRC RTP payload format
 > >  > >
 > >  > >Hello,
 > >  > >
 > >  > >I have some questions regarding the draft-ietf-avt-evrc-07.txt 
 > > describing
 > >  > >the RTP payload format for EVRC speech.
 > >  > >
 > >  > >In the Type 1 format, each of the TOC entries has the "Rate 
 > > Reduction" or
 > >  > >the "D" bit (which if set indicates that the packet is requesting a
 > >  > >reduced codec rate for the reverse direction).  The questions are listed
 > >  > >below:
 > >  > >1. Since this request is "per packet", why is this "D"bit present per
 > >  > >frame in each TOC entry?
 > >  > >2. Furthermore, if some frames have this bit set and some do not, how
 > >  > >should the sender make a decision on receiving this packet?
 > >  > >3. Also, since the "D" bit only works for point-to-point full duplex
 > >  > >conversation, would it not be a better idea to use some other mechanism
 > >  > >for rate reduction which is useful in all cases rather than having 
 > > the "D"
 > >  > >bit at all?
 > >  > >
 > >  > >Thanks,
 > >  > >Kirti
 > >  > >
 > >  > >
 > >  > >
 > >  > <html>
 > >  > At 01:09 AM 8/29/2001 -0700, Adam Li wrote:<br>
 > >  > <blockquote type=cite class=cite cite><font face="arial" size=2 
 > > color="#0000FF">Hi,
 > >  > Kirti,</font><br>
 > >  > &nbsp;<br>
 > >  > <font face="arial" size=2 color="#0000FF">Thanks for the questions. About
 > >  > the Rate Reduction &quot;D&quot; bit, as currently specified in the
 > >  > draft, is designed to be &quot;per frame&quot; signal I suppose.
 > >  > </font><br>
 > >  > &nbsp;<br>
 > >  > <font face="arial" size=2 color="#0000FF">The inclusion of the
 > >  > &quot;D&quot; has been discussed once. Peter suggested keeping the
 > >  > &quot;D&quot; bit in Type 1 format for the following
 > >  > reasons:</font><br>
 > >  > &nbsp;<br>
 > >  > <font size=2>&quot;There are some usage cases involving RTP running
 > >  > between two gateways, where the latency between the two is low enough to
 > >  > make the R bit useful. In this case RTP does not run over the air, but
 > >  > there is an air interface connected to one of the gateways, and there is
 > >  > sometimes a need to multiplex signaling in a dim-and-burst fashion. I am
 > >  > hearing from some people that blank-and-burst, or waiting for a sub-rate
 > >  > frame, may not be acceptable from a speech quality
 > >  > perspective.&quot;</font> </blockquote><br>
 > >  > I agree that there may be a need to reduce the source code rate to allow
 > >  > for dim &amp; burst signalling over the air interface.&nbsp; However, in
 > >  > order to use the R-bit for this purpose requires that the gateway knows
 > >  > that blank &amp; burst signalling is to be sent on the air
 > >  > interface.&nbsp; In a 3GPP2 network this is not the case: the BSC handles
 > >  > the signalling traffic while the PDSN/gateway is not aware of BSC forward
 > >  > link signalling load requirements.&nbsp; Did you have other networks in
 > >  > mind?<br>
 > >  > <br>
 > >  > -Nik<br>
 > >  > <br>
 > >  > <br>
 > >  > <blockquote type=cite class=cite cite><font face="arial" size=2 
 > > color="#0000FF">Maybe
 > >  > Peter can further elaborate on more details of the application
 > >  > scenarios.</font><br>
 > >  > &nbsp;<br>
 > >  > <font face="arial" size=2 color="#0000FF">Adam</font>
 > >  > <dl><font face="tahoma" size=2>
 > >  > <dd>-----Original Message-----
 > >  > <dd>From:</b> [email-masked]
 > >  > [<a href="mailto:[email-masked]" 
 > > eudora="autourl">mailto:[email-masked]</a>]On
 > >  > Behalf Of </b>Kirti Gupta
 > >  > <dd>Sent:</b> Tuesday, August 28, 2001 3:46 PM
 > >  > <dd>To:</b> [email-masked]
 > >  > <dd>Subject:</b> [AVT] Question on Rate Reduction bit in EVRC RTP payload
 > >  > format<br>
 > >  > <br>
 > >  > </font>
 > >  > <dd>Hello,<br>
 > >  > <br>
 > >  >
 > >  > <dd>I have some questions regarding the draft-ietf-avt-evrc-07.txt
 > >  > describing the RTP payload format for EVRC speech. <br>
 > >  > <br>
 > >  >
 > >  > <dd>In the Type 1 format, each of the TOC entries has the &quot;Rate
 > >  > Reduction&quot; or the &quot;D&quot; bit (which if set indicates that the
 > >  > packet is requesting a reduced codec rate for the reverse
 > >  > direction).&nbsp; The questions are listed below:
 > >  > <dd>1. Since this request is &quot;per packet&quot;, why is this
 > >  > &quot;D&quot;bit present per frame in each TOC entry?
 > >  > <dd>2. Furthermore, if some frames have this bit set and some do not, how
 > >  > should the sender make a decision on receiving this packet?
 > >  > <dd>3. Also, since the &quot;D&quot; bit only works for point-to-point
 > >  > full duplex conversation<font color="#0000FF">, </font>would it not be a
 > >  > better idea to use some other mechanism for rate reduction which is
 > >  > useful in all cases rather than having the &quot;D&quot; bit at
 > >  > all?<br>
 > >  > <br>
 > >  >
 > >  > <dd>Thanks,
 > >  > <dd>Kirti<br>
 > >  > <br>
 > >  > <br>
 > >  > <br>
 > >  >
 > >  > </dl></blockquote></html>
 > <html>
 > Hello All,<br><br>
 > Thanks for your replies. However, I still have some questions in the
 > light of what has been said in your emails.<br><br>
 > 1. It seems that the reason for having the &quot;D&quot; bit (in band
 > signalling) is that it is useful<b> only</b> for<br>
 > -<i>Point-to-point full duplex conversation (as stated in the
 > draft).<br>
 > </i>But out of band signalling will still have to be used for all other
 > scenarios.<br><br>
 > -<i>When there us low latency between two gateways (as stated in Nikolai'
 > reply)<br>
 > </i>And the reason for using the D bit is to be able to create room for
 > signalling to reduce latency in an air interface. There seems to be
 > a<br>
 > contradiction here?<br><br>
 > 2.Also, since this is an IETF draft defining the transport of EVRC
 > vocoder frames in an RTP packet, this means that this<i>
 > &quot;signalling&quot; will work only for an EVRC payload,</i> and not
 > any other kind of payload being carried in an RTP packet. However, if
 > there is indeed a need of such a signalling mechanism, should it not be
 > more generic (maybe included in&nbsp; RTCP) and not be defined only for a
 > particular vocoder payload? That again leads us to out of band signalling
 > common for all scenarios.<br><br>
 > 3. I agree with Pete that the draft is not (and should not be) designed
 > only for support of 3GPP2 packet data architecture. Isn't it a layering
 > violation for a packet being sent over an IP network be carrying some
 > signalling bits only useful for an air interface?<br><br>
 > 4. Lastly, even though the rate reduction bit comes from a process that
 > is scheduling packets on a per-frame basis, it seems to be extra overhead
 > for the packet to be carrying multiple bits over the IP-network since the
 > sender still makes the decision based on only one bit (the &quot;D&quot;
 > bit of the last/youngest frame).<br><br>
 > Thanks,<br>
 > Kirti<br><br>
 > <br>
 > <blockquote type=cite class=cite cite>Hi, Nikolai,<br><br>
 > <font color="#0000FF">This draft is not only in support of the 3GPP2
 > packet data<br>
 > architecture</font> (where IP/UDP/RTP runs all the way to the terminal);
 > it<br>
 > also must support EVRC in RTP wherever it is being carried.&nbsp;
 > For<br>
 > example, there might be a legacy circuit mobile connected to a
 > gateway<br>
 > at a BSC, which is in turn connected to a remote vocoder via an IP<br>
 > network.&nbsp; Here EVRC-in-RTP is being used between the BSC and
 > the<br>
 > vocoder.&nbsp; Let's say the BSC has some (legacy, circuit) signaling
 > that<br>
 > needs to be sent to the mobile. <font color="#0000FF"> It must slow down
 > the vocoder so that<br>
 > there is room to send such signaling.&nbsp; In this case, the D bit can
 > be<br>
 > used for this purpose</font>, and will behave much better than<br>
 > blank-and-burst or waiting passively for a low-rate frame,
 > especially<br>
 > if there is a long train of signaling data waiting to go out to the<br>
 > terminal.<br><br>
 > The 'D' bit will generally not be used over an air interface,
 > because<br>
 > it would require the terminal to know in advance that there was
 > incoming<br>
 > signaling from the network, which in general is not possible.<br><br>
 > Kirti, to answer your questions: <font color="#0000FF">logically, the 'D'
 > bit is generated<br>
 > per-frame because the rate reduction request comes from a process
 > that<br>
 > is scheduling traffic on a per-frame basis.&nbsp; The sender should
 > respect<br>
 > the setting of the 'D' bit on the last or &quot;youngest&quot; frame
 > received</font><br>
 > (which should hopefully be clear from the text).&nbsp; We wanted to keep
 > it<br>
 > in-band because there is a need for very quick response time from
 > the<br>
 > sender, and out-of-band signaling was likely to be too slow and<br>
 > asynchronous.<br><br>
 > -Pete<br><br>
 > Nikolai Leung writes:<br>
 > &nbsp;&gt; At 01:09 AM 8/29/2001 -0700, Adam Li wrote:<br>
 > &nbsp;&gt; &gt;Hi, Kirti,<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;Thanks for the questions. About the Rate Reduction
 > &quot;D&quot; bit, as currently <br>
 > &nbsp;&gt; &gt;specified in the draft, is designed to be &quot;per
 > frame&quot; signal I suppose.<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;The inclusion of the &quot;D&quot; has been discussed
 > once. Peter suggested keeping <br>
 > &nbsp;&gt; &gt;the &quot;D&quot; bit in Type 1 format for the following
 > reasons:<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;&quot;<font color="#0000FF">There are some usage cases
 > involving RTP running between two gateways, <br>
 > &nbsp;&gt; &gt;where the latency between the two is low enough to make
 > the R bit useful. </font><br>
 > &nbsp;&gt; &gt;In this case RTP does not run over the air, but there is
 > an air interface <br>
 > &nbsp;&gt; &gt;connected to one of the gateways, and there is sometimes a
 > need to <br>
 > &nbsp;&gt; &gt;multiplex signaling in a dim-and-burst fashion. I am
 > hearing from some <br>
 > &nbsp;&gt; &gt;people that blank-and-burst, or waiting for a sub-rate
 > frame, may not be <br>
 > &nbsp;&gt; &gt;acceptable from a speech quality perspective.&quot;<br>
 > &nbsp;&gt; <br>
 > &nbsp;&gt; I agree that there may be a need to reduce the source code
 > rate to allow <br>
 > &nbsp;&gt; for dim &amp; burst signalling over the air interface.&nbsp;
 > However, in order to <br>
 > &nbsp;&gt; use the R-bit for this purpose requires that the gateway knows
 > that blank &amp; <br>
 > &nbsp;&gt; burst signalling is to be sent on the air interface.&nbsp; In
 > a 3GPP2 network <br>
 > &nbsp;&gt; this is not the case: the BSC handles the signalling traffic
 > while the <br>
 > &nbsp;&gt; PDSN/gateway is not aware of BSC forward link signalling load
 > <br>
 > &nbsp;&gt; requirements.&nbsp; Did you have other networks in mind?<br>
 > &nbsp;&gt; <br>
 > &nbsp;&gt; -Nik<br>
 > &nbsp;&gt; <br>
 > &nbsp;&gt; <br>
 > &nbsp;&gt; &gt;Maybe Peter can further elaborate on more details of the
 > application <br>
 > &nbsp;&gt; &gt;scenarios.<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;Adam<br>
 > &nbsp;&gt; &gt;-----Original Message-----<br>
 > &nbsp;&gt; &gt;From: [email-masked]
 > [<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]On
 > Behalf Of Kirti Gupta<br>
 > &nbsp;&gt; &gt;Sent: Tuesday, August 28, 2001 3:46 PM<br>
 > &nbsp;&gt; &gt;To: [email-masked]<br>
 > &nbsp;&gt; &gt;Subject: [AVT] Question on Rate Reduction bit in EVRC RTP
 > payload format<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;Hello,<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;I have some questions regarding the
 > draft-ietf-avt-evrc-07.txt describing <br>
 > &nbsp;&gt; &gt;the RTP payload format for EVRC speech.<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;In the Type 1 format, each of the TOC entries has the
 > &quot;Rate Reduction&quot; or <br>
 > &nbsp;&gt; &gt;the &quot;D&quot; bit (which if set indicates that the
 > packet is requesting a <br>
 > &nbsp;&gt; &gt;reduced codec rate for the reverse direction).&nbsp; The
 > questions are listed <br>
 > &nbsp;&gt; &gt;below:<br>
 > &nbsp;&gt; &gt;1. Since this request is &quot;per packet&quot;, why is
 > this &quot;D&quot;bit present per <br>
 > &nbsp;&gt; &gt;frame in each TOC entry?<br>
 > &nbsp;&gt; &gt;2. Furthermore, if some frames have this bit set and some
 > do not, how <br>
 > &nbsp;&gt; &gt;should the sender make a decision on receiving this
 > packet?<br>
 > &nbsp;&gt; &gt;3. Also, since the &quot;D&quot; bit only works for
 > point-to-point full duplex <br>
 > &nbsp;&gt; &gt;conversation, would it not be a better idea to use some
 > other mechanism <br>
 > &nbsp;&gt; &gt;for rate reduction which is useful in all cases rather
 > than having the &quot;D&quot; <br>
 > &nbsp;&gt; &gt;bit at all?<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;Thanks,<br>
 > &nbsp;&gt; &gt;Kirti<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &gt;<br>
 > &nbsp;&gt; &lt;html&gt;<br>
 > &nbsp;&gt; At 01:09 AM 8/29/2001 -0700, Adam Li wrote:&lt;br&gt;<br>
 > &nbsp;&gt; &lt;blockquote type=cite class=cite cite&gt;&lt;font
 > face=&quot;arial&quot; size=2 color=&quot;#0000FF&quot;&gt;Hi,<br>
 > &nbsp;&gt; Kirti,&lt;/font&gt;&lt;br&gt;<br>
 > &nbsp;&gt; &amp;nbsp;&lt;br&gt;<br>
 > &nbsp;&gt; &lt;font face=&quot;arial&quot; size=2
 > color=&quot;#0000FF&quot;&gt;Thanks for the questions. About<br>
 > &nbsp;&gt; the Rate Reduction &amp;quot;D&amp;quot; bit, as currently
 > specified in the<br>
 > &nbsp;&gt; draft, is designed to be &amp;quot;per frame&amp;quot; signal
 > I suppose.<br>
 > &nbsp;&gt; &lt;/font&gt;&lt;br&gt;<br>
 > &nbsp;&gt; &amp;nbsp;&lt;br&gt;<br>
 > &nbsp;&gt; &lt;font face=&quot;arial&quot; size=2
 > color=&quot;#0000FF&quot;&gt;The inclusion of the<br>
 > &nbsp;&gt; &amp;quot;D&amp;quot; has been discussed once. Peter suggested
 > keeping the<br>
 > &nbsp;&gt; &amp;quot;D&amp;quot; bit in Type 1 format for the following
 > <br>
 > &nbsp;&gt; reasons:&lt;/font&gt;&lt;br&gt;<br>
 > &nbsp;&gt; &amp;nbsp;&lt;br&gt;<br>
 > &nbsp;&gt; &lt;font size=2&gt;&amp;quot;There are some usage cases
 > involving RTP running<br>
 > &nbsp;&gt; between two gateways, where the latency between the two is low
 > enough to<br>
 > &nbsp;&gt; make the R bit useful. In this case RTP does not run over the
 > air, but<br>
 > &nbsp;&gt; there is an air interface connected to one of the gateways,
 > and there is<br>
 > &nbsp;&gt; sometimes a need to multiplex signaling in a dim-and-burst
 > fashion. I am<br>
 > &nbsp;&gt; hearing from some people that blank-and-burst, or waiting for
 > a sub-rate<br>
 > &nbsp;&gt; frame, may not be acceptable from a speech quality<br>
 > &nbsp;&gt; perspective.&amp;quot;&lt;/font&gt;
 > &lt;/blockquote&gt;&lt;br&gt;<br>
 > &nbsp;&gt; I agree that there may be a need to reduce the source code
 > rate to allow<br>
 > &nbsp;&gt; for dim &amp;amp; burst signalling over the air
 > interface.&amp;nbsp; However, in<br>
 > &nbsp;&gt; order to use the R-bit for this purpose requires that the
 > gateway knows<br>
 > &nbsp;&gt; that blank &amp;amp; burst signalling is to be sent on the
 > air<br>
 > &nbsp;&gt; interface.&amp;nbsp; In a 3GPP2 network this is not the case:
 > the BSC handles<br>
 > &nbsp;&gt; the signalling traffic while the PDSN/gateway is not aware of
 > BSC forward<br>
 > &nbsp;&gt; link signalling load requirements.&amp;nbsp; Did you have
 > other networks in<br>
 > &nbsp;&gt; mind?&lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; -Nik&lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; &lt;blockquote type=cite class=cite cite&gt;&lt;font
 > face=&quot;arial&quot; size=2 color=&quot;#0000FF&quot;&gt;Maybe<br>
 > &nbsp;&gt; Peter can further elaborate on more details of the
 > application<br>
 > &nbsp;&gt; scenarios.&lt;/font&gt;&lt;br&gt;<br>
 > &nbsp;&gt; &amp;nbsp;&lt;br&gt;<br>
 > &nbsp;&gt; &lt;font face=&quot;arial&quot; size=2
 > color=&quot;#0000FF&quot;&gt;Adam&lt;/font&gt;<br>
 > &nbsp;&gt; &lt;dl&gt;&lt;font face=&quot;tahoma&quot; size=2&gt;<br>
 > &nbsp;&gt; &lt;dd&gt;-----Original Message-----<br>
 > &nbsp;&gt; &lt;dd&gt;From:&lt;/b&gt; [email-masked]<br>
 > &nbsp;&gt; [&lt;a href=&quot;mailto:[email-masked]&quot;
 > eudora=&quot;autourl&quot;&gt;<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>&lt;/a&gt;]On<br>
 > &nbsp;&gt; Behalf Of &lt;/b&gt;Kirti Gupta<br>
 > &nbsp;&gt; &lt;dd&gt;Sent:&lt;/b&gt; Tuesday, August 28, 2001 3:46
 > PM<br>
 > &nbsp;&gt; &lt;dd&gt;To:&lt;/b&gt; [email-masked]<br>
 > &nbsp;&gt; &lt;dd&gt;Subject:&lt;/b&gt; [AVT] Question on Rate Reduction
 > bit in EVRC RTP payload<br>
 > &nbsp;&gt; format&lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; &lt;/font&gt;<br>
 > &nbsp;&gt; &lt;dd&gt;Hello,&lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; <br>
 > &nbsp;&gt; &lt;dd&gt;I have some questions regarding the
 > draft-ietf-avt-evrc-07.txt<br>
 > &nbsp;&gt; describing the RTP payload format for EVRC speech.
 > &lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; <br>
 > &nbsp;&gt; &lt;dd&gt;In the Type 1 format, each of the TOC entries has
 > the &amp;quot;Rate<br>
 > &nbsp;&gt; Reduction&amp;quot; or the &amp;quot;D&amp;quot; bit (which if
 > set indicates that the<br>
 > &nbsp;&gt; packet is requesting a reduced codec rate for the 
 > reverse<br>
 > &nbsp;&gt; direction).&amp;nbsp; The questions are listed below:<br>
 > &nbsp;&gt; &lt;dd&gt;1. Since this request is &amp;quot;per
 > packet&amp;quot;, why is this<br>
 > &nbsp;&gt; &amp;quot;D&amp;quot;bit present per frame in each TOC entry?
 > <br>
 > &nbsp;&gt; &lt;dd&gt;2. Furthermore, if some frames have this bit set and
 > some do not, how<br>
 > &nbsp;&gt; should the sender make a decision on receiving this
 > packet?<br>
 > &nbsp;&gt; &lt;dd&gt;3. Also, since the &amp;quot;D&amp;quot; bit only
 > works for point-to-point<br>
 > &nbsp;&gt; full duplex conversation&lt;font
 > color=&quot;#0000FF&quot;&gt;, &lt;/font&gt;would it not be a<br>
 > &nbsp;&gt; better idea to use some other mechanism for rate reduction
 > which is<br>
 > &nbsp;&gt; useful in all cases rather than having the
 > &amp;quot;D&amp;quot; bit at <br>
 > &nbsp;&gt; all?&lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; <br>
 > &nbsp;&gt; &lt;dd&gt;Thanks,<br>
 > &nbsp;&gt; &lt;dd&gt;Kirti&lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; &lt;br&gt;<br>
 > &nbsp;&gt; <br>
 > &nbsp;&gt;
 > &lt;/dl&gt;&lt;/blockquote&gt;&lt;/html&gt;</blockquote></html>

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

---

From: Randall Gellens <[email-masked]>
Date: Fri, 07 Sep 2001 13:53:54 -0700

>request and the actual rate reduction.

Could you explain in more detail how the bit per frame is needed for low 
latency?

If the D bit is needed, it seems to make more sense as a bit per packet.