Milestone documentation mentions that ONVIF cameras must "adheres to both the 1.01 and 1.02 versions of the ONVIF standard".
What does this means in term of implementation with gSOAP ?
Thanks!
You are probably pointing to obsolete documentation. Nowadays, camera must adhere only to Profiles, such as Profile S or Profile T for cameras.
Adhering to profiles does not pose any particular requirement on gSoap, you need to have updated WSDL file (you can get them from www.onvif.org) and to implement the functions required by each profile.
Related
Vehicles communicate using 802.11p on Veins 5.1, OmNET 5.6.2, sumo 1.8.0 environment.
My questions
Do I have to implement retransmission process(like CSMA/CA) when collision is occurred?
or, is retransmission process(like CSMA/CA) already implemented in library or such class?
I want to use RTS/CTS option, do I have to implement it too?
Thank you
To directly answer your question: the 802.11p modules that are included in Veins 5.1 trigger automatic retransmissions (following the 802.11 specification) for lost unicast messages if the MAC layer useAcks parameter is set to true (which is not the default). RTS/CTS is not implemented, so if you want to use only modules from Veins you would need to implement this yourself.
More generally, though, your research sounds like it might be better served if you would combine Veins with The INET Framework (via veins_inet); this would allow you to use the more general 802.11 simulation model included in The INET Framework. It includes features like block-ACKs, RTS/CTS, fragmentation and reassembly, infrastructure mode, automatic rate selection, and many more.
I have a camera that is ONVIF compatible.
If I want to zoom in/out, I presently have to send this URL to the camera:
http://192.168.2.88/cgi-bin/ptz_cgi?action=FocusAdd&steps=50&user=admin&pwd=admin
This is proprietary to my camera so I would like to do the same with ONVIF.
My question:
Is using onvif as simple as sending:
ONVIF://192.168.2.88:2010/some command ?
If so, what is the command :)
I am using Delphi XE2
Thank you.
No, it is not easy easy as a CGI protocol. The main differences are:
ONVIF is based on SOAP, while many proprietary protocols are based on REST or just parameters encoded in the URL
the ONVIF device model is more complicated, because it supports a wider set of use cases.
Thus, after you either generate the code from the WSDL files or get a library that implements the necessary functions, you have to do:
get the device services
verify that it has a PTZ service
verify that it has a Media service, either 1 or 2 (the latter is for profile T devices)
get the list of media profiles
select the media profile that has a PTZNode and that is actually the one you are looking for
select an adeguate coordinate space from the PTZ service capabilities
send the Move command with the correct parameters
This could seem overcomplex, but you need to remember that the ONVIF protocol needs to support devices with more that one input, such as multichannels encoders. These encoders may have a few fixed cameras and other cameras connected may have a PTZ controlled by the encoder. In practice, the list I just gave you lets you understand what the device you are controlling looks like.
As far as I know, cobalt will support widevine/playready drm playback, and we are trying to port on our platform with TEE support.
We have already done the starboard/player.h porting and I want to say the reference code for player did a great help! But when I try to start starboard/drm.h porting (at Cobalt 6.14197), I only find a little code related to drm. (e.g Starboard_decryptor, some stub implementation for drm.h API).
Do we need to implement our own content decryption module to handle license parsing, policy, etc., or will cobalt provide the reference cdm (which will be great) and we can use our OEMCrypto module to finish the rest part?
Cobalt is able to support any DRM system compatible with the Encrypted Media Extensions, but this has only been fully proven out with both PlayReady and Widevine on deployed products.
Licensing makes it difficult to provide an open-source reference integration with Widevine or PlayReady, so it is currently up to the platform implementer to integrate the code to generate license challenges, install keys, and decrypt samples before decoding. Note that you should not need to change any code in src/media to do this, you should be able to accomplish this by only implementing Starboard player/drm/media APIs.
You may be able to directly contact the business entities involved to get access to a non-open-source reference implementation.
I have a problem that it's bugging me:
I have some iBeacon devices (tags to be exact) and I want to create a custom new app supporting their functionality.
The problem is that every now and then the tags change their mac address (very frequently) as well as their UUID (frequently but not too frequently). The way I see it this feature has been implemented to protect users against tracking.
Now this can be hardware specific feature (I use the lasso tags) or be a standard functionality of the standard (iBeacon spec which I don't have).
Can someone please verify the intended functionality or at least give pointers to iBeacon official specification and/or other documents?
Regards
Recently, Apple made the iBeacon specification available on their iBeacon Developer pages: https://developer.apple.com/ibeacon/ (the "Download Artwork and Specification" link in the right-hand sidebar). You still need to accept the iBeacon License Agreement.
Some vendors use rotating UUIDs (and/or majors and minors) as a way to address security and privacy concerns, just like you said. It's not exactly what Apple intended for iBeacon (they mentioned on multiple occasions that you should plan around the possibility of beacons being spoofed, b/c iBeacon is not meant to be secure), but it's still compatible with the specification.
Most commonly, there's some known seed or secret key uploaded to the beacon during manufacturing or when enabling such security feature. Only authorized parties know the seed/key, and thus can either predict what's the UUID/major/minor of a beacon supposed to be at any given time, or decrypt it. In the end, UUID+major+minor is just 20 bytes of data broadcast by the beacon, and you can encrypt it just like any other data. (Well, actually, the problem with the iBeacon is that on the iOS side, you need to know the UUID of the beacon in order to scan for it, so at least the UUID—i.e., the first 16 bytes—need to be only pseudo-random, and can't be completely random.)
Personally, I would say this is one of the cases where the market validated the iBeacon idea/spec, and came up with a solution to a problem that Apple decided not to tackle. And I wouldn't blame them—they pretty much pioneered the beacon technology (sure, it was there before, but much less popular than it is today), and nobody at that time though about using iBeacon for tagging personal belongings.
When Google released Eddystone—i.e., an alternative beacon protocol—earlier this year, they announced at the very same time that encrypting the Eddystone identifiers will be part of the core spec:
At the same time, privacy and security are really important, so we built in a feature called Ephemeral Identifiers (EIDs) which change frequently, and allow only authorized clients to decode them. EIDs will enable you to securely do things like find your luggage once you get off the plane or find your lost keys. We’ll publish the technical specs of this design soon.
(source: http://googledevelopers.blogspot.com/2015/07/lighting-way-with-ble-beacons.html)
To me, this pretty much validates the idea of securing beacons, and rotating the UUIDs is just a clever market/community "hack" of the iBeacon spec to do just that.
Bluetooth LE beacons transmitting the iBeacon format, including those displaying the iBeacon certification logo, typically do not change their mac address. I base this statement on two years of experience testing these beacons from a wide variety of vendors. It is also unusual for an iBeacon to automatically change its ProximityUUID. These appear to be peculiarities that are specific to one vendor's implementation. The fact that these implementation details are unusual doesn't necessarily mean it isn't allowed -- it just means it is unusual.
Unfortunately, the iBeacon specification is proprietary and not publicly available from Apple. You need to enter a business relationship with Apple to be able to access the official documentation. That said, there is no shortage of information about iBeacons in the public domain obtained by folks who have reverse engineered the simple devices. In the absence of official public documentation, you simply have to do Google searches and use your judgement about the quality of the information you find.
In order to implement an FHIR based system for exchanging patient data, I would know if there is an ISO standard that could be applied to my project ?
I know that HL7 Version 3 is standardized with ISO/HL7 21731.
Is this the same thing for HL7 FHIR ? IE Would an FHIR based system be automatically ISO/HL7 21731 compliant ?
Thanks.
No, it's not the same thing. No, a FHIR based system would not automatically be 21731 compliant. FHIR has not yet been brought to ISO - it will be a number of years before it becomes time to do that
If all you're looking for is a tick in the box to meet legal requirements, you might get away with claiming that a FHIR based system is 21731 compliant