Emergency Calling — Campus Responsibilities
What the law requires, who does what, and what your campus must keep current
|
Status — program validation required before publication
The legal summary in section 1, the New York location standard in section 4, and the items marked pending in section 5 are awaiting formal confirmation by SUNY. This document is complete and usable as a working draft for design and planning. It should not be issued as final campus guidance, and no campus sign-off should be sought, until that confirmation is recorded.
|
|
How the program and your campus work together on this
The program provides the platform, the carrier path and the configuration work. What it cannot provide is knowledge of where a caller is standing — that comes from address and network data held locally, and from a small number of decisions each campus makes for itself. This page sets out both halves so you can see what is already handled and what needs you.
|
1. What the law requires
A plain-language summary for planning purposes. It is not legal advice, and the wording is pending review by SUNY counsel. Where a campus needs a definitive interpretation, raise it through the program.
| Requirement |
What it means here |
Kari’s Law
systems after Feb 2020 |
911 must dial direct, with no prefix, from every endpoint.
The call must carry a callback number that reaches the caller.
Someone on campus must be notified automatically when a 911 call is placed. |
RAY BAUM’S Act
systems after Jan 2022 |
The call must carry a dispatchable location (e.g. has to be more precise than main campus's address, should be as accurate as technically feasible)
This applies to off-premise devices as well: laptops and mobiles used off campus. |
SUNY campuses began implementing in 2023, so both apply in full. A correct street address on its own does not meet them, and neither does a configuration that was accurate at go-live — the detail needs to stay current as the estate changes.
Back to contents
2. Who does what
Every row has an owner. Where a row names the campus, the data or the decision sits locally and the program cannot complete it on your behalf — but it can advise on any of them.
| Task |
SUNY System Administration |
AudioCodes |
Campus |
| Decide how many emergency response locations, and where their boundaries fall |
Advises on approach |
Configures what is supplied |
Decides the threshold and records it |
| Supply the civic address for each location |
Advises on format |
Enters it as supplied |
Holds the data and confirms it |
| Map the network to those locations — subnets, wireless access points, switch ports |
Advises |
Subnet level, per the statement of work |
Supplies the mapping; port-level detail is campus |
| Supply every public internet address the campus presents — IPv4 and IPv6 — for the tenant trusted IP list |
Advises |
Enters what is supplied |
Network team supplies the full list and keeps it current |
| Enable LLDP so switch and port detection works — native on Windows 10 and later; Mac needs LLDP enablement software |
— |
Advises |
Campus desktop management |
| Set the emergency calling policy, the notification target and the notification mode |
Advises |
Applies the configuration |
Names the target and chooses the mode |
| Analog life-safety devices — elevators, blue lights, alarm panels, fax — on managed analog gateways |
Contracts the gateways and per-port service on the PIA |
Deploys, configures and monitors the gateways; sets a static emergency address and callback number per port |
Inventories the devices and locations, provides cabling and power at gateway sites, decides which devices must survive a network outage |
| Confirm PIDF-LO is enabled on the PSTN gateway object |
Verifies across the platform |
Platform side |
Confirm at commissioning |
| Run a 933 test for each location and check the address read back |
— |
Supports during implementation |
Runs it and records the result |
| Keep the above current as buildings, moves and networks change |
Reminds at review points |
Reconfigures on request |
Holds the data and the review cycle |
| Route the emergency call to the correct answering point |
Contracts the path |
Delivers via Spectrotel and IntelePeer |
— |
|
Plan for the size of your estate early
AudioCodes’ professional services configure up to 50 emergency response locations across up to 10 buildings, at subnet level, working alongside your team — that is the teaching case. The method is handed over as part of the implementation, and your campus configures the remaining locations itself in the Teams admin center, with AudioCodes advising. It is a scope line for the services, not a limit on the platform. Know your total count early so the handover is planned into the project rather than discovered at the end.
|
Back to contents
3. Seven things worth knowing before go-live
| Most campuses have no local survivability |
Trunking is centralized through Albany and Buffalo, so where a campus has no Survivable Branch Appliance a wide-area network failure takes Teams endpoints off the emergency network. Twenty-one of the twenty-eight campuses are in that position today. Mobile phones are the documented fallback; write that down and tell staff, so the answer exists before it is needed. The program can advise on survivability options. |
| The web client and VDI have no dynamic location |
Dynamic emergency calling works on the desktop, mobile, Teams Room and Phone clients. It is not available in the web client, so the playbook’s general rule to test there first does not apply to 911 or 933 — use a desktop or mobile client instead. If your campus delivers Teams through VDI, raise it with the program early. |
| Subnet mapping only works from a trusted IP |
Before Teams looks up a location by subnet, it checks whether the client’s public internet address is on the tenant’s trusted IP list. If the campus egresses through an address that is not listed — a second ISP, a new firewall, an IPv6 path nobody thought to record — subnet-mapped locations silently stop matching and the call is screened instead of going straight to the answering point. Every public address the campus presents, IPv4 and IPv6, has to be on the list and stay on it. Wireless access point and switch-port matches do not depend on the trusted IP list. |
| The client matches in a fixed order |
Wireless access point first, then switch and port, then switch, then subnet — the first match wins. A 933 test that reads back the wrong building is usually a stale or mistyped access point or switch entry beating a correct subnet, not a subnet error. Check in that order. |
| Direct to the answering point, or screened first |
A location the platform determined from your network data goes straight to the public safety answering point. A location the caller typed in or confirmed, a static address assigned to a number, or no location at all goes to a screening center first, which confirms the address with the caller and transfers. Screening costs time. That is the practical reason to get network mapping right and to keep static numbers to the devices that need them. |
| Location refreshes quickly; tenant settings do not |
The desktop client re-checks its location at sign-in, whenever the network changes, and on a short polling cycle — a wrong address on a 933 test is more likely a mapping or trusted IP problem than a stale client. Tenant-level changes are the slow part: new trusted IPs, network sites and subnets take up to two hours to take effect. Do not conclude a change has failed before that window has passed — and report a wrong address the same day either way, since it is treated as urgent until it is explained. [Timing being confirmed with AudioCodes; this replaces the earlier eight-hour cache statement.] |
| Working from home is a policy, not a setting |
Off campus, Teams has no network data to match, so it asks the operating system for a location and asks the user to confirm an address. That requires the user to have allowed Teams to use location services — campus device management can enforce it — and it only works on the Windows and Mac desktop apps; Teams phones do not support it and the mobile app detects but does not let the user enter an address. The campus decides whether staff working from home should dial 911 from Teams at all or use a mobile phone, and tells them. Record that in section 4. |
Back to contents
4. Decisions your campus must record
These are choices rather than configuration, so they are yours to make. Record them here with a name and a date, and return this section to the program — it becomes your campus’s reference point and helps the program support you consistently.
| Decision |
Campus answer |
| Emergency response location threshold adopted |
per building / per floor / per [n] sq ft — [record it] |
| Who is notified when 911 is dialed |
University Police / campus dispatch / other — [name the target] |
| Notification target per site, if the campus has more than one |
[site → target] — a satellite campus with its own dispatch can be notified separately by network site; leave blank if one target covers everything |
| Notification mode |
notification only / conference muted / conference unmuted |
| Emergency location reminder shown to users |
on / off — the banner that asks users to review their emergency location on the Calls page |
| Who maintains location data and the trusted IP list, and how often they are reviewed |
[name, title] • reviewed [monthly / quarterly] |
| Fallback policy during a network outage |
[how staff are told to call 911 when Teams is unavailable] |
| Staff working from home or off campus |
dial 911 from Teams with a confirmed address / use a mobile phone — [choose one, and name who pushes the Teams location permission and tells staff] |
| Life-safety devices that must keep working through a network outage, and how |
[device or group → SBA at this campus / retained analog line / cellular gateway] — everything else rides the managed analog gateways; see section 6; the tracker holds the owner and date |
Back to contents
5. Where the line sits
Section 2 sets out the confirmed operational responsibilities. The items below sit with the program rather than the campus. Those marked pending are being formally confirmed and will be reissued with this document — no campus action is required on them.
| Item |
Position |
Status |
| Emergency call routing path |
Contracted and operated by the program through Spectrotel and its underlying carrier. |
Confirmed |
| Professional services scope for locations |
AudioCodes configures up to 50 response locations across 10 buildings at subnet level, with the campus, and hands over the method; the campus configures the rest. Not a platform limit. |
Confirmed |
| Platform location settings |
Configured and verified by the program across the estate. Campuses do not set them. |
Validation in progress |
| Location granularity for New York |
Being confirmed centrally so the same standard applies at every campus. |
Pending |
| 933 behavior on this platform |
Being confirmed with the carrier. If a 933 call does not behave as this page describes, report it. |
Pending |
| Client location refresh timing |
Section 3 now reflects AudioCodes’ description (re-check at sign-in, on network change and on a short poll; tenant settings up to two hours). Being confirmed in writing. |
Pending |
| Analog gateway behavior on network loss |
Being confirmed with AudioCodes: what a managed analog gateway does when the campus loses its wide-area connection, with and without an SBA, and any local fallback options. |
Pending |
| Campus acceptance model |
Whether this is issued as a responsibilities statement or as a signed acceptance. |
Pending |
Back to contents
6. Emergency devices outside Teams — the managed analog gateways
Elevator phones, blue light phones, alarm panels, fax lines and similar devices do not become Teams users, but they are part of the program. Each Participation Agreement carries a managed analog service: AudioCodes media gateways deployed on campus where the devices are, a one-time setup charge per gateway and a monthly charge per analog port, with the ports counting toward the campus’s calling capacity like any other line. The device stays analog; the gateway carries its calls over the campus network to the shared platform and out through the same carrier path as everything else.
|
What this means for emergency calling
A device on a managed gateway is a platform endpoint. Kari’s Law and RAY BAUM’S Act apply to it: each port that can dial 911 needs a callback number and a static dispatchable address, set by AudioCodes from the inventory the campus supplies. And because the gateway reaches the shared platform over the campus network and the wide-area link, a campus without a Survivable Branch Appliance loses those devices in a wide-area outage along with its Teams endpoints. That is the decision each campus has to make deliberately, device by device — not discover later.
|
| Path |
What it means |
Watch for |
| Managed analog gateway (the program default) |
The device connects to an AudioCodes gateway on campus; AudioCodes deploys, configures and monitors it as a program component. Priced per gateway and per port on the PIA. |
Cabling and power at the gateway location are campus. Static emergency address and callback number per port. Goes down with the campus network where there is no SBA. |
| Gateway plus Survivable Branch Appliance |
An SBA on campus keeps local calling — including gateway-connected devices — alive when the wide-area link fails. Priced monthly on the PIA; seven campuses have taken it. |
One appliance per campus site that needs it; confirm what stays up and what does not before relying on it. |
| Retained analog line |
Keep a specific device on a carrier analog line, outside the platform, where the carrier still offers one. |
Rising cost and retirement notices; the carrier decides when this ends. Confirm the emergency address the carrier holds. |
| Cellular gateway |
A POTS-replacement gateway with its own cellular path and battery, for a device that must work through any network outage. |
Signal at the device location, battery run time, who monitors the gateway, and the address registered for the line. |
|
Four questions to answer for every device before the inventory closes
Which code or standard applies to it — elevator and fire codes typically require monitored two-way communication — and who is accountable for compliance. Who answers when it is used, and how that is monitored. Whether it must keep working when the campus network is down, and if so by which path above. What callback number and dispatchable address the answering point receives.
|
The device inventory in the readiness tracker is what sizes the gateways and ports on the Participation Agreement, so it needs to be complete before the PIA is finalized, and every device needs a named owner. The AudioCodes Dynamic Emergency Calling overview indexed in the Campus Pack explains how Teams emergency calling works; AudioCodes has said it will extend it to cover these devices.
|
If anything here is unclear, ask
Emergency calling is the one area where the program would happily answer the same question twenty-eight times rather than have a campus work it out alone. Raise it through your voice administrator to the Shared Calling Services Program, or open it with the AudioCodes help desk if a configuration is already live and behaving unexpectedly.
|
Back to contents