Minutes for RTCWEB, IETF82 Chairs: Magnus Westerlund Cullen Jennings Ted Hardie Minute takers: Cary Bran, Stephan Wenger, Jean Mahoney Audio Recordings: http://www.ietf.org/audio/ietf82/ietf82-201abc-20111115-0855-pm.mp3 http://www.ietf.org/audio/ietf82/ietf82-201abc-20111117-0855-am.mp3 Meetecho archives:http://www.meetecho.com/ietf82/recordings#RTCWEB1 http://www.meetecho.com/ietf82/recordings#RTCWEB2 9:00 - 11:30 TUESDAY, November 15, 2011, Room 201 ABC ===================================================================== 9:00 WG Adminstrative and Status Update (WG chairs) draft-ietf-rtcweb-overview-02 draft-ietf-rtcweb-use-cases-and-requirements-06 draft-ietf-rtcweb-rtp-usage-01 Notes on other meetings occuring this week: Lunch with CLUE on Thursday - Byo Lunch MMUSIC meeting - sdp signaling bundling mechanism will be discussed. Not discussing the overview docs - please review and provide feedback; they should be stable. Usage doc - not finished but please comment 9:10 Report from AVTCORE WG (Magnus Westerlund) draft-lennox-rtcweb-rtp-media-type-mux-00 draft-holmberg-mmusic-sdp-bundle-negotiation-00 draft-westerlund-avtcore-transport-multiplexing-01 draft-westerlund-avtcore-multiplex-architecture-00 Transport multiplexing discussed, but no consensus reached. There's a call for consensus on the avtcore list. Please provide input The WG expects to update both docs 9:20 Report from W3C (Harald Alvestrand) Harald provided background on how w3c meetings are held, then went over the list of discussion topics good summary at: http://www.w3.org/2011/04/webrtc/wiki/October_31_-_November_1_2011 Conclusions - W3C wg wants to review getusermedia function (IPR etc.). They don't want to admit that they looked at the data connection proposal. We'll split into separate spec so they don't have to make IPR commitments. - Mediastream track - not immutable - need i/fs for changing it - Data API - Justin's proposal was well received. - Hints and stats as key/value Questions: Igor - what is XR? Harald - XR extended reporting blocks Igor - what protocol has been selected? Harald - SDP, check the meeting minutes. They are open. There's rumored to be a non-public list for members (but all work is happening on the public list). Need to tweak stats without tweaking the standard. Spec Status First public working draft - released Oct 27, 2011 It's not stable, but the W3C WG believes its doing fine. ========================================================================== 9:30 Signalling Discussion (Cullen) draft-jennings-rtcweb-signaling-01 = ROAP - what it is, what are the issues? = What is implemented in the browsers? SDP What's the minimal things to add to SDP to make it work with the OA model? Need it to be extensible. Cullen proposes json = What's the architecture? = The first model separate the javascript app from the browser. Set up SRTP session between browsers. The javascript is proprietary. API from browser to javascript app - use ROAP to traverse the i/f. Another model model supports a basic api, an implmentation can use SIP or something. ROAP provides info. Third model Roap to sip signalling gw. Takes the roap msgs (transport agnostic), translate to SIP to talk to something else. Ted, commenting on the slide - the red line should go through the proxy. = Telling offer from answer = It's the pair that informs what you can do for the media flow. Matthew coffman - Are we talking API? Cullen - or OTW protocol Matt - why are offer and answer on separate call backs? Cullen - don't care about encoding. Need to know if it's a O or A. Partha - Question on the gw. ROAP doesn't have the info to build a ROAP to sip gw. There's a draft that's has a strawman. Is this in scope? It will add semantics to the protocol. Cullen - In scope to design that the protocol can gw to sip and jingle. Partha - The ROAP message doesn't go to the web server, just the gw. Cullen - it does, the red line means along the green and orange info corresponds to 3264 SDP logic Partha: Is it sip Magnus - Do we have consensus? Cullen - We don't. We need to set up the SDP streams. Do we need a protocol? Matthew doesn't. Most people think we do. Igor - There's two sets of APIs here. Could there be something on top without going to the browser? Cullen - The browswer does what it wants. Doesn't have to use SDP. There could be another API into the medial control. It's assumed that this is the OA. Can do something different in javascript in the lower level. We don't have any proposals yet on it. Igor - Feature interaction problems Cullen - like to see examples. Unkown speaker - Clarify - a protocol or API. The draft talks about a API so does the mail list? Cullen - the mail list is confused. We are talking about both. Unkown speaker - In the ROAP spec, do we define the baseline of extensions for SDP Cullen - The wg needs to specify mandatory pieces of SDP. I'm keeping ROAP separate from that. Another draft will identify mandatory RFCs. However, we're stuck with SDP. Unknown speaker - Leaving the SDP negotiation to the browser, it would know about the codecs? Cullen - yes Unkwon speaker - you have a mixture of the browser negotiating and the javascript negotiating. Cullen - javascript tells peer API that it wants to add a datastream. Unkown speaker - isn't the OA require in the java script. Cullen - I see that you want a MIME type. But others don't want to standardize MIME types. Two Options - use SDP to negotiate or not. Colin perkins - I agree SDP is correct choice. However, if we want to move away, need to ensure that we have MIME type for SDP so we have a future path for negotiation. Multipart alternative. Unkown speaker - does it make sense to use a jsonized version rather than SDP. Can we drive all of this from javascript? Could you do the entire signaling state machine in javascript Cullen - Could we encode this a different way? I don't care. But talking about specifying SDP mandatory extensions, we could extend that also. I want either SDP or not SDP. Cullen - 3264 has a message for getting options. If we had an api for getting capabilities, would make sense. Unknown speaker: Can you generate the message at the app and feed it to the browser? Cullen - have to say what the port you want is. The browser can do that, not the app. The app can use hints for simple things. SDP is rich enough to describe anything you want to do with RTP. Unkown speaker: Question about jingle (ICE) and app layer. Cullen - jingle is richer than SDP. There are things that you can specify with jingle that SDP can't handle. This needs to be backwards compatible. Unkown speaker points out that putting MSRP in a message would break going through the ROAP gw. Cullen - THe pink unicorns have to be registered with SDP. Others want TCP between end points. Let's take it offline. Unkown speaker - Need to put in something that maps to a SIP feature tag. Cullen - need to have an option to make comprehension mandatory, don't have that yet. Unkown speaker - ROAP name may need some change. Cullen - consider a name change - take it to the list. = identifying sessions = Need an identifier that can be updated. Since we interested in the pair. Combine offererSessionId and answererSessionID. Ensure it's globally unique. We haven't decided to support forking. Forking would result in different session ids. = extending OA = Negotiate change to session. There's a sequence number. If you replace a OA pair with a new - has same session id but different sequence number. Christer - Isn't this in the sdp oline? Cullen - inquired about usage of oline and didn't get good answers. Christer - keep the oline alive for interworking, like with sip. Igor - what's the lifetime of a session? Cullen - as long as you can send/receive rtp. I suggest a shutdown message later in the slides. In the multicase, they will be managed independently. = What can go wrong? = There will be some errors, also need to know that things worked. Need an OK message. When you send an offer, can't send another - limitation of SDP. Thus, timing issues. OK is sent to answer. magnus - why use sequence number? Cullen - no guarantee of order of delivery. = Ice pipelining = Ice takes time so you want the other end to do ice processing as soon as possible. But you want to wait until you have consent. = moreComing flag = Tells the other end that you can't close the offer. And you will send another answer. Lennox - how does this gw to sip if sip was the offer. Cullen - in early media, it would set morecoming to No. When a web client doesn't want to do early media, it sends one answer. I need to have someway to express in SDP enough info to start doing ice. Enough to reserve the part we'll multipex over. Lennox - what happens when early answer hits the gw Cullen - send an 180 and then a 200. If you think it's back implement prack. Harald - unhappy with morecoming. It will lock the browswer for a long time. It would be better if an answer was answer. Then send to another. Cullen - let's come back to this - I have a slide. = 1-800-gofedex Use Case = A sip message with 180 with critical information that you can't lose. Do we want to deal with serial forking? There won't be more than 1 media stream setup. Parallel forking - have to deal with multiple streams at the same time. Matthew - there is no such thing as early media. Cullen - agree, but it describes an SDP interaction model. Matthew - morecoming flag is a problem - if it blocks new offers that need to happen. Cullen - would have to replace 3264 with something else. Unknown speaker - ROAP doesn't have an early dialog concept. Need to clarify what we mean by early media. Cullen - should not use the term early media. Cullen - 3264 is underspecified, but you can have an offer at any time you can make another offer, but can't pair it with other open answers. Harald - let's take it to the list. = Alternative design with media gw = Can't figure out how to do it with out the gw being a media relay as well. Unknown speaker - either the gw supports changing ports on the browser or not. It needs to send an error ("I'm an incompetent implementation"). Cullen - port change mid call is different - it's handled. Unknown speaker - it has to map an answer into an offer. Christer - this is messy. We can support forking, fake the browser to think that it has forked. Cullen - let's look at that. I was trying to pick between forking and morecoming. Hadriel - It has to be a parallel fork, not serial fork. If we build SDP OA into the browswer, need ROAP. Matthew - The slide shows why we shouldn't use SDP and use javascript. There's not a problem at the end. Otherwise you're just reimplementing SIP. Cullen - I want to keep browser2browser interactions simple Paul K - Slide is showing an illegal case according to 3261, if it's not a forking case. Cullen - don't want to change 3264. I want the 1800-gofedex case to work.