sporadisches "peer buys"

Toggle sidebar Toggle sidebar
Upgrade 3CX to v18 and get it hosted free!
T

theWireless

Neuer User
Mitglied seit
20 Feb 2007
Beiträge
59
Punkte für Reaktionen
0
Punkte
6
Hallo,
ich setze Asterisk mit einer FritzCard in Verbdindung mit chan_capi und mehreren SIP-Telefonen ein. Der Asterisk hängt zusammen mit einer TK-Anlage für's analoge Fax am NTBA.
Sporadisch und nicht reproduzierbar kommt es jedoch vor, dass das Telefon beim Rauswählen dieses mit "peer busy" quittiert. Eine Wahlwiederholung direkt im Anschluss funktioniert dann jedoch meist.
Nein, die Gegenstelle ist nicht besetzt - das Problem taucht auch auf, wenn man sich selbst aufm Handy anruft, das definitiv nicht besetzt ist.

Das Problem ist, ich kann die CLI bei diesen Fehlern nicht betrachten, da der Server einige Kilometer von mir entfernt steht und dieses Problem wie gesagt nicht reproduzierbar ist.
Ich habe auch schon mISDN versucht - gleiches Problem.

Langsam verzweifle ich wirklich. Habe den Asterisk schon neu gebaut, die Configs alle mehrfach überprüft - es ist einfach keine Besserung in Sicht.
Kann das Problem auch am ISDN-Anschluss liegen? Der Anschluss ist ein Neuanschluss, daher kann ich auch nicht sagen ob zuvor ohne Asterisk die gleichen Probleme bestanden hätten. Neubau und wie gesagt der erste Telefonanschluss in dem Gebäude...

Hat jmd. sonst noch eine Idee?
 
Hi

theWireless schrieb:
Das Problem ist, ich kann die CLI bei diesen Fehlern nicht betrachten, da der Server einige Kilometer von mir entfernt steht und dieses Problem wie gesagt nicht reproduzierbar ist.
Zum Vergrößern anklicken....

Wie konfigurierst du denn den Asterisk? SSH - Remote?

Falls ja, verstehe ich nich wieso du nicht die CLI benutzen kannst? =)

Ansonsten hoert sich das schon mal sehr eigenartig an....
Bei SIP Gespraechen untereinander tritt das Problem nicht auf?

Gruß cheGGo
 
Sorry für die späte Antwort, bin erst heute ausm Urlaub zurück.

Wie du richtig vermutest, administriere ich per SSH. Das Problem an der Sache mit der CLI ist, dass ich eben nicht 24/7 vor meiner SSH-Session sitze und die Telefonate mitlese.
Daher ist die chance, dass ich genau im richtigen Moment einen Blick auf die CLI werfe, sehr sehr gering, da der Fehler eben nicht reproduzierbar ist und nur sporadisch, unregelmäßig auftritt.
Würde die CLI Uhrzeiten mitloggen wäre das bedeutend einfacher, dann könnte man da gezielt danach suchen....

Ob interne Gespräche Sip <=> Sip funktionieren weis ich nicht, werde ich beim Nächsten Ausfall testen lassen.
Es liegt jedenfalls definitiv nicht am ISDN-Anschluss. Für die 14 Tage, die ich nun in Urlaub war, habe ich meinen privaten Server dort hin gestellt und die Konfigurationsdateien 1:1 übernommen (also komplett /etc/asterisk/) und es lief ohne Probleme und Zwischenfälle.
Daher bliebe also eigentlich nur noch der Asterisk selbst oder die Server-HW als Fehlerquelle.
Ich werde nun wohl mal testhalber den Server ununterbrochen pingen und falls ein packetloss auftaucht Meldung machen lassen. Vielleicht liegt es ja tatsächlich daran, dass die NIC kurzzeitig aussetzt und das Sip-Phone so nich mit dem Server schnacken kann....
Wobei ich das als sehr weit hergeholt betrachte, da die Kiste ja was in die Logs schreiben würde, wenn die NIC kurzzeitig den Link verliert....

Alles seeehr merkwürdig.
 
Zuletzt bearbeitet:
Das der Asterisk üblicherweise ein Logfile in /var/log/asterisk schreibt hast du aber schon bemerkt? Ausserdem besteht noch die Möglichkeit über Syslog zu loggen. Sieh dir einfach mal die logger.conf an.
 
Kleiner Tipp:

du musst nicht die ganze Zeit die CLI im Auge haben. Es gibt auch ein full-Logfile in /var/log/asterisk/ ;)

tante edit sagt: ups, da war jemand schneller :D
 
ui, an die logger.conf hab ich garnich gedacht, gleich ma das full-logging einschalten... Ich bin aber auch plöd :D

Gut, dann werde ich da mal ne Zeit mitschreiben lassen und hoffen, dass der da was aussagekräftiges rein schreibt
 
sou, wieder neues von der Asterisk-Front.

Habe mich nun mal hin gesetzt und so lange auf die Wahlwiederholung gedrückt, bis ich ein "peer busy" gemeldet bekam. Hier der Log-Auszug:

Code: 
2007-10-10 15:56:59 DEBUG[956] chan_sip.c: Setting NAT on RTP to 524288
2007-10-10 15:56:59 DEBUG[956] chan_sip.c: Stopping retransmission on '[email protected]' of Response 1: Match Found
2007-10-10 15:56:59 DEBUG[956] chan_sip.c: Setting NAT on RTP to 524288
2007-10-10 15:56:59 DEBUG[956] chan_sip.c: Checking SIP call limits for device 104
2007-10-10 15:56:59 DEBUG[956] chan_sip.c: build_route: Contact hop: <sip:[email protected]:5060>
2007-10-10 15:56:59 VERBOSE[6627] logger.c:     -- Executing Set("SIP/104-081b9620", "CALLERID(number)=6732839") in new stack
2007-10-10 15:56:59 VERBOSE[6627] logger.c:     -- Executing Dial("SIP/104-081b9620", "CAPI/ISDN1/*****641198") in new stack
2007-10-10 15:56:59 VERBOSE[6627] logger.c:        > data = ISDN1/*****641198 format=8
2007-10-10 15:56:59 VERBOSE[6627] logger.c:        > capi request for interface 'ISDN1'
2007-10-10 15:56:59 DEBUG[943] channel.c: Avoiding initial deadlock for 'CAPI/ISDN1/*****641198-2d'
2007-10-10 15:56:59 VERBOSE[6627] logger.c:   == ISDN1#02: Call CAPI/ISDN1/*****641198-2d   (pres=0x00, ton=0x00)
2007-10-10 15:56:59 DEBUG[943] channel.c: Avoiding initial deadlock for 'CAPI/ISDN1/*****641198-2d'
2007-10-10 15:56:59 DEBUG[943] channel.c: Avoiding initial deadlock for 'CAPI/ISDN1/*****641198-2d'
2007-10-10 15:56:59 VERBOSE[6627] logger.c:     -- Called ISDN1/*****641198
2007-10-10 15:56:59 VERBOSE[947] logger.c:     -- ISDN1#02: received CONNECT_CONF PLCI = 0x101
2007-10-10 15:56:59 VERBOSE[947] logger.c:     -- CAPI queue frame:Control (4) SUBCLASS: Hangup (1) ] [ISDN1#02]
2007-10-10 15:56:59 VERBOSE[6627] logger.c:   == ISDN1#02: Interface cleanup PLCI=0x101
2007-10-10 15:56:59 VERBOSE[6627] logger.c:   == No one is available to answer at this time (1:0/0/0)
2007-10-10 15:56:59 DEBUG[6627] app_dial.c: Exiting with DIALSTATUS=NOANSWER.
2007-10-10 15:57:09 VERBOSE[6627] logger.c:     -- Timeout on SIP/104-081b9620
2007-10-10 15:57:09 VERBOSE[6627] logger.c:   == CDR updated on SIP/104-081b9620
2007-10-10 15:57:09 VERBOSE[6627] logger.c:     -- Executing Hangup("SIP/104-081b9620", "") in new stack
2007-10-10 15:57:09 VERBOSE[6627] logger.c:   == Spawn extension (104, t, 1) exited non-zero on 'SIP/104-081b9620'
2007-10-10 15:57:09 VERBOSE[6627] logger.c:     -- Executing Hangup("SIP/104-081b9620", "") in new stack
2007-10-10 15:57:09 VERBOSE[6627] logger.c:   == Spawn extension (104, h, 1) exited non-zero on 'SIP/104-081b9620'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '"Rolf Dietz" <6732839>'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '6732839'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is 't'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '104'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is 'SIP/104-081b9620'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is 'CAPI/ISDN1/*****641198-2d'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is 'Hangup'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '(null)'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '2007-10-10 15:56:59'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '(null)'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '2007-10-10 15:57:09'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '10'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '0'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is 'NO ANSWER'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is 'DOCUMENTATION'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '(null)'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '1192024619.89'
2007-10-10 15:57:09 DEBUG[6627] pbx.c: Function result is '(null)'
2007-10-10 15:57:09 DEBUG[6627] chan_sip.c: update_call_counter(104) - decrement call limit counter
2007-10-10 15:57:09 DEBUG[6627] chan_sip.c: AST hangup cause 16 (no match found in SIP)
2007-10-10 15:57:09 DEBUG[956] chan_sip.c: Stopping retransmission on '[email protected]' of Response 2: Match Found

Edit: nochmal vereinfacht direkt von der CLI:

Code: 
xeon*CLI>
    -- Executing Set("SIP/104-081b40e0", "CALLERID(number)=6732839") in new stack
    -- Executing Dial("SIP/104-081b40e0", "CAPI/ISDN1/*****641198") in new stack
       > data = ISDN1/*****641198 format=8
       > capi request for interface 'ISDN1'
  == ISDN1#02: Call CAPI/ISDN1/*****641198-2f   (pres=0x00, ton=0x00)
    -- Called ISDN1/*****641198
    -- ISDN1#02: received CONNECT_CONF PLCI = 0x101
xeon*CLI>
    -- CAPI queue frame: TYPE: Control (4) SUBCLASS: Hangup (1) ] [ISDN1#02]
  == ISDN1#02: Interface cleanup PLCI=0x101
  == No one is available to answer at this time (1:0/0/0)
    -- Timeout on SIP/104-081b40e0
  == CDR updated on SIP/104-081b40e0
    -- Executing Hangup("SIP/104-081b40e0", "") in new stack
  == Spawn extension (104, t, 1) exited non-zero on 'SIP/104-081b40e0'
    -- Executing Hangup("SIP/104-081b40e0", "") in new stack
  == Spawn extension (104, h, 1) exited non-zero on 'SIP/104-081b40e0'
xeon*CLI>

Kann damit irgend jmd. was anfangen? Sacht mir leider absolut garnix:noidea:

EditEdit: Ich weis ja nicht, wo der Error her kommt - aber seltsam finde ich den Output von capi, während der Fehler auftritt:

Code: 
xeon*CLI> capi show channels
CAPI B-channel information:
Line-Name       NTmode state i/o bproto isdnstate   ton  number
----------------------------------------------------------------
ISDN1#02         no    Disc   -  trans              0x00 ''->''
ISDN1#01         no    -----  -  trans              0x00 ''->'

da scheint ja alles "in butter" zu sein - es hängt nirgends n Anruf fest oder so... Aber warum zum Teufel setzt Asterisk den Anruf nicht ab *grrr* Alles sehr sehr seltsam

Edit^3: Was ich gerade noch getestet habe:
Während einem "Ausfall" kann man intern (über SIP) noch problemlos telefonieren. Aber man kann über ISDN auch NICHT angerufen werden!
Langsam bin ich wirklich ratlos, denn die ISDN-Karte wurde ja bereit schon getauscht...

Habe auch gerade chan_capi upgedated sowie testhalber den aktuellsten Asterisk (1.4x statt 1.2x) - keine Veränderung...
 
Zuletzt bearbeitet:
okay, vergesst alles was ich zuvor geschrieben habe.
Ich habe grade bei aufgetretenem Problem einen capi-trace mitgeschnitten.

Code: 
Oct 10 18:21:59 xeon kernel: kcapi: put [001] CONNECT_REQ                ID=002 #0x047c LEN=0061
Oct 10 18:21:59 xeon kernel:   Controller/PLCI/NCCI            = 0x1
Oct 10 18:21:59 xeon kernel:   CIPValue                        = 0x1
Oct 10 18:21:59 xeon kernel:   CalledPartyNumber               = <80>*****641198
Oct 10 18:21:59 xeon kernel:   CallingPartyNumber              = <00 80>6732839
Oct 10 18:21:59 xeon kernel:   CalledPartySubaddress           = default
Oct 10 18:21:59 xeon kernel:   CallingPartySubaddress          = default
Oct 10 18:21:59 xeon kernel:   BProtocol
Oct 10 18:21:59 xeon kernel:    B1protocol                     = 0x1
Oct 10 18:21:59 xeon kernel:    B2protocol                     = 0x1
Oct 10 18:21:59 xeon kernel:    B3protocol                     = 0x0
Oct 10 18:21:59 xeon kernel:    B1configuration                = default
Oct 10 18:21:59 xeon kernel:    B2configuration                = default
Oct 10 18:21:59 xeon kernel:    B3configuration                = default
Oct 10 18:21:59 xeon kernel:   BC                              = default
Oct 10 18:21:59 xeon kernel:   LLC                             = default
Oct 10 18:21:59 xeon kernel:   HLC                             = default
Oct 10 18:21:59 xeon kernel:   AdditionalInfo                  = default
Oct 10 18:21:59 xeon kernel:
Oct 10 18:21:59 xeon kernel: kcapi: got [001] CONNECT_CONF               ID=002 #0x047c LEN=0014
Oct 10 18:21:59 xeon kernel:   Controller/PLCI/NCCI            = 0x101
Oct 10 18:21:59 xeon kernel:   Info                            = 0x0
Oct 10 18:21:59 xeon kernel:
Oct 10 18:21:59 xeon kernel: kcapi: got [001] DISCONNECT_IND             ID=002 #0x7b36 LEN=0014
Oct 10 18:21:59 xeon kernel:   Controller/PLCI/NCCI            = 0x101
Oct 10 18:21:59 xeon kernel:   Reason                          = 0x3302
Oct 10 18:21:59 xeon kernel:
Oct 10 18:21:59 xeon kernel: kcapi: put [001] DISCONNECT_RESP            ID=002 #0x7b36 LEN=0012
Oct 10 18:21:59 xeon kernel:   Controller/PLCI/NCCI            = 0x101
Oct 10 18:21:59 xeon kernel:
Reason = 0x3302 ist, laut google, ein layer2-error. Nur, was sagt mir das? Die Karte hängt direkt am NTBA, zusammen mit einem ISDN-Fax (Fax und ISDN-Karte natürlich an getrennten ports).
 
theWireless schrieb:
Reason = 0x3302 ist, laut google, ein layer2-error. Nur, was sagt mir das? Die Karte hängt direkt am NTBA, zusammen mit einem ISDN-Fax (Fax und ISDN-Karte natürlich an getrennten ports).
Zum Vergrößern anklicken....

Layer 2 ist meist ein Problem mit dem verwendeten ISDN Protokoll, also PtP oder PtMP.
Layer 1 waere die physikalische Verbindung.

Armin
 
danke, habe zwischenzeitlich hier im Forum gelesen, dass es Probleme in Verbindung mit SMP gibt (Mehrkern-Prozessoren /HT). Nachdem ich SMP aus dem Kernel rauskompiliert hatte, bekam ich dann einen layer3-error.

Ich werde nun mal einen 2. Rechner frisch aufsetzen und Asterisk darauf installieren, habe allmählich die Faxen dicke...
 
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Zurzeit aktive Besucher

Gesamt: 635 (Mitglieder: 31, Gäste: 604)

Statistik des Forums

Themen
248,534
Beiträge
2,293,725
Mitglieder
378,041
Neuestes Mitglied
Quqa

3CX jetzt einen Monat kostenlos testen

Die Verbindung, Zusammenarbeit und Kommunikation mit Ihrem Team und Ihren Kunden war noch nie so einfach. Nutzen Sie unsere kostenlose 30-Tage-Testversion und entdecken Sie die richtige Lösung für Ihr Unternehmen.

3CX start your free trial guy
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.
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten