ISAPI_2.0 RaCM Service 用户指南：监控API与内容管理详解

需积分: 5 56 浏览量更新于2024-07-01 收藏 1.3MB PDF 举报

ISAPI_2.0-RaCM Service 用户指南是一份详细的技术文档，主要针对ISAPI_2.0-RaCMS（IP Surveillance API，即RaCM Part）的版本2.0，修订1，发布于2014年9月。这份文档涵盖了RaCM Service的核心功能和操作规范，旨在帮助用户理解和利用这款服务进行视频监控（DVR和NVR）设计以及内容管理。 1. **简介**：文档首先介绍了ISAPI_2.0-RaCM Service的主要目的，它可能是一种用于网络视频监控系统的接口，提供了一套统一的标准和规则来支持远程摄像头配置、内容管理和录制功能。 2. **规范与术语**：章节2详细阐述了相关术语和实体关系，包括术语定义（3.1），如DVR（Digital Video Recorder）和NVR（Network Video Recorder）等，以及实体之间的关联性，有助于用户理解技术架构。 3. **通用规则和指导**：第4节给出了关于设计DVR和NVR时需要考虑的一般原则，以及如何有效地管理输入源，比如远程摄像头的配置，确保系统的稳定性和兼容性。 4. **内容管理系统基础服务**：在第5章中，重点是/ISAPI/ContentMgmt服务，包括sourceSupport（5.1），其中提供了源支持的XML Schema定义，以及访问和操作方法。这涉及到数据的上传、管理和查询。 5. **内容管理能力**：章节6探讨了/ISAPI/ContentMgmt/Capabilities，可能涉及服务的功能列表，以便开发者了解其在内容管理上的可扩展性和兼容性。 6. **记录功能**：第7章深入到录制功能，如存储位置（/ISAPI/ContentMgmt/record/storageMounts）、录制配置（profile，7.2），以及对记录项（tracks）的定制配置，包括支持的扩展数据（7.3.1）、创建方法（7.3.2）和流媒体链接的隐含设置（7.3.3）。 7. **细节描述**：例如，7.3.4部分提到了RecordingSourceDescription，可能是指录制源的详细描述，这对于设置录像策略和元数据管理至关重要。 ISAPI_2.0-RaCM Service用户指南提供了关键的技术细节，适用于开发人员和系统管理员，他们需要根据这份文档来构建和维护一个高效、兼容的视频监控解决方案。通过遵循这些规则和指南，用户可以充分利用ISAPI_2.0-RaCMS提供的功能，确保监控系统的有效运作。

“bottom”

GET

/ISAPI/ContentMgmt/sourceSupport?send=middle

Similar to the two above tags, this tag

value indicates that the consumer

wants the last 1/3

(roughly) of the

source support list. RaCM devices

receiving this QSP should provide,

approximately, the final one-third of

the “CMSourceSupport” list data.

Please note that it is up to the RaCM

device on how to apportion the source

support info into ‘chunks’.

When a RaCM device receives a “send=head” request, the returned schema should only contain the

“MediaDeviceModelCount” element and its value. For all of the other QSP strings, the RaCM device is to

provide portions of the schema document that align on list element boundaries (i.e. manufacturer/make

boundaries). This apportioning scheme prohibits the use of the “mfgr=…” QSP, which is described in the

following section. The following examples are provided as additional descriptive information. These examples

are based on the example XML schema instance listed in the table at the top of Section

/ISAPI/ContentMgmt/sourceSupport.

Send ‘head’ Example:

(request)

GET /ISAPI/ContentMgmt/sourceSupport?send=head HTTP/1.1

… (response) HTTP/1.1 200 OK

Content-type:application/xml

Content-length :165

<?xml version="1.0" encoding="UTF-8"?>

</CMSourceSupport>

Send ‘top’ Example:

(request)

GET /ISAPI/ContentMgmt/sourceSupport?send=top HTTP/1.1

… (response) HTTP/1.1 200 OK

Content-type:application/xml

Content-length :<nnn>

<?xml version="1.0" encoding="UTF-8"?>

<MediaDeviceMgmtMode>Proxy</MediaDeviceMgmtMode>

</MediaDeviceSource>

</SupportedMediaDeviceList>

</CMSourceSupport>

Send ‘middle’ Example:

(request)

GET /ISAPI/ContentMgmt/sourceSupport?send=middle HTTP/1.1

… response)HTTP/1.1 200 OK

Content-type:application/xml

Content-length :<nnn>

<?xml version="1.0" encoding="UTF-8"?>

<MediaDeviceMfgr>ClearView</MediaDeviceMfgr>

<MediaDeviceMake>MaxView Series</MediaDeviceMake>

<MediaDeviceMgmtMode>Simple</MediaDeviceMgmtMode>

</MediaDeviceSource>

</SupportedMediaDeviceList>

</CMSourceSupport>

Send ‘bottom’ Example:

(request)

GET /ISAPI/ContentMgmt/sourceSupport?send=bottom HTTP/1.1

… (response) HTTP/1.1 200 OK

Content-type:application/xml

Content-length :<nnn>

<?xml version="1.0" encoding="UTF-8"?>

<MediaDeviceMfgr>ISAPI</MediaDeviceMfgr>

<MediaDeviceMake>Any ISAPI compliant IP Media device</MediaDeviceMake>

<MediaDeviceMgmtModel>Standard</MediaDeviceMgmtModel>

</MediaDeviceSource>

</CMSourceSupport>

The above examples are for reference. The data set they contain is hypothetical and relatively small for the

sake of simplicity. Please note that in these examples the RaCM device made its own arbitrary decision as to

where to subdivide the CMSourceSupport information of ‘top’ versus ‘middle’ versus ‘bottom’. Also note that the

“MediaDeviceModelCount” size varies since the number of IP media device models varied per response. The

next section describes the ability for consumers to ask for specific forms of information.

5.1.2.2 “mfgr=” Query String Parameter

The “mfgr=…” QSP enables consumers to ask for supported IP media device information related to a

specific manufacturer or standards organization. Consumers using this capability can ask for supported model

information related to a specific manufacturer or standard. An example request would look like:

GET /ISAPI/ContentMgmt/souceSupport?mfgr=GoodVision

This type of request instructs the RaCM to only return a “CMSourceSupport” schema instance that lists the

supported models for the manufacturer “GoodVision”. The following is an example of what is expected to be

returned:

…(request)

GET /ISAPI/ContentMgmt/sourceSupport?mfgr=std-cgi HTTP/1.1

… (response) HTTP/1.1 200 OK

Content-type:application/xml

Content-length :<nnn>

<?xml version="1.0" encoding="UTF-8"?>

<MediaDeviceMgmtMode>Proxy</MediaDeviceMgmtMode>

</MediaDeviceSource>

</SupportedMediaDeviceList>

</CMSourceSupport>

Please note that the manufacturer name string is treated in a case insensitive manner. Also, manufacturer

strings that contain spaces must use the W3C special character replacement scheme. For example, a fictitious

vendor named “Volcano Vision” would have a QSP that looks like “...mfgr=Volcano%20Vision…”. RaCM

devices must parse out, and convert, the special character symbols just like the processing associated with a

standard URI. Additionally, a consumer may place multiple “mfgr=…” QSPs in a request. For example:

GET /ISAPI/ContentMgmt/souceSupport?mfgr=std-cgi&mfgr=ONVIF is a valid REST URI for the

sourceSupport resource. The recommendation is that a consumer should not send more than 3 manufacturer

IDs per request. If a RaCM device cannot process the number of ‘mfgr’ QSPs sent in a single request, it should

return an HTTP status code of ‘503 Bad Request’.

6 /ISAPI/ContentMgmt/Capabilities

/ISAPI/ ContentMgmt /capabilities

General Resource v2.0

GET

Description

It is used to get device capability.

Query

None

Inbound Data

None

Success Return

Notes:

RacmCap XML Block

< RacmCap version="1.0" xmlns=“http://www.isapi.org/ver20/XMLSchema”>

7 /ISAPI/ContentMgmt/record

This section describes the REST Interfaces to configure the logical storage used for media archival, along

with the actual recording session configurations. A recording session is also known as a “track” in the RaCM

Device. A track archives media (Audio, Video, and Metadata) from a Source. The Source can be local (e.g.

DVR recording from a local analog port) or remote (e.g. IP Network Media Device).

7.1 /ISAPI/ContentMgmt/record/storageMounts

This REST Interface is used to configure the total storage available to the RaCM Device to be used to

archive media. This storage is described as a List of Mount points, along with root directories and sizes. There

is no affinity specified, at this time, with regards to assigning tracks or range of tracks

to a particular Disk or

Mount.

URI

/ISAPI/ContentMgmt/record/storageMounts

Type

Resource

RequirementL

evel

Basic

Function

Description of the REST method parameters and formats available to functionally manipulate

the ‘record/storage’ resource.

Methods

Query String(s)

Inbound Data

Return Result

GET

None

PUT

None

POST

None

<Mount>

DELETE

None

Notes

This resource is used to manage the total storage allocation and logical mounts of the

Recorder. It is allowable to DELETE the entire list, though any implementation is free to

return an error for that operation if that capability is undesirable.

Low level drive configuration should be done through “/ISAPI/System/storage”.

This resource manages the <MountList> XML object and follows the same scheme used for <TrackList>

manipulation and other similar examples from IPMD that manage a list-based XML resource (see

“ISAPI-REST List-Entry <id> Creation method”, below.). As such, GET and PUT methods are used to access

the entire <MountList>. POST is used (with a “dummy” <id> of 0) to create an individual entry within the list;

where the newly created <id> is returned in the <ResponseStatus> given for the POST request.

Once an <Mount> entry is created, it can be accessed by its <id>, using this resource:

剩余97页未读，继续阅读

oABiao

粉丝: 1
资源: 10

ISAPI_2.0 RaCM Service 用户指南：监控API与内容管理详解

HIKVISION ISAPI_2.0.2-RaCM Service.pdf

HIKVISION ISAPI_2.0-RaCM Service_Hikvision_

HIKVISION ISAPI_2.0-RaCM Service_Hikvision_源码.zip

ISAPI_2.0-IPMD Service.pdf

ISAPI_2.0-PTZ Service.pdf

ISAPI_2.0-Image Service.pdf

HIKVISION ISAPI_2.0-PTZ Service.pdf

HIKVISION ISAPI_2.0-IPMD Service.pdf

HIKVISION ISAPI-2.0-IPMD Service.pdf

ISAPI_2.0-Image Service_Hikvision_

最新资源