Neue BetaFirmware: Telefonate per Lua initiieren, Konfiguration DialPort unklar

[Kruemelino]

Ich habe auf meiner 7390 die letzte Laborfirmware von AVM geladen.

Das Addin für Outlook (Signatur) initiiert Telefonate der Fritz!Box-Wählhilfe direkt per Http POST/GET. Dazu habe ich an die URL http://fritz.box/cgi-bin/webcm per POST die Daten wie Telefonnummer und Dialport gesendet.

Daten: "sid=" & SID & "&getpage=&telcfg:settings/UseClickToDial=1&telcfg:settings/DialPort=" & DialPort & "&telcfg:command/" & "Dial=" & DialCode

Anscheinend hat AVM aufgeräumt, denn ich erhalte nun mit der Labor-Firmware eine Fehlermeldung: (404) Nicht gefunden. - Link: http://fritz.box/cgi-bin/webcm

Mein Anliegen: Nun darf ich das Wählen auf lua umstricken. Ich habe schon herausbekommen, wie ich die Wählhilfe ansteuern kann:

http://fritz.box/home/home.lua?sid=<SID>&query=dial&action=dial&number=<TELNR>

Auf http://www.ip-phone-forum.de/showthread.php?t=241699 hab ich erfahren, dass es einen "dialingport" gibt.

Wenn ich diesen mit

dialingport=<TELNAME>

in den Link einbaue, wird jedoch stets das eingestellte Standard-Wählhilfe-Telefon verwendet und nicht das Telefon, welches im mit dem "dialingport" angesprochen wird, eingefügt ist.

Kann jemand bestätigen, dass der Aufruf von http://fritz.box/cgi-bin/webcm mit der letzten Labor-Firmware ein 404-Error liefert?
Hat jemand schon eine Lösung?
Ist mein Ansatz mit folgendem Link korrekt?
Ist das Schlüsselwort "dialingport" korrekt?

http://fritz.box/home/home.lua?sid=<SID>&query=dial&action=dial&dialingport=<TELNAME>&number=<TELNR>

Wie wäre er korrekt, wenn falsch.

Danke im vorraus

 

[andiling]

Zu webcm: http://www.ip-phone-forum.de/showthread.php?t=279200&page=2

 

[PeterPawn]

"dialingport" ist eine "Übersetzung" der von der Wählhilfe zu verwendenden internen Nummer in einen Anzeigenamen für das Telefoniegerät/die Geräte und nur eine Ausgabe. Dort ist die Wahl des Telefons nicht möglich.

Eine temporäre Änderung des "Wählhilfe"-Telefons ist nicht vorgesehen in der Firmware, es gibt (im Moment) nur zwei Stellen, an denen dieser Parameter gesetzt wird und das sind die beiden Einstellungsdialoge unter /fon_num/dial_fonbook.lua und /fon_num/dial_foncalls.lua. Wenn also ein anderes Telefon verwendet werden soll, muß erst dort (geht auch per Skript, die Parameter kriegst Du aber durch Mitschnitt alleine heraus) die richtige Nummer eingestellt werden, bevor das Wählen gestartet wird.

Nichts anderes machte eigentlich der Aufruf von webcm mit "telcfg:settings/DialPort", aber das Setzen von Einstellungen direkt über URL-Parameter gibt es in dieser Form nicht mehr in aktueller Firmware. Für die Abfrage existiert eine Seite "query.lua", das Pendant zum Setzen fehlt (verständlicherweise) und damit ist man auf den "Mißbrauch" entsprechender GUI-Seiten angewiesen, indem man sich als Browser ausgibt.

Wobei man auch da nicht müde werden sollte zu betonen, daß es auch eine dokumentierte Schnittstelle für das Wählen einer Nummer gibt und es nur wenige Gründe geben dürfte, da auf eine "Browser-Emulation" zu setzen. Wenn die bei der nächsten Änderung durch AVM wieder nicht funktioniert, trägt man selbst die Schuld ... bei einer dokumentierten Schnittstelle kann man dem Hersteller eine größere Hemmschwelle für grundlegende Änderungen unterstellen.

 

[Kruemelino]

Danke für die Antworten,

ich habe dies bereits vermutet. Danke auch für den Hinweis, mit der Schnittstelle. Zwar werd ich noch nicht schlau daraus und weiß auch nicht wo ich beginnen soll, aber das wird schon werden.

 

[PeterPawn]

Zwar werd ich noch nicht schlau daraus und weiß auch nicht wo ich beginnen soll

Die Funktionen (TR-064 allgemein setze ich mal voraus, ansonsten gab es z.B. in der letzten c't-Aktion zur FRITZ!Box Beispiele dafür) heißen:

X_AVM-DE_DialGetConfig
X_AVM-DE_DialSetConfig
X_AVM-DE_DialNumber
X_AVM-DE_Hangup
X_AVM-DE_GetPhonePort
X_AVM-DE_GetNumberOfClients
X_AVM-DE_GetClient2

Da dort die "Clients" (das sind die Telefone) über ihren Namen identifiziert werden, muß man halt ggf. vorher die vorhandenen Telefoniegeräte einmal abrufen, die Zuordnung der internen Rufnummer zum Namen sollte mit GetPhonePort funktionieren.

Ich habe allerdings in aktueller Firmware noch nicht selbst die Funktionen erneut getestet, es wäre also auch denkbar, daß AVM da etwas geändert hat und es noch nicht für die Releases entsprechend dokumentiert ist.

Bei der 06.29 kamen irgendwie zwei Schnittstellen dazu (bei 06.25 - die lag ja zeitlich tatsächlich später - habe ich das noch nicht untersucht), die auch noch nirgendwo bei AVM dokumentiert waren und es gab auch diverse Änderungen an anderen, wenn ich mich richtig erinnere. Wenn Du das selbst checken willst, brauchst Du Dir nur die SCPD-Definitionen aus der ausgepackten Firmware ansehen und die für verschiedene Firmware-Versionen vergleichen.

# find /etc/default.$CONFIG_PRODUKT/$OEM/*SCPD*.xml
/etc/default.Fritz_Box_HW185/avm/avm-ahaSCPD.xml
/etc/default.Fritz_Box_HW185/avm/deviceconfigSCPD.xml
/etc/default.Fritz_Box_HW185/avm/deviceinfoSCPD.xml
/etc/default.Fritz_Box_HW185/avm/ethifconfigSCPD.xml
/etc/default.Fritz_Box_HW185/avm/fboxSCPD.xml
/etc/default.Fritz_Box_HW185/avm/hostsSCPD.xml
/etc/default.Fritz_Box_HW185/avm/igdconnSCPD.xml
/etc/default.Fritz_Box_HW185/avm/igddslSCPD.xml
/etc/default.Fritz_Box_HW185/avm/igdicfgSCPD.xml
/etc/default.Fritz_Box_HW185/avm/l2tpv3SCPD.xml
/etc/default.Fritz_Box_HW185/avm/lanconfigsecuritySCPD.xml
/etc/default.Fritz_Box_HW185/avm/lanhostconfigmgmSCPD.xml
/etc/default.Fritz_Box_HW185/avm/layer3forwardingSCPD.xml
/etc/default.Fritz_Box_HW185/avm/mgmsrvSCPD.xml
/etc/default.Fritz_Box_HW185/avm/timeSCPD.xml
/etc/default.Fritz_Box_HW185/avm/usbSCPD.xml
/etc/default.Fritz_Box_HW185/avm/userifSCPD.xml
/etc/default.Fritz_Box_HW185/avm/wancommonifconfigSCPD.xml
/etc/default.Fritz_Box_HW185/avm/wandslifconfigSCPD.xml
/etc/default.Fritz_Box_HW185/avm/wandsllinkconfigSCPD.xml
/etc/default.Fritz_Box_HW185/avm/wanethlinkconfigSCPD.xml
/etc/default.Fritz_Box_HW185/avm/wanipconnSCPD.xml
/etc/default.Fritz_Box_HW185/avm/wanpppconnSCPD.xml
/etc/default.Fritz_Box_HW185/avm/wlanconfigSCPD.xml
/etc/default.Fritz_Box_HW185/avm/x_contactSCPD.xml
/etc/default.Fritz_Box_HW185/avm/x_myfritzSCPD.xml
/etc/default.Fritz_Box_HW185/avm/x_remoteSCPD.xml
/etc/default.Fritz_Box_HW185/avm/x_storageSCPD.xml
/etc/default.Fritz_Box_HW185/avm/x_tamSCPD.xml
/etc/default.Fritz_Box_HW185/avm/x_upnpSCPD.xml
/etc/default.Fritz_Box_HW185/avm/x_voipSCPD.xml
/etc/default.Fritz_Box_HW185/avm/x_webdavSCPD.xml

aus einer 113.06.24.

 

[koyaanisqatsi]

Moins

Danke PeterPawn das du dass mal gepostet hast, denn die XML lassen sich auch gemütlich im Webbrowser schmökern.
Einfach die HTML als fb_upnp.html auf dem Desktop abspeichern und: Klicken und Schmökern

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<base href="http://fritz.box:49000/" target="_blank" />
<meta name="author" content="koyaanisqatsi">
<title>UPnP/TR-064</title>
</head>
<body>
<a href="avm-ahaSCPD.xml">avm-ahaSCPD.xml</a>
<br/>
<a href="deviceconfigSCPD.xml">deviceconfigSCPD.xml</a>
<br/>
<a href="deviceinfoSCPD.xml">deviceinfoSCPD.xml</a>
<br/>
<a href="ethifconfigSCPD.xml">ethifconfigSCPD.xml</a>
<br/>
<a href="fboxSCPD.xml">fboxSCPD.xml</a>
<br/>
<a href="hostsSCPD.xml">hostsSCPD.xml</a>
<br/>
<a href="igdconnSCPD.xml">igdconnSCPD.xml</a>
<br/>
<a href="igddslSCPD.xml">igddslSCPD.xml</a>
<br/>
<a href="igdicfgSCPD.xml">igdicfgSCPD.xml</a>
<br/>
<a href="l2tpv3SCPD.xml">l2tpv3SCPD.xml</a>
<br/>
<a href="lanconfigsecuritySCPD.xml">lanconfigsecuritySCPD.xml</a>
<br/>
<a href="lanhostconfigmgmSCPD.xml">lanhostconfigmgmSCPD.xml</a>
<br/>
<a href="layer3forwardingSCPD.xml">layer3forwardingSCPD.xml</a>
<br/>
<a href="mgmsrvSCPD.xml">mgmsrvSCPD.xml</a>
<br/>
<a href="timeSCPD.xml">timeSCPD.xml</a>
<br/>
<a href="usbSCPD.xml">usbSCPD.xml</a>
<br/>
<a href="userifSCPD.xml">userifSCPD.xml</a>
<br/>
<a href="wancommonifconfigSCPD.xml">wancommonifconfigSCPD.xml</a>
<br/>
<a href="wandslifconfigSCPD.xml">wandslifconfigSCPD.xml</a>
<br/>
<a href="wandsllinkconfigSCPD.xml">wandsllinkconfigSCPD.xml</a>
<br/>
<a href="wanethlinkconfigSCPD.xml">wanethlinkconfigSCPD.xml</a>
<br/>
<a href="wanipconnSCPD.xml">wanipconnSCPD.xml</a>
<br/>
<a href="wanpppconnSCPD.xml">wanpppconnSCPD.xml</a>
<br/>
<a href="wlanconfigSCPD.xml">wlanconfigSCPD.xml</a>
<br/>
<a href="x_contactSCPD.xml">x_contactSCPD.xml</a>
<br/>
<a href="x_myfritzSCPD.xml">x_myfritzSCPD.xml</a>
<br/>
<a href="x_remoteSCPD.xml">x_remoteSCPD.xml</a>
<br/>
<a href="x_storageSCPD.xml">x_storageSCPD.xml</a>
<br/>
<a href="x_tamSCPD.xml">x_tamSCPD.xml</a>
<br/>
<a href="x_upnpSCPD.xml">x_upnpSCPD.xml</a>
<br/>
<a href="x_voipSCPD.xml">x_voipSCPD.xml</a>
<br/>
<a href="x_webdavSCPD.xml">x_webdavSCPD.xml</a>
</body>
</html>

Auf die Art kann bei einer Änderung flexibel reagiert werden.
Wie schonmal passiert: upnp <--> igdupnp

Ach, ja, diese Listen bekommt man ganz ohne: Login

 

[PeterPawn]

Kleiner Tipp noch zur Datei ... wenn Du den Host einmal im Kopf der Datei definierst (mit einem BASE-Tag), dann kann auch jemand, bei dem die Box nicht "fritz.box" heißt (und auch nicht der DNS-Server ist, denn dann würde die Auflösung als lokale Domain ja trotzdem funktionieren, wie Du erst letztens festgestellt hast), das mit einer einzelnen Änderung verwenden, was jetzt mit einem ordentlichen Editor mit "global change" zwar auch geht, das aber nicht übersichtlicher macht - speziell beim Vergleich mehrerer Boxen/Firmware-Versionen.

Ein ähnlicher Ansatz (als Powershell-Skript) war glaube ich auch in der c't bei der letzten größeren FRITZ!Box-Aktion enthalten, da wurde dann gleich noch auf die entsprechende PDF-Datei bei AVM mit der Schnittstellendefinition verlinkt - wobei es nicht für jede SCPD-Datei auch die passende PDF-Datei geben muß, da sollte man also ggf. beim "Generieren" das Ziel des Links noch prüfen.

 

[koyaanisqatsi]

Hast Recht, bei abweichenden Namen reicht es dann das <base href=""> Attribut zu Ändern.
...im Post korrigiert.

 

[Kruemelino]

Nochmal Danke für die Hilfe. Und ersten Tipps.
Ich werde jetzt erst mal laufen lernen müssen. Das heißt ganze Klassen und Routinen dafür zusammenstellen.

Hab ich das richtig verstanden, dass ich für jeden Zugriff und Abfrage eine XML-Datei erzeugen muss, diese an die Box per GET/POST (?) senden muss, und die antwort auswerten darf?

(Ganz schön viele Berliner hier. Ich bin schockiert. 20. Juni 12,4°C und Regen)

 

[koyaanisqatsi]

Yup, jetzt regnets auch in Neukölln. :mrgreen:

Ich geb dir mal ein Beispiel als curl Shellskript, moment...
ForceTermination.sh

#!/bin/sh
curl "http://fritz.box:49000/igdupnp/control/WANIPConn1" -H "Content-Type: text/xml; charset="utf-8"" -H "SoapAction:urn:schemas-upnp-org:service:WANIPConnection:1#ForceTermination" -d "<?xml version='1.0' encoding='utf-8'?> <s:Envelope s:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'> <s:Body> <u:ForceTermination xmlns:u='urn:schemas-upnp-org:service:WANIPConnection:1' /> </s:Body> </s:Envelope>"
#EOF

Also, ein XML SOAP Request muss in XML eingetütet (Envelope) werden.

Aber, da der meist gleich bleibt, auch als Template konstruibar.

PS: Dieses SOAP benötigt kein Login

 

[PeterPawn]

Hab ich das richtig verstanden, dass ich für jeden Zugriff und Abfrage eine XML-Datei erzeugen muss, diese an die Box per GET/POST (?) senden muss, und die antwort auswerten darf?

Als "low level API" schon, aber es gibt bestimmt in den Weiten des Internets auch eine entsprechende Bibliothek. Die der Schnittstelle zugrunde liegende Philosophie ist ja SOAP, da muß man das Rad kein weiteres Mal erfinden.

Ich bin schockiert.

Vom Wetter? Oder davon, daß von den vielen Bewohnern unserer Stadt auch viele hier im IPPF sind? Das dürfte relativ zur Bevölkerungsdichte/Einwohnerzahl trotzdem nur ein hinterer Platz werden, wenn man mal die AVM-Mitarbeiter, die das beruflich vielleicht lesen müssen, nicht berücksichtigt.

EDIT: Nochmal zur SOAP-Schnittstelle ... ich weiß ja nicht, womit Du da programmieren willst, aber ich erwähne es trotzdem einfach mal, daß man in aller Regel mit entsprechenden SOAP-Schnittstellenbeschreibungen ganz einfach die dort exportierten Funktionen in .NET-Programmen importieren kann (ist am Ende nichts anderes als ein Webservice) und dann reduziert sich der Aufwand auf den Aufruf einer Funktion (mit ein paar Zeilen Fehlerbehandlung, wenn man es ordentlich machen will).

 

[koyaanisqatsi]

AVM? Wenn sie schlau sind lesen sie mit, aber ich hab hier von denen noch nie was gesehn.
Da ist SNOM deutlich präsenter.

 

[PeterPawn]

aber ich hab hier von denen noch nie was gesehn.

Ich habe auch von "lesen" geschrieben, nicht von "schreiben". Das wäre dann vermutlich wieder zu viel Aufmerksamkeit/Unterstützung für die "Fan-Community" und die "social media"-Verantwortlichen sind ja offenbar auf anderen Plattformen präsent.

Ich warte ja auf den Tag, wo die AVM-Seite auch einen Like-Button für oder einen Link zur IPPF-Startseite (bzw. eher noch zur Freetz-Domain) enthält ... das ist dann ein guter Tag und man könnte dann annehmen, daß AVM sich wirklich "freut", wenn jemand ihre Boxen "aufbohrt" und es nicht nur still duldet, weil der Kampf dagegen i.d.R. ohnehin aussichtslos ist.

 

[Kruemelino]

Vom Wetter

Ja klar gibt es sicher was. Ich bau mir aber immer lieber selber was. Dann weiß ich wie, was funktioniert. Und wenn was schief geht, kenne ich den schuldigen (MICH) und weiß wo ich suchen muss. Ist halt so ein persönliches Ding. Ich will wissen, was mein Code macht und was nicht. (Ein weiterer Punkt: Wenn ich eine externe Bibliothek einbinde, hab ich immer das "Problem" der Lizenz.)

Ja es soll .Net werden. Da gibt es auch etwas, hab ich schon gesehen. Muss mal die Doku lesen.

 

[koyaanisqatsi]

:doktor:

Ähem, SOAP geht auch mit .vbs

FB-WAN-IP.vbs (von Pikachu)

' 24.06.2013
' FB-WAN-IP.vbs 
' wscript.exe muss in Windows vorhanden sein
'
 Option Explicit
'
 Dim WshShell, http, page, host, post, soap, sXML
 Dim new_ip
 Dim objResultXMLDoc
 Dim v1, v2
'
' sXML = ""
 sXML =        "<?xml version=" + chr(34) + "1.0" + chr(34) + "?>" + vbCRLF
 sXML = sXML + "<s:Envelope xmlns:s=" + chr(34) + "http://schemas.xmlsoap.org/soap/envelope/" + chr(34) + " s:encodingStyle=" + chr(34) + "http://schemas.xmlsoap.org/soap/encoding/" + chr(34) + ">" + vbCRLF
 sXML = sXML +  "<s:Body>" + vbCRLF
 sXML = sXML +   "<u:GetExternalIPAddressResponse xmlns:u=" + chr(34) + "urn:schemas-upnp-org:service:WANIPConnection:1" + chr(34) + ">" + vbCRLF
 sXML = sXML +    "<NewExternalIPAddress></NewExternalIPAddress>" + vbCRLF
 sXML = sXML +   "</u:GetExternalIPAddressResponse>" + vbCRLF
 sXML = sXML +  "</s:Body>" + vbCRLF
 sXML = sXML + "</s:Envelope>" + vbCRLF
'
 host = "fritz.box" ' "192.168.178.1" ' FB IP Adresse
 page = "http://" + host + ":49000/igdupnp/control/WANIPConn1" ' UPNP Soap Url
 post = sXML ' XML Daten
 soap = "urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress"
'
'
 Set WshShell = CreateObject("WScript.Shell")
'
'
 Set http = Nothing
 Set http = CreateObject("WinHttp.WinHttpRequest.5.1")
'
 If http Is Nothing Then Set http = CreateObject("WinHttp.WinHttpRequest.5")
 If http Is Nothing Then Set http = CreateObject("WinHttp.WinHttpRequest")
 If http Is Nothing Then Set http = CreateObject("MSXML2.ServerXMLHTTP")
 If http Is Nothing Then Set http = CreateObject("Microsoft.XMLHTTP")
'
 If http Is Nothing Then
  MsgBox "Kein HTTP-Objekt verfügbar!", 16, "Fehler:"
 Else
'
  new_ip = SendPostSoap(http, page, host, post, Soap)
'
'  WScript.Echo new_ip
'
  Set objResultXMLDoc = Nothing
  Set objResultXMLDoc = CreateObject("Msxml2.DOMDocument")
'
' -- Load the response XML document into DOM
  objResultXMLDoc.loadXML(new_ip)
'
' -- Save the response to 'result.xml'
'  v1 = "result.xml"
'  objResultXMLDoc.save(v1) 
'
  v1 = "//u:GetExternalIPAddressResponse/NewExternalIPAddress"
  v2 = 0
  new_ip = objResultXMLDoc.selectNodes(v1).ITEM(v2).TEXT
'
'  WScript.Echo new_ip
'
  DIM objFSO, file, FileName 
'
  FileName = "FB-WAN-IP.log"
'
    If new_ip > 0 Then
     Set objFSO = CreateObject("Scripting.FileSystemObject")
     Set file = objFSO.OpenTextFile(FileName, 2, true) ' Write
'     Set file = objFSO.OpenTextFile(FileName, 8, true) ' Append
'     file.WriteLine(new_ip) ' für Append
     file.Write(new_ip) ' für Write
     file.Close
     Set objFSO = Nothing
'
    End If
'
 END IF
'
'
 Set WshShell = nothing
 Set http = Nothing
 Set objResultXMLDoc = Nothing
'
 WScript.Quit
'
'
Public Function SendPostSoap(http, page, host, post, soap)
 With http
  .Open "POST", page, false
  .setRequestHeader "HOST", host
  .setRequestHeader "Connection", "Keep-Alive"
  .setRequestHeader "Content-Type", "text/xml; charset=UTF-8"
  .setRequestHeader "Content-Length", Len(post)
  .setRequestHeader "SoapAction", soap
  .Send post
 End With
 SendPostSoap = http.responseText
End Function
'
'

 

[Kruemelino]

So 00:30 eine einfache Abfrage nach dem "GetSecurityPort" hab ich durchgeführt. Hat funktioniert. Die nächsten Tage muss ich mich in die muss ich mich noch in die Authentication einlesen. Dann irgendwann hab ich vielleicht Zugriff auf, das was ich will.

Danke nochmal

Ich bin platt...

 

[koyaanisqatsi]

Moins

Wofür hast du dich denn jetzt entschieden? .NET oder VBS?
Außerdem, wenn du "introvertiert" skriptest, hast nur du was davon.

Stell dir mal (kurz) vor, es gibt keine Beispiele mehr, sondern nur noch die Theorien, wie was gehen könnte.

 

[Kruemelino]

Sorry, dass ich mein Code noch nicht veröffentlicht habe.
Das bestehende Addin: http://www.ip-phone-forum.de/showthread.php?t=237086 gibt es schon. Es basiert auf vb.net, daher wird es .NET.
Den Code zum Addin gibt es auf Github und dort für jeden einsehbar. Meine aktuelle Arbeitsversion zum dieser Baustelle noch nicht, da sie nicht vollständig funktioniert.
Was bis jetzt geht:

• Auslesen der tr64desc.xml um alle verfügbaren XML zu ermitteln.
• Ermittlung von "serviceType", "serviceId", "controlURL", "eventSubURL", "SCPDURL" zur späteren Verwendung.
• Ermitteln aller in XML erhaltenen "Actions"zum späteren Abgleich, ob die auzuführende Action überhaupt exsisiert.
• Für jede "Action": Ermittlung der zugehörigen Argumente, sowohl einbehend als auch ausgehend auch zum Check, ob sie vorhanden sind.
• Authentifizierung über den Fritz!Box UserName und zugehörigem Passwort
• Einfache Abfragen wie: GetSecurityPort, GetVoIPCommonAreaCode, GetCallList
• Abfragen über https

Was bis jetzt nicht geht geht:

• Übergabe von Eingabedaten (IN)
• Vermeintlich einfache Abfragen wie: GetPhonebookList/GetPhonebook (Da mach irgendwas falsch, ich seh aber den Fehler momentan nicht.)
• Diverse Checks auf Eingabefehler
• der Rest
• Dokumentation

Ich verwende meine eigenen Routinen, für das XML-Handling. Wie oben beschrieben, ich schreib mir das lieber selbst, dann weiß ich dass sie funktionieren.

Falls du was bestimmtes brauchst, frag mich einfach. Ich stelle meinen Code immer zur Verfügung, und bin bereit zu teilen.


Edit:

So nun mein seltsames Problem. Ich erhalte bei GetPhonebook ein 500-Fehler. Ich seh aber die Ursache nicht. Bin ich blind? was soll ich prüfen

Method: POST
SOAPACTION: "urn:dslforum-org:service:X_AVM-DE_OnTel:1#GetPhonebook"
ContentType: text/xml; charset="utf-8"
UserAgent: AVM UPnP/1.0 Client 1.0
ContentLength: 402

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetPhonebook xmlns:u="urn:dslforum-org:service:X_AVM-DE_OnTel:1">
<NewPhonebookID>0</NewPhonebookID>
<password>Passwort</password>
<login>UserName</login>
</u:GetPhonebook>
</s:Body>
</s:Envelope>

GetPhoneBook
Im Vergleich zum c't-Artikel fallen einige Unterschiede auf: "GetPhoneBook" vs. "GetPhonebook". Daran liegt es aber nicht. Hab ich geprüft. Andere Abfragen, bei denen man ein Login braucht funktionieren.

 

[PeterPawn]

was soll ich prüfen

Ist dieser Aufruf "von Hand" kodiert oder resultiert der aus irgendeiner Schnittstellen-Definition per SCPD-Datei?

Wenn es das hier beschriebene GetPhonebook (S. 5) sein soll, stimmt die Parameterliste nicht (jedenfalls nicht nach der verlinkten Spezifikation). Diese Funktion dient dazu, eine URL zum Download eines XML-formatierten Telefonbuchs aus der FRITZ!Box zu ermitteln, diese ist dann wieder als "normaler HTTPS-Download" aufzurufen und liefert das angeforderte Telefonbuch (optional mit der Möglichkeit, es nur dann auszugeben, wenn es nach einem definierten Zeitpunkt geändert wurde). Dabei muß man dann selbst einen "sid"-Parameter zu der URL hinzufügen, über den die Authentifizierung für diesen Download erfolgt. Es gibt auch irgendwo eine TR-064-Funktion, um eine solche SID mit korrekten Credentials zu erhalten, diese Sitzung wird dann im ctlmgr-Sessioncache als "TR064" gekennzeichnet (Blick in die Supportdaten) und man kann diese SID mehrfach verwenden, solange sie nicht abgelaufen ist, was sie nur nach 3600 Sekunden ohne Request mit dieser SID (oder einer erfolgreichen Abmeldung, wobei ich im Moment gar nicht genau weiß, ob es auch ein TR-064-"Logoff" gibt) sein würde. Eine erfolgreiche TR-064-Anmeldung wird vom FRITZ!OS auch im Eventlog vermerkt - als "App"-Anmeldung.
EDIT: Falls das mit dem Vermerk im Eventlog nicht so richtig im Zusammenhang erscheint ... damit wollte ich darauf aufmerksam machen, daß es von Vorteil ist, wenn man diese SID irgendwo cached und nicht für jeden Zugriff eine neue erzeugt, da dann - je nach der Frequenz der Zugriffe - das AVM-Eventlog "zugemüllt" wird und man mit der (täglichen/wöchentlichen) Status-Mail nur noch nicht-relevanten Unsinn im Eventlog erhält.

Die Authentifizierung für so einen SOAP-Request sollte (meines Wissens) auf der Transportebene erfolgen, damit haben Parameter wie "login" und "password" als Inhalt des Requests nur dann einen Sinn, wenn sie zu der Parameterliste der aufgerufenen Funktion gehören.

Wenn es ein anderer Namespace ist (ich weiß nicht, worauf Du Dich bei dem c't-Verweis beziehst - lese jetzt aber den Artikel deshalb auch nicht), wäre die Angabe, was da eigentlich die Basis (Namensraum/Schnittstelle) ist, hilfreich ...

Wenn Du tatsächlich mit .NET programmierst, solltest Du vielleicht noch einmal über einen dynamischen Import einer Webservice-Definition nachdenken ... das ist ja immer noch "eigene Routinen" (das .NET-Framework wirst Du ja nicht auch noch selbst implementieren wollen mit den dort vorhandenen - höher abstrahierten - Klassen) und es erspart einiges an Aufwand, wenn man einfach für so einen Service ein Objekt erhält, dessen Methoden man mit einem Enumeration-Aufruf "abklappern" kann, um sich dort die richtige herauszusuchen. Die ganze Arbeit des Generierens eines passenden Wrapper-Objekts nimmt Dir die Runtime ab ... es ist halt der Umgang mit einem dynamnisch erzeugten Service-Objekt, der ggf. ein anderes Herangehen erfordert.

Aber da würde ich einen Layer zwischen dem Webservice-Objekt und meinem eigenen (vorhandenen) Code programmieren, der die von mir benötigten Funktionen auf die entsprechenden Webservice-Methoden abbildet. Wenn also Dein Addin (ich habe mir das Repository noch nicht angesehen) eine Funktion "LeseTelefonbuch" benötigt, dann ruft man diese Funktion des Layers(/Wrappers/wie auch immer) auf und der kümmert sich dann um die Umsetzung in die "boxspezifischen" Funktionen. So hat man auch gleich noch eine Möglichkeit, auf unterschiedliche Firmware-Stände (damit ggf. unterschiedlichen TR-064-Umfang) und unterschiedliche Modelle (auch hier ggf. wieder mit unterschiedlichem Umfang an bereitgestellten/funktionierenden Schnittstellen, schon aufgrund abweichender Hardware-Ausstattung) zu reagieren und den "eigentlichen Code" des Addins von solchen Spezialitäten weitgehend zu trennen. Wenn Du das tatsächlich schon so machen solltest, wäre mal eine Interface-Definition dieses Wrappers schön zu lesen. Wenn man das als ordentliches Interface implementiert und Du das unter eine entsprechende Lizenz stellst, kann das ja ein anderer praktisch ohne Änderungen wiederverwenden - z.B. auch aus der PowerShell heraus, wenn er kein Outlook benutzen will/muß/darf/kann. Und eine .NET-Klasse, die durch einfachen Methodenaufruf (ggf. auch mehrere Aufrufe, je nach Interface) eine Telefonverbindung herstellen kann, können garantiert viele andere Projekte auch brauchen ...

 

[Kruemelino]

Du schreibst aber viel


Ich denke, ich mache bereits das was du vorschlägst. Ich baue mir eine Klasse, mit der ich die ganze Kommunikation mit der Box erschlage. D. h. am Ende möchte ich der Klasse sagen, was ich tun will, die Klasse liefert die Argumentliste dazugehörige. Danach werden die Argumente in die Liste gefüllt und an die Klasse zurückgeliefert. Danach erfolgt der eigentliche Aufruf an die Box. Die Rückgabedaten werden dann an die eigentlich rufende Klasse zurückgegeben. So mein Plan.


Also nein, dieser Aufruf wurde neu aus der Spezifikation erstellt. Die Daten werden nicht Hardcoded in Variablen hinterlegt. Ich generiere mir den XML-Teil je nach Abfrage neu. So dabei scheine ich vorgestern Nacht einen Fehler gemacht zu haben.


Ich bin schon so weit, mit meiner Erkentnis, dass jedee Aufruf an die Box schief geht, wenn ich eine Argument übergeben will. Also die Argumente mit der Direction "in". Jeder Aufruf, der nur Rückgabeargumente enthält (out) funktioniert. Auch das Login in die Box funktioniert da. Ich erhalte z.B. bei GetCallList einen Link mit SessionID zum herunterladen der Daten.


Ich ahne meinen Fehler, ich darf nicht nur die "in"-Argumente in die XML-Überführen sondern muss auch stets die "out"-Argumente senden? Wie wäre denn die Argumentliste korrekt?


Zum Login:
Wenn ich die Spezifikation richtig gelesen haben muss es einen Logout geben. Ich weiß momentan nicht, wie und wo. Das Login auf Basis der TR-064 will ich später nachziehen. Eine Baustelle nach der anderen.


Na klar, kann das am Ende in einer .NET-Klasse resultieren, die andere auch verwenden können. Ich hab jetzt sowieso Lust darauf bekommen.
Bis dahin lerne ich aber mal das laufen und mach ein Schritt nach dem anderen. Ich bin auch kein Profi und hab mir mein Wissen selbst erarbeitet. Meine Lösungen sind sicher so, dass andere die Hände über den Kopf zerschlagen und sich denken, was macht der da für ein Mist.