Authorize the observed public source before testing outbound calls
Voxbeam's current getting-started page says outbound service is authenticated by IP address and requires the customer address in the account Settings area. Preserve the intended account, authorized address, actual translated public source, signaling destination and first provider response. A local interface address, a saved portal value and the source observed by the provider are three different facts.
The page names sbc.voxbeam.com as the SIP server. Preserve the DNS answer and selected address at test time rather than turning one resolved address into permanent policy. The reviewed public pages do not establish SIP REGISTER as the current outbound health signal.
Documented service facts
Reviewed 2026-10-22. Compare SIP trunk services →
Outbound authentication
DocumentedVoxbeam's current getting-started page documents outbound authorization by customer public source IP entered in account Settings. Preserve the intended account, saved address, actually translated egress source, DNS-selected provider target and first response; these are separate observations.
SIP registration
DocumentedThe current public outbound workflow documents source-IP authorization rather than SIP REGISTER. A legacy Voxbeam Asterisk peer example contains username and secret fields but does not establish a current registration or digest-authentication contract. Verify the live account method before using registration as health evidence.
Inbound delivery
DocumentedA trunk-level IP or SIP URI is the default inbound destination, while a populated per-DID SIP Endpoint URI overrides it; an empty DID field falls back to the trunk default. Preserve DID ownership, both values, provider attempt, current source, Request-URI and first PBX route.
Inbound failover
Not verifiedVoxbeam publishes provider-network redundancy and hot-standby claims, but the reviewed pages do not establish an ordered set of customer SIP destinations or its failure triggers. Provider infrastructure claims do not prove customer PBX, access-circuit, DNS or active-call failover.
Number and regional availability
Not verifiedVoxbeam publishes DID search and porting paths, while exact number inventory, documents, portability, activation timing, caller-identity handling and route reach vary by market, number, account and date. Confirm the selected order before migration.
Audio codecs
DocumentedVoxbeam publishes route-dependent codec support: G.729a and G.723 across its routes, with G.711 mu-law, G.711 A-law and G.726 for most. Preserve both SDP bodies and the selected codec because the catalog does not prove one specific destination or carrier path.
T.38 fax
Not verifiedThe DID page lists T.38, but it does not establish universal number, direction, carrier, renegotiation, error-correction or fallback behavior. Pilot each selected number, endpoint, page profile and audio fallback separately.
Signaling and media encryption
Not verifiedThe reviewed current product, help, FAQ and network pages do not establish one customer-facing TLS and SRTP trunk workflow. Source-IP authorization controls network identity; it must not be represented as signaling or media encryption.
Call-start capacity
DocumentedVoxbeam distinguishes DID-only service with two concurrent calls per DID and a published minute threshold from shared purchased trunk channels. A DID-specific channel cap cannot exceed the trunk count. None of those values establishes calls per second or every downstream limit.
Emergency calling
Not verifiedThe reviewed first-party pages do not document an emergency-calling enrollment, registered-location, calling-identity, dispatch or approved test workflow for this service. Obtain a written account-specific procedure or retain a separately validated route before deployment.
Pricing model
Not verifiedPublic pages distinguish outbound route classes, DID-only service and channel-based inbound capacity. Exact rates, increments, number charges, minimums, taxes, surcharges, support and contract terms require the current account portal or a dated quote.
Administration and support
DocumentedPreserve authorized and observed source IPs, DNS result, selected route class and prefix, DID-level endpoint, trunk default, current provider ingress publication, package and channel settings, loaded PBX objects, call records and authorized changes together.
SMS and MMS
Not verifiedThe FAQ describes SMS on some US DIDs and excludes toll-free numbers from the published scope. It does not establish MMS, universal eligibility, sender registration, throughput, API behavior, retention or pricing; evaluate messaging separately from voice.
Apply one route-class prefix to the normalized destination
Voxbeam documents an E.164-style destination with an added route prefix and publishes separate prefixes for Platinum, Gold, Silver and Call Center routes. Capture the user-entered number, PBX normalization result, selected class, exact Request-URI and first response. A correct country code with the wrong or duplicated route prefix is still a different provider request.
Route-class descriptions are commercial positioning, not proof that one individual call delivered CLI, met a quality target or used a particular underlying carrier. Preserve the actual call record and signaling evidence without turning a route label into an outcome.
Trace inbound delivery through trunk default and DID override
The Voxbeam FAQ documents a default trunk-level IP or SIP URI and a per-DID SIP Endpoint URI override. When the DID-level field is empty, it falls back to the trunk default. Preserve DID ownership, the DID-level value, trunk default, provider source, delivered Request-URI and first loaded PBX route.
The FAQ also publishes a current ingress-address list. Treat that list as dated provider publication: reconcile it through the normal firewall change process and confirm the actual packet. An allowed address does not prove that the provider attempted the call or that the PBX matched the intended endpoint.
Keep DID-only limits, trunk channels and media claims separate
Voxbeam distinguishes a DID-only package with two concurrent calls per DID and a published incoming-minute threshold from a capacity package with purchased shared channels. The FAQ also allows a per-DID channel limit that cannot exceed the trunk channel count. Preserve package, trunk channels, DID override and the observed rejection independently; none of these values establishes calls per second or every downstream limit.
The public FAQ lists route-dependent codec support and the DID page advertises T.38. Preserve both SDP bodies, the selected codec, DTMF method, RTP endpoints and fax negotiation. A catalog statement does not prove that a particular destination, number, direction or carrier path negotiated it.
Translate the provider Asterisk example to the installed driver
Voxbeam's downloadable Asterisk example uses sip.conf, chan_sip-style peers, insecure=very and route-prefixed Dial strings. Current Asterisk documentation says chan_sip was removed in Asterisk 21 and identifies PJSIP as the standard SIP driver. Treat the provider example as historical field and dial-pattern evidence, not a current paste-in template.
Inventory the running Asterisk or FreePBX release, generated-configuration owner and loaded PJSIP endpoint, AOR, identify, transport and dialplan objects. For source-identified inbound traffic, prove the current provider source matched the intended identify object before changing contexts or broadening an ACL.
Preserve unsupported and commercial questions as open checks
The reviewed public pages do not establish a current customer TLS or SRTP workflow, emergency-calling enrollment and test process, a complete customer-destination failover policy or universal caller-ID delivery. Provider-network redundancy is not the same as customer endpoint order, retry triggers, restoration or established-call survival.
Obtain the current rate deck, route terms, DID order, support window and approved escalation path for the exact account. No account, call, packet, media stream, failover event, emergency result, price, availability, compatibility or support response was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Voxbeam getting-started and outbound routing help ↗
- Voxbeam service and DID FAQ ↗
- Voxbeam DID service and capacity packages ↗
- Voxbeam wholesale voice services ↗
- Voxbeam network overview ↗
- Voxbeam VoIP glossary and codec summary ↗
- Voxbeam Asterisk chan_sip example ↗
- Asterisk chan_sip removal and PJSIP guidance ↗
- Asterisk PJSIP endpoint-identification troubleshooting ↗
- Voxbeam FreeSWITCH configuration guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.