Re: [Ecrit] PSAP Call Backs

["Milan Patel" <[e-mail]>]

Keith's suggestions sound sensible to me.
Regards,
Milan 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of James M. Polk
Sent: 05 January 2009 19:20
To: DRAGE, Keith (Keith); Brian Rosen; 'Hannes Tschofenig'; 'Tschofenig,
Hannes (NSN - FI/Espoo)'; 'ECRIT'
Subject: Re: [Ecrit] PSAP Call Backs

At 01:07 PM 1/5/2009, DRAGE, Keith (Keith) wrote:
>I think I agree with what Brian is saying here, but I would turn the 
>statement round.
>
>We should decide what special behaviours callback calls required, and 
>then identify the appropriate means of signalling to generate that 
>behaviour.
>
>That means if we identify that callback calls need special treatment in

>the network, then RPH may be the way to do it. If we want to override 
>incoming call bahaviour in the destination UA, then we find an 
>appropriate way of doing that (along with a security solution to 
>prevent misuse.
>
>I though we had decided to deal with callback issues with a separate 
>requirements draft. As such I would support taking out callback text 
>from all documents at the moment, not with the idea that that might not

>be the solution, but that we come up with a complete package of 
>solutions in the future.

I think this is appropriate


>regards
>
>Keith
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Brian Rosen
> > Sent: Monday, January 05, 2009 3:47 PM
> > To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes (NSN -

> > FI/Espoo)'; 'ECRIT'
> > Subject: Re: [Ecrit] PSAP Call Backs
> >
> > I would have said that we decide if callbacks should have special 
> > treatment of any kind.
> >
> > If we decide that they should, then we decide how we will mark them,

> > and then what the behavior is for that marking.
> >
> > Please do not confuse the resource priority marking and behavior 
> > with this discussion.  As with the emergency call marking 
> > (urn:service:sos in Route), and the associated behaviors in 
> > PhoneBCP, the RPH is an independent marking and behavior 
> > specification.  If we mark call backs, it won't be with RPH.  A 
> > callback MAY also have an RPH marking, and there could be behavior 
> > associated with that with respect to priority handling within a 
> > network.
> > Similarly, the packets of a callback could have a DiffServ marking, 
> > and behavior associates with that marking within a network.
> >
> > I think we should have a call back marking, and we should specify 
> > behaviors for that marking.
> >
> > Brian
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Hannes Tschofenig
> > Sent: Saturday, January 03, 2009 1:29 PM
> > To: 'James M. Polk'; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
> > Subject: Re: [Ecrit] PSAP Call Backs
> >
> > There are two different aspects:
> >
> > A) A decision that decides whether a call back has to be marked or 
> > not
> >
> > B) When the decision is made that is has to be marked then how the 
> > marking is going to look like.
> >
> > Regarding (A): This might be a policy issues. Some PSAPs might want 
> > to use this indication and others might not.
> > Nothing we have to worry about.
> >
> > Regarding (B): Here there needs to be one way todo the marking -- 
> > not multiple ways. It would just increase the implementation 
> > complexity, the number of error cases and interop problems.
> >
> > I am not sure to what your "MAY" statement refers to -- to
> > (A) or (B).
> >
> > Ciao
> > Hannes
> >
> >
> > >-----Original Message-----
> > >From: [e-mail] [mailto:[e-mail]]
> > On Behalf
> > >Of James M. Polk
> > >Sent: 02 January, 2009 22:15
> > >To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
> > >Subject: Re: [Ecrit] PSAP Call Backs
> > >
> > >At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> > >>Hi all,
> > >>
> > >>In the last few months we have seen increased interest in the
> > >topic of
> > >>PSAP call backs.
> > >>
> > >>Section 10 of
> > http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06
> > >>says:
> > >>
> > >>    SP-36 Call backs to the Contact: header URI recieved within 30
> > >>    minutes of an emergency call must reach the device
> > >regardless of call
> > >>    features or services that would normally cause the call
> > >to be routed
> > >>    to some other entity.
> > >>
> > >>More importantly, Section 13 says:
> > >>
> > >>    ED-73 Call backs SHOULD be determined by retaining the
> > >domain of the
> > >>    PSAP which answers an outgoing emergency call and
> > instantiating a
> > >>    timer which starts when the call is terminated.  If a call is
> > >>    received from the same domain and within the timer
> > period, sent to
> > >>    the Contact: or AoR used in the emergency call, it should
> > >be assumed
> > >>    to be a call back.  The suggested timer period is 5 minutes.
> > >>
> > >>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt
> > >>proposed another solution based on marking the callback using
> > >the "sos"
> > >>URI parameter.
> > >>
> > >>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc
> > >y-rph-nam
> > >>e space/ proposes another solution by utilizing the
> > Resource Priority
> > >>Header.
> > >
> > >within the namespace ID, the total thought (for PSAP
> > callback) is here:
> > >
> > >    This namespace will also be used
> > >   for communications between emergency authorities, and MAY be
used
> > >   for emergency authorities calling public citizens. An example of
> > >   the later is a PSAP operator calling back someone who previously
> > >   called 9111/112/999 and the communication was terminated before
it
> > >   should have been (in the operator's judgment).
> > >
> > >Notice this is all based on the MAY in the first sentence,
> > therefore it
> > >can be considered an afterthought, i.e., something that can be 
> > >utilized/specified later.
> > >
> > >the "sos" parameter solution is more definitive, yet it
> > should identify
> > >a priority marking (in SIP), given that there is already a
> > defined way
> > >to do that in SIP, and a second way shouldn't be defined
> > >- as it will only lead to interoperability issues.
> > >
> > >
> > >>So, here are my high-level questions:
> > >>
> > >>A) Do you think that you understand the requirements that lead to 
> > >>a need for a technical solution?
> > >>
> > >>B) Do you believe that more work beyond the mechanism described in

> > >>Phone BCP is needed?
> > >>
> > >>Ciao
> > >>Hannes
> > >>_______________________________________________
> > >>Ecrit mailing list
> > >>[e-mail]
> > >>https://www.ietf.org/mailman/listinfo/ecrit
> > >
> > >_______________________________________________
> > >Ecrit mailing list
> > >[e-mail]
> > >https://www.ietf.org/mailman/listinfo/ecrit
> > >
> >
> > _______________________________________________
> > Ecrit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ecrit
> >
> > _______________________________________________
> > Ecrit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ecrit
> >

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit