Freeze one attempt and name the service lineage
Record UTC and local time, account and plan without secrets, the current Cloudli portal object, any legacy babyTEL label, called and calling identities, expected registration, continuity rule, edge, PBX route, answer and media result. Redact credentials and personal data.
Classify the first unexpected state: identity was copied from a legacy record; portal parameters and loaded PBX differ; registration or NAT state is unstable; continuity selected another destination; the expected edge did not receive the INVITE; the PBX chose another route; or signaling completed without usable media.
Compare current portal parameters with the loaded PBX
Use Device Configuration → SIP parameters for the current User ID, Authentication ID, SIP password, proxy and port, and obtain the account’s current guideline. Compare those fields with the effective PBX object rather than a draft screen or an old babyTEL PDF. Never copy the secret into a ticket or packet annotation.
Preserve REGISTER, challenge and final response; Request-URI, From, To, Contact, Via and Call-ID; expiry and retry timing; and the selected transport. A 200 response proves only that transaction, not inbound routing or media.
Demonstrate the NAT or firewall divergence
Cloudli warns that inconsistent NAT can change the remapped source port between REGISTER messages. Correlate consecutive transactions at the PBX, firewall and authorized provider edge. Record local, translated and remote tuples, received/rport, Contact rewriting, keepalive interval, UDP timeout and SIP ALG state.
Correct only the demonstrated owner. Do not open broad signaling or media ranges merely because a legacy guide lists them, and do not assume a public PBX, static mapping or ALG policy without the selected network record.
Separate capacity, reachability and inbound selection
Confirm subscribed capacity and active calls, but keep those facts separate from registration, provider reachability and number routing. For the affected number, align the provider attempt with the same time window as edge evidence. If no matching request reaches the authorized edge, keep PBX dialplan changes out of the incident.
If the request reaches the edge, preserve the delivered number and identity headers, response sequence and SDP. A busy response, capacity rejection, authentication failure and missing provider attempt require different owners and corrections.
Prove service-continuity scope before changing the PBX
Cloudli documents Settings → Service Continuity and per-number handling when numbers are independently routed. Record the exact number, destination, enabled state, save time, trigger and forwarded result. Distinguish that control from a PBX route, endpoint forward, carrier failover and manual diversion.
When normal delivery should resume, verify that the continuity state is restored and that the provider again attempts the expected edge. An answered backup leg is evidence of that leg only.
Retest signaling and media, then keep 911 separate
After an authorized correction, retest the affected ordinary number and one unaffected control. Preserve registration stability, provider attempt, edge receipt, loaded PBX route, answer, negotiated SDP, RTP tuples and each audio direction. If fax is affected, record T.38 or audio fallback and completed pages separately.
Do not place an uncoordinated emergency call. Confirm the current registered address, effective update, outbound identity, callback and alternate method through Cloudli’s approved process. No Cloudli or babyTEL account, parameter, trunk, packet, call, media, continuity or 911 result was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- babyTEL rebrands as Cloudli Communications ↗
- Cloudli Support — How do I get my IP-PBX or SIP device registered? ↗
- Cloudli Support — Firewall Considerations ↗
- Cloudli Support — Set up a backup number for an outage ↗
- Cloudli 911 Service Information ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.