Subject: Re: [Ecrit] call marking

From: <[email-masked]>
Date: Thu, 4 Jan 2007 20:51:37 -0500

Would this also playinto priority access? For example, the London Bombing After Action report when EVERYONE tried to make a call. (?) Or - during a transfer from a PSAP (or third party provider TO a PSAP) when they have a bonafide emergency and want the recipient to know that the incoming call IS truly an emergency. ? The London example is something that fits here I think ... If u want a real world example. 
Sent from JH/Blackberry 

----- Original Message -----
From: Brian Rosen <[email-masked]>
To: 'Henning Schulzrinne' <[email-masked]>; 'Andrew Newton' <[email-masked]>
Cc: 'ECRIT' <[email-masked]>
Sent: Thu Jan 04 20:42:40 2007
Subject: RE: [Ecrit] call marking

Well, let me cite some reasons for marking:
1. Actual routing; knowing how to route the call, especially if there is
more than one element involved.  I think this is the big one.  We need the
service URN to stay around even after we have done one level of LoST
routing.  This includes things like having the call go to the E-CSCF in the
visited network instead of anything in the home network, for example.
2. Allowing the UAS, and a proxy on the route, to know what service is being
requested
3. Invoking emergency call specific behavior, like adding location
4. Priority handling of signaling and media within the network at all levels
5. Disabling of services like call waiting that are provided by the network
6. Charging issues or lack thereof
7. Processing of the call at all (some systems will allow emergency calls,
but no other forms of call), like a cellphone with no service plan.
8. Assistance in detecting theft of service when fraudulent attempts to get
the above are attempted without a genuine service call

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, January 04, 2007 8:24 PM
> To: Andrew Newton
> Cc: Brian Rosen; 'ECRIT'
> Subject: Re: [Ecrit] call marking
> 
> I don't think my basic question has been answered: what's the purpose
> of marking? Who interprets these markings for what purpose?
> 
> Adding random strings to protocols in the hope that they might be
> useful for somebody somewhere for something isn't too useful.
> 
> (The URI/routing mechanisms are simply that - routing mechanisms.
> They obviously work just as well for urn:service:pizza as for
> emergency.)
> 
> On Jan 4, 2007, at 8:21 PM, Andrew Newton wrote:
> 
> >
> > On Jan 4, 2007, at 7:54 PM, Brian Rosen wrote:
> >
> >>  Existing mechanisms don't use sos URNs and they don't need
> >> markings.   They have their own conventions.
> >
> > Good, then I'd hope you would agree the re-purposing something they
> > do use, the request-URI, for call marking is asking for
> > collisions.  Finding some other mechanism means that the logic is
> > the same regardless of the path, which is likely to result in
> > greater interoperability and fewer mistakes.
> >
> >> Carrying the geolocation header is probably good all the way,
> >> again assuming
> >> implementations follow 3261 rules on ignoring headers they don't
> >> understand.
> >> I am more than a little worried about multipart in this case
> >> however.  If
> >> the existing systems don't implement multipart, they get hosed
> >> pretty badly.
> >
> > I've always intended to do LbyR here.
> >
> > -andy
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
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: Thu, 4 Jan 2007 20:58:08 -0500

This is yet another issue, which is congestion control.  That's not an ecrit
issue.  We're working that issue now in NENA.

Generally, everyone that called considered the call to BE an emergency call.
Furthermore, there were lots of side incidents that actually ARE emergency
calls.  The caller doesn't know what the PSAP knows yet.  It may be
duplicative of information they already have, it may not.

The only way to deal with this is to answer all the calls, and let a human
decide what to do.  We can make that work.  I'll send you a idea I've
proposed to NENA if you wish.  Again, it's not (currently) an ecrit issue.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 04, 2007 8:52 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Would this also playinto priority access? For example, the London Bombing
> After Action report when EVERYONE tried to make a call. (?) Or - during a
> transfer from a PSAP (or third party provider TO a PSAP) when they have a
> bonafide emergency and want the recipient to know that the incoming call
> IS truly an emergency. ? The London example is something that fits here I
> think ... If u want a real world example.
> Sent from JH/Blackberry
>