[03:15:55] --- rpelletier has joined
[03:16:03] --- rpelletier has left
[04:43:09] --- kvehmanen has joined
[04:43:33] --- kvehmanen has left
[05:26:47] --- tomkri has joined
[06:31:27] --- tomkri has left: Logged out
[10:24:11] --- miro has joined
[10:24:20] --- miro has left
[10:27:07] --- tomkri has joined
[10:27:26] --- tomkri has left
[10:38:29] --- miro has joined
[10:38:32] --- miro has left
[10:58:51] --- bman has joined
[10:59:05] --- bman has left: Logged out
[10:59:11] --- bman has joined
[10:59:18] --- bman has left: Logged out
[11:15:26] --- amayer has joined
[11:15:50] --- amayer has left
[12:26:33] --- mlepinski has joined
[12:28:46] --- miro has joined
[12:31:00] --- renee has joined
[12:31:14] --- miro has left
[12:31:51] --- bman has joined
[12:32:39] --- scribe has joined
[12:33:08] <scribe> MMusic, IETF meeting shing March 19, 2007 shing 1740
[12:38:51] --- teemuk has joined
[12:39:38] --- ericc@jidfe.net has joined
[12:40:42] --- admin has joined
[12:47:05] --- Jean-Francois has joined
[12:47:18] --- csp has joined
[12:48:05] --- philip_matthews has joined
[12:48:07] --- ob has joined
[12:48:11] <scribe> NEW SPEAKER: Okay. Welcome shing everybody to MMusic.
[12:48:16] <scribe> Please calm down and please find your seats. Please join the
[12:48:18] <scribe> jabber room, in case people are mumbling away,
[12:48:21] <scribe> particularly, you will have the chance to read everything word by
[12:48:25] <scribe> word in our jabber room, and particularly for this reason, please
[12:48:28] <Jean-Francois> (speaker = Joerg Ott)
[12:48:29] <scribe> also make sure that you state your names clearly before you speak, so that we can
[12:48:34] <scribe> also get that into shing as good as possible.
[12:48:40] <scribe> And then we have programs, and so we better get started.
[12:48:46] <scribe> As usual, to begin with, intellectual property, you
[12:48:55] --- isudo has joined
[12:48:57] <scribe> know that boat got you're a quair of I
[12:49:01] <scribe> were sosh IP R sosh quait ted with what you're fawking
[12:49:04] <scribe> about, please disclose. You have probably read all the
[12:49:09] <scribe> sheets in your package so we don't have to spend all that time on
[12:49:09] <scribe> it.
[12:49:11] --- Jabber-Wile has joined
[12:49:14] <scribe> Our agenda today is kind of full. We have ice in the
[12:49:19] <scribe> beginning, to get finally finished. We have then a bit of
[12:49:23] <scribe> SDP, negotiation and then we have a random SDP extensions in
[12:49:24] <scribe> the end.
[12:49:29] --- jonlennox has joined
[12:49:32] <scribe> To begin, brief status report of where we are, where we have
[12:49:36] <scribe> been, where we have been and maybe in the end where we will
[12:49:41] <scribe> be going. We have three RFCs since the last IETF.
[12:49:44] --- amayer has joined
[12:49:47] <scribe> 45 '83, on SDP descriptions for the bin re flow control
[12:49:56] <scribe> protocol. We have 47 56 done for grouping in and the media
[12:49:56] <scribe> content.
[12:50:01] <scribe> We have I guess for Collin and myself, we calculated
[12:50:03] <scribe> yesterday, it took like four years now, one document,
[12:50:07] <scribe> probably close to obsolete, in the RFC editor and we are
[12:50:12] <scribe> probably not going to re submit it a revised I D on that one.
[12:50:17] <scribe> And release a number from the four digit RFC number space.
[12:50:19] <scribe> Hopefully to be re claimed.
[12:50:27] <scribe> And we do have one document with the IESG which are are the security pre
[12:50:32] <scribe> conditions and if we trust the I D track err tling is a revised
[12:50:36] <scribe> I D needed. So just as a reminder, please provide I us
[12:50:38] <scribe> with a revised I D on it.
[12:50:47] --- hejingtong has joined
[12:50:47] <scribe> And we are pretty much done with ice. thaers weird. Everything
[12:50:51] <scribe> comes in packets.
[12:50:55] <scribe> And we should use a different something.
[12:51:03] <scribe> And we are also pretty well along with the requirements for the
[12:51:07] <scribe> capability negotiation, we actually designed it and that's
[12:51:11] --- kvehmanen has joined
[12:51:11] <scribe> okay. Pretty much all the I M G related drafts are dead.
[12:51:15] <scribe> We may publish some of this stuff as experimental if the
[12:51:19] <scribe> authors are interested in that, will be removed from our
[12:51:20] <scribe> charter.
[12:51:24] --- dumdidum has joined
[12:51:28] <scribe> An interesting question is what about the faith of R T S P 2 point
[12:51:32] <scribe> O. At the moment it feels quite cold. Maybe we can revive
[12:51:35] <scribe> that thing to a certain extent but we have been launching
[12:51:38] <scribe> calls for support on that activity over and over again. So
[12:51:42] <scribe> if nobody really cares about that, well then, we may just let it
[12:51:46] <scribe> go away. Otherwise we will need real commitments from people
[12:51:47] <scribe> to work on this.
[12:51:49] --- hejingtong has left: 已登出
[12:51:56] --- gas has joined
[12:51:56] <scribe> R T S P-1 works to some extent. It has many many issues,
[12:52:02] <scribe> but it doesn't look. R T S P-2 has not been moving for a while.
[12:52:09] <scribe> So we will look at trying to form a review team in April, with regular
[12:52:13] <scribe> calls, so if you are eager to put something into it, and
[12:52:16] <scribe> your help is needed then please come to us.
[12:52:16] --- Magnus Westerlund has joined
[12:52:26] <scribe> Future directions for the next, for the short time to come,
[12:52:31] --- tomkri has joined
[12:52:33] <scribe> finish ice, ice live and ice I S T P. And that's
[12:52:36] <scribe> hopefully, finish media capability negotiation, which is
[12:52:38] --- ysuzuki has joined
[12:52:40] <scribe> we'll see later today how straightforward that is going to be.
[12:52:47] <scribe> And we believe that the specification is pretty much done,
[12:52:53] <scribe> particularly we will have to spend effort on the best effort
[12:52:58] <scribe> R, S R T P stuff. And well, then we have significant ek
[12:53:01] <scribe> stenk document addressing all kinds of media
[12:53:04] <scribe> capabilities, which is probably has a slightly longer way to
[12:53:08] <scribe> go. brut we have time on that one. And there are more
[12:53:11] <scribe> important things that are in reasonably good shape. And then
[12:53:14] <scribe> we have a couple of other documents that I want to advance,
[12:53:18] <scribe> and we will probably then at some point re charter to consider future
[12:53:19] <scribe> directions.
[12:53:26] --- hejingtong has joined
[12:53:26] <scribe> Any general comments before we ask for dab dash
[12:53:29] <scribe> no general comments, everybody is eager to
[12:53:31] <scribe> see the grand ice finish. Jonathan. NEW SPEAKER:
[12:53:32] <scribe> Okay. No pressure.
[12:53:38] <scribe> NEW SPEAKER: None at all. NEW SPEAKER: It's not me
[12:53:42] <scribe> that's going to finish.
[12:53:44] <scribe> NEW SPEAKER: Wow, look at this thing. It's cool.
[12:53:45] <scribe> Let me talk about ice.
[12:53:53] <scribe> Next slide. So, the good news is is that ice has, in
[12:53:57] <scribe> terms of the technical content of the specification has changed
[12:54:02] <scribe> very little, 14 to 13, 14 is backwards compatibe with 13 except
[12:54:06] <scribe> for the bug fixes, and if you hit that case, it wouldn't
[12:54:06] <Jean-Francois> (SPEAKER = Jonathan Rosenberg)
[12:54:08] <scribe> work. That's good. And there's not many of those, and I'll
[12:54:09] <scribe> describe they will in a moment.
[12:54:16] <scribe> However, there is roughly 1.2 ga sill yon editorial changes, and
[12:54:20] <scribe> that's as a consequence of thorough ringing by Eckard and
[12:54:23] --- emcho has joined
[12:54:25] <scribe> somebody else. And that was many countless hours to fix and it's
[12:54:28] <scribe> mostly clarity stuff. I'm not going to even review what
[12:54:33] <scribe> those are. Generally trying to break stuff up into more read
[12:54:37] <scribe> able snip pets into stead instead of one
[12:54:39] <scribe> big section with two page brakes.
[12:54:42] <scribe> Let's get to the technical changes, I'll review them quickly
[12:54:46] <scribe> now. Mostly bug fixes. The spec is still inconsistent on
[12:54:51] <scribe> when you have to include M candidates for media stream. Some
[12:54:57] <scribe> cases it says everything equals zero. And other cases I saw
[12:55:03] <scribe> all but A equal inactive. And all but four equal seer re.
[12:55:06] <scribe> And I fixed the remaining case there.
[12:55:12] <scribe> This came up in a common list, ice will based on the frozen algorithm check
[12:55:16] <scribe> the first M line first, and as a consequence, you'll be
[12:55:20] <scribe> able to send e me the first M line first, if you don't want to
[12:55:24] <scribe> wait for the rest. But if that is an important media stream for
[12:55:26] <scribe> you, you should actually list it first.
[12:55:31] <scribe> I think Eckard pointed out this next bug, you know, no,
[12:55:34] <scribe> somebody else reported it. It's a good point on. Actually,
[12:55:38] <scribe> so if you learn stun servers through D N S, if you learn a
[12:55:42] <scribe> cluster of stun servers, let's say you use a different one for
[12:55:45] <scribe> obtaining all of the different candidates that you're using for
[12:55:48] <scribe> the session, you'll end up with different
[12:55:52] <scribe> foundations for all these different candidates and the frozen algorithm
[12:55:56] <scribe> will perform poorly. So, Jonathan points out, this
[12:56:00] <scribe> probably won't work, in fact. But we'll fix that. And
[12:56:06] <scribe> so the, you should go and use the same stun server for the
[12:56:10] <scribe> entire call. In other words, don't load balance within a
[12:56:11] <scribe> call, you know, use the same one.
[12:56:16] <scribe> Next time you make a new SIP call, you'll use it and it works just
[12:56:17] <scribe> brait. Very simple.
[12:56:23] <scribe> This was a real corner case. If you're using turn to get U D P
[12:56:26] <scribe> relay candidates and server re Plaintiff's Exhibit sieve
[12:56:30] <scribe> candidates and the relay says, I'm totally out of capacity and there's nothing
[12:56:34] <scribe> else, I have got nothing for you, it will fail the request and you
[12:56:38] <scribe> won't get your server reflexive candidate either, which of
[12:56:45] <scribe> course you should be able to get. So it says do re try with
[12:56:47] <scribe> a regular stun server. A corner case.
[12:56:53] <scribe> Then as I was editing, a couple of things came up. There's the thing
[12:57:01] <scribe> about A equal inactive versus zero Dot zero Dot zero. And
[12:57:03] <scribe> this brakes ice, it just doesn't works. So you can't
[12:57:07] <scribe> really do that. If you're going to do ice, you have to
[12:57:11] <scribe> actually implement 30 six4 and use A equal inactive.
[12:57:19] <scribe> There was this bit in here, in the text says, if you learn a
[12:57:23] <scribe> a peer reflexive candidate in the initial change, when you do
[12:57:27] <scribe> your updated offer, you include the reflexive candidate.
[12:57:32] <scribe> It's not necessary to do that unless you explicitly want to do
[12:57:32] --- hb47713 has joined
[12:57:36] <scribe> that. This was a discussion we had several meetings ago with
[12:57:38] <scribe> Philip about how important this case was.
[12:57:40] <scribe> Now the text says, you don't have to do that unless you're
[12:57:44] <scribe> worried about the extra cases, because if you do, ice will
[12:57:47] <scribe> pair the peer reflexive candidates with all the other
[12:57:50] <scribe> candidates and continue text for them. Assuming you're doing
[12:57:53] <scribe> the re invite in the middle of ice, and that's generally
[12:57:55] <scribe> unnecessary. So I made that clearer.
[12:58:04] <scribe> Next slide. This one also, so, when you, let's say ice completes
[12:58:08] <scribe> and you send an updated offer, what candidates do you include?
[12:58:11] <scribe> At this point, we're done with ice. And the only reason
[12:58:15] <scribe> to include a candidate at all is to have like the user name and
[12:58:21] <scribe> pass words for the text checks and just to sort of clean stuff
[12:58:25] <scribe> up. So it used to say, you know, you should only include
[12:58:30] <scribe> your selected candidate. When there's never a reason to send
[12:58:35] <scribe> anything but your select candidate ever, so in the interest
[12:58:37] --- avwijk has joined
[12:58:38] <scribe> of not leaving open doors, I changed that to
[12:58:42] <scribe> must. Then I fixed the raise condition. This is -- no,
[12:58:46] <scribe> this is a different one. Oh, yes, I have to go through the
[12:58:53] <scribe> flow to explain it. But, the high level idea is ice would
[12:58:57] <scribe> say, when you're done, when you send a stun conductivity
[12:59:00] --- hbaosiy has joined
[12:59:01] <scribe> check with the stun candidate flag, we're finished so you have
[12:59:07] <scribe> if you have any tranks transactions in progress, it may not
[12:59:09] --- lminiero has joined
[12:59:12] <scribe> be true. You give up on re transmits and you may epd up with
[12:59:15] <scribe> an inconsistent view of whether that completed successfully or
[12:59:20] <scribe> not. So you can actually only stop re translates for a lower
[12:59:22] <scribe> priority track, next slide. Almost done.
[12:59:27] <scribe> If a controller uses, so I -- they used to have this somewhat
[12:59:31] <scribe> obscure thing about introspective versus reactive algorithms, it
[12:59:35] <scribe> didn't get much treatment. It's actually really important in the spec.
[12:59:38] <scribe> That section got much more substantial and I hope to explain it
[12:59:43] <scribe> better. I re named them to something more understandable. The
[12:59:46] <scribe> terminology also illustrates the recommended one, which is
[12:59:49] <scribe> regular. Aggressive is faster, but it runs into some
[12:59:50] <scribe> problems.
[12:59:55] <scribe> If you're using, and the aggressive algorithm is, when you
[12:59:58] <scribe> start your checks, put the use candidate flag in every single
[13:00:02] <scribe> request you send. Every single one. And as soon as a
[13:00:05] <scribe> single one of those completes, you're done.
[13:00:10] <scribe> Basically, the old ice all along before we put this candidate
[13:00:14] <scribe> flag. That does lead to a case where you can end up
[13:00:18] <scribe> selecting the pair, then a higher priority check completes,
[13:00:21] <scribe> and the selected pair changes. This is why we
[13:00:25] <scribe> usedd to have this lock down timer. We got rid of that and
[13:00:29] <scribe> had to use candidate flag. When we allowed the aggressive
[13:00:33] <scribe> mode, we kind six never never put it back. But it's only
[13:00:37] <scribe> needed on the updated offer. Since we can send media without
[13:00:41] <scribe> the updated offer in both directions, you can take your suite
[13:00:45] <scribe> old time. It's a fix up. So you can turn it down the you you
[13:00:46] <scribe> really want.
[13:00:52] <scribe> The biggest khainks is did next change is the next one.
[13:00:56] <scribe> It's the remote candidate race condition. And I'll remind you what
[13:00:58] <scribe> the problem is. Here's the offer, here's the answer.
[13:01:00] <scribe> Send an offer, send an answer, great.
[13:01:07] <scribe> Now, what happens is that we do a stun conductivity check in this
[13:01:10] <scribe> direction, that successes, and there's a
[13:01:13] <scribe> packet loss. And as far as this guy is concerned we're finish
[13:01:16] <scribe> finished. In fact, he put the use candidate flag in and
[13:01:16] <scribe> all that.
[13:01:23] <scribe> It turned out that because of nats in the middle, the row meet
[13:01:26] <scribe> candidate, the IP address at the offer sees for the
[13:01:32] <scribe> answer, so the answers candidate is new, it was learned. So
[13:01:36] <scribe> in that case the updated offer arrives, and it contains a remote
[13:01:40] <scribe> candidate that's actually, that the answer has never even
[13:01:43] <scribe> seen before. What's this, you say? I don't know what
[13:01:46] <scribe> that is. He's about to learn it if he would just wait, you know, just
[13:01:52] <scribe> wait for that, you know, this stun transaction to
[13:01:54] <scribe> complete, it will teach him this new candidate and it's
[13:01:57] <scribe> priority and foundation and all that.
[13:02:00] <scribe> That in itself is not such a problem, except whether the
[13:02:03] <scribe> updated offer comes, you have to send the answer and that answer is
[13:02:07] <scribe> supposed to contain the candidate that was selected. But you
[13:02:09] <scribe> don't even know the candidate was selected. You've been
[13:02:13] <scribe> instructed as to what it is in the remote candidate. You don't have the
[13:02:16] <scribe> rest of the information necessary to fill in the rest of the A equal
[13:02:21] <scribe> candidate attribute. So you have to wait to send the answer.
[13:02:24] <scribe> That's the ugly part. You get an offer and the remote
[13:02:27] <scribe> candidate is a candidate you don't even know. You must wait
[13:02:30] <scribe> for your check to complete and then send the answer.
[13:02:33] --- TomTaylor has joined
[13:02:34] <scribe> Now, this would be kind of horrible except that the case in
[13:02:38] <scribe> which this happens is an amazingly rare case, and in fact I'm
[13:02:44] <scribe> fairmly sure it requires Philip's topologies where it's not a
[13:02:47] <scribe> symmetric nat, otherwise it would know
[13:02:51] <scribe> about the candidate. And the only reason, if it were a
[13:02:54] <scribe> symmetric nat, the check would complete in this direction.
[13:02:59] <scribe> So the case in which afford check teaches a new candidate, I
[13:03:02] <scribe> mean, it like real corner. But again, toyv cover all the
[13:03:06] <scribe> bases so it's a minor bug fix, but it's -- next slide.
[13:03:16] <scribe> I added hints, we agreed last time to add mux.
[13:03:20] <scribe> And I have to hint that. And you know, you would kind of do that kind of
[13:03:26] <scribe> thing. Is all it really says. And I documented how ice
[13:03:28] <scribe> and A nat work together. We're going to have a more extended
[13:03:30] <scribe> discussion on that. So I'll leave that for now.
[13:03:36] <scribe> That is it, all the changes in dash 13. Those are mostly
[13:03:40] <scribe> minor bug fixes that come up when you're polishing the document.
[13:03:45] <scribe> Good sign. Of course, as is inevitable. People raise
[13:03:49] <scribe> more bugs as they look at documents. So I have a
[13:03:53] <scribe> couple more that were reported to me that I didn't go into 14
[13:03:54] <scribe> because I didn't know about them.
[13:03:58] <scribe> This is an interesting one, which is the ice algorithm makes
[13:04:01] <scribe> this real fundamental assumption, it's
[13:04:05] <scribe> absolutely foundation Al to the algorithm. One side is
[13:04:08] <scribe> controller and one side is controlling agent. And they
[13:04:09] --- tobia has joined
[13:04:13] <scribe> unambiguously agree to this. In our normal
[13:04:17] <scribe> flows, regular first party flows all of the third party call party
[13:04:21] <scribe> flows in the spec, this is a correct assumption. However, people
[13:04:25] <scribe> point where it is not a correct assumption. These are not great call
[13:04:27] <scribe> flows, there's are not call flows that we think are
[13:04:30] <scribe> necessarily the best current practice, but they're all, you
[13:04:34] <scribe> know, application, moving call legs around, we're
[13:04:38] <scribe> using all SDP, all kinds of good stuff that people do
[13:04:40] <scribe> in practice. The interesting problem is that you can
[13:04:45] <scribe> end up with both problems in these cases, where both
[13:04:48] <scribe> ends think they're controller and controlling. We don't have
[13:04:52] <scribe> to optimize for this case, but ice actually fails poorly in
[13:04:55] <scribe> this case. And I wanted to make sure we add the minimum fix
[13:05:00] <scribe> to at least detect and fix if possible. So, there's a fix
[13:05:02] <scribe> for each of them and fortunately they're relatively
[13:05:07] <scribe> straightforward and I'm going to tut them in fifteen. I'd like to
[13:05:07] <scribe> do that.
[13:05:10] <scribe> Next slide. So, if both agents are the
[13:05:13] <scribe> controller, this is actually easy, because it's trivial to
[13:05:16] <scribe> detect. If I think I'm the controlling agent, I should
[13:05:19] <scribe> never receive a stun request with the use candidate flag in it. But
[13:05:23] <scribe> if the other guy also thinks he's the controlling agent, I always
[13:05:26] <scribe> will. So if you're the controlling agent and you get a use
[13:05:29] <scribe> candidate in a stun request, you've detected the problem.
[13:05:32] <scribe> Then the only hard part is how you back out of it. What I do
[13:05:36] <scribe> in both these cases, I revert to a tie breaker, which
[13:05:40] <scribe> again, is not optimal, right, but again, I'm going to be able to
[13:05:45] <scribe> fix up most of these cases. Which is basically the largest U
[13:05:50] <scribe> dpraing wins. So, we, I used to have text in the
[13:05:53] <scribe> document about largest for things that were not numbers and
[13:05:58] <scribe> basically treat it as a, like a, instead of having a
[13:06:02] <scribe> decimal system, it's whatever, you know, if it was 16
[13:06:07] <scribe> characters, hexadecimal. Whatever that is. And you do
[13:06:11] <scribe> the comparison and the largest one wins. Basically, you run a tie
[13:06:14] <scribe> breaker and whoever is actually the controlling agent proceeds.
[13:06:18] <scribe> If it turns out that when you receive the stun request, you're the
[13:06:21] <scribe> controlling agent, and the other side isn't, you reject the
[13:06:25] <scribe> stun request and anyway, he'll know it the minute he gets the
[13:06:28] <scribe> rejection and he'll re pick and everything works great. This
[13:06:30] <scribe> one detects and recovers quite nicely.
[13:06:34] <scribe> This one, where both agents think they're
[13:06:37] <scribe> controller, you have to wait for a time out because you'll never get the use
[13:06:37] --- philip_matthews has left
[13:06:43] <scribe> candidate flag. That's what you do. I made up a random
[13:06:47] <scribe> 500 milli second timer. This is a corner case so what am I going
[13:06:51] <scribe> to do. If you complete it and you never see a use candidate
[13:06:54] <scribe> from the controlling side, at some point you run the tie
[13:06:57] <scribe> breaker and do this. That's it. NEW SPEAKER:
[13:07:02] <scribe> dwo issues of this, first that because different media
[13:07:06] <Jean-Francois> (Jonathan Lennox)
[13:07:06] <scribe> streams have different view frag did (Several people
[13:07:09] <scribe> talking.) NEW SPEAKER: I knew you were going to say that.
[13:07:14] <scribe> I menlt the largest U frags, and he takes all of his
[13:07:17] <scribe> U frags and the largest is -- NEW SPEAKER:
[13:07:21] <scribe> So, the case I'm worried about is a three P cc where somebody is
[13:07:26] <scribe> stitching together the media streams from different sources, which
[13:07:32] <scribe> are, I don't know if that's valid, but so, the other case
[13:07:34] <scribe> is the -- NEW SPEAKER: You want to suggest a better tie breaker? NEW SPEAKER:
[13:07:39] <scribe> I'm not sure. The other thing is, after completion of all
[13:07:44] <scribe> checks, the other side is, if you have a something going into a black
[13:07:49] <scribe> whole, and never get I C P for it can take ten seconds by the
[13:07:51] <scribe> definition of stun. NEW SPEAKER: Okay. NEW SPEAKER:
[13:07:54] <scribe> So that means that this ten seconds -- NEW SPEAKER:
[13:07:58] <scribe> Yes, but the stun transaction will time out long before ten seconds. NEW SPEAKER:
[13:08:03] <scribe> I thought the timer is, for stun is, back off --
[13:08:08] <scribe> NEW SPEAKER: It's like r50 milli seconds. NEW SPEAKER:
[13:08:11] <scribe> Reject the back offer on. NEW SPEAKER: I don't think it's ten.
[13:08:12] <scribe> I thought it was like two or something. NEW SPEAKER: I'd
[13:08:17] <scribe> have to look. NEW SPEAKER: Okay. I mean shing this
[13:08:20] <scribe> was after the completion of the last transaction. So this is
[13:08:21] <scribe> post that.
[13:08:27] <scribe> I'll think if I can come up with a better tie breaker, I want to see if
[13:08:31] <scribe> there's something that comes up in the tie breaker too. The
[13:08:34] <scribe> only case where you run into problems is where there's not
[13:08:39] <scribe> actually signal discrete end point and you may have inconsist
[13:08:42] <scribe> Us on what the largest frag is.
[13:08:45] <scribe> I mean, there's potential fixes. We don't have to work in all
[13:08:48] <scribe> cases, I mean, so we're just trying to detect and recover
[13:08:51] <scribe> dpr the problem as best as possible. Any comments?
[13:08:56] <scribe> NEW SPEAKER: Philip Mathews, just another one. Isn't
[13:08:59] <scribe> there a case where you change the U frag in some cases, on
[13:09:02] <scribe> some re invites dash NEW SPEAKER: But when you re
[13:09:06] <scribe> start, you re start ice. So if that happens, you may have this
[13:09:09] <scribe> case not happen initially and happen on the re start. That's fine. That works. NEW SPEAKER:
[13:09:13] <scribe> Okay. NEW SPEAKER: So I'll think about whether there's something better
[13:09:17] <scribe> than the U frag and if not, we'll have to declare that one a hopeless
[13:09:20] <scribe> case and fix this other one. Any problems with that? Then
[13:09:24] <scribe> again, I'm just trying to get these last things polished
[13:09:27] <scribe> here. NEW SPEAKER: Adam roach, if I can grow something
[13:09:31] <scribe> possibly a little crazy, I know we don't want to optimize the
[13:09:35] <scribe> failure case, but we're frying to do things here without
[13:09:38] <scribe> being explicit. And that has the problem of the second
[13:09:41] <scribe> solution means that even though you probably won't use it every
[13:09:45] <scribe> single time you do ice, you're going to run this timer and that
[13:09:48] <scribe> probably solves it unless things go off the rails. NEW SPEAKER:
[13:09:52] <scribe> You want to put dash NEW SPEAKER: Actually, I want to fix
[13:09:54] <scribe> both problems at the same time. But that's the first half of
[13:09:58] <scribe> it. You put an attribute that basically says, I think I'm the
[13:10:03] <scribe> controller and the controller. And the by the way, my
[13:10:07] <scribe> randomly chosen cookie e we're going to use as food. NEW SPEAKER:
[13:10:10] <scribe> Okay. Right. That could work. It still won't work in
[13:10:15] <scribe> Jonathan's case. Which I just don't know how to solve that
[13:10:17] <scribe> case, because you're dealing with three end
[13:10:22] <scribe> points dha each side thinks there's two. I'm totally bee if you
[13:10:26] <scribe> do Delld how to fix that. I mean, I don't know how to
[13:10:26] <scribe> do that.
[13:10:29] <scribe> You disagree, Adam?
[13:10:32] <scribe> NEW SPEAKER: No, I was -- NEW SPEAKER: You see what
[13:10:33] --- spromano has joined
[13:10:34] <scribe> I'm saying. NEW SPEAKER: I don't think we can solve
[13:10:37] <scribe> that problem. NEW SPEAKER: Right. So my view is,
[13:10:41] <scribe> I always was trying to make -- you know, I'm, I'm trying to make
[13:10:45] <scribe> as few changes as possible in every way, and you know, to me, just
[13:10:49] <scribe> making a tie breaker on stuff we already have, unless this
[13:10:52] <scribe> covers additional corner cases, which it doesn't sound like
[13:10:54] <scribe> it does, I don't see the benefit.
[13:10:58] <scribe> Yes, no?
[13:11:02] <scribe> NEW SPEAKER: Yes, but this is, I would hate to say that
[13:11:06] <scribe> in the, in making as few changes as possible to the spec,
[13:11:11] <scribe> we end up adding this relatively high implementation complexity
[13:11:15] <scribe> both at like implementation time and run time. By adding a new
[13:11:18] <scribe> timer, to handle (Several people talking.)
[13:11:20] <scribe> NEW SPEAKER: In your case. NEW SPEAKER: My objection
[13:11:22] <scribe> here, primarily is to adding another timer. NEW SPEAKER:
[13:11:27] <scribe> I see, I see. Okay. Any other comments
[13:11:30] <scribe> on that, whether they have a preference for that? I have
[13:11:33] <scribe> to think whether that totally eliminates the timer.
[13:11:45] <scribe> If we ignore the two way case, it probably does.
[13:11:49] <scribe> NEW SPEAKER: Make a media attribute. NEW SPEAKER: You
[13:11:53] <scribe> can't. Any of that stuff runs into the same three G cc
[13:11:54] <scribe> problems.
[13:11:59] <scribe> If we add a little bit that says if it's not present, you
[13:12:03] <scribe> default to the offerer as the controller and the offerer party
[13:12:07] <scribe> is controlling, and we get backwards compatibility with
[13:12:12] <scribe> this, and it's probably simpler. Is the group
[13:12:12] <scribe> okay with that?
[13:12:18] <scribe> Anyone -- NEW SPEAKER: Originally the tie breaker was the
[13:12:22] <scribe> original offer that was dash NEW SPEAKER: Why is there no
[13:12:25] <scribe> Mike here? NEW SPEAKER: Because he's holding it. NEW SPEAKER:
[13:12:29] <scribe> The remote Mike didn't work on us. NEW SPEAKER: The
[13:12:32] <scribe> original tie breaker was the original offer that was the controller
[13:12:35] <scribe> of everything else. Does inform that not work. NEW SPEAKER:
[13:12:37] <scribe> What is the original offer you mean? NEW SPEAKER: The
[13:12:39] <scribe> guy who sent the first --
[13:12:39] <scribe> (Several people talking.)
[13:12:43] <scribe> NEW SPEAKER: We're right back to the same problem. You can
[13:12:45] <scribe> actually have both sides with the original offer. NEW SPEAKER:
[13:12:48] <scribe> I haven't seen this call flow. NEW SPEAKER: I have
[13:12:51] <scribe> several that have this. They're all awful SDP weird
[13:12:53] <scribe> flows with controllers.
[13:12:58] <scribe> Yes, so the current spec is controller for this round, but
[13:13:02] <scribe> they're all the same. So, okay. I'm going to do what
[13:13:06] <scribe> Adam suggests with the backward compatibility fall back. I'll look
[13:13:10] <scribe> at, you know, not if you understand and in order
[13:13:15] <scribe> if nod if you understand you and you think that's okay. NEW SPEAKER: Can
[13:13:17] <scribe> you restate that? NEW SPEAKER: The proposal to fix
[13:13:23] <scribe> this bug, is that we will add a U attribute that gets present
[13:13:25] <scribe> in a stun request that indicates whether you think you're the
[13:13:28] <scribe> controlling or the controlled party, and includes a random
[13:13:28] <scribe> number.
[13:13:34] <scribe> Okay. And if you get this, the same conditions apply, you
[13:13:38] <scribe> know, what's this? You say you're controller, I thought I was
[13:13:41] <scribe> controller. You'll detect it because the flag will actually say
[13:13:45] <scribe> this. And then you'll break the tie based on the content of
[13:13:45] <scribe> the random number.
[13:13:51] <scribe> That's the proposed approach. And that attribute is not
[13:13:54] <scribe> present, you fall back like a U frag breaker. NEW SPEAKER:
[13:13:57] --- robert.mcqueen has joined
[13:13:58] --- robert.mcqueen has left: Disconnected
[13:13:59] <scribe> I'm not sure you need to run a number. It seems like you
[13:14:03] <scribe> need an algorithm and the only people who ever put it in are U A and
[13:14:07] <scribe> three G cc and everything else defaults to what you have now.
[13:14:09] <scribe> NEW SPEAKER: This is a stun attribute. (Several people talking.) NEW SPEAKER:
[13:14:13] <scribe> It's an attribute in a stun message, because that fixed this.
[13:14:20] <scribe> We don't need a timer for this. That was Adam's point.
[13:14:22] <scribe> I'll see that none of us are the controller in the very first
[13:14:25] <scribe> stun check. Therefore I can run the tie breaker immediately and
[13:14:28] <scribe> immediately, you know, fix the -- it will be detected right
[13:14:30] <scribe> away. See what I'm saying?
[13:14:34] <scribe> In stakt, in fact, with the flag, you'll detect
[13:14:38] <scribe> this on the very first stun check even before the candidate flag
[13:14:43] <scribe> shows up. So it will also be be an earlier than these, and
[13:14:47] <scribe> so, then the random numbers also in the stun message, to deal with
[13:14:52] <scribe> this issue of, you know, who knows what people did with U
[13:14:53] <scribe> frags or whatever. Okay.
[13:14:58] <scribe> All right. NEW SPEAKER: Can I just ask one more
[13:15:01] <scribe> question really quick. This is just to address the case where
[13:15:04] <scribe> both agents are controlled to eliminate the timer?
[13:15:07] <scribe> Because the concern was regardless of whether or not you hit
[13:15:10] <scribe> the scenario, you're going to have to implement the timer, even
[13:15:14] <scribe> if you think you're controlled or controlling. NEW SPEAKER:
[13:15:18] <scribe> With this proposal, you'll get rid of timer. (Several people
[13:15:22] <scribe> talking.) NEW SPEAKER: Yes. It and it also improve the
[13:15:22] --- robert.mcqueen has joined
[13:15:25] <scribe> detection, it will be ex split sit on the very first stun check rather
[13:15:28] <scribe> than waiting for all these candidates. NEW SPEAKER:
[13:15:33] <scribe> That sounds good I will make that change in ice
[13:15:36] <scribe> fifteen. NEW SPEAKER: Yes. NEW SPEAKER: Is
[13:15:37] <scribe> somebody naiking notes? NEW SPEAKER: Yes, two
[13:15:41] <scribe> people. NEW SPEAKER: Bring that Mike to the front. It might
[13:15:44] <scribe> be easier. NEW SPEAKER: Great idea. Was there
[13:15:50] <scribe> another question?
[13:15:54] --- robert.mcqueen has left: Disconnected
[13:15:54] <scribe> NEW SPEAKER: The there's people walking in and out and throwing
[13:15:57] <scribe> me off. Pick it up and carry it to the front. Thank
[13:15:57] <scribe> you.
[13:16:05] <scribe> NEW SPEAKER: Philip Mathews. I have another large
[13:16:08] <scribe> question that somebody else didn't want to say. We
[13:16:11] <scribe> originally started conference calls back in the fall. This
[13:16:16] <scribe> is actually a simplification, we started the conference calls back in
[13:16:20] <scribe> the fall. You were really keen on the aggressive whatever,
[13:16:23] --- bman has left: Replaced by new connection
[13:16:23] <scribe> the aggressive whatever mode and with less keen on the (Several people
[13:16:23] <scribe> talking.)
[13:16:26] <scribe> NEW SPEAKER: I've totally flipped on that. NEW SPEAKER: I noticed
[13:16:29] <scribe> that when I read the document. (Several people talking.) NEW SPEAKER:
[13:16:32] <scribe> Can we drop the aggressive mode. NEW SPEAKER: That
[13:16:35] <scribe> crossed my mind when I was writing the spec, I kid you not.
[13:16:42] <scribe> I was worried because it remains a valid something and you are
[13:16:44] <scribe> increasing delays and you're going to basically require
[13:16:48] <scribe> whatever, as many video, R T T you're going to double it.
[13:16:52] --- bman has joined
[13:16:53] <scribe> And in many use cases, especially where you're
[13:16:57] <scribe> running ice for V four, v6, aggressive is probably going to
[13:17:02] <scribe> be the better choice. I didn't want to revisit all these old
[13:17:05] <scribe> design decisions. We did agree to do them both and I wasn't
[13:17:07] <scribe> going to remove them all. NEW SPEAKER: Is there any
[13:17:12] <scribe> point, just because I think it would be a fair amount of SIM
[13:17:13] <scribe> nri indication. NEW SPEAKER: It would be a little,
[13:17:21] <scribe> not a lot. It would be less flag, remove the thing on aggressive.
[13:17:26] <scribe> And the selected algorithm would always equal the nominated
[13:17:29] <scribe> one, as opposed to having one a priority comparison.
[13:17:33] <scribe> That's not huge in my opinion. And I really am trying to
[13:17:37] <scribe> approach the stability in this document, these are
[13:17:42] <scribe> bugs, that's what I'm trying to fix. Corner cases, I'm not
[13:17:46] <scribe> really interested in design Dee is sitions. NEW SPEAKER:
[13:17:50] <scribe> You imply in the spec you're either doing aggressive or regular.
[13:17:56] <scribe> Is it possible to, these changes, it will do these
[13:17:57] <Jean-Francois> (J. Lennox)
[13:18:00] <scribe> aggressive and the rest regular? NEW SPEAKER: Across
[13:18:04] <scribe> different media streams. NEW SPEAKER: No. Same
[13:18:09] <scribe> component. Just pick a few aggressive, if they success
[13:18:11] <scribe> succeed, do those. NEW SPEAKER:
[13:18:15] <scribe> Yes, basically, they're all variants on
[13:18:17] <scribe> the aggressive. Because on the receiving side, all you,
[13:18:20] <scribe> you always run the same thing. You take all the use, the
[13:18:24] <scribe> ones that have use candidates flags and pick the highest,
[13:18:29] <scribe> if there's one, two, three, it doesn't matter. It's the same algorithm.
[13:18:32] <scribe> It's not so much an over SIM nri fi indication as you might
[13:18:32] <scribe> think.
[13:18:38] <scribe> NEW SPEAKER: So A nat is probably the big ees issue.
[13:18:42] <scribe> It's not an ice issue. It changes how we describe this, or
[13:18:44] <scribe> something else to describe the problem.
[13:18:53] <scribe> There's definite overlap. Although I note that the
[13:18:56] <scribe> requirements document, originally said we weren't going to do
[13:19:00] <scribe> this. They were and then dhe decided not to address this
[13:19:03] <scribe> problem. Architecturally, you certainly could and it's
[13:19:06] <scribe> going to work better than A nat, so here's a quick, sort of
[13:19:07] <scribe> sense how you do this.
[13:19:13] <scribe> The problem is, if I'm doing them, how do I pick to use V
[13:19:18] <scribe> four, v6. The way ice would work, and thls always
[13:19:21] <scribe> worked. You will just do this and it would work. Since like
[13:19:24] <scribe> version zero. For each media stream, you just include V
[13:19:28] <scribe> four and v6 candidates and prioritize them as needed. Maybe
[13:19:31] <scribe> you prefer v6, maybe V four, whatever you want.
[13:19:36] <scribe> You include multiple v6 candidates for six to four selection
[13:19:40] <scribe> selection of, so many different types of v6 addresses, you
[13:19:42] <scribe> put in as many as you like.
[13:19:48] <scribe> You run, then you selection in the end can be based on
[13:19:52] <scribe> priority conductivity. Icing on the case is with the regular
[13:19:55] <scribe> selection algorithm, you could layer in the v6 selection,
[13:19:59] <scribe> there's a separate spec that talks about how you pick amongst
[13:20:02] <scribe> v6 addresses. You can run that as a local priority algorithm,
[13:20:05] <scribe> using the regular selection technique. So you can layer that
[13:20:09] <scribe> stuff in. And ice will work great, because if the v6 path is
[13:20:14] <scribe> broken, then you can fall back to V four or even if, let's
[13:20:17] <scribe> say you're not interested in always preevring v6, let's say
[13:20:21] <scribe> you want the lower latency one, it may actually happen to be
[13:20:27] <scribe> that it's V four, not v6 interface. And they'll require re invite
[13:20:30] <scribe> if you guessed wrong in the default, as always. And e
[13:20:35] <scribe> so, it's real nice. Much more snrex I believe,
[13:20:39] <scribe> flexible, much more robust.
[13:20:46] <scribe> Select v6, if both are v6. If you do a re invite needed if
[13:20:51] <scribe> the remote side doesn't support A nat, but not if they do.
[13:20:56] <scribe> Next slide. You can use them together. You can basically
[13:21:02] <scribe> use A nat have an M line for v6, M line for V four. The v6
[13:21:09] <scribe> M line contains v6 candidates. The V four has one or more V four
[13:21:12] <scribe> candidates and then you do a hybrid things that says you'll
[13:21:16] <scribe> pick the v6 pair if at least one of the v6 validates, and only
[13:21:21] <scribe> if none of them, do you pick V four. That's sort of across
[13:21:24] <scribe> between ice and A nat, you can do that.
[13:21:28] <scribe> In some sense, it picks the worst, because you still need to
[13:21:33] <scribe> do if remote require, and also if the selected candidate
[13:21:38] <scribe> doesn't match the M C line. So you get the double wam me.
[13:21:45] <scribe> As a third option, you can use SDP capability, and it could
[13:21:48] <scribe> support are it and that's pretty much what A nat is doing. NEW SPEAKER:
[13:21:50] <scribe> Just a question. NEW SPEAKER: Name. NEW SPEAKER:
[13:21:57] <scribe> Nor tell somebody. And the ice plus a nat. So where
[13:21:59] <csp> francois audet
[13:22:03] <scribe> does it fit when you, you're trying to, you're obviously
[13:22:10] <scribe> trying to IP v6, but you want to be, to sf insure that it
[13:22:14] <scribe> will work if the other side is not support ice? NEW SPEAKER:
[13:22:19] <scribe> The T fold would be a V four address. NEW SPEAKER:
[13:22:22] <scribe> Right. But that means you need A nat for that, for
[13:22:25] <scribe> supporting IP v6. NEW SPEAKER: With ice alone you mean? NEW SPEAKER:
[13:22:36] <scribe> No. Here's the scenario. I call you, my, I do no ice.
[13:22:40] <scribe> I do A nat. I return the terminal. Your terminal is not
[13:22:44] <scribe> that great. It supports IP v6 but doesn't
[13:22:46] <scribe> support ice. NEW SPEAKER: Doesn't do A nat? NEW SPEAKER:
[13:22:49] <scribe> Right. And would that be covered by your dash NEW SPEAKER:
[13:22:51] <scribe> No. NEW SPEAKER: Your third one? NEW SPEAKER:
[13:22:56] <scribe> The one that says ice plus A nat or is that a different
[13:22:59] <scribe> problem. NEW SPEAKER: Yes, that would work. So
[13:23:04] <scribe> ice plus A nat would mean if I'm the caller, and doy ice plus
[13:23:09] <scribe> A nat and you're the caller, we revert to a A nat and no ice. NEW SPEAKER:
[13:23:12] <scribe> So regardless of what you're recommending, and maybe this
[13:23:17] <scribe> is the next slide, we still need A nat, if anything, for the
[13:23:20] <scribe> backward compatibility problem. NEW SPEAKER: So the
[13:23:25] <scribe> issue at hand is, are we effectively
[13:23:27] <scribe> deprecating A nat? NEW SPEAKER: Right. NEW SPEAKER:
[13:23:31] <scribe> And that's the choice here, because the issue is, you have
[13:23:35] <scribe> v6 end points that make the selection using A
[13:23:38] <scribe> nat, that's the assumption you just made. If we say the default
[13:23:40] <scribe> selection is ice, you wouldn't have that problem. Right.
[13:23:43] <scribe> None of this stuff is really deployed. NEW SPEAKER:
[13:23:48] <scribe> Right. NEW SPEAKER: So it's a spec backwards
[13:23:53] <scribe> compatibility issue. What would be right in the SIPPING v6 V
[13:24:00] <scribe> four trans. Dual honed to a device or A nat or SDP
[13:24:02] <scribe> cabinet negotiation. NEW SPEAKER: Okay. I'll wait
[13:24:08] <scribe> until see what you suggest. NEW SPEAKER: I
[13:24:10] <csp> gonzalo
[13:24:11] <scribe> suggest ice. NEW SPEAKER: Maybe to give background,
[13:24:14] <scribe> we got feedback from the v6 guys and they were concerned
[13:24:17] <scribe> exactly about that case. We said that basically, using ice everybody
[13:24:21] <scribe> has to implement ice and no matter if you are using V four and v6,
[13:24:25] <scribe> you will use ice. They are actually challenging that
[13:24:29] <scribe> assumption. Because let's say Greenfield v6 deployment,
[13:24:32] <scribe> they would actually only like to use offer answer and then
[13:24:36] <scribe> don't use ice. They will implement something for inter route
[13:24:39] <scribe> ability, and side effects that ice has and they
[13:24:43] <scribe> are nice actually. So we were wondering if it actually worth it
[13:24:45] <Jean-Francois> (Gonzalo Camarillo)
[13:24:49] <scribe> to add several ways of doing things, ice plus A nat and
[13:24:52] <scribe> that kind of stuff so we would like to have discussions whether
[13:24:54] <scribe> it makes sense to require ice for that. NEW SPEAKER: I
[13:24:59] <scribe> think what's happening is ice is handy for other things here and
[13:25:05] <scribe> there as Gonzalo calls side effect problems. Where I I run ice
[13:25:08] <scribe> and I don't gather server reflexive or candidates and I'm not
[13:25:12] <scribe> using it for nat source, I'm using it because it helps me select
[13:25:16] <scribe> because it solves the voice, the voices hammer attack,
[13:25:20] <scribe> because it solves the forking correlation problem. You
[13:25:24] <scribe> know, it solves like a bunch of other side effects that are
[13:25:29] <scribe> nice and has the benefit of, if you call a regular V four nat
[13:25:33] <scribe> end point you happen to nicely get ice for them to get their
[13:25:33] --- akiniemi has joined
[13:25:33] <scribe> nat traverse Sal.
[13:25:41] <scribe> So one of my not so subtle reasoning is that ice has this difficult
[13:25:46] <scribe> deployment barrier where you need both sides to support it.
[13:25:50] <scribe> And I go like geez, e we could have another thing that solves
[13:25:54] <scribe> this in a better way than A nat, why shouldn't we do that?
[13:25:58] <scribe> Why should we have a different mek nis many for that.
[13:26:05] <scribe> The complexity is a real concern. Ice is more complex than A
[13:26:11] <scribe> nat, so you could have SDP cap negotiation plus ice. I
[13:26:15] <scribe> talked with Flemming about this and it made my head blow up.
[13:26:20] --- roni_even has joined
[13:26:23] <scribe> I think it's an awful idea. So today the potential fix is
[13:26:30] <scribe> priority order. If this ice check succeeds, then pick this
[13:26:33] <scribe> con fig, but I'm not proposing that, Flemming, so dash NEW SPEAKER:
[13:26:34] --- Brandybuck has joined
[13:26:36] <scribe> That's good. I just want to say I'm not proposing that
[13:26:40] <scribe> either. And on the capability negotiations, most of this
[13:26:43] <scribe> needs to be clear. This is not part of what we have in scope
[13:26:46] <scribe> today or in the solution but we can define an extension. NEW SPEAKER:
[13:26:49] <scribe> I understand. Yes. NEW SPEAKER: Question? NEW SPEAKER:
[13:26:54] <scribe> Chris ter Homer. I like to ask one question about this.
[13:26:59] <scribe> Replacing A nat with ice. Let's assume that I'm going to use
[13:27:05] <scribe> ice for what I use A nat for today. I mean, I don't have a
[13:27:09] <scribe> nat traverse Sal problem. So I only want to use ice in order
[13:27:14] <scribe> to do that for V four. V6. Do I need to implement the
[13:27:15] <scribe> full ice or would (Several people talking.) NEW SPEAKER:
[13:27:21] <scribe> actually start to call it ice media, to just
[13:27:25] <scribe> piss people off. NEW SPEAKER: You can't implement ice light as
[13:27:28] <scribe> defined today, because if both sides do it, you wonlt do
[13:27:33] <scribe> the checks required to pick, and you'll need to do full ice
[13:27:36] <scribe> except you can skip the server reflexive and re lae
[13:27:37] <scribe> gathering. NEW SPEAKER: (Several people talking.) NEW SPEAKER:
[13:27:44] <scribe> NEW SPEAKER: I mean, this is something you can always do.
[13:27:48] <scribe> I mean, maybe the V four, v6 trans document would say it
[13:27:52] <scribe> requires no changes in ice to do that. So that would be appropriate
[13:27:55] <scribe> for that. Because you may want to do it anyway. You know,
[13:28:00] <scribe> I mean, it, we'll see how it goes with v6 equals no nat
[13:28:03] <scribe> theory. That's my personal opinion that it is a theory. You
[13:28:08] <scribe> know, so, we'll see. But yes, you would skip the server
[13:28:13] <scribe> reflexive relay if you just wanted to can do dual host. NEW SPEAKER:
[13:28:15] <scribe> Must NEW SPEAKER: NEW SPEAKER: It's not must
[13:28:19] <scribe> today, e it's should. NEW SPEAKER: Hello. So I
[13:28:22] <scribe> think this is two cases like we were discussing, general
[13:28:27] <scribe> solution, and then you say, about this in ice packet. So
[13:28:33] <scribe> I think, I really prefer this. Like these cases, I guess
[13:28:37] <scribe> those still are, supporting old case, so they can still be
[13:28:41] <scribe> used in the future too, in the same as this ice light, I
[13:28:44] <scribe> think. NEW SPEAKER: So, I'm, I don't understand the
[13:28:48] <scribe> point. Sorry. NEW SPEAKER: So I would prefer
[13:28:57] <scribe> like, so in ice, especially having like using ice, A nat in ice
[13:29:01] <scribe> pack, because this might be one option to use and others would
[13:29:05] <scribe> provide the other way to use, like ice light provides another
[13:29:08] <scribe> way to use dash NEW SPEAKER: I'm not sure what you're
[13:29:13] <scribe> asking for. NEW SPEAKER: Like A nat is now like
[13:29:16] <scribe> problem. There are already people using and they wouldn't (Several people talking.) NEW SPEAKER:
[13:29:18] <scribe> There's already specs that describe it. NEW SPEAKER:
[13:29:23] <scribe> Yes. So I think that this should be the ice spec should
[13:29:28] <scribe> basically not mention A nat. NEW SPEAKER: Right now,
[13:29:33] <scribe> the ice spec is neutral on this. It describes ice plus A nat
[13:29:38] <scribe> plus ice alone, and it basically doesn't say anything about what you
[13:29:42] <scribe> ought to do. NEW SPEAKER: I don't agree with that. NEW SPEAKER:
[13:29:46] <scribe> That's another choice. We can leave ice alone and totally leave
[13:29:50] <scribe> the decision to later, but then it looks stupid if you try to
[13:29:53] <scribe> deprecate A nat for ice two minutes after
[13:29:56] <scribe> you pushl published the ice spec (Several people talking.) NEW SPEAKER:
[13:30:00] <scribe> If we make the decision not to, then it's real easy and the
[13:30:03] <scribe> spec stands alone. But if we have consensus to
[13:30:06] <scribe> do that, then I think it makes more sense to remove that
[13:30:08] <scribe> text. NEW SPEAKER: Regarding the decision, woy like to
[13:30:12] <scribe> make it now. Because that's just one extra piece of
[13:30:17] <scribe> information, in the SIPPING v6 document is going to be last call
[13:30:20] <scribe> shortly actually. So I would really like to nail everything
[13:30:23] <scribe> down today and go forward with both documents. NEW SPEAKER: So
[13:30:28] <scribe> I mean, we're already here. So, why am I suggesting ice?
[13:30:34] <scribe> My she re and the ice these re is transport address selection is
[13:30:44] <scribe> always better than dine klee than stat klee die ma'am MCI klee.
[13:30:45] <scribe> Than stat klee.
[13:30:54] <scribe> Besides increasing complexity. It is a super set and it
[13:30:59] <scribe> always work better than A nat will. So remove the section on
[13:31:03] <scribe> A nat interaction. You don't need to add anything else.
[13:31:06] <scribe> Maybe I'll put like two words when it says should use server
[13:31:09] <scribe> reflexive. One case you should dash (Several people talking.) NEW SPEAKER:
[13:31:13] <scribe> It does say must. NEW SPEAKER: Okay. I have to fix
[13:31:15] <scribe> that. That would be the change required. I could have
[13:31:19] <scribe> sworn it was a should. NEW SPEAKER: Should re lay
[13:31:21] <scribe> mustache dash NEW SPEAKER: It would be change to should
[13:31:28] <scribe> should I take that back. And then document the more full
[13:31:30] <scribe> discussion on V four, v6 transition.
[13:31:36] <scribe> So again, I'm with Gonzalo, and I'd like to make a
[13:31:40] <scribe> decision. What does the group think? NEW SPEAKER:
[13:31:44] <scribe> Somebody from nor tell again. I was looking at this, and we
[13:31:49] <csp> audet
[13:31:50] <scribe> probably need the A nat thing for transition and backward
[13:31:52] <scribe> compatibility and then I started thinking about me trying to
[13:31:56] <scribe> explain to people at work how this works and I thought, no,
[13:31:59] <scribe> this is a bad plan. So, I think I support what
[13:32:06] <scribe> you're proposing here. I think it makes sense. And I'm not not
[13:32:11] <scribe> sure that ice ob so let's A nat, I think it's just we're
[13:32:14] <scribe> duplicating A nat and I'm not sure that needs to be done in ice.
[13:32:18] <scribe> But the end rilts needs to be done, and I don't really care how we
[13:32:22] <scribe> do it. But I think I would support this.
[13:32:26] <scribe> You may need -- NEW SPEAKER: My main suggestions why it's a
[13:32:30] <scribe> procedural issue, if you have ice deprecate as a formal RFC
[13:32:34] <scribe> editor function, deprecate A nat, when somebody retrieves
[13:32:37] <scribe> the A nat spec, they'll see it's been obsolete ted by ice.
[13:32:42] <scribe> That's the main benefit of doing it here. To help point
[13:32:46] <scribe> people here -- NEW SPEAKER: Doesn't the transition
[13:32:49] <scribe> document do that. NEW SPEAKER: That's not a normative
[13:32:51] <scribe> specification. NEW SPEAKER: All right. So that's,
[13:32:53] <scribe> I'm fine with that. One thing you might want to be
[13:32:58] <scribe> careful, I seem to remember somewhere in the ice document or it might
[13:33:01] <scribe> be have been in the stun document. I think it's in the ice
[13:33:05] <scribe> document. There's something that explains in there, in some
[13:33:09] <scribe> sort of section that's like how are we going to get out of this mess
[13:33:11] <scribe> eventually, blah, blah, blah. And I think there's some
[13:33:18] <scribe> wording somewhere about when everybody moves to IP v6, we don't
[13:33:23] <scribe> need this because there's no nat? NEW SPEAKER: I never
[13:33:25] <scribe> wrote that, did I write something NEW SPEAKER: (Several people
[13:33:25] <scribe> talking.)
[13:33:29] <scribe> NEW SPEAKER: Well, I mean shing you kind of have to say
[13:33:31] --- kafka-j31415927 has joined
[13:33:33] <scribe> that to be able to say anything about nat anyway. But if it's
[13:33:35] --- kafka-j31415927 has left: Logged out
[13:33:37] <scribe> still there, let's make sure it doesn't say that. To me,
[13:33:40] <scribe> what that means is, it's essentially saying, regardless
[13:33:44] <scribe> if there's a nat or not, you still need to do this to support
[13:33:47] <scribe> ice. NEW SPEAKER: Yes. It's basically making the
[13:33:52] <scribe> statement, regardless of nat, the MMusic solution for
[13:33:55] <scribe> selecting transporting
[13:33:59] <scribe> addresses is a dynamic solution. Even if you don't care
[13:34:04] <scribe> about nat, because of broken path or latency methods,
[13:34:08] <scribe> that's going to be super handy. And we won't talk about fire
[13:34:08] --- kafka-j31415927 has joined
[13:34:11] <scribe> wall traverse Sal. We know ice works. So you know, let's,
[13:34:16] <scribe> okay. NEW SPEAKER: So, my last point is, somewhere
[13:34:22] <scribe> it has to say that the mandatory mechanism to support IP V
[13:34:29] <scribe> four, v6 transition is ice. NEW SPEAKER: That's (Several people
[13:34:31] <scribe> talking.) NEW SPEAKER: Yes. NEW SPEAKER: That's
[13:34:35] <scribe> what I meant by that. That's why the transition document is
[13:34:38] <scribe> blocking this. It would be the one that formally says that. NEW SPEAKER:
[13:34:40] <scribe> Okay. So I support this. NEW SPEAKER: Okay. NEW SPEAKER:
[13:34:47] <scribe> Just one quick comment, we are facing our typical ice faith. We
[13:34:52] <scribe> are 5 minutes over time and we
[13:34:56] <scribe> haven't even gone through half the slides, so please make
[13:34:59] <scribe> your point short. NEW SPEAKER: Kevin John's, I'll
[13:35:02] <scribe> try to make this short. Question on
[13:35:06] <scribe> transitioning, I'm pretty much in favor but the concern I have,
[13:35:11] <scribe> if you're expecting ice to do the negotiation and the remote
[13:35:16] <scribe> device does not support ice and it's IP V four only and you're
[13:35:18] <scribe> offering IP v6 address. NEW SPEAKER: You wouldn't do that.
[13:35:22] <scribe> So NEW SPEAKER: So, that leads to my question, does
[13:35:28] <scribe> the transition document always handle that, a non ice end point NEW SPEAKER: NEW SPEAKER:
[13:35:33] <scribe> I think you have to say something similar to what the v6 trans document
[13:35:38] <scribe> says today. Which is if you're a v6 client, you would have
[13:35:42] <scribe> to say must. Implement ice. And it works fine. NEW SPEAKER:
[13:35:47] <scribe> Okay. So I think if we made that clarification of (Several people talking.) NEW SPEAKER:
[13:35:51] <scribe> Right. It's exactly what it says now, it NEW SPEAKER:
[13:35:55] <scribe> Okay. NEW SPEAKER: Because if you have v6 only host that
[13:36:00] <scribe> didn't implement A nat, you'll have the same stupid problem. And
[13:36:04] <scribe> you'll get a rejection and you'll have to try V four and v6,
[13:36:07] <scribe> it's awful. You have to have, once you go to v6 you have to
[13:36:12] <scribe> have that end point implement whatever the transition mechanism
[13:36:14] <scribe> is and that's what the document does today. NEW SPEAKER:
[13:36:16] <scribe> Okay. Thanks. NEW SPEAKER: I believe. I don't
[13:36:20] <scribe> want to, I mean, Gonzalo, you'll correct me. NEW SPEAKER:
[13:36:27] <scribe> Somebody Homer. Maybe I understood, but I I'm not sure
[13:36:32] <scribe> whether we should throw the A nat spec away, because that's what that
[13:36:36] <scribe> means, because you know, it's much, it's easier to implement
[13:36:37] <Jean-Francois> Christer Holmberg
[13:36:39] <scribe> than ice, and I think that mandating ice is going to, you
[13:36:44] <scribe> know, have an effect on transition. I do support the
[13:36:47] <scribe> suggestions to remove the A nat stuff from ice, we can say
[13:36:52] <scribe> that, you know, if you support ice, do only ice and don't
[13:36:54] <scribe> do ice and A nat together. Do only ice. NEW SPEAKER:
[13:36:58] <scribe> Well, that's a bit of inter operability problem. NEW SPEAKER:
[13:37:02] <scribe> In the long run it will be that everybody will have to implement
[13:37:04] <scribe> both. It's even more complex than ice. NEW SPEAKER:
[13:37:08] <scribe> I agree. You have to really pick. You're either going to say it's,
[13:37:12] <scribe> if you're going to go A nat, go to the previous slide. If
[13:37:17] <scribe> you're going to say A natural is V four v6 transition thing
[13:37:21] <scribe> then they do that plus A natural. you have
[13:37:26] <scribe> at na. You have to do that. Okay. NEW SPEAKER:
[13:37:29] <scribe> Right. NEW SPEAKER: I don't know. What you mean by
[13:37:34] <scribe> saying A nat is trans (Several people talking.)
[13:37:40] <scribe> NEW SPEAKER: V6 must implement A nat and that's our official
[13:37:46] <scribe> technique. If I'm a dual stack v6 V four client and I also want to do
[13:37:51] <scribe> ice, because v6 nats and V four nats are still there. You
[13:37:57] <scribe> must do that one. Ice plus a nat. smls you want to do
[13:38:02] <scribe> three re invites to guess whenever you get V four,
[13:38:04] <scribe> v6. See what I'm saying. NEW SPEAKER: Yes. NEW SPEAKER:
[13:38:05] <scribe> I think (Several people talking.)
[13:38:10] <scribe> NEW SPEAKER: I'm scared about this mandate being ice for this purpose
[13:38:10] <scribe> --
[13:38:14] <scribe> NEW SPEAKER: That's the proposal on the table. You're
[13:38:17] <scribe> paying for it with complex see. It's an engineering trade
[13:38:22] <scribe> off. If you think you're going to have nat in v6 long run, you're
[13:38:26] <scribe> going to stick yourself in this really BIS sair case. I'm saying
[13:38:35] <scribe> go with the ice now. That's the choice, that's why I'm asking
[13:38:37] <scribe> the working group to make that decision.
[13:38:49] <scribe> I'm not too sure about ob see leeting the A nat document. But
[13:38:55] <scribe> if we were to do that, what about back wards compatibility
[13:38:57] <scribe> with A nat devices, would there be something -- NEW SPEAKER:
[13:39:04] <scribe> This is a general issue. It is actually, this is my theory
[13:39:09] <scribe> and you tell me if you disagree with it. We had the problem
[13:39:13] <scribe> with 2543. Because what do you do about stuff that doesn't
[13:39:17] <scribe> work anymore. And my bar was, who deployed
[13:39:18] --- sve has joined
[13:39:20] <scribe> it. And people said oh, it's in my lab. Not really
[13:39:24] <scribe> interested. So, you, so the thing, where I think you really have
[13:39:28] <scribe> to take that into consideration, is if they were active
[13:39:30] <scribe> deployments. My knowledge right now shing there's only
[13:39:35] <scribe> specs according to A nat, maybe there's
[13:39:37] <scribe> implementation but no deployments.
[13:39:42] <scribe> So it's a theoretical backwards compatibility problem, not a
[13:39:44] <scribe> real one. NEW SPEAKER: It matters what people are
[13:39:46] <scribe> implementing today. NEW SPEAKER: Right. NEW SPEAKER:
[13:39:48] <scribe> Because customers can demand this. NEW SPEAKER: You
[13:39:54] <scribe> know, in the grand scheme, we may vary on this one. But this is
[13:39:58] <scribe> amongst the backwards compatibility problems we've had where we have
[13:40:05] <scribe> to tell people to change gears. This is not nearly as bad as
[13:40:09] <scribe> the other mess. V6 real large scale deployment, even for
[13:40:13] <scribe> the few people doing it, we know the customers doing it.
[13:40:18] <scribe> And there's not that many at this time. It's an issue but I don't think
[13:40:21] <scribe> it's a big issue. NEW SPEAKER: So I have a slight
[13:40:24] <scribe> concern over using Adam roach. I have a slight concern over use
[13:40:28] <scribe> thing long term. And it's not a backwards xat ability issue.
[13:40:32] <scribe> It's more of a forwards compatibility issue. And you
[13:40:35] <scribe> said, you didn't say it with the last two words, I'm going to
[13:40:40] <scribe> use to say it. That IP v6 implementation be required to
[13:40:44] <scribe> implement ice in perpetuity. Meaning even after we have
[13:40:49] <scribe> retired IP V four addresses and going forward, then things
[13:40:52] <scribe> are going to have to implement dash NEW SPEAKER: Why do that?
[13:40:55] <scribe> If there's no V four left, you can turn off ice. NEW SPEAKER:
[13:40:59] <scribe> So, the way that it is right now, is if I'm talking with
[13:41:00] <scribe> another ice implementation. NEW SPEAKER: Yes. NEW SPEAKER:
[13:41:04] <scribe> Then the draft right now, and I'd have to go back and check the
[13:41:09] <scribe> language, but I'm fairly certain it says you must put your V four
[13:41:13] <scribe> address into the M line. NEW SPEAKER: Right now, I'm
[13:41:17] <scribe> pretty sure it's V four. Put that in the default. NEW SPEAKER:
[13:41:22] <scribe> If we're expecting this to be transition technology, phrase it in
[13:41:30] <scribe> terms of the one that's most likely to work
[13:41:37] <scribe> NEW SPEAKER: So we now have v6 out there and we didn't do A
[13:41:41] <scribe> nat and we use ice, although a much older version of ice to make
[13:41:45] <scribe> it work. But all that being said, I actually prefer the
[13:41:51] <scribe> fork option, SDP cap A nat, xwaws if we do SDP caps and
[13:41:56] <scribe> it's, it does everything we need, why have a second mechanism?
[13:42:01] <scribe> I think that's simpler because people can do SDP caps and not do ice
[13:42:04] <scribe> and it gets V four or v6. NEW SPEAKER: I expect
[13:42:07] <scribe> there's no consensus, but maybe we should take a hum over the
[13:42:12] <scribe> options. I have a fall back in case there's no consensus. NEW SPEAKER:
[13:42:18] <scribe> All right. So I'd like people to hum for what do we want do
[13:42:22] <scribe> do here? NEW SPEAKER: Go through all four of them,
[13:42:28] <scribe> or just in favor of a particular proposal, namely ice alone. NEW SPEAKER: (Several people
[13:42:30] <scribe> talking.) NEW SPEAKER: Only if there is some kind of
[13:42:35] <scribe> opposition. NEW SPEAKER: Okay. Two options,
[13:42:38] <scribe> either ice alone as a transition mechanism or something else.
[13:42:45] <scribe> So who is in favor of ice alone as an IP V four, v6
[13:42:50] <scribe> transition mechanism meaning that A nat will become deprecate
[13:42:52] <scribe> ted at some point. Please hum now.
[13:42:58] <scribe> ( Humming. ) NEW SPEAKER: Okay. Opposed.
[13:43:04] <scribe> ( Humming. ) NEW SPEAKER: Okay.
[13:43:07] <scribe> NEW SPEAKER: It was something in the beginning and it
[13:43:11] <scribe> ramped up. NEW SPEAKER: Did people get louder or get more? NEW SPEAKER:
[13:43:14] <scribe> NEW SPEAKER: More. NEW SPEAKER:
[13:43:18] <scribe> NEW SPEAKER: Try again. NEW SPEAKER: Show of hands.
[13:43:20] <scribe> NEW SPEAKER: Show of hands, yes.
[13:43:26] <scribe> Okay. In favor of ice, no A nat. Raise your
[13:43:36] <scribe> hands now.
[13:43:38] <scribe> NEW SPEAKER: About a dozen. NEW SPEAKER: Okay.
[13:43:47] <scribe> On the other side. 5.
[13:43:52] <scribe> NEW SPEAKER: So, about a dozen for the first and 5 for the
[13:43:54] <scribe> second. NEW SPEAKER: That's kind of rough. NEW SPEAKER:
[13:43:57] <scribe> Yes.
[13:44:00] <scribe> NEW SPEAKER: Why don't you see if there's any agreement on
[13:44:06] <scribe> what the other proposal would be. Because there's only one
[13:44:09] <scribe> and that kills it. NEW SPEAKER: We could do that.
[13:44:14] <scribe> Out of those 5 who raised their hands, so who is for
[13:44:21] <scribe> A nat alone? Nobody. Okay. Who is for ice plus A nat?
[13:44:32] <scribe> That's two. And who is for SDP caps? dwo. And one
[13:44:34] <scribe> person forgot what they were in favor of. NEW SPEAKER:
[13:44:38] <scribe> Sorry. NEW SPEAKER: Maybe something different. And
[13:44:42] <scribe> then that I guess gives us a fairly rough consensus to go with
[13:44:45] <scribe> ice alone. NEW SPEAKER: So I will change the ice spec to
[13:44:50] <scribe> have it obsolete A nat and to remove the A nat considerations
[13:44:53] <scribe> to change the must to should. NEW SPEAKER: Peter
[13:44:56] <scribe> somebody, before we move on, how many people have not thought
[13:44:59] <scribe> about it enough and are nervous?
[13:45:03] <scribe> NEW SPEAKER: Okay. NEW SPEAKER: That's a fair one.
[13:45:05] <scribe> So how many --
[13:45:08] <scribe> NEW SPEAKER: If I can make a comment, because I think that
[13:45:14] <scribe> was a good observation, I mean capability negotiation, is
[13:45:17] <TomTaylor> Flemming
[13:45:17] <scribe> fundamentally two fairly different things. One is about
[13:45:20] <scribe> negotiating what you would like to do. The other one is
[13:45:25] <scribe> about selecting what actually works. And it's not clear to
[13:45:28] <scribe> me what it is that we're suggesting that we want to do here.
[13:45:29] <scribe> Is it one or both?
[13:45:34] <scribe> NEW SPEAKER: I made the statement, I mean, transport address
[13:45:37] <scribe> selection is better done by what works, IP address and port.
[13:45:44] <scribe> And I tried to narrow that, like the ice SDP lost some
[13:45:47] <scribe> stuff. I think that's the narrow focus we have here. NEW SPEAKER:
[13:45:51] <scribe> But it is clearly a selection based algorithm. It is not
[13:45:54] <scribe> really negotiation we run into. NEW SPEAKER: Well,
[13:45:56] <scribe> it's negotiation in that it's a dual prioritization algorithm.
[13:46:00] <scribe> That's the limit of it. It's certainly not a cap
[13:46:04] <scribe> replacement by any stretch. But I mean, you could
[13:46:07] <scribe> prioritize your v6. And remember, when you're the controlling end
[13:46:11] <scribe> point, you basically get to run the selection algorithm.
[13:46:18] <scribe> So you could pick these four, v6, even if the priorities are
[13:46:22] <scribe> muckd up. To the extent that ice does that, that is the
[13:46:26] <scribe> selection, but it's really about con nekt tivt. I'd like
[13:46:31] <scribe> to get the answer. NEW SPEAKER: So, let's phrase
[13:46:36] <scribe> that, let's try to phrase that carefully. Who has so far thought
[13:46:40] <scribe> about the problem at all, but is at this point undecided, because
[13:46:49] <scribe> those who didn't care so far, I'm not interested in get their
[13:46:54] <scribe> opinions. Who cares, has been following this but feels
[13:46:57] <scribe> uncomfortable with making a decision at this point. That's quite
[13:47:03] --- roni_even has left
[13:47:05] <scribe> a few. NEW SPEAKER: The xw a dozen again.
[13:47:09] <scribe> ( About a dozen again. Gonzalo? ) NEW SPEAKER: At the
[13:47:13] <scribe> latest we have to make this decision would be SIPPING session on
[13:47:15] <scribe> Friday, if you want to give people more time to think. But not
[13:47:17] <scribe> later than that.
[13:47:20] <scribe> As the next steps. NEW SPEAKER: SIPPING on Friday
[13:47:24] <scribe> sounds like a deal. NEW SPEAKER: Okay. NEW SPEAKER: All
[13:47:24] --- ericc@jidfe.net has left: Offline
[13:47:28] <scribe> right. So we'll wait for SIPPING on Friday. I'm fine with
[13:47:31] <scribe> that. People want to talk to me in the
[13:47:35] <scribe> hallways about it that are unsure shing we'll do that. NEW SPEAKER:
[13:47:39] <scribe> Please think, you won't get another delay. NEW SPEAKER:
[13:47:42] <scribe> Okay. Next slide. NEW SPEAKER: Okay. So, we'll
[13:47:48] <scribe> get to this with Eckard's slide. Next slide. Ice T C
[13:47:51] <scribe> preponderance. This draft changed a lot. The biggest
[13:47:57] <scribe> things I removed TLS entirely because it was trying to
[13:48:02] <scribe> negotiate whether it succeeds or not. But it finally sunk
[13:48:07] <scribe> in. What does this have to do with it and I think he's correct.
[13:48:11] <scribe> I'd like to totally separate this from the ice piece which is
[13:48:12] <scribe> the transport connection.
[13:48:18] <scribe> So ice TCP requires a full implementation, not light. Because
[13:48:22] <scribe> you're using both active and as if you have multiple
[13:48:23] <scribe> candidates, you need ice full.
[13:48:30] <scribe> If the default is U D P, this doesn't work. This is an open
[13:48:37] <scribe> issue. If default is U D P and TV P candidate is meant as
[13:48:44] <scribe> TLS alternate, include a fingerprint attribute. With the,
[13:48:49] <scribe> if you include the fingerprint attribute and you have U D P or
[13:48:57] <scribe> TCP candidates, if you do TCP and it means TCP TLS.
[13:48:59] <scribe> I think that's exactly what you want.
[13:49:05] <scribe> Another reason to use the same thing, transition so nicely for us.
[13:49:09] <scribe> So, that's what I think we need to do. So this is already
[13:49:11] <scribe> not correct in the document but I'll fix it.
[13:49:18] <scribe> It used to be that you couldn't verify the fingerprint until the
[13:49:20] <csp> ekr
[13:49:21] <scribe> offer changed and now we changed that. NEW SPEAKER: So
[13:49:29] <scribe> you just said, I want to think about it some. But it
[13:49:32] <scribe> sounded like you were saying. If you did a fingerprint,
[13:49:34] <scribe> then that would imply (Several people talking.)
[13:49:37] <scribe> NEW SPEAKER: So the way it works, with ice and cap, the
[13:49:39] --- ericc@jidfe.net has joined
[13:49:42] <scribe> model I have in my mind, cap neing runs first, it's going
[13:49:44] <scribe> to select the actual offer and answer. If that selected
[13:49:49] <scribe> offer and answer has a fingerprint attribute and has both
[13:49:52] <scribe> candidates, then it will be what I just described what happens.
[13:49:56] <scribe> NEW SPEAKER: All right. So we're not assuming
[13:49:58] <scribe> NEW SPEAKER: No. NEW SPEAKER: Crypt tow, between the
[13:50:05] <scribe> candidates? There's, the only candidates have the same
[13:50:09] <scribe> crypto anchors. NEW SPEAKER: If you want do do that,
[13:50:12] <scribe> you have to gosh indicate candidates along with your crypt tow
[13:50:17] <scribe> -- NEW SPEAKER: Right, so, so any given end line has to have
[13:50:20] <scribe> associated with it single associated parameters. NEW SPEAKER:
[13:50:25] <scribe> Yes, for example, if you want to negotiate U D P without security or
[13:50:33] <scribe> T P L S. You basically have to do the cap neing to select it NEW SPEAKER:
[13:50:35] <scribe> Right. NEW SPEAKER: Or you'll (Several people talking.) NEW SPEAKER:
[13:50:42] <scribe> Yes. Okay. Next slide.
[13:50:47] <scribe> It's all details, I posted these on the list. Go on. I'm
[13:50:51] <scribe> not going to review the changes. Keep going. There's a
[13:50:56] <scribe> couple of minor open issues. If simultaneous, this is the big
[13:51:03] --- akiniemi has left
[13:51:04] <scribe> one. If simultaneous open TV P is used with with TLS, who
[13:51:08] <scribe> sends client hello. They have the unfortunate side effect of
[13:51:14] <scribe> coupling the TCP p, it's a simple choice and you have
[13:51:18] <scribe> to pick. You can either define the new, the same thing,
[13:51:24] <scribe> act pass or act tt pass, but just for TLS, or have the
[13:51:28] <scribe> controlling agent always send the client alone, which
[13:51:31] --- sve has left: Logged out
[13:51:32] <scribe> dpusn't work at all. So throw that away. Or basically re
[13:51:36] <scribe> use co-immediate yas and slightly re define the semantics when
[13:51:39] <scribe> present with ice. It's really between one and three. And I
[13:51:43] <scribe> personally don't care too much. This is an open issue,
[13:51:46] <scribe> does anyone have an opinion? Jonathan at all? Flemming?
[13:51:51] <scribe> NEW SPEAKER: sa semantic
[13:51:53] <scribe> clarity above all. Choice one. NEW SPEAKER: All
[13:52:01] <scribe> right. All right. Okay.
[13:52:05] --- ft has joined
[13:52:06] <scribe> NEW SPEAKER: All right. prob blee this just works. I don't know
[13:52:12] <scribe> if I need to say anything about resumption with TLS. Eckard
[13:52:14] <scribe> says I don't, I'll trust him. NEW SPEAKER: You
[13:52:18] <scribe> should. Just to clarify, basically, as long as you're
[13:52:24] <scribe> matching, as long as the same guy is the client server, it works.
[13:52:26] <scribe> NEW SPEAKER: That's it. NEW SPEAKER: All right.
[13:52:29] <scribe> So the only, any other comments on ice TCP. NEW SPEAKER:
[13:52:33] <scribe> I briefly asked you this on Sunday night. Does this mean
[13:52:37] <Jean-Francois> phil matthews
[13:52:38] <scribe> now that if we negotiate multiple, if we have multiple TCP
[13:52:42] <scribe> candidates, that we select the candidate first before we do
[13:52:43] <scribe> --
[13:52:45] <scribe> (Several people talking.) NEW SPEAKER: I forgot to raise this. This is
[13:52:48] <scribe> a big issue. Right now, if you're doing U D P, here is
[13:52:52] <scribe> the sequence, you get the IP address and port. You will do
[13:52:57] <scribe> the stun, and then you would do the D TLS signal. Which has
[13:53:00] <scribe> the benefit that fill was talking about, that you always
[13:53:05] <scribe> select the candidate before you try the T L C P. But the current
[13:53:10] <scribe> ice TCP draft doesn't work that way. It says you're going to
[13:53:16] <scribe> open the TCP connection and then do T C L S and then do stun.
[13:53:18] <scribe> I think that's incorrect.
[13:53:24] <scribe> Instead, you open the TCP connection and run stun and run TLS.
[13:53:27] --- leifj has joined
[13:53:29] <scribe> I think that's more consistent of viewing the role of stun to see
[13:53:33] <scribe> which connection it is. And then revert to whatever the TLS
[13:53:36] <scribe> tells you to do. NEW SPEAKER: So my question is keep a
[13:53:43] <scribe> lives, so we'll ask it together. Do they run outside or inside?
[13:53:48] <scribe> NEW SPEAKER: Damn you.
[13:53:49] --- leifj has left
[13:53:50] <scribe> NEW SPEAKER: Some ways, I want them out.
[13:53:53] <scribe> Sometimes I would like them in. I don't
[13:53:54] <scribe> think I don't know what the right answer is.
[13:54:02] <scribe> NEW SPEAKER: One answer that, for a TCP streams you're not
[13:54:08] <scribe> using the stun keep a lives. Maybe that's an option. NEW SPEAKER:
[13:54:12] <scribe> We're already doing something slightly different for the keep
[13:54:14] --- mlepinski has left: Lost connection
[13:54:19] <scribe> a lives. It's already not symmetric.
[13:54:21] <scribe> NEW SPEAKER: Open issue. NEW SPEAKER: Open issue.
[13:54:23] <scribe> We're here to discuss open issues. (Several people
[13:54:23] <scribe> talking.)
[13:54:30] <scribe> NEW SPEAKER: This one is not in the same track, as ready
[13:54:32] <scribe> for working group last call. NEW SPEAKER: So you
[13:54:35] <Jean-Francois> ekr
[13:54:38] <scribe> can, at the moment you can distinguish TCP data records from stun
[13:54:46] <scribe> data. So, you could potentially mux TLS or parallel to
[13:54:47] <scribe> TLS.
[13:54:52] <scribe> NEW SPEAKER: It's a framing problem on TCP. I don't see how
[13:54:56] <scribe> you're going to do that. NEW SPEAKER: It's not
[13:54:58] <scribe> framing. NEW SPEAKER: But if you shing NEW SPEAKER:
[13:55:03] <scribe> Maybe don't decide at the Mike. (Several people
[13:55:03] <scribe> talking.)
[13:55:07] <scribe> NEW SPEAKER: Go ahead. The flip side is, you have to think
[13:55:12] <scribe> about how your application behaves. I mean, I hate to talk too much
[13:55:16] <scribe> about programming, right, but from the perspective of the
[13:55:20] <scribe> application, you'd like to treat the TLS channel as much as
[13:55:26] <scribe> possible like a TCP channel. And how to post a Dee mux
[13:55:30] --- mlepinski has joined
[13:55:33] <scribe> layer, between the TLS and the other layer. That's
[13:55:38] <scribe> architecture of the TLS staff, even the architecture, you
[13:55:40] <scribe> have to put a shin (Several people talking.) NEW SPEAKER:
[13:55:45] <scribe> I think that's why I had it this way to begin with you. I
[13:55:49] <scribe> just assume I get a TLS connection and once that up, then I can
[13:55:54] <scribe> send data. That would encourage what's currently
[13:55:59] <scribe> this in the draft. It may not be symmetric for TCP use. NEW SPEAKER:
[13:56:06] <scribe> I guess, right now, with ice, you could actually run ice
[13:56:09] <scribe> as a protocol above the colonel. Not inside the concern nel.
[13:56:14] <scribe> And if we start doing this other stuff. It koobility do that. NEW SPEAKER:
[13:56:24] <scribe> Sit down. NEW SPEAKER: The keep a live is for TCP.
[13:56:27] <scribe> I guess they are pt really the same --
[13:56:31] <scribe> NEW SPEAKER: No, they're not. That's why an alternate
[13:56:35] <scribe> proposal was to do something different for tpdz. We're going to
[13:56:39] <scribe> have to discuss this more. It's a totally new issue. So
[13:56:40] <scribe> plan of action.
[13:56:44] <scribe> I'd like to issue ice fifteen with list comments
[13:56:48] <scribe> on dash 14 which are all minor. I've incorporated most of
[13:56:52] <scribe> these comments already into my working version
[13:56:57] <scribe> fifteen. I need to incorporate the bug fix for controlling miss
[13:57:01] <scribe> matches as well. I would have been able to incorporate that
[13:57:04] <scribe> had we had a resolution. Had we had a resolution shing I would
[13:57:08] <scribe> have proposed that ice fifteen gets issued this week. But if
[13:57:12] <scribe> it's now only on Friday that we make it to the A nat decision, you
[13:57:16] <scribe> know, because I was going to do it in an evening here. I wanted
[13:57:20] <scribe> to, you know, get a dire punishment laid on it. Because
[13:57:24] <scribe> I'd like to have working group last call, fifteen,
[13:57:29] <scribe> immediately this week, you know, once the block is off of
[13:57:33] <scribe> drafts, go. Because I know my own behavior, and once I go
[13:57:37] <scribe> home and real job comes back, with each passing day, the
[13:57:40] <scribe> probability of delay goes off. So I don't want to have that
[13:57:45] <scribe> happen. So I guess I'll do everything but the A nat
[13:57:49] <scribe> resolution and taking my promise to buy you a bottle of beer or
[13:57:53] <scribe> wine. NEW SPEAKER: Bring Gonzalo swimming. That's your
[13:58:00] <scribe> punishment. NEW SPEAKER: So ice TCP we're not ready
[13:58:04] <scribe> for last call. I'd like to issue last call on fifteen. Is everybody
[13:58:06] <scribe> okay with tla? NEW SPEAKER: Yes. NEW SPEAKER:
[13:58:10] <scribe> One last thing, this is important. Please, ice has had a
[13:58:13] <scribe> tremendous amount of review, nitpick,
[13:58:17] <scribe> rewording, clarification, suggestions, I think it would be
[13:58:20] <scribe> clearer if kind of comments. Technically,
[13:58:24] <scribe> it's had a lot of people looking at it, more than a lot of
[13:58:27] <scribe> other documents. Right now, what we need more than
[13:58:30] <scribe> everything else is this document to be finished. It does not
[13:58:34] <scribe> need another 500 comment review with your view on how it would be
[13:58:37] <scribe> slightly clearer. The kind of comments I
[13:58:41] <scribe> really want are just like what Jonathan sent. Things that
[13:58:43] <scribe> areing wrong that are bugs in the spec. I don't get
[13:58:45] <scribe> enough of those. Those have to be fixed.
[13:58:50] <scribe> And they're good. Okay. So I'm asking, I can't tell
[13:58:53] <scribe> people what to put in the reviews, but I'm strongly
[13:58:56] <scribe> encouraging folks to focus on what's important so we can get
[13:58:59] <scribe> the document out the door. And please don't nitpick it to
[13:59:01] <scribe> debt. NEW SPEAKER: Make sure you do that too. NEW SPEAKER:
[13:59:03] <scribe> Well,
[13:59:08] <scribe> NEW SPEAKER: oo, is that my punish
[13:59:14] <scribe> punishment. You get to give me a nitpick go away card. I
[13:59:17] <scribe> wouldn't say that except this one has been through the wringer so
[13:59:21] <Jean-Francois> (Keith Drage)
[13:59:21] <scribe> much. NEW SPEAKER: Just remind the ice option group,
[13:59:23] <scribe> working group NEW SPEAKER: Right. NEW SPEAKER:
[13:59:26] <scribe> So review the two documents together. NEW SPEAKER: Yes. All right.
[13:59:29] <scribe> Sorry we ran over so much. Folks, thank you.
[13:59:38] <scribe> NEW SPEAKER: Thank you. It is half past six so I hate to say
[13:59:43] --- emcho has left
[13:59:45] <scribe> this, but can you talk quickly.
[13:59:50] <scribe> NEW SPEAKER: Okay. So, first slide. So, it's really
[13:59:54] <scribe> short. In San Diego, we agreed we were going to do ice for
[13:59:58] <scribe> gate waist, if you you have a public IP address, and you
[14:00:00] <scribe> don't want to bother to implement it,
[14:00:04] <scribe> checklists, that kind of stuff, that we do it, a
[14:00:09] <scribe> degenerate mode and talk to basically, you don't have to do
[14:00:12] <scribe> anything, you're always talking to the same IP address.
[14:00:16] <scribe> And the real premise was because, because there hasn't been
[14:00:22] <scribe> enough nitpicking to debt, we're trying inform find a way to
[14:00:26] <scribe> not read it all. And encourage gay way implementation. So
[14:00:28] <scribe> this document is intended to fill that need.
[14:00:33] <scribe> So the overall strategy here is to basically, there's a two or
[14:00:38] <scribe> three page introduction providing the overall, overview of
[14:00:41] <scribe> how ice light works with latter diagrams and you can read that
[14:00:45] <scribe> and figure out how things are going to happen, and it
[14:00:49] <scribe> explains the design. And then basically, it says, here are
[14:00:52] <scribe> the ten things you have to dochlt and for each thing you have
[14:00:58] <scribe> to do, it provides an overview of what you're expected do in
[14:01:02] <scribe> ice light. And reference to specific ice sections and
[14:01:03] <scribe> paragraphs it tells you what you have to do.
[14:01:09] <scribe> At least theoretically, if you read that and you read like the
[14:01:12] --- admin has left
[14:01:13] <scribe> first two sections of ice, and then you read the specific ice
[14:01:17] <scribe> sections that are referenced by the document, then you can do
[14:01:20] <scribe> ice light implementation without having to read the whole rest
[14:01:25] <scribe> of ice. So, but, of course, the document does not
[14:01:28] <scribe> stand alone, you have to have a copy of ice next to you for
[14:01:29] <scribe> the implementation.
[14:01:37] <scribe> So, the, there are, comments on the list
[14:01:41] <scribe> and two open issues. The first is, should we provide complete
[14:01:44] <scribe> descriptions of the features so that you don't have to read ice at
[14:01:47] <scribe> all. That is, you I mean, that we cut and paste as much
[14:01:51] <scribe> as we need it in and whatever, you don't have to read it all.
[14:01:53] <scribe> That's the first question. And second question is, where
[14:01:58] <scribe> should the normative text that describes ice light be. There
[14:02:02] <scribe> are two choices. Right now, it's -- right now, it's spread between ice,
[14:02:07] <scribe> this document and ice. And so, there are obviously two
[14:02:08] <scribe> choices.
[14:02:14] <scribe> One is ice light, and only references to ice. You know,
[14:02:18] <scribe> most lower case everything and the other is to move some of the
[14:02:23] <scribe> stuff in from ice into ice light. So it would be normative
[14:02:27] <scribe> behavior in this. I don't want to have these things in two
[14:02:30] <scribe> places because that means keeping these things in sink
[14:02:35] <scribe> is difficult, and I worry about touching up and in the final
[14:02:40] <scribe> process. So I have the strong opinion that the issues, I
[14:02:44] <scribe> need to get a sense of the working group. So I know -- you
[14:02:49] <scribe> keep asking IP R, if there's any IP R in here shing this is
[14:02:52] <scribe> hopeless, because we're supposed to complete this stuff.
[14:02:55] <scribe> Comments on how things --
[14:03:01] <scribe> NEW SPEAKER: Well, just, to me it looks like kind of the first thing should
[14:03:06] <scribe> be reference, rather than replicated. And the second thing should
[14:03:14] <scribe> be just leave Jonathan alone. That's the personal opinion. NEW SPEAKER:
[14:03:18] <scribe> Francois. I don't think it's a problem to, I don't think it should
[14:03:21] <scribe> be a goal to have the document completely stands alone. I don't
[14:03:29] <scribe> think the shing the fact that ice is complicated is okay.
[14:03:33] <scribe> The point, I don't think it's a problem for us to have the
[14:03:38] <scribe> ice document. As long as he does and need e to understand every single
[14:03:42] <scribe> thing that's in there. That's a main issue, and have to implement it.
[14:03:46] <scribe> But I think the approach of the second one you said, which is
[14:03:50] <scribe> just to put some receive enses to ice when we references
[14:03:56] <scribe> to ice when we need it and explain this is a simple mode of
[14:03:59] <scribe> that, and this is what you need to do in an environment,
[14:04:02] <scribe> like a Gateway or media server or whatever. I think that should
[14:04:05] <scribe> be sufficient.
[14:04:09] <scribe> And for the other one shing I'm not sure I understand it. NEW SPEAKER:
[14:04:13] <scribe> There's stuff that says, if you're ice light
[14:04:17] <scribe> implementation, you must do check, you must do, must create
[14:04:21] <scribe> a checklist, not a checklist but candidate in the following
[14:04:22] --- ben has joined
[14:04:25] <scribe> way. And right now, that stuff is sort of spread between ice and
[14:04:28] <scribe> ice light. And Jonathan has paragraphs in there that is says this
[14:04:33] <scribe> is how you must do it. So I sort of I am Tate ted those so I
[14:04:38] <scribe> was clear in the text. So they probably shouldn't say must
[14:04:39] <scribe> implementations. One should
[14:04:45] <scribe> say must in capital letters and quun should say must in lower case
[14:04:50] <scribe> letters and say go see him. NEW SPEAKER:
[14:04:53] <scribe> On xakly how you split it, I think that should be something that
[14:04:57] <scribe> you and Jonathan decide. I don't think that, I think for us to
[14:05:01] <scribe> make, oh, I think it should be that way when we don't really
[14:05:06] <scribe> know would be stupid.
[14:05:10] <scribe> NEW SPEAKER: Philip Mathews. I think that you should not
[14:05:13] <scribe> work on ice light until Jonathan finishes ice. And then I think that
[14:05:17] <scribe> the ice light document should actually take the text from
[14:05:21] <scribe> there and copy it in so there's no the dependencies. But then
[14:05:25] <scribe> this document should simply be an informative reference, which
[14:05:30] <scribe> tells people who don't want to read the ice spec what do do.
[14:05:34] <scribe> That's my opinion and this is just my opinion, if you point
[14:05:38] <scribe> people at the ice spec, they'll feel obligated to read the
[14:05:41] <scribe> stuff you're not pointing out and therefore comprehend or try to weighed
[14:05:45] <scribe> through most of them. NEW SPEAKER: But how much of the
[14:05:49] <scribe> explanatory figures that Jonathan has in there would you want
[14:05:53] <scribe> to copy. People have to cross reference anyway. Honestly,
[14:05:58] <scribe> somebody who has implemented SIP, has read such a pile of documents
[14:06:02] <scribe> anyway. So who cares about another hundred pages. NEW SPEAKER:
[14:06:07] <scribe> My reading, I was at the meeting where we talked about this.
[14:06:10] <scribe> My understanding it was supposed to make it easier, that it
[14:06:13] <scribe> was going to be too hard for people to actually go off and read
[14:06:19] <scribe> ice. Now, I think it could be interesting to ask people, you know,
[14:06:22] <scribe> some of these Gateway vendors, s do they really find it hard. Because
[14:06:26] <scribe> if they don't find it hard, there's no point in having this
[14:06:32] <scribe> document at all. NEW SPEAKER: Yes, I guess my
[14:06:36] <Jean-Francois> (Kevin Johns)
[14:06:38] <scribe> concern is that if other bodies are looking at using ice or ice
[14:06:41] <scribe> light, it's good to have one reference and not, you know,
[14:06:45] <scribe> a set of indirect references where I, here's ice light,
[14:06:49] <scribe> it's really a bun of of information and oh, by the way, here
[14:06:52] <scribe> are all the sections that are relevant in ice, the other body
[14:06:55] <scribe> can just provide that information and say, go do ice and here are
[14:06:56] <scribe> the relevant sections.
[14:07:00] <scribe> So I think, from my opinion p, you know, it would be
[14:07:03] <scribe> really nice to have one document that describes the ice light
[14:07:06] <scribe> procedures and the relevant information and whether that's in
[14:07:10] <scribe> ice the way it is now, I mean, there's very clearly pulled
[14:07:13] <scribe> out, here's ice light procedures. Somebody can go in there
[14:07:16] <scribe> knowing that, pull all that information out. You can norm
[14:07:20] <scribe> tivrly reference it and say, go do ice procedures that
[14:07:21] <scribe> apply to ice light
[14:07:25] <scribe> implementations. They know exactly what do get. You can have
[14:07:29] <scribe> another document that provides informative overview if you
[14:07:32] <scribe> want. Otherwise those requirements need to be in that document.
[14:07:37] <scribe> So, either they're in ice or somewhere else but you need one
[14:07:40] <scribe> normative reference for those requirements that are not
[14:07:43] <scribe> duplicate. So I don't know that I have a strong opinion at this
[14:07:48] <scribe> point. I kind of like the idea of a stand alone document.
[14:07:53] <scribe> It's easier to reference and very clear and just simplifies
[14:07:56] <scribe> things for the third parties and
[14:07:58] <scribe> implementers. NEW SPEAKER: Can I ask, not you in
[14:08:01] <scribe> particular, but the room, if you read the document, did you
[14:08:05] <scribe> think it was useful or should I just go home? I thought this
[14:08:08] <scribe> would be useful. But --
[14:08:12] <scribe> NEW SPEAKER: Everybody who read the document, raise your
[14:08:15] <scribe> hand. Did you think it was at all useful, keep your hand
[14:08:19] <scribe> up. Okay. Well, sort of. NEW SPEAKER: Sort of. NEW SPEAKER:
[14:08:22] <scribe> Go ahead. NEW SPEAKER: I guess from my perspective on
[14:08:25] <scribe> that, I was confused. Because I was reading ice and I saw
[14:08:29] <scribe> the ice light requirements in it and then I read ice light and I saw
[14:08:32] <scribe> the same stuff and my first reaction was, quhaes going on
[14:08:36] <scribe> here. This is something that needs to be resolved because I
[14:08:40] <scribe> have dup tiff peoplees of information. NEW SPEAKER: Adam
[14:08:44] <scribe> roach, I think I'm echoing the same sentiment. I
[14:08:48] <scribe> would vote for not having normative language at all in ice
[14:08:52] <scribe> light. Basically, if you want to read ice and learn how to
[14:08:55] <scribe> do ice and ice light in one sitting, that's fine. If you
[14:08:58] <scribe> want to just do ice light, it would be nice to have a nice
[14:09:03] <scribe> thin document X Y Z over here and have ex split sit language
[14:09:07] <scribe> that says don't worry about the rest of it. And I think
[14:09:11] <scribe> people will be smart enough to follow that advice. NEW SPEAKER:
[14:09:15] <scribe> I didn't understand that. NEW SPEAKER: Let me
[14:09:18] <scribe> summarize the position more concisely. I think we want all
[14:09:21] <scribe> normative language in one document and it would be nice to have
[14:09:24] <scribe> the an informative document that points into that
[14:09:29] <scribe> one that says don't worry about anything but section X Y and Z in
[14:09:31] <scribe> here, but without normative language. NEW SPEAKER: That's
[14:09:35] <scribe> sort of what we have now. You're talking about the lower
[14:09:37] <scribe> case stuff, that says must in ice light basically?
[14:09:41] <scribe> NEW SPEAKER: Effectively, yes. NEW SPEAKER: So
[14:09:45] <scribe> it's not a complete description. NEW SPEAKER: John el well.
[14:09:50] <scribe> I would say I was confused. Don't dup indicate normative
[14:09:54] <scribe> statement if we can have bug fixes published for ice and
[14:09:58] <scribe> they're not noticed by somebody implementing ice light, that would
[14:10:02] <scribe> be a disaster. If we really need a separate document, and I'm
[14:10:06] <scribe> not sure we do, just best current practices, that describes
[14:10:10] <scribe> how to do it but they're normative statements. NEW SPEAKER:
[14:10:13] <scribe> I have to say just having to review documents, the
[14:10:17] <scribe> likelihood that somebody will take the ice light document, check
[14:10:19] <scribe> the references to make sure these
[14:10:23] <scribe> references don't contain another chain of references which then
[14:10:28] <scribe> I have to unRalph or ignore and actually reads as a consecutive
[14:10:32] <scribe> read able document, as opposed to random snip pets
[14:10:37] <scribe> that kind of make sense with but nobody is going to read it in
[14:10:39] <scribe> context. So if it's re hoo meant for
[14:10:42] <scribe> implementers, the only way to do it is to have a document
[14:10:46] <scribe> that you can actually read at a single sitting, without going
[14:10:49] <scribe> through that. Otherwise nobody is going to actually do that.
[14:10:51] <scribe> Is it going to be useful for
[14:10:55] <scribe> implementers and hope that a implementer does it or maybe
[14:10:55] <scribe> doesn't use it at all.
[14:10:59] <scribe> If we're trying to serve implementers, with
[14:11:04] <scribe> the copy, when it's done, it's only two document, to update
[14:11:08] <scribe> ice, I'm sure somebody will remember re need to update ice
[14:11:09] --- jakob@kirei.se has joined
[14:11:10] <scribe> light. NEW SPEAKER: Doesn't that imply normative
[14:11:13] <scribe> language has to be in this document. NEW SPEAKER: It should
[14:11:16] --- lminiero has left
[14:11:17] <scribe> be. But if it was cross reference or a term that's not
[14:11:21] <scribe> defined, I'm not going to catch that if it's just snip
[14:11:28] <scribe> pits out there. It's not going to happen without it.
[14:11:33] <scribe> NEW SPEAKER: Keith draiing. I'm going to make a plea for
[14:11:36] --- jakob@kirei.se has left
[14:11:38] <scribe> not duplicating text at all at any level. Inter operability
[14:11:42] <scribe> discussions between two vendors, we want those on the basis of
[14:11:46] <scribe> the main documents, not on the basis of text in the main
[14:11:49] <scribe> document and ice light. That's what you're going to get if you
[14:11:52] <scribe> update a second document being informative. NEW SPEAKER:
[14:11:54] <scribe> So I'm now completely confused. I don't know if
[14:11:57] <scribe> NEW SPEAKER: I'm saying no duplication of text. NEW SPEAKER:
[14:12:03] <scribe> I understood but I think I've heard every possible implementation
[14:12:09] <scribe> of this thing. And it may mean this is not useful at
[14:12:17] <scribe> all and maybe we should say the text is read able enough.
[14:12:21] <scribe> Gateway owners have an edge and somebody said how with do with ice
[14:12:28] <scribe> light. Fine, we'll do it. But is this useless, that's
[14:12:32] <scribe> okay. With me, but I'm trying to get a read out how to
[14:12:34] <scribe> proceed with the document. NEW SPEAKER: So here was my,
[14:12:37] <scribe> a couple of comments. One is just to be
[14:12:39] <scribe> clear, you cannot have a separate normative document that
[14:12:43] <scribe> specifies ice light because there's two reasons. One, if you
[14:12:46] <scribe> look at the spec, there's a lot of normative statements that
[14:12:50] <scribe> actually cover both ice and ice light. You would have to
[14:12:55] <scribe> repeat that, have a stand alone normative ice spec, you would
[14:12:59] <scribe> have to repeat all that. Or a fairly complicated pointer system
[14:13:02] <scribe> that points into ice light. I worked hard to do
[14:13:05] <scribe> that. So that there was just, you know, big, here's the
[14:13:09] <scribe> common stuff, here's the stuff that's specific to ice full,
[14:13:12] <scribe> and it's usually more than the common stuff. NEW SPEAKER:
[14:13:15] <scribe> We can fix that.
[14:13:16] <scribe> ( Laughter. ) NEW SPEAKER: You'll send
[14:13:21] <scribe> comments with suggestions. And furthermore, a full
[14:13:24] <scribe> implementation also has to recognize a bunch of things that ice
[14:13:25] --- Jabber-Wile has left: Replaced by new connection
[14:13:28] <scribe> light does, because you negotiate it. I mean, so a full
[14:13:30] <scribe> implementation of the spec would have to describe the ice light
[14:13:35] <scribe> parameter, describe the control controlling, it's mostly
[14:13:38] <scribe> going to be there anyway. So I had not envisioned you would
[14:13:42] <scribe> have have a stand alone document for ice light. It makes no
[14:13:44] <scribe> sense. NEW SPEAKER: I didn't either. NEW SPEAKER:
[14:13:48] <scribe> So what I thought this document would be useful for, was as
[14:13:53] <scribe> almost a tutorial document that says it's entirely informative.
[14:13:57] <scribe> It is stand alone. It is not complete in that it's a
[14:14:01] <scribe> tutorial document and just gives you the flavor. Enough of a
[14:14:04] <scribe> flavor where you get the basic idea so when you actually go to
[14:14:06] <scribe> code it, well that you can give an estimate to your product
[14:14:12] <scribe> manager that it may not take a ga sill yon years and when you go
[14:14:14] <scribe> to code it you read the spec.
[14:14:18] <scribe> So therefore, you can have references that says, okay.
[14:14:21] <scribe> And the first thing you're going to do is allocate a IP address
[14:14:24] <scribe> from the host and put that in a candidate line and candidate
[14:14:28] <scribe> line has an IP address and port and has these couple of other
[14:14:32] <scribe> things, has this thing called foundation and you don't need to worry
[14:14:35] <scribe> about it too much. For more details see section blah, blah,
[14:14:41] <scribe> blah. It it's a stand alone document that has receive ens e
[14:14:45] <scribe> into ice references to understand ice light. Whatever it is,
[14:14:49] <scribe> it ought to be stand alone ice light document.
[14:14:55] <scribe> It's prirm re function was to give enough of a tutorial to
[14:14:58] <scribe> people who have to implement it, to make them say, oh, you know
[14:15:03] <scribe> wa, I read this thing and it doesn't look like as much as I thought it was. And
[14:15:07] <scribe> then, that's, it's objective. To help people get over that
[14:15:11] <scribe> hump. That was my personal perspective.
[14:15:15] <scribe> NEW SPEAKER: May I make a suggestion, Philip Mathews here
[14:15:19] <scribe> again. Maybe the first question to ask is, is such a
[14:15:21] <scribe> document, anything like this, useful to people? You
[14:15:25] <scribe> know, or should we just forget the whole idea of doing the
[14:15:28] <scribe> document and stick with the ice full. NEW SPEAKER: You will have
[14:15:33] <scribe> to stick with the ice spec in any case. And so I guess we
[14:15:37] <scribe> concentrate on that one, and we can rant about the second
[14:15:41] <scribe> document, its nature, its structure be its amount of
[14:15:45] <scribe> text, and copying or not copying over the next couple of weeks.
[14:15:49] <scribe> And nobody is going to worry about this. We got an
[14:15:52] <scribe> impression and different opinions and the most sensible thing
[14:15:58] <scribe> seems at this point, work on the ice and carry on the ice
[14:16:01] <scribe> light to get that to some conclusion, on the list. Because
[14:16:05] <scribe> we have something like 30 minutes left and we really need to
[14:16:08] <scribe> get through the capability stuff. And that is what we should
[14:16:08] <scribe> do now.
[14:16:24] <scribe> NEW SPEAKER: Flemming.
[14:16:27] <scribe> NEW SPEAKER: Okay. SDP capability negotiation, we have
[14:16:31] <scribe> two documents here, capability negotiation requirements document
[14:16:33] <scribe> and an actual solution document.
[14:16:39] <scribe> The IP R statement is the same one that you saw the last time,
[14:16:42] <scribe> basically saying, royalty free, as long as you're willing
[14:16:47] <scribe> to do the same if you have any IP R on this one. You can take
[14:16:49] <scribe> a close look at the statement if you want.
[14:16:54] <scribe> What did we do since the last IETF. Well, we had a design team
[14:16:56] <scribe> formed with the following
[14:17:00] <scribe> participants.
[14:17:02] <scribe> ( Reading from the slide.)
[14:17:07] <scribe> We got some inpult from other people's here had this room as well.
[14:17:12] <scribe> And what the team basically did, started having weekly conference
[14:17:16] <scribe> calls going from December to February. And started out using
[14:17:20] <scribe> the draft from the last meeting as a starting point. That
[14:17:23] <scribe> document had both requirements and a proposed
[14:17:27] <scribe> solution in it and we split that in two the pretty quickly.
[14:17:30] <scribe> So we had a requirements document and a solutions document.
[14:17:36] <scribe> Requirements document version 01, that is what we focused on in
[14:17:39] <scribe> the beginning, basically discussing the various requirements in
[14:17:43] <scribe> there. We had two the main guiding principles for what we
[14:17:48] <scribe> wanted to do. We wanted a general purpose capability
[14:17:50] <scribe> negotiation mechanism developed. At the same time we're
[14:17:54] <scribe> trying to make sure we didn't have too many requirements in the
[14:18:00] <scribe> basic capability negotiation protocol, best effort SDP folks, you know, try
[14:18:04] <scribe> to impose as few requirements on them as possible while at the same
[14:18:07] <scribe> time having a fairly general solution that we could extend to other
[14:18:08] <scribe> areas as well.
[14:18:12] <scribe> So as a result of that, we ended up dividing the requirements
[14:18:15] <scribe> into two different types, what we consider core requirements which
[14:18:19] <scribe> is what everybody has to input and support. And extensions which
[14:18:22] <scribe> are optional to support.
[14:18:25] <scribe> Part of what we did as a result of this, the original
[14:18:32] <scribe> proposals end requirements you could negotiate
[14:18:34] <scribe> different codecs, et cetera. And we moved that
[14:18:37] <scribe> into a separate document and we marked the requirements for
[14:18:42] <scribe> those as extension requirements. So, we had two solution
[14:18:47] <scribe> documents as I mentioned before, capability negotiation core
[14:18:50] <scribe> document O 5. That's the document I'm going to be talking
[14:18:54] <scribe> about here and media capabilities negotiation which Ronnie is
[14:18:55] <scribe> going to be talking about.
[14:19:00] <scribe> So the core document is real quick, what does it provide?
[14:19:06] <scribe> It provides a couple of capabilities for essentially expressing
[14:19:08] <scribe> attributes as capabilities and transport
[14:19:12] <scribe> protocols as capabilities. Then it defines extensions that
[14:19:15] <scribe> allows you to use those capabilities in a negotiation context.
[14:19:20] <scribe> There's a potential configuration at trib brute that you can
[14:19:23] <scribe> provide. It basically lists which one of these capabilities
[14:19:26] <scribe> that I have defined are going to be used in a particular
[14:19:29] <scribe> potential configuration. The answer then looks at those and
[14:19:33] <scribe> says, okay, I'm going to try and use one of these potential
[14:19:34] <scribe> con fig raises.
[14:19:37] <scribe> And if you can select one of them, that is what will now be
[14:19:42] <scribe> used for the particular media session that's being negotiated.
[14:19:45] <scribe> If you can't use any of these or you don't support the
[14:19:48] <scribe> framework, then you're going to be defaulting back to the
[14:19:52] <scribe> actual configuration, which is what is contained this the M
[14:19:56] <scribe> equals line and any associated the attributes as normal SDP.
[14:20:00] <scribe> Finally, we have a concept of option tags where you can
[14:20:05] <scribe> essentially define the extensions to the framework and you can say I require support
[14:20:07] --- ericc@jidfe.net has left
[14:20:09] <scribe> for the particular option or an extension or I just support
[14:20:16] <scribe> some of these extensions. Open issues in the core,
[14:20:19] <scribe> so, we had a lot of discussion on the design team. We had
[14:20:25] <scribe> various iterations of the document issued and made some good progress I
[14:20:28] <scribe> think. At the time when we basically made the slides here
[14:20:31] <scribe> and had the solution document issued as well, there weren't
[14:20:35] <scribe> really any known open issues in the document. There was one
[14:20:40] <scribe> thing that was added fairly late, which is probably worth talking a
[14:20:45] <scribe> little bit about, and that has to do with add cases, and
[14:20:50] <scribe> another one Jonathan brought up on the list is the
[14:20:54] <scribe> inconsistency where you have selection level attributes and you have
[14:20:58] <scribe> to select them from the media level. And we'll talk a little
[14:21:00] <scribe> bit about those.
[14:21:06] --- philip_matthews has joined
[14:21:08] <scribe> Just background information here to understand the attribute
[14:21:12] <scribe> issue. The conceptual model that we have inside the
[14:21:16] <scribe> capability negotiation framework is essentially, like I said
[14:21:19] <scribe> before, we have a bunch of attributes, those are the T cap
[14:21:23] <scribe> and A caps that you see in the actual configuration on the left.
[14:21:28] <scribe> And what you then do is you have a potential configuration attribute that
[14:21:31] <scribe> references those capabilities. You form a conceptual
[14:21:35] <scribe> potential configuration SDP, if you will. That is made up of
[14:21:39] <scribe> the attribute capabilities and transport protocol capabilities that are
[14:21:43] <scribe> referenced in that configuration. And you add those to the ridge snal
[14:21:51] <scribe> SDP original sdpd. But what you can essentially see
[14:21:56] <scribe> happening here is, we started out saying, R T P A D P to
[14:22:00] <scribe> the M equals lines and we had a potential configuration which
[14:22:05] <scribe> uses S A P profile. Oh so that now gets
[14:22:09] <scribe> put in the M equals line and we have an attribute capability one shing which
[14:22:15] <scribe> is the crypto attribute and that's atop level, if you will,
[14:22:18] <scribe> crypto the attribute inside that media description.
[14:22:24] <scribe> So we replace inside the media, M equals line and add
[14:22:27] <scribe> attributes to the original SDP. And you then use that
[14:22:31] <scribe> potential configuration SDP as your potential offer.
[14:22:36] <scribe> Now, this is all we had said originally, noted that, you
[14:22:40] <scribe> know, well, there could be some potential inconsistency issues with just
[14:22:44] <scribe> doing that. And originally we thought that was probably ki.
[14:22:48] <scribe> You can rely on implementation to do something sane. But as
[14:22:54] <scribe> we looked and thought more about it, we essentially klundd that is
[14:23:01] <scribe> probably not okay. There is a variety of problems. You
[14:23:06] <scribe> can get attributes that re define an existing value. For
[14:23:11] <scribe> example. We could have you know, atop level R T P map that
[14:23:19] <scribe> uses pay load R T six and inside you could reference another
[14:23:22] <scribe> attribute capability that maps to something different. Well,
[14:23:26] <scribe> we if we add the new attributes. We all of a stud have two R
[14:23:30] <scribe> T P maps for the same table map. Which one do you pick?
[14:23:36] <scribe> You can also have at trub buts in a potential configuration that
[14:23:42] <scribe> contradict some that are already there. Maybe this is not a
[14:23:46] <scribe> practical example, but I'm sure you see the issue, what do
[14:23:49] <scribe> we do if we have send only and send receive. NEW SPEAKER:
[14:23:52] <scribe> Why don't you prohibit these cases and basically say, if you
[14:23:56] <scribe> wanted to offer a stream, you have to set it up so that these
[14:23:59] <scribe> things are absent from the base line and then you pick which
[14:24:03] <scribe> ones you want in the potential configuration?
[14:24:07] <scribe> NEW SPEAKER: Say that again. NEW SPEAKER:
[14:24:10] <scribe> Basically, they must work -- NEW SPEAKER: Talk into the
[14:24:13] <scribe> Mike, please. NEW SPEAKER: You need to put a certain
[14:24:17] <scribe> level of attributes into the base line, otherwise you are not
[14:24:20] <scribe> backwards compatibe. We need to specify those. NEW SPEAKER:
[14:24:23] <scribe> So the question is, if you look at the direction one, so
[14:24:26] <scribe> the direction, the default value is send, receive, right? NEW SPEAKER:
[14:24:30] <scribe> Right. NEW SPEAKER: So one constraint is, the base
[14:24:35] <scribe> line can only contain default values for these things. I
[14:24:39] <scribe> mean, I'm suggesting it's an alternative. I'm worried
[14:24:43] <scribe> about the complexity of this thing and the ad lead thing, I
[14:24:46] <scribe> don't understand it. There's a global delete and individual
[14:24:50] <scribe> delete. And I mean, right? NEW SPEAKER: Yes.
[14:24:54] <scribe> So, we're jumping into describing the solutions. But to
[14:24:58] <scribe> answer your specific question, the basic issue is yeshtion you
[14:25:03] <scribe> can review this with attributes. What about attributes you
[14:25:07] <scribe> don't now. how don't know. How is this going to
[14:25:11] <scribe> address those? For every single attribute I'm going to have
[14:25:14] <scribe> to define how to deal with it. It's not general (Several people
[14:25:14] <scribe> talking.)
[14:25:17] <scribe> NEW SPEAKER: I'm not saying that at all. If you
[14:25:21] <scribe> introduce the constraint, that the only thing you can do is add
[14:25:25] <scribe> attributes, right, with the capability and not remove.
[14:25:31] <scribe> Then all, are you really losing any use cases that were a big deal?
[14:25:34] <scribe> And what are they? NEW SPEAKER: I think we are. (Several people talking.) NEW SPEAKER:
[14:25:38] <scribe> I think we're NEW SPEAKER: I'm not sure. Okay. R T
[14:25:44] <scribe> P map size different codec to a different even pay load type, well don't do that. NEW SPEAKER:
[14:25:47] <scribe> These are just examples. NEW SPEAKER: Well, I'm
[14:25:51] <scribe> saying, so what are the use cases?
[14:25:58] <scribe> NEW SPEAKER: One comment, if you actually have different,
[14:26:01] <scribe> depending on what you're trying to do with different
[14:26:04] <scribe> capabilities how do you describe them. NEW SPEAKER: We
[14:26:07] <scribe> need to describe an extension for that. NEW SPEAKER:
[14:26:13] <scribe> My comment is, I mean, I have done something similar for
[14:26:21] <scribe> descriptive things, old thing, if you go look in the --
[14:26:28] <scribe> it's like describing the 3-D P registration draft. And we
[14:26:33] <scribe> describe it in one respect. And yes, that's doing a bit
[14:26:37] <scribe> more ugly half, which is a bit more undefined, which is, if
[14:26:43] <scribe> the initial, like if it's A F GP and it matches, you over
[14:26:46] <scribe> write it. But it's very undefined on how long you should
[14:26:49] <scribe> actually compare a string. NEW SPEAKER: Yes. NEW SPEAKER:
[14:26:53] <scribe> So it's a bit shaky.
[14:26:57] <scribe> NEW SPEAKER: Okay. Basically, trying to list various
[14:27:02] <scribe> examples here of why is it problematic just to the ad thighs
[14:27:06] <scribe> attributes to the SDP that we start out with. And you know,
[14:27:11] <scribe> my basic con tenk here is that we really don't want the SDP
[14:27:14] <scribe> capability negotiation to try and sort out what happens when you
[14:27:17] <scribe> actually add attributes and as a result of that you have
[14:27:21] <scribe> something that's actually not meaningful or overlapping or just
[14:27:21] <scribe> contributing or whatever.
[14:27:25] <scribe> And again, you know, extensibility, you know, if you try
[14:27:31] <scribe> to deal with just well known attributes, it's problematic. You
[14:27:34] <scribe> don't want that semantic knowledge here in this negotiation
[14:27:37] <scribe> layer. So this is just trying to illustrate,
[14:27:40] <scribe> essentially, some of the examples that we have before, by
[14:27:43] <scribe> actually showing you what it could look like. So here we have
[14:27:47] <scribe> a session that will key management attribute, where if we end
[14:27:52] <scribe> up actually choosing R T P as the profile, right you, don't
[14:27:55] <scribe> want to have that attribute there.
[14:28:00] <scribe> If we have S R P chosen we have crypt tow as an although tevrn
[14:28:04] <scribe> tiff mechanism to using Mike ee. If you choose to use that as
[14:28:08] <scribe> descriptions, then we're not going to do Mike e. NEW SPEAKER:
[14:28:13] <scribe> Don't do this. The thing I keep coming back to is, in the
[14:28:16] <scribe> universe where everybody supports SDP
[14:28:19] <scribe> capability negotiation, this feature is useful. Because
[14:28:22] <scribe> you would not just include nothing in the default. That
[14:28:25] <scribe> would drive everything off the potential con figs,
[14:28:28] <scribe> right. NEW SPEAKER: That's possible but we're not going to be there any
[14:28:32] <scribe> time soon. NEW SPEAKER: I just want to establish that.
[14:28:36] <scribe> This ability to add and remove attributes is there because we need
[14:28:39] <scribe> to smort fall back end points that
[14:28:42] <scribe> don't do SDP
[14:28:45] <scribe> (Several people talking.) NEW SPEAKER: Why is that? NEW SPEAKER:
[14:28:48] <scribe> Why is that? NEW SPEAKER: Yes. I think tlar
[14:28:51] <scribe> various scenarios, I mean, where you have
[14:28:55] <scribe> existing SDP and whatever you have in that actual
[14:28:57] <scribe> configuration, your contention is, I can put something in
[14:29:00] <scribe> there that is so minimal, and still reflects my
[14:29:04] <scribe> desired outcome that it doesn't contradict with anything else I (Several people
[14:29:07] <scribe> talking.) NEW SPEAKER: Right. I mean, if everybody
[14:29:10] <scribe> does capability negotiation, you take all the potential con
[14:29:14] <scribe> figs that you have and the stuff that shows up outside, as
[14:29:18] <scribe> actual attributes is only the stuff that's common across all
[14:29:21] <scribe> potential configurations, maybe that's nothing, but so
[14:29:24] <scribe> what. NEW SPEAKER: You can argue that, so we don't need
[14:29:26] <scribe> to put any of these at trib (Several people talking.) NEW SPEAKER:
[14:29:30] <scribe> Exactly, right. Yes. NEW SPEAKER: But that would
[14:29:35] <scribe> not be valid SDP per today's SDP. NEW SPEAKER: Okay.
[14:29:38] <scribe> So I'm trying to understand the issue. So one issue is,
[14:29:43] <scribe> backwards compatibility with non SDP capability negotiation end
[14:29:45] <scribe> points. NEW SPEAKER: Right. NEW SPEAKER: And
[14:29:54] <scribe> issue two is sin tackly valid syntactically. It would be valid.
[14:29:59] <scribe> Semantically it would not. So in this particular case,
[14:30:04] <scribe> you just say put SDP in M equals line but not the key
[14:30:08] <scribe> management line. Put that in capability if instead and
[14:30:11] <scribe> just drive everything off the capability framework. But what happens
[14:30:16] <scribe> if that offer reaches somebody that doesn't support capability
[14:30:18] <scribe> negotiation, you wouldn't have any key material. NEW SPEAKER:
[14:30:24] <scribe> So, I mean, a lot of this sounds like the ice
[14:30:27] <scribe> thing. So the alternative is, you know, if you're going
[14:30:34] <scribe> to start to do this crypt stow crypt tow stuff. Then you're
[14:30:38] <scribe> supporting
[14:30:39] <scribe> (Several people talking.) NEW SPEAKER: Sure 6789 NEW SPEAKER:
[14:30:42] <scribe> Backwards compatibility with existing things that need SDP. NEW SPEAKER:
[14:30:45] <scribe> Right. Which is like one of the very first requirements. NEW SPEAKER:
[14:30:47] <scribe> ISDN understand that. NEW SPEAKER: You have to be backwards
[14:30:52] <scribe> compatibe, right? If we could just start with a clean
[14:30:55] <scribe> slate, we could do a lot of things differently. NEW SPEAKER:
[14:30:59] <scribe> Sure.
[14:31:04] <scribe> NEW SPEAKER: All right. Collin pishing kins and I left
[14:31:08] <scribe> my chair hat up there. So so, my
[14:31:09] <scribe> ( Perkins.)
[14:31:14] <scribe> And something that I could develop is the complexity came from, you
[14:31:17] <scribe> know, the complexity of this was the fact that you you had to
[14:31:22] <scribe> be able to somehow represent these potential configurations and do some
[14:31:26] <scribe> sourt of edit to the SDP to introduce them. NEW SPEAKER: Right. NEW SPEAKER:
[14:31:30] <scribe> To my mind, once you've got that level of complexity, the
[14:31:35] <scribe> fact that you're removing some lines, is trivial extra
[14:31:39] <scribe> addition. The complexity is the ability to have the multiple
[14:31:43] <scribe> offers and decide between them. Exactly which sin tactic
[14:31:46] <scribe> modifications you do is not -- NEW SPEAKER: Absolutely
[14:31:50] <scribe> agreed. NEW SPEAKER: So, yes, there is complexity
[14:31:53] <scribe> here, but I don't see that adding the ability to delete
[14:31:57] <scribe> attributes makes it significantly more complex. So once you've
[14:31:58] <scribe> added the ability to add them --
[14:32:02] <scribe> NEW SPEAKER: No, no. Let me disagree with that.
[14:32:05] <scribe> There's, I agree, I think there's some truth to that, but
[14:32:09] <scribe> there's other things too. One is the ability to look at and inspect
[14:32:13] <scribe> SDP and to understand what it says. Quickly evaporates in a
[14:32:15] <Jean-Francois> (Jonathan R)
[14:32:16] <scribe> poov of smoke. NEW SPEAKER: Why is that? Why does
[14:32:21] <scribe> that evaporate? This is a purely sin tactic klee driven --
[14:32:24] <scribe> NEW SPEAKER: I understand that. Now I have to look at all these
[14:32:28] <scribe> deletes to figure out what stays and what goes. I think I it
[14:32:32] <scribe> becomes harder to read an SDP quickly and see what it says when
[14:32:34] <scribe> you've got the delete thing. NEW SPEAKER: As human.
[14:32:36] <scribe> That's true. NEW SPEAKER: (Several people talking.) NEW SPEAKER:
[14:32:39] <scribe> As a machine absolutely not. NEW SPEAKER: I'm talking
[14:32:44] <scribe> about human, I'm talk making a point. This may not be the
[14:32:46] <scribe> most important thing, but it's a thing. All right. I'll
[14:32:48] <scribe> move on to the next one.
[14:32:51] <scribe> The other one is errors, and this is the one I worry about
[14:32:53] <scribe> more. Depending on how you construct these things, because
[14:33:00] <scribe> it may be purely sin tactic to decode, but it's not at
[14:33:03] <scribe> all obvious this is a trivial algorithm to even code.
[14:33:10] <scribe> Especially if you're encoding algorithm is not syntactically
[14:33:10] --- ft has left
[14:33:15] <scribe> driven. If you do it by creating 5 SDPs that are all
[14:33:17] <scribe> potential offers, could you construct this the thing from that?
[14:33:23] <scribe> And the question is, will people who implement this construct their
[14:33:27] <scribe> SDPs like that. And my suspicion is no. Most
[14:33:30] --- amayer has left
[14:33:31] <scribe> people will figure out the one thing they want to negotiate, throw in a
[14:33:33] <scribe> couple of lines for that and that is going to be much more
[14:33:37] <scribe> error prone. NEW SPEAKER: Could be. Let's just run
[14:33:39] <scribe> through, there's three alternative solutions suggestions in
[14:33:42] <scribe> here and let's just run through those quickly. NEW SPEAKER:
[14:33:45] <scribe> Just a quick comment on this. So I didn't think it was,
[14:33:50] <scribe> from an implementer's perspective all that difficult to implement.
[14:33:55] <scribe> What I did find in reading the draft is, it took me quite
[14:33:58] <scribe> awhile to understand it. By the time I got two-thirds the of the
[14:34:02] <scribe> way through, I got it. And I'm now quite able to read
[14:34:05] <scribe> these things and understand what they mean, and I don't think
[14:34:07] <scribe> it would be that hard to make them up. Although I agree with
[14:34:10] <scribe> Jonathan, if you started with 5 SDPs and wanted to
[14:34:14] <scribe> produce one of these, I don't think I'd do that as an
[14:34:17] <scribe> implementer, I'd do it a different way. NEW SPEAKER:
[14:34:22] <scribe> I think also for, Ronnie Evan, I think also for read ability
[14:34:26] <scribe> then, after you finish the negotiation, you have the final SDP which
[14:34:31] <scribe> is regular SDP that you transmitting in the works of, and you can see what
[14:34:34] <scribe> the result was. NEW SPEAKER: True. NEW SPEAKER:
[14:34:42] <scribe> So, basically, I mean, there's a couple of different
[14:34:46] <scribe> ways we can go about doing this, right. We can do what we had done
[14:34:49] <scribe> originally, which was essentially to say shing keep the
[14:34:53] <scribe> existing attributes and I think Jonathan kind of along the
[14:34:57] <scribe> lines of what you suggested, for existing well known
[14:35:00] <scribe> attributes here, specify certain rules to say how do we
[14:35:04] <scribe> actually deal with those. For example, if we had an R T P
[14:35:07] <scribe> map, just specify the order, or whatever, and you can do
[14:35:10] <scribe> something for the well known attributes of course, right.
[14:35:14] <scribe> The stuff we haven't specified shs that's the big question.
[14:35:15] --- philip_matthews has left
[14:35:15] --- admin has joined
[14:35:18] <scribe> What do we do with those? I think, it looks simple, it looks
[14:35:22] <scribe> appealing, because there's not as much text in the spec. I
[14:35:25] <scribe> think in practice, when we go forward, I think the this is the
[14:35:28] <scribe> going to be very, very difficult. I think it's not going to
[14:35:30] <scribe> be inter operable and extensible.
[14:35:36] <scribe> Solutions two, instead says, this was another proposal that we had.
[14:35:40] <scribe> Basically says, okay are forget about all this that we had in
[14:35:44] <scribe> there right now. You can essentially add and delete
[14:35:48] <scribe> individual attributes. And I'm just saying
[14:35:51] <scribe> instead, what we're going to be doing is just starting with a clean
[14:35:55] <scribe> SDP every single time we have one of these potential configuration
[14:36:00] <scribe> SDPs and then we're going to have the configuration and add all
[14:36:04] <scribe> the necessary attributes to it. The semantics are very
[14:36:05] <scribe> clear, easy to understand.
[14:36:10] <scribe> The issue we saw is in terms of message size. You put in
[14:36:14] <scribe> keying parameters, ice attributes, candidates, et cetera, et
[14:36:18] <scribe> cetera. Every single one of those have to be duplicated now as
[14:36:20] <scribe> capabilities in order for you to be able to do that.
[14:36:26] <scribe> So the big concern we had there originally is message size.
[14:36:32] <scribe> Had with looked more since then, it's obvious it's not as
[14:36:37] <scribe> easy to reconstruct the SDP in certain cases. You know shs
[14:36:43] <scribe> Magnus's SDP is a can great example. It's not obvious once
[14:36:46] <scribe> you get into some of the GRUU things that essentially transcend
[14:36:50] <scribe> both the session and media at the same time. Something we
[14:36:53] <scribe> can look more at, but it's certainly something else to look out
[14:36:53] <scribe> for.
[14:36:58] <scribe> And then finally, solution three which is essentially what we have in
[14:37:03] <scribe> there and it's, you know, I think it allows you to do what
[14:37:08] <scribe> we need. We can argue whether we need more fine grain control
[14:37:14] --- Magnus Westerlund has left
[14:37:15] <scribe> than what is in there. Like Magnus's comment like just
[14:37:17] <scribe> attribute name, maybe just a substrate base.
[14:37:23] <scribe> But I'll readily admit, it's not a simple thing the for an
[14:37:27] <scribe> implementer to understand or use. So that's essentially the
[14:37:28] <scribe> three different solutions.
[14:37:35] <scribe> Next slide. So, you know, unsurprisingly, solution
[14:37:39] <scribe> three, given what's in there right now, is what's
[14:37:42] <scribe> recommended, at least by me, and you know, there's additional
[14:37:47] <scribe> considerations here, whether we even want to extend what it
[14:37:49] <scribe> does now and more on that. Any additional
[14:37:57] <scribe> comments on this particular issue? Alternative solutions, preferences
[14:37:58] <scribe> for what we should be doing here?
[14:38:05] <scribe> NEW SPEAKER: So who has read the spec? That's not the
[14:38:16] <scribe> too bad.
[14:38:20] <scribe> NEW SPEAKER: You also comment on the specs,
[14:38:25] <scribe> John el well. Yes, I read the previous version of the
[14:38:29] <scribe> spec, and I was specifically asked if I was happy with that.
[14:38:35] <scribe> And I indicated I was happy with that. And I'm beginning to see
[14:38:37] <scribe> that going to working group last call.
[14:38:43] <scribe> With this extra complexity, in the O 5 version, I'm not so
[14:38:47] <scribe> is sure I would have liked something simpler than that. And
[14:38:49] <scribe> I just have this concern that we're getting --
[14:38:52] <scribe> NEW SPEAKER: Can you specify the extra complexity more
[14:38:54] <scribe> precisely?
[14:38:58] <scribe> NEW SPEAKER: I think Jonathan put his finger on it partly.
[14:39:02] <scribe> The fact that it's, it's difficult to read. It's
[14:39:08] <scribe> difficult, may be difficult to can construct the right SDP.
[14:39:13] <scribe> There's at least one necessary option and I think the sort in
[14:39:16] <scribe> the master lead, versus the individual delete.
[14:39:23] <scribe> I haven't can got a specific solution other than to go back to
[14:39:26] <scribe> the previous version and say, well, if you, there are, it's
[14:39:32] <scribe> limited in terms of you can't cover cases that aren't satisfied
[14:39:35] <scribe> by just adding.
[14:39:40] <scribe> NEW SPEAKER: So so just to be clear, your primary concern
[14:39:47] <scribe> on the current solution document is really just that, or is
[14:39:51] <scribe> this just one of more concerns? NEW SPEAKER: My
[14:39:57] <scribe> concern was to do with the, this addition, the delete and
[14:40:01] <scribe> replace. It seems to be making it a lot more
[14:40:05] <scribe> complex. The existing one, the previous one, I
[14:40:07] <scribe> reluctantly agreed to, to satisfy the requirements, we
[14:40:11] <scribe> probably can't get any simpler than that. And it's more complex
[14:40:17] <scribe> than I wanted to see, because I originally was looking for
[14:40:22] <scribe> something are R S T P. And the group said they wanted a
[14:40:26] <scribe> proper, a more general solution to capabilities negotiation.
[14:40:31] <scribe> So you know, I looked at, and said, I ge that's the simple
[14:40:32] <scribe> as we can get to satisfy that general requirement.
[14:40:38] <scribe> Now we've got something more complex. And I'm concerned about
[14:40:42] <scribe> first of all putting off people, putting people off
[14:40:46] <scribe> implementing it and secondly more chance for implementing
[14:40:49] <scribe> wrongly. NEW SPEAKER: Do you agree though with the
[14:40:51] <scribe> issue as it has been presentd here, if not the
[14:40:54] <scribe> solutions that is taking a problem. Or are you just
[14:40:57] <scribe> saying, this is not even an issue we should worry about. NEW SPEAKER:
[14:41:03] <scribe> I'm not so convinced about the use cases. That's my point
[14:41:08] <scribe> of view. Other people with use cases, and then fine.
[14:41:11] <scribe> But I'm not convinced personally. NEW SPEAKER: Would
[14:41:15] <scribe> it help if we clarify that you can implement this in
[14:41:19] <scribe> essentially the same way as the best effort R S T P and just say you
[14:41:24] <scribe> don't support it if you get this complex, any of the complex features? NEW SPEAKER:
[14:41:28] <scribe> It's quite possible if you get something
[14:41:31] <scribe> which says delete or replace, you just act as if you don't
[14:41:33] <scribe> understand this extension. NEW SPEAKER: I mean, you
[14:41:36] <scribe> don't understand the delete? NEW SPEAKER: If you
[14:41:39] <scribe> can offer which has potential configuration of which delete, then you can
[14:41:42] <scribe> just say, I don't understand any of this capability
[14:41:45] <scribe> negotiations stuff. NEW SPEAKER: You don't understand
[14:41:47] <scribe> the whole --
[14:41:49] <scribe> NEW SPEAKER: Just fall back to not supporting it and just
[14:41:53] <scribe> do a minimal implementation. NEW SPEAKER: Well, I'm
[14:42:01] <scribe> not sure how helpful that would be.
[14:42:10] <scribe> NEW SPEAKER: Three observations. Eric shol. First,
[14:42:17] <scribe> I think it is clear that it is dramatically something read
[14:42:20] <scribe> ability. Probably it's not that important.
[14:42:25] <scribe> I think that in terms of software read ability on the parse
[14:42:32] <scribe> side, the receiving side, it looks complicated but also will something
[14:42:35] <scribe> about I am mre menting. So the only thing that
[14:42:39] <scribe> sounds more complicated on, is how to generate things. On
[14:42:42] <scribe> the other hand, now that I think bit, it seems to me that
[14:42:46] <scribe> all the things I want to express seem relatively straightforward
[14:42:50] <scribe> to express. So the worst case scenario, it seems to me all
[14:42:56] <scribe> you want to express is simple things there is a way. And
[14:43:00] <scribe> more complex things, but that seems like the problem is with
[14:43:03] <scribe> people with complex things. So I'm not going to stress out
[14:43:09] <scribe> about any of this. NEW SPEAKER: Francois. I think I
[14:43:18] <scribe> agree with a lot of people that just talked. If you could show
[14:43:24] <scribe> us a real good reason why it's really useful to have the delete
[14:43:27] <scribe> replace stuff in there, I think that would be useful.
[14:43:31] <scribe> Because the problem is, it's kind of hurting our brains a
[14:43:34] <scribe> little bit too much and we don't really see why we need to hurt
[14:43:37] <scribe> our brains to understand this. So, maybe it's
[14:43:41] <scribe> psychological and it's just difficult, but I'ven't heard
[14:43:44] <scribe> anything that says, this is really useful. So I'll take
[14:43:50] <scribe> the time to explain it to people so e they implement it. So
[14:43:52] <scribe> I think that would be very helpful.
[14:43:54] <scribe> That would be my first comment.
[14:44:01] <scribe> I guess as a general comment, which I don't think has changed
[14:44:05] <scribe> since the last time we looked at this, I I'm a
[14:44:08] <scribe> little bit worried that all the this stuff is a little bit too
[14:44:12] <scribe> late for some of the best effort S R T P. I don't think I
[14:44:17] <scribe> have any proposal for that, though. But I think that there's
[14:44:21] <scribe> lots of implementation out there that are going to stick with
[14:44:24] <scribe> what they have, because it probably has a better chance of inter
[14:44:31] <scribe> operating than this in real life, as opposed to other life.
[14:44:36] <scribe> But, since I don't have anything I can propose on that area, I don't
[14:44:38] <scribe> know what to do.
[14:44:42] <scribe> But anyway, think of a real good use case for this, and I think that would
[14:44:45] <scribe> be useful. Because it seemed kind of theoretical, you know
[14:44:49] <scribe> shing and maybe there's cases where it really works better and
[14:44:53] <scribe> it's more backward compatibe, but it, I'd like to see an
[14:44:53] <scribe> SDP.
[14:44:59] <scribe> One last comment. When you use potential and actual, I
[14:45:02] <scribe> thought it was really confusing. I finally understood it today.
[14:45:06] <scribe> But to me, they mean the opposite of what they are. The
[14:45:10] <scribe> actual, the one you call actual, is the one that, the one
[14:45:16] <scribe> you call potential is the one that you actually use, to
[14:45:20] <scribe> describe the media that will be used. So I find that very
[14:45:28] <scribe> confusing. Something really helped with but I struggle why
[14:45:31] <scribe> you chose those names. NEW SPEAKER: They're actually
[14:45:38] <scribe> well documented. You shuvd should have read that document from years
[14:45:40] <scribe> ago. NEW SPEAKER: Jonathan explaind?
[14:45:43] <scribe> some of that in there. NEW SPEAKER: Yes, that would
[14:45:45] <scribe> be useful.
[14:45:53] <scribe> NEW SPEAKER: Caplan. I definitely think the document
[14:45:56] <scribe> came a long way from version 5. I apologize for not
[14:45:59] <scribe> responding on the list, there was way too much e-mail on this
[14:46:01] --- hbaosiy has left
[14:46:02] <scribe> topic. I really have two comments to make.
[14:46:05] <scribe> One is, I was thinking the same thing the I think Collin, I don't
[14:46:10] <scribe> know who said, but that if you don't want to support the delete type of
[14:46:13] <scribe> thing, well then you just pretend you don't support it if you
[14:46:17] <scribe> received it. And then it occurred to me, that's a really
[14:46:20] <scribe> bad idea. It's basically saying, I kind of support this
[14:46:22] <scribe> standard, but I don't really support this. And really,
[14:46:27] <scribe> the problem is if you send it with the attributes in this
[14:46:30] <scribe> document, you're implying that you do support it and then you
[14:46:33] <scribe> get back something that's too complex, it's even worse.
[14:46:38] <scribe> So really, you have aversion one without delete replace.
[14:46:40] <scribe> And you have it inversion two. So you have the support
[14:46:44] <scribe> inversion concept. Although I think it's optional. NEW SPEAKER:
[14:46:49] <scribe> This is going to create another explosion in terms of things you have
[14:46:52] <scribe> to consider. It's not going to make anything any better. (Several people
[14:46:56] <scribe> talking.) NEW SPEAKER: But you do a version attribute (Several people talking.) NEW SPEAKER:
[14:47:02] <scribe> Then you add another kind of round to figure out --
[14:47:04] <scribe> actually, the (Several people talking.) NEW SPEAKER:
[14:47:05] <scribe> Well, they have it in there. NEW SPEAKER: The point that
[14:47:10] <scribe> was in made before, that parsing is easy, because you have
[14:47:13] <scribe> your attributes in some data structure. You can reference
[14:47:16] <scribe> and replace one by the other. And that's not difficult.
[14:47:19] <scribe> If you don't care about that many complex things to send,
[14:47:23] <scribe> because you are simple implementation, then generating your
[14:47:27] <scribe> offer is not also going to be easy because you don't want to
[14:47:31] <scribe> express complicated things, so that shouldn't be an issue for you. If
[14:47:34] <scribe> receiving something is easy and you don't want to generate complex
[14:47:39] <scribe> things in the first place (Several people talking.)
[14:47:42] <scribe> NEW SPEAKER: You get answer and updated offer and therefore NEW SPEAKER:
[14:47:47] <scribe> Yes, but parsing is fine.
[14:47:50] <scribe> NEW SPEAKER: Parsing is fine. NEW SPEAKER: Yes.
[14:47:53] <scribe> Parsing if you understand it. NEW SPEAKER: No.
[14:47:59] <scribe> Parsing is understanding the issue. Is trivial. If you can understand
[14:48:01] <scribe> adding. NEW SPEAKER: I'm with you with that too.
[14:48:06] <scribe> I'm not sure -- well, ta that whole semantic thing is
[14:48:07] <scribe> complicated.
[14:48:17] <scribe> My other comment is, RF T Cs and I know they're not
[14:48:21] <scribe> recognized. It
[14:48:25] <scribe> caught me by surprise. And I didn't realize it, the answer you
[14:48:29] <scribe> picked has the new transport. So you offer a transport, in other
[14:48:33] <scribe> words, the M line originally had R T. And the answer has R
[14:48:38] <scribe> T PSA D P and there's some S T Ps out there that says,
[14:48:42] <scribe> no, they don't support this new thing and he offered R S T P A
[14:48:47] <scribe> D P. And NEW SPEAKER: That is probably need to be
[14:48:50] <scribe> fixed. NEW SPEAKER: I don't know if they can.
[14:48:55] <scribe> That's the I mean, in the best effort R S T P draft, you
[14:48:58] <scribe> were just saying sh -- remember the whole discussion about
[14:49:03] <scribe> well, the RF C really say you have to do that. And no vrment
[14:49:07] <scribe> you can change the transport in the answer. NEW SPEAKER:
[14:49:13] <scribe> So will they still send an answer back and pass whatever
[14:49:14] <scribe> attributes that are in there? NEW SPEAKER: I don't
[14:49:21] <scribe> know. But the offer went through with them so I assume they
[14:49:24] <scribe> must have passed the offer. NEW SPEAKER: You can
[14:49:27] <scribe> detect the case then because we actually
[14:49:28] <scribe> NEW SPEAKER: Correct. (Several people talking.)
[14:49:32] <scribe> NEW SPEAKER: You know it because you told the actual one this the response.
[14:49:36] <scribe> It's not like it doesn't know. It's just like the M line changed
[14:49:40] <scribe> the transport. I don't know if you're willing to undo that part. NEW SPEAKER:
[14:49:44] <scribe> Yes, I don't think you're undoing anything. You
[14:49:48] <scribe> essentially add another paragraph to say you get the S T Ps out there.
[14:49:51] <scribe> So when you get the answer coming back, even though the
[14:49:55] <scribe> actual configuration says the answer was generated based on one
[14:49:56] <scribe> thing, the answer looks different. NEW SPEAKER: I don't
[14:49:59] <scribe> think you're following me. The answer doesn't come back. (Several people talking.) NEW SPEAKER:
[14:50:07] <scribe> That is a bad thing. NEW SPEAKER: Yes. So are S T
[14:50:10] <scribe> Cs. NEW SPEAKER: That's pretty hard to fix though. NEW SPEAKER:
[14:50:15] <scribe> Agreed. NEW SPEAKER: That's fundamental Dee sign. NEW SPEAKER:
[14:50:18] <scribe> Only because he wants that M line response, the
[14:50:20] <scribe> answer to be the chosen one of the
[14:50:24] <scribe> potentials. Right. Whereas, in ours, we're
[14:50:31] <scribe> saying, well, crypt tow and the D I D P was there the. It
[14:50:36] <scribe> had the crypt tow NEW SPEAKER: So you would want to even code
[14:50:38] <scribe> it in the M equals line. NEW SPEAKER: Yes. NEW SPEAKER:
[14:50:41] <scribe> You want to hide everything. NEW SPEAKER: Pretty
[14:50:42] <scribe> much.
[14:50:42] <scribe> (Several people talking.)
[14:50:53] <scribe> NEW SPEAKER: I have a question, so basically, if the
[14:50:57] <Jean-Francois> (Miguel Garcia)
[14:50:58] <scribe> offer is very fundamentally organization and we're trying to
[14:51:01] <scribe> improve with this. So the way it is now, does it
[14:51:06] <scribe> automatically mean that in the extensions that we move from now
[14:51:12] <scribe> on, we are going to be extensions to the SDP cap, or or do
[14:51:15] <scribe> we need to see like the -- NEW SPEAKER: No, I don't
[14:51:22] <scribe> think they necessarily be extensions to the capability negotiation
[14:51:25] <scribe> framework. I think they would be useful to say how do you use
[14:51:28] <scribe> them. The options tag, that's what you're referring to, that
[14:51:32] <scribe> was not intended to cover every single SDP extensions, only
[14:51:33] --- hejingtong has left
[14:51:36] <scribe> extensions to the capability negotiation framework itself. So for
[14:51:39] <scribe> example, we have the media capability stuff, that would be an
[14:51:42] <scribe> extension with an option tag, if you came out and there were
[14:51:45] <scribe> other attributes, that doesn't have anything to do with
[14:51:50] <scribe> this, that would be part of that. NEW SPEAKER: Right. NEW SPEAKER:
[14:51:54] <scribe> I was going to make a comment on SDP on this. But I really
[14:51:58] <scribe> should say the A Ds should cut the line off, starting with
[14:52:00] <scribe> me.
[14:52:02] <scribe> NEW SPEAKER: Okay. NEW SPEAKER:
[14:52:05] <scribe> How much time do we have left? NEW SPEAKER: Time is
[14:52:07] <scribe> gone. NEW SPEAKER:
[14:52:10] <scribe> NEW SPEAKER: Negative two minutes. NEW SPEAKER:
[14:52:14] <scribe> Let's just move, and skip that part. One more. There's
[14:52:18] <scribe> another issue I guess we'll have to take it on the list,
[14:52:21] <scribe> but, key question here is, right, next step, where do we
[14:52:26] <scribe> go from here? You know, are we on the right track? Are we
[14:52:29] <scribe> more than on just the right track? We've gotten some
[14:52:33] <scribe> comments and feedback, what are people's general feeling here?
[14:52:38] <scribe> Is this something people are willing to accept? You know,
[14:52:40] <scribe> comments, and various comments on the list,
[14:52:44] <scribe> obviously, you have to incorporate it in an update, but other
[14:52:48] <scribe> than that, are people willing to move forward with working
[14:52:51] <scribe> group last call on this?
[14:52:54] <scribe> All right. Who would not be willing to do that? NEW SPEAKER:
[14:52:58] <scribe> You mean now? NEW SPEAKER: No. We would have an update
[14:53:02] <scribe> obviously. I mean Jonathan has posted a lot of
[14:53:05] <scribe> comments that need to be addressed. We've had discussion here today.
[14:53:09] <scribe> So I think it makes sense to issue a new version first that basically addresses
[14:53:13] <scribe> those things and I would be looking forward to last call if the
[14:53:15] <scribe> group of course agrees to that. NEW SPEAKER: We're
[14:53:19] <scribe> basically asking, is this basically on the right track, or
[14:53:20] <scribe> is this completely broken?
[14:53:23] <scribe> NEW SPEAKER: I think it's on the right track for what it's
[14:53:29] <scribe> trying to do. Carefully worded. And the real issue I
[14:53:33] <scribe> think, the remaining one that I've seen so far is, do we
[14:53:37] <scribe> need to delete stuff or not? And my position would be, we
[14:53:42] <scribe> don't need it unless you show us why we need it. Right? As
[14:53:46] <scribe> opposed to its there, and you know, we're going to leave it there
[14:53:48] <scribe> because it's there. So I think you need to, I think you
[14:53:53] <scribe> need to prove why it's useful. And after that, I think would
[14:53:55] <scribe> be ready for working group last call. NEW SPEAKER: I think that's
[14:53:57] <scribe> fair. NEW SPEAKER: That's fair. NEW SPEAKER:
[14:54:00] <scribe> Yes. So I would have two comments, one
[14:54:05] <scribe> is, I'd like to have a much better demonstrable use cases for us
[14:54:09] <scribe> to explicitly decide those are important. Because anything could come
[14:54:14] <scribe> up with a potential use case. We could dream up SDP cases all over
[14:54:18] <scribe> again. The whole objective here is to really just do
[14:54:22] <scribe> something minimal and you know, I come back to a point he just said,
[14:54:25] <scribe> dp the problem that's really paining people the most
[14:54:31] <scribe> is best effort S R T P, this is a hefty pill to swallow for
[14:54:35] <scribe> that. So I want to make sure the bar is not too high for us to
[14:54:37] <scribe> miss the main problem we're trying to solve.
[14:54:42] <scribe> The second point is I wouldn't proof of encoding. I want you to
[14:54:45] <scribe> really think through how you would write an implementation to generate
[14:54:49] <scribe> these things with the complexities you discussed and could you
[14:54:53] <scribe> write a general algorithm or, you know, whatever, for a
[14:54:56] <scribe> bunch of the different cases we're considering. I'm worried
[14:55:01] <scribe> it's not obvious how you would construct -- I believe decoder
[14:55:06] --- Brandybuck has left
[14:55:06] <scribe> is trivial but encoder, I'm not convinced. It's somewhere
[14:55:10] <scribe> between sin tactic and semantic, it's neither and it's somewhere
[14:55:14] <scribe> in the middle. What code would you write that spits out
[14:55:20] <scribe> something that has lots of adds deletes.
[14:55:27] <scribe> I would like you guys to come back and say, yes, we thought bit,
[14:55:32] <scribe> worked it out and discussed it and we're pretty sure we know
[14:55:35] <scribe> how to implement a sin tactic algorithm. Or given this is the rough
[14:55:38] <scribe> input, we've thought about it. Because I'm not convinced I
[14:55:42] <scribe> would know how to tell, how to implement this. NEW SPEAKER:
[14:55:48] <scribe> Okay. That seems fair. NEW SPEAKER: I have just, I
[14:55:53] <scribe> have my usual simplicity rant, so have you talked to any the
[14:55:56] <scribe> implementers who are actually going to do this? One I'm
[14:55:59] <scribe> really concerned that we're again going with the sledge hammer
[14:56:03] <scribe> after a fly. And we have this tendency to have a small
[14:56:09] <scribe> problem and have a sort of discussion -- NEW SPEAKER:
[14:56:13] <scribe> NEW SPEAKER: We do con fig framework which also has, I don't
[14:56:17] <scribe> want to repeat these things, we should have enough lessons
[14:56:22] <scribe> that we don't have to go through this exercise, N times, and
[14:56:28] <scribe> then have kind of a emergency brakes after 5 years because we get rat
[14:56:32] <scribe> wholed. And I admire what you're trying do do. I think we
[14:56:36] <scribe> need to, it's always good to explore what something leads to,
[14:56:40] <scribe> because you don't know how complex it is until you try it.
[14:56:42] <scribe> Most things look simple until you try it.
[14:56:47] <scribe> I'm really concerned xw mixing sa man particular and syntactical
[14:56:50] <scribe> expression presentations in the same
[14:56:53] <scribe> document. We should look at if we need to go there, should
[14:56:57] <scribe> we do two parts type thing, and two parts thing which one
[14:57:01] <scribe> focuses on operations and one on just the basics. And the other
[14:57:08] <scribe> approaches that you haven't looked until now. This isn't
[14:57:10] <scribe> going to be completely back ward compatibe. NEW SPEAKER:
[14:57:12] <scribe> No, it's completely backward compatibe. NEW SPEAKER:
[14:57:17] <scribe> But let's say, you have to implement it to be useful.
[14:57:21] <scribe> Right. As usual. So it's not like you have some A nats type
[14:57:26] <scribe> things where people have done stuff. You're pretty much clean
[14:57:29] <scribe> slate for the diff type of things. So are there mechanisms which
[14:57:34] <scribe> are maybe not a single SDP but multiple SDPs that would be
[14:57:37] <scribe> simpler. NEW SPEAKER: What we have is a bunch of
[14:57:40] <scribe> requirements. NEW SPEAKER: I mean X M L diff type of
[14:57:43] <scribe> thing we've done before. NEW SPEAKER: No doubt,
[14:57:46] <scribe> there's a million different possible solutions out there. We
[14:57:48] <scribe> have a requirements document that's basically trying to say,
[14:57:52] <scribe> these are the problems we want to try and address. They go
[14:57:56] <scribe> beyond this RF T P. We got the guy in the meeting last
[14:57:58] <scribe> time, we're trying to satisfy that. The requirements are out
[14:58:02] <scribe> there, the design team has discussed it, everybody on the list has had
[14:58:07] <scribe> a chance to provide input if they agree. One of the primary
[14:58:10] <scribe> requirements is backward compatibility. Anything in multi part
[14:58:13] <scribe> MIME is out the window. It basically says, you have to --
[14:58:17] <scribe> NEW SPEAKER: Most things don't dash NEW SPEAKER: yi,
[14:58:19] <scribe> it's not supported. Right. You got to have something that could
[14:58:23] <scribe> be represented in the existing SDP, and the only way to do
[14:58:28] <scribe> that and be truly backwards compatibe is by encoding
[14:58:32] <scribe> attributes. If you have another proposal, preferably in
[14:58:35] <scribe> writing, we can do the same thing and the other thing as
[14:58:38] <scribe> well, we're trying to come up with something fairly quickly.
[14:58:42] <scribe> because everybody says if you are going to do
[14:58:44] <scribe> anything, you have to do it now.
[14:58:46] <scribe> So while I appreciate the comments and everything and
[14:58:49] <scribe> I understand where you're coming from, in the absence of
[14:58:53] <scribe> concrete alternative proposals, you know, I'm not sure what
[14:58:53] --- gas has left: Replaced by new connection
[14:58:56] <scribe> to do with them. NEW SPEAKER: That's, if you rule
[14:58:59] <scribe> out most of these, there are probably only degrees of
[14:59:05] <scribe> arguments that we can talk about. NEW SPEAKER: Yes.
[14:59:10] <scribe> NEW SPEAKER: Yes. Final comment. The point was made about
[14:59:14] <scribe> backward compatibility and your answer is, it is backward
[14:59:19] <scribe> compatibility. It is xwak ward compatibe with
[14:59:23] <scribe> implementations that did not try to do best effort S R T P for example.
[14:59:27] <scribe> But I'm not convinced that it is backward compatibe with
[14:59:31] <scribe> plethora of things that we have out there for best effort S R T
[14:59:33] <scribe> P. It's probably not.
[14:59:38] <scribe> And to me, that is the issue which goes back to what Jonathan
[14:59:43] <scribe> was saying, is did we address the problem we have? And
[14:59:45] --- admin has left
[14:59:46] <scribe> I, I'm not sure. I'm really not sure we did. NEW SPEAKER:
[14:59:47] <scribe> So why would it not --
[14:59:54] <scribe> NEW SPEAKER: SDP has, is stl a correct way of trying to do
[14:59:56] <scribe> just the next tiny little bit. And one of the reasons that
[15:00:01] <scribe> SDP can is in a pretty bad mess at this point is that nobody
[15:00:08] <scribe> ever thought more than 5 minutes at once. Best effort R T P
[15:00:09] <scribe> may be another example.
[15:00:14] <scribe> So having gone a step further is something highly desirable as
[15:00:17] <scribe> opposed to always trying to prove up imagination. NEW SPEAKER:
[15:00:24] <scribe> I agree. We are completely the opposite of SDP N can G and that's
[15:00:29] <scribe> the argument to this. Basically, I don't think this is saying this is
[15:00:30] <scribe> backward compatibility, is necessarily
[15:00:32] <scribe> (Several people talking.) NEW SPEAKER: It's NEW SPEAKER:
[15:00:35] <scribe> I think it is, actually, right, because if you have an
[15:00:38] <scribe> existing implementation out there the that uses whatever
[15:00:42] <scribe> proprietary I am mre ment taition, it has to be encoded
[15:00:45] <scribe> somehow. You're obviously not supporting this stuff. So by
[15:00:49] <scribe> the time you add support for this stuff, you can essentially
[15:00:53] <scribe> be not have a code, address, which one of these mechanisms
[15:00:58] <scribe> do I use, you know. So I don't understand. NEW SPEAKER: I
[15:01:02] <scribe> think the people that have done best effort S R T P, should
[15:01:06] <scribe> probably go and look at their pet mechanism and see if there is
[15:01:11] <scribe> an actual way to get to this, where you don't end up being
[15:01:14] <scribe> the lose err by being the first idiot to upgrade to this.
[15:01:18] <scribe> That's the problem. That I think needs to be addressed so
[15:01:23] <scribe> I'm going to look at it to see if it's do able. And I think
[15:01:25] <scribe> I'd encourage others to see that.
[15:01:30] <scribe> And maybe it's just a matter of fixing a few little things,
[15:01:34] <scribe> and I think we need do that exercise. Otherwise the upgrade
[15:01:43] <scribe> path is going to be very difficult.
[15:01:47] <scribe> NEW SPEAKER: Yes, I guess everybody is welcome to provide
[15:01:52] <scribe> input. So we have put out quite a few revisions in quite a
[15:01:55] <scribe> short time frame. Everything has been pretty open. So,
[15:02:00] <scribe> if there are additional concerns, additional input, not just
[15:02:03] <scribe> concerns, but solutions or things that should be taken into
[15:02:07] <scribe> account, then yes. Sure. You do want to get something
[15:02:08] <scribe> work able in the end. NEW SPEAKER:
[15:02:12] <scribe> Just want to say that you should also read the requirements,
[15:02:16] <scribe> not only this one. Because to understand the motivation for the
[15:02:19] <scribe> things, because otherwise, you reread it and you
[15:02:26] <scribe> don't know why we're doing these things and the questions come. NEW SPEAKER:
[15:02:31] <scribe> Okay. It look like it wasn't ice alone this time. But we
[15:02:37] <scribe> are definitely out of time. So, we had some discussions
[15:02:39] <scribe> here, probably going to be close to impossible to get any
[15:02:42] <scribe> kind of a second session scheduled here during this
[15:02:50] <scribe> week, so, I guess we are done. Have a good evening.
[15:02:51] --- ob has left
[15:02:53] --- scribe has left
[15:02:55] --- csp has left
[15:02:58] --- TomTaylor has left
[15:03:05] --- Jean-Francois has left
[15:03:09] --- spromano has left
[15:03:10] --- renee has left
[15:03:19] --- ysuzuki has left
[15:03:20] <avwijk> cheers
[15:03:29] --- avwijk has left
[15:03:31] --- jonlennox has left
[15:03:33] --- ben has left
[15:03:34] --- kvehmanen has left
[15:03:43] --- tomkri has left: Logged out
[15:04:20] --- hb47713 has left
[15:04:25] --- isudo has left
[15:04:34] --- mlepinski has left
[15:05:32] --- dumdidum has left
[15:13:15] --- tobia has left
[15:21:13] --- teemuk has left
[15:21:37] --- kafka-j31415927 has left
[15:37:04] --- bman has left: Replaced by new connection
[15:37:04] --- bman has joined
[17:45:18] --- isudo has joined
[17:50:46] --- isudo has left: Replaced by new connection
[19:21:30] --- jonlennox has joined
[19:22:26] --- bman has left
[19:23:58] --- jonlennox has left