SIP / Telephony Engineer Carrier Behavior Feasibility Testing

What this job is We're building a call-routing service and we need to know whether the core mechanism actually works on live US carrier networks before we commit to a full build. We are hiring you to test it and tell us the truth. This is a research and validation engagement. We are not asking you to build the product. We want test calls, SIP traces, and a clear written answer to a specific list of questions including, potentially, "this won't work, here's why, here's what I'd do instead." A clear negative finding is a successful outcome and will be paid in full. We've already spent money building something that turned out not to be viable. We're trying not to repeat that. The architecture we need validated At a high level: 1. An end user enables **unconditional call forwarding** on their existing phone line (mobile or landline) pointing at a DID we control. Nothing is installed on their device. Their number does not change. 2. All inbound calls to that user now arrive at our platform first. 3. We make a routing decision in under 500ms based on the calling number. 4. We then **place an outbound call back to that same end-user number** to connect the call, **passing the original caller's number through as the caller ID**. 5. Both legs are bridged. We track call metadata (calling number, duration) only. **No audio is recorded, analyzed, or transcribed at any point.** 6. On certain metadata conditions, we send SMS notifications and may bridge an additional third party into the live, in-progress call. We currently use Twilio Programmable Voice for an unrelated existing service. We're evaluating whether to stay on Twilio, move to Twilio Elastic SIP Trunking, move to Telnyx, or use something else entirely. ## The core problem **The end user's number has unconditional forwarding pointed at us. When we dial that same number back to connect the call, a naive carrier will forward it right back to us. Infinite loop. Call fails.** The standard mitigation is a **SIP Diversion header** (RFC 5806) or History-Info (RFC 7044) signaling that the call was already diverted from that number, so the terminating carrier should deliver to the handset rather than re-forwarding. This is long-standing behavior for voicemail platforms. **We do not know whether US consumer carriers honor this in our specific scenario.** We've researched it extensively. Prior art exists for enterprise PBX-to-SIP-trunk setups under negotiated commercial agreements, but nothing we can find covers a retail consumer mobile line with `*72`-style forwarding, dialed back from a CPaaS platform. Documentation doesn't answer it. Only test calls do. **This is the single highest-priority item in this engagement. Everything else is contingent on it.** --- ## What we've already established (so you don't repeat it) **Twilio Programmable Voice cannot set a Diversion header on a PSTN leg.** Their docs state custom headers apply only to Programmable Voice SIP calls, only with an X-prefix, and BYOC trunk headers are discarded. If a Diversion header is required, Programmable Voice is out. - **Twilio Elastic SIP Trunking** adds a Diversion header on inbound noting the Twilio number dialed, and forwards Diversion headers received from our infrastructure to carriers. Requires our own SIP endpoint. - **Telnyx documents a feature called "External Call Transfers"** for an inbound PSTN call arriving at a SIP endpoint and being transferred to an outside number while preserving the original caller as originator. Their validation requires an active inbound call match plus a Diversion header referencing the Telnyx number in a format rejecting with `403 Unverified origination number D51` otherwise. **Open question: our transfer destination *is* the number that forwarded to us. Does that pass their validation? Can we stack two Diversion headers — one for their validation, one referencing the end user's number so their carrier suppresses re-forwarding?** - **On SIP 302 redirect:** our research suggests a 302 does not reduce billing, because carrier SBCs are B2BUAs that terminate the dialog and re-originate on our account. Twilio's docs state they honor the first URI of a 302 but that the redirected call uses the same interconnect connection. We'd like this confirmed or refuted, but note a 302 **does not solve the loop** — a 302 to the end user's number gets re-forwarded the same way. --- ## What we need tested Please test on, at minimum: **Verizon, AT&T, T-Mobile, one Verizon-based MVNO, one prepaid carrier, and one traditional POTS landline.** We expect behavior to vary and need that variation documented per carrier. ### 1. The forwarding loop — highest priority Simplest form, requires no SIP infrastructure: enable unconditional forwarding on a test number pointing at a CPaaS DID; configure that DID to dial the same number back out; call the test number from a third phone. Does the handset ring, or does it loop and fail? If it loops: repeat with a Diversion header on the outbound leg. Does it ring now? Test both single and stacked Diversion headers. Document exactly which header configuration works, per carrier. ### 2. Caller ID passthrough and spam labeling We re-originate with the original caller's number. Does it arrive intact? What STIR/SHAKEN attestation level is applied? Do these calls get labeled "Spam Likely" on the terminating handset? Test across all major terminating carriers. If passthrough proves unreliable, our fallback is ringing from a consistent per-customer local DID with recognizable CNAM. Please assess whether that's necessary and how much worse the experience is. ### 3. Post-dial delay How much later does the handset ring versus no forwarding? **Target is under 2 seconds.** Beyond that, callers hang up before the person answers — a failure that's invisible to us and infuriating to the end user. ### 4. Voicemail behavior We believe unconditional forwarding bypasses carrier voicemail entirely, since calls never reach the line. If so, when we dial and nobody answers, nothing catches the call and the caller can't leave a message — a serious functional regression. Per carrier: with unconditional forwarding active, does carrier voicemail still trigger on a no-answer of the leg we originate? Or must we build and host voicemail ourselves? We're fine building it, we just need to know before we build. ### 5. Subscriber identification When a forwarded call arrives, we must know which subscriber it belongs to. Two options: **shared DID** (read the inbound Diversion header added by the forwarding carrier — cheaper, but depends on every carrier populating and preserving it) or **per-customer DID** (the `To:` number identifies deterministically — reliable, but ~$0.50–1.15/mo per subscriber). Does the inbound Diversion header survive, per carrier? If patchy, is per-customer DID the only robust approach, or is a hybrid viable? ### 6. Fail-open behavior — critical requirement **If our application is down, slow, or errors, the call must still reach the handset.** A service outage on our side must be indistinguishable from our service not existing. It must never mean the end user's phone stops ringing. Can the platform be configured with an automatic fallback route to a PSTN number when our webhook times out or errors? What's the timeout window, and is it configurable? Telnyx documentation references inbound fallbacks does that satisfy this, or must we build it ourselves in a SIP proxy? 7. Bridging a third party into a live call Can an additional party be added to an already-connected PSTN-to-PSTN call without dropping or disturbing it? Or does that require every call to be a conference from the start (which would add per-participant cost and latency to every call, not just the rare ones that escalate)? Telnyx published a "supervising leg" feature (March 2025) that appears to allow adding a leg to an existing call without conferencing. **Does it support full two-way audio, or listen-only? What's the actual billing treatment?** 8. Measured cost per bridged minute Real billed cost, both legs, per route and per platform — **actual invoice data, not published rate-card figures.** Also: are we billed for ringing time on an unanswered outbound leg? Carrier compatibility matrix Per carrier, document: exact forwarding activation/deactivation codes, whether forwarded calls consume the subscriber's plan minutes, whether the carrier charges a monthly fee for the call forwarding feature, and any carrier that doesn't support unconditional forwarding at all. Context: Verizon's documentation states that without unlimited minutes, subscribers are billed for all forwarded calls as if answered. Many of our end users will be on limited-minute plans. Traditional landline carriers often charge monthly for call forwarding as a feature. We need this verified so we can disclose it accurately at signup. Deliverables 1. A written report answering every question above explicitly, with evidence — SIP traces, call logs, screenshots, or billing records where applicable. 2. A carrier compatibility matrix — per carrier: loop behavior, working header configuration, caller ID result, post-dial delay, voicemail behavior, Diversion survival, forwarding codes, subscriber cost implications. 3. A platform recommendation with reasoning: Twilio Programmable Voice, Twilio Elastic SIP, Telnyx, or something else. 4. A clear answer on infrastructure: does this architecture require us to run our own SIP proxy (Kamailio/FreeSWITCH), or can it be done entirely through a Call Control style API? This materially affects our hiring and operations plan. If a proxy is required, what does it realistically take for a small team to operate one in production with an uptime obligation? 5. A go / no-go on the architecture as designed and if no-go, what you'd do instead. What we provide - Funding for trial accounts, DIDs, minutes, and any paid lookups - We will get Sim cards and help test with you - Access to our existing Twilio account if useful - Direct access to us for questions, with fast turnaround on anything blocking Who we're looking for You have hands-on experience with SIP trunking, PSTN interconnects, and at least one CPaaS platform (Twilio, Telnyx, Bandwidth, SignalWire). You've debugged real SIP traces. You understand Diversion/History-Info headers, STIR/SHAKEN attestation, and how US carriers actually handle call forwarding in practice not just in theory. **Application developers whose only telephony experience is calling Twilio's REST API are not a fit for this engagement.** We need someone who has been inside the signaling. Bonus if you've worked on anything involving call screening, call forwarding services, IVR at scale, or carrier interconnect debugging. To apply Please tell us: 1. **Have you dealt with call-forwarding loops before?** What happened and how did you resolve it? 2. **Your read on the core question** — do you expect US consumer carriers to honor a Diversion header in this scenario? What's your prior? 3. A brief example of SIP-level debugging you've done (no confidential details needed). 4. Your proposed approach and timeline. Please skip generic proposals. If you've read this far and have an opinion on question 2, lead with that.