Subject: RE: [Sip] Second Comment on draft-ietf-sip-location-conveyance-00

From: "James M. Polk" <[email-masked]>
Date: Thu, 07 Jul 2005 19:19:55 -0500

Sebastien

At 11:45 AM 7/1/2005 +0200, PROUVOST Sebastien RD-CORE-ISS wrote:

>Hi,
>I fully agree with John.

I hope I just answered his concerns with the limitations of the existing 
SIP architecture and emergency calling in the message I just sent to the 
list. Let me address your questions directly here

>The solution presented in the draft that says that if the UAC do not 
>insert the location in the INVITE and if its outbound proxy has the info 
>and wants to have it included it into the INVITE, it returns it in a 4xx 
>"Retry Location Body" has several drawbacks :
>
>- What if the UAC issues the new INVITE that does not contains the 
>location object

I'll turn this one around on you: What if the only INVITE were received by 
the outbound proxy with no location included... where would that Proxy 
route the message to?

Because there is no realm or domain part of a emergency call today, there 
is no place for SIP servers to look up where the UAC is or the destination 
UAS is to route the message to. The message will not go anywhere today. So 
we need an extension to SIP to accomplish this.

This document is to address what needs to be done in SIP to convey 
location. The ECRIT WG is chartered with how to take a well formed SIP 
message (with location) and route it towards the appropriate PSAP.

>(because it does not support this draft for example). If the call does not 
>go through, this is a very big issue when the call is an emergency call.

I fully agree - yet I do not see another way of solving this issue other 
than to have location in the INVITE. Let me explain this:

If you want location to be in a header, the UAC doesn't have that 
information unless it's told that information - or - the SIP proxy server 
inserts this header in the INVITE message once it determines it is an 
emergency call. This means the SIP Proxy always has to know where the UAC 
is. That sounds like the SP is tracking the UAC. That enables tracking of 
users through their UAs.

Doesn't this have some privacy concerns?

Do you want to be tracked everywhere you go for the one or two times in 
your life you call 911 or 112?

Further, what if I merely want to send my location to you in an IM. Do I 
have to rely on a tracking SP to insert it into my MESSAGE Request message 
towards you in order for you to receive it from me?

What if I use two different SPs: one for Voice and one for IM. Now I have 
to have two SPs tracking me all the time because IM will be just as easy to 
use in the near future for emergency services as voice calling 911/112 is 
today. Where does this additive SPs stop? How many SPs need to be able to 
track me (through my UAC) to provide location conveyance services? This is 
every minute of every day, 7 days a week, 365 days a year, on every UAC you 
and I own.

>As a service provider we cannot rely on the capacity of the UAC to allow 
>emergency calls to go through.

What if your UAC's have a GPS? Is this not the best means of determining 
location of the UAC? Is this going to be forbidden? If it is not, then we 
have to have a consistent means for allowing a GPS assisted UAC to convey 
its location for whatever purpose, even emergencies.

I believe you have a trust issue with the system. That's a separate issue - 
and a lot of folks have that belief. If the designed system isn't good 
enough, design a better system.

>- What if the UAC issues a new INVITE that contains the location object 
>but that does not correspond to the one the proxy gave.

Then that is not a well behaving UAC. Folks that call for emergency want to 
get help. If their UAC fails on them, it fails. What if I have an emergency 
today and my existing GSM phone fails for whatever reason? It also fails. 
I'm in just as much trouble. We need to build the best products for each 
situation, but the IETF isn't defining products themselves, it's defining 
protocols and triggers within protocols to provide features/functions.

>- This solution introduces a supplementary exchange between the UA and its 
>proxy which introduces an additional delay to the call establishement 
>(especially important if the UA is over a radio access).

how much more delay do you expect this single exchange to cause? It's one 
round trip between one application layer hop - it's not that much time. 
But, do you have a figure in mind that makes this undesireable?

>If the draft stays as it is, this is one more reason why service providers 
>would need an SBC

and this isn't going to inject any delays? huh?

>  : in order to be able to insert location information to an INVITE 
> request without requiring any UA intervention.

this will require the SBC to be completely stateful as to where EVERY UAC 
is at all times just in case a UAC calls for an emergency. That means every 
second of every day for the life of that UAC, and every other UAC within 
that realm. Do you believe that will scale?

Do you believe that will not cause delay in the look-up of where a 
particular UAC is in a location database?

Does the SBC have this database local for all UACs that it could receive a 
911/112 INVITE from, or is this datebase more centralized within the SP realm?

How many SBCs are you expecting per realm?

How current is the database of UAC locations among all SBCs?

I'm having a hard time believing an SBC inserting location into the INVITE 
will increase efficiency. I think getting location down into the UAC is the 
most efficient means of location conveyance - especially for emergency calling.

>It is necessary for a proxy to be able to insert this location info 
>without having to rely on the UA's intervention.

Why is it necessary?

>Sebastien.
>
>
>----------
>De : [email-masked] [mailto:[email-masked]] De la part de 
>Elwell, John
>Envoyé : mercredi 29 juin 2005 11:19
>À : [email-masked]; [email-masked]
>Cc : [email-masked]
>Objet : [Sip] Comment on draft-ietf-sip-location-conveyance-00
>
>James, Brian,
>
>In section 9 (special provisions for emergency calls) it states:
>
>"In the case where the Proxy knows the location of the UAC and does not 
>detect the UAC's location information message body in the message (or 
>determines the LO is bad), the Proxy generates a new 4XX (Retry Location 
>Body) error message that includes a location information message body for 
>that UAC to include in the subsequent message.  The user agent MUST 
>include this message body in the subsequent emergency message."
>
>This places a new requirement on the UAC, which will not be met by UACs 
>that are not compliant to this document. It seems emergency calls from 
>such UACs will fail.
>
>Regards,
>
>John

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Fri, 8 Jul 2005 11:12:10 +0200

James,

Fist, sébastien wasn't arguing against the need for an extension in the INVITE, we fully support this. The problem is that network operators have one very important goal:

- the need to support a large range of terminals, not only complex ones and this requirement is even stronger when dealing with emergency calls. 

The solution proposed here might have some benefits for certain situations, but it would be a pity not to come up with a solution that doesnot require any specific terminal functionnality and would most likely cause non-standardized solution to be used.

Sébastien G.

-----Message d'origine-----
De : James M. Polk [mailto:[email-masked]] 
Envoyé : vendredi 8 juillet 2005 02:20
À : PROUVOST Sebastien RD-CORE-ISS; Elwell, John; [email-masked]
Cc : [email-masked]; GARCIN Sebastien RD-CORE-ISS
Objet : RE: [Sip] Second Comment on draft-ietf-sip-location-conveyance-00

Sebastien

>I fully agree with John.

I hope I just answered his concerns with the limitations of the existing SIP architecture and emergency calling in the message I just sent to the list. Let me address your questions directly here

>insert the location in the INVITE and if its outbound proxy has the 
>info and wants to have it included it into the INVITE, it returns it in 
>a 4xx "Retry Location Body" has several drawbacks :
>

I'll turn this one around on you: What if the only INVITE were received by the outbound proxy with no location included... where would that Proxy route the message to?

Because there is no realm or domain part of a emergency call today, there is no place for SIP servers to look up where the UAC is or the destination UAS is to route the message to. The message will not go anywhere today. So we need an extension to SIP to accomplish this.

This document is to address what needs to be done in SIP to convey location. The ECRIT WG is chartered with how to take a well formed SIP message (with location) and route it towards the appropriate PSAP.

>(because it does not support this draft for example). If the call does 
>not go through, this is a very big issue when the call is an emergency call.

I fully agree - yet I do not see another way of solving this issue other than to have location in the INVITE. Let me explain this:

If you want location to be in a header, the UAC doesn't have that information unless it's told that information - or - the SIP proxy server inserts this header in the INVITE message once it determines it is an emergency call. This means the SIP Proxy always has to know where the UAC is. That sounds like the SP is tracking the UAC. That enables tracking of users through their UAs.

Do you want to be tracked everywhere you go for the one or two times in your life you call 911 or 112?

Further, what if I merely want to send my location to you in an IM. Do I have to rely on a tracking SP to insert it into my MESSAGE Request message towards you in order for you to receive it from me?

What if I use two different SPs: one for Voice and one for IM. Now I have to have two SPs tracking me all the time because IM will be just as easy to use in the near future for emergency services as voice calling 911/112 is today. Where does this additive SPs stop? How many SPs need to be able to track me (through my UAC) to provide location conveyance services? This is every minute of every day, 7 days a week, 365 days a year, on every UAC you and I own.

>As a service provider we cannot rely on the capacity of the UAC to 
>allow emergency calls to go through.

What if your UAC's have a GPS? Is this not the best means of determining location of the UAC? Is this going to be forbidden? If it is not, then we have to have a consistent means for allowing a GPS assisted UAC to convey its location for whatever purpose, even emergencies.

I believe you have a trust issue with the system. That's a separate issue - and a lot of folks have that belief. If the designed system isn't good enough, design a better system.

>but that does not correspond to the one the proxy gave.

Then that is not a well behaving UAC. Folks that call for emergency want to get help. If their UAC fails on them, it fails. What if I have an emergency today and my existing GSM phone fails for whatever reason? It also fails. 
I'm in just as much trouble. We need to build the best products for each situation, but the IETF isn't defining products themselves, it's defining protocols and triggers within protocols to provide features/functions.

>- This solution introduces a supplementary exchange between the UA and 
>its proxy which introduces an additional delay to the call 
>establishement (especially important if the UA is over a radio access).

how much more delay do you expect this single exchange to cause? It's one round trip between one application layer hop - it's not that much time. 
But, do you have a figure in mind that makes this undesireable?

Why is it necessary?

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 08 Jul 2005 14:13:02 -0500

At 11:12 AM 7/8/2005 +0200, GARCIN Sebastien RD-CORE-ISS wrote:
>James,
>
>Fist, sébastien wasn't arguing against the need for an extension in the 
>INVITE, we fully support this. The problem is that network operators have 
>one very important goal:
>
>- the need to support a large range of terminals, not only complex ones 
>and this requirement is even stronger when dealing with emergency calls.
>
>The solution proposed here might have some benefits for certain 
>situations, but it would be a pity not to come up with a solution that 
>doesnot require any specific terminal functionnality and would most likely 
>cause non-standardized solution to be used.

There are a few requirements that need to be met for emergecny calls:

1) determine the call is an emergency call
2) determine where the UAC is
3) route the call set-up messages to the appropriate PSAP for that UAC
4) update the location of the UAC to the PSAP if the UAC moves

#1 above is solved by Henning's sos@ document

#2 is hard. There are several documents addressing this (RFC3825, Henning's 
civic version that's still an ID), and there is GPS locally to the UAC, or 
manual configuration. The hardest part of #2 is that this needs to be good 
100% of the time, meaning something has to be statefully aware of the UAC's 
location wherever it is every second of every day (I feel I'm repeating 
myself). So, is that statefulness in the UAC or in a server (or series of 
servers) within a domain/realm? The most scalable location for this 
information is in the UAC. Getting the info to the UAC is easy for wired 
and limited range wireless devices. It gets harder for longer range 
wireless devices.

I believe in the US that cellular location determination is conveyed on the 
PSAP operator's terminal something like 15 seconds after the call is placed 
to the PSAP. This means the call is routed to the most likely PSAP based on 
the originating cell tower the signal came from. Once at the PSAP, sw there 
goes out and searches for the actual location of the caller (cell twoer 
triangulation providing GPS coordinates - which get mapped to a street map 
database, which generates a street address for where the caller is).

#3 can be solved once the location of the UAC is determined and forwarded 
to the PSAP, because each should have a database to resolve the specific 
location of the UAC to its proper PSAP. The ECRIT WG is chartered with 
solving this.

Once any PSAP receives the call, it should be able to "transfer" the call 
to the more appropriate PSAP (if the original PSAP wasn't the correct one). 
This should direct and could be over quite secure communications between 
PSAPs that know each other through an SA.

#4 is not so hard if the UAC knows its location and determines it has 
moved. At last year's Minneeapolis meeting, the WG was quite clear that the 
UPDATE Method is to be used by the UAC to update its location even after 
the dialog has been established.

If the UAC does not know its location, then whatever is statefully aware of 
the UAC's location will have to convey that change in UAC location to the 
PSAP about the UAC. I'm not sure at all what message that would be. Would 
the Proxy originate an UPDATE message towards the PSAP UAS that the 
original UAC knows nothing about? I can see that being messy, as I can see 
the (PSAP) UAS 200 OKing to the user's UAC (which would be ignored because 
it didn't originate the UPDATE).

>to have two SPs tracking me all the time because IM will be just as easy 
>to use in the near future for emergency services as voice calling 911/112 
>is today. Where does this additive SPs stop? How many SPs need to be able 
>to track me (through my UAC) to provide location conveyance services? This 
>is every minute of every day, 7 days a week, 365 days a year, on every UAC 
>you and I own.
>
>I believe you have a trust issue with the system. That's a separate issue 
>- and a lot of folks have that belief. If the designed system isn't good 
>Then that is not a well behaving UAC. Folks that call for emergency want 
>to get help. If their UAC fails on them, it fails. What if I have an 
>emergency today and my existing GSM phone fails for whatever reason? It 
>also fails.

cheers,
James

                                 *******************