RE: [AVT] VoIP Shim for RTP Payload Formats

["Desineni, Harikishan" <hdesinen at qualcomm.com>]

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)


> -----Original Message-----
> From: Ingemar Johansson S (LU/EAB)
> [mailto:ingemar.s.johansson at ericsson.com]
> Sent: Tuesday, August 29, 2006 11:44 PM
> To: Desineni, Harikishan; avt at ietf.org; Colin Perkins
> Cc: roni.even at polycom.co.il
> Subject: RE: [AVT] VoIP Shim for RTP Payload Formats
> 
> 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
> 
> 
> 
> > -----Original Message-----
> > From: Desineni, Harikishan [mailto:hdesinen at qualcomm.com]
> > Sent: den 29 augusti 2006 20:42
> > To: Ingemar Johansson S (LU/EAB); avt at ietf.org; Colin Perkins
> > Cc: roni.even at polycom.co.il
> > Subject: RE: [AVT] RE: avt Digest, Vol 28, Issue 21
> >
> >
> >
> > > -----Original Message-----
> > > From: Ingemar Johansson S (LU/EAB)
> > > [mailto:ingemar.s.johansson at ericsson.com]
> > > Sent: Tuesday, August 29, 2006 2:27 AM
> > > To: avt at ietf.org
> > > Cc: roni.even at polycom.co.il
> > > Subject: [AVT] RE: avt Digest, Vol 28, Issue 21
> > >
> > > 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-s
> > him-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 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.
> > > ========
> > >
> > > 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" <roni.even at polycom.co.il>
> > > > Subject: [AVT] VoIP Shim for RTP Payload Formats
> > > > To: <avt at ietf.org>
> > > > Message-ID:
> > > >
> > > > <144ED8561CE90C41A3E5908EDECE315C03D3E4A4 at IsrExch01.israel.pol
> > > > 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
> > > avt at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/avt
> >

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt