the same way that the Route header sos urn is
not a good choice for a resource priority mark.
Brian
-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
James M. Polk
Sent: Friday, January 02, 2009 3:15 PM
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-emergency-rph-name
>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