VoIP.info Troubleshooting

VoIP Much trunk registers but calls or audio fail

Separate registration, source-address policy, number and route selection, channel scope, signaling, SDP and both media directions before changing credentials or firewall rules.

Reviewed 2026-10-16Current VoIP Much SIP-trunk product, 3CX, FreePBX, UniFi Talk, IP-blocking, SIP ALG, codec, quality, status and service-agreement pages reviewed October 16, 2026. Registration-based account examples, account-issued server and credentials, paid channel scope, supported codec lists, SIP-server port guidance and several network cautions are documented; selected-account DNS, transport and proxy profile, number inventory, caller identity, routing, failover, RTP range, DTMF, fax, emergency service, messaging, encryption, capacity, price, SLA, availability and compatibility remain account, route, contract or observation specific. No account, order, credential, trunk, number, registration, packet, media stream, status incident, emergency call or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one failure and classify the earliest divergence

Record the timestamp and timezone, account and trunk identifiers, PBX release and driver, loaded server and transport, registration result, direction, dialed and normalized number, caller identity, response code, alert, answer, SDP, first RTP packet in each direction and user outcome. Redact secrets and personal numbers before sharing evidence.

Classify the first divergence as no request, no response, repeated challenge, source blocked, rejected INVITE, wrong number route, channel refusal, remote not alerted, no answer, no media, one-way media or later degradation. A successful REGISTER ends only the registration branch.

Prove registration cadence and source-address state

Compare the loaded account-issued server, username, credential owner, Contact and expiry with one complete REGISTER transaction. VoIP Much says failed credentials and registration requests that ignore the minimum re-register time can trigger source blocking. Stop uncontrolled retries, preserve the exact responses and coordinate any unblock through the authorized support path.

If the environment has multiple PBXs, devices or public addresses using the same identity, document them before deleting contacts or changing NAT. The provider warns that multi-device use can affect inbound delivery; do not treat a consumer clone-device note as proof of a trunk redundancy feature.

Trace outbound and inbound routing independently

For outbound failure, retain the digits before and after PBX normalization, Request-URI, From and asserted identity, selected trunk, provider response and paid-channel state. Invalid numbers can contribute to provider source blocking, so do not automate repeated probes. For inbound failure, identify the owned number, provider route, delivered Request-URI and identity, selected PBX route and final destination.

A registered contact does not establish that every number points to it. A status-page OK does not establish selected-account routing. Correct only the earliest demonstrated number, identity, authorization, channel or route mismatch and repeat the same permitted call.

Compare the SDP and both packet directions before touching codecs

Preserve the offer and answer, selected codec and packetization, DTMF method, advertised media addresses, NAT rewrites, first and last packet per direction, loss, jitter and decoded result. Reconcile the codec actually negotiated with the provider documentation; do not enable every listed codec to hide a specific mismatch.

No RTP differs from packets in one direction, packets reaching the host but not the PBX, and packets decoded but not heard. VoIP Much associates SIP ALG with one-way audio and dropped calls, but that warning is not proof that ALG caused this call. Demonstrate the signaling or SDP rewrite before changing it.

Verify the repair without creating a wider exposure

Repeat one authorized inbound and outbound call, confirm intended identity and number route, answer, two-way audio, DTMF and clean release, then compare a negative control. Confirm that registration cadence remains within the server response, temporary captures and broad rules are removed, and normal monitoring and escalation are restored.

Do not open unrestricted SIP or RTP forwarding, weaken authentication, raise channel scope or use an emergency number merely to clear an alarm. The public documentation was reviewed for this workflow; no account, block, firewall, packet, media stream, service incident or live call was inspected or tested.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.