One of our customers was trying to add 3rd party IP-camera into our video management software (VMS). There is indeed such possibility, but not all camera manufacturers/models are supported. In other words, it’s always better to try and see if it works.

The process of adding 3rd party camera looks like the next:

• Add camera in corresponding menu:

• Define an URL to access MJPEG-stream.

“I can’t get an image!” the customer said in his email to our first line support. After that some more mailing occured 🙂

“Have you tried the latest firmware?”- “Yes, I have. Still no image!”

“Have you checked password?” – “Sure, but still have no image! I can access my camera via browser, but not with your VMS!”, and so on.

All this mailing lasted for some days with zero result, after which the case was escalated to me.

It’s good to know we have both working example (via browser) and not working (with VMS). Let’s capture some traffic and see what is going on.

1. Browser traffic. I’m interested only in traffic to/from the camera, so I can use ‘host 88.88.88.88’ capture filter.

We send just an ordinary HTTP GET request for MJPEG stream, nothing unusual is here.  Then we got ‘200 OK’ and the stream itself was started. This is very iseful to have such baseline to compare with the next example wich represents an issue.

2. Traffic from our VMS trying to connect to camera.

3-way handshake is good, GET request is sent, but suddenly camera replies with “400 Bad request” and closes the connection.  Let’s look closer into the stream:

Hmm.. Our GET request is kinda strange, it has too much in it! It contains server IP, port values in ‘Request URI’ string AND in the corresponding ‘Host‘ header too. Of course, the camera doesn’t like such request and it sends an error back to us.

So, one last question remains. Why does VMS send unnecessary parts in request? Remember an URL to MJPEG stream we’ve defined before in VMS?

We ourselves are forcing it to do so! Thus the problem can be solved with only Backspace key 🙂

Let’s remove needless URL part and check one more time:

(Don’t look at the image itself, it’s been a little bit anonymized)

So, total time spent to solve this issue: several days with no result without leveraging packet analysis, 5 minutes with it.