Freeze the assigned service model and identity
BCM One's September 2024 guide separates PBXs with a static public address from those with a dynamic public address. Dynamic service registers with an assigned username and password; static-address service does not need REGISTER for inbound delivery. Preserve the account worksheet, selected model, assigned proxy, public-address ownership, source authorization, registration identity, Contact, expiry and redacted credentials independently.
The guide carries legacy nexVortex hostnames, while BCM One's current portals page identifies a separate SIP Trunking portal formerly branded nexVortex. Treat that lineage as documentation context, not permission to replace an assigned hostname. Portal access, an Active indicator, REGISTER, an authenticated outbound request and an inbound call are different evidence states.
Documented service facts
Reviewed 2026-10-20. Compare SIP trunk services →
Authentication
DocumentedThe September 2024 implementation guide separates static-public-IP service from credentialed registration. It says dynamic-public-IP PBXs require registration using the assigned username and password, while a static-public-IP PBX does not need to register. Preserve public-address ownership, source authorization, credentials and the selected service model separately.
SIP registration
DocumentedThe guide requires registration for dynamic public addresses and gives bounded expiry guidance, but says a static public address should not register for inbound delivery. A successful REGISTER, portal Active status and completed inbound or outbound call remain different evidence states. Confirm the current account worksheet and registrar before using the historical nexVortex hostnames in the guide.
Inbound delivery
DocumentedNumber Routing selects static-address or dynamic-registration delivery for each DID or toll-free number and can translate the inbound Request-URI user. Preserve the number, term type, selected address or Contact, translation, delivered identity, edge receipt and PBX result separately.
Inbound failover
DocumentedProvider-side DNS SRV or primary/backup proxy behavior and per-number Disaster-Recovery Routing are distinct. The latter can use as many as three alternate telephone-number or IP destinations. The public guide does not establish one universal timer, response-code matrix, restoration sequence or established-call guarantee.
Number and regional availability
Not verifiedThe guide describes continental US and Canada outbound calling, DID and toll-free inbound service, international capability and number porting. It does not establish current inventory, portability, service eligibility or regulatory support for any requested address or number. Obtain a dated order and portability result for the exact account and location.
Audio codecs and DTMF
DocumentedThe guide lists G.711u and G.729a and specifies RFC 2833 telephone-event DTMF with payload 101 toward BCM One gateways. Its bandwidth figures are planning inputs, not measured call quality or account acceptance. Capture the actual SDP, packetization, RTP endpoints and digit events on authorized representative calls.
T.38 fax
DocumentedBCM One documents G.711u pass-through and T.38, recommends T.38, and explicitly calls fax over IP best effort. This is not a delivery guarantee. Qualify the exact number, direction, gateway, document set, initial audio path, T.38 switchover, redundancy, page count and fallback behavior.
Signaling and media encryption
Not verifiedThe reviewed BCM One guide documents UDP 5060, a TCP exception path, source-address and RTP firewall requirements, passwords and PBX hardening, but does not establish customer-facing TLS, certificate validation, SRTP or a downgrade policy for this service. Flowroute support articles describe a different BCM One-owned service and are not transferred to this record.
Concurrent calls and burst
Not verifiedThe guide advertises unlimited SIP trunk call paths but separately notes restrictions for broadcast and auto-dialer applications and recommends PBX-side maximums. It does not publish one account's call-start rate, fraud controls, fair-use terms, queueing or rejection behavior. Do not convert marketing language into infinite technical capacity; obtain dated contractual and operational limits before load testing.
Emergency calling
DocumentedThe current E911 addendum requires the outbound caller ID to be the specific ten-digit DID associated with the service and requires correct physical-address notification for changed, added or ported numbers. Preserve approved location and current 933 procedure; ordinary call success is not an emergency-routing test.
Pricing model
Not verifiedThe reviewed guide and public legal index do not publish a complete current SIP Trunking quote. Obtain dated terms for call paths, usage, numbers, toll-free service, international calling, off-net disaster-recovery forwarding, E911, porting, taxes, support, restrictions, renewal and termination. A real-time billing portal is operational evidence, not a general rate card.
Administration and support
DocumentedThe current portals page separates Customer Care from the SIP Trunking portal formerly branded nexVortex. The legal index lists base SIP, SIP HyperNetwork and E911 documents separately. Preserve the assigned portal, service schedule, worksheet, hosts, DNS answers, tickets and changes rather than transferring terms across products.
SMS and MMS
Not verifiedThe reviewed BCM One SIP Trunking implementation guide does not establish SMS or MMS on trunk numbers. Voice and toll-free service do not prove messaging eligibility, sender registration, consent management, API delivery, throughput, retention or fees. Verify the exact number and a separately identified messaging product before representing support.
Follow each number through delivery and Request-URI translation
The Number Routing workflow chooses static-address or dynamic-registration delivery for each DID or toll-free number and can translate the user part of the inbound Request-URI. Preserve the number, term type, selected public address or registered Contact, configured translation, delivered Request-URI, To identity, PBX endpoint or trunk match, context and final destination.
A portal save records configured intent; it does not prove provider execution, packet arrival or PBX acceptance. For an authorized call, correlate the provider timestamp and call identifier with the customer-edge INVITE, Request-URI, To, Diversion or History-Info when present, the first SIP response and the user-visible result. Change only the first proven divergence.
Separate provider redundancy from per-number recovery
BCM One documents DNS SRV and primary or backup proxy behavior for provider-side service redundancy. It separately describes Disaster-Recovery Routing for an individual number, with as many as three alternate telephone-number or IP destinations after delivery to the intended location fails. A second provider proxy and an alternate per-number destination are not the same recovery layer.
Record which layer selected the next target, its order, the observed response or absence of response, timestamps and the resulting destination. The reviewed public guide does not define one universal detection interval, retry-code matrix, restoration sequence or established-call survival guarantee. Treat recovery routing as a new-call control unless dated account material and an authorized test establish more.
Keep service operation and SLA eligibility distinct
BCM One's base SIP SLA measures an outage only for network elements under its exclusive control and excludes third-party transport, customer systems, incorrect IP-PBX or CPE routing, lines reconfigured during the month, and backup or alternate routes. Its availability figure, trouble-ticket clock and credit process therefore do not prove that one number, Request-URI, PBX route or disaster-recovery destination worked.
The legal index lists the base SIP SLA, SIP HyperNetwork SLA and E911/BYOB addendum separately. Do not transfer HyperNetwork routing or SLA terms to base SIP service, and do not infer account entitlement from a public PDF. Preserve the signed service schedule, eligible port, opened ticket, provider determination and any credit independently from call-path evidence.
Bind emergency routing to the actual number and address
The implementation guide describes 933 address readback and identity mapping by number, proxy or fixed public address. The current E911 addendum states that the outbound caller ID must be the specific ten-digit DID associated with E911 service and that changed, added or ported numbers need the correct address registered. An incorrect number or physical address can produce the wrong emergency destination.
Preserve the eligible DID, approved civic address, service model, outbound identity, callback path and current provider test procedure for every site. A 933 readback is not a live 911, dispatch, callback or notification test. Do not place an uncoordinated emergency call, and keep an independently tested alternative calling method.
Bound media, capacity and product claims
The guide lists G.711u, G.729a and RFC 2833 telephone-event payload 101, documents G.711u pass-through and T.38 fax, and calls fax over IP best effort. Its bandwidth figures are planning inputs, not measurements. It does not establish customer-facing TLS, SRTP or a downgrade policy for this service. Capture actual SDP, RTP, digit events and fax transitions on authorized representative calls.
The guide's unlimited-call-path language sits beside use restrictions and PBX-side maximum guidance; it is not infinite technical capacity. Base SIP, mSIP, SIP HyperNetwork and Flowroute remain separate products or service layers. Obtain dated account terms for capacity, locations, numbers, pricing, SLA, support and messaging. No account, route, recovery event, SLA event, media path 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.
- BCM One SIP Trunking and Implementation Guide, September 2024 ↗
- BCM One customer portals ↗
- BCM One legal and service documents ↗
- BCM One SIP Service Level Agreement ↗
- BCM One SIP Service E-911 and Service Addendum ↗
- BCM One SIP HyperNetwork Service Level Agreement ↗
- BCM One: SIP Trunking vs mSIP ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.