Welcher Codec für voIP-Buster?

Wow! Wurden die Werte noch mal erhöht von AVM? Da muss man ja froh sein, mit DSL 1000 überhaupt eine Verbindung hinzukriegen. ;-)
Das ist ja fast die doppelte Netto-Datenrate bei den meisten Codecs!

(Und ich weiß immer noch nicht, wie ich meine Box beim Booten zu Gesicht kriege! So ein Mist! Muss es doch mal unter Linux versuchen)
 
so direkt hab ich da keinen Link zu, hab das halt irgendwo gelesen und fand das auch logisch. Dass es diesen Unterschied in der Bandbreite zwischen europaeischem und amerikanischem ISDN gibt vonwegen 57600bps und 64000bps, ist ja kein Geheimniss. Wenn ich was finde, liefere ich nen Link nach :)
Was auch immer deine Fritzbox (oder meine auch, kein Ahnung) da hinschreibt vonwegen bits/second passt aber vorne und hinten nicht, z.B.:
...fritz.box voipd[1189]: G726-32: 70666 bits/second...
...fritz.box voipd[1189]: G726-32: 84800 bits/second...
Also da ist es wohl kein Geheimniss, dass G726-32 (auch als G721 bekannt) 32kbps benutzt, was dann mit Protokollheader so auf gut 50kbps kommt
das gleiche gilt fuer die Werte, die hinter den anderen Codecs steht
Was das also fuer Angaben sind weiss ich auch nicht, aber hat so direkt nix mit der Bandbreite zu tun :)
 
Diese Meldungen kommen übrigens auch, wenn Du den voipd killst und erneut startest. Beim Startvorgang kannst Du ihn dann im syslog beobachten.

Ich sehe übrigens anscheinend alles von Anfang an, hier mal ein Logausschnitt, als ich ein Reboot durchgeführt habe:
Code:
Aug 15 15:21:39 fritz.box voipd[1141]: Signal: termination
Aug 15 15:21:39 fritz.box voipd[1141]: signal detected, shutdown already in progress
Aug 15 15:21:43 fritz.box voipd[1189]: startup (AVM FRITZ!Box Fon WLAN 08.03.73 AVM SIP v1.06.14 Jul 21 2005 13:24:21)
Aug 15 15:21:43 fritz.box voipd[1189]: using capi controller 4
Aug 15 15:21:43 fritz.box voipd[1189]: using b1 protocol 1
Aug 15 15:21:43 fritz.box voipd[1189]: tel: supported
Aug 15 15:21:43 fritz.box voipd[1189]: ENUM enabled
Aug 15 15:21:43 fritz.box voipd[1189]: enumdomain: e164.arpa
Aug 15 15:21:43 fritz.box voipd[1189]: enumdomain: e164.org
Aug 15 15:21:43 fritz.box voipd[1189]: 0: ... configured
Aug 15 15:21:43 fritz.box voipd[1189]: 1: ... configured
Aug 15 15:21:43 fritz.box voipd[1189]: 2: ... configured
Aug 15 15:21:43 fritz.box voipd[1189]: 4: ... configured
Aug 15 15:21:43 fritz.box voipd[1189]: 5: ... configured
Aug 15 15:21:43 fritz.box voipd[1189]: 6: ... configured
Aug 15 15:21:43 fritz.box voipd[1189]: 7: ... configured
Aug 15 15:21:43 fritz.box voipd[1189]: 8: ... configured
Aug 15 15:21:43 fritz.box voipd[1189]: 8 useragents configured
Aug 15 15:21:43 fritz.box voipd[1189]: INFO led: off (value=0)
Aug 15 15:21:43 fritz.box voipd[1189]: priority is -20
Aug 15 15:21:43 fritz.box voipd[1189]: encaplen 32
Aug 15 15:21:43 fritz.box voipd[1189]: brutto speed 1184000/160000 voip speed 144000
Aug 15 15:21:43 fritz.box voipd[1189]: connstatus 0 -> 5
Aug 15 15:21:43 fritz.box voipd[1189]: ...: REGISTER starting
...
Und nachdem er sich dann überall registriert hat, kommt schon die Angabe der Codecs. Statt "..." kommen natürlich die SIP-URLs, klar.
 
Hm. Unter Windows meldet sich erst mal fröhlich das Netzwerk zwei mal ab und wieder an. Bis ich dann etwas von dem Log zu sehen kriege, ist es schon zu spät.
Logst Du mit einem Mac oder mit dem Debian Server?

@JSchling: Ich denke, dass die Box diese Werte als Grundlage für Ihre Payload-Berechnungen nimmt. Jetzt weiß ich auch wieder, wo ich die Zahlen gesehen habe.
Die Box verständigt sich ja mit der Gegenstelle über die Codecs, vergleicht die vorhandene Upload-Datenrate mit den oben genannten Werten und entscheidet, welche Codecs noch zur vorhandenen Bandbreite passen.
Der Grund für die hohen Brutto-Werte ist wahrscheinlich, dass AVM auf Nummer sicher gehen will, bevor ein Gespräch wegen zu geringer Bandbreite abbricht.
Code:
voipd[417]: allowed bandwidth 656000 for sip:[email protected]
voipd[417]: audio: 2 (<NORTPMAP>)
voipd[417]: audio: 2 (<NORTPMAP>) => (2 (G726-32/8000))
voipd[417]: audio: 101 (101 telephone-event/8000)
voipd[417]: audio: 101 (101 telephone-event/8000) => (101 (101 telephon
voipd[417]: audio: 100 (100 X-NSE/8000)
voipd[417]: audio: 100 (100 X-NSE/8000) => NOT CONFIGURED
voipd[417]: payload >>> 2
voipd[417]: payload >>> 101
voipd[417]: xxxxxxxxxxx - 7078 audio 2(G726-32)
voipd[417]: Codec G726-32 (2) - audio 70666 hold=none (none) (by local)
 
dm41 schrieb:
Logst Du mit einem Mac oder mit dem Debian Server?
Ich logge mit meinem Server unter Debian Sarge (Also Linux).[/quote]
Wird langsam eigentlich derbe OT, oder? ;-)
 
Ja, schon. Aber Faessje meldet sich ja nicht mehr... ;-)

Außerdem geht es ja im Grunde schon noch um die Codecs. Voipbuster war zwar der Aufhänger, aber die Codec-Bandbreiten und deren Auswirkungen gelten ja für alle Anbieter.
 
Und wo es schon so offtopic ist: vielleicht sind andere Betriebssysteme etwas schneller beim Aufbau der Netzwerkverbindung (so XY Millisekunden), aber wenn Windows meldet, dass keine Verbindung da ist beim Booten, dann ist dem auch so und auch bei anderen Betriebssystem nicht anders.
Die Netzwerkkarte wird halt erst vom Bootloader zur Verfuegung gestellt, z.B. um mit dem Recover-Tool ein Update einzuspielen, danach startet die Box ihr Betriebssystem und dabei wird die Netzwerkkarte vom Linux-OS initialisiert = sie ist kurz weg, unabhaengig vom verwendeten Betriebssystem physikalisch nicht ansprechbar, was ein anderes Betriebssytem vielleicht garnicht als Meldung bringt. Bei Windows duerfte die Meldung ja auch nur kommen, wenn der PC direkt mit der Box verbunden ist.
Wie gesagt, mag ein anderes Betriebssystem die Netzwerkverbindung schneller aktiv haben, wenn ein Hub/Switch dazwischen geschaltet ist, sollte sich unter Windows exakt das gleiche Loggen lassen wie bei einam anderen OS
PS: um vielleicht etwas beim Thema zu bleiben :) dass die angegebenen Bitraten hinter den Codecs die Mindest-Bitraten sind, die physikalisch vom DSL vorhanden sein muessen / frei sein muessen (fuer 2tes VoIP-Telefonat) koennte ich mir auch vorstellen, aber die Werte haben nichts mit den tatsaechlichen Bandbreiten der aufgefuehrten Codecs zu tun.
 
Meine Erfahrungen bezüglich Netzwerk und Windows sehen anders aus. Unter Linux (und auch MacOS) ist es z.B. kein Problem, eine SSH-Verbindung aufzubauen, dann die Netzwerkverbindung physikalisch zu trennen, neu zu verbinden und immer noch in der bestehenden Verbindung zu sein.

Windows hingegen scheint jegliche Netzverbindungen schon bei kurzen Unterbrechungen zu trennen. Und das dürfte es auch sein, wieso es mit Linux klappt. Die Netzwerkverbindung zum Syslog besteht, dann rebootet die Fritzbox, die Verbindung bleibt aber bestehen.
 
Hallihallo, ein Lebenszeichen :)

Hab immer noch keine Lösung des Problems.
Werd mich vorerst geschlagen geben und den voipbuster nicht mehr benutzen. Ich brauche sowieso etliche Versuche bis endlich mal eine Verbindung zustande kommt.

Gruß, Daniel
 
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.