From ecrit-bounces@ietf.org Fri Feb 18 08:32:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00967; Fri, 18 Feb 2005 08:32:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28ar-0008Na-Ug; Fri, 18 Feb 2005 08:54:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D284t-00035T-09; Fri, 18 Feb 2005 08:21:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1uzw-0004gb-Qa for ecrit@megatron.ietf.org; Thu, 17 Feb 2005 18:23:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23347 for ; Thu, 17 Feb 2005 18:23:50 -0500 (EST) Received: from okigate.oki.co.jp ([202.226.91.194] helo=iscan4.intra.oki.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1vLT-0004EM-OM for Sipping-emergency@ietf.org; Thu, 17 Feb 2005 18:46:08 -0500 Received: from s24c10.dm1.oii.oki.co.jp (iscan [127.0.0.1]) by iscan4.intra.oki.co.jp (8.11.6/8.11.6) with ESMTP id j1HNNkH27982; Fri, 18 Feb 2005 08:23:46 +0900 Received: from sippc01 (t101m178.dm1.oii.oki.co.jp [10.55.71.178]) by s24c10.dm1.oii.oki.co.jp (8.11.6/8.11.2) with ESMTP id j1HNNkp30843; Fri, 18 Feb 2005 08:23:46 +0900 Message-Id: <200502172323.j1HNNkp30843@s24c10.dm1.oii.oki.co.jp> From: "Arai, Hideki" To: , Date: Fri, 18 Feb 2005 08:23:44 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUVR7j+oarRS003R9qqwVafRer7hQ== X-Spam-Score: 1.9 (+) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 18 Feb 2005 08:21:50 -0500 Subject: [Ecrit] RE: [Sipping-emergency] draft-arai-ecrit-japan-req-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 X-Spam-Score: 1.9 (+) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: 7bit Hi, Thank you for comments. First of all, let me make some revisions in the draft. I have to revise the description about the composition of Police head offices in section 2 as follows; "1 in each 47 prefectures, except 2 in Tokyo and 5 in Hokkaido" other comments in line. Regards, Hideki -- Hideki Arai IPTPC, Oki arai859@oki.com > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, February 17, 2005 12:16 AM > To: 'Motoharu Kawanishi'; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] draft-arai-ecrit-japan-req-00.txt > > > I appreciate this draft very much. It will be of great help to us as > we complete the work in ecrit. > > I have some questions and comments on the draft. > > 1. Are the boundaries for the police, fire/ems, and coast guard > services always aligned to a municipal boundary? In North America, > while they often are, there are some cases where the boundaries are > not aligned with municipal boundaries. I suspect that is true also in > Japan, but would like to know for sure. I assume that prefecture > boundaries, and thus police districts always align with municipal > boundaries. In Tokyo and Hokkaido, what defines the boundaries of the > 2 or 3 police districts? Is there only one fire district in Tokyo > (really, is there only one fire emergency call center in Tokyo)? Police districts always align with prefecture boundaries except Tokyo and Hokkaido. I do not exactly know the police boundaries in Tokyo and Hokkaido, but they should be aligned with cities, counties, towns or villages. About the fire/ems district in Tokyo, there are more than one fire emergency call centers. The boundaries are also aligned with cities, counties, towns or villages. > Another way to ask this is, if all I knew was the name of the > municipality, would I be able to determine to which desk the call > should be sent in all case? Yes, that's right. However, the name of the municipality may not be used for the routing purpose in general, because originating call server can look up the relevant emergency desk's address by calling party's telephone number except for mobile phones. > > 2. (not really an ecrit question) When you have the "keeping > connection" facility, if the caller hangs up, does the telephone ring? > Presumably whether or not it rings, if the handset was picked up > again, the caller would still be connected to the emergency call > center. According to the MIC proposal, telephone does not ring when a caller hangs up. However, either of the following functionalities must be supported. a. no new call from/to the caller is established, or b. establishing a new call from/to the caller is allowed, but the emergency call center's call always override other call. I.e., if the caller were on a new call, the call must be terminated and another call from the emergency call center must be established. > > 3. (also not really ecrit). Could you explain more about "add_area", > as defined in Figure 1. Is this municipality? prefecture? Is it a > code or a text string? "add_area" is a tag for enclosing the tags from "add_post" to "add_others". For example; 1000000 13101000000 ..... ..... > > 3. We will have to add someplace to put a > JIS code. We have the other fields. JIS codes as an encoding method for Japanese characters won't appear in call control signaling messages (e.g. SIP). According to the draft proposal from MIC, the geographical location information won't be conveyed by any call control signaling messages through a connection for them but will be conveyed by XML/HTTP through a route different from it currently. The reason is to follow the existing manner, i.e. POTS and mobile phone. > > 4. We need to spend > more time on "Name". We have AoR (for SIP), that is not name. We > could translate AoR to name if we had an appropriate database. This > may also be useful as a way to provide (directly or via a pointer/URI) > other information associated with a caller, independently of an AoR. > For example, pre-existing medical conditions, "In emergency, please > contact ...". > > 5. I am not familiar enough with names in > Japanese. I understand kana/kanji, but I do not understand > "name_area". Could you explain. "name_area" is the tag, like "add_area", for enclosing tags "name_kana" and "name_kanji". > > 6. In figure 3, you have both what we would call a "civic" location, > as well as what we would call a "geo" location. Can you explain how > you intend to use both sets of fields? Is it intended that either, but > not both would be used at one time? If both may be used, what would > be understood to be the meaning? If both were used, how would a > routing decision be made if the route for one was different from the > route for the other? These information won't be used for a routing decision. As already mentioned, they will be conveyed through a different connection from a call. For that reason this requirement might not be relevant to the ecrit discussion. > > 7. I am not sure I understand how you use both a radius and a > precision. In North America, we have attempted to use "uncertainty" > and "confidence", where uncertainty can be related to radius, but > "confidence" is a percentage ("I am 90% sure it lies within 500 meters > of this lat/lon/altitude"). How is "precision" defined? What units > of measure does it use? The precision of the radius is 1 meter unit, and the range is between 10 and 1000. the range within which he/she would be must be indicated by CircularArea (X, Y and Radius). And also the precision of the altitude is 1 meter unit. > 8. As I understand the current system, the emergency call center must > request location; it is not automatically supplied. In general, the > direction we had been going is to assume location came with the call. > Would that violate any law or cause a large problem for the emergency > center? According to "The Guidelines on the Protection of Personal Information in the Telecommunication Business (MIC Announcement No. 695 of 2004)", when a caller indicated CLIR, a caller's location information should not be supplied even to the emergency call center. However, the guideline allows the emergency call center to know the caller's personal information where there is a situation that the caller faces a crisis of a matter of life and death, Unless the caller indicated CLIR, the caller ID would be conveyed by a call control signaling message (e.g. SIP) and the geographical location information would be conveyed by XML/HTTP. > > 9. You have presented a specific transport and a specific format for > location. If location came in the form of the present PIDF-LO, so > long as we addressed the "JIS code", would that be acceptable? If > there was a different transport other than HTTP, would that be > acceptable? Use of PIDF-LO for the emergency call may be a possibility in the future. However I don't have a concrete proposal at present. > 10. In this draft, you have assumed that there is always a carrier. > You have also assumed that there is always a telephone NUMBER. In > VoIP, there may not be a carrier, and we may have a URI that is not a > number. Do you intend to allow such calls? Although the necessity of handling emergency reports under such environment is recognized in Japan, the current version of MIC report is mainly for the emergency reports using public IP telephony services that are hosted by carriers. Future MIC study may address other types of IP communication. > > > -----Original Message----- > > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency- > > bounces@ietf.org] On Behalf Of Motoharu Kawanishi/???? > > Sent: Wednesday, February 16, 2005 6:49 AM > > To: sipping-emergency@ietf.org > > Subject: [Sipping-emergency] draft-arai-ecrit-japan-req-00.txt > > > > > > Hi all, > > > > We submitted an I-D that describes the functional requirements to > > emergency calls for Japanese IP telephony services. Those > requirements > > are extracted from a proposed report of a Japanese > government-hosted > > study group on emergency-calls. I hope these functional > requirements > > are used as an informational input to the ecrit work, and are > > reflected to the functional requirements where appropriate. > > > > The draft is now available below. I appreciate your comments. > > > http://www.ietf.org/internet-drafts/draft-arai-ecrit-japan-req-00.txt > > > > Regards, > > Motoharu > > > > --- > > Motoharu Kawanishi > > IPTPC, Oki > > kawanishi381@oki.com > > > > > > _______________________________________________ > > Sipping-emergency mailing list > > Sipping-emergency@ietf.org > > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 18 08:33:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01094; Fri, 18 Feb 2005 08:33:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28bs-0008PF-Ff; Fri, 18 Feb 2005 08:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D285M-0003Lr-5E; Fri, 18 Feb 2005 08:22:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qSb-0003Rn-Qb for ecrit@megatron.ietf.org; Thu, 17 Feb 2005 13:33:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16044 for ; Thu, 17 Feb 2005 13:33:05 -0500 (EST) Received: from [216.220.209.221] (helo=mfe3.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qo3-0002AO-JD for sipping-emergency@ietf.org; Thu, 17 Feb 2005 13:55:21 -0500 Received: from [10.253.5.251] (HELO localhost.localdomain) by mfe3.prod.danger.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 245726308 for sipping-emergency@ietf.org; Thu, 17 Feb 2005 10:31:20 -0800 Date: Thu, 17 Feb 2005 13:31:07 -0500 X-Mailer: Danger Service Content-Type: multipart/mixed; boundary="==DNGR-1108665080==" To: sipping-emergency@ietf.org Mime-Version: 1.0 References: <200502171459.JAA01707@ietf.org> From: Brian Rosen Message-Id: <1108665079.30270707@bd12.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Fri, 18 Feb 2005 08:22:19 -0500 Subject: [Ecrit] Fw: I-D ACTION:draft-rosen-nena-ecrit-requirements-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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --==DNGR-1108665080== Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Description: message body text Content-Transfer-Encoding: 7bit We would like to discuss this draft in Minneapolis Brian -----Original Message----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosen-nena-ecrit-requirements-00.txt Date: Thu, 17 Feb 2005 09:59:23 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NENA Requirements for Emergency Call processing Author(s) : B. Rosen, N. Abbott Filename : draft-rosen-nena-ecrit-requirements-00.txt Pages : 14 Date : 2005-2-16 The National Emergency Number Association (NENA)'s mission is to foster the technological advancement, availability, and implementation of a universal emergency telephone number system in North America. NENA has an active effort to develop a new architecture for emergency call handling known as 'i3' being developed in its Long Term Definition working group. The following requirements are a subset of the requirements of the i3 work which relate to ecrit work. NENA understands the global nature of the Internet, and is eager to work with the IETF to ensure that emergency call processing meets the needs of users in North America. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-nena-ecrit-requirements-00.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-rosen-nena-ecrit-requirements-00.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-rosen-nena-ecrit-requirements-00.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --==DNGR-1108665080== Content-Type: message/external-body Content-Disposition: attachment; filename="attachment" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2005-2-17102340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-nena-ecrit-requirements-00.txt --==DNGR-1108665080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --==DNGR-1108665080==-- From ecrit-bounces@ietf.org Fri Feb 18 08:35:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01268; Fri, 18 Feb 2005 08:35:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28dR-0008RU-4g; Fri, 18 Feb 2005 08:57:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D287A-00041n-Oh; Fri, 18 Feb 2005 08:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nEy-0008PI-3L for ecrit@megatron.ietf.org; Thu, 17 Feb 2005 10:06:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03070 for ; Thu, 17 Feb 2005 10:06:49 -0500 (EST) From: h.arai@d9.dion.ne.jp Received: from mail.dion.ne.jp ([61.117.3.52] helo=dsmtp3.dion.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1naK-0005mT-FV for Sipping-emergency@ietf.org; Thu, 17 Feb 2005 10:29:02 -0500 Received: from webmail.dion.ne.jp ([210.196.2.178]) by dsmtp3.dion.ne.jp (3.7W-04012715) id AAA19948; Fri, 18 Feb 2005 00:06:21 +0900 (JST) To: br@brianrosen.net, Sipping-emergency@ietf.org Date: Fri, 18 Feb 2005 00:06:21 +0900 Message-Id: <1108652781.7917@222.226.43.29.DIONWebMail> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: DION Web mail version 1.03 X-Originating-IP: 222.226.43.29(*) X-Spam-Score: 1.3 (+) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 X-Mailman-Approved-At: Fri, 18 Feb 2005 08:24:11 -0500 Subject: [Ecrit] RE: [Sipping-emergency] draft-arai-ecrit-japan-req-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 X-Spam-Score: 1.3 (+) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Hi, Thank you for comments. First of all, let me make some revisions in the draft. I have to revise the description about the composition of Police head offices in section 2 as follows; "1 in each 47 prefectures, except 2 in Tokyo and 5 in Hokkaido" other comments in line. Regards, Hideki -- Hideki Arai IPTPC, Oki arai859@oki.com > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, February 17, 2005 12:16 AM > To: 'Motoharu Kawanishi'; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] draft-arai-ecrit-japan-req-00.txt > > > I appreciate this draft very much. It will be of great help to us as > we complete the work in ecrit. > > I have some questions and comments on the draft. > > 1. Are the boundaries for the police, fire/ems, and coast guard > services always aligned to a municipal boundary? In North America, > while they often are, there are some cases where the boundaries are > not aligned with municipal boundaries. I suspect that is true also in > Japan, but would like to know for sure. I assume that prefecture > boundaries, and thus police districts always align with municipal > boundaries. In Tokyo and Hokkaido, what defines the boundaries of the > 2 or 3 police districts? Is there only one fire district in Tokyo > (really, is there only one fire emergency call center in Tokyo)? Police districts always align with prefecture boundaries except Tokyo and Hokkaido. I do not exactly know the police boundaries in Tokyo and Hokkaido, but they should be aligned with cities, counties, towns or villages. About the fire/ems district in Tokyo, there are more than one fire emergency call centers. The boundaries are also aligned with cities, counties, towns or villages. > Another way to ask this is, if all I knew was the name of the > municipality, would I be able to determine to which desk the call > should be sent in all case? Yes, that's right. However, the name of the municipality may not be used for the routing purpose in general, because originating call server can look up the relevant emergency desk's address by calling party's telephone number except for mobile phones. > > 2. (not really an ecrit question) When you have the "keeping > connection" facility, if the caller hangs up, does the telephone ring? > Presumably whether or not it rings, if the handset was picked up > again, the caller would still be connected to the emergency call > center. According to the MIC proposal, telephone does not ring when a caller hangs up. However, either of the following functionalities must be supported. a. no new call from/to the caller is established, or b. establishing a new call from/to the caller is allowed, but the emergency call center's call always override other call. I.e., if the caller were on a new call, the call must be terminated and another call from the emergency call center must be established. > > 3. (also not really ecrit). Could you explain more about "add_area", > as defined in Figure 1. Is this municipality? prefecture? Is it a > code or a text string? "add_area" is a tag for enclosing the tags from "add_post" to "add_others". For example; 1000000 13101000000 ..... ..... > > 3. We will have to add someplace to put a > JIS code. We have the other fields. JIS codes as an encoding method for Japanese characters won't appear in call control signaling messages (e.g. SIP). According to the draft proposal from MIC, the geographical location information won't be conveyed by any call control signaling messages through a connection for them but will be conveyed by XML/HTTP through a route different from it currently. The reason is to follow the existing manner, i.e. POTS and mobile phone. > > 4. We need to spend > more time on "Name". We have AoR (for SIP), that is not name. We > could translate AoR to name if we had an appropriate database. This > may also be useful as a way to provide (directly or via a pointer/URI) > other information associated with a caller, independently of an AoR. > For example, pre-existing medical conditions, "In emergency, please > contact ...". > > 5. I am not familiar enough with names in > Japanese. I understand kana/kanji, but I do not understand > "name_area". Could you explain. "name_area" is the tag, like "add_area", for enclosing tags "name_kana" and "name_kanji". > > 6. In figure 3, you have both what we would call a "civic" location, > as well as what we would call a "geo" location. Can you explain how > you intend to use both sets of fields? Is it intended that either, but > not both would be used at one time? If both may be used, what would > be understood to be the meaning? If both were used, how would a > routing decision be made if the route for one was different from the > route for the other? These information won't be used for a routing decision. As already mentioned, they will be conveyed through a different connection from a call. For that reason this requirement might not be relevant to the ecrit discussion. > > 7. I am not sure I understand how you use both a radius and a > precision. In North America, we have attempted to use "uncertainty" > and "confidence", where uncertainty can be related to radius, but > "confidence" is a percentage ("I am 90% sure it lies within 500 meters > of this lat/lon/altitude"). How is "precision" defined? What units > of measure does it use? The precision of the radius is 1 meter unit, and the range is between 10 and 1000. the range within which he/she would be must be indicated by CircularArea (X, Y and Radius). And also the precision of the altitude is 1 meter unit. > 8. As I understand the current system, the emergency call center must > request location; it is not automatically supplied. In general, the > direction we had been going is to assume location came with the call. > Would that violate any law or cause a large problem for the emergency > center? According to "The Guidelines on the Protection of Personal Information in the Telecommunication Business (MIC Announcement No. 695 of 2004)", when a caller indicated CLIR, a caller's location information should not be supplied even to the emergency call center. However, the guideline allows the emergency call center to know the caller's personal information where there is a situation that the caller faces a crisis of a matter of life and death, Unless the caller indicated CLIR, the caller ID would be conveyed by a call control signaling message (e.g. SIP) and the geographical location information would be conveyed by XML/HTTP. > > 9. You have presented a specific transport and a specific format for > location. If location came in the form of the present PIDF-LO, so > long as we addressed the "JIS code", would that be acceptable? If > there was a different transport other than HTTP, would that be > acceptable? Use of PIDF-LO for the emergency call may be a possibility in the future. However I don't have a concrete proposal at present. > 10. In this draft, you have assumed that there is always a carrier. > You have also assumed that there is always a telephone NUMBER. In > VoIP, there may not be a carrier, and we may have a URI that is not a > number. Do you intend to allow such calls? Although the necessity of handling emergency reports under such environment is recognized in Japan, the current version of MIC report is mainly for the emergency reports using public IP telephony services that are hosted by carriers. Future MIC study may address other types of IP communication. > > > -----Original Message----- > > From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency- > > bounces@ietf.org] On Behalf Of Motoharu Kawanishi/???? > > Sent: Wednesday, February 16, 2005 6:49 AM > > To: sipping-emergency@ietf.org > > Subject: [Sipping-emergency] draft-arai-ecrit-japan-req-00.txt > > > > > > Hi all, > > > > We submitted an I-D that describes the functional requirements to > > emergency calls for Japanese IP telephony services. Those > requirements > > are extracted from a proposed report of a Japanese > government-hosted > > study group on emergency-calls. I hope these functional > requirements > > are used as an informational input to the ecrit work, and are > > reflected to the functional requirements where appropriate. > > > > The draft is now available below. I appreciate your comments. > > > http://www.ietf.org/internet-drafts/draft-arai-ecrit-japan-req-00.txt > > > > Regards, > > Motoharu > > > > --- > > Motoharu Kawanishi > > IPTPC, Oki > > kawanishi381@oki.com > > > > > > _______________________________________________ > > Sipping-emergency mailing list > > Sipping-emergency@ietf.org > > https://www1.ietf.org/mailman/listinfo/sipping-emergency > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 23 16:21:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18981; Wed, 23 Feb 2005 16:21:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D44JY-0002GE-Dg; Wed, 23 Feb 2005 16:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3tjf-0007dV-3Y; Wed, 23 Feb 2005 05:27:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mBT-0007Pg-NV for ecrit@megatron.ietf.org; Tue, 22 Feb 2005 21:23:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26159 for ; Tue, 22 Feb 2005 21:23:20 -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.33) id 1D3mY0-0002UC-6O for sipping-emergency@ietf.org; Tue, 22 Feb 2005 21:46:44 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2005 19:37:14 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,108,1107734400"; d="scan'208"; a="228074307:sNHT115473794" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1N2Mfq8018521; Tue, 22 Feb 2005 18:22:42 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA24379; Tue, 22 Feb 2005 18:22:46 -0800 (PST) Message-Id: <4.3.2.7.2.20050215032703.026d6be0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Feb 2005 08:45:50 -0600 To: "Stastny Richard" , "Henning Schulzrinne" From: "James M. Polk" In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4601D81D@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.3 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 23 Feb 2005 05:27:09 -0500 Cc: sipping-emergency@ietf.org Subject: [Ecrit] RE: [Sipping-emergency] Basic Requirements for emergency services 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 X-Spam-Score: 2.3 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Richard I believe only the "identification and routing of the emergency calls" is in scope of this WG; with the rest of the i3 requirements to (really) be dealt with in NENA itself. At 02:46 PM 2/14/2005 +0100, Stastny Richard wrote: >Henning, Chairs, > >Just a question for clarification to the draft >draft-schulzrinne-sipping-emergency-req-01.txt >before I dive into it in detail: > >My understanding is that section 4. Trunk replacement >is out-of-scope in ecrit > >only section 5. End-to-End IP Bases Emergency Calls >is relevant. > >Is this correct? > >Richard > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Saturday, February 12, 2005 6:00 PM > > To: Stastny Richard > > Cc: Marc Linsner; sipping-emergency@ietf.org; Tschofenig Hannes > > Subject: Re: [Sipping-emergency] Basic Requirements for emergency >services > > > > Oops, I meant to link to > > > > >http://www.cs.columbia.edu/sip/drafts/sipping/draft-schulzrinne-sipping- > > emergency-req-01.txt > > > > Henning > > > > Henning Schulzrinne wrote: > > > I'm curious as to the relation of these requirements to the ones in >an > > > earlier draft: > > > > > > >http://www.cs.columbia.edu/sip/drafts/sipping/draft-schulzrinne-sipping- > > emergency-arch-02.txt > >_______________________________________________ >Sipping-emergency mailing list >Sipping-emergency@ietf.org >https://www1.ietf.org/mailman/listinfo/sipping-emergency cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit