VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

MetTel SIP Trunking: order, capacity, identity and 911 evidence

Evaluate MetTel SIP Trunking without turning product copy, bursting, policy limits, portal access, codec names or 911 terms into an assumed account configuration or tested call path.

Reviewed 2026-10-29Current first-party MetTel SIP Trunking product, portfolio, VoIP-term, support, order and product-guide records were reviewed October 29, 2026. The current order, service location, account, product-specific terms, assigned numbers and provider confirmation govern. Public records do not establish one account’s registrar, authentication model, transport, addressing, firewall rule, encryption, ordered call paths, burst entitlement, number delivery format, emergency-location state, price, availability or PBX compatibility. No MetTel account, order, portal, credential, trunk, registration, PBX, SBC, firewall, packet, number, call, media stream, capacity event, outage, emergency outcome, price, availability, compatibility, ticket or support response was inspected or testedAdvancedDocumentation based · not lab tested

Start with the exact ordered product and service boundary

MetTel lists SIP Trunking separately from SIP PRI, Cloud PBX, Digital Voice and other cloud-communications products. The SIP Trunking datasheet describes an IP PBX using the customer data network, while the general terms say the accepted order and product-specific guide govern availability, installation and demarcation. Preserve the legal customer, order identifier, product, site, access, number inventory, enabled date and responsibility boundary.

A sales datasheet, approved order, portal inventory row, enabled cloud call path and completed call are different evidence. Do not transfer SIP PRI gateway behavior, Cloud PBX administration or a federal contract specification to a commercial SIP Trunk order.

Documented service facts

Reviewed 2026-10-29. Compare SIP trunk services →

SIP authentication

Not verified

The reviewed public records do not establish one universal MetTel registrar, authentication name, password, digest realm, source-IP model or certificate path. The accepted order and provider configuration govern.

SIP registration

Not verified

The product sheet establishes SIP Trunking for an IP PBX but does not establish whether one order registers, uses source-address identification or another handoff. Loaded state and an accepted transaction remain unverified.

Numbers and inbound delivery

Documented

The product sheet lists directory services, calling-name handling and optional additional DIDs. Assignment, activation, delivered called-number format, route match and completed call remain unverified.

Redundancy and continuity

Documented

MetTel describes six geographically redundant North American data centers. One order’s ingress diversity, DNS or route behavior, customer-access diversity, established-call survival and completed failover remain unverified.

Access and serviceability

Documented

MetTel describes service over Internet or dedicated connectivity. Exact locations, access, demarcation, serviceability, activation, routing and lead time require an accepted order and current confirmation.

Codecs and QoS

Documented

The product sheet lists G.711 or G.729 and describes traffic prioritization. Offer, answer, packetization, RTP directions, decoding, audibility and end-to-end QoS remain unverified.

Fax

Not verified

The reviewed MetTel SIP Trunking records do not establish T.38, passthrough, fallback, gateway requirements or completed-page results for one order.

Transport and protection

Not verified

The reviewed public records do not establish TLS, SRTP, certificate policy, source ranges, firewall rules or one order’s credential custody. Account-specific provider records govern.

Call paths, bursting and rate

Documented

The datasheet describes concurrency-based trunk sizing and on-demand bursting; current VoIP terms publish one-call-per-second and traffic-policy boundaries. One order’s paths, burst entitlement and observed capacity remain unverified.

911 and location

Documented

MetTel’s VoIP terms bind service to registered-location, power, access and account-state conditions and identify separate nomadic terms. One effective address, number association, route, callback and outcome remain unverified.

Price, order and availability

Not verified

Pricing, fees, availability, optional features, serviceability and activation are time-sensitive and order-specific. This record does not reproduce them as a quote.

Portal, activation and support

Documented

MetTel documents Bruin portal, activation, porting, ticket-status and advanced-services support paths. Portal rows, tickets, provider findings and verified restoration remain separate evidence.

SMS and MMS

Not verified

The reviewed MetTel SIP Trunking records do not establish SMS or MMS on trunk numbers, sender registration, throughput, retention, API access or price.

Keep ordered paths, bursting and traffic policy separate

The product sheet describes sizing trunks to maximum concurrent calls and on-demand bursting for spikes. MetTel’s current VoIP terms separately publish a one-call-per-second limit, a call-completion policy and an inbound-versus-outbound traffic ratio for SIP Trunking. Ordered call paths, burst entitlement, attempted starts, admitted dialogs, simultaneous active calls, media load and monthly traffic policy are different quantities.

A burst claim does not prove unlimited capacity or account entitlement. A rejected attempt can involve order limits, policy, routing, identity, destination response or PBX resources; preserve the first response and account evidence before changing capacity.

Treat number assignment and caller identity as controlled records

The datasheet lists Calling Line ID, calling-name delivery and retrieval, directory listing and optional additional DIDs. The VoIP terms require caller line identity to be a name and number the customer is authorized to use. Preserve assigned number, selected PBX identity, signaling value, provider acceptance, downstream presentation and final call result separately.

A DID on an invoice or portal row does not prove activation, inbound delivery format, PBX route match, callback or emergency-location association. Port request, provider acceptance, activation, first inbound attempt and stable operation also require their own evidence.

Separate access, QoS, codecs, signaling and audible media

MetTel describes service over the Internet or a dedicated connection and lists G.711 or G.729 in the product sheet. It also describes integrating voice and data while prioritizing business traffic. Record the ordered access, customer and provider demarcation, route, measured bottleneck, QoS marking and queue treatment without assuming end-to-end priority.

Published codec names do not prove one offer, answer, packetization or licensed use. SIP signaling, SDP, RTP tuples, packet directions, decoding and what each party heard remain separate. The public records reviewed here do not establish a registrar, source-address policy, TLS, SRTP, firewall range or universal PBX template.

Use Bruin, ticket and support records as bounded evidence

The datasheet lists the Bruin platform, the general terms describe the MetTel portal for ordering and service-ticket management, and the support page exposes activation, porting, ticket-status and advanced-services paths. Preserve portal inventory time, order or change request, ticket identifier, affected service, status event, provider finding and restoration separately.

A green portal state, open ticket, platform-status notice or closed case does not by itself prove registration, route acceptance, media or durable restoration. Support contacts are operational paths, not availability or response-time guarantees for one order.

Bound outages, account state and 911 to the effective location

MetTel’s VoIP terms state that Internet or dedicated-connection outages, power loss and account suspension can interrupt service including 911. The same terms require the customer to notify MetTel before moving the service location and distinguish non-fixed or nomadic 911 terms. Preserve the effective registered address, number association, presented identity, callback, PBX route, provider route, power, access and independent calling method.

Do not place an uncoordinated live 911 call as a test. A portal address, change request or ordinary completed call does not prove emergency routing. Pricing, administrative fees, serviceability, activation and optional features are time-sensitive and order-specific, so this guide does not reproduce them as current quotes.

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.

Continue your research

Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Troubleshooting · Current first-party MetTel SIP Trunking product, portfolio, VoIP-term, support, order and product-guide records were reviewed October 29, 2026. The current order, service location, account, product-specific terms, assigned numbers and provider confirmation govern. Public records do not establish one account’s registrar, authentication model, transport, addressing, firewall rule, encryption, ordered call paths, burst entitlement, number delivery format, emergency-location state, price, availability or PBX compatibility. No MetTel account, order, portal, credential, trunk, registration, PBX, SBC, firewall, packet, number, call, media stream, capacity event, outage, emergency outcome, price, availability, compatibility, ticket or support response was inspected or tested

MetTel SIP trunk capacity, caller ID, 911 or call fails

Find the first divergence across order, site, access, number, policy, identity, signaling, media, portal, support and emergency-location evidence.

Read guide →
Guide

SIP trunking: numbers, capacity and operational control

Plan the carrier relationship that connects a self-managed PBX to outside calling.

Read guide →
Guide

SIP trunk channels and simultaneous calls

Size external capacity around busy-hour demand and the provider’s counting rules.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Guide

QoS for VoIP

Apply prioritization where you control the bottleneck and understand what happens beyond it.

Read guide →
Guide

Firewall rules for VoIP

Define management, signaling and media access separately using actual deployment requirements.

Read guide →
Guide

PBX credentials and extension secrets

Keep administrator, handset, trunk and backup identities separate and retire them deliberately.

Read guide →
Guide

Planning emergency calling for a VoIP deployment

Assign responsibility for location, routing and outage procedures before rollout.

Read guide →
Guide

Business number porting: a cutover checklist

Keep ownership records, dependencies and a fallback plan aligned with the gaining provider’s process.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Guide · FreePBX 17 and current Asterisk res_pjsip documentation reviewed October 5, 2026; Sangoma's generic module pages are responsibility guides rather than an exact installed field map; no FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested

Configure and verify a FreePBX 17 PJSIP trunk

Translate current carrier requirements into FreePBX-owned PJSIP trunk, route and identity controls, then verify the generated Asterisk objects and each call direction independently.

Read guide →
Guide · Current Asterisk PJSIP object, outbound-registration, configuration-example and res_pjsip references reviewed October 1, 2026; no account, carrier, PBX, endpoint, registration, identifier, route, call, emergency workflow, media stream, capacity or failover path was tested

Plan and configure an Asterisk SIP trunk

Translate each carrier direction into explicit PJSIP objects, identification, restricted dialplan, retry policy and leg-by-leg acceptance evidence.

Read guide →
Troubleshooting · Current SIPTRUNK IP-authentication, registration, status, inbound-call, failover, interconnection and general-configuration documentation reviewed October 14, 2026; the sources describe mutually exclusive credential-registration and static-public-IP modes but do not prove the selected account mode, public address, gateway resolution, Contact, registration, number assignment, route, failover treatment, capacity, compatibility or completed call, and no account, portal, credential, PBX, firewall, DNS answer, packet, registration, number, route, failover event, media stream or live call was inspected or tested

SIPTRUNK registration or IP-authentication mode does not match the call path

Determine whether the trunk uses credential registration or static-IP authentication, then trace the exact public address, gateway, Contact or stored destination, provider state, inbound route and failover treatment.

Read guide →
Troubleshooting · First-party Asterisk documentation and SIP standard reviewed September 30, 2026; FreePBX 17 terminology retained; no PBX, provider, number, route or live call test

Inbound VoIP calls do not reach the business

Trace carrier delivery, Asterisk endpoint identification, DID matching and the final destination without collapsing the boundaries.

Read guide →
Troubleshooting · Current Sangoma outbound-route guidance, current Asterisk Dial and troubleshooting documentation, and SIP standards reviewed October 5, 2026; no phone, PBX, carrier or live call test

Outbound VoIP calls fail: locate the broken call leg

Classify one failed call, then follow the exact digits through the phone, PBX route, attempted trunk, remote response, answer and media.

Read guide →
Troubleshooting · Current Sangoma Core API, outbound-route, trunk, caller-ID customization and emergency-service documentation plus current Asterisk res_pjsip and party-ID documentation reviewed October 11, 2026; several detailed Sangoma GUI guides retain older PBX GUI examples, and no PBX, extension, route, trunk, provider account, number, header, identity, privacy state, presentation, emergency service or live call was inspected or tested

FreePBX outbound caller ID is wrong or rejected: trace the active owner

Bind one call to the selected route and trunk, resolve FreePBX identity precedence, inspect the egress headers and separate carrier authorization from destination display.

Read guide →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 checks

One-way VoIP audio

Trace the missing direction from advertised media address to receiving endpoint.

Read guide →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 checks

VoIP call connects but has no audio

Separate endpoint audio selection from a media path that fails in both directions.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →