Subject: [Ecrit] Presentation at Wimax Forum

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Aug 2007 14:42:03 +0200

Hi all,

I had the chance to attend the Wimax Forum meeting last week and I gave 
a presentation about the work in ECRIT. My slides can be found here: 
http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/WebHome/Emergency-Services.ppt

In the slide set I describe three variants of emergency call signaling 
and I wanted to double-check whether you believe that a description 
about them should be added to the framework document (see slide 17,18, 
and 19).

Ciao
Hannes

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Aug 2007 09:36:53 -0400

You have a typo on slide 17, the first two bullets are the same.
On slide 18, I do not want the endpoint sending the call direct to the PSAP
unless that is it's normal call processing path.  If it normally sends the
call to an outbound proxy, I want the call to go to it's outbound proxy.
Among other things, I want the carrier to deal with identity.

You have neglected the step of recognizing the dial string.  This is
important because in many current systems the endpoint does not do dial
string interpretation.  It's important that the endpoint recognize the local
dial string, because the proxy doesn't have the location of the endpoint
normally, and thus cannot determine what the local dial string is.
You should discuss this issue if you are going to cover the issues of proxy
route.

You should also mention that in the 3rd case, either the proxy has to track
the endpoint's location so that it can determine what the local dial string
is if the proxy is doing dial string interpretation, or the endpoint has to
be given the local dial string when it's location crosses a national
boundary.  You might also note the LoST boundary mechanism which is helpful
for this.

I don't foresee any circumstances where the access network must supply the
calling proxy except in a case like a 3GPP visited network, where the access
network has an explicit agreement with the home network to handle emergency
calls.  Unauthenticated access, if it is actually deployed, must allow the
call to get to any proxy.  If, for example, a Vonage subscriber roams to
some network, it is Vonage that must complete the call.  There is no way
that the Vonage device will be able to find or use some other proxy to
complete the call. So I would say the last point on slide 22 is wrong.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, August 27, 2007 8:42 AM
> To: ECRIT
> Subject: [Ecrit] Presentation at Wimax Forum
> 
> Hi all,
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 27 Aug 2007 10:15:58 -0400

Hannes,

Those three cases are a good start, but the other location dependent 
operation (dial string acquisition) should be incorporated as well.  I 
would state it in two parts:

1. There are three things to do in order for emergency calls to work. 
(In this section, explain how each is accomplished).
1.a. Determine location
1.b. Determine dial strings (and use them to recognize em. calls)
1.c. Determine correct PSAP URIs

2. Each step can be done either by the endpoint or by a proxy, subject 
to the constraints that dial-plan interpretation and routing can only be 
done after location is acquired, and routing will only be done after a 
call is determined (based on a dial-string) to be an emergency call. 
This leaves four cases:
2.a. Endpoint does positioning, interpretation, and routing
2.b. Endpoint does positioning and interpretation, Proxy does routing
2.c. Endpoint does positioning, Proxy does interpretation and routing
2.d. Proxy does positioning, interpretation, and routing

[
When the endpoint doesn't base its dial-plan interpretation on its 
location (e.g., with "home" numbers), there's also the scenario
2.e. Endpoint does interpretation, Proxy does positioning and routing
]

--Richard

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 27 Aug 2007 16:34:27 +0200

I agree with the cases you listed.  See also Henning's old slides on this subject: 
http://www3.ietf.org/proceedings/06mar/slides/ecrit-3/sld3.htm

With 2.e you can also add cases where the end host is pre-configured with certain emergency numbers. 

The question is only: Should we describe the cases in a more systematic way in the framework document or are we happy with the current description?

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext Richard Barnes [mailto:[email-masked]] 
> Gesendet: Montag, 27. August 2007 16:16
> An: Hannes Tschofenig
> Cc: ECRIT
> Betreff: Re: [Ecrit] Presentation at Wimax Forum
> 
> Hannes,
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Aug 2007 10:51:21 -0400

I'll try to be more systematic about it.  This is the same tradeoff: do you
discuss first location, then dial string, then LoST, or you discuss first
endpoints then proxies then PSAPs?  My current answer is you start with a
walk through, step by step, pointing out alternatives.  Then you circle back
and show what each entity's responsibilities are.

You can only pre-configure universal numbers (1-1-2) and home dial strings.
You can't preconfigure local dial strings unless you know for certain that
the device can't move.  The access network could tell you that (the REAL
access network, not the one you think you are attached to), but we have no
way presently to communicate that.  Consider the RV with a wired phone on a
router.  The "access network" as seen by the phone is a LAN.  The access
network as seen by the router is the mobile data network.  The mobile data
network knows the whole LAN is mobile, but the LAN wouldn't unless it was
told.

Brian

> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
> [mailto:[email-masked]]
> Sent: Monday, August 27, 2007 10:34 AM
> To: ext Richard Barnes; Hannes Tschofenig
> Cc: ECRIT
> Subject: AW: [Ecrit] Presentation at Wimax Forum
> 
> The question is only: Should we describe the cases in a more systematic
> way in the framework document or are we happy with the current
> description?
> 
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Aug 2007 16:55:51 +0200

Hi Brian,

> and show what each entity's responsibilities are.
I certainly see the problems when describing this in a systematic way.
I am just sure that we need more figures.

> network knows the whole LAN is mobile, but the LAN wouldn't unless it was
I agree with you.

Ciao
Hannes

>>>> I had the chance to attend the Wimax Forum meeting last
>>>>         
>>> week and I gave
>>>       
>>>> a presentation about the work in ECRIT. My slides can be
>>>>         
>>> found here:
>>>       
>>>> In the slide set I describe three variants of emergency
>>>>         
>>> call signaling
>>>       
>>>> about them should be added to the framework document (see
>>>>         
>>> slide 17,18,
>>>       
>>>> and 19).
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 27 Aug 2007 18:12:28 +0200

Hi Brian, 

I copied this part of your response into a separate mail since it
touches a separate subject:

>  Unauthenticated access, if it is actually deployed, 
> must allow the
> call to get to any proxy.

What do you mean by any proxy? 

There are different cases that you need to consider: 

* In case that the end host does not have credentials for its VoIP
provider (as it is the case with uninitialized phones or also with
SIM-less phones) then there is no "VoIP provider". There is only the
local access network. 

* There is also the case where a phone with credentials is just
disallowed to attach to the network for security reasons. I guess you
refer to this scenario and you ignore the first one. 

  If, for example, a Vonage 
> subscriber roams to

If you would like to deal with fraud* then you need to provide
functionality in the access network to understand that this is indeed an
emergency call.

(*): With fraud I mean that I could connect to every network and claim
to make emergency calls while I am doing something else. 

I agree that 
http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-a
ccess-00.txt
is a bit blank on this aspect. 

I believe that there are the following ways to deal with this aspect: 

*  3GPP IMS emergency services architecture approach: This is handled
like a roaming case where the SIP messages travel through the
P-CSCF/E-CSCF all the way to the home network to provide call-back and
to deal with the identity stuff.

* Diameter SIP application: The proxy in the visited network acts as a
Diameter client and contacts the home AAA server with regard to the
identity info 

* Available Certs: You assume that the end host already has some
credentials that can be used for authentication in this scenario. For
example, the end host has a cert that can be used by the PSAP (such as a
device certificate). 

* You ignore identity information in this case.

Is there anything else that comes to your mind? 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 27 Aug 2007 18:17:37 +0200

Hi Brian, 

> You have a typo on slide 17, the first two bullets are the same.
You are right. It should read: 

Model 1: Location Information is provided to End Host and PSAP URI is
determined by End Host
Model 2: Location Information is provided to End Host and PSAP URI is
determined by proxy
Model 3: Location Information is attached by a Proxy

> Among other things, I want the carrier to deal with identity.

Slide 18: Model 1: End Host does the Job

Correct. You use the normal call processing path. I indicated this
saying "The INVITE might be sent to the PSAP directly."

> You should discuss this issue if you are going to cover the 

Correct. It is important to determine the dial string as well. 
>From this point of view model 1 provides all you want. 

Model 2 leaves this aspect unspecified and model 3 covers it again since
the proxy is in the access network, hence it knows the visited emergency
number. 

> boundary.  You might also note the LoST boundary mechanism 

Correct. The proxy case has to determine the location and has todo the
dial string interpretation. 

> calls.

During the last IETF meeting I recall that someone said that this is
quite likely in enterprise networks. 
To me that sounds like a reasonable thing. 

Ciao
Hannes

> http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/WebHome/
> Emergency-
> > Services.ppt
> >

---

From: Richard Barnes <[email-masked]>
Date: Mon, 27 Aug 2007 12:20:15 -0400

> and show what each entity's responsibilities are.

How about a third approach?
1. Example walk-through that shows all the steps, with actors.  E.g. 
Endpoint does location and dial-plan recognition; proxy does LoST routing.
2. Technical description of the steps, independent of actors.
3. Assignment of technical requirements per entity/actor

That said, I'm not sure that "entity responsibilities" are really 
well-defined independent of the 4-5 scenarios from my email to Hannes. 
That is, if you're in situation 2.d. (Proxy does everything), then the 
requirements for the endpoint and the proxy, are different than if 
you're in situation 2.a. (Endpoint does everything).

Perhaps a way to address this is to replace part 3 above with 3.a. 
through 3.d. corresponding to the use cases.  Each section would explain 
the duties of each entity in that case, and prerequisites for that case 
to be viable (e.g., the ability of the proxy to do positioning wherever 
the endpoint connects).  Which case applies to a particular instance of 
an entity would depend on the (layer 8) relationship(s) between 
endpoints, proxies, and networks.

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 28 Aug 2007 09:19:35 +0200

Hi Richard,

> you're in situation 2.a. (Endpoint does everything).
I totally agree with you.

> through 3.d. corresponding to the use cases.
But the "walk-through" (1) would be different for each of the cases.
>   Each section would explain the duties of each entity in that case, 
> and prerequisites for that case to be viable (e.g., the ability of the 
> proxy to do positioning wherever the endpoint connects).  Which case 
> applies to a particular instance of an entity would depend on the 
> (layer 8) relationship(s) between endpoints, proxies, and networks.
>
Ciao
Hannes

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Aug 2007 10:58:53 -0400

>> 3. Assignment of technical requirements per entity/actor
<snip/>
 > But the "walk-through" (1) would be different for each of the cases.

You're right that the actual sequence of steps would differ in each 
case, but the steps involved are the same.  So let me modify my proposal 
to try to clarify what I mean:

0. High-level description
0.a. Steps involved in an emergency call
0.a.1. Configuration of dial strings (manual, LoST, or other)
0.a.2. Location acquisition
0.a.3. Recognition that an emergency call is being made
0.a.4. LoST-based call routing
0.b. Scenarios a-d/e
1. Example walk-through that shows all the steps, with actors.  E.g. 
Endpoint does location and dial-plan recognition; proxy does LoST routing.
2. Technical description of the steps, independent of actors.
3. Assignment of technical requirements per entity/actor

This way,
Section 0 describes whole model in the abstract,
Section 1 gives a concrete example (corresponding to ONE scenario)
Section 2 gives the technical details of each step
Section 3 describes the requirements per entity

Does that make more sense?

--Richard