[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp

"SIP"? That's the charter scope. The critical distinction is that it's at the application layer (where the application is whatever is being used to reach the PSAP). 


Brian Rosen wrote:

Better.  "Voice" is too limiting.

-----Original Message-----
From: Richard Barnes [mailto:rbarnes at bbn.com] Sent: Tuesday, March 24, 2009 3:04 PM 
To: Brian Rosen
Cc: 'Dawson, Martin'; Rosen, Brian; ecrit at ietf.org
Subject: Re: [Ecrit] Proposal to add "applicability" statementto
-framework/-phonebcp

Aha, I get it.  So both types of service provider show up.
-- The ISP MUST provide location information (in either case)
-- The VSP MAY add location and route calls
Does the following capture it? (Also added a call out to "interoperability issues" to address Mr. Gellens' concern):
This document describes an architecture for emergency calling in the typical Internet environment, in which the calling device bears most of the burden of implementing emergency calls, and the caller's Internet Service Provider has a supporting role. The caller's Voice Service Provider plays a minor role, if such a provider is present at all. The underlying specifications do allow for the Voice Service Provider to take a more expansive role in emergency calls. However, such cases and any associated issues (e.g., interoperability issues) are not covered extensively in this document; rather, they are left for future study in other documents. 

--Richard


Brian Rosen wrote:

Richard

We're not communicating.  Where your sentence says "Internet Service
Provider", I want it changed to "calling network service provider".  It is
the network that would add location and route calls, not the ISP.  The ISP
supplies location in both scenarios.  The difference is to whom (the end
device or the proxy in the calling network).

Brian

-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
Richard Barnes
Sent: Tuesday, March 24, 2009 1:26 PM
To: Dawson, Martin
Cc: Rosen, Brian; ecrit at ietf.org
Subject: Re: [Ecrit] Proposal to add "applicability" statementto
-framework/-phonebcp
Yes, I think we all agree, and agree that my original sentence was poorly constructed. 

Updated proposal:
This document describes an architecture for emergency calling in the typical Internet environment, in which the calling device bears most of the burden of implementing emergency calls, and the caller's Internet Service Provider has a supporting role. The underlying specifications allow for the network to take a more expansive role in emergency calls, but such cases (and any associated issues) are not covered extensively in this document; rather, they are left for future study in other documents. 


Dawson, Martin wrote:

Apart from Richard's original statement, which I think parses to be the
opposite of intent, I think we're all agreeing...


Richard's original statement was:


To be clear, it's the *Internet* Service Provider, not the *Voice*
Service Provider, which may or may not be there.


That statement actually says that the ISP may or may not be there. I
don't think anybody actually thinks an Internet emergency call can be
made without some access to the Internet... :-)


Cheers,

Martin

________________________________
From: Rosen, Brian [mailto:Brian.Rosen at neustar.biz] Sent: Tuesday, 24 March 2009 1:36 PM 
To: rbarnes at bbn.com; Dawson, Martin
Cc: ecrit at ietf.org
Subject: Re: [Ecrit] Proposal to add "applicability" statementto
-framework/-phonebcp


No.

The ISP requirements are unwaivering.

[[MCD]] "requirements are unwaivering" = "it has requirements" in my
book. So I think we're saying the same thing.

The VSP requirements change.  The VSP, not the ISP adds location and
route, not the ISP.

[[MCD]] "requirements change" = "may not be there" by the same token.
The device may query the LIS and LoST and send the INVITE directly to
the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary
for some VSP to do it. I think that's what we're all saying.



Brian
------Original Message------
From: Richard Barnes
To: Dawson, Martin
Cc: Brian Rosen
Cc: ECRIT
Sent: Mar 23, 2009 5:03 PM
Subject: Re: [Ecrit] Proposal to add "applicability" statementto
-framework/-phonebcp

That's what I meant:
-- ISP plays a role in Framework (i.e., it has requirements)
-- VSP does not (no requirements - may not be there)

Dawson, Martin wrote:

Isn't that the other way around? The VSP may or may not be there?

-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
Of Richard Barnes
Sent: Tuesday, 24 March 2009 10:56 AM
To: Rosen, Brian
Cc: ECRIT
Subject: Re: [Ecrit] Proposal to add "applicability" statementto
-framework/-phonebcp

To be clear, it's the *Internet* Service Provider, not the *Voice*
Service Provider, which may or may not be there.

In summary, s/IP access network/Internet Service Provider/


Rosen, Brian wrote:

Nah, it's not the access network (AN) it's the calling service

provider

(SP) that is affected.  The examples are adding location (who adds

the

Geolocation header) and the LoST query.  Both of those would be done

by

the SIP calling network in, for example, an IMS system.

Brian

-----Original Message-----
From: Richard Barnes [mailto:rbarnes at bbn.com]
Sent: Monday, March 23, 2009 7:27 PM
To: Rosen, Brian
Cc: ECRIT
Subject: Re: [Ecrit] Proposal to add "applicability" statement to
-framework/-phonebcp

Editorial changes:

This document describes an architecture for emergency calling in the
typical Internet environment, in which the calling device bears most

of

------Original Message Truncated------

--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen at neustar.biz



----------------------------------------------------------------------------

--------------------

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]


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit