Subject: [Ecrit] Let us focus on the HUM

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 1 Aug 2009 13:58:49 +0300

... and avoid discussing the same old stuff again.

Ciao
Hannes

---

From: <[email-masked]>
Date: Mon, 3 Aug 2009 16:37:49 +0200

>-----Original Message-----
  >From: [email-masked] [mailto:[email-masked]] 
  >On Behalf Of ext Brian Rosen
  >Sent: Friday, July 31, 2009 5:00 PM
  >To: 'DRAGE, Keith (Keith)'; 'Elwell, John'; 'Marc Linsner'; 'ecrit'
  >Subject: Re: [Ecrit] HUM on PhoneBCP
  >
  >Haha, yes, a browser, or even an app using the raw packet 
  >service in a 3GPP GPRS device is on the Internet, although 
  >there are some subtle differences (the DNS root for 
  >example),

These are deployment and operational decisions, which have nothing to do with the ongoing discussion.

  > but then, a service using that raw packet 
  >interface to make, say, an IM to an emergency service would 
  >probably have to make use of the phonebcp procedures, a fact 
  >3GPP is studiously ignoring.

3gpp has defined a set of different procedures for emergency calls, and carriers will likely ask vendors to implement as specified. Then users will also use it as specified.

  >  I would not go so far as to 
  >say most people would prefer the 3GPP specified procedures 
  >vs the IETF phonebcp procedures, especially if they 
  >understood the tradeoffs.

It is not a question of preference. Carriers want to have a solution which is reliable and operational 99.99999% of the cases. It has to be a stricly managed network.

  >However, a 3GPP mobile telephone service is not an Internet 
  >service, no matter how you stretch it.

Wow. What is your definition of Internet Service? I do remember statements on this mailing list that cellular networks are not IP capable. I guess you didn't want to go that far.
I access the same content regardless of whether I use the comcast cable ending in the house or t-mobile's packet data service anywhere else. The only difference is the speed and the cost. 
Looks the same to me, no matter how I strech it.

- gabor

  >Brian
  >
  >> -----Original Message-----
  >> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
  >> Sent: Friday, July 31, 2009 7:20 AM
  >> To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit'
  >> Subject: RE: [Ecrit] HUM on PhoneBCP
  >> 
  >> Just to outline one of the issues.
  >> 
  >> Take any 3GPP GPRS enabled mobile phone where you have a 
  >browser open 
  >> and it is browsing the general internet. In your 
  >understanding that 
  >> would be a device on the Internet.
  >> 
  >> However if the user attempts to make an emergency call from that 
  >> device, 3GPP specifies that certain things should happen 
  >if the user 
  >> happens to press the keys associated with making an 
  >emergency call, 
  >> and the device then recognises an emergency call. It then 
  >goes on to 
  >> specify how the emergency call is made from such a device. 
  >That set of 
  >> procedures is not the same as specified in phonebcp.
  >> 
  >> In this case 3GPP assumes in their specifications that the 3GPP 
  >> procedures take precedence, and indeed most people would 
  >consider that 
  >> for this particular device, despite it being a device 
  >attached to the 
  >> Internet, those procedures are the best first mechanism to 
  >attempt to 
  >> make an emergency call.
  >> 
  >> regards
  >> 
  >> Keith
  >> 
  >> > -----Original Message-----
  >> > From: Brian Rosen [mailto:[email-masked]]
  >> > Sent: Thursday, July 30, 2009 9:22 PM
  >> > To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc Linsner'; 'ecrit'
  >> > Subject: RE: [Ecrit] HUM on PhoneBCP
  >> >
  >> > I specified the Internet, and not an internet.  Usually 
  >we mean the 
  >> > public Internet.  I think we have a decent definition of 
  >that.  It 
  >> > wouldn't cover, for example, a closed network like a  
  >IMS call on a 
  >> > cellular 3G network.
  >> > Might include, however, something like a call on an IMS 
  >network from 
  >> > a nomading customer on some random public access 
  >network, depends.
  >> >
  >> > Anyway, I said I was willing to do the edit in a effort to gain 
  >> > consensus.
  >> >
  >> > Brian
  >> >
  >> > > -----Original Message-----
  >> > > From: DRAGE, Keith (Keith) [mailto:[email-masked]]
  >> > > Sent: Thursday, July 30, 2009 4:13 PM
  >> > > To: Brian Rosen; 'Elwell, John'; 'Marc Linsner'; 'ecrit'
  >> > > Subject: RE: [Ecrit] HUM on PhoneBCP
  >> > >
  >> > > I don't believe you can use the word "Internet" to target a
  >> > distinct
  >> > > scope of phonebcp from other SDOs work in this area.
  >> > >
  >> > > But I'll follow the argument through if you really want. Which 
  >> > > well known definition of internet are you using so we 
  >start from
  >> > a common
  >> > > baseline?
  >> > >
  >> > > regards
  >> > >
  >> > > Keith
  >> > >
  >> > > > -----Original Message-----
  >> > > > From: Brian Rosen [mailto:[email-masked]]
  >> > > > Sent: Thursday, July 30, 2009 6:15 PM
  >> > > > To: 'Elwell, John'; DRAGE, Keith (Keith); 'Marc 
  >Linsner'; 'ecrit'
  >> > > > Subject: RE: [Ecrit] HUM on PhoneBCP
  >> > > >
  >> > > > The IETF does work targeted to the Internet. Other SDOs
  >> > do work on
  >> > > > different kinds of networks other than the Internet.
  >> > > > The document describes best current practice for
  >> > emergency calls on
  >> > > > the Internet.
  >> > > >
  >> > > > Brian
  >> > > >
  >> > > > > -----Original Message-----
  >> > > > > From: [email-masked]
  >> > > > [mailto:[email-masked]] On Behalf
  >> > > > > Of Elwell, John
  >> > > > > Sent: Thursday, July 30, 2009 1:02 PM
  >> > > > > To: DRAGE, Keith (Keith); Marc Linsner; ecrit
  >> > > > > Subject: Re: [Ecrit] HUM on PhoneBCP
  >> > > > >
  >> > > > >
  >> > > > >
  >> > > > > > -----Original Message-----
  >> > > > > > From: [email-masked]
  >> > [mailto:[email-masked]] On
  >> > > > > > Behalf Of DRAGE, Keith (Keith)
  >> > > > > > Sent: 30 July 2009 09:01
  >> > > > > > To: Marc Linsner; 'ecrit'
  >> > > > > > Subject: Re: [Ecrit] HUM on PhoneBCP
  >> > > > > >
  >> > > > > > I don't agree.
  >> > > > > >
  >> > > > > > Some background.
  >> > > > > >
  >> > > > > > There was a set of comments provided by Stephen Edge on
  >> > > > 5th February
  >> > > > > > 2009. I can find no response to that set of comments on
  >> > > > the mailing
  >> > > > > > list.
  >> > > > > >
  >> > > > > > The gist of that set of comments was that phonebcp claims
  >> > > > to cover
  >> > > > > > all access technologies and it identified a
  >> > significant number
  >> > > > > > of requirements within phonebcp that the author
  >> > considered were
  >> > > > > > not requirements on 3GPP accesses.
  >> > > > > >
  >> > > > > > So my position is that the document is not ready
  >> > because all the
  >> > > > > > valid comments on the document were not addressed.
  >> > > > > >
  >> > > > > > There are two ways of dealing with this set of comments:
  >> > > > > >
  >> > > > > > -    going through and modifying all the identified
  >> > > > > > requirements where the comment is upheld.
  >> > > > > >
  >> > > > > > -    making more clear in the abstract and / or 
  >introduction
  >> > > > > > that this is solely the view of IETF in regard to IP
  >> > > > capable devices
  >> > > > > > and that other organisations may specify other 
  >requirements.
  >> > > > > >
  >> > > > > > I would note at this point that the current 
  >abstract says:
  >> > > > > >
  >> > > > > >    The IETF and other standards organization have efforts
  >> > > > targeted at
  >> > > > > >    standardizing various aspects of placing emergency
  >> > calls on IP
  >> > > > > >    networks.  This memo describes best current
  >> > practice on how
  >> > > > > > devices,
  >> > > > > >    networks and services should use such standards to
  >> > > > make emergency
  >> > > > > >    calls.
  >> > > > > >
  >> > > > > > Because the two sentences follow each other, it implies
  >> > > > that other
  >> > > > > > SDOs that have efforts targetted at addressing these
  >> > > > solutions are
  >> > > > > > complicit in the requirements so stated, and 
  >this is untrue.
  >> > > > > [JRE] I agree that this juxtaposition of 
  >statements is rather 
  >> > > > > misleading, and would suggest we try to improve. In
  >> > fact the only
  >> > > > > "other standards organization"  responsible for "such
  >> > standards"
  >> > > > > is ANSI/TIA, since LLDP-MED is the only normative reference
  >> > > > (and I would
  >> > > > > argue that LLDP-MED is not specifically targeted at
  >> > > > emergency calls).
  >> > > > > So perhaps we can reword the abstract to say "The IETF has
  >> > > > efforts..."
  >> > > > >
  >> > > > > John
  >> > > > >
  >> > > > >
  >> > > > > Certainly the current status of this document
  >> > > > > > as addressed by various informal 3GPP discussions is to
  >> > > > ensure that
  >> > > > > > things do not fall apart in entities using the 3GPP
  >> > mechanisms,
  >> > > > > > however 3GPP devices do not use these requirements
  >> > (no do these
  >> > > > > > requirements represent the 3GPP requires.
  >> > > > > >
  >> > > > > > One solution to the issue would just be to make much
  >> > > > clearer which
  >> > > > > > SDOs have participated in this work and which have
  >> > not and the
  >> > > > > > status of that progress - however that was also what
  >> > people keep
  >> > > > > > calling the "applicability statement" was trying to do.
  >> > > > > >
  >> > > > > > regards
  >> > > > > >
  >> > > > > > Keith
  >> > > > > >
  >> > > > > >
  >> > > > > >
  >> > > > > >
  >> > > > > > ________________________________
  >> > > > > >
  >> > > > > > 	From: [email-masked] 
  >> > > > > > [mailto:[email-masked]] On Behalf Of Marc Linsner
  >> > > > > > 	Sent: Wednesday, July 29, 2009 2:53 PM
  >> > > > > > 	To: 'ecrit'
  >> > > > > > 	Subject: [Ecrit] HUM on PhoneBCP
  >> > > > > >
  >> > > > > >
  >> > > > > > 	During today's meeting there was discussion as to why
  >> > > > the chairs
  >> > > > > > Publication Requested PhoneBCP version 13 when there are
  >> > > > unresolved
  >> > > > > > issues.  This discussion led us to call for a hum.
  >> > We are now
  >> > > > > > asking the same question on the list.
  >> > > > > >
  >> > > > > > 	Do you agree or disagree that PhoneBCP -13 is ready to
  >> > > > Publication
  >> > > > > > Request?
  >> > > > > >
  >> > > > > > 	Please respond by close of business on Wednesday August
  >> > > 5th.
  >> > > > > >
  >> > > > > > 	Thanks,
  >> > > > > >
  >> > > > > > 	Marc & Hannes
  >> > > > > >
  >> > > > > >
  >> > > > > >
  >> > > > > _______________________________________________
  >> > > > > Ecrit mailing list
  >> > > > > [email-masked]
  >> > > > > https://www.ietf.org/mailman/listinfo/ecrit
  >> > > >
  >> > > > =
  >> >
  >> > =
  >
  >_______________________________________________
  >Ecrit mailing list
  >[email-masked]
  >https://www.ietf.org/mailman/listinfo/ecrit
  >

---

From: Andrew Newton <[email-masked]>
Date: Mon, 3 Aug 2009 15:16:30 -0400

But isn't it fun to debate the meaning of the "Internet"?

I don't think Stephen's concerns should hold up either document.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 3 Aug 2009 23:18:49 -0500

I interpret Brian's comment as being that a conventional *switched
circuit* mobile phone service is not the same as an Internet [call]
service. I think that's pretty apparent from the context. Would you
claim that it is, in fact, the Internet when a switched circuit call is
made Gabor?

Comments about reliability are misleading. Either architectural solution
can be made arbitrarily reliable. Both can be deployed in the context of
managed access according to the requirements applied by the
jurisdiction.

There's been a presumption in this debate that somehow ECRIT needs
"apologists" relative to IMS because IMS has a complete, definitive, and
apparently infinitely versatile definition for handling emergency calls
in 3GPP access. It would be reasonable to infer from the representations
made with respect to the IMS model that this definition is clear, well
understood, and unambiguous to those familiar with the domain. I'd like
to explore that premise a little.

While you're contributing your knowledge to the discussion then Gabor,
could you please elaborate on the detailed procedures, including which
protocols are employed, when an emergency call is invoked according to
3GPP 23.167?

I'll grant that, somehow, the UE has recognized the appropriate E-CSCF
in that managed network and now needs to invoke the emergency service
procedures. As the spec points out, there's the Ml interface to the
location routing function (LRF). Can you please describe the details as
defined by 3GPP from then on? Or, alternatively, could you point to the
detailed procedure specification that explains what actually occurs? The
analogue from the ECRIT perspective is quite well elaborated, including
the use of LoST for the routing query and the use of candidate LCPs for
the location determination by value and by reference, the associated
conveyance of location value/reference in SIP etc.

I'm sure IETF participants would appreciate and benefit from elucidation
of just what the 3GPP "secret sauce" is. I don't want to leave anyone
out and, of course, invite other 3GPP knowledgeable and vocal parties to
contribute.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, 4 August 2009 12:38 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ecrit] HUM on PhoneBCP

  >there are some subtle differences (the DNS root for 

These are deployment and operational decisions, which have nothing to do
with the ongoing discussion.

  >3GPP is studiously ignoring.

3gpp has defined a set of different procedures for emergency calls, and
carriers will likely ask vendors to implement as specified. Then users
will also use it as specified.

  >understood the tradeoffs.

It is not a question of preference. Carriers want to have a solution
which is reliable and operational 99.99999% of the cases. It has to be a
stricly managed network.

  >service, no matter how you stretch it.

Wow. What is your definition of Internet Service? I do remember
statements on this mailing list that cellular networks are not IP
capable. I guess you didn't want to go that far.
I access the same content regardless of whether I use the comcast cable
ending in the house or t-mobile's packet data service anywhere else. The
only difference is the speed and the cost. 
Looks the same to me, no matter how I strech it.

- gabor

------------------------------------------------------------------------------------------------
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: Francois Menard <[email-masked]>
Date: Tue, 4 Aug 2009 02:49:02 -0400

Hum for me, however, I remember that back in june, John Lange  
suggested making reference to:

http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery-02

Its still missing from version 13...

f.

On 29-Jul-09, at 9:53 AM, Marc Linsner wrote:

> During today’s meeting there was discussion as to why the chairs  
> Publication Requested PhoneBCP version 13 when there are unresolved  
> issues.  This discussion led us to call for a hum.  We are now  
> Do you agree or disagree that PhoneBCP -13 is ready to Publication  
> Request?
>
> Please respond by close of business on Wednesday August 5th.
>
> Thanks,
>
> Marc & Hannes

Francois Menard
[email-masked]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 4 Aug 2009 10:06:16 +0300

Hi Francois, 
 
I hope not a normative reference. Right? 
 
Ciao
Hannes

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Francois Menard
	Sent: 04 August, 2009 09:49
	To: Marc Linsner
	Cc: 'ecrit'
	Subject: Re: [Ecrit] HUM on PhoneBCP

	f.

		During today's meeting there was discussion as to why
the chairs Publication Requested PhoneBCP version 13 when there are
unresolved issues.  This discussion led us to call for a hum.  We are
now asking the same question on the list.
		
Publication Request?

		Thanks,
		
		Marc & Hannes

	Francois Menard
	[email-masked]

---

From: Francois Menard <[email-masked]>
Date: Tue, 4 Aug 2009 07:39:46 -0400

I would agree that under a simplified architecture, where the  
operator's network supports DHCP-based PIDF-LO download, and the end- 
point supports sipcore-loc-conveyance, that there is no need for a LIS  
discovery process, so it should not be made mandatory.  As per the  
BCP, the end-point should still have a HELD client built into it, but  
would not need to use it in this case.

Hum is maintained.

What does 'entitlement' to publication actually gives... does the BCP  
still remains a document which will be subject to further revisions?

F.

Francois Menard
[email-masked]

---

From: <[email-masked]>
Date: Tue, 4 Aug 2009 20:40:39 +0200

>From: ext Dawson, Martin [mailto:[email-masked]]
  >Sent: Monday, August 03, 2009 9:19 PM
  >To: Bajko Gabor (Nokia-CIC/MtView); [email-masked];
  >[email-masked];
  >Subject: ECRIT/IMS - independent discussion from the PhoneBCP hum
  >
  >circuit* mobile phone service is not the same as an Internet
  >[call] service. I think that's pretty apparent from the
  >context.

This might have been what Brian meant, but it wasn't obvious for me, especially as circuit switching is not part of 3G (HSPA or LTE), that is 2G.

  >Would you claim that it is, in fact, the Internet
  >when a switched circuit call is made Gabor?

No, I don't say that. But would you claim that a VoIP call made on a 3G (packet switched) network is not an Internet Service?

  >Comments about reliability are misleading. Either
  >architectural solution can be made arbitrarily reliable.

Yes, they can. But as we can see, unless it is required by regulation, reliability is missing. Carriers operating in licenced bands have to meet certain conditions, while a network operating in an unlicenced band is free to turn on/off its operation.

  >Both can be deployed in the context of managed access
  >according to the requirements applied by the jurisdiction.

Certain radio access protocols are inherently unreliable.

  >There's been a presumption in this debate that somehow ECRIT
  >needs "apologists" relative to IMS because IMS has a
  >complete, definitive, and apparently infinitely versatile
  >definition for handling emergency calls in 3GPP access.

;)
I am by far not an IMS evangelist, nor an ECRIT one, so I'd rather stay out from these kind of debates.
What people seem to have trouble understanding is that some networks (eg the ones operating in licenced bands) can not afford to rely on the client to do all the procedures needed to place an emergency call. They need to assist the client and make sure the call ends up in the right place. They are liable for that. That's the difference.

  >  It
  >would be reasonable to infer from the representations made
  >with respect to the IMS model that this definition is clear,
  >well understood, and unambiguous to those familiar with the
  >domain. I'd like to explore that premise a little.
  >
  >While you're contributing your knowledge to the discussion
  >then Gabor, could you please elaborate on the detailed
  >procedures, including which protocols are employed, when an
  >emergency call is invoked according to 3GPP 23.167?
  >
  >I'll grant that, somehow, the UE has recognized the
  >appropriate E-CSCF in that managed network and now needs to
  >invoke the emergency service procedures. As the spec points
  >out, there's the Ml interface to the location routing
  >function (LRF). Can you please describe the details as
  >defined by 3GPP from then on? Or, alternatively, could you
  >point to the detailed procedure specification that explains
  >what actually occurs? The analogue from the ECRIT
  >perspective is quite well elaborated, including the use of
  >LoST for the routing query and the use of candidate LCPs for
  >the location determination by value and by reference, the
  >associated conveyance of location value/reference in SIP etc.

Brian sent me off-list a pretty comprehensive list of issues where the 3GPP procedures differ from the ones defined in ECRIT. Since that list is by far more complete than the one I could produce, I will copy paste it below. I hope Brian doesn't mind it:

" At the moment, the major differences between 3GPP and phonebcp are:
a) Who inserts location, and what protocols are used
b) LoST (3GPP doesn't say LoST can't be used; it basically leaves this as local practice.  Since in North America, LoST will be mandated, that's not a difference.  However, 3GPP would say that LoST, if used, would be queried by the E-CSCF, and not the endpoint, which differs from -phonebcp
c) SIP termination: present 3GPP specs make no provision for packet mode termination.

There are some relatively minor signaling issues.

To be phonebcp compatible, 3GPP networks would have to implement one of the -phonebcp LCPs, and provide access to a LoST server.  The former is a big issue, the latter is a small issue."

My request was to either restrict the scope of the document to 'Internet', or make it a requirements document (instead of bcp) with intended status standards track. Writing a bcp which excludes the most likely near future practice looks weird to me.

- Gabor

  >I'm sure IETF participants would appreciate and benefit from
  >elucidation of just what the 3GPP "secret sauce" is. I don't
  >want to leave anyone out and, of course, invite other 3GPP
  >knowledgeable and vocal parties to contribute.
  >
  >Cheers,
  >Martin
  >
  >On Behalf Of [email-masked]
  >These are deployment and operational decisions, which have
  >nothing to do with the ongoing discussion.
  >
  >3gpp has defined a set of different procedures for emergency
  >calls, and carriers will likely ask vendors to implement as
  >specified. Then users will also use it as specified.
  >
  >It is not a question of preference. Carriers want to have a
  >solution which is reliable and operational 99.99999% of the
  >cases. It has to be a stricly managed network.
  >
  >Wow. What is your definition of Internet Service? I do
  >remember statements on this mailing list that cellular
  >networks are not IP capable. I guess you didn't want to go that far.
  >I access the same content regardless of whether I use the
  >comcast cable ending in the house or t-mobile's packet data
  >service anywhere else. The only difference is the speed and
  >the cost.
  >immediately and delete the original.  Any unauthorized use
  >of this email is prohibited.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 4 Aug 2009 18:11:58 -0500

Hi Gabor,

I would like to point out what I see as a problem in your reasoning, and to do that I will use the analogy of a DSL service.

Firstly, I agree with you that 3G SHOULD be regarded as just another Internet access technology, the fact that certain applications are unreasonably disabled by the providers of these access services aside.

When I buy a wireline broadband service I buy that service form an ISP. That provider may or may not have any underlying access infrastructure of their own, certainly in Australia it is very likely that they whole the access from the large carrier here. I can then go to one of many of the independent VoIP service providers and buy a service from them that I expect to just work over my newly bought wireline Internet access service.

Your argument seems to be that this model can't apply to the 3G space because the underlying access provider is somehow obliged to route emergency calls. 

My counter argument is this, that the 3G carrier is no more obliged to route these calls than the ISP or the underlying copper wire owner in my DSL example. The content of my packets should be largely invisible to the access provider. This is what happens with other broadband technologies operating in licensed spectrum, why is 3GPP somehow special here?  

I believe that your argument doesn't apply if the service is just a broadband pipe, it only applies if I also buy other things such as a voice service from the operator.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Tue 8/4/2009 1:40 PM
To: Dawson, Martin; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum

;)

- Gabor

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 4 Aug 2009 20:37:19 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, 5 August 2009 4:41 AM
To: Dawson, Martin; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: ECRIT/IMS - independent discussion from the PhoneBCP hum

  >[email-masked]; [email-masked];

  >[email-masked]

  >context.

This might have been what Brian meant, but it wasn't obvious for me,
especially as circuit switching is not part of 3G (HSPA or LTE), that is
2G.

[[MCD]] Exactly - but much has been made of how 3GPP/IMS has defined
ways of providing transparent hand-off between packet service and
circuit service in the context of an emergency call, with the subsequent
inference that this makes ECRIT non-applicable in a 3GPP access context.
That's an incorrect inference and the scenario is orthogonal to the
purpose of ECRIT. Nevertheless, I'm genuinely interested in the details
- i.e. how does IMS state that this is done (not a description of how it
*could* be done by someone but what are the exact protocols and
procedures specified). I'm particularly interested in how these
procedures appear to the end device and the emergency network.

  >when a switched circuit call is made Gabor?

No, I don't say that. But would you claim that a VoIP call made on a 3G
(packet switched) network is not an Internet Service?

[[MCD]] I do think it's an Internet context in that case - and that's
the case where I have no difficulty seeing that ECRIT is applicable.

  >architectural solution can be made arbitrarily reliable.

Yes, they can. But as we can see, unless it is required by regulation,
reliability is missing. Carriers operating in licenced bands have to
meet certain conditions, while a network operating in an unlicenced band
is free to turn on/off its operation.

[[MCD]] Legislation imposing reliability and the question of unlicensed
bands are both orthogonal. ECRIT is applicable to a broadband access
regardless of, and independently constrained by, those considerations.
Regulation is a movable feast - in the US, the Phase 2 regulation was
aimed at CMRS (circuit service) E9-1-1. The FCC is still kicking around
the ideas associated with VoIP. There's no doubt that, from a technical
perspective, IMS is VoIP. The question of how operators choose to
interpret their own obligations wrt IMS is subject to their own risk and
business assessments including how they present that service to their
subscribers. That is, do they regard it as phase 2 cellular or do they
regard it as VoIP? But that's just the US. Any arbitrary jurisdiction
could say that any provider of broadband Internet access to the public
is required to support the ECRIT compliant functions of a LIS, access to
LoST, and a reliable route to the PSAP URI(s) applicable to the
operators' areas of coverage. They could further require specific levels
of reliability/availability and accuracy. They could require it of
municipal WiFi network operators (unlicensed band) just as much as they
could of licensed band wireless operators. They could even require it of
enterprises of a certain size (unlicensed wireless and wired Ethernet).
The point is that the existence of regulatory requirements or otherwise
does not militate against the applicability of ECRIT to specific
technologies.

[[MCD]] Well - I certainly have reliability problems with GSM and UMTS
coverage in a lot of places... but, again, the reliability of any given
technology does not say anything about the applicability of ECRIT to
that or other technologies.

;)

I am by far not an IMS evangelist, nor an ECRIT one, so I'd rather stay
out from these kind of debates.

What people seem to have trouble understanding is that some networks (eg
the ones operating in licenced bands) can not afford to rely on the
client to do all the procedures needed to place an emergency call. They
need to assist the client and make sure the call ends up in the right
place. They are liable for that. That's the difference.

[[MCD]] I don't actually understand how you infer that people involved
in this debate don't understand those issues; I don't see the evidence
of that. In any case, all existing licensed mobile networks absolutely
rely on functionality within the device to make emergency calls;
standards have to be supported or the device cannot be used. I'm also
not asking for a position in the debate; I'm asking for elucidation of
how IMS achieves all the things that are claimed for it (exactly) given
the context that ECRIT is argued to be inadequate in comparison. That
detail, so far, has been assumed and not provided as part of the debate.

  >associated conveyance of location value/reference in SIP etc.

Brian sent me off-list a pretty comprehensive list of issues where the
3GPP procedures differ from the ones defined in ECRIT. Since that list
is by far more complete than the one I could produce, I will copy paste
it below. I hope Brian doesn't mind it:

b) LoST (3GPP doesn't say LoST can't be used; it basically leaves this
as local practice.  Since in North America, LoST will be mandated,
that's not a difference.  However, 3GPP would say that LoST, if used,
would be queried by the E-CSCF, and not the endpoint, which differs from
-phonebcp

c) SIP termination: present 3GPP specs make no provision for packet mode
termination.

To be phonebcp compatible, 3GPP networks would have to implement one of
the -phonebcp LCPs, and provide access to a LoST server.  The former is
a big issue, the latter is a small issue."

[[MCD]] I understand the philosophical difference - and how, for
example, ECRIT could support an emergency call initiated from an
ECRIT-compliant emergency client on a child's portable game console
connected to the in-vehicle WiFi connected to the Internet via an LTE
access network (but it's difficult to see how IMS can do that). I'm
actually asking for the specific details (end-to-end and including the
protocols used) of an IMS call according to 23.167 as part of an attempt
to ensure that both sides of the debate are equipped with the same
information.

My request was to either restrict the scope of the document to
'Internet', or make it a requirements document (instead of bcp) with
intended status standards track. Writing a bcp which excludes the most
likely near future practice looks weird to me.

[[MCD]] I'm comfortable that the scope of the document is restricted to
"Internet" - or certainly to IP (internet with a lower case 'i')
networks generally. It's just that others would like to see some
indication that, somehow, it doesn't apply to 3GPP networks - even
though it does.

- Gabor

  >[email-masked]; [email-masked];

  >[email-masked]

  >  >To: 'DRAGE, Keith (Keith)'; 'Elwell, John'; 'Marc

  >  >> > To: DRAGE, Keith (Keith); 'Elwell, John'; 'Marc

  >  >> > Anyway, I said I was willing to do the edit in a

  >effort to gain

  >  >> > > But I'll follow the argument through if you really

  >want. Which

  >  >> > > > > > There was a set of comments provided by

  >Stephen Edge on

  >  >> > > > > > 2009. I can find no response to that set of

  >comments on

  >  >> > > > > > The gist of that set of comments was that

  >phonebcp claims

  >  >> > > > > > There are two ways of dealing with this set

  >of comments:

  >  >> > > > > >    The IETF and other standards organization

  >have efforts

  >  >> > > > > > Because the two sentences follow each other,

  >it implies

  >  >> > > > > is ANSI/TIA, since LLDP-MED is the only

  >normative reference

  >  >> > > > > So perhaps we can reword the abstract to say

  >"The IETF has

  >  >> > > > > > as addressed by various informal 3GPP

  >discussions is to

  >  >> > > > > > calling the "applicability statement" was

  >trying to do.

  >  >> > > > > > [mailto:[email-masked]] On Behalf Of

  >Marc Linsner

  >  >> > > > > >       During today's meeting there was

  >discussion as to why

  >  >> > > > > > Publication Requested PhoneBCP version 13

  >when there are

  >  >> > > > > >       Do you agree or disagree that PhoneBCP

  >-13 is ready to

  >  >> > > > > >       Please respond by close of business on

  >Wednesday August

  >-------------------------------------------------------------

  >-----------------------------------

  >-------------------------------------------------------------

  >-----------------------------------

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 5 Aug 2009 11:15:54 -0700

Based on a little more detail, I agree that the document is NOT ready.  
 
I have been told that 3GPP's intent is to discuss this at their next
formal meeting.  If we say that we want to work together with 3GPP, then
we should hold off moving it forward until we receive their feedback.
 
-roger marshall.

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Randall Gellens
	Sent: Thursday, July 30, 2009 5:40 AM
	To: DRAGE, Keith (Keith); Marc Linsner; 'ecrit'
	Subject: Re: [Ecrit] HUM on PhoneBCP

	+1.  The document is not ready.

	Further, there is a liaison from 3GPP SA2 that says that they
intend to send further liaison on this document.  We should wait at
least a little while for this liaison.

	At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE wrote:

		I don't agree.

		Some background.

		There was a set of comments provided by Stephen Edge on
5th February 2009. I can find no response to that set of comments on the
mailing list.

		The gist of that set of comments was that phonebcp
claims to cover all access technologies and it identified a significant
number of requirements within phonebcp that the author considered were
not requirements on 3GPP accesses.

		So my position is that the document is not ready because
all the valid comments on the document were not addressed.

		-    making more clear in the abstract and / or
introduction that this is solely the view of IETF in regard to IP
capable devices and that other organisations may specify other
requirements.

		I would note at this point that the current abstract
says:

		   The IETF and other standards organization have
efforts targeted at

		   standardizing various aspects of placing emergency
calls on IP
		   networks.  This memo describes best current practice
on how devices,
		   networks and services should use such standards to
make emergency
		   calls.

		Because the two sentences follow each other, it implies
that other SDOs that have efforts targetted at addressing these
solutions are complicit in the requirements so stated, and this is
untrue. Certainly the current status of this document as addressed by
various informal 3GPP discussions is to ensure that things do not fall
apart in entities using the 3GPP mechanisms, however 3GPP devices do not
use these requirements (no do these requirements represent the 3GPP
requires.

		One solution to the issue would just be to make much
clearer which SDOs have participated in this work and which have not and
the status of that progress - however that was also what people keep
calling the "applicability statement" was trying to do.

		regards

		Keith

			During today's meeting there was discussion as
to why the chairs Publication Requested PhoneBCP version 13 when there
are unresolved issues.  This discussion led us to call for a hum.  We
are now asking the same question on the list.
			
			Do you agree or disagree that PhoneBCP -13 is
ready to Publication Request?
			
			Please respond by close of business on Wednesday
August 5th.
			
			Thanks,

			Marc & Hannes

	-- 
	Randall Gellens
	Opinions are personal;    facts are suspect;    I speak for
myself only
	-------------- Randomly selected tag: ---------------
	I worry that the person who thought up Muzak may be thinking up
	something else.
	 --Lily Tomlin

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Carlberg, Kenneth G." <[email-masked]>
Date: Wed, 5 Aug 2009 14:22:05 -0400

out of curiousity, when is their next meeting, and how strong is this
"intent"?  Is it firm on their calendar, or is there a reasonable
possibility that it won't be discussed but deferred until some future
time?
 
(speaking as one who has no stake in the matter other than wishing it
get resolved soon)
 
-ken

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Roger Marshall
	Sent: Wednesday, August 05, 2009 2:16 PM
	To: Randall Gellens; DRAGE, Keith (Keith); Marc Linsner; ecrit
	Subject: Re: [Ecrit] HUM on PhoneBCP

	Based on a little more detail, I agree that the document is NOT
ready.  
	 
	I have been told that 3GPP's intent is to discuss this at their
next formal meeting.  If we say that we want to work together with 3GPP,
then we should hold off moving it forward until we receive their
feedback.
	 
	-roger marshall.

[mailto:[email-masked]] On Behalf Of Randall Gellens

		Further, there is a liaison from 3GPP SA2 that says that
they intend to send further liaison on this document.  We should wait at
least a little while for this liaison.

			I don't agree.

			Some background.

			There was a set of comments provided by Stephen
Edge on 5th February 2009. I can find no response to that set of
comments on the mailing list.

			The gist of that set of comments was that
phonebcp claims to cover all access technologies and it identified a
significant number of requirements within phonebcp that the author
considered were not requirements on 3GPP accesses.

			So my position is that the document is not ready
because all the valid comments on the document were not addressed.

			There are two ways of dealing with this set of
comments:

			-    going through and modifying all the
identified requirements where the comment is upheld.

have efforts targeted at

			   standardizing various aspects of placing
emergency calls on IP
			   networks.  This memo describes best current
practice on how devices,
			   networks and services should use such
standards to make emergency
			   calls.

			Because the two sentences follow each other, it
implies that other SDOs that have efforts targetted at addressing these
solutions are complicit in the requirements so stated, and this is
untrue. Certainly the current status of this document as addressed by
various informal 3GPP discussions is to ensure that things do not fall
apart in entities using the 3GPP mechanisms, however 3GPP devices do not
use these requirements (no do these requirements represent the 3GPP
requires.

			One solution to the issue would just be to make
much clearer which SDOs have participated in this work and which have
not and the status of that progress - however that was also what people
keep calling the "applicability statement" was trying to do.

			regards

			Keith

				During today's meeting there was
discussion as to why the chairs Publication Requested PhoneBCP version
13 when there are unresolved issues.  This discussion led us to call for
a hum.  We are now asking the same question on the list.
				
				Do you agree or disagree that PhoneBCP
-13 is ready to Publication Request?
				
Wednesday August 5th.
				
				Thanks,

				Marc & Hannes

		-- 
		Randall Gellens
		Opinions are personal;    facts are suspect;    I speak
for myself only
		-------------- Randomly selected tag: ---------------
		I worry that the person who thought up Muzak may be
thinking up
		something else.
		 --Lily Tomlin

	CONFIDENTIALITY NOTICE: The information contained in this
message may be privileged and/or confidential. If you are not the
intended recipient, or responsible for delivering this message to the
intended recipient, any review, forwarding, dissemination, distribution
or copying of this communication or any attachment(s) is strictly
prohibited. If you have received this message in error, please notify
the sender immediately, and delete it and all attachments from your
computer and network.

---

From: Marc Linsner <[email-masked]>
Date: Wed, 05 Aug 2009 14:39:09 -0400

Ken,

Take a look at the liaison.

https://datatracker.ietf.org/liaison/551/

Cullen committed to handling any comments/issues they bring to us during
IESG review or IETF last call.  Of course, that commitment includes keeping
the ECRIT wg involved.

-Marc-

On 8/5/09 2:22 PM, "Carlberg, Kenneth G." <[email-masked]>
wrote:

> "intent"?  Is it firm on their calendar, or is there a reasonable possibility
> that it won't be discussed but deferred until some future time?
>  
> (speaking as one who has no stake in the matter other than wishing it get
> resolved soon)
>  
> -ken
> 
>  
>>  
>>  
>> 
>>  From: [email-masked]  [mailto:[email-masked]] On Behalf Of
>> Roger  Marshall
>> I have been told that 3GPP's intent is to discuss this at  their next formal
>> meeting.  If we say that we want to work together  with 3GPP, then we should
>> hold off moving it forward until we receive  their feedback.
>>  
>>  
>>  
>> -roger marshall.
>> 
>>  
>>>  
>>>  
>>> 
>>>  From: [email-masked]  [mailto:[email-masked]] On Behalf Of
>>> Randall  Gellens
>>> Further, there is a liaison from 3GPP SA2 that says that they intend to
>>> send further liaison on this document.  We should wait at least a  little
>>> while for this liaison.
>>>  
>>> 
>>>  
>>>> There was a  set of comments provided by Stephen Edge on 5th February 2009.
>>>> I can find  no response to that set of comments on the mailing list.
>>>  
>>>>  
>>>  
>>>> The gist of  that set of comments was that phonebcp claims to cover all
>>>> access  technologies and it identified a significant number of requirements
>>>> within  phonebcp that the author considered were not requirements on 3GPP
>>>> accesses.
>>>  
>>>>  
>>>  
>>>> So my  position is that the document is not ready because all the valid
>>>> comments  on the document were not addressed.
>>>  
>>>>  
>>>  
>>>> -    going through and modifying all the  identified requirements where the
>>>> comment is upheld.
>>>  
>>>>  
>>>  
>>>> -    making more clear in the abstract and /  or introduction that this is
>>>> solely the view of IETF in regard to IP  capable devices and that other
>>>> organisations may specify other  requirements.
>>>  
>>>>  
>>>  
>>>> I would  note at this point that the current abstract says:
>>>  
>>>>  
>>>  
>>>>    The IETF and other standards organization have  efforts targeted at
>>>  
>>>>    standardizing various aspects of placing  emergency calls on IP
>>>>    networks.  This memo describes  best current practice on how devices,
>>>>    networks and  services should use such standards to make emergency
>>>>     calls.
>>>  
>>>> Because the  two sentences follow each other, it implies that other SDOs
>>>> that have  efforts targetted at addressing these solutions are complicit in
>>>> the  requirements so stated, and this is untrue. Certainly the current
>>>> status  of this document as addressed by various informal 3GPP discussions
>>>> is to  ensure that things do not fall apart in entities using the 3GPP
>>>> mechanisms, however 3GPP devices do not use these requirements (no do
>>>> these requirements represent the 3GPP requires.
>>>  
>>>>  
>>>  
>>>> One  solution to the issue would just be to make much clearer which SDOs
>>>> have  participated in this work and which have not and the status of that
>>>> progress - however that was also what people keep calling the
>>>> "applicability statement" was trying to do.
>>>  
>>>>  
>>>  
>>>> regards
>>>  
>>>>  
>>>  
>>>> Keith
>>>  
>>>>  
>>>  
>>>>  
>>>  
>>>> 
>>>>  
>>>>>  
>>>>> 
>>>>>  
>>>>  
>>>>> From: [email-masked]  [mailto:[email-masked]] On Behalf Of
>>>>> Marc  Linsner
>>>>> During today's meeting there was  discussion as to why the chairs
>>>>> issues.  This discussion led us to  call for a hum.  We are now asking the
>>>>> same question on the  list.
>>>>>

---

From: <[email-masked]>
Date: Wed, 5 Aug 2009 20:50:21 +0200

________________________________
From: ext Dawson, Martin [mailto:[email-masked]]
Sent: Tuesday, August 04, 2009 6:37 PM
To: Bajko Gabor (Nokia-CIC/MtView); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: ECRIT/IMS - independent discussion from the PhoneBCP hum

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 5 August 2009 4:41 AM
To: Dawson, Martin; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: ECRIT/IMS - independent discussion from the PhoneBCP hum

[[MCD]] Exactly - but much has been made of how 3GPP/IMS has defined ways of providing transparent hand-off between packet service and circuit service in the context of an emergency call, with the subsequent inference that this makes ECRIT non-applicable in a 3GPP access context. That's an incorrect inference and the scenario is orthogonal to the purpose of ECRIT. Nevertheless, I'm genuinely interested in the details - i.e. how does IMS state that this is done (not a description of how it *could* be done by someone but what are the exact protocols and procedures specified). I'm particularly interested in how these procedures appear to the end device and the emergency network.

[[MCD]] I do think it's an Internet context in that case - and that's the case where I have no difficulty seeing that ECRIT is applicable.

[[MCD]] Legislation imposing reliability and the question of unlicensed bands are both orthogonal.

<Gabor> But reliability and mobility were the main architectural design choices in 3GPP. That is why they ended up with that complex architecture! The procedures themselves are a consequence of the architecture.

Carriers plan to switch emergency call handling from CS to PS domain, and they wanted a network controlled ES, they did not want to rely on the handset doing the whole procedure because of the liability. Support for emergency calls is not a revenue generator for carriers, they'd be happy leaving the tasks up to the client if there were no consequences of emergency calls failing for whatever reason.

And just to answer James point, ISPs offering broadband internet service can not be paralelled with carriers operating networks using 3GPP standards. The ISPs do not commit to offer you service with less than a few minutes outage per year, they provide no mobility and they are not mandated to support emergency services.

- gabor

 ECRIT is applicable to a broadband access regardless of, and independently constrained by, those considerations. Regulation is a movable feast - in the US, the Phase 2 regulation was aimed at CMRS (circuit service) E9-1-1. The FCC is still kicking around the ideas associated with VoIP. There's no doubt that, from a technical perspective, IMS is VoIP. The question of how operators choose to interpret their own obligations wrt IMS is subject to their own risk and business assessments including how they present that service to their subscribers. That is, do they regard it as phase 2 cellular or do they regard it as VoIP? But that's just the US. Any arbitrary jurisdiction could say that any provider of broadband Internet access to the public is required to support the ECRIT compliant functions of a LIS, access to LoST, and a reliable route to the PSAP URI(s) applicable to the operators' areas of coverage. They could further require specific levels of reliability/availability and accuracy. They could require it of municipal WiFi network operators (unlicensed band) just as much as they could of licensed band wireless operators. They could even require it of enterprises of a certain size (unlicensed wireless and wired Ethernet). The point is that the existence of regulatory requirements or otherwise does not militate against the applicability of ECRIT to specific technologies.

[[MCD]] Well - I certainly have reliability problems with GSM and UMTS coverage in a lot of places... but, again, the reliability of any given technology does not say anything about the applicability of ECRIT to that or other technologies.

;)

[[MCD]] I don't actually understand how you infer that people involved in this debate don't understand those issues; I don't see the evidence of that. In any case, all existing licensed mobile networks absolutely rely on functionality within the device to make emergency calls; standards have to be supported or the device cannot be used. I'm also not asking for a position in the debate; I'm asking for elucidation of how IMS achieves all the things that are claimed for it (exactly) given the context that ECRIT is argued to be inadequate in comparison. That detail, so far, has been assumed and not provided as part of the debate.

[[MCD]] I understand the philosophical difference - and how, for example, ECRIT could support an emergency call initiated from an ECRIT-compliant emergency client on a child's portable game console connected to the in-vehicle WiFi connected to the Internet via an LTE access network (but it's difficult to see how IMS can do that). I'm actually asking for the specific details (end-to-end and including the protocols used) of an IMS call according to 23.167 as part of an attempt to ensure that both sides of the debate are equipped with the same information.

[[MCD]] I'm comfortable that the scope of the document is restricted to "Internet" - or certainly to IP (internet with a lower case 'i') networks generally. It's just that others would like to see some indication that, somehow, it doesn't apply to 3GPP networks - even though it does.

- Gabor

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 5 Aug 2009 11:51:16 -0700

Ken:
My understanding is that the next meeting will be held from Aug 31 to
Sept 4. Based on the initial liaison response referenced, it appears
that the "intent" is real - as to them having an adequate discussion in
SA WG2 (SA2) on the topic.
 
-roger marshall.

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marc Linsner
	Sent: Wednesday, August 05, 2009 11:39 AM
	To: Carlberg, Kenneth G.; ecrit
	Subject: Re: [Ecrit] HUM on PhoneBCP

	Ken,

	
	Cullen committed to handling any comments/issues they bring to
us during IESG review or IETF last call.  Of course, that commitment
includes keeping the ECRIT wg involved.
	
	-Marc-
	
	On 8/5/09 2:22 PM, "Carlberg, Kenneth G."
<[email-masked]> wrote:

		out of curiousity, when is their next meeting, and how
strong is this "intent"?  Is it firm on their calendar, or is there a
reasonable possibility that it won't be discussed but deferred until
some future time?
		
		(speaking as one who has no stake in the matter other
than wishing it get resolved soon)
		
		-ken

			 

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Roger  Marshall
			Sent: Wednesday, August 05, 2009 2:16 PM
			To:  Randall Gellens; DRAGE, Keith (Keith); Marc
Linsner; ecrit
			Subject:  Re: [Ecrit] HUM on PhoneBCP

			Based on a little more detail, I agree that the
document  is NOT ready.  

			I have been told that 3GPP's intent is to
discuss this at  their next formal meeting.  If we say that we want to
work together  with 3GPP, then we should hold off moving it forward
until we receive  their feedback.

			-roger marshall.

				 

				To: DRAGE,  Keith (Keith); Marc Linsner;
'ecrit'

				 
				Further, there is a liaison from 3GPP
SA2 that says that they intend to  send further liaison on this
document.  We should wait at least a  little while for this liaison.

				At 10:00 AM +0200 7/30/09, Keith (Keith)
DRAGE wrote:

				I don't  agree.

				

				Some  background.

				

				There was a  set of comments provided by
Stephen Edge on 5th February 2009. I can find  no response to that set
of comments on the mailing list.

				

				The gist of  that set of comments was
that phonebcp claims to cover all access  technologies and it identified
a significant number of requirements within  phonebcp that the author
considered were not requirements on 3GPP  accesses.

				

				So my  position is that the document is
not ready because all the valid comments  on the document were not
addressed.

				

				There are  two ways of dealing with this
set of comments:

				

				

				

				-    making more clear in the abstract
and /  or introduction that this is solely the view of IETF in regard to
IP  capable devices and that other organisations may specify other
requirements.

				

				I would  note at this point that the
current abstract says:

				

				  The IETF and other standards
organization have  efforts targeted at

				  standardizing various aspects of
placing  emergency calls on IP
				   networks.  This memo describes  best
current practice on how devices,
				   networks and  services should use
such standards to make emergency
				    calls.

				Because the  two sentences follow each
other, it implies that other SDOs that have  efforts targetted at
addressing these solutions are complicit in the  requirements so stated,
and this is untrue. Certainly the current status  of this document as
addressed by various informal 3GPP discussions is to  ensure that things
do not fall apart in entities using the 3GPP  mechanisms, however 3GPP
devices do not use these requirements (no do  these requirements
represent the 3GPP requires.

				

				One  solution to the issue would just be
to make much clearer which SDOs have  participated in this work and
which have not and the status of that  progress - however that was also
what people keep calling the  "applicability statement" was trying to
do.

				

				regards

				

				Keith

				

				

				

				

				

				During today's meeting there was
discussion as to why the chairs Publication Requested PhoneBCP version
13 when there are unresolved issues.  This discussion led us to  call
for a hum.  We are now asking the same question on the  list.

				
				Thanks,

				Marc &  Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 5 Aug 2009 22:26:40 +0300

Please note that comments can be provided during the IETF Last Call. A
common procedure in the IETF.

The intention was to address comments from the 3GPP, if there are any,
during IETF Last Call and to still advance the document to the IESG. 

Ciao
Hannes

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Carlberg, Kenneth G.
	Sent: 05 August, 2009 21:22
	To: Roger Marshall; Randall Gellens; DRAGE, Keith (Keith); Marc
Linsner; ecrit
	Subject: Re: [Ecrit] HUM on PhoneBCP

	out of curiousity, when is their next meeting, and how strong is
this "intent"?  Is it firm on their calendar, or is there a reasonable
possibility that it won't be discussed but deferred until some future
time?
	 
	(speaking as one who has no stake in the matter other than
wishing it get resolved soon)
	 
	-ken

		To: Randall Gellens; DRAGE, Keith (Keith); Marc Linsner;
ecrit

		Based on a little more detail, I agree that the document
is NOT ready.  
		 
		I have been told that 3GPP's intent is to discuss this
at their next formal meeting.  If we say that we want to work together
with 3GPP, then we should hold off moving it forward until we receive
their feedback.
		 
		-roger marshall.

			Further, there is a liaison from 3GPP SA2 that
says that they intend to send further liaison on this document.  We
should wait at least a little while for this liaison.

			At 10:00 AM +0200 7/30/09, Keith (Keith) DRAGE
wrote:

				I don't agree.

				Some background.

				There was a set of comments provided by
Stephen Edge on 5th February 2009. I can find no response to that set of
comments on the mailing list.

				One solution to the issue would just be
to make much clearer which SDOs have participated in this work and which
have not and the status of that progress - however that was also what
people keep calling the "applicability statement" was trying to do.

				regards

				Keith

					From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marc Linsner
					Sent: Wednesday, July 29, 2009
2:53 PM
					To: 'ecrit'
					Subject: [Ecrit] HUM on PhoneBCP

					Do you agree or disagree that
PhoneBCP -13 is ready to Publication Request?
					
					Please respond by close of
business on Wednesday August 5th.
					
					Thanks,

					Marc & Hannes

			-- 
			
			Randall Gellens
			Opinions are personal;    facts are suspect;
I speak for myself only
			-------------- Randomly selected tag:
---------------
			I worry that the person who thought up Muzak may
be thinking up
			something else.
			 --Lily Tomlin

		CONFIDENTIALITY NOTICE: The information contained in
this message may be privileged and/or confidential. If you are not the
intended recipient, or responsible for delivering this message to the
intended recipient, any review, forwarding, dissemination, distribution
or copying of this communication or any attachment(s) is strictly
prohibited. If you have received this message in error, please notify
the sender immediately, and delete it and all attachments from your
computer and network.

---

From: Marc Linsner <[email-masked]>
Date: Wed, 05 Aug 2009 15:29:50 -0400

Gabor,

>>>  
>>>  
>>> <Gabor> But reliability and mobility were  the main architectural design
>>> choices in 3GPP. That is why they ended up  with that complex architecture!
>>> The procedures themselves are a consequence  of the architecture.
>>>  
>>> Carriers plan to switch emergency call handling  from CS to PS domain, and
>>> they wanted a network controlled ES, they did not  want to rely on the
>>> handset doing the whole procedure because of the  liability. Support for
>>> emergency calls is not a revenue generator  for carriers, they'd be happy
>>> leaving the tasks up to the client if  there were no consequences of
>>> emergency calls failing for whatever  reason.
>>>  
>>> And just to answer James point, ISPs offering  broadband internet service
>>> can not be paralelled with carriers operating  networks using 3GPP
>>> standards. The ISPs do not commit to offer you service  with less than a few
>>> minutes outage per year, they provide no mobility and  they are not mandated
>>> to support emergency  services.
>>>  
>>>  
>>>  
>>> - gabor
>>>  
>>> 
>>> [Marc] Are you implying that 3GPP carriers operating a packet voice service
>>> have a different mandate for supporting emergency services than an OTT
>>> provider that sells packet voice services?  (my understanding, which could
>>> be wrong, is that VoIP is VoIP no matter who is the SP)
>>> 
>>> Or is this a 3GPP self-inflicted mandate that is trying to emulate 2G
>>> circuit-switched services?
>>> 
>>> 
>>> -Marc-
>>>  
>>>  
>>>  
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 5 Aug 2009 14:53:43 -0700

At 8:37 PM -0500 8/4/09, Martin Dawson wrote:

>  It's just that others would like to see some indication that, 
> somehow, it doesn't apply to 3GPP networks - even though it does.

The compromise text didn't say that the ecrit solution can't or 
shouldn't be used in 3GPP or any other environment; it was just a 
brief acknowledgment that there were some key differences between 
this solution and others, and that interoperability and related 
issues between them are left for future documents.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There are things that are so serious that you can only joke about them
                                                          --Heisenberg

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 5 Aug 2009 17:42:21 -0500

Hi Gabor,

I think you're view of the world is more complicated than it needs to
be. Only one key development has happened. The world has moved from
using circuit switching in a global PSTN to using packet switching in a
global Internet. You may see some details, and interim fluctuations in
service standards as consequence of that transition, but the
fundamentals of operator obligation, regulatory requirements, and
service levels will be the same in the long term.

Mobile network operators are moving from providing cellular PSTN access
to providing cellular Internet access. Wireline operators are moving
from providing fixed PSTN access to providing fixed Internet access.
Both parties can, and will ultimately be required to, provide a reliable
service. I can certainly tell you that, as of now, the Internet access
side of cellular is no more reliable than Wireline Internet access is.

An ECRIT compliant Internet access provider needs to ensure the
following (apart from reliable basic Internet access to begin with of
course):

1.	Access to LIS functionality for routing and dispatch purposes
2.	Access to LoST (either within the network or to a public server)
3.	SIP routability to the PSAP URI(s) in their area of coverage

The elements involved in that can be just as reliable as any
IMS-specific elements that 3GPP define. A LoST server can be just as
reliable as an LRF - and is no more complex. There is always a
dependency on the end device but I'll say this - if all that devices
have to do is provide a consistent reliable ECRIT-compliant client
function then we'll all get something more reliable when that client is
the same regardless of the actual access technology compared to if it
has to be "re-invented" for every flavour of access technology.

Cheers,

Martin

Sent: Thursday, 6 August 2009 4:40 AM

	

	From: ext Dawson, Martin [mailto:[email-masked]] 
	Sent: Tuesday, August 04, 2009 6:37 PM
	To: Bajko Gabor (Nokia-CIC/MtView); [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: ECRIT/IMS - independent discussion from the
PhoneBCP hum

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, 5 August 2009 4:41 AM
	To: Dawson, Martin; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
	Subject: RE: ECRIT/IMS - independent discussion from the
PhoneBCP hum

	  >context.

	This might have been what Brian meant, but it wasn't obvious for
me, especially as circuit switching is not part of 3G (HSPA or LTE),
that is 2G.

	[[MCD]] Exactly - but much has been made of how 3GPP/IMS has
defined ways of providing transparent hand-off between packet service
and circuit service in the context of an emergency call, with the
subsequent inference that this makes ECRIT non-applicable in a 3GPP
access context. That's an incorrect inference and the scenario is
orthogonal to the purpose of ECRIT. Nevertheless, I'm genuinely
interested in the details - i.e. how does IMS state that this is done
(not a description of how it *could* be done by someone but what are the
exact protocols and procedures specified). I'm particularly interested
in how these procedures appear to the end device and the emergency
network.

	  >when a switched circuit call is made Gabor?

	No, I don't say that. But would you claim that a VoIP call made
on a 3G (packet switched) network is not an Internet Service?

	[[MCD]] I do think it's an Internet context in that case - and
that's the case where I have no difficulty seeing that ECRIT is
applicable.

	  >architectural solution can be made arbitrarily reliable.

	Yes, they can. But as we can see, unless it is required by
regulation, reliability is missing. Carriers operating in licenced bands
have to meet certain conditions, while a network operating in an
unlicenced band is free to turn on/off its operation.

	[[MCD]] Legislation imposing reliability and the question of
unlicensed bands are both orthogonal.  

	<Gabor> But reliability and mobility were the main architectural
design choices in 3GPP. That is why they ended up with that complex
architecture! The procedures themselves are a consequence of the
architecture.

	Carriers plan to switch emergency call handling from CS to PS
domain, and they wanted a network controlled ES, they did not want to
rely on the handset doing the whole procedure because of the liability.
Support for emergency calls is not a revenue generator for carriers,
they'd be happy leaving the tasks up to the client if there were no
consequences of emergency calls failing for whatever reason.

	And just to answer James point, ISPs offering broadband internet
service can not be paralelled with carriers operating networks using
3GPP standards. The ISPs do not commit to offer you service with less
than a few minutes outage per year, they provide no mobility and they
are not mandated to support emergency services.

	- gabor

	 ECRIT is applicable to a broadband access regardless of, and
independently constrained by, those considerations. Regulation is a
movable feast - in the US, the Phase 2 regulation was aimed at CMRS
(circuit service) E9-1-1. The FCC is still kicking around the ideas
associated with VoIP. There's no doubt that, from a technical
perspective, IMS is VoIP. The question of how operators choose to
interpret their own obligations wrt IMS is subject to their own risk and
business assessments including how they present that service to their
subscribers. That is, do they regard it as phase 2 cellular or do they
regard it as VoIP? But that's just the US. Any arbitrary jurisdiction
could say that any provider of broadband Internet access to the public
is required to support the ECRIT compliant functions of a LIS, access to
LoST, and a reliable route to the PSAP URI(s) applicable to the
operators' areas of coverage. They could further require specific levels
of reliability/availability and accuracy. They could require it of
municipal WiFi network operators (unlicensed band) just as much as they
could of licensed band wireless operators. They could even require it of
enterprises of a certain size (unlicensed wireless and wired Ethernet).
The point is that the existence of regulatory requirements or otherwise
does not militate against the applicability of ECRIT to specific
technologies.

	[[MCD]] Well - I certainly have reliability problems with GSM
and UMTS coverage in a lot of places... but, again, the reliability of
any given technology does not say anything about the applicability of
ECRIT to that or other technologies.

	;)

	I am by far not an IMS evangelist, nor an ECRIT one, so I'd
rather stay out from these kind of debates.

	What people seem to have trouble understanding is that some
networks (eg the ones operating in licenced bands) can not afford to
rely on the client to do all the procedures needed to place an emergency
call. They need to assist the client and make sure the call ends up in
the right place. They are liable for that. That's the difference.

	[[MCD]] I don't actually understand how you infer that people
involved in this debate don't understand those issues; I don't see the
evidence of that. In any case, all existing licensed mobile networks
absolutely rely on functionality within the device to make emergency
calls; standards have to be supported or the device cannot be used. I'm
also not asking for a position in the debate; I'm asking for elucidation
of how IMS achieves all the things that are claimed for it (exactly)
given the context that ECRIT is argued to be inadequate in comparison.
That detail, so far, has been assumed and not provided as part of the
debate.

	  >associated conveyance of location value/reference in SIP etc.

	Brian sent me off-list a pretty comprehensive list of issues
where the 3GPP procedures differ from the ones defined in ECRIT. Since
that list is by far more complete than the one I could produce, I will
copy paste it below. I hope Brian doesn't mind it:

	" At the moment, the major differences between 3GPP and phonebcp
are:

	b) LoST (3GPP doesn't say LoST can't be used; it basically
leaves this as local practice.  Since in North America, LoST will be
mandated, that's not a difference.  However, 3GPP would say that LoST,
if used, would be queried by the E-CSCF, and not the endpoint, which
differs from -phonebcp

	c) SIP termination: present 3GPP specs make no provision for
packet mode termination.

	To be phonebcp compatible, 3GPP networks would have to implement
one of the -phonebcp LCPs, and provide access to a LoST server.  The
former is a big issue, the latter is a small issue."

	 

	[[MCD]] I'm comfortable that the scope of the document is
restricted to "Internet" - or certainly to IP (internet with a lower
case 'i') networks generally. It's just that others would like to see
some indication that, somehow, it doesn't apply to 3GPP networks - even
though it does.

	- Gabor

	  >  >From: [email-masked]
[mailto:[email-masked]]

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 5 Aug 2009 17:49:26 -0500

Please elaborate on what you mean by "interoperability issues" Randy?
What are they?

Also - the request stands for a more detailed end-to-end description of
the 3GPP emergency call procedure for the benefit of all in this
discussion. Can you provide that?

Cheers,
Martin

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Thursday, 6 August 2009 7:54 AM
To: Dawson, Martin; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the
PhoneBCP hum

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 7 Aug 2009 09:35:46 +0200

Obviously mandates differ between different parts of the world, but certainly any wireless operator (2G or 3G) is currently required by the 3GPP standards, reflecting national regulation, to provide ermegency calling where they provide CS voice service on their networks.

Where IMS is supported, there is also a requirement to support emergency calling on IMS.

For the deployments where an operator is providing LTE in an area not covered by 2G or 3G service, there are indications prior to the network selection to enable determination of whether an emergency call is possible over IMS or not.

What this essentially boils down to is that if you have an contract with a 3G operator to give you voice service, then emergency calls will work on that phone, because the network operator is required to support it. That applies whether there is an internet browser on the phone or not.

As far as I know there is currently no mandate on any ISP or indeed internet VOIP provider to support emergency calls. That may come in the future, but so far I have seen no evidence of it.

So writing a document that claims that some other mechanism is the way to offer emergency calls, and then shouting from the rooftops that this applies to mobile phones, is more likely to result in deaths than not.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Linsner
Sent: Wednesday, August 05, 2009 8:30 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum

Gabor,

- gabor

[Marc] Are you implying that 3GPP carriers operating a packet voice service have a different mandate for supporting emergency services than an OTT provider that sells packet voice services?  (my understanding, which could be wrong, is that VoIP is VoIP no matter who is the SP)

Or is this a 3GPP self-inflicted mandate that is trying to emulate 2G circuit-switched services?

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 7 Aug 2009 03:08:53 -0500

Thanks Keith,

WRT:

Where IMS is supported, there is also a requirement to support emergency
calling on IMS.

Can you elaborate please? Where is this requirement applicable and by
what legislation/docket? I'm assuming you'd agree that IMS is in fact
VoIP - but I probably shouldn't.

Cheers,

Martin

From: [email-masked] [mailto:[email-masked]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Friday, 7 August 2009 5:36 PM
To: Marc Linsner; [email-masked]; [email-masked]
Subject: Re: [Ecrit] ECRIT/IMS - independent discussion from the
PhoneBCP hum

Obviously mandates differ between different parts of the world, but
certainly any wireless operator (2G or 3G) is currently required by the
3GPP standards, reflecting national regulation, to provide ermegency
calling where they provide CS voice service on their networks.

Where IMS is supported, there is also a requirement to support emergency
calling on IMS.

For the deployments where an operator is providing LTE in an area not
covered by 2G or 3G service, there are indications prior to the network
selection to enable determination of whether an emergency call is
possible over IMS or not.

What this essentially boils down to is that if you have an contract with
a 3G operator to give you voice service, then emergency calls will work
on that phone, because the network operator is required to support it.
That applies whether there is an internet browser on the phone or not.

As far as I know there is currently no mandate on any ISP or indeed
internet VOIP provider to support emergency calls. That may come in the
future, but so far I have seen no evidence of it. 

So writing a document that claims that some other mechanism is the way
to offer emergency calls, and then shouting from the rooftops that this
applies to mobile phones, is more likely to result in deaths than not. 

regards

Keith

	Gabor,

			<Gabor> But reliability and mobility were  the
main architectural design choices in 3GPP. That is why they ended up
with that complex architecture! The procedures themselves are a
consequence  of the architecture.
			
			Carriers plan to switch emergency call handling
from CS to PS domain, and they wanted a network controlled ES, they did
not  want to rely on the handset doing the whole procedure because of
the  liability. Support for emergency calls is not a revenue generator
for carriers, they'd be happy leaving the tasks up to the client if
there were no consequences of emergency calls failing for whatever
reason.
			
			And just to answer James point, ISPs offering
broadband internet service can not be paralelled with carriers operating
networks using 3GPP standards. The ISPs do not commit to offer you
service  with less than a few minutes outage per year, they provide no
mobility and  they are not mandated to support emergency  services.

			- gabor

			[Marc] Are you implying that 3GPP carriers
operating a packet voice service have a different mandate for supporting
emergency services than an OTT provider that sells packet voice
services?  (my understanding, which could be wrong, is that VoIP is VoIP
no matter who is the SP)
			
			Or is this a 3GPP self-inflicted mandate that is
trying to emulate 2G circuit-switched services?

			-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Fri, 07 Aug 2009 09:01:40 -0400

Keith,

On 8/7/09 3:35 AM, "DRAGE, Keith (Keith)" <[email-masked]> wrote:

> Obviously mandates differ between different parts of the world, but certainly
> any wireless operator (2G or 3G) is currently required by the 3GPP standards,
> reflecting national regulation, to provide ermegency calling where they
> provide CS voice service on their networks.
>  
> For the deployments where an operator is providing LTE in an area not covered
> by 2G or 3G service, there are indications prior to the network selection to
> enable determination of whether an emergency call is possible over IMS or not.
>  
> What this essentially boils down to is that if you have an contract with a 3G
> operator to give you voice service, then emergency calls will work on that
> phone, because the network operator is required to support it. That applies
> whether there is an internet browser on the phone or not.
> 
> [Marc] I agree if the voice service is circuit-switched.
>  
> As far as I know there is currently no mandate on any ISP or indeed internet
> VOIP provider to support emergency calls. That may come in the future, but so
> far I have seen no evidence of it.
> 
> [Marc] In 2005 in the US, the FCC imposed 911 obligations on VoIP providers
> that interconnect with the PSTN.
> (http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-258818A1.pdf)
> 
> What is not clear to me is whether the owner of the RF license that sells
> VoIP-only (IMS  no CS) has more regulatory obligation wrt 911 than an OTT
> VoIP provider.  Hence, my questioning whether these mandates are
> self-inflicted.
>  
> So writing a document that claims that some other mechanism is the way to
> offer emergency calls, and then shouting from the rooftops that this applies
> to mobile phones, is more likely to result in deaths than not.
> 
> [Marc] I don¹t believe anyone claims that the ECRIT architecture is a better
> technical solution for emergency calling than any of the legacy (CS)
> solutions.  But it is certain that legacy solutions for emergency calling
> CANNOT work on the Internet (which, btw, is where the IETF is focused).  The
> ECRIT solution is targeted at the Internet and CAN work on private IP
> networks.  If the owner/operator of a private IP network doesn¹t care about
> global universal support, then they can utilize whatever solution they wish.
> The market will decide in the end.
> 
> -Marc-
>  
>  
>  
> regards
>  
> Keith
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 10 Aug 2009 13:40:55 +0200

Who knows what regulation.

But the standard goes straight to a normative requirement to process a request as an emergency call and route to an E-CSCF without any other option when an emergency call is detected, so conformance to something claiming to be IMS is impossible without it.

As for VOIP, the UE requirements require an INVITE with voice as the only type of emergency call generated. The network processes all requests, e.g. INVITE, MESSAGE, or whatever, as an emergency call if so recognised. It is up to the PSAP to reject the ones it cannot handle (or the MGCF if the PSAP is CS connected).

regards

Keith

________________________________
From: Dawson, Martin [mailto:[email-masked]]
Sent: Friday, August 07, 2009 9:09 AM
To: DRAGE, Keith (Keith); Marc Linsner; [email-masked]; [email-masked]
Subject: RE: [Ecrit] ECRIT/IMS - independent discussion from the PhoneBCP hum

Thanks Keith,

WRT:

Can you elaborate please? Where is this requirement applicable and by what legislation/docket? I’m assuming you’d agree that IMS is in fact VoIP – but I probably shouldn’t.

Cheers,
Martin
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)

regards

Keith

- gabor

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 10 Aug 2009 09:49:33 -0500

Thanks Keith,

You didn't mean *statutory* requirement then - so it's somewhat
different; there are no protocol police.

Can you point me to the normative requirement that says IMS
implementations must support the emergency procedures and E-CSCF? Which
specification is that in?

Cheers,

Martin

From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Monday, 10 August 2009 9:41 PM
To: Dawson, Martin; Marc Linsner; [email-masked]; [email-masked]
Subject: RE: [Ecrit] ECRIT/IMS - independent discussion from the
PhoneBCP hum

But the standard goes straight to a normative requirement to process a
request as an emergency call and route to an E-CSCF without any other
option when an emergency call is detected, so conformance to something
claiming to be IMS is impossible without it.

As for VOIP, the UE requirements require an INVITE with voice as the
only type of emergency call generated. The network processes all
requests, e.g. INVITE, MESSAGE, or whatever, as an emergency call if so
recognised. It is up to the PSAP to reject the ones it cannot handle (or
the MGCF if the PSAP is CS connected).

regards

Keith

	From: Dawson, Martin [mailto:[email-masked]] 
	Sent: Friday, August 07, 2009 9:09 AM
	To: DRAGE, Keith (Keith); Marc Linsner; [email-masked];
[email-masked]
	Subject: RE: [Ecrit] ECRIT/IMS - independent discussion from the
PhoneBCP hum

	Thanks Keith,

	WRT:

	Where IMS is supported, there is also a requirement to support
emergency calling on IMS.

	Can you elaborate please? Where is this requirement applicable
and by what legislation/docket? I'm assuming you'd agree that IMS is in
fact VoIP - but I probably shouldn't.

	Cheers,

	Martin

	Obviously mandates differ between different parts of the world,
but certainly any wireless operator (2G or 3G) is currently required by
the 3GPP standards, reflecting national regulation, to provide ermegency
calling where they provide CS voice service on their networks.

	Where IMS is supported, there is also a requirement to support
emergency calling on IMS.

	For the deployments where an operator is providing LTE in an
area not covered by 2G or 3G service, there are indications prior to the
network selection to enable determination of whether an emergency call
is possible over IMS or not.

	What this essentially boils down to is that if you have an
contract with a 3G operator to give you voice service, then emergency
calls will work on that phone, because the network operator is required
to support it. That applies whether there is an internet browser on the
phone or not.

	As far as I know there is currently no mandate on any ISP or
indeed internet VOIP provider to support emergency calls. That may come
in the future, but so far I have seen no evidence of it. 

	So writing a document that claims that some other mechanism is
the way to offer emergency calls, and then shouting from the rooftops
that this applies to mobile phones, is more likely to result in deaths
than not. 

	regards

	Keith

		Subject: Re: [Ecrit] ECRIT/IMS - independent discussion
from the PhoneBCP hum

		Gabor,

				<Gabor> But reliability and mobility
were  the main architectural design choices in 3GPP. That is why they
ended up  with that complex architecture! The procedures themselves are
a consequence  of the architecture.
				
				Carriers plan to switch emergency call
handling  from CS to PS domain, and they wanted a network controlled ES,
they did not  want to rely on the handset doing the whole procedure
because of the  liability. Support for emergency calls is not a revenue
generator  for carriers, they'd be happy leaving the tasks up to the
client if  there were no consequences of emergency calls failing for
whatever  reason.
				
				And just to answer James point, ISPs
offering  broadband internet service can not be paralelled with carriers
operating  networks using 3GPP standards. The ISPs do not commit to
offer you service  with less than a few minutes outage per year, they
provide no mobility and  they are not mandated to support emergency
services.

				- gabor

				[Marc] Are you implying that 3GPP
carriers operating a packet voice service have a different mandate for
supporting emergency services than an OTT provider that sells packet
voice services?  (my understanding, which could be wrong, is that VoIP
is VoIP no matter who is the SP)
				
				Or is this a 3GPP self-inflicted mandate
that is trying to emulate 2G circuit-switched services?

				-Marc-

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]