Use Cloudli as the current provider identity
Cloudli’s first-party rebrand notice says the company formerly known as babyTEL adopted the Cloudli identity in January 2021. Current product and support pages use Cloudli, while some configuration-guide links, addresses or screenshots may still contain babyTEL names. Preserve both strings when correlating a legacy order or trace, but do not create two providers from one lineage.
A babyTEL label in an old guide, credential realm, invoice or PBX object can be relevant historical evidence. It does not establish that an old hostname, address, plan, price or device combination remains current.
Documented service facts
Reviewed 2026-10-25. Compare SIP trunk services →
SIP authentication
DocumentedThe current portal exposes distinct User ID, Authentication ID, SIP password, proxy and port fields. The selected account and downloaded guideline govern; legacy babyTEL examples are not current credentials.
SIP registration
DocumentedCloudli directs customers to Device Configuration → SIP parameters and publishes firewall guidance about stable NAT mappings across REGISTER messages. Registration, inbound routing, answer and media remain different states.
Inbound delivery and identity
Not verifiedCurrent product material describes retaining or selecting numbers, while continuity can be set per independently routed number. Number assignment, port completion, provider attempt, delivered identity, edge receipt and PBX route remain separate.
Forwarding and continuity
DocumentedCloudli documents Settings → Service Continuity with a backup destination and per-number handling, and describes IP-enabled failover strategies. Trigger, scope, provider attempt, forwarded result and restoration remain unverified until observed.
Number and regional availability
Not verifiedThe product page describes numbers across the U.S. and Canada, but it does not establish serviceability, inventory, portability, lead time or regulatory eligibility for a requested address and block. Retain dated qualification and port results.
Codecs, DTMF and RTP
Not verifiedThe reviewed current account and support records do not establish the selected codec set, DTMF method, packetization, RTP range or transcoding for one order. Preserve both SDP bodies and decoded media rather than inheriting a legacy guide.
Fax
DocumentedCloudli publishes separate T.38 fax services, but voice-trunk registration does not prove fax entitlement, negotiation, fallback or completed pages for the selected account.
Signaling and media protection
Not verifiedThe reviewed records do not prove selected TLS identity, mutual authentication, SRTP profile, encryption across intermediary legs or current peer ranges for one account. Portal parameters and observed negotiation govern.
Concurrent calls and call starts
DocumentedCloudli exposes plan capacity in the portal, and its terms state simultaneous calls equal subscribed lines. Call starts, bursts, PBX channels, codec bandwidth, billing effective time and observed acceptance remain separate quantities.
911
DocumentedCloudli says the calling number and registered address are sent to a specialized emergency call-answer centre and records Internet, power and location dependencies. Current address, effective update, identity, routing, callback and provider-approved testing remain unverified.
Pricing and contract
Not verifiedNo current selected-account price was established. Bind plan, capacity, numbers, usage, continuity, fax, taxes, regulatory charges, term, renewal and termination to the dated order, contract and bill.
Portal, guides and support
DocumentedCloudli publishes portal instructions, a SIP-trunk support section and configuration guides including Asterisk and several appliances. A guide listing is not current compatibility proof for an installed release, custom module or topology.
SMS and MMS
Not verifiedThe reviewed SIP-trunk records do not establish messaging entitlement on trunk numbers, sender registration, API access, throughput, webhook security, retention or price. Treat messaging as a separate ordered service.
Take registration parameters from the selected portal account
Cloudli’s registration article directs customers to Device Configuration → SIP parameters for User ID, Authentication ID, SIP password, proxy and port, and to Device Configuration → Guidelines for the account’s guide. Keep the user identity, authentication identity, secret, proxy, port, transport and PBX object separate.
Do not transcribe credentials or example infrastructure from an archived babyTEL PDF into production. Compare the current portal record with the loaded PBX configuration, redact secrets from evidence, and change only the first demonstrated mismatch.
Prove NAT and firewall behavior independently
Cloudli’s firewall guidance says a SIP device or IP-PBX may be public or behind a firewall and explains that inconsistent NAT can change the remapped source port between REGISTER messages, making inbound delivery unpredictable. That is a behavior to verify, not a reason to expose a PBX broadly.
Record the local and translated tuple, REGISTER and response sequence, expiry, Contact and received/rport behavior, keepalive cadence, SIP ALG state and the provider’s current peer evidence. A registered state does not prove inbound routing, answer or two-way media.
Keep plan capacity separate from call throughput
Cloudli’s support article exposes plan capacity as an account control, and its terms state that simultaneous calls for a SIP Trunking plan equal the subscribed lines. The product page separately presents scalability. Preserve subscribed capacity, active dialogs, offered attempts, call starts, PBX channels, codec bandwidth and rejected responses as different quantities.
A portal capacity change does not prove immediate billing state, call-per-second limits, burst handling, PBX resources or successful calls. Bind any operational or commercial conclusion to the selected account, effective time, order and observed traffic.
Separate service continuity from PBX routing
Cloudli’s support article places outage forwarding under Settings → Service Continuity, with a destination number and per-number handling when numbers are independently routed. The current product page also describes IP-enabled failover strategies. Provider continuity, a DID route, PBX failover, carrier selection and endpoint forwarding remain separate controls.
Record the affected number, saved destination, enabled state, trigger, provider attempt, PBX reachability, forwarded leg and restoration owner. An alternate destination answering does not prove why the primary failed or that normal delivery has recovered.
Keep fax and 911 acceptance independent
Cloudli publishes separate T.38 fax services and 911 information. Its 911 page says the telephone number and registered address are sent to a specialized emergency call-answer centre; its terms also record power, Internet and location dependencies. These records do not prove a selected trunk, PBX identity or current registered location.
Test fax only with authorized endpoints and preserve negotiation, fallback and completed pages. Do not place an uncoordinated 911 call. Keep registered address, effective update, outbound identity, callback, PBX route, power and Internet continuity, and an alternate calling method in a provider-approved acceptance record.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Cloudli SIP Trunking ↗
- babyTEL rebrands as Cloudli Communications ↗
- Cloudli Support — How do I get my IP-PBX or SIP device registered? ↗
- Cloudli Support — SIP Trunking Configuration Guides ↗
- Cloudli Support — Firewall Considerations ↗
- Cloudli Support — Set up a backup number for an outage ↗
- Cloudli Support — How to change SIP Trunking plan capacity ↗
- Cloudli 911 Service Information ↗
- Cloudli Terms of Service ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.