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
>