IP Speakers

At minimum you need the speaker and a network cable to a port of a PoE+ (IEEE 802.3at) switch, or the 12 V, 2 A adapter if you have no PoE switch. A SIP PBX is only needed if you want to speak to the speakers from IP phones or from the PBX itself; multicast announcements from a console or software and playback of stored files by schedule work without any extra server. KDT speakers have a built-in web page where you upload audio files to the internal memory, set schedules and control playback, and a SIP account can be defined on them when needed. Also point the speaker's clock to an NTP server, local or on the internet, so that scheduled playback happens on time.

In a conventional system a central amplifier sends an analog signal over speaker cable (for example a 100 V line) to passive speakers, whereas an IP speaker has its own network interface, audio decoder and amplifier and needs only a network cable, which also carries power when PoE is used. Each speaker has its own IP address and can be controlled alone or as part of a group, and adding a speaker means adding a switch port instead of running audio cable and upgrading an amplifier. The trade-offs are power and distance: a PoE speaker delivers less than 20 W of continuous audio power, and the network cable can be at most 100 m from the switch. So very large halls and buildings that already have a 100 V line are often better served by the analog approach, and evacuation announcements need certified voice-alarm equipment.

In SIP mode each speaker registers on the PBX like an extension and answers automatically when it is dialed (or when a paging group is called); it is ideal for live announcements from phones, but the PBX sends a separate audio stream to every speaker, so the load on the PBX and the network grows with the number of speakers. In multicast mode the source sends a single RTP stream to a group address and all member speakers play it together; no server is needed and the network load stays constant, but the stream is one-way and the switches must be configured for IGMP. In standalone mode each speaker plays its stored files by schedule or from its alarm input and depends on no server or console, but every speaker has to be configured separately. Real projects usually combine them: bells and fixed programs standalone, music and group announcements by multicast, and live announcements from phones by SIP.

Yes. Paging, scheduled playback, SIP calls and multicast all run inside the local network and the audio path does not depend on the internet; the KDT console also runs paging and music on the local network and works without internet, needing it only for remote access and notifications. Only two things need attention: the clock and online content. Point the speakers to an NTP server inside the network (or set the time manually) so that schedules stay accurate, and remember that internet radio and cloud text-to-speech need internet, while files stored in the speaker and its own web page do not.

For rooms, corridors, classrooms and shops with a false ceiling choose a ceiling model: KA-iC25-P (25 W, 5.5 inch) or the stronger KA-iC35-P (35 W, 6.5 inch); with the dedicated accessory (see the datasheet) they can also be installed on an exposed ceiling. For halls, gyms, workshops and other spaces without a suitable ceiling choose an indoor wall model: KA-iW45-P (45 W) or KA-iW55-PB (55 W, with two speaker units of 6.5 and 1.5 inch). For yards, parking lots, campuses and factory exteriors use the KA-OH25-P horn (25 W, IP66), whose 380 Hz to 8 kHz range suits speech and alarm tones. All five run on PoE (IEEE 802.3at) or a 12 V adapter and support SIP, multicast, scheduled playback and an alarm input; the indoor models are IP44, so keep them out of the rain.

The hardware is the same in both: PoE power (IEEE 802.3at) or a 12 V adapter, internal memory for audio files and alarm inputs; the difference is the firmware they run. The Germanium model has the current firmware and supports SIP, RTP, multicast, MQTT and HTTP, manual, scheduled, multicast and event-linked playback, audio processing (AEC, AGC and ANS), and integration with the KDT console, NVRs, cameras and KDT video management software. The Germanium Smart model is the same hardware with firmware written by KDT's software team; it handles SIP calls, multicast paging and music from the KDT console, and adds priority between audio sources, grouping speakers without a console, group commands such as a siren, a clip or text-to-speech (TTS) on a whole group, and updates from KDT's server that automatically return to the previous version if a new one fails to start. For paging, scheduled playback and alerts together with KDT video systems the Germanium model is enough; if you need priorities between audio sources, group alerts without a console or text-to-speech, choose Germanium Smart.

IEEE 802.3af (PoE) provides up to 15.4 W at the switch port, of which at most 12.95 W reaches the device; IEEE 802.3at (PoE+) provides up to 30 W at the port and 25.5 W at the device, and 802.3bt goes up to 60 W and 90 W at the port. A speaker can draw much more power than a phone or a camera when it plays loudly, which is why the specifications of the KDT Germanium speakers list IEEE 802.3at: connect them to PoE+ ports, or use a PoE+ injector or the 12 V adapter. Besides the class of each port, check the total PoE budget of the switch in its datasheet, because a 24-port switch does not necessarily supply 30 W on every port at the same time. The maximum cable length is 100 m in every case.

The watt figures on a datasheet describe the capability of the amplifier and the speaker, but the average power a PoE port can feed is limited: a PoE+ device may draw at most 25.5 W in total (12.95 W on 802.3af). Assuming about 10% loss in the power converter, about 2 W for the processor and network circuits and roughly 85% efficiency for a Class D amplifier, about 18 W of continuous audio power is left on PoE+ and about 8 W on standard PoE (typical values). Speech and music usually have an average power of only 3 to 10% of their peaks, so peaks can be higher, but a siren or tone loads the supply continuously, and the 12 V, 2 A adapter (24 W) is in the same range. The difference is smaller than it sounds: 55 W instead of 18 W is only about 5 dB louder, so compare models by sensitivity and maximum SPL, and add speakers when you need more level.

Use PoE wherever a PoE+ port is available: one cable carries both power and audio, and a single UPS behind the switch keeps all the speakers alive during a power cut. The network cable (Cat5e or better, solid copper rather than CCA) can be up to 100 m; for longer distances put a switch or PoE extender near the speaker, or use fiber with a media converter. Use the 12 V, 2 A adapter (24 W) where there is no PoE, for example for a horn on a pole, and keep the DC cable short because the voltage drops along it: at 2 A, 20 m of 1.5 mm² cable loses about 0.9 V (about 8%), while 2.5 mm² loses about 0.56 V (about 5%). Unless the manual explicitly allows it, do not power a speaker from both sources (PoE and adapter) at the same time.

Plan on about 30 W per PoE+ speaker unless the switch measures real consumption: a switch with a 240 W PoE budget powers 8 speakers, one with 370 W powers 12, and 24 speakers need 720 W. The number of PoE ports in the specifications does not mean full power on every port at the same time, so read the total PoE budget of the switch. The audio itself is light: a G.711 stream is about 87 kbps on Ethernet, under 0.1% of a 100 Mbps port, so the PoE budget, not the bandwidth, limits how many speakers you can connect. If announcements must also work during a power cut, put the switches on a UPS.

KDT Germanium speakers have one RJ45 Ethernet port (10/100 Mbps) and their datasheets list no Wi-Fi, so a wireless connection means linking them through a bridge or an access point in client mode, with power supplied separately by the 12 V adapter or by a PoE port on the bridge. The weak point of Wi-Fi is multicast: multicast frames are sent at the lowest basic rate and without acknowledgement, so paging can stutter or drop; use a point-to-point bridge with IGMP snooping or multicast-to-unicast conversion, or use SIP (unicast) for that speaker. Audio needs steady delivery rather than high speed, so build the link with a good signal margin and test it with a long announcement before handing over.

The source sends one RTP audio stream to a group (multicast) address, and every speaker set to that address and port plays it at the same time; speakers that have not joined the group receive nothing. Take the address from 239.0.0.0/8 (for example 239.255.10.1 for the first zone), avoid 224.0.0.x, and also avoid 239.0.0.x and 239.128.0.x because they share a MAC address with the 224.0.0.x range, which switches always flood to every port. Use an even UDP port for RTP (the next odd port is reserved for RTCP), give each zone its own address or port, and choose G.711 (PCMU or PCMA) with 20 ms packets, the most widely supported format for paging. The settings of the sender and of all speakers in the group must be identical.

Give each zone its own multicast address (or its own address and port), for example 239.255.10.1 for the ground floor and 239.255.10.2 for the first floor; paging one zone then means sending to one address. An all-call means announcing to every speaker: either a common address that all speakers listen to in addition to their zone address (if the model supports several addresses), or the sender transmits to the addresses of all zones at once. Divide zones by how people use the space (floor, wing, classroom, outdoor area), not by which switch the speakers happen to be connected to, and keep a table of the addresses for future expansion. The KDT console also sends paging and music to groups of speakers, and each group can be treated as a zone.

Speakers announce with IGMP messages that they want to receive a multicast group, and a switch with IGMP snooping listens to these messages and forwards the stream only to those ports; without snooping the switch floods the stream to every port like broadcast traffic. Snooping needs a querier, a device (normally the router or a switch with the querier enabled) that asks every 125 seconds who is still listening. If a VLAN has no querier, the memberships expire after about 260 seconds and audio that started fine stops after four to five minutes. Turn on IGMP snooping, enable exactly one querier per VLAN, and check in the switch's multicast table that the speaker ports are listed.

A router does not forward multicast unless multicast routing (PIM) is enabled, and many senders use a TTL of 1, so the packets die at the first router. To cross VLANs, enable multicast routing on the layer 3 switch or router (usually PIM sparse mode with IGMP on each VLAN) and set the sender's TTL higher than the number of routers on the path (at least 2), or place the paging source in the same VLAN as the speakers. The simplest design for a small system is to keep the speakers and the console or paging source in one VLAN; on larger networks use SIP (unicast) between subnets, where normal routing applies, or ask the network administrator to enable multicast routing only for the paging addresses.

KDT speakers support G.711 (A-law and μ-law at 8 kHz), G.722 (16 kHz) and MP3 (44.1 kHz). G.711 carries only the telephone band of about 300 to 3400 Hz at 64 kbps, but every paging source understands it, so it is the safe choice for live announcements and speech; G.722 roughly doubles the audio bandwidth (about 50 to 7000 Hz) at the same 64 kbps and gives clearer, more natural speech when both the sender and the speakers support it. For background music and stored jingles use MP3 (128 kbps is a good compromise) or WAV, because speech codecs sound thin on music. Set the same codec on the sender and on all speakers of a zone.

Sensitivity is the level a speaker produces at 1 m with 1 W of input, so the level at 1 m with power P is SPL = Sensitivity + 10 × log10(P). For example, a speaker with 90 dB sensitivity driven with 10 W gives 90 + 10 = 100 dB at 1 m, and only 90 dB with 1 W. Doubling the power adds just 3 dB (ten times the power adds 10 dB), so a difference of a few dB in sensitivity matters as much as a large difference in watts. The Max SPL in the datasheet is usually the highest level at 1 m for short peaks (check the test conditions in the datasheet), and it is more useful for planning than the watt figure.

In open air the level drops by about 6 dB with every doubling of the distance from the speaker (drop = 20 × log10(d2/d1), the inverse square law). For example, 100 dB at 1 m becomes 94 dB at 2 m, 88 dB at 4 m, 82 dB at 8 m and 76 dB at 16 m. Indoors, reflections stop the level from falling that fast, and in a reverberant room it levels off beyond a certain distance, so treat the rule as a first estimate for placing speakers, and measure the real level at the farthest listening position with a sound level meter or a sound measurement app.

A common design rule is to make speech 10 to 15 dB louder than the background noise at the listener's position: with 50 dB(A) of noise in an office, 65 dB(A) in a busy shop and 75 dB(A) on a production floor, for example, the targets are roughly 60 to 65, 75 to 80 and 85 to 90 dB. Calculate the level with the formulas above, or measure it with a sound level meter while playing pink noise or a test announcement. In very noisy places add more speakers closer to the people instead of raising the volume, because sustained exposure above 85 dB(A) can damage hearing and very loud speech distorts and becomes less intelligible.

Start from the geometry: at ear level a ceiling speaker covers a circle of radius (ceiling height minus ear height) × tan(coverage angle ÷ 2). With a 3 m ceiling, an ear height of 1.2 m and a 100° coverage angle, the radius is 1.8 × tan 50° = 2.15 m, so the speakers can be about 4.3 m apart edge to edge, which is roughly one speaker per 18 m² of floor. A 10 by 20 m room then needs about 15 speakers in a 3 by 5 grid, and a 60 m corridor about 14 speakers spaced 4.3 m apart; with taller ceilings the spacing grows. Take the coverage angle from the datasheet (typically around 90 to 120°) and place speakers closer for better speech clarity or in noisy rooms.

Usually not: in a reverberant hall (a gym, a large prayer hall or a lobby with hard walls) a powerful speaker mainly excites the room, and the reflections smear the speech. Intelligibility improves when the direct sound dominates, so use more speakers of lower power placed closer to the listeners, aim them at the audience and away from hard walls, and keep the level moderate. Sound-absorbing panels and carpet also reduce the reverberation, and in echoing rooms recording or reading announcements slowly with short sentences helps a great deal.

This horn has a sensitivity of 106 dB (1 W at 1 m) and a coverage pattern of 90° horizontally by 30° vertically, so it sends its sound forward in a wide, flat fan. As a rough free-field estimate, if it delivers 10 W of real audio power it produces about 116 dB at 1 m, which falls on axis to about 86 dB at 32 m and 80 dB at 63 m; with 70 dB of ambient noise that is about 10 dB above the noise at 60 m. Wind, temperature layers, reflections and obstacles reduce this range and the level falls quickly off axis, so mount the horn about 3 to 5 m above the ground, tilted slightly down toward the area to be covered, and use several horns facing different directions for large yards. Its frequency range of 380 Hz to 8 kHz suits speech and sirens better than music.

The first IP digit shows protection against dust and objects and the second protection against water (IEC 60529). IP66 means completely dust-tight and protected against powerful water jets, so the KA-OH25-P horn can be mounted outdoors in the rain. IP44 means protection only against objects larger than 1 mm and against splashing water, which is enough for dry or occasionally damp indoor rooms but not for rain, so the indoor ceiling and wall models (IP44) must not be installed outdoors or where water can hit them directly. Outdoor installation also needs a sealed cable entry, a drip loop in the cable and surge protection; KDT speakers list 6 kV surge protection in their specifications.

Upload the bell, announcement or music files to the speaker's internal memory, then create a schedule entry for each with the time, weekdays, file and volume. Before that, set the speaker's time zone and point it to an NTP server, because a clock that is one minute fast or slow shifts every bell by one minute. If music plays at the same time as a bell, make sure the bell can interrupt it (a priority setting or a separate schedule that stops the music), and test a full day before handing over. With many speakers it is easier to use one central source, such as a console or paging software that sends multicast to groups at the scheduled times, than to edit dozens of speaker web pages; KDT speakers support scheduled playback of stored files and can also be driven from the KDT console.

Prayer times change every day: in Tehran, for example, the dawn and sunset prayer times move by up to about 1.5 minutes per day around the equinoxes and by more than 40 minutes within a month, so a schedule that simply repeats the same time every week soon becomes wrong. There are two solutions: enter the exact time of each day in the schedule and update it weekly or monthly from an official prayer-times table for your city, or use a controller or software that calculates the times and triggers the speaker at each one (for example through a network command or the alarm input). Use a short, clean recording, set the speaker's time zone and NTP first, and make sure the azan does not clash with music or bells at the same time; for a prayer room or mosque it is best to give the azan its own zone and a fixed volume, and to retest in the seasons when the times change quickly.

The datasheets of KDT speakers list MP3, WAV and PCM audio files, with 100 MB of internal memory in the KA-OH25-P and KA-iW45-P and 150 MB in the KA-iW55-PB, KA-iC25-P and KA-iC35-P. As a guide, 100 MB holds about 104 minutes of 128 kbps MP3 (about 156 minutes in 150 MB) but only about 19 minutes of 44.1 kHz 16-bit mono WAV, so use MP3 for long music and short WAV files for bells and messages. Prepare the files as mono at 44.1 kHz, trim the silence at the start and end, and normalize the level of all files so that they play at the same volume setting. Files are uploaded through the speaker's own web page.

Record in a quiet room with a close microphone, speak slowly in short sentences, and put the most important information first and again at the end. Start with a short chime of one or two seconds so that listeners stop talking and listen, keep the message under about 30 seconds, and export it as mono MP3 (128 kbps) or WAV at 44.1 kHz without clipping, with the peaks about 1 dB below full scale. Test each file on the farthest speaker of the zone and adjust the speaker's volume rather than pushing the file level too high. If your visitors speak several languages, prepare the same message in a separate file for each language.

Text-to-speech (TTS) turns a typed message into speech and is useful for messages that change often, such as names, room numbers or times. Cloud voices sound the most natural and cover the most languages but need internet access and a service, while offline voices run on the device or on a local server, work without internet and sound more robotic. In the KDT range, the Germanium Smart model adds running a clip or a TTS message on a whole group of speakers. Write the text the way it should be spoken (spell out numbers and abbreviations), keep it short, and test the pronunciation of Persian or Arabic names before real use.

Register each speaker on the PBX as an extension that answers automatically; then dial that extension to speak to one location, or create a paging group in the PBX that contains several speakers and dial the group number to speak to them all. The datasheets of KDT speakers list compatibility with PBX systems, the KDT VoIP server, Asterisk and FreePBX. The PBX sends a separate stream to each speaker, so large groups load the PBX and the network more than multicast does, and for many speakers a paging source that uses multicast is the better choice. Restrict which extensions may page, in the PBX itself, and remember that live paging over SIP normally uses G.711 or G.722; a SIP desktop paging microphone such as the KV-TDC-ISM-P is more convenient than picking up a handset.

The KDT console sends paging and music as multicast to groups of speakers, so every speaker in a group plays the same stream at the same time; this runs on the local network and needs neither a PBX nor internet. You can page from the console itself or from a browser connected to it, choosing the group that should hear the announcement. If a speaker of the group stays silent, the most common cause is that IGMP snooping and a querier are not set up correctly on the switches.

A well-designed system ranks the sources by priority: usually the emergency alert first, then live paging or a SIP call, then scheduled bells and announcements, and background music last; a higher-priority source interrupts a lower one and the music resumes afterwards. Without priorities, depending on the device, either the source that arrived first or the one that started last plays, and a siren may be stuck behind music. In the KDT range, the Germanium Smart model adds priority between audio sources so that an emergency siren and a SIP call always come before music and radio; if your project needs this behavior, choose that model or define the priority in the sender software. Before handing over, test the scenario while music is playing.

Each speaker plays the stream with its own buffer and clock, so small differences appear: two clocks that differ by 50 ppm drift apart by 30 ms in 10 minutes and by 180 ms in an hour, and different buffer sizes or models add a fixed offset. Our ears fuse the sound of several speakers into one when they arrive within about 30 ms of each other, but a difference of more than about 50 ms is heard as a separate echo, which is easy to notice where the coverage of two speakers overlaps, for example in a corridor. Use multicast so that all speakers receive the packets together, keep the network wired, use the same model and firmware in overlapping areas, and if an area has echo, separate the zones or lower the volume of the overlapping speakers. Sample-accurate synchronization needs a shared clock (such as PTP), which basic paging speakers usually do not have.

Yes: KDT speakers have an alarm input (a normally open trigger) and can receive network (HTTP) commands from KDT NVRs, cameras and video management software, so events such as motion detection or an alarm activation can instantly play a stored siren or voice message on the right speaker. For a burglar alarm panel, connect its relay output to the speaker's alarm input following the wiring diagram in the manual, check the input type and polarity there, and assign the message that should play; in a larger system select the speakers by area with the software's event rules. Use a different message for each type of event (intruder, fire, access) and set the volume to suit the area. This use is for security and information messages and does not replace a fire evacuation system.

Not automatically. A voice alarm system for evacuation is certified as a whole: the loudspeakers must comply with EN 54-24, the control equipment with EN 54-16 and the power supply with EN 54-4, with supervised speaker lines and battery backup, and a general-purpose IP speaker on an ordinary network has none of this. Unless a speaker's datasheet explicitly lists EN 54-24 and a certificate is available, treat it as a general paging and alert speaker, for everyday announcements, security messages or as a supplement to the certified system. For evacuation, follow your local fire regulations and use certified voice alarm equipment; IP speakers can still carry the everyday announcements of the same building.

Treat them like any network device: set a strong, unique password for the web page during installation, keep the speakers in their own VLAN, and allow only the PBX, the console or the management PC to reach them, using a firewall or ACL. Use HTTPS for the web page, disable protocols you do not need and keep the firmware up to date; the specifications of KDT speakers list JWT (HS256) security. For SIP, accept calls only from your PBX or your own phones (for example by restricting the source address in the firewall) so that nobody else can play audio, and never expose a speaker's web or SIP port to the internet. The main risk is not data theft but somebody triggering announcements or sirens, so restrict who can send audio.

IP speakers do not have supervised speaker lines like voice alarm systems, so their health has to be checked with network methods: ping or periodic polling of the speakers with a network monitoring tool, and the web page of each speaker. A periodic audio test also reveals an amplifier or speaker fault that ping cannot see, for example a short chime at low volume every morning before people arrive. Keep a list of the speakers with their IP address and location (fixed IP or DHCP reservation) and make a test announcement after every power cut.

Check in this order: the power (a port that supplies less than 30 W or is out of budget can leave the speaker rebooting or quiet), the volume on the speaker and on the source, the selected source and priority (a higher-priority source or a stopped schedule can block playback), and the network path. For multicast, confirm that the speaker uses the same address, port and codec as the sender and that IGMP snooping has a querier; for SIP, check the registration; for files, check that the format is supported and the file is not corrupted. Playing a stored file from the speaker's own web page separates a speaker problem from a network or sender problem within a minute.

A siren or test tone is a continuous signal and draws far more power than speech or music, which are mostly quiet between the peaks. If the PoE port cannot deliver 30 W (an 802.3af port, an exhausted switch budget, a thin, long or CCA cable, or a damaged connector), the voltage sags and the speaker distorts, mutes or restarts. Try the same speaker on another PoE+ port with a short, known-good patch cord or on the 12 V adapter, lower the volume, and check that the audio file itself is not clipped (peaks that reach the maximum sound distorted on any speaker). If the problem disappears with the adapter or a direct connection, the cause is the switch, the cable or the power budget.

The microphone picks up the sound of the speakers in that room, and when the loop gain reaches one the system howls (acoustic feedback). IP audio also arrives late, typically from a few tens of milliseconds to about two hundred after your voice (network buffers and the codec), so you hear your own voice as an echo. The reliable fix is to exclude the zone where the announcer stands from the page, or to page from a room without speakers; otherwise use a directional microphone close to your mouth, keep it away from the speakers and lower the volume of the nearest speakers.

The specifications of all five KDT speaker models list the microphone as N/A, which means these speakers only play sound and do not pick up the room. That is enough for one-way announcements, music and bells, with the announcement itself coming from an IP phone, a paging microphone or the console. For two-way conversation, for example at a building entrance, you need a device with a microphone such as a SIP intercom or phone, and the IP speaker can only repeat its sound over the area. So do not count on these speakers for listening to the environment or for getting an answer from a person.