[08:58:32] --- Aki has joined
[08:58:54] --- isudo has joined
[09:00:55] --- magnus has joined
[09:01:39] <magnus> Hi, are any of you in the room?
[09:01:53] <magnus> That beeing the meeting room?
[09:02:40] --- danyork has joined
[09:02:54] <danyork> the room is filling up now
[09:03:56] <magnus> I am not present and I would really like somone to do a bit of scribing. I am primarily interested in questions and answers.
[09:04:10] <magnus> Knowing which presentation is ongoing would also be good.
[09:04:12] --- sakuma.macx has joined
[09:06:20] <danyork> magnus: will try
[09:06:41] <danyork> just welcome right now
[09:07:36] <danyork> agenda was messed up and has been rearranged
[09:08:05] <danyork> ICE is at 9:10, followed by another presentation
[09:08:10] <danyork> on ICE
[09:08:28] <magnus> Thanks
[09:08:54] <danyork> other genda items are SDP Capability Negotiation, Signalling of media decodingg dependency in SDP and the Security Description Extension for IPSec
[09:09:04] <danyork> main focus, though, will be ICE
[09:10:02] <danyork> Status - RFC4473 and 4435 published
[09:10:11] <danyork> 7 documents in Auth 48
[09:10:21] <danyork> 1 in RFC editor queue
[09:10:33] <danyork> numer of docs with ADs... all in all in good shape
[09:11:24] <danyork> actually -> http://www3.ietf.org/proceedings/06jul/slides/mmusic-0.pdf
[09:12:30] <danyork> Cullen Jennings is now addressing the group announcing that Jean-Francois (sp?) is joining as a WG Co-Chair
[09:12:40] <danyork> Now starting ICE discussion
[09:14:11] <danyork> now in http://www3.ietf.org/proceedings/06jul/slides/mmusic-1.pdf with Jonathan Rosenberg speaking
[09:16:48] --- cullenfluffyjennings@gmail.com has joined
[09:17:10] <cullenfluffyjennings@gmail.com> Do we have a note take for this meeting ?
[09:17:56] <magnus> The chair usually use audio plus their own notes to create the minutes.
[09:19:21] <danyork> someone did say they were taking notes
[09:19:22] <cullenfluffyjennings@gmail.com> Cool - good to have hard working chairs :-)
[09:19:34] <danyork> Jonathan is at slide 7, open issue #1 about SBCs
[09:19:43] --- miaofy has joined
[09:20:08] --- jean-francois has joined
[09:20:08] <magnus> ok
[09:21:06] <danyork> cullenfluffyjennings@gmail.com: the chairs did ask that question and someone responded
[09:21:46] <danyork> jonathan speaking about not wanting ICE to be a SBC-bypass mechanism
[09:23:12] <danyork> Francois Audet asking a question about this case
[09:23:25] <jean-francois> Q: what if the session or call comes back to the SBC? Would passing the candidate along help in this case
[09:23:30] <jean-francois> (from Francois)
[09:23:36] * danyork notices that cullenfluffyjennings@gmail.com is actually here in the room as Cullen is now standing behind Francoiis
[09:23:46] <danyork> jean-francois: thanks for the assist!
[09:24:28] --- ysuzuki has joined
[09:25:03] <jean-francois> Jonathan responded: we should treat this as an interop pb, whatever is in the m/c line is where media should be sent.
[09:26:33] <jean-francois> Jonathan: the big issue is some SBCs muck with the m/c line leaving the candidates ==> this should be treated as the primary case for this open issue
[09:27:38] --- sakuma.macx has left
[09:27:41] <jean-francois> Cullen: repositioning the pb, SBC = B2BUA, if a UA sends SDP it does not understand, it is a bug
[09:27:45] <danyork> cullen is asking a question
[09:28:04] <danyork> what jean-francois said.. :-)
[09:28:26] <jean-francois> (:) helping but thinking brings latency ;)
[09:29:19] <danyork> jean-francois: actually, I'll let you post the questions here because you are doing a great job summarizing them
[09:29:39] <danyork> francois back at the mic
[09:30:23] --- miki_h has joined
[09:30:41] <jean-francois> Francois is back on the original question (case where call comes back with SBC and the SBC changes the m/c line back) or so I think
[09:31:24] <danyork> Bob Penfield from Acme Packet up at the mic
[09:31:28] <jean-francois> Bob Penfield: strongly recommend keeping the current approach
[09:32:23] <danyork> Jonathan indicates that there is a *giant* problem looming at the end of the slide deck that will far overshadow this comparitively tiny problem
[09:32:36] <jean-francois> Phil Matthews: we should look at the case where SBC is ice-aware. Jonathan responded we don't care about this case, there is no interop pb there
[09:32:39] <cullenfluffyjennings@gmail.com> agrement to keep text on it
[09:32:48] <danyork> slide 8
[09:33:13] <danyork> skipped it and moved to slide 9
[09:33:15] --- sakuma.macx has joined
[09:33:16] <danyork> will come back to 8
[09:33:24] <jean-francois> slide 12 actually
[09:33:41] <cullenfluffyjennings@gmail.com> Open Issue #3
[09:34:16] <danyork> thanks
[09:34:51] * danyork had to sign the blue sheets at the time Jonathan moved forward
[09:35:14] <jean-francois> slide 13: correction on approach 2: " –BUT, it doesn’t work since q-values are *ordinal*"
[09:36:08] <jean-francois> resolution on open issue #1: keep approach 1
[09:36:08] --- isudo has left: Lost connection
[09:36:08] --- ysuzuki has left: Lost connection
[09:36:08] --- miaofy has left: Lost connection
[09:36:08] --- Aki has left: Lost connection
[09:36:08] --- sakuma.macx has left: Lost connection
[09:36:08] --- miki_h has left: Lost connection
[09:36:08] --- danyork has left: Lost connection
[09:36:57] <jean-francois> --- slide 15, open issue#5
[09:39:06] <jean-francois> Phil: no longer an issue after he has had time to rethink it - agreement to keep current mechanism which is not broken
[09:39:18] <jean-francois> --- slide 16
[09:40:00] <jean-francois> Cullen: thinks that only the outer bound NAT matters
[09:40:47] <jean-francois> unclear, Jonathan thinks it matters (need more thinking)
[09:40:54] --- bewo has joined
[09:43:02] <jean-francois> Issue illustrated on this slide is showing that if you have a STUN server on public Internet that does not do TURN, and the STUN and TURN servers are separated by addr=res NAT, then we have a call failure
[09:43:10] <jean-francois> (explanation from Jonathan)
[09:43:51] <jean-francois> Jonathan: think this is a broken deployment, the STUN server should do TURN here too
[09:44:22] <jean-francois> Eric: if you start to look at all network topologies, you won't be done with Ice
[09:44:38] --- isudo has joined
[09:44:46] --- miki_h has joined
[09:45:22] --- Aki has joined
[09:46:08] <jean-francois> --- slide 17, open issue #7
[09:46:09] --- danyork has joined
[09:46:47] <jean-francois> RECAP: resolution on slide 16 (ok to not address this but suggestion made to capture this case somewhere as something that does not work)
[09:46:54] <jean-francois> --- slide 17
[09:47:53] <danyork> back... sorry about that... jabber.org seemed to die and wouldn't let me back on... had to bring up a jabber server on a server I control to get back in
[09:48:32] <jean-francois> no discussion or comments on slide 17, resolution as proposed in the slide: no work on this
[09:48:34] <danyork> jumping back to slide 8
[09:48:51] <jean-francois> wb dan, i'm going back in sleep mode for a while
[09:48:57] <danyork> open issue #2: pairing peer derived with no other candidates
[09:51:14] --- csp has joined
[09:52:00] <danyork> now in discussion on slide 11
[09:52:16] <danyork> cullen is at the mike asking for a clarification on earlier lsides
[09:52:48] --- bewo has left: Replaced by new connection
[09:52:54] --- juampe has joined
[09:52:55] --- bewo has joined
[09:53:05] <danyork> jonathan sees this as an unsupported use case
[09:53:13] <danyork> it would add significant complexity
[09:53:20] --- ldondeti has joined
[09:54:09] <danyork> jonathan presenting his alternative (3rd bullet on slide 11)
[09:54:51] --- ysuzuki has joined
[09:55:32] <danyork> someone at the mic pointed out that a re-invite only works if the first exchange succeeds
[09:55:59] <jean-francois> (was Flemming I think)
[09:56:04] <danyork> Philip Matthews back at the mic (he was the one who created this use case and has been at the mic several times)
[09:56:38] --- juampe has left
[09:58:08] --- miki_h has left
[09:58:25] <danyork> cullen at the mic
[09:59:20] <danyork> cullen - this whole thing is about optimizing for a broken deployment scenario
[09:59:28] --- dumdidum has joined
[09:59:45] <danyork> jonathan agrees (and wants to get to the final "big" issue)
[10:00:14] --- miki_h has joined
[10:00:26] <danyork> Philip back at the mic - he sees that this *could* be an actual use case that he does think we need to deal with (and is explaining how he sees it could be deployed)
[10:01:37] <danyork> Jonathan moving to open issue #8: Too Complicated
[10:01:43] <jean-francois> Philip added: NAT NL is owned by a residential user (home router box preconfigured to use STUN server S) and NAT NR is an enterprise while NAT N is an overall SP NAT (entire network is natt'ed - bad)
[10:01:50] <danyork> slide 18
[10:02:12] <danyork> JR has an idea for a simplification
[10:02:27] --- miaofy has joined
[10:02:36] <danyork> looking for rough interest for him to try it out
[10:03:12] <cullenfluffyjennings@gmail.com> Rohan - says : the ICE spec makes the media work better, or even just work at all, than without it. It does not need to optimize to the best possible path in every pathological situation
[10:03:17] <danyork> i.e. is it too complex that he should go back for a rewrite? Or should we just move on
[10:03:56] --- miaofy has left
[10:04:56] <danyork> slide 19
[10:05:23] <danyork> JR shows his "Big Idea" on slide 20
[10:05:31] --- bew has joined
[10:07:03] <cullenfluffyjennings@gmail.com> Rohan says: the implementor still needs to store the actual transport address, right?
[10:07:53] <danyork> basically the idea is that when a connectivity check is received and the source IP differs, the IP address is *updated* in the existing candidate pair
[10:08:09] <danyork> instead of killing off the pair and creating a new one
[10:08:28] <danyork> Tim Hall went to the mic and said this is how they implement ICE today
[10:09:30] <danyork> slide 21
[10:10:25] <danyork> slide 22
[10:10:59] <danyork> drawbacks - will take time, will not be backwards-compatible and will not work for use case #2 raised by Phil
[10:11:07] --- juampe has joined
[10:11:19] <danyork> chair asks for questions
[10:12:00] <danyork> JR asking whether people think this is appealing enough
[10:12:19] <danyork> phil zimmermann at mic
[10:12:35] --- dumdidum has left
[10:13:06] <danyork> phil - if draft comes out quickly and saves time for all, it will represent net savings
[10:13:23] <danyork> phil - Skype put engineers in closed room and told them to make NAT work
[10:13:41] <danyork> phil - we need to be fast and get out there
[10:14:35] <danyork> things are paused here as Philip Matthews gets a slide deck up there in response to JR's proposal
[10:14:55] <danyork> Philip now presenting... is in agreement about simplifying
[10:15:14] <jean-francois> where are those slides?
[10:15:32] <danyork> his proposal not so much alternative but rather an orthagonal alternative for simplifying the core state machine
[10:15:36] <danyork> jean-francois: don't know
[10:15:45] <csp> http://www3.ietf.org/proceedings/06jul/slides/mmusic-2.pdf
[10:15:50] <jean-francois> thx
[10:16:30] <danyork> csp: thanks
[10:16:51] <csp> see my email to the mmusic list for a pointer to all slides
[10:16:53] --- sakuma.macx has joined
[10:17:32] <jean-francois> got it, had downloaded them but was looking at the pointers on the agenda and couldn't find them, my bad
[10:21:02] --- miki_h has left
[10:21:12] <magnus> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 contains all the WG meeting material.
[10:21:29] <magnus> All the WGs of this meeting to be clear.
[10:22:31] <danyork> on slide 3
[10:23:37] --- bewo has left: Disconnected
[10:25:09] --- juampe has left
[10:27:15] <danyork> into example on slides 6, 7 and now 8
[10:27:56] <danyork> slide 9
[10:30:21] <danyork> stepping through slides... up to 13 now
[10:30:52] <danyork> slide 14... slide 15 (final slide)
[10:31:36] <danyork> chair asks for questions
[10:31:50] <danyork> Fleming at the mic asking for the example one
[10:32:02] <danyork> (for the example slide)
[10:32:19] <danyork> asking about how this would work for symmetric NAT
[10:35:04] <danyork> JR at the mic
[10:35:08] --- miki_h has joined
[10:35:09] --- jpc has joined
[10:38:05] <danyork> lots of discussion... happening too fast to easily summarize
[10:39:31] <danyork> cullen and JR have both been at mic asking clarification questions
[10:39:39] <danyork> chair is now asking for general comments
[10:39:47] <danyork> Francois Audet at mic
[10:40:32] <danyork> Francois: can JR and Philip work this out? Or are you asking group to arbitrate?
[10:41:03] <danyork> cullen at mic as AD
[10:41:36] --- dumdidum has joined
[10:42:15] --- bew has left
[10:42:49] --- csirkin has joined
[10:42:59] <danyork> cullen - we need to pick minimum set of requirements that we can relay to implementors in ways that they can understand
[10:43:38] <danyork> cullen - reducing complexity may mean some network configs aren't supported
[10:43:44] <danyork> bob sparks at mic
[10:44:23] <danyork> bob - spec is written for WG not implementors... implementors are just looking for what they *need to do*
[10:45:01] <danyork> bob - simplifying state machine is very good but focus should be need to make text more accessible
[10:45:26] <danyork> bob - backwards compatibility not a huge issue because ICE is not yet widely deployed
[10:45:49] <danyork> bob - doesn't want to be here for "ICE-09000" (play on "ISO-9000")
[10:45:54] <cullenfluffyjennings@gmail.com> Robert Sparks - "I don't want to be here for ICE O 9000"
[10:46:31] <danyork> Tim Hall (?) at mic talking about backward compatibiility - JR responding
[10:47:56] <danyork> Tim - backward compatibility to ICE-09 would be compatible
[10:48:13] <danyork> Jason (?) at mic stating that he agrees with JR's simplification proposals
[10:48:26] <cullenfluffyjennings@gmail.com> Jason Fischl - Counterpath
[10:48:33] <danyork> thx
[10:48:49] --- bewo has joined
[10:48:50] <csirkin> That was Tim Moore before Jason
[10:49:00] <danyork> Jason - backward compatibility is a huge issue for *vendors* but shouldn't be an issue for the WG.
[10:49:11] <danyork> csirkin: thx
[10:50:30] <danyork> Jason - would be willing to take the delay for simplification - assuming delay isn't incredibly long - ICE needs to get to RFC *soon*
[10:50:36] <danyork> Rohan at mic
[10:50:48] --- bewo has left: Disconnected
[10:51:25] <danyork> Rohan - requirements issue... we can't optimize for every situation... supports JR's simplification
[10:51:30] --- ldondeti has left
[10:51:35] <danyork> Rohan - use case document would be useful
[10:52:12] <danyork> Eric at mic
[10:53:22] <danyork> Eric - text is too explanatory... targeted for WG... needs to be targeted to implementors
[10:54:35] <danyork> bob sparks at mic - all of the implementors he is aware of have *stopped* their ICE development to wait until a stable draft is out
[10:55:13] <danyork> Francois at mic - agree with simplification but troubled by sense that we are not converging... every meeting has a gigantic breakthrough that changes everything
[10:55:42] <danyork> Francois - how sure are we that these proposals are converging?
[10:57:35] <danyork> JR at mic - do we want a new editor?
[10:59:06] <danyork> chair has closed line at mic
[10:59:29] <danyork> Tim Moore at mic - needs simplificatioin
[11:00:15] --- Shida has joined
[11:00:37] <danyork> Tim - doesn't understand why Philip's duplicate check removal is needed
[11:00:53] <danyork> Derek at mic - wants simplification
[11:01:00] <danyork> Rohan at mic for last comment
[11:01:20] <danyork> (Derek from CounterPath)
[11:02:03] <danyork> rohan - it's important to make ICE simpler for more people to implement
[11:02:10] <danyork> chair trying to summarize
[11:05:58] <danyork> JR at mic suggesting the scheduling of a public conf call to drive debate
[11:07:21] <danyork> chair asking for hum about whether people are okay with the 12-page-weight-loss program
[11:07:26] <danyork> positive hum
[11:07:48] <danyork> chair asks for hum about if waiting 6 weeks is too long
[11:07:51] <danyork> silence
[11:08:45] <danyork> rohan to mic answering someone who asked about whether we should have new editor - rohan says - it is a LOT of work
[11:09:04] <danyork> Philip at mic saying that he is willing to help JR as much as possible
[11:09:20] <danyork> Eric at mic saying he would be willing to help with rewrite at well
[11:09:47] <danyork> ICE discussion now closing
[11:10:13] <danyork> With 20 minutes remaining, the next presentation is now up
[11:10:20] <danyork> SDP Capability Negotiation
[11:10:34] <danyork> chair says there will be a second mtg time tomorrow afternoon
[11:10:45] <danyork> 3:10-4:10 pm tomorrow
[11:10:56] --- Shida has left: Disconnected.
[11:12:29] <danyork> looks like other presenters will be here so will proceed
[11:12:50] <danyork> Marie-Jose Montpetit now presenting because she won't be here
[11:12:53] <danyork> tomorrow
[11:13:05] <danyork> SIP for streaming media
[11:13:16] <csp> Will confirm on the mailing list, but plan for 3:10-4:10pm in same room tomorrow.
[11:13:25] <danyork> http://www3.ietf.org/proceedings/06jul/slides/mmusic-6.pdf
[11:13:32] --- csirkin has left
[11:14:10] <danyork> slide 3
[11:17:00] <danyork> up to slide 5
[11:17:22] <danyork> recommendation on slide 6
[11:18:36] <danyork> Dave Oran at mic - if you strip setup out of RTSP and have only stream control, why did you not consider MRCP?
[11:19:08] <danyork> Dave - saw nothing in draft explaining why using a subset of RTSP was better than MRCP
[11:19:23] <danyork> Rohan at mic
[11:20:57] <danyork> one of the chairs asking a question (can't see who from here)
[11:21:26] <jean-francois> was Joerg
[11:21:51] <danyork> Dave Oran back at mic - everything you just described is in the MRCP spec and we shouldn't describe another protocol
[11:22:20] <danyork> new preso
[11:22:32] <danyork> Kylin Weit for Bitrate header in RTSP
[11:22:36] <jean-francois> http://www3.ietf.org/proceedings/06jul/slides/mmusic-11.pdf
[11:23:35] <danyork> slide 3
[11:24:19] <danyork> slide 4, Example
[11:26:56] <danyork> preso over
[11:27:35] <danyork> chair asking question from Magnus Westerand (?) on mailing list about whether 3GPP has already solved this
[11:27:46] <danyork> and why this solution is different
[11:27:54] <danyork> chair - do we actually *need* a solution here?
[11:27:58] --- magnus has left
[11:28:09] <danyork> chair - what is advantage of your proposal over that of 3GPP?
[11:28:23] <danyork> Kylin Wei - can we take this to mailing list
[11:28:51] <danyork> chair - yes
[11:28:57] <danyork> new preso quick
[11:29:00] <danyork> Henning -
[11:29:04] <jean-francois> http://www3.ietf.org/proceedings/06jul/slides/mmusic-8.pdf
[11:29:24] <danyork> http://www3.ietf.org/proceedings/06jul/slides/mmusic-8.pdf
[11:29:28] * danyork laughs
[11:29:32] <jean-francois> :))
[11:29:58] * danyork acknowledges that jean-francois is far faster with the URL copy/paste
[11:30:08] <danyork> Henning up to slide 3
[11:31:24] <danyork> Henning asks question - is he going about this the right way?
[11:31:53] <jean-francois> (j/k may be, copy/paste only?)
[11:32:14] <danyork> rohan - what's to prevent originator from ignoring recipient's recording preference?
[11:32:33] <danyork> Henning - we can't *enforce* it, but it shows preference
[11:33:45] <danyork> Flemming at mic - why preconditions versus separate header?
[11:34:10] <danyork> Henning - my assumption was that we would delay ringing until conditions are set
[11:34:40] <danyork> mark tower at mic - could be dangerous without integrity check - MiTM could modify the statement
[11:35:07] <danyork> JR at mic - doesn't see this as precondition... more like text in subject line
[11:35:24] <danyork> JR - header okay, don't see need for precondition
[11:35:35] --- Aki has left
[11:36:37] <danyork> Steve (?) at mic - sees it unrealistic that users would create list in advance of who they would let record
[11:37:06] <danyork> i.e. doesn't think policies can be automated.
[11:37:15] <danyork> rohan at mic
[11:37:21] <danyork> ------
[11:37:29] <danyork> unfortunately, I have to leave now
[11:37:47] <danyork> bye all
[11:37:59] <jean-francois> thx dan
[11:38:02] --- jean-francois has left
[11:38:24] --- jean-francois has joined
[11:38:42] <jean-francois> resolution on Henning: look at other alternatives
[11:38:56] --- csp has left
[11:39:02] --- jpc has left
[11:39:06] <jean-francois> Colin confirmed meeting for tomorrow, 3:10-4:10pm
[11:39:10] --- sakuma.macx has left
[11:39:14] <cullenfluffyjennings@gmail.com> just saw
[11:39:42] --- jean-francois has left
[11:40:08] --- isudo has left
[11:40:35] --- ysuzuki has left
[11:43:34] --- cullenfluffyjennings@gmail.com has left: Logged out
[11:56:21] --- danyork has left: Disconnected
[11:58:03] --- dumdidum has left
[12:01:47] --- miki_h has left: Replaced by new connection
[12:56:16] --- danyork has joined
[12:56:34] --- danyork has left
[13:31:37] --- Aki has joined
[13:33:29] --- Aki has left
[17:15:08] --- LOGGING STARTED