Subject: [Sipping] Comments on sos draft -0

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 6 Jan 2003 15:56:22 -0000

Rather than reply to the other mails on this draft, I thought I should start from scratch on generating comments, although some of the comments below have some bearing on the discussions that are already taking place.

Comments on draft-schulzrinne-sipping-sos-03

1)	The document is missing an abstract which defines the scope. I am therefore unsure whether it is just a requirements document, or whether it is intended to be provide the total solution for emergency calls. My assumption is the latter, and therefore this ultimately will be the RFC that will register the sos and sos. urls, and will also define the actions of UAs and proxies in regard to emergency calls. However the latter presumably should be SIP actions, and should be in the SIP group. The following should therefore be done:

-	add an abstract detailing the scope of this specification
-	if the document is to define requirements for SIP UAs and proxies, then decide whether it should be a SIP group draft.

2)	section 3 (Emergency URI). I think we should break down this section into 2. The first should detail requirements for SIP URLs and the second should deal with tel URLs. It seems to me that the requirements for these are somewhat different. For sip URLs we assume that designated URLs are always emergency calls, and send them to the local emergency centre. For tel URLs, we have the additional problem of determining whether the related telephony number is an emergency local service number, and this issue requires considerable discussion in its own right, see later comments.

Perhaps we also need to take a step further back, and start with the user input itself. Perhaps we need a requirement that "UAs that determine that a dialog or transaction relates to an emergency MUST use an emergency call identifier in the Request-URI". Such a requirement would relate to where the user pushes the big red emergency button, and also to where input key sequences are analysed against a list of emergency related key sequences.

3)	section 3 (Emergency URI), last paragraph, text: 'The "sos" user name and user names starting with "sos." MUST NOT be assigned to any regular user.' I assume this a requirement relating specificly to SIP URLs, and is not a general URL requirement. It would be desirable to state this explicitly.

4)	section 3 (Emergency URI), last paragraph, text: 'It is RECOMMENDED that SIP MESSAGE requests are directed....' is presumably a requirement that must be taken in the context of section 4, i.e. it applies to all UAs and all proxies. It would be better specified in clause 4, and its applicability should be made clear. Further "SIP messaging" should presumably be "instant messaging" which is I believe the terminology used in the SIP MESSAGE RFC.

5)	section 3 (Emergency URI), 3rd paragraph: "In addition, user agents and proxies SHOULD also recognise the telephone numbers 911 and 112 ...". The 3GPP specification (3GPP TS 22.101) makes a somewhat longer list of numbers that should be applied. The following two sentences apply: 
-	"The following emergency numbers shall be stored in the ME for use when no emergency numbers are stored in the SIM/USIM: 000, 08, 112, 110,  911 and 999. "
-	"The following emergency numbers shall be stored in the ME for use without SIM/USIM: 000, 08, 112, 110, 118, 119, 911 and 999."
Given that the above lists work for all existing GSM phones in the countries of the world where GSM is used, which is most, it would seem sensible to use those lists rather than come up with a new IETF specific list. 
As to which list should be used, perhaps in fact the answer is both. The first list should apply where there is an additional number list in the SIP phone that is dynamically configurable by some external entity, and the second when there is not. More on these requirements in other comments.

6)	section 3 (Emergency URI), 3rd paragraph: use of "phone-context". Is it appropriate to use phone context in any emergency call. In 3GPP, any use of one of the numbers from the list stored in the phone is an emergency call, no matter where it originates from. If my understanding of phone-context is correct, it SHOULD NOT be used, as it could result in failure to deliver an emergency call.

7)	Section 4 (Request handling). There are mentions of "sos.*" in this text. Is the intent that "sos.*" should be a valid SIP URL with appropriate emergency call handling, or is it being used as a shorthand in this document to refer to those defined in section 3, and as such would not appear in a Request-URI? 

8)	Section 4 (Request handling), text: "It is RECOMMENDED that user agents periodically automatically check for the availability....". I consider that the use of this may be unnecessary in all cases. If the phone can be loaded with emergency numbers dynamically, and the update of those numbers is of reasonable frequency, then there is no need to regularly perform the OPTIONS request. For this reason, it would appear to be unnecessary for 3GPP phones. 

9)	Section 4 (Request handling): There seems to be an assumption that a local emergency number, e.g. 911 is more routeable in a network of SIP proxies than a sos URL. Surely this is a matter of local policy. Surely it is possible that the emergency call is entirely routed as a sos URL. Surely the main requirement is that the owner of the first proxy reached is responsible for routing it to an emergency call centre, and it is a matter of local policy how that is done.

10)	Section 4 (Request handling): Further the text should acknowledge that where a SIP outbound proxy exists then that can also perform such analysis of keyed numbers. Mechanisms for establishing an outbound proxy at registration time are standards track items. 3GPP accompanies all requests with the Mobile Country Code and the Mobile Network Code to assist in this analysis (where the analysis has failed at the phone). Some text for this is currently stated in section 3, but section 3 is the wrong place for this information.

11)	Section 5 (Request routing): I believe the text should acknowledge that at least some phones will have the capability of storing dynamically emergency numbers for use in analysing calls made with telephony type user input. 3GPP SIP phones will carry this requirement, and any SIP phone that uses some SIM like technology to carry subscription information is capable of being programmed at subscription time (i.e. delivery of the SIM to the subscriber) to carry the appropriate emergency numbers. It is becoming clear from the discussion that no one method is appropriate for doing this, but I believe there should be a discussion of the mechanisms that do exist, and any future SIP extensions should take account of that. Clause 5 should not be specific to the one mechanism that is specified here; for example 3GPP will use another mechanism and not one based on DHCP.

12)	If this draft is creating the sos URLs, should it not have an IANA considerations section telling IANA to register these URLs.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 
_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Mon, 06 Jan 2003 15:06:11 -0500

Drage, Keith (Keith) wrote:
> Rather than reply to the other mails on this draft, I thought I
> should start from scratch on generating comments, although some of
> the comments below have some bearing on the discussions that are
> already taking place.
> 

Thanks for your extensive comments. Responses inline, where needed. I've 
split my response to keep it to a length that others may still read...

> 
> 1)	The document is missing an abstract which defines the scope. I am
> therefore unsure whether it is just a requirements document, or
> whether it is intended to be provide the total solution for emergency
> calls. My assumption is the latter, and therefore this ultimately
> will be the RFC that will register the sos and sos. urls, and will
> also define the actions of UAs and proxies in regard to emergency
> calls. However the latter presumably should be SIP actions, and
> should be in the SIP group. The following should therefore be done:
> 
> -	add an abstract detailing the scope of this specification -	if the
> document is to define requirements for SIP UAs and proxies, then
> decide whether it should be a SIP group draft.

Abstract updated as:

This document describes how SIP user agents and proxies can set up
emergency calls and, more generally, reach emergency assistance via SIP
requests.  For that purpose, it defines a universal emergency SIP URI,
sip:sos@domain and sips:sos@domain, that allows SIP user agents to
contact the local emergency number.  It also defines conventions that
increase the high probability of reaching the appropriate emergency call
center.  The document does not define any SIP protocol extensions.

Except for a reserved-name, the spec does not modify or extend SIP 
protocol behavior (that's the point). Thus, I don't think this requires 
SIP WG action. I believe this activity falls under WG charter item 2:

"2. Documenting the usage of SIP to solve real problems that need to be 
solved in a standardized way."

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 06 Jan 2003 18:11:11 -0500

> 5)	section 3 (Emergency URI), 3rd paragraph: "In addition, user
> two sentences apply: -	"The following emergency numbers shall be
> stored in the ME for use when no emergency numbers are stored in the
> SIM/USIM: 000, 08, 112, 110,  911 and 999. " -	"The following

Good idea. The only difference seems to be 118 and 119.

> 6)	section 3 (Emergency URI), 3rd paragraph: use of "phone-context".
> Is it appropriate to use phone context in any emergency call. In
> 3GPP, any use of one of the numbers from the list stored in the phone
> is an emergency call, no matter where it originates from. If my
> understanding of phone-context is correct, it SHOULD NOT be used, as
> it could result in failure to deliver an emergency call.
> 

I wrote this before the most recent phone-context discussion and I tend 
to agree. If there's to be a phone context at all, it would need to be 
something like 'sos' or some other recognized identifier. The problem 
occurs with 118 and 119, which presumably are omitted from the shorter 
list since they mean something other than emergency somewhere. 
(Apparently, 118 is directory assistance in the UK; 119 is fire in 
Japan.) The outbound proxy doesn't know whether the phone was configured 
with a local list or not, so it needs to be able to tell whether tel:118 
is emergency or something else.

One simple, pragmatic rule would be that numbers from the longer list 
without context always mean emergency.

> 8)	Section 4 (Request handling), text: "It is RECOMMENDED that user
> agents periodically automatically check for the availability....". I
> consider that the use of this may be unnecessary in all cases. If the
> phone can be loaded with emergency numbers dynamically, and the
> update of those numbers is of reasonable frequency, then there is no
> need to regularly perform the OPTIONS request. For this reason, it
> would appear to be unnecessary for 3GPP phones.

The problem is that I can't rely on a local friendly outbound proxy that 
knows how to handle either sip:sos or tel:XXX. You can mandate this for 
3GPP providers, but not all VoIP systems will be run by common carriers.

I'm reluctant to encode 'I'm a 3GPP phone, so I don't need to do this' 
into the protocol. After all, this 3GPP phone may also use your friendly 
neighborhood 802.11 hotspot.

> 
> 9)	Section 4 (Request handling): There seems to be an assumption that
> a local emergency number, e.g. 911 is more routeable in a network of
> SIP proxies than a sos URL. Surely this is a matter of local policy.
> Surely it is possible that the emergency call is entirely routed as a
> sos URL. Surely the main requirement is that the owner of the first
> proxy reached is responsible for routing it to an emergency call
> centre, and it is a matter of local policy how that is done.

This wasn't the intent. I'll reword.

> 
> 10)	Section 4 (Request handling): Further the text should acknowledge
> that where a SIP outbound proxy exists then that can also perform
> such analysis of keyed numbers. Mechanisms for establishing an
> outbound proxy at registration time are standards track items. 3GPP
> accompanies all requests with the Mobile Country Code and the Mobile
> Network Code to assist in this analysis (where the analysis has
> failed at the phone). Some text for this is currently stated in
> section 3, but section 3 is the wrong place for this information.

Moved and reworded.

> 12)	If this draft is creating the sos URLs, should it not have an
> IANA considerations section telling IANA to register these URLs.

There will be a section on registering additional sos.* services. There 
currently is no registry for reserved SIP user identities and tel URIs. 
Should there be?

Henning