Tuesday, 31 January 2012< ^ >
martin.thomson has set the subject to: RTCWEB WG
Room Configuration

[14:03:04] Andreas Kuckartz joins the room
[16:02:09] Cullen Jennings joins the room
[16:16:52] <Cullen Jennings> We will be starting in 45 minutes
[16:16:52] Andreas Kuckartz leaves the room
[16:26:32] Paul Hoffman joins the room
[16:27:09] <Paul Hoffman> Cullen: the WebEx is set to phone-in only, no computer audio.
[16:27:16] <Paul Hoffman> Is that intentional?
[16:27:38] rillian joins the room
[16:29:19] <rillian> do none of us have voice, or is my client broken?
[16:30:21] <Paul Hoffman> We just started talking.
[16:30:37] <Paul Hoffman> rillian: are you hearing us?
[16:30:52] <Paul Hoffman> rillian: I don't see you listed as having called in.
[16:32:00] Neil Stratford joins the room
[16:32:07] <rillian> I haven't called in yet
[16:34:36] <Paul Hoffman> You need to call in; they have WebEx set up for this meeting as call-in onlyl
[16:35:07] <rillian> just joined
[16:37:55] Magnus joins the room
[16:38:05] <Magnus>
[16:38:13] burn joins the room
[16:39:33] <Magnus> This page contains slides
[16:39:44] <rillian> thank you!
[16:40:09] Jonathan Lennox joins the room
[16:40:42] joins the room
[16:40:52] Spencer Dawkins joins the room
[16:41:02] <> RTCWEB Interim Meeting, January 30, 2012
[16:41:23] <> Oops... January 31, 2012
[16:42:47] Neil Stratford leaves the room
[16:42:52] dromasca joins the room
[16:43:13] Neil Stratford joins the room
[16:45:35] <Cullen Jennings> slides are at
[16:46:07] <rillian> have we started yet? call in is quiet.
[16:46:24] <> Meeting has not yet started.
[16:46:31] <rillian> ok, thanks
[16:46:48] <Cullen Jennings> Ted has opened a ticket with AV people on weak audio
[16:46:54] <Cullen Jennings> Not sure what else to do at this point
[16:47:12] <Jonathan Lennox> Shout?
[16:47:19] <Paul Hoffman> We can sometimes hear people on the phone who are not muted. :-) It's not bad yet. No barking or flushing.
[16:47:37] rillian leaves the room
[16:47:40] rillian joins the room
[16:47:43] <rillian> :)
[16:48:29] <Paul Hoffman> Cullen: it's not "weak" at this point, it is non-existant.
[16:48:41] <Cullen Jennings> room is pretty quiet
[16:48:43] <Paul Hoffman> I assumed that you were not even started.
[16:48:45] <Paul Hoffman> Ah, good.
[16:49:07] Spencer Dawkins leaves the room
[16:49:08] <dromasca> we can see shared slides
[16:50:51] Spencer Dawkins joins the room
[16:56:37] leaves the room
[17:02:15] Spencer Dawkins leaves the room
[17:02:17] <Paul Hoffman> I take it we're not supposed to be hearing the hilarity that is happening in the room.
[17:02:41] <rillian> I can hear the occasional mangled syllable
[17:03:01] <rillian> and feedback
[17:03:09] <rillian> otherwise everything is under the noise floor
[17:03:14] Spencer Dawkins joins the room
[17:04:03] <rillian> I heard cullen's question, but that's all
[17:06:34] <Paul Hoffman> FWIW, I am only being a tourist here this morning and will drop off after a bit.
[17:06:45] <Paul Hoffman> But it would be good to know if the audio ends up working. :-)
[17:08:11] Bran, Cary joins the room
[17:08:40] dontcallmedom joins the room
[17:11:36] <dontcallmedom> Today agenda
[17:11:43] <dontcallmedom> IETF Note well
[17:12:36] Hadriel Kaplan joins the room
[17:13:00] joins the room
[17:13:19] rejzak joins the room
[17:13:37] <> Ted shows the Note Well... emphasizes that this applies to contributions, so if you speak (or provide input in the Jabber room) it applies to you. NOTE WELL....
[17:13:58] <> Justin Uberti up, with JSEP Overview slides.
[17:14:13] <rillian> can't hear justin
[17:14:25] <> Justin isn't speaking yet.... just up at the podium.
[17:14:27] <burn> justin isn't talking to the room yet
[17:14:40] <rillian> there we go, sort of
[17:15:07] <Paul Hoffman> It is just barely audible.
[17:15:32] <Paul Hoffman> Like 80% of the words.
[17:15:38] <> Justin: "JSEP arose from an impedance mismatch... looked at "what would it mean for the application to have more control over the signaling process... and not just be a conduit."
[17:15:50] <rejzak> need to improve the audio if possible
[17:16:00] <> 3 dozen slides in two hours... if you have a question, bring it up.
[17:16:34] <> Topcs: Status, Why JSEP? , Theory of Operation, Example Call Setup, Implementation Considerations... JSEP vs. ROAP.
[17:16:58] Martin Thomson joins the room
[17:16:59] <> Status: jsep-00 posted last week.... -01 about to be posted, fixes several issues.
[17:17:01] hta joins the room
[17:17:03] <dontcallmedom>
[17:17:53] Gonzalo joins the room
[17:17:57] RjS joins the room
[17:18:25] jmce joins the room
[17:18:35] rillian gives up on the audio. let me know if it gets fixed.
[17:20:01] hardie joins the room
[17:20:44] <> Goals of JSEP: allows easy translation to common signaling protocols and architectures (SIP, XMPP, H.323, streaming, etc.); supports early transport negotiation (can add candidates as they arrive); allow local session description to be changed by app; change session parameters at any time (change resolution of video, bw sent); allow session state to be manipulated (can serialize state, send it to server, then reload it), which enables things like page reload, failover between servers, etc.
[17:22:23] Bran, Cary leaves the room
[17:22:36] Bran, Cary joins the room
[17:23:00] <Paul Hoffman> Nikos: I think you need to mute.
[17:23:33] <> JSEP: Doesn't try to solve everything. Non-goals: super-simple API (e.g. WebGL isn't simple either, libraries abstract things for higher level uses), Replace SDP (JSON format could be supported without major changes to the API), Offer generation in JS (at least for now, need to be aware of potential browser fingerprinting issues).
[17:23:46] <dontcallmedom> I remain unconvinced that jQuery shows that we don't need super-simple APIs; the persaviseness of jQuery shows that the complexity of the DOM as an API was a disservice to the Web; likewise, WebGL hasn't quite reached the level of adoption that shows that low-level APIs are a good thing
[17:24:45] <rejzak> Nikos, please go on mute as you are generating a lot of noise on the bridge
[17:24:48] <hardie> dontcallmedom: do you need this reflected to the room?
[17:24:58] <> Justin: Showing diagram of Web App communicating to legacy XMPP client; similar diagram for "SIP in Browser" sending SIP over HTTP to a SIP Proxy (e.g. SIP over Websocket draft)
[17:25:18] <Cullen Jennings> Do people want me to mute Nikos ?
[17:25:25] <dontcallmedom> hardie: I'm not sure if it's worth interrupting the presentation for this (I'm new to IETF meetings, so I don't feel very comfortable intervening yet :)
[17:25:26] <Cullen Jennings> We can't hear the nois e in the room ?
[17:25:27] <> Justin: Web to Web case diagram (using ROAP over HTTP)
[17:25:32] <Paul Hoffman> Ted: Yes, probably: he doesn't seem to be in Jabber, and WebEx doesn't let us communicate with other WebEx users.
[17:25:53] <hta> dontcallmedom: I think there are many people who think the DOM was a Really Bad Design, but the specific nature of its badness is not something we should spend time debating in the webrtc.
[17:26:18] <hta> and yes, this is the place for whispering in the back :-)
[17:26:38] <hta> the tradition is to put MIC: in front of stuff you want relayed to the mike, I think.
[17:26:42] <Paul Hoffman> Nikos just muted himself.
[17:27:02] <dontcallmedom> hta: agreed that bad-mouthing the DOM is probably not a good use of our collective time :)
[17:27:10] <dontcallmedom> (let alone badmouthing Dom)
[17:28:00] <> Justin: Differences in Signaling protocols with respect to candidate handling (SIP vs. XMPP). Can get local candidates quickly, but some interfaces may not return candidates because of poor connectivity, firewalls. To get TURN candidate, have to look up DNS, get TURN Binding, etc. Being able to send candidates as they arise is helpful.
[17:28:23] <> Justin: Glare handling differently in ROAP, SIP, etc.
[17:29:08] <> Justin: Adding or removing sources or sessions can be exposed to the app... if it's built-in it becomes hard to customize it to work for any signaling or app.
[17:29:56] <> Justin: XMPP has concept of content add/remove... different part of the session can be updated without collisions. Individual source can be add/removed within an m-line without disrupting the session.
[17:30:34] <> Justin: If we say that GLARE occurs whenever anything happens at the same time, we create issues that otherwise wouldn't exist, so it's app dependent.
[17:30:41] jesup joins the room
[17:31:21] <> Justin: Core problem: Hard to have a generic signaling mechanism that can map to all signaling state mechanisms. We don't want to limit what we can do going forward.
[17:31:48] <> Justin: What does Media Layer need? Local/Remote format descriptions, Local/Remote transport info.
[17:33:21] <> JSEP: separates signaling and transport We don't care how you got session descriptions, you can still use them.
[17:34:34] <dontcallmedom> one thing I haven't figured out yet: can we make the offer/answer exchange an optional part of the API? i.e. let the browser handle it unless the app developer wants to take it in charge
[17:35:10] <> Justin: Example call setup: offer. Create PeerConnection, add a localStream, create the offer, setLocalDescription, then send the offer
[17:35:19] <> Can you hear Justin? Doing mic check...
[17:36:02] <rillian> about the same as before
[17:36:08] <rillian> I just got dropped though
[17:36:31] <> Justin: App is given the ability to modify the offer before calling setLocalescription; can remove or change anything within SDP, as to what it can add, will discuss later.
[17:36:40] <hta> dontcallmedom: we can't make it optional to provide it (that would just be chaos), but we can potentially offer both. I think that it'd be better to offer a library, though.
[17:37:09] <> Justin: Hints parameter given to createOffer can say "I want one-way video although I haven't added any video tracks to my MediaStream"
[17:37:44] <dontcallmedom> hta: yeah, I didn't mean to make it optional to provide, but make it optional to use for developers (so that the simple case remain simple to write)
[17:38:36] <> Justin: Starting ICE (used to be called Connect()). Once startIce() called, app starts to receive callbacks.
[17:39:05] <dontcallmedom> hta: also, we could develop JSEP on a different timescale, as a complementary API from the main WebRTC API
[17:39:12] <> transportInfo can contains stuff such as bundling, DTLS fingerprint, ICE username/passwd.
[17:39:16] wolfgang.beck01 joins the room
[17:39:58] <dontcallmedom> my fear is that JSEP exposes a lot more than most Web developers want to be exposed to; libraries can help, but they have their own drawbacks (download, maintenance, etc)
[17:40:08] <> Justin: Call Setup: Answer.
[17:40:44] <hardie> Matthew Kaufmann @mic: The runtime here has cool boxes except for "state machine". How does this work with page reload?
[17:40:48] <> Mathew: From Skypro-soft. A question: the run-time here has cool boxes except the one called "state machine". Can you rexplain how the ICE embedded state machine works and how it handles page reload?
[17:41:22] <> Justin: In the page reload case we get a new set of local transport info. May not be able to rehydrate the exact same ports. Plugin in session description again.
[17:41:32] <> Mathew: worried about state machine at other end that's not reloaded.
[17:42:18] <> Justin: In that case, remote side will receive new transportInfo from the reloaded page, can treat this as if the page disconnected, and ICE restarted, media state remains the same.
[17:42:40] <Cullen Jennings> can bridge hear mathew now ?
[17:43:07] <> Mathew: concerned about interaction.. want to move state out of the browser... server at one end knows that page was reloaded... needs to ell ICE implementation at page that wasn't reloaded "you need to do stuff"... easier if the ICE state machine is pulled out like offier/answer state machine. Don't you want to pull it all out?
[17:43:42] <> Mathew: I love the things solved by moving offer/answer out... can you explain how remaining state issue is solved?
[17:43:49] <Martin Thomson> mute please
[17:43:50] <hardie> mute again, telephone folks
[17:44:18] <Paul Hoffman> Cary: did you mean to be muted? :-)
[17:44:34] <> Justin: Upon receiving new transport info from page that reloaded, and realizing transport had dropped (from STUN timeouts), it knows it needs do ICE restart... doesn't require moving ICE out... not opposed to giving app more power, but have opted not to do that... thinks rehydration can occur with out it.
[17:45:08] <> Jonathan Lennox: Can move from WiFi to WWAN... how does this work with APIs? Is it a related problem? ICE candidates can show up....
[17:45:44] <> Justin: Maybe haven't specified it fully... where IP mobility occurs, we can generate candidates on new interface and if we find that the new link is better we can transition... maybe we need new APIs to allow explicit control.
[17:46:36] <> Justin: would like to see scenario in which when it is done internally it's a problem... ICE agent is perpetually doing its thing... notifies when new ICE candidates are available... ICE agent can realize that new pair has better connectivity... is reflected in nominations.
[17:47:22] <> Jonathan Rosenberg (ICEMAN): Doesn't agree that choice of underlying connectivity can be handled by browser. Examples: cost can drive decision and it is app specific. Challenge with ICE is that it has a fairly slow... loses mic
[17:47:28] <> Justin: next question :)
[17:47:36] <> Eric: Get him an IPv6 microphone!
[17:48:10] <Cullen Jennings> can someon see who pis putting noise on bridge ?
[17:48:21] <Bran, Cary> @Paul - my speakerphone says I am muted - my apologies if it is not
[17:48:25] <> Jonathan: because of startup time... on rehydration don't want to restart ICE, want to reconnect using existing creds, same IP addr/port, immediately glue so reconnect can be almost instant... might want TLS-style rapid restart. Wouldn't necessarily go through process of gathering whole new set of candidates.
[17:48:54] <> Jonathan: need more granular access to ICE functionality so more granular stuff can be pulled out, so that we can reuse TURN candidates while gathering new host candidates.
[17:49:22] <> Justin: Reusing candidates is a good idea... assume call persists in some way.... better than what happens today.
[17:49:48] <> Mathew: Would like to consider case where ICE is only be doing because of security. Case of PSTN gateway, only wants one connectivity check, not more.
[17:50:42] <> Eric Rescorla: Case where you need to re-ICE is different from reload. Where you have to re-ICE because of mobility, you have resources (camera mic) don't need to regrab. You have resources on TURN server (TURN candidates). In case of re-load you have to re-acquire everything.
[17:51:20] <> Justin: if you can keep the STUN username/passwd and present from a new 5-tuple, you could migrate it over.
[17:51:28] <> Jonathan: You can! It's a feature of the TURN spec!
[17:51:43] <> Eric: Need to preserve resource allocations through a glitch.
[17:51:52] <> Justin: Even reload can be prompted by Javascript itself.
[17:52:32] <> Justin: To summarize discussion. What can you do to get ICE process to run as quickly as possible, so you don't have to completely re-ICE.
[17:53:16] <> Justin: Now that ICE is established, we receive response from remote side that it acepts session. Plug in remote description, activates stuff proposed in offer, media is sent.
[17:54:04] <> Justin: Once call is active, app can watch media flow by, no additional calls to app unless changes to session descriptions are needed (which can be done by changing localDescription). How do we add a stream in mid-call?
[17:54:18] <> Justin: Say we want to add a new camera or start screen sharing....
[17:55:06] <> Justin: addStream, Send it off as an update message, parse the answer and setRemoteDescription.
[17:55:25] <> Christer: Offer you get contains old offer? Or does it only provide new stuff?
[17:55:41] <> Justin: Offer is full SDP. But you could generate a delta in app and finesse the signaling.
[17:56:07] <> Randall Jessup, Mozilla: What if new localDescription, does it cause an immediate change? Does it get installed only when an answer is added?
[17:56:30] <> Justin: It is installed immediately, need to deal with receie media immediately, but won't start transmitting until we've received the Accept.
[17:56:43] <> Justin: New sources won't occur unntil it is answered.
[17:56:49] <> RRandall: What about removal?
[17:57:01] Spencer Dawkins leaves the room
[17:57:12] <> Justin: If you unplug webcam and remove the stream, what does it mean for remote side to reject it? Remove happens immediately.
[17:57:45] <> Randall: If new localDescription is incompatible with current state of the call and other side wants to reject the change, by installing immediately you have a broken call until you get the rejection.
[17:57:47] Spencer Dawkins joins the room
[17:58:22] <> Justin: -00 version didn't install localDescription till it got response to address that, but it was pointed out that reception needed to be set up immediately or clipping could occur.
[17:58:35] <> Randall: still worried that there are cases where call ends up broken for a while.
[17:59:12] <> Magnus Westerlund, Ericsson (as an Individual): You need to stiuplate something else when you still local state. You need to install loal state that covers both previous and new state, cover both versions to avoid clipping.
[17:59:21] <> Justin: Is that an API constraint or advice for the app ?
[17:59:41] <> Magnus: It's not an API consideration.. when you dig into details...
[18:00:02] <> Justin: When call new createOffer... app can munge and put into an incompatible state... but answer is "dont' do that!"
[18:00:46] <> Cullen Jennings: The idea of changing what you receive right away, but waiting for remote to send... it is declarative, but there is a negotiation and both sides need to have agreement on the merge between them. If we look at this we will also find issues.
[18:01:05] <> Justin: What you receive is your prerogative... other side needs to deal with it.
[18:01:15] <> Cullen: Isn't really the case? Isn't the goal negotiation?
[18:01:25] <> Justin: It's a two-way handshake, not three, right?
[18:01:55] <> Justin: I'd like to get a specific example....
[18:02:11] <> Ted Hardie, Google: If the set intersection changes over time, you may have to redo the whole thing.
[18:03:32] <> Mathew: I think that the disconnect here is that in the pure browser is subordinate to web server, intersection can happen on web server... browser explains to web server its capabilities, web server tells what to do... there may not be an intersection... yu can then take any code running in a server on a client... disconnect between the API provided versus the functionality that must occur (API is a two-way exchange), but SDP offer/answer is different.
[18:04:12] <> Justin: Actual offer/answer intersection can occur on server... creation of answer can be done outside browser... this makes sense, we have implementations that do that... allows for customization of intersection... API could use default intersection from createAnswer API....
[18:04:15] <hardie> That's not quite what I was getting at: the set intersection model for conneg-style negotiation can't be assumed to run once; other things may have changed the available resource set.
[18:04:39] <> Mathew: If using two different browsers... don't have expectation that server or Javascript will have to do work...
[18:05:18] <> Robert Sparks: Go through a simple use case of swapping out an audio codec. Go from low bandwidth to high bandwidth codec. Sounds like use of low bandwidth codec will be disrupted till you get the answer to the offer.
[18:06:12] <> Justin: session with iLBC.. make a new offer with iLBC *and* OPUS... still willing to receive ilLBC... other side indicates OPUS is highest priority... will start transmitting via OPUS, but can still receive iLBC....
[18:06:59] <> Harald Alvestrand, Google (Individual contributor): One way I like to think of SDP is that if you look at the browser API, as long as the SDP offers and answers would have been legal if they had been passing through offer/answer state machine, then the browser will accept them. We make no judgement about whether they actually passed through the state mahcine.
[18:07:16] <> Harald: As long as they would be acceptable in SDP offer/answer it is OK to the browser. I
[18:07:48] <> Jonathan Rosenberg: Makes sense, Harald. But doesn't that mean that offer/answer is in browser?
[18:07:56] <> Harald: GLARE handling isn't in the browser.
[18:08:40] <> Justin: In some ways, since we need to deal with media that arrives before answer is received, we need to separate offer and answer, and install local description so we can receive media before the answer. Cant wait for answer.
[18:08:45] <Cullen Jennings> who is making noise on bridge ?
[18:08:46] <Cullen Jennings> I can't see
[18:08:55] <hardie> Someone on the bridge ?
[18:09:04] <> Looks like bridge... muted.
[18:09:05] <dontcallmedom> where is Zakim when you need it :)
[18:09:51] <> Justin: We have distinction between local and remote, there are different rules for offers versus answers. With SDES/SRTP, you can propose multiple crypto-suites in offer, but answer can only choose one.
[18:10:38] <> Mathew: Is it possible if you already know everything about you... what is minimum JS if you want to hard code this. For PSTN, gateway only does G711 just want to send G711 audio to here, do just one ICE ping, that's it.
[18:10:56] <> Justin: Synthensize SDP with PCU, jam it in.
[18:11:20] <> Justin: It's a design goal not to prevent you from doing this.
[18:11:48] <Cullen Jennings> If people on the bridge want me to unmute them, let me know
[18:11:56] <> Aaron Rosenberg: For last comment... if remote is allowed to be synthesized at local end... doesn't that affect ability to not flood a remote candidate.
[18:12:07] <> Mathew: That's an ICE issue...
[18:12:36] <> Aaron: If offer includes multiple codecs... can browser switch payload number....
[18:12:53] <> Mathew: Don't want browser to do anything you don't want it to do.
[18:13:00] Neil Stratford leaves the room
[18:13:11] <> Jonathan: But if app asks for it, and multiple codecs were included in answer, it's ok right?
[18:13:19] Neil Stratford joins the room
[18:13:22] <> Mathew: Right, you can do it today.
[18:13:37] <> Robert Sparks: App can switch between audio codec and tones, right?
[18:14:22] <> Cullen Jennings: Microsoft clients switch between codecs rapidly.... would be nice to have.
[18:14:54] <jesup> cullen: +1 engine-switching of codecs if multiple agreed to without JS involvement
[18:15:10] <> Jonathan: Mapping between SDP offer/answer when you're doing an update it's complex... used to be an implementation problem, but now it is a standardization problem.
[18:15:35] <> Jonathan: when switching old stuff needs to be live at least temporarily....
[18:16:19] <> (Jonathan Lennox): Tension between wanting to finish ICE early, and ICE consent as media.
[18:16:55] <> Mathew: You can't stop someone sending 8 Mbps to me....
[18:17:12] <> Justin: Nobody wants media to be transmitted until we have consent....
[18:19:29] <> Bernard Aboba: RFC 5245 says that media can arrive after an Offer is sent... so browser might not be able to send media before ICE answer is received... but it can receive. Remember that the other side may not be a browser. Existing state machines apply.
[18:20:14] <> Justin: Add Stream.. in this case we don't have GLARE.... if both sides propose an offer, you might not be able to install each side as an incoming offer, because youre expecting an answer.
[18:20:57] Neil Stratford leaves the room
[18:21:43] <> Justin: JSEP supports Glareless ADd, when offer is created instead of sending full SDP, it generates a delta, like XMPP content add or source add.. just adding new SSRC with this CNAME, don't need to change the other attributes. localDescription is full description but only delta is communicated to the other side... when both sides receive deltas they realize that they have outstanding offers, but by looking at deltas you can acknowledge the offer, and upon receiving ACK can convert offer into an answer and go ahead and install it, avoiding GLARE.
[18:22:13] <> Justin: core part that makes it work is by isolating change in session description into delta... is like editing different parts in a source file, so now you can touch same pieces without a GLARE situation.
[18:22:51] Neil Stratford joins the room
[18:23:11] <> Christer: This sounds tricky... local knows what it is doing, but on remote side... there is bundle proposal that could affect the delta if you are changing it... sounds complicated to me.
[18:23:29] <dontcallmedom> Many of these things that Justin is describing seems to be things that should just happen; it seems wasteful to have every WebRTC app to have to re-implement this (even if reimplementing is "just" re-using a library)
[18:23:35] <> Justin: those cases *are* complicated, but if you're just ading a track, it's only adding an a = SSRC entry, don't need a new transport or c line,
[18:24:34] <> Justin: What needs to be specified is how app treats receiving an offer in a state when it has sent an offer... to translate remote side's offer into an answer. Having a diagram would have helped, so I might make one later.
[18:24:47] <> Eric: Can you run through offer/answer sequence verbally?
[18:25:20] <> Justin: A says I want to add SSRC 1. B at same time says I want to add an SSRC to my offer (SSRC 2). The delta is translated "I'm adding a new source...".
[18:26:12] <hardie> White board has entered the room; I'll upload a picture when it is done
[18:26:40] <> Both sides have plugged in the new sources.... A receives an offer from B in a state where it has an offer outstanding. How to deal? A can't send with new source till B has ACK'd. Wants to ACK B's offer somehow so that A understands that B has accepted A's offer of a new source.
[18:27:11] <> Cullen: Shows A sending ACK +2, B sending ACK +1.
[18:27:18] Spencer Dawkins leaves the room
[18:27:31] <> Ted takes picture of white board.
[18:29:32] <> After B gets "ACK + 2", then B starts sending with SSRC 2
[18:29:45] <> After A gets "ACK +1" then A starts sending with SSRC 1.
[18:30:12] <hardie> Picture uploaded as pdf with title "Delta"
[18:30:18] <hardie> at the proceedings site.
[18:31:19] <> Justin: Goal was to show things you can do with JSEP that you might not be able to do otherwise. What we have here is the ability to treat offers as answers.
[18:31:22] Spencer Dawkins joins the room
[18:31:36] <> Mathew: It's really "cause browser to do X or Y"... but they aren't really offers or answers....
[18:31:57] <hardie> solicitation/proposition?
[18:32:09] <> Justin: No need for complicated GLARE backoff mechanism.
[18:32:58] <> Christer: From an implementers background, we have one RFC 3264 doing offer/answer and we still need to clarify it... if we're basing it on offer/answer we should accept limitations. You're trying to extend offer/answer. This is offer/answer+.
[18:33:43] <> Justin: I'm sure there are edge cases... but common cases like adding a track are going to occur and in those cases, amount of SDP munging is small, we can send a Delta.
[18:34:16] <> Justin: By not coupling this to limitations of existing offer/answer we can have more advanced handling. We have implementation experience with this.... but in practice it can work quite well with this API.
[18:34:38] <> Christer: Not questioning use case. Today you may have to send a large offer or answer....
[18:35:11] <> Justin: You can still do RFC 3264... but this mechanism gives apps that want more advanced handling the ability to do more advanced stuff.
[18:35:41] <> Cullen: This isn't really offer/answer (doesn't bother me). What would be passed across the API in this example? This isn't in the draft.
[18:36:05] Neil Stratford leaves the room
[18:36:14] Neil Stratford joins the room
[18:37:00] <> Justin: In non-GLARE case we install localDescription before sending Offer 1, when receiving ACK we setremote (same remote description, since it hasn't changed).
[18:37:10] <> Justin: Adding a new video source doesn't add a new m line.
[18:37:26] <hardie> does someone on the phone need to speak?
[18:37:28] <> Cullen: If you have a left and right camera... what is it in SDP that tells you have two cameras?
[18:37:32] <hardie> If not, please mute?
[18:37:39] <> Justin: RFC 5576 (source specific session descriptions).
[18:38:10] <> Cullen: I think there is two m lines (that is what RFC 3264 says).
[18:38:19] <> Justin: If we have 20 participants, do we have 20 m-lines?
[18:38:22] <> Cullen: Yes.
[18:38:27] <> Harald: Separate agenda item!!
[18:38:39] <> Justin: I'm assuming one m-line....
[18:38:49] <> Cullen: What if you have multiple codecs?
[18:39:02] <> Justin: hadn't thought that through... don't want to walk through it on the fly.
[18:39:13] <hta> we just went through the changing of codecs question.
[18:39:21] <> Jonathan Rosenberg: Want to disagree with Christer on all points.
[18:39:55] <> Jonathan: we are in this middle between no SDP and all SDP...
[18:40:16] <Jonathan Lennox> Bernard: between no offer/answer and all offer/answer
[18:40:25] <Jonathan Lennox> JDR isn't saying whether it's SDP or not
[18:40:33] <> Jonathan Rosenberg: We don't want to be tied to SDP.... we want to foster innovation... not be locked into old ways just calling it javascript.
[18:41:47] <> Mathew: Confusion with offer/answer... only API should deal with when to send media... not an RFC that would specify this.
[18:42:25] <> Justin: Wanted to avoid API for should I send or stop sending... would give you two ways to do HOLD.
[18:42:50] <> ?: We're conflating APIs and protocols... that's not necessary.
[18:42:58] <rejzak> Instead of promoting end-to-end interop with the LCD offer/answer, JSEP is introducing a generic mechanism that allows implementation of multiple potentially incompatible versions of SDP offer/answer. I have not heard any real technical advantages of doing this.
[18:43:23] <> Cary Bran: sending the delta over the wire is mathematically indistinguishable from sending the whole thing.
[18:43:42] <> Justin: Delta allows you to easily realize that offers don't interfere, and you can process simultaneously.
[18:43:45] <Jonathan Lennox> rejzak: basically, you can't map Jingle's delta capabilities to LCD offer/answer.
[18:44:00] <wolfgang.beck01> get rid of the server-server trapezoid and you don't have to worry about incompatible JS implementations
[18:44:42] Spencer Dawkins leaves the room
[18:44:58] Spencer Dawkins joins the room
[18:45:36] <rejzak> Jonathan Lennox: but Jingle doesn't need to use the delta capabilities to realize any functionality that can't be achieved using full SDP
[18:45:48] <hta> what's LCD?
[18:45:54] <rejzak> least common denominator
[18:46:44] <> Bernard: When A receives B's offer add 2 he can prepare to receive 2, right? Then when A gets B's ACK + 1, he can send new SSRC 1, right?
[18:46:47] <> Justin: Yes
[18:47:05] <Jonathan Lennox> rejzak: full SDP has glare in cases where non-conflicting deltas don't — that's the point.
[18:47:14] <Cullen Jennings> Log ago had a "?" speaker - that was Cary Fitzgerald - not sure if IM im made it to room
[18:47:33] <> Justin: Hold... can send SDP with a=inactive or a=sendonly.... or in Jingle can send an informative message to other side indicating hold.
[18:48:01] <> Justin: create new offer... append send only, then set local description indicating send only and then send it out.
[18:49:06] <> Justin: Things you can do.... send candidates as they are gathered... add/remove sources simultaneously... can change session parameters at any time with or without O/A; can control location session description... can rehydrate from stored state.
[18:49:33] <> New APIs: Creating SDP. Six main new APIs.
[18:50:00] <> Justin: creatOffer(hints). Hints allows some customization. createOffer does not reserve resources or change state.
[18:50:18] <> createAnswer (offer, hints). Like createOffer but uses offer as input to create a session description.
[18:50:42] <> Mathew: Just standing in line for createAnswer.
[18:51:40] <> Justin: these APIs are not required to call... generation can be done by Javascript or by the server.
[18:52:08] <> Mathew: Offer and Answer are not the right words here. What does the browser know for createAnswer that I couldn't write myself in JS?
[18:52:15] <> Justin: It knows the capabilities.
[18:52:27] <> Mathews: Does that mean we're missing a call to get those?
[18:52:37] <> Justin: we want to avoid browser fingerprinting.
[18:52:48] <Martin Thomson> createOffer == getCapabilities ... ?
[18:52:52] <> Mathew: If you have createAnswer you can do fingerprinting right? It's just more work.
[18:53:18] <> Mathew: why are the hints for createOffer not the same as createAnswer?
[18:54:34] <> Justin: Hints can be more object oriented...
[18:54:48] <> Mathew: Disturbed that I can't write createAnswer myself in JS...
[18:55:01] Spencer Dawkins leaves the room
[18:55:08] <> Justin: If you had capabilities API you could... but it could easily be added later, doesn't change other stuff we have discussed.
[18:55:37] <> Harald (wearing W3C Chairs hat): Fingerprinting is on W3C agenda, and implications of capabilities API.
[18:57:11] <> Justin: (rephrasing): Why do you need setRemoteDescription? You need to be able to sync changes to localDescription and push it down (if remote side changes something in the answer).
[18:58:20] <> Justin: If we add APIs to allow control of everything in SDP... you're headed toward a low level API...
[18:59:05] <Jonathan Lennox> Btw, is the audio (such as it is) being recorded?
[18:59:10] <> Justin: addStream is one way to change localDescription...
[18:59:45] <> Justin: Can try to come up with more examples.... things described here can't be done with existing API.
[18:59:53] <> ?: WebGL is not a well designed API.
[19:00:15] <hardie> Jonathan: I believe Cullen set it to record, but there was serious concern about it being audible at the and of the day. We'll have to see.
[19:00:20] <> Justin: We built a high level 3D API and the devs said they wanted WebGL... and then they didn't adopt it!
[19:00:32] <> ?: Depends on who you talk to....
[19:01:10] <hta> ? = Anant
[19:01:12] <> Justin: We are taking the position that we have Javascript Monkeys writing applications... but the amount of code in gmail is staggering.... if we don't provide the important things to allow apps competing with other platforms this is bad for the web platform.
[19:01:27] <> Anard: Mapping existing APIs to Javascript doesn't make sense.
[19:01:40] <Jonathan Lennox> hardie: I don't see the "record" light on the webex screen, but I might be missing something.
[19:01:44] <> Cullen: WebGL as a low level API is hilarious....
[19:01:49] <hta> (I think he spells his name Ananat Narayan, but would have to look it up to make sure)
[19:02:16] <> Cullen: would be interesting to innumerate use cases...
[19:02:44] <> Justin: Had a case where change of PT wasn't acceptable... allowing app to control this gives more flexibility.
[19:03:05] <> Justin: can't change PT of what you receive in an offer within ROAP...
[19:03:32] <burn> hta: Anant Narayanan
[19:03:35] <> Cullen: Wanted to defend JSEP against Mr. Kaufman... yes they are returning caps in form of SDP, but I believe all the semantic info is returned in getOffer.
[19:04:32] <> M. Kaufman: Question for the podium. Is it the case that I can take info from getOffer and write my own js getAnswer as if you had called getAnswer with your SDP....
[19:05:36] <dontcallmedom> (isn't it impossible to separate the discussion on fingerprinting/capabilities and signalling?)
[19:05:43] <> Justin: You can imagine things like AVPF behavior that is supported but not turned on by default. createOffer will generate a large slice of capabilities... but not everything you can do. You can use it as an Oracle and a savvy implementer could by using userAgent string and createOffer...
[19:05:51] <> Mathew: Cullen isn't entirely correct.
[19:05:56] <> Cullen: I stand abused.
[19:06:19] <Jonathan Lennox> Back when fortran was not even three-tran!
[19:07:14] <> Ted Hardie: In praise of the Javascript Monkey. Our primary goal is to make this as easy as possible. Whether it's done in libraries or browser calls. But if I can't give my JS Monkey 20 lines I will be unhappy. The more the monkey needs to understand about state machines... the worse. Chat Roulette was implemented by a 17 year old... who didn't know SIP, offer/answer, etc.
[19:07:54] <> Justin: I also want monkeys to be happy!
[19:08:08] <> Ted: I blame it all on Rosenberg!
[19:08:12] <hta> Rematch!
[19:08:41] <> Justin: Some middleware will be needed by these js monkeys....
[19:09:14] <> Rosenberg: monkeys use libraries... we don't have to specify that high level API... it's wrong to think we'll get this right. It will evolve over time. Much more important is to gert browser right....
[19:09:41] <> Ted: Is the API subject to evolution or is it fixed in stone?
[19:09:45] <jesup> ted++
[19:09:57] <> Rosenberg: Am assuming that browser shipping with new API is less frequent than libraries.
[19:10:20] <> Ted: Let's ask the browser developers...
[19:10:33] <> Jonathan R.: Depends on which browser vendor you work for!
[19:11:16] <jesup> Mozilla ships new versions every 6 weeks; eta from fix to production release is 12-18 weeks depending on timing
[19:11:43] <> ?: If we can develop simple API for 80 percent of use cases, and plug in additional API for complex stuff that's fine with me. But priority is high level API... because WebRTC puts technology in hands of millions of developers... who don't know SDP.
[19:12:22] <Cullen Jennings> Person speaking is Dominique Hazaël-Massieux
[19:12:45] <> Justin: A fan of layered APIs.... can write a library that takes a peerConnection and Websocket and says "go"
[19:13:17] <> Dominique: Priority is on developers....
[19:13:48] <> Eric: There are two kinds of API deficiencies... one is that it is hard... other is that you can't do things. Second kind is a disaster.
[19:14:11] <> Eric: We need a careful study....
[19:14:44] <> Justin: Let's quantify complexity. Someone send examples about simple call with ROAP And JSEP. ROAP was 40-50 lines, JSEP was 120, but was tweaked to 60-80.
[19:14:51] <> Eric R: by deleting comments?
[19:15:31] <> Justin: Factoring... amounts of complexity not so bad for typical stuff... but not talking about 1000 lines of code to do junior js apps.
[19:16:10] <> Rescorla: I care less about code than whether stuff I want to do is there. What do I need to find capabilities? Is it important to be able to forge a complete set of SDP without peerConnection API?
[19:16:50] <> Harald Alvestrand: To make a very short version of what Eric said.... libraries can make hard things easy, but browser APIs are responsible for making good things possible... and bad things impossible.
[19:17:18] <> Harald: We need to concentrate on what we're trying to make possible... and what we are trying to make impossible... and whether we've done that.
[19:17:38] <> Anant: I agree that low level access is useful... I disagree with doing that through SDP.
[19:17:53] <hardie> I have not come to praise SDP, but to bury him?
[19:17:57] <jesup> Bury it in an unmarked grave
[19:18:48] <> Magnus: In IETF WG we are not responsible for the API. Please remember this!
[19:18:56] <> Magnus: Responsibility for API is in W3C.
[19:19:22] <> Justin: I have now used up two hours?
[19:19:35] <> Eric: Keep going! It's the most important thing we'll do all day!
[19:20:49] <> Justin: wanted to touch on Anand's point... trying to be pragmatic... what can we build to expose a modicum of deep control... we've kept SDP because it is the best way we have of representing the session description... if we come up with something else, we either need a mapping or a transformation... that seems like a hard problem.
[19:21:29] <> Justin: Despite this API requires chunks of SDP, it can be treated as opaque in most circumstances.... in a library it would be opaque in all circumstances.
[19:21:42] <> Justin: We can ship sooner if we ignore how sausage is made.
[19:22:23] <> Justin: Hints... shortcuts to allow customization of offers/answers.
[19:22:33] Spencer Dawkins joins the room
[19:22:59] <> Justin: Applying SDP... setLocalDescription changes state, applying the local description (recv codecs, enc. keys).
[19:23:28] <> setRemoteDescription changes remote description (send codecs, decryption keys).
[19:24:11] <hta> 45 mins to scheduled lunch...
[19:24:35] <> Cullen; I'm worried about granularity of error codes....
[19:25:04] <hardie> Today's is a sandwich board, so it will hold if we need it. Tomorrow is hot, and we'll need to be closer.
[19:25:22] <> Say I change video resolution and other side can't handle.... what do the errors look like? Do they help figure out what happened?
[19:25:23] Spencer Dawkins leaves the room
[19:28:47] <> Cullen: an example... what if another app grabbed the camera... how would you find out?
[19:29:26] <> Justin: ICE: IceCallback (media transportInfo) Callback function that receies trnapsort info that needs to be signaled.
[19:29:40] <RjS> (or hardware becomes unavailable in an unusual way - what should happen when I pull the cable on my firewire connected camera?)
[19:29:49] <> processIceMesasge(media, transportInfo) invoked to handle received transport info
[19:30:53] <> Justin: Formats: standard SDP (m = lines), ice-candidate lines, etc.
[19:32:42] <> Justin: Complexity issue. JSEP requires more code (need to manually create offer and send it off), but would need to do them already if you're using your own signaling protocol, but it's only 2x more code not 10x. JSEP can be encapsulated in a JS library.
[19:33:08] <> Justin: Power APIs are the trend (WebGL, IndexedDB).
[19:33:23] <jmce> the audio is pretty much useless now, fwiw
[19:33:34] <> Cullen Jennings (Cisco): Not sure I agree with two or three... i
[19:33:55] <> Cullen: Need GLARE handling.
[19:34:04] <> Justin: Does Chat Roulette handle those cases?
[19:34:09] <> Cullen: Yes.
[19:34:39] <> Justin: You're saying that an app that has robust error handling there will be lots of code?
[19:34:46] <> Cullen: minimal error handling...
[19:34:57] <> Justin: That's more than what existing web apps do....
[19:35:50] <> Cullen: assume voice and/or video to 2 people.... used in games, phone calls, etc. That class of app is > 100 lines of code. Doesn't get me worked up... but there are lots of things that need to be specified.
[19:36:47] <> Adam ?: Wrote examples with JSEP and the old API.... two different questions... if you use a library complexity is less of a pro issue is that junior devs will pick a library, download it, bundle it with app.. but what happens if library is updated?
[19:37:25] <> Adam ?: Could argue that an app is bad, but web is full of them... once something has worked it can't stop working.... needs to be supported in future.
[19:38:21] <> Adam: When I wrote code... JSEP was hard... -00 wasn't consistent... maybe it's fixed in -01. App with old API is symmetric... in JSEP you have to be more aware if you are the A or B side.
[19:38:50] <hta> Adam Bergkvist.
[19:38:51] <> Adam: I prefer old API because I think people will find JSEP hard to use and library has its drawbacks.
[19:40:24] <> Eric: There is a conventional tradeoff here.... doing anything with JSEP requires knowing more. You need to think about protocol state machine.... but it is more obvious how to do somethings in JSEP than in ROAP. There is a tradeoff between writing a simple app and ability to do things.
[19:41:16] <> Harald: As far as I can tell.... I can build ROAP on top of JSEP... there is nothing that JSEP makes impossible that is possible in ROAP. So difference in complexity is a constant not a proportion. With 1000 lines of JS I can make JSEP look like ROAP.
[19:42:15] <> Harald: ROAP makes trickle candidates impossible.... but JSEP makes it possible. I don't see a reason to forbid trickle candidates... at the moment in my present understanding I know which I like better. Things that need to be impossible still are... but JSEP makes more things possible.
[19:42:28] <> Adam: Trickle isn't impossible with ROAP.
[19:42:58] <> Dan B (with AT&T): I'll try to stay out of debate... whole point of JSEP was to move state machine out of browser. That's a good goal.
[19:43:19] <> Dan B: we should look at this as a way to encapsulate resource management...
[19:43:45] <> Dan B: We are now at the point of the spaghetti sauce dilema... the one sauce that meets everyone's need.
[19:44:05] <> Dan B.: allowing decision in a URI to where state is handled is better.
[19:44:21] <RjS> (Dan Druta)
[19:44:26] <burn> Actually, that's Dan D, not Dan B
[19:44:36] <> Dan Druta (AT&T): You will have interop issues no matter what, you will need iff then else code to handle different browsers.
[19:45:17] <> Justin: Wearing both hats of a browser dev and app dev... come down on side of giving app developer more latitude.
[19:46:31] <> Justin: Can build other libraries on JSEP.... people who build apps and don't touch it again and orphans the app.. that doesn't affect that many web users, it's not a main case we should optimize for...
[19:47:13] <> Justin: Key differences between JSEP and ROAP
[19:48:43] Neil Stratford leaves the room
[19:48:49] Neil Stratford joins the room
[19:50:55] <> Justin: Real-World Benefits: hangouts now using a form of this API (proven model). Early candidate gathering improves start time by over a second in >20 percent of calls
[19:51:15] <> Cullen: TURN servers respond quickly or else I'll have delays... what was it that caused a 1 second delay???
[19:51:33] <> Justin: STUN retransmit interval (500 ms)...
[19:51:46] <> Justin: Don't you try 3 or 4 TURN Servers in parallel to get delay down?
[19:52:21] <> Justin: if you obtain a credential over HTTPS... the RTOmin is 3000 ms....
[19:52:36] <> Cullen: our experiments show that we load it faster over a TURN server than a CDN.
[19:52:58] <> Justin: There are cases where 90 percent packet loss is 5 percent and 99 percent is way worse.
[19:53:33] <> Justin: What if you never get STUN candidates? Access to TURN server is blocked over UDP... these things take finite time.
[19:53:50] <> Justin: You don't need to wait for candidates to appear... the local candidates might be good enough....
[19:53:57] <> Cullen: But if you can't do UDP, how does it help?
[19:54:13] <> Justin: But you might be talking within your enterprise.... so it might work.
[19:54:51] <> Justin: In non wester-EU cases, there can be a signficant effect.
[19:55:10] <> Lars Eggert: If you have 5 percent packet loss you have bigger problems? It will be unusable!!
[19:56:33] Martin Thomson leaves the room
[19:56:39] <> Cullen: what is specific to an implementation that could be changed? Some folks wait 10 seconds before concluding a TURN server isn't available... others abandon the TURN server way quicker and move on.... we need to separate it out. Lots of people doing TURN with SIP, not seeing these problems.
[19:56:43] Martin Thomson joins the room
[19:57:03] <> Cullen: Not abusing you about your numbers... but they don't seem right.
[19:57:40] <Cullen Jennings> If you are on the bridge and find yourself muted, say something in this chat room and someone will get me to unmute you
[19:57:54] <> Justin: These were taken from initial call setup.....
[19:58:42] <> Justin: we talked about more advanced ways to handle GLARE.... that don't require backoff.
[19:59:13] <> Justin: We talked about new features lie one-way video, hold, res change without new APIS....
[19:59:33] <> We also talked about calls persisting across app upgrades (moving app from one data center to another).
[20:00:21] <> Adam B: Have a comment about Real-World Benefits... one-way video not hard (same with hold), also res change not such a big deal....
[20:01:00] <> Adam B: There are things like trickle... but I'm not pro-ROAP or any signaling protocol... I just care about the API. I'm only in W3C group... you can do whatever you want unless I have to see it in the API!
[20:01:44] <> Adam B: You can have most complex signaling protocol under the API, that's fine for me... there is setlocal, setremote, ice, etc. in other API it's just one.
[20:02:07] <> Adm B. Before we change API we need to look at problems with current signaling.
[20:02:35] <> Adam B: Changing the API should be the last resort.
[20:03:09] <> Justin: There is stuff I don't want to give up... but am not wedded to it.
[20:04:12] <> Adam B: If you get an answer why does API need to say it is an answer?
[20:04:20] <> Justin: For semantic checking reasons....
[20:05:22] varun joins the room
[20:06:01] <> Justin: Oneway video does require JSEP.... because can only ask m = video line based on whether you have audio tracks or you always have m = video line.
[20:06:09] <> Adam B: That's a protocol think I don't care about.
[20:06:53] <> Eric: I'm trying to get at the innovative pieces of this... two things are separation of transport from media and signaling.... pulling offer/answer state machine out of browser?
[20:07:07] <> Justin: Yes, those are big things about JSEP.
[20:07:37] <> Ted: Lunch is here... if you're here. If you're on the bridge we don't know where your lunch is. We'll get into ROAP discussion after lunch.
[20:07:58] <> Ted: Please don't eat in this room... that will cause tomato sauce on someone's laptop.
[20:08:00] RjS leaves the room
[20:08:02] Neil Stratford leaves the room
[20:08:08] Jonathan Lennox leaves the room
[20:08:08] wolfgang.beck01 leaves the room
[20:29:56] Neil Stratford joins the room
[20:30:34] Neil Stratford leaves the room
[20:38:53] RjS joins the room
[20:45:19] Neil Stratford joins the room
[20:48:11] Jonathan Lennox joins the room
[20:54:29] <> Cullen Jennings up to talk about ROAP.
[20:55:13] <> Cullen: ROAP Design Rationale: simplest thing to do RFC 3264 Offer/answer. Concerns: browser conscious of SDP offer/answer, re-hydration
[20:55:47] <> Cullen: What's the minimum thing to be able to implement RFC 3264... brings pluses and minuses of offer/answer.
[20:56:08] <> Cullen: SDP Offer/Answer pair define what media engine is sending and capable of receiving.
[20:57:33] <> Cullen: SDP streams and formats. Multiple m lines.... if mmultiple media streams of smae tpye are present, means that the offers wishes to send (and/or receive) multiple streams of that type at the same time.
[20:57:44] <> Cullen: slides on the website are the right ones....
[20:58:08] <> Ted tries to load slides and gets an error message... "he assured me they were the right ones"
[20:58:35] <> Cullen: RFC 3264 is clear that before you send an offer you have to be willing to receive that codec on that port... so you have to set up it before you send the offer.
[20:59:32] <> Cullen: It's also clear when you can send... once you receive an offer you are welcome to send media since the other person is set to receive it. At what point can you free up resources?
[20:59:44] <> Cullen: That's also clear.
[20:59:54] <> Resource allocation/deallocation flow.
[21:00:37] dromasca leaves the room
[21:00:59] <> Start off offering G.711, get an answer, in a call. Offer #2 for opus, still have to deal with new SDP and old SDP (simultaneous). Since while new offer/answer is outstanding they could be still sending/receiving G.711. Once the answer comes back with "OPUS", you can free up G.711 resources.....
[21:01:18] dontcallmedom wonders if there will be coffee for the jetlag-challenged among us
[21:01:31] <> Cullen: So there is a time when you've got resources for G.711, then both G.711 and Opus and then Opus only reception. There is no mechanism for rollback.
[21:01:53] <> The reason it doesn't allow you to roll back is because of version numbers, which must always move forward.
[21:02:25] <> Cullen: It's clear we can roll out an alternative, such as advertisement/proposal... but this is what we have weith SDP.
[21:02:56] <> Cullen: when we talk of SDP state not being in browser, but in JS... I am dubious... most of SDP state is rolled up with allocation....
[21:03:42] <> Cullen (fonts too small to read). It's not been clear when we change local and remote to go from G.711 to Opus, what you would do. You'd have to start with G.711, offer both G.711 and Opus and then once you got an answer could change to Opus only.
[21:04:06] <> Cullen: GLARE is separate and is abstracted out with ROAP.
[21:05:02] <> Cullen: What else is in SDP? There is transport stuff, bandwidth, packet rates, mappings to payload types, stuff syncrhoized with lipsync (a=group), don't have bundling but it could be there. Everything relates to stuff the media engine needs to know.
[21:06:12] <> Harald: vocabulary disconnect... what you are calling SDP state is what I would call browser state... we previously thought of this as state of the SDP offer/answer. I feel dis-confabulated.
[21:07:00] <> Cullen: I think that when you can send/receive is reflected in signalling...
[21:07:16] <> Christer: You have offer/answer state... are you talking about media state which is described by SDP?
[21:07:36] <> The "state" is offer/answer state or session state... this is describing the current media state.
[21:08:07] <> Cullen: Confusion about the term "SDP state"... argument I'm making is about the media engine's idea of when you can send/receive... that's the only state there is.
[21:08:48] <> Justin: That wasn't what we were talking about before... this is the media plane... it has configuration. How do these parameters get set? After the fact, can they be moved out of storage to re-initiatlize media engine?
[21:09:52] <> Cullen: confusion about HOLD. Clearly you often want "mute". My definition is you stop sending "useful media" to the far end, and conceal the fact you did that. You can send silence packets.... HOLD is not sending useless packets... it's stopping the packets from flowing. They are both useful
[21:10:29] <> Cullen: In HOLD media engine knows the packets are useless and shouldn't be sending them, and it tells app "whatever the nego protocol is, it needs to be updated to stop"
[21:10:50] <> Eric: When I press the HOLD button I want the other guy's screen to say "you are on HOLD now".
[21:11:14] <> Cullen: This is a slippery slope because of Music on HOld. My definition of HOLD is different from Cisco's which is "you are transferred to Advertising".
[21:11:14] <jesup> Music videos on Hold :-)
[21:11:35] <> Mathew: HOLD is a great case for re-hydration.
[21:11:42] <> Cullen: I have a slide! Let's wait until then!
[21:12:25] <> Cullen: Issue of how long it takes to setup calls comes up....
[21:17:25] <> Cullen shows case with offer audio & video, then non-final answer with ICE u-frags, ICE nego and then DTLS..... and finally media is sent... time between DTLS completion and media can be substantial.
[21:17:46] <> Cullen: You need multiple TURN servers to find one close to you... but you only need one TURN allocation you can use with forking.
[21:18:12] Paul Hoffman leaves the room
[21:18:24] Paul Hoffman joins the room
[21:18:54] <> Christer: Bob sends media... then final answer. Question about when Bob is alerted.
[21:19:35] <> Christer: This is what precondition is all about.
[21:20:16] <> Hadriel: Otherwise it's just an IP discovery mechanism... don't want people to know you're not at home by discovering your address. Deployments won't reveal IP until after user accepts alterting. So only address needed to get quickly is the TURN address.
[21:21:19] <> EKR: You can push latency around...
[21:21:35] <> Cullen: I don't think you can beat this using something like offer/answer.
[21:22:08] varun leaves the room
[21:22:14] <> Cullen: This is a design choice that was the fastest we could make it...
[21:22:14] varun joins the room
[21:22:33] <> Mathew: This is the fastest you could do it with O/A... but there are call cases where O/A is not necessary.
[21:23:00] <> Mathew: If Alice is calling server which is a PSTN Gateway.... which can provide all candidates....
[21:23:13] <> Cullen: That's what I have drawn in that case.
[21:23:17] <> Mathew: I disagree.
[21:23:22] <> EKR: Can I try?
[21:23:44] <> hangouts is not a bad example. As soon as I join hangouts it startes learning....
[21:24:08] <> Cullen: You're totally wrong... browser have to generate the fragments... which can't be under control of server or JS or security fails....
[21:24:37] <> EKR: Let's imagine where there is an affirmative join of the chat room.... you can push this down...
[21:24:50] <> Was that what you're trying to say?
[21:25:01] <> Mathew: No, but it's interesting :)
[21:26:37] <> Ted: This diagram is useful... but there is more. Can we get to that?
[21:27:42] <> Justin: You might not be located near a TURN Server... so if you moved that down and sent your host candidates first... this is trickle ICE.
[21:28:38] <> Cullen: If we're both in the same enterprise and we can use local addrs and even IPv6, we can gather candidates with trickle approach...
[21:29:28] <> Justin: Key one is alice providng the addresses sooner, cause she doesn't care about location privacy.
[21:30:02] wolfgang.beck01 joins the room
[21:30:02] wolfgang.beck01 leaves the room
[21:30:02] wolfgang.beck01 joins the room
[21:30:03] <> Cullen: Proposal to add Candidate messages to ROAP
[21:35:47] <> Cullen: what would you need to extract transport? IP addr and ports... directions of DTLS and crypto-finger prints.... bandwidth stuff... ice-pwd and ice-ufrag... TCP-mix... secure vs. non-secure... most of SDP is highly entwined in transport.
[21:36:03] <> Cullen: One thing that isn't is mapping of payload types to codecs.
[21:37:01] <> Justin: we're moving away from baggage...
[21:37:16] <> How much do we really need?
[21:37:39] <> Cullen: MMUSIC didn't agree to dump old stuff because of backward compat.
[21:39:59] <> Cullen: Web Server Media Engine Control: how do you chat roulette quickly?
[21:40:49] <> Load the web page.... server sends give me an offer to Bob and Alice... alice sends and offer to server as does. This looks like a Web Server SBC, like most PBXes do.
[21:41:18] <> Then server sends answer to Bob and Alice. ICE runs between Bob and Alice as does DTLS, then media gets sent end to end.
[21:46:25] <> Discussion of when media can be sent by a browser... is it a STUN response (Mathew), ICE response with creds (Hadriel) or more than that? ....
[21:46:49] <> Jonathan Lennox: if u-frag and password is know it can be baked in....
[21:47:03] <> EKR: What are we arguing about on this slide?
[21:47:59] <> EKR: It's an illustration of how server forces params onto Alice and Bob, right?
[21:48:02] <> Cullen: You could push the answer directly down if you don't need the offer....
[21:49:35] <> Cullen: What does browser have to generate on its own? Transaction ID. Mathew: Remaining pieces can't be part of the security.
[21:50:00] <> Ted: Let's take this to the security agenda.
[21:50:16] <> Cullen: My point was not security...
[21:52:26] <> Cullen: Rehydration on page load.
[21:52:47] <> Cullen: This is hard... issues in lots of web sites.
[21:53:33] <> Cullen: This will be complicated... maybe I can cut and paste from stack overload as a web monkey, but I dunno....
[21:54:23] <> Cullen: Could have a 500 ms glitch when a reload happens... need to rerun ICE, DTLS cause ports can change.
[21:55:13] <> Cullen: Does Bob get re-asked if he wants to talk to Alice... imagine it is yes, and that is the largest part of delay. If not, you could have a cookie where camera/mic could be enabled wthout consent.
[21:56:04] <> Cullen: Cullen: A bunch of it is up to the app...
[21:57:08] <> Justin: Why does Bob have to be an explicit party to the fact that Alice is reloading?
[21:57:14] <> That's not the case in JSEP.
[21:58:25] <> Cullen: Don't see how an ICE restart would be faster than this....
[22:03:54] <> Ted: Is this about syntax of offer/answer or semantics... JSEP can do O/A, but is not restricted to it.
[22:06:25] <> Cullen: Current ROAP API calls callback with new SDP, JS sends... instead it could call a callback and JS would then be able to ask for new SDP and send it.
[22:11:19] <> Cullen: Design Choices... Paths: use sdp offer/answer, separate transport out of SDP, replace SDP.
[22:12:57] <wolfgang.beck01> sdp finished and deployed? is this true for the RTP multiplexing stuff?
[22:13:24] <> Cullen: people have suggested, why don't you do MGCP or what the ITU-T guys do?
[22:13:40] <> Cullen: we have no drafts....
[22:14:28] <> Ted Hardie: From the floor... back to re-hydration... what if we induce do I hop on one foot...
[22:14:48] <> Cullen: In RFC 3264 you don't have to ever send a final answer... you can keep sending answers, and this is actually done.
[22:15:03] <> Ted: ARe the advantages of moving past offer/answer worth the pain?
[22:15:32] <> We are way past intellectual purity....
[22:16:09] <> Ted: I will take off my individual hat and face the line. We have two proposals. How many of you were in Taipei?
[22:16:34] <> 15 or so raise hands.
[22:16:50] <> How many in Taipei raised hands to agree to do Offer/Answer: 7 raise hands.
[22:16:55] <> Hadriel doesn't remember.
[22:17:02] <> Ted: It was you, Hadriel!!
[22:17:21] <> Ted: How many raised hands for not doing offer/answer. Mary raised hands.
[22:18:00] <rejzak> we on the bridge cannot hear you at all
[22:18:03] <> Ted: It was 60 to 12. Either overlap was small or we have selective memory. We should have panned the camera.
[22:18:11] <> EKR: ARe we leaving ROAP to head into open discussion?
[22:18:14] <> Ted: Yes.
[22:18:23] <> EKR: Where is my caffeine??
[22:18:35] <> EKR: It isn't ready yet...
[22:19:02] <> Ted: Most important decision is what path we are on... gets expressed as input doc and editors....
[22:19:35] <> Ted: We have two things in front of us... one is ROAP (RFC 3264 O/A) other is JSEP which goes beyond O/A.
[22:19:53] <> Mathew: Both sides are the side I'm not on!
[22:20:08] <> Cullen: Neither are the low-level API.
[22:20:35] <> Cullen: Only one low level API, submitted in March... we have same discussion every WG meeting.
[22:20:51] <> Mathew: Can you re-iterate?
[22:21:26] <> Ted: JSEP is a match to syntax but does not match semantics....
[22:21:41] <> Ted: WG has to take on full work of describing permitted semantics.
[22:22:26] <> Stefan: I'm chair of WEBRTC.. the decision will be handled there, so what are we doing here?
[22:23:12] <> Magnus: To answer Stefan's question... API is W3C's responsibility, not IETF. But discussion goes to protocol....
[22:23:28] <> Stefan: There is a huge difference in the work that needs to go into APIs.
[22:24:47] <> Hadriel: Can one proposal do something the other can't do.
[22:25:02] <rejzak> speak up!
[22:25:06] <> JOnathan Rosenberg: Jingle and incremental ICE can be done in JSEP, but not ROAP.
[22:25:17] <> Cullen: I think it can be done in ROAP.
[22:26:06] <> Spencer: I want a sanity check for me or you or both.... In Taipei people weren't jazzed about SDP but weren't jazzed about doing anything else. So we floated toward SDP as the default. That's the impression I walked away with.
[22:26:41] <> Spencer Dawkins (HuaWei): Key question you are thinking about is this line of interworking with legacy VoIP... if you need this you will need machinery to do it.
[22:27:32] <> Ted: Consensus in room in Taipei was Offer/Answer....
[22:27:47] <> Ted: Current question is not one we asked in Taipei.
[22:28:14] <> Ted: Issue is SDP in browser...
[22:29:04] <> Cullen; a concrete difference is the trickle ICE proposal... but in other use cases, there isn't anything we don't do.
[22:30:35] <> Stefan Wenger (Vidyo): Is ROAP a subset of JSEP? In that case, then going with the subset first might be right... and then broaden.
[22:30:59] <> Harald: I'm so happy to be in this group as a contributor because I wouldn't like to be a chair in this one.
[22:31:06] <> Ted: Thank you for your support.
[22:31:47] <> Harald: What got me dis-enchanted with ROAP was the sending of answers...
[22:31:55] <> Jonathan Rosenberg: That's not true.
[22:32:11] <> Harald: That was my understanding of having an outstanding answer....
[22:32:40] <> Harald: Answerer gets to decide if answer is final or not final...
[22:33:01] <> Jonathan: Yes, answerer gets to decide if answer is final or provisional, but that's orthogonal to who picks up the phone.
[22:33:25] <> Harald: Locking made me say "this is something not required by administration of resources in the browser"
[22:33:40] <rejzak> the one aspect of ROAP I disagree with and does not exist in RFC 3264 is the concept of "moreComing" or multiple answers. it makes more sense to simply perform a series of offer/answer transactions.
[22:35:12] <> Robert Sparks: RFC 3264 as used by SIP, once you get an answer in a Reliable Response, it is an Answer.
[22:35:57] <> Jonathan Rosenberg: Reliable answer does not need to wait for human to answer the phone.
[22:36:28] <> Harald: I am happy to have so much feedback that tells me I'm not stupid for not understanding this.
[22:37:44] <> Dan Burnett: Process comment. I'm also active in W3C group. Constant question of "Who decides what?". Official answer is W3C. What I would like to see stopped is that proposals have not been sent into IETF. I did send a proposal to the W3C list... bickering must stop between these two groups. There is a lot of connection, but they need to remain heavily synchronized.
[22:37:51] <> Cullen: My apologies.
[22:38:28] <> Cullen: If we are coming up with a replacement for SDP, that is an IETF topic. API is a totally different topic... I agree that there was a proposal for a different API in W3C and so discussion of submission to IETF is not relevant.
[22:38:58] <> Justin: Genesis for JSEP was to reconcile discussion of low and high level API. How can we enable high level API to do what we want to do?
[22:40:34] <wolfgang.beck01> JSEP goes into the right direction
[22:42:41] <dontcallmedom> but isn't every problem solvable with enough time?
[22:42:57] <rejzak> the server can make many compatible SDP modifications without involving the JS app; JSEP is not needed for this capability
[22:43:03] <> Justin: This will be our platform for the next decade.... if we lock ourselves in we're missing a big opportunity.
[22:43:45] <> EKR: We're trying to make a decision today or tomorrow....
[22:44:06] <> Argument is that JSEP allows things that are difficult or impossible to do with ROAP.
[22:45:07] <wolfgang.beck01> type faster, Bernard :-)
[22:46:07] <> Hadriel: We had a conf. call on low level API vs. ROAP... and a lot of arguments on this slide were talked about on that call..... result of that call and even in Taipei was that people were ok with putting more logic in browser... even for things that were more advanced, almost all can be done with ROAP, albeit with a B2BUA.
[22:46:51] <> Hadriel: You could emulate MGCP or MEGACO, you could make your JS library terminate ROAP without offer/answer. Even with Trickle you can do this, keep feeding answers to your browser and generate trickle events Northbound... this brought us full circle back to mailing list.
[22:48:19] <> Ted: Are ADs OK if we cut the line? Yes.
[22:48:29] <> Cullen: Noone named an end-user feature you can do in one and not the other.
[22:48:50] <> Cullen: we are picking something that has longer term impact.
[22:49:41] <> Justin: I don't understand how you can edit local SDP in ROAP.
[22:49:51] <> Cullen: You can make whatever changes a B2BUA could make.
[22:50:21] <> Justin: You can't change what goes out... if you do, what the browser thinks about is different from the site.
[22:50:51] <> Justin: I mentioned a couple of cases: HOLD, Resolution, Bandwidth...
[22:51:26] <> Justin: things with more control have better longevity.....
[22:52:55] <> Cullen: Idea that apps can quickly update libraries is less true in app world... Fluffyworld runs on Google app... but my cloud provider doesn't support Python 3.0... but it's not my server! You can download JS from anywhere... Oath library is tied to a Jingle lib on the server side, which is tied to Python....
[22:53:11] <jesup> cullen++ on libraries
[22:53:27] drageke joins the room
[22:53:54] <jesup> unlike jquery, where an old version only affects your site, in this if you're relying on libraries above jsep/etc then everyone else must be interoperable with the oldest version of that library still in general use. (Not a new concern, of course)
[22:54:32] <> Jonathan Rosenberg: It comes down to understanding tradeoff... time to specification versus greater degree of flexibility. What is fundamentally different about this project vs. reams of SIP? Difference is Web model, which is vastly improved. We're doing a disservice to the future community unless we move as much out of browser into the app. If someone who has a deployed app says I need more that should mean a lot. The more we say the browser does less it is better even if we have to do more work.
[22:54:53] <> JR: I'm confident we can get it right...
[22:55:00] <> Ted: AFter 15 years of SIP standardization!
[22:56:05] <> Dave D: WE should be in agreement that browser is in charge of allocation of resources... what we are challenged with is the ability to manage nego aspect. This is the bubble we're moving left and right. It's who is managing the negotiation. Transport and media allocation if we can expose those APIs through browser we should be ok.
[22:56:17] Martin Thomson leaves the room
[22:56:39] Jonathan Lennox leaves the room
[22:56:45] Martin Thomson joins the room
[22:56:50] Jonathan Lennox joins the room
[22:57:09] <> Harald: A public service announcement. As of this Friday if you think you can do something on top of ROAP, it is now out in Chrome... has been out for several hours without being rolled back. If you can't do it, either you should give up or file a bug. That said.... there are unconvincing arguments... we get more flexibility out of JSEP way, even though some things are slightly under-specified.
[22:57:38] <> Harald: I say.... we need the flexibility and we have to go do it...
[22:59:08] <> Ted: Harald reminds me of a joke... student with anti-gravity machine and shows it's not magnetic.... "it works in practice, but does it work in theory?". We have working implementations of JSEP and ROAP. We had volunteers to do demos but we ate all the time.... we know people can build code that implements both. I would like to kick this down the road a bit. JSEP is a JS implementation of ROAP in which signaling mechanism lives in the app, if JS is restricted to offer/answer.
[22:59:28] <dontcallmedom> "if you limit JSEP to offer/answers, it is a JavaScript implementation of the ROAP offer/answer model"
[23:04:19] <> Bernard: Once you get into complex offers, chance of browser supporting all that goes down... JSEP could be much more interoperable.
[23:04:27] <wolfgang.beck01> either the bridge is failing or people don't use the mic..
[23:04:43] <> Justin: I think things like trickle candidates are things we shouldn't rule out...
[23:06:25] <> Mathew: Why do a merge? Why should I test drive two cars but the high performance car has limits to make it like the low perf. car. I can do that analysis? Once you have crippled JSEP to make it like ROAP they are the same.
[23:06:39] <> I believe that the higher perf one is also the lower complexity one.
[23:07:13] <> EKR: proposal is to stick with style of JSEP but would prohibit the operational sequences, restricting it... is that what you're saying? Yes.
[23:07:39] <> Jonathan Rosenberg: From a process perspective it seems odd, because we don't have a doc making it clear whether the merger would get the best or worst of both.
[23:07:51] <> Also, we're not making a decision... be curious to see where a hum would come out.
[23:08:27] <> Rosenberg: I prefer JSEP model because of more flexibility.
[23:08:48] <> JR: I'm not in favor of merger, would prefer a vote and would vote for JSEP.
[23:11:13] <> Mathew: I will restate what other speakers have said and add color... nobody has proven that JSEP can do something that ROAP can't... however, I think there is a second point which is what is easy and what is not. If we have two ways one of which is hard and the other is not....
[23:11:38] <> Cullen: JSEP has no way to switch between G.711 and OPUS without dropping media...
[23:11:46] <> Hadriel: Sure you can do it. Turn on two codecs....
[23:12:32] <> Jonathan Rosenberg: I understand better how to do trickle candidates and GLARE in JSEP. Can't say ROAP can't work via B2BUA....
[23:12:43] <> Cullen: Neither trickle nor GLARE are handled by B2BUA.
[23:13:10] <> Dan Burnett: Two abstractions. Some abstractions are better for some things than others. I'd like to hear more from users than implementers.
[23:14:55] <> Dave D: I like idea of combining them... API is more of a W3C WEBRTC responsibility...
[23:15:31] <> Stefan Hakansson: I'm bringing up what Dan said before... this is about the API...
[23:15:52] <> Hadriel: Stefan: Our experience shows that current API is easy to use.
[23:16:10] <> Stefan; But you only forward info that comes from browser... no editing.
[23:17:07] <jmce> GENBAND input here - we prefer JSEP, because it appears more consistent with web architecture. Also like the fact that signaling state is removed from browser core.
[23:17:25] <> Hadriel: Harald and I are on opposite sides of where we were 8 months ago... was told that people were for ROAP was it handled easy case but made everything complicated... too bad. I would like to hear if JSEP is simple for simple case, or more complicated for simple case... or simpler for complicated case....
[23:18:15] <> ?: ROAP is simpler for point to point... but easier to use JSEP for multi-party...
[23:18:37] <> ?: JSEP allows client to talk to server use cases better....
[23:18:57] <> Aaron Rosenberg (Lifesize/Logitech): JSEP gives more flexibility with bi-directional offer/answer.
[23:19:45] <> Mainline RFC 3264 this is pushed down to per-codec RTP mapping level. Trying to describe async H.264 has to be done there versus VP8... can handle certain sample rates on send versus receive.. In JSEP model we can update one side of conversation, things are easier for us.
[23:20:41] <> Justin: Wearing app developer hat... JSEP power hangouts, gmail call phone for PSTN interop... have demonstrated in variety of scenarios, can update participants, add streams, hand off call from centralized to P2P... if we were talking about B2BUA in JS... is that what we want???
[23:20:49] <> Ted: Can the AD come to the mike?
[23:20:56] <> Gonzalo steps forward.
[23:21:14] <> Ted: Question: please stand up if you don't care about ROAP vs. JSEP.
[23:21:22] <> Question 2: Stand up if you prefer ROAP.
[23:21:29] <dontcallmedom> technically, these aren't questions ;)
[23:21:30] <> Question 3: Stand up if you prefer JSEP.
[23:21:38] <> Question 4: Stand up if you prefer to merge docs.
[23:21:58] <> Ted: And mathew gets to lay back... because he doesn't like any of them.
[23:22:10] <> Justin: Can we ask prefer 1... but can live with merged?
[23:22:20] <> Ted: Can do Condorcet voting if we need it but....
[23:22:29] <> Mathew: Merger is the worst of the options.
[23:22:36] <> Ted: You can sit down for that one too, then!
[23:23:07] <> Ted: Stand up if you don't care. 9.
[23:23:55] Spencer Dawkins joins the room
[23:24:07] <jmce> do people on the bridge get to stand up too???
[23:24:11] <Bran, Cary> remotely standing for ROAP
[23:24:12] <rejzak> Q2: prefer ROAP
[23:24:13] <Spencer Dawkins> So, we're taking hums ...yes, please
[23:24:14] <> Ted: Stand up if believe ROAP should be the basis of further work.
[23:24:44] <> 11+2.
[23:24:47] <jmce> Q3 - prefer JSEP
[23:24:47] <> Stand up for JSEP
[23:24:51] wolfgang.beck01 stands up for jsep
[23:24:59] <drageke> Standing for JSEP
[23:25:11] <> 25+3
[23:25:19] <> Please stand up for merged doc....
[23:25:32] <> 8
[23:26:19] <> Chairs are calling consensus for JSEP...
[23:26:32] <> Authors: You have LOTS of work for Paris... there will be lots of comments.
[23:26:33] <dontcallmedom> (we're more than 53, so clearly some people didn't express an opinion)
[23:26:40] <> Time for a break....
[23:27:09] Jonathan Lennox leaves the room
[23:27:30] <wolfgang.beck01> thank you Bernard for scribing in this detail
[23:27:40] wolfgang.beck01 leaves the room
[23:27:54] RjS leaves the room
[23:43:22] RjS joins the room
[23:43:28] Jonathan Lennox joins the room
[23:43:41] Spencer Dawkins leaves the room
[23:44:15] Spencer Dawkins joins the room
[23:46:32] RjS leaves the room
[23:47:22] <> Harald up talking about the MSID draft.
[23:47:41] <> Harald: Tracks are inside Streams inside PeerConnection.....
[23:47:53] <> Channels are inside Tracks.
[23:48:20] <> If you want an identifier... add one.
[23:48:39] Jonathan Lennox leaves the room
[23:48:47] <> Harald: You could ignore problem (works badly with multiple streams).
[23:48:47] Jonathan Lennox joins the room
[23:49:01] <> You could use existing identiiers (SSRC, CNAME, RTP session/SDP m-line
[23:49:16] <> Or you could add a new identifier... (nonstandard, API only).
[23:49:46] <> m-line can only contain audio OR video....
[23:50:16] <> Choices: could use in API only... or could carry it in SDP blobs.
[23:50:59] <> MSID draft defines a stable ID for a MediaStream... passed over SDP in an SSRC-specific attribute.
[23:51:41] <> Cullen: we try not to add labels to SDP unless we need them.
[23:51:48] <> Harald: Doesn't correspond to an m line....
[23:52:04] <> Harald: Track is an SSRC....
[23:52:15] <> Cullen: Yes....
[23:52:34] <> Cullen: How do two streams show up in SDP.....
[23:53:08] <> Harald: MSID 1 means it goes into mediastream 1?
[23:53:36] <> Harald: semantics of media stream as added by editor (Cullen!) is that all the tracks in a media stream are played out synchronously... that is the only semantics it has.
[23:54:32] <> Cullen: Can we take SDP label attribute and for each track form a label from name of the stream concatenated with a name of the track? Would allow us to clearly extract stream names and track names.... while we could interop with different stuff.
[23:54:40] <> Cullen: Would that work?
[23:54:58] <> Magnus: It won't work. Single reason is because one media stream track could be part of multiple media streams.
[23:55:01] <> Cullen: What???
[23:55:42] <> Magnus: one video track could combine with an audio stream within a media stream... then same audio stream could be in another media stream.....
[23:55:55] <> Cullen: Packets are only sent once... API is grossly broken for that.....
[23:56:15] <> Harald: Proposal is broken, because it assumes that one SSRC has only one a= line.
[23:57:19] <> Harald: Answering your question... using label doesn't work because it labels the m-line. m-line doesn't map to anything particularly useful. To have a sane number of m-lines we are going to the thing that hangouts do... send a lot of different SSRCs in a different RTP session which is described by one m-line. So unless you can encode everything in one label....
[23:57:28] <> Cullen: What makes 100 m-lines insane?
[23:57:47] <> Harald: Unless bundle is supported... we'd have to set up 100 holes through the firewall.
[23:58:07] <> Harald: Multiple SSRCs in one RTP session works, so why not use it?
[23:58:23] <> Cullen: you could have 100 m-lines with same port and address....
[23:58:47] <> Harald: Using multiple m-lines is a major change... so that it won't work.
[23:59:14] <> Christer: I sent an email based on a request from MMUSIC to ask if people want to move bundle forward... please go to MMUSIC list.
[23:59:43] <> Christer: Every SSRC below an m-line would share a payload type and codec...
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!