RTCWEB Signaling. Ma/hew Kaufman

Transcription

1 RTCWEB Signaling Ma/hew Kaufman

2 Scope Web Server Browser Browser

3 Scope Web Server HTTP Already standardized Beyond that several possibilifes Browser Browser

4 Scope Web Server Browser Browser Media Transport In scope for IETF DTLS- SRTP + ICE?

5 Scope Web Server Web Server Signaling federafon Could be in scope for IETF SIP + SDP O/A? Browser Browser

6 Scope Web Server Browser Browser

7 Scope Web Server Browser App (HTML + JS) Javascript APIs CODECs HTTP/WS RTP Browser

8 Scope Web Server Browser App (HTML + JS) Javascript APIs CODECs API In scope for W3C Several possibilifes HTTP/WS RTP Browser

9 IdenFfied In- Scope QuesFons 1. Should the format of what travels over HTTP between the web server and the browser be standardized? 2. What should the media transport protocol be? 3. Should the format of what travels between two federated web servers be standardized? 4. What should the Javascript API be like?

10 QuesFon 1 Should the format of what travels over HTTP between the web server and the browser be standardized? Choices: No, leave it up to the applicafon developer Yes, it should be SIP Yes, it should be a lightweight SIP Yes, it should be not SIP but use SDP Offer/Answer

11 QuesFon 1 No, leave it up to the applicafon developer Maximum flexibility Works for RTC applicafons other than building phones Yes, it should be SIP Very high implementafon bar, and sfll missing funcfonality Yes, it should be a lightweight SIP Slippery slope (early media? prack? redirect? Etc?) Not actually compafble with exisfng servers/services Yes, it should be not SIP but use SDP Offer/Answer Does make answering QuesFon 3 (and implemenfng federafon) easier. Does not support cases where early determinafon of capabilifes is useful Does not work well for some mulfparty and other non- phone use cases Not clear why the IETF or W3C should be telling Javascript programmers what they can send over XMLHTTPRequest anyway

12 QuesFon 2 What should the media transport protocol be? Not in scope for these slides, but I think we can solve this with exisfng IETF protocols +/- minor changes

13 QuesFon 3 Should the format of what travels between two federated web servers be standardized? Choices: Yes, it should be SIP Yes, it should be something else No, that s up to the two website operators to work out

14 QuesFon 3 Yes, it should be SIP + SDP O/A There are good arguments for this This is probably an area that IETF should explore later Yes, it should be something else The arguments for this are weaker No, that s up to the two website operators to work out They will probably choose to use SIP and SDP O/A anyway But this quesfon is NOT the same as QuesFon 1 If we need SDP O/A for federafon, it doesn t necessarily follow that SDP O/A must be used between the browser and its web site

15 QuesFon 4 What should the Javascript API be like? Before answering: Is this really an IETF problem, or is this a W3C problem? Choices are on mulfple axes How much of calling is built in? How does address selecfon and NAT traversal work? How are CODECs selected?

16 QuesFon 4 How much of calling is built in? One extreme: phone = new SIPPhone(); phone.call( sipuser@example.com ); This would then imply that SIP travels over the wire to the servers (maybe not even over HTTP!) and SDP offer/answer is used Not much room for innovafon here

17 QuesFon 4 How much of calling is built in? Other extreme: Javascript developer gets a PeerConnecFon object Runs an ICE implementafon in Javascript using calls that allow for sending and receiving of STUN probes Gets a camera object and a codec object and examines the capabilifes NegoFates the capabilifes with the web server using a proprietary protocol Explicitly sets the camera and codec properfes A/aches the codec to the PeerConnecFon and starts sending Lots of interesfng (though perhaps difficult) Javascript code to write and new applicafons to build

18 QuesFon 4 How much of calling is built in? And of course many intermediate choices

19 QuesFon 4 How does address selecfon and NAT traversal work? OpFon A PeerConnecFon is told what to connect to by being passed a blob of SDP PeerConnecFon runs ICE, generates more blobs of SDP containing ICE candidates as events, these are transported to the other end and pushed into the PeerConnecFon

20 QuesFon 4 How does address selecfon and NAT traversal work? OpFon B PeerConnecFon is told what to connect to by being passed a candidate address or list of candidate addresses PeerConnecFon runs ICE, generates blobs of SDP (or some other format) containing ICE candidates as events, these are transported to the other end and pushed into the PeerConnecFon

21 QuesFon 4 How does address selecfon and NAT traversal work? OpFon C PeerConnecFon has APIs that let the developer implement ICE or any equivalent algorithm that meets the STUN probe is used to prove far end wants to receive media security requirement

22 QuesFon 4 How does address selecfon and NAT traversal work? This is discussed in drap- cbran- rtcweb- nat- 01

23 QuesFon 4 How are CODECs selected? SDP offer/answer is used between the PeerConnecFon objects at each end over their event- based signaling channel and the results determine the CODECs in use Direct Javascript APIs allow the developer to query for capabilifes and then select a CODEC and specify necessary parameters

24 QuesFon 4 SDP offer/answer is used between the PeerConnecFon objects at each end over their event- based signaling channel and the results determine the CODECs in use TempFng, as you already need this channel for ICE Actually, the Javascript can manipulate the SDP that comes out and even parse it and convert it to another form so this doesn t mandate sending SDP over the wire (QuesFon 1) But it would probably encourage developers to simply pass the SDP intact from end to end

25 QuesFon 4 Direct Javascript APIs allow the developer to query for capabilifes and then select a CODEC and specify necessary parameters Allows for the building of applicafons which query for capabilifes before offering calling to the user Allows for more complex mulf- party calling (know in advance which codec one could switch everyone else to in order to support a new joiner with a more limited set) Leverages the Device APIs that are coming into existence

26 QuesFon 4 Direct Javascript APIs allow the developer to query for capabilifes and then select a CODEC and specify necessary parameters STILL ALLOWS for SDP Offer/Answer on the wire, simply by wrifng some Javascript to create it STILL ALLOWS for SDP Offer/Answer in the federafon case, by creafng SDP at the browser in Javascript or up at the server

27 QuesFon 4 Direct Javascript APIs allow the developer to query for capabilifes and then select a CODEC and specify necessary parameters COULD STILL LEVERAGE the MMUSIC work performed for each new CODEC by exposing the capabilifes and parameter sesng as compafble strings, rather than individual Javascript knobs COULD EVEN use SDP, but not as SDP offer/answer, instead as a command mechanism as in other protocols like MGCP

28 RecommendaFons Try to avoid solving problems that are out of scope We have enough that are in scope already Try to maximize the flexibility by turning the browser into the next operafng system in which we create RTC applicafons, not by bolfng a phone on the side

29 Therefore QuesFon 1: No. Up to the app developer, just as in web clients QuesFon 2: Probably DTLS- SRTP, possibly with mulfplexing added, and ICE for NAT traversal QuesFon 3: Leave this up to the site operators for now and revisit whether addifonal SIP (or other) work is needed at a later Fme QuesFon 4: Don t build a SIP phone into the browser Implement ICE in Javascript if pracfcal, otherwise implement ICE nafvely and pass the ICE candidates in and out via strings in a reasonable format (perhaps even SDP) Don t build SDP offer/answer into the PeerConnecFon object (where it doesn t belong anyway) for CODEC selecfon, instead expose APIs for querying capabilifes and sesng CODEC and CODEC parameters. If possible, leverage types and parameter serializafon created by MMUSIC.