Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 16 May 2006 10:33:26 -0400

BTW, is the URN intended to stay with the message all the way to the UAS
(PSAP)?

If so, how is that accomplished?

Also, if there are B2BUA (e.g. SBC) along the way, how is this
accomplished?  
I don't think B2BUA behavior is specified anywhere.

If not, nevermind.

Mike 

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]] 
> Sent: Tuesday, May 16, 2006 9:42 AM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 
> Child helpline
> 
> My starting point is ECRIT's requirement, I thought. 
> Originally that was for some way to mark a call to indicate 
> that it was an emergency call. I just finished reading the 
> first part of section 6 of the requirements document and can 
> hardly recognize it.
> 
> I can't quite understand the current intention. Is it:
> 
> (a) that the client passes the identifier in the mapping 
> request and gets back a URI appropriate to that identifier, 
> so that the mapping database becomes more general-purpose 
> than just to locate PSAPs; or
> 
> (b) that the mapping response includes an identifier to be 
> appended to the call; or
> 
> (c) something else?
> 
> Henning Schulzrinne wrote:
> > Service URNs indeed serve as identification, both in the end system 
> > and in points along the way to the destination. My goal is to hard- 
> > code as little as possible, so that we can adjust the system over 
> > time, without changing end systems and new protocol specs.
> > 
> > The basic idea is that all entities along the way can look up 
> > identifiers and determine
> > 
> > - what users should dial if they have a twelve-button phone
> > - where to route the call (based on the identifier and location)
> > - whether the call should contain location information
> > - whether the location information should be (or can be) end-to-end 
> > encrypted
> > 
> > Not all calls may end up in a PSAP (see poison control).
> > 
> > On May 16, 2006, at 9:09 AM, Tom-PT Taylor wrote:
> > 
> >> Let's back off a moment and consider what this is for. The 
> purpose of 
> >> the service URN, as far as ECRIT is concerned, is to provide an 
> >> unambiguous indication that the call should be routed to a PSAP.
> >> It's all very well to have attributes whose treatment is 
> defined by 
> >> local policy, but what about the proxy half-way around the 
> world that 
> >> has to recognize an emergency call?
> > 
> > 
> > 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 16 May 2006 10:59:10 -0400

Jonathan proposed that it be put in a Route header.  It would stay in that
Route header all the way to the PSAP.  It may at some point, also be in a
To: (but often it wouldn't; you would have a dialstring there), it may occur
in a Request-URI (specifically, between the element that recognized the
dialstring and turned it into the service urn and the element that does the
LoST dip if those elements are different).

Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2006 10:33 AM
To: Tom-PT Taylor; Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline

If not, nevermind.

Mike