Re: [AVTCORE] WG Last Call: "Frame Marking RTP Header Extension"

Bernard Aboba <> Sun, 22 November 2020 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20A553A0AF7 for <>; Sun, 22 Nov 2020 06:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 K8-4GJT5HJZr for <>; Sun, 22 Nov 2020 06:40:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D4543A07F0 for <>; Sun, 22 Nov 2020 06:40:31 -0800 (PST)
Received: by with SMTP id b63so12421703pfg.12 for <>; Sun, 22 Nov 2020 06:40:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=jkATJIjz754XckTuk6CLs6biQRw9WgUFLLiDTK32JMM=; b=AK2ZCusjH0Pb8oVblqqsi796JrmLZ7aOZmvm/ioBVmY3lt5Vmj9l0iNTNwFmH6okpq +2abz5FZt3gjNfoC3U6e2OL7ERw0VcqzyNZ/pVZUog3sN8w9cQ3wcRJYFD04sheQFTc0 smOe1tZWp7J3WdL+wLOkBATXqAM4QwxZ4SdlcyakHr7aRYpCT/w7fGxbj3xTmsR829OC vIb9ed70rZizCnJRxW9XwFZVAW/0fjgPkW0bkOhXmwAbQf5FOxYH121lcqBOa2IhJ3pf LdFv9UWwPAlBF7Dw3oh9IeGG6DsOkeuxkzs39Vii4kVGOAKmoc7C+Eynk93/wEVkKVP1 r97A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=jkATJIjz754XckTuk6CLs6biQRw9WgUFLLiDTK32JMM=; b=ZHgFDw14Bj/V+2Xf6vKrfRnj4cwDkKGID10SfMJmlCe9EpJFe8oXK52uQbSUzQJuDq lKDYa9xhBeyOyvOncgA2qIM4KRxXxAOAcfEoHikr3nc8NfyLflrUg+av4uAHAQP4pdvn +RapaH9NLlb175SVoR+vqtW47OG36NoG2Q2HCwePMT0ZD8fQN2RNfI8adpTNTrLdqg/u FTYqSEAKSC7R1S95kcD+hbV3PBOkNUWrFkBLbaMZD5znaCLfRMVfbo5KulEkQe9BlDY7 AfoNx7WUSSJnW9eaOtr2NjK/Ia11Bwc9UV/yTAkdnOSgQAVXHm/OHWeetx2PmUazvc7X dTig==
X-Gm-Message-State: AOAM530jtfwcJPCDfeb4RrX3bFNRYrXaXogE9MbTI6Y805bvN3mVwrth MkWW4ZJ44Z8PE+Rof5tpvPynXgbSGV8kiQ==
X-Google-Smtp-Source: ABdhPJxRKFMUMrBhReL15v090Hq4EdxqW5ekZdUkFHIJqemhBNARSRCkiFHnYpz0+XrwVbbIp3+ieQ==
X-Received: by 2002:a65:40ca:: with SMTP id u10mr23561011pgp.71.1606056030244; Sun, 22 Nov 2020 06:40:30 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id b5sm9367918pfr.193.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Nov 2020 06:40:29 -0800 (PST)
From: Bernard Aboba <>
X-Google-Original-From: Bernard Aboba <>
Content-Type: multipart/alternative; boundary=Apple-Mail-695E560E-6BC8-4A49-98C7-FC574C3EED5F
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Sun, 22 Nov 2020 06:39:53 -0800
Message-Id: <>
References: <>
Cc: IETF AVTCore WG <>
In-Reply-To: <>
To: Stephan Wenger <>
X-Mailer: iPad Mail (18B92)
Archived-At: <>
Subject: Re: [AVTCORE] WG Last Call: "Frame Marking RTP Header Extension"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Nov 2020 14:40:33 -0000

Stephan -

Thank you for raising the question of implementation experience. I will start a separate thread to attempt to collect this, since it does not appear to have been discussed on this list.

Can you expand upon your remarks (in a separate thread) with respect to SRTP and Sframe? AFAICT Sframe does not obsolete SRTP, nor does it lessen the need for a frame forwarding RTP header extension.

> On Nov 21, 2020, at 19:45, Stephan Wenger <> wrote:
> All:
> This is not a hard objection, but I want to inquire if there is anyone out there who continues to think that frame marking as originally proposed is still a good idea and will see implementations.  The main reason I want to know is that accepting frame marking as an RFC would imply, per previous WG agreement, that future video codec payload formats include a (mandatory?) section on how to map the codepoints in the frame marking draft to the codec in question.  That’s non-trivial cost and effort, and chances are that effort will grow over time as codecs develop beyond what was mainstream in 2016. 
> What triggered my thinking about dumping frame marking are a) webrtc’s removal of frame marking as a required to implement technology, b) the decreasing relevance, as I perceive it, of SRTP for which frame marking is predominantly designed, and c) the myriad of new ideas in the IETF that skin the secure-SFU cat in different ways (sframe among them, but not the only one).
> Stephan
> From: avt <> on behalf of Bernard Aboba <>
> Date: Saturday, November 21, 2020 at 13:08
> To: IETF AVTCore WG <>
> Subject: [AVTCORE] WG Last Call: "Frame Marking RTP Header Extension"
> This is an announcement of WG last call on "Frame Marking RTP Header Extension"
> The document is available for inspection here: 
> WG Last Call will end on December 6, 2020. 
> In response, please state one of the following: 
> * I support advancing "Frame Marking RTP Header Extension" to Proposed Standard
> * I object to advancing "Frame Marking RTP Header Extension" to Proposed Standard, due to Issues described below <Issue description or link>. 
> Bernard Aboba
> For the Chairs
> _______________________________________________
> Audio/Video Transport Core Maintenance