SUNY SHARED CALLING SERVICES PROGRAM · MICROSOFT TEAMS TRACK

Frequently Asked Questions

Real questions from campuses and the program, with the answers as they were settled

Getting help

Something is broken. Who do I call — and does it matter that our project is still open?

It does not matter. Once a component is live and your authorized support contacts are registered, every service-impacting issue starts with an AudioCodes ticket — services.audiocodes.com or 800-735-4588, 24x7 — whether or not your implementation project has closed. AudioCodes triages and routes it, including to the carrier. You are never expected to work out whether an issue is “Day 1” or “Day 2” before reporting it.

Can I just email the project engineer I have been working with?

During implementation, yes — that is what the project team is for. But once the affected component is live, open a ticket even if you also tell the engineer. Email leaves no record and no clock; the ticket is the system of record, and during the ten working days after each cutover the project team is actively watching the queue.

Is SUNY System Administration a support line?

No. System Administration owns the program — contracts, governance, approvals — and is not staffed for technical support. Outages and call failures go to AudioCodes; number and billing matters go to Spectrotel through your voice administrator.

Spectrotel has two mailboxes. Which one do I use?

quotes@spectrotel.com places orders — activations, new numbers, ports, capacity changes — and takes the Port and Order Template with the SUNY approval. customercare@spectrotel.com handles support, billing questions, account changes and order status. Sending an order to customer care gets redirected and costs a day. The Spectrotel Request Templates document carries a ready-to-send email for each.

Porting numbers

How far ahead do we need to plan a port?

Thirty to forty-five days as the working rule — and treat holidays as dead time. A 73-number port requested about four weeks out, with Labor Day in the window and a key Spectrotel resource on vacation, drew an immediate caution from the port desk. Book the date early, and remember the number list freezes at submission: a change after that cancels the order and restarts the thirty days.

Some of our numbers are not actually in use. Can we still port them?

Not as they are — losing carriers reject inactive numbers, and it is one of the two most common rejection causes. The working fix, used at several campuses: point the unused numbers at something that answers before the port. SUNY Maritime mapped four inactive fax numbers to spare IP phones so they would ring; other campuses send them to a common voicemail. Either satisfies the losing carrier.

The other common rejection cause is an account mismatch — which is why every number is checked against the Customer Service Record before submission, and why the CSR is requested early.

Why do you keep asking for a fresh invoice and CSR?

Per port order, not per campus. The invoice must be no older than 31 days at submission, and the CSR is what the losing carrier validates the request against — numbers not listed on it get checked one by one before anything is submitted. On a recent order, one number on the template turned out not to belong to the campus at all; the CSR check caught it before the carrier could reject the whole order.

Who approves a port or activation, and how?

Every order that changes billing carries a SUNY Shared Calling Service Change Release Authorization, approved by John Green or Kevin Stillman replying “Approved” on the request email. The request also states the bundle math so the approver can see it — for example: currently 23 calling bundles, this adds 8, new total 31, within the 58 approved in the PIA. If the new total would exceed the PIA, the request says so in plain words: the reply-all “Approved” authorizes the order under the annual purchase order; it does not amend the PIA, which needs its own update. The authorization form itself is in the pack.

What actually happens to our order inside Spectrotel?

The request goes to quotes@ with the template, CSR, invoice and approval. Spectrotel creates the order and assigns it to Service Delivery Project Management (Ellen Burke), who releases it to the port desk at the right time. Order status is visible at nic.spectrotel.com, or via customercare@.

Caller ID and spam labeling

Our calls show as “Spam Likely” or “Scam Likely” after a port. Why?

Spam labeling is decided by the receiving carrier — Verizon, T-Mobile, AT&T — using their own analytics, not by anything on the platform. Updating the caller ID name (CNAM) does not typically clear a spam label; the two systems are separate. This has occurred at more than one campus following ports, so the program treats it as a known risk, not a surprise.

CNAM itself is submitted automatically to the national database as part of every port — once, by the carrier chain. No separate re-push is required, and Spectrotel and IntelePeer have confirmed a repeat push adds nothing.

So what do we actually do about spam labels?

Register the numbers with the three carriers’ analytics providers — the campus or AudioCodes does this, as the owner of the numbers; it is not something the carrier chain can do for you. One free registration at freecallerregistry.com reaches all three (Verizon/TNS, T-Mobile/First Orion, AT&T/Hiya); for a number already being labeled, go direct — voicespamfeedback.com, portal.firstorion.com, and Hiya’s review request form.

Give it up to thirty days. If a number is still labeled after removal, the affected recipients pursue it with their own carrier — and report it to the program, which escalates call examples through Spectrotel to IntelePeer to confirm outbound information is passing correctly. The step-by-step guide with links is document 15, Calls Marked as Spam After a Port.

What should we capture when someone reports a spam or caller ID problem?

Six things, per call: who reported it; the specific symptom (wrong name, spam label, call failed, busy); date and time; direction; both numbers in full; and the carrier of the far-end number. Without dated call examples the carriers will not investigate — this list is what Spectrotel’s service delivery team asks for verbatim.

Activating and changing numbers

We have parked numbers. Can I just assign one to a new hire in Teams?

No — a parked number has no calling and no emergency service, so assigning it in Teams produces a number that looks finished and does not work. Activation is two requests and one approval: the Port and Order Template to Spectrotel quotes@ (moves it to In-service and sets the e911 record — the address on the form is used for the 911 update), the SUNY approval in between, and the User List Template to AudioCodes so the number is configured on the platform. Then you assign it in Teams.

How is capacity charged when we activate numbers?

Calling capacity is bought in bundles that each cover ten active numbers, with unlimited local and long distance and e911 included. Activation is therefore a step, not a smooth per-number cost — activating one number can buy a whole bundle. Your PIA states the bundle ceiling your campus signed at; every activation request states where you stand against it.

Emergency calling

I work from home some days. Should I dial 911 from Teams?

That is your campus’s call to make, and it should be written down — the Emergency Calling responsibilities KB has a line for it. Off campus, Teams has no campus network data to match, so it asks your computer for a location and asks you to confirm an address under the dial pad. For that to work, Teams has to be allowed to use location services on your device, and it only works in the Windows and Mac desktop apps — not on a Teams phone, and the mobile app detects a location but does not let you type one in.

A confirmed address you typed yourself is routed through a screening center that checks it with you before transferring to the answering point, which takes a little longer than a call from campus. Many organizations tell remote staff to use a mobile phone for 911 for exactly that reason. Whichever your campus chooses, confirm your Teams location anyway — it is also what shows up to campus police if you do dial.

My 933 test read back the wrong building. What went wrong?

Report it the same day — a wrong address is treated as urgent until it is explained — and then check three things in order. First, the trusted IP list: Teams only looks up a location by subnet when your campus’s public internet address is on the tenant’s trusted list, so a new firewall, a second ISP or an IPv6 path nobody recorded makes subnet locations silently stop matching. Second, the match order: wireless access point beats switch and port, which beats switch, which beats subnet, and the first match wins — a mistyped or moved access point entry will override a correct subnet. Third, timing: changes to trusted IPs, network sites and subnets take up to two hours to take effect, so a test run five minutes after a change proves nothing yet.

The desktop client itself refreshes location at sign-in, on any network change and on a short polling cycle, so a stale client is the least likely explanation. Section 3 of the Emergency Calling document walks through all of this.

Our elevator phones, blue lights and alarm panels are on copper lines. Do they move to Teams?

They move to the program, not to Teams. Every Participation Agreement includes a managed analog service: AudioCodes media gateways installed on campus where the devices are, priced as a one-time setup per gateway and a monthly charge per port. The device stays analog and plugs into the gateway; the gateway carries its calls to the shared platform. The device inventory your campus builds in the readiness tracker is what sizes those gateways and ports, so it has to be complete before the PIA is finalized.

Two things to decide deliberately. First, a device on a gateway is a platform endpoint — it needs a callback number and a static emergency address, which AudioCodes sets from your inventory. Second, the gateway reaches the platform over the campus network, so at a campus without a Survivable Branch Appliance those devices go down in a wide-area outage along with Teams. For any device that must work through an outage — an elevator is the obvious case — the campus chooses an SBA, a retained analog line or a cellular gateway. Section 6 of the Emergency Calling document (04) lays out the paths and the four questions to answer per device.

The program

When the documents say “SUNY,” do they mean my campus?

No. “SUNY” alone always means SUNY System Administration — the program office in Albany. Your institution is always “the campus” or “your campus.” The two are never interchangeable in program documents.

Our whole migration will take most of a year. Is that normal?

Yes — it is the design, not a delay. Campuses port in phases, typically five to twelve port orders over six to twelve months, one losing carrier per order. Parts of your campus will be live and fully supported while others are still being planned. The readiness tracker’s Port Orders tab is how everyone stays oriented.

Who is Integritas, and what can they approve?

Integritas supports the program for SUNY System Administration — advising, assembling port packets, relaying documentation between campuses and vendors, and running the checks before an order is submitted. They approve nothing: every billing change is approved by SUNY, and every design decision belongs to SUNY or your campus.

Where do the official documents live, and how do I know mine is current?

The KB articles at sharedcalling.suny.edu are the authority — a document not listed there, or listed at a higher version than the copy you hold, has been superseded..