[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] PSAP Call Backs

At 09:47 AM 1/5/2009, Brian Rosen wrote:
>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 (again) agree with all of the above (which has been said over and 
over again).


>I think we should have a call back marking, and we should specify behaviors
>for that marking.

I'm on the fence about callback marking, mostly because I believe 
there is an unpredictable path back to the original UAC, and even if 
marked, do we know the receiving proxies or UAC will have any 
awareness of this marking?  If not, why have this discussion and 
complexity attempting to elicit a marking and associated behavior 
that falls on deaf ears?


>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) i Format="flowed"
Sender: ecrit-bounces at ietf.org
Errors-To: ecrit-bounces at ietf.org

At 09:47 AM 1/5/2009, Brian Rosen wrote:
>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 (again) agree with all of the above (which has been said over and 
over again).


>I think we should have a call back marking, and we should specify behaviors
>for that marking.

I'm on the fence about callback marking, mostly because I believe 
there is an unpredictable path back to the original UAC, and even if 
marked, do we know the receiving proxies or UAC will have any 
awareness of this marking?  If not, why have this discussion and 
complexity attempting to elicit a marking and associated behavior 
that falls on deaf ears?


>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:
s 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


> >
> >    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