IP Phones

Work from the bottom up, one layer at a time, because each layer depends on the one below it. First check power and link: the screen is lit, the switch port shows link (and, if the phone runs on PoE, PoE is enabled on that port with budget left) and the cable is no longer than 100 meters. Then check that the phone has a valid IP address (no address, or 0.0.0.0, means DHCP failed, often because of a wrong VLAN or DHCP scope) and that its SIP account shows Registered; if not, verify the server address, extension, password and transport, and whether the PBX has banned the phone's IP. If calls ring but the audio is missing, one-way or choppy, look at NAT and firewall settings, RTP ports, codecs, jitter and packet loss. Finally, swap in a known-good phone, or move this phone to a known-good port, to learn whether the fault is in the phone or in the network.

An analog phone carries the voice as an electrical signal over a copper pair to a PBX or the telephone exchange and draws its power from that same line. An IP phone digitizes the voice, sends it as RTP packets over the Ethernet network, sets calls up and ends them with SIP and is powered by PoE or an adapter, so it needs an IP-PBX or another SIP device to work with. In practice a single network cable serves both the phone and the PC, the extension number follows the phone to any network outlet, and features such as HD voice, programmable keys and a shared directory become available. The price is that the phone depends on the network and on power, so the switch and the PBX need a UPS and a properly designed network. Existing analog phones and fax machines can be kept by connecting them through an FXS adapter or gateway.

SIP (Session Initiation Protocol), defined in RFC 3261, is the IETF standard for setting up, changing and ending calls; messages such as REGISTER, INVITE, 180 Ringing, 200 OK, ACK and BYE carry the call signaling, normally on port 5060 (5061 for TLS). The voice itself does not travel inside SIP: the two ends agree on codecs and addresses using SDP inside the SIP messages, and the audio then flows as RTP (RFC 3550) on separate UDP ports, which is why a phone can ring and still have no audio. Because SIP is an open standard, phones, door stations, gateways, IP speakers and PBXs from different makers work together and you are not tied to one PBX brand. Vendor-specific extras, such as special key functions, may still depend on the PBX.

If the phones support direct IP calling, two SIP phones can call each other without a PBX by dialing the other phone's IP address (for example 192.168.1.20); this is enough for two or three phones, or for a door station that rings a single indoor phone. Without a PBX, however, there are no extension numbers, ring groups, voicemail, call recording or outside lines, and every device needs a fixed IP address. As soon as you have more than a handful of phones, need city lines or a SIP trunk, or want central management, use an IP-PBX such as an Asterisk-based system (for example FreePBX or Issabel), which can also run on a small server or a virtual machine. Direct IP calls inside the LAN keep working even when the PBX or the internet link is down.

Yes. KDT Radonium phones use standard SIP 2.0 (RFC 3261) over UDP, TCP or TLS, and KDT lists their compatibility with platforms such as Asterisk, FreePBX and BroadSoft; Issabel is built on Asterisk, and any PBX that follows the SIP standard can register them as extensions. Basic features such as hold, transfer, call forwarding and local conference work with any standard PBX, while server-dependent features such as BLF, call pickup, call parking and the message-waiting indicator must also be configured on the PBX itself. For a trouble-free start, keep at least one common codec enabled on both sides and set the same DTMF method on the phone and on the PBX. As with any interoperability project, test one pilot phone against your own PBX before ordering a large quantity.

Choose by the number of lines and DSS keys each desk really needs, not by price alone. The entry-level KV-N2S4 series (4 SIP lines, 2.4-inch color screen, 3 DSS keys) is enough for most staff; the Prime KV-N4S12 (12 lines, 3.5-inch screen, 21 DSS keys) suits managers and heavy callers, and the KV-N4S12-PH adds a Bluetooth wireless handset. For receptionists, secretaries and operators who watch the status of many extensions, the enterprise KV-M3S12 (12 lines with a side display) and KV-M4S20 (20 lines, two side displays, up to 106 DSS keys and video call reception) are the best fit. The same family also includes the KV-IC06-ISMO SIP intercom for entrances and the KV-TDC-ISM-P desktop paging microphone for public announcements.

The suffixes distinguish versions of one model, and the KDT product pages show these differences: the product pages describe the P versions with Gigabit network ports and the PF versions (for example KV-N2S4-PF) with Fast Ethernet ports at 10/100, although the specification tables of some PF pages list 10/100/1000, so confirm the port speed in the datasheet of the exact model before ordering; all of these phones support PoE. The KV-N4S12-PH adds a Bluetooth wireless handset to the KV-N4S12-P, and the flagship KV-M4S20-PX has larger side displays (3.5 inches instead of 2.4 inches) and more DSS keys (106 instead of up to 60) than the KV-M4S20-P. The V2 and V3 suffixes (for example KV-N2S4-PF/V2 and KV-N2S4-P/V3) are presented on the same pages as newer, improved versions of the base model; if you need the exact difference between two versions, compare their datasheets side by side.

Not exactly. A SIP line is really an account: the phone can be registered with that many different extensions or servers at the same time, for example one extension on the head-office PBX and one on a branch PBX. How many calls the phone can handle at once (the active call, calls on hold and a waiting call) is a separate matter, and each account can usually carry more than one call. One or two accounts are enough for an ordinary desk, while extra lines are useful for reception desks, secretaries and shared phones that answer several numbers. For example, the KV-N2S4 has 4 SIP lines, the KV-N4S12 and KV-M3S12 have 12 and the KV-M4S20 has 20.

On the phone's account (line) page you enter the SIP server address (IP or domain name) and its port (5060 by default), the extension number (user ID), the authentication name if the PBX defines one separately from the extension, the password set for that extension on the PBX, and the transport (UDP, TCP or TLS). An outbound proxy is needed only when the service provider or the network design requires it. After you save, the phone sends a REGISTER, the PBX challenges it with a 401 response asking for digest authentication, and the phone answers with its name and password. From then on the account shows as registered on the phone and in the PBX's list of registered extensions, and the phone renews the registration before it expires (3600 seconds is a common value).

Go step by step: the phone has a valid IP address, gateway and DNS and can ping the PBX; the server address, port and transport on the phone match the PBX; the extension exists on the PBX; and the user name, authentication name and password are identical on both sides. A 401 response that keeps repeating means a wrong name or password, while a 403 means the PBX is refusing the request on purpose; so check that the PBX has not banned the phone's IP after earlier failed attempts (for example with fail2ban), that the extension is not restricted to a particular subnet, and that no firewall or ACL between VLANs blocks the SIP port. If no response arrives at all and the request times out, the cause is more likely routing, a firewall or a wrong server address or port than the password. If everything looks right, capture the SIP messages with the Packet Dump function on the phone's web page (listed in the datasheets of KDT phones) to see exactly which response the PBX returns.

It depends on the PBX and its settings: an extension can usually be configured to accept several registrations and ring all the devices together, but many setups allow only one device per extension, and then the second device is either refused or pushes the first one out. A more predictable design is to give the softphone its own extension and ring both extensions at once with a ring group, which also shows which device answered. A softphone used outside the building must connect like any remote extension, over a VPN or with SIP over TLS and SRTP. A mobile softphone also needs push-notification support, otherwise it can miss calls when the operating system puts the app to sleep.

G.711 sends narrowband speech (300 to 3400 Hz) uncompressed at 64 kbps and is universally supported; it comes in two variants, A-law (PCMA), used in Iran and most countries, and µ-law (PCMU), used in North America and Japan. G.722 uses the same 64 kbps but carries wideband speech (50 to 7000 Hz), so on a LAN it sounds clearly better at no extra bandwidth cost. G.729 compresses narrowband speech to 8 kbps at slightly lower quality and suits limited WAN links, while Opus is a flexible codec from 6 to 510 kbps that adapts to network conditions and is common in softphones and WebRTC. A practical order is G.722 first and then G.711 A-law on the LAN, and G.729 or Opus on constrained links; both ends must share at least one codec, otherwise the PBX has to transcode, which costs processing power and quality.

HD (wideband) voice carries about 50 to 7000 Hz instead of the 300 to 3400 Hz of an ordinary phone call, using wideband codecs such as G.722 or Opus, so speech is clearer and names and numbers are easier to understand. Both ends must agree on a wideband codec, so place G.722 (or Opus) above G.711 in the phones and in the extension settings on the PBX, and use HD-capable handsets, speakers and headsets. The whole call path must be wideband: if any part is narrowband, such as a PSTN line through an FXO gateway, an analog phone on an FXS port or the PBX transcoding to G.711 or G.729, the whole call becomes narrowband. KDT Radonium phones list the G.722 wideband codec and, on most models, Opus as well (check the datasheet of your model), so internal calls between them are HD as long as the PBX allows a wideband codec that both ends support.

Every voice packet carries headers in addition to the codec payload: 12 bytes of RTP, 8 of UDP, 20 of IPv4 and 18 of Ethernet (a 14-byte header plus a 4-byte FCS). With G.711 at the default 20 ms packet time the payload is 160 bytes, so each frame is 218 bytes and 50 frames per second give 218 × 8 × 50 = 87.2 kbps per direction on Ethernet (80 kbps at the IP layer, or 95.2 kbps if the 8-byte preamble and the 12-byte inter-frame gap are counted too). The same headers make G.729 (8 kbps codec, 20-byte payload) use about 31.2 kbps, almost four times its codec rate. A longer packet time reduces the overhead, for example G.711 needs about 79.5 kbps at 30 ms and 75.6 kbps at 40 ms, but it adds delay and makes each lost packet more audible, so 20 ms is the usual choice and 30 to 40 ms is used only on constrained links.

Choppy or robotic audio almost always means that packets arrive late or not at all, so the phone's jitter buffer cannot fill the gaps. Commonly used design targets for voice are one-way delay under 150 ms (ITU-T G.114), jitter under about 30 ms and packet loss under 1 percent. The usual causes are a saturated uplink or VPN (a large download or backup competing with voice), Wi-Fi with a weak signal, a duplex mismatch or a faulty cable (look for CRC errors on the switch port), an overloaded PBX or router CPU, and transcoding between codecs. Measure before you change anything: ping the PBX for a few minutes and read the loss and jitter figures from the phone's call statistics, from RTCP-XR reports or from the RTP stream analysis in Wireshark, then fix the cause, for example with QoS, uplink shaping or by moving the phone to a wired port.

Echo is heard by the person who is talking, so the fault is usually at the other end of the call and not in your own phone: either the other party's speakerphone microphone is picking up their loudspeaker, or an analog gateway is reflecting your voice. Echo becomes clearly noticeable once the one-way delay exceeds about 25 ms, which is why IP paths need echo cancellation, while a local call on an old analog line had too little delay for echo to be noticed. The fixes are to lower the speaker volume and keep the microphone away from it, use the handset or a headset, enable the phone's acoustic echo cancellation (AEC) and, on FXO and FXS gateways, enable echo cancellation (ITU-T G.168) and check the impedance and gain settings. If the echo appears only on calls to PSTN lines or mobile numbers, ask the gateway administrator or the line provider to check their echo canceller.

Most IP phones are IEEE 802.3af devices: the port guarantees 15.4 W and the phone may draw up to 12.95 W, with class 1 covering up to 3.84 W, class 2 up to 6.49 W and class 3 up to 12.95 W. Simple phones typically draw about 2 to 5 W, while models with big color screens or side displays draw more. The datasheets of KDT phones list PoE consumption between about 1.3 W and 12.1 W depending on the model and the load (the highest figure belongs to the KV-N4S12-PH), so even the highest figure stays within the 12.95 W that an 802.3af port can deliver to a device; confirm the PoE class in the datasheet of your model. If the switch has no PoE, use a PoE injector or the phone's power adapter, and in either case keep the cable between switch and phone to Cat5e or better and no longer than 100 meters.

Add up the power each port reserves and keep the total below the switch's overall PoE budget: a switch usually reserves by the phone's class, so 24 class 2 phones reserve 24 × 7 W = 168 W, while a phone that is not classified reserves 15.4 W and 24 phones of that kind need 24 × 15.4 = 369.6 W. Some switches allocate power through LLDP negotiation or by actual consumption and waste less of the budget; check the switch's datasheet for the method it uses and for its total budget in watts. If a phone restarts under load, for example when ringing or using the speaker, suspect a port power limit that is too low, an exhausted switch budget, or a poor cable or one longer than 100 meters. To be sure, power the phone from its adapter: if the problem goes away, the cause was the PoE supply.

A voice VLAN puts phone traffic in its own VLAN and IP subnet, separate from the office PCs, so that broadcasts and data traffic cannot disturb calls and QoS and security rules can be applied to voice alone. The phone tags its own frames with an 802.1Q VLAN ID (and 802.1p priority), while the PC plugged into the phone's second port normally stays untagged in the data VLAN; the switch port is therefore configured with both the data VLAN and the voice VLAN. The switch can tell the phone which VLAN ID, priority and DSCP to use through LLDP-MED (or CDP on Cisco networks), or you can enter the VLAN ID on the phone by hand. If a phone gets no IP address or does not register, first check that its VLAN ID matches the switch port and that the voice VLAN has its own DHCP scope; the datasheets of KDT phones list support for VLAN and LLDP.

Voice media (RTP) is normally marked DSCP EF (Expedited Forwarding, value 46, which is 0xB8 in the IP ToS byte) with 802.1p priority value 5, while SIP signaling is commonly marked CS3 (value 24). Marking alone does nothing: the switches and the router must trust these marks on the phone ports and serve the voice queue first (for example a strict-priority queue for EF), and it matters only where a link can become congested, typically the uplinks and the WAN or VPN link. On the public internet DSCP marks are usually ignored or rewritten, so QoS helps only on links you control, such as your LAN, a private WAN or a shaped uplink (set the router's shaper slightly below the real uplink speed so the queue forms in your own router). The phone itself takes its DSCP and priority values from its own settings, from LLDP-MED or from auto-provisioning.

SIP signaling and RTP audio take separate paths: if SIP gets through but RTP does not, the phone rings and the call connects, yet there is no audio or only one-way audio. The cause is usually NAT or a firewall: a phone behind NAT announces its private address (for example 192.168.1.50) in the SDP, so the other side sends its audio to a place that does not exist. To fix it, set the PBX's public address and local networks correctly (in Asterisk-based PBXs such as FreePBX, the NAT settings with External Address and Local Networks), enable symmetric RTP so audio is returned to the address and port it came from, use STUN and keep-alives for phones behind NAT, turn off SIP ALG on the router, and leave the RTP port range open in the firewall. If the problem occurs only between two internal subnets, check routing and ACLs between the VLANs and whether the PBX lets the audio flow directly between the two phones (direct media).

STUN (RFC 5389, now replaced by RFC 8489) lets a phone ask a server outside the NAT which public address and port the NAT has given it, so that it can write those into its SIP and SDP messages. This is enough for most home and office NATs, but it does not work behind a symmetric NAT, which gives a different port for every destination; there you need TURN, an SBC or a VPN. Keep-alives are small packets that the phone sends, for example every 20 to 30 seconds, so that the NAT does not close the UDP mapping; many routers forget an idle mapping after 30 seconds to a few minutes, and from then on incoming calls no longer reach the phone. If the phone and the PBX are on the same network, or the phone connects to the company network by VPN, STUN is normally not needed, but for remote phones that connect directly to a public PBX enable STUN and keep-alives together with symmetric RTP on the PBX; STUN is listed in the datasheets of KDT phones.

SIP ALG is a feature of some routers and firewalls that rewrites SIP and SDP messages so that they can pass through NAT. In practice it often rewrites them wrongly and causes symptoms such as a registration that keeps dropping, one-way audio and calls that are cut off after about 30 seconds; the last symptom happens because the ACK never reaches the right destination and, following RFC 3261, the PBX stops waiting for it after 64 × T1, which is 32 seconds when T1 is 500 ms, and ends the call. For this reason it is recommended in almost every VoIP project to turn SIP ALG off and to configure NAT on the PBX and the phone instead (public address, symmetric RTP, STUN and keep-alives). If the router does not have the option or it cannot be disabled, use SIP over TLS so that the ALG cannot read and tamper with the messages.

SIP signaling needs port 5060 (UDP and TCP), and 5061 for SIP over TLS, while the audio uses a separate UDP range chosen by the PBX; the default in Asterisk and FreePBX is 10000 to 20000. Every audio stream takes a pair of ports (RTP and RTCP) and a call passing through the PBX has two streams, so a range of 200 ports is enough for about 50 simultaneous calls; keep the range as small as you need and open only that range. If the PBX and the phones are in the same network with no firewall between them, there is nothing to open; ports have to be opened only for remote phones or for a PBX that is reachable from the internet. Never leave the PBX's SIP port open to the whole internet: restrict access to the allowed IP addresses or use a VPN.

There are two common safe options: connect the phone to the company network over a VPN so that it works with the PBX like a local extension (KDT Radonium phones support OpenVPN and L2TP; prefer OpenVPN, or use L2TP with IPsec, because plain L2TP does not encrypt), or connect the phone directly to the PBX's public address using SIP over TLS, SRTP and access limited to allowed IP addresses. A VPN simplifies NAT and firewall issues but adds tens of bytes of header to every packet (for example 50 to 80 bytes, which is about 20 to 32 kbps more per call at 50 packets per second), and an unstable VPN makes the audio choppy. To get through the NAT at home or in the branch, enable the phone's STUN and keep-alives (for example every 20 to 30 seconds) so the router does not close the UDP mapping, and turn off SIP ALG on the router. Judge the quality on the real link at that site: its internet upload speed must be enough for the number of calls and must not collapse in busy hours.

The biggest risk is a PBX that faces the internet: automated tools guess extension passwords around the clock and, if they succeed, place international calls at your expense (toll fraud). Give every extension a unique random password of at least 12 characters (never the extension number or a simple word), disable guest and anonymous calls, allow international and premium-rate calls only for the extensions that need them and set a limit on simultaneous calls per extension. Open the SIP port only to the IP addresses that need it or put the PBX behind a VPN, use a tool such as fail2ban to block addresses that repeatedly send wrong passwords (for example after 5 failures within 10 minutes) and review the call logs for odd patterns such as night-time calls to unknown destinations. On the phones themselves, change the web administration password to a strong one, restrict web access to the management network and keep the firmware up to date.

TLS encrypts the SIP signaling (SIP over TLS normally uses port 5061), so the dialed number, user names and call details are hidden from eavesdroppers. SRTP (RFC 3711) encrypts the voice itself, normally with AES-128, and its key is either carried inside the SDP message (the SDES method, which is only safe when the signaling runs over TLS) or negotiated with DTLS-SRTP. For real call encryption you must enable both and both ends of the call, including the PBX, must support both; the PBX certificate must also be trusted by the phone (a certificate from a public CA, or a self-signed certificate installed on the phone) and TLS 1.2 or later should be used. The datasheets of KDT phones list SIP over TLS and SRTP (optional or compulsory), and the encryption load on a phone's processor is usually small.

When it powers on, the phone finds the address of a provisioning server and downloads its own configuration file from it, usually named after the phone's MAC address. The server address is normally supplied by DHCP Option 66 (other methods are SIP PnP, TR-069 or typing the address by hand) and the file is fetched by TFTP, FTP, HTTP or HTTPS; all of these methods are listed in the datasheets of KDT phones. For a few dozen phones, build one shared template, generate one MAC-based file per phone with its own extension and password, set Option 66 in the DHCP scope of the phone VLAN and restart the phones. Because these files contain the extension passwords, use HTTPS with authentication, or make the TFTP server reachable only from the phone VLAN.

Check the exact model of the phone (for example KV-N2S4-P, KV-N2S4-P/V3 or KV-N2S4-PF) and the current firmware version, and download only the file for that model, because files for similar models are not interchangeable. Before you start, export the phone's settings (the Configuration Export function is listed in the datasheets of KDT phones) and keep the previous firmware file for a rollback. Upgrade one phone first and, after it restarts, test registration, audio quality and keys; then upgrade the rest in batches, by hand or through auto-provisioning. Do not interrupt the power or the network of the phone during the upgrade, and do the work outside busy call hours.

Besides their own local phonebook, the phones can fetch a remote phonebook from a central source, so you keep the contacts in one place and every phone uses them. The two common formats are XML, which the phone downloads over HTTP or HTTPS, and LDAP, where the phone queries a directory server such as Active Directory or OpenLDAP while you search. Set the phonebook address for all phones in one go with auto-provisioning. The datasheets of the KV-N2S4, KV-N4S12 and KV-M3S12 list a 1000-entry local phonebook and a 1000-entry remote XML or LDAP phonebook, and the KV-M4S20 lists a 2000-entry local phonebook; all of these models also support importing and exporting the phonebook.

A DSS key can be set to speed dial (one-touch dialing of an extension or number), to BLF or to functions such as call transfer. With BLF (Busy Lamp Field) the phone asks the PBX for the state of the monitored extension with a SUBSCRIBE message (the dialog event of RFC 4235) and the PBX reports changes with NOTIFY; the key's lamp shows whether that extension is idle, ringing or busy, and the same key can pick up its ringing call or transfer a call to it. BLF works only if the PBX publishes the extension state, which in Asterisk-based PBXs is done by defining a hint for each extension. The number of DSS keys on KDT phones starts at 3 on the KV-N2S4 and 21 on the KV-N4S12 and reaches 106 on the KV-M4S20-PX, so choose the model by the number of extensions that must be watched.

In a blind (unattended) transfer you press Transfer, dial the destination and the call is passed on immediately, so you leave the call without knowing whether the destination answers; if it does not, depending on the PBX settings the caller may go to a queue or voicemail or even ring back to you. In an attended transfer you first put the original call on hold, call the destination, talk to that person and then complete the transfer; if the destination is busy or unavailable you can return to the caller. Both modes are normally carried out with the SIP REFER message and the PBX must support it; the datasheets of KDT phones list both attended and unattended call transfer. At a reception desk, attended transfer gives the better experience because the caller is never sent to an extension that does not answer.

In a local conference the phone itself mixes the audio of all parties: it holds one call per participant and builds the mixed audio for each of them, so the load falls on the phone's processor and your uplink, and it works best when all the calls use the same codec such as G.711 or G.722. The datasheets of KDT phones list a 6-way (for example KV-N2S4 and KV-N4S12) or 3-way (for example KV-M3S12) audio conference depending on the model. For larger meetings, or when many participants are outside callers, use the PBX's own conference room: everyone dials one conference number and the audio is mixed in the PBX. A PBX conference room usually also offers features such as an entry PIN, a moderator and recording, and it does not depend on one particular phone.

The voicemail box lives on the PBX, not on the phone; the phone only shows that a message is waiting and dials the mailbox. For the message-waiting lamp or indicator (MWI), the PBX tells the phone with a NOTIFY message of the message-summary type (RFC 3842) that a new message exists; some phones must subscribe with SUBSCRIBE to receive it while on others the PBX sends it unsolicited, so match this setting on the phone and on the PBX. The phone's Voice Message or Messages key must be set to the number that reaches the mailbox on the PBX (for example the My Voicemail feature code in FreePBX). The datasheets of KDT phones list the VMWI message indicator (or a server-dependent Voice Message function).

In intercom mode the called phone answers immediately without ringing and plays the caller's voice on its speaker. It usually starts at the PBX: when it sends the call, the PBX adds a SIP header such as Alert-Info, Call-Info or Answer-Mode (RFC 5373) and the phone accepts it if auto-answer or intercom is enabled in its settings; the exact header name and value differ between manufacturers and must be taken from the phone's manual. Enable auto-answer only for specific extensions or through the PBX's intercom feature code, and set the phone to trust only calls from the PBX, because a phone that answers every call without ringing can cause nuisance or be misused for eavesdropping. The datasheets of KDT Radonium phones list an Intercom function among their call features, and the KV-M4S20 datasheet also lists Auto-Answering.

There are two common methods. In SIP paging the PBX rings several extensions at once with one group call and they all answer immediately by auto-answer; it is simple to set up, but every destination receives its own audio stream from the PBX. In multicast paging the sender transmits a single RTP stream to one multicast address and every phone or speaker in the group plays it at the same time, so bandwidth use stays constant, but the network must support multicast (IGMP snooping and a querier on the switches) and the paging is one-way. For announcements in halls and other large spaces use network IP speakers instead of phone loudspeakers; the KDT KV-TDC-ISM-P desktop microphone (SIP and MQTT) is built for making such announcements from a control room.

A SIP door phone registers on the PBX like an ordinary extension (or calls an IP address directly) and, when the button is pressed, calls an extension or a ring group; set its codec to G.711 or G.722. The door is normally opened by sending a DTMF code during the call, which makes the door phone switch its lock relay, or by an HTTP request sent from a phone's DSS key (the Action URL function listed in the KV-M4S20 datasheet), so set the same DTMF method on the door phone and the PBX. To see the picture there are two ways: a SIP video call with H.264, which the door phone, the phone (for example the KV-M4S20, which receives video calls up to VGA) and the PBX (with a video codec allowed) must all support, or showing the door camera's RTSP stream on a separate screen.

DTMF (the tones of the digit keys) can be sent in SIP in three ways: RFC 4733, which carries each key press as a telephone-event inside the RTP stream (usually with payload type 101), SIP INFO, which sends it in a separate message, and in-band, where the key tone itself travels inside the audio. If the phone and the PBX (or the door phone and the PBX) do not agree on one method, key presses either never arrive or are counted twice. In-band tones are corrupted by compressed codecs such as G.729 and by packet loss, so select RFC 4733 on both sides and use SIP INFO only for devices that understand nothing else. After changing it, make a test call to the IVR or the door phone and check that the keys are counted correctly.

FXS is the port that serves an analog phone or fax the way a wall telephone socket does (it supplies dial tone, ring voltage and loop current), while FXO is the port that behaves like the phone itself and connects to a PSTN line or to the extension port of an analog PBX. So to connect an analog phone or fax machine to an IP-PBX you need an FXS adapter or gateway (ATA), and to connect a PSTN line you need an FXO gateway; for many lines use an E1 gateway (30 voice channels on 2.048 Mbps), and for a mobile SIM line a GSM gateway. These devices register on the PBX like an extension or a SIP trunk, and call quality on them depends on correct impedance, gain and echo cancellation settings. Audio on these paths stays narrowband like the analog line, so HD voice exists only between IP phones.

Fax was not designed to travel over IP networks and is sensitive to delay, jitter and packet loss, so start with an analog fax machine on an FXS adapter: make G.711 (A-law) the only codec for that extension, turn off silence detection (VAD) and any compression on that port, and keep ptime at 20 ms. If the adapter and the PBX both support T.38, enable it; T.38 (the ITU-T standard for real-time fax over IP) sends the fax data itself instead of the modem tones and tolerates packet loss better. If T.38 is not available, G.711 pass-through on a network without packet loss gives the better result. If you send few faxes, also consider a software or e-mail fax service, which needs no modem tones over the voice path.

A phone normally takes its time from a time server using SNTP or NTP, so if the clock is wrong, first check that the NTP server address in the phone's settings (or from DHCP Option 42) is correct and reachable. On networks where the internet is restricted or down, use a local NTP server, for example the router or an internal server, and give its address through DHCP or in the auto-provisioning file of all phones. Then set the time zone to UTC+03:30 (Iran) and set daylight saving to match the rule where the phone is; Iran has not used daylight saving time since 2022, so switch it off there, otherwise the clock will stay an hour ahead or behind. A correct clock is not just cosmetic: it makes the call times in the PBX reports and phone logs right, and a phone with a wrong date may refuse a valid TLS certificate and fail to register or to provision over HTTPS.

Some models can. The KV-M3S12 supports Bluetooth headsets and Wi-Fi through an optional dongle, the KV-M4S20 models have built-in Bluetooth and support a Wi-Fi dongle, the KV-N4S12-PH comes with a Bluetooth wireless handset and some KV-N2S4 models work with EHS wireless headsets (according to the product pages on the KDT site). For a fixed desk, however, a wired connection is always more stable, and Wi-Fi makes sense only where cabling is not possible. If you do use Wi-Fi for voice, use the 5 GHz band, WMM (voice prioritization), a signal stronger than about -67 dBm and a proper roaming design, because a weak signal turns directly into choppy audio.

If the PBX is inside the building on the local network, internal calls continue without the internet and only outside calls over an internet SIP trunk fail; if the PBX is remote or in the cloud, all calls fail when the link goes down, unless you have a backup link or a local PBX. To keep outside lines alive, put an FXO or GSM gateway next to the SIP trunk so calls can also go through a PSTN line or a SIM card. For power cuts, put the PoE switch, PBX, router and gateways on a UPS sized for their total load; PoE phones then run from the same UPS. If the PBX itself fails, phones that support direct IP calling can still call each other on the same network.

The easiest way is to capture on the phone itself: the web page of KDT phones has a Packet Dump function that saves the phone's traffic for analysis, usually with Wireshark. Another way is to capture on the PBX with tcpdump, or on the switch with port mirroring (SPAN), and open the file in Wireshark; apply the display filter sip or rtp. In Wireshark, open the Telephony menu and look at VoIP Calls (a ladder diagram of the SIP messages) and RTP Streams (packet loss, jitter and packet order); in Asterisk the command pjsip set logger on prints the SIP messages on the console. If the signaling runs over TLS the messages are encrypted and unreadable without the keys, and SRTP also encrypts the audio, so for troubleshooting temporarily use unencrypted UDP or read the PBX's own logs.