Re: [AVTCORE] Header Compression and RFC5285bis

"Roni Even" <> Tue, 10 May 2016 07:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB0DC12D1CA for <>; Tue, 10 May 2016 00:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h2ZoHqVXPUQ9 for <>; Tue, 10 May 2016 00:36:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BE7412D580 for <>; Tue, 10 May 2016 00:36:24 -0700 (PDT)
Received: by with SMTP id n129so165975905wmn.1 for <>; Tue, 10 May 2016 00:36:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=rn6jtKBbumxqp0FJKJ3aPrS7mr9QBOcVu6hpnte1M78=; b=HGkPnSKnVJxVChjQQzdQzOeQtRH0nvNt7cDcrLOr0nmrR6rchJFv/z/ZSNHf3hj9u0 IBNVCfGsl0yCDDPbjTkxPBlg/fM4NOrWDTRdaOi8oMHCNSwvozYU7UtdWi1Br9OGqIZR TFjrFyHu9G6QT3sgk6PdnDkUXF6Y/DzDnma38ynp/diGwWzAfzOXQT9huGv6D7InvAQA Pi4Co68kjvs2tdQn5fTIuinGuigNF3pNyXAOAS6yI2xm/kARHKNck33Rek6Xe0/VP+5C ApwKJzTXAa4z0AsFhEos8c1k5EnpnoYL8TZDtWSMyvNsnCvn7duzp2UjrbxaD0dsW1N1 wE+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=rn6jtKBbumxqp0FJKJ3aPrS7mr9QBOcVu6hpnte1M78=; b=iWxINf+rD5VCArQwlRN2Srb6FkXI7yVn5kl3uhBrHX1GyJZmeWdm5C2+PcaIVjfSRa 8OSah8if+ZUteei8ZZ1aPchCoRQLJUuT20nFPiNLE0DdTKGbQhnR3205jbYmWvu7G7pg D7BBv0+7O74ip3po4IwmZr/3MtFZtIoCz4F40I8pYzONc6lvHbmwAkq60tvDXPbiqyHV C3UI2cDVBFbciwSdIpVIpl4eZgO5/933uTfnhmQNZj8YjydA5kL/dkaUKkebvn9KEoVq gvaEhxOto/bqH2WxiZEFMuzELmWFHlIYTYkxX/HNJcY55HbdtPBVNSTXbJdAXvI7RAWj upTg==
X-Gm-Message-State: AOPr4FWhJQZRg6NXoUk0Tj5wF/frVW0O7ApTCfpERB+kVSmAkdoRF2TheVowH0AOQdlPpA==
X-Received: by with SMTP id uq3mr26749619wjc.44.1462865781686; Tue, 10 May 2016 00:36:21 -0700 (PDT)
Received: from RoniPC ( []) by with ESMTPSA id jr8sm956238wjb.15.2016. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 00:36:20 -0700 (PDT)
From: "Roni Even" <>
To: "'Magnus Westerlund'" <>, "'IETF AVTCore WG'" <>, "'Stephen Casner'" <>
References: <>
In-Reply-To: <>
Date: Tue, 10 May 2016 10:36:07 +0300
Message-ID: <071a01d1aa8e$9e4c1800$dae44800$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKz49dNSeiH6WyIxJ1uGuCsbsh9+J3tVRoA
Content-Language: he
Archived-At: <>
Subject: Re: [AVTCORE] Header Compression and RFC5285bis
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 May 2016 07:36:30 -0000

Hi Magnus,
I am updating the document based on other comments from Colin.
The current text says "The interactions of the RTP   header extension and
header compression is explored further in   [RFC2508] and [RFC3095]."
Do you think we need more text here? Any suggestions

> -----Original Message-----
> From: avt [] On Behalf Of Magnus Westerlund
> Sent: Saturday, April 02, 2016 6:47 PM
> To: IETF AVTCore WG; Stephen Casner
> Subject: [AVTCORE] Header Compression and RFC5285bis
> Hi,
> Stephen Casner raised a private comment on the
> draft-ietf-avtext-sdes-hdr-ext-05 when he did the IANA expert review.
> This was that both
> draft-ietf-avtext-sdes-hdr-ext-05 and RFC5285bis doesn't discuss impact of
> header compression due to the presence of RTP header extensions.
> I have to agree that this is something that at least RFC5285bis should
have a
> discussion on. There are some impact.
> In the case of Robust Header Compression (ROHC) (RFC 5795 and RFC 5225)
> the impact to my understanding is the following. RFC5225 and the RTP
> profile don't compress the actual header extension at all. The X bit in
> header is compressed and it is classified in Section A.5 as Rarely
> The assumption here is that what value is set on a previous packet will be
> maintained on the next.
> Looking at the emerging usages that is mostly right, but there will be
> where the x bit may be flipping its value. The usage I am considering is
> initial inclusion of the MID, CNAME etc. However for example a video
> stream, it is sufficient to include the header extension in a single
packet out
> potentially many for an particular video image/frame. Thus one might have
> on, off, next TS, on, then off on subsequent packets.
> The impact of the classification as Rarely changing is that when a change
> needed a larger header than otherwise needed will be sent.
> Thus the impact will be that each on and off behaviour will result in one
> maybe two larger ROHC headers to get the change across compared to if no
> RTP header extensions would have been present.
> I haven't looked at CRTP, but I would guess similar impact.
> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Core Maintenance