MANE Activity Group (AG) Update Chair: Bernard Aboba- Principal Architect, Skype/Lync, Microsoft

1. MANE AG Update
Chair: Bernard Aboba

2. •MANE AG approved by Board on 20 May 2014, succeeding the MANE Study Group.
–First Meeting 11 June 2014
•Chair:
–Bernard Aboba (Microsoft)
•Web page:
http://www.imtc.org/uc/mane-task-group/
•Mailing list:
imtc_mane@mail.imtc.org
MANE AG

3. •Every two weeks at 1 PM Eastern (10 AM Pacific).
–Next Meeting: 29 October 2014.
•Using Vidyo’s system:
–http://bit.ly/IMTCatVidyo
•To join: send email to help@imtc.org
Meeting Schedule

4. RFC 6184:
•A Media Aware Network Element (MANE) is “A network element, such as a middlebox or application layer gateway that is capable of parsing certain aspects of the RTP payload headers or the RTP payload and reacting to the contents.”
draft-ietf-avtcore-rtp-topologies Section 3.7:
•The selective forwarding middlebox…. selects which parts of a scalable bitstream (or which bitstream, in the case of simulcasting) to forward to each of the receiving endpoints. The decision may be driven by a number of factors, such as available bit rate, desired layout, etc.
What is a MANE? What is an SFU?

5. MANE: A Video Router
5
VR b
B
a
A
c
C
b
B
c
a
Control Plane
(RTCP/SDP)
Forwarding Plane
(RTP)

6. Forwarding Plane
•RTP header (e.g. Payload Type, SSRC, CSRCs, Sequence Number, RTP header extensions, etc.)
•RTP Payload
Control Plane
•(S)RTCP feedback messages
•STUN/TURN/ICE
•Codec-specific messages (e.g. PACSI NAL)
–Key management (e.g.DTLS/SRTP(-EKT))
•Signaling (SIP/SDP, H.323, JSON, etc.)
Inside a MANE

7. •RFC 6184: A network element, such as a middlebox or application layer gateway that is capable of parsing certain aspects of the RTP payload headers or the RTP payload and reacting to the contents.
–Informative note: The concept of a MANE goes beyond normal routers or gateways in that a MANE has to be aware of the signaling (e.g., to learn about the payload type mappings of the media streams) and that it has to be trusted when working with Secure Real-time Transport Protocol (SRTP).
•What if the MANE is NOT trusted with SRTP keys, and therefore cannot access the RTP payload?
•Come to MANE AG and find out!
Some Questions

8. Initial MANE implementations have typically supported only a single codec (H.264/SVC) and have frequently relied upon proprietary technology in order to implement features and achieve required performance. As a result, interoperability is lacking.
Today with SVC entering the mainstream, there is an increasing need for MANEs to support multiple codecs in an interoperable way. As an example, WebRTC- enabled browsers now support SVC codecs, creating a demand for MANEs compatible with them.
Conclusions of the MANE SG

9. The IMTC MANE AG will summarize existing MANE implementations as well as reviewing existing standards and draft proposals, in order to document the existing state of the art and its implications for interoperability.
What Do We Do?

10. •Review of the state of the art in IETF RFCs and Internet-Drafts:
•Terminology: MANE, SFU, etc. – 11 June
•MANE taxonomy – 11 June
•Forwarding plane
•Transport: MST, SST – 11 June
•Security: SRTP/SRTCP and key management – 9 July
•Header extensions – 9 July
•Multiplexing: RTP/RTCP, A/V mux, DTLS/RTP/STUN/TURN – 11 June
Work Items

11. •Control plane
•RTCP Feedback messages – 11 June
•BW estimation messages
•Signaling: SDP/RTCP
•Simulcast
•Scalable Video Coding
•Resilience: RTX, FEC: 17 September
Work Items

12. •Review of existing implementations
•What standards have been implemented?
•What gaps have been filled by proprietary technology?
•Output
•A document summarizing existing implementations.
Work Items (cont’d)