[GELÖST] TK Austria, PTP, DID & WaitExten klappt nicht

[ahaumer]

Frohe Weihnachten!

Ich habe ein Asterisk-1.4.10.1 unter Linux mit 2 Eicon Diva Server Karten mit chan_capi-1.0.1 an 2x ISDN Anschlüssen im PTP Modus konfiguriert. Intern habe ich mehrere Linksys SIP Telefone, Hylafax an IAXmodem und noch eine zusätzliche Eicon Diva Server ISDN Karte im NT Modus für einen internen S0 Bus.

Es funktioniert fast alles, leider habe ich aber nach wie vor keine Lösung für das hierorts bereits mehrfach angesprochene, österreichspezifische Problem mit Direkt-Durchwahl von Geräten, die keine Blockwahl beherrschen, gefunden.

An den beiden ISDN Karten, die an jeweils einem ISDN BA im PTP Modus hängen, habe ich chan_capi mit folgenden Einstellungen konfiguriert:

ntmode=no
isdnmode=did
incomingmsn=*
immediate=yes
controller=2
group=1
context=extern
echocancel=yes
devices=2

Der Dialplan in extensions.conf sieht im Wesentlichen so aus (reduziert um Funktionen für den internen S0 Bus und die Faxanbindung):

[general]
static=yes
writeprotect=no

[default]
include => intern
include => extern
include => capi-out

; Macro zur Anwahl eines SIP Telefons
[macro-siphone]
exten => s,1,Dial(SIP/${ARG1},45)
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s-NOANSWER,1,VoiceMail(${ARG1},u)
exten => s-BUSY,1,VoiceMail(${ARG1},b)
exten => s-ANSWER,1,Hangup()
exten => _s-.,1,Goto(s-NOANSWER,1)

[sipphones]
exten => 10,1,Macro(siphone,${EXTEN})
exten => 11,1,Macro(siphone,${EXTEN})
exten => 12,1,Macro(siphone,${EXTEN})
exten => 30,1,Macro(siphone,${EXTEN})
exten => 31,1,Macro(siphone,${EXTEN})
exten => 40,1,Macro(siphone,${EXTEN})
exten => 41,1,Macro(siphone,${EXTEN})
exten => 42,1,Macro(siphone,${EXTEN})
exten => 60,1,Macro(siphone,${EXTEN})
exten => 61,1,Macro(siphone,${EXTEN})
exten => 62,1,Macro(siphone,${EXTEN})

[intern]
include => sipphones

[extern]
exten => s,1,Set(TIMEOUT(digit)=5)
exten => s,n,WaitExten(5)
exten => s,n,Macro(siphone,12)

exten => 0,1,Macro(siphone,12)
include => sipphones

[capi-out]
exten => _0X.,1,Set(RUFNUMMER=${EXTEN:1})
exten => _0X.,n,Dial(CAPI/g1/${RUFNUMMER}|45|r)


Die beiden ISDN-Karten am öffentlichen ISDN Netz arbeiten wie in capi.conf ersichtlich im Kontext "extern".

Mein Ziel ist: Anrufe von außen an die Hauptnummer inklusive Durchwahl sollen direkt an die passende Nebenstelle durchgestellt werden, Anrufe ohne Durchwahl oder mit der Kurzdurchwahl "-0" sollen an die Nebenstelle mit der Nummer 12 gehen.

Das klappt, wenn ich von einem Mobiltelefon aus anrufe (das beherrscht Blockwahl), aber nicht von einem Gerät, das Blockwahl
nicht beherrscht.

Im Fehlerfall sieht die Debug-Info von Asterisk so aus (Beispiel mit Ruf auf die Kopfnummer + Durchwahl "60"):

    -- CONNECT_IND (PLCI=0x102,DID=,CID=nnnn7449,CIP=0x10,CONTROLLER=0x2)
  == ISDN2#02: setting format alaw - 0x8 (alaw)
  == ISDN2#02: Incoming call '0nnnn7449' -> ''
    -- ISDN2#02: info element CHANNEL IDENTIFICATION 89
    -- ISDN2#02: info element SETUP
    -- ISDN2#02: CAPI/ISDN2#02/-7: s matches in context extern for immediate
    -- ISDN2#02: CAPI/ISDN2#02/-7: s matches in context extern
       > CAPI devicestate requested for ISDN2#02/
    -- Executing [s@extern:1] Set("CAPI/ISDN2#02/-7", "TIMEOUT(digit)=5") in new stack
    -- Digit timeout set to 5
    -- Executing [s@extern:2] WaitExten("CAPI/ISDN2#02/-7", "5") in new stack
  == Started pbx on channel CAPI/ISDN2#02/-7
    -- ISDN2#02: info element CALLED PARTY NUMBER
    -- ISDN2#02: Updated channel name: CAPI/ISDN2#02/60-8
    -- CAPI queue frame: [ TYPE: DTMF End (1) SUBCLASS: 6 (54) ] [ISDN2#02]
    -- CAPI queue frame: [ TYPE: DTMF End (1) SUBCLASS: 0 (48) ] [ISDN2#02]
    -- ISDN2#02: info element INFORMATION
    -- Timeout on CAPI/ISDN2#02/60-8, continuing...
    -- Executing [s@extern:3] Macro("CAPI/ISDN2#02/60-8", "siphone|12") in new stack
    -- Executing [s@macro-siphone:1] Dial("CAPI/ISDN2#02/60-8", "SIP/12|45") in new stack
    -- Called 12

Wie man sieht, geht Asterisk auf die "s" Extension (das ist zu erwarten, ich habe "immediate=yes" in der capi.conf und die DID Information ist leer). Dann wird die "WaitExten" Funktion ausgeführt und die beiden Nummern für die Durchwahl werden anscheinend auch tatsächlich empfangen (zuerst "6" und dann "0")

Aber WaitExten läuft dann in den Timeout und es wird trotzdem wieder die Durchwahl "12" angerufen und nicht die 60!

Eventuell habe ich noch nicht begriffen, wie das "WaitExten" eigentlich funktioniert: woher weiß diese Funktion, wann die Durchwahl-Nummer vollständig ist und was macht es dann mit dieser Nummer? Wie formuliere ich den Dialplan, damit ich dann genau die mit "WaitExten" empfangenen Ziffern auslesen und z.B. in einem Makro wählen kann?

Im Forum gibt es einige Beispiele dazu, aber die scheinen mir alle irgendwie unvollständig zu sein.

Z.B. im Beitrag http://www.ip-phone-forum.de/showthread.php?t=133837

Dort wird als "Lösung" für das Problem folgende Konfiguration empfohlen:

exten = s,1,Set(TIMEOUT(digit)=5)
exten = s,2,WaitExten(10)
exten = s,3,Macro(dial-zentrale)

Das Makro "dial-zentrale" ist leider nicht spezifiziert. Was soll das Makro machen? Wann wird das aufgerufen? Wird es nur aufgerufen, wenn WaitExten keine Durchwahl empfängt oder wird es umgekehrt mit der neuen Durchwahl, die von WaitExten empfangen wurde, aufgerufen. Woher weiß das Makro dann aber, welche Durchwahl-Nummer empfangen wurde? Steht die in einer (mir unbekannten) Asterisk Variablen?

Ich bastle an dem Problem schon seit mehreren Tagen, bisher aber ohne Erfolg. Ich denke, ich habe alle Foren-Beiträge, Mailing-Listen, HOWTO's, Webseiten, Wiki, usw. zu diesem Thema bereits durchgelesen, die richtige Lösung war leider noch nicht dabei (oder ich habe sie nicht erkannt)

Wenn ich in capi.conf "immediate=no" setze, klappt die direkte Durchwahl auf Nebenstellen auch von Geräten ohne Blockwahl, allerdings funktioniert dann die Anwahl der Kopfnummer nicht mehr korrekt: Der Anrufer hört eine Zeit lang nichts, dann wird die Verbindung terminiert. Das ist also auch keine Lösung.

Hat irgendjemand eine Idee, wo der Fehler liegen könnte?

 

[ahaumer]

Weitere Infos

Nach mehreren Stunden des Probierens und Debuggens bin ich leider immer noch nicht schlauer. Ein paar zusätzliche Infos gibt es aber doch...

Zuerst habe ich chan_capi auf Version 1.0.2 aktualisiert. Das hat aber keine Änderung des Verhaltens gebracht.

Zusätzlich habe ich meinen Dialplan erweitert, um ein paar zusätzliche Debug-Infos zu erhalten:

; Ein Test-Macro
[macro-didtest]
exten => s,1,NoOp(MACRO_EXTEN : ${MACRO_EXTEN})
exten => s,2,NoOp(MACRO_CONTEXT : ${MACRO_CONTEXT})
exten => s,3,NoOp(MACRO_PRIORITY : ${MACRO_PRIORITY})
exten => s,4,NoOp(CALLERID : ${CALLERID})
exten => s,5,Macro(siphone,12)                  ; -> Zentrale

[extern]
exten => s,1,Set(TIMEOUT(digit)=5)
exten => s,2,WaitExten(5)                          ; Warte 5 Sekunden auf eine Durchwahl
exten => s,3,Macro(didtest)                        ; Wann wird das aufgerufen?

exten => t,1,Macro(siphone,12)                  ; immer noch keine Nummer -> Zentrale

exten => 0,1,Macro(siphone,12)                  ; Durchwahl 0 -> Zentrale
include => sipphones                            ; unsere SIP Telephone
exten => 58,1,Macro(s0intern,${EXTEN})          ; Durchwahl zum ISDN Router
exten => 71,1,Goto(fax-in,71,1)                 ; Durchwahl zum Fax

Bei einem Anruf von einem Gerät ohne Blockwahl auf die Durchwahl 60 passiert nun folgendes (meine Interpretation der Debug-Ausgaben):

1.) Der Ruf geht beim chan_capi ein, DID ist aber leer:

    -- CONNECT_IND (PLCI=0x102,DID=,CID=nnnn7449,CIP=0x10,CONTROLLER=0x2)
  == ISDN2#02: setting format alaw - 0x8 (alaw)
  == ISDN2#02: Incoming call '0nnnn7449' -> ''
    -- ISDN2#02: info element CHANNEL IDENTIFICATION 89
    -- ISDN2#02: info element SETUP

2.) Weil "immediate=yes" gesetzt ist, wird im Kontext "extern" die Extension "s" angesprungen:

    -- ISDN2#02: CAPI/ISDN2#02/-3c: s matches in context extern for immediate
    -- ISDN2#02: CAPI/ISDN2#02/-3c: s matches in context extern
       > CAPI devicestate requested for ISDN2#02/

3.) Die Priorität "1" der Extension "s" im Kontext "extern" wird exekutiert:

    -- Executing [s@extern:1] Set("CAPI/ISDN2#02/-3c", "TIMEOUT(digit)=5") in new stack
    -- Digit timeout set to 5

4.) Die Priorität "2" der Extension "s" im Kontext "extern" wird exekutiert:

    -- Executing [s@extern:2] WaitExten("CAPI/ISDN2#02/-3c", "5") in new stack

5.) chan_capi empfängt die beiden Ziffern der gewählten Durchwahl:

  == Started pbx on channel CAPI/ISDN2#02/-3c
    -- ISDN2#02: info element CALLED PARTY NUMBER
    -- ISDN2#02: Updated channel name: CAPI/ISDN2#02/K60-3d
    -- CAPI queue frame: [ TYPE: DTMF End (1) SUBCLASS: 6 (54) ] [ISDN2#02]
    -- CAPI queue frame: [ TYPE: DTMF End (1) SUBCLASS: 0 (48) ] [ISDN2#02]
    -- ISDN2#02: info element INFORMATION

Man beachte, wie der "channel name" mit der richtigen Durchwahl aktualisiert wird!

6.) WaitExten läuft in den voreingestellten Timeout von 5 Sekunden:

    -- Timeout on CAPI/ISDN2#02/K60-3d, continuing...

7.) Obwohl die beiden Ziffern der Durchwahl ("6" und "0") empfangen wurden, scheinen diese nicht bei WaitExten (oder wo auch immer in Asterisk) angekommen zu sein. Jedenfalls wird das "didtest" Makro (Priorität "3" der Extension "s" im Kontext "extern") exekutiert, ohne dass hier die neue Duchwahl bekannt wäre:

    -- Executing [s@extern:3] Macro("CAPI/ISDN2#02/K60-3d", "didtest") in new stack
    -- Executing [s@macro-didtest:1] NoOp("CAPI/ISDN2#02/K60-3d", "MACRO_EXTEN : s") in new stack
    -- Executing [s@macro-didtest:2] NoOp("CAPI/ISDN2#02/K60-3d", "MACRO_CONTEXT : extern") in new stack
    -- Executing [s@macro-didtest:3] NoOp("CAPI/ISDN2#02/K60-3d", "MACRO_PRIORITY : 3") in new stack
    -- Executing [s@macro-didtest:4] NoOp("CAPI/ISDN2#02/K60-3d", "CALLERID : ") in new stack

8.) Als Fallback wird im "didtest" Makro der Ruf an die Zentrale durchgestellt, damit der Anruf wenigstens nicht verloren geht:

    -- Executing [s@macro-didtest:5] Macro("CAPI/ISDN2#02/K60-3d", "siphone|12") in new stack
    -- Executing [s@macro-siphone:1] Dial("CAPI/ISDN2#02/K60-3d", "SIP/12|45") in new stack
    -- Called 12

Dieser "Fallback" ist aber natürlich nicht das, was ich eigentlich erreichen will.

Wo aber liegt das Problem?
Ist meine Vermutung korrekt, dass die Durchwahl zwar empfangen wird, Asterisk diese aber nicht als neu zu wählende Extension interpretiert? Falls ja, warum ist das so und wie kann ich das ändern?

Falls nein: wo liegt mein Denkfehler? Wie funktioniert dieses "WaitExten"?

Da anscheinend andere Asterisk Anwender dieses Problem bereits gelöst haben, wäre es nett, wenn mir jemand seine Erkenntnisse dazu mitteilen könnte. Die Debugging-Ausgaben bei einem funktionierenden Call von einem Gerät ohne Blockwahl wären interessant!

Ein Anruf von einem Gerät mit Blockwahl (Mobiltelefon) sieht mit dem o.a. Dialplan in den Debugging-Ausgaben jedenfalls so aus:

    -- CONNECT_IND (PLCI=0x102,DID=60,CID=664nnnnnnn,CIP=0x1,CONTROLLER=0x2)
  == ISDN2#02: setting format alaw - 0x8 (alaw)
  == ISDN2#02: Incoming call '0664nnnnnnn' -> '60'
    -- ISDN2#02: info element CALLED PARTY NUMBER
    -- ISDN2#02: Updated channel name: CAPI/ISDN2#02/60-5a
    -- ISDN2#02: CAPI/ISDN2#02/60-5a: 60 matches in context extern
       > CAPI devicestate requested for ISDN2#02/60
    -- Executing [60@extern:1] Macro("CAPI/ISDN2#02/60-5a", "siphone|60") in new stack
    -- Executing [s@macro-siphone:1] Dial("CAPI/ISDN2#02/60-5a", "SIP/60|45") in new stack
    -- Called 60
  == Started pbx on channel CAPI/ISDN2#02/60-5a
    -- ISDN2#02: info element Sending Complete
  == ISDN2#02: pbx already started on channel CAPI/ISDN2#02/60-5a
    -- ISDN2#02: info element CHANNEL IDENTIFICATION 89
    -- ISDN2#02: info element SETUP
       > ISDN2#02: IE SETUP / SENDING-COMPLETE already received.
    -- SIP/60-08238248 is ringing

Aber leider gibt es da draußen noch eine Unmenge an Geräten ohne Blockwahl, so dass mir das nur bedingt hilft...

Hat irgendjemand eine hilfreiche Idee?

 

[ahaumer]

Problem gelöst!

Hallo!

(Dieser Beitrag richtet sich speziell an alle Asterisk User, die an einem ISDN Anlagenanschluss der Telekom Austria hängen: nicht aufgeben, es funktioniert tatsächlich!)

Mehrere Monate, nachdem ich den Fehler entdeckt habe, nach vielen erfolglosen Tests und einer Menge Herumprobiererei habe ich das Problem nun tatsächlich gelöst!

Ursache des Fehlers: ein Bug in Asterisk in Versionen < 1.4.15!

Meine Originalkonfiguration (siehe meinen ersten Beitrag) wäre prinzipiell schon korrekt gewesen, leider hat das WaitExten() die nachgewählten Nummern auf Grund eines Fehlers in der DTMF Erkennung nicht erkannt.

Der folgende Eintrag im ChangeLog von Asterisk hat mich schließlich auf die richtige Spur geführt:

2007-11-27 21:45 +0000 [r89790] Russell Bryant <[email protected]>

* main/autoservice.c, main/pbx.c: Merge changes from
team/russell/autoservice_1.4 This set of changes fixes an issue
that was reported to me on IRC yesterday. The user, d1mas, was
using chan_zap for incoming calls and was having DTMF recognition
issues in some situations. Specifically, he noticed that the
problem occurred when using DISA or WaitExten. He also noticed
that when using Read, the problem did not occur. His system also
used DUNDi for dialplan lookups. So, he theorized that if the
DUNDi lookups blocked for some period of time, that audio from
the zap channel could get lost. If the audio got lost, then it
wouldn't be run through the DTMF detector, and digits could get
lost.

Der Bug wurde Ende November 2007 mit Asterisk v1.4.15 behoben. Zu dem Zeitpunkt hatte ich schon eine Reihe von erfolglosen Versuchen mit verschiedenen Asterisk Versionen hinter mir, so dass ich den Fehler nur mehr in meiner Konfiguration gesucht habe und leider auf den Update auf diese neue Version verzichtet habe. Das hätte mir eine Menge Arbeit erspart...

Anyway, derzeit läuft hier ein Asterisk-1.4.18 mit chan_capi-1.0.2 an insgesamt drei Diva Server PRI-2M 2.0 PCI ISDN Karten. Zwei ISDN Karten laufen im PTP Modus an jeweils einem ISDN Basisanschluss der Telekom Austria und die Direkt-Durchwahl funktioniert mit allen Geräten, mit denen ich bis jetzt getestet habe!

Ein ankommender Ruf aus dem öffentlichen ISDN Netz an eine interne Nebenstelle (im Beispiel: 10) führt nun zu folgenden Logmeldungen von Asterisk:

  == ISDN2#02: Incoming call '01NNNNNNN' -> ''
    -- Executing [s@extern:1] NoOp("CAPI/ISDN2#02/-8", "") in new stack
    -- Executing [s@extern:2] Set("CAPI/ISDN2#02/-8", "TIMEOUT(digit)=4") in new stack
    -- Digit timeout set to 4
    -- Executing [s@extern:3] Set("CAPI/ISDN2#02/-8", "TIMEOUT(response)=4") in new stack
    -- Response timeout set to 4
    -- Executing [s@extern:4] WaitExten("CAPI/ISDN2#02/-8", "") in new stack
    -- ISDN2#02: Updated channel name: CAPI/ISDN2#02/K10-9
  == CDR updated on CAPI/ISDN2#02/K10-9
    -- Executing [10@extern:1] Macro("CAPI/ISDN2#02/K10-9", "siphone|10") in new stack
    -- Executing [s@macro-siphone:1] Dial("CAPI/ISDN2#02/K10-9", "SIP/10|45") in new stack
    -- Called 10
    -- SIP/10-08233b20 is ringing
    -- SIP/10-08233b20 answered CAPI/ISDN2#02/K10-9
  == ISDN2#02: Answering for K10
  == ISDN2#02: Setting up echo canceller (PLCI=0x102, function=1, options=4, tail=0)
    -- ISDN2#02: Echo canceller successfully set up (PLCI=0x102)

Der Unterschied zu den Logmeldungen im Fehlerfall sind im Wesentlichen die folgenden Zeilen:

   -- ISDN2#02: Updated channel name: CAPI/ISDN2#02/K10-9
 == CDR updated on CAPI/ISDN2#02/K10-9
    -- Executing [10@extern:1] Macro("CAPI/ISDN2#02/K10-9", "siphone|10") in new stack

WaitExten hat hier die nachgewählten Ziffern korrekt erkannt und reagiert auch korrekt darauf! So sollte es sein, warum nicht gleich so?

Jetzt bin ich erstmal geschafft, aber glücklich!

- andreas

 

[Telephonmann]

noch eine Frage

Gehe ich recht in der Annahme, dass von dem Bug auch alle 1.2.XX Versionen betroffen sind?