Internet Engineering Task Force 103, 8 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF103-SIPCORE-20181108-1120

Description

SIPCORE meeting session at IETF103
2018/11/08 1120

https://datatracker.ietf.org/meeting/103/proceedings/

A

So welcome everyone to sip core. We are in the business of needing a note-taker if we could have a volunteer. Please.

A

Thank you, sorry, one more second and you'll jabber scribe. Thank you.

B

Roland is the note-taker. Thank you so welcome to succour and bankok ITF 103. We start with note. Well, hopefully you all have seen this in previous meetings this week. If not, please read on the slides what you're signing up for if you make comments here or participate.

B

New sheets are going around, we have a note taker and we have a jabber relay as you might notice, we're not we're not Jean and Robert. They couldn't make it here to Bangkok, so we're like substitutes, and that gets us to the agenda for today. You're.

C

Not Brian either. Oh sorry, yes- and this has been. Thank you very much for substituting. That's very helpful. No.

B

Worries all right: today's agenda, it's pretty much like one presentation which is Christa on session time or glare.

B

Any agenda bish doesn't look like all right.

B

B

Don't know if you.

A

Say bendy and you know if Jean was planning to join remotely.

D

Okay, can you all hear me yes,.

C

We can okay.

D

Hey this is Jean Mahoney I am participating remotely and just wanted to give a brief update on the drafts first of Cour, so last call has ended for the originating seed of Graham, être draft and Marianne is updating it with that's called feedback and I assume it's going to hit a teletype agenda really soon. The next three drafts listed are underneath the evaluation and then the next page.

D

We have our active working group drafts, so we're going to be discussing social time erase today the rejected.

D

Response code for rejected calls is of interests to the ster working group, its received a little bit of discussion and so far and then finally, the location source parameter for the geolocation header.

D

It has received some feedback, the author's reviewing that and will be updating that draft soon. So that's what I've got for working group status and we can move on to Christopher's presentation.

A

Thank You Jean.

E

Okay, hello, everyone. This is something that's been going on for a while this session, timer layer handling, it's been on a hold for for a little while, partly because on me having focused pretty much on the c.push stuff, but we tried now to move forward with this. So, as you can see here, we've also open a github or actually the the. We already had a github repo for this, but we was in addition to storing the draft there.

E

We also open or try to say using the issue tracker for really opening and trying to log all the issues, because we saw that or at least I. It was very difficult for me to follow some of the email discussions. There are threads which were jumping all over, so we tried to address the issues there. So please have a look so next slide, please, as you can see there, there is also a draft and some people have comment on a draft and okay, so for a first first yeah. It is what it's all about.

E

So this is. This is just a recap: I and unless you have follow Dave's word before the current session, timer RFC, it's very unclear or actually doesn't really describe it at all.

E

When you have simultaneous session time, a negotiation taking place at one simultaneously and what we mean by that is, for example, if you have the initial or even a re-invite transaction, where, where you negotiate the session timer and within that invite transaction, what is still active you may send updates because so precondition or whatever the codec negotiation and also, if in in those updates, you may have session time, area, information and and then you're going to get different responses and and if the different responses have different session, primary information, expiration values, the refresher role and all these things.

E

Who are you gonna trust, for example, if you get the 200 in today invite and the 200 to enough date, which which you know are you gonna trust, and in some cases you may also the sinner invite me and may receive an update request. And then you don't know you know, what's this sent before the 200, okay or after and so on.

E

Best ass message in this shift on the network, so we really need to try to come up with a solution where you don't really have to guess in which order something was sent and- and you know in which order the remote pair and and the intermediary and everything receiving and again this is actually something which is creating big problems in in deployed networks. This is just not an you know, an engineering exercise when you know I read their RFC and didn't have anything else to do so. Let's try to fix some bugs.

E

This is actually causing a lot of problems. So next slide. Please yeah. This swing like I was just gonna say yes at some point, you should read it, but but you don't really have to read a current version, because it's not up-to-date with the discussions we've had I haven't updated it for a long time. There were some people commenting on a text, but but really you don't need to do that.

E

It's gonna be changed pretty much based on the discussions we've had and one reason for that is because initially I was maybe a little too now.

E

You think yeah we only need to update, maybe one or two or three sections and that's it so it's gonna be a short crack, but I say you know, as the discussions have progressed, we've seen that they're, probably gonna, be a little need for more more updates, so I really want, but before I do that and and and before we discuss exactly how it's gonna look like I think we really need to at least in a higher level, try to to to agree on an approach.

E

How we're gonna move forward, then it's easier because otherwise it's just gonna, be you know, walking in the dark and and spending a lot of time yeah. So next, please draft. Please now what's happened since the last meeting and there hasn't happened too much, at least as I said from my side. That's very much because obviously push work. No, however, a few weeks ago, I tried to you know, get this rolling again. We've had email discussions, pretty intensive, thank you to everyone. Who's participated in those like I said earlier. Where are we I?

E

Try to use github to track the issues? As always, all decisions are gonna made be made here or or in the community. We're not gonna make a decision on github, but at least trying to catch the document issues too, and we had a phone call last week or the week before that, where we, where I, really try to talk about the the suggestion that I'm also going to present here to see whether people interested are okay with that.

E

So so you know, I don't come here with a solution and- and everyone disagrees and and again no spinning top so so we'll see what's happened so next. It's like this, not a working assumption here, like some people have said, and I agreed the easiest thing. As far as standardization is concerned, it's just would just be to throw D'arcy away and do session primarily or over again right that that would be easy this way, but that doesn't work because, like I said, this is deployed and everything.

E

So so we need to try to fix it now and also some of the discussions, and also that's partly my fault, really went into discussing other things that people found with the session time I yeah. This is how we could make it better and so on, but I think really.

E

We need to focus on fixing this glare issue really I mean that that's what we need to fix if there are non related bugs sure we can fix those also and like I said: please put them on on on on github, but we're not going to do modification, or at least that's not putting the Charter, and if someone disagrees, please do but we're not going to do magnification just because someone thinks something could be done in a better way. You know session.

E

Time is what it is it has bugs and an our aim is to fix those bugs this.

C

Is then I would implore implore everyone to focus on bugs that are actually breaking things yet in the field.

E

And, as we also say, there is obviously no solution. That's gonna make every existing implementation standards compliant without any change or anything I mean. If that would be the case. We wouldn't have a problem right so, but really we try to come up. You know with the changes that that we need to do, but at the same time try to make existing implementations work.

E

It's obviously not always going to happen like any standard. When you find a bargain and you fix those bugs I mean you may have to update some implementations, I mean that that's life so next slide. Please know the way we split it up is in we're going to modify the UAC procedures or we are I mean this is my suggestion. We're in the UAS and the proxy procedures know the the text you see here is not an extensive list of all the procedures. It's what I think is important as far as this discussion is concerned.

E

Now the thing you see in the text you see in black it's basically existing procedures in the RFC, which one I think they are important point out, but they're not modified ish I mean there may be, you know, maybe not a master shoot, but I mean it. It's it's it's implicit so for an undertakes you've seen violet is basically the change suggestions that I had or new procedure or restriction of existing procedures etc.

E

So for the UAC and then basically, if the UN search, the SE, which is the session expires that are filled in an invite and and the UN must insert the same as see in any update request that is sent while the invited transaction is going non-going. That means before you receive the final response to today in my transaction and so on.

E

So you can't send your invite and have session expires value X and then you send, update and with session expires value Y. If you, for, whatever reason, want to change to Y, you have to wait until the the invite transaction everything is done and and then you can send a new one with with Y or whatever you want now. This is how I want to do now when you have existing implementations day.they this. Even if you do this, you may get conflicting information back.

E

You may get different values in the 200 to invite and the 200 to the update. There is very little to do that. So basically, what we're saying here if the UAC gets conflicting information it really, it really doesn't know what it should do. Just send a new update after again after the invite for a second, it's done. Try try to you know this is the value I want to use, send an update.

E

You are not going to have this invites and updates and everything you just haven't going to have that update transaction so to basically renegotiate the session timer. So next slide. Please, then, the proxy first, how the proxy handle is. The request must reject the I guess, as usually must reject invite or the request if the expiration value is too short.

E

Basically, what are see today say it may do so. It may reject, but I think we should make it stronger. I mean if a proxy thinks that the value is too short, it should reject it. I mean that's, that's what the USC do and the second bullet again violet is similar to UA us see if the proxy inserts or forwards or modifies the session expire value in an invite request.

E

It must do the same thing for all update requests that it receives to make sure that the value is is is aligned now originally I suggested yeah again similar for the UAC was that if there is an ongoing invite transaction? No, as we've had some discussions, it has been indicated that proxy doesn't necessarily know whether there is an ongoing in by transaction, and so basically we're saying here as that it doesn't need to know just insert the values in the same value in all requests.

E

Now, if the proxy knows that whether there is or is not an ongoing transaction, it can, you know, do whatever it wants, but in in general, I think that- and this is also something that plan to put in a draft try to avoid having to renegotiation the the the the session timer I mean from the beginning, insert the value you want. There may be some use. A third party call control use case or something where you really need to renegotiate the session timeout during the session, but in general they shouldn't really be a need.

E

Now, the response handling, if there is.

E

Yep, when the when the proxy gets a response, if it contains s session, expires, if the proxy must not modify it, that's existing procedures and and if the response does not contain a session expires, the proxy may insert it if it remembers that the request indicated support of the session timer. Now this is also existing procedures. One one thing which was raised on on the list was that yeah: this is fine, but is this only applies if the UAC has indicated that it wants to be the refresher.

E

If the USC has indicated that the UAS should be the refresher on the UAS doesn't support session timer, then this obviously is not going to work. So that's a clarification that I think we should put into the draft so next slide, please and then the u.s.

E

again to if, if the request contains SC the u.s. copies they see of the request interval response, this is existing procedures. Nothing strange about that. What I'm suggesting here is that the UAS must not reduce the SC expiration value in their response. Currently, it's allowed to do that. Really. The suggestion here is that, if the US, for whatever reason, wants to do it, there was also a huge use case where the UAS may not even know at that point what value it wants to use.

E

There may be some ongoing precondition, negotiation or whatever, but the suggestion here is that just copy the same value into the response and if the UAS, for whatever reason, doesn't like the value again, one stain by transaction and everything is done, send a new update and try to fix it.

E

The session timer expiration is normally going to be pretty long. I mean we're talking about many minutes in most cases or even more. So it's really not gonna cause any trouble because most likely you're not going to send any refreshes anyway, while everything is ongoing. So in addition to whatever updates you, otherwise gonna send forward so and if the receive request does not contain us, the session expires, but it does contain the indication that the UAC supported the u.s. s. My include session expires in the response.

E

This is also existing procedure, so nothing's changed next slide. Please now there are some open issues. I mean this is not all of them, so so so so I may have forgot something again.

E

Some of the issues I, don't think, are related, and these are not even directly related to this layer situation. Either. I mean these are things which could happen at any time. These are other so-called bugs, which I think would be useful to handle. I don't want to spend too much discussion on them. I just want to raise them in case people are interested.

E

One of the things which was raised was that if you have an on offer update request clear situations, what I mean is that you have update requests which do not contain offer and both end points sentiment at the same time, this was actually a surprise to me.

E

I thought it's covered by the glare situation, procedures that we have RFC, 3, 3, 1, 1, 6, 1, 4, 1, &, 3, 6, 1, etc, but it doesn't because those procedures only apply to when the update contains an offer for whatever reason or actually when both updates contain an offer. So if you send a session refresh request without an offer but and the other end point for whatever reason sends an update- we don't offer for maybe wants to modify something and they collide.

E

There is no procedure for how to handle that sending for 9 month so that we need to discuss. I mean we're. Actually, there isn't is discussion already, should we, you know, apply the four nine one declare handling situations. Also, for this is, should we just I know it's an implementation issue whatever and yeah. This is the second bullet I mentioned. That already is that when the proxy inserts the section expires in the response, the proxy can only insert if the USD indicated that it's willing to refresh, because the u.s.

E

hasn't in the court indicated supporter lever mechanism, then it was also I mean. This is maybe a pure editorial issue, but there was kind of discussion. What initial session refresh request means because initial sounds like this is the first of something but refresh sounds so like this is something that's coming later. So again we will see if we have to fix that somehow, but I mean that should only be an editorial exercise, yeah. So next slide. Please that's it any any comments.

F

Rowland Dutch Telecom I fully support the proposed the proposals and I would like to come to an end, since we are one of the hidden networks with problems on session time. Our real problems. So with regard to that, I would like to see that we come to in solution very soon so and it looks not bad Thank You.

A

Romani at the floor.

G

I also support the proposal and actually wanted to comment on some of the slides.

G

One thing which I would like to mention is on the 9th and then on offer update.

G

Resolving the glare on update is kind is also related to the initial glare issue, because without resolving this as well, there is no easy way to kind of fix up any sort of collision issues, because when we propose that frequently, if we have some sort of initiation collision between invite and updates- and you, both user agents are not clear what the current session or session timer is that we should just do an update transaction.

G

The fact like there is a good chance both of them will do an update transaction will end up with a glare situation and end up exactly where they started. So what so? We kind of need to solve the there. So this so in this problem is related, because there is need to be a way to resolve this again. There are a couple of other comments on otherwise, but it's probably better to do it on list, because it's it's, it's essentially details of how they will be solved.

G

But we just need to kind of look at this issue with the initial, with the session time, a negotiation when multiple transactions and progress and from what we've seen solving it, cannot be done as they just a separate draft which updates the session time. It looks like it requires to be straf, because the old updates are kind of spread out.

G

The session time address so most likely. The the new B's draft would be much easier to comprehend and understand versus having a separate draft which just tries to address this issue, which is going to be extremely confusing.

E

Yeah I agree that I didn't bring that up on purpose, because I didn't really want the discussion to go into.

E

Are we gonna make a beast or not, but I totally agree with Roman I also had some offline discussions, at least with with the chairs I think Ben was involved also and where I basically said that yeah, probably it would be much easier to write a base instead of trying to update because, like I said there there's a lot of sections, we are probably going to be affected if we're trying to, in addition, going to clarify CID session refresh request and so on. It's it. It's gonna be tricky.

E

Now, the the as far as I'm concerned, I, know I, know III, guess gene is still on the line. If we would do abby's I think we need to have a very strong statement that the scope of it. Sometimes we have that, but you know sometimes it's getting. You know sloppy and, and assuming I would be the author that you know I I don't want this to become another never-ending things also, so you know it should be very clear what we're gonna do this.

C

Has been I agree and actually a previous commit a genius online shavelev, but I agree and I was actually going to stand up and say: I don't object to abyss. But if you do abyss, I would like people to be draconian and secure in skill control, which probably means, if we're going to do a business notate the milestone in some way. That says here's what we're fixing and if people want to fix other things they can do their own biz.

A

Alice floors, yours.

D

Thank you. This is Jean. Yes, my first name is Alice I I go by my middle name, so with the keeping the scones firmly in check for this draft.

D

What a quick and dirty requirements draft be helpful where you sketch out what needs to be captured, or you know the list you know break it down and you know here are high-priority bugs. We went to fix. We've identified these enhancements for this, that we're not going to touch them I, or did we just capture that in the mailing list, discussions I, I'm, just kind of tossing that out, as you know, is that something to consider this.

C

Is been again, please don't spin on own requirements. I think people know what the requirements are right. So if the requirements, if we're writing a requirements draft, it I really hope it doesn't and blocking work on the solution, but also keep in mind that you had our group wiki and things like that. That are good places to document things like this, that don't have a need for archival purposes.

C

You know where you're not going to no one's gonna care, what the requirements Travis said after the business published and unless you think there's some reason to keep it. You know that we can describe to the iesg who will start abstaining on things like this, unless we have a really good reason. My.

A

Last two trips been to the isg. They have no appetite for requirement, dress at all.

E

A

E

I from experience.

C

Even I used remember, I can tell you that's very true and.

E

I agree, and in any case, of course, if we would or we do, the bass, there will be a section where we actually describe the changes from from from the previous or the current RFC and so on, but I don't think we need a we've had this requirement our seams before one we had in our TC web.

E

The funny thing was that once we finalized that requirements draft, we have it already done a lot of the solution. Drafts.

E

D

I, you know I I, just poked at that and I'm hearing nope. We don't need it and that's good.

C

Bendy of them see if Paula is wanting to comment on this particular thing or something different. Here me: okay, Paul, yep,.

H

Okay, well just regarding acquirements I, think I'm in violent agreement that we'll need a requirements document that, if we're going to do the best, we order informally enumerate the requirements. We're going to do.

H

And limiting the scope, I also agree for one thing: I think we have. We aren't changing any even really as much about clarifications and not not changing anything, and the one thing I just observed for forever. That I hope we can do, even though it might be optional in some sense, is that nobody ever really understands this thing correctly. I think it was just so poorly.

H

You know that the language of it was so confusing or misleading, or something that I think it just needs a bunch of text improvements just to clarify I, think, but I realized that the most important thing is the erase condition.

E

Yeah I agree, I, mean I, think there's a lot of takes, for example, that can be simplified by bullet points and so on. So if we do it abyss, I mean sure we should also make the we can make the text more readable because I don't just want to copy pasted text which is difficult to understand. But again, that's that's. That's not a technical change, that's and in editorial exercise. So.

G

Again, my suggestion is to limit the scope firmly to or what the value of session timers should be when multiple transactions are in multiple session time. Initiation transactions are in progress. At the same time, if the language we should be new should be written in the more I can in this clear fashion as possible, but again we're writing. This draft trying to clarify things which we are not touching again should probably be out of scope.

G

The commits, because we are, if we're attaching this I kind of getting onto this slippery slope of trying to resolve 10-15 years worth of unclear issues that people can again discuss forever. So just trying to deal with multiple, like with this issue, which is completely undescribed in the current draft and kind of trying to focus on that. If something can be easily fix them, we should fix it. But again that should be pretty much out of scope. We can I try to I want to limit it, so it can be finished reasonably quickly.

C

This has been I was coming up to say: I was exactly what Roman said and I would. If there is text that needs to be made easier to read, because it's ambiguous and it's causing these problems, then by all means fix it. But if there's just other unrelated text that is hard to read, but it's not causing problems right now. I would advise you not to, and the reason for that is when you hit the review process and when you go to IETF last call and you go to a ESG evaluation.

C

If we can just look at a different see what the real changes are. The evaluation is easy. If you look at the different things that aren't related to the technical differences, it becomes very hard. If what happens is people start reviewing the entire document and they start trying to change all this other stuff that without a scope for your stuff, you change, and then we have to get into a roundabout with people to explain. No, that's not what we're working on this time.

C

So I have come to believe that editorial and stylistic improvements that are not material to the change being made in a bid are very risky downstream through the when you start going through the general IETF consensus process. No.

E

I I, agree and I guess I should be clarified. These so called bullet points that I've been looking into and draft and kind of my own. They are all related. It's it's how you create the request. You know what what what header failure in circa don't insert it. So it's not all related to that then there. So there is background text and everything in in the draft. I don't plan to touching that, and so, but again this initial session request refresh that may have, but but but let's see, I think we don't.

E

We don't need to do anything here. I'm just wondering. Is it possible? As always, it has to be confirmed on the list, but could we really make them try to trigger the whole thing already now so asking me whatever someone would object to to so.

A

I think the question becomes is: do we are we coming to a consensus for whatever it's worth in this room on continuing with this draft or with the best effort and having that replace any efforts that are ongoing now. Does.

C

Anyone who have not come to the microphone care I.

E

Mean the thing is that if we would do a piece it would, it would take some time to write the first version of it right.

E

So so, and at least that's not something I want to do unless, unless you know, we know that I'm not saying that you know I'm going to write it and it's blank chick I mean people may have whatever comments on it and that's fine, but but but if people have an issue with the idea of doing an abyss in the first place, I think we should race it now before we start timeing. You know. Writing writing stuff. Now.

F

Roland here, Deutsche Telekom I was in favor for peace, because I was asked so many times from my people how to implement this session timer, because our interpretations going around even with let's say your company- how to interpret this draft and and they're real failures, and we have no business, not only failure we have with with the session timer, so that there are the clear situations.

F

What is when hitting both sides having doing updates and and there's a broken back to back user agent, letting through these requests and everything so, but nevertheless, I would like to see a very fast solution to get the failures out of the network, and if we can hit this code to your presentation say so, that's the scope. What we would like to solve. That's it I, don't care about a documentation, so either we do that what you have done.

F

It takes new text or we could also do the piece which would be more readable for my paper, but nevertheless, I know what to do. Thank you. Okay,.

A

Sounds like from the purposes of what we have in the room right now. The decision is to move to a this effort. Obviously, that'll have to be confirmed on the list, but I think that's the decision and by the way, Chris proof you need any help. I mean I know all this stuff falls to you, but I'm willing to help out. If you need it, yeah.

E

Wonder if Easter XML for the IRC available somewhere, because it's pretty old okay, if not, if not I- think they can.

A

Convert it their.

E

Additional to for that nowadays, right.

C

It's not I believe they are a fee. Editor can provide it. It may not that's the thing.

A

I think they use a conversion tool. It's not perfect.

C

But it's good enough. Women I'm coming to the mic for gene saving, a saving, a saving, yeah a red button, push I! Guess: gene said that she's comfortable, declaring that we have a sense of the room that from discussion so far to go ahead and do a bit. Obviously, that needs to be confirmed on the list.

E

Excellent, that's what I had I think.

A

That's all we have thank you. Everyone.

B

All right, that's the end of the session. Thank you see you in.