VoIP Telefon funktioniert nicht richtig

E

edlomprul

Well-Known Member
Guten Tag,

ich habe bei meinen Eltern im Zuge der Umstellung auf splitterloses DSL (von der Telekom) ein Snom M9R VoIP DECT Telefon aufgestellt.

Das funktioniert aber nicht richtig:

Ausgehende Anrufe funktionieren immer, brechen aber oft nach ziemlich genau 15min ab.
Eingehende Anrufe funktionieren nur manchmal, ich habe keine Ahnung, unter welchen Umständen.

Die Zugangsdaten müssen korrekt sein, weil ich sonst ja gar nicht telefonieren könnte. Einen STUN Server (von der Telekom natürlich) habe ich eingetragen.
Ich habe auch testweise schon einmal diverse Ports zum Snom weitergeleitet. Das habe ich inzwischen wieder rausgenommen, bin mir aber nicht sicher, ob es eine Verbesserung gebracht hat oder nicht. Eher nicht. Ich kann halt auch nicht immer neben dem Telefon warten und gucken, wer wann anruft und in welchem Zustand das Netzwerk/Telefon/VoIP Gerät gerade ist.

Vielleicht ist das ein bekanntes Problem oder es gibt übliche Vorgehensweisen.

Mutti dreht durch und würde am liebsten meine ganzen Geräte gegen einen Speedport von der Telekom austauschen lassen. :)
 
Hi,

wie viel Bandbreite habt ihr denn?

Was für einen Router verwendest du momentan? Kannst du evtl. mal mitschneiden was das VoIP Telefon macht und dann schauen ob da etwas "auffällig" ist? Hast du irgendwelche auffälligen Paketfilterregeln?

Hat es im lokalen LAN eine feste Addresse oder bekommt es eine per DHCP?

Laufen, wenn die Gespräche abbrechen noch irgendwelche anderen Rechner und machen periodisch irgend etwas? (z.B. ein Cron-Job der Automisch alle 15 Minuten irgendwelche Dateien hochlädt und dem VoIP dann für wenige sekunden die Leitung so "dicht" macht das das Gespräch abbricht?

Evtl. mal IPv6 an/auschalten?

Kann mann bei dem Telefon evtl. die MTU einstellen? AFAIK kommt VoIP manchmal nicht damit zurecht, wenn Pakete vom router gestückelt werden müssen?

Hast du mal auf dem STUN Server (Oder, wenn der nicht antwortet auf irgend etwas was Netztechnisch in der nähe ist) nen dauer-ping (o.ä.) laufen lassen und mal geschaut ob da etwas auffällt, z.B. wärend ein Gespräch läuft oder wenn es abbricht?
 
DSL 6000 RAM (mehrere Stichproben ergaben mindstens 6000kbits/s down und >1000kbits/s up)

TP-Link TL-WR1043N v1 mit OpenWRT

Ich habe BISHER noch nichts mitgeschnitten, ich habe gerade gesehen, dass das Snom selbst sogar so eine Funktion hat. Ich werde das machen, sobald ich wieder vor Ort bin.

Ich habe gar keine besonderen Filterregeln eingestellt, alles ist auf OpenWRT Standard.

Sämtliche fest installierte Geräte (Switch, Router, VoIP Telefon, Workstation usw.) haben eine feste IP Adresse, es gibt aber einen DHCP für "Laufgeräte".

Nein, es laufen in dem Netzwerk keine derartigen Automatismen. Es wird sicherlich manchmal gleichzeitig gesurft und telefoniert, aber auf keinen Fall werden größere Daten hochgeladen.

IPv6 könnte ich am Router einschalten. Ist aber aus.

Ich habe keinen Dauerping laufen lassen, werde das aber auch machen, wenn ich vor Ort bin.

Es ist ja auch komisch, dass es wirklich ziemlich genau 15min eines Gesprächs sind. Und wenn ich so etwas in Google eingebe, gibt es auch andere Leute die ein ähnliches Problem haben. Aber ich habe leider keine Lösung gefunden.

Ich verstehe auch nicht, welche Ports ich für Versuche forwarden soll:
http://hilfe.telekom.de/hsp/cms/con...82239611/IP-basierter-Anschluss/faq-350884716

Das sind imho ziemlich viele für diesen einen Service.


Kann mir vielleicht auch mal einen in einem Satz erklären, was ein STUN Server überhaupt macht.
Was ich glaube: Technik, die nicht nur für VoIP einsetzbar ist, sondern allgemein. Damit umgeht man die Notwendigkeit Ports weiterzuleiten. Ist also eine "Komfortfunktion" für Fälle in denen eine Portweiterleitung nicht realisiert werden kann.
 
edlomprul schrieb:
Ich habe gar keine besonderen Filterregeln eingestellt, alles ist auf OpenWRT Standard.
Zum Vergrößern anklicken....
Frage an alle: Wie ist auf OpenWRT eigentlich der Timeout für dynamische Firewall- oder NAT-Regeln? (Aber eigentlich darf da nichts dichtmachen, solange es noch Traffic gibt.)
edlomprul schrieb:
Ich verstehe auch nicht, welche Ports ich für Versuche forwarden soll
Zum Vergrößern anklicken....
Was Du an den Apparat forwarden mußt, sind die eingehenden UDP-Ports. Die Hilfeseite der Telekom macht da einige Vorschläge, aber wirklich klarstellen kannst Du das nur aus der Dokumentation des Telefonapparats. Du könntest vielleicht auch mit Kanonen auf Spatzen schießen und unter der Annahme, daß kein anderes Gerät im Netzwerk überhaupt von UDP-Verbindungen Gebrauch macht, alle (0-65535) UDP-Ports ans Telefon forwarden.
Du könntest auch auf einem Laptop mal ein SIP-Programm installieren, die Zugangsdaten eintragen und damit mal 15 min lang telefonieren, mit und ohne Port-Forwarding auf dem Router. Das SIP-Programm horcht natürlich i. a. auf anderen UDP-Ports als der Telefonapparat, und das ist auch wünschenswert, damit sich beide nicht gegenseitig in die Quere kommen.
edlomprul schrieb:
Das sind imho ziemlich viele für diesen einen Service.
Zum Vergrößern anklicken....
Zwei oder drei sollten immer reichen, aber die Telekom kann natürlich keine allgemeine Aussage über alle SIP-Telefone dieser Welt machen.
edlomprul schrieb:
Kann mir vielleicht auch mal einen in einem Satz erklären, was ein STUN Server überhaupt macht.
Zum Vergrößern anklicken....
Ein Client schickt ein einfaches, kleines Paket mit der Frage: "Unter welcher IP-Adresse siehst du mich?" Und der STUN-Server antwortet: "Ich sehe dich unter 123.45.67.89." Das ist ggf. die IP-Adresse Deines Routers.
Das Problem der Port-Weiterleitung ist davon unabhängig und alleinige Aufgabe Deines Routers. Wenn sie statisch eingestellt ist, funktioniert es am zuverlässigsten, aber ordentliche Router erlauben auch dynamische Regeln: Auf irgendeine Weise (wie?) wird der Router instruiert, einen bestimmten Port vorübergehend an Gerät X weiterzuleiten; danach vergißt er diese Regel wieder, normalerweise nach Ablauf eines Inaktivitäts-Timeouts.
 
Naja ich kann beim Snom schon einen Port einstellen:

"SIP client Port (z.B. 5060): "
Den hab ich auf 5060 gestellt. Da steht aber auf der Telekom Seite, dass dieser ein ausgehender Port sein soll.
Mir ist schon klar, dass die Telekom das nicht von jedem SIP Phone wissen kann. Aber das ist doch dort nicht eindeutig geschrieben. Was soll den bitte der Hinweis bringen, dass gefühlte 10% aller verfügbaren Ports für eine Weiterleitung in Frage kommen, sie aber nicht wissen, welche...................
 
edlomprul schrieb:
"SIP client Port (z.B. 5060): "
Den hab ich auf 5060 gestellt. Da steht aber auf der Telekom Seite, dass dieser ein ausgehender Port sein soll.
Zum Vergrößern anklicken....
Das sollte unabhängig voneinander sein. Es kann 5060 sowohl als eingehender als auch als ausgehender fungieren. Mach doch mal im Router eine feste Weiterleitung von UDP 5060-5062 an das Telefon, wenn Du das noch nicht hast. (Es kann sein, daß das Telefon bei Verbindungsproblemen auf 5060 einfach den nächsthöheren Port nimmt, daher besser drei Ports festlegen.)
Bzgl. Dokumentation auf den Telekom-Webseiten hast Du recht, aber wir können schon froh sein über das, was wir kriegen. Die Telekom ist da bei weitem nicht die schlechteste Firma. (Und bei vielen Heimanwendern spielt es keine Rolle, wenn sie 10000 Ports forwarden, weil nicht viele Programme Gebrauch von UDP machen: DNS, VoIP, Streaming ...)
 
3D Shooter setzten eigentlich alle auf UDP.

Edit:
Post 10^4 habe ich mir irgendwie spannender vorgestellt.
 
Praktisch alle Echtzeitspiele benutzen UDP. Da ich selbst aber kein Gamingserver hoste, wäre das auch kein Problem.

Im übrigen hat sich zwischenzeitlich das Problem "gelöst":
In den meisten Fällen funktioniert das Telefon jetzt, alle paar Wochen gibts wieder mal Probleme aller Art und random (Inbound/Outbound Calls, kein Sound, Gesprächsabbrüche nach bestimmter Zeit).
Momentan isses mal wieder so, dass Gespräche entweder nach 7,5 oder 15 oder 30 Minuten einfach abgebrochen werden. In zufälliger Reihenfolge, also keine Reihe wie bei IQ Tests erkennbar (huehuehue).
Mir persönlich ist auch in den PCAP Logs nichts aufgefallen (keine schwarzen Felder bezüglich Erreichbarkeit).
Ob mit oder ohne STUN, es macht keinen Unterschied. Überhaupt habe ich an den Einstellungen, die imho richtig waren/sind (oder auch nicht) in den letzten Monaten keine Änderungen vorgenommen.

Es ist ja eh so, dass die Telekom in den letzten sechs Monaten erhebliche Probleme bezüglich VoIP hatte. Mich hat das Thema auf jeden Fall EXTREM viele Nerven gekostet. Zumindest kann Mutti inzwischen halbwegs vernünftig telefonieren. (meistens)


Und jetzt ist es so, dass ich den Scheiß auch bei mir daheim einführen muss (!). Dumm nur, dass meine PF Firewall erstmal jeden Outbound Traffic blockiert. Und die RTP Ports bei VoIP sind ja scheinbar zufällig.
Ohne Witz, kann mir mal jemand eine gute Quelle (oder ein Buch) empfehlen, in dem die gesamte VoIP Technik detailgenau erklärt wird. Ich steig echt nicht durch, diese Technik ist das schlimmste was ich jemals bezüglich Netzwerktechnik erlebt habe. Nicht nur die Ports scheinen random zu sein, auch die Auswirkungen diverser Einstellungen an Clients und Firewall. Ich dreh noch durch.

Wie haltet ihr das denn mit euren Voip? Soll ich jetzt jedes VoIP Phone als exposed Host hinstellen oder was?
 
Bei mir hockt VoIP in seiner eigenen DMZ und darf nur mit dem Telekom-Netz reden.

Und ja, die Leute, die SIP und STUN und den ganzen Dreck verbrochen haben, gehören eingewiesen.
 
Also es SCHEINT zu funktionieren bisher, mit neuer Konfiguration.
Funktionieren heißt:
- ausgehende Anrufe
- eingehende Anrufe
- Ton beidseitig
- kein knacksen im Ton
- Gespräche bis mind. 2min möglich, länger nicht getestet.


Wenn ich morgen früh wieder nen Testlauf mache, OHNE vorher irgendwas aus- und einzuschalten und es funktioniert IMMER noch, bin ich zuversichtlich, dass ich zu des Pudels Kern vorgedrungen bin. Ich weiß zwar immer noch nicht, warum das so ist, und ich verstehe wenn ich ehrlich bin auch die entsprechenden Regeln nicht (ich verstehe, was sie machen, aber nicht warum ich sie brauche).

Berufen habe ich mich auf folgende kleine Anleitung:
http://www.cryptednets.org/openbsd-pf-and-voice-over-ip/

Viele andere Anleitungen, die vor allem das "Spezial-NAT" nach draußen nicht beinhalten sind alle kläglich gescheitert.
Natürlich musste ich die Regeln auf die neue PF Syntax ummünzen, was kein Problem war.

Auf
https://en.wikipedia.org/wiki/List_of_SIP_software#Enabled_firewalls
steht ja auch, dass unter anderem PF diese Spezialbehandlung beherrscht. Weiß der Geier, warum man die braucht. Was auf keinen Fall funktionierte, was aber ca. 90% der Anleitungen (nicht nur speziell PF) sagen: "Portforwarding auf dies und jen Port und das passt". Nein es passt nicht, es funktioniert einfach nicht...



Es gibt scheinbar andere Lösungen, die mir sogar noch lieber wären:
Einen SIP Proxy aufsetzten. OpenBSD bietet ein Paket von siproxd an. Ich kann den anscheinend aber nicht benutzen weil mein (imho Hardcore-)VoIP Telefon Snom 715 keine "Domain" parametrieren kann, was auch immer ne Domain in dem Zusammenhang ist. Ich kann mich dann auf jeden Fall auf Grund der fehlenden Domain nicht mehr registrieren.

Ein https://en.wikipedia.org/wiki/Back-to-back_user_agent stand auf ner OpenBSD Mailingliste auch mal zur Debatte, da kapier ich leider gar nicht, was der macht, noch finde ich ein entsprechendes Paket für OpenBSD.


Mind. 6h Arbeit und rumgetüfftel, jetzt gehts vielleicht, schlauer als vorher bin ich immer noch nicht.
 
Kleiner Rant gefällig?

Mit Jabber sieht es auch kaum besser aus. Da liegen die Probleme auf einer höheren Ebene, nämlich im XMPP-Kommunikationsprotokoll mit seinen unzähligen Variationsmöglichkeiten. Und in SIP werden gerne Standard-inkonforme Erweiterungen benutzt, um die ganzen Unzulänglichkeiten zu umgehen. Das bringt natürlich noch mehr Probleme mit sich. Kein Wunder, daß die Anbieter reihenweise dichtmachen! Sowohl mein SIP-Provider (www.fahr-telecom.de) als auch mein Jabber-Provider (web.de aka United Internet) haben gegen Ende des Jahres den Dienst eingestellt, und bisher kämpfe ich noch, für beides eine gut funktionierende Kombination von Dienstanbieter und Client-Software zu finden, letztere möglichst auch in FreeBSD. Fast alle meine Freunde nutzen mittlerweile Skype oder Viber und haben nur noch aus Mitleid mit mir einen Jabber-Client installiert, meistens mit Google-Account. Und weil Google seit kurzem für seine Google-Talk-Kunden jegliche Kommunikation mit Jabber-Adressen außerhalb von Google blockiert, dürfte sich das Thema endgültig erledigt haben.
SIP hat keiner außer mir je genutzt, kein Wunder, und ich folglich nur zwecks Verbindungen ins normale Telefonnetz. Das würde ich auch gerne über XMPP machen, aber da gibt es ja keinen einzigen Provider außer Google Talk.

Ja, ich habe nun auch einen Skype-Account. Zumindest für den Kostenlos-Teil. Geld werden die an mir keins verdienen.
 
Was ich zu pf sagen kann und was bei mir augenscheinlich mit einem Hardware-VoIP-Adapter funktionierte:

Ausgehend 5060/udp per "static-port" NATen, damit der Source-Port erhalten bleibt. 5060/udp eingehend normal mit rdr reinleiten. Traffic vom VoIP-Adapter zum SIP-Server/-Netz einfach komplett erlauben.

Damit hatte ich eigtl keine Schmerzen.
 
TCM:
Ja, du machst das scheinbar richtig. Die static-port Nuss scheint mein Problem gewesen zu sein. Der Rest ist dann natürlich auch genau so wie bei dir. Ich habe leider sehr lange gebraucht, bis ich herausgefunden habe, wie ich es machen muss.
Wie würdest du das ganze lösen, wenn du mehrere VoipTelefone hast? Ich hätte jetzt für jedes Phone den Inbound Port um 2 inkrementiert und eine entsprechende zusätzliche PF Regel geschrieben. Das funktioniert aber scheinbar nicht perfekt, es klingelt nämlich immer nur auf einem Telefon. Glücklicherweiße dem wichtigsten. Kann aber natürlich auch sein, dass das wiederum dann an der entsprechenden Client Software liegt.
Wenn du dazu nichts gutes mehr zu sagen hast, ist mir des jetzt echt scheißegal, was für ein großer Haufen Mist. Ne Freundin meinte gerade "hm du kennst dich doch sonst so mit Computern und so aus. Und dein Telefon kriegst nicht zum laufen??"


Tronar:
Meh, sowas wollt ich jetzt eigentlich gar nicht hören. Mein Smartphone ist weitgehend Closed Source App frei, das wollte ich so lassen, am Desktop siehts genau so aus. Und die XMPP Krankheit habe ich (natürlich) auch. Die ganzen Clients und die RFCs miteinander zu vergleichen und abzustimmen (über diverse Plattformen hinweg) ist irre. Inzwischen habe ich mich drauf eingeschossen, dass ich nur Messaging und Carbon brauche. Bescheuerte Bildchen schicken geht halt dann nicht. Für manche war das das Ausschlusskriterium: "Nein, dann musst du dir Whatsapp zulegen".... Ehrm.. nö ><
 
Bei mehreren Clients auf jeden Fall einen lokalen Asterisk o.ä. PBX. Das steht bei mir auch schon ewig auf der TODO-Liste.
 
Kurz zum Klingeln auf nur einem Telefon unter der Annahme, dass beide dieselben Credentials verwenden: Das kann je nach Provider schon sein, obwohl es mich bei der Telekom ehrlich gesagt wundern würde. Aber bei der Anmeldung hinterlegt der Provider einen Kontakt in Form von IP-Adresse und Port und nicht jede Software kann oder will (Konfigurationssache) sich mehrere Kontakte merken. Insofern könnte Telefon 2 die Informationen von Telefon 1 überschreiben. Wenn das wichtigere Telefon auch noch ein geringeres Anmeldeintervall hat, erhöht das entsprechend die Wahrscheinlichkeit, dass es genau dort klingelt.

Zu verwendende RDP-Ports werden normalerweise im SIP-Dialog zwischen den direkt beteiligten Komponenten ausgehandelt. Das heißt zunächst, dass sie nicht völlig beliebig sind. Man kann sie also schon irgendwo im Endgerät konfigurieren, wenn man will (und die Verwaltungsoberfläche die entsprechende Option bietet). Das heißt aber auch, dass Ports unterwegs mal besser nicht umgeschrieben werden sollten, daher die Wichtigkeit von static-port, Teil 1. Teil 2: SIP selbst, hier Port 5060/5062. Wenn der Registrar den oben erwähnten Kontakt nicht an Details im SIP-Request festmacht, an der Stelle bin ich nicht sicher, könnte er einfach Informationen aus dem Socket nehmen. Nach NAT wäre dann zwar die IP-Adresse richtig, aber der Port falsch. Wenn dann jemand anruft, würde die Firewall artig ihren Job machen.
 
Danke für die Infos!

Zu den RTP Ports: Ja, die kann ich bei jedem meiner Clients beliebig konfigurieren. Ich habe danach auch brav die entsprechenden (UDP) Ports nach außen freigegeben in PF. Natürlich funktionierte gar nix und in Wireshark sah ich auch Ports komplett außerhalb der konfigurierten Range. Diese waren wirklich zufällig. Haufenweiße in PF geblockte Ports, rein zufällig. Habe später für die entsprechenden Hosts einfach den gesamten Outbound Traffic freigegeben, wie es halt jede andere Deppenfirewall auch macht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben