Busy() bleibt hängen

[hehol]

Hallo,

ich habe vor kurzem einen unserer Asterisk-Server von 1.2.9.1 mit bristuff 0.3.0-pre-1q auf 1.2.17 mit bristuff 0.3.0-pre-1y-b aktualisiert. Im System sind zwei quadBri-Karten (4xTE PTP, 4xNT PTP) installiert.

Nun fällt mir auf, daß der Server - mal nach ein paar Minuten Laufzeit, mal nach 12-24 Stunden - kein "Besetzt" mehr am ISDN-Amt signalisiert. Normalerweise sieht das inkl. "pri intense debug" so aus:

    -- Executing Busy("Zap/10-1", "") in new stack
  == Spawn extension (macro-vm, s-BUSY, 2) exited non-zero on 'Zap/10-1' in macro 'vm'
  == Spawn extension (macro-vm, s-BUSY, 2) exited non-zero on 'Zap/10-1' in macro 'exten-vm'
  == Spawn extension (macro-vm, s-BUSY, 2) exited non-zero on 'Zap/10-1'
4 terisk2*CLI> 
> [ 00 01 02 02 08 01 ed 5a 08 02 80 91 ]
4 
> Informational frame:
4 > SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
4 > N(S): 001   0: 0
> N(R): 001   P: 0
> 8 bytes of data
4 -- Restarting T203 counter
4 Stopping T_203 timer
4 Starting T_200 timer
4 > Protocol Discriminator: Q.931 (8)  len=8
4 > Call Ref: len= 1 (reference 237/0xED) (Terminator)
4 > Message type: RELEASE COMPLETE (90)
4 > [08 02 80 91]
4 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
4 >                  Ext: 1  Cause: User busy (17), class = Normal Event (1) ]
    -- Hungup 'Zap/10-1'

Wenn es nicht mehr funktioniert, dann passiert das:

    -- Executing Busy("Zap/7-1", "") in new stack
3 terisk2*CLI> 
> [ 00 01 ee b2 08 01 b5 03 1e 02 81 88 ]
3 terisk2*CLI> 
> Informational frame:
3 > SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
3 > N(S): 119   0: 0
> N(R): 089   P: 0
> 8 bytes of data
3 -- Restarting T203 counter
3 Stopping T_203 timer
3 Starting T_200 timer
3 > Protocol Discriminator: Q.931 (8)  len=8
3 > Call Ref: len= 1 (reference 181/0xB5) (Terminator)
3 > Message type: PROGRESS (3)
3 > [1e 02 81 88]
3 > Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
3 >                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]

Man sieht, daß Busy offenbar nicht fertig wird. Mich wundert außerdem, das im ersten Fall RELEASE COMPLETE gesendet wird und im zweiten PROGRESS.

Wenn man Asterisk neu startet, dann ist das Problem verschwunden.

Das Problem tritt nur auf dem einen betroffenen Asterisk-Server auf. Andere Systeme mit gleicher Asterisk/Zaptel/Bristuff-Version haben keine Probleme. Die einzige Besonderheit ist, daß wir am problematischen Server CLIP no screening auf den ISDN-Anschlüssen gebucht haben, weshalb es in der zapata.conf so aussieht:

[channels]
language=en
context=from-pstn
pridialplan=dynamic
prilocaldialplan=dynamic
nationalprefix=0
internationalprefix=00
overlapdial=yes
echocancel=yes
immediate=no
switchtype=euroisdn
signalling=bri_cpe
priindication=outofband

group=1
channel => 1-2,4-5,7-8,10-11

Auf den anderen Systemen benutze ich pridialplan=unknown. Leider kann ich die Einstellung nicht ändern, weil dann längere Zeit alle Benutzer mit der falschen CallerID raustelefonieren würden.

Hat irgendwer dieses Problem schonmal beobachtet und eventuell sogar eine Lösung?

Gruß
Henning

 

[clan]

Die Progress Indication teilt der Anlage mit, daß vom Provider eine Ansage eingespielt wird. Sind alle Server am gleichen Provider angeschlossen? Die pridialplan/prilocaldialplan haben damit eher nichts zu tun.

Intense debug ist übrigens hier nur bedingt hilfreich, gegenüber dem 'normalen' debug kommen noch die Schicht-2-Meldungen, die die Sache eher unübersichtlich machen.

 

[hehol]

Die Progress Indication teilt der Anlage mit, daß vom Provider eine Ansage eingespielt wird. Sind alle Server am gleichen Provider angeschlossen?

Ja, alle Server sind bei der Telekom angeschlossen.

Die pridialplan/prilocaldialplan haben damit eher nichts zu tun.

Das war halt meine erste Vermutung, weil das der einzige offensichtliche Unterschied zwischen meinen Servern ist.

Ich habe in der Zwischenzeit mal einen Testserver an einem Mehrgeräteanschluß angeschlossen und dort tritt der gleiche Effekt auf. Es scheint sich also um ein generelles Problem handeln. Ich downgrade jetzt mal Zaptel und die libpri und schaue, ob das Problem dadurch verschwindet ...

Henning

 

[hehol]

N'Abend,

ich habe das Busy() Problem inzwischen auch auf einem Primärmultiplexanschluß beobachtet. Irgendwann dämmerte mir, daß ich in einer Präsentation von Herrn Junghanns mal gelesen hatte, daß Busy "schlecht" ist. Also habe ich alle Busy()-Aufrufe durch

Hangup(17)

ersetzt. Auf den ersten Blick wird es dadurch viel besser als vorher. Mal schauen, ob das auch im Dauerbetrieb so bleibt.

Henning

 

[xc0n42]

Danke für die Infos. Mein Problem wurde damit gelöst.

Falls jemand ähnliche Probleme hat, hier mein gelöstes Problem:

3xISDN Telekom Anlagenanschluss mit CLIP no screening ===> OctoBRI ===> 3 Ports im NT Modus an Siemens HiPath 3350

Das Problem war folgendes:
HiPath Teilnehmer ruft externe Nummer und erhält Busy. Zweiter Teilnehmer ruft ebenfalls externe Nummer und erhält auch ein Busy von der Gegenseite.
Die HiPath ist so konfiguriert, dass sie die Amtskanäle immer in der gleichen Reihenfolge holt. Für die OctoBRI/Asterisk sind die beiden ersten Kanäle zur HiPath scheinbar noch belegt. Die HiPath zeigt diese aber als frei an.

Versucht ein Teilnehmer dann ein Amt zu bekommen, versucht's die Siemens auf den beiden auf der OctoBRI belegten Kanäle und der HiPath Teilnehmer sieht "Zur Zeit belegt" und bekommt kein Amt.

Das Problem ist gelöst indem in jede Regel in der extensions.conf der Befehl Hangup(17) aufgerufen wird. Damit werden die DAHDI Kanäle ordentlich freigegeben.