[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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