This is a continuation of the series on E9-1-1 within Skype4B Server and Lync Server. Today, we begin to look at configuration required for our PSTN Gateway and additional coordination required with our telco.
In our last post we had already ensured that LIS data was available and that calls would get routed to our PSTN gateway. At this point we need to ensure that the PSTN gateway correctly handles the PIDF-LO data and performs ELIN functionality so that it sends a specific PS-ANI for the outbound 9-1-1 call. This can be a complex topic, sadly, but I’ll try to offer some insight for two of the most common PSTN gateway vendors: Audiococdes and Sonus.
Note: I will not give detailed how-to’s about creating a routing configuration within your gateway. This will be specific to ELIN configuration only!
Enabling ELIN functionality on Audiocodes gateways is very, very simple. The specific location of this menu item may vary a little bit given the different hardware platforms Audiocodes has but the settings you need to enable are here:
Advanced SIP Parameters
Under the E911 Gateway setting, make sure that ‘NG911 Callback Gateway’ is set. That setting turns on the ELIN gateway functionality within the Audiocodes device itself and can also be found within the .INI file configuration here:
[SIP Params] PLAYRBTONE2IP = 0 MEDIACHANNELS = 48 ISPROXYUSED = 1 PLAYRBTONE2TEL = 3 SECURECALLSFROMIP = 1 GWDEBUGLEVEL = 5 ;ISPRACKREQUIRED is hidden but has non-default value ENABLEEARLYMEDIA = 1 SIPGATEWAYNAME = 'noam-us-tn-sbc01.widgets.com' PROXYREDUNDANCYMODE = 1 SIPTRANSPORTTYPE = 1 TCPLOCALSIPPORT = 5061 TLSLOCALSIPPORT = 5061 LOCALISDNRBSOURCE = 1 PLAYRBTONE2TRUNK = 1 MEDIASECURITYBEHAVIOUR = 3 REDUNDANTROUTINGMODE = 2 SOURCENUMBERPREFERENCE = 'From' FORKINGHANDLINGMODE = 1 MSLDAPPRIMARYKEY = 'telephoneNumber' ENABLEEARLY183 = 1 FAKERETRYAFTER = 60 ENABLESYMMETRICMKI = 1 E911GATEWAY = 1 ENABLECALLTRANSFERUSINGREINVITES = 1 RESETSRTPSTATEUPONREKEY = 1 ENERGYDETECTORCMD = 587202560 ANSWERDETECTORCMD = 10485760 SYSLOGCPUPROTECTION = 0
Once the NG911 gateway feature is enabled within the configuration, there is very little left to be done with exception of making sure that a 9-1-1 call has an available route to an available ISDN circuit.
Note: NG911, or ELIN gateway functionality, is a licensed feature in the Audiocodes world, so make sure you have appropriate licensing on your gateways/SBCs to be able to use it!
E911 Callback Timeout
This setting defines how long the gateway leaves an outbound emergency call mapping in the callback table. The callback table matches the ELIN used on the call to the internal number/user that dialed 9-1-1 and is sometimes required by legislation so that a PSAP can reach the original caller in case the call gets unexpectedly dropped. By default it is set to 30, which means 30 minutes. I would expect few to edit this parameter, but you can change it to a different value if you so choose.
IP to Tel Routing
At a minimum you need a single route to match for the destination phone prefix (or the called number), which is ‘911’:
Dest. Host Prefix = * Source Host Prefix = * Dest. Phone Prefix = 911 Source Phone Prefix = * Source IP Address = * Trunk Group ID = 1 IP Profile ID = 1
Here you are simply matching for calls destined to “911” and telling the Audiocodes to send the call to a specific trunk group associated with your ISDN PRI trunk group. In my configuration shown above, I only have a single external trunk group ID so all calls get sent to the trunk group ID of ‘1’.
Final Audiocodes Note
Once the route and ELIN functionality is enabled, the Audiocodes gateway will read the PIDF-LO data sent by Skype4B/Lync and use the ‘CompanyName’ field for configuration data input. Remember that the ‘CompanyName’ field contains the ELINs you want to use for a given ERL, so the gateway simply accepts the values and uses those to generate the PS-ALI on the outbound ISDN call.
Note: You may need to tweak your Audiocodes manipulation rules for ANI/PS-ANI for your ISDN trunks to make sure that calls get sent with the appropriate calling party number information. Whatever you do, make sure that the correct (and correctly formatted) PS-ANI gets used – e.g: 10 digit number or 11 digit number.
The UX platform is a bit more involved in the configuration of ELIN functionality, but all things considered, it actually offers a bit more flexibility than what you can do with Audiocodes. The URLs below give Sonus’s opinion on setup so I’ll extol on what they have and clarify a few things:
You define which PIDF-LO attribute the gateway uses to determine location information within the MIME Payloads section. Using the ‘LOC’ field (Location field in LIS/PIDF-LO) is best practice here so long as you don’t have duplicate names of any ‘Location’ fields within LIS.
Bottom line: if each location in LIS unique, use the ‘LOC’ field. Otherwise use one of the alternative options (assuming those options in LIS are unique, as well).
You can turn this on but it actually won’t be utilized for ISDN calls. If you were using a SIP-based E9-1-1 service, you absolutely need this setting set to TRUE so that PIDF-LO data gets sent to the Selective Router in the E9-1-1 service.
Bottom line: turn this on for both ISDN and SIP based implementation.
Unknown Subtype Passthrough
You can turn this on but it actually won’t be utilized for ISDN calls. If you were using a SIP-based E9-1-1 service, you may need this setting set to TRUE, depending on the E9-1-1 service you are utilizing. As an aside, this setting may need to be tweaked to make sure that sufficient SIP elements are sent to your ITSP SIP trunks to prevent call setup failures.
Bottom line: you shouldn’t need this on, but you can turn on if desired or if testing dictates it must be on.
Callback Number Pool
A callback number pool is defined to configure ELINs for your ERLs. In our previous post we know that three ELINs per ERL are required, so in the Sonus gateway we would define two callback number pools each with three unique and non-overlapping numbers. The picture above shows an example of a single ERL with three ELINs.
I would strongly advise making the description the same name as your ERL. This simplifies administration and helps you maintain uniformity between Skype4B and Sonus.
Callback Numbers List
Enter the ELINs here. They can be in any order but just know that the first 9-1-1 call received for this particular ERL will use the first number in the table. The second call uses the second and so on.
Put simply, this is your emergency services number that you dial. For US customers it will be ‘911’. For other locales it may be ‘112’ or ‘999’. Match this number with the Emergency Dial String from your Skype4B location policy.
At a minimum you need two transformation rules to match:
- Called Address/Number= \911
- Input Field Type = ELIN Identifier
Transformation Rule One – Called Address/Number
Input Field Type = Called Address/Number Input Field Value = \911 Output Field Type = Called Address/Number Output Field Value = 911 Match Type = Mandatory
Note: Here you are simply matching for calls destined to “911” and telling Sonus to send the call to “911”. Do not use the configuration as shown in the picture above – make sure you create a rule that matches your outbound voice route in Skype4B to match the DNIS format (911 vs. +911).
Transformation Rule Two – ELIN Identifier
Input Field Type = ELIN Identifier Input Field Value = ERL location name E.g.: "333-FL10-NW Wing" Output Field Type = Callback Pool Identifier Output Field Value = Callback Pool Name E.g.: "333-FL10-NW Wing" Match Type = Mandatory
Note: Here we are matching for the ERL name within the PIDF-LO data. Once we find the name, we match that name to the callback number pool we previously configured. Do not use the configuration as shown in the picture – make sure you use the specific configuration outlined in the section above.
Call Routing Table
A call route table entry is required to get calls to search through a transformation table. The entry needs to be at the very top of the call routing table to ensure that 9-1-1 calls get the first preference. The call route entry simply needs to reference the transformation table where you created the ELIN matching rules.
Final Sonus Note
You need to have as many of the second transformation rule above as required for each of the ERLs you have defined! If you have 10 ERLs, then you will have 10 ELIN identifier matches to 10 indivudal callback number pools. 5 ERLs = 5 ELIN identifier matches. Etc…
Note: In previous UX versions there was a limitation on the total number of Callback Number Pools that could be created. For topologies that have centralized call routing for E9-1-1 or topologies with a large number of ERLs, this may be an issue for you. The last time I checked the limitation was 20, or 25…I can’t really remember as it has been a few years. This may alter your gateway planning/deployment strategy so be sure to check with Sonus for latest numbers!
This is the last step and unfortunately the most difficult piece because there is no good way for me to provide information for all the various LECs, C-LECs, and other telco providers out there. Additionally, many of the telcos have very poorly trained sales staff (and sales engineers) that don’t understand how E9-1-1 needs to work, so you often face an uphill battle in getting the correct information.
Note: I cannot tell you how many times I’ve spoken with telco engineers who know nothing about PS-ALI/PS-ANI or claim it isn’t available or claim it must be purchased separately. It is available and must be available since E9-1-1 is a requirement by law. Do not let them provide false info or “drop the ball” on E9-1-1!
Bottom line, make sure your sales engineers know that you are subject to E9-1-1 compliance and need to ensure the ability to utilize PS-ALI/PS-ANI services through their ISDN PRI circuits. As a result of that request, there may be some additional charges they pass along your way (sorry) but you need to make sure the telco has the following info in order to correctly set up E9-1-1 within their systems:
- What PS-ANIs are in use for each physical office location
- The specific PS-ALI data for each PS-ANI (ELIN)
Make sure the telco has the address data correctly populated within the PS-ALI database for each of the PS-ANI entries! Testing is worthless until you have confirmation that it has been completed!
Once you have confirmation that everything is in place, you MUST TEST! Contact your local non-emergency number and make them aware that you are testing a new telephony system and want to ensure that E9-1-1 is functioning correctly. Some locales may have you specify a date/time to begin testing the functionality, but the most important piece is to get the local government & PSAP involved to make sure you have all players alerted and all paperwork completed to ensure compliance.
Once all is in place, begin making calls and testing the ERL recognition across the campus, building, floors, etc. Test all your ERLs – perform due diligence to make sure that all necessary network components are being recognized before signing off and saying that “yes, things work”.
- Are your BSSIDs correct?
- Are your LLDP-MED items correct?
- Are subnets correct?
- Are PS-ANI being used correctly by the gateway?
- Does the PSAP operator receive the PS-ALI information?
Do not take anything for granted or assume anything works. Make sure you have concrete validation that E9-1-1 is working as you expect it!
We’ve made it! It was a long road and the work isn’t done. You will now need to maintain this configuration and update as appropriate as the network topology changes or as offices come and go. It is an ongoing work that is never complete so don’t become complacent with the responsibility!
This concludes the ISDN-related portion of this E9-1-1 series. What follows next is actually utilizing NG9-1-1 within Skype4B Server. Stay tuned!