Subject: [Ecrit] New Comments on ECRIT Reqs ID

From: "James M. Polk" <[email-masked]>
Date: Sun, 31 Jul 2005 11:59:30 -0500

All

I have the following comments on the ECRIT Requirements -01 ID:

Intro section, 5th pragraph:  I don't understand this 
"identified/identifier" language. The device making the emergency call 
doesn't have to identify anything to it, but the device MUST make the 
emergency message identifiable to the next SIP element (to treat that 
message special). This isn't what's stated here.

Intro section, 7th pragraph:  I don't believe it is achievable to identify 
who is making the call attempt *in the protocol*.  I can easily use Marc's 
SIP UA to call 911. The PSAP will think Marc is in trouble, right? The text 
here needs to be clarified for what it really wants.

Intro section, 7th pragraph:  I believe stating that "....most 
jurisdictions require something by law..." means there should be a 
reference *here* to that or those laws to justify this claim.

Intro section, 8th pragraph should be rewritten to the following:
"Emergency calls need to identify the location of the calling 
device  (Section 5).  Caller location needs to be identified for two 
purposes, namely to route the call set-up messages to the appropriate PSAP 
and to display the caller's location to the call taker to simplify 
dispatching emergency assistance to the correct location."

Section 2, 2nd paragraph: "implement able" should be one word

Section 2. I thought we agreed "AIP" was to change back to "IAP" to 
maintain consistency with "ISP".

Section 2. ESRP - this definition seems to miss what it's really about: 
providing the correct Request-URI for either the appropriate PSAP, or of a 
next hop SIP element that will do this "mapping function" right.

Section 2. ESRP - stating the ESRP would typically be a SIP Proxy or a 
B2BUA is redundant, because a B2BUA is an instance of a SIP Proxy.

Section 2. "Location Key" - if we're going to have location by-reference, 
then this is a URI and not a key, and this document should start syaing as 
much.

R6. needs to add  "...once the URI is delivered to the device, complying 
with normal 3261 operations MUST be all that is necessary for that device 
to communicate with the PSAP."

A3, second sentence: instead of "...routing to a PSAP.", it needs to be 
"...routing only to a PSAP."

A6. What does this requirement have to do with Emergency Addressing? R6 
above should cover this one regardless.

Section 5. The three definitions (UA-inserted and UA-referenced and 
Proxy-inserted) are not mentioned again with this section, therefore should 
be removed.

Section 6, second paragraph. I believe the contention that PSAP boundaries 
"change" often needs to be substantiated in some way. How often does this 
really occur? Once a year at most? This synchronization cannot therefore be 
mentioned like something to be afraid of

I1. the must needs to be capitalized, MUST

I13 - "proferred"? do you mean "preferred"?

I3 and I31 appear to have some overlap with the URI being to a PSAP or 
another ESRP.

I39 is contradictory to prior agreement that a call set-up, once started, 
doesn't get re-routed with a change in UAC location - but that it's up to 
the PSAP to receive this UPDATE in SIP to then transfer the call to the now 
correct PSAP.

In SIP, this would cause the UAC to send a CANCEL to the first INVITE and 
generate a new INVITE, costing time from a live operator.

"Reachback" can be up to 15 seconds into the call.... surely the SIP call 
is expected to be "up" by then, and no one expects the UAC to INVITE to a 
new PSAP, or do they here?

D9 doesn't make clear where this mandatory-to-implement protocol is to be 
implemented.

I'm not sure what the motivation is for SD2, SD3, SD4 or SD5, or where this 
is expected to be conveyed? Each of these requirements need to be clearer 
or deleted.

Noticeably less comments this version, but I'm also noticing there is not a 
lot of synergies with the SIP Location Conveyance doc in a number of areas.

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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