Subject: RE: [Sipping] Comments on sos draft -03 (URI)

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Jan 2003 17:52:03 -0000

See below - I have snipped out the areas where I am happy with the response, or have replied elsewhere.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: 06 January 2003 23:11
> To: Drage, Keith (Keith)
> Cc: [email-masked]'
> Subject: Re: [Sipping] Comments on sos draft -03 (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.
> 
> 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.
> 
> 
> > 
Firstly I note that the requirement already was only a SHOULD rather than a MUST. In the case where SHOULD is used I usually prefer to specify some examples of where the SHOULD does not apply as guidance, and this appeared to be the appropriate one.

From what you are saying, the flaw in the argument is that 3GPP controls the routeing to the emergency call centre as well as the downloading of numbers to the UA, and therefore can say that if a number is downloaded it will work, and therefore the the testing of the numbers is not needed. In a more general case the DHCP server or whatever may be providing information in the emergency numbers to the UE may not be provided by the same provider who does the routeing to the emergency call centre and therefore such numbers may fail, and as a result, should be tested.

I am not convinced by the argument; that may be answered by what do we expect the UA to do if the OPTIONS request it sends to the tel url it has been given fails? If the user dials that tel url, does the UA continue to treat such a call as an emergency call, or does it flash a message on the users display saying "I don't know what to do with this"?
_______________________________________________
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: Fri, 10 Jan 2003 16:36:28 -0500

> Firstly I note that the requirement already was only a SHOULD rather
 > than a MUST. In the case where SHOULD is used I usually prefer to
 > specify some examples of where the SHOULD does not apply as guidance,
 > and this appeared to be the appropriate one.

 > I am not convinced by the argument; that may be answered by what do
 > we expect the UA to do if the OPTIONS request it sends to the tel url
 > it has been given fails? If the user dials that tel url, does the UA
 > continue to treat such a call as an emergency call, or does it flash
 > a message on the users display saying "I don't know what to do with
 > this"?

There are only two choices: try again and hope that it works (maybe 
because somebody botched the OPTIONS implementation) or fail without 
trying. I suspect the robust solution is:

- if OPTIONS doesn't work, warn the user that emergency calls for 
numbers X and Y may not work (but Z seems to). This will cause any 
failures to be discovered early, rather than at the time of emergency. 
One of the problems with the existing corporate emergency number systems 
is that I have no good way to "non-invasive" testing. The OPTIONS 
approach fixes this. 'Ping' has been a very useful network debugging 
tool - consider this the SIP equivalent.

In the translation model I posited in my earlier note, all numbers would 
be translated to sos@.

- if the user still tries to dial those numbers, I guess there's no harm 
in trying.