[Gelöst] overlap receiving für beliebige Rufnummern

[sunnyman]

Hallo Forum,

ich nutze eine DIVA 4BRI in einem Asterisk, um den Amtskopf für eine Octopus E300 zu machen. Die Karte läuft im NT-Modus und es muss nun folgendes geleistet werden:
abhängig von der CALLERID soll ein bestimmtes SIP-Konto zum Rauswählen genutzt werden.

Ich hatte dazu ein "catch-all" mit einer Fallunterscheidung nach diesem Schema eingerichtet:

exten => _X.,1,Verbose(Ruf aus der E300 von ${CALLERID(num)} nach ${EXTEN})
 same => n,Ringing()
 same => n,GotoIf($["${CALLERID(num)}"="${RUMPF}217"]?amt_1125789)

Das funktioniert natürlich nur mit Blockwahl gut. Wählt man aus der E300 per overlap (also analoger Tln. oder Wahl aus Rückfrage), schnappt sich Asterisk die ersten 1 bis 3 Ziffern und wertet sie aus.

Ich habe es anschließend nun probiert mit einem WaitExten:

exten => _X.,1,Verbose(Ruf aus der E300 von ${CALLERID(num)} nach ${EXTEN})
 same => n,WaitExten(2)
 same => n,Ringing()
 same => n,GotoIf($["${CALLERID(num)}"="${RUMPF}217"]?amt_1125789)

Das hat den merkwürdigen Effekt, dass Asterisk zwar wartet, aber die z. B. zwei Ziffern, die schon gewählt waren, verschluckt und diese nicht mehr Teil von ${EXTEN} sind.

Dann habe ich in der capi.conf immediate=yes gesetzt und probehalber einfach nur folgende Extension gebaut:

exten =>s,1,WaitExten(10)
  same => n,Verbose(${EXTEN})

Ergebnis: die Extension wird auch angelaufen, aber der Timeout wird abgebrochen sobald die erste Ziffer gewählt wird:

  == ISDN1#02: Incoming call '0309234' -> ''
    -- Executing [s@bri_e300:1] NoOp("CAPI/ISDN1#02/-a", "") in new stack
    -- Executing [s@bri_e300:2] WaitExten("CAPI/ISDN1#02/-a", "15") in new stack
    -- ISDN1#02: Updated channel name: CAPI/ISDN1#02/1-b
[Feb 12 20:50:41] WARNING[26327]: pbx.c:5413 __ast_pbx_run: Invalid extension '1', but no rule 'i' or 'e' in context 'bri_e300'
  == ISDN1#02: CAPI Hangingup for PLCI=0x201 in state 7
       > ISDN1#02: CAPI INFO 0x3490: Normal call clearing

Was mache ich falsch? Ich verstehe nicht, warum bei der letzten Version das WaitExten einfach abgebrochen wird.

 

[abw1oim]

Probiere mal folgendes (capi.conf immediate=no)

exten => _X!,1,Verbose(Ruf aus der E300 von ${CALLERID(num)} nach ${EXTEN})
 same => n,Ringing()
 same => n,GotoIf($["${CALLERID(num)}"="${RUMPF}217"]?amt_1125789)

Nach meinem Kenntnisstand sollte das Pattern _X! dafür sorgen, dass Asterisk nach der ersten emfangenen Ziffer in den Overlapmodus schaltet und dann auch die komplette Rufnummer durchkommen sollte.

 

[sunnyman]

So, hat nun ein paar Tage gedauert bis ich mich endlich mal wieder mit beschäftigen konnte.

So wie von dir vorgeschlagen klappt es leider nicht.
Asterisk nimmt nur die erste Ziffer entgegen und die Rufbehandlung schlägt direkt durch, sprich es wird einfach nur die erste Ziffer an das Dial übergeben.

 

[rentier-s]

Blöde Frage, aber wie hast Du das Overlapdialing bis jetzt umgesetzt? Es geht doch hier "nur" darum, Callerid-abhängig ein bestimmtes abgehendes Peer zu verwenden. :gruebel:

Ich verwende den Ansatz mit WaitExten für ein selbst gebasteltes Callback. Dabei wird EXTEN zwar überschrieben, man kann die vorher bereits gewählten Ziffern aber ganz einfach zuvor in einer Variable speichern, nachher wieder davor setzen und mit Goto in die gewünschte Rufbehandlung springen.

 

[sunnyman]

Blöde Frage, aber wie hast Du das Overlapdialing bis jetzt umgesetzt?

Eben nicht, das ist das Problem
Im Moment funktioniert nur Blockwahl. Das funktioniert soweit auch, aber man kann so eben kein Faxgerät betreiben oder in Rückfrage Gespräche mit Rufnummern aufbauen die nicht im Telefonbuch stehen (da kann die E300 nur Overlap).

Es geht doch hier "nur" darum, Callerid-abhängig ein bestimmtes abgehendes Peer zu verwenden. :gruebel:

Exakt. Ich habe noch an anderer Stelle einen Asterisk in Betrieb, wo für diese Aufgabe eine ISDN-Karte mit DAHDI-Treibern eingesetzt wird. Da funktioniert das tadellos und ohne dass ich jemals irgendwas hätte konfigurieren müssen.

Ich verwende den Ansatz mit WaitExten für ein selbst gebasteltes Callback. Dabei wird EXTEN zwar überschrieben, man kann die vorher bereits gewählten Ziffern aber ganz einfach zuvor in einer Variable speichern, nachher wieder davor setzen und mit Goto in die gewünschte Rufbehandlung springen.

Uff, das klingt nach ziemlichen Gebastel. Kann man aber zur Not auch noch mal probieren.

 

[rentier-s]

OK, dann geht es also jetzt erst mal um das Overlapdialing.

Ich hab mir im Hinblick darauf den ersten Beitrag grad noch mal genau durchgeschaut, bei Verwendung von immediate=yes hattest Du wohl aus [bri_e300] alles rausgelöscht außer der s-extension?

[Feb 12 20:50:41] WARNING[26327]: pbx.c:5413 __ast_pbx_run: Invalid extension '1', ...

Du brauchst neben s auch noch ein gültiges Ziel für WaitExten, also zB. eine exten=>_X.,1,irgenwas

So ein fürchterliches Gebastel find ich ein Set und ein Goto eigentlich nicht, da hab ich schon schlimmeres gemacht ;-)

@abw1oim, das _X! ist soweit ich das verstanden habe eine Abkürzung für _X. und _X
Also sozusagen ein numerisches _. mit best-match Garantie.
Ich glaube, wir haben darüber schon mal diskutiert, weiß aber nicht mehr wann und auch nicht mehr, was raus gekommen ist :noidea:

 

[abw1oim]

@abw1oim ...

Da täuscht Deine Erinnerung:

_X. -> Ein numerisches Zeichen (0-9) mit mindestens einem weiteren Zeichen (beliebig)

_X -> Genau ein numerisches Zeichen (0-9)

_X! -> Ein numerisches Zeichen (0-9) weitere beliebige Zeichen sind möglich

_. -> mindestens ein beliebiges Zeichen -> Das ist das "verbotene" Pattern, da es auch die "Sonderextensions" wie s,h,t etc. "fängt"

Hinsichtlich des Overlapdialings (mit immediate=no) funktioniert bei mir immer _X! erfolgreich, aber: der Weg mit immediate=yes, s-Exten und entsprechendem WaitExten (zu einem vorhandenen Pattern wie _X.) geht natürlich auch ...

 

[rentier-s]

Ja, genau so verstehe ich das ! auch. Heißt, es kann, muss aber nicht eine weitere Ziffer folgen. Also greift _X! sowohl bei einer, als auch bei mehreren Ziffern. Das Verhalten erreicht man sonst nur mit _X. plus _X
Außerdem wird das Pattern durch das ! bevorzugt, das habe ich aber noch nicht wirklich kapiert inwieweit das best-match dadurch beeinflusst wird.

Im Zusammenhang mit Overlap wird desöfteren _X! erwähnt (auch im Asterisk Buch), aber eigentlich immer in Kombination mit address incomplete seitens Peer bzw. entsprechende Call Setup Rückmeldungen über den ISDN Treiber. :noidea:

Hast Du eine Umgebung im Kopf (Anbindung, Channel-Treiber, ...), bei der das allein mit _X! funktioniert?

 

[sunnyman]

Also um nochmal zum ursprünglichen Problem zurückzukommen: ich sehe den Tipp von rentier-s, die obige Variante zu benutzen bei der konstant 2 Ziffern geschluckt werden. Diese dann vorher in einer Variable speichern und später dazuschreiben.
Sonst noch konkrete Vorschläge?

 

[abw1oim]

@rentier-s: Ich hatte mich getäuscht und jetzt selbst noch mal nachgeschaut, wie ich es genau gelöst habe.

capi.conf: immediate=yes

extensions.conf

exten => s,1,Verbose(Overlap-Ruf aus der E300 von ${CALLERID(num)} nach ${EXTEN})
 same => n,Set(TIMEOUT(digit)=2)
 same => n,WaitExten(10)
					
exten => _X.,1,Verbose(Ruf aus der E300 von ${CALLERID(num)} nach ${EXTEN})
 same => n,Ringing()
 same => n,GotoIf($["${CALLERID(num)}"="${RUMPF}217"]?amt_1125789)

So müsste es gehen.
Zur Erklärung: Im Blockwahlmodus wird direkt _X. angesprungen, da ist ja die Rufnummer bereits komplett. Im Overlapmodus wird s angesprungen und es gibt 2 sec je Ziffer und 10 sec insgesamt. Damit klappt bei mir sowohl Blockwahl als auch Overlap. Ist die Nummer komplett, wird auch hier _X. angesprungen.
Probier mal, ob das hilft.

 

[sunnyman]

Ich hatte nun die Gelegenheit, es zu testen. Es funktioniert wohl, und zwar genau so wie abw1oim zuletzt vorgeschlagen hat.
Die Lösung ist so sauber und simpel, ich frage mich, warum ich da damals nicht drauf gekommen bin Vielen Dank!

 

[rentier-s]

Wenn Du magst, verrate uns doch bitte noch, wie Du es gelöst hast.

In jedem Fall könntest Du dann das Titel-Prefix auf "gelöst" ändern, dazu den 1. Beitrag bearbeiten -> Erweitert.

 

[sunnyman]

Wenn Du magst, verrate uns doch bitte noch, wie Du es gelöst hast.

Wie ich bereits schrieb: genauso wie abw1oim in Beitrag #10 vorgeschlagen hat.