Welcher Telefoncode beendet einen von extern eingehenden Anruf?

[Black Senator]

Abgetrennt von https://www.ip-phone-forum.de/threads/telefoncodes-der-fritzbox-neue-version.77281/page-22 by stoney

​

Welcher Telefoncode beendet einen von extern eingehenden Anruf?​

Moin,

wie hier schon an einigen Stellen und bei AVM selbst beklagt gibt es ja leider kein SOAP-Action, um einen eingehenden Anruf zu beenden.
Nun kam mir heute die spontane Idee, ob es nicht einfach mit einem "Gegenfeuer" realisierbar wäre. Sprich: per Telefoncode den Anruf zu terminieren.
Ich habe folgende Codes mit X_AVM-DE_DialNumber - erfolglos - ausprobiert:

• nach der Liste hier: '##'
• nach Tipp aus Stackoverflow: 'ATH', 'ATH0', 'ATH1', 'AT+CHUP', 'AT+CHLD' und 'AT+CHCCS'

Interessant war, dass ich, nachdem ich 'ATH' probiert habe, anschließend beim Versuch mit 'ATH0' einen SOAP-Error 600 (Argument Value Invalid) zurückgeliefert bekomme. Bei der Wiederholung mit 'ATH0' dann nicht mehr. Das lässt sich zumindest mit der Sequenzwiederholung reproduzieren - aber dafür verstehe ich auch zu wenig gar nichts?) von den AT Kommados.
Zumindest belegt es, dass man mit dem SOAP-Action AT Kommandos senden kann - auch wenn Sie nicht das gewünschte bewirken

Vermutlich bin ich total auf dem Holzweg mit meinem Ansatz - wäre aber ein spannender Workaround, um das Dilemma des fehlenden "X_AVM-DE_Disconnect" zu lösen

Hat jemand einen Tipp?

Grüße

Black Senator

 

[PeterPawn]

Trotzdem rate ich hier mal mit (notfalls bitte einfach mit verschieben) und behaupte, daß da vermutlich die beim Dial übergebene Nummer unsaniert an ein AT-Kommando zum Wählen angehangen wird. Denn daß im FRITZ!OS der telefon-Daemon auch AT-Kommandos versteht, ist ja kein Geheimnis - das kann jeder mittels Telnet-Zugriff auf dem Port 1011 (aber nur innerhalb der FRITZ!Box, will man ihn nach außen legen, braucht man irgendeinen Proxy oder meinetwegen einen SSH-Tunnel) ausprobieren.

Wenn also die angestoßene SOAP-Aktion X_AVM-DE_DialNumber (oben ist ein Bindestrich anstelle eines Unterstrich zu sehen, der ist aber falsch an dieser Stelle) die Nummer tatsächlich ungeprüft übernimmt, dann wäre das auch eine - für mich zumindest - plausible Erklärung, warum hier überhaupt AT-Kommandos IRGENDETWAS bewirken sollten.

Denn tatsächlich funktioniert auch die "Verkettung" mehrerer AT-Kommandos, indem man zwischen sie ein Semikolon setzt. Wenn dann ein ATH tatsächlich ALLE Leitungen auflegt (bei VoIP-Clients bin ich mir da nicht so sicher - der ganze AT-Kommandokram stammt ja noch aus der Vorzeit des voipd), dann würde ich als Nummer eher so etwas wie **3;ATH versuchen - bei einem ATD**50;ATH (direkte Eingabe am Port 1011) klingelt mein ISDN-Telefon jedenfalls (auch heute noch mit einer 07.24-irgendwas an der 7490 - genauso wie schon vor Jahren mit einer 06.2x) sehr kurz, bevor der Ruf wieder beendet wird (wer will, kann sich auch die ISDN-Messages im D-Kanal ansehen mittels dtrace). Ob davon auch parallel laufende andere Telefonate betroffen wären (unabhängig von der Technologie, wobei DECT ja auf ISDN "gemappt" wird bei AVM), habe ich nicht getestet.

Voraussetzung wäre es eben, daß die Nummer tatsächlich unsaniert weitergegeben wird (was mich nicht wirklich verblüffen würde, denn auch das stammt partiell ja noch aus der Zeit, wo Sicherheit noch kein Thema war) ... ich habe aber gerade keinen Bock, das auf TR-064 im X_VOIP-Interface selbst zu testen. Aber bei anderer Implementierung würde sich mir nicht erschließen, wieso da überhaupt irgendwelche AT-Kommandos interpretiert werden sollten.

Wenn das wirklich so klappt, müßte man sogar wieder nachsehen, ob nicht durch geschickte Wahl der Rufnummer und ein anschließend noch angehangenes ATD wieder der Zugriff auf eigentlich gesperrte Rufnummerngassen möglich wird - wenn so eine Nummer nur am Beginn geprüft wird und da eine erlaubte Gasse steht, könnte auf diesem Weg ja auch wieder ein kostenpflichtiges und -intensives Gespräch "durchrutschen".

Wenn das hier also als OT angesehen werden sollte, dann bitte ich darum, das in einen neuen Thread zu packen und nicht nur zu entsorgen ... das Thema an sich ist durchaus "spannend" und sollte nicht einfach unter den Tisch fallen.

EDIT: BTW ... daß ein richtig platziertes ATH tatsächlich eingehende Gespräche auflegen kann, ist m.W. tatsächlich bekannt und war hier (aus der Erinnerung) auch schon Thema - irgendwie habe ich da eine Diskussion zum Datenschutz i.V.m. der automatischen Abfrage eingehender Rufnummern bei Tellows im Kopf, wo aber bei entsprechendem Ergebnis der eingehende Anruf auch "aufgelegt" wurde.

Nur weiß ich nicht mehr, ob das tatsächlich für alle Technologien funktioniert(e). Wobei die Wählhilfe ja (zumindest bei der Konfiguration im GUI) auch auf "keine SIP-Clients" beschränkt ist - oder kann man über X_AVM-DE_DialSetConfig mittlerweile doch auch SIP-Clients auswählen?

 

[Black Senator]

@PeterPawn

Danke für´s mitraten und Zuspruch.
Ich hatte das Umfeld (SOAP) und meine "Beobachtungen" nur geschildert, um nicht in gewohnter Weise gleich abgebürstet oder mit inhaltslosen Wortmeldungen bedacht zu werden.

'**3;ATH', bewirkt leider ebensowenig ein DISCONNECT wie '**1;ATH' oder '**2;ATH'

 

[Black Senator]

Hallo,

das Thema musste nun leider ein halbes Jahr ruhen - nun wollte ich mich dem wieder widmen. In dem Zusammenhang muss ich aber noch einen kleinen Exkurs machen der mich in dem Zusammenhang seit zwei Wochen umtreibt:
Ich verstehe nicht was mir einige Actions aus x_voip zurückliefern!
Das liegt sicher daran, dass ich von Telefonie in der FRITZ!Box keine Ahnung habe - sicher aber jemand hier im Forum (@PeterPawn zum Beispiel?).

Ausgangssituation:

• zugewiesen sind 10 MSN
• aktuell verwendet werden davon 4
• die Telefoniegeräte sind drei FRITZ!Fon, ein paar Anrufbeantworter, internes FAX und virtuell die "Haustür":
  

So nun zu meinen
Ergebnissen und Fragen:

• GetExistingVoIPNumbers liefert "10" zurück - passt also
• GetMaxVoIPNumbers liefert "20" zurück - wird wohl stimmen, wenn ich die AVM Angaben addiere:
  • 1 S0-Bus
  • 3 analoge Anschlüsse
  • 6 DECT Geräte
  • 10 IP Telefone
• GetVoIPEnableCountryCode(ui2) mit ui2 (int) von 0 bis 9 liefert jeweils "0" - das bezieht sich also vermutlich auf die 10 IP Telefone von denen ich ja wohl keines installiert habe(?)
• X_AVM-DE_GetNumberOfClients liefert auch "0" - was mich stutzig macht, da nicht dokumentiert ist, dass Clients = IP Telefoniegeräte sei
• nicht überraschend liefert X_AVM-DE_GetClient()ui2 mit ui2 (int) von 0 bis 9 jeweils der Error "713"
• und ebenso X_AVM-DE_GetClients lediglich den XML-Rumpf "<List />"
• X_AVM-DE_GetNumberOfNumbers liefert "10" zurück - aber das wissen wir doch schon mit GetExistingVoIPNumbers?
• zumal mit X_AVM-DE_GetNumbers die Liste mit den zehn MSN als XML ausgegeben werden:
  

  <?xml version="1.0"?>    <List>
          <Item>
              <Number>9xxxxx</Number>
              <Type>eVoIP</Type>
              <Index>0</Index>
              <Name>Privatnummer</Name>
          </Item>
          <Item>
          ...

• ebenso wie mit X_AVM-DE_GetVoIPAccount die Zugangsdaten der 10 MSN zurückgeliefert werden
• X_AVM-DE_GetPhonePort(ui2) mit ui2 (int) von 1 bis 5 liefert:
  

  FON1: Haustür
  ISDN: ISDN/DECT Rundruf
  DECT: Lxxxx
  DECT: Erdgeschoss
  DECT: Obergeschoss

  wobei ich nicht verstehe, warum
  • der Index mit "1" statt "0" beginnt und
  • ich es auch leider kein Action wie z.B. GetMaxPhonePorts gibt, damit man gezielt mit den Indizes abfragen kann, ohne umständlich falsche Indizes über Errorcodes abzufangen...

Kann mir jemand ein wenig die Zusammenhänge zwischen dem, was in der FRITZ!Box eingestellt ist, und dem, was in diesem Fall der SOAP-Service x_voip so zurückliefert, erklären?

Danke

Black Senator

 

[B612]

GetMaxVoIPNumbers liefert "20" zurück

Das ist aber nicht die Anzahl der möglichen Telefone sondern die Anzahl der möglichen eigenen Nummern.

 

[Kruemelino]

Hallo,
ich klinke mich hier mal ein. Für mein Outlook-Addin habe ich eigene TR-064 Routinen erstellt und kann die seltsamen Ergebnisse nachvollziehen. Insbesondere bei X_AVM-DE_GetPhonePort habe ich mich auch gefragt was der Künstler mir damit sagen wollte. An der Stelle habe ich mir damit beholfen, dass ich vorher alle in Frage kommenden Telefone ausgelesen habe. (Es gibt aber keine TR-064 Funktion, die alle Telefon liefert. Es sind mehrere Abfragen teils mit http-Queries notwendig.)

Ich werde bei mir mal Testen, was die anderen Abfragen liefern. Auch das initiale Thema mit dem Telefoncode für den Abbruch gehe ich gerne mal nach.

Irgendwie läuft dein Link auf die Dokumentation der X_VoiP auf die alte Version von 2012. Hier die aktuelle:
2012: https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_voipSCPD.pdf
2019: https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_voip-avm.pdf

Meine Konfiguration:
Fritz!Box 7490 mit 3 registrierten Telefonnummern (alles VOIP, kein Festnetz etc), 2 IP-Telefone als Softwaretelefon (Phoner620 und MicroSIP)

Meine Testergebnisse:

• GetExistingVoIPNumbers liefert 3. Das passt also zu den registrierten Telefonnummern
• GetMaxVoIPNumbers liefert 20
• X_AVM-DE_GetNumberOfClients liefert 2. Das passt zu den beiden IP-Telefonen
• X_AVM-DE_GetNumberOfNumbers liefert 2 Ich habe noch keinen Plan, was dahinter steht.
• GetVoIPEnableAreaCode mit NewVoIPAccountIndex = 0 liefert True. Das gibt vielleicht an, dass die Ortsnetzkennzahl immer mit gewählt wird? Die Dokumentation ist eine wahre Freude.
• GetVoIPEnableCountryCode mit NewVoIPAccountIndex = 0 liefert False. Das gibt vielleicht an, dass die Landeskennzahl immer mit gewählt wird? Die Dokumentation ist eine wahre Freude.
• NewX_AVM-DE_ClientList liefert eine Liste der angeschlossenen IP-Telefone.
  

  <List>
      <Item>
          <X_AVM-DE_ClientUsername>Phoner620</X_AVM-DE_ClientUsername>
          <X_AVM-DE_ClientIndex>0</X_AVM-DE_ClientIndex>
          <X_AVM-DE_ClientRegistrar>192.168.180.1</X_AVM-DE_ClientRegistrar>
          <X_AVM-DE_ClientRegistrarPort>5060</X_AVM-DE_ClientRegistrarPort>
          <X_AVM-DE_ClientId/>
          <X_AVM-DE_ExternalRegistration>0</X_AVM-DE_ExternalRegistration>
          <X_AVM-DE_OutGoingNumber>111111</X_AVM-DE_OutGoingNumber>
          <X_AVM-DE_InComingNumbers>
              <Item>
                  <Number>111111</Number>
                  <Type>eVoIP</Type>
                  <Index>4</Index>
                  <Name/>
              </Item>
          </X_AVM-DE_InComingNumbers>
          <X_AVM-DE_PhoneName>Phoner</X_AVM-DE_PhoneName>
          <X_AVM-DE_InternalNumber>620</X_AVM-DE_InternalNumber>
          <X_AVM-DE_DelayedCallNotification>0</X_AVM-DE_DelayedCallNotification>
      </Item>
      <Item>
          <X_AVM-DE_ClientUsername>MicroSIP</X_AVM-DE_ClientUsername>
          <X_AVM-DE_ClientIndex>1</X_AVM-DE_ClientIndex>
          <X_AVM-DE_ClientRegistrar>192.168.180.1</X_AVM-DE_ClientRegistrar>
          <X_AVM-DE_ClientRegistrarPort>5060</X_AVM-DE_ClientRegistrarPort>
          <X_AVM-DE_ClientId/>
          <X_AVM-DE_ExternalRegistration>0</X_AVM-DE_ExternalRegistration>
          <X_AVM-DE_OutGoingNumber>999999</X_AVM-DE_OutGoingNumber>
          <X_AVM-DE_InComingNumbers>
              <Item>
                  <Number>999999</Number>
                  <Type>eVoIP</Type>
                  <Index>4</Index>
                  <Name/>
              </Item>
          </X_AVM-DE_InComingNumbers>
          <X_AVM-DE_PhoneName>MicroSIP</X_AVM-DE_PhoneName>
          <X_AVM-DE_InternalNumber>621</X_AVM-DE_InternalNumber>
          <X_AVM-DE_DelayedCallNotification>0</X_AVM-DE_DelayedCallNotification>
      </Item>
  </List>

• X_AVM-DE_GetVoIPAccount mit NewVoIPAccountIndex = 0 liefert die Daten zu der registrierten VoIP-Nummer:
  

  <NewVoIPRegistrar>registrar.*******.de</NewVoIPRegistrar>
  <NewVoIPNumber>999999</NewVoIPNumber>
  <NewVoIPUsername>111111999999</NewVoIPUsername>
  <NewVoIPPassword>****</NewVoIPPassword>
  <NewVoIPOutboundProxy>proxy.*******.de</NewVoIPOutboundProxy>
  <NewVoIPSTUNServer></NewVoIPSTUNServer>

Zusammenfassend würde ich jetzt sagen, dass hier zum einen die IP-Telefoniegeräte (Clients) abgefrühstückt werden, als auch die registrierten Telefonnummern (VoIPNumbers).

 

[Black Senator]

Hallo,

wie angedeutet habe ich diesen zur Überschrift abweichenden "Nebenkriegsschauplatz" eröffnet mit folgender Intention:
Einigen anderen Beiträgen hier im Forum von u.a. @creon zufolge

• wäre ein Disconnect möglich,
• wenn alle Telefone nacheinander per AT Kommando ATP[x] x=phone
• das Gespräch an sich ziehen (catch all) ATD*09
• und dann beenden ATH0
• das also n-mal für die Art und Anzahl der angeschlossenen Telefone als Dial-String

Meine Idee darauf basierend war/ist: per SOAP-Request die Phones ermitteln (daher die Ergebnisse aus x_voip) und darauf aufbauend den passenden String von AT-Kommandos zur Terminierung aufzubauen (also für jede Konstellation individuell) und dann mit X_AVM-DE_DialNumber([AT-string]) das Disconnect auszulösen.

Leider bin ich kein Kenner von AT-Kommandos und bin mir daher auch nicht sicher wie das auf z.B. mit meine Konstellation:

• FON1: Haustür -> **1
• ISDN: ISDN/DECT Rundruf ->
• DECT: Lxxxx -> **611
• DECT: Erdgeschoss -> **613
• DECT: Obergeschoss -> **614

zu übertragen wäre: "ATP1;ATD*09;ATH0;ATP611;ATD*09;ATH0;ATP613;ATD*09;ATH0;ATP614;ATD*09;ATH0" ?

Irgendwo anders hab ich auch etwas von notwendigen Pausen zwischen den AT-Kommandos gelesen.
Ist das Trennzeichen ";" oder " " oder ","?

Mit diesen Wissenslücken bzw. Variablen per trial & error AT-Kommando-Strings aufzubauen, dann im Versuch sich selbst anzurufen und dann versuchen per Dial mit dem String den eingehenden Anruf abzuschießen erscheint mir nicht effizient.

Wenn hier jemand mit Sicherheit weiß, wie so ein Dial-String mit AT-Kommandos richtig lauten muss - das wäre hilfreich!

Nun hat @creon aber auch noch zwischenzeitlich per PM geschrieben:

...für mich herausgefunden: Es gibt keine Möglichkeit, ein Gespräch mit einem Befehl zu beenden.
Schieße ich aber mit 10 Befehlen hintereinander, bricht das Gespräch – vermutlich aufgrund eines Fehlers – ab.

Wenn jemand etwas beizutragen hat was Hoffnung auf eine Lösung bietet - bitte gern!

Grüße

Black Senator

 

[Black Senator]

@Kruemelino

Ich habe heute noch etwas rumexperimentiert:
Die Wählhilfe kann ich mit X_AVM-DE_DialSetConfig() nur mit den Strings verändern, die X_AVM-DE_GetPhonePort() zurückgibt.

Hier mal als Beispiel:

Basierend auf meinen Erfahrungen mit dem Image-Upload auf ein FRITZ!Fon hätte ich angenommen, dass auch hier mit der Nummer des Gerätes z.B. '613' das gewünschte Gerät gewählt bzw. gewechselt wird.
Versuche mit der Nummern in verschiedener Kombination (z.B. '**613', '63', 'DECT3', 'DECT: 613' etc.) funktionieren nicht und werden entsprechend mit dem Fehler 402 (Invalid Args) quitiert.

Einzige positive Überraschung war, dass ein leerer String die Wählhilfe deaktiviert - unerwartet, aber im Nachhinein auch logisch.
X_AVM-DE_DialGetConfig liefert dann 'unconfigured'.

Grüße

Black Senator

 

[Kruemelino]

Hallo @Black Senator,

Asche auf mein Haupt. Das hätte ich dir vorab sagen können. Sorry.

Leider ist die TR-064 Wählhilfe nicht besonders gut beschrieben. Über die vier Abfrage X_AVM-DE_DialGetConfig, X_AVM-DE_DialSetConfig, X_AVM-DE_DialNumber und X_AVM-DE_DialHangup kannst du die Wählhilfe steuern. Für die Wählhilfe muss immer ein Telefon voreingestellt sein. Die ganze Konfiguration kann auch über die Benutzeroberfläche erfolgen.

• X_AVM-DE_DialGetConfig: Ausgabe des eingestellten Telefones. Es kommt die Zeichenfolge des eingestellten Telefons nach der Formatierung X_AVM-DE_PhoneName zurück. (ich nenn das Ding immer "DialPort")
• X_AVM-DE_DialSetConfig: Setzen des "DialPort". Auch hier muss eine Zeichenfolge analog zu X_AVM-DE_PhoneName gesendet werden. Dies gibt die Dokumentation auch so vor. Unter Related state variable steht der Verweis auf die zugehörige Variable in der Service States Table (Seite 16 - 19). Hinweis: Für das setzen des DialpPortes ist eine 2FA erforderlich, sofern die nicht deaktiviert wurde.
• X_AVM-DE_DialNumber: Anruf auf dem eingestellten Telefon zur Nummer starten.
• X_AVM-DE_DialHangup: Anruf auf dem eingestellten Telefon beenden. Naja AVM schreibt hier Disconnect the dialling process. was ja frei übersetzt eher einem Beende den Wählvorgang entspricht.

Es gäbe da noch die Möglichkeit das Wählen über http GET und POST zu realisieren. Das hab ich aber schon lange nicht mehr so gemacht. (Oh je. was hab ich damals zusammengeschrieben. Grauenvoll!)

Setzen des DialPort per http POST auf https://fritz.box/data.lua:

&xhr=1&clicktodial=on&port={SessionID}&sid={DialPort}&back_to_page=%2Ffon_num%2Fdial_fonbook.lua&btn_apply=&lang=de&page=telDial

wobei:

    '  Die ID des Telefones addieren werden (nullbasiert). (Das erste DECT ist 60, das zweite 61 usw. Dein "Erdgeschoß" wäre die 63!)  
    Private Enum DialPortBase As Integer
        FON = 1
        Fax = 5 ' keine Ahnung, ob das je funktioniert hat. Das ist der integrierte Faxempfang.
        S0 = 50
        DECT = 60
    End Enum

Abfrage des Dialportes via Query:

https://fritz.box/query.lua?sid={SessionID}&DialPort=telcfg:settings/DialPort

Wählvorgang:

' Die Rückgabe ist der JSON - Wert "dialing"
' Bei der Wahl von Telefonnummern ist es ein {"dialing": "0123456789#"}
' Bei der Wahl von Telefoncodes ist es ein {"dialing": "#96*0*"}
' Bei der Wahl Des Hangup ist es ein {"dialing": false}
' NEU {"dialing":true,"err":0}
' NEU {"dialing":false,"err":0}

https://fritz.box/fon_num/fonbook_list.lua?sid={SessionID}&dial={TelNr}
https://fritz.box/fon_num/fonbook_list.lua?sid={SessionID}&hangup=

Ich hoffe ich konnte helfen.

 

[Black Senator]

Moin,

wieder ist ein halbes Jahr vergangen und erneut habe ich versucht mit AT-Kommandos das vermaledeite Problem zu lösen. Ich habe auch - mal wieder - an den AVM Entwicklersupport geschrieben. Aber noch keine weitere (beschwichtigend nichtsagende) Antwort erhalten.
Irgendwie kann ich nicht begreifen, warum mit den dokumentierten AT-Befehlen ein eingehender Call nicht terminiert werden kann - zefix

Das es prinzipiell mit TR-064 (x_voip) funktioniert kann man bei ausgehenden Calls sehen:
Ein Rundruf an zwei weitere FRITZ!Fon mit X_AVM-DE_DialNumber("ATD**9"), ein paar Sekunden warten und dann beenden mit X_AVM-DE_DialNumber("ATH") funktioniert.
Damit ist bewiesen, dass AT-Befehle mit X_AVM-DE_DialNumber() korrekt abgesetzt werden können und darüber hinaus, dass X_AVM-DE_DialNumber("ATH") genauso funtioniert wie X_AVM-DE_DialHangup.

Zum Test für eingehende Anrufe rufe ich eine noch freie MSN auf das FRITZ!Fon, das mit der Wählhilfe gekoppelt ist gelegt und Rufe dort von meinem Mobiltelefon an. Nach einem Mal Klingeln lasse ich das Script mit den jeweiligen Test-AT-Kommandos laufen, um zu sehen, ob der Anruf aufgelegt (abgewiesen wird):
Der oben genannten und weiteren Quellen folgend (z.B. stackoverflow) habe ich u.a. versucht dem ATH ein AT+CVHU=0 voranzustellen bzw. auch noch einmal das schon viel weiter oben bereits erwähnte AT+CHUP ("...always will hang up the current call, independently of ATH behaviour configuration..." und "...command ends call whenever answered or not...") zu versuchen: es klingelt munter weiter - zefix es ist zum Mäusemelken...

Grüße

Black Senator

 

[koyaanisqatsi]

Querdenken - Äh - Assoziieren
Wenn ATD**9 und ATH klappt,
dann versuch doch mal bei eingehenden Anruf: ATD09 und ATH
( Call Pickup & auflegen )

 

[stsoft]

Damit ist bewiesen, dass AT-Befehle mit X_AVM-DE_DialNumber() korrekt abgesetzt werden können und darüber hinaus, dass X_AVM-DE_DialNumber("ATH") genauso funtioniert wie X_AVM-DE_DialHangup.

Weder das ATD noch das ATH sind hier sinnvoll/notwendig. Sehr vermutlich, weil alles außer Ziffern, * und # ausgefiltert werden.
Wenn Du weiter probiert hättest, dann hättest Du festgestellt, das vermutlich
X_AVM-DE_DialNumber("Legebitteauf") auch genauso funktioniert wie X_AVM-DE_DialHangup.
Wie Du selbst festgestellt hast, sind die Funktionen um ausgehende Rufe als Wahlhilfe aufzubauen bzw. vor Rufübernahme durch das lokale Telefon wieder zu beenden.
Wenn Du das für die Wahlhilfe zugeordnete lokale Telefon abgehoben hättest, hättest Du auch festgestellt, das weder
X_AVM-DE_DialNumber("ATH")
noch
X_AVM-DE_DialNumber("Legebitteauf")
noch
X_AVM-DE_DialHangup
funktioniert.

 

[Black Senator]

@stsoft
Ja, da hast Du recht. Inzwischen hat AVM auch explizit bestätigt

Im FRITZ!OS werden keine AT-Kommandos unterstützt.

und

Die beschriebene Funktionen X_AVM-DE_DialNumber und X_AVM-DE_DialHangup dienen der Wahlhilfe zum ausgehenden Rufaufbau und sind nicht für eine andere Verwendung vorgesehen.

Schade, schade! Es wäre schon irgendwie geil gewesen, wenn man X_AVM-DE_DialNumber('AT+irgendwas') einen Weg "durch-die Brust-ins-Auge" gefunden hätte, um endlich einen Befehl zu haben, um Inbound-Calls zu terminieren...

AVM-Entwicklersupport schreibt weiter:

Grundsätzlich könnten Sie zu einer Lösung kommen, wenn Sie ein ISDN- oder DECT-Telefon auf "Besetzt bei Besetzt" konfigurieren und dann dort den Ruf abweisen.

Kann damit jemand etwas anfangen?
Ein "virtuelles" Telefongerät am S0 (**51) mit dem Merkmal Busy on Busy einrichten bekomme ich ja noch hin...
Mhmm, aber wie müsste denn der Telefon-Code bzw. deren Kombination/Abfolgen lauten, um einen Anruf (Nummer ist dann ja vom Callmonitor bekannt) auf dieses Gerät umzuleiten?

Fragt sich der an dieser Stelle völlig unbedarfte

Black Senator

 

[stsoft]

Du kannst CapiOverTCP aktivieren und dann per SW virtuell an den ISDN-Bus.
Per IP-Telefon und mit einem SIP-Client kannst Du das auch machen. Direkt nach dem 200 OK ein BYE senden. Gut ist kein direktes Abweisen, sondern annehmen + Auflegen, aber funktional sehr identisch für den Anrufer.

 

[Black Senator]

@stsoft
Danke für deine rasche Antwort, aber was Du damit meinst habe ich leider nicht verstanden.
Vorab vieleicht noch eine Erklärung, die in diesem Thread evtl. untergegangen ist: ich habe ein Spamfilterprogramm am Start, in welchem ich identifizierte(!) Spammer nicht nur in das entsprechende Spam-Telefonbuch übertragen will, sondern den Anruf auch möglichst gleich automatisch vom Programm beenden lassen will.

a) CapiOverTCP ist bei mir sowieso aktiviert, da ich fritz4fax noch ab und an nutze. Unabhängig davon: das mit X_AVM-DE_DialNumber('#96*3*') per Programm zu aktivieren funktioniert. Nur wozu ich die Aktivierung in diesem Fall benötige ist mir noch nicht klar.
b) Was Du aber mit "...und dann per S[oft]W[are] virtuell an den ISDN-Bus..." meinst, erschließt sich mir leider gerade auch nicht.

Grüße

Black Senator

 

[Kruemelino]

Ich hab das Thema nur verfolgen können. Leider kann ich momentan nicht viel testen.

Aber mal folgende Überlegung:
Das eingehende Telefonat, welches abgewiesen werden soll, wird per X_AVM-DE_DialNumber(**0ns) auf ein nicht weiter konfiguriertes S0-Gerät herangezogen. Entweder es klingelt dort lustig vor sich hin, oder es wird dort irgendwie beendet. Zuvor muss natürlich das Wählhilfe-Telefon auf das S0-Gerät abgeändert werden.

1. Mittels X_AVM-DE_DialGetConfig das aktuell eingestellte Telefon der Wählhilfe auslesen und merken.
2. Mittels X_AVM-DE_DialSetConfig die Wählhilfe auf das konfiguriertes S0-Gerät umschalten
3. Das Wählkomando für das Heranholen eines Telefonates (z. B. X_AVM-DE_DialNumber(**062)) absetzen.
4. ... (hoffen das es klappt)
5. ggf. Telefonat beenden (wie?) Wahlregel? Anrufbeantworter?
6. Wahlhilfe wieder auf das ursprünglich eingestellte Telefon setzen (X_AVM-DE_DialSetConfig).

Das hat bestimmt schon mal jemand probiert.

Edit: Einfacher Test hat bei mir funktioniert (zumindest hat nicht das eigentliche Telefon geklingelt sondern ich hab ein Besetztzeichen erhalten). Ich hab dann nur Bedenken, dass es immer in allen Konstellationen funktioniert. (Da man sich das Telefonat von einer Nebenstelle holt und beim RING eigentlich noch keine Nebenstelle bekannt ist, kann das auch schön Scheitern)

 

[PeterPawn]

Wer sich nicht auf "unmodifizierte Firmware" beschränkt, kann über den Port 1011 (an "localhost" auf der Box) aber tatsächlich auch AT-Kommandos an den telefon-Daemon von AVM absetzen.

Vielleicht verwechseln andere Quellen auch diese Option (die natürlich auch nicht offiziell dokumentiert ist und schon gar keine "Kunststücke" bei den AT-Kommandos versteht, sondern nur "basic Hayes": https://en.wikipedia.org/wiki/Hayes_command_set und auch das nicht "vollständig") mit der möglichen Angabe von AT-Kommandos in einem TR-064-Funktionsaufruf.

Wer es ernst genug meint und auch bereit ist, die Firmware entsprechend zu modifizieren, kann sich mittels stunnel oder auch mit einem SSH-Server auf der Box diesen Port auch auf sicherem Weg "nach außen" legen (ggf. sogar mit Client-Zertifikat, wenn man stunnel nutzt).

Die dort eingegebenen Kommandos "steuern" praktisch den ersten analogen Port. Ob das auch für den zweiten gilt (falls der erste "unkonfiguriert" ist), weiß ich aus dem Kopf nicht mehr.

"Ausgehende" Anrufe sind (iirc) seit einiger Zeit auch nicht mehr möglich, aber das Anwählen interner Nebenstellen und auch die Benutzung von Telefon-Codes funktionieren immer noch.

Vielleicht ist es auch nur meine "zerwürgte" Konfiguration der Nebenstellen, die ausgehende Anrufe verhindert (bei mir läßt sich auf der getesteten Box keine Einstellung der Telefoniegeräte mehr verändern, das führt immer zum Fehler im GUI - ich habe nur keine Lust, das erneut "richtig" zu konfigurieren, weil das ohnehin nur "Spielerei" ist mit dieser Box bzw. Testen von Software).

Es IST also auch möglich, solche Anrufe "abzuwürgen" (wenn auch erst nach "Heranholen" - ATD09 - oder "Antworten" - ATA) durch ein ATH-Kommando. Aber das ist keinesfalls irgendeine besonders smarte "Modem-Emulation", das dient wohl in erster Linie nur der Kommunikation zwischen verschiedenen AVM-Komponenten und selbst da wäre ich mir (angesichts zunehmender Umstellungen auf SIP-Protokoll) nicht mehr so sicher, daß das heutzutage überhaupt noch (intern) genutzt wird. Aber es funktioniert zumindest noch ... und zwar bis einschließlich zur 07.29 (getestet mit 7490, weil die gerade da und an war).

---

Ansonsten stehe ich ja vielleicht auch auf dem Schlauch ... im Moment wird ja offenbar auf dem CallMonitor-Port ein eingehender Anruf erkannt.

Wenn man stattdessen einen SIP-Client (konfiguriert für ALLE eingehenden Anrufe) verwenden würde, kriegt man die Signalisierung direkt vom voipd und kann dann - je nach Anrufernummer - den Anruf auch (als SIP-Client) annehmen und wieder auflegen lassen, womit alle anderen Clients dann auch "unbelästigt" bleiben sollten.

Der dazu benötigte SIP-UAC muß ja gar nicht wirklich "das ganze Protokoll" beherrschen - es reicht, wenn er sich registrieren kann (inkl. Renews) und INVITE-Nachrichten auswerten kann. Dann noch - wenn's ein Spam-Anruf ist - das "Annehmen" des Anrufs (das ist ja nur ein "OK" auf das "INVITE" hin) und danach ein passendes "BYE" ... das ist - alles in allem - nur der "Rumpf" eines vollständigen SIP-Clients, weil ja gar kein Media-Handling (angefangen beim Auslesen/Auswerten der SDP-Entries bis zur Auswahl passender Codecs/Endpoints für RTP) benötigt wird.

Oder wo ist da mein "Denkfehler"? Bevor ich mich mit CAPI herumschlagen würde, würde ich persönlich jedenfalls eher auf einen solchen rudimentären SIP-Client setzen - auch wenn das nicht als "Schnittstelle" seitens AVM beschrieben ist, sollte das SIP(rotocol) alles das bieten, was man für diese Aufgabe braucht - nur müßte man halt zusätzlich noch einen passenden Eintrag für ein "Telefoniegerät" anlegen, auf dem dann auch alle eingehenden Anrufe signalisiert werden. Die Tatsache, daß so ein Anruf dann tatsächlich erst einmal angenommen werden muß (inkl. "billing" für den Anrufenden), würde ich eher noch als Bonus denn als Malus sehen - JEDE Reaktion verrät ja, daß die Nummer "gültig" ist. Solange man nicht extern ein 404 oder 410 "forcieren" kann (was m.W. nicht funktioniert, solange die FRITZ!Box sich für eine Nummer "zuständig" fühlt), ist es auch egal, wenn der Anruf angenommen und sofort wieder beendet wird.

 

[Theo Tintensich]

auf ein nicht weiter konfiguriertes S0-Gerät herangezogen

Dieses Telefon muss es geben. Ebenso wie bei VoIP-Ports, an denen sich kein SIP-Client angemeldet hat, bekommt man entweder "Dienst oder Dienstmerkmal nicht möglich" (ISDN) bzw die Meldung, dass die Rufnummern nicht bekannt sei.
Oder, wenn die beteiligten Anlagen das nicht können, ein Besetzt.

Wenn man eine in einer Telefonanlage konfigurierte Nummer anruft, auf die sich kein SIP-Client angemeldet hat, (Besonders bei Fritz!Boxen hat der SIP-Client intern ja eine andere Nummer, die F!B hat sich aber beim Telefonanbieter für diese Nummer angemeldet, ist dort also der angemeldete SIP-Client) dauert es lange, bis ein Anruf auf diese Nummer (bei meinem Test) zu einem Klingelsignal beim Anrufer kommt.

Beim Rückruf konnte ich bei dem auf diese Nummer registrierte Anruf mit der [x]-Taste (Snom-Telefon) das Klingeln für dieses Telefon wegdrücken. Ich habe die anderen Telefon, die auf diese Nummer konfiguriert sind, aber nicht klingel hören. Doch für den Anrufer 'klingelte' es weiter.

 

[Black Senator]

@Kruemelino @PeterPawn @Theo Tintensich

vielen Dank Euch für´s mit reinhängen - leider bin ich mit Euren Idee/Hinweisen noch nicht weitergekommen. Es sind jetzt ja sogar noch mehr lose Enden als vorher:

Daher vielleicht noch einmal der Reihe nach:

Lösungsvorschlag der AVM:

...ein ISDN- oder DECT-Telefon auf "Besetzt bei Besetzt" konfigurieren und dann dort den Ruf abweisen.

Dazu meine Frage ins Forum: was meinen die netten Menschen vom AVM-Entwickler-Support damit?

Die Antwort/Idee dazu von @stsoft

...CapiOverTCP aktivieren und dann per SW virtuell an den ISDN-Bus

löst weitere Fragen aus und bleibt leider auch nicht abschließend beantwortet bzw. nach meinem Verständnis ausdiskutiert/bewertet.

Den Lösungsvorschlag von @Kruemelino verstehe ich ja prinzipiell und kann den auch nachbilden, der Haken liegt dabei aber (wie sowieso schon) bei:

5. ggf. Telefonat beenden (wie?) Wahlregel? Anrufbeantworter?

und bei mir klingelt es - nicht unerwartet - trotzdem weiter.

Die Idee von @PeterPawn

...über den Port 1011 ... AT-Kommandos an den telefon-Daemon ... absetzen

finde ich ja noch am vielversprechensten (das war ja mal der Startpunkt für diesen Thread). Aber über die doppelt Verneinung

Wer sich nicht auf "unmodifizierte Firmware" beschränkt,

grübele ich immer noch. Das heißt dann ja eigentlich: "Wer sich auf "modifizierte Firmware" beschränkt," was irgendwie verwirrend ist, weil kurz danach ja als Alternative genannt wird

Wer es ernst genug meint und auch bereit ist, die Firmware entsprechend zu modifizieren...

Sorry Peter, aber ich konnte dem leider nicht folgen.


Zum Abschluss noch mal kurz mein Test-Setting:

• auf dem S0, sonst physisch ungenutzt, habe ich eine ISDN-Telefonanlage definiert mit Busy on Busy (siehe Empfehlung AVM)
• eine ansonsten ungenutzte MSN habe ich auf eines der FRITZ!Fon gelegt (also "DECT: Obergeschoss", **614)
• zum Test rufe ich dann die o.g. MSN an und starte nach dem ersten Klingeln das jeweils adaptierte PHP-script (MVP), um zu sehen, ob das Klingeln sich abwürgen lässt

Die Frage ist/bleibt:
Wie kann man mit einem externen Programm und nur unter Ausnutzung der AVM-Schnittstellen bzw. FRITZ!Box-Ausprägung eine einfache(sic!) Konstellation schaffen, um einen dezidierten Anruf abzuwürgen?

Grüße

Black Senator

 

[PeterPawn]

Das heißt dann ja eigentlich: "Wer sich auf "modifizierte Firmware" beschränkt,"

Eher nicht ... wenn man sich NICHT auf etwas Bestimmtes BESCHRÄNKT (hier eben auch "unmodifizierte Firmware"), dann hat man auch andere Möglichkeiten ... eben jene, die Firmware zu ändern und damit seinem Ziel einen Schritt näher zu kommen, weil man dann mit AT-Kommandos tatsächlich einen Anruf abwürgen kann. Keine Ahnung, wo ich Dich da "verloren" haben könnte ...

Allerdings paßt das - mit der Notwendigkeit, dafür die Firmware zu modifizieren - dann nicht (mehr) zur Prämisse:

nur unter Ausnutzung der AVM-Schnittstellen

Das mit dem S0-Bus (und in der Folge auch mit DECT-Telefonen, denn die laufen bei AVM ebenso wie ISDN-Geräte, wovon man sich mit dtrace leicht selbst überzeugen kann) kann (nach meiner Ansicht) so auch nicht funktionieren - bei dieser Technologie ist es ja vollkommen NORMAL, wenn sich ein Endgerät nicht angesprochen fühlt von der Signalisierung eines eingehenden Anrufs - sei es, weil das Gerät gar nicht am Bus hängt oder weil es für die signalisierte MSN nicht konfiguriert ist.

Damit dann die "Reaktion" des Endgeräts den Anruf(er) auch wirklich abwürgt (dafür ja das "busy on busy", damit das dann auch zum Anrufer signalisiert wird), müßte man da - als emuliertes ISDN-Endgerät im D-Kanal, also als CAPI-Client, wenn man es über "CAPI over TCP" machen wollte - nach der Entscheidung, den Anruf (der per SETUP-Message von der Box signalisiert wird) nicht haben zu wollen, eine Antwort mit passendem Cause-Code (vermutlich am ehesten "user busy", bei "call rejected" bin ich nicht sicher, wie die AVM-Implementierung reagiert und ob die das nicht nur auf dieses eine Endgerät bezieht) senden.

Da ist also auch nichts mehr mit den TR-064-Funktionen von der Wählhilfe zu machen ... zumindest wüßte ich nicht, wie das gehen sollte. DAS dürfte aber der Weg sein, den AVM da meinte - nur sollte das mit SIP (und "Annehmen + Auflegen") auch eleganter zu lösen sein und sogar an beliebiger Stelle (und nicht nur hinter einer FRITZ!Box) funktionieren, da man dabei nicht länger auf die Ausgaben des Call-Monitors auf Port 1012 angewiesen ist (die Signalisierung kriegt man ja als INVITE "frei Haus" geliefert).

Das heißt, die Option mit dem rudimentären SIP-Client bleibt (nach meiner Ansicht) immer noch offen ... ein einfacher Test, ob das Prinzip funktioniert, läßt sich mit jedem SIP-Client (z.B. Phoner, wenn man Windows verwendet) ausführen. Wenn der Anruf signalisiert wird und NICHT erwünscht ist, einfach abnehmen (lassen) und danach wieder auflegen. Dabei sollten alle anderen Nebenstellen, die den Anruf ebenfalls signalisiert haben, direkt beim Annehmen im SIP-Client auch "verstummen" (ggf. mit kurzer Verzögerung), egal um welche Technologie es sich dabei handelt (POTS, ISDN, DECT, SIP).