VoIP Troubleshooting Guide - CallerID.com

🖶 Print / Save as PDF

VoIP Troubleshooting Guide

Quick Reference ScopeComplete VoIP troubleshooting for all CallerID.com devices — Vertex, POS, and Whozz Calling units

DevicesVertex (VoIP/Ethernet), POS 2/4/8 (Serial/Ethernet), Whozz Calling 2/4/8 (Serial/Ethernet)

SupportCallerID.com — 770.263.7111 — Info@CallerID.com

AudienceTechnicians, IT staff, POS installers, and support agents

Table of Contents VoIP vs. Analog: Choosing the Right Device

VoIP Fundamentals for Caller ID

ATA Adapter Setup with CallerID Devices

SIP Trunk Caller ID Delivery Requirements

Common VoIP Issues

Network Requirements

Vertex VoIP-Specific Configuration

EdgeMarc SBC Integration

VoIP Provider-Specific Notes

Diagnostic Flowchart

Advanced Diagnostics

Frequently Asked Questions

1. VoIP vs. Analog: Choosing the Right Device

The first step in any CallerID.com installation is identifying whether the customer has a VoIP (Voice over IP) or analog (POTS/landline) phone system. The wrong device for the wrong phone system will never work.

1.1 How to Identify the Phone System Type

Indicator Analog (POTS/Landline) VoIP / IP Phones

Phone connection Standard phone cord (RJ11) into a wall jack Ethernet cable (RJ45) into a router/switch, or softphone on computer

Phone hardware Basic handset, no screen or small LCD IP phone with color screen, brand logos (Polycom, Yealink, Cisco, etc.)

Monthly bill from Local telephone company (AT&T, CenturyLink, Verizon landline) VoIP provider (RingCentral, Vonage, 8x8, Comcast Business VoIP, Ooma, etc.)

Wiring at demarc Copper pairs (Cat3 or phone wire) from telephone pole or NID box Ethernet or fiber from ISP; calls ride on internet

PBX present? Possibly analog PBX with analog extensions Cloud PBX, on-prem IP PBX (Asterisk, FreePBX, 3CX), or hosted VoIP

1.2 Device Selection Guide

Phone System Type Recommended CallerID Device Connection Method Notes

VoIP — Unencrypted SIP Vertex Ethernet bridge (inline between router and phone switch) Reads SIP packets directly from network traffic; requires unencrypted SIP on port 5060

VoIP — Encrypted SIP (TLS/SRTP) Vertex + EdgeMarc SBC or Whozz Calling + ATA EdgeMarc decrypts on LAN side; ATA converts VoIP to analog See Section 8 for EdgeMarc; Section 3 for ATA

Analog — 1-2 lines Whozz Calling 2 or POS 2 Serial (RS-232) or Ethernet to POS Connects in parallel to phone lines via RJ11 splitter

Analog — 3-4 lines Whozz Calling 4 or POS 4 Serial (RS-232) or Ethernet to POS Connects in parallel to phone lines via RJ11 splitter

Analog — 5-8 lines Whozz Calling 8 or POS 8 Serial (RS-232) or Ethernet to POS Connects in parallel to phone lines via RJ11 splitter

VoIP with ATA adapter Whozz Calling (any) or POS (any) ATA converts VoIP to analog; unit reads analog signal Best for 1–4 lines; works with any VoIP provider including encrypted

Key Decision: If the customer has VoIP and the provider uses unencrypted SIP, use the Vertex. If the VoIP provider uses encrypted SIP (TLS/SRTP), either deploy an EdgeMarc SBC to decrypt on the LAN side, or use a Whozz Calling/POS unit with an ATA adapter to convert the VoIP lines to analog.

1.3 When to Use an ATA Instead of a Vertex

An ATA (Analog Telephone Adapter) is the simpler solution in these situations:

The VoIP provider uses encrypted SIP and will not provide an unencrypted option

The customer has 4 or fewer phone lines (ATA ports are limited)

The installation environment is non-technical and a simple plug-and-play approach is needed

The customer already has an existing ATA from their VoIP provider

Budget does not allow for an EdgeMarc SBC

ATA Limitation: Most ATA adapters support 1–2 analog lines (some models support 4). For sites with 5+ VoIP lines, the Vertex with an EdgeMarc SBC is the recommended solution, or multiple ATA adapters can be deployed.

2. VoIP Fundamentals for Caller ID

2.1 How VoIP Caller ID Works

In VoIP systems, caller ID information is carried in SIP (Session Initiation Protocol) signaling packets, not in an analog signal like traditional phone lines. Understanding this is critical to troubleshooting.

Component Protocol What It Carries Default Port

Call signaling SIP Caller name, caller number, called number, call setup/teardown 5060 (UDP) or 5061 (TLS)

Voice audio RTP The actual voice conversation 10000–20000 range (dynamic)

Caller ID data is embedded in SIP headers, specifically:

SIP Header Contains Priority

P-Asserted-Identity Verified caller name and number (most reliable) Highest

Remote-Party-ID Legacy caller identity header Medium

From Caller display name and number Lowest (can be spoofed)

2.2 Encrypted vs. Unencrypted SIP

Feature Unencrypted SIP (Required for Vertex) Encrypted SIP (TLS/SRTP)

Signaling port 5060 (UDP or TCP) 5061 (TLS)

Audio protocol RTP (plain) SRTP (encrypted)

Vertex can read? Yes No

ATA workaround? Not needed Yes — ATA decrypts and outputs analog

EdgeMarc workaround? Not needed Yes — decrypts on LAN side

Critical: The Vertex is a passive network device that reads SIP packets as they flow through the network. If SIP signaling is encrypted with TLS, the Vertex cannot read the caller ID data. You must either: (1) request unencrypted SIP from the provider, (2) deploy an EdgeMarc SBC, or (3) use an ATA adapter with a Whozz Calling/POS unit.

2.3 SIP Signaling Standards (FSK vs. DTMF in VoIP Context)

In analog systems, caller ID is delivered using FSK (Frequency Shift Keying) or DTMF tones. In VoIP, caller ID is carried in SIP headers — the signaling standard is different. However, when using an ATA adapter, the ATA converts SIP caller ID back to analog FSK/DTMF, so the CallerID unit receives it just like a standard analog line.

3. ATA Adapter Setup with CallerID Devices

3.1 What Is an ATA?

An ATA (Analog Telephone Adapter) converts VoIP phone service into a traditional analog phone signal. It has an Ethernet port (connects to your network/internet) and one or more FXS phone ports (connects to analog devices like phones or CallerID units).

3.2 Recommended ATA Models

ATA Model FXS Ports Caller ID Support Notes

Cisco SPA112 2 Yes Reliable; widely available; caller ID enabled by default

Grandstream HT802 2 Yes Good value; may need caller ID enabled in admin panel

Grandstream HT812 2 Yes Gigabit Ethernet; newer model

Grandstream HT814 4 Yes 4-port model for more lines

Obihai OBi200/OBi202 1–2 Yes Works with Google Voice; good for small setups

Poly OBi302 2 Yes Successor to OBi202

3.3 ATA Wiring Diagram

INTERNET ATA ADAPTER CALLERID UNIT ============== ==================== ====================

+------------+ +------------------+ +------------------+ | VoIP | Ethernet | | Phone | Whozz Calling | | Provider | ---------> | ATA Adapter | ---------> | or POS Unit | | (Cloud) | | (e.g. HT802) | Cord | (Line Input) | +------------+ +--------+---------+ (RJ11) +--------+---------+ | | Ethernet Port Serial or Ethernet connects to connects to POS router/switch or computer

3.4 ATA Installation Steps

1Connect the ATA to your network

Plug an Ethernet cable from your router or network switch into the ATA’s WAN or LAN port. Plug in the ATA’s power adapter.

2Register the ATA with your VoIP provider

If your VoIP provider supplied the ATA, it may already be registered. Otherwise, log into the ATA’s admin panel (typically http://192.168.1.1 or the IP assigned by DHCP) and enter the SIP credentials provided by your VoIP provider: registrar/proxy address, SIP username, SIP password.

3Verify dial tone

Connect an analog phone to the ATA’s FXS (PHONE) port using a standard phone cord. Pick up the handset and listen for a dial tone. If you hear dial tone, the ATA is registered and working.

4Enable Caller ID on the ATA (if needed)

Some ATAs have caller ID delivery disabled by default. Log into the ATA admin panel and verify:

Caller ID Enable: Yes / On

Caller ID Method: FSK (preferred) or DTMF

Call Waiting Caller ID: Yes (if needed)

5Connect the CallerID unit

Use a phone line splitter on the ATA’s FXS port: one side goes to the analog phone (if desired), and the other goes to the CallerID unit’s line input. Alternatively, if no phone is needed on that line, connect the CallerID unit directly to the ATA FXS port.

6Test with an incoming call

Have someone call the VoIP number. The CallerID unit should display or transmit the caller’s name and phone number. If using serial output, verify data appears in your POS or terminal software.

Common ATA Issue: If the caller’s name appears but the number is missing (or vice versa), the ATA may not be forwarding all SIP caller ID fields. Check the ATA’s caller ID settings and ensure both name and number delivery are enabled. On Grandstream devices, look for “Caller ID Scheme” and set it to match your region (e.g., “Bellcore/Telcordia” for North America).

3.5 ATA Caller ID Settings by Model

ATA Model Admin URL Caller ID Setting Location Key Settings

Cisco SPA112 http:// Voice → Line 1 (or 2) → Caller ID Caller ID Enable: Yes; Display Name: From Header

Grandstream HT802/812 http:// FXS Port → Caller ID Caller ID Scheme: Bellcore/Telcordia; CIDCW: Enable

Grandstream HT814 http:// FXS Ports → each port → Caller ID Same as HT802; configure for each active port

Obihai/Poly OBi http:// or OBiTALK portal Voice Services → SP Service → Caller ID CallerID Enable: Enable; CallerID Method: FSK

4. SIP Trunk Caller ID Delivery Requirements

4.1 What the VoIP Provider Must Deliver

For the Vertex (or any SIP-based caller ID extraction), the VoIP provider’s SIP trunk must deliver caller ID in standard SIP headers. These are the requirements:

Requirement Details Priority

Unencrypted SIP signaling SIP over UDP or TCP on port 5060; no TLS on port 5061 Required for Vertex

Unencrypted RTP audio Standard RTP, not SRTP Required for Vertex call detection

Caller ID in SIP headers At least one of: P-Asserted-Identity, Remote-Party-ID, or From header with caller name and number Required

CNAM delivery Caller name (CNAM) included in SIP headers, not just the phone number Recommended

Full 10-digit number Complete caller phone number in E.164 or 10-digit format, not truncated Required

No SIP ALG SIP Application Layer Gateway must be disabled on all routers/firewalls Required

4.2 Sample SIP INVITE with Caller ID

Here is what a properly formatted SIP INVITE looks like. The Vertex reads the highlighted headers:

INVITE sip:7702637111@provider.com SIP/2.0 Via: SIP/2.0/UDP 10.0.0.50:5060 From: "John Smith" <4045551234>;tag=abc123 To: <7702637111> Call-ID: unique-call-id-12345@10.0.0.50 CSeq: 1 INVITE P-Asserted-Identity: "John Smith" <4045551234> Contact: <4045551234> Content-Type: application/sdp4045551234>4045551234>7702637111>4045551234>

4.3 Requesting Caller ID from Your VoIP Provider

If caller ID is not being delivered, contact your VoIP provider and request the following:

Enable caller ID / CNAM delivery on all inbound trunks

Include both caller name and number in the P-Asserted-Identity or From header

Use unencrypted SIP on port 5060 (if using a Vertex)

Disable any SIP ALG or SIP manipulation on their end that strips or modifies caller ID headers

Ensure CNAM lookup is enabled on their PSTN gateway — some providers do not perform CNAM lookups by default and only pass the raw phone number

5. Common VoIP Issues

5.1 No Caller ID Data at All

Possible Cause How to Diagnose Solution

SIP traffic is encrypted (TLS/SRTP) Check if VoIP phones connect on port 5061. Use Wireshark to capture traffic — if SIP INVITE is not visible in plain text, encryption is active Request unencrypted SIP from provider; deploy EdgeMarc SBC; or use ATA adapter

Vertex bridge ports not inline with VoIP traffic Check that all VoIP traffic passes through the Vertex “Toward Gateway” and “To Phones” ports. Verify all 3 amber LEDs are solid Re-cable so VoIP phones are downstream of the Vertex bridge

SIP ALG enabled on router/firewall Check router settings for SIP ALG, SIP Inspection, or SIP Transformation Disable SIP ALG on all routers and firewalls in the network path

VoIP provider not sending caller ID Use Wireshark to capture a SIP INVITE and check for From, P-Asserted-Identity, or Remote-Party-ID headers Contact VoIP provider and request caller ID / CNAM be enabled on the trunk

Vertex not configured (no SIP Gateway MAC) Use VCT (Vertex Configuration Tool) to check if SIP Gateway MAC is set Run VCT Setup Wizard or use phone-based setup to configure SIP Gateway MAC

Wrong data output format selected Check VCT settings — Data Format must match your POS software Select the correct POS format in VCT Setup Wizard

Management port not on same subnet as POS Ping the Vertex management IP from the POS computer Move Management port cable to the same network as the POS system

5.2 Garbled or Partial Caller ID Data

Symptom Possible Cause Solution

Number appears but name is missing VoIP provider not performing CNAM lookup; only passing ANI (number) Request CNAM lookup be enabled on inbound trunk; some providers charge extra for CNAM

Name appears but number is missing or truncated SIP headers malformed; provider stripping digits Check SIP INVITE in Wireshark; contact provider to fix number format

Caller ID shows “UNKNOWN” or “UNAVAILABLE” Caller has blocked their number; or the provider is not delivering caller ID for that trunk This is normal for blocked callers. If it happens for all calls, contact VoIP provider

Random characters or garbage text in caller name Character encoding mismatch; SIP header contains non-ASCII characters Check ATA or provider settings for character encoding; update Vertex firmware

Caller ID displays for some calls but not others Multiple SIP trunks with different configurations; some lines encrypted, some not Verify all trunks deliver caller ID; ensure all VoIP traffic routes through Vertex bridge

Wrong caller name displayed (name doesn’t match number) Provider’s CNAM database is outdated or incorrect This is a provider-side issue. Caller can request their provider update CNAM records

5.3 Missing Calls (Some Calls Not Detected)

Possible Cause How to Diagnose Solution

Not all VoIP traffic flows through Vertex bridge Some phones connect to a different switch or directly to the router, bypassing the Vertex Re-cable so all VoIP phones are downstream of the Vertex bridge

Multiple SIP gateways / registrars Check if the site has multiple VoIP providers or SIP trunks coming from different gateways Ensure the Vertex bridge is positioned to see all SIP traffic; may need multiple Vertex units

SIP Gateway MAC not set correctly VCT shows wrong MAC address for SIP Gateway Re-run VCT Setup Wizard; use “Discover SIP Gateway” feature during a live call

Calls routed through different network path (VLAN) VoIP traffic is on a separate VLAN that bypasses the Vertex bridge ports Reconfigure network so VoIP VLAN traffic passes through the Vertex, or use port mirroring

ATA not receiving all lines (ATA setup) ATA only has 2 FXS ports but site has 4+ lines Add additional ATA adapters; or switch to a Vertex with EdgeMarc SBC for all lines

5.4 Intermittent Caller ID

Possible Cause How to Diagnose Solution

Network congestion / packet loss Run a packet capture during missed calls; look for dropped SIP INVITEs Implement QoS rules to prioritize SIP traffic; check for bandwidth saturation

Energy Efficient Ethernet (EEE / IEEE 802.3az) Managed switches have EEE enabled by default; causes initial packets to be lost when link wakes from low-power state Disable EEE on all switch ports connected to VoIP devices and the Vertex

Switch auto-negotiation issues Vertex bridge operates at 100 Mbps; Gigabit switches may have negotiation problems Manually set switch ports connected to Vertex to 100 Mbps Full Duplex

Firewall intermittently blocking SIP Check firewall logs for blocked UDP 5060 traffic Create explicit allow rules for SIP traffic on all firewalls

ATA losing registration Check ATA status page — registration may drop periodically Set shorter registration expiry (e.g., 60 seconds); check ATA firmware updates

Energy Efficient Ethernet (EEE): This is one of the most common causes of intermittent caller ID with VoIP. Many managed switches (especially Cisco) enable EEE by default. It puts ports into a low-power state during idle periods, and the first few packets after waking up can be lost — which often includes the SIP INVITE containing caller ID. Always disable EEE on ports connected to VoIP equipment and the Vertex.

6. Network Requirements

6.1 Required Ports and Protocols

Port Protocol Direction Purpose

5060 UDP/TCP Inbound & Outbound SIP signaling (call setup, caller ID)

5061 TLS Inbound & Outbound Encrypted SIP signaling (not compatible with Vertex)

10000–20000 UDP Inbound & Outbound RTP voice audio (range varies by provider)

3520 (default) UDP Outbound from Vertex Vertex management port — sends caller ID data to POS

80 / 443 TCP Various ATA admin panel access; VoIP provider provisioning

6.2 NAT and Firewall Configuration

Firewall Rules for VoIP + CallerID

Allow SIP traffic (port 5060 UDP/TCP) in both directions between the VoIP provider and your LAN

Allow RTP traffic (ports 10000–20000 UDP) in both directions for voice audio

Disable SIP ALG on all routers and firewalls — SIP ALG modifies SIP packets in transit and frequently breaks caller ID delivery

Disable SIP Inspection / SIP Transformation — similar to ALG, these features modify SIP headers

Allow Vertex management traffic on the configured port (default UDP 3520) between the Vertex and the POS system

6.3 QoS (Quality of Service) Recommendations

Traffic Type DSCP Value Priority Notes

SIP Signaling CS3 (24) or EF (46) High Ensures SIP INVITEs (with caller ID) are not dropped

RTP Voice Audio EF (46) Highest Prevents choppy audio and dropped calls

Vertex Management CS1 (8) or default Normal Not latency-sensitive; standard priority is fine

Bandwidth: Each VoIP call typically uses 80–100 Kbps (using G.711 codec). A 4-line system needs at least 400 Kbps of dedicated bandwidth. If the internet connection is saturated, SIP packets may be dropped, causing missed caller ID. Ensure adequate bandwidth or implement QoS to prioritize VoIP traffic.

6.4 SIP ALG — Why It Must Be Disabled

SIP ALG (Application Layer Gateway) is a feature on many consumer and business routers that attempts to “help” SIP traffic traverse NAT. In practice, it frequently breaks VoIP by modifying SIP headers, which can:

Strip or corrupt caller ID information

Cause one-way audio

Prevent SIP registration

Cause dropped calls

Disable SIP ALG on every router and firewall in the network path. Common locations for this setting:

Router Brand Where to Find SIP ALG

Cisco / Meraki Security → Firewall → Layer 7 Rules; or CLI: no ip nat service sip

Netgear Advanced → WAN Setup → Disable SIP ALG

TP-Link Advanced → NAT → ALG → uncheck SIP

Ubiquiti / UniFi Settings → Routing & Firewall → Firewall → Disable SIP ALG

SonicWall VoIP → Settings → Enable Consistent NAT: Yes; Enable SIP Transformations: No

Fortinet / FortiGate System → Settings → Disable SIP ALG; or CLI: config system settings then set sip-helper disable

pfSense System → Advanced → Firewall & NAT → disable pf SIP proxy

6.5 VLAN Considerations

Many enterprise networks place VoIP phones on a separate VLAN from data traffic. This creates a potential problem for the Vertex:

VLAN Issue: If VoIP phones are on VLAN 100 and the POS system is on VLAN 1, the Vertex bridge ports must be on the VoIP VLAN (to see SIP traffic), while the management port must be on the data VLAN (to communicate with the POS). Ensure the Vertex management port is connected to the same subnet/VLAN as the POS system.

Vertex bridge ports (“Toward Gateway” and “To Phones”) must be inline with VoIP traffic — they must see all SIP packets

Vertex management port must be on the same subnet as the POS system that receives caller ID data

If the VoIP VLAN and data VLAN are isolated, the management port connects to a port on the data VLAN

7. Vertex VoIP-Specific Configuration

7.1 Physical Installation

The Vertex has three key Ethernet ports:

Port Purpose Connects To

Toward Gateway VoIP bridge input (upstream side) ISP modem/router or main network switch

To Phones VoIP bridge output (downstream side) Phone switch or VoIP phones

Management Port Data output to POS/software Network switch where POS system resides

Bridge Speed: The Vertex bridge operates at 100 Mbps. This is more than sufficient for VoIP traffic but will limit the throughput between the two bridged devices. If Gigabit speeds are needed for data, ensure the Vertex bridge is only inline with VoIP traffic, not general data traffic.

7.2 LED Status Indicators

LED Normal State Problem State

Power LED (amber) Solid ON — unit is powered OFF — no power; check adapter and outlet

VoIP Bridge 1 (amber) Solid ON — connected to gateway side OFF — no link on “Toward Gateway” port; check cable

VoIP Bridge 2 (amber) Solid ON — connected to phone side OFF — no link on “To Phones” port; check cable

All 3 amber LEDs must be solid ON before proceeding with configuration. If any LED is off, check and reseat the corresponding Ethernet cable. The Vertex will not capture caller ID unless the bridge is fully connected.

7.3 Configuration Methods

Option A: Phone-Based Setup (No PC Required)

Set DIP switch #2 DOWN, all others UP

Power cycle the Vertex

POS should display: 777-000-0000 “Setup Mode On”

From a monitored VoIP phone, dial: 777-123-4567

Visit CallerID.com/vertex_website.php?tab=phone-setup to generate your setup number based on POS type and time zone

Dial the generated setup number from the phone

Set all DIP switches DOWN

Power cycle the Vertex

Test with an incoming call

Option B: VCT Setup (Windows PC)

Download VCT from CallerID.com/vct

Set all DIP switches DOWN

Ensure your PC is on the same subnet as the Vertex management port

Launch VCT — it should auto-detect the Vertex

Run the Setup Wizard when prompted

Configure key parameters: Data Gateway MAC — for time/date sync

SIP Gateway MAC — the MAC address of the VoIP gateway/router that sends SIP traffic (use “Discover SIP Gateway” during a live call)

Time Zone

Data Output Format — select your POS software

Save settings

Test with an incoming call

7.4 SIP Gateway MAC Discovery

The SIP Gateway MAC tells the Vertex which device is the VoIP gateway so it can determine call direction (inbound vs. outbound). If this is set incorrectly, caller ID may not appear or may show the wrong data.

To discover the SIP Gateway MAC using VCT:

Open VCT and connect to the Vertex

Click the “Discover SIP Gateway” button

Have someone make a test call (inbound or outbound) to/from a monitored phone

VCT will capture the SIP traffic and display the detected SIP gateway MAC address

Click Apply to save the discovered MAC

Tip: If the discovered SIP Gateway MAC matches the Data Gateway MAC, set the SIP Gateway MAC to 00:00:00:00:00:00 (all zeros). The Vertex will automatically use the Data Gateway MAC in this case.

7.5 DIP Switch Reference

DIP Switch Position Function

#1 DOWN (normal) Factory reset when UP during power-on

#2 DOWN (normal) / UP (setup) UP = phone-based setup mode

#3 DOWN (normal) Reserved

#4 DOWN (normal) Reserved

8. EdgeMarc SBC Integration

8.1 When to Use an EdgeMarc SBC

An Edgewater EdgeMarc Session Border Controller (SBC) is required when:

The VoIP provider uses encrypted SIP (TLS on port 5061) and will not provide an unencrypted option

The site has 5+ VoIP lines, making an ATA solution impractical

The customer requires enterprise-grade VoIP security on the WAN side while still enabling caller ID on the LAN

8.2 How the EdgeMarc Solves the Encryption Problem

INTERNET (WAN Side) LOCAL NETWORK (LAN Side) ================== =========================

+------------------+ +-------------------+ | VoIP Provider | | IP Phones / | | (SIP Trunk) | | PBX System | +--------+---------+ +--------+----------+ | | | TLS/SRTP (Encrypted) | UDP 5060 (Unencrypted) | Port 5061 | Standard SIP | | +--------+--------------------------------------------+----------+ | | | EDGEWATER EDGEMARC SBC | | | | WAN Interface LAN Interface | | (Encrypted TLS) ---------> (Decrypted UDP/TCP) | +-----------------------------------------------------------------+ | | LAN (Same Subnet) | +--------+----------+ | CallerID.com | | Vertex Unit | | (Bridge Inline) | +--------------------+

The EdgeMarc acts as a B2BUA (Back-to-Back User Agent). It terminates the encrypted TLS session from the VoIP provider on the WAN side and creates a new, unencrypted SIP session on the LAN side. The Vertex sits inline on the LAN and reads the unencrypted SIP traffic.

8.3 EdgeMarc Configuration Summary

For detailed step-by-step instructions, refer to the EdgeMarc SBC Installation Guide. Key configuration points:

Setting WAN Side LAN Side

Signaling Protocol TLS (encrypted) UDP (unencrypted)

SIP Port 5061 5060

Audio Protocol SRTP (if required by provider) RTP (unencrypted)

TLS Enabled Yes No

SRTP Enabled Per provider requirement No

Transparent Proxy N/A Enabled

8.4 Supported EdgeMarc Models

Model Max SIP Sessions Recommended For

EdgeMarc 2900 15 Small offices (1–8 phones)

EdgeMarc 4550 30 Medium offices (8–20 phones)

EdgeMarc 4600 50 Larger offices

EdgeMarc 4700 100 Enterprise / multi-location

EdgeMarc 7301 200+ Large enterprise deployments

9. VoIP Provider-Specific Notes

9.1 Provider Compatibility Matrix

VoIP Provider Encryption Default Vertex Compatible? ATA Compatible? Notes

RingCentral Encrypted (TLS/SRTP) No (without SBC) Yes Does not offer unencrypted SIP; use ATA or EdgeMarc

Vonage Business Encrypted by default Maybe Yes May be able to request unencrypted SIP trunk; contact Vonage support

8x8 Encrypted (TLS/SRTP) No (without SBC) Yes Does not offer unencrypted option; use ATA or EdgeMarc

Comcast Business VoiceEdge Mixed — varies by market Maybe Yes Some markets use EdgeMarc; contact Comcast Business support to request unencrypted SIP on LAN

Spectrum Business Voice Typically unencrypted on LAN Yes (usually) Yes Often deploys an EdgeMarc or Adtran SBC that decrypts on LAN side

Ooma Office Unencrypted on LAN Yes Yes Uses Ooma base station as ATA; standard SIP on LAN

Nextiva Encrypted by default No (without SBC) Yes Does not offer unencrypted SIP; use ATA or EdgeMarc

Clarity Voice Unencrypted SIP available Yes Yes Familiar with CallerID.com devices; request unencrypted SIP trunk

Pizza Cloud Unencrypted SIP available Yes Yes Common with pizza POS systems; works well with Vertex

Windstream Typically unencrypted Yes Yes Standard SIP trunk delivery; verify with local account team

Mitel / ShoreTel Varies by deployment Maybe Yes On-prem PBX may use unencrypted SIP internally; check with admin

Asterisk / FreePBX / 3CX Configurable Yes (if configured for unencrypted) Yes Admin can configure unencrypted SIP on LAN side; enable CNAM pass-through

Broadvoice Typically unencrypted Yes Yes Standard SIP; request CNAM delivery if not included

Lingo / Birch Typically unencrypted Yes Yes Standard SIP trunk

Google Voice / Google Fi Encrypted No Yes (via OBi ATA) Use an Obihai/Poly ATA configured for Google Voice

9.2 How to Ask Your VoIP Provider for Unencrypted SIP

Use the following template when contacting your VoIP provider:

Subject: Request for Unencrypted SIP Signaling on LAN Side

Hello,

We are installing a CallerID.com Vertex Caller ID unit at our location. This device reads caller ID information from SIP packets on our local network. It requires unencrypted SIP signaling (UDP port 5060) on our LAN side to function.

Could you please confirm whether our SIP trunks use encrypted signaling (TLS on port 5061)? If so, can you provide one of the following options:

Switch our SIP trunk to unencrypted SIP (port 5060) on the LAN side

Provide unencrypted SIP on a secondary trunk/registration for our caller ID device

Deploy an EdgeMarc SBC or similar device that decrypts SIP on the LAN side

Our account number is: [YOUR ACCOUNT NUMBER]

Thank you for your assistance.

10. Diagnostic Flowchart

10.1 No Caller ID — VoIP System

Are all 3 Vertex amber LEDs solid ON? No → Check and reseat Ethernet cables on bridge ports; verify power

Yes → Continue

Do VoIP phones have dial tone and can make/receive calls? No → VoIP service issue, not CallerID issue; contact VoIP provider

Yes → Continue

Is SIP traffic encrypted (TLS/SRTP)? Yes → Deploy EdgeMarc SBC, or switch to ATA + Whozz Calling/POS setup

No / Unknown → Continue

Is SIP ALG disabled on all routers and firewalls? No or Unknown → Disable SIP ALG on all network devices

Yes → Continue

Is the Vertex configured with correct SIP Gateway MAC? No / Unknown → Use VCT “Discover SIP Gateway” during a live call

Yes → Continue

Is the correct data output format selected in VCT? No → Select the correct POS format

Yes → Continue

Is the Vertex management port on the same subnet as the POS? No → Move management port to the POS subnet

Yes → Continue

Does the VoIP provider deliver caller ID in SIP headers? No or Unknown → Contact provider; request CNAM/caller ID delivery

Yes → Contact CallerID.com support at 770.263.7111

10.2 No Caller ID — ATA Setup

Does the ATA have dial tone on its FXS port? No → ATA not registered with VoIP provider; check SIP credentials and network

Yes → Continue

Is caller ID enabled on the ATA? No / Unknown → Log into ATA admin panel; enable Caller ID; set scheme to Bellcore/Telcordia

Yes → Continue

Is the CallerID unit connected to the ATA FXS port (via splitter or direct)? No → Connect CallerID unit to ATA FXS port with phone cord

Yes → Continue

Is the CallerID unit powered and its LEDs normal? No → Check power and connections

Yes → Continue

Does the VoIP provider deliver caller ID to the ATA? No or Unknown → Test with a phone connected to the ATA; if incoming call shows caller ID on the phone display, it is working

Yes → Contact CallerID.com support at 770.263.7111

11. Advanced Diagnostics

11.1 Using Wireshark to Capture SIP Traffic

Wireshark is a free network protocol analyzer that can capture and display SIP packets. This is the most reliable way to determine if SIP traffic is encrypted and if caller ID is being delivered.

Install Wireshark on a PC connected to the same network as the VoIP phones

Start a capture on the network interface connected to the VoIP subnet

Apply the display filter: sip

Have someone make an inbound call to a monitored line

Look for a SIP INVITE packet in the capture

If you see readable SIP INVITE text — SIP is unencrypted and the Vertex should work

If you see TLS handshake packets and no readable SIP — SIP is encrypted

In the SIP INVITE, check for From, P-Asserted-Identity, or Remote-Party-ID headers containing the caller’s name and number

11.2 Testing Vertex Data Output

Serial output test (if using serial connection):

Connect the Vertex serial port to a PC COM port (or USB-to-Serial adapter)

Open a terminal program (PuTTY, HyperTerminal, or Tera Term)

Set serial parameters: 115200 baud, 8 data bits, no parity, 1 stop bit (115200-8-N-1)

Make a test inbound call

Caller ID data should appear in the terminal window

Ethernet output test (if using Ethernet/management port):

Install the Whozz Calling desktop application or use VCT

Ensure the PC is on the same subnet as the Vertex management port

Open the application and verify it detects the Vertex

Make a test inbound call

Caller ID data should appear in the application window

11.3 Vertex Firmware Updates

Outdated firmware can cause compatibility issues with certain VoIP providers or SIP implementations. Always ensure the Vertex is running the latest firmware.

Open VCT and connect to the Vertex

Check the current firmware version displayed on the main screen

Contact CallerID.com support (770.263.7111) for the latest firmware version

If an update is needed, use VCT’s firmware update feature

12. Frequently Asked Questions

Q: How do I know if my VoIP uses encrypted or unencrypted SIP?

A: The quickest method is to ask your VoIP provider. You can also use Wireshark to capture network traffic and look for SIP packets. If you see readable SIP INVITE messages, it is unencrypted. If you see TLS handshakes on port 5061, it is encrypted. The Vertex Web Configuration Tool also includes automatic TLS/encryption detection.

Q: Can the Vertex work with encrypted VoIP?

A: Not directly. The Vertex reads SIP packets passively and cannot decrypt TLS-encrypted traffic. To use the Vertex with encrypted VoIP, you need an EdgeMarc SBC or similar device to decrypt SIP on the LAN side while keeping the WAN side encrypted.

Q: What is the difference between a Vertex and a Whozz Calling unit?

A: The Vertex reads caller ID from VoIP (SIP) traffic on the network. Whozz Calling and POS units read caller ID from analog phone lines (POTS, copper). If you have VoIP, use a Vertex. If you have analog lines, use a Whozz Calling or POS unit. If you have VoIP with encrypted SIP, you can use a Whozz Calling/POS unit with an ATA adapter as a workaround.

Q: Do I need one ATA per phone line?

A: Each ATA FXS port supports one phone line. Most ATAs have 2 FXS ports, so one ATA covers 2 lines. For 4 lines, use a 4-port ATA (like the Grandstream HT814) or two 2-port ATAs. Each ATA FXS port connects to one line input on the CallerID unit.

Q: The Vertex shows caller ID for some calls but not others. Why?

A: Most common causes: (1) Some phones bypass the Vertex bridge (not all VoIP traffic flows through it); (2) Multiple SIP trunks with different configurations; (3) Energy Efficient Ethernet (EEE) enabled on managed switches; (4) The caller has blocked their caller ID. Check all these possibilities in order.

Q: Will the Vertex slow down my network?

A: The Vertex bridge operates at 100 Mbps. For VoIP traffic only, this is more than sufficient (each call uses approximately 100 Kbps). If you need Gigabit speeds for data, ensure the Vertex bridge is only inline with VoIP traffic, not your general data network.

Q: What if my VoIP provider will not offer unencrypted SIP?

A: You have two options: (1) Deploy an EdgeMarc SBC which decrypts SIP on the LAN side while maintaining encryption on the WAN side. (2) Use an ATA adapter with a Whozz Calling or POS unit, which bypasses the encryption entirely by converting VoIP to analog.

Q: Can I use the Vertex with a cloud PBX like RingCentral or 8x8?

A: These providers typically enforce TLS encryption and do not offer an unencrypted SIP option. For these providers, use an ATA adapter with a Whozz Calling or POS unit, or deploy an EdgeMarc SBC if the provider supports it.

Q: What is SIP ALG and why does it cause problems?

A: SIP ALG (Application Layer Gateway) is a feature on many routers that modifies SIP packets as they pass through NAT. While intended to help, it frequently corrupts SIP headers, strips caller ID data, causes one-way audio, and drops calls. It should always be disabled on all routers and firewalls in a VoIP network.

Q: How do I check if Energy Efficient Ethernet (EEE) is causing issues?

A: If caller ID works intermittently — some calls show it, others do not — EEE is a likely culprit. Log into your managed switch and disable EEE (IEEE 802.3az) on all ports connected to VoIP devices and the Vertex. On Cisco switches, use the command: no power efficient-ethernet auto on each interface.

Q: Can the Vertex detect outbound calls too?

A: Yes, if the SIP Gateway MAC is configured correctly. The Vertex uses the SIP Gateway MAC to determine call direction. Calls originating from the gateway side are marked as inbound; calls originating from the phone side are marked as outbound.

Q: What POS systems work with the Vertex?

A: The Vertex supports many POS systems including Toast, Speedline, Domino’s Pulse, Hunger Rush, Linga, SpotOn, Revel, Total Touch, Future POS, R.O. Writer, and many others. The VCT Setup Wizard has a dropdown with all supported POS data formats. Contact CallerID.com support if your POS is not listed.

CallerID.com | 770.263.7111 | Info@CallerID.com

VoIP Troubleshooting Guide | Version 1.0 | 2026

© 2025 CallerID.com. All Rights Reserved.