![]() |
WebServices - Discovery: Hello, Probe, Bye ......
Ich versuche mich noch immer an ONVIF-tauglichen IP/WLAN-Kameras - deren Erkennung zunächst (dann auch auslesen und steuern).
Suche/Lese seit einigen Tagen das WWW rauf und runter, finde aber nichts wirklich gescheites für "Dummies", die das noch nie gemacht haben. Der ONVIF-Application-Programmers-Guide (hier frei ladbar: ![]() ist zwar recht gut les- und interpretierbar (Programmneutral) und ich bin im groben dabei, das ganze nach Delphi zu portieren. Probleme beginnen jedoch schon im Kapitel 4: Wie erkenne ich die Kamera('s) im Netz ? Dieses "Dicovery" scheint WSDL-unabhängig zu sein und ist offensichtlich dur MS definiert. Siehe hier: ![]() (Sehr wahrscheinlich) Bin ich zu blöd zum suchen ...!? Finde nix gescheites in Bezug auf Delphi, was mir als NewBy in diesem Bereich ein AHA-Erlebnis aus irgendwelchen Beschreibungen oder Code bringen würde. Div. TUT's zu WebServices haben da auch nicht wirklich weitergeholfen .... Was braucht's da an vorhandenen Packages / Klassen ? Ist eine spezielle "WSAPI" erforderlich ? HILFE .... BITTE ! Ergänzung: Was kann man hiermit (ONVIF-Prog-Guide s.o. - ab Seite 110) anfangen ? Zitat:
Code:
.... noch ne Ergänzung:
<?xml version="1.0" encoding="UTF-8"?>
<e:Envelope xmlns:e="http://www.w3.org/2003/05/soap-envelope" xmlns:w="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:dn="http://www.onvif.org/ver10/network/wsdl"> <e:Header> <w:MessageID>uuid:84ede3de-7dec-11d0-c360-f01234567890</w:MessageID> <w:To e:mustUnderstand="true">urn:schemas-xmlsoap-org:ws:2005:04:discovery</w:To> <w:Action a:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</w:Action> </e:Header> <e:Body> <d:Probe> <d:Types>dn:NetworkVideoTransmitter</d:Types> </d:Probe> </e:Body> </e:Envelope> Bei MS (siehe Link oben zu Discovery) sieht das dann so aus:
Code:
.... fehlt da nicht was ? ? ? Zunmindestens das Ende von "Envelope"
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof"> <soap:Header> <wsa:To> urn:schemas-xmlsoap-org:ws:2005:04:discovery </wsa:To> <wsa:Action> http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe </wsa:Action> <wsa:MessageID> urn:uuid:29cf10da-5c41-4d55-b184-5ee15e38ce23 </wsa:MessageID> </soap:Header> <soap:Body> <wsd:Probe> <wsd:Types>wsdp:Device</wsd:Types> </wsd:Probe> </soap:Body> Dinge zu ONVIF stehen hier nicht drin - Systembedingt. |
AW: WebServices - Discovery: Hello, Probe, Bye ......
.... Hallooooo ? Niemand hier im Forum, der schon mal mit so was "rumgemacht" hat ?
|
AW: WebServices - Discovery: Hello, Probe, Bye ......
Die SOAP-Erweiterungen Discovery etc. werden von Delphi nicht unterstützt. Es wäre sehr viel Fleißarbeit diese selber zu programmieren.
Machbar wäre: ein Delphi Programm mit einem C# Programm (das den Web Service Client enthält) kommunizieren lassen. Das C# Programm leitet die Daten dann nur weiter, wie ein Proxy oder 'Übersetzer'. |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Danke dir für die Antwort !
Fleissarbeit ? Das ist nun wirklich das allerletzte, kleinste Problem .... mache ich gerne. Problem ist / wäre hier auch noch zu wissen, wie man / ich denn so einen "Seifenschaum" in das Indernet - hier an die Kameras portiert bekommt. Bietet Delphi da wenigsstens was elementares ? Ich find da nix wirklich zu ..... Leider bin ich (NOCH !) Total-Dummy zu diesem Thema. |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Zitat:
|
AW: WebServices - Discovery: Hello, Probe, Bye ......
Danke dir nochmals für Antwort !
Selbstverständlich ist der Aufwand nicht gering ... Als etwas älterer Herr, welcher seiner ehemaligen Arbeit nicht mehr wirklich nachkommen kann und der zu Hause programmier- und hardwareseitig allerlei Dinge gerne in der vielen Freizeit ausprobiert, stellt das nicht wirklich ein Problem dar ! Das Prob ist hierbei eher die Frage, wie der alte Sack, der mit TurboPascal aus den Kinder-/Schultagen vor mehr als 30 Jahren angefangen hat, minimal vorhandenen, kryptischen C-Mist in gescheiten Delphi-Code wandeln kann ... nein das will ich mir nicht unbedingt antun. Logo kann ich mittlerweile auch C-Code lesen, aber ich weiß dennoch nicht immer, was da hinten im entsprechenden Compiler mit dort eingebauten "Packackes" u.a. ab geht. Sprich: Die paar Zeilen verfügbarer "Elementar-Code" ist noch lange kein brauchbares Proggy zum mal eben übersetzen. Müsste also schon mal hier nicht nur ein Wissender sprachenübergreifend etwas hilfreich tätig werden. Gibbet echt was, was Delphi nicht kann ? In diesem Fall wie du schreibst KEINE (!) SOAP-Erweiterungen zu Discovery u.a.ö.ä ??? Das wäre extremst erschreckend und würde alle eingefleischten Delphianer doch bis auf die Knochen blamieren. ..... ich habe mich vor vielen Jahren z.B. auch mit DirectX/DirectShow sehr schwer getan. Die Anwendung des sehr genialen DSPacks hat auch erst nach Zeiten Wunder gewirkt - das geht hier heute "on the fly". ..... also warum nicht noch mal mit der "Discovery von WS u. a." anfangen ? .... "eben mal schnell" nen API-Wrapper gebastelt .... (Ähemm :)) Ich hab Zeit, mich hetzt keiner - außer ich mich selbst. .... bin mir aber sehr, sehr sicher, dass da schon viele Delphianer am Start gewesen waren / immer sind und auch was passendes gecodet haben. Fragt sich nur, wo sich da was passendes findet. |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Liste der Anhänge anzeigen (Anzahl: 1)
Hab noch mal ein wenig rumgelesen...
Billy Boy Gates lässt hier ![]() schreiben: A Probe message is a WS-Discovery message used by a client to search for services on the network by service type. For more information about Probe messages, see section 5.2 of the WS-Discovery Specification. A Probe message is sent by UDP multicast to port 3702. Unicast Probe messages are not supported. DPWS clients send Probe messages. The following list shows scenarios in which WSDAPI will send a Probe message. Im oben benannten PDF ![]() findet man auf Seite 4/5 entsprechendes wieder: ... Probe message multicast by a Client searching for ... (dort Drucker) Because there is no explicit ReplyTo SOAP header block [WS-Addressing], any response to this Probe will be sent as a UDP packet to the source IP address and port of the Probe transport header [SOAP/UDP]. Lt. dem Beispiel im ONVIF-Progger-Handbuch (link dazu weiter oben) und Wiki's ist die Multicast-Adresse 239.255.255.250 Als Port bei MS als auch bei ONVIF ist 3207 angegeben. Nach sehr vielen Jahren hab ich wieder INDY in der letzten Version Indy10_5339 auf das Delphi 7 gepackt, reichlich aus dem Netz abgeguckt betreff UDP und was mit UDPClient/-Server gebastelt. (Grausig, warum es so viele Unterschiede von Indy 9 nach 10 bei den Demos gibt ...)
Code:
Prinzipiell müsste das meiner bescheidenen Meinung nach funktionieren.
unit TestUnit2;
interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, IdUDPBase, IdUDPServer, IdBaseComponent, IdComponent, IdGlobal, IdSocketHandle, IdUDPClient, IdStack; type TForm1 = class(TForm) Memo1: TMemo; Label1: TLabel; EditHost: TEdit; Label2: TLabel; EditPort: TEdit; UDPServer: TIdUDPServer; Button1: TButton; UDPClient: TIdUDPClient; procedure UDPServerUDPRead(AThread: TIdUDPListenerThread; const AData: TIdBytes; ABinding: TIdSocketHandle); procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} // http://stackoverflow.com/questions/15741862/delphi-xe2-indy10-udp-client-server-interchange-using-sendbuffer-receivebuffer // ----------------------------------------------------------------------------- procedure TForm1.UDPServerUDPRead(AThread: TIdUDPListenerThread; const AData: TIdBytes; ABinding: TIdSocketHandle); begin Memo1.Lines.Add(' Server read: ' + ToHex(AData, length(AData))); // with ABinding do // SendTo(PeerIP, PeerPort, AData); end; // ----------------------------------------------------------------------------- procedure TForm1.Button1Click(Sender: TObject); var XMLRequest : TStringStream; SndBytes, RcvBytes : TIdBytes; k : integer; begin Memo1.Clear; // Siehe ONVIF Application Programmer's Guide - Seite 14-15 XMLRequest := TStringStream.Create( '<?xml version="1.0" encoding="UTF-8"?>' + #10#13 + '<e:Envelope xmlns:e="http://www.w3.org/2003/05/soap-envelope"' + #10#13 + 'xmlns:w="http://schemas.xmlsoap.org/ws/2004/08/addressing"' + #10#13 + 'xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"' + #10#13 + 'xmlns:dn="http://www.onvif.org/ver10/network/wsdl">'+ #10#13 + '<e:Header>' + #10#13 + '<w:MessageID>uuid:84ede3de-7dec-11d0-c360-f01234567890</w:MessageID>' + #10#13 + '<w:To e:mustUnderstand="true">urn:schemas-xmlsoap-org:ws:2005:04:discovery</w:To>' + #10#13 + '<w:Action a:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</w:Action>' + #10#13 + '</e:Header>' + #10#13 + '<e:Body>' + #10#13 + '<d:Probe>' + #10#13 + '<d:Types>dn:NetworkVideoTransmitter</d:Types>' + #10#13 + '</d:Probe>' + #10#13 + '</e:Body>' + #10#13 + '</e:Envelope>'); SndBytes := RawToBytes(XMLRequest, SizeOf(XMLRequest)); try // Setup UDP-Server: with udpServer do begin Active := false; DefaultPort := strtoint(EditPort.text); // DEFAULT: 3702 BufferSize := 8192; // BroadcastEnabled := true; // ?? ThreadedEvent := true; Active := True; if Active then Memo1.Lines.Add('Server started on port: ' + IntToStr(DefaultPort)); end; // Setup UDP-Client: with udpClient do begin BufferSize := 8192; Host := EditHost.Text;; // DEFAULT: 239.255.255.250 Port := strtoint(EditPort.text); // DEFAULT: 3702 end; Memo1.Lines.Add(' Client sending Probe-Message'); with udpClient do SendBuffer(Host, Port, SndBytes); try k := udpClient.ReceiveBuffer(RcvBytes, 10); if k > 0 then Memo1.Lines.Add(' Client read: ' + ToHex(RcvBytes, length(RcvBytes))) else Memo1.Lines.Add(' Client no response !'); except on E: exception do begin Memo1.Lines.Add(Format(' Client read err: %s',[E.Message])); end; end; except on E: Exception do begin ShowMessage(E.ClassName + ': ' + E.Message); end; end; XMLRequest.Free; end; end. Das Proggy läuft zwar fehlerfrei - ich bekomme allerdings keinerlei Antwort. Gar nix, auch kein Daten-Kauderwelsch. Was ist (grundsätzlich ?) falsch ? Was hab ich vergessen ? (Zuweisungen, Einstellung am Client, Server, ...) Ich alles komplett auch mit EXE angehängt, falls das jemand mal probieren möchte - vielleicht hat ja jemand eine ONVIF-taugliche Kamera o.ä. Gerät in seinem LAN. Nochmals Hilfe bitte - hier ist mein KnoffHoff eher sehr bescheiden. |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Hmm..
Ich werfe mal ein paar Punkte in den Raum: Windows-Firewall? Auf dem UDP-Port des UDP-Servers offen, damit dieser überhaupt eine Antwort bekommen kann? DSL-Router? Forward-Regel, damit die Antwortpakete überhaupt zu deinem Rechner gelangen, wenn abfrage über Internet. Gibt es überhaupt den abzufragen Service in deinem Netz? |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Kurz zum Verständnis:
Es geht hier (momentan !) nur um mein Haus-LAN an einer 7490, wo div. Überwachungskameras reingehängt werden sollen (4 sind schon drin). Die machen geben den "Service". Kommunikation also nur im eigenen LAN - (noch) nicht aus dem InderNett. Port 3702 habe ich in der FW pauschal mal freigemacht. Kleiner Erfolg hier btw.: Ich habe beim Clienten von SendBuffer() auf Broadcast() geändert. Damit sieht der Server wenigstens die Message des Clienten - allerdings immer auf Port 1045 statt auf 3702 .... ?? |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Noch ein paar Anmerkungen, bevor Fragen kommen wie:
".... wozu das eigentlich ? Die IP's der Kameras solltest du doch kennen - warum fragst du die nicht direkt (via TCP ?!) ab ?" Sicherlich berechtigte Frage. Aber: Soweit ich das bisher verstanden habe, sind mit WS-Discovery auch "Geräte" zu ermitteln, die nicht im IP-Breich des Routers liegen - aber im LAN erreichbar sind/wären. Z.B. ein frisches China-Teil kommt immer irgendwie mit 192.168.0.1-10 Erstaunlicherweise erkennt die mitgelieferte PingPong-Soft diese CAMs trotzdem und man kann selbige dann auf die gewünschte IP (oder mit DCHP) umstellen. Das wäre nur die "PROBE" Message. Dann gibt es ja auch noch "HELLO", wenn sich so ein Gerät im Netz (neu !?) von selbst anmeldet. Oder auch das "BYE", wenn man ein solches Gerät bewusst z.B. in StandBy schickt. Auch diese Messages auszuwerten (ohne Ansage von einem Clienten) wäre sehr wünschenswert. .... nur wie geht das ? |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Bist Du dir sicher, das die Kameras mit PROBE,HELLO,BYE arbeiten?
Teilweise werden von den Hersteller eigene Protokolle/Services verwendet und dann antworten die Geräte natürlich nicht auf dein PROBE. Ein Beispiel ist mein Buffalo NAS, die haben dort auch ein auf UDP basierenden Service auf dem NAS laufen, welcher jedoch über ein spezielles Protokoll (Commandos) arbeitet. Die Hersteller eigene Software kennt natürlich das Protokoll und kann so mit den Geräten kommunizieren. Einfach mal die Kommunikation zwischen der PingPong-Software und den Kameras belauschen. ;) |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Ja, bin ich - zumindestens was PROBE betrifft.
Schau doch bitte noch mal genau in mein 1. Posting. Dort habe ich die XML-Texte von ONVIF und Microsoft zu dem Thema gelistet. Beide nahezu identisch - zumindestens inhaltlich. (MS hat am Schluss '</e:Envelope>' vergessen) Beide geben 239.255.255.250 : 3702 an. Dieser Satz in der WS-Spezifikation gibt mir doch noch etwas zu denken: Because there is no explicit ReplyTo SOAP header block [WS-Addressing], any response to this Probe will be sent as a UDP packet to the source IP address and port of the Probe transport header [SOAP/UDP]. Soll dann heißen: (!?) Jede Antwort auf die PROBE wird als UDP-Paket an die im Probe-Header enthaltene IP-Adresse und Port der Quelle (Absender) gesendet. Da ich hier keinen Plan habe, die Fragen: - Welche IP sende ich denn ? Die meines Rechner denke ich mal ... oder ? - Und welcher Port ist hier gemeint ? Der, den ich anfrage ? |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Die gute Nachricht zwischendurch:
.... HOUSTON - WIR HABEN KONTAKT !!! (ich zur Kamera und nutzbare Daten davon zurück) Allerdings nicht wie erwartet via WS-Dicovery-Probe. Der "Kabel-Hai" hat's an's Licht gebracht - Mega Dank an HolgerX für den Tipp !!! :-D Details später - ich muss da noch im speziellen eben noch mal schnell etwas fummeln .... 8-) |
AW: WebServices - Discovery: Hello, Probe, Bye ......
... die Details - wo fange ich mal an ?
Vorweg gesagt: Es geht offensichtlich auf 2 Wegen - sowohl via WS-Discovery PROBE und auch einem anscheinend internem Protokoll/Kommando ! Nachdem ich mir nach den (zunächst) erfolglosen Versuchen mal den Datenverkehr mit dem Kabel-Hai angesehen habe, was denn da alles so vom ChinaMan-DeviceManager gesendet wird, war zunächst folgendes festzustellen: Es geht abweichend zu WS-Discovery ein Broadcast an 255.255.255.255 : 34569 mit 20 Byte Daten raus, von nur 3 Byte > 0 sind. Die Kamera(s) antworten alle innerhalb 1/2 Sekunde an die absendende IP an den Port, der beim Senden mitgegeben wurde und schicken dazu etwa 450-500 Byte mit. Diese Daten sind fast selbsterklärend und bestehen immer aus "Variable":"Wert und Komma. Recht einfach, das auszuwerten. Das wird hier offensichtlich genauso gehandelt wie bei WS-Discovery. Entspricht genau dem Satz aus der Spezifikation, wie ich es 2 Postings zuvor geschrieben gabe. Das war nämlich mein Fehler bei der Anfrage via ONVIF - ich hab schlicht vergessen dem UDP-Server den richtigen Port zu sagen .... der hat dann in's leere gehorcht. Vorhin hab ich noch ein bischen rumgesnifft, um zu sehen, was denn der ONVIF-Manager (sourceforge.net) so alles von sich gibt und auch zurückbekommt. Siehe da: alle Kameras antworten ebenfalls artig mit einem ProbeMatch zurück ! Und nochmal siehe da: Nimmt man einer Kamera mal kurz den Saft, meldet diese sich nach ca. 10-15 sek. Initialisierung mit einem freundlich WS-Discovery HELLO ! Demzufolge müsste auch ein BYE drin sein - sofern ein entsprechenden Befehl zum "schlafengehen" exisiert. Fazit bis hierher: Nachdem ich mir Tage mit diesem WSDL-Kram um die Ohren gehauen habe, ist es doch erstaunlich festzustellen, mit wie wenig Zeilen Code + entsprechenden XML-Befehlssätzen sich eine Kommunikation erstellen lässt. Hab ich selber nicht dran geglaubt ... Und wenn man zwischen <d:Types>dn: xxxxxx </d:Types>' etwas anderes als NetworkVideoTransmitter angibt, lassen sich sicherlich auch andere, diesen Service unterstützende Geräte im LAN finden. Ich werde derweil ein wenig weitertippen, damit ein brauchbares Tool draus wird und lasse es euch bei zeiten zukommen. Zwischenzeitlich kommen sicherlich noch etliche Fragen auf ... |
AW: WebServices - Discovery: Hello, Probe, Bye ......
Ich möchte euch ja nicht vorenthalten, wie das mit eigentlich minimalistischem Code funktioniert.
Ich habe dafür nur einen UDP-Server benutzt, der beides macht: Daten versenden und gleichzeitig empangen. Die eigentliche procedure zur Anfrage als Broadcast via UDP:
Code:
Die procedure, woher obige den SOAP/XML-String her bekommt:
procedure TForm1.Button2Click(Sender: TObject);
var SndBytes : TIdBytes; begin with udpServer do begin Active := false; // proforma FALSE / stoppen Bindings.DefaultPort := strtoint(EditRcvPort.text); BroadcastEnabled := true; // Active := True; // ... und wieder starten ONVIF.GenSendBytes_PROBE(SndBytes); udpServer.SendBuffer(EditHost.Text, strtoint(EditPort.text), SndBytes); Memo1.Lines.Add('Data send to: ' + EditHost.Text + ':' + EditPort.text); Memo1.Lines.Add('Server started on port: ' + EditRcvPort.text); end; end;
Code:
.... und die procedure im Receive-Event des UDP-Servers:
procedure TONVIF.GenSendBytes_PROBE(var SndBytes : TIdBytes);
var s : string; begin s := '<?xml version="1.0" encoding="UTF-8"?>' + '<e:Envelope xmlns:e="http://www.w3.org/2003/05/soap-envelope"' + 'xmlns:w="http://schemas.xmlsoap.org/ws/2004/08/addressing"' + 'xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"' + 'xmlns:dn="http://www.onvif.org/ver10/network/wsdl">'+ '<e:Header>' + '<w:MessageID>uuid:84ede3de-7dec-11d0-c360-f01234567890</w:MessageID>' + '<w:To e:mustUnderstand="true">urn:schemas-xmlsoap-org:ws:2005:04:discovery</w:To>' + '<w:Action a:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</w:Action>' + '</e:Header>' + '<e:Body>' + '<d:Probe>' + '<d:Types>dn:NetworkVideoTransmitter</d:Types>' + '</d:Probe>' + '</e:Body>' + '</e:Envelope>'; SetLength(SndBytes, Length(s) + 1); fillchar(SndBytes[0], length(s) + 1, 0); move(s[1], SndBytes[0], Length(s)); end;
Code:
Dabei kommt dann z.B. so etwas als "Seifen-Oper" von der Kamera zurück:
procedure TForm1.UDPServerUDPRead(AThread: TIdUDPListenerThread;
const AData: TIdBytes; ABinding: TIdSocketHandle); begin Memo1.Lines.Add(' Server read num of bytes: ' + inttostr(length(AData))); Memo1.Lines.Add(' - from > IP: ' + ABinding.PeerIP + ' | Port: ' + inttostr(ABinding.PeerPort)); Memo1.Lines.Add(BytesToString(AData)); end; (Händisch formatiert ohne Einrückungen für die Optik)
Code:
... 627 Byte allerfeinstes WebService-WSDL-SOAP-XML-Kauderwelsch !
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa5="http://www.w3.org/2005/08/addressing" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:ns1="http://www.w3.org/2005/05/xmlmime" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:ns7="http://docs.oasis-open.org/wsrf/r-2" xmlns:ns2="http://docs.oasis-open.org/wsrf/bf-2" xmlns:dndl="http://www.onvif.org/ver10/network/wsdl/DiscoveryLookupBinding" xmlns:dnrd="http://www.onvif.org/ver10/network/wsdl/RemoteDiscoveryBinding" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:dn="http://www.onvif.org/ver10/network/wsdl" xmlns:ns10="http://www.onvif.org/ver10/replay/wsdl" xmlns:ns11="http://www.onvif.org/ver10/search/wsdl" xmlns:ns13="http://www.onvif.org/ver20/analytics/wsdl/RuleEngineBinding" xmlns:ns14="http://www.onvif.org/ver20/analytics/wsdl/AnalyticsEngineBinding" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:ns15="http://www.onvif.org/ver10/events/wsdl/PullPointSubscriptionBinding" xmlns:ns16="http://www.onvif.org/ver10/events/wsdl/EventBinding" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" xmlns:ns17="http://www.onvif.org/ver10/events/wsdl/SubscriptionManagerBinding" xmlns:ns18="http://www.onvif.org/ver10/events/wsdl/NotificationProducerBinding" xmlns:ns19="http://www.onvif.org/ver10/events/wsdl/NotificationConsumerBinding" xmlns:ns20="http://www.onvif.org/ver10/events/wsdl/PullPointBinding" xmlns:ns21="http://www.onvif.org/ver10/events/wsdl/CreatePullPointBinding" xmlns:ns22="http://www.onvif.org/ver10/events/wsdl/PausableSubscriptionManagerBinding" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:ns3="http://www.onvif.org/ver10/analyticsdevice/wsdl" xmlns:ns4="http://www.onvif.org/ver10/deviceIO/wsdl" xmlns:ns5="http://www.onvif.org/ver10/display/wsdl" xmlns:ns8="http://www.onvif.org/ver10/receiver/wsdl" xmlns:ns9="http://www.onvif.org/ver10/recording/wsdl" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:tnsn="http://www.eventextension.com/2011/event/topics"> <SOAP-ENV:Header> <wsa:MessageID>urn:uuid:327b23c6-5566-7788-99aa-0012152b823d</wsa:MessageID> <wsa:RelatesTo>uuid:84ede3de-7dec-11d0-c360-f01234567890</wsa:RelatesTo> <wsa:To SOAP-ENV:mustUnderstand="true"> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous </wsa:To> <wsa:Action SOAP-ENV:mustUnderstand="true"> http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches </wsa:Action> </SOAP-ENV:Header> <SOAP-ENV:Body> <d:ProbeMatches><d:ProbeMatch><wsa:EndpointReference> <wsa:Address>urn:uuid:327b23c6-5566-7788-99aa-0012152b823d</wsa:Address> </wsa:EndpointReference> <d:Types>dn:NetworkVideoTransmitter</d:Types> <d:Scopes> onvif://www.onvif.org/type/video_encoder onvif://www.onvif.org/type/audio_encoder onvif://www.onvif.org/hardware/IPC-model onvif://www.onvif.org/location/country/china onvif://www.onvif.org/name/NVT </d:Scopes> <d:XAddrs>http://192.168.178.39:8899/onvif/device_service</d:XAddrs> <d:MetadataVersion>1</d:MetadataVersion> </d:ProbeMatch></d:ProbeMatches> </SOAP-ENV:Body> </SOAP-ENV:Envelope> ... wovon mich eigentlich nur interessiert: <wsa:MessageID>urn:uuid:327b23c6-5566-7788-99aa-0012152b823d</wsa:MessageID> (gleich mit wsa:Address - immer !?) <wsa:RelatesTo>uuid:84ede3de-7dec-11d0-c360-f01234567890</wsa:RelatesTo> (zum Vergleich - die uuid hab ich geschickt) <d:Scopes> .... </d:Scopes> (die hier 5 darin entahltenen Typen, durch Leerzeichen getrennt) ... und wichtig <d:XAddrs>http://192.168.178.39:8899/onvif/device_service</d:XAddrs> hier eigenlich nur der Port für weitere Ansagen per HTTP. Die IP kenne ich ha schon aus dem eigentlichen Response vom Binding des UDP-Servers. Als NOOB in diesem Bereich fällt mir als erstes die gute alte funktion POS ein, hier die elementar 3 bis 8 wichtigen Werte mit nem 5-Zeiler rauszubröseln. Oder hat hemand da vielleicht eine (simplere) Idee ? Lasst hören ! |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:14 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz