Probleme mit eingehenden Anrufen - manchmal...

[nexus]

Hallo zusammen,

wie's aussieht funktioniert leider doch noch nicht alles ganz reibungslos *seufz*.

Bei mir hängt eine Conrad HFC im TE-Modus an einem Hansenet (Alice) PtMP-Anschluss (mit stinknormalem Kabel direkt an der NTBA). In den meisten Fällen funktioniert rein- und raustelefonieren auch ganz prima, nur hin und wieder habe ich offensichtlich ein Problem mit eingehenden Gesprächen. Es klingelt an meinen Apparaten dann ganz kurz, anschließend ist das Gespräch weg. Der anrufende Teilnehmer bekommt kein Freizeichen und irgendwann ein "Teilnehmer nicht erreichbar".

Ein verbose auf der Konsole brachte folgendes zu Tage:

    -- Executing Dial("Zap/4-1", "ZAP/g1/12345678/&SIP/111&SIP/222|60") in new stack
    -- Accepting voice call from '1798765432' to '12345678' on channel 0/1, span 2
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called g1/12345678/
    -- Called 111
    -- Called 222
    -- SIP/111-6388 is ringing
    -- SIP/222-5bab is ringing
  == Primary D-Channel on span 2 down
    -- Hungup 'Zap/1-1'
  == Spawn extension (tcom-trunk, 12345678, 1) exited non-zero on 'Zap/4-1'
    -- Hungup 'Zap/4-1'
  == Primary D-Channel on span 2 up
Jul  5 23:42:18 WARNING[2372]: chan_zap.c:7504 zt_pri_error: PRI: ACK received for '1' outside of window of '0' to '0', restarting

Speziell die letzte Zeile der Ausgabe stimmt mich etwas missmutig. Das Beste aber: Wenn ich es 10 Sekunden später nochmal probiere, kommt der Anruf einwandfrei durch. Die Sache ist auch nicht so richtig reproduzierbar - manchmal klappt's, manchmal nicht.

Hier noch ein paar Configs:

zaptel.conf

loadzone=nl
defaultzone=nl
span=1,1,3,ccs,ami
bchan=1-2
dchan=3
span=2,1,3,ccs,ami
bchan=4-5
dchan=6

zapata.conf

[channels]
;----------------------------------------------------------------------------
;NT-Karte fuer ISDN-Telefonanlage im Mehrgeraete-Anschluss
;----------------------------------------------------------------------------
switchtype = euroisdn
signalling = bri_net_ptmp
pridialplan = local
prilocaldialplan = local
echocancel = yes
overlapdial = yes
echocancelwhenbridged=no
echotraining=no
immediate = no
usecallerid = yes
group = 1
context = pbx-trunk
channel => 1-2
usecallingpres=yes
nationalprefix = 0
internationalprefix = 00

;-----------------------------------------------------------------------------
;TE-Karte fuer Anschluss an NTBA/ISDN-Telefonnetz
;-----------------------------------------------------------------------------
switchtype = euroisdn
signalling = bri_cpe_ptmp
pridialplan = local
prilocaldialplan = local
echocancel = yes
echocancelwhenbridged=no
echotraining=no
usecallerid = yes
overlapdial = no
immediate = no
group = 2
context = tcom-trunk
channel => 4-5

... und der kurze relevante Teil aus extensions.conf:

[tcom-trunk]
exten => _X.,1,Dial(ZAP/g1/${EXTEN}/&SIP/111&SIP/222,60)
exten => _X.,2,Hangup

Edit - noch eine Zusatzinformation:
Ich habe neben dem Asterisk auch mal ein ISDN-Telefon direkt an die NTBA gehängt. Wenn das Problem auftritt, klingelt das ISDN-Telefon normal weiter, der Anrufer bekommt ein Freizeichen. Nur der Asterisk und alle dahinter hängenden Geräte haben das Gespräch verloren.

Hat zufällig jemand eine Idee? Schon jetzt vielen Dank für Eure Hilfe!

 

[jhansen]

Hallo,

habe das gleiche Problem mit zt_pri_error: PRI: ACK received for '1' outside of window of '0' to '0', restarting

an einem Alice Anschluss.

Hast Du es gelöst bekommen?

Gruss
Jens

 

[kombjuder]

Hallo,

habe das gleiche Problem mit zt_pri_error: PRI: ACK received for '1' outside of window of '0' to '0', restarting

Ich würde als erstes die Software aktualisieren - sofern möglich- und den Florzpatch probieren (wegen der 2 Hfc).
Könnten uU IRQ- oder Synchronisationsprobleme der beiden Hfc sein.

 

[nexus]

Ja, ich habe das Problem tatsächlich gelöst bekommen - das heißt eigentlich nicht, aber zumindest gibt es einen Workaround, der das Problem verschwinden lässt.

Die Problemursache bestand in meinem Fall darin, dass nach einer längeren Nicht-Nutzung der Leitung die sog. Schicht 3 abgebaut wird - das ist standardmäßig bei allen ISDN-Anbietern so. Bei Alice scheint es jedoch der Fall zu sein, dass das Wiederaufbauen der Schicht etwas länger dauert, als es die Asterisk-Treiber verkraften können.

Nachdem ich auf Asterisk-Seite trotz längerer Suche keine Lösung finden konnte, habe ich den Alice-Kundenservice angerufen und darum gebeten, ein sog. Dauersignal auf meinen ISDN-Anschluss zu legen - das hat zur Folge, dass kein Abbau der Schicht 3 mehr stattfindet. Seitdem sind die Probleme spurlos verschwunden. Um auch noch ein Lob auszusprechen: Der Kundenservice hatte das ohne viele Nachfragen und innerhalb einer halben Stunde nach meinem Anruf erledigt...