Subject: [Ecrit] RE: [Sipping-emergency] draft-arai-ecrit-japan-req-00.txt

From: [email-masked]
Date: Fri, 18 Feb 2005 00:06:21 +0900

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
[email-masked]

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, February 17, 2005 12:16 AM
> To: 'Motoharu Kawanishi'; [email-masked]
> 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;
<add_area>
  <add_post>1000000</add_post>
  <add_code>13101000000</add_code>
  .....
  <add_others>.....</add_others>
</add_area>

>
> 3. <Comment, also not ecrit>  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. <Comment, maybe not ecrit, but if not, where?> 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. <maybe not ecrit, but...>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: [email-masked] [mailto:sipping-emergency-
> > [email-masked]] On Behalf Of Motoharu Kawanishi/????
> > Sent: Wednesday, February 16, 2005 6:49 AM
> > To: [email-masked]
> > 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
> > [email-masked]
> >
> >
> > _______________________________________________
> > Sipping-emergency mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sipping-emergency
> >

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit