Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Netzwerke (https://www.delphipraxis.net/14-netzwerke/)
-   -   WebServices - Discovery: Hello, Probe, Bye ...... (https://www.delphipraxis.net/188105-webservices-discovery-hello-probe-bye.html)

TERWI 31. Jan 2016 19:44

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: http://www.onvif.org/Portals/0/docum...%27s_Guide.pdf)
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: https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

(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:

B.1 SOAP Communication Trace for Discovery
The following trace refers to Section 4.
In the examples below,
Types: dn:NetworkVideoTransmitter
Scopes: onvif://www.onvif.org/type/video_encoder
onvif://www.onvif.org/type/audio_encoder
onvif://www.onvif.org/hardware/MODEL
onvif://www.onvif.org/name/VENDOR%20MODEL
onvif://www.onvif.org/location/ANY
XAddrs: http://169.254.76.145/onvif/services
http://192.168.1.24/onvif/services
Address: urn:uuid:a1f48ac2-dc8b-11df-b255-00408c1836b2
Discovery.Probe message
Code:
<?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>
.... noch ne Ergänzung:
Bei MS (siehe Link oben zu Discovery) sieht das dann so aus:
Code:
<?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>
.... fehlt da nicht was ? ? ? Zunmindestens das Ende von "Envelope"
Dinge zu ONVIF stehen hier nicht drin - Systembedingt.

TERWI 2. Feb 2016 16:23

AW: WebServices - Discovery: Hello, Probe, Bye ......
 
.... Hallooooo ? Niemand hier im Forum, der schon mal mit so was "rumgemacht" hat ?

mjustin 2. Feb 2016 17:22

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'.

TERWI 2. Feb 2016 17:31

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.

mjustin 2. Feb 2016 18:19

AW: WebServices - Discovery: Hello, Probe, Bye ......
 
Zitat:

Zitat von TERWI (Beitrag 1329124)
Fleissarbeit ? Das ist nun wirklich das allerletzte, kleinste Problem .... mache ich gerne.

Ich schätze den Aufwand allerdings nicht gerade gering - so zirka ein halbes Jahr mit zwei bis drei Entwicklern in Vollzeit. Minimum :)

TERWI 3. Feb 2016 18:32

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.

TERWI 5. Feb 2016 13:05

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
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx
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
http://specs.xmlsoap.org/ws/2005/04/...-discovery.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:
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.
Prinzipiell müsste das meiner bescheidenen Meinung nach funktionieren.
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.

HolgerX 5. Feb 2016 13:59

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?

TERWI 5. Feb 2016 14:34

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 .... ??

TERWI 5. Feb 2016 14:54

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 ?

HolgerX 5. Feb 2016 17:48

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. ;)

TERWI 6. Feb 2016 11:02

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 ?

TERWI 6. Feb 2016 18:15

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-)

TERWI 7. Feb 2016 11:26

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 ...

TERWI 8. Feb 2016 18:27

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:
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;
Die procedure, woher obige den SOAP/XML-String her bekommt:
Code:
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;
.... und die procedure im Receive-Event des UDP-Servers:
Code:
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;
Dabei kommt dann z.B. so etwas als "Seifen-Oper" von der Kamera zurück:
(Händisch formatiert ohne Einrückungen für die Optik)
Code:
<?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>
... 627 Byte allerfeinstes WebService-WSDL-SOAP-XML-Kauderwelsch !
... 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