Next Generation 911 – What Every Service Provider Needs to Know

The emergency service environment is rapidly evolving due to National Emergency Number Association’s (NENA) i3 Next Generation 911 systems. How can your company prepare for the future? Find out in this webinar!

What you’ll learn

• What the next generation of 911 looks like in action
• How telecommunications companies may be impacted by changing regulations or may be able to take advantage of the new technology
• What you can do to ensure that you’re prepared for the future

Webinar Transcription

Welcome to our webinar,  “Next Generation 911, What Every Service Provider Needs to Know” presented by Bandwidth. I’m happy to introduce our speaker and emergency thought leader, Thomas Ginter.

Thomas is a certified professional engineer and 911 industry veteran who has been working in the space since 1995. He has been engaged in the design, development and deployment of emergency services technologies supporting cellular 2G, 3G, and 4G wireless mobile systems for voice over IP 911 systems, and text to 911 systems. All on a national scale as well as statewide systems for Next Generation 911. That’s quite a list of accolades. I’ll hand everything over to Thomas now.

What You Need to Know

Well, thank you very much, Tyler, it’s really good to be here with you today. Voice over IP has now displaced traditional wire line telephony. It’s no news to the folks who are listening here on the call. There are more voice over IP phones than there are wireline phones, in fact, and wireless telephony is now using voice over LTE.

So here we have a very interesting change in dynamic that really started in the early two thousands and back in the day before voice over IP really took over, a few problems were observed. From a cloud based service, often the cloud VoIP providers of the day didn’t send calls to 911, or if they sent it to 911, it could wind up at any place inside of the United States, any 911 call center. If it did appear at a 911 call center, the location of the caller or their address certainly did not appear in the correct format.

By the time we got to 2005, the FCC had made some decrees in this regard. The North American Emergency Numbering Association had developed some standards and they all kind of sorted out how VoIP calls would get to the 911 call centers in a sensible and orderly fashion. That was something we call today the i2 Protocol.

So what is happening now? Here we are in 2016, we’ve got another change, whereas voice over IP changed sort of the way that the pitcher side of the mount, you know, the way that calls came from the pitcher. Now we have the capture side of the ballpark changing and the capture side is the 911 networks itself, so here we have IP taking over for traditional emergency services networks and these are called Next Generation 911 networks.

For the purposes of today, we’re going to talk about how the emergency services network site changes might have impacts coming back to the service providers pitching those VoIP calls across the mount.

Quick Review of “Legacy” 911

Now, we’re going to go through today a quick overview of legacy 911. I’m going to do a quick overview of i2 so you can see how those voice calls get there and how they are differentiated from legacy 911.

We’re going to keep this at a very high level. I’m not going to be getting into explicit protocols for parameters. We’re going to look at the paradigms that are shifting. We’re going to step into Next Gen 911, again, at a very high level and we’re going to talk a little bit about this technology called SIP PIDF-Lo, we’ll be explaining that in a little bit of detail, but again, not at a coder level, it’s more for the business manager so they can understand what’s coming and what the ramifications are from a business perspective. Even more importantly, what these technologies mean in terms of new opportunities for new business ventures that the local exchange carrier or the competitive local exchange carrier can engage in.

Now, you know, I’m the kind of guy that if I’m listening to the evening news and they say “meteor streaking from the sky towards the earth, please wait for the next following couple of minutes of commercials and we’ll tell you all about it”, that’s a little irritating to me. I just kind of want to know what the punchline is and not have to hang around for 28 more minutes on a webinar to find out what’s the big impact.

Well, so the punchline is that for voice over IP service providers, the techniques that you’re using today to pitch those VoIP calls into the 911 networks are going to work for quite some time to come. There are no immediate and drastic changes that you need to make. The vendor community, including Bandwidth 911 Access, that is taking your 911 VoIP calls and brokering them to all of the Public Safety Answering Points in the nation, they are sound, and don’t need to change or rather the changes that are being made are made on the back end and transparent to you.

However, because there are some neat features and some neat capabilities, again, this thing called SIP PIDF-Lo, there are opportunities where you, the competitive local exchange carriers for the VoIP cloud carriers might be able to pitch some neat, new innovative features for university communications, for telematics, and for home security.

We’re going to give you some examples of those, but we’re going to build up to it going through first, some legacy training and some explanations of Next Gen. Then show you how to apply these at the end. So bottom line is, of course good news, you don’t have to do a darn thing, just sit back, relax, and let’s give you some information on how 911 is changing the world around you.

LEC Implementation of Enhanced 911

Here are a list of terms. I’m not going to provide definitions of all of these terms. What I’m going to do is provide this list again at the end of the webinar. That way as we go through, I will be explaining all of these terms in context, in diagrams, and call flows, just to show you what they all are. But at the very end, as you’re contemplating questions or maybe as you’re jotting down questions as we go along, you’ll be able to use this as a quick cheat sheet saying, “Hey Thomas, that ESGW, what is that? Could you explain that a bit more?” And you’ll have a list here that you can work off of.

Without further ado, let’s talk a local exchange carrier. Really, even before we talk local exchange carrier, let’s make sure that the audience here understands the difference between a VoIP service provider, a local exchange carrier (LEC) and incumbent local exchange carrier (ILEC) or a competitive local exchange carrier (CLEC).

I’m using the term VoIP service provider or VSP for any carrier that has carriage of a voice call over the internet protocol.

I’m using the term LEC to really refer to an old school landline twisted pair technology, for the incumbent carriers, so I’m using the word incumbent LEC, to really to identify facilities based carrier that still has a physical SS7 and ISDN infrastructure buried in the ground and they’re limited to the physicality footprint of where they have literally wires extending into homes and businesses.

I’m using the term CLEC or competitive local exchange carrier to refer to cloud based carriers that are disassociated from the fiber cables that are in the ground and can instead provide a telephone number in any municipality and provide that service.

Having said that, here we have a quickie little picture. We have a local exchange carrier, delivering a call through to a Public Safety Answering Point, so what I like to do here is follow the bouncing ball. You’ll see a series of red balls and we’re going to go through these numerically starting at zero, which is actually in the center of the screen.

The first thing that happens in legacy 911 is provisioning. That telephone number has a place in the local exchange carriers back office in their billing system, and they keep track of who has what phone at what address and they obviously would also track how they paid for it and is it in service and all those kinds of things. Of course, none of that information is provided to the ALI database, this automatic location identification.

What is happening here is that every time the telephone company adds a number, they have to add a line item in this automatic location database called an ALI database, so that the telephone number, the name associated with the number and the address where a 911 call is made that help needs to be delivered to, that triplet of information is there in the ALI database.

Also, above it there’s a selective router and that selective router will want to know which Public Safety Answering Point in the nation that particular caller ought to have his calls routed to at the time that 911 was dialed.

So with that bit of provisioning at step zero, we can go two steps, one, two, and three. Individual dials, 911, it hits the local exchange carriers switch. Local exchange carriers switch is able to do one and only one thing with that 911 call, it sends it to the selective router. The selective router, takes a look at the pre-provisioned routing instructions based on that address and sends the call onto the correct Public Safety Answering Point. That caller, that call taker rather, receives the 911 call and says, “what’s your emergency? And can you confirm your location”.

While they’re saying those words, they’re actually dipping the database that is this ALI database, Automatic Location Identification database, and getting the correctly formatted address presented to them on the screen and this is a landline 911 that has been implemented in the 1980s and 1990s and still works exactly this way today.

What’s important is that the provisioning to that ALI database is again legacy, typically flat file transfers, daily deltas, something called standard order input files that are not real time provisioning. This is the one fallback of the legacy 911 system. You can’t just turn on a phone, plug it in, dial 911 and expect the call to work, it takes time.

National “Regional” 911 Network

Stepping forward, observe that it is a national network. There are roughly 500 or more selective routers in the nation. There are approximately 6,000 911 call centers. They’re called Public Safety Answering Points and it truly is a nationwide 911 network, but I like to refer to this as a network with the lowercase and on the front of it.

In a, you know, in a network like a VoIP network or an internet, you can enter that network at any point and exit that network at any point. The selective routers that are here in the United States are not interconnected to one another or only in very rare circumstances are they interconnected to one another. So if you make a LEC based 911 call in an area, it cannot be transferred arbitrarily elsewhere.

That means if you’ve got a cloud surface that is depositing 911 calls into a particular, you know, jurisdictional area, they have no way of getting those calls to potentially the correct place where that cloud based call may be coming from.

To fix that, of course we have this i2 specification originally published in 2005/2006, re-published in 2010. We won’t have to get into a lot of details here. There’s like 250 pages of the specification, 19 contributing authors. There’s 12, functional elements, 11 interface points, but what we really want to focus on are three components, the ESGW, the VoIP Position Center, and the Location Information Center, and some of these are going to appear forward in the Next Gen context as well.

We’ll explain all of these inner call flow in a moment. You’re going to see the word gateway here, and again, I’m not getting too deep into the technology, but what a gateway does is it converts media from one form to another. The media, in this case, is voice and the Emergency Services Gateway for i2, converts VoIP media or voice to legacy circuit switch, what’s called TDM, or time division multiplex. Think old school dial tone type technology.

How VoIP Connects to Enhanced 911

So we have a gateway between our two networks that’s going to convert. The VoIP position center’s going to track our location so the call gets to the right place and the Location Information Server is going to act as our surrogate ALI.

Let’s take a look at the legacy LEC and the legacy 911. We need to get rid of a couple of things. We don’t need the old phone, we don’t need the LEC switch, we’re going to be putting in a cloud service. So we have a nice VoIP service provider box.

On the far left hand side, we have our VoIP position center and Location Information Service, and we also have this gateway. Note that the arrow going into the gateway is green. I’m using green to distinguish VoIP and I’m using orange, solid orange, to distinguish legacy telephony. All of the dotted lines are database transactions.

Again, a little foreshadowing in the Next Gen world, we’re going to get rid of as many of those dotted lines as possible because we want real information, address information, and similar information to flow with the call at call setup. So again, let’s follow the bouncing ball, a couple of more balls because there’s a couple more components here, but again, roughly in the center of the screen is a zero, which means provisioning.

We have to do some stuff at provisioning time. Now, what’s, what’s interesting, actually let me back up for just a moment, let’s identify one of the problems here, because that VoIP service can be anywhere, it’s going to have to know how to get a call from anywhere in the US to the correct selective router.

Think about this for just a moment. That means that a voice over service provider, think a little small mom and pop shop, that set up some service and has maybe a couple of thousand telephone subscribers across the US. They’ve done a good job on marketing, advertising, and maybe they’re getting some traction or providing some sort of specialty service.

In order for them to deliver 911 calls for those 1,000 or 2,000 subscribers, they would have to have a relationship with all 500 selective routers and have some sort of understanding of where all 6,000 of those public safety 911 call answering points are.

There is no small company that can do that and that is why this infrastructure, this i2 infrastructure, exists. It’s to solve that national routing problem. So again, at step zero, we’re going to provision telephone number, name, and address inside of that Location Information Server.

That address information is going to get geocoded. It’s going to be turned into routing information by the VoIP Position Center, and the VoIP Position Center’s going to do something very, very clever. It observes that, you know, mom and pop VoIP service provider has a telephone number in Tucson, Arizona.

It’s not going to take that address and put it into the Tucson, Arizona, ALI database, it’s going to do something smarter than that. It’s going to go: ‘I’ve got many customers who used that Tucson, Arizona, ALI database, what I’m going to do is, do a little calculation figuring out how many calls simultaneously I need to support nationally to Tucson, Arizona, and I’m going to put some keys, some empty shell record keys inside of that ALI database and use them when I need to, and train that ALI database that if it comes across one of the keys from one of my callers, it needs to come to me for address information.

So it’s a little bit of a interesting thing. That key incidentally, in i2, is called an emergency services query key. So let’s watch. Watch what happens as we go through the call, step one, two and three again, following the red balls.

Subscriber on the VoIP phone, dials 911, that VoIP switch, just like the LEC switch, doesn’t know what to do with that call except send it to the VoIP Position Center. It doesn’t need to know where all of the selective routers are. So it sends it to the VoIP Position Center.

Position Center says, “Oh, I remember this guy, he’s in Tucson, Arizona. I’m going to send him to this emergency services gateway, close to the Tucson, Arizona selective router and get that voice over IP call converted back to legacy circuit switch, that Tucson, Arizona selective router can understand”, that’s step three. “More importantly, I’m not going to pass the telephone number. I’m going to pass one of my Tucson keys for this call only and that call is going to now be presented over at the call taker and they’re going to observe an incoming 911 call.”

They’re going to observe it has a key which incidentally looks exactly like the phone number, but it’s an un-dialable phone number. While that call taker is saying, “what’s your emergency and can you confirm your location?” while that same dialogue is happening, at step four, that equipment at the PSAP is querying that Automatic Location Identity database, for information about this key.

The ALI is going, ‘I don’t know that key belongs over to that VoIP Position Center. I need to go get the information from there’, and the address for that subscriber in Tucson is presented dynamically and returned at step four or back along that double headed arrow to the call taker. From the 911 call takers perspective, nothing different happened than within normal Local Exchange Carriers 911 call. A number was presented, location was fetched, they were able to talk to the caller, determine the emergency, confirm location information, because they always do that verbally and then proceed with emergency dispatch if needed.

All right, so that’s how i2 works. Now, interestingly enough, folks, again on the far left hand side, VoIP service providers, they are connected to folks like Bandwidth and a couple of other i2 vendors and they just have to send us this, with the i2 provider, again, it’s a cloud service, so their cloud, or i2 service providers are cloud, don’t think in terms of a VPC per carrier, these are all cloud services.

The 911 traffic, as VoIP comes in over the Internet, hits the i2 cloud, and it converts quite literally to each selective router in its locale and presents through those keys, the proxy of the address in order to get the correct address each time, no matter where the VoIP provider or rather where the VoIP subscriber initiates that call from. They can be nomadic, wander around, provide new address information, and it’ll get to where it needs to go.

What is Changing: Next Generation 911

That’s all very cool. We now step forward and start to talk about Next Gen. Let’s cover a couple of very, very simple definitions of what Next Generation 911 is. It is the conversion of that landline network that TDM, Time Division Multiplex, circuit switch copper wire stuff to modern IP, internet protocol, modern VoIP call processing equipment.

We are going to look at those selective routers and replace them with IP switches. We’re going to look at those ALI databases, which are, you know, file transfer systems, table driven systems, and put in modern list technology that was developed for i2.

We’re going to be able to, because it’s now all voice over IP, but more importantly, it’s all session initiation protocol, SIP, in the end when you have an arbitrary endpoint to a telephone or soft phone, that end point when it is connected to the far end point across an entire IP at end to end network and including Next Gen, that 911 call taker because it’s a fully connected call voice isn’t the only thing that can traverse that call. Text can traverse that call, video can traverse that call, a photo can traverse that call and it would wind up at the same 911 call taker.

Unlike today, if I make a series of 911 calls, they will, you know, they could wind up at different call takers. If I had to pause in my call and try to send an email to that particular call taker, that’s a problem that’s called out of band communication. So the great promise of Next Gen 911 is all IP, all in band communications.

Alright? So what’s that look like?  Let’s go back to the Local Exchange Carrier picture that we’re familiar with. We said we were going to get rid of the selective router and the ALI database and introduce a modern LIS, Location Information Server to that Local Exchange Carrier. So we do that, we get rid of that equipment, and we introduce this Next Gen cloud, and now let’s take a little observation here.

I’ve got an orange arrow coming into this cloud and green arrow on the back end. I said that orange was circuits switch TDM and green is voice over IP. That creates a little bit of a problem because there is a conversion that’s needed. Well, that conversion is actually handled by something called a legacy network gateway, there’s that word gateway again, and it’s going to handle the conversion media.

Now, this is an important point for every VoIP service provider who’s listening to understand the paradigm shift that is happening here. In i2, it was the carrier’s responsibility or potentially the carrier through a vendor contract, to convert VoIP media to legacy circuit switch TDM, whether you did it yourself through a gateway that you bought and then installed or did this as a service through vendors like Bandwidth, it was ultimately on your dime.

What we have here now, is that the 911 call side is VoIP, and the LEC carrier side is TDM, but emergency services is taking on the burden of doing those media conversions. So what’s going to happen here in just a moment is that the VoIP service providers will be able to enter that blue Next Gen network natively, and be able to drop out your own gateway equipment, thereby reducing your costs.

We’re going to see that now, we’re going to do the Next Gen conversion. We’re going to get rid of the selective router and we’re going to get rid of that ALI database, and we are going to get rid of that emergency services gateway. This is going to be an all IP interconnection. That VoIP Position Center doesn’t really have an analog in Next Gen.

Some of its routing determination functions are in some other Next Gen components called BCRF LVF, but we’re not gonna get into that level of detail. You can just understand for the moment at mild simplifications that those functions are subsumed in the data that’s populated within that location information server.

So here we have the end result with, and now that I’m looking at, I see one small one small error, the orange arrow on the far side to the Public Safety Answering Point should actually be green, that should be an all IP network. The beauty here is that again, the 911 caller, it makes a call, it hits the VoIP switch. That VoIP switch is now going to dip its Location Information Server and pull up that address that’s associated with the user.

Instead of having to have that 911 call taker, go to some third party database through some other back door system to go get that location information, this is where that SIP PIDF-LO terminology comes in. Now SIP, session initiation protocol, that PIDF-LO object is going to carry the address natively and directly from that VoIP service provider through the Next Gen cloud all the way to the call taker so they can see a display on their screen without going to a third party database.

That’s a little bit past where we need to understand because what I’m going to do is break down some of that SIP PIDF-LO next and show you where new information elements or new degrees of freedom and how these things are provisioned gives you the opportunity to build some new services.

So at the end of the day, we have VoIP service providers on the left, 6,000 911 call centers on the right. As those Next Gen systems now replace selective router and ALI database, this is why at the very beginning of this Webinar when I said, punchline up front, you will observe that it is on the downstream side of the i2 provider that conversion support transitions need to be made in order to support those Next Gen pieces of infrastructure.

The VoIP service providers can continue to do their i2 techniques really for as long as they want or as long as their i2 provider is in business, I suppose. The i2 provider, Bandwidth, for example, takes care of those conversions. Now again, the benefit here is of course that some of the Next Gen capabilities in a SIP PIDF-LO, are tools now that the service provider can use and send them into that same blue cloud where you have a VPC and a LIS, and new infrastructure and services. All right, so that was a mouthful.

Let’s do a quick check. So we have NENA, the North American Emergency Number Association having published this i2 specification, using SIP, session initiation protocol, PIDF-LO, Presence Information Data Format for the technical folks. That is an HTTP, XML tag format. It includes a location object that location object can be an address, could be a latitude/longitude, could be a latitude/longitude and altitude, could be any type of location.

The Presence Information Data Format, don’t get too hung up on that, this was a piece of technology that was crafted way back in the beginning of a wireless roaming where phones have, you know, very expensive call plans. Roaming was expensive. You want it to control when and where you receive calls or potentially data messages. So the presence information came back to call service that said yes, he’s, he’s awake and able to take a call or, or maybe not, maybe send a voicemail.

That same presence information and ability to figure out where VoIP callers are in the network and how to serve them is really part of the same technology. We’re going to talk now about some specific building blocks.

One of the specific building blocks is that in the old school environment you had a rigidity between the telephone number, the name and the address, and those can now with SIP PIDF-LO all be dynamically provisioned at the point of the call. Again, it gives you some freedom, some flexibility to build a feature out of that in just a moment, geo routing, instead of having a table entry in an ALI database, or even a key entry in an ALI database.

Now we’re going to do georouting based on the location object that goes with the call, as the call traverses the network. I’m thinking geocoding as determining the x, y coordinates the latitude longitude, you know ‘x marks the spot’.

Somewhere in the US, and in this case, in the example that you’re looking at, x marks the spot in the state of North Carolina and little further inspection sees that it’s inside of Wake County, which is the yellow box that you see a little bit more closer inspection. You observe that it is within the red area, which is the polygon served by the a 911 call center for the city of Raleigh, North Carolina, where this webinar is being broadcast from. And so geo coding is to able to figure that out and figured out that that 911 call center in Raleigh is identified by a URI, think in terms of the same stuff that you type at the top of a browser, the universal resource indicator.

That universal resource indicator or URI represents the routing instructions for a VoIP call to get to a 911 person in the city of Raleigh who can then dispatch help. Last line on this slide is class of service. This is worth just a few seconds of description.

Because we have multiple types of location objects, addresses, latitude, longitude, maybe even a latitude and longitude with a circle representing the confidence that someone is within 50 meters or 75 meters of a point. That’s complex information. And what we’ve done within the standards within the working groups is developed class of service indicators to indicate what type of call in this case, VNOM stands for VoIP nomadic VMOB stands for VoIP mobile.

In the case of nomadic, when the Public Safety Answering Point receives a VoIP, nomadic call, they know that they’re going to look at some address information displayed on the screen as opposed to a VoIP mobile call where they would expect to see x, y coordinates or latitude longitude, to display that on the screen, so there’s always an indicator that assists the Public Safety Answering Point equipment and presenting this new SIP PIDF-Lo types of location information eventually to the caller.

New Building Blocks, Potential Features

We have just three or four more slides and we’re going to put it all together. Here we have a table representing the types of VoIP, you know, CLEC type services that you see today, a fixed service, a nomadic service, nomadic VoIP, and mobile VoIP.

What does Nex Gen do for these types of services? Well, on the fixed VoIP side, it used to be that you had these addresses that you had to stick in selective routers and ALI databases and that took a day or sometimes a week to provision.

Well, with SIP PIDF-LO, you’re taking those location objects and sending them natively with the call end to end across the internet or, it can also be close to BPC surfaces. Point is that, it’s instant provisioning. You don’t have to wait a day or a week for anybody to tell you that you got your data right, you cleaned it up inside of the Next Gen, what’s called an LBF.

Again, we won’t get into that level of detail and with the clean location object, it goes end to end to the right place every time and you can change it dynamically. In fact, fixed VoIP service begins to look a lot like nomadic service where you have an expectation that your soft phone on a laptop could be at home, to be at your favorite coffee shop, could be taken to work, and nomadically moved from floor to floor in a building complex, or on a campus, and expect that your voice over IP service to work.

Again, new information elements on this second row are present. You can have a callback number that’s different than the telephone number of the VoIP provider or the TN, telephone number.

Why would you want to do that? Well, if you’re in a conference room with a better speaker phone than someone’s laptop that’s just about to lose its battery, you could include that callback number instead of the native call number of the mobile phone or the voice over IP phone. So there’s some interesting developments here for those of you familiar with PS ALI or Multiple Line Telephone Systems in terms of your local state public utilities commission is dissatisfied with a 20 building campus environment, where only the front gate address winds up in public safety.

They want the specific building, the specific floor, even if designation down to the cafeteria to be able to be presented to public safety. In this case, these SIP PIDF-LO and dynamic location objects can facilitate that type of rich, dynamic provisioning.

Last but not least on the mobile side, of course I’m going to take my soft phone and I’m going to put it onto my soft phone, goes on my smart phone. I’m going to have a universal communications experience and if I make a 911 call now from that device, what I want to have happen is not the address that was, you know, with that soft phone and my laptop. I want the latitude/longitude because I happen to be moving at that time.

Again, these techniques will allow you to make your CLEC in this particular case, VoIP provider, make your services more flexible. A couple of examples: Telematics, interesting opportunity. You have telematics, you have a vehicle, airbags go off and there is a call center that receives a call from that vehicle and it could be, you know, case A case B.

Case A, is the dad saying, “well, training my daughter how to drive the car and we kind of backed into the garage. There’s no emergency here, thanks for coming out.”

Or, case B where it is a, you know, some sort of a serious event and that telematics operator wants to escalate that particular communication with the car occupants to that of a 911 caller requesting an emergency services.

What’s important for you, the voice over IP carrier community or the CLEC community, cloud based communications is that these call centers, these telematics call centers, they have inbound telephony to have origination, termination, long distance, potentially messaging, and potentially connecting not just to cars now, but to a plethora of new devices on becoming sort of the Internet of things.

You have an opportunity, the CLEC community, to go after these folks as enterprises and say, “Hey, I’ve got an interesting x, y latitude/longitude routing capability that can be dynamic. Let’s talk about that and how about the rest of your business as well.

Step forward into home security, more kind of cool internet of things stuff here, where, suppose you go down to your Home Depot, you pick up a couple of wifi cameras as part of a home alarm system. You picked up some door sensors, you install that in your house, you put your smartphone app in play. You also put one in your aging father’s home or grandfather. You’d like to check up on them every now and again.

At some point you get an alert. You see that your cats on fire. Oh, that’s a problem. Or maybe you see that you’re father or grandfather, probably needs assistance. Well, if you are a business person out and about and possibly not even in your home city, and you make a 911 call at that point, traditional i1 and i2 telephony will have that call go to the wrong place. It will go to where your phone is, not to where help is required.

By using these SIP PIDF-LO techniques, you can actually inject the address of your home into the call flow and that call will go to the 911 call center in the jurisdictional vicinity of your home. You’ll talk to them even though you’re in Detroit, you know, I’m thinking of Raleigh as the example, but you get the idea.

Similarly, if your grandfather is in New York City and you are here, say again in Detroit, and that’s where his home is, you can still set it up using these PIDF-LO and dynamic location objects. We can still set it up that if you want to make the call on behalf of him, these techniques will allow you to do so. That’s an interesting service.

Again, from a CLEC perspective, home alarm companies, do it yourselfers. There’s an opportunity to take your telephony origination and termination messaging services and now dynamic 911 services and bundle them up for these new entrants who are talking to these new devices that are being placed onto the market.

Last but not least, I explained Multiple Line Telephone Systems. Again, in the legacy of terms it’s called PS ALI. This is a graphic of that same example, again, you can imagine that your soft phone is watching where you are moving from wifi access point to wifi access point.

You could have an administrator say it’s a university campus and administrator, take a look at their wifi network, take a look at their IP, hard port network, assign address information to where they know that this particular wifi access point is just for the cafeteria, and others for the 4th floor and others for the 5th floor, maybe another for the parking garage.

As your device wanders around, and a 911 call is made from the soft switch of that university, it can make note of the Mac address or the IP hardport address, and inject dynamically, the correct location object and eliminate all of the provisioning necessary for selective routers and the ALI databases.

On the right hand side of this picture, that call flow would pass through, now the Bandwidth cloud, and if it was going to a Next Gen network, the PIDF-LO would go natively to the Next Gen operator that’s at the top right hand corner of the screen. If however that call needed to go to a legacy system, Bandwidth’s service or any good i2 intermediary service, there’s several out there, would then take that SIP PIDF-LO and convert back to the key technique I described in the i2 sections.

It is fully true, the promise that was made is kept here, that the CLEC can do a little or a lot with these services. You could continue to use your i2 techniques and they’ll be translated to Next Gen or you can use SIP PIDF-LO and the intermediary, in this case Bandwidth, would convert them back to the legacy i2 if needed to complete a completely transparent set of services.

Alright, so thanks everybody for jumping on this webinar, and on behalf of the Bandwidth team, we wanted to thank you for coming out and listening to us and we hope you have a great day!

Learn More About Bandwidth 911