IdPoint service

An IdPoint is bound to a specific hardware unit using the DeviceUUID field. When setting an IdPointConfiguration with an empty DeviceUUIDfield, the field will be filled in with the UUID of the device to which the request is made. This will bind the configuration to that specific unit. For more information about the UUID field, see UUID.

The Configuration data structure describes the common hardware devices connected to the door controller and their connection types, see table. Some of the settings generate new IoUsers that can be bound to physical pins using axisio:SetIoAssignment, see I/O assignment service guide.

When issuing a call to SetIdPointConfiguration without a value for all parameters, one of two things will happen:

• If a structure with the same token already exists in the database, only the supplied parameters will be replaced.

• If a structure with the specified token does not exist in the database, any missing parameters will be replaced with default values (the first value in each list of possible values).

Implementing mV

It is recommended that you place a supervised resistor-circuit as close to the monitoring device as possible.

For example, the circuit schema for serial first is used for supervised settings specifically for the AXIS A1601 Network Door Controller, with the mV values listed in the first table below.

On the other hand, the circuit schema for parallel first is used for the supervised settings of the mV values, and refers to the column Parallel 22k 4k7 in the second table below.

This table showcases the mV values for an open collector output with 1k pull-up to 5V (HID RK40) when using IdPointConfiguration.Tampering

This table showcases the mV values for a basic switch when using either IdPointConfiguration.REX or DoorConfiguration.Doormonitor.

This is a configuration for a Wiegand reader (e.g. HID RK40 with default parameters). It has the following features:

• Wiegand output

• A single LED that switches between red and green.

• The LED turns to green when grounded.

• A beeper which sounds when grounded.

• A tampering detection line which indicates tampering when grounded.

{"IdPointConfiguration": [{
  "token": "",
  "DeviceUUID": "",
  "IdDataConfiguration": [""],
  "Configuration": [ {"Name": "IdPoint.Reader.Type",
        "Value": "Wiegand"},
        {"Name": "IdPoint.LED.Type",
        "Value": "SingleLED"},
        {"Name": "IdPoint.LED.ActiveLevel",
        "Value": "ActiveLow"},
        {"Name": "IdPoint.Beeper.Type",
        "Value": "ActiveLow"},
        {"Name": "IdPoint.Tampering.Type",
        "Value": "ActiveLow"} ]
  }]
}

<axtid:IdPointConfiguration token="">
  <axtid:Configuration>
    <axconf:Name>IdPoint.Reader.Type</axconf:Name>
    <axconf:Value>Wiegand</axconf:Value>
  </axtid:Configuration>
  <axtid:Configuration>
    <axconf:Name>IdPoint.LED.Type</axconf:Name>
    <axconf:Value>SingleLED</axconf:Value>
  </axtid:Configuration>
  <axtid:Configuration>
    <axconf:Name>IdPoint.LED.ActiveLevel</axconf:Name>
    <axconf:Value>ActiveLow</axconf:Value>
  </axtid:Configuration>
  <axtid:Configuration>
    <axconf:Name>IdPoint.Beeper.Type</axconf:Name>
    <axconf:Value>ActiveLow</axconf:Value>
  </axtid:Configuration>
  <axtid:Configuration>
    <axconf:Name>IdPoint.Tampering.Type</axconf:Name>
    <axconf:Value>ActiveLow</axconf:Value>
  </axtid:Configuration>
  <axtid:DeviceUUID></axtid:DeviceUUID>
  <axtid:IdDataConfiguration></axtid:IdDataConfiguration>
</axtid:IdPointConfiguration>

Note that IdDataConfiguration is set to empty in this request since it will be covered later. Note also that DeviceUUID is set to empty here. This will be replaced by the UUID of the device to which the request is made.

Once this configuration has been set together with its corresponding IdPoint, some IoUsers will exist on the unit to which the request was made. See I/O assignment service guide for how to assign these to physical pins.

For an OSDP reader, it is only necessary to assign the serial pins since LED, beeper, tampering information etc. is sent using serial commands. Here we are assuming a half-duplex RS485 connection.

{"IdPointConfiguration": [{
  "token": "",
  "DeviceUUID": "",
  "IdDataConfiguration": [""],
  "Configuration": [ {"Name": "IdPoint.Reader.Type",
        "Value": "RS-485HD"},
        {"Name": "IdPoint.RS-485HD.Protocol",
        "Value": "OSDP"} ]
  }]
}

<axtid:IdPointConfiguration token="">
<axtid:Configuration>
<axconf:Name>IdPoint.Reader.Type</axconf:Name>
<axconf:Value>RS-485HD</axconf:Value>
</axtid:Configuration>
<axtid:Configuration>
<axconf:Name>IdPoint.RS-485HD.Protocol</axconf:Name>
<axconf:Value>OSDP</axconf:Value>
</axtid:Configuration>
<axtid:DeviceUUID></axtid:DeviceUUID>
<axtid:IdDataConfiguration></axtid:IdDataConfiguration>
</axtid:IdPointConfiguration>

The RS-485HD IoUser can now be assigned using the I/O Assignment service, see I/O assignment service.

Step1: Start by adding a key to the key store, by issuing the following to the axkey service:

{
	"axkey:SetEncryptionKey": {
		"axkey:EncryptionKey": [
			{
				"Name": "My key name",
				"Description": "My key description",
				"token": "my_key",
				"Key": "00010203040506070809101112131415"
			}
		]
	}
}

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:key="http://www.axis.com/vapix/ws/KeyStore">
<soap:Header/>
  <soap:Body>
    <key:SetEncryptionKey>
      <!--1 or more repetitions:-->
      <key:EncryptionKey token="my_key">
      <key:Key>00010203040506070809101112131415</key:Key>
      <!--Optional:-->
      <key:Name>My key name</key:Name>
      <!--Optional:-->
      <key:Description>My key description</key:Description>
      </key:EncryptionKey>
    </key:SetEncryptionKey>
  </soap:Body>
</soap:Envelope>

Step 2: Continue by configuring an IdPoint. Please refer to the IdPoint service for details:

{
	"axtid:SetIdPoint": {
		"IdPoint": [
			{
				"Name": "My OSDP SC IdPoint",
				"Action": "Access",
				"token": "osdp_sc_idpoint",
				"MaxPINSize": 4,
				"MinPINSize": 4
			}
		]
	}
}

<soap:Envelope	xmlns:soap="http://www.w3.org/2003/05/soap-envelope"	xmlns:idp="http://www.axis.com/vapix/ws/IdPoint">
  <soap:Header/>
  <soap:Body>
    <idp:SetIdPoint>
      <!--1 or more repetitions:-->
      <idp:IdPoint token="osdp_sc_idpoint">
        <idp:Name>My OSDP SC IdPoint</idp:Name>
        <!--Optional:-->
        <idp:Description></idp:Description>
        <idp:Location></idp:Location>
        <idp:Area></idp:Area>
        <!--Optional:-->
        <idp:Action>Access</idp:Action>
        <!--Optional:-->
        <idp:MinPINSize>4</idp:MinPINSize>
        <!--Optional:-->
        <idp:MaxPINSize>4</idp:MaxPINSize>
        <!--Optional:-->
        <idp:EndOfPIN></idp:EndOfPIN>>
        <idp:Timeout></idp:Timeout>
        <idp:HeartbeatInterval></idp:HeartbeatInterval>
      </idp:IdPoint>
    </idp:SetIdPoint>
  </soap:Body>
</soap:Envelope>
<>

Once the IdPoint is set, add an IdPointConfiguration, using the same token as in the call to tid:SetIdPoint. Note that there are further parameters for SetIdPointConfiguration - only those relevant to OSDP secure channel configuration are shown here. Please refer to IdPoint Service API for details.

{
	"axtid:SetIdPointConfiguration": {
		"IdPointConfiguration": [
			{
				"token": "osdp_sc_idpoint",
				"Configuration": [
					{
						"Name": "IdPoint.Reader.Type",
						"Value": "RS-485HD"
					},
					{
						"Name": "IdPoint.RS-485HD.Protocol",
						"Value": "OSDP"
					},
					{
						"Name": "IdPoint.SecureChannel.KeyToken",
						"Value": "my_key"
					},
					{
						"Name": "IdPoint.SecureChannel.KeyType",
						"Value": "KeyBase"
					}
				]
			}
		]
	}
}

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:idp="http://www.axis.com/vapix/ws/IdPoint" xmlns:con="http://www.axis.com/vapix/ws/Config">
<soap:Header/>
  <soap:Body>
    <idp:SetIdPointConfiguration>
      <!--1 or more repetitions:-->
      <idp:IdPointConfiguration token="osdp_sc_idpoint">
      <idp:DeviceUUID></idp:DeviceUUID>
      <!--Zero or more repetitions:-->
      <idp:IdDataConfiguration></idp:IdDataConfiguration>
      <!--Zero or more repetitions:-->
        <idp:Configuration>
        <con:Name>IdPoint.Reader.Type</con:Name>
        <con:Value>RS-485HD</con:Value>
        </idp:Configuration>
        <idp:Configuration>
        <con:Name>IdPoint.RS-485HD.Protocol</con:Name>
        <con:Value>OSDP</con:Value>
        </idp:Configuration>
        <idp:Configuration>
        <con:Name>IdPoint.SecureChannel.KeyToken</con:Name>
        <con:Value>my_key</con:Value>
        </idp:Configuration>
        <idp:Configuration>
        <con:Name>IdPoint.SecureChannel.KeyType</con:Name>
        <con:Value>KeyBase</con:Value>
        </idp:Configuration>
      </idp:IdPointConfiguration>
    </idp:SetIdPointConfiguration>
  </soap:Body>
</soap:Envelope>

The IdPoint is now configured to use the key with the token my_key from the keystore (the value of this key is 00010203040506070809101112131415). We have also specified that we will use this key as a base key (no diversification using cUID). Valid values for KeyType are KeyBase, KeyMaster or None. Once the steps above have been completed, the rest of the setup may be done as usual, to get a working system (IO assignments, doors, access points, credentials and users).

A REX device can be represented as a standalone IdPoint or be added to an IdPoint that already has a reader. It is possible to connect an unlimited amount of REX devices to the same IdPoint using the I/O Assignment service, see I/O assignment service guide.

Here is an example of an IdPoint that contains only a REX device. The REX device is active when the circuit is closed.

{"IdPointConfiguration": [{
  "token": "",
  "DeviceUUID": "",
  "IdDataConfiguration": [""],
  "Configuration": [ {"Name": "IdPoint.Reader.Type",
        "Value": "None"},
        {"Name": "IdPoint.REX.Type",
        "Value": "ActiveLow"} ]
  }]
}

<axtid:IdPointConfiguration token="">
  <axtid:Configuration>
    <axconf:Name>IdPoint.Reader.Type</axconf:Name>
    <axconf:Value>None</axconf:Value>
  </axtid:Configuration>
  <axtid:Configuration>
    <axconf:Name>IdPoint.REX.Type</axconf:Name>
    <axconf:Value>ActiveLow</axconf:Value>
  </axtid:Configuration>
  <axtid:DeviceUUID></axtid:DeviceUUID>
  <axtid:IdDataConfiguration></axtid:IdDataConfiguration>
</axtid:IdPointConfiguration>

When this has been set, a REX IoUser has been created for this IdPoint that can be assigned to one or more physical pins.

The general format for the IdDataFieldMap is <Format>, <Format>, ...

where <Format> is described in the table below.

All the chunks will then be added together to form the value of the map. The most common case will be to use a single M-N format for each IdDataFieldMap. The constant data is only useful for adapting to legacy systems.

The table below shows the available encodings.

This section is an example for the H10301 format.

The table shows the data field mapping. Note that the CardNrHex is supplied as an example to show that it is possible to use the same bits but with different encodings (compare with CardNr).

Let us assume that the 26 bits received from the reader are:

1 0000 0000 0010 0111 1110 0101 1

This will generate key/value pairs as described in the table below. Note that the complete raw data is always automatically encoded as hexadecimal and supplied in the Card field.

The complete axtid:SetIdDataConfiguration request would look like:

{
  "axtid:SetIdDataConfiguration":{
    "IdDataConfiguration":[ {
      "token":"",
      "InputBitlength":26,
      "Name":"IdDataConfig example",
      "IdDataFieldMap": [ {
        "Map": "1-26",
        "Name": "FullCard",
        "Encoding":"BinLE2hex"
      },{
        "Map":"1",
        "Name":"ParityEven",
        "Encoding": "BinLE2Int"
      }, {
        "Map": "2-9",
        "Name": "FacilityCode",
        "Encoding": "BinLE2Int"
      }, {
        "Map":"10-25",
        "Name": "CardNr",
        "Encoding": "BinLE2Int"
      }, {
        "Map": "10-25",
        "Name": "CardNrHex",
        "Encoding":"BinLE2hex"
      },{
        "Map":"26",
        "Name": "ParityOdd",
        "Encoding": "BinLE2Int"
      } ],
    "Description":"Test Description" } ]
  }
}

<axtid:SetIdDataConfiguration>
  <axtid:IdDataConfiguration token="">
    <axtid:Description>Test Description</axtid:Description>
    <axtid:IdDataFieldMap>
      <axtid:Encoding>BinLE2hex</axtid:Encoding>
      <axtid:Map>1-26</axtid:Map>
      <axtid:Name>FullCard</axtid:Name>
    </axtid:IdDataFieldMap>
    <axtid:IdDataFieldMap>
      <axtid:Encoding>BinLE2Int</axtid:Encoding>
      <axtid:Map>1</axtid:Map>
      <axtid:Name>ParityEven</axtid:Name>
    </axtid:IdDataFieldMap>
    <axtid:IdDataFieldMap>
      <axtid:Encoding>BinLE2Int</axtid:Encoding>
      <axtid:Map>2-9</axtid:Map>
      <axtid:Name>FacilityCode</axtid:Name>
    </axtid:IdDataFieldMap>
    <axtid:IdDataFieldMap>
      <axtid:Encoding>BinLE2Int</axtid:Encoding>
      <axtid:Map>10-25</axtid:Map>
      <axtid:Name>CardNr</axtid:Name>
    </axtid:IdDataFieldMap>
    <axtid:IdDataFieldMap>
      <axtid:Encoding>BinLE2hex</axtid:Encoding>
      <axtid:Map>10-25</axtid:Map>
      <axtid:Name>CardNrHex</axtid:Name>
    </axtid:IdDataFieldMap>
    <axtid:IdDataFieldMap>
      <axtid:Encoding>BinLE2Int</axtid:Encoding>
      <axtid:Map>26</axtid:Map>
      <axtid:Name>ParityOdd</axtid:Name>
    </axtid:IdDataFieldMap>
    <axtid:InputBitlength>26</axtid:InputBitlength>
    <axtid:Name>IdDataConfig example</axtid:Name>
  </axtid:IdDataConfiguration>
</axtid:SetIdDataConfiguration>

A hardware configuration needs to be in place due to the IndicateRemoteActivities-request body requiring a valid IdPoint-token to be able to send the IdPoint events.

For detailed information about configuring the hardware, see AXIS A1001 and AXIS Entry Manager User Manual.

The second step is the access decision that will be triggered by the tns1:IdPoint/tnsaxis:Request event.

To get a positive access decision the following criteria need to be met:

1. The Name/Value pairs of the params in the API request need to match the Name/Value pairs of the IdData in a credential and have the same ordering. This credential needs to be associated with an AccessProfile, AccessPoint and IdPoint, that matches the ID and AuthenticationProfile as seen in Setting the credential.

2. Each Name in the Params of the IndicateRemoteActivities request must match the IdDataName in the IdFactor list of an AuthenticationProfile that is associated with either the Credential, AccessPoint or AccessProfile mentioned above. For additional information, see Setting the access point, Setting the access profile and Retrieve default configuration in the Access Control Service Guide.

If a Card and a PIN is expected from physical access control system all the following parameters are granted access:

• IndicateRemoteActivities (Card) + IndicateRemoteActivities (PIN) (Separate API requests)

• IndicateRemoteActivities (Card + PIN) (Same API request)

• IndicateRemoteActivities (PIN + Card) (Same API request)

But this can be denied access:

• IndicateRemoteActivities (PIN) + IndicateRemoteActivities (Card) (Separate API requests)

The service capabilities reflect optional functionality of a service. The information is static and does not change during device operation. The following capabilities are available:

SetIdPoint

True if SetIdPoint and SetIdPointList is supported.

This operation returns the capabilities of the IdPoint service.

An ONVIF compliant device which provides the IdPoint service shall implement this method.

The IdPointInfo type represents the IdPoint as a physical object. The structure contains information and capabilities of a specific idpoint instance. An ONVIF compliant device shall provide the following fields for each IdPoint instance:

Token

A service-unique identifier of the IdPoint.

Name

Name of the structure.

Location

Text description of location of IdPoint.

Area

The Area the IdPoint is in.

Capabilities

The capabilities for this IdPoint.

To provide more information, the device may include the following optional field:

Description

Description of the structure

IdPointCapabilities reflect optional functionality of a particular physical entity. Different IdPoint instances may have different set of capabilities. This information may change during device operation, e.g. if hardware settings are changed. The following capabilities are available:

Configurable

True if the IdPoint settings can be modified

SupportCard

True if the IdPoint support reading Card data

SupportPIN

True if the IdPoint support PIN/keypad entry.

SupportREX

True if the IdPoint support/has a REX input.

SupportBiometric

True if the IdPoint support/has some kind of Biometric input.

SupportedMessageTypes

List of supported mime types for Message in FeedbackMessage function, e.g. text/plain - but may be an empty list.

SupportedGraphicsTypes

List of supported mime types for Graphics in FeedbackMessage function, e.g. image/jpeg, image/png - but may be an empty list.

SupportedAudioTypes

List of supported Audio formats in FeedbackMessage function, e.g. audio/basic, audio/mp3

AdditionalCapabilities

General list of supported features, currently not specified in the specification.

This operation requests a list of all of IdPointInfo items provided by the device. An ONVIF compliant device which provides the IdPoint service shall implement this method.

The returned list shall start with the item specified by a StartReference parameter. If it is not specified by the client, the device shall return items starting from the beginning of the dataset.

StartReference is a device internal identifier used to continue fetching data from the last position, and shall allow a client to iterate over a large dataset in smaller chunks. The device shall be able to handle a reasonable number of different StartReferences at the same time and they must live for a reasonable time so that clients are able to fetch complete datasets.

An ONVIF compliant client shall not make any assumptions on StartReference contents and shall always pass the value returned from a previous request to continue fetching data. Client shall not use the same reference more than once.

For example, the StartReference can be incrementing start position number or underlying database transaction identifier.

The returned NextStartReference shall be used as the StartReference parameter in successive calls, and may be changed by device in each call.

The number of items returned shall not be greater than Limit parameter. If Limit parameter is not specified by the client, the device shall assume it unbounded. The number of returned elements is determined by the device and may be less than requested if the device is limited in its resources.

This operation request a list of IdPointInfo items matching the given tokens. An ONVIF-compliant device that provides IdPoint service shall implement this method.

The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens.

If the number of requested items is greater than the max limit supported, a TooManyItems fault shall be returned

The IdPoint type provides the full configuration for an id point.

The following fields are available:

Token

A service-unique identifier of the IdPoint.

Name

Name of the structure.

Location

Text description of location of IdPoint.

Area

The Area the IdPoint is in.

Timeout

Timeout between user interactions.

HeartbeatInterval

The time between heartbeat event updates. A time of 0 means no heartbeat events.

To provide more information, the device may include the following optional fields:

Description

Description of the structure.

Action

The default action the IdPoint want to do. If not set, assume "Access".

MinPINSize

Minimum number of characters in the PIN.

MaxPINSize

Maximum number of characters in the PIN.

EndOfPIN

String/character that ends a PIN and trigs sending of PIN.

This operation requests a list of all of IdPoint items provided by the device. An ONVIF compliant device which provides the IdPoint service shall implement this method.

The returned list shall start with the item specified by a StartReference parameter. If it is not specified by the client, the device shall return items starting from the beginning of the dataset.

StartReference is a device internal identifier used to continue fetching data from the last position, and shall allow a client to iterate over a large dataset in smaller chunks. The device shall be able to handle a reasonable number of different StartReference:s at the same time and they must live for a reasonable time so that clients are able to fetch complete datasets.

An ONVIF compliant client shall not make any assumptions on StartReference contents and shall always pass the value returned from a previous request to continue fetching data. Client shall not use the same reference more than once.

For example, the StartReference can be incrementing start position number or underlying database transaction identifier.

The returned NextStartReference shall be used as the StartReference parameter in successive calls, and may be changed by device in each call.

The number of items returned shall not be greater than Limit parameter. If Limit parameter is not specified by the client, the device shall assume it unbounded. The number of returned elements is determined by the device and may be less than requested if the device is limited in its resources.

This operation request a list of IdPoint items matching the given tokens. An ONVIF-compliant device that provides IdPoint service shall implement this method.

The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens.

If the number of requested items is greater than the max limit supported, a TooManyItems fault shall be returned

Set a list of IdPoints. If the specified token in an IdPoint is empty, a new unique token is created by the service. If an IdPoint with the specified token already exist it will be updated. If the token does not exist, a new IdPoint is created. The list of supplied or created tokens is returned.

Remove the IdPoints specified by the Tokens.

The IdPointFeedback type enumerates the different type of feedback profiles. The actual implementation of these profiles is defined by the vendor and out of scope for ONVIF. Typically InvalidCredential, AccessDenied, Fault, Warning and Alarm would give "negative" feedback involving red LED and buzzer.

The following values are available:

Other

The feedback mode is specified in some other defined way.

Idle

Normal state - typically DoorLocked or DoorUnlocked is used instead (if the IdPoint controls a door).

DoorLocked

Indicates that the Door is locked.

DoorUnlocked

Indicates that the Door is unlocked.

DoorOpenTooLong

Indicates that the Door is open too long.

DoorPreAlarmWarning

Indicates that the Door soon is open too long.

RequirePIN

PIN (Personal Identification Number/Code) is required.

RequireCard

Card is required.

Processing

Processing in progress.

InvalidCredential

Credential is not valid.

AccessGranted

Access is granted.

AccessDenied

Access is denied.

Ok

Generic Ok indication

Fault

Generic fault indication

Warning

Generic Warning indication.

Alarm

Generic Warning indication.

Custom

Some custom mode.

Control how the IdPoint specified by the Token should give feedback.

The device and hardware configuration for an IdPoint.

The following fields are available:

Token

IdPoint Id to use for set, remove and usage.

DeviceUUID

What device the IdPoint is on.

IdDataConfiguration

Reference to the IdDataConfigurations to use.

Configuration

Configuration for the IdPoint.

This operation requests a list of all of IdPointConfiguration items provided by the device. An ONVIF compliant device which provides the DoorControl service shall implement this method.

The returned list shall start with the item specified by a StartReference parameter. If it is not specified by the client, the device shall return items starting from the beginning of the dataset.

StartReference is a device internal identifier used to continue fetching data from the last position, and shall allow a client to iterate over a large dataset in smaller chunks. The device shall be able to handle a reasonable number of different StartReferences at the same time and they must live for a reasonable time so that clients are able to fetch complete datasets.

An ONVIF compliant client shall not make any assumptions on StartReference contents and shall always pass the value returned from a previous request to continue fetching data. Client shall not use the same reference more than once.

For example, the StartReference can be incrementing start position number or underlying database transaction identifier.

The returned NextStartReference shall be used as the StartReference parameter in successive calls, and may be changed by device in each call.

The number of items returned shall not be greater than Limit parameter. If Limit parameter is not specified by the client, the device shall assume it unbounded. The number of returned elements is determined by the device and may be less than requested if the device is limited in its resources.

This operation request a list of IdPointConfiguration items matching the given tokens. An ONVIF-compliant device that provides IdPoint service shall implement this method.

The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens.

If the number of requested items is greater than the max limit supported, a TooManyItems fault shall be returned.

Add/update a list of IdPointConfiguration items, the token in the IdPointConfiguration should typically refer to an existing IdPoint.

Remove the IdPointConfiguration items specified by the tokens. This is normally not needed, since when removing an IdPoint, the configuration is removed as well - although it's possible to create configurations without a corresponding IdPoint.

Get the ConfigurationInfo for a single IdPoint specified by the token.

Get the last entered credential on this reader.

Specifies a configuration of how to map binary data input from a card reader or keypad to Request event messages.

The following fields are available:

token

Id used to reference the structure.

Name

Name of the configuration.

Description

Description of configuration.

InputBitlength

The number of bits the input data must have to use this configuration.

IdDataFieldMap

List of maps.

Specifies the different encoding of binary data possible.

The following values are available:

Other

For extendability, the encoding is specified some other way.

BinLE2hex

Binary data is encoded as hex-lowercase.

BinBE2hex

Binary data is encoded as hex-lowercase.

Bin2Base64

Binary data is encoded as base64.

Bin2String

Binary ASCII data is encoded as an URL encoded string.

BinLEBCD2String

Binary Little Endian BCD data is encoded as a numeric string.

BinBEBCD2String

Binary Big Endian BCD data is encoded as a string-

BinLE2Int

Binary data is encoded as an integer number, with Little Endian byte order.

BinBE2Int

Binary data is encoded as an integer number, with Big Endian byte order.

BinLEIBO2hex

Binary data with inversed byte order is encoded as hex-lowercase.

BinBEIBO2hex

Binary data with inversed byte order is encoded as hex-lowercase.

BinIBO2Base64

Binary data with inversed byte order is encoded as base64.

BinIBO2String

Binary with inversed byte order ASCII data is encoded as an URL encoded string.

BinLEIBO2Int

Binary data with inversed byte order is encoded as an integer number using Little Endian byte order.

BinBEIBO2Int

Binary data with inversed byte order encoded as an integer number using Big Endian byte order.

The configuration for how binary card data read by the IdPoint should be mapped to an IdData name and value.

The following fields are available:

Name

Name of the IdData field (e.g. UserNbr, SiteCode, FacilityCode).

Map

Location of the field in the binary carddata (e.g. b0101,10-25,3,5,7,1,2,4,xFEDEBEDA,). First bit is bit 1, that is the first received over e.g. a wiegand port. The symbol 0bBBB (e.g. 0b111) indicates a sequence of constant binary digits BBB. The symbol 0xh..h indicates a constant sequence of hex digits h..h. The hex digits is interpreted with MSB first. The symbol sSSSS indicates a constant string SSSS, if you want the comma character ',' use ,0x2c, which is the ASCII representation of comma.

Encoding

How the resulting bits is encoded to a Value.

This operation requests a list of all of IdDataConfiguration items provided by the device. An ONVIF compliant device which provides the DoorControl service shall implement this method.

The returned list shall start with the item specified by a StartReference parameter. If it is not specified by the client, the device shall return items starting from the beginning of the dataset.

StartReference is a device internal identifier used to continue fetching data from the last position, and shall allow a client to iterate over a large dataset in smaller chunks. The device shall be able to handle a reasonable number of different StartReference:s at the same time and they must live for a reasonable time so that clients are able to fetch complete datasets.

An ONVIF compliant client shall not make any assumptions on StartReference contents and shall always pass the value returned from a previous request to continue fetching data. Client shall not use the same reference more than once.

For example, the StartReference can be incrementing start position number or underlying database transaction identifier.

The returned NextStartReference shall be used as the StartReference parameter in successive calls, and may be changed by device in each call.

The number of items returned shall not be greater than Limit parameter. If Limit parameter is not specified by the client, the device shall assume it unbounded. The number of returned elements is determined by the device and may be less than requested if the device is limited in its resources.

This operation request a list of IdDataConfiguration items matching the given tokens. An ONVIF-compliant device that provides IdPoint service shall implement this method.

The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens.

If the number of requested items is greater than the max limit supported, a TooManyItems fault shall be returned.

Set (adds or modifies) the supplied list of IdDataConfiguration items to the internal storage/database. If the token attribute is empty, a new unique token will be generated by the service. All supplied and generated tokens are returned.

Remove the specified IdDataConfiguration from storage.

Get the current feedback message status of an IdPoint.

Get the current secure channel status for an IdPoint.

This operation request a list of IdPointWhiteList items matching the given tokens.

The device shall ignore tokens it cannot resolve and may return an empty list if there are no items matching specified tokens.

If the number of requested items is greater than the max limit supported, a TooManyItems fault shall be returned.

This operation requests a list of all of the IdPointWhiteList items provided by the device.

The returned list should start with the item specified by a StartReference parameter. If it is not specified by the client, the device shall return items starting from the beginning of the dataset.

StartReference is a device used for internal identifier and is used to fetch data from the last position, allowing the client to iterate over a large dataset in smaller chunks. The device shall be able to handle a reasonable number of different StartReferences at the same time and they must live for a reasonable time so that clients are able to fetch complete datasets.

A client shall not make any assumptions on StartReference contents and shall always pass the value returned from a previous request to continue fetching data. The client shall not use the same reference more than once.

For example, the StartReference can increment the start position number or the underlaying database transaction identifier.

The returned NextStartReference shall be used as the StartReference parameter in successive calls and may be changed by the device in each call.

The number of items returned shall not be greater than the Limit parameter. If the Limit parameter is not specified by the client, the device will assume that it is unbounded. The number of returned elements is determined by the device and may be less than requested if the device is limited in its resources.

Applies activities for a remote IdPoint. For each activity two IdPoint events are sent.

The first event is tns1:IdPoint/tnsaxis:Activity for all supported activities.

The Reason field for this event is:

• CardPresented for activity-type Card

• REX for activity-type REX

• CodeEntered for activity-type PIN

The second event for each activity is:

• tns1:IdPoint/tnsaxis:Request/tnsaxis:IdData for activity-type Card

• tns1:IdPoint/tnsaxis:Request/tnsaxis:REX for activity-type REX

• tns1:IdPoint/tnsaxis:Request/tnsaxis:PIN for activity-type PIN