From rbarnes@bbn.com Wed May 12 20:01:35 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1AB3A6923; Wed, 12 May 2010 20:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_50=0.001, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6sNvvvERGQk; Wed, 12 May 2010 20:01:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 513DA3A6908; Wed, 12 May 2010 20:01:34 -0700 (PDT) Received: from [128.89.254.67] (port=50098 helo=[192.168.1.47]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OCOfr-000KOf-85; Wed, 12 May 2010 23:01:23 -0400 Message-Id: <54B33341-E8B9-4563-BD34-D68DCDF1DB7A@bbn.com> From: Richard Barnes To: geopriv@ietf.org, ecrit@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 May 2010 23:01:22 -0400 References: <9E7FA17E-0029-4B16-9E86-303A8B2873C6@bbn.com> X-Mailer: Apple Mail (2.936) Subject: [Ecrit] igtk++ X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 03:01:35 -0000 This is more implementation-focused (so for further discussion, please move to the loc-imp list [1]), but thought some folks on GEOPRIV and ECRIT might be interested. --Richard [1] Begin forwarded message: > From: Richard Barnes > Date: May 12, 2010 2:33:31 PM EDT > To: loc-imp@googlegroups.com > Subject: igtk++ > > Hey all, > > We're pleased to announce that we've released an update to our > Internet Geolocation Toolkit (igtk). Highlights of this update: > -- Support for LIS discovery > -- Support for WiFi measurements > -- Java and XPCOM interfaces > -- Some sample location-based applications > -- Location servers in Perl and Java > > One caveat: Since these first few releases have been in a growth > phase, the code base is a little bit of a mess. One major objective > for the next round is to give things a more logical structure and > flow, tidy up dependencies, etc. Nonetheless, I consider the > software safe to use -- it's not going to erase your hard drive or > something. (And I won't take responsibility if it does!) > > Hope this is interesting. Let me know if you have questions or > comments -- or if you would like to contribute! > > Best, > --Richard From wwwrun@core3.amsl.com Tue May 18 07:46:42 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 87BDC28C17C; Tue, 18 May 2010 07:46:42 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100518144642.87BDC28C17C@core3.amsl.com> Date: Tue, 18 May 2010 07:46:42 -0700 (PDT) Cc: ecrit chair , Internet Architecture Board , ecrit mailing list , RFC Editor Subject: [Ecrit] Protocol Action: 'Specifying Holes in LoST Service Boundaries' to Proposed Standard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 14:46:42 -0000 The IESG has approved the following document: - 'Specifying Holes in LoST Service Boundaries ' as a Proposed Standard This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-03.txt Technical Summary The LoST protocol maps location and service identifiers to Uniform Resource Identifiers (URIs). LoST may additionally return a so-called service boundary, i.e., a region within which all locations map to the same service URI or set of URIs for a given service. The geodetic boundary is a polygon made up of sets of geodetic coordinates specifying an enclosed area. In some circumstances an area enclosed by a polygon, also known as an exterior polygon, may contain exception areas, or holes, that for the same service must yield a different destination to that described by the larger area. This document describes how holes should be specified in service boundaries defined using a GML encoding for the polygons and their internal elements (holes). Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has been reviewed by ECRIT working group members and feedback was provided by Carl Reed from the OGC. Personnel Hannes Tschofenig is the document shepherd for this document. RFC Editor Note Section 1: OLD: This document describes a profile of Geographic Markup Language (GML) [ISO-19107] polygons that constrains their representation when used for describing service boundaries. NEW: This document describes a profile of Geographic Markup Language (GML) [ISO-19107] polygons that constrains their representation when used for describing service boundaries. The profile removes a number of permutations that are difficult to process. This allows for simplified implementations that are not capable of handling all potential variations allowed by GML. A fully conformant GML implementation must produce polygons that fit this profile to ensure interoperability. From hoene@uni-tuebingen.de Thu May 27 03:49:18 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA333A6781; Thu, 27 May 2010 03:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3haxnM9nonQU; Thu, 27 May 2010 03:49:16 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 567C23A6880; Thu, 27 May 2010 03:49:16 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4RAmvSu003951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 May 2010 12:48:58 +0200 From: "Christian Hoene" To: "'Cullen Jennings'" , References: <2575CD49-B0DE-4257-B9B7-A0F84D1A8F3F@cisco.com> In-Reply-To: <2575CD49-B0DE-4257-B9B7-A0F84D1A8F3F@cisco.com> Date: Thu, 27 May 2010 12:48:58 +0200 Message-ID: <002a01cafd8a$3691f610$a3b5e230$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr9TeFvwAIcoQvjTqijHtTrJC4yEQAON8cg Content-Language: de x-cr-hashedpuzzle: IYQt Ix0f I6YU Jh7D LrlL Ocnd P51K Q/Cb TqJJ VuXt WLse ZFae eIEq jrbT k+Jd lzBm; 4; YgByAEAAYgByAGkAYQBuAHIAbwBzAGUAbgAuAG4AZQB0ADsAYwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAZQBjAHIAaQB0AEAAaQBlAHQAZgAuAG8AcgBnADsAZgBsAHUAZgBmAHkAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sosha1_v1; 7; {F07F4252-EE12-49CE-A695-F7B5DDFFBE02}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Thu, 27 May 2010 10:48:09 GMT; UwBwAGUAZQBjAGgAIABRAHUAYQBsAGkAdAB5ACAAQQBzAHAAZQBjAHQAcwAgAGkAbgAgAGUAbQBlAHIAZwBlAG4AYwB5ACAAYwBhAGwAbABzAA== x-cr-puzzleid: {F07F4252-EE12-49CE-A695-F7B5DDFFBE02} X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: ecrit@ietf.org Subject: [Ecrit] Speech Quality Aspects in emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 10:49:18 -0000 Hello Cullen, dear ECRIT experts, >I think that the bulk of the people that work on emergency calls in the ECRIT WG and much of the IESG >are going to be very strong supporters of exactly what Brian is saying here. I agree that the support of emergency call are important, also in the IETF WG Codec. However, at this point of time it is not clear to me what the service requirements of an emergency call are going to be. Which speech/audio quality requirements do the emergency agencies have? Brian is suggesting a technical solution to become a requirement. But, don't we have to listen to the users, first? Only then, we can develop a technical solutions that might affect our work in the Codec WG. > The implications aren't a >big deal for the CODEC WG, just that you need to be able to use SDP to signal no VAD. Are you sure that this is the only requirement? I think that there are other important things in case of emergency calls. Do they need audio quality? Do they need ultra-low-delay or is any transmission delay fine? What shall happen, if the transmission quality is bad? Push-to-talk? > No one thinks an >end user is going to go and change the configuration in their phone before making an emergency call. No, he does know VAD and he does not care about. Some part of the system must take care of. However, the user does know that he wants to make a emergency call and the phone might have a button called "emergency call". >If you want the CODEC chairs to go ask the ECRIT WG Chairs if they think this is a requirement for an >internet codec, it's easy to make that happen but they are going to tell us the same thing Brian is. Good idea, I carbon-copied this email to the ECRIT mailing list, if you do not mind. With best regards, Christian > > > >On May 24, 2010, at 12:20 PM, Brian Rosen wrote: > >> Okay, you asked for it :) >> >> In any country, the codes used in another country for emergency numbers are >> used as service invocations for other services. You have to know what >> country you are in to know what emergency numbers are. It is roughly >> impossible (today) to know that with sufficient reliability. >> >> You can place an emergency call to an e.164 in many countries. This may >> depend on which service. >> >> The emergency call center (PSAP) can call you back. >> >> A call placed to a call center can be transferred or upgraded to an >> emergency call. This happens with relay centers used by disabled >> individuals. >> >> In all of these circumstances, VAD must be disabled. Emergency calling >> systems are filled with a lot of complexity that handle seldom occurring >> circumstances. However, when it comes to saving lives, seldom occurring >> circumstances are important. >> >> Brian >> >> ps - I have been working in this field for a number of years. You can learn >> a bit more about emergency calling from draft-ietf-ecrit-framework. The >> inability to turn off VAD in VoIP systems believed to have caused actual >> harm according to some of my associates who work in PSAPs. >> >> >> >> >> On 5/24/10 1:37 PM, "Christian Hoene" wrote: >> >>> Hi Brian, >>> >>>> I'll be happy to go into the details, but phones may not know they are in an >>>> emergency call. No phone knows this today. There is some proposed >>>> signaling that would tell them, IF the phone, and the service provider >>>> implement it, but even then, there are circumstances where the phone won't >>>> know. >>> >>> If(called.number==112 || called.number==911 || called.number=XYZ) >>> EmergencyCall(); >>> >>> See more at http://en.wikipedia.org/wiki/1-1-2 >>> It is so easy to know... I do not get your arguments. >>> >>> With best regards, >>> >>> Christian >>> >>> >>> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec From br@brianrosen.net Thu May 27 06:15:25 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099EC3A6931; Thu, 27 May 2010 06:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.935 X-Spam-Level: X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YyGjsGGMTxk; Thu, 27 May 2010 06:15:18 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id E0C1B3A68E4; Thu, 27 May 2010 06:15:15 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.195]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1OHcvK-0000A8-JP; Thu, 27 May 2010 08:14:58 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 27 May 2010 09:14:56 -0400 From: Brian Rosen To: Christian Hoene , Cullen Jennings , Message-ID: Thread-Topic: Speech Quality Aspects in emergency calls Thread-Index: Acr9TeFvwAIcoQvjTqijHtTrJC4yEQAON8cgAAX2Tq4= In-Reply-To: <002a01cafd8a$3691f610$a3b5e230$@de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] Speech Quality Aspects in emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 13:15:25 -0000 Generally, high fidelity is a good thing for emergency calls. This has to be balanced against how many codecs each PSAP implements, but at least in the evolving North American standards, which are currently believed to be the most advanced, it is recommended that PSAPs implement one or two wideband codecs. Graceful fallback in cases of congestion would be nice, but not a hard requirement. Delay below 150ms is unlikely to be of much use. Sometimes, an emergency call can have audio+video and the delays must match (lip sync). Frame time really doesn't matter much independent of its effect on delay. I personally think delay over 150ms is not acceptable, but we've had this discussion and there are some who persist in believing you can get good quality with 250 ms. In an emergency call, stress is a big factor, and social skills are not nuanced. This means turn taking is an issue, and anything that gets in the way of an interruption is bad. All of my testing indicates that turn taking, especially argument, is impaired above around 150 ms. All of the above doesn't really rise to hard requirements other than the soft requirement that delay doesn't impair turn taking. The ability to disable VAD is a hard requirement. I believe that is it with respect to codec. See ietf-ecrit-phonebcp for the actual requirements. Brian On 5/27/10 6:48 AM, "Christian Hoene" wrote: > Hello Cullen, > dear ECRIT experts, > >> I think that the bulk of the people that work on emergency calls in the ECRIT >> WG and much of the IESG >> are going to be very strong supporters of exactly what Brian is saying here. > > I agree that the support of emergency call are important, also in the IETF WG > Codec. However, at this point of time it is not clear > to me what the service requirements of an emergency call are going to be. > Which speech/audio quality requirements do the emergency > agencies have? > > Brian is suggesting a technical solution to become a requirement. But, don't > we have to listen to the users, first? Only then, we > can develop a technical solutions that might affect our work in the Codec WG. > >> The implications aren't a >> big deal for the CODEC WG, just that you need to be able to use SDP to signal >> no VAD. > > Are you sure that this is the only requirement? I think that there are other > important things in case of emergency calls. Do they > need audio quality? Do they need ultra-low-delay or is any transmission delay > fine? What shall happen, if the transmission quality > is bad? Push-to-talk? > >> No one thinks an >> end user is going to go and change the configuration in their phone before >> making an emergency call. > > No, he does know VAD and he does not care about. Some part of the system must > take care of. However, the user does know that he > wants to make a emergency call and the phone might have a button called > "emergency call". > >> If you want the CODEC chairs to go ask the ECRIT WG Chairs if they think this >> is a requirement for an >> internet codec, it's easy to make that happen but they are going to tell us >> the same thing Brian is. > > Good idea, I carbon-copied this email to the ECRIT mailing list, if you do not > mind. > > With best regards, > > Christian > >> >> >> >> On May 24, 2010, at 12:20 PM, Brian Rosen wrote: >> >>> Okay, you asked for it :) >>> >>> In any country, the codes used in another country for emergency numbers are >>> used as service invocations for other services. You have to know what >>> country you are in to know what emergency numbers are. It is roughly >>> impossible (today) to know that with sufficient reliability. >>> >>> You can place an emergency call to an e.164 in many countries. This may >>> depend on which service. >>> >>> The emergency call center (PSAP) can call you back. >>> >>> A call placed to a call center can be transferred or upgraded to an >>> emergency call. This happens with relay centers used by disabled >>> individuals. >>> >>> In all of these circumstances, VAD must be disabled. Emergency calling >>> systems are filled with a lot of complexity that handle seldom occurring >>> circumstances. However, when it comes to saving lives, seldom occurring >>> circumstances are important. >>> >>> Brian >>> >>> ps - I have been working in this field for a number of years. You can learn >>> a bit more about emergency calling from draft-ietf-ecrit-framework. The >>> inability to turn off VAD in VoIP systems believed to have caused actual >>> harm according to some of my associates who work in PSAPs. >>> >>> >>> >>> >>> On 5/24/10 1:37 PM, "Christian Hoene" wrote: >>> >>>> Hi Brian, >>>> >>>>> I'll be happy to go into the details, but phones may not know they are in >>>>> an >>>>> emergency call. No phone knows this today. There is some proposed >>>>> signaling that would tell them, IF the phone, and the service provider >>>>> implement it, but even then, there are circumstances where the phone won't >>>>> know. >>>> >>>> If(called.number==112 || called.number==911 || called.number=XYZ) >>>> EmergencyCall(); >>>> >>>> See more at http://en.wikipedia.org/wiki/1-1-2 >>>> It is so easy to know... I do not get your arguments. >>>> >>>> With best regards, >>>> >>>> Christian >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >