Verbinden, Rückfrage oder makeln in der TK-Anlage

[petschgo]

Hallo,

hier geht es um die Frage, wie man von Asterisk aus innerhalb der TK-Anlage Vermitteln (Makeln) kann. Also einen Anruf von der TK-Anlage kommend auch wieder innerhalb der TK-Anlage verbinden kann. So wird die ISDN-Karte im Asterisk wieder frei.

Das gleicher Thema habe ich schon mal eingestellt, nur mit dem Unterschied, das es dabei um eine HFC-Karte (Cologne-Chipsatz) geht. Siehe hier: http://ting.ip-phone-forum.de/showthread.php?t=130976

Dies scheint sehr schwierig zu sein, daher habe ich es mal (erfolgreicher) mit der Capi probiert. Um das ganze zu vereinfachen habe ich ein spez. Telefon angelegt, welches nur den Anruf entgegen nimmt, einen kurzen Text spielt und anschließend die Teilnehmer miteinander verbindet. Der Anruf erfolgt auf MSN 31 und wird dann zum Teilnehmer der TK-Anlage 21 verbunden.

Hier der Teilnehmer:

exten => 31,1,Set(LANGUAGE()=de)
exten => 31/33,2,Set(CALLERID(name)=App 33)
exten => 31/34,2,Set(CALLERID(name)=App 34)
exten => 31/33,3,Set(CALLERID(number)=33)
exten => 31/34,3,Set(CALLERID(number)=34)
exten => 31,2,NoOp()
exten => 31,3,NoOp()
exten => 31,4,Set(LANGUAGE()=de)
exten => 31,5,Answer() ; Anruf annehmen
exten => 31,6,Background(demo-thanks) ; Text abspielen
exten => 31,7,capicommand(hold) ; Teilnehmer halten
exten => 31,8,Dial(CAPI/contr1/21,10,M(capiect)) ; Anwahl Tln 21 und verbinden ect
exten => 31,9,Hangup()

[macro-capiect]
exten => s,1,capicommand(ect) ; Macro um die Verbindung durchzuführen

Hier die Ausgabe im CLI

Connected to Asterisk 1.2.9.1-BRIstuffed-0.3.0-PRE-1r currently running on kserv
Verbosity was 0 and is now 5
== ISDN1: Incoming call '25' -> '31'
-- Executing Set("CAPI/ISDN1/31-0", "LANGUAGE()=de") in new stack
-- Executing NoOp("CAPI/ISDN1/31-0", "") in new stack
-- Executing NoOp("CAPI/ISDN1/31-0", "") in new stack
-- Executing Set("CAPI/ISDN1/31-0", "LANGUAGE()=de") in new stack
-- Executing Answer("CAPI/ISDN1/31-0", "4") in new stack
== ISDN1: Answering for 31
-- Executing BackGround("CAPI/ISDN1/31-0", "demo-thanks") in new stack
-- Playing 'demo-thanks' (language 'de')
-- Executing capiCommand("CAPI/ISDN1/31-0", "hold") in new stack
-- Executing Dial("CAPI/ISDN1/31-0", "CAPI/contr1/21|10|M(capiect)") in new stack
-- Called contr1/21
-- CAPI/ISDN1/21-1 is proceeding passing it to CAPI/ISDN1/31-0
-- CAPI/ISDN1/21-1 is ringing
-- CAPI/ISDN1/21-1 answered CAPI/ISDN1/31-0
-- Executing capiCommand("CAPI/ISDN1/21-1", "ect") in new stack
-- Attempting native bridge of CAPI/ISDN1/31-0 and CAPI/ISDN1/21-1
> CAPI INFO 0x3490: Normal call clearing
-- Attempting native bridge of CAPI/ISDN1/31-0 and CAPI/ISDN1/21-1
== ISDN1: CAPI Hangingup
== Spawn extension (incoming, 31, 8 ) exited non-zero on 'CAPI/ISDN1/31-0'
-- Executing Hangup("CAPI/ISDN1/31-0", "") in new stack
== Spawn extension (incoming, h, 1) exited non-zero on 'CAPI/ISDN1/31-0'
== ISDN1: CAPI Hangingup
kserv*CLI>

Grundsächlich hat alles funktioniert und die Verbindung kam innerhalb der TK-Anlage zustand (schwarzer Teil). Nur hängt jetzt irgendwie die Capi im Asterisk. Auch wenn die Ausgabe (dkl. rot) gut aussieht, ist kein weiterer Anruf mehr möglich. Erst nach dem zurücksetzen des Asterisk geht es wieder. Die Capi auf dem Server (Faxannahme mit Hylafax) funktioniert aber weiterhin. Jemand eine Idee wie man die Capi wieder frei kriegt?

MfG
Peter

 

[armincm]

Welche chan-capi Version benutzt du?
Welcher Karte, bzw. welcher Treiber?

Ein log mit
set verbose 5
capi debug
von dem gleichen Test waere hilfreich.

Armin

 

[petschgo]

Capi Debug

Habe genau den gleichen Vorgang mit Capi Debug erstellt. Weil der Log mächtig lang geworden ist, habe ich ihn nur angehängt.

Als Linux verwende ich Eisfair (www.eisfair.org) mit 2 ISDN-Karten. Einmal eine passive HFC-S (Cologne-Chip) mit der ein Verbindungsvorgang bisher nicht möglich war (Wer weiß wie?). Desweiteren Eine passive AVM Fritz-Karte (A1 3.11-02) mit der ich die Rückfrage durchführen möchte. Da bei dem Eisfair-Server alles automatisch installiert (avm_fritz_pci_2.4.26-1) wird kann ich keine Aussage zur chan-capi treffen. Wie kann ich das evtl. per Konsole herausfinden?

 

[armincm]

Wenn du im CLI
unload chan_capi.so
load chan-capi.so
machst, dann kannst Du die infos wie z.B. die Version sehen.

Im log ist zu sehen, dass die erste Verbindung ausgeloest wird, aber die zweite nicht. Eigentlich sollte das die Telefonanlage machen. Eventuell ist auch die ISDN Karte, bzw. der Treiber hier dran Schuld.
Was kommt denn bei 'show channels' ? Kannst du Kanaele im CLI stoppen?

Armin

 

[petschgo]

Hallo,

zuerst möchte ich mich mal für die professionelle Hilfe bedanken, gerade bei einem Thema welches für die meisten nicht so interessant ist.

Hier die Ausgabe von unload/load chan_capi.so. Die blau markierten sind sicherlich sehr interessant.

kserv*CLI> unload chan_capi.so
== Unregistered application 'capiCommand'
== Unregistered channel type 'CAPI'
kserv*CLI> load chan_capi.so
Loaded /usr/lib/asterisk/modules/chan_capi.so => (Common ISDN API for Asterisk)
== Parsing '/etc/asterisk/capi.conf': Found
== This box has 1 capi controller(s).
-- CAPI/contr1 supports DTMF
-- CAPI/contr1 supports supplementary services
> supplementary services : 0x000003ff
> HOLD/RETRIEVE
> TERMINAL PORTABILITY
> ECT
> 3PTY
> CF
> CD
> MCID
> CCBS
> MWI
> CCNR
== Reading config for ISDN1
-- capi_pvt ISDN1-pseudo-D (31,85,88,incoming,0,2) (0,4,64)
-- capi_pvt ISDN1 (31,85,88,incoming,0,2) (0,4,64)
-- capi_pvt ISDN1 (31,85,88,incoming,0,2) (0,4,64)
-- listening on contr1 CIPmask = 0x1fff03ff
== Registered channel type 'CAPI' (Common ISDN API Driver (cm-0.6.5))
== Registered application 'capiCommand'
kserv*CLI>

Ich habe daraufhin auch noch mal show channels ausprobiert. Der blaue Teil findet während des Rufes auf Telefon 21 statt. Der untere Teil kommt wenn ich nicht innerhalb 10 Sek. abhebe. Dann wird der Vorgang auch korrekt getrennt. Weitere Anrufe sind möglich.

-- Called contr1/21
-- CAPI/ISDN1/21-1 is proceeding passing it to CAPI/ISDN1/31-0
-- CAPI/ISDN1/21-1 is ringing
kserv*CLI> show channels
Channel Location State Application(Data)
CAPI/ISDN1/21-1 21@incoming:1 Dialing AppDial((Outgoing Line))
CAPI/ISDN1/31-0 31@incoming:8 Up Dial(CAPI/contr1/21|10|M(capie
2 active channels
1 active call
> CAPI INFO 0x3490: Normal call clearing
== ISDN1: CAPI Hangingup
== Spawn extension (incoming, 31, 8 ) exited non-zero on 'CAPI/ISDN1/31-0'
-- Executing Hangup("CAPI/ISDN1/31-0", "") in new stack
== Spawn extension (incoming, h, 1) exited non-zero on 'CAPI/ISDN1/31-0'
== ISDN1: CAPI Hangingup
kserv*CLI> show channels
Channel Location State Application(Data)
0 active channels
0 active calls
kserv*CLI

Hebe ich ab und die Verbindung kommt zustande dann gibt es folgende Ausgabe.

kserv*CLI> show channels
Channel Location State Application(Data)
0 active channels
0 active calls
kserv*CLI>

Die Kanäle sind "scheinbar" frei, aber erneute Anrufe sind nicht mehr möglich.

Die generelle Frage ist eigentlich, gehe ich richtig vor wenn ich innerhalb der TK-Anlage verbinden will? Oder geht das auch anders?

 

[armincm]

== Registered channel type 'CAPI' (Common ISDN API Driver (cm-0.6.5))

Diese Version ist schon aelter und du solltest updaten. Nach dieser 0.6.5 sind auch ECT fixes mit drin. Es koennte also daran liegen. Wenn es mit einer neuen Version nicht klappt, koennen wir nochmal genauer schauen.

Armin

 

[petschgo]

Ich denke da genauso. Ich werde erst mal die chan_capi updaten weil gerade für ECT einige fixes mit drin sind. Dies wird aber nicht so einfach sein weil bei dem Eisfair-Server die Asterisk Header (asterisk/include) nicht verfügbar sind. Weiß im Monment auch noch nicht wie ich das machen soll. Werde euch aber auf dem laufenden halten ...

 

[petschgo]

Update

Inzwischen habe ich auf einem Ubuntu-Server die aktuellsten Pakete von Asterisk sowie die chan_capi 1.0.0 aufgesetzt. Nach wie vor das gleiche Problem, außer das nach dem beenden der Gespräche die ISDN-Karte im Asterisk wieder frei war (beim "alt"-System mußte ich Asterisk neu starten). Keine wirkliche Verbesserung.

Möglicherweise ein Bug in der chan_capi? Siehe Forumsbeitrag (letzter Eintrag leider am 10.01.2006):

http://www.ip-phone-forum.de/showthread.php?t=81965

Demnach hat das ECT noch mit der chan_capi 0.3.5 funktioniert. Seitdem funktioniert nur noch HOLD und RETRIEVE, was ich durch meine eigenen Erfahrungen bestätigen kann.

Hat irgendjemand eine Idee?
Gibt es irgendjemand, bei dem ECT funktioniert? Bitte dann auch die relevanten Teile der extensions.conf posten.
Hat igendjemand schon mal was mit "MYHOLDVAR" ausprobiert?

ECT:
Explicit call transfer of the call on hold (must put call on hold first!)
Example:
exten => s,1,capicommand(ect|${MYHOLDVAR})
or
[macro-capiect]
exten => s,1,capicommand(ect)
[default]
exten => s,1,capicommand(hold)
exten => s,2,Wait(1)
exten => s,3,Dial(CAPI/contr1/1234,60,M(capiect))

MfG
Peter

 

[armincm]

Wenn es immer noch nicht funktioniert, mach doch bitte nochmal ein log mit
set verbose 5
capi debug
mit der neuen Version von chan-capi.

Armin

 

[petschgo]

Das LOG stammt vom Ubuntu-Server 6.06LTS mit Asterisk 1.4.2 und chan_capi 1.0.0 sowie chan_capi HEAD. Ich habe inzwischen sehr viel probiert. Mit passiver AVM-Karte sowie mit aktiver AVM C4 Karte. Ebenso die TK-Anlage AVAYA-Tenovis Integral3 und Integral5. Das Ergebnis war leider immer das selbe.

Korrektur zum Update: Auch hierbei hängt sich die chan_capi (1.0.0) nach dem ECT auf. Muß wohl bei dem vielen probieren was durcheinander gebracht haben.

Anschließend noch mal die Frage: Hat schon irgendjemand das mit dem ECT hinbekommen? HOLD und RETRIEVE funktionieren einwandfrei.

MfG
Peter

 

[armincm]

Bitte teste mal die SVN trunk version (rev 472). Falls es nicht klappt, bitte wieder ein log davon.

Armin

 

[petschgo]

Ist denn schon Weihnachten?

ICH BIN BEGEISTERT !!!

War das nun Zufall oder Absicht? :idea:

Mit der SVN trunk version (rev 473) hat ECT nun endlich funktioniert.

Dank an alle die sich Gedanken gemacht haben, besonders an armincm der sich diesem "fast" aussichtslosem Problem angenommen hat. Für mich gehen nun endlose Tage und Nächte des experimentierens vorbei. Nicht das ich dem nachtrauere.

Grüße Peter

 

[petschgo]

Verbinden nur mit 2 b-Kanälen möglich! Geht das nicht auch über einen b-Kanal?

Hallo,

habe mich mal wieder intensiver mit der Thematik beschäftigt. Vor schreiben dieses Artikels habe ich natürlich auch die Foren durchsucht. Mein Problem taucht dabei immer wieder auf, doch eine Lösung gibt es dafür wohl nicht, oder doch?
Grundsätzlich funktioniert alles so wie es soll. Nur mit der Einschränkung daß zum verbinden 2 b-Kanäle benötigt werden. So sieht das bisher aus:

=> Anruf in der TK-Anlage
=> Weiterleitung auf Asterisk (IVR)
=> Abspielen der Ansage
=> dann wieder zurück zur TK-Anlage

exten => 31,1,Set(LANGUAGE()=de)
exten => 31,2,Answer() ; Anruf annehmen (1 b-Kanal belegt)
exten => 31,3,Background(demo-thanks) ; Text abspielen (1 b-Kanal belegt)
exten => 31,4,capicommand(hold) ; Teilnehmer halten (Tatsächlich findet die Rückfrage in der TK-Anlage statt)
exten => 31,5,Dial(CAPI/contr1/21,20,M(capiect)) ; Anwahl Tln 21 und verbinden per ect (jetzt wird der 2. b-Kanal belegt und erst bei Annahme des Rufes durch den Teilnehmer 21 wird per ECT verbunden und beide Kanäle sind dann wieder frei.)
exten => 31,6,Hangup()

[macro-capiect]
exten => s,1,capicommand(ect) ; Macro um die Verbindung durchzuführen

Nun meine Frage:
Nach exten => 31,4,capicommand(hold) wird der Anrufer in der TK-Anlage gehalten. So soll es auch sein. Doch wie kann ich nun der TK-Anlage mitteilen wohin der Anrufer verbunden werden soll ohne einen 2. b-Kanal mit dem "DIAL" Befehl zu belegen? Denn wenn zwischenzeitlich der 2. b-Kanal belegt wurde, ist ein Verbinden unmöglich.
Irgend eine Idee?

Grüße
Peter

 

[armincm]

Das ist leider ein Problem wie die Kanäle in Asterisk organisiert sind. Meiner Meinung nach ist Asterisk hier sehr schlecht konzipiert, denn es wird fuer jede Verbindung ein (B-)Kanal vorausgesetzt.
Man koennte natuerlich irgendwie im Channel-Treiber (chan-capi) das ganze etwas umgehen und das ganze nicht B-Kanal basiert machen, aber hier gäbe es mit Asterisk an anderen Stellen Probleme.
Auch der Punkt, dass man innerhalb eines Dial() keine Kommandos (also während die B-Kanäle gebridged sind) im Dialplan ausführen kann, ist schlecht von Asterisk gemacht. Das sind eigentlich Basis-Dinge einer PBX.
Anyway, hier habe ich einfach keine gute Loesung.
Mit ein paar 'gemeinen' Workarounds in chan-capi könnte man aber ein paar Dinge erreichen.

Armin

 

[petschgo]

Hallo,

du schreibst:
"Mit ein paar 'gemeinen' Workarounds in chan-capi könnte man aber ein paar Dinge erreichen."
Ich denke mal das dies sicher eine aufwendige Sache ist, oder? Es wäre natürlich toll, wenn sich so etwas realisieren ließe. Siehst du da eine Chance?

Bis es aber möglicherweise eines Tages soweit ist, gäbe es da evtl. irgendwelche anderen "gemeinen" Tricks? Beispiel: Die meisten TK-Anlagen erzeugen einen Rückruf, wenn während eines gehaltenem Gespräches, einfach aufgelegt wird.

Also wenn bei einem in Rückfrage (HOLD) befindlichen Gespräch aufgelegt wird, meldet sich die TK-Anlage per Rückruf. Dieser Rückruf würde dann per (CD) an einem anderen Teilnehmer der TK-Anlage weitergeleitet werden. Ich habe diese Variante schon versucht, aber bisher leider ohne Erfolg. Vielleicht waren dafür meine Einträge in den extensions.conf noch nicht optimal oder es geht halt einfach nicht. Hat jemand vielleicht eine Idee?

Grüße
Peter

 

[armincm]

Ich denke mal das dies sicher eine aufwendige Sache ist, oder? Es wäre natürlich toll, wenn sich so etwas realisieren ließe. Siehst du da eine Chance?

So eine Umstellung dauert etwas und das kann ich nicht mal eben so nebenbei machen.

Also wenn bei einem in Rückfrage (HOLD) befindlichen Gespräch aufgelegt wird, meldet sich die TK-Anlage per Rückruf. Dieser Rückruf würde dann per (CD) an einem anderen Teilnehmer der TK-Anlage weitergeleitet werden. Ich habe diese Variante schon versucht, aber bisher leider ohne Erfolg. Vielleicht waren dafür meine Einträge in den extensions.conf noch nicht optimal oder es geht halt einfach nicht. Hat jemand vielleicht eine Idee?

Wie genau hast du denn das versucht? Eventuell macht die Anlage in diesem Fall keinen Rückruf!? Hast Du ein Log davon?

Armin

 

[petschgo]

Hallo,

das Problem scheint schon das Kommando capicommand(deflect|22) zu sein. Wenn ich folgendes versuche (s. u.), klappt schon die Umleitung nicht. Muß man evtl. noch irgendwo anders etwas eintragen, außer in der extensions.conf? In der capi.conf gibt es wohl eine Möglichkeit einen Eintrag ala deflect=12345 zu machen, der soll aber nur dann funktionieren wenn beide b-Kanäle belegt sind. Oder funktioniert capicommand(deflect|22) nur an ISDN-Hauptanschlüssen und gar nicht intern an einer TK-Anlage?

exten => 68,1,capicommand(deflect|22)
exten => 68,2,Hangup()

Mit dem obrigen Eintrag in der extensions.conf habe ich erst mal probiert ob deflect grundsätzlich an einem internen Anschluß einer TK-Anlage funktioniert. Scheint wohl nicht so. :-(

 

[m.goegel]

Die Wahrscheinlichkeit, dass eine Anlage CallDeflect am internen S0 unterstützt ist rel. gering, da Endgeräte dieses Feature im Normalfall nicht nutzen, sondern hauptsächlich TK-Anlagen.
Ausserdem dürfte das IMHO auch nur bei unbeantworteten Anrufen funktionieren, da das LM Rufabweisung mit neuer Zielnummer bedeuten soll.

Mario

 

[petschgo]

Ich befürchte, da hast du recht. Also muß ich warten bis vielleicht eines Tages die chan_capi geändert wird. Wie wäre es mit "capicommand(send)" ?

Beispiel:

exten => 31,1,Set(LANGUAGE()=de)
exten => 31,2,Answer() ; Anruf annehmen
exten => 31,3,Background(demo-thanks) ; Text abspielen
exten => 31,4,capicommand(hold|myholdvar) ; Teilnehmer halten
exten => 31,5,capicommand(send|${myholdvar|22) ; Kommando frei erfunden
exten => 31,6,Hangup()

Könnte das so etwa aussehen?
Klar, ich weiß. Der schwerste Teil folgt noch, nämlich die chan_capi anzupassen.

 

[m.goegel]

Ist prinzipiell machbar - ein Kommando hinzuzufügen ist simpel.
Ich habe das im QSIG Teil ja schon genau so eingebaut - Transfer per Dialplan oder auch automatisch beim bridgen.

Das einzige Problem ist an dieser Stelle nur das ISDN Hold, ich denke aber, Armin würde das schon hinbekommen...

Mario