CAPI 0x3495 bei eingehendem Anruf an unkonfigurierte Durchwahl

[Ralph*]

Unser Asterisk hängt an einem T-Com ISDN-Anlagenanschluss. Alle Anrufe mit einer gültigen Durchwahl werden an das konfigurierte Endgerät weitergeleitet. Alles ok...

Wenn ein Anrufer aber eine Durchwahl wählt, die ich nicht konfiguriert habe, dann erhält er einen CAPI-Status 0x3495 (Anruf abgelehnt):

  == ISDN_TE1#02: Incoming call '0172xxxxxxx' -> '1234567'
    -- ISDN_TE1#02: Updated channel name: CAPI/ISDN_TE1#02/1234567-7e6
       > ISDN_TE1#02: CAPI INFO 0x3495: Call rejected
  == ISDN_TE1#02: CAPI Hangingup for PLCI=0x201 in state 4

Wenn ich das von meinem D2-Handy teste, höre ich das Congestion-Tonsignal (Hat das auch eine deutsche Bezeichnung? Es sind die 3 Töne in aufsteigender Tonhöhe). Von meinem privaten analogen T-Com Festnetzanschluss erklingt ein freundliches "Der Anschluss ist vorübergehend nicht erreichbar". (Ich glaube, dass diese Ansage auch erklingt, wenn man seine Telefonrechnung nicht bezahlt hat...).

Nun zu meiner Frage: Was wäre der korrekte CAPI-Statuscode bzw. das korrekte Verhalten, das im deutschen Telefonnetz in einem solchen Fall erwartet wird? Wie verhält sich denn eine herkömmliche ISDN-Anlage?

Und wie setze ich dann den Statuscode in meinem Dialplan?

Wäre 0x3481 (Rufnummer falsch) nicht besser? Oder 0x3495 (Anruf abgelehnt)? Oder 0x3483 (Kein Routing zum Ziel)?

Klar, es funktioniert. Aber irgendwie kommt es mir komisch vor...

Ralph

 

[armincm]

Wie es eine normale Anlage macht, kann ich auch nicht sagen. Eventuell kann man es auch dort konfigurieren. Meist wird aber wohl ein solcher Anruf an die Zentrale durchgestellt.
Am besten du leitest solche Anrufe in einen eigenen context weiter und machst dort einen Hangup(), aber vorher stellt du
Set(PRI_CAUSE=17)
wobei '17' hier der Cause code laut asterisk causes.h ist: BUSY.
Ich verwende PRI_CAUSE=88, dies ist "dienst oder dienstmerkmal nicht möglich".
Aber auch "kein Anschluss unter dieser Nummer" wäre denkbar.

Armin

PS: Eigentlich wird der cause code von asterisk (also z.B. vom Kanal 'gegenüber' verwendet, aber wenn es das nicht gibt, oder eben man etwas anderes setzen will, nimmt man PRI_CAUSE.

 

[Ralph*]

Armin,

danke sehr für Deine schnelle Antwort!

Am besten du leitest solche Anrufe in einen eigenen context weiter...

Ähem, wie geht das? Mit der Extension s vermutlich, aber wie (und warum) leite ich dann in einen eigenen Context weiter?

Ankommende Gespräche werden bei mir wie folgt behandelt (Ausschnitt):

[from-capi]
include => ivrmenue

exten => 123450,1,Answer()
exten => 123450,2,Wait(1)
exten => 123450,3,Goto(ivrmenue,s,1)
exten => 123450,4,Hangup()

exten => 1234541,1,Macro(inhousecall,41)
exten => 1234541,n,Hangup()

exten => 1234544,1,Set([email protected])
exten => 1234544,n,Goto(faxempfang,s,1)
exten => 1234544,n,Hangup()

[ivrmenue]
exten => s,1,Answer()
exten => s,2,Background(rs-selectdestination)
exten => s,3,WaitExten()
exten => s,4,Hangup()

exten => 1,1,Macro(inhousecall,90)
exten => 1,2,Hangup()

exten => 2,1,Macro(inhousecall,260)
exten => 2,2,Hangup()

Ralph

 

[armincm]

Du musst kein eigenen context nehmen...
mit Goto() oder über include die 'anderen' Nummern auch abfangen. In deinem Beispiel einfach ein
include => othernumbers
am ende von [from-capi] und dann

[othernumbers]
exten => _X.,1,Set(PRI_CAUSE=88)
exten => _X.,2,Hangup

Armin

 

[Ralph*]

Armin,

und nochmals danke für die Hilfe... ich habe es nun eingebaut und getestet, wobei ich drei Möglichkeiten versucht habe:

PRI_CAUSE 88 -- CAPI 0x34D8 -- Incompatible Destination / Zielrufnr. falsch

PRI_CAUSE 3 -- CAPI 0x3483 -- No route to Destination / kein Routing zum Ziel

PRI_CAUSE 1 -- CAPI 0x3481 -- Unallocated number / Kein Anschluss


Ich habe mich dann für die letzte Variante entschieden, denn damit erhalte ich vom Handy aus die Ansage "Die gewählte Nummer ist nicht vergeben" - wunderbar. Ich denke, mit dieser Auskunft kommt jeder Anrufer klar ;-)


EDIT (wäre ja auch zu einfach gewesen):

Leider erhalte ich von meinem analogen T-Com Anschluss diese Ansage (hier: "Kein Anschluss unter dieser Nummer") auch bei konfigurierten Extensions... wir waren also zumindest für ein paar Menschen eine Zeit lang auf keiner Durchwahl erreichbar.

Für den Moment halte ich also mal fest: Wenn ich einen Context am Ende von [from-capi] einfüge, der sich per _X. alle Anrufe "krallt", dann tut er das bei Anrufen von einem analogen Festnetzanschluss in jedem Fall, bei Anrufen vom Handy aus jedoch nur, wenn er keine andere passende Extension findet (was ja der eigentliche Plan war).

Ob das mit der Blockwahl im Mobilfunknetz zu tun hat?


Ralph

 

[Ralph*]

Armin,

ich hätte nun doch noch eine Frage:

Nachdem die von Dir vorgeschlagene (und auch an anderer Stelle empfohlene) Lösung auf wundersame Weise (und leider auch fälschlicherweise!) von meinem analogen Festnetzanschluss aus alle Anrufe abgefangen hat - also auch die Anrufe, die an eine konfigurierte Durchwahl gehen sollten - suche ich nach einer Möglichkeit, Asterisk einen neuen "Standard" für die Behandlung ungültiger Nebenstellen mitzuteilen.

Bislang (also ohne von mir gesetzten PRI_CAUSE) geht ein CAPI Code 0x3495 an die Anrufer, die eine ungültige Nebenstelle angerufen haben. Wo ist das hinterlegt?

Du schreibst, dass "der cause code von asterisk (also z.B. vom Kanal 'gegenüber' verwendet wird" - ich verstehe leider nicht, was Du mir damit sagen wolltest.

Ralph

 

[armincm]

Wie sieht denn der Context aus? Wenn du einfach _X. dazu setzt, dann macht Asterisk hier eine sehr merkwürdige Reihenfolge. Um die Reihenfolge vorzugeben, solltest du die einzelnen 'Zielgruppen' in eigene Contexte setzen und im eigentlichen in-context dann per include=>
arbeiten.

Mit Kanal gegenüber meinte ich die Verbindung die ein Kanal in Asterisk hat. Z.B. wenn ein Call von CAPI auf ein SIP Telefon geht, dann ist der SIP Kanal der Kanal gegenüber (blödes Wort, aber mir ist nichts besseres in dem Moment eingefallen). Wenn also dieser SIP Kanal nun ein hangup macht, dann wird ein hangupcause gesetzt. Und dieser Cause dann auch fuer das Hangup des CAPI Kanals verwendet (ausser du setzt PRI_CAUSE vor dem Hangup).

Armin

 

[Ralph*]

Armin,

sorry, hat ein wenig gedauert...

Wie sieht denn der Context aus?

Ich springe bei ankommenden ISDN-Gesprächen in [from-capi] und include dort - wie von Dir vorgeschlagen - einen neuen Context für die ungültigen Durchwahlen:

[from-capi]
include => ivrmenue

exten => 123450,1,Answer()
exten => 123450,2,Wait(1)
exten => 123450,3,Goto(ivrmenue,s,1)
exten => 123450,4,Hangup()

exten => 1234541,1,Macro(inhousecall,41)
exten => 1234541,n,Hangup()

exten => 1234544,1,Set([email protected])
exten => 1234544,n,Goto(faxempfang,s,1)
exten => 1234544,n,Hangup()

exten => all die anderen gültigen Durchwahlen...

include => AllTheOthers

[ivrmenue]
exten => s,1,Answer()
exten => s,2,Background(rs-selectdestination)
exten => s,3,WaitExten()
exten => s,4,Hangup()

exten => 1,1,Macro(inhousecall,90)
exten => 1,2,Hangup()

exten => 2,1,Macro(inhousecall,260)
exten => 2,2,Hangup()

[AllTheOthers]
; ***********************************************
; Kein Anschluss unter dieser Nummer
; ***********************************************
exten => _X.,1,NoCDR()
exten => _X.,2,Set(PRI_CAUSE=1)
exten => _X.,3,Hangup()

Das funktioniert aber komischerweise nicht von meinem analogen Festnetzanschluss: Verbindungsversuche auf eine eigentlich gültige Durchwahl landen dann trotzdem in [AllTheOthers].

Von meinem Handy aus allerdings ist alles ok.

Warum das manchmal nicht funktioniert, verstehe ich leider nicht...

Daher der zweite Lösungsansatz:

Lasse ich [AllTheOthers] einfach weg, dann findet Asterisk bei einer undefinierten Durchwahl keinen Match im Dialplan und reagiert in Richtung ISDN mit CAPI 0x3495.

Dann kann ich übrigens auch vom analogen Festnetz aus wieder dir definierten Durchwahlen erreichen...

Was ist denn zu diesem Zeitpunkt (kein Dialplan-Match) der Kanal gegenüber? Woher kommt CAPI 0x3495 und könnte man als Default (in chan_capi?) nicht evtl. etwas anderes (0x3481) vorgeben?

Ralph

 

[armincm]

Versuch doch mal deine normalen extensions auch per include einzubinden und hier mit den include Zeilen die korrekte Reihenfolge einzuhalten. So mache ich es auch immer.

Armin

 

[Ralph*]

EDIT:
Ich dachte schon, ich hätte jetzt eine Lösung - aber: Nein, es funktioniert nicht.

Auch auf dem unten beschriebenen Weg kann ich seltsamerweise von meinem analogen T-Com Festnetzanschluss auch die erlaubten, konfigurierten Durchwahlen NICHT erreichen. Ich erhalte in allen Fällen ein "Kein Anschluss unter dieser Nummer".

Es funktioniert von meinem D2-Handy und von einem anderen ISDN-Anschluss aus - nicht aber von Analog. Wie kann das sein?
/EDIT

Der Vollständigkeit halber - das war es wohl, was Armin gemeint hat:

[from-capi]
include => ivrmenue
include => valid-extens
include => AllTheOthers

[valid-extens]
exten => 123450,1,Answer()
exten => 123450,2,Wait(1)
exten => 123450,3,Goto(ivrmenue,s,1)
exten => 123450,4,Hangup()

exten => 1234541,1,Macro(inhousecall,41)
exten => 1234541,n,Hangup()

exten => 1234544,1,Set([email protected])
exten => 1234544,n,Goto(faxempfang,s,1)
exten => 1234544,n,Hangup()

[ivrmenue]
exten => s,1,Answer()
exten => s,2,Background(rs-selectdestination)
exten => s,3,WaitExten()
exten => s,4,Hangup()

exten => 1,1,Macro(inhousecall,90)
exten => 1,2,Hangup()

exten => 2,1,Macro(inhousecall,260)
exten => 2,2,Hangup()

[AllTheOthers]
; ***********************************************
; Kein Anschluss unter dieser Nummer
; ***********************************************
exten => _X.,1,NoCDR()
exten => _X.,2,Set(PRI_CAUSE=1)
exten => _X.,3,Hangup()

Komischerweise widerspricht das aber (zumindest so weit ich das verstehe) der Angabe in
Das-Asterisk-Buch.de - dort heißt es:

Asterisk sucht bevor es einen anderen Context einbindet (include) immer erst im aktuellen Context nach einem Treffer (einem Match). Gibt es einen Treffer, wird dieser benutzt. Gibt es keinen Treffer, wird das erste Include vollzogen und dort nach einem Treffer gesucht...

Ich hatte in meinem ersten Versuch doch im eigentlichen Context [from-capi] die gültigen Durchwahlen definiert. Asterisk hätte also doch zunächst den Treffer im Context finden sollen und erst im Fehlerfall das includierte [AllTheOthers] benutzen sollen. Oder?