SIP (VoIP) Client Einrichtungs-Probleme auf Vserver

  • Hallo liebes Forum,

    hier kommt nun meine Frage - wer Ideen hat, woran es liegen könnte dann raus damit ;)! Ansonsten viel Spaß beim durchlesen!


    SIP was? Meinst du ZIP?

    Nein, ich meine schon SIP. SIP ist das Protokoll, welches z.B. für VoIP (also Internettelefonie) verwendet wird, um eine Verbindung, also Sitzung, mit dem SIP Server zu Beginnen. Die eigentlichen Gesprächsdaten werden dann via RTP bzw. RTCP übertragen. So gut wie jeder Telefonanbieter stellt nun nach der Umstellung auf IP-Anschlüsse SIP Server bereit. So leutet z.B. der SIP Server der Telekom tel.t-online.de.


    Okay, und was ist jetzt dein Problem?

    Es tut nicht :P. Nachdem ich einen Client auf dem Vserver eingerichtet habe, bekommt dieser immer einen Timeout bei der Verbindung mit dem entsprechenden SIP-Server.


    Hmmm, was genau tut also nicht?

    Um es einmal grob zu erklären, SIP läuft so ab:

    Client –––––––––––REGISTER––––––––––> SIP-Server

    //Zunächst schickt der Client ein REGISTER-SIP Paket an den Server, welcher die Logindaten prüft und dann...

    Client <––––––––––––––OK––––––––––––> SIP-Server

    //...mit einem "OK-SIP" Paket antwortet. Danach kann z.B. ein Anruf via INVITE-SIP Paket gestartet werden o.Ä.


    Diese Anmeldung müsste alle 300 Sekunden (bei der Telekom) wiederholt werden. Das Problem ist, dass der Vserver keine Antwort vom SIP-Server erhält. Ich habe dies sowohl auf dem Vserver als auch auf meinem lokalen PC mit Wireshark überprüft. So wird auf dem Vserver das REGISTER Paket angeblich versand, nur dann folgt keine Antwort - weshalb das Paket immer wieder geschickt wird, bis zum Timeout. Auf meinem lokalen PC wird das erste REGISTER Paket wegen falschen Format (liegt wohl am Client [Ekiga]) zurückgewiesen, worauf aber der zweite Einwählversuch erfolgreich ist. Somit scheit das Problem beim Weiter-Versand bzw. beim Empfangen des REGISTER Paketes zu liegen.


    Sicher, dass es daran liegt? Schon XY ausprobiert?

    So gut wie sicher. Ich habe schon...

    ...verschiedene Betriebsysteme probiert (Lubuntu 18.04 LTS, Debian 9)

    ...Firewall nochmals abgeschaltet (die war laut Iptables nie an)

    ...verschiedene Clients probiert (Linphone, Ekiga, Selbstgeschrieben [basierend auf libPjSIP], Twinkle)

    ...verschiedene Loginverfahren (mit und ohne STUN-Server) - sollte irrelevant sein, wenn man bedenkt, wofür STUN-Server da sind.

    ...verschieden SIP-Server (T-online direkt, oder Fritz!Box (auch Verschiedene) fürs Internet erreichbar geschaltet) - in allen Fällen funktionabel mit lokalem PC

    ...verschiedene Logindaten (T-online mit 2 Nummern ausprobiert)

    ...Support kontakiert: Ich denke dieser glaubt, dass der Fehler nicht bei Ihnen läge.

    ...VPN-Tunnel eigerichtet - diese hat aber glaube ich nicht die notw. Portweiterleitungen gehabt.


    Was hast du noch nicht versucht?

    Ich habe noch nicht...

    ...Windows mit MicroSIP

    ...Linux Mint wie auf meinem lokalen Büro-PC zu verwenden

    ...Vertrag kündigen und eigenen Server bauen

    versucht.


    Sonst noch was?

    -> Wir haben das Vserver Paket "VPS 500 G8".

    -> Da wir bei unseren Test-Systemen anfangs das selbe Problem hatten mussten wir bei der Firmen-Fritz!Box das Häkchen für "Nutzung von Internettelefonie aus dem Heimnetz unterbinden" entfernen - danach klappte die Kommunikation super.

    -> Das Problem ist nicht (unbedingt), dass der UDP Port XY geblockt ist, sondern, dass (so glaube ich) die Pakete mit SIP-Header nicht weitergeleitet / verworfen werden. Ggf. liegt dies auch an Netcups-Internet-Vertrag oder VM-Einstellungen...

    -> Ich würde das Netcup-Team bitten selbst einmal einen SIP-Client in eben einem solchen Vserver einzurichten - schafft ihr es? Und wenn ja WIE?

    -> Habt ihr dieses Problem auch gehabt und was habt ihr getan damit es nun tut? Laut Support gäbe es mehrere Kunden, welche VoIP auf Vservern nutzen würden!

    -> Die versandten REGISTER Pakete (zumindest das erste) ist sowohl auf dem Vserver also auch auf meinem lokalen PC nahezu identisch. Sie unterscheiden sich lediglich in zwei Bytes, ausglößt durch die verschiedenen IPs (denke ich).


    Soo, auf jeden Fall vielen Dank fürs Durchlesen! Da ich heute nicht auf der Arbeit bin, kann ich leider die Screenshots / Paketmitschnitte der REGISTER und Antwort Pakete der Systeme nicht mit anhängen.

    Viele Grüße,

    Simonmicro

  • So leutet z.B. der SIP Server der Telekom tel.t-online.de.

    So wird auf dem Vserver das REGISTER Paket angeblich versand, nur dann folgt keine Antwort - weshalb das Paket immer wieder geschickt wird, bis zum Timeout.

    Wenn ich es richtig verstehe und deute, versuchst du dich von deinem netcup VPS auf den SIP-Server der Telekom (tel.t-online.de) zu verbinden korrekt?


    So wird dies wahrscheinlich nicht funktionieren, da in der Regel auf dem Server tel.t-online.de keine Verträge laufen, die für die nomadische Nutzung freigeschaltet sind. Auch ein freundliches anklopfen auf Port 5060 mittels telnet zeigt eher, dass Verbindungen außerhalb des DTAG Netz nicht gewünscht ist (drop).


    Es gibt SIP-Trunk Anschlüsse/Verträge bei der Telekom wo die nomadische Nutzung funktioniert. Preislich aber nicht so wirklich attraktiv

  • twiddern Hmmm, guter Einwurf, aber warum klappt dann die Verbindung auf die vorbereiteten Fritz!Box-en nicht? Diese sind ja auch für nomadische Nutzung offen. Und zudem muss die Verbindung auf tel.t-online.de via UDP erfolden, da kann man via Telnet, welches TCP verwendet (https://de.wikipedia.org/wiki/Telnet) nix erreichen :/ - wahrscheinlich der Grund für den Drop. Und sollte die telekom nomadische Nutzung verbieten, warum wird dann nicht einfach "403 Forbidden" (oder so) geantwortet?

    Gruß,

    Simon

  • aber warum klappt dann die Verbindung auf die vorbereiteten Fritz!Box-en nicht? Diese sind ja auch für nomadische Nutzung offen.

    Vielleicht eine Einstellungssache? Dazu kenne ich das komplette Setup nicht. Die nomadische Nutzung ist immer vom Anbieter abhängig.

    Und zudem muss die Verbindung auf tel.t-online.de via UDP erfolden

    In der regel willst du deine SIP-Kommunikation über SIPS abwickeln, mittels TCP damit diese Daten wirklich "sicher" (verschlüsselt und garantiert mit TCP) ankommen. Die Sprache willst du aber später über (S)RTP abwickeln mit UDP.


    Und sollte die telekom nomadische Nutzung verbieten, warum wird dann nicht einfach "403 Forbidden" (oder so) geantwortet?

    In der Regel ist es beim 0815-Anschluss kein Vertragsbestandteil. Schau mal rein :S. Warum man nicht antwortet, naja um die Last zu reduzieren, jede Antwort benötigt Rechenpower und generiert Datenverkehr.

  • In der regel willst du deine SIP-Kommunikation über SIPS abwickeln, mittels TCP damit diese Daten wirklich "sicher" (verschlüsselt und garantiert mit TCP) ankommen. Die Sprache willst du aber später über (S)RTP abwickeln mit UDP.

    Wenn das mal so einfach wäre. :) Da ich inzwischen weg von meiner eigenen Lösung bin (zum Testen) verwende ich Ekiga, dieses versucht (so vermute ich) auch mal SIPS. However - verwende ich Ekiga von meinem lokalen, privaten PC, so verbindet es sich mit Telekom oder auch mir der anderen Fritz!Box der Firma...

  • So wird dies wahrscheinlich nicht funktionieren, da in der Regel auf dem Server tel.t-online.de keine Verträge laufen, die für die nomadische Nutzung freigeschaltet sind. Auch ein freundliches anklopfen auf Port 5060 mittels telnet zeigt eher, dass Verbindungen außerhalb des DTAG Netz nicht gewünscht ist (drop).

    tel.t-online.de ist außerhalb des DTAG Netzes nicht erreichbar (t-dialin / t-ipconnect).

    Weiterhin wird tel-t-online.de unverschlüsselt über UDP angesprochen.


    Du brauchst einen SIP-Trunk der öffentlich erreichbar ist. Z.B. sipgate (näheres gerne über PN)

    Bei VPN brauchst du ein äußerst sauberes NAT, und da darf kein Speedport im Weg hängen.


    Ist ja schön, dass du uns SIP erklärst...

  • H6G Wow. Kaum SipGate eingerichtet und tada! Alles funktioniert. Ich entschuldige mich bei allen Netcup Mitarbeiter, welche wir / ich genervt haben! Ich hatte nicht erwartet, dass die Telekom uns da nochmal so viel Ärger macht. Zugegebenermaßen der Support von deren Seite war wohl so inkompetent, dass er uns nicht mit dieser Info versorgen konnte. Aua. Und ja durch eigenes Googlen hätte man es vlt. finden können - aber ich hatte erwartet, dass der Telekom-Telefon-Support uns dies hätte mitteilen können.

    Dennoch danke!

  • Hay,


    sorry, war in Projekten die letzten Woche :) (und bin's noch).


    tel.t-online.de ist außerhalb des DTAG Netzes nicht erreichbar (t-dialin / t-ipconnect).


    Das ist absolut richtig. Sobald man das Netz der Telekom verlässt (je nach Vertrag reicht dafür auch schon der Hausanschluß) gibt es keine Connection zur Telekom über VoIP. Ich habe zwei Beinchen ins Internet, eines geht zur Telekom, eines geht über Wifi zu einem anderen Anbieter. Der SIP-Account der Telekom funktioniert nur über das DSL der Telekom, mit derselben Kombination über den anderen Provider geroutet klappt das nicht.


    Ein anderes Zeichen, dass die Accounts Telekom-gebunden sind: In der Fritzbox reicht es neben den normalen Anschlußdaten für DSL (wenn man das überhaupt noch muss) nur noch das Eintragen der Telefonnummern - und schon funzt es, ohne irgendwelche anderen Zugangsdaten. Die Legitimität der Rufnummern wird somit über den Anschluß als solchen geprüft, nicht über Credentials.

    Kaum SipGate eingerichtet und tada! Alles funktioniert.

    Das war auch ein guter Tipp. Ich habe Sipgate seit Jahren, mit Einzelanschlüssen und mehreren Trunks. Und die kennen sich mit SIP außerdem aus - ich kann es beurteilen. Während wenn ich mit der Telekom über SIP reden muss... lasse ich es lieber.


    Der Vertriebler, mit dem ich eine (geplante) IP-Umstellung von zwei Primärmultiplex besprochen habe, wollte mir weiß machen, dass die Telekom einen definierten Endpunkt bei uns bräuchte, um sich per SIP mit uns zu verbinden (nebenbei ist die Richtung verkehrt herum... WIR bauen die Verbindung zum SIP-Server auf). Nein, "brauchen" sie nicht. Wollen Sie, um die SIP-Trunks auf die eigene Leitung zu binden, obwohl ich von anderen Providern dicke Leitungen habe. Und ja, wenn man mehr wie 50 Telefonate über Telekom leiten möchte, brauchen wir Glasfaser und 100MBit, drunter geht das nicht. Also ... "WOLLEN" sie nicht.


    Ich rate derzeit jedem, der von IP-Umstellung bedroht ist, der Telekom Adieu zu sagen, wenn man die Chance hat ...


    CU, Peter

  • Während wenn ich mit der Telekom über SIP reden muss... lasse ich es lieber.

    DTAG verweigert ja sämtlichen Support für Endgeräte, die nicht durch die DTAG ausgeliefert werden.

    Die haben ja schon zu Bundespostzeiten viel Mist mit ISDN gebaut - und setzten sie auch alle möglichen Vorteile von VoIP in den Sand.

    Aber wenigstens ist Annex J das bessere Annex A (was man ja nirgens bekommen hat). Telefonieren tue ich eh mit anderen Anbietern.


    Was ich besonders scharf finde: die senden keine KeepAlives (Option Pakete), dass muss schön das Endgerät machen.

    In Verbindung mit den ReInvites einfach herrlich. Dazu kommt ja noch, dass die DTAG von unterschiedlichen IPs antwortet - welche genau ist Wetterabhängig und nicht öffentlich einsehbar. Die IP hinter tel.t-online.de antwortet jedenfalls nicht.


    D.h. Firewallfreigaben zur PBX hin sind total nutzlos, ich kann ja schlecht das gesamte 217.0.0.0/8 er Netz freigeben.

    Die DTAG hätte beim Rollout so viel richtig machen können: TLS auf Sprache und Signalisierung: Fehlanzeige - alles wird unverschlüsselt durchs Netz geprügelt

    T.38: Fehlanzeige: nur T.30 über G711

    Leitungssperrung bei Missbrauch: Fehlanzeige


    Sipgate bekomme ich problemlos durch zwei NATs durch. Die machen es nämlich richtig; denen ist nämlich nicht egal was der Kunde da anschließt.

    DTAG ist: friss oder stirb.


    (aber man kann ja leider nicht immer einen großen Bogen um DTAG + SIP machen)

  • Hay,

    D.h. Firewallfreigaben zur PBX hin sind total nutzlos, ich kann ja schlecht das gesamte 217.0.0.0/8 er Netz freigeben.

    Die komödiantische Details wußte ich ja noch gar nicht. Hab nie auch nur versucht, mit Telekom und VoIP mehr zu machen als Fritzboxen von privaten Nutzern angeschlossen. Ich hatte bei oben genannter Umstellung schon extremste Bauchschmerzen... wen könnte ich fragen, wenn was schief geht? Und was ist, wenn der krank wird?


    Die bekommen das über die technische Hotline von T-Systems mit den klassischen PMXen schon nicht richtig hin, wenn ich nicht direkt mit dem PMX-Zentrum in Köln spreche (gottseidank habe ich direkte Durchwahlen).


    Egal, sieht so aus, als ob die Firma zu einem Drittanbieter geht, weil Telekom ist zu teuer (das kommt ja noch hinzu). Zwei PMXer mit ein paar Dienstmerkmalen 600 Euro netto im Monat - IP-Umstellung mit Glasfaser und Sip-Trunks 1100 Euro netto im Monat (und 3 Jahre Bindung). Die haben sie nicht mehr alle... Business T-DSL mit 50MBit = 30 Euro, Sipgate Trunking um die 30 Euro und geht... mache ich schon seit 2010 so, keiner hat sich über Gesprächsqualität beschwert und Verfügbarkeit nicht schlechter als Telekom.


    CU, Peter

  • Stimmt nicht. T.38 wird mittlerweile unterstützt. Wobei man auch nie weiss, ob das "Empfängernetz" auch T.38 unterstützt, daher schalte ich T.38 immer aus.

    Auch im Privatkundensektor und Netzübergreifend? Genau genommen müsste ein Provider ja zwischen T.38 und T.30 übersetzen können.

    Die können ja auch Sprachcodecs umcodieren beim Wechsel aufs Mobilfunknetz.


    Eigentlich macht man es ja auch so, dass man sich mit T.30 und 2 kHz Ton meldet; und dann einen T.38 reinvite schickt.

    Ist halt die Frage, ob die Telekom den ReInvite ohne Manipulation zum anderen Teilnehmer durchgibt.

  • Auch im Privatkundensektor und Netzübergreifend? Genau genommen müsste ein Provider ja zwischen T.38 und T.30 übersetzen können.

    Die können ja auch Sprachcodecs umcodieren beim Wechsel aufs Mobilfunknetz.

    Genau das ist ja das Problem.

    T.38 wird im Telekom Netz "gesprochen" und wird auch weitergegeben. Aber ob das "Empfängernetz" damit umgehen kann, ist die andere Frage.

  • Huui! Vielen Dank an euch alle, die ihr mir hier geholfen habt! Zudem hat man dann doch noch ein bissel was gelernt - was für mich feststeht, dass die DTAG deutlich an ihren Dokumentationen über "wann 'vergessen' wir deine SIP-Pakete" oder auch "welche Protokolle/Standards wir nicht wirklich kennen" arbeiten muss. Außerdem werde ich/wir nun der Telekom für dieses Projekt den Rücken zukehren, zwar kann SipGate auch ordentlich ins Geld gehen - macht aber bei weitem nicht so viel Ärger und selbst deren Support reagiert in unter !10 Minuten! und zwar deutlich kompetenter als die Telekom-"Helfer". Ich kann nun Jedem nur dazu raten direkt die Telekom zu vergessen - ich hatte letztens übrigens über zwei Stunden rumtelefoniert, bis mir der Mitarbeiter aus der Großkundenabteilung (irgendwann war ich hier weitergeleitet worden...) die notwendigen Einstellungen raten konnte. Aber, dass die Telekom gerne Mist verzapft wusste ich schon vorher, so hatten wir damals einen Speedport vertraglich zugewiesen bekommen (angeblich eine umgelabelte Fritz!Box - nix da: Chinaschrott), welcher aufgrund der damaligen TR-069 Angriffe regelmäßig abstürzte oder einfror. Für Serverbetrieb ein Graus.

    Wie auch immer:

    Nochmals vielen Dank an euch,

    Simonmicro

  • was für mich feststeht, dass die DTAG deutlich an ihren Dokumentationen über "wann 'vergessen' wir deine SIP-Pakete" oder auch "welche Protokolle/Standards wir nicht wirklich kennen" arbeiten muss.

    Es gibt eine Dokumentation. Nur macht die keinen Spaß: https://www.telekom.de/hilfe/g…reibungen-fuer-hersteller


    angeblich eine umgelabelte Fritz!Box

    ein gefritzer Speedport. Nix Neues und absolut klar, dass der zu nix zu gebrauchen ist.

  • Alle derzeitigen Speedports haben GAR nichts mit Fritzboxen zu tun.

    Die einzigen umgelabelten Boxen gibt's bei 1&1.


    Die Telekom geht zwar nicht so "offen" mit Ihrer IP Wolke, wie zb Sipgate, um. Dennoch funktioniert die Plattform sehr gut bei Millionen Anschlüssen.


    Man muss halt nur wissen, dass die Registrierung der Rufnummern nur im Telekom Netz funktioniert.

  • Es gibt eine Dokumentation. Nur macht die keinen Spaß: https://www.telekom.de/hilfe/g…reibungen-fuer-hersteller


    ein gefritzer Speedport. Nix Neues und absolut klar, dass der zu nix zu gebrauchen ist.

    Schö wäre es, aber wie p4scal bereits schrieb, war unser Speedport w724v schon eines der Mist-Geräte. DIese basieren nicht nur nicht mehr auf AVM's Software sondern verwenden auch billigere Chipsätze. Was man halt auch merkte.