Start with the ordered trunk, not the generic compatibility list
net2phone presents its SIP trunk as a connection for an existing PBX and names several PBX vendors and projects. That portfolio-level compatibility statement does not define the supported release, module, gateway, SBC, topology or tested feature set for one deployment.
Require the dated quote, order and implementation handoff. Record the PBX and SBC versions, access provider, peers or registrar, authentication owner, transport, number inventory, channels and support boundary before adapting a configuration.
Documented service facts
Reviewed 2026-10-08. Compare SIP trunk services →
SIP authentication
Not verifiedThe reviewed public product page, July 2026 terms and general guide do not define whether the selected trunk authenticates by source address, SIP digest credentials, certificate or a combination, nor do they publish a realm, digest algorithms or allowlist. Obtain the accepted implementation record and map each secret, address and certificate to its PBX, SBC and provider owner without exposing reusable credentials.
SIP registration
Not verifiedThe public records do not establish whether one account uses REGISTER, static peering or another handoff. Record the registrar or peer addresses, transport, proxy, Contact behavior, expiration, qualification, DNS dependencies and source-address rules from the provider-approved implementation record rather than inferring them from a generic PBX compatibility claim.
Inbound delivery
Documentednet2phone says its portal manages call routing, caller ID, location addresses and associated phone numbers and markets virtual numbers in more than 50 countries and 300 cities. Those statements do not establish one account's assigned inventory, completed port, delivered Request-URI, asserted identity, normalization or route priority. Preserve the order, number record and authorized traces for every accepted inbound pattern.
Routing and failover
Not verifiedThe product page describes global infrastructure and a fully redundant network, while a separate public status page exposes platform-level operational reporting. Neither source defines one trunk's ingress or egress peers, route priority, failure responses, timers, customer-access diversity, alternate destination, established-call behavior or recovery order. Bind resilience to the order and implementation handoff, then validate new-call behavior under an approved exercise.
Number and regional availability
DocumentedThe product page markets international calling to more than 40 countries and DIDs in more than 50 countries and 300 cities. The terms say requested numbers and ports are not guaranteed and reserve rights over international numbers. Treat the published footprint as a portfolio claim; retain dated serviceability, number-availability and portability responses for the exact country, rate centre, address and account.
Audio codecs and DTMF
Not verifiedThe reviewed public records do not publish a complete current codec, packetization, DTMF, early-media, transcoding or media-address profile for the selected interface. Obtain the provider-approved handoff and retain both SDP bodies, negotiated payload mapping, RTP evidence and decoded digit results for each required call path.
T.38 fax
Not verifiedThe reviewed SIP-trunk pages and terms do not establish T.38 or audio-fax entitlement, direction, switchover, gateway compatibility, error-correction handling, redundancy or page limits. The terms' separate references to fax use do not define a SIP-trunk fax transport. Treat fax as its own ordered and accepted workflow with a non-sensitive representative document set.
Signaling and media encryption
Not verifiedThe product page's increased-security language does not define SIP TLS versions, certificate validation, client certificates, SRTP suites, keying, topology hiding or the protected call legs for the selected service. Keep access controls, signaling protection, media protection, PBX hardening and fraud policy separate until the exact handoff and authorized traces prove each control.
Concurrent calls and call starts
Documentednet2phone presents calling on a per-channel basis and its current FAQ gives an approximate twenty-channel illustration for a trunk. That public illustration is not one account's ordered capacity and does not establish calls per second, bursts, access bandwidth, PBX or SBC resources, or provider enforcement. Use the quote and order for exact channels and a provider-approved load plan for call-start acceptance.
Emergency calling
DocumentedThe July 2026 terms require SIP-trunk customers to register a unique telephone number and accurate location for each handset or line and to send the number associated with that service address on an emergency call. Availability is location-dependent; power, broadband and service outages can prevent calling, the service is not primary-line or lifeline service, and net2phone recommends an alternate means of reaching emergency services. Confirm activation, supported equipment, every number-address association and the provider-approved validation procedure before use.
Pricing model
Not verifiedThe reviewed current product page does not publish a complete selected-account price. Bind channels, calling scope, numbers, ports, installation, equipment or gateways, international and toll-free usage, emergency service, support, taxes, term, renewal and cancellation to a dated quote, contract and bill. Do not apply generic cost illustrations to the account.
Administration and support
Documentednet2phone says the portal can create and manage trunks, caller ID, call routing, location addresses and associated numbers, and can view and export call-detail records. A public status page reports platform services separately. Preserve account roles, change approval, onboarding contacts, incident timestamps, ticket numbers, portal exports and the responsibility split among net2phone, the access supplier, PBX or SBC owner and customer network.
SMS and MMS
Not verifiedThe reviewed SIP-trunk product page does not establish SMS or MMS entitlement on trunk numbers, sender registration, API access, throughput, webhook security, retention or price. A general guide's reference to messaging is not a selected-product interface commitment. Treat messaging as a separate service and workflow unless the order and current technical documentation say otherwise.
Keep channels, trunks and call-start rate separate
The product page describes calling on each channel, while its FAQ gives an approximate illustration of twenty channels per trunk. Treat that as public product language rather than the selected account's limit.
Record ordered channels separately from trunk objects, telephone numbers, simultaneous calls, calls per second, bursts, access bandwidth, PBX resources and SBC capacity. Validate only the exact numeric contract under a provider-approved load plan.
Make the portal inventory traceable
net2phone says its portal can create and manage trunks, caller ID, call routing, location addresses and associated phone numbers and can export call-detail records. Those controls are useful evidence surfaces, not proof that a saved change is active or that a call followed the intended path.
Retain the current number and location inventory, change owner and export time. Correlate a portal value with the order, loaded PBX or SBC state, authorized SIP trace and provider CDR before concluding that identity or routing is correct.
Do not turn redundancy language into a failover design
The product page describes global infrastructure and a fully redundant network. The provider also operates a public status surface. Neither establishes one customer's access diversity, ingress and egress peers, route priority, failure responses, trigger timers, alternate destinations, established-call survival or restoration order.
Build continuity from the selected handoff and access design. Exercise approved new-call cases in both directions, preserve the failure stimulus and restored result, and keep provider-platform status separate from PBX, SBC, LAN and internet-access health.
Treat emergency identity and location as per-line controls
The July 2026 terms require a unique telephone number and accurate location for each handset or line used with SIP Trunking. Emergency calls must send the number associated with that service address. Availability is location-dependent, service outside the United States or Canada requires written agreement, and wrong or missing records can cause failure, misrouting or dispatch to the wrong address.
The terms also say power, broadband and service outages can prevent all calling, that the service is not primary-line or lifeline service and that an alternate means of reaching emergency services should be maintained. Confirm activation and supported equipment, reconcile every number-address pair and use only net2phone's approved validation procedure.
Resolve the technical interface and commercial record before acceptance
The reviewed public records do not define the selected authentication or registration method, complete codec and DTMF profile, fax support, SIP TLS or SRTP policy, messaging interface, call-start limit or account pricing. Marketing descriptions of security, redundancy or compatibility do not fill those fields.
Obtain the current technical handoff, quote, contract and support plan. Accept registration or static peering, inbound delivery, outbound identity, two-way media, DTMF, hangup, continuity and emergency records separately. No account, trunk, PBX, packet flow or live call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- net2phone SIP Trunking ↗
- net2phone Terms of Service — updated July 2026 ↗
- net2phone SIP trunking guide ↗
- net2phone service status ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.