Daniel's been reading SIP documentation again, which for him is what a lazy Sunday looks like. His question this week is about taking a protocol everyone associates with phone calls and trunking and asking what happens when you point it in one direction only. A building PA system. An always-on listener that sits on a channel and plays whatever arrives, no microphone, no transmit path. He wants to know how SIP actually gets wired into intercom and public address backbones, what RTP is doing underneath, and whether you can build the whole thing without proprietary gear, just network speakers, SIP, and some way to move packets around.
And the answer to that last part is yes, with a few asterisks that are going to take us most of the episode to unpack. The first thing to get straight is what SIP actually is, because the name does half the work and then stops. Session Initiation Protocol. It is a signaling protocol, full stop. Its job is to set up, modify, and tear down sessions. It does not carry audio.
That's the part everyone gets wrong. They hear VoIP and assume the protocol is moving the voice.
The voice rides on RTP, usually over UDP. SIP just negotiates the whole thing, like a maître d' who seats you and then disappears. RFC 3261, published June 2002, obsoleting 2543, defines it as an HTTP-like request-response transaction model. You send an INVITE, you get back a response. Every transaction is a method plus at least one response. It's text-based, human-readable, which is why you can debug it with a packet capture and a cup of coffee.
And the user agent split, that's the part that sounds academic but actually matters for what we're doing today.
Right. A user agent client initiates requests. A user agent server receives them and generates responses. A SIP phone is both, and it flips roles mid-call. When you hang up first, your phone sends the BYE as a client. When someone calls you, your phone is the server answering the INVITE. The point is that nothing in the architecture requires symmetry. A device can be a user agent server that receives an INVITE, acknowledges it, and then just listens. It never has to send media back. That's the whole one-way trick, and it's not a hack, it's just a session where the audio flows in a single direction.
So the reason SIP got glued to trunking is historical, not architectural. It became the lingua franca for connecting PBXs to carriers and to each other because it was open and everyone implemented it. But the same machinery that sets up a call between two extensions can set up a session between a phone and a speaker.
And the speaker doesn't have to be a phone at all. Grandstream makes the GSC3506, which they market explicitly as a one-way public address SIP speaker. Offices, schools, hospitals, apartment buildings. Thirty watt HD speaker, supports SIP paging, multicast paging, group paging, push to talk. It's a SIP endpoint that has no handset, no dial pad, no microphone. It receives an INVITE, negotiates the session, and plays the RTP stream that arrives.
A speaker with a phone number.
A speaker with a phone number, and that's not a joke, that's the product description. Viking has a ceiling speaker, the 40-IP, that's described as a SIP endpoint or multicast group member. Six watt class D amplifier, Power over Ethernet class 3, under thirteen watts, so you're running the whole thing off the same cable that carries the data. It supports up to ten multicast paging groups. Their PA-IP amplifier is the same idea but with a relay for door locks and strobes.
So the hardware exists, and it's been commoditized to the point where a ceiling speaker is just another device on the network. But here's the fork in the road, and it's the thing Daniel's really asking about. When you page a building, do you call every speaker individually, or do you broadcast?
Unicast versus multicast. Unicast is point to point, much like a regular phone call. The PBX sets up and maintains one individual SIP call per endpoint. Viking's own tutorial is blunt about this. A thirty speaker system means thirty simultaneous calls, which can strain the CPU, risk lost calls and data, and potentially cause system lockups. VoIP Supply wrote about this back in 2011. A twenty extension page group means twenty simultaneous SIP calls. They said in larger applications where paging groups range from fifty to a hundred plus users, unicast paging is strongly advised against.
Thirty speakers, thirty calls, thirty separate RTP streams, all carrying the same audio. It's like mailing thirty identical letters instead of putting one notice on a bulletin board.
And it's not just CPU. It's SIP licensing fees if you're on a commercial PBX, it's bandwidth on the trunk, it's session state the PBX has to track for every single leg. Multicast flips the whole thing. Audio is sent once to a multicast IP address, and endpoints tune in. The PBX makes a single SIP call and a single RTP stream, regardless of whether there are five listeners or five hundred. VoIP Supply's framing is that a five hundred user page group could very easily receive a page using multicast because the PBX only makes one SIP call.
Five hundred speakers, one call. That's the moment where the architecture goes from scaling linearly to scaling not at all.
There's no practical limit to the number of endpoints, at least not from the PBX's perspective. The network has to handle the multicast traffic, but the PBX is done. One stream, one session, everyone tuned in.
So what's the catch? Because there's always a catch.
Configuration. Multicast is tedious and error prone. You have to program IP addresses carefully, you have to make sure your switches are handling multicast properly, you have to think about IGMP if you're crossing VLANs. And there's a security consideration. If someone gets the multicast address and the network info, they can potentially inject audio or listen in. It's not encrypted by default. Not all endpoints support multicast either.
And this is the part where the boring network stuff becomes the actual engineering. Let's get into how this actually works under the hood, because Daniel asked about RTP and I want to be concrete.
Asterisk added multicast RTP support in version 1.8. The dial string looks like MulticastRTP, then a type, then a destination, then a control address. The type is basic or linksys. The destination is the IP and port for the RTP packets. The control address is Linksys specific, because Linksys phones need a start and stop packet to know when to start listening. Cisco phones need a different control packet. This comes from the original rtppage commit by Andreas Brodmann. So you'd have an extension like 8400 that calls the Page application with MulticastRTP basic 224 dot 30 dot 15 dot 50 port 1234.
And Page itself, that's the Asterisk application that takes the caller and dumps them into a conference bridge as the speaker, with the endpoints as muted participants. It's been around since Asterisk 1.2.
Right, and that's the unicast version. Page places outbound calls to each endpoint and conferences them together. The multicast approach is different, and there's a nuance worth getting exactly right. A commenter named Dave on that VoIP Supply series, back in 2017, pointed out that most multicast solutions don't send the audio from the originating phone back to the PBX for proxy back to the other phones. The phone multicasts to the other endpoints directly on the LAN segment. You don't haul the audio back to the PBX, possibly over the WAN in hosted deployments, unless the page needs to be recorded.
So the PBX sets up the session, but the audio never actually touches it. The phone becomes the broadcaster.
Which is elegant and also a little terrifying if you're the PBX administrator who's used to seeing every call. But it's how the de facto standard works now. There's a GitHub project, Param Cloudtelecom's multicast paging system, MIT licensed, created this past June. It uses FreeSWITCH and a Python ESL service. Caller dials star 80, the dialplan triggers a script that forks the caller's audio and re-emits it as multicast RTP to 224 dot 0 dot 1 dot 75 port 5555. That address, 224 dot 0 dot 1 dot 75, is described in the readme as the de facto standard most vendors default to.
And the insight from that project's readme is the thing that made the whole architecture click for me. Every paging capable phone is already listening on the same multicast address. The announcement plays on all of them the instant audio hits that address, full stop, regardless of individual phone state. Unlike a ring group page, which calls each extension individually and misses phones that are busy or in do not disturb.
That's the difference between a broadcast and a series of individual calls. A ring group page dials twenty extensions, and if three of them are on another call or set to DND, those three miss the page. Multicast doesn't care. The phone is listening on the multicast address whether it's idle or busy or in do not disturb. The audio arrives and it plays.
So the phone is passively listening on a multicast address at all times, and the page is just audio that happens to arrive at that address. That's the passive always-on player Daniel was talking about, just in the SIP world instead of the Zello world.
And the network caveat from that same project is the asterisk I mentioned earlier. Multicast paging only works within the same layer 2 broadcast domain, or across routed segments with IGMP and multicast routing explicitly enabled. The multicast TTL is set to one, meaning the packet dies at the first router. Across VLANs, you need multicast routing or per VLAN paging groups at the switch or router layer.
So the PBX is trivial. The speaker is trivial. The part that requires actual thought is whether your network will carry the multicast traffic from one VLAN to another without you having to configure every switch along the path.
That's the mechanism to connect packets across the network that Daniel mentioned. It's not a proprietary box. It's understanding layer 2 versus layer 3, IGMP snooping, multicast routing, TTL. The network is the product.
Let's talk about the open source path, because Daniel's question was whether you can do this without proprietary gear, and the answer is that you can get surprisingly far with commodity hardware and software you can read.
The classic hack is on voip info dot org, and it's been there for years. Take an auto answer SIP phone, a Grandstream Budgetone or GXP 2000, a Snom, an Aastra, a Polycom, a Cisco 7940 or 7960. Splice an RCA or 3.5 millimeter jack in place of the built in speaker. Feed that into a traditional paging amplifier. Total investment, about eighty dollars for the phone, the wire, and the connectors, and you have a basic paging system at your office. The GXP 2000 even has a built in 3.5 millimeter jack, so you don't have to splice anything.
An eighty dollar paging system. That's the part where the proprietary gear argument starts to look pretty thin.
But the same voip info page notes that SIP phones for the most part don't support any of these phone based paging functions natively. The workaround is auto answer plus a SIP add header or call info headers to trigger the auto answer, or the multicast approach. So it's not that the phones are paging devices out of the box. It's that they can be coerced into behaving like paging devices if you're willing to do the work.
Auto answer is the key there. You send a header that tells the phone to answer without ringing, and then the RTP stream just plays. The phone doesn't know it's a page versus a call. It just knows it's been told to answer and there's audio.
That's the whole thing in miniature. SIP doesn't have a paging mode. It has sessions, and a session can be one way, and a phone can be configured to accept a session without user interaction. Everything else is convention and configuration.
Now let's get to the Zello side, because Daniel mentioned the first responder use case, and the listen only mode there is the cleanest real world example of the passive always on player.
Zello's Channel API is WebSocket based, JSON control plus binary audio, Opus codec. And it explicitly supports a listen only mode. Anonymous accounts can access unrestricted channels in listen only mode, that's on the Friends and Family side. The logon command takes a listen only parameter set to true. And there's a dedicated error code, listen only connection, the client tried to send a message over a listen only connection.
The API itself enforces the asymmetry. The client connects, authenticates, and the server knows from the start that this client is not allowed to transmit. If it tries, it gets an error.
The SDKs expose a listenOnly boolean. The documentation says whether the user is allowed to talk on the channel. When this is true, you should not show any UI to allow the user to talk on the channel. The Android options also include noDisconnect, hidePowerButton, emergencyOnly. This is built for kiosk style deployments where a device sits on a wall and listens.
There are third party listener clients. JCMurray's monitor was originally designed to listen to traffic on Zello channels and not to originate any voice or other traffic. It explicitly does not support sending start stream, stream data, or stop stream. It's a receive only client, by design. There's also zelpy, a Python async client, and ts-zello, a Node bot library, that can monitor channel activity and receive audio.
The API even has a platform name field. If it includes the word Gateway or Kiosk, case insensitive, the Zello Alarms service will track the online status of this client. So there's a whole category of always on monitoring devices that the platform expects to exist and has built specific hooks for.
A speaker on a wall that's logged into a Zello channel, playing whatever comes across, with no microphone and no transmit button. That's the passive always on player Daniel described, and it's not a hypothetical. The API has a flag for it.
The architectural parallel to SIP is exact. In SIP, the signaling layer sets up the session and the media flows one way. In Zello, the WebSocket control channel sets up the connection and the audio flows one way. The listen only flag is the equivalent of a SIP endpoint that receives an INVITE and never sends media back.
The difference is that Zello built the one way case into the protocol as a first class citizen, while SIP just doesn't care. It's not that SIP supports one way audio, it's that SIP doesn't have an opinion about it at all.
Which is why the 2003 Asterisk mailing list post is so funny in retrospect. Someone called multicast paging usually unworkable and mostly unsupported for SIP devices, and advised avoiding it. Two decades later, 224 dot 0 dot 1 dot 75 port 5555 is a de facto standard across Yealink, Snom, Grandstream, and Cisco. The thing that was unworkable in 2003 is the default behavior now.
The phones caught up. The network equipment caught up. The multicast address became conventional. That's the whole story of infrastructure protocols. They look inevitable in hindsight and impossible in foresight.
The no proprietary gear claim is largely true, but with asterisks. You can absolutely do this with FreeSWITCH or Asterisk, commodity SIP speakers, multicast RTP, or even a hacked auto answer desk phone. But you still need multicast capable network infrastructure and careful layer 2 and layer 3 configuration. The mechanism to connect packets across the network is where the real work lives.
The proprietary gear isn't the speaker. It was never the speaker. The proprietary gear is the assumption that someone else will handle the network.
That's the thing I want to sit with for a second. SIP paging is not hard. The protocol is twenty years old, the hardware is commodity, the software is open source. What's hard is that buildings are physical objects with switches and VLANs and firewalls and a guy who knows where the conduit runs.
The guy who knows where the conduit runs. That's the real infrastructure.
Hilbert: A punch down tool. Fluke, model D914S. I bought it in 1997 and I still have it.
That's a specific tool to name.
Hilbert: I spent three years pulling eighteen gauge wire through risers in mid rise apartment buildings. Intercom systems. Before SIP was everywhere, before IP speakers, before any of this. You had a panel in the lobby, a station in each unit, and wire between them. Terminated on 66 blocks. Punch down, punch down, punch down. Three years of my life.
When we say the network is the hard part, you're saying the network used to be literal wire.
Hilbert: The gear was never the proprietary part. The wire was. The riser was. The fact that you had to get a key to the electrical closet from a building superintendent who only worked Tuesdays and Thursdays. That's the proprietary part. You can buy a SIP speaker for a hundred bucks and have it running in an afternoon. You cannot buy your way into the riser closet. You have to know a guy.
The physical plant is the moat.
Hilbert: The SIP part is the easy part. The hard part is that buildings are physical objects with locked doors and asbestos and a guy named Sal who knows where the conduit runs. Sal doesn't care about multicast. Sal cares that you don't drill through his conduit.
Sal is the last mile.
Hilbert: Sal is the whole mile. I once lost fourteen hundred dollars on a pallet of surplus intercom stations I bought at an auction in 1994. Thought I could flip them. They're still in my garage, next to the punch down tool.
The economics of surplus intercom stations are apparently unforgiving.
Hilbert: The stations were fine. The buildings didn't want them. Every building had its own system, its own wire, its own Sal. You can't just drop in a different station. The wire doesn't match, the voltage doesn't match, the mounting holes don't match. The station is the cheap part. The installation is the expensive part.
That's the thing about the SIP world that's different. The speaker is a network device. It doesn't care what building it's in. It just needs an IP address and a route to the PBX.
Hilbert: That's the elegant part, I'll grant you. One cable, power and data, and the speaker is on the network. No 66 blocks, no punch down tool, no Sal. But somebody still has to run that cable. Somebody still has to get into the closet. Somebody still has to know which switch port goes to which floor.
The network is the new riser.
Hilbert: The network is the new riser, and the switch is the new 66 block, and the VLAN is the new zone. Same job, different tools.
When Daniel says you don't need proprietary gear, the honest answer is that you don't need proprietary audio gear. You need access.
Hilbert: You need a key. That's what you need. The rest is just packets.
The open question this leaves me with is why so many buildings still have separate PA systems at all. If SIP can do one way audio this cleanly, and the speakers are commodity, and the software is free, why is the PA system still a separate thing with its own amplifier and its own wiring and its own maintenance contract?
Inertia is the obvious answer. The PA system was installed in 1987 and it works and nobody wants to be the person who replaces it with something that requires a network engineer.
But I think there's something deeper. A PA system is life safety adjacent in a lot of buildings. Fire alarm integration, emergency announcements, evacuation tones. The people who install those systems are certified and the systems are inspected. A SIP speaker on the network is a computer, and computers get patched and rebooted and sometimes they just don't work.
The convergence hasn't happened because the PA system isn't just an audio system. It's a safety system with a regulatory apparatus around it. The SIP speaker is a better audio device, but it's not a better safety device, at least not in the eyes of the people who sign the inspection reports.
That's the line between phone system and building infrastructure. The phone system is allowed to be a computer. The PA system is supposed to be a fixture, like a fire extinguisher or an exit sign. It's supposed to be boring.
The passive always on listener is a hint of where that line blurs. A device that sits on a channel and plays everything, no microphone, no transmit path. That's not a phone. That's a speaker. But it's using phone infrastructure. The categories are already leaking into each other.
As more devices become SIP capable, not just phones but speakers and horns and amplifiers, the line gets blurrier. The phone system and the building infrastructure are converging on the same protocol, the same network, the same address space.
Daniel's question was whether you can build an intercom without proprietary gear. The answer is yes, and the asterisk is that the gear was never the hard part. The hard part is the building, the network, the access, the Sal factor. The protocol is the easy part. That's what twenty years of open standards buys you.
The protocol is elegant. A signaling layer that sets up sessions, a media layer that carries audio, and no architectural requirement that the audio flow in both directions. One way is not a special case. It's just a session with a single media stream.
If you want to hear more about the protocols and plumbing behind the systems you use every day, subscribe and leave a review. It helps more than you'd think.
Thanks to our producer Hilbert Flumingtop, who apparently still owns a punch down tool and is not sorry about it.
This has been My Weird Prompts. We'll be back soon.
