{
  "id": "01a0b3b9-4ff4-7aa3-b8ee-e5eb627cd526",
  "type": "post",
  "thread": [
    {
      "id": "01a0b3b9-4ff4-7aa3-b8ee-e5eb627cd526",
      "depth": 0,
      "author": "Dietmar Zipfel",
      "url": "https://vutuv.de/dzb/posts/01a0b3b9-4ff4-7aa3-b8ee-e5eb627cd526",
      "published_on": "2026-09-18",
      "in_reply_to_id": null,
      "author_username": "dzb",
      "body_markdown": "Super heterogene internationale Telko Regeln sind ein innovations Hemmnis.\n\nDie **Internationalisierung** der \"Anrufwiederholung bei Besetzt\" App [weCall4you](https://apps.apple.com/us/app/wecall4you-phone-auto-redial/id6475631159) hat als größte Hürde die unterschiedlichen **Telko Regulierungen** überwinden müssen. In diesem Artikel gehe ich auf die Herausforderungen genauer ein.\n\n \n\nAls die Voice App außerhalb von Deutschland in die Appstores in den großen Märkten **USA und Indien** gebracht werden sollte, hatte ich einen einfachen Plan: Eine Codebasis (Flutter + Firebase + Twilio) für iOS und Android und ein gemeinsamer Anruf Flow. Die Technik ist schließlich überall die gleiche.\n\nDie Technik war auch die gleiche und die **CPaaS API war sogar so flexibel**, dass ich später ohne Probleme von Twilio auf die europäische [myCPaaS](https://mycpaas.io/) Api wechseln konnte (im \"Compatibility\" Mode ohne Code Änderungen), aber die Telekommunikationsregeln waren in den Ländern überall anders. Und das Beste: Die Regeln ändern sich immer wieder mal (meistens verschärfen sie sich weiter).\n\nWas ich dabei über internationale Caller-ID-Regulierung gelernt habe, steht in keiner API-Dokumentation. Oft habe ich es erst bemerkt, wenn ein Anruf einfach nicht ankommt. Genau das ist der Teil, den ich hier aufschreiben will.\n\n### Der technische Rahmen: Es geht nicht um „die Nummer\", sondern um „darfst du diese Nummer präsentieren\"\n\nEine Rufnummer als Caller-ID zu senden, ist technisch trivial. Man setzt ein Feld im API-Call. Ob dieser Anruf beim Empfänger aber *so ankommt*, wie du ihn abgeschickt hast, entscheiden nicht du und nicht dein CPaaS-Anbieter — sondern das terminierende Carrier-Netz im Zielland. Und die Regeln dieser Netze sind reguliert, national, und teilweise diametral verschieden.\n\nKonkret hängt in einer klassischen Rückruf-Architektur (zwei Legs: das System ruft das Ziel an, das System ruft den Nutzer an) an *jedem* Leg eine eigene Caller-ID-Entscheidung. Und die richtige Entscheidung ist pro Zielland eine andere.\n\n### 🇺🇸 USA: STIR/SHAKEN — und warum dein Anruf „Spam Likely\" heißt\n\nDie USA setzen STIR/SHAKEN strikt durch. Vereinfacht gesagt attestiert der originierende Carrier jeden Anruf mit einer von drei Stufen:\n\n* **Full Attestation (A):** Der Carrier kennt den Anrufer *und* bestätigt, dass er berechtigt ist, diese Nummer zu nutzen.\n* **Partial Attestation (B):** Der Carrier kennt den Anrufer, kann aber die Nummernberechtigung nicht bestätigen.\n* **Gateway Attestation (C):** Der Anruf kam über ein Gateway ins Netz — typisch bei internationalem Traffic —, und die Quelle ist nicht authentifizierbar.\n\nUnd hier liegt die Falle für alle, die aus dem Ausland US-Nutzer erreichen wollen: Ein Anruf, der über ein internationales Gateway läuft aber eine US-Nummer präsentiert, die dir nicht nachweislich „gehört\", bekommt bestenfalls ein C. Das terminierende Netz sieht: unbekannte Quelle, US-Nummer, keine saubere Attestierung. Die Reaktion reicht von „Anruf-ID unterdrückt\" über das berüchtigte **„Spam Likely\"**-Label bis zur direkten Zustellung auf die Mailbox.\n\nIn **Österreich** passiert übrigens seit relativer kurzer Zeit ähnliches und immer mehr Länder verhalten sich ähnlich und anonymisieren oder blockieren internationalen Call Traffic, der vorgibt, national zu sein.\n\nDer Nutzer sieht im schlimmsten Fall nie, dass du angerufen hast. Du siehst in deinen Logs einen erfolgreich abgesetzten Call. Beide Seiten glauben, alles sei in Ordnung. Es ist der teuerste Bug, den es gibt: der, der wie ein Erfolg aussieht.\n\nDie einzige saubere Lösung: **verifizierte Caller-IDs**. Der Nutzer verifiziert seine eigene Nummer beim Anbieter (bei uns per Voice-Call-Verifizierung in den USA oder SMS in Deutschland), und erst danach darf diese Nummer als Absender genutzt werden. Vorher — und für jeden unverifizierten Bestandsnutzer — muss zwingend eine anbietereigene, sauber attestierte Nummer als Absender her.\n\n### 🇮🇳 Indien: TRAI, und ein noch härteres „Nein\"\n\n**Indien ist der Extremfall**. TRAI und DoT regulieren den Telefonieverkehr über ein striktes Lizenzregime (OSP-Framework), und die indischen Carrier blocken internationale Anrufe (die also technisch aus dem Ausland kommen), die eine indische CallerID anzeigen komplett.\n\nMan kann sich hier gar nicht erst auf Verifizierung verlassen — ich habe für Indien deshalb eine harte Regel eingezogen: Die verifizierte Rufnummer des indischen Nutzers wird nie beim indischen Anruf Ziel angezeigt, sondern immer eine deutsche oder US Rufnummer.\n\nDas führt dazu, dass in der App weCall4you, die am Ende (wenn die besetzte Rufnummer von unserer Plattform endlich erreicht wurde) zwei indische Anrufer miteinander verbindet, beiden Parteien eine deutsche oder US Rufnummer als Caller ID anzeigt, was für unnötige Verwirrung sorgt und genau dem **Zweck der Regulierung widerspricht**, für maximale Transparenz zu sorgen.\n\n### 🇬🇧 UK: Ofcom, aber mit angezogener Handbremse\n\nGroßbritannien ist der entspannte Fall. Ofcom verlangt inzwischen CLI-Authentifizierung, aber die Durchsetzung durch die UK-Carrier ist deutlich weicher als STIR/SHAKEN in den USA. In der Praxis läuft hier vieles noch so durch, wie man es aus einer klassischen Rückruf-Logik kennt — was aber kein Grund ist, sich darauf zu verlassen. Regulierung, die heute weich durchgesetzt wird, ist morgen hart durchgesetzt. Das erfahren wir gerade aus **Österreich**, wo die Regeln gerade wieder verschärft werden.\n\n### Die Konsequenz im Code: eine Fallunterscheidung, die kein Framework dir abnimmt\n\nWas als „eine Codebasis\" geplant war, wurde zu einer verzweigten Entscheidung, die bei *jedem einzelnen Anruf* neu getroffen wird — abhängig vom Zielland und vom Verifizierungsstatus des Nutzers:\n\n* **Ziel Indien:** Niemals indische Caller ID anzeigen. Keine Ausnahme.\n* **Ziel USA/Kanada, Nutzer nicht verifiziert:** Nur anbietereigene Nummer als Caller ID anzeigen.\n* **Ziel USA/Kanada, Nutzer verifiziert:** eigene Nummer erlaubt (STIR/SHAKEN-konform über verifizierte Caller-IDs).\n* **Deutschland:** Standard-Rückruf-Logik (Nutzer-Nummer als Absender, Zielnummer als Caller-ID beim Rückruf-Leg).\n\n### Meine Meinung: Die Fragmentierung ist ein Innovationshemmnis — trägt aber ihre Berechtigung in sich\n\n**Ich verstehe** ***warum*** **es diese Regeln gibt.** STIR/SHAKEN existiert, weil Robocall-Betrug in den USA epidemische Ausmaße hatte. Indiens harte CLI-Kontrolle ist eine Reaktion auf massiven Spoofing-Missbrauch. Das sind keine bürokratischen Schikanen, das ist Verbraucherschutz mit echtem Anlass. Der Grundgedanke — „du darfst nur präsentieren, was dir gehört\" — ist richtig.\n\n**Aber die** ***Umsetzung*** **ist ein Flickenteppich**, und die Kosten dieses Flickenteppichs trägt asymmetrisch der Kleine. Ein Konzern hat eine Regulatory-Abteilung, die pro Land die Regeln kennt. Ein Solo-Entwickler oder ein kleines Team hat das nicht — und lernt jede Regel schmerzhaft im Livebetrieb, weil das Scheitern eben *lautlos* ist. Kein HTTP-Fehler, kein Alert, nur ein Nutzer, der sich wundert, warum er nie einen Anruf bekommt, und der irgendwann abwandert.\n\nDas Schlimmste ist nicht die Strenge der Regeln. Es ist die **Diagnostizierbarkeit, die Heterogenität in den Ländern und die Unkalkulierbarkeit bei Änderungen**. Wenn ein Call regelwidrig ist, sollte er mit einem klaren Fehler abgewiesen werden — nicht scheinbar durchgehen und dann im terminierenden Netz still versanden.\n\n**Und mindestens in Europa sollten in allen Ländern gleiche Regeln herrschen**, auf die ich mich auch morgen noch verlassen kann, ohne dass ich fürchten muss, dass mir die Grundlage meines Produktes entzogen wird, weil z.B. Österreich plötzlich alle von Twilio nach Österreich aufgebauten Anrufe mit deutscher (verifizierter) Caller ID komplett blockt (in Deutschland hat das Problem meines Wissens nur myCPaaS gemeinsam mit der Deutschen Telekom lösen können).\n\nWas ich mir wünschen würde: nicht weniger Regulierung, sondern ***harmonisierte Signale mit einheitlichen Regeln für Europa***. Ein einheitlicher, maschinenlesbarer Weg, über den ein terminierendes Netz zurückmeldet, *warum* es einen Anruf abgewertet oder unterdrückt hat. Das würde Missbrauch kein Stück erleichtern — aber es würde den ehrlichen Entwicklern die Diagnose zurückgeben, die ihnen heute fehlt.\n\n### Das eigentliche Learning\n\nDer Wechsel des CPaaS-Anbieters ist einfach. Die API ist einfach. Was schwer ist — und was den Unterschied zwischen „funktioniert im Test\" und „funktioniert für echte Nutzer in echten Ländern\" ausmacht —, ist das Wissen darüber, **was** ***nach*** **deinem API-Call passiert, im regulierten Niemandsland zwischen deinem Space und dem Telefon des Empfängers.**\n\n**Genau dieses Wissen steuere ich mit SignalNet aus zahlreichen Implementierungs Projekten mit bei.** Wenn ihr an diesem Punkt steht — bei einer Migration, einem neuen Markt, oder einfach bei Anrufen, die „irgendwie nicht ankommen\" —, schreibt mir. Ich habe die eine oder andere Herausforderung in diesem Bereich schon erlebt und gemeistert.",
      "in_reply_to_author": null
    }
  ],
  "description": "Super heterogene internationale Telko Regeln sind ein innovations Hemmnis.",
  "title": "Dietmar Zipfel · 2026-09-18",
  "author": {
    "name": "Dietmar Zipfel",
    "username": "dzb",
    "url": "https://vutuv.de/dzb"
  },
  "replies": [],
  "url": "https://vutuv.de/dzb/posts/01a0b3b9-4ff4-7aa3-b8ee-e5eb627cd526",
  "formats": {
    "json": "https://vutuv.de/dzb/posts/01a0b3b9-4ff4-7aa3-b8ee-e5eb627cd526.json",
    "text": "https://vutuv.de/dzb/posts/01a0b3b9-4ff4-7aa3-b8ee-e5eb627cd526.txt",
    "markdown": "https://vutuv.de/dzb/posts/01a0b3b9-4ff4-7aa3-b8ee-e5eb627cd526.md",
    "xml": "https://vutuv.de/dzb/posts/01a0b3b9-4ff4-7aa3-b8ee-e5eb627cd526.xml"
  },
  "video": null,
  "tags": [
    "telekommunikation",
    "CPaaS",
    "STIRSHAKEN",
    "VoiceAPI",
    "SignalWire"
  ],
  "in_reply_to": null,
  "like_count": 0,
  "generated_at": "2026-09-20T14:45:28Z",
  "schema_version": 3,
  "published_on": "2026-09-18",
  "images": [],
  "review": null,
  "license": null,
  "fediverse_reaction_count": 0,
  "reply_count": 0,
  "fediverse_replies": [],
  "body_markdown": "Super heterogene internationale Telko Regeln sind ein innovations Hemmnis.\n\nDie **Internationalisierung** der \"Anrufwiederholung bei Besetzt\" App [weCall4you](https://apps.apple.com/us/app/wecall4you-phone-auto-redial/id6475631159) hat als größte Hürde die unterschiedlichen **Telko Regulierungen** überwinden müssen. In diesem Artikel gehe ich auf die Herausforderungen genauer ein.\n\n \n\nAls die Voice App außerhalb von Deutschland in die Appstores in den großen Märkten **USA und Indien** gebracht werden sollte, hatte ich einen einfachen Plan: Eine Codebasis (Flutter + Firebase + Twilio) für iOS und Android und ein gemeinsamer Anruf Flow. Die Technik ist schließlich überall die gleiche.\n\nDie Technik war auch die gleiche und die **CPaaS API war sogar so flexibel**, dass ich später ohne Probleme von Twilio auf die europäische [myCPaaS](https://mycpaas.io/) Api wechseln konnte (im \"Compatibility\" Mode ohne Code Änderungen), aber die Telekommunikationsregeln waren in den Ländern überall anders. Und das Beste: Die Regeln ändern sich immer wieder mal (meistens verschärfen sie sich weiter).\n\nWas ich dabei über internationale Caller-ID-Regulierung gelernt habe, steht in keiner API-Dokumentation. Oft habe ich es erst bemerkt, wenn ein Anruf einfach nicht ankommt. Genau das ist der Teil, den ich hier aufschreiben will.\n\n### Der technische Rahmen: Es geht nicht um „die Nummer\", sondern um „darfst du diese Nummer präsentieren\"\n\nEine Rufnummer als Caller-ID zu senden, ist technisch trivial. Man setzt ein Feld im API-Call. Ob dieser Anruf beim Empfänger aber *so ankommt*, wie du ihn abgeschickt hast, entscheiden nicht du und nicht dein CPaaS-Anbieter — sondern das terminierende Carrier-Netz im Zielland. Und die Regeln dieser Netze sind reguliert, national, und teilweise diametral verschieden.\n\nKonkret hängt in einer klassischen Rückruf-Architektur (zwei Legs: das System ruft das Ziel an, das System ruft den Nutzer an) an *jedem* Leg eine eigene Caller-ID-Entscheidung. Und die richtige Entscheidung ist pro Zielland eine andere.\n\n### 🇺🇸 USA: STIR/SHAKEN — und warum dein Anruf „Spam Likely\" heißt\n\nDie USA setzen STIR/SHAKEN strikt durch. Vereinfacht gesagt attestiert der originierende Carrier jeden Anruf mit einer von drei Stufen:\n\n* **Full Attestation (A):** Der Carrier kennt den Anrufer *und* bestätigt, dass er berechtigt ist, diese Nummer zu nutzen.\n* **Partial Attestation (B):** Der Carrier kennt den Anrufer, kann aber die Nummernberechtigung nicht bestätigen.\n* **Gateway Attestation (C):** Der Anruf kam über ein Gateway ins Netz — typisch bei internationalem Traffic —, und die Quelle ist nicht authentifizierbar.\n\nUnd hier liegt die Falle für alle, die aus dem Ausland US-Nutzer erreichen wollen: Ein Anruf, der über ein internationales Gateway läuft aber eine US-Nummer präsentiert, die dir nicht nachweislich „gehört\", bekommt bestenfalls ein C. Das terminierende Netz sieht: unbekannte Quelle, US-Nummer, keine saubere Attestierung. Die Reaktion reicht von „Anruf-ID unterdrückt\" über das berüchtigte **„Spam Likely\"**-Label bis zur direkten Zustellung auf die Mailbox.\n\nIn **Österreich** passiert übrigens seit relativer kurzer Zeit ähnliches und immer mehr Länder verhalten sich ähnlich und anonymisieren oder blockieren internationalen Call Traffic, der vorgibt, national zu sein.\n\nDer Nutzer sieht im schlimmsten Fall nie, dass du angerufen hast. Du siehst in deinen Logs einen erfolgreich abgesetzten Call. Beide Seiten glauben, alles sei in Ordnung. Es ist der teuerste Bug, den es gibt: der, der wie ein Erfolg aussieht.\n\nDie einzige saubere Lösung: **verifizierte Caller-IDs**. Der Nutzer verifiziert seine eigene Nummer beim Anbieter (bei uns per Voice-Call-Verifizierung in den USA oder SMS in Deutschland), und erst danach darf diese Nummer als Absender genutzt werden. Vorher — und für jeden unverifizierten Bestandsnutzer — muss zwingend eine anbietereigene, sauber attestierte Nummer als Absender her.\n\n### 🇮🇳 Indien: TRAI, und ein noch härteres „Nein\"\n\n**Indien ist der Extremfall**. TRAI und DoT regulieren den Telefonieverkehr über ein striktes Lizenzregime (OSP-Framework), und die indischen Carrier blocken internationale Anrufe (die also technisch aus dem Ausland kommen), die eine indische CallerID anzeigen komplett.\n\nMan kann sich hier gar nicht erst auf Verifizierung verlassen — ich habe für Indien deshalb eine harte Regel eingezogen: Die verifizierte Rufnummer des indischen Nutzers wird nie beim indischen Anruf Ziel angezeigt, sondern immer eine deutsche oder US Rufnummer.\n\nDas führt dazu, dass in der App weCall4you, die am Ende (wenn die besetzte Rufnummer von unserer Plattform endlich erreicht wurde) zwei indische Anrufer miteinander verbindet, beiden Parteien eine deutsche oder US Rufnummer als Caller ID anzeigt, was für unnötige Verwirrung sorgt und genau dem **Zweck der Regulierung widerspricht**, für maximale Transparenz zu sorgen.\n\n### 🇬🇧 UK: Ofcom, aber mit angezogener Handbremse\n\nGroßbritannien ist der entspannte Fall. Ofcom verlangt inzwischen CLI-Authentifizierung, aber die Durchsetzung durch die UK-Carrier ist deutlich weicher als STIR/SHAKEN in den USA. In der Praxis läuft hier vieles noch so durch, wie man es aus einer klassischen Rückruf-Logik kennt — was aber kein Grund ist, sich darauf zu verlassen. Regulierung, die heute weich durchgesetzt wird, ist morgen hart durchgesetzt. Das erfahren wir gerade aus **Österreich**, wo die Regeln gerade wieder verschärft werden.\n\n### Die Konsequenz im Code: eine Fallunterscheidung, die kein Framework dir abnimmt\n\nWas als „eine Codebasis\" geplant war, wurde zu einer verzweigten Entscheidung, die bei *jedem einzelnen Anruf* neu getroffen wird — abhängig vom Zielland und vom Verifizierungsstatus des Nutzers:\n\n* **Ziel Indien:** Niemals indische Caller ID anzeigen. Keine Ausnahme.\n* **Ziel USA/Kanada, Nutzer nicht verifiziert:** Nur anbietereigene Nummer als Caller ID anzeigen.\n* **Ziel USA/Kanada, Nutzer verifiziert:** eigene Nummer erlaubt (STIR/SHAKEN-konform über verifizierte Caller-IDs).\n* **Deutschland:** Standard-Rückruf-Logik (Nutzer-Nummer als Absender, Zielnummer als Caller-ID beim Rückruf-Leg).\n\n### Meine Meinung: Die Fragmentierung ist ein Innovationshemmnis — trägt aber ihre Berechtigung in sich\n\n**Ich verstehe** ***warum*** **es diese Regeln gibt.** STIR/SHAKEN existiert, weil Robocall-Betrug in den USA epidemische Ausmaße hatte. Indiens harte CLI-Kontrolle ist eine Reaktion auf massiven Spoofing-Missbrauch. Das sind keine bürokratischen Schikanen, das ist Verbraucherschutz mit echtem Anlass. Der Grundgedanke — „du darfst nur präsentieren, was dir gehört\" — ist richtig.\n\n**Aber die** ***Umsetzung*** **ist ein Flickenteppich**, und die Kosten dieses Flickenteppichs trägt asymmetrisch der Kleine. Ein Konzern hat eine Regulatory-Abteilung, die pro Land die Regeln kennt. Ein Solo-Entwickler oder ein kleines Team hat das nicht — und lernt jede Regel schmerzhaft im Livebetrieb, weil das Scheitern eben *lautlos* ist. Kein HTTP-Fehler, kein Alert, nur ein Nutzer, der sich wundert, warum er nie einen Anruf bekommt, und der irgendwann abwandert.\n\nDas Schlimmste ist nicht die Strenge der Regeln. Es ist die **Diagnostizierbarkeit, die Heterogenität in den Ländern und die Unkalkulierbarkeit bei Änderungen**. Wenn ein Call regelwidrig ist, sollte er mit einem klaren Fehler abgewiesen werden — nicht scheinbar durchgehen und dann im terminierenden Netz still versanden.\n\n**Und mindestens in Europa sollten in allen Ländern gleiche Regeln herrschen**, auf die ich mich auch morgen noch verlassen kann, ohne dass ich fürchten muss, dass mir die Grundlage meines Produktes entzogen wird, weil z.B. Österreich plötzlich alle von Twilio nach Österreich aufgebauten Anrufe mit deutscher (verifizierter) Caller ID komplett blockt (in Deutschland hat das Problem meines Wissens nur myCPaaS gemeinsam mit der Deutschen Telekom lösen können).\n\nWas ich mir wünschen würde: nicht weniger Regulierung, sondern ***harmonisierte Signale mit einheitlichen Regeln für Europa***. Ein einheitlicher, maschinenlesbarer Weg, über den ein terminierendes Netz zurückmeldet, *warum* es einen Anruf abgewertet oder unterdrückt hat. Das würde Missbrauch kein Stück erleichtern — aber es würde den ehrlichen Entwicklern die Diagnose zurückgeben, die ihnen heute fehlt.\n\n### Das eigentliche Learning\n\nDer Wechsel des CPaaS-Anbieters ist einfach. Die API ist einfach. Was schwer ist — und was den Unterschied zwischen „funktioniert im Test\" und „funktioniert für echte Nutzer in echten Ländern\" ausmacht —, ist das Wissen darüber, **was** ***nach*** **deinem API-Call passiert, im regulierten Niemandsland zwischen deinem Space und dem Telefon des Empfängers.**\n\n**Genau dieses Wissen steuere ich mit SignalNet aus zahlreichen Implementierungs Projekten mit bei.** Wenn ihr an diesem Punkt steht — bei einer Migration, einem neuen Markt, oder einfach bei Anrufen, die „irgendwie nicht ankommen\" —, schreibt mir. Ich habe die eine oder andere Herausforderung in diesem Bereich schon erlebt und gemeistert.",
  "repost_count": 0,
  "bookmark_count": 0,
  "fediverse_reply_count": 0,
  "likers": [],
  "fediverse_reactions": [],
  "thread_truncated": false,
  "verified_author_links": [],
  "fediverse_like_count": 0,
  "fediverse_repost_count": 0
}