dtmfbox (AB/CB/CT VoIP/ISDN/Analog)

Hey, nur mal so als Info reingeworfen:

FRITZ!Box Fon WLAN 7170 (UI), Labor-Version 29.04.31-6572

hat nen AB an board... :) Von der Config her sehr mau, funzt aber gut, Nachrichten lassen sich unkompliziert auf dem USB-Stick speichern,
also für Configfaule wie mich DIE Lösung ;)
Link

so long...
burger
 
Stimmt.. wusste ich noch nicht... :-Ö
 
Die Frage ist nur, ob wir dei AB-Funktion der Labor-Version uns irgendwie zunutze machen können, um an die 1und1 Problematik anzuknüpfen...
 
Wahrscheinlich nicht und wenn doch, dann nur über einen Workaround (wie z.B. über die Rufumleitung). Der AB von AVM ist leider nicht OpenSource (soweit ich das mitgekriegt habe).
Keine Ahnung, was an den 1und1 Servern eingestellt ist ...

Wie dem auch sei, sobald ich es endlich schaffe den Source der dtmfbox zu uppen, kann da mal jeder selbst reinschauen. Der Grund warum ich das noch nicht gemacht habe liegt an der Patcherei der Lib. Das möchte ich am liebsten umgehen.
 
Ich habe eine Frage. Und zwar wollte ich das VoIP standardmäßig deaktivieren (wozu auch VoIP, hab ISDN), die Änderungen an der dtfmbox.cfg werden jedoch immer wieder überschrieben.

Daraufhin habe ich in der default.dtmfbox/dtmfbox.cfg folgende Änderungen durchgeführt:

Code:
DTMFBOX_VOIP=0
DTMFBOX_VOIP_CLIENT=0

Blöderweise übernimmt er die Änderungen auch nicht. Wie kann ich permanent einstellen dass VoIP deaktiviert ist? Denn sonst bekomme ich beim neustarten des Dienstes oder beim Ändern der Konfigurationen folgenden Fehler:

Code:
 20:45:00.494    voip_ctrl.c ERR: (120125) Unable to bind RTP socket
 20:45:00.494      dtmfbox.c ERR: Unable to initialize VOIP!
 20:45:00.495      dtmfbox.c Exiting...

Vielen Dank!
 
VoIP kann man in der Version noch nicht abschalten, da ich Teile von pjsip verwende um Wave-Dateien abzuspielen. Das werde ich aber in der nächsten Version berücksichtigen.
 
Hi!
Ich habe folgendes Problem:
Ich nutze die dtmfbox nur auf einer MSN per ISDN. Der Anrufbeantworter wird nicht genutzt, sondern nur die Steuerfunktionen.
Ich kann die box 2-3 Male anrufen, danach beendet sich die dtmfbox mit einem simplen "dtmfbox.c: Exiting..." mitten im Anruf. Wenn ich diese jetzt erneut versuche zu starten erhalte ich folgendes Log:
Code:
 23:13:01.664    capi_ctrl.c Init CAPI...
 23:13:01.677    capi_ctrl.c CAPI initialized!
 23:13:01.678    voip_ctrl.c Init VOIP...
 23:13:01.679    voip_ctrl.c ERR: (120125) UDP bind() error
 23:13:01.680      dtmfbox.c ERR: Unable to initialize VOIP!
 23:13:01.681      dtmfbox.c Exiting...
Der Start gelingt erst wieder nach einem Neustart der FritzBox.
Hat jemand eine Idee?

Gruß Jan

P.S. Kann die dtmfbox mehrere oder nur einen Steuerbefehl pro Anruf verwalten? (interessant wäre für mich z.B.: "PIN# *21# *32#")
 
@silberwolf: Das liegt daran dass VoIP standardmäßig aktiviert ist. Wenn du den Dienst neu startest, ist lustigerweise der Port immernoch gebunden und der Start des Dienstes schlägt fehl.

Hatte das Thema schonmal angesprochen (ich glaub sogar hier im Thread), mir wurde gesagt dass das komplette Deaktivieren von VoIP erst später geht.
 
Moin die herren/damen...*GRINS*

habe mir mal den spass gemacht und via top geschaut was meine box so tut...und siehe da...
Code:
/ $ top -bn 1
Mem: 29164K used, 1208K free, 0K shrd, 1384K buff, 8496K cached
Load average: 2.53 2.35 2.22
  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
 2006 root     R       2412  2000 91.6  7.9 dtmfbox
 2295 root     R        368  2217  8.1  1.2 top
  811 root     S N     3216     1  0.0 10.5 ctlmgr
  870 root     S N     3216   866  0.0 10.5 ctlmgr
  872 root     S N     3216   866  0.0 10.5 ctlmgr
  866 root     S N     3216   811  0.0 10.5 ctlmgr
 1976 root     S       2412     1  0.0  7.9 dtmfbox
 2039 root     S       2412  2000  0.0  7.9 dtmfbox
 2001 root     S       2412  2000  0.0  7.9 dtmfbox
 2000 root     S       2412  1976  0.0  7.9 dtmfbox
 2040 root     S       2412  2000  0.0  7.9 dtmfbox

Sie ist massiv beschäftigt...
iss i.o??
immerhin iss dtmf ja nu eigentlich im idle...aber wie man sieht 92%...

Kann da was falsch konfiguriert sein?
 
@Darkyputz:
das ist mir auch schon aufgefallen. Das komische ist, ich starte den Dienst neu und dann hab ich für drei Tage ruhe. Dann kommt irgendwann wieder so ein CPU-Hog.
Ich bin mir jetzt nicht sicher, ob das vielleicht ein Busybox Problem ist, da der Prozess mit vfork() gestartet wird. Bei dropbear passiert das auch, wie ich hier mal gelesen habe.

Man kann das reproduzieren, wenn man einen reboot durchführt und den Dienst auf "automatisch" stellt. Nach Boxstart ist die CPU Auslastung dann hoch. Starte ich den Dienst neu, geht sie ganz normal runter (bis zum nächsten Box-Start). Siehe hier.

Das passierte bei mir auch bisher nur in der ersten Shell.

Wie gesagt, damit bist du nicht alleine. Mich stört es auch. Es ist wie die Suche nach der Nadel im Heuhaufen.
In der dtmfbox hab ich in jeder Schleife mindestens ein sleep drin, damit die CPU kühl bleibt. Verstehe das irgendwie nicht...
 
Zuletzt bearbeitet:
also...soll ich den nu automatsich mitstarten lassen oder lieber per crond nach dem neustart etwas später??
habe ja da so einige möglichkeiten ;-)

helfe aber gern beim suchen...

meine test 7170 mit 14.3 mod und dtmf box hat das im übrigen nicht...aber da iss die dtmf box nicht kofiguriert...kann das dmait zusammenhängen??
 
mhh.. das habe ich in der tat noch nicht probiert. Der Ansatz klingt nicht schlecht. Sozusagen startest du das Programm mit der Standard-Konfig, ohne Accounts?

Hast du bei der Box (mit dem CPU-Problem) zufällig auch einen VoIP-Account miteingestellt?

Ich werde es mir heute abend anschauen.
 
ja, ich habe da den voip account konfiguriert...
aber da ch 1und1 habe geht der nicht...
muss ich auch ma mit rumtesten...
 
Es kann sein, dass irgendwas initialisiert wird, was beim booten vielleicht noch nicht zur Verfügung steht. Dazu müsste ich mal das rc.dtmfbox Skript anpassen und mitloggen.

Unter der Windowsversion der dtmfbox tritt das nicht auf, deswegen schwer zu debuggen... aber nicht unlösbar ;) (unter VC++ ist's doch einfacher als unter nem Text-Editor.)

Ich schau mal, dass ich das mit berlios auch auf die Reihe kriege.
 
Zuletzt bearbeitet:
Ich hab jetzt mal den Dienst auf 'manuell' gestellt und einen Eintrag in die /var/flash/debug.cfg gemacht:

Code:
sleep 30
/etc/init.d/rc.dtmfbox start

und siehe da, der CPU-Hog ist weg. Also muss der Start wohl verzögert durchgeführt werden, da irgendwas noch nicht initialisiert wurde. Ich schau mir das aber noch etwas an...
 
habe da nu was rausbekommen...
denke ich *GRINS*
wäre nochmal zu klären...
da ich die config incl aufnahmen auf dem stick habe, bekomme ich beim booten immer bla bla dtmf box cannot cd to ustor01...und dann iss er am prozessorzeit fressen...
kann es sein, das er sich aufgrund das er fürher fertig mit starten iss, als die box mit mounten da erger macht?
denn die cpu zeit probs habe ich nciht wenn ich keinen stikc angebe...ausser ich restarte die dtmf box manuell unter dienste...
wie müsste ich das machen, damit die dtmf box später starett, oder 5 min anch neustart neu gstartet wird?
 
Hi Darkyputz,

den Start kannst du verzögert durchführen, wie ich oben gezeigt habe. Nach dem Mount kannst du dann die dtmfbox aufrufen.

In der nächsten Version muss ich da wohl ein paar Checks mehr in das rc.dtmfbox Skript einbauen (u.a. ist der Stick gemountet). Es hat zumindest nichts mit der Konfiguration oder der dtmfbox an sich zu tun. Den Hog bekomme ich auch ohne USB.

Die Logausgabe zeigt mir ein ganz normales Programmverhalten. Warum die CPU da so hochschießt, ist mir ein Rätsel (busybox, irgendein Dienst muss gestartet sein??). Zumindest schonmal eine Lösung.

EDIT:
sehe gerade, es war sehr zeitnah ;)
 
Zuletzt bearbeitet:
ich habe das bereit über den mod cron gelöst...*GRINS*
aber 2 doofe ein gedanke ,-)

Code:
0 3 * * * /sbin/reboot
5 3 * * * /etc/init.d/rc.dtmfbox start
10 3 * * * httpd -p 86 -h /var/media/ftp/uStor01/webseite
 
so...mehrere starts...und kein 100% hog mehr...klappt also...dtmf box braucht also nen verzögerten start...dann iss er unschlagbar...
und das mit 1und1 kriegen wir auch noch hin...
 
So, ich habe auch noch einen Schönheitsfehler entdeckt:
Wenn die dtmfbox einen Ruf (ISDN) annimmt, dann wird im Callmonitor ein in:cancel erzeugt, was in meinem Fall ungünstig ist. Wäre gut, wenn das mit auf die ToDo Liste kommt.

Gruß Jan
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
245,952
Beiträge
2,243,260
Mitglieder
373,292
Neuestes Mitglied
Sinankarateke
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.