This is a continuation of the series on E9-1-1 within Skype4B Server and Lync Server. Today, we begin to take our emergency requirements and turn them into a logical configuration within Skype4B.
Skype4B Server LIS Network Requirements
Just when you thought that all the requirements were in place, there comes one more. Sorry…don’t shoot the messenger! We know from the previous post that we need to have two ERLs per floor but we also know that the client must send an identifying network attribute to LIS so that a single, definite location can be ascertained. Recall that there are multiple options for location recognition by the client (in order of most preferred to least preferred):
- BSSID MAC of Wi-Fi access point
- Switch port ID from LLDP-MED
- Switch Chassis ID from LLDP-MED
- Subnet
Using IP subnets to identify locations is by far the most simple solution but there are two other factors you must be extra aware of:
- You can’t use subnets if a single subnet spans two ERLs.
- You can’t use subnets if a single subnet exists in two separate physical locations.
Regarding issue #1
Take a look at the diagram below:
If you intend to use IP subnets for location recognition, you must ensure that an IP subnet does not leak outside the physical bounds of the defined ERL it is serving. Thus, an IP subnet used within ERL 2 must not be used for any client that may exist outside the physical bounds of ERL 2.
Regarding issue #2
This type of scenario tends to exist in medium to large organizations that have grown by acquisition. In that case, a single subnet (10.0.100.0/24) might be used at a site in the US and also within a site in the UK. To differentiate on the WAN and keep Layer 3 routing alive, network engineers use Network Address Translation (NAT) to ensure that traffic can route between the two locations. The major issue with this approach is that LIS is global so you cannot define two separate locations within LIS for a single subnet.
Note: It’s not that you can’t define two separate locations for a single subnet because you very much can. The issue is that you can only have one that is active. As soon as you create the second subnet & location, the first location becomes inactive and thus completely negates E9-1-1 location information you had previously entered.
Additionally, the client sends the distinguishing subnet ID to LIS WS within the web service communication, so the fact that a NAT is in place is completely irrelevant – NAT will change the SrcIP on the Layer 3 traffic between client and server but it doesn’t change the information within the web services request.
Workarounds
With the two caveats above in mind, you have two options to get around these issues:
- Utilize unique IP subnets within each ERL and ensure IP subnets are unique across all sites, OR…
- Utilize the switch port ID or switch MAC address to identify the ERL and don’t use subnets
Note: You could technically use Option 2 and forgo Option 1 and identify ERLs by switch information, but the shared-subnet-uniqueness will still be a problem for you if not remediated. Fixing that problem is painful and hard work to accomplish, but the rewards are plentiful because it removes other configuration blockers that arise for Skype4B/Lync when subnet-uniqueness is not available. As an aside – IPv6 doesn’t allow that kind of shared-subnet-uniqueness anyway, so network engineers should not be fighting the inevitable (IMHO). Remember, resistance is futile.
It may not seem like a big deal but the whole goal of E9-1-1 is provide as accurate of location information as possible, so if you can’t ensure subnet uniqueness and subnet geofencing then you’ve broken E9-1-1. If you have unique IP subnets but can’t keep the subnet within the physical bounds of an ERL then enable LLDP and utilize option 2 above.
Note: You must utilize LLDP-MED on your switches for Option 2 above, as the Skype clients obtain that information from the LLDP-MED tags on the network. In addition, you must be using an IP Phone that supports it (LPE and qualified phones do) or a Windows OS that supports it (Windows 8.1 or above) if you are using soft phones only. An example of information available via LLDP is below.
noam-us-tn-accsw02# show lldp neighbors detail
Chassis id: 0019.2fa7.b28d
Port id: Gi0/13
Port Description: GigabitEthernet0/13
System Name: noam-us-tn-accsw01.widgets.com
System Description:
Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(44)SE, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Sat 05-Jan-08 00:15 by weiliu
Time remaining: 114 seconds
System Capabilities: B,R
Enabled Capabilities: B
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
10base-T(HD)
10base-T(FD)
100base-TX(HD)
100base-TX(FD)
1000baseT(HD)
1000baseT(FD)
Media Attachment Unit type: 16
---------------------------------------------
Total entries displayed: 1
For the purposes of our sample scenario, our network engineer can ensure that subnets are unique and isolated to the physical location of each ERL. Given that all requirements are in place, we can begin building the pieces of the solution.
Creating the LIS Components
First up is creating the subnet and access point information within LIS:
Set-CsLisSubnet -Subnet 10.7.100.0 -Description "" -Location "333-FL10-NW Wing" -CompanyName "6155551000;6155551001;6155551002" -HouseNumber "333" -HouseNumberSuffix "" -PreDirectional "" -StreetName "Commerce" -StreetSuffix "St" -PostDirectional "" -City "Nashville" -State "TN" -PostalCode "37021" -Country "US"
Set-CsLisSubnet -Subnet 10.7.101.0 -Description "" -Location "333-FL10-SE Wing" -CompanyName "6155551003;6155551004;6155551005" -HouseNumber "333" -HouseNumberSuffix "" -PreDirectional "" -StreetName "Commerce" -StreetSuffix "St" -PostDirectional "" -City "Nashville" -State "TN" -PostalCode "37021" -Country "US"
Set-CsLisWirelessAccessPoint -Bssid 18-8b-9d-74-77-3f -Description "" -Location "333-FL10-NW Wing" -CompanyName "6155551000;6155551001;6155551002" -HouseNumber "333" -HouseNumberSuffix "" -PreDirectional "" -StreetName "Commerce" -StreetSuffix "St" -PostDirectional "" -City "Nashville" -State "TN" -PostalCode "37021" -Country "US"
Set-CsLisWirelessAccessPoint -Bssid 18-8b-9d-74-77-3b -Description "" -Location "333-FL10-SE Wing" -CompanyName "6155551003;6155551004;6155551005" -HouseNumber "333" -HouseNumberSuffix "" -PreDirectional "" -StreetName "Commerce" -StreetSuffix "St" -PostDirectional "" -City "Nashville" -State "TN" -PostalCode "37021" -Country "US"
A few important notes here:
‘Location’ Parameter
The ‘Location” field contains the specifics around your ERL. You are limited to 20 characters in this field, so arrive on a standard of how you will name this. Since this field is actually shown in the client, it is best not to make it so convoluted as to not potentially be helpful to end-users who may want to know where a certain person is by looking at their Skype4B Contact Card. I usually utilize “HouseNumber-Floor-Location” or “Building-Floor-Location” for mine. Examples:
- “333-FL10-STE 1001”
- “333-FL10-NW Wing”
- “333-FL2-RM 210”
- “BldgA-FL1-NW Wing”
- “Bldg10-FL1-RM 210”
Note: For pure SIP-trunk E9-1-1 scenarios, this information gets passed all the way to the PSAP operator. For that additional reason it is extremely important to use a clear naming standard. I recommend using USPS abbreviations to denote floors, wings, suites, etc, so that a PSAP operator has a clear understanding of where you are.
‘CompanyName’ Parameter
Are you using an Audiocodes gateway? If so, the CompanyName parameter should include the numbers that will be used as the ELINs. The gateways detect that information in the PIDF-LO data and use the numbers for outbound PS-ANI on outbound 9-1-1 calls.
Are you using a Sonus gateway? If so, the CompanyName parameter can be anything you want but will likely be your company name. Duh, right? Sonus gateways have ELINs defined within the gateways themselves, specifically in the Callback Table configuration, so there is no need to define it within Skype4B.
‘Subnet’ Parameter
The subnet ID must be the subnet as your DHCP server hands out to the clients. No supernetting allowed here. Be specific and no subnet mask required.
‘BSSID’ Parameter
The BSSID MAC address must be defined for all of your access points. You will typically see multiple MAC addresses for each AP, one for each frequency, BSSID name, etc. Make sure you obtain all Wi-FI MAC addresses from your network engineers and import them appropriately.
Other Parameters
You should use address information that matches the USPS delivery address, if at all possible. The USPS address lookup is closely linked to proper MSAG-validated addresses, so it helps to perform that due diligence.
Note: You’ll notice that no MSAG validation is performed as a part of these steps. For ISDN-based scenarios, it is not required. When we talk about SIP-based scenarios later on, it is required. Regardless, get the address information correct the first time you do this so you don’t have to go back and change things after MSAG validation.
Note: You’ll notice none of the address information changed between the pairs of subnet/BSSID parameters. Each BSSID and and subnet is mapped to a single physical location – the only difference being the ‘Location’ field between the two sets. This is critical to ensure that only a single location (ERL) is created within LIS and that each of the network elements maps to a single location.
Note: When you use the Set-CsLis cmdlets, if an existing location in the database doesn’t exist with the address information you’ve entered, a new location will be created automatically. This is by far the easiest way to enter LIS data.
Check your work!
Before moving any further, you need to check and make sure that LIS locations are correct!
Get-CsLisLocationet-CsLisSubnet
Get-CsLisWirelessAccessPoint
If the locations are correct within LIS, then you need to take the config and make it active:
Publish-CsLisConfiguration -Verbose
Creating the Voice Routing
In order for the 9-1-1 call to route outside of Skype4B Server, you need a voice route and a PSTN Usage. You could, in practice, go two major routes (pun intended):
- Create a single voice route and single PSTN usage for all your ERLs within the location, OR…
- Create a dedicated route and dedicated PSTN usage for each ERL within the location
The option you use generally depends on the routing requirements and/or gateway availability within your environment. I cannot give you a “do this to set up E9-1-1” answer that accurately covers all scenarios. In almost all cases there are various potential answers so it is up to you to decide what is appropriate given the requirements and gateway availability. In my fictitious scenario we will send all routes for multiple ERLs out to a single gateway:
#Create new PSTN Usage
Set-CsPSTNUsage -Identity global -Usage @{Add="US-TN-Nashville-333Commerce-Emergency"} -WarningAction:SilentlyContinue
#Create new voice route match for 911
New-CSVoiceRoute -Name "US-TN-Nashville-333Commerce-Emergency" -PSTNUsages "US-TN-Nashville-333Commerce-Emergency" -NumberPattern '^\+(911)
I won’t belabor the configuration of voice routing here, but just know that we should have a specific voice route AND specific PSTN usage that will be dedicated 100% to emergency calls. This usage and route should not be shared with <strong>any </strong>other type of outbound call from Skype4B. Additionally, we are enabling PIDF-LO support on the trunk out to our voice gateway so that Skype4B can pass the location data within SIP messaging to the gateway – this is required so that the gateway can perform ELIN functionality for us. After all is said and done, it ends up looking like this: <pre><a href=”https://ucvnext.org/wp-content/uploads/2016/02/Skype4B-E911-VoiceRoutingConfig.jpg” rel=”attachment wp-att-571″><img class=”aligncenter wp-image-571 size-full” src=”https://ucvnext.org/wp-content/uploads/2016/02/Skype4B-E911-VoiceRoutingConfig.jpg” alt=”Skype4B-E911-VoiceRoutingConfig” width=”990″ height=”448″></a></pre> <h3>Creating the Network Components</h3> Once you have routing configuration and LIS data populated there is another piece of topology that is required, and that is configuring the Skype4B Network Configuration. Many people get confused at this part because it seems foolish that you must separately tie LIS data into a network configuration, but it truly <span style=”text-decoration: underline;”>is required</span> to ensure that 9-1-1 call routing is defined to match only the physical network topology. <h4><strong>Create Network Subnets</strong></h4> Each subnet must be created within the network topology: <pre>
New-CsNetworkSubnet -Identity 10.7.100.0 -MaskBits 24
New-CsNetworkSubnet -Identity 10.7.101.0 -MaskBits 24
A few important notes here:
‘Identity’ & ‘MaskBits’ Parameter
The identity and mask bits must be the subnet and subnet mask as your DHCP server hands out to the clients. No supernetting allowed here.
Create Network Sites
A network site is analagous to an ERL within LIS but it is actually a completely separate entity within Skype4B Server. In my scenario I could do two things:
- Create a network site for each ERL, OR…
- Create a network site for each floor
The major restriction will be this: you apply a location policy (which defines E9-1-1 calling parameters) at the network site so if you need specific voice routing or specific IM notifications for each ERL, then you must ensure that network subnets don’t exist outside of the ERL boundary – this is required so that those subnets are contained within each network site you create within Option 1 above.
Note: This is another scenario where having non-unique subnets used in multiple sites causes issues. Network subnets are a global configuration in Skype4B so you can’t have a single subnet exist in two separate locations. While I’ve discussed mainly E9-1-1 impacts thus far, this problem also causes issues for things like CAC policies and P2P traffic flows. If this non uniqueness includes your current network topology, then a plan needs to be in place to begin migrating sites to unique subnets across the entire enterprise.
For my fictitious scenario, we have subnets contained within the physical bounds of the ERL, so we can utilize Option 1:
New-CsNetworkSite -Identity "333_FL10_NW Wing" -NetworkRegionID NOAM
New-CsNetworkSite -Identity "333_FL10_SE Wing" -NetworkRegionID NOAM
A few important notes here:
‘Identity’ Parameter
For easiest configuration, I set the identity parameter to be the same as the ERL name. Technically, it does not need to be the same, but I can tell you from experience that the administration becomes easier if you do so. Additionally, these network site names show up in the Monitoring Reports so it becomes a huge advantage to have detailed naming, especially for troubleshooting and performance reports.
Note: This is the only place where you cannot use a ‘-‘ in the identity. I do not know why, but it’s a huge pain in my naming schemes. I just switch to ‘_’ for network site names.
‘NetworkRegionID’ Parameter
You must already have a network region ID created in order to create a network site. I use ‘NOAM’ simply as an example for a previously created network region.
Create Location Policies
Location policies contain the specific configuration for E9-1-1 call behavior and routing within Skype4B. While there are many ways you could configure this, in practice I see it boiling down to two main methods:
- Create a location policy for each ERL and assign it to the corresponding network site, OR…
- Create a single location policy and assign to all applicable network sites, for example: per floor or per building
If you have requirements to have specific alerting or routing behaviors per ERL then use Option 1. In my fictitious scenario we don’t need unique settings for each of our ERLs within the floor, I can utilize Option 2 and configure a single location policy that covers the entire floor:
New-CsLocationPolicy -Identity "333-FL10" -EnhancedEmergencyServicesEnabled $TRUE -PSTNUsage "US-TN-Nashville-333Commerce-Emergency" -EmergencyDialMask "9911;112;999;000" -EmergencyDialString "911" -LocationRequired Disclaimer -NotificationUri "sip:[email protected]"
A few important notes here:
‘Identity’ Parameter
For easiest configuration, I typically set the identity parameter to be the same as the ERL name or as another identifier such as floor name or wing or building.
‘EnhancedEmergencyServicesEnabled’ Parameter
Many people get confused here and turn this off because they aren’t subscribing to an E9-1-1 service. In reality, you must have this turned on, even for simple purposes as using location information internally.
‘PSTNUsage’ Parameter
This is the usage we created earlier.
‘EmergencyDialMask’ Parameter
Many people also confuse the overall purpose of this parameter and include the logic within their dial plan normalization rules – that’s a huge ‘No-No’ in my opinion. The dial mask should include all the different ways someone may attempt to dial 9-1-1. For US residents it may be 9-1-1, or 9-9-1-1, but for others in the world it may be 1-1-2 or 9-9-9 or 0-0-0. Configure the most common values here.
Note: I never, EVER configure a dial plan normalization rule to match dialing emergency numbers, because it could allow normalization and outbound emergency call completion when location information may not be available, such as a call through Skype4B Mobile clients or external desktop clients. In the event one of those calls can be completed (mobile/external/etc) you can’t accurately control routing and location information recognition so you will have calls going to PSAPs with no information about where the caller physically is. Emergency calling configuration should be isolated to emergency calling components within Skype4B to ensure that physical location information is the only parameter that can be matched and utilized for all 9-1-1 calls.
‘EmergencyDialString’ Parameter
This is what the dial mask gets normalized into. In the US, it will simply be ‘911’ but in other countries it may be “112” or “999”, etc.
‘LocationRequired’ Parameter
I generally put ‘disclaimer’ here but it is up to your discretion. If the location information is configured correctly you never have to worry about this setting appearing to end users, but if you want users to see a warning within the Skype4B client when location information is not available, then configure this setting appropriately.
‘NotificationURI’ Parameter
This can be a user or e-mail distribution group of people who should receive an IM when an emergency call is made. Populate the group as required and put the name in the configuration field.
‘ConferenceURI’ and ‘ConferenceMode’ Parameters
The ‘ConferenceURI’ and ‘ConferenceMode’ settings do not apply when using ELIN gateways to integrate with ISDN circuits. You must use a SIP-based E9-1-1 service, such as 911Enable or RedSky, to take advantage of those settings. The reason being is that the SIP-based E9-1-1 service extracts the values from the PIDF-LO data and initiates the call on your behalf. ISDN has no capability to pass this information on the outbound call so it does not work there. Additionally, Skype4B server does not perform the call merging itself, so please don’t configure these two settings and wonder why it doesn’t work!
Connect the dots
With all components ready, you simply need to connect the dots by assigning subnets to your network sites and applying the location policy to the network site:
Set-CsNetworkSubnet -Identity 10.7.100.0 -MaskBits 24 -NetworkSite "333_FL10_NW Wing"
Set-CsNetworkSubnet -Identity 10.7.101.0 -MaskBits 24 -NetworkSite "333_FL10_SE Wing"
Set-CsNetworkSite -Identity "333_FL10_NW Wing" -RegionID NOAM -LocationPolicy "333-FL10"
Set-CsNetworkSite -Identity "333_FL10_SE Wing" -RegionID NOAM -LocationPolicy "333-FL10"
Network Subnets
Network Sites
Location Policy
With the LIS configuration in place, any time a client communicates with the LIS web services they will now receive proper location information. With the network & voice routing configuration in place, any 9-1-1 call will be routed correctly and send specific PIDF-LO information to our PSTN gateway for the purposes of 9-1-1 routing. So long as that gateway is a certified Skype4B device then we can use the native ELIN functionality to take the PIDF-LO data that will be passed from Skype4B and ensure that the gateway sends the dedicated PS-ANI on the outbound call across the ISDN-PRIs.
Wash, Rinse, Repeat
I’ve given a base configuration above, but you would need to implement the same type of configuration for every single ERL within the locations where you plan to deploy voice. Every subnet, every LIS location, every Wi-Fi AP, etc… Quite frankly, it’s a lot of work, but every piece needs to be accounted for to ensure that E9-1-1 is truly in place. Don’t miss something!
Wrapping Up
We’re not done, not quite yet, but we are awfully close. We have ensured that regardless where you go on that floor, your client will receive correct location data and that Skype4B Server will transmit that unique location data across the SIP trunk to the PSTN gateway. Stay tuned for the next post as we discuss what need to be communicated with your telco to ensure that all the work you’ve done is handled on their end as well!
-Description “Emergency routing for Nashville, TN – 333 Commerce” #Add PSTN Usage to voice route Set-CSVoiceRoute -Identity “US-TN-Nashville-333Commerce-Emergency” -PSTNGatewayList @{Add=”PstnGateway:noam-us-tn-nashSBC1.widgets.com”} #Alter trunk to enable PIDF-LO New-CsTrunkConfiguration -Identity “PstnGateway:noam-us-tn-nashSBC1.widgets.com” -EnableBypass $TRUE -EnablePIDFLOSupport $TRUE -ForwardCallHistory $TRUE -ForwardPAI $TRUE -SRTPMode Optional[/code]
I won’t belabor the configuration of voice routing here, but just know that we should have a specific voice route AND specific PSTN usage that will be dedicated 100% to emergency calls. This usage and route should not be shared with any other type of outbound call from Skype4B. Additionally, we are enabling PIDF-LO support on the trunk out to our voice gateway so that Skype4B can pass the location data within SIP messaging to the gateway – this is required so that the gateway can perform ELIN functionality for us. After all is said and done, it ends up looking like this:
Creating the Network Components
Once you have routing configuration and LIS data populated there is another piece of topology that is required, and that is configuring the Skype4B Network Configuration. Many people get confused at this part because it seems foolish that you must separately tie LIS data into a network configuration, but it truly is required to ensure that 9-1-1 call routing is defined to match only the physical network topology.
Create Network Subnets
Each subnet must be created within the network topology:
A few important notes here:
‘Identity’ & ‘MaskBits’ Parameter
The identity and mask bits must be the subnet and subnet mask as your DHCP server hands out to the clients. No supernetting allowed here.
Create Network Sites
A network site is analagous to an ERL within LIS but it is actually a completely separate entity within Skype4B Server. In my scenario I could do two things:
- Create a network site for each ERL, OR…
- Create a network site for each floor
The major restriction will be this: you apply a location policy (which defines E9-1-1 calling parameters) at the network site so if you need specific voice routing or specific IM notifications for each ERL, then you must ensure that network subnets don’t exist outside of the ERL boundary – this is required so that those subnets are contained within each network site you create within Option 1 above.
Note: This is another scenario where having non-unique subnets used in multiple sites causes issues. Network subnets are a global configuration in Skype4B so you can’t have a single subnet exist in two separate locations. While I’ve discussed mainly E9-1-1 impacts thus far, this problem also causes issues for things like CAC policies and P2P traffic flows. If this non uniqueness includes your current network topology, then a plan needs to be in place to begin migrating sites to unique subnets across the entire enterprise.
For my fictitious scenario, we have subnets contained within the physical bounds of the ERL, so we can utilize Option 1:
A few important notes here:
‘Identity’ Parameter
For easiest configuration, I set the identity parameter to be the same as the ERL name. Technically, it does not need to be the same, but I can tell you from experience that the administration becomes easier if you do so. Additionally, these network site names show up in the Monitoring Reports so it becomes a huge advantage to have detailed naming, especially for troubleshooting and performance reports.
Note: This is the only place where you cannot use a ‘-‘ in the identity. I do not know why, but it’s a huge pain in my naming schemes. I just switch to ‘_’ for network site names.
‘NetworkRegionID’ Parameter
You must already have a network region ID created in order to create a network site. I use ‘NOAM’ simply as an example for a previously created network region.
Create Location Policies
Location policies contain the specific configuration for E9-1-1 call behavior and routing within Skype4B. While there are many ways you could configure this, in practice I see it boiling down to two main methods:
- Create a location policy for each ERL and assign it to the corresponding network site, OR…
- Create a single location policy and assign to all applicable network sites, for example: per floor or per building
If you have requirements to have specific alerting or routing behaviors per ERL then use Option 1. In my fictitious scenario we don’t need unique settings for each of our ERLs within the floor, I can utilize Option 2 and configure a single location policy that covers the entire floor:
A few important notes here:
‘Identity’ Parameter
For easiest configuration, I typically set the identity parameter to be the same as the ERL name or as another identifier such as floor name or wing or building.
‘EnhancedEmergencyServicesEnabled’ Parameter
Many people get confused here and turn this off because they aren’t subscribing to an E9-1-1 service. In reality, you must have this turned on, even for simple purposes as using location information internally.
‘PSTNUsage’ Parameter
This is the usage we created earlier.
‘EmergencyDialMask’ Parameter
Many people also confuse the overall purpose of this parameter and include the logic within their dial plan normalization rules – that’s a huge ‘No-No’ in my opinion. The dial mask should include all the different ways someone may attempt to dial 9-1-1. For US residents it may be 9-1-1, or 9-9-1-1, but for others in the world it may be 1-1-2 or 9-9-9 or 0-0-0. Configure the most common values here.
Note: I never, EVER configure a dial plan normalization rule to match dialing emergency numbers, because it could allow normalization and outbound emergency call completion when location information may not be available, such as a call through Skype4B Mobile clients or external desktop clients. In the event one of those calls can be completed (mobile/external/etc) you can’t accurately control routing and location information recognition so you will have calls going to PSAPs with no information about where the caller physically is. Emergency calling configuration should be isolated to emergency calling components within Skype4B to ensure that physical location information is the only parameter that can be matched and utilized for all 9-1-1 calls.
‘EmergencyDialString’ Parameter
This is what the dial mask gets normalized into. In the US, it will simply be ‘911’ but in other countries it may be “112” or “999”, etc.
‘LocationRequired’ Parameter
I generally put ‘disclaimer’ here but it is up to your discretion. If the location information is configured correctly you never have to worry about this setting appearing to end users, but if you want users to see a warning within the Skype4B client when location information is not available, then configure this setting appropriately.
‘NotificationURI’ Parameter
This can be a user or e-mail distribution group of people who should receive an IM when an emergency call is made. Populate the group as required and put the name in the configuration field.
‘ConferenceURI’ and ‘ConferenceMode’ Parameters
The ‘ConferenceURI’ and ‘ConferenceMode’ settings do not apply when using ELIN gateways to integrate with ISDN circuits. You must use a SIP-based E9-1-1 service, such as 911Enable or RedSky, to take advantage of those settings. The reason being is that the SIP-based E9-1-1 service extracts the values from the PIDF-LO data and initiates the call on your behalf. ISDN has no capability to pass this information on the outbound call so it does not work there. Additionally, Skype4B server does not perform the call merging itself, so please don’t configure these two settings and wonder why it doesn’t work!
Connect the dots
With all components ready, you simply need to connect the dots by assigning subnets to your network sites and applying the location policy to the network site:
With the LIS configuration in place, any time a client communicates with the LIS web services they will now receive proper location information. With the network & voice routing configuration in place, any 9-1-1 call will be routed correctly and send specific PIDF-LO information to our PSTN gateway for the purposes of 9-1-1 routing. So long as that gateway is a certified Skype4B device then we can use the native ELIN functionality to take the PIDF-LO data that will be passed from Skype4B and ensure that the gateway sends the dedicated PS-ANI on the outbound call across the ISDN-PRIs.
Wash, Rinse, Repeat
I’ve given a base configuration above, but you would need to implement the same type of configuration for every single ERL within the locations where you plan to deploy voice. Every subnet, every LIS location, every Wi-Fi AP, etc… Quite frankly, it’s a lot of work, but every piece needs to be accounted for to ensure that E9-1-1 is truly in place. Don’t miss something!
Wrapping Up
We’re not done, not quite yet, but we are awfully close. We have ensured that regardless where you go on that floor, your client will receive correct location data and that Skype4B Server will transmit that unique location data across the SIP trunk to the PSTN gateway. Stay tuned for the next post as we discuss what need to be communicated with your telco to ensure that all the work you’ve done is handled on their end as well!
Success Code - 0, Successful on 1 agents
Sophos_Detoured_x64.dll
