This is a continuation of the series on E9-1-1 within Skype4B Server and Lync Server. Today, we begin to take some concepts and structure them around the capabilities provided within Skype4B.
Skype4B Server Location Information Service
All location-recognition functionality is provided through the Location Information Service (LIS) within Skype4B Server 2015. At a high level, LIS is comprised of two major components:
- LIS Database
- LIS Web Services
LIS Database
The LIS database is used to house all the information about your network, physical office information and ERL information. It is used to store a ‘network map’ that maps physical network elements, such as an IP subnet, or wireless access point MAC address, or switch MAC address or switch port ID, to a physical location.
Each configured location within the LIS database is comprised of two major pieces of information:
- ERL Name
- Civic Address
Note: While I show them separately above, the two objects are actually not separate at all. To define a location within LIS, you must define both, and all within a single PowerShell cmdlet.
The “ERL name” above corresponds to the “Location” field within the LIS location parameters. The civic address information is just like any other mailing address info we are used to seeing. When you combine the two together, you get something very specific, such as:
| LIS Field | LIS Location |
| Location | 333-FL10-NW Wing |
| CompanyName | Widgets, Inc |
| HouseNumber | 333 |
| HouseNumberSuffix | |
| PreDirectional | |
| StreetName | Commerce |
| StreetSuffix | St |
| PostDirectional | |
| City | Nashville |
| State | TN |
| PostalCode | 37201 |
| Country | US |
So in essence, the entire table entry above is a single location, or ERL, within LIS. Any number of network elements could tie you into the location above. If multiple ERLs are required within a single site (such as a single building with multiple floors), you will have multiple locations within the LIS database (or multiple tables such as above) and the only distinguishing difference between them will be the value configured in the ‘Location’ field.
LIS Web Services
The LIS web services (LIS WS) serve as a conduit for clients and phones to query the LIS database to determine where they are.
Note: Mobility clients are not included. In fact, they don’t support getting location information from LIS at all. This is primarily a server architecture limitation because LIS WS only works on the internal IIS website and not the external IIS website, which is where mobility clients (even when physically internal) work from.
After a client has successfully registered to a front end pool (steps 1 & 2), it asks LIS web services “where am I?” (steps 3 & 4):
As part of the LIS web service query, the client provides LIS with one of the identifying network attributes it knows about its current network whereabouts, such as a currently connected Wi-Fi access point MAC address, or subnet, or switch MAC address, or switchport ID. An important note is that there is a preference or precedence of network objects that the clients use when communicating with LIS WS. In order of most preferred to least preferred:
- BSSID MAC of Wi-Fi access point
- Switch port ID from LLDP-MED
- Note: Not available unless you use LLDP on your switches!
- Switch Chassis ID from LLDP-MED
- Note: Not available unless you use LLDP on your switches!
- Subnet
Thus, if all values are present, the client will send the BSSID MAC within the LIS web services request. If BSSID MAC is not present but the remainder of the values are present, the client will send the switch port ID within the LIS web services request… and so on and so forth. Bottom line: the client sends the distinguishing value to LIS web services so that LIS can look up that value in the database and then return the location information to the client. When the location information is returned, only the ‘Location’ parameter information (or ERL) is displayed within the Skype4B client:
All other location information is cached within the Skype4B/Lync application itself and only transmitted to the registrar server via SIP/PIDF-LO when an emergency call is actually made.
Now that you understand the framework of location services within Skype4B and Lync, you need to understand what dictates the design of that framework…
Letter of the Law
It seems that we can’t escape regulations within our lives these days and E9-1-1 is no different. While you can wax poetic about the technical capabilities of a communications solution, the reality you must understand is that the E9-1-1 configuration within Skype4B (and any other communications platform) is completely dependent upon the exact legal/regulatory requirements that may apply to the physical office location. The most common requirements boil down to:
- How do you define your ERLs?
- Per civic address (assuming a single building)?
- Per building (assuming multiple buildings at a single civic address)?
- Per floor within each building?
- A certain number of square feet per floor within each building?
- Per suite number?
- Per office number?
- Other?
- What are callback requirements?
Hands down, the best public resource for determining E9-1-1 requirements for each state within the US are these two resources:
RedSky’s website is a bit more friendly and contains excerpts of each state’s requirements and is often the best place to start in understanding what state legislation may exist, whereas 911Enable includes a small snippet of each state’s requirements, as they exist on the individual state’s website, and isn’t quite as easy to read. Regardless of the site you use, you need to do more homework though, and find out what local legislation may exist in addition to any national/state requirements. Some cities may have their own E9-1-1 requirements that aren’t captured within the website’s analysis, so it is important to perform due diligence beyond what RedySky and 911Enable have. Many times it is impossible for IT engineers to know the available resources to find out these national/state/local regulations, so plan on getting HR and Legal involved early on. Once they are involved…hold on for the wild ride.
Internal Politics
The HR and legal meetings tend to be the most difficult aspect of any internal or external E9-1-1 discussions, as it often involves folks that aren’t technical and don’t understand the core concepts and difficulties of E9-1-1. Regardless of the difficulty, pain and frustration endured, don’t give up on this. Continue pressing for answers and firm, official decisions. Get all parties to understand the problem, discover all requirements, discuss potential solutions and accept a design that meets the internal and external needs . Bottom line, you need to get universal agreement on the following items:
- Are the state requirements for emergency location identification (ERL) sufficient?
- Do they match the expectation of safety/security that HR and legal are willing to sign off on for employees?
- Are more specific emergency location identification (ERLs) required, above and beyond what the state requires?
- If the state/city requires none, does the company want to provide something better?
- What is the life safety plan and how does E9-1-1 fit in?
- How will this new E9-1-1 system fit in to existing policies and procedures around handling emergencies?
- How does the life safety plan handle multiple emergencies within a single emergency location?
- How does the life safety plan handle off-hours emergencies?
- Are notifications needed to alert employees and/or non-employees of an emergency?
- How do analog phones, such as elevator phones, fit in?
- Are any additional services or solutions required to meet any of the policy needs?
Until you have almost all of those questions answered, it becomes nearly impossible to architect a technical solution to fit the policy requirements. Once you do have all the questions answered, you can easily implement the requirements within Skype4B.
The Scenario
Going back to the scenario from my first post, assume we’re back at the same office building. Each floor is laid out in this general fashion:
After discussions with HR and legal, the determination has been made that the following E9-1-1 support must be provided for:
- Unique emergency location per 10,000 sq ft per floor
- Each emergency location must be able to support a maximum of 3 emergency calls
- Each emergency call must provide the correct emergency location so that emergency responders can quickly search an area
- Each emergency call must provide an instant message alert to a group of users that contains the location of the emergency and the caller
- To ensure E9-1-1 capabilities with the telephone company, each emergency call must use the right ELIN/PS-ALI based on the caller’s physical location
Given that we have the requirements above, we can state the following as technical requirements:
- We require two ERLs (and thus two LIS locations) per floor
- NW Wing and SE Wing
- We require 3 ELINs per ERL
- We require that location information is populated within LIS and proper configuration within Skype4B to ensure that all calls contain the proper ERL of the location of the caller
- We require a unique IM notification configuration per floor
- We require a PSTN gateway that supports ELIN functionality to send the appropriate PS-ALI
Wrapping Up
Now that we have policy decisions in place, the next steps are to take these configuration values and implement within Skype4B. The configuration of E9-1-1 will include items such as configuring the LIS database, configuring network sites, and enabling location policies. Stay tuned for the next post on those topics!