Subject: Re: [Ecrit] Comments on phonebcp-07

From: "Elwell, John" <[email-masked]>
Date: Tue, 03 Mar 2009 14:43:53 +0000

Brian,

Thanks for your responses. See below. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: 28 February 2009 00:30
> To: [email-masked]
> Subject: Re: [Ecrit] Comments on phonebcp-07
> 
> Thank you for your comments.  Sorry this took so long.  I am 
> temporarily
> unable to create an actual "Reply all" to your email, so this is
> cut/pasted from a non-IETF archive (the archives are screwed 
> up, there is
> no mail from Feb 2 to Feb 27).  The changes are now in 
> -framework-08 and
> -phonebcp-08
> 
> Enterprise = access network operator.  They must meet the AN 
> requirements.
>  I'll point that out.  Enterprises could run their own LoST 
> server which
> would deliver the right things (dial string, URI, ...).  I've 
> added text
> on both enterprise as access network provider and potential 
> LoST and PSAP
> provider in -framework, and mentioned enterprise as a possible access
> network provider in -phonebcp
> 
> 1. ED-6 vs ED-9 is the difference between discovery with a 
> home country
> code and provisioning of actual dial string.  We haven't described
> discovery, so I'll have to delete ED-6
> 
> 2. I'll Reword SP-8 to say that Service providers may 
> provision endpoints
> with home dial strings (see ED-9)
> 
> 3. Changes in the list clarifies this, but ED-18 says do it, and ED-21
> specifies protocol support to do it.  I added a reference to 
> -21 in -18.
> 
> 4. We discussed this on the interim conference call.  The 
> resolution will
> be to remove the requirement and have something non normative in
> -framework.
> 
> 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.

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."?

> 
> 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. 

> 
> 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.

> 
> 9. Rework to make it a SHOULD noting the issue.  
> Unauthenticaed devices
> usually are allowed to make calls, but not always.  I'll add text.
> 
> 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.

> Don't know how to 
> handle B2BUAs
> that munge Contact headers.   I can at least call out the problem in
> -framework.
[JRE] That should be good enough.

> 
> 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.

> 
> 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.

> 
> 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...

> 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.

> 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?

> 
> 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).

> 
> 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.

> 
> 16. I don't really care much what error message we use.  I 
> can change it
> to 404 if there are no objections.  ".test" is not registered.  We
> probably should do that, but not in this document.  It's not really
> required that we register it, as it's a subdomain of a 
> registered domain. 
> i need to get a document started to register a couple of things not
> dissimilar to this, so I'll put it in that
[JRE] The point is, an entity that does not support phonebcp would
presumably return a 404, no matter what we say in phonebcp. So I think
404 is correct.

> 
> 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.

John

> 
> 18.  I will delete the sentence referencing 4916.
> 
> Brian
> 
> ------ original message contents -------
> Some WGLC comments on this. Apologies for not raising them 
> before, but I
> have not participated in this WG until recently.
> 
> General comment:
> It is not clear if and how this applies to enterprise networks.
> Enterprise networks are mentioned in a couple requirements involving
> intermediate range wireless connections, but that is all. Particular
> requirements of enterprise networks, which might include their own
> "PSAPs" in some situations, for example, and different dial strings in
> some circumstances, do not seem to be addressed. So perhaps 
> it should be
> made clear that it does not address special requirements of enterprise
> networks.
> 
> Detailed comments:
> 
> 1. "ED-6/SP-5 Devices MUST be able to be configured with the home
> country
>    from which the home dial string(s) can be determined."
> And later:
> "ED-9 Endpoints SHOULD be able to have home dial strings provisioned
>    by configuration."
> I can't figure out exactly why we need two separate requirements here.
> 
> 2. "SP-8 Service providers MAY provide home dial strings by
>    configuration"
> It is not clear to whom or to what home dial strings are provided, and
> how this relates to requirements ED-6/SP-5 and ED-9.
> 
> 3. "ED-18/INT-9 Endpoints SHOULD attempt to configure their own
> location."
> And later:
> "ED-21/INT-12 Devices MUST support both the DHCP location options
>    [RFC4776], [RFC3825] and HELD"
> There appears to be some inconsistency here. If there are 
> circumstances
> in which a device does not need to attempt to configure its 
> own location
> (because it is only SHOULD strength), why are support for 
> DHCP and HELD
> mandated?
> 
> 4. "ED-59 Best Current Practice for SIP user agents [RFC4504] 
> including
>    handling of audio, video and real-time text [RFC4103] SHOULD be
>    applied."
> Is it permissible for a Standards Track to make a SHOULD statement
> involving an informational RFC? I believe not. Furthermore, RFC 4504
> refers back to ECRIT work, which makes it rather circular.
> 
> 5. "ED-60/SP-31 TLS MUST be specified when attempting to signal an
>    emergency call with SIP per [I-D.ietf-sip-sips].  IPSEC 
> [RFC3986] is
>    an acceptable alternative."
> I think we need to be more specific about what aspect of 
> sip-sips we are
> referring to. For example, are we talking about 3.1 "Models for using
> TLS in SIP"? That section doesn't seem to include any normative
> statements, so why is it a normative reference. The normative part of
> sip-sips seems to relate to the SIPS URI scheme, which presumably we
> don't want to use.
> 
> 6. " 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 to
>         permit an immediate call-back to the specific device which
>         placed the emergency call."
> As a requirement for a user agent, I don't think this is necessary in
> situations where there is a B2BUA that maps a local contact URI to a
> globally routable contact URI.
> 
> 7. "ED-58 Initial INVITES MUST provide an Offer [RFC3264]."
> And later:
> "A normal SDP offer SHOULD be included in the INVITE.  If voice
>         is supported the offer MUST include the G.711 codec, see
>         Section 14."
> This seems contradictory (MUST and SHOULD). Also what is "normal"?
> 
> 8. "A proxy that processes such a call looks for
>    the presence of a SIP Route header field with a URI of a PSAP.
>    Absence of such a Route header indicates the UAC was 
> unable to invoke
>    LoST and the proxy MUST perform the LoST mapping and insert a Route
>    header field with the URI obtained."
> How does the proxy determine whether a URI is indeed a PSAP 
> URI? Does it
> need to examine the Geolocation header field to see if the 
> location has
> been used for routing?
> 
> 9. "Either a P-Asserted-Identity [RFC3325] or an Identity header
>        [RFC4474], or both, MUST be included to identify the sender."
> A proxy cannot do this unless it has authenticated the UA or unless it
> violates the rules of RFC 3325 or RFC 4474. I think we need some
> commentary on whether unauthenticated UAs are allowed to make 
> emergency
> calls, and if so, how to get around this problem of providing PAI or
> Identity.
> 
> 10. "SP-36 Call backs to the Contact: header URI recieved within 30
>    minutes of an emergency call must reach the device 
> regardless of call
>    features or services that would normally cause the call to 
> be routed
>    to some other entity."
> a) What if the device is no longer registered?
> c) Also, what if there are downstream B2BUAs that map contact 
> URIs? Will
> they necessarily cache that mapping after the original call has
> finished? If not, I don't see how a callback to the contact URI can
> work.
> 
> 11. "ED-67/SP-38 During the course of an emergency call, devices and
>    proxies MUST support REFER transactions and the Referred-by: header
>    [RFC3515]."
> a)This is a very broad requirement. I can see the need for supporting
> REFER with SIP/SIPS URI and with method=INVITE. Is there a requirement
> beyond this?
> b) A UA can support REFER by consulting its user whether to 
> go ahead and
> reference. The user may decline. Or UA policy might prevent certain
> dereferences. Does anything need to be said about this?
> 
> 12. "If in the interval, an incoming call is received from
>    the domain of the PSAP, the device MUST drop the old call and alert
>    for the (new) incoming call."
> Can the device necessarily determine this? For example, if the device
> just submitted a dial string, or submitted a service URN without
> performing a LoST query, or if the call gets retargeted to a different
> PSAP domain?
> 
> 13. "ED-70/SP-39 User Agents and proxies MUST disable outgoing call
>    features such as
>    o  Call Waiting
>    o  Call Transfer
>    o  Three Way Call
>    o  Flash hold
>    o  Outbound Call Blocking"
> a) I don't see how Call Waiting can be considered an outgoing call
> feature. Some explanation is needed.
> b) I don't see call transfer, three way call (presumably 3-way
> conference) and hold as "outgoing call features" particularly 
> - you can
> use these "features" with incoming calls too.
> c) "Flash hold" seems to be a north American term - use a more generic
> term or describe what this means.
> d) If "flash hold" means "hold", proxies have no influence over it.
> Also, if hold means "stop sending and rendering media", a 
> device can do
> that simply by preventing the user turning down the microphone or
> speaker volume. Is this what it means? Removing any control 
> over volume
> seems unwise.
> 
> 14. " ED-72/SP-41 The User Agent and Proxies SHOULD disable the
> following
>    incoming call features on call backs from the PSAP:
>    o  Call Waiting"
> a) Disabling call waiting will generally result in rejecting 
> an incoming
> call with a 486, or forwarding, e.g., to voicemail. Is this 
> really what
> is required?
> b) How does a UA or proxy determine that the callback is from a PSAP
> (see earlier comment, and also next comment)?
> 
> 15. "ED-73 Call backs SHOULD be determined by retaining the domain of
> the
>    PSAP which answers an outgoing emergency call and instantiating a
>    timer which starts when the call is terminated.  If a call is
>    received from the same domain and within the timer period, sent to
>    the Contact: or AoR used in the emergency call, it should 
> be assumed
>    to be a call back.  The suggested timer period is 5 minutes."
> Suppose there is a B2BUA on the path that maps contact URIs. 
> Every call
> the UA makes through that B2BUA will have a contact URI with 
> the domain
> of that B2BUA, so every call within the time period concerned would be
> treated as coming from a PSAP.
> 
> 16. "ED-81 INVITE requests to a service URN ending in ".test" 
> indicates
> a
>    request for an automated test.  For example,
>    "urn:service.sos.fire.test".  As in standard SIP, a 200 
> (OK) response
>    indicates that the address was recognized and a 404 (Not 
> found) that
>    it was not.  A 486 (Busy Here) MUST be returned if the test service
>    is busy, and a 488 (Not Acceptable Here) MUST be returned 
> if the PSAP
>    does not support the test mechanism."
> This seems to be the wrong semantics for 488, since in this case there
> is nothing wrong with the session description. Wouldn't 404 be more
> appropriate, since the .test URN is not recognised?
> Also, where is ".test" registered?
> 
> 17. "ED-82 In its response to the test, the PSAP MAY include 
> a text body
>    (text/plain) indicating the identity of the PSAP, the requested
>    service, and the location reported with the call.  For the latter,
>    the PSAP SHOULD return location-by-value even if the original
>    location delivered with the test was by-reference."
> Isn't there a security issue with this, particularly for the 
> case where
> SIPS has not been used? There is no discussion in Security
> Considerations.
> 
> 18. "The response MAY
>    include the connected identity of the PSAP per [RFC4916]."
> RFC 4916 makes no provision for responses.
> 
> John
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Mar 2009 09:10:18 -0800

> attempting to establish an emergency call."?

This change makes sense.  If taken literally, a TLS mandate would 

result in the failure of many emergency calls with serious consequences

for the callers.

---

From: Karl Heinz Wolf <[email-masked]>
Date: Tue, 3 Mar 2009 16:58:57 -0500

Brian, just one comment on the now deleted ED-6:

> 1. ED-6 vs ED-9 is the difference between discovery with a home country

I thought LoST would be the way to discover dial strings for the home
country. A mapping request with just the home country as location
information would be the discovery, wouldn't it?

karl heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 3 Mar 2009 17:25:13 -0500

Hmmmm.  That works.  Either I forgot about it, or we never actually
discussed it.

I'll put it back and put some text in -framework about it:
You MAY provision home country
The device could discover home dial strings knowing home country via LoST.

Sorry about that.  ED-6 will come back.

Brian

-----Original Message-----
From: Karl Heinz Wolf [mailto:[email-masked]] 
Sent: Tuesday, March 03, 2009 4:59 PM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [Ecrit] Comments on phonebcp-07

karl heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 3 Mar 2009 17:25:36 -0500

Please read the document:

   ED-61/SP-32 If TLS session establishment fails, the call MUST be

   retried without TLS.

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Tuesday, March 03, 2009 12:10 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Ecrit] Comments on phonebcp-07

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Mar 2009 07:49:56 +0000

Brian,
 
Concerning ED-60, I guess it depends how one interprets "TLS MUST be
specified", which is rather a strange way of formulating a normative
statement. For example, if when following RFC 3263 procedures TLS is not
identified as a possibility, what does one do? It is not a case that TLS
establishment fails, it simply isn't available. I still prefer the
wording I proposed before: "An end device MUST use TLS, if available,
when attempting to establish an emergency call".
 
I now notice a concern with ED-47, where it says that TLS MUST be used
to protect the location. It does also refer to 9.1, where ED-61 resides,
so there is a get-out for fallback to an alternative transport. However,
I could interpret this in two ways. One way is to send the location
unprotected. I believe this is the intention. But it could also be
interpreted that you MUST NOT send location if signalling is not
protected by TLS. Do you think some clarification is needed here too?
 
John

________________________________

	From: Brian Rosen [mailto:[email-masked]] 
	Sent: 03 March 2009 22:26
	To: 'Bernard Aboba'; Elwell, John; [email-masked]
	Subject: RE: [Ecrit] Comments on phonebcp-07

	   ED-61/SP-32 If TLS session establishment fails, the call MUST
be

	   retried without TLS.

	> attempting to establish an emergency call."?
	 
	This change makes sense.  If taken literally, a TLS mandate
would 
	result in the failure of many emergency calls with serious
consequences
	for the callers.

---

From: Karl Heinz Wolf <[email-masked]>
Date: Fri, 13 Mar 2009 10:47:17 -0400

Thank you for putting back ED-6.

I thought about the configuration of the home emergency number and how
to map the home emergency number to the visited one. In case the same
emergency (sub-)services exist in both the home and visited country,
there shouldn’t be a problem. But what about the following situation:
the user dials his home dialstring for sos.physician, but this service
does not exist in the visited country.
Or the user just has a single home dial string for sos, but there is
no such general emergency service in the visited country, but all the
subservices. Where should the call be connected to?

Would it make sense to have a rule on this like:

Home emergency dial strings should be mapped to the corresponding
emergency service in the visited country. In case there is not such a
service in the visited country, the mapping for urn:service:sos should
be used to connect the call. If there is no such general emergency
service available, urn:service:sos.police should be tried, followed by
other randomly selected services in case of failure.
?

Karl Heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Mar 2009 11:18:18 -0400

I think we're better off saying (if it isn't already in LoST), that
urn:service:sos MUST be specified (locally) and lead somewhere appropriate.
Then a missing service goes to urn:service:sos always.

Brian

-----Original Message-----
From: Karl Heinz Wolf [mailto:[email-masked]] 
Sent: Friday, March 13, 2009 10:47 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [Ecrit] Comments on phonebcp-07

Karl Heinz

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 13 Mar 2009 10:35:46 -0500

I agree - the alternative, as Karl Heinz suggests, is to pick another URN, 
which might ALSO be missing, and/or just start trying services at random...

Thanks,

Spencer

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Karl Heinz Wolf'" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 13, 2009 10:18 AM
Subject: Re: [Ecrit] Comments on phonebcp-07

Brian

-----Original Message-----
From: Karl Heinz Wolf [mailto:[email-masked]]
Sent: Friday, March 13, 2009 10:47 AM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [Ecrit] Comments on phonebcp-07

there shouldn't be a problem. But what about the following situation:

Karl Heinz

---

From: Karl Heinz Wolf <[email-masked]>
Date: Fri, 13 Mar 2009 11:48:10 -0400

I just noticed that Spencer's first mail was off-list and so was my reply.

My question there was: do you think every country having subservices
could agree on picking one service as a default sos service?
I certainly agree that having a urn:service:sos would make things easier.

karl heinz

On Fri, Mar 13, 2009 at 11:35 AM, Spencer Dawkins
<[email-masked]> wrote:
> ----- Original Message ----- From: "Brian Rosen" <[email-masked]>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Mar 2009 11:56:05 -0400

As a practical matter, nearly every country already does that, because of
the 1-1-2 action in mobile phones, so I think it's a practical answer.

Brian

-----Original Message-----
From: Karl Heinz Wolf [mailto:[email-masked]] 
Sent: Friday, March 13, 2009 11:48 AM
To: Spencer Dawkins
Cc: Brian Rosen; [email-masked]
Subject: Re: [Ecrit] Comments on phonebcp-07

karl heinz

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 27 Mar 2009 06:11:05 +0100

I would note that the text in RFC 5031 leads one to the belief that if a subservice is defined, use of the service above the subservice is equally valid and should result in delivery to some valid answer point. This would appear to apply to both counselling and sos.

So it would appear to me that any usage of a subservice implies a requirement to also route the top level service to some point where it can be dealt with.

regards

Keith 

> Sent: Friday, March 13, 2009 3:56 PM
> To: 'Karl Heinz Wolf'; 'Spencer Dawkins'
> Cc: [email-masked]
> As a practical matter, nearly every country already does 
> that, because of the 1-1-2 action in mobile phones, so I 
> think it's a practical answer.
> 
> Brian
> 
> My question there was: do you think every country having 
> subservices could agree on picking one service as a default 
> sos service?
> > I agree - the alternative, as Karl Heinz suggests, is to 
> pick another 
> > URN, which might ALSO be missing, and/or just start trying 
> services at
> random...
> >
> > Thanks,
> >
> > Spencer
> >
> >> The device could discover home dial strings knowing home 
> country via
> LoST.
> >>
> >>> 1. ED-6 vs ED-9 is the difference between discovery with a home 
> >>> country code and provisioning of actual dial string. We haven't 
> >>> described discovery, so I'll have to delete ED-6
> >>>
> >>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Mar 2009 13:15:34 -0400

Finishing this up

<BR>I'll remove the reference to sip-sips

<BR>It's been discussed, and look at the very next requirement

<BR>see below
[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] 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] 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] 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

<BR>Rewrote to:
User Agents and proxies MUST disable features that will interrupt an

[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

[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] 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] 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] "The test response

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 Mar 2009 21:15:17 +0000

Brian,

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

> Sent: 27 March 2009 17:16
> To: Elwell, John; [email-masked]
[JRE] OK

> <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".

> entities know that LoST routing has not been completed.
[JRE] OK

> subsequent B2BUA maps that to a globally routable URI.
[JRE] Good.

> <xref target="RFC3515"></xref> in that transaction.
[JRE] OK

> standardization will be required to give the UA the ability 
[JRE] Good

> ongoing emergency call, such as:
[JRE] Good

> with the ability of call backs from the PSAP to be completed such as:
[JRE] Good

> <BR>How 'bout I just delete any reference to "flash" and just 
[JRE] OK

> from the list, so I think the meaning is now clear.
[JRE] OK

> [RFC4916] may be used by the PSAP to inform the UA of the 
[JRE] OK

> <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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Mar 2009 17:37:27 -0400

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:[email-masked]] 
Sent: Friday, March 27, 2009 5:15 PM
To: Brian Rosen; [email-masked]
Subject: RE: [Ecrit] Comments on phonebcp-07

Brian,

[JRE] OK

[JRE] OK

[JRE] Good.

[JRE] OK

[JRE] Good

[JRE] Good

[JRE] Good

[JRE] OK

[JRE] OK

[JRE] OK

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 Mar 2009 21:53:55 +0000

> Sent: 27 March 2009 21:37
[JRE] Yes

John