GrandDixence

H-P-K

Ob sunrise eine solche Meldung machen wird entzieht sich meiner Kenntnis.

Salt hat die Abschaltung von 2G/GSM ohne vorgängige Warnung an ihre Kunden und Kundinnen durchgeführt. Salt-Kunden ohne 2G/GSM-fähigen Mobiltelefon konnten dann von einem Tag auf den anderen nicht mehr telefonieren.

Da Sunrise eine schlimme Kundenservicewüste ist, wird Sunrise die 3G/UMTS-Abschaltung vermutlich ohne grosse Vorwarnung an die Kundinnen und Kunden am Tag x.y.2025 durchführen. Ich wäre erstaunt, wenn Sunrise alle Kundinnen und Kunden zeitgerecht informieren würde, dass ihr Mobiltelefon nicht VoLTE-fähig ist oder die darin steckende SIM-Karte nicht VoLTE-fähig ist.

AbRaCH

Warum denn Band 28? Sunrise nutzt ihre mickrigen 5MHz im Band 28 kaum, weder auf LTE noch in 5G.

Weil Band 28 ein Mobilfunkfrequenzband ist, welches in naher Zukunft weltweit für die 5G-Mobilfunkversorgung verwendet wird. Einzige Ausnahme: USA und Kanada. Egal ob man in Grönland ist oder auf einer Südseeinsel im Pazifik, die 5G-Grundversorgung erfolgt (in naher Zukunft) ab Band 28.
https://community.swisscom.ch/d/630107-2g-abschaltung/13

Heute wird in Europa das (mickrige) Band 20 für die Grundversorgung mit 4G/LTE verwendet.
https://de.wikipedia.org/wiki/Mobilfunkfrequenzen_in_der_Schweiz

In Band 8 erwarte ich (in Europa) die zukünftige Grundversorgung mit 6G. Die öffentlichen Mobilfunkanbietern in Europa sollten Band 8 für die zukünftige Nutzung als 6G-Grundversorgungsband reservieren.

Neue Band 28-fähige Mobilfunkantennen sind erforderlich für die schweizweite Grundversorgung mit 5G. Sunrise ist (wegen der Schweizer Einsprachenpolitik) offensichtlich zu langsam mit dem Ausbau ihres Mobilfunknetzes mit neuen Mobilfunkantennen. Wenn die schweizweite Versorgung mit Band 28-Mobilfunksignal fehlt, muss notgedrungen die 5G-Grundversorgung ab Band 8 erfolgen.

Im Sunrise-Mobilfunknetzwerk sollten ausschliesslich Mobiltelefone eingesetzt werden, welche:

VoLTE
UND Band 28
UND “Emergency Call over IMS”

für alle SIM-Kartenhalter unterstützen. Siehe dazu:
https://community.swisscom.ch/d/854440-volte-abstellen/16

Offenbar wird mindestens eine dieser genannten Anforderungen von diesem Smartphone nicht erfüllt.

Leuchtet während einem laufenden Telefongespräch in der Statuszeile ein “4G”-Logo? => VoLTE

Wer die BAKOM-Funksenderkarte und die CellMapper-Karte studiert, wird feststellen, dass in Chiasso TI auf jedem Quadratkilometer mindestens eine Sunrise-Mobilfunkantenne steht. Bei einer solch hohen Mobilfunkantennendichte von ungenügenden Mobilfunkempfang zu sprechen, ist doch völliger Schwachsinn!

https://www.cellmapper.net/map?MCC=228&MNC=2&type=LTE&latitude=45.835962570654175&longitude=9.025563836349159&zoom=15.420422989733236&showTowers=true&showIcons=true&showTowerLabels=true&clusterEnabled=true&tilesEnabled=true&showOrphans=false&showNoFrequencyOnly=false&showFrequencyOnly=false&showBandwidthOnly=false&DateFilterType=Last&showHex=false&showVerifiedOnly=false&showUnverifiedOnly=false&showLTECAOnly=false&showENDCOnly=false&showBand=0&showSectorColours=true&mapType=roadmap&darkMode=false&imperialUnits=false

Von den genannten Perrons im Bahnhof Chiasso TI besteht vermutlich Sichtverbindung auf die Sunrise-Mobilfunkantenne Sunrise TI434-2 (westlich vom Bahnhof, am Bach Faloppia). Und die meisten Mobilfunkantenne sind sowieso mit 3 Sektorenantennen ausgerüstet, was eine (lückenlose) Rundum-Versorgung mit Mobilfunk ergibt (3 × 120° = 360°).

Entweder ist das Mobiltelefon defekt oder die SIM-Karte hat eine “Macke”. Siehe dazu:
https://community.sunrise.ch/d/42613-netzabdeckung-schlecht/8

Wurde durch die Sunrise-Hotline der Reset der Sunrise-SIM-Karte durchgeführt?

Wieso sind in den Wireshark-Aufzeichnungen zwei unterschiedliche IPv4-Adressen für den DNS-Client ersichtlich?

Working.pcap: 62.2.45.209
Not Working.pcap: 192.168.1.102

Gemäss Paket Nr. 13 in “not working.pcap” ist die Fehlerursache eindeutig: Der DNS-Server verwendet eine unpassende Sequenznummer, welche darauf hinweist, dass der DNS-Server ein TCP-Paket abgesendet hat, welches beim DNS-Client (192.168.1.102) nie angekommen ist!

Der Inhalt von Working.pcap sieht identisch mit den Wireshark-Aufzeichnungen von meinem Internetanschluss aus (EuroDOCSIS-Kabelmodem im Bridge-Modus). Einzige Ausnahme: In der Antwort auf die DNS-Anfrage per TCP werden bei mir 3 und nicht 4 DNSKEY-Einträge aufgeführt.

In der Antwort von Pato sehe ich auch nur 3 DNSKEY-Einträge. Gleiches gilt auch für den DNSSEC-Debugger:
https://dnssec-debugger.verisignlabs.com/post.ch

=> Found 3 DNSKEY records for post.ch

Wieso sind in “working.pcap” 4 statt 3 DNSKEY-Einträge für post.ch ersichtlich?

Wieso veröffentlicht man hier veraltete Wireshark-Aufzeichnungen vom Zeitraum 25./26. Januar 2025?

Bitte mal die Path-MTU von IPv4 an diesem Glasfaser-Internetanschluss (mit Linux) ausmessen:
https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

`# ping -M do -c 3 -s 1472 tick.switch.ch
PING tick.switch.ch (130.59.31.31) 1472(1500) Bytes Daten.
1480 Bytes von tick.switch.ch (130.59.31.31): icmp_seq=1 ttl=58 Zeit=17.8 ms
1480 Bytes von tick.switch.ch (130.59.31.31): icmp_seq=2 ttl=58 Zeit=19.0 ms
1480 Bytes von tick.switch.ch (130.59.31.31): icmp_seq=3 ttl=58 Zeit=15.8 ms

— tick.switch.ch ping-Statistik —
3 Pakete übertragen, 3 empfangen, 0% Paketverlust, Zeit 2003ms
rtt min/avg/max/mdev = 15.841/17.542/19.027/1.309 ms`

`# ping -M do -c 3 -s 1473 tick.switch.ch
PING tick.switch.ch (130.59.31.31) 1473(1501) Bytes Daten.
ping: lokaler Fehler: Nachricht zu lang, MTU=1500
ping: lokaler Fehler: Nachricht zu lang, MTU=1500
ping: lokaler Fehler: Nachricht zu lang, MTU=1500

— tick.switch.ch ping-Statistik —
3 Pakete übertragen, 0 empfangen, +3 Fehler, 100% Paketverlust, Zeit 2055ms`

Genau solche Probleme sind der Grund, weshalb ich bei einem Glasfaser-Internetanschluss (FTTH) das Angebot Fiber7 von Init7 bevorzuge. Nach dem Motto: Bridge-Modus oder gar nichts. Siehe dazu:
https://community.sunrise.ch/d/36969-xgs-pon-bridge-faehige-modemtypen/39

https://community.sunrise.ch/d/40629-glasfaser-mit-bridge/3

DNSSEC mit unbound läuft hier auf einigen Internetanschlüssen von UPC/Sunrise einwandfrei (Raspberry Pi 4 mit Ubuntu Server 20.04). Diese EuroDOCSIS-Kabelmodeme werden im Bridge-Modus betrieben. Der Bridge-Modus ist bekanntlich für Glasfaser-Internetanschlüsse von Sunrise nicht verfügbar.

Ich empfehle die unter:
https://community.sunrise.ch/d/36906-dns-probleme

https://community.swisscom.ch/d/773537-erreichbarkeit-von-postfinancech
veröffentlichte DNSSEC-Fehlersuche durchzugehen. Zu DNS-Allgemein siehe auch meine Hinweise unter:
https://community.sunrise.ch/d/41982-quad9-tcp-ports-443-und-853-nicht-erreichbar/10

Es hat schon Helden und Heldinnen gegeben, welche vergessen haben, in den Firewalleinstellungen den ausgehenden DNS-Datenverkehr auf Serverport TCP 53 freizuschalten.

millernet

und die beträchtliche Anzahl aktiver Komponenten im Netz, die alle Strom brauchen und potentiell ausfallen können.

XGS-PON ist zu komplex (=> Konfigurationsfehlern) und hat auch zu viele Komponenten die stören oder ausfallen können. XGS-PON ist sicher nicht der Königsweg. XGS-PON ist schlicht die “Sparlösung auf dem Buckel der zahlenden Kunden”.

XGS-PON ist auch hier der Königsweg fürs “gemeine Volk”,

Der Königsweg für das “gemeine” Volk ist das Angebot Easy7 von Init7.

Nerds gehen zu Init7 mit echtem P2P Ethernet.

Oder sie warten monatelang, wenn nicht gar jahrelang, bis der versprochene Init7-PoP in Betrieb geht und in der Init7-Glasfaserkarte die Farbe vom PoP von grün (In Planung/im Aufbau) auf rot (in Betrieb) wechselt.
https://ftth.init7.net/

Das “soon” beim Fiber7-Angebot auf dieser Karte steht für: Musst Dich noch viele Monaten gedulden, vielleicht kommt dann irgendwann in naher oder ferner Zukunft die Inbetriebnahme vom Init7-PoP. Bis dahin darfst Du nachts von P2P/AON träumen und dich tagsüber mit XGS-PON (Hybrid7) oder einem Internetanschluss über Fernsehkabelnetzwerk (EuroDOCSIS) oder per Telefonkabel (VDSL2/G.FAST) grün und blau ärgern.

xipu
Bei nicht nachvollziehbarem Verhalten könnte auch ein fehlerhafter SIP-ALG Ursache für die VoIP-Telefonieprobleme sein. Ein solch fehlerhafter SIP-ALG könne im EuroDOCSIS-Kabelmodem oder auf der eigenen Hardware-Firewall laufen.
https://community.sunrise.ch/d/8601-voip-telefon-uber-netvoip-hangt-immer-nach-genau-30-sekunden-auf-giga-connect/3

Fehlerhafte SIP-ALG sind ein Grund, weshalb ich kein Fan von unverschlüsselter SIP-Kommunikation bin.

Wurde schon getestet, ob die VoIP-Telefonie über die “Mobilen Daten” (Internetanschluss über Mobilfunknetzwerk) funktioniert? Dazu muss vorgängig irgendwo in den Einstellungen der Linphone-App (unter “Erweitert” oder “Netzwerk”) der Regler “Nur über WLAN telefonieren” korrekt justiert werden.

Vielleicht hilft auch die Linphone-Einstellung:

Netzwerk > Zufällige Ports verwenden:=aus

weiter.

Und gemäss diesem Artikel:
https://blog.evaristesys.com/2018/05/07/server-side-nat-traversal-with-kamailio-the-definitive-guide/
gibt es zwei bekannte Verfahren für das “Keep alive” von SIP.

1.) Das VoIP-Telefon sendet innerhalb der UDP-/TCP-Aging-Zeit ein SIP REGISTER-Telegramm für die Neuregistrierung am SIP-Server vom VoIP-Anbieter.

2.) Der SIP-Server sendet innerhalb der UDP-/TCP-Aging-Zeit ein SIP OPTIONS-Telegramm an alle registrieren VoIP-Telefone.

Methode 1) funktioniert nicht einwandfrei beim Einsatz von SIP über UDP und in Kombination mit aggressiven Firewalls, deren UDP-Aging < 60 Sekunden ist! Das Zeitintervall zwischen dem Versand der SIP REGISTER-Telegramme ist in den Einstellungen der Linphone-App konfigurierbar. Der Standardwert ist 3600 Sekunden.

oli-h
1.) Ja, meinem “DUStel Starter”-Angebot ist keine Telefonnummer (MSISDN) zugewiesen. Deshalb kann ich über das “DUStel starter” nicht per Wahl einer Telefonnummer (MSISDN => tel:+41312134567) angerufen werden. Ankommende Anrufe sind nur im URI-Format möglich: sip:user@secure.dus.net

Siehe dazu:
https://de.wikipedia.org/wiki/Session_Initiation_Protocol#Funktionsweise

Diese Direktwahl im URI-Format funktioniert aber nicht mit jedem VoIP-Anbieter. Beim Prepaid-Angebot von NetVoIP musste ich feststellen, dass ich mein VoIP-fähiges und beim NetVoIP-SIP-Server angemeldetes Festnetztelefon nicht per Linphone-App, und VoIP-Konto bei DUS.net, mit der Angabe im URI-Format (sip:0312134567@sip.netvoip.ch) anrufen kann.

NetVoIP blockiert offenbar (netzfremde) Anrufe (aus dem Internet) per URI-Formatangabe. Ob diese Blockade von NetVoIP aus Sicherheitsgründen oder aus Kostenspargründen erfolgt, ist mir nicht bekannt. Es sieht danach aus, dass NetVoIP nur Anrufe aus dem klassischen Telefonienetzwerk (PSTN) und VoIP-Anrufe von anderen NetVoIP-Kunden erlaubt.

2.) Ich kann mit dem “DUStel Starter”-Angebot nur die beim Angerufenen angezeigte Telefonnummern fälschen (faken), welche vorgängig von DUS.net mit einem Validierungsanruf erfolgreich geprüft wurden. Im Validierungsanruf teilt eine Computerstimme am Telefon einen PIN-Code mit, welcher man per Webbrowser im DUS.net-Kundencenter eingeben muss. Siehe den Screenshot unter:
https://community.swisscom.ch/d/809999-sim-swap-maximaler-schutz/8

Dass die Sprachtelefonie mit der LinPhone-App nicht funktioniert, liegt nicht an der App, sondern an der fehlerhaften Konfiguration der VoIP-Telefonie (SIP/RTP). SIP = Sicher Immer Probleme

Bei der Konfiguration von VoIP-Telefonen, oder von Apps für die VoIP-Telefonie, muss beachtet werden dass die Signalisierung von Telefongespräche (klingen, Besetztton etc.) über das Netzwerkprotokoll SIP abgewickelt wird. Die Übermittelung der Sprachdaten vom Telefongespräch erfolgt mit dem Netzwerkprotokoll RTP.

Erscheint in der Linphone-App oben links der grüne Punkt, funktioniert die Signalisierung einwandfrei zwischen VoIP-Telefon (hier: Linphone-App) und dem VoIP-Anbieter (hier: Sunrise). Wenn dieser Punkt aber in oranger oder gar roter Farbe dargestellt wird, liegt entweder ein Netzwerkproblem vor oder die Konfiguration vom SIP-Anteil im VoIP-Telefon ist nicht korrekt.

Wird das Telefongespräch aufgebaut, aber die Gegenseite ist nicht hörbar, liegt ein Problem mit der Konfiguration im RTP-Anteil im VoIP-Telefon vor.

Gegen die Trennung der SIP-Netzwerkverbindung zwischen VoIP-Telefon und VoIP-Anbieter wegen Inaktivität (durch eine Firewall => UDP-/TCP-Aging) hilft das sogenannte “Keep alive”:

• Erfolgt die SIP-Verbindung per Netzwerkprotokoll UDP, sollte das “Keep alive” auf 15 Sekunden konfiguriert werden.
• Erfolgt die SIP-Verbindung per Netzwerkprotokoll TCP oder in verschlüsselter Form mit SIPS (mit TLS verschlüsseltes SIP), sollte das “Keep alive” auf 120 Sekunden konfiguriert werden.

Mit “keep alive” (keepalive packets, keep-alive) holt man sich aber auf dem Mobiltelefon “gewaltige” Batterieprobleme ein. Siehe dazu:
https://wiki.linphone.org/xwiki/wiki/public/view/Linphone/Good%20practices%20for%20using%20SIP/

Wenn die Firewall die SIP-Verbindung wegen Inaktivität trennt, merkt man dies als Anwender, wenn ankommende Anrufe nur zu einem Besetztton führen.

Wenn der VoIP-Anbieter die Signalisierung per TCP-Serverport unterstützt (transport = TCP), empfehle ich die Signalisierung per TCP (Serverport: TCP 5060). Signalisierung über Serverport UDP 5060 ist in meinen Augen nur eine Not- oder Billiglösung (transport = UDP)! Noch besser ist die verschlüsselte Signalisierung (transport = TLS => SIPS -> üblicher Serverport: TCP 5061).

Zur verschlüsselten Signalisierung (SIPS) siehe diesen Beitrag:
https://community.sunrise.ch/d/42761-ich-will-nach-wie-vor-zwei-festnetznummern/19

Einfach diese Anleitung verwenden und die “SIP-Credentials” entsprechend anpassen:
https://support.phonestar.ch/help/de-de/148-linphone-smartphone-app/269-linphone-smartphone-app-konfiguration

oli-h
Ja, ich habe seit 2016 ein “DUStel starter”-Angebot im Einsatz.

Im Jahr 2016 gab es noch kein “WiFi-Calling” (VoWLAN) und ich wollte eine kostengünstige und bis zum VoIP-Anbieter verschlüsselte Lösung für die Sprachtelefonie, wenn ich im fernen Ausland in die Schweiz telefonieren möchte/müsste. Man beachte die “sauteuren” Minutenpreise für die Sprachtelefonie über Mobiltelefon, wenn man sich in Ländern wie Argentinien oder Marokko befindet und sich im Mobiltelefon nur eine Schweizer SIM-Karte befindet (Swisscom, Sunrise).

Dieses “DUStel starter”-Angebot betreibe ich auf dem Android-Smartphone mit der Open Source-App LinPhone. Natürlich mit Verschlüsselung der Signalisierung (SIPS) und der Sprachdaten (SRTP) bis zum VoIP-Anbieter. Danach ist sowieso alles unverschlüsselt (keine End-to-End-Verschlüsselung)!
https://de.wikipedia.org/wiki/Linphone

https://www.dus.net/de/sip

Dieses “DUStel starter” eignet sich in meinen Augen nur für abgehende Sprachanrufe. Kommt ein Anruf über die Schweizer SIM-Karte ein, lehne ich den Anruf ab (roter Telefonhörer), positioniere mich an einen Standort mit sehr gutem Hotel-WLAN-Empfang und rufe mit der LinPhone-App über das Hotel-WLAN mit dem “DUStel starter”-Angebot zurück.

Ich habe keine deutsche Telefonnummer für “DUStel starter”. Der Trick mit dem “DUStel starter”-Angebot ist der, dass man die auf dem angerufenen Telefon angezeigte Telefonnummer (MSISDN) leicht fälschen kann. Wenn ich mit LinPhone und “DUStel starter” jemanden anrufen, erscheint beim Angerufenen meine Festnetztelefonnummer, weil ich diese Festnetztelefonnummer im DUS.net-Kundenportal für das “DUStel starter”-Angebot hinterlegt habe. Siehe dazu:
https://community.swisscom.ch/d/809999-sim-swap-maximaler-schutz/8

Heute verwende ich als Massnahme gegen sauteures Roaming einen VPN-Tunnel nach Hause. Durch diesen VPN-Tunnel funktioniert dann WiFi-Calling (VoWLAN), wie als wäre ich zu Hause (Schweizer Privathaushalt-WLAN). Dank VPN-Tunnel und öffentlicher Schweizer IPv4-Adresse sind die Minutenpreise für diese Anrufe aus dem ausländischen Hotel-WLAN wie in der Schweiz. Mit meiner Swisscom Prepaid SIM-Karte: 0.90 CHF pro Stunde.

Heute betreibe ich auch zwei Raspberry Pi 4 mit Ubuntu Server 20.04 und der SIP-Software Kamailio als eigene “Telefonzentralen”. Über Kamailio werden mit VoIP-Telefonen in mehreren Privathaushalten die “internen” Telefongespräche abgewickelt. Siehe dazu:
https://www.lancom-forum.de/viewtopic.php?p=101750&hilit=kamailio#p101750

Da diese Privathaushalte mit VPN-Tunneln verbunden sind, ist diese Sprachtelefonie abhörsicher (und kostenlos). Da die eingesetzten Gigaset-Drahtlostelefone kein SIPS und kein SRTP unterstützen, fehlt aber die durchgängige End-to-End-Verschlüsselung der internen Telefongespräche. Fällt der Raspberry Pi 4 im Privathaushalt A aus, übernimmt der Raspberry Pi im Privathaushalt B die Aufgabe der eigenen Telefonzentrale (Redundanz => Hochverfügbarkeit).

Abgehender Anruf an Haushalt C über Kamailio auf Raspberry Pi in Privathaushalt A: Telefonnummer: 3
Abgehender Anruf an Haushalt C über Kamailio auf Raspberry Pi in Privathaushalt B: Telefonnummer: 33

Eine Einwahl mit VPN-Tunnel für die Abwicklung der internen Telefongespräche ab Mobiltelefon per LinPhone-App ist problemlos technisch realisierbar, fehlt aber noch…

chokito
Eine Verschlüsselung der Sprachdaten mit SRTP zwischen VoIP-Telefon und VoIP-Anbieter bringt nichts, wenn die Signalisierung von Telefonanrufen zwischen VoIP-Telefon und VoIP-Anbieter unverschlüsselt durch das Internet geht. SRTP ist eine Variante der verschlüsselten Übertragung vom Netzwerkprotokoll RTP.

Wenn SRTP in Kombination mit unverschlüsseltem SIP eingesetzt wird, so wird in den SIP-Datenpakete das Schlüsselmaterial für die Entschlüsselung der (nachkommenden) SRTP-Datenpakete unverschlüsselt (durch das Internet) übertragen! Ein Hacker braucht nur mit Wireshark diese SIP-Datenpakete zu untersuchen und kann dann mit diesem kinderleicht auslesbaren Schlüsselmaterial das gesamte, mit SRTP verschlüsselte Telefongespräch abhorchen…

Unter dem Begriff “TLS für die Verschlüsselung von Anrufen” meint PhoneStar(*) offensichtlich SIPS. SIPS ist die mit TLS verschlüsselte Version von SIP.

SIP dient der Signalisierung von Telefonanrufen.
RTP der Übermittlung der Sprachdaten vom Telefonanruf.

Vor dem Einsatz von SRTP empfehle ich das Durchlesen der Hinweise zum Einsatz von SRTP im BSI TR-02102-1 (Anhang C.1):
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr02102_node.html

Ohne SIPS ist die VoIP-Sprachtelefonie mit SIP/RTP anfällig für sogenannte “SIP-Digest-Leak-Angriffe”. Siehe dazu:
https://www.syss.de/fileadmin/dokumente/Publikationen/2022/2022-05-12_Abrell_Sonderdruck_VoIP-Hack_VAF-Report.pdf

oli-h

Hat jemand eine Empfehlung für einen unabhängigen SIP-Anbieter?

Empfehlen kann ich nur den deutschen Anbieter DUS.net ( https://www.dus.net/ ). DUS.net ist der einzige mir bekannte VoIP-Telefonieanbieter, welcher auch Privatkunden ohne Aufpreis die für VoIP-Telefonie empfehlenswerten Sicherheitsmerkmale SIPS (verschlüsselte Signalisierung der Telefonie) und SRTP (verschlüsselte Sprachdaten) unterstützt. Leider bietet DUS.net keine Schweizer Telefonnummern an und die Minutenpreise für Telefongespräche auf Schweizer Festnetz- und Mobilanschlüsse sind relativ hoch.

Für einen Festnetztelefonanschluss mit Schweizer Telefonnummer fiel meine Wahl auch auf NetVOIP. Bis jetzt bin ich mit NetVOIP zufrieden.

Übersicht aller auf Providerliste registrierten VoIP-Anbieter mit aktuellen Telefonie-Angeboten.
https://www.providerliste.ch/provider/voip.html?l=de

In dieser Auflistung fehlt mir der unabhängige Anbieter Winet:
https://www.winet.ch/
Neben Winet, NetVOIP sind für Privatkunden auch die unabhängigen VoIP-Anbietern iWay, PhoneStar und SipCall für einen Schweizer Festnetzanschluss interessant.

Ich habe zwei Festnetz-Telefonanschlüsse und möchte die weiterhin.

Heute wird für jeden Festnetztelefonanschluss ein Internetanschluss benötigt. Egal ob dieser Festnetzanschluss von Swisscom, Sunrise oder Telefonieanbieter <xyz> angeboten wird. Diese Aussage gilt für alle Anbietern von Festnetzanschlüssen in der Schweiz!

Sunrise betreibt eine Strategie der Zwangs-Migration auf den “Internetanschluss über Fernsehkabelnetzwerk” (EuroDOCSIS):

Wenn noch kein EuroDOCSIS-Kabelmodem in diesem Privathaushalt vorhanden ist, wird dem Endkunde am Tag <x> ein EuroDOCSIS-Kabelmodem per Postpaket zugeschickt, und kurz danach wird am Tag <y> der Internetanschluss über das Telefonkabel abgeschaltet. Mit der Abschaltung vom “Internetanschluss über Telefonkabel” wird logischerweise auch gleichzeitig die Festnetztelefonie über dieses Telefonkabel abgeschaltet. => Siehe Beiträge von Jupiisii am 18.01.2025 unter:
https://community.sunrise.ch/d/42029-festnetz-untaugliches-material-und-untaugliche-anweisung

Die EuroDOCSIS-Kabelmodeme von Sunrise verfügen in der Regel über zwei Anschlüsse (RJ-11) für die analoge Telefonie. Jedoch unterstützt die Sunrise aus administrationstechnischen Gründen gleichzeitig nur einen einzigen RJ-11-Anschluss. Mit einem einzigen RJ-11-Anschluss für die analoge Telefonie kann nur eine einzige Telefonnummer betrieben werden. Siehe dazu:
https://community.sunrise.ch/d/42029-festnetz-untaugliches-material-und-untaugliche-anweisung/5

Weiter werden alle bestehenden UPC-Kunde früher oder später “zwangsmigriert” zu Sunrise-Kunden. => Siehe Beitrag von jupiisii am 22.02.2025 unter:
https://community.sunrise.ch/d/42761-ich-will-nach-wie-vor-zwei-festnetznummern

Will der Sunrise-Endkunde zwei oder mehrere Festnetznummern, muss mindestens eine Telefonnummer mit der zukunftssicheren VoIP-Telefonie realisiert werden. VoIP-Telefonie für eine zweite Festnetznummer ist bei Sunrise heute nur für Geschäftskunden erhältlich. => Siehe Beitrag von Pato am 22.02.2025 unter:
https://community.sunrise.ch/d/42761-ich-will-nach-wie-vor-zwei-festnetznummern/2

Unter:
https://community.sunrise.ch/d/42029-festnetz-untaugliches-material-und-untaugliche-anweisung/5
habe ich bereits Tipps gegeben zum Umstieg auf die zukunftssichere VoIP-Telefonie (SIP-Anbieter mit SIP-fähigen Telefon). Wieso wurde die Umsetzung dieser Tipps über einen Monat versäumt?!

Wenn dem Endkunde die Installation und Konfiguration der VoIP-Telefonie (mit SIP-Anbieter und SIP-Telefon) zu kompliziert ist, so muss die zweite Telefonnummer mit einer SIM-Karte in einem Mobiltelefon betrieben werden. SIP: Sicher Immer Probleme

Wenn man diesen Sachverhalt nicht wahrhaben will, steht man halt früher oder später ohne funktionstüchtige Festnetztelefonie da. Solche Probleme, deren Ursache man vor der Tastatur suchen muss, sind zum Glück nicht mein Problem!