1 of 68

AVTCORE WG

Virtual Interim

February 13, 2024

09:00 - 11:00 AM Pacific Time

​

​

1

Mailing list: avt@ietf.org

Notes: https://notes.ietf.org/notes-ietf-interim-2024-avtcore-00-avtcore

Meeting link: https://datatracker.ietf.org/meeting/interim-2024-avtcore-01/session/avtcore

2 of 68

Virtual Interim 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.
  • Keep audio and video off unless you are chairing or presenting.
  • Use of a headset is strongly recommended.

2

2

This session is being recorded

3 of 68

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:

3

3

4 of 68

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.

4

4

5 of 68

About this meeting

5

6 of 68

Draft Status

  • Published
    • RFC 9071: was draft-ietf-avtcore-multi-party-rtt-mix
    • RFC 9134: was draft-ietf-payload-rtp-jpegxs
    • RFC 9328: was draft-ietf-avtcore-rtp-vvc
    • RFC 9335: was draft-ietf-avtcore-cryptex
    • RFC 9443: was draft-ietf-avtcore-rfc7983bis
  • RFC Editor Queue
    • draft-ietf-payload-vp9 (976 days, MISSREF)
    • draft-ietf-avtcore-rtp-evc (EDIT)
  • IESG: AD Followup (404 days, 1 DISCUSS position)
  • IESG Evaluation::Revised I-D Needed (199 days)
    • draft-ietf-avtext-framemarking

6

7 of 68

Draft Status (cont’d)

  • WGLC
    • draft-ietf-avtcore-rtp-v3c (ended November 7, 2023)
  • Adopted
    • draft-ietf-avtcore-rtp-over-quic
    • draft-ietf-avtcore-rtcp-green-metadata
    • draft-ietf-avtcore-rtp-v3c
    • draft-ietf-avtcore-hevc-webrtc
    • draft-ietf-avtcore-rtp-j2k-scl
    • draft-ietf-avtcore-rtp-sframe

7

8 of 68

IANA Registries Background

https://www.iana.org/assignments/media-types/media-types.xhtml

Spreadsheet: https://www.iana.org/assignments/media-types/video.csv

  • Issue tracked by MEDIAMAN WG

​

8

9 of 68

Action Items from IETF 118

  • IANA Registries
    • Magnus Westerlund to write a short doc to update both RFCs on IANA Considerations and close the RTP payload registry.
  • V3C
  • SCIP
    • Bernard working with authors and IESG to address DISCUSS comments.
    • Meeting with IESG on Thursday, February 8, 2024
      • Technical issues appear resolved.
      • SCIP document availability issue appears resolved.
      • Editorial modifications under discussion with IESG (more later)

9

10 of 68

Agenda

  1. Note Well, Note Takers, Agenda Bashing, Draft status, IANA Registries (Chairs, 10 min)
  2. RTP Payload Format for SCIP (D. Hanson, M. Faller, 15 min)

draft-ietf-avtcore-rtp-scip/ballot/

draft-ietf-avtcore-rtp-j2k-scl

draft-ietf-avtcore-hevc-webrtc

draft-ietf-avtcore-rtp-over-quic

draft-ietf-avtcore-rtp-sframe

draft-ietf-avtcore-rtcp-green-metadata

draft-majali-avtcore-rtcp-fb-timing-cfg

draft-hsyang-avtcore-rtp-haptics

​

10

/

11 of 68

RTP Payload Format for SCIP

draft-ietf-avtcore-rtp-scip

11

Dan Hanson

Mike Faller

Start time: 09:10

End time: 09:25

12 of 68

RTP Payload Format for SCIP

  • draft-ietf-avtcore-rtp-scip-08 published on February 1, 2024
    • Updated Abstract and Introduction to strongly emphasize the purpose and scope of the document
    • Reorganized Payload Format (Section 4)
      • Added figure illustrating the SCIP payload format within an RTP packet
      • Added to Congestion Control Considerations that AVPF/SAVPF are OPTIONAL
      • Added “Use of Augmented RTP Transport Protocols with SCIP” section explicitly addressing comments regarding FEC, multiplexing/BUNDLE, …
        • Stated that such protocols, as long as they do not modify the payload, are OPTIONAL
    • Updated Security Considerations to indicate that use of SRTP is OPTIONAL

12

13 of 68

RTP Payload Format for SCIP

  • draft-ietf-avtcore-rtp-scip-09 in progress
    • Update some statements regarding security provided by SCIP
    • After meeting with IESG, they will provide us an “acceptable” disclaimer regarding the security claims of SCIP.
      • IETF has not performed a security review of SCIP.
    • Really want to finish IESG review before board changes in March
  • Needs 3 more YES or NO OBJECTION positions to pass:
    • 1 Yes
    • 7 No objection
    • 1 DISCUSS
    • 3 Abstain
    • 3 No record

​

13

14 of 68

High-performance�JPEG 2000 RTP payload format

draft-ietf-avtcore-rtp-j2k-scl

​

14

Start time: 09:25

End time: 09:35

P. A. Lemieux

15 of 68

Update

15

16 of 68

HEVC Profile for WebRTC

draft-ietf-avtcore-hevc-webrtc

​

16

Bernard Aboba

Philipp Hancke

Start time: 09:35

End time: 09:50

17 of 68

Progress Report

  • HEVC support in WebCodecs
  • HEVC support in WebRTC
  • Open Issues (https://github.com/aboba/hevc-webrtc/issues)
    • Issue 20: Clarify SPS/PPS/VPS Requirement before kefyrame
    • Issue 22: Issues with Receive-only codecs

17

18 of 68

HEVC WebCodecs Support

  • Config tester
  • Chrome 119 (stable)
    • Supports HEVC hw-only decode
      • Examples: Surface Pro 7, 8, Surface Book 3, AMD rx5700 GPU
      • Encode behind a flag (--enable-features= PlatformHEVCEncoderSupport)
        • Enable by default resolved as “Won’t fix” (1502354)
  • Edge
    • HEVC and AV1 decode support restored in 122.

18

19 of 68

HEVC WebCodecs Support (cont’d)

  • Safari
    • Safari 17.4: WebCodecs VideoEncoder/VideoDecoder + VP8/VP9/H.264 in hardware w/temporal scalability
      • Devices: Mac OS X, iOS iPad/iPhone.
    • Safari Technical Preview R188+: Adds support for H.265/AV1 decode/encode in hardware.
      • AV1 supports temporal scalability, H.265 does not.
      • Discovery
        • WebCodecs decoding bug (262950) (still open)
    • NB: “Lockdown mode” disables WebCodecs in Safari.

19

20 of 68

MacBook Air M2 Running Sonoma, Safari Test Preview R188

https://webrtc.internaut.com/wc/isup/

20

chrome://gpu (no HEVC/AV1 enc)

AV1 SVC (Enc)

HEVC no SVC (Enc)

21 of 68

HEVC Support in WebRTC

  • Test pages (media capabilities, getCapabilities)
  • Chrome
    • WebRTC Tracking bug (13485)
      • Packetization merged
      • Depacketization work in progress, expected to fully land in 1Q 2024
      • Includes support for SDP, RTP payload format
  • WebKit
    • WebRTC Tracking bug (242921)
      • PR 19703 (enable HEVC by default, merged)
        • Not visible in TP 188, but in a future release
      • PR 20422 (sync with libWebRTC upstream)
        • Branch conflicts, some merged Chrome CLs not yet ported
    • Discovery

21

22 of 68

Issue 20: Clarify SPS/PPS/VPS Requirement before kefyrame

  • Desire to avoid H.264 issues:
  • H.264 encoders that did not update the SPS/PPS ID even if those parameters changed.
  • Matching (and applying) in-band parameter sets to an IDR.
  • Question: IRAP picture types include: IDR, CRA, BLA
    • Is it required to provide SPS/PPS/VPS prior to CRA and BLA in addition to IDR?
    • Reasoning: If CRA/BLA change parameters (e.g. resolution, frame rate, temporal layers) new parameter sets might be necessary. Best to require them rather than taking risks.
    • Recommended text (now in Section 2 of -02):

“An IDR/CRA/BLA sent MUST always be preceded by the relevant parameter sets sent in a packet (not necessarily a separate packet) with the same RTP timestamp as the IDR/CRA/BLA.”

​

​

22

23 of 68

Issue 22: Issues with Receive-only codecs

  • Some WebRTC browsers will be able to send and receive HEVC (Safari) while others (Chrome) may only support receiving HEVC.
  • Problems have been reported with receive-only H.264 profiles, so issues are expected with HEVC as well.
    • Can Chrome (receive-only) successfully negotiate reception of HEVC with Safari that can send/receive HEVC?
      • Desired result: Chrome sends H.264 to Safari and receives H.265 from Safari.
      • Requires codec preference manipulation via setCodecPreferences(), discussed in draft-uberti-rtcweb-rfc8829bis Section 4.2.6.
        • Does setCodecPreferences() only affect received codecs, even with a send-only m-line?

23

24 of 68

Issue 22: Issues with Receive-only codecs (cont’d)

  • Scenarios
    • Offer from Safari with a send/recv m-line preferring H.265, then H.264
      • Answer from Chrome with send/recv m-line with H.265 and H.264
      • Predicted result (not tested): Safari will send H.265 to Chrome and will receive H.264 from Chrome
    • Offer from Chrome with a send/recv m-line
      • Answer from Safari with send/recv m-line
      • Problem: Chrome Offer will not include recv-only codecs (H.265) on a send/recv m-line, even when setCodecPreferences() is used to prefer H.265.
        • Chrome send/recv Offer includes only H.264.
        • Likely result: Safari sends H.264 to Chrome and receives H.264 from Chrome.
        • Chrome can Offer recv-only, Safari Answer send-only but now we need two m-lines!

24

25 of 68

Issue 22: Issues with Receive-only codecs (cont’d)

  • draft-uberti-rtcweb-rfc8829bis Section 4.2.6 says:
  • The setCodecPreferences method sets the codec preferences of a transceiver, which in turn affect the presence and order of codecs of the associated "m=" section on future calls to createOffer and createAnswer. Note that setCodecPreferences does not directly affect which codec the implementation decides to send. It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer. Even when a codec is excluded by setCodecPreferences, it still may be used to send until the next offer/answer exchange discards it.
  • The codec preferences of an RtpTransceiver can cause codecs to be excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated "m=" section will be excluded. The codec preferences cannot add media formats that would otherwise not be present. The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer, in which case the order of the media formats in the associated "m=" section will follow the specified preferences.

25

26 of 68

Issue 22: Issues with Receive-only codecs (cont’d)

  • Discussion is occurring here:
    • AVTCORE:
      • WebRTC-HEVC Issue 22
    • W3C WEBRTC WG:

26

27 of 68

Comments? Next steps?

  • ?

​

​

27

28 of 68

RTP over QUIC

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

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

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

​

28

Mathis Engelbart, Jörg Ott, Spencer Dawkins

Start time: 09:50

End time: 10:10

29 of 68

Remaining Open Issues

29

  • We have 12 open issues remaining as of 12 February 2024
  • We have PRs for 5 of them
  • We plan to close 3 more with no action on this specification ("FIN-WAIT")
    • One enhancement for a follow-on specification
    • One issue that's "Not Just RTP" on QUIC interaction with ICE
    • One issue that's been half-resolved (other half will be new issue)
  • One "Not Just RTP" issue on policy-based path selection
  • Remember this when we get to the Last Slide

30 of 68

#50: QUIC and ICE

30

  • Author proposal:
    • Solved when QUIC working group provides a solution for NAT traversal
    • The RoQ specification defines a new ALPN for session establishment, but the RoQ protocol defines how RTP works on top of an established QUIC connection, no matter how UDP connectivity is reached
    • Mathis explained this at IETF 118 and hasn’t heard any other opinions on this
    • Close as External Doc

31 of 68

#51: MP-QUIC

31

  • Author proposal:
    • RoQ doesn’t care if the QUIC connection is single or multipath
    • We have limited our discussion to QUIC as defined in published RFCs, and draft-ietf-quic-multipath hasn't been WGLCed yet
    • RoQ over MP-QUIC might benefit from guidance on MP-Scheduling, but that can be done in a separate document
    • Mathis explained this at IETF 118 and hasn’t heard any other opinions on this
    • Close as NextDoc

32 of 68

#65: RTP/non-RTP multiple connections

32

  • We should not care about coordination between multiple connections
  • The discussion in the issue is actually about other topics:
    • Using low latency CC for media and data will result in slower data but that is desired anyway
    • Multiplexing should be solved in a different standard (i.e., QUIC extension)
    • No need for multiplexing since it will be handled by P2P QUIC
  • We think the CC issue is nothing we should try to solve
  • Close this issue and open a new one on multiplexing (next slide)

33 of 68

#???: Multiplexing

33

  • We have discussed multiplexing many times in the past but it keeps coming up
  • We currently have a flow ID that allows multiplexing RTP and anything else
  • Martin Thomson said we shouldn’t assume our framework will be important enough to justify something super generic: https://mailarchive.ietf.org/arch/msg/avt/FRISykFrlo5BPkr2_KWvDzc2-QU/
  • We now have draft-engelbart-quic-data-channels and draft-engelbart-multiplex-roq-qdc. These drafts showcase how to extend RoQ to enable all the use cases that were asked for when we discussed multiplexing without letting rtp-mux-quic bypass ALPN.

34 of 68

#84: CC for RTP/non-RTP sharing a connection

34

  • Asked for input at IETF 118
  • Not much feedback
  • We are providing relevant guidance in 7.3
  • Ultimately, this is up to the application
  • Any action required?
    • Yes, section 7.3 needs some clean up (PR#155)
    • At least the bullet point list should include using a single QUIC connection as discussed in the last paragraph of the section.

35 of 68

#86: Coalescing RTP packets in a single QUIC packet

35

  • PR#152 is still open for this discussion
  • How much more can we say in this document?
  • This is guidance to application developers that interacts with QUIC stacks
  • The decision to delay sending a packet, and how long, is up to the sender
  • Our guidance is literally RTP heuristics to deal with QUIC's heuristics

36 of 68

#87: RT-CC applicability

36

  • Was discussed at IETF 118
  • Authors' understanding of the discussion at IETF 118:
    • We need to provide some considerations, i.e., use a congestion controller that keeps latencies low (already in the draft)
    • There don’t need to be many details about this in the draft
  • Mathis and Spencer's opinion
    • We don't need, and shouldn't include, more specific guidance
  • Any action required?
    • We plan to close as "won't fix"

37 of 68

#111: Check SHOULD requirements

37

  • This has been listed as TODO: Review while we were still adding text
  • The draft is stable enough to allow us to review this now
  • Spencer is reviewing this - PR#158

38 of 68

#114: Guidance on RoQ DATAGRAM use

38

  • Current Draft: Senders MAY combine both modes by sending some RTP/RTCP packets over the same or different QUIC streams and others in QUIC datagrams.
  • Discussion at IETF 118 resulted in two contradictory suggestions
    • For a given media stream, choose either streams or datagrams, don’t switch
    • Allow senders to optimize, e.g., audio/datagrams and video/streams or even I-frames/streams and P-/B-frames/datagrams, FEC use cases
  • Switching should be allowed as a decision made by senders
    • We're giving guidance. This isn't normative, and applications may have reasons to switch between datagrams and streams for a single media flow
    • Any guidance we give should be understood to be helpful in the general case

39 of 68

#115: Motivation: Exploiting multiple connections

39

  • gchandok observed that Section 1.2.6 is about multiple PATHS
    • Spencer renamed the section, and edited to distinguish between connections and paths
  • Current specification says

Connection migration may be desirable for a number of reasons, but to give one example, this allows a sender to distinguish between more costly cellular paths and less costly WiFi paths, with no action required from the application.

  • gchandok made this suggestion

[RTP applications do need to know about path used being expensive/not since the application may want to use a lower bitrate cap for an expensive path like cellular. So some action will be required from the application possibly at connection setup time to specify the caps in wants to use for each interface type]

  • That's a helpful observation, but Spencer treated it as out of scope in PR #154

​

40 of 68

#126: Review Appendix B

40

  • This has been TODO: Review for a while
  • It's time to review Appendix B
  • Watch for any PRs linked to this issue (PR#156)
  • Please check our work, in case we miss anything!

41 of 68

#147: Use term Datagram consistently

41

  • This has been TODO: Review
  • Watch for any PRs linked to this issue
  • Please check our work, in case we miss anything!

42 of 68

#149: Incorrect use of rate adaptation

42

  • We've merged PR #153
  • Please pay special attention to the revised definitions of "congestion control" and "rate adaptation"!
  • This has been a source of confusion for a while …

43 of 68

#157: Add references for IANA references

43

  • References go in Section 8.4 and for each table in Appendix B subsections.
  • What happened was, @SpencerDawkins used the RFC references that CREATED each registry of interest, but didn't add references for the registries themselves.
  • THAT'S what Spencer needs to fix.

44 of 68

Time to revisit SDP for RTP over QUIC

44

  • Spencer created draft-dawkins-avtcore-sdp-rtp-quic a LONG time ago
    • It seemed better to spend time on the rtp-over-quic specification first
    • Spencer let this expire, planning to circle back to it
  • It's time to return to the SDP draft, and align it with RoQ
    • Spencer is interested in collaborators for this, of course

45 of 68

Next Steps

45

  • Do people agree with the directions we've shared here?
  • Do people agree RoQ as currently specified will be worth publishing?
    • We are deferring support for P2P communication to QUIC WG
    • We've talked about the need for a corresponding SDP specification
    • Are there any other show-stoppers that are in scope for AVTCORE?
  • Does WGLC by IETF 120 seem realistic to the working group?
  • Are We Almost Finished With This Specification???

46 of 68

RTP Payload Format for SFrame

draft-ietf-avtcore-rtp-sframe

​

46

Peter Thatcher

Start time: 10:10

End time: 10:20

47 of 68

The New Problem Harald Noticed

The Inner Payload Type is encrypted, �so an SFU can't read it or rewrite it

�

47

48 of 68

The Solution I'm Proposing

The Inner Payload Type is put in each "outer" packet,

so the SFU can read it and write it

​

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|L| media PT | media frame ID |

| fragment index | fragment ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

​

Everything except for the fragment is encrypted hop-by-hop, not end-to-end, which means it can be read and rewritten. This is already in the draft. The header extensions are also not encrypted hop-by-hop and so can be read and rewritten.

​

48

49 of 68

The Old Problem

Do all SFrame packets contain all of the inner-codec's header extensions?��Then the SFU can read and rewrite all of them. But there might be too much to duplicate (like for Dependency Descriptor). ��Is that worth avoiding? If so, how do decide which are excluded?�

​

49

50 of 68

Implementations?

Last time: "Harald Alvestrand: Google is interested in implementing this, but unsure of timeframe."��Any changes?

�

​

50

51 of 68

RTP Control Messages (RTCP) for Green Metadata

51

Yong He

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

Start time: 10:20

End time: 10:30

52 of 68

Comments and draft updates

  • Comments from virtual interim May 2023
    • how to handle a request for temporal and spatial resolutions greater than what was negotiated in the SDP
    • describe what the receiver does which works better than trying to control what the sender is doing
    • it is desirable to send some response, so the sender won’t keep retransmitting
  • draft-ietf-avtcore-rtcp-green-metadata-02
    • 4.2.1 Message format: It is to note that the returned value (Frame Rate, Picture Width, Picture Height) may differ from the requested one, for example, in cases where a media encoder cannot change its frame rate or picture resolution, or when the requested temporal and spatial resolutions are larger than the temporal and spatial resolutions negotiated via SDP, or when pre-recorded content is used.
    • 5 Security Consideration: Spoofed or maliciously created feedback messages of the type defined in this specification can have the following implications:
      • severely increased picture resolution due to false TSRR messages that sets the picture width and height to a value that is larger than the value negotiated via SDP;
      • severely increased frame rate due to false TSRR messages that sets the frame rate to a value that is larger than the value negotiated via SDP

52

53 of 68

RTCP feedback Message Timing Configuration

53

S. Majali

https://datatracker.ietf.org/doc/draft-majali-avtcore-rtcp-fb-timing-cfg/

Start time: 10:30

End time: 10:40

54 of 68

RTCP feedback Message Timing Cfg

54

  • Motivation
    • Do not have provision to provide timing configuration for specific RTCP message
    • “trr-int” defined in RFC4585 defines minimum interval between two regular (full compound) RTCP packets
  • Published draft-majali-rtcp-fb-timing-cfg-00 on Feb-06
  • Proposing optional SDP parameter “fb-min-time” proposed to provide timing configuration

a=rtcp-fb:<rtcp-fb-pt> <rtcp-fb-param>;fb-min-time=<fb-min-time-val>

rtcp-fb-pt = /fmt ; as defined in SDP

rtcp-fb-param = SP "app" [SP byte-string]

/ SP token [SP byte-string]

/ ; empty

fb-min-time-val = feedback message minimum time value in milliseconds

​

55 of 68

RTCP feedback Message Timing Cfg

55

  • SDP Examples
    • RTCP feedback transport-cc with minimum time of 50 milliseconds. Receiver to send transport-cc feedback every 50 milliseconds elapsed

a=rtcp-fb:96 transport-cc ;fb-min-time=50

    • RTCP feedback PLI (Picture Loss Indication) with minimum interval of 50 milliseconds. Configuration can be used by the receiver to trigger PLI when no decodable unit is available to decode for 50ms.

a=rtcp-fb:96 nack pli;fb-min-time=50

    • RTCP feedback Generic NACK with minimum time of 1 milliseconds. Receiver to wait for 1 milliseconds before NACK RTCP feedback message is sent on packet loss.

a=rtcp-fb:96 nack;fb-min-time=1

56 of 68

RTCP feedback Message Timing Cfg

56

  • Synchronization counter
    • “fb-min-time” may have an OPTIONAL parameter “sync-counter”, to synchronize with RTP timestamp change.
    • Example: transport-cc feedback with minimum time of 50 milliseconds and synchronization counter set to 3. Receiver to send transport-cc feedback on every 3rd change in RTP timestamp change or 50 milliseconds elapsed, whichever happens earliest.

a=rtcp-fb:96 transport-cc ;fb-min-time=50;sync-counter=3

​

57 of 68

RTP Payload for Haptics

57

H. Yang

X. de Foy

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

Start time: 10:40

End time: 10:50

58 of 68

Status

  • Published Draft Version 01 on Feb 05 (based on Spencer’s comments)
    • Updated some minor update (terminology, abbreviation)
    • Updated haptic definition in section 3
    • Clarified definition of RTP Payload Header
    • Updated Optional parameter definition
    • Rephrased the text in section 4.3

​

  • Next steps
    • Sharing FDIS document
    • Request for WG adoption call
    • Minor update before or after adoption call

​

58

59 of 68

Spencer’s review

(terminology, abbreviation)

•Abbreviation

​

​

​

•Terminology (sync → independent , non-sync→ dependent)

​

59

60 of 68

Spencer’s review

Updated definitions in section 3

•Adding some terms in definition section 3

​

60

61 of 68

Spencer’s review

Clarified definition of RTP Payload Header

•Moving the example of header usage to another section to clarify the definition.

​

61

62 of 68

Spencer’s review

Updated the optional parameters definition section

•Adding reference information

​

62

63 of 68

Spencer’s review

Rephrased the text in section 4.3

63

64 of 68

Normative Reference : FDIS Document

  • ISO/IEC DIS 23090-31,Information technology - Coded representation of immersive media - Part 31: Haptics coding will be ready for sharing with the IETF community in a couple of weeks (a few pending editorial changes).

​

  • Due date is Feb 29, 2024.

​

​

64

65 of 68

Next steps

​

  • We plan to update the draft shortly with text on aggregation and security

​

  • Suggestions and feedback are welcome

​

  • We are looking for people interested in reviewing, implementing or participating in the draft.

​

  • Request for WG adoption call

​

​

​

65

66 of 68

Wrapup and Next Steps

66

Chairs

Start time: 10:50

End time: 11:00

67 of 68

Action Items and Next Steps

  • Chairs
    • Call for adoption of Viewport and Region-of-Interest-Dependent Delivery of Visual Volumetric Media.
    • Figure out WG GitHub repo hierarchy, transfer individual repos there.
    • Find a place for store test vectors and the like
  • Authors
    • SCIP: prompt resolution of Eric’s remaining IESG DISCUSS.
      • Time is of the essence since IESG will turn over in March and only a few more IESG meetings left.
    • V3C: Resolution of comments from Christer.
    • HEVC-WebRTC: discuss JSEP one-way codec issues with RTCWEB WG which is not yet closed.
    • RTP over QUIC: Identify the “Experimental” plan (questions and actions) to be followed up after publication of an Experimental RFC.
    • Green metadata: WGLC once reviews are completed and issues are resolved.

67

68 of 68

Thank you

Special thanks to:

​

The Secretariat, WG Participants & ADs

68