Subject: [Ecrit] Phone BCP: Multiple Location

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Mar 2008 22:55:17 +0300

"
   ED-39 If a UA has more than one location available to it, it MUST
   choose one location to route the call towards the PSAP.

   SP-16 If a proxy inserts location on behalf of an endpoint, and it
   has multiple locations available for the endpoint it MUST choose one
   location to use to route the call towards the PSAP.
"

I could imagine that someone might ask how to make a decision.
So, how does the decision making look like?

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 30 Mar 2008 16:18:05 -0400

I think -framework motivates how you do it:
   Getting multiple locations all purported to describe the location of
   the caller is confusing to all, and should be avoided.  Handling
   multiple locations is discussed in .  Conflicting location
   information is particularly harmful if different routes (PSAPs)
   result from LoST queries for the multiple locations.  When they occur
   anyway, the general guidance is that the entity earliest in the chain
   generally has more knowledge than later elements to make an
   intelligent decision, especially about which location will be used
   for routing.  It is permissable to send multiple locations towards
   the PSAP, but the element that choses the route must select one (and
   only one) location to use with LoST.

   Guidelines for dealing with multiple locations are also given in
   [I-D.ietf-ecrit-lost].  If a UA gets multiple locations, it must
   choose the one to use for routing, but it may send all of the
   locations it has in the signaling.  If a proxy is inserting location
   and has multiple locations, it must choose the one to use to route
   and send any others it has.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Sunday, March 30, 2008 3:55 PM
To: [email-masked]
Subject: [Ecrit] Phone BCP: Multiple Location

"

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 30 Mar 2008 15:35:33 -0500

PIDF-LO profile describes how to choose the correct location for exactly this purpose.
That is the application form which the original requirements were drawn.

-----Original Message-----
From: [email-masked] on behalf of Hannes Tschofenig
Sent: Sun 3/30/2008 2:55 PM
To: [email-masked]
Subject: [Ecrit] Phone BCP: Multiple Location
 
"

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 31 Mar 2008 09:05:34 -0400

It's my understanding that PIDF-LO only describes multiple location
precedence within a single message. It doesn't describe how to
prioritize multiple locations received from various  sources, received
in multiple messages (or statically configured) at various times.

I did include that sort of logic in my latest DSLF draft. If there is a
desire to have some of this in phonebcp, I'm fine with that.
Barbara 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Winterbottom, James
Sent: Sunday, March 30, 2008 4:36 PM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [Ecrit] Phone BCP: Multiple Location

PIDF-LO profile describes how to choose the correct location for exactly
this purpose.
That is the application form which the original requirements were drawn.

-----Original Message-----
From: [email-masked] on behalf of Hannes Tschofenig
Sent: Sun 3/30/2008 2:55 PM
To: [email-masked]
Subject: [Ecrit] Phone BCP: Multiple Location
 
"

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 31 Mar 2008 15:08:25 +0200

Should we at least reference PIDF-LO profile and indicate constraints? 

-------- Original-Nachricht --------
> Datum: Mon, 31 Mar 2008 09:05:34 -0400
> Von: "Stark, Barbara" <[email-masked]>
> An: "Winterbottom, James" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, [email-masked]
> Betreff: RE: [Ecrit] Phone BCP: Multiple Location

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 31 Mar 2008 15:28:53 -0500

Nope.

This is from PIDF-LO Profile 

" Rule #9:  Where multiple PIDF documents can be sent or received
      together, say in a multi-part MIME body, and current location
      information is required by the recipient, then document selection
      SHOULD be based on document order, with the first document considered first."

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Hannes Tschofenig
Sent: Sun 3/30/2008 2:55 PM
To: [email-masked]
Subject: [Ecrit] Phone BCP: Multiple Location
 
"

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 31 Mar 2008 22:29:48 -0400

Key words are "Where multiple PIDF documents can be sent or received
together". When a device has a configured location, a location from
LLDP-MED, one from DHCP, and one or two (routing and dispatch) from
HELD, I think that the quoted language has no relevance on the order in
which these are then included in an "sos" message. These different
locations were not received together. LLDP-MED and DHCP locations are
not received as PIDF documents.

This language does apply to the PSAP when it receives all of these
locations. They arrive together, and all in PIDF format.
Barbara 

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 4:29 PM
To: Stark, Barbara; Hannes Tschofenig; [email-masked]
Subject: RE: [Ecrit] Phone BCP: Multiple Location

Nope.

" Rule #9:  Where multiple PIDF documents can be sent or received
      together, say in a multi-part MIME body, and current location
      information is required by the recipient, then document selection
      SHOULD be based on document order, with the first document
considered first."

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Hannes Tschofenig
Sent: Sun 3/30/2008 2:55 PM
To: [email-masked]
Subject: [Ecrit] Phone BCP: Multiple Location
 
"

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 31 Mar 2008 21:37:58 -0500

I think that we need to be really careful about what kind of systems we
are talking about then.

For example RFC 3261 is extremely clear about what a proxy can and
cannot do with a SIP body. So if extra body elements are being inserted
then we better not be calling this thing a proxy.

PIDF-LO profile is clear about how to interpret what is provided. So, my
previous paragraph aside for one second, things upstream from the device
originating the call MUST only be providing location if they believe
that the location they are providing is better than that that is already
provided. Assuming this premise holds true, then the rules for inclusion
are clear, the new location must appear ahead of any existing location
information.

Cheers
James

> Sent: Tuesday, 1 April 2008 1:30 PM
> ------------------------
> [mf2]
> 
> 
> *****
> 
> The information transmitted is intended only for the person or entity
to
> which it is addressed and may contain confidential, proprietary,
and/or
> privileged material. Any review, retransmission, dissemination or
other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited.
If
> you received this in error, please contact the sender and delete the
> material from all computers. GA622
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 31 Mar 2008 21:45:33 -0500

Hi Barbara,

Having re-read your email I think I misunderstood what you were saying.
I think what you are saying is that if a device engages all three LCPs
and gets a different location for each of them, what does it do?

I think the correct answer is that it should only try 3 methods if the
first 2 failed. That is, it tries one method, if that doesn't work, it
tries the next one.

In the HELD routing/dispatch example I hope that we can say always use
dispatch since the dispatch location kind of needs to fall into the
catchment of the routing area to make any sense.

I think we should avoid trying to get as many different locations as we
can.

As for DHCP and LLDP-MED I am not sure that I understand your last
sentence in the first paragraph. I am not aware that we considering
sending a literal location in any form other than a PIDF-LO with the sos
message.

Cheers
James

to
and/or
other
If

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 1 Apr 2008 08:47:18 -0400

Hey James,
I agree with your statement in your other email about proxies. I thought
I had also read that proxies can only insert LbyR, because they aren't
supposed to insert stuff in the body. And I think that proxies that have
multiple locations for an endpoint are beyond anyone's help in writing
recommendations for decision making. We don't know what those locations
are or where they came from.

I'm really only concerned with end devices and "intermediate devices",
like home routers.  If you say that devices "should" only try 3 methods
if the first 2 failed, that means that it's ok if they want to just do
all 3. There's no prohibition against trying multiple methods. And a
configured location may also be available. Recommendations for how an
end device prioritizes these (if it happens to get multiple locations),
before sending them out, are included in my document. And I'm not going
to remove those recommendations just because devices "should" try to
avoid having multiple locations.

My statement on LLDP-MED and DHCP was that the location sent by those
protocols does not arrive at the end device in PIDF-LO format. I was
mentioning that the PIDF rules on prioritizing received PIDF locations
state that they apply to received PIDF locations. LLDP-MED and DHCP
locations are not received by the end device as PIDF locations.
Therefore the rules do not apply. They are also not received "together".
Therefore, the rules do not apply. If recommendations are needed for
handling multiple locations at an end device (and I believe they are),
then I am saying that the PIDF rules are necessary (for multiple PIDF
received together) but insufficient (for multiple locations gotten in a
variety of ways), and that the PIDF document is the wrong place for
comprehensive  recommendations that take into account a variety of
permutations of how devices get location.
Barbara

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 10:46 PM
To: Stark, Barbara; Hannes Tschofenig; [email-masked]
Subject: RE: [Ecrit] Phone BCP: Multiple Location

Hi Barbara,

Cheers
James

to
and/or
other
If

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623