Re: [Ecrit] PSAP Call Backs

["Brian Rosen" <[e-mail]>]

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