ECRIT Meeting - Summary Report 11/20/2008 - 15:40 - 17:30 Compiler: R. Marshall Summary based on two minutes documents (attached at end), Renee & Steve_Norreys I've relisted the agenda items in order and provided a summary paragraph that attempts to capture the take aways for each. 1. • :05 - Agenda Bashing & :10 – Document Status Hannes’ walked through the ECRIT agenda slides, followed by a brief topical discussion on rechartering to include 3 primary areas (LoST maintenance, LoST extensions, and citizen-to-authority emergency service standards (5 starter drafts referenced – see slides). Hannes mentioned the current dilemma around RFC 5031, which for Service URNs, demands a standards-track doc for every additional top-level service label. Since this approach makes timely additions difficult, there is a proposal to possibly create a RFC5031bis, in addition to a couple of draft documents which would help with the justification for such an approach. These are shelter-services and service-classifications. Lead-in discussion over possible Design Team formation around Premature Call Termination – more on this coming up in Brian’s presentation. Another design team proposal discussed for the purpose of outlining common characteristics between emergency service deployments such as are taking place in the UK, Germany, Canada, etc., primarily where the VSP involved uses the IP address to determine the ISP, request location, and route the call. The response from the working group was mostly against the notion of forming a design team, citing that to do so would likely head down the wrong solution path. Whereas the right design team motive may have intended to properly bound the problem, a more accepted approach would be to have a considerations document created, not a requirements document per se. Hannes gave a status on recent activities, on the 5th Emergency Services Workshop in Vienna Austria that included a good 3 day meeting and a Vienna city PSAP tour, (which had no precise location enablement). Links are at: • More info: http://www.emergency-services-coordination.info/esw5.html • Slides: http://www.emergency-services-coordination.info/2008Oct/slides/ • Pictures: http://www.emergency-services-coordination.info/2008Oct/pics/ • IETF ECRIT Tutorial Slides http://www.emergency-services-coordination.info/2008Oct/slides/esw5-tutorial.ppt Also mentioned that Hannes attended the 1-1-2 Roundtable in Poland (http://tinyurl.com/5m4hvs), and the REACH112 Project selected by the European Commission, proposal submitted to Total Conversation CFP (similar to U.S. DOT NG9-1-1 project). 2. • :20 - Finishing PhoneBCP and Framework – Brian Rosen – http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-06.txt – http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-06.txt Brian Rosen gave an update to phonebcp and framework – said that all comments (so far as he knew) have been incorporated, including the removal of the bye from phonebcp. There was discussion around what to do if a URI is missing/not available, whether you go up/down a level. There were some comments posted on the list which may not have been addressed yet, such as if a device can’t find a LoST server, what does it do? There were several comments favoring the inclusion of the OMA/SUPL location protocol as an optional LCP (Location Configuration Protocol) choice. The point was made questioning the applicability of LLDP-MED for the general Internet. Discussion was also around including SUPL and 802-wired networks as an “optional” LCP choices. Brian requested text to be sent to him within one week for this last item to be included. A Hum was taken in the room between a two-optioned approach to changes in the existing text around which LCPs are “musts”. The two options for the Hum, Option 1.) which is to make the wording in phonebcp read, “end points MUST implement both HELD and DHCP, and if the device is an 802 wired device, it MUST implement LLDP. Option 2.) is to change text to as follows, “MUST implement both of HELD and DHCP, period.”, (with any other LCPs mentioned, as a MAY.) The results of the 2 Hums were inconclusive – so chairs will take it to the list. 3. • :20 - SOS Uniform Resource Identifier (URI) parameter for marking of SIP requests related to emergency services – Keith Drage – http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt Discussion around the proposed use of a /SOS parameter within a AOR (or was it Contact – both were mentioned on the slide) header so to facilitate 3GPP’s need for a call marking mechanism – since the presence of a service URN alone in the Route header is (apparently) insufficient. There was explanation given that the placement and use of this parameter is for registration, and for use by the PSTN gateway – well on past the ESRP. The main issue here is about IETF-3GPP divergence risks. There seemed to be several voices among the group in favor of solving the problem – taking on the work – but it wasn’t clear as to in which form. One proposal was to rev the document, list only requirements, another, to create a new document that focuses only on the first requirement – on registration. So a Hum was taken as to whether ECRIT should make this a wg item with a focus only on requirement 1. Result was that the Hum was in favor of the proposed action, with no apparent objections. There was a proposal by Brian to split the document and he would (along with a tbd co-author) create a draft around requirements for call-back, stripping the associated text from the above draft. Discussion around choice of editors for 1st (requirement One – Milan?) draft separate from Brian’s offer to co-author the call-back draft (decision not clarified). 4. • :20 - Report from Design Team about Premature Call Termination – Brian Rosen – http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts Clarification work on requirements as applied to the “call taker” vs. “caller” vs. user agent, “server” or “client”. Also, clarification in text around multi-lines, that nothing would bar use of an additional line – and discussion around proper feature negotiation for “abandoned call” term. PD-1 rapid renotiation topic discussed. Encouragement was given to take any issues to the list. Discussion on rapid reconnection (as currently stated), overriding configuration by user agent – some objections to the notion that the phone couldn’t disconnect (hence might get thrown on the floor), and of regulations which are pushing for this (and in some cases may prohibit this). Clarification that so far, regulation only applies to wired phones, not wireless. Emphasis put on fact that Canada has this regulation and expectation. Request made that a new editor be installed, since Brian seems to have a strong opinion on the outcome. Discussion around whether the requirements can be met through interaction as UI-driven. Some comments that the requirements get refined before taken on as a wg item – that they should focus on the user experience. 5. • :20 - LoST Extension: ServiceListBoundary – Karl Heinz Wolf – http://tools.ietf.org/id/draft-wolf-ecrit-lost-servicelistboundary-00.txt The meeting ran out of time, so Alex did not get a chance to present on the above topic. 6. • :15 – Open Discussion Ran out of time. Meeting adjourned. Detailed Meeting Minutes: Renee ( This is the beginning of the right meeting. About the NEW SPEAKER: So, my suggestions was to have, get some folks to get in the IETF, folks room here, presumably, also guys who wok on routing, for example, since those seem to be preferred mechanisms, or are they different countries, people come up with different mechanisms, so we can investigate those, and then, look into some of those and what we are doing, whether we think everything, just to do, sc sot of an early investigation, and have some discussions some way. But I see, there's some scary faces. p you don't like migrate idea? NEW SPEAKER: Mark, is this an ECRIT issue or geo priv issue? NEW SPEAKER: I believe, because of the context, so, I'm specifically, this is about emergency calling. At least the requirements that I have seen those solutions being brought forward have to do with emergency calling and not finding the nearest Pizza Hut which most people use Google for, and I sus is expect ha the solution space is radically different, if you want to see how some of these guys today look for gentleman ne Rick location based services, to find some services then, you can look at my Nokia phone. NEW SPEAKER: Ray bell list, this is a geo priv issue, not ECRIT. Just total location of persons making the call. NEW SPEAKER: Jon Peterson. So, I think, it probably is worth investigating this, I think it's an interesting top pick. I again, would be very surprised if you managed to constrained it down to the scope you were hoping for. I think this has the po thenks potential to turn into a lot more. You may be able to xwet away with it inform a certain pet but I'm pretty sure this is going to pop up into something a lot bigger, and it might not be bad. NEW SPEAKER: We're just trying to be proactive. That's the spirit m this room. NEW SPEAKER: Here's a buzz word I hate. In addition to hating that buzz word, I think you're going way over board at this point, by saying that we're going to take new work into the working group by forming a design team. Fist you start by figuring out whether the woking group figes it's the right place to do the work and then you fig e out how to tackle it. Stating by saying you want to do a design team, pretty much, you're stating down the wrong path. I'm not at all sure that we should tackle something that has this architecture. Send a location protocol as yet undefined, if they're actually going to listen to us and use the pieces of the tool kit we've put together, to build their architecture, great. But this is heading down the direction that's clearly not in the direction we originally started, and it doesn't appear to re use any of the pieces that we've built. Why is is this our problem? p p this is an emergency services design from these countries, then they may be designing systems we have nothing to do with and that's their prerogative. They're sovereign nations, not our problem. But you know, this isn't our problem as presented and the way you're presenting is it is, this is our problem, how about a design team to solve it and that kind of irritates me. NEW SPEAKER: That you, for your constructive feedback. In this IETF meeting, I hear a lot of of interesting, we should is also get in touch with what the real world does out there, and I thought I make my contribution, make a suggestion, that's something I would like to be looking on. If the group thinks that it's totally bogus and not interested, you know, but it's, it's, but Keith snoochlt Keith Drage. So what is the problem we trying to solve? NEW SPEAKER: What is the problem. Is it related to the IETF? Is it not related to the IETF? You need to actually explain it much better if you're asking for a design team. NEW SPEAKER: Brian Rosen. Two things. The first one is, that this environment is where the regulator forces a relationship between the I S P and the calling network. And we have to decide whether we want to go deal with that. But it is a piece of reality. People get to do that, but keep in mind, that's the environment where this thing works. And the second thing is, just sort of piling on here, if you think thtion this is a good idea, write a document, present the problem, let us read it, and if that results in work that we want to accept, then decide that the document is not a good basis and you wantd to have a design team, blah, blah, blah, that's great. But let's start with the document. NEW SPEAKER: Are you willing to help with the document? NEW SPEAKER: Yes. NEW SPEAKER: Well, I probably don't need to pile on the design team idea, because that one seems buried under a host of problems. I would comment on the following with respect to what Ted said. Sometimes people don't choose were you architecture because they think it's not ready or it's just not there. Sometimes. Sometimes they have concerns relating to deployment or other issues. So one thing to think about here, we stat ted way way far away from the design team, but might be to try to articulate just what led to this designs, what concerns are out there, just to inform people about what is happening and what lead to it and just stop there. And just try to present the point of view, present the design Dee ition es and maybe it's just totally random and has nothing to teach us. That's completely possible. Or maybe there's something in there that we do need to pay attention to. But just write up reality and explain it. NEW SPEAKER: That's a good idea. I like that. NEW SPEAKER: Yes, ditto. Not what he just said, ditto. Write a considerations document. Don't right write a requirements document. Write a consideration document, discussing what this is, because this is the first or second time people have seen this, but it's only one side. Write a document explaining all the situation es, and offerring solutions, but offering directions, maybe. Or proposing directions, proposesing options. And that will convince us or not convince us, but that's a sell job. We need to sell this working group, whether this is something that's in ou charter. I'm okay with it. If you detail it more. NEW SPEAKER: Jon Pete tea son again, again, I think it's not selling this. I think everybody is going to be buying roughly this from other areas, from take your pick. I think the trick is going to be defining the scope actually nai row enough that we can construct work on. And I think there's one step from where this is on the slide to a much wider user space. So I understand why people are objecting to design team but I think I know what property you wanted out of a design team, which is to be able to bound things at the start. NEW SPEAKER: Right. I want to want to do that, rae than )Several people talking.) NEW SPEAKER: Invite the routing area and say this is what we're going to do. You would not need us ever of doing anything about this. NEW SPEAKER: Yes. NEW SPEAKER: So, I want to just, before everybody tack kels you and piles on you putting up the words design team, I think your in stint in some sense is correct to try to find a narrow scope of this, rather than what will certainly turn into a brawl soon. NEW SPEAKER: Roger marshal. I don't oppose a design team, I've been involved in other design teams before documents come out. For example, in geo priv held by our requirements, that started as a design team. I don't see a problem with the requirements elly procedure. I like what Bernard said, I'm trying to characterize the problems that may exist out stl. I think deployments tend to take a path of least resistance, and I feel like, it's not, perhaps worthwhile to try to make other entities take a more onerous path. So we need to kind of learn from what they are facing, both in terms of business and tech logical problems to deploy, to try to adapt internet technologies to that emergency service. NEW SPEAKER: Somebody from the jabber room. He says he or she, these arc textures are stop gap solutions, they are being well deployed in the UK, why does the IETF have to define them too? NEW SPEAKER: Next slide. Thank you, for the feedback, and Steve will probably hate me because he now regrets that he raised his hand as minute taker. NEW SPEAKER: I got tapped on the way through as volunteer. NEW SPEAKER: Next slide. NEW SPEAKER: So, this is essentially the last slide now for the direction. So, a couple of things that happenedd recently, I wanted to point you to. We have one emergency services workshop that got a lot good input. If you go, if you look at the web pages, you can download a couple of slides, I think we now put already our meeting minutes up there, pictures and so on. And you will find just in case you need that, explain somebody the IETF work we have been doing so far, I produced a new version of tutorial slide set is, it was a two our presentation. I also spoke at one one two round table in Poland and so there are also some slides there. And there's one project that was selected by the Europe peen commission that is SIM is lar to the USD O T N G 911 project. So you might, if you are working in that field, with pilots, you might be interested in getting in touch with those folks. NEW SPEAKER: One other things that's not on the slide that just came out, I think today, is IANA, actually is looking at the work done in this working group and the emergency services workshop as their, they're giving some award for visionaries for that. NEW SPEAKER: Excellent. NEW SPEAKER: So, a couple of point test so you can look them up. That was actually logo for the T shirts, so for those of you who haven't been, who haven't had a chance to go there because of the economic situation, so you unfortunately don't have such is a nice T-shirt. Don't ask me what the person is holding in his hand, it's probably mobile phone. Next slide. Only two pictures but I couldn't resist. So, we had a really nice venue, and natural history museum, was that true? NEW SPEAKER: Museum of history. NEW SPEAKER: You were with the dinosaurs? NEW SPEAKER: Yes. NEW SPEAKER: Yes, the museum was closed for the first day -- NEW SPEAKER: I thought that was us. NEW SPEAKER: And we also had P sap in Austria in Vienna police P sap and got some really shocking insights, because they don't have any location from cell phone and 70 percent of the calls are hoax calls and these type of things scare the heck out of us. But it still was nice. Anyway, I'm done. Brian, you are on the spot. [ed. Note: Brian Rosen’s presentation on status update for phonebcp and framework drafts] NEW SPEAKER: Okay. NEW SPEAKER: So. There's a new release of framework and phone B C P. It's. There were a lot of of comments on the previous version and I dealt with all the comments. I removed the line that said don't send by. And subsequent to that, there was a discussion about what to do when the service URI wasn't available, so you got, you're in a country that implements 911 as all emergencies and you get S O S Dot police, what do you do. That's the question. And there's two possibilities. One that says, just, you know, go up a level, just, you know, if you're in that circumstance is, just do what S O S says. And the other one is is, require the loss where we have some mapping for that. Tell the lost server what to do when somebody does that. We ought to say something and I think this is a valid point, we probably ought to say something what you do for emergency calls. This is not a general lost problem, this is specific to emergency calls, you don't want to have it drop, right? So we need to do something. NEW SPEAKER: Ted Hardie speaking. Isn't the first case a degenerative case of the second NEW SPEAKER: NEW SPEAKER: Well, you certainly could. It's, one is that you actually control it. That is, you require the jurisdiction to decide what to do. And the other is a fix dz rule. Just go up a level. NEW SPEAKER: I thought we had this conversation a long time ago and that we had basically said, if they had a mapping, you you used whatever the mapping the jurisdiction introduced was, and if there was no one you went up a level as default. Maybe that's an illusion. NEW SPEAKER: I don't that discussion. I mean, things go on in my mind. NEW SPEAKER: If we did not that discussion it certainly seems like a logical conclusion. The base thing is No. 2 and the first is degenerative case. NEW SPEAKER: I think that's a perfectly good answer. NEW SPEAKER: Keith Drage, I had some is colleagues working for the department and they actually did continue with the emergency call in some form, rather than just file everything together. Is that actually written this this document or is that missing as well? NEW SPEAKER: You mean, the notion that if you don't get -- I'm not sure, what question u asking. If you don't get a route what do you do NEW SPEAKER: Where do we go when we can't find police, we must go somewhere. I'm not sure that we managed to find that we must go somewhere, rather than just say to the user, tough, we can't do anything for you. NEW SPEAKER: Okay. NEW SPEAKER: So can you make sure that's written somewhere as well. NEW SPEAKER: It doesn't say anything, I admit that. You might come up with a suggestion. I can tell you what we do in the U.S. In that case. But yes. NEW SPEAKER: Hand nis, yes, I think, I recall discussions we had about this issue. As he mentioned but I looked up and tried to find something in the e-mails but I couldn't find it. So maybe it was -- NEW SPEAKER: Are you happy with his proposed solution? Which was, you should provide a mapping and if there is no mapping, you know, go up a level. NEW SPEAKER: Yes. NEW SPEAKER: Or down a level? NEW SPEAKER: Yes. NEW SPEAKER: Okay. Next slide. Now, there have been a flurry of ee mailings since I made these slides. So I really can't do this. But, the notion was that I would address the issue that I just raced m the next raised in the next revision, but I would say send it to the IESG anyway. This will never get through the IESG without a revision. So I would like to get opinions, well, you know, to ask your concurrence to send this to the IESG. NEW SPEAKER: Ted Hardie. After your exchange with me on the e-mail list, you saw something about E D 78 from me el yer today. And somebody came up to me before the meeting and said is, what's that meant to say, if you support SIP I N, and that's why -- NEW SPEAKER: Yes. NEW SPEAKER: If it is, put SIP I N in front of it NEW SPEAKER: Yes. NEW SPEAKER: Yes, u correct. NEW SPEAKER: Somebody else cekts ted me. And so (Several people talking.) NEW SPEAKER: Well, it's an error in the spec, it needs to be corrected, but yes, that's what it was supposed to be. NEW SPEAKER: Thanks inform the clarification. NEW SPEAKER: Sorry. NEW SPEAKER: I'm surprised there's not a line at the microphone, with 30072 e-mails. Is it all right. Is this document ready to go? NEW SPEAKER: No. NEW SPEAKER: I think that there were some few e-mails which did not get answered on the mailing list. A few weeks ago, there was a question, posted by Henning, I guess, on what is the behavior of the device if it doesn't find something. NEW SPEAKER: I don't remember that. But, the if the device can't find the lost server, what does it do? NEW SPEAKER: Yes. NEW SPEAKER: It forwards the call, and has the provided e, the, there is text in there that says that, even if the end point doesn't proxy ser very should be prepared to do, adding location, and sending the call, and I'll on try and find the place of that text and site it for you you but I believe it's covered. If it needs to be improvedd a little bit, I'll come up with wording. That's what you're supposed to do. Forward it on and get the next guy to worry about it. NEW SPEAKER: The next thing is st police stop supported S is E Ps which are being discussed to mailing list today. But I wasn't sure if there was any con scene is sus consensus? NEW SPEAKER: Yes. Sorry. Inform those of you who haven't been reading the list, there's a discussion of the list of required configuration protocols to support 689 and there was a suggestion to add sup something to the list, making four instead is of three L C Ps. There is a lot of discussion on that subject, and at this point I don't think that's the right thing to do at all. And I'd like to leave it as it is. NEW SPEAKER: Now would be the time to have that discussion I guess. NEW SPEAKER: I had a few e-mails, first I asked the question that we needed to have that on the list. Second, if they want to add supple, and I T P '80 two Dot 11 on this this. NEW SPEAKER: We had a fairly long discussion when we made that list, whether L D P ought to be on it or not. And the work group at that point, I mean, there was quite a heated discussion about that. Whether it should or shouldn't be on. And it was decided to leave it on. What I think we ought to do, every work group decision is subject to being re visited but usually you have you've got to have a pretty good reason why the original decision was wrong, and if you can come up with that, we can consider it. But we have talked about whether L D P should be on the list or not and it was a fairly lengthy discussion and we got consensus is and that was not a small, we, it wasn't, if ee. It was pretty big. NEW SPEAKER: Can you recall when that discussion took place, how many years ago? NEW SPEAKER: It's Pete tea. Think think two. I think like snchlt Peter. I think like two. Rev two of the dock. So woking group of the document. NEW SPEAKER: So in two years, you've seen deployments. NEW SPEAKER: I think there is deployment of it. NEW SPEAKER: I haven't seen any. NEW SPEAKER: L L D P is used. NEW SPEAKER: Yes, it's deployed. NEW SPEAKER: L L D P met, in particular, is what you're questioning and it's dpee employed. NEW SPEAKER: L D P includes other things than just location. NEW SPEAKER: Yes. NEW SPEAKER: So are they sending location out with no L D P? NEW SPEAKER: So, would it be fair to require from a mobile device to support that? Even if we never use it? NEW SPEAKER: The problem that you have is knowing that the device connected to the, let me try this again. I understand that. But it's really hard to come up with the circumstances. I mean, if you can come up with really really good text that says is you know for sure that L D P is not going to be the supported L C P, that you could let it off. But I think that would be very hard to construct that. NEW SPEAKER: DSL doesn't support it. NEW SPEAKER: Go ahead. NEW SPEAKER: A couple of things about L D P. The initial version was not suitable for use with wireless networks. Okay. And I think everybody was clear on that. So, as a result, that version is only been deployed in wiredd networks. They are in the process of revising it. That will come out and I will say there's still controversy on whether the revise isd version will be suitable for wireless networks. But at least they're trying for that one. So when you ask for deployment, there is no deployment on wireless, and it is not clear that the revision will address that. I personally have is my doubts. But that's basically where the situation is with L D P NEW SPEAKER: Thank you. NEW SPEAKER: If I remember the conversation two weers ago two years ago. Obviously, L L D P is only good on 8 O two networks. It does not run on non 8 O 2 networks. But it's pervasive is enough that we included it in our document anyway. NEW SPEAKER: I want to take this to the list and I want to make sure that Peter who have I haven't seen for a little will, but I think is still around, could respond, but I could imagine, we could say, and if you are on an 802.11 network, you have to have L D P. But I don't know dab dash NEW SPEAKER: Just 8 O two vrments NEW SPEAKER: Just '80 twochlt. NEW SPEAKER: Wired. NEW SPEAKER: (Several people talking.) NEW SPEAKER: Why don't we work that out. But right now, -- NEW SPEAKER: The thing is, that the minute you start carving out exceptions, we start losing inter operability really quick. NEW SPEAKER: 8 O two itself would not make that statement, I don't believe. But L D P is its solution. I don't think you would see that out of an 8 O two if you asked them. I'd be happen pea to ask but I'm pretty sure they would not accept that statement. Because they have location other things like 11 K, 11 B are being developed in 8 O two 11. And there's a lot of sentiment in those groups that it was not appropriate for those particular kinds of networks. NEW SPEAKER: Pete Norris. I think, whatever the case is here, whether this is supported by wired, wireless or whatever terminals, the P sap needs to support it. So, one entity, one end of this end to end conversation in the emergency context needs to support all this. So if you want to separate it out, it's going to be possible then, you're going to have to dash NEW SPEAKER: Well, I mean, that's a funny statement. The truth is, the only thing the P sap has to support is hell, because right at the moment, anyway, the only way to transport a location by reference, would be sup is err held, and you can't get location by reference out of the P sap, which means, sorry. Out of L L D P-3 which means the P sap doesn't have to. NEW SPEAKER: Sorry. NEW SPEAKER: So that's not true. NEW SPEAKER: Roger marshal. I guess, I don't see why you would say the P sap has to support hell, when the next statement says, that it's support either SIP is or held. NEW SPEAKER: Because it doesn't know what it's going to get for a reference. It could get either. NEW SPEAKER: Because L R is delivered with the SIP signaling it's got and it can subscribe. NEW SPEAKER: If you're delivered a held L by R, if the scheme of L by R is held, however we do that, it's not clear. But however that's done, you have to be able to reference, and you have to be able to use that protocol to reference it. NEW SPEAKER: I wanted to, I'll leave that alone. I wanted to put in some support for the inclusion of supple, in this document. Even, you know in a minor way saying for example, supple. And then I want to ask a larger question on context, is this B C intended to apply to wired as well as wireless as was mentioned NEW SPEAKER: It's intended to apply to all devices. NEW SPEAKER: Or is it orthagonal. NEW SPEAKER: All devices, wired or wireless. NEW SPEAKER: So I would think that there needs to be text up front somewhere in the scope of the document that talks about its applicability for both contexts, because the two contexts are not the same. NEW SPEAKER: If that, if it isn't clear, we'll come up with words that make it clear. Change is not getting beyond what you can reasonably do and I'm going to have to rev the dock. NEW SPEAKER: The document is intended to apply to the internet. As the internet -- NEW SPEAKER: It does say that. NEW SPEAKER: So, so this is why I find that the in klution of L L D P puzzling because I don't remember this conversation, or wasn't around for this conversation two yeast ago. NEW SPEAKER: I don't think you were here. NEW SPEAKER: So what I was going to propose and I think I proposed this on the list, is that we require the stuff that's Stan add for the internet, which is held and D H C P-3 and recommend that end points and networks implement anymore restrictive things, things that are specific to physical input things or things that operate in restricted environments like supple. But that the core requirement be to support the things that are Stan add for the internet. NEW SPEAKER: What's your name? NEW SPEAKER: That was Richard barns. NEW SPEAKER: I was just going to agree with Richard. NEW SPEAKER: And your name is? NEW SPEAKER: Martin Thompson and it's on the jabber room. NEW SPEAKER: It's not on me. NEW SPEAKER: He's the scribe rps. NEW SPEAKER: I point out that optional L C Ps are worthless and the reason is this: -- NEW SPEAKER: No, they're not Brian. If you can get location, you can get location. Ultimately, if you can get it, it doesn't matter how you got it. Right? NEW SPEAKER: Right. I agree with that. All right. NEW SPEAKER: We're trying to go beyond that by saying, here's what you should support in a minimum, so when you kenkt to a network. You can guarantee some minimum service. NEW SPEAKER: Okay. So, it's L C P is beyond the minimum. It may give you capabilities that the minimum protocols won't give you. I mean, supple has capabilities that don't exist in D H C P or held and that's a reason to implement. However, you must also implement one of D H C P or held, you can't get away with not implementing one or the other on all networks. And, the text in framework talks about the fact that you can have is other protocols, but you must implement at least one of the required ones for a network. And all of them for a end point. NEW SPEAKER: So, in the interest of time, I'll try and be very quick, but I think very fundamentally, u missing the point here. And I think one of the big issues is, most wireless networks are actually combinations of multiple different types of networks, some of which are circuit switched and some are hybrid model, and some very internet like. What we have written is actually a document that describes how to deploy this in an internet model version of a network wireless or wired. If you are running the sish cut switched wireless network, it clearly does not actually deal with ta. It's a lot closer to a P S T N and this is all about -- NEW SPEAKER: That would be out of scope. Complete circuit switch network is out of scope. NEW SPEAKER: Exactly. But you have to be careful in talking about that when you talk about the kind of networks we're talking about and you have to pay attention to supple, you know, you talk about it as adding nothing else. Well, what it adds is deployment. There is some deployment of sup pem, especially one Dot O. And there slb some deployment of two Dot O which means you can put a held device in your network. But you may serve the vast majority of these emergency calls with your sup supple services, with the quote unquote additional. And that's not negligible. And we have to pay attention to that, if this is going to be heard. Or people will say, these people have no clue what my networks looks like. NEW SPEAKER: I agree with you. And NEW SPEAKER: whu. NEW SPEAKER: And I think that framework discusses those issues and it says that other protocols may be implemented. When you get to phone B C P. It's proscriptive and says you must do this. And there is no must and there's not even a should. There could be a may. If you, if that's okay, that you may implement other L C P s and that would solve the problem, I don't mind that. That's fine. NEW SPEAKER: This is Roger marshal. I agree with you Brian. I would say go ahead and make those changes and I'm good. NEW SPEAKER: Okay. I'll do that. NEW SPEAKER: Richard barns, can we review the changes are that you're going to make? NEW SPEAKER: I'm going to add, I'm going sto double check to make sure that I have a complete discussion and use supple as an example of another L C P that is listed in the framework discussion of the subject. And I'm going to make sure that the requirement for implementing L C P in phone B C P says must implement, for a network, must implement one of, for an end device must implement all of, and in both cases may implement others. So we'll do that. But now we have to deal with the issue of, are we going to revisit L L D P? NEW SPEAKER: That's one of the questions. Yes. NEW SPEAKER: Right. NEW SPEAKER: And the other question is, why do we want to mandate for the end device to use B C P-3 and not mandate for the network to use more than one. NEW SPEAKER: In order to get inter operability, one end has to do all and the other end can have freedom. You can't have freedom on both ends. NEW SPEAKER: So let's speak to the network which implements all of them. NEW SPEAKER: We've discussed that thoroughly and we believe that was not deploy able. NEW SPEAKER: I don't see why we have to revisit L D P if you're putting the thing in about supple, it makes the point. NEW SPEAKER: It currently says must L L D P. NEW SPEAKER: Oh, that's weird. NEW SPEAKER: He's, began bore agrees a gab bore agrees with you. NEW SPEAKER: And so, now I turn to the chairs and say, I don't personally mind dropping L L D P as required L C P, but the work group had a con scene is sus call and consensus call and the only discussion I heard so far is we haven't had a lot of deployment, and you guys get to decide. Do you want to call consensus on dropping L L D P? NEW SPEAKER: Obviously, we have to take it to the list, right? NEW SPEAKER: We have to take it to the list, but are you going to ask for consensus? Is that what you want to do? NEW SPEAKER: Let's let James talk. NEW SPEAKER: James Polk. This is getting a little bit into kind of theme that has been going on, throughout this meeting, more so than I've heard at previous meeting, and I've been around for about 20. About if a document or a protocol or extension is not deployed today with experience, IETF should just drop it. No, no. I'll work it into the issue. I've heard Hanna say it. You're yus one of them. Mary barns have said it. Several people have said it this week, move more often than I've heard (Several people talking.) NEW SPEAKER: Deployment does count in B C P. NEW SPEAKER: I know it's in our product road map. NEW SPEAKER: It is deployed. NEW SPEAKER: For all enterprise, including location. NEW SPEAKER: It's out there. NEW SPEAKER: Right. NEW SPEAKER: And I'm revealing a lot right now, but I'm more or less taking a chance doing. But it's in our product road map and it got pushed. It should have been released and then it got pushed. NEW SPEAKER: There are several other large telephony manufacturers for which that's also true. NEW SPEAKER: So what I'm saying is, I'm talking ether net switches. And I'm talking about a lot of them. NEW SPEAKER: Yes. NEW SPEAKER: Like almost all that we make. NEW SPEAKER: Okay. NEW SPEAKER: Having a code rev. NEW SPEAKER: sos there's an argument in favor. NEW SPEAKER: That's an argument in favor of dropping this, and I'm NEW SPEAKER: Not dropping it. NEW SPEAKER: And I'm arguing not to drop it and this is the exact example, which we don't normally consider. It's all enterprise. NEW SPEAKER: Okay. So, the reason I find this conclusion valid D P puzzling, is because they can not make reasonably make use of code that does all much L D P. So thinking from a kleely philosophical perspective, there seems to be a mismatch and putting that in the internet wide document. NEW SPEAKER: Well, there may be a practicality. NEW SPEAKER: And (Several people talking.) NEW SPEAKER: And the counter argument is that there are devices for which you you cannot run D H C P. You could physically do it but theres is no D H C P server. NEW SPEAKER: You can probably get it everywhere, NEW SPEAKER: Who is this? NEW SPEAKER: It's the context of does not do 8 O two, that's the bizarre thing. Or 802.11, those guys, go what the hell is this. I don't support this. I have 11 B or 11 K. They would also think that's weird. So you're essentially making a statement about 8 O two than what they would make themselves and that's bizarre. NEW SPEAKER: Okay. So, I think the point we're at, for phone B C P, Brian, correct me if I'm wrong. Is, we have today the text says is that a host must implement D H C P, L and L L D P network. NEW SPEAKER: Correct, that's what I it says right now. NEW SPEAKER: So the question dpor the group is, do we want to remove L L D P from that list of requirements. NEW SPEAKER: That's the question. NEW SPEAKER: So we'll take a hum in the room and then we'll take it to the list and we'll try and figure out -- NEW SPEAKER: If we have consensus to remove it. NEW SPEAKER: So the question here is is, do we want to remove L L D P immediate med from the list of must support the devices in phone P C P? If you dash dash NEW SPEAKER: Just clarifying, is this going to be removed from the document or is it going to be moved into optional or what? NEW SPEAKER: It's removed from the must list. It would be included in the may list. NEW SPEAKER: Okay. So if we remove it from the must list, the words will still appear in the document NEW SPEAKER: I will, I mean, I'm going to add supple to may. I will L L D P to may. Not a problem. NEW SPEAKER: But just how about the, I mean, I guess NEW SPEAKER: Can you announce your name please. NEW SPEAKER: Give me a name. NEW SPEAKER: Bernard. NEW SPEAKER: There's two alternatives we've been discussing, one is take it out, and other is leave it in. You can state the a applicability. If you're on an '80 two wired network, do it. Otherwise it doesn't make any sense. NEW SPEAKER: So the mailing list could just have that statement. It could. NEW SPEAKER: It says, if it works. For your environment. NEW SPEAKER: No. No. Must. NEW SPEAKER: No. It was different. I think what Bernard meant was you can have a must statement, but with the applicability that it only relevant for a wired -- NEW SPEAKER: That could do. You could say if you were, that and L L D P if the device is an 8 O two wired network. NEW SPEAKER: I could do that. NEW SPEAKER: Then you have a three way, I mean, -- NEW SPEAKER: You have three musts with a caveat. NEW SPEAKER: One of the musts have a caveat. NEW SPEAKER: Two and a half musts. NEW SPEAKER: So, we're saying is, asterisk, must only apply -- NEW SPEAKER: Well it (Several people talking.) NEW SPEAKER: I will say must implement bla and bla, and if the device is is an 8 O two device must implement wired 8 O two. NEW SPEAKER: Okay. I'm okay with that. NEW SPEAKER: But even in that case, you're doing what Bernard said, making a statement on behalf of 8 O two about what the standard thing for 8 O two is. It seems like it's their decision, not ours. I mean, well, very strongly in favor of a statement that says, if there's other techniques available to you, use them. You really should use them. Strongly should. But it doesn't seem like we're in a position to must, not internet stuff. NEW SPEAKER: But then we might get in a case of inter operability. NEW SPEAKER: Name at microphone. NEW SPEAKER: Say your name. NEW SPEAKER: Say your name for the note taker. NEW SPEAKER: James Polk. NEW SPEAKER: Speak into the microphone, we can't hear you. NEW SPEAKER: But then you're getting into an inter operability issue. NEW SPEAKER: Really. NEW SPEAKER: And inter operability issue with any wired switches. If we know that's coming, or we we reasonably predict that's coming, it should have been here already. That this is coming, and if you put it into a may, u going to get implementations of end points that don't do it. And the customer is going to be like, why not? So I think 8 O two, you can make a stronger case for saying 8 O two Dot 11, I think, Bernard is more right. So, this goes to the wire versus wireless. I agree with not, orp forcing this on a wireless or I should say. Dot 11, because I differentiate that from cellular. NEW SPEAKER: Randy somebody. I think it makes sense for inter operability to say something in the lines of wired network must support L L D P and probably also to say, in sell is lar network must support sup is pel. NEW SPEAKER: Cellular? NEW SPEAKER: Cellular network. NEW SPEAKER: Ron Thompson, define cellular. NEW SPEAKER: The problem with supple for IETF standard is that we have non inter operability of of representation and privacy. It's really tough. Geo priv would be all over us. NEW SPEAKER: They already are. NEW SPEAKER: James Polk, I would be perfectly happy if I E E E or '80 two or '80 two Dot three required L D P support for devices that wouldn't do emergency services or support emergency services, or if 3GPP wanted to require supple for compliant terminals. I just don't think it's in the scope of this document. NEW SPEAKER: I think you should call it. If there's anybody else that wants to talk. Call a hum. See what we get. NEW SPEAKER: Leave it in as must or take it out. NEW SPEAKER: Leave it in with the caveat version is the only one that makes sense. Is NEW SPEAKER: So we're going to take a hum. We will leave it in as a must, Brian will write a caveat that it works in 8 O two wired networks only or we will remove it or degrade it down to a may list, and include supple in the may list. NEW SPEAKER: Right. NEW SPEAKER: Those are the two options. So, the first hum will be if you want to leave it in the must list, and add a caveat to it. NEW SPEAKER: Sorry. Clarifying question. Do I tell my developers that they have to put it in their code in the first case, but it's never going to be used because that's for wired networks, or are they allowed not to have it in their code base. NEW SPEAKER: No. If it isn't a wired network, it doesn't have to be. NEW SPEAKER: The awk no, (Several people talking.) NEW SPEAKER: I will tell you what the Code will say. It will say, end points must implement all of held and D H C P or both, must implement both, held and D H C P, and if they are a wired 8 O two network attached device, must implement L L D P. NEW SPEAKER: Does the chair agree. NEW SPEAKER: That's the hum. NEW SPEAKER: Roger marshal. What about the clarifying addition of supple as may, still in the first scenario. NEW SPEAKER: Supple is not inter operable with what we're doing. You can't do it in IETF documents. NEW SPEAKER: You already agreed to, if the hum, I mean, if the other side of the hum was, I'll remove it down to a may, and I'll include sup is pel. Because of May. NEW SPEAKER: You know, when you get to mays, you can get all kinds of things things because they can -- if you want to be sticklers about it I'll take it out of the may list, but I'm willing to leave it in. The inter open ra ability problem is big. NEW SPEAKER: Let's get through this L L D med hum first. NEW SPEAKER: The way I was imagining what was being proposed is that supple is may. NEW SPEAKER: We're all agreeing that supple is may. NEW SPEAKER: The people on the bridge asked you to row Pete. NEW SPEAKER: The first version of the hum is to make the wording in the phone B C P read, end points must implement both of held and D H C P and if they are a, if the device is an 8 O two kenkt ted wired device Dee connected, wired device, it must implement L L D P. And then there's a an equivalent which has one of those. For the network that has one of of those. That's option one. Right? NEW SPEAKER: Correct. And option two is NEW SPEAKER: And option two is, you must implement both of held and D H C P, period. And there's a may list which includes L L D P. It doesn't. It's not must at all. It's just a may. NEW SPEAKER: So does everybody understand the difference between option one and option two. Okay. So those in favor of option one, hum now. ( Humming. NEW SPEAKER: And those in favor of option two, hum now. ) Humming. NEW SPEAKER: Wow. NEW SPEAKER: Thanks. ( It was about the same. NEW SPEAKER: We're going to take it to the list at this point. NEW SPEAKER: I couldn't tell. NEW SPEAKER: I couldn't. With this Big Bear tone voice next to me, I couldn't tell ) Bear tone voice. ( B.A. R I the T O N E. NEW SPEAKER: ) Big Bear is in California. NEW SPEAKER: Keith is up. NEW SPEAKER: sfoo r NEW SPEAKER: NEW SPEAKER: Am I audible? NEW SPEAKER: Yes. No NEW SPEAKER: No. NEW SPEAKER: Okay. I'm not the author of this draft, so I hope there are various people around the room that can connect me if I'm wrong. So, the, within 3GPP, they've been having a number of problems identified with the inability to carry various markings for emergency calls, and so basically, this draft is basically identifying those problems and asking for progression of some resolution. Before I start, I am going to say, in each of the requirements I've tried to identify p why we're trying to mark the particular aspect. The fact that something carries some other indicator, that might relate to emergency, may not be appropriate for the Tulsa man particulars that what is trying to be expressed. So basically, what we're looking for is a marker that carries the semantics that we're asking for. Not a general marker that says, this is a emergency call, ignore everything else. I think you raised a priority header and what these requirements are. These requirements are nothing about doing pry on the. And therefore, it's totally distinct. NEW SPEAKER: Hand nis. I'm going to ask it later. NEW SPEAKER: So, SIP basically has semantics for its headers. You use the head err or whatever, with the appropriate semantics of what you're trying to do. Next slide. So, the first issue we've got is that 3GPP needs to be able to distinguish the emergency registrations from ordinary registrations, and 3GPP registrations do do something slightly more than SIP ones which are basically only allows incoming calls. 3GPP has some extra bits like, implicit registrations and the human needs to learn what those registrations are. So if you register device address of records, then it's just the one you put in the register message. And, so you get an associated tell URI with a SIP URI, registered when you do a registration. But it needs to get emergency registration different, so for example, it can allow barred public user identities to actually be used for emergency calls and to receive call backs, and it needs the register to basically allow call backs to get through. In the first place. And it needs to be an emergency registration to basically happen in the local network as well, if you're roaming. So, essentially, we need to take something in the register request, and the proposal is being that we should add some sort of URI parameter to the call tag that actually goes in the register request. And I've given some idea of the solutions that 3GPP have actually lookd at in this case, and while some of them appear valid and some are are more invalid, that's, we won't go into details, this is the most urgent issue that I think 3GPP needs to look at of the slides. NEW SPEAKER: Brian. NEW SPEAKER: The URI of the registrar in the request URI. NEW SPEAKER: So, Brian, that's funny that you mentioned this. Because, when I asked about the differentiation between the service U RN and the re sesh research priority header, you say the service U RN is for routing. NEW SPEAKER: Yes, you're routing in the emergency reg star. NEW SPEAKER: Come on, give me a break. NEW SPEAKER: This is, you know, there's nothing about routing. Nothing. NEW SPEAKER: Ted. NEW SPEAKER: u right. NEW SPEAKER: Have you given up? NEW SPEAKER: No. No. The point was made much better than I could have made it. NEW SPEAKER: So I have said on the list, that this is the only use that I think actually absolutely needs a solution. I accept that you have a requirement that needs a solution. And I'm not sure that the parameters are the right value, but I accept that the there's an issue that must be solved. NEW SPEAKER: All right. The thing I would point out, this is also the one that we need a clear dprex on failly urgely. Urgently. This was finished well over 18 months ago and plenary, 3GPP claims, basically said if we don't get a solution, we're going to choose one dpor the working group and it's like ely to be that one or that one. And I don't think think you want that one. At all. NEW SPEAKER: No, no. NEW SPEAKER: Not really. NEW SPEAKER: No. NEW SPEAKER: Okay. Next slide. NEW SPEAKER: So, is there -- NEW SPEAKER: Let's focus on the solution first. NEW SPEAKER: Jon Elwell. Yes, I'm confused by the text there and in the draft, that says, address of of record in contact. NEW SPEAKER: Sorry? NEW SPEAKER: I'm confused by the text there that says address of record in contact. Because normally you don't put address of record into the contact URI, into a contact header field. NEW SPEAKER: You do in register. NEW SPEAKER: Well, if it's a GRUU. NEW SPEAKER: Well, it marks the URI in registry. Which is your public user identifier. But I need to go back to the 3GPP spec to check that. NEW SPEAKER: It means the address of record rather than the contact. NEW SPEAKER: Yes. NEW SPEAKER: I think that's the problem here. I don't think it goes -- NEW SPEAKER: That's the problem. NEW SPEAKER: The key thing is something needs to go in, there are various URIs, and what's being proposed is you mark one of those. NEW SPEAKER: nawd (inaudible) NEW SPEAKER: So the requirement two, is that one, we also need to mark the call going forward, and I believe the problem here starts when we're actually past the emergency center routing proxy, which is the UC S F and we want to go for example to the P S T N. We have existing P S T N Gateways that don't understand service U RNs in the request URI, and don't expect to see anything at all in the router header that they can use. So basically they are going to go to Q Dot 5 on whatever, and basically that says map it into a six4 number and ignore the rest. So basically, there's a marking needed that is different to what the is currently being proposed in ECRIT. NEW SPEAKER: So, first requirement I understood it, and I understand it as why we need it. The second requirement, we discussed this already and I think we have the presentation, and we with discussed it and I thought it was gone. Because I thought it was somewhat strange. So you have a P S T N Gateway, and P S T N Gateway. A legacy device that doesn't understand these emergency services things and doesn't understand the service U RN. Why the heck would it understand something else, the stuff that's yet to be defined. NEW SPEAKER: The answer to that is it doesn't need to, but if you have happen to reroute to somebody who is not legacy Gateway. It will know. Oh, by the way, you're going to a legacy device, therefore, build your request in a different way. NEW SPEAKER: Chris ter. NEW SPEAKER: Yes, Chris ter home bering, I think the answer to that is that the call will you can succeed anyway. It will G to P S T N, it will not be marked as emergency call in the P S T N side because the Gateway doesn't understand the emergency see indicator. But it will still succeed with the existing Gateway which will take the phone number from the request URI and then it can be updated so it understanding this emergency indicator. But the thing is bk ward compatibility. NEW SPEAKER: Brian Rosen. I'm still pretty confused. I got past the A C S F. The routing was okay. The route header is okay at the UC S F. It gee sides itsdz going to send is it onto something else. You're saying it could send it to two places, which is true. A P sap and IP connected P sap, it's going to send it with the routing header going going forward and the other choice you've got is the Gateway. And the problem, you're saying is the Gateway will fail, if it gets a route header. And I don't think that's true. NEW SPEAKER: What's Q 19 12 Dot 5 say. In Q 19 12 Dot 5. It does jt make any requirement at all. It just set is says map NEW SPEAKER: No, no. (Several people talking.) NEW SPEAKER: The route header is the thing that's got the service URI in it. It's going to ignore the route head e. NEW SPEAKER: Yes. NEW SPEAKER: That's what, but that's okay. It just ignores the route header. NEW SPEAKER: So, before somebody else has a chance to come to the mic. Henning wants to speak. NEW SPEAKER: Go ahead and speak. NEW SPEAKER: Henning? NEW SPEAKER: Best yet. NEW SPEAKER: Don't have priority. NEW SPEAKER: Are the participants still there? NEW SPEAKER: Bad route header. ( He's trying to get henks Henning to talk on the jabber. NEW SPEAKER: Some friends of my mother are supposed to take me to dinner tonight, you're going to regret it. If this working group gets me in trouble with my mom, you're going to regret it. NEW SPEAKER: ) Henning is talking. NEW SPEAKER: NEW SPEAKER: Something works, and something else is hard to understand. So I apologize if I'm missed something, something that you already said. My, too much high level concern is is that the draft itself, while it states and mostly refers to other documents, it really jumps right in, and says, here's the solution which does all of that. Which worries me a little bit. My fundamental concern is that, I thought weapon trying to prevent, and to the extent possible that 3GPP further diverges from what we want to do in ECRIT. So I would like to see if we can focus on, if these are problems with a generic the networks that we want to support or if these are truly 3GPP specific problems, with P he P header problem. I would never see the outside of a 3GPP network. And then when we have to worry less about that, because it's more of 3GPP internal problem. But my, there may we will be other solutions for example, we had discussions on the mailing list which didn't really seem to go very far and I'm not convinced that the registration mechanism itself is even necessary nor particularly well designed at the moment. So, if we, I know we have documents in there, but I think it would be really helpful if the requirements were stated in a way that they were more generic as opposed to saying, this is how 3GPP works. NEW SPEAKER: Ted? NEW SPEAKER: So, the point I was going to make when I got up before Henning talked is actually repeated by what henks said is. This draft, I think has one solid reason on the first slide that we've seen for us to be interested in resolving this problem. And that is, there is a need in some is cases to be able to indicate whether the registration you are making is an emergency registration or not. And those are the cases where a particular registrar will admit you if you claim what you're doing is an emergency registration and would not otherwise admit you. In the 3GPP case, there's a whole infrastructure around this and there may be other cases that come up that don't have the full flight ted SEC Fs around them. But hey, this is not for you unless you're making an emergency call. In which case, yes. I think because of that, what we should do, given our very short amount of time here, is accept this as a working group draft and then pound out first what the exact requirements are, how to get the registration part done and then work through whether the other requirements need exactly the same things or not. But I think what we really need to do here is agree that we are going to take on that problem in this working group or we are going to see diverge generals and that's going to be bad. And some of the other things that have been proposed are much more serious die verge generals than this. So I think if we don't adopt this draft, and work through the problems, we're going to end up hearth on the inter operability things later on. NEW SPEAKER: Brian Rosen. Since is I have said is all along I think there's a problem that needs to be solved I can't help but agree, to the stept that we've got to have a work item solve this problem. Period. I oppose taking this draft as the basis for that work. If you took out the solution and just put it in as a requirements document, and the requirement for the first one said, got to have emergency registration and this thing said is, must make sure that if a call reaches a Gateway it doesn't choke to route header and I'm not sure what the third one is, I forgot. Okay. Rev the document, requirements only, accept it as a working group item and we'll do something about it. But as it stands the document is pretty far from what I think we want as working group item. NEW SPEAKER: Andrew Allen. Basically, I agree with ted. I think and as Keith said, the first requirement is the one that's absolutely urgent. And if we're not positive towards it, then as Ted said is, you're going to end up with some different ver gent solution that's not working in IETF at all and would not be aligned with anything we're doing in ECRIT. So I think we need to take on the work, we need to create a working group draft and I think the priority should be to concentrate on the first requirement, the one important the registration. If people have other suggestions or other solutions for the registration, I think we should try and understand what those are. Personally, I think having a parameter in the contact header, for the registration part is, seems to me a fairly good idea. I have some sense about some of the other aspects of the draft for other usages, or for this parameter for other usages, but I think, for the registration cases, this is at least a start. If people don't have any other sukts I think we should at least start with that as a working assumption and then have our discussions as to what the other solution or not. The first requirement is urgent. NEW SPEAKER: Ted hard Dee speaking, I actually agree with Brian, in the general case, that we should have started with a requirements document and worked through this and done it the right way and I would normally say yes, let's not battle the time pressure here, but I think we will get diverge generals if we don't pay attention to it. If that's the what the working group is going to live with, then that's not something I can stop. But I do believe at this point, at least for the first requirement. We should accept the draft, rev st working group version of it, so that the requirements are even clearer, work on the solution, and if something is startlingly better than this, we should definitely talk. But very fundamentally, the other solutions that have been proposed in 3GPP for this, I think are going to be bad for the ECRIT system and that's not where we want to go. NEW SPEAKER: Tom son. Would it help if there was a draft that that had the first requirement only? And empty whole in it that said, we will insert solution here, and could we accept that as a working group item? NEW SPEAKER: I think if we do that, we will get, 3GPP will see is say plenary said they'll pick one out of the hat and we have a one in four chance at best. NEW SPEAKER: I think the upcoming meeting and it's basically the week after next, we need to have something, I think documented. As I said, a working assumptions. It doesn't mean we can't change it. We've got gone through 3GPP with drafts and a year later it got changed. You're not necessarily blocking yourself into a whole, if there's a real justification of use ago parameter is isn't going to work. But I think we need something more than just a TV D, because no one can start implementing a TV D. We need something. Otherwise we're going to get another solution. NEW SPEAKER: Maybe a few words on how we actually got here. We did have another solution in the document, which was found to be technically wrong and therefore it's going to be stripped out. And basically, we now need something to replace that that is technically right, and we need it pretty damn quick. We're trying to fix the technical problem we had already. So, basically, you know, this is meant to be a deployed release. NEW SPEAKER: So, thank you, Keith. We have a little bit of time issue here now. So we don't look at the requirement anymore, that was the call back issue. A couple of folks said we should look at call backs. Let's focus clearly on understanding some of the timing issues. Focus purely on the requirement one. And I'm going to ask for hum. And based on what I heard from some of the comments, here's what I propose. We strip out all the stuff about requirement one, put that in a document. The include the requirement and the first sort of, as attentive solution, as something that has been proposed, we put that in there, and use that as a starting point. And my question is, is that okay for you to have picked this up in ECRIT as a wroshing working group item? So, please hum now if you think that's a good idea. ( Humming. NEW SPEAKER: Please hum if you object to that idea. NEW SPEAKER: ) Silence. NEW SPEAKER: Okay. So, yes, we will talk to the, to our A D and NEW SPEAKER: Can you say what the hum result was. NEW SPEAKER: So the hum result was the hull was in favor of of taking on the document as a working group item, with focus on requirement one. And there were no objections. At least I couldn't hear some. NEW SPEAKER: I think you also said, if I understood, that the document solution would at least be a bit taking us a working assumption. NEW SPEAKER: Yes, right. NEW SPEAKER: So go from there and basically, if there's attentive on the table, it's basically to replace something that's technically flawed, rather than anything else. NEW SPEAKER: Right. And on the call back issue, I think what Brian initially said when the meeting started. I think we have a little bit more time there. So we can, we already have now two different solutions, so we can start with a requirements document there and figure out on on what we should be doing, is that roughly correct? NEW SPEAKER: What I suggest is that we actually do a split in the dpok ments, and the requirement one of the solution, goes forward into presumably on to be a working group draft and we'll re publish the second half, the rest of it, as the author draft and then basically, we can work on the requirements part of that document, which is what Ted wants, I think. And try and get those out to stability, and then we can split those as we get other work charterdd along the line. Does that suit you Brian? NEW SPEAKER: I was going to offer a slightly different proposal, which is simply that, I will work on it a call back requirements doc and I will grab the text and list somebody as a co-author and produce a, the beginning of cull back requirements doc. And I, you know, I, I'm more worried about the charter item than I am about the working group item. So I don't know how you want to do that. I'd libling to not go through a whole cycle before we get that in the charter. NEW SPEAKER: Obviously we have to discuss this. NEW SPEAKER: But if that is reasonable to you, for that particular piece of it, that's seems like a really good solution to me. NEW SPEAKER: And I think I would say that, comments are, we'll forward the requirements and the text that are still valid, while we're working that through. NEW SPEAKER: Okay. NEW SPEAKER: Are you satisfied. NEW SPEAKER: Yes. NEW SPEAKER: Okay. So, just to clarify, NEW SPEAKER: So I assume the first draft, the one that just has the requirements in it, that we agreed to split off, that the original author of this draft is is expected to produce that revision or is Brian. NEW SPEAKER: The process is the boshing working group chairs choose an editor. NEW SPEAKER: Right but million LAN seems to be a good guy, if somebody wantings to help him, I'm happy. NEW SPEAKER: I propose he and I produce a call back -- NEW SPEAKER: No, no. We're talking about requirement one. NEW SPEAKER: Oh, sorry. Sorry. NEW SPEAKER: We, you may actually want to -- I don't know. NEW SPEAKER: Okay. NEW SPEAKER: But, (Several people talking.) NEW SPEAKER: Next. We have two more. [ed. Note: Next presentation by Brian Rosen on Premature Call Termination] NEW SPEAKER: Brian. NEW SPEAKER: I think Alex, we won't make your presentation. NEW SPEAKER: I'm getting used to it. NEW SPEAKER: Right I'll try and keep it as quickly as I can. It's the top of the screen. A banned Don call and premature disconnect. NEW SPEAKER: So, this is the second revision of this draft, there was a lot of list discussion on it, I revised it. I tried to address all the issues that were raised. And as soon as you get there, I'll -- the first thing that I did was, that I clearly stated what, I made the distinction between the human being, the call taker and user agent server or client, the device and I tried to walk through all the requirements, making crystal clear, to whom the text was referring to. Some were referring to human, some were referring to the dough advise and I made it clear which one was which. I used consistent terminology. So, first one. Yes, all right. So then we defined when abandoned call starts. Which is after feature negotiation, so the sdiing naling goes all the way to the P sap and back, and so we can negotiate whether the feature is enabled or not. Whatever the mechanism is, whether it's two or three round trips, it doesn't matter. When that is done, then we can talk about, if the call is dropped after that, then you have an abandoned call. And you added text in the P D three to clarify when it applies and when it doesn't apply, added text in P D 5 to clarify it doesn't apply for multi lines. If you have a multi line phone and you push the other button, we're not calling that an abandoned call. We're going to let that go. NEW SPEAKER: Yes? NEW SPEAKER: Martin. Did I hear you say that an abandoned call is after this feature fwosh yaition happens NEW SPEAKER: Into yes. NEW SPEAKER: So you're talking solution now, not just -- NEW SPEAKER: No. I'm trying to define abandoned call. And I'm saying that because there's a requirement to negotiate the feature, you can't have abandoned call defined as a call can before the feature is negotiated, however you negotiate the feature. NEW SPEAKER: Okay. It sounds to me like you're -- (Several people talking.) NEW SPEAKER: I'm not trying to prejudice solutions. I'm simply saying, you have to be able to negotiate the feature. You can't always have it on. So, if you have to negotiate the feature, you can't have abandon call start before the feature is negotiated. Otherwise, you're -- NEW SPEAKER: Okay. konlt snoochlt okay. That's all I meant. All right. NEW SPEAKER: Okay. And added text to deal with the word rapidly. There was confusion over what that meant. So, here are the requirements. So, you have to have it rapidly re establish communication with the caller that attempts to prematurely disconnect. Must be know when it's done. Re connecting the caller must work reasonably reliably understand congestion conditions. Especially where call admission control is implemented. We had had this discussion last time. And then P D-4 said, it has to cause alerting at the U A C. Next. NEW SPEAKER: Can I ask a quick question. NEW SPEAKER: So, the way P D-1 is written now, very rapid re establishment as opposed to no by versions actually work with this. But many of the others, like four, refer to attempted to disconnect, wherein fact, you might have different mechanisms if there was a disconnect and a rapid re establishment. And I'm a little bit concerned about that. So in P D-4 for example, if you have have a rapid re establishment, the alerting would actually be different than if it were a call that somebody attempt today drop and did not. Because you have up media streams. NEW SPEAKER: What would you like me to do to the text. NEW SPEAKER: Well, I think your basic thing for P D-1, you don't want, you want any attempt to prematurely disconnect to fail. And I think the way you've written P D-1 doesn't say that. I disagree with P D-1, either way. But to be consistent with what u saying, your real P D-1 is attempts to disconnect when this feature has been negotiated should fail. NEW SPEAKER: Attempts to disconnect. All right. I'll work on that. I think I've got what you meant. Anything else? NEW SPEAKER: Next. NEW SPEAKER: So, 5 says when P D-1 is enforced the caller has to be able to place another, must not be able to place another call until the P sap allows the call to be released. This requirement is not intended to imply a user interface with multiple lines. Mistakes can be made an override mechanism must be feasible. This is people requesting, look I want the user to have ultimate control of the phones. We said all right. The implementation must fail safely so the phone can't be broke. Do you want me to stop. NEW SPEAKER: So, I'm not sure I actually understand st qualification. Sorry, Keith Drage. I mean, all SIP phones effectively can handle multiple calls in some way. I.E, you receive an invite doesn't mean you don't receive another one. NEW SPEAKER: I said a usable line, yes, I understand. You have call waiting inform ex. I'm not talking about physical lines. Obviously you have multiple lines. If the phone implements a multi line interface, then go ahead and use, you can use the other line. I'm trying to not box -- people were yelling and screaming about multi line phones, every other multi line phone you can make a call on another line. NEW SPEAKER: Okay. I'll let you make a call on another line. NEW SPEAKER: But it puts the retrieve and something else function was the exactly the same significant is naling as multi line tie operations. NEW SPEAKER: No, on old systems multi line phones were except is rat pairs and then we got to the point where they were separate logical line elements. I don't know where we are now. I only have ten minutes. NEW SPEAKER: Take it to the list. NEW SPEAKER: yorn if it's terminology anybody understanding. NEW SPEAKER: I was responding to people who said multi line phones ought to not lock all lines. NEW SPEAKER: Six, all media and signaling streams flowing wen the U A C and U A S must be maintained to the extent needed for rapid re connection. This specifically does not imply that the call taker be able to receive the live media. That means the phone is not a spy device. Rapidly is in human terms, the time from when the caller reacts to the mechanism initiating the re connect and the time the call taker can resume conversing. And is about a second. 7, control of disconnect is not neededd in all jurisdictions. It must be possible to invoke the function to allow preem mature disconnect. NEW SPEAKER: Can the user say I will not allow you to yol this line? NEW SPEAKER: It doesn't. NEW SPEAKER: Why not? NEW SPEAKER: We're now in the argument of what is the best way to handle emergencies, and the notion that you have to be able to, an override, is one thing, but not saying I'm going to preemptively override, is another. NEW SPEAKER: I don't understand the distinction, if you're going to have a P D which, a requirement which says it must be possible to override this feature, so that I can actually disconnect, why is it not possible for somebody to simply say, I reject your request to let me control the byes, and the reason inform this is it goes to the use concern. If this creeps out and gets abused so lots of people other than emergency services figure out a way to use it, having this in from the beginning means that people can re configure their phones to turn it on. Where if they cannot, then they have to, while they're in the middle, the guy won't let me go pr the row bow call, remember what the sequence is. NEW SPEAKER: The only argument I have for you is greater good. The greater good is is that the P sap gets to control it. To have a way to say, you know, go through, no, it's me, no, it's you. We'll let you in the last one. NEW SPEAKER: Regulation. NEW SPEAKER: Well, you may get over regulation. NEW SPEAKER: Sometimes, in Canada, there's regulation about it. NEW SPEAKER: And in Europe, there wouldn't be a regulation the other way. NEW SPEAKER: There could be. I can't, I don't cover regulation either way. I'm not using regulation either way. NEW SPEAKER: Ron Thompson. If I made a call, and it keeps bugging me, saying that the P sap operator wants to talk to me, I don't wability to throw the phone on the floor and break it before it goes away. I want to go, no, get lost. NEW SPEAKERin Canada, it will keep bugging you. Canada is just an example. There are several other countries inform which this is true. It will keep ringing, you have to pick it up until the P sap call taker says you're done. That's the way it works. If you rip the line out of the wall, it will stop ringing. If you take the battery out of a battery operated phone, it will stop ringing. NEW SPEAKER: I don't want to have to result to that. NEW SPEAKER: But that's the way it works. We have a lot of experience with this thing. Right. There are, this is an in use on a daily basis. The frustration factor is, happens, not like it doesn't happen. It does happen. But people's lives get saved much much more often than people get annoyed because the P sap won't let the call release. NEW SPEAKER: One more thing. If they have my number, they can call me. Isn't that enough? NEW SPEAKER: It's time. It's just how long. If it's fast enough, it works. There's call waiting in and a bunch of other things that get in the way. But if you can make it work, the requirements don't say how you implement it. NEW SPEAKER: Randy. I just wanted to clarify that the experience you're referring to is specific to wire line phones, people with circuit switch networks and in certain places, because I think that there are fundamental differences in how use ersz react to things that happen in a cell phone, on a computer or a sell is phone versus, you know 2500 sot. NEW SPEAKER: I don't understand that. I mean, I think that the sort of fundamental notion that you try to disconnect, and the phone alerts you in some way, that it's not going to let you disconnect. NEW SPEAKER: But can I just -- NEW SPEAKER: Who you have that alerting is done, whatever disconnect means, is not related to 2500 series phones. NEW SPEAKER: Just a quick clarifying question, but the experience in Canada is NEW SPEAKER: (Several people talking.) NEW SPEAKER: Yes. That's true. And not because they didn't want it that way, let me tell you. NEW SPEAKER: Define they. NEW SPEAKER: The P saps. The P saps really really, I mean, and as did the U.S. P saps when the care yes took it away from them. NEW SPEAKER: But presume (Several people talking.) NEW SPEAKER: The regulator did not choose to override the wireless care yes, that's correct. NEW SPEAKER: Just on this point of release, I think one of the issues is, in certain is scene nai yos, like a squon con Jennings scene nair congestion scenario, you the caller can't easily get through. NEW SPEAKER: First of all, there are congestion conditions where none of this is going to work, p period, the end. Of course. One of the reasons why we want negotiation is so that you can fail in congestion conditions and not engage it. You know, so if you if signaling doesn't round trip to say enable this thing, the function is not going to be enabled, you can hang up and go away. That's why these things are written that way. But once the, once you get to the point where the P sap believes solid connection is there, and it says now I want to enable this function. NEW SPEAKER: That's why you want to hold on to the caller. Because (Several people talking.) NEW SPEAKER: Yes (Several people talking.) NEW SPEAKER: Anything in the congestion situation, if you keep serving initial requests you never complete the transaction. You don't get any whe. NEW SPEAKER: Exactly. NEW SPEAKER: So you may as well keep the caller on the line NEW SPEAKER: Now you're into mek nis ment but I agree, they hold it up, rather than route the re connect. That's a better solution. NEW SPEAKER: So I just wanted to echo Ted's concerns over the security of this mechanism and the ability of a UAC to differentiate when it's talk to go a P sap and when it's talk to go somebody else. So I think there's some -- NEW SPEAKER: Well, okay. But rb, this is an emergency call. (Several people talking.) NEW SPEAKER: The end point is the one that originated this emergency call. It's not a call back. It's an emergency call. You started by making an emergency call. You can be answered by somebody who isn't a P sap, because they're masquerading as a P sap and then get into that circumstances, that could occur. NEW SPEAKER: Keith Drage. P D six, I think we need to probably elaborate more on what this one actually means. First of all, if it means keeping for example, the radio access bear request yer up on the mobile phone, it means you'll drain the battery while doing it. If it has 5 minutes of battery life in the phone, you might actually want to call back the user on, at some point later, then you cause the phone to go flat and the other thing is is, actually preventing other users from accessing, maybe that particular sell site. NEW SPEAKER: I hae you and I think all of that, personally, personally think, that all of that is just really small potatoes compared to the realistic circumstances where people get flustered and do the wrong thing. Yes, that can occur. I agree. But most often, it's people get flustered and they do the wrong thing. NEW SPEAKER: Jon Elwell. Have we given any consideration to the fact that with VoIP the media takes a different path for the signaling so the signaling might think the call is in close and the user experiencing the fact that audio just isn't working, he really wants to disconnect the call and try and make it again? NEW SPEAKER: Well, I think, I think that's a good point. Actually I hadn't thought about that one and perhaps we ought to sput put some requirement about, you know, not, doing something about that. Somebody make sure I get that in the notes. I I'll think about that problem. Because that, it's how does the call take e know that? And if it can't know then you're in a pretty bad situation. NEW SPEAKER: Yes. Ted Hardie. So, a couple of people are going, you ago you said, the end unit knows, not, the caller generally knows they're making an emergency call, and the device they're calling with knows. NEW SPEAKER: Yes. NEW SPEAKER: And I believe in that case, which is I hope the vast majority of these cases, what we can do here is is so simple, as to need no signaling path anything. And that's simply to say if you're in one of these jurisdictions where this needs to be in place and you are a device that is making an emergency call by regulation, by advice, by whatever, don't send 5, just like you had in the very original version of this, and stop. Because as long as the end device knows where it is, and what they're expected to do, what you had at the very beginning worked. NEW SPEAKER: No. NEW SPEAKER: When you add all of this other stuff and try and handle the other case of I don't know whether I'm making an emergency call so I have to accept negotiation from the other side or it's a call back with the same signaling in it, originated by somebody else and it's really the call taker calling back, you are adding a world of complexity. That buys you very little. NEW SPEAKER: You can brick the phone. NEW SPEAKER: If you start with that, you can have exactly the same protections in that very U I driven version of this. That is, in this version, because, the functional equivalents are the same, and yes, you can say, there's an override, or there's a squawk if you press the end button but you're in this condition, all of this stuff works, without touching the major signaling that involves all of these boxes on the path. And that's my real concern here. Like you, I want people to get their 911 calls answered. It could be my phone. I go to Canada and it could be me by the side of the road. I want it to work. But you're adding a whole bunch of stuff here that actually addition fragility and it makes me concerned that in this system, as opposed to the wire line circuit switched world, this actually is worse. NEW SPEAKER: I think that the way to answer that is is to get the requirements and then figure out that the solution is, don't send the buy. NEW SPEAKER: Okay. Folks, looks like -- NEW SPEAKER: Can I just ask then that we find somebody else to edit this document? Because I believe Brian has a very, very strong opinion. NEW SPEAKER: First off, we haven't accepted it as a working group. NEW SPEAKER: Let's take it to the list. NEW SPEAKER: Do we have anything anybody in mind NEW SPEAKER: NEW SPEAKER: Well, if you here's my suggestions. Go on. Just go, go past this and past that. Past that. So, I propose that we except accept it as a working group item and give somebody else the editor ship. NEW SPEAKER: I think the document is as it's currently written has a presumed solution in mind to the extent I don't think it's ready. I think if we're, if we really really are starting from the requirements, we need to keep working on this. Before it's accepted as a woking group item. NEW SPEAKER: Well, okay. NEW SPEAKER: So let's take NEW SPEAKER: Send text. NEW SPEAKER: Have the discussion on the list. NEW SPEAKER: Just as a suingtsz is, I think the requirements should focus on the user experience of the people involved, and not on NEW SPEAKER: P sap. (Several people talking.) awk NEW SPEAKER: If you read the requirements. NEW SPEAKER: The requirements are talking about keeping media paths up, and when negotiations NEW SPEAKER: I'll work. NEW SPEAKER: That is a that's a valid -- NEW SPEAKER: Requirement one is good. Because it talks about user experience of communication. NEW SPEAKER: I'll try it that way and see how it happens. NEW SPEAKER: It's at least worth trying. NEW SPEAKER: Thank you, Brian. NEW SPEAKER: So, anyway, that was a good meeting. Lots of discussions, and you got offered something for your money. If someone would like to work on this document as editor, please drop us a mail. NEW SPEAKER: It's his dock. But in the future, so if somebody is actually interest dz, because if we don't have any person be willing to edit the document, -- NEW SPEAKER: I'm willing to edit the document. NEW SPEAKER: But anyway, we are going to discuss this on the list, and if you stay a little bit longer, I'll take a picture of you. NEW SPEAKER: Oh, gee. NEW SPEAKER: I think we're done. Detailed Meeting Minutes (Steve Norreys) Agenda bashing Document Status Hannes indicated that we are doing well on all Rechartering Jon P Resorise priority header is his favou and he doesnt care James P needed to know if chairs were commenting on the list from the chair or as a individual Hannes Name space is on the agenda Bernard agreed with the ideas Ted H agreed but not with this specific case of the experimental rfcs and this should be taken to the list H reach a conclusion by the end of year Brian R asked for a charter item for call backs which includes marking and routeing. Hannes two draft that discuss this and in conjunction with Kieth URI parameter Brian R need to start from requirements. Proposal for a new design team for natiuonal solutions problems Marc L is this ecrit or geopriv Hannes this is about emergency calling not finding pizza hut Ray UK dont use location based routeing Jon worth investigating this potential to turn into something larger maynot be bad Ted Going way overboard start with fig if this is the wright group to do the stuff and this is in the preorative of the national authorities not IETF Keith needs to be better scoped Brian Regulator forces the relationship to ISP Bernard Design team buried what lead to these designs to the group etc. James write a consideration doc expliaing the situation Jon Trick is to find the scope narrow enough to find the requirements Rogerr M dont oppose the dT but supported Bernard Jabber why does the Marc NENA looking at theresults from this group to Phone BCP & Framework Brian R presenting Ted is the first case and sub set of teh second if no mapping then go up a level Keith the emergencu continues in some form and if cant go to psap so it must go somewhere but where? Hannes happy with ted solution Ted H need to add SIP before IM - agreed not ready to go to the IESG Kabour If the device cant server what does it do Brian for ward on Kabour Add supple to the list making four LCP not 3 Brian long discussion on LLDP is on the lcp list and we agreed to put it on concenus was large two years ago Ka in two years no delopyment of the protocol Brian it is deployed supported by Marc K It it fair from a mobile to support it B Need to Bernard not suitable for wireless revision may be suitable for wireless doubts expressed Marc Only good for 802.11 networks B Steve Psap needs to support this Brian not true need to support held Roger need to support supple Richard B This is for the internet and independent of the access Mark T agreed Brian Ted most w/leess networks covers all sorts of archs from fully manged to internet like and what supple adds is supple and this is not negilable Brian agrees phone bcp RogerM agrees What are the changes Doule check that supple is listed in the framework 2 must impletment one of and end edeivese implement all of ARe we going to revistit Kabour Netwok Brian are we asking concenus James P theme of what is going on in this meeting if this not deployed the the IETF isnot deployed then drop it in the Brian this is bcp so is deployed Richard B Brian couter arguem cant run dhcp Bernard 802 statement are stronger than Marc Do we want to remove LLDP from this list of must support devices James P is it removed Bernard tewo alternatives stqate apllicability to the particalr network B add LLDP if the device is a wired network James OK with this Richard strongly in favour of not doing this as we are doing IEE job for them Jmaes P the get inot interoperability issue Bernard all write not forceing this on a 802.11 Randy wired ntwk must support LLDP and celluaro must support supple someone? Define cellualr Richard this is not is the scope of this doc Marc Hum on leaving this in the must list with the caverate Ted Clarification of the Must B spelt it out Roger M what about the supple Bri supple is not interoperable so is a may TO make the wording in the phone bcp endpiint s must implement opt 2 must implement Inconcluesive hum taken to the list SOS URI parameter Keith presenting Prioity this uri not part of this Req1 Register request Brian R use the smae method as for routeing e,g use service URN Hannes this is for routeing Brain R agree that this urgently needed John E Dont normally use AOR in contact Req2 Indication of Emergency call origination Hannes discussed already and thought that this was gone Keith Christer the answer is the call will be completed anyway Brian R Clarifiaction required on teh choice with one being gateway and this will be ignored this is ok Henning concern is that he draft refer to other docs jumps in with a solution and what to bring 3gpp with the internet solutions ot are the problem s mpre generaric Ted This working group cant make him late to meet his mum Ted one reason to take this serously on the admittance od devices for emergency call which would not normally be allowed so this should be adopted as the WI Brain agreed that thsi should a WI but not this draft Andrew A Agree with Ted and take on the work but concentrate on the reg problem Ted agree with Brian should start with requirement draft need to take care of the time problem with this and rev the working group Mark T would it help if draft had the first req1 only Andrew need to have something doc as a working assumption Keith did have another solution that was wrong and need a slution that is wright Hannes focus on req1 strip out req1 put in a draft with Hum result concenus on taking the work as a WI with the foucus on Req1 Keith needs to work on a requiremnt draft for req2 Brian will work on a call back req draft Premature call termination Brain presenting Marc does this give a solution not a requirement as it goes to the feature Brian it must do this to define the aboned call Ted PD1 raqpid reestablishement but other talk about attemtped disconnect need to get PD1 attempts to disconnect should fail Keith all sip phone can handle multicalls any way Brian caller can use multiline calls Take this to the list TEd does this PD7 mean that the user can reject the override Brian the only arguement is that greater good is that the psap Mark T whats to stop this Brian can rip the phone or take out the battery Randy this is specific to wirelined phone in certaqin places and not everywhere Andrew in congestion scenarios then this could be differecult B this true for all emergey scanios ????? Keithm PD6 what doe this mean drain the battery if 5 mins left Brian people get flustered John E is the fact that the signalling takes different path to the media and may not know that the call has been prematurely disabled Ted if device knwo it is in the area where this is require then it should not send bye Brian this can break the phone Ted this adds fragiliuty so addinghte bye for this area this makes it worse. Ted not ready it has a assumed solution Marc discussion on the llist