Status er kontrolleret mod projektkilderne den 29. september 2026. Udviklingskode, beståede softwaretests og pilot-/produktionsklarhed vurderes hver for sig. De aktuelle GitHub-kandidater er åbne kladder; hjemmesidens offentliggørelse er ikke en softwarefrigivelse.
Qualification v2, evidensbinding og rollback-kontroller er implementeret i udviklingsgrenen.
Eksekveret CI, operatørtest, rettigheder, signering og releasegodkendelse.
Den aktuelle CI-status indeholder ikke eksekverede jobtrin. Den kan derfor ikke bruges som bevis for, at programtests er kørt og fejlet.
Den foreslåede konstruktion af Call Guard: datamodel, opkaldsflow, policy-motor, integration, sikkerhed, drift og test.
Produkt- og udviklingsoplæg · September 2026 · Ikke dokumentation for en færdig implementering
En lokal tjeneste modtager et normaliseret beslutningsinput fra operatørens betroede SIP-proxy eller SBC. Den bruger et versionsbundet snapshot af nummerrettigheder og policies. Den kritiske vej skal kunne fungere uden et synkront kald til den centrale cloud.
Administrerer kunder, rettigheder, delegationer, policyversioner og roller. Signerede konfigurationspakker distribueres til de lokale motorer, som validerer og aktiverer dem atomisk. Hændelser sendes asynkront til analyse og rapportering.
| Komponent | Foreslået konstruktion | Hvorfor |
|---|---|---|
| Beslutningstjeneste | Go med lokal, skrivebeskyttet snapshot-cache | Begrænset afhængighed i opkaldsvejen og enkel distribution. |
| Administrations-API | Go REST API med OpenAPI-kontrakt | Valideret input, versionsstyring og integration til operatørens systemer. |
| Rettighedsregister | PostgreSQL med tenant-nøgler, constraints og migrationsstyring | Transaktioner og sporbare rettighedsændringer. |
| Operatørportal | TypeScript/React med rollebaseret adgang | Gennemgang af regler, undtagelser og beslutninger. |
| Hændelseskø | Lokal holdbar buffer; central kø vælges efter målt behov | Rapportering må ikke blokere opkald ved cloududfald. |
| Observability | OpenTelemetry-signaler og Prometheus-kompatible målinger | Latens, kødybde, fejl og snapshot-alder skal kunne overvåges. |
En separat grafdatabase er ikke et krav til første version. Autorisationsgrafen kan modelleres som relationer i PostgreSQL; mere kompleks grafanalyse tilføjes kun ved et dokumenteret behov.
| Entitet | Centrale felter | Kontrol |
|---|---|---|
| Tenant | tenant_id, status, policy_scope | Entydig adskillelse mellem operatørens kunder. |
| Trunk | trunk_id, tenant_id, trusted_ingress, status | Bindes til autentificeret kontekst fra betroet integration. |
| NumberRight | number/range, holder, valid_from, valid_to, source_ref | Retten skal være dokumenteret, aktuel og uden uafklarede overlap. |
| Delegation | grantor, grantee, numbers, routes, expiry, approval | Delegation må ikke overstige afgiverens egen rettighed. |
| PolicyVersion | version, rules, priority, hash, signature | Gennemgang, integritetskontrol og atomisk aktivering. |
| Decision / Enforcement | decision_id, rule_id, snapshot_id, desired_action, actual_action | Skelner motorens anbefaling fra den faktisk udførte handling. |
Numre normaliseres efter aftalt nummerplan. Originalt input bevares kun, hvor nødvendigt for fejlfinding og dokumentation. Skjult nummer, servicekoder, viderestilling og internationale formater kræver eksplicit behandling; de må ikke blot afvises som ukendte E.164-numre.
POST /v1/decisions
// Autentificeret lokal integration; alle værdier er syntetiske.
{
"request_id": "example-001",
"tenant_id": "tenant-demo",
"trunk_id": "trunk-demo",
"direction": "outbound",
"presented_cli": "<normaliseret nummer>",
"route_id": "egress-demo"
}
{
"decision_id": "decision-demo",
"action": "REJECT",
"reason_code": "CLI_NOT_AUTHORIZED",
"rule_id": "outbound-cli-001",
"policy_version": "example-v1",
"rights_snapshot": "example-r1",
"enforcement_status": "PENDING"
}Den endelige kontrakt skal også definere timeout, fejl, idempotens, datakvalitet og kompatibilitet. Eksemplet er ikke et tilgængeligt API.
Første motor er deterministisk: samme input og snapshot skal give samme resultat. Adfærdsmodeller må tilføje signaler uden at skjule, hvilke regler der udløste handlingen.
| Situation | Foreslået behandling |
|---|---|
| Gyldig rettighed og ingen regelkonflikt | ALLOW efter operatørens policy; dette siger intet sikkert om hensigten. |
| Dokumenteret manglende rettighed | OBSERVE i pilot; REJECT efter godkendt håndhævelse. |
| Manglende eller forældede rettighedsdata | Eksplicit datakvalitetsstatus og aftalt fallback, ikke automatisk fraud-stempel. |
| Gyldig identitet, men adfærdsafvigelse | Alarm og eventuelt understøttet rate limit efter validering. |
| Indgående eget nummer via ekstern rute | Observation og kontrol af legitime undtagelser, fx viderestilling og alternative ruter. |
Første connector bygges til én valgt SIP-proxy/SBC eller PBX. Et synkront hook i kaldopsætningen skal kunne afvente beslutningen inden for et aftalt tidsbudget. Et hændelsesfeed alene er ikke tilstrækkeligt til at bevise blokering før opkaldsetablering.
CHALLENGE og QUARANTINE er integrationsafhængige arbejdsgange, ikke universelle SIP-handlinger. Første version bør kun tilbyde verificerede handlinger. Nødopkald, viderestilling, roaming-lignende ruter og driftsundtagelser skal gennemgås særskilt med operatøren.
Log regel, inputkilder, versioner, tidspunkt og udført handling. Begræns rå signaleringsdata, og beskyt nødvendige identifikatorer med kryptering, adgangsstyring og passende pseudonymisering. En hash af et telefonnummer alene er ikke anonymisering.
Manipulationsspor kan bygges med hashkæder og signerede checkpoints med separat beskyttelse. Det kan gøre ændringer sporbare, men er ikke i sig selv en garanti for korrekt evidens. Opbevaringsperioder, eksport, sletning og databehandlerforhold skal aftales før persondata behandles.
Afgræns én integration, normaliseret input og understøttede handlinger. Etablér syntetiske SIP-testkald i et isoleret miljø. Godkend nummerplan og undtagelser.
Byg migrationsstyret register, delegationskontrol, snapshots og deterministiske regler. Test gyldige, udløbne, tilbagekaldte og overlappende rettigheder samt kryds-tenant-forsøg.
Test ALLOW/OBSERVE/REJECT, timeouts, retransmissioner, dubletter og manglende kvitteringer. Dokumentér med kontrollerede SIP-spor, at afvisning faktisk sker ved det aftalte punkt.
Mål p50/p95/p99-latens, maksimal bæredygtig kaldhastighed, CPU og hukommelse. Test cloududfald, nodefejl, forældet snapshot, køpres og restore. Gennemgå afhængigheder, SBOM, licenser og adgangskontrol.
Start i observation. Lad operatøren efterprøve alarmer, legitim trafik og falske positiver. Aktivér på en afgrænset trafikgruppe med dokumenteret rollback og godkendte grænseværdier.
Prioritér adfærdsbaseline, gennemgang af delegationer, flere connectors og eksterne identitetssignaler efter pilotens fund. Maskinlæring, central grafanalyse og avancerede workflows skal have en målt gevinst, før de øger systemets kompleksitet.
Det næste konkrete skridt er en gennemgang af jeres SIP-miljø, nummerregister, driftskrav og kriterier for en vellykket pilot.
Kontakt om teknikken ↗