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

Re: [Ecrit] PSAP Call Backs

At 12:28 PM 1/3/2009, Hannes Tschofenig wrote:

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


MAY means not prohibited, and can be specified in a future doc.
Regarding your questions A and B, I'm not a fan of using an RP namespace to do callbacks, given that I don't believe we can be sure or the signaling path in the reverse direction (i.e., from the PSAP back to the original UAC caller), so I'm not sure how we can believe any marking indication is going to work even 50% of the time (if that).
Remember, you personally don't trust the UAC to set a correct esnet namespace, so how can you trust the UAC to correctly receive this same esnet namespace and do the right things about that SIP INVITE?
I believe the same applies to the sos-parameter draft. How do we know it'll be only used during emergency callback, and not used to prevent call forwarding or otherwise disable features the UA endpoint normally wants applied to any inbound call attempt? 



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


-bounces at ietf.org

At 12:28 PM 1/3/2009, Hannes Tschofenig wrote:

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


MAY means not prohibited, and can be specified in a future doc.
Regarding your questions A and B, I'm not a fan of using an RP namespace to do callbacks, given that I don't believe we can be sure or the signaling path in the reverse direction (i.e., from the PSAP back to the original UAC caller), so I'm not sure how we can believe any marking indication is going to work even 50% of the time (if that).
Remember, you personally don't trust the UAC to set a correct esnet namespace, so how can you trust the UAC to correctly receive this same esnet namespace and do the right things about that SIP INVITE?
I believe the same applies to the sos-parameter draft. How do we know it'll be only used during emergency callback, and not used to prevent call forwarding or otherwise disable features the UA endpoint normally wants applied to any inbound call attempt? 



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