Subject: [Ecrit] Nomadic VOIP is dead

From: John Lange <[email-masked]>
Date: Fri, 20 Nov 2009 14:34:06 -0600

Just thought the readers of this list would be interested in some
developments here in Canada.

Faced with the prospect of spending millions to implement a IP location
system in support of the proposed Canadian i2 enhanced 911 for VOIP
solution, a consortium of Canadian cable providers (Rogers, Shaw,
Cogeco, and Videotron) commissioned a report to assess the true need for
such a system.

The result, in a nutshell is that nomadic VOIP is almost non-existent.

The report contends that there there are 250,000 VOIP customers
(0.00677% of the population) and of those, only 10,000 regularly move
with their devices. 

This agrees with statistics gathered from New York which indicate only
0.0064% of calls to 911 come from nomadic VOIP customers.

Given the above statistics, the current estimated cost of implementing
Ci2 is between $20,000 - $30,000 per user.

You can view the entire submission (the actual report was not released)
as well as my comments on my blog:

http://www.johnlange.ca/2009/11/06/residential-voip-is-dead/

Regards,

-- 
John Lange
http://www.johnlange.ca

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Nov 2009 15:52:46 -0500

Not too surprising.

Do consider that there are some reasons why you might think this will
change.  Extensive use of WiFi handsets for example.  Still, it's probably
more than a couple of years before the numbers would get big enough to
matter.

I'd also point out that for "next generation" emergency "call", things like
instant messaging is almost entirely nomadic.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Nov 2009 16:06:06 -0500

I didn't know Canada had 3.6 billion inhabitants, let alone families. Do moose get VoIP, too?

Henning

---

From: Marc Linsner <[email-masked]>
Date: Fri, 20 Nov 2009 16:36:02 -0500

Apparently user supplied location will be the norm for 'wired' devices.

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Nov 2009 17:11:14 -0500

John,

A few comments on a quick read of this submission:

The most relevant finding of the study is that there are 250,000  
"Nomadic VoIP" subscribers (a figure that itself seems dubious, given  
at the 800,000 Canadians using softphones are also nomadic and also  
using VoIP).  Any one of those subscribers has the technical  
capability to move their VoIP endpoint to another place.  If the CRTC  
is to adopt a solution that depends on those users staying in one  
place (such as user-supplied location), then they are increasing the  
risk, for all quarter-million of these users, that their calls will  
fail.  There's simply no way to ensure that these users will not move  
their phones.

This dramatically changes the cost analysis: The denominator in the  
"cost per user" fraction should be "number of users who benefit from  
Ci2".  This standard would clearly include all 250,000 nomadic users,  
who benefit from the increased robustness (decreased risk) of their  
emergency calls.  If you include them, the cost per user drops to  
$800-1200.  If you also include the 800,000 softphone users (since  
there's no real technical difference between a nomadic user's ATA and  
a softphone on an iPod), the cost drops to less than $200 per user.   
So in this dimension, at least, the submission is off by at least two  
orders of magnitude.

Finally the figure that "0.0064% of calls to 911 come from nomadic  
VOIP customers" is completely irrelevant to this debate, since most  
nomadic VoIP users (e.g., Skype users) have no way to get their 9-1-1  
calls to a PSAP in the first place!

--Richard

On Nov 20, 2009, at 3:34 PM, John Lange wrote:

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

---

From: John Lange <[email-masked]>
Date: Fri, 20 Nov 2009 16:49:27 -0600

>From my perspective the critical point of the submission is that VOIP is
declining, not growing.

Even accepting your point that potentially 250,000 users _could_
benefit, the investment would return less and less value as the number
of subscribers declines.

And given that Ci2 does not support services such as Skype, it fails to
service what is by far the largest, and still growing segment of the
nomadic VOIP landscape.

To be clear, I support the goal of IP location determination for the
purpose of providing enhanced 911 services to nomadic VOIP users. I just
don't support the proposed Ci2 because, to a large extent, it does not
meet that goal.

Until the IETF gets all of the relevant standards in place and vendors
start making products compatible with those standards, it's likely still
too expensive and too early for implementation.

-- 
John Lange
http://www.johnlange.ca

---

From: "Francois D. Menard" <[email-masked]>
Date: Fri, 20 Nov 2009 22:34:53 -0500

The report says:

This translates into approximately 250,000 households – or slightly less than 2% of all households when taking into account the fact approx 76% of households subscribe to a high speed Internet service – that are currently access-independent VoIP service subscribers.

F.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 20 Nov 2009 21:53:22 -0800

It is not all that surprising to me that a survey done of cable customers
utilizing the wired fixed VOIP services offered by those providers would
conclude that those VOIP users are not very mobile. 

Today broadband wireless is still in its infancy, smartphones still
represent 
less than 15 percent of all cellular handsets and providers of fixed
broadband services are only just beginning to bundle in access to wireless
services such as WLAN hotspots.  As a result, the vast majority of today's
mobile telephony users find themselves attached to cellular networks. 

However, in 5 years, the situation might look quite different and therefore
a survey of today's usage patterns does not enable us to conclude that the
future will always look like the present, or even that the transition
between 
today's usage patterns and tomorrow's will be gradual enough to enable us to

plan the transition at our leisure. 

The nature of technological change is that things move at blinding speed
once the "tipping point" is reached.  Today, SMS is ubiquitous and therefore
the demand for (and mis-informed use of) texting to 911 has become a problem
for which we have no easily deployable solutions.  This would have seemed 
quite unlikely 5 years ago. 

Thus while mobile VOIP technologies such as Voice over WLAN appear to be an
overhyped bust with only a fraction of the market share of DECT (to pick
just a single competitor), other technologies such as White Space could
easily
change the equation over the next decade. 

In the words of Monty Python, "nomadic VOIP's not dead -- he's only
sleeping!"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Lange
Sent: Friday, November 20, 2009 12:34 PM
To: ecrit
Subject: [Ecrit] Nomadic VOIP is dead

Regards,

-- 
John Lange
http://www.johnlange.ca

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 21 Nov 2009 14:07:55 +0800

Yes. If anyone can be bothered doing the research, they'll find similar reports from the late 80's and early 90's concluding that mobile telephony will never be a mass market technology. Too expensive, low market penetration based on current stats blah blah. It's a failure to recognize what Peter Drucker calls "the future that's already happened". It's a common syndrome.

These are not the sort of people I want between me and the nearest PSAP. Roll on ECRIT direct!

Cheers,
Martin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bernard Aboba [[email-masked]]
Sent: 20 November 2009 23:53
To: 'John Lange'; 'ecrit'
Subject: Re: [Ecrit] Nomadic VOIP is dead

-----Original Message-----

Regards,

--
John Lange
http://www.johnlange.ca

---

From: Richard Barnes <[email-masked]>
Date: Sat, 21 Nov 2009 17:16:58 -0500

>> From my perspective the critical point of the submission is that  

I hope you mean that "*Nomadic* VoIP is declining", and even then  
"Nomadic" understood in some peculiar sense that excludes soft- 
phones.  (I'm not familiar with CRTC's specific definition, but  
whatever it is, it seems awkward from a technical perspective.)

> service what is by far the largest, and still growing segment of the

That seems to me to argue for fixing the current incarnation of Ci2  
rather than doing nothing.

On the other hand, as I understand it, the major barrier to support  
for VSPs like Skype is the establishment of trust relationships with  
them.  In which case, it should be straightforward to extend Ci2 to  
support a limited number of these VSPs.  As the report notes, simply  
bringing Skype into the fold would cover more than 90% of users, or  
around 720,000 subscribers.

> don't support the proposed Ci2 because, to a large extent, it does not

I certainly agree that there are better ways of doing it than current  
Ci2 -- mainly, just deploying the GEOPRIV Location Configuration  
Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful  
than the report seems to imply.

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 22 Nov 2009 06:37:53 +0800

I have stayed largely out of this discussion to this point.
Ci2 had very specific criteria that simply following base ECRIT could not meet, namely the location dependability criteria. I, and a number of others, have been saying in the IETF since before ECRIT came about that a lack of location dependability was a series impediment to uptake. I have subsequently visited and talked to quite a number of regulators around the world and as things currently stand they will not allow an architecture that does not have a solution to the location dependability problem. Ci2 addresses this problem by using HELD identity extensions and a trusted third-party query, though the solution also addresses quite a number of other barriers to deployment of a base-NENA i2 solution.

Automatic location from the network is required to support all of the architectures that I have seen, and it is this component of the Ci2 solution that is deemed to be the most expensive to implement. So unless people are professing a solution of "only user provided location" then it seems that going Ci2 or some other architecture saves little to nothing. My understanding is that there is a strict requirement from the CRTC that says that the Ci2 solution must not require user-provided location, so it seems to me that location-enabling the network is not optional, it is mandatory.

As far as I understand it, most of the people complaining about Ci2 are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. This removes the VSPs from the equation when it comes to making an emergency call, so this should alleviate most of your concerns John.

Cheers
James

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Richard Barnes [[email-masked]]
Sent: Saturday, November 21, 2009 4:16 PM
To: John Lange
Cc: ecrit
Subject: Re: [Ecrit] Nomadic VOIP is dead

declining, not growing.

I hope you mean that "*Nomadic* VoIP is declining", and even then "Nomadic" understood in some peculiar sense that excludes soft-phones.  (I'm not familiar with CRTC's specific definition, but whatever it is, it seems awkward from a technical perspective.)

That seems to me to argue for fixing the current incarnation of Ci2 rather than doing nothing.

On the other hand, as I understand it, the major barrier to support for VSPs like Skype is the establishment of trust relationships with them.  In which case, it should be straightforward to extend Ci2 to support a limited number of these VSPs.  As the report notes, simply bringing Skype into the fold would cover more than 90% of users, or around 720,000 subscribers.

I certainly agree that there are better ways of doing it than current Ci2 -- mainly, just deploying the GEOPRIV Location Configuration Protocols (LCPs) -- but at the same time, Ci2 is more broadly useful than the report seems to imply.

--Richard

---

From: "Francois D. Menard" <[email-masked]>
Date: Sat, 21 Nov 2009 23:44:16 -0500

Actually, ISPs also fear this quite a lot, as there is no standard for LIS to LIS communications at this time.

Reduced Ci2 was proposed.  The document should be posted to the CRTC web site on monday and I will circulate.

At this time, many of you got it via private correspondance.

We think that wholesale DSL and wholesale cable should enable ISPs to implement their own LISes without being forced to interface with the ILEC LIS in the live emergency call path.

Location aware devices should become available prior to Ci2 being available.

The problem is Ci2 DENIES use of location aware devices.

ILECs need to be told to enable SIP LOCATION CONVEYANCE on their servers.... and forego all of this nonsense to use the public IP address as the key to look for a LIS in an ARIN IP address block... its not going to work.

F.

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 22 Nov 2009 12:52:28 +0800

Again Francois, you fail to address the key requirement that there is NO LOCATION DEPENDABILIY offerred by location provided by end-points, this includes location that traverses end-points. There is far more of a standard for LIS to LIS communication, including the NENA TRD (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than there is any form location dependability.

So, having a location enabled or capable end-point without a standard for location dependability is unlikely to meet any degree of acceptability. Again ECRIT Direct goes a long way towards addressing these requirements.

Cheers
James

________________________________________
From: Francois D. Menard [[email-masked]]
Sent: Saturday, November 21, 2009 10:44 PM
To: Winterbottom, James
Cc: Richard Barnes; John Lange; ecrit
Subject: Re: [Ecrit] Nomadic VOIP is dead

F.

---

From: "Francois D. Menard" <[email-masked]>
Date: Sun, 22 Nov 2009 00:55:34 -0500

Error.

Reduced Ci2 as proposed is all about LOCATION DEPENDABILITY

For cable: We speak of Reverse DNS in realtime fashion for cable - a Cable MODEM MAC address is a CIVIC address.

For DSL: We speak of PPPoE intermediate agents showing unique Layer 2 identifiers which ISPs will know that they can bind to CIVIC addresses.

There is no end-user inputted location in our proposed Reduced Ci2 architecture.

F.

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 22 Nov 2009 15:14:05 +0800

May be I am missing something, but your previous email was suggesting that Ci2 precluded location aware devices, and I think all I did was to to state why. Are you aware of a location dependability standard that for device provided location?

Cheers
James

Sent: Saturday, November 21, 2009 11:55 PM

Error.

F.

---

From: "Francois D. Menard" <[email-masked]>
Date: Sun, 22 Nov 2009 07:59:34 -0500

The combination of SIPCORE LOCATION CONVEYANCE with DHCP OPTION 99/123 from an ISP owned LIS, pushing PIDF-LO's from unique identifiers acquired from ILEC through PPPoE intermediate agents pushing data over the NNI between ILEC and ISP over RADIUS, into a RADIUS database interfaced to an DHCP OPTION 99/123 server will work!!!

f.

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Nov 2009 06:07:10 +0800

Hi Francois,

Let me read your proposal, but anything that requires changes to CPE is already unable to satisfy the CRTC requirements as I understand them.

Cheers
James

> From: Francois D. Menard [mailto:[email-masked]]
> Sent: Monday, 23 November 2009 12:00 AM
> To: Winterbottom, James
> Cc: ecrit
> The combination of SIPCORE LOCATION CONVEYANCE with DHCP OPTION 99/123
> from an ISP owned LIS, pushing PIDF-LO's from unique identifiers acquired
> from ILEC through PPPoE intermediate agents pushing data over the NNI
> between ILEC and ISP over RADIUS, into a RADIUS database interfaced to an
> DHCP OPTION 99/123 server will work!!!
> 
> f.
> 
> > May be I am missing something, but your previous email was suggesting
> that Ci2 precluded location aware devices, and I think all I did was to to
> state why. Are you aware of a location dependability standard that for
> device provided location?
> >
> > Cheers
> > James
> >
> >
> >
> > For cable: We speak of Reverse DNS in realtime fashion for cable - a
> Cable MODEM MAC address is a CIVIC address.
> >
> > For DSL: We speak of PPPoE intermediate agents showing unique Layer 2
> identifiers which ISPs will know that they can bind to CIVIC addresses.
> >
> >> Again Francois, you fail to address the key requirement that there is
> NO LOCATION DEPENDABILIY offerred by location provided by end-points, this
> includes location that traverses end-points. There is far more of a
> standard for LIS to LIS communication, including the NENA TRD
> (http://www.nena.org/sites/default/files/08-505_20061221.pdf) than there
> is any form location dependability.
> >>
> >> So, having a location enabled or capable end-point without a standard
> for location dependability is unlikely to meet any degree of
> acceptability. Again ECRIT Direct goes a long way towards addressing these
> requirements.
> >>
> >> Cheers
> >> James
> >>
> >> We think that wholesale DSL and wholesale cable should enable ISPs to
> implement their own LISes without being forced to interface with the ILEC
> LIS in the live emergency call path.
> >>
> >> ILECs need to be told to enable SIP LOCATION CONVEYANCE on their
> servers.... and forego all of this nonsense to use the public IP address
> as the key to look for a LIS in an ARIN IP address block... its not going
> to work.
> >>
> >> F.
> >>
> >>
> >>> Ci2 had very specific criteria that simply following base ECRIT could
> not meet, namely the location dependability criteria. I, and a number of
> others, have been saying in the IETF since before ECRIT came about that a
> lack of location dependability was a series impediment to uptake. I have
> subsequently visited and talked to quite a number of regulators around the
> world and as things currently stand they will not allow an architecture
> that does not have a solution to the location dependability problem. Ci2
> addresses this problem by using HELD identity extensions and a trusted
> third-party query, though the solution also addresses quite a number of
> other barriers to deployment of a base-NENA i2 solution.
> >>>
> >>> Automatic location from the network is required to support all of the
> architectures that I have seen, and it is this component of the Ci2
> solution that is deemed to be the most expensive to implement. So unless
> people are professing a solution of "only user provided location" then it
> seems that going Ci2 or some other architecture saves little to nothing.
> My understanding is that there is a strict requirement from the CRTC that
> says that the Ci2 solution must not require user-provided location, so it
> seems to me that location-enabling the network is not optional, it is
> mandatory.
> >>>
> >>> As far as I understand it, most of the people complaining about Ci2
> are VoIP providers, Ci2 morphs quite easily to support ECRIT Direct. This
> removes the VSPs from the equation when it comes to making an emergency
> call, so this should alleviate most of your concerns John.
> >>>
> >>> Cheers
> >>> James
> >>>
> >>>
> >>>
> >>>
> "Nomadic" understood in some peculiar sense that excludes soft-phones.
> (I'm not familiar with CRTC's specific definition, but whatever it is, it
> seems awkward from a technical perspective.)
> >>>
> for VSPs like Skype is the establishment of trust relationships with them.
> In which case, it should be straightforward to extend Ci2 to support a
> limited number of these VSPs.  As the report notes, simply bringing Skype
> into the fold would cover more than 90% of users, or around 720,000
> subscribers.
> >>>
> >>>
> Ci2 -- mainly, just deploying the GEOPRIV Location Configuration Protocols
> (LCPs) -- but at the same time, Ci2 is more broadly useful than the report
> seems to imply.
> >>>
> >>> --Richard

---

From: "Francois D. Menard" <[email-masked]>
Date: Sun, 22 Nov 2009 20:01:36 -0500

Can Canadians see $300M+ invested on an infrastructure tracking public IP addresses for 10,000 VoIP end-points that can be upgraded to become location aware faster than Ci2 will be implemented ?

The CRTC did never require that the chosen solution not require a change into CPEs. That's the sales pitch of the ILECs.

The way I see this, we could get away with spending $2M and get the problem fixed.

Or get stuck in court review for 5 years, on the promise of something nobody can afford to implement.

F.

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Nov 2009 09:08:19 +0800

Let me try again.
Regardless of how you deliver the location, the expensive part will be in setting up the systems to determine it in the first place. You will need to this no matter what system you put in place. So it is very very unclear to me where you see this magical cost saving coming from. 

I am also still quite confused over how providing a location to an end-point over DHCP solves the location veracity problem that I described previously. Perhaps you can explain in a little more detail what assurance the PSAP has that this location is actually attributable to the calling entity.

Cheers
James

> Sent: Monday, 23 November 2009 12:02 PM
> To: Winterbottom, James
> Cc: ecrit
> Can Canadians see $300M+ invested on an infrastructure tracking public IP
> addresses for 10,000 VoIP end-points that can be upgraded to become
> location aware faster than Ci2 will be implemented ?
> 
> The CRTC did never require that the chosen solution not require a change
> into CPEs. That's the sales pitch of the ILECs.
> 
> > Let me read your proposal, but anything that requires changes to CPE is
> already unable to satisfy the CRTC requirements as I understand them.
> >
> > Cheers
> > James
> >
> >
> >>>> Actually, ISPs also fear this quite a lot, as there is no standard
> for
> >> LIS to LIS communications at this time.
> >>>>
> >>>>> From my perspective the critical point of the submission is that
> VOIP
> >> is
> >>>>> declining, not growing.
> >>>>>
> them.
> Protocols

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 22 Nov 2009 17:14:11 -0800

Keep in mind that the 10,000 consumer endpoints doesn't include enterprise VOIP users.  Therefore even if the consumer problem could be solved by giving each of the 10,000 users a free cell phone that can make emergency calls even if there are no funds associated with the SIM, there will still be multi-line PBXes for whom transmission of location information would represent an important advance.  For a while now, NENA has been advocating legislation requiring enterprise customers to provide a solution to that problem, to which the ECRIT architecture is relevant. 

> From: [email-masked]
> Date: Sun, 22 Nov 2009 20:01:36 -0500
> To: [email-masked]
> CC: [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 22 Nov 2009 17:16:02 -0800

Yes, I'm missing that part as well.  If the location information is obtained via RADIUS and placed in a database, then that database can be made equally accessible for use with any LCP, including HELD.

---

From: "Francois D. Menard" <[email-masked]>
Date: Sun, 22 Nov 2009 22:58:03 -0500

Canada's Ci2 has not been designed to solve the enterprise PBX problem.

That requires a special assembly tariff where you register DIDs to a CIVIC address and you make sure you call 9-1-1 with that DID if you want dispatch to the right place.

ILEC made a point to ignore enterprise applications, or VoIP not on the public Internet with public IPs.

This is not a SIP-based interconnection to a PSAP gateway run by ILECs... its an Internet-based interconnection only meant to work with Internet Public IP addresses.

This is why SIPCORE LOC CONVEYANCE is the way to go.. then the IP address is irrelevant.

f.

---

From: "Francois D. Menard" <[email-masked]>
Date: Sun, 22 Nov 2009 23:07:35 -0500

> Regardless of how you deliver the location, the expensive part will be in setting up the systems to determine it in the first place. You will need to this no matter what system you put in place. So…

I am not sure you actually 'DETERMINE' a location.  Its more like you 'REGISTER A BINDING OF A UNIQUE IDENTIFIER WITH CIVIC'

In the case of wholesale cable modem, this is the MAC address of the cable modem.  The cable modem is expected not to move.

The only approved system for reporting cable modem MAC addresses is a Reverse DNS zone transfer (private DNS) as per CRTC Decision 2007-1:

http://www.crtc.gc.ca/eng/archive/2007/dt2007-1.htm

We just need it realtime.

For DSL wholesale, if its IP DSLAMs, DSL modems have MAC addresses and its the same deal.

For DSL wholesale, for ATM DSLAMs, then its PPPoE intermediate agent tags shipped over RADIUS accounting to the ISP.

The ISP will register the 'unique identifier' with the PPPoE logon, and populate its LIS with it.

I do not think that the LIS will be all that expensive in that case... its a matter of putting a database which links FreeRadius to ISC DHCPD ... all opensource stuff.

We just need layer 2 identifiers which are guaranteed to be unique when we are 'firehosed' with wholesale traffic.... we want to make sure that there is something unique for every water droplets stream in the big bundle of water hitting the ISP.

Hopefully you see where the cost saving is coming from. Open Source. No HELD. No BEEP. No Bell Canada patents.  (Did Bell Canada report to the IETF its intellectual property in GEOPRIV ?).

> I am also still quite confused over how providing a location to an end-point over DHCP solves the location veracity problem that I described previously. Perhaps you can explain in a little more det…

The PSAP in Canada sees diddly squat in Ci2.  The ILEC does it on its behalf.  The ILEC has contractual relationships with ISPs which shield PSAPs from any requirement to engage into veracity assessment. Please indicate when and where PSAPs actually engage into such an undertaking in the context of Ci2 and how this differs with ECRIT.

-=Francois=-

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Nov 2009 12:45:57 +0800

> The PSAP in Canada sees diddly squat in Ci2.  The ILEC does it on its
> behalf.  The ILEC has contractual relationships with ISPs which shield
> PSAPs from any requirement to engage into veracity assessment. Please
> indicate when and where PSAPs actually engage into such an undertaking in
> the context of Ci2 and how this differs with ECRIT.
> 
> -=Francois=-

I think you are seriously misrepresenting the picture here, in particular just where the trust relationship comes into play.

If I understand your approach, you will provide location directly to an end-point over DHCP, have the Target constructs a PIDF-LO and send this information off to its VSP (no checking), then have the VPS direct this to the stage-1 routing proxy, because the location has been provided by the end-point you have the stage-1 routing proxy route the cal to the PSAP. Again no checking. This mean that the caller could quite literally be anywhere on Earth, but says he is in Toronto and the system will believe. Where is the veracity provided in your solution because I can't see it.

Canadian i2, says, VSP will send 911 call to the stage-1 routing proxy. Stage-1 routing proxy is only accessible by registered VSPs. Stage-1 routing proxy uses IP address of the call to make a TRUSTED third-party request to the LIS for the caller's location. The routing proxy then includes the location in-band to the PSAP or whatever exists between the routing proxy and the PSAP. The trust in this case comes from the fact that there are only 5 stage-1 routing proxies and they are run by the existing 911 service providers. Further more the call needs to have originated from a local ISP or the third-party request will fail. Veracity not perfect, but certainly better than the other proposal.

Cheers
James

---

From: "Francois D. Menard" <[email-masked]>
Date: Mon, 23 Nov 2009 00:01:38 -0500

> If I understand your approach, you will provide location directly to an end-point over DHCP, have the Target constructs a PIDF-LO and send this information off to its VSP (no checking),

This means what you are saying is that end-points cannot be trusted to report their locations?

Is this a stated assumption in ECRIT that the end-points cannot be trusted?

You are saying that OBO should aways be mandatory?

You are saying that veracity needs to be assessed while a 9-1-1 call is being established?

> then have the VPS direct this to the stage-1 routing proxy, because the location has been provided by the end-point you have the stage-1 routing proxy route the cal to the PSAP. Again no checking. This mean that the caller could quite literally be anywhere on Earth, but says he is in Toronto and the system will believe.

If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he is elsewhere on Earth, he will get a DHCP 99/123 with that information.

How can he be elsewhere on earth and get  DHCP 99/123 from Toronto?  Because he cached it?

> Where is the veracity provided in your solution because I can't see it.

We are getting in the wild wet slide of 9-1-1 requires OBO...
> 
> Canadian i2, says, VSP will send 911 call to the stage-1 routing proxy. Stage-1 routing proxy is only accessible by registered VSPs. Stage-1 routing proxy uses IP address of the call to make a TRUSTED third-party request to the LIS for the caller's location

Error here... the IP address is the key.  Will not work in many scenarios.  This also requires that IP address be tied to a CIVIC in what is called the ILEC HOSTED LIS.  This means that we have to constantly upload the public IP addresses of all canadians just in case they call 9-1-1. This is a big privacy problem.

> . The routing proxy then includes the location in-band to the PSAP or whatever exists between the routing proxy and the PSAP.

ok

> The trust in this case comes from the fact that there are only 5 stage-1 routing proxies and they are run by the existing 911 service providers.

Do I trust the ILEC with the IP addresses of all my customers?

> Further more the call needs to have originated from a local ISP or the third-party request will fail.

Why ?

> Veracity not perfect, but certainly better than the other proposal.
> 

How about adding digital signatures to DHCP 99/123 constructs that can flow through from the PSAP MSAG to the end-points and can get sent-back to the PSAP for authentication assessments?  I am thinking of MIME digital signatures of PIDF-LO constructs that can be stored in the memory of end-points and can be sent back to the PSAP via the relationship between the ILEC and the PSAP.

And there will be no need that the ILEC provides a Hosted LIS and knows the identity of customers on the Internet that may never call 9-1-1 in their life.

This is way too much of a big brother database than what is the least acceptable.

It will be fought in court.

We need to re-state the concept of ECRIT as not requiring OBO... but trust between PSAPs and End-points.

That requires digital signatures of PIDF-LOs.

I've been saying so for the last couple of months to many people on the ECRIT list.  I think its time I do a real IETF draft on this.

Any people think its a bad idea?

-=Francois=-

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Nov 2009 13:41:52 +0800

Inline.

> Sent: Monday, 23 November 2009 4:02 PM

> > If I understand your approach, you will provide location directly to an

> end-point over DHCP, have the Target constructs a PIDF-LO and send this

> information off to its VSP (no checking),

> This means what you are saying is that end-points cannot be trusted to

> report their locations?

> Is this a stated assumption in ECRIT that the end-points cannot be

> trusted?

> You are saying that OBO should aways be mandatory?

[AJW] I am saying that I have spoken to quite a number (more than 4) regulators around the world and they will not trust location coming from end-points that cannot be verified by some other means. Martin Thomson, I and a few others have been trying to get a means for having literal location bound to a specific end-point but so far this has gotten little traction. So yes, I am saying that the only option right now is a trusted third-party request.

> You are saying that veracity needs to be assessed while a 9-1-1 call is

> being established?

[AJW] Trusted third-party also eliminates the need to do a veracity check at call time. So I only see this as another advantage.

> > then have the VPS direct this to the stage-1 routing proxy, because the

> location has been provided by the end-point you have the stage-1 routing

> proxy route the cal to the PSAP. Again no checking. This mean that the

> caller could quite literally be anywhere on Earth, but says he is in

> Toronto and the system will believe.

> If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he is

> elsewhere on Earth, he will get a DHCP 99/123 with that information.

[AJW] Absolutely wrong. He can have a softphone and be where ever he wants to be and this is precisely the problem. You are not providing a means to stop this kind of malicious calling, or any means to trace the culprit. The solution does not provide any bar to entry for the would-be attacker and doesn't meet the requirements as I understand them to have been laid out. That is:

Location must be attributable and verifiable as belonging to a specific end-point at the time a specific call is made. Ci2, as currently proposed does do this.

<keep going>

> How can he be elsewhere on earth and get  DHCP 99/123 from Toronto?

> Because he cached it?

> > Canadian i2, says, VSP will send 911 call to the stage-1 routing proxy.

> Stage-1 routing proxy is only accessible by registered VSPs. Stage-1

> routing proxy uses IP address of the call to make a TRUSTED third-party

> request to the LIS for the caller's location

> Error here... the IP address is the key.  Will not work in many scenarios.

> This also requires that IP address be tied to a CIVIC in what is called

> the ILEC HOSTED LIS.  This means that we have to constantly upload the

> public IP addresses of all canadians just in case they call 9-1-1. This is

> a big privacy problem.

> > . The routing proxy then includes the location in-band to the PSAP or

> whatever exists between the routing proxy and the PSAP.

> > The trust in this case comes from the fact that there are only 5 stage-1

> routing proxies and they are run by the existing 911 service providers.

> > Further more the call needs to have originated from a local ISP or the

> third-party request will fail.

> Why ?

[AJW] because if it does not, then the stage-1 routing proxy will fail to resolve to a known LIS and request will get default treatment. This sort of call can then be investigated.

> How about adding digital signatures to DHCP 99/123 constructs that can

> flow through from the PSAP MSAG to the end-points and can get sent-back to

> the PSAP for authentication assessments?  I am thinking of MIME digital

> signatures of PIDF-LO constructs that can be stored in the memory of end-

> points and can be sent back to the PSAP via the relationship between the

> ILEC and the PSAP.

[AJW] As I have stated many times before, simply signing the location isn't good enough. You need to bind it to the device making the call, and you need to have a way of saying that the binding was still valid when the call was made. Quite frankly I don't believe that this can be done in any meaningful way using DHCP, and to the best of my knowledge I haven't seen any proposal (even draft ones) that show how it can be done. My question to you, is what is your aversion to doing this at the application layer and avoid having to change all the home routers in the path?

> And there will be no need that the ILEC provides a Hosted LIS and knows

> the identity of customers on the Internet that may never call 9-1-1 in

> their life.

[AJW] I am not a big fan of the ILEC hosted solution. As I understand it, it was in fact the ISPs that asked for such an option to exist. Quite frankly from my assessments any solution using this approach will require as much equipment in their networks as putting a LIS in will, so they may as well put the LIS in.

> This is way too much of a big brother database than what is the least

> acceptable.

> We need to re-state the concept of ECRIT as not requiring OBO... but trust

> between PSAPs and End-points.

[AJW] I disagree. I actually think that the right place to put the trust is between the ISP and the PSAP, and separate agreement exists between the end-point and the ISP. The ISP is then responsible for who he lets on to his network, and what they do when they are there.

> I've been saying so for the last couple of months to many people on the

> ECRIT list.  I think its time I do a real IETF draft on this.

[AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed PIDF-LOs. Check out http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability-04 it has been around for a very long time.

I will restress my position however, that I think ECRIT Direct and Trusted third-party requests is the right approach for emergency calling.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 Nov 2009 08:54:16 -0500

That¹s where we started with the U.S. Folks.  We educated them.  They are
now comfortable, although they would like a signature on the location
(integrity protection).  Not foolproof.  No system is.

If you just go ask, you get fear, uncertainty, and doubt.  If you educate,
then most people come around to a reasonable point of view.

Ci2 cant work in next generation systems.  It¹s marginally better than the
current U.S. i2 system because it does supply an actual location instead of
a user reported location.  You can¹t extend it to next generation.
Enterprise is merely one example, there are many more.

Anything using an IP address as an identifier is not accurate, and not
reliable.  It can be more accurate and more reliable than some mechanisms,
but it¹s fairly easily defeatable by any attacker with a modicum of
knowledge.   An attack with a false location requires someone to code:
devices would be built to do the right thing.  If you can code, you can find
a relay/zombie/whatever to hide your IP address and present a different
location.  If you are telling regulators that OBO substantially increases
location veracity, you are misleading them.  It improves it only marginally,
and only works for a subset of what we want it to work for.

Brian

On 11/23/09 12:41 AM, "James Winterbottom" <[email-masked]>
wrote:

> [AJW] I am saying that I have spoken to quite a number (more than 4)
> regulators around the world and they will not trust location coming from
> end-points that cannot be verified by some other means. Martin Thomson, I and
> a few others have been trying to get a means for having literal location bound
> to a specific end-point but so far this has gotten little traction. So yes, I
> am saying that the only option right now is a trusted third-party request.
>  
> [AJW] Trusted third-party also eliminates the need to do a veracity check at
> call time. So I only see this as another advantage.
>  
>  
>> > 
> [AJW] Absolutely wrong. He can have a softphone and be where ever he wants to
> be and this is precisely the problem. You are not providing a means to stop
> this kind of malicious calling, or any means to trace the culprit. The
> solution does not provide any bar to entry for the would-be attacker and
> doesn¹t meet the requirements as I understand them to have been laid out. That
> is:
> Location must be attributable and verifiable as belonging to a specific
> end-point at the time a specific call is made. Ci2, as currently proposed does
> do this. 
>  
> <keep going> 
>  
> [AJW] because if it does not, then the stage-1 routing proxy will fail to
> resolve to a known LIS and request will get default treatment. This sort of
> call can then be investigated.
>  
>> > 
> [AJW] As I have stated many times before, simply signing the location isn¹t
> good enough. You need to bind it to the device making the call, and you need
> to have a way of saying that the binding was still valid when the call was
> made. Quite frankly I don¹t believe that this can be done in any meaningful
> way using DHCP, and to the best of my knowledge I haven¹t seen any proposal
> (even draft ones) that show how it can be done. My question to you, is what is
> your aversion to doing this at the application layer and avoid having to
> change all the home routers in the path?
>  
> [AJW] I am not a big fan of the ILEC hosted solution. As I understand it, it
> was in fact the ISPs that asked for such an option to exist. Quite frankly
> from my assessments any solution using this approach will require as much
> equipment in their networks as putting a LIS in will, so they may as well put
> the LIS in.
>  
>> > 
> [AJW] I disagree. I actually think that the right place to put the trust is
> between the ISP and the PSAP, and separate agreement exists between the
> end-point and the ISP. The ISP is then responsible for who he lets on to his
> network, and what they do when they are there.
>  
>> > 
> [AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed PIDF-LOs. Check
> out http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability-04
> it has been around for a very long time.
> I will restress my position however, that I think ECRIT Direct and Trusted
> third-party requests is the right approach for emergency calling.
>  
>> >

---

From: John Lange <[email-masked]>
Date: Mon, 23 Nov 2009 10:12:49 -0600

When I posted the link to that report I didn't really expect it to
generate so much interest and list traffic ;)

Regardless of the technical discussion that has erupted, the point is
simply that the cost of any solution, Ci2 or otherwise is too high to
justify implementation considering the limited number of users who will
benefit at this time and the significant number of users that will be
left out (Skype etc).

Even the argument that Ci2 should be implemented because it's a
worthwhile stepping stone to next-gen systems is misleading.

While it is true that there are some functional components which are
similar (the LIS for example), the architecture itself is proprietary
and therefore there would likely be very little of Ci2 which would not
have to undergo significant changes or outright replacement should there
be a move to something that looks more standards based.

Even worse, once Ci2 is in place (and all that money has been spent)
there will be no motivation to repeat the process and implement a proper
next-gen (Ci3) solution so we'll be stuck with it.

Much better to wait for something more solid to develop from the IETF
while we wait to see how nomadic VOIP evolves.

My crystal ball tells me that the future is mobile and that mobile
data-only devices with softphones will proliferate. This will further
diminish the nomadic VOIP market share.

(and this is a bit off topic but my hope would be that the systems in
place for cellphone/wireless 911 location can be leveraged for these
devices as well. If you dial 911, the device will "intercept" the call
and send you down an emergency call path rather than sending you to your
softphone's VSP).

-- 
John Lange
http://www.johnlange.ca

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Nov 2009 08:40:01 -0800

> diminish the nomadic VOIP market share.

I agree that "mobile" is likely to rapidly displace nomadic.   However, the move to "data only" has ocurred much slower than we had originally thought.  For example, while the original designs for WiMAX were data-only, it quickly became clear that building out a nationwide greenfield 4G data network was so expensive that it would be very difficult to provide coverage competitive with existing 2 and 3G services.  

Even where it has been possible to provide substantial coverage (such as municipal WiFi rollouts), the  level of interest in "data only" networks has been much lower than originally projected, limited to only a few percent of the population, which was insufficient to get to make the services self-sustaining.  

As a result, recent designs have moved toward technology overlays, such as overlays of 4G technology on top of existing 2G networks.  In such designs, voice traffic is typically handled with conventional technology rather than VOIP.

---

From: John Lange <[email-masked]>
Date: Mon, 23 Nov 2009 12:09:24 -0600

On Mon, 2009-11-23 at 08:40 -0800, Bernard Aboba wrote:
> I agree that "mobile" is likely to rapidly displace nomadic.
> However, the move to "data only" has ocurred much slower than we had
> originally thought.

I submit that the relatively slow uptake of data-only is due largely to
the fact that the providers are clinging to voice-based business models.

Devices which support VOIP over data are still rare. For example, the
iPhone technically can do it but the VOIP over data applications are
blocked by Apple.

With Andriod finally showing real signs life on a multitude of hardware
platforms, widespread use of VOIP on data-only mobile devices is
inevitable.

That isn't to imply that there aren't still roadblocks. For example,
here in Canada, the growth of mobile data is severely restricted by the
lack of competition leading to mediocre selection of devices (we just
got the iPhone about a year ago) and very high data prices.

-- 
John Lange
http://www.johnlange.ca

---

From: Francois Menard <[email-masked]>
Date: Mon, 23 Nov 2009 13:47:09 -0500

> Anything using an IP address as an identifier is not accurate, and not reliable.  It can be more accurate and more reliable than some mechanisms, but it’s fairly easily defeatable by any attacker with a modicum of knowledge.   An attack with a false location requires someone to code: devices would be built to do the right thing.  If you can code, you can find a relay/zombie/whatever to hide your IP address and present a different location.  If you are telling regulators that OBO substantially increases location veracity, you are misleading them.  It improves it only marginally, and only works for a subset of what we want it to work for.  
> 

Does ECRIT support OBO?

f.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 23 Nov 2009 11:01:07 -0800

>the fact that the providers are clinging to voice-based business models....
>widespread use of VOIP on data-only mobile devices is inevitable.

While I'd agree that it's likely to happen at some point, there is no "data only" wireless technology on the horizon that seems likely to result in widespread deployment of wireless VOIP in the near future. 

Today's fragmented hotspot deployments with their web portal-based access model are not exactly "VOIP-friendly".  

Even greenfield wireless providers with no existing voice-based business model have failed in their introduction of "data-only" plans.  Typically this is due to unfavorable speed/power and cost/coverage tradeoffs.  This problem occurs because next generation wireless data technologies have greatly increased power consumption and much reduced coverage radius compared with existing technologies.  Capital and maintenance costs rise with the inverse square of the coverage ratio.  So reducing the coverage radius by 50 percent increases cost by 400 percent.  Similarly, power consumption increases more than linearly with speed.  These basic mathematical principles have had devastating effects on the prospects of "data only" wireless networks, whether they be municipal networks unable to provide acceptable coverage with 802.11 APs running at 2.4 or 5 Gz mounted on lamp-posts 600 feet apart or 2.5 Ghz WiMAX pilots that have only demonstrated a 1-2 mile coverage radius.  The bottom line is that the 2.4/2.5 or 5 Ghz spectrum bands are not hospitable to construction of viable "data only" networks.  

It's possible that allocation of spectrum with longer propagation characteristics (e.g. White Spaces) may help in overcoming coverage obstacles, but that is years away.  

>got the iPhone about a year ago) and very high data prices.

Here in the U.S. we have seen "data only" wireless networks offering access for as little as $20/month fail to sign up even 5 percent of the population.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Nov 2009 14:12:32 -0500

Sure it does, especially in the secondary/verification context that  
James describes.  It just requires the access network to *also*  
provide location to the end host so that it (or the VSP) has some idea  
what to do with the call.  E.g., whether to send it to the Canadian  
Stage 1 proxy or the Albanian one.

--Richard

On Nov 23, 2009, at 1:47 PM, Francois Menard wrote:

>> Anything using an IP address as an identifier is not accurate, and  
>> not reliable.  It can be more accurate and more reliable than some  
>> mechanisms, but it’s fairly easily defeatable by any attacker with  
>> a modicum of knowledge.   An attack with a false location requires  
>> someone to code: devices would be built to do the right thing.  If  
>> you can code, you can find a relay/zombie/whatever to hide your IP  
>> address and present a different location.  If you are telling  
>> regulators that OBO substantially increases location veracity, you  
>> are misleading them.  It improves it only marginally, and only  
>> works for a subset of what we want it to work for.
>>
>
> Does ECRIT support OBO?
>
> f.
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 23 Nov 2009 13:17:47 -0600

>iPhone technically can do it but the VOIP over data applications are

well, this is wrong. Apple doesn't block real-time over data, AT&T does.

Think about it. AT&T (like any cellular operator that has a fixed 
all-you-can-eat data plan) charges much much more for cellular calls 
than it does for its data plan.  If all calls were to go over its 
data network,

         #1 this would bring its data network to its knees (something
         AT&T is already struggling with without voice/video traversing
         this part of the network (i.e., bandwidth usage and congested links))

and

         #2 users would choose the cheapest cellular voice plans that
         allow the flat rate data plan -- because most of what users use
         smartphones for is still calling.

Apple has zero incentive to prevent calls from being data packets, 
whereas cellular carriers definitely do, because it impacts all the 
other applications that use their data network.

James

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 23 Nov 2009 14:29:58 -0500

http://finance.yahoo.com/news/ATT-Extends-VoIP-to-3G-bw-767580967.html?x
=0

AT&T does not block VoIP calls on its 2G, 3G, or public Wi-Fi networks.
AT&T does not prevent Apple from offering VoIP applications on the
iPhone that will run over 2G or 3G.
Please stick to blaming Canada. :)
Barbara

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of James M. Polk
> Sent: Monday, November 23, 2009 2:18 PM
> To: John Lange; Bernard Aboba
> Cc: [email-masked]

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Francois Menard <[email-masked]>
Date: Mon, 23 Nov 2009 14:55:24 -0500

> Sure it does, especially in the secondary/verification context that James describes.  It just requires the access network to *also* provide location to the end host so that it (or the VSP) has some idea what to do with the call.  E.g., whether to send it to the Canadian Stage 1 proxy or the Albanian one.
> 

I am referring to the access network providing location to Stage One Proxy.

Does ECRIT allows for this to happen?

f.

---

From: Marc Linsner <[email-masked]>
Date: Mon, 23 Nov 2009 15:15:34 -0500

Bernard,

What would you consider the data dongles and mifi thingies?  Aren't those a
data only service?

My experience has been that VoIP over 3G is less than desirable due to
jitter.  Even the most forgiving of codecs (Skype) struggle with the jitter
on 3G.

-Marc-

On 11/23/09 2:01 PM, "Bernard Aboba" <[email-masked]> wrote:

> While I'd agree that it's likely to happen at some point, there is no "data
> only" wireless technology on the horizon that seems likely to result in
> widespread deployment of wireless VOIP in the near future.
> 
> Even greenfield wireless providers with no existing voice-based business model
> have failed in their introduction of "data-only" plans.  Typically this is due
> to unfavorable speed/power and cost/coverage tradeoffs.  This problem occurs
> because next generation wireless data technologies have greatly increased
> power consumption and much reduced coverage radius compared with existing
> technologies.  Capital and maintenance costs rise with the inverse square of
> the coverage ratio.  So reducing the coverage radius by 50 percent increases
> cost by 400 percent.  Similarly, power consumption increases more than
> linearly with speed.  These basic mathematical principles have had devastating
> effects on the prospects of "data only" wireless networks, whether they be
> municipal networks unable to provide acceptable coverage with 802.11 APs
> running at 2.4 or 5 Gz mounted on lamp-posts 600 feet apart or 2.5 Ghz WiMAX
> pilots that have only demonstrated a 1-2 mile coverage radius.  The bottom lin
>  e is that the 2.4/2.5 or 5 Ghz spectrum bands are not hospitable to
> construction of viable "data only" networks.
> 
> It's possible that allocation of spectrum with longer propagation
> characteristics (e.g. White Spaces) may help in overcoming coverage obstacles,
> but that is years away.
> 
> Here in the U.S. we have seen "data only" wireless networks offering access
> for as little as $20/month fail to sign up even 5 percent of the population.
>

---

From: Marc Linsner <[email-masked]>
Date: Mon, 23 Nov 2009 15:21:48 -0500

Francois,

Yes, ECRIT allows this.  The general OBO topic of privacy/security is for
GeoPriv.

See section 6.3 at:

http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-13#page-8
And
http://tools.ietf.org/html/draft-ietf-ecrit-framework-10#page-19

-Marc-

On 11/23/09 2:55 PM, "Francois Menard" <[email-masked]> wrote:

>> Sure it does, especially in the secondary/verification context that James
>> describes.  It just requires the access network to *also* provide location to
>> the end host so that it (or the VSP) has some idea what to do with the call.
>> E.g., whether to send it to the Canadian Stage 1 proxy or the Albanian one.
>> 
> 
>>>> devices would be built to do the right thing.  If you can code, you can
>>>> find a relay/zombie/whatever to hide your IP address and present a
>>>> different location.  If you are telling regulators that OBO substantially
>>>> increases location veracity, you are misleading them.  It improves it only
>>>> marginally, and only works for a subset of what we want it to work for.
>>>> 
>>> 
>>> Does ECRIT support OBO?
>>> 
>>> f.
>>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Nov 2009 15:28:20 -0500

Yes, it allows it to happen.  There's not a *requirement* that the ISP  
provide location to anyone other than the endpoint, but neither is  
there a *prohibition*.  So it's an area where a national architecture  
like Ci2 could elaborate.

--Richard

On Nov 23, 2009, at 2:55 PM, Francois Menard wrote:

>> provide location to the end host so that it (or the VSP) has some  
>> idea what to do with the call.  E.g., whether to send it to the  
>> Canadian Stage 1 proxy or the Albanian one.
>>
>
>>>> Anything using an IP address as an identifier is not accurate,  
>>>> and not reliable.  It can be more accurate and more reliable than  
>>>> some mechanisms, but it’s fairly easily defeatable by any  
>>>> attacker with a modicum of knowledge.   An attack with a false  
>>>> location requires someone to code: devices would be built to do  
>>>> the right thing.  If you can code, you can find a relay/zombie/ 
>>>> whatever to hide your IP address and present a different  
>>>> location.  If you are telling regulators that OBO substantially  
>>>> increases location veracity, you are misleading them.  It  
>>>> improves it only marginally, and only works for a subset of what  
>>>> we want it to work for.
>>>>
>>>
>>> Does ECRIT support OBO?
>>>
>>> f.
>>>

---

From: John Lange <[email-masked]>
Date: Mon, 23 Nov 2009 15:03:44 -0600

> well, this is wrong. Apple doesn't block real-time over data, AT&T does.

Apple controls what apps are allowed in and does not allow any that can
do VOIP over data. And my understanding is that jailbroke phones can do
VOIP over data so the restriction is on the apps, not the network.

This may have been a result of the deal with AT&T but AFAIK it's a
world-wide restriction.

They do allow apps with voip over wifi.

I personally don't keep up on iPhone news so perhaps things have changed
recently?

-- 
John Lange
http://www.johnlange.ca

---

From: John Lange <[email-masked]>
Date: Mon, 23 Nov 2009 15:12:18 -0600

On Mon, 2009-11-23 at 11:01 -0800, Bernard Aboba wrote:

> Here in the U.S. we have seen "data only" wireless networks offering
> access for as little as $20/month fail to sign up even 5 percent of
> the population.  

Well 5% of the US population is a significant number, but in any case,
what device were they pushing with these plans and what kind of
speeds/coverage did they have?

If there was a great device available with a VOIP softphone and
unlimited data for $20 with the coverage of a cellphone it would have
some real potential.

I know I'd get one.

-- 
John Lange
http://www.johnlange.ca

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Nov 2009 13:36:18 -0800

The data dongles, etc. are indeed "data only" devices.  However, today they only represent a small fraction of all wireless endpoints.  It is conceivable that this could change with the introduction of new computing devices with built in WWAN chipsets (such as netbooks or tablets).   But the current "attach rate" of WWAN chipsets is currently much lower than with free wireless technologies such as WLAN, Bluetooth or even GPS.  In the current economic environment, those wireless chipsets are selling a lot better than WWAN chipsets which require "data only" plans running $60+/month.  

In terms of jitter, this varies considerably based on the specifics of a particular deployment.  The rapid increase in usage of smartphones has put a lot of pressure on existing networks, and many are now running very close to capacity.  So even though we have seen some loosening of VOIP restrictions (my understanding is that Skype use is no longer restricted to WLAN, for example), the user experience during peak usage times will often not be very good. 

I've also seen networks with self-inflicted design problems.  For example, sometimes the GGSN buffering is over-provisioned, in the mistaken belief that this somehow will decrease packet loss.  Instead, it results in a sawtooth ramp up in delay as the queues fill, followed by sustained packet loss as incoming packets drop until the queue can be slowly emptied.  Not good for VOIP. 

As to whether future technologies such as LTE can be provide a better VOIP experience, I'm skeptical.  In the medium term, LTE is most likely to be deployed as an "infill" technology, providing higher speed data access in areas with a high density of data users.  This kind of incremental deployment is much more economical than attempting to create a "greenfield" 4G network, so it is quite likely to happen, paid for by all the new smartphone data plans.  

The question is whether all those new smartphones and data plans will transition to use of VOIP in the near future.  I doubt it.  As long as LTE coverage remains spotty, and wireless networks remain congested, demand for wireless data bandwidth will run ahead of supply.  Without better handling of congestion (such as by using some of the techniques discussed in the Transport Area, such as LEDBAT or Re-ECN), the VOIP user experience won't be good enough to handle a very large fraction of calls, even if restrictions on VOIP usage are removed.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Nov 2009 13:53:32 -0800

> unlimited data for $20 with the coverage of a cellphone it would have

The Philadelphia municipal WiFi buildout is one example that comes to mind.  
With an initial estimated capital cost of $17 million, coverage only extended 
to 70 percent of the city and even within the covered areas, access was 
often only available at the lowest rate (1 Mbps) due to the spacing between
lamp posts (600 feet).   

Covering 100% of the city at higher rates (e.g. 5.5 Mbps) would probably 
have required quadrupling of the capital cost.   Achieving payback on that 
kind of investment would probably have required signing up at least 15 
percent of the population, but initial marketing only garnered a tepid response.

The voice-oriented devices available at the time were VoWLAN handsets from
manufacturers such as Belkin.  At one time, quite a few VOIP providers 
(including Vonage) announced their interest in offering such devices.  However,
due to the price (most VoWLAN handsets today still cost $100 or more) 
and convenience (ever tried to configure WPA2 or sign on to a hotspot web portal
with a special purpose VoWLAN handset?) VOIP providers focused instead on delivering 
wireless voice using DEC 6.0 cordless phones. 

At this point, smartphones are so ahead of special purpose VoWLAN handsets
that the game is effectively over.   However, many smartphones sold via carriers
come with a built-in data plan, and if you're already signed up for a
cellular voice and data plan, the extra $20/month for muni-WiFi access looks a 
lot less attractive.

---

From: Francois D. Menard <[email-masked]>
Date: Mon, 23 Nov 2009 21:08:23 -0500

> [AJW] Trusted third-party also eliminates the need to do a veracity check at call time. So I only see this as another advantage.

How is that different from end-to-end location download in the end-point then?

If the veracity check is not done at call time, how is veracity is being assessed?
> [AJW] Absolutely wrong. He can have a softphone and be where ever he wants to be and this is precisely the problem. You are not providing a means to stop this kind of malicious calling, or any means to trace the culprit. The solution does not provide any bar to entry for the would-be attacker and doesn’t meet the requirements as I understand them to have been laid out. That is:

How are softphones  different from ATAs?

If he is in Singapour, he will get an IP address from Singapour, and thus will get an DHCP location from Singapour.

I do not see your point at all.

Ci2 only bases its finding on the public IP address of the Call.  If I am behind VPN, we're toast.

Say I am VPNing to my home and using my SIP PBX at home... which I do by the way ;)

> [AJW] because if it does not, then the stage-1 routing proxy will fail to resolve to a known LIS and request will get default treatment. This sort of call can then be investigated.

It will also fail in the case where an ISP is using a block of IP addresses of another ISP, where it is impossible to register something in ARIN.

There are lots of blocks out there that are not 'clean'.

This issue of involving ARIN has been over simplified by the ILECs in Canada.

> [AJW] As I have stated many times before, simply signing the location isn’t good enough. You need to bind it to the device making the call, and you need to have a way of saying that the binding was still valid when the call was made. Quite frankly I don’t believe that this can be done in any meaningful way using DHCP, and to the best of my knowledge I haven’t seen any proposal (even draft ones) that show how it can be done. My question to you, is what is your aversion to doing this at the application layer and avoid having to change all the home routers in the path?

OK, there is this new requirement 'you need to have a way to say that the binding is valid at E-9-1-1 call time'

In your statement, who is the entity referred to as 'you'.

The ISP? The PSAP? The End-User?

Our proposed legal requirement is not to have 'user-inputted' location.  There is no legal requirement for disallowing 'user-sent location if not user-inputted'.

I did not read this as being a requirement of ECRIT to deny end-to-end 'user-sent but not user-inputted location'.

OBO is not end-to-end.  All IETF standards are supposed to be end-to-end.

Show me an OBO that will actually work and will preserve privacy.  Ci2 doesn't do any of these two basic criterias.

a) if it is based on a public IP address it will not work all the time
b) if it is based on a Hosted LIS, which will contain all public IP addresses, it will not work period.

> [AJW] I am not a big fan of the ILEC hosted solution. As I understand it, it was in fact the ISPs that asked for such an option to exist. Quite frankly from my assessments any solution using this a…

Ci2 requires a LIS at the ILEC as well as a LIS at the ISP called a Location Determination Platform.  LDP LIS.

Ci2 requires LIS to LIS communications utilizing HELD. HELD was never designed for that.

I am not even sure there is a current IETF draft which explains how to use HELD or BEEP for that.

An ISP LIS is to communicate to an ILEC LIS to retrieve location.

This location could actually come over RADIUS and the wiremap only reside in the ISP LIS.

If you really want OBO, the only other option that I can see is to force VoIP end-users to utilize a SIP PROXY that belongs to the ISP rather than one of the VoIP service provider and get into technical ITMPs (Internet Traffic Management Practices).   This way, no VoIP is allowed unless granted by an ISP SIP PROXY where the OBO can be assessed by the ISP.

This seems to me as adverse to net neutrality. 

It would be better to make end-to-end work.

> [AJW] I disagree. I actually think that the right place to put the trust is between the ISP and the PSAP, and separate agreement exists between the end-point and the ISP. The ISP is then responsibl…

There is no option for such trust to exist in Ci2.

There is no relationship between the ISP and the PSAP.  One only exists between the ISP and MaBell as an agent of the PSAPs.

MaBell is requiring ISPs to divulge the public IP addresses of all subscribers 24/7 just in case an E9-1-1 call ever gets made.

This is the OBO proposal we have in Canada before the regulator.  it will be fought in court if ever mandated. 

> I will restress my position however, that I think ECRIT Direct and Trusted third-party requests is the right approach for emergency calling.

Thanks for the pointer. 

I fail to understand how signed PIDF-LO's, i.e. location objects that the PSAP can reconcile at call time, as being MSAG-VALID, and failing to reconcile at call time, can issue a dispatch knowing that it may take a chance... do not make such information exchange 'trustable'.

-=Francois=-

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Nov 2009 13:00:04 +0800

Hi Francois,

Please read the ECRIT Direct draft. It does not require a SIP Proxy in the ISP.

Other comments inline.

> From: Francois D.Menard [mailto:[email-masked]]

> Sent: Tuesday, 24 November 2009 1:08 PM

> > > You are saying that veracity needs to be assessed while a 9-1-1 call

> > [AJW] Trusted third-party also eliminates the need to do a veracity

> check at call time. So I only see this as another advantage.

> How is that different from end-to-end location download in the end-point

> then?

[AJW] Let me see. If the emergency service provider requests the location information directly from the source, versus trusting location that has traversed and end-point, that as you continually point out could have been downloaded from an open source site and modified. Hmmm!! Do you really see these as being the same? I know I don't.

> If the veracity check is not done at call time, how is veracity is being

> assessed?

> > > If he is in Toronto, his ATA will get a DHCP 99/123 with that. If he

> > [AJW] Absolutely wrong. He can have a softphone and be where ever he

> wants to be and this is precisely the problem. You are not providing a

> means to stop this kind of malicious calling, or any means to trace the

> culprit. The solution does not provide any bar to entry for the would-be

> attacker and doesn't meet the requirements as I understand them to have

> been laid out. That is:

> end-point at the time a specific call is made. Ci2, as currently proposed

> does do this.

> If he is in Singapour, he will get an IP address from Singapour, and thus

> will get an DHCP location from Singapour.

> I do not see your point at all.

[AJW] I know you don't. If you did you wouldn't be saying what you are saying. There is absolutely nothing stopping him from adding whatever location he wants either directly into the device itself, or through the DHCP server. There is no control in this case, and no means to check veracity, and no bar to entry. Quite frankly anyone proposing this as a serious solution has really not assessed the risks. The regulators that I have spoken to will not support a proposal of this nature.

> Ci2 only bases its finding on the public IP address of the Call.  If I am

> behind VPN, we're toast.

[AJW] Actually you might not be. The onus is on the VPN server end to ensure that you get proper connectivity for the applications you want to use.

> Say I am VPNing to my home and using my SIP PBX at home... which I do by

> the way ;)

[AJW] So perhaps nomadic VoIP is not as dead as you might be professing... ;)

> > > > Further more the call needs to have originated from a local ISP or

> the

> > [AJW] because if it does not, then the stage-1 routing proxy will fail

> to resolve to a known LIS and request will get default treatment. This

> sort of call can then be investigated.

> It will also fail in the case where an ISP is using a block of IP

> addresses of another ISP, where it is impossible to register something in

> ARIN.

[AJW] Certainly when I was at the RIPE meeting a couple of months ago ARIN and the APNIC guys seemed to think that this type of problem was far from insurmountable. I don't propose to have a solution here, but those people that manage the database seemed to think that it could be solved.

> This issue of involving ARIN has been over simplified by the ILECs in

> Canada.

> > > flow through from the PSAP MSAG to the end-points and can get sent-

> back to

> > > the PSAP for authentication assessments?  I am thinking of MIME

> digital

> > > signatures of PIDF-LO constructs that can be stored in the memory of

> end-

> > > points and can be sent back to the PSAP via the relationship between

> the

> > [AJW] As I have stated many times before, simply signing the location

> isn't good enough. You need to bind it to the device making the call, and

> you need to have a way of saying that the binding was still valid when the

> call was made. Quite frankly I don't believe that this can be done in any

> meaningful way using DHCP, and to the best of my knowledge I haven't seen

> any proposal (even draft ones) that show how it can be done. My question

> to you, is what is your aversion to doing this at the application layer

> and avoid having to change all the home routers in the path?

> OK, there is this new requirement 'you need to have a way to say that the

> binding is valid at E-9-1-1 call time'

> In your statement, who is the entity referred to as 'you'.

[AJW] This is not actually a new requirement it is a core requirement. The you refers to the entity providing the location, and the entity ultimately using the location to provide a service.

> Our proposed legal requirement is not to have 'user-inputted' location.

> There is no legal requirement for disallowing 'user-sent location if not

> user-inputted'.

[AJW] Since for reasons previously stated there is no way in your proposal to disseminate between the two, this split hair proposal that I think has very little merit. Either you can verify it, or the solution can't, if you can't, then you should assume that it as user entered.

> I did not read this as being a requirement of ECRIT to deny end-to-end

> 'user-sent but not user-inputted location'.

[AJW] I was under the impression that we were debating Ci2 and not ECRIT. Having said that, I believe that without a means to check location veracity that a lot of regions will be reluctant to deploy what is currently being proposed.

[AJW] I would argue that IETF specifications are peer to peer, rather than end to end per say. Consequently a Trusted Third-party location request is peer to peer and so quite acceptable.

> Show me an OBO that will actually work and will preserve privacy.  Ci2

> doesn't do any of these two basic criterias.

[AJW] It is for exactly this reason that the term OBO is no longer used. It is Trusted third-party, and the onus is on the trusted entity, and rules associated with that trust relationship.

> b) if it is based on a Hosted LIS, which will contain all public IP

> addresses, it will not work period.

> > > And there will be no need that the ILEC provides a Hosted LIS and

> knows

> > [AJW] I am not a big fan of the ILEC hosted solution. As I understand

> it, it was in fact the ISPs that asked for such an option to exist. Quite

> frankly from my assessments any solution using this approach will require

> as much equipment in their networks as putting a LIS in will, so they may

> as well put the LIS in.

> Ci2 requires a LIS at the ILEC as well as a LIS at the ISP called a

> Location Determination Platform.  LDP LIS.

> Ci2 requires LIS to LIS communications utilizing HELD. HELD was never

> designed for that.

[AJW] As an original designer of HELD I can state quite categorically that you are wrong. HELD was absolutely designed with this in mind. You might also care to look at: http://www.nena.org/standards/technical/voip/location-determination-ip-based-emergency-services

> I am not even sure there is a current IETF draft which explains how to use

> HELD or BEEP for that.

http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-05

> This location could actually come over RADIUS and the wiremap only reside

> in the ISP LIS.

> If you really want OBO, the only other option that I can see is to force

> VoIP end-users to utilize a SIP PROXY that belongs to the ISP rather than

> one of the VoIP service provider and get into technical ITMPs (Internet

> Traffic Management Practices).   This way, no VoIP is allowed unless

> granted by an ISP SIP PROXY where the OBO can be assessed by the ISP.

[AJW] See above, this is not what is being described at all.

> > > We need to re-state the concept of ECRIT as not requiring OBO... but

> trust

> > [AJW] I disagree. I actually think that the right place to put the trust

> is between the ISP and the PSAP, and separate agreement exists between the

> end-point and the ISP. The ISP is then responsible for who he lets on to

> his network, and what they do when they are there.

[AJW] Let's agree to disagree on this point. The ISP is providing service within the jurisdiction of a PSAP. Ci2, as I understand it, proposes that if the ISP has a LIS, that the Stage-1 routing proxy has a VPN connection to the LIS over which third-party requests are made. How can this VPN be established without a trust agreement being in place?

> There is no relationship between the ISP and the PSAP.  One only exists

> between the ISP and MaBell as an agent of the PSAPs.

[AJW] If Bell is operating as the agent for the PSAP then it is still representing the PSAP is it not?

> MaBell is requiring ISPs to divulge the public IP addresses of all

> subscribers 24/7 just in case an E9-1-1 call ever gets made.

[AJW] This is not true if the ISP elects to run the LIS. Also what you are not making clear, is that if the ISP runs a LIS there is nothing that stops the ISP from making this location available to end-points so that they can use it. The only thing that Ci2 says is that for now we won't use device-provided location for emergency calling because we have no way to test it veracity. These all seem very reasonable approaches to me.

> This is the OBO proposal we have in Canada before the regulator.  it will

> be fought in court if ever mandated.

[AJW] That would be a pity and certainly not in the best interests of the public.

> > [AJW] version 1.0 of HELD (5 or is it 6 years ago) had signed PIDF-LOs.

> Check out http://tools.ietf.org/html/draft-thomson-geopriv-location-

> dependability-04 it has been around for a very long time.

> > I will restress my position however, that I think ECRIT Direct and

> Trusted third-party requests is the right approach for emergency calling.

> I fail to understand how signed PIDF-LO's, i.e. location objects that the

> PSAP can reconcile at call time, as being MSAG-VALID, and failing to

> reconcile at call time, can issue a dispatch knowing that it may take a

> chance... do not make such information exchange 'trustable'.

[AJW] I don't understand what you are trying say here. My point is that calls that come with location that cannot be validated may get a completely different call handling procedure to those that can be verified. Providing a single consistent means to verify location means that this can be done much more efficiently.

---

From: "Francois D. Menard" <[email-masked]>
Date: Tue, 24 Nov 2009 00:17:25 -0500

> [AJW] I would argue that IETF specifications are peer to peer, rather than end to end per say. Consequently a Trusted Third-party location request is peer to peer and so quite acceptable.

OK, so if I get this right there are 5 peers in a single E-9-1-1 transaction involving Ci2.

Lets call them  1, 2, 3, 4 & 5

1) The end-point requesting emergency calls

2) The SIP proxy of the voice-over-ip service provider

3) The SIP proxy of the emergency service provider (in our case, the ILEC)

4) The LIS of the ILEC

5) The LIS of the ISP

So for veracity to be assessed 

For every E-9-1-1 call

1 sends an invite to 2
2 sends an invite to 3
3 sends a HELD request to 4
4 sends a HELD request to 5
5 responds to 4
4 responds to 3
3 responds to 2
2 responds to 1

3 is not on the public Internet
4 is not on the public Internet
5 is not on the public Internet

And all of this is peer to peer ;)

I am confused!

If this is superior to end-to-end, because regulators want a double check on location because PSAPs are not willing to trust anything downloaded to end-points, even PIDF-LO's that they can recognize MSAG VALID... then perhaps we actually need a policy debate on their requirement.

And since you profess that I am the one saying VoIP is dead, I changed the topic.

f.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Nov 2009 13:42:29 +0800

I think you have missed the point, and I think you call flow is mixed up, unless you are using a hosted LIS solution, which is something that I don't particularly like and is not mandated for use in Ci2.

In any case, veracity of location is achieved using a third-party request from, in the ci2 case, the stage-1 routing-proxy to the ISP LIS (though I agree this could be the hosted LIS). The ISP LIS is obliged to provide the location it has for the IP address, and it is obliged to make sure that that is as correct as can be. How it determines that is a different problem.

The request and response between the stage-1 routing-proxy and the ISP-LIS is a peer to peer relationship. Request and response.

I will actually go one step further and say that the stage-1 routing proxy is in fact and ESRP, and that most if not all ESRPs that I am aware of are being implemented as B2BUAs, so the termination point in your end-to-end model is in fact the stage-1 routing-proxy or ESRP, making Ci2 perfectly fine.

Cheers
James

> Sent: Tuesday, 24 November 2009 4:17 PM
> To: Winterbottom, James
> Cc: ecrit
> Subject: ECRIT is not end-to-end?
> 
> >
> > [AJW] I would argue that IETF specifications are peer to peer, rather
> than end to end per say. Consequently a Trusted Third-party location
> request is peer to peer and so quite acceptable.
> 
> If this is superior to end-to-end, because regulators want a double check
> on location because PSAPs are not willing to trust anything downloaded to
> end-points, even PIDF-LO's that they can recognize MSAG VALID... then
> perhaps we actually need a policy debate on their requirement.
>

---

From: "Francois D. Menard" <[email-masked]>
Date: Tue, 24 Nov 2009 00:48:32 -0500

> I think you have missed the point, and I think you call flow is mixed up, unless you are using a hosted LIS solution, which is something that I don't particularly like and is not mandated for use i…

I do not believe that I am mixed up and yes, I am using the hosted LIS call flow.

BTW, hosted LIS is the only implementation of Ci2 currently costed and promoted by the ILECs to the CRTC.

While it may not be mandated, the ILECs have made it  cost prohibitive for ASPs to have their own LIS.

> In any case, veracity of location is achieved using a third-party request from, in the ci2 case, the stage-1 routing-proxy to the ISP LIS (though I agree this could be the hosted LIS). The ISP LIS…

Is there any other possible key than a public IP address?

> The request and response between the stage-1 routing-proxy and the ISP-LIS is a peer to peer relationship. Request and response.

a peer-to-peer relationship not on the public Internet that is...

> I will actually go one step further and say that the stage-1 routing proxy is in fact and ESRP, and that most if not all ESRPs that I am aware of are being implemented as B2BUAs, so the termination…

its not end-to-end, as the ESRP of the Stage-1 proxy is not on the public internet in Ci2... its only accessible via direct interconnection between a voice-over-IP service provider and the ILEC as an agent to the PSAPs in Ci2.

Do I have the call flow down path?

f.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Nov 2009 13:56:11 +0800

Hi Francois,

Can you explain the fragment below please?

Cheers

James

> BTW, hosted LIS is the only implementation of Ci2 currently costed and

> promoted by the ILECs to the CRTC.

> While it may not be mandated, the ILECs have made it  cost prohibitive for

> ASPs to have their own LIS.

[AJW] If the hosted LIS is the only proposal costed, then how can the ILECs have priced ISP LIS ownership out of existence?

Are there indicative connection costs being quoted?

---

From: "Francois D. Menard" <[email-masked]>
Date: Tue, 24 Nov 2009 07:25:17 -0500

See:

http://www.crtc.gc.ca/public/partvii/2007/8663/c12_200717738/898632.zip

Bell Canada intends to charge for an ASP who is also a VISP:

$10,700 per year for ISP LIS and $5400 per year for hosted LIS.

Bell Aliant  for the Maritimes, for or an ASP who is also a VISP:

$46,100 per year for ISP LIS and $19,000 per year for hosted LIS 

There isin't one service provider out there in Canada that can afford this.

and in the latter case, also $68 per month per subscriber as well on top of it;)

$81 per month per sub for a business case I'm trying to make happen based on 300 subscribers in one province.

At least with end-to-end location download, there is still hope that the thing will be affordable.

The ILECs did provide incentives not to have several ASPs entertain use of their own LIS.

F.

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 09:50:32 +0100

Hi Bernard,

One reason for high jitter in many of the current 3G wireless networks is that the link layer operates in "acknowledged mode". This means that at L2 a packet/frame is retransmitted if it's lost for instance due to unrecoverable bit errors over the radio. For that particular user/connection, all the forthcoming packets are then waiting too until the retransmission completes. As RTTs tend to be rather high and bitrates relatively slow, this creates a situation where the E2E delay for a number of packets suddenly peaks way over the average. For something like VoIP all those packets are probably discarded at the receiver. GGSN buffers may contribute something more to this, but at least some of the network elements provide per user/connection queueing, so the users are separated from each other what comes to congestion and queuing. I'm not sure if this is going to change in newer radio systems such as LTE except the RTT will be lower and the transmit rate higher.

LTE deployment will differ between different regions too. In US (Verizon, ATT both have ~700 MHz spectrum for LTE) and Japan the situation may actually be pretty good in a few years time, in Europe it will take longer (initial deployments at 2.6 GHz). The operators may start offering voice service as a combination of LTE VoIP and Circuit Switched voice, the call handover techniques between the two have been standardized by 3GPP (but not tested in the field yet). One of the interesting questions about LTE indeed is whether good quality VoIP only works as offered by the access operator, since they can provision the connections used for their own services, or can we make access operator independent real-time services good enough too. If the buffers, L2 modes etc. things that can be configured are a major issue, we may need something like HOMEGATE for wide area wireless :)

Markus

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bernard Aboba
Sent: 23 November, 2009 23:36
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] wireless VOIP is dead

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Nov 2009 07:19:00 -0800

In practice, it has proved quite tricky for voice and data to co-exist well on wireless data services.  I believe that it is possible with the right L2 engineering on both the client and operator side,  even without  QoS schemes that have not gotten much deployment (e.g. multiple CIDs/PDP contexts). So far, the question has been the level of care required to get it right.  For example, some chipset vendors do not pay attention to VOIP performance, since their chips are mostly purchased for use with bulk data transmission. 

In the case of WLAN chipsets, the lack of interest in VOIP has lead to a self-fulfilling prophesy, resulting in selection of other technologies such as DECT, both in consumer and even enterprise scenarios (see http://www.avaya.com/usa/resource/assets/casestudies/univwashcasestudyuc3920.pdf ).  

In general, I have been disappointed in wireless services operating in the 2.5/2.6 Ghz band.  The proximity to the 2.4 Ghz unlicensed band, while allowing reuse of mass market components, has caused quite a few interference problems and the propagation characteristics make it difficult to achieve excellent coverage. 

My overall conclusion is that "all data" wireless networks are still in the nascient stages and that this, along with some of the other trends could impede the widespread deployment of the ECRIT architecture. 

From: [email-masked]
To: [email-masked]; [email-masked]
CC: [email-masked]
Date: Wed, 25 Nov 2009 09:50:32 +0100
Subject: RE: [Ecrit] wireless VOIP is dead

Hi Bernard,
 
One reason for high jitter in many of the current 3G wireless 
networks is that the link layer operates in "acknowledged mode". This means that 
at L2 a packet/frame is retransmitted if it's lost for instance due to 
unrecoverable bit errors over the radio. For that particular user/connection, 
all the forthcoming packets are then waiting too until the retransmission 
completes. As RTTs tend to be rather high and bitrates relatively slow, this 
creates a situation where the E2E delay for a number of packets suddenly peaks 
way over the average. For something like VoIP all those packets are probably 
discarded at the receiver. GGSN buffers may contribute something more to this, 
but at least some of the network elements provide per user/connection 
queueing, so the users are separated from each other what comes to 
congestion and queuing. I'm not sure if this is going to change in newer radio 
systems such as LTE except the RTT will be lower and the transmit rate 
higher. 
 
LTE deployment will differ between different regions too. In US 
(Verizon, ATT both have ~700 MHz spectrum for LTE) and Japan the situation may 
actually be pretty good in a few years time, in Europe it will take longer 
(initial deployments at 2.6 GHz). The operators may start offering voice service 
as a combination of LTE VoIP and Circuit Switched voice, the call handover 
techniques between the two have been standardized by 3GPP (but not tested in the 
field yet). One of the interesting questions about LTE indeed is whether good 
quality VoIP only works as offered by the access operator, since they can 
provision the connections used for their own services, or can we make access 
operator independent real-time services good enough too. If the buffers, L2 
modes etc. things that can be configured are a major issue, we may need 
something like HOMEGATE for wide area wireless :)
 
Markus

  
  From: [email-masked] 
  [mailto:[email-masked]] On Behalf Of ext Bernard 
  Aboba
Sent: 23 November, 2009 23:36
To: 
  [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] 
  wireless VOIP is dead

  The data dongles, etc. are indeed "data only" devices.  
  However, today they only represent a small fraction of all wireless 
  endpoints.  It is conceivable that this could change with the 
  introduction of new computing devices with built in WWAN chipsets (such as 
  netbooks or tablets).   But the current "attach rate" of WWAN 
  chipsets is currently much lower than with free wireless technologies such as 
  WLAN, Bluetooth or even GPS.  In the current economic environment, those 
  wireless chipsets are selling a lot better than WWAN chipsets which require 
  "data only" plans running $60+/month.  

In terms of jitter, this 
  varies considerably based on the specifics of a particular deployment.  
  The rapid increase in usage of smartphones has put a lot of pressure on 
  existing networks, and many are now running very close to capacity.  So 
  even though we have seen some loosening of VOIP restrictions (my understanding 
  is that Skype use is no longer restricted to WLAN, for example), the user 
  experience during peak usage times will often not be very good. 

I've 
  also seen networks with self-inflicted design problems.  For example, 
  sometimes the GGSN buffering is over-provisioned, in the mistaken belief that 
  this somehow will decrease packet loss.  Instead, it results in a 
  sawtooth ramp up in delay as the queues fill, followed by sustained packet 
  loss as incoming packets drop until the queue can be slowly emptied.  Not 
  good for VOIP. 

As to whether future technologies such as LTE can be 
  provide a better VOIP experience, I'm skeptical.  In the medium term, LTE 
  is most likely to be deployed as an "infill" technology, providing higher 
  speed data access in areas with a high density of data users.  This kind 
  of incremental deployment is much more economical than attempting to create a 
  "greenfield" 4G network, so it is quite likely to happen, paid for by all the 
  new smartphone data plans.  

The question is whether all those new 
  smartphones and data plans will transition to use of VOIP in the near 
  future.  I doubt it.  As long as LTE coverage remains spotty, and 
  wireless networks remain congested, demand for wireless data bandwidth will 
  run ahead of supply.  Without better handling of congestion (such as by 
  using some of the techniques discussed in the Transport Area, such as LEDBAT 
  or Re-ECN), the VOIP user experience won't be good enough to handle a very 
  large fraction of calls, even if restrictions on VOIP usage are 
  removed.

> Bernard,
> 
> What would you consider the 
  data dongles and mifi thingies? Aren't those a
> data only 
  service?
  -Marc-
> >> I submit 
  that the relatively slow uptake of data-only is due largely to
> > only" wireless technology 
  on the horizon that seems likely to result in
> > widespread 
  deployment of wireless VOIP in the near future.
  Today's fragmented hotspot deployments with their web portal-based 
  access
> > model are not exactly "VOIP-friendly".
> > 
  
> > to unfavorable speed/power and 
  cost/coverage tradeoffs. This problem occurs
> > because next 
  generation wireless data technologies have greatly increased
  power consumption and much reduced coverage radius compared with 
  existing
> > cost by 400 percent. 
  Similarly, power consumption increases more than
> > linearly with 
  speed. These basic mathematical principles have had devastating
  effects on the prospects of "data only" wireless networks, whether they 
  be
> > characteristics (e.g. White 
  Spaces) may help in overcoming coverage obstacles,
> > but that is 
  years away.
> >> here in Canada, the 
  growth of mobile data is severely restricted by the
> >> lack of 
  competition leading to mediocre selection of devices (we just
  
> > Ecrit mailing 
  list

---

From: John Lange <[email-masked]>
Date: Wed, 25 Nov 2009 09:35:05 -0600

> One reason for high jitter in many of the current 3G wireless networks is
> that the link layer operates in "acknowledged mode". This means that at L2 a
> packet/frame is retransmitted if it's lost for instance due to unrecoverable
> bit errors over the radio. For that particular user/connection, all the
> forthcoming packets are then waiting too until the retransmission completes.

This seems like the classic bellhead vs. nethead battle. Bellheads
built the wireless network and made it "smart" at layer 2. The network
therefore tries to do the work of ensuring all the data makes it from
end-to-end. The "smart" network makes sure all the packets arrive at
the endpoints but the delay results in them being discarded anyway.

In the nethead model, it's the TCP layer (or higher if you choose UDP)
that worries (or not) about the packets making it from end-to-end.

Given that people use wireless data for IP based networks, does
operating in ack mode make any sense? It's just redundant at the TCP
layer and broken at the UDP layer. Or maybe this is just a convenient
way of ensuring the network isn't good for real-time data applications
like voice?

-- 
John Lange
www.johnlange.ca

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Nov 2009 08:16:16 -0800

> layer and broken at the UDP layer. 

For wireless data traffic, (most of which runs over TCP), limited retransmission

maximizes throughput, as long as the RTT from the client to the cell tower

is much less than the end-to-end RTT.  Without retransmission, the packet

error rate (PER) could be too high to allow TCP to function. 

For example, I have seen WLAN deployments with frame error rates (FER) as high

as 50  percent, requiring multiple retransmissions to get the PER down to a reasonable

level.  This is why standards such as IEEE 802.11 specify 7 as the default maximum

number of retransmissions.  

>Or maybe this is just a convenient way of ensuring the network isn't good for real-time 

>data applications like voice?

Today, VOIP performance testing is relatively rare among wireless LAN chipset vendors.  

This is because good results on these tests are rarely a purchase criteria from customers. 

The customers in turn don't care that much about wireless VOIP performance because it's

not a big revenue generator.  This isn't a conspiracy, it's just capitalism at work.