Asterisk mit QSIG

Google mit "asterisk qsig" gefüttert, ergab z.B. das:

http://www.ip-phone-forum.de/forum/viewtopic.php?t=19755
http://www.computerwoche.de/nachrichten/568820
http://www.silicon.de/cpo/news-telecom/detail.php?nr=25002

Scheint so, als ob es wirklich erst ab 1.2.0 geht.

Ohne jetzt die oben ganannten Links genauer zu lesen, kann ich nur sagen, dass es mit chan_capi-cm und Eicon Diva Server Karten funktioniert, unabhaengig von der Asterisk Version.

Armin

Vorsicht, eventuell Missverstaendnis! Mit den Eicon Diva Server Karten funktioniert es, denn die koennen eine ganze Menge QSIG Dialekte und nach oben trotzdem 'normal' CAPI.
QSIG Besonderheiten sind im chan_capi noch nicht drin (falls es da ueberhaupt Bedarf gibt), denn ich selbst hab kein QSIG um es zu testen.
Wie sich das mit den AVM Karten verhaelt, kann ich allerdings gar nicht sagen.

Armin

Habe mir die Links jetzt auch mal angeschaut. Bei "Asterisk kann jetzt auch QSIG" geht es wohl um die HFC basierten Karten, wo die von Digium auch Treiber zu bekommen sind und diese Treiber koennen jetzt auch QSIG zusammen mit den Asterisk Aenderungen.
Bei CAPI spielt das keine Rolle. Egal welches Protokoll die Karte faehrt, CAPI ist hier gleich und kann es eben (bis auf ein paar kleine Zusaetze manchmal, die nicht ueber CAPI spezifiziert sind).
Ob nun die AVM Karten ueberhaupt QSIG koennen, kann ich nicht sagen. Eicon hat es mit im Programm.

Armin

Wenn die C4-Karten das koennen, dann sollte es auch mit jeder Asterisk Version funktionieren, sofern sich die C4 an die CAPI spec haelt.
Aus Sicht der Asterisk gibt es da kein QSIG, da alles ueber CAPI laeuft.
Status und Ergebnisse interessieren mich sehr, eventuell koennen wir QSIG Besonderheiten mit in chan_capi einbauen.

Armin

Ich würde auch gern Q.Sig nutzen. Ich habe mir sagen lassen das unsere HiPath 3750 beliebige CallerID-Numbers nur akzeptiert, wenn das über Q.Sig passiert.... weiss einer ob das stimmt? Ich möchte halt, das im lokalem S0-Netz die Amtsrufnummern vom 2. Standort angezeigt werden (IAX Verbindung)

Ich will mich gerade mal in die Richtung QSIG Integration bewegen.
Ich habe hier eine Alcatel 4400 und eine Eicon DIVA Server BRI zur Verfügung.

Hier kommt immer mal wieder die Frage nach QSIG auf und ich benötige es auch zukünftig wohl öfters mal auf Arbeit...

Ich weiß noch nicht, wie weit ich das zeitlich und programmiermässig hinbekomme (bin in C etwas eingerostet), hatte aber letztes Jahr schonmal erste Tests gemacht - QSIG lief damals schon unter Asterisk 1.0 irgendwas (mit der Eicon). Die besonderen Features werden halt nicht von chan_capi ausgewertet, hab' sie aber im Trace schon gesehen (Facility IE's).
Die Spezifikationen sind auch bei pda.etsi.org beziehbar.
Mit Unterstützung ist das aber mit Sicherheit in den Griff zu kriegen ;-)

Mario

Sicher ist das zu machen. Die Eicon Karte kann QSIG und die besonderen Featueres, die ueber standard CAPI nicht benutzbar sind, koennen trotzdem
von chan_capi ausgewertet werden.
Wenn diese IEs von Funktion und Struktur gut bekannt sind, dann koennen wir
das in chan_capi einbauen.

Armin

armincm schrieb:

Sicher ist das zu machen. Die Eicon Karte kann QSIG und die besonderen Featueres, die ueber standard CAPI nicht benutzbar sind, koennen trotzdem
von chan_capi ausgewertet werden.
Wenn diese IEs von Funktion und Struktur gut bekannt sind, dann koennen wir
das in chan_capi einbauen.

Armin

Zum Vergrößern anklicken....

Super, die Antwort gefällt mir

Ich hab' hier einige PDFs und mich die letzten Wochen öfters mit QSIG Traces zwischen Alcatel und anderen Anlagen herumgeschlagen - bin bald per du damit
Und das schönste daran ist: ich hab' ne 4400 mit der ich das zuhause in Ruhe testen und rumspielen kann...

Gruß Mario

Ich hab' hier mal ein Beispiel aus einem capi debug letzten Jahres, wo man auch schön die Namensübermittlung im facility array sehen kann:


Jun 19 21:18:59 NOTICE[2912]: chan_capi.c:1931 capi_handle_msg: CONNECT_IND ID=001 #0x018d LEN=0212
Controller/PLCI/NCCI = 0x101
CIPValue = 0x10
CalledPartyNumber = <80>599
CallingPartyNumber = <00 81>310
CalledPartySubaddress = default
CallingPartySubaddress = default
BC = <80 90 a3>
LLC = default
HLC = <91 81>
AdditionalInfo
BChannelinformation = default
Keypadfacility = default
Useruserdata = default
Facilitydataarray = <1c 84 91 aa 06 80 01 00 82 01 00 8b 01 00 a1 11 02 02 2e e0 06 04 2b 0c 09 00 80 05>Mario<a1>E<02 01 01 06 06 2b 0c 02 88>R<01>08<80 05 06 c4>F<03 04 82 01 00 83 01 01 ab 29>0<0f 02 02 1b>X0<09 83 01 01 84 01 11 85 01 01>0<16 02 02 1b 5d>0<10 80 01 01 81 01 03 84 05 00 c0> <00 5c 86 01 00 a1 1c 02 01 19 06 06 2b 0c 02 88>R<19>0<0f 80 01 04 81 02 07 00 aa 06 02 02 1b>Z<01 01 1c 23 91 aa 06 80 01 00 82 01 01 8b 01 00 a1 15 02 02 2a fe 06 07 2b 0c 02 88>R<d5 7e>0<06 02 01 00 02 01 00>


die anderen Einträge sind dokumentiert und kann ich schön mit dem Trace aus der Alcatel vergleichen.

@armincm: ich kann dir ja auch mal das ETSI PDF zusenden...

Mario

Du hast geschrieben, dass du mit C etwas eingerostet bist. Aber wenn Du die 'Regeln' mal zusammenstellst (also wann muss was aus welchen Daten wie verarbeitet oder gesendet werden), dann kann ich das in chan_capi einbauen.

Armin

mach' ich - mal sehen, ob ichs dir morgen schon mal was mailen kann...

Hi Armin,

armincm schrieb:

Du hast geschrieben, dass du mit C etwas eingerostet bist. Aber wenn Du die 'Regeln' mal zusammenstellst (also wann muss was aus welchen Daten wie verarbeitet oder gesendet werden), dann kann ich das in chan_capi einbauen.

Armin

Zum Vergrößern anklicken....

ich hab's leider gestern doch noch nicht geschafft, mußte meine Anlage erstmal wieder zusammenstöpseln, aber jetzt hab ich sie erstmal wieder am laufen.

Ich hab' hier nochmal einen Trace für einen Call aus der Alcatel zum Asterisk, der erklärt schon einiges. Näheres muss ich nochmal aus den ETSI PDF's zusammenstellen, damit du nicht unbedingt erstmal alles lesen musst.


----------
______________________________________________________________________________
| (009961:000051) 93: Send_IO1 (link-nbr=5, sapi=0, tei=0) :
| long: 262 desti: 0 source: 15 cryst: 0 cpl: 5 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 00 06
| SENDING COMPLETE
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a9 83 82 -> T2 : B channel 2 exclusive
| IE:[1c] FACILITY (l=132)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=17):
| Invoke Ident. : 2ee0 (12000)
| OP: ECMA RO_CALLING_NAME (0)
| [80] Name presentation allowed (l=5) 'Mario'
| [a1] INVOKE (l=69):
| Invoke Ident. : 0001 (1)
| OP: ALCATEL RO_CLASSMARKS (1)
| [30] Sequence (l=56)
| [80] Feature identifier (l=5) 06 c4 46 03 04
| [82] Cug (l=1) 00
| [83] SubNetwork number (l=1) 01
| [ab] Sequence of Project data (l=41)
| [30] Sequence (l=15)
| OP :RO_CLASSMARKS_SUPPLEMENTARY_INFO_1 (7000)
| [30] Sequence (l=9)
| [83] Current entity (l=1) 01
| [84] Initial kind of call (l=1) 11
| [85] Context specific (l=1) 01
| [30] Sequence (l=22)
| OP :RO_SERVER_ACCESS_INFO (7005)
| [30] Sequence (l=16)
| [80] Language (l=1) 01
| [81] type of set (l=1) 03
| [84] Feature identifier 2 (l=5) 00 c0 20 00 5c
| [86] Priority of call (l=1) 00
| [a1] INVOKE (l=28):
| Invoke Ident. : 0019 (25)
| OP: ALCATEL RO_MINIMES (25)
| [30] Sequence (l=15)
| [80] Message (l=1) 04 IA5 : no message
| [81] Presentation (l=2) 07 00
| [aa] Project Data (l=6)
| OP :RO_UUS_INFO_EXTENSION (7002)
| Party Category -> EXTENSION (1)
| IE:[1c] FACILITY (l=35)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) Any_type_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=21):
| Invoke Ident. : 2afe (11006)
| OP: ALCATEL Unknown (11006)
| [30] Sequence (l=6)
| [02] Integer (l=1) 00
| [02] Integer (l=1) 00
| IE:[27] NOTIF_INDI (l=23)
| 83 : discriminator for notif. extention
| [30] Sequence (l=20)
| OP : 1b77 (7031)
| [30] Sequence (l=9)
| [12] Numeric string (l=3) 33 31 30
| [02] Integer (l=2) 01 0b
| IE:[27] NOTIF_INDI (l=14)
| 83 : discriminator for notif. extention
| [30] Sequence (l=11)
| OP : 1b7d (7037)
| [05] ARG NULL (l=0)
| IE:[6c] CALLING_NUMBER (l=5) -> 00 81 Num : 310
| IE:[70] CALLED_NUMBER (l=4) -> 80 Num : 512
| IE:[7d] HLC (l=2) 91 81
| [95] Locking shift. codeset : 5
| IE:[32] EI_PARTY_CATEGORY (l=1) -> EXTENSION (1)
|______________________________________________________________________________

______________________________________________________________________________
| (009963:000056) Physical-Event :
| long: 23 desti: 2 source: 0 cryst: 0 cpl: 5 us: 0 term: 1 type a5
| tei: 0 >>>> message received : CALL PROC (02) Call ref : 80 06
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 82 -> T2 : B channel 2 exclusive
|______________________________________________________________________________

______________________________________________________________________________
| (009963:000057) Physical-Event :
| long: 23 desti: 2 source: 0 cryst: 0 cpl: 5 us: 0 term: 1 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 80 06
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 82 -> T2 : B channel 2 exclusive
|______________________________________________________________________________

______________________________________________________________________________
| (010026:000058) 93: Send_IO1 (link-nbr=5, sapi=0, tei=0) :
| long: 52 desti: 0 source: 15 cryst: 0 cpl: 5 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : DISCONNECT [45] Call ref : 00 06
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING
| IE:[1c] FACILITY (l=27)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [a1] INVOKE (l=16):
| Invoke Ident. : 1b89 (7049)
| OP: ALCATEL RO_CALL_NOT_ANSWERED (7049)
| [0a] No answer list (l=1) 02
|______________________________________________________________________________

______________________________________________________________________________
| (010027:000059) Physical-Event :
| long: 36 desti: 2 source: 0 cryst: 0 cpl: 5 us: 0 term: 1 type a5
| tei: 0 >>>> message received : FACILITY [62] Call ref : 80 06
|______________________________________________________________________________
|
| IE:[1c] FACILITY (l=16)
| [9f] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [a4] REJECT (l=5):
| [05] Nul (l=0)
| [81] Invoke Problem (l=1) Mistyped Argument (2)
|______________________________________________________________________________

______________________________________________________________________________
| (010027:000060) 93: Send_IO1 (link-nbr=5, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 0 cpl: 5 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : REL COMP [5a] Call ref : 00 06
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=3) 80 e4 00 -> [e4] INVALID INFORMATION ELEMENT CONTENTS
|______________________________________________________________________________

______________________________________________________________________________
| (010027:000061) Physical-Event :
| long: 18 desti: 2 source: 0 cryst: 0 cpl: 5 us: 0 term: 1 type a5
| tei: 0 >>>> message received : RELEASE [4d] Call ref : 80 06
|______________________________________________________________________________

---------

der Trace vom Asterisk dazu:

---------
-- CONNECT_IND ID=001 #0x0ba0 LEN=0212
Controller/PLCI/NCCI = 0x201
CIPValue = 0x10
CalledPartyNumber = <80>512
CallingPartyNumber = <00 81>310
CalledPartySubaddress = default
CallingPartySubaddress = default
BC = <80 90 a3>
LLC = default
HLC = <91 81>
AdditionalInfo
BChannelinformation = default
Keypadfacility = default
Useruserdata = default
Facilitydataarray = <1c 84 91 aa 06 80 01 00 82 01 00 8b 01 00 a1 11 02 02 2e e0 06 04 2b 0c 09 00 80 05>Mario<a1>E<02 01 01 06 06 2b 0c 02 88>R<01>08<80 05 06 c4>F<03 04 82 01 00 83 01 01 ab 29>0<0f 02 02 1b>X0<09 83 01 01 84 01 11 85 01 01>0<16 02 02 1b 5d>0<10 80 01 01 81 01 03 84 05 00 c0> <00 5c 86 01 00 a1 1c 02 01 19 06 06 2b 0c 02 88>R<19>0<0f 80 01 04 81 02 07 00 aa 06 02 02 1b>Z<01 01 1c 23 91 aa 06 80 01 00 82 01 01 8b 01 00 a1 15 02 02 2a fe 06 07 2b 0c 02 88>R<d5 7e>0<06 02 01 00 02 01 00>

Feb 20 22:18:45 NOTICE[2749]: chan_capi.c:1931 capi_handle_msg: CONNECT_IND ID=001 #0x0ba0 LEN=0212
Controller/PLCI/NCCI = 0x201
CIPValue = 0x10
CalledPartyNumber = <80>512
CallingPartyNumber = <00 81>310
CalledPartySubaddress = default
CallingPartySubaddress = default
BC = <80 90 a3>
LLC = default
HLC = <91 81>
AdditionalInfo
BChannelinformation = default
Keypadfacility = default
Useruserdata = default
Facilitydataarray = <1c 84 91 aa 06 80 01 00 82 01 00 8b 01 00 a1 11 02 02 2e e0 06 04 2b 0c 09 00 80 05>Mario<a1>E<02 01 01 06 06 2b 0c 02 88>R<01>08<80 05 06 c4>F<03 04 82 01 00 83 01 01 ab 29>0<0f 02 02 1b>X0<09 83 01 01 84 01 11 85 01 01>0<16 02 02 1b 5d>0<10 80 01 01 81 01 03 84 05 00 c0> <00 5c 86 01 00 a1 1c 02 01 19 06 06 2b 0c 02 88>R<19>0<0f 80 01 04 81 02 07 00 aa 06 02 02 1b>Z<01 01 1c 23 91 aa 06 80 01 00 82 01 01 8b 01 00 a1 15 02 02 2a fe 06 07 2b 0c 02 88>R<d5 7e>0<06 02 01 00 02 01 00>

== CONNECT_IND (PLCI=0x201,DID=512,CID=310,CIP=0x10,CONTROLLER=0x1)
-- INFO_IND ID=001 #0x0ba1 LEN=0019
Controller/PLCI/NCCI = 0x201
InfoNumber = 0x70
InfoElement = <80>512

-- INFO_IND ID=001 #0x0ba2 LEN=0018
Controller/PLCI/NCCI = 0x201
InfoNumber = 0x18
InfoElement = <a9 83 82>

-- INFO_IND ID=001 #0x0ba3 LEN=0015
Controller/PLCI/NCCI = 0x201
InfoNumber = 0x8005
InfoElement = default

-- ALERT_CONF ID=001 #0x0ba0 LEN=0014
Controller/PLCI/NCCI = 0x201
Info = 0x0

-- INFO_IND ID=001 #0x0ba4 LEN=0042
Controller/PLCI/NCCI = 0x201
InfoNumber = 0x1c
InfoElement = <91 aa 06 80 01 00 82 01 00 a1 10 02 02 1b 89 06 07 2b 0c 02 88>R<b7 09 0a 01 02>

-- DISCONNECT_IND ID=001 #0x0ba5 LEN=0014
Controller/PLCI/NCCI = 0x201
Reason = 0x0

== DISCONNECT_IND PLCI=0x201 REASON=0
== Spawn extension (capicall, 512, 1) exited non-zero on 'CAPI[contr1/512]/18'
== Spawn extension (default, 12, 1) exited non-zero on 'Local/12@default-37cf,2'
-------------

für ein paar Bytes vor dem Namen fehlt mir auch noch eine genaue Beschreibung (d.h. ich hab's in den PDFs noch nicht gefunden).

Im Prinzip gelten eigentlich die selben "Regeln", wie im Euro-ISDN, hier sind lediglich einige Facilities mehr definiert.
Einiges von den Informationen kann man vermutlich im Asterisk ignorieren, da es im * vermutlich keine Entsprechung gibt.

Was äußerst interessant für die Alcatel wäre (also abgehend vom Asterisk) ist die Festlegung von Progress-Informationen, also der Ursprung des Calls, damit hat die Alcatel eine Möglichkeit zwischen externen und internen Calls zu unterscheiden (Klingelton). Leider ist das in diesem Trace nicht dabei, dafür kann ich aber auch noch Beispiele geben, wie sowas aussehen müsste.

So, für heute hab' ich genug gebastelt, mehr Infos evtl. morgen...

Gruß Mario

Ich hatte die letzte Woche doch leider weniger Zeit.
Was mir bei den wenigen tests aufgefallen ist: Wenn eine segmented Setup Message, dann stürzt mein asterisk PC komplett ab - IMHO gab's da eine Kernel-Panic.

Wo das Problem im Moment liegt weiß ich nicht - kommt chan_capi(-cm) derzeit nicht mit diesen Messages klar?
______________________________________________________________________________
| (979363:000040) 88: Send_IO1 (link-nbr=5, sapi=0, tei=0) :
| long: 343 desti: 0 source: 15 cryst: 0 cpl: 5 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 00 0f
|
| CONCATENATION OF 2 SEGMENTED MESSAGES
|______________________________________________________________________________
|
| [a1] Sending complete
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a9 83 82 -> T2 : B channel 2 exclusive
| IE:[1c] FACILITY (l=146)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=15):
| Invoke Ident. : 2ee0 (12000)
| OP: ECMA RO_CALLING_NAME (0)
| [80] Name presentation allowed (l=3) 'Amt'
| [a1] INVOKE (l=93):
| Invoke Ident. : 0001 (1)
| OP: ALCATEL RO_CLASSMARKS (1)
| [30] Sequence (l=80)
| [80] Feature identifier (l=5) 06 44 c0 1f 00
| [82] Cug (l=1) 05
| [83] SubNetwork number (l=1) 01
| [84] Trunk identity (l=1) 30
| [ab] Sequence of Project data (l=62)
| [30] Sequence (l=25)
| OP :RO_CLASSMARKS_SUPPLEMENTARY_INFO_1 (7000)
| [30] Sequence (l=19)
| [80] Trunk group feature (l=5) 06 01 80 00 00
| [81] Trunk group type (l=1) 08
| [83] Current entity (l=1) 00
| [84] Initial kind of call (l=1) 11
| [85] Context specific (l=1) 00
| [30] Sequence (l=22)
| OP :RO_SERVER_ACCESS_INFO (7005)
| [30] Sequence (l=16)
| [80] Language (l=1) 01
| [81] type of set (l=1) 00
| [84] Feature identifier 2 (l=5) 00 c0 20 00 5c
| [86] Priority of call (l=1) 00
| [30] Sequence (l=9)
| OP :RO_AUTOMATED_ATTENDANT (7004)
| [30] Sequence (l=3)
| [80] Context specific (l=1) 00
| [a1] INVOKE (l=20):
| Invoke Ident. : 1b9d (7069)
| OP: ALCATEL RO_DIVERTING_LEG_INFO_CSTA (7069)
| [30] Sequence (l=5)
| [82] Initial Called Number (l=3) '512'
| IE:[1c] FACILITY (l=35)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) Any_type_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=21):
| Invoke Ident. : 2afe (11006)
| OP: ALCATEL Unknown (11006)
| [30] Sequence (l=6)
| [02] Integer (l=1) 00
| [02] Integer (l=1) 00
| IE:[1e] PROGRESS_ID (l=2) a0 90
| IE:[27] NOTIF_INDI (l=20)
| 83 : discriminator for notif. extention
| [30] Sequence (l=17)
| OP : 1b77 (7031)
| [30] Sequence (l=6)
| [04] Octet string (l=0)
| [02] Integer (l=2) 01 0b
| IE:[27] NOTIF_INDI (l=14)
| 83 : discriminator for notif. extention
| [30] Sequence (l=11)
| OP : 1b7d (7037)
| [05] ARG NULL (l=0)
| IE:[27] NOTIF_INDI (l=31)
| 83 : discriminator for notif. extention
| [30] Sequence (l=28)
| OP : 1b8d (7053)
| [30] Sequence (l=17)
| [02] Integer (l=1) 05
| [02] Integer (l=1) 0b
| [30] Sequence (l=9)
| [02] Integer (l=1) 02
| [02] Integer (l=1) 00
| [02] Integer (l=1) 00
| IE:[6c] CALLING_NUMBER (l=12) -> 21 81 Num : 173561xxxx
| IE:[70] CALLED_NUMBER (l=4) -> 80 Num : 512
| IE:[7d] HLC (l=2) 91 81
| [95] Locking shift. codeset : 5
| IE:[32] EI_PARTY_CATEGORY (l=1) -> UNKNOWN (0)
|______________________________________________________________________________

______________________________________________________________________________
| (979370:000042) Physical-Event :
| long: 23 desti: 2 source: 0 cryst: 0 cpl: 5 us: 0 term: 1 type a5
| tei: 0 >>>> message received : CALL PROC (02) Call ref : 80 0f
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 82 -> T2 : B channel 2 exclusive
|______________________________________________________________________________

______________________________________________________________________________
| (979437:000043) Physical-Event :
| long: 21 desti: 2 source: 0 cryst: 0 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : RELEASE [4d] Call ref : 5a
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 80 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

______________________________________________________________________________
| (979437:000044) 91: Send_IO1 (link-nbr=5, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 0 cpl: 5 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : DISCONNECT [45] Call ref : 00 0f
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

______________________________________________________________________________
| (979438:000045) 88: Send_IO1 (link-nbr=5, sapi=0, tei=0) :
| long: 21 desti: 0 source: 15 cryst: 0 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : REL COMP [5a] Call ref : da
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

______________________________________________________________________________
| (979477:000046) 88: Send_IO1 (link-nbr=5, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 0 cpl: 5 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : RELEASE [4d] Call ref : 00 0f
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

______________________________________________________________________________
| (979477:000047) Physical-Event :
| long: 22 desti: 2 source: 0 cryst: 0 cpl: 5 us: 0 term: 1 type a5
| tei: 0 >>>> message received : REL COMP [5a] Call ref : 80 0f
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 80 e3 -> [e3]
| INFORMATION ELEMENT NON-EXISTENT OR NOT IMPLEMENTED
|______________________________________________________________________________

Ein Kernel Panic? Das kann nicht von chan_capi kommen, sondern eher von ISDN Treiber der Karte.

Armin

an sich hast du recht, das war auch mein Gedanke.
Ich hab' das System diese Woche erst von Sarge(noch testing) auf unstable hoch gerüstet. Das einzige, was unverändert ist, ist WIMRE der Kernel/diva-Treiber.

Der * capi channel wurde von chan_capi auf chan_capi-cm 0.6.4 upgedatet.

Witzigerweise stürzt die Kiste nicht ab, solange asterisk nicht läuft - der Ruf wird mit "unassigned Number" zurückgewiesen, solange keine capi Appli auf einen Arnuf wartet.
Werde das ganze nochmal mit irgendeiner anderen Capi Anwendung checken...

PS: werde mir für zukünftige traces mal ein wiki aufsetzen, das wird hier im Thread etwas unübersichtlich und lang...

ok, nachdem ich den kernel mal upgedatet habe, funktioniert auch eine rufumleitung durch die Alcatel, allerdings sehe ich mit dem chan_capi-cm 0.6.4 das facility data array nicht mehr, selbst mit verbosity von 10 steht da nur default, kann man das wieder sichtbar machen?