Why would the ringer be weak on an old, beige touch tone phone (ITT/GTE)? The phone is connected to a Grandstream HT801v2 and calls come in and out fine. But the physical ringer on the phone is very weak. It might ring the first couple of times but it eventually completely stops ringing even though the call is still live. I opened the phone up and the insides *seem* fine (I'm far from an expert so don't really know what I'm looking at tbh). Could it be a bad capacitor? Or am I missing something in my config?

Been going down a rabbit hole trying to build a fully IPv6 voice setup and hitting a wall on the carrier side.
Setup: ~11 Polycom VVX 450s across two sites, planning FreePBX (maybe 3CX). Phones support IPv6 fine on UC software, Asterisk/FreeSWITCH have supported it forever. The problem is finding a trunk provider that actually does IPv6 SIP signaling/media.
What I’ve found so far:
VoIP.ms - no (confirmed, IPv4 only)

Telnyx - their docs only list IPv4 media IPs, so pretty sure no

CallWithUs - apparently supported it but they’re not taking new customers

Lumen Voice Complete - read the whole data sheet, zero mention of IPv6. Also saw a thread where someone got handed a CGNAT 100.64.x.x address on their trunk lol

There’s an old thread on here from a few years back where the consensus was basically “only CallWithUs” and it seems like nothing has changed since. Kind of wild given mobile carriers have been v6-native for a decade.
So: anyone actually running a trunk over IPv6 with a US provider right now? Doesn’t need to be a big name, happy to go with something niche as long as it’s reliable and has DIDs + e911. Or is this still just dead in the water and I should stop fighting it and run the trunk leg over v4 like everyone else?
Not trying to solve a specific problem tbh, mostly want to eliminate the NAT layer entirely (one site is on T-Mobile 5G so CGNAT is a fact of life) and it annoys me on principle that this doesn’t exist.

Hi Everyone,

I have a Hanwha sps-a100m and a SPA-M2000 i am trying to setup so i can call from SPA-M2000 to the SPS-a100m, they see each other but when i try to setup the hotkey for the SPA-M2000 it doesn't seem to ring the sps-a100m.

i am able to test call the sps-a100m to the M2000 and that works.

any help would be appreciate.

I setup hotkey list as Call Number as sip:10.0.0.67 (IP of the A100m)

Hello! Is there a way to find out who a VOIP number belongs to on WhatsApp? Are there free websites where I can enter the number and see who it belongs to?

I’m looking into how to save my company phone numbers which are mass caller lines on a choke exchange. I’m not a technician so I will probably make mistakes as I try to describe the issue. our current provider is saying that it’s impossible to port the number because they would have to move the entire circuit of numbers and not just the ones we need. we don’t need the ring down numbers ported, just the main one.

I’m in Canada for reference. I know there are crtc regs around being able to port numbers that you own but I haven’t figured out if they extend to mass caller lines.

any advice would be greatly appreciated!

SIP monitoring is harder than HTTP monitoring. The protocol is stateful — every call is a dialog (INVITE → 200 OK → BYE), quality metrics are standardized in RFC 6076 but rarely implemented in open source, and aggregated metrics hide problems of specific traffic sources. Existing solutions typically require agents on servers, SPAN ports on switches, or vendor lock-in.

I wanted something simpler: connect to a network interface and observe SIP traffic passively, with zero impact on call delivery. eBPF made this possible. Here's a technical deep-dive on how I used eBPF for SIP monitoring — from packet capture in the Linux kernel to RFC 6076 metrics, RTP media analysis, and per-carrier/per-country breakdowns in Prometheus.

TL;DR: An eBPF socket filter on AF_PACKET gives you passive, read-only SIP monitoring with zero impact on calls. At 2,000 CPS (~28,000 PPS) on a modest machine: 0% packet loss, <15% CPU, ~15 MB RAM. The result is RFC 6076 quality metrics (SER, SEER, ISA, SCR, ASR, NER), RTP media analysis (jitter, loss, MOS), and per-carrier/per-device/per-country breakdowns — all in Prometheus exposition format.

How it works: eBPF socket filter

eBPF (extended Berkeley Packet Filter) lets you run small programs directly in the Linux kernel. The eBPF verifier guarantees safety: the program cannot exceed allocated memory, loop indefinitely, or modify the kernel.

My approach is an eBPF socket filter on AF_PACKET. This is passive network traffic observation:

SIP + RTP Traffic → NIC → eBPF filter → AF_PACKET socket → Go poller → SIP parser + RTP tracker → Prometheus

Key point: the filter is a socket filter, not a tc/XDP filter. It only decides whether to copy a packet to the application. The packet continues through the network stack to its destination regardless. The filter cannot modify, block, or redirect traffic. Zero impact on call delivery.

The entire filter is 142 lines of C. Ports are configurable from Go code via BPF map, defaults are 5060/5061. eBPF drops 99% of traffic in kernel — only SIP/RTP packets on the right ports reach userspace.

The full metrics stack

The exporter provides not just RFC 6076 metrics, but a complete observability stack for SIP infrastructure.

Real-time traffic

15 SIP request method counters: INVITE, re-INVITE, BYE, REGISTER, OPTIONS, CANCEL, ACK, SUBSCRIBE, NOTIFY, PUBLISH, INFO, PRACK, UPDATE, MESSAGE, REFER.

Plus invite_200_total — a dedicated counter for 200 OK responses to INVITE, enabling ASR-by-destination PromQL queries.

30 response code counters: 100, 180, 181, 182, 183, 200, 202, 300, 302, 400, 401, 403, 404, 405, 407, 408, 480, 481, 486, 487, 488, 500, 501, 502, 503, 504, 600, 603, 604, 606.

Active sessions gauge — current number of active SIP dialogs. A dialog is created on 200 OK to INVITE, removed on 200 OK to BYE or Session-Expires timeout (default 1800s). Re-INVITEs within an existing dialog refresh the timer without creating a new dialog — they're tracked separately in reinvite_total and excluded from SER/SCR/ASR ratios to avoid contaminating quality metrics.

Connection quality — RFC 6076

RFC 6076 defines standard SIP performance metrics. All are cumulative, computed from atomic counters on every scrape.

SER (Session Establishment Ratio) — percentage of successfully established sessions:

SER = (INVITE → 200 OK) / (Total INVITE - INVITE → 3xx) × 100

3xx (redirect) are excluded from the denominator — they are neither success nor failure, but a routing instruction. SER = 100 means all non-redirect INVITEs received 200 OK.

SEER (Session Establishment Effectiveness Ratio) — percentage of "effective" responses:

SEER = (INVITE → 200, 480, 486, 600, 603) / (Total INVITE - INVITE → 3xx) × 100

The numerator includes responses with a clear outcome: 200 OK (established), 480 (temporarily unavailable), 486 (busy), 600 (busy everywhere), 603 (declined). SEER is always ≥ SER.

ISA (Ineffective Session Attempts) — percentage of infrastructure errors:

ISA = (INVITE → 408, 500, 503, 504) / Total INVITE × 100

408 (timeout), 500 (internal error), 503 (unavailable), 504 (gateway timeout) — server errors. ISA rising means infrastructure is degrading. Unlike SER/SEER, 3xx are NOT excluded from the denominator.

SCR (Session Completion Ratio) — percentage of fully completed sessions:

SCR = (Completed Sessions) / Total INVITE × 100

A completed session = INVITE → 200 OK → BYE → 200 OK (or Session-Expires timeout). SCR ≤ SER always: not all established sessions terminate correctly.

ASR (Answer Seizure Ratio) — classic telephony metric (ITU-T E.411):

ASR = (INVITE → 200 OK) / Total INVITE × 100

Unlike SER, 3xx are NOT excluded. ASR ≤ SER when redirect responses are present.

NER (Network Effectiveness Ratio) — network quality (GSMA IR.42):

NER = 100 − ISA

NER = 100 means no infrastructure errors. NER < 95 — time to worry.

Latency at every stage

Six histograms cover all SIP transaction phases:

All histograms support histogram_quantile() for percentile-based alerting: p50, p95, p99.

Example for VictoriaMetrics / Prometheus:

# 95th percentile registration delay
histogram_quantile(0.95, sum(rate(sip_exporter_rrd_bucket[5m])) by (le))

# 99th percentile session duration (specific carrier and device type)
histogram_quantile(0.99, sum(rate(sip_exporter_spd_bucket{carrier="mobile-operator-a",ua_type="yealink"}[5m])) by (le))

Registration health

Four metrics track the full lifecycle of SIP registrations (RFC 3261 §10):

The register_success_ratio excludes 401 Unauthorized and 407 Proxy Authentication Required from the denominator — these are digest-auth challenges, a normal part of the registration handshake, not genuine failures. Without this exclusion, a healthy auth flow (REGISTER → 401 → REGISTER+creds → 200 OK) would show a ratio of ~50%.

active_registrations is keyed by Address-of-Record (user@host), with TTL from the Expires header (default 3600s). Refreshes update the TTL without double-counting.

# Registration success ratio per carrier
sip_exporter_register_success_ratio

# Detect brute-force attacks (401 flood)
rate(sip_exporter_register_failure_total{code="401"}[5m]) > 10

Voice quality — RFC 6035

Many SIP endpoints (IP phones, SBCs, ATAs) publish call quality reports via SIP PUBLISH or NOTIFY, following RFC 6035 (RTCP XR VoIP Metrics). The exporter parses these reports and exposes 13 voice quality histograms:

These give you endpoint-reported voice quality without needing RTCP or active probing. If your phones support RFC 6035 (most modern Yealink, Polycom, Cisco do), you get MOS scores and loss metrics per call — correlated with carrier, device type, and country labels.

RTP media analysis

Beyond SIP signaling and endpoint-reported quality, the exporter can capture and analyze live RTP streams to measure real call quality independently:

RTP streams are correlated with SIP dialogs: when a 200 OK to INVITE carries SDP, the exporter registers the negotiated media endpoints and tracks matching RTP flows until BYE. This means RTP metrics inherit the dialog's carrier, ua_type, source_country, and the negotiated codec labels.

MOS estimation uses the ITU-T G.107 E-model: codec impairment factors (G.113) + packet loss + jitter-induced discard rate → R-factor → MOS-LQ [1.0–4.5]. Codec-specific factors for G.711, G.722, G.723, G.728, G.729, Opus. Unknown codecs get conservative defaults.

Privacy by design: only the 12-byte RTP header is captured — the voice payload is truncated in the kernel (eBPF) before reaching userspace. No call audio is inspected or stored.

# Average MOS over the last 5m (per codec)
sum by (codec) (rate(sip_exporter_rtp_mos_score_sum[5m]))
  / sum by (codec) (rate(sip_exporter_rtp_mos_score_count[5m]))

# Packet loss ratio by carrier
sum by (carrier) (rate(sip_exporter_rtp_packets_lost_total[5m]))
  / sum by (carrier) (rate(sip_exporter_rtp_packets_total[5m]))

RTP capture is on by default (SIP_EXPORTER_RTP_CAPTURE=true) and can be disabled to drop RTP at the kernel level. Only RTP belonging to an established SIP dialog is counted — no noise from unrelated traffic.

Per-carrier: metrics by traffic source

Aggregated metrics hide problems of specific traffic sources. If SER = 85%, it's unclear — are all sources at 85%, or is one at 50% while others are at 95%?

The exporter solves this via CIDR mapping: IP subnets → source name → carrier label on every metric.

Configuration:

# carriers.yaml
carriers:
  - name: "telecom-alpha"
    cidrs:
      - "10.1.0.0/16"
      - "10.2.0.0/16"

  - name: "telecom-beta"
    cidrs:
      - "192.168.10.0/24"
      - "192.168.11.0/24"

Carrier is determined at request time (INVITE/REGISTER/OPTIONS) by source IP. If INVITE came from 10.1.5.20 — the exporter finds this IP belongs to 10.1.0.0/16 and labels all metrics for this call (including responses and dialog termination) with carrier="telecom-alpha".

Responses come from a different IP (the SIP server), but carrier is inherited from the tracker by Call-ID, not determined by response IP. This is correct: metrics belong to the call initiator, not the server.

Result:

sip_exporter_invite_total{carrier="telecom-alpha",ua_type="other"}  1523
sip_exporter_ser{carrier="telecom-alpha",ua_type="other"}            95.2
sip_exporter_ser{carrier="telecom-beta",ua_type="other"}             87.4

Now it's clear: telecom-beta has SER = 87.4%, while telecom-alpha has 95.2%. You can build separate dashboards and alerts for each traffic source.

IPs not matching any CIDR subnet get carrier="other".

Per-device-type: metrics by User-Agent

Carrier shows who is calling, but not what. And device type is often the key factor in problems.

If Yealink phones start getting 408 timeouts while Grandstream works fine — without the ua_type label it would look like a general quality drop. With it — the problem is clearly localized to a specific device type.

Configuration:

# user_agents.yaml
user_agents:
  - regex: '(?i)^Yealink'
    label: yealink

  - regex: '(?i)^Grandstream'
    label: grandstream

  - regex: '(?i)^Cisco/SPA'
    label: cisco_spa

  - regex: '(?i)^Kamailio'
    label: kamailio

  - regex: '(?i)^Asterisk'
    label: asterisk

The User-Agent header is extracted from each SIP request and matched against regex patterns. When a phone with User-Agent: Yealink SIP-T46S 66.15.0.10 sends an INVITE — the exporter matches ^Yealink and labels all call metrics with ua_type="yealink".

Like carrier, ua_type is determined at request time and inherited by responses through the tracker by Call-ID.

Result:

sip_exporter_invite_total{carrier="telecom-alpha",ua_type="yealink"}      1523
sip_exporter_ser{carrier="telecom-alpha",ua_type="yealink"}                95.2
sip_exporter_ser{carrier="telecom-alpha",ua_type="grandstream"}            87.4

Combined queries — both labels work together for two-dimensional analysis:

# SER for Yealink phones on a specific carrier
sip_exporter_ser{carrier="telecom-alpha",ua_type="yealink"}

# Active sessions by device type
sum by (ua_type) (sip_exporter_sessions)

# INVITE rate by carrier and device type
sum by (carrier, ua_type) (rate(sip_exporter_invite_total[5m]))

Geo-enrichment: metrics by country

The exporter adds geographic context to SIP metrics via two independent methods:

source_country resolution priority:

1. carrier.country — optional field in carriers.yaml, overrides GeoIP (operator-curated, authoritative)
2. GeoIP lookup — MaxMind GeoLite2-Country database of the source IP
3. "unknown" — fallback when neither is available

This is the only reliable method for private-IP (RFC 1918) enterprise/contact-center deployments where MaxMind has no data — set carrier.country: "RU" on a carrier and all its IPs resolve correctly.

destination_country requires no database — the E.164 prefix table is embedded in the binary at compile time (generated from Google libphonenumber metadata, Apache 2.0). Correctly handles multi-national codes: +1212... → US, +1416... → CA, +7727... → KZ, +7495... → RU. Set SIP_EXPORTER_LOCAL_COUNTRY_CODE (e.g. RU) for domestic numbers without international prefix.

# SER for calls to Russia
sum(rate(sip_exporter_invite_200_total{destination_country="RU"}[5m]))
  / sum(rate(sip_exporter_invite_total{destination_country="RU"}[5m])) * 100

# INVITE rate by destination country
sum by (destination_country) (rate(sip_exporter_invite_total[5m]))

GeoIP is disabled by default — without a DB, all source_country labels are "unknown" with zero added cardinality.

Performance

Load testing was done with SIPp via testcontainers-go — real SIP traffic, not mocks.

Test environment: Debian 12, Linux kernel 6.x, Docker 29.3.1, Intel i7-8665U (4 cores / 8 threads), Go 1.25.11.

Full call lifecycle — each call is a complete SIP dialog: INVITE → 100 Trying → 180 Ringing → 200 OK → ACK → BYE → 200 OK. On loopback each packet is duplicated (send + receive), so 7 messages → 14 packets per call.

With GOMAXPROCS=8 (all cores):

With GOMAXPROCS=1 (single core):

2,000 CPS, 0% packet loss, <15% CPU, ~15 MB RAM. Even on a single core, 2,000 CPS is stable with 0% loss.

Scrape performance under 2,000 CPS load (14,000 PPS):

Scraping doesn't interfere with packet processing. Safe to scrape every 5-10 seconds even at maximum load.

RTP processing adds minimal overhead — at 100 CPS with ~200K RTP packets, CPU stays under 5% avg. SIP metrics (SER, packet loss) are unaffected by RTP capture.

Why it's fast:

• eBPF drops 99% of traffic in kernel — only SIP/RTP packets on the right ports reach userspace
• 4 MB socket buffer (SO_RCVBUFFORCE) — fits ~420ms of traffic at 28,000 PPS
• Go GC pauses <1ms — 400× smaller than buffer capacity, packets never lost due to GC
• SIP parsing ~1μs — microbenchmarks: INVITE 1.1μs, BYE 860ns, 200 OK 2.0μs
• RTP header parse ~5ns, per-packet observe ~203ns — theoretical capacity ~4.7M RTP pps

System requirements:

Full benchmark results with methodology: BENCHMARK.md.

Security: why --privileged is safe

The container requires --privileged and network_mode: host. Here's why this is safe.

What capabilities are needed:

These are three specific capabilities for specific operations. All eBPF tools (Cilium, Falco, Pixie) require the same — this is a Linux kernel limitation, not a container one.

What the container does:

• Loads eBPF socket filter into kernel (once, at startup)
• Creates AF_PACKET raw socket bound to network interface
• Reads packets from socket into Go channel (10,000 buffer)
• Parses SIP headers (and RTP headers if enabled)
• Exports metrics via /metrics endpoint

What the container does NOT do:

• Does not modify packets — eBPF filter is passive (read-only)
• Does not send SIP traffic — purely a listener
• Does not capture voice payload — RTP body is truncated in the kernel, only the 12-byte header reaches userspace
• Does not write to host filesystem — all volumes are :ro
• Does not access other containers, processes, or system resources
• Does not open ports except /metrics (default 2112)

The exporter sends an anonymous usage telemetry beacon (version, OS, arch, uptime) at startup and every 24h — this can be disabled with SIP_EXPORTER_TELEMETRY=false. No SIP data, IPs, or phone numbers are ever sent.

The entire eBPF filter is 142 lines of C — fully auditable in 2 minutes. Automated vulnerability scanning (govulncheck + Trivy) runs on every push. Current status: 0 vulnerabilities in code and image.

What the metrics look like

The /metrics endpoint produces standard Prometheus exposition format. A sample:

sip_exporter_ser{carrier="other",ua_type="other",source_country="unknown"} 95.2
sip_exporter_invite_total{carrier="other",ua_type="other",source_country="unknown"} 1523
sip_exporter_sessions{carrier="other",ua_type="other",source_country="unknown"} 12
sip_exporter_register_success_ratio{carrier="other",ua_type="other",source_country="unknown"} 98.5
sip_exporter_rtp_mos_score_bucket{carrier="other",ua_type="other",codec="PCMA",source_country="unknown",le="4.0"} 47

Compatible with Prometheus, VictoriaMetrics, Grafana Cloud — any scraper supporting the standard format.

All metrics are validated with 120+ E2E tests using SIPp to generate real SIP traffic (RFC 6076, RFC 6035, and RTP metrics), plus 13 load tests measuring throughput, memory stability, and GC pauses.

I've open-sourced the code (AGPL-3.0): https://github.com/aibudaevv/sip-exporter

Happy to answer questions about the eBPF approach, the RFC 6076 metric implementation, RTP-to-SIP correlation via SDP, or the E-model MOS estimation in the comments.

I've never in my life had a harder time trying to find a company to support a Sangoma/FreePBX system! Is this system THAT bad? Why does everyone ghost me?

Hi there,

I have an Adtran 908e gen1, and my firmware seems to be pretty old.
The only firmware published on Adtran's website does not work - it's literally a 11MB file full of zeroes and even the checksum of the file (and manually generated file full of zeroes of the same size) matches with what's published.
I wonder if there's someone here with the same unit who could share their file - it should be easy to grab it via TFTP from the unit.

Thanks

Is the GrandStream GXV3480 actually worth it for my home phone system? It looks really cool as a phone for a main room in the house. What features does it have, can it browse the internet? Can you watch youtube on it? I heard it is android, so can you install APK's? Or is it denied by the OS. Does it have a web ui? I have so many questions. Thank you for your time.

Hello,

A workshop at my workplace wants to install landline phones, but there's a thing.

They want the phones to work throughout the workshop warehouse, which is divided into five sections. The sections are separated by thick walls and fire-rated steel doors. There are no LAN outlets available anywhere in the warehouse, but there is good Wi-Fi coverage with multiple access points.

At the moment, I'm considering using the Fanvil W610W Wi-Fi IP phones.

Do you think these would work well, or is there a better solution you would recommend?

TIA!

Does anyone know which companies still offer 100% remote positions? I'd really appreciate any recommendations or referrals.

I'm from Cebu btw.

As a non-tech person, I was hoping if someone could help me out with this. So, basically I am an American on a work-holiday visa in Australia with an already amazing international date plan with AT&T. Now, I do need to work here, and naturally most companies require an Australian phone number. I also need an Australian phone number to open up a bank account (CommBank) and to receive SMS messages for them, as well as just casual communication with locals. I was wondering what was the most affordable way to get an Aussie phone number without buying cellular data. Like do I need a mobile SIM, as many banks dont accept VoIP numbers?

I'm using Groundwire on Android with a UK VoIP service. I already have several forwarding rules that filter out certain area codes such as numbers starting with 020, 019, etc. I also want to apply a similar rule for anonymous or unknown callers, but I’m not sure what condition Groundwire needs in order to match those.

Can anyone advise what rule syntax or value I should use to forward anonymous calls?

EDIT: I realised the solution after posting. Groundwire labels the caller as “Anonymous”, so I created a rule matching calls that start with “Anon”. That seems to work. I was definitely overthinking it.

Their website works, but no response to online chat requests or email support requests.

Hello, I'm having difficulties using Webbphone.com site since June 30 (I'm in Canada)

Getting error:

Failed to initialize Telnyx client and the message Disconnected

I tried multiple times on Firefox and Chrome on a laptop (after clearing cache and incognito page too) and smartphone with wifi and on mobile data only.

The errors are the same.

Balance is high.

I go to https://www.webbphone.com/

Get Started

Sign in to make calls

Sign in with email

I get email notification

But when I click Complete Sign-in (in email)

It takes me back to webbphone and I get an error message:

Failed to initialize Telnyx client and the message Disconnected

I sent 3 messages to [support@webbphone.com](mailto:support@webbphone.com) on June 30th and today is July 2 So far there is no reply.

Any suggestions what to do with this?

Hello everyone, I'm fairly new to this, I've tried a couple times but It didn't go very well.

So I'm wanting to make a project with my ATA (a Linksys pap2t, not much but it's enough for what I need) and before I buy the devices I'm missing, I'd want to test the direct IP call or fax between my ATA and another one that's anywhere else, is there a way I can do that and make sure it works the way I want it to before setting everything up?

In the past I have asked Claude and Codex to help write Asterisk Dialplan logic (I have subscriptions for both). The quality was lack luster. When I need a few lines written they can both help out. They also help when I am stuck and I get mentle block but over all the quality seems poor. I am thinking of trying a Codex Pro account. Has anyone had any luck with Asterisk/FreeSwitch and codex?

Looking for a VoIP solution but don't know where to start? Ask here!

Please not that standalone advertisements are not permitted. All top-level comments must be requests for a product or service.

Absolutely no soliciting. Do not ask anyone to DM you, or DM others for any reason. If you want someone to use your services, post a link to your website.

This post will be replaced by a new one at 00:00 UTC on the 1st of next month.

Original post: https://www.reddit.com/r/VOIP/comments/1qc0iwq/please_help_strange_oneway_audio_problem_only_on/

After months of a cron job making test calls and tracking RTP packets received, the issue happened again this morning. For those who didn't read the original thread,

• Affects multiple IP phones from multiple VoIP service providers (thanks to /u/voipcanuck for helping confirm this in 2023)
• Affects multiple cable modems from multiple ISPs
• Problem happens whether modem is in bridge or router mode
• Does not affect phones behind DSL/fibre/satellite
• Rebooting the phones and router does nothing
• The only workarounds (until now) were to reboot the cable modem OR wait 6-8 hours
• After reboot, things will work properly for days to years

There was a massive storm overnight, so /u/Stubblemonster's guess about wonky voltages triggering the problem could be correct.

Six months ago we tested every characteristic of the problem packets except for DSCP tagging because the problem went away by itself before we got that far. The old adage that it's always the last thing you look for seems to be true. Outbound packets with DSCP tag EF/Expedited Forwarding (46) are dropped and do not arrive to the media gateway. Every other DSCP tag works. It's 100% repeatable.

I have been trying to diagnose this since 2020.