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

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Oct 2005 06:52:31 -0500

I am happy with these Roger..

Thanks
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Roger Marshall
> Sent: Thursday, 20 October 2005 3:56 AM
> To: Michael Hammer (mhammer); ECRIT
> Subject: RE: [ECRIT]: Caller Identity requirements: replacement text
> foremptysection in ECRIT req doc.
> 
> Michael:
> Henning suggests using SIP:URI alone.  I like this, since it makes it
> avoids the issue of IP Address specifically, (and yet doesn't preclude
> it, since I've written it as "should be in the form of a sip:uri".
> 
> Given no objection, I've deleted my orig. req-2 (req-1 covers it), and
> for 1 & 3, we now have:
> 
> Req1.  call-back uri. Req1: A "call-back" number MUST
> be supplied within the call signaling for each emergency call sent to
> the
> PSAP.  The ECRIT protocol should provide this number in the form of a
> sip:uri.
> 
> Req3.  call identity parameters. 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.
> 
> 
> Roger Marshall.
> 
> >-----Original Message-----
> >From: Michael Hammer (mhammer) [mailto:[email-masked]]
> >Sent: Wednesday, October 19, 2005 10:36 AM
> >To: Roger Marshall; ECRIT
> >Subject: RE: [ECRIT]: Caller Identity requirements:
> >replacement text for emptysection in ECRIT req doc.
> >
> >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
> >
> >> -----Original Message-----
> >> From: Roger Marshall [mailto:[email-masked]]
> >> Sent: Wednesday, October 19, 2005 1:09 PM
> >> To: Michael Hammer (mhammer); ECRIT
> >> Subject: RE: [ECRIT]: Caller Identity requirements:
> >> replacement text for emptysection in ECRIT req doc.
> >>
> >> 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.
> >>
> >> >-----Original Message-----
> >> >From: Michael Hammer (mhammer) [mailto:[email-masked]]
> >> >Sent: Wednesday, October 19, 2005 8:43 AM
> >> >To: Roger Marshall; ECRIT
> >> >Subject: RE: [ECRIT]: Caller Identity requirements:
> >> >replacement text for emptysection in ECRIT req doc.
> >> >
> >> >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
> >> >
> >> >> -----Original Message-----
> >> >> 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."
> >> >>
> >> >>
> >> >>
> >> >> 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
> >> >>
> >> >
> >>
> >
> 
> _______________________________________________
> 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: "Tim Dunn" <[email-masked]>
Date: Fri, 21 Oct 2005 09:33:33 -0600

That's all I believe the proposed requirement was stating, and the very
direct point I've been attempting to make:  Location and callback must be
provided in the call process somewhere.  

My question is where?  Why not here? (And I disagree that it is out of scope
for ECRIT based on my earlier arguments).

Tim

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, October 21, 2005 7:25 AM
To: Tim DUNN
Cc: [email-masked]
Subject: Re: [ECRIT]: Caller Identity requirements: replacement text

Tim DUNN wrote:
> The PSAP needs is a location and a call back.  Not providing both is a 
> reduction in existing capabilities in place for circuit switched and 
> mobile 911 calls.  Both need to be accounted for somewhere in this 
> overall set of requirements/architecture.
> 

It's pretty simple: The call setup request reaching the PSAP provides 
call back information and location information, in-band. I agree with 
the need for an architecture document; I've written (long-expired) 
versions of something approximating those.

Henning