[Gelöst] Zusammenspiel Dahua SIP1.0 und SIP2.0 Komponenten

[riogrande75]

Liebe Dahua Freunde!
Hat es schon jemand geschafft, eine VTO mit alter SIP1.0 Firmware (z.b. 20170425) an einer VTH mit aktueller SIP2.0 FW (z.b. 4.3) anzubinden und das Bild des Besuchers VOR dem "Abheben" gesehen?
Bin da gerade hart am Forschen, warum das so ist. Eine heiße Spur habe ich zwar schon, wollte aber wissen, ob das jemand anders auch noch so am laufen hat.

 

[riogrande75]

Hab das Problem nun gelöst.

Auch wenn die Wenigsten unter euch das Problem haben und das folgende nachvollziehen/verstehen werden, ich poste es trotzdem als "Ideen/Ansatz-Geber" für andere Problemchen (und "Reminder" für mich selbst).

Grund für das fehlende Video vor Verbindungsannahme war, dass die VTO keinen RTSP Stream von der VTO anforderte. Im Gutfall wird sofort nach dem SIP-INVITE zur VTH ein RTSP Stream von der VTO anfgefordert (kann man mit VLC nachspielen). Dieser RTSP Request wurde aber nie zur alten V1.0 VTO geschickt...

Ich hab daraufhin beim Einrichten+Aktivieren der VTO auf der VTH mitgesniffert. Dabei ist mir aufgefallen, das die VTH eine Verbindung zur VTO auf Port 5000 aufbaut um offenbar Config-Infos abzugleichen.
Im Schlechtfall (VTO2000A mit V1.0) wurde diese Verbindung nur nach AES Verschlüsselt und dabei kommt es zu einem Fehler ("Method not found!").
Im Gutfall (VTO2000A mit FW 4.3) wurde nach AES+RPAC Verschlüsselt und die Config wird in der VTH sauber aktualisiert.



Somit war klar, die Config IN der VTH passt nicht.

Auf die Schliche bin ich dem Problem mit der Dahua-DHIP-JSON-Debug-Console gekommen.
Damit kann man zwar mit aktuellen Firmware'n nicht mehr auf die VTO2000A zugreifen (neue Verschlüsselung, Bugfix?), sehr wohl aber noch auf die VTH's.
Ich hab also einfach die Config ausgelesen (config all) und Gut- und Schlechtfall verglichen. Neben einigen unwichtigen Kleinigkeiten fiel mir die "MiddleNumber" auf, welche im Schlechtfall gefehlt hat.

               "Vto00": {
                    "Username": "admin",
                    "Type": "Vto",
                    "Enable": true,
                    "RingFile": "/mnt/data/Sounds/phoneRing/phone_ring1.mp3",
                    "Address": "192.168.1.2",
                    "LockNumber": 2,
                    "Password": "password",
                    "MiddleNumber": "19", <<=== Hier war im Schlechtfall nur ""
                    "Port": 5000,
                    "RingVolume": 70,
                    "MachineAddress": "Main VTO"

Somit war das Problem zwar gefunden, aber noch nicht gefixt. Die Config auf dem Gerät kann man nämlich nur ansehen, nicht editieren.

Mit etwas Hausverstand war klar: Ich gebe der Test-VTO mit FW 4.3 einfach die IP Adresse und Zugangsdaten der "produktiven" VTO und melde sie an der VTH an. Danach stecke ich einfach die produktive VTO wieder an.

Und siehe da, die VTH behält auch nach dem Wechsel der VTO die Config und alles funktioniert

 

[pjotr_weliki]

@ riogrande75
Cool, darauf muss man erst mal kommen. Aber du bist schon ein verrückter Hund...

 

[alex_ffm]

@riogrande75 Kurze Rückfrage: Hält er die Konfig auch nach einem Restart der VTH?

 

[riogrande75]

Ja.
Das Ganze sollte man, **deutlich einfacher** auch über die Debug-Console machen können (Config ändern).