- √ - HS and camera Cisco CIVS-IPC-2500

[Warichet]

RTP/RTSP protocols

Hi,

I did RTFM again. I read that the cam can deliver 2 video streams. I was thinking about:
- one for the HS Visu
- one for saving to the NAS archive per ftp
Is that correct / make any sense ?

I'm reading also that the cam supports the RTP/RTSP protocols. According to the doc, this feature could be used to manage / redirect the video stream, but there it stops....
Anyone having a practical experience or example and want to share it ? or a pointer to a meaningfull doc (I know Wikipedia).

Thanks

RTP/RTSP
RTSP Port
Transmission Control Protocol (TCP) port on which the IP camera receives Real-Time Streaming Protocol (RTSP) commands. You must configure this port to allow third-party devices or software to access video streams from the IP camera.

RTSP is a standard for connecting a client to control streaming data
(MPEG-4) over the web.

Valid values are 554 and 1024 through 65535. The default value is 554.

RTP Data Port

Universal Data Protocol (UDP) port on which the IP camera transmits Real-Time Transport Protocol (RTP) data.

RTP is a standard for transmitting real-time data, such as audio and video, to a selected clients.
Valid values are 1024 through 65535. The default value is 5000. The default value can be used for multicasting and typically does not need to be changed.

Max RTP Data Packet
Maximum number of bytes per data packet that are sent in each RTP request.
Configure a lower number if you are streaming video to a cell phone that
requires smaller data packets.

Valid values are 400 through 1400. The default value is 1400.

[Warichet]

Hi,

I moved a bit forward.

Now, when I pass under the cam, a lamp goes on.
That means: the cam, ftp, eibd, N148, NAS are technically working.
So, when the cam detects a motion control, it triggers a php script that calls eibd and switches a lamp On.

Now the question: what is the best way to write the video stream to the NAS (ftp) in case of incident ?
NB: I can configure the cam to write to an ftp server or send an e-mail at each motion detection, but that's not what I want.
I want the video stream to be written ONLY in case of intrusion.

How to you do it ?

Thanks for any hint.

[makki]

Again, you best friend is Wireshark, he knows what really happens
It's often not easy going but in the end - if you figured out what really happens - it's getting clear what has to be done to get the beast done..
Have no such cam but the way is always the same: find out what it does.

Makki

[Warichet]

Off-topic: http_post, http_get, php

Hi,

Would someone be so kind to point me to some readings about http_post, http_get and php, please ?

So far, I was using the W3schools site for my learning but it's not detailed enough for my current project. I want to learn more about those topics for integrating the cameras, NAS, HomeServer and eibd.

I've a problem with http_post, http_get and enumerating the content of the camera reply.
Some how, I've to get started but I don't even know the number of parameters in the cam's reply.
I know there is a a special syntax to get the elements of the reply but there I'm stuck. I've a serious lack of knowledge here

First, I'd like to make sure if the cam uses get or post. How can I do this ?
Then, I'd like to enumerate all elements of the reply, eventually handle a 2 dimensions table and select the element appropriate to trigger the writing of the cam data stream to the NAS.

Any suggestion ? or code sample ? or documentation about the topic ?

Thank in advance.

[Warichet]

In the mean time ...
I've upgraded the Visu PC to Ubuntu 10.04 and FF to 7.01.
Now I've the camera stream nicely displayed in the HS Visu.

Next step is to record the stream on the NAS.


The cam has 3 applications:

• e-mail
• ftp
• http

all being triggered by an event, i.e. motion control.
I guess I've to write a php script triggered by the http application to start the recording to NAS (same question here).

How do you guys do it ?

[makki]

Might sound smart-aleck (Neunmalklug, got that from dict.leo.org) now and is less secure: but never use any special-characters besides a-Z/0-9 in such passwords. Passwords are bad anyway, so if the device is properly secured (by network/IP) this doesn't matter.

http://user:password@hostname/page

works AFAIK in any browser/OS, thats written in some RFC and simply true (it also works with special chars in passwords, but they have to be escaped properly - and this is where trouble starts..)
Chrome and any IE accept this syntax either pretty well, because it's a pretty simple base of the HTTP-Standard. (it might still be that the cam doesn't, in your capture there's only the part until the browser would ask for credentials)

Makki

[Warichet]

Hi,

In yet another attempt to solve my problem (I'm kind of "die hard massochist" ), I've installed Google Chrome on yet another PC.

Chrome does accept the basic authentication syntax in the URL, i.e. http://<username>:<password>@<ip address>
Unfortunately, it doesn't work, I get a message back about "site not found".
It looks like basic authentication is not supported by the cam.
Is this the end of the long road ?

When I make a mistake in the password, I get another error, bizarre, it looks like basic authentication is accepted ?!? but not honored ?!? bizarre !
I changed my password in the cam, it was a "real" password with small letters, capitals and it did contain a hash sign (#).

It works.

So, it's not a basic authentication problem, it's a password problem where some signs are interpreted.

I've entered the new password in the HS, Kameras properties and the Kamera Direckt Zugrif check box still checked for user guest (although I still fail to undestand those settings in the case of a browser access).

Still no go.

The alternative via xxHTTP with basic authentication in the URL does work ! but then I've a page formatting problem, which I'm going to ask here in the xxAPI forum.

[Warichet]

-> wireshark, capture what happens, how User/PW gets to the cam..

As you mentionned several times, it's all about Basic Authentication, so I tried to make a definite point about that item (otherwise the remainder of the reasoning will be false)
I'm using the following URL syntax:
http://admin:1234@10.x.x.x/img/video.mjpeg
In IE8, IE9: not allowed (MS knows better what is good for me)
In OpenSuse, FF: the URL is interpreted (not executed) and I end up in another web site, this is crazy !
In Ubuntu 9.10, FF: same as above
In HomeServer, xxAPI, xxHTTP: no result, but it's not known if Basic Authentication works, so no conclusion.

HS setup for the test:
Kameras:
see tuut1
NB: the account "gira" has been defined in the cam
Benutzer:
I don't know in which user context the connection takes place, so I suppose "guest" (but did it for my account as well)
see tuut2
Camera setup for the test:
An account has been created that matches the setup in the HS "Kameras"
The capture has been taken just before hitting the button in the Visu (Ubuntu+FF) and before the pop-up.
NB: the WireShark PC has been connected to a port of the switch which "mirrors" the port of the cam, hence solely traffic intented for the cam has been recorded.
see tuut3
Here it is, be prepared for a surprise
https://rapidshare.com/files/2762174089/Camera.pcap

[makki]

The Visu is running Ubuntu 9.10 and FF

..where Flash and Java ist default on and runs fine
-> wireshark, capture what happens, how User/PW gets to the cam..

Makki

[Warichet]

Tipp: turn off Flash, Java, Silverlight and all this other crap, if the popup still comes your chances rise that it's simple

The Visu is running Ubuntu 9.10 and FF, nothing else, so I guess I'm already at the bottom line.

Thank you for the hint

[makki]

Again: if http://USER:PASSWORD@cam-ip works it's HTTP-basic auth according to the the RFC's, otherwise you can forget about it (at least in simple, this way)
And if yes this would work both ways so it isn't.
Tipp: turn off Flash, Java, Silverlight and all this other crap, if the popup still comes your chances rise that it's simple but Sony isn't really famous for being simple & standard

Makki

[Warichet]

Hi,

Yet another idea, probably the last

I though XXHTTP could do the trick, that is: an icon in the Visu points to an "external" web site: the camera, but then again arises the pop-up about username & password, but at least here I've a chance to supply basic authentication.

Don't know how to deal with that, but asked here.
I first tried with username & password in the URL, no go

Any hint ?

[makki]

The question: is this thing supposed to work ?

Probably not.. Either the Cam does HTTP Basic-Auth then both works or not - than only entering it afterwards with Direktzugriff in the Browser works.

Checking this tick only makes sense if one want to to wild things like forwarding the HS-Webif unprotected into the Inet without being able to directly access the cam, it won't help to make strange authentication-schemes of a cam better

Makki

[Warichet]

Hi,
In a desperate move to solve my password problem, I've re-read all your posts.
I think I got the idea.
So, I've un-checked the "Kamera-Direktzugriff". If I got you right, the HS will do the authentication (basic authentication), based on "Benutzername" and "Passwort" as entered in the camera menu.
Re-boot, click on the camera, image is empty (no error message).
NB: I didn't change anything else, so the image path is still the same.

I sniffed again, the cam port, I see the request for image with the correct path and the words Authentication Basic. Later a connection close. But no authentication data. Also, I see plenty of "continuation or non-http traffic", it is as if the image transfer takes place, but no track of it.

The question: is this thing supposed to work ?
I mean, is there anyone having it running with un-checked "Kamera-Direktzugriff" ?

Yet another dumb question, the "Kamera-Direktzugriff" is a user property (not a cam property), so when accessing the cam over a browser, which user is that ? guest ?
I've unchecked the box for guest: no go

Any hint ?

[makki]

As I said: it depends!
Kamera-Direktzugriff means only the cleint talks to the Cam and vice-versa.
If the cam does HTTP Basic-Auth it's simple and straightforward. If not, now I call this "propretäre grütze"

Makki