What “SIP Compatible” Actually Means
Session Initiation Protocol is a published open standard. It is not owned by a phone company, it is not licensed, and no vendor can prevent another vendor from implementing it. That single fact is why the question “will my handsets work” has a much better answer than most people expect.
When a desk phone registers to a cloud platform, a small and well-defined set of things happens. The phone announces itself and authenticates with a username, a password and a server address. The platform records where that extension can be reached. From then on, call setup, ringing, answering, hold, transfer and hang-up are all carried as SIP messages, and the audio itself runs over RTP using codecs that every manufacturer supports — G.711 for uncompressed clarity, G.722 for HD audio, and increasingly Opus.
The useful way to think about it
SIP is to phones roughly what SMTP is to email. Any mail client can talk to any mail server because the protocol is public. You would find it strange if changing email provider meant replacing every laptop in the building — and it is equally strange when a phone provider implies you must replace every handset. Sometimes there is a genuine reason. Often there is a hardware margin.
Now the honest half. SIP standardises calling. It does not standardise features. The things people actually judge a desk phone by — a wall of busy lamp keys showing who is free, a shared line that lights up across reception, one-touch call park, presence, a directory lookup that resolves a caller's name — are built on extensions and conventions that vendors implement differently. Some use SIP SUBSCRIBE and NOTIFY in the standard way. Some use their own XML services. A few do something idiosyncratic that only works properly against the platform they were designed for.
So the accurate sentence is this: a standards-compliant SIP handset will register to Uniden Voice and make and receive calls reliably; the feature keys need checking model by model. That is a much smaller job than replacing your hardware, and it is the job this article is really about.
Three Tiers of Support, Honestly Labelled
Most providers answer the compatibility question with either a flat “we only support our own phones” or an equally unhelpful “anything SIP works”. Neither is true. There are three tiers, and knowing which one your hardware falls into tells you what your migration will actually involve.
| Tier | What it covers | What you do | What we do |
|---|---|---|---|
| 1. Auto-provisioned | The models we ship and configure ourselves, including the Uniden EVOC2 and the third-party models on our hardware page | Give us the MAC address. Plug the phone into the network | Everything else. Config, keys, firmware policy, directory, and support when it breaks |
| 2. Standards-compliant, manually configured | The broad field of current-generation SIP desk phones, DECT bases, ATAs, intercoms and paging devices from established manufacturers | Reset the device, enter the SIP credentials we issue, or point it at a provisioning URL | Issue credentials, supply the settings, help you get the first one working so you can repeat it |
| 3. Registers, unsupported | End-of-life handsets, obscure imports, devices with locked or vendor-specific firmware, anything that cannot do modern transport security | Accept that it is your risk, and keep a spare | Not block it. It will register. We will not promise to fix it |
Tier three is a real category and pretending otherwise helps nobody
There are handsets on Australian desks today that were discontinued before the pandemic, that have not had a firmware release in five years, and that cannot negotiate a current TLS version. They will still make phone calls. They are also a security exposure and a support black hole, and the responsible thing is to say so rather than to quietly include them in a compatibility claim. See the security section below for what actually matters here — it is not the age of the plastic.
The Brands and Models We See Most
This is the list Australian businesses actually ring us about, assembled from what turns up on real desks during real migrations. It is not a certification matrix and it is not exhaustive — the point of an open protocol is that the list can never be complete.
| Manufacturer | Models commonly deployed in Australia | Notes |
|---|---|---|
| Yealink | Entry: T31G, T31P, T33G. Mid-range: T43U, T46U, T48U. Executive and smart: T53W, T54W, T57W, T58W Pro, T87W. Expansion modules EXP43 and EXP50 | The most common brand on Australian desks by a wide margin. Excellent standards behaviour and a mature provisioning system |
| Yealink DECT | W73P and W73H, W78P and W78H, W79P, the rugged W59R, the W70B base, and the multi-cell W80 and W90 systems | Good choice for warehouses, clinics and venues. Multi-cell needs planning, not just plugging in |
| Fanvil | X series: X3U, X4U, X5U, X6U, X7A, X7C. Reception and console: X210, X210i. V series: V62, V64, V66 and V66 Pro. Android touch: A320, A32i, A330 | Strong on high key-count reception phones. The X210 at 106 keys and the V66 at 116 are hard to beat on price per key |
| Grandstream | GRP2601, GRP2612 and GRP2612W, GRP2613, GRP2614, GRP2615, GRP2616, GRP2624, GRP2634, GRP2636, GRP2650, GRP2670. DECT: DP730, DP752, DP755. ATAs: HT801, HT802, HT812, HT814, HT818 | Very widely deployed by MSPs. The HT ATA range is the default answer for analogue devices in Australia |
| Snom | D717, D735, D785, D812, D815, D862, D865, and the M-series DECT with M300, M700 and M900 bases | Less common here than in Europe, but solid and standards-clean |
| Poly (Polycom) | VVX 150, 250, 350 and 450. Edge E100, E220, E320, E350, E450, E550. Trio 8300, 8500, 8800 and C60 conference. Rove DECT | Frequently inherited from an earlier enterprise deployment. Check firmware generation before assuming |
| Cisco | 6800 series (6821, 6841, 6851, 6861), 7800 series (7811, 7821, 7841, 7861), 8800 series (8811, 8841, 8851, 8861, 8865) | Must be running multiplatform (MPP) firmware, not the enterprise call manager load. This is the single most common Cisco disappointment |
| Htek, Gigaset, AudioCodes, Sangoma | Htek UC902, UC912, UC924, UC926. Gigaset Maxwell, N670 and N870 DECT. AudioCodes 400HD series. Sangoma P310, P320, P325, P330, P370 | All standards-based. Sangoma and Gigaset DECT in particular are well built and often overlooked |
| Uniden | The EVOC2 IP handset | Auto-provisions with a MAC address and nothing else. Uniden's cordless analogue home and office phones are a different thing entirely and need an ATA |
Read the model list as a starting point, not a promise
Manufacturers revise hardware inside the same model name, ship regional variants, and occasionally issue a firmware build that changes behaviour. The only test that settles it is registering one of your actual phones, which takes about ten minutes and which we will do with you before you commit to anything. If a model is not on this list, that is not a refusal — it means we have not seen enough of them to say something useful.
The Third-Party Phones We Already Ship
It is worth being concrete about this, because “we support third-party devices” is the sort of claim that is easy to make and rarely tested. Look at our own hardware page. Alongside the Uniden EVOC2 you will find, sold and supported by us:
The EVOC2 desk phone
Our own handset. A 2.8″ colour screen, dual gigabit ports, PoE, Bluetooth for a headset, seven DSS keys and true plug-and-play provisioning. The default for most desks.
A DECT cordless system
The W78P, a Yealink DECT base and handset pairing supporting up to ten cordless handsets, with roughly 21 hours of talk time and a ten-minute quick charge. For people who do not sit still.
A reception console
The X210, a Fanvil reception handset with 106 DSS keys across three screens. If one person answers for the whole building, this is the tool for that job.
Manager and executive handsets
The V66 with a 7″ screen and 116 virtual keys, and the T87W with AI noise filtering, dual-band Wi-Fi and 84 virtual keys. Both third-party, both sold and provisioned by us.
In other words, three of the five handsets on our own price list are made by other people. We chose them because they are the right tool for a particular desk, and we provision and support them exactly as we do our own hardware. A provider that genuinely only supported its own phones could not have built that page.
Everything bought directly from us also includes complimentary remote setup and ongoing technical support, so the initial configuration is handled without a service call. That applies to the third-party models as much as to the EVOC2.
Beyond Desk Phones: DECT, ATAs, Intercoms and Paging
Desk phones are the visible part of the estate and usually the smallest part of the problem. The devices that cause migrations to stall are the ones nobody has thought about since they were installed.
| Device class | What it is for | Common devices | What to watch |
|---|---|---|---|
| Analogue adapters (ATAs) | Putting an old analogue device onto an IP platform | Grandstream HT801, HT802, HT812, HT814, HT818. AudioCodes MP-1xx. Patton SmartNode. Yeastar TA series | One FXS port equals one analogue device. Count your ports before you buy |
| Door and gate intercoms | Answering the front door from any handset or the mobile app | 2N IP Verso, Force and Solo. Akuvox R20, E12, X915. Fanvil i10, i16V, i18S. Doorbird | Relay control for the strike plate is configured on the intercom, not on the phone platform |
| Overhead paging and speakers | Announcements across a warehouse, workshop or retail floor | Algo 8180, 8186, 8301 and 8373. CyberData SIP speakers and paging adapters | Multicast paging behaves differently from a SIP page. Decide which you need before wiring |
| Conference phones | Boardroom and meeting room audio | Yealink CP925, CP935W, CP965. Poly Trio 8300, 8500, 8800. Grandstream GAC series | Often the oldest thing in the building and the most likely to be out of firmware support |
| Cordless DECT estates | Warehouses, clinics, aged care, hospitality | Yealink W70B, W80 and W90. Gigaset N670 and N870. Snom M300, M700, M900. Fanvil W710D and W610D | Multi-cell handover is an RF design job. Moving platform does not fix a bad cell plan, and does not break a good one |
Three analogue things that need a decision, not an adapter
Monitored alarm panels, lift emergency phones and EFTPOS terminals are not ordinary analogue devices. They can often be made to work through an ATA, and they should not simply be assumed to. A monitored alarm belongs on a path designed for it — an IP or 4G reporting module — because a dial-up alarm behind an adapter can fail silently and you find out at the worst moment. A lift phone has a legal obligation attached to it and should be tested, in the lift, by someone who has read the maintenance contract. Fax is discussed below.
On fax specifically: T.38 exists, it is supported, and it works better than passing fax tones through a voice codec. It is still a best-effort protocol carrying a 1980s modem handshake over a packet network, and if faxing matters to your business — as it still does in parts of health and conveyancing — the reliable answer in 2026 is fax-to-email rather than a physical machine on an adapter. We will support either. We will be honest about which one produces fewer phone calls to us.
The Lock You May Not Know You Have
This is the part that catches out even experienced IT people, and it is worth reading carefully because it can turn a smooth migration into a fortnight of frustration.
Every major handset manufacturer runs a redirection service — Yealink calls it RPS, Grandstream and Cisco use EDOS-style device provisioning, Poly has ZTP. The purpose is genuinely useful: a phone straight out of the box asks the manufacturer's server “who do I belong to?”, is pointed at the correct provider's provisioning system, and configures itself with no human involvement. That is how zero-touch deployment works at all.
The consequence
Whoever registered the handset in the redirection service controls where it points, and a factory reset does not clear that. If you bought your phones through your current provider, they may be registered to that provider's account. Reset the phone and it will dutifully go back to asking their server, and their server will keep sending it home. The fix is simple and entirely in their hands: they release the MAC address. It takes them a minute. Getting them to do it during an acrimonious exit can take considerably longer.
What to do about it, in order:
| When | Action |
|---|---|
| Before you buy handsets, ever | Ask one question in writing: “If I leave, will you release these devices from your provisioning account?” A provider that will not answer that plainly has told you something important |
| Before you sign anywhere new | Check who supplied the existing phones and whether they were sold to you or supplied as part of the service. Those are very different legal positions and the invoice will usually settle it |
| At the start of a migration | Request the release in writing, early, while the relationship is still cordial. Not on cutover week |
| If release is refused | Most phones can be manually configured to override the redirection, which sidesteps the lock for devices you own. It is more work per handset and it is a perfectly good fallback |
For completeness, and because it is a fair question to ask of us: handsets bought from Uniden Voice are yours. If you leave, we release them. We would rather keep you because the service is good.
Five Things That Do Not Carry Across
Setting expectations properly is the difference between a migration people describe as smooth and one they describe as fine-but-there-were-surprises. Five things will not survive the change, no matter whose platform you move to.
Your key layouts
Every programmed DSS, BLF and speed dial key is defined by the old provisioning template. They are rebuilt on the new platform. On an auto-provisioned model this is a template change once, not forty phones by hand.
Local phonebooks
Contacts saved on individual handsets are stored on the handset and are usually exportable, but rarely in a format the next system wants. The better answer is a shared cloud directory that every device reads, which is what you should have had all along.
Vendor-specific apps
XML browser applications, weather widgets and bespoke screen integrations built for the old platform will not follow you. Almost nobody misses them. Occasionally someone does, and it is better to know now.
Call recordings and voicemail
These live on the old platform, not the handset. Export them before the account closes — it is the single most common regret in a switch, and it is unrecoverable afterwards.
Branded firmware editions
A phone flashed with a Teams-branded or provider-branded firmware load behaves as that product, not as a generic SIP phone. It usually can be re-flashed to a standard load. Budget an hour to discover which case you are in.
None of these five is a reason not to move. They are reasons to spend an hour on an inventory before cutover week rather than during it. A migration that surprises nobody is not a lucky migration — it is one where somebody wrote the list down in advance.
The Question Nobody Asks About Old Handsets
The usual argument for replacing handsets is that they are old. Age on its own is a poor reason: a well-built desk phone from 2019 can be perfectly good in 2026, and plenty are. The real question is different and much sharper.
| Check | Why it matters | What good looks like |
|---|---|---|
| Is the firmware still receiving updates? | A device the manufacturer has stopped patching accumulates known, published vulnerabilities. Anyone can read the advisories | A firmware release within the last 18 months, or a model still listed as current |
| Can it do TLS 1.2 or better for SIP? | Without it, registration credentials and call signalling cross the network in the clear | SIP over TLS, negotiated successfully, not merely offered in a menu |
| Can it do SRTP for the audio? | Signalling encryption without media encryption protects the envelope and not the letter | SRTP negotiated on real calls, verified in the call detail, not assumed |
| Has the admin password been changed? | Default web interface passwords on IP phones are the oldest trick there is, and toll fraud is still a going concern in Australia | Unique credentials, web interface not reachable from outside the LAN |
| Is the web interface exposed? | A phone with a public-facing admin page is an open door with a doorbell | Management on the internal network only, ideally on a voice VLAN |
The rule that actually decides it
A handset that cannot negotiate current transport security should be replaced regardless of how well it makes calls, and a handset that can should probably be kept regardless of how old it looks. That is the whole test. It is also the opposite of the way most hardware refresh conversations are run, which is by age and appearance.
Auditing Your Fleet in an Afternoon
Before anyone quotes you for hardware, do this. It takes one person one afternoon in a normal small or medium business and it changes the conversation entirely, because you arrive with facts instead of an estimate.
| Step | What to capture | Where to find it |
|---|---|---|
| 1. Walk the floor | Make, model and location of every device with a handset or a speaker on it | Printed on the base of the phone. Include the meeting rooms, the warehouse, the kitchen and the one in the storeroom nobody uses |
| 2. Record MAC addresses | The MAC of each device | On the label under the phone, and in the phone's status menu. This is what makes auto-provisioning possible |
| 3. Note firmware versions | Current firmware on each model — one per model is enough, not one per phone | Status or About menu on the handset |
| 4. Find the analogue things | Fax, EFTPOS, lift phone, alarm panel, gate intercom, paging horn, door strike | Follow the cables. Ask the person who has been there longest — this step is genuinely social, not technical |
| 5. Establish who owns them | Purchased outright, or supplied with the service | The original invoice. If there is no invoice, they were probably supplied with the service |
| 6. Ask the release question | Written confirmation that devices will be released from the provisioning account | Your current provider, by email, so there is a record |
Send us the list
Give us that inventory and we will tell you, per line, which tier it falls into and what it will take. That answer is free, it is specific to your building, and it is worth considerably more than a general compatibility claim on a web page — including this one.
Keep, Re-Flash or Replace
A simple framework for the decision, ordered by the thing that should drive it.
| Situation | Verdict | Reasoning |
|---|---|---|
| Current-generation handset, supported firmware, TLS and SRTP working | Keep | There is no case for replacing it. Reconfigure and move on |
| Good handset carrying a provider-branded or Teams firmware load | Re-flash | A standard SIP load usually exists. One phone tells you whether the fleet can follow |
| Cisco phone on enterprise call manager firmware | Re-flash to MPP | The hardware is fine. The software is the wrong product. Conversion is a known, documented path |
| Handset out of firmware support, no TLS 1.2 | Replace | Security, not sentiment. This is the one case where age genuinely does decide it |
| Reception console, but nobody sits at reception any more | Replace with nothing | The honest answer more often than people expect. If calls are answered in the app or by AI, a 106-key console is furniture |
| Desks where the person is rarely at the desk | Replace with nothing | The mobile and desktop apps cover it. Buy handsets for the desks that earn one, not for the headcount |
The counter-argument, stated fairly
A single-vendor estate is genuinely easier to run. One firmware policy, one provisioning template, one set of quirks, one support conversation. If you are buying from scratch, buying one model for most desks is the right call and we will recommend it. That argument applies to new purchases. It is not a reason to skip thirty working handsets you already paid for, and a provider using it that way is arguing for their hardware margin rather than for your outcome.
The summary
Standard SIP means your existing handsets are very probably fine. Check three things before you worry about anything else: whether the firmware is still supported, whether the device can do TLS and SRTP, and whether your current provider will release it from their provisioning account. Those three answers determine your entire hardware position. Everything else is configuration.
Related reading: how plug-and-play provisioning actually works for the mechanics behind tier one, changing providers without losing a call for the wider migration, and troubleshooting VoIP and SIP problems for when a registration will not come up.