[03:45:37] --- hbaosiy has joined
[03:45:47] --- hbaosiy has left
[03:48:14] --- renee has joined
[03:50:53] --- scribe has joined
[03:51:13] <scribe> SIPPING, March 23, 2007, 9 a.m. IETF 68.
[03:58:31] --- csp has joined
[04:03:51] <scribe> A natural
[04:03:52] <scribe> NEW SPEAKER: We'll be starting shortly.
[04:03:58] <scribe> Mary is going to distribute the blue sheets, they shouldn't
[04:04:01] <scribe> cross the aisle. Actually, I understood, even if they
[04:04:04] <scribe> signed last time, they have to sign again. Is that right?
[04:04:05] <scribe> NEW SPEAKER: That is
[04:04:14] <scribe> correct, the purpose of these blue sheets is that to figure
[04:04:18] <scribe> out what size room to use. And Dean has been lying to us. NEW SPEAKER:
[04:04:19] <scribe> So sign anyway, even if you --
[04:04:23] <scribe> NEW SPEAKER: Sign twice. For Chicago, vote early.
[04:04:27] <scribe> (Several people talking.) NEW SPEAKER: Okay. We're
[04:04:32] <scribe> going to be needing a a note taker. Okay. Spencer, thank you very much,
[04:04:34] <scribe> we would like to get a back up as well.
[04:04:39] --- hbaosiy has joined
[04:04:41] <scribe> Any volunteers to be the backup note taker. NEW SPEAKER: We
[04:04:44] <scribe> only need one. I care about service I D. NEW SPEAKER:
[04:04:49] <scribe> Expense err is saying he's going to be -- okay. Great, we
[04:04:53] <scribe> have two note takers. The jabber room, we're going to have
[04:04:57] <scribe> the scribe again, just putting there everything we say.
[04:05:02] <scribe> Now, we got two jabber rooms, so I sent an e-mail to
[04:05:06] <scribe> SIPPING a few days ago, just giving the address of the other
[04:05:10] <scribe> jabber room, so that they don't get overloaded, actually.
[04:05:10] --- thomas.stach has joined
[04:05:13] <scribe> So one is going to be only for the transcript of what we are talking
[04:05:17] <scribe> about here, and the then you will have the regular SIPPING
[04:05:21] <scribe> jabber room. Okay. As soon as the laptop is able
[04:05:26] <scribe> to project the agenda, okay. We have modified the agenda
[04:05:28] --- jonlennox has joined
[04:05:29] <scribe> slightly, since Monday, when we presented last time.
[04:05:34] <scribe> We have accommodated two new slots. Well, actually, first
[04:05:38] <scribe> of all, in principle, we were supposed to finish at 10:30 because the
[04:05:42] <scribe> ECRIT working group needed the last hour of this meeting.
[04:05:46] <scribe> Now it turns out that we can actually use the full slot. So we have
[04:05:49] --- vkg has joined
[04:05:50] <scribe> time there. And we allocated two new slots. One is for
[04:05:54] <scribe> the area directors to explain what is going to be done with the
[04:05:57] <scribe> service identification issue that was discussed on Monday.
[04:06:07] <scribe> And the other one, the MMusic working group has bore read in
[04:06:07] <scribe> principle half an hour to discuss an issue that relates to the
[04:06:11] <scribe> SIPPING working group in the sense that we have the IP v6 SIP
[04:06:12] --- ysuzuki has joined
[04:06:13] <scribe> transition document, which is going to be IETF last call
[04:06:14] <scribe> shortly.
[04:06:20] --- guido.franceschini has joined
[04:06:20] <scribe> And we have to decide what mechanism to use for the media transition,
[04:06:22] --- bpenfield has joined
[04:06:23] <scribe> and there have been discussion in the MMusic mailing list and the
[04:06:26] --- marc.bailly has joined
[04:06:27] <scribe> SIPPING mailing list, so the MMusic chairs, they will be
[04:06:30] <scribe> actually chairing for half an hour, to get a consensus of you
[04:06:31] <scribe> know, which way to go.
[04:06:35] <scribe> Okay. It seements that the laptop is working now.
[04:06:43] <scribe> Hopefully. Okay. There we go. NEW SPEAKER: I just
[04:06:45] <scribe> want to highlight, we did re name the page where we stored the
[04:06:49] <scribe> reviews and stuff, so hopefully it's more obvious when people
[04:06:50] <scribe> go out to look for that.
[04:06:56] <scribe> NEW SPEAKER: And Robert, I sent you actually an e-mail
[04:06:58] <scribe> asking you for feedback, and in particular, so let us know
[04:07:02] <scribe> if now it's clearer, otherwise we would love to got more
[04:07:07] <scribe> feedback so even somebody who goes for the first time to soft armor can
[04:07:11] <scribe> actually find the spreadsheet. NEW SPEAKER: Here's the
[04:07:15] <scribe> a general dwa as Gonzalo just mentioned. And Miguel, I
[04:07:17] --- kafka-j31415927 has joined
[04:07:20] <scribe> need your charts. NEW SPEAKER: Send them to Oscar and copy
[04:07:21] --- frodeki has joined
[04:07:24] <scribe> us as well. NEW SPEAKER: There's one other draft,
[04:07:26] <scribe> and that's homework SIPPING one 99. NEW SPEAKER:
[04:07:30] <scribe> Regarding that draft, it's getting actually a lot of attention
[04:07:33] <scribe> on the list. It relates to how to terminate early
[04:07:37] <scribe> dialogue s and be explicit about that. So please have a look
[04:07:40] <scribe> at it and send your comments toll mailing list
[04:07:46] <scribe> and keep the discussions there. NEW SPEAKER: Okay.
[04:07:50] <scribe> So, those were the updates to the agenda. To the chair
[04:07:54] <scribe> slides. And now Cullen will be talking about the service identification
[04:07:54] <scribe> issue.
[04:08:04] <scribe> As long as Mary's laptop recognizes the USB. NEW SPEAKER:
[04:08:17] <scribe> So, we get together and looked at this problem, and we come
[04:08:21] <scribe> up with early eesz see solution. We have got it all figured
[04:08:25] <scribe> out. No. This was impossible. The more we looked at it, it's
[04:08:29] <scribe> going to be a difficult topic going on. We've been thinking about it
[04:08:30] <scribe> a whole bunch.
[04:08:34] <scribe> So really, John was going to come and talk to folks about it
[04:08:38] <scribe> for a minute here. He is quite sick this morning and is not
[04:08:40] --- mayumimunakata has joined
[04:08:44] <scribe> making it due to something he ate. And so, I want to
[04:08:45] --- nils has joined
[04:08:50] <scribe> explain a little bit about what John and I would like to try and encourage
[04:08:54] <scribe> the working group to consider taking on a little bit of work
[04:08:57] <scribe> here, that we think will help solve a path forward.
[04:09:03] <scribe> And due to our usual, you know, we're running sneak err net
[04:09:08] <scribe> here on the slide, so, -- NEW SPEAKER: There you go. NEW SPEAKER:
[04:09:15] --- isudo has joined
[04:09:16] <scribe> So, the key piece of work that we really want to ask the
[04:09:18] <scribe> working group about, let me say something about the background of
[04:09:19] --- mayumimunakata has left
[04:09:22] <scribe> which. You've all seen the argument going back and forth on the mailing
[04:09:27] <scribe> list. It's a complicated issue. It's a real, there's a
[04:09:31] <scribe> real inter operability issue between some of the stuff that
[04:09:31] --- mayumi has joined
[04:09:35] <scribe> three G is considering doing, and terminally, user
[04:09:38] <scribe> agents that were outside of that type of environment and how they work
[04:09:43] <scribe> together in the long run. And you know, John and I are going
[04:09:47] <scribe> to work with the I A B, and other people have been involved with
[04:09:51] <scribe> this, and try and figure out what's the right sort of liaison
[04:09:54] <scribe> statement to send and say, hey, there's a problem here and we
[04:09:56] <scribe> need to figure out how to deal with it.
[04:10:01] <scribe> But what we'd like to be able to do is have some documents to
[04:10:05] <scribe> point out the problem and also some possible thoughts on how we
[04:10:09] <scribe> might go forward. The most important of those dock ments would
[04:10:13] <scribe> be this repository document that Jonathan has, is working
[04:10:18] <scribe> on, and has authord, and has agreed to write in
[04:10:21] <scribe> a fairly short period of time pt that explains what the problem
[04:10:24] <scribe> is and tries to give some real examples of it. We talked
[04:10:29] <scribe> about the problems of differentiating I TV and something
[04:10:34] <scribe> else, and different yaiting voice and gang, versus the type
[04:10:37] <scribe> of voice you might do in chat or something else.
[04:10:41] <scribe> There are many examples of what the problem is, and we need to
[04:10:44] <scribe> talk about possible ways to solve them. The key
[04:10:48] <scribe> thing I'm going to ask the working group, is the working group willing
[04:10:51] <scribe> to adopt doing that chunk of work as a working group item. Write an
[04:10:55] <scribe> informational document that explains what the problem is
[04:10:56] <scribe> here, and the issues.
[04:11:00] <scribe> The other thing, and I'll not going to ask the working group
[04:11:04] <scribe> to do, is a P header document that might address a path
[04:11:08] <scribe> forward, to solve some of these problems, and also, there's
[04:11:09] --- Alan H has joined
[04:11:13] <scribe> a media feature tag registration, and this is, it's a very
[04:11:16] <scribe> short document. Jonathan almost has
[04:11:20] <scribe> finished that fills a gap that we already have, and this is something we need to
[04:11:24] <scribe> definitely work on moving forward. But that's less of an
[04:11:25] <scribe> important issue than No. 1 here.
[04:11:29] <scribe> So we don't have much time to talk about this. But I would like
[04:11:33] <scribe> to try and encourage people to adopt to do some work on the
[04:11:37] <scribe> informational document on exploratory document, and if we
[04:11:40] <scribe> have anything people want to say why we shouldn't do this
[04:11:42] <scribe> particularly or issues around it?
[04:11:49] <scribe> Spencer?
[04:11:58] <scribe> NEW SPEAKER: Spencer dawk kins. sdmoo clearly some
[04:12:03] <scribe> people think the meeting is over. The volume is turned down. NEW SPEAKER:
[04:12:11] <scribe> No wireless in here. NEW SPEAKER: Sound good?
[04:12:17] <scribe> NEW SPEAKER: This is Spencer, so basically, I just want
[04:12:20] <scribe> to say, I think this is exactly the right thing to do. I
[04:12:23] <scribe> think we're doing the right thing. I think the steps are the right steps.
[04:12:28] <scribe> NEW SPEAKER: Thanks. Any other
[04:12:31] <scribe> comments, opinions, sukts?
[04:12:35] <scribe> Suggestions?
[04:12:41] <scribe> Okay.
[04:12:45] <scribe> NEW SPEAKER: Jonathan, do you want to speak or are you just
[04:12:48] <scribe> fixing the mic? NEW SPEAKER: I'm fixing the mic. NEW SPEAKER:
[04:12:53] <scribe> Okay. If you guys are willing, I'd like to take a hum on
[04:12:55] <scribe> whether we can a sdopt this. NEW SPEAKER: So you want
[04:12:57] <scribe> -- NEW SPEAKER: You can do it. NEW SPEAKER: So
[04:13:01] <scribe> you want to take a hum for who is in favor of this or point by
[04:13:04] <scribe> point. NEW SPEAKER: Just for the first one, adding a
[04:13:06] <scribe> working group Milestone to -- NEW SPEAKER: Okay. NEW SPEAKER:
[04:13:10] <scribe> Classic, you have to turn the power on. Now it's fixed.
[04:13:14] <scribe> Okay. NEW SPEAKER: Jonathan, an engineer (Several people
[04:13:14] <scribe> talking.)
[04:13:19] <scribe> NEW SPEAKER: We're going to take a hum as Colorado Cullen
[04:13:23] <scribe> suggested, do you want to say something before we take a hum? NEW SPEAKER:
[04:13:26] <scribe> Come up to the mic. NEW SPEAKER: Exactly. NEW SPEAKER:
[04:13:32] --- dgtlsoul has joined
[04:13:33] <scribe> Just a short question for clarification, in the first
[04:13:36] <scribe> bullet, I don't have a problem with it. I would just like
[04:13:38] <scribe> to, when you say discussing the problem, is it going to be
[04:13:42] <scribe> looked from a general perspective or is the input going to be
[04:13:46] <scribe> three GP P solution? What's going to be, you know, -- NEW SPEAKER:
[04:13:47] <scribe> The I (Several people talking.)
[04:13:48] <scribe> NEW SPEAKER:
[04:13:50] <scribe> NEW SPEAKER: Starting point. NEW SPEAKER: I'll let
[04:13:56] <scribe> Jonathan comment, but I view it as more solving capabilities negotiation and some of
[04:13:59] <scribe> the other I shall issues in using
[04:14:04] <scribe> NEW SPEAKER: Right. I mean, so, the general idea is
[04:14:08] <scribe> to just have an expository on the general problem of service
[04:14:12] <scribe> identification when it comes up. Why is it, and what do
[04:14:16] <scribe> they want to accomplish. What are the examples. Why is it perilous to
[04:14:22] <scribe> have a flag that the user agent inserts. What are the proob
[04:14:26] <scribe> lems with fraud, innovation, inter operability. With
[04:14:28] <scribe> concrete examples that demonstrate the problem. That's it.
[04:14:32] <scribe> And the proposition is that, you know, especially when you
[04:14:35] <scribe> separate out the P header, you know, this is, this
[04:14:43] <scribe> becomes a fairly generic statement that's not often covered with three G
[04:14:46] <scribe> F P but it's something they bump into. That's what's
[04:14:48] <scribe> involved. NEW SPEAKER: I mean, that
[04:14:51] <scribe> sounds like a good idea. I mean, you know, bullet two and
[04:14:55] <scribe> three are not really sure we can do that before we really have
[04:14:58] <scribe> is seen this bullet one, because we don't, we need to see
[04:15:01] <scribe> what the problem is before we can define how we're going to
[04:15:03] <scribe> solve it. NEW SPEAKER: Yes, of course. I'm not asking
[04:15:07] <scribe> about bullet two or three. We may deal with those
[04:15:10] <scribe> differently. I may not be asking them to be done in the working
[04:15:12] <scribe> group at all. NEW SPEAKER: Okay. Let's take a hum.
[04:15:16] <scribe> As Cullen explaind, or clarified, we're
[04:15:22] <scribe> going to take a hum only for bullet No. 1. So who is in
[04:15:26] <scribe> favor of producing an informational document along the lines of
[04:15:29] <scribe> bullet No. 1, and what Jonathan just explaind on the
[04:15:32] <scribe> mic, please hum. ( Humming. ) NEW SPEAKER:
[04:15:35] <scribe> Those who are opposed, please hum.
[04:15:37] <scribe> ( Silence. ) NEW SPEAKER: Okay. For the note
[04:15:42] <scribe> taker, it was nobody hummed opposed to it. NEW SPEAKER:
[04:15:45] <scribe> Strong consensus for. NEW SPEAKER: Unanimous. NEW SPEAKER:
[04:15:48] <scribe> Exactly. Okay. NEW SPEAKER: Okay. Thank you.
[04:15:54] <scribe> So now we will be giving the floor to the MMusic chairs for the
[04:16:02] <scribe> next half an hour. And to talk about IP v6 transition in
[04:16:03] <scribe> SIP, oois ANAT and these topics.
[04:16:07] <scribe> ( Ice, ANAT and these topics. ) NEW SPEAKER: You can
[04:16:11] <scribe> bring up the slides, right?
[04:16:12] <scribe> NEW SPEAKER: Just one second.
[04:16:16] <scribe> NEW SPEAKER: So Jonathan, I guess you are up. NEW SPEAKER:
[04:16:17] --- ttfr has joined
[04:16:22] --- ben has joined
[04:16:22] <scribe> Oh, Oscar, I just drop e-mail with slides, could you please
[04:16:27] <scribe> up load them to the web page. You should have them in your in box.
[04:16:32] <scribe> To all the speakers, we would appreciate if you copy Oscar
[04:16:35] <scribe> all the time. Otherwise we are running from our laptop and we
[04:16:39] <scribe> cannot up load the slides in real time. Okay. Jonathan,
[04:16:42] <scribe> go ahead. NEW SPEAKER: Okay. So, folks have notice order the
[04:16:46] <scribe> SIPPING and MMusic mailing list there's heated discussion on this
[04:16:53] <scribe> topic. Not a new topic, you know, this has had a running
[04:16:55] <scribe> thread on MMusic at extremely low volume for like two months
[04:17:00] <scribe> before this, but IETF, if nothing, is great for
[04:17:02] <scribe> escalating issues to people's attention.
[04:17:05] <scribe> So, I'm not going to have a long presentation here, rather
[04:17:08] <scribe> I'm going to summarize the points that I saw on the
[04:17:11] <scribe> mailing list on each side. And then open the floor for
[04:17:15] <scribe> continued discussion and then I've got some text for hums that
[04:17:19] <scribe> I think makes sense so I can make a decision on this and I can update ice
[04:17:20] <scribe> accordingly, next slide.
[04:17:27] <scribe> Here's basically what we're bee debating and it's three options and
[04:17:30] <scribe> it's important to be clear on what the options are. Option one
[04:17:37] <scribe> is to say that ice deposition indicates ANAT and the V 4 v6
[04:17:41] <scribe> transition document in public request will recommend ice as the
[04:17:44] <scribe> transition technique and basically no longer discuss ANAT.
[04:17:46] <scribe> That's option one.
[04:17:56] <scribe> Option two is the more or less the static quo I would say, that
[04:18:02] <scribe> ANAT is the V 4 v6 transition technique, which
[04:18:06] <scribe> is you have to have ANAT, of course you can always add ice,
[04:18:09] <scribe> and if you ever think you need to solve any of the problems
[04:18:12] <scribe> that ice solves, you put ice in, but if you're
[04:18:17] <scribe> also dual stack, you need both. That's why I don't, I
[04:18:21] <scribe> write it as ANAT or ANAT plus ice, so start with ANAT and
[04:18:26] <scribe> when you find you want ice, as long as you're stacked you
[04:18:32] <scribe> also have it. You can't slip over, because you run into an inter
[04:18:36] <scribe> op problem. Because one guy has ANAT and the other guy has
[04:18:40] <scribe> ice alone. And the whole thing doesn't work for dual
[04:18:44] <scribe> stack. So it's about the choice for base line mechanism for
[04:18:48] <scribe> dual stack quotes that will be there for the duration of dual stack
[04:18:48] <scribe> hosts.
[04:18:54] <scribe> Option three which has not gotten a lot of support, at best
[04:18:58] <scribe> luke warm from Flemming even, I don't want to misquote you.
[04:19:04] <scribe> But SDP capabilities negotiations replaces ANAT and then add ice
[04:19:08] <scribe> on top of cap, if you wanltd to do that. That's the three
[04:19:12] <scribe> options. I only have bullets, pros and cons on the first two.
[04:19:16] <scribe> I didn't see a lot again specifically, on the list in favor of SDP cap.
[04:19:19] <scribe> I think most of the discussion was, if you're going to twist
[04:19:25] <scribe> ice to look like ANAT, might as well do
[04:19:28] <scribe> that. Here's a summary of the pros and cons, difficult try
[04:19:32] <scribe> to be fair. Although my opinion is known to capture the pros and
[04:19:36] <scribe> cons. The biggest things in favor of ice is the first bullet
[04:19:41] <scribe> item. Even if you think there's no nats and no fire walls,
[04:19:45] <scribe> what ice is really good at is selection. It's picking between
[04:19:49] <scribe> choices where that choice depends on dynamic path connectivity.
[04:19:53] <scribe> And ice, generally speaking, it's way better idea to pick between
[04:20:01] <scribe> a pair of transport addresses with a dynamic stack than it is a
[04:20:02] <scribe> static prioritization.
[04:20:06] <scribe> That's the biggest reason why ice makes sense as a transition technique.
[04:20:10] <scribe> Next bullet, of course, if you do discover a fire wall
[04:20:13] <scribe> problem, you don't have to add something new on top of
[04:20:17] <scribe> something else. Ice is already there for that too. The next
[04:20:21] <scribe> bullet, again, if you want it, it's a feet stur, important
[04:20:26] <scribe> feature, because you're your selection of V four v6 candidate is
[04:20:31] <scribe> based on an end to end stun check, ice had this feature for
[04:20:35] <scribe> sometime now, where you can use path measurement, say or other
[04:20:40] <scribe> properties, that stun can or something else can even provide
[04:20:44] <scribe> you, dynamically, to pick mention these. So you might
[04:20:47] <scribe> elect to go to V four, even though you have v6, just
[04:20:51] <scribe> because the V four path for today happens to have 20 milli
[04:20:54] <scribe> seconds latency, compared to 150 on the v6 path.
[04:21:00] <scribe> You can, another plus is, you can use RFC 3484 with
[04:21:03] <scribe> it. I'll take two seconds and explain this RFC. Because I don't
[04:21:06] <scribe> think it's widely known in the community. This is an RFC that talks
[04:21:10] <scribe> about address sklex for v6 addresses. It's very similar
[04:21:14] <scribe> problem to ice is doing. But it's totally stacked and the problem
[04:21:18] <scribe> is, I know v6 host, you almost always have multiple v6
[04:21:21] <scribe> addresses. You've got link local addresses, six to four
[04:21:25] <scribe> addresses, you used to have site local addresses. You
[04:21:26] --- bman has joined
[04:21:28] <scribe> don't have those anymore. But there are several types of v6
[04:21:33] <scribe> addresses. You do a DNS query and you get back a lot of
[04:21:36] <scribe> addresses. I got a bunch from the server I want to reach.
[04:21:40] <scribe> This RFC talks about how you intelligently pick which of the
[04:21:43] <scribe> pairs to use, and it's kind of what you'd expect. You
[04:21:47] <scribe> would pick a link local address, pair it with another link local address,
[04:21:51] <scribe> when the prefixes match. But if they don't match, you
[04:21:54] <scribe> wouldn't normally pair them up. So it basically gives its
[04:21:57] <scribe> own priority based on knowing the pairs.
[04:22:02] <scribe> It turns out you can't run that algorithm with ANAT as currently
[04:22:06] <scribe> specified. It's not awful hard to add to ANAT, but the
[04:22:11] <scribe> essential problem is ANAT doesn't work that way. The offerer
[04:22:14] <scribe> err prioritizees all their addresses, sends them
[04:22:17] <scribe> over. The answer picks the highest priority one that works.
[04:22:21] <scribe> You've already prioritized at the offerer even before you have seen
[04:22:25] <scribe> the other addresses. And the whole idea with this RFC you
[04:22:27] <scribe> have to you have to see them both.
[04:22:32] <scribe> Why don't I do it at the answer or do it at the offer once I get
[04:22:34] <scribe> the answer. NEW SPEAKER: Well, it's similar to that.
[04:22:42] <scribe> Is the algorithm in 348 4 something that, that the
[04:22:47] <scribe> offerer could know in advance, so that it could order them
[04:22:49] <scribe> properly? NEW SPEAKER: No. That's the trick.
[04:22:52] <scribe> The algorithm depends on you knowing both the source and the destination
[04:22:55] <scribe> IP addresses to run it. So the offer can't do it. The
[04:22:58] <scribe> answer could do it. And the offer could do it when st answer
[04:23:02] <scribe> comes back. So the problem is, you have no way to signal what the
[04:23:06] <scribe> selection was. You could extend ANAT, to add a use
[04:23:11] <scribe> candidate flag, in the answer. That basically signals it.
[04:23:16] <scribe> But my only -- yes. But my only point is it's not there today. You need
[04:23:20] <scribe> to update ANAT to do that. Whereas with ice, it will work
[04:23:22] <scribe> out of the box with the regular selection. NEW SPEAKER:
[04:23:25] <scribe> So we have to change ANAT, regardless of what we do. NEW SPEAKER:
[04:23:28] <scribe> Yes. NEW SPEAKER: If you want to support this RFC,
[04:23:33] <scribe> which I understand is one of the v6 mandatory documents. You
[04:23:35] <scribe> would have to change ANAT to make it work. NEW SPEAKER:
[04:23:39] <scribe> This isn't quite an A D comment but just from having watched
[04:23:44] <scribe> the I S E G in action, I would be very surprised for anyone to say we don't have
[04:23:48] <scribe> to comply with it. I don't know how it would work if you
[04:23:51] <scribe> didn't comply with this, let's put it that way. NEW SPEAKER:
[04:23:57] <scribe> Caplan. So, I I'm no expert on 3484, but I did
[04:24:01] <scribe> skim it. And as far as I can understand from reading it,
[04:24:04] <scribe> to comply with it, your application can merely override it.
[04:24:09] <scribe> It's completely the application will. You fully comply with
[04:24:11] <scribe> it by not doing it. NEW SPEAKER: Fair point. NEW SPEAKER:
[04:24:16] <scribe> So just for the IESG perspective, you can comply by not doing
[04:24:19] <scribe> it at all. That's my only -- just because NEW SPEAKER:
[04:24:21] <scribe> (Several people talking.) NEW SPEAKER: I think the
[04:24:24] <scribe> point is it has some good advice. NEW SPEAKER:
[04:24:25] <scribe> Absolutely. NEW SPEAKER: It's not there (Several people
[04:24:25] <scribe> talking.)
[04:24:29] <scribe> NEW SPEAKER: And we're not going to exactly comply with it
[04:24:31] <scribe> in ice NEW SPEAKER: Which is my next poynltd. (Several people
[04:24:31] <scribe> talking.)
[04:24:32] --- bhoeneis has joined
[04:24:37] <scribe> NEW SPEAKER: It's not 3484. You are going to
[04:24:40] <scribe> pick on your own priority scheme, on what is going to be the
[04:24:43] <scribe> highest preference on whoever is the controller. NEW SPEAKER:
[04:24:45] <scribe> Let me answer that. The regular selection algorithm is very
[04:24:48] <scribe> important to understand, runs separately from the ice
[04:24:52] <scribe> prioritization. In the signalling messages,
[04:24:55] <scribe> that allows you to pick stop to ice checks whenever you want
[04:24:59] <scribe> and pick whatever you want whenever you want. So an
[04:25:02] <scribe> algorithm locally, without any change to the ice spec or
[04:25:06] <scribe> cooperation from the other end could run the RFC 3484
[04:25:10] <scribe> selection process as defined. It could add the dynamic checks
[04:25:15] <scribe> to it. Don't pick a pair that RFC 3484 says to pick
[04:25:18] <scribe> if the checks failed. Good advice. Do something slightly
[04:25:22] <scribe> different. You use the new version of the 3484,
[04:25:26] <scribe> whatever you want. The point is, it's entirely
[04:25:31] <scribe> localized decision. Whereas ANAT you need to extend it. NEW SPEAKER:
[04:25:35] <scribe> Again, I don't think you need to extend it at all. As far
[04:25:39] <scribe> as I can read ANAT, sorry, as far as I can read
[04:25:40] <scribe> 3484. (Several people talking.)
[04:25:43] <scribe> NEW SPEAKER: So you can make the argument that ANAT
[04:25:47] <scribe> decidedd, make I doubt it was conscious, but
[04:25:49] <scribe> yes, fair point. NEW SPEAKER: You could decide that
[04:25:52] <scribe> you're all going to use local scope address. That's the other
[04:25:57] <scribe> thing I don't understand. If you pick a global scope and if
[04:26:01] <scribe> the media happens to go to link local scope, but you picked a
[04:26:05] <scribe> global and he picked a global, so what, the packet still gets
[04:26:07] <scribe> there. NEW SPEAKER: There's some reason I presume they
[04:26:11] <scribe> recommended to do it this way. I'm not a v6 expert. I'm only
[04:26:14] <scribe> saying, there's some wisdom captured in this
[04:26:16] <scribe> document, if you think it's important, the group thinks this
[04:26:20] <scribe> is important, this requires an ANAT extension to incorporate that
[04:26:23] <scribe> wisdom. You can incorporate it as your leisure with ice,
[04:26:26] <scribe> without any change is my point. NEW SPEAKER: Right. NEW SPEAKER:
[04:26:29] <scribe> And I think you're just saying, I would rather ignore it. Which
[04:26:31] <scribe> is your choice. NEW SPEAKER: I'm not saying I'd rather
[04:26:34] <scribe> ignore it. I'm saying ANAT doesn't need that either. NEW SPEAKER:
[04:26:37] <scribe> You can say that, I think about any
[04:26:39] <scribe> pairings. NEW SPEAKER: Exactly? NEW SPEAKER:
[04:26:46] <scribe> In theory it can work. There was some reason they made this
[04:26:47] <scribe> mandatory, but I don't know the details.
[04:26:54] <scribe> NEW SPEAKER: Cullen Jennings here. Easiest way to think
[04:26:58] <scribe> about 3484 that everybody can relate to, imagine you
[04:27:01] <scribe> had two IP before your facees that went to different
[04:27:05] <scribe> networks. One went to ten Dot zero Dot zero, if you pick the wrong
[04:27:09] <scribe> one, it's not going to work. And you know, that was the
[04:27:14] <scribe> essence of what some of the 344 stuff was trying to get at,
[04:27:17] <scribe> in a way that was prioritizing things that might work.
[04:27:22] <scribe> But, it's called picking the right source IP address. You
[04:27:25] <scribe> can't do that without a destination. Now, in ice we deal
[04:27:28] <scribe> with that, right? We pair NEW SPEAKER: Right. NEW SPEAKER:
[04:27:32] <scribe> So anything we do with ice is not going to be inconsistent with
[04:27:34] <scribe> 3484. NEW SPEAKER: Exactly. NEW SPEAKER:
[04:27:39] <scribe> But, just saying, trying to ignore it or blow it off.
[04:27:42] <scribe> It's not a small document. It's like, if you don't do
[04:27:45] <scribe> something along the lines of this document, discuss it,
[04:27:48] <scribe> packets are not going to end up on an interface that's going to
[04:27:53] <scribe> work. NEW SPEAKER: Well, if you run ice alone, you could
[04:27:57] <scribe> argue you don't need 3484 because ice will figure all that out.
[04:27:59] <scribe> But you can't say that about ANAT. NEW SPEAKER:
[04:28:02] <scribe> Probably people would say you were consistent wa can with
[04:28:05] <scribe> 3484. That was exactly the kind of stuff they were saying. NEW SPEAKER:
[04:28:09] <scribe> Right. NEW SPEAKER: You had two interfaces to the two different
[04:28:12] <scribe> networks, you could not figure out which one to use. That has
[04:28:18] <scribe> nothing do do with something that that whole problem comes up. NEW SPEAKER:
[04:28:22] <scribe> Just, hold on a second. Francois. Before we go on, you
[04:28:25] <scribe> know, discussing this, what I've seen on the list is that people
[04:28:30] <scribe> claiming the ice plus ANAT thing, we're saying that they
[04:28:33] <scribe> understand that in some circumstances, it will not work.
[04:28:36] <scribe> But it seems that for their deployments, they were happy to
[04:28:39] <scribe> have ANAT for the time being and implement isolate err.
[04:28:43] <scribe> So I guess everybody agrees that ANAT doesn't work
[04:28:46] <scribe> for every single use case, so if we're going to be discussing
[04:28:50] <scribe> the same thing, it's Bertha we move along a better, that we
[04:28:53] <scribe> move along. NEW SPEAKER: I don't think I agree with
[04:28:59] <scribe> what you said. I think my conclusion is that, the way we define
[04:29:06] <scribe> ANAT right now, I think conflicts with 3484, and I don't
[04:29:13] <scribe> think our group here has the mandate or authority to overrule
[04:29:17] <scribe> something that was done, that we're where really, the
[04:29:21] <scribe> expertise is in the IP v6 crowd. So whatever we do, I think we
[04:29:25] <scribe> really need to make sure that we're not breaking something with
[04:29:28] <scribe> IP v6. NEW SPEAKER: We've been working with v6 guys
[04:29:31] <scribe> actually and they are giving us their advice, NEW SPEAKER:
[04:29:33] <scribe> And they understand ANAT? NEW SPEAKER: Sorry? NEW SPEAKER:
[04:29:36] <scribe> And they understand ANAT? They understand that it -- NEW SPEAKER:
[04:29:40] <scribe> They claim they understand it as much as anybody. I mean,
[04:29:42] <scribe> that's a fair point. NEW SPEAKER: Something is wrong (Several people
[04:29:46] <scribe> talking.) NEW SPEAKER: I mean, I looked at the v6
[04:29:49] --- dgtlsoul has left
[04:29:49] <scribe> transition document that discusses 3484 for SIP signalling.
[04:29:55] <scribe> It doesn't utter one word about usage for media. e so I
[04:29:57] <scribe> think there's a disconnect here, that independent of the ice
[04:29:59] <scribe> issue, has come up, okay. NEW SPEAKER: Yes. NEW SPEAKER:
[04:30:02] <scribe> As part of this discussion. NEW SPEAKER: I agree with
[04:30:04] <scribe> you. I'm just trying to reflect, you know, the
[04:30:08] <scribe> discussions on the mailing list, I'm by no means saying my
[04:30:10] <scribe> personal opinion on this actually. NEW SPEAKER: But I
[04:30:14] <scribe> think, my point only is that sure, discussions are happening with
[04:30:18] <scribe> v6 ops, but we still have a problem. NEW SPEAKER: Sure.
[04:30:22] <scribe> Francois. NEW SPEAKER: Actually, I spoke with an dra
[04:30:27] <scribe> who has been involved NEW SPEAKER: With who? Allan
[04:30:30] <scribe> dura. NEW SPEAKER: Who has been involved with the six
[04:30:36] <scribe> ops quite a bit. Especially in the context of since whashtion
[04:30:40] <scribe> they call IP v6 IP V four hosts. And in my
[04:30:44] <scribe> opinion, it's very important to make sure that we do support
[04:30:47] <scribe> 3484. I think I brought 3484 oh the
[04:30:52] <scribe> mailing list during my review of ice 11. Because I thought
[04:30:56] <scribe> this could be a means to help prioritize the local candidates
[04:30:59] <scribe> when you sort out all the candidates you have locally.
[04:31:02] <scribe> That's when I -- NEW SPEAKER: I agree. So I think you
[04:31:05] <scribe> can't use 3484 to change the ice pairing. But you
[04:31:08] <scribe> can use it as part of the regular selection algorithm. NEW SPEAKER:
[04:31:13] <scribe> So I guess my point here is, we probably need to send some formal
[04:31:17] <scribe> e-mails to the v6 ops mailing list to get three feedback, but my
[04:31:22] <scribe> discussions with hanz, especially for some of the
[04:31:23] --- mayumi has left
[04:31:25] <scribe> specs, that this is absolutely required when you build a dual
[04:31:30] <scribe> stack IP six V 4 host. It's not something you can ignore.
[04:31:34] <scribe> Therefore. And to the comments that add dral
[04:31:37] <scribe> made that the application can over right this, that's in the
[04:31:40] <scribe> first paragraph of 3484, but when you really look
[04:31:43] <scribe> into it, you cannot ignore it. You can override it but not
[04:31:46] <scribe> ignore it. NEW SPEAKER: What would be the difference of
[04:31:49] <scribe> overriding something and not ignoring it or ignoring it? NEW SPEAKER:
[04:31:52] <scribe> Well, let's say 3484 process as Jonathan said,
[04:31:56] <scribe> either when you're on the answer side or after you receive the
[04:31:59] <scribe> answer on the offerer side. Because you have to have the
[04:32:00] <scribe> destination address to compute the algorithm.
[04:32:07] <scribe> Once you do that, you get sort, yes, when you do the SDP
[04:32:10] <scribe> negotiation, you may cup up with a can different sorting. That's when you
[04:32:13] <scribe> can override it. But the fact that ice does provide you with the
[04:32:19] <scribe> grammar to negotiate that, is actually an advantage, and I think
[04:32:23] <scribe> they would have to provide a means to provide multiple IP v6
[04:32:25] <scribe> addresses, which is exactly what ice provides. NEW SPEAKER:
[04:32:28] <scribe> It can do that. The problem is, it's the selection that's
[04:32:29] <scribe> not signald.
[04:32:34] <scribe> The main point is we can debate how you can add 3484 to
[04:32:37] <scribe> ANAT. Right now it utters not one breath about
[04:32:37] --- mayumi has joined
[04:32:41] <scribe> it. And I'm pretty sure it needs either a flag or mandatory
[04:32:46] <scribe> requirement for, you have to simultaneously run the same algorithm on both
[04:32:51] <scribe> sides. I hate that approach. So you need some, something in
[04:32:53] <scribe> ANAT. Okay.
[04:32:58] <scribe> NEW SPEAKER: Caplan. One more comment on this topic.
[04:33:04] <scribe> Only that since you're making 3484 a construction crux of
[04:33:07] <scribe> this argument -- NEW SPEAKER: It's one bullet
[04:33:08] <scribe> (Several people talking.)
[04:33:11] <scribe> NEW SPEAKER: What I don't understand, ice works with it
[04:33:14] <scribe> it's err. And it's confusing to me when you say, it
[04:33:17] <scribe> clearly confuses some other people, because I would assume
[04:33:18] <scribe> and you don't know the destination address (Several people
[04:33:18] <scribe> talking.)
[04:33:20] <scribe> NEW SPEAKER: I'll try (Several people talking.) NEW SPEAKER:
[04:33:23] <scribe> The real bug is you have no concept of what the other address is. NEW SPEAKER:
[04:33:27] <scribe> I'll explain it, because it's really important. It's one piece
[04:33:32] <scribe> of ice that came in late. It was like a 12 edition, this
[04:33:35] <scribe> concept of what was previously called introspective
[04:33:38] <scribe> selection, now called regular selection, implying you really
[04:33:41] <scribe> want this approach. And in fact, 14 switches to recommend it.
[04:33:47] <scribe> One of the problems that motivated is, is that people want new
[04:33:49] <scribe> algorithms for picking what the candidate pairs are.
[04:33:54] <scribe> So instead of specifying one algorithm and having both sides
[04:33:56] <scribe> unilaterally agree. We introduced the
[04:33:59] --- hejingtong has joined
[04:34:00] <scribe> concept of a role, controlling and control. And the
[04:34:03] <scribe> controlling node gets to pick when the checks stop and which one of the
[04:34:07] <scribe> ones that works get picked. That algorithm you is completely
[04:34:10] <scribe> and totally orthagonal, to the pair
[04:34:13] <scribe> prioritizations. And does not need to be standardized
[04:34:15] <scribe> because it's a local implementation choice. NEW SPEAKER:
[04:34:19] <scribe> Absolutely. NEW SPEAKER: We have the use candidate flag in
[04:34:21] <scribe> the message oh the choice is communicated to
[04:34:22] <scribe> the other side.
[04:34:26] <scribe> Let me give you a simple algorithm that will incorporate
[04:34:30] <scribe> 3484 that is sub optimal, but just to get to the point.
[04:34:34] <scribe> You put your IP addresses in. You prioritize them randomly.
[04:34:39] <scribe> You send your offer. The answer is v6 addresses in.
[04:34:43] <scribe> Prioritized them randomly. Controlling node let's the check
[04:34:45] <scribe> run to completion. You don't want to do that because of
[04:34:49] <scribe> latency. You can do much better. Run them to completion.
[04:34:51] <scribe> We now know all of the v6 pairs that work. NEW SPEAKER:
[04:34:55] <scribe> Yes. NEW SPEAKER: We take those pairs. We run RFC
[04:34:58] <scribe> z 3484 on them and we take the highest priority one. That is
[04:35:02] <scribe> the one that is selected xwi ice and then you send the stun
[04:35:04] <scribe> check with the use candidate. Right? NEW SPEAKER: Yes. NEW SPEAKER:
[04:35:08] <scribe> That's one algorithm. I can go through many
[04:35:11] <scribe> variants and they're all local implementation choicees
[04:35:13] <scribe> because I signal the selection with use candidate. NEW SPEAKER:
[04:35:16] <scribe> Why? Because you just verified that three different
[04:35:21] <scribe> addresses work. Whichever one you want. The reason
[04:35:22] <scribe> 3484 does all this --
[04:35:23] <scribe> (Several people talking.)
[04:35:26] <scribe> NEW SPEAKER: I any you're saying, if you had ice, you may
[04:35:28] <scribe> not even need to bother with 34784. NEW SPEAKER:
[04:35:31] <scribe> Right. NEW SPEAKER: That may be true too. But no
[04:35:33] <scribe> matter what, you have a problem with ANAT. NEW SPEAKER:
[04:35:38] <scribe> So my interpretation of how ANAT would work, ANAT woo get all the addresses that
[04:35:41] <scribe> are available. Offer them all, as grouped, several grouped
[04:35:46] <scribe> addresses. Answering side, running 3484, would
[04:35:50] <scribe> say, which one am I I in the address space (Several people
[04:35:51] <scribe> talking.) NEW SPEAKER: Answer that one. NEW SPEAKER:
[04:35:53] --- hb47713 has joined
[04:35:54] <scribe> That's not currently how it works. I'm not saying (Several people
[04:35:56] <scribe> talking.)
[04:35:58] <scribe> NEW SPEAKER: But ANAT
[04:36:01] <scribe> NEW SPEAKER: ANAT doesn't say
[04:36:02] <scribe> (Several people talking.) NEW SPEAKER: I mean, I don't
[04:36:06] <scribe> know where we're going with this. My point is, at the moment, I'm
[04:36:09] <scribe> not saying you couldn't fix ANAT. I'm saying, at the
[04:36:14] <scribe> moment, ANAT does not address RFC 3484. I can
[04:36:17] <scribe> think of two ways to do it, we can have a technical debate
[04:36:20] <scribe> about what the right way is, because we need a flag, just
[04:36:23] <scribe> like we did in ice. Okay. NEW SPEAKER: Okay. NEW SPEAKER: But I
[04:36:27] <scribe> think it's not correct to state, no, no, it's all done.
[04:36:30] <scribe> ANAT works with RFC 3484. That's the thing I don't
[04:36:35] <scribe> think you can claim, if for no other reason, the RFC is not
[04:36:39] <scribe> utterd this the specification. NEW SPEAKER: It's not my
[04:36:42] <scribe> claim. My claim is it did not contradict it. In the sense
[04:36:44] <scribe> that it did not comply (Several people talking.) NEW SPEAKER:
[04:36:49] <scribe> Alter ANAT and maybe not even a big alteration, I agree with that.
[04:36:51] <scribe> I think it would take a flag, not much different from use
[04:36:55] <scribe> candidate. NEW SPEAKER: We have now taken up like 20
[04:36:58] <scribe> minutes of 30 minutes, so can we please stop this argument. NEW SPEAKER:
[04:37:02] <scribe> Yes. NEW SPEAKER: I'm moving on to the next topic.
[04:37:06] <scribe> The last bullet point on your eyes plus will be on that point
[04:37:11] <scribe> anyway. And to me, that is the crux of the debate.
[04:37:15] <scribe> Because I really feel that you live in two different worlds.
[04:37:18] <scribe> There's a world where there will be a lot of ice end
[04:37:22] <scribe> points and there is another world where there won't be at all.
[04:37:26] <scribe> And I don't know how to consolidate those two worlds, but my
[04:37:30] <scribe> viewpoint, it's -- NEW SPEAKER: See, I disagree. NEW SPEAKER:
[04:37:35] <scribe> I have one -- I guess it would be fair to let Jonathan run
[04:37:39] <scribe> through all the pros and cons that he has proposed. Not
[04:37:42] <scribe> jumping out one and sake, this is what I care very much
[04:37:46] <scribe> about. We had one discussion and so it makes most sense to go
[04:37:49] <scribe> through the rest, and then have the discussion as opposed to
[04:37:52] <scribe> jumping back and forth, which is not going to be any
[04:37:53] <scribe> constructive at all. NEW SPEAKER: Okay. Sorry. (Several people
[04:37:58] <scribe> talking.) NEW SPEAKER: Just one, because you brought
[04:38:03] <scribe> this ice versus non ice up, we are always often tend to make the
[04:38:05] <scribe> assumption that we are kind of whoevering above
[04:38:08] <scribe> the internet and say, oh, this is nice, this is nice cloud
[04:38:11] <scribe> or so. If you are an end point stuck in the middle of
[04:38:15] <scribe> somewhere, you may not be able to see very far. And we
[04:38:19] <scribe> shouldn't be claiming, when we build something that we have an
[04:38:22] <scribe> overview of how the network, how our connectivity or whatever
[04:38:25] <scribe> looks like. So, just keep that in mind. You don't have
[04:38:29] <scribe> an overview. A simple box that is one interface or two
[04:38:33] <scribe> interfaces or whatever. But they -- dash NEW SPEAKER:
[04:38:36] <scribe> That's one of the bullet points. That one,
[04:38:40] <scribe> 3484, we had to take time, because I don't think it was
[04:38:45] <scribe> understood. If awm you cared about is select between v6 and V
[04:38:48] <scribe> 4, you could make the solution.
[04:38:52] <scribe> Another argument that's come up on the list, well, if this
[04:38:58] <scribe> turns out there are no pir fire walls and nats, I
[04:39:00] <scribe> think this was what he was saying. They'll be there (Several people talking.) NEW SPEAKER:
[04:39:06] <scribe> NEW SPEAKER: Your business is based on that assumption. But there
[04:39:10] <scribe> are, so that's a different comment. But there were comments
[04:39:13] <scribe> on the list that said, there's not going to be nats and fire
[04:39:17] <scribe> world in a v6 world, so ice is a transition technology that we
[04:39:20] <scribe> don't want to nail in there permanently. I don't agree
[04:39:22] <scribe> with that, but it was an argument made.
[04:39:27] <scribe> Argument again made, came up on the list, that it was likely
[04:39:30] <scribe> to be on end points anyway, and maybe it's a
[04:39:34] <scribe> lot, some or a little but I think there are some fraction of
[04:39:37] <scribe> end points where it will be there already. Just
[04:39:38] <scribe> an issue.
[04:39:43] <scribe> Again, the main issue is unquestion blee simpler dhan ice if
[04:39:47] <scribe> all you care about is a static V four, v6 connection. A
[04:39:51] <scribe> lot of the debate is whether static is tough actually enough or
[04:39:51] <scribe> not.
[04:39:56] <scribe> It's question mark already specified. It sounds
[04:40:00] <scribe> like we may need to revise it to deal with the 3484.
[04:40:04] <scribe> The one that I think is most painful here, if we decide to use
[04:40:11] <scribe> ANAT for V 4 v6 transition, v6 trans SIPPING trans document
[04:40:15] <scribe> whatever we call it. Says ANAT is what you implement, then
[04:40:19] <scribe> if later on you want to add ice, it's an addition. It's not
[04:40:26] <scribe> instead of. If this guy picks ANAT and this guy picks ice and they're
[04:40:30] <scribe> both dual stacked and he thought ANAT was the answer and he thought
[04:40:34] <scribe> ice was the answer, it doesn't work. So once you say that
[04:40:37] <scribe> dual stack hosts use ANAT, and by the way, I believe
[04:40:41] <scribe> the trans document is only should and it's not going to work.
[04:40:44] <scribe> It needs to be must, and it's independent of the ice thing,
[04:40:47] <scribe> okay. Even if you thought there was no ice. If you don't
[04:40:52] <scribe> say must it won't work. That you're locking ANAT in for dual
[04:40:55] <scribe> stack and then it's only adding ice, never replacing it.
[04:41:01] <scribe> So people who think that I need only ANAT now, I'll deal with the ice thing
[04:41:06] <scribe> later, you're going to not switch, you're going to add. You're going
[04:41:07] <scribe> to add more complexity later.
[04:41:11] <scribe> Doesn't work with 3484, wenlt through that. Stack
[04:41:14] <scribe> selection does not fall back, path problems. Again, this is
[04:41:20] <scribe> sort of reiterating the stuff on top. No path
[04:41:23] <scribe> based selection, you can't use latency checks or whatever
[04:41:26] <scribe> mechanisms you might otherwise make.
[04:41:29] <scribe> I think I captured everything. If there's something
[04:41:32] <scribe> people are not familiar with or thoughts that are on the list
[04:41:35] <scribe> that I didn't capture it, you know, speak now, please.
[04:41:41] <scribe> NEW SPEAKER: Francois speaking. From a process
[04:41:45] <scribe> perspective, I mean, the reason we're rushing this in, at
[04:41:48] <scribe> the last minute, is that we believe that in order to move
[04:41:52] <scribe> forward with the transition -- NEW SPEAKER: Before you go
[04:41:55] <scribe> on, this is not rushing in the last minute. This has been brought up
[04:41:59] <scribe> long time ago in the MMusic mailing list. People, they just didn't
[04:42:02] <scribe> care. So it's just the lack of response, because that's why we
[04:42:06] <scribe> are discussing that. It's not that we are trying to sneak it
[04:42:08] <scribe> in at the last moment, just a clarification. NEW SPEAKER:
[04:42:11] <scribe> I agree with that. It's our fault. That's not the issue.
[04:42:15] <scribe> The problem that I'm seeing here is, we have to be very
[04:42:19] <scribe> careful what we do, so we don't end up with screwing up
[04:42:22] <scribe> things even more. I think that there's really two main
[04:42:29] <scribe> issues that are, where I don't think we're going to get
[04:42:35] <scribe> resolution today, and so, the first issue is what are,
[04:42:40] <scribe> what is the syntax of the description in the SDP where it lists
[04:42:44] <scribe> all the IP v6 addresses? And that's where we have talked, you know, is it
[04:42:50] <scribe> ice or is it ANAT or is it diff negotiation.
[04:42:55] <scribe> That one in my mind is not really where the complexity is.
[04:42:59] <scribe> The main issue is arguing about do we need the connectivity
[04:43:05] <scribe> check that ice provides, in all cases? And will we need it
[04:43:06] <scribe> forever? Essentially.
[04:43:11] <scribe> Okay. Where there's a lot of differences of opinion p, and
[04:43:15] <scribe> it's not clear to me that, I'm sure we will not resolve that today.
[04:43:18] <scribe> I mean, it's completely impossible. We can argue here the
[04:43:22] <scribe> whole afternoon if we want to. So what we need to find is how do
[04:43:27] <scribe> we move forward without, you know, flushing the baby with
[04:43:31] <scribe> the bath water. And the only thing I can see, that would
[04:43:38] <scribe> actually work, could potentially work, in reality is,
[04:43:44] <scribe> kind of base it on ice for now. And with the caveat that if we
[04:43:48] <scribe> believe that we need a way to eliminate the connectivity check
[04:43:54] <scribe> later on based on analysis from the group, that we bring it
[04:43:57] <scribe> later. Without delaying the document.
[04:44:03] <scribe> So a sort of optimization for ice. If we
[04:44:06] <scribe> think it's feasible. Something like we did with ice light or
[04:44:09] <scribe> something even lighter. I know ice light as it is today
[04:44:13] <scribe> doesn't work on for this, we discussed that. But to me,
[04:44:14] <scribe> I think it's the only way forward.
[04:44:18] <scribe> If we leave ANAT in there, I think Jonathan is correct, that
[04:44:21] <scribe> we're, there's going to be some compatibility problems with
[04:44:24] <scribe> the way this works. NEW SPEAKER: So, there's, I
[04:44:28] <scribe> can separate document hats from decision making. I mean, I thought
[04:44:33] <scribe> about this too. Ice right now, takes a completely agnostic
[04:44:37] <scribe> stance on this problem. ANAT relationship says, you can
[04:44:40] <scribe> put your V four, v6 in one end line or you can put them in
[04:44:45] <scribe> ANAT. And it's notoriously decided which one you should
[04:44:48] <scribe> actually do. So it has no inter operability with ANAT
[04:44:52] <scribe> because of this problem. You could delegate the decision to
[04:44:57] <scribe> the v6 trans document if you felt the problem was we need three
[04:45:01] <scribe> more weeks, and publish another document later that trition
[04:45:04] <scribe> to relax the confusing. So, one of the reasons we
[04:45:08] <scribe> want a decision today is because we want to complete ice. So
[04:45:12] <scribe> a little bit to couple them, in the expense of a little document
[04:45:15] <scribe> confusion. But your proposing something different still, which
[04:45:18] <scribe> is -- NEW SPEAKER: Not really, actually. I think,
[04:45:22] <scribe> what I was saying was in reference to the v6 trans document.
[04:45:26] <scribe> I do think for ice document you should do the document path.
[04:45:30] <scribe> I do not think you want to go deep into this, because we're going to
[04:45:33] <scribe> get into a huge argument, because -- NEW SPEAKER: We
[04:45:36] <scribe> already are. NEW SPEAKER: People who don't like the approach
[04:45:38] <scribe> are not going agree with you doing it on your own. NEW SPEAKER:
[04:45:41] <scribe> I brought this to the working group. I am not taking -- NEW SPEAKER:
[04:45:45] <scribe> Right. So I think you need to kind of be fairly neutral, in
[04:45:47] <scribe> the ice document. I agree with that. NEW SPEAKER:
[04:45:51] <scribe> We as a group need to decide this in the end, so that's why I'm
[04:45:53] <scribe> raising the issue. NEW SPEAKER: We'll be cutting the
[04:45:56] <scribe> mic line now. NEW SPEAKER: So that's what I have to
[04:46:00] <scribe> say. I think we need to have a creative way to move forward.
[04:46:03] <scribe> And I don't think we want to debate all the technical stuff today.
[04:46:07] <scribe> Because we're not going to solve it today sh. It's just
[04:46:09] <scribe> impossible. NEW SPEAKER: We will be taking a hum at
[04:46:12] <scribe> the end on this presentation anyway, to see where we stand. NEW SPEAKER:
[04:46:17] <scribe> I think he's saying, the third adoption I add to the hum,
[04:46:22] <scribe> if that's what you meant, let ice proceed, debate v6, V four
[04:46:25] <scribe> separately. I mean, we can add more things to the hum
[04:46:28] <scribe> list, NEW SPEAKER: Sure. But, just postponing the
[04:46:29] <scribe> decision, you know, doesn't help. NEW SPEAKER: That's
[04:46:32] <scribe> quha I thought I heard you say. Unless we need two more
[04:46:36] <scribe> weeks, or today, we won't know for engineers years. NEW SPEAKER:
[04:46:40] <scribe> The point is that we make, the, we had discussion Monday.
[04:46:44] <scribe> People said we need one extra week to think about it. Okay.
[04:46:48] <scribe> Jonathan intended to discuss it during the week. He hasn't
[04:46:52] <scribe> done it because we want to close it now. Now people want three
[04:46:56] <scribe> extra weeks and then people want another month. Nothing is
[04:46:59] <scribe> going to change in the meantime so I would rather take a hum today and
[04:47:02] <scribe> try to find a way forward. NEW SPEAKER: Let me clarify
[04:47:05] <scribe> what I'm proposing. Essentially what I'm proposing is that
[04:47:13] <scribe> we do deprecate ANAT. Okay. We base the algorithm on ice with the
[04:47:18] <scribe> caveat that if we do not need an ice negotiation, or have a much
[04:47:21] <scribe> simpler ice negotiation, we do that later. But the syntax
[04:47:27] <scribe> on the wire is actually the ice SDP. And if we need a flag
[04:47:31] <scribe> that says, just don't do the negotiation or do the simpler one, we do that later. NEW SPEAKER:
[04:47:33] <scribe> I see. So --
[04:47:37] <scribe> NEW SPEAKER: So that way, we avoid the xwoot strap
[04:47:40] <scribe> problem of how do we move forward right away with if NEW SPEAKER: NEW SPEAKER:
[04:47:42] <scribe> (Several people talking.) NEW SPEAKER: Let me
[04:47:44] <scribe> summarize. You're proposing that this topic of what, you
[04:47:50] <scribe> know, and another ice type, ice, you know, extra medium
[04:47:55] <scribe> or something. We could spec that later, not put it in the
[04:47:58] <scribe> core ice spec as a new mode that was backward compatibe with ice
[04:48:02] <scribe> and ice light. If we find the checks are not necessary in
[04:48:04] <scribe> this condition. NEW SPEAKER: But but NEW SPEAKER:
[04:48:08] <scribe> But basically say we proceed with ice and deprecate ANAT
[04:48:10] <scribe> today. NEW SPEAKER: We can take an MMusic look, in 20
[04:48:15] <scribe> years when everybody is transitioned to v6 and turned off their
[04:48:19] <scribe> fire walls, we'll try and come up with the transition spec.
[04:48:24] <scribe> Maybe it's 20 2K 5. NEW SPEAKER: 27. NEW SPEAKER:
[04:48:31] <scribe> Yes, we also need to wait then until people have removed, you
[04:48:36] <scribe> know, thinking in the nat case or things like that. It's not
[04:48:42] <scribe> only for ice, it's regarding R T P six and anything else. But that's
[04:48:45] <scribe> also going to take a while. That's not going to happen just
[04:48:50] <scribe> because we deprecate ANAT. So the question is not, I only need
[04:48:54] <scribe> ANAT today because ANAT maybe the only thing that works today.
[04:48:58] <scribe> So I mean, and then, you deprecate that, and that I think
[04:49:03] <scribe> then there's the risk that people will start doing, you know
[04:49:06] --- mayumi has left
[04:49:07] <scribe> high priority things, which means that ice or anything is
[04:49:08] <scribe> never going to be Dee employed.
[04:49:12] <scribe> So I think we need to look at it from that perspective. NEW SPEAKER:
[04:49:14] <scribe> I didn't understand the point you're making. NEW SPEAKER:
[04:49:19] <scribe> What I say, you may have architectures and something where ice
[04:49:22] <scribe> doesn't work because you have gates. NEW SPEAKER:
[04:49:24] <scribe> Okay. Let me make sure I understand. I think this is the
[04:49:27] <scribe> point but I'm not clear what you say, when you say gates is
[04:49:31] <scribe> what you think I mean. You are concerned about fire walls
[04:49:35] <scribe> that pass R T P but drop sdun even though the IP address and
[04:49:39] <scribe> ports are all the same because they do Dee packet inspection. NEW SPEAKER:
[04:49:43] <scribe> That's one scenario. It can also be that it does, I
[04:49:49] <scribe> mean, that it does it at a certain point. If you get a 200
[04:49:52] <scribe> okay, at that point the gates are open. You can (Several people talking.) NEW SPEAKER:
[04:49:58] <scribe> So we'll have U As that don't, you know, that don't open gates,
[04:50:00] <scribe> because that's what it is, it's a SIP inspecting
[04:50:05] <scribe> E intermediary that blocks all R T P traffic and doesn't
[04:50:10] <scribe> support ice until the 200 okay. So any technique that
[04:50:14] <scribe> assumes that ice, that SIP flows work only, wonlt
[04:50:17] <scribe> work. NEW SPEAKER: I think he's talking about packet cable NEW SPEAKER:
[04:50:21] <scribe> So my view on those things is, this is the pain you get when
[04:50:25] <scribe> you put A L Gs and something else in the network. They
[04:50:26] <scribe> have to fix these. NEW SPEAKER: Okay. (Several people
[04:50:28] --- mayumi has joined
[04:50:30] <scribe> talking.) NEW SPEAKER: I'm not going to block the entire process
[04:50:34] <scribe> because you're worried about A L Gs, we've not done that. That's what you're talking
[04:50:36] <scribe> about ment NEW SPEAKER: Okay. I'm just saying that
[04:50:40] <scribe> there's a real world outside there, and that's not going to change
[04:50:42] <scribe> overnight because we, you know, make a decision to
[04:50:46] <scribe> deprecate an RFC. Unfortunately.
[04:50:49] <scribe> NEW SPEAKER: The point was made. We would appreciate it
[04:50:52] <scribe> if people are concise, otherwise I'm going -- the mic was cut
[04:50:56] <scribe> already. So I will give Flemming 30 seconds because I know
[04:50:59] <scribe> he's going to answer to the previous comment. But anyway be very
[04:51:02] <scribe> concise to the point and we're going to wrap up very seen. NEW SPEAKER:
[04:51:06] <scribe> I actually went through the whole thread last night, trying to
[04:51:11] <scribe> be neutral and really look at both both sides and my feeling is
[04:51:14] <scribe> the following, NEW SPEAKER: What started this
[04:51:18] <scribe> discussion is the discussion that ANAT is not widely deployed today.
[04:51:21] <scribe> It may be implemented,
[04:51:28] <scribe> NEW SPEAKER: How ANAT and ice co-exist or co-slide. And
[04:51:31] <scribe> basically, I think what company we work with. What we have
[04:51:35] <scribe> to serve here, is the community of implementers that do not
[04:51:39] <scribe> make any assumption on how their implementation is gk to be
[04:51:42] <scribe> deployed. If you think about it, you know, you can imagine
[04:51:46] <scribe> during an enterprise as we've seen on the list, and you don't
[04:51:50] <scribe> have a problem. Right. Your phones work with X Y Z but the
[04:51:55] <scribe> bottom line is we don't serve enterprises and service
[04:51:57] <scribe> providers. We have to think about end users that has to work
[04:51:57] <scribe> anywhere.
[04:52:01] <scribe> And then, the people who are taking positions on one side or
[04:52:04] <scribe> the other are making assumptions on whether it's just okay to
[04:52:08] <scribe> advertise that you support a dual stack device, we're using
[04:52:11] <scribe> ANAT and that's going to be sufficient for you or whether you have to
[04:52:16] <scribe> have connectivity checks. Which is ultimately important in
[04:52:20] <scribe> this debate. If we let both options co-exist, quhaes going
[04:52:23] <scribe> to happen is, for the implementers we need to serve, we're going to
[04:52:27] <scribe> have have both ANAT and ice. I think we have consensus that this
[04:52:28] <scribe> is the worst option.
[04:52:33] <scribe> So I think I'm very much in favor of having strong guidance of
[04:52:36] <scribe> deprecating ANATs. And going
[04:52:40] <scribe> with one choice today, and actually in ice, resolving this now,
[04:52:43] <scribe> rather than later. NEW SPEAKER: Okay. Thank you.
[04:52:50] <scribe> NEW SPEAKER: Caplan again. By the way, it's a
[04:52:54] <scribe> misconception that S B C something about nat traversal.
[04:53:00] <scribe> Anyway. I want to make two points. Now of
[04:53:01] <scribe> course I forget what they were.
[04:53:05] <scribe> One is that I thought that deprecating ANAT
[04:53:12] <scribe> or not, why does that hold up by moving forward? If your
[04:53:14] <scribe> deadline goal NEW SPEAKER: Right. NEW SPEAKER: (Several people talking.) NEW SPEAKER:
[04:53:17] <scribe> I explaind that. So, it's because
[04:53:20] <scribe> today, something needs to explain how ice works with ANAT.
[04:53:25] <scribe> Today ice has a section that describes how it works with ANAT.
[04:53:30] <scribe> Today ice describes both cases where there's v6 V 4 and no
[04:53:34] <scribe> ANAT and where you have it split across ANAT. An implementer
[04:53:38] <scribe> with that document alone will not produce specs that
[04:53:40] <scribe> inter operate. NEW SPEAKER: One point, we don't have
[04:53:45] <scribe> to explain why we want to make a decision today. We need to explain
[04:53:50] <scribe> why we cannot make the decision today. What is going to change
[04:53:52] <scribe> that's going to make this decision easier in one day or one
[04:53:55] <scribe> month. (Several people talking.) NEW SPEAKER: I
[04:53:57] <scribe> thought you were concerned about today's deadline, getting
[04:53:59] <scribe> this over with so we can get ice to move forward. NEW SPEAKER: We
[04:54:02] <scribe> are concerned not the delaying things just because we
[04:54:04] <scribe> like to delay things. NEW SPEAKER: Absolutely. (Several people
[04:54:06] <scribe> talking.) NEW SPEAKER: I agree with that. I'm not can dash NEW SPEAKER:
[04:54:11] <scribe> So please go to the second point. NEW SPEAKER: Right. I
[04:54:17] <scribe> totally understand what, you know, the motivation is to
[04:54:22] <scribe> push ice forward, the singular model for this to work. The
[04:54:27] <scribe> thing that concerns me is that if we focus on that as the only
[04:54:30] <scribe> model that works and it doesn't succeed in the marketplace,
[04:54:33] <scribe> which has happened many times in this working group and others in the
[04:54:36] <scribe> IETF, then there is no alternative. NEW SPEAKER:
[04:54:38] <scribe> We'll spec one when that happens. We have that all the time. NEW SPEAKER:
[04:54:42] <scribe> It's not a good idea to just start with 5 alternatives.
[04:54:47] <scribe> Okay, I'm going to buy 5 tickets and one will succeed.
[04:54:49] <scribe> That's not the way to work here.
[04:54:52] <scribe> NEW SPEAKER: That's actually the way the IETF works. NEW SPEAKER:
[04:54:54] <scribe> Sometimes. NEW SPEAKER: We're specifying this because
[04:54:56] <scribe> we believe ice is st right way to go (Several people
[04:54:57] <scribe> talking.)
[04:54:59] <scribe> NEW SPEAKER: This is not the right approach, then we
[04:55:02] <scribe> should just throw it away now and do something else. If the market
[04:55:05] <scribe> decides we're wrong, well, try and fix it later. NEW SPEAKER:
[04:55:09] <scribe> Okay. NEW SPEAKER: But if we believe we're wrong now,
[04:55:12] <scribe> we shouldn't standardize ice. We should do things completely different.
[04:55:15] <scribe> NEW SPEAKER: You have 30 seconds. Remember. NEW SPEAKER:
[04:55:19] <scribe> Flemming. So, just responding to Francois's
[04:55:23] <scribe> comments. I think if we choose ice and I think that's a reasonable
[04:55:27] <scribe> choice, we should be because we sign up for wanting to use
[04:55:30] <scribe> connectivity checks. If we don't want to do connectivity checks then I don't
[04:55:33] <scribe> think we should be getting into the ice business, and
[04:55:36] <scribe> modifying syntax and all that. I think we have no benefit
[04:55:40] <scribe> snoochlt right. I'll make one further point that hasn't been
[04:55:43] <scribe> raised which is that ice also talks about ice helps
[04:55:46] <scribe> the voice handling packet. Which is not often thought
[04:55:51] <scribe> about, but a big issue. And so even if you don't care about natural tra
[04:55:55] <scribe> scers sa, that's another bit. NEW SPEAKER: Yes. That's why
[04:55:59] <scribe> actually some people were claiming in IP v6 you will have other
[04:56:03] <scribe> mechanisms to do that, and that was actually what started all
[04:56:04] <scribe> the discussion. But yes, that's important. You need
[04:56:08] <scribe> anyway. Having mechanisms to do return route ability checks
[04:56:12] <scribe> and other set of things that ice actually, well, basically includes all
[04:56:14] <scribe> of that.
[04:56:18] <scribe> So at this point be, I guess the MMusic chairs would like to
[04:56:29] <scribe> wrap up and take a hum. NEW SPEAKER:
[04:56:31] <scribe> NEW SPEAKER: Do you want me to explain the choices?
[04:56:40] <scribe> NEW SPEAKER: So the hums at the moment that I'm putting on
[04:56:45] <scribe> the table, option one, is we make the following two
[04:56:49] <scribe> changes, the V four, v6 SIPPING document will be retrieved and
[04:56:52] <scribe> will document ice in the transition technique and will either say nothing about
[04:56:58] <scribe> ANAT or not use it. And ice itself deposition indicates ANAT
[04:57:02] <scribe> and the section on ice and ANAT disappears and a little bit of text
[04:57:06] <scribe> goes in there to say if you're dual stacked, you list what's more or
[04:57:10] <scribe> less there, but just to clarify, you would use this for the
[04:57:12] <scribe> dual stack case. NEW SPEAKER: Just a clarification,
[04:57:17] <scribe> sorry. John Elwell. Would the modification that Francois
[04:57:20] <scribe> suggested, that we do dash NEW SPEAKER: That's why I
[04:57:24] <scribe> said, we can decide whether or not we want a stall tactic of
[04:57:26] <scribe> the documentation process, but that would only involve
[04:57:31] <scribe> waiting for V 4 v6 to point to ANAT ice and say don't do that,
[04:57:37] <scribe> do that. I mean, v6 V 4 is ahead of ice. In the process
[04:57:40] <scribe> of you're only buying a couple of weeks. I'd rather not take
[04:57:44] <scribe> that approach if we can actually get consensus on one of these today.
[04:57:49] <scribe> Option two. Is the V 4 v6 document uses ANAT as a transition
[04:57:52] <scribe> technique, as it can does today. So we have no change.
[04:57:56] <scribe> Unless we think we need to bring ANAT back to fix the
[04:58:00] <scribe> 3484 problem and ice describes usage with ANAT, and again,
[04:58:05] <scribe> may need to retrieve ANAT and revise, NEW SPEAKER: I
[04:58:09] <scribe> just want to clarify this question. So, the thing I was
[04:58:11] <scribe> proposing is actually to do one today. NEW SPEAKER: I
[04:58:14] <scribe> understand that. NEW SPEAKER: And later on, if we
[04:58:17] <scribe> figure out that maybe that's not optimal, we can work on it.
[04:58:19] <scribe> But we don't need to hum on anything for that today. I don't
[04:58:22] <scribe> think we can. NEW SPEAKER: Right. So there is a
[04:58:25] <scribe> third option that I hinted but would rather not do, that is a
[04:58:28] <scribe> document hack for two weeks more time. I don't want to do
[04:58:34] <scribe> that. That wasn't what Francois was propose. Does anyone have
[04:58:39] <scribe> any questions on the hums or can we amend the hums?
[04:58:41] <scribe> Everybody is good with these hum questions? NEW SPEAKER:
[04:58:51] <scribe> Okay. So we have two hums here. So please intensely and
[04:58:55] <scribe> strongly so we get everybody same volume so we get roughly a
[04:58:58] <scribe> reasonable sense in the sense that might be tricky here.
[04:59:03] <scribe> So if you are in favor of, if you do want to see things happen
[04:59:10] <scribe> as option No. 1, going with ice only, sdep indicating
[04:59:11] <scribe> ANAT, please hum now.
[04:59:13] <scribe> ( Deprecating ANAT.)
[04:59:16] <scribe> ( Humming. ) NEW SPEAKER: That's a good start. If
[04:59:22] <scribe> you want to go with option No. 2, declaring ANAT as
[04:59:28] <scribe> transition and ice ascribing usage, together with ANAT,
[04:59:29] <scribe> please hum now.
[04:59:33] <scribe> ( Humming. ) NEW SPEAKER: I guess we have consensus.
[04:59:36] <scribe> It's a bit rough, but it's fairly clear. So please note,
[04:59:40] <scribe> we're going with option No. 1. NEW SPEAKER: Okay.
[04:59:42] <scribe> Wow, we are done. NEW SPEAKER: Did you get that
[04:59:46] <scribe> Spencer, I mean, note taker? NEW SPEAKER: Yes. So
[04:59:48] <scribe> rough Ken sus says to go for option one. NEW SPEAKER:
[04:59:56] <scribe> Okay. NEW SPEAKER: Thank you. One thing, just while we can
[05:00:00] <scribe> actually get ready to present that, concerns me a little bit.
[05:00:04] <scribe> We were discussing these issues on the mailing list, on the MMusic
[05:00:06] <scribe> mailing list for a long while. And then as soon as we
[05:00:10] <scribe> brought it up to SIPPING, it seems that many people they are
[05:00:14] <scribe> not even subscribed to MMusic, they may not, you know -- NEW SPEAKER:
[05:00:20] <scribe> Let me, this is why we have meetings Gonzalo, s so to get people
[05:00:22] <scribe> thinking and talking about the topics. NEW SPEAKER: What
[05:00:25] <scribe> I'm saying, if you are inltd in SIP, just be aware that
[05:00:28] <scribe> MMusic does things that relate to SIP very much on the session description
[05:00:31] <scribe> protocol. And if you are concerned about that, please subscribe
[05:00:35] <scribe> to MMusic and follow discussions there. That was my only
[05:00:40] <scribe> point. NEW SPEAKER: Yes, Cullen maybe
[05:00:45] <scribe> wants to add something. NEW SPEAKER: So, Cullen
[05:00:50] <scribe> Perkins, just following up, looking at the MMusic mailing list, I
[05:00:54] <scribe> had to approve about three quarters of those messages so people
[05:00:58] <scribe> would not subscribe to it. MMusic does stuff which directly
[05:01:01] <scribe> impacts SIP. If you're interested in SIP, come to
[05:01:04] <scribe> SIPPING, you need to be on the MMusic list too, and be
[05:01:07] <scribe> reviewing the documents with those. NEW SPEAKER: That
[05:01:10] <scribe> was the point. Because then we have these late surprises,
[05:01:12] <scribe> and it's not nice. NEW SPEAKER: Well, I also want to
[05:01:16] <scribe> highlight to folks we get so much spam and other garbage on these
[05:01:22] <scribe> mailing lists that it's often difficult to see the real stuff to
[05:01:25] <scribe> get through. NEW SPEAKER: So, please. NEW SPEAKER:
[05:01:28] <scribe> Okay. So, can you hear me?
[05:01:34] <scribe> NEW SPEAKER: No. NEW SPEAKER: All right. Now,
[05:01:40] <scribe> so this is what the associated drafts. Three drafts.
[05:01:44] <scribe> Everything started like mechanism for file directory with SIP.
[05:01:45] --- jonlennox has left
[05:01:47] <scribe> All right. So, s here's a history. About this. I'm
[05:01:53] <scribe> sorry these links are, I think it is a little bit hard to
[05:01:56] <scribe> read. But anyway, the point is that, we have in all
[05:02:00] <scribe> these communications suites mechanism that allows
[05:02:05] <scribe> file transfer, you know, like all the messages and stuff allows me
[05:02:08] <scribe> to transfer files to the other person and communicating with.
[05:02:13] <scribe> We had some requirements recommended in SIPPING file transfer
[05:02:17] <scribe> document, and there is ongoing work in the MMusic about offer
[05:02:21] <scribe> answer mechanism for enabling file transfer.
[05:02:27] <scribe> So, this discussion is about this, so the draft allows me to
[05:02:30] <scribe> enable a few of the use cases that we are thinking of are
[05:02:35] <scribe> needed, and they are namely collectively called resource
[05:02:36] <scribe> sharing documents. Next slide.
[05:02:44] <scribe> So, the file transfer document that is going in MMusic allows me
[05:02:48] <scribe> to do operation where I can send an invite to, and Alice
[05:02:53] <scribe> sends invite to Bob and standards SDP describes the file that is
[05:02:57] <scribe> going to be sent. There's a Bob here, is presented with
[05:03:03] <scribe> the offer, and he accepts. And there's a 200
[05:03:06] <scribe> okay, with the SDP that describes the file to be received and
[05:03:09] <scribe> then there is MSR P there that includes the file that is
[05:03:11] <scribe> actually transferred.
[05:03:16] <scribe> That's the push operation. A is sending a file to B. Next
[05:03:16] <scribe> slide.
[05:03:21] <scribe> The file transfer allows me also to do a pull operation. Which
[05:03:26] <scribe> is the opposite. Alice sends an invite to Bob.
[05:03:32] <scribe> With the SDP describes the file to be received, the user,
[05:03:36] <scribe> Bob, is presented with the offerer, and he can accept or
[05:03:39] <scribe> deny the file transfer, assuming everything goes okay,
[05:03:46] <scribe> there's 200 okay, with the SDP coming back. And the MSR P
[05:03:51] <scribe> send from Bob to Alice. Next one.
[05:03:55] <scribe> Now, here's the problem. How can Alice know what is the
[05:03:59] <scribe> description of the file that wants to pull from Bob.
[05:04:03] <scribe> We don't have any mechanism from that. The file transfer lab says,
[05:04:08] <scribe> if you know the something file, if you know the file name, that
[05:04:13] <scribe> happens to be stored in this end poyntd, and there is another
[05:04:17] <scribe> information, but we don't have any mechanism for that. So we
[05:04:21] <scribe> start working on that. We can go to the next slide. And
[05:04:27] <scribe> come out of this concept of re solves event package that is
[05:04:32] <scribe> basically the mechanism where we can use the sub is describe
[05:04:39] <scribe> the file to publish, to one side to do publication of
[05:04:46] <scribe> resources, to the com possible ter. and com possible
[05:04:50] <scribe> sit tore. And the other side to do subscriptions and
[05:04:56] <scribe> notifications of X M L documents to describe fines and end
[05:04:56] <scribe> points here.
[05:05:02] <scribe> At this point, we studied as a file, file thing, but we
[05:05:06] <scribe> came up with something a little bit generic that basically
[05:05:10] <scribe> enables to describe any resource. So this can be used for
[05:05:13] <scribe> instance, for describing printers that are locally connected
[05:05:14] --- thomas.stach has left
[05:05:19] <scribe> here or any other kind of things. So, I could have, I could be
[05:05:23] <scribe> hosting a chat room here for example, in one of these end
[05:05:25] <scribe> points, and be announcing that.
[05:05:31] <scribe> Into the other, you know, to community, what wre call here.
[05:05:35] <scribe> Go to the next slide. This is just to show that this can be
[05:05:39] <scribe> used end to end. There's no really, we actually thought,
[05:05:43] <scribe> there's some sort of interesting use cases there where you
[05:05:50] <scribe> could be describing a file, let's say by its hash, and
[05:05:54] <scribe> pushing it to a V H D or something like that. So this can be
[05:06:00] <scribe> used also end to end, yes. Without any com possible ter.
[05:06:03] <scribe> Composite ter.
[05:06:08] <scribe> We got comments sometime ago, like some people
[05:06:13] <scribe> I was speaking here in some previous IETF meetings, okay,
[05:06:16] <scribe> why don't you do this with presence.
[05:06:20] <scribe> So not that I'm really Complaints, but on
[05:06:24] <scribe> the list we explore a little bit this. It could be fairly
[05:06:28] <scribe> simple to add an extension to the P header, to the, you
[05:06:34] <scribe> know, the model, device, part of the it, and another
[05:06:37] <scribe> description of resources that can be available at some end
[05:06:41] <scribe> points so that's fairly simple information, if it is needed.
[05:06:44] <scribe> I mean, this is interesting use cases where I could be
[05:06:48] <scribe> prubling my presence information, and
[05:06:51] <scribe> ( Publishing my presence information and through authorization
[05:06:54] <scribe> rules, you know, allowing some people to see
[05:06:58] <scribe> some of the files that I'm storing my carry forward and things
[05:06:59] <scribe> like that.) Next slide.
[05:07:03] <scribe> So, on this, probably some people is going to ask, I
[05:07:07] <scribe> mean, the first thing is we need to ask, is why are we using
[05:07:12] <scribe> SIP at all? And we had some discussion yesterday, with
[05:07:18] <scribe> Henning in the simple meeting. One of the things that is
[05:07:22] <scribe> interesting, if we start enabling these use cases
[05:07:29] <scribe> with SIP, we have passed like 5 betters of the pain.
[05:07:31] <scribe> Authentication, authorization, rules, we have
[05:07:34] <scribe> conversation, we have notification, we have a lot of stuff
[05:07:38] <scribe> done. If you start looking at some of the protocols
[05:07:42] <scribe> then you need to go through all the steps one by Juan, enabling
[05:07:45] <scribe> one by Juan one.
[05:07:48] <scribe> NEW SPEAKER: Just go on. NEW SPEAKER: All right.
[05:07:57] <scribe> I have here a description of the X M L document that we
[05:08:02] <scribe> propose in one of the drafts where this is collection of
[05:08:03] --- hbaosiy has left: Replaced by new connection
[05:08:07] <scribe> resources, each resource contains one part which is like the
[05:08:10] <scribe> identity of the resource, another could be for example, we'll
[05:08:16] <scribe> say the hash out the file, or MIME type, size, some real
[05:08:22] <scribe> identifier of the resource. And there's an instance part
[05:08:27] <scribe> which is small and mostly describes which is the end point or SIP
[05:08:32] <scribe> URI with a user and cause, could be like a GRUU, and it is
[05:08:35] --- hbaosiy has joined
[05:08:36] <scribe> hosting that particular instance of the resource
[05:08:40] <scribe> So it could be for example, we think again, in our files,
[05:08:43] <scribe> one given file can be sdord in several end points
[05:08:47] <scribe> because it has been some file transfer, and something that I
[05:08:51] <scribe> mentioned that I already transfer to some friends
[05:08:53] <scribe> and things like that. So the MIME type, the hash of the
[05:08:57] <scribe> file is going to be perm nanlt no matter whether they're
[05:09:01] <scribe> storing my end points or some other end points and
[05:09:03] <scribe> the instance parallel described, like the GRUU where this is
[05:09:08] <scribe> stored and some other meta data like key words or names or something like
[05:09:09] <scribe> that.
[05:09:15] <scribe> Next slide. This is just an example of X M L document. I
[05:09:18] <scribe> think it's very unread able but you can fetch it from the
[05:09:18] <scribe> slides.
[05:09:24] <scribe> And there's three documents here, now, there's a framework for
[05:09:29] <scribe> sharing resources, with SIP, this is an entire collection of use
[05:09:36] <scribe> cases it is just an example of things that we like to work on. It should
[05:09:40] <scribe> really be identity framework, but at the moment it's an
[05:09:43] <scribe> exploration document of use cases and try to collect
[05:09:44] <scribe> requirements and so on.
[05:09:49] <scribe> There is an event package and data format for describing the
[05:09:55] <scribe> resources, which is the resource event package. I want to
[05:09:58] <scribe> mention on the identifications of
[05:10:02] <scribe> it, you can fetch it through the link there. And there is
[05:10:06] <scribe> an extension to the P dip torrey source descriptions.
[05:10:15] <scribe> Okay. So here's the big question. So, this draft have
[05:10:18] <scribe> been there for some time, maybe six months something like
[05:10:21] <scribe> that. So, is there enough interest to, you know,
[05:10:28] <scribe> pursue and study the use cases that we want to do and study a
[05:10:31] <scribe> little bit further the documentation? I mean, the kind of
[05:10:32] --- hbaosiy has left: Replaced by new connection
[05:10:34] <scribe> high level things that we would like to do, is there enough interest?
[05:10:38] <scribe> I think this is the thing that we like to question at this
[05:10:43] <scribe> stage. Or this is something horrendous that we shouldn't be
[05:10:46] <scribe> contaminating SIP with this kind of evil ideas?
[05:10:48] <scribe> ( Laughter.)
[05:10:54] <scribe> NEW SPEAKER: I see you run to the mic.
[05:10:57] <scribe> NEW SPEAKER: Let's go ahead and let them talk. NEW SPEAKER:
[05:11:03] <scribe> Okay. Two quick remarks. One is I'll just advertise,
[05:11:08] <scribe> we, I set up a mailing list last night and I announced to the
[05:11:13] <scribe> simple mailing list, the general notion of notification that is not
[05:11:17] <scribe> directly tied to the classical use of SIP events.
[05:11:19] <scribe> See where the discussion goes. If you're interested sign up
[05:11:24] --- hbaosiy has joined
[05:11:24] <scribe> on the mailing list and we can see if this is either trivial,
[05:11:26] <scribe> bad, needs a behalf, whatever the case may be.
[05:11:30] <scribe> NEW SPEAKER: I want to interrupt on that topic and then
[05:11:32] <scribe> I'll let you carry on.
[05:11:39] <scribe> The aps area is also very interested in some generic a sin conk
[05:11:42] <scribe> nus notification tough. And we'll probably need to
[05:11:48] <scribe> synchronize with them. To work with the APs group. There's been
[05:11:50] <scribe> about 5 topics on the mailing list. NEW SPEAKER:
[05:11:52] <scribe> (Several people talking.) NEW SPEAKER: I'm glad to see
[05:11:55] <scribe> some inlt here. NEW SPEAKER: Maybe we can talk about
[05:11:58] <scribe> this, a little bit of time. NEW SPEAKER: Go ahead. NEW SPEAKER:
[05:12:01] <scribe> Basically, do we need to set up, you know, to have a
[05:12:04] <scribe> discussion in SIP mailing list to avoid spaming those
[05:12:08] <scribe> who are not interested in this topic? Or is it -- NEW SPEAKER:
[05:12:14] <scribe> I, you know, your drafts, or SIPPING drafts can be sus
[05:12:17] <scribe> discussed on the SIPPING mailing list right now. And anyone
[05:12:20] <scribe> can set up a mailing list to gather inlt on some things.
[05:12:24] <scribe> What I'm going to try and do is work towards consolidating
[05:12:27] <scribe> interests in common. NEW SPEAKER: Right. Because you
[05:12:30] <scribe> don't want different groups out too far. NEW SPEAKER: I
[05:12:32] <scribe> can't solve this right now, right here. NEW SPEAKER:
[05:12:35] <scribe> It would be good if you can send some pointers, (Several people
[05:12:36] <scribe> talking.) NEW SPEAKER: I'll send pointers. NEW SPEAKER:
[05:12:40] <scribe> There's a lot of discussion on the SIPPING list which is not
[05:12:43] <scribe> relevant to that, and vice versa.
[05:12:47] <scribe> The other question, which is a more generic one and more specific
[05:12:52] <scribe> one to your particular proposal is, I'm a little concerned,
[05:12:56] <scribe> the kind of things, the properties that you're describing,
[05:13:00] <scribe> apply to things which naturally have a name, a date and size
[05:13:03] <scribe> of some sort. But I don't think that extending
[05:13:07] <scribe> the same set of meta data to all kinds of other
[05:13:12] <scribe> things, such aspirin terse or chat as, printers, chat
[05:13:16] <scribe> rooms, mace a lot of sense because they are different.
[05:13:19] <scribe> File and printers have different properties. I don't want to
[05:13:21] <scribe> have printer properties there.
[05:13:26] <scribe> dp you use I D F where you just push up the problem one level and you
[05:13:30] <scribe> have the same X M L and you have attributes which have your
[05:13:34] <scribe> real data types in them, and it's generic container format.
[05:13:37] <scribe> Or you have schemas, but kind of this hybrid which
[05:13:41] <scribe> tries to use the same data for very different things, which
[05:13:44] <scribe> have very different attributes, seems to be a
[05:13:46] <scribe> direction we don't need to or want to go to. NEW SPEAKER:
[05:13:51] <scribe> So, okay. Point taken. We thought that, we study as
[05:13:54] <scribe> file transfer or file description but we wanted to see if there's
[05:13:58] <scribe> possibilities to make it generic enough. If you think this is not the way to go
[05:14:00] <scribe> forward, I mean, dash NEW SPEAKER: That's (Several people talking.) NEW SPEAKER:
[05:14:06] <scribe> The whole idea is, not to do everything into generic tags which
[05:14:07] <scribe> are then
[05:14:09] <scribe> NEW SPEAKER: Right. NEW SPEAKER: Half of them
[05:14:12] <scribe> don't apply or apply only in a very weird way. NEW SPEAKER:
[05:14:16] <scribe> Right. NEW SPEAKER: Jason fishl. I was just
[05:14:21] <scribe> wondering whether it's worth considering using the MSR P
[05:14:24] <scribe> channel, rather than SIP to carry this sort of information?
[05:14:28] <scribe> Because I think running it, running all of
[05:14:31] <scribe> these events, all these notifications through all of
[05:14:34] <scribe> the, you know, through the proxies of all records routes
[05:14:38] <scribe> seems like a lot of overhead. You've -- NEW SPEAKER: We
[05:14:41] <scribe> don't have subscription notification mechanism with MSR P and
[05:14:50] <scribe> user name. On the immediate channels. NEW SPEAKER:
[05:14:53] <scribe> All notifications are MSR P. NEW SPEAKER: So, this is not
[05:14:56] <scribe> evil, but I think this steps over the line. And you know,
[05:15:00] <scribe> the line that goes for SIP authors, that extensions describes
[05:15:05] <scribe> is communication services and setting up streams whose purposes
[05:15:08] <scribe> are still communications. File transfer is clearly in
[05:15:10] <scribe> scope, as we've done, because we see that all the time.
[05:15:17] <scribe> That's a well understood concept between the traversal to send data.
[05:15:21] <scribe> But to start to turn SIP into MS G 5 whatever it is, I don't
[05:15:22] <scribe> see the benefit.
[05:15:25] <scribe> I could be convinced that a natural part of the communication
[05:15:29] <scribe> between users is showing my hard drive as a remote file system,
[05:15:35] <scribe> then you could just run N F S as a media stream between end
[05:15:38] <scribe> points, that's an arguably reasonable perhaps limited use of
[05:15:42] <scribe> SIP. If you're worried about nat traversal and all that, we
[05:15:45] <scribe> have a lot of techniques to solve that problem. But I don't
[05:15:48] <scribe> think it makes sense to build an entire file system and
[05:15:51] <scribe> directory structure within SIP context. It's not worth it. NEW SPEAKER:
[05:15:56] <scribe> I have to disagree with Jonathan to some extent. The
[05:16:01] <scribe> problem that we see, we actually build a non SIP system for
[05:16:04] <scribe> something very similar is that files change. You have a
[05:16:07] <scribe> small group collaboration for example, somebody up loads a new
[05:16:14] <scribe> slide, power point file, and the N F S structure doesn't
[05:16:17] <scribe> works. Event notification is exactly what you want. NEW SPEAKER:
[05:16:21] <scribe> Exactly. This is what we have run through. The typical use
[05:16:24] <scribe> case is that they have, I take a picture with my camera phone
[05:16:27] <scribe> and then I announce it to my set of friends and
[05:16:31] <scribe> then, you know, minutes later I edit the file and I took,
[05:16:34] <scribe> I red eye with action, and then the file is different, and you
[05:16:38] <scribe> know, I want to, you know, so we have sufficient
[05:16:41] <scribe> notification with SIP. We can dash NEW SPEAKER: That's
[05:16:44] <scribe> two separate questions, which I'd like to keep separate.
[05:16:48] <scribe> Event notification is the right model and whether
[05:16:52] <scribe> extending SIP to non directory communication events
[05:16:56] <scribe> makes sense. And the second part is one where we can argue
[05:17:00] <scribe> as to scope and properties, which seems to be, one seems to
[05:17:03] <scribe> be, for whatever, fivl solve Cal reasons, we don't want
[05:17:08] <scribe> it outside and there might be actual protocol, mechanical
[05:17:11] <scribe> notification, size of notification, security properties, naming
[05:17:15] <scribe> properties, which may make it inadvice able, but that's a
[05:17:19] <scribe> separate discussion. That we have after we decide event notification.
[05:17:26] <scribe> If they don't make sense, we can save ourselves the second NEW SPEAKER:
[05:17:30] <scribe> We're going to have to continued the discussion on the list
[05:17:33] <scribe> with this topic. NEW SPEAKER: I'm having trouble
[05:17:37] <scribe> fitting this, to the event framework, because whether it's
[05:17:44] <scribe> suitable for an event framework at all. I think, if I view
[05:17:46] <scribe> this as, what you're doing is subscribing
[05:17:51] <scribe> to like a file system, to find out, you know, what's
[05:17:54] <scribe> there, how many systems are going to want to support this
[05:17:59] <scribe> kind of event driven file report on every time it exchanges any
[05:18:04] <scribe> file? You know, maybe if this was restricted to some, if it's
[05:18:08] <scribe> not the file system, it's some restricted set of stuff -- NEW SPEAKER:
[05:18:10] <scribe> It is (Several people talking.) NEW SPEAKER: I
[05:18:13] <scribe> mean, I I don't want to subscribe to the entire file system.
[05:18:16] <scribe> I want to subscribe to certain, call it directories, or
[05:18:19] <scribe> whatever I'm authorized to see the con tenlt, yes, that's
[05:18:23] <scribe> why, you know, if it's not naturally my opinion into
[05:18:27] <scribe> anything that where we have halfway into do optimization
[05:18:31] --- marc.bailly has left
[05:18:32] <scribe> policies for who can see and do what, NEW SPEAKER: Well,
[05:18:34] <scribe> I mean, even if the file system is filterd by
[05:18:39] <scribe> the set of something, it's still NEW SPEAKER: It's
[05:18:41] <scribe> typically a sharing directory. NEW SPEAKER:
[05:18:43] <scribe> (Several people talking.) NEW SPEAKER: It seems like it's
[05:18:46] <scribe> not a sharing directory anymore. Well, it's a whole special
[05:18:51] <scribe> thing. NEW SPEAKER: All right. NEW SPEAKER: I don't
[05:18:56] <scribe> know. It's a fine line. NEW SPEAKER: All right.
[05:18:56] <scribe> Q.
[05:19:01] <scribe> Just to comment that we have implemented a very similar procedure
[05:19:05] <scribe> based on SIP to debate and remote cameras and
[05:19:10] <scribe> printers and to learn their state, and we are interested in
[05:19:12] <scribe> this kind of ideas.
[05:19:15] <scribe> NEW SPEAKER: You have something similar. NEW SPEAKER:
[05:19:21] <scribe> Yes. Based on SIP. NEW SPEAKER: Okay. Dean? NEW SPEAKER:
[05:19:27] <scribe> It strikes me, Dean Willis here. It strikes me that we might
[05:19:30] <scribe> be talking about something that's fairly similar in nature to
[05:19:33] <scribe> something you can do with R S S, and it might be interesting to
[05:19:40] <scribe> have an event package that notifies you about changes and R S
[05:19:45] <scribe> S. NEW SPEAKER: When you say, EKR commented on the list
[05:19:48] <scribe> something like that.
[05:19:52] <scribe> NEW SPEAKER: Either we are re in venting the
[05:19:56] <scribe> wheel or there's a generic model slightly around the corner
[05:19:58] <scribe> from where we are. NEW SPEAKER: So I guess the
[05:20:01] <scribe> conclusion we've heard a lot of opinions, and I guess can you
[05:20:06] <scribe> want on say something Cullen? NEW SPEAKER: Yes. I
[05:20:10] <scribe> think we, this is, we're suddenly discussing a bunch of
[05:20:13] <scribe> things where it sounds, that were aps issues,
[05:20:16] <scribe> basically. I think the question we should be answering,
[05:20:20] <scribe> either who else we need doing talk to about this or how appropriate this
[05:20:24] <scribe> looks to be in SIP, and/or what part of this we feel
[05:20:25] <scribe> uncomfortable with this being in SIP is. NEW SPEAKER: Yes,
[05:20:28] <scribe> exactly, I was going to propose something along those lines,
[05:20:32] <scribe> actually. For the time being, s in the short term, you can
[05:20:37] <scribe> discuss that in the SIPPING mailing list and then we'll have
[05:20:42] <scribe> Cullen and henks to other groups doing something similar and
[05:20:45] <scribe> then get the proper way forward to discuss that. NEW SPEAKER:
[05:20:49] <scribe> Okay. Thanks. NEW SPEAKER: Sea, performance.
[05:20:53] <scribe> dairl. NEW SPEAKER: Darryl.
[05:21:08] <scribe> Okay. So what I want to talk about is actually the
[05:21:09] <scribe> advantages of ANAT over ice.
[05:21:12] <scribe> But
[05:21:17] <scribe> ( Laughter. ) NEW SPEAKER: So, no. About, my
[05:21:20] <scribe> name is dare rel. About 9 months ago, I
[05:21:25] <scribe> introduced a draft, called SIP performance metrics and over
[05:21:28] <scribe> the last 9 months, we kind of looked at the scope and looked
[05:21:32] <scribe> at what other working groups with doing within IETF and we
[05:21:35] <scribe> narrowedd the scope to focus on end to end
[05:21:36] <scribe> performance metrics.
[05:21:40] <scribe> Over this time I know I've been the author of this draft but I
[05:21:43] <scribe> wanted to acknowledge a number of people that have provided a
[05:21:47] <scribe> lot of good feedback in regards to the draft, and so, next.
[05:21:53] <scribe> Just kind of, you know, quickly, to you know reiterate the
[05:21:58] <scribe> value of this, what the draft really does, I have a number of
[05:22:00] <scribe> conversations, just over and over again, just
[05:22:03] <scribe> continues to occur between people, as they say, you know,
[05:22:06] <scribe> especially from a carrier perspective or service provider
[05:22:09] <scribe> perspective, or you know, really any type of environment where you
[05:22:12] <scribe> have multiple proxies, even in a lab environment, where you want
[05:22:17] <scribe> to test, you know, you want to test the throughput, or the
[05:22:23] <scribe> ability for an end box of how quickly your environment works to come
[05:22:25] <scribe> up with a common set of metrics.
[05:22:29] <scribe> Many people sit down in a room or sit at the table and say this
[05:22:33] <scribe> is how we do it or what we do. It doesn't mean the same thing.
[05:22:37] --- thomas.stach has joined
[05:22:37] <scribe> From a telephony perspective, even simple conversations, of you
[05:22:41] <scribe> know, post dial delay, which was originally defined I T T about
[05:22:45] <scribe> 721. And simply say, how do do that? How did you measure
[05:22:46] <scribe> that in SIP?
[05:22:49] <scribe> So this is really, this draft is one thing I wanltd to be
[05:22:53] <scribe> clear, it's specifically not about telling you a benchmark or
[05:23:00] <scribe> saying, you know, your session set up delay or session set
[05:23:04] <scribe> up delay has to be this certain amount of time frame. But more
[05:23:06] <scribe> specifically it gives a common set of metrics that everybody can
[05:23:10] <scribe> be talking to the same platform. Saying this is how we do it, and
[05:23:15] <scribe> really how you decide, what's good, bad, indifferent, is up to you.
[05:23:18] <scribe> So, just briefly to talk about the changes to the draft since
[05:23:23] <scribe> the last time that I talked about it. One is I had
[05:23:26] <scribe> a lot of questions that came back in regards to the terms I was
[05:23:30] <scribe> using throughout the draft so I took some time to really Dee fine the terms.
[05:23:36] <scribe> One of the terms was session, I added that. And of course, you
[05:23:40] <scribe> know, throughout a session request delay, session
[05:23:42] <scribe> disconnect delay and things like that. Really, it's to
[05:23:46] <scribe> talk about the specific aspect here, just to be clear, it's
[05:23:49] <scribe> measuring the signalling aspects. I know that session
[05:23:53] <scribe> from an aspect of SIP and defined in 3261 is about creating
[05:23:56] <scribe> sessions, tearing down sessions conclude dz sessions, requesting
[05:23:59] <scribe> them. This is really measuring the
[05:24:00] <scribe> signalling aspects much
[05:24:04] <scribe> Next is session establishment, what does that mean? And
[05:24:09] <scribe> really, it's, you know, it's the process in which
[05:24:13] <scribe> receiving back from the U A S that it got, the necessary things to
[05:24:15] <scribe> actually establish the session.
[05:24:23] <scribe> Next slide. Next was session set up. And this is really
[05:24:26] <scribe> just defining a set of messages, parameters necessary that are
[05:24:31] <scribe> directly associated with UAC requesting a session with the U A
[05:24:36] <scribe> S. RFC 3261 really describes that as the set of steps in
[05:24:37] <scribe> order to establish ringing.
[05:24:44] <scribe> Also, I had defined some time indications of like time begin
[05:24:50] <scribe> and time, I can't even remember, time start, time stop.
[05:24:53] <scribe> And one thing that I had done is, there have been a number of
[05:24:57] <scribe> conversations of when does it actually begin? when
[05:24:58] <scribe> do you begin to start the measurement?
[05:25:02] <scribe> I had originally said it was when the last bit leaves the
[05:25:06] <scribe> application, you know, as measurable biological, physical
[05:25:11] <scribe> interface. But someone made a good point, in I T U T
[05:25:16] <scribe> 721, it post selection delay it actually specifies the first
[05:25:19] <scribe> bit. So I wanted to align this to make sure it alliance with
[05:25:23] <scribe> other sfan ardz that have been recommended and I think the I T U
[05:25:26] <scribe> T E 721 has been around a long time.
[05:25:30] <scribe> Next, just an overview of the changes to the draft. One is
[05:25:33] <scribe> that I had specified a lot of, you know, an average as
[05:25:36] <scribe> being a quai to utilize a lot of the metrics.
[05:25:40] <scribe> Really, what I had done is, this is how you use this
[05:25:43] <scribe> metric. But really, it needs to be clear, it's just one of the
[05:25:46] <scribe> methods, one of the uses of those metrics. The other thing
[05:25:52] <scribe> is, I originally specified all the metrics be from the UAC
[05:25:54] <scribe> perspective. I mean, a lot of people want to be able to
[05:26:00] <scribe> measure things from U A S and UAC so I opened up the draft for
[05:26:00] <scribe> that capability.
[05:26:08] <scribe> I specifically wanted to, you know, add references into I T U T
[05:26:14] <scribe> 4 11 and E Dot 721 as my references within the draft and I
[05:26:15] <scribe> hadn't specified those.
[05:26:19] <scribe> The other thing is that, it's got to be clear that obviously, any
[05:26:24] --- mayumi has left
[05:26:24] <scribe> time that you are making a calculation based on a set of input
[05:26:27] <scribe> variables, is that the output variables are
[05:26:31] <scribe> directly related to the consistency or accuracy of the input
[05:26:33] <scribe> variables, that's important and I wanted to specify that.
[05:26:39] <scribe> As far as metrics changes, I won't really go through each one of
[05:26:42] <scribe> these, but one of the things that I had before was I had given
[05:26:43] --- ttfr has left
[05:26:49] <scribe> options around the output variable basically
[05:26:52] <scribe> seconds, milli seconds, what should it be
[05:26:56] <scribe> measured in and I wanted to specify specifically that I basically
[05:27:00] <scribe> decided that milli seconds was probably the best way, the reason
[05:27:03] <scribe> why is because it's really the least common, or the most
[05:27:08] <scribe> granular value for which you can then run, you know, change
[05:27:11] <scribe> that that to seconds or whatever you wanted to use, whatever makes
[05:27:11] <scribe> sense.
[05:27:16] <scribe> From registration request delay there was confusion, because my
[05:27:20] --- mayumi has joined
[05:27:21] <scribe> failed registration request delay had multiple 4 01s and
[05:27:25] <scribe> people said, isn't that normal, you almost always get one
[05:27:28] <scribe> because of the authentication request, or challenge, and that
[05:27:32] <scribe> is correct. What I then basically specified in there is because they
[05:27:36] <scribe> that was a very common header scenario is to
[05:27:39] <scribe> say, it's directly relative to the final response code. So
[05:27:43] <scribe> it's the find release causes 4 01 because you failed to be able
[05:27:44] <scribe> to authenticate, then you would use that.
[05:27:48] <scribe> Session request delay is similar and I just added the reference
[05:27:52] <scribe> again, that ties in I T U 721.
[05:27:59] <scribe> Again, session disconnect delay, similar to registration
[05:28:03] <scribe> requests delay. I did add back in average hops per invite.
[05:28:07] <scribe> That was, I was told that people were very interested in that
[05:28:10] <scribe> metric, and so it's back in and I'm going to leave it in,
[05:28:15] <scribe> not going to take it out again. Unless there's a mass an
[05:28:17] <scribe> nashing ee in regards to that.
[05:28:19] <scribe> ( An nashing key? Regards to that.) NEW SPEAKER:
[05:28:25] <scribe> Forking, how are the metrics impacted by forking
[05:28:28] <scribe> quns. So I added into the consideration on
[05:28:31] <scribe> forking. And how that, how the metrics would be impacted.
[05:28:35] <scribe> Obviously, if you have a client that forks the messages and you
[05:28:39] <scribe> are to try and utilize all the responses or all of the invites
[05:28:44] <scribe> went out, it would dramatically skew any type of average or
[05:28:47] <scribe> record that you were trying to collect. So what it is, I
[05:28:50] <scribe> put some verbiage around how does forking impact it.
[05:28:53] <scribe> Obviously, it's a downstream proxy that's forking the
[05:28:57] <scribe> messages. It doesn't matter because the metrics, the way
[05:29:00] <scribe> they're set up, if you measure from the way the UAC
[05:29:03] <scribe> perspective, it's only going to forward back to you upstream to
[05:29:08] <scribe> you, the message that is the selected, you know, 200
[05:29:12] <scribe> okay, to the multiple invites. And it's going to actually reject all the
[05:29:16] <scribe> rest of them with buy, so you don't see those. If your a
[05:29:18] <scribe> client forking all the messages out, then you'll
[05:29:24] <scribe> have to use, the method with which it's collecting the input
[05:29:27] <scribe> variables for the metric, it will have to utilize the tag to be
[05:29:30] <scribe> able to determine which one, which one received it's going to
[05:29:33] <scribe> maintain the session dialogue with, and then, you know, which
[05:29:39] <scribe> ones are all sending back byes to a 200 okay.
[05:29:44] <scribe> Next. One comment on that, is that someone had suggested that,
[05:29:48] <scribe> okay, it's great that we have this common set of metrics that
[05:29:51] <scribe> we can all utilize and say, this is great for us to work
[05:29:54] <scribe> from. But how is this extensible or is it extensible? Is
[05:29:58] <scribe> there anyway to say, if we wanted to add metrics later on,
[05:30:02] <scribe> if it made sense, how could we do that? So I built
[05:30:09] <scribe> a metrics template which is actually on the previous slide,
[05:30:13] <scribe> and so, you know, really what it does, it's very specific.
[05:30:17] <scribe> . It just talks about, you have to define what the
[05:30:19] <scribe> problem is that you're trying to solve. You have to
[05:30:22] <scribe> determine what's the unit of measure, things like this. So
[05:30:25] <scribe> that it's consistent and there's a consist way in which we can do
[05:30:25] <scribe> this.
[05:30:30] <scribe> It's one of the things that I'll mention here in a minute, was
[05:30:35] <scribe> basically I. ANA considerations of whether or not you should
[05:30:38] <scribe> specifically define these acronyms or metrics and
[05:30:43] <scribe> if you extended it later it would be consistent and you could do it.
[05:30:47] <scribe> Metrics under consideration, session efficiency establishment
[05:30:51] --- ttfr has joined
[05:30:51] <scribe> rate, so, I know that's a long name for a metric but it
[05:30:58] <scribe> kind of alliance with all the metrics. So, I T U. Four
[05:31:02] <scribe> 11. NEW SPEAKER: Just a curiosity item, first time I
[05:31:06] <scribe> heard that IANA was essentially used as an aa dictionary. NEW SPEAKER:
[05:31:08] <scribe> These are not protocol. (Several people talking.) NEW SPEAKER:
[05:31:14] <scribe> Have you talked to IANA folks to see if they want to be in that business? NEW SPEAKER:
[05:31:18] <scribe> I haven't, and to be honest, it was a suggestion to me, I don't
[05:31:23] <scribe> know the details around that. And to me, I really would
[05:31:27] <scribe> have to rely on other peoples understanding and
[05:31:31] <scribe> expertise of that area. Whenever I look at IANA for other
[05:31:35] <scribe> things, it doesn't have to do with an acronym dictionary. But
[05:31:38] <scribe> I think the idea was, if you could specify saying that, for
[05:31:42] <scribe> example, session request delay, S R D is always going to be S
[05:31:45] <scribe> R D and no one else can use S R D, then you would want to
[05:31:49] <scribe> somehow, you know, register that somehow, so that it is
[05:31:52] <scribe> set as that. NEW SPEAKER: IANA has the trademark. New
[05:31:56] <scribe> IETF trademark office. NEW SPEAKER: Yes. I would
[05:31:59] <scribe> have to, you know, I think there was a number of steps that
[05:32:03] <scribe> need to take place before we get to that point. If you look in
[05:32:05] <scribe> the draft, there's nothing about IANA consideration. So, you
[05:32:08] <scribe> know, I just wanted to throw that out there.
[05:32:09] <scribe> Interesting feedback.
[05:32:14] <scribe> So what this is, this is essentially a recommendation came in.
[05:32:19] <scribe> So session establishment rate is similar to I T U T Dot 4 11, which
[05:32:24] <scribe> is A S R. And in the telephony application, there wasn't
[05:32:28] <scribe> -- it doesn't take into consideration any user behavior. So
[05:32:34] <scribe> therefore, you know, they came out with a new one, in I T
[05:32:37] <scribe> U T Dot four 11, they came out with effectiveness ratio.
[05:32:41] <scribe> So this metric is aligning with that. So it's taking A S R and
[05:32:45] <scribe> putting user behavior associated with it and placing some
[05:32:50] <scribe> values, 4 '86 and 600 to the S ER enumerate tore which
[05:32:54] <scribe> essentially gives you the session efficiency establishment rate.
[05:32:59] <scribe> Other metrics that was suggested as well, would be initial
[05:33:02] <scribe> response time, which is a metric essentially for the
[05:33:06] <scribe> originator, which is basically time from the invite to the
[05:33:13] <scribe> first SIP response. Authentication time, which isolates
[05:33:17] <scribe> the actual authentication related time. Which is essentially
[05:33:20] <scribe> once you send an invite or register request, how long does it
[05:33:24] <scribe> take to actually go to the authentication process and resolve that?
[05:33:29] <scribe> You know, in regards to these, these are metrics that people
[05:33:34] <scribe> suggested that you know, I didn't get a lot of feedback from,
[05:33:37] <scribe> on these two specifically, the session establishment
[05:33:41] <scribe> effectiveness rate, which you know, has to be, there's got to
[05:33:45] <scribe> be an easier way to say that. But essentially, it was the one that I
[05:33:48] <scribe> got the most feedback on and I think it makes a lot of sense,
[05:33:51] <scribe> so I plan to add that in as a metric. NEW SPEAKER:
[05:33:54] <scribe> Just a general consideration, I don't know how much, how
[05:33:58] <scribe> many metrics you have in there right now, I haven't counted.
[05:34:03] <scribe> My information generally speaking, would be since this is
[05:34:07] <scribe> naturally extensible, and there's really no reason for the
[05:34:10] <scribe> second draft couldn't be two minutes later with the three
[05:34:14] <scribe> additional ones and to kind of start as
[05:34:19] <scribe> small as possible, rather than kind of do the, whatever,
[05:34:21] <scribe> whenever some random e-mail -- NEW SPEAKER: Totally
[05:34:24] <scribe> completely agree. 100 percent agree with that. I made the
[05:34:28] <scribe> comment early on, I think it was, either in Montreal or San Diego, I
[05:34:31] <scribe> specifically said, the whole point of this draft is to
[05:34:34] <scribe> establish a common set, a small set of metrics. Which is
[05:34:38] <scribe> really the foundation Al set of metrics for which people can
[05:34:40] <scribe> say, it's great, I know for a fact that every company out
[05:34:44] <scribe> there is going to decide, hey, we really need this metrics.
[05:34:48] <scribe> Dust this metric really make sense to us? That's great.
[05:34:52] <scribe> Does it make sense to the whole industry. So this was an attempt to,
[05:34:57] <scribe> I agree, keep a summarized, a small set of metrics, for
[05:35:00] <scribe> which we could all say, we could all agree upon and say, yes,
[05:35:05] <scribe> this set makes sense. This is a good common set. And so, you
[05:35:08] <scribe> know, to be honest, I leveraged a lot of
[05:35:12] <scribe> what has really become a common set of metrics out of the I T U
[05:35:12] <scribe> T.
[05:35:16] <scribe> You know, I mean, I think it's a good resource. They've had metrics set
[05:35:19] --- vkg has left
[05:35:19] <scribe> up for a long time. That people have been using and
[05:35:23] <scribe> telephony world, and so I started with that, and then there
[05:35:25] --- hbaosiy has left: Replaced by new connection
[05:35:26] <scribe> are some that were easily, that easily made sense because it
[05:35:30] <scribe> made sense for SIP. That's the whole point of these. NEW SPEAKER:
[05:35:34] <scribe> Again, I don't know how many you have but
[05:35:35] <scribe> dash NEW SPEAKER: I think there's about 14. NEW SPEAKER:
[05:35:40] <scribe> That seems kind of borderline much. So, I mean, agree
[05:35:44] <scribe> having something which makes it comparable to existing format
[05:35:50] <scribe> is good for transition the but people worry a call that used to
[05:35:53] <scribe> take two sexdz is going to take 5 now because it's SIP. So
[05:35:58] <scribe> that's useful because people relate to that, S L.A. s In some
[05:36:02] <scribe> cases that people have, for old equipment it's purely the
[05:36:08] <scribe> lawyers like it. So all of these, but all the metrics that you
[05:36:12] <scribe> have to work out, just likely to be extremely strongly
[05:36:17] <scribe> correlated, in the sense that, metric X is 5 seconds,
[05:36:21] <scribe> metric Y is likely going to be 5 seconds plus something. NEW SPEAKER:
[05:36:23] --- hbaosiy has joined
[05:36:26] <scribe> Yes. NEW SPEAKER: And so, or double the other
[05:36:29] <scribe> ones, the other one is likely to double type of deal. So the
[05:36:34] <scribe> value of having a second metric is practically speaking, low.
[05:36:37] <scribe> It just inflates the metric packet. NEW SPEAKER: So I
[05:36:40] <scribe> understand. If there's a related metric, NEW SPEAKER:
[05:36:44] <scribe> Pick one. NEW SPEAKER: Why have the related metric if
[05:36:48] <scribe> you can establish a certain amount of, you know, result
[05:36:51] <scribe> through a simpler metric if you will NEW SPEAKER: Yes. NEW SPEAKER: (Several people talking.) NEW SPEAKER:
[05:36:55] <scribe> NEW SPEAKER: Metrics I would, two things I would say, as
[05:36:58] <scribe> guidelines is, if there's an existing telephone metrics,
[05:37:02] <scribe> simply for reasons I've mentioned and if it's user behavior
[05:37:06] <scribe> measurable and customers can observe it and it has some relationship to
[05:37:11] <scribe> user experience, those I think are important and we care about
[05:37:14] <scribe> those. NEW SPEAKER: We need to go ahead and wrap up
[05:37:18] <scribe> the discussion. Go through the line really quickly here. NEW SPEAKER:
[05:37:23] <scribe> Cullen, you can insert yourself. If you'd like. NEW SPEAKER:
[05:37:27] <scribe> My quick comment following up with that. e I completely
[05:37:29] <scribe> agree. NEW SPEAKER: Who is speaking. NEW SPEAKER:
[05:37:36] <scribe> Allan mortgage ton, sorry mort ton. I quickly
[05:37:40] <scribe> agree with that. And the key point is, there's a we that
[05:37:43] <scribe> has to decide, you know, what's the minimum set? And we haven't
[05:37:46] <scribe> established the we yet. There isn't a working group item. NEW SPEAKER:
[05:37:49] <scribe> Yes, that's dash NEW SPEAKER: We sort of need a hum for
[05:37:52] <scribe> this. NEW SPEAKER: Wait. Hold on. We have the A
[05:37:55] <scribe> Ds in the line. NEW SPEAKER: Let me get to the mic
[05:37:56] <scribe> snoochlt
[05:38:01] <scribe> NEW SPEAKER: Let's take the comments and
[05:38:05] <scribe> Cullen will clarify where this is going to be discussed and who we means.
[05:38:08] <scribe> NEW SPEAKER: As long as that's going to be a topic, good. NEW SPEAKER:
[05:38:12] <scribe> So, one point I saw, I think one of the things you changed
[05:38:16] <scribe> was about the averages that you're using.
[05:38:20] <scribe> And with averages, you've got to think of
[05:38:24] <scribe> failure cases. With failures, don't assign those like
[05:38:27] <scribe> infinite times because you don't get average. So we have to
[05:38:29] <scribe> have a condition of distribution on success. NEW SPEAKER:
[05:38:32] <scribe> Correct. NEW SPEAKER: If the wording says that,
[05:38:36] <scribe> then you're in good shape. NEW SPEAKER: I believe so. NEW SPEAKER: Let's
[05:38:36] <scribe> --
[05:38:38] <scribe> (Several people talking.) NEW SPEAKER: Let me go back
[05:38:40] <scribe> and look at that. But that's a valid point. NEW SPEAKER:
[05:38:48] <scribe> Good, thank you. NEW SPEAKER: Keith dredge. I believe you
[05:38:53] <scribe> sorted out the differences with the benchmark and this is
[05:38:54] <scribe> basically --
[05:38:58] <scribe> NEW SPEAKER: Let's let Cullen get up here and explain how
[05:39:00] <scribe> we're going to handle this work. NEW SPEAKER: What I
[05:39:02] <scribe> was going to say -- NEW SPEAKER: He's working (Several people
[05:39:02] <scribe> talking.)
[05:39:05] <scribe> NEW SPEAKER: I'm worried, what I'm saying, about to say, I
[05:39:08] <scribe> made a whole load of comments against the document
[05:39:11] <scribe> in benchmarking that should be equally
[05:39:14] <scribe> applicable to this document. It would be useful if they
[05:39:17] <scribe> actually looked at the two documents together and say, it's could
[05:39:19] <scribe> could haved there, therefore, we also need to
[05:39:24] <scribe> cover it in our document. For example, there is nothing in your
[05:39:26] <scribe> dock document that
[05:39:29] <scribe> characterizes the presence for handling basically presence rather
[05:39:33] <scribe> than voice communication. You know, they should both cover
[05:39:34] <scribe> the same scope of work.
[05:39:37] <scribe> The other comment I also made against the other documents which
[05:39:41] <scribe> also applies here is latent message has a great deal of impact
[05:39:44] <scribe> on the phones. Particularly in radio systems. There's
[05:39:47] <scribe> nothing that the parameter says, any of the test you're doing
[05:39:52] <scribe> or says the user has to give some idea of the prioritization of
[05:39:57] <scribe> the message, in order to have the ability for the results.
[05:39:59] <scribe> Should there be? I guess there should. NEW SPEAKER:
[05:40:04] <scribe> Keith, can could you please point the authors of this draft
[05:40:06] <scribe> to your comments dash NEW SPEAKER: The
[05:40:10] <scribe> draft is NEW SPEAKER: The other draft is the pret see
[05:40:14] <scribe> draft. NEW SPEAKER: Yes. NEW SPEAKER: Just a
[05:40:17] <scribe> couple of comments, I hope this work
[05:40:20] <scribe> continues. I don't know in which working group or which form. But
[05:40:24] <scribe> I think the idea is a good one. And that 14 metrics may be not
[05:40:28] <scribe> enough, maybe a lot for some people. We probably need to
[05:40:33] <scribe> have some agreement and I wanted to re in force the comment
[05:40:36] <scribe> that Keith made about going beyond voice in terms of the
[05:40:42] <scribe> metrics that are inserted there and maybe finding a way to how you address that. NEW SPEAKER:
[05:40:46] <scribe> My one comment on that is, this is very much intended to be a
[05:40:50] <scribe> set of metrics that's related to SIP. So regardless of whether SIP is
[05:40:57] <scribe> used for voice or for imor media or something loo thaik. So,
[05:41:01] <scribe> if they do not address that, they absolutely shood.
[05:41:07] <scribe> NEW SPEAKER: Jeff smrb. I guess the thing I see missing here
[05:41:11] <scribe> is the interaction between signalling and media.
[05:41:21] <scribe> In particular, in sort of which, when you have a two way
[05:41:26] <scribe> media path and when a call is being initiated and when in band
[05:41:29] <scribe> call progress signals are present. Did you consider that as
[05:41:32] <scribe> part of this? NEW SPEAKER: Yes, I absolutely did.
[05:41:35] <scribe> I've gotten that comment back a couple of times and so, I
[05:41:40] <scribe> specifically, so because SIP is a, it's really a control
[05:41:45] <scribe> protocol, and can actually establish, I mean, it can
[05:41:49] <scribe> establish media and can be used for I M and text and it can be
[05:41:54] <scribe> used for without ever establishing media, so and so I think the
[05:41:58] <scribe> metrics, to be honest, I strayed away from that specific
[05:42:01] <scribe> example, where I'm measuring from the aspect of, you know,
[05:42:05] <scribe> therefore, you know, I sent the invite, got back the 200
[05:42:09] <scribe> okay and now the time in which it takes for me to actually have
[05:42:13] <scribe> bidirectional media two between two end points, I
[05:42:18] <scribe> just, you know, and maybe this will change, dp, as this
[05:42:21] <scribe> draft moves forward, but I specifically wanted to stay in measuring
[05:42:25] <scribe> only the signaling aspects. The SIP signaling aspects of
[05:42:27] <scribe> this. NEW SPEAKER: But since your document really
[05:42:32] <scribe> defines the time interval of, and terminology of when, what the
[05:42:36] <scribe> measurement means, it would be really useful to add, I think it would be
[05:42:41] <scribe> really useful to add a couple that show the interaction between
[05:42:44] <scribe> signaling and media, because that's where many customer
[05:42:47] <scribe> Complaints are going to end up being. And that's where
[05:42:50] <scribe> you're going to have trouble, saying, gee, customer pick
[05:42:52] <scribe> up and then you have a path for some period of time. I need
[05:42:58] <scribe> to know that. NEW SPEAKER: Okay.
[05:43:01] <scribe> NEW SPEAKER: I'm one of the transport area directors.
[05:43:06] <scribe> The existing working groups, I think in ops, has
[05:43:09] <scribe> benchmarking working group, we have done a pretty nice
[05:43:13] <scribe> framework for IP layer of metrics. And I think if both of those
[05:43:23] <scribe> groups, the idea to do that at the application has come up.
[05:43:25] <scribe> And we're currently trying to think of where we can put that work.
[05:43:32] <scribe> And I think it's important, to have some discussion between the area
[05:43:36] <scribe> directors, the three areas, what to do with this. One is
[05:43:39] <scribe> sort of opening up an application layer metrics would be too
[05:43:43] <scribe> broad. But there is certainly smaller scope that might be successful.
[05:43:48] <scribe> So, I guess I'd say we're interested in opening an discussion
[05:43:52] <scribe> if there's interested people who want to think about what to do
[05:43:55] <scribe> with this, maybe in a new group. NEW SPEAKER: I
[05:43:59] <scribe> think so. Cullen, area director here. I mean, we,
[05:44:02] <scribe> clearly we need to bring the combination of the metrics
[05:44:07] <scribe> experience, and the actual, the SIP or whatever the
[05:44:10] <scribe> application of interest is together. And we sort of, you
[05:44:13] <scribe> know, I'm embarrassed to say, we have sort of given this draft
[05:44:17] <scribe> the run around so far. As I said here, and there and here
[05:44:19] <scribe> and back again. I'm glad to see that the real work
[05:44:22] <scribe> progressed even as it got the run around. But what we're trying to
[05:44:26] <scribe> dpiing err figure out what the right group is to bring
[05:44:28] <scribe> together to do this.
[05:44:34] <scribe> Dan is one of the ops A D has more or less taken an action item who is
[05:44:37] <scribe> a ring leader of figuring this out. It will be between the
[05:44:44] <scribe> six relevant A Ds and perhaps we'll run a BOF meeting or form
[05:44:47] <scribe> some type of group. But we will get something back to people
[05:44:51] <scribe> in the next few weeks, as sort of a strong man proposal and
[05:44:55] <scribe> start a discussion of how to bring this together. So, I
[05:44:58] <scribe> don't want to decide to bring this in as a SIPPING working
[05:45:03] <scribe> group item right now, because there's a big question as to
[05:45:06] <scribe> whether this group has the right expertise to review it. I
[05:45:09] <scribe> do want it to move forward, and SIPPING is a logical place to
[05:45:13] <scribe> discuss it until then. But we need to get some group to
[05:45:15] <scribe> review it. NEW SPEAKER: My only comment there is just
[05:45:20] <scribe> that, and that's good, I mean, I guess, let me just
[05:45:24] <scribe> express a little bit of sense of frustration, kind of, it's
[05:45:28] <scribe> more that we've had this similar type of conversation of where
[05:45:31] <scribe> should this live, and you know, I'm getting close to the
[05:45:35] <scribe> point where, you know, it's going to live on my trash can. NEW SPEAKER:
[05:45:39] <scribe> Well, awb awk NEW SPEAKER: Very fair. NEW SPEAKER:
[05:45:41] <scribe> I did get that message clear. (Several people
[05:45:42] <scribe> talking.)
[05:45:47] <scribe> NEW SPEAKER: I've lost the interest in following it and
[05:45:51] <scribe> chasing it from different working groups all around. And
[05:45:54] <scribe> it's like one of those things where it's starting to just
[05:45:58] <scribe> languish and, I and I understand whenever I first
[05:46:02] <scribe> introduced it it all of a sudden created this, new, you
[05:46:04] <scribe> know it fell into a gap. NEW SPEAKER: Right. NEW SPEAKER:
[05:46:07] <scribe> And understanding that we need to find out exactly where does
[05:46:11] <scribe> it need to go, my concern is, three and a half years from
[05:46:15] <scribe> now, we'll determine, a ha, we have a group now that does
[05:46:17] <scribe> this. Where is this draft? And you know, it should be our
[05:46:22] <scribe> first working group item. You know. And at that point,
[05:46:26] <scribe> I'm playing racquetball in the Caribbean and don't give a crap
[05:46:29] <scribe> about SIP. That's probably not the case. But, NEW SPEAKER:
[05:46:32] <scribe> So, we want to be quick on this, and we want to capture
[05:46:35] <scribe> the people who are, you know, interested in doing some real
[05:46:38] <scribe> work on this, both have the experience to review it from the
[05:46:41] <scribe> various different points of view, metrics and the
[05:46:42] <scribe> application point of view. NEW SPEAKER: Right. I mean
[05:46:42] <scribe> --
[05:46:45] <scribe> NEW SPEAKER: Before they also get, old and die or
[05:46:49] <scribe> something. NEW SPEAKER: Right. So is, the A Ds
[05:46:53] <scribe> are going to go take care of where this draft lives, to make
[05:46:56] <scribe> sure we have the right parties. If we continue in SIPPING, we
[05:46:59] <scribe> don't have the experts. We have to send it to all the
[05:47:02] <scribe> different working groups for expert review. NEW SPEAKER:
[05:47:06] <scribe> You're not alone. There are people who feel like you in other
[05:47:10] <scribe> areas. And that's why we got put off here in the group and
[05:47:13] <scribe> let's see what happens. NEW SPEAKER: Yes, so for the note
[05:47:17] <scribe> taker, basically, the A Ds have an action point to figure
[05:47:20] <scribe> this one out. Yes. We're going to be talking about call
[05:47:25] <scribe> completion services please. NEW SPEAKER: Yes. I'll
[05:47:32] <scribe> give a short overview of the status of the work, considering
[05:47:36] <scribe> the call completion service. Basically, currently there are two
[05:47:40] <scribe> solutions on the run. One is based on the SIP event
[05:47:45] <scribe> framework. The other one is based on the binary flow control
[05:47:49] <scribe> protocol. And yes, basically, what I'd like to achieve
[05:47:54] <scribe> today is to have some guidance from the group which way the group would
[05:47:59] <scribe> prefer to go. And I'll give some information on the discussion
[05:48:03] <scribe> status and pros and cons of the boat options.
[05:48:11] <scribe> So, so the SIP event framework based solution requires several
[05:48:18] <scribe> extensions to work. And those are the new event package for
[05:48:23] <scribe> queue management and state change notification. The P service indication
[05:48:26] <scribe> header for priority treatment of call back calls. And
[05:48:29] <scribe> extension to a lou event header.
[05:48:33] <scribe> Or extension of the definition of allow event header to be also
[05:48:38] <scribe> will included in one '80 and 4 '86 responses.
[05:48:51] <scribe> All right. The use of the subscribe or event framework to
[05:48:58] <scribe> change the state in this case, the queue, was considered or
[05:49:02] <scribe> there was some arguments that it's not the appropriate way for
[05:49:07] <scribe> the use of the event framework. On the other hand there was
[05:49:13] <scribe> some arguments that similar use is already done in the policy
[05:49:18] <scribe> package where the, submit the SDP in the subscribe and receive
[05:49:22] <scribe> then a policy for that SDP to notify request. Meaning that
[05:49:26] <scribe> you are already doing something, or providing information
[05:49:28] <scribe> using the subscribe. And not just
[05:49:30] <scribe> subscribing for the change of the state.
[05:49:38] <scribe> The service identification discussion could help with the P
[05:49:41] <scribe> source service indication header, because that's something
[05:49:44] <scribe> that's introduced in this draft. And
[05:49:51] <scribe> based on the output of this identification discussion, this could
[05:49:53] <scribe> be re used. NEW SPEAKER: Yes, I know. This is
[05:49:56] <scribe> why we need to write that draft. It makes me cry,
[05:49:59] <scribe> because the whole idea of the service
[05:50:03] <scribe> identification draft is that you don't have a different header
[05:50:06] <scribe> field that does the same thing as the service identification.
[05:50:09] <scribe> It's a semantic for what you want to dochlt not just have
[05:50:13] <scribe> another thing you can draw.
[05:50:16] <scribe> I agree you should use the guidance on that to properly design it.
[05:50:20] <scribe> But the goal is not to build a different syntax way of
[05:50:25] <scribe> representing a dwim field, we're not going to do that. NEW SPEAKER:
[05:50:30] <scribe> Okay. And the extension of the allow M header to finish into one
[05:50:34] <scribe> '80 and 4 '86. I haven't seen any problems or
[05:50:36] <scribe> responses talking about problems about it.
[05:50:43] <scribe> So, basically, the main discussion, or main issue with the
[05:50:48] <scribe> solution base on is SIP events is the use of the
[05:50:50] <scribe> subscribe message to change the state of the queue.
[05:50:57] <scribe> Next. The B F C P solution basically works, but, so there
[05:51:05] <scribe> are, there is a draft available, that discusses how the T S
[05:51:08] <scribe> P S and the other protocol. But at the last meeting, there
[05:51:14] <scribe> were some discussions or, about the solution proposal, and
[05:51:18] <scribe> was the conclusion was drawn that the complexity of the
[05:51:24] <scribe> decoupling SIP signaling and B F C P signaling, speblly the
[05:51:27] <scribe> case in the inter working case, where their could be
[05:51:31] <scribe> decomposed gate waist which is normally the case. Then this
[05:51:36] <scribe> complexity would ex extent the benefits of the proposed solution.
[05:51:41] <scribe> Next. So the proposal is, agree on the SIP event package
[05:51:44] <scribe> based solution as a preferred way forward. You know, use the
[05:51:49] <scribe> output of a service identification for the call back priority
[05:51:52] <scribe> indication. And stepped the allow event header definition to
[05:51:57] <scribe> one '80 and 4 '86, and yes. So, I'm kind of seeking
[05:52:01] <scribe> guidance from the group, if this is an acceptable way forward?
[05:52:08] <scribe> NEW SPEAKER: Do we have any xhements on that? John? NEW SPEAKER:
[05:52:13] <scribe> Yes. I think the important thing is to make the decision on
[05:52:18] <scribe> the event package versus the B F C P solution. I think the, I
[05:52:21] <scribe> believe the service identification one aside, and the last one
[05:52:25] <scribe> I think is really coupled to the decision we make on the first one
[05:52:28] <scribe> anyway. And that's a rather small thing, so that's just on
[05:52:36] <scribe> the that one big issue. And I think that the event package
[05:52:40] <scribe> solution is the way to go because of its simplicity. It fits
[05:52:43] <scribe> this brob lem better. Thank you.
[05:52:48] <scribe> NEW SPEAKER: Any other comments?
[05:52:52] <scribe> NEW SPEAKER: So maybe we can take a hum on which is the
[05:52:56] <scribe> preferred solution? Or would you like to have more discussion
[05:52:58] <scribe> on the list? NEW SPEAKER: There were a lot of
[05:53:02] <scribe> discussions actually for the last IETF, the
[05:53:04] <scribe> threads actually died out somehow. So we haven't seen
[05:53:06] <scribe> lately so much discussion. But yes, Paul? NEW SPEAKER:
[05:53:14] <scribe> Paul, dp we're just deciding between these two
[05:53:17] <scribe> alternatives, does it mean that the two alternatives are
[05:53:21] <scribe> considered to be finished and once we've decided one, they're
[05:53:23] <scribe> over. NEW SPEAKER: They're not finished, no. It's
[05:53:25] <scribe> just a way forward. NEW SPEAKER: So if we're concerned
[05:53:31] <scribe> about refinements as to whai the event packet works, that will
[05:53:35] <scribe> still be on the table later? NEW SPEAKER: Okay. So let's try
[05:53:38] <scribe> to get a hum, at least to get a sense of -- NEW SPEAKER:
[05:53:41] <scribe> Right. Just to let us know the way forward in progressing
[05:53:45] <scribe> this document what path. So, who all is in support of
[05:53:49] <scribe> doing the event package rather than the B F C P approach for this? NEW SPEAKER:
[05:53:53] <scribe> I just want to understand whether we're agreeing to adopt this
[05:53:53] <scribe> as a work being da --
[05:53:54] <scribe> NEW SPEAKER: No. (Several people talking.)
[05:53:57] <scribe> NEW SPEAKER: We're giving peed gak to keep this moving forward
[05:53:59] <scribe> for him. NEW SPEAKER:
[05:54:02] <scribe> ( Feedback. ) NEW SPEAKER: It's just for the
[05:54:06] <scribe> information to get a sense of the room. Not talking at all about
[05:54:08] <scribe> getting working group item at this point. NEW SPEAKER:
[05:54:11] <scribe> Okay. Folks, this is just to get feedback on this. Who
[05:54:15] <scribe> all would be supportive of us going forward with the event
[05:54:16] <scribe> package approach? NEW SPEAKER:
[05:54:20] <scribe> ( Humming. ) NEW SPEAKER: All right. Mild hum.
[05:54:23] <scribe> And then the B F C P approach?
[05:54:27] <scribe> ( Humming. ) NEW SPEAKER: Okay. So it seems
[05:54:30] <scribe> like, the more dash NEW SPEAKER: Can I make a procedural
[05:54:37] <scribe> comment. Go back two slides. The one about tie span
[05:54:43] <scribe> discussion. NEW SPEAKER: Okay. So, this is, I
[05:54:48] <scribe> mean, maybe this is something for the liaison, sort of, I kind
[05:54:53] <scribe> of, to me, this is the kind of discussion here, that I would have
[05:54:57] <scribe> liked, that should be in the IETF as well. Sometimes I think there's
[05:55:01] <scribe> a perception that IETF is syntax makers. Right? That other
[05:55:04] <scribe> standards actually figure out the protocol and they come and tell
[05:55:08] <scribe> us, they want to know which field we should use. IETF e we have
[05:55:13] <scribe> a question, should we use a P header or context header this
[05:55:17] <scribe> header or that header. To me, all of this is part of the
[05:55:21] <scribe> protocol design. I welcome tie span, and I would much
[05:55:24] <scribe> preferred that this kind of discussion that has not happened the
[05:55:29] <scribe> IETF list, that folks from tie span who are interested in
[05:55:33] <scribe> understanding the protocol. Should come and make
[05:55:37] <scribe> comments on the mailing list and have these discussions. NEW SPEAKER:
[05:55:41] <scribe> You're perfectly right. As I pointed out before, that
[05:55:43] <scribe> type of discussion actually happened before the last IETF.
[05:55:47] <scribe> Again, we haven't seen discussion on the IETF dash NEW SPEAKER:
[05:55:50] <scribe> I'm reading from this thing, that there was some other discussions
[05:55:54] <scribe> that may or may not have raised points --
[05:55:58] <scribe> NEW SPEAKER: What he's reporting back is what happened in
[05:56:01] <scribe> the tie span meeting. I don't know if we want to bring all
[05:56:03] <scribe> their discussions to the SIPPING list. I see (Several people
[05:56:06] <scribe> talking.) NEW SPEAKER: I so I mean, part of it, it is
[05:56:09] <scribe> important for them to still, that this is interaction with
[05:56:11] <scribe> IETF and bring it sooner rather than later. NEW SPEAKER:
[05:56:15] <scribe> Right. There's a very fuzzy line between system
[05:56:21] <scribe> architecture and protocol design. It's okay dm my mine that
[05:56:25] <scribe> tie span call flows and all that, that's great.
[05:56:28] <scribe> But this kind of discussion, this protocol dash NEW SPEAKER:
[05:56:32] <scribe> But the problem is, that these people in the protocol Dee
[05:56:33] <scribe> sign stage right now. NEW SPEAKER: I thought IETF does
[05:56:37] <scribe> protocols for tie span. Am I misunderstanding. NEW SPEAKER:
[05:56:41] <scribe> I'll let John answer snoochlt I'm
[05:56:46] <scribe> NEW SPEAKER: Who am I to know? You've got the sill gist
[05:56:52] <scribe> many wrong I think. NEW SPEAKER: I'm not part of the tie span discussions
[05:56:57] <scribe> really. I'm sitting on the side, but my understanding was
[05:57:01] <scribe> that the tie span people are talking to the architectural
[05:57:04] <scribe> discussion we had on the SIPPING list some months ago, and
[05:57:07] <scribe> reviewed that, and came to this conclusion. We're not
[05:57:11] <scribe> aware that they came up with any solution. It was discussed
[05:57:13] <scribe> there and I think we did say that here. NEW SPEAKER:
[05:57:16] <scribe> Just to give a little bit of historical background. The tie
[05:57:19] <scribe> span people actually came here a few IETFs ago and
[05:57:23] <scribe> they proposed to use an event packet. There were discussions
[05:57:26] <scribe> on the mailing list and some people thought that the use of an
[05:57:29] <scribe> event package was inappropriate. And then Adam actually put
[05:57:35] <scribe> together a draft that proposed to use B F C P for that, there were more
[05:57:36] <scribe> discussions on the list.
[05:57:41] <scribe> They went off and analyzed those discussion, John is saying no
[05:57:44] <scribe> new points were raised and now they're coming back
[05:57:48] <scribe> and sake they didn't like the B F C P approach for what he has
[05:57:51] <scribe> proposed and they are basically asking me, the IETF is so
[05:57:54] <scribe> uncomfortable with the event package or not? Obviously, we have to have
[05:57:58] <scribe> those discussions on the list, but we would like to give
[05:58:00] <scribe> Dennis just a sense of the room, of you know, what's the
[05:58:05] <scribe> level of people being uncomfortable with the event packet.
[05:58:10] <scribe> So, NEW SPEAKER: Adam roach. I just, to review the
[05:58:13] <scribe> point, there wasn't anything of substance discussed that hadn't
[05:58:17] <scribe> been brought to the IETF yet. The second point on this slide
[05:58:23] <scribe> here, that's a technical point, had not been raised. And
[05:58:26] <scribe> it's not a very good description of the problem but my reading
[05:58:30] <scribe> of that is it's based on a misconception. There's, for
[05:58:33] <scribe> example, just to take the specific example in front of us, there's
[05:58:38] <scribe> nothing saying that the SDP has to run to the media Gateway at
[05:58:41] <scribe> all. That runs to the same place your SIP is can going. You're
[05:58:45] <scribe> basically passing the address of the ports back and forth in
[05:58:45] <scribe> SDP.
[05:58:49] <scribe> So if those kind of technical discussions had been brought to the
[05:58:52] <scribe> IETF, we probably could have cleared them up. That's
[05:58:56] <scribe> exactly the sort of thing that would have been a really good
[05:59:00] <scribe> thing to bring to the list. I'm looking at this, it's been
[05:59:02] <scribe> almost two months since the discussion occurred and we're
[05:59:06] <scribe> finding out now, in real time, that based on a
[05:59:07] <scribe> misconception. NEW SPEAKER: Yes. NEW SPEAKER:
[05:59:10] <scribe> Those are the kind of things that I think would require a
[05:59:13] <scribe> little more integrated discussion. NEW SPEAKER: Yes.
[05:59:15] <scribe> That's a fair point. Yes. Jonathan. NEW SPEAKER:
[05:59:19] <scribe> Let me make another point, sort of an analogy. The
[05:59:23] <scribe> analogy would be, if tie span we're going to do a V four,
[05:59:27] <scribe> v6 discussion and we're going to have our own discussion about
[05:59:31] <scribe> ice versus ANAT, and then they come to IETF and say tie span
[05:59:34] <scribe> thinks we should have ANAT -- NEW SPEAKER: Point taken. NEW SPEAKER:
[05:59:37] <scribe> So my point is, that kind of stuff, which I agree is on
[05:59:40] <scribe> the line, I'm not accusing any one of malice, I'm just
[05:59:44] <scribe> saying, this is real fuzzy stuff, but it is protocol
[05:59:48] <scribe> design, make no mistake and I want to make sure that IETF is a
[05:59:51] <scribe> parts panlt and ultimately the owner of the design of the protocols for
[05:59:53] <scribe> these functions. NEW SPEAKER: Yes. Sure. (Several people talking.) NEW SPEAKER:
[05:59:55] <scribe> That's my procedural point. NEW SPEAKER: Just
[05:59:59] <scribe> wrapping up this issue because we are running out of time.
[06:00:01] <scribe> Basically, the conclusion is that the group wants to see
[06:00:04] <scribe> more discussions on the list so please
[06:00:08] <scribe> bring all the technical arguments that you had in tie span to elaborate those
[06:00:13] <scribe> slides and let's see how this progresses. NEW SPEAKER:
[06:00:17] <scribe> And I personally am quite torn, but my main point is that, I
[06:00:23] <scribe> just want to make sure that the, dash NEW SPEAKER: Next
[06:00:25] <scribe> step is to discuss more on the list. NEW SPEAKER: Just
[06:00:28] <scribe> to make sure I understand, we are going with the event package
[06:00:31] <scribe> are and we're going to do the work here? No, no. We are
[06:00:34] <scribe> actually having more discussions on the list. We are not saying that we
[06:00:37] <scribe> are going for the event packet yet. NEW SPEAKER: So
[06:00:41] <scribe> why did we hum then? Yes, s the hum supported that, and the sense of the
[06:00:46] <scribe> group, but basically we need to ratify that on the list. NEW SPEAKER:
[06:00:49] <scribe> Yes, Jonathan? NEW SPEAKER: Well, I thought you
[06:00:53] <scribe> wanted to know do the people sitting here think he's totally
[06:00:57] <scribe> crazy or should he continue to work on it? And I think the
[06:01:00] <scribe> feedback was konlt to work on it. We haven't even adopt
[06:01:04] <scribe> dead this as a working item. It's not too late, but we're
[06:01:06] <scribe> not saying that's the right approach. NEW SPEAKER:
[06:01:08] <scribe> Exactly. NEW SPEAKER: I think the general feedback
[06:01:10] <scribe> is, we need to have the discussion on the list on these technical
[06:01:12] <scribe> issues. NEW SPEAKER: This is a hard problem but I don't
[06:01:15] <scribe> know, we've had, you know, I've been in internal
[06:01:19] <scribe> discussions on this feature and we had a million discussions on the
[06:01:23] <scribe> topic. This may be one where we need a design team. If we
[06:01:26] <scribe> tried that, I don't know. This is har to do as a list discussion. NEW SPEAKER:
[06:01:29] <scribe> Okay. NEW SPEAKER: As long as we acknowledge and you
[06:01:31] <scribe> know, the reports and whatever, that the
[06:01:34] <scribe> feeling from the group at this point seems to indicate that
[06:01:37] <scribe> we're going for the event package and we'll have more
[06:01:40] <scribe> discussion, sure, but that's always the case, I'm happy
[06:01:42] <scribe> with that. NEW SPEAKER: That's exactly what I said.
[06:01:46] <scribe> Keith? NEW SPEAKER: Keith draij. So I think what I'm
[06:01:53] <scribe> hearing is also you don't want this document to go through the other
[06:01:56] <scribe> group of approval, which is informational draft, expert
[06:02:00] <scribe> review, A D responses. You want to go to a working item.
[06:02:05] <scribe> Is that what I'm hearing? Decide one or the other of those as
[06:02:07] <scribe> well. NEW SPEAKER: We haven't decided that yet
[06:02:10] <scribe> actually. NEW SPEAKER: But that's actually fairly
[06:02:13] <scribe> critical, because the author needs to know whether he needs
[06:02:18] <scribe> to work in tie span and bring it through the expert review
[06:02:21] <scribe> processor work on it here. NEW SPEAKER: Let me make a
[06:02:25] <scribe> strong opinion that just because something is an event package
[06:02:27] <scribe> doesn't mean it should be informational. We never thought
[06:02:30] <scribe> presence or dialogue should be informational. There's nothing
[06:02:35] <scribe> about this that says cable, wire line, wireless, D S
[06:02:39] <scribe> L, Europe, America, IP and SIP is the same everywhere. This
[06:02:43] <scribe> feature should work the same everywhere. This has to be
[06:02:46] <scribe> proposed standard inter operate. NEW SPEAKER: What I'm
[06:02:50] <scribe> saying, we have nltd decided that yet. We don't know if we
[06:02:53] <scribe> would add it to the SIPPING group and we have to discuss with
[06:02:56] <scribe> the area directors, which I believe is a fair summary of the situation right
[06:02:57] <scribe> now.
[06:03:00] <scribe> Okay. Next step as we indicated before. Let's have
[06:03:05] <scribe> discussions on the list. If we have, or we believe that we
[06:03:09] <scribe> get the impression that we need a design team, we will be
[06:03:12] <scribe> forming one. But anyway, the bottom line is that we need more
[06:03:13] <scribe> discussions in the SIPPING working group.
[06:03:20] <scribe> That much, on that one, the next presentation, we have two
[06:03:23] <scribe> presentations more on early media, the first one is going to
[06:03:29] <scribe> be by Richard. Go ahead. NEW SPEAKER: Okay.
[06:03:30] <scribe> Let's talk about early media.
[06:03:36] <scribe> I'll try and get through this quickly so we can safe some time
[06:03:40] <scribe> for Francois. Early media is a problem that's been around
[06:03:44] <scribe> for a long time and there's been a lot of controversy.
[06:03:47] <scribe> What this document tries to do is consolidate a lot of those
[06:03:53] <scribe> discussions and provide focus target to provide a way to have a
[06:03:56] <scribe> reasonable focused productive discussion about Earl wlee media
[06:03:57] <scribe> so we can come quickly to a solution.
[06:04:04] <scribe> So, in that spirit, there's three parts to the document it starts
[06:04:07] <scribe> out with a one paragraph statement of the early media problem
[06:04:09] <scribe> as we see it that needs to be solved.
[06:04:16] <scribe> From that, problem statement, we had stated some requirements,
[06:04:20] <scribe> trying to could consolidate some requirements that had been
[06:04:23] <scribe> stated in the SIPPING list in the past 9 months or so. And
[06:04:28] <scribe> look at the set of possible solutions and how they mrit up those
[06:04:30] <scribe> requirements. Next slide.
[06:04:35] <scribe> So what do we mean when we say early media? There are a couple of definitions
[06:04:39] <scribe> around. Sort of working definition right now, is that
[06:04:43] <scribe> early media is media that comes before a 200 okay response.
[06:04:46] <scribe> But in between an invite and the 200.
[06:04:53] <scribe> This happens for a lot of reasons, I'm not an expert in SIP I don't
[06:04:57] <scribe> know all of them, but I think I B R and T S P
[06:05:01] <scribe> Gateways tend to create these situations. It causes a lot of
[06:05:02] <scribe> problems.
[06:05:09] <scribe> So, why is this a problem? Why is it a problem that we get
[06:05:13] <scribe> media before we get a 200 okay, speaking as an offerer here?
[06:05:17] <scribe> My understanding is, the problems arise because there's
[06:05:20] <scribe> essentially an asymmetry of the information. I as the
[06:05:23] <scribe> offerer err have no information about what's
[06:05:29] <scribe> comesing to me. While people who are sending information
[06:05:31] <scribe> to me have full information.
[06:05:36] <scribe> So there's a lot of problems that result with this. When I
[06:05:40] <scribe> send out an invite that forks, I get potentially lots of media
[06:05:43] <scribe> streams, and I have no way to differentiate them based on
[06:05:49] <scribe> signaling. Security, if I'm using Mike ee or something
[06:05:52] <scribe> with a different exchange, there's no way I can use, I
[06:05:56] <scribe> mean, there's no way I can use security, in half around trip.
[06:05:58] --- mlepinski has joined
[06:06:02] <scribe> So, the draft uses this definition of early that I called it here.
[06:06:07] <scribe> Not that early media is media before a 200, but that early media
[06:06:11] <scribe> is media that comes to the offerer before the offerer has
[06:06:14] <scribe> received an answer to its SDP offer.
[06:06:19] <scribe> So, this is an important distinction because this allows media
[06:06:25] <scribe> to come before the 200 okay. But it's, it provides the full
[06:06:28] <scribe> SDP negotiation before media starts flowing. Next slide,
[06:06:29] <scribe> please.
[06:06:37] <scribe> So, our goal here then is to insure that the offerer always
[06:06:40] <scribe> receives an answer before media starts dmroing. So what's
[06:06:44] <scribe> the solution? Well, you can either get the answer to the
[06:06:47] <scribe> offerer before the media, or push the media back until
[06:06:51] <scribe> afterwards. So, I think what we need to solve this, is a
[06:06:56] <scribe> normative update to the appropriate RFCs, normative
[06:07:01] <scribe> because, well, it needs to happen everywhere.
[06:07:05] <scribe> So we need to update the appropriate RFCs that require an
[06:07:09] <scribe> SDP answer to be received by the offerer before there's media.
[06:07:13] <scribe> So, in order to do that, we have to have what I call
[06:07:17] <scribe> reliable transport here. And that means reliable at an
[06:07:20] <scribe> application layer. So, we need to have a transport, a
[06:07:24] <scribe> message that gets the SDP to answer back to the offerer, so
[06:07:26] <scribe> in such a way that the answer err knows that the
[06:07:32] <scribe> offerer has been received. So for instance, a reliable 183
[06:07:35] <scribe> message, where reliability is provided by PRACK or stun request or
[06:07:36] <scribe> whatever.
[06:07:43] <scribe> So, we need reliability, and we need to clarify, you know,
[06:07:46] <scribe> provide a clear set of rules about, you know, whatever the
[06:07:49] <scribe> transport is, that we use, we need to provide rules for
[06:07:53] <scribe> people who use that mechanism for when they can then send media in
[06:07:58] <scribe> a way that complies and makes sure that it's, the offerer has
[06:07:59] <scribe> received the answer.
[06:08:07] <scribe> Next slide. So this is the outline of what something would
[06:08:11] <scribe> look like. We just add one message here, or two. We
[06:08:15] <scribe> have an SDP answer going back to the offerer err in between, you
[06:08:17] <scribe> know, hopefully, as soon as possible after the invite is
[06:08:22] <scribe> received. So that media can start flowing as soon as
[06:08:23] <scribe> possible. Next slide.
[06:08:31] <scribe> So, there's been there was a long thread on the SIPPING list
[06:08:34] <scribe> either shortly before or shortly after Montreal. NEW SPEAKER:
[06:08:37] <scribe> I have a question on the last slide. How does the U A S know
[06:08:41] <scribe> if it starts sending. What's the signal that tells I dash NEW SPEAKER:
[06:08:45] <scribe> It's not in there. You're correct. There should be some sort of
[06:08:48] <scribe> ACK. Some sort of application.
[06:08:55] <scribe> So, there's along thread on SIPPING a while back about this.
[06:09:00] <scribe> That lots of people proposed solutions and none of them have
[06:09:03] <scribe> really gone forward. The oldest solution out there that I
[06:09:09] <scribe> know of is RFC z 3960 which defines these two ab tract
[06:09:13] <scribe> models for doing early media. There's early session media
[06:09:17] <scribe> around, nobody implements that. People
[06:09:22] <scribe> propose using a reliable 183 message with PRACK
[06:09:25] <scribe> acknowledges. There's certain ways to use ice to
[06:09:26] <scribe> make sure all answers get back.
[06:09:31] <scribe> But none of these are mandatory implement. Which means you're never
[06:09:34] <scribe> guaranteed that the other end is going to support it. All
[06:09:37] <scribe> these, you know, came up against objections on the list.
[06:09:40] <scribe> So, what I'd like to do here, and what I tried to do in the
[06:09:43] <scribe> document, is consolidate all of the objections that were
[06:09:48] <scribe> raised on the list against all of these various proposals.
[06:09:50] <scribe> Into a single list of requirements that we can then work
[06:09:53] <scribe> against. Next slide, please.
[06:10:02] <scribe> So, the base requirement is to solve the problem. To insure there's
[06:10:05] <scribe> an answer before media flows. Given that, we
[06:10:08] <scribe> want to do that with the minimal amount of
[06:10:11] <scribe> additional messaging beyond the single round
[06:10:14] <scribe> trip to insure the answer has arrived. We need to have well define
[06:10:18] <scribe> backward compatibility. Make sure nothing else brakes.
[06:10:25] <scribe> Whatever the solution is, we need to re define, the relevant
[06:10:31] <scribe> RFCs that define interaction with I S D N and P S T N networks.
[06:10:36] <scribe> From a security perspective, we are adding some addition of
[06:10:39] <scribe> state potentially so we need to look at for service
[06:10:42] <scribe> opportunities, and ( Denial of service opportunities.)
[06:10:47] <scribe> And whatever the solution is, we need to minimize IP R constraints which
[06:10:49] <scribe> is the usual practice in the IETF.
[06:10:55] <scribe> And I'll paws here to pause here to ask people
[06:11:00] <scribe> if there are any other requirements that they think should be
[06:11:03] <scribe> included in this draft? NEW SPEAKER: Francois
[06:11:07] <scribe> speaking. The answer to that question depends on what is the
[06:11:13] <scribe> scope of what you're trying to fix? And it seems to me, I
[06:11:19] <scribe> basically disagree with the terminology you're using, either
[06:11:24] <scribe> with the terminology you're using, the term early media for
[06:11:29] <scribe> example, to refer to media before the answer, okay. So to
[06:11:35] <scribe> me, that's absolutely not what early media is. Although it's
[06:11:35] <scribe> --
[06:11:36] <scribe> NEW SPEAKER: Okay. (Several people talking.) NEW SPEAKER:
[06:11:40] <scribe> So if you're drying to solve the problem of early media, and
[06:11:44] <scribe> if you use the term early media, in the way I think most of
[06:11:52] <scribe> the industry is using it, which is providing inbound tones
[06:11:56] <scribe> and announcements before answer, and by answer, I mean if answer of
[06:12:03] <scribe> the call, then what you have in your document is extremely
[06:12:06] <scribe> insufficient. It's really only looking at a tip of the
[06:12:10] <scribe> iceberg. And it's really only one small problem.
[06:12:16] <scribe> So, either we expand your document to have many more
[06:12:21] <scribe> requirements, to tackle this, or we change the terminology and
[06:12:26] <scribe> explain that really, the problem you're trying to address is the
[06:12:32] <scribe> fact that the media can happen before you get the answer and
[06:12:34] <scribe> cause a certain set of problems.
[06:12:40] <scribe> I personally think that, you know, the, as a group, we
[06:12:44] <scribe> probably need to look at all of this. But I don't think it's
[06:12:47] <scribe> necessarily a good idea to try to put all these requirements in
[06:12:48] --- mayumi has left
[06:12:51] <scribe> one dock. Because I don't think we'll ever solve it. So
[06:12:55] <scribe> my advice would be to try to shrink the
[06:13:00] <scribe> scope of what you're looking at, to what you have in your
[06:13:02] <scribe> document and just change the terminology. NEW SPEAKER: Sure. NEW SPEAKER:
[06:13:06] <scribe> I think we can look at is it a good idea to do what you're
[06:13:13] <scribe> proposing, which is essentially to disallow media before you
[06:13:17] <scribe> get the answer, and you know, vote on that at some point.
[06:13:19] <scribe> But dash NEW SPEAKER: Yes, I've tried to maintain a
[06:13:24] <scribe> fairly strict scope, and maybe that's, that doesn't
[06:13:26] <scribe> encompass what people mean by early media. NEW SPEAKER:
[06:13:29] <scribe> Correct. I think you did, but the terminology when I
[06:13:32] <scribe> first read it, I thought he's completely missing the boat on
[06:13:36] <scribe> what the problem is. Maybe he's not, maybe his terminology
[06:13:40] <scribe> is too good for his own good. It's too vague or too and
[06:13:43] <scribe> compassing for your own good and I think that's
[06:13:45] <scribe> the key here. NEW SPEAKER: We're going to take Dave,
[06:13:49] <scribe> Chris ter and then Ron. NEW SPEAKER: I will say what I
[06:13:53] <scribe> said dwo minutes ago ingest and now I'll say it seriously.
[06:13:58] <scribe> We do not have an early media problem. We have a late
[06:14:03] <scribe> billing problem. NEW SPEAKER: Kristen. Yes, I
[06:14:09] <scribe> mean, I do agree what Francois said, there's probably more to
[06:14:14] <scribe> this, I do support the fact that yes, we should get an SDP before
[06:14:18] <scribe> we get the answer. So I think an R T P, maybe, in other
[06:14:18] <scribe> places.
[06:14:24] <scribe> What I do have, my main comment is about this, because when I read
[06:14:27] <scribe> bullet three, it says backward compatibility with SIP as
[06:14:32] <scribe> defined today, and listening to presentation, seems like
[06:14:37] <scribe> you want to solve this using RFC 3261 only. I think that's what you're
[06:14:41] <scribe> trying to do for many years already and I think we have, you
[06:14:47] <scribe> know, we have, you know unless we look at another concept as
[06:14:52] <scribe> was proposed by Dave here, but I mean, if you we look at
[06:14:56] <scribe> early media, as you describe it, I think it's not going to
[06:15:01] <scribe> be solve able by 3261. We tried it for many years. But
[06:15:03] <scribe> maybe I misunderstood. NEW SPEAKER: Right. NEW SPEAKER:
[06:15:11] <scribe> Rohan. I think that we should finish ice and see if, with
[06:15:14] <scribe> we get through ice, if this problem goes away by itself.
[06:15:18] <scribe> If it does, that's less work that we have to do. NEW SPEAKER:
[06:15:24] <scribe> That may be. NEW SPEAKER: Okay. So, yes. Please
[06:15:26] <scribe> continue the discussions on the list. NEW SPEAKER:
[06:15:29] <scribe> Yes, I think we can let the rest of this presentation go. NEW SPEAKER:
[06:15:33] <scribe> Okay. NEW SPEAKER: So now, Francois will be
[06:15:37] <scribe> presenting on behalf of Brian, that couldn't make it here. NEW SPEAKER:
[06:15:48] <scribe> Also on early media, or late billing. NEW SPEAKER:
[06:15:50] --- mayumi has joined
[06:15:56] <scribe> Okay. All right. So I'm Brian stuck customer err.
[06:15:58] <scribe> So,
[06:15:59] <scribe> ( Stuck ker. ) NEW SPEAKER:
[06:16:02] <scribe> NEW SPEAKER: Let's go to the next slide.
[06:16:11] <scribe> This, the problem that this draft is addressing is
[06:16:15] <scribe> a completely different problem from the
[06:16:18] <scribe> previous one we just looked at. And I really hope that we
[06:16:22] <scribe> can keep that in mind when we go through this document. If
[06:16:27] <scribe> you remember, I think it was a previous IETF, Brian had a
[06:16:30] <scribe> document that was explaining all the really,
[06:16:35] <scribe> really ugly hacks that we've seen in the wild, for
[06:16:44] <scribe> allowing, I guess service providers to provide announcements or
[06:16:49] <scribe> tones or things of the like, before the call is answered by
[06:16:54] <scribe> the, typically by the Hugh man on the other end.
[06:16:58] <scribe> So, that's what we mean by early immediate yeah. So it's a
[06:17:03] <scribe> much different problem from the media we just talked about.
[06:17:09] <scribe> The mechanism that is used by this draft is actually, and I'll
[06:17:13] <scribe> explain that in a little bit more detail later, is really
[06:17:22] <scribe> essentially fairly simple and, the concept is fairly simple.
[06:17:26] <scribe> It says, basically, just treat the other, the early
[06:17:28] <scribe> media as a completely separate dialogue. So I'll show that
[06:17:29] <scribe> later.
[06:17:36] <scribe> As opposed to trying to keep it with the same dialogue that you
[06:17:38] <scribe> have for establishing the call.
[06:17:46] <scribe> This is handled by, well, so that point there is actually kind
[06:17:51] <scribe> of orthagonal to this proposal. But if you want to, one
[06:17:55] <scribe> further aspect to this, if you want to, you may actually want to
[06:18:02] <scribe> have the pay load type different for the early media than the
[06:18:06] <scribe> final media, to allow it to distribute a name between the
[06:18:11] <scribe> two, which means that you, the, the person that's, or the
[06:18:15] <scribe> user agent that's receiving the media has a clear indication of
[06:18:18] <scribe> when you're switching from early to the final media.
[06:18:28] <scribe> It is an alternative to RFC 39 59. Minimum new protocol, protocol
[06:18:31] <scribe> level, the requirements are not really big. However, from
[06:18:35] <scribe> a user agent perspective, it is a fairly big change. So
[06:18:36] <scribe> let's move to the next slide.
[06:18:39] <scribe> I'm not going to go through this. But basically, what it
[06:18:45] <scribe> shows is you have one session implementation, initiation.
[06:18:50] <scribe> There's a little, in the response, you'll get something
[06:18:54] <scribe> that indicates where do you go to get your early media, and
[06:18:59] <scribe> that's a SIP URI and you do that invitation, if you support
[06:19:04] <scribe> this. In real time. During the call. And you can get
[06:19:08] <scribe> your media from a separate source, really, than the final
[06:19:08] <scribe> source.
[06:19:12] <scribe> And I'll explain that later. So let's move -- and it also
[06:19:15] <scribe> shows the pay load type at the bottom.
[06:19:21] <scribe> Let's go to the next slide.
[06:19:26] <scribe> NEW SPEAKER: The slides are available on the IETF meeting
[06:19:29] <scribe> material site. NEW SPEAKER: So some of the
[06:19:33] <scribe> comments that we have on the mailing list, I guess, related
[06:19:36] --- nils has left
[06:19:38] <scribe> to, you know, how is this different from a 39 59, RFC 39
[06:19:44] <scribe> 59, what it really does, it uses an overlapped offer
[06:19:50] <scribe> answer, the early media, offer answer is actually inside the
[06:19:52] --- nils has joined
[06:19:56] <scribe> late media over answer, that's what we have in 39 59.
[06:19:59] <scribe> The first observation we have seen is that, I'm not aware of
[06:20:08] <scribe> any implementation of this, there the industry, and we
[06:20:11] <scribe> believe the reason why is that it actually has a set of
[06:20:15] <scribe> problems which basically, well, I'll explain that in the next
[06:20:15] <scribe> slide.
[06:20:23] <scribe> The mechanism proposed in this document is actually mentioned in
[06:20:26] <scribe> RFC 39 59. They mention, oh, why don't we don't use
[06:20:30] <scribe> that, and then it says, it has a bunch of points on
[06:20:36] <scribe> why we shouldn't do that and instead use the embed offer
[06:20:39] <scribe> answer. And by the way, Brian saw that before he wrote it,
[06:20:43] <scribe> and I pointed it out to him, that it might be a good idea to explain
[06:20:46] <scribe> why we don't think that's actually accurate.
[06:20:49] <scribe> So the points that are made is that it's supposed to be
[06:20:53] <scribe> simpler, lacks synchronization, lack of
[06:20:55] <scribe> synchronization problem. All the -- so the point that you
[06:20:59] <scribe> see here are everything that are the justification on why a separate
[06:21:02] <scribe> dialogue would not be a good idea. Next slide.
[06:21:11] <scribe> 39 59 is simpler. We would actually kind of disagree with
[06:21:15] <scribe> that. We kind of think that's why people have not
[06:21:20] <scribe> implemented this. 39 59 is relatively simple if the end point providing the
[06:21:25] <scribe> early media is actually the same end point that's answering the
[06:21:30] <scribe> call. So if you have a big gigantic power sucking
[06:21:35] <scribe> back to back user agent type of device, that's a contact
[06:21:38] <scribe> center, with say, phones that are hooked on it. It could work
[06:21:44] <scribe> fairly well. But if the end of ice is actually answering the
[06:21:49] <scribe> call is a SIP phone, then it's actually fairly clugy,
[06:21:53] <scribe> because you have to muk around with the SDPs, you
[06:21:57] <scribe> break 4474. You do a bunch of nasty things. NEW SPEAKER:
[06:21:59] <scribe> Just the point is to separate early can
[06:22:00] --- nils has left: Logged out
[06:22:02] <scribe> dialogues to different points, just go ahead. I
[06:22:04] <scribe> don't agree with your comment. But go ahead. NEW SPEAKER:
[06:22:05] --- nils has joined
[06:22:08] <scribe> So here's a comment. Let's say you're using 3474
[06:22:15] <scribe> and the far end is the, is providing its U D P it won't work
[06:22:18] <scribe> because it's not checking. So you have to have a back to back
[06:22:23] <scribe> user agent, in 39 59 to modify the SDP.
[06:22:26] <scribe> NEW SPEAKER: As I said, I mean, there are ways to go
[06:22:29] <scribe> around that, but let's not discuss that. Just go ahead. NEW SPEAKER:
[06:22:35] <scribe> The synchronization problem, I would say that it's probably, if you have
[06:22:39] --- hb47713 has left
[06:22:40] <scribe> lots of controls, it's probably ease yer to synchronize with 39
[06:22:44] <scribe> 59 than it is with this thing. So it kind much works better
[06:22:49] <scribe> in sink
[06:22:51] <scribe> where sink synchronization is not an
[06:22:53] <scribe> issue. Announce ments is an example.
[06:22:58] <scribe> If you really need to be tied to the media, like a contact
[06:23:01] <scribe> center, then you may want to do the termination of the media in the
[06:23:04] <scribe> far end.
[06:23:08] <scribe> NEW SPEAKER: Just a question. As do using pay load,
[06:23:14] <scribe> seems kind of clugy to put it mildly. Why not a source is
[06:23:17] <scribe> type things or all kinds of R T P mechanisms. NEW SPEAKER:
[06:23:21] <scribe> None of them work. I mean, people change the S S R C all
[06:23:25] <scribe> the time for whatever reason. So, it's, I have never
[06:23:31] <scribe> seen people that manage to, and you can't signal it either.
[06:23:34] <scribe> So it's very difficult to dash NEW SPEAKER: Just a
[06:23:37] <scribe> discussion, source description for S S Cs NEW SPEAKER:
[06:23:42] <scribe> So you're talking about S R C or something else NEW SPEAKER:
[06:23:46] <scribe> MMusic. S S R C. NEW SPEAKER: If you can show me
[06:23:47] <scribe> implementations where you can
[06:23:52] <scribe> guarantee the S S R C is not changing very arbitrarily, I'd like to
[06:23:57] <scribe> see that. But that's certainly not what I have seen. NEW SPEAKER:
[06:24:01] <scribe> Well, you only care that it changes between early media and
[06:24:05] <scribe> real media. That's the only change -- changes later is not
[06:24:07] <scribe> an issue that you're concerned about. NEW SPEAKER:
[06:24:09] <scribe> Right. But my point is, it could change for other reasons
[06:24:11] <scribe> than that. NEW SPEAKER: Let's take it off line. NEW SPEAKER:
[06:24:18] <scribe> Like a codec that, let's say, a Gateway for example, and
[06:24:23] <scribe> they, it re sets or something like that. Then you'll an S R
[06:24:26] <scribe> C change. But your point is taken. There might be better
[06:24:29] <scribe> ways to do this and I don't think this is central to this at
[06:24:31] <scribe> all. I actually think it's a separate topic. Yes? NEW SPEAKER:
[06:24:39] <scribe> Two comments, I think that you know, when we
[06:24:45] <scribe> have discussions which was raised due to my draft
[06:24:51] <scribe> that there should be a way to, you know, identify media
[06:24:56] <scribe> with just dialogue. We don't have tra that today.
[06:25:00] <scribe> You can make use SDP parameters. But that may not work. I
[06:25:04] <scribe> think that's a generic thing that I think we would be able to work
[06:25:06] <scribe> on at some point. Which could also be applicable to this.
[06:25:09] <scribe> But my comment on your specific solution is, because when you
[06:25:13] <scribe> had a call flow of your slides, you know, earlier. I
[06:25:16] <scribe> think what you're showing here is an example when the early media
[06:25:22] <scribe> comes from an entity of which is not in the part of the initial
[06:25:24] <scribe> invite. And yes, in that case, it could be a good thing
[06:25:28] <scribe> to say, send another dialogue there and get the early media.
[06:25:33] <scribe> But if the early media comes tr the same entity where the
[06:25:36] <scribe> final media will come, it may be a Gateway for example, I
[06:25:39] <scribe> don't see a reason why the UAC should have to send another
[06:25:43] <scribe> invite to the same location. You can create two
[06:25:49] <scribe> dialogues just by changing the to tag. I mean, you sent
[06:25:54] <scribe> one with two tag X and later stage when you send a 200, you
[06:25:57] <scribe> sent it with two type Y. This is also discussed on the
[06:26:00] <scribe> mailing list, and it has different names, some of the people
[06:26:03] <scribe> call it simulated forking, fake forking,
[06:26:07] <scribe> whatever. But you don't need to send two invites to the same
[06:26:09] <scribe> place. Thank you. NEW SPEAKER: I agree. That is
[06:26:12] <scribe> absolutely correct. It is the first case that he's trying to
[06:26:12] <scribe> address here.
[06:26:23] <scribe> GRUU and neither case is optional. This sentence there does not
[06:26:27] <scribe> introduce service interaction issues related to services that
[06:26:31] <scribe> may be wrongly applied to the new dialogue, we had no clue
[06:26:34] <scribe> what this was supposed to mean, so you can really answers
[06:26:39] <scribe> that. NEW SPEAKER: By the way. I'm not going to try
[06:26:42] <scribe> to hum on anything here. So this is all to go to the mailing
[06:26:44] <scribe> list. NEW SPEAKER: You want to clarification on what that
[06:26:47] <scribe> means or NEW SPEAKER: In you want to do it now. Sure. NEW SPEAKER:
[06:26:50] <scribe> In 30 seconds. Basically, it means that some people have, you
[06:26:53] <scribe> know, like invites, they can come invite I don't like this
[06:26:57] <scribe> service, right and they can have a way to actually
[06:26:59] <scribe> distinguish if that was, you know, an incoming invite,
[06:27:03] <scribe> related to the other dialogue or if it was a real nr coming
[06:27:06] <scribe> invite in a call. This was discussed actually when we were
[06:27:12] <scribe> doing 3261, even before that and dhavs the situation at that point.
[06:27:16] <scribe> So that was meant in this RFC, actually. NEW SPEAKER:
[06:27:20] <scribe> So we have, in other words, we would have, if we were to do something
[06:27:24] <scribe> like this, we to have to discriminate somehow. NEW SPEAKER: To
[06:27:26] <scribe> address that issue. NEW SPEAKER: Different type of
[06:27:31] --- bpenfield has left
[06:27:32] <scribe> invite. NEW SPEAKER: Better fire wall management. We
[06:27:35] <scribe> actually didn't really agree on this, because in our opinion,
[06:27:37] <scribe> if you have two dialogues, this looks likes
[06:27:40] <scribe> two way fire wall looks like two different calls. The other
[06:27:44] <scribe> approach, basically, if you're thinking of a fire wall,
[06:27:49] <scribe> that does the, like an A L G type thing, then it has to understand
[06:27:52] <scribe> the embedded offer answer. So I think this is, I think we
[06:27:57] <scribe> were a little bit too fast on the trigger, when we did this
[06:28:02] <scribe> analysis, in 39 59. Let's move to the next slide. NEW SPEAKER:
[06:28:05] <scribe> I thought it was the last one. NEW SPEAKER: It is. NEW SPEAKER:
[06:28:12] <scribe> So, I mean, I don't think I want a hum right now. What I think, you
[06:28:18] <scribe> know, the conclusion I'd like to see here is that, I
[06:28:23] <scribe> believe we have not necessarily done a perfect job with 39 59
[06:28:29] <scribe> on how to address cases where the, you're trying to provide
[06:28:37] <scribe> announcements in bound. And still blur the call to a
[06:28:40] <scribe> terminating end be point and how do we address that. That is
[06:28:44] <scribe> something that we is important to us. We have lots of
[06:28:48] <scribe> situations where every call needs to have some sort of
[06:28:54] <scribe> announcement. And you kind of need to have a mechanism to
[06:28:57] --- ben has left
[06:28:59] <scribe> deliver that without requiring a back to back user agent type
[06:29:04] <scribe> thing in the middle. So, that's what I would like to bring
[06:29:07] --- ttfr has left
[06:29:08] <scribe> back to the list. NEW SPEAKER: Yes. Exactly. I
[06:29:11] <scribe> mean, the thing I see in this presentation-s that when we,
[06:29:16] <scribe> spees fi 39 59, there was general
[06:29:19] <scribe> agreement that that was requirements and that was a good thing
[06:29:24] <scribe> to do. That's why we published the RFC. It's obvious as far as I
[06:29:26] <scribe> know, nobody has deployed that. So it would be
[06:29:30] <scribe> interests ing to more than do a technical comparison with 39
[06:29:37] <scribe> 59 and say this is better or worse, for any new solution,
[06:29:41] <scribe> to analyze why this will be deployed. Right? Analyze why 39
[06:29:42] --- nils has left
[06:29:46] <scribe> 59 hasn't been deployed and why any new mechanism could be
[06:29:50] <scribe> deployed in a progressive way. Because we cannot have,
[06:29:52] <scribe> from tomorrow on, everybody implements that.
[06:29:55] <scribe> So, I would like to, for all these drafts that we get every
[06:29:59] <scribe> now and then, analyzing early media, to actually tackle
[06:30:01] <scribe> specifically that problem. We need something that is
[06:30:03] <scribe> deployed, because I have the feeling that sometimes we are
[06:30:07] <scribe> trying to push down the implementers
[06:30:10] <scribe> dlots, specifications without really thinking who is going to
[06:30:15] <scribe> deploy that. And I have the feeling that we have to play more
[06:30:16] <scribe> attention to that.
[06:30:20] <scribe> I would like to hear any further opinions or suggestions or
[06:30:22] <scribe> comments. Chris ter. NEW SPEAKER: Yes. Chris ter
[06:30:26] <scribe> home bering. I hope we don't need to go into this, you
[06:30:30] <scribe> know, tie span, what should I do and what should they do
[06:30:33] <scribe> discussion. I just like to get feedback on what happens in tie
[06:30:40] <scribe> span. Actually with de did, we had early media study and actually
[06:30:46] <scribe> we did, I wrote it myself, a cooperation between 39 59 and
[06:30:50] <scribe> a solution, which tie span has documented, which is
[06:30:55] <scribe> basically that the one I mentioned here earlier, about using
[06:31:00] <scribe> different two tags, it's documented in tie span if
[06:31:04] <scribe> anybody is interested. I can you know, show it. It's a little,
[06:31:08] <scribe> again, it's a little different scenario than the one you're
[06:31:12] <scribe> showing, because they know there they're sending early media
[06:31:15] <scribe> or at least creating the dialogue. Again, it's different.
[06:31:18] --- guido.franceschini has left
[06:31:20] <scribe> But I earn personally think that dash but to come back to this cooperation
[06:31:24] <scribe> study, maybe that's something that, you know, can be
[06:31:27] <scribe> brought here also, to IETF as part of this work if people are
[06:31:30] <scribe> inltd. I mean, just, this is what's happened. NEW SPEAKER:
[06:31:34] <scribe> Yes. Please send a pointer to that document to the SIPPING
[06:31:38] <scribe> mailing list, because I think that's something that's SIPPING
[06:31:40] <scribe> should have an opinion on. NEW SPEAKER: Yes. I
[06:31:43] <scribe> mean, I need to of course figure out whether it can be
[06:31:46] <scribe> distributed, but again, since I wrote it myself, I can
[06:31:48] <scribe> write it again in another format. NEW SPEAKER: Is NEW SPEAKER:
[06:31:51] <scribe> So you mean it's not a public specification? NEW SPEAKER:
[06:31:56] <scribe> It was a contribution. I mean, this cooperation was just
[06:32:00] <scribe> a con trib bution to the tie span meeting. And then the
[06:32:04] <scribe> actual document which specifies this doesn't compare anymore. Because -- NEW SPEAKER:
[06:32:07] <scribe> No. I'm talking about the specification itself. Is it a
[06:32:09] <scribe> public document or -- NEW SPEAKER: I don't know. But NEW SPEAKER: If
[06:32:12] <scribe> you could NEW SPEAKER: Maybe it has more information about
[06:32:14] <scribe> that. Unfortunately I don't know. NEW SPEAKER: If you
[06:32:17] <scribe> can figure that out, that would be great. Robert? NEW SPEAKER:
[06:32:24] <scribe> Well, it's kind of at tej of the conversation comment that I
[06:32:26] <scribe> wanted to make, do you want moo to do that now? NEW SPEAKER:
[06:32:27] <scribe> Yes.
[06:32:28] <scribe> ( At the edge.)
[06:32:32] <scribe> NEW SPEAKER: Sure. This stuff looks complex. A lot of
[06:32:35] <scribe> people are sitting around looking at this going, wow, these
[06:32:39] <scribe> folks are off in science experiment, think about really
[06:32:43] <scribe> strank hard problem mode. But it's a topic that is,
[06:32:47] <scribe> there's going to be market pressure very soon that is significant.
[06:32:52] <scribe> Oncoming around to solve this problem. At the SIP pits the
[06:32:54] <scribe> implementers are starting to spend time
[06:32:58] <scribe> to make up answers to these questions, because, their
[06:33:02] <scribe> customers are running into one of the very large number of
[06:33:06] <scribe> venues and asking for a custom solution to that
[06:33:06] <scribe> problem.
[06:33:11] <scribe> So, it's, you know, I don't think we're to the point where the
[06:33:15] <scribe> house is on fire and we've got to scramble to solve this, but the
[06:33:17] <scribe> smoke is starting to appear in the corners. NEW SPEAKER:
[06:33:21] <scribe> Yes. That's a very fair point. Actually what Chris ter was
[06:33:23] <scribe> pointing out is another sign that, you know, of the fact
[06:33:29] <scribe> that we have to basically look into it and probably, you know
[06:33:33] <scribe> yes, work on it so I guess, what we can do, and we have to wrap
[06:33:36] <scribe> up in one minute, it's just you know, go on discussing this
[06:33:39] <scribe> on the mailing list. I think the feedback was good. And let's keep on working
[06:33:40] <scribe> on it.
[06:33:46] <scribe> Any xhept before we wrap up? Comments.
[06:33:50] <scribe> Okay. Thank you very much. And we'll see you all in
[06:33:51] <scribe> Chicago. Thank you.
[06:33:51] --- thomas.stach has left
[06:33:52] --- scribe has left
[06:34:06] --- hbaosiy has left
[06:34:14] --- hejingtong has left
[06:34:15] --- isudo has left
[06:34:22] --- frodeki has left
[06:34:29] --- ysuzuki has left
[06:34:47] --- csp has left
[06:34:54] --- bman has left
[06:34:57] --- mayumi has left
[06:35:00] --- renee has left: Disconnected
[06:37:07] --- Alan H has left
[06:47:12] --- bhoeneis has left
[06:52:51] --- kafka-j31415927 has left
[07:05:05] --- mayumi has joined
[07:06:01] --- mayumi has left