Subject: Re: [Sipping] [Fwd: I-D ACTION:draft-taylor-sipping-emerg-scen-00.txt]

From: [email-masked]
Date: Fri, 17 Oct 2003 13:15:12 +0100

Comments on draft-taylor-sipping-emerg-scen-00.txt, based on the information sent to Tom about the UK emergency service (999).

1. Abstract: rather than "would be helpful" in the major finding, it would be better to say: " The major finding from the point of view of SIP standardization is it is essential in a number of scenarios (and helpful for all) if a location header field could be added either by the SIP phone or by a proxy to indicate the location of the phone in a machine-readable way." The UK uses automated location information at a call centre to determine the "local" emergency service, and the emergency service uses the information to dispatch the emergency response.

2. In section 2 (definitions), the definition provided of an ECC is USA specific. Please add, after "(police, fire department, medical aid) the words "either directly or by connection to a separate centre" - this will cover both cases.

3. In Section 3.1, System Components, the UK is described as having a system similar to the USA. It is not, it is radically different and more similar to the Australian system. Please modify, by deleting "and Britain" after ".  In other       places, such as North America ", and insert "and the UK" after " such as Australia " a couple of lines higher.

4. Section 3.2 "System Requirements" under "(2) Call processing entities"       add to the end of the parenthesised sentence " directly or by further onward connection to a service-specific despatching centre " - so that it reads "(i.e., one which can dispatch emergency service resources to the caller's location)." 

5. Again in Section 3.2, under (£) and (4), the document reads as though it is placing requirements on the PSTN, rather than defining requirements for SIP. The PSTN is unlikely to change! This part needs rewording as follows:
(3)   The telephone network should be supplied-with, or enabled to supply, a calling party number or other unique geographic indicator, that can serve as a key to the mapping database. 
(4)   The caller's location needs to be supplied during call set-up, or by being keyed by calling party number or other unique identifier, is available in the mapping database.  In this document this is assumed to happen as a configuration step in advance of the call. 

6. in (5) it states:
(5)   At least in some jurisdictions, it is required that the ECC 
      call taker can stay in touch with the caller, even though the 
      telephone set goes on hook for an intervening period. Alternatively 
      the ECC call taker must be given a callback number -- one which can 
      be dialled to reach the original caller. 
The second sentence is a different requirement. Consider the scenario where someone is attacked, manages to reach a phone and dial the emergency number, it is answered, but before being able to pass any information other than 'I am being attacked', the attacker causes the phone to go on hook for long enough to clear the call. As the attacker continues the phone goes off hook again - thus effectively preventing any call back. A callback number is more usually used when the emergency services response is unable to find the location of the incident and needs to contact the original reporter in order to get directions. I suggest a separate point (e.g. (8), saying:
(8) The telephone network should be supplied-with, or enabled to supply, a number which enables the ECC to callback the SIP phone that made the original emergency call.

7. In (7) of the system requirements, you do not really place any real requirements on SIP. The caller should be accountable, but how? Suggest you add to the existing text of (7):
"In particular callers should not be able to withold calling number or location information when using emergency codes and have call records stored for at least initial and final steps in call path within public call processing entities."

8. Section 3.3: Legacy system operation. The first paragraph would benefit from some additional clarification on how the system (at least in the UK) operates. I suggest the following addition as the last sentence of the first paragraph of 3.3:
"This is presented to the emergency call taker to speed-up call handling and response times on all calls, and to be of especially important assistance in cases where the caller is unable to provide the information. (This is now part of the regulatory regime for emergency calls in the US and European Community)."

9. The second paragraph of 3.3 appears to be a description of the UK system, and I suggest the following as that paragraph:
A special arrangement at the switch serving the ECC may allow the emergency call taker to hold open the voice path back to the caller as long as necessary, even if the caller goes on-hook to help establish if the call is genuine. Note that this functionality is not supported for ISDN. 

10. The third paragraph, beginning "where this arrangement does not apply", delete "where this arrangement does not apply" and replace with "For further checks after call connection, and when it is not possible to hold the line" (a better description).

11. The last paragraph of 3.3 would be more helpful if we describe the configuration data the PSTN uses in their switches, and why:
"In the legacy network, PSTN service providers are responsible for maintaining the ECC mapping database and, of course, the routing information and Calling Party Number information by configuration of data in their switches based on knowing call's originating location.  Updates are required every time the relationship between incoming circuit, the calling number assigned to that circuit, and the location of the terminal at the other end of that circuit changes.  It can typically take a day to put through a change in the ECC mapping database, meaning that advance coordination is required to ensure consistency between configuration and reality."

12. Section 4.2.1, penultimate paragraph: rather than PSTN having "to know what number to use", it would be better to say what SIP needs to do: "the PSTN gateway also needs to be provided with a callback number to use

13. In 4.3.2, last bullet, beginning "The PSTN gateway is responsible for ...", you seem to be placing requirements on the PSTN gateway. The PSTN gateway can only act on the information it receives... Suggest adding "(based on information from the SIP network)" after "a called party number on the PSTN side".

14. In the conclusion, I suggest that "The ability to signal that location in SIP would be helpful" is strengthened by adding "in all cases and essential in a number of scenarios."

15. In 5. Conclusions, before the paragraph beginning "Finally ...", I suggest a new paragraph that states:
"There is now an urgency to arrive at emergency call standards with use of VoIP growing and the potential for existing implementations to result in problems and delays in organising responses for ECCs."

16. In 6. Security Considerations, it may be helpful to add to the first bullet as follows:
abuse of the service (i.e., use to make non-emergency calls); this is of critical importance with hoax, false and accidental calls being more than half the emergency calls received in some countries;

I hope that these comments will help to progress this draft and assist in the development of SIP for this life-saving sevice.

Dick Knight

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Tom Taylor <[email-masked]>
Date: Sun, 26 Oct 2003 21:26:53 -0500

Thanks for your comments, Dick.  I've just submitted a new version 
incorporating your comments, generally verbatim.  I have a couple of 
counter-comments below.

I made sure to add you to the acknowledgements section this time around :-)

[email-masked] wrote:

> 
> Comments on draft-taylor-sipping-emerg-scen-00.txt, based on the
> information sent to Tom about the UK emergency service (999).
> 
...
> 
> 5. Again in Section 3.2, under (£) and (4), the document reads as
> though it is placing requirements on the PSTN, rather than defining
> requirements for SIP. The PSTN is unlikely to change! This part needs
> rewording as follows: (3)   The telephone network should be
> supplied-with, or enabled to supply, a calling party number or other
> unique geographic indicator, that can serve as a key to the mapping
> database. (4)   The caller's location needs to be supplied during
> call set-up, or by being keyed by calling party number or other
> unique identifier, is available in the mapping database.  In this
> document this is assumed to happen as a configuration step in advance
> of the call.

[PTT] I accepted your rewording.  Just a word of explanation for how it 
was: this section in my mind presented the premises upon which the 
emergency call system is built.  You took it to be the requirements 
specifically on the SIP network.  That's a better slant, and more to the 
point of this document.
...
> 
> 12. Section 4.2.1, penultimate paragraph: rather than PSTN having "to
> know what number to use", it would be better to say what SIP needs to
> do: "the PSTN gateway also needs to be provided with a callback
> number to use
> 
> 13. In 4.3.2, last bullet, beginning "The PSTN gateway is responsible
> for ...", you seem to be placing requirements on the PSTN gateway.
> The PSTN gateway can only act on the information it receives...
> Suggest adding "(based on information from the SIP network)" after "a
> called party number on the PSTN side".

[PTT] I viewed the PSTN gateway primarily as a SIP entity.  I accepted 
your rewording, but with some uneasiness: a PSTN gateway which is part 
of the same network as the SIP phone (both in the same company network, 
for example) can have access to information which is not provided 
directly by preceding SIP entities in the call path.  Your wording 
applies if the PSTN gateway is in a different administrative domain from 
the SIP phone.
...
> 
> 15. In 5. Conclusions, before the paragraph beginning "Finally ...",
> I suggest a new paragraph that states: "There is now an urgency to
> arrive at emergency call standards with use of VoIP growing and the
> potential for existing implementations to result in problems and
> delays in organising responses for ECCs."
> 
[PTT] I'm not sure this follows from the preceding part of the document. 
  I see it as a motivation rather than a conclusion, so I stuck it at 
the beginning of the introduction.