Telekom VoIP Telefonie hinter (draytek) Router Probleme

VoIP mit DrayTek Routern und dem DrayTek Softphone. SIP (Session Initiation Protocol), CODEC, RTP, SRTP und DTMF, ...

Moderatoren: TommyTC, alf, Petrus, andreastc, DSL-Hexe, nobody

Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon nobody » Di 10.05.2016 - 18:52

So man hinter einem Router der z.B. auch von Draytek sein kann VoIP Telefone oder auch eine Telefonanlage betreiben möchte, und Kunde bei der Telekom ist, kann es geschehen, dass manche Anrufer einen nicht erreichen können.
Stattdessen kommt lange nichts, und dann die Ansage "bitte rufen Sie den Teilnehmer zu einem späteren Zeitpunkt an".

Mit etwas Mühe habe ich festgestelt, dass dies vielleicht ein Fehler bei der Telekom ist, der zusammen mit UDP und NAT auftritt, vielleicht aber auch ein Problem mit Draytek Routern, das Draytek beheben könnte. Eher aber ein Fehler der Telekom, denn Laut RFC3261 ist es nicht zulässig SIP Pakete >MTU-200 per udp zu schicken. Auch andere Routerhersteller (Cisco, Sonicwall) verwerfen solche Pakete als unzulässig. Aber auch nicht alle Router, denn es gibt auch Stimmen im Internet die von "braindead" Routern sprechen die fragmentierte SIP pakete einfach verwerfen. Ganz klar ist es nicht wen hier die Verantwortung trifft.

Die Anrufer die einen nicht erreichen können, da schickt der Server der Telekom ein INVITE das größer als die MTU ist. Daher wird das Paket durch den Telekom Server fragmentiert in drei kleinere Paket-Fragmente. Der (daytek)Router kann aber das Paket nicht defragmentieren, oder macht es einfach nicht, stattdessen wird es verworfen. Selbst eine portfreigabe auf port 5060 hilft hier nichts.
Auch die Telekom eigene HomeTalk App für Android funktioniert nicht hinter einem (draytek) Router.
Der Ruf kommt aber an, wenn der Anrufer anonym anruft -merkwürdig auf den ersten Blick- aber, vermutlich eben weil kürzer um die Telefonnummer, und die kommt ja häufig genug im Header des INVITE Paketes vor.
Dies betrifft Anrufer nicht nur aus dem Bereich der Telekom, auch, aus anderen Netzen.
Hingegen ein Speedport Router der Telekom der die Telefonie ja mit eingebaut hat der hat kein Problem, vermutlich auch ein Draytek router mit VoIP eingebaut nicht. Das werde ich aber nochmals testen. Nicht jeder kann oder will so ein Gerät nehmen, oft haben die zu wenig features/leistung/sprachkanäle

Abhilfe schafft hier nur SIP über TCP statt UDP wenn der Router das Paket verwirft. Abhängig vom verwendeten Endgerät/Telefonanlage ist das aber einstellbar. Macht man das ist der Fehler behoben. Die Telekom kann auch SIP über TCP, selbst, wenn es keinen SRV record im DNS gibt, der darauf hinweist.

Nachvollzogen haben ich das mit einem draytek 2860 und 2960. Beim 2860 gibt es zwar in den Firewalleinstellungen die Option grosse fragmentierte UDP pakete zu akzeptieren. Aber selbst mit dieser option eingeschaltet bleibt der Fehler. Beim 2960 gibt es diese Option nicht. In den release notes für die Firmware 1.0.8 wird aber erwähnt "Support acceleration of fragmented UDP packets (maximum 1628 bytes)." Das fragmentierte Paket der Telekom hat aber leider 1650 bytes. Auch weiss man nicht ob in der version 1.2 dieses Feature überhaupt noch vorhanden ist.

Der 2960 ist die Draytek generation mit OpenWrt, also wie 3900 und auch ein paar andere Modelle
Der 2860 ist die Draytek eigenbau OS version, ähnlich 2920, 2925 usw.
Daher gehe ich davon aus, dass dieses Problem nahezu alle Draytek Router die aktuell erhältlich sind betrifft.
Vermutlich aber betrifft dies auch einige Router anderer Hersteller.

Somit, Vorsicht, und, bei Telekom besser SIP over TCP verwenden. Wenn man nicht angerufen werden kann, das ist nicht gut. Das Problem habe ich bisher nur bei der Telekom bemerkt. Mit einem anderen VoIP Provider bestand es nicht.

Vielleicht möchte Draytek ja eine Extra-Einstellung einbauen "Accept large fragmented SIP packets from broken Registrars"?

Die Telekom gehe ich aber auch noch fragen, ob Sie diesen Bug nicht beheben möchten. Allerdings rechne ich mir da keine großen Chancen aus, denn dort sind nicht nur Router "braindead".
nobody
Hardcore-Poster
 
Beiträge: 1332
Registriert: So 19.09.2004 - 16:45

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Sa 21.05.2016 - 13:34

Hallo,

nmap sagt mir, dass die Fritzbox eines Kumpels, der VOIP mit der Telekom macht, auf Port 5060 eine tcp-Verbindung offen hält.

Ein DNS SRV Record für SIP per tcp gibt es bei der Telekom schon, aber nur für t-online.de

Für tel.t-online.de gibt es dagegen nur einen Eintrag für SIP per udp

In der Telekom VOIP-Konfiguration verwendet man t-online.de für die SIP-Adresse und tel.t-online.de für Proxy+Registrar.
Für welche der beiden domains ein SIP Client bei welcher Gelegenheit eine DNS-Anfrage machen sollte, weiß ich nicht genau.
Vermutlich haben alle SIP-Clients mit vorkonfiguriertem T-Online-Modus TCP hart kodiert.

Bzgl. DNS-Einträgen würde ich denken, dass es für t-online.de und tel.t-online.de beide Einträge (tcp+udp) geben sollte, wobei dann der weight-Wert bei tcp größer sein sollte, falls die Telekom tcp favorisiert.

Gruß Erwin
(der selbst keinen Draytek-Router hat, aber gerade das Thema Voip etwas untersucht)

Code: Alles auswählen
nslookup -querytype=SRV _sip._tcp.t-online.de

_sip._tcp.t-online.de   SRV service location:
          priority       = 0
          weight         = 5
          port           = 5060
          svr hostname   = ims001.voip.t-ipnet.de
_sip._tcp.t-online.de   SRV service location:
          priority       = 1
          weight         = 5
          port           = 5060
          svr hostname   = ims002.voip.t-ipnet.de
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon nobody » So 22.05.2016 - 11:41

broeselmeier hat geschrieben:Hallo,

nmap sagt mir, dass die Fritzbox eines Kumpels, der VOIP mit der Telekom macht, auf Port 5060 eine tcp-Verbindung offen hält.

Ein DNS SRV Record für SIP per tcp gibt es bei der Telekom schon, aber nur für t-online.de

Für tel.t-online.de gibt es dagegen nur einen Eintrag für SIP per udp

In der Telekom VOIP-Konfiguration verwendet man t-online.de für die SIP-Adresse und tel.t-online.de für Proxy+Registrar.
Für welche der beiden domains ein SIP Client bei welcher Gelegenheit eine DNS-Anfrage machen sollte, weiß ich nicht genau.
Vermutlich haben alle SIP-Clients mit vorkonfiguriertem T-Online-Modus TCP hart kodiert.

Bzgl. DNS-Einträgen würde ich denken, dass es für t-online.de und tel.t-online.de beide Einträge (tcp+udp) geben sollte, wobei dann der weight-Wert bei tcp größer sein sollte, falls die Telekom tcp favorisiert.

Gruß Erwin
(der selbst keinen Draytek-Router hat, aber gerade das Thema Voip etwas untersucht)

Code: Alles auswählen
nslookup -querytype=SRV _sip._tcp.t-online.de

_sip._tcp.t-online.de   SRV service location:
          priority       = 0
          weight         = 5
          port           = 5060
          svr hostname   = ims001.voip.t-ipnet.de
_sip._tcp.t-online.de   SRV service location:
          priority       = 1
          weight         = 5
          port           = 5060
          svr hostname   = ims002.voip.t-ipnet.de


Hi,
Das ist ja auch schonmal interessant. Ich versuchs daher mal mit t-online statt tel.t-online.

Und, frag doch mal Deinen Kumpel, wie der das Konto eingerichet hat. Ich habe hier nämlich jemand anderern mit einer FB. Da habe ich zwar laut einer Anleitung aus dem Internet das geändert mit "transport=tcp". Aber die FB, die macht eine UDP verbindung auf, und, der Telekom server, der sagt sich wohl, wenn jemand mit UDP startet, dann mach ich mit UDP weiter. Somit klappts dann nicht.
Eine funktionierende Anleitung wie man das mit einer FB macht, das wäre wertvoll!


Gruss
nobody
Hardcore-Poster
 
Beiträge: 1332
Registriert: So 19.09.2004 - 16:45

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Mo 23.05.2016 - 11:23

Hm, vom Kumpel habe ich erst mal nur die myfritz-domain.
D.h. mit
Code: Alles auswählen
nmap -p 5060 xyz123.myfritz.net

bekomme ich "open" für den tcp-Port und mit

Code: Alles auswählen
nmap -sU -p 5060 xyz123.myfritz.net

"open|filtered" für den udp-Port.

Die Fritzbox ist in dem Bespiel übrigens auch der Router.

Kann es sein, dass ein standardkonformer SIP user agent auf Port 5060 per udp und tcp erreichbar zu sein hat?
In den SIP-RFC heißt es ja irgendwo, dass SIP-udp-Requests, die auf dem Zustellweg über diverse Proxies eine sichere Größe, bis der es zu keiner Fragmentierung kommt, überschreiten, ab dem Moment per tcp weitergereicht werden sollen.
(jeder SIP-Proxy fügt z.B. dem Request seinen eigenen VIA-Header hinzu)

Läuft der SIP user agent direkt auf dem Gerät mit der öffentlichen IP, dann mag er sich zwar per UDP registriert haben, sein zugehöriger Proxy könnte aber dynamisch, wenn eine Request-Message für udp zu groß wird, eine Verbindung per tcp versuchen.

Der SIP user agent im privaten Netz hinter dem NAT-Router erzeugt aber lediglich einen NAT Eintrag im Router bei der Registrierung. Also wird am NAT-Router ohne zusätzliche Maßnahmen Port 5060 nur für udp offen sein. Versucht der SIP-Proxy eine TCP-Verbindung aufzubauen, weil eine größere Request-Message zugestellt werden soll, wird er ein Port-closed bekommen. Die Fallback-Lösung könnte so aussehen, dass der Proxy dann eben doch die zu große Message per udp zustellt, die dann ggf. zu den genannten Erreichbarkeitsproblemen führt.

Zwei Lösungen fallen mir für das Problem ein:

1. wenn man nur einen SIP-Client im LAN hat, dann kann man auf dem Router Portforwardings für 5060 tcp+udp für den Client einrichten.

2. man zwingt den Client dazu, sich per tcp zu registrieren

Zur Telefoniekonfiguration der Fritzboxen:
Dort gibt es für die bekannten großen SIP-Provider vorkonfigurierte Masken, so dass ich davon ausgehe, dass die Fritzboxen sich je nach SIP-Provider sehr unterschiedlich verhalten. Die meisten SIP-Provider unterstützen den Betrieb von SIP-Clients hinter einem NAT-Router offiziell nicht. Bei AVM finden sich Hinweise zu den auf dem Router einzurichtenden Portforwardings für SIP, SIPS, RTP, RTCP.

Für NAT-Router und mehr als einen SIP-Client im LAN, wird man wahrscheinlich keine einfache und mit allen SIP-Providern funktionierende Lösung für die Routerkonfiguration finden.

Falls man eine FB hat und sich weitere SIP-Clients im LAN nicht gerade auf die Geräte durchreisender Gäste verteilen, dann könnte man darauf hinarbeiten, dass sich alle SIP-Clients an der FB registrieren und die Portforwardings im Router für die FB passend gesetzt werden.

Gruß Erwin

ps. Ich bin mir nicht sicher, ob die Registrierung per tcp nur Vorteile bringt. Bei SIP geht es ja auch darum, möglichst schnell und sicher tote Verbindungen zu erkennen und zu erneuern. Das könnte vielleicht mit einer der Gründe sein, warum sich SIP Clients standardmäßig per udp registrieren wollen.
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Mo 23.05.2016 - 16:59

Wenn man erst mal weiß, wonach man suchen muss, dann findet man auch Sachen
z.B. hier
http://www-01.ibm.com/support/docview.wss?uid=swg21316620

SIP soll also tatsächlich dynamisch von udp auf tcp umschalten, wenn Request-Messages eine bestimmte Größe (1300 Bytes) überschreiten.
Im angegebenen Link geht es um eine diesbezügliche Fehlerbehebung für einen SIP-Server in einer IBM-Umgebung.
Das Problem der Überschreitung der Paketgröße hat danach übrigens nicht die Request-Message sondern die daraus resultierende Response-Message des angerufenen user agents, da die Response um 200 Byte größer ist als die Request-Message.

Es erscheint mir nicht wahrscheinlich, dass die Telekom dieses Problem hat, denn es würde dann alle SIP-Clients betreffen.

Aus der Beobachtung der NAT-Einträge, die meine Uralt-Fritzbox für meine Test-Sip-Accounts im Router erzeugt, bleibe ich bei meiner obigen Vermutung, dass die Umschaltung auf tcp nicht funktionieren kann, weil es keinen NAT-Eintrag für tcp für die FB im Router gibt.
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Di 24.05.2016 - 08:29

Hallo,

habe nochmal gesucht, warum nicht von vornherein tcp der Standard für SIP ist.

Der Hauptgrund scheint der deutlich größere Protokolloverhead und die daraus resultierende Last auf Seiten der SIP-Server zu sein.
Grundsätzlich könnte man zwar eine tcp-Verbindung bei der Registrierung des user agents herstellen und dann locker für mehrere Stunden keinen Traffic über diese Verbindung schicken, wenn niemand telefonieren will, aber dann würde man es wahrscheinlich auch immer erst bemerken, dass die Verbindung tot ist, wenn ein Anruf signalisiert werden soll. Der Anrufer bekäme, dann ein nicht erreichbar oder wird an eine serverseitige Sprachbox weitergeleitet.

Irgendwo im SIP-RFC-Sammelsurium habe ich gelesen, dass tote SIP-Verbindungen innerhalb von 2 Minuten diagnostiziert und erneuert werden sollten.
Ein SIP-Ping ist auch für tcp spezifiziert.
Würde man nun vielleicht im Minutentakt einen SIP-Ping per tcp machen, dann führt das zu einer deutlich größeren Serverlast als ein SIP-Ping per udp im Minutentakt. Dass der udp-SIP-Ping ganz nebenbei dazu dient, die NAT-Einträge in NAT-Routern am Leben zu erhalten, die sonst typischerweise nach 180s Sendepause vom Router gelöscht würden, passt zusätzlich gut zu den Verfügbarkeitsanforderungen für SIP.

Schaut man sich die Hinweise zum SIP-Header in den RFC an, dann erkennt man, dass die Überschreitung der 1300Byte für SIP-Requests und dadurch der Wechsel von udp auf tcp möglichst lange hinausgezögert werden soll, indem z.B. für alle Header-Felder eine Kurzform definiert ist.
z.B. "f:" statt "From:"
SIP-Proxies dürfen vielleicht auch Langformen in empfangenen Messages durch Kurzformen ersetzen.
Selbst wenn die Telekom-Server hier noch Optimierungspotenzial hätten, bezweifle ich, dass die Telekom an ihrer SIP-Plattform etwas ändert.
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Di 24.05.2016 - 08:45

broeselmeier hat geschrieben:Vermutlich haben alle SIP-Clients mit vorkonfiguriertem T-Online-Modus TCP hart kodiert.


fürs Protokoll: Das ist vermutlich falsch. s.o.
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon nobody » Mi 25.05.2016 - 19:13

Danke erstmal für Deine antworten.

Mein setup ist eben dass auf dem router Keine Telefonalage ist sondern hinter dem Router.
ein port forward ist sowieso an (symetrisches NAT), aber, das hilft leider nichts, wenn Der Router die zu grossen Pakete die eintreffen verwirft. Der Router müsste das zu grosse UDP Paket erstmal reassemblieren und wieder fragmentieren für den weitertransport im privaten Netz. Das ist im Falle von UDP auch ein bisschen schwieriger als bei TCP.

Ein dynamischer switch von UDP auf TCP wie in der RFC gefordert, das wäre die lösung, die Telekom macht das aber nicht, obwohl sie wissen könnte, dass das eigentlich gemacht werden muss. Sowhl FB als auch meine Tel. Anlage wären ja empfangsbereit für TCP. Die Telekom schickt das paket fragmentiert weg, und, da udp weiss sie ja nichtmal ob es überhaupt ankommt. Dann kommt nach längere warte zeit: teilnehmer zur Zeit nicht erreichbar dabei raus.

Ich denke dieses Problem betrifft alle Personen die eine Tel. Anlage hinter einem NAT router betreiben der konform zur RFC UDP pakete verwirft die zu gross sind. Und die an einem Telekom SIP-Server hängen, der diesen Bug hat.

hier ein paar links dazu:
Sonicwall:
https://support.software.dell.com/kb/sw10958

Cisco:
https://quickview.cloudapps.cisco.com/q ... CSCut60261

die RFC:
https://tools.ietf.org/html/rfc3261
und:
https://tools.ietf.org/html/draft-gurba ... esponse-00
nobody
Hardcore-Poster
 
Beiträge: 1332
Registriert: So 19.09.2004 - 16:45

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Do 26.05.2016 - 10:11

Das habe ich schon verstanden, dass dein SIP-Client im LAN hinter dem NAT-Router ist.

Deinen Hinweis "port forward ist sowieso an (symetrisches NAT)" verstehe ich vielleicht nicht richtig.
Du hast also geprüft, dass das NAT deines Router tatsächlich auch Quellport 5060 für die Registrierungsverbindung des SIP-Clients verwendet und hast dann manuell auf dem Router für 5060 für UDP und TCP ein Forward auf deinen SIP-Client konfiguriert?
Falls das NAT des Routers einen anderen Quellport verwendet, hast du für den manuell das Forward konfiguriert.
Und ein "nmap -p 5060 (bzw. dein alternativer Port) deine.öffentliche.ip" liefert auch, dass 5060 bzw. dein alternativer Port für tcp offen ist?
Wenn ja, dann könnte es tatsächlich ein Problem in der Konfiguration der SIP-Server der Telekom geben.

Falls du mehr als einen SIP-Client im LAN hinter dem NAT-Router hast, der sich zum gleichen SIP-Provider verbindet, dann dürfte das NAT einen anderen Quellport als 5060 wählen bzw. dein Router wählt grundsätzlich irgend einen Zufallsport. Dieser Port ist dann durch die Registrierung des SIP-Clients wieder nur für UDP offen. In dem Fall müsste man dann geordnet dafür sorgen, dass die Clients vorbestimmte Quellports verwenden, für die man dann die entsprechenden TCP Forwards konfigurieren kann.

Plausibel ist, dass fragmentierte UDP-SIP-Requests oder -Responses nicht funktionieren können, da es keinen Mechanismus gibt, nach der die UDP-Pakete wieder zu einer vollständigen SIP-Message zusammengesetzt werden können. (Bei RTP wird zusätzlich das RTCP verwendet, damit man mindestens die RTP-Pakete wieder in die richtige Reihenfolge bekommt)

Ebenso plausibel ist es, dass nicht standardkonforme, weil zu große, UDP-Pakete von sicherheitsbewussten Routern als Angriffsversuch gewertet und verworfen werden.

Eine Lösung kann also nur so aussehen, dass SIP-Messages ab einer bestimmten Größe per TCP übertragen werden müssen. Dabei müssen SIP-Request-Messages bereits 200 Byte unterhalb der standardkonformen MTU per TCP übertragen werden, da die Response zwangsläufig um bis zu 200 Byte größer wird und sich der empfangende Server bei der Response an die Protokollvorgabe des Senders im VIA-Header halten muss.

Wenn UDP-SIP-Messages fragmentieren oder wegen Übergröße von Routern verworfen werden, dürfte es egal sein, ob der SIP-Client auf dem Router oder im LAN hinter dem Router ist. Beim SIP-Client auf dem Router dürften alle Pakete auch zuerst durch die entsprechenden Filterketten des Routers laufen, bevor sie an den SIP-Client weitergereicht werden.

Die von dir verlinkten Quellen, die sich auf Router beziehen, scheinen alle in die Richtung zu gehen, dass SIP-Messages entweder die zulässige Größe für UDP einhalten oder per TCP übertragen werden.

Der verlinkte Entwurf einer Aktualisierung des RFC3261 zur Behandlung zu großer UDP-SIP-Messages scheint nie bestätigt worden zu sein.

An Hand der oben von mir verlinkten Support-Mitteilung von IBM, die sich auf eine SIP-Server-Konfiguration bezieht, gehe ich davon aus, dass die dynamische Umschaltung auf TCP bei zu großen SIP-Messages nach RFC3261 aktueller Standard ist.

Man kann nicht ausschließen, dass die Telekom genau so ein Problem hat, wie es in dem IBM-Link beschrieben ist.

Da das Problem bei SIP-Clients auf dem Router aber scheinbar nicht auftritt, hätte ich eher den Verdacht, dass der SIP-Client hinter dem NAT-Router wegen fehlender Forward-Regel für den registrierten Port für TCP nicht per TCP erreichbar war und die zu großen UDP-SIP-Requests das Ergebnis eines Fallback-Verhaltens des SIP-Servers der Telekom sind.

Wenn man sich die Bilder in deinem Link https://support.software.dell.com/kb/sw10958 genau ansieht, dann sieht man, dass die zu große UDP-Message an Port 47887 des Routers gesendet wurde.
D.h. der SIP-Client hinter diesem Router hat sich mit diesem Quellport beim SIP-Provider registriert und hat damit automatisch einen NAT-Eintrag für UDP für diesen Port im Router erzeugt.
Da die Zahl etwas zufällig wirkt, könnte man vermuten, dass der Port nicht per TCP erreichbar war und die zu große SIP-UDP-Message ebenfalls das Ergebnis eines Fallback-Verhaltens des SIP-Servers ist.
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon nobody » Do 26.05.2016 - 17:47

Hi,
ich habe nur einen SIP Client, das ist die Tel. Anlage. Und auf Router habe ich port 5060 udp + tcp per portforward auf die Tel. anlage geöffnet.
Ich habe nicht geprüft, vermute das aber (kann es auch noch prüfen), ob 5060 auch der quellport ist der für die Registrierung verwendet wird.
Was ich gemacht habe, ist mit wireshark den traffic mitgeschitten, der zwischen DSL-Modem und Router-WANSchnittstelle läuft.
Und hier kann man schön sehen, dass meist UDP pakte mit <=1300 bytes ankommen auf zielport 5060, und, dann klingelt das telefon.
Aber manchmal kommen 3 pakete, größe 1650 bytes in 3 Fragmenten zielport 5060, und das telefon klingelt nicht.
Ebenso haben ich den Traffic an der internen LAN Schnittstelle des Routers migeschnitten, und, hier kommt im Falles des zu grossen Paketes nichts raus.

Daher denke ich der Fall ist klar - da die pakete zu port 5060 kommen, müsste das mit dem Port stimmen. sonst würden die ja an einen anderen port gerichtet sein. Das hätte ich ja dann gesehen.
Und, der Router verwirft diese zu grossen fragmentierten UDP pakete - zurecht vermutlich.

Ach und, was ich auch gemacht habe:
X-lite genommen, die Tel. Anlage runtergefahren. Bei X-Lite kann man TCP für SIP erzwingen. Mache ich das, dann kommen die Anrufer, die mich sonst nicht erreichen sofort problemlos zu mir durch. Schalte ich auf UDP, kommt wie zu erwarten eben wieder das "der teilnehmer ist derzeit nicht erreichbar" beim Anrufer.
Die Fa. 3CX bastelt nun auch einer Implementation von SIP über TCP. Ich hoffe, dass damit das problem für mich zumindest aus der Welt ist.
nobody
Hardcore-Poster
 
Beiträge: 1332
Registriert: So 19.09.2004 - 16:45

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Do 26.05.2016 - 19:47

Das hört sich dann doch nach einem Telekom-Problem an.
Dass es jeweils 3 Pakete sind, dürfte den Retry-Versuchen des SIP-Proxy geschuldet sein.
Der Router kann die Pakete nur wegen ihrer Größe verwerfen.
Wenn sich der Inhalt einer SIP-Message auf mehrere UDP-Pakete verteilt, dann wäre das kein Grund für einen Router die Pakete zu verwerfen. Also Fragmentierung dürfte hier kein Thema sein.

Interessant wäre ja mal der Inhalt der zu großen UDP-Pakete. Vielleicht kann man erkennen welche Anrufer betroffen sind.
War da nicht mal was mit zwei verschiedenen SIP-Plattformen der Telekom?

Mit deinem Hinweis auf 3CX kann ich nichts anfangen.

Sich einen SIP-Client zu suchen, den man zu tcp zwingen kann, scheint ja dann aktuell ein funktionierender Workaround zu sein.

Ob es Sinn macht, das Problem bei AVM vorzustellen und danach zu fragen, wie man die FB zu tcp mit der Telekom zwingen kann?
Selbst wenn da nichts passiert, besteht vielleicht eine Chance, dass jemand bei AVM einen direkteren Draht zur Telekom hat und in Erfahrung bringen kann, wie sich die Telekom das mit den zu großen udp-Paketen vorstellt.
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Do 26.05.2016 - 20:21

Vielleicht auch noch einen Versuch wert.
Mach mal auch für 5061 ein Forwarding.
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Fr 27.05.2016 - 10:20

Hallo,

habe gerade deinen Thread im IP-Phone-Forum entdeckt.

Dein SIP-Client ist also eine TA von 3CX, die sich in der aktuellen Version nicht dazu überreden lässt, sich per TCP zu registrieren.

Bei der Beschreibung des Verhaltens am Router wäre es schön, wenn die Begriffe SIP-Message und Paket klar voneinander getrennt wären.
SIP-Messages können fragmentieren, d.h. auf mehrere ip-Pakete aufgeteilt werden und sollen dann entspr. rfc3261 per tcp übertragen werden, damit die empfangende SIP-Komponente die IP-Pakete wieder zu einer Message zusammenfügen kann.
IP-Pakete fragmentieren nicht sondern werden ggf. nur verworfen, wenn sie sich nicht an die Größenbeschränkung eines Kommunikationskanals halten.

Wenn dich bestimmte Leute anrufen wollen, sendet die Telekom offensichtlich zu große IP-Pakete, die vom Router verworfen werden. Das ist für sich allein gesehen doch erst mal ein Problem, das mit SIP (und auch mit UDP?) nichts zu tun hat und grundsätzlich abgestellt gehört. (Wie wird überhaupt die max. Paketgröße bestimmt? Ist das eine statische Einstellung oder tauschen sich die Kommunikationspartner darüber aus? Falls ja, könnte der Vigor130 vielleicht eine zu große MTU signalisieren?)

Hast du geschaut, ob bei den fehlschlagenden Anrufversuchen auch TCP-Pakete an 5060 verworfen werden?
(vielleicht werden ja zuerst ein paar zu große TCP-Pakete verworfen und weil keine Antwort kommt, kommen dann noch ein paar zu große UDP-Pakete, die auch verworfen werden)

ps. Kann man seine auf SIP umgestellte Telekom-Telefonnummer tatsächlich im Kundencenter auf einen beliebigen SIP-Account umleiten?

http://www.heise.de/netze/artikel/Byte- ... 24316.html
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon nobody » Fr 27.05.2016 - 14:35

Hi,
3CX Telekom anlage: die Kann schon TCP, aber, wenn die gegenseite das nur dann macht wenn die Tel. Anlage selber mit TCP beginnt, dann gehts eben nicht. Aber der hersteller arbeitet ja dran, dass es wie bei X-lite erzwungen werden kannn.

Die fraglichen SIP-nachrichten sind fragmentierte udp pakete, die zusammengenommen (defragmentiert) eine größe von 1650 bytes haben.
Mehr als 1492 bytes geht eben nicht. Daher werden die ja fragmentiert geliefert (die "guten" SIP Nachrichten sind alle unfragmentiert). Es sind keine 3 gleichen Pakete, die wiederholt wurden, sondern ein SIP-Paket.
Ich habe den gesamten traffic mitgezeichnet. Es kommt keine nachricht per TCP an.

Tatsächlich list es kein problem alle runfnummern im Telefoniecenter umzuleiten. Das geht einfach und funktioniert.
nobody
Hardcore-Poster
 
Beiträge: 1332
Registriert: So 19.09.2004 - 16:45

Re: Telekom VoIP Telefonie hinter (draytek) Router Probleme

Beitragvon broeselmeier » Sa 28.05.2016 - 11:01

Habe mich etwas zu UDP, IP und Fragmentierung belesen.

UDP-Datagramme dürfen demnach theoretisch ca. 65.000 Byte groß werden und werden, wenn sie größer sind als die MTU, vom IPV4-Stack auf mehrere IP-Pakete aufgeteilt. Der IP-Stack gibt dazu allen Paketen eine Fragmentierungskennzeichnung und eine Offsetkennung. Wenn kein Paket verloren geht, kann der Empfänger das Datagramm grundsätzlich wieder richtig aus den einzelnen IP-Paketen zusammensetzen. Für das Zusammensetzen des UDP-Datagramms wäre grundsätzlich der SIP-Client zuständig.
Wie hier http://blog.csrpswitch.com/sip-udp-fragmentation-and-kamailio-the-sip-header-diet/ aus rfc3261 zitiert, müssen SIP-Clients grundsätzlich SIP-Messages als UDP-Datagramme bis zur maximal für UDP definierten Größe akzeptieren.
Für UDP per IPV6 ist Fragmentierung nicht mehr erlaubt. IPV6 wird von den SIP-Servern der Telekom aber nicht unterstützt.

Im Moment ist mir noch nicht plausibel, warum der SIP-Server der Telekom ein 1650 Byte UDP-Datagramm auf 3 IP-Pakete aufteilt. 2 Pakete müssten locker reichen. Wenn man 1 oder 2 Retrys einplant, sollte SIP-Signalisierung auch hinreichend zuverlässig funktionieren.

In deinem Fall beschließt dein Router, IP-Pakete, die Fragmente von UDP-Datagrammen sind, zu verwerfen.
Eine plausible Erklärung für dieses Verhalten findet sich hier
http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html#anc2

Wer hat nun Recht?
Die Telekom könnte sich darauf berufen, dass in rfc3261 steht, dass SIP-Clients auch mit großen UDP-Datagrammen klarkommen müssen. Das wird für die meisten SIP-Clients vermutlich auch gegeben sein.
Gleichzeitig gibt es genau so gute Begründungen, warum fragmentierte UDP-Datagramme von einigen Routern verworfen werden.
Da rfc3261 naheliegenderweise fordert, dass ab SIP-Messagegröße größer MTU minus 200Byte TCP zu verwenden ist, dürfte nach Abwägung aller Sachverhalte herauskommen, dass bei größeren SIP-Messages auf TCP umgeschaltet werden muss.

Es könnte sein, dass die SIP-Landschaft der Telekom die messagegrößenabhängige Umschaltung auf TCP gar nicht beherrscht, weil es bisher meistens kein Thema war, dass SIP-Messages die kritische Größe überschreiten. Wahrscheinlich finden sich auch bei den aktuell betroffenen Nummern eher Ansätze, die SIP-Messages zu verkleinern, als dass man über den dynamischen Wechsel auf TCP nachdenkt.

Interessant ist, wie DUS.net das Problem gelöst hat. Du schriebst ja im IPPF, dass das Problem verschwunden ist, nachdem du deine Telekom-Nummern zu einem DUS.net-SIP-Account umgeleitet hast.
Beherrscht DUS.net die fallweise Umschaltung auf TCP bei großen SIP-Messages oder haben auch sie das Problem gelöst, indem sie (nicht standardkonform) überflüssige Angaben aus der SIP-Message entfernen und sie so unter der kritischen Größe für UDP halten? D.h. gibt es überhaupt jemals TCP-Traffic auf Port 5060?

Da die Telekom ja auch gerade massiv kleineren Geschäftskunden die ISDN-Anschlüsse kündigt und solche Kunden eher mal einen aufwändigeren Router mit dahinterliegender TA verwenden, müsste das Problem doch irgendwann auffallen.

Könntest du vielleicht mal so eine lange Invite-Message posten. Vielleicht sieht man, ob und von wem zusätzlicher Ballast gekommen ist.
broeselmeier
Ambitionierter User
 
Beiträge: 36
Registriert: Sa 21.05.2016 - 13:04

Nächste

Zurück zu VoIP - Voice over IP

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste