Subject: [AVT] RE: avt Digest, Vol 28, Issue 21

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Tue, 29 Aug 2006 11:27:00 +0200

Hi

The problem is not limited to a specific speech codec, it is more a
general problem that all speech codecs have. The proposed solution is to
(by using inband signaling) being able to request redundant transmission
and/or frame aggregation in order to enable an efficient channel
adaptation strategy as the one proposed in the draft
(http://www.ietf.org/internet-drafts/draft-johansson-avt-rtp-shim-00.txt
)

Reason why I propose inband signaling for this is because RTCP is bulky
and bursty and does not fit well with optimized cellular networks (this
is copy pasted from a previous post).
========
One example of the possible problems that RTCP might face in a 3G
cellular network, this is not to be interpreted as a bash at 3G
networks, it is just the laws of physics that applies to all wireless
access technology today.

The smallest size of the RTCP packets (SR) is 672bits with IPv4 . In
order to add the proposed functionality (request for redundancy/frame
aggregation one can add an APP packet (128bits). The total size is then
800 bits. With IPv6 the size is 160 bits more.
With the optimized radio transmission scheduled for in 3GPP the maximum
size of the radio blocks is in the order 300-400 bits. This means that
the RTCP packets always get fragmented, this is no big issue with
persistent radio bearers such as defined for HSDPA as they do
retransmission until the packet is reassembled, there will be a little
more jitter however. 
There are however also specified non persistent radio bearers in
GERAN-EDGE that allows a maximum of one retransmission, in this case the
risk is quite high that the RTCP packets does not reach the receiver at
all, especially if the RTCP sender is close to a cell border. This means
that there is a risk to use RTCP in the adaptation. 
========

The proposed strategy is meant to be used for VoIP (which is
bidirectional ), also the main application is point to point and for the
reasons explained above RTCP is not a good option. Adding a few bytes of
inband signaling bits fits much better.

Ingemar

> ------------------------------
> 
> Message: 5
> Date: Mon, 28 Aug 2006 15:51:11 +0300
> From: "Even, Roni" <[email-masked]>
> Subject: [AVT] VoIP Shim for RTP Payload Formats
> To: <[email-masked]>
> Message-ID:
> 	
> <[email-masked]
> ycom.com>
> 	
> Content-Type: text/plain;	charset="US-ASCII"
> 
> Hi,
> Some comments after reading the draft and the email exchange 
> 
> I am not sure about the right way here. The reason is that 
> even though the SHIM tries to define a general channel I only 
> see one use here.
> 
> I do not see how Shims ID are allocated and managed.
> 
> Maybe if the problem is just for the AMR codecs then maybe 
> you can define a new payload type and have this information 
> as a payload header or payload packet type like in the video 
> codecs. This will enable negotiation.
> 
> My understanding is that this is a back channel type of 
> message so it will only work if you have bi-directional 
> communication which is what the RTCP channel is. If this is 
> true then you should state it.
> 
> Thanks
> Roni Even 
> 
> 

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

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 29 Aug 2006 11:41:59 -0700

> -----Original Message-----
> From: Ingemar Johansson S (LU/EAB)
> [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2006 2:27 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] RE: avt Digest, Vol 28, Issue 21
> 
> Hi
> 
> that there is a risk to use RTCP in the adaptation.

The above mentioned risk of using RTCP for rate adaptation on 3gpp is
true / valid irrespective of the codec or media type (audio/video) used
over 3GPP (The size of those RTCP packets stays pretty much the same or
increases with other codecs and other media types). Hence, I prefer that
a very generic RTP header extension be designed/proposed for in-band
feedback signaling. It is intuitive to see that in-band signaling (with
very few additional bits) is better than RTCP in terms bandwidth
requirement, feedback reliability, robustness to guard against loss of
feedback info, timeliness of feedback which are all extremely important
for media adaptation over cellular networks.

I just want to be careful that any RTP header extension design should
not be shortsighted and limited to address a very specific issue.

---

From: David R Oran <[email-masked]>
Date: Tue, 29 Aug 2006 14:58:05 -0400

>> is copy pasted from a previous post).
Stupid question. What if the audio is going one way and there IS NO  
RTP packet to piggyback the feedback on going in the reverse  
direction? Lots of cases for this, e.g. VAD, MOH, playing voicemail,  
etc.

Seems like you need the RTCP machinery anyway.

Dave.

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 30 Aug 2006 08:04:24 +0200

Hi

Reply below.
Ingemar 

> From: David R Oran [mailto:[email-masked]] 
> Sent: den 29 augusti 2006 20:58
> To: Desineni, Harikishan
> Cc: Ingemar Johansson S (LU/EAB); [email-masked]; Colin 
> Perkins; [email-masked]
> Subject: Re: [AVT] RE: avt Digest, Vol 28, Issue 21
> 
> 
> >> general problem that all speech codecs have. The proposed 
> solution is
> > to
> Stupid question. What if the audio is going one way and there 
> IS NO RTP packet to piggyback the feedback on going in the 
> reverse direction? Lots of cases for this, e.g. VAD, MOH, 
> playing voicemail, etc.
> 

 VAD (I assume that you mean DTX, correct me if I am wrong here) the
case is that silence descriptor packets are transmitted with regular
intervals, for AMR the interval is typically 160ms, this interval is
however a requirement from a circuit switched cellular network
perspective and for packet switced networks 500ms is sufficient.
 Music on hold: Not 100% sure here but in todays cellular networks I
belive that both directions are active despite music on hold, however
DTX will be used in one direction due to speech inactivity.
 Voicemail is a special case and is not meant to be covered by the
proposed adaptation strategy (at least not my intention).

As stated in the draft, the intention is not to replace RTCP, RTCP is
needed for other purposes such as sychronization of speech and video in
a videophone session. For a speech only situation the situation for RTCP
is however less certain as the burstyness causes some potential problems
in optimized cellular networks.

Ingemar

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 30 Aug 2006 08:44:19 +0200

Hi

I very much welcome a discussion around the issue of inband signaling.
The intention was to create a generic inband signaling format for speech
codecs mainly as the gain in terms of overhead is highest (lowest codec
bitrate), also it is my area. 
I have not looked into inband signaling for the video coding parts
because I assumed that the RTCP mechanisms was good enough for this
purpose (higher bitrate, less impact of RTCP burstyness), but maybe I am
wrong here.

Ingemar

> From: Desineni, Harikishan [mailto:[email-masked]] 
> Sent: den 29 augusti 2006 20:42
> To: Ingemar Johansson S (LU/EAB); [email-masked]; Colin Perkins
> Subject: RE: [AVT] RE: avt Digest, Vol 28, Issue 21
> 
> 
> 
> The above mentioned risk of using RTCP for rate adaptation on 
> 3gpp is true / valid irrespective of the codec or media type 
> (audio/video) used over 3GPP (The size of those RTCP packets 
> stays pretty much the same or increases with other codecs and 
> other media types). Hence, I prefer that a very generic RTP 
> header extension be designed/proposed for in-band feedback 
> signaling. It is intuitive to see that in-band signaling 
> (with very few additional bits) is better than RTCP in terms 
> bandwidth requirement, feedback reliability, robustness to 
> guard against loss of feedback info, timeliness of feedback 
> which are all extremely important for media adaptation over 
> cellular networks.
> 
> I just want to be careful that any RTP header extension 
> design should not be shortsighted and limited to address a 
> very specific issue.
> > ========
> > 
> > reasons explained above RTCP is not a good option. Adding a 
> few bytes
> of
> > > I am not sure about the right way here. The reason is that even 
> > > though the SHIM tries to define a general channel I only 
> see one use 
> > > here.
> > >
> > > Maybe if the problem is just for the AMR codecs then 
> maybe you can 
> > > define a new payload type and have this information as a payload 
> > > header or payload packet type like in the video codecs. This will 
> > > enable negotiation.
> > >
> message so 
> > > it will only work if you have bi-directional 
> communication which is 
> > > what the RTCP channel is. If this is true then you should 
> state it.
> > >
> > > Thanks
> > > Roni Even
> > >
> > >
> >

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 30 Aug 2006 10:36:58 -0700

Risk of loosing RTCP packet (As per Ingemar, this is high at the edge of
a cellular network with very weak service signal) applies to any type of
media adaptation which relies on RTCP to deliver feedback info. Such a
risk may look high for low bit rate speech services. IMO, such a risk
applies to any low bit rate service when a cellular terminal is at the
edge of a cell with very weak service signal. Adaptation risk on other
media services like video cannot be ignored. Under such conditions,
video services on cellular networks will scale down to low bit-rate
(24Kbps to 48Kbps) and hence they are not necessarily out of risk. The
video service on cellular networks can also start at a very low-bit rate
(A mobile at the edge of a cell can start with low bit rate even though
it can support higher bit rates). High risk of losing RTCP packet is not
specific to adaptation of speech service and it is a valid case for
adaptation of any type of point to point real-time conversational media
service on cellular networks. Also, irrespective of the media type, the
risk of losing RTCP packet increases with IPv6.

Using RTCP, sometimes the feedback has to be either delayed or totally
suppressed as the value of delayed feedback may not be useful at the
sender. It can be hard for a receiver to determine whether a delayed
feedback message would really be useful to a sender at a given time. A
feedback message delayed by X msec may sometimes be useful and other
times it may not be. Relying on a fixed value of X may not be a good
idea and (RTCP) re-transmissions in conversational services (low delay)
would mostly not work due to high RTT values in bad n/w conditions.
Ability to provide fast (real-time) feedback (via in-band RTP or using a
separate control channel) can greatly benefit adaptation of point to
point low bit rate media services over cellular networks. 

Of course, RTCP should continue to exist for reasons it is widely known
for. RTCP feedback based solutions can exist where there isn't great
probability of losing RTCP packets or where timeliness of feedback is
not so critical with respect to the impact on service quality. 

Fast feedback using in-band signaling with RTP header extension:
   
Pros: Fast-feedback with few more additional bps. Timely, robust,
feedback need not be delayed or suppressed. Far less additional bit rate
reqd when compared to RTCP. Concern about the risk of RTCP packet loss
at the edge of a cell is addressed. Much simpler feedback loops can
evolve from this approach.
   
Cons: Requires 8 bytes of header extension for 1 byte of feedback. More
feedback bytes may further impact header compression (RoHC). Can ROHC
compress the header extensions to an extent that the resultant packet
does not get segmented over the lower layers?

If not, This extra overhead + additional update overhead in header
compression (RoHC) increases the risk to cause segmentation at lower
layers in optimized cellular networks.  One has to further optimize
applications to leverage the existing lower layer optimization on
cellular networks. This may or may not be possible based on the type of
cellular technology and the type of application. Next generation
cellular networks have to be optimized to prevent unwanted side effects
of such packet structure. 

Not easily applicable to other services/topologies which are not point
to point. 

Has to fallback to RTCP based feedback if the RTP stream in the reverse
direction is moved to hold status or removed. Hence, it can only
co-exist with RTCP based feedback. (For each header extn, one might have
to provide details on how RTCP can be used to carry the same info)

> Sent: Tuesday, August 29, 2006 11:44 PM
> To: Desineni, Harikishan; [email-masked]; Colin Perkins
> Subject: RE: [AVT] VoIP Shim for RTP Payload Formats
> 
> Hi
> 
> 
> > > GERAN-EDGE that allows a maximum of one retransmission, in this
case
> > the
> > > risk is quite high that the RTCP packets does not reach the
receiver
> > at
> > > bidirectional ), also the main application is point to point and
for
> > the