For a century, a phone was an object. In a VoIP system, a phone is a role that several kinds of endpoint can play: a dedicated desk phone, an application on a computer, an app on a mobile, or a tab in a browser. All of them speak SIP or WebRTC toward the same platform, and the platform decides which of them ring for a given call. The word softphone covers the software members of that family.
The practical consequence is that a business number stops being tied to a place. The same number can ring a desk at the office, a laptop at home, and a mobile in transit, simultaneously, and the first endpoint to answer takes the call. Understanding how that works, and where each endpoint type is strong or weak, is most of what there is to know.
The endpoint landscape
- Softphone (desktop)
- An installed application on Windows, macOS, or Linux that registers to the platform over SIP or a proprietary protocol and uses the computer's audio devices. Often paired with a USB or Bluetooth headset.
- Mobile app
- A softphone on iOS or Android. Behaves differently from a desktop client because mobile operating systems suspend background apps; incoming calls arrive via push notification rather than a persistent connection.
- Browser client
- A WebRTC endpoint running in a web page. Nothing to install, works anywhere a modern browser runs, subject to the browser's microphone permissions and tab lifecycle.
- Desk phone (hardphone)
- Dedicated SIP hardware: a handset, speaker, display, and Ethernet port in one device. Always on, independent of any computer, with purpose-built acoustics.
| Endpoint | Runs on | Strengths | Weak spots |
|---|---|---|---|
| Desktop softphone | Computer OS, installed app | Integrates with CRM and screen work, headset audio, click-to-dial, full feature surface | Dies with the laptop (battery, sleep, reboots), depends on the computer's audio setup, notification fatigue |
| Mobile app | iOS / Android | Rings anywhere with data, separates work identity from the personal line (see second phone number), camera and contacts integration | Push-wake delay on inbound, cellular-data audio varies, OS battery policies can delay notifications |
| Browser client (WebRTC) | Chrome, Edge, Firefox, Safari | Zero install, always current version, works on locked-down machines | Tab must stay alive (or a service worker must), mic permission prompts, browser update surprises |
| Desk phone | Dedicated SIP hardware | Always registered, boots with the desk, excellent handset acoustics, no OS in the way, physical buttons for transfer and hold | Costs money per seat, tied to a location, needs provisioning, no screen-based context about the caller |
One number, many endpoints
In SIP, an endpoint announces itself with a REGISTER request: it binds the user's address of record to a contact address where that device can be reached, with an expiry that the device refreshes. Nothing limits a user to one binding. A desk phone, a desktop client, and a browser tab can all hold current registrations for the same user at the same time.
When a call arrives for that user, the platform forks the invitation to every registered contact in parallel. All the endpoints ring. The first to answer wins, and the platform cancels the other legs, which stop ringing. This is the same parallel-forking mechanic that powers simultaneous ring in forwarding and hunt groups, applied to one person's devices, and it is also how shared numbers ring a whole team's endpoints at once.
Mobile is the exception to always-on registration. iOS and Android suspend backgrounded apps, so a mobile softphone cannot hold a SIP connection open all day without destroying the battery. Instead, the platform sends a push notification (through APNs on iOS or FCM on Android) when a call arrives. The push wakes the app, the app registers or reattaches in the background, and only then does the device ring. Done well this adds under a second. Done poorly, or throttled by an aggressive battery-saver mode, it is why a mobile app sometimes rings a few seconds after the desk phone, or shows a missed call it never audibly received.
Audio hardware realities
Software does not change acoustics. A desk phone's handset puts the microphone an inch from the mouth in a sealed enclosure; a laptop's built-in microphone is a hole in a keyboard deck, a foot or more from the speaker's face, next to a fan, above a clattering keyboard. Echo cancellation (the DSP that stops the far party from hearing themselves through your speakers) works hardest, and fails most audibly, in the open-mic laptop configuration.
- A wired USB headset is the single biggest audio upgrade for a softphone user: close-talking microphone, sealed ears, hardware echo isolation by design.
- Bluetooth headsets are convenient but add radio latency and occasionally negotiate low-quality codec modes when the microphone is active.
- Open speaker plus built-in mic is the worst case: the echo canceller must subtract the far party's voice from the room, and background noise passes straight through. Acceptable for a quick call, wrong for hours of them.
- Configure the softphone's audio devices explicitly. OS-default device switching (a monitor's speakers, a webcam's mic) is a leading cause of 'they cannot hear me' tickets.
Desk-phone provisioning, briefly
Softphones configure themselves at login. Desk phones need provisioning: on boot the phone fetches a configuration file (accounts, server addresses, keys, firmware) from a provisioning server, discovered through a DHCP option, a redirect service run by the manufacturer, or a URL entered once. Modern hosted platforms make this near zero-touch: the admin enters the phone's MAC address, the user plugs it in, and the phone comes up registered. The mechanics matter mostly when they fail: a phone that boots but does not register is usually failing to reach or authenticate against its provisioning source, or a firewall issue covered in network requirements.
When each endpoint wins
The endpoint decision is per role, not per company. The pattern that has emerged across most deployments:
- Desk phones still win where the phone is shared or the job is the phone: reception desks, retail counters, warehouses, break rooms, and anywhere a device must work regardless of whose laptop is nearby or whether it is charged.
- Desktop softphones win for people who take calls while working at a screen: support, sales, and anyone who benefits from caller context, notes, and click-to-dial in the same place.
- Mobile apps win for mobility: field staff, after-hours coverage, remote workers, and anyone answering a shared number away from a desk.
- Browser clients win for occasional users, contractors, and locked-down or borrowed machines where installing software is not an option.
Because one user can register several endpoints, the practical default is a softphone (desktop or mobile) for every user, plus hardware only where the table above justifies it. Whatever the mix, every endpoint rides the same network path, so the targets in network requirements and call quality apply to all of them equally.