Asterisk als ISDN Anlage und QSIG

Ja Q.SIG ist auf L3 ... aber ich verstehe immer noch nicht wie ihr das implementiert habt. Die Karte an sich verseht ja Q.SIG... dh die Pakete wandern mitels der CAPI-Schnittstelle bis in L3 hoch. Da wird dann der Q.SIG-Code an chan_capi gereicht, den ihr dann in chan_capi so aufbereitet, dass Asterisk damit umgehen kann. Asterisk klappert dann sein extension.conf ab und reicht gegeben falls Infos an chan_capi weiter. chan_capi reicht dann die Information Q.SIG konform an die CAPI-Schnittstelle. CAPI packt dann alles auf die lustigen Käfer auf der Karten und dieser jagt dann das Paket raus. Firmware und Treiber sorgt dafür, dass bis in L1-L3 alles richtig läuft. Ist das richtig?

Ach hab da nun mal eine sehr provisorische Skizze gemacht wie das aussehen könnte mit der OSI-Einordnung(Anhang).


mir fehlt auch irgendwie eine gescheite Spezifikation von Q.SIG ... ich weiß was es ist und dass es sich in SS, GF, BS aufteilt... dass ist aber auch das einzigste, mehr geben die Seiten die ich über Q.SIG gefunden habe nicht preis. Ich würde aber gerne wissen wie das von innen aussieht...

Gruß! T33baum
 

Anhänge

  • OSI.pdf
    105.7 KB · Aufrufe: 8
Das passt so nicht ganz, denke ich.
Im Prinzip musst dir das so vorstellen, das einfach an eine SETUP Nachricht einfach in ein dafür vorgesehenes Array ein paar zusätzliches Bytes eingepackt sind (Facility-Array).
Dort werden ein paar zusätzliche Informationen kodiert, die die Anwendung (chan_capi) auswerten kann oder auch nicht.
Ein paar Beispiele, wie das aussehen tut, findest du unter http://wikihost.org/wikis/qsigast/wiki/start
Wenn du dort mal einen Link zu einen Trace folgst siehst du innerhalb einer ISDN Nachricht erst die entspr. ISDN Infos (SETUP, DISCONNECT, etc) und da halt ein paar Bytes vom QSIG.
Wenn man QSIG nicht in derselben Schicht wie chan_capi ansiedeln will, dann würde ich es eigentlich in eine höhere Ebene setzen, welche dann aber nicht 4 ist (lt. Definition).

Mario
 
Ich hab mir mal die Logs angeschaut, ich log eigentlich mit /usr/lib/divas/divalog ... meine Logs sehen etwas änderst aus ... jedoch kommen da auch Facility-Array vor ...

dreht es sich bei qsig nur um diese Facility-Array ... alles andere ist pupsnormale ISDN DSS1 Protokoll ..... hmmm bzw Q.931 ?

also wenn ich mich nun wirklich nicht irre ... ist Q.SIG Basic Call komplett Q.931. Generic Funktion beinhaltet die "Facility" mit diesen Protocol Profile, Network Facility Extension, Network Protocol Profile, Interprtation APDU und Service APDU. Die nächste stufe beinhaltet eben Supplementary Service. Additional Network Features und Generic Funktion Procedures.

dh. die Magie steckt in der Facility IE ... und mit chan_capi tut ihr eben diese je nach Gebrauch dekodieren oder codieren (hab mir mal den Code angeschaut)

ich hab mir nun mal ECMA-165, ECMA-133, ECMA-143 Spezifikation und die Q.931 ( 05/98 ) Spezifikation von der ITU zum lesen besorgt ... gibt es noch eine Spezifikation die dir spontan einfällt das lesenswert ist?

Wenn man QSIG nicht in derselben Schicht wie chan_capi ansiedeln will, dann würde ich es eigentlich in eine höhere Ebene setzen, welche dann aber nicht 4 ist (lt. Definition).

verseht nicht ganz was du mit meinst ... q.sig ist ein Protokoll auf L3 den kann ich wohl kaum höher stufen... und so wie ich das nun verstanden habe, modifiziert ihr mit der chan_capi über die CAPI-Schnittstelle/Treiber ... was auch immer ( die ja für den ganzen L1-L3 Geschichten zuständig ist ... das sind dann diese B1-B3 )Schichten ) im Facility IE rum. Ob chan_capi nun L4 ist oder höher ist eigentlich egal ... es gehört aber (denk ich zumindest) zwischen Asterisk und CAPI 2.0

Gruß! t33baum
 
Ich hab mir mal die Logs angeschaut, ich log eigentlich mit /usr/lib/divas/divalog ... meine Logs sehen etwas änderst aus ... jedoch kommen da auch Facility-Array vor ...

dreht es sich bei qsig nur um diese Facility-Array ... alles andere ist pupsnormale ISDN DSS1 Protokoll ..... hmmm bzw Q.931 ?

also wenn ich mich nun wirklich nicht irre ... ist Q.SIG Basic Call komplett Q.931. Generic Funktion beinhaltet die "Facility" mit diesen Protocol Profile, Network Facility Extension, Network Protocol Profile, Interprtation APDU und Service APDU. Die nächste stufe beinhaltet eben Supplementary Service. Additional Network Features und Generic Funktion Procedures.

dh. die Magie steckt in der Facility IE ... und mit chan_capi tut ihr eben diese je nach Gebrauch dekodieren oder codieren (hab mir mal den Code angeschaut)

Das ist im Prinzip korrekt - nur das hat mich ermutigt, sowas zu programmieren :)
Leider gibt es manche Features, die noch andere Aktionen erfordern.
zB. Rückruf bei besetzt oder MWI.
Dort muss zum Beispiel eine virtuelle Verbindung zwischen den Anlagen aufgebaut werden (also ein kompletter Anruf, ober ohne Belegung eines B-Kanals) und die Facilities werden dann auf den virtuellen Verbindungen übermittelt. Bei CCBS kann so eine Verbindung schonmal über längere Zeit bestehen bleiben.
Da gibts aktuell das Problem, das die DIVA Karten das noch nicht unterstützen - ist aber für Q2 zugesichert.
Auch chan_capi ist dafür noch nicht optimiert. Aber da ist schon was in Arbeit ;-).

ich hab mir nun mal ECMA-165, ECMA-133, ECMA-143 Spezifikation und die Q.931 ( 05/98 ) Spezifikation von der ITU zum lesen besorgt ... gibt es noch eine Spezifikation die dir spontan einfällt das lesenswert ist?
So aus dem Stehgreif fällt mir da nichts ein.
Ich habe speziell zu den einzelnen Features gegoogelt. Im H323 findet sich da immer passendes - das Protokoll ist stark an QSIG angelehnt - deswegen ist es wohl auch so kompliziert :blonk: .

verseht nicht ganz was du mit meinst ... q.sig ist ein Protokoll auf L3 den kann ich wohl kaum höher stufen... und so wie ich das nun verstanden habe, modifiziert ihr mit der chan_capi über die CAPI-Schnittstelle/Treiber ... was auch immer ( die ja für den ganzen L1-L3 Geschichten zuständig ist ... das sind dann diese B1-B3 )Schichten ) im Facility IE rum. Ob chan_capi nun L4 ist oder höher ist eigentlich egal ... es gehört aber (denk ich zumindest) zwischen Asterisk und CAPI 2.0

Ich hab' mich da wohl etwas falsch ausgedrückt - "höhere Schicht" passt nicht - eher setzt man den QSIG Teil in Schicht 3 über chan_capi.


Mario
 
Sallü... ich bins mal wieder.

Ich frage mich gerade was es damit aufsich hat, dass die DIVA Karte Q.SIG kann. Theoretisch ist doch Q.SIG mit jeder ISDN Karte möglich, die Q.931 kann und die es erlaubt in den Paketen (insbesonderes im Facility IE) rumzupfuschen.

Was macht also die DIVA Karte so besonders gegenüber den HFC Karten und vorallem inwiefern hat es euch geholfen, das die DIVA Karte Q.SIG kann bzw was ist dieses Q.SIG "können" ?

So wie ich das bis jetzt sehe, ist das einfach nur pure Zufall, das ihr Q.SIG mit einer DIVA Karte realisiert habt, genauso gut wäre dass auch bei mISDN oder bei vISDN mit einer HFC Karte möglich gewesen. Nur das die es bis jetzt einfach noch nicht Offiziell gemacht haben (bei vISDN hab ich zu mindestens eine Diplomarbeit gefunden, in dem die mit einigen dirty hacks es dann doch geschafft haben)


Ich hab' mich da wohl etwas falsch ausgedrückt - "höhere Schicht" passt nicht - eher setzt man den QSIG Teil in Schicht 3 über chan_capi.

Ich glaube ich verstehe was du damit meinst. Jedoch bezweifle ich, dass das ISO-OSI-Modell konform ist. Die erste Idee die du geschrieben hast gefällt mir dann schon besser ( chan_capi und Q.SIG auf einer Schicht)

gruß
t33baum
 
Die DIVA Karte ist eine aktive Karte. D.h. die gesammte Protokoll-Sache (eben auch QSIG) macht die Firmware auf der Karte, ohne dass die Applikation oder der Treiber etwas machen muss. Zusätzlich hat man natürlich immer noch die Möglichkeit (nicht immer), selbst mit 'reinzupfuschen'.

Armin
 
ok, und dieses "reinpfuschen" ist genau das was ihr mit chan_capi macht. Wird da eigentlich dann Direkt auf der Karte was geändert, oder geschieht das über eine bestimmte Schnittstelle?

Ich würde dann gerne noch eine Bestätigung für die Folgenden Annahmen haben:

Asterisk, kann mittels vISDN, mISDN, Bristuff und der chan_capi an ein ISDN-Netz gebunden werd.

vISDN: wird nicht mehr offiziell weiterentwickelt. Q.SIG ist zwar möglich jedoch ist bis jetzt (inoffiziell) nur die Basic Call Funktion Implementiert worden. Benötigt eine Karte mit HFC-Chip

mISDN: ist die Weiterentwicklung vom HISAX-Treiber. Mittels chan_misdn kann Asterisk auf die ISDN Karten zugreifen. Q.SIG ist möglich wurde aber offiziell noch nicht implementiert.

Bristuff: ist ein Patch von der Firma Junghanns für libPRI um auch günstige Karten mit HFC-Chip an Asterisk nutzen zu können. Q.SIG ist da irgendwo auch mit drin, jedoch nur Rudimentär (hier habt ihr es ja dann irgendwie geschafft)

chan_capi: ermöglicht ISDN-Server Karten über den CAPI Schnittstelle mit der Asteriskanlage zu nutzen. Q.SIG ist mit einer DIVA-Server Karte nutzbar ... es fehlen nur wenige Q.SIG Leistungsmerkmale wie zum Beispiel CCBS

Ich hoffe das das so im groben stimmt.
Wieso behauptet eigentlich Junghanns, das sie chan_capi entwickelt haben, ich hab bis jetzt gedacht, das chan_capi von armincm kommt.

t33baum
 
Sallü... ich bins mal wieder.

Ich frage mich gerade was es damit aufsich hat, dass die DIVA Karte Q.SIG kann. Theoretisch ist doch Q.SIG mit jeder ISDN Karte möglich, die Q.931 kann und die es erlaubt in den Paketen (insbesonderes im Facility IE) rumzupfuschen.
Fast, ich bin mir jetzt nicht 100% sicher, aber ich denke, dass es ein paar (kleine) Unterschiede im Layer 2 gibt. Sonst könnte man eigentlich auch einfach eine B1 nehmen und die an den Anschluss hängen, das ist mir bisher aber noch nicht gelungen... Ich wollte mich da immer mal intensiver mit beschäftigen, bin aber noch nicht dazugekommen...

Was macht also die DIVA Karte so besonders gegenüber den HFC Karten und vorallem inwiefern hat es euch geholfen, das die DIVA Karte Q.SIG kann bzw was ist dieses Q.SIG "können" ?
Einmal ist die Karte aktiv und hat 'nen EC (zumindest die Voice-fähigen Karten), zweitens ist es der Hersteller Support, der QSIG einschliesst :).
Das Q.SIG können ist es nicht unbedingt selbst...


So wie ich das bis jetzt sehe, ist das einfach nur pure Zufall, das ihr Q.SIG mit einer DIVA Karte realisiert habt, genauso gut wäre dass auch bei mISDN oder bei vISDN mit einer HFC Karte möglich gewesen. Nur das die es bis jetzt einfach noch nicht Offiziell gemacht haben (bei vISDN hab ich zu mindestens eine Diplomarbeit gefunden, in dem die mit einigen dirty hacks es dann doch geschafft haben)
Mein Ziel war es bisher eigentlich, den HFC Karten auch Q.SIG zu ermöglichen, leider wäre das ganze eine one-man Show und ich will mein Leben nicht NUR am PC verbringen ;-). Ich habe sonst noch andere Projekte, wo ich was lernen, bzw. was vollbringen will.

Technisch ist es absolut kein Problem, den HFC stacks das beizubringen. mISDN bietet z. Bsp schon einige Grundvorraussetzungen an Routinen, um die Leistungsmerkmale zu codieren, da manche ISDN LMs (AOC*) ähnlich codiert werden. Mir mangelt es da einfach nur an Zeit und Leuten, die da mit programmieren würden. Nur wird es vermutlich das Problem sein, dass man keine Anlage zuhause hat, mit der man da was testen kann, oder nicht programmieren kann, wenn man solche Technik zur Verfügung hat :confused: .

vISDN hätte an sich auch gute Möglichkeiten geboten, da die Jungs dort aber seit der Code-Umstellung scheinbar kein interesse mehr am ISDN Teil haben (mein HFC Karten laufen da nicht mehr), ist es leider für mich tot.

Ich glaube ich verstehe was du damit meinst. Jedoch bezweifle ich, dass das ISO-OSI-Modell konform ist. Die erste Idee die du geschrieben hast gefällt mir dann schon besser ( chan_capi und Q.SIG auf einer Schicht)
Naja, ich habe mich auch nicht so sehr mit den OSI Schichten im Detail auseinandergesetzt. Ich habe einfach mit meinem Wissen aus meiner Berufserfahrung angefangen zu programmieren, fertig. ;)

ok, und dieses "reinpfuschen" ist genau das was ihr mit chan_capi macht. Wird da eigentlich dann Direkt auf der Karte was geändert, oder geschieht das über eine bestimmte Schnittstelle?
Naja, wir "pfuschen" da nirgends anders, als an der CAPI Schnittstelle rum, indem wir einfach ein Array zusätzlich mit übergeben und die Eicon/Dialogic eigenen Hersteller-Funktionen links liegen lassen, da wir sonst ein DIVA SDK nutzen müssten :)

Ich würde dann gerne noch eine Bestätigung für die Folgenden Annahmen haben:

Asterisk, kann mittels vISDN, mISDN, Bristuff und der chan_capi an ein ISDN-Netz gebunden werd.
korrekt

vISDN: wird nicht mehr offiziell weiterentwickelt. Q.SIG ist zwar möglich jedoch ist bis jetzt (inoffiziell) nur die Basic Call Funktion Implementiert worden. Benötigt eine Karte mit HFC-Chip
korrekt, HFC-4-Port Karten funktionieren wohl noch mit dem letzten Stand.

mISDN: ist die Weiterentwicklung vom HISAX-Treiber. Mittels chan_misdn kann Asterisk auf die ISDN Karten zugreifen. Q.SIG ist möglich wurde aber offiziell noch nicht implementiert.
korrrekt

Bristuff: ist ein Patch von der Firma Junghanns für libPRI um auch günstige Karten mit HFC-Chip an Asterisk nutzen zu können. Q.SIG ist da irgendwo auch mit drin, jedoch nur Rudimentär (hier habt ihr es ja dann irgendwie geschafft)
kann ich nicht direkt was zu sagen, kenne bristuff nicht - mir war bisher unklar, ob libpri hier bei HFC Karten genutzt wird.

chan_capi: ermöglicht ISDN-Server Karten über den CAPI Schnittstelle mit der Asteriskanlage zu nutzen. Q.SIG ist mit einer DIVA-Server Karte nutzbar ... es fehlen nur wenige Q.SIG Leistungsmerkmale wie zum Beispiel CCBS
so in etwa (CAPI gibts auch bei passiven Karten oder alternativ über mISDN)

Ich hoffe das das so im groben stimmt.
Wieso behauptet eigentlich Junghanns, das sie chan_capi entwickelt haben, ich hab bis jetzt gedacht, das chan_capi von armincm kommt.

t33baum
Die haben damit angefangen, wenn ich die changelogs richtig interpretiert habe, dann hat Armin sich den channel irgendwann gekrallt und einen fork gemacht, seitdem wird der originale wohl auch von Junghanns nicht mehr weiter gepflegt (deshalb gab es dann auch zwischenzeitlich Versionen namens chan_capi-cm)
Korrekt Armin? :)

Mario
 
Die haben damit angefangen, wenn ich die changelogs richtig interpretiert habe, dann hat Armin sich den channel irgendwann gekrallt und einen fork gemacht, seitdem wird der originale wohl auch von Junghanns nicht mehr weiter gepflegt (deshalb gab es dann auch zwischenzeitlich Versionen namens chan_capi-cm)
Korrekt Armin? :)

Ja, die Version von Junghanns damals (0.3.5) wollte ich erweitern, aber das hat mir alles zu lange gedauert. Deswegen habe ich darauf chan-capi-cm (ab 0.5) generiert. Da Junghanns da nicht weitergemacht hat, habe ich das -cm wieder weggelassen und chan-capi.org ins Leben gerufen.

Armin
 
Sallü

Wollte mir mal ECT anschauen ... jedoch verstehe ich es absolut nicht =(

ECT funktioniert doch folgendermaßen:

Über CAPI sind Teilnehmer A und B miteinander am telefonieren.
Teilnehmer A setzt Teilnehmer B in Hold.
A Ruft Teilnehmer C an.

soweit ich das jetzt mitbekommen habe, ist es nicht möglich mit C zu sprächen.
B wird direkt mit C verbunden und A hängt sich aus der Verbindung raus.

Mein Problem beginnt schon bei Hold... laut dem README kann man mit

exten => s,1,capicommand(hold)

eine CAPI-Verbindung in Hold schicken. Wie kann ich den wehrend des Gespräches diese Extension wählen?

sorry falls ich ziemlich verwirrt rüber komme... aber das bin ich momentan auch =(

bis denne und einen schönen 1.Mai
T33baum

[EDIT1]

oh verdammte Axt... die Magie liegt wohl in der lustigen s Parameter... d.h. jedoch ... der A Teilnehmer muss auflegen bevor ECT beginnen kann ... na ja bin jetzt zu müde um das jetzt zu testen, machts gut =D


[EDIT2]

Ok habs heute mal getestet.
Ist ja doch nicht das "s" ....

habs jetzt vorerst mal so gemacht:
Code:
[isdn-in]
exten => 3,1,Wait(1)
exten => 3,n,Playback(auth-thankyou)
exten => 3,n,capicommand(hold)
exten => 3,n,Wait(1)
exten => 3,n,Dial(CAPI/DIVA1/<ziel>,40,M(capiect))

[macro-capiect]
exten => s,1,capicommand(ect)
(Sprechen mit den Teilnehmern ist somit nicht drin)

Es verbindet auch bis zum <ziel>, nur kommt wenn am Ziel der Hörer abgenommen wird dieser
lustige fehler:
Code:
[May  1 11:50:01] WARNING[18052]: chan_capi.c:3664 show_capi_conf_error: DIVA1#02: conf_error 0x300e PLCI=0x201 Command=FACILITY_CONF,0x8497
       > DIVA1#02: CAPI INFO 0x300e: TEI assignment failed or supplementary service not supported

Der geparkte Teilnehmer bleibt im Hold und am Ziel ist nichts zu hören =(

liegt da das Problem nun an mir (mit cpiinfo wird ECT angezeigt)
oder an der TK-Anlage an der ich mit der Asterisk hänge?
 
Zuletzt bearbeitet:
Moin
habe eine Eicon Diva Server 2FX, und versuche die Treiber zu installieren. Habe die Kernel Sources runtergeladen und versuche nun zu installieren. Dabei passiert folgender Fehler:

Code:
[root@asterisk2 divas4linux-melware-3.0.10-107.884-1]# make

Searching for configured kernel in /usr/src/linux
Kernel version is 2.6.24

Do you want to use the Diva optimized CAPI interface?
 Note: if you say 'y' here, the common kernelcapi is not used
 and therefore other CAPI cards than Diva are not usable.
 If you use Diva cards only, you can say 'y'.
Your selection (y/n)[y]: y
Yes, using optimized Diva CAPI.
Building divas4linux kernel modules...
Using kernel 2.6 build mechanism of /usr/src/linux...

make[1]: Entering directory `/usr/src/linux'
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/divasi.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/idifunc.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/um_idi.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/dqueue.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/divamnt.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/mntfunc.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/debug.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/maintidi.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/capimain.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/capifunc.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/message.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/capidtmf.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/manage.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/drv_man.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/capi_man.o
  CC [M]  /usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/diva_didd.o
/usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/diva_didd.c: In function `create_proc':
/usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/diva_didd.c:136: Fehler: »proc_net« nicht deklariert (erste Benutzung in dieser Funktion)
/usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/diva_didd.c:136: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt
/usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/diva_didd.c:136: Fehler: für jede Funktion in der er auftritt.)
/usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/diva_didd.c: In function `remove_proc':
/usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/diva_didd.c:476: Fehler: »proc_net« nicht deklariert (erste Benutzung in dieser Funktion)
make[2]: *** [/usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26/diva_didd.o] Fehler 1
make[1]: *** [_module_/usr/src/divas4linux-melware-3.0.10-107.884-1/kernel26] Fehler 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [kernel] Fehler 1
[root@asterisk2 divas4linux-melware-3.0.10-107.884-1]#
Kann mir damit jemand helfen???

MfG Nico
 
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.