Re: [Ecrit] Comments on phonebcp-07

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

Thanks

I will fix ED-61 as you suggest.

If I change ED-82 last line to:
Use of SIPS for the request would assure the response containing the
location is kept private.

Would that be acceptable?

Brian

-----Original Message-----
From: Elwell, John [mailto:[e-mail]] 
Sent: Friday, March 27, 2009 5:15 PM
To: Brian Rosen; [e-mail]
Subject: RE: [Ecrit] Comments on phonebcp-07

Brian,

Thanks for addressing my concerns. Just a couple of outstanding points
below.

> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]] 
> Sent: 27 March 2009 17:16
> To: Elwell, John; [e-mail]
> Subject: RE: [Ecrit] Comments on phonebcp-07
> 
> 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
[JRE] OK

> 
> 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
[JRE] But the ED-61 talks about only the case where TLS fails, rather
than the case where TLS is simply not available. I guess it is a
question of interpretation of words, but if you can't find a port for
TLS, you can't even attempt it. So instead of "fails" I would say "is
not available or fails".

> 
> > 
> > 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.
[JRE] OK

> 
> > 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.
[JRE] Good.

> 
> 
> 
> > 
> > 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.
[JRE] OK

> 
> 
> > 
> > 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
[JRE] Good

> 
> > 
> > 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:
[JRE] Good

> 
> > 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:
[JRE] Good

> 
> > 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"?
[JRE] OK

> 
> > 
> > 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.
[JRE] OK

> 
> > 
> > 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.
[JRE] OK

> 
> > 
> > 
> > 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.
[JRE] I don't see the point of SHOULD. If the request has arrived over
an all TLS path, then the response should follow an all TLS path, based
on the Via header field. If the request has not arrived over an all TLS
path, it is unclear what the UAS can do. Can the UAS check the  string
of Via headers and check the path is all TLS? Otherwise I feel that the
SHOULD is rather pointless. If the UAC wants to protect its location
during test, it should use SIPS, rather than relying on the UAS to fix
the problem.


John