"Dumme" neue alte Probleme bei VoIP

meyergru21 · ‎08.06.2019

Ich hatte bis vor kurzem ein immer öfter auftretendes Problem mit VoIP bei der Telekom, dass ich nun endlich lösen konnte.
Offenbar bin ich nicht der einzige, ich habe etliche Threads mit ähnlichen Symptomen gefunden, z.B.:

https://www.ip-phone-forum.de/threa...dstream-möglich-mobil-d2-funktioniert.294647/

Das Symptom ist, dass eingehende Telefonate an einem Telekom-VoIP-Anschluß direkt bei Annahme abbrechen, während ausgehende Telefonate an die gleiche Rufnummer einwandfrei funktionieren. Das tritt aber nur in bestimmten Konstellationen auf.

Die Besonderheit ist bei mir (und bei den anderen Betroffenen), dass ein VoIP-Endgerät hinter einem anderen Router eingesetzt wird. Bei mir war das eine Fritzbox 7390 hinter einem Edgemax ER-4. Diese Kombination hat in der Vergangenheit einwandfrei funktioniert, bis vor einigen Wochen ein Kollege mit seinem Handy mich konsequent nicht mehr erreichen konnte, während eingehende Telefonate über das Fetznetz gingen. Seit ca. 2 Wochen gehen nun auch die nicht mehr.

Ich habe alles durchprobiert - vom Wechsel der angebotenen Codecs über die Deaktivierung der HD-Telefonie über Wiederherstellen der Basiskonfiguration (ich hatte Nicht-Standard SIP- und RTP-Ports verwendet) bis hin zum Austausch der Hardware (7490 statt 7390) - alles ohne Effekt.

Die Lösung ist ganz einfach, aber unerwartet: Man muss die VoIP-Zugangsdaten von "Telekom" auf "Anderer Anbieter" umschalten und dann in den erweiterten Einstellungen einen STUN-Server (stun.t-online.de) eintragen, dann geht es.

Warum sage ich, dass das dumm ist? Weil das eigentlich komplett unnötig wäre und bis vor kurzem auch bei der Telekom unnötig war. Die Telekom selbst konnte das schon mal besser als jetzt und ich zumindest hatte nicht erwartet, dass sie an dieser Stelle "verschlimmbessern".

STUN ist nämlich ein Mittel, um bei einem VoIP-Endgerät festzustellen, welche IP nach außen verwendet wird und genau diese IP-Adresse im SIP-"Register"-Aufruf mitzugeben. Ansonsten würde das VoIP-Endgerät hinter einem NAT-Router ja nur seine eigene LAN-IP kennen und diese auch nach außen melden - nur dass diese IP vom Internet aus gar nicht erreichbar ist. Das merkt man dann aber erst, wenn man bei einem eingehenden Anruf diese IP mittels RTP zu erreichen versucht, weshalb der Anruf genau beim Annehmen scheitert.

In der grauen Frühzeit von VoIP war der Einsatz eines STUN-Servers also essentiell, wenn das VoIP-Gateway nicht zufällig mit dem Router identisch war (der kennt ja seine externe IP), wie z.B. bei einer Fritzbox, die gleichzeitig als Router und VoiP-Endgerät genutzt wird.

Seit einigen Jahren sind die meisten VoIP-Provider (darunter bislang auch die Telekom) aber so intelligent, dass sie die im SIP-Register-Aufruf gemeldete IP ignorieren und stattdessen einfach die Ansende-IP verwenden - das ist ja genau die externe IP des Anschlusses. Somit muss das VoIP-Endgerät seine externe IP nicht kennen.

Genau so hat es auch die Telekom bislang gemacht. Offenbar tut sie das jetzt aber nicht mehr und hat Zug um Zug die Software auf Ihren VoIP-Gateways umgestellt oder falsch konfiguriert - zuerst bei denen für einige Mobilfunkprovider und jetzt auf allen oder zumindest den meisten.

Den meisten Benutzern wird das gar nicht auffallen. In der Fritzbox beispielsweise ist die Nutzung von STUN dann unnötig, wenn die Fritzbox selbst auch die Routerfunktion wahrnimmt. Nutzt man eine Fritzbox aber nur als VoIP-Client, enthält die Standardeinstellung für den Provider "Telekom" eben auch keinen STUN-Server. Das ging früher, jetzt aber nicht mehr - deshalb sind viele der Einrichtungsanleitungen inzwischen falsch.

Lösungsmöglichkeiten in dieser Situation:

1. Man trägt selbst den STUN-Server ein.
2. Für AVM: man passt die Standardeinstellungen für den Provider Telekom entsprechend an.
3. Für die Telekom: Stellt das bisherige Verhalten wieder her!

fdi · ‎08.06.2019

Hi @meyergru21 ,

ich nutze ein IP-Telefon hinter einer pfSense an einem Telekom-Anschluß. Ich benötige da keinen STUN und auch keinerlei Portweiterleitungen. Ich kann ohne Probleme Telefonate aus allen Mobilfunknetzen empfangen und auch dort hin telefonieren. Ich denke das da deine Ausführungen umd vermutete Konfigurationsfehler nicht zutreffen, zumindestens hier nicht.

Vielleicht ein AVM-Problem? Oder deines eingesetzten Edgemax-Router?

Gruß

fdi

muc80337_2 · ‎08.06.2019

@meyergru21 schrieb:

Offenbar bin ich nicht der einzige, ich habe etliche Threads mit ähnlichen Symptomen gefunden, z.B.:

https://www.ip-phone-forum.de/threa...dstream-möglich-mobil-d2-funktioniert.294647/

Das Symptom ist, dass eingehende Telefonate an einem Telekom-VoIP-Anschluß direkt bei Annahme abbrechen, während ausgehende Telefonate an die gleiche Rufnummer einwandfrei funktionieren. Das tritt aber nur in bestimmten Konstellationen auf.

Im verlinkten Thread ist es so, dass Anrufe aus manchen Netzen die Ansage erhalten "Die gewählte Rufnummer ist ungültig. "

Davon hast du nichts geschrieben. Ist das bei Dir auch so?

Falls es bei Dir diese Ansage nicht gibt dann wäre mein Anfangsverdacht, dass das Problem von irgendeiner Änderung im Edgemax ER-4 kommt. Gab es da eine?

Sherlocka · ‎08.06.2019

@meyergru21

wenn man alleine durch die Änderung von Einstellungen in einem Gerät eine Funktion wieder herstellen kann, dann liegt das an den Einstellungen in dem Gerät, weil es die Software dieses Gerätes zu braucht.

Also ist die Ursache entweder in nicht optimalen Einstellungen oder in der Firmware des Gerätes zu suchen. Also dürfte das insbesondere für Fritzbox-Inhaber interessant sein, also für Kunden von AVM, welche eine FB hinter einem andern Router einsetzen.

Es ist toll, dass du deine Lösung anderen hier im Forum zur Verfügung stellst. Damit andere mit einem ähnlichen Problem auch den Versuch wagen können, wie sie etwas bei sich anpassen können.

Und es wäre sinnvoll, das so auch AVM mitzuteilen, dass du diesen Zusammenhang festgestellt hast. Falls das bei AVM noch nicht bekannt ist, können sie das verifizieren und dann auch mit anderen Betroffenen teilen. Und möglicherweise sogar eine Firmwareanpassung vornehmen, dass dieses Problem künftig nicht mehr auftritt oder abgemildert wird. Denn AVM ist für den Inhalt der Firmware der Fritzboxen verantwortlich, nicht die Telekom.

Router müssen sich immer an den Anschluss anpassen und nicht umgekehrt der Anschluss an den Router. Umgekehrt auch weniger sinnvoll, an welchem Router soll sich denn dann die Telekom orientierten: an Fritzboxen, an Speedports, TP-Links und so weiter. Jeder Routerhersteller würde dann für sich in Anspruch nehmen wollen, dass man seine Router als Basis nehmen soll, und die anderen Routerhersteller hätten sich dem anzupassen. Was dann die anderen Routerhersteller dann davon halten werden?

Ich sehe also nicht, was die Telekom hierbei ändern müsste. Entwickeln sich Anschlüsse weiter, weil sich die Technik weiter entwickelt, dann werden in einem zweiten Schritt die nutzenden Geräte sich anpassen müssen, oder sinnlos werden, also dann zur Konkurrenz, ... .

viper.de · ‎08.06.2019

Ich hatte ähnliche Phänomene beim Betrieb einer FB7490 hinter verschiedenen Gateways. Die Fritzbox war ursprünglich der DSL Router. Ohne Änderungen an der SIP Konfiguration funktionierte die Telefonie hinter einem Speedport Smart3 einwandfrei, im Zusammenspiel mit einem Speedport Pro nicht. Des Rätsels Lösung war, den Intervall für das Offenhalten der NAT Tabellen runterzusetzen. Einen STUN Server habe ich nicht eingetragen. Telefonnummern sind mit Anbieter Telekom eingerichtet. Lag hier also eindeutig an der Router Firmware.

Ergänzung: Firmware des Speedport Pro, nur um Missverständnissen vorzubeugen

fdi · ‎08.06.2019

Da stimme ich @viper.de voll zu, man muss im Router auf die Konfiguration des Outbound-NAT achten und auch das Keep-Alive in dem Telefongerät richtig einstellen, damit die notwendigen Ports und States von "innen" her offen gehalten werden..

aluny · ‎08.06.2019

@meyergru21

@Sherlocka Danke für den Ping

Es kommt hier darauf an, wie die Telefonie eingerichtet wird,

Ich musste bisher den STUN nicht manuell eintragen, das hat schon die 7390 bei Konfiguration als "Telekom" von ganz alleine getan, wie man auch hier im Bild sehen kann.

Ich habe das eben auch nochmal an meiner 7580 (Client hinter der 7590) nachgestellt und dort die Telefonie als "Telekom" eingerichet.

Nach Wechsel auf "anderer Anbieter" ist der STUN auch dort schon eingetragen und es muss nur das "Register Fetch" noch gesetzt werden.

meyergru21 · ‎08.06.2019

Interessant, dass STUN teilweise schon automatisch bei einer Fritzbox eingetragen wurde. Bei mir war das nicht der Fall, das ist eventuell von der Firmware-Version abhängig. Es könnte sein, dass bei der Umstellung auf einen anderen Router die Telefonie-Einstellungen nicht angepasst werden - eventuell ist der Default für STUN ja abhängig vom Internet-Modus und wird nachträglich nicht geändert, wenn man den umstellt.

Mein Router ist sicher nicht das Problem, und auch nicht die Frage, ob oder wie lange die Fritzbox den Port offen hält, da ich manuell auf die RTP-Ports und den SIP-Port ein Port-Forwarding eingestellt habe - die Ports sind IMMER offen. Wie gesagt, das funktionierte seit Jahren auch ohne Probleme. Erst Umstellungen der Telekom haben es verursacht und ich kann es durch Veränderung einer einzelnen Einstellung (nämlich STUN) vollständig beheben, da bleibt nicht viel Interpretationsspielraum.

Dass bei jemand anderem die Eintragung nicht notwendig ist, ist kein Indiz dafür, dass ich nicht richtig liege: Wie ich schon schrieb, verschlimmerte sich das Problem über die letzten 6 Wochen immer mehr - bei mir waren zuerst nur Verbindungen betroffen, die von einem bestimmten VoIP-Gateway der Telekom kamen, jetzt alle.

Es ist ziemlich wahrscheinlich, dass die VoIP-Gateways den regionalen Bereichen zugeordnet sind. Es kann also gut sein, dass jemand in Hamburg das Problem nicht hat, während es in München auftritt.

muc80337_2 · ‎08.06.2019

@meyergru21

Ich würde mich wirklich sehr freuen, wenn Du meine essentielle Frage beantworten würdes, ob das bei Dir so ist wie im von Dir verlinkten Thread mit der Ansage.

Es stellt ein vollkommen anderes technisches Szenario dar wenn besagte Ansage generiert wird als wenn der Call aufgebaut wird und dann abbricht.

@meyergru21 schrieb:

Mein Router ist sicher nicht das Problem,

Eine sehr gewagte Aussage.

meyergru21 · ‎08.06.2019

@muc80337_2 schrieb:
@meyergru21
Ich würde mich wirklich sehr freuen, wenn Du meine essentielle Frage beantworten würdes, ob das bei Dir so ist wie im von Dir verlinkten Thread mit der Ansage.
Es stellt ein vollkommen anderes technisches Szenario dar wenn besagte Ansage generiert wird als wenn der Call aufgebaut wird und dann abbricht.

@meyergru21 schrieb:
Mein Router ist sicher nicht das Problem,
Eine sehr gewagte Aussage.

1. In dem Thread ist weiter hinten ein Posting von jemand, der genau mein Problem beschreibt. In anderen Quellen habe ich das auch mehrfach beschrieben gefunden.

2. So gewagt finde ich die Aussage nicht, wenn das in der Konstellation seit Jahren funktioniert und erst jetzt ohne Änderungen meinerseits nicht mehr und ich durch Änderung einer einzigen Einstellung am VoIP-Endgerät das Problem nach Belieben auftreten oder verschwinden lassen kann.

3. Wenn Du das Problem nicht hast und/oder die Lösung Dir nicht weiterhilft, dann ist ja alles gut

muc80337_2 · ‎08.06.2019

@meyergru21 schrieb:

1. In dem Thread ist weiter hinten ein Posting von jemand, der genau mein Problem beschreibt. In anderen Quellen habe ich das auch mehrfach beschrieben gefunden.

Bringt es Dich echt fast um kurz zu schreiben "Ja, bei meinen Anrufern kommt auch diese Ansage" oder "Nein, in meinem Fall kommt keine solche Ansage"?

Mir ist es immer noch nicht klar wie das in Deinem Fall ist.

meyergru21 · ‎08.06.2019

Übrigens: Ich halte das nicht für ein Problem von AVM, sondern um eins der Telekom:

Ich gebe zu, dass formal korrekterweise das VoIP-Gateway seine eigene IP übermitteln muss. Weil das aber so oft schiefgeht, macht man das heutzutage anders (und die Telekom hat es ja auch bislang gekonnt). Ich selbst betreibe ein VoIP-Gateway und auch das beherrscht die Erkennung der Absende-IP im SIP-Register-Call, weil es einfach viel unproblematischer ist.

Es ist zumindest überraschend, wenn ein solcher Rückschritt auf Seiten der Telekom passiert - damit rechnet halt niemand.

meyergru21 · ‎08.06.2019

Wie ich schrieb: Auf meiner Seite wird der Anruf beim Abheben abgebrochen, der Anrufer bekommt keine Ansage, es wirkt so, als ob ich den Anruf ablehne - was ja auch so ist: In dem Augenblick, wo ich abhebe, wird eine RTP-Verbindung versucht, die fehlschlägt.

muc80337_2 · ‎08.06.2019

@meyergru21 schrieb:

Wie ich schrieb: Auf meiner Seite wird der Anruf beim Abheben abgebrochen, der Anrufer bekommt keine Ansage, es wirkt so, als ob ich den Anruf ablehne - was ja auch so ist: In dem Augenblick, wo ich abhebe, wird eine RTP-Verbindung versucht, die fehlschlägt.

Also nicht wie im von Dir eingangs verlinkten Thread. Dort vermute ich das Problem auf Telekomseite.

D.h. ich bin mir fast sicher, dass das Problem bei Dir nicht von der Telekom verursacht wird sondern

entweder durch eine unbemerkte Änderung in Deinem Gateway
oder durch eine unbemerkte Änderung in Deiner Fritzbox

viper.de · ‎08.06.2019

Naja, wenn das Problem durch Aktivieren von STUN behoben wird, dann sieht es eher nicht nach Fehlkonfiguration aus. Allerdings schreibt AVM auch in der knowledebase beim Betrieb hinter einem anderen Router solle STUN genutzt werden, vermutlich genau aus dem Grund, dass manche VoIP Gateways nicht auf die Source IP schauen sondern in den Header.

Wobei, dann gibt es ja auch noch die sip alg, die genau dort rumfummeln.

meyergru21 · ‎08.06.2019

@muc80337_2 schrieb:
@meyergru21 schrieb:
Wie ich schrieb: Auf meiner Seite wird der Anruf beim Abheben abgebrochen, der Anrufer bekommt keine Ansage, es wirkt so, als ob ich den Anruf ablehne - was ja auch so ist: In dem Augenblick, wo ich abhebe, wird eine RTP-Verbindung versucht, die fehlschlägt.
Also nicht wie im von Dir eingangs verlinkten Thread. Dort vermute ich das Problem auf Telekomseite.

D.h. ich bin mir fast sicher, dass das Problem bei Dir nicht von der Telekom verursacht wird sondern
entweder durch eine unbemerkte Änderung in Deinem Gateway
oder durch eine unbemerkte Änderung in Deiner Fritzbox

Welche Änderung sollte das sein? Insbesondere, wenn:

1. Ich keine Änderung vorgenommen habe, weder am Router noch an der Fritzbox.

2. Die Probleme bei manchen Typen von Anrufen auftreten, bei anderen nicht und diese sich über die Zeit verändert haben? Ich konnte übrigens durch Beobachten der Log-Einträge sehen, dass bestimmte VoIP-Gateway-IPs der Telekom für Anrufe aus bestimmten Netzen benutzt werden. Die Aurufe, die von O2 kamen, gingen zu Beginn der Probleme immer schief, jetzt sind mehr (oder alle) Gateways betroffen.

3. Ich das Problem durch die Änderung einer einzigen Einstellung beseitigen kann, die sich noch dazu in Bezug auf MEIN beobachtetes Problem absolut logisch erschließt? Occams Razor ist Dir ein Begriff?

Wie ich schon schrieb: Ich betreibe selbst einen SIP-Service, der hatte niemals dieses Problem, weil er wie gesagt, die gemeldete IP im SIP Register immer durch die Absende-IP ersetzt. Ich behaupte ferner, dass mit an Sicherheit grenzender Wahrscheinlichkeit die Telekom das früher auch so gemacht hat und jetzt nicht mehr tut. Das erzwingt die Nutzung eines STUN Servers, wenn das VoIP-Endgerät nicht identisch mit dem Router ist.

Schön, wenn AVM das teilweise richtig macht, bei mir war es nicht so, was mit der Historie der Einstellungen zusammenhängen kann.

Das Problem wäre aber ohne die Änderung bei der Telekom sicher nicht entstanden.

muc80337_2 · ‎08.06.2019

Manchmal geht halt auch ohne aktives Eingreifen mal was schief.

Interessant wäre es wenn Du der 7390 ein Werksreset (oder noch besser: eine Recovery) verpassen würdest und dann hinterher schauen würdest, was die Box einrichtet für eine Telekom Rufnummer. Ob da der STUN dann belegt ist oder nicht.

Bei mir in der Fritzbox 7590 unter 7.10 ist der STUN-Server stun.t-online.de automatisch eingetragen bei Auswahl des Anbieters Telekom.

Bei meinem Vater in der 7390 auch - allerdings ist dort nicht "Telekom" ausgewählt sondern tel.t-online.de* (und ich bin mir gerade nicht sicher, ob das eine von mir manuell angelegte Konfiguration ist oder ob die von AVM so hinterlegt wurde)

meyergru21 · ‎08.06.2019

@muc80337_2 schrieb:
Manchmal geht halt auch ohne aktives Eingreifen mal was schief.

Interessant wäre es wenn Du der 7390 ein Werksreset (oder noch besser: eine Recovery) verpassen würdest und dann hinterher schauen würdest, was die Box einrichtet für eine Telekom Rufnummer. Ob da der STUN dann belegt ist oder nicht.

Bei mir in der Fritzbox 7590 unter 7.10 ist der STUN-Server stun.t-online.de automatisch eingetragen bei Auswahl des Anbieters Telekom.
Bei meinem Vater in der 7390 auch - allerdings ist dort nicht "Telekom" ausgewählt sondern tel.t-online.de* (und ich bin mir gerade nicht sicher, ob das eine von mir manuell angelegte Konfiguration ist oder ob die von AVM so hinterlegt wurde)

Das mit dem Werksreset hatte ich nicht gemacht, nur die Übernahme von der 7390 auf die 7490, was zur Folge hatte, dass die Warnung mit den "nicht vorgesehenen Einstellungen" nicht mehr kam. Ich nehme aufgrund der Postings hier jetzt an, dass das zumindest bei aktuellen Firmwareversionen eventuell schon klappen würde. Die 7390 hatte noch 6.85, was aktuell die neuste ist, aber die Konfiguration schleppt sich inzwischen schon von 5.x durch.

tel.t-online.de würde mit Sicherheit nicht funktionieren, ich nehme mal an das war eine individuelle Konfiguration:

#stunc stun.t-online.de
STUN client version 0.97
Primary: Independent Mapping, Port Dependent Filter, preserves ports, no hairpin
Return value is 0x000017

#stunc tel.t-online.de
STUN client version 0.97
Primary: Blocked or could not reach STUN server
Return value is 0x00001c

muc80337_2 · ‎08.06.2019

Sieht so aus (und funktioniert)

Ich hatte mit meiner damaligen 7490 auch schon irgendwann mal ein Konfigurationskuddelmuddel. Schlich sich vermutlich bei einer Labor-FW ein.

Glücklicherweise lässt sich ja das Telefonbuch separat sichern.

Dann die Recovery drüber und zu Fuß neu eingerichtet. Das gesicherte Telefonbuch konnte ich ja einlesen.

Dann lief es wieder.

meyergru21 · ‎09.06.2019

Ja, klar, stun.t-online.de als STUN server geht, nur tel.t-online.de wäre nicht nutzbar. Solange man keine vorgeschalteten Router hat oder an VoIP-Gateways hängt, die noch auf dem alten Stand sind, ist's ja auch kein Problem.

Beim mir wär's mehr als das Telefonbuch: mehrere SIP-Provider und etliche Telefoniegeräte, weshalb ich den Aufwand der Neueinrichtung gescheut habe...

muc80337_2 · ‎09.06.2019

@meyergru21 schrieb:
Beim mir wär's mehr als das Telefonbuch: mehrere SIP-Provider und etliche Telefoniegeräte, weshalb ich den Aufwand der Neueinrichtung gescheut habe...

Bei mir war es auch sehr viel mehr als nur das Telefonbuch.

Aber wenigstens musste ich das Telefonbuch nicht alles neu eintippen.

"Dumme" neue alte Probleme bei VoIP

Social Media