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

From: Kirti Gupta <[email-masked]>
Date: Tue, 28 Aug 2001 15:45:44 -0700

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

---

From: "Adam Li" <[email-masked]>
Date: Wed, 29 Aug 2001 01:09:14 -0700

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."

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,

  1. Since this request is "per packet", why is this "D"bit present per
frame in each TOC entry?

  Thanks,
  Kirti

---

From: Nikolai Leung <[email-masked]>
Date: Wed, 29 Aug 2001 15:30:59 -0400

At 01:09 AM 8/29/2001 -0700, Adam Li wrote:
>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

>From: [email-masked] [mailto:[email-masked]]On Behalf Of Kirti Gupta
>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:
>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
>
>
>

---

From: Pete McCann <[email-masked]>
Date: Wed, 29 Aug 2001 15:44:09 -0500

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:
 > <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>
 > 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
 > <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>

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

---

From: Kirti Gupta <[email-masked]>
Date: Thu, 30 Aug 2001 09:49:32 -0700

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?

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.

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?

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).

Thanks,
Kirti

>  > [<a href="mailto:[email-masked]" 
> eudora="autourl">mailto:[email-masked]</a>]On