1 / 16

RTP Payload Format for Multiple Flows FEC

RTP Payload Format for Multiple Flows FEC. IETF 76 – November 2009. draft-peck-fecframe-rtp-mf-00. Orly Peck, RADVISION orlyp@radvision.com. Background. protecting RTP packets from multiple flows This draft FEC scheme generic Specifies RTP payload format for such FEC packets

tyrell
Download Presentation

RTP Payload Format for Multiple Flows FEC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RTP Payload Format for Multiple Flows FEC IETF 76 – November 2009 draft-peck-fecframe-rtp-mf-00 Orly Peck, RADVISION orlyp@radvision.com

  2. Background • protecting RTP packets from multiple flows • This draft • FEC scheme generic • Specifies RTP payload format for such FEC packets • Aims to solve source-synchronization problems • Multiple Flows includes Multi-Session and Multi-Source Transmission

  3. Multi-Source From draft-schierl-avt-rtp-multi-session-transmission-00: • multi-session transmission: In multi-session transmission, media data from a single media source is split over multiple RTP sessions. The term "layered multicast" is equivalent to multi-session transmission for sessions using multicast addresses. • multi-source transmission: In multi-source transmission, data from a single media source is sent as several RTP streams in the same RTP session. The sources contained in an RTP session are identified by their synchronization source identifiers (SSRCs) or, if combined by a RTP mixer, by their contributing source identifiers (CSRCs), as defined in RTP [RFC3550].

  4. Use cases • Video conferencing • 3D video delivery: 2D + depth (multi-session) • Telepresence (multi-source) • SVC (Scalable Video Coding) • streaming • interactive video

  5. Concept

  6. Design Approach • Defining FEC-MF header for Repair packets with information regarding the subsequent FEC headers.

  7. Source Synchronization • For Multi-source protection including multiple-session and multiple-source flows, a unique flow identifier is required. • Unique identifier: fec-source-flow + SSRC • Problem: SSRC list creates large overhead • Proposed solution: Marker bit indicating if SSRC list is present.

  8. RTP header for repair packets 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Marker bit (M) – Indicates if a list of SSRC identifiers is appended to the FEC-MF header. • Payload Type (PT) – dynamically determined in SDP • Sequence Number • initiated randomly [rfc3550] • One higher than number in the previously transmitted repair packet • Timestamp – corresponds to repair packet transmit time • Synchronization source (SSRC) – randomly assigned [rfc3550]

  9. FEC-MF header for repair packets 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Flows | FID | FID | FID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID | FID | Padding | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC Identifiers | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Num flows – number of flows protected in this FEC block • FID – flow ID. Determined by SDP. Correlated to a FEC header appended to the MF-Header. Number of FIDs = Num Flows. • SSRC Identifiers – list of SSRC identifiers from the source RTP headers. Number of SSRC identifiers is 0 if M-bit in RTP header is 0. Otherwise, equals Num Flows.

  10. IANA Registration • Register subtype name fec-mf for application type • Required parameters • FEC-Scheme as <encoding parameter> in ‘rtpmap’ line. • Scheme-specific parameters in ‘fmtp’ line.

  11. Example – SDP v=0 o=orly 1122334455 1122334466 IN IP4 fec.example.com s= MF FEC Example t=0 0 a=group:FEC S1 S2 R1 m=video 30000 RTP/AVP 100 c=IN IP4 224.1.1.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=0 a=mid:S1 m=video 30001 RTP/AVP 100 c=IN IP4 224.1.1.2/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=1 a=mid:S2 m=application 30000 RTP/AVP 110 c=IN IP4 224.1.2.1/127 a=rtpmap:110 fec-mf/90000/reed-solomon-fec a=fmtp:110 max_N:5; repair-window:200000; symbol-size:8 a=mid:R1

  12. example

  13. Example – cont (FEC headers) Example using Reed-Solomon with RTP, according to draft-galanos-fecframe-rtp-reedsolomon-00

  14. Optional Alternative (1) • Using CSRC in RTP header. • CC field represents number of source flows “multiplexed” • CSRC list contains the SSRC identifiers of each source flow.

  15. Optional Alternative (2) • Using RFC 5576 (SSRC grouping) • Using additional parameter in SSRC line • a=ssrc:11111 cname:user3@example.com;fec-source-id:1 • Advantage: using 1 byte for each source flow identifier, instead of 4 bytes for each SSRC.

  16. Next Steps • Decide on a design approach for protecting multi-flows • Get draft reviewed by AVT group • Comments are welcome!

More Related