Subject: [Ecrit] ECRIT Architecture Review by Deutsche Telekom

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Mar 2007 13:04:17 +0200

Hi all,

the chairs have sent request for reviews to VoIP providers and we have 
already received a few responses. Here is another one from the Deutsche 
Telekom.

We would like to thank Deutsche Telekom for their honest review comments.

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Mar 2007 11:07:56 -0400

I've looked at the review from Deutsche Telecom and have some comments.

There are three major themes to the response:
1. No one knows if the IMS emergency call support will align with the IETF
ecrit architecture
2. Giving endpoints location has a number of economic, operational, and
possibly legal ramifications
3. It doesn't match existing PSAP systems

In addition, there are some misconceptions about the ecrit approach.

I'd like to examine each of these in turn.

We are well aware of the issues surrounding the alignment of the IETF ecrit
emergency calling architecture and the 3GPP IMS architecture.  As members of
the work group know, there has been significant effort expended between IETF
and 3GPP to explore this issue.  I believe there is intent on both sides to
not allow the architectures to deviate, and indeed 3GPP has gone to great
lengths to make certain that its protocols align with IETF protocols where
they are appropriate.  A great many individual participants in both 3GPP and
IETF are committed to making sure the two architectures align.  Clearly,
getting DT behind the effort to align IMS and ecrit would be beneficial.

I would also point out that nearly every IMS system supports a raw IP packet
service, which typically could allow a device with, for example, a PC Card
to have Internet access.  With such a card plugged into any device which
routes, and has other access connections such as an Ethernet or WiFi,
regular hardwired VoIP phones could be attached to the 3GPP wireless network
and would work through nearly any VoIP service.  These VoIP telephones or
terminal adapters could reasonably be expected to conform to IETF protocols,
and specifically draft-ietf-ecrit-phonebcp (or at least the expected RFC
that it will become).  If these phones cannot place emergency calls because
location is not supplied in a manner the phones can use, the access network
may be liable.  

It would be unreasonable to expect EVERY phone device to conform to IMS
specifications, while it would be reasonable to expect every phone device to
conform to IETF standards in this regard.  While IMS handsets may conform to
different requirements and be able to place emergency calls on any IMS
network, the cost to the carrier who supports both a raw packet service and
an IMS calling service will be significantly larger if there is a divergence
of architecture.  The ability of the access carrier to specify the
requirements of all VoIP end devices is very limited.  Warnings or other
mechanisms that disclaim support for emergency calls on such devices are
unlikely to be acceptable to regulatory authorities.

Further, there is work in several countries to specify next generation IP
based PSAP interfaces.  So far, the IETF standards have been looked upon
favorably, and indeed, in the United States it now seems quite certain that
"Next Generation 9-1-1" systems will conform to IETF standards.  In the U.S.
effort, there is also great interest in assuring that IMS standards and
ecrit standards align, and participants in that effort expect that they
ultimately will.

Turning now to the issues of supplying devices to endpoints, we observe the
quandary that has largely driven this decision: The access network and the
calling network do not have a relationship.  Historically, the calling
network and the access network have come from the same entity.  The Internet
has broken that connection.  It is possible, today, to take a device and use
it from nearly any access network in the world that supplies a raw packet
service and get to any calling network.  Since the emergency calling system
needs a call, there are only three choices:
1. Force relationships between access networks and calling networks to allow
the access network to supply the calling network with location
2. Force all access networks to support emergency calling for all possible
end devices, thus restricting location to the access network.
3. Force the access network to supply location to its subscriber, and have
the subscriber supply it to the calling network, noting that the endpoint is
the customer of BOTH the access network and the calling network.

Forcing relationships between calling and access networks won't scale.
There are thousands to tens of thousands of each, and any calling network
may have to process an emergency call originating on any access network.  My
usual example is a nomadic caller from Sierra Leone, using a Sierra Leone
VoIP service, connecting a softclient through a WiFi Access Point in a café
in Chicago served by a WiFi network with a DSL connection from the local
ILEC.  Trying to create a relationship between the Sierra Leone VoIP
Services Pty and any of Starbucks, T-Mobile Hotspot or AT&T (DSL) is not
feasible. You can claim this is a corner case, but it's happening NOW, and
there are millions of subscribers to VoIP services who are independent of
any access network (e.g. Vonage).  To make it work, the access network has
to trust the calling network that there is an emergency call, that the
putative caller is actually using the access network it is contacting, etc.
Further, it would be necessary to have some kind of identifier that the
calling network can determine, which is known to the access network, and can
be used to identify what location is needed.  Assuming NATs and VPNs, such
identifiers are very difficult to create, especially without the endpoint
directly participating.

We have looked at forcing all access providers, regardless of whether they
offer any kind of calling service, to have to support an emergency calling
service.  We have determined that this is unfeasible.  There is too much
variation in services as seen by endpoints.  For example, Next Generation
PSAPs are expected to allow Instant Messaging.  While the PSAP interface can
reasonably be restricted to SIP/SIMPLE and/or XMPP/Jabber, clients may have
those or AOL AIM, MSN Messenger, Yahoo and/or Skype interfaces.  The access
networks would have to accept a wide range of clients, but interwork to a
small number of PSAP interfaces.  Text, video and voice clients would need
to be supported.  Any form of authentication would be difficult, and PSAPs
do not like unauthenticated callers (although they may accept such calls
anyway).  To expect every access network to pay for the cost of supporting
these services seems unlikely at best.  DG worries about the cost of
supporting the location service; this would be additional costs beyond that.

The latter alternative, requiring access networks to give their own
subscribers their location provides the most practical answer, and also
meets the very real requirements in the IETF architecture to protect the
privacy of location.  The endpoint is the ONLY entity that is known to have
a formal, authenticated, contractual relationship with BOTH the access
network and the calling network.  This is always true one way or the other;
albeit in some networks, the endpoint has a formal relationship with a home
network, that network has an existing relationship with the visited network,
and all of the issues solved by the endpoint getting location from the
access network hold.

With respect to privacy, if the only entity that gets the location is the
endpoint, then it can decide who else gets it.  It could subsequently
delegate some service to serve as its location provider (e.g. presence
service), but assuming the access network is the subscribers location
service of choice is not seen as conducive to allowing users to control the
privacy of their own location.  We understand the economic implications of
this architecture.  In theory, if the endpoint has its location, it can give
it to anyone else, and the access network may not receive any payment.  It
may be permissible, in some environments, to prevent this contractually.
It’s also quite clear that IMS standards will support endpoints getting
their own location and unless DT intends to prohibit this (and thus restrict
the range of applications that can execute on IMS endpoints), that
particular issue is moot.

With respect to PSAP interfaces, as DT well knows, there are no
international standards for TDM interfaces to PSAPs.  Every country has
their own standards.  Networks have had to cope with these issues, and will
continue to have to cope.  Next Generation, IP based PSAPs may not have such
variation.  There is reason to hope that international standards, and
probably IETF standards, will be able to be adopted worldwide for emergency
calling.  The benefits to DT and other carriers are obvious.  Again, the
benefits of alignment between IETF standards and 3GPP standards are obvious
if this occurs.  IETF does not believe it is feasible to standardize
mechanisms that will work with ALL existing TDM based emergency calling
networks.

We do observe, however, that it seems feasible to interwork most of the IETF
emergency calling architecture to existing standards on a case by case
basis.  The LoST based routing mechanisms may not be able to be used in all
cases, but the location, marking, and other components of the ecrit
architecture do seem to map fairly well into existing systems.  DT may wish
to look at the NENA i2 standard to see how the ecrit location architecture,
in particular, smoothly integrates into existing North American PSAP
networks.  The nomadic cases will fail, of course, which is a large
incentive to move to IP based PSAP interfaces that don't have the
restrictions of current networks.

Finally, the DT paper has some misconceptions about the IETF ecrit
architecture.  Most prominent among these is the assumption that there is
some kind of relationship between the SIP REGISTER and any other part of
emergency calling.  There is not.  It would be common for the endpoint to
REGISTER on boot, and it is specified that the endpoint should get location
at boot, and periodically thereafter, but those operations are independent.
The endpoint's interactions between it and the access network and between it
and the calling network are separate until there is an emergency call.

Some other specifics:
In point 3, DT worries about the liability of providing location when the
device may be corrupted.  I do not understand this issue.  The access
network has never been held liable for any other information it may supply
the device when it is corrupted, why would location be treated differently?
IMS standards permit devices to learn their location.  Would this engender
the same concerns?

With respect to point 4, there are some who believe that contractual
limitations may be effective in preventing location dereferences where there
is not a genuine emergency and no other arrangements have been made.  In
general, I do agree that when a location is dereferenced as part of an
emergency call, the LIS cannot demand any form of credential, or we are back
to the problem of forcing relationships between access networks and calling
networks.

In point 6, I do not believe the ecrit architecture would permit callers to
dial the PSAP directly.  The caller would use the sos urn marking, and route
with LoST to a URI that was the "front door" of the PSAP.  The PSAP could,
theoretically, restrict who can place calls through that front door, but as
a practical matter, as with the example of Sierra Leone VoIP services PTY,
the Chicago PSAP is unlikely to have some kind of authorization in place for
the Sierra Leone call.  The notion that calls only come from
known-in-advance, small number of domestic carriers is an anachronism of the
PSTN, and no longer holds on the Internet. The law may have to change to
reflect reality.  That would be up to the German regulators, of course, but
in my discussions with EU regulators, they seem to grasp the issues, even if
they wish it were not so.

Point 7 refers to what is called "Location Update".  The IETF documents
(-phoneBCP) specifically suggests that devices get location when they boot,
periodically thereafter, AND JUST BEFORE PLACING THE EMERGENCY CALL.  It is,
of course, best if the route chosen for the call is based on the current
location of the caller.  However, the IETF ecrit architecture is designed to
work in stressful situations (such as disasters), in which, when the
emergency call is placed, some of the infrastructure is busy or not
available.  In these circumstances, cached location should be used, in
preference to no location, or failing the call.  Although getting location
at boot and periodically thereafter does place some load on the location
infrastructure, it is fairly minimal (devices don't boot often, and the
update interval can be controlled by the access network).  The load is much
less than most location based services, and does help substantially in
disaster scenarios.  Note that in most mobile networks, it may be reasonable
to provide a coarse, cell site/sector based location until the emergency
call is placed if the location determination infrastructure can't reasonably
support more accurate location determination.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2007 7:04 AM
> To: ECRIT
> Cc: Liess, Laura
> Subject: [Ecrit] ECRIT Architecture Review by Deutsche Telekom
> 
> Hi all,
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Mar 2007 11:51:51 -0400

Some additional remarks inline.

> any access network (e.g. Vonage).  To make it work, the access  

It is also quite likely that even if an ILEC provides VoIP service,  
that it would want this service to work outside of its own network.  
In other words, DT will, in order to be competitive with other  
providers, want to be able to have its VoIP users use non-DT access  
networks, e.g., while traveling, using a public hot spot  or visiting  
neighbors. Thus, even DT has an incentive to make this type of  
arrangement work. Naturally, this is not a concern if DT is not  
interested in selling VoIP service at all.

> particular issue is moot.

To emphasize a point you hinted at earlier: the customer is already  
paying for location information, by subscribing to the DSL or similar  
service. Since location is fundamentally an access network service,  
unbundling it makes as much sense as charging separately for getting  
an IP address or IP packets, since they can also used by other  
entities to derive value.

It should also be noted that there are regulatory models in the US  
that allow network providers to charge customers for emergency- 
calling related services (the 9-1-1 tax). The model has its flaws,  
but it is disingenuous to claim that there is no alternative beyond  
giving location information "for free" (as untrue as that is) or not  
giving it out at all.

> architecture do seem to map fairly well into existing systems.  DT  

In particular, LoST can easily point to a proxy, which dials the  
'hidden' PSTN number through a special gateway, so that the number is  
never visible to callers.

> IMS standards permit devices to learn their location.  Would this  

Plus, a corrupted device could easily just snoop on audio, likely  
obtaining far more sensitive data. (Besides, users will enter their  
home location on e-commerce web pages, so a keyboard sniffer can  
easily get this data on a machine that has been 0wned.) I'll also  
note that DT (used to?) use telephone numbers as identifiers for DSL  
customers; these numbers provide fairly fine-grained location and  
identity information. (In Germany, area codes are often specific to a  
small community of no more than a few thousand people, so even  
unlisted numbers provide lots of location detail that is likely  
equivalent to the amount of detail needed for PSAP routing.)

Henning