RTP Usage for CLUE IETF 82 – 14 November 2011
-
Upload
joan-maldonado -
Category
Documents
-
view
24 -
download
2
description
Transcript of RTP Usage for CLUE IETF 82 – 14 November 2011
![Page 1: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/1.jpg)
RTP Usage for CLUEIETF 82 – 14 November 2011
Jonathan Lennox [email protected] Romanow [email protected] Witty [email protected]
![Page 2: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/2.jpg)
Source Multiplexing: Motivation
• A telepresence session has lots of sources– Dozens at a time• e.g. for a continuous presence screen
– Out of a pool of hundreds possible• Sessions have asymmetric numbers of sources• So the usual SIP model (a single media source
per session) doesn’t scale, and is needlessly complex.
![Page 3: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/3.jpg)
Source multiplexing
• Send all sources (of the same media type) over a single RTP session, single transport flow.– Protocol behavior is straightforward– NAT traversal is fast, port consumption is low.– SDP is small, and looks “normal” to middleboxes.
• This was always part of RFC 3550 (RTP), but not widely used until recently.
![Page 4: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/4.jpg)
Source multiplexing: exceptions
• There may be cases where we still need to use multiple RTP sessions– Most obviously, if sources should have different
transport characteristics, e.g. different QoS.– This doesn’t preclude having those sessions
themselves carry multiple sources!
![Page 5: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/5.jpg)
Source multiplexing: complications
• Some things get complicated• One-source-per-session was a fairly pervasive assumption.
– Even though RTP always supported source multiplex.
• Details of RTCP behavior.• Backward compatibility.
• Not in scope for CLUE – general IETF architecture.• See:
• draft-westerlund-avtcore-multiplex-architecture-00
• draft-lennox-rtcweb-rtp-media-type-mux-00
• The AVTCORE WG, and probably other groups too.
![Page 6: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/6.jpg)
CLUE-specific Complications
• When you receive a source, you need to know why you’re receiving it.– Which requested capture it corresponds to.
• This can change dynamically– Source collision / restart.– Switched captures.– Source moving between switched captures.
• Three camera to two screen: LC → LR → CR → LR
• This is needed before stream decoding starts.– Many systems: which screen to display on → which decoder
hardware to use.
![Page 7: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/7.jpg)
Demultiplexing RTP Streams in Same Session
![Page 8: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/8.jpg)
Case to Consider: Infinite Sources
EndPoint
EndPoint
EndPoint
EndPointMCU
![Page 9: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/9.jpg)
How to Demultiplex
• SSRC• MuxID• Hybrid
![Page 10: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/10.jpg)
SSRCs Pros
• Already in RTP packet• Unique number
![Page 11: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/11.jpg)
The issue with SSRC: 3 streams sent
SSRC 1
SSRC 2
SSRC 3
VC1
VC2
VC3
![Page 12: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/12.jpg)
2 of 3 streams stop
SSRC 1
SSRC 2
SSRC 3
VC1
VC3
VC2
![Page 13: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/13.jpg)
VC2 and VC3 continue with different SSRC
SSRC 1
SSRC 5
SSRC 4
VC1
VC2
VC3
![Page 14: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/14.jpg)
Timeline
A BSSRCS 1, 2, 3
SSRCS 1, 4, 5
A decides toChange VC2 &
VC3VC2 = SSRC 4; VC3 = SSRC 5
Aim is tominimise this
time
![Page 15: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/15.jpg)
SSRCs Challenges
• SSRC changes– Requires metadata to link SSRC to CLUE capture– Requires storage for lookup tables– Timing requirements for codec when SSRC
changes
![Page 16: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/16.jpg)
Where to put metadata
• CLUE message– Advantage – reliable– Disadvantage – reliability can cause large delays, esp.
when lots of conference participants. Switching latency
• RTCP, e. g., new SDES– Advantage – in data path, can arrive early– Disadvantage – RTCP lossy, receiver won’t know how
to route media– Can use acks and retrans, but can cause high latency
![Page 17: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/17.jpg)
Sending metadata
A BSSRCS 1, 2, 3
SSRCS 1, 4, 5
A decides toChange VC2 &
VC3VC2 = SSRC 4; VC3 = SSRC 5
HighLatency Acknowledge updated mapping
![Page 18: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/18.jpg)
Multiplex ID Advantages
• Tag media packet with muxID– Header extension
• Advantage – no lag time when SSRC changes– When stream changes, muxID can remain – Receiver can add useful info to muxID
![Page 19: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/19.jpg)
Multiplex ID Cons
• Disadvantage – high processing costs– Scoped only within one hop– Adding, modifying expensive due to SRTP auth– requires re-auth of whole packet, could limit
throughput– Might need to re-auth due to SDP anyway
![Page 20: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/20.jpg)
Sending Multiplex IDs
A BSSRCS 1, 2, 3
SSRCS 1, 4, 5 with updated Multiplex IDs
A decides toChange VC2 &
VC3LowLatency
![Page 21: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/21.jpg)
Hybrid Scheme, Pros and Cons
• MuxID only in packet of the first frame of media (typically an IDR/GDR).
• All other packets demux using only the SSRC• Advantage - Mitigates high switching latency
and high processing cost• Can’t send without IDR so must wait anyway
![Page 22: RTP Usage for CLUE IETF 82 – 14 November 2011](https://reader038.fdocuments.us/reader038/viewer/2022110211/5681350b550346895d9c5d6b/html5/thumbnails/22.jpg)
Hybrid Challenges
• Additional complexity in demuxing – check if muxID, if not use SSRC
• Needs more investigation