I never really looked at this stuff previously, but got to pick up on a project that had been started already. The installers used cameras from AXIS; I'm reasonably impressed by them so far.
It sounds like you're thinking the camera should "push" and you're asking why the end-user can't control "where to". The unit that I have (M1114) gives you the ability to "pull" - this might be a better fit to your needs. Yes, a bit trickier than something that self-publishes, but much more control.
(The big issue here was this is being used for surveillance, and there were many choices for server software, most of which were Windows-based - I'll put in a plug for 'motion', a package that we're running on Ubuntu and has been pretty flawless for what we needed. People here were impressed by the result of both the software and the hardware.)
Don't give up, there are good industrial-grade IP camera solutions out there!
I have my own server running WebDAV. It's "stock" Apache, the DAV module is included. A couple of people have mentioned Subversion, but of course that overlays functionality that may not be necessary or practical. DAV is fairly simple, and dedicated to supporting an essential set of semantics for accessing files.
The reason this may not be useful to you is that my primary use of the server has been as my "remote" fileserver, for Mac and Windows clients. In some sense, it'd be easier if I wanted to set up CIFS (Samba) or AFP (Apple), but neither of these work all that great when you have significant latency, which is the case if the server isn't right there physically to where you're working. Many iOS apps have taken to being written to directly talk to things like Dropbox, or WebDAV. That may not be true about the Android Apps that you care about. I agree with the premise that Dropbox doesn't give a warm fuzzy security feeling, though the functionality is very nice.
Setting up WebDAV on Apache, secured with TLS, isn't all that difficult. The protocol works well in a high-latency environment. The one technical issue that I've found is that there aren't good solutions for access control - it's not easy to set up multiple user accounts for one server and enforce separate access for those users. I've looked at a few kludges but nothing that seems satisfying.
Depending on your specific need, though, don't rule WebDAV out.
Sure, I understand that Microsoft implements SIP and RTP in these products, just like Exchange implements SMTP and IMAP. But they now own the other side of the conversation - meaning that it appears you'll need a Microsoft Windows Server-based gateway to bridge SIP and Skype. This is a different proposition than a $70 licence (per channel/session, I think), which is the current cost of running the Asterisk/Skype gateway. Skype as a closed protocol is now owned by a company whose business model historically is based on closed protocols; Microsoft presumably sees the value of limiting the ability of non-Microsoft PBXs to interoperate with it.
Lync Server is probably a fine solution for an environment that wishes to integrate SIP into a Windows/Exchange/AD workplace, but carries costs and risks for those not wanting to have their infrastructure assimilated, er, integrated in this manner. And the direction that Microsoft intends to take with this acquisition isn't yet clear.
If Microsoft were to open the Skype protocols or migrate Skype to SIP or some other open standard, I think I'd be cheering.
The Microsoft way of doing things is to keep things closed. Skype is closed, SIP - whether you're using Asterisk or some other solution - is open. The Asterisk product was a good way to provide an organization with a gateway they could control to bridge SIP in the enterprise with Skype.
Who cares about Asterisk... if there are other gateways between SIP and Skype? Except there aren't. It *appears* that this is a way to keep what's closed closed. That's the underlying pain here.
Slashdot Mirror
I never really looked at this stuff previously, but got to pick up on a project that had been started already. The installers used cameras from AXIS; I'm reasonably impressed by them so far.
It sounds like you're thinking the camera should "push" and you're asking why the end-user can't control "where to". The unit that I have (M1114) gives you the ability to "pull" - this might be a better fit to your needs. Yes, a bit trickier than something that self-publishes, but much more control.
(The big issue here was this is being used for surveillance, and there were many choices for server software, most of which were Windows-based - I'll put in a plug for 'motion', a package that we're running on Ubuntu and has been pretty flawless for what we needed. People here were impressed by the result of both the software and the hardware.)
Don't give up, there are good industrial-grade IP camera solutions out there!
This may or may not be helpful.
I have my own server running WebDAV. It's "stock" Apache, the DAV module is included. A couple of people have mentioned Subversion, but of course that overlays functionality that may not be necessary or practical. DAV is fairly simple, and dedicated to supporting an essential set of semantics for accessing files.
The reason this may not be useful to you is that my primary use of the server has been as my "remote" fileserver, for Mac and Windows clients. In some sense, it'd be easier if I wanted to set up CIFS (Samba) or AFP (Apple), but neither of these work all that great when you have significant latency, which is the case if the server isn't right there physically to where you're working. Many iOS apps have taken to being written to directly talk to things like Dropbox, or WebDAV. That may not be true about the Android Apps that you care about. I agree with the premise that Dropbox doesn't give a warm fuzzy security feeling, though the functionality is very nice.
Setting up WebDAV on Apache, secured with TLS, isn't all that difficult. The protocol works well in a high-latency environment. The one technical issue that I've found is that there aren't good solutions for access control - it's not easy to set up multiple user accounts for one server and enforce separate access for those users. I've looked at a few kludges but nothing that seems satisfying.
Depending on your specific need, though, don't rule WebDAV out.
Sure, I understand that Microsoft implements SIP and RTP in these products, just like Exchange implements SMTP and IMAP. But they now own the other side of the conversation - meaning that it appears you'll need a Microsoft Windows Server-based gateway to bridge SIP and Skype. This is a different proposition than a $70 licence (per channel/session, I think), which is the current cost of running the Asterisk/Skype gateway. Skype as a closed protocol is now owned by a company whose business model historically is based on closed protocols; Microsoft presumably sees the value of limiting the ability of non-Microsoft PBXs to interoperate with it. Lync Server is probably a fine solution for an environment that wishes to integrate SIP into a Windows/Exchange/AD workplace, but carries costs and risks for those not wanting to have their infrastructure assimilated, er, integrated in this manner. And the direction that Microsoft intends to take with this acquisition isn't yet clear. If Microsoft were to open the Skype protocols or migrate Skype to SIP or some other open standard, I think I'd be cheering.
The Microsoft way of doing things is to keep things closed. Skype is closed, SIP - whether you're using Asterisk or some other solution - is open. The Asterisk product was a good way to provide an organization with a gateway they could control to bridge SIP in the enterprise with Skype. Who cares about Asterisk... if there are other gateways between SIP and Skype? Except there aren't. It *appears* that this is a way to keep what's closed closed. That's the underlying pain here.