Is there a way to determine whether Profile S is supported by looking at the ONVIF responses/profiles in the device? Do I just assume if the profile includes Video Source configuration, that Profile S is supported?
As you can read in section 9 of the ONVIF_Profile_-S_Specification_v1-1-1,
A device compliant to this specification shall additionally include
the specific scope parameter as presented in Table 1: Scope
parameters. Apart from this pre-defined parameter, it shall be
possible to set any scope parameter as defined by the device owner.
Scope parameters can be listed and set through the commands provided
by the Device service, defined in the ONVIF Core Specification.
+--------+--------------+---------------------------------------------------------+
|Category|Defined values|Description |
+--------+--------------+---------------------------------------------------------+
|Profile |Streaming |The Streaming scope indicates if the device is |
| | |compliant to the Profile S. A device compliant to the |
| | |Profile S shall include a scope entry with this value in |
| | |its scope list. |
+--------+--------------+---------------------------------------------------------+
So, in order to know if the device claims Profile S support, you need to check if the scope onvif://www.onvif.org/Profile/Streaming is present.
You can create a onvif Media client with:
https://www.onvif.org/ver10/media/wsdl/media.wsdl
This client can request the supported profiles with 'GetProfiles'.
Related
I would like to know what is the exact behaviour of the Apizee PaaS when the meshModeEnabled and meshOnlyEnabled parameters are set to true ?
The documentation describes the usefulness of these 2 parameters but does not explain the behaviour in the Apizee application.
If we set the meshModeEnabled parameter to true and set the meshOnlyEnabled parameter to true, then this will prohibit ApiRTC from redirecting traffic to the SFU (to maintain a true Peer-To-peer).
My question is: by setting the two parameters mentioned above to true, the traffic will be exclusively P2P, which means that it is no longer possible to use the conversation recording system and the media retrieval with the API (because no passage to SFU)?
Thank you in advance
I have already used the 2 parameters but without any information on their technical behaviour on the Apizee PaaS side
Answer for the ApiRTC lib release 4.7.8
If we set the meshModeEnabled parameter to true and set the
meshOnlyEnabled parameter to true, then this will prohibit ApiRTC from
redirecting traffic to the SFU (to maintain a true Peer-To-peer).
You re right
My question is: by setting the two parameters mentioned above to true,
the traffic will be exclusively P2P, which means that it is no longer
possible to use the conversation recording system and the media
retrieval with the API (because no passage to SFU)?
I confirm. The SFU is needed for any activity that needs to centralize all the streams (recording, bandwith optimisation,...)
Beware that ApiRTC has a mecanism to choose the best stream routes depending of the use and of the bandwith quality of participant.
If you enable mesh mode,the behavior of ApiRTC will be:
If < 5 participants AND session has not been in SFU mode before ==> roomMode = "mesh"
If >= 5 participant OR someone join the room in SIP OR recording OR someone hase a doggy upload link OR session has been in SFU mode before ==> roomMode = SFU
Here are the default values if you don't specify any:
meshModeEnabled : false ==> so by default it doesn't use the ApiRTC stream routing optimisation
meshOnlyEnabled : false
To get the current connection mode, you can use the apiCC.session.apiCCWebRTCClient.webRTCClient.MCUClient.sessionMCUs object in your browser console. (unsupported) watch for the roomModeChanged of the current Conversation to be fired when the mode changes from mesh to SFU.
The roomMode attribute will show
"mesh" => mesh mode
or will not be defined => SFU mode
In oneM2M, I want to update the MN-CSE configurations by sending the command from IN-CSE to MN-CSE. How can I achieve this?
My Approach: I am thinking of creating an AE on MN-CSE say CONFIG-AE. Every time I want to change anything, I will create a new Content Instance inside the container of CONFIG-AE. The container will have a subscription with the CONFIG-AE resource as the notificationURL. Now when we add new content instance, the request will be redirected to the POA (point of access) of CONFIG-AE. The POA will be basically an IPE implementation which will further process the action. Is the approach correct?
CONFIG-AE (POA=an IPE implementation)
|
|
--------Container
|
|
--------Subscription (notificationURL=path of CONFIG-AE)
Thanks in advance.
Your approach would work. Any AE that has the permissions to create a content instance under the container can set configuration data this way. The CONFIG-AE in your example would then need to apply the new configuration accordingly. I am not sure, though, why this AE would be an IPE? With what would it provide interworking functionality?
Nevertheless, you should also have a look at TS-0001, clause 10.2.8 "Device management" and the whole of TS-0022, "Field Device Configuration". Here, oneM2M specifies specific management resources to manage nodes in a oneM2M deployment. This might look like an overkill at first but since the resource types defined there are well aligned with other management technologies this might be worth the efforts.
Depending on your infrastructure you might also want to look at TS-0005 "Management Enablement (OMA)" and TS-0006 "Management Enablement (BBF)" in case you are working with remote management technologies from OMA or BBF.
I'm trying to add an lora device on Live Objects.
There is 'AppEUI' field on device registration form.
I don't know how to define AppEUI.
The FAQ explains:
The AppEUI and AppKey parameters are specific to the owner of the object and/or the application used with the object (see specification LoraWan).
And the LoRaWAN spec says:
The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame.
So, i wonder if i can define appEUI for myself. I create my own EUI-64 address and just fill 'AppEUI' field of the form. Is that it?
Thank you.
yes you're right, you can define your own appEUI
best regards
I need to parse the buffer of m3ua protocol. In order to parse the same I will require asn.1 specifications for M3UA.
Kindly could anyone provide me the link for the same.
It will be a great help.
Thanks in advance.
I think you are looking for this one:
RFC 3332: Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User
Adaptation Layer (M3UA)
https://www.ietf.org/rfc/rfc3332.txt
SIGTRAN's MTP3-User Adaptation Layer (M3UA) provides for the transport of MTP user protocols such as ISUP and SCCP.
Since you are inquiring about ASN.1 we can assume you are interested in one of the SCCP user protocols. The first step will be to decode the Signaling Connection Control Part (SCCP). See the ITU-T recommendations (http://www.itu.int/itu-t/recommendations/index.aspx?ser=Q) or your national variant (e.g. ANSI):
Q.711-Q.719: Signalling Connection Control Part (SCCP)
In all likelihood the SCCP user protocol you are interested in is TCAP:
Q.770-Q.779: Transaction Capabilities Application Part (TCAP)
The ASN.1 specification for TCAP is contained in Q.773:
Q.773: Transaction Capabilities Formats and Encoding
http://www.itu.int/itu-t/recommendations/rec.aspx?rec=4079
The TC user protocol you are most likely to be interested in is the Mobile Application Part (MAP). The GSM/UMTS specification for MAP contains the ASN.1:
3GPP TS 29.002 Mobile Application Part (MAP) Specification
http://webapp.etsi.org/key/key.asp?GSMSpecPart1=29&GSMSpecPart2=002&Search=search
Writing NDIS 5.1 driver for WinXPe. In addition to normal NDIS send/receive functionality, driver also needs to make some discrete IO values available to user processes, presumably via a set of custom OIDs. Info on web indicates IOCTL_NDISUIO_OPEN_DEVICE then IOCTL_NDISUIO_QUERY_OID_VALUE would be perfect, but these functions appear to be limited to Windows CE and not WinXPe. CreateFile to "\\.\\NdisUio" succeeds, but IOCTL_NDISUIO_OPEN_DEVICE fails with code (50) "the request is not supported". Additionally, I had to cheat just to get nuiouser.h into my project because it's not available with the regular SDK. WMI does not appear to help, because WMI appears to only support "standard" parameters, not custom parameters.
If necessary, I believe I can implement IoCreateDevice and IoCreateSymbolicLink in my NDIS driver, then making custom IOCTLs available to user processes. But I'd rather go the OID route if possible.
Can a WinXPe user process perform an NDIS OID query?
MOF files integrated with the driver SYS permit linkage into WMI system and thus access to OID data.