[Communication] Mehrere Plugins an einem Trunk: eingehende Anrufe zuordnen und Kapazität teilen

[BechsteinDigital]

Worum es geht

Mehrere Plugins sollen sich einen Trunk teilen. Ein Contact Center betreibt einen Outbound-Dialer und
eine Support-Hotline, dazu vielleicht Telefon-Einwahl in Konferenzen und ein Softphone im Browser —
alle über dieselbe SIP-Registrierung, weil ein Trunk mit Rufnummernblock der Normalfall ist und nicht
die Ausnahme.

Die Fähigkeiten dafür sind da: ICommunicationChannelRegistry ist workspace-scoped, jedes Plugin kommt
an die Channels, hängt sich an IncomingCall und kann über PlaceCallAsync selbst wählen. Was fehlt,
sind die zwei Regeln, die aus „alle können alles" ein geordnetes Nebeneinander machen.

Beide gehören hierher, weil kein Plugin sie für sich entscheiden kann: Keines kann festlegen, dass ein
eingehender Anruf ihm gehört, und keines kann sich selbst ein faires Kapazitätsbudget geben.

---

Teil A — Eingehende Anrufe zuordnen

Heute

IncomingCallObserver meldet jeden eingehenden Anruf, und jeder Konsument, der sich an
ICommunicationChannel.IncomingCall gehängt hat, bekommt ihn. Wer zuerst AcceptAsync ruft, gewinnt.
Das ist ein Rennen, kein Routing — und bei zwei Konsumenten im selben Workspace ist es nicht
entscheidbar, wer gewinnen sollte.

Erschwerend: ICall.Target ist der Anrufer. Die gerufene Nummer gibt es im Vertrag nicht. Ein
Plugin könnte also nicht einmal dann korrekt filtern, wenn es wollte.

Was fehlt

Rufnummern am Account. SipAccount trägt heute Id, Workspace, Verbindung,
MaxConcurrentCalls und Enabled — aber keine Rufnummern. Ein Workspace kann gar nicht ausdrücken,
welche DIDs er hat.

Die gerufene Nummer im Vertrag. Auf IncomingCallEventArgs oder ICall, damit überhaupt
entscheidbar ist, wem ein Anruf gilt.

Eine Zuordnung Nummer → Konsument, pro Workspace konfiguriert. Im Kern eine kleine
PBX-Routingtabelle: Diese Durchwahl gehört der Support-Hotline, jene der Konferenz-Einwahl.

Beobachten ist nicht Besitzen

Die wichtigste Unterscheidung, und sie sollte im Vertrag stehen, nicht in einer Konvention:

• Ein Besitzer bekommt die Anrufe seiner Nummern und entscheidet über Annehmen und Abweisen. Genau
  einer pro Nummer.
• Ein Beobachter — Aufzeichnung, Analyse, Wallboard, Compliance — sieht alle Anrufe und
  entscheidet nichts. Beliebig viele.

Heute sind beide dasselbe Event, und deshalb kann ein Beobachter versehentlich einen Anruf annehmen.

Zu entscheiden

• Keine Zuordnung trifft zu. Ablehnen ist ehrlicher als von allen ignorieren zu lassen, und der
  Ablehnungscode sollte derselbe Gedanke sein wie bei IQuiescableChannel: 503 schickt den Carrier
  zur nächsten Route, 486 gibt dem Anrufer ein Besetztzeichen.
• Besitzer ist nicht aktiv (Plugin deaktiviert, im Workspace nicht verfügbar). Nicht stillschweigend
  an den Nächstbesten fallen lassen — das wäre dieselbe Klasse Fehler wie ein Identitätsanbieter, der
  bei Deinstallation auf anonym zurückfällt.
• Zwei Nummern, ein Besitzer muss gehen (eine Hotline mit mehreren Durchwahlen). Umgekehrt nicht.

---

Teil B — Kapazität teilen

Heute

MaxConcurrentCalls steht auf SipAccount, wird beim Anlegen validiert und liegt in der Datenbank —
und wird beim Wählen nirgends geprüft. CallControlService liest es nicht. Gebremst wird heute nur
vom Carrier.

Solange ein Plugin telefoniert, fällt das nicht auf. Sobald mehrere es tun, ist es ein Betriebsunfall
mit Ansage: Ein Outbound-Dialer belegt alle dreißig Leitungen und die Support-Hotline ist
unerreichbar.

Kontingente statt getrennter Accounts

Der naheliegende Reflex — jedes Plugin bekommt seinen eigenen Account — löst es schlechter. Bei einem
Trunk mit Rufnummernblock ist das technisch kaum sinnvoll teilbar, und die Kapazität wird starr
halbiert: Der Dialer bekommt fünfzehn und lässt sie brachliegen, während die Hotline an ihren fünfzehn
ansteht.

Besser ist ein Account mit Kontingenten: „Der Dialer darf höchstens zwanzig der dreißig belegen, zehn
bleiben eingehend reserviert." Getrennte Accounts bleiben richtig, wo der Unterschied wirklich außen
liegt — anderer Carrier, andere Marke, anderer Vertrag.

Zu entscheiden

• Reservieren, nicht zählen. Zwei gleichzeitige Wählversuche dürfen nicht beide gewinnen, weil
  beide vor dem Hochzählen geprüft haben.
• Eingehende Anrufe zählen mit. Sie belegen dieselben Leitungen. Ein Kontingent, das nur Ausgehendes
  begrenzt, schützt die Hotline nicht.
• Verhalten bei Erschöpfung. Ausgehend: benannter Fehler, kein stiller Fehlschlag. Eingehend: 503,
  aus demselben Grund wie oben.
• Reservierung überlebt den Anrufer nicht. Ein Plugin, das abstürzt oder deaktiviert wird, darf
  keine Leitungen dauerhaft binden.

---

Akzeptanzkriterien

Teil A

• Ein Account trägt seine Rufnummern
• Die gerufene Nummer ist bei einem eingehenden Anruf im Vertrag verfügbar
• Eine Nummer hat genau einen Besitzer; die Zuordnung ist pro Workspace konfigurierbar
• Besitzer und Beobachter sind im Vertrag getrennt — ein Beobachter kann keinen Anruf annehmen
• Ein Anruf ohne passende Zuordnung wird definiert abgelehnt, nicht stillschweigend fallengelassen
• Ein inaktiver Besitzer führt nicht dazu, dass ein anderer Konsument den Anruf übernimmt

Teil B

• MaxConcurrentCalls wird beim Wählen durchgesetzt
• Die Prüfung reserviert atomar; zwei gleichzeitige Versuche können das Limit nicht überschreiten
• Eingehende Anrufe zählen auf dasselbe Limit
• Kontingente pro Konsument sind konfigurierbar, mit dem Account-Limit als Obergrenze
• Erschöpfung meldet sich benannt (ausgehend) bzw. mit 503 (eingehend)
• Eine Reservierung wird freigegeben, wenn der haltende Konsument endet oder deaktiviert wird

Referenzen

• custom/static-plugins/Communication/src/Application/Calls/IncomingCallObserver.cs — meldet, entscheidet
  ausdrücklich nicht („that is a consumer plugin's (e.g. a PBX's) decision")
• custom/static-plugins/Communication/src/Domain/Accounts/SipAccount.cs — MaxConcurrentCalls ohne Durchsetzung
• custom/static-plugins/Communication/src/Infrastructure/Sdk/SdkVoiceChannel.cs — 503-statt-486-Begründung
• Künftige Konsumenten: Telefon-Einwahl, Softphone im Surface, Dialer, CRM

[BechsteinDigital]

Ich habe SDK und Plugin durchgesehen, bevor ich anfange. Drei Punkte, die den Zuschnitt ändern.

Rufnummern gibt es bereits

SipAccount trägt heute Id, Workspace, Verbindung, MaxConcurrentCalls und Enabled — aber keine
Rufnummern.

InboundNumbers existiert durchgängig: in der Domäne, in SipAccountConnectionFactory, in der
Admin-API (CreateSipAccountRequest, UpdateSipAccountRequest, SipAccountResponse), mit eigener
Migration AddTrunkInboundFields — und SdkSipAccountFactory reicht sie ans SDK-Konto weiter.

Das erste Akzeptanzkriterium von Teil A ist damit erfüllt.

Die gerufene Nummer entscheidet bereits — sie wird nur nicht gezeigt

Der Befund stimmt: Im Vertrag gibt es sie nicht. Aber sie existiert im SDK und wird dort schon
benutzt. TrunkInboundMatcher.IsForThisLine liest die To-/Request-URI, parst den User-Part als
localUser und entscheidet damit, ob ein INVITE zu dieser Line gehört. Der Wert ist also da, trifft
eine Entscheidung, und wird danach verworfen.

Was fehlt, ist die Durchreichung nach oben — ISipCallSession.LocalUri → SipCoreCallChannel →
ICallChannel → ICall, exakt das Muster, das RemoteAssertedIdentity schon geht. Dazu kommt der
Display-Name des Anrufers, den ExtractUriFromNameAddr zwischen <> wegwirft. Beides gehört in ein
SDK-Issue („Inbound-Identität nur teilweise exponiert").

Neu: Der Domain-Fallback bricht die Mandantentrennung

Das ist der Punkt, der im Issue fehlt und schwerer wiegt als das beschriebene Rennen.

SdkSipAccountFactory setzt AcceptTrunkInbound = true unbedingt, auch für einfache
Register-Konten, und füllt InboundNumbers nur im Trunk-Modus. Für ein reguläres Konto greift damit
Schritt 5 des Matchers: der Domain-Fallback.

Zwei Workspaces mit Konten beim selben Provider haben dieselbe SipServer-Domain. Ohne DID-Whitelist
akzeptiert dann jede dieser Lines jeden eingehenden INVITE an diese Domain — auch die Anrufe des
anderen Workspace. Wer zuerst annimmt, gewinnt. Das ist dasselbe Rennen wie im Issue, nur eine Ebene
höher und mit der Mandantentrennung als Einsatz.

Das SDK ist hier nicht schuld: Es dokumentiert den permissiven Default (Provider liefern von IPs, die
nicht im Registrar-DNS stehen) und nennt zwei Gegenmittel. Callora benutzt beide nicht.

Teil A braucht deshalb ein Kriterium mehr: Die Zuordnung muss zuerst den Workspace treffen, dann den
Konsumenten.

Teil B: nicht „fehlt", sondern „endet in der Datenbank"

MaxConcurrentCalls … wird beim Wählen nirgends geprüft. CallControlService liest es nicht.
Gebremst wird heute nur vom Carrier.

Im Ergebnis richtig, in der Begründung nicht. Das SDK reserviert bereits atomar, mit genau den
Eigenschaften, die das Issue fordert — Rollback bei Überschreitung, eingehende Anrufe zählen mit,
Freigabe wenn das Setup scheitert (PhoneLine.TryReserveCallSlot).

Nur speist sich dieses Limit aus VoipConfiguration.MaxConcurrentCallsPerLine — client-weit, nicht
pro Konto — und Callora setzt den Wert nirgends. SdkSipAccountFactory mappt neun Felder,
MaxConcurrentCalls ist keines davon. Das Limit wird also gepflegt, validiert, gespeichert und
erreicht nie etwas, das es durchsetzen könnte.

Für die Umsetzung heißt das: Der Kern ist keine neue Reservierungsmechanik, sondern eine eigene
Schicht in Callora. Die braucht es ohnehin, weil Kontingente pro Konsument etwas sind, das eine
SIP-Line prinzipiell nicht wissen kann. Das SDK-Limit bleibt darunter als zweites Netz, sobald es
korrekt gespeist wird.

Vorschlag zum Schneiden

Ohne SDK sofort machbar: Teil B vollständig · Besitzer/Beobachter trennen · die zwei
Mandanten-Korrekturen an SdkSipAccountFactory · P-Asserted-Identity und Diversion überhaupt erst
mappen (SdkCall lässt sie heute fallen).

Wartet auf das SDK: die Zuordnung Nummer → Konsument.

[BechsteinDigital]

Korrektur zu meinem vorigen Kommentar. Ich hatte geschrieben, MaxConcurrentCalls „endet in der
Datenbank" und erreiche nichts, das es durchsetzen könnte. Das ist falsch, und es war ein zu früher
Schluss: Ich hatte nur SdkSipAccountFactory geprüft, die das Limit nicht ans SDK-Konto mappt — der
Weg läuft aber gar nicht dorthin.

Teil B ist überwiegend bereits gebaut

SdkVoiceChannelConnector.cs:65 reicht account.MaxConcurrentCalls an den Channel, und
SdkVoiceChannel setzt es durch:

// Reserve a slot atomically before dialing; release on Terminated or on Dial failure.
if (Interlocked.Increment(ref _activeCalls) > _maxConcurrentCalls)
{
    Interlocked.Decrement(ref _activeCalls);
    throw new InvalidOperationException(
        $"Channel '{ChannelId}' has reached its concurrent-call limit of {_maxConcurrentCalls}.");
}

Und eingehende Anrufe zählen mit:

// Inbound calls count against the concurrent-call ceiling so outbound gating reflects the real
// trunk load.
Interlocked.Increment(ref _activeCalls);

Damit sind vier der sechs Akzeptanzkriterien von Teil B erfüllt: Durchsetzung beim Wählen, atomare
Reservierung (Increment-dann-Rollback, zwei gleichzeitige Versuche können das Limit nicht
überschreiten), eingehende Anrufe auf demselben Limit, benannter Fehler bei Erschöpfung. Die Freigabe
ist idempotent gelöst und deckt auch den Fall ab, dass ein Anruf bereits terminiert ist, bevor der
Handler hängt.

Was von Teil B übrig bleibt

Kontingente pro Konsument — das eigentliche Thema, siehe unten.

Eingehende Erschöpfung wird nicht abgelehnt. Eingehende Anrufe zählen mit, aber ein eingehender
Anruf über dem Konto-Limit wird nicht mit 503 abgewiesen; die Ablehnung passiert eine Ebene tiefer im
SDK und gegen dessen client-weites MaxConcurrentCallsPerLine, nicht gegen das des Kontos. Bei
MaxConcurrentCalls = 4 nimmt die Line also den fünften Anruf an, und der Zähler steht danach über
dem Limit — was die nächste ausgehende Wahl blockiert, obwohl das nicht die Absicht war. Kleiner
Defekt, aber ein anderer als der ursprünglich beschriebene.

Kontingente: die Einheit ist feiner als ein Plugin

Aus der Diskussion: Betreiber denken in Funktionen, nicht in Komponenten — „Kampagne X zwei Leitungen,
Kampagne Y fünf, CRM zehn, damit zehn Mitarbeiter gleichzeitig telefonieren können".

Das schließt die naheliegenden Achsen aus. Plugin ist zu grob: Kampagne X und Y leben beide im
Dialer. Surface trägt nicht: Ein Predictive Dialer wählt serverseitig ohne Oberfläche, und die
Telefon-Einwahl kommt von außen herein — beide verbrauchen Leitungen und haben kein Surface.
Richtung löst nur einen der beiden Konflikte (ausgehend frisst eingehend), nicht den zweiten (der
Dialer nimmt dem CRM-Agenten die Leitung).

Was bleibt, ist eine frei benannte Herkunft, die der Aufrufer angibt — nach ADR-013
(Trusted-in-Process) ist das ausreichend: Plugins laufen im selben Prozess und sind vertrauenswürdig,
ein Kontingent ist eine Betriebsgrenze und keine Sicherheitsgrenze. Ein böswilliges Plugin könnte
ohnehin mehr, als ein Kontingent je verhindern würde.