Subject: [Ecrit] Phone BCP Draft Comments

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2007 23:11:18 +0200

Hi Brian,
Hi James,
Hi all,

I like the document, as I expressed several times in the past.

There are, however, a few issues with it.

Henning and myself have recently written an ECRIT overview document. See 
http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-overview-00.txt

One thing that was quite important for us to highlight was that the IETF 
emergency service architecture has a very nice property, namely the fact 
that different VoIP protocols may be supported between the end host and 
the VoIP provider. There is no need to implement SIP only.

Now, this document does not give me the impression that this aspect is 
given enough consideration.

The IETF emergency service architecture realistically requires that the 
emergency calls are routed through the VSP in order to get identity 
information attached to an emergency call.

Having said all that I believe that one important aspect, which is also 
different to architecturs investigated by other SDOs, is that the PSAP 
has to support a certain functionality. This functionality is described 
in the document but might not be too visible to the working group or at 
least hasn't be advertised a lot.

I believe we have to indicate quite close what the different entities 
have to support rather than meshing everything together. This impacts 
the document structure a bit.

Here is a suggested structure for the document:

* Introduction

Shorten the introduction

It contains a lot of info that is already available in the framework.
This document has to be read in the context of the architecture anyway.

Btw, the introduction must not use RFC 2119 language.

* Terminology

Classical RFC boilerplate and pointers to the requirements document.

* End Host Profile

This section just describes what is absolutely necessary for an end 
point to support the

This is essentially the location part, the LoST part.
This would essentially be Section 4.2, 4.3, 4.4, and 4.5.
The LoST stuff can be found in Section 6.3.

* ISP Profile

This is the location part. The server side of Section 4.2.
Optionally, LoST may be provided by the ISP.

* VSP Profile

Some parts from Section 5 and Section 6 could go in here. Might want to 
separate this into a separate sub-section to have a way to reference it 
from the "End Host Profile" section to say something like
"When the end host implements SIP then the VSP might want to use the 
same functionality already at the client."

The detailed considerations about SIP location conveyance are not 
necessary since they can already be found in the SIP Location Conveyance 
document already.

Section 6.2 does not work with the general IETF emergency architecture, 
as described in the ECRIT framework document. For example, the proxy 
does not obtain location information since it cannot do so in the 
generic case.

Section 8 is also relevant.

* PSAP Profile

Section 6.5 is relevant but only to the extend where the PSAP operator 
network faces the outside world. I don't think it is too relevant for 
this document to talk about PSAP network interal operator, such as 
transferring a call to another PSAP operator.

Section 8 is also relevant.

* Security Considerations

Don't go too much into the details since we talk about all the stuff in 
other docs.

The testing section is fine.

-- I am not so sure about the location update section.

In any case: Try to make the document as short as possible.

Ciao
Hannes

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

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 14 Jul 2007 16:43:52 -0400

See in line

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, July 13, 2007 5:11 PM
> To: ECRIT
> Subject: [Ecrit] Phone BCP Draft Comments
> 
> Hi Brian,
> Hi James,
> Hi all,
> 
There are two things that came to mind when I read this.  One is that you
are right, and we can be more clear that any protocol can be used between
the endpoint and some kind of gateway that interworks to a protocol that the
PSAP implements.  

The other is that SIP need not be the only protocol the PSAP implements.
However. There are some requirements on what the protocol needs to do.  We
should list them, and I think probably that discussion belongs in
-framework.  LoST already can return multiple URIs with different schemes
corresponding to what it implements.

> information attached to an emergency call.
NO!!!!

That is NOT true.  The PSAPs I work with will take calls that don't come
from a VSP over the internet.  They may well have some suspicion on such
calls due to the lack of a verifiable identity but they will take the call
anyway.  I've had numerous conversations with PSAP people who want to make
sure I understand the "rules" they have (validated location for examples).
When I press them for what they want to do when something goes wrong and it
doesn't happen (like, validation fails, do they want unvalidated location or
no location), they ALWAYS want the call, and they want the data you have.
They may treat the call with suspiscion.  They may go back later and try to
figure out why they didn't get what they wanted but they take the call and
ask questions later.

So please don't make that assumption.  Ysa, we expect nearly all calls to go
through a VSP, but the system works if Marc Linsner's proxy in his house
sends the call to the PSAP.
> least hasn't be advertised a lot.
Yes, this is true.  We could make that more explicit.  

> the document structure a bit.
Yes, we have thought about that a lot, and have had some suggestions in that
the direction, the goal being to have all the BCPs for phones in one place,
those for the access network in another place, etc.
> This document has to be read in the context of the architecture anyway.
We will do that

> Btw, the introduction must not use RFC 2119 language.
Yes

> Optionally, LoST may be provided by the ISP.
You see where the problem is?  You have the location part in both End Host
and ISP.  Same with LoST.

This is the problem with this suggestion.  It actually makes as much sense
to keep all the location information together as it does to keep all the end
host information together.

My best idea to address this is to leave the structure as is, but to make
the BCP elements pulled out and labeled as to whom they apply (endpoint,
VSP, ISP, PSAP).  Then, after the functional sections, we can copy the BCP
elements (only, not the other text) and sort them by who they apply to.

> necessary since they can already be found in the SIP Location Conveyance
Actually, I think a lot of this text has to stay as it describes how you use
the -conveyance mechanism.  We'll take a sharp look at it for deletions.

> does not obtain location information since it cannot do so in the
I don't want IETF to be in the position of not supporting proxy insertion of
location as, for example, 3GPP does.  I think we explicitly allow it but
explain the difficulties.

> transferring a call to another PSAP operator.
Probably right, but the endpoint requirements to support transfer must stay
> Don't go too much into the details since we talk about all the stuff in
If you say so.  I'm not sure we can get away with this.  Can we ask you to
get a security reviewer assigned sooner rather than later and we can work
with him to see what we can accomplish with just references to other docs?
> The testing section is fine.
Albeit it mixes endpoint and PSAP BCP statements.
> -- I am not so sure about the location update section.
There is nothing to reference.  It has to be somewhere else, and referenced
here, or here.  This is a use of presence (and presumably HELD).

> In any case: Try to make the document as short as possible.
Okay

Thanks for the suggestions

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Jul 2007 23:38:25 +0200

Hi Brian,

thanks for the quick response. Please see my comments below:

> The other is that SIP need not be the only protocol the PSAP implements.
That's certainly true. We do, however, have to start somewhere. We 
cannot describe what Skype protocol features a PSAP has to implement for 
an emergency service scenario.

Hence, we focus only on SIP. That's already enough for a PSAP to implement.
We do, however, only mandate functionality that is absolutely necessary 
for interoperability.

> corresponding to what it implements.
It might be a good idea to state what protocols have to support -- there 
aren't too many things anyway.

> >from a VSP over the internet.

I guess you need to describe in more detail what you have seen.

>   They may well have some suspicion on such

That's fine. It is just the question what we write into the document. 
What is the default behavior?
We sent the calls directly to the PSAP or via the VSP?

This has impact for the phone BCP document. If you assume that calls are 
routed through the VSP then the protocol run by the end point does not 
matter too much.
If you assume that the end host MUST be able to route directly to the 
PSAP as well then you have to mandate a certain functionality at the end 
point.

So, what behavior do we want?

> those for the access network in another place, etc.

It's OK to have the required functionality listed in one document even 
though they address all the involved parties in the architecture.

> elements (only, not the other text) and sort them by who they apply to.

It's not a big problem to consider location aspects at the ISP and at 
the end host since the demanded functionality is, to some extend, 
different.
In this particular document we, for example, say that the ISP has to 
implement one of the location protocols and the client implements all of 
them.

> explain the difficulties.
The problem is that it does not work together with the framework document.
The framework document does not have a case for it.

It's fine that the SIP Location Conveyance document has something in 
there that could potentially be useful for the 3GPP. The interesting 
case, however, is that the emergency services architecture of the 3GPP 
has the functionality of the P-CSCF and the E-CSCF in the local network 
and hence they don't standardize the interaction with the PSAP, unlike 
we do because the PSAP in the IETF emergency services architecture might 
get the call from an arbitrary entity rather than from the local network 
operator.

> Probably right, but the endpoint requirements to support transfer must stay
That's fine

> with him to see what we can accomplish with just references to other docs?
Good idea. We should do that.

> here, or here.  This is a use of presence (and presumably HELD).
Hmm. I have to re-read that part.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 14 Jul 2007 18:01:10 -0400

The text now says that the phone applies normal outbound processing.  That
would mean it sends calls to the VSP.  That's what we want.

Marc's phone would normally send calls to his house proxy.  That is what we
want.

Let us try my way with the organization and see if it accomplishes what you
want.  If it's a mess, I'll look at doing it your way.

I'll make sure we discuss proxy insertion of location in both -framework and
-phonebcp.  I think it is best to state it is acceptable if the limitations
implied (VSP has a relationship with ISP, has a good identifier that ISP can
use) hold.

Brian

> Sent: Saturday, July 14, 2007 5:38 PM
> To: Brian Rosen
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] Phone BCP Draft Comments
> 
> Hi Brian,
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Jul 2007 18:08:31 -0400

> Marc's phone would normally send calls to his house proxy.  That is  

Brian,

Note that outbound proxies are NOT mandatory for SIP, whether a VSP  
is in place or not. I see no reason to change that basic architecture  
for emergency calls, even if the vast majority of calls do use an  
outbound proxy (or, in enterprises, just the 'local' proxy.)

Do you have a pointer in the SIP documents that mandate an outbound  
proxy?

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 14 Jul 2007 19:26:40 -0400

Henning

I said "normal outbound processing".  Whatever that is for that phone.  If
it's configured for an outbound proxy, use that.  If it's not, send it to
the PSAP directly.

I went and looked, and actually, it says:
The call would normally be sent to the first hop proxy of the communications
service

I really do want it to be whatever is normal for that UA.  Got a suggested
wording?

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, July 14, 2007 6:09 PM
> To: Brian Rosen
> Cc: ECRIT

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Jul 2007 19:48:04 -0400

Brian,

I would omit anything that could be seen as implying that SIP  
behavior for emergency calls is different from normal calls, unless  
it actually is. Thus, I'd simply omit statements such as the one  
below, since there's no need to repeat what's already documented  
elsewhere. Also makes the document shorter...

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 14 Jul 2007 20:23:00 -0400

I don't like that suggestion because I think some readers would think they
SHOULD skip normal outbound processing and send the call directly.  I think
it would be better to be explicit.

Brian

> Sent: Saturday, July 14, 2007 7:48 PM
> To: Brian Rosen
> Cc: 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Jul 2007 20:30:21 -0400

Just state up front

"SIP call processing for emergency calls is exactly the same as for  
non-emergency calls, except where this document explicitly describes  
alternate behavior."

This should remove all doubt, not just for this case.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 10:11:22 +0200

Hi Brian,

> Marc's phone would normally send calls to his house proxy.  That is what we
Typically, it would be the proxy of Marc's VoIP provider.
> implied (VSP has a relationship with ISP, has a good identifier that ISP can

I don't think we have a place in our current architecture for the proxy 
insertion for location.
We should first discuss that aspect from an architectural point of view.

Ciao
Hannes

>>>> Henning and myself have recently written an ECRIT overview document.
>>>>         
>> See
>>     
>>>> One thing that was quite important for us to highlight was that the
>>>>         
>> IETF
>>     
>>>> emergency service architecture has a very nice property, namely the
>>>>         
>> fact
>>     
>>> There are two things that came to mind when I read this.  One is that
>>>       
>> you
>>     
>>> are right, and we can be more clear that any protocol can be used
>>>       
>> between
>>     
>>> the endpoint and some kind of gateway that interworks to a protocol that
>>>       
>> the
>>     
>>> PSAP implements.
>>>
>>> However. There are some requirements on what the protocol needs to do.
>>>       
>> We
>>     
>>> -framework.  LoST already can return multiple URIs with different
>>>       
>> schemes
>>     
>>> calls due to the lack of a verifiable identity but they will take the
>>>       
>> call
>>     
>>> anyway.  I've had numerous conversations with PSAP people who want to
>>>       
>> make
>>     
>>> sure I understand the "rules" they have (validated location for
>>>       
>> examples).
>>     
>>> When I press them for what they want to do when something goes wrong and
>>>       
>> it
>>     
>>> doesn't happen (like, validation fails, do they want unvalidated
>>>       
>> location or
>>     
>>> no location), they ALWAYS want the call, and they want the data you
>>>       
>> have.
>>     
>>> They may treat the call with suspiscion.  They may go back later and try
>>>       
>> to
>>     
>>> figure out why they didn't get what they wanted but they take the call
>>>       
>> and
>>     
>>> ask questions later.
>>>
>>> So please don't make that assumption.  Ysa, we expect nearly all calls
>>>       
>> to go
>>     
>>> Yes, we have thought about that a lot, and have had some suggestions in
>>>       
>> that
>>     
>>> the direction, the goal being to have all the BCPs for phones in one
>>>       
>> place,
>>     
>>> You see where the problem is?  You have the location part in both End
>>>       
>> Host
>>     
>>> and ISP.  Same with LoST.
>>>
>>> This is the problem with this suggestion.  It actually makes as much
>>>       
>> sense
>>     
>>> to keep all the location information together as it does to keep all the
>>>       
>> end
>>     
>>> My best idea to address this is to leave the structure as is, but to
>>>       
>> make
>>     
>>> VSP, ISP, PSAP).  Then, after the functional sections, we can copy the
>>>       
>> BCP
>>     
>>>> necessary since they can already be found in the SIP Location
>>>>         
>> Conveyance
>>     
>>>> document already.
>>>>
>>>>         
>>> Actually, I think a lot of this text has to stay as it describes how you
>>>       
>> use
>>     
>>> I don't want IETF to be in the position of not supporting proxy
>>>       
>> insertion of
>>     
>>> Probably right, but the endpoint requirements to support transfer must
>>>       
>> stay
>>     
>> That's fine
>>
>>     
>>> If you say so.  I'm not sure we can get away with this.  Can we ask you
>>>       
>> to
>>     
>>> get a security reviewer assigned sooner rather than later and we can
>>>       
>> work
>>     
>>> with him to see what we can accomplish with just references to other
>>>       
>> docs?
>>     
>>> There is nothing to reference.  It has to be somewhere else, and
>>>       
>> referenced
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 10:13:05 +0200

Henning, do you think that the emergency call should go directly to the 
PSAP without traveling through the VSP?

Btw, I noticed that we say nothing about NAT traversal in the Phone BCP. 
That seems to be mandatory functionality, however.

Ciao
Hannes

Henning Schulzrinne wrote:
> Note that outbound proxies are NOT mandatory for SIP, whether a VSP is 
> in place or not. I see no reason to change that basic architecture for 
> emergency calls, even if the vast majority of calls do use an outbound 
> proxy (or, in enterprises, just the 'local' proxy.)
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 10:17:27 +0200

Hi Brian,
Hi Henning,

this is, however, an important design consideration that would 
essentially open the door to have absolutely no identity information 
available for the PSAP.

Ciao
Hannes

 Henning Schulzrinne wrote:
> Brian,
>
> I would omit anything that could be seen as implying that SIP behavior 
> for emergency calls is different from normal calls, unless it actually 
> is. Thus, I'd simply omit statements such as the one below, since 
> there's no need to repeat what's already documented elsewhere. Also 
> makes the document shorter...
>
> Henning
>

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 15 Jul 2007 09:18:10 -0400

Hannes

I believe your opinion runs counter to consensus, and I'll bring this up for
a hum at the meeting.  I think most of us think endpoint insertion of
location is preferred, but proxy insertion, under the right circumstances,
is acceptable.

Brian

> Sent: Sunday, July 15, 2007 4:11 AM
> To: Brian Rosen
> Cc: 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jul 2007 09:20:19 -0400

The lack of identity information doesn't really change whether Marc  
uses his home proxy or not.

I think this is the case where we reach the limits of what an IETF  
BCP can do. Something like "you should be going through a proxy that  
can assert your identity and is known to the PSAP/widely known" might  
be nice, but this is pretty vague. I suspect that the necessity of  
spam filtering will generally have this result, even for non- 
emergency calls, but this seems like something that's better  
addressed by other standards bodies, such as NENA, who can take local  
conditions and laws into account.

The RIAA/MPAA seem to have no problem using IP address information to  
drag people into court for a civil matter; I suspect the same will be  
true in the absence of authentication for criminal offenses such as  
making a false emergency call.

Henning

On Jul 15, 2007, at 4:17 AM, Hannes Tschofenig wrote:

> essentially open the door to have absolutely no identity  
> information available for the PSAP.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jul 2007 09:26:22 -0400

On Jul 15, 2007, at 4:13 AM, Hannes Tschofenig wrote:

> Henning, do you think that the emergency call should go directly to  
> the PSAP without traveling through the VSP?
>

An emergency call should behave like any other SIP call from that end  
system. If the device uses a proxy to place calls to grandma, it  
should use that same proxy to reach 911. If it reaches destinations  
directly, it should do the same thing for emergency calls. This is  
far more likely to work than special-casing emergency calls. (I  
realize that the unauthenticated network access case is an  
unfortunate exception, but it should remain that.)

> Btw, I noticed that we say nothing about NAT traversal in the Phone  
> BCP. That seems to be mandatory functionality, however.
>

We don't want to write a "How to deploy SIP" manual in ECRIT. I think  
you recently suggested trimming the document size; filling it with  
boilerplate and bromides just obscures the important parts. "Traverse  
NATs" is not testable behavior, given that there is no solution that  
can be guaranteed to work for all NATs under all circumstances.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 15:49:03 +0200

Hi Brian,

sure that's fine. But the problem is the following: What proxy should 
add location information other than a proxy in the access network.
So far, such a proxy does not exist in our emergency services 
architecture. Right?

Ciao
Hannes

Brian Rosen wrote:
>>> The text now says that the phone applies normal outbound processing.
>>>       
>> That
>>     
>>> Marc's phone would normally send calls to his house proxy.  That is what
>>>       
>> we
>>     
>>> want.
>>>
>>>       
>>> Let us try my way with the organization and see if it accomplishes what
>>>       
>> you
>>     
>>> I'll make sure we discuss proxy insertion of location in both -framework
>>>       
>> and
>>     
>>> -phonebcp.  I think it is best to state it is acceptable if the
>>>       
>> limitations
>>     
>>> implied (VSP has a relationship with ISP, has a good identifier that ISP
>>>       
>> can
>>     
>>> use) hold.
>>>
>>>       
>>>>>> that different VoIP protocols may be supported between the end host
>>>>>>             
>> and
>>     
>>>>>> Now, this document does not give me the impression that this aspect
>>>>>>             
>> is
>>     
>>>>> the endpoint and some kind of gateway that interworks to a protocol
>>>>>           
>> that
>>     
>>>> the
>>>>
>>>>         
>>>>> PSAP implements.
>>>>>
>>>>> The other is that SIP need not be the only protocol the PSAP
>>>>>           
>> implements.
>>     
>>>>>           
>>>> cannot describe what Skype protocol features a PSAP has to implement
>>>>         
>> for
>>     
>>>> It might be a good idea to state what protocols have to support --
>>>>         
>> there
>>     
>>>>>> The IETF emergency service architecture realistically requires that
>>>>>>             
>> the
>>     
>>>>> That is NOT true.  The PSAPs I work with will take calls that don't
>>>>>           
>> come
>>     
>>>>> When I press them for what they want to do when something goes wrong
>>>>>           
>> and
>>     
>>>> it
>>>>
>>>>         
>>>>> They may treat the call with suspiscion.  They may go back later and
>>>>>           
>> try
>>     
>>>> to
>>>>
>>>>         
>>>>> through a VSP, but the system works if Marc Linsner's proxy in his
>>>>>           
>> house
>>     
>>>> This has impact for the phone BCP document. If you assume that calls
>>>>         
>> are
>>     
>>>> PSAP as well then you have to mandate a certain functionality at the
>>>>         
>> end
>>     
>>>> point.
>>>>
>>>>>> Having said all that I believe that one important aspect, which is
>>>>>>             
>> also
>>     
>>>>>> different to architecturs investigated by other SDOs, is that the
>>>>>>             
>> PSAP
>>     
>>>>>> has to support a certain functionality. This functionality is
>>>>>>             
>> described
>>     
>>>>>> in the document but might not be too visible to the working group or
>>>>>>             
>> at
>>     
>>>>> Yes, we have thought about that a lot, and have had some suggestions
>>>>>           
>> in
>>     
>>>> that
>>>>
>>>>         
>>>>>> This document has to be read in the context of the architecture
>>>>>>             
>> anyway.
>>     
>>>>>>             
>>>>> We will do that
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>> to keep all the location information together as it does to keep all
>>>>>           
>> the
>>     
>>>> end
>>>>
>>>>         
>>>>> the BCP elements pulled out and labeled as to whom they apply
>>>>>           
>> (endpoint,
>>     
>>>>> elements (only, not the other text) and sort them by who they apply
>>>>>           
>> to.
>>     
>>>>>
>>>>>           
>>>> implement one of the location protocols and the client implements all
>>>>         
>> of
>>     
>>>> them.
>>>>
>>>>
>>>>         
>>>>>> * VSP Profile
>>>>>>
>>>>>> Some parts from Section 5 and Section 6 could go in here. Might want
>>>>>>             
>> to
>>     
>>>>>> separate this into a separate sub-section to have a way to reference
>>>>>>             
>> it
>>     
>>>>> Actually, I think a lot of this text has to stay as it describes how
>>>>>           
>> you
>>     
>>>> use
>>>>
>>>>         
>>>>> the -conveyance mechanism.  We'll take a sharp look at it for
>>>>>           
>> deletions.
>>     
>>>>>
>>>>>           
>>>>>> Section 6.2 does not work with the general IETF emergency
>>>>>>             
>> architecture,
>>     
>>>>> location as, for example, 3GPP does.  I think we explicitly allow it
>>>>>           
>> but
>>     
>>>> The problem is that it does not work together with the framework
>>>>         
>> document.
>>     
>>>> we do because the PSAP in the IETF emergency services architecture
>>>>         
>> might
>>     
>>>> get the call from an arbitrary entity rather than from the local
>>>>         
>> network
>>     
>>>> operator.
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>>> Section 6.5 is relevant but only to the extend where the PSAP
>>>>>>             
>> operator
>>     
>>>>>> Don't go too much into the details since we talk about all the stuff
>>>>>>             
>> in
>>     
>>>>>> other docs.
>>>>>>
>>>>>>
>>>>>>             
>>>>> If you say so.  I'm not sure we can get away with this.  Can we ask
>>>>>           
>> you
>>     
>>>> to
>>>>
>>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 16:03:53 +0200

Hi Henning,

Henning Schulzrinne wrote:
> directly, it should do the same thing for emergency calls. This is far 
> more likely to work than special-casing emergency calls. (I realize 
> that the unauthenticated network access case is an unfortunate 
> exception, but it should remain that.)
>
I agree; that's a nice property.

But it is quite likely that systems that provide some level of 
robustness also route calls through their VSP rather than sending them 
directly to some entities.

> can be guaranteed to work for all NATs under all circumstances.
Consider your previous statement: Emergency calls should be sent 
directly to the PSAP without routing them through the VSP. Now, consider 
a DSL network that typically has a NAT box in your home network. How 
likely is it that this stuff works without any statement about 
functionality that has to be available for the end point and the PSAP 
with regard to NAT traversal?

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 15 Jul 2007 10:11:21 -0400

That is up to the VSP.  In the 3GPP case, they send emergency calls to the
E-CSCF.  Others may do it on the first hop outbound (what would be the
P-CSCF).  I don't think we care, and I don't think we even discuss it.

Brian

> Sent: Sunday, July 15, 2007 9:49 AM
> To: Brian Rosen
> Cc: 'ECRIT'

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 15 Jul 2007 10:16:30 -0400

I'm going to jump the gun on Henning.

We don't want emergency calls special cases in any way other than things
that are absolutely necessary (recognizing, adding location and LoST route).
In particular, the way it normally sends outbound calls is what we want.
Henning did NOT say send direct, unless that is the way the phone normally
handles outbound calls.  If it has an outbound proxy configured, which most
VSP-enabled phones would have, we want them sent there.  Henning suggests
not even discussing where to send them.  I wanted to say that explicitly.
He wants us to just say "emergency calls are handled exactly the same as any
outbound calls except these very specific things".

Brian

> Sent: Sunday, July 15, 2007 10:04 AM
> To: Henning Schulzrinne
> Cc: Brian Rosen; ECRIT

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jul 2007 10:22:44 -0400

> directly to the PSAP without routing them through the VSP. Now,  
> consider a DSL network that typically has a NAT box in your home  
> network. How likely is it that this stuff works without any  
> statement about functionality that has to be available for the end  
> point and the PSAP with regard to NAT traversal?

These calls will work just as well as calls to any other SIP  
destination. In other words, if you screw up your SIP configuration  
so that calls to grandma don't work, it is extremely unlikely that  
the PSAP can fix that for you or that an ECRIT document will help.

PSAPs have no special role in NAT traversal.

Again, we don't want to write a manual about "how to build a SIP  
network". This is not within the charter of the working group and  
requires far more than a few vague statements about "beware of NATs".  
There is a danger of these documents becoming as useful as the  
typical investment disclosure form for stock offerings, consisting  
mainly of platitudes that read more like a lawyer trying to cover  
their liability than an engineering document.

We want to write test capability into the spec so that people can  
figure out ahead of time when things don't work, for any number of  
reasons.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 16:34:55 +0200

But we cannot leave this aspect open. We need to specify actions that 
the different parties have todo.
As part of this description, the framework document makes it very clear 
that the end host obtains location information (*).
The 3GPP has a different architecture for emergency services and that's 
fine.

We cannot just make such a vague statement that the VSP may add a 
reference to location information without explain the big picture.

Ciao
Hannes

(*) In this discussion we ignoring the location hiding aspect for a moment.

Brian Rosen wrote:
>>> I believe your opinion runs counter to consensus, and I'll bring this up
>>>       
>> for
>>     
>>> location is preferred, but proxy insertion, under the right
>>>       
>> circumstances,
>>     
>>> is acceptable.
>>>
>>> Brian
>>>
>>>
>>>       
>>>>> Marc's phone would normally send calls to his house proxy.  That is
>>>>>           
>> what
>>     
>>>> we
>>>>
>>>>         
>>>>> want.
>>>>>
>>>>>
>>>>>           
>>>>> Let us try my way with the organization and see if it accomplishes
>>>>>           
>> what
>>     
>>>> you
>>>>
>>>>         
>>>>> I'll make sure we discuss proxy insertion of location in both -
>>>>>           
>> framework
>>     
>>>> and
>>>>
>>>>         
>>>>> implied (VSP has a relationship with ISP, has a good identifier that
>>>>>           
>> ISP
>>     
>>>> can
>>>>
>>>>         
>>>>> use) hold.
>>>>>
>>>>>
>>>>>           
>>>> We should first discuss that aspect from an architectural point of
>>>>         
>> view.
>>     
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>
>>>>         
>>>>> Brian
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>>>> Henning and myself have recently written an ECRIT overview
>>>>>>>>                 
>> document.
>>     
>>>>>>>>                 
>>>>>> See
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> There are two things that came to mind when I read this.  One is
>>>>>>>               
>> that
>>     
>>>>>>>               
>>>>>> you
>>>>>>
>>>>>>
>>>>>>             
>>>>>> We do, however, only mandate functionality that is absolutely
>>>>>>             
>> necessary
>>     
>>>>>> for interoperability.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> However. There are some requirements on what the protocol needs to
>>>>>>>               
>> do.
>>     
>>>>>>>               
>>>>>> We
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> calls due to the lack of a verifiable identity but they will take
>>>>>>>               
>> the
>>     
>>>>>>>               
>>>>>> call
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> anyway.  I've had numerous conversations with PSAP people who want
>>>>>>>               
>> to
>>     
>>>>>>>               
>>>>>> make
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> figure out why they didn't get what they wanted but they take the
>>>>>>>               
>> call
>>     
>>>>>>>               
>>>>>> and
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> ask questions later.
>>>>>>>
>>>>>>> So please don't make that assumption.  Ysa, we expect nearly all
>>>>>>>               
>> calls
>>     
>>>>>>>               
>>>>>> to go
>>>>>>
>>>>>>
>>>>>>             
>>>>>> routed through the VSP then the protocol run by the end point does
>>>>>>             
>> not
>>     
>>>>>> matter too much.
>>>>>>>> in the document but might not be too visible to the working group
>>>>>>>>                 
>> or
>>     
>>>> at
>>>>
>>>>         
>>>>>>>> I believe we have to indicate quite close what the different
>>>>>>>>                 
>> entities
>>     
>>>>>>>> have to support rather than meshing everything together. This
>>>>>>>>                 
>> impacts
>>     
>>>>>> It's OK to have the required functionality listed in one document
>>>>>>             
>> even
>>     
>>>>>>>> It contains a lot of info that is already available in the
>>>>>>>>                 
>> framework.
>>     
>>>>>>>> Classical RFC boilerplate and pointers to the requirements
>>>>>>>>                 
>> document.
>>     
>>>>>>>>
>>>>>>>>                 
>>>>>>>> * End Host Profile
>>>>>>>>
>>>>>>> You see where the problem is?  You have the location part in both
>>>>>>>               
>> End
>>     
>>>>>>>               
>>>>>> Host
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> and ISP.  Same with LoST.
>>>>>>>
>>>>>>> VSP, ISP, PSAP).  Then, after the functional sections, we can copy
>>>>>>>               
>> the
>>     
>>>>>>>               
>>>>>> BCP
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> Some parts from Section 5 and Section 6 could go in here. Might
>>>>>>>>                 
>> want
>>     
>>>> to
>>>>
>>>>         
>>>>>>>> separate this into a separate sub-section to have a way to
>>>>>>>>                 
>> reference
>>     
>>>> it
>>>>
>>>>         
>>>>>>>> "When the end host implements SIP then the VSP might want to use
>>>>>>>>                 
>> the
>>     
>>>>>>>> as described in the ECRIT framework document. For example, the
>>>>>>>>                 
>> proxy
>>     
>>>>>> case, however, is that the emergency services architecture of the
>>>>>>             
>> 3GPP
>>     
>>>>>> has the functionality of the P-CSCF and the E-CSCF in the local
>>>>>>             
>> network
>>     
>>>>>> and hence they don't standardize the interaction with the PSAP,
>>>>>>             
>> unlike
>>     
>>>>>>>> network faces the outside world. I don't think it is too relevant
>>>>>>>>                 
>> for
>>     
>>>>>>> Probably right, but the endpoint requirements to support transfer
>>>>>>>               
>> must
>>     
>>>>>>>               
>>>>>> stay
>>>>>>
>>>>>> That's fine
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> Don't go too much into the details since we talk about all the
>>>>>>>>                 
>> stuff
>>     
>>>> in
>>>>
>>>>         
>>>>>>>> other docs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jul 2007 10:44:01 -0400

Since this is highly dependent on the specific network, I don't think  
we can say anything useful. The VSP will figure this out, based on  
local needs and capabilities. For example, a Vonage-like VSP may  
initially simply insert the user-provided location, i.e., the address  
customers typed into a web form. A combined VSP/ISP could use some  
proprietary mechanism that only works with its particular brand of  
equipment. The Hogwart's VSP would probably use Professor Trelaney's  
crystal ball.

Unless there's an IETF protocol that we can tell somebody to  
implement, what useful information are we going to provide to the  
implementor and operator? Saying "only insert location information if  
you have it" isn't terribly helpful. But maybe you have a concrete  
proposal that the VSP should always use?

Henning

[trimming huge 10-deep quote]

On Jul 15, 2007, at 10:34 AM, Hannes Tschofenig wrote:

> But we cannot leave this aspect open. We need to specify actions  
> that the different parties have todo.
> As part of this description, the framework document makes it very  
> clear that the end host obtains location information (*).
> The 3GPP has a different architecture for emergency services and  
> that's fine.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 16:55:12 +0200

Not treating emergency calls special sounds good to me.

Ciao
Hannes

Henning Schulzrinne wrote:
>> network. How likely is it that this stuff works without any statement 
>> about functionality that has to be available for the end point and 
>> the PSAP with regard to NAT traversal?
>
>
> destination. In other words, if you screw up your SIP configuration so 
> that calls to grandma don't work, it is extremely unlikely that the 
> PSAP can fix that for you or that an ECRIT document will help.
>
> There is a danger of these documents becoming as useful as the typical 
> investment disclosure form for stock offerings, consisting mainly of 
> platitudes that read more like a lawyer trying to cover their 
> liability than an engineering document.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 17:01:32 +0200

Currently the framework document does not say that the VSP should attach 
location information to an emergency call. Instead, the end host obtains 
it. That's why the document goes into a lot of details regarding the 
protocols that could be used for this purpose.

Are we going to change this to

a) If the VSP wants to add something in addition the information that is 
already inserted by the end host then it can do so.

b) Change the architecture to something where the VSP adds location 
instead of the end point

I am confused.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jul 2007 11:19:12 -0400

There are two cases of interest:

(1) The VSP receives a call without location information; I suspect  
we would agree that if the VSP has location information, it should  
insert it and route on it. There are no good alternatives.

(2) The VSP receives a call with location information, but it (a)  
either cannot read it or (b) it can, but the VSP has different  
location information. (ISP claims that caller is at location X, VSP  
believes him to be at Y.) In the first case, I'd argue that having  
the VSP provide the location is probably a good thing, as long as it  
is labeled; see the SIP location conveyance discussion on that topic.  
I'm unsure about the second case, but would tend to favor inclusion  
for the same reason. Almost always, the ISP/end system will know  
better, but there may well be exceptions. (One exception you could  
imagine is that the ISP says "customer X is somewhere in the WiMax  
coverage area, which is Lincoln county". VSP says "by the way, the  
customer lives at 123 Main Street, Springfield, Lincoln County." Any  
such insertion should be marked by the appropriate source indication,  
i.e., billing address in the latter case.)

I suspect we can also agree that having the VSP remove location  
information from a signaling message is a bad idea.

The only interesting case for routing is case (2b). I don't know if  
we need to say anything about which location should be handed to  
LoST, although the right answer is usually likely to be the ISP/end- 
system provided location.

Henning

On Jul 15, 2007, at 11:01 AM, Hannes Tschofenig wrote:

> Currently the framework document does not say that the VSP should  
> attach location information to an emergency call. Instead, the end  
> host obtains it. That's why the document goes into a lot of details  
> regarding the protocols that could be used for this purpose.
>
> a) If the VSP wants to add something in addition the information  
> that is already inserted by the end host then it can do so.
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 15 Jul 2007 14:39:42 -0500

Hi Hannes,

Well... I can imagine a proxy in a residential LAN that knows how to
talk HELD to the access provider network when the client device (e.g.
legacy ATA) does not know how to. So the proxy does the request on
behalf of the ATA and does the insertion on the outbound.

I can imagine an Asterisk server in an enterprise that knows how to talk
to the enterprise LIS and requests and inserts location on behalf of the
standard phone form factor IP handsets that don't know how to do it
themselves.

In both cases, the option exists to route the call directly to whatever
URI the LoST service indicates is appropriate without any external VSP
being involved.

Or are you saying that these proxies are the "VSP" in these scenarios?
It's just a question of semantics?

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Sunday, 15 July 2007 11:49 PM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] Phone BCP Draft Comments

Hi Brian,

Ciao
Hannes

circumstances,
what
what
ISP
view.
document.
>>>> See
http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-
>>>>>> overview-00.txt
that
necessary
do.
the
to
call
calls
not
or
entities
impacts
even
framework.
document.
End
the
want
reference
the
proxy
3GPP
network
unlike
for
must
stuff

------------------------------------------------------------------------------------------------
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: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2007 10:25:30 +0200

Hi Martin,

Dawson, Martin wrote:
> \
I can imagine many scenarios as well

The problem with all these things is that
* we haven't described them clearly
* there are a number of options
* the client does not know in which environment it is in order get 
things to work.

> standard phone form factor IP handsets that don't know how to do it
I know that these things are possible and this would be very similar to 
the 3GPP emergency architecture where the user is actually at home.

> URI the LoST service indicates is appropriate without any external VSP
The VSP in this case would be the enterprise.

Ciao
Hannes

>> I believe your opinion runs counter to consensus, and I'll bring this
>>     
> up for
>   
>>>> I'll make sure we discuss proxy insertion of location in both
>>>>         
> -framework
>   
>>>>       
>>>>         
>>> and
>>>     
>>>       
>>> I don't think we have a place in our current architecture for the
>>>       
> proxy
>   
>>> insertion for location.
>>>>>>> One thing that was quite important for us to highlight was that
>>>>>>>               
> the
>   
>>>>>>>             
>>>>>>>               
>>>>> IETF
>>>>>
>>>>>         
>>>>>           
>>>>>>> emergency service architecture has a very nice property, namely
>>>>>>>               
> the
>   
>>>>>>>             
>>>>>>>               
>>>>> fact
>>>>>
>>>>>         
>>>>>           
>>>>>>> that different VoIP protocols may be supported between the end
>>>>>>>               
> host
>   
>>>>>>>             
>>>>>>>               
>>> and
>>>     
>>>       
>>>>>>> Now, this document does not give me the impression that this
>>>>>>>               
> aspect
>   
>>>>>>>             
>>>>>>>               
>>> is
>>>     
>>>       
>>>>>> the endpoint and some kind of gateway that interworks to a
>>>>>>             
> protocol
>   
>>>>>>           
>>>>>>             
>>> that
>>>     
>>>       
>>>>> the
>>>>>
>>>>>         
>>>>>           
>>>>>> PSAP implements.
>>>>>>
>>>>> cannot describe what Skype protocol features a PSAP has to
>>>>>           
> implement
>   
>>>>>         
>>>>>           
>>> for
>>>     
>>>       
>>>>>>> The IETF emergency service architecture realistically requires
>>>>>>>               
> that
>   
>>>>>>>             
>>>>>>>               
>>> the
>>>     
>>>       
>>>>>>> emergency calls are routed through the VSP in order to get
>>>>>>>               
> identity
>   
>>>>>> That is NOT true.  The PSAPs I work with will take calls that
>>>>>>             
> don't
>   
>>>>>>           
>>>>>>             
>>> come
>>>     
>>>       
>>>>>> When I press them for what they want to do when something goes
>>>>>>             
> wrong
>   
>>>>>>           
>>>>>>             
>>> and
>>>     
>>>       
>>>>> it
>>>>>
>>>>>         
>>>>>           
>>>>>> no location), they ALWAYS want the call, and they want the data
>>>>>>             
> you
>   
>>>>>>           
>>>>>>             
>>>>> have.
>>>>>
>>>>>         
>>>>>           
>>>>>> They may treat the call with suspiscion.  They may go back later
>>>>>>             
> and
>   
>>>>>>           
>>>>>>             
>>> try
>>>     
>>>       
>>>>> to
>>>>>
>>>>>         
>>>>>           
>>>>> That's fine. It is just the question what we write into the
>>>>>           
> document.
>   
>>>>> This has impact for the phone BCP document. If you assume that
>>>>>           
> calls
>   
>>>>>         
>>>>>           
>>> are
>>>     
>>>       
>>>>> If you assume that the end host MUST be able to route directly to
>>>>>           
> the
>   
>>>>> PSAP as well then you have to mandate a certain functionality at
>>>>>           
> the
>   
>>>>>         
>>>>>           
>>> end
>>>     
>>>       
>>>>> point.
>>>>>
>>>>>>> Having said all that I believe that one important aspect, which
>>>>>>>               
> is
>   
>>>>>>>             
>>>>>>>               
>>> also
>>>     
>>>       
>>>>>> Yes, we have thought about that a lot, and have had some
>>>>>>             
> suggestions
>   
>>>>>>           
>>>>>>             
>>> in
>>>     
>>>       
>>>>> that
>>>>>
>>>>>         
>>>>>           
>>>>>> the direction, the goal being to have all the BCPs for phones in
>>>>>>             
> one
>   
>>>>>>           
>>>>>>             
>>>>> place,
>>>>>
>>>>>         
>>>>>           
>>>>>>> This section just describes what is absolutely necessary for an
>>>>>>>               
> end
>   
>>>>>>> point to support the
>>>>>>>
>>>>>> This is the problem with this suggestion.  It actually makes as
>>>>>>             
> much
>   
>>>>>>           
>>>>>>             
>>>>> sense
>>>>>
>>>>>         
>>>>>           
>>>>>> to keep all the location information together as it does to keep
>>>>>>             
> all
>   
>>>>>>           
>>>>>>             
>>> the
>>>     
>>>       
>>>>> end
>>>>>
>>>>>         
>>>>>           
>>>>>> My best idea to address this is to leave the structure as is, but
>>>>>>             
> to
>   
>>>>>>           
>>>>>>             
>>>>> make
>>>>>
>>>>>         
>>>>>           
>>>>>> elements (only, not the other text) and sort them by who they
>>>>>>             
> apply
>   
>>>>>>           
>>>>>>             
>>> to.
>>>     
>>>       
>>>>>>           
>>>>>>             
>>>>> It's not a big problem to consider location aspects at the ISP and
>>>>>           
> at
>   
>>>>> In this particular document we, for example, say that the ISP has
>>>>>           
> to
>   
>>>>> implement one of the location protocols and the client implements
>>>>>           
> all
>   
>>>>>         
>>>>>           
>>> of
>>>     
>>>       
>>>>> them.
>>>>>
>>>>>
>>>>>         
>>>>>           
>>>>>>> * VSP Profile
>>>>>>>
>>>>>> Actually, I think a lot of this text has to stay as it describes
>>>>>>             
> how
>   
>>>>>>           
>>>>>>             
>>> you
>>>     
>>>       
>>>>> use
>>>>>
>>>>>         
>>>>>           
>>>>>> location as, for example, 3GPP does.  I think we explicitly allow
>>>>>>             
> it
>   
>>>>>>           
>>>>>>             
>>> but
>>>     
>>>       
>>>>> It's fine that the SIP Location Conveyance document has something
>>>>>           
> in
>   
>>>>> there that could potentially be useful for the 3GPP. The
>>>>>           
> interesting
>   
>>>>>>> this document to talk about PSAP network interal operator, such
>>>>>>>               
> as
>   
>>>>>> If you say so.  I'm not sure we can get away with this.  Can we
>>>>>>             
> ask
>   
>>>>>>           
>>>>>>             
>>> you
>>>     
>>>       
>>>>> to
>>>>>
>>>>>         
>>>>>           
>>>>>> get a security reviewer assigned sooner rather than later and we
>>>>>>             
> can
>   
>>>>>>           
>>>>>>             
>>>>> work
>>>>>
>>>>>         
>>>>>           
>>>>>> with him to see what we can accomplish with just references to
>>>>>>             
> other
>   
>>>>>>           
>>>>>>             
>>>>> docs?
>>>>>