Re: [Ecrit] Comments on phonebcp-07

["Brian Rosen" <[e-mail]>]

Finishing this up

> 5. I'll downgrade the sip-sips reference to Informational.  
> Could refer to
> the 3.1 text.
[JRE] It still doesn't make sense to me for a normative statement to
refer to 3.1 of sip-sips when that section does not contain any
normative language. All we are doing is saying that TLS MUST be used,
and this doesn't seem to require any reference to sip-sips. So I would
suggest removing the reference to sip-sips entirely.
<BR>I'll remove the reference to sip-sips

In addition (apologies if this has already been discussed), by mandating
TLS we effectively are saying that you can't make an emergency call if
you can't use TLS! I doubt if that is really the intent. Should it not
say something like "An end device MUST use TLS, if available, when
attempting to establish an emergency call."?
<BR>It's been discussed, and look at the very next requirement

> 
> 6. Don't know how to define a requirement which assumes the 
> presence of a
> B2BUA.  I propose to leave as is
[JRE] Let me put it a different way. I don't think this is necessarily
achievable by the end device (UA). If the registrar does not support
GRUU, the UA may not have any means of obtaining a globally routable
contact URI. Perhaps the second "MUST" should be "SHOULD", with some
rationale why it might not always be possible. In any case, a locally
routable contact URI is acceptable if a B2BUA maps it to a globally
routable contact URI. 
<BR>see below
> 
> 7. I'll fix the text for MUST and delete "normal"
> 
> 8. An actual problem.  Calls out for a way to mark the Route as the
> emergency route.  Two solutions were discussed.  One is to use the sos
> parameter.  The other is to say that the Geolocation header 
> must not have
> a "used for routing" parameter unless the LoST routing was 
> completed.  I
> think I will recommend the second.
[JRE] OK - but I didn't see this in 08.
<BR>-08 says:
If a device understands the SIP Location Conveyance extension and supports
LoST [RFC5222], the Geolocation "used-for-routing" header parameter MUST be
added to the corresponding URI in the Geolocation header.  If the device is
unable to obtain a PSAP URI for any reason it
MUST NOT include "used-for-routing" on a Geolocation URI, so that downstream
entities know that LoST routing has not been completed.

> 10.  If the device is no longer registered, then the Contact can't be
> valid.  I can insert text to this effect.  
[JRE] I didn't see this in 08.
<BR>It will now read:
A Contact header MUST be present which MUST be globally routable, for
example a GRUU [I-D.ietf-sip-gruu], and be valid for several minutes
following the termination of the call, 
provided that the UAC remains registered with the same registrar, to permit
an immediate call-back to the specific device which placed the emergency
call.  It is acceptable if the UAC inserts a locally routable URI and a
subsequent B2BUA maps that to a globally routable URI.



> 
> 11. Tried to make the requirement minimal (no Replaces, for 
> example), but
> I think you need referred by.  I'll think some more about 
> that.  I'll add
> text that says device implementers should consider the effect 
> of emergency
> call transfer on a stressed user; generally, the device should do the
> transfer.
[JRE] I didn't see anything in 08. For a device, the requirement is to
support receipt of REFER with method=INVITE, I believe, and to handle
the Referred-By header field in such a request. If so, this should be
stated clearly.
<BR>Rewrote to:
ED-67 During the course of an emergency call, devices and proxies MUST
support REFER transactions with method=INVITE and the Referred-by: header
<xref target="RFC3515"></xref> in that transaction.


> 
> 12. Don't understand the problem.  The situation described is 
> AFTER a call
> session is established, but before it is terminated.   LoST 
> resolution is
> complete.
[JRE] What I meant is how can the UA determine that the new call
originated at a PSAP. If the device did a LoST query, then a From or PAI
URI matching the result of the LoST query might be one mechanism. But if
the device didn't do a LoST query, or if the call comes from a different
PSAP (e.g., because the original call was forwarded or transferred) that
might not help.
<BR>At this time, I think the domain idea is all we have to work with.  As
you know, there is a draft that proposes new mechanisms to mark call backs.
If I just qualify the current text that this won't always work, and future
work will address this, is that okay?  Suggested text:
Recognizing a call back from the domain of the PSAP will not always work,
and further
standardization will be required to give the UA the ability to recognize a
call back

> 
> 13. a) If a call arrives while an emergency call is up, we 
> don't want a
> call waiting tone, alert or other prompt, we don't want the 
> emergency call
> put on hold and we don't want the incoming call to be answered.
[JRE] Thanks for the clarification, but this does not alter the fact
that call waiting is not an outgoing call feature. It would be better to
say what we mean, e.g., MUST disable features that will interrupt an
ongoing emergency call, such as call waiting...
<BR>Rewrote to:
User Agents and proxies MUST disable features that will interrupt an
ongoing emergency call, such as:

> b) Although some features can be applied to incoming calls, 
> they are also
> applicable to outgoing calls, which is what we want here; we 
> don't want
> the emergency call put on hold, put into a client-side conference, ...
[JRE] This too could be covered by the form of words I suggested above.
<BR>Reworded to:
The User Agent and Proxies MUST disable call features which would interfere
with the ability of call backs from the PSAP to be completed such as:

> c) I'll add a definition of "flash hold" to -framework.  Of  
> course "flash
> hold" does involve a proxy,  where normal SIP hold does not.  
> You don't
> want Hold (that is, disconnect the media to or from the PSAP).
[JRE] Flash hold as you now describe it in the framework is a PSTN
feature, so how does it relate to a SIP device?
<BR>How 'bout I just delete any reference to "flash" and just say "Hold"?

> 
> 14. Call waiting on an incoming call is the same as on an 
> outgoing call:
> you don't alert to another call, you don't offer hold and switch.  The
> PSAP callback stays up.  Yes, 486 or voicemail is 
> appropriate.  Indeed the
> recognition of the callback is difficult, and I hope we will 
> charter an
> item.  I think the domain recognition is a reasonable first 
> step, and I
> recognize it won't always work.   When it doesn't, callback 
> won't get the
> feature suppression.  Not a good thing, but not fatal.
[JRE] That is one way of interpreting the text of ED-72, but the way I
interpreted it is this. If I am engaged in a (non-PSAP) call and a
callback from a PSAP arrives, the callback is not allowed to use call
waiting to interrupt the existing call. That seems wrong. So there are
two situations: i) during an ordinary call when a callback from a PSAP
arrives, and ii) during a call that is a callback from a PSAP (which
really should be treated no differently from a call to a PSAP).
<BR>In the rewording, I used " interfere with the ability of 
call backs from the PSAP to be completed".  I have also deleted "Call
Waiting"
from the list, so I think the meaning is now clear.

> 
> 15. I may be misinterpreting your concern, but I think the 
> B2BUA that maps
> Contact doesn't alter the caller's domain as seen by the 
> called party.  If
> the call arrives directed TO the Contact or AoR given out in 
> the original
> emergency call, and it's FROM the same domain that answered 
> the call, then
> it should be treated as a call back.
[JRE] I didn't express my concern correctly. How does the end device
determine the domain of the PSAP that answers the call? We don't yet
have response identity defined in SIP. We could get the PSAP to send a
request (e.g., UPDATE) in the reverse direction and use PAI in that
request or RFC 4916 to change the From URI.
<BR> Aha.  I'll add a reference to 4916:
[RFC4916] may be used by the PSAP to inform the UA of the domain of the
PSAP.

> 
> 
> 17. The response certainly should be using TLS, but it might 
> not work. 
> I'll add text.
[JRE] "The test response
   SHOULD be protected with TLS.  If the body cannot be protected, the
   location SHOULD NOT be included in the response.."
Although the first hop from the responding node might be TLS, it is not
known that all upstream hops are TLS.

<BR>What do you want me to do?  S/MIME isn't a practical answer.