Primary D-Channel up/down/up/down...

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
N

nexus

Neuer User
Mitglied seit
6 Jun 2005
Beiträge
30
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

inzwischen habe ich meine etwas komplexe Konfiguration erfolgreich am Laufen <freu>.

Im Verbose-Mode müllt mir Asterisk die Konsole allerdings noch mit folgenden Meldungen zu:

Code: 
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up
  == Primary D-Channel on span 2 down
  == Primary D-Channel on span 2 up

Span 2 hängt über eine HFC direkt am Hansenet PtMP-Anschluss. Diese Meldungen kommen mal häufig in sehr kurzen Abständen, dann mal wieder eine Weile nicht. Einschränkungen in der Funktionalität habe ich keine (wenn's stehen bleibt, dann immer im Status "up"), ich wundere mich nur über die Log-Einträge. Gehört das so?
 
Ich hab sowas auch schon gesehen (in der Schweiz), scheit normal zu sein. Beeinträchtigungen gibts da auch nicht.
 
Bei meinem Setup tauchten diese Meldungen nur im Fehlerfall auf.

Die am PSTN angeschlossenen Ports meiner beroNet Karte waren im falschen Modus konfiguriert (NT statt TE).
Nach beheben des Fehlers verschwanden auch die Meldungen.

Einschränkungen waren aber in beiden Fällen nicht zu erkennen.
 
Hm, leider muss ich mich korrigieren:

Das ständige up und down des D-Kanals hat wohl doch Einschränkungen in der Funktionalität zur Folge. Das Problem in diesem Thread

http://www.ip-phone-forum.de/forum/viewtopic.php?t=20944&highlight=

tritt reproduzierbar immer dann auf, wenn genau im Moment des eingehenden Anrufs der D-Kanal auf "down" umspringt. Ich habe schon mal versucht, jede Komponente zwischen Asterisk und Telefondose auszutauschen (Kabel, NTBA, Splitter), um Wackelkontakte auszuschließen - leider hat das keinen Erfolg gebracht.

Ich bin mir auch sicher, dass die Karten richtig auf TE- und NT-Modus konfiguriert sind - wie gesagt, in der Mehrzahl der Fälle funktioniert ja auch alles einwandfrei.

Hat vielleicht jemand noch eine zündende Idee? Besten Dank vorab!

Edit:
Hier noch die Ausgabe des "bri intense debug" während eines down/up-Zyklus:
Code: 
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 89 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 068        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 00 89 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 068        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 89 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 068        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 02 89 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 068        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter

< [ 00 89 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 068        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Unsolicited RR with P/F bit, responding
Sending Receiver Ready (0)

> [ 02 89 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 068        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter
-- Restarting T203 counter

< [ 02 89 53 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 068        EA: 1
<   M3: 2   P/F: 1 M2: 0 11: 3  [ DISC (disconnect) ]
< 0 bytes of data
-- Got Disconnect from peer.
Sending Unnumbered Acknowledgement

> [ 02 89 73 ]

> Unnumbered frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 068        EA: 1
>   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
> 0 bytes of data
-- Restarting T203 counter
Sending Set Asynchronous Balanced Mode Extended

> [ 00 89 7f ]

> Unnumbered frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 068        EA: 1
>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
  == Primary D-Channel on span 2 down
fish*CLI>
< [ 00 89 73 ]

< Unnumbered frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 068        EA: 1
<   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
< 0 bytes of data
-- Got UA from network peer  Link up.
-- Restarting T203 counter
  == Primary D-Channel on span 2 up
 
Ist normal am Mehrgeräteanschluss

Die ISDN-Schicht2 RR (Receive Ready) Meldungen laufen regelmässig zur Schicht 2 Überwachung ob das Endgerät noch aktiv ist. Amt schickt RR und Endgerät antwortet mit RR

beim Mehrgeräteanschluss wird nach einiger bestimmten Zeit von der Vermittlungsstelle die Schicht 3 abgebaut, AMT schickt DISC und Endgerät antwortet mit UA

Damit ist die Schicht 3 abgebaut, wenn jetzt eine Seite wieder aktiv werden will schickt sie ein SABME und die Gegenstelle antwortet mit UA.
dann ist die Schicht 3 wieder aktiv, der dann folgende SETUP ist dann der abgehende Anruf oder der kommende Anruf.
ZapHFC scheint nicht mitzukriegen das Schicht 3 weg ist oder kriegt nicht schnell genug mit das sie wieder da ist und wird von dem SETUP überrascht. wenn man dann sofort nochmal anruft gehts wahrscheinlich, weil Schicht 3 ist ja jetz aufgebaut.....bis das Amt sie wieder abbaut...

also das ist keine Lösung....nur ne Erklärung ;-)
 
Vielen Dank für diese Erklärung - das klingt auf jeden Fall sehr schlüssig und passt genau zu meinem Problem.

Ist es denn normal, dass das DISC vom Amt derart häufig kommt (bei mir gern 10x direkt hintereinander - in "schlechten" Zeiträumen habe ich ich bis zu 20 solcher up/down-Zyklen pro Minute) ?

Weiß zufällig noch jemand, auf wessen Problemliste man dieses Thema setzen kann? Gehört das zu kpj oder direkt zu Digium? ;)
 
nexus schrieb:
Weiß zufällig noch jemand, auf wessen Problemliste man dieses Thema setzen kann? Gehört das zu kpj oder direkt zu Digium? ;)
Zum Vergrößern anklicken....

Auf jeden Fall erst mal an kpj schicken.
 
Okay, werde ich dann machen - davor aber noch eine freudige Nachricht: Ich habe den Asterisk bei einem der fehlgeschlagenen Anrufe mit aktivem "intense debug" ertappen können ;)

Hier die Ausgabe:
Code: 
< [ 02 89 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 068        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Unsolicited RR with P/F bit, responding
Sending Receiver Ready (0)

> [ 02 89 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 068        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter
-- Restarting T203 counter
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 89 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 068        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 00 89 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 068        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter

< [ 02 ff 03 08 01 34 05 04 03 80 90 a3 18 01 89 6c 0c 21 83 31 37 39 36 36 35 38 35 32 37 70 09 c1 39 37 33 39 36 36 30 33 a1 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 127        EA: 1
<   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
< 38 bytes of data
< Protocol Discriminator: Q.931 (8)  len=38
< Call Ref: len= 1 (reference 52/0x34) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                              Ext: 1  User information layer 1: A-Law (35)
< [18 01 89]
< Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
<                        ChanSel: B1 channel
                         ]
< [6c 0c 21 83 31 37 39 36 36 35 38 35 32 37]
< Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation allowed of network provided number (3) '1799876543' ]
< [70 09 c1 39 37 33 39 36 36 30 33]
< Called Number (len=11) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '12345678' ]
< [a1]
< Sending Complete (len= 1)
-- Restarting T203 counter

> [ 00 89 00 00 08 01 b4 02 18 01 89 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 068        EA: 1
> N(S): 000   0: 0
> N(R): 000   P: 0
> 7 bytes of data
-- Restarting T203 counter
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=7
> Call Ref: len= 1 (reference 180/0xB4) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 01 89]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
>                        ChanSel: B1 channel
                         ]
    -- Executing SetLanguage("Zap/4-1", "de") in new stack
    -- Accepting voice call from '1799876543' to '12345678' on channel 0/1, span 2
    -- Executing AGI("Zap/4-1", "reverse.agi| 01799876543") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/reverse.agi
fish*CLI>
< [ 02 89 53 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 068        EA: 1
<   M3: 2   P/F: 1 M2: 0 11: 3  [ DISC (disconnect) ]
< 0 bytes of data
-- Got Disconnect from peer.
Sending Unnumbered Acknowledgement

> [ 02 89 73 ]

> Unnumbered frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 068        EA: 1
>   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
> 0 bytes of data
Sending Set Asynchronous Balanced Mode Extended

> [ 00 89 7f ]

> Unnumbered frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 068        EA: 1
>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
  == Primary D-Channel on span 2 down
fish*CLI>
> [ 00 89 00 00 08 01 b4 45 08 02 81 90 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 068        EA: 1
> N(S): 000   0: 0
> N(R): 000   P: 0
> 8 bytes of data
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=8
> Call Ref: len= 1 (reference 180/0xB4) (Terminator)
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
  == Spawn extension (tcom-trunk, 12345678, 2) exited non-zero on 'Zap/4-1'
    -- Hungup 'Zap/4-1'
fish*CLI>
< [ 00 89 73 ]

< Unnumbered frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 068        EA: 1
<   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
< 0 bytes of data
-- Got UA from network peer  Link up.
-- Restarting T203 counter
  == Primary D-Channel on span 2 up
Jul  7 08:38:16 WARNING[3931]: chan_zap.c:7534 zt_pri_error: PRI: ACK received for '1' outside of window of '0' to '0', restarting

< [ 02 89 00 02 08 01 34 7d 08 02 82 e2 14 01 06 ]

< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 068        EA: 1
< N(S): 000   0: 0
< N(R): 001   P: 0
< 11 bytes of data
Sending Set Asynchronous Balanced Mode Extended

> [ 00 89 7f ]

> Unnumbered frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 068        EA: 1
>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
  == Primary D-Channel on span 2 down
fish*CLI>
< [ 00 89 73 ]

< Unnumbered frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 068        EA: 1
<   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
< 0 bytes of data
-- Got UA from network peer  Link up.
-- Restarting T203 counter
  == Primary D-Channel on span 2 up

Deckt sich dieser Output ebenfalls mit der Schilderung von cbrandtner? Nach meinem laienhaften Verständnis des Protokolls kommt direkt nach dem SETUP ein DISC vom Amt...

Ich habe diesen Test übrigens extra als ersten Anrufversuch nach der Nacht durchgeführt - wenn es auf der Leitung länger still ist, kommen die beschriebenen up/down-Zyklen nur noch sehr selten vor, so auch diesmal - vor dem Anrufversuch gab es keine verdächtigen Aktivitäten. Außerdem kann ich nach langen Pausen mit relativ hoher Sicherheit davon ausgehen, dass der Versuch fehlschlagen wird.
 
Hatte leider nicht viel Zeit zum analysieren, aber was mir auffällt ist das nach dem Setup mit der Callref 52 ein Call Proceeding mit Call Ref 180 kommt, da sollte eigentlich ein Setup Ack mit der Call Ref 52 kommen.
Es scheint fast so als wäre vom letzen Call noch irgendwas hängengeblieben bzw. der nicht richtig beendet worden sein. Ein kompl. Protokoll mit einem erfolgreichen Call bis zum nicht erfolgr. wäre hilfreich
 
Ich habe jetzt mal ein wenig herumexperimentiert - in der gewünschten Reihenfolge kann ich den Fehler leider nicht reproduzieren, weil nach einem erfolgreichen Anrufversuch für längere Zeit auch alle nachfolgenden Anrufversuche grundsätzlich erfolgreich sind.

Hier jedoch ein Ausschnitt in umgekehrter Reihenfolge (erfolgreich nach erfolglos), ich hoffe, das hilft auch weiter:

Code: 
fish*CLI> bri intense debug span 2
Enabled EXTENSIVE debugging on span 2
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 8d 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 02 8d 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 070        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter

< [ 00 8d 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Unsolicited RR with P/F bit, responding
Sending Receiver Ready (0)

> [ 02 8d 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 070        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter
-- Restarting T203 counter
    -- parse_srv: SRV mapped to host sipgate.co.uk, port 5060
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 8d 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 02 8d 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 070        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter

< [ 00 8d 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Unsolicited RR with P/F bit, responding
Sending Receiver Ready (0)

> [ 02 8d 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 070        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter
-- Restarting T203 counter

< [ 02 ff 03 08 01 15 05 04 03 80 90 a3 18 01 89 6c 0c 21 83 31 37 39 36 36 35 38 35 32 37 70 09 c1 39 37 33 39 36 36 30 33 a1 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 127        EA: 1
<   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
< 38 bytes of data
< Protocol Discriminator: Q.931 (8)  len=38
< Call Ref: len= 1 (reference 21/0x15) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                              Ext: 1  User information layer 1: A-Law (35)
< [18 01 89]
< Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
<                        ChanSel: B1 channel
                         ]
< [6c 0c 21 83 31 37 39 36 36 35 38 35 32 37]
< Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation allowed of network provided number (3) '1799876543' ]
< [70 09 c1 39 37 33 39 36 36 30 33]
< Called Number (len=11) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '12345678' ]
< [a1]
< Sending Complete (len= 1)
-- Restarting T203 counter

> [ 00 8d 00 00 08 01 95 02 18 01 89 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> N(S): 000   0: 0
> N(R): 000   P: 0
> 7 bytes of data
-- Restarting T203 counter
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=7
> Call Ref: len= 1 (reference 149/0x95) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 01 89]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
>                        ChanSel: B1 channel
                         ]
    -- Executing SetLanguage("Zap/4-1", "de") in new stack
    -- Accepting voice call from '1799876543' to '12345678' on channel 0/1, span 2
    -- Executing AGI("Zap/4-1", "reverse.agi| 01799876543") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/reverse.agi
    -- AGI Script reverse.agi completed, returning 0
    -- Executing SetCIDName("Zap/4-1", "Bastian Mobile") in new stack
    -- Executing SetCIDNum("Zap/4-1", "01799876543") in new stack
    -- Executing Dial("Zap/4-1", "ZAP/g1/12345678/&SIP/111&SIP/222|60") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called g1/12345678/
Jul 11 18:32:57 NOTICE[24741]: app_dial.c:777 dial_exec: Unable to create channel of type 'SIP'
    -- Called 222
fish*CLI>
< [ 02 8d 53 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 070        EA: 1
<   M3: 2   P/F: 1 M2: 0 11: 3  [ DISC (disconnect) ]
< 0 bytes of data
-- Got Disconnect from peer.
Sending Unnumbered Acknowledgement

> [ 02 8d 73 ]

> Unnumbered frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 070        EA: 1
>   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
> 0 bytes of data
Sending Set Asynchronous Balanced Mode Extended

> [ 00 8d 7f ]

> Unnumbered frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
  == Primary D-Channel on span 2 down
fish*CLI>
> [ 00 8d 00 00 08 01 95 45 08 02 81 90 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> N(S): 000   0: 0
> N(R): 000   P: 0
> 8 bytes of data
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=8
> Call Ref: len= 1 (reference 149/0x95) (Terminator)
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
    -- Hungup 'Zap/1-1'
  == Spawn extension (tcom-trunk, 12345678, 5) exited non-zero on 'Zap/4-1'
    -- Hungup 'Zap/4-1'
fish*CLI>
< [ 00 8d 73 ]

< Unnumbered frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
<   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
< 0 bytes of data
-- Got UA from network peer  Link up.
-- Restarting T203 counter
  == Primary D-Channel on span 2 up
Jul 11 18:32:57 WARNING[8728]: chan_zap.c:7534 zt_pri_error: PRI: ACK received for '1' outside of window of '0' to '0', restarting

< [ 02 8d 00 02 08 01 15 7d 08 02 82 e2 14 01 06 ]

< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 070        EA: 1
< N(S): 000   0: 0
< N(R): 001   P: 0
< 11 bytes of data
Sending Set Asynchronous Balanced Mode Extended

> [ 00 8d 7f ]

> Unnumbered frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
  == Primary D-Channel on span 2 down
fish*CLI>
< [ 00 8d 73 ]

< Unnumbered frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
<   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
< 0 bytes of data
-- Got UA from network peer  Link up.
-- Restarting T203 counter
  == Primary D-Channel on span 2 up


************ hier beginnt der 2. Anrufversuch (erfolgreich) **************


T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 8d 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 00 8d 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter

< [ 02 8d 53 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 070        EA: 1
<   M3: 2   P/F: 1 M2: 0 11: 3  [ DISC (disconnect) ]
< 0 bytes of data
-- Got Disconnect from peer.
Sending Unnumbered Acknowledgement

> [ 02 8d 73 ]

> Unnumbered frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 070        EA: 1
>   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
> 0 bytes of data
-- Restarting T203 counter
Sending Set Asynchronous Balanced Mode Extended

> [ 00 8d 7f ]

> Unnumbered frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
  == Primary D-Channel on span 2 down
fish*CLI>
< [ 00 8d 73 ]

< Unnumbered frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
<   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
< 0 bytes of data
-- Got UA from network peer  Link up.
-- Restarting T203 counter
  == Primary D-Channel on span 2 up
fish*CLI>
< [ 02 ff 03 08 01 19 05 04 03 80 90 a3 18 01 89 6c 0c 21 83 31 37 39 36 36 35 38 35 32 37 70 09 c1 39 37 33 39 36 36 30 33 a1 ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 127        EA: 1
<   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
< 38 bytes of data
< Protocol Discriminator: Q.931 (8)  len=38
< Call Ref: len= 1 (reference 25/0x19) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                              Ext: 1  User information layer 1: A-Law (35)
< [18 01 89]
< Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
<                        ChanSel: B1 channel
                         ]
< [6c 0c 21 83 31 37 39 36 36 35 38 35 32 37]
< Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation allowed of network provided number (3) '1799876543' ]
< [70 09 c1 39 37 33 39 36 36 30 33]
< Called Number (len=11) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '12345678' ]
< [a1]
< Sending Complete (len= 1)
-- Restarting T203 counter

> [ 00 8d 00 00 08 01 99 02 18 01 89 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> N(S): 000   0: 0
> N(R): 000   P: 0
> 7 bytes of data
-- Restarting T203 counter
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=7
> Call Ref: len= 1 (reference 153/0x99) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 01 89]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
>                        ChanSel: B1 channel
                         ]
    -- Executing SetLanguage("Zap/4-1", "de") in new stack
    -- Accepting voice call from '1799876543' to '12345678' on channel 0/1, span 2
    -- Executing AGI("Zap/4-1", "reverse.agi| 01799876543") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/reverse.agi
    -- AGI Script reverse.agi completed, returning 0
    -- Executing SetCIDName("Zap/4-1", "Bastian Mobile") in new stack
    -- Executing SetCIDNum("Zap/4-1", "01799876543") in new stack
    -- Executing Dial("Zap/4-1", "ZAP/g1/12345678/&SIP/111&SIP/222|60") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called g1/12345678/
Jul 11 18:33:13 NOTICE[24751]: app_dial.c:777 dial_exec: Unable to create channel of type 'SIP'
    -- Called 222
    -- SIP/222-fb05 is ringing
fish*CLI>
> [ 00 8d 02 00 08 01 99 01 1e 02 81 88 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> N(S): 001   0: 0
> N(R): 000   P: 0
> 8 bytes of data
T_200 timer already going (2)
> Protocol Discriminator: Q.931 (8)  len=8
> Call Ref: len= 1 (reference 153/0x99) (Terminator)
> Message type: ALERTING (1)
> [1e 02 81 88]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
    -- Zap/1-1 is making progress passing it to Zap/4-1
fish*CLI>
> [ 00 8d 04 00 08 01 99 03 1e 02 81 88 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> N(S): 002   0: 0
> N(R): 000   P: 0
> 8 bytes of data
T_200 timer already going (2)
> Protocol Discriminator: Q.931 (8)  len=8
> Call Ref: len= 1 (reference 153/0x99) (Terminator)
> Message type: PROGRESS (3)
> [1e 02 81 88]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]

< [ 00 8d 01 06 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 003 P/F: 0
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 3
-- ACKing packet 0, new txqueue is 1 (-1 means empty)
-- ACKing packet 1, new txqueue is 2 (-1 means empty)
-- ACKing packet 2, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Nothing left, starting T203 counter
-- Restarting T203 counter
    -- Zap/1-1 is ringing
fish*CLI>

**** hier lege ich wieder auf ****

fish*CLI>
fish*CLI>
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 8d 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 00 8d 01 07 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 003 P/F: 1
< 0 bytes of data
-- ACKing all packets from 2 to (but not including) 3
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter

< [ 02 8d 00 06 08 01 19 4d 08 02 80 90 ]

< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 070        EA: 1
< N(S): 000   0: 0
< N(R): 003   P: 0
< 8 bytes of data
-- ACKing all packets from 2 to (but not including) 3
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
< Protocol Discriminator: Q.931 (8)  len=8
< Call Ref: len= 1 (reference 25/0x19) (Originator)
< Message type: RELEASE (77)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
<                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
Sending Receiver Ready (1)

> [ 02 8d 01 02 ]

> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 070        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 001 P/F: 0
> 0 bytes of data
-- Restarting T203 counter
-- Restarting T203 counter
    -- Channel 0/1, span 2 got hangup
    -- Hungup 'Zap/1-1'
  == Spawn extension (tcom-trunk, 12345678, 5) exited non-zero on 'Zap/4-1'

> [ 00 8d 06 02 08 01 99 5a 08 02 81 90 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 070        EA: 1
> N(S): 003   0: 0
> N(R): 001   P: 0
> 8 bytes of data
-- Restarting T203 counter
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=8
> Call Ref: len= 1 (reference 153/0x99) (Terminator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
    -- Hungup 'Zap/4-1'
fish*CLI>
< [ 00 8d 01 08 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 070        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 004 P/F: 0
< 0 bytes of data
-- ACKing all packets from 2 to (but not including) 4
-- ACKing packet 3, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Nothing left, starting T203 counter
-- Restarting T203 counter
    -- parse_srv: SRV mapped to host sipgate.de, port 5060
fish*CLI>

An kpj habe ich einen ausführlichen Fehlerbericht geschickt - falls eine Antwort kommt (was ich sehr hoffe), halte ich Euch natürlich auf dem Laufenden...
 
Hallo Nexus,

ich hab genau das gleiche Problem. Ich verwende zwei HFC-Karten von Conrad. Eine im TE-Modus am Telekom-Netz, die zweite im NT-Modus mit angeschlossenem Siemens ISDN-Telefon. Zudem habe ich den Florz-patch installiert um die Interruptlast zu senken. Interruptgeber ist die NT-Karte, weil diese keinen Interrupt teilt. Die TE-Karte teilt den Interrupt mit der Netzwerkkarte, das kann ich leider nicht ändern. Evtl. liegt das daran. Ich hoffe dieser Threat bring ein wenig Licht ins Dunkel. Ach ja, ich nutze auch die Bristuff RC8h.

Bis denne

Simpel
 
@Simpel:
Dann freue ich mich ja fast schon, dass ich einen "Mitleidenden" habe ;)
Tritt bei Dir "nur" das Problem des sich auf- und abbauenden D-Kanals auf oder hast Du auch die Schwierigkeit, dass eingehende Anrufe deshalb teilweise nicht durch kommen?

Bei mir teilt eine der HFC-Karten den Interrupt mit der Grafikkarte. Ich habe aber auch schon die Karte ohne Interrupt-Teilung in den TE-Modus gestellt - das Problem tritt auch in dieser Konstellation noch unverändert auf.
 
Bisher hatte ich keine Probleme, aber ich hab auch nicht soviele eingehende Gespräche. Evtl. würde es helfen bei der Telekom bzw. beim Telkoanbieter zu beantragen, daß die Schicht drei nicht mehr abgebaut wird. In der EWSD kann man das über einen Befehl regeln. Ich vermute, daß der Zaptel Driver nicht mit deutschen verhältnissen klar kommt. Ein ähnliches Problem gab es anfangs mit dem ext. ISDN TA von USRobotics bzw. 3COM, der hat die Verbindung nach Abbau der Schicht 3 komplett verloren.

Gruß

Simpel
 
Nur zur Dokumentation: Nachdem auf meine Fehlermeldung an kpj leider keine Rückmeldung kam, habe ich nun doch mal meine Telefongesellschaft (in diesem Fall Alice/Hansenet) gequält. Dort hat man jetzt wie von simpel vorgeschlagen veranlasst, dass Schicht 3 nicht mehr abgebaut wird ("Dauersignal"). Seitdem ist mein Problem, dass jeweils der erste Anruf nach längerer Nichtnutzung des Anschlusses abbricht, verschwunden - alles funktioniert jetzt perfekt.

Dieses Dauersignal zu bekommen, war übrigens erstaunlich einfach und innerhalb von 30 Minuten (an einem Samstag!) erledigt - ich möchte gar nicht wissen, wie schwierig das bei der T-Com gewesen wäre ;)

Obwohl das zwar keine Lösung des eigentlichen Problems ist - dieses muss ja irgendwo in den Asterisk-Treibern verborgen liegen - ist ein Dauersignal von der Telco wohl zumindest ein adäquater Workaround.

Viele Grüße,

Bastian
 
Hallo Nexus,

das war ja einfach ;-)....aber scheint wohl ein Problem von Deinem Telco zu sein. Ich hänge an der Telekom...da kommt auch regelmässig Up/Down...schätze mal so alle 2-5 Minuten...aber trotzdem funzt hier alles bestens.
Aber Du hast Recht, bei den Telekomikern wär das ein Problem geworden u.U hätte das sogar noch Geld gekostet....jeden Monat..

Christian
 
Hallo Leute,

leider habe ich ein ähnliches Problem:
ich hab mir den neuesten Bristuff-0.2.0-RC8o installiert und den Florz Patch drüber gepatcht.
Im Server befinden sich 3 HFC-S Karten, wovon eine im NT Modus ist.

Wenn ich nun mit dem ISDN Telefon eine Nummer anrufe, komm ich auch wunderbar durch.
Jedoch, wenn ich lokal auf dem Server die Console aufrufe und set verbose 4 eingebe und anschließend versuche zu telefonieren, kommt erst gar keine Verbindung zustande.
Als Fehlermeldung bekomme ich zunächst die up-/down meines D-Kanales und meistens auch die Meldung:
b channel buffer underrun: 0, 0
b channel buffer overflow: 44, 44

Kann mir vielleicht jemand weiterhelfen?

Gruß,

Wolfgang
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 828 (Mitglieder: 31, Gäste: 797)

Neueste Beiträge

Statistik des Forums

Themen
246,115
Beiträge
2,246,360
Mitglieder
373,601
Neuestes Mitglied
Bernd1712
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück