AMDY.IO
Start free
← All articles
Product UpdatesAug 22, 2026 8 min read

How to Connect Any SIP Dialer to AMDY.IO via WebSocket API in 2026

If your dialer isn't ViciDial, Asterisk, GoAutoDial, FreePBX, or Issabel, you still have a problem. Legacy silence-based AMD misidentifies 1 in 5 live humans as voicemail. That 15 to 20 percent false positive rate burns leads and costs a 10-agent team an estimated $24,000 per month.

The one-line install covers the most common open-source stacks. For everything else, AMDY.IO exposes a WebSocket API that connects any SIP-based dialer directly to its ML audio fingerprint engine. This article walks through how that connection works, what you need on your end, and what to expect once it's live.

Why the WebSocket API Exists

AMDY.IO's native integrations handle ViciDial, Asterisk, GoAutoDial, FreePBX, and Issabel with a single command. But outbound call centers run a wide range of SIP infrastructure. Custom-built dialers, hosted PBX platforms, third-party predictive dialers — they all need accurate AMD without a full platform migration.

That's what the WebSocket API is for. It streams real-time audio from your dialer to AMDY.IO's ML engine, which analyzes the audio fingerprint and returns a detection result in milliseconds. Your dialer acts on that result: route to agent, drop to voicemail, or skip entirely.

No platform swap. No agent retraining. No new dialer license.

What You Need Before You Start

Confirm these prerequisites on your end before opening a WebSocket connection:

  • SIP-based dialer with audio streaming capability. Your dialer must be able to stream raw audio — typically RTP or PCM — over a WebSocket connection. If your platform supports AGI, ESL, or a REST hook for call events, you likely already have what you need.
  • Network access to AMDY.IO's endpoint. Your dialer server needs outbound access to the AMDY.IO WebSocket endpoint. Check firewall rules and any NAT traversal requirements for your environment.
  • API credentials. You'll receive an API key and endpoint URL when you start your trial. Keep these out of your codebase. Use environment variables or a secrets manager.
  • Audio format compatibility. AMDY.IO's engine expects a specific audio format — typically 8kHz, 16-bit PCM mono, which is standard for telephony. Check the integration docs for the exact spec.

The Connection Flow

Here's how a call moves through the WebSocket integration from dial to detection.

1. Call Initiation

Your dialer places an outbound call through your SIP trunk as normal. Nothing changes at the SIP signaling layer. AMDY.IO doesn't sit in the SIP path.

2. Audio Stream Opens

As soon as the remote party answers — based on your dialer's call progress detection — your dialer opens a WebSocket connection to the AMDY.IO endpoint and begins streaming audio. Your API key goes in the handshake header.

A minimal handshake looks like this:

GET wss://api.amdy.io/amd/stream HTTP/1.1
Host: api.amdy.io
Upgrade: websocket
Connection: Upgrade
Authorization: Bearer YOUR_API_KEY
X-Call-ID: your-unique-call-identifier

The X-Call-ID field ties the detection result back to the specific call leg in your system. Use your dialer's internal call UUID or session ID here.

3. Audio Frames Stream In

Your dialer sends binary audio frames over the open WebSocket. Frame size is flexible, but smaller frames — 20ms chunks are common in telephony — give the engine more granular data and reduce detection latency.

Keep the stream continuous from answer detection through the first 3 to 4 seconds of audio. That's the window where the ML model distinguishes a live human greeting from a voicemail system's recorded message or silence pattern.

4. Detection Result Returns

AMDY.IO returns a JSON result over the same WebSocket connection:

{
  "call_id": "your-unique-call-identifier",
  "result": "human",
  "confidence": 0.98,
  "latency_ms": 420
}

The result field returns human, machine, or unknown. The confidence score reflects the model's certainty. The latency_ms field shows how long detection took from the first audio frame.

At 99% accuracy, a human result is reliable enough to route directly to an agent without a buffer delay.

5. Your Dialer Acts on the Result

This is where your integration logic lives. On human, connect the call to an available agent. On machine, execute your voicemail drop logic or disconnect. On unknown, define a fallback — typically a short hold or a default route.

The WebSocket closes after the result returns. You don't need to manage a persistent connection per call beyond the detection window.

Handling Edge Cases

False Start Audio (FAS)

FAS happens when a brief audio burst triggers an answer event before the actual greeting begins. Your dialer may stream a fraction of a second of noise before the real audio starts. AMDY.IO's engine handles this by analyzing the full audio fingerprint pattern rather than reacting to the first frame. Don't truncate the stream early — let it run through the greeting.

Network Latency

WebSocket connections add round-trip latency. For most hosted environments, that's under 100ms. If your dialer server is geographically distant from AMDY.IO's infrastructure, test latency before going live. Detection results arriving after 600ms may conflict with your dialer's own timeout logic. Check your AMD timeout setting and align it with observed AMDY.IO latency.

Concurrent Call Volume

Each outbound call opens its own WebSocket connection for the detection window. At high concurrency — 50 or more simultaneous calls — confirm your server handles that many open connections without hitting file descriptor limits. On Linux, check ulimit -n and increase it if needed for your call volume.

Unknown Results

An unknown result means the engine didn't receive enough clean audio to make a determination. This typically happens when a call drops before 1.5 seconds of audio streams through, or when audio quality is severely degraded. Define a fallback route for these cases. Routing unknown to an agent is the conservative choice and protects against false negatives.

Testing the Integration

Before going live, run the integration against a test call set. AMDY.IO's trial environment supports this.

What to verify:

  • Detection accuracy on your specific call types. Run 50 to 100 test calls split between live answers and voicemail. Compare AMDY.IO's results against what actually happened on each call.
  • Latency under load. Simulate your peak concurrent call volume. Confirm detection results return within your dialer's AMD timeout window.
  • Failover behavior. Deliberately drop the WebSocket mid-stream. Confirm your dialer handles a missing result gracefully without hanging the call.
  • Call ID matching. Confirm every result maps back to the correct call leg in your system. Mismatched call IDs at scale will cause routing errors.

What Changes After Integration

Once the WebSocket integration is live, your agents stop receiving dead air calls. Every call that reaches them is a confirmed live human. Ghost calls drop to near zero, which protects your caller ID reputation and reduces spam flag risk.

Your AMD false positive rate falls from the 15 to 20 percent range typical of legacy silence-based detection to under 1 percent. For a 10-agent team, that's an estimated $24,000 per month in recovered live connections.

The integration doesn't touch your SIP trunk, your agent interface, or your campaign configuration. Your team works exactly the same way. The only thing that changes is the quality of the calls reaching them.

Ready to Connect Your Dialer?

The 14-day free trial at amdy.io includes full WebSocket API access with no setup fees. You get your API key, the endpoint URL, and integration docs on signup. Same-day deployment is realistic for any team with SIP audio streaming already in place.

Start your 14-Day Free AMD Trial or use the built-in ROI calculator to put a dollar figure on what your current false positive rate is costing you.

FAQs

Does the WebSocket API work with any SIP-based dialer, or only specific platforms?
Any SIP-based dialer that can stream audio over a WebSocket connection is compatible. There are no platform restrictions beyond SIP and audio streaming capability. If your dialer supports AGI, ESL, or a programmable call event hook, integration is straightforward.

What audio format does AMDY.IO's WebSocket API require?
The engine expects 8kHz, 16-bit PCM mono audio — the standard telephony format. Confirm the exact spec in the integration docs provided at trial signup, as format requirements may be updated.

How fast does AMDY.IO return a detection result?
Detection latency is typically under 500ms from the first audio frame. The result JSON includes a latency_ms field so you can measure actual performance in your environment.

What happens if the WebSocket connection drops mid-call?
If the connection drops before a result returns, your dialer receives no detection signal. Define a fallback route in your integration logic for this case. Routing to an agent is the safest default to avoid hanging live calls.

Can I run the WebSocket API alongside a native ViciDial or Asterisk integration?
Yes. If part of your infrastructure runs ViciDial or Asterisk, use the one-line native install for those systems and the WebSocket API for any additional dialers in your stack. Both paths connect to the same ML engine.

Does the WebSocket API support voicemail drop?
Yes. When the engine returns machine, your dialer can trigger its voicemail drop logic. AMDY.IO gives you a reliable signal to act on — not a guess based on silence thresholds.

Is the 14-day free trial limited in call volume or features?
The trial includes full WebSocket API access with no setup fees. Volume limits and any trial-specific restrictions are detailed in the trial documentation at amdy.io.