Freeze one failed connection and its exact owner
Record timestamp and timezone, trunk name and region, customer endpoint FQDN and port, LoopUp regional target, resolver answers, protocol, local and peer addresses, SBC and version, TLS profile, certificate identifiers, handshake alert or timeout, SIP transaction, SDP, media direction and whether failure began after a certificate, DNS, clock, firewall or software change.
Distinguish no TCP connection, failed TLS handshake, successful TLS with failed SIP, answered SIP with failed secure-media negotiation, and negotiated SRTP with missing or undecodable packets. They require different evidence.
Prove the regional FQDN, port and network path
LoopUp publishes regional FQDNs, recommends DNS because addresses can change, and uses 5061 for TLS. Confirm the trunk region, current DNS answers, selected address, route, source address, firewall state and TCP connection for the same attempt.
Do not pin an old published IP as a repair or open broad Internet access. A successful DNS lookup does not prove the application used that answer, and a completed TCP handshake does not prove TLS identity or SIP acceptance.
Separate the customer certificate from LoopUp trust
The encrypted SBC guides require a customer certificate rooted in LoopUp's supported CA list and also import LoopUp's public intermediate and root into the customer trust store. Inventory both directions: customer leaf, intermediates and key presented to LoopUp; LoopUp chain and roots trusted by the customer.
Check exact FQDN coverage, issuer chain, validity window, local clock, intended key, enabled profile and complete presented chain. Do not replace every certificate when only one direction or one missing intermediate is demonstrated.
Correlate the mutual-TLS handshake before SIP
LoopUp's current AudioCodes example enables mutual authentication and uses TLS 1.2; RFC 5246 separates certificate exchange, key agreement and the finished handshake. Preserve both peer identities, negotiated protocol and cipher, validation result and any fatal alert.
A certificate that appears in a management screen is not proof that the listening interface or proxy set selected it. Likewise, a successful TLS session does not prove that the next SIP request has an accepted route, identity or number.
Inspect SIP and SDP after transport succeeds
Once TLS is established, retain the complete authorized SIP request and response. Compare From, Request-URI, P-Asserted-Identity, route, Contact and the SDP offer and answer. LoopUp publishes two SRTP cipher suites; RFC 4568 requires the actual security descriptions and keys to be interpreted within the negotiated SDP.
Do not infer SRTP from port 5061, TLS from an SDP attribute, or usable media from an answered INVITE. Correct the earliest signaling or offer-answer mismatch.
Prove packets, decode and rollback independently
For an authorized non-emergency call, preserve both media addresses, ports, SSRCs, packet directions, negotiated protection, authentication failures and decoded audio at each permitted capture point. A packet counter without successful authentication and playout is not proof of usable speech.
Rehearse certificate renewal before expiry with a rollback copy, trust-store owner and bounded test. After a change, repeat DNS, TCP, mutual TLS, SIP, SDP, SRTP and two-way audio evidence separately. No LoopUp trunk, certificate, key, packet or call was tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- LoopUp SIP Trunking Setup Guide ↗
- LoopUp SIP Trunking Public Certificate Chain ↗
- LoopUp SIP Trunking Supported Root Certificate Authorities ↗
- LoopUp SIP Trunking Configuration for AudioCodes Mediant SBCs ↗
- LoopUp SIP Trunking Configuration for Ribbon 1000, 2000, and SWe Edge SBCs ↗
- RFC 5246: TLS 1.2 ↗
- RFC 4568: SDP Security Descriptions for Media Streams ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.