[Frage] laufendes Gespräch übernehmen - ChannelRedirect()

[Subbaviper]

Hallo zusammen,

hänge über folgendem Problem und komme nicht weiter.

An einer DECT Basisstation sind DECT Headsets angeschlossen (haben nur einen Button ... annehmen oder auflegen).

Gespräche annehmen ist damit ja kein Problem, allerdings möchte ich die Gespräche auch wieder vom Headset auf einen anderen Apparat bekommen.

Ich habe ein bisschen gegoogelt und herausgefunden, dass es mal die Funktion Steal() gab in 1.4 (bristuff). Allerdings ist diese nicht mehr verfügbar.

Danach habe ich mir Channelredirect angeschaut bin allerdings auch nicht schlau daraus geworden.

Vom Prinzip her ist der Channel ja immer z. B. SIP/1818-Unique-ID ... wie bekomme ich denn diese Unique-ID heraus?

Ziel des ganzen ist es ein laufendes Gespräch von egal woher mit der Extension 1818 mit einer Tastenkombination an irgend einem Telefon übernehme, so dass das Gespräch von der 1818 weg ist.

Kann mir da jemand helfen?

Verwendet wird Asterisk 1.6.2.20.

Danke im Voraus,


Sebastian

PS: Die andere Alternative wäre, wenn mir jemand gute Headsets mit Kopfbügel Bluetooth empfehlen könnte. Dann wäre das auch erledigt.

 

[rentier-s]

Vom Prinzip her ist der Channel ja immer z. B. SIP/1818-Unique-ID ... wie bekomme ich denn diese Unique-ID heraus?

Ich hab das mal mit einem PHP AGI gemacht, das asterisk -rx 'core show channels' ausgewertet hat.
Vielleicht geht's auch eleganter :noidea:

 

[abw1oim]

Für die Ermittlung des Channels sollte folgendes auch mit 1.6 gehen:

exten => _X.,1,Dial(SIP/1818,,U(getchannel))

[getchannel]
exten => s,1,Set(DB(Channel/1818)=${CHANNEL})
exten => s,n,Return

[steel]
exten => 1818,1,Set(AChannel=${DB(Channel/1818)})
exten => 1818,n,ChannelRedirect(${AChannel},context,ext,priority)

Wenn 1818 gewählt wird, wird vor dem Bridge der Kontext getchannel ausgeführt, der seinerseits den CHANNEL in die DB schreibt (Variablen nützen nix, da der "Steel" ja nicht von einem Kindprozess kommt). Das kann man dann - hier angedeutet - in einem "Steel"-Kontext auslesen. Voraussetzung ist allerdings, dass 1818 nur ein Gespräch (einen Channel) parallel annimmt, sonst würde die DB-Variable überschrieben ...
Einfach mal ausprobieren.

 

[rentier-s]

Das geht aber nur, wenn die Nebenstelle immer direkt über ein Dial gerufen wird. Local-Channels, Call-File, Originate oder SIP 302 fallen da durch's Raster.

 

[abw1oim]

Jein, Du kannst eine ähnliche Technik bei Local-Channels anwenden, dto. bei Call-Files (via Local-Channel), bei Originate theor. auch via Local-Channel. Zugegebenermaßeen muß dann dort aber noch ein wenig Aufwand getrieben werden, aber letztlich braucht man ja den Channel, auf den der interessierende peer hört (hier: SIP/1818) und den bekommt man immer in dem Dial, das ihn anspricht. Bei Groupcalls müsste man natürlich noch prüfen, ob der zu bridgende Channel dem gewünschten CHANNEL(peername) entspricht, da andernfalls ein Steel von SIP/1818 nicht gewünscht wäre ...

 

[Subbaviper]

ich habe jetzt ein wenig rumprobiert .... meine schwierigkeit ist noch, da ich gemeinschaft verwende, dass ich das in einer ael eintragen muss.

Es klappt jedoch nicht. Jedesmal wenn ich das versuche kommt ein anklopfanruf auf der nebenstelle 1818 ....


aber was ich so weit verstanden habe ist:


sobald ein anruf auf die nebenstelle 1818 erfolgt muss der channel in die db variable geschrieben werden und dann kann ich mit einer tastenkombination redirectchannel aufruden und da die variable aus der db auslesen

ist das so richtig?

 

[abw1oim]

So ist zumindest meine Idee ...

 

[Subbaviper]

okay gut ... nachdem ich nicht so viel ahnung habe wo ich das in der gemeischaft dann genau eintragen muss, frag ich nochmal in der gemeinschaft group

herzlichen dank ....

 

[rentier-s]

Ich würde sagen, in der /opt/gemeinschaft/etc/asterisk/e-internal.ael im [to-internal-users-self], dort findest Du das Dial im Label to-user.

Den Rest kannst Du in die /etc/gemeinschaft/asterisk/extensions-to-internal-custom.ael packen.

Danach musst Du im GUI über Dialplan Reload den Dialplan neu erstellen lassen.

 

[Subbaviper]

Ich habe es jetzt gerade nochmal versucht ... blicks aber leider nicht ... da sind zu viele variablen

 

[eibo]

Etwas anders habe ich es gelöst, aber unter anderem mit Hinweisen, die ich in diesem Thread bekommen habe. Im Beispiel ist 54321 die Telefonnummer, 21 die Nummer des SIP-Telefons und 192.168.100.121 dessen IP-Adresse. Aktuell arbeite ich mit Asterisk 1.6.2.9 auf einem Debian Squeeze Rechner, früher habe ich auf ähnliche Weise das gleiche Problem mit Steal2 von Thorsten Knabe gelöst.

extensions.conf

[incoming]
exten => 54321,1,Dial(SIP/[email protected],15,t)
exten => 54321,2,Set(GLOBAL(AB)=21)
exten => 54321,3,Set(GLOBAL(ABC)=${CHANNEL})
exten => 54321,4,VoiceMail(21)
...
exten => h,1,Set(GLOBAL(AB)=)
exten => h,2,Hangup

[outgoing]
exten => 0,1,GotoIF(${LEN(${AB})} > 0 ?10))
exten => 0,2,VoiceMailMain(${CALLERID(num)},s)
exten => 0,3,Hangup
exten => 0,10,Bridge(${ABC},x)
exten => 0,11,Hangup
...

Ein Anruf versucht es zuerst 15 Sekunden auf dem Telefon, setzt dann die globale Variable ${ABC} mit der aktuellen Channel-ID (die Variable ${AB} soll bei mir später die verschiedenen Telefone unterscheiden könnnen) und stellt eine Verbindung zum Anrufbeantworter her. Wählt man nun, nachdem ein Anrufer auf dem Anrufbeantworter gelandet ist, eine 0, wird in outgoing geprüft, ob ein Anrufer auf den Anrufbeantworter geschickt wurde (${AB} ist in diesem Fall nicht leer), falls nicht, landet man ganz normal in VoiceMailMain zum Abrufen der aufgesprochenen Nachrichten, falls doch wird mit dem Bridge-Kommando das Gespräch von VoiceMail weggeholt. Immer nach dem Auflegen wird die Variable ${AB} zurückgesetzt, also auch dann, wenn sie garnicht gesetzt war, aber so ist es einfacher.

Das ist natürlich alles noch nicht wirklich gut, was mache ich z.B. bei zwei überlappenden Anrufen, aber das Kernproblem ist gelöst.