Subject: RE: [AVT] 3 to last-call - RTP header extensions

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 23 Oct 2006 07:15:15 +0200

Hi

FYI I have updated the draft-johansson-avt-rtp-shim draft and if I
followed the guidlines correctly the update should appear on 
http://tools.ietf.org/wg/avt quite soon.
This updated draft tries to explain in better detail how the proposal is
implemented.

To comment on RTP header extensions against Shim inband signaling: 
It is perfectly in order to put the Shim messages in the header
extension as in the draft submitted by Dave Singer. This gives the extra
minimum 8 byte overhead as indicated before. If 3GPP optimized VoIP
radio bearers are used, the 8 bytes is enough to make a larger transport
block needed, this has an increased risk for packet. In the Shim inband
case the overhead is minimum 1 byte and the proposed radiobearers
actually has a spare byte left so a larger transport block is not needed
if only one Shim inband signaling is transmitted.

The radio bearers specified in e.g 3GPP TS 34.108 are devised with the
assumption that header compression (RoHC) is used.
Switching of payload type (like in the Shim inband signaling case) or
header extension bit (like in the RTP header extension draft) has some
consequences on the compression efficiency  as an extra RoHC overhead of
typically 4 bytes for 3 consequtive packets is needed for stable RoHC
compressor/decompressor states each time these RTP header fields change.
If RTP header extension is used this will cause segmentation of the
packets with an increased risk of packet loss. If Shim is used a larger
transport block will be needed but segmentation is avoided, additionally
change of payload type can be avoided completely if the payload type
with Shim + original payload is always in use, this gives a continuous
one byte overhead.

The Shim draft is more recent than the RTP header extension draft.
Please note however that tricks similar to Shim has been proposed
earlier, one such example is proposed in 3GPP in TS 26.234 when defining
a crypto payload used for DRM (see Annex K) and in the RTP payload
format for retransmission (RFC 4588) (the "apt" parameter) (quote from
an earlier email by Magnus Westerlund)

Regards
Ingemar

> ------------------------------
> 
> Message: 3
> Date: Sun, 22 Oct 2006 21:48:55 +0800
> From: Dave Singer <[email-masked]>
> Subject: RE: [AVT] 3 to last-call - RTP header extensions
> To: [email-masked], "Even, Roni" <[email-masked]>
> Cc: [email-masked]
> Message-ID: <p0623094fc16126b0e2fa@[17.202.35.52]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> At 9:36  +0200 22/10/06, [email-masked] wrote:
> >Hi Roni, folks,
> >
> >Here's my take:
> >
> >The shim draft's main intention/application is to signal certain 
> >information (error resilience strength commands to be 
> precise) from a 
> >media decoder to a media encoder, utilizing the reverse 
> direction media 
> >path.  I won't comment on that idea in fear of using inappropriate 
> >language, but I do have an opinion :-)
> >
> >If work should contrinue at all on this draft (I'm personally not of 
> >the opinion it should) I guess one avenue would be to split 
> the draft 
> >into a) transport of opaque bytes shimmed between RTP header and RTP 
> >payload, plus related signaling, and b) the use case proposed 
> >(signaling of AMR encoder operation points from an AMR 
> decoder).  Then 
> >a) should be called a profile.  That would be half-way 
> clean, I think, 
> >though not necessarily helpful, considering that the profile 
> >negotiation problem is (to the best of my knowledge) still unsoved.
> >
> >Dave's header extension stuff, on the other hand, is a comparatively 
> >clean use of RTP's exstension mechanism that has been available for 
> >many years (although perhaps intended more for experiments than for 
> >regular use).  It should not break existing codebases and monitoring 
> >tools intended to support any of the existing profiles, as 
> long as the 
> >implementatiosn/tools follow RFC3550 in throwing away 
> extensions they 
> >don't understand.  Not true for shim.  That's why shim 
> should be called a profile.
> >
> >Dave's stuff could carry the payload proposed in the shim 
> draft, though 
> >at a certain penalty of a few bytes per packet (using Dave's 
> >mechanisms, I think it's 8 bytes penalty).  Some companies 
> in 3GPP SA4 
> >see this as a major problem, as it makes radio optimization 
> difficult.  Others disagree.
> >  But on the Internet, the 8 bytes should not do any 
> significant harm.
> 
> The 8 bytes comes from the current treatment of the X bit (I 
> have to have the signature and the length in there, even 
> though my stuff is self-identifying and self-framing).  So 
> they're not quite my fault. 
> But they are there.
> 
> >
> >I believe, the main discussion should be between Dave's 
> header extensions
> >and the specification/use of new profiles.  I believe to 
> recall that there
> >was a plan (proposed by Cullen?) to take this issue to the RAI area
> >mailing list, as it is closely related to profile 
> negotiations.  But I
> >haven't seen any related traffic.
> 
> Nor I.  I also note that we have been refining the header extensions 
> for a while now, while the shim draft is both more recent (first 
> version in august) and more specialized.  I guess I'd like their 
> comment on why the general header extension is not appropriate, or 
> other alignment issues.
> 
> >
> >Regards,
> >Stephan
> >
> >P.s.: in SA4, even the shim use case is by no means agreed.
> >
> >>  Hi,
> >>  My concern is with what looks to me like duplication 
> between the header
> >>  extensions and the "shim" draft and I would like have one 
> mechanism if
> >>  possible.
> >>  Roni
> >>
> >>>  -----Original Message-----
> >>>  From: Dave Singer [mailto:[email-masked]]
> >>>  Sent: Friday, October 20, 2006 7:58 PM
> >>>  To: [email-masked]
> >>>  Subject: [AVT] 3 to last-call - RTP header extensions
> >>>
> >>>  Hi folks
> >>>
> >>>  the only adjustment here from the previous drafts is to 
> use URIs to
> >>>  identify header extensions, rather than reversed domain 
> names.  URIs
> >>>  have the advantage that they might be de-referencable URLs, and
> >>>  indeed the draft now says that for RFCs, the extension 
> name is the
> >>>  URL to the RFC.  So the following two now say that, as well.
> >>>
> >>>  I'm asking for last-call on these, as we've seen them a 
> while, they
> >>>  are complete, and the discussion has died down.  Re-start the
> >>>  discussion if you disagree!
> >>>
> >>>  * * * *
> >>>
> >>>  This draft is a work item of the Audio/Video Transport 
> Working Group
> >>>  of the IETF.
> >>>
> >>>	Title		: A general mechanism for RTP Header Extensions
> >>>	Author(s)	: D. Singer
> >>>	Filename	: draft-ietf-avt-rtp-hdrext-06.txt
> >>>	Pages		: 17
> >>>	Date		: 2006-10-19
> >>>
> >  >> This document provides a general mechanism to use the header-
> >>>      extension feature of RTP (the Real Time Transport 
> Protocol).  It
> >>>      provides the option to use a small number of small 
> extensions in
> >>  each
> >>>      RTP packet, where the universe of possible 
> extensions is large and
> >>>      unregistered.  The actual extensions in use in a session are
> >>  signaled
> >>>      in the setup information for that session.
> >>>
> >>>  A URL for this Internet-Draft is:
> >>>  
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt
> >>>
> >>>
> >>>
> >>>	Title		: Transmission Time offsets in RTP streams
> >>>	Author(s)	: H. Desineni, D. Singer
> >>>	Filename	: draft-ietf-avt-rtp-toffset-02.txt
> >>>	Pages		: 15
> >>>	Date		: 2006-10-19
> >>>
> >>>  This document describes a method to inform RTP clients when RTP
> >>>      packets are transmitted at a time other than their 'nominal'
> >>>      transmission time.  It also provides a mechanism to provide
> >>  improved
> >>>      inter-arrival jitter reports from the clients, that take into
> >>  account
> >>>      the reported transmission times.
> >>>
> >>>  A URL for this Internet-Draft is:
> >>>  
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-02.txt
> >>>
> >>>	Title		: Associating Time-codes with RTP streams
> >>>	Author(s)	: D. Singer
> >>>	Filename	: draft-ietf-avt-smpte-rtp-05.txt
> >>>	Pages		: 20
> >>>	Date		: 2006-10-19
> >>>
> >>>  This document describes a mechanism for associating 
> time-codes, as
> >>>      defined by the Society of Motion Picture and 
> Television Engineers
> >>>      (SMPTE), with media streams, in a way that is 
> independent of the
> >>  RTP
> >>>      payload format of the media stream itself.
> >>>
> >>>  A URL for this Internet-Draft is:
> >>>  
> http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-05.txt
> >>>
> >>>
> >>>
> >>>  --
> >>>  David Singer
> >>>  Apple Computer/QuickTime
> >>>
> >>>  _______________________________________________
> >>>  Audio/Video Transport Working Group
> >>>  [email-masked]
> >>>  https://www1.ietf.org/mailman/listinfo/avt
> >>
> >>  _______________________________________________
> >>  Audio/Video Transport Working Group
> >>  [email-masked]
> >>  https://www1.ietf.org/mailman/listinfo/avt
> >>
> >
> >
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> -- 
> David Singer
> Apple Computer/QuickTime
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 30, Issue 18
> ***********************************
> 

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