Conversation with esw07@conference.ecotroph.net at Wed 31 Oct 2007 03:37:41 AM EDT

(03:37:41 AM) richard.barnes: in general, slides at <http://www.tschofenig.com/twiki/bin/view/EmergencyServices/EswAgenda2007>
(03:38:03 AM) richard.barnes: Hannu: how many EU countries are using non-standard numbers (other than 1-1-2)?
(03:38:25 AM) richard.barnes: Alain: 1-1-2 is not exclusive of other numbers, just a minimum requirement
(03:38:49 AM) linsner left the room.
(03:39:37 AM) richard.barnes: Marcus: Question is also which ones have non-1-1-2 numbers. This was documented in a recent study
(03:42:08 AM) richard.barnes: Slide 5
(03:42:22 AM) andres.kytt@skype.net entered the room.
(03:46:21 AM) richard.barnes: Chris: Extension to VoIP -- does that apply to service providers that location/VoIP, or does that extend to enterprises as well?
(03:46:42 AM) richard.barnes: Alain: Doesn't apply within an enterprise network
(03:46:55 AM) richard.barnes: Olivier: What do you say about accuracy?
(03:47:56 AM) richard.barnes: Alain: No legal requirements on it in our framework. Legislation is more long-term, tends not to deal with specifics. The implementing committee will set more specific requirements.
(03:48:38 AM) richard.barnes: McCann: With respect to VoIP, you don't mention a specific technology. Do you have a specific technology in mind?
(03:49:16 AM) linsner entered the room.
(03:49:16 AM) richard.barnes: Alain: That was intentionally vague.
(03:49:33 AM) richard.barnes: McCann: Is the regulatory framework starting toward regulation of the service vs. access?
(03:50:07 AM) linsner: Alain's preso is now on the wiki: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EswAgenda2007
(03:50:25 AM) richard.barnes: Alain: The purpose of the framework has always been to achieve a service, independent of the technology
(03:50:52 AM) richard.barnes: VoIP over WiMAX, WiFi, DSL, etc all the same obligations
(03:52:03 AM) richard.barnes: Wu: How is payment for location handled?
(03:52:41 AM) richard.barnes: Alain: Different by member state. In certain countries, the gov't pays, in others, the location provider does it for free (possibly covered by business uses)
(03:53:34 AM) richard.barnes: Kleven: In the US, the obligation for 9-1-1 is on the wireless operator, and in the EU, the operator is only responsible for making the location available (third party delivers the call)
(03:53:51 AM) richard.barnes: In this proposal, who own the obligation, or will have to pay for the service?
(03:54:19 AM) richard.barnes: If it's free of charge and the operator isn't responsible for the whole routing of the call, where does the obligation for paying for the call rest?
(03:55:07 AM) richard.barnes: Alain: The positioning function must be made accessible for free; the gov't may have to pay to direct that information to the right PSAP.
(03:56:55 AM) richard.barnes: Winterbottom: This is not applicable just to wireless; DSL & cable as well, and they're way behind.
(03:57:29 AM) richard.barnes: Says "providing location is free of charge" -- not clear how or to whom?
(03:57:53 AM) richard.barnes: Is this push going to have to happen to endpoints?
(03:58:20 AM) richard.barnes: Alain: In the proposal, the provision is to emergency authorities, not to endpoints.
(03:58:49 AM) richard.barnes: The TIC (technical implementation committee) will make more specific recommendations about other situations
(03:59:07 AM) richard.barnes: Winterbottom: Have you got an architecture in mind for this?
(03:59:25 AM) richard.barnes: Alain: Trying to be technology-neutral, so we don't want to pick a specific setup.
(03:59:41 AM) richard.barnes: We are trying to accommodate the separation of network vs. service providers
(04:00:46 AM) richard.barnes: Winterbottom: We will need to apply this to specific architectures
(04:01:18 AM) richard.barnes: Alain: Rules also apply to interoperability of networks. TICs deal with the details
(04:02:00 AM) richard.barnes: Kroeselberg: WiMAX providers are under the impression that the obligation is all on the VSP, at least in US.
(04:02:25 AM) richard.barnes: Alain: When someone makes a call, there may not even be a VSP. The network is the only one that has location.
(04:03:46 AM) richard.barnes: Murhammer: Wireline networks will also be subject to these obligations?
(04:04:05 AM) richard.barnes: Alain: In wireline networks, location is less of an issue, and they already have an obligation to provide it
(04:04:21 AM) richard.barnes: The difference is, e.g., Vonage over DSL or cable
(04:06:01 AM) richard.barnes: Liess: The situation is not a big deal if the network & service providers know each other. But we need to consider the case when they don't. Do you intend to put these kind of rules in the framework. E.g., not only free of charge, but also without an agreement between providrs?
(04:07:16 AM) richard.barnes: Alain: Framework doesn't specify relationships, just that it has to get to the ES authorities. TIC may say something more specific
(04:08:19 AM) richard.barnes: Nistal: Do you have a timeline for when this extension of obligations will happen?
(04:08:24 AM) richard.barnes: Alain: Next slide.
(04:08:39 AM) richard.barnes: These things have to be implemented through national legislation
(04:12:30 AM) richard.barnes: Schramm: Does this mean that every mobile operator has to provide location to every VoIP operator for free?
(04:13:04 AM) richard.barnes: Alain: If I'm in McDonalds in Vienna, and I use VoIP provider XYZ, and I need to make an emergency call without a contract with the WiFi provider...
(04:13:56 AM) richard.barnes: I think this is only possible if the WiFi provider gives me location for free
(04:14:12 AM) richard.barnes: Schramm: We need an authorization framework, perhaps
(04:14:24 AM) richard.barnes: Alain: Yes, privacy is also an issue
(04:15:12 AM) richard.barnes: Marcus: It doesn't necessarily need to be implemented in a way that requires communication between the LSP and the VSP
(04:15:23 AM) richard.barnes: (LSP = Location Service Provider)
(04:16:26 AM) richard.barnes: Rosen: In the IETF, we observe that the endpoint subscribes to both the access network and the VSP
(04:16:50 AM) richard.barnes: So it makes sense to pass information through the endpoint (access net -> endpoint -> VSP)
(04:17:02 AM) richard.barnes: This is a weakness when you don't trust the users
(04:17:25 AM) richard.barnes: This is a smaller problem than trying to force relationships, though
(04:17:42 AM) richard.barnes: Tschofenig: Also, need to differentiate between location for routing vs. dispatch
(04:18:19 AM) richard.barnes: Alain: This is another reason we're not going into specifics, just making the functional requirement that it come out the right place in the end
(04:18:51 AM) richard.barnes: ???: The EU should keep open the possibility of compensating providers
(04:19:38 AM) richard.barnes: If the EC could launch an evaluation of the benefits of location implementation, the governments and insurance will benefit
(04:20:23 AM) richard.barnes: Alain: Funding in general is a big issue.
(04:22:02 AM) richard.barnes: Hellstrom: Where are the terminal providers in this? Will the service provider now be careful that you only use approved terminals?
(04:22:45 AM) richard.barnes: Alain: Hope that you can buy any terminal you wish, from a competitive perspective. Endpoints don't do a lot in emergency access right now.
(04:23:05 AM) richard.barnes: If you start including laptops, it's a whole different discussion
(04:23:23 AM) richard.barnes: But this is getting deep in technology, and we haven't done that in the Commission yet
(04:23:57 AM) richard.barnes: Hellstrom: Don't forget the terminals, though.
(04:24:41 AM) linsner: richard, check your email
(04:24:53 AM) richard.barnes: Lonvick: Is the use of location restricted to emergency services? Or are providers allowed to use it for other purposes
(04:25:08 AM) richard.barnes: marc, I'll do it when we get to the next slide :)
(04:27:00 AM) richard.barnes: Bajko: (1) Is the EU going to require that any terminal on the market support VoIP ES?
(04:27:15 AM) richard.barnes: Alain: No. Theoretically you could, but we don't have any plans to.
(04:27:27 AM) richard.barnes: That wouldn't have a positive effect on the market
(04:28:51 AM) richard.barnes: Might consider imposing a standard if it's really required and if the market isn't doing it
(04:29:04 AM) richard.barnes: That would be very heavy-handed
(04:29:29 AM) richard.barnes: Bajko: From an EU registration point of view, it would be valid to have a phone that does not support emergency services?
(04:29:49 AM) richard.barnes: Alain: There's no "support" in my terminal right now
(04:30:13 AM) richard.barnes: If there are requirements on the terminal in the future, we might regulate that, but we don't see that now
(04:30:50 AM) richard.barnes: Bajko: Who does the location obligation apply to? Any old WiFi?
(04:31:11 AM) richard.barnes: Not enterprise networks. But public accesses, yes.
(04:34:01 AM) richard.barnes: Hannu: What happens if you install Skype on your mobile, so that you're now a VoIP endpoint? Fair to expect the same rules apply to, say, GPRS.
(04:34:16 AM) richard.barnes: Alain: Seems reasonable, but that's mostly a TIC issue.
(04:35:24 AM) richard.barnes: Kytt: Skype is not in a position to make voice calls over GPRS; the packet service isn't good enough
(04:36:32 AM) richard.barnes: Alain: When we get the final package on 13 Nov, we can then start talking technical issues, implementations
(04:37:44 AM) richard.barnes: Slide 6
(04:39:36 AM) richard.barnes: Slide 7
(04:41:58 AM) richard.barnes: Slide 8
(04:43:41 AM) richard.barnes: There is a principal that things that can best be handled at the national level should be handled at that level
(04:45:39 AM) richard.barnes: [ Anyone know who's talking? ]
(04:47:46 AM) richard.barnes: Lange: Different member states have have different requirements for emergency services. Because of these difference, I would prefer that most decisions be at the local level
(04:49:06 AM) richard.barnes: Marcus: The current universal service directive says that calls will be handled in the manner best suited to national needs
(04:49:24 AM) richard.barnes: Slide 9
(04:50:28 AM) richard.barnes: Slide 10
(04:51:37 AM) richard.barnes: Slide 11
(04:51:46 AM) richard.barnes: Slide 12
(04:52:56 AM) richard.barnes: Slide 14
(04:55:00 AM) richard.barnes: Slide 15
(04:56:15 AM) richard.barnes: Slide 16
(04:56:31 AM) richard.barnes: Slide 17
(04:58:16 AM) richard.barnes: Slide 20
(04:59:30 AM) richard.barnes: Lange: I was objecting to your comment that standards are being implemented by member states. In my view, they're implemented by the marketplace/industry
(04:59:42 AM) richard.barnes: Alain: Also need to make some changes on the PSAP side
(05:01:45 AM) richard.barnes: Tschofenig: There are also many operational and procedural issue
(05:01:50 AM) richard.barnes: End of Alain's section
(05:02:19 AM) andres.kytt@skype.net left the room.
(05:02:36 AM) esw07 entered the room.
(05:12:52 AM) richard.barnes: esw07 - i think you may have entered the name of the conference room in the "nickname" or "handle" field
(05:13:05 AM) richard.barnes: might be better to put in something clearer
(05:14:43 AM) esw07 left the room.
(05:15:11 AM) wusolomon entered the room.
(05:17:59 AM) wusolomon: Changed my nickname to show correctly
(05:29:19 AM) wusolomon: Is there a voice stream?
(05:29:30 AM) richard.barnes: great, looks good. glad you were able to get connected
(05:29:31 AM) linsner left the room.
(05:29:39 AM) richard.barnes: no, no real-time audio
(05:29:46 AM) richard.barnes: maybe a podcast, but I'm not sure
(05:29:58 AM) richard.barnes: we're starting again -- Policy panel
(05:30:28 AM) richard.barnes: I'll try to add more detail in the text chat
(05:30:43 AM) richard.barnes: Hannu introducing, panelists introducing themselves
(05:30:53 AM) richard.barnes: Roger Hixson - technical issues director at NENA
(05:31:22 AM) richard.barnes: Huey Tan - Director of Gov't Relations and Regulatory Affairs at Skype (not EU, focused on international markets)
(05:31:40 AM) richard.barnes: Markus Koenig: Swiss regulator
(05:31:52 AM) richard.barnes: Olivier Paul-Morandini: EENA
(05:32:02 AM) richard.barnes: Alain van Gaever: European Commission
(05:32:15 AM) richard.barnes: Hannu: Chair of 3GPP CT
(05:32:38 AM) richard.barnes: Hannu presenting one slide from EENA
(05:32:45 AM) richard.barnes: Olivier taking the mic
(05:32:59 AM) richard.barnes: EENA is not the little sister of NENA
(05:33:13 AM) richard.barnes: Context is different in Europe, approach is different
(05:33:34 AM) richard.barnes: Common market, free circulation of people led to 1-1-2
(05:33:44 AM) richard.barnes: EENA was created to promote 1-1-2
(05:33:55 AM) richard.barnes: Gathered together all stakeholders
(05:34:30 AM) richard.barnes: (Slide 2)
(05:35:17 AM) richard.barnes: EC has not had a proactive policy on this issue, only some MSs
(05:35:50 AM) richard.barnes: Slide 3
(05:36:15 AM) richard.barnes: Reviewing citizen-authority, auth-auth, auth-cit
(05:36:25 AM) richard.barnes: EENA / 1-1-2 focused on cit-auth
(05:37:06 AM) richard.barnes: Slide 4
(05:38:15 AM) richard.barnes: Update: around 200M calls/yr nowadays
(05:40:05 AM) wusolomon: The panel discussion.ppt only have 2 slides. Is there a newer version?
(05:40:08 AM) richard.barnes: 15-30% of emergency calls are handled inappropriate or not at all
(05:40:26 AM) richard.barnes: I just figured out that the current slides are not available online. I'll try to narrate
(05:40:44 AM) richard.barnes: Currently, no standards for any of the three types of emergency communications
(05:41:39 AM) richard.barnes: EENA has been supporting enforcement of Directive 22/2002 (Universal Service Directive)
(05:42:29 AM) richard.barnes: Among the MSs, it's impossible to improve the situation without a common solution
(05:42:55 AM) richard.barnes: industry will not converge on this solution, so it needs to be driven by citizens
(05:43:48 AM) richard.barnes: Thanks to the EP, these citizen-centered arguments have a place in the discussion
(05:44:08 AM) richard.barnes: what do citizens expect from 1-1-2? how can they use it?
(05:44:52 AM) richard.barnes: how are many languages handled? how quickly does help need to arrive
(05:44:53 AM) richard.barnes: ?
(05:45:04 AM) richard.barnes: EENA is leading these sorts of quality crieria
(05:46:36 AM) richard.barnes: Next steps: Advisory board to increase EU budget for ES and promote existing solutions
(05:46:49 AM) richard.barnes: End of EENA slides
(05:46:55 AM) richard.barnes: Hannu back at the mic
(05:47:16 AM) richard.barnes: EENA is an illustration of the real-life requirements that the system needs to meet, like the NENA presentation yestreday
(05:47:35 AM) richard.barnes: Before going to technical issues, one slide with a graph
(05:48:51 AM) richard.barnes: Markus Koenig: Swiss OFCOM allowed SIM-less emergency calls for one month, saw 250% increase in emergency calls from mobiles
(05:50:54 AM) richard.barnes: Hannu: This was the all-time highest number of cellular emergency calls
(05:51:04 AM) richard.barnes: Hannu: Opening the floor for discussion
(05:57:37 AM) richard.barnes entered the room.
(05:57:37 AM) SDO Emergency Services Workshop 2007
(05:40:05 AM) wusolomon: The panel discussion.ppt only have 2 slides. Is there a newer version?
(05:40:08 AM) richard.barnes: 15-30% of emergency calls are handled inappropriate or not at all
(05:40:26 AM) richard.barnes: I just figured out that the current slides are not available online. I'll try to narrate
(05:40:44 AM) richard.barnes: Currently, no standards for any of the three types of emergency communications
(05:41:39 AM) richard.barnes: EENA has been supporting enforcement of Directive 22/2002 (Universal Service Directive)
(05:42:29 AM) richard.barnes: Among the MSs, it's impossible to improve the situation without a common solution
(05:42:55 AM) richard.barnes: industry will not converge on this solution, so it needs to be driven by citizens
(05:43:48 AM) richard.barnes: Thanks to the EP, these citizen-centered arguments have a place in the discussion
(05:44:09 AM) richard.barnes: what do citizens expect from 1-1-2? how can they use it?
(05:44:52 AM) richard.barnes: how are many languages handled? how quickly does help need to arrive
(05:44:53 AM) richard.barnes: ?
(05:45:04 AM) richard.barnes: EENA is leading these sorts of quality crieria
(05:46:36 AM) richard.barnes: Next steps: Advisory board to increase EU budget for ES and promote existing solutions
(05:46:49 AM) richard.barnes: End of EENA slides
(05:46:55 AM) richard.barnes: Hannu back at the mic
(05:47:16 AM) richard.barnes: EENA is an illustration of the real-life requirements that the system needs to meet, like the NENA presentation yestreday
(05:47:35 AM) richard.barnes: Before going to technical issues, one slide with a graph
(05:48:51 AM) richard.barnes: Markus Koenig: Swiss OFCOM allowed SIM-less emergency calls for one month, saw 250% increase in emergency calls from mobiles
(05:50:54 AM) richard.barnes: Hannu: This was the all-time highest number of cellular emergency calls
(05:51:04 AM) richard.barnes: Hannu: Opening the floor for discussion
(05:57:37 AM) HannesTschofenig has set the topic to: 3rd Emergency Services Workshop
(05:57:53 AM) richard.barnes: (sorry, dropped out for a minute, back now)
(05:58:01 AM) richard.barnes: McCann: It is critical to 802.11 to know whether there is a requirement for unauthenticated access to 802.11 networks. If people want wifi hotspots to enable people to make emergency calls via SIM devices, IEEE should be the ones to enable that. We need to know if we need to add that requirement.
van Gaever: No yes or no answer. At least 5 member states are not allowing SIM-less calls, others are routing to an automated system. So there's a tendency not to do it. It's not something that's handled at a European level.
Hannu: There may be a mismatch of concept here. "SIM-less" is meaningful in the cellular context, but very technology-specific. Perhaps "unauthenticated" is better.
(05:58:38 AM) richard.barnes: Medland: In the UK, we don't allow SIMless calls
(05:58:56 AM) JamesWinterbottom: 45% of all emergency calls >from mobiles are accidental
(05:58:57 AM) richard.barnes: even still, 45% of emergency calls from mobiles are accidentally dialed
(05:59:04 AM) richard.barnes: takes a long time to filter these calls
(05:59:38 AM) linsner left the room.
(05:59:46 AM) linsner entered the room.
(06:00:11 AM) richard.barnes: Hannu: So we have numbers from the UK
(06:00:39 AM) richard.barnes: Stark: At a personal level, my thought is that if you're connected to the Internet, I would rather not require providers to be looking into SIP traffic
(06:00:52 AM) richard.barnes: (i.e., to determine which calls are authenticated / emergency calls)
(06:01:31 AM) richard.barnes: Are there going to be requirements for ISPs to search for authenticated / emergency calls
(06:01:53 AM) richard.barnes: Separate from the question of access to the IP network for emergency purposes
(06:02:23 AM) richard.barnes: Linsner: McCann is talking about getting access to the AP (i.e., not Barbara's IP-level concern)
(06:02:51 AM) richard.barnes: Liess: PSAPs have the same problem with fake calls. Mostly on Sundays, because people go to the flea market and use 112 to test phones
(06:03:10 AM) richard.barnes: test call is a very nice feature of skype
(06:03:33 AM) richard.barnes: If the cellular network had a SIM-less test mechanism, there would be much less problem with fake calls
(06:04:20 AM) richard.barnes: Winterbottom: Just because you don't want to pay for access to the AP, that doesn't mean they have a SIP server that can help set up the call, it can just connect to the Internet.
(06:04:37 AM) richard.barnes: You can't determine at layer 2 (802.11) what the device is going to use the connection for
(06:04:51 AM) richard.barnes: Also need to clarify which APs the access requirement applies to
(06:05:33 AM) richard.barnes: Tschofenig: If you want to make sure that the connection is only used for emergency calls, APs will need to deploy ES-specific features
(06:05:43 AM) richard.barnes: Winterbottom: The hotspots will just disappear
(06:06:03 AM) richard.barnes: Tschofenig: We can probably come up with a solution, but it will be complicated and difficult to deploy
(06:06:35 AM) richard.barnes: IETF ES architecture allows lots of different types of VoIP access
(06:06:49 AM) richard.barnes: To allow the network to spot ES traffic, need to use a small set of specific things
(06:08:02 AM) richard.barnes: Koenig: About non-emergency test mechanism: That can work in certain situations, but doesn't rule out malicious users
(06:08:12 AM) richard.barnes: Denial of service at the PSAP via lots of SIMless calls
(06:09:00 AM) richard.barnes: Olivier: France is seeing a 50-50 split between 1-1-2 and 1-8, and many more 1-1-2 calls are false
(06:09:39 AM) richard.barnes: If we inform people that caller location is accurate (hence police can come for you), that will reduce false calls
(06:10:08 AM) richard.barnes: If you educate people about 1-1-2 like you do about 1-8 (or other numbers), you'll get similar numbers of false calls
(06:10:30 AM) richard.barnes: For 1 accident on the road, you get 40 calls, so filtering can help
(06:10:52 AM) richard.barnes: Working these dimensions may be more constructive than just ruling out SIMless calls
(06:11:20 AM) richard.barnes: Also, at least one provider is using 1-1-2 to test their phones, so it's not just end users!
(06:11:48 AM) richard.barnes: Winterbottom: Sometimes location comes from the endpoint. So you also have a requirement for accuracy in the location.
(06:12:20 AM) richard.barnes: Olivier: If the gov't says that they can locate you, then this will convince people not to make false calls
(06:12:42 AM) richard.barnes: Winterbottom: A teenager in australia could easily send an emergency call that looks like they're in downtown Paris
(06:12:52 AM) richard.barnes: So you need to have mechanisms to add trustworthiness to location
(06:13:17 AM) richard.barnes: Alain: Two approaches: Technical means to prevent modification, and procedures to deal with it
(06:13:45 AM) richard.barnes: NL has some procedures for dealing with fraudulent callers that have been pretty successful
(06:13:59 AM) richard.barnes: Tschofenig: Roger, is there any data from the US?
(06:14:39 AM) richard.barnes: Hixson: The stats are maybe not as well defined, but 30-45% of mobile calls are accidental in many locations
(06:15:15 AM) richard.barnes: Very few cases of real emergencies with unsubscribed terminals
(06:16:00 AM) richard.barnes: FCC included a statement that meant to say that validation of a wireless call should be ignored, but wording was interpreted to say that authentication should be ignored
(06:17:09 AM) richard.barnes: Hannu: That's an interesting item. Want to highlight that the high number of unauthenticated calls is only part of the story. Also have to consider additional work-load and complexity in the system
(06:17:28 AM) richard.barnes: Does anyone have a figure for what % of unauthenticated calls are genuine?
(06:17:57 AM) richard.barnes: If that's too small, then we may be doing more harm than good
(06:18:14 AM) richard.barnes: Rosen: Hixson said that they couldn't find any
(06:18:21 AM) richard.barnes: Hixson: a "vanishingly small amount"
(06:18:43 AM) richard.barnes: Palm: In SE, we have rerouted all SIM-less calls to a separate call center. 3-5% are real calls.
(06:18:55 AM) richard.barnes: So there are real calls, but you need a mechanism to select them out.
(06:19:50 AM) richard.barnes: Medland: On wireline systems, where location is well-known, still have ~30% false call rate
(06:21:22 AM) richard.barnes: Tan: From the perspective of an observer (this being my first meeting), it's interesting that there seems to be very little user perspective.
(06:21:42 AM) richard.barnes: We need a better understanding of why people are making emergency calls
(06:22:08 AM) richard.barnes: Yesterday, there was a discussion of how to implement emergency calls, but not much discussion of why that's being done
(06:22:40 AM) richard.barnes: As a software provider, there's a very different expectation -- Skype users know that it doesn't provide emergency calling
(06:22:59 AM) richard.barnes: Maybe the question isn't how you do it, but does it make sense?
(06:23:06 AM) richard.barnes: Is it setting up unrealistic expectations?
(06:24:16 AM) richard.barnes: By providing emergency calls via (e.g.) Skype, many software companies would have to take stock of their emergency capabilities
(06:25:13 AM) richard.barnes: Without more detailed thinking about what reasonable expectations are, the resulting confusion will be to the detriment of industry and users
(06:25:39 AM) richard.barnes: Rosen: We've been working this for 3-4 years. The position that many of us hold is very user-centric -- if the user has a reasonable expectation that it will work, then it will.
(06:25:56 AM) richard.barnes: Goal is to make it so cheap and simple that a free service will do it
(06:26:09 AM) richard.barnes: Zennstrom said "why not?" when Brian asked
(06:26:27 AM) richard.barnes: Skype has used a loophole in the US law to get out of it
(06:26:50 AM) richard.barnes: We would like to make it so that your inclination is not to do that, but just to do ES because its so easy
(06:27:09 AM) richard.barnes: We want AOL to do IM to emergency services, we want all sorts of services to offer emergency access
(06:27:24 AM) richard.barnes: This is one reason I don't like unauthenticated calls -- it adds cost, barriers
(06:28:14 AM) richard.barnes: Tan: We are exploring the possibility of offering emergency services. Question is when? how? how do you manage expectations?
(06:28:32 AM) richard.barnes: If you put a phone on the fridge and it can call Tesco's -- do you add emergency calling? why not?
(06:28:47 AM) richard.barnes: But there shouldn't be a regulatory requirement for it.
(06:29:14 AM) richard.barnes: It's not avoidance, it's that Skype users don't reasonably expect that capability right now
(06:29:39 AM) richard.barnes: Kytt: We're seeing the same problem as all the VoIP providers.
(06:30:03 AM) richard.barnes: We're inclined to not do ES right now because of the nomadic nature of callers.
(06:30:22 AM) richard.barnes: We could probably do it in the US or the EU, but if a user roams to Malaysia, we might not have capability there.
(06:30:43 AM) richard.barnes: Our presence here shows that we're interested. But we're worried about people asking us to do things we can't do.
(06:31:08 AM) richard.barnes: Skype is all about community, so we're obliged to give something back. But we can't do what we can't do.
(06:32:37 AM) richard.barnes: Winterbottom: Anything that can technically make an emergency call should be able to. Andres was saying that if you can't provide ES universally, then you shouldn't provide it at all. Realistically, we're going to expect some trickle-in.
(06:33:42 AM) richard.barnes: Kytt: All I'm saying is that this creates fragmentation.
(06:33:57 AM) richard.barnes: Bajko: Going back to SIMless question.
(06:34:09 AM) richard.barnes: Now that everyone has a mobile, who do you expect to make a SIMless call?
(06:34:37 AM) jchiaramonte: Kytt: US-based subscribers represent a small percentage of Skype users
(06:34:41 AM) richard.barnes: In order to do it SIMless, you need to take out the SIM
(06:34:55 AM) richard.barnes: (yes, thanks John, I lost the thread there)
(06:35:55 AM) richard.barnes: van Gaever: E.g., whenever there's a football game, they put SIMless phones around so they can be used in case of emergency
(06:36:06 AM) richard.barnes: If you change networks, etc...
(06:36:14 AM) richard.barnes: There are legitimate reasons for systems to be without SIMs
(06:37:17 AM) richard.barnes: Liess: Back to Skype -- you said that users don't expect it, but that will change as soon as there are successful Skype mobiles.
(06:37:23 AM) richard.barnes: Kytt: That's absolutely true.
(06:37:45 AM) richard.barnes: Hannu: expectations are based less on the technical qualities than the gadgets they see
(06:38:32 AM) richard.barnes: Dirk: There are multiple levels of subscription here -- access net, VoIP service, in particular
(06:38:52 AM) richard.barnes: might be intersting for 802.11 people to consider this question; we're looking at similar issues in WiMAX
(06:39:44 AM) richard.barnes: Hannu: three main items
(06:39:48 AM) richard.barnes: (1) key lock on
(06:39:52 AM) richard.barnes: (2) SIM for WLAN
(06:40:01 AM) richard.barnes: (3) [what was the third?]
(06:40:16 AM) jchiaramonte: emergency calls without subscription
(06:40:38 AM) richard.barnes: Key lock case seems like the clearest case: Seems like there's consensus that this should not be allowed
(06:40:48 AM) richard.barnes: Linsner: This is just a UI issue, right?
(06:41:07 AM) richard.barnes: Hannu: yes. Can't find a 3GPP requirement on it, but all 3GPP phones do it
(06:42:03 AM) richard.barnes: Dirk: Key lock is part of the picture; When I switch it on, my phone says "enter sim or place emergency call", which also speaks against emergencycalls
(06:42:14 AM) richard.barnes: i.e., against SIMless emergency calls
(06:42:31 AM) richard.barnes: Hannu: Any objections to no keylock-on calls
(06:43:08 AM) richard.barnes: Marcus: Shouldn't be mandated by regulation, but could be useful in some cases
(06:43:35 AM) richard.barnes: ???: This should probably be an opt-in
(06:44:04 AM) jchiaramonte: (James Price - ETSI)
(06:44:24 AM) richard.barnes: Hannu: Providers doing it to reduce liability risks
(06:45:06 AM) richard.barnes: best we can achieve here is to say that nobody knows of a requirement for it, and the expert opinion of the meeting is that it should be configurable/opt-in
(06:45:54 AM) richard.barnes: Palm: the reason this came about is that if someone is unconscious, this would allow someone else to use his (the victim's) phone
(06:46:50 AM) richard.barnes: Olivier: Don't we increase the chance of false calls ?
(06:47:11 AM) richard.barnes: Hannu: I don't see how we're making it worse...
(06:48:20 AM) richard.barnes: If the mobile gives instructions for how to unlock it, then we've ruled out some people
(06:48:52 AM) richard.barnes: van Gaever: When you say there's a recommendation, that's fine, but the executives will still worry about liability
(06:49:11 AM) richard.barnes: maybe you need some endorsement from, say, a PSAP organization
(06:49:39 AM) richard.barnes: you're going to need more validation in order to change operators' behavior
(06:50:49 AM) richard.barnes: Hixson: NENA would look on this as something positive to discuss
(06:51:22 AM) richard.barnes: Several years ago, we had a problem with one-button calling, and we sent letters to ask them to make that opt-in
(06:52:10 AM) richard.barnes: At the time, there weren't a lot of clamshell phones, and we had a lot of "butt calls" -- people sitting on their phones and dialing 9-1-1 by accident
(06:52:30 AM) richard.barnes: the manufacturers did end up making it optional, this could be a similar situation
(06:52:45 AM) richard.barnes: there should be support from emergency organizations to make that happen
(06:53:47 AM) richard.barnes: Hannu: Let's turn to SIMless WLAN access
(06:54:20 AM) richard.barnes: There is no current requirement for SIM authentication to WLAN, except for some special 3GPP WLANs
(06:54:52 AM) richard.barnes: The proposal is that SIM is irrelevant to most WLANs (non-3GPP)
(06:55:36 AM) richard.barnes: Winterbottom: 3GPP doesn't really just apply to cellular anymore, it encompasses IMS, which is being applied to cable, possibly WiMAX
(06:56:06 AM) richard.barnes: Hannu: Agreed. Whatever we say here, we'll need to review the text
(06:56:23 AM) richard.barnes: By 3GPP, meant a 3GPP PLMN using SIM authentication
(06:56:52 AM) richard.barnes: This leaves open DOCSIS/TISPAN authentication; don't see a need to impose SIM there
(06:57:14 AM) richard.barnes: Turning to the 3GPP SIMless access
(06:57:33 AM) richard.barnes: What about emergency calls when the subscriber hasn't subscribed for IP connectivity
(06:58:07 AM) richard.barnes: If a device is capable of establishing WLAN connectivity, should a VoIP application be able to place calls even if there's no subscription
(06:58:51 AM) richard.barnes: Winterbottom: Maybe this means you don't allow subscriptions that don't include IP access. You charge for IP usage, but you provide access for free.
(06:59:16 AM) richard.barnes: Hannu: That covers the case when I'm a CS subscriber that lands in a PS cell.
(06:59:28 AM) linsner left the room.
(06:59:42 AM) richard.barnes: What about the case where I'm a subscriber of another network, but there's no roaming agreement?
(07:01:03 AM) richard.barnes: In the wired context, if I haven't got an ISP agreement, then I haven't got IP connectivity, and that's that. Why should we expect different from wireless?
(07:02:38 AM) richard.barnes: CS emergency call in CS PLMN without subscription -- subject to current regulations
(07:02:51 AM) richard.barnes: VoIP call over internet without ISP subscription?
(07:02:59 AM) richard.barnes: over cellular without cellular subscription?
(07:03:20 AM) richard.barnes: IMS over cellular without cellular subscription?
(07:04:16 AM) richard.barnes: additional problem that there's no central entity doing call control -- no practical way to block misuse
(07:05:15 AM) richard.barnes: van Gaever: Depends on how users experience technology. If you cross the border and you can no longer make calls because there's no roaming agreement, that's a problem.
(07:06:32 AM) richard.barnes: Hannu: We need to keep this on the table, so that regulators will at least know that it's not a copy-paste operation
(07:07:11 AM) richard.barnes: van Gaever: Need to get a better picture of how this looks in scenarios. It's about what the user gets out of things.
(07:07:38 AM) richard.barnes: Hannu: The way I'd like to interpret this is that we go out of this meeting with an action to better explain the use cases.
(07:08:03 AM) richard.barnes: Hixson: At least in the US, there's a tendency to head for simple solutions to complex questions.
(07:08:34 AM) richard.barnes: There is a tendency to take the existing requirements for both unsubscribed access and location accuracy and apply them to new technologies
(07:09:17 AM) richard.barnes: As far as roaming agreements, it seems like if you have a subscription anywhere, you should be able to make an emergency call anywhere
(07:09:40 AM) richard.barnes: the more difficult question is whether you should be able to make a call without a subscription
(07:10:11 AM) richard.barnes: In the wired context, a phone without subscription can still make an emergency call
(07:10:38 AM) richard.barnes: If we could go back and avoid the misinterpretation of the FCC, we wouldn't have unsubscribed access
(07:10:54 AM) richard.barnes: That's too well established to drop it in cellular networks, but maybe we can prevent it from spreading.
(07:11:13 AM) richard.barnes: Winterbottom: can't roam >from CDMA to UMTS
(07:11:32 AM) richard.barnes: Linsner: I turned on my CDMA phone when I got here and didn't get much
(07:11:43 AM) richard.barnes: I didn't have an expectation of service
(07:12:00 AM) jchiaramonte: (me neither - left the phone at home)
(07:12:32 AM) richard.barnes: Winterbottom: It's not that different -- just because two completely independent operators use the same technology, you're saying they have to have the same service model
(07:14:00 AM) richard.barnes: Linsner: From the Internet point of view, we don't want to encumber ISPs to such a degree that you'll inhibit the growth of the Internet.
(07:14:36 AM) richard.barnes: van Gaever: Regulators don't tend to distinguish between PS and CS, they see it as a service being provided to the caller.
(07:15:05 AM) richard.barnes: same type of service, same type of business model; same regs might make sense
(07:15:56 AM) richard.barnes: Medland: How can we inform users, shaping expectations? Maybe we should display more information?
(07:16:13 AM) richard.barnes: Some terminals already say "emergency calls only"; why not say "no emergency calls available"
(07:16:57 AM) linsner entered the room.
(07:17:07 AM) richard.barnes: Rosen: Somebody ought to be commissioned to make a symbol that says "this device can make an emergency call" and "this device is capable of emergency calls, but can't right now"
(07:18:25 AM) richard.barnes: Hannu: The more critical thing might be just to indicate "you can't make an emergency call".
(07:18:39 AM) richard.barnes: The other thing would be "you can try, and I'll try to make it work"
(07:18:54 AM) richard.barnes: i.e., sometimes the terminal can't tell
(07:20:10 AM) richard.barnes: moving to issues around location...
(07:20:22 AM) richard.barnes: Tschofenig: Let's discuss this as part of the location hiding discussion
(07:20:49 AM) richard.barnes: Marcus: As far as the number of national emergency numbers, the EC doesn't have the authority to get rid of them
(07:21:04 AM) richard.barnes: But this group could say that there's too many, and regulators can consider it
(07:21:37 AM) richard.barnes: Price: Sounds reasonable to me. One issue in ETSI is what use network operators can make of location information.
(07:22:02 AM) richard.barnes: Obviously privacy is overridden in the case of emergency calls, but there's an issue of defining what's an emergency call
(07:22:52 AM) richard.barnes: Bovim: There are also good arguments against having only one emergency number
(07:23:16 AM) richard.barnes: But if you do have multiple numbers, they should all meet the requirements of 1-1-2
(07:23:22 AM) richard.barnes: I would not agree that there should be only one
(07:23:35 AM) richard.barnes: Hannu: I think that some other people would agree with you
(07:23:47 AM) richard.barnes: Having said that, we don't need ALL the existing numbers
(07:24:23 AM) richard.barnes: Breaking for lunch ....
(07:48:48 AM) linsner left the room.
(08:02:28 AM) linsner entered the room.
(08:17:44 AM) richard.barnes: ... and we're back!
(08:17:55 AM) richard.barnes: James Winterbottom giving an update on HELD
(08:18:22 AM) richard.barnes: HELD is the IETF application-layer location acquisition protocol
(08:18:59 AM) richard.barnes: Location comes from a local access network (no reliance on a home network or roaming agreements)
(08:19:40 AM) richard.barnes: Acquiring location is a separate action from determining location
(08:19:59 AM) richard.barnes: acquisition is independent of the type of access; determination is access-specific
(08:20:31 AM) richard.barnes: Returns location in a PIDF-LO
(08:20:58 AM) richard.barnes: Simplest HELD request is just an HTTP GET
(08:21:12 AM) richard.barnes: returns the location chosen based on the IP address of th erequestor
(08:21:26 AM) richard.barnes: Can also ask for different location formats (civic/geo) or a URI
(08:22:40 AM) richard.barnes: responseTime parameter allows recipient to specify how long it's willing to wait
(08:23:24 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/HELD.ppt
(08:23:33 AM) richard.barnes: (responseTime slide)
(08:23:38 AM) richard.barnes: (now The Location Response)
(08:23:53 AM) richard.barnes: HELD response contains a PIDF-LO and/or URIs
(08:24:47 AM) richard.barnes: Other HELD-related drafts
(08:26:55 AM) richard.barnes: Moving to the next update....
(08:27:00 AM) richard.barnes: Winterbottom on PIDF-LO Profile
(08:27:09 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/PIDF-LO-Profile.ppt
(08:27:45 AM) richard.barnes: slide 2
(08:28:13 AM) richard.barnes: Issue was that there were multiple ways to interpret a PIDF-LO; this draft clarifies
(08:28:42 AM) richard.barnes: next slide - need for guidance
(08:29:38 AM) richard.barnes: issue is a PIDF-LO can have multiple "things" of various types: tuples, <geopriv> elements, locations
(08:30:17 AM) richard.barnes: This was the original problem that PIDF-LO profile was trying to address
(08:30:34 AM) richard.barnes: Also adds geographic shapes
(08:30:45 AM) richard.barnes: next slide - geodetic shapes
(08:31:05 AM) jchiaramonte: (CRS = Coordinate Reference System)
(08:31:50 AM) richard.barnes: Linsner: The reason for supporting these shapes is as an artifact of the determination system, not because we want to describe people of those shapes
(08:33:52 AM) richard.barnes: next slide - Civic and Compound location
(08:34:10 AM) richard.barnes: revised civic should be submitted as a RFC Real Soon Now
(08:35:14 AM) richard.barnes: next slide - Confidence
(08:35:34 AM) richard.barnes: In N. America, there are regulatory requirements for confidence
(08:36:27 AM) richard.barnes: Linsner: You said there's mandates in the US to provide location with a given confidence. Is there a requirement to express location as well.
(08:36:50 AM) richard.barnes: Winterbottom: 3GPP format (GAD?) requires confidence as part of a location
(08:37:02 AM) richard.barnes: 95% = ~2 standard deviations
(08:37:21 AM) richard.barnes: Not really clear what confidence means in terms of civic location
(08:37:23 AM) jchiaramonte: Universal Geographical Area Description
(08:37:46 AM) richard.barnes: End of PIDF-LO profile update...
(08:38:12 AM) richard.barnes: Roger Marshall taking the stand (no slides available)
(08:39:07 AM) richard.barnes: Location-by-Reference Status Update
(08:39:59 AM) richard.barnes: this document is the result of a location-by-reference design team
(08:40:13 AM) richard.barnes: LbyR is an alternative to LbyValue - it's a pointer instead of an object
(08:40:50 AM) richard.barnes: Brian's presentation from yesterday showed how LbyR shows up in the NENA architecture
(08:41:35 AM) richard.barnes: Current draft has 2 segments: Requirements for location configuration protocol and location dereference protocol
(08:42:50 AM) richard.barnes: Several use cases for LbyR: Configuration/acquisition, conveyance, etc
(08:43:23 AM) richard.barnes: LbyR is used by sip-location-conveyance, held-deref, held-context-management
(08:43:32 AM) richard.barnes: very popular, useful concept
(08:43:51 AM) richard.barnes: Seeking input from other people about the utility of this work
(08:44:32 AM) richard.barnes: not a lot of controversy about this document
(08:44:45 AM) richard.barnes: Linsner: can you clarify your "no controversy" statement?
(08:45:11 AM) richard.barnes: Marshall: Just haven't gotten many comments on these requirements. The concept of LbyR might still be controversial
(08:45:26 AM) richard.barnes: Winterbottom: Think there is general consensus that LbyR is a necessary thing to have
(08:45:38 AM) richard.barnes: NENA i2 has supported references from the start
(08:46:14 AM) richard.barnes: Marshall: Current 3GPP structures have a certain type of location reference, but not a URI (ESQK?)
(08:46:24 AM) richard.barnes: Stark: It's also critical to location hiding
(08:49:22 AM) richard.barnes: (oops, stopped scribing while i got caught up in the controversy)
(08:49:53 AM) richard.barnes: Stark: Presence as a basis for LbyR also means you have authentication and access control
(08:50:25 AM) richard.barnes: Linsner: My wife gets to know I'm in belgium, my mistress that I'm in Brussels
(08:50:45 AM) richard.barnes: Conceivably, I could set it up so that 9-1-1 doesn't get anything
(08:51:01 AM) richard.barnes: Hixson: This is being done for general-purpose use, not for specific emergency service use
(08:51:16 AM) richard.barnes: Bothered by the use of coarse location in 9-1-1
(08:52:40 AM) richard.barnes: Marshall: If you do "fuzz" location, you still want to make sure that it works for routing
(08:52:54 AM) richard.barnes: Wu: It was mentioned that 3GPP might adopt this concept
(08:53:31 AM) richard.barnes: For the control plane, we have a critical response time requirement
(08:53:43 AM) richard.barnes: LbyR may induce additional delay
(08:54:28 AM) richard.barnes: Marshall: Not really worried about performance, but consistency. This style of reference should be roughly equivalent to other references in use today
(08:55:28 AM) richard.barnes: Linsner: You also get subscription from some types of location URI
(08:55:56 AM) richard.barnes: Next up: Hannes on LoST
(08:55:57 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/lost-hannes.ppt
(08:56:15 AM) richard.barnes: Slide 2
(08:56:36 AM) richard.barnes: Lost is a protocol to translate information location+service for a way to obtain that service in that location
(08:56:56 AM) richard.barnes: Slide 3
(08:57:12 AM) richard.barnes: 2nd WGLC finished in September
(08:57:32 AM) richard.barnes: Sent to IESG for processing
(08:58:12 AM) richard.barnes: Latest version adds shapes, clarifies error handling in relation to HTTP
(08:59:11 AM) richard.barnes: Slide 4
(08:59:46 AM) richard.barnes: End of LoST update
(08:59:53 AM) klaas entered the room.
(09:00:06 AM) richard.barnes: Mapping architecture also done
(09:00:29 AM) richard.barnes: Brian Rosen briefing on draft-ietf-ecrit-framework
(09:00:38 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/EScoord3-BRosen-frameworkPhonebcp.ppt
(09:00:42 AM) richard.barnes: Slide 2
(09:01:26 AM) richard.barnes: Slide 3
(09:01:42 AM) richard.barnes: Slide 3 is approximately the table of contents for the document
(09:01:56 AM) richard.barnes: Describes all the steps involved in making an emergency call
(09:04:09 AM) richard.barnes: Barnes: Clarification - this is specifically about SIP
(09:04:22 AM) richard.barnes: Rosen: Yes, for now. We will probably extend to XMPP, etc in the future
(09:04:25 AM) richard.barnes: Slide 4
(09:05:40 AM) richard.barnes: Hannu: There's an item in the table of contents on "disabling of features" what features do you have in mind?
(09:05:54 AM) richard.barnes: Rosen: Three-way calling, hold, ...
(09:06:06 AM) richard.barnes: Now briefing on phonebcp (same slides)
(09:06:11 AM) richard.barnes: Slide 7
(09:06:23 AM) richard.barnes: This says you MUST implement specific things
(09:07:34 AM) richard.barnes: This document says "what you need to do" but doesn't say 'why"
(09:08:21 AM) richard.barnes: Slide 9
(09:08:36 AM) richard.barnes: Slide 10
(09:09:13 AM) richard.barnes: Current plan of ECRIT is to go ahead and publish these documents, even though they may need updates later
(09:09:40 AM) richard.barnes: Marshall: What will be the status of phonebcp?
(09:09:51 AM) richard.barnes: Rosen: It will be a BCP, RFC 2119 applies
(09:10:00 AM) richard.barnes: Bajko: But there is no common practice
(09:10:39 AM) richard.barnes: Rosen: The closest approximation we could find. Maybe the IESG will disagree.
(09:10:59 AM) richard.barnes: Linsner: Could you provide a guide for someone who wants to understand how ECRIT works?
(09:11:10 AM) richard.barnes: Rosen: Read framework, then follow the references
(09:11:36 AM) richard.barnes: Worstell: Can you provide a link to the document?
(09:11:57 AM) richard.barnes: Rosen: google it!
(09:12:06 AM) richard.barnes: Tschofenig: We'll send it out to the SDOs
(09:12:16 AM) richard.barnes: Winterbottom: Just send a link to the ECRIT homepage
(09:12:35 AM) richard.barnes: Lange: What makes you think it's normative for any region other than the US?
(09:12:46 AM) jchiaramonte: http://tools.ietf.org/wg/ecrit/
(09:12:53 AM) richard.barnes: Rosen: The IETF doesn't allow for national variations.
(09:12:59 AM) jchiaramonte: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/
(09:13:07 AM) jchiaramonte: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-phonebcp/
(09:13:15 AM) richard.barnes: The assumption is that calls will be made over the internet
(09:14:02 AM) richard.barnes: We've tried to capture everybody's requirements
(09:14:33 AM) richard.barnes: it's got separate numbers for different services, it's got different address types for different places, etc.
(09:15:05 AM) richard.barnes: it should be usable everywhere
(09:15:39 AM) richard.barnes: Hellstrom: I'm realizing that I may have some other, immature requirements, particularly around disability services
(09:15:42 AM) linsner left the room.
(09:16:04 AM) richard.barnes: What if there's additions/changes that need to be made?
(09:16:24 AM) richard.barnes: Rosen: There will definitely need to be another version. This is a first release.
(09:18:09 AM) richard.barnes: Laura Liess talking about location hiding
(09:18:20 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/EWS_30112007_LH_v01_pdf.pdf
(09:20:17 AM) richard.barnes: Slide 1
(09:23:17 AM) richard.barnes: Slide 2
(09:23:22 AM) richard.barnes: Current plans for DT network
(09:23:54 AM) richard.barnes: Emergency calls are gatewayed to the PSTN
(09:25:42 AM) richard.barnes: Requirement from PSAPs that user cannot dial PSAP directly
(09:28:39 AM) richard.barnes: Linsner: The location determination isn't the cost, but dissemination 10^6 more times is the cost
(09:29:10 AM) richard.barnes: Laura: Also determination to keep track of dynamic IP addresses
(09:30:22 AM) richard.barnes: Winterbottom: It looks like you always have to do the IP-to-ConnectionID mapping on every call
(09:30:31 AM) richard.barnes: Stark: That's standard, from the SIP registry
(09:30:42 AM) richard.barnes: Winterbottom: How do you tell which PSAP
(09:30:49 AM) richard.barnes: Laura: We have tables
(09:30:58 AM) richard.barnes: Stark: This is vertically integrated
(09:31:10 AM) richard.barnes: Winterbottom: So this won't support a nomadic user
(09:31:13 AM) richard.barnes: Laura: Yes.
(09:31:34 AM) richard.barnes: Hannes: Connection ID is essentially the SIP location reference
(09:31:48 AM) richard.barnes: Hixson: How do you tell that a caller doesn't answer
(09:32:14 AM) richard.barnes: If you don't send location and the caller answers, what if the caller doesn't know where they are?
(09:32:43 AM) richard.barnes: Lange: The called party always answer, but the caller may not be able to say where he is.
(09:33:05 AM) richard.barnes: So it really doesn't mean "caller doesn't answer", it's "caller can't give his location"
(09:33:23 AM) richard.barnes: On which interface does the PSAP request location?
(09:33:37 AM) richard.barnes: Laura: A proprietary X.121 interface
(09:33:50 AM) richard.barnes: In some cases, it's a fax
(09:34:12 AM) richard.barnes: Marshall: The location request from the PSAP -- why does it go through the ECCC?
(09:34:56 AM) richard.barnes: Laura: Because the ECCC is a trusted entity, partly for historical reasons
(09:35:38 AM) richard.barnes: This is also exactly how it works with the PSTN (except for the VoIP leg)
(09:36:56 AM) richard.barnes: Palm: It seems like if this is for a fixed phone, you still have a phone number, so you can just use the old TN->Address database
(09:37:12 AM) richard.barnes: Laura: This works with nomadic users, as long as its within the DT IP network
(09:37:17 AM) richard.barnes: Slide 3
(09:38:11 AM) richard.barnes: Privacy considerations are very important - European Directive 2002/58/EC
(09:40:14 AM) richard.barnes: Liess: If we just send location to the user, we may not be in compliance with this directive
(09:40:29 AM) richard.barnes: This has been the recommendation of DT legal
(09:44:49 AM) richard.barnes: Barnes: While the directive doesn't prohibit giving location to the user, it does require that the provider have strong assurance that it is the user himself that is receiving the location
(09:45:18 AM) richard.barnes: Liess: Also, it's possible that there's malicious software
(09:46:22 AM) richard.barnes: ???: Surely the point is that if anyone is given his location, that person can decide what he does with it
(09:46:33 AM) richard.barnes: So once you've given the location, that's the end of the operator's responsibility
(09:47:16 AM) richard.barnes: Barnes: That emphasizes the importance of assuring that entities that receive location are the correct entities
(09:47:41 AM) richard.barnes: Wu: Question about the IETF position about the terminal side -- Does the terminal have to have its location for ES?
(09:49:29 AM) richard.barnes: Hixson: The PSAP needs it too!
(09:49:42 AM) richard.barnes: Winterbottom: But you could give the endpoint a PSAP URI and a location URI and be done.
(09:50:06 AM) richard.barnes: Stark: In certain jurisdictions, regulators might frown on handing out location without due diligence
(09:50:34 AM) richard.barnes: Linsner: The concept is that you would authenticate a user differently to give him location?
(09:51:14 AM) richard.barnes: Stark: THe protocols go beyond their application to ES, and in certain environments, you might just want to give devices referenecs
(09:52:50 AM) richard.barnes: Liess: Our customers are generally not technical experts. So they may say 'yes' without really knowing the consequences
(09:53:58 AM) richard.barnes: Lange: Who takes responsibility for the accuracy and correctness of the location?
(09:54:10 AM) richard.barnes: I expect that nobody wants to take this responsibility
(09:54:47 AM) richard.barnes: So you have to ask who can be trusted, and usually, the user is the least trustworthy
(09:54:59 AM) richard.barnes: There are many fewer carriers and ISPs than customers
(09:55:26 AM) richard.barnes: so PSAPs will likely put more trust in ISPs/VSPs than in users. Same is true of CLI
(09:55:43 AM) klaas left the room (Replaced by new connection).
(09:55:45 AM) richard.barnes: Winterbottom: LbyR is one way to do it; location signing is another
(09:56:46 AM) richard.barnes: Can use these sorts of things for redirect
(09:56:57 AM) richard.barnes: Lange: In many cases, you might not need location at the dispatch center
(09:57:40 AM) richard.barnes: First thing a dispatcher does is verify the location with the user
(09:59:31 AM) richard.barnes: Slide 9
(10:01:55 AM) richard.barnes: Slide 11
(10:03:32 AM) richard.barnes: Slide 12
(10:05:47 AM) richard.barnes: ???: What does it mean that a PSAP boundary has a hole?
(10:06:09 AM) richard.barnes: Stark: This just means that the location used for routing needs to get you to the right place...
(10:06:31 AM) richard.barnes: ???: Your diagram doesn't make sense to me
(10:06:44 AM) richard.barnes: Stark: In the US, this is pretty common, with a city contained in a county
(10:07:21 AM) richard.barnes: Winterbottom: Also heard about holes in Austria, Italy (Vatican). Things in lakes are treated differently than things around lakes
(10:07:55 AM) richard.barnes: Hannu: I'm in the middle of a hole and I get in trouble -- does that go to the hole PSAP or the bigger one?
(10:08:16 AM) richard.barnes: Winterbottom: To the hole PSAP
(10:09:46 AM) richard.barnes: Linsner: A little bit of background: It was proposed to use "rough" location for routing, so the "roughness" can't cause things to fail when there's a hole
(10:10:38 AM) richard.barnes: ???: For routing, it's important that you think in polygons, not boundaries
(10:12:56 AM) richard.barnes: Slide 13
(10:15:30 AM) richard.barnes: Kytt: Let me describe what happens with a SkypeIn number. To purchase one in Germany right now, you have to enter a civic address.
(10:16:02 AM) richard.barnes: This essentially means that even though the information is never used (since SkypeIn numbers never originate calls), Skype is forced to collect location information about the user
(10:16:16 AM) richard.barnes: So if we're talking about location hiding, we should do so consistently
(10:17:36 AM) richard.barnes: Linsner: We're really talking about the network provider providing the location; this doesn't keep the user from using a location that he already knows
(10:18:37 AM) richard.barnes: Lange: Do you also need to consider lots of old-fashioned terminals?
(10:19:13 AM) richard.barnes: Ok, end of location hiding
(10:19:54 AM) richard.barnes: Hannes talking about unauthenticated emergency services
(10:20:04 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/unauthenticated-emergency-services-hannes.ppt
(10:20:09 AM) richard.barnes: Slide 2 now
(10:21:33 AM) richard.barnes: Slide 3
(10:24:05 AM) richard.barnes: Slide 4
(10:25:09 AM) richard.barnes: Slide 5
(10:25:50 AM) richard.barnes: Hannes: You need to have some intelligence in the access network, so that you can distinguish cases of fraud and abuse
(10:26:10 AM) richard.barnes: the access network needs to be able to limit the unauthorized caller to only making emergency calls
(10:26:30 AM) richard.barnes: Also, the caller needs to use a very limited VoIP profile
(10:26:44 AM) richard.barnes: Same signaling protocol (SIP) everywhere
(10:28:38 AM) richard.barnes: Also depends a lot on lower-layer procedures just to get the caller access to the IP network
(10:29:16 AM) richard.barnes: Slide 6
(10:29:50 AM) richard.barnes: Worstell: Is this directed at hotspots in particular? Does my personal AP need to give him access?
(10:31:17 AM) richard.barnes: I'm bringing this up because we have regulators in the room. How far do you extend the requirement?
(10:32:02 AM) richard.barnes: Price: BT have recently announced that users will be able to be FON access points
(10:32:13 AM) richard.barnes: This blurs the line between public and private
(10:33:26 AM) richard.barnes: ???: I think that this morning it became clear that the requirements would be for service providers -- by doing FON, do I become a service provider?
(10:34:41 AM) richard.barnes: ???: This also raises the question of who in the protocol stack is responsible for making things work?
(10:38:00 AM) richard.barnes: McCann: Has this work gone far enough that you could provide an audit trail to support callback?
(10:38:26 AM) richard.barnes: Hannes: In the unauthenticated cases, there's no real identity.
(10:38:41 AM) richard.barnes: In that case, phonebcp provides a temporary call-back identifier
(10:39:02 AM) richard.barnes: Winterbottom: The IETF has not said that this is good to deploy, it's more of a consideration
(10:39:08 AM) richard.barnes: to investigate
(10:42:33 AM) richard.barnes: ???: Will this also work for PSAPs that are not IP connected?
(10:43:01 AM) richard.barnes: Rosen: This just says what happens in the IP signaling; probably doesn't work with PS-only PSAPs
(10:43:38 AM) richard.barnes: Rosen briefing about draft-ietf-sip-location-conveyance
(10:43:48 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/SIP_Location_Conveyance_Update.ppt
(10:43:52 AM) jchiaramonte: previous comment was Milan Patel-Nortel
(10:43:54 AM) richard.barnes: used to carry location in a SIP message
(10:44:38 AM) richard.barnes: next slide: Recent changes
(10:45:52 AM) richard.barnes: Winterbottom: "used-for-routing" only indicates the PIDF-LO
(10:46:04 AM) richard.barnes: Rosen: Right, can't distinguish among locations within a PIDF-LO
(10:46:19 AM) richard.barnes: next slide: Recent Changes II
(10:48:30 AM) richard.barnes: next slide: Status
(10:48:55 AM) richard.barnes: Wu: Location information is conveyed by SIP?
(10:49:15 AM) richard.barnes: Hannes: If you provide LbyR, then the dereference protocol also carries location
(10:50:21 AM) richard.barnes: Rosen: But right now, the only location dereference mechanism is SIP.
(10:50:47 AM) richard.barnes: Next up: Barbara Stark, on DSL Forum status
(10:50:49 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/DSL_Forum_Report.ppt
(10:51:35 AM) richard.barnes: Slide 2
(10:51:51 AM) richard.barnes: This document tries to pick up where phonebcp leaves off
(10:52:02 AM) richard.barnes: Tries to clarify anything that's ambiguous in phonebcp
(10:52:57 AM) richard.barnes: Barnes: What about this document is specific to DSL?
(10:53:14 AM) richard.barnes: Stark: Nothing
(10:53:23 AM) richard.barnes: Barnes: Why not just put it into phonebcp?
(10:53:37 AM) richard.barnes: Stark: There are things that phonebcp doesn't want to include
(10:53:41 AM) richard.barnes: Slide 3
(10:54:44 AM) richard.barnes: DSL forum does more than DSL, also pays attention to devices that hang off of DSL, and to related technologies
(10:55:47 AM) richard.barnes: Providers of other type of services have picked up DSLForum documents in the past
(10:58:32 AM) richard.barnes: Slide 6 now
(10:58:57 AM) richard.barnes: Slide 7
(10:59:58 AM) richard.barnes: Don't think phonebcp will get to the level of detail -- decision-making processes, flowcharts
(11:03:29 AM) richard.barnes: Barnes: But there are ambiguities in phonebcp that need to be resolved -- how does a client connecting to a network figure out which LCP to use?
(11:03:47 AM) richard.barnes: That's somewhere in between phonebcp and Barbara's document
(11:04:16 AM) richard.barnes: Steve McCann briefing on IEEE 802.11
(11:04:29 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/11-07-2694-00-000u-IEEE_802_wide_project_on_ES.ppt
(11:04:57 AM) richard.barnes: Slide 3
(11:05:10 AM) richard.barnes: Apologies to Hannes for not getting to the IETF before now
(11:07:16 AM) richard.barnes: Slide 4
(11:07:30 AM) richard.barnes: Trying to start an IEEE ES project
(11:08:34 AM) richard.barnes: Slide 5
(11:09:49 AM) richard.barnes: Slide 6
(11:10:32 AM) richard.barnes: 802.21 is looking at handover between different things/networks in an emergency call
(11:11:19 AM) richard.barnes: Slide 7
(11:11:21 AM) richard.barnes: Slide 8
(11:11:29 AM) richard.barnes: Slide 9
(11:12:08 AM) richard.barnes: Slide 10
(11:12:22 AM) jchiaramonte: 802.11p also has some alliance with the 4.9 GHz band of PS
(11:13:12 AM) richard.barnes: GAS allows APs to advertise more detailed information, e.g., whether they support ES
(11:13:44 AM) richard.barnes: Slide 11
(11:14:49 AM) richard.barnes: Capabilities in 11v are pretty well-aligned with IETF (e.g., in location formats)
(11:15:04 AM) richard.barnes: Also supports LbyR
(11:16:07 AM) richard.barnes: Slide 12
(11:16:10 AM) richard.barnes: Slide 13
(11:16:52 AM) richard.barnes: End of McCann's presentation
(11:17:24 AM) richard.barnes: ???: What requirements are you deriving from eCall?
(11:17:44 AM) richard.barnes: McCann: None specifically, yet. We're just aware that they might have some.
(11:18:08 AM) richard.barnes: Hannes: About QoS - Do you plan to have QoS only at the link layer, or do you expect that that higher layers are helping as well?
(11:18:20 AM) richard.barnes: Providing something on the air interface is not the whole story
(11:18:40 AM) richard.barnes: McCann: Intent is that we would have some sort of hook to pass QoS down the line
(11:19:00 AM) richard.barnes: But we're constrained by our role in Layers 1-2
(11:19:09 AM) richard.barnes: Hannes: Are people implementing layer 2 QoS?
(11:19:21 AM) richard.barnes: McCann: I believe people are.
(11:20:19 AM) richard.barnes: [ Steve & Barbara discussing liaison on DSLForum doc ]
(11:20:25 AM) richard.barnes: [ they'll figure it out ]
(11:20:50 AM) richard.barnes: Next up: Dirk Kroeselberg on WiMAX
(11:20:52 AM) richard.barnes: http://www.tschofenig.com/twiki/pub/EmergencyServices/EswAgenda2007/071017_ES_WiMAX_NWG_status.ppt
(11:21:31 AM) richard.barnes: second slide - the wimax forum
(11:21:41 AM) richard.barnes: Talking specifically about the Network Working Group
(11:21:47 AM) richard.barnes: and their ES activities
(11:21:58 AM) richard.barnes: Skipping through overview; see the website
(11:22:05 AM) richard.barnes: http://www.wimaxforum.org/
(11:23:26 AM) richard.barnes: Next slide: Work group structure
(11:23:57 AM) richard.barnes: next slide: Network Reference Model
(11:24:04 AM) richard.barnes: (non-roaming case)
(11:25:24 AM) richard.barnes: Important thing is the separation of the providers of physical and network access
(11:25:35 AM) richard.barnes: next slide - Entities in the Reference Model
(11:26:39 AM) richard.barnes: next slide - network reference model (roaming case)
(11:27:06 AM) richard.barnes: 3 different business entities here
(11:27:21 AM) richard.barnes: next slide - NWG Specification
(11:30:27 AM) richard.barnes: next slide - ES work in NWG
(11:33:31 AM) richard.barnes: Rosen: You are responsible for supplying location
(11:33:41 AM) richard.barnes: Dirk: Is that a regulatory requirement?
(11:33:59 AM) richard.barnes: Rosen: Not yet. Discussion this morning might indicate that it's coming, and FCC might have something soon.
(11:34:35 AM) richard.barnes: Stark: We need location out of WiMAX
(11:34:52 AM) richard.barnes: There's an expectation from people that work with the FCC that the FCC is likely to require it
(11:35:18 AM) richard.barnes: Rosen: Specifically point you to the framework/phonebcp
(11:35:28 AM) richard.barnes: In particular, the part for access networks
(11:37:00 AM) jchiaramonte: Hixson - where is WiMAX on non-voice ES?
(11:37:12 AM) jchiaramonte: Dirk - need to be aware of that to put into requirements
(11:37:23 AM) richard.barnes: (thanks John - want to keep going :)
(11:37:37 AM) richard.barnes: ?
(11:37:44 AM) jchiaramonte: Hixson - getting heat in the US from the ADA with regard to people using text today
(11:37:55 AM) jchiaramonte: sorry - didn't get James' comment
(11:38:19 AM) richard.barnes: ???: In WiMAX, are there protocols at the radio level to get location?
(11:38:43 AM) richard.barnes: Dirk: There's some initial work being done on base-station ID granularity
(11:38:59 AM) richard.barnes: No triangulation right now
(11:39:59 AM) richard.barnes: Wu: OMA SUPL is being extended to support WiMAX
(11:40:09 AM) richard.barnes: Dirk: Ongoing discussion to determine which protocols to use
(11:41:13 AM) richard.barnes: WiMAX forum is not the right place to do VoIP work
(11:42:00 AM) richard.barnes: Rosen: Absolutely agree. However, you need 100m accurate location. Not right away (like with cellular), but you're going to need it.
(11:42:14 AM) richard.barnes: There's no regulation right now, nothing that says you have to do it, but it's just a matter of time
(11:42:24 AM) richard.barnes: Please don't bury your head in the sand
(11:42:41 AM) richard.barnes: Dirk: Location team is working on that; Base Station granularity is the first step
(11:43:14 AM) richard.barnes: Winterbottom: Based on timing advance, you're going to get a lot better than GPS
(11:43:19 AM) JamesWinterbottom left the room.
(11:43:24 AM) richard.barnes: That's it for today...
(11:43:27 AM) richard.barnes: Off to beer!
(11:44:00 AM) richard.barnes: Well, one more slide: WiMAX roamingconsiderations
(11:44:02 AM) richard.barnes: (ctd)
(11:46:04 AM) richard.barnes: (ctd, again)
(11:48:44 AM) richard.barnes: Stark: Really think there needs to be an acknowledgement that you you can have IWLANs, but you're also going to have the case where it's just another broadband connection
(11:49:00 AM) richard.barnes: In that case, there will not be a relationship between the VSP and ANY of the access providers
(11:49:18 AM) richard.barnes: Winterbottom: If you design for the latter, you get the former for free
(11:49:28 AM) richard.barnes: [ latter = no relationship, former = relationship ]
(11:49:39 AM) richard.barnes: next slide - Unauthorized access
(11:51:13 AM) richard.barnes: next slide - Subscription-less Access
(11:53:13 AM) richard.barnes: ???: When you say WiMAX certification, what does that entail
(11:53:22 AM) richard.barnes: Dirk: Defined interop tests for device
(11:55:10 AM) richard.barnes: One idea: give WiMAX certified access devices device certs, so there's never really any unauthenticated access
(11:55:23 AM) richard.barnes: (Signing off to head for the bus...)