Suchergebnisse

der Workaround ist hier: Asterisk aus dem Source ziehen und neu kompilieren und installieren, dann läuft auch mISDN wieder vernünftig.

Zu dem Problem gibts inzwischen schon weiter Infos, einen bugreport gibts auch schon: http://bugs.beronet.com/bug_view_page.php?bug_id=0000266 Das ganze passiert deshalb weil trixxbox zusätzliche Patches zu asterisk macht, ohne dabei entsprechende Header-Pakete zu generieren. Damit lässt...

cause:3 == No route to Destination.

benutze doch einfach die Application SendText(Hello World).

Wir haben übrigens seit heute ein install-asterisk.tar.gz, welches Asterisk + zaptel + mISDN in aktuellen stable versionen installiert. Es ist optimiert für debian, sollte aber auch mit anderen distros laufen. Zu holen gibts das unter: http://www.beronet.com/downloads/install-asterisk.tar.gz

Die Meldung kommt bei jedem Verbindungsaufbau und ist gutartig.

deine Extension matched einfach schon früher. wenn deine extensions.conf z.b. etwa so aussieht: 0234-6545X. dann würde schon nach der zweiten Nachwahl matchen. Ich empfehl dir im PP fall wenn deine stammnr. 1234 ist und du 2stellige durchwahlen hast folgendes: exten =>...

Asterisk -> 1.2.10 zaptel -> 1.2.7 ? mISDN und mISDNuser -> cvs head chan_misdn -> 0.3.1-rc21 (bzw. wenn du noch bis Ende der Woche wartest dann rc22) Du wirst in deiner Konstellation mit den neuesten Versionen keine grösseren Probleme haben.

das problem ist in aktuelleren Versionen behoben, und kann durchaus die Ursache der Symptome sein die du hast.

was zeigt den dmesg bzw die syslog in diesem Zustand an? seit der rc10 hat sich ne Menge geändert. Du solltest tatsächlich mal auf ein höheres rc updaten.

das neue mISDN hat tatsächlich ein Problem mit einseitigem Ton und echo-cancel. Tatsächlich genügt es einfach echotraining=no in der misdn.conf zu setzen, denn hier liegt das Problem. Im nächsten chan_misdn wirds kein echotraining mehr geben, das funzt eh nicht. Der neue echocancel code...

tipp mal "make force" ein und danach nochmal "make install"

ja ich glaube der takt kann nur von hfcmultis gezogen werden.

den fix für den NT Stack bug gibst übrigens nach einem mISDNuser update.

Ich konnte am Freitag einen NT Bug fixen. Schick mir deine nt.log bitter per mail, kannste ja zippen, dann wirds klein, schicks einfach an support at beronet dot com. dann bekomm ichs auch.

das matched immer noch nicht weil du dieselbe callerid wie extension im dialplan einträgst. mach deine extensions.conf einfach so: exten => 929468,1,Set(FROM_DID=929468/929468) exten => 929468,n,Goto(ext-local,203,1) das sollte dann gehen

sieht so aus als ob die gewählte nr. nicht in der extensions.conf enthalten ist.

sterkel: das ist normal. Die Schicht 2 startet alle 10 Sekunden einen timer um zu prüfen ob das gegenüber noch fit ist.

bist du sicher das nur die führende ziffer nicht richtig ankommt ? oder sind auch andere ziffern nicht richtig erkannt?

das ist aber ein bug von chan_sip würde ich sagen. der müsste einen sinvolleren cause zurückliefern. Aber du hast schon recht es wäre schön wenn man den cause aus der extensions.conf heraus beeinflussen kann, ich würde dich bitten dafür einen feature request für 0.4.0 bei bugs.beronet.com...