1 of 62

AVTCORE WG

IETF 114

Hybrid Meeting

Thursday, July 28, 2022

13:30 - 15:30 Eastern Time

Session II, Philadelphia North

​

​

1

​

Mailing list: avtcore@ietf.org

Notes: https://notes.ietf.org/notes-ietf-114-avtcore

MeetEcho link: https://wws.conf.meetecho.com/conference/?group=avtcore

2 of 62

IETF 114 Meeting Tips

In-person participants

  • Make sure to sign into the session using the Meetecho (usually the “Meetecho lite” client) from the Datatracker agenda
  • Use Meetecho to join the mic queue
  • Keep audio and video off if not using the onsite version
  • Wear masks unless actively speaking at the microphone.

Remote participants

  • Make sure your audio and video are off unless you are chairing or presenting during a session
  • Use of a headset is strongly recommended

2

2

This session is being recorded

3 of 62

IETF 114 Remote Meeting Tips

​

  • Enter the queue with , leave with

​

  • When you are called on, you need to enable your audio to be heard.�
  • Audio is enabled by unmuting and disabled by muting

​

  • Video can also be enabled, but it is separate from audio.
  • Video is encouraged to help comprehension but not required.

3

3

This session is being recorded

4 of 62

Resources for IETF 114 Philadelphia

4

4

5 of 62

Note well

This is a reminder of IETF policies in effect on various topics such as patents or code of conduct. It is only meant to point you in the right direction. Exceptions may apply. The IETF's patent policy and the definition of an IETF "contribution" and "participation" are set forth in BCP 79; please read it carefully.

As a reminder:

  • By participating in the IETF, you agree to follow IETF processes and policies.
  • If you are aware that any IETF contribution is covered by patents or patent applications that are owned or controlled by you or your sponsor, you must disclose that fact, or not participate in the discussion.
  • As a participant in or attendee to any IETF activity you acknowledge that written, audio, video, and photographic records of meetings may be made public.
  • Personal information that you provide to IETF will be handled in accordance with the IETF Privacy Statement.
  • As a participant or attendee, you agree to work respectfully with other participants; please contact the ombudsteam (https://www.ietf.org/contact/ombudsteam/) if you have questions or concerns about this.

�Definitive information is in the documents listed below and other IETF BCPs. For advice, please talk to WG chairs or ADs:

5

5

6 of 62

Note really well

  • IETF meetings, virtual meetings, and mailing lists are intended for professional collaboration and networking, as defined in the IETF Guidelines for Conduct (RFC 7154), the IETF Anti-Harassment Policy, and the IETF Anti-Harassment Procedures (RFC 7776). If you have any concerns about observed behavior, please talk to the Ombudsteam, who are available if you need to confidentially raise concerns about harassment or other conduct in the IETF.
  • The IETF strives to create and maintain an environment in which people of many different backgrounds are treated with dignity, decency, and respect. Those who participate in the IETF are expected to behave according to professional standards and demonstrate appropriate workplace behavior.
  • IETF participants must not engage in harassment while at IETF meetings, virtual meetings, social events, or on mailing lists. Harassment is unwelcome hostile or intimidating behavior -- in particular, speech or behavior that is aggressive or intimidates.
  • If you believe you have been harassed, notice that someone else is being harassed, or have any other concerns, you are encouraged to raise your concern in confidence with one of the Ombudspersons.

6

7 of 62

Reminder: IETF Mask Policy

Participants in sessions and other IETF-controlled rooms will be required to wear an FFP2/N95 mask, KN95/KF94/FFP3 masks, or locally certified equivalents. The only exception is for chairs or presenters who are actively speaking; participants making comments or asking questions from the floor microphones are expected to remain masked.

​

https://www.ietf.org/how/meetings/114/faq/#covidmeasures

7

8 of 62

About this meeting

8

9 of 62

In Memoriam: Stephen L. Casner

9

10 of 62

A few Readings, Writings, Viewings

•A Brief prehistory of VoIP

•https://site.ieee.org/pikespeak/files/2021/06/prehistory-voip.share.pdf

•First IETF Internet Audiocast / Newsweek MBone coverage

•https://dl.acm.org/doi/10.1145/142267.142338

•https://www.newsweek.com/mbone-cant-you-hear-it-knocking-185526

•IEEE 2020 Internet Award / ISI News

•https://www.youtube.com/watch?app=desktop&v=qGlQque52zw

•https://www.isi.edu/news/40167/2020-ieee-award-behind-the-screens-with-scientists-stephen-casner-and-eve-schooler/

•The Oxy Campaign for Good

•https://campaign.oxy.edu/stories/stephen-l-casner-73-and-karen-johnson-casner-74

•Tesla blog - Handing over the keys

•https://www.tesla.com/blog/handing-over-keys

•Vintage Computer Festival West

•https://www.mercurynews.com/2016/08/06/vintage-computer-festival-west-returns-after-nine-year-hiatus/

​

​

10

11 of 62

Agenda

  1. Note Well, Note Takers, In Memorium, Agenda Bashing, Draft status (Chairs, 20 min)
  2. Cryptex (S. Murillo, 10 min)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex

https://github.com/juberti/cryptex/issues

  • RTP Payload Format for Versatile Video Coding (VVC) (S. Wenger, 10 min)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-vvc

  • RTP Payload Format for SCIP (D. Hanson, 10 min)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip

  • RFC7983bis (B. Aboba, 10 min)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic

  • SDP for RTP over QUIC (S. Dawkins, 10 min)

https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic

  • RTP Payload for V3C (L. Ilola, 10 min)

https://datatracker.ietf.org/doc/html/draft-ilola-avtcore-rtp-v3c

  • RTP Control Protocol (RTCP) Messages for Green Metadata (W. Zia, 10 min)

https://datatracker.ietf.org/doc/html/draft-he-avtcore-rtcp-green-metadata

  • Wrapup and Next Steps (Chairs, 10 min)

​

11

12 of 62

Draft Status

  • Published
    • RFC 9071: was draft-ietf-avtcore-multi-party-rtt-mix
    • RFC 9134: was draft-ietf-payload-rtp-jpegxs
  • RFC Editor Queue
    • draft-ietf-payload-vp9 (MISSREF)
  • IETF Last Call Completed: IESG Evaluation::AD Followup
    • draft-ietf-avtcore-cryptex (IETF LC completed April 5)
      • Revised I-D submitted (draft-ietf-avtcore-cryptex-07)
    • draft-ietf-avtcore-rtp-vvc (IETF LC completed May 19)
  • Waiting for AD Go-Ahead::Revised I-D Needed
    • draft-ietf-avtext-framemarking

12

13 of 62

Draft Status (cont’d)

  • WGLC Completed, Waiting for WG Chair Go-Ahead : Proposed Standard
    • draft-ietf-avtcore-rtp-scip (WGLC completed May 8, 2022)
      • Gen-Art and Art-Art reviews posted
      • Secdir review pending
    • draft-ietf-avtcore-rfc7983bis (WGLC completed June 6, 2022)
  • Adopted
    • draft-ietf-avtcore-rtp-over-quic (CfA completed July 11, 2022)
    • draft-ietf-avtcore-rtp-evc
  • Call for Adoption completed:

13

14 of 62

CfA on “Game State over RTP”

  • CfA Completed on May 8, 2022
  • CfA summary: https://mailarchive.ietf.org/arch/msg/avt/w80E9ihE4rrJyMzU6F9eOYgvYVE/
  • Two responses:
  • Chair proposal
    • Proponents to provide a plan for obtaining responses outside the IETF (e.g. game developer forums)
    • WG to extend the CfA to sometime in September (due to August vacations)

14

15 of 62

Completely Encrypting RTP Header Extensions and Contributing Sources (Cryptex)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex

https://github.com/juberti/cryptex/issues

​

15

Sergio Garcia Murillo

16 of 62

Current Status

  • 39 comments received from IESG review, IANA and SDP Directorate review, 3 “wontfix”, 8 open, requiring further discussion

https://github.com/juberti/cryptex/issues?q=is%3Aissue

  • New draft available addressing the non-contentious feedback

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex-07

​

​

​

​

​

16

17 of 62

Won’t fix issues

  • Usage of inclusive language (#69)
    • Can not rename “master key” term as it is referencing RFC3711.
  • Detail fingerprinting issue (#92)
    • Not aware of any analysis that can be referenced .
  • IANA registry for "defined by profile" (#95)
    • This an issue for RFC8285, or even for RFC3550. There is no IANA registry for the "defined by profile" values, so we can't add the values specified in this doc to it.

​

​

17

18 of 62

IANA issue feedback #60

  • [SOLVED] Section 4, 2nd paragraph - It says the the attribute "can be used at the session level or media level", however the IANA registration in Section 9.1 says it can only be used at the media-level. Which way is it ?

​

Changing “cryptex” attribute from session and media level to media only was a change introduced by mistake in the previous draft. Reverted now.

18

19 of 62

IPR (#74,#91)

  • The Shepherds write-up with respect to IPR shows two authors confirming they have filed "all required disclosures" but does not list whether this means "there are none", "there are some, compatible with IETF" or that there is "disclosed, incompatible with IETF".

​

[BERNARD] The authors have not filed any IPR disclosures. The status of the non-author IPR disclosures is here: https://mailarchive.ietf.org/arch/msg/avt/c88xDocWibCpJntwzj0rYG-3lfk/

​

19

20 of 62

CRYPTEX updates RFC3711

  • [SOLVED] I believe that this document should formally Update rfc3711. The mechanism described here is a replacement for what rfc6904 defined. That original mechanism was tagged as formally Updating rfc3711 -- this work should also be tagged that way.

​

But would like to check agreement from the WG about this. Also, two idnits warnings triggered:

    • pre-RFC5378 disclaimer (#110): Should be ignored?
    • [TODO] Mention rfc3711 update in abstract (#109)

​

20

21 of 62

CRYPTEX and RFC6878

  • Would it be time to deprecate RFC6904? (#68)
  • Prefer Cryptex over RFC6904 (#73)

​

[QUESTION] If both are negotiated, Cryptex SHOULD be used? Or why not stronger, if both peers support Cryptex, RFC6904 SHOULD NOT (MUST NOT?) be used?

​

21

22 of 62

Mandatory stop #76

Alternatively, if the implementation considers the use of this

specification mandatory and the "defined by profile" field does not match one of the values defined above, it SHOULD stop the processing of the RTP packet and report an error for the RTP stream.

​

[QUESTION] Why is this not a MUST stop? If it is mandatory, what is an example where it can continue processing an RTP packet without the mandatory requirement?

22

23 of 62

Next Steps

  • Update draft with consensus of this meeting
  • Publish cryptex-08
  • Call for IESG review again?

​

23

24 of 62

RTP Payload Format for Versatile Video Coding (VVC)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-vvc

​

24

Stephan Wenger

25 of 62

Current Status and next steps

  • Lots of good AD comments against v16, leading to V17, which was posted 7/2/22.
  • Thereafter, only Zahed’s DISCUSS remained. It relates to behavior of “sender property” (sprop-) code points in the SDP
  • Per Zahed’s suggestion, we will add informative language explaining that unusual behavior, and issue v18.
  • Zahed plans to clear his DISCUSS against v18, assuming that change is made to his satisfaction.
  • As all our changes since v16 were editorial, or reviewed by relevant experts and/or ADs, we do not see a need for another LC.

​

​

​

​

25

26 of 62

​

​

​

​

​

​

​

​

RTP Payload Format for for SCIP

Dan Hanson

Mike Faller

​

​

26

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip

27 of 62

SCIP Draft RFC – Status

  • “Status - Awaiting Eternal Review/Resolution of Issues Raised”
  • An email from MMUSIC WG indicates that their review of the SDP is complete
    • “As the draft does not define any new SDP attributes etc, there is no need for any new SDP procedures.”
  • GENART - “This simple document is adequate to register the media type as is.”
  • ARTART - “Not Ready”
  • Draft RFC Expires Nov 26, 2022

​

27

28 of 62

Comments (1 of 4)

  • GENART - “The references SCIP210 and SCIP214 are shown as informational. I assume that as much as anything this is because they are not widely available and strictly you could just treat them as opaque, but given they are fundamental to what you are standardising I would have expected them to be normative.”
  • ARTART - “Section 4: SCIP-210 (and perhaps SCIP-214.2) seem like they are required to implement SCIP, and should therefore be normative references.”
  • Response - The AVTCORE WG determined that SCIP-210 and SCIP-214 should be informational references. Section 5 contains all the information necessary to implement support for SCIP in network devices so the SCIP standards are listed for informational purposes.

28

29 of 62

Comments (2 of 4)

  • ARTART - Abstract: SCIP-214.2 is mentioned here but nowhere else in the document except as a reference and in the media subtype registration. It seems inappropriate for the sole mention to be in the abstract; should it also appear in Section 4 along with SCIP-210?
  • Response - Open to discussion. Even considering complete removal since SCIP-214.2 is essentially the predecessor to the RFC

29

30 of 62

Comments (3 of 4)

  • ARTART - Sections 5.1 and 5.2: These media subtypes are already registered with IANA and should not be repeated here (some things like contact addresses may change, and RFCs are immutable).
  • Response - To be discussed.
  • Question: what is the process for updating contact addresses?

​

  • ARTART - Section 7: Please add instructions to IANA that upon publication as an RFC, the registrations for [AUDIOSCIP] and [VIDEOSCIP] should be updated to cite this document as a reference..
  • To be discussed.

30

31 of 62

Actions and Questions

  • Some comments received that were narrative were not incorporated as they do not impact the technical information necessary to support SCIP
  • Comments which may impact technical understanding that are discussed here with a resolution will be incorporated into the draft RFC
  • Questions were asked about when and how to update the IANA registration of the AUDIOSCIP and VIDEOSCIP registration information. The sumitters of the draft RFC will take actions based upon the group reply.
  • Next Steps?

31

32 of 62

RFC 7983bis

Bernard Aboba

G. Salgueiro

C. Perkins

32

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis

33 of 62

RFC 7983bis

  • Update to RFC 7983 Section 7, documenting QUIC multiplexing.
    • Description of multiplexing SRTP, SRTCP, STUN, TURN, DTLS, ZRTP and QUIC
    • Guidance on handling overlap between QUIC and TURN channels.
    • Discussion of usage scenarios and multiplexing requirements
  • Update to (D)TLS Content-Type Field IANA page to reference new RFC (no other change needed)

33

34 of 62

WGLC

  • WGLC completed June 6, 2022
    • Announcement
  • Comments
    • Martin Thomson
      • Concerned about QUIC version dependencies (e.g. diagram mentioning QUIC short/long header)
    • David Schinazi
      • Add: “MUST NOT send grease_quic_bit transport parameter”
      • Question about demultiplexing of TURN channels and QUIC.
    • Jonathan Lennox
      • TURN channel packets should only ever be received from a TURN server, and a TURN client knows whether it sent TURN allocation requests, and channel-binding requests, to a server.

34

35 of 62

Updated Diagram

35

36 of 62

RFC 7983bis-05 Changes

  • Section 1

​

​

​

  • Section 2

In the absence of QUIC bit greasing, the first octet of a QUIC packet (e.g. a short header packet in QUIC v1 or v2) may fall in the range 64 to 127, thereby overlapping with the allocated range for TURN channels of 64 to 79. However, in practice this overlap does not represent a problem. TURN channel packets will only be received from a TURN server to which TURN allocation and channel-binding requests have been sent. Therefore a TURN client receiving packets from the source IP address and port of a TURN server only needs to disambiguate STUN (i.e. regular TURN) packets from TURN channel packets; (S)RTP, (S)RTCP, ZRTP, DTLS or QUIC packets will not be sent from a source IP address and port that had previously responded to TURN allocation or channel-binding requests. As a result, if the source IP address and port of a packet does not match that of a responding TURN server, a packet with a first octet of 64 to 127 can be unambiguously demultiplexed as QUIC.

36

37 of 62

Next steps…

  • Is the draft ready for publication?
  • If not, what Issues remain?

37

38 of 62

RTP over QUIC

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic

38

Mathis Engelbart, Jörg Ott

39 of 62

Scope

  • Aiming at minimal mapping, more complex scenarios later�
  • RTP over QUIC defines application usage of QUIC�
  • Baseline expects nothing more than standard QUIC�
  • Can benefit from QUIC extensions�
  • Describes how QUIC implementation and its API can be extended to improve efficiency�
  • Limited to RTP over QUIC, without enhancing QUIC or RTP�
  • Signaling defined separately (e.g. draft-dawkins-sdp-rtp-quic)

39

40 of 62

ALPN

  • Required by QUIC�
  • Added “rtp-mux-quic” to indicate that multiple flows may be multiplexed�
  • Append version suffix for draft implementations�
  • See also: Issue #13

40

41 of 62

API Considerations

  • List of features which a QUIC implementation can provide to help implementing the previously described optimizations�
  • Split into two subsections:�
    • Exposed information: MTU size, ACKs, Stream states, Timestamps (if available)�
    • Exposed methods: Cancel Streams, Set Congestion Controller

41

42 of 62

Other updates

  • Restrict RTP sessions to use QUIC streams or QUIC datagrams
    • Not both simultaneously (at this point)�
  • Note about implications of mapping QUIC statistics to RTCP when QUIC streams are used�
  • New subsection about congestion control considerations when sharing a QUIC connection with non-real-time streams�
  • Considerations on Connection Migration and 0-RTT�
  • Security Considerations

42

43 of 62

Open Issues

  • Translator forwarding packets over UDP: packets received via QUIC stream may exceed MTU (and even max UDP packet size)�
  • #16: Retransmission flow ID (PR: #19: See RTP Retransmissions)�
  • #14: Which stream types (PR: #17: Unidirectional)�
  • #15: Considerations about Stream concurrency�
  • #13: What if datagrams are not enabled?

44 of 62

Recent / Next Steps

  • Submitted as WG draft this week

​

  • Working further with Spencer on SDP signaling

44

45 of 62

SDP for RTP over QUIC

Spencer Dawkins

45

draft-dawkins-avtcore-sdp-rtp-quic - a minimal specification

https://github.com/SpencerDawkins/sdp-rtp-quic-issues - includes discussion

46 of 62

Background for this session

  • draft-dawkins-avtcore-sdp-rtp-quic
    • a minimal SDP specification, tracking draft-ietf-avtcore-rtp-over-quic
    • Issues and PRs based on current text are welcome in this GitHub repo
  • Separate GitHub repo, used for broader issue tracking
    • Most issues fit within draft-ietf-avtcore-rtp-over-quic scope
  • At IETF 114 - provide an update based on draft-ietf-avtcore-rtp-over-quic
    • Please feel free to provide feedback on the mailing list also
  • My goal is to issue a -01 before our next AVTCORE meeting
    • I plan to request adoption of draft-dawkins-avtcore-sdp-rtp-quic

46

47 of 62

What AVP profiles to register - # 5

  • draft-dawkins-avtcore-sdp-rtp-quic-issues-00 registered three profiles
    • “QUIC/RTP/SAVP", "QUIC/RTP/AVPF", and "QUIC/RTP/SAVPF"
  • Proposal at last interim was to register one profile - "QUIC/RTP/AVPF"
    • Secure AVP profiles most useful when bridging to non-QUIC/RTP
    • We’ll have that conversation when we revise RTP Topologies RFC
  • And, of course, we need to prepend “UDP/” for consistency in registry
    • Spencer missed this - my apologies
  • Then, two related questions popped up
    • What about streams versus datagrams? (next slide)
    • Will we need ICE-TCP? (new issue)

​

47

48 of 62

RTP over streams, datagrams, or both?

  • This shows up in two related issues
    • What will RTP be using? (#8)
    • Do we need to signal this in SDP (#3)
  • draft-ietf-avtcore-rtp-over-quic-00 now includes all three choices
    • (“Both” is called “shared” - it’s new since our last interim meeting)
  • My proposal is to include “stream/”, “dgram/” and “/shared”

48

49 of 62

Do We Need TCP-ICE? - #12 (new)

  • Using ICE to solve fundamental problem of UDP blocking/rate-limiting
    • Roman Shpount explained this in an email onlist
    • His email text is also included in the Github issue
  • His key point is that we need a way to fall back to TCP
    • If we can use ICE TCP candidates, we do have a fallback
    • If we can’t use ICE TCP candidates, what’s the alternative?
  • His proposal was to also register TCP/QUIC/RTP/AVPF-style profiles
    • This almost certainly needs more working group discussion

​

49

50 of 62

QUIC also does congestion control - #1

  • To get a QUIC implementation to change its HTTP/3 behavior, we might
    • Explicitly ask the QUIC implementation to do something media friendly
    • Explicitly ask the QUIC implementation to do SCReAM
    • Explicitly ask a QUIC implementation for specific feedback information
    • I proposed we explore whether this is a problem in practice
  • draft-ietf-avtcore-rtp-over-quic registers "rtp-mux-quic" ALPN
    • So, the QUIC implementation at the other end will know this is RTP
  • Proposal is that SDP should carry ALPNs
    • This allows use of multiple draft versions, experiments, etc.

​

50

51 of 62

How to ask for QUIC feedback - #13 (new)

  • Want to allow implementations to ask QUIC for feedback
    • This is included in draft-ietf-avtcore-rtp-over-quic
  • Goal: substitute transport layer feedback for RTCP feedback
    • Reduce overhead when possible
    • Mapping may require creativity (interpret lost packet as a NACK)
  • What should SDP look like for this?
    • "enable-transport-layer-feedback", or something similar, or
    • name individual pieces of transport layer feedback
  • Proposal is "enable-transport-layer-feedback", or something similar
    • This almost certainly needs more working group discussion

51

52 of 62

RTP Payload for V3C

https://datatracker.ietf.org/doc/draft-ilola-avtcore-rtp-v3c/

https://github.com/laurilo/draft-ilola-avtcore-rtp-v3c

​

52

Lauri Ilola

Lukasz Kondrad

53 of 62

Background

  • The topic was first introduced in the AVTCORE virtual meeting (15/02/22)
  • Visual volumetric video-based coding (V3C) aims to re-use the existing 2d video coding technologies and it is video codec agnostic.
  • V3C encoder decomposes volumetric frame into multiple components
    • video components (geometry, occupancy, attribute) that can be encoded by any video codec
    • atlas (metadata) component
      • provide information how to re-project the video components back into volumetric video frame
      • is encoded using mechanisms defined in ISO/IEC 23090-5
      • high-level syntax is represented as atlas NAL units that are very similar to HEVC/VVC.

53

54 of 62

V3C RTP overview

  • Video components can be streamed according to respective RTP payload specifications (e.g. H.264 - RFC6184, H.265 - RFC7798, etc.)
  • Atlas component is missing RTP payload format.
  • Defining V3C RTP payload format for NAL unit based atlas data
    • Encapsulation of atlas NAL units into RTP packets
    • V3C specific payload format parameters
    • Grouping mechanism (e.g. video component streams and atlas component stream can be grouped according to RFC5888)
    • Bundling of RTP streams according to RFC8843

54

55 of 62

Feedback implemented

  • AVTCore feedback on draft-00 (#1)
    • Align with VVC instead of HEVC RTP payload format - Done
    • Remove Multi Time Aggregation Packets - Done
    • Clean payload format parameter section - Done
  • Public feedback
    • Missing acronyms (#3) - Done
    • Editorial feedback & fixing errors in examples (#4) - Done

​

  • Feedback managed on Github

55

56 of 62

Next Steps

  • Suggestions and feedback is much appreciated
    • Can be done directly on Github
    • Continue to update the draft based on feedback

​

  • We would like to propose working group adoption

​

Any questions or comments?

​

56

57 of 62

RTP Control Protocol Messages (RTCP) for Green Metadata

https://datatracker.ietf.org/doc/html/draft-he-avtcore-rtcp-green-metadata

​

57

Yong He (Qualcomm), Waqar Zia (Qualcomm), Christian Herglotz (FAU), Edouard Francois (InterDigital)

58 of 62

Overview

  • Energy Efficient Media Consumption is specified by MPEG in ISO/IEC 23001-11
  • 2 types of metadata specified:
    1. Video encoder generated decoding complexity (sent via Supplemental Enhancement Information (SEI), not the focus here)
    2. Decoder feedback ⇒ encoder adapts decoder energy consumption
      • A format is needed for this to carry these messages ⇒ draft-he-avtcore-rtcp-green-metadata
        • Current draft version:

https://www.ietf.org/archive/id/draft-he-avtcore-rtcp-green-metadata-00.html

      • Specifies a new RTCP payload format for
        1. Temporal-Spatial Resolution Request and
        2. Notification feedback message Temporal-Spatial Resolution Notification

​

58

59 of 62

New Messages

  • AVPF [RFC4585][RFC5104] defines seven payload-specific feedback messages and one application layer feedback message.
  • This document specifies 2 new payload-specific feedback messages
  • Message may be sent
    • in a regular full compound RTCP packet or
    • in an early RTCP packet
  • Decoder requests specific video quality based on decoder-local conditions (e.g. power consumption etc.)

59

Temporal-Spatial Resolution Request

Temporal-Spatial Resolution Notification (TSRN)

60 of 62

Timing, Security

  • Mixer encoding for multiple sessions may need to consider joint needs of participants
  • Messages not time-critical
    • Sent using regular RTCP timing
  • Security:
    • Spoofed or malicious messages may degrade video performance (e.g. low quality video)
    • Need to apply authentication and integrity protection: SRTP and SAVPF

60

61 of 62

Next Steps

  • Gather feedback
  • Reflector discussions
  • Incorporate, update, review
  • Seek adoption when ready

61

62 of 62

Thank you

Special thanks to:

​

The Secretariat, WG Participants & ADs

62