.titleBar { margin-bottom: 5px!important; }

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

Dieses Thema im Forum "Asterisk ISDN mit mISDN" wurde erstellt von HobbyStern, 4 Nov. 2006.

  1. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    #1 HobbyStern, 4 Nov. 2006
    Zuletzt bearbeitet: 4 Nov. 2006
    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 :

    Code:
    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 :

    Code:
    Nov  3 08:32:59 asterisk kernel:
    
    Gespräch 2 äussert sich ebenso, vom Nov 3 , 10:37:32

    messages
    Code:
    Nov  3 10:37:32 asterisk kernel:
    
    notice
    Code:
    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
     
  2. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    #2 HobbyStern, 6 Nov. 2006
    Zuletzt bearbeitet: 6 Nov. 2006
    Ich konnte das ganze heute morgen schön replizieren, herausgekommen ist folgendes :

    Code:
    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
     
  3. crich

    crich Mitglied

    Registriert seit:
    1 Sep. 2005
    Beiträge:
    529
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  4. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    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
     
  5. princemo

    princemo Neuer User

    Registriert seit:
    4 Dez. 2006
    Beiträge:
    17
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
    Code:
    [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
     
  6. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    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
     
  7. princemo

    princemo Neuer User

    Registriert seit:
    4 Dez. 2006
    Beiträge:
    17
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hi Stefan,

    die Warnung erhalte ich ebenfalls:
    Code:
    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
     
  8. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    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
     
  9. princemo

    princemo Neuer User

    Registriert seit:
    4 Dez. 2006
    Beiträge:
    17
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
  10. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    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
     
  11. princemo

    princemo Neuer User

    Registriert seit:
    4 Dez. 2006
    Beiträge:
    17
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  12. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    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
     
  13. princemo

    princemo Neuer User

    Registriert seit:
    4 Dez. 2006
    Beiträge:
    17
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    ich wäre auch an einer lösung interessiert :)
    am Freitag werde ich ersteinmal den Asterisk auf Hardwarekonflikte untersuchen und dann berichten!
     
  14. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    Tu das mal - lspci -v sollte Klarheit schaffen.
     
  15. jackfritt

    jackfritt Mitglied

    Registriert seit:
    28 Dez. 2005
    Beiträge:
    325
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Hat sich das Problem bei dir erledigt ?


    Gruss,

    Jörg
     
  16. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    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
     
  17. jackfritt

    jackfritt Mitglied

    Registriert seit:
    28 Dez. 2005
    Beiträge:
    325
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    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
     
  18. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    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
     
  19. jackfritt

    jackfritt Mitglied

    Registriert seit:
    28 Dez. 2005
    Beiträge:
    325
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Super. Wußte nicht das es die option gibt. Direkt mal testen.

    Gruss,

    Jörg
     
  20. HobbyStern

    HobbyStern Aktives Mitglied

    Registriert seit:
    5 Dez. 2005
    Beiträge:
    1,837
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    vorhanden
    Ort:
    Ruhrgebiet
    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!