Subject: RE: [ECRIT]: Caller Identity requirements: replacement text for emptysection in ECRIT req doc.

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 18 Oct 2005 20:40:10 -0500

Hi Roger,

With req 2, I am not sure how you declare that something must be
supported, but at the same time say that it is out of scope. I am also
not sure that I understand how this is a routing requirement. Will req 1
suffice with what you are trying to achieve?

Req 3, is it the responsibility of the ECRIT protocol to provide the
capability to make the association, or is it the responsibility of the
ECRIT protocol to support the transport of parameters such that some
other node may be able to make this association. To my mind there is a
difference.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Roger Marshall
> Sent: Wednesday, 19 October 2005 9:42 AM
> To: ECRIT
> Subject: [ECRIT]: Caller Identity requirements: replacement text for
> emptysection in ECRIT req doc.
> 
> All:
> There has been a placeholder within the ECRIT requirements draft
titled,
> "Emergency Caller Identification".  Since this section was requested
> back on 8/09, I guess I'll take a crack at submitting some (proposed)
> text for it (below):
> 
> 
> "When a person places an emergency call to a PSAP, existing emergency
> service messaging conveys associated caller information in addition to
> receiving the caller's voice.  This additional information typically
> consists of a call-back number, and the caller's location (referred to
> as ANI and ALI, for North American systems)."
> 
> "Some systems use the received callback number to perform a identity
> lookup via a database lookup service, and then use the location
> information received to help verify the caller's identity presented
both
> via voice, as well as the external data presented from the identity
> database query.  These external mechanisms are important for many
> reasons, including helping callers who cannot, or will not speak, to
> prevent false information from impeding appropriate dispatch
> instructions and procedures, and ultimately to enable faster response
in
> the offering of help."
> 
> "IP-based emergency systems in the future may be able to offer even
more
> information about the caller, to help establish personal identity, but
> also for today, for near-term implementations, need to provide the
same
> minimum level of identitifcation support as in the existing legacy
> emergency systems."
> 
> "Req1: A "Call-back" number MUST be supplied within the call signaling
> for each emergency call sent to the PSAP.  The ECRIT protocol may
> provide this number in the form of a tel:uri, a sip:uri, or an
> IP-Address."
> 
> "Req2: The ECRIT protocol MUST support the ability for the PSAP to
> perform caller identity lookup based on the tel:uri, sip:uri, or IP
> Address provided with call signaling.  (A variety of competing
directory
> lookup services may exist, but is not discussed in detail here, as it
is
> out of scope of this document.)"
> 
> "Req3:  The ECRIT protocol MUST support the ability to associate
> individual call location information with external caller identity
> records."
> 
> 
> 
> I have attempted to steer clear of obvious privacy
concerns/objections,
> modeling this after what's available today in ES, but there are more
> details that some may want to tease out.
> 
> Comments?
> 
> Roger Marshall.
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 19 Oct 2005 11:42:50 -0400

Roger,

In Req-1, you mention an IP address as a call-back number.  Is there
some assumed higher level protocol that will be used with that IP
address?  What will the PSAP operator do with it?

Mike

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Roger Marshall
> Sent: Tuesday, October 18, 2005 7:42 PM
> To: ECRIT
> Subject: [ECRIT]: Caller Identity requirements: replacement 
> text for emptysection in ECRIT req doc. 
> 
> All:
> There has been a placeholder within the ECRIT requirements 
> draft titled, "Emergency Caller Identification".  Since this 
> section was requested back on 8/09, I guess I'll take a crack 
> at submitting some (proposed) text for it (below):
> 
> 
> "When a person places an emergency call to a PSAP, existing 
> emergency service messaging conveys associated caller 
> information in addition to receiving the caller's voice.  
> This additional information typically consists of a call-back 
> number, and the caller's location (referred to as ANI and 
> ALI, for North American systems)."
> 
> "Some systems use the received callback number to perform a 
> identity lookup via a database lookup service, and then use 
> the location information received to help verify the caller's 
> identity presented both via voice, as well as the external 
> data presented from the identity database query.  These 
> external mechanisms are important for many reasons, including 
> helping callers who cannot, or will not speak, to prevent 
> false information from impeding appropriate dispatch 
> instructions and procedures, and ultimately to enable faster 
> response in the offering of help."
> 
> "IP-based emergency systems in the future may be able to 
> offer even more information about the caller, to help 
> establish personal identity, but also for today, for 
> near-term implementations, need to provide the same minimum 
> level of identitifcation support as in the existing legacy 
> emergency systems."
> 
> "Req1: A "Call-back" number MUST be supplied within the call 
> signaling for each emergency call sent to the PSAP.  The 
> ECRIT protocol may provide this number in the form of a 
> tel:uri, a sip:uri, or an IP-Address."
> 
> "Req2: The ECRIT protocol MUST support the ability for the 
> PSAP to perform caller identity lookup based on the tel:uri, 
> sip:uri, or IP Address provided with call signaling.  (A 
> variety of competing directory lookup services may exist, but 
> is not discussed in detail here, as it is out of scope of 
> this document.)"
> 
> "Req3:  The ECRIT protocol MUST support the ability to 
> associate individual call location information with external 
> caller identity records."
> 
> 
> 
> concerns/objections, modeling this after what's available 
> today in ES, but there are more details that some may want to 
> tease out.
> 
> Comments?
> 
> Roger Marshall.
>

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 19 Oct 2005 10:11:05 -0700

James:
See responses in-line. 

>From: Winterbottom, James [mailto:[email-masked]] 
>Sent: Tuesday, October 18, 2005 6:40 PM
>To: Roger Marshall; ECRIT
>Subject: RE: [ECRIT]: Caller Identity requirements: 
>replacement text for emptysection in ECRIT req doc. 
>
>Hi Roger,
>
>With req 2, I am not sure how you declare that something must 
>be supported, but at the same time say that it is out of 
>scope. I am also not sure that I understand how this is a 
>routing requirement. Will req 1 suffice with what you are 
>trying to achieve?

Yes, I think req-1 ought to suffice.  Therefore req-2 deleted.

>
>Req 3, is it the responsibility of the ECRIT protocol to 
>provide the capability to make the association, or is it the 
>responsibility of the ECRIT protocol to support the transport 
>of parameters such that some other node may be able to make 
>this association. To my mind there is a difference.

I agree.  I have rewritten req-3 as follows:

"Req3:  The ECRIT protocol MUST support the transport of parameters 
which can be used by PSAPs to associate individual call location 
information with external caller identity records."

Does this work?

Roger Marshall.

>On Behalf
>emergency 
>signaling

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 19 Oct 2005 13:36:02 -0400

Yes, that helps.  It could also be an IP address embedded in a sip URI
in the form of a Contact, but I didn't want to presume too much.  I
don't know if the call-back types need to be enumerated here or these
are just used as examples.

Mike

> From: Roger Marshall [mailto:[email-masked]] 
> Sent: Wednesday, October 19, 2005 1:09 PM
> To: Michael Hammer (mhammer); ECRIT
> Michael:
> It seems that the PSAP needs to know which type of service 
> (application) that the caller could be used to contact the 
> call initiator.  For example, if the ECRIT protocol provided 
> an IP Address as the "call-back"
> number, the protocol SHOULD (or MUST?) provide an indicator 
> as to which application is to be used to target this IP 
> Address (e.g. IM, email, VoIP, etc.).
> 
> Does this get close to addressing the question you're asking?
> 
> Roger Marshall.
> 
> >From: Michael Hammer (mhammer) [mailto:[email-masked]]
> >Sent: Wednesday, October 19, 2005 8:43 AM
> >> Of Roger Marshall
> >> titled, "Emergency Caller Identification".  Since this section was 
> >> requested back on 8/09, I guess I'll take a crack at 
> submitting some
> >> (proposed) text for it (below):
> >> 
> >> 
> >> receiving the caller's voice.
> >> This additional information typically consists of a
> >call-back number,
> >> and the caller's location (referred to as ANI and ALI, for North 
> >> American systems)."
> >> 
> >> both via voice, as well as the external data presented from the 
> >> identity database query.  These external mechanisms are
> >important for
> >> many reasons, including helping callers who cannot, or will
> >not speak,
> >> to prevent false information from impeding appropriate dispatch 
> offer even 
> >> more information about the caller, to help establish personal 
> >> identity, but also for today, for near-term 
> implementations, need to 
> >> provide the same minimum level of identitifcation support 
> as in the 
> >> existing legacy emergency systems."
> >> 
> >> directory lookup services may exist, but is not discussed 
> in detail 
> >> here, as it is out of scope of this document.)"
> >> 
> >today in ES,
> >> but there are more details that some may want to tease out.
> >> 
> >> Comments?
> >> 
> >> Roger Marshall.
> >>