IETF 93 - Payload Notes Chairs: Roni Even, Ali Begen Note takers: Stephan Wenger, Mo Zanaty Jabber scribe: Jonathan Lennox Recording: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#PAYLOAD Payload Status Update Chairs https://www.ietf.org/proceedings/93/slides/slides-93-payload-0.pdf H265: SDP directorate review by Flemming Andreasen noted no overall grammar and no formal grammar for fmtp parameters. No interoperability issues, so no change needed, according to Stephan, Magnus Westerlund, others. Magnus: Recommendation is in how-to: when you have complex parameters, then you should include ABNF. Otherwise not. Stephan: there is an ABNF in the draft for one complex parameter. No need to change h265 draft so it should progress. VP9 RTP Payload Format (Magnus Flodman) draft-ietf-payload-vp9-00 https://www.ietf.org/proceedings/93/slides/slides-93-payload-3.pdf Flexible and Non-Flexible GOF (Group of Frames) structure: Mo thinks this may be useful for other codecs, authors have no issues with reusing this. Stephan noted that other codecs (e.g. H.264/5) have other means to convey this within the payload itself not in payload headers. The authors need to go to the list about the payload vs. payload header option. Flexible FEC RTP Payload Format (Varun Singh) draft-ietf-payload-flexible-fec-scheme-00 https://www.ietf.org/proceedings/93/slides/slides-93-payload-1.pdf Bernard Aboba: How can a sender signal specific FEC patterns, like only protect the base layer of SRST RTP streams? Authors clarified that no static signaling (e.g. SDP) is necessary since the sender is free to pick dynamic patterns and all receivers must handle this. Slide 8: open issue: Jonathan: putting SSRC into RTP payload is scary (layer violation) Mo: we are already in layer violation due to SN; could go Fecframe model Jonathan: ??? something about Perc, fec over encrypted payload Magnus: Dislikes no support for jumbo packets > 4KB. Better to support 64KB packets and expand the FEC header. Stephan agrees with expansion. Different opinions expressed on whether source flow SSRC(s) should be included in the FEC header, or other identifiers like MID or the newly proposed ESID/RSID. Also different views on signaling multiple source flows. Result: Need a side meeting to decide what source flow identifier is used to associate with a FEC repair flow and how to handle multiple source flows. Varun will lead and copy the list. Side meeting notes: It was decided that 1. We will need to revisit how FEC operates with PERC-enabled middleboxes. This is currently a non-goal. 2. An identifier will be in the FEC payload. For now this is SSRC. However, if a needed this could be replaced by another identifier (e.g., RSID). Jonathan said: Even if we define identifiers like RSID in the future, the identifier in FlexFEC should nonetheless remain an SSRC. The reason is that the FEC receiver needs to know, after an SSRC change, whether the packets being FEC’d come from the old SSRC or the new SSRC. It was also pointed out that the FEC format, as a degenerate case, can also perform retransmission (by creating a FEC packet that covers only a single source packet). This may be able to resolve some of the annoyances of the RFC 4588 RTX format, notably in a BUNDLE context — it avoids payload type explosion (because the source PT is in the packet), and gives you stream association automatically. 3. Keep the encapsulated length as 16 bits. Add the 4 bits of SSRC Counter elsewhere, this is still TBD. To summarize the version 3/3 in the slides was accepted. MELPe Codec (Roni Even for Victor Demjanenko) draft-demjanenko-payload-melpe-03 https://www.ietf.org/proceedings/93/slides/slides-93-payload-4.pdf Stephan has read it and thinks it is a well written RTP payload format draft. No other reviewers, so chairs will ask the list to review. Chairs will go to the list for adoption. Interleaved RTP Payload Format (Rachel Huang) draft-huang-payload-rtp-interleave-00 https://www.ietf.org/proceedings/93/slides/slides-93-payload-2.pdf Jonathan: Note that PT must be the same. Rachel: yes Jonathan: assumption aggregation never changes number of packets. Rachel: yes Jonathan: with more flexible sequence number mechanism, you could do better Rachel: yes Imed: Interleave an IDR, what’s the gain? Rachel: Only applying interleaving on IDR frames helps to reduce the delay caused by interleaving, which is now considered by some ISPs who provide 4K IPTV services still on DSL access network.