1. Encoding syntax alternatives Oct 8 th 2013, CLUE design team meeting

2. Encodings in CLUE Allows multiplexing of multiple streams onto a single m-line Encodings are expressed in CLUE advertisment Uses SSRC (or appId) to differentiate between streams in SDP Also uses SSRC to relate CLUE encodings to specific m-lines (could use appId, or could use label)

3. Offer SDP and Advertisment m=video...... a=ssrc:1234 a=ssrc:2345 a=ssrc:3456 a=sendrecv Capture Scene 1: Capture 1: Left (Encoding Group 1) Capture 2: Center (Encoding Group 1) Capture 3: Right (Encoding Group 1) Capture 4: Switched Capture Scene Entry 1: 1,2,3 Capture Scene Entry 2: 4 Simultaneous Sets: 1,2,3,4 Encoding Group 1: Encoding 1: H264, 1080p30, ssrc=1234 Encoding 2: H264, 1080p30, ssrc=2345 Encoding 3: H264, 1080p30, ssrc=3456 Offer SDP Advertisment

4. Answer SDP and Configure m=video...... H264@720p30 a=sendrecv Capture 1, Encoding 1 Capture 2, Encoding 2 Capture 3, Encoding 3 Answer SDP Configure

5. Expressing receiver limitations fmtp parameters refer to total for all streams – Not all parameters can be subdivised (max-fs) – Allows a single over-large stream to be sent fmtp parameters refer to total for any one stream Need to decide how to deal with different stream needing different limits – Reproduce limits in CLUE – Receiver must split streams onto seperate m-lines

6. Answer SDP and Configure m=video...... H264@720p30 a=sendrecv Capture 1, Encoding 1, 720p30 Capture 2, Encoding 2, 720p30 Capture 3, Encoding 3, 720p30 Answer SDP Configure

7. Dealing with multiple m-lines Disaggregated use case requires multiple m- lines, as may receiving streams with different limits Hard to write rules for how to change the number of m-lines in use.

8. Advantages/Disadvantages Can express full send limitations Fewer O/As and m-lines required Need to reinvent codec-specific language Varying the number of m-lines is painful Media-specific information CLUE messages limits interworking with other ongoing IETf work.

9. Encoding constraints in CLUE Alternate approach, more similar to ‘encodings in SDP’ approach Seperate m-line per stream Send limitations are expressed in CLUE

10. Offer SDP and Advertisment m=video...... H264@720p30 a=label:A a=sendrecv m=video...... H264@720p30 a=label:B a=sendrecv m=video...... H264@720p30 a=label:C a=sendrecv Capture Scene 1: Capture 1: Left (Encoding Group 1) Capture 2: Center (Encoding Group 1) Capture 3: Right (Encoding Group 1) Capture 4: Switched Capture Scene Entry 1: 1,2,3 Capture Scene Entry 2: 4 Simultaneous Sets: 1,2,3,4 Encoding Group 1: Encoding 1: H264, 1080p30, label=A Encoding 2: H264, 1080p30, label=B Encoding 3: H264, 1080p30, label=C Offer SDPAdvertisment

11. Upshots of this approach m-lines can now be sendrecv, as there is no need to use sendonly to express the send limits Receive limits are expressed via SDP

12. Answer SDP and Configure m=video...... H264@720p30 a=sendrecv m=video...... H264@720p30 a=sendrecv m=video...... H264@720p30 a=sendrecv Capture 1, Encoding 1 Capture 2, Encoding 2 Capture 3, Encoding 3 Answer SDP Configure

13. Advantages/Disadvantages Can express full send limitations Can use sendrecv for many m-lines, reduces number of O/As needed Need to reinvent codec-specific language