mISDN RC 25 -> "Bridge failed on channel..."

[HobbyStern]

Mit der "neuen" RC23 habe ich seit dem Update hin und wieder merkwürdiges beobachtet - leider bis dato (noch) sehr schlecht dokumentiert.

Vorweg : Die RC21 lief monatelang stabil.

Mitten in einem Gespräch bricht ein eingegangener Anruf weg, dies passiert sehr selten und ist damit schlecht zu dokumentieren, seit Tagen habe ich nach einer Erklärung gesucht, einen Hinweis habe ich nun gefunden, zwei Gespräche habe ich herausgepickt :

Gespräch 1 : Zeit : Nov 3 , 08:32:59
Als Hinweis (Notice) spuckt Asterisk dieses hier aus :

Nov  3 08:32:59 WARNING[29305] res_features.c: Bridge failed on channels mISDN/1-1 and SIP/41-0842bf68

Auf der Suche nach Erklärungen habe ich nun die verbosity von 1 auf 3 erhöht, das ganze auch für mISDN mit debug=1 gesetzt. Bis dato hatte ich noch kein Glück

In der System "messages" habe ich folgenden Blankoeintrag gefunden :

Nov  3 08:32:59 asterisk kernel:

Gespräch 2 äussert sich ebenso, vom Nov 3 , 10:37:32

messages

Nov  3 10:37:32 asterisk kernel:

notice

Nov  3 10:37:32 WARNING[30632] res_features.c: Bridge failed on channels SIP/10-0843a868 and mISDN/1-u183

Kann das ganze jemand bestätigen, hat noch jemand ein solches Problem entdeckt ?

Ich werde nun die RC23 etwas laufen lassen um den Fehler zu reproduzieren und dann mal mit mehr Logs aufwarten zu können, ab Ende der Woche wird dann aber die RC21 wieder eingesetzt, wenn ich es nicht beheben kann, weil dann gehts für mich in den Süden

Grüsse, Stefan

 

[HobbyStern]

Ich konnte das ganze heute morgen schön replizieren, herausgekommen ist folgendes :

Mon Nov  6 09:51:47 2006: P[ 1]  I IND :SETUP oad:<Anrufer> dad:<"Wir"> pid:36 state:none
Mon Nov  6 09:51:47 2006: P[ 1]  EXPORT_PID: pid:36
Mon Nov  6 09:51:47 2006: P[ 1]  I SEND:SETUP_ACKNOWLEDGE oad:0<Anrufer> dad:<"Wir"> pid:36
Mon Nov  6 09:51:47 2006: P[ 1]   --> bc_state:BCHAN_CLEANED
Mon Nov  6 09:51:47 2006: P[ 1]  After SETUP BC
Mon Nov  6 09:51:47 2006: P[ 1]  I IND :INFORMATION oad:0<Anrufer> dad:<"Wir"> pid:36 state:WAITING4DIGS
Mon Nov  6 09:51:47 2006: P[ 1]  * IND : Indication [3] from <"Wir">0
Mon Nov  6 09:51:47 2006: P[ 1]   --> * IND :   ringing pid:36
Mon Nov  6 09:51:47 2006: P[ 1]  I SEND:ALERTING oad:0<Anrufer> dad:<"Wir">0 pid:36
Mon Nov  6 09:51:47 2006: P[ 1]   --> bc_state:BCHAN_ACTIVATED
Mon Nov  6 09:51:47 2006: P[ 1]  After SETUP BC
Mon Nov  6 09:51:47 2006: P[ 1]   --> * SEND: State Ring pid:36
Mon Nov  6 09:51:47 2006: P[ 1]   --> incoming_early_audio off
Mon Nov  6 09:51:56 2006: P[ 1]  * IND : Indication [-1] from <"Wir">0
Mon Nov  6 09:51:56 2006: P[ 1]   --> * IND :   -1! (stop indication) pid:36
Mon Nov  6 09:51:56 2006: P[ 1]  * ANSWER:
Mon Nov  6 09:51:56 2006: P[ 1]   --> ECHO OFF
Mon Nov  6 09:51:56 2006: P[ 1]  I SEND:CONNECT oad:0<Anrufer> dad:<"Wir">0 pid:36
Mon Nov  6 09:51:56 2006: P[ 1]   --> bc_state:BCHAN_ACTIVATED
Mon Nov  6 09:51:56 2006: P[ 1]  After SETUP BC
Mon Nov  6 09:51:56 2006: P[ 1]  ec_enable
Mon Nov  6 09:51:56 2006: P[ 1]  Sending Control ECHOCAN_ON taps:32 training:0
Mon Nov  6 09:51:56 2006: P[ 1]  I IND :CONNECT_ACKNOWLEDGE  oad:0<Anrufer> dad:<"Wir">0 pid:36 state:CONNECTED
Mon Nov  6 09:52:19 2006: P[ 1]  * IND : Indication [3] from 35
Mon Nov  6 09:52:19 2006: P[ 1]   --> * IND :   ringing pid:36 but Connected, so just send TONE_ALERTING without state changes
Mon Nov  6 09:52:28 2006: P[ 1]  * IND : Indication [-1] from 35
Mon Nov  6 09:52:28 2006: P[ 1]   --> * IND :   -1! (stop indication) pid:36
Mon Nov  6 09:53:15 2006: P[ 1]  I IND :DTMF_TONE oad:0<Anrufer> dad:<"Wir">0 pid:36 state:CONNECTED

--> DTMF Ton wurde gesandt und dann wurde aufgelegt !
Ausschnitt aus meinem DTMF Log :
Nov  6 09:53:26 DTMF[22637] channel.c: Zap/1-1 : *


Mon Nov  6 09:53:26 2006: P[ 1]  I IND :DISCONNECT oad:0<Anrufer> dad:<"Wir">0 pid:36 state:CONNECTED
Mon Nov  6 09:53:26 2006: P[ 1]  hangup_chan
Mon Nov  6 09:53:26 2006: P[ 1]  -> queue_hangup
Mon Nov  6 09:53:26 2006: P[ 1]  I SEND:RELEASE oad:0<Anrufer> dad:<"Wir">0 pid:36
Mon Nov  6 09:53:26 2006: P[ 1]   --> bc_state:BCHAN_ACTIVATED
Mon Nov  6 09:53:26 2006: P[ 1]  * IND : HANGUP pid:36 ctx:buero_tele dad:35 oad:0<Anrufer> State:CONNECTED
Mon Nov  6 09:53:26 2006: P[ 1]   --> cause:16
Mon Nov  6 09:53:26 2006: P[ 1]   --> out_cause:16
Mon Nov  6 09:53:26 2006: P[ 1]   --> state:CONNECTED
Mon Nov  6 09:53:26 2006: P[ 1]  Channel: mISDN/1-1 hanguped new state:CLEANING
Mon Nov  6 09:53:26 2006: P[ 1]  ec_disable
Mon Nov  6 09:53:26 2006: P[ 1]  I IND :RELEASE_COMPLETE oad: dad: pid:36 state:CLEANING
Mon Nov  6 09:53:26 2006: P[ 1]  hangup_chan
Mon Nov  6 09:53:26 2006: P[ 1]  No need to queue hangup
Mon Nov  6 09:53:26 2006: P[ 1]  Cannot hangup chan, no ast
Mon Nov  6 09:53:26 2006: P[ 1]  release_chan: bc with l3id: 201a3

Wie ich gemarkert habe ist ein DTMF Signal gesendet worden (*) - das hat dann anscheinend Asterisk zum auflegen bewogen.

Also - immernoch - die alte DTMF Ton Geschichte ( http://www.ip-phone-forum.de/showthread.php?t=102357 )

- EDIT -

Nun nochmals "herumgespielt" - und um folgendes Szenario schlauer geworden :

Testanruf "Echotest" intern (SIP->Asterisk)
TestDTMFTon : "*" bzw "#"
Ergebnis - Ton erklingt, es passiert NICHTS

Testanruf "Echotest" extern (SIP->Asterisk->mISDN->DTAG->mISDN->Asterisk)
TestDTMFTon : "*" bzw "#"
Ergebnis :
Beim "#" möchte Asterisk vermitteln
Beim "*" legt Asterisk "komisch" auf, s.h. das Gespräch wird in meinem Snom immernoch als aktiv angezeigt, man hört nur nichts mehr, im Log ist das Gespräch aber (wie oben) beendet.

Ich kann nicht ganz nachvollziehen warum mISDN die Töne immernoch akzeptiert?!

Grüsse, Stefan

 

[crich]

mISDN scheint den DTMF Ton vom AMT zu erhalten.. Asterisk selbst legt dann auf, lässt sich in der features.conf beeinflussen.

Ich habe vor einiger Zeit mal eine option namens:

dtmftreshold=millisekunden

in die /etc/misdn-init.conf eingebaut. Du kannst mal versuchen diesen Wert auf 150 oder 200 zu erhöhen.

 

[HobbyStern]

Hi,

schön Dich hier zu lesen.

Dtmftreshold habe ich gesetzt, gestern - radikalerweise auf 450.

Es scheint so als mISDN aus der Fehlerliste der DTMF Sender heraus wäre - leider hält sich der Rest ...

siehe hier.

Einen "selbstgetippten" Ton findet mISDN aber immernoch und leitet ihn durch, das ist ja auch gewollt.

Aber die Funktion scheint sehr gut für mISDN zu sein !


Danke! Stefan

 

[princemo]

Hi HobbyStern,

ich habe genau das gleiche phänomen wie du. Sobald die *-Tase während eines Gespräches gedrückt wird, bricht das Gespräch ab, bzw. die Gesprächspartner hören sich nicht mehr...
meine features.conf

[featuremap]
blindxfer => *1         ; Blind transfer
disconnect => *                ; Disconnect
;automon => *1                  ; One Touch Record
atxfer => *2                     ; Attended transfer

hast Du die rc23 noch am laufen (mit dtmftreshold ?), oder bist Du wieder auf die rc21 zurück gegangen?

--- Eingesetzte Versionen ---
Asterisk 1.2.12.1
Suse 10.1
mISDN 0.3.1-rc23 (Beronet BN2S0)
---

Vielen Dank im Voraus
Grüße Timo

 

[HobbyStern]

Ich bin bei meiner *First Choice* RC23 geblieben, das Problem besteht weiterhin, bei Dir wäre mein erster Gedanke :

disconnect => *

auszukommentieren.

Hast Du auch meine Meldung bekommen als Warning (Bridge failed...)

Anbei : Das Problem besteht weiterhin, jedoch hat der dtmftreshold (ohne "h") vieles gebessert (weniger bridge failed)

Grüsse, Stefan

 

[princemo]

Hi Stefan,

die Warnung erhalte ich ebenfalls:

Dec  2 11:44:25 WARNING[2587] res_features.c: Bridge failed on channels SIP/410-08c2d640 and mISDN/1-u1710

den dtmftreshold - wert habe ich in der misdn-init.conf (400) gesetzt, welche funktion bewirkt das "h"?

Habe deine Infos erst gestern konfiguriert, mal schauen ob's die nächsten Tage besser wird. ich melde mich

Grüße Timo

 

[HobbyStern]

das "h" ist eher ein itüpfelchen

in zaptel heisst die variable : "dtmfthreshold" in misdn "dtmftreshold"

Daher "mit h" und "ohne h"..

Ahja , was für Hardware hast Du verbaut ? (Foschi, ja - es ging nicht ohne Spuren an mir vorbei)

Grüsse, Stefan

 

[princemo]

gudn'abet

der PC kommt von Siemens: http://cpp.fujitsu-siemens.com/cpp2/de/db/esprimo_edition_p2524xx.pdf P2510 Pentium 4
ISDN: 2 x Beronet BN2S0 (eine wurde nachträglich eingebaut, sonst wäre es eine BN4S0 geworden)
OS: Open Suse 10.1

wie läuft's denn momentan bei dir?

Grüße Timo

 

[HobbyStern]

Es hat sich nicht soooo viel getan, Du hast ja bestimmt die in Beziehung stehenden Threads gelesen (Thema : in etwa : "DTMF Ton"), das zufällige Bridge failed tritt bei mir in Zusammenhang mit wild ausgespuckten DTMF Tönen auf, da kommen dann einsen, zweien, achten, und ab und mal eine Raute (Asteriskaufforderung : Vermitteln) oder ganz schlimm halt, ein Sternchen - was Asterisk dazu bringt : Leg auf!

Ich habe mittlerweile die Asterisk Mailingliste genervt, das gesamte Board hier sowieso, die Mailingliste von chan misdn, misdn. Hab die Karten getauscht, IRQs geprüft, talkoff entgegengegangen, system frisch installiert, kernel getauscht, hw getauscht usw usf -- nichts hat geholfen.

Der neuste Einfall war den dtmft"h"reshold auch bei zaptel zu empfehlen, da kann man das ganze bis dato nicht einstellen - (dazu siehe diesen thread : "WANTED Zaptel Patch Schreiber" - aber das ganze scheint im Sand zu verlaufen...

Naja, wie dem auch sei, nett zu lesen das ich auch hier nicht der einzige bin - es wäre sehr nett wenn du eine lösung findest - lass es mich auch wissen Ich bleib dran.

Grüsse, Stefan

 

[princemo]

Ich habe mir damit beholfen, nur noch den attendant transfer zu aktivieren und alles nur mit der #-taste zu steuern. d.h. einmal drücken der #-taste wird schon ein attendant transfer eingeleitet...kann zwar auch mal passieren, dass ein Anrufer ungewollt in den Tranfervorgang geleitet wird, aber dann kommt er wenigstens nach dem Timeout zurück Blind-Tranfer ist völlig deaktiviert!

was ich mir auch überlegt habe ist folgendes:
das Sip-Protokoll bietet ja von Haus aus das Transferfeature an, wenn es bei mir schlimmer wird, werde ich das res_features.so entladen und nur noch über diese Methode arbeiten. Ich weiß, dass dann das komfortable transferieren zu anderen channels, ISDN, ZAP usw. nicht funktioniert - was ich aber in meinem Fall auch nicht brauche.
Oder hast Du so etwas auch schon getestet?

Wodurch werden bei dir die DTMF-Töne generiert? Alleine durch das TALKOFF-Phänomen, oder passiert das auch, wenn keiner spricht? Bei mir kommen sie lediglich während des Telefonates zustande - hauptsächlich bei weiblichen Gesprächspartnern :-Ö

Du hasttest in deinem ersten Beitrag geschrieben, dass Du mit der rc21 monatelang keine Probleme hattest - warum steigst du nicht wieder um?

Grüße Timo

 

[HobbyStern]

Nein, RC21 war leider auch kein Wundermittel.

Ich hatte zugefügt : "Ich habe es nicht darauf getestet" - schliesslich war mir nicht klar das ich mit solchen einem Problem herumjuckel ,)

talkoff ist definitiv ein Problem und ja , ich kann es bestätigen das die Damen der Nation das Problem besser erzeugen, aber auch ein lauter "Chef" kann das erreichen.

Wodurch die Töne kommen kann ich nur insofern eingrenzen : talkoff, ggf. Hardwareprobleme (obwohl ich was weiss ich was getan habe um das auszuschliessen - foschi schrieb mir dazu ich sollte doch von 2 hfc auf eine bn2so umstellen, jedoch wenn ich lese das du das auch hast - es bleibt die konstellation 2 x hfc + 1 x Wildcard, jedoch spuckt jegliche Systeminfo oder Analyse KEINE Konflikte aus) (langeklammerzu)

Ich würde sehr gerne wissen woher soetwas stammt, mich wundert es nur - ich habe bereits mit einigen darüber geschrieben, einige schrieben mir ähnliches, aber niemand ist mehr darauf eingegangen, leben die alle damit ?

Das entladen der res_features wäre ein Versuch um auszuschliessen das es daran liegt, aber für mich ist das leider nicht machbar.
Ich möchte mir gerne mal in nächster Zeit einen zweiten Asterisk wieder zusammenbauen um das gleiche Szenario mal radikaler zu testen...

Grüsse, Stefan

 

[princemo]

Ich würde sehr gerne wissen woher soetwas stammt, mich wundert es nur - ich habe bereits mit einigen darüber geschrieben, einige schrieben mir ähnliches, aber niemand ist mehr darauf eingegangen, leben die alle damit ?

ich wäre auch an einer lösung interessiert
am Freitag werde ich ersteinmal den Asterisk auf Hardwarekonflikte untersuchen und dann berichten!

 

[HobbyStern]

Tu das mal - lspci -v sollte Klarheit schaffen.

 

[jackfritt]

Hat sich das Problem bei dir erledigt ?


Gruss,

Jörg

 

[HobbyStern]

Erledigt ist es bis dato nicht - ich habe es in die Knie gezwungen (siehe WORKAROUND Thread) - in dem ich ihm einfach die Sensitivität für den DTMF Ton etwas nahm. Er erkennt immernoch jeden Tastendruck, die Logs zeigen aber nur noch einen Bruchteil der damaligen Tönchen an und ich nehme von diesen noch 50% weg da es ja auch mal gewollte Tönchen gibt

Ich habe vor einiger zeit mit jemanden aus Miami geschrieben - er erlebte exakt dasselbe und konnte sich nicht behelfen, wir haben die Hardware verglichen und es war auffällig das auf jedem System auf welchem dieses passiert ein AMD im Spiel ist...aber das wird nicht alles sein, es wird an einer Kombination zwischen irgendwas liegen...

Wieso? Hast Du ähnliches Theather?

Grüsse, Stefan

 

[jackfritt]

Ich hatte heute morgen 2.B Kanäle mit Gesprächen belegt. Ein Gespräch wurde beendet und das andere brach scheinbar gleichzeitig auch zusammen. Obwohl ja beide nichts miteinander zu tun hatten außer auf derselben Karte zu laufen. Dort wo das Gespräch einfach so abbrach war kurz vorher ein paar DTMF Töne zu hören. So wurde mir berichtet. Ich werde das hier mal weiter beobachten. Habe auch schonmal die * in features.conf deaktiviert.


Gruss,

Jörg

 

[HobbyStern]

Schau mal in die logger.conf und setze ein eigenes File für das DTMF-Logging, dann siehst Du recht schnell was los ist...

Grüsse, Stefan

 

[jackfritt]

Super. Wußte nicht das es die option gibt. Direkt mal testen.

Gruss,

Jörg

 

[HobbyStern]

Nun Kreuzfeuern wir in 2 Threads, lass HIER bleiben - auch wenn es ein bisschen daneben liegt, schliesslich ist es defakto KEIN mISDN Problem.

Grüsskes, Stefan!