o2 DSL + P-2602-HWN-D7A + fritz!box 7170

>klingt ja schon ganz gut.
>In der voip.cfg findet man auch noch einen Eintrag rtpport_start.
>Ich vermute der muss auch noch angepasst werden?!

:-o
Ups, hatte ich ganz vergessen. War schon spät heute nacht ;)
Ja, der muß auch noch angepasst werden.
Dem o2 Router kann ich entnehmen, daß für RTP-Pakete der komplette Bereich von 50000-65535 freigegeben wird. Schein ein wenig übertrieben
und hat auch nichts gebracht als ich das mal ausprobiert habe.
In der detaillierten Anrufliste der Fritzbox erscheint übrigens bei abgehenden Gesprächen in beide Richtungen G711 und bei eingehenden nur in einer Richtung. Ich vermute, daß SIP Pakete hängen bleiben.

Wie kann man das tracen?
Gibt es irgendwo eine Beschreibung was die einzelnen Einträge in der ar7.cfg
und voip.cfg zu bedeuten haben, oder sind wir da auf probieren angewiesen?

Einiges erklärt sich ja von selbst, aber bei vielen Parametern rätsel ich noch.
Ich habe z.B. versucht die VOIP-Konfiguration auf CBR umzustellen, was der o2 Router benutzt, während bei der Fritzbox UBR eingestellt ist.
Das hat die FB komplett verweigert. Scheint aber nicht das Problem zu sein, da sich die ATM Dienste auch so zu verstehen scheinen.

Heute bin ich leider komplett ausgebucht, so daß ich mich erst morgen
dransetzen kann.

Den anderen wünsche ich schon mal viel Erfolg!
 
Hi

Hab seit heute auch 02 dsl und will meine Fritzbox nutzen. Leider geht bei mir das Internet nicht ..

Eingeloggt bin ich zwar und ich kann auch pingen

Ping google.de [216.239.59.104] mit 32 Bytes Daten:

Antwort von 216.239.59.104: Bytes=32 Zeit=55ms TTL=242
Antwort von 216.239.59.104: Bytes=32 Zeit=53ms TTL=242
Antwort von 216.239.59.104: Bytes=32 Zeit=54ms TTL=242
Antwort von 216.239.59.104: Bytes=32 Zeit=54ms TTL=242

aber weder skype noch Opera oder irgendeine sonstige Internetanwendung funktioniert. Kann mir wer da helfen?
 
Hallo zusammen,

stimmt, mit RTP Ports >50000 funktionieren zumindest ausgehende Verbindungen.
Leider kommt bei eingehenden Verbindungen keine Sprachverbindung zustande.

Hab zwischenzeitig noch mal einen Trace gezogen.
Nach INVITE -> TRYING -> RINGING und kommt beim abheben des Hörers das OK vom AVM Router. Dieses Paket wird jedoch recht merkwürdig fragmentiert!
Das erste Paket enthält 1472 Byte (soweit so gut) das zweite Paket enthält 8 Byte das dritte (!!) Paket enthält dann nochmals 18 Byte! Aus meiner Sicht ergibt das so keinen Sinn. Vermutlich wird das o2 Voice Gateway (oder eine vor geschaltete FW) dieses Paket verwerfen, wodurch dann keine RTP Verbindung vom GW zum Router zustande kommt und das Gateway noch immer einen Wählton zum Anrufer ausgibt.
Übrigens startet die Fritz!Box sofort nach dem OK den ausgehenden RTP Stream (korrekt auf Port 50000).
Auch bei mehreren Versuchen ergab sich immer die gleiche Situation, das OK Paket wurde in 3 Frames fragmentiert, wobei der erste (klar) und der zweite Frame (konstant 8Byte) immer die gleiche Größe aufwiesen. Nur die Framegröße des 3 Frames variierte leicht so um die 17-18 Byte. Gibt es hier eventuell ein Problem im IP Stack der Fritz!Box?!?!
Gibt es eine Möglichkeit die MTU Size des VoIP PVC einzustellen (zu verringern) um zu schauen ob dieses einen Einfluss auf die Fragmentierung hat?

Viele Grüße

mm3311
 
Mr.Mit schrieb:
Hi

Hab seit heute auch 02 dsl und will meine Fritzbox nutzen. Leider geht bei mir das Internet nicht ..

Eingeloggt bin ich zwar und ich kann auch pingen

Ping google.de [216.239.59.104] mit 32 Bytes Daten:

Antwort von 216.239.59.104: Bytes=32 Zeit=55ms TTL=242
Antwort von 216.239.59.104: Bytes=32 Zeit=53ms TTL=242
Antwort von 216.239.59.104: Bytes=32 Zeit=54ms TTL=242
Antwort von 216.239.59.104: Bytes=32 Zeit=54ms TTL=242

aber weder skype noch Opera oder irgendeine sonstige Internetanwendung funktioniert. Kann mir wer da helfen?
Wenn du feste IP's im Netzwerk hast, trage folgende DNS-Server ein:

62.53.236.4
193.189.244.205
 
Hoi

Das mim Internet hab ich nu hinbekommen, jedoch geht bei mir VOIP auch nicht. Hab nun erstmal die FB hinter den O2 Router gehängt und das Telefon an den o2 router solange es dafür noch keine Lösung gibt
 
Hallo mm311,

sehr guter Beitrag von Dir. Das TR069 sehe ich auch sehr kritisch. Aber man kanns deaktivieren im Kommandozeileninterface. Theoretisch ist aber immer noch möglich, dass versteckte Hintertüren eingegbaut sind.

mm3311 schrieb:
Ich würde vermuten, dass die Jungs von o2 in besagter Nacht eine Accessliste zwischen Daten- und Voice-PVC (wieder) aktiviert haben, die verhindert, dass aus dem Daten-PVC Zugriffe auf das Voice Netz erfolgen.
Klingt plausibel. Aber ganz wasserdicht ist das noch nicht. Zumindest bei mir kommen über den VC 1/35 Zugriffsversuche z.B. von chinesischen IP-Adressen an. Und das nach (!) der scheinbaren Trennung der beiden Netze für Voice und Inet vor einigen Tagen.

Wie ich das weiss? Ich habe testhalber über die johmart-rom-t-Methode den Wan Node #2 ("voice"/Sprache) deaktiviert und den Wan Node #1 ("MyISP"/Internet) von 1/32 auf 1/35 umgeschaltet. Der Router hält anscheinend eine Historie der IP-Verbindungen bzw. Verbindungsversuche; sowas wird ja für SUA/NAT und Statefull Packet Inspection gebraucht. Diese kann vom Command-Prompt mittels "sys tos display" ausgegeben werden. Die Liste geht übrigens über mehrere Seiten (mehrmals Leertaste drücken) und wird anscheinend von Hinten gefüllt.
 
Zuletzt bearbeitet:
Hallo,

habt ihr euch schon mals das Log des Ufos genauer angesehen? Ich habe mal einen Ausschnitt angehängt (von unten nach oben lesen)
Sieht für mich so aus, als ob das UFO selbständig Anrufe tätigt! :confused:

Das passiert scheinbar immer um den Auf-/Abbau der DSL-Verbindung herum.
In Zeile 45 und 44 wird ein Anruf beendet. Danch wird wohl die Verbindung beendet und weitere Versuche unternommen. Ab Zeile 6 wird wieder die DSL-Verbindung aufgebaut und anschliessend besteht wieder eine Telefon-Verbindung.

Ist das die Ursache, warum eine FBF nicht mit o2 klar kommt?
Vielleicht liege ich ja total falsch :noidea:

Code:
1|10/02/2007 03:31:23  |                      |                      |                                
    ppp:PAP Opening
  2|10/02/2007 03:31:23  |                      |                      |                                
    ppp:LCP Opening
  3|10/02/2007 03:31:23  |                      |                      |                                
    ppp:LCP Opening
  4|10/02/2007 03:31:23  |                      |                      |                                
    ppp:LCP Starting
  5|10/02/2007 03:31:23  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 154, C02 OutCall Connected 512000 
  6|10/02/2007 03:31:23  |                      |                      |                                
    ppp:LCP Starting
  7|10/02/2007 03:31:23  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 153, C02 OutCall Connected 512000 
  8|10/02/2007 03:31:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 154, C01 Outgoing Call dev=6 ch=1 
  9|10/02/2007 03:31:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 153, C01 Outgoing Call dev=6 ch=0 
 10|10/02/2007 03:30:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 152, C01 Outgoing Call dev=6 ch=1 
 11|10/02/2007 03:30:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 151, C01 Outgoing Call dev=6 ch=0 
 12|10/02/2007 03:30:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 150, C01 Outgoing Call dev=6 ch=1 
 13|10/02/2007 03:30:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 149, C01 Outgoing Call dev=6 ch=0 
 14|10/02/2007 03:29:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 148, C01 Outgoing Call dev=6 ch=1 
 15|10/02/2007 03:29:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 147, C01 Outgoing Call dev=6 ch=0 
 16|10/02/2007 03:29:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 146, C01 Outgoing Call dev=6 ch=1 
 17|10/02/2007 03:29:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 145, C01 Outgoing Call dev=6 ch=0 
 18|10/02/2007 03:28:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 144, C01 Outgoing Call dev=6 ch=1 
 19|10/02/2007 03:28:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 143, C01 Outgoing Call dev=6 ch=0 
 20|10/02/2007 03:28:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 142, C01 Outgoing Call dev=6 ch=1 
 21|10/02/2007 03:28:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 141, C01 Outgoing Call dev=6 ch=0 
 22|10/02/2007 03:27:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 140, C01 Outgoing Call dev=6 ch=1 
 23|10/02/2007 03:27:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 139, C01 Outgoing Call dev=6 ch=0 
 24|10/02/2007 03:27:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 138, C01 Outgoing Call dev=6 ch=1 
 25|10/02/2007 03:27:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 137, C01 Outgoing Call dev=6 ch=0 
 26|10/02/2007 03:26:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 136, C01 Outgoing Call dev=6 ch=1 
 27|10/02/2007 03:26:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 135, C01 Outgoing Call dev=6 ch=0 
 28|10/02/2007 03:26:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 134, C01 Outgoing Call dev=6 ch=1 
 29|10/02/2007 03:26:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 133, C01 Outgoing Call dev=6 ch=0 
 30|10/02/2007 03:25:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 132, C01 Outgoing Call dev=6 ch=1 
 31|10/02/2007 03:25:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 131, C01 Outgoing Call dev=6 ch=0 
 32|10/02/2007 03:25:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 130, C01 Outgoing Call dev=6 ch=1 
 33|10/02/2007 03:25:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 129, C01 Outgoing Call dev=6 ch=0 
 34|10/02/2007 03:24:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 128, C01 Outgoing Call dev=6 ch=1 
 35|10/02/2007 03:24:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 127, C01 Outgoing Call dev=6 ch=0 
 36|10/02/2007 03:24:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 126, C01 Outgoing Call dev=6 ch=1 
 37|10/02/2007 03:24:22  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 125, C01 Outgoing Call dev=6 ch=0 
 38|10/02/2007 03:23:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 124, C01 Outgoing Call dev=6 ch=1 
 39|10/02/2007 03:23:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 123, C01 Outgoing Call dev=6 ch=0 
 40|10/02/2007 03:23:52  |                      |                      |                                
    ppp:IPCP Closing
 41|10/02/2007 03:23:52  |                      |                      |                                
    ppp:LCP Closing
 42|10/02/2007 03:23:52  |                      |                      |                                
    ppp:IPCP Closing
 43|10/02/2007 03:23:52  |                      |                      |                                
    ppp:LCP Closing
 44|10/02/2007 03:23:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 0, call 122, C02 Call Terminated
 45|10/02/2007 03:23:52  |                      |                      |CALL DETAIL RECORD              
    board 0 line 0 channel 1, call 119, C02 Call Terminated
 46|10/02/2007 03:22:53  |                      |                      |SIP[3]                          
    SIP Registration Success by SIP:49711xxx
 47|10/02/2007 03:22:52  |                      |                      |SIP[4]
 
Hmmm, dann sind das wohl die Chinesen, die vor der Umschaltung auf den anderen PVC versucht haben sich zu verbinden ...
 
Hab zwischenzeitig noch mal einen Trace gezogen.
Nach INVITE -> TRYING -> RINGING und kommt beim abheben des Hörers das OK vom AVM Router. Dieses Paket wird jedoch recht merkwürdig fragmentiert!
Das erste Paket enthält 1472 Byte (soweit so gut) das zweite Paket enthält 8 Byte das dritte (!!) Paket enthält dann nochmals 18 Byte! Aus meiner Sicht ergibt das so keinen Sinn. Vermutlich wird das o2 Voice Gateway (oder eine vor geschaltete FW) dieses Paket verwerfen, wodurch dann keine RTP Verbindung vom GW zum Router zustande kommt und das Gateway noch immer einen Wählton zum Anrufer ausgibt.
Übrigens startet die Fritz!Box sofort nach dem OK den ausgehenden RTP Stream (korrekt auf Port 50000).
Auch bei mehreren Versuchen ergab sich immer die gleiche Situation, das OK Paket wurde in 3 Frames fragmentiert, wobei der erste (klar) und der zweite Frame (konstant 8Byte) immer die gleiche Größe aufwiesen. Nur die Framegröße des 3 Frames variierte leicht so um die 17-18 Byte. Gibt es hier eventuell ein Problem im IP Stack der Fritz!Box?!?!
Gibt es eine Möglichkeit die MTU Size des VoIP PVC einzustellen (zu verringern) um zu schauen ob dieses einen Einfluss auf die Fragmentierung hat?

Habe mich auch mal hingesetzt und einen Trace gezogen. Ich kann das Verhalten bestätigen.
Die SIP Meldung "200 OK" wird beim Annehmen eines Gespräches fragmentiert.
Eigentlich sollte das ja kein Problem sein, da der Empfänger das wieder zusammenfriemeln sollte, aber genau das scheint nicht zu passieren.
Ist das nun ein AVM-Fehler oder ein o2-Fehler?
Aus gut unterrichteten Kreisen habe ich erfahren, daß bei o2 tatsächlich keine Änderungen vorgenommen wurden,
allerdings ist nicht das ganze VoIP-Netz in o2 Hand. Da fummeln noch ein paar externe Firmen mit rum, so daß evtl. ohne Wissen von o2 Änderungen vorgenommen wurden.

Ich habe mal eine Support Anfrage an AVM gestellt und bin mal gespannt was die sagen.
 
Hallo,

sind es bei Dir auch drei Pakete, in die das OK fragmentiert wird?
Wenn ja, würde ich vermuten, dass dieser Fehler bei AVM liegt. Die Fragmentierung in drei Frames dürfte nämlich nicht ganz RFC konform sein.
Und wenn ich mich recht erinnere gab es in der Vergangenheit div. Angriffe mit fehlerhaft fragmentierten Paketen, die es ermöglichten auf den betroffenen Maschinen den IP-Stack abzuschießen oder gar Malicious Code auszuführen.
Daher will ich hoffen, dass das o2 Gateway diese Pakete verwirft! Diese Systeme sollten nämlich sehr gut abgesichert und gehärtet sein!
Was mich aber mehr irritiert ist die Info, dass o2 nichts geändert hätte. Es gibt ja scheinbar doch zumindest mehrere Leute hier, die eine Änderung festgestellt haben.
Wenn o2 eine nichts von einer solchen Änderung ihrer Produkte mitbekommen sollte, dann schein da in den Prozessen aber etwas nicht ganz zu stimmen und ich bekomme Angst, was da noch geändert wird, ohne dass sie es bemerken…
Dabei sollte es keine Rolle spielen, von wem die Systeme betrieben werden oder welche externen Firmen daran beteiligt sind!

Schönen Feiertag

mm3311
 
mm3311 schrieb:
Hallo,
sind es bei Dir auch drei Pakete, in die das OK fragmentiert wird?
Wenn ja, würde ich vermuten, dass dieser Fehler bei AVM liegt. Die Fragmentierung in drei Frames dürfte nämlich nicht ganz RFC konform sein.
mm3311

ja, ist bei mir genauso. Das Paket ist zu groß, weshalb es fragmentiert wird.

"IP Fragments (1496 bytes): #22( 1472 ), #23( 8 ), #24( 16 )"

Entweder wurden fragmentierte Pakete bisher bei o2 akzeptiert, oder die Pakete waren einfach nicht so groß und irgendeine Änderung sorgt nun dafür, daß das passiert.

Ich habe einen Trace mit dem o2-Zyxel-Router gemacht, da ist das Paket 1175 Byte groß!
Leider konnte ich mit Zyxel nicht vollständig tracen, die Info wird abgeschnitten, so daß ich nur den Anfang der Pakete sehen kann.
Wäre interessant zu wissen, was da drin steht.
Ich würde sagen, daß das Problem damit erkannt ist. Die Ursache für das zu große Paket scheint der Schlüssel für eine Lösung zu sein.
Vieleicht kommt ja was brauchbares von AVM. Ich melde mich, wenn ich eine Antwort erhalten habe.

mm3311 schrieb:
Was mich aber mehr irritiert ist die Info, dass o2 nichts geändert hätte. Es gibt ja scheinbar doch zumindest mehrere Leute hier, die eine Änderung festgestellt haben.
mm3311

Nun, vermutlich muß man nur mal den Richtigen fragen. Ich werde das mal weitergeben, vielleicht erreicht diese Info ja einen kompetenten Telefonica Mitarbeiter :)
 
Ich habe das schon länger verfolgt: Vor ein paar Wochen noch hatte Foristen schon ein von den sympthomen her ähnliches Problem mit der FB an O2, basierend auf dem Versuch die Voip in PVC 35 zu machen. Dann auf einmal liessen einige andere Forister verlauten, man bedarf gar keines dedizierten PVC für Voice, also hatten sie (auch) per Internet Zugriff auf den Voip Server/Gateway von O2, denke ich.

Dann letzte Woche ging nix mehr. Accesslisten oder Firwalls, bin leider technisch nicht so beleckt. Jedenfalls ging das dann wohl nicht mehr von ausserhalb des PVCs. Aus Sicht von O2 hat sich an den Kundenanschlüssen nichts geändert, man hat nur den Zugriff auf die Server "wieder" zugemacht, der aus welchen Gründen auch immer für eine gewisse Zeit offen war.

Da ging dann für manche foristen nix mehr. Durchdiskuttiert wurde wieder die Möglichkeit mit dem PVC 35, was aber noch nie jemand hinbekommen hat.

Hypthese: Die Fritzbox macht dann Probleme, wenn Voip per dediziertem PVC konfiguriert wird, sonst wäre es wohl zu keinem Zeitpunkt gegangen und schliesslich funktioniet die FB mit so jedem Voip Provider. Vielleicht solltet Ihr auch bei AVM ein Troubleticket eröffnen (würds selbst tun, aber bin nicht so fit) und gleich den Feature Request miteinbringen, der es ermöglicht für jede Telnummer zu definieren, welche PVC genutzt werden soll.
 
nucki schrieb:
Vielleicht solltet Ihr auch bei AVM ein Troubleticket eröffnen (würds selbst tun, aber bin nicht so fit) und gleich den Feature Request miteinbringen, der es ermöglicht für jede Telnummer zu definieren, welche PVC genutzt werden soll.

Ist ja bereits passiert....

Aber je mehr derartige Anforderungen bei AVM aufschlagen, desto eher sehen die überhaupt einen Sinn darin, dies zu realisieren.

Von daher wär's ganz schlau, wenn Du dies trotzdem auch tätest.
 
...was genau müsste ich denn an avm schreiben...mein Technikverständnis reicht leider nicht um den genau zu beschreiben, was ich will...mein Text würde da nur lauten...bitte Firmware so gestalten, dass O2 VOIP wieder nutzbar ist....nur reicht das sicher nicht ;-)...Hat jemand nen Standardsatz, damit ich das Problem genau erläutere?..Dann würden sicher auch mehr an AVM schreiben.

Weiterhin schönen Feiertag

Kevyo
 
Noch was ;-) Für die, die eine FB hinter dem UFO laufen haben.Seitdem ich die FB hinter den O2 Router gehängt habe, verliert mein voip Account andauernd die Verbindung. Müssen im O2 Router gewisse Ports freigeschaltet und bestimmte firewall Regeln erstellt werden? Als die FB alleine am Netz hing, gabs da keinerlei Probleme...
 
Hallo,

Also für mich ist das Problem der potentiell fehlerhaften Fragmentierung eine Sache für AVM! Aber es kann natürlich auch ein Workaround sein, die SIP Pakete zu verkleinern, damit keine Fragmentierung auftritt.
Wenn man sich die Traces anschaut, dann fällt schon auf, dass der SIP Message Header des OK Paketes recht groß ist (~ 1259Byte). Wäre interessant zu vergleichen, was die Zyxel-Box hier sendet. Und noch viel interessanter wäre es einen Parameter zu finden, um die AVM Box ein bisschen weniger geschwätzig zu machen! Leider sind die Parameter der voip.cfg nicht öffentlich zugänglich dokumentiert.
Hat hier niemand einen Business Kunden von o2 greifbar, der die FB nutzt und bei dem man mal in die Config schauen kann?!?! Wenn AVM hier nicht eine komplett neue FW geschrieben hat, sollte es eigentlich nur ein Parameter in der voip.cfg sein, der die ganze Sache wieder zum spielen bringt…

Ansonsten hab ich auch mal ein Ticket hierzu bei AVM geöffnet, denn die Fragmentierung sehe ich als echten Bug.

Viele Grüße

mm3311
 
kevyo schrieb:
...was genau müsste ich denn an avm schreiben...mein Technikverständnis reicht leider nicht um den genau zu beschreiben, was ich will...mein Text würde da nur lauten...bitte Firmware so gestalten, dass O2 VOIP wieder nutzbar ist....nur reicht das sicher nicht ;-)...Hat jemand nen Standardsatz, damit ich das Problem genau erläutere?..Dann würden sicher auch mehr an AVM schreiben.
Kevyo

Nicht zu vergessen, daß der Portbereich für RTP vom Benutzer festgelegt werden können muß.
Eine Nachricht an AVM in der Art "macht, daß o2 wieder geht" ist vielleicht nicht so detailliert wie es AVM gerne sehen würde, aber für alles andere kannst du aus den vorigen Beiträgen was zusammenkopieren.

Stichworte: RTP Portbereich, Fragmentierungsproblem

Btw. weiß jemand ob es üblich ist, bei zu großen Paketen von UDP auf TCP zu wechseln?
So scheint es die Norm ja zu beschreiben.
 
mm3311 schrieb:
Hallo,

Also für mich ist das Problem der potentiell fehlerhaften Fragmentierung eine Sache für AVM! Aber es kann natürlich auch ein Workaround sein, die SIP Pakete zu verkleinern, damit keine Fragmentierung auftritt.
Wenn man sich die Traces anschaut, dann fällt schon auf, dass der SIP Message Header des OK Paketes recht groß ist (~ 1259Byte). Wäre interessant zu vergleichen, was die Zyxel-Box hier sendet.

mm3311

habe ich doch schon gemacht (in einem der letzten Beiträge von mir erwähnt).
Beim Zyxel-Router ist das gesamte in zu verpackende Paket 1175 Byte groß, es findet keine Fragmentierung statt. Das ist der einzige Unterschied, den ich ausmachen konnte. Ich bin mir deshalb sicher, daß es das Problem ist.

Bei der Fritzbox ist das Gesamtpaket ein paar hundert Bytes größer und das ist dann halt zu viel. Die Norm sagt ja es sollen keine Pakete >1300 Byte entstehen.
 
Hallo,

dass hatte ich auch schon so verstanden.;)
Mir ging es mehr um die Unterschiede im Inhalt zwischen AVM und Zyxel. Leider hab ich keine Ahnung wie ich auf dem Zyxel einen Trace ziehe. (Findet man sicherlich hier irgendwo im Forum, war aber bisher zu Faul es zu suchen…)
Zudem fehlt dann noch immer der zugehörige Parameter um der FB das Quasseln abzugewöhnen.

Viele Grüße

mm3311
 
mm3311 schrieb:
Hallo,
dass hatte ich auch schon so verstanden.;)
Mir ging es mehr um die Unterschiede im Inhalt zwischen AVM und Zyxel. Leider hab ich keine Ahnung wie ich auf dem Zyxel einen Trace ziehe. (Findet man sicherlich hier irgendwo im Forum, war aber bisher zu Faul es zu suchen…)
Zudem fehlt dann noch immer der zugehörige Parameter um der FB das Quasseln abzugewöhnen.
mm3311

jo, so eine Parameterbeschreibung für die FB Konfigurationsdateien wäre was feines.
Bin gerade nicht zu Hause und kann deshalb nicht nachgucken wie die Datei heißt,
aber ich habe mir eine Beschreibung von Zyxel ergoogelt in der das Tracen beschrieben ist.
Man kann offline-tracen, also innerhalb der Box aufzeichnen und sich dann die Aufzeichnung ansehen,
oder online tracen, also die direkte Ausgabe in die Shell. Ich habe beides versucht,
leider funktioniert das nicht so gut wie mit der FB. Im offline Modus ist der interne Speicher anscheinend minimal,
so daß nicht viel aufgezeichnet wird. Online kann ich in der Shell den Speicher auf unbegrenzt einstellen, so geht nichts verloren.
Leider zeichnet er die Pakete immer im Stil "on wire 1225 Byte / captured 64 Bytes" auf,
d.h. nur einen Teil des Paketes, so daß ich nicht den kompletten Inhalt sehen kann wie bei der FB.

Wenn jemand weiß wie ich das ändern kann, dann immer her mit der Info!

Wir sind dicht dran..... :cool:


Hier noch ein kleine Ergänzung. Habs doch noch gefunden:

ftp://ftp.zyxel.com/P-2602RL-D1A/support_note/P-2602RL-D1A_3.40.pdf

Ab Seite 138 unten beginnt das Thema "using embedded packet trace"
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.