JSEP Update Justin Uberti & Cullen Jennings IETF 85.

Slides:



Advertisements
Similar presentations
1 Carol Davids © 2010 WebRTC Standards Summary. 2 What is WebRTC? WebRTC refers to protocols as well as Javascript APIs used to enable realtime communications.
Advertisements

Re-INVITE Handling draft-camarillo-sipping-reinvite-00.txt
CLUE REQUIREMENTS IETF 80 Allyn Romanow
11 Halloween, 2011 Cullen Jennings
Reza hooshangi ( ). short history  One of the last major challenges for the web is to enable human communication via voice and video: Real Time.
Real-time Transport Protocol (RTP) Recommendations for SIPREC (draft-eckel-siprec-rtp-rec-01) Charles Eckel IETF-81, Quebec City, July.
ICE Jonathan Rosenberg dynamicsoft. Issue 1: Port Restricted Flow This case does not work well with ICE right now Race condition –Works if message 13.
RTSP Interoperability Bakeoff Ron Frederick
RTP Multiplexing draft-rosenberg-rtcweb-rtpmux Jonathan + {Rosenberg, Lennox}
Session-ID Requirements for IETF84 draft-ietf-insipid-session-id-reqts-00 1 August 2012 Paul Jones, Gonzalo Salgueiro, James Polk, Laura Liess, Hadriel.
Introduction to SDP Issues. Content Background Goals SDP Primer RTP Primer Use cases “New” Functionalities in SDP Multiple RTP Streams in SDP Decision.
TURN draft-ietf-behave-turn-07 Philip Matthews, Avaya Jonathan Rosenberg, Cisco Rohan Mahy, Plantronics.
Draft-rosenberg-mmusic-sdp-offer-answer-00.txt Jonathan Rosenberg dynamicsoft IETF 52.
July 10, 2006rtpsec BOF IETF-661 Best Effort SRTP Phil Zimmermann Alan Johnston.
RTCWEB Signaling Matthew Kaufman. Scope Web Server Browser.
SIPREC Conference Recording (draft-kyzivat-siprec-conference-use-cases-01) IETF 89, March 7, 2014 Authors: Michael Yan, Paul Kyzivat, Simon Romano.
Roni Even Jonathan Lennox Mapping RTP streams to CLUE media captures draft-even-clue-rtp-mapping-03 IETF-84.
Slide title minimum 48 pt Slide subtitle minimum 30 pt RTP Multiple Stream Sessions and Simulcast draft-westerlund-avtcore-multistream-and-simulcast-00.
Draft-ietf-mmusic-sdp-tcpmedia-00.txt Dialout.Net, Inc. David Yon TCP-Based Media Transport in SDP.
Curtsy Web
(Business) Process Centric Exchanges
M337 Standards Based Video Interop Interoperability modelling for Video Skype for Business Video Interoperability Server (VIS)
RMCAT Application Interaction draft-zanaty-rmcat-app-interaction-01 Mo Zanaty, Varun Singh, Suhas Nandakumar, Zahed Sarker IETF 90.
Slide title minimum 48 pt Slide subtitle minimum 30 pt RTCWEB Terminology A Discussion of relation between RTCWEB Media Protocol Terminology and the PeerConnection.
Security, NATs and Firewalls Ingate Systems. Basics of SIP Security.
Real-time Transport Protocol (RTP) Recommendations for SIPREC (draft-eckel-siprec-rtp-rec-02) Charles Eckel SIPREC Virtual Interim.
Session Recording (SIPREC) Protocol (draft-ietf-siprec-protocol-09) Leon Portman Henry Lum
1 SIPREC Protocol IETF #80 Authors: L. Portman, H. Lum, A. Johnston, A. Hutton.
SIP working group IETF#70 Essential corrections Keith Drage.
SIP and SIPPING WGsMay, IETF Interim Meeting Orit levin Conferencing Requirements for SIP Based Applications.
IETF-81, Quebec City, July 25-29, 2011
Christian Groves Describing Captures in CLUE and relation to multipoint conferencing draft-groves-clue-multi-content-00 CLUE Interim meeting (09/13)
BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.
CLUE RTP usage Andy Pepperell
Interactive Connectivity Establishment : ICE
TURN Jonathan Rosenberg Cisco Systems. Changes since last version Moved to behave terminology Many things moved into STUN –Basic request/response formation.
IETF WG Presentation1 Urooj Rab Audio/Video Transport.
Call Completion using BFCP draft-roach-sipping-callcomp-bfcp IETF 67 – San Diego November 7, 2006.
A RTCP-based Retransmission Protocol for Unicast RTP Streaming Multimedia draft-podolsky-avt-rtprx-00.txt Matthew Podolsky, Koichi Yano, and Steven McCanne.
draft-ivov-mmusic-trickle-ice E. Rescorla, J. Uberti, E. Ivov
RTP Usage for CLUE draft-lennox-clue-rtp-usage-02 Clue WG, IETF 83, 27 March 2012 Jonathan Lennox Allyn Romanow
RTP Functionalities for RTCWEB A combined view from the authors of draft-cbran-rtcweb-media-00 draft-cbran-rtcweb-media-00 draft-perkins-rtcweb-rtp-usage-02.
RTP Usage for CLUE IETF 82 – 14 November 2011 Jonathan Lennox Allyn Romanow Paul Witty.
Draft-ietf-p2psip-base-08 Cullen Jennings Bruce Lowekamp Eric Rescorla Salman Baset Henning Schulzrinne March 25, 2010.
Allyn Romanow Stephen Botzko Robert Hansen Signaling Requirements for implementing the.
SDP Security Descriptions for Media Streams draft-ietf-mmusic-sdescriptions-02.txt November 14, 2003 Flemming Andreasen Mark Baugher.
Slide title minimum 48 pt CAPITALS Slide subtitle minimum 30 pt WebRTC Data Channels draft-ietf-rtcweb-data-channel-00 Salvatore Loreto Randell Jesup Michael.
Real-time aspects June 19, 2016
Codec Control for RTCWEB
The Transport Layer Congestion Control & UDP
CLUE Framework Interim Meeting Feb 15, 2012 Mark Duckworth
SDP Offer/Answer mechanism to negotiate the usage of bundled media
CLUE WG Interim Meeting San Jose, CA Sept , 2012
CLUE WG Interim Meeting San Jose, CA Sept , 2012
Virtual Interim CLUE Signalling discussion
draft-ietf-simple-message-sessions-00 Ben Campbell
IETF 82 BFCPBIS WG Meeting
IETF#67 – 5-10 November 2006 FECFRAME requirements (draft-ietf-fecframe-req-01) Mark Watson.
Options to Transport CLUE Messages draft-wenger-clue-transport-01
Multi-Media Concepts and Relations
IMTC SIP Interconnect and SuperOp
IMTC SIP Interconnect and SuperOp
Session Initiation Protocol (SIP)
Issues from telemedical-callflows
CLUE Use Cases 02 – comments and proposal
RTCWeb Data Channel Management
draft-ietf-p2psip-base-03
SCTP in SDP draft-loreto-mmusic-sctp-sdp-07
A RELOAD Usage for Distributed Conference Control (DisCo) – Update
Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams draft-ietf-avtcore-multiplex-guidelines-06 Magnus.
Presentation transcript:

JSEP Update Justin Uberti & Cullen Jennings IETF 85

Recap Implementation Status Report from W3C meeting Changes since last draft Pending Issues Topics

Resolved o Serial forking/Trickle ICE interaction o Special offer creation  Capabilities, ICE restart, etc Deferred o Cloning o Rehydration Recap from last IETF

Implementation Status Current WebRTC implementations o Public: Chrome 23 Beta, Chrome 24 Dev o Behind flag: Mozilla 18 Alpha Using W3C RTCPeerConnection API o createOffer/Answer, setLocal/Remote now async o startIce removed, ICE starts automatically Getting mileage on key WebRTC functionality o Opus o ICE, STUN, TURN o SRTP o DTLS o BUNDLE o MSID

W3C Status Issues recently resolved o Format of SessionDescription, Candidate objects o State machines for signaling and ICE o Timings for MediaStream-related callbacks o Mapping of MediaStreams to m= lines o Error handling TBD issues o getUserMedia timing o Handling of multiple streams/tracks o Exact format of stats API o DTMF API

Changes to JSEP -02 Removed old cruft including ROAP stuff Removed stuff now covered by W3C API spec Clarified applicability of PRANSWER Provided explanation around forking Added a list of SDP that MUST be implemented

Open Issues o Document review notes and feedback o What SDP must be supported o Cloning o Quirks Mode o MSID o Handling of multiple streams o Trickle ICE o Rehydration

Document review notes Richard Ejzak and Andrew Hutton, as well as several others, provided detailed feedback: o JSEP state machine vs RFC 3264 state machine is unclear  Reached agreement on state machine at W3C meeting, need to update draft accordingly o Exact SDP generated by createOffer is not defined, especially in a re- INVITE scenario o Exact handling of SDP by setLocal/setRemote not defined  Starting to nail these down in -02 o Relationship between MediaStreams and m= lines is unclear  Sent proposal, general agreement on this at W3C

Proposal for SDP that MUST be implemented RFC 4566 base SDP spec RFC 5124 to signaling RTP/SAVPF profile RFC 5761 to signal multiplexing of RTP and RTCP RFC 5245 to signaling the ICE candidate RFC 3264 to signal media direction RFC 5888 grouping framework RFC 5576 to signal RTP SSRC values RFC 4572 for DTLS/SRTP Fingerprint RFC 4733 for DTMF draft-spittka-payload-rtp-opus for Opus RFC 5245 for ICE UDP RFC 6544 for ICE TCP

Proposal for SDP that MAY be implemented RFC 5506 to signal Reduced-Size RTCP RFC 3556 with bandwidth modifiers

Should we add? MUST: RFC 6236 Image resolution negotiation RFC 4796 for a=content draft-rescorla-mmusic-ice-trickle for Trickle ICE draft-ietf-mmusic-sdp-bundle-negotiation draft-alvestrand-mmusic-msid for MSID in SDP draft-ietf-mmusic-sctp-sdp for data channel MAY: RFC 3890 TIAS draft-westerlund-mmusic-sdp-bw-attribute

Forking with PRANSWER A ---- offer > PSTN A <-- pr answer PSTN A ---- ringing media ---- PSTN A <---- answer Voic A media Voic

1.PC A1 sends offer to B 2.B sends answer to A1 3.JS clones A1 to form A2 4.A2 is in the offer state, just like A1 5.A1 installs B's answer 6.Media between A1 and B 7.C sends answer to A2 8.A2 installs C's answer 9.Media flows between A2 and C 10.JS application figures out what to do with the media from B and C Compare with PRANSWER: 3. A1 installs B's answer as PRANSWER 4. Media between A1 and B 5. A1 installs C's answer 6. Media between A1 and C (only) Forking with Cloning PC A1PC B Offer Ans1 PC A2PC C Offer Ans2 Clone RTP

Cloning - Details The cloned Peer Connection would share same ports and ICE ufrag/pwd on local side, but have an independent state machine. To work this needs: o Use of ICE and ability to demux by 5-tuple o Ability to allocate 2x encode/decode resources o Ability to allocate 2x bandwidth o Ability of app to handle simultaneous incoming media from multiple locations More complicated than PRANSWER, and more flexible. But do we need it? Don't want to support both. - Can constrained devices handle the 2x requirements above? - Do we need to support 200 after 180 with different SDP?

A recurring question: should JSEP generate "correct" SDP, or "compatible" SDP? e.g. SRTP/AVPF vs RTP/AVP for profile, for devices that croak when they see SRTP/AVPF Our proposal: generate correct SDP by default, but allow app to generate quirky SDP by use of a "QuirksMode" constraint that can be passed to CreateOffer/Answer. Quirks Mode

MediaStream ID MediaStream ID (MSID) is the glue that binds MediaStreamTracks (from the JS API) to SSRCs in SDP: m=video a=ssrc:1 msid: Necessary to support multiple MediaStreamTracks and SSRCs. Not the same as SSRC; MediaStreamTrack can map to multiple SSRCs (e.g. SSRC-muxed FEC) Not the same as CNAME, CNAME can be shared between tracks (i.e. they are synced). Need to understand distinction between MSID and recent CLUE "srcname" and "capture ID" proposals.

Stream Selection General problem: o A has M streams (e.g. 2 cameras), B has N streams (e.g. MCU with 5 participants) o How are streams described in SDP? o How does B select some or all of the streams from A, and vice versa? o How does this work when B is a legacy device that can only receive one stream?

Stream SDP A's SDP: o m=video a=ssrc:1 msid: a=ssrc:2 msid: B's SDP: o m=video a=ssrc:11 msid: a=ssrc:12 msid: a=ssrc:13 msid: a=ssrc:14 msid: a=ssrc:15 msid:

To get a subset of streams, we can use draft-lennox-mmusic- sdp-source-selection to request streams, and specify hints on how they should be sent. A sends to B, give me User1 in HD, User2/3 in SD: o m=video a=remote-ssrc:11 recv:on a=remote-ssrc:11 imageattr:* [x=1280,y=720] a=remote-ssrc:12 recv:on a=remote-ssrc:12 imageattr:* [x=640,y=360] a=remote-ssrc:13 recv:on a=remote-ssrc:13 imageattr:* [x=640,y=360] a=remote-ssrc:14 recv:off a=remote-ssrc:15 recv:off Stream Selection SDP

The ideal case (1.5 RTT) o A sends list of sources to B as offer o B sends the set of A's sources it wants to receive as answer o B sends its list of sources to A as offer o A replies with the set of B's sources it wants to receive as answer Fallback case (B is legacy) o A sends list of sources to B as offer o B replies with answer, no remote-ssrc attribute o A sends its "default" stream to B This mostly lines up with direction of CLUE WG, need to nail down details Stream Selection O/A

Trickle ICE New draft, draft-rescorla-mmusic-ice-trickle, specifies the details on how trickle ICE can be used with new and legacy endpoints JSEP is almost fully compliant with this draft: o createOffer with no candidates generates a RFC compliant offer ( :1 address) o Indication of end-of-candidates provided by API o Can support "No Trickle", "Half Trickle", and "Full Trickle" o Just need to add ICE option to indicate trickle support

Rehydration Previous approaches to rehydration have focused on persisting and restoring local call state, but SDP does not provide enough info to do this reliably: ICE ports and credentials RTP seqnum SRTP ROC DTLS key material While we could find ways to persist and restore this information, we favor a simpler approach called Session Restart.

Session Restart Session restart is an ICE restart plus restart of crypto, resulting in a new offer/answer exchange (re-INVITE) to the remote peer. For rehydration: Store old local description Refresh page and create new PeerConnection Apply old local description as offer createOffer("RestartSession") to get new local description with new ICE and crypto Apply new local description as offer and send it Apply received answer as remote description Could also be used to fix non-rehydrated calls...

Questions

(Backup) Other approaches Plan for handling multiple streams of the same media type is to combine them on the same m= line, and demux based on a=ssrc. However, need some way to indicate that endpoint supports this kind of demuxing. o a=ssrc not sufficient; doesn't have right semantics, and endpoint may not send any SSRCs (i.e. no a=ssrc lines) o New a=max-recv-ssrc proposal covers this, but has IPR constraints o We only need a single bit, i.e. a=i-can-demux-ssrcs; suggest we roll this into source selection draft or new draft