[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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)?

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?  

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.

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?

3. <Comment, also not ecrit>  We will have to add someplace to put a JIS
code.  We have the other fields.

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.

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?

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?

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?

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?

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? 

> -----Original Message-----
> From: sipping-emergency-bounces at ietf.org [mailto:sipping-emergency-
> bounces at ietf.org] On Behalf Of Motoharu Kawanishi/????
> Sent: Wednesday, February 16, 2005 6:49 AM
> To: sipping-emergency at 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 refrected to the functional requirements where
> appropreate.
> 
> 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 at oki.com
> 
> 
> _______________________________________________
> Sipping-emergency mailing list
> Sipping-emergency at ietf.org
> https://www1.ietf.org/mailman/listinfo/sipping-emergency
> 




_______________________________________________
Sipping-emergency mailing list
Sipping-emergency at ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency