1. RTP Usage for CLUE draft-lennox-clue-rtp-usage-02 Clue WG, IETF 83, 27 March 2012 Jonathan Lennox jonathan@vidyo.comjonathan@vidyo.com Allyn Romanow allyn@cisco.comallyn@cisco.com Paul Witty paul.witty@balliol.oxon.orgpaul.witty@balliol.oxon.org 1RTP Usage for CLUE

2. RTP Usage: What’s New since the Interim Draft -03 explicitly lists what we think are the important requirements of an RTP architecture for CLUE. The solution in the document (which is essentially unchanged) is designed to meet these requirements. In this presentation, I’ll go over these requirements, their motivations, and some implications. RTP Usage for CLUE2

3. Req. Media-1 “It must not be necessary for a Clue session to use more than a single transport flow for transport of a given media type (video or audio).” The number of transport flows (NAT/FW usage, ICE setup) shouldn’t need to increase as the number of captures does. This requirement is worded so as to allow BUNDLE but not require it. RTP Usage for CLUE3

4. Req. Media-2 “It must, however, be possible for a Clue session to use multiple transport flows for a given media type where it is considered valuable (for example, for quality-of-service reasons).” There are good reasons to use multiple transports, sometimes – but these won’t usually need to increase with the number of captures. This is also necessary for backward compatibility with separate Main/Presentation media lines. RTP Usage for CLUE4

5. Req. Media-3 “A Clue endpoint or MCU must be able to send sources corresponding both to composited and switched captures.” Hopefully obvious; the point is that the MCU or endpoint distribution point can both forward sources (switched captures) and synthesize sources (composited captures). RTP Usage for CLUE5

6. Req. Media-4 “It must be possible for an original source to move among switched captures (i.e. at one time be sent for one switched capture, and at a later time be sent for another one).” The example is the three-camera-to-two- screen: RTP Usage for CLUE6

7. Req Media-4: source moving Receiver, getting two switched captures (Left and Right). Initially, source 1 is sent for the Left switched capture, source 2 for the Right switched capture. RTP Usage for CLUE7 SenderReceiver 1 2 3

8. Req Media-4: source moving After a change, source 2 is sent for the Left switched capture, source 3 for the Right switched capture. Notice that source 2 was Right, but is now Left. RTP Usage for CLUE8 SenderReceiver 1 2 3

9. Req. Media-5 “It must be possible for a source to be placed into a switched capture even if the source is a ‘late joiner’, i.e. was added to the conference after the receiver requested the switched source.” This means that it’s not possible to specify in advance, in signaling, which sources could go into which captures, without continuous roster updates. RTP Usage for CLUE9

10. Req. Media-6 “Whenever a given source is assigned to a switched capture, it must be immediately possible for a receiver to determine the switched capture it corresponds to, and thus that any previous source is no longer being mapped to that switched capture.” For many decoder architectures, specific decoding resources are allocated per capture (e.g. particular codec chips). It’s not possible to pass received packets to a decoder without knowing which capture’s hardware is handling it. RTP Usage for CLUE10

11. Req. Media-7 “It must be possible for a receiver to identify the actual source that is currently being mapped to a switched capture.” Meta-data about a source (the name of the current speaker, e.g., for a source from an MCU) is very useful to be displayed. RTP Usage for CLUE11

12. Req. Media-8 “It must be possible for a source to move among switched captures without requiring a refresh of decoder state (e.g., for video, a fresh I-frame), when this is unnecessary.” A use case is a single decoder decoding (e.g.) images of the N most recent speakers, each of which is represented by a switched source. Clearly, as sources go from being the 1 st, to the 2 nd, to the 3 rd, …, most recent speaker, they shouldn’t need a fresh I- frame each time. This means a switched capture can’t be implemented as a single, mixed RTP source (with CSRCs), since decoding state doesn’t carry over across RTP sources. RTP Usage for CLUE12

13. Req. Media-9 “If a given source is being received for more than one reason (e.g. if it corresponds to more than one switched capture at once, or if it has also been requested explicitly), it should be possible for only one copy of the source to be sent.” Since bandwidth is limited, sending duplicate copies of the same media (except when explicitly needed, e.g. for simulcast) is wasteful. RTP Usage for CLUE13

14. Req. Media-10 “For the sake of middleboxes, on the wire the signaling and media flows should, as much as possible, look like currently-defined usage of existing protocols.” I.e., don’t make RTP not look like RTP on the wire. (This will probably get re-worded in a future version.) RTP Usage for CLUE14

15. Req. Media-11 “The solution should seek to minimize the processing burden for boxes that distribute media to decoding hardware.” In many architectures, a single box receives media traffic, then farms it out to decoding hardware. The protocol should make this as light-weight as possible (subject to other constraints). RTP Usage for CLUE15

16. Comments? Reactions? Should any of these not be requirements? Are there more requirements that should be added? RTP Usage for CLUE16