Customer Deep Dives

Four customers, four trunk topologies

Every customer SIP integration is a variation on the same three knobs: where the carrier sits (public internet, on-net via firewall, MPLS, or single-host public IP), how authentication works (IP allowlist or registered credentials), and which transport actually carries the signaling (UDP vs TCP — the most common silent failure). The table below is the cheat sheet. Click any row to jump to that customer's deep dive.

Allianz — Connecta SIP Trunk (cloud-hosted)

The simplest topology in the lineup. Allianz's CRM owns campaign creation; Freya is the voice runtime; Connecta is the Turkish telecom partner that hands us a SIP trunk over the public internet. There is no VPN, no SBC, no MPLS — just an IP-allowlisted trunk to a Connecta-side gateway at 31.155.2.249.

Topology

Things you must remember

• Connecta is a trunk, not a PBX. Allianz's CRM still owns campaign creation, destination lists, and outcome write-back. Freya is just the voice runtime sitting between the trunk and the AI agent.
• Public-internet trunk = strict ACL. Only Connecta's 31.155.2.249 may reach our 5060. Lock the firewall by source IP and use the matching identify block in pjsip.conf so unsolicited INVITEs are dropped.
• The 9015 prefix. Outbound dialed numbers go out as e.g. 9015-0532-1234567. The dialplan needs a rewrite rule to insert/strip the prefix or Connecta will route the call to the wrong destination.
• DID choice has product implications. If Allianz picks the 444 number, callbacks land in their existing call center. If they pick a fresh 0216 number, callbacks come back to Freya. This is a business decision being made on their side.

$ # The KKB pjsip.conf has the same shape Allianz will use. Inspect:
$ ssh freya@192.168.35.197 "docker exec freya-asterisk asterisk -rx 'pjsip show endpoints'"
$ # Find the [providers] endpoint - that's the trunk. Note the identify match line.
$ # When Allianz signs, we'll add a near-identical block pinned to 31.155.2.249.

Reference: notes/customers/allianz/2026-03-31-1017-allianz-connecta-sip-trunk-notes.md

Garanti BBVA — Cisco UCCE + KASP Light Proxy

Garanti is the most enterprise-flavoured topology in the set. The customer telephony stack is Cisco UCCE with a VVB (Virtual Voice Browser) sitting between the call center and the SIP world, and a KASP (Kamailio-based) SIP proxy in light/stateless mode in front of it. Freya's Asterisk pod is on the Garanti OpenShift cluster, on the same routed network. Splunk gives the customer full packet visibility.

Topology — and the M08 lesson visualized

The Garanti M08 story (read it once, remember it forever)

• Symptom. Every call dropped at exactly 60 seconds.
• Six hypotheses tested. Firewall ACL gap, NAT/address rewrite missing, stateless proxy bypassing ACK, codec/transport mismatch, identify match miss, header parse failure.
• Root cause. KASP light mode does not insert Record-Route. ACK and BYE bypass the proxy and go direct VVB↔Asterisk. Customer firewall opened 5060 only on the proxy path. ACK never arrived. rtptimeout=60 did its job.
• Fix. Open UDP 5060 directly between VVB and Asterisk in addition to the proxy path.

Garanti-tuned PJSIP knobs

$ # See the same knobs on KKB endpoints (default values, since KKB has no proxy):
$ ssh freya@192.168.35.197 "docker exec freya-asterisk asterisk -rx 'pjsip show endpoint providers'" \
    | grep -E 'force_rport|rewrite_contact|rtp_timeout'

Reference: freya-onprem/openshift/garanti/, freya-onprem/playbooks/sip-asterisk-debug.md

Anadolu Sigorta — Genesys SBC + MPLS

The customer telephony stack here is Genesys (call center + SBC, on Cisco UCCE Appliance OS variant). Freya's Asterisk sits at 10.31.39.14; the Genesys SBC is at 10.1.137.60/61 (two interfaces on one device) plus four Genesys generic /32s. The path between them is an MPLS circuit, which means firewall-transparent at the port level — the customer firewall does not enforce TCP/UDP rules on this path. ACLs only live on the network gear.

Topology

Two traps you must remember

$ # The "always confirm transport" check:
$ ssh freya@192.168.35.197 "sudo tcpdump -i any -nn -v 'tcp port 5060 or udp port 5060'" 2>&1 | head -30

Reference: notes/customers/anadolu-sigorta/on-prem-blueprint.md, 2026-04-03-1404-anadolu-sigorta-sip-debug-notes.md

KKB / Kloudeks — Verimor Trunk

This is the box you have an SSH key to: kkbfcfreyasrv01 (192.168.35.197 internal, 185.199.89.19 public). Single-host Docker Compose deployment, 4× H100 NVL, Gemma LLM. The trunk is Verimor, a Turkish wholesale PSTN carrier, reached over the public internet at 194.49.126.26. Outbound caller-ID is 908502427127.

Topology

The 2026-04-24 outbound concurrency tests

Three burst campaigns at 16:31, 18:26, and 20:38 UTC. The Freya stack itself was healthy throughout — voice agents, dashboard, campaign worker, Asterisk all green. The failures originate at the carrier (Verimor), plus a number-format bug that broke the first burst entirely.

What 2026-04-24 told us

• Not a Freya-side network problem. Voice agents (30 containers), dashboard, campaign worker, Asterisk — all healthy. Pre-dial path completed successfully on every attempt, including the failed ones.
• Same five destinations rejected across all three campaigns. +905374705251, +905510154221, +905532890209, +905053864612, +905535918355 all returned SIP 603 / Q.850 cause 41 in every test. Stable carrier-side block, not transient congestion.
• Number-format bug in the 16:31 campaign. Every destination dialed with a stray 94350 prefix instead of +90. Result: zero connections.
• One transient 408 on +905537721287 at 20:38. Same number connected fine at 18:26, so it was a handset/PSTN issue, not a trunk issue.

Open work items at KKB

1. Open a Verimor ticket with the five blocked numbers and ask about per-caller-ID concurrency caps.
2. Find and fix the source of the 94350 prefix (campaign upload path or dialplan rewrite).
3. Throttle outbound dialing on the campaign worker (e.g. 2 calls/sec/caller-ID).
4. Surface SIP response codes + Q.850 cause in the dashboard so future triage doesn't need shell access.

Full report: notes/customers/kloudeks-kkb/reports/kkb-outbound-concurrency-2026-04-24/