[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] PSAP Call Backs
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.
regards
Keith
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> 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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> 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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> 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
> >>Ecrit at ietf.org
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >
> >_______________________________________________
> >Ecrit mailing list
> >Ecrit at ietf.org
> >https://www.ietf.org/mailman/listinfo/ecrit
> >
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit