merlinab

Habe ich auch schon gelesen. Die Amerikanische Version der Fritzbox hat das aktiviert - nur bei der Deutschen haben die sich wohl die Lizenzgebühren gespart. Aber man kann es noch nachträglich aktivieren. Ich habe nun auch die RTP-Größe auf 20ms gestellt und gerade zwei Lizenzen für den Asterisk des G.729 bestellt. Ich denke der ist dann morgen da und wir können das ganze dann mal über den G.729 testen ;)

Hallo, also es wird in beide Richtungen der A-Standard verwendet. Habe gerade auch nett im Netz gesucht und solche Einstellungen kann man bei der FritzBox nicht machen. Ich schreib dem Support mal ne Mail. Aber eigendlich sollte doch der Asterisk solche unterschied ausgleichen können, oder? Hab aber ne nette Seite gefunden um "mehr" aus der Box raus zu holen, http://www.wehavemorefun.de/fritzbox/Main_Page mal schauen ob da sowas villeicht drinne steht...

Was würdest du denn für akzeptabel halten bei einer unstrukturierten 2MBit Leitung an Paketverusten pro Stunde bei nem normalen ping jede Sekunde?

In diesem Beispiel waren relativ wenig Knacken drinne. Im AU File höre ich es wesendlich geringer als im Telefon (meine ich). Ich muss das aber morgen noch mal testen wo mehr Knacken auftritt - ich denke das ist nicht 100% represenatativ. Interessanterweise sind die RTP-Pakete von der FirtzBox mit 294 Bytes größer als die von dem * mit 214 Bytes. (Ein paar dutzen überflogen) Ja nen leichtes Rauschen hört man, aber das ist nicht besonders störend. Ich denke das ist extra so, damit es keine Totenstille gibt, oder? Ob das ein A oder U Standard ist sehe ich hier leider nicht. Steht nur als Payload-Type: ITU.T G.711 PCMA (8) Ja das Knacken ist auf beiden Seiten nur verhäuft auf der FritzBox Seite - deswegen auch der Verdacht das die ne Macke haben könnte, wobei ich glaube das wäre nur ein teil denn die Paketverluste versuche ich jetzt mal mit 24 Dauerpings zu beobachten... Achso, ich dachte dafür muss man blechen oder nen Zertifikat haben um da rein zu kommen. Muss ich mal schauen ob die mir nen Login geben ;) Also meinst du mit dem Dubley-Mixmatch also, das das Ethernet-Interface z.B. auf fulldublex läuft und der Switch das nicht packet?

Mist nbar via SNMP wird von meinem IOS c3620-ik9o3s7-mz.123-1a.bin nicht unterstützt, jedenfalls laut http://tools.cisco.com/Support/SNMP/do/MIBSupport.do?mibname=CISCO-NBAR-PROTOCOL-DISCOVERY-MIB ;-) - Schade wäre ja auch zu schön gewesen. Weiß du eigendlich, ob ich das IOS von einer 3620 auf eine 3640 kopieren kann ohne probleme?

zu 1) Erste Link hat leider nen PW drauf - du hast das nicht zufällig als PDF oder so ;) zu 2) Hab leider noch nix von unserem Partner gehört - hoffe das das spätestens morgen was gibt zu 3) Jeap werde ich direkt mal testen. Was meinst du denn mit Duplex/Seed Mismatch? Ich hab jetzt mal nen Testgespräch mitgedumpt und mit Ethrereal Analysiert. Ich wusste gar nicht, dass Ethereal auch so gut mit RTP klar kommt. Gefällt mir immer besser das Proggi ;) Auf die forward ist alles top in ordnung (auch keine Kunst, hab das auf dem * mitgeloggt) und auf dem rev-Kanal 3463 RTP-Paketen 21 verluste und 8 seq fehler. Diesmal waren nur wenig, aber hörbares Knacken dabei... Jitter bleibt immer unter 0,00x und max delay ist 0,24 - klingt doch eigendlich gut, oder? Aber ist schon erschreckend, wie easy man daraus ein .au File machen kann ;) Ich denke ich werde morgen mal die FritzBox tauschen lassen... Auf der anderen Seite (FritzBox) kann ich wohl nix mitdumpen da der Linux ja hinter der Fritzbox steht ;((

Hi, Du bist auch Tag und Nacht Online ;-) Ich musste leider heute Vormittag zum Kunden... Also wir haben folgende Kontelation: TK-Anlage von Agfeo --> Asterisk-Server --> Cisco Catalyst --> Cisco 3620 bzw 3640 --> 2MBIT --> 1600er --> dedizierte Standleitung nach Frankfurt --> 6 MBit DSL+Fastpath --> FirtzBox 7050 --> 2x ISDN-Telefone Ich fahre zu mindestens auf unseren 3620/3640 Staitstiken via rrd über Mem und CPU der Ciscos und da ist denke ich noch ne menge luft. Wie das auf der 1600er aussieht muss ich erfragen. Solange die CPU der 1600er aber nicht am Limit ist - sollte das doch kein Problem geben, oder? Mit "ip rtp priority" aktiviere ich doch ein Pririty Queing bei dem alle RTP-Pakete erst übertragen werden bevor irgendwas anderes dran kommt und wenn es viele RTP-Pakete gibt kommt eben nix anderes durch die Leitung, oder? Ist das CPU-Schonender? Was meinst du mit Cisco SAA? Zurzeit monitore ich die Ciscos klassisch den Traffic mit MRTG und CPU/Mem mit RRD-Tools. Schön wäre wirklich ne nette RRD-Statistik über Infos wie: Delay, Packet Dropt, wieviel ist davon HTTP, SMTP, FTP, RTP, SIP, etc. Geht das mit SSA? Ich glaube dann haben wir echt ein Problem mit Paketverlusten. Ich dachte immer so 1-2% wären OK. Im Ping habe ich eigendlich nur minimale Paketverluste zu verzeichnen aber ein Ping ist ja auch nicht soo auschlaggeben. Gibt´s ne bessere Methode?

Mit QCheck habe ich schon etwas rumgespielt und es ist etwas komisch da in der Regal alles top ist und der delay immer so unter 40ms aber manchmal gibt es unerklärliche Paketverluste und beim Telefonieren hab ich irgendwie ab uns zu mal unangenehmes knacken ;( Kann ich mit QCheck auch ein MOS testen? Ist Chariot auch free? Schade ist nur, das QCheck nur unter Win läuft. Ich bin hier dabei nen Asterisk aufzusetzen (und bin echt begeistert) und der läuft nun mal auf Linux so das ich nur so ungefähre Tests machen kann. Was setzt du denn ein, klassisches Cisco Skinny? Aber "show ip nbar proto" ist ja klasse - sowas hab ich schon wirklich gesucht um endlich herrzufinden was da eigendlich für der Traffic drauf geht ;-) Aber irgendwie scheint da nur RTP bis jetzt eingekommen zu sein. Muss ich mal schauen, was morgen während des Tages abgeht: Input Output Protocol Packet Count Packet Count Byte Count Byte Count 5 minute bit rate (bps) 5 minute bit rate (bps) ---------------------------------------------------------------------------- rtp 731 0 70971 0 0 0 Bei der Police-map sieht das schon gar nicht so schlecht aus: Class-map: VoIP-RTP (match-all) 729 packets, 63503 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol rtp Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 33 (%) Bandwidth 509 (kbps) Burst 12725 (Bytes) (pkts matched/bytes matched) 126/10923 (total drops/bytes drops) 0/0 Nun muss ich mal schauen was morgen so abgeht und hoffen das ich das auf auf der anderen Seite realisierbar ist. Wahrscheinlich brauche ich da erstmal nen neues IOS für die schwache 1600 auf dieser Seite ;-((

Hi daking super danke dir vielmal. Und das soll jetzt wirklich bewirken, dass der VoIP-Traffic voran hat und sich so verhält als wäre die Leitung frei?

Hi Daking, super, durch das "ip cef" und "ip route-cache cef" hat er nun auch das "ip nbar protocol-discovery" auf dem Ethernet gefuttert ;) Nun muss ich mal schauen wie sich die Leitung bei Last reagiert. Kann ich irgendwie kontrollieren was so in der Que hängt? Ich hab schon etwas "show queue Serial1/0" gefunden, aber so recht schlau werde ich da jetzt nicht ;(

Hi, leider sagt er mit bei "ip nbar protocol-discovery" den Fehler "CEF or distributed CEF switching is required for NBAR 'protocol discovery' command" Scheinbar fehlt hinter dem Befehl noch nen Parameter. Hast du eine Idee welcher? #ip nbar protocol-discovery ? <cr> Danke dir für deine super Hilfe!

mit fa0/1 meinst du bestimmt das Ethernet-Interface. Sprich bei mir würde das so aussehen: LAN ==> Ethernet0/0 ==> Serial1/0 --- 2 MBIT ---> <-- snip --> interface Ethernet0/0 ip nbar protocol-discovery exit class-map match-all VoIP-Signalling match access-group 101 class-map match-all VoIP-RTP match protocol rtp exit policy-map QOS class VoIP-RTP priority percent 33 class class-default fair-queue exit Serial1/0 service-policy output QOS exit <-- snap --> Und das ganze am besten aus beide Seiten der 2MBit, oder?

Ja, den G.729 würde ich auch gerne benutzen, allerdings wird der leider nicht von der FritzBox unterstützt ;(

Hallo nochmal, ich habe im netz ein ähnliches iptables-Statement gefunden: -A OUTPUT -p udp -m udp --dport 5060 -j DSCP --set-dscp 0x1a -A OUTPUT -p udp -m udp --sport 10000:20000 -j DSCP --set-dscp 0x2e denn bei deinem sagt er iptables-restore v1.2.11: DSCP `104` out of range Selbst wenn das mit iptables soweit hinhaut, weißt du ob eine AVM 7050 Box die DSCP richtig setzt? Denn von der anderen Seite muss ich das ja auch entsprechend setze. Hast du zufällig auch eine nbar-Lösung zur Hand?

Hmm, dumme Frage: DSCP ist doch zum Priorisieren von Paketen da. Aber in meinem Asterisk kann ich lediglich die TOS-Felder definieren. Meine ich zu mindestens. Bedeutet das also, dass ich eigendlich nur DSCP=46 höher priorisiere und nicht den RTP-Traffic? Sprich ich muss dann erst noch ne Möglichkeit finden wie ich den RTP-Traffic auf DSCP=46 setzen kann? Was meinst du mit nbar?