From ecrit-bounces@ietf.org Wed Feb 01 06:53:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4GXv-00032t-2d; Wed, 01 Feb 2006 06:53:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4GXt-00031X-2j for ecrit@megatron.ietf.org; Wed, 01 Feb 2006 06:53:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07801 for ; Wed, 1 Feb 2006 06:51:21 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Giq-0001dt-Fk for ecrit@ietf.org; Wed, 01 Feb 2006 07:04:29 -0500 Received: from [10.0.1.100] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 01 Feb 2006 06:52:02 -0500 id 01588075.43E0A0E2.000009C5 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Wed, 1 Feb 2006 06:52:43 -0500 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Subject: [Ecrit] initial thoughts on draft-taylor-ecrit-security-threats-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Though I haven't had the chance to review this draft as thoroughly as I would have liked, here are my comments on this revision: 1) Overall, I like the changes. Tom, you have done a very good job. I especially appreciate the requirements changes from things like "MUST do channel security" to "MUST provide integrity". Again, good job. 2) My two main points from the last revision still stand. Here they are from that email: > a) First, I question whether or not they are overly burdensome with > regard to performance. Invoking channel security is more than just > a few roundtrips and is CPU intensive. Additionally, the > requirement for object signing may be even more burdensome, as it > requires the triple of location info, URI, and timestamp (that's a > lot of data to sign -- especially in the geo x,y,z case, and just > how often does it need resigning). And I certainly don't think > both of these measures are required. Now, this isn't to say that what is stated in the draft is incorrect. The point here is that there is a real-world gap between what we would like to have and what we can deploy. Any system that requires channel-based integrity & confidentiality while also dictating multiple objects signed on-the-fly is going to be its own denial of service attack. > b) There is no discussion regarding what a user would do if > authentication fails. What does it mean? Do they just put down > the phone and let their house burn down? Or do they continue on > with the call in hopes that the authentication failure is false > indicator? Understanding the use case will likely lighten the load. After all, authentication is worthless if there is no authorization that can be applied to it. I believe this point was made in Vancouver as well. 3) Section 6.1 says that LI configured manually must be authenticated and authorized. If this is true, then in reality you are ruling out manually configured LI. But going beyond that, how is GPS acquired LI any better than manually configured LI? If all an attacker has to do is set the "I got this from GPS" flag to true, doesn't that just circumvent the protection placed against manual configuration? So do we then need to authenticate and authorize GPS acquired LI? If so, just how will that be accomplished? 4) Section 5.4 should include the threat that information gained from the IP network could be used by attackers in the PSTN against the PSAPs, as has been discussed on this list many times. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 01 07:30:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4H7l-0002wm-Ci; Wed, 01 Feb 2006 07:30:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4H7h-0002uf-2F for ecrit@megatron.ietf.org; Wed, 01 Feb 2006 07:30:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13448 for ; Wed, 1 Feb 2006 07:28:22 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4HIh-0002t9-Nm for ecrit@ietf.org; Wed, 01 Feb 2006 07:41:32 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F4H7M-0000G5-IB; Wed, 01 Feb 2006 06:29:51 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Stark, Barbara'" Subject: RE: [Ecrit] Issue 30: Summary Date: Wed, 1 Feb 2006 07:27:06 -0500 Message-ID: <00d801c6272a$d96e1de0$2b6414ac@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYm7a99FWbMSR2aQdaOcnJjUEh6qQAPJSfw In-Reply-To: <43E015D7.3010506@cs.columbia.edu> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think incidence will be higher that you think, but I'll also agree that as overlap dialing decreases, the problem decreases. I can live with punting this problem for now; we don't really have the expertise to decide, as long as we do standardize the mechanisms to learn the home and visited emergency dialstrings. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Tuesday, January 31, 2006 8:59 PM To: Stark, Barbara Cc: ecrit@ietf.org Subject: Re: [Ecrit] Issue 30: Summary While this is an interesting debate, I think we need to recognize that we're worrying about a very small fraction of users, with a likely decrease to zero over time, namely: - overlap dialing (i.e., ATA-style devices rather than mobile) - roaming or using a foreign VSP - likely to be residential rather than office (PBX) use; I just don't see that many businesses deploying a PBX with a foreign VSP (and those businesses are likely to hand-tune their dial plan in any event) I think the most common use of foreign dial plans will be *inbound* calls, e.g., from relatives and friends in the old home country. Since this is indeed a rare case, we need to make sure it works correctly, precisely because visitors, babysitters and the like will have no clue, like Brian noted. However, it is probably less important that these rare emergency calls are delayed by a few seconds. The time-out delay noted seems well within the standard answer delay budget of most PSAPs. On the other hand, given that the owner of the phone is likely to be aware of the special status of the foreign dial plan, I don't see much of a practical problem if he has to dial #9112345 for the rare cases of collision with a local number. Yes, there might be a mistake made and an accidental 911 call placed, but the number of such arrangements will be so small, that it is unlikely to matter. Given that there is no perfect solution, I don't think we need to make a decision on this now; operational experience can dictate whether 911T (timeout) or 911. (immediate) is the right dial plan (or maybe even 911C, where C stands for confirmation). We just need to design discovery protocols that allow for both options. By the time this stuff gets widely deployed, this may be about as relevant as rotary dials. Stark, Barbara wrote: > This seems generally reasonable to me, also. > However, there is an implicit expectation in the description below that > I'm not quite comfortable with, in the "precedence" statement. That is, > whether or not end of dialing string is automatically recognized for > visited emergency numbers. > > For devices that use a "Send" button, this isn't a problem. "Send" must > always be pressed to indicate "end of dialing". For these, there would > be no clash between a US "911" and UK "911xxx" dial string. If the user > enters "911xxx" + "Send", then this must never be interpreted as "911". > Similarly, "911" + "Send" is equally unambiguous (in this example). > > SIP devices without a "Send" button generally employ a variety of > mechanisms to recognize "end of dialing". > 1. Some strings are automatically recognized; for example, when a user > dials any "N11" string and has an ATA configured for US dialing plans, > the ATA recognizes this string and automatically sends the SIP Invite > without waiting any further. > > 2. The user can usually press "#" to indicate end of dialing. Many > users are unaware of this fact. > 3. If the user does not press another digit in 4 or 5 seconds (differs > by device), this is interpreted as end of dialing, and the SIP Invite is > sent. > > What this means, is that, if a user enters a string that is not > automatically recognized as being "complete", and the user doesn't press > "#", there will be a 4 or 5 second delay between the time when the last > digit is pressed and SIP signaling begins. > > While I realize that this delay is generally undesirable, I would prefer > that there be no requirement to automatically recognize "end of dialing" > for visited emergency strings. > > The flip side of this is that if the ATA's current dialing plan has an > automatically escaped string that is shorter than the visited emergency > number (e.g., an ATA might automatically recognize "00" as a complete > string, and the visited emergency number is "000"), then the ATA logic > needs to stop recognizing "00" as a complete string. I'm fine with this. > The user can then dial "00" (+ timeout) or "00#", and also "000" (+ > timeout) or "000#". > > If done this way, the only clashes would be for exact matches. > Barbara > ======================================== > On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote: > > 1. By default, the device is set to use the home dialplan > and home emergency numbers, either directly or via > the home provider. > 2. If not at home, the device get its location and also > the visited emergency numbers via some means > 3. The visited emergency numbers take precendence > over the home dialling plan, if a clash occurs. > (Note: your home provider may provide you with an > escape code to override this, but then you definitely know > what you are doing - e.g. to reach 911xxx local numbers in UK > if you happen to be in the US.) > Note: this may cause some emergency calls done wrong, > but this is preferrable to missroute some real emergency calls > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. 117 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 01 13:58:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4NBo-0005p1-1H; Wed, 01 Feb 2006 13:58:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4NBm-0005mH-0g for ecrit@megatron.ietf.org; Wed, 01 Feb 2006 13:58:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22481 for ; Wed, 1 Feb 2006 13:57:09 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4NMz-00005q-BS for ecrit@ietf.org; Wed, 01 Feb 2006 14:10:22 -0500 Received: (qmail invoked by alias); 01 Feb 2006 18:58:34 -0000 Received: from 134.94.11.192.in-addr.arpa (EHLO [192.168.1.101]) [192.11.94.134] by mail.gmx.net (mp029) with SMTP; 01 Feb 2006 19:58:34 +0100 X-Authenticated: #29516787 Message-ID: <43E104D7.60907@gmx.net> Date: Wed, 01 Feb 2006 19:58:31 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Ecrit] Interim Meeting Slides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all please find the interim meeting slides at: http://www.ietf-ecrit.org/Interim2006/ ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 16:21:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4lt6-0004f6-P4; Thu, 02 Feb 2006 16:21:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4lt4-0004ZN-3Q for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 16:21:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12087 for ; Thu, 2 Feb 2006 16:19:20 -0500 (EST) Received: from mta3.prod1.dngr.net ([216.220.209.222] helo=mfe1.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4m4N-0004Oo-5j for ecrit@ietf.org; Thu, 02 Feb 2006 16:32:48 -0500 Received: from [10.253.10.252] (HELO localhost.localdomain) by mfe1.prod.danger.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 529606641 for ecrit@ietf.org; Thu, 02 Feb 2006 13:16:45 -0800 Date: Thu, 2 Feb 2006 16:16:42 -0500 X-Mailer: Danger Service X-Danger-Send-Id: AAAEsEPidr0AAYax Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" To: ecrit@ietf.org Mime-Version: 1.0 From: Brian Rosen Message-Id: <1138915005.7E0F671@fc4.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Ecrit] Wireline vs wireless routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A subtle problem that may give rise to another requirement is that in some areas a true moble client has different routing than a wireline client. The psap service boundaies are different depending on what you are calling on. It may be that this difference fades over time, but its clearly different in some areas today. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 16:56:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mRb-0003tL-Cc; Thu, 02 Feb 2006 16:56:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mRY-0003sf-Oh for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 16:56:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17946 for ; Thu, 2 Feb 2006 16:54:56 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4mcq-0006nP-1Y for ecrit@ietf.org; Thu, 02 Feb 2006 17:08:25 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 15:56:18 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 02 Feb 2006 15:56:18 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 15:56:17 -0600 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , Date: Thu, 2 Feb 2006 15:56:14 -0600 Subject: RE: [Ecrit] Wireline vs wireless routing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 02 Feb 2006 21:56:17.0529 (UTC) FILETIME=[7E67CE90:01C62843] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Wireline vs wireless routing Thread-Index: AcYoQxHn7P0NCc+ZRSOtRndhp6Jy9wAAD4JA X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This could be a quite hard problem to solve indeed, since there is no indication at all in PIDF-LO as to the access type. The closest thing is the , but it only tells you how location was determined, not the access media. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, 3 February 2006 8:17 AM > To: ecrit@ietf.org > Subject: [Ecrit] Wireline vs wireless routing >=20 > A subtle problem that may give rise to another requirement is that in > some areas a true moble client has different routing than a wireline > client. The psap service boundaies are different depending on what you > are calling on. It may be that this difference fades over time, but its > clearly different in some areas today. >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 16:57:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mS8-00041K-FZ; Thu, 02 Feb 2006 16:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mS7-00040m-7c for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 16:57:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18020 for ; Thu, 2 Feb 2006 16:55:40 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4mdV-0006p6-Rt for ecrit@ietf.org; Thu, 02 Feb 2006 17:09:09 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 15:57:05 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 02 Feb 2006 15:57:05 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 15:57:04 -0600 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , Date: Thu, 2 Feb 2006 15:57:02 -0600 Subject: RE: [Ecrit] Wireline vs wireless routing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 02 Feb 2006 21:57:04.0451 (UTC) FILETIME=[9A5F8930:01C62843] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Wireline vs wireless routing Thread-Index: AcYoQxHn7P0NCc+ZRSOtRndhp6Jy9wAAG4tQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ooopss... I meant to add whether this was a 5% outlying problem, or a significant proportion of jurisdictions? > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, 3 February 2006 8:17 AM > To: ecrit@ietf.org > Subject: [Ecrit] Wireline vs wireless routing >=20 > A subtle problem that may give rise to another requirement is that in > some areas a true moble client has different routing than a wireline > client. The psap service boundaies are different depending on what you > are calling on. It may be that this difference fades over time, but its > clearly different in some areas today. >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 18:28:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ns5-0006OM-18; Thu, 02 Feb 2006 18:28:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ns1-0006LT-ED for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 18:28:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26274 for ; Thu, 2 Feb 2006 18:26:20 -0500 (EST) Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4o3J-0002Em-73 for ecrit@ietf.org; Thu, 02 Feb 2006 18:39:50 -0500 Received: from Youra9279112e3 ([71.251.76.224]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IU300KSO2I3CN21@vms042.mailsrvcs.net> for ecrit@ietf.org; Thu, 02 Feb 2006 17:27:56 -0600 (CST) Date: Thu, 02 Feb 2006 18:27:35 -0500 From: "Delaine M Arnold ENP" Subject: RE: [Ecrit] Wireline vs wireless routing In-reply-to: To: "'Winterbottom, James'" , "'Brian Rosen'" , Message-id: <00fc01c62850$481e0720$0501a8c0@Youra9279112e3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcYoQxHn7P0NCc+ZRSOtRndhp6Jy9wAAG4tQAAL3SEA= X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dmarnold@verizon.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I've heard some numbers from various PSAPs indicating their wireless call volume continues to increase and is more than their wireline volume. I've heard 45-50% wireless in some areas. Many PSAPs have separate trunks for wireline and wireless. This is not a small problem. Delaine M. Arnold, ENP Independent Consultant Chair, NENA Data Technical Committee Voice: 813-960-1698 Fax: 309-412-7821 Email: dmarnold@verizon.net "The finish line is just the beginning." -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Thursday, February 02, 2006 4:57 PM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Wireline vs wireless routing Ooopss... I meant to add whether this was a 5% outlying problem, or a significant proportion of jurisdictions? > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, 3 February 2006 8:17 AM > To: ecrit@ietf.org > Subject: [Ecrit] Wireline vs wireless routing > > A subtle problem that may give rise to another requirement is that in > some areas a true moble client has different routing than a wireline > client. The psap service boundaies are different depending on what you > are calling on. It may be that this difference fades over time, but its > clearly different in some areas today. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 18:41:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4o4g-0002ke-Dh; Thu, 02 Feb 2006 18:41:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4o4e-0002gl-8H for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 18:41:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27176 for ; Thu, 2 Feb 2006 18:39:28 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4oG2-0002gp-K5 for ecrit@ietf.org; Thu, 02 Feb 2006 18:52:58 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 17:40:58 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 02 Feb 2006 17:40:57 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 17:40:56 -0600 Message-ID: From: "Winterbottom, James" To: , "Brian Rosen" , Date: Thu, 2 Feb 2006 17:40:54 -0600 Subject: RE: [Ecrit] Wireline vs wireless routing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 02 Feb 2006 23:40:56.0508 (UTC) FILETIME=[1CF7F7C0:01C62852] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Wireline vs wireless routing Thread-Index: AcYoQxHn7P0NCc+ZRSOtRndhp6Jy9wAAG4tQAAL3SEAAAI//8A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Delaine, Maybe I have misunderstood the problem. Calling volume from different service types is interesting, and certainly I have heard the 50% of 911 calls originate from mobile (good reason for locationURI being the default). The other concern I think Brian was raising is whether how you call, from a mobile or a standard phone, would result in different responders coming to you even if the locations reported were the same. Cheers James > -----Original Message----- > From: Delaine M Arnold ENP [mailto:dmarnold@verizon.net] > Sent: Friday, 3 February 2006 10:28 AM > To: Winterbottom, James; 'Brian Rosen'; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing >=20 > I've heard some numbers from various PSAPs indicating their wireless call > volume continues to increase and is more than their wireline volume. I've > heard 45-50% wireless in some areas. Many PSAPs have separate trunks for > wireline and wireless. This is not a small problem. >=20 > Delaine M. Arnold, ENP > Independent Consultant > Chair, NENA Data Technical Committee > Voice: 813-960-1698 > Fax: 309-412-7821 > Email: dmarnold@verizon.net >=20 > "The finish line is just the beginning." > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Thursday, February 02, 2006 4:57 PM > To: Brian Rosen; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing >=20 > Ooopss... I meant to add whether this was a 5% outlying problem, or a > significant proportion of jurisdictions? >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Brian Rosen > > Sent: Friday, 3 February 2006 8:17 AM > > To: ecrit@ietf.org > > Subject: [Ecrit] Wireline vs wireless routing > > > > A subtle problem that may give rise to another requirement is that in > > some areas a true moble client has different routing than a wireline > > client. The psap service boundaies are different depending on what > you > > are calling on. It may be that this difference fades over time, but > its > > clearly different in some areas today. > > > > Brian > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 20:42:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pyN-0005na-0j; Thu, 02 Feb 2006 20:42:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pyL-0005mP-97 for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 20:42:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09319 for ; Thu, 2 Feb 2006 20:41:11 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4q9p-00085l-AX for ecrit@ietf.org; Thu, 02 Feb 2006 20:54:41 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2006 17:42:40 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k131gdKT016600; Thu, 2 Feb 2006 17:42:39 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 17:42:39 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 17:42:35 -0800 From: "Marc Linsner" To: "'Brian Rosen'" , Subject: RE: [Ecrit] Wireline vs wireless routing Date: Thu, 2 Feb 2006 20:42:13 -0500 Message-ID: <006701c62863$1b651300$d0791e44@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1138915005.7E0F671@fc4.dngr.org> Thread-Index: AcYoQxXIdGICmt5KQGWdkihEX4iiMwAHyUHA X-OriginalArrivalTime: 03 Feb 2006 01:42:38.0851 (UTC) FILETIME=[1D811530:01C62863] X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Is this a symptom of wireless or a desired mechanism? 1) I'm aware that using cell tower routing results in X% of calls going to a neighboring PSAP. 2) I'm also aware that some PSAPs still do not receive wireless calls, they are routed to local/state police. Is this issue different than either #1 or #2 ? Thanks, -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Thursday, February 02, 2006 4:17 PM > To: ecrit@ietf.org > Subject: [Ecrit] Wireline vs wireless routing > > A subtle problem that may give rise to another requirement is > that in some areas a true moble client has different routing > than a wireline client. The psap service boundaies are > different depending on what you are calling on. It may be > that this difference fades over time, but its clearly > different in some areas today. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 20:42:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pyR-0005oh-95; Thu, 02 Feb 2006 20:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pyK-0005gS-FH for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 20:42:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09305 for ; Thu, 2 Feb 2006 20:41:06 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4q9h-00085e-N8 for ecrit@ietf.org; Thu, 02 Feb 2006 20:54:36 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2006 17:42:32 -0800 X-IronPort-AV: i="4.02,81,1139212800"; d="scan'208"; a="400115080:sNHT33162040" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k131gVKT016456; Thu, 2 Feb 2006 17:42:31 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 17:42:31 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 17:42:24 -0800 From: "Marc Linsner" To: "'Winterbottom, James'" , , "'Brian Rosen'" , Subject: RE: [Ecrit] Wireline vs wireless routing Date: Thu, 2 Feb 2006 20:42:13 -0500 Message-ID: <006601c62863$16947820$d0791e44@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcYoQxHn7P0NCc+ZRSOtRndhp6Jy9wAAG4tQAAL3SEAAAI//8AAETGKQ X-OriginalArrivalTime: 03 Feb 2006 01:42:31.0319 (UTC) FILETIME=[1903CA70:01C62863] X-Spam-Score: 1.1 (+) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Inline... > > Maybe I have misunderstood the problem. > Calling volume from different service types is interesting, > and certainly I have heard the 50% of 911 calls originate > from mobile (good reason for locationURI being the default). > The other concern I think Brian was raising is whether how > you call, from a mobile or a standard phone, would result in > different responders coming to you even if the locations > reported were the same. Different responders? Dispatched by the same PSAP? -Marc- > > Cheers > James > > > -----Original Message----- > > From: Delaine M Arnold ENP [mailto:dmarnold@verizon.net] > > Sent: Friday, 3 February 2006 10:28 AM > > To: Winterbottom, James; 'Brian Rosen'; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > I've heard some numbers from various PSAPs indicating their wireless > call > > volume continues to increase and is more than their wireline volume. > I've > > heard 45-50% wireless in some areas. Many PSAPs have > separate trunks > for > > wireline and wireless. This is not a small problem. > > > > Delaine M. Arnold, ENP > > Independent Consultant > > Chair, NENA Data Technical Committee > > Voice: 813-960-1698 > > Fax: 309-412-7821 > > Email: dmarnold@verizon.net > > > > "The finish line is just the beginning." > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Winterbottom, James > > Sent: Thursday, February 02, 2006 4:57 PM > > To: Brian Rosen; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > Ooopss... I meant to add whether this was a 5% outlying > problem, or a > > significant proportion of jurisdictions? > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of > > > Brian Rosen > > > Sent: Friday, 3 February 2006 8:17 AM > > > To: ecrit@ietf.org > > > Subject: [Ecrit] Wireline vs wireless routing > > > > > > A subtle problem that may give rise to another requirement is that > in > > > some areas a true moble client has different routing than > a wireline > > > client. The psap service boundaies are different > depending on what > > you > > > are calling on. It may be that this difference fades > over time, but > > its > > > clearly different in some areas today. > > > > > > Brian > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > -------------------------------------------------------------- > ---------- > -- > > -- > > -------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > > -------------------------------------------------------------- > ---------- > -- > > -- > > -------------------- > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 20:50:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4q5l-0007Ms-4Q; Thu, 02 Feb 2006 20:50:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4q5j-0007Lp-7x for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 20:50:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09716 for ; Thu, 2 Feb 2006 20:48:41 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4qH4-0008Jn-KA for ecrit@ietf.org; Thu, 02 Feb 2006 21:02:11 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k131mkJ0011475 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 2 Feb 2006 20:48:47 -0500 (EST) In-Reply-To: <006701c62863$1b651300$d0791e44@amer.cisco.com> References: <006701c62863$1b651300$d0791e44@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <369D2959-65B6-4080-BFEB-BFD223853253@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Wireline vs wireless routing Date: Thu, 2 Feb 2006 20:48:41 -0500 To: "Marc Linsner" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I know that in LA, wireless calls go to the CHP, since the LA PSAP (used to, last summer) have no mapping/GIS capability. From my understanding when I asked the question during the tour, that was considered a bug, not a feature. I'm having a hard time believing that somebody would upgrade a PSAP to ECRIT/I3 and then not install a geo-capable system, but maybe there are more subtle reasons. On Feb 2, 2006, at 8:42 PM, Marc Linsner wrote: > Is this a symptom of wireless or a desired mechanism? > > 1) I'm aware that using cell tower routing results in X% of calls > going to a > neighboring PSAP. > > 2) I'm also aware that some PSAPs still do not receive wireless > calls, they > are routed to local/state police. > > Is this issue different than either #1 or #2 ? > > Thanks, > > -Marc- > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Brian Rosen >> Sent: Thursday, February 02, 2006 4:17 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] Wireline vs wireless routing >> >> A subtle problem that may give rise to another requirement is >> that in some areas a true moble client has different routing >> than a wireline client. The psap service boundaies are >> different depending on what you are calling on. It may be >> that this difference fades over time, but its clearly >> different in some areas today. >> >> Brian >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 02 21:54:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4r5H-0001wn-52; Thu, 02 Feb 2006 21:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4r5D-0001uQ-PA for ecrit@megatron.ietf.org; Thu, 02 Feb 2006 21:54:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13407 for ; Thu, 2 Feb 2006 21:52:17 -0500 (EST) From: br@brianrosen.net Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4rGd-0001jS-EX for ecrit@ietf.org; Thu, 02 Feb 2006 22:05:47 -0500 Received: from brtech by dx28.winwebhosting.com with local (Exim 4.52) id 1F4r4t-0000PE-5a; Thu, 02 Feb 2006 20:53:39 -0600 Received: from 209.173.53.233 ([209.173.53.233]) (SquirrelMail authenticated user br@brianrosen.net) by www.brianrosen.net with HTTP; Thu, 2 Feb 2006 20:53:39 -0600 (CST) Message-ID: <54185.209.173.53.233.1138935219.squirrel@www.brianrosen.net> In-Reply-To: References: Date: Thu, 2 Feb 2006 20:53:39 -0600 (CST) Subject: RE: [Ecrit] Wireline vs wireless routing To: "Winterbottom, James" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32207 32002] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 8bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Just to be clear: different PSAP answers call, in the end, same responders, often by transferring call from the first PSAP to the "right" PSAP. > Hi Delaine, > > Maybe I have misunderstood the problem. > Calling volume from different service types is interesting, and > certainly I have heard the 50% of 911 calls originate from mobile (good > reason for locationURI being the default). The other concern I think > Brian was raising is whether how you call, from a mobile or a standard > phone, would result in different responders coming to you even if the > locations reported were the same. > > Cheers > James > >> -----Original Message----- >> From: Delaine M Arnold ENP [mailto:dmarnold@verizon.net] >> Sent: Friday, 3 February 2006 10:28 AM >> To: Winterbottom, James; 'Brian Rosen'; ecrit@ietf.org >> Subject: RE: [Ecrit] Wireline vs wireless routing >> >> I've heard some numbers from various PSAPs indicating their wireless > call >> volume continues to increase and is more than their wireline volume. > I've >> heard 45-50% wireless in some areas. Many PSAPs have separate trunks > for >> wireline and wireless. This is not a small problem. >> >> Delaine M. Arnold, ENP >> Independent Consultant >> Chair, NENA Data Technical Committee >> Voice: 813-960-1698 >> Fax: 309-412-7821 >> Email: dmarnold@verizon.net >> >> "The finish line is just the beginning." >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of >> Winterbottom, James >> Sent: Thursday, February 02, 2006 4:57 PM >> To: Brian Rosen; ecrit@ietf.org >> Subject: RE: [Ecrit] Wireline vs wireless routing >> >> Ooopss... I meant to add whether this was a 5% outlying problem, or a >> significant proportion of jurisdictions? >> >> > -----Original Message----- >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf >> Of >> > Brian Rosen >> > Sent: Friday, 3 February 2006 8:17 AM >> > To: ecrit@ietf.org >> > Subject: [Ecrit] Wireline vs wireless routing >> > >> > A subtle problem that may give rise to another requirement is that > in >> > some areas a true moble client has different routing than a wireline >> > client. The psap service boundaies are different depending on what >> you >> > are calling on. It may be that this difference fades over time, but >> its >> > clearly different in some areas today. >> > >> > Brian >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit >> >> > ------------------------------------------------------------------------ > -- >> -- >> -------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> > ------------------------------------------------------------------------ > -- >> -- >> -------------------- >> [mf2] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 03:48:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4wcW-0001GP-0k; Fri, 03 Feb 2006 03:48:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4wcV-0001EE-0C for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 03:48:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06144 for ; Fri, 3 Feb 2006 03:47:04 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4wo1-0004Me-HY for ecrit@ietf.org; Fri, 03 Feb 2006 04:00:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 09:52:12 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4D09@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Wireline vs wireless routing Thread-Index: AcYoQ7KMcEGlfR3cT6OymHUYXTxMsQAWseDQ From: "Stastny Richard" To: "Brian Rosen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It is true that mobile operators do currently different routing The basic question is: 1. Is thai because they cannot do better, because they calculate >From the cell coverage, which normally does not match the real boundaries - kind of best effort 2. or is this on purpose for some other means? In the first case we do not need to care, because we simply take the location given In the second case we need additional layers for mobile mapping and also an additional parameter. IMHO the first case is true. Richard > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Thursday, February 02, 2006 10:17 PM > To: ecrit@ietf.org > Subject: [Ecrit] Wireline vs wireless routing >=20 > A subtle problem that may give rise to another requirement is that in > some areas a true moble client has different routing than a wireline > client. The psap service boundaies are different depending on what you > are calling on. It may be that this difference fades over time, but its > clearly different in some areas today. >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 04:17:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4x4G-0003ke-BI; Fri, 03 Feb 2006 04:17:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4x4D-0003h8-8r for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 04:17:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08209 for ; Fri, 3 Feb 2006 04:15:41 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4xFh-0005SS-43 for ecrit@ietf.org; Fri, 03 Feb 2006 04:29:15 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id k139H4Ai007998Fri, 3 Feb 2006 09:17:06 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1F4x3w-0001jR-00; Fri, 03 Feb 2006 09:17:04 +0000 Date: Fri, 3 Feb 2006 09:17:04 +0000 From: "Clive D.W. Feather" To: "Winterbottom, James" Subject: Re: [Ecrit] Wireline vs wireless routing Message-ID: <20060203091703.GB4177@finch-staff-1.thus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Winterbottom, James said: > Calling volume from different service types is interesting, and > certainly I have heard the 50% of 911 calls originate from mobile (good > reason for locationURI being the default). The numbers I've heard in the UK are that 50% of emergency (999/112) calls are silent call false alarms from mobiles ("handbag calls"). -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 04:53:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4xd9-0004kU-Ht; Fri, 03 Feb 2006 04:53:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4xd7-0004Zs-1b for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 04:53:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10838 for ; Fri, 3 Feb 2006 04:51:38 -0500 (EST) Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4xoV-0006dA-RL for ecrit@ietf.org; Fri, 03 Feb 2006 05:05:13 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 03:53:03 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 03 Feb 2006 03:53:03 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 03:53:02 -0600 Message-ID: From: "Winterbottom, James" To: "Clive D.W. Feather" Date: Fri, 3 Feb 2006 03:53:00 -0600 Subject: RE: [Ecrit] Wireline vs wireless routing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 03 Feb 2006 09:53:02.0131 (UTC) FILETIME=[9F255030:01C628A7] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] Wireline vs wireless routing Thread-Index: AcYoopxJNCTRFeYeTAuP6zF3xkQvLwABNG3A X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Perhaps, I do not have stats to that effect. I do know that 60% of long distance calls in the US were made from mobiles last year. So what ever way you look at it, mobile is going to be dominant in a very short period of time, and fixed is only a special case of mobile. > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net] > Sent: Friday, 3 February 2006 8:17 PM > To: Winterbottom, James > Cc: dmarnold@verizon.net; Brian Rosen; ecrit@ietf.org > Subject: Re: [Ecrit] Wireline vs wireless routing >=20 > Winterbottom, James said: > > Calling volume from different service types is interesting, and > > certainly I have heard the 50% of 911 calls originate from mobile (good > > reason for locationURI being the default). >=20 > The numbers I've heard in the UK are that 50% of emergency (999/112) calls > are silent call false alarms from mobiles ("handbag calls"). >=20 > -- > Clive D.W. Feather | Work: | Tel: +44 20 8495 > 6138 > Internet Expert | Home: | Fax: +44 870 051 > 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 > Thus plc | | ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 09:29:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51wg-0007s0-6O; Fri, 03 Feb 2006 09:29:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51we-0007qe-C6 for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 09:29:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02870 for ; Fri, 3 Feb 2006 09:28:04 -0500 (EST) Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5282-0003zW-N7 for ecrit@ietf.org; Fri, 03 Feb 2006 09:41:41 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k13ETFs22575 for ; Fri, 3 Feb 2006 09:29:15 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006020309292027576 for ; Fri, 03 Feb 2006 09:29:20 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Feb 2006 09:29:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 09:29:12 -0500 Message-ID: Thread-Topic: [Ecrit] Wireline vs wireless routing Thread-Index: AcYoQxHn7P0NCc+ZRSOtRndhp6Jy9wAAG4tQAAL3SEAAAQiUcAADPiEgABtqf6A= From: "Abbott, Nadine B" To: "ECRIT" X-OriginalArrivalTime: 03 Feb 2006 14:29:20.0602 (UTC) FILETIME=[38AF3BA0:01C628CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Some clarifications -----Original Message----- From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com]=20 Sent: Thursday, February 02, 2006 8:44 PM To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom, James; Brian Rosen Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) Subject: RE: [Ecrit] Wireline vs wireless routing This is just an "application of terminology" problem. Its not that PSAP routing is intentionally different for wireline vs wireless, it has to do with how granular you can get in your routing decisions. The PSAP that dispatches emergency services is the same for both callers, but the PSAP that gets the call initially may be different. NJ is a good example of how this plays out. NJ has 230 PSAPs covering the 21 counties. Many PSAPs serve a single municipality and several counties in NJ have more than 20 PSAPs with no county-level PSAP. Let's say I place a cell tower on the roof of 4 Skiles Ave in Piscataway. The street address for that tower is 4 Skiles Ave which, according to the MSAG, would be routed to the Piscataway PD PSAP. Unfortunately, the cell tower, with a 5 mile serving radius, serves callers in 4 or 5 neighboring towns as well as Piscataway. I need to route calls from this cell to a County or State Police PSAP that is set up to answer from a wider area. To do that, we created the State of XX in the MSAG, so that 4 Skiles Ave, Piscataway, XX could be assigned a different ESN and be routed to a different PSAP. If the caller turns out to be in Piscataway, the call is transferred from the County/State PSAP to Piscataway PD for dispatching. The point is that the wireless caller may be routed to a different PSAP out of necessity, but the call will ultimately end up at the PSAP serving the caller's location. Why not route the call based on the caller's actual location? Because, generally speaking, the location data is not derived or delivered fast enough to be usable for routing. We'd have to place the caller in queue and play cheesy elevator music until the location could be derived, delivered and translated to an ESN. That probably wouldn't be popular. Wireless callers already have to wait longer to reach 9-1-1 than wireline callers simply because wireless calls take longer to set up, particularly if RF channels are not immediately available. Over time, as the technology matures, routing on location will become the norm and the need to route differently will go away. I hope no one considers this type of routing a viable option for VoIP. We did it for wireless because we had to, not because we wanted to. Gojo Robert K. Gojanovich, ENP Director iXP Corporation 609-406-7625 Direct Dial 215-435-0703 Mobile 609-406-7699 Fax rgojo@ixpcorp.com www.ixpcorp.com iXP Corporation... Problem Solved -----Original Message----- From: Abbott, Nadine B [mailto:nabbott@telcordia.com] Sent: Thursday, February 02, 2006 7:31 PM To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT); Gojanovich, Robert Subject: RE: [Ecrit] Wireline vs wireless routing Brian, Perhaps you can clarify with some examples of what you mean about different routing of wireline and wireless callers? I've never heard before that for the very same location, emergency calls routed to a given PSAP would be dispatched differently, with different emergency responders for wireline and wireless.=20 However, I have heard of examples of different routing to different answering points/PSAPs for wireless calls based on access type and location, like the following. In California, wireless calls used to be routed to the Highway Patrol, but this began phasing out several years ago. Likewise, in other states, like NJ, wireless calls were routed to a central PSAP because of the high volumes and the need to handle the traffic slightly differently, at least partly because of location-related concerns. But I believe that these kind of arrangements are being phased out as most areas are at least moving toward implementation of Wireless Phase I and Phase II, and are enabling wireless calls to be appropriately routed to a PSAP based on location. However, wireless calls may be routed based on primary PSAP serving area, because the granularity (down to information that identifies the appropriate emergency resources to be dispatched, i.e., ESZ) may not be available for wireless p-ANIs. =20 =20 As Delaine mentions, there are sometimes different trunk groups to the PSAP also for wireline and wireless, but I think that this is to help the PSAP ensure that volumes and bursts of calls from mobiles won't swamp out emergency service to wireline callers, not because they were routed differently? =20 Nadine P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and Paul Stoffels to this thread because they have a wealth of experience to add to this discussion, I expect.=20 =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Delaine M Arnold ENP Sent: Thursday, February 02, 2006 6:28 PM To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org Subject: RE: [Ecrit] Wireline vs wireless routing I've heard some numbers from various PSAPs indicating their wireless call volume continues to increase and is more than their wireline volume. I've heard 45-50% wireless in some areas. Many PSAPs have separate trunks for wireline and wireless. This is not a small problem. Delaine M. Arnold, ENP Independent Consultant Chair, NENA Data Technical Committee Voice: 813-960-1698 Fax: 309-412-7821 Email: dmarnold@verizon.net =20 "The finish line is just the beginning." -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Thursday, February 02, 2006 4:57 PM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Wireline vs wireless routing Ooopss... I meant to add whether this was a 5% outlying problem, or a significant proportion of jurisdictions? > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, 3 February 2006 8:17 AM > To: ecrit@ietf.org > Subject: [Ecrit] Wireline vs wireless routing >=20 > A subtle problem that may give rise to another requirement is that in=20 > some areas a true moble client has different routing than a wireline=20 > client. The psap service boundaies are different depending on what you > are calling on. It may be that this difference fades over time, but its > clearly different in some areas today. >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ---- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ---- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 10:58:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53KH-0000KF-HL; Fri, 03 Feb 2006 10:58:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53KE-0000Hk-MZ for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 10:58:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13551 for ; Fri, 3 Feb 2006 10:56:33 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F53Vj-0008Ll-4A for ecrit@ietf.org; Fri, 03 Feb 2006 11:10:11 -0500 Received: from nj0117exch001p.wins.lucent.com (h135-5-177-157.lucent.com [135.5.177.157]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k13Fw4R2014706; Fri, 3 Feb 2006 09:58:04 -0600 (CST) Received: by nj0117exch001p.wh.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Feb 2006 10:58:04 -0500 Message-ID: <6CF036121950A44C93F5DB88CF3398D41B4D88EE@nj0117exch001u.wh.lucent.com> From: "Rollender, Douglas Harold (Douglas)" To: "Abbott, Nadine B" , ECRIT Subject: RE: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 10:58:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Follow up questions for Gojo on the NJ scenario - 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? Doug Douglas Rollender Lucent Technologies Wireless Standards Development and Industry Relations TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Abbott, Nadine B Sent: Friday, February 03, 2006 9:29 AM To: ECRIT Subject: FW: [Ecrit] Wireline vs wireless routing Some clarifications -----Original Message----- From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] Sent: Thursday, February 02, 2006 8:44 PM To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom, James; Brian Rosen Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) Subject: RE: [Ecrit] Wireline vs wireless routing This is just an "application of terminology" problem. Its not that PSAP routing is intentionally different for wireline vs wireless, it has to do with how granular you can get in your routing decisions. The PSAP that dispatches emergency services is the same for both callers, but the PSAP that gets the call initially may be different. NJ is a good example of how this plays out. NJ has 230 PSAPs covering the 21 counties. Many PSAPs serve a single municipality and several counties in NJ have more than 20 PSAPs with no county-level PSAP. Let's say I place a cell tower on the roof of 4 Skiles Ave in Piscataway. The street address for that tower is 4 Skiles Ave which, according to the MSAG, would be routed to the Piscataway PD PSAP. Unfortunately, the cell tower, with a 5 mile serving radius, serves callers in 4 or 5 neighboring towns as well as Piscataway. I need to route calls from this cell to a County or State Police PSAP that is set up to answer from a wider area. To do that, we created the State of XX in the MSAG, so that 4 Skiles Ave, Piscataway, XX could be assigned a different ESN and be routed to a different PSAP. If the caller turns out to be in Piscataway, the call is transferred from the County/State PSAP to Piscataway PD for dispatching. The point is that the wireless caller may be routed to a different PSAP out of necessity, but the call will ultimately end up at the PSAP serving the caller's location. Why not route the call based on the caller's actual location? Because, generally speaking, the location data is not derived or delivered fast enough to be usable for routing. We'd have to place the caller in queue and play cheesy elevator music until the location could be derived, delivered and translated to an ESN. That probably wouldn't be popular. Wireless callers already have to wait longer to reach 9-1-1 than wireline callers simply because wireless calls take longer to set up, particularly if RF channels are not immediately available. Over time, as the technology matures, routing on location will become the norm and the need to route differently will go away. I hope no one considers this type of routing a viable option for VoIP. We did it for wireless because we had to, not because we wanted to. Gojo Robert K. Gojanovich, ENP Director iXP Corporation 609-406-7625 Direct Dial 215-435-0703 Mobile 609-406-7699 Fax rgojo@ixpcorp.com www.ixpcorp.com iXP Corporation... Problem Solved -----Original Message----- From: Abbott, Nadine B [mailto:nabbott@telcordia.com] Sent: Thursday, February 02, 2006 7:31 PM To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT); Gojanovich, Robert Subject: RE: [Ecrit] Wireline vs wireless routing Brian, Perhaps you can clarify with some examples of what you mean about different routing of wireline and wireless callers? I've never heard before that for the very same location, emergency calls routed to a given PSAP would be dispatched differently, with different emergency responders for wireline and wireless. However, I have heard of examples of different routing to different answering points/PSAPs for wireless calls based on access type and location, like the following. In California, wireless calls used to be routed to the Highway Patrol, but this began phasing out several years ago. Likewise, in other states, like NJ, wireless calls were routed to a central PSAP because of the high volumes and the need to handle the traffic slightly differently, at least partly because of location-related concerns. But I believe that these kind of arrangements are being phased out as most areas are at least moving toward implementation of Wireless Phase I and Phase II, and are enabling wireless calls to be appropriately routed to a PSAP based on location. However, wireless calls may be routed based on primary PSAP serving area, because the granularity (down to information that identifies the appropriate emergency resources to be dispatched, i.e., ESZ) may not be available for wireless p-ANIs. As Delaine mentions, there are sometimes different trunk groups to the PSAP also for wireline and wireless, but I think that this is to help the PSAP ensure that volumes and bursts of calls from mobiles won't swamp out emergency service to wireline callers, not because they were routed differently? Nadine P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and Paul Stoffels to this thread because they have a wealth of experience to add to this discussion, I expect. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Delaine M Arnold ENP Sent: Thursday, February 02, 2006 6:28 PM To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org Subject: RE: [Ecrit] Wireline vs wireless routing I've heard some numbers from various PSAPs indicating their wireless call volume continues to increase and is more than their wireline volume. I've heard 45-50% wireless in some areas. Many PSAPs have separate trunks for wireline and wireless. This is not a small problem. Delaine M. Arnold, ENP Independent Consultant Chair, NENA Data Technical Committee Voice: 813-960-1698 Fax: 309-412-7821 Email: dmarnold@verizon.net "The finish line is just the beginning." -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Thursday, February 02, 2006 4:57 PM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Wireline vs wireless routing Ooopss... I meant to add whether this was a 5% outlying problem, or a significant proportion of jurisdictions? > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, 3 February 2006 8:17 AM > To: ecrit@ietf.org > Subject: [Ecrit] Wireline vs wireless routing > > A subtle problem that may give rise to another requirement is that in > some areas a true moble client has different routing than a wireline > client. The psap service boundaies are different depending on what you > are calling on. It may be that this difference fades over time, but its > clearly different in some areas today. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ---- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ---- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 15:16:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57Li-000755-Na; Fri, 03 Feb 2006 15:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57Lb-00073Y-0Y for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 15:16:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06407 for ; Fri, 3 Feb 2006 15:14:11 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F57X4-0002d5-7V for ecrit@ietf.org; Fri, 03 Feb 2006 15:27:51 -0500 Received: from nj0117exch001p.wins.lucent.com (h135-5-177-157.lucent.com [135.5.177.157]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k13KFcp8002196; Fri, 3 Feb 2006 14:15:38 -0600 (CST) Received: by nj0117exch001p.wh.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Feb 2006 15:15:38 -0500 Message-ID: <6CF036121950A44C93F5DB88CF3398D41B4D8B53@nj0117exch001u.wh.lucent.com> From: "Rollender, Douglas Harold (Douglas)" To: "Rollender, Douglas Harold (Douglas)" , "Abbott, Nadine B" , ECRIT Subject: RE: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 15:15:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C628FE.98665D8C" X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: RGojo@iXPCorp.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C628FE.98665D8C Content-Type: text/plain Reply to follow-up questions from Gojo attached. Gojo, Thanks for further clarification on difference in routing between wireless and wireline. Not sure how ECRIT may use the information except we can anticipate needing to support the same routing scenarios for voice and data and the same location functions and performance characteristics in future access networks. Doug Douglas Rollender Lucent Technologies Wireless Standards Development and Industry Relations TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Rollender, Douglas Harold (Douglas) Sent: Friday, February 03, 2006 10:58 AM To: Abbott, Nadine B; ECRIT Subject: RE: [Ecrit] Wireline vs wireless routing Follow up questions for Gojo on the NJ scenario - 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? Doug Douglas Rollender Lucent Technologies Wireless Standards Development and Industry Relations TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Abbott, Nadine B Sent: Friday, February 03, 2006 9:29 AM To: ECRIT Subject: FW: [Ecrit] Wireline vs wireless routing Some clarifications -----Original Message----- From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] Sent: Thursday, February 02, 2006 8:44 PM To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom, James; Brian Rosen Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) Subject: RE: [Ecrit] Wireline vs wireless routing This is just an "application of terminology" problem. Its not that PSAP routing is intentionally different for wireline vs wireless, it has to do with how granular you can get in your routing decisions. The PSAP that dispatches emergency services is the same for both callers, but the PSAP that gets the call initially may be different. NJ is a good example of how this plays out. NJ has 230 PSAPs covering the 21 counties. Many PSAPs serve a single municipality and several counties in NJ have more than 20 PSAPs with no county-level PSAP. Let's say I place a cell tower on the roof of 4 Skiles Ave in Piscataway. The street address for that tower is 4 Skiles Ave which, according to the MSAG, would be routed to the Piscataway PD PSAP. Unfortunately, the cell tower, with a 5 mile serving radius, serves callers in 4 or 5 neighboring towns as well as Piscataway. I need to route calls from this cell to a County or State Police PSAP that is set up to answer from a wider area. To do that, we created the State of XX in the MSAG, so that 4 Skiles Ave, Piscataway, XX could be assigned a different ESN and be routed to a different PSAP. If the caller turns out to be in Piscataway, the call is transferred from the County/State PSAP to Piscataway PD for dispatching. The point is that the wireless caller may be routed to a different PSAP out of necessity, but the call will ultimately end up at the PSAP serving the caller's location. Why not route the call based on the caller's actual location? Because, generally speaking, the location data is not derived or delivered fast enough to be usable for routing. We'd have to place the caller in queue and play cheesy elevator music until the location could be derived, delivered and translated to an ESN. That probably wouldn't be popular. Wireless callers already have to wait longer to reach 9-1-1 than wireline callers simply because wireless calls take longer to set up, particularly if RF channels are not immediately available. Over time, as the technology matures, routing on location will become the norm and the need to route differently will go away. I hope no one considers this type of routing a viable option for VoIP. We did it for wireless because we had to, not because we wanted to. Gojo Robert K. Gojanovich, ENP Director iXP Corporation 609-406-7625 Direct Dial 215-435-0703 Mobile 609-406-7699 Fax rgojo@ixpcorp.com www.ixpcorp.com iXP Corporation... Problem Solved -----Original Message----- From: Abbott, Nadine B [mailto:nabbott@telcordia.com] Sent: Thursday, February 02, 2006 7:31 PM To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT); Gojanovich, Robert Subject: RE: [Ecrit] Wireline vs wireless routing Brian, Perhaps you can clarify with some examples of what you mean about different routing of wireline and wireless callers? I've never heard before that for the very same location, emergency calls routed to a given PSAP would be dispatched differently, with different emergency responders for wireline and wireless. However, I have heard of examples of different routing to different answering points/PSAPs for wireless calls based on access type and location, like the following. In California, wireless calls used to be routed to the Highway Patrol, but this began phasing out several years ago. Likewise, in other states, like NJ, wireless calls were routed to a central PSAP because of the high volumes and the need to handle the traffic slightly differently, at least partly because of location-related concerns. But I believe that these kind of arrangements are being phased out as most areas are at least moving toward implementation of Wireless Phase I and Phase II, and are enabling wireless calls to be appropriately routed to a PSAP based on location. However, wireless calls may be routed based on primary PSAP serving area, because the granularity (down to information that identifies the appropriate emergency resources to be dispatched, i.e., ESZ) may not be available for wireless p-ANIs. As Delaine mentions, there are sometimes different trunk groups to the PSAP also for wireline and wireless, but I think that this is to help the PSAP ensure that volumes and bursts of calls from mobiles won't swamp out emergency service to wireline callers, not because they were routed differently? Nadine P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and Paul Stoffels to this thread because they have a wealth of experience to add to this discussion, I expect. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Delaine M Arnold ENP Sent: Thursday, February 02, 2006 6:28 PM To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org Subject: RE: [Ecrit] Wireline vs wireless routing I've heard some numbers from various PSAPs indicating their wireless call volume continues to increase and is more than their wireline volume. I've heard 45-50% wireless in some areas. Many PSAPs have separate trunks for wireline and wireless. This is not a small problem. Delaine M. Arnold, ENP Independent Consultant Chair, NENA Data Technical Committee Voice: 813-960-1698 Fax: 309-412-7821 Email: dmarnold@verizon.net "The finish line is just the beginning." -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Thursday, February 02, 2006 4:57 PM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Wireline vs wireless routing Ooopss... I meant to add whether this was a 5% outlying problem, or a significant proportion of jurisdictions? > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, 3 February 2006 8:17 AM > To: ecrit@ietf.org > Subject: [Ecrit] Wireline vs wireless routing > > A subtle problem that may give rise to another requirement is that in > some areas a true moble client has different routing than a wireline > client. The psap service boundaies are different depending on what you > are calling on. It may be that this difference fades over time, but its > clearly different in some areas today. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ---- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ---- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_000_01C628FE.98665D8C Content-Type: message/rfc822 Content-Description: NJ Questions Message-ID: <769F4DDF781FA641A3D06A0872E27271013FE05C@lawexch01.ixpcorp.com> From: "Gojanovich, Robert" To: "Rollender, Douglas Harold (Douglas)" Cc: "Abbott, Nadine B" Subject: NJ Questions Date: Fri, 3 Feb 2006 13:46:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 X-MS-Has-Attach: Thread-Topic: NJ Questions Content-Class: urn:content-classes:message thread-index: AcYo8lfgWKfKzMnJTRW8uvIuqINw/g== Content-Type: text/plain Doug, Nadine forwarded me your questions (I am not on the ecrit list server). Answers below. Follow up questions for Gojo on the NJ scenario - 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? Gojo: It doesn't. Until the call is answered and the location arrives or is provided by the caller, no one knows where the call came from. 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? Gojo: You have no caller location until after the call is answered. This is the legacy of NCAS thinking. The original design in J-Std-036 called for the location information to be sent as a TCAP message over SS7 as part of the call setup. Three things, unfortunately, were missing: 1) ALI databases are not SCPs and are not on the SS7 network, 2) most 9-1-1 networks did not support SS7 at the time, and 3) The location technology can't derive location that fast. In wireline compatibility mode deployments, it is possible for the MPC to receive some locations fast enough to affect! (ESRK selection) routing (at least, that is what they claim), but NJ implemented CAS for Phase 1 and NCAS (J-std terminology, formerly called HCAS) for Phase 2. The NJ system does have the potential to route on location. The architecture includes a data link between the SR and the ALI. When a wireless call hits the SR, a message containing the ESRD and CBN is sent to the ALI. The ALI immediately launches a query to the MPC. It was designed so that when the coordinate routing feature was implemented, the SR would wait 2-3 seconds before completing the call to the PSAP. In that time, the ESME would query the MPC, acquire the coordinates and translate to the precise ESN. The ESN would be sent to the SR to be used for routing. If the ALI did not respond in 2-3 seconds, say, the SR would go ahead and route the call based on the ESRD (cell sector). Since the PDEs can't deliver fast enough on a consistent basis, the State hasn't yet bought the feature. You have two choices: Route the call to the County/State or route the call to the municipality where the cell is located. Either way will result in some number of transfers. The municipal PSAPs, for the most part, are too small to deal with a high volume of calls from outside their jurisdiction and don't want calls unless they belong to them. Unless it can be determined with some certainty that the caller is within their jurisdiction, they will refuse to answer the calls. This forces the call to the next wrung on the ladder, be it County or State. It is no more unsafe to send the call to the County for them to screen and transfer to the appropriate PSAP, than it is to send the call to the municipal PSAP where it still has to be screened and, in many cases, transferred. Sending all calls to the County provides for consistency and some predictability. It also allows the County to screen out redundant and non-emergency calls that the local PSAPs are too small to handle in many, many cases. 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? Gojo: The data delivered through the ESME will follow the call, sort of, and will often be updated. The PSAP that receives the transfer does not get ALI data from the first PSAP, it does its own dip to the ALI database using the ESRK, ESRD or CBN. This dip will generate a new position request to the MPC, so the location data received at the second PSAP may be different than that received by the first PSAP. The Phase 1 data will be the same but the lat/long may be different. Ancillary information acquired from the caller is usually given to the second PSAP verbally. Very few PSAPs have links between CAD systems to do that automatically. Most of that data flow is verbal. Gojo Robert K. Gojanovich, ENP Director iXP Corporation 609-406-7625 Direct Dial 215-435-0703 Mobile 609-406-7699 Fax rgojo@ixpcorp.com www.ixpcorp.com iXP Corporation... Problem Solved ------_=_NextPart_000_01C628FE.98665D8C Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_000_01C628FE.98665D8C-- From ecrit-bounces@ietf.org Fri Feb 03 16:19:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58LV-00070a-UJ; Fri, 03 Feb 2006 16:19:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57sa-0005Qa-KV; Fri, 03 Feb 2006 15:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09142; Fri, 3 Feb 2006 15:48:26 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F584D-0004CS-5L; Fri, 03 Feb 2006 16:02:05 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F57sX-0006UY-Vp; Fri, 03 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 03 Feb 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Fri, 03 Feb 2006 16:19:55 -0500 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-03.txt Pages : 30 Date : 2006-2-3 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-3130404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-3130404.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Fri Feb 03 16:57:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58vk-0001au-DE; Fri, 03 Feb 2006 16:57:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58vh-0001WP-0c for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 16:57:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18913 for ; Fri, 3 Feb 2006 16:55:42 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F597L-00008f-I0 for ecrit@ietf.org; Fri, 03 Feb 2006 17:09:24 -0500 Received: from lion.cs.columbia.edu (IDENT:I3qqffi+0dgzvJXkSbapqvEOUEWjymH7@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k13Lv76j018366 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 3 Feb 2006 16:57:11 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k13Lv2nE020668 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Feb 2006 16:57:07 -0500 Message-ID: <43E3D1A9.7050009@cs.columbia.edu> Date: Fri, 03 Feb 2006 16:56:57 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Rollender, Douglas Harold (Douglas)" Subject: Re: [Ecrit] Wireline vs wireless routing References: <6CF036121950A44C93F5DB88CF3398D41B4D8B53@nj0117exch001u.wh.lucent.com> In-Reply-To: <6CF036121950A44C93F5DB88CF3398D41B4D8B53@nj0117exch001u.wh.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Content-Transfer-Encoding: 7bit Cc: RGojo@iXPCorp.com, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The conclusion, however, seems to be that routing is, in all cases, based on currently-available location information, just that a wireless call may end up in the wrong place initially due to the limitations of that initial location fix. This seems to indicate that no new mechanisms in the mapping protocol are required. Rollender, Douglas Harold (Douglas) wrote: > Reply to follow-up questions from Gojo attached. > > Gojo, > > Thanks for further clarification on difference in routing between wireless and wireline. Not sure how ECRIT may use the information except we can anticipate needing to support the same routing scenarios for voice and data and the same location functions and performance characteristics in future access networks. > > Doug > > Douglas Rollender > Lucent Technologies > Wireless Standards Development and Industry Relations > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > Rollender, Douglas Harold (Douglas) > Sent: Friday, February 03, 2006 10:58 AM > To: Abbott, Nadine B; ECRIT > Subject: RE: [Ecrit] Wireline vs wireless routing > > > Follow up questions for Gojo on the NJ scenario - > > 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? > > 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? > > 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? > > Doug > > Douglas Rollender > Lucent Technologies > Wireless Standards Development and Industry Relations > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > Abbott, Nadine B > Sent: Friday, February 03, 2006 9:29 AM > To: ECRIT > Subject: FW: [Ecrit] Wireline vs wireless routing > > > Some clarifications > > -----Original Message----- > From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] > Sent: Thursday, February 02, 2006 8:44 PM > To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom, James; Brian > Rosen > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) > Subject: RE: [Ecrit] Wireline vs wireless routing > > This is just an "application of terminology" problem. > > Its not that PSAP routing is intentionally different for wireline vs > wireless, it has to do with how granular you can get in your routing > decisions. The PSAP that dispatches emergency services is the same for > both callers, but the PSAP that gets the call initially may be > different. > > NJ is a good example of how this plays out. NJ has 230 PSAPs covering > the 21 counties. Many PSAPs serve a single municipality and several > counties in NJ have more than 20 PSAPs with no county-level PSAP. Let's > say I place a cell tower on the roof of 4 Skiles Ave in Piscataway. The > street address for that tower is 4 Skiles Ave which, according to the > MSAG, would be routed to the Piscataway PD PSAP. Unfortunately, the cell > tower, with a 5 mile serving radius, serves callers in 4 or 5 > neighboring towns as well as Piscataway. > > I need to route calls from this cell to a County or State Police PSAP > that is set up to answer from a wider area. To do that, we created the > State of XX in the MSAG, so that 4 Skiles Ave, Piscataway, XX could be > assigned a different ESN and be routed to a different PSAP. > > If the caller turns out to be in Piscataway, the call is transferred > from the County/State PSAP to Piscataway PD for dispatching. The point > is that the wireless caller may be routed to a different PSAP out of > necessity, but the call will ultimately end up at the PSAP serving the > caller's location. > > Why not route the call based on the caller's actual location? Because, > generally speaking, the location data is not derived or delivered fast > enough to be usable for routing. We'd have to place the caller in queue > and play cheesy elevator music until the location could be derived, > delivered and translated to an ESN. That probably wouldn't be popular. > Wireless callers already have to wait longer to reach 9-1-1 than > wireline callers simply because wireless calls take longer to set up, > particularly if RF channels are not immediately available. Over time, as > the technology matures, routing on location will become the norm and the > need to route differently will go away. > > I hope no one considers this type of routing a viable option for VoIP. > We did it for wireless because we had to, not because we wanted to. > > Gojo > > Robert K. Gojanovich, ENP > Director > iXP Corporation > 609-406-7625 Direct Dial > 215-435-0703 Mobile > 609-406-7699 Fax > rgojo@ixpcorp.com > www.ixpcorp.com > iXP Corporation... Problem Solved > > -----Original Message----- > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > Sent: Thursday, February 02, 2006 7:31 PM > To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT); > Gojanovich, Robert > Subject: RE: [Ecrit] Wireline vs wireless routing > > Brian, > > Perhaps you can clarify with some examples of what you mean about > different routing of wireline and wireless callers? I've never heard > before that for the very same location, emergency calls routed to a > given PSAP would be dispatched differently, with different emergency > responders for wireline and wireless. > > However, I have heard of examples of different routing to different > answering points/PSAPs for wireless calls based on access type and > location, like the following. > In California, wireless calls used to be routed to the Highway Patrol, > but this began phasing out several years ago. Likewise, in other > states, like NJ, wireless calls were routed to a central PSAP because of > the high volumes and the need to handle the traffic slightly > differently, at least partly because of location-related concerns. But I > believe that these kind of arrangements are being phased out as most > areas are at least moving toward implementation of Wireless Phase I and > Phase II, and are enabling wireless calls to be appropriately routed to > a PSAP based on location. However, wireless calls may be routed based > on primary PSAP serving area, because the granularity (down to > information that identifies the appropriate emergency resources to be > dispatched, i.e., ESZ) may not be available for wireless p-ANIs. > > As Delaine mentions, there are sometimes different trunk groups to the > PSAP also for wireline and wireless, but I think that this is to help > the PSAP ensure that volumes and bursts of calls from mobiles won't > swamp out emergency service to wireline callers, not because they were > routed differently? > > Nadine > > P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and Paul Stoffels to > this thread because they have a wealth of experience to add to this > discussion, I expect. > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Delaine M Arnold ENP > Sent: Thursday, February 02, 2006 6:28 PM > To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing > > I've heard some numbers from various PSAPs indicating their wireless > call volume continues to increase and is more than their wireline > volume. I've heard 45-50% wireless in some areas. Many PSAPs have > separate trunks for wireline and wireless. This is not a small problem. > > Delaine M. Arnold, ENP > Independent Consultant > Chair, NENA Data Technical Committee > Voice: 813-960-1698 > Fax: 309-412-7821 > Email: dmarnold@verizon.net > > "The finish line is just the beginning." > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Thursday, February 02, 2006 4:57 PM > To: Brian Rosen; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing > > Ooopss... I meant to add whether this was a 5% outlying problem, or a > significant proportion of jurisdictions? > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of >> Brian Rosen >> Sent: Friday, 3 February 2006 8:17 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] Wireline vs wireless routing >> >> A subtle problem that may give rise to another requirement is that in >> some areas a true moble client has different routing than a wireline >> client. The psap service boundaies are different depending on what > you >> are calling on. It may be that this difference fades over time, but > its >> clearly different in some areas today. >> >> Brian >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ > ---- > -------------------- > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------ > ---- > -------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ------------------------------------------------------------------------ > > Subject: > NJ Questions > From: > "Gojanovich, Robert" > Date: > Fri, 3 Feb 2006 13:46:44 -0500 > To: > "Rollender, Douglas Harold (Douglas)" > > To: > "Rollender, Douglas Harold (Douglas)" > CC: > "Abbott, Nadine B" > > > Doug, > > Nadine forwarded me your questions (I am not on the ecrit list server). Answers below. > > Follow up questions for Gojo on the NJ scenario - > > 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? Gojo: It doesn't. Until the call is answered and the location arrives or is provided by the caller, no one knows where the call came from. > > 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? Gojo: You have no caller location until after the call is answered. This is the legacy of NCAS thinking. The original design in J-Std-036 called for the location information to be sent as a TCAP message over SS7 as part of the call setup. Three things, unfortunately, were missing: 1) ALI databases are not SCPs and are not on the SS7 network, 2) most 9-1-1 networks did not support SS7 at the time, and 3) The location technology can't derive location that fast. In wireline compatibility mode deployments, it is possible for the MPC to receive some locations fast enough to affe ct! > (ESRK selection) routing (at least, that is what they claim), but NJ implemented CAS for Phase 1 and NCAS (J-std terminology, formerly called HCAS) for Phase 2. > > The NJ system does have the potential to route on location. The architecture includes a data link between the SR and the ALI. When a wireless call hits the SR, a message containing the ESRD and CBN is sent to the ALI. The ALI immediately launches a query to the MPC. It was designed so that when the coordinate routing feature was implemented, the SR would wait 2-3 seconds before completing the call to the PSAP. In that time, the ESME would query the MPC, acquire the coordinates and translate to the precise ESN. The ESN would be sent to the SR to be used for routing. If the ALI did not respond in 2-3 seconds, say, the SR would go ahead and route the call based on the ESRD (cell sector). Since the PDEs can't deliver fast enough on a consistent basis, the State hasn't yet bought the feature. > > You have two choices: Route the call to the County/State or route the call to the municipality where the cell is located. Either way will result in some number of transfers. The municipal PSAPs, for the most part, are too small to deal with a high volume of calls from outside their jurisdiction and don't want calls unless they belong to them. Unless it can be determined with some certainty that the caller is within their jurisdiction, they will refuse to answer the calls. This forces the call to the next wrung on the ladder, be it County or State. > > It is no more unsafe to send the call to the County for them to screen and transfer to the appropriate PSAP, than it is to send the call to the municipal PSAP where it still has to be screened and, in many cases, transferred. Sending all calls to the County provides for consistency and some predictability. It also allows the County to screen out redundant and non-emergency calls that the local PSAPs are too small to handle in many, many cases. > > 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? Gojo: The data delivered through the ESME will follow the call, sort of, and will often be updated. The PSAP that receives the transfer does not get ALI data from the first PSAP, it does its own dip to the ALI database using the ESRK, ESRD or CBN. This dip will generate a new position request to the MPC, so the location data received at the second PSAP may be different than that received by the first PSAP. The Phase 1 data will be the same but the lat/long may be different. > > Ancillary information acquired from the caller is usually given to the second PSAP verbally. Very few PSAPs have links between CAD systems to do that automatically. Most of that data flow is verbal. > > Gojo > > Robert K. Gojanovich, ENP > Director > iXP Corporation > > 609-406-7625 Direct Dial > > 215-435-0703 Mobile > > 609-406-7699 Fax > > rgojo@ixpcorp.com > > www.ixpcorp.com > > iXP Corporation... Problem Solved > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 17:23:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59LM-000278-8w; Fri, 03 Feb 2006 17:23:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59LI-000267-1i for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 17:23:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21013 for ; Fri, 3 Feb 2006 17:21:59 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F59Wm-0001Ds-4i for ecrit@ietf.org; Fri, 03 Feb 2006 17:35:41 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F59Km-0003gO-0N; Fri, 03 Feb 2006 16:23:16 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Rollender, Douglas Harold \(Douglas\)'" Subject: RE: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 17:18:48 -0500 Message-ID: <010001c6290f$d05b4b10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYpDXYj3ugQSc/6SAGor6tUKwolOQAAR9Mg In-Reply-To: <43E3D1A9.7050009@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 Content-Transfer-Encoding: 7bit Cc: RGojo@iXPCorp.com, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I do not agree. While you can argue that the route is wrong it IS the route, and you can't say "but I can send it to the right place". The reality is that there is a set of wireline polygons and a set of wireless polygons, and they are different. Wishing they were not isn't helpful. You can route a wireless call with the wireline polygon set. Eventually, this situation will resolve itself, but I think we will deploy before it does. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, February 03, 2006 4:57 PM To: Rollender, Douglas Harold (Douglas) Cc: RGojo@iXPCorp.com; ECRIT Subject: Re: [Ecrit] Wireline vs wireless routing The conclusion, however, seems to be that routing is, in all cases, based on currently-available location information, just that a wireless call may end up in the wrong place initially due to the limitations of that initial location fix. This seems to indicate that no new mechanisms in the mapping protocol are required. Rollender, Douglas Harold (Douglas) wrote: > Reply to follow-up questions from Gojo attached. > > Gojo, > > Thanks for further clarification on difference in routing between wireless and wireline. Not sure how ECRIT may use the information except we can anticipate needing to support the same routing scenarios for voice and data and the same location functions and performance characteristics in future access networks. > > Doug > > Douglas Rollender > Lucent Technologies > Wireless Standards Development and Industry Relations > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > Rollender, Douglas Harold (Douglas) > Sent: Friday, February 03, 2006 10:58 AM > To: Abbott, Nadine B; ECRIT > Subject: RE: [Ecrit] Wireline vs wireless routing > > > Follow up questions for Gojo on the NJ scenario - > > 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? > > 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? > > 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? > > Doug > > Douglas Rollender > Lucent Technologies > Wireless Standards Development and Industry Relations > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > Abbott, Nadine B > Sent: Friday, February 03, 2006 9:29 AM > To: ECRIT > Subject: FW: [Ecrit] Wireline vs wireless routing > > > Some clarifications > > -----Original Message----- > From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] > Sent: Thursday, February 02, 2006 8:44 PM > To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom, James; Brian > Rosen > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) > Subject: RE: [Ecrit] Wireline vs wireless routing > > This is just an "application of terminology" problem. > > Its not that PSAP routing is intentionally different for wireline vs > wireless, it has to do with how granular you can get in your routing > decisions. The PSAP that dispatches emergency services is the same for > both callers, but the PSAP that gets the call initially may be > different. > > NJ is a good example of how this plays out. NJ has 230 PSAPs covering > the 21 counties. Many PSAPs serve a single municipality and several > counties in NJ have more than 20 PSAPs with no county-level PSAP. Let's > say I place a cell tower on the roof of 4 Skiles Ave in Piscataway. The > street address for that tower is 4 Skiles Ave which, according to the > MSAG, would be routed to the Piscataway PD PSAP. Unfortunately, the cell > tower, with a 5 mile serving radius, serves callers in 4 or 5 > neighboring towns as well as Piscataway. > > I need to route calls from this cell to a County or State Police PSAP > that is set up to answer from a wider area. To do that, we created the > State of XX in the MSAG, so that 4 Skiles Ave, Piscataway, XX could be > assigned a different ESN and be routed to a different PSAP. > > If the caller turns out to be in Piscataway, the call is transferred > from the County/State PSAP to Piscataway PD for dispatching. The point > is that the wireless caller may be routed to a different PSAP out of > necessity, but the call will ultimately end up at the PSAP serving the > caller's location. > > Why not route the call based on the caller's actual location? Because, > generally speaking, the location data is not derived or delivered fast > enough to be usable for routing. We'd have to place the caller in queue > and play cheesy elevator music until the location could be derived, > delivered and translated to an ESN. That probably wouldn't be popular. > Wireless callers already have to wait longer to reach 9-1-1 than > wireline callers simply because wireless calls take longer to set up, > particularly if RF channels are not immediately available. Over time, as > the technology matures, routing on location will become the norm and the > need to route differently will go away. > > I hope no one considers this type of routing a viable option for VoIP. > We did it for wireless because we had to, not because we wanted to. > > Gojo > > Robert K. Gojanovich, ENP > Director > iXP Corporation > 609-406-7625 Direct Dial > 215-435-0703 Mobile > 609-406-7699 Fax > rgojo@ixpcorp.com > www.ixpcorp.com > iXP Corporation... Problem Solved > > -----Original Message----- > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > Sent: Thursday, February 02, 2006 7:31 PM > To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT); > Gojanovich, Robert > Subject: RE: [Ecrit] Wireline vs wireless routing > > Brian, > > Perhaps you can clarify with some examples of what you mean about > different routing of wireline and wireless callers? I've never heard > before that for the very same location, emergency calls routed to a > given PSAP would be dispatched differently, with different emergency > responders for wireline and wireless. > > However, I have heard of examples of different routing to different > answering points/PSAPs for wireless calls based on access type and > location, like the following. > In California, wireless calls used to be routed to the Highway Patrol, > but this began phasing out several years ago. Likewise, in other > states, like NJ, wireless calls were routed to a central PSAP because of > the high volumes and the need to handle the traffic slightly > differently, at least partly because of location-related concerns. But I > believe that these kind of arrangements are being phased out as most > areas are at least moving toward implementation of Wireless Phase I and > Phase II, and are enabling wireless calls to be appropriately routed to > a PSAP based on location. However, wireless calls may be routed based > on primary PSAP serving area, because the granularity (down to > information that identifies the appropriate emergency resources to be > dispatched, i.e., ESZ) may not be available for wireless p-ANIs. > > As Delaine mentions, there are sometimes different trunk groups to the > PSAP also for wireline and wireless, but I think that this is to help > the PSAP ensure that volumes and bursts of calls from mobiles won't > swamp out emergency service to wireline callers, not because they were > routed differently? > > Nadine > > P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and Paul Stoffels to > this thread because they have a wealth of experience to add to this > discussion, I expect. > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Delaine M Arnold ENP > Sent: Thursday, February 02, 2006 6:28 PM > To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing > > I've heard some numbers from various PSAPs indicating their wireless > call volume continues to increase and is more than their wireline > volume. I've heard 45-50% wireless in some areas. Many PSAPs have > separate trunks for wireline and wireless. This is not a small problem. > > Delaine M. Arnold, ENP > Independent Consultant > Chair, NENA Data Technical Committee > Voice: 813-960-1698 > Fax: 309-412-7821 > Email: dmarnold@verizon.net > > "The finish line is just the beginning." > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Thursday, February 02, 2006 4:57 PM > To: Brian Rosen; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing > > Ooopss... I meant to add whether this was a 5% outlying problem, or a > significant proportion of jurisdictions? > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of >> Brian Rosen >> Sent: Friday, 3 February 2006 8:17 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] Wireline vs wireless routing >> >> A subtle problem that may give rise to another requirement is that in >> some areas a true moble client has different routing than a wireline >> client. The psap service boundaies are different depending on what > you >> are calling on. It may be that this difference fades over time, but > its >> clearly different in some areas today. >> >> Brian >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ > ---- > -------------------- > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------ > ---- > -------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ------------------------------------------------------------------------ > > Subject: > NJ Questions > From: > "Gojanovich, Robert" > Date: > Fri, 3 Feb 2006 13:46:44 -0500 > To: > "Rollender, Douglas Harold (Douglas)" > > To: > "Rollender, Douglas Harold (Douglas)" > CC: > "Abbott, Nadine B" > > > Doug, > > Nadine forwarded me your questions (I am not on the ecrit list server). Answers below. > > Follow up questions for Gojo on the NJ scenario - > > 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? Gojo: It doesn't. Until the call is answered and the location arrives or is provided by the caller, no one knows where the call came from. > > 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? Gojo: You have no caller location until after the call is answered. This is the legacy of NCAS thinking. The original design in J-Std-036 called for the location information to be sent as a TCAP message over SS7 as part of the call setup. Three things, unfortunately, were missing: 1) ALI databases are not SCPs and are not on the SS7 network, 2) most 9-1-1 networks did not support SS7 at the time, and 3) The location technology can't derive location that fast. In wireline compatibility mode deployments, it is possible for the MPC to receive some locations fast enough to affe ct! > (ESRK selection) routing (at least, that is what they claim), but NJ implemented CAS for Phase 1 and NCAS (J-std terminology, formerly called HCAS) for Phase 2. > > The NJ system does have the potential to route on location. The architecture includes a data link between the SR and the ALI. When a wireless call hits the SR, a message containing the ESRD and CBN is sent to the ALI. The ALI immediately launches a query to the MPC. It was designed so that when the coordinate routing feature was implemented, the SR would wait 2-3 seconds before completing the call to the PSAP. In that time, the ESME would query the MPC, acquire the coordinates and translate to the precise ESN. The ESN would be sent to the SR to be used for routing. If the ALI did not respond in 2-3 seconds, say, the SR would go ahead and route the call based on the ESRD (cell sector). Since the PDEs can't deliver fast enough on a consistent basis, the State hasn't yet bought the feature. > > You have two choices: Route the call to the County/State or route the call to the municipality where the cell is located. Either way will result in some number of transfers. The municipal PSAPs, for the most part, are too small to deal with a high volume of calls from outside their jurisdiction and don't want calls unless they belong to them. Unless it can be determined with some certainty that the caller is within their jurisdiction, they will refuse to answer the calls. This forces the call to the next wrung on the ladder, be it County or State. > > It is no more unsafe to send the call to the County for them to screen and transfer to the appropriate PSAP, than it is to send the call to the municipal PSAP where it still has to be screened and, in many cases, transferred. Sending all calls to the County provides for consistency and some predictability. It also allows the County to screen out redundant and non-emergency calls that the local PSAPs are too small to handle in many, many cases. > > 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? Gojo: The data delivered through the ESME will follow the call, sort of, and will often be updated. The PSAP that receives the transfer does not get ALI data from the first PSAP, it does its own dip to the ALI database using the ESRK, ESRD or CBN. This dip will generate a new position request to the MPC, so the location data received at the second PSAP may be different than that received by the first PSAP. The Phase 1 data will be the same but the lat/long may be different. > > Ancillary information acquired from the caller is usually given to the second PSAP verbally. Very few PSAPs have links between CAD systems to do that automatically. Most of that data flow is verbal. > > Gojo > > Robert K. Gojanovich, ENP > Director > iXP Corporation > > 609-406-7625 Direct Dial > > 215-435-0703 Mobile > > 609-406-7699 Fax > > rgojo@ixpcorp.com > > www.ixpcorp.com > > iXP Corporation... Problem Solved > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 17:34:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59Vc-0005gk-Rs; Fri, 03 Feb 2006 17:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59VZ-0005el-Lv for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 17:34:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22432 for ; Fri, 3 Feb 2006 17:32:38 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F59h5-0001pS-Qj for ecrit@ietf.org; Fri, 03 Feb 2006 17:46:20 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F59VF-0005Qn-7H; Fri, 03 Feb 2006 16:34:05 -0600 From: "Brian Rosen" To: , "'Henning Schulzrinne'" , "'Rollender, Douglas Harold \(Douglas\)'" Subject: RE: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 17:29:33 -0500 Message-ID: <010c01c62911$5118cb00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYpDXYj3ugQSc/6SAGor6tUKwolOQAAR9MgAACpJbA= In-Reply-To: <010001c6290f$d05b4b10$640fa8c0@cis.neustar.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Content-Transfer-Encoding: 7bit Cc: RGojo@iXPCorp.com, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sorry, dropped a "'t". I meant to say that you CAN'T route a wireless call with the wireline polygon set. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, February 03, 2006 5:19 PM To: 'Henning Schulzrinne'; 'Rollender, Douglas Harold (Douglas)' Cc: RGojo@iXPCorp.com; 'ECRIT' Subject: RE: [Ecrit] Wireline vs wireless routing I do not agree. While you can argue that the route is wrong it IS the route, and you can't say "but I can send it to the right place". The reality is that there is a set of wireline polygons and a set of wireless polygons, and they are different. Wishing they were not isn't helpful. You can route a wireless call with the wireline polygon set. Eventually, this situation will resolve itself, but I think we will deploy before it does. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, February 03, 2006 4:57 PM To: Rollender, Douglas Harold (Douglas) Cc: RGojo@iXPCorp.com; ECRIT Subject: Re: [Ecrit] Wireline vs wireless routing The conclusion, however, seems to be that routing is, in all cases, based on currently-available location information, just that a wireless call may end up in the wrong place initially due to the limitations of that initial location fix. This seems to indicate that no new mechanisms in the mapping protocol are required. Rollender, Douglas Harold (Douglas) wrote: > Reply to follow-up questions from Gojo attached. > > Gojo, > > Thanks for further clarification on difference in routing between wireless and wireline. Not sure how ECRIT may use the information except we can anticipate needing to support the same routing scenarios for voice and data and the same location functions and performance characteristics in future access networks. > > Doug > > Douglas Rollender > Lucent Technologies > Wireless Standards Development and Industry Relations > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > Rollender, Douglas Harold (Douglas) > Sent: Friday, February 03, 2006 10:58 AM > To: Abbott, Nadine B; ECRIT > Subject: RE: [Ecrit] Wireline vs wireless routing > > > Follow up questions for Gojo on the NJ scenario - > > 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? > > 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? > > 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? > > Doug > > Douglas Rollender > Lucent Technologies > Wireless Standards Development and Industry Relations > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of > Abbott, Nadine B > Sent: Friday, February 03, 2006 9:29 AM > To: ECRIT > Subject: FW: [Ecrit] Wireline vs wireless routing > > > Some clarifications > > -----Original Message----- > From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] > Sent: Thursday, February 02, 2006 8:44 PM > To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom, James; Brian > Rosen > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) > Subject: RE: [Ecrit] Wireline vs wireless routing > > This is just an "application of terminology" problem. > > Its not that PSAP routing is intentionally different for wireline vs > wireless, it has to do with how granular you can get in your routing > decisions. The PSAP that dispatches emergency services is the same for > both callers, but the PSAP that gets the call initially may be > different. > > NJ is a good example of how this plays out. NJ has 230 PSAPs covering > the 21 counties. Many PSAPs serve a single municipality and several > counties in NJ have more than 20 PSAPs with no county-level PSAP. Let's > say I place a cell tower on the roof of 4 Skiles Ave in Piscataway. The > street address for that tower is 4 Skiles Ave which, according to the > MSAG, would be routed to the Piscataway PD PSAP. Unfortunately, the cell > tower, with a 5 mile serving radius, serves callers in 4 or 5 > neighboring towns as well as Piscataway. > > I need to route calls from this cell to a County or State Police PSAP > that is set up to answer from a wider area. To do that, we created the > State of XX in the MSAG, so that 4 Skiles Ave, Piscataway, XX could be > assigned a different ESN and be routed to a different PSAP. > > If the caller turns out to be in Piscataway, the call is transferred > from the County/State PSAP to Piscataway PD for dispatching. The point > is that the wireless caller may be routed to a different PSAP out of > necessity, but the call will ultimately end up at the PSAP serving the > caller's location. > > Why not route the call based on the caller's actual location? Because, > generally speaking, the location data is not derived or delivered fast > enough to be usable for routing. We'd have to place the caller in queue > and play cheesy elevator music until the location could be derived, > delivered and translated to an ESN. That probably wouldn't be popular. > Wireless callers already have to wait longer to reach 9-1-1 than > wireline callers simply because wireless calls take longer to set up, > particularly if RF channels are not immediately available. Over time, as > the technology matures, routing on location will become the norm and the > need to route differently will go away. > > I hope no one considers this type of routing a viable option for VoIP. > We did it for wireless because we had to, not because we wanted to. > > Gojo > > Robert K. Gojanovich, ENP > Director > iXP Corporation > 609-406-7625 Direct Dial > 215-435-0703 Mobile > 609-406-7699 Fax > rgojo@ixpcorp.com > www.ixpcorp.com > iXP Corporation... Problem Solved > > -----Original Message----- > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > Sent: Thursday, February 02, 2006 7:31 PM > To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT); > Gojanovich, Robert > Subject: RE: [Ecrit] Wireline vs wireless routing > > Brian, > > Perhaps you can clarify with some examples of what you mean about > different routing of wireline and wireless callers? I've never heard > before that for the very same location, emergency calls routed to a > given PSAP would be dispatched differently, with different emergency > responders for wireline and wireless. > > However, I have heard of examples of different routing to different > answering points/PSAPs for wireless calls based on access type and > location, like the following. > In California, wireless calls used to be routed to the Highway Patrol, > but this began phasing out several years ago. Likewise, in other > states, like NJ, wireless calls were routed to a central PSAP because of > the high volumes and the need to handle the traffic slightly > differently, at least partly because of location-related concerns. But I > believe that these kind of arrangements are being phased out as most > areas are at least moving toward implementation of Wireless Phase I and > Phase II, and are enabling wireless calls to be appropriately routed to > a PSAP based on location. However, wireless calls may be routed based > on primary PSAP serving area, because the granularity (down to > information that identifies the appropriate emergency resources to be > dispatched, i.e., ESZ) may not be available for wireless p-ANIs. > > As Delaine mentions, there are sometimes different trunk groups to the > PSAP also for wireline and wireless, but I think that this is to help > the PSAP ensure that volumes and bursts of calls from mobiles won't > swamp out emergency service to wireline callers, not because they were > routed differently? > > Nadine > > P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and Paul Stoffels to > this thread because they have a wealth of experience to add to this > discussion, I expect. > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Delaine M Arnold ENP > Sent: Thursday, February 02, 2006 6:28 PM > To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing > > I've heard some numbers from various PSAPs indicating their wireless > call volume continues to increase and is more than their wireline > volume. I've heard 45-50% wireless in some areas. Many PSAPs have > separate trunks for wireline and wireless. This is not a small problem. > > Delaine M. Arnold, ENP > Independent Consultant > Chair, NENA Data Technical Committee > Voice: 813-960-1698 > Fax: 309-412-7821 > Email: dmarnold@verizon.net > > "The finish line is just the beginning." > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Winterbottom, James > Sent: Thursday, February 02, 2006 4:57 PM > To: Brian Rosen; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing > > Ooopss... I meant to add whether this was a 5% outlying problem, or a > significant proportion of jurisdictions? > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of >> Brian Rosen >> Sent: Friday, 3 February 2006 8:17 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] Wireline vs wireless routing >> >> A subtle problem that may give rise to another requirement is that in >> some areas a true moble client has different routing than a wireline >> client. The psap service boundaies are different depending on what > you >> are calling on. It may be that this difference fades over time, but > its >> clearly different in some areas today. >> >> Brian >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ > ---- > -------------------- > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------ > ---- > -------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ------------------------------------------------------------------------ > > Subject: > NJ Questions > From: > "Gojanovich, Robert" > Date: > Fri, 3 Feb 2006 13:46:44 -0500 > To: > "Rollender, Douglas Harold (Douglas)" > > To: > "Rollender, Douglas Harold (Douglas)" > CC: > "Abbott, Nadine B" > > > Doug, > > Nadine forwarded me your questions (I am not on the ecrit list server). Answers below. > > Follow up questions for Gojo on the NJ scenario - > > 1) How does the county PSAP know which local PSAP is to receive the call if the caller location data is not available from the ESME to the state/county PSAP until after the call arrives? Gojo: It doesn't. Until the call is answered and the location arrives or is provided by the caller, no one knows where the call came from. > > 2) Is it really safer and faster to deliver the call initially to a state/county PSAP without the location data and then transfer the call to the town PSAP after the either (a) data message arrives from the ESME to the state/county PSAP or (b) the caller is asked to provide the location information verbally, the state/county PSAP call taker does a "manual" data look-up and then signals a call transfer? Gojo: You have no caller location until after the call is answered. This is the legacy of NCAS thinking. The original design in J-Std-036 called for the location information to be sent as a TCAP message over SS7 as part of the call setup. Three things, unfortunately, were missing: 1) ALI databases are not SCPs and are not on the SS7 network, 2) most 9-1-1 networks did not support SS7 at the time, and 3) The location technology can't derive location that fast. In wireline compatibility mode deployments, it is possible for the MPC to receive some locations fast enough to affe ct! > (ESRK selection) routing (at least, that is what they claim), but NJ implemented CAS for Phase 1 and NCAS (J-std terminology, formerly called HCAS) for Phase 2. > > The NJ system does have the potential to route on location. The architecture includes a data link between the SR and the ALI. When a wireless call hits the SR, a message containing the ESRD and CBN is sent to the ALI. The ALI immediately launches a query to the MPC. It was designed so that when the coordinate routing feature was implemented, the SR would wait 2-3 seconds before completing the call to the PSAP. In that time, the ESME would query the MPC, acquire the coordinates and translate to the precise ESN. The ESN would be sent to the SR to be used for routing. If the ALI did not respond in 2-3 seconds, say, the SR would go ahead and route the call based on the ESRD (cell sector). Since the PDEs can't deliver fast enough on a consistent basis, the State hasn't yet bought the feature. > > You have two choices: Route the call to the County/State or route the call to the municipality where the cell is located. Either way will result in some number of transfers. The municipal PSAPs, for the most part, are too small to deal with a high volume of calls from outside their jurisdiction and don't want calls unless they belong to them. Unless it can be determined with some certainty that the caller is within their jurisdiction, they will refuse to answer the calls. This forces the call to the next wrung on the ladder, be it County or State. > > It is no more unsafe to send the call to the County for them to screen and transfer to the appropriate PSAP, than it is to send the call to the municipal PSAP where it still has to be screened and, in many cases, transferred. Sending all calls to the County provides for consistency and some predictability. It also allows the County to screen out redundant and non-emergency calls that the local PSAPs are too small to handle in many, many cases. > > 3) Does the call data (ESME data as well as interview information entered manually such as caller location) automatically follow the call, is it sent separately, "pulled" by the local call taker from a central data source after the call arrives at the local PSAP or not delivered at all? If data is sent separately, how is data delivery ensured to the same call taker that receives the call? Gojo: The data delivered through the ESME will follow the call, sort of, and will often be updated. The PSAP that receives the transfer does not get ALI data from the first PSAP, it does its own dip to the ALI database using the ESRK, ESRD or CBN. This dip will generate a new position request to the MPC, so the location data received at the second PSAP may be different than that received by the first PSAP. The Phase 1 data will be the same but the lat/long may be different. > > Ancillary information acquired from the caller is usually given to the second PSAP verbally. Very few PSAPs have links between CAD systems to do that automatically. Most of that data flow is verbal. > > Gojo > > Robert K. Gojanovich, ENP > Director > iXP Corporation > > 609-406-7625 Direct Dial > > 215-435-0703 Mobile > > 609-406-7699 Fax > > rgojo@ixpcorp.com > > www.ixpcorp.com > > iXP Corporation... Problem Solved > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 17:48:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59jE-0004Ln-Vz; Fri, 03 Feb 2006 17:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59jA-0004JM-Nf for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 17:48:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23679 for ; Fri, 3 Feb 2006 17:46:50 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F59un-0002R6-SG for ecrit@ietf.org; Fri, 03 Feb 2006 18:00:32 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2006 14:48:17 -0800 X-IronPort-AV: i="4.02,85,1139212800"; d="scan'208"; a="253486888:sNHT39009370" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k13MmGKT021838; Fri, 3 Feb 2006 14:48:16 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 14:48:16 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 14:48:15 -0800 From: "Marc Linsner" To: , "'Henning Schulzrinne'" , "'Rollender, Douglas Harold \(Douglas\)'" Subject: RE: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 17:48:13 -0500 Message-ID: <016b01c62913$ead14ae0$2e0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <010c01c62911$5118cb00$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYpDXYj3ugQSc/6SAGor6tUKwolOQAAR9MgAACpJbAAAJ0H8A== X-OriginalArrivalTime: 03 Feb 2006 22:48:15.0447 (UTC) FILETIME=[EB3E1670:01C62913] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ba8529e77affe49b0f315db98a262ee Content-Transfer-Encoding: 7bit Cc: RGojo@iXPCorp.com, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org But, you can certainly route a call different for 123 main st than you do for 125 main st (and perform the equivalent with geo locs). This is NOT a problem. -Marc- > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Friday, February 03, 2006 5:30 PM > To: br@brianrosen.net; 'Henning Schulzrinne'; 'Rollender, > Douglas Harold (Douglas)' > Cc: RGojo@iXPCorp.com; 'ECRIT' > Subject: RE: [Ecrit] Wireline vs wireless routing > > Sorry, dropped a "'t". I meant to say that you CAN'T route a > wireless call with the wireline polygon set. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Friday, February 03, 2006 5:19 PM > To: 'Henning Schulzrinne'; 'Rollender, Douglas Harold (Douglas)' > Cc: RGojo@iXPCorp.com; 'ECRIT' > Subject: RE: [Ecrit] Wireline vs wireless routing > > I do not agree. > > While you can argue that the route is wrong it IS the route, > and you can't > say "but I can send it to the right place". > > The reality is that there is a set of wireline polygons and a > set of wireless polygons, and they are different. Wishing > they were not isn't helpful. You can route a wireless call > with the wireline polygon set. > > Eventually, this situation will resolve itself, but I think > we will deploy before it does. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Henning Schulzrinne > Sent: Friday, February 03, 2006 4:57 PM > To: Rollender, Douglas Harold (Douglas) > Cc: RGojo@iXPCorp.com; ECRIT > Subject: Re: [Ecrit] Wireline vs wireless routing > > The conclusion, however, seems to be that routing is, in all > cases, based on currently-available location information, > just that a wireless call may end up in the wrong place > initially due to the limitations of that initial location > fix. This seems to indicate that no new mechanisms in the > mapping protocol are required. > > Rollender, Douglas Harold (Douglas) wrote: > > Reply to follow-up questions from Gojo attached. > > > > Gojo, > > > > Thanks for further clarification on difference in routing between > > wireless > and wireline. Not sure how ECRIT may use the information > except we can anticipate needing to support the same routing > scenarios for voice and data and the same location functions > and performance characteristics in future access networks. > > > > Doug > > > > Douglas Rollender > > Lucent Technologies > > Wireless Standards Development and Industry Relations > > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf > > Of Rollender, Douglas Harold (Douglas) > > Sent: Friday, February 03, 2006 10:58 AM > > To: Abbott, Nadine B; ECRIT > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > > > Follow up questions for Gojo on the NJ scenario - > > > > 1) How does the county PSAP know which local PSAP is to receive the > > call > if the caller location data is not available from the ESME to > the state/county PSAP until after the call arrives? > > > > 2) Is it really safer and faster to deliver the call initially to a > state/county PSAP without the location data and then transfer > the call to the town PSAP after the either (a) data message > arrives from the ESME to the state/county PSAP or (b) the > caller is asked to provide the location information verbally, > the state/county PSAP call taker does a "manual" data look-up > and then signals a call transfer? > > > > 3) Does the call data (ESME data as well as interview information > > entered > manually such as caller location) automatically follow the > call, is it sent separately, "pulled" by the local call taker > from a central data source after the call arrives at the > local PSAP or not delivered at all? If data is sent > separately, how is data delivery ensured to the same call > taker that receives the call? > > > > Doug > > > > Douglas Rollender > > Lucent Technologies > > Wireless Standards Development and Industry Relations > > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf > > Of Abbott, Nadine B > > Sent: Friday, February 03, 2006 9:29 AM > > To: ECRIT > > Subject: FW: [Ecrit] Wireline vs wireless routing > > > > > > Some clarifications > > > > -----Original Message----- > > From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] > > Sent: Thursday, February 02, 2006 8:44 PM > > To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom, > James; Brian > > Rosen > > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > This is just an "application of terminology" problem. > > > > Its not that PSAP routing is intentionally different for > wireline vs > > wireless, it has to do with how granular you can get in > your routing > > decisions. The PSAP that dispatches emergency services is > the same for > > both callers, but the PSAP that gets the call initially may be > > different. > > > > NJ is a good example of how this plays out. NJ has 230 > PSAPs covering > > the 21 counties. Many PSAPs serve a single municipality and several > > counties in NJ have more than 20 PSAPs with no county-level PSAP. > > Let's say I place a cell tower on the roof of 4 Skiles Ave in > > Piscataway. The street address for that tower is 4 Skiles > Ave which, > > according to the MSAG, would be routed to the Piscataway PD PSAP. > > Unfortunately, the cell tower, with a 5 mile serving radius, serves > > callers in 4 or 5 neighboring towns as well as Piscataway. > > > > I need to route calls from this cell to a County or State > Police PSAP > > that is set up to answer from a wider area. To do that, we > created the > > State of XX in the MSAG, so that 4 Skiles Ave, Piscataway, > XX could be > > assigned a different ESN and be routed to a different PSAP. > > > > If the caller turns out to be in Piscataway, the call is > transferred > > from the County/State PSAP to Piscataway PD for > dispatching. The point > > is that the wireless caller may be routed to a different > PSAP out of > > necessity, but the call will ultimately end up at the PSAP > serving the > > caller's location. > > > > Why not route the call based on the caller's actual > location? Because, > > generally speaking, the location data is not derived or > delivered fast > > enough to be usable for routing. We'd have to place the caller in > > queue and play cheesy elevator music until the location could be > > derived, delivered and translated to an ESN. That probably > wouldn't be popular. > > Wireless callers already have to wait longer to reach 9-1-1 than > > wireline callers simply because wireless calls take longer > to set up, > > particularly if RF channels are not immediately available. > Over time, > > as the technology matures, routing on location will become the norm > > and the need to route differently will go away. > > > > I hope no one considers this type of routing a viable > option for VoIP. > > We did it for wireless because we had to, not because we wanted to. > > > > Gojo > > > > Robert K. Gojanovich, ENP > > Director > > iXP Corporation > > 609-406-7625 Direct Dial > > 215-435-0703 Mobile > > 609-406-7699 Fax > > rgojo@ixpcorp.com > > www.ixpcorp.com > > iXP Corporation... Problem Solved > > > > -----Original Message----- > > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > > Sent: Thursday, February 02, 2006 7:31 PM > > To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen > > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT); > > Gojanovich, Robert > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > Brian, > > > > Perhaps you can clarify with some examples of what you mean about > > different routing of wireline and wireless callers? I've > never heard > > before that for the very same location, emergency calls routed to a > > given PSAP would be dispatched differently, with different > emergency > > responders for wireline and wireless. > > > > However, I have heard of examples of different routing to different > > answering points/PSAPs for wireless calls based on access type and > > location, like the following. > > In California, wireless calls used to be routed to the > Highway Patrol, > > but this began phasing out several years ago. Likewise, in other > > states, like NJ, wireless calls were routed to a central > PSAP because > > of the high volumes and the need to handle the traffic slightly > > differently, at least partly because of location-related > concerns. But > > I believe that these kind of arrangements are being phased > out as most > > areas are at least moving toward implementation of Wireless Phase I > > and Phase II, and are enabling wireless calls to be appropriately > > routed to a PSAP based on location. However, wireless calls may be > > routed based on primary PSAP serving area, because the granularity > > (down to information that identifies the appropriate emergency > > resources to be dispatched, i.e., ESZ) may not be available > for wireless p-ANIs. > > > > As Delaine mentions, there are sometimes different trunk > groups to the > > PSAP also for wireline and wireless, but I think that this > is to help > > the PSAP ensure that volumes and bursts of calls from mobiles won't > > swamp out emergency service to wireline callers, not > because they were > > routed differently? > > > > Nadine > > > > P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and > Paul Stoffels > > to this thread because they have a wealth of experience to > add to this > > discussion, I expect. > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Delaine M Arnold ENP > > Sent: Thursday, February 02, 2006 6:28 PM > > To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > I've heard some numbers from various PSAPs indicating their > wireless > > call volume continues to increase and is more than their wireline > > volume. I've heard 45-50% wireless in some areas. Many PSAPs have > > separate trunks for wireline and wireless. This is not a > small problem. > > > > Delaine M. Arnold, ENP > > Independent Consultant > > Chair, NENA Data Technical Committee > > Voice: 813-960-1698 > > Fax: 309-412-7821 > > Email: dmarnold@verizon.net > > > > "The finish line is just the beginning." > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Winterbottom, James > > Sent: Thursday, February 02, 2006 4:57 PM > > To: Brian Rosen; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > Ooopss... I meant to add whether this was a 5% outlying > problem, or a > > significant proportion of jurisdictions? > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf > > Of > >> Brian Rosen > >> Sent: Friday, 3 February 2006 8:17 AM > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Wireline vs wireless routing > >> > >> A subtle problem that may give rise to another requirement > is that in > >> some areas a true moble client has different routing than > a wireline > >> client. The psap service boundaies are different depending on what > > you > >> are calling on. It may be that this difference fades over > time, but > > its > >> clearly different in some areas today. > >> > >> Brian > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > ---------------------------------------------------------------------- > > -- > > ---- > > -------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > > ---------------------------------------------------------------------- > > -- > > ---- > > -------------------- > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > Subject: > > NJ Questions > > From: > > "Gojanovich, Robert" > > Date: > > Fri, 3 Feb 2006 13:46:44 -0500 > > To: > > "Rollender, Douglas Harold (Douglas)" > > > > To: > > "Rollender, Douglas Harold (Douglas)" > > CC: > > "Abbott, Nadine B" > > > > > > Doug, > > > > Nadine forwarded me your questions (I am not on the ecrit > list server). > Answers below. > > > > Follow up questions for Gojo on the NJ scenario - > > > > 1) How does the county PSAP know which local PSAP is to receive the > > call > if the caller location data is not available from the ESME to > the state/county PSAP until after the call arrives? Gojo: It > doesn't. Until the call is answered and the location arrives > or is provided by the caller, no one knows where the call came from. > > > > 2) Is it really safer and faster to deliver the call initially to a > state/county PSAP without the location data and then transfer > the call to the town PSAP after the either (a) data message > arrives from the ESME to the state/county PSAP or (b) the > caller is asked to provide the location information verbally, > the state/county PSAP call taker does a "manual" data look-up > and then signals a call transfer? Gojo: You have no caller > location until after the call is answered. This is the legacy > of NCAS thinking. The original design in J-Std-036 called for > the location information to be sent as a TCAP message over > SS7 as part of the call setup. Three things, unfortunately, > were missing: 1) ALI databases are not SCPs and are not on > the SS7 network, 2) most 9-1-1 networks did not support SS7 > at the time, and > 3) The location technology can't derive location that fast. > In wireline compatibility mode deployments, it is possible > for the MPC to receive some locations fast enough to affe ct! > > (ESRK selection) routing (at least, that is what they > claim), but NJ > implemented CAS for Phase 1 and NCAS (J-std terminology, > formerly called > HCAS) for Phase 2. > > > > The NJ system does have the potential to route on location. The > architecture includes a data link between the SR and the ALI. > When a wireless call hits the SR, a message containing the > ESRD and CBN is sent to the ALI. The ALI immediately launches > a query to the MPC. It was designed so that when the > coordinate routing feature was implemented, the SR would wait > 2-3 seconds before completing the call to the PSAP. In that > time, the ESME would query the MPC, acquire the coordinates > and translate to the precise ESN. The ESN would be sent to > the SR to be used for routing. If the ALI did not respond in > 2-3 seconds, say, the SR would go ahead and route the call > based on the ESRD (cell sector). Since the PDEs can't deliver > fast enough on a consistent basis, the State hasn't yet > bought the feature. > > > > You have two choices: Route the call to the County/State or > route the > > call > to the municipality where the cell is located. Either way > will result in some number of transfers. The municipal PSAPs, > for the most part, are too small to deal with a high volume > of calls from outside their jurisdiction and don't want calls > unless they belong to them. Unless it can be determined with > some certainty that the caller is within their jurisdiction, > they will refuse to answer the calls. This forces the call to > the next wrung on the ladder, be it County or State. > > > > It is no more unsafe to send the call to the County for > them to screen > > and > transfer to the appropriate PSAP, than it is to send the call > to the municipal PSAP where it still has to be screened and, > in many cases, transferred. Sending all calls to the County > provides for consistency and some predictability. It also > allows the County to screen out redundant and non-emergency > calls that the local PSAPs are too small to handle in many, > many cases. > > > > 3) Does the call data (ESME data as well as interview information > > entered > manually such as caller location) automatically follow the > call, is it sent separately, "pulled" by the local call taker > from a central data source after the call arrives at the > local PSAP or not delivered at all? If data is sent > separately, how is data delivery ensured to the same call > taker that receives the call? Gojo: The data delivered > through the ESME will follow the call, sort of, and will > often be updated. The PSAP that receives the transfer does > not get ALI data from the first PSAP, it does its own dip to > the ALI database using the ESRK, ESRD or CBN. This dip will > generate a new position request to the MPC, so the location > data received at the second PSAP may be different than that > received by the first PSAP. The Phase 1 data will be the same > but the lat/long may be different. > > > > Ancillary information acquired from the caller is usually > given to the > second PSAP verbally. Very few PSAPs have links between CAD > systems to do that automatically. Most of that data flow is verbal. > > > > Gojo > > > > Robert K. Gojanovich, ENP > > Director > > iXP Corporation > > > > 609-406-7625 Direct Dial > > > > 215-435-0703 Mobile > > > > 609-406-7699 Fax > > > > rgojo@ixpcorp.com > > > > www.ixpcorp.com > > > > iXP Corporation... Problem Solved > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 18:12:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5A6W-0005Ad-R1; Fri, 03 Feb 2006 18:12:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5A6O-00059O-IV for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 18:12:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25279 for ; Fri, 3 Feb 2006 18:10:41 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5AHu-0003QB-R1 for ecrit@ietf.org; Fri, 03 Feb 2006 18:24:24 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 03 Feb 2006 15:12:09 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k13NC7WF017316; Fri, 3 Feb 2006 15:12:07 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 18:12:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 18:12:05 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3010F9591@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Ecrit] Wireline vs wireless routing Thread-Index: AcYpDXYj3ugQSc/6SAGor6tUKwolOQAAR9MgAACpJbAAAWYa4A== From: "Michael Hammer \(mhammer\)" To: , "Henning Schulzrinne" , "Rollender, Douglas Harold \(Douglas\)" X-OriginalArrivalTime: 03 Feb 2006 23:12:07.0213 (UTC) FILETIME=[40A43DD0:01C62917] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4863a9796402a44fdb52482f353618fe Content-Transfer-Encoding: quoted-printable Cc: RGojo@iXPCorp.com, ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So, if a phone switches from wireline (WiFi) to wireless (GSM) or vice versa, do the PSAPs have to change also? I know some are suggesting that the call can not switch networks when on 911, but the alternative is when one moves beyond radio coverage the call gets dropped. Redialing the call will go to a different PSAP. So, I guess you get two [fill in your emergency responder here] sent to your location. I think that will last as long as the emergency organizations have money to burn. Mike =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Friday, February 03, 2006 5:30 PM > To: br@brianrosen.net; 'Henning Schulzrinne'; 'Rollender,=20 > Douglas Harold (Douglas)' > Cc: RGojo@iXPCorp.com; 'ECRIT' > Subject: RE: [Ecrit] Wireline vs wireless routing >=20 > Sorry, dropped a "'t". I meant to say that you CAN'T route a=20 > wireless call with the wireline polygon set. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Friday, February 03, 2006 5:19 PM > To: 'Henning Schulzrinne'; 'Rollender, Douglas Harold (Douglas)' > Cc: RGojo@iXPCorp.com; 'ECRIT' > Subject: RE: [Ecrit] Wireline vs wireless routing >=20 > I do not agree. >=20 > While you can argue that the route is wrong it IS the route,=20 > and you can't > say "but I can send it to the right place". =20 >=20 > The reality is that there is a set of wireline polygons and a=20 > set of wireless polygons, and they are different. Wishing=20 > they were not isn't helpful. You can route a wireless call=20 > with the wireline polygon set. >=20 > Eventually, this situation will resolve itself, but I think=20 > we will deploy before it does. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Friday, February 03, 2006 4:57 PM > To: Rollender, Douglas Harold (Douglas) > Cc: RGojo@iXPCorp.com; ECRIT > Subject: Re: [Ecrit] Wireline vs wireless routing >=20 > The conclusion, however, seems to be that routing is, in all=20 > cases, based on currently-available location information,=20 > just that a wireless call may end up in the wrong place=20 > initially due to the limitations of that initial location=20 > fix. This seems to indicate that no new mechanisms in the=20 > mapping protocol are required. >=20 > Rollender, Douglas Harold (Douglas) wrote: > > Reply to follow-up questions from Gojo attached. > >=20 > > Gojo, > >=20 > > Thanks for further clarification on difference in routing between=20 > > wireless > and wireline. Not sure how ECRIT may use the information=20 > except we can anticipate needing to support the same routing=20 > scenarios for voice and data and the same location functions=20 > and performance characteristics in future access networks. > >=20 > > Doug > >=20 > > Douglas Rollender > > Lucent Technologies > > Wireless Standards Development and Industry Relations > > TN=3D973 386-4560, FAX=3D973 386-4555, Mobile=3D908-963-7965 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org]On Behalf=20 > > Of Rollender, Douglas Harold (Douglas) > > Sent: Friday, February 03, 2006 10:58 AM > > To: Abbott, Nadine B; ECRIT > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > >=20 > > Follow up questions for Gojo on the NJ scenario - > >=20 > > 1) How does the county PSAP know which local PSAP is to receive the=20 > > call > if the caller location data is not available from the ESME to=20 > the state/county PSAP until after the call arrives? > >=20 > > 2) Is it really safer and faster to deliver the call initially to a > state/county PSAP without the location data and then transfer=20 > the call to the town PSAP after the either (a) data message=20 > arrives from the ESME to the state/county PSAP or (b) the=20 > caller is asked to provide the location information verbally,=20 > the state/county PSAP call taker does a "manual" data look-up=20 > and then signals a call transfer? =20 > >=20 > > 3) Does the call data (ESME data as well as interview information=20 > > entered > manually such as caller location) automatically follow the=20 > call, is it sent separately, "pulled" by the local call taker=20 > from a central data source after the call arrives at the=20 > local PSAP or not delivered at all? If data is sent=20 > separately, how is data delivery ensured to the same call=20 > taker that receives the call? > >=20 > > Doug > >=20 > > Douglas Rollender > > Lucent Technologies > > Wireless Standards Development and Industry Relations > > TN=3D973 386-4560, FAX=3D973 386-4555, Mobile=3D908-963-7965 > >=20 > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org]On Behalf=20 > > Of Abbott, Nadine B > > Sent: Friday, February 03, 2006 9:29 AM > > To: ECRIT > > Subject: FW: [Ecrit] Wireline vs wireless routing > >=20 > >=20 > > Some clarifications > >=20 > > -----Original Message----- > > From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] > > Sent: Thursday, February 02, 2006 8:44 PM > > To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom,=20 > James; Brian=20 > > Rosen > > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > > This is just an "application of terminology" problem. > >=20 > > Its not that PSAP routing is intentionally different for=20 > wireline vs=20 > > wireless, it has to do with how granular you can get in=20 > your routing=20 > > decisions. The PSAP that dispatches emergency services is=20 > the same for=20 > > both callers, but the PSAP that gets the call initially may be=20 > > different. > >=20 > > NJ is a good example of how this plays out. NJ has 230=20 > PSAPs covering=20 > > the 21 counties. Many PSAPs serve a single municipality and several=20 > > counties in NJ have more than 20 PSAPs with no county-level PSAP.=20 > > Let's say I place a cell tower on the roof of 4 Skiles Ave in=20 > > Piscataway. The street address for that tower is 4 Skiles=20 > Ave which,=20 > > according to the MSAG, would be routed to the Piscataway PD PSAP.=20 > > Unfortunately, the cell tower, with a 5 mile serving radius, serves=20 > > callers in 4 or 5 neighboring towns as well as Piscataway. > >=20 > > I need to route calls from this cell to a County or State=20 > Police PSAP=20 > > that is set up to answer from a wider area. To do that, we=20 > created the=20 > > State of XX in the MSAG, so that 4 Skiles Ave, Piscataway,=20 > XX could be=20 > > assigned a different ESN and be routed to a different PSAP. > >=20 > > If the caller turns out to be in Piscataway, the call is=20 > transferred=20 > > from the County/State PSAP to Piscataway PD for=20 > dispatching. The point=20 > > is that the wireless caller may be routed to a different=20 > PSAP out of=20 > > necessity, but the call will ultimately end up at the PSAP=20 > serving the=20 > > caller's location. > >=20 > > Why not route the call based on the caller's actual=20 > location? Because,=20 > > generally speaking, the location data is not derived or=20 > delivered fast=20 > > enough to be usable for routing. We'd have to place the caller in=20 > > queue and play cheesy elevator music until the location could be=20 > > derived, delivered and translated to an ESN. That probably=20 > wouldn't be popular. > > Wireless callers already have to wait longer to reach 9-1-1 than=20 > > wireline callers simply because wireless calls take longer=20 > to set up,=20 > > particularly if RF channels are not immediately available.=20 > Over time,=20 > > as the technology matures, routing on location will become the norm=20 > > and the need to route differently will go away. > >=20 > > I hope no one considers this type of routing a viable=20 > option for VoIP. > > We did it for wireless because we had to, not because we wanted to. > >=20 > > Gojo > >=20 > > Robert K. Gojanovich, ENP > > Director > > iXP Corporation > > 609-406-7625 Direct Dial > > 215-435-0703 Mobile > > 609-406-7699 Fax > > rgojo@ixpcorp.com > > www.ixpcorp.com > > iXP Corporation... Problem Solved > >=20 > > -----Original Message----- > > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > > Sent: Thursday, February 02, 2006 7:31 PM > > To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen > > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT);=20 > > Gojanovich, Robert > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > > Brian, > >=20 > > Perhaps you can clarify with some examples of what you mean about=20 > > different routing of wireline and wireless callers? I've=20 > never heard=20 > > before that for the very same location, emergency calls routed to a=20 > > given PSAP would be dispatched differently, with different=20 > emergency=20 > > responders for wireline and wireless. > >=20 > > However, I have heard of examples of different routing to different=20 > > answering points/PSAPs for wireless calls based on access type and=20 > > location, like the following. > > In California, wireless calls used to be routed to the=20 > Highway Patrol,=20 > > but this began phasing out several years ago. Likewise, in other=20 > > states, like NJ, wireless calls were routed to a central=20 > PSAP because=20 > > of the high volumes and the need to handle the traffic slightly=20 > > differently, at least partly because of location-related=20 > concerns. But=20 > > I believe that these kind of arrangements are being phased=20 > out as most=20 > > areas are at least moving toward implementation of Wireless Phase I=20 > > and Phase II, and are enabling wireless calls to be appropriately=20 > > routed to a PSAP based on location. However, wireless calls may be=20 > > routed based on primary PSAP serving area, because the granularity=20 > > (down to information that identifies the appropriate emergency=20 > > resources to be dispatched, i.e., ESZ) may not be available=20 > for wireless p-ANIs. > > =20 > > As Delaine mentions, there are sometimes different trunk=20 > groups to the=20 > > PSAP also for wireline and wireless, but I think that this=20 > is to help=20 > > the PSAP ensure that volumes and bursts of calls from mobiles won't=20 > > swamp out emergency service to wireline callers, not=20 > because they were=20 > > routed differently? > > =20 > > Nadine > >=20 > > P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and=20 > Paul Stoffels=20 > > to this thread because they have a wealth of experience to=20 > add to this=20 > > discussion, I expect. > > =20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Delaine M Arnold ENP > > Sent: Thursday, February 02, 2006 6:28 PM > > To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > > I've heard some numbers from various PSAPs indicating their=20 > wireless=20 > > call volume continues to increase and is more than their wireline=20 > > volume. I've heard 45-50% wireless in some areas. Many PSAPs have=20 > > separate trunks for wireline and wireless. This is not a=20 > small problem. > >=20 > > Delaine M. Arnold, ENP > > Independent Consultant > > Chair, NENA Data Technical Committee > > Voice: 813-960-1698 > > Fax: 309-412-7821 > > Email: dmarnold@verizon.net > > =20 > > "The finish line is just the beginning." > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Winterbottom, James > > Sent: Thursday, February 02, 2006 4:57 PM > > To: Brian Rosen; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > > Ooopss... I meant to add whether this was a 5% outlying=20 > problem, or a=20 > > significant proportion of jurisdictions? > >=20 > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >> Behalf > > Of > >> Brian Rosen > >> Sent: Friday, 3 February 2006 8:17 AM > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Wireline vs wireless routing > >> > >> A subtle problem that may give rise to another requirement=20 > is that in=20 > >> some areas a true moble client has different routing than=20 > a wireline=20 > >> client. The psap service boundaies are different depending on what > > you > >> are calling on. It may be that this difference fades over=20 > time, but > > its > >> clearly different in some areas today. > >> > >> Brian > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > ---- > > -------------------- > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > >=20 > ---------------------------------------------------------------------- > > -- > > ---- > > -------------------- > > [mf2] > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > Subject: > > NJ Questions > > From: > > "Gojanovich, Robert" > > Date: > > Fri, 3 Feb 2006 13:46:44 -0500 > > To: > > "Rollender, Douglas Harold (Douglas)" > >=20 > > To: > > "Rollender, Douglas Harold (Douglas)" > > CC: > > "Abbott, Nadine B" > >=20 > >=20 > > Doug, > >=20 > > Nadine forwarded me your questions (I am not on the ecrit=20 > list server). > Answers below. > >=20 > > Follow up questions for Gojo on the NJ scenario - > >=20 > > 1) How does the county PSAP know which local PSAP is to receive the=20 > > call > if the caller location data is not available from the ESME to=20 > the state/county PSAP until after the call arrives? Gojo: It=20 > doesn't. Until the call is answered and the location arrives=20 > or is provided by the caller, no one knows where the call came from. > >=20 > > 2) Is it really safer and faster to deliver the call initially to a > state/county PSAP without the location data and then transfer=20 > the call to the town PSAP after the either (a) data message=20 > arrives from the ESME to the state/county PSAP or (b) the=20 > caller is asked to provide the location information verbally,=20 > the state/county PSAP call taker does a "manual" data look-up=20 > and then signals a call transfer? Gojo: You have no caller=20 > location until after the call is answered. This is the legacy=20 > of NCAS thinking. The original design in J-Std-036 called for=20 > the location information to be sent as a TCAP message over=20 > SS7 as part of the call setup. Three things, unfortunately,=20 > were missing: 1) ALI databases are not SCPs and are not on=20 > the SS7 network, 2) most 9-1-1 networks did not support SS7=20 > at the time, and > 3) The location technology can't derive location that fast.=20 > In wireline compatibility mode deployments, it is possible=20 > for the MPC to receive some locations fast enough to affe ct! > > (ESRK selection) routing (at least, that is what they=20 > claim), but NJ > implemented CAS for Phase 1 and NCAS (J-std terminology,=20 > formerly called > HCAS) for Phase 2. > >=20 > > The NJ system does have the potential to route on location. The > architecture includes a data link between the SR and the ALI.=20 > When a wireless call hits the SR, a message containing the=20 > ESRD and CBN is sent to the ALI. The ALI immediately launches=20 > a query to the MPC. It was designed so that when the=20 > coordinate routing feature was implemented, the SR would wait > 2-3 seconds before completing the call to the PSAP. In that=20 > time, the ESME would query the MPC, acquire the coordinates=20 > and translate to the precise ESN. The ESN would be sent to=20 > the SR to be used for routing. If the ALI did not respond in=20 > 2-3 seconds, say, the SR would go ahead and route the call=20 > based on the ESRD (cell sector). Since the PDEs can't deliver=20 > fast enough on a consistent basis, the State hasn't yet=20 > bought the feature. > >=20 > > You have two choices: Route the call to the County/State or=20 > route the=20 > > call > to the municipality where the cell is located. Either way=20 > will result in some number of transfers. The municipal PSAPs,=20 > for the most part, are too small to deal with a high volume=20 > of calls from outside their jurisdiction and don't want calls=20 > unless they belong to them. Unless it can be determined with=20 > some certainty that the caller is within their jurisdiction,=20 > they will refuse to answer the calls. This forces the call to=20 > the next wrung on the ladder, be it County or State. > >=20 > > It is no more unsafe to send the call to the County for=20 > them to screen=20 > > and > transfer to the appropriate PSAP, than it is to send the call=20 > to the municipal PSAP where it still has to be screened and,=20 > in many cases, transferred. Sending all calls to the County=20 > provides for consistency and some predictability. It also=20 > allows the County to screen out redundant and non-emergency=20 > calls that the local PSAPs are too small to handle in many,=20 > many cases. > >=20 > > 3) Does the call data (ESME data as well as interview information=20 > > entered > manually such as caller location) automatically follow the=20 > call, is it sent separately, "pulled" by the local call taker=20 > from a central data source after the call arrives at the=20 > local PSAP or not delivered at all? If data is sent=20 > separately, how is data delivery ensured to the same call=20 > taker that receives the call? Gojo: The data delivered=20 > through the ESME will follow the call, sort of, and will=20 > often be updated. The PSAP that receives the transfer does=20 > not get ALI data from the first PSAP, it does its own dip to=20 > the ALI database using the ESRK, ESRD or CBN. This dip will=20 > generate a new position request to the MPC, so the location=20 > data received at the second PSAP may be different than that=20 > received by the first PSAP. The Phase 1 data will be the same=20 > but the lat/long may be different. > >=20 > > Ancillary information acquired from the caller is usually=20 > given to the > second PSAP verbally. Very few PSAPs have links between CAD=20 > systems to do that automatically. Most of that data flow is verbal. > >=20 > > Gojo > >=20 > > Robert K. Gojanovich, ENP > > Director > > iXP Corporation > >=20 > > 609-406-7625 Direct Dial > >=20 > > 215-435-0703 Mobile > >=20 > > 609-406-7699 Fax > >=20 > > rgojo@ixpcorp.com > >=20 > > www.ixpcorp.com > >=20 > > iXP Corporation... Problem Solved > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 03 18:25:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5AIZ-0003J2-UR; Fri, 03 Feb 2006 18:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5AIT-0002ww-41 for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 18:25:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26076 for ; Fri, 3 Feb 2006 18:23:12 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5AU1-0003qt-MK for ecrit@ietf.org; Fri, 03 Feb 2006 18:36:54 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F5AI3-0005BA-CX; Fri, 03 Feb 2006 17:24:32 -0600 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Henning Schulzrinne'" , "'Rollender, Douglas Harold \(Douglas\)'" Subject: RE: [Ecrit] Wireline vs wireless routing Date: Fri, 3 Feb 2006 18:20:39 -0500 Message-ID: <011501c62918$74cacec0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYpDXYj3ugQSc/6SAGor6tUKwolOQAAR9MgAACpJbAAAWYa4AAASENA In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3010F9591@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 Content-Transfer-Encoding: 7bit Cc: RGojo@iXPCorp.com, 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If the call is up, it stays up. No one is suggesting you drop it. Yes, redialing might change the route. Moving and redialing might change the route. The end result is the same responders go; you don't get two responders for one actual location. It definitely is the case that if you move, you may get beyond the range of the responder dispatched, although in most cases they know how to get the right thing to happen. This IS the reality today. The only thing we really get to do is to bet on whether the differences will disappear before we deploy the ecrit mechanism. I'd say, not a good thing to bet that they will. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, February 03, 2006 6:12 PM To: br@brianrosen.net; Henning Schulzrinne; Rollender, Douglas Harold (Douglas) Cc: RGojo@iXPCorp.com; ECRIT Subject: RE: [Ecrit] Wireline vs wireless routing So, if a phone switches from wireline (WiFi) to wireless (GSM) or vice versa, do the PSAPs have to change also? I know some are suggesting that the call can not switch networks when on 911, but the alternative is when one moves beyond radio coverage the call gets dropped. Redialing the call will go to a different PSAP. So, I guess you get two [fill in your emergency responder here] sent to your location. I think that will last as long as the emergency organizations have money to burn. Mike > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Friday, February 03, 2006 5:30 PM > To: br@brianrosen.net; 'Henning Schulzrinne'; 'Rollender, > Douglas Harold (Douglas)' > Cc: RGojo@iXPCorp.com; 'ECRIT' > Subject: RE: [Ecrit] Wireline vs wireless routing > > Sorry, dropped a "'t". I meant to say that you CAN'T route a > wireless call with the wireline polygon set. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Friday, February 03, 2006 5:19 PM > To: 'Henning Schulzrinne'; 'Rollender, Douglas Harold (Douglas)' > Cc: RGojo@iXPCorp.com; 'ECRIT' > Subject: RE: [Ecrit] Wireline vs wireless routing > > I do not agree. > > While you can argue that the route is wrong it IS the route, > and you can't > say "but I can send it to the right place". > > The reality is that there is a set of wireline polygons and a > set of wireless polygons, and they are different. Wishing > they were not isn't helpful. You can route a wireless call > with the wireline polygon set. > > Eventually, this situation will resolve itself, but I think > we will deploy before it does. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Henning Schulzrinne > Sent: Friday, February 03, 2006 4:57 PM > To: Rollender, Douglas Harold (Douglas) > Cc: RGojo@iXPCorp.com; ECRIT > Subject: Re: [Ecrit] Wireline vs wireless routing > > The conclusion, however, seems to be that routing is, in all > cases, based on currently-available location information, > just that a wireless call may end up in the wrong place > initially due to the limitations of that initial location > fix. This seems to indicate that no new mechanisms in the > mapping protocol are required. > > Rollender, Douglas Harold (Douglas) wrote: > > Reply to follow-up questions from Gojo attached. > > > > Gojo, > > > > Thanks for further clarification on difference in routing between > > wireless > and wireline. Not sure how ECRIT may use the information > except we can anticipate needing to support the same routing > scenarios for voice and data and the same location functions > and performance characteristics in future access networks. > > > > Doug > > > > Douglas Rollender > > Lucent Technologies > > Wireless Standards Development and Industry Relations > > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf > > Of Rollender, Douglas Harold (Douglas) > > Sent: Friday, February 03, 2006 10:58 AM > > To: Abbott, Nadine B; ECRIT > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > > > Follow up questions for Gojo on the NJ scenario - > > > > 1) How does the county PSAP know which local PSAP is to receive the > > call > if the caller location data is not available from the ESME to > the state/county PSAP until after the call arrives? > > > > 2) Is it really safer and faster to deliver the call initially to a > state/county PSAP without the location data and then transfer > the call to the town PSAP after the either (a) data message > arrives from the ESME to the state/county PSAP or (b) the > caller is asked to provide the location information verbally, > the state/county PSAP call taker does a "manual" data look-up > and then signals a call transfer? > > > > 3) Does the call data (ESME data as well as interview information > > entered > manually such as caller location) automatically follow the > call, is it sent separately, "pulled" by the local call taker > from a central data source after the call arrives at the > local PSAP or not delivered at all? If data is sent > separately, how is data delivery ensured to the same call > taker that receives the call? > > > > Doug > > > > Douglas Rollender > > Lucent Technologies > > Wireless Standards Development and Industry Relations > > TN=973 386-4560, FAX=973 386-4555, Mobile=908-963-7965 > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf > > Of Abbott, Nadine B > > Sent: Friday, February 03, 2006 9:29 AM > > To: ECRIT > > Subject: FW: [Ecrit] Wireline vs wireless routing > > > > > > Some clarifications > > > > -----Original Message----- > > From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] > > Sent: Thursday, February 02, 2006 8:44 PM > > To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom, > James; Brian > > Rosen > > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > This is just an "application of terminology" problem. > > > > Its not that PSAP routing is intentionally different for > wireline vs > > wireless, it has to do with how granular you can get in > your routing > > decisions. The PSAP that dispatches emergency services is > the same for > > both callers, but the PSAP that gets the call initially may be > > different. > > > > NJ is a good example of how this plays out. NJ has 230 > PSAPs covering > > the 21 counties. Many PSAPs serve a single municipality and several > > counties in NJ have more than 20 PSAPs with no county-level PSAP. > > Let's say I place a cell tower on the roof of 4 Skiles Ave in > > Piscataway. The street address for that tower is 4 Skiles > Ave which, > > according to the MSAG, would be routed to the Piscataway PD PSAP. > > Unfortunately, the cell tower, with a 5 mile serving radius, serves > > callers in 4 or 5 neighboring towns as well as Piscataway. > > > > I need to route calls from this cell to a County or State > Police PSAP > > that is set up to answer from a wider area. To do that, we > created the > > State of XX in the MSAG, so that 4 Skiles Ave, Piscataway, > XX could be > > assigned a different ESN and be routed to a different PSAP. > > > > If the caller turns out to be in Piscataway, the call is > transferred > > from the County/State PSAP to Piscataway PD for > dispatching. The point > > is that the wireless caller may be routed to a different > PSAP out of > > necessity, but the call will ultimately end up at the PSAP > serving the > > caller's location. > > > > Why not route the call based on the caller's actual > location? Because, > > generally speaking, the location data is not derived or > delivered fast > > enough to be usable for routing. We'd have to place the caller in > > queue and play cheesy elevator music until the location could be > > derived, delivered and translated to an ESN. That probably > wouldn't be popular. > > Wireless callers already have to wait longer to reach 9-1-1 than > > wireline callers simply because wireless calls take longer > to set up, > > particularly if RF channels are not immediately available. > Over time, > > as the technology matures, routing on location will become the norm > > and the need to route differently will go away. > > > > I hope no one considers this type of routing a viable > option for VoIP. > > We did it for wireless because we had to, not because we wanted to. > > > > Gojo > > > > Robert K. Gojanovich, ENP > > Director > > iXP Corporation > > 609-406-7625 Direct Dial > > 215-435-0703 Mobile > > 609-406-7699 Fax > > rgojo@ixpcorp.com > > www.ixpcorp.com > > iXP Corporation... Problem Solved > > > > -----Original Message----- > > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > > Sent: Thursday, February 02, 2006 7:31 PM > > To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen > > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT); > > Gojanovich, Robert > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > Brian, > > > > Perhaps you can clarify with some examples of what you mean about > > different routing of wireline and wireless callers? I've > never heard > > before that for the very same location, emergency calls routed to a > > given PSAP would be dispatched differently, with different > emergency > > responders for wireline and wireless. > > > > However, I have heard of examples of different routing to different > > answering points/PSAPs for wireless calls based on access type and > > location, like the following. > > In California, wireless calls used to be routed to the > Highway Patrol, > > but this began phasing out several years ago. Likewise, in other > > states, like NJ, wireless calls were routed to a central > PSAP because > > of the high volumes and the need to handle the traffic slightly > > differently, at least partly because of location-related > concerns. But > > I believe that these kind of arrangements are being phased > out as most > > areas are at least moving toward implementation of Wireless Phase I > > and Phase II, and are enabling wireless calls to be appropriately > > routed to a PSAP based on location. However, wireless calls may be > > routed based on primary PSAP serving area, because the granularity > > (down to information that identifies the appropriate emergency > > resources to be dispatched, i.e., ESZ) may not be available > for wireless p-ANIs. > > > > As Delaine mentions, there are sometimes different trunk > groups to the > > PSAP also for wireline and wireless, but I think that this > is to help > > the PSAP ensure that volumes and bursts of calls from mobiles won't > > swamp out emergency service to wireline callers, not > because they were > > routed differently? > > > > Nadine > > > > P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and > Paul Stoffels > > to this thread because they have a wealth of experience to > add to this > > discussion, I expect. > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Delaine M Arnold ENP > > Sent: Thursday, February 02, 2006 6:28 PM > > To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > I've heard some numbers from various PSAPs indicating their > wireless > > call volume continues to increase and is more than their wireline > > volume. I've heard 45-50% wireless in some areas. Many PSAPs have > > separate trunks for wireline and wireless. This is not a > small problem. > > > > Delaine M. Arnold, ENP > > Independent Consultant > > Chair, NENA Data Technical Committee > > Voice: 813-960-1698 > > Fax: 309-412-7821 > > Email: dmarnold@verizon.net > > > > "The finish line is just the beginning." > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Winterbottom, James > > Sent: Thursday, February 02, 2006 4:57 PM > > To: Brian Rosen; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > > > > Ooopss... I meant to add whether this was a 5% outlying > problem, or a > > significant proportion of jurisdictions? > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf > > Of > >> Brian Rosen > >> Sent: Friday, 3 February 2006 8:17 AM > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Wireline vs wireless routing > >> > >> A subtle problem that may give rise to another requirement > is that in > >> some areas a true moble client has different routing than > a wireline > >> client. The psap service boundaies are different depending on what > > you > >> are calling on. It may be that this difference fades over > time, but > > its > >> clearly different in some areas today. > >> > >> Brian > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > ---------------------------------------------------------------------- > > -- > > ---- > > -------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > > ---------------------------------------------------------------------- > > -- > > ---- > > -------------------- > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > Subject: > > NJ Questions > > From: > > "Gojanovich, Robert" > > Date: > > Fri, 3 Feb 2006 13:46:44 -0500 > > To: > > "Rollender, Douglas Harold (Douglas)" > > > > To: > > "Rollender, Douglas Harold (Douglas)" > > CC: > > "Abbott, Nadine B" > > > > > > Doug, > > > > Nadine forwarded me your questions (I am not on the ecrit > list server). > Answers below. > > > > Follow up questions for Gojo on the NJ scenario - > > > > 1) How does the county PSAP know which local PSAP is to receive the > > call > if the caller location data is not available from the ESME to > the state/county PSAP until after the call arrives? Gojo: It > doesn't. Until the call is answered and the location arrives > or is provided by the caller, no one knows where the call came from. > > > > 2) Is it really safer and faster to deliver the call initially to a > state/county PSAP without the location data and then transfer > the call to the town PSAP after the either (a) data message > arrives from the ESME to the state/county PSAP or (b) the > caller is asked to provide the location information verbally, > the state/county PSAP call taker does a "manual" data look-up > and then signals a call transfer? Gojo: You have no caller > location until after the call is answered. This is the legacy > of NCAS thinking. The original design in J-Std-036 called for > the location information to be sent as a TCAP message over > SS7 as part of the call setup. Three things, unfortunately, > were missing: 1) ALI databases are not SCPs and are not on > the SS7 network, 2) most 9-1-1 networks did not support SS7 > at the time, and > 3) The location technology can't derive location that fast. > In wireline compatibility mode deployments, it is possible > for the MPC to receive some locations fast enough to affe ct! > > (ESRK selection) routing (at least, that is what they > claim), but NJ > implemented CAS for Phase 1 and NCAS (J-std terminology, > formerly called > HCAS) for Phase 2. > > > > The NJ system does have the potential to route on location. The > architecture includes a data link between the SR and the ALI. > When a wireless call hits the SR, a message containing the > ESRD and CBN is sent to the ALI. The ALI immediately launches > a query to the MPC. It was designed so that when the > coordinate routing feature was implemented, the SR would wait > 2-3 seconds before completing the call to the PSAP. In that > time, the ESME would query the MPC, acquire the coordinates > and translate to the precise ESN. The ESN would be sent to > the SR to be used for routing. If the ALI did not respond in > 2-3 seconds, say, the SR would go ahead and route the call > based on the ESRD (cell sector). Since the PDEs can't deliver > fast enough on a consistent basis, the State hasn't yet > bought the feature. > > > > You have two choices: Route the call to the County/State or > route the > > call > to the municipality where the cell is located. Either way > will result in some number of transfers. The municipal PSAPs, > for the most part, are too small to deal with a high volume > of calls from outside their jurisdiction and don't want calls > unless they belong to them. Unless it can be determined with > some certainty that the caller is within their jurisdiction, > they will refuse to answer the calls. This forces the call to > the next wrung on the ladder, be it County or State. > > > > It is no more unsafe to send the call to the County for > them to screen > > and > transfer to the appropriate PSAP, than it is to send the call > to the municipal PSAP where it still has to be screened and, > in many cases, transferred. Sending all calls to the County > provides for consistency and some predictability. It also > allows the County to screen out redundant and non-emergency > calls that the local PSAPs are too small to handle in many, > many cases. > > > > 3) Does the call data (ESME data as well as interview information > > entered > manually such as caller location) automatically follow the > call, is it sent separately, "pulled" by the local call taker > from a central data source after the call arrives at the > local PSAP or not delivered at all? If data is sent > separately, how is data delivery ensured to the same call > taker that receives the call? Gojo: The data delivered > through the ESME will follow the call, sort of, and will > often be updated. The PSAP that receives the transfer does > not get ALI data from the first PSAP, it does its own dip to > the ALI database using the ESRK, ESRD or CBN. This dip will > generate a new position request to the MPC, so the location > data received at the second PSAP may be different than that > received by the first PSAP. The Phase 1 data will be the same > but the lat/long may be different. > > > > Ancillary information acquired from the caller is usually > given to the > second PSAP verbally. Very few PSAPs have links between CAD > systems to do that automatically. Most of that data flow is verbal. > > > > Gojo > > > > Robert K. Gojanovich, ENP > > Director > > iXP Corporation > > > > 609-406-7625 Direct Dial > > > > 215-435-0703 Mobile > > > > 609-406-7699 Fax > > > > rgojo@ixpcorp.com > > > > www.ixpcorp.com > > > > iXP Corporation... Problem Solved > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 09:52:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5Olz-0000TP-0n; Sat, 04 Feb 2006 09:52:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5C8i-0008Fu-19 for ecrit@megatron.ietf.org; Fri, 03 Feb 2006 20:23:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15963 for ; Fri, 3 Feb 2006 20:21:12 -0500 (EST) Received: from ixpvpn.ixpcorp.com ([151.204.176.206] helo=lawexch01.ixpcorp.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5CKD-0003Fu-VE for ecrit@ietf.org; Fri, 03 Feb 2006 20:34:54 -0500 Content-Class: urn:content-classes:message Subject: RE: [Ecrit] Wireline vs wireless routing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Feb 2006 20:22:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: <769F4DDF781FA641A3D06A0872E27271013FE15A@lawexch01.ixpcorp.com> Thread-Topic: [Ecrit] Wireline vs wireless routing thread-index: AcYpDXYj3ugQSc/6SAGor6tUKwolOQAAR9MgAACpJbAAAWYa4AADnfPg From: "Gojanovich, Robert" To: "Michael Hammer \(mhammer\)" , , "Henning Schulzrinne" , "Rollender, Douglas Harold \(Douglas\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 87e958510a39f65fbeb5ae8b5e360e3b Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 04 Feb 2006 09:52:21 -0500 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If you are moving fast enough that an immediate second call goes to a different PSAP, either you are the extremely rare abductee, or you are not the person with the emergency. The calls that have gotten the most bad press have been from people who were not moving - the paraplegic stuck on a railroad crossing; the salesman upside down in a gully off the interstate and bleeding from his femoral artery; the woman drowning in her Beemer in a swamp right off the Florida turnpike - all because their location was not known. I would concentrate on the main problem. There will always be special circumstances or movement that cause some calls to fail despite our best efforts. Don't let worrying about them get in the way of the greater solution. To answer Mike's hypothetical question directly... If I dial 9-1-1 while on the WiFi network, and the location of the WiFi hub is delivered with the call, along with the serving radius (let's say 30 meters), that call will probably be routed to the local, "serving" (meaning, where services are dispatched) PSAP. Looks like wireline. Also looks like a pico cell on the wireless side. If the caller moves down the street out of WiFi range and onto a GSM network, The TDOA location technology in the GSM network will triangulate the caller's location and deliver it to the designated PSAP for the cell sector used. That may be a different PSAP than the "serving" PSAP. However, the calltaker at the designated PSAP will look at the location info delivered, interrogate the caller to confirm his/her location, and transfer the call to the "serving" PSAP. (The designated PSAP in this scenario does not dispatch anything, so two responders will not show up.) The serving PSAP will automatically perform its own ALI dip, which will look like a Rebid to the MPC, and the serving PSAP may then receive updated location data. The rest of the information will be relayed from the designated PSAP to the serving PSAP verbally. Bada Bing, Bada Boom. Just to argue with Brian a little (a guy needs a hobby), you CAN route wireless calls using wireline polygons. The downside is that the cell coverage is bigger than the polygon, so the recipient of the calls has to be prepared to transfer them to someone else. Small, municipal PSAPs don't want to deal with that extra work load. They'd rather have the County or State Police screen it for them. In the case of short-range WiFi or pico cells (which generally have a range of 150 meters and are installed to specifically serve readily identifiable hotel lobbies, one wing of a mall, train station waiting room, etc.), you could absolutely use the wireline polygons for routing. This is an exception right now, but keep in mind that the trend is toward a larger number of smaller cells to maximize frequency utilization. There may come a time, very soon, where the average cell site is quite small, in which case, wireline polygons will work fine and we will be able to abandon this dual method. This is especially true in heavily populated areas, which are, after all, where the people are. Gojo Robert K. Gojanovich, ENP Director iXP Corporation 609-406-7625 Direct Dial 215-435-0703 Mobile 609-406-7699 Fax rgojo@ixpcorp.com www.ixpcorp.com iXP Corporation... Problem Solved -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Friday, February 03, 2006 6:12 PM To: br@brianrosen.net; Henning Schulzrinne; Rollender, Douglas Harold (Douglas) Cc: Gojanovich, Robert; ECRIT Subject: RE: [Ecrit] Wireline vs wireless routing So, if a phone switches from wireline (WiFi) to wireless (GSM) or vice versa, do the PSAPs have to change also? I know some are suggesting that the call can not switch networks when on 911, but the alternative is when one moves beyond radio coverage the call gets dropped. Redialing the call will go to a different PSAP. So, I guess you get two [fill in your emergency responder here] sent to your location. I think that will last as long as the emergency organizations have money to burn. Mike =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Friday, February 03, 2006 5:30 PM > To: br@brianrosen.net; 'Henning Schulzrinne'; 'Rollender,=20 > Douglas Harold (Douglas)' > Cc: RGojo@iXPCorp.com; 'ECRIT' > Subject: RE: [Ecrit] Wireline vs wireless routing >=20 > Sorry, dropped a "'t". I meant to say that you CAN'T route a=20 > wireless call with the wireline polygon set. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Friday, February 03, 2006 5:19 PM > To: 'Henning Schulzrinne'; 'Rollender, Douglas Harold (Douglas)' > Cc: RGojo@iXPCorp.com; 'ECRIT' > Subject: RE: [Ecrit] Wireline vs wireless routing >=20 > I do not agree. >=20 > While you can argue that the route is wrong it IS the route,=20 > and you can't > say "but I can send it to the right place". =20 >=20 > The reality is that there is a set of wireline polygons and a=20 > set of wireless polygons, and they are different. Wishing=20 > they were not isn't helpful. You can route a wireless call=20 > with the wireline polygon set. >=20 > Eventually, this situation will resolve itself, but I think=20 > we will deploy before it does. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: Friday, February 03, 2006 4:57 PM > To: Rollender, Douglas Harold (Douglas) > Cc: RGojo@iXPCorp.com; ECRIT > Subject: Re: [Ecrit] Wireline vs wireless routing >=20 > The conclusion, however, seems to be that routing is, in all=20 > cases, based on currently-available location information,=20 > just that a wireless call may end up in the wrong place=20 > initially due to the limitations of that initial location=20 > fix. This seems to indicate that no new mechanisms in the=20 > mapping protocol are required. >=20 > Rollender, Douglas Harold (Douglas) wrote: > > Reply to follow-up questions from Gojo attached. > >=20 > > Gojo, > >=20 > > Thanks for further clarification on difference in routing between=20 > > wireless > and wireline. Not sure how ECRIT may use the information=20 > except we can anticipate needing to support the same routing=20 > scenarios for voice and data and the same location functions=20 > and performance characteristics in future access networks. > >=20 > > Doug > >=20 > > Douglas Rollender > > Lucent Technologies > > Wireless Standards Development and Industry Relations > > TN=3D973 386-4560, FAX=3D973 386-4555, Mobile=3D908-963-7965 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org]On Behalf=20 > > Of Rollender, Douglas Harold (Douglas) > > Sent: Friday, February 03, 2006 10:58 AM > > To: Abbott, Nadine B; ECRIT > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > >=20 > > Follow up questions for Gojo on the NJ scenario - > >=20 > > 1) How does the county PSAP know which local PSAP is to receive the=20 > > call > if the caller location data is not available from the ESME to=20 > the state/county PSAP until after the call arrives? > >=20 > > 2) Is it really safer and faster to deliver the call initially to a > state/county PSAP without the location data and then transfer=20 > the call to the town PSAP after the either (a) data message=20 > arrives from the ESME to the state/county PSAP or (b) the=20 > caller is asked to provide the location information verbally,=20 > the state/county PSAP call taker does a "manual" data look-up=20 > and then signals a call transfer? =20 > >=20 > > 3) Does the call data (ESME data as well as interview information=20 > > entered > manually such as caller location) automatically follow the=20 > call, is it sent separately, "pulled" by the local call taker=20 > from a central data source after the call arrives at the=20 > local PSAP or not delivered at all? If data is sent=20 > separately, how is data delivery ensured to the same call=20 > taker that receives the call? > >=20 > > Doug > >=20 > > Douglas Rollender > > Lucent Technologies > > Wireless Standards Development and Industry Relations > > TN=3D973 386-4560, FAX=3D973 386-4555, Mobile=3D908-963-7965 > >=20 > >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org]On Behalf=20 > > Of Abbott, Nadine B > > Sent: Friday, February 03, 2006 9:29 AM > > To: ECRIT > > Subject: FW: [Ecrit] Wireline vs wireless routing > >=20 > >=20 > > Some clarifications > >=20 > > -----Original Message----- > > From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] > > Sent: Thursday, February 02, 2006 8:44 PM > > To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom,=20 > James; Brian=20 > > Rosen > > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > > This is just an "application of terminology" problem. > >=20 > > Its not that PSAP routing is intentionally different for=20 > wireline vs=20 > > wireless, it has to do with how granular you can get in=20 > your routing=20 > > decisions. The PSAP that dispatches emergency services is=20 > the same for=20 > > both callers, but the PSAP that gets the call initially may be=20 > > different. > >=20 > > NJ is a good example of how this plays out. NJ has 230=20 > PSAPs covering=20 > > the 21 counties. Many PSAPs serve a single municipality and several=20 > > counties in NJ have more than 20 PSAPs with no county-level PSAP.=20 > > Let's say I place a cell tower on the roof of 4 Skiles Ave in=20 > > Piscataway. The street address for that tower is 4 Skiles=20 > Ave which,=20 > > according to the MSAG, would be routed to the Piscataway PD PSAP.=20 > > Unfortunately, the cell tower, with a 5 mile serving radius, serves=20 > > callers in 4 or 5 neighboring towns as well as Piscataway. > >=20 > > I need to route calls from this cell to a County or State=20 > Police PSAP=20 > > that is set up to answer from a wider area. To do that, we=20 > created the=20 > > State of XX in the MSAG, so that 4 Skiles Ave, Piscataway,=20 > XX could be=20 > > assigned a different ESN and be routed to a different PSAP. > >=20 > > If the caller turns out to be in Piscataway, the call is=20 > transferred=20 > > from the County/State PSAP to Piscataway PD for=20 > dispatching. The point=20 > > is that the wireless caller may be routed to a different=20 > PSAP out of=20 > > necessity, but the call will ultimately end up at the PSAP=20 > serving the=20 > > caller's location. > >=20 > > Why not route the call based on the caller's actual=20 > location? Because,=20 > > generally speaking, the location data is not derived or=20 > delivered fast=20 > > enough to be usable for routing. We'd have to place the caller in=20 > > queue and play cheesy elevator music until the location could be=20 > > derived, delivered and translated to an ESN. That probably=20 > wouldn't be popular. > > Wireless callers already have to wait longer to reach 9-1-1 than=20 > > wireline callers simply because wireless calls take longer=20 > to set up,=20 > > particularly if RF channels are not immediately available.=20 > Over time,=20 > > as the technology matures, routing on location will become the norm=20 > > and the need to route differently will go away. > >=20 > > I hope no one considers this type of routing a viable=20 > option for VoIP. > > We did it for wireless because we had to, not because we wanted to. > >=20 > > Gojo > >=20 > > Robert K. Gojanovich, ENP > > Director > > iXP Corporation > > 609-406-7625 Direct Dial > > 215-435-0703 Mobile > > 609-406-7699 Fax > > rgojo@ixpcorp.com > > www.ixpcorp.com > > iXP Corporation... Problem Solved > >=20 > > -----Original Message----- > > From: Abbott, Nadine B [mailto:nabbott@telcordia.com] > > Sent: Thursday, February 02, 2006 7:31 PM > > To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen > > Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT);=20 > > Gojanovich, Robert > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > > Brian, > >=20 > > Perhaps you can clarify with some examples of what you mean about=20 > > different routing of wireline and wireless callers? I've=20 > never heard=20 > > before that for the very same location, emergency calls routed to a=20 > > given PSAP would be dispatched differently, with different=20 > emergency=20 > > responders for wireline and wireless. > >=20 > > However, I have heard of examples of different routing to different=20 > > answering points/PSAPs for wireless calls based on access type and=20 > > location, like the following. > > In California, wireless calls used to be routed to the=20 > Highway Patrol,=20 > > but this began phasing out several years ago. Likewise, in other=20 > > states, like NJ, wireless calls were routed to a central=20 > PSAP because=20 > > of the high volumes and the need to handle the traffic slightly=20 > > differently, at least partly because of location-related=20 > concerns. But=20 > > I believe that these kind of arrangements are being phased=20 > out as most=20 > > areas are at least moving toward implementation of Wireless Phase I=20 > > and Phase II, and are enabling wireless calls to be appropriately=20 > > routed to a PSAP based on location. However, wireless calls may be=20 > > routed based on primary PSAP serving area, because the granularity=20 > > (down to information that identifies the appropriate emergency=20 > > resources to be dispatched, i.e., ESZ) may not be available=20 > for wireless p-ANIs. > > =20 > > As Delaine mentions, there are sometimes different trunk=20 > groups to the=20 > > PSAP also for wireline and wireless, but I think that this=20 > is to help=20 > > the PSAP ensure that volumes and bursts of calls from mobiles won't=20 > > swamp out emergency service to wireline callers, not=20 > because they were=20 > > routed differently? > > =20 > > Nadine > >=20 > > P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and=20 > Paul Stoffels=20 > > to this thread because they have a wealth of experience to=20 > add to this=20 > > discussion, I expect. > > =20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Delaine M Arnold ENP > > Sent: Thursday, February 02, 2006 6:28 PM > > To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > > I've heard some numbers from various PSAPs indicating their=20 > wireless=20 > > call volume continues to increase and is more than their wireline=20 > > volume. I've heard 45-50% wireless in some areas. Many PSAPs have=20 > > separate trunks for wireline and wireless. This is not a=20 > small problem. > >=20 > > Delaine M. Arnold, ENP > > Independent Consultant > > Chair, NENA Data Technical Committee > > Voice: 813-960-1698 > > Fax: 309-412-7821 > > Email: dmarnold@verizon.net > > =20 > > "The finish line is just the beginning." > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Winterbottom, James > > Sent: Thursday, February 02, 2006 4:57 PM > > To: Brian Rosen; ecrit@ietf.org > > Subject: RE: [Ecrit] Wireline vs wireless routing > >=20 > > Ooopss... I meant to add whether this was a 5% outlying=20 > problem, or a=20 > > significant proportion of jurisdictions? > >=20 > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >> Behalf > > Of > >> Brian Rosen > >> Sent: Friday, 3 February 2006 8:17 AM > >> To: ecrit@ietf.org > >> Subject: [Ecrit] Wireline vs wireless routing > >> > >> A subtle problem that may give rise to another requirement=20 > is that in=20 > >> some areas a true moble client has different routing than=20 > a wireline=20 > >> client. The psap service boundaies are different depending on what > > you > >> are calling on. It may be that this difference fades over=20 > time, but > > its > >> clearly different in some areas today. > >> > >> Brian > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > ---- > > -------------------- > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > >=20 > ---------------------------------------------------------------------- > > -- > > ---- > > -------------------- > > [mf2] > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > Subject: > > NJ Questions > > From: > > "Gojanovich, Robert" > > Date: > > Fri, 3 Feb 2006 13:46:44 -0500 > > To: > > "Rollender, Douglas Harold (Douglas)" > >=20 > > To: > > "Rollender, Douglas Harold (Douglas)" > > CC: > > "Abbott, Nadine B" > >=20 > >=20 > > Doug, > >=20 > > Nadine forwarded me your questions (I am not on the ecrit=20 > list server). > Answers below. > >=20 > > Follow up questions for Gojo on the NJ scenario - > >=20 > > 1) How does the county PSAP know which local PSAP is to receive the=20 > > call > if the caller location data is not available from the ESME to=20 > the state/county PSAP until after the call arrives? Gojo: It=20 > doesn't. Until the call is answered and the location arrives=20 > or is provided by the caller, no one knows where the call came from. > >=20 > > 2) Is it really safer and faster to deliver the call initially to a > state/county PSAP without the location data and then transfer=20 > the call to the town PSAP after the either (a) data message=20 > arrives from the ESME to the state/county PSAP or (b) the=20 > caller is asked to provide the location information verbally,=20 > the state/county PSAP call taker does a "manual" data look-up=20 > and then signals a call transfer? Gojo: You have no caller=20 > location until after the call is answered. This is the legacy=20 > of NCAS thinking. The original design in J-Std-036 called for=20 > the location information to be sent as a TCAP message over=20 > SS7 as part of the call setup. Three things, unfortunately,=20 > were missing: 1) ALI databases are not SCPs and are not on=20 > the SS7 network, 2) most 9-1-1 networks did not support SS7=20 > at the time, and > 3) The location technology can't derive location that fast.=20 > In wireline compatibility mode deployments, it is possible=20 > for the MPC to receive some locations fast enough to affe ct! > > (ESRK selection) routing (at least, that is what they=20 > claim), but NJ > implemented CAS for Phase 1 and NCAS (J-std terminology,=20 > formerly called > HCAS) for Phase 2. > >=20 > > The NJ system does have the potential to route on location. The > architecture includes a data link between the SR and the ALI.=20 > When a wireless call hits the SR, a message containing the=20 > ESRD and CBN is sent to the ALI. The ALI immediately launches=20 > a query to the MPC. It was designed so that when the=20 > coordinate routing feature was implemented, the SR would wait > 2-3 seconds before completing the call to the PSAP. In that=20 > time, the ESME would query the MPC, acquire the coordinates=20 > and translate to the precise ESN. The ESN would be sent to=20 > the SR to be used for routing. If the ALI did not respond in=20 > 2-3 seconds, say, the SR would go ahead and route the call=20 > based on the ESRD (cell sector). Since the PDEs can't deliver=20 > fast enough on a consistent basis, the State hasn't yet=20 > bought the feature. > >=20 > > You have two choices: Route the call to the County/State or=20 > route the=20 > > call > to the municipality where the cell is located. Either way=20 > will result in some number of transfers. The municipal PSAPs,=20 > for the most part, are too small to deal with a high volume=20 > of calls from outside their jurisdiction and don't want calls=20 > unless they belong to them. Unless it can be determined with=20 > some certainty that the caller is within their jurisdiction,=20 > they will refuse to answer the calls. This forces the call to=20 > the next wrung on the ladder, be it County or State. > >=20 > > It is no more unsafe to send the call to the County for=20 > them to screen=20 > > and > transfer to the appropriate PSAP, than it is to send the call=20 > to the municipal PSAP where it still has to be screened and,=20 > in many cases, transferred. Sending all calls to the County=20 > provides for consistency and some predictability. It also=20 > allows the County to screen out redundant and non-emergency=20 > calls that the local PSAPs are too small to handle in many,=20 > many cases. > >=20 > > 3) Does the call data (ESME data as well as interview information=20 > > entered > manually such as caller location) automatically follow the=20 > call, is it sent separately, "pulled" by the local call taker=20 > from a central data source after the call arrives at the=20 > local PSAP or not delivered at all? If data is sent=20 > separately, how is data delivery ensured to the same call=20 > taker that receives the call? Gojo: The data delivered=20 > through the ESME will follow the call, sort of, and will=20 > often be updated. The PSAP that receives the transfer does=20 > not get ALI data from the first PSAP, it does its own dip to=20 > the ALI database using the ESRK, ESRD or CBN. This dip will=20 > generate a new position request to the MPC, so the location=20 > data received at the second PSAP may be different than that=20 > received by the first PSAP. The Phase 1 data will be the same=20 > but the lat/long may be different. > >=20 > > Ancillary information acquired from the caller is usually=20 > given to the > second PSAP verbally. Very few PSAPs have links between CAD=20 > systems to do that automatically. Most of that data flow is verbal. > >=20 > > Gojo > >=20 > > Robert K. Gojanovich, ENP > > Director > > iXP Corporation > >=20 > > 609-406-7625 Direct Dial > >=20 > > 215-435-0703 Mobile > >=20 > > 609-406-7699 Fax > >=20 > > rgojo@ixpcorp.com > >=20 > > www.ixpcorp.com > >=20 > > iXP Corporation... Problem Solved > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 10:12:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5P5q-0007NM-7U; Sat, 04 Feb 2006 10:12:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5P5n-0007I5-Ig for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 10:12:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13359 for ; Sat, 4 Feb 2006 10:11:13 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5PHb-0006dz-NA for ecrit@ietf.org; Sat, 04 Feb 2006 10:25:03 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k14FCETs003395; Sat, 4 Feb 2006 09:12:14 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 4 Feb 2006 15:12:14 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB011E33E24@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Winterbottom, James'" , "'Brian Rosen'" , "'ecrit@ietf.org'" Subject: RE: [Ecrit] Wireline vs wireless routing Date: Sat, 4 Feb 2006 15:12:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If you really need to treat these cases special, then it is relatively easy to solve in the case where access cellphone over IMS, as by the time it reachs the routeing entity the request will be carrying a P-Access-Network-Info header (see RFC 3455) that will tell you it is a cellphone user. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org]On Behalf Of > Winterbottom, James > Sent: 02 February 2006 21:56 > To: Brian Rosen; ecrit@ietf.org > Subject: RE: [Ecrit] Wireline vs wireless routing > > > This could be a quite hard problem to solve indeed, since there is no > indication at all in PIDF-LO as to the access type. The > closest thing is > the , but it only tells you how location was > determined, not the > access media. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Brian Rosen > > Sent: Friday, 3 February 2006 8:17 AM > > To: ecrit@ietf.org > > Subject: [Ecrit] Wireline vs wireless routing > > > > A subtle problem that may give rise to another requirement > is that in > > some areas a true moble client has different routing than a wireline > > client. The psap service boundaies are different depending on what > you > > are calling on. It may be that this difference fades over time, but > its > > clearly different in some areas today. > > > > Brian > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 10:21:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5PEY-0002ox-UX; Sat, 04 Feb 2006 10:21:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5PET-0002nP-Jj for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 10:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13851 for ; Sat, 4 Feb 2006 10:20:01 -0500 (EST) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5PQ6-000726-Ri for ecrit@ietf.org; Sat, 04 Feb 2006 10:33:52 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k14FLN01017348 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 4 Feb 2006 10:21:24 -0500 (EST) In-Reply-To: <475FF955A05DD411980D00508B6D5FB011E33E24@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB011E33E24@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C6B90F1-F380-40F0-B8AC-36E0673A05A2@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Wireline vs wireless routing Date: Sat, 4 Feb 2006 10:21:22 -0500 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem is that the mapping protocol, presumably the location part, would also have to carry this information. Maybe the mapping protocol can just inherit the label string from the P-Access-Network header, to avoid creating yet another registry. On Feb 4, 2006, at 10:12 AM, Drage, Keith (Keith) wrote: > If you really need to treat these cases special, then it is > relatively easy to solve in the case where access cellphone over > IMS, as by the time it reachs the routeing entity the request will > be carrying a P-Access-Network-Info header (see RFC 3455) that will > tell you it is a cellphone user. > > regards > > Keith > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 13:55:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYq-0006ue-Kj; Sat, 04 Feb 2006 13:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYn-0006ke-Uy for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 13:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29177 for ; Sat, 4 Feb 2006 13:53:16 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5SkW-0008WN-NG for ecrit@ietf.org; Sat, 04 Feb 2006 14:07:10 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k14Isirp013366 for ; Sat, 4 Feb 2006 19:54:44 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k14Isiev031120 for ; Sat, 4 Feb 2006 19:54:44 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Feb 2006 19:54:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Feb 2006 19:54:44 +0100 Message-ID: Thread-Topic: Mapping Protocol: Next Steps Thread-Index: AcYpGBv7E12OLBVUSxegLPpLt+dS2A== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Feb 2006 18:54:44.0341 (UTC) FILETIME=[7662BA50:01C629BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Mapping Protocol: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 we spend a lot of time during the interim meeting to talk about the mapping protocol proposals. We had three proposals on the table:=20 LUMP: draft-schulzrinne-ecrit-lump-01.txt DNS-SOS: draft-rosen-dns-sos-03.txt ECON-IRIS: draft-hardie-ecrit-iris-03.txt Our discussions produced the following results: * The proposals LUMP and ECON-IRIS will be merged due to their similarity and a new proposal will be published before the IETF draft submission deadline.=20 * The work on the DNS-SOS proposal will be stopped. A hum showed lack of interest in moving the proposal forward.=20 The positive and negative aspects of the DNS-SOS proposal will be (or have already been) captured and will be input to the mapping protocol work in the future.=20 A number of details were discussed and need to be reflected in the yet-to-be-written mapping protocol document.=20 To make good progress with this work the chairs would like to know whether there is acceptance or resistance against the suggested way forward.=20 Ciao Hannes & Marc Ps: Please take a look at the published meeting minutes to learn more about the discussed aspects.=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 13:55:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYr-0006vU-2E; Sat, 04 Feb 2006 13:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYn-0006kj-S0 for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 13:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29173 for ; Sat, 4 Feb 2006 13:53:16 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5SkX-0008WV-Q1 for ecrit@ietf.org; Sat, 04 Feb 2006 14:07:10 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k14IskjU013378 for ; Sat, 4 Feb 2006 19:54:46 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k14Isjcw031134 for ; Sat, 4 Feb 2006 19:54:45 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Feb 2006 19:54:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Feb 2006 19:54:45 +0100 Message-ID: Thread-Topic: Meeting Minutes for the Interim Meeting Thread-Index: AcYpIFmmH70bf3G6TNiBLK0rPRpjxQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Feb 2006 18:54:45.0701 (UTC) FILETIME=[77323F50:01C629BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Meeting Minutes for the Interim Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 please find the meeting minutes at:=20 http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.html http://www.ietf-ecrit.org/Interim2006/MeetingMinutes.txt Slides can be found at:=20 http://www.ietf-ecrit.org/Interim2006/ Jabber logs can be found at: * Original: http://www.xmpp.org/ietf-logs/ecrit@ietf.xmpp.org/2006-02-01.html http://www.xmpp.org/ietf-logs/ecrit@ietf.xmpp.org/2006-02-02.html * Cache: http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-01.html http://www.ietf-ecrit.org/Interim2006/Jabber-Log_2006-02-02.html Deadline for modifications to the meeting minutes: 12. Feb. 2006 Thanks to Spencer and Andy for the meeting minutes and the jabber log! Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 13:55:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYr-0006wD-D5; Sat, 04 Feb 2006 13:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYn-0006kk-S9 for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 13:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29178 for ; Sat, 4 Feb 2006 13:53:16 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5SkW-0008WL-NO for ecrit@ietf.org; Sat, 04 Feb 2006 14:07:10 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k14IsivP013365 for ; Sat, 4 Feb 2006 19:54:44 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k14IsigM031116 for ; Sat, 4 Feb 2006 19:54:44 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Feb 2006 19:54:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Feb 2006 19:54:43 +0100 Message-ID: Thread-Topic: A Uniform Resource Name (URN) for Services: An ECRIT WG item? Thread-Index: AcYpFpV6Zsj0MFfsSSyjmLcIEnAN1A== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Feb 2006 18:54:43.0977 (UTC) FILETIME=[762B2F90:01C629BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] A Uniform Resource Name (URN) for Services: An ECRIT WG item? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, we have a charter item for identifying a session set-up request to an emergency response center. We have two proposals for this charter item:=20 http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-02.txt http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-01 .txt The idea of moving the draft-schulzrinne-sipping-service-01.txt document forward and to stop the work on draft-ietf-sipping-sos-02.txt was raised at the last IETF meeting and at the interim meeting. =20 Furthermore, a hum at the interim meeting indicated support for making the draft-schulzrinne-sipping-service-01.txt a working group item.=20 Please speak for or against making draft-schulzrinne-sipping-service-01.txt a working group item for the ECRIT working group.=20 Deadline for responding to this hum is the 14th February 2006. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 13:55:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYu-000719-Of; Sat, 04 Feb 2006 13:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYo-0006km-54 for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 13:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29183 for ; Sat, 4 Feb 2006 13:53:17 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5SkW-0008WJ-3c for ecrit@ietf.org; Sat, 04 Feb 2006 14:07:10 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k14IshV4011862 for ; Sat, 4 Feb 2006 19:54:44 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k14IshUJ011091 for ; Sat, 4 Feb 2006 19:54:43 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Feb 2006 19:54:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Feb 2006 19:54:43 +0100 Message-ID: Thread-Topic: Charter discussions and milestone adjustments Thread-Index: AcYpFPTeUHSw+1SXRGygbhM9EXjkdA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Feb 2006 18:54:43.0560 (UTC) FILETIME=[75EB8E80:01C629BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Charter discussions and milestone adjustments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 during the interim meeting we had time to review our charter. As part of the discussions we thought about aligning the charter milestones to the current work.=20 Here is the proposal we came up with:=20 ------- March 2006 Informational RFC containing terminology definitions and the requirements May 2006 An Informational document describing the threats and security considerations March 2006 A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Nov 2006 A Standards Track RFC describing how to route an emergency call based on location information ------- Please take a look at the updated completion date and also note that the number of milestone items was reduced.=20 New charter items will be added to the charter=20 * if we make progress with the existing work items AND * if there are concrete proposals (i.e., available drafts) (assuming interest by the group and area director approval -- obviously).=20 Please let us know if you agree or object with the proposed charter adjustment.=20 Deadline for responding: 20th February 2006 Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 13:55:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SZ0-0007CL-Ay; Sat, 04 Feb 2006 13:55:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYo-0006kl-3s for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 13:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29179 for ; Sat, 4 Feb 2006 13:53:16 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5SkW-0008WO-Oq for ecrit@ietf.org; Sat, 04 Feb 2006 14:07:10 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k14IsjB6013369 for ; Sat, 4 Feb 2006 19:54:45 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k14IsiO6011106 for ; Sat, 4 Feb 2006 19:54:44 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Feb 2006 19:54:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Feb 2006 19:54:44 +0100 Message-ID: Thread-Topic: Requirements Draft close to completion Thread-Index: AcYpGuOrlFGcU7rJQaS0Q/pkRe93rA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Feb 2006 18:54:44.0763 (UTC) FILETIME=[76A31EB0:01C629BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Requirements Draft close to completion X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 the first day of the interim meeting was spend to walk through the open issues of=20 draft-ietf-ecrit-requirements-02.txt. We were able to close ALL open issues. Thanks to all the participants. Roger has already incorporated the suggested changes into a new version and he submitted the document already. Please find it at http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-03.txt (before it appears in the IETF archive). Thank you Roger! To make sure that we have indeed addressed all open issues listed at=20 http://www.ietf-ecrit.org:8080/ecrit-req correctly we would like to ask everyone to review the document again and to ask those people who haven't had the chance to attend the interim meeting to carefully inspect whether their open issue was adequately addressed.=20 The next steps for this document are as follows: - Roger will add information to each requirement to indicate whether the RFC 2119 language refers to=20 (a) a requirement for an implementation or to (b) a requirement for usage He will then resubmit the document. Targeted resubmission date: next week=20 - We would then like to start a WGLC on the 20th February running for 2 weeks.=20 Since these goals are quite ambitious we would like to ask for your help. Please review the document as early as possible AND make constructive feedback (e.g., text suggestions instead of just stating 'i don't like it').=20 Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 13:58:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5ScJ-0000bA-Jn; Sat, 04 Feb 2006 13:58:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SYr-0006ko-Js for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 13:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29188 for ; Sat, 4 Feb 2006 13:53:17 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5SkX-0008WQ-AG for ecrit@ietf.org; Sat, 04 Feb 2006 14:07:10 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k14IsjGQ013375 for ; Sat, 4 Feb 2006 19:54:45 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k14IsjsM031126 for ; Sat, 4 Feb 2006 19:54:45 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Feb 2006 19:54:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Feb 2006 19:54:45 +0100 Message-ID: Thread-Topic: Threats and Security Requirements Draft Thread-Index: AcYpHLxHc07IsCmDTuqW4aGKTVSKFw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Feb 2006 18:54:45.0310 (UTC) FILETIME=[76F695E0:01C629BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Threats and Security Requirements Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 draft-taylor-ecrit-security-threats-01.txt was rewritten after the last IETF meeting. Still, the document has not met the expectation of the interim meeting participants.=20 The main problem with the current version of the document is its broad scope -- the document just covers too many things that are outside the scope of the working group.=20 The proposal was therefore to focus ONLY on the security threats and requirements of the=20 - mapping protocol and the - usage of emergency identifiers The new document will be considerably shorter. Tom has already started working on the document and a new version will be available during the next week.=20 Brian, Andy and Roger agreed to do a quick review immediately after the document gets published.=20 Since the document has already seen a lot of reshaping and restructuring the chairs hope that the next version will finally meet our expectation. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 14:01:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SfN-00029u-7y; Sat, 04 Feb 2006 14:01:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SfM-00028r-Gn for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 14:01:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29677 for ; Sat, 4 Feb 2006 14:00:00 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5Sr4-0000Y1-Ap for ecrit@ietf.org; Sat, 04 Feb 2006 14:13:54 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k14J1UNE017616 for ; Sat, 4 Feb 2006 20:01:30 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k14J1UAX003106 for ; Sat, 4 Feb 2006 20:01:30 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Feb 2006 20:01:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Feb 2006 20:01:12 +0100 Message-ID: Thread-Topic: Requirements Draft close to completion Thread-Index: AcYpGuOrlFGcU7rJQaS0Q/pkRe93rAAokvDg From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Feb 2006 19:01:30.0200 (UTC) FILETIME=[684BE580:01C629BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] AW: Requirements Draft close to completion X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 The issue tracker is currently empty since Roger closed all of them.=20 If you want to retrieve the full list of issues (including all closed = issues) please use the following link: http://www.ietf-ecrit.org:8080/ecrit-req/issue?:columns=3Did,activity,tit= le,creator,assignedto,status&:sort=3Did&:group=3Dstatus&:pagesize=3D50&:s= tartwith=3D0 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Tschofenig, Hannes=20 > Gesendet: Samstag, 4. Februar 2006 00:38 > An: 'ecrit@ietf.org' > Betreff: Requirements Draft close to completion >=20 > Hi all,=20 >=20 > the first day of the interim meeting was spend to walk=20 > through the open issues of=20 > draft-ietf-ecrit-requirements-02.txt. We were able to close=20 > ALL open issues. Thanks to all the participants. >=20 > Roger has already incorporated the suggested changes into a=20 > new version and he submitted the document already. Please=20 > find it at=20 > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements- > 03.txt (before it appears in the IETF archive). > Thank you Roger! >=20 > To make sure that we have indeed addressed all open issues listed at=20 > http://www.ietf-ecrit.org:8080/ecrit-req > correctly we would like to ask everyone to review the=20 > document again and to ask those people who haven't had the=20 > chance to attend the interim meeting to carefully inspect=20 > whether their open issue was adequately addressed.=20 >=20 > The next steps for this document are as follows: >=20 > - Roger will add information to each requirement to indicate=20 > whether the RFC 2119 language refers to=20 > (a) a requirement for an implementation or to > (b) a requirement for usage > He will then resubmit the document. Targeted resubmission=20 > date: next week=20 >=20 > - We would then like to start a WGLC on the 20th February=20 > running for 2 weeks.=20 >=20 > Since these goals are quite ambitious we would like to ask=20 > for your help. Please review the document as early as=20 > possible AND make constructive feedback (e.g., text=20 > suggestions instead of just stating 'i don't like it').=20 >=20 > Ciao > Hannes & Marc >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 14:08:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5Slq-0005JE-GJ; Sat, 04 Feb 2006 14:08:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5Slo-0005I1-9r for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 14:08:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00144 for ; Sat, 4 Feb 2006 14:06:38 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5SxT-0000qT-Co for ecrit@ietf.org; Sat, 04 Feb 2006 14:20:32 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k14J89G8012965 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 4 Feb 2006 14:08:09 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Charter discussions and milestone adjustments Date: Sat, 4 Feb 2006 14:08:07 -0500 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Suggestion: Please consider adding I-D names to charter items where these are known to exist, as this makes tracking easier (or, at least, align the charter items with the I-D titles). On Feb 4, 2006, at 1:54 PM, Tschofenig, Hannes wrote: > Hi all, > > during the interim meeting we had time to review our charter. As > part of > the discussions we thought about aligning the charter milestones to > the > current work. > > Here is the proposal we came up with: > > ------- > > March 2006 Informational RFC containing terminology > definitions and the requirements > > May 2006 An Informational document describing the threats > and security considerations > > March 2006 A Standards Track RFC describing how to identify > a session set-up request is to an emergency response center > > Nov 2006 A Standards Track RFC describing how to route an > emergency call based on location information > > ------- > > Please take a look at the updated completion date and also note > that the > number of milestone items was reduced. > > New charter items will be added to the charter > * if we make progress with the existing work items AND > * if there are concrete proposals (i.e., available drafts) > (assuming interest by the group and area director approval -- > obviously). > > Please let us know if you agree or object with the proposed charter > adjustment. > > Deadline for responding: 20th February 2006 > > Ciao > Hannes & Marc > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 04 15:26:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5TzJ-0000i8-BS; Sat, 04 Feb 2006 15:26:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5TzH-0000h1-0b for ecrit@megatron.ietf.org; Sat, 04 Feb 2006 15:26:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04779 for ; Sat, 4 Feb 2006 15:24:38 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5UAw-0004Ro-TB for ecrit@ietf.org; Sat, 04 Feb 2006 15:38:32 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k14KQCF7015994 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 4 Feb 2006 15:26:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <3E3BDDE4-7D26-4685-B899-7D66AB182080@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: Henning Schulzrinne Date: Sat, 4 Feb 2006 15:26:10 -0500 X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Ecrit] LUMP demo; need MSAG data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Wonsang Song, one of my grad students, has put up a demo of an early LUMP prototype at http://irtcluster01.cs.columbia.edu:8080/index.jsp?id=2 This is very much work in progress, but comments are appreciated. (The schema and other details will change as we merge ICON and LUMP.) We currently are supporting county-level data, using the Census polygons, pretending that each county has a PSAP. We'd much rather have more realistic data, so if you can share MSAG or polygon data, it would be very helpful for testing and making sure that we're handling various special cases correctly. We'll take any format, e.g., Excel spreadsheets for MSAG and Arcview for polygons. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 05 10:34:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5lto-0008Ev-AR; Sun, 05 Feb 2006 10:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5lth-0008Cw-6T for ecrit@megatron.ietf.org; Sun, 05 Feb 2006 10:33:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19393 for ; Sun, 5 Feb 2006 10:32:00 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5m5T-0003kK-0A for ecrit@ietf.org; Sun, 05 Feb 2006 10:46:04 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k15FW9Iu008844; Sun, 5 Feb 2006 09:32:10 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 5 Feb 2006 15:32:09 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB011E33E7D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Henning Schulzrinne , "Drage, Keith (Keith)" Subject: RE: [Ecrit] Wireline vs wireless routing Date: Sun, 5 Feb 2006 15:32:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Point taken - of course if the mapping is done by two separate databases (as per one of the comments) then this would not be an issue. regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 04 February 2006 15:21 > To: Drage, Keith (Keith) > Cc: 'Winterbottom, James'; 'Brian Rosen'; 'ecrit@ietf.org' > Subject: Re: [Ecrit] Wireline vs wireless routing > > > The problem is that the mapping protocol, presumably the location > part, would also have to carry this information. Maybe the mapping > protocol can just inherit the label string from the P-Access-Network > header, to avoid creating yet another registry. > > On Feb 4, 2006, at 10:12 AM, Drage, Keith (Keith) wrote: > > > If you really need to treat these cases special, then it is > > relatively easy to solve in the case where access cellphone over > > IMS, as by the time it reachs the routeing entity the request will > > be carrying a P-Access-Network-Info header (see RFC 3455) > that will > > tell you it is a cellphone user. > > > > regards > > > > Keith > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 05 11:09:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5mRv-0002PJ-BI; Sun, 05 Feb 2006 11:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5mRt-0002Lk-7o for ecrit@megatron.ietf.org; Sun, 05 Feb 2006 11:09:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22025 for ; Sun, 5 Feb 2006 11:07:26 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5mdm-0007jZ-A4 for ecrit@ietf.org; Sun, 05 Feb 2006 11:21:31 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k15G3wJu010863 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 5 Feb 2006 11:03:59 -0500 (EST) In-Reply-To: <475FF955A05DD411980D00508B6D5FB011E33E7D@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB011E33E7D@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Wireline vs wireless routing Date: Sun, 5 Feb 2006 11:03:49 -0500 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think the assumption has been that the mapping service would be run by either local authorities or their designates (service providers), or possibly the VSP (but they'd run just the resolver). On Feb 5, 2006, at 10:32 AM, Drage, Keith (Keith) wrote: > Point taken - of course if the mapping is done by two separate > databases (as per one of the comments) then this would not be an > issue. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 09 12:00:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7F9c-0001Di-LI; Thu, 09 Feb 2006 12:00:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7F9H-00017y-IJ for ecrit@megatron.ietf.org; Thu, 09 Feb 2006 12:00:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08599 for ; Thu, 9 Feb 2006 11:58:12 -0500 (EST) Received: from smtp01out.dot.gov ([199.79.179.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7FLz-00077m-Bi for ecrit@ietf.org; Thu, 09 Feb 2006 12:13:12 -0500 Received: from dothqnwms005.ad.dot.gov (152.119.86.155) by smtp01out.dot.gov with ESMTP; 09 Feb 2006 11:59:50 -0500 X-IronPort-AV: i="4.02,100,1139202000"; d="scan'208,217"; a="29557538:sNHT898639202" Received: from msgbrdg1.NED.NHTSA.AD ([152.119.106.183]) by DOTHQNWMS005.ad.dot.gov with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 11:59:50 -0500 Received: from MSGC2.NED.NHTSA.AD ([152.119.106.191]) by msgbrdg1.NED.NHTSA.AD with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Feb 2006 11:59:52 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Feb 2006 12:02:43 -0500 Message-ID: <9D25AF0E6FE1ED41A54215BC3E37772C0234E518@MSGC2.NED.NHTSA.AD> Thread-Topic: US DOT Next Generation 9-1-1 Project: Information and a Question Thread-index: AcYtmqSiFfMqAk4rSECJPw4svNWh2g== From: "Hansen, Jenny " To: X-OriginalArrivalTime: 09 Feb 2006 16:59:52.0415 (UTC) FILETIME=[3E8B06F0:01C62D9A] X-Spam-Score: 0.6 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Subject: [Ecrit] US DOT Next Generation 9-1-1 Project: Information and a Question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1780999251==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1780999251== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62D9A.A44C6330" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62D9A.A44C6330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My name is Jenny Hansen. I'm the Project Coordinator for the Next Generation 9-1-1 Project at the U.S. Department of Transportation.=20 We're in the early stages of the project and I'm developing a listserv for the project to insure we share the information for any agency (public or private) that may have mutual interest in what is occurring in this effort. I'm soliciting input, while offering project updates to our ListServ recipients, but I'd like to reach out to your membership at large. (I've included a copy of the original Email sent last month regarding the release of the Preliminary Concept of Operations document - a "user's document" of sorts). Is there a process we may follow to provide the information to your members? Additionally, if there is any option for us to share the information at one of your regional meetings or programs, we'd be happy to provide same. Any thoughts, suggestions or recommendations you have are truly appreciated. Thank you for your consideration. Jenny Hansen Jenny Hansen, Project Coordinator Next Generation 9-1-1 (NG 9-1-1) USDOT/NHTSA (202) 366-5598 Greetings and Happy New Year! You are receiving this information as a key member of public safety, telecommunications or professional industry that may have a mutual interest in the following project underway with the U.S. Department of Transportation (DOT). The Next Generation 9-1-1 Initiative is a DOT research and development project to define the system architecture and develop a transition plan that considers responsibilities, costs, schedule and benefits for deploying IP-based=20 9-1-1 services across the Nation. This project is leveraging work from DOT's earlier Wireless E9-1-1 Initiative, which has enhanced location capability for 9-1-1 calls placed from wireless phones.=20 To provide a bit of background for your consideration, I've included an excerpt of the NG9-1-1 Initiative which provides an overview of the NG9-1-1 Project phases. As follows: Next Generation 9-1-1 (NG9-1-1) Initiative. Working closely with the 9-1-1 stakeholders and industry, this research initiative, funded by the Intelligent Transportation System program, will produce a national architecture and deployment plan for the next generation of the 9-1-1 system (or system of systems); enabling access to the 9-1-1 network with most communication devices. This project is an $11 million dollar, 3-year initiative and will be completed in three phases.=20 * Telecommunication and 9-1-1 users and providers will be recruited to become actively involved in the process of determining operational policies and user requirements for an Internet/multimedia-capable 9-1-1 system.=20 * The NG9-1-1 system will be operationally defined. Based on this preliminary "ConOps" document, a variety of strategies will be used to develop user requirements for the NG9-1-1 system. * Finally, a design team/consortium will be tasked with completing a high-level architecture and a migration plan that can guide the transition from the present 9-1-1 system to the next generation of 9-1-1. The final documents, with a target deadline of 2008, will be made available to the public, and can serve as the basis for NG9-1-1 deployment plans. The NG9-1-1 Concept of Operations (ConOps) is a formal document that provides a user-oriented vision of NG9-1-1 within the context of an emergency services internetwork that can be understood by stakeholders with a broad range of operational and technical expertise. It is intended to communicate the vision of this system to stakeholders so that they can be actively engaged in its development and deployment. It also serves as the foundation for the development of the NG9-1-1 requirements and to drive the design of the overall system. This document will be updated throughout the NG9-1-1 Initiative effort, as the thinking related to the implementation of NG9-1-1 capabilities becomes clearer and more precise. It is expected that under procured work to design NG9-1-1 applications, this document will be used as supplemental information, and will be revisited and refined into a more comprehensive NG9-1-1 ConOps document.=20 You'll find the Preliminary Concept of Operations document at:=20 http://www.its.dot.gov/ng911/next_gen_911_sys.htm You will be kept apprised of each project phase as implemented. Thank you for your interest.=20 Feel free to contact Jenny Hansen, the Project Coordinator for related information. Or visit the web at:=20 http://www.its.dot.gov/ng911 ------_=_NextPart_001_01C62D9A.A44C6330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable US DOT Next Generation 9-1-1 Project: Information and a = Question

My name is Jenny = Hansen. I'm the Project Coordinator for the Next Generation 9-1-1 = Project at the U.S. Department of Transportation.

We're in the early = stages of the project and I'm developing a listserv for the project to = insure we share the information for any agency (public or private) that = may have mutual interest in what is occurring in this effort.

I'm soliciting input, = while offering project updates to our ListServ recipients, but I'd like = to reach out to your membership at large. (I've included a copy of the = original Email sent last month regarding the release of the Preliminary = Concept of Operations document - a "user's document" of = sorts). Is there a process we may follow to provide the information to = your members? Additionally, if there is any option for us to share the = information at one of your regional meetings or programs, we'd be happy = to provide same.

Any thoughts, = suggestions or recommendations you have are truly appreciated.
Thank you for your = consideration.
Jenny = Hansen

Jenny Hansen, Project = Coordinator
Next Generation 9-1-1 (NG = 9-1-1)
USDOT/NHTSA
(202) 366-5598

Greetings and Happy New Year!
You are = receiving this information as a key member of public safety, = telecommunications or professional industry that may have a mutual = interest in the following project underway with the U.S. Department of = Transportation (DOT).

The Next Generation 9-1-1 Initiative is a DOT research = and development project to define the system architecture and develop a = transition plan that considers responsibilities, costs, schedule and = benefits for deploying IP-based

9-1-1 = services across the Nation. This project is leveraging work from = DOT’s earlier Wireless E9-1-1 Initiative, which has enhanced = location capability for 9-1-1 calls placed from wireless phones. =

To provide = a bit of background for your consideration, I've included an excerpt of = the NG9-1-1 Initiative which provides an overview of the NG9-1-1 Project = phases. As follows:

Next = Generation 9-1-1 (NG9-1-1) Initiative. Working closely with the 9-1-1 = stakeholders and industry, this research initiative, funded by the = Intelligent Transportation System program, will produce a national = architecture and deployment plan for the next generation of the 9-1-1 = system (or system of systems); enabling access to the 9-1-1 network with = most communication devices. This project is an $11 million dollar, = 3-year initiative and will be completed in three phases.

· Telecommunication and 9-1-1 users and providers will be recruited = to become actively involved in the process of determining operational = policies and user requirements for an Internet/multimedia-capable 9-1-1 = system.

· The NG9-1-1 system will be operationally defined. Based on this = preliminary “ConOps” document, a variety of strategies will = be used to develop user requirements for the NG9-1-1 system.

· Finally, a design team/consortium will be tasked with completing = a high-level architecture and a migration plan that can guide the = transition from the present 9-1-1 system to the next generation of = 9-1-1. The final documents, with a target deadline of 2008, will be made = available to the public, and can serve as the basis for NG9-1-1 = deployment plans.

The NG9-1-1 = Concept of Operations (ConOps) is a formal document that provides a = user-oriented vision of NG9-1-1 within the context of an emergency = services internetwork that can be understood by stakeholders with a = broad range of operational and technical expertise. It is intended to = communicate the vision of this system to stakeholders so that they can = be actively engaged in its development and deployment. It also serves as = the foundation for the development of the NG9-1-1 requirements and to = drive the design of the overall system. This document will be updated = throughout the NG9-1-1 Initiative effort, as the thinking related to the = implementation of NG9-1-1 capabilities becomes clearer and more precise. = It is expected that under procured work to design NG9-1-1 applications, = this document will be used as supplemental information, and will be = revisited and refined into a more comprehensive NG9-1-1 ConOps = document.

You'll find = the Preliminary Concept of Operations document at:=20
http://www.its.dot.gov/ng911/next_gen_911_sys.htm
You will = be kept apprised of each project phase as implemented. Thank you for = your interest.=20
Feel free = to contact Jenny Hansen, the Project Coordinator for related = information. Or visit the web at:=20
http://www.its.dot.gov/ng911



------_=_NextPart_001_01C62D9A.A44C6330-- --===============1780999251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1780999251==-- From ecrit-bounces@ietf.org Thu Feb 09 13:01:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7G6i-0005xx-3F; Thu, 09 Feb 2006 13:01:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7G6f-0005t1-QF for ecrit@megatron.ietf.org; Thu, 09 Feb 2006 13:01:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14119 for ; Thu, 9 Feb 2006 12:59:36 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7GJO-00014G-NO for ecrit@ietf.org; Thu, 09 Feb 2006 13:14:37 -0500 Received: from [10.10.2.124] (expo112.palais-congres-paris.fr [212.155.202.112] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k19I1Ej0013790 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Feb 2006 12:01:15 -0600 In-Reply-To: <9D25AF0E6FE1ED41A54215BC3E37772C0234E518@MSGC2.NED.NHTSA.AD> References: <9D25AF0E6FE1ED41A54215BC3E37772C0234E518@MSGC2.NED.NHTSA.AD> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5469E596-E68B-443F-B0AF-0E0C58EA4F3C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Ecrit] US DOT Next Generation 9-1-1 Project: Information and a Question Date: Thu, 9 Feb 2006 12:01:30 -0600 To: "Hansen, Jenny " X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Feb 9, 2006, at 11:02 AM, Hansen, Jenny wrote: > My name is Jenny Hansen. I'm the Project Coordinator for the Next > Generation 9-1-1 Project at the U.S. Department of Transportation. > > We're in the early stages of the project and I'm developing a > listserv for the project to insure we share the information for any > agency (public or private) that may have mutual interest in what is > occurring in this effort. > > I'm soliciting input, while offering project updates to our > ListServ recipients, but I'd like to reach out to your membership > at large. (I've included a copy of the original Email sent last > month regarding the release of the Preliminary Concept of > Operations document - a "user's document" of sorts). Is there a > process we may follow to provide the information to your members? > Additionally, if there is any option for us to share the > information at one of your regional meetings or programs, we'd be > happy to provide same. I'd say that given your copied email included a link to a web site where we can download the preliminary document, that you've succeeded in sharing it with our working group, which is a Good Thing. Thank you -- this whole process is improved by the free exchange of information. I'll leave further commentary on meeting participation or other alternatives to the folks who plan those meetings, but it sounds like it might be a good idea to me. I'm also curious about any interaction you might have (and about the opportunity for convergence with) emergency communications coordination agencies for other jurisdictions. Having to make 192 different varieties of emergency response software is a bit tedious. -- Dean Willis > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 14 07:36:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zQA-0008I7-Sf; Tue, 14 Feb 2006 07:36:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zQ8-0008Hx-TV for ecrit@megatron.ietf.org; Tue, 14 Feb 2006 07:36:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21215 for ; Tue, 14 Feb 2006 07:34:54 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8zdx-00089y-2J for ecrit@ietf.org; Tue, 14 Feb 2006 07:50:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Requirements Draft close to completion Date: Tue, 14 Feb 2006 13:40:26 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4D47@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Requirements Draft close to completion Thread-Index: AcYpGuOrlFGcU7rJQaS0Q/pkRe93rAIR++7g From: "Stastny Richard" To: "Tschofenig, Hannes" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Folks, first I want to thank all participants of the interim meeting and especially Roger for the excellent work done finalizing the requirements draft. I have not yet cross-checked the draft with the meeting minutes completely, but on the first complete read I have not found any open issues not addressed. I am also the opinion that the draft is after the below announced re-submission ready for WGLC. Cheers Richard > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Tschofenig, Hannes > Sent: Saturday, February 04, 2006 7:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] Requirements Draft close to completion >=20 > Hi all, >=20 > the first day of the interim meeting was spend to walk through the open > issues of > draft-ietf-ecrit-requirements-02.txt. We were able to close ALL open > issues. Thanks to all the participants. >=20 > Roger has already incorporated the suggested changes into a new version > and he submitted the document already. Please find it at > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-03.txt > (before it appears in the IETF archive). > Thank you Roger! >=20 > To make sure that we have indeed addressed all open issues listed at > http://www.ietf-ecrit.org:8080/ecrit-req > correctly we would like to ask everyone to review the document again and > to ask those people who haven't had the chance to attend the interim > meeting to carefully inspect whether their open issue was adequately > addressed. >=20 > The next steps for this document are as follows: >=20 > - Roger will add information to each requirement to indicate whether the > RFC 2119 language refers to > (a) a requirement for an implementation or to > (b) a requirement for usage > He will then resubmit the document. Targeted resubmission date: next > week >=20 > - We would then like to start a WGLC on the 20th February running for 2 > weeks. >=20 > Since these goals are quite ambitious we would like to ask for your > help. Please review the document as early as possible AND make > constructive feedback (e.g., text suggestions instead of just stating 'i > don't like it'). >=20 > Ciao > Hannes & Marc >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 14 08:06:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zt7-000164-2q; Tue, 14 Feb 2006 08:06:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zt4-00013r-VZ for ecrit@megatron.ietf.org; Tue, 14 Feb 2006 08:06:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23826 for ; Tue, 14 Feb 2006 08:04:48 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F906t-0000sm-W9 for ecrit@ietf.org; Tue, 14 Feb 2006 08:20:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] A Uniform Resource Name (URN) for Services: An ECRIT WGitem? Date: Tue, 14 Feb 2006 14:10:22 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4D4A@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] A Uniform Resource Name (URN) for Services: An ECRIT WGitem? Thread-Index: AcYpFpV6Zsj0MFfsSSyjmLcIEnAN1AIUVMEQ From: "Stastny Richard" To: "Tschofenig, Hannes" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree making=20 draft-schulzrinne-sipping-service-01.txt an ECRIT WG item Richard > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Tschofenig, Hannes > Sent: Saturday, February 04, 2006 7:55 PM > To: ecrit@ietf.org > Subject: [Ecrit] A Uniform Resource Name (URN) for Services: An ECRIT > WGitem? >=20 > Hi all, >=20 > we have a charter item for identifying a session set-up request to an > emergency response center. >=20 > We have two proposals for this charter item: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-02.txt > http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-service-01 > .txt >=20 > The idea of moving the draft-schulzrinne-sipping-service-01.txt document > forward and to stop the work on draft-ietf-sipping-sos-02.txt was raised > at the last IETF meeting and at the interim meeting. >=20 > Furthermore, a hum at the interim meeting indicated support for making > the draft-schulzrinne-sipping-service-01.txt a working group item. >=20 > Please speak for or against making > draft-schulzrinne-sipping-service-01.txt a working group item for the > ECRIT working group. >=20 > Deadline for responding to this hum is the 14th February 2006. >=20 > Ciao > Hannes & Marc >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 14 08:13:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zzb-0005EB-Fo; Tue, 14 Feb 2006 08:13:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zza-0005Dr-7J for ecrit@megatron.ietf.org; Tue, 14 Feb 2006 08:13:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24735 for ; Tue, 14 Feb 2006 08:11:31 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F90DO-0001E0-7b for ecrit@ietf.org; Tue, 14 Feb 2006 08:27:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Ecrit] Mapping Protocol: Next Steps Date: Tue, 14 Feb 2006 14:17:04 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4D4C@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Mapping Protocol: Next Steps Thread-Index: AcYpGBv7E12OLBVUSxegLPpLt+dS2AITBOnAAAEr0WA= From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > -----Original Message----- > From: Stastny Richard > Sent: Tuesday, February 14, 2006 1:51 PM > To: 'Tschofenig, Hannes' > Subject: RE: [Ecrit] Mapping Protocol: Next Steps >=20 > Since I consider progress concerning the mapping protocol as > essential, I welcome ANY decision to move forward, because > Time is pressing >=20 > Merging LUMP and ECON_IRIS and capturing the aspects of > the DNS-SOS proposal sounds convincing, but > since I am not the expert here, I can only leave > the realization to the experts. >=20 > Anyway, I am already looking forward for the new > proposed draft. >=20 > Regards > Richard >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Tschofenig, Hannes > > Sent: Saturday, February 04, 2006 7:55 PM > > To: ecrit@ietf.org > > Subject: [Ecrit] Mapping Protocol: Next Steps > > > > Hi all, > > > > we spend a lot of time during the interim meeting to talk about the > > mapping protocol proposals. > > We had three proposals on the table: > > > > LUMP: draft-schulzrinne-ecrit-lump-01.txt > > DNS-SOS: draft-rosen-dns-sos-03.txt > > ECON-IRIS: draft-hardie-ecrit-iris-03.txt > > > > Our discussions produced the following results: > > > > * The proposals LUMP and ECON-IRIS will be merged due to their > > similarity and a new proposal will be published before the IETF draft > > submission deadline. > > > > * The work on the DNS-SOS proposal will be stopped. A hum showed lack of > > interest in moving the proposal forward. > > The positive and negative aspects of the DNS-SOS proposal will be (or > > have already been) captured and will be input to the mapping protocol > > work in the future. > > > > A number of details were discussed and need to be reflected in the > > yet-to-be-written mapping protocol document. > > > > To make good progress with this work the chairs would like to know > > whether there is acceptance or resistance against the suggested way > > forward. > > > > Ciao > > Hannes & Marc > > > > Ps: Please take a look at the published meeting minutes to learn more > > about the discussed aspects. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 14 08:11:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zxk-0002cy-Bt; Tue, 14 Feb 2006 08:11:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zxi-0002YT-7B for ecrit@megatron.ietf.org; Tue, 14 Feb 2006 08:11:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24383 for ; Tue, 14 Feb 2006 08:09:35 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F90BX-00015f-77 for ecrit@ietf.org; Tue, 14 Feb 2006 08:25:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Charter discussions and milestone adjustments MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2006 14:15:09 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4D4B@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] Charter discussions and milestone adjustments Thread-Index: AcYpv3PE5bcOB8LISZGcwdBCy9mlJQHqPx5g From: "Stastny Richard" To: "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with the charter modifications, although I wish you good luck with the third item. I also support Hennings suggestion below. Richard > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Saturday, February 04, 2006 8:08 PM > To: Tschofenig, Hannes > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Charter discussions and milestone adjustments >=20 > Suggestion: Please consider adding I-D names to charter items where > these are known to exist, as this makes tracking easier (or, at > least, align the charter items with the I-D titles). >=20 > On Feb 4, 2006, at 1:54 PM, Tschofenig, Hannes wrote: >=20 > > Hi all, > > > > during the interim meeting we had time to review our charter. As > > part of > > the discussions we thought about aligning the charter milestones to > > the > > current work. > > > > Here is the proposal we came up with: > > > > ------- > > > > March 2006 Informational RFC containing terminology > > definitions and the requirements > > > > May 2006 An Informational document describing the threats > > and security considerations > > > > March 2006 A Standards Track RFC describing how to identify > > a session set-up request is to an emergency response center > > > > Nov 2006 A Standards Track RFC describing how to route an > > emergency call based on location information > > > > ------- > > > > Please take a look at the updated completion date and also note > > that the > > number of milestone items was reduced. > > > > New charter items will be added to the charter > > * if we make progress with the existing work items AND > > * if there are concrete proposals (i.e., available drafts) > > (assuming interest by the group and area director approval -- > > obviously). > > > > Please let us know if you agree or object with the proposed charter > > adjustment. > > > > Deadline for responding: 20th February 2006 > > > > Ciao > > Hannes & Marc > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 14 09:00:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90ir-0006NG-QA; Tue, 14 Feb 2006 09:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90ip-0006M9-K2 for ecrit@megatron.ietf.org; Tue, 14 Feb 2006 09:00:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27632 for ; Tue, 14 Feb 2006 08:58:16 -0500 (EST) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F90we-0002WI-NF for ecrit@ietf.org; Tue, 14 Feb 2006 09:14:21 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k1EDxrW1027354; Tue, 14 Feb 2006 14:59:53 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k1EDxqjT026504; Tue, 14 Feb 2006 14:59:53 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 14:59:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Charter discussions and milestone adjustments Date: Tue, 14 Feb 2006 14:56:10 +0100 Message-ID: Thread-Topic: [Ecrit] Charter discussions and milestone adjustments thread-index: AcYpv3PE5bcOB8LISZGcwdBCy9mlJQHqPx5gAAFZtyA= From: "Tschofenig, Hannes" To: "Stastny Richard" X-OriginalArrivalTime: 14 Feb 2006 13:59:50.0329 (UTC) FILETIME=[EC104290:01C6316E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi richard,=20 > I agree with the charter modifications, although I wish you > good luck with the third item. thanks for the feedback.=20 with everyone's help we will hit the deadline for the third item.=20 >=20 > I also support Hennings suggestion below. here is the problem: what draft name should i add with the third item?=20 should i also add draft-taylor-ecrit-security-threats-01.txt to the charter? (second item) ciao hannes >=20 > Richard >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Henning Schulzrinne > > Sent: Saturday, February 04, 2006 8:08 PM > > To: Tschofenig, Hannes > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Charter discussions and milestone adjustments > >=20 > > Suggestion: Please consider adding I-D names to charter items where > > these are known to exist, as this makes tracking easier (or, at > > least, align the charter items with the I-D titles). > >=20 > > On Feb 4, 2006, at 1:54 PM, Tschofenig, Hannes wrote: > >=20 > > > Hi all, > > > > > > during the interim meeting we had time to review our charter. As > > > part of > > > the discussions we thought about aligning the charter=20 > milestones to > > > the > > > current work. > > > > > > Here is the proposal we came up with: > > > > > > ------- > > > > > > March 2006 Informational RFC containing terminology > > > definitions and the requirements > > > > > > May 2006 An Informational document describing the threats > > > and security considerations > > > > > > March 2006 A Standards Track RFC=20 > describing how to identify > > > a session set-up request is to an emergency response center > > > > > > Nov 2006 A Standards Track RFC describing how to route an > > > emergency call based on location information > > > > > > ------- > > > > > > Please take a look at the updated completion date and also note > > > that the > > > number of milestone items was reduced. > > > > > > New charter items will be added to the charter > > > * if we make progress with the existing work items AND > > > * if there are concrete proposals (i.e., available drafts) > > > (assuming interest by the group and area director approval -- > > > obviously). > > > > > > Please let us know if you agree or object with the=20 > proposed charter > > > adjustment. > > > > > > Deadline for responding: 20th February 2006 > > > > > > Ciao > > > Hannes & Marc > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 14 09:30:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91Bt-0008Ch-H2; Tue, 14 Feb 2006 09:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91Bs-0008Av-5W for ecrit@megatron.ietf.org; Tue, 14 Feb 2006 09:30:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29904 for ; Tue, 14 Feb 2006 09:28:16 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F91Ph-0003Wj-HY for ecrit@ietf.org; Tue, 14 Feb 2006 09:44:21 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1EETokY026039 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 14 Feb 2006 09:29:59 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16F7A8CA-8C33-454B-9332-66E14BF59F86@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: AW: [Ecrit] Charter discussions and milestone adjustments Date: Tue, 14 Feb 2006 09:29:49 -0500 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > here is the problem: what draft name should i add with the third item? > I'll be happy to submit draft-ietf-ecrit-service-urn-00 tomorrow, depending on the outcome of the "vote" today. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 15 09:14:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9NQD-0003vs-9S; Wed, 15 Feb 2006 09:14:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9NQC-0003vn-3S for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 09:14:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12546 for ; Wed, 15 Feb 2006 09:12:32 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9NeA-0003aB-2i for ecrit@ietf.org; Wed, 15 Feb 2006 09:28:50 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k1FEDxR10932 for ; Wed, 15 Feb 2006 09:13:59 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006021509084607027 for ; Wed, 15 Feb 2006 09:08:46 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Feb 2006 09:08:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] AW: Requirements Draft close to completion Date: Wed, 15 Feb 2006 09:08:46 -0500 Message-ID: Thread-Topic: [Ecrit] AW: Requirements Draft close to completion Thread-Index: AcYpGuOrlFGcU7rJQaS0Q/pkRe93rAAokvDgAhyKfFA= From: "Abbott, Nadine B" To: X-OriginalArrivalTime: 15 Feb 2006 14:08:46.0402 (UTC) FILETIME=[56004220:01C63239] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, Roger, all, Thanks to Roger for the quick turn-around and heroic efforts to capture = lively discussion in text. After reviewing my notes, the meeting minutes and logs, I'd like to = suggest a few small text edits in the requirements documents. 1) Thanks for adding a definition for PSAP URI. It would help to add = the example of ESRP, I think.=20 The change text is <> to say: PSAP URI: PSAP URI is a general term, used to refer to the output of the mapping protocol, and represents either the actual = PSAP IP address, or <> which points to the actual PSAP. 2) Need to add a definition for the acronym LCMS or spell out (used in = requirement Ma24X). 3) Minor edits: Ma7: Multiple PSAP <> (no apostrophe needed) Ma9: replace "urii" with "uri" 4) We added two new requirements to further clarify the requirements on = the protocol in responding to location validation requests: Lo1X and = Lo1XX. I think I understand them, but I am not sure that someone not = involved in the discussion would understand them the same way. In the = discussion (see posted meeting notes) we said: "Do we agree that we need = a result code, in addition to a URI? Partial validation may be the = common case (public verifiers won't know suite numbers/room numbers, for = example)... The protocol MUST have the mechanism (whether it gets used = or not is up to the administration)." I think it would clarify = requirement Lo1X to add a motivation with wording like the following in = <>.=20 =20 Lo1X. Validation Resolution: The mapping protocol MUST support the return of additional information which can be used to determine the precision or resolution of the data elements used to determine a PSAP URI, for example. =20 <>=20 5) There was also another idea that I think it would be valuable to = capture--that it is useful to be able to provide in the response a URI = that the client can then use to further resolve problems. (See posted = meeting notes: "Does the ECRIT protocol need to provide a way to fix = data that's wrong in the database? No, but is it helpful to provide a = URL for a mechanism that would help in fixing the data? NENA did this - = it's actually helpful. We can't tell whether the user is wrong or the = database is wrong.") I think this is a requirement on the protocol and = is more than just an indication that something is wrong. Therefore, I = suggest that we add text like the following in <> to Lo1XX, = plus maybe a Motivation with wording like that below in <>.=20 Lo1XX. Indication of non-existent location: The protocol MUST support a mechanism to indicate that a location or a part of a location is known to not exist, even if a valid location-to-PSAP uri mapping can be provided. <> <> =20 Regards, Nadine Abbott -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Tschofenig, Hannes Sent: Saturday, February 04, 2006 2:01 PM To: ecrit@ietf.org Subject: [Ecrit] AW: Requirements Draft close to completion Hi all,=20 The issue tracker is currently empty since Roger closed all of them.=20 If you want to retrieve the full list of issues (including all closed = issues) please use the following link: http://www.ietf-ecrit.org:8080/ecrit-req/issue?:columns=3Did,activity,tit= le,creator,assignedto,status&:sort=3Did&:group=3Dstatus&:pagesize=3D50&:s= tartwith=3D0 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Tschofenig, Hannes > Gesendet: Samstag, 4. Februar 2006 00:38 > An: 'ecrit@ietf.org' > Betreff: Requirements Draft close to completion >=20 > Hi all, >=20 > the first day of the interim meeting was spend to walk through the=20 > open issues of draft-ietf-ecrit-requirements-02.txt. We were able to=20 > close ALL open issues. Thanks to all the participants. >=20 > Roger has already incorporated the suggested changes into a new=20 > version and he submitted the document already. Please find it at > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements- > 03.txt (before it appears in the IETF archive). > Thank you Roger! >=20 > To make sure that we have indeed addressed all open issues listed at=20 > http://www.ietf-ecrit.org:8080/ecrit-req > correctly we would like to ask everyone to review the document again=20 > and to ask those people who haven't had the chance to attend the=20 > interim meeting to carefully inspect whether their open issue was=20 > adequately addressed. >=20 > The next steps for this document are as follows: >=20 > - Roger will add information to each requirement to indicate whether=20 > the RFC 2119 language refers to > (a) a requirement for an implementation or to > (b) a requirement for usage > He will then resubmit the document. Targeted resubmission > date: next week >=20 > - We would then like to start a WGLC on the 20th February running for=20 > 2 weeks. >=20 > Since these goals are quite ambitious we would like to ask for your=20 > help. Please review the document as early as possible AND make=20 > constructive feedback (e.g., text suggestions instead of just stating=20 > 'i don't like it'). >=20 > Ciao > Hannes & Marc >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 15 10:32:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Odc-0002xz-QW; Wed, 15 Feb 2006 10:32:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Odb-0002p9-5L for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 10:32:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17765 for ; Wed, 15 Feb 2006 10:30:27 -0500 (EST) Received: from mail42.messagelabs.com ([216.82.244.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F9Ore-0006Pv-0h for ecrit@ietf.org; Wed, 15 Feb 2006 10:46:46 -0500 X-VirusChecked: Checked X-Env-Sender: kamran.aquil@mitretek.org X-Msg-Ref: server-23.tower-42.messagelabs.com!1140017444!20688693!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [66.10.26.57] Received: (qmail 11603 invoked from network); 15 Feb 2006 15:30:44 -0000 Received: from mtk-news1.mitretek.org (HELO mtk-news1.mitretek.org) (66.10.26.57) by server-23.tower-42.messagelabs.com with SMTP; 15 Feb 2006 15:30:44 -0000 Received: from email1.mitretek.org (email1.mitretek.org [172.16.49.40]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id k1FFUhQc006606 for ; Wed, 15 Feb 2006 10:30:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Feb 2006 10:30:43 -0500 Message-ID: <88C80871CC296F438124F37C5656BDAFB22FBC@email1.mitretek.org> Thread-Topic: ECRIT support for TTY/TDD calls Thread-Index: AcYyRMiwRvRmrrgLS6CL3tlGcXJMcA== From: "Aquil, Kamran" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Ecrit] ECRIT support for TTY/TDD calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0405918492==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0405918492== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63244.C8D9F2D7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63244.C8D9F2D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 Like to know if there are specific ECRIT requirements recognizing support for Telecommunications Device for the Deaf (TDD) services for the hearing impaired. If not is this left for VOIP/SIP gateways to perform this requirement of translating the TDD calls to Text and Speech encoding. Wanted to make sure how ECRIT meet requirement for TDD services. =20 Regards, Kamran Aquil Intelligent Transportation Systems- Division Mitretek Systems. =20 =20 =20 ------_=_NextPart_001_01C63244.C8D9F2D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
Like = to know if=20 there are specific ECRIT requirements recognizing support for Telecommunications Device for the Deaf = (TDD)=20 services for the hearing impaired. If not is this left for VOIP/SIP = gateways to=20 perform this requirement of translating the TDD calls to Text = and=20 Speech encoding. Wanted to make sure how ECRIT meet requirement for TDD=20 services.
 
Regards,

Kamran = Aquil

Intelligent Transportation = Systems-=20 Division

Mitretek = Systems.

 

 

 
------_=_NextPart_001_01C63244.C8D9F2D7-- --===============0405918492== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0405918492==-- From ecrit-bounces@ietf.org Wed Feb 15 10:51:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Owe-0002o6-DJ; Wed, 15 Feb 2006 10:51:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Owc-0002o1-Vw for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 10:51:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20302 for ; Wed, 15 Feb 2006 10:50:09 -0500 (EST) Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9PAX-0007Vv-L2 for ecrit@ietf.org; Wed, 15 Feb 2006 11:06:26 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F9OwF-0004ai-1o; Wed, 15 Feb 2006 09:51:31 -0600 From: "Brian Rosen" To: "'Aquil, Kamran'" , Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Wed, 15 Feb 2006 10:51:32 -0500 Message-ID: <043801c63247$b340e800$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <88C80871CC296F438124F37C5656BDAFB22FBC@email1.mitretek.org> Thread-Index: AcYyRMiwRvRmrrgLS6CL3tlGcXJMcAAAjV0g X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0617675041==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0617675041== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0439_01C6321D.CA6C66A0" This is a multi-part message in MIME format. ------=_NextPart_000_0439_01C6321D.CA6C66A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Within the scope of our work, I don't see how TDD services are impacted until we get to the architecture effort, which probably has to have some sections on that subject. With respect to the mapping protocol, I do not believe there is any impact at all. With respect to the sos service urn, I do not believe there is any impact at all Ecrit doesn't have scope to talk about any kind of gateways or codec support. Ah! My BCP on phones and proxies may need some mention, although this is the IETF, and I don't think the ploy of forcing the entire PSTN to support TDD just so 9-1-1 TDD will work. That effort would have to be in the general SIP arena. Brian _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Aquil, Kamran Sent: Wednesday, February 15, 2006 10:31 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT support for TTY/TDD calls Folks, Like to know if there are specific ECRIT requirements recognizing support for Telecommunications Device for the Deaf (TDD) services for the hearing impaired. If not is this left for VOIP/SIP gateways to perform this requirement of translating the TDD calls to Text and Speech encoding. Wanted to make sure how ECRIT meet requirement for TDD services. Regards, Kamran Aquil Intelligent Transportation Systems- Division Mitretek Systems. ------=_NextPart_000_0439_01C6321D.CA6C66A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Within the scope of our work, I = don’t see how TDD services are impacted until we get to the architecture = effort, which probably has to have some sections on that = subject.

With respect to the mapping = protocol, I do not believe there is any impact at all.

With respect to the sos service = urn, I do not believe there is any impact at all

 

Ecrit doesn’t have scope to = talk about any kind of gateways or codec = support.

 

Ah!  My BCP on phones and = proxies may need some mention, although this is the IETF, and I don’t think = the ploy of forcing the entire PSTN to support TDD just so 9-1-1 TDD will work. =  That effort would have to be in the general SIP = arena.

 

Brian

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Aquil, Kamran
Sent: Wednesday, February = 15, 2006 10:31 AM
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT = support for TTY/TDD calls

 

Folks,

 

Like to know if there are specific ECRIT requirements recognizing support for Telecommunications Device for = the Deaf (TDD) services for the hearing impaired. If not is this left for = VOIP/SIP gateways to perform this requirement of translating the = TDD calls to Text and Speech encoding. Wanted to make sure how ECRIT meet requirement = for TDD services.

 

Regards,

Kamran Aquil

Intelligent Transportation Systems- = Division

Mitretek Systems.

 

 

 

------=_NextPart_000_0439_01C6321D.CA6C66A0-- --===============0617675041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0617675041==-- From ecrit-bounces@ietf.org Wed Feb 15 11:14:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PIM-0003f8-Qf; Wed, 15 Feb 2006 11:14:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PIK-0003eP-9J for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 11:14:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27306 for ; Wed, 15 Feb 2006 11:12:34 -0500 (EST) Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9PWE-0001qq-HL for ecrit@ietf.org; Wed, 15 Feb 2006 11:28:51 -0500 Received: from [192.168.2.204] (helo=[192.168.2.204]) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1F9PRR-00058Q-00; Wed, 15 Feb 2006 11:23:45 -0500 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 15 Feb 2006 11:13:43 -0500 Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls From: "Fran=?ISO-8859-1?B?5w==?=ois D. M=?ISO-8859-1?B?6Q==?=nard" To: , "'Aquil, Kamran'" , Message-ID: Thread-Topic: [Ecrit] ECRIT support for TTY/TDD calls Thread-Index: AcYyRMiwRvRmrrgLS6CL3tlGcXJMcAAAjV0gAADzC7U= In-Reply-To: <043801c63247$b340e800$640fa8c0@cis.neustar.com> Mime-version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1918711346==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1918711346== Content-type: multipart/alternative; boundary="B_3222846840_2266267" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3222846840_2266267 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I made a contribution to CISC NTWG on use of SIP for transporting TDD traffic: http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc I think it may be relevant to ECRIT. -=3DFrancois=3D- On 2/15/06 10:51 AM, "Brian Rosen" wrote: > Within the scope of our work, I don=B9t see how TDD services are impacted u= ntil > we get to the architecture effort, which probably has to have some sectio= ns on > that subject. > With respect to the mapping protocol, I do not believe there is any impac= t at > all. > With respect to the sos service urn, I do not believe there is any impact= at > all > =20 > Ecrit doesn=B9t have scope to talk about any kind of gateways or codec supp= ort. > =20 > Ah! My BCP on phones and proxies may need some mention, although this is= the > IETF, and I don=B9t think the ploy of forcing the entire PSTN to support TD= D > just so 9-1-1 TDD will work. That effort would have to be in the general= SIP > arena. > =20 > Brian > =20 >=20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Aquil, Kamran > Sent: Wednesday, February 15, 2006 10:31 AM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT support for TTY/TDD calls > =20 >=20 > Folks, >=20 > =20 >=20 > Like to know if there are specific ECRIT requirements recognizing support= for > Telecommunications Device for the Deaf (TDD) services for the hearing > impaired. If not is this left for VOIP/SIP gateways to perform this > requirement of translating the TDD calls to Text and Speech encoding. Wan= ted > to make sure how ECRIT meet requirement for TDD services. >=20 > =20 >=20 > Regards, > Kamran Aquil > Intelligent Transportation Systems- Division > Mitretek Systems. > =20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit --=20 Francois D. Menard fmenard@xittelecom.com --B_3222846840_2266267 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] ECRIT support for TTY/TDD calls
I made a contribution to CISC NTWG on use of SIP for transporting TDD traff= ic:

http://ww= w.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc

I think it may be relevant to ECRIT.

-=3DFrancois=3D-


On 2/15/06 10:51 AM, "Brian Rosen" <br@brianrosen.net> wrot= e:

Within the scope of our work, I don= 217;t see how TDD services are impacted until we get to the architecture eff= ort, which probably has to have some sections on that subject.
With respect to the mapping protocol, I do not believe there is any impact = at all.
With respect to the sos service urn, I do not believe there is any impact a= t all
 
Ecrit doesn’t have scope to talk about any kind of gateways or codec = support.
 
Ah!  My BCP on phones and proxies may need some mention, although this= is the IETF, and I don’t think the ploy of forcing the entire PSTN to= support TDD just so 9-1-1 TDD will work.  That effort would have to be= in the general SIP arena.
 
Brian
 

=

From:<= /B> ecrit-bounces@ietf.org [mailto:= ecrit-bounces@ietf.org] On Behalf Of Aquil, Kamran
Sent: Wednesday, February 15, 2006 10:31 AM
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT support for TTY/TDD calls

Folks,

Like to know if there are specific ECRIT requirements recognizing suppor= t for Telecommunications Device for the Deaf (TDD) services f= or the hearing impaired. If not is this left for VOIP/SIP gateways to perfor= m this requirement of translating the TDD calls to Text and Speech encoding.= Wanted to make sure how ECRIT meet requirement for TDD services.

Regards,
Kamran Aquil
Intelligent Transportation Systems- Division
Mitretek Systems.
 

____________________= ___________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit


--
Francois D. Menard
fmenard@xittelecom.com


 --B_3222846840_2266267-- --===============1918711346== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1918711346==-- From ecrit-bounces@ietf.org Wed Feb 15 11:32:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PZo-0006lb-Hb; Wed, 15 Feb 2006 11:32:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PZn-0006lM-PP for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 11:32:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04837 for ; Wed, 15 Feb 2006 11:30:37 -0500 (EST) Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Pnm-0004fU-Da for ecrit@ietf.org; Wed, 15 Feb 2006 11:46:54 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1FGW5t16222; Wed, 15 Feb 2006 11:32:05 -0500 (EST) Received: from [127.0.0.1] ([47.130.25.171] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 11:32:05 -0500 Message-ID: <43F35780.9090000@nortel.com> Date: Wed, 15 Feb 2006 11:32:00 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Aquil, Kamran" Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls References: <88C80871CC296F438124F37C5656BDAFB22FBC@email1.mitretek.org> In-Reply-To: <88C80871CC296F438124F37C5656BDAFB22FBC@email1.mitretek.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2006 16:32:05.0443 (UTC) FILETIME=[5B6DC930:01C6324D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Some countries have separate emergency numbers to call for TDD support. The implication is that this may have to be reflected somehow in the mapping, but definitely will be reflected in the media negotiation between the emergency caller's device and the PSAP. Aquil, Kamran wrote: > Folks, > > Like to know if there are specific ECRIT requirements recognizing > support for Telecommunications Device for the Deaf (TDD) services for > the hearing impaired. If not is this left for VOIP/SIP gateways to > perform this requirement of translating the TDD calls to Text and Speech > encoding. Wanted to make sure how ECRIT meet requirement for TDD > services. > > Regards, > Kamran Aquil > > Intelligent Transportation Systems- Division > > Mitretek Systems. > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 15 17:47:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9VQw-0006d7-6b; Wed, 15 Feb 2006 17:47:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9VQu-0006bl-5J for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 17:47:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15329 for ; Wed, 15 Feb 2006 17:45:49 -0500 (EST) Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Veh-0005d8-Au for ecrit@ietf.org; Wed, 15 Feb 2006 18:02:10 -0500 Received: from MISAN (213.64.230.47) by pne-smtpout1-sn1.fre.skanova.net (7.2.070) id 43E9FE42001ECB27; Wed, 15 Feb 2006 23:47:06 +0100 From: "Gunnar Hellstrom" To: , "'Aquil, Kamran'" , , "=?iso-8859-1?Q?Fran=E7ois_D._M=E9nard?=" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Wed, 15 Feb 2006 23:47:05 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 27f32072baa9c4fb41949212e86ea6d2 Cc: Gregg Vanderheiden X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0297749092==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0297749092== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C6328A.204B4FC0" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C6328A.204B4FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable Re: [Ecrit] ECRIT support for TTY/TDD callsIt is quite widely accepted no= w that real-time text transmitted with its own text coded RTP payload RFC 4= 103 is used to carry text that may be gatewayed to/from TTY/TDD/textphones in PSTN. It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt And it is documented in http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt Also other standardisation bodies have picked up the real-time text conce= pt in IP networks, and pointed at RFC 4103 (or its compatible predecessor RFC2793 ). E.g. 3GPP and ETSI. A couple of years ago we had an intensive discussion in the SIMPLE mail l= ist about the possibility to use MSRP to carry the real-time text medium, but= we concluded that it would cause too much overhead or too much delay for the users, so that RTP was recommended instead. The most common use of MSRP i= s to not transmit until end of sentence, while for real time text, transmission is required with at most 500 ms interval as long as there is anything to transmit in order to maintain the real-time feeling of being = in touch in a conversation through this medium. Quite commonly you will connect a text RTP stream and an audio RTP stream and possibly a video RTP stream in the same call, so that you will get an enhanced multimedia phone call with all supported media The ecrit requirements also mentions this correspondence in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt Re4. Multiple Modes: Multiple communication modes, such as audio, video and text messaging MUST be supported. Motivation: In PSTN, voice and text telephony (often called TTY or textphone in North America) are the only commonly supported media. Emergency calling must support a variety of media. Such media should include voice, conversational text (RFC 4103 [9]), instant messaging and video. I am working in a European group where one of the goals is to agree on handling text users' requirements on emergency calling in IP networks. O= f course we want to agree on global solutions if possible. Address mapping is one important and tricky question for text users. It i= s true that different countries have different approaches on emergency call= ing with PSTN Text telephones (TTYs). Some have the same number as voice user= s, while others have specific numbers. On the SIP side it would be good to h= ave the same URL and make any required routing based on declared media, mode = and language capabilities and preferences. Text capable gateways are not at all as common as VoIP gateways, so if th= e PSAP is still in PSTN, there is a need to have a good mechanism for routi= ng emergency calls from SIP into PSTN through a text capable gateway. I cann= ot say that the mechanisms for finding the right gateway and make the proper address mapping to a PSTN number is solved yet for the text calls, and it would be excellent if we could have that topic in mind in the discussions and get proper methods documented. I have drafted, but not yet submitted a registration of a SIP URL and an ENUM subservice for real-time text. It might be helpful for finding text gateways and mapping addresses and (text) numbers, but I would like to se= e some scenarios thoroughly discussed before adding SIP URL and another ENU= M subservice. Would there be any benefit of being allowed to enter TXP:112 or having ENUM to find an appropriate address if I call 112 from a SIP multimedia phone declaring text capabilities with m=3Dtext in sdp? Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf O= f Fran=E7ois D. M=E9nard Sent: Wednesday, February 15, 2006 5:14 PM To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls I made a contribution to CISC NTWG on use of SIP for transporting TDD traffic: http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc I think it may be relevant to ECRIT. -=3DFrancois=3D- On 2/15/06 10:51 AM, "Brian Rosen" wrote: Within the scope of our work, I don=92t see how TDD services are impa= cted until we get to the architecture effort, which probably has to have some sections on that subject. With respect to the mapping protocol, I do not believe there is any impact at all. With respect to the sos service urn, I do not believe there is any impact at all Ecrit doesn=92t have scope to talk about any kind of gateways or code= c support. Ah! My BCP on phones and proxies may need some mention, although thi= s is the IETF, and I don=92t think the ploy of forcing the entire PSTN to support TDD just so 9-1-1 TDD will work. That effort would have to be in the general SIP arena. Brian -------------------------------------------------------------------------= --- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f Of Aquil, Kamran Sent: Wednesday, February 15, 2006 10:31 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT support for TTY/TDD calls Folks, Like to know if there are specific ECRIT requirements recognizing support for Telecommunications Device for the Deaf (TDD) services for the hearing impaired. If not is this left for VOIP/SIP gateways to perform th= is requirement of translating the TDD calls to Text and Speech encoding. Wan= ted to make sure how ECRIT meet requirement for TDD services. Regards, Kamran Aquil Intelligent Transportation Systems- Division Mitretek Systems. -------------------------------------------------------------------------= --- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit -- Francois D. Menard fmenard@xittelecom.com ------=_NextPart_000_0004_01C6328A.204B4FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable Re: [Ecrit] ECRIT support for TTY/TDD calls
It is=20 quite widely accepted now that real-time text transmitted with its = own text=20 coded RTP payload RFC 4103 is used to carry text that may be gatewayed = to/from=20 TTY/TDD/textphones in PSTN.
 
It is=20 discussed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt=
 
And it=20 is documented in http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.t= xt
 
Also=20 other standardisation bodies have picked up the real-time text concept = in IP=20 networks, and pointed at RFC 4103 (or its compatible predecessor RFC2793 = ). E.g.=20 3GPP and ETSI.
A=20 couple of years ago we had an intensive discussion in the SIMPLE mail = list about=20 the possibility to use MSRP to carry the real-time text medium, but we = concluded=20 that it would cause too much overhead or too much delay for the users, = so that=20 RTP was recommended instead. The most common use of MSRP is to not = transmit=20 until end of sentence, while for real time text, transmission is = required with=20 at most 500 ms interval as long as there is anything to transmit in = order to=20 maintain the real-time feeling of being in touch in a conversation = through this=20 medium.
 
Quite=20 commonly you will connect a text RTP stream and an audio RTP stream and = possibly=20 a video RTP stream in the same call, so that you will get an enhanced = multimedia=20 phone call with all supported media
 
The ecrit = requirements also=20 mentions this correspondence
in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.tx= t

   Re4.  Multiple = Modes: Multiple=20 communication modes, such as audio,
      = video and=20 text messaging MUST be supported.

     =20 Motivation: In PSTN, voice and text telephony (often called TTY=20 or
      textphone in North America) are the = only=20 commonly supported media.
      Emergency = calling=20 must support a variety of media.  Such=20 media
      should include voice, = conversational=20 text (RFC 4103 [9]), instant
      messaging = and=20 video.
 
I am=20 working in a European group where one of the goals is to agree on=20 handling text users'  requirements on emergency calling in IP=20 networks. Of course we want to agree on global solutions if=20 possible.
 
Address mapping is one important and tricky question for text = users. It=20 is true that different countries have different approaches on emergency = calling=20 with PSTN Text telephones (TTYs). Some have the same number as voice = users,=20 while others have specific numbers. On the SIP side it would be good to = have the=20 same URL and make any required routing based on declared media, = mode and=20 language capabilities and preferences.
 
Text=20 capable gateways are not at all as common as VoIP gateways, so if the = PSAP is=20 still in PSTN, there is a need to have a good mechanism for routing = emergency=20 calls from SIP into PSTN through a text capable gateway. I cannot say = that the=20 mechanisms for finding the right gateway and make the proper address = mapping to=20 a PSTN number is solved yet for the text calls, and it would be = excellent if we=20 could have that topic in mind in the discussions and get proper methods=20 documented.
 
I have=20 drafted, but not yet submitted a registration of a SIP URL and an ENUM=20 subservice for real-time text. It might be helpful for finding text = gateways=20 and mapping addresses and (text) numbers, but I would like to = see some=20 scenarios thoroughly discussed before adding SIP URL and another ENUM=20 subservice.
 
Would there be any benefit of being allowed to enter=20 TXP:112    or having ENUM to find an appropriate = address if=20 I   call 112 from a SIP multimedia = phone declaring text=20 capabilities with m=3Dtext in sdp?
 
 
Gunnar
----------------------------------------------------------------= -------------
Gunnar Hellstr=F6m, = Omnitor
gunnar.hellstrom@omnitor.se
-----Original Message-----
From: = ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org]On Behalf Of Fran=E7ois D.=20 M=E9nard
Sent: Wednesday, February 15, 2006 5:14 = PM
To:=20 br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org
Subject: = Re:=20 [Ecrit] ECRIT support for TTY/TDD calls


I made a=20 contribution to CISC NTWG on use of SIP for transporting TDD=20 traffic:

http://w= ww.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc

I=20 think it may be relevant to = ECRIT.

-=3DFrancois=3D-


On 2/15/06=20 10:51 AM, "Brian Rosen" <br@brianrosen.net> = wrote:
Within the scope of our work, I don=92t = see how TDD=20 services are impacted until we get to the architecture effort, which = probably has to have some sections on that subject.
With respect = to the=20 mapping protocol, I do not believe there is any impact at = all.
With=20 respect to the sos service urn, I do not believe there is any impact = at=20 all
 
Ecrit doesn=92t have scope to talk about any kind = of gateways=20 or codec support.
 
Ah!  My BCP on phones and = proxies may=20 need some mention, although this is the IETF, and I don=92t think = the ploy of=20 forcing the entire PSTN to support TDD just so 9-1-1 TDD will work.=20  That effort would have to be in the general SIP=20 = arena.
 
Brian
 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 On Behalf Of Aquil, Kamran
Sent: Wednesday, = February 15,=20 2006 10:31 AM
To: ecrit@ietf.org
Subject: = [Ecrit] ECRIT=20 support for TTY/TDD calls


Folks,



Like to know if there = are specific=20 ECRIT requirements recognizing support for = Telecommunications Device for the Deaf = (TDD)=20 services for the hearing impaired. If not is this left for VOIP/SIP = gateways=20 to perform this requirement of translating the TDD calls to Text and = Speech=20 encoding. Wanted to make sure how ECRIT meet requirement for TDD=20 services.



Regards,
Kamran=20 Aquil
Intelligent Transportation Systems- Division
Mitretek=20 Systems.

 



_______________________________________________
Ecrit=20 mailing=20 = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit


-- =
Francois=20 D.=20 Menard
fmenard@xittelecom.com


------=_NextPart_000_0004_01C6328A.204B4FC0-- --===============0297749092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0297749092==-- From ecrit-bounces@ietf.org Wed Feb 15 18:16:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9VtL-00039D-H6; Wed, 15 Feb 2006 18:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9VtJ-00037x-G4 for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 18:16:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17237 for ; Wed, 15 Feb 2006 18:15:10 -0500 (EST) Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9W7O-0006eW-UD for ecrit@ietf.org; Wed, 15 Feb 2006 18:31:32 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F9Vsu-00058C-CN; Wed, 15 Feb 2006 17:16:33 -0600 From: "Brian Rosen" To: "'Gunnar Hellstrom'" , , "'Aquil, Kamran'" , "=?iso-8859-1?Q?'Fran=E7ois_D._M=E9nard'?=" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Wed, 15 Feb 2006 18:16:36 -0500 Message-ID: <063001c63285$e0734e10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: Thread-Index: AcYygc9+2x9oXF1jSw2czQoct3KIHgAA8TJw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.6 (/) X-Scan-Signature: 30f4e7d5c947c6a4148c223879d273fc Cc: 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0843689201==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0843689201== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0631_01C6325B.F79D4610" This is a multi-part message in MIME format. ------=_NextPart_000_0631_01C6325B.F79D4610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All I get out of this for ecrit is that we need entries for = sos.police.tty in the service registry =20 Brian =20 _____ =20 From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: Wednesday, February 15, 2006 5:47 PM To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. = M=E9nard Cc: Gregg Vanderheiden Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls =20 It is quite widely accepted now that real-time text transmitted with its = own text coded RTP payload RFC 4103 is used to carry text that may be = gatewayed to/from TTY/TDD/textphones in PSTN. =20 It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt =20 And it is documented in http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt =20 Also other standardisation bodies have picked up the real-time text = concept in IP networks, and pointed at RFC 4103 (or its compatible predecessor RFC2793 ). E.g. 3GPP and ETSI. A couple of years ago we had an intensive discussion in the SIMPLE mail = list about the possibility to use MSRP to carry the real-time text medium, = but we concluded that it would cause too much overhead or too much delay for = the users, so that RTP was recommended instead. The most common use of MSRP = is to not transmit until end of sentence, while for real time text, transmission is required with at most 500 ms interval as long as there = is anything to transmit in order to maintain the real-time feeling of being = in touch in a conversation through this medium. =20 Quite commonly you will connect a text RTP stream and an audio RTP = stream and possibly a video RTP stream in the same call, so that you will get = an enhanced multimedia phone call with all supported media=20 =20 The ecrit requirements also mentions this correspondence in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt Re4. Multiple Modes: Multiple communication modes, such as audio, video and text messaging MUST be supported. Motivation: In PSTN, voice and text telephony (often called TTY or textphone in North America) are the only commonly supported media. Emergency calling must support a variety of media. Such media should include voice, conversational text (RFC 4103 [9]), instant messaging and video. =20 I am working in a European group where one of the goals is to agree on handling text users' requirements on emergency calling in IP networks. = Of course we want to agree on global solutions if possible. =20 Address mapping is one important and tricky question for text users. It = is true that different countries have different approaches on emergency = calling with PSTN Text telephones (TTYs). Some have the same number as voice = users, while others have specific numbers. On the SIP side it would be good to = have the same URL and make any required routing based on declared media, mode = and language capabilities and preferences.=20 =20 Text capable gateways are not at all as common as VoIP gateways, so if = the PSAP is still in PSTN, there is a need to have a good mechanism for = routing emergency calls from SIP into PSTN through a text capable gateway. I = cannot say that the mechanisms for finding the right gateway and make the = proper address mapping to a PSTN number is solved yet for the text calls, and = it would be excellent if we could have that topic in mind in the = discussions and get proper methods documented. =20 I have drafted, but not yet submitted a registration of a SIP URL and an ENUM subservice for real-time text. It might be helpful for finding text gateways and mapping addresses and (text) numbers, but I would like to = see some scenarios thoroughly discussed before adding SIP URL and another = ENUM subservice. =20 Would there be any benefit of being allowed to enter TXP:112 or = having ENUM to find an appropriate address if I call 112 from a SIP = multimedia phone declaring text capabilities with m=3Dtext in sdp? =20 =20 Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Fran=E7ois D. M=E9nard Sent: Wednesday, February 15, 2006 5:14 PM To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls I made a contribution to CISC NTWG on use of SIP for transporting TDD traffic: http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc I think it may be relevant to ECRIT. -=3DFrancois=3D- On 2/15/06 10:51 AM, "Brian Rosen" wrote: Within the scope of our work, I don=92t see how TDD services are = impacted until we get to the architecture effort, which probably has to have some sections on that subject. With respect to the mapping protocol, I do not believe there is any = impact at all. With respect to the sos service urn, I do not believe there is any = impact at all =20 Ecrit doesn=92t have scope to talk about any kind of gateways or codec support. =20 Ah! My BCP on phones and proxies may need some mention, although this = is the IETF, and I don=92t think the ploy of forcing the entire PSTN to = support TDD just so 9-1-1 TDD will work. That effort would have to be in the general SIP arena. =20 Brian =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Aquil, Kamran Sent: Wednesday, February 15, 2006 10:31 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT support for TTY/TDD calls Folks, Like to know if there are specific ECRIT requirements recognizing = support for Telecommunications Device for the Deaf (TDD) services for the = hearing impaired. If not is this left for VOIP/SIP gateways to perform this requirement of translating the TDD calls to Text and Speech encoding. = Wanted to make sure how ECRIT meet requirement for TDD services. Regards, Kamran Aquil Intelligent Transportation Systems- Division Mitretek Systems. =20 _____ =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=20 Francois D. Menard fmenard@xittelecom.com ------=_NextPart_000_0631_01C6325B.F79D4610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] ECRIT support for TTY/TDD calls

All I get out of this for ecrit is = that we need entries for sos.police.tty in the service = registry

 

Brian

 

From: = Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]
Sent: Wednesday, February = 15, 2006 5:47 PM
To: ecrit@ietf.org; = 'Aquil, Kamran'; br@brianrosen.net; = Fran=E7ois D. M=E9nard
Cc: Gregg = Vanderheiden
Subject: RE: [Ecrit] = ECRIT support for TTY/TDD calls

 

It is quite widely accepted = now that real-time text transmitted with its own text coded RTP payload RFC 4103 = is used to carry text that may be gatewayed to/from TTY/TDD/textphones in = PSTN.

 

 

 

Also other standardisation bodies = have picked up the real-time text concept in IP networks, and pointed at RFC = 4103 (or its compatible predecessor RFC2793 ). E.g. 3GPP and = ETSI.

A couple of years ago we had an = intensive discussion in the SIMPLE mail list about the possibility to use MSRP to = carry the real-time text medium, but we concluded that it would cause too much overhead or too much delay for the users, so that RTP was recommended = instead. The most common use of MSRP is to not transmit until end of sentence, = while for real time text, transmission is required with at most 500 ms interval as = long as there is anything to transmit in order to maintain the real-time = feeling of being in touch in a conversation through this = medium.

 

Quite commonly you will connect a = text RTP stream and an audio RTP stream and possibly a video RTP stream in the = same call, so that you will get an enhanced multimedia phone call with all supported media

 

The ecrit requirements also mentions this = correspondence


   Re4.  Multiple Modes: Multiple communication modes, = such as audio,
      video and text messaging MUST be = supported.

      Motivation: In PSTN, voice and text = telephony (often called TTY or
      textphone in North = America) are the only commonly supported media.
      Emergency calling must support a variety = of media.  Such media
      should include voice, conversational text = (RFC 4103 [9]), instant
      messaging and = video.

 

I am working in a European group = where one of the goals is to agree on handling text users'  requirements = on emergency calling in IP networks. Of course we want to agree on global solutions if possible.

 

Address mapping is one important = and tricky question for text users. It is true that different countries have different approaches on emergency calling with PSTN Text telephones = (TTYs). Some have the same number as voice users, while others have specific = numbers. On the SIP side it would be good to have the same URL and make any required routing based on declared media, mode and language capabilities = and preferences.

 

Text capable gateways are not at = all as common as VoIP gateways, so if the PSAP is still in PSTN, there is a = need to have a good mechanism for routing emergency calls from SIP into PSTN = through a text capable gateway. I cannot say that the mechanisms for finding the = right gateway and make the proper address mapping to a PSTN number is solved = yet for the text calls, and it would be excellent if we could have that topic in = mind in the discussions and get proper methods = documented.

 

I have drafted, but not yet = submitted a registration of a SIP URL and an ENUM subservice for real-time text. It = might be helpful for finding text gateways and mapping addresses and = (text) numbers, but I would like to see some scenarios thoroughly discussed = before adding SIP URL and another ENUM subservice.

 

Would there be any benefit of = being allowed to enter TXP:112    or having ENUM to find = an appropriate address if I   call 112 from a SIP multimedia phone declaring text capabilities with m=3Dtext in = sdp?

 

 

Gunnar

------------------------------------------------------= -----------------------

Gunnar Hellstr=F6m, = Omnitor

-----Original = Message-----
From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On = Behalf Of Fran=E7ois D. M=E9nard
Sent: Wednesday, February = 15, 2006 5:14 PM
To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org
Subject: Re: [Ecrit] = ECRIT support for TTY/TDD calls


I made a contribution to CISC NTWG on use of SIP for transporting TDD = traffic:

http://w= ww.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc

I think it may be relevant to ECRIT.

-=3DFrancois=3D-


On 2/15/06 10:51 AM, "Brian Rosen" <br@brianrosen.net> wrote:

Within the scope of our work, I = don’t see how TDD services are impacted until we get to the architecture = effort, which probably has to have some sections on that subject.
With respect to the mapping protocol, I do not believe there is any = impact at all.
With respect to the sos service urn, I do not believe there is any = impact at all
 
Ecrit doesn’t have scope to talk about any kind of gateways or = codec support.
 
Ah!  My BCP on phones and proxies may need some mention, although = this is the IETF, and I don’t think the ploy of forcing the entire PSTN to support TDD just so 9-1-1 TDD will work.  That effort would have to = be in the general SIP arena.
 
Brian
 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]<= /a> On Behalf Of Aquil, = Kamran
Sent: Wednesday, February = 15, 2006 10:31 AM
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT = support for TTY/TDD calls


Folks,



Like to know if there are specific ECRIT requirements recognizing support for Telecommunications Device for the Deaf (TDD) services for the hearing impaired. If not is this left for VOIP/SIP = gateways to perform this requirement of translating the TDD calls to Text and Speech encoding. Wanted to make sure how ECRIT meet requirement for TDD = services.



Regards,
Kamran Aquil
Intelligent Transportation Systems- Division
Mitretek Systems.

 


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

=



--
Francois D. Menard
fmenard@xittelecom.com

------=_NextPart_000_0631_01C6325B.F79D4610-- --===============0843689201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0843689201==-- From ecrit-bounces@ietf.org Wed Feb 15 18:52:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WS5-0003y5-3h; Wed, 15 Feb 2006 18:52:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WS2-0003wm-P4 for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 18:52:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19231 for ; Wed, 15 Feb 2006 18:51:03 -0500 (EST) Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Wg8-0007jz-7w for ecrit@ietf.org; Wed, 15 Feb 2006 19:07:26 -0500 Received: from MISAN (213.64.230.47) by pne-smtpout2-sn1.fre.skanova.net (7.2.070) id 43EC2A6A0016D559; Thu, 16 Feb 2006 00:52:34 +0100 From: "Gunnar Hellstrom" To: , , "'Aquil, Kamran'" , "=?iso-8859-1?Q?'Fran=E7ois_D._M=E9nard'?=" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Thu, 16 Feb 2006 00:52:31 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <063001c63285$e0734e10$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: 58a894dbf8d0c4c152ea0be9e8cd3d14 Cc: 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1451732395==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1451732395== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C63293.441B9F00" This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C63293.441B9F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable Re: [Ecrit] ECRIT support for TTY/TDD callsWhat would sos.police.tty do = and how would it be invoked? If it could lead to a text capable IP terminal, it should be called sos.police.real-time-text or so. If it helps to find a PSTN based PSAP with text capabilities, it could be called sos.police.txp tty is a US term. Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, February 16, 2006 12:17 AM To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D. M=E9nard' Cc: 'Gregg Vanderheiden' Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls All I get out of this for ecrit is that we need entries for sos.police.= tty in the service registry Brian -------------------------------------------------------------------------= --- -- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: Wednesday, February 15, 2006 5:47 PM To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. M= =E9nard Cc: Gregg Vanderheiden Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls It is quite widely accepted now that real-time text transmitted with it= s own text coded RTP payload RFC 4103 is used to carry text that may be gatewayed to/from TTY/TDD/textphones in PSTN. It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt And it is documented in http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt Also other standardisation bodies have picked up the real-time text concept in IP networks, and pointed at RFC 4103 (or its compatible predecessor RFC2793 ). E.g. 3GPP and ETSI. A couple of years ago we had an intensive discussion in the SIMPLE mail list about the possibility to use MSRP to carry the real-time text medium= , but we concluded that it would cause too much overhead or too much delay = for the users, so that RTP was recommended instead. The most common use of MS= RP is to not transmit until end of sentence, while for real time text, transmission is required with at most 500 ms interval as long as there is anything to transmit in order to maintain the real-time feeling of being = in touch in a conversation through this medium. Quite commonly you will connect a text RTP stream and an audio RTP stre= am and possibly a video RTP stream in the same call, so that you will get an enhanced multimedia phone call with all supported media The ecrit requirements also mentions this correspondence in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt Re4. Multiple Modes: Multiple communication modes, such as audio, video and text messaging MUST be supported. Motivation: In PSTN, voice and text telephony (often called TTY o= r textphone in North America) are the only commonly supported media= =2E Emergency calling must support a variety of media. Such media should include voice, conversational text (RFC 4103 [9]), instant messaging and video. I am working in a European group where one of the goals is to agree on handling text users' requirements on emergency calling in IP networks. O= f course we want to agree on global solutions if possible. Address mapping is one important and tricky question for text users. It= is true that different countries have different approaches on emergency call= ing with PSTN Text telephones (TTYs). Some have the same number as voice user= s, while others have specific numbers. On the SIP side it would be good to h= ave the same URL and make any required routing based on declared media, mode = and language capabilities and preferences. Text capable gateways are not at all as common as VoIP gateways, so if = the PSAP is still in PSTN, there is a need to have a good mechanism for routi= ng emergency calls from SIP into PSTN through a text capable gateway. I cann= ot say that the mechanisms for finding the right gateway and make the proper address mapping to a PSTN number is solved yet for the text calls, and it would be excellent if we could have that topic in mind in the discussions and get proper methods documented. I have drafted, but not yet submitted a registration of a SIP URL and a= n ENUM subservice for real-time text. It might be helpful for finding text gateways and mapping addresses and (text) numbers, but I would like to se= e some scenarios thoroughly discussed before adding SIP URL and another ENU= M subservice. Would there be any benefit of being allowed to enter TXP:112 or havi= ng ENUM to find an appropriate address if I call 112 from a SIP multimedia phone declaring text capabilities with m=3Dtext in sdp? Gunnar -----------------------------------------------------------------------= --- --- Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf= Of Fran=E7ois D. M=E9nard Sent: Wednesday, February 15, 2006 5:14 PM To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls I made a contribution to CISC NTWG on use of SIP for transporting TDD traffic: http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc I think it may be relevant to ECRIT. -=3DFrancois=3D- On 2/15/06 10:51 AM, "Brian Rosen" wrote: Within the scope of our work, I don=92t see how TDD services are impa= cted until we get to the architecture effort, which probably has to have some sections on that subject. With respect to the mapping protocol, I do not believe there is any impact at all. With respect to the sos service urn, I do not believe there is any impact at all Ecrit doesn=92t have scope to talk about any kind of gateways or code= c support. Ah! My BCP on phones and proxies may need some mention, although thi= s is the IETF, and I don=92t think the ploy of forcing the entire PSTN to support TDD just so 9-1-1 TDD will work. That effort would have to be in the general SIP arena. Brian -------------------------------------------------------------------------= --- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f Of Aquil, Kamran Sent: Wednesday, February 15, 2006 10:31 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT support for TTY/TDD calls Folks, Like to know if there are specific ECRIT requirements recognizing support for Telecommunications Device for the Deaf (TDD) services for the hearing impaired. If not is this left for VOIP/SIP gateways to perform th= is requirement of translating the TDD calls to Text and Speech encoding. Wan= ted to make sure how ECRIT meet requirement for TDD services. Regards, Kamran Aquil Intelligent Transportation Systems- Division Mitretek Systems. -------------------------------------------------------------------------= --- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit -- Francois D. Menard fmenard@xittelecom.com ------=_NextPart_000_0067_01C63293.441B9F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable Re: [Ecrit] = ECRIT support for TTY/TDD calls
What=20 would sos.police.tty  do and how would it be = invoked?
 
If it=20 could lead to a text capable IP terminal, it should be called=20 sos.police.real-time-text    or so.
 
If it=20 helps to find a PSTN based PSAP with text capabilities, it could be = called=20 sos.police.txp
 
tty is=20 a US term.
 
Gunnar
 
----------------------------------------------------------------= -------------
Gunnar Hellstr=F6m, = Omnitor
gunnar.hellstrom@omnitor.se
Mob: +46 708 204 288
Phone: +46 8 556 002 03
-----Original Message-----
From: Brian Rosen=20 [mailto:br@brianrosen.net]
Sent: Thursday, February 16, 2006 = 12:17=20 AM
To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran';=20 'Fran=E7ois D. M=E9nard'
Cc: 'Gregg = Vanderheiden'
Subject: RE:=20 [Ecrit] ECRIT support for TTY/TDD calls

All I get = out of this=20 for ecrit is that we need entries for sos.police.tty in the service=20 registry

 

Brian

 

From: Gunnar=20 Hellstrom [mailto:gunnar.hellstrom@omnitor.se]
Sent: Wednesday, February 15, = 2006 5:47=20 PM
To: = ecrit@ietf.org;=20 'Aquil, Kamran'; br@brianrosen.net;=20 Fran=E7ois D. M=E9nard
Cc: Gregg=20 Vanderheiden
Subject: RE:=20 [Ecrit] ECRIT support for TTY/TDD = calls

 

It is quite = widely=20 accepted now that real-time text transmitted with its own text = coded RTP=20 payload RFC 4103 is used to carry text that may be gatewayed to/from=20 TTY/TDD/textphones in PSTN.

 

It is = discussed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt=

 

And it is = documented=20 in http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.t= xt

 

Also other=20 standardisation bodies have picked up the real-time text concept in IP = networks, and pointed at RFC 4103 (or its compatible predecessor = RFC2793 ).=20 E.g. 3GPP and ETSI.

A couple of = years ago=20 we had an intensive discussion in the SIMPLE mail list about the = possibility=20 to use MSRP to carry the real-time text medium, but we concluded that = it would=20 cause too much overhead or too much delay for the users, so that RTP = was=20 recommended instead. The most common use of MSRP is to not transmit = until end=20 of sentence, while for real time text, transmission is required with = at most=20 500 ms interval as long as there is anything to transmit in order to = maintain=20 the real-time feeling of being in touch in a conversation through this = medium.

 

Quite = commonly you=20 will connect a text RTP stream and an audio RTP stream and possibly a = video=20 RTP stream in the same call, so that you will get an enhanced = multimedia phone=20 call with all supported media

 

The ecrit requirements = also=20 mentions this correspondence

in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.tx= t


   = Re4. =20 Multiple Modes: Multiple communication modes, such as=20 audio,
      video and text messaging MUST = be=20 supported.

      Motivation: In PSTN, = voice=20 and text telephony (often called TTY = or
     =20 textphone in North America) are the = only=20 commonly supported media.
      Emergency = calling=20 must support a variety of media.  Such=20 media
      should include voice, = conversational=20 text (RFC 4103 [9]), instant
      = messaging and=20 video.

 

I am = working in a=20 European group where one of the goals is to agree on = handling text users'=20  requirements on emergency calling in IP networks. Of course we = want to=20 agree on global solutions if = possible.

 

Address = mapping is=20 one important and tricky question for text users. It is true that = different=20 countries have different approaches on emergency calling with PSTN = Text=20 telephones (TTYs). Some have the same number as voice users, while = others have=20 specific numbers. On the SIP side it would be good to have the = same URL=20 and make any required routing based on declared media, mode and = language=20 capabilities and preferences.

 

Text = capable gateways=20 are not at all as common as VoIP gateways, so if the PSAP is still in = PSTN,=20 there is a need to have a good mechanism for routing emergency calls = from SIP=20 into PSTN through a text capable gateway. I cannot say that the = mechanisms for=20 finding the right gateway and make the proper address mapping to a = PSTN number=20 is solved yet for the text calls, and it would be excellent if we = could have=20 that topic in mind in the discussions and get proper methods=20 documented.

 

I have = drafted, but=20 not yet submitted a registration of a SIP URL and an ENUM subservice = for=20 real-time text. It might be helpful for finding text gateways=20 and mapping addresses and (text) numbers, but I would like = to see=20 some scenarios thoroughly discussed before adding SIP URL and another = ENUM=20 subservice.

 

Would there be=20 any benefit of being allowed to enter TXP:112    or=20 having ENUM to find an appropriate address if I   call=20 112 from a SIP multimedia phone declaring text = capabilities=20 with m=3Dtext in sdp?

 

 

Gunnar

------------------------------------------------------------------= -----------

Gunnar Hellstr=F6m,=20 Omnitor

gunnar.hellstrom@omnitor.se

-----Original=20 Message-----
From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Fran=E7ois D.=20 M=E9nard
Sent: = Wednesday,=20 February 15, 2006 5:14 PM
To: br@brianrosen.net; 'Aquil, Kamran';=20 ecrit@ietf.org
Subject: Re:=20 [Ecrit] ECRIT support for TTY/TDD calls


I = made a=20 contribution to CISC NTWG on use of SIP for transporting TDD=20 traffic:

http://w= ww.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc

I=20 think it may be relevant to = ECRIT.

-=3DFrancois=3D-


On 2/15/06=20 10:51 AM, "Brian Rosen" <br@brianrosen.net>=20 wrote:

Within the = scope of=20 our work, I don=92t see how TDD services are impacted until we get = to the=20 architecture effort, which probably has to have some sections on = that=20 subject.
With respect to the mapping protocol, I do not believe = there is=20 any impact at all.
With respect to the sos service urn, I do not = believe=20 there is any impact at all
 
Ecrit doesn=92t have scope = to talk=20 about any kind of gateways or codec support.
 
Ah! =  My BCP=20 on phones and proxies may need some mention, although this is the = IETF, and=20 I don=92t think the ploy of forcing the entire PSTN to support TDD = just so=20 9-1-1 TDD will work.  That effort would have to be in the = general SIP=20 arena.
 
Brian
 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]<= /A>=20 On Behalf Of Aquil,=20 Kamran
Sent: = Wednesday,=20 February 15, 2006 10:31 AM
To: = ecrit@ietf.org
Subject: [Ecrit] ECRIT = support for=20 TTY/TDD calls


Folks,



Like to=20 know if there are specific ECRIT requirements recognizing support = for=20 Telecommunications = Device for=20 the Deaf (TDD) services for the hearing impaired. If not is this = left for=20 VOIP/SIP gateways to perform this requirement of translating the TDD = calls=20 to Text and Speech encoding. Wanted to make sure how ECRIT meet = requirement=20 for TDD services.



Regards,
Kamran=20 Aquil
Intelligent Transportation Systems- Division
Mitretek=20 Systems.

 


_______________________________________________
Ecrit=20 mailing=20 = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit



--=20
Francois D. Menard
fmenard@xittelecom.com

------=_NextPart_000_0067_01C63293.441B9F00-- --===============1451732395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1451732395==-- From ecrit-bounces@ietf.org Wed Feb 15 19:44:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9XFa-0007el-6e; Wed, 15 Feb 2006 19:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9XFX-0007d2-Cb for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 19:44:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29664 for ; Wed, 15 Feb 2006 19:42:12 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9XTd-0003Km-B4 for ecrit@ietf.org; Wed, 15 Feb 2006 19:58:35 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 15 Feb 2006 16:43:48 -0800 X-IronPort-AV: i="4.02,118,1139212800"; d="scan'208,217"; a="1776761286:sNHT68240308" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1G0hljt001303; Wed, 15 Feb 2006 16:43:47 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 16:43:46 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 16:43:46 -0800 From: "Marc Linsner" To: , "'Gunnar Hellstrom'" , , "'Aquil, Kamran'" , "=?iso-8859-1?Q?'Fran=E7ois_D._M=E9nard'?=" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Wed, 15 Feb 2006 19:43:44 -0500 Message-ID: <007901c63292$0ac6e9e0$1b103c0a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYygc9+2x9oXF1jSw2czQoct3KIHgAA8TJwAAMXf0A= In-Reply-To: <063001c63285$e0734e10$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 16 Feb 2006 00:43:46.0350 (UTC) FILETIME=[0B56F4E0:01C63292] X-Spam-Score: 1.8 (+) X-Scan-Signature: 63de1eb80dd4230367fc1d266729643d Cc: 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1084125597==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1084125597== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01C63268.21F0E1E0" This is a multi-part message in MIME format. ------=_NextPart_000_007A_01C63268.21F0E1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So the UA must know this? Not the proxy...? =20 -Marc- _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Brian Rosen Sent: Wednesday, February 15, 2006 6:17 PM To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D. M=E9nard' Cc: 'Gregg Vanderheiden' Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls All I get out of this for ecrit is that we need entries for = sos.police.tty in the service registry =20 Brian =20 _____ =20 From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: Wednesday, February 15, 2006 5:47 PM To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. = M=E9nard Cc: Gregg Vanderheiden Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls =20 It is quite widely accepted now that real-time text transmitted with its = own text coded RTP payload RFC 4103 is used to carry text that may be = gatewayed to/from TTY/TDD/textphones in PSTN. =20 It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt =20 And it is documented in http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt =20 Also other standardisation bodies have picked up the real-time text = concept in IP networks, and pointed at RFC 4103 (or its compatible predecessor RFC2793 ). E.g. 3GPP and ETSI. A couple of years ago we had an intensive discussion in the SIMPLE mail = list about the possibility to use MSRP to carry the real-time text medium, = but we concluded that it would cause too much overhead or too much delay for = the users, so that RTP was recommended instead. The most common use of MSRP = is to not transmit until end of sentence, while for real time text, transmission is required with at most 500 ms interval as long as there = is anything to transmit in order to maintain the real-time feeling of being = in touch in a conversation through this medium. =20 Quite commonly you will connect a text RTP stream and an audio RTP = stream and possibly a video RTP stream in the same call, so that you will get = an enhanced multimedia phone call with all supported media=20 =20 The ecrit requirements also mentions this correspondence in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt Re4. Multiple Modes: Multiple communication modes, such as audio, video and text messaging MUST be supported. Motivation: In PSTN, voice and text telephony (often called TTY or textphone in North America) are the only commonly supported media. Emergency calling must support a variety of media. Such media should include voice, conversational text (RFC 4103 [9]), instant messaging and video. =20 I am working in a European group where one of the goals is to agree on handling text users' requirements on emergency calling in IP networks. = Of course we want to agree on global solutions if possible. =20 Address mapping is one important and tricky question for text users. It = is true that different countries have different approaches on emergency = calling with PSTN Text telephones (TTYs). Some have the same number as voice = users, while others have specific numbers. On the SIP side it would be good to = have the same URL and make any required routing based on declared media, mode = and language capabilities and preferences.=20 =20 Text capable gateways are not at all as common as VoIP gateways, so if = the PSAP is still in PSTN, there is a need to have a good mechanism for = routing emergency calls from SIP into PSTN through a text capable gateway. I = cannot say that the mechanisms for finding the right gateway and make the = proper address mapping to a PSTN number is solved yet for the text calls, and = it would be excellent if we could have that topic in mind in the = discussions and get proper methods documented. =20 I have drafted, but not yet submitted a registration of a SIP URL and an ENUM subservice for real-time text. It might be helpful for finding text gateways and mapping addresses and (text) numbers, but I would like to = see some scenarios thoroughly discussed before adding SIP URL and another = ENUM subservice. =20 Would there be any benefit of being allowed to enter TXP:112 or = having ENUM to find an appropriate address if I call 112 from a SIP = multimedia phone declaring text capabilities with m=3Dtext in sdp? =20 =20 Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Fran=E7ois D. M=E9nard Sent: Wednesday, February 15, 2006 5:14 PM To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls I made a contribution to CISC NTWG on use of SIP for transporting TDD traffic: http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc I think it may be relevant to ECRIT. -=3DFrancois=3D- On 2/15/06 10:51 AM, "Brian Rosen" wrote: Within the scope of our work, I don=92t see how TDD services are = impacted until we get to the architecture effort, which probably has to have some sections on that subject. With respect to the mapping protocol, I do not believe there is any = impact at all. With respect to the sos service urn, I do not believe there is any = impact at all =20 Ecrit doesn=92t have scope to talk about any kind of gateways or codec support. =20 Ah! My BCP on phones and proxies may need some mention, although this = is the IETF, and I don=92t think the ploy of forcing the entire PSTN to = support TDD just so 9-1-1 TDD will work. That effort would have to be in the general SIP arena. =20 Brian =20 _____ =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Aquil, Kamran Sent: Wednesday, February 15, 2006 10:31 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT support for TTY/TDD calls Folks, Like to know if there are specific ECRIT requirements recognizing = support for Telecommunications Device for the Deaf (TDD) services for the = hearing impaired. If not is this left for VOIP/SIP gateways to perform this requirement of translating the TDD calls to Text and Speech encoding. = Wanted to make sure how ECRIT meet requirement for TDD services. Regards, Kamran Aquil Intelligent Transportation Systems- Division Mitretek Systems. =20 _____ =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=20 Francois D. Menard fmenard@xittelecom.com ------=_NextPart_000_007A_01C63268.21F0E1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] = ECRIT support for TTY/TDD calls
So the UA must know this?  Not the=20 proxy...?
 
-Marc-

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian=20 Rosen
Sent: Wednesday, February 15, 2006 6:17 = PM
To:=20 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D.=20 M=E9nard'
Cc: 'Gregg Vanderheiden'
Subject: RE: = [Ecrit]=20 ECRIT support for TTY/TDD calls

All I get = out of this=20 for ecrit is that we need entries for sos.police.tty in the service=20 registry

 

Brian

 

From: Gunnar=20 Hellstrom [mailto:gunnar.hellstrom@omnitor.se]
Sent: Wednesday, February 15, = 2006 5:47=20 PM
To: = ecrit@ietf.org;=20 'Aquil, Kamran'; br@brianrosen.net;=20 Fran=E7ois D. M=E9nard
Cc: Gregg=20 Vanderheiden
Subject: RE:=20 [Ecrit] ECRIT support for TTY/TDD = calls

 

It is quite = widely=20 accepted now that real-time text transmitted with its own text = coded RTP=20 payload RFC 4103 is used to carry text that may be gatewayed to/from=20 TTY/TDD/textphones in PSTN.

 

It is = discussed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt=

 

And it is = documented=20 in http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.t= xt

 

Also other=20 standardisation bodies have picked up the real-time text concept in IP = networks, and pointed at RFC 4103 (or its compatible predecessor = RFC2793 ).=20 E.g. 3GPP and ETSI.

A couple of = years ago=20 we had an intensive discussion in the SIMPLE mail list about the = possibility=20 to use MSRP to carry the real-time text medium, but we concluded that = it would=20 cause too much overhead or too much delay for the users, so that RTP = was=20 recommended instead. The most common use of MSRP is to not transmit = until end=20 of sentence, while for real time text, transmission is required with = at most=20 500 ms interval as long as there is anything to transmit in order to = maintain=20 the real-time feeling of being in touch in a conversation through this = medium.

 

Quite = commonly you=20 will connect a text RTP stream and an audio RTP stream and possibly a = video=20 RTP stream in the same call, so that you will get an enhanced = multimedia phone=20 call with all supported media

 

The ecrit requirements = also=20 mentions this correspondence

in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.tx= t


   = Re4. =20 Multiple Modes: Multiple communication modes, such as=20 audio,
      video and text messaging MUST = be=20 supported.

      Motivation: In PSTN, = voice=20 and text telephony (often called TTY = or
     =20 textphone in North America) are the = only=20 commonly supported media.
      Emergency = calling=20 must support a variety of media.  Such=20 media
      should include voice, = conversational=20 text (RFC 4103 [9]), instant
      = messaging and=20 video.

 

I am = working in a=20 European group where one of the goals is to agree on = handling text users'=20  requirements on emergency calling in IP networks. Of course we = want to=20 agree on global solutions if = possible.

 

Address = mapping is=20 one important and tricky question for text users. It is true that = different=20 countries have different approaches on emergency calling with PSTN = Text=20 telephones (TTYs). Some have the same number as voice users, while = others have=20 specific numbers. On the SIP side it would be good to have the = same URL=20 and make any required routing based on declared media, mode and = language=20 capabilities and preferences.

 

Text = capable gateways=20 are not at all as common as VoIP gateways, so if the PSAP is still in = PSTN,=20 there is a need to have a good mechanism for routing emergency calls = from SIP=20 into PSTN through a text capable gateway. I cannot say that the = mechanisms for=20 finding the right gateway and make the proper address mapping to a = PSTN number=20 is solved yet for the text calls, and it would be excellent if we = could have=20 that topic in mind in the discussions and get proper methods=20 documented.

 

I have = drafted, but=20 not yet submitted a registration of a SIP URL and an ENUM subservice = for=20 real-time text. It might be helpful for finding text gateways=20 and mapping addresses and (text) numbers, but I would like = to see=20 some scenarios thoroughly discussed before adding SIP URL and another = ENUM=20 subservice.

 

Would there be=20 any benefit of being allowed to enter TXP:112    or=20 having ENUM to find an appropriate address if I   call=20 112 from a SIP multimedia phone declaring text = capabilities=20 with m=3Dtext in sdp?

 

 

Gunnar

------------------------------------------------------------------= -----------

Gunnar Hellstr=F6m,=20 Omnitor

gunnar.hellstrom@omnitor.se

-----Original=20 Message-----
From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Fran=E7ois D.=20 M=E9nard
Sent: = Wednesday,=20 February 15, 2006 5:14 PM
To: br@brianrosen.net; 'Aquil, Kamran';=20 ecrit@ietf.org
Subject: Re:=20 [Ecrit] ECRIT support for TTY/TDD calls


I = made a=20 contribution to CISC NTWG on use of SIP for transporting TDD=20 traffic:

http://w= ww.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc

I=20 think it may be relevant to = ECRIT.

-=3DFrancois=3D-


On 2/15/06=20 10:51 AM, "Brian Rosen" <br@brianrosen.net>=20 wrote:

Within the = scope of=20 our work, I don=92t see how TDD services are impacted until we get = to the=20 architecture effort, which probably has to have some sections on = that=20 subject.
With respect to the mapping protocol, I do not believe = there is=20 any impact at all.
With respect to the sos service urn, I do not = believe=20 there is any impact at all
 
Ecrit doesn=92t have scope = to talk=20 about any kind of gateways or codec support.
 
Ah! =  My BCP=20 on phones and proxies may need some mention, although this is the = IETF, and=20 I don=92t think the ploy of forcing the entire PSTN to support TDD = just so=20 9-1-1 TDD will work.  That effort would have to be in the = general SIP=20 arena.
 
Brian
 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]<= /A>=20 On Behalf Of Aquil,=20 Kamran
Sent: = Wednesday,=20 February 15, 2006 10:31 AM
To: = ecrit@ietf.org
Subject: [Ecrit] ECRIT = support for=20 TTY/TDD calls


Folks,



Like to=20 know if there are specific ECRIT requirements recognizing support = for=20 Telecommunications = Device for=20 the Deaf (TDD) services for the hearing impaired. If not is this = left for=20 VOIP/SIP gateways to perform this requirement of translating the TDD = calls=20 to Text and Speech encoding. Wanted to make sure how ECRIT meet = requirement=20 for TDD services.



Regards,
Kamran=20 Aquil
Intelligent Transportation Systems- Division
Mitretek=20 Systems.

 


_______________________________________________
Ecrit=20 mailing=20 = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit



--=20
Francois D. Menard
fmenard@xittelecom.com

------=_NextPart_000_007A_01C63268.21F0E1E0-- --===============1084125597== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1084125597==-- From ecrit-bounces@ietf.org Wed Feb 15 20:06:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9XbC-0006Ig-N8; Wed, 15 Feb 2006 20:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9XbA-0006Gz-Bn for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 20:06:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01255 for ; Wed, 15 Feb 2006 20:04:33 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9XpI-00043f-2z for ecrit@ietf.org; Wed, 15 Feb 2006 20:20:56 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1G15oQ0029128 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 15 Feb 2006 20:05:59 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <232E09D4-6327-4A28-9A1D-D469E4CEA48D@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls Date: Wed, 15 Feb 2006 20:05:46 -0500 To: "Gunnar Hellstrom" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Content-Transfer-Encoding: quoted-printable Cc: 'Gregg Vanderheiden' , "'Aquil, Kamran'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think we want a service label for each media type. While =20 *today* there are PSAPs that only answer TTY calls, is this likely to =20= make sense in an all-IP PSAP environment where the media would =20 terminate on the same PC that's used for IM, video and so on? Why =20 would you do this? Rather than trying to put SDP in a URN, maybe the better solution is =20 to route to one PSAP for the emergency service and have that PSAP =20 then redirect the call based on the full SDP information, if this =20 becomes necessary. That way, you can deal with situations where the =20 caller can handle a variety of means of communications, albeit with =20 different ease, and the PSAP has access to the full media information. Since this could be added on later if necessary, once we know whether =20= anybody actually needs this, maybe it's better to avoid gratuitous =20 complexity, both in terms of protocol operation, testing (yet another =20= thing a mapping protocol has to test) and user agents. Henning On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > What would sos.police.tty do and how would it be invoked? > > If it could lead to a text capable IP terminal, it should be called =20= > sos.police.real-time-text or so. > > If it helps to find a PSTN based PSAP with text capabilities, it =20 > could be called sos.police.txp > > tty is a US term. > > Gunnar > > ----------------------------------------------------------------------=20= > ------- > Gunnar Hellstr=F6m, Omnitor > gunnar.hellstrom@omnitor.se > Mob: +46 708 204 288 > Phone: +46 8 556 002 03 > www.omnitor.se > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, February 16, 2006 12:17 AM > To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois =20= > D. M=E9nard' > Cc: 'Gregg Vanderheiden' > Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > All I get out of this for ecrit is that we need entries for =20 > sos.police.tty in the service registry > > > > Brian > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Wednesday, February 15, 2006 5:47 PM > To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. =20= > M=E9nard > Cc: Gregg Vanderheiden > Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > > > It is quite widely accepted now that real-time text transmitted =20 > with its own text coded RTP payload RFC 4103 is used to carry text =20 > that may be gatewayed to/from TTY/TDD/textphones in PSTN. > > > > It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-=20 > sipping-toip-03.txt > > > > And it is documented in http://www.ietf.org/internet-drafts/draft-=20 > sinnreich-sipdev-req-08.txt > > > > Also other standardisation bodies have picked up the real-time text =20= > concept in IP networks, and pointed at RFC 4103 (or its compatible =20 > predecessor RFC2793 ). E.g. 3GPP and ETSI. > > A couple of years ago we had an intensive discussion in the SIMPLE =20 > mail list about the possibility to use MSRP to carry the real-time =20 > text medium, but we concluded that it would cause too much overhead =20= > or too much delay for the users, so that RTP was recommended =20 > instead. The most common use of MSRP is to not transmit until end =20 > of sentence, while for real time text, transmission is required =20 > with at most 500 ms interval as long as there is anything to =20 > transmit in order to maintain the real-time feeling of being in =20 > touch in a conversation through this medium. > > > > Quite commonly you will connect a text RTP stream and an audio RTP =20 > stream and possibly a video RTP stream in the same call, so that =20 > you will get an enhanced multimedia phone call with all supported =20 > media > > > > The ecrit requirements also mentions this correspondence > > in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt > > > Re4. Multiple Modes: Multiple communication modes, such as audio, > video and text messaging MUST be supported. > > Motivation: In PSTN, voice and text telephony (often called =20 > TTY or > textphone in North America) are the only commonly supported =20 > media. > Emergency calling must support a variety of media. Such media > should include voice, conversational text (RFC 4103 [9]), =20 > instant > messaging and video. > > > > I am working in a European group where one of the goals is to agree =20= > on handling text users' requirements on emergency calling in IP =20 > networks. Of course we want to agree on global solutions if possible. > > > > Address mapping is one important and tricky question for text =20 > users. It is true that different countries have different =20 > approaches on emergency calling with PSTN Text telephones (TTYs). =20 > Some have the same number as voice users, while others have =20 > specific numbers. On the SIP side it would be good to have the same =20= > URL and make any required routing based on declared media, mode and =20= > language capabilities and preferences. > > > > Text capable gateways are not at all as common as VoIP gateways, so =20= > if the PSAP is still in PSTN, there is a need to have a good =20 > mechanism for routing emergency calls from SIP into PSTN through a =20 > text capable gateway. I cannot say that the mechanisms for finding =20 > the right gateway and make the proper address mapping to a PSTN =20 > number is solved yet for the text calls, and it would be excellent =20 > if we could have that topic in mind in the discussions and get =20 > proper methods documented. > > > > I have drafted, but not yet submitted a registration of a SIP URL =20 > and an ENUM subservice for real-time text. It might be helpful for =20 > finding text gateways and mapping addresses and (text) numbers, but =20= > I would like to see some scenarios thoroughly discussed before =20 > adding SIP URL and another ENUM subservice. > > > > Would there be any benefit of being allowed to enter TXP:112 or =20 > having ENUM to find an appropriate address if I call 112 from a =20 > SIP multimedia phone declaring text capabilities with m=3Dtext in sdp? > > > > > > Gunnar > > ----------------------------------------------------------------------=20= > ------- > > Gunnar Hellstr=F6m, Omnitor > > gunnar.hellstrom@omnitor.se > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On =20 > Behalf Of Fran=E7ois D. M=E9nard > Sent: Wednesday, February 15, 2006 5:14 PM > To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls > > > I made a contribution to CISC NTWG on use of SIP for transporting =20 > TDD traffic: > > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc > > I think it may be relevant to ECRIT. > > -=3DFrancois=3D- > > > On 2/15/06 10:51 AM, "Brian Rosen" wrote: > > Within the scope of our work, I don=92t see how TDD services are =20 > impacted until we get to the architecture effort, which probably =20 > has to have some sections on that subject. > With respect to the mapping protocol, I do not believe there is any =20= > impact at all. > With respect to the sos service urn, I do not believe there is any =20 > impact at all > > Ecrit doesn=92t have scope to talk about any kind of gateways or =20 > codec support. > > Ah! My BCP on phones and proxies may need some mention, although =20 > this is the IETF, and I don=92t think the ploy of forcing the entire =20= > PSTN to support TDD just so 9-1-1 TDD will work. That effort would =20= > have to be in the general SIP arena. > > Brian > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On =20 > Behalf Of Aquil, Kamran > Sent: Wednesday, February 15, 2006 10:31 AM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT support for TTY/TDD calls > > > Folks, > > > > Like to know if there are specific ECRIT requirements recognizing =20 > support for Telecommunications Device for the Deaf (TDD) services =20 > for the hearing impaired. If not is this left for VOIP/SIP gateways =20= > to perform this requirement of translating the TDD calls to Text =20 > and Speech encoding. Wanted to make sure how ECRIT meet requirement =20= > for TDD services. > > > > Regards, > Kamran Aquil > Intelligent Transportation Systems- Division > Mitretek Systems. > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > --=20 > Francois D. Menard > fmenard@xittelecom.com > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 15 21:17:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Yi9-0005UT-Fe; Wed, 15 Feb 2006 21:17:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Yi8-0005Sv-6S for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 21:17:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05696 for ; Wed, 15 Feb 2006 21:15:46 -0500 (EST) Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9YwE-0006gW-G3 for ecrit@ietf.org; Wed, 15 Feb 2006 21:32:11 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F9Yhi-0005H1-K3; Wed, 15 Feb 2006 20:17:11 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Gunnar Hellstrom'" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Wed, 15 Feb 2006 21:17:15 -0500 Message-ID: <070c01c6329f$1d36b030$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <232E09D4-6327-4A28-9A1D-D469E4CEA48D@cs.columbia.edu> Thread-Index: AcYylSuffn/d2sDoQfOvfrsJpoptrQACQJSw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: quoted-printable Cc: "'Aquil, Kamran'" , ecrit@ietf.org, 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If a country has a dialstring that is the text-to-police dialstring, = then we must map it into a unique urn unless we know that in every instance we = can differentiate the text calls from voice calls. I suspect that's hard. With a SIP URI, you know you can use media negotiation to get the text codec, and if the PSAP accepts the text call, then the mapper will have = the same result for sos.police.txt as sos.police. If you have to map = instead to some older technology, you have to differentiate (that is, the mapping = will be different). It may be that we make an assumption that the mapping function does not yield a URI if the PSAP doesn't accept a call with a negotiated text = codec, which would mean we don't need to have sos.police.txt. That would force backwards compatibility to existing systems when mapping fails. That's = not terrible, but I thought it made more sense to let mapping yield a URI = that resolved to the older technology. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Wednesday, February 15, 2006 8:06 PM To: Gunnar Hellstrom Cc: br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D. = M=E9nard' ; 'Gregg Vanderheiden' Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls I don't think we want a service label for each media type. While =20 *today* there are PSAPs that only answer TTY calls, is this likely to =20 make sense in an all-IP PSAP environment where the media would =20 terminate on the same PC that's used for IM, video and so on? Why =20 would you do this? Rather than trying to put SDP in a URN, maybe the better solution is =20 to route to one PSAP for the emergency service and have that PSAP =20 then redirect the call based on the full SDP information, if this =20 becomes necessary. That way, you can deal with situations where the =20 caller can handle a variety of means of communications, albeit with =20 different ease, and the PSAP has access to the full media information. Since this could be added on later if necessary, once we know whether =20 anybody actually needs this, maybe it's better to avoid gratuitous =20 complexity, both in terms of protocol operation, testing (yet another =20 thing a mapping protocol has to test) and user agents. Henning On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > What would sos.police.tty do and how would it be invoked? > > If it could lead to a text capable IP terminal, it should be called =20 > sos.police.real-time-text or so. > > If it helps to find a PSTN based PSAP with text capabilities, it =20 > could be called sos.police.txp > > tty is a US term. > > Gunnar > > ---------------------------------------------------------------------- = > ------- > Gunnar Hellstr=F6m, Omnitor > gunnar.hellstrom@omnitor.se > Mob: +46 708 204 288 > Phone: +46 8 556 002 03 > www.omnitor.se > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, February 16, 2006 12:17 AM > To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois =20 > D. M=E9nard' > Cc: 'Gregg Vanderheiden' > Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > All I get out of this for ecrit is that we need entries for =20 > sos.police.tty in the service registry > > > > Brian > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Wednesday, February 15, 2006 5:47 PM > To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. = > M=E9nard > Cc: Gregg Vanderheiden > Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > > > It is quite widely accepted now that real-time text transmitted =20 > with its own text coded RTP payload RFC 4103 is used to carry text =20 > that may be gatewayed to/from TTY/TDD/textphones in PSTN. > > > > It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-=20 > sipping-toip-03.txt > > > > And it is documented in http://www.ietf.org/internet-drafts/draft-=20 > sinnreich-sipdev-req-08.txt > > > > Also other standardisation bodies have picked up the real-time text =20 > concept in IP networks, and pointed at RFC 4103 (or its compatible =20 > predecessor RFC2793 ). E.g. 3GPP and ETSI. > > A couple of years ago we had an intensive discussion in the SIMPLE =20 > mail list about the possibility to use MSRP to carry the real-time =20 > text medium, but we concluded that it would cause too much overhead =20 > or too much delay for the users, so that RTP was recommended =20 > instead. The most common use of MSRP is to not transmit until end =20 > of sentence, while for real time text, transmission is required =20 > with at most 500 ms interval as long as there is anything to =20 > transmit in order to maintain the real-time feeling of being in =20 > touch in a conversation through this medium. > > > > Quite commonly you will connect a text RTP stream and an audio RTP =20 > stream and possibly a video RTP stream in the same call, so that =20 > you will get an enhanced multimedia phone call with all supported =20 > media > > > > The ecrit requirements also mentions this correspondence > > in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt > > > Re4. Multiple Modes: Multiple communication modes, such as audio, > video and text messaging MUST be supported. > > Motivation: In PSTN, voice and text telephony (often called =20 > TTY or > textphone in North America) are the only commonly supported =20 > media. > Emergency calling must support a variety of media. Such media > should include voice, conversational text (RFC 4103 [9]), =20 > instant > messaging and video. > > > > I am working in a European group where one of the goals is to agree =20 > on handling text users' requirements on emergency calling in IP =20 > networks. Of course we want to agree on global solutions if possible. > > > > Address mapping is one important and tricky question for text =20 > users. It is true that different countries have different =20 > approaches on emergency calling with PSTN Text telephones (TTYs). =20 > Some have the same number as voice users, while others have =20 > specific numbers. On the SIP side it would be good to have the same =20 > URL and make any required routing based on declared media, mode and =20 > language capabilities and preferences. > > > > Text capable gateways are not at all as common as VoIP gateways, so =20 > if the PSAP is still in PSTN, there is a need to have a good =20 > mechanism for routing emergency calls from SIP into PSTN through a =20 > text capable gateway. I cannot say that the mechanisms for finding =20 > the right gateway and make the proper address mapping to a PSTN =20 > number is solved yet for the text calls, and it would be excellent =20 > if we could have that topic in mind in the discussions and get =20 > proper methods documented. > > > > I have drafted, but not yet submitted a registration of a SIP URL =20 > and an ENUM subservice for real-time text. It might be helpful for =20 > finding text gateways and mapping addresses and (text) numbers, but =20 > I would like to see some scenarios thoroughly discussed before =20 > adding SIP URL and another ENUM subservice. > > > > Would there be any benefit of being allowed to enter TXP:112 or =20 > having ENUM to find an appropriate address if I call 112 from a =20 > SIP multimedia phone declaring text capabilities with m=3Dtext in sdp? > > > > > > Gunnar > > ---------------------------------------------------------------------- = > ------- > > Gunnar Hellstr=F6m, Omnitor > > gunnar.hellstrom@omnitor.se > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On =20 > Behalf Of Fran=E7ois D. M=E9nard > Sent: Wednesday, February 15, 2006 5:14 PM > To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls > > > I made a contribution to CISC NTWG on use of SIP for transporting =20 > TDD traffic: > > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc > > I think it may be relevant to ECRIT. > > -=3DFrancois=3D- > > > On 2/15/06 10:51 AM, "Brian Rosen" wrote: > > Within the scope of our work, I don=92t see how TDD services are =20 > impacted until we get to the architecture effort, which probably =20 > has to have some sections on that subject. > With respect to the mapping protocol, I do not believe there is any =20 > impact at all. > With respect to the sos service urn, I do not believe there is any =20 > impact at all > > Ecrit doesn=92t have scope to talk about any kind of gateways or =20 > codec support. > > Ah! My BCP on phones and proxies may need some mention, although =20 > this is the IETF, and I don=92t think the ploy of forcing the entire =20 > PSTN to support TDD just so 9-1-1 TDD will work. That effort would =20 > have to be in the general SIP arena. > > Brian > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On =20 > Behalf Of Aquil, Kamran > Sent: Wednesday, February 15, 2006 10:31 AM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT support for TTY/TDD calls > > > Folks, > > > > Like to know if there are specific ECRIT requirements recognizing =20 > support for Telecommunications Device for the Deaf (TDD) services =20 > for the hearing impaired. If not is this left for VOIP/SIP gateways =20 > to perform this requirement of translating the TDD calls to Text =20 > and Speech encoding. Wanted to make sure how ECRIT meet requirement =20 > for TDD services. > > > > Regards, > Kamran Aquil > Intelligent Transportation Systems- Division > Mitretek Systems. > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > --=20 > Francois D. Menard > fmenard@xittelecom.com > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 15 21:18:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Yj2-0006Zi-Jn; Wed, 15 Feb 2006 21:18:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Yiz-0006Vh-1h for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 21:18:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06004 for ; Wed, 15 Feb 2006 21:16:39 -0500 (EST) From: Rockford9@aol.com Received: from imo-d21.mx.aol.com ([205.188.144.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Yx2-0006mx-Og for ecrit@ietf.org; Wed, 15 Feb 2006 21:33:03 -0500 Received: from Rockford9@aol.com by imo-d21.mx.aol.com (mail_out_v38_r7.3.) id c.75.55537d35 (17228); Wed, 15 Feb 2006 21:18:04 -0500 (EST) Message-ID: <75.55537d35.31253adb@aol.com> Date: Wed, 15 Feb 2006 21:18:03 EST Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls To: mlinsner@cisco.com, br@brianrosen.net, gunnar.hellstrom@omnitor.se, ecrit@ietf.org, kamran.aquil@mitretek.org, fmenard@xittelecom.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: fc231bf912a450f71747fa7a4e3e2f5a Cc: gv@trace.wisc.edu X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1225123842==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1225123842== Content-Type: multipart/alternative; boundary="-----------------------------1140056283" -------------------------------1140056283 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IApJIGhhdmUgYSBxdWVzdGlvbiBvbiB3aGF0IGlzIGJlaW5nIGRpc2N1c3NlZC4gQXJlIHlv dSBvbmx5IGRpc2N1c3NpbmcgIApUVFkvVEREIGRldmljZXMgdXNlZCB2aWEgUFNUTiBzcGVj aWZpY2FsbHkgYnkgZGVhZiB0byBhY2Nlc3MgZW1lcmdlbmN5IHNlcnZpY2VzPyAgCldhbnRp bmcgdG8gY2xhcmlmeSB0aGF0IHlvdSBhcmUgbm90IGRpc2N1c3NpbmcgYW55IHRleHQgdXNl ciBhY2Nlc3MgYmV5b25kIHRoYXQsIAogc2luY2UgdGhhdCBjb3VsZCBiZSB1c2VkIGJ5IGFu eW9uZSB0byBhY2Nlc3MgZW1lcmdlbmN5IHNlcnZpY2VzIGFuZCBzbyAKc2hvdWxkICBoYXZl IG5vIHNwZWNpYWwgVFRZL1RERCB0eXBlIGhhbmRsaW5nLgogClRoYW5rcyBmb3IgYXNzaXN0 YW5jZS4KIApSaWNrIEpvbmVzCiAKSW4gYSBtZXNzYWdlIGRhdGVkIDIvMTUvMjAwNiA3OjQ3 OjMzIFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZSwgIAptbGluc25lckBjaXNjby5jb20gd3Jp dGVzOgoKU28gdGhlIFVBIG11c3Qga25vdyB0aGlzPyAgTm90IHRoZSAgcHJveHkuLi4/CiAK LU1hcmMtCgoKIApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206 IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIApCcmlhbiAgUm9zZW4KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAxNSwgMjAwNiA2OjE3IFBNClRvOiAgJ0d1bm5hciBIZWxsc3Ryb20nOyBlY3JpdEBpZXRm Lm9yZzsgJ0FxdWlsLCBLYW1yYW4nOyAnRnJhbsOnb2lzIEQuICAKTcOpbmFyZCcKQ2M6ICdH cmVnZyBWYW5kZXJoZWlkZW4nClN1YmplY3Q6IFJFOiBbRWNyaXRdICBFQ1JJVCBzdXBwb3J0 IGZvciBUVFkvVEREIGNhbGxzCgoKCgpBbGwgSSBnZXQgb3V0IG9mICB0aGlzIGZvciBlY3Jp dCBpcyB0aGF0IHdlIG5lZWQgZW50cmllcyBmb3Igc29zLnBvbGljZS50dHkgCmluIHRoZSBz ZXJ2aWNlICByZWdpc3RyeSAKQnJpYW4gCiAKICAKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCiAKRnJvbTogIEd1bm5hciBIZWxsc3Ryb20gW21haWx0bzpndW5uYXIu aGVsbHN0cm9tQG9tbml0b3Iuc2VdIApTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAy MDA2IDU6NDcgIFBNClRvOiBlY3JpdEBpZXRmLm9yZzsgICdBcXVpbCwgS2FtcmFuJzsgYnJA YnJpYW5yb3Nlbi5uZXQ7IEZyYW7Dp29pcyBELiBNw6luYXJkCkNjOiBHcmVnZyBWYW5kZXJo ZWlkZW4KU3ViamVjdDogUkU6IFtFY3JpdF0gRUNSSVQgc3VwcG9ydCBmb3IgIFRUWS9UREQg Y2FsbHMKIApJdCBpcyBxdWl0ZSB3aWRlbHkgIGFjY2VwdGVkIG5vdyB0aGF0IHJlYWwtdGlt ZSB0ZXh0IHRyYW5zbWl0dGVkIHdpdGggaXRzIG93biAKdGV4dCBjb2RlZCAgUlRQIHBheWxv YWQgUkZDIDQxMDMgaXMgdXNlZCB0byBjYXJyeSB0ZXh0IHRoYXQgbWF5IGJlIGdhdGV3YXll ZCAKdG8vZnJvbSAgVFRZL1RERC90ZXh0cGhvbmVzIGluIFBTVE4uCiAKCiAKSXQgaXMgZGlz Y3Vzc2VkIGluICAKX2h0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtc2lwcGluZy10b2lwLTAzLnR4dF8gCihodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcHBpbmctdG9pcC0wMy50eHQpIAogCgogCkFuZCBp dCBpcyAgZG9jdW1lbnRlZCBpbiAKX2h0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LXNpbm5yZWljaC1zaXBkZXYtcmVxLTA4LnR4dF8gCihodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zaW5ucmVpY2gtc2lwZGV2LXJlcS0wOC50 eHQpIAogCgogCkFsc28gb3RoZXIgIHN0YW5kYXJkaXNhdGlvbiBib2RpZXMgaGF2ZSBwaWNr ZWQgdXAgdGhlIHJlYWwtdGltZSB0ZXh0IGNvbmNlcHQgCmluIElQICBuZXR3b3JrcywgYW5k IHBvaW50ZWQgYXQgUkZDIDQxMDMgKG9yIGl0cyBjb21wYXRpYmxlIHByZWRlY2Vzc29yIApS RkMyNzkzICkuICBFLmcuIDNHUFAgYW5kIEVUU0kuCiAKQSBjb3VwbGUgb2YgeWVhcnMgIGFn byB3ZSBoYWQgYW4gaW50ZW5zaXZlIGRpc2N1c3Npb24gaW4gdGhlIFNJTVBMRSBtYWlsIGxp c3QgCmFib3V0IHRoZSAgcG9zc2liaWxpdHkgdG8gdXNlIE1TUlAgdG8gY2FycnkgdGhlIHJl YWwtdGltZSB0ZXh0IG1lZGl1bSwgYnV0IHdlIApjb25jbHVkZWQgIHRoYXQgaXQgd291bGQg Y2F1c2UgdG9vIG11Y2ggb3ZlcmhlYWQgb3IgdG9vIG11Y2ggZGVsYXkgZm9yIHRoZSAKdXNl cnMsIHNvICB0aGF0IFJUUCB3YXMgcmVjb21tZW5kZWQgaW5zdGVhZC4gVGhlIG1vc3QgY29t bW9uIHVzZSBvZiBNU1JQIGlzIHRvIApub3QgIHRyYW5zbWl0IHVudGlsIGVuZCBvZiBzZW50 ZW5jZSwgd2hpbGUgZm9yIHJlYWwgdGltZSB0ZXh0LCB0cmFuc21pc3Npb24gaXMgIApyZXF1 aXJlZCB3aXRoIGF0IG1vc3QgNTAwIG1zIGludGVydmFsIGFzIGxvbmcgYXMgdGhlcmUgaXMg YW55dGhpbmcgdG8gIAp0cmFuc21pdCBpbiBvcmRlciB0byBtYWludGFpbiB0aGUgcmVhbC10 aW1lIGZlZWxpbmcgb2YgYmVpbmcgaW4gdG91Y2ggaW4gYSAgCmNvbnZlcnNhdGlvbiB0aHJv dWdoIHRoaXMgbWVkaXVtLgogCgogClF1aXRlIGNvbW1vbmx5IHlvdSAgd2lsbCBjb25uZWN0 IGEgdGV4dCBSVFAgc3RyZWFtIGFuZCBhbiBhdWRpbyBSVFAgc3RyZWFtIAphbmQgcG9zc2li bHkgYSB2aWRlbyAgUlRQIHN0cmVhbSBpbiB0aGUgc2FtZSBjYWxsLCBzbyB0aGF0IHlvdSB3 aWxsIGdldCBhbiAKZW5oYW5jZWQgbXVsdGltZWRpYSAgcGhvbmUgY2FsbCB3aXRoIGFsbCBz dXBwb3J0ZWQgbWVkaWEgCiAKCiAKVGhlIGVjcml0IHJlcXVpcmVtZW50cyBhbHNvICBtZW50 aW9ucyB0aGlzIGNvcnJlc3BvbmRlbmNlCiAKaW4gX3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVudHMtMDMudHh0XyAKKGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZWNyaXQtcmVxdWlyZW1l bnRzLTAzLnR4dCkgCiAKClJlNC4gICBNdWx0aXBsZSBNb2RlczogTXVsdGlwbGUgY29tbXVu aWNhdGlvbiBtb2Rlcywgc3VjaCBhcyAgYXVkaW8sCnZpZGVvIGFuZCB0ZXh0IG1lc3NhZ2lu ZyBNVVNUIGJlICBzdXBwb3J0ZWQuCgpNb3RpdmF0aW9uOiBJbiBQU1ROLCB2b2ljZSAgYW5k IHRleHQgdGVsZXBob255IChvZnRlbiBjYWxsZWQgVFRZIG9yCnRleHRwaG9uZSBpbiBOb3J0 aCBBbWVyaWNhKSBhcmUgdGhlIG9ubHkgIGNvbW1vbmx5IHN1cHBvcnRlZCBtZWRpYS4KRW1l cmdlbmN5ICBjYWxsaW5nIG11c3Qgc3VwcG9ydCBhIHZhcmlldHkgb2YgbWVkaWEuICBTdWNo ICBtZWRpYQpzaG91bGQgaW5jbHVkZSB2b2ljZSwgY29udmVyc2F0aW9uYWwgIHRleHQgKFJG QyA0MTAzIFs5XSksIGluc3RhbnQKbWVzc2FnaW5nIGFuZCAgdmlkZW8uCiAKCiAKSSBhbSB3 b3JraW5nIGluIGEgIEV1cm9wZWFuIGdyb3VwIHdoZXJlIG9uZSBvZiB0aGUgZ29hbHMgaXMg dG8gYWdyZWUgb24gCmhhbmRsaW5nIHRleHQgIHVzZXJzJyAgcmVxdWlyZW1lbnRzIG9uIGVt ZXJnZW5jeSBjYWxsaW5nIGluIElQIG5ldHdvcmtzLiBPZiBjb3Vyc2UgCndlICB3YW50IHRv IGFncmVlIG9uIGdsb2JhbCBzb2x1dGlvbnMgaWYgIHBvc3NpYmxlLgogCgoKIApBZGRyZXNz IG1hcHBpbmcgaXMgIG9uZSBpbXBvcnRhbnQgYW5kIHRyaWNreSBxdWVzdGlvbiBmb3IgdGV4 dCB1c2Vycy4gSXQgaXMgCnRydWUgdGhhdCBkaWZmZXJlbnQgIGNvdW50cmllcyBoYXZlIGRp ZmZlcmVudCBhcHByb2FjaGVzIG9uIGVtZXJnZW5jeSBjYWxsaW5nIAp3aXRoIFBTVE4gVGV4 dCAgdGVsZXBob25lcyAoVFRZcykuIFNvbWUgaGF2ZSB0aGUgc2FtZSBudW1iZXIgYXMgdm9p Y2UgdXNlcnMsIAp3aGlsZSBvdGhlcnMgIGhhdmUgc3BlY2lmaWMgbnVtYmVycy4gT24gdGhl IFNJUCBzaWRlIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSAKdGhlICBzYW1lIFVSTCBhbmQg bWFrZSBhbnkgcmVxdWlyZWQgcm91dGluZyBiYXNlZCBvbiBkZWNsYXJlZCBtZWRpYSwgbW9k ZSAgYW5kIApsYW5ndWFnZSBjYXBhYmlsaXRpZXMgYW5kIHByZWZlcmVuY2VzLiAgCiAKCiAK VGV4dCBjYXBhYmxlICBnYXRld2F5cyBhcmUgbm90IGF0IGFsbCBhcyBjb21tb24gYXMgVm9J UCBnYXRld2F5cywgc28gaWYgdGhlIApQU0FQIGlzIHN0aWxsICBpbiBQU1ROLCB0aGVyZSBp cyBhIG5lZWQgdG8gaGF2ZSBhIGdvb2QgbWVjaGFuaXNtIGZvciByb3V0aW5nIAplbWVyZ2Vu Y3kgIGNhbGxzIGZyb20gU0lQIGludG8gUFNUTiB0aHJvdWdoIGEgdGV4dCBjYXBhYmxlIGdh dGV3YXkuIEkgY2Fubm90IHNheSAKdGhhdCAgdGhlIG1lY2hhbmlzbXMgZm9yIGZpbmRpbmcg dGhlIHJpZ2h0IGdhdGV3YXkgYW5kIG1ha2UgdGhlIHByb3BlciAKYWRkcmVzcyAgbWFwcGlu ZyB0byBhIFBTVE4gbnVtYmVyIGlzIHNvbHZlZCB5ZXQgZm9yIHRoZSB0ZXh0IGNhbGxzLCBh bmQgaXQgd291bGQgYmUgIApleGNlbGxlbnQgaWYgd2UgY291bGQgaGF2ZSB0aGF0IHRvcGlj IGluIG1pbmQgaW4gdGhlIGRpc2N1c3Npb25zIGFuZCBnZXQgIApwcm9wZXIgbWV0aG9kcyBk b2N1bWVudGVkLgogCgogCkkgaGF2ZSBkcmFmdGVkLCBidXQgIG5vdCB5ZXQgc3VibWl0dGVk IGEgcmVnaXN0cmF0aW9uIG9mIGEgU0lQIFVSTCBhbmQgYW4gCkVOVU0gc3Vic2VydmljZSBm b3IgIHJlYWwtdGltZSB0ZXh0LiBJdCBtaWdodCBiZSBoZWxwZnVsIGZvciBmaW5kaW5nIHRl eHQgCmdhdGV3YXlzICBhbmQgbWFwcGluZyBhZGRyZXNzZXMgYW5kICh0ZXh0KSBudW1iZXJz LCBidXQgSSB3b3VsZCBsaWtlIHRvIHNlZSAgc29tZSAKc2NlbmFyaW9zIHRob3JvdWdobHkg ZGlzY3Vzc2VkIGJlZm9yZSBhZGRpbmcgU0lQIFVSTCBhbmQgYW5vdGhlciBFTlVNICBzdWJz ZXJ2aWNlLgogCgogCldvdWxkIHRoZXJlIGJlICBhbnkgYmVuZWZpdCBvZiBiZWluZyBhbGxv d2VkIHRvIGVudGVyIFRYUDoxMTIgICAgb3IgIGhhdmluZyAKRU5VTSB0byBmaW5kIGFuIGFw cHJvcHJpYXRlIGFkZHJlc3MgaWYgSSAgIGNhbGwgIDExMiBmcm9tIGEgU0lQIG11bHRpbWVk aWEgCnBob25lIGRlY2xhcmluZyB0ZXh0IGNhcGFiaWxpdGllcyAgd2l0aCBtPXRleHQgaW4g c2RwPwogCgogCgogCkd1bm5hcgogCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAKR3VubmFy IEhlbGxzdHLDtm0sICBPbW5pdG9yCiAKX2d1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZV8g KG1haWx0bzpndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UpIAoKLS0tLS1PcmlnaW5hbCAg TWVzc2FnZS0tLS0tCkZyb206ICBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNy aXQtYm91bmNlc0BpZXRmLm9yZ11PbiBCZWhhbGYgT2YgCkZyYW7Dp29pcyBELiAgTcOpbmFy ZApTZW50OiBXZWRuZXNkYXksICBGZWJydWFyeSAxNSwgMjAwNiA1OjE0IFBNClRvOiBickBi cmlhbnJvc2VuLm5ldDsgJ0FxdWlsLCBLYW1yYW4nOyAgZWNyaXRAaWV0Zi5vcmcKU3ViamVj dDogIFJlOiBbRWNyaXRdIEVDUklUIHN1cHBvcnQgZm9yIFRUWS9UREQgY2FsbHMgCgpJIG1h ZGUgYSAgY29udHJpYnV0aW9uIHRvIENJU0MgTlRXRyBvbiB1c2Ugb2YgU0lQIGZvciB0cmFu c3BvcnRpbmcgVEREICAKdHJhZmZpYzoKCl9odHRwOi8vd3d3LmNydGMuZ2MuY2EvY2lzYy9D T01NSVRURS9OLWRvY3MvTlRDTzAzMzguZG9jXyAKKGh0dHA6Ly93d3cuY3J0Yy5nYy5jYS9j aXNjL0NPTU1JVFRFL04tZG9jcy9OVENPMDMzOC5kb2MpIAoKSSAgdGhpbmsgaXQgbWF5IGJl IHJlbGV2YW50IHRvIEVDUklULgoKLT1GcmFuY29pcz0tCgoKT24gIDIvMTUvMDYgMTA6NTEg QU0sICJCcmlhbiBSb3NlbiIgPGJyQGJyaWFucm9zZW4ubmV0PiAgd3JvdGU6IApXaXRoaW4g dGhlIHNjb3BlICBvZiBvdXIgd29yaywgSSBkb27igJl0IHNlZSBob3cgVEREIHNlcnZpY2Vz IGFyZSBpbXBhY3RlZCAKdW50aWwgd2UgZ2V0IHRvIHRoZSAgYXJjaGl0ZWN0dXJlIGVmZm9y dCwgd2hpY2ggcHJvYmFibHkgaGFzIHRvIGhhdmUgc29tZSBzZWN0aW9ucyAKb24gdGhhdCAg c3ViamVjdC4KV2l0aCByZXNwZWN0IHRvIHRoZSBtYXBwaW5nIHByb3RvY29sLCBJIGRvIG5v dCBiZWxpZXZlIHRoZXJlICBpcyBhbnkgaW1wYWN0IAphdCBhbGwuCldpdGggcmVzcGVjdCB0 byB0aGUgc29zIHNlcnZpY2UgdXJuLCBJIGRvIG5vdCAgYmVsaWV2ZSB0aGVyZSBpcyBhbnkg aW1wYWN0IGF0IAphbGwKCkVjcml0IGRvZXNu4oCZdCBoYXZlIHNjb3BlICB0byB0YWxrIGFi b3V0IGFueSBraW5kIG9mIGdhdGV3YXlzIG9yIGNvZGVjIHN1cHBvcnQuCgpBaCEgIE15IEJD UCBvbiBwaG9uZXMgYW5kIHByb3hpZXMgbWF5IG5lZWQgc29tZSBtZW50aW9uLCBhbHRob3Vn aCB0aGlzIGlzICAKdGhlIElFVEYsIGFuZCBJIGRvbuKAmXQgdGhpbmsgdGhlIHBsb3kgb2Yg Zm9yY2luZyB0aGUgZW50aXJlIFBTVE4gdG8gc3VwcG9ydCAgVEREIApqdXN0IHNvIDktMS0x IFRERCB3aWxsIHdvcmsuICBUaGF0IGVmZm9ydCB3b3VsZCBoYXZlIHRvIGJlIGluIHRoZSAg Z2VuZXJhbCBTSVAgCiBhcmVuYS4KCkJyaWFuCiAKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCiAKRnJvbTogIGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW19tYWlsdG86 ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ11fIAoobWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5v cmddKSAgIE9uIEJlaGFsZiBPZiBBcXVpbCwgIEthbXJhbgpTZW50OiBXZWRuZXNkYXksICBG ZWJydWFyeSAxNSwgMjAwNiAxMDozMSBBTQpUbzogZWNyaXRAaWV0Zi5vcmcKU3ViamVjdDog W0Vjcml0XSBFQ1JJVCBzdXBwb3J0IGZvciAgVFRZL1RERCBjYWxscwoKCkZvbGtzLAoKCgpM aWtlIHRvICBrbm93IGlmIHRoZXJlIGFyZSBzcGVjaWZpYyBFQ1JJVCByZXF1aXJlbWVudHMg cmVjb2duaXppbmcgc3VwcG9ydCAKZm9yICBUZWxlY29tbXVuaWNhdGlvbnMgRGV2aWNlIGZv ciAgdGhlIERlYWYgKFRERCkgc2VydmljZXMgZm9yIHRoZSBoZWFyaW5nIAppbXBhaXJlZC4g SWYgbm90IGlzIHRoaXMgbGVmdCBmb3IgIFZPSVAvU0lQIGdhdGV3YXlzIHRvIHBlcmZvcm0g dGhpcyByZXF1aXJlbWVudCAKb2YgdHJhbnNsYXRpbmcgdGhlIFRERCBjYWxscyAgdG8gVGV4 dCBhbmQgU3BlZWNoIGVuY29kaW5nLiBXYW50ZWQgdG8gbWFrZSBzdXJlIApob3cgRUNSSVQg bWVldCAgcmVxdWlyZW1lbnQgZm9yIFRERCBzZXJ2aWNlcy4KCgoKUmVnYXJkcywKS2FtcmFu ICBBcXVpbApJbnRlbGxpZ2VudCBUcmFuc3BvcnRhdGlvbiBTeXN0ZW1zLSBEaXZpc2lvbgpN aXRyZXRlayAgU3lzdGVtcy4KCgoKCiAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCiAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KRWNyaXQgIG1haWxpbmcgIGxpc3QKRWNyaXRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQgCgoKLS0gIApGcmFuY29pcyBELiBNZW5h cmQKZm1lbmFyZEB4aXR0ZWxlY29tLmNvbQoKCgoKCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpFY3JpdCAgbWFpbGluZyAgbGlzdApFY3JpdEBp ZXRmLm9yZwpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdAoK CgoK -------------------------------1140056283 Content-Type: text/html; charset="UTF-8" Content-Language: en Content-Transfer-Encoding: quoted-printable
I have a question on what is being discussed. Are you only discussing=20 TTY/TDD devices used via PSTN specifically by deaf to access emergency servi= ces?=20 Wanting to clarify that you are not discussing any text user access beyond t= hat,=20 since that could be used by anyone to access emergency services and so shoul= d=20 have no special TTY/TDD type handling.
 
Thanks for assistance.
 
Rick Jones
 
In a message dated 2/15/2006 7:47:33 PM Eastern Standard Time,=20 mlinsner@cisco.com writes:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>
So the UA must know this?  Not the=20 proxy...?
 
-Marc-

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian=20 Rosen
Sent: Wednesday, February 15, 2006 6:17 PM
To:= =20 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=C3=A7ois D.=20 M=C3=A9nard'
Cc: 'Gregg Vanderheiden'
Subject: RE: [= Ecrit]=20 ECRIT support for TTY/TDD calls

All I get out= of=20 this for ecrit is that we need entries for sos.police.tty in the service= =20 registry

 

Brian

 

From:<= /SPAN>=20 Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]
Sent: Wednesday, February 15, 200= 6 5:47=20 PM
To: ecrit@ietf.org= ;=20 'Aquil, Kamran'; br@brianrosen.net; Fran=C3=A7ois D. M=C3= =A9nard
Cc: Gregg Vanderheiden
Subject: RE: [Ecrit] ECRIT suppor= t for=20 TTY/TDD calls

 

It is quite w= idely=20 accepted now that real-time text transmitted with its own text code= d=20 RTP payload RFC 4103 is used to carry text that may be gatewayed to/from= =20 TTY/TDD/textphones in PSTN.

 

 

And it is=20 documented in http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt=

 

Also other=20 standardisation bodies have picked up the real-time text concept in IP=20 networks, and pointed at RFC 4103 (or its compatible predecessor RFC2793= ).=20 E.g. 3GPP and ETSI.

A couple of y= ears=20 ago we had an intensive discussion in the SIMPLE mail list about the=20 possibility to use MSRP to carry the real-time text medium, but we concl= uded=20 that it would cause too much overhead or too much delay for the users, s= o=20 that RTP was recommended instead. The most common use of MSRP is to not=20 transmit until end of sentence, while for real time text, transmission i= s=20 required with at most 500 ms interval as long as there is anything to=20 transmit in order to maintain the real-time feeling of being in touch in= a=20 conversation through this medium.

 

Quite commonl= y you=20 will connect a text RTP stream and an audio RTP stream and possibly a vi= deo=20 RTP stream in the same call, so that you will get an enhanced multimedia= =20 phone call with all supported media

 

The ecrit requirements als= o=20 mentions this correspondence

in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt<= /A>


   Re4. = ;=20 Multiple Modes: Multiple communication modes, such as=20 audio,
      video and text messaging MUST b= e=20 supported.

      Motivation: In PSTN, vo= ice=20 and text telephony (often called TTY or
     = ;=20 textphone in North America) are the o= nly=20 commonly supported media.
      Emergency=20 calling must support a variety of media.  Such=20 media
      should include voice, conversati= onal=20 text (RFC 4103 [9]), instant
      messaging= and=20 video.

 

I am working=20= in a=20 European group where one of the goals is to agree on handling text=20 users'  requirements on emergency calling in IP networks. Of course= we=20 want to agree on global solutions if=20 possible.

 

Address mappi= ng is=20 one important and tricky question for text users. It is true that differ= ent=20 countries have different approaches on emergency calling with PSTN Text=20 telephones (TTYs). Some have the same number as voice users, while other= s=20 have specific numbers. On the SIP side it would be good to have the=20 same URL and make any required routing based on declared media, mod= e=20 and language capabilities and preferences.=20

 

Text capable=20 gateways are not at all as common as VoIP gateways, so if the PSAP is st= ill=20 in PSTN, there is a need to have a good mechanism for routing emergency=20 calls from SIP into PSTN through a text capable gateway. I cannot say th= at=20 the mechanisms for finding the right gateway and make the proper address= =20 mapping to a PSTN number is solved yet for the text calls, and it would=20= be=20 excellent if we could have that topic in mind in the discussions and get= =20 proper methods documented.

 

I have drafte= d, but=20 not yet submitted a registration of a SIP URL and an ENUM subservice for= =20 real-time text. It might be helpful for finding text gateways=20 and mapping addresses and (text) numbers, but I would like to=20= see=20 some scenarios thoroughly discussed before adding SIP URL and another EN= UM=20 subservice.

 

Would th= ere be=20 any benefit of being allowed to enter TXP:112    or=20 having ENUM to find an appropriate address if I   call=20 112 from a SIP multimedia phone declaring text capabiliti= es=20 with m=3Dtext in sdp?

 

 

Gunnar=

--------------------------= ---------------------------------------------------=

Gunnar Hellstr=C3=B6m,=20 Omnitor

gunnar.hellstrom@omnitor.se<= /A>

-----Ori= ginal=20 Message-----
From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of Fran=C3=A7ois D.=20 M=C3=A9nard
Sent: W= ednesday,=20 February 15, 2006 5:14 PM
To: br@brianrosen.net; 'Aquil, Kamran';=20 ecrit@ietf.org
Subject:= =20 Re: [Ecrit] ECRIT support for TTY/TDD calls


I ma= de a=20 contribution to CISC NTWG on use of SIP for transporting TDD=20 traffic:

http:= //www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc

I=20 think it may be relevant to ECRIT.

-=3DFrancois=3D-


= On=20 2/15/06 10:51 AM, "Brian Rosen" <br@brianrosen.net>=20 wrote:

Within the s= cope=20 of our work, I don=E2=80=99t see how TDD services are impacted until w= e get to the=20 architecture effort, which probably has to have some sections on that=20 subject.
With respect to the mapping protocol, I do not believe the= re=20 is any impact at all.
With respect to the sos service urn, I do not= =20 believe there is any impact at all
 
Ecrit doesn=E2=80=99t=20= have scope=20 to talk about any kind of gateways or codec support.
 
Ah!=20  My BCP on phones and proxies may need some mention, although thi= s is=20 the IETF, and I don=E2=80=99t think the ploy of forcing the entire PST= N to support=20 TDD just so 9-1-1 TDD will work.  That effort would have to be in= the=20 general SIP=20 arena.
 
Brian
 

From:= =20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.or= g]=20 On Behalf Of Aquil,=20 Kamran
Sent: Wednes= day,=20 February 15, 2006 10:31 AM
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT support=20= for=20 TTY/TDD calls


Folks,
<= FONT=20 face=3DVerdana size=3D1>


Like to=20 know if there are specific ECRIT requirements recognizing support for=20 Telecommunications Devi= ce for=20 the Deaf (TDD) services for the hearing impaired. If not is this left=20= for=20 VOIP/SIP gateways to perform this requirement of translating the TDD c= alls=20 to Text and Speech encoding. Wanted to make sure how ECRIT meet=20 requirement for TDD services.



Regards,
Kamran=20 Aquil
Intelligent Transportation Systems- Division
Mitretek=20 Systems.

 


_________________= ______________________________
Ecrit=20 mailing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit=



--=20
Francois D. Menard
fmenard@xittelecom.com

=



__________________= _____________________________
Ecrit=20 mailing=20 list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
=
 
-------------------------------1140056283-- --===============1225123842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1225123842==-- From ecrit-bounces@ietf.org Wed Feb 15 21:23:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Ync-0002l0-4c; Wed, 15 Feb 2006 21:23:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9YnZ-0002jV-VX for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 21:23:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06895 for ; Wed, 15 Feb 2006 21:21:25 -0500 (EST) Received: from smtp01out.dot.gov ([199.79.179.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Z1h-0007A8-53 for ecrit@ietf.org; Wed, 15 Feb 2006 21:37:50 -0500 Received: from dotfaawms005.ad.dot.gov (152.119.86.161) by smtp01out.dot.gov with ESMTP; 15 Feb 2006 21:23:04 -0500 X-IronPort-AV: i="4.02,118,1139202000"; d="scan'208"; a="30107786:sNHT478175152" Received: from msgbrdg1.NED.NHTSA.AD ([152.119.106.183]) by DOTFAAWMS005.ad.dot.gov with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 21:23:03 -0500 Received: from MSGC2.NED.NHTSA.AD ([152.119.106.191]) by msgbrdg1.NED.NHTSA.AD with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Feb 2006 21:22:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Feb 2006 21:25:58 -0500 Message-ID: <9D25AF0E6FE1ED41A54215BC3E37772C02350B78@MSGC2.NED.NHTSA.AD> Thread-Topic: Ecrit Digest, Vol 13, Issue 20 Thread-Index: AcYyn/KYuGof7MNkSISNin6a82wK4QAAF/hG From: "Hansen, Jenny " To: X-OriginalArrivalTime: 16 Feb 2006 02:22:56.0295 (UTC) FILETIME=[E5C88370:01C6329F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d705d72e8b350fed958d93136c5ddf2 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] Re: Ecrit Digest, Vol 13, Issue 20 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree w/Henning. From an operational standpoint, old salt dispatcher = that I am, have the call (all of them) routed to the Primary PSAP. Jenny Hansen NG9-1-1 -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: ecrit-bounces@ietf.org To: ecrit@ietf.org Sent: Wed Feb 15 21:20:21 2006 Subject: Ecrit Digest, Vol 13, Issue 20 Send Ecrit mailing list submissions to ecrit@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ecrit or, via email, send a message with subject or body 'help' to ecrit-request@ietf.org You can reach the person managing the list at ecrit-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Ecrit digest..." Today's Topics: 1. Re: ECRIT support for TTY/TDD calls (Henning Schulzrinne) 2. RE: ECRIT support for TTY/TDD calls (Brian Rosen) 3. Re: ECRIT support for TTY/TDD calls (Rockford9@aol.com) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Feb 2006 20:05:46 -0500 From: Henning Schulzrinne Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls To: "Gunnar Hellstrom" Cc: 'Gregg Vanderheiden' , "'Aquil, Kamran'" , ecrit@ietf.org Message-ID: <232E09D4-6327-4A28-9A1D-D469E4CEA48D@cs.columbia.edu> Content-Type: text/plain; charset=3DWINDOWS-1252; delsp=3Dyes; format=3Dflowed I don't think we want a service label for each media type. While =20 *today* there are PSAPs that only answer TTY calls, is this likely to =20 make sense in an all-IP PSAP environment where the media would =20 terminate on the same PC that's used for IM, video and so on? Why =20 would you do this? Rather than trying to put SDP in a URN, maybe the better solution is =20 to route to one PSAP for the emergency service and have that PSAP =20 then redirect the call based on the full SDP information, if this =20 becomes necessary. That way, you can deal with situations where the =20 caller can handle a variety of means of communications, albeit with =20 different ease, and the PSAP has access to the full media information. Since this could be added on later if necessary, once we know whether =20 anybody actually needs this, maybe it's better to avoid gratuitous =20 complexity, both in terms of protocol operation, testing (yet another =20 thing a mapping protocol has to test) and user agents. Henning On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > What would sos.police.tty do and how would it be invoked? > > If it could lead to a text capable IP terminal, it should be called =20 > sos.police.real-time-text or so. > > If it helps to find a PSTN based PSAP with text capabilities, it =20 > could be called sos.police.txp > > tty is a US term. > > Gunnar > > ---------------------------------------------------------------------- = > ------- > Gunnar Hellstr=F6m, Omnitor > gunnar.hellstrom@omnitor.se > Mob: +46 708 204 288 > Phone: +46 8 556 002 03 > www.omnitor.se > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, February 16, 2006 12:17 AM > To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois =20 > D. M=E9nard' > Cc: 'Gregg Vanderheiden' > Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > All I get out of this for ecrit is that we need entries for =20 > sos.police.tty in the service registry > > > > Brian > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Wednesday, February 15, 2006 5:47 PM > To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. = > M=E9nard > Cc: Gregg Vanderheiden > Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > > > It is quite widely accepted now that real-time text transmitted =20 > with its own text coded RTP payload RFC 4103 is used to carry text =20 > that may be gatewayed to/from TTY/TDD/textphones in PSTN. > > > > It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-=20 > sipping-toip-03.txt > > > > And it is documented in http://www.ietf.org/internet-drafts/draft-=20 > sinnreich-sipdev-req-08.txt > > > > Also other standardisation bodies have picked up the real-time text =20 > concept in IP networks, and pointed at RFC 4103 (or its compatible =20 > predecessor RFC2793 ). E.g. 3GPP and ETSI. > > A couple of years ago we had an intensive discussion in the SIMPLE =20 > mail list about the possibility to use MSRP to carry the real-time =20 > text medium, but we concluded that it would cause too much overhead =20 > or too much delay for the users, so that RTP was recommended =20 > instead. The most common use of MSRP is to not transmit until end =20 > of sentence, while for real time text, transmission is required =20 > with at most 500 ms interval as long as there is anything to =20 > transmit in order to maintain the real-time feeling of being in =20 > touch in a conversation through this medium. > > > > Quite commonly you will connect a text RTP stream and an audio RTP =20 > stream and possibly a video RTP stream in the same call, so that =20 > you will get an enhanced multimedia phone call with all supported =20 > media > > > > The ecrit requirements also mentions this correspondence > > in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt > > > Re4. Multiple Modes: Multiple communication modes, such as audio, > video and text messaging MUST be supported. > > Motivation: In PSTN, voice and text telephony (often called =20 > TTY or > textphone in North America) are the only commonly supported =20 > media. > Emergency calling must support a variety of media. Such media > should include voice, conversational text (RFC 4103 [9]), =20 > instant > messaging and video. > > > > I am working in a European group where one of the goals is to agree =20 > on handling text users' requirements on emergency calling in IP =20 > networks. Of course we want to agree on global solutions if possible. > > > > Address mapping is one important and tricky question for text =20 > users. It is true that different countries have different =20 > approaches on emergency calling with PSTN Text telephones (TTYs). =20 > Some have the same number as voice users, while others have =20 > specific numbers. On the SIP side it would be good to have the same =20 > URL and make any required routing based on declared media, mode and =20 > language capabilities and preferences. > > > > Text capable gateways are not at all as common as VoIP gateways, so =20 > if the PSAP is still in PSTN, there is a need to have a good =20 > mechanism for routing emergency calls from SIP into PSTN through a =20 > text capable gateway. I cannot say that the mechanisms for finding =20 > the right gateway and make the proper address mapping to a PSTN =20 > number is solved yet for the text calls, and it would be excellent =20 > if we could have that topic in mind in the discussions and get =20 > proper methods documented. > > > > I have drafted, but not yet submitted a registration of a SIP URL =20 > and an ENUM subservice for real-time text. It might be helpful for =20 > finding text gateways and mapping addresses and (text) numbers, but =20 > I would like to see some scenarios thoroughly discussed before =20 > adding SIP URL and another ENUM subservice. > > > > Would there be any benefit of being allowed to enter TXP:112 or =20 > having ENUM to find an appropriate address if I call 112 from a =20 > SIP multimedia phone declaring text capabilities with m=3Dtext in sdp? > > > > > > Gunnar > > ---------------------------------------------------------------------- = > ------- > > Gunnar Hellstr=F6m, Omnitor > > gunnar.hellstrom@omnitor.se > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On =20 > Behalf Of Fran=E7ois D. M=E9nard > Sent: Wednesday, February 15, 2006 5:14 PM > To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls > > > I made a contribution to CISC NTWG on use of SIP for transporting =20 > TDD traffic: > > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc > > I think it may be relevant to ECRIT. > > -=3DFrancois=3D- > > > On 2/15/06 10:51 AM, "Brian Rosen" wrote: > > Within the scope of our work, I don't see how TDD services are =20 > impacted until we get to the architecture effort, which probably =20 > has to have some sections on that subject. > With respect to the mapping protocol, I do not believe there is any =20 > impact at all. > With respect to the sos service urn, I do not believe there is any =20 > impact at all > > Ecrit doesn't have scope to talk about any kind of gateways or =20 > codec support. > > Ah! My BCP on phones and proxies may need some mention, although =20 > this is the IETF, and I don't think the ploy of forcing the entire =20 > PSTN to support TDD just so 9-1-1 TDD will work. That effort would =20 > have to be in the general SIP arena. > > Brian > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On =20 > Behalf Of Aquil, Kamran > Sent: Wednesday, February 15, 2006 10:31 AM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT support for TTY/TDD calls > > > Folks, > > > > Like to know if there are specific ECRIT requirements recognizing =20 > support for Telecommunications Device for the Deaf (TDD) services =20 > for the hearing impaired. If not is this left for VOIP/SIP gateways =20 > to perform this requirement of translating the TDD calls to Text =20 > and Speech encoding. Wanted to make sure how ECRIT meet requirement =20 > for TDD services. > > > > Regards, > Kamran Aquil > Intelligent Transportation Systems- Division > Mitretek Systems. > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > --=20 > Francois D. Menard > fmenard@xittelecom.com > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ------------------------------ Message: 2 Date: Wed, 15 Feb 2006 21:17:15 -0500 From: "Brian Rosen" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls To: "'Henning Schulzrinne'" , "'Gunnar Hellstrom'" Cc: "'Aquil, Kamran'" , ecrit@ietf.org, 'Gregg Vanderheiden' Message-ID: <070c01c6329f$1d36b030$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=3D"iso-8859-1" If a country has a dialstring that is the text-to-police dialstring, = then we must map it into a unique urn unless we know that in every instance we = can differentiate the text calls from voice calls. I suspect that's hard. With a SIP URI, you know you can use media negotiation to get the text codec, and if the PSAP accepts the text call, then the mapper will have = the same result for sos.police.txt as sos.police. If you have to map = instead to some older technology, you have to differentiate (that is, the mapping = will be different). It may be that we make an assumption that the mapping function does not yield a URI if the PSAP doesn't accept a call with a negotiated text = codec, which would mean we don't need to have sos.police.txt. That would force backwards compatibility to existing systems when mapping fails. That's = not terrible, but I thought it made more sense to let mapping yield a URI = that resolved to the older technology. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Wednesday, February 15, 2006 8:06 PM To: Gunnar Hellstrom Cc: br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D. = M=E9nard' ; 'Gregg Vanderheiden' Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls I don't think we want a service label for each media type. While =20 *today* there are PSAPs that only answer TTY calls, is this likely to =20 make sense in an all-IP PSAP environment where the media would =20 terminate on the same PC that's used for IM, video and so on? Why =20 would you do this? Rather than trying to put SDP in a URN, maybe the better solution is =20 to route to one PSAP for the emergency service and have that PSAP =20 then redirect the call based on the full SDP information, if this =20 becomes necessary. That way, you can deal with situations where the =20 caller can handle a variety of means of communications, albeit with =20 different ease, and the PSAP has access to the full media information. Since this could be added on later if necessary, once we know whether =20 anybody actually needs this, maybe it's better to avoid gratuitous =20 complexity, both in terms of protocol operation, testing (yet another =20 thing a mapping protocol has to test) and user agents. Henning On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > What would sos.police.tty do and how would it be invoked? > > If it could lead to a text capable IP terminal, it should be called =20 > sos.police.real-time-text or so. > > If it helps to find a PSTN based PSAP with text capabilities, it =20 > could be called sos.police.txp > > tty is a US term. > > Gunnar > > ---------------------------------------------------------------------- = > ------- > Gunnar Hellstr=F6m, Omnitor > gunnar.hellstrom@omnitor.se > Mob: +46 708 204 288 > Phone: +46 8 556 002 03 > www.omnitor.se > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, February 16, 2006 12:17 AM > To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois =20 > D. M=E9nard' > Cc: 'Gregg Vanderheiden' > Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > All I get out of this for ecrit is that we need entries for =20 > sos.police.tty in the service registry > > > > Brian > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: Wednesday, February 15, 2006 5:47 PM > To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. = > M=E9nard > Cc: Gregg Vanderheiden > Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > > > It is quite widely accepted now that real-time text transmitted =20 > with its own text coded RTP payload RFC 4103 is used to carry text =20 > that may be gatewayed to/from TTY/TDD/textphones in PSTN. > > > > It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-=20 > sipping-toip-03.txt > > > > And it is documented in http://www.ietf.org/internet-drafts/draft-=20 > sinnreich-sipdev-req-08.txt > > > > Also other standardisation bodies have picked up the real-time text =20 > concept in IP networks, and pointed at RFC 4103 (or its compatible =20 > predecessor RFC2793 ). E.g. 3GPP and ETSI. > > A couple of years ago we had an intensive discussion in the SIMPLE =20 > mail list about the possibility to use MSRP to carry the real-time =20 > text medium, but we concluded that it would cause too much overhead =20 > or too much delay for the users, so that RTP was recommended =20 > instead. The most common use of MSRP is to not transmit until end =20 > of sentence, while for real time text, transmission is required =20 > with at most 500 ms interval as long as there is anything to =20 > transmit in order to maintain the real-time feeling of being in =20 > touch in a conversation through this medium. > > > > Quite commonly you will connect a text RTP stream and an audio RTP =20 > stream and possibly a video RTP stream in the same call, so that =20 > you will get an enhanced multimedia phone call with all supported =20 > media > > > > The ecrit requirements also mentions this correspondence > > in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt > > > Re4. Multiple Modes: Multiple communication modes, such as audio, > video and text messaging MUST be supported. > > Motivation: In PSTN, voice and text telephony (often called =20 > TTY or > textphone in North America) are the only commonly supported =20 > media. > Emergency calling must support a variety of media. Such media > should include voice, conversational text (RFC 4103 [9]), =20 > instant > messaging and video. > > > > I am working in a European group where one of the goals is to agree =20 > on handling text users' requirements on emergency calling in IP =20 > networks. Of course we want to agree on global solutions if possible. > > > > Address mapping is one important and tricky question for text =20 > users. It is true that different countries have different =20 > approaches on emergency calling with PSTN Text telephones (TTYs). =20 > Some have the same number as voice users, while others have =20 > specific numbers. On the SIP side it would be good to have the same =20 > URL and make any required routing based on declared media, mode and =20 > language capabilities and preferences. > > > > Text capable gateways are not at all as common as VoIP gateways, so =20 > if the PSAP is still in PSTN, there is a need to have a good =20 > mechanism for routing emergency calls from SIP into PSTN through a =20 > text capable gateway. I cannot say that the mechanisms for finding =20 > the right gateway and make the proper address mapping to a PSTN =20 > number is solved yet for the text calls, and it would be excellent =20 > if we could have that topic in mind in the discussions and get =20 > proper methods documented. > > > > I have drafted, but not yet submitted a registration of a SIP URL =20 > and an ENUM subservice for real-time text. It might be helpful for =20 > finding text gateways and mapping addresses and (text) numbers, but =20 > I would like to see some scenarios thoroughly discussed before =20 > adding SIP URL and another ENUM subservice. > > > > Would there be any benefit of being allowed to enter TXP:112 or =20 > having ENUM to find an appropriate address if I call 112 from a =20 > SIP multimedia phone declaring text capabilities with m=3Dtext in sdp? > > > > > > Gunnar > > ---------------------------------------------------------------------- = > ------- > > Gunnar Hellstr=F6m, Omnitor > > gunnar.hellstrom@omnitor.se > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On =20 > Behalf Of Fran=E7ois D. M=E9nard > Sent: Wednesday, February 15, 2006 5:14 PM > To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls > > > I made a contribution to CISC NTWG on use of SIP for transporting =20 > TDD traffic: > > http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc > > I think it may be relevant to ECRIT. > > -=3DFrancois=3D- > > > On 2/15/06 10:51 AM, "Brian Rosen" wrote: > > Within the scope of our work, I don't see how TDD services are =20 > impacted until we get to the architecture effort, which probably =20 > has to have some sections on that subject. > With respect to the mapping protocol, I do not believe there is any =20 > impact at all. > With respect to the sos service urn, I do not believe there is any =20 > impact at all > > Ecrit doesn't have scope to talk about any kind of gateways or =20 > codec support. > > Ah! My BCP on phones and proxies may need some mention, although =20 > this is the IETF, and I don't think the ploy of forcing the entire =20 > PSTN to support TDD just so 9-1-1 TDD will work. That effort would =20 > have to be in the general SIP arena. > > Brian > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On =20 > Behalf Of Aquil, Kamran > Sent: Wednesday, February 15, 2006 10:31 AM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT support for TTY/TDD calls > > > Folks, > > > > Like to know if there are specific ECRIT requirements recognizing =20 > support for Telecommunications Device for the Deaf (TDD) services =20 > for the hearing impaired. If not is this left for VOIP/SIP gateways =20 > to perform this requirement of translating the TDD calls to Text =20 > and Speech encoding. Wanted to make sure how ECRIT meet requirement =20 > for TDD services. > > > > Regards, > Kamran Aquil > Intelligent Transportation Systems- Division > Mitretek Systems. > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > > --=20 > Francois D. Menard > fmenard@xittelecom.com > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ------------------------------ Message: 3 Date: Wed, 15 Feb 2006 21:18:03 EST From: Rockford9@aol.com Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls To: mlinsner@cisco.com, br@brianrosen.net, gunnar.hellstrom@omnitor.se, ecrit@ietf.org, kamran.aquil@mitretek.org, fmenard@xittelecom.com Cc: gv@trace.wisc.edu Message-ID: <75.55537d35.31253adb@aol.com> Content-Type: text/plain; charset=3D"utf-8" =20 I have a question on what is being discussed. Are you only discussing =20 TTY/TDD devices used via PSTN specifically by deaf to access emergency = services? =20 Wanting to clarify that you are not discussing any text user access = beyond that,=20 since that could be used by anyone to access emergency services and so=20 should have no special TTY/TDD type handling. =20 Thanks for assistance. =20 Rick Jones =20 In a message dated 2/15/2006 7:47:33 PM Eastern Standard Time, =20 mlinsner@cisco.com writes: So the UA must know this? Not the proxy...? =20 -Marc- =20 ____________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of=20 Brian Rosen Sent: Wednesday, February 15, 2006 6:17 PM To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=C3=A7ois = D. =20 M=C3=A9nard' Cc: 'Gregg Vanderheiden' Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls All I get out of this for ecrit is that we need entries for = sos.police.tty=20 in the service registry=20 Brian=20 =20 =20 ____________________________________ =20 From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: Wednesday, February 15, 2006 5:47 PM To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=C3=A7ois = D. M=C3=A9nard Cc: Gregg Vanderheiden Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls =20 It is quite widely accepted now that real-time text transmitted with = its own=20 text coded RTP payload RFC 4103 is used to carry text that may be = gatewayed=20 to/from TTY/TDD/textphones in PSTN. =20 =20 It is discussed in =20 _http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt_=20 (http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-03.txt)=20 =20 =20 And it is documented in=20 _http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt_=20 (http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt)=20 =20 =20 Also other standardisation bodies have picked up the real-time text = concept=20 in IP networks, and pointed at RFC 4103 (or its compatible predecessor=20 RFC2793 ). E.g. 3GPP and ETSI. =20 A couple of years ago we had an intensive discussion in the SIMPLE mail = list=20 about the possibility to use MSRP to carry the real-time text medium, = but we=20 concluded that it would cause too much overhead or too much delay for = the=20 users, so that RTP was recommended instead. The most common use of MSRP = is to=20 not transmit until end of sentence, while for real time text, = transmission is =20 required with at most 500 ms interval as long as there is anything to =20 transmit in order to maintain the real-time feeling of being in touch in = a =20 conversation through this medium. =20 =20 Quite commonly you will connect a text RTP stream and an audio RTP = stream=20 and possibly a video RTP stream in the same call, so that you will get = an=20 enhanced multimedia phone call with all supported media=20 =20 =20 The ecrit requirements also mentions this correspondence =20 in _www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt_=20 (http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt= )=20 =20 Re4. Multiple Modes: Multiple communication modes, such as audio, video and text messaging MUST be supported. Motivation: In PSTN, voice and text telephony (often called TTY or textphone in North America) are the only commonly supported media. Emergency calling must support a variety of media. Such media should include voice, conversational text (RFC 4103 [9]), instant messaging and video. =20 =20 I am working in a European group where one of the goals is to agree on=20 handling text users' requirements on emergency calling in IP networks. = Of course=20 we want to agree on global solutions if possible. =20 =20 Address mapping is one important and tricky question for text users. It = is=20 true that different countries have different approaches on emergency = calling=20 with PSTN Text telephones (TTYs). Some have the same number as voice = users,=20 while others have specific numbers. On the SIP side it would be good to = have=20 the same URL and make any required routing based on declared media, = mode and=20 language capabilities and preferences. =20 =20 =20 Text capable gateways are not at all as common as VoIP gateways, so if = the=20 PSAP is still in PSTN, there is a need to have a good mechanism for = routing=20 emergency calls from SIP into PSTN through a text capable gateway. I = cannot say=20 that the mechanisms for finding the right gateway and make the proper=20 address mapping to a PSTN number is solved yet for the text calls, and = it would be =20 excellent if we could have that topic in mind in the discussions and get = =20 proper methods documented. =20 =20 I have drafted, but not yet submitted a registration of a SIP URL and = an=20 ENUM subservice for real-time text. It might be helpful for finding = text=20 gateways and mapping addresses and (text) numbers, but I would like to = see some=20 scenarios thoroughly discussed before adding SIP URL and another ENUM = subservice. =20 =20 Would there be any benefit of being allowed to enter TXP:112 or = having=20 ENUM to find an appropriate address if I call 112 from a SIP = multimedia=20 phone declaring text capabilities with m=3Dtext in sdp? =20 =20 =20 Gunnar =20 -------------------------------------------------------------------------= ---- =20 Gunnar Hellstr=C3=B6m, Omnitor =20 _gunnar.hellstrom@omnitor.se_ (mailto:gunnar.hellstrom@omnitor.se)=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf = Of=20 Fran=C3=A7ois D. M=C3=A9nard Sent: Wednesday, February 15, 2006 5:14 PM To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls=20 I made a contribution to CISC NTWG on use of SIP for transporting TDD =20 traffic: _http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc_=20 (http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc)=20 I think it may be relevant to ECRIT. -=3DFrancois=3D- On 2/15/06 10:51 AM, "Brian Rosen" wrote:=20 Within the scope of our work, I don=E2EUR(tm)t see how TDD services are = impacted=20 until we get to the architecture effort, which probably has to have = some sections=20 on that subject. With respect to the mapping protocol, I do not believe there is any = impact=20 at all. With respect to the sos service urn, I do not believe there is any = impact at=20 all Ecrit doesn=E2EUR(tm)t have scope to talk about any kind of gateways or = codec support. Ah! My BCP on phones and proxies may need some mention, although this = is =20 the IETF, and I don=E2EUR(tm)t think the ploy of forcing the entire PSTN = to support TDD=20 just so 9-1-1 TDD will work. That effort would have to be in the = general SIP=20 arena. Brian =20 ____________________________________ =20 From: ecrit-bounces@ietf.org [_mailto:ecrit-bounces@ietf.org]_=20 (mailto:ecrit-bounces@ietf.org]) On Behalf Of Aquil, Kamran Sent: Wednesday, February 15, 2006 10:31 AM To: ecrit@ietf.org Subject: [Ecrit] ECRIT support for TTY/TDD calls Folks, Like to know if there are specific ECRIT requirements recognizing = support=20 for Telecommunications Device for the Deaf (TDD) services for the = hearing=20 impaired. If not is this left for VOIP/SIP gateways to perform this = requirement=20 of translating the TDD calls to Text and Speech encoding. Wanted to = make sure=20 how ECRIT meet requirement for TDD services. Regards, Kamran Aquil Intelligent Transportation Systems- Division Mitretek Systems. =20 ____________________________________ =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit=20 -- =20 Francois D. Menard fmenard@xittelecom.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit -------------- next part -------------- An HTML attachment was scrubbed... URL: = http://www1.ietf.org/pipermail/ecrit/attachments/20060215/840ae5e2/attach= ment.htm ------------------------------ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit End of Ecrit Digest, Vol 13, Issue 20 ************************************* _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 15 21:38:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Z2A-0004ez-3r; Wed, 15 Feb 2006 21:38:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Z27-0004cQ-EU for ecrit@megatron.ietf.org; Wed, 15 Feb 2006 21:38:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07828 for ; Wed, 15 Feb 2006 21:36:27 -0500 (EST) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9ZGF-0007ct-70 for ecrit@ietf.org; Wed, 15 Feb 2006 21:52:52 -0500 Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net [141.153.211.136]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1G2c2P0004882 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 15 Feb 2006 21:38:07 -0500 (EST) In-Reply-To: <070c01c6329f$1d36b030$640fa8c0@cis.neustar.com> References: <070c01c6329f$1d36b030$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3552E5E4-94EE-499A-A4FF-B298BD37DF6C@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls Date: Wed, 15 Feb 2006 21:38:00 -0500 To: X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: "'Aquil, Kamran'" , ecrit@ietf.org, 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Feb 15, 2006, at 9:17 PM, Brian Rosen wrote: > If a country has a dialstring that is the text-to-police > dialstring, then we > must map it into a unique urn unless we know that in every instance > we can > differentiate the text calls from voice calls. I suspect that's hard. I don't think this is hard when you have the SDP information, as the codec list would differ depending on whether the caller (or caller's device) can do text or audio (or video). Alternatively, there's also the caller preferences model. > > With a SIP URI, you know you can use media negotiation to get the text > codec, and if the PSAP accepts the text call, then the mapper will > have the > same result for sos.police.txt as sos.police. If you have to map > instead to > some older technology, you have to differentiate (that is, the > mapping will > be different). > > It may be that we make an assumption that the mapping function does > not > yield a URI if the PSAP doesn't accept a call with a negotiated > text codec, > which would mean we don't need to have sos.police.txt. That would > force > backwards compatibility to existing systems when mapping fails. > That's not > terrible, but I thought it made more sense to let mapping yield a > URI that > resolved to the older technology. I'm biased towards making the initial system as simple as possible and leave out cases that may well become obsolete by the time we see deployment, particularly where, as in this case, adding them later is not hard, requiring only a registration action. If we're lucky, we'll never need the mechanism. I hope we all agree that having separate numbers for TTY (or other special media) is not a desirable situation from a user interface perspective, even if it exists in some places today. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 16 00:51:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9c2m-0004cW-Rq; Thu, 16 Feb 2006 00:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9c2M-0004Ke-UA for ecrit@megatron.ietf.org; Thu, 16 Feb 2006 00:50:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18120 for ; Thu, 16 Feb 2006 00:48:55 -0500 (EST) Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9cGN-0005DK-NX for ecrit@ietf.org; Thu, 16 Feb 2006 01:05:21 -0500 Received: from MISAN (213.64.230.47) by pne-smtpout2-sn1.fre.skanova.net (7.2.070) id 43EC2A6A00171994; Thu, 16 Feb 2006 06:49:53 +0100 From: "Gunnar Hellstrom" To: "Henning Schulzrinne" , Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Thu, 16 Feb 2006 06:49:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <3552E5E4-94EE-499A-A4FF-B298BD37DF6C@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: "'Aquil, Kamran'" , ecrit@ietf.org, 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please understand that just showing text capability in SDP does absolutely not mean that the user needs to get in touch with any special text-adapted handling in emergency. The real-time-text medium should be used in mainstream terminals to the benefit of all users. But if PSAPs have both text capable terminals and plain voice terminals, the real-time-text sdp capability can be taken as a guiding factor to answer the call in a capable terminal. Preference indications are more appropriate to use for diverting calls to special handling. Gunnar ---------------------------------------------------------------------------- - Gunnar Hellstrom, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, February 16, 2006 3:38 AM To: br@brianrosen.net Cc: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; ''Francois D. Menard' ' ; 'Gregg Vanderheiden' Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls On Feb 15, 2006, at 9:17 PM, Brian Rosen wrote: > If a country has a dialstring that is the text-to-police > dialstring, then we > must map it into a unique urn unless we know that in every instance > we can > differentiate the text calls from voice calls. I suspect that's hard. I don't think this is hard when you have the SDP information, as the codec list would differ depending on whether the caller (or caller's device) can do text or audio (or video). Alternatively, there's also the caller preferences model. > > With a SIP URI, you know you can use media negotiation to get the text > codec, and if the PSAP accepts the text call, then the mapper will > have the > same result for sos.police.txt as sos.police. If you have to map > instead to > some older technology, you have to differentiate (that is, the > mapping will > be different). > > It may be that we make an assumption that the mapping function does > not > yield a URI if the PSAP doesn't accept a call with a negotiated > text codec, > which would mean we don't need to have sos.police.txt. That would > force > backwards compatibility to existing systems when mapping fails. > That's not > terrible, but I thought it made more sense to let mapping yield a > URI that > resolved to the older technology. I'm biased towards making the initial system as simple as possible and leave out cases that may well become obsolete by the time we see deployment, particularly where, as in this case, adding them later is not hard, requiring only a registration action. If we're lucky, we'll never need the mechanism. I hope we all agree that having separate numbers for TTY (or other special media) is not a desirable situation from a user interface perspective, even if it exists in some places today. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 16 07:15:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9i3B-000076-PS; Thu, 16 Feb 2006 07:15:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9i38-0008VD-Og for ecrit@megatron.ietf.org; Thu, 16 Feb 2006 07:15:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16380 for ; Thu, 16 Feb 2006 07:14:07 -0500 (EST) Received: from ns.xittelecom.com ([205.151.16.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9iHI-00027F-7Z for ecrit@ietf.org; Thu, 16 Feb 2006 07:30:36 -0500 Received: from fmenard (helo=localhost) by ns.xittelecom.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1F9i2p-0001vC-00; Thu, 16 Feb 2006 07:15:35 -0500 Date: Thu, 16 Feb 2006 07:15:35 -0500 (EST) From: Francois Menard X-X-Sender: fmenard@localhost To: Henning Schulzrinne Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls In-Reply-To: <232E09D4-6327-4A28-9A1D-D469E4CEA48D@cs.columbia.edu> Message-ID: References: <232E09D4-6327-4A28-9A1D-D469E4CEA48D@cs.columbia.edu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-515440095-1140092135=:4579" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: "'Aquil, Kamran'" , 'Gregg Vanderheiden' , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-515440095-1140092135=:4579 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE If you look at my proposal, I was thinking of using SIMPLE for the=20 real-time-text between the SIP client 'MSN Messenger' and the PSAP=20 terminal 'MSN Messenger'. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Wed, 15 Feb 2006, Henning Schulzrinne wrote: > I don't think we want a service label for each media type. While *today*= =20 > there are PSAPs that only answer TTY calls, is this likely to make sense = in=20 > an all-IP PSAP environment where the media would terminate on the same PC= =20 > that's used for IM, video and so on? Why would you do this? > > Rather than trying to put SDP in a URN, maybe the better solution is to r= oute=20 > to one PSAP for the emergency service and have that PSAP then redirect th= e=20 > call based on the full SDP information, if this becomes necessary. That w= ay,=20 > you can deal with situations where the caller can handle a variety of mea= ns=20 > of communications, albeit with different ease, and the PSAP has access to= the=20 > full media information. > > Since this could be added on later if necessary, once we know whether any= body=20 > actually needs this, maybe it's better to avoid gratuitous complexity, bo= th=20 > in terms of protocol operation, testing (yet another thing a mapping prot= ocol=20 > has to test) and user agents. > > Henning > > On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > >> What would sos.police.tty do and how would it be invoked? >>=20 >> If it could lead to a text capable IP terminal, it should be called=20 >> sos.police.real-time-text or so. >>=20 >> If it helps to find a PSTN based PSAP with text capabilities, it could b= e=20 >> called sos.police.txp >>=20 >> tty is a US term. >>=20 >> Gunnar >>=20 >> ----------------------------------------------------------------------= =20 >> ------- >> Gunnar Hellstr=F6m, Omnitor >> gunnar.hellstrom@omnitor.se >> Mob: +46 708 204 288 >> Phone: +46 8 556 002 03 >> www.omnitor.se >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, February 16, 2006 12:17 AM >> To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D.= =20 >> M=E9nard' >> Cc: 'Gregg Vanderheiden' >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >>=20 >> All I get out of this for ecrit is that we need entries for sos.police.t= ty=20 >> in the service registry >>=20 >>=20 >>=20 >> Brian >>=20 >>=20 >>=20 >> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] >> Sent: Wednesday, February 15, 2006 5:47 PM >> To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. M= =E9nard >> Cc: Gregg Vanderheiden >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >>=20 >>=20 >>=20 >> It is quite widely accepted now that real-time text transmitted with its= =20 >> own text coded RTP payload RFC 4103 is used to carry text that may be=20 >> gatewayed to/from TTY/TDD/textphones in PSTN. >>=20 >>=20 >>=20 >> It is discussed in http://www.ietf.org/internet-drafts/draft-ietf-=20 >> sipping-toip-03.txt >>=20 >>=20 >>=20 >> And it is documented in http://www.ietf.org/internet-drafts/draft-=20 >> sinnreich-sipdev-req-08.txt >>=20 >>=20 >>=20 >> Also other standardisation bodies have picked up the real-time text conc= ept=20 >> in IP networks, and pointed at RFC 4103 (or its compatible predecessor= =20 >> RFC2793 ). E.g. 3GPP and ETSI. >>=20 >> A couple of years ago we had an intensive discussion in the SIMPLE mail= =20 >> list about the possibility to use MSRP to carry the real-time text mediu= m,=20 >> but we concluded that it would cause too much overhead or too much delay= =20 >> for the users, so that RTP was recommended instead. The most common use = of=20 >> MSRP is to not transmit until end of sentence, while for real time text,= =20 >> transmission is required with at most 500 ms interval as long as there i= s=20 >> anything to transmit in order to maintain the real-time feeling of being= in=20 >> touch in a conversation through this medium. >>=20 >>=20 >>=20 >> Quite commonly you will connect a text RTP stream and an audio RTP strea= m=20 >> and possibly a video RTP stream in the same call, so that you will get a= n=20 >> enhanced multimedia phone call with all supported media >>=20 >>=20 >>=20 >> The ecrit requirements also mentions this correspondence >>=20 >> in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt >>=20 >>=20 >> Re4. Multiple Modes: Multiple communication modes, such as audio, >> video and text messaging MUST be supported. >>=20 >> Motivation: In PSTN, voice and text telephony (often called TTY or >> textphone in North America) are the only commonly supported media. >> Emergency calling must support a variety of media. Such media >> should include voice, conversational text (RFC 4103 [9]), instant >> messaging and video. >>=20 >>=20 >>=20 >> I am working in a European group where one of the goals is to agree on= =20 >> handling text users' requirements on emergency calling in IP networks. = Of=20 >> course we want to agree on global solutions if possible. >>=20 >>=20 >>=20 >> Address mapping is one important and tricky question for text users. It = is=20 >> true that different countries have different approaches on emergency=20 >> calling with PSTN Text telephones (TTYs). Some have the same number as= =20 >> voice users, while others have specific numbers. On the SIP side it woul= d=20 >> be good to have the same URL and make any required routing based on=20 >> declared media, mode and language capabilities and preferences. >>=20 >>=20 >>=20 >> Text capable gateways are not at all as common as VoIP gateways, so if t= he=20 >> PSAP is still in PSTN, there is a need to have a good mechanism for rout= ing=20 >> emergency calls from SIP into PSTN through a text capable gateway. I can= not=20 >> say that the mechanisms for finding the right gateway and make the prope= r=20 >> address mapping to a PSTN number is solved yet for the text calls, and i= t=20 >> would be excellent if we could have that topic in mind in the discussion= s=20 >> and get proper methods documented. >>=20 >>=20 >>=20 >> I have drafted, but not yet submitted a registration of a SIP URL and an= =20 >> ENUM subservice for real-time text. It might be helpful for finding text= =20 >> gateways and mapping addresses and (text) numbers, but I would like to s= ee=20 >> some scenarios thoroughly discussed before adding SIP URL and another EN= UM=20 >> subservice. >>=20 >>=20 >>=20 >> Would there be any benefit of being allowed to enter TXP:112 or havin= g=20 >> ENUM to find an appropriate address if I call 112 from a SIP multimedi= a=20 >> phone declaring text capabilities with m=3Dtext in sdp? >>=20 >>=20 >>=20 >>=20 >>=20 >> Gunnar >>=20 >> ----------------------------------------------------------------------= =20 >> ------- >>=20 >> Gunnar Hellstr=F6m, Omnitor >>=20 >> gunnar.hellstrom@omnitor.se >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf Of= =20 >> Fran=E7ois D. M=E9nard >> Sent: Wednesday, February 15, 2006 5:14 PM >> To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls >>=20 >>=20 >> I made a contribution to CISC NTWG on use of SIP for transporting TDD=20 >> traffic: >>=20 >> http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc >>=20 >> I think it may be relevant to ECRIT. >>=20 >> -=3DFrancois=3D- >>=20 >>=20 >> On 2/15/06 10:51 AM, "Brian Rosen" wrote: >>=20 >> Within the scope of our work, I don=19t see how TDD services are impacte= d=20 >> until we get to the architecture effort, which probably has to have some= =20 >> sections on that subject. >> With respect to the mapping protocol, I do not believe there is any impa= ct=20 >> at all. >> With respect to the sos service urn, I do not believe there is any impac= t=20 >> at all >>=20 >> Ecrit doesn=19t have scope to talk about any kind of gateways or codec= =20 >> support. >>=20 >> Ah! My BCP on phones and proxies may need some mention, although this i= s=20 >> the IETF, and I don=19t think the ploy of forcing the entire PSTN to sup= port=20 >> TDD just so 9-1-1 TDD will work. That effort would have to be in the=20 >> general SIP arena. >>=20 >> Brian >>=20 >>=20 >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f=20 >> Aquil, Kamran >> Sent: Wednesday, February 15, 2006 10:31 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] ECRIT support for TTY/TDD calls >>=20 >>=20 >> Folks, >>=20 >>=20 >>=20 >> Like to know if there are specific ECRIT requirements recognizing suppor= t=20 >> for Telecommunications Device for the Deaf (TDD) services for the hearin= g=20 >> impaired. If not is this left for VOIP/SIP gateways to perform this=20 >> requirement of translating the TDD calls to Text and Speech encoding.=20 >> Wanted to make sure how ECRIT meet requirement for TDD services. >>=20 >>=20 >>=20 >> Regards, >> Kamran Aquil >> Intelligent Transportation Systems- Division >> Mitretek Systems. >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >>=20 >> --=20 >> Francois D. Menard >> fmenard@xittelecom.com >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > --8323328-515440095-1140092135=:4579 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --8323328-515440095-1140092135=:4579-- From ecrit-bounces@ietf.org Thu Feb 16 07:45:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9iVW-0004Gw-9b; Thu, 16 Feb 2006 07:45:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9iVU-0004Gr-Mt for ecrit@megatron.ietf.org; Thu, 16 Feb 2006 07:45:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18907 for ; Thu, 16 Feb 2006 07:43:25 -0500 (EST) Received: from 67.254.241.83.in-addr.dgcsystems.net ([83.241.254.67] helo=smtp.dgcsystems.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9iji-00039L-5U for ecrit@ietf.org; Thu, 16 Feb 2006 07:59:55 -0500 Received: from MISAN ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 13:45:09 +0100 From: "Gunnar Hellstrom" To: "Francois Menard" , "Henning Schulzrinne" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Thu, 16 Feb 2006 13:45:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 16 Feb 2006 12:45:09.0935 (UTC) FILETIME=[D25DE3F0:01C632F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA18907 Cc: 'Gregg Vanderheiden' , "'Aquil, Kamran'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Francois, Yes, I saw that you had specified SIMPLE for real time text. Can you explain how you intended to signal the real-time characteristics = of the session rather than the customary sentence-wise messaging that is usually assumed for SIMPLE? Sentence-wise transmission in emergency situations is risky. It creates l= oss of time, anxiousness etc. For loosely coupled messaging it is of course OK, but not for a tight conversation. The real-time text users do not accept more than a maximum of two seconds delay from typing a character until it is presented to the other user. An= d even that is regarded on the high side. One second is quite good. What we found when this was discussed in SIMPLE, was that the overhead ev= en from transmission with one second intervals would become more than what i= s feasible to use for the real-time text medium. The big VoIP gateway providers Can you accept to change your spec to use real-time RTP text? So that we together try to get the world move in the same direction. Sorry, if this is a deviation from the original topic of Ecrit. But it definitely influences the opportunities to act on capability and preferen= ce negotiation if you need to look for various ways of indication that you w= ant to use text in a call. Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com] Sent: Thursday, February 16, 2006 1:16 PM To: Henning Schulzrinne Cc: Gunnar Hellstrom; br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg Vanderheiden' Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls If you look at my proposal, I was thinking of using SIMPLE for the real-time-text between the SIP client 'MSN Messenger' and the PSAP terminal 'MSN Messenger'. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Wed, 15 Feb 2006, Henning Schulzrinne wrote: > I don't think we want a service label for each media type. While *today= * > there are PSAPs that only answer TTY calls, is this likely to make sens= e in > an all-IP PSAP environment where the media would terminate on the same = PC > that's used for IM, video and so on? Why would you do this? > > Rather than trying to put SDP in a URN, maybe the better solution is to route > to one PSAP for the emergency service and have that PSAP then redirect = the > call based on the full SDP information, if this becomes necessary. That way, > you can deal with situations where the caller can handle a variety of means > of communications, albeit with different ease, and the PSAP has access = to the > full media information. > > Since this could be added on later if necessary, once we know whether anybody > actually needs this, maybe it's better to avoid gratuitous complexity, both > in terms of protocol operation, testing (yet another thing a mapping protocol > has to test) and user agents. > > Henning > > On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > >> What would sos.police.tty do and how would it be invoked? >> >> If it could lead to a text capable IP terminal, it should be called >> sos.police.real-time-text or so. >> >> If it helps to find a PSTN based PSAP with text capabilities, it could= be >> called sos.police.txp >> >> tty is a US term. >> >> Gunnar >> >> ---------------------------------------------------------------------- >> ------- >> Gunnar Hellstr=F6m, Omnitor >> gunnar.hellstrom@omnitor.se >> Mob: +46 708 204 288 >> Phone: +46 8 556 002 03 >> www.omnitor.se >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, February 16, 2006 12:17 AM >> To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D. >> M=E9nard' >> Cc: 'Gregg Vanderheiden' >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> All I get out of this for ecrit is that we need entries for sos.police.tty >> in the service registry >> >> >> >> Brian >> >> >> >> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] >> Sent: Wednesday, February 15, 2006 5:47 PM >> To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. M=E9nard >> Cc: Gregg Vanderheiden >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> >> It is quite widely accepted now that real-time text transmitted with i= ts >> own text coded RTP payload RFC 4103 is used to carry text that may be >> gatewayed to/from TTY/TDD/textphones in PSTN. >> >> >> >> It is discussed in http://www.ietf.org/internet-drafts/draft-ietf- >> sipping-toip-03.txt >> >> >> >> And it is documented in http://www.ietf.org/internet-drafts/draft- >> sinnreich-sipdev-req-08.txt >> >> >> >> Also other standardisation bodies have picked up the real-time text concept >> in IP networks, and pointed at RFC 4103 (or its compatible predecessor >> RFC2793 ). E.g. 3GPP and ETSI. >> >> A couple of years ago we had an intensive discussion in the SIMPLE mai= l >> list about the possibility to use MSRP to carry the real-time text medium, >> but we concluded that it would cause too much overhead or too much del= ay >> for the users, so that RTP was recommended instead. The most common us= e of >> MSRP is to not transmit until end of sentence, while for real time tex= t, >> transmission is required with at most 500 ms interval as long as there= is >> anything to transmit in order to maintain the real-time feeling of bei= ng in >> touch in a conversation through this medium. >> >> >> >> Quite commonly you will connect a text RTP stream and an audio RTP str= eam >> and possibly a video RTP stream in the same call, so that you will get= an >> enhanced multimedia phone call with all supported media >> >> >> >> The ecrit requirements also mentions this correspondence >> >> in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt >> >> >> Re4. Multiple Modes: Multiple communication modes, such as audio, >> video and text messaging MUST be supported. >> >> Motivation: In PSTN, voice and text telephony (often called TTY = or >> textphone in North America) are the only commonly supported medi= a. >> Emergency calling must support a variety of media. Such media >> should include voice, conversational text (RFC 4103 [9]), instan= t >> messaging and video. >> >> >> >> I am working in a European group where one of the goals is to agree on >> handling text users' requirements on emergency calling in IP networks. Of >> course we want to agree on global solutions if possible. >> >> >> >> Address mapping is one important and tricky question for text users. I= t is >> true that different countries have different approaches on emergency >> calling with PSTN Text telephones (TTYs). Some have the same number as >> voice users, while others have specific numbers. On the SIP side it wo= uld >> be good to have the same URL and make any required routing based on >> declared media, mode and language capabilities and preferences. >> >> >> >> Text capable gateways are not at all as common as VoIP gateways, so if the >> PSAP is still in PSTN, there is a need to have a good mechanism for routing >> emergency calls from SIP into PSTN through a text capable gateway. I cannot >> say that the mechanisms for finding the right gateway and make the pro= per >> address mapping to a PSTN number is solved yet for the text calls, and= it >> would be excellent if we could have that topic in mind in the discussi= ons >> and get proper methods documented. >> >> >> >> I have drafted, but not yet submitted a registration of a SIP URL and = an >> ENUM subservice for real-time text. It might be helpful for finding te= xt >> gateways and mapping addresses and (text) numbers, but I would like to see >> some scenarios thoroughly discussed before adding SIP URL and another ENUM >> subservice. >> >> >> >> Would there be any benefit of being allowed to enter TXP:112 or hav= ing >> ENUM to find an appropriate address if I call 112 from a SIP multime= dia >> phone declaring text capabilities with m=3Dtext in sdp? >> >> >> >> >> >> Gunnar >> >> ---------------------------------------------------------------------- >> ------- >> >> Gunnar Hellstr=F6m, Omnitor >> >> gunnar.hellstrom@omnitor.se >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf = Of >> Fran=E7ois D. M=E9nard >> Sent: Wednesday, February 15, 2006 5:14 PM >> To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> I made a contribution to CISC NTWG on use of SIP for transporting TDD >> traffic: >> >> http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc >> >> I think it may be relevant to ECRIT. >> >> -=3DFrancois=3D- >> >> >> On 2/15/06 10:51 AM, "Brian Rosen" wrote: >> >> Within the scope of our work, I don=19t see how TDD services are impac= ted >> until we get to the architecture effort, which probably has to have so= me >> sections on that subject. >> With respect to the mapping protocol, I do not believe there is any impact >> at all. >> With respect to the sos service urn, I do not believe there is any imp= act >> at all >> >> Ecrit doesn=19t have scope to talk about any kind of gateways or codec >> support. >> >> Ah! My BCP on phones and proxies may need some mention, although this= is >> the IETF, and I don=19t think the ploy of forcing the entire PSTN to support >> TDD just so 9-1-1 TDD will work. That effort would have to be in the >> general SIP arena. >> >> Brian >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf= Of >> Aquil, Kamran >> Sent: Wednesday, February 15, 2006 10:31 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> Folks, >> >> >> >> Like to know if there are specific ECRIT requirements recognizing supp= ort >> for Telecommunications Device for the Deaf (TDD) services for the hear= ing >> impaired. If not is this left for VOIP/SIP gateways to perform this >> requirement of translating the TDD calls to Text and Speech encoding. >> Wanted to make sure how ECRIT meet requirement for TDD services. >> >> >> >> Regards, >> Kamran Aquil >> Intelligent Transportation Systems- Division >> Mitretek Systems. >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> >> -- >> Francois D. Menard >> fmenard@xittelecom.com >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 16 09:14:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9jtf-0002Es-NI; Thu, 16 Feb 2006 09:14:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9jte-0002Ej-AZ for ecrit@megatron.ietf.org; Thu, 16 Feb 2006 09:14:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26726 for ; Thu, 16 Feb 2006 09:12:26 -0500 (EST) Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9k7k-0006wJ-GR for ecrit@ietf.org; Thu, 16 Feb 2006 09:28:57 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1F9jtE-0003bA-Bo; Thu, 16 Feb 2006 08:13:49 -0600 From: "Brian Rosen" To: "'Gunnar Hellstrom'" , "'Francois Menard'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Thu, 16 Feb 2006 09:13:48 -0500 Message-ID: <07a801c63303$36c29c80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: Thread-Index: AcYy9tE2yxdpU8uqS82ltVyWM0iUKgAC5olA X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Content-Transfer-Encoding: quoted-printable Cc: "'Aquil, Kamran'" , ecrit@ietf.org, 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm thinking PSAPs will accept: SIP Session creation with audio, video and/or Interactive text Message transactions (IM with no session) MSRP Sessions (IM with session) There are some who want to accept XMPP as well as SIP IM. I don't think this is in ecrit scope until we get to the architecture, = and then it couldn't mandate that, just suggest it's likely. Gunnar, if the current capabilities negotiation in SIP are insufficient, = I think you have to raise them in sipping and not here. I don't think we = have scope for any of that. It's conceivable, if we do the architecture work, that we will discuss gateways, but I'm not certain it will be necessary to. Brian -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: Thursday, February 16, 2006 7:45 AM To: Francois Menard; Henning Schulzrinne Cc: br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg = Vanderheiden' Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Francois, Yes, I saw that you had specified SIMPLE for real time text. Can you explain how you intended to signal the real-time characteristics = of the session rather than the customary sentence-wise messaging that is usually assumed for SIMPLE? Sentence-wise transmission in emergency situations is risky. It creates = loss of time, anxiousness etc. For loosely coupled messaging it is of course OK, but not for a tight conversation. The real-time text users do not accept more than a maximum of two = seconds delay from typing a character until it is presented to the other user. = And even that is regarded on the high side. One second is quite good. What we found when this was discussed in SIMPLE, was that the overhead = even from transmission with one second intervals would become more than what = is feasible to use for the real-time text medium. The big VoIP gateway providers Can you accept to change your spec to use real-time RTP text? So that we together try to get the world move in the same direction. Sorry, if this is a deviation from the original topic of Ecrit. But it definitely influences the opportunities to act on capability and = preference negotiation if you need to look for various ways of indication that you = want to use text in a call. Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com] Sent: Thursday, February 16, 2006 1:16 PM To: Henning Schulzrinne Cc: Gunnar Hellstrom; br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg Vanderheiden' Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls If you look at my proposal, I was thinking of using SIMPLE for the real-time-text between the SIP client 'MSN Messenger' and the PSAP terminal 'MSN Messenger'. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Wed, 15 Feb 2006, Henning Schulzrinne wrote: > I don't think we want a service label for each media type. While = *today* > there are PSAPs that only answer TTY calls, is this likely to make = sense in > an all-IP PSAP environment where the media would terminate on the same = PC > that's used for IM, video and so on? Why would you do this? > > Rather than trying to put SDP in a URN, maybe the better solution is = to route > to one PSAP for the emergency service and have that PSAP then redirect = the > call based on the full SDP information, if this becomes necessary. = That way, > you can deal with situations where the caller can handle a variety of means > of communications, albeit with different ease, and the PSAP has access = to the > full media information. > > Since this could be added on later if necessary, once we know whether anybody > actually needs this, maybe it's better to avoid gratuitous complexity, both > in terms of protocol operation, testing (yet another thing a mapping protocol > has to test) and user agents. > > Henning > > On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > >> What would sos.police.tty do and how would it be invoked? >> >> If it could lead to a text capable IP terminal, it should be called >> sos.police.real-time-text or so. >> >> If it helps to find a PSTN based PSAP with text capabilities, it = could be >> called sos.police.txp >> >> tty is a US term. >> >> Gunnar >> >> = ---------------------------------------------------------------------- >> ------- >> Gunnar Hellstr=F6m, Omnitor >> gunnar.hellstrom@omnitor.se >> Mob: +46 708 204 288 >> Phone: +46 8 556 002 03 >> www.omnitor.se >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, February 16, 2006 12:17 AM >> To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois = D. >> M=E9nard' >> Cc: 'Gregg Vanderheiden' >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> All I get out of this for ecrit is that we need entries for sos.police.tty >> in the service registry >> >> >> >> Brian >> >> >> >> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] >> Sent: Wednesday, February 15, 2006 5:47 PM >> To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. M=E9nard >> Cc: Gregg Vanderheiden >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> >> It is quite widely accepted now that real-time text transmitted with = its >> own text coded RTP payload RFC 4103 is used to carry text that may be >> gatewayed to/from TTY/TDD/textphones in PSTN. >> >> >> >> It is discussed in http://www.ietf.org/internet-drafts/draft-ietf- >> sipping-toip-03.txt >> >> >> >> And it is documented in http://www.ietf.org/internet-drafts/draft- >> sinnreich-sipdev-req-08.txt >> >> >> >> Also other standardisation bodies have picked up the real-time text concept >> in IP networks, and pointed at RFC 4103 (or its compatible = predecessor >> RFC2793 ). E.g. 3GPP and ETSI. >> >> A couple of years ago we had an intensive discussion in the SIMPLE = mail >> list about the possibility to use MSRP to carry the real-time text medium, >> but we concluded that it would cause too much overhead or too much = delay >> for the users, so that RTP was recommended instead. The most common = use of >> MSRP is to not transmit until end of sentence, while for real time = text, >> transmission is required with at most 500 ms interval as long as = there is >> anything to transmit in order to maintain the real-time feeling of = being in >> touch in a conversation through this medium. >> >> >> >> Quite commonly you will connect a text RTP stream and an audio RTP = stream >> and possibly a video RTP stream in the same call, so that you will = get an >> enhanced multimedia phone call with all supported media >> >> >> >> The ecrit requirements also mentions this correspondence >> >> in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt >> >> >> Re4. Multiple Modes: Multiple communication modes, such as audio, >> video and text messaging MUST be supported. >> >> Motivation: In PSTN, voice and text telephony (often called TTY = or >> textphone in North America) are the only commonly supported = media. >> Emergency calling must support a variety of media. Such media >> should include voice, conversational text (RFC 4103 [9]), = instant >> messaging and video. >> >> >> >> I am working in a European group where one of the goals is to agree = on >> handling text users' requirements on emergency calling in IP = networks. Of >> course we want to agree on global solutions if possible. >> >> >> >> Address mapping is one important and tricky question for text users. = It is >> true that different countries have different approaches on emergency >> calling with PSTN Text telephones (TTYs). Some have the same number = as >> voice users, while others have specific numbers. On the SIP side it = would >> be good to have the same URL and make any required routing based on >> declared media, mode and language capabilities and preferences. >> >> >> >> Text capable gateways are not at all as common as VoIP gateways, so = if the >> PSAP is still in PSTN, there is a need to have a good mechanism for routing >> emergency calls from SIP into PSTN through a text capable gateway. I cannot >> say that the mechanisms for finding the right gateway and make the = proper >> address mapping to a PSTN number is solved yet for the text calls, = and it >> would be excellent if we could have that topic in mind in the = discussions >> and get proper methods documented. >> >> >> >> I have drafted, but not yet submitted a registration of a SIP URL and = an >> ENUM subservice for real-time text. It might be helpful for finding = text >> gateways and mapping addresses and (text) numbers, but I would like = to see >> some scenarios thoroughly discussed before adding SIP URL and another ENUM >> subservice. >> >> >> >> Would there be any benefit of being allowed to enter TXP:112 or = having >> ENUM to find an appropriate address if I call 112 from a SIP = multimedia >> phone declaring text capabilities with m=3Dtext in sdp? >> >> >> >> >> >> Gunnar >> >> = ---------------------------------------------------------------------- >> ------- >> >> Gunnar Hellstr=F6m, Omnitor >> >> gunnar.hellstrom@omnitor.se >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf = Of >> Fran=E7ois D. M=E9nard >> Sent: Wednesday, February 15, 2006 5:14 PM >> To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> I made a contribution to CISC NTWG on use of SIP for transporting TDD >> traffic: >> >> http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc >> >> I think it may be relevant to ECRIT. >> >> -=3DFrancois=3D- >> >> >> On 2/15/06 10:51 AM, "Brian Rosen" wrote: >> >> Within the scope of our work, I don=19t see how TDD services are = impacted >> until we get to the architecture effort, which probably has to have = some >> sections on that subject. >> With respect to the mapping protocol, I do not believe there is any impact >> at all. >> With respect to the sos service urn, I do not believe there is any = impact >> at all >> >> Ecrit doesn=19t have scope to talk about any kind of gateways or = codec >> support. >> >> Ah! My BCP on phones and proxies may need some mention, although = this is >> the IETF, and I don=19t think the ploy of forcing the entire PSTN to support >> TDD just so 9-1-1 TDD will work. That effort would have to be in the >> general SIP arena. >> >> Brian >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >> Aquil, Kamran >> Sent: Wednesday, February 15, 2006 10:31 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> Folks, >> >> >> >> Like to know if there are specific ECRIT requirements recognizing = support >> for Telecommunications Device for the Deaf (TDD) services for the = hearing >> impaired. If not is this left for VOIP/SIP gateways to perform this >> requirement of translating the TDD calls to Text and Speech encoding. >> Wanted to make sure how ECRIT meet requirement for TDD services. >> >> >> >> Regards, >> Kamran Aquil >> Intelligent Transportation Systems- Division >> Mitretek Systems. >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> >> -- >> Francois D. Menard >> fmenard@xittelecom.com >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 16 11:19:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lqV-0007U9-2g; Thu, 16 Feb 2006 11:19:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lqU-0007U4-78 for ecrit@megatron.ietf.org; Thu, 16 Feb 2006 11:19:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08881 for ; Thu, 16 Feb 2006 11:17:17 -0500 (EST) Received: from 67.254.241.83.in-addr.dgcsystems.net ([83.241.254.67] helo=smtp.dgcsystems.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9m4i-0003mb-Uy for ecrit@ietf.org; Thu, 16 Feb 2006 11:33:50 -0500 Received: from MISAN ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 17:19:02 +0100 From: "Gunnar Hellstrom" To: , "'Francois Menard'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Thu, 16 Feb 2006 17:19:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <07a801c63303$36c29c80$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 16 Feb 2006 16:19:02.0633 (UTC) FILETIME=[B3403590:01C63314] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08881 Cc: "'Aquil, Kamran'" , ecrit@ietf.org, 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, The ambitions for media and communication methods in PSAPs that you descr= ibe look good. Where are they discussed and agreed? I rechecked MSRP negotiation and see that it is a proper SDP media negotiation with m=3Dmessage. As you know, real time text is a proper SDP media negotiation with m=3Dte= xt. That makes it easy to specify a recommendation on what media to set up. Some decision needs to be taken if both are declared. Preferences or application agreements could help with that decision. It is quite likely that it will confuse the user if both types of text communication are accepted and offered in different windows. I agree that if there are no specific emergency application aspects on that selection, it should be discussed in sipping and simple. I noticed I left one sentence unfinished in my last mail. Here it is finished: If the big VoIP gateway providers are willing to consider PSTN textphone gatewaying at all, they likely only accept to consider gatewaying to RTP = for text. For small dedicated text gateways it is another situation, they can have = a wider range of communication methods on the IP side. We have reached one important conclusion: It is best to not do any specia= l addressing or routing for calls just because they include text capabiliti= es. Let all PSAP terminals handle voice and real-time text ( and any messagin= g format that may be agreed ). If special handling of deaf users is felt to be needed in some country, l= et that be initiated by other indications. Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, February 16, 2006 3:14 PM To: 'Gunnar Hellstrom'; 'Francois Menard'; 'Henning Schulzrinne' Cc: ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg Vanderheiden' Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls I'm thinking PSAPs will accept: SIP Session creation with audio, video and/or Interactive text Message transactions (IM with no session) MSRP Sessions (IM with session) There are some who want to accept XMPP as well as SIP IM. I don't think this is in ecrit scope until we get to the architecture, an= d then it couldn't mandate that, just suggest it's likely. Gunnar, if the current capabilities negotiation in SIP are insufficient, = I think you have to raise them in sipping and not here. I don't think we h= ave scope for any of that. It's conceivable, if we do the architecture work, that we will discuss gateways, but I'm not certain it will be necessary to. Brian -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: Thursday, February 16, 2006 7:45 AM To: Francois Menard; Henning Schulzrinne Cc: br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg Vanderheid= en' Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Francois, Yes, I saw that you had specified SIMPLE for real time text. Can you explain how you intended to signal the real-time characteristics = of the session rather than the customary sentence-wise messaging that is usually assumed for SIMPLE? Sentence-wise transmission in emergency situations is risky. It creates l= oss of time, anxiousness etc. For loosely coupled messaging it is of course OK, but not for a tight conversation. The real-time text users do not accept more than a maximum of two seconds delay from typing a character until it is presented to the other user. An= d even that is regarded on the high side. One second is quite good. What we found when this was discussed in SIMPLE, was that the overhead ev= en from transmission with one second intervals would become more than what i= s feasible to use for the real-time text medium. The big VoIP gateway providers Can you accept to change your spec to use real-time RTP text? So that we together try to get the world move in the same direction. Sorry, if this is a deviation from the original topic of Ecrit. But it definitely influences the opportunities to act on capability and preferen= ce negotiation if you need to look for various ways of indication that you w= ant to use text in a call. Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com] Sent: Thursday, February 16, 2006 1:16 PM To: Henning Schulzrinne Cc: Gunnar Hellstrom; br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Gregg Vanderheiden' Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls If you look at my proposal, I was thinking of using SIMPLE for the real-time-text between the SIP client 'MSN Messenger' and the PSAP terminal 'MSN Messenger'. F. -- Francois D. Menard Project Manager/Charge de projet Xit telecom inc. 1350 Royale # 800 Trois-Rivieres, QC, G9A 4J4 Tel: +1 819 374 2556 x 268 Cell: +1 819 692 1383 fmenard@xittelecom.com On Wed, 15 Feb 2006, Henning Schulzrinne wrote: > I don't think we want a service label for each media type. While *today= * > there are PSAPs that only answer TTY calls, is this likely to make sens= e in > an all-IP PSAP environment where the media would terminate on the same = PC > that's used for IM, video and so on? Why would you do this? > > Rather than trying to put SDP in a URN, maybe the better solution is to route > to one PSAP for the emergency service and have that PSAP then redirect = the > call based on the full SDP information, if this becomes necessary. That way, > you can deal with situations where the caller can handle a variety of means > of communications, albeit with different ease, and the PSAP has access = to the > full media information. > > Since this could be added on later if necessary, once we know whether anybody > actually needs this, maybe it's better to avoid gratuitous complexity, both > in terms of protocol operation, testing (yet another thing a mapping protocol > has to test) and user agents. > > Henning > > On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > >> What would sos.police.tty do and how would it be invoked? >> >> If it could lead to a text capable IP terminal, it should be called >> sos.police.real-time-text or so. >> >> If it helps to find a PSTN based PSAP with text capabilities, it could= be >> called sos.police.txp >> >> tty is a US term. >> >> Gunnar >> >> ---------------------------------------------------------------------- >> ------- >> Gunnar Hellstr=F6m, Omnitor >> gunnar.hellstrom@omnitor.se >> Mob: +46 708 204 288 >> Phone: +46 8 556 002 03 >> www.omnitor.se >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, February 16, 2006 12:17 AM >> To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D. >> M=E9nard' >> Cc: 'Gregg Vanderheiden' >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> All I get out of this for ecrit is that we need entries for sos.police.tty >> in the service registry >> >> >> >> Brian >> >> >> >> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] >> Sent: Wednesday, February 15, 2006 5:47 PM >> To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D. M=E9nard >> Cc: Gregg Vanderheiden >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> >> It is quite widely accepted now that real-time text transmitted with i= ts >> own text coded RTP payload RFC 4103 is used to carry text that may be >> gatewayed to/from TTY/TDD/textphones in PSTN. >> >> >> >> It is discussed in http://www.ietf.org/internet-drafts/draft-ietf- >> sipping-toip-03.txt >> >> >> >> And it is documented in http://www.ietf.org/internet-drafts/draft- >> sinnreich-sipdev-req-08.txt >> >> >> >> Also other standardisation bodies have picked up the real-time text concept >> in IP networks, and pointed at RFC 4103 (or its compatible predecessor >> RFC2793 ). E.g. 3GPP and ETSI. >> >> A couple of years ago we had an intensive discussion in the SIMPLE mai= l >> list about the possibility to use MSRP to carry the real-time text medium, >> but we concluded that it would cause too much overhead or too much del= ay >> for the users, so that RTP was recommended instead. The most common us= e of >> MSRP is to not transmit until end of sentence, while for real time tex= t, >> transmission is required with at most 500 ms interval as long as there= is >> anything to transmit in order to maintain the real-time feeling of bei= ng in >> touch in a conversation through this medium. >> >> >> >> Quite commonly you will connect a text RTP stream and an audio RTP str= eam >> and possibly a video RTP stream in the same call, so that you will get= an >> enhanced multimedia phone call with all supported media >> >> >> >> The ecrit requirements also mentions this correspondence >> >> in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt >> >> >> Re4. Multiple Modes: Multiple communication modes, such as audio, >> video and text messaging MUST be supported. >> >> Motivation: In PSTN, voice and text telephony (often called TTY = or >> textphone in North America) are the only commonly supported medi= a. >> Emergency calling must support a variety of media. Such media >> should include voice, conversational text (RFC 4103 [9]), instan= t >> messaging and video. >> >> >> >> I am working in a European group where one of the goals is to agree on >> handling text users' requirements on emergency calling in IP networks. Of >> course we want to agree on global solutions if possible. >> >> >> >> Address mapping is one important and tricky question for text users. I= t is >> true that different countries have different approaches on emergency >> calling with PSTN Text telephones (TTYs). Some have the same number as >> voice users, while others have specific numbers. On the SIP side it wo= uld >> be good to have the same URL and make any required routing based on >> declared media, mode and language capabilities and preferences. >> >> >> >> Text capable gateways are not at all as common as VoIP gateways, so if the >> PSAP is still in PSTN, there is a need to have a good mechanism for routing >> emergency calls from SIP into PSTN through a text capable gateway. I cannot >> say that the mechanisms for finding the right gateway and make the pro= per >> address mapping to a PSTN number is solved yet for the text calls, and= it >> would be excellent if we could have that topic in mind in the discussi= ons >> and get proper methods documented. >> >> >> >> I have drafted, but not yet submitted a registration of a SIP URL and = an >> ENUM subservice for real-time text. It might be helpful for finding te= xt >> gateways and mapping addresses and (text) numbers, but I would like to see >> some scenarios thoroughly discussed before adding SIP URL and another ENUM >> subservice. >> >> >> >> Would there be any benefit of being allowed to enter TXP:112 or hav= ing >> ENUM to find an appropriate address if I call 112 from a SIP multime= dia >> phone declaring text capabilities with m=3Dtext in sdp? >> >> >> >> >> >> Gunnar >> >> ---------------------------------------------------------------------- >> ------- >> >> Gunnar Hellstr=F6m, Omnitor >> >> gunnar.hellstrom@omnitor.se >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On Behalf = Of >> Fran=E7ois D. M=E9nard >> Sent: Wednesday, February 15, 2006 5:14 PM >> To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> I made a contribution to CISC NTWG on use of SIP for transporting TDD >> traffic: >> >> http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc >> >> I think it may be relevant to ECRIT. >> >> -=3DFrancois=3D- >> >> >> On 2/15/06 10:51 AM, "Brian Rosen" wrote: >> >> Within the scope of our work, I don=19t see how TDD services are impac= ted >> until we get to the architecture effort, which probably has to have so= me >> sections on that subject. >> With respect to the mapping protocol, I do not believe there is any impact >> at all. >> With respect to the sos service urn, I do not believe there is any imp= act >> at all >> >> Ecrit doesn=19t have scope to talk about any kind of gateways or codec >> support. >> >> Ah! My BCP on phones and proxies may need some mention, although this= is >> the IETF, and I don=19t think the ploy of forcing the entire PSTN to support >> TDD just so 9-1-1 TDD will work. That effort would have to be in the >> general SIP arena. >> >> Brian >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf= Of >> Aquil, Kamran >> Sent: Wednesday, February 15, 2006 10:31 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> Folks, >> >> >> >> Like to know if there are specific ECRIT requirements recognizing supp= ort >> for Telecommunications Device for the Deaf (TDD) services for the hear= ing >> impaired. If not is this left for VOIP/SIP gateways to perform this >> requirement of translating the TDD calls to Text and Speech encoding. >> Wanted to make sure how ECRIT meet requirement for TDD services. >> >> >> >> Regards, >> Kamran Aquil >> Intelligent Transportation Systems- Division >> Mitretek Systems. >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> >> -- >> Francois D. Menard >> fmenard@xittelecom.com >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 16 15:15:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9pXg-0008VM-Gd; Thu, 16 Feb 2006 15:15:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9pXa-0008Nq-E5 for ecrit@megatron.ietf.org; Thu, 16 Feb 2006 15:15:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00514 for ; Thu, 16 Feb 2006 15:14:02 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9pln-0006Mq-Ge for ecrit@ietf.org; Thu, 16 Feb 2006 15:30:36 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k1GKELjH030831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2006 12:14:22 -0800 Received: from [67.188.152.237] (vpn-10-50-0-122.qualcomm.com [10.50.0.122]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k1GKEIIW022071; Thu, 16 Feb 2006 12:14:19 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <070c01c6329f$1d36b030$640fa8c0@cis.neustar.com> References: <070c01c6329f$1d36b030$640fa8c0@cis.neustar.com> Date: Thu, 16 Feb 2006 12:14:15 -0800 To: br@brianrosen.net, "'Henning Schulzrinne'" , "'Gunnar Hellstrom'" From: Ted Hardie Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by numenor.qualcomm.com id k1GKELjH030831 X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Content-Transfer-Encoding: quoted-printable Cc: "'Aquil, Kamran'" , ecrit@ietf.org, 'Gregg Vanderheiden' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 9:17 PM -0500 2/15/06, Brian Rosen wrote: >If a country has a dialstring that is the text-to-police dialstring, the= n we >must map it into a unique urn unless we know that in every instance we c= an >differentiate the text calls from voice calls. I suspect that's hard. > >With a SIP URI, you know you can use media negotiation to get the text >codec, and if the PSAP accepts the text call, then the mapper will have = the >same result for sos.police.txt as sos.police. If you have to map instea= d to >some older technology, you have to differentiate (that is, the mapping w= ill >be different). It does seem possible to define a URI scheme specific to the text service= , so that the mapping protocol can respond with a URI for that service which is distinguishable from the voice service. As it stands, we have said that the mapping protocol should return at most one result per URI scheme, but if the URI schemes are distinct that's not a problem. This also makes it possible to define the text-capable PSAP mapping independently of the voice-capable PSAP mapping, which may be valuable if a subset of PSAPs are capable. I agree with Henning, though, that this subset case should get rarer. regards, Ted >It may be that we make an assumption that the mapping function does not >yield a URI if the PSAP doesn't accept a call with a negotiated text cod= ec, >which would mean we don't need to have sos.police.txt. That would force >backwards compatibility to existing systems when mapping fails. That's = not >terrible, but I thought it made more sense to let mapping yield a URI th= at >resolved to the older technology. > >Brian > >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Wednesday, February 15, 2006 8:06 PM >To: Gunnar Hellstrom >Cc: br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois D. M= =E9nard' >; 'Gregg Vanderheiden' >Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls > >I don't think we want a service label for each media type. While=20 >*today* there are PSAPs that only answer TTY calls, is this likely to=20 >make sense in an all-IP PSAP environment where the media would=20 >terminate on the same PC that's used for IM, video and so on? Why=20 >would you do this? > >Rather than trying to put SDP in a URN, maybe the better solution is=20 >to route to one PSAP for the emergency service and have that PSAP=20 >then redirect the call based on the full SDP information, if this=20 >becomes necessary. That way, you can deal with situations where the=20 >caller can handle a variety of means of communications, albeit with=20 >different ease, and the PSAP has access to the full media information. > >Since this could be added on later if necessary, once we know whether=20 >anybody actually needs this, maybe it's better to avoid gratuitous=20 >complexity, both in terms of protocol operation, testing (yet another=20 >thing a mapping protocol has to test) and user agents. > >Henning > >On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > >> What would sos.police.tty do and how would it be invoked? >> >> If it could lead to a text capable IP terminal, it should be called=20 >> sos.police.real-time-text or so. >> >> If it helps to find a PSTN based PSAP with text capabilities, it=20 >> could be called sos.police.txp >> >> tty is a US term. >> >> Gunnar >> >> ---------------------------------------------------------------------- >> ------- >> Gunnar Hellstr=F6m, Omnitor >> gunnar.hellstrom@omnitor.se >> Mob: +46 708 204 288 >> Phone: +46 8 556 002 03 >> www.omnitor.se >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, February 16, 2006 12:17 AM >> To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran'; 'Fran=E7ois=20 >> D. M=E9nard' >> Cc: 'Gregg Vanderheiden' >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > >> All I get out of this for ecrit is that we need entries for=20 >> sos.police.tty in the service registry >> >> >> >> Brian >> >> >> >> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] >> Sent: Wednesday, February 15, 2006 5:47 PM >> To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net; Fran=E7ois D.=20 >> M=E9nard >> Cc: Gregg Vanderheiden >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> >> It is quite widely accepted now that real-time text transmitted=20 >> with its own text coded RTP payload RFC 4103 is used to carry text=20 >> that may be gatewayed to/from TTY/TDD/textphones in PSTN. >> >> >> >> It is discussed in http://www.ietf.org/internet-drafts/draft-ietf- >> sipping-toip-03.txt >> >> >> >> And it is documented in http://www.ietf.org/internet-drafts/draft- >> sinnreich-sipdev-req-08.txt >> >> >> >> Also other standardisation bodies have picked up the real-time text=20 >> concept in IP networks, and pointed at RFC 4103 (or its compatible=20 >> predecessor RFC2793 ). E.g. 3GPP and ETSI. >> >> A couple of years ago we had an intensive discussion in the SIMPLE=20 >> mail list about the possibility to use MSRP to carry the real-time=20 >> text medium, but we concluded that it would cause too much overhead=20 >> or too much delay for the users, so that RTP was recommended=20 >> instead. The most common use of MSRP is to not transmit until end=20 >> of sentence, while for real time text, transmission is required=20 >> with at most 500 ms interval as long as there is anything to=20 >> transmit in order to maintain the real-time feeling of being in=20 >> touch in a conversation through this medium. >> >> >> >> Quite commonly you will connect a text RTP stream and an audio RTP=20 >> stream and possibly a video RTP stream in the same call, so that=20 >> you will get an enhanced multimedia phone call with all supported=20 >> media >> >> >> >> The ecrit requirements also mentions this correspondence >> >> in www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt >> >> >> Re4. Multiple Modes: Multiple communication modes, such as audio, >> video and text messaging MUST be supported. >> >> Motivation: In PSTN, voice and text telephony (often called=20 >> TTY or >> textphone in North America) are the only commonly supported=20 >> media. >> Emergency calling must support a variety of media. Such media >> should include voice, conversational text (RFC 4103 [9]),=20 >> instant >> messaging and video. >> >> >> >> I am working in a European group where one of the goals is to agree=20 >> on handling text users' requirements on emergency calling in IP=20 >> networks. Of course we want to agree on global solutions if possible. >> >> >> >> Address mapping is one important and tricky question for text=20 >> users. It is true that different countries have different=20 >> approaches on emergency calling with PSTN Text telephones (TTYs).=20 >> Some have the same number as voice users, while others have=20 >> specific numbers. On the SIP side it would be good to have the same=20 >> URL and make any required routing based on declared media, mode and=20 >> language capabilities and preferences. >> >> >> >> Text capable gateways are not at all as common as VoIP gateways, so=20 >> if the PSAP is still in PSTN, there is a need to have a good=20 >> mechanism for routing emergency calls from SIP into PSTN through a=20 >> text capable gateway. I cannot say that the mechanisms for finding=20 >> the right gateway and make the proper address mapping to a PSTN=20 >> number is solved yet for the text calls, and it would be excellent=20 >> if we could have that topic in mind in the discussions and get=20 >> proper methods documented. >> >> >> >> I have drafted, but not yet submitted a registration of a SIP URL=20 >> and an ENUM subservice for real-time text. It might be helpful for=20 >> finding text gateways and mapping addresses and (text) numbers, but=20 >> I would like to see some scenarios thoroughly discussed before=20 >> adding SIP URL and another ENUM subservice. >> >> >> >> Would there be any benefit of being allowed to enter TXP:112 or=20 >> having ENUM to find an appropriate address if I call 112 from a=20 >> SIP multimedia phone declaring text capabilities with m=3Dtext in sdp? > > >> >> >> >> >> Gunnar >> >> ---------------------------------------------------------------------- >> ------- >> >> Gunnar Hellstr=F6m, Omnitor >> >> gunnar.hellstrom@omnitor.se >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]On=20 >> Behalf Of Fran=E7ois D. M=E9nard >> Sent: Wednesday, February 15, 2006 5:14 PM >> To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> I made a contribution to CISC NTWG on use of SIP for transporting=20 >> TDD traffic: >> >> http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc >> >> I think it may be relevant to ECRIT. >> >> -=3DFrancois=3D- >> >> >> On 2/15/06 10:51 AM, "Brian Rosen" wrote: >> >> Within the scope of our work, I don=92t see how TDD services are=20 >> impacted until we get to the architecture effort, which probably=20 >> has to have some sections on that subject. >> With respect to the mapping protocol, I do not believe there is any=20 >> impact at all. >> With respect to the sos service urn, I do not believe there is any=20 >> impact at all >> >> Ecrit doesn=92t have scope to talk about any kind of gateways or=20 >> codec support. >> >> Ah! My BCP on phones and proxies may need some mention, although=20 >> this is the IETF, and I don=92t think the ploy of forcing the entire=20 >> PSTN to support TDD just so 9-1-1 TDD will work. That effort would=20 >> have to be in the general SIP arena. >> >> Brian >> >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> Behalf Of Aquil, Kamran >> Sent: Wednesday, February 15, 2006 10:31 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] ECRIT support for TTY/TDD calls >> >> >> Folks, >> >> >> >> Like to know if there are specific ECRIT requirements recognizing=20 >> support for Telecommunications Device for the Deaf (TDD) services=20 >> for the hearing impaired. If not is this left for VOIP/SIP gateways=20 >> to perform this requirement of translating the TDD calls to Text=20 >> and Speech encoding. Wanted to make sure how ECRIT meet requirement=20 >> for TDD services. >> >> >> >> Regards, >> Kamran Aquil >> Intelligent Transportation Systems- Division >> Mitretek Systems. >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> >> -- >> Francois D. Menard >> fmenard@xittelecom.com >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 17 09:48:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6u2-0001BA-ED; Fri, 17 Feb 2006 09:48:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6ps-0007E7-DM for ecrit@megatron.ietf.org; Fri, 17 Feb 2006 09:43:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11763 for ; Fri, 17 Feb 2006 09:28:30 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9sP7-0002s3-5L for ecrit@ietf.org; Thu, 16 Feb 2006 18:19:19 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k1GN4DpH015938; Fri, 17 Feb 2006 00:04:13 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k1GN490A008994; Fri, 17 Feb 2006 00:04:12 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 00:04:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2006 00:04:08 +0100 Message-ID: Thread-Topic: WG: I-D ACTION:draft-taylor-ecrit-security-threats-02.txt thread-index: AcYzQWKYpr18I8QBR+y8FnBdfUfguQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 16 Feb 2006 23:04:09.0913 (UTC) FILETIME=[4B84CA90:01C6334D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Subject: [Ecrit] WG: I-D ACTION:draft-taylor-ecrit-security-threats-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all,=20 during the ECRIT interim meeting we discussed how to re-write the ECRIT = Security Threats draft. Tom started already at the interim meeting and = here is another draft update. Thanks Tom! During the interim meeting Andy, Spencer and Roger agreed to quickly = review the draft. Feedback by everyone is, as usual, highly appreciated. Ciao Hannes=20 -----Urspr=FCngliche Nachricht----- Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] Im Auftrag von = Internet-Drafts@ietf.org Gesendet: Donnerstag, 16. Februar 2006 21:50 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-taylor-ecrit-security-threats-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Security Threats and Requirements for Emergency Call Mapping Author(s) : H. Schulzrinne Filename : draft-taylor-ecrit-security-threats-02.txt Pages : 16 Date : 2006-2-16 =09 This document reviews the security threats to the process of mapping locations to URIs pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the threats, this document establishes a set of security requirements for the mapping protocol, which is being developed by the ECRIT Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-0= 2.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 17 10:16:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7La-0008FH-AH; Fri, 17 Feb 2006 10:16:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA71U-0001Gk-Br for ecrit@megatron.ietf.org; Fri, 17 Feb 2006 09:55:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09566 for ; Fri, 17 Feb 2006 09:21:30 -0500 (EST) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9txZ-0006Um-Et for ecrit@ietf.org; Thu, 16 Feb 2006 19:58:58 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 16 Feb 2006 16:43:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] AW: Requirements Draft close to completion Date: Thu, 16 Feb 2006 16:43:56 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657504444F89@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] AW: Requirements Draft close to completion Thread-Index: AcYpGuOrlFGcU7rJQaS0Q/pkRe93rAAokvDgAhyKfFAAR+18gA== From: "Roger Marshall" To: "Abbott, Nadine B" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Nadine: Thanks very much for your feedback. See my responses inline. -roger.=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Abbott, Nadine B >Sent: Wednesday, February 15, 2006 6:09 AM >To: ecrit@ietf.org >Subject: RE: [Ecrit] AW: Requirements Draft close to completion > >Hannes, Roger, all, > >Thanks to Roger for the quick turn-around and heroic efforts=20 >to capture lively discussion in text. >After reviewing my notes, the meeting minutes and logs, I'd=20 >like to suggest a few small text edits in the requirements documents. > >1) Thanks for adding a definition for PSAP URI. It would help=20 >to add the example of ESRP, I think.=20 >The change text is <> to say: > PSAP URI: PSAP URI is a general term, used to refer to the=20 >output of > the mapping protocol, and represents either the=20 >actual PSAP IP > address, or <intermediary, e.g.,=20 > an ESRP,>> which points to the actual PSAP. Suggested change accepted for next version. > >2) Need to add a definition for the acronym LCMS or spell out=20 >(used in requirement Ma24X). Added definition for LCMS, and defined as follows, (based on language = found in draft-polk-newton-ecrit-arch-considerations-01.txt): "Location Context Mapping System (LCMS): A system=20 defined as a set of mechanisms and services working together to=20 perform a mapping, (or, direct association), between a location and a=20 PSAP uri designated as responsibleto to serve that location." > >3) Minor edits: > Ma7: Multiple PSAP <> (no apostrophe needed) > Ma9: replace "urii" with "uri" Ma7: done Ma9X: done > >4) We added two new requirements to further clarify the=20 >requirements on the protocol in responding to location=20 >validation requests: Lo1X and Lo1XX. I think I understand=20 >them, but I am not sure that someone not involved in the=20 >discussion would understand them the same way. In the=20 >discussion (see posted meeting notes) we said: "Do we agree=20 >that we need a result code, in addition to a URI? Partial=20 >validation may be the common case (public verifiers won't know=20 >suite numbers/room numbers, for example)... The protocol MUST=20 >have the mechanism (whether it gets used or not is up to the=20 >administration)." I think it would clarify requirement Lo1X to=20 >add a motivation with wording like the following in <>.=20 > =20 > Lo1X. Validation Resolution: The mapping protocol MUST support the > return of additional information which can be used to determine > the precision or resolution of the data elements used to=20 >determine > a PSAP URI, for example. > =20 > <data elements=20 > in the location in determining a match, or=20 >may be able=20 > to find a match for all but specific tags. =20 > The specifics of the information used may vary among=20 > emergency jurisdictions. Precision or=20 >resolution in the context=20 > of this requirement might mean, for example,=20 >explicit identification=20 > of the data elements that were used=20 >successfully in the mapping.>>=20 Added Motivation section to Lo1X, based on (though reworded) text = provided above: "Motivation: The mapping server may not use all the data elements in=20 the provided location information to determine a match, or may be able = to=20 find a match based on all of the information execept for some specific=20 data elements. The uniqueness of this information set may be used to=20 differentiate among emergency jurisdictions. Precision or resolution in = the context of this requirement might mean, for example, explicit=20 identification of the data elements that were used successfully in the=20 mapping." Please let me know if this does NOT convey what you wanted to say. > >5) There was also another idea that I think it would be=20 >valuable to capture--that it is useful to be able to provide=20 >in the response a URI that the client can then use to further=20 >resolve problems. (See posted meeting notes: "Does the ECRIT=20 >protocol need to provide a way to fix data that's wrong in the=20 >database? No, but is it helpful to provide a URL for a=20 >mechanism that would help in fixing the data? NENA did this -=20 >it's actually helpful. We can't tell whether the user is wrong=20 >or the database is wrong.") I think this is a requirement on=20 >the protocol and is more than just an indication that=20 >something is wrong. Therefore, I suggest that we add text=20 >like the following in <> to Lo1XX, plus maybe a=20 >Motivation with wording like that below in <>.=20 > > Lo1XX. Indication of non-existent location: The protocol MUST > support a mechanism to indicate that a location or a part of a > location is known to not exist, even if a valid location-to-PSAP > uri mapping can be provided. <support inclusion=20 > of a means to identify a separate mechanism to resolve=20 >the discrepancy.>> > > <may provide a means=20 > to resolve addressing problems, e.g., a=20 >URI for a web service=20 > that can be used to report problems with=20 >an address.=20 > The response should allow this service to=20 >be identified.>> I've rewritten the requirement Lo1XX some, taking into consideration the = suggested text as well as provided a parenthetical for purposes of = clarifying per RFC 2119. A Motivation text block has also been added = (though reworded some from the original suggested text). "Lo1XX. Indication of non-existent location: The=20 protocol MUST support (i.e. must implement in the protocol, though not=20 necessarily use), a mechanism to indicate that a location or a=20 part of a location is known to not exist, even if a valid = location-to-PSAP=20 uri mapping can be provided. This mechanism includes a means to=20 identify a separate mechanism that could be used to resolve the=20 discrepancy." "Motivation: The emergency authority for a given jurisdiction may=20 provide a means to resolve addressing problems, e.g., a URI for a=20 web service that can be used to report problems with an address. =20 The mapping response would allow this service to be identified." Please let me know if this does NOT coincide with what you were trying = to say. Roger Marshall > =20 >Regards, >Nadine Abbott > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Tschofenig, Hannes >Sent: Saturday, February 04, 2006 2:01 PM >To: ecrit@ietf.org >Subject: [Ecrit] AW: Requirements Draft close to completion > >Hi all,=20 > >The issue tracker is currently empty since Roger closed all of them.=20 >If you want to retrieve the full list of issues (including all=20 >closed issues) please use the following link: >http://www.ietf-ecrit.org:8080/ecrit-req/issue?:columns=3Did,acti vity,title,creator,assignedto,status&:sort=3Did&:group=3Dstatus&:pagesize= =3D50&:startwith=3D0 > >ciao >hannes >> -----Urspr=FCngliche Nachricht----- >> Von: Tschofenig, Hannes >> Gesendet: Samstag, 4. Februar 2006 00:38 >> An: 'ecrit@ietf.org' >> Betreff: Requirements Draft close to completion >>=20 >> Hi all, >>=20 >> the first day of the interim meeting was spend to walk through the=20 >> open issues of draft-ietf-ecrit-requirements-02.txt. We were able to=20 >> close ALL open issues. Thanks to all the participants. >>=20 >> Roger has already incorporated the suggested changes into a new=20 >> version and he submitted the document already. Please find it at >> http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements- >> 03.txt (before it appears in the IETF archive). >> Thank you Roger! >>=20 >> To make sure that we have indeed addressed all open issues listed at=20 >> http://www.ietf-ecrit.org:8080/ecrit-req >> correctly we would like to ask everyone to review the document again=20 >> and to ask those people who haven't had the chance to attend the=20 >> interim meeting to carefully inspect whether their open issue was=20 >> adequately addressed. >>=20 >> The next steps for this document are as follows: >>=20 >> - Roger will add information to each requirement to indicate whether=20 >> the RFC 2119 language refers to >> (a) a requirement for an implementation or to >> (b) a requirement for usage >> He will then resubmit the document. Targeted resubmission >> date: next week >>=20 >> - We would then like to start a WGLC on the 20th February running for >> 2 weeks. >>=20 >> Since these goals are quite ambitious we would like to ask for your=20 >> help. Please review the document as early as possible AND make=20 >> constructive feedback (e.g., text suggestions instead of=20 >just stating=20 >> 'i don't like it'). >>=20 >> Ciao >> Hannes & Marc >>=20 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 17 10:33:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7bs-0000Ct-3X; Fri, 17 Feb 2006 10:33:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7bq-0000AX-Q2 for ecrit@megatron.ietf.org; Fri, 17 Feb 2006 10:33:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26036 for ; Fri, 17 Feb 2006 10:31:36 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7qG-0007PI-NN for ecrit@ietf.org; Fri, 17 Feb 2006 10:48:21 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2006 07:33:15 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1HFXEjx014034 for ; Fri, 17 Feb 2006 07:33:14 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 07:33:14 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 07:33:14 -0800 From: "Marc Linsner" To: Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls Date: Fri, 17 Feb 2006 10:33:12 -0500 Message-ID: <007001c633d7$76b53490$2f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcYzNeXmSYwCa0uvQ66SgQCNsoY0oQAn6BVA In-Reply-To: X-OriginalArrivalTime: 17 Feb 2006 15:33:14.0397 (UTC) FILETIME=[77966CD0:01C633D7] X-Spam-Score: 3.4 (+++) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 Content-Transfer-Encoding: quoted-printable X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org After reading this thread, it makes one wonder if ecrit mapping is the = most appropriate place to perform 'routing' based on attributes other than pidf-lo. If we define service urns for media types, why not language preferences? Why not time of day? Why not current weather conditions? = Why not color of handset? My point: Routing based on non-location attributes belongs to the = ESRP/PSAP domain and should remain there. I don't believe that anyone expects the = uri returned by the ecrit mapping mechanism to be the actual end device at = the PSAP. There will be an intermediary proxy that can/should handle = routing based on attributes other than location. IMO, keeping the = for-public-view ECRIT mapping simple and clean goes a long way towards acceptance and easy/fast implementation. -Marc- > At 9:17 PM -0500 2/15/06, Brian Rosen wrote: > >If a country has a dialstring that is the text-to-police dialstring,=20 > >then we must map it into a unique urn unless we know that in every=20 > >instance we can differentiate the text calls from voice=20 > calls. I suspect that's hard. > > > >With a SIP URI, you know you can use media negotiation to=20 > get the text=20 > >codec, and if the PSAP accepts the text call, then the=20 > mapper will have=20 > >the same result for sos.police.txt as sos.police. If you=20 > have to map=20 > >instead to some older technology, you have to differentiate=20 > (that is,=20 > >the mapping will be different). >=20 > It does seem possible to define a URI scheme specific to the=20 > text service, so that the mapping protocol can respond with a=20 > URI for that service which is distinguishable from the voice=20 > service. As it stands, we have said that the mapping=20 > protocol should return at most one result per URI scheme, but=20 > if the URI schemes are distinct that's not a problem. >=20 > This also makes it possible to define the text-capable PSAP=20 > mapping independently of the voice-capable PSAP mapping,=20 > which may be valuable if a subset of PSAPs are capable. >=20 > I agree with Henning, though, that this subset case should get rarer. > regards, > Ted >=20 >=20 > >It may be that we make an assumption that the mapping=20 > function does not=20 > >yield a URI if the PSAP doesn't accept a call with a negotiated text=20 > >codec, which would mean we don't need to have sos.police.txt. That=20 > >would force backwards compatibility to existing systems when mapping=20 > >fails. That's not terrible, but I thought it made more sense to let=20 > >mapping yield a URI that resolved to the older technology. > > > >Brian > > > >-----Original Message----- > >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >Sent: Wednesday, February 15, 2006 8:06 PM > >To: Gunnar Hellstrom > >Cc: br@brianrosen.net; ecrit@ietf.org; 'Aquil, Kamran';=20 > 'Fran=E7ois D. M=E9nard' > >; 'Gregg Vanderheiden' > >Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls > > > >I don't think we want a service label for each media type. While > >*today* there are PSAPs that only answer TTY calls, is this=20 > likely to=20 > >make sense in an all-IP PSAP environment where the media would=20 > >terminate on the same PC that's used for IM, video and so=20 > on? Why would=20 > >you do this? > > > >Rather than trying to put SDP in a URN, maybe the better=20 > solution is to=20 > >route to one PSAP for the emergency service and have that PSAP then=20 > >redirect the call based on the full SDP information, if this becomes=20 > >necessary. That way, you can deal with situations where the=20 > caller can=20 > >handle a variety of means of communications, albeit with different=20 > >ease, and the PSAP has access to the full media information. > > > >Since this could be added on later if necessary, once we=20 > know whether=20 > >anybody actually needs this, maybe it's better to avoid gratuitous=20 > >complexity, both in terms of protocol operation, testing=20 > (yet another=20 > >thing a mapping protocol has to test) and user agents. > > > >Henning > > > >On Feb 15, 2006, at 6:52 PM, Gunnar Hellstrom wrote: > > > >> What would sos.police.tty do and how would it be invoked? > >> > >> If it could lead to a text capable IP terminal, it should=20 > be called=20 > >> sos.police.real-time-text or so. > >> > >> If it helps to find a PSTN based PSAP with text capabilities, it=20 > >> could be called sos.police.txp > >> > >> tty is a US term. > >> > >> Gunnar > >> > >>=20 > --------------------------------------------------------------------- > >> - > >> ------- > >> Gunnar Hellstr=F6m, Omnitor > >> gunnar.hellstrom@omnitor.se > >> Mob: +46 708 204 288 > >> Phone: +46 8 556 002 03 > >> www.omnitor.se > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net] > >> Sent: Thursday, February 16, 2006 12:17 AM > >> To: 'Gunnar Hellstrom'; ecrit@ietf.org; 'Aquil, Kamran';=20 > 'Fran=E7ois D.=20 > >> M=E9nard' > >> Cc: 'Gregg Vanderheiden' > >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > > > > >> All I get out of this for ecrit is that we need entries for=20 > >> sos.police.tty in the service registry > >> > >> > >> > >> Brian > >> > >> > >> > >> From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > >> Sent: Wednesday, February 15, 2006 5:47 PM > >> To: ecrit@ietf.org; 'Aquil, Kamran'; br@brianrosen.net;=20 > Fran=E7ois D.=20 > >> M=E9nard > >> Cc: Gregg Vanderheiden > >> Subject: RE: [Ecrit] ECRIT support for TTY/TDD calls > >> > >> > >> > >> It is quite widely accepted now that real-time text=20 > transmitted with=20 > >> its own text coded RTP payload RFC 4103 is used to carry text that=20 > >> may be gatewayed to/from TTY/TDD/textphones in PSTN. > >> > >> > >> > >> It is discussed in http://www.ietf.org/internet-drafts/draft-ietf- > >> sipping-toip-03.txt > >> > >> > >> > >> And it is documented in http://www.ietf.org/internet-drafts/draft- > >> sinnreich-sipdev-req-08.txt > >> > >> > >> > >> Also other standardisation bodies have picked up the=20 > real-time text=20 > >> concept in IP networks, and pointed at RFC 4103 (or its compatible=20 > >> predecessor RFC2793 ). E.g. 3GPP and ETSI. > >> > >> A couple of years ago we had an intensive discussion in the SIMPLE=20 > >> mail list about the possibility to use MSRP to carry the real-time=20 > >> text medium, but we concluded that it would cause too much=20 > overhead=20 > >> or too much delay for the users, so that RTP was=20 > recommended instead.=20 > >> The most common use of MSRP is to not transmit until end=20 > of sentence,=20 > >> while for real time text, transmission is required with at=20 > most 500=20 > >> ms interval as long as there is anything to transmit in order to=20 > >> maintain the real-time feeling of being in touch in a conversation=20 > >> through this medium. > >> > >> > >> > >> Quite commonly you will connect a text RTP stream and an audio RTP=20 > >> stream and possibly a video RTP stream in the same call,=20 > so that you=20 > >> will get an enhanced multimedia phone call with all supported media > >> > >> > >> > >> The ecrit requirements also mentions this correspondence > >> > >> in=20 > www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-03.txt > >> > >> > >> Re4. Multiple Modes: Multiple communication modes,=20 > such as audio, > >> video and text messaging MUST be supported. > >> > >> Motivation: In PSTN, voice and text telephony (often=20 > called TTY=20 > >> or > >> textphone in North America) are the only commonly supported=20 > >> media. > >> Emergency calling must support a variety of media. =20 > Such media > >> should include voice, conversational text (RFC 4103 [9]),=20 > >> instant > >> messaging and video. > >> > >> > >> > >> I am working in a European group where one of the goals is=20 > to agree=20 > >> on handling text users' requirements on emergency calling in IP=20 > >> networks. Of course we want to agree on global solutions=20 > if possible. > >> > >> > >> > >> Address mapping is one important and tricky question for=20 > text users.=20 > >> It is true that different countries have different approaches on=20 > >> emergency calling with PSTN Text telephones (TTYs). > >> Some have the same number as voice users, while others=20 > have specific=20 > >> numbers. On the SIP side it would be good to have the same URL and=20 > >> make any required routing based on declared media, mode=20 > and language=20 > >> capabilities and preferences. > >> > >> > >> > >> Text capable gateways are not at all as common as VoIP=20 > gateways, so=20 > >> if the PSAP is still in PSTN, there is a need to have a good=20 > >> mechanism for routing emergency calls from SIP into PSTN through a=20 > >> text capable gateway. I cannot say that the mechanisms for finding=20 > >> the right gateway and make the proper address mapping to a PSTN=20 > >> number is solved yet for the text calls, and it would be=20 > excellent if=20 > >> we could have that topic in mind in the discussions and get proper=20 > >> methods documented. > >> > >> > >> > >> I have drafted, but not yet submitted a registration of a=20 > SIP URL and=20 > >> an ENUM subservice for real-time text. It might be helpful for=20 > >> finding text gateways and mapping addresses and (text)=20 > numbers, but I=20 > >> would like to see some scenarios thoroughly discussed=20 > before adding=20 > >> SIP URL and another ENUM subservice. > >> > >> > >> > >> Would there be any benefit of being allowed to enter TXP:112 or=20 > >> having ENUM to find an appropriate address if I call 112 from a=20 > >> SIP multimedia phone declaring text capabilities with=20 > m=3Dtext in sdp? > > > > >> > >> > >> > >> > >> Gunnar > >> > >>=20 > --------------------------------------------------------------------- > >> - > >> ------- > >> > >> Gunnar Hellstr=F6m, Omnitor > >> > >> gunnar.hellstrom@omnitor.se > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org]On Behalf=20 > >> Of Fran=E7ois D. M=E9nard > >> Sent: Wednesday, February 15, 2006 5:14 PM > >> To: br@brianrosen.net; 'Aquil, Kamran'; ecrit@ietf.org > >> Subject: Re: [Ecrit] ECRIT support for TTY/TDD calls > >> > >> > >> I made a contribution to CISC NTWG on use of SIP for=20 > transporting TDD=20 > >> traffic: > >> > >> http://www.crtc.gc.ca/cisc/COMMITTE/N-docs/NTCO0338.doc > >> > >> I think it may be relevant to ECRIT. > >> > >> -=3DFrancois=3D- > >> > >> > >> On 2/15/06 10:51 AM, "Brian Rosen" wrote: > >> > >> Within the scope of our work, I don=92t see how TDD services are=20 > >> impacted until we get to the architecture effort, which=20 > probably has=20 > >> to have some sections on that subject. > >> With respect to the mapping protocol, I do not believe=20 > there is any=20 > >> impact at all. > >> With respect to the sos service urn, I do not believe there is any=20 > >> impact at all > >> > >> Ecrit doesn=92t have scope to talk about any kind of=20 > gateways or codec=20 > >> support. > >> > >> Ah! My BCP on phones and proxies may need some mention, although=20 > >> this is the IETF, and I don=92t think the ploy of forcing the = entire=20 > >> PSTN to support TDD just so 9-1-1 TDD will work. That=20 > effort would=20 > >> have to be in the general SIP arena. > >> > >> Brian > >> > >> > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >> Behalf Of Aquil, Kamran > >> Sent: Wednesday, February 15, 2006 10:31 AM > >> To: ecrit@ietf.org > >> Subject: [Ecrit] ECRIT support for TTY/TDD calls > >> > >> > >> Folks, > >> > >> > >> > >> Like to know if there are specific ECRIT requirements recognizing=20 > >> support for Telecommunications Device for the Deaf (TDD)=20 > services for=20 > >> the hearing impaired. If not is this left for VOIP/SIP gateways to=20 > >> perform this requirement of translating the TDD calls to Text and=20 > >> Speech encoding. Wanted to make sure how ECRIT meet=20 > requirement for=20 > >> TDD services. > >> > >> > >> > >> Regards, > >> Kamran Aquil > >> Intelligent Transportation Systems- Division Mitretek Systems. > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >> > >> > >> > >> -- > >> Francois D. Menard > >> fmenard@xittelecom.com > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 17 17:28:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAE5N-0006uf-GW; Fri, 17 Feb 2006 17:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAE5L-0006uG-Uy for ecrit@megatron.ietf.org; Fri, 17 Feb 2006 17:28:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19915 for ; Fri, 17 Feb 2006 17:26:30 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAEJr-0006Na-Qc for ecrit@ietf.org; Fri, 17 Feb 2006 17:43:20 -0500 Received: from lion.cs.columbia.edu (IDENT:aSimHk/rcazk/Dm0FiI3AR95tXl2WvIl@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k1HMSGVu028732 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 17 Feb 2006 17:28:16 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k1HMSFnE018695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 17 Feb 2006 17:28:16 -0500 Message-ID: <43F64DFB.9030106@cs.columbia.edu> Date: Fri, 17 Feb 2006 17:28:11 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ecrit@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LEO_OBFU_DATE_0500 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Ecrit] Re: I-D ACTION:draft-ietf-ecrit-service-urn-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The new working group draft is now available. It incorporates suggestions made by the URN mailing list and other reviewers. I believe that the draft is essentially done, except for deciding whether to use this draft to formally register the sos service types with IANA. I would appreciate feedback on the draft, but I don't foresee that having it sit around for a few more IETF meetings is going to substantially improve the draft. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. > > Title : A Uniform Resource Name (URN) for Services > > Author(s) : H. Schulzrinne > Filename : draft-ietf-ecrit-service-urn-00.txt > Pages : 10 > Date : 2006-2-17 > > The content of many communication services depend on the context, > such as the user's location. We describe a 'service' URN that allows > to register such context-dependent services that can be resolved in a > distributed manner. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-00.txt > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 17 18:01:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAEb0-0002ch-JC; Fri, 17 Feb 2006 18:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAEaz-0002cc-7V for ecrit@megatron.ietf.org; Fri, 17 Feb 2006 18:01:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22086 for ; Fri, 17 Feb 2006 17:59:11 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAEpU-0007fG-Cx for ecrit@ietf.org; Fri, 17 Feb 2006 18:16:01 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2006 15:00:51 -0800 X-IronPort-AV: i="4.02,124,1139212800"; d="scan'208"; a="406801273:sNHT33266176" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1HN0ZSf023158; Fri, 17 Feb 2006 15:00:49 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 15:00:46 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.83.168]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 15:00:45 -0800 Message-Id: <4.3.2.7.2.20060217165554.02753990@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Feb 2006 17:00:44 -0600 To: Henning Schulzrinne , ecrit@ietf.org From: "James M. Polk" Subject: Re: [Ecrit] Re: I-D ACTION:draft-ietf-ecrit-service-urn-00.txt In-Reply-To: <43F64DFB.9030106@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Feb 2006 23:00:46.0023 (UTC) FILETIME=[FC676570:01C63415] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This ID should formally register the service types. It appears to be a concrete way of putting a stake in the ground on this issue that everyone can point at. Otherwise, other SDOs can say "no one has reeeally made a decision yet, have they?" I've already heard this, so this isn't a prediction. ...and what's the harm in waiting around a few more meetings to see if any progress can be made in the text... ;-) At 05:28 PM 2/17/2006 -0500, Henning Schulzrinne wrote: >The new working group draft is now available. It incorporates suggestions >made by the URN mailing list and other reviewers. I believe that the draft >is essentially done, except for deciding whether to use this draft to >formally register the sos service types with IANA. I would appreciate >feedback on the draft, but I don't foresee that having it sit around for a >few more IETF meetings is going to substantially improve the draft. > >Internet-Drafts@ietf.org wrote: >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the Emergency Context Resolution with >>Internet Technologies Working Group of the IETF. >> Title : A Uniform Resource Name (URN) for Services >> Author(s) : H. Schulzrinne >> Filename : draft-ietf-ecrit-service-urn-00.txt >> Pages : 10 >> Date : 2006-2-17 >> >>The content of many communication services depend on the context, >>such as the user's location. We describe a 'service' URN that allows >>to register such context-dependent services that can be resolved in a >>distributed manner. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-00.txt > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 17 20:39:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAH4V-0006tr-0m; Fri, 17 Feb 2006 20:39:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAH4T-0006tM-6u for ecrit@megatron.ietf.org; Fri, 17 Feb 2006 20:39:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09894 for ; Fri, 17 Feb 2006 20:37:48 -0500 (EST) Received: from mta1.prod1.dngr.net ([216.220.209.220] helo=mfe1.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAHIw-0008C3-PT for ecrit@ietf.org; Fri, 17 Feb 2006 20:54:39 -0500 Received: from [10.253.1.252] (HELO localhost.localdomain) by mfe1.prod.danger.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 547878720; Fri, 17 Feb 2006 17:39:23 -0800 Date: Fri, 17 Feb 2006 20:39:13 -0500 Subject: Re: [Ecrit] Re: I-D ACTION:draft-ietf-ecrit-service-urn-00.txt X-Mailer: Danger Service X-Danger-Send-Id: AAAm9UP2essAAYbC Content-Transfer-Encoding: 7bit In-Reply-To: <4.3.2.7.2.20060217165554.02753990@email.cisco.com> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: "James M. Polk" , Henning Schulzrinne , ecrit@ietf.org Mime-Version: 1.0 References: <4.3.2.7.2.20060217165554.02753990@email.cisco.com> From: Brian Rosen Message-Id: <1140226763.DC58041@fd4.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree. Put the service registration in this draft and last call it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 17 21:52:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAICl-0007Aj-90; Fri, 17 Feb 2006 21:52:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAICk-0007AF-65 for ecrit@megatron.ietf.org; Fri, 17 Feb 2006 21:52:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14087 for ; Fri, 17 Feb 2006 21:50:25 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAIRI-0002I6-Cn for ecrit@ietf.org; Fri, 17 Feb 2006 22:07:16 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1I2qAv3007661 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 17 Feb 2006 21:52:11 -0500 (EST) In-Reply-To: <1140226763.DC58041@fd4.dngr.org> References: <4.3.2.7.2.20060217165554.02753990@email.cisco.com> <1140226763.DC58041@fd4.dngr.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61022EBE-B0D3-4AD9-85E4-4B508F5AD084@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: I-D ACTION:draft-ietf-ecrit-service-urn-00.txt Date: Fri, 17 Feb 2006 21:52:10 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- urn-01.html has my initial attempt at a list. Please let me know if I missed any or if you have suggestions for better definitions of the services listed. On Feb 17, 2006, at 8:39 PM, Brian Rosen wrote: > I agree. Put the service registration in this draft and last call it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 18 12:06:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVXm-0003Jy-Sv; Sat, 18 Feb 2006 12:06:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzw-0002AL-Oq for ecrit@ietf.org; Sat, 18 Feb 2006 11:31:52 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAUY9-0002Vo-9V for ecrit@ietf.org; Sat, 18 Feb 2006 11:03:09 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FATST-0000gK-Rs for ecrit@ietf.org; Sat, 18 Feb 2006 09:53:15 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k1IEqlUD019821; Sat, 18 Feb 2006 15:52:47 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k1IEqks8000529; Sat, 18 Feb 2006 15:52:47 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Feb 2006 15:52:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Re: I-D ACTION:draft-ietf-ecrit-service-urn-00.txt Date: Sat, 18 Feb 2006 15:52:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: I-D ACTION:draft-ietf-ecrit-service-urn-00.txt thread-index: AcY0Nnt5rmMbuT1nQBmCWFwahfQzgwAYhJZA From: "Tschofenig, Hannes" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 18 Feb 2006 14:52:46.0968 (UTC) FILETIME=[FB23E780:01C6349A] X-Spam-Score: -2.3 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org hi henning, hi all,=20 i looked at the draft and i think it is ok.=20 the list of sos service types was discussed on the list / in meetings.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von Henning Schulzrinne > Gesendet: Samstag, 18. Februar 2006 03:52 > An: Brian Rosen > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] Re: I-D=20 > ACTION:draft-ietf-ecrit-service-urn-00.txt >=20 > http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit- > service-=20 > urn-01.html has my initial attempt at a list. Please let me=20 > know if I =20 > missed any or if you have suggestions for better definitions of the =20 > services listed. >=20 > On Feb 17, 2006, at 8:39 PM, Brian Rosen wrote: >=20 > > I agree. Put the service registration in this draft and=20 > last call it. >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Feb 18 12:08:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVZ8-0004DW-5i; Sat, 18 Feb 2006 12:08:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzx-0002BM-1O for ecrit@ietf.org; Sat, 18 Feb 2006 11:31:53 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAUYS-0002Vo-Cj for ecrit@ietf.org; Sat, 18 Feb 2006 11:03:28 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FASbg-0000AL-Ma for ecrit@ietf.org; Sat, 18 Feb 2006 08:58:43 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k1IDwOHP030143; Sat, 18 Feb 2006 14:58:25 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k1IDwO95008380; Sat, 18 Feb 2006 14:58:24 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Feb 2006 14:58:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Re: I-D ACTION:draft-ietf-ecrit-service-urn-00.txt Date: Sat, 18 Feb 2006 14:57:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: I-D ACTION:draft-ietf-ecrit-service-urn-00.txt thread-index: AcY0Nnt5rmMbuT1nQBmCWFwahfQzgwAXK+bg From: "Tschofenig, Hannes" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 18 Feb 2006 13:58:10.0351 (UTC) FILETIME=[5A1FD3F0:01C63493] X-Spam-Score: -2.0 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org here is the diff: http://www.ietf-ecrit.org/TEMP/Diff.htm =20 > -----Urspr=FCngliche Nachricht----- > Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > Im Auftrag von Henning Schulzrinne > Gesendet: Samstag, 18. Februar 2006 03:52 > An: Brian Rosen > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] Re: I-D=20 > ACTION:draft-ietf-ecrit-service-urn-00.txt >=20 > http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit- > service-=20 > urn-01.html has my initial attempt at a list. Please let me=20 > know if I =20 > missed any or if you have suggestions for better definitions of the =20 > services listed. >=20 > On Feb 17, 2006, at 8:39 PM, Brian Rosen wrote: >=20 > > I agree. Put the service registration in this draft and=20 > last call it. >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 19 02:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAjQy-0005wf-1s; Sun, 19 Feb 2006 02:56:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAjQx-0005wM-7l for ecrit@ietf.org; Sun, 19 Feb 2006 02:56:43 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAjQt-0001KD-NE for ecrit@ietf.org; Sun, 19 Feb 2006 02:56:43 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k1J7ucfj027876 for ; Sun, 19 Feb 2006 08:56:38 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k1J7ucHl010358 for ; Sun, 19 Feb 2006 08:56:38 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Feb 2006 08:56:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 19 Feb 2006 08:54:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT session at IETF#65 thread-index: AcY1Kbz+90kTjyL/Sn2wcPCmT5R4OA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Feb 2006 07:56:37.0865 (UTC) FILETIME=[02CEE590:01C6352A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ecrit] ECRIT session at IETF#65 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0505402981==" Errors-To: ecrit-bounces@ietf.org --===============0505402981== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 aGkgYWxsLCANCg0KeW91IG1pZ2h0IGhhdmUgc2VlbiB0aGF0IHRoZSBhZ2VuZGEgZm9yIHRoZSBu ZXh0IG1lZXRpbmcgd2FzIHBvc3RlZC4gSGVyZSBpcyBvdXIgc2xvdDoNCg0KVFVFU0RBWSwgTWFy Y2ggMjEsIDIwMDYNCjA4MDAtMTgwMCBJRVRGIFJlZ2lzdHJhdGlvbiAtIA0KMDgwMC0wOTAwIENv bnRpbmVudGFsIEJyZWFrZmFzdCAtIA0KMDkwMC0xMTMwIE1vcm5pbmcgU2Vzc2lvbiBJIMOi4oKs 4oCcIDIuNSBob3VyDQpBUFAJZWFpCUVtYWlsIEFkZHJlc3MgSW50ZXJuYXRpb25hbGl6YXRpb24g Qk9GDQpJTlQJbmV0bG1tCU5ldHdvcmstYmFzZWQgTG9jYWxpemVkIE1vYmlsaXR5IE1hbmFnZW1l bnQgV0cNCklOVAl0cmlsbAlUcmFuc3BhcmVudCBJbnRlcmNvbm5lY3Rpb24gb2YgTG90cyBvZiBM aW5rcyBXRw0KT1BTCWFkc2xtaWIJQURTTCBNSUIgV0cNCk9QUwlyYWRleHQJUkFESVVTIEV4dGVu c2lvbnMgV0cNClJBSQlhdnQJQXVkaW8vVmlkZW8gVHJhbnNwb3J0IFdHDQpSQUkJZWNyaXQJRW1l cmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hub2xvZ2llcyBXRw0K UlRHCWZvcmNlcwlGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiBXRw0K DQooTm90ZSB0aGF0IGl0IG1pZ2h0IGNoYW5nZSBhZ2Fpbi4pDQoNCkNpYW8NCkhhbm5lcw0K --===============0505402981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0505402981==-- From ecrit-bounces@ietf.org Sun Feb 19 07:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAnuX-0006QR-UR; Sun, 19 Feb 2006 07:43:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAnuW-0006QM-84 for ecrit@ietf.org; Sun, 19 Feb 2006 07:43:32 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAnuS-0002ba-Pq for ecrit@ietf.org; Sun, 19 Feb 2006 07:43:32 -0500 Received: (qmail invoked by alias); 19 Feb 2006 12:43:26 -0000 Received: from ip-80-226-150-90.vodafone-net.de (EHLO [10.227.222.205]) [80.226.150.90] by mail.gmx.net (mp029) with SMTP; 19 Feb 2006 13:43:26 +0100 X-Authenticated: #29516787 Message-ID: <43F867E2.1020005@gmx.net> Date: Sun, 19 Feb 2006 13:43:14 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Tom, Hi All, I went through the recently submitted ECRIT security threats draft (see draft-taylor-ecrit-security-threats-02.txt). My impression is that the document is more focused than the previous versions. Good job, Tom! Here are some minor review comments: http://www.ietf-ecrit.org/TEMP/draft-taylor-ecrit-security-threats-02_hannes.txt The challenge in the near future will be to capture security threats and security requirements that show up in the context of the work on the mapping protocol. Request to all: Please review the document and submit you comments. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 19 14:41:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAuQr-0006rq-Bf; Sun, 19 Feb 2006 14:41:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAuAF-0006KV-L2 for ecrit@ietf.org; Sun, 19 Feb 2006 14:24:11 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAu0G-0002KB-Lc for ecrit@ietf.org; Sun, 19 Feb 2006 14:13:54 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k1JJDe2O025068; Sun, 19 Feb 2006 20:13:40 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k1JJDeXY021891; Sun, 19 Feb 2006 20:13:40 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Feb 2006 20:13:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Feb 2006 20:13:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIPPING-SOS thread-index: AcY1h68coP5U1X0CTXChUAxcYi4ojQ== From: "Tschofenig, Hannes" To: , , X-OriginalArrivalTime: 19 Feb 2006 19:13:39.0798 (UTC) FILETIME=[975DF760:01C63588] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ecrit@ietf.org Subject: [Ecrit] SIPPING-SOS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Gonzalo,=20 Hi Dean,=20 Hi Rohan,=20 please remove the draft 'Emergency Services URI for the Session Initiation Protocol' http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-02.txt (SIPPING-SOS) from your SIPPING charter page.=20 During the ECRIT interim meeting (and also later on the mailing list) ECRIT members concluded that we want to go for=20 A Uniform Resource Name (URN) for Services http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-00.txt=20 The work on SIPPING-SOS will be stopped.=20 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 19 18:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAy4s-0004yv-Jr; Sun, 19 Feb 2006 18:34:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAy4s-0004yp-8H for ecrit@ietf.org; Sun, 19 Feb 2006 18:34:54 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAy4p-0001Es-Pg for ecrit@ietf.org; Sun, 19 Feb 2006 18:34:54 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k1JNUg211218; Sun, 19 Feb 2006 18:30:42 -0500 (EST) Received: from [127.0.0.1] ([47.130.16.23] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Feb 2006 18:34:44 -0500 Message-ID: <43F9008D.2000205@nortel.com> Date: Sun, 19 Feb 2006 18:34:37 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt References: <43F867E2.1020005@gmx.net> In-Reply-To: <43F867E2.1020005@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Feb 2006 23:34:44.0562 (UTC) FILETIME=[104B4320:01C635AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks for the comments. In most cases I will reword to clarify. Details to follow in another E-mail. I worded a number of the requirements carefully to say that "The protocol must permit ..." or "The protocol must not prevent ...". This was to meet the criticism that the proposed measures were too expensive in the real world. Your suggested rewording sometimes seems to restore mandatory implementation. Perhaps we need a discussion on whether we want security measures to be mandatory to deploy (most stringent), mandatory to implement, or simply possible to implement and deploy. Or has this issue already been settled? Hannes Tschofenig wrote: > Hi Tom, > Hi All, > > I went through the recently submitted ECRIT security threats draft (see > draft-taylor-ecrit-security-threats-02.txt). > > My impression is that the document is more focused than the previous > versions. Good job, Tom! > > Here are some minor review comments: > http://www.ietf-ecrit.org/TEMP/draft-taylor-ecrit-security-threats-02_hannes.txt > > > The challenge in the near future will be to capture security threats and > security requirements that show up in the context of the work on the > mapping protocol. > > Request to all: Please review the document and submit you comments. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 19 19:29:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAyw5-0007R4-3p; Sun, 19 Feb 2006 19:29:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAyw4-0007Qz-AK for ecrit@ietf.org; Sun, 19 Feb 2006 19:29:52 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAyw2-0002eV-Q6 for ecrit@ietf.org; Sun, 19 Feb 2006 19:29:52 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k1K0TnIl016946; Mon, 20 Feb 2006 01:29:49 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k1K0TkK4019580; Mon, 20 Feb 2006 01:29:48 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 01:29:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt Date: Mon, 20 Feb 2006 01:29:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt thread-index: AcY1rSVS2RQ7ueNvTn2qGBcOR00jkAAAx+Gg From: "Tschofenig, Hannes" To: "Tom-PT Taylor" , "Hannes Tschofenig" X-OriginalArrivalTime: 20 Feb 2006 00:29:46.0583 (UTC) FILETIME=[C073AE70:01C635B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org hi tom,=20 my intention was only to provide a little bit more text within the = requirements section.=20 in the requirements document roger is currently trying to add a little = more text about mandatory to implement vs. mandatory to use. i think we = should do the same in the security requirements document.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Tom-PT Taylor [mailto:taylor@nortel.com]=20 > Gesendet: Montag, 20. Februar 2006 00:35 > An: Hannes Tschofenig > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] Review of=20 > draft-taylor-ecrit-security-threats-02.txt >=20 > Thanks for the comments. In most cases I will reword to=20 > clarify. Details=20 > to follow in another E-mail. >=20 > I worded a number of the requirements carefully to say that "The=20 > protocol must permit ..." or "The protocol must not prevent=20 > ...". This=20 > was to meet the criticism that the proposed measures were too=20 > expensive=20 > in the real world. Your suggested rewording sometimes seems=20 > to restore=20 > mandatory implementation. Perhaps we need a discussion on whether we=20 > want security measures to be mandatory to deploy (most stringent),=20 > mandatory to implement, or simply possible to implement and=20 > deploy. Or=20 > has this issue already been settled? >=20 > Hannes Tschofenig wrote: > > Hi Tom, > > Hi All, > >=20 > > I went through the recently submitted ECRIT security=20 > threats draft (see=20 > > draft-taylor-ecrit-security-threats-02.txt). > >=20 > > My impression is that the document is more focused than the=20 > previous=20 > > versions. Good job, Tom! > >=20 > > Here are some minor review comments: > >=20 > http://www.ietf-ecrit.org/TEMP/draft-taylor-ecrit-security-thr > eats-02_hannes.txt=20 > >=20 > >=20 > > The challenge in the near future will be to capture=20 > security threats and=20 > > security requirements that show up in the context of the=20 > work on the=20 > > mapping protocol. > >=20 > > Request to all: Please review the document and submit you comments. > >=20 > > Ciao > > Hannes > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Feb 19 19:52:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAzHk-00007j-5f; Sun, 19 Feb 2006 19:52:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAzHi-00007b-Cn for ecrit@ietf.org; Sun, 19 Feb 2006 19:52:14 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAzHf-0002yx-Uy for ecrit@ietf.org; Sun, 19 Feb 2006 19:52:14 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k1K0m6d15541; Sun, 19 Feb 2006 19:48:06 -0500 (EST) Received: from [127.0.0.1] ([47.130.16.23] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Feb 2006 19:52:08 -0500 Message-ID: <43F912B1.8020204@nortel.com> Date: Sun, 19 Feb 2006 19:52:01 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt References: <43F867E2.1020005@gmx.net> In-Reply-To: <43F867E2.1020005@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2006 00:52:08.0673 (UTC) FILETIME=[E0665D10:01C635B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Here are my detailed responses. Comment: section 1, first sentence, delete "unique". Response: OK. Comment: section 5.1, end of third para, what is meant by "installing filters"? Response: What I meant by this was to say "intercept and discard mapping queries relating to the target at a router on the query-response path or at the mapping server". Because this is rather longer than the original, I'll rework the sentence structure to handle it. Comment: same section, immediately following sentence talking about man-in-the-middle attacks, what is meant by "taking control of the channel"? Response: I meant "taking control of a router in the query-response path", and I'll say that instead. And BTW, I'm told that taking control of routers is indeed a credible threat. Comment: end of section 5.1, after mention of impersonation of the mapping server, a suggestion that we should also talk about attacks on the process of mapping server discovery. Response: OK, though this gets close to the configuration issues I had to get rid of because they were out of scope. Comment: more detailed and precise wording for bullet c. of section 5.3. Response: Looks good -- I'll take it. Comment: bullet d., section 5.3, wondering if we should add a remark to the effect that one cannot tell from the URI itself whther it points to a PSAP. Response: OK, that's the point -- just wonder if it's too obvious. Comment: last para of section 5.3 -- described attack by caller is way too elaborate -- he just has to hack his device to mark an ordinary call as an emergency, rather than substitute for the result of mapping. Response: agreed, will change accordingly. The attack on the mapping database is a separate one and will remain, though it is probably a bit far-fetched. Comment: beginning of section 6, wording changes. Response: OK. Comment: section 6, spell out man-in-the-middle threat. Response: This is the requirements section. I suggest spelling out of attacks belongs in section 5.1. I'd like to make the requirements stand out clearly by having most of the words in section 6 deal with them rather than the attacks to which they respond. BTW I see "returning no results" as denial of service, whereas "returning incorrect results" is the MITM attack. If this seems overly picky, I'll reclassify the attacks by what they attack (caller's device, router, mapping server + impersonation as a separate category) instead. Comment: section 6, requirements in response to man-in-the-middle threat. Proposed alternative wording. Response: Your wording introduces the issue I mentioned in my previous E-mail: do we require implementation or only make it possible to implement? Comment: section 6, different words for the impersonation threat, and for the response to it. Response: again, I'd propose that expanded descriptions of attacks belong in section 5. And your requirement wording appears to go beyond requirements by becoming a discussion of ways and means. Comment: section 6, confidentiality. Alternative wording. Response: short rewording OK. Longer wording of threat belongs in section 5. Comment: section 6, fraudulent calls, remark that reverse lookup is an unnecessary requirement. Response: You're half right -- it is mostly an optimization. But then you're assuming that the VSP/ASP proxy is capable of reading the location from the INVITE so it can redo the lookup. Is this sufficiently problematic that we need the reverse lookup anyway? Hannes Tschofenig wrote: > Hi Tom, > Hi All, > > I went through the recently submitted ECRIT security threats draft (see > draft-taylor-ecrit-security-threats-02.txt). > > My impression is that the document is more focused than the previous > versions. Good job, Tom! > > Here are some minor review comments: > http://www.ietf-ecrit.org/TEMP/draft-taylor-ecrit-security-threats-02_hannes.txt > > > The challenge in the near future will be to capture security threats and > security requirements that show up in the context of the work on the > mapping protocol. > > Request to all: Please review the document and submit you comments. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 20 09:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBCTB-00044B-1W; Mon, 20 Feb 2006 09:56:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBCT9-000446-Ex for ecrit@ietf.org; Mon, 20 Feb 2006 09:56:55 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBCT7-0001DZ-6S for ecrit@ietf.org; Mon, 20 Feb 2006 09:56:55 -0500 Received: (qmail invoked by alias); 20 Feb 2006 14:56:51 -0000 Received: from ip-80-226-194-224.vodafone-net.de (EHLO [10.226.212.99]) [80.226.194.224] by mail.gmx.net (mp037) with SMTP; 20 Feb 2006 15:56:51 +0100 X-Authenticated: #29516787 Message-ID: <43F9CA96.5010505@gmx.net> Date: Mon, 20 Feb 2006 14:56:38 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] New Draft: ECRIT Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Roger submitted an updated draft version as discussed during the interim meeting. Here is the draft: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-04.txt Thanks Roger! Important: PLEASE read the document as soon as possible. We want to start WGLC as soon as possible. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 20 20:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMDF-0002Hv-LT; Mon, 20 Feb 2006 20:21:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMDE-0002Hp-BQ for ecrit@ietf.org; Mon, 20 Feb 2006 20:21:08 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBMDB-0004g0-TB for ecrit@ietf.org; Mon, 20 Feb 2006 20:21:08 -0500 Received: (qmail invoked by alias); 21 Feb 2006 01:21:03 -0000 Received: from ip-80-226-155-30.vodafone-net.de (EHLO [10.227.221.132]) [80.226.155.30] by mail.gmx.net (mp038) with SMTP; 21 Feb 2006 02:21:03 +0100 X-Authenticated: #29516787 Message-ID: <43FA5CDB.1060102@gmx.net> Date: Tue, 21 Feb 2006 01:20:43 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Subject: Re: [Ecrit] New Draft: ECRIT Requirements References: <43F9CA96.5010505@gmx.net> In-Reply-To: <43F9CA96.5010505@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org hi all, it might be more convenient to take a look at the diff version: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-03.txt&url2=http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-04.txt ciao hannes Hannes Tschofenig wrote: > Hi all, > > Roger submitted an updated draft version as discussed during the interim > meeting. Here is the draft: > http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-04.txt > > Thanks Roger! > > Important: > > PLEASE read the document as soon as possible. We want to start WGLC as > soon as possible. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 22 18:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3AA-0006kB-LA; Wed, 22 Feb 2006 18:12:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3A9-0006k6-Sl for ecrit@ietf.org; Wed, 22 Feb 2006 18:12:49 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3A8-00010J-Er for ecrit@ietf.org; Wed, 22 Feb 2006 18:12:49 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 22 Feb 2006 15:12:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] New Draft: ECRIT Requirements - Clarification Date: Wed, 22 Feb 2006 15:12:41 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657504502E76@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New Draft: ECRIT Requirements - Clarification Thread-Index: AcY2hTau6iJCYDPdSGi9T/iy2KxW6ABfu8BA From: "Roger Marshall" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: marc.linsner@cisco.com X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Clarification on -04 version of ECRIT requirements draft: Note that requirements, Id2, Ma7, and Ma8 are somewhat duplicated in text. Of each of these three sets of identically named requirements, only the second in each set are those that are intended to be kept. These (keepers) are restated here for reference: Id2. Universal Identifier Resolution: Where multiple=20 emergency service types exist, the mapping protocol MUST support=20 the individual treatment of each emergency identifier used, based on=20 the specific type of emergency help requested. Ma7. Multiple PSAP URIs: The mapping protocol MUST=20 support (i.e. implement, though not necessarily use), a method to be=20 able to return multiple URIs for different PSAPs that cover the same=20 area. Ma8. URL properties: The mapping protocol MUST=20 support (i.e. implement, thought not necessarily use), the ability to=20 provide additional information that allows the querying entity to=20 determine relevant properties of the URL. Regards, Roger Marshall. =20 >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Monday, February 20, 2006 4:21 PM >To: ecrit@ietf.org >Subject: Re: [Ecrit] New Draft: ECRIT Requirements > >hi all, > >it might be more convenient to take a look at the diff version: > >http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://ww >w.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-03.txt&url >2=3Dhttp://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-04.txt= > >ciao >hannes > >Hannes Tschofenig wrote: >> Hi all, >>=20 >> Roger submitted an updated draft version as discussed during the=20 >> interim meeting. Here is the draft: >> http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-04.txt >>=20 >> Thanks Roger! >>=20 >> Important: >>=20 >> PLEASE read the document as soon as possible. We want to=20 >start WGLC as=20 >> soon as possible. >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 23 08:22:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGQb-0004IN-3N; Thu, 23 Feb 2006 08:22:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBG0Z-00026V-87 for ecrit@ietf.org; Mon, 20 Feb 2006 13:43:39 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBG0Y-0000k3-1U for ecrit@ietf.org; Mon, 20 Feb 2006 13:43:39 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Feb 2006 10:43:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,131,1139212800"; d="scan'208"; a="22270369:sNHT5100594470" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1KIhULN004826 for ; Mon, 20 Feb 2006 13:43:30 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 13:43:17 -0500 Received: from [10.86.242.93] ([10.86.242.93]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 13:43:15 -0500 Message-ID: <43FA0DC2.5050705@cisco.com> Date: Mon, 20 Feb 2006 13:43:14 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ecrit@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2006 18:43:15.0940 (UTC) FILETIME=[82AD1240:01C6364D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Thu, 23 Feb 2006 08:22:39 -0500 Subject: [Ecrit] Re: draft-ietf-ecrit-service-urn-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Syntax has some problems: "URN:service:" top-level-service *("." service-identifier) top-level-service = ALPHA / DIGIT / "-" / service-identifier = ALPHA / DIGIT / "-" / This only allows service identifiers to be one character each. Also, 'service-identifier' is defined here, but 'sub-service' is defined in the text. And the top-level-service and the sub-service are syntactically identical, so there is no need to repeat that. I would suggest: "URN:service:" top-level-service *("." sub-service) top-level-service = service-identifier sub-service = service-identifier service-identifier = 1*(ALPHA / DIGIT / "-") Paul _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 23 08:22:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGQb-0004JJ-9p; Thu, 23 Feb 2006 08:22:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0vz-00052D-J4; Wed, 22 Feb 2006 15:50:03 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0vy-00070j-L5; Wed, 22 Feb 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1MKo2vP004497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FC0vy-0004Qt-2L; Wed, 22 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Feb 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Thu, 23 Feb 2006 08:22:39 -0500 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-04.txt Pages : 30 Date : 2006-2-22 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-requirements-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-requirements-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-22130947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-22130947.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Thu Feb 23 13:33:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLHP-000844-2d; Thu, 23 Feb 2006 13:33:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLHN-00082L-Qu for ecrit@ietf.org; Thu, 23 Feb 2006 13:33:29 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLHM-0007zs-7X for ecrit@ietf.org; Thu, 23 Feb 2006 13:33:29 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 23 Feb 2006 10:33:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Wireline vs wireless routing Date: Thu, 23 Feb 2006 10:33:22 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A6575045032AC@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Wireline vs wireless routing Thread-Index: AcYoQxHn7P0NCc+ZRSOtRndhp6Jy9wAAG4tQAAL3SEAAAQiUcAADPiEgABtqf6AD9Nz3QA== From: "Roger Marshall" To: "Abbott, Nadine B" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Nadine: Id2 - Yes, agree with the change. Updated text as follows: "Id2. Universal Identifier Resolution: Where multiple=20 emergency service types exist, the mapping protocol MUST support=20 (i.e. implement, though not necessarily use) the individual treatment of each emergency identifier used, based on the specific type of=20 emergency help requested." Ma8 - Fixed spelling problem, thx. =20 Ma8 - As to relevant properties, my take is that this would be a (visible) differentiation between a URI associated with a sub-jurisdiction vs. a URI pointing to a larger encompassing jurisdiction. An example might be, a 9-1-1 call made from the University of Washington campus verses a 9-1-1 call initiated off-campus, but still in Seattle. Let's say, that a rule exists (for a UA, ESRP, etc.), that based on the caller's on-campus location, service URN, and subsequent returned URI, a 9-1-1 call would be routed to the UW call center, whereas if the call was initiated from a location just off-campus, it would route to the Seattle PSAP. What this requirement says (to me), is that protocol supports the return of both URIs (e.g. sip:911@psap.u.washington.edu and sip:911@psap.seattle.wa.gov) together so that the routing decision can be made. -Roger Marshall >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Abbott, Nadine B >Sent: Friday, February 03, 2006 6:29 AM >To: ECRIT >Subject: FW: [Ecrit] Wireline vs wireless routing > >Some clarifications > >-----Original Message----- >From: RGojo@iXPCorp.com [mailto:RGojo@iXPCorp.com] >Sent: Thursday, February 02, 2006 8:44 PM >To: Abbott, Nadine B; dmarnold@verizon.net; Winterbottom,=20 >James; Brian Rosen >Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R (AIT) >Subject: RE: [Ecrit] Wireline vs wireless routing > >This is just an "application of terminology" problem. > >Its not that PSAP routing is intentionally different for=20 >wireline vs wireless, it has to do with how granular you can=20 >get in your routing decisions. The PSAP that dispatches=20 >emergency services is the same for both callers, but the PSAP=20 >that gets the call initially may be different. > >NJ is a good example of how this plays out. NJ has 230 PSAPs=20 >covering the 21 counties. Many PSAPs serve a single=20 >municipality and several counties in NJ have more than 20=20 >PSAPs with no county-level PSAP. Let's say I place a cell=20 >tower on the roof of 4 Skiles Ave in Piscataway. The street=20 >address for that tower is 4 Skiles Ave which, according to the=20 >MSAG, would be routed to the Piscataway PD PSAP.=20 >Unfortunately, the cell tower, with a 5 mile serving radius,=20 >serves callers in 4 or 5 neighboring towns as well as Piscataway. > >I need to route calls from this cell to a County or State=20 >Police PSAP that is set up to answer from a wider area. To do=20 >that, we created the State of XX in the MSAG, so that 4 Skiles=20 >Ave, Piscataway, XX could be assigned a different ESN and be=20 >routed to a different PSAP. > >If the caller turns out to be in Piscataway, the call is=20 >transferred from the County/State PSAP to Piscataway PD for=20 >dispatching. The point is that the wireless caller may be=20 >routed to a different PSAP out of necessity, but the call will=20 >ultimately end up at the PSAP serving the caller's location. > >Why not route the call based on the caller's actual location?=20 >Because, generally speaking, the location data is not derived=20 >or delivered fast enough to be usable for routing. We'd have=20 >to place the caller in queue and play cheesy elevator music=20 >until the location could be derived, delivered and translated=20 >to an ESN. That probably wouldn't be popular. >Wireless callers already have to wait longer to reach 9-1-1=20 >than wireline callers simply because wireless calls take=20 >longer to set up, particularly if RF channels are not=20 >immediately available. Over time, as the technology matures,=20 >routing on location will become the norm and the need to route=20 >differently will go away. > >I hope no one considers this type of routing a viable option for VoIP. >We did it for wireless because we had to, not because we wanted to. > >Gojo > >Robert K. Gojanovich, ENP >Director >iXP Corporation >609-406-7625 Direct Dial >215-435-0703 Mobile >609-406-7699 Fax >rgojo@ixpcorp.com >www.ixpcorp.com >iXP Corporation... Problem Solved > >-----Original Message----- >From: Abbott, Nadine B [mailto:nabbott@telcordia.com] >Sent: Thursday, February 02, 2006 7:31 PM >To: dmarnold@verizon.net; Winterbottom, James; Brian Rosen >Cc: ric@tc911.org; tom.breen@bellsouth.com; STOFFELS, PAUL R=20 >(AIT); Gojanovich, Robert >Subject: RE: [Ecrit] Wireline vs wireless routing > >Brian, > >Perhaps you can clarify with some examples of what you mean=20 >about different routing of wireline and wireless callers? =20 >I've never heard before that for the very same location,=20 >emergency calls routed to a given PSAP would be dispatched=20 >differently, with different emergency responders for wireline=20 >and wireless.=20 > >However, I have heard of examples of different routing to=20 >different answering points/PSAPs for wireless calls based on=20 >access type and location, like the following. >In California, wireless calls used to be routed to the Highway=20 >Patrol, but this began phasing out several years ago. =20 >Likewise, in other states, like NJ, wireless calls were routed=20 >to a central PSAP because of the high volumes and the need to=20 >handle the traffic slightly differently, at least partly=20 >because of location-related concerns. But I believe that these=20 >kind of arrangements are being phased out as most areas are at=20 >least moving toward implementation of Wireless Phase I and=20 >Phase II, and are enabling wireless calls to be appropriately=20 >routed to a PSAP based on location. However, wireless calls=20 >may be routed based on primary PSAP serving area, because the=20 >granularity (down to information that identifies the=20 >appropriate emergency resources to be dispatched, i.e., ESZ)=20 >may not be available for wireless p-ANIs. =20 > =20 >As Delaine mentions, there are sometimes different trunk=20 >groups to the PSAP also for wireline and wireless, but I think=20 >that this is to help the PSAP ensure that volumes and bursts=20 >of calls from mobiles won't swamp out emergency service to=20 >wireline callers, not because they were routed differently? > =20 >Nadine > >P.S. I added Ric Atkins, Tom Breen, Bob Gojanovich, and Paul=20 >Stoffels to this thread because they have a wealth of=20 >experience to add to this discussion, I expect.=20 >=20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Delaine M Arnold ENP >Sent: Thursday, February 02, 2006 6:28 PM >To: 'Winterbottom, James'; 'Brian Rosen'; ecrit@ietf.org >Subject: RE: [Ecrit] Wireline vs wireless routing > >I've heard some numbers from various PSAPs indicating their=20 >wireless call volume continues to increase and is more than=20 >their wireline volume. I've heard 45-50% wireless in some=20 >areas. Many PSAPs have separate trunks for wireline and=20 >wireless. This is not a small problem. > >Delaine M. Arnold, ENP >Independent Consultant >Chair, NENA Data Technical Committee >Voice: 813-960-1698 >Fax: 309-412-7821 >Email: dmarnold@verizon.net >=20 >"The finish line is just the beginning." >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of Winterbottom, James >Sent: Thursday, February 02, 2006 4:57 PM >To: Brian Rosen; ecrit@ietf.org >Subject: RE: [Ecrit] Wireline vs wireless routing > >Ooopss... I meant to add whether this was a 5% outlying=20 >problem, or a significant proportion of jurisdictions? > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf >Of >> Brian Rosen >> Sent: Friday, 3 February 2006 8:17 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] Wireline vs wireless routing >>=20 >> A subtle problem that may give rise to another requirement=20 >is that in=20 >> some areas a true moble client has different routing than a wireline=20 >> client. The psap service boundaies are different depending on what >you >> are calling on. It may be that this difference fades over time, but >its >> clearly different in some areas today. >>=20 >> Brian >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > >--------------------------------------------------------------- >--------- >---- >-------------------- >This message is for the designated recipient only and may=20 >contain privileged, proprietary, or otherwise private information. =20 >If you have received it in error, please notify the sender=20 >immediately and delete the original. Any unauthorized use of=20 >this email is prohibited. >--------------------------------------------------------------- >--------- >---- >-------------------- >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 24 08:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdI0-0004YQ-PP; Fri, 24 Feb 2006 08:47:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdHz-0004YL-SO for ecrit@ietf.org; Fri, 24 Feb 2006 08:47:19 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCdHy-0003AS-87 for ecrit@ietf.org; Fri, 24 Feb 2006 08:47:19 -0500 Received: (qmail invoked by alias); 24 Feb 2006 13:47:16 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp012) with SMTP; 24 Feb 2006 14:47:16 +0100 X-Authenticated: #29516787 Message-ID: <43FF0E58.1080703@gmx.net> Date: Fri, 24 Feb 2006 14:47:04 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt References: <43F867E2.1020005@gmx.net> <43F912B1.8020204@nortel.com> In-Reply-To: <43F912B1.8020204@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org hi tom, thanks for your response. please find some comments inline: Tom-PT Taylor wrote: > Here are my detailed responses. > > Comment: section 1, first sentence, delete "unique". > Response: OK. > > Comment: section 5.1, end of third para, what is meant by "installing > filters"? > Response: What I meant by this was to say "intercept and discard mapping > queries relating to the target at a router on the query-response path or > at the mapping server". Because this is rather longer than the original, > I'll rework the sentence structure to handle it. the problem is: how do you setup these filters to only drop queries by adversaries. this sounds like a difficult problem to me. furthermore, we are supposed to be indicating requirements rather than specific solutions. > > Comment: same section, immediately following sentence talking about > man-in-the-middle attacks, what is meant by "taking control of the > channel"? > Response: I meant "taking control of a router in the query-response > path", and I'll say that instead. ok. > > And BTW, I'm told that taking control of routers is indeed a credible > threat. sure, i agree with you. > > Comment: end of section 5.1, after mention of impersonation of the > mapping server, a suggestion that we should also talk about attacks on > the process of mapping server discovery. > Response: OK, though this gets close to the configuration issues I had > to get rid of because they were out of scope. hmmm. in some sense you are right and on the other hand we have already discussed solutions that effect the "configuration" problem (e.g., recall the discussion we had about the emergency identifier / dial string discussion). > Comment: more detailed and precise wording for bullet c. of section 5.3. > Response: Looks good -- I'll take it. ok. > > Comment: bullet d., section 5.3, wondering if we should add a remark to > the effect that one cannot tell from the URI itself whther it points to > a PSAP. > Response: OK, that's the point -- just wonder if it's too obvious. maybe it is too obvious; i don't know. > > Comment: last para of section 5.3 -- described attack by caller is way > too elaborate -- he just has to hack his device to mark an ordinary call > as an emergency, rather than substitute for the result of mapping. > Response: agreed, will change accordingly. The attack on the mapping > database is a separate one and will remain, though it is probably a bit > far-fetched. ok. > > Comment: beginning of section 6, wording changes. > Response: OK. ok. > > Comment: section 6, spell out man-in-the-middle threat. > Response: This is the requirements section. I suggest spelling out of > attacks belongs in section 5.1. I'd like to make the requirements stand > out clearly by having most of the words in section 6 deal with them > rather than the attacks to which they respond. ok. > > BTW I see "returning no results" as denial of service, whereas > "returning incorrect results" is the MITM attack. If this seems overly > picky, I'll reclassify the attacks by what they attack (caller's device, > router, mapping server + impersonation as a separate category) instead. it is indeed difficult to assign the attacks to specific groups since there is some overlap. > > Comment: section 6, requirements in response to man-in-the-middle > threat. Proposed alternative wording. > Response: Your wording introduces the issue I mentioned in my previous > E-mail: do we require implementation or only make it possible to implement? you mean: implementation vs. usage my impression is that we have to be explicit as whether we talk about usage or implementation when we use RFC 2119 language. we ask roger to walk through the requirements draft todo the same. hence, i think we should also apply it to this draft. you are right that a MUST use in this particular case is really difficult to accomplish in all cases. what about MUST implement and SHOULD use? > > Comment: section 6, different words for the impersonation threat, and > for the response to it. > Response: again, I'd propose that expanded descriptions of attacks > belong in section 5. And your requirement wording appears to go beyond > requirements by becoming a discussion of ways and means. > yes, maybe i went too far with my description of the requirement. (btw, i noticed that i used the word countermeasures and that's a copy-and-paste mistake. it should be read as 'requirement' instead.) > Comment: section 6, confidentiality. Alternative wording. > Response: short rewording OK. Longer wording of threat belongs in > section 5. ok. > > Comment: section 6, fraudulent calls, remark that reverse lookup is an > unnecessary requirement. > Response: You're half right -- it is mostly an optimization. But then > you're assuming that the VSP/ASP proxy is capable of reading the > location from the INVITE so it can redo the lookup. Is this sufficiently > problematic that we need the reverse lookup anyway? we are entering solution specific teritory here. maybe we should talk about this at all in the draft. here is my impression about this stuff in relationship to the ongoing solution specific work: we do not have the infrastructure to perform reverse lookups. we only worried about "Location -> URI" mapping. We have never looked at the URI -> Location mapping. we should keep an eye on this issue. ciao hannes > > Hannes Tschofenig wrote: > >> Hi Tom, >> Hi All, >> >> I went through the recently submitted ECRIT security threats draft >> (see draft-taylor-ecrit-security-threats-02.txt). >> >> My impression is that the document is more focused than the previous >> versions. Good job, Tom! >> >> Here are some minor review comments: >> http://www.ietf-ecrit.org/TEMP/draft-taylor-ecrit-security-threats-02_hannes.txt >> >> >> The challenge in the near future will be to capture security threats >> and security requirements that show up in the context of the work on >> the mapping protocol. >> >> Request to all: Please review the document and submit you comments. >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 24 09:12:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdfr-0001tI-9J; Fri, 24 Feb 2006 09:11:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdfp-0001ru-Nh for ecrit@ietf.org; Fri, 24 Feb 2006 09:11:57 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCdfp-000446-AB for ecrit@ietf.org; Fri, 24 Feb 2006 09:11:57 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1OEBs010902; Fri, 24 Feb 2006 09:11:54 -0500 (EST) Received: from [127.0.0.1] ([47.130.17.248] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 09:11:42 -0500 Message-ID: <43FF141A.5010301@nortel.com> Date: Fri, 24 Feb 2006 09:11:38 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt References: <43F867E2.1020005@gmx.net> <43F912B1.8020204@nortel.com> <43FF0E58.1080703@gmx.net> In-Reply-To: <43FF0E58.1080703@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 14:11:42.0771 (UTC) FILETIME=[3CD7C830:01C6394C] X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm pleased to get your response. I never got my copy of my E-mail to the list,so I was afraid it had disappeared into a black hole. Just a couple of items to discuss, see below. Other stuff snipped away. Hannes Tschofenig wrote: > hi tom, > > thanks for your response. > please find some comments inline: > > Tom-PT Taylor wrote: > >> Here are my detailed responses. >> ... >> >> Comment: section 5.1, end of third para, what is meant by "installing >> filters"? >> Response: What I meant by this was to say "intercept and discard >> mapping queries relating to the target at a router on the >> query-response path or at the mapping server". Because this is rather >> longer than the original, I'll rework the sentence structure to handle >> it. > > > the problem is: how do you setup these filters to only drop queries by > adversaries. this sounds like a difficult problem to me. > furthermore, we are supposed to be indicating requirements rather than > specific solutions. > [PTT] No, I meant that the attacker installs the filters. Presumably the attacker has the information to construct them. >> ... >> >> Comment: section 6, requirements in response to man-in-the-middle >> threat. Proposed alternative wording. >> Response: Your wording introduces the issue I mentioned in my previous >> E-mail: do we require implementation or only make it possible to >> implement? > > > you mean: implementation vs. usage > > my impression is that we have to be explicit as whether we talk about > usage or implementation when we use RFC 2119 language. we ask roger to > walk through the requirements draft todo the same. hence, i think we > should also apply it to this draft. > > you are right that a MUST use in this particular case is really > difficult to accomplish in all cases. > > what about MUST implement and SHOULD use? > [PTT] We've heard objections that MUST implement is unrealistic for a couple of reasons -- client resources and effect on call setup times. Anyway, a "MUST implement" provision would be part of the protocol specification rather than the requirements. What we would distinguish at the requirements level is "the protocol must provide" vs. "the protocol must not prevent". I am suggesting we use the latter. >> ... >> >> Comment: section 6, fraudulent calls, remark that reverse lookup is an >> unnecessary requirement. >> Response: You're half right -- it is mostly an optimization. But then >> you're assuming that the VSP/ASP proxy is capable of reading the >> location from the INVITE so it can redo the lookup. Is this >> sufficiently problematic that we need the reverse lookup anyway? > > we are entering solution specific teritory here. maybe we should talk > about this at all in the draft. > > here is my impression about this stuff in relationship to the ongoing > solution specific work: > we do not have the infrastructure to perform reverse lookups. we only > worried about "Location -> URI" mapping. We have never looked at the URI > -> Location mapping. > > we should keep an eye on this issue. > [PTT] The requirement doesn't go that far. What is needed is to be able to look up a URI and get back an assurance that the URI points to a PSAP -- a "yes" or "no". I'll make sure the wording is clear on this point. > ciao > hannes > ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 27 08:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDim3-0001Xa-Kt; Mon, 27 Feb 2006 08:50:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDim2-0001XI-Eu for ecrit@ietf.org; Mon, 27 Feb 2006 08:50:50 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDim1-0002gW-0B for ecrit@ietf.org; Mon, 27 Feb 2006 08:50:50 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k1RDomvN028860 for ; Mon, 27 Feb 2006 14:50:48 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k1RDolk7012073 for ; Mon, 27 Feb 2006 14:50:47 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 14:50:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Feb 2006 14:47:58 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Draft Submissions thread-index: AcY7pFXlw2mbKkTBSliVC+HyrmyKkA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 27 Feb 2006 13:50:46.0895 (UTC) FILETIME=[CF858FF0:01C63BA4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Ecrit] New Draft Submissions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all,=20 it seems that we have a few new drafts to read. LoST: A Location-to-Service Translation Protocol http://www.ietf-ecrit.org/cache/draft-hardie-ecrit-lost-00.txt This document describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. As discussed during the interim meeting Ted, Andy, Henning and myself worked on a new mapping protocol proposal -- a merger between ECON-IRIS & LUMP. This is the first step. James/Brian provided a few more documents. Very good! ECRIT Mapping During Session Initiation Protocol Registration http://www.ietf-ecrit.org/cache/draft-polk-ecrit-mapping-during-registra tion-00.txt This document discusses four different Layer-7 options to solve the=20 problem of getting the appropriate Public Safety Answering Point=20 (PSAP) Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) into an emergency calling capable device prior to it's user=20 calling for help. Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling http://www.ietf-ecrit.org/cache/draft-polk-ecrit-mapping-events-00.txt Emergency calling is a localized event, requiring a caller to place=20 an specially identified local emergency call to a Public Safety=20 Answering Point (PSAP), while including the location of the caller=20 in that signaling. The function of routing the set-up messaging to=20 the appropriate PSAP is performed by a mapping function that binds a given location with one or more PSAP SIP(S)-URIs. This function is=20 done by the ECRIT mapping protocol. This document analyzes when the ECRIT mapping protocol function can occur, and what general=20 components are involved in that mapping. Using the Session Initiation Protocol REGISTER Method To Obtain an Emergency Dialstring http://www.ietf-ecrit.org/cache/draft-polk-ecrit-emergency-dialstring-00 .txt Most efforts to address emergency calling challenges over IP (and=20 cellular technologies such as GSM, TDMA, CDMA, etc, for that matter) have focused on locating the calling user in order to route the=20 emergency call set-up request to the appropriate Public Safety=20 Answering Point (PSAP). Little or no effort to date has focused on=20 informing the caller what dialstring sequence they may need to use=20 to initiate a call for emergency help. This document describes how=20 the Session Initiation Protocol (SIP) REGISTER Request message is=20 used to inform a user of which emergency dialstring (of the 60 known dialstring choices around the world) they should use, for where they are geographically. A Dynamic Host Configuration Protocol Option for the Locally Significant Emergency Calling Dialstring=20 http://www.ietf-ecrit.org/cache/draft-polk-dhc-emergency-dialstring-opti on-00.txt This document defines a new Dynamic Host Configuration Protocol=20 Option for a client to be able to request its locally significant=20 emergency dialstring from the local infrastructure. =20 James/Brian might be able to give more info about their documents.=20 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 27 09:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDj9D-0006sj-Fg; Mon, 27 Feb 2006 09:14:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDj9B-0006p3-Pf for ecrit@ietf.org; Mon, 27 Feb 2006 09:14:45 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDj9A-0003YN-JB for ecrit@ietf.org; Mon, 27 Feb 2006 09:14:45 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1REEhb9016375 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 27 Feb 2006 09:14:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <25C50492-1B2D-4E28-8E79-9B881119644C@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: Henning Schulzrinne Date: Mon, 27 Feb 2006 09:14:42 -0500 X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] draft-polk-ecrit-mapping-during-registration-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org From a quick glance at the draft, I'm surprised that it doesn't mention the option that we discussed extensively during the interim meeting, namely that the end point (UA) performs a mapping protocol query. It is unclear from the draft whether the Option #3 (UA performs a HTTP query to a remote server) is meant to imply that. Also, the draft does not mention the use of the SIP configuration mechanism as another option. I have to admit that I find it peculiar that we need this draft at all, given that the end system can run the mapping protocol easily. Having half a dozen different ways to do roughly the same thing seems rather sub-optimal. I will note that configuration via REGISTER has been discussed in the SIPPING working group. I can't speak for that group, but my recollection was that this did not find favor. Given that the draft proposes changes to SIP, it would presumably have to be discussed in SIPPING as well. I suspect the authors have had particular issues in mind that they can share with the group at large. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 27 09:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjOi-0007Bm-7I; Mon, 27 Feb 2006 09:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjOg-0007BP-GD for ecrit@ietf.org; Mon, 27 Feb 2006 09:30:46 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjOg-00043S-4k for ecrit@ietf.org; Mon, 27 Feb 2006 09:30:46 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1REUjOs020135 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 27 Feb 2006 09:30:45 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <69435D85-5673-4F32-B321-F766EBB2A218@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: Henning Schulzrinne Date: Mon, 27 Feb 2006 09:30:44 -0500 X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ecrit] draft-polk-dhc-emergency-dialstring-option X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Another quick comment: I'm glad to see this problem discussed, but I think we again need to ask ourselves how we can achieve economy of protocols. I think we should aim, overall, for the smallest number of distinct protocols, as that will greatly simplify interoperation, testing and in-field configuration. I think the configuration problem is easily solved using existing mechanisms, without DHCP. In particular, there are two options: (1) Using the mapping protocol: If the UA does a mapping protocol query, using either geo or civic, the response returns the dialstring. As shown in the LoST draft example, this is a one-line trivial addition to the protocol and has the advantage that the people who maintain the mapping database are in a much better position than anybody else to know 'their' dial strings. (2) Using the SIP configuration mechanism: The user includes the location information in the configuration request (or the VSP gets the location) and gets the dial string along with all the other configuration information. The configuration server would presumably do the mapping query as in (1). My concern with a DHCP solution is that it only works for residential users if all home routers (Linksys, etc.) are upgraded and, longer term, if we can trust local providers, including the coffee shop running their own AP, to track changes in dial strings. While this is not likely to be a major problem for 911 in the US, dial strings can and do change, particularly as local dial strings are replaced by region-wide strings, such as 112 in Europe or as new services, such as poison control, are introduced. I think we had general agreement that we want to invent as few new protocols as possible, integrating emergency calling into more general frameworks where possible, such as device configuration for SIP devices. Thus, in my opinion, we should try to see first if existing mechanisms can address the problem, rather than adding to the protocol and mechanism proliferation. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 27 09:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjbu-0005gu-CY; Mon, 27 Feb 2006 09:44:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjbt-0005gm-L6 for ecrit@ietf.org; Mon, 27 Feb 2006 09:44:25 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjbs-0004pU-7I for ecrit@ietf.org; Mon, 27 Feb 2006 09:44:25 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k1REiN56019064 for ; Mon, 27 Feb 2006 15:44:23 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k1REiM2h003335 for ; Mon, 27 Feb 2006 15:44:23 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 15:44:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Feb 2006 15:43:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Best Current Practice for Communications Services in support of Emergency Calling thread-index: AcY7q3UCNyC5bIHhRCWPJ1877Is1Rw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 27 Feb 2006 14:44:22.0336 (UTC) FILETIME=[4C12EC00:01C63BAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] Best Current Practice for Communications Services in support of Emergency Calling X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all,=20 here is another draft: Best Current Practice for Communications Services in support of Emergency Calling http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-00.txt =20 Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 28 06:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE320-0008Fx-MA; Tue, 28 Feb 2006 06:28:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE31z-0008Fd-D7 for ecrit@ietf.org; Tue, 28 Feb 2006 06:28:39 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE31w-0007uV-TF for ecrit@ietf.org; Tue, 28 Feb 2006 06:28:39 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k1SBSZq4003989 for ; Tue, 28 Feb 2006 12:28:35 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k1SBSUpC006226 for ; Tue, 28 Feb 2006 12:28:35 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 12:28:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2006 12:23:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Update: ECRIT Requirements thread-index: AcY8WV6tR6gaLPtTTKKTjzD3yXs4Qg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 28 Feb 2006 11:28:30.0779 (UTC) FILETIME=[1A0360B0:01C63C5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ecrit] Draft Update: ECRIT Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Roger has submitted another draft update based on the comments he received. Please find the draft here: http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-05.txt http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-05.html Thank you Roger!=20 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 28 06:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE329-0008KN-S8; Tue, 28 Feb 2006 06:28:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE328-0008K5-KE for ecrit@ietf.org; Tue, 28 Feb 2006 06:28:48 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE328-0007ul-6g for ecrit@ietf.org; Tue, 28 Feb 2006 06:28:48 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k1SBSZh3003987; Tue, 28 Feb 2006 12:28:38 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k1SBSUpA006226; Tue, 28 Feb 2006 12:28:31 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 12:28:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2006 12:25:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for ECRIT Requirements thread-index: AcY8WaC89tq9guP7T3mAD70zgefP3Q== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 28 Feb 2006 11:28:30.0513 (UTC) FILETIME=[19DACA10:01C63C5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ecrit] WGLC for ECRIT Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all,=20 the requirements draft is ready for WGLC. We initially planned to start the WGLC a bit earlier (20th Feb.) as mentioned on the mailing list and discussed during the interim meeting (see http://www1.ietf.org/mail-archive/web/ecrit/current/msg01518.html) but additional review comments had to be incorporated. Anyway, here is the document draft-ietf-ecrit-requirements-05.txt: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-05.txt Before the draft appears in the archive please find it at:=20 http://www.ietf-ecrit.org/cache/draft-ietf-ecrit-requirements-05.txt The WGLC will run for two weeks until March 14th. Ciao Hannes / Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 28 09:02:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5R2-0006XR-Ey; Tue, 28 Feb 2006 09:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5R0-0006V8-S2 for ecrit@ietf.org; Tue, 28 Feb 2006 09:02:38 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5Qz-00047z-En for ecrit@ietf.org; Tue, 28 Feb 2006 09:02:38 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k1SE2Y17001874; Tue, 28 Feb 2006 15:02:34 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k1SE2WU5018701; Tue, 28 Feb 2006 15:02:33 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 15:02:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2006 14:59:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF#65 ECRIT WG Meeting Preparation thread-index: AcY8bz7txLgv9wbmSqiSF6dxUDOaDg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 28 Feb 2006 14:02:32.0589 (UTC) FILETIME=[9E8FABD0:01C63C6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ecrit] IETF#65 ECRIT WG Meeting Preparation X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all,=20 to prepare the agenda for the meeting you need to let us know whether you would like to give a presentation. Title, pointer to your draft and estimated presentation time is already sufficient.=20 If you have submitted a draft please also drop a mail to the ECRIT mailing list (or to the chairs) to inform us about the new work (or update) as soon as possible.=20 Ciao Hannes/Marc PS: The final agenda will be available here: https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 28 09:26:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5no-0006nJ-5D; Tue, 28 Feb 2006 09:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5nm-0006hF-Ok for ecrit@ietf.org; Tue, 28 Feb 2006 09:26:10 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5nl-00057J-IG for ecrit@ietf.org; Tue, 28 Feb 2006 09:26:10 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1SEQ85n024331 for ; Tue, 28 Feb 2006 08:26:08 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Feb 2006 14:26:08 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0122FFB0B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: ecrit@ietf.org Date: Tue, 28 Feb 2006 14:26:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] draft-ietf-ecrit-urn X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I understood that the predecessor of this document draft-ietf-sipping-sos-02: Emergency Services URI for the Session Initiation Protocol implicitly carried the implementation of the following requirement from draft-ietf-ecrit-requirements-05, i.e. the presence of the emergency URI was also the emergency marking. Id3. Emergency Marking: Any device in the signaling path that recognizes by some means that the signaling is associated with an emergency call MUST add a specific emergency indication, if it doesn't already exist, to the signaling before forwarding it. This marking mechanism must be different than QoS marking. Motivation: Marking ensures proper handling as an emergency call by downstream elements that may not recognize, for example, a local variant of a logical emergency address. So my question is as to whether the presence of the service type "sos" defined in the new draft is sufficient indication of this marking, or whether ecrit expects some other SIP indication to give this emergency marking. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 28 15:32:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEBWI-0005OK-SH; Tue, 28 Feb 2006 15:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEBWH-0005NN-FE for ecrit@ietf.org; Tue, 28 Feb 2006 15:32:29 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEBWG-0001ED-5h for ecrit@ietf.org; Tue, 28 Feb 2006 15:32:29 -0500 Received: from lion.cs.columbia.edu (IDENT:DA1nimTPTZiercyOJxRweLHT2fLtbaIJ@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k1SKVreg010146 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 28 Feb 2006 15:32:14 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k1SKVqjN032748 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Feb 2006 15:31:52 -0500 Message-ID: <4404B333.2010206@cs.columbia.edu> Date: Tue, 28 Feb 2006 15:31:47 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Ecrit] draft-ietf-ecrit-urn References: <475FF955A05DD411980D00508B6D5FB0122FFB0B@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0122FFB0B@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_INTRO 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm hoping that the use of the service URN in the SIP To header field is sufficient marking. In the sipping-sos case, I had split this into two since there was the perception that overloading the user field of the URI with lots of different services would be a bad idea. This isn't really a problem here. See http://www.cs.columbia.edu/~hgs/papers/2006/ecrit-arch.ppt for an attempt to go through the various cases of who determines that a call is an emergency call. The one issue that arises is if the UA doesn't recognize emergency calls and just routes the SIP or tel URI to the proxy. The proxy can't replace the To header field, so there's no place to put a service indication. I don't know if that is important since the same entity will also have to do the mapping and thus insert a PSAP URI in the request URI field. The request will then visit that PSAP URI on the next hop. Unless a PSAP were to use the same URI for both the general business address and the emergency contact address, there is no confusion and no additional routing in the "public" SIP server space. (Commingling emergency and non-emergency calls on the same SIP URI seems both ill-advised and unnecessary.) Do you think we need the additional marker? (My general inclination is to keep things as simple as possible, i.e., to avoid adding SIP header fields if we can help it.) It would be easy to keep the same media feature tag as in sipping-sos: Accept-Contact: *;sip.service="urn:service:sos.marine" Opinions? Henning Drage, Keith (Keith) wrote: > I understood that the predecessor of this document > > draft-ietf-sipping-sos-02: Emergency Services URI for the Session Initiation Protocol > > implicitly carried the implementation of the following requirement from draft-ietf-ecrit-requirements-05, i.e. the presence of the emergency URI was also the emergency marking. > > Id3. Emergency Marking: Any device in the signaling path that > recognizes by some means that the signaling is associated with an > emergency call MUST add a specific emergency indication, if it > doesn't already exist, to the signaling before forwarding it. > This marking mechanism must be different than QoS marking. > > Motivation: Marking ensures proper handling as an emergency call > by downstream elements that may not recognize, for example, a > local variant of a logical emergency address. > > So my question is as to whether the presence of the service type "sos" defined in the new draft is sufficient indication of this marking, or whether ecrit expects some other SIP indication to give this emergency marking. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit