GB/T 28181-2016 (GB/T 28181-2022 Newer Version) PDF English
GB/T 28181-2016 (GB/T28181-2016, GBT 28181-2016, GBT28181-2016)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GB/T 28181-2022 | English | 2330 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Technical requirements for information transmission,switch and control in video surveillance networking system for public security
| Valid |
| GB/T 28181-2016 | English | 1205 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Technical requirements for information transport, switch and control in video surveillance network system for public security
| Obsolete |
| GB/T 28181-2011 | English | RFQ |
ASK
|
3 days
|
[Replaced by GB/T 28181-2016] Security and protection video monitoring network system technical specification for information transport, switch and control
| Obsolete |
Newer version: GB/T 28181-2022 Standards related to (historical): GB/T 28181-2022
PDF Preview
GB/T 28181-2016: PDF in English (GBT 28181-2016) GB/T 28181-2016
GB
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 13.310
A 91
Replacing GB/T 28181-2011
Technical requirements for information transport,
switch and control in video surveillance network
system for public security
ISSUED ON: JULY 12, 2016
IMPLEMENTED ON: AUGUST 01, 2016
Issued by: General Administration of Quality Supervision, Inspection and
Quarantine;
Standardization Administration of PRC.
Table of Contents
Foreword ... 5
1 Scope ... 8
2 Normative references ... 8
3 Terms and definitions, abbreviations ... 10
3.1 Terms and definitions ... 10
3.2 Abbreviations ... 16
4 Interconnection structure ... 18
4.1 Interconnection structure of SIP surveillance domain ... 18
4.2 The interconnection structure of SIP surveillance domain and non-SIP
surveillance domain... 21
4.3 Communication protocol structure of networking system ... 23
5 Transmission requirements ... 25
5.1 Network transmission protocol requirements ... 25
5.2 Media transmission protocol requirements ... 25
5.3 Information transmission delay time ... 25
5.4 Network transmission bandwidth ... 25
5.5 Network transmission quality ... 26
5.6 Video frame rate ... 26
6 Exchange requirements ... 26
6.1 Uniform coding rules ... 26
6.2 Media compression codec... 27
6.3 Media storage encapsulation format ... 27
6.4 SDP definition ... 27
6.5 Conversion of network transmission protocol ... 27
6.6 Conversion of control protocol ... 28
6.7 Conversion of media transmission protocol ... 28
6.8 Conversion of media data format ... 28
6.9 Data exchange with other systems ... 28
6.10 Signaling character set ... 28
7 Control requirements ... 28
7.1 Registration ... 28
7.2 Real-time video-audio on-demand ... 29
7.3 Device control ... 29
7.4 Notification and distribution of alarm events ... 29
7.5 Device information query... 29
7.6 Status information report ... 30
7.7 Retrieval of historical video-audio files ... 30
7.8 Playback of historical video-audio ... 30
7.9 Download of historical video-audio files ... 30
7.10 Network timing... 31
7.11 Subscription and notification ... 31
7.12 Voice broadcast and voice intercom ... 31
8 Requirements for transmission, exchange, control security ... 31
8.1 Device identity authentication... 31
8.2 Data encryption ... 32
8.3 SIP signaling authentication ... 32
8.4 Data integrity protection ... 32
8.5 Access control ... 33
9 Control, transmission process and protocol interface ... 33
9.1 Registration and cancellation ... 33
9.2 Real-time video-audio on-demand ... 37
9.3 Device control ... 44
9.4 Notification and distribution of alarm events ... 47
9.5 Network device information query ... 49
9.6 Status information report ... 55
9.7 Device video-audio file retrieval ... 57
9.8 Playback of historical video-audio ... 58
9.9 Download of video-audio file ... 67
9.10 Timing ... 76
9.11 Subscription and notification ... 76
9.12 Voice broadcast and voice intercom ... 81
Appendix A (Normative) Command set of monitoring and alarming network
system control description protocol (MANSCDP) ... 90
Appendix B (Normative) Command set of monitoring and networking system
real-time streaming protocol (MANSRTSP) command set ... 138
Appendix C (Normative) RTP-based video-audio data encapsulation ... 142
Appendix D (Normative) Uniform coding rules ... 146
Appendix E (Normative) Video-audio coding/decoding technical requirements
... 151
Appendix F (Normative) SDP definition ... 160
Appendix G (Normative) Message format for the interface between networked
systems and other systems... 167
Appendix H (Normative) Digital digest signaling authentication process and
method ... 185
Appendix I (Normative) Certificate format and certificate revocation list format
... 188
Appendix J (Normative) Signaling message demonstration ... 192
Appendix K (Normative) Definition of subject header field ... 327
Appendix L (Normative) Video-audio media transmission based on TCP
protocol ... 328
Appendix M (Normative) Media stream keep-alive mechanism ... 329
Appendix N (Normative) Multi-response message transmission ... 330
Appendix O (Normative) Description of example of catalog query responses
... 331
Appendix P (Normative) Notification of inter-domain catalog subscription ... 336
References ... 344
Technical requirements for information transport,
switch and control in video surveillance network
system for public security
1 Scope
This standard specifies the basic requirements and security requirements for
the interconnection structure, transmission, exchange, control in video
surveillance network system for public security (hereinafter referred to as the
network system), as well as the technical requirements for control, transmission
processes and protocol interfaces.
This standard applies to the scheme design, system testing, acceptance of
video surveillance network system for public security, as well as the
development and production of related device.
2 Normative references
The following documents are essential to the application of this document. For
the dated documents, only the versions with the dates indicated are applicable
to this document; for the undated documents, only the latest version (including
all the amendments) is applicable to this standard.
GB/T 2260-2007 Codes for the administrative divisions of the Peoples
Republic of China
GB 2312 Code of Chinese graphic character set for information interchange;
Primary set
GB/T 2659-2000 Codes for the representation of names of countries and
regions
GB/T 7408-2005 Data elements and interchange formats - Information
interchange - Representation of dates and times
GB/T 25724-2010 Technical specification of surveillance video-audio coding
ISO/IEC 13818-1:2000 Information technology -Generic coding of moving
pictures and associated audio information - Part 1: Systems
ISO/IEC 14496-2:2004 Information technology - Coding of audio - visual
objects - Part 2: Visual
ISO/IEC 14496-2:2004/Amd.2:2005 Information technology - Coding of
audio-visual objects - Part 2: Visual (Technical Corrigendum 2)
ISO/IEC 14496-4:2004 Information technology - Coding of audio-visual
objects - Part 4: Conformance testing (available in English only)
ISO/IEC 14496-4:2004/Amd.10:2005 Information technology - Coding of
audio-visual objects - Part 4: Conformance testing (available in English only;
Technical Corrigendum 10)
ISO/IEC 14496-5:2001 Information technology - Coding of audio - Part 5:
Referenced software
ITU-T Rec. G. 711-1988 Pulse code modulation (PCM) of voice frequencies
ITU-T Rec. G. 722.1-1999 A new low-complexity 14 kHz audio coding
standard
ITU-T Rec. G. 723.1-1996 Dual rate speech coder for multimedia
communications transmitting at 5.3 and 6.3 kbit/s
ITU-T Rec. G. 729-1996 Coding of speech at 8 kbit/s using conjugate-
structure algebraic-code-excited linear prediction (CS-ACELP)
ITU-T Rec. H. 264-2005 H series: Audio, video and multimedia systems -
Audio and video service basics - Active video coding: Advanced video
coding for generic audio visual services
ITU-TRec.H.264.1-2005 H series: Audio, video and multimedia systems -
Audio and video service basics - Active video coding: Conformance
specification for H.264 advanced video coding
IETF RFC 2030 Simple network time protocol (SNTP) version 4 for IPv4,
IPv6 and OSI
IETF RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video
IETF RFC 2326-1998 (RTSP) Real Time Streaming Protocol
IETF RFC 2327 SDP: Session Description Protocol
IETF RFC 2976 The SIP INFO Method
IETF RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams
IETF RFC 3261-2002 SIP: Session Initiation Protocol
which is converted by DVR, DVS and other transcoding device from the analog
video-audio signal of the front-end analog camera, to the surveillance center
through the digital transmission channel.
3.1.8
Analog access
The access method of the front-end device or regional surveillance alarm
system transmitting analog video-audio signals to the surveillance center
through the analog transmission channel.
3.1.9
Analog and digital surveillance system
The surveillance systems which have both analog and digital signal control
and processing methods.
3.1.10
Digital surveillance system
The surveillance system which has only the digital signal control and
processing methods.
3.1.11
Session initiation protocol; SIP
A framework protocol for multi-party multimedia communication formulated
by the Internet Engineering Task Force.
Note: It is a text-based application layer control protocol, independent of the
underlying transmission protocol, used to establish, modify, terminate two-party or
multi-party multimedia sessions on the IP network. Internet Engineering Task Force,
namely IETF.
3.1.12
Session control
The process of establishing, modifying, or ending communication between
one or more participants.
3.1.13
SIP surveillance realm
A request message may be transmitted through several proxy servers, each
proxy server determines the route independently; the response message is
transmitted in the opposite direction of the request message.
3.1.19
Register server
The SIP logical entity as specified by IETF RFC 3261, which is a functional
server that receives registration requests, saves the information carried in
the requests, provides location services in the domain.
3.1.20
Redirect server
SIP logical entity specified by IETF RFC 3261, which is responsible for
planning SIP call routing. It tells the caller the next hop address information
it has obtained, so that the caller sends a request directly to the next hop
based on this address, then the redirect server exits the call process.
3.1.21
Back-to-back user agent
SIP logical entity as specified by IETF RFC 3261, which acts as a user agent
server (UAS) to receive the request message and process the message. At
the same time, in order to determine how to respond to the request message,
it also acts as a user agent client (UAC) to send the request message.
Note: The difference between a back-to-back user agent (B2BUA) and a proxy
server is that B2BUA needs to maintain a conversation state it creates.
3.1.22
Functional entity
A collection of logical units that implement some specific functions.
Note: A physical device can be composed of multiple functional entities; a functional
entity can also be composed of multiple physical devices.
3.1.23
Source device/target device
The source device represents the party that actively initiates the
conversation; the target device represents the party that ultimately responds
Provide real-time media stream forwarding services, media storage,
historical media information retrieval and on-demand services. The media
server receives media data from SIP devices, gateways or other media
servers; forwards these data to other single or multiple SIP clients and media
servers according to commands.
3.1.28
Secure signal routing gateway
It has the function of receiving or forwarding SIP signaling within and outside
the domain, completing the transfer of routing information between signaling
security routing gateways, and performing addition and identification of
routing signaling and signaling identity. It is a SIP server with security
functions.
3.1.29
Cascaded networking
The two signaling security routing gateways are connected in accordance
with the subordinate relationship. The central signaling control server of
higher level can call the surveillance resources managed by the lower central
signaling control server through the signaling secure routing gateway, whilst
the lower central signaling control server can use signaling secure routing
gateway to upload the surveillance resources managed by the central
signaling control server at the same level to the central signaling control
server at the higher level or shares the upper level resources.
3.1.30
Peer-to-peer networking
Two signaling security routing gateways are connected according to a level
relationship; the central signaling control server can mutually call the
surveillance resources of the other central signaling control server with
authorization.
3.2 Abbreviations
The following abbreviations apply to this document.
AES: Advanced Encryption Standard
B2BUA: Back to Back User Agent
CIF: Common Intermediate Format
Interconnected system platforms and devices shall not send application-
independent messages to each other’s SIP ports, to avoid application-
independent messages occupying the system platform and device’s SIP
message processing resources.
This standard is based on basic protocols such as IETF RFC 3261, to regulate
the various business functions related to surveillance networking. If there are
special provisions in this standard, each function shall follow this standard;
otherwise it shall follow the reference protocol such as IETF RFC 3261.
4.3.3 Session description protocol
The session negotiation and media negotiation in the process of establishing a
session between devices in a networked system shall be described by the IETF
RFC 4566 protocol. The main content includes session description, media
information description, time information description. The session negotiation
and media negotiation information shall be carried and transmitted in the
message body of the SIP message.
4.3.4 Control description protocol
Control commands related to front-end device control, alarm information,
device catalog information, etc. of the networked system shall be described by
the Monitoring and Alarm Networking System Control Description Protocol
(MANSCDP), as shown in Appendix A. Networking system control commands
shall be carried and transmitted in the message body of the SIP message.
4.3.5 Media playback control protocol
The playback control commands of historical video-audio shall use the
Monitoring Alarm Networking System Real-Time Streaming Protocol
(MANSRTSP). The protocol description is as shown in Appendix B, to realize
the remote control such as normal playback, fast, pause, stop, random drag of
the video-audio stream from end to end. The playback control commands of
historical media are carried and transmitted in the message body of the SIP
message Info.
4.3.6 Media transmission and media codec protocol
The media stream shall support RTP transmission when it is transmitted on the
IP network of the networked system. The media stream sending source shall
support the function of controlling the peak value of the media stream. The RTP
payload shall adopt one of the following two formats: video-audio data based
on PS package or video-audio elementary stream data, as shown in Appendix
C. The transmission of media streams shall use the RTP protocol as specified
by IETF RFC 3550, to provide time stamp information in real-time data
transmission and the synchronization of each data stream. It shall use the
transmission bandwidth of the front-end device connected to the surveillance
center shall be not less than 512 kbps. The single-channel network
transmission bandwidth of the front-end device connected to the surveillance
center in important places shall not be less than 2 Mbps. The single-channel
network transmission bandwidth between the surveillance centers at all levels
shall not be less than 2.5 Mbps.
5.5 Network transmission quality
The transmission quality of the IP network of the networking system (such as
transmission delay, packet loss rate, packet error rate, false packet rate, etc.)
shall meet the following requirements:
a) The upper limit of network delay is 400 ms;
b) The upper limit of delay jitter is 50 ms;
c) The upper limit of the packet loss rate is 1 × 10-3;
d) The upper limit of the packet error rate is 1 × 10-4.
5.6 Video frame rate
The video frame rate that can be supported during local recording shall not be
less than 25 frames/s. When the image format is CIF, the video frame rate of
network transmission shall not be less than 25 frames/s. When the image
format is 4CIF or more, the video frame rate transmitted over the network shall
be no less than 15 frames/s; the important image information should be 25
frames/s.
6 Exchange requirements
6.1 Uniform coding rules
6.1.1 ID uniform coding rules
The networked system shall uniformly code the front-end device, surveillance
center device, user terminal ID; the code is globally unique. Coding shall adopt
coding rule A (20-digit decimal digital character coding), as shown in D.1. Local
application systems may also use coding rule B (18-digit decimal digital
character coding), as shown in D.2. The communication between the
management platform of the networked system, as well as the communication
between the management platform and other systems shall adopt the uniform
6.6 Conversion of control protocol
It shall support the two-way protocol conversion between the device control
protocol of the non-SIP surveillance domain and the session initiation protocol,
session description protocol, control description protocol, media playback
control protocol as specified in 4.3.
6.7 Conversion of media transmission protocol
It shall support the two-way protocol conversion between the media
transmission protocol and data encapsulation format of the non-SIP
surveillance domain and the media transmission protocol and data
encapsulation format as specified in 5.2.
6.8 Conversion of media data format
It shall support the conversion of media data in non-SIP surveillance domains
into data conforming to the media encoding format as specified in 6.2.
6.9 Data exchange with other systems
The networked system provides interfaces with other application systems such
as the integrated alarm handling system and tollgate system through the access
gateway. The basic requirements, functional requirements, data specifications,
transmission protocols and extension methods of the interface shall meet the
requirements of Appendix G. The message format of the networked system and
other system interfaces shall meet the requirements of Appendix G.
6.10 Signaling character set
The SIP signaling character set of networked systems and device shall adopt
the encoding format of GB 2312.
7 Control requirements
7.1 Registration
It shall support the working mode of registering with SIP server when the device
or system enters the networked system.
If the registration of the device or system is unsuccessful, it should be delayed
for a certain random time and then re-register.
Refer to 9.1 for the session control process of device or system registration.
7.2 Real-time video-audio on-demand
It shall support real-time on-demand video on designated device and
designated channels; support simultaneous on-demand video on the same
image resource by multiple users.
See 9.2 for the session control process of real-time video-audio on-demand;
the session description information uses the format as specified in 6.4.
7.3 Device control
It shall support sending control information to designated device, such as
dome/pan-tilt control, video control, arming/disarming of alarm device, etc., to
achieve remote control of various actions of the device.
The session control process of device control is as shown in 9.3. The device
control command adopts the XML format as specified in Appendix A.
7.4 Notification and distribution of alarm events
It shall be able to receive the alarm information sent by the alarm source in real
time, distribute the alarm information to the corresponding user terminal or
system and device in time according to the alarm handling plan.
Refer to 9.4 for the session control process of receiving and distributing alarm
information. The alarm event notification command adopts the XML format as
specified in Appendix A.
7.5 Device information query
It shall support hierarchical query and obtain catalog information and status
information of registered devices or systems in the networked system. The
device catalog information includes device ID, device name, device
manufacturer name, device model, device address, device password, device
type, device status, device installation address, device attribution unit, parent
device ID and other information.
Refer to 9.5.2 for the session control process of the device catalog query. The
See 9.9 for the historical video-audio download process.
7.10 Network timing
The IP network server device in the networked system shall support the unified
network timing service of the NTP (see IETF RFC 2030) protocol. The network
timing device is divided into a clock source and a client; supports the
client/server working mode. The clock source shall support TCP/IP, UDP and
NTP protocols; it can output the input or self-generated time signal in a standard
NTP packet format.
The IP network access device in the networked system shall support the unified
timing of SIP signaling. The access device shall accept the time service carried
by the Date field of the message header from the SIP server during registration.
7.11 Subscription and notification
It should support subscription and notification mechanisms, events and catalog
subscriptions and notifications. See 9.11 for the specific protocol signaling
process.
7.12 Voice broadcast and voice intercom
It should support voice broadcast and voice intercom mechanism. See 9.12 for
protocol signaling flow.
8 Requirements for transmission, exchange, control
security
8.1 Device identity authentication
All device connected to the system shall be uniformly coded. For device coding
specifications, see the provisions in 6.1. Access device authentication shall
adopt different authentication methods according to different situations. For
non-standard SIP devices, it should be authenticated through the gateway.
In the case of low-level security applications, the password-based digital digest
authentication method shall be used to authenticate the device. For the
authentication process, see 9.1 and Chapter 22 of IETF RFC 3261-2002. In the
case of high-security applications, digital certificate-based authentication
method shall be used to authenticate the device identity. See 9.1 for the
8.5 Access control
The networked system shall realize unified user management and authorization.
On the basis of identity authentication, the system should adopt attribute-based
or role-based access control models to control user access. When accessing
across domains, the user identity information carried by the signaling Monitor-
User-Identity should be used for access control.
9 Control, transmission process and protocol
interface
9.1 Registration and cancellation
9.1.1 Basic requirements for registration and cancellation
SIP user agent (SIP UA) such as SIP clients, gateways, SIP devices,
networking systems use the Register method as defined in IETF RFC 3261 to
register and unregister. Authentication shall be carried out during registration
and cancellation. The authentication method shall support the digital digest
authentication method. The authentication method of digital certificate should
be supported for high security level. The format of the digital certificate
conforms to the provisions in Appendix I.
The SIP user agent shall refresh the registration with the registration server
before the registration expiration time arrives. The refresh registration message
process shall be consistent with the process description in 9.1.2.1, meanwhile
follow the provisions of IETF RFC 3261 on refresh registration.
If the registration fails, the SIP user agent shall continue to initiate the
registration process after a certain period of time. The time interval from the
previous registration shall be adjustable. Generally, it shall not be shorter than
60 s.
The expiration time of system and device registration shall be configurable; the
default value is 86400 s (1 d). The refresh registration message shall be sent
before the registration expiration time arrives; the SIP server shall reserve
appropriate refresh registration processing time. The registration expiration
time shall not be shorter than 3600 s.
If the SIP user agent's registration is successful, the SIP server is considered
to be online; if the registration fails, the SIP server is considered to be offline.
The SIP server considers it to be online after the SIP user agent's registration
is successful; it is considered offline when the SIP proxy registration expires.
a) 1: The SIP user agent sends a Register request to the SIP server; the
value of the Expires field is 0, indicating that the SIP user agent wants to
log out;
b) 2: The SIP server sends a response 401 to the SIP user agent; provides
the authentication system and parameters suitable for the SIP proxy in the
WWW_Authenticate field of the response message header;
c) 3: The SIP user agent sends a Register request to the SIP server again;
gives a letter of trust in the Authorization field of the request, including
authentication information; the value of the Expires field is 0;
d) 4: The SIP server verifies the request. If it checks that the SIP user agent
identity is legal, it sends a successful response 200 OK to the SIP user
agent. If the identity is illegal, it sends a denial of service response.
See J.3. for message demonstration.
9.2 Real-time video-audio on-demand
9.2.1 Basic requirements for real-time video-audio on-demand
Real-time video-audio on-demand SIP messages shall be routed and
forwarded through SIP servers in this domain or other domains. The real-time
video-audio streams of target devices shall be forwarded through media servers
in this domain.
Real-time video-audio on-demand uses the Invite method in the SIP protocol
(IETF RFC 3261) to achieve session connection; uses the RTP/RTCP protocol
(IETF RFC 3550) to achieve media transmission.
The signaling process of real-time audio-visual on-demand is divided into two
methods: the client initiates actively and the third-party call control. The
networked system can choose one or two combined implementation methods.
The third-party controller of third-party call control shall be implemented by
back-to-back user agents. For third-party call control, see IETF RFC 3725.
Real-time video-audio on-demand shall support the media stream keep-alive
mechanism as specified in Appendix M.
9.2.2 Command flow
9.2.2.1 Client initiatively initiated
The real-time video-audio on-demand process initiated by the client is as shown
in Figure 11.
The command flow is described as follows:
a) 1: The media stream receiver sends an Invite message to the SIP server.
The Subject field is carried in the message header field, indicating the on-
demand video source ID, the sender's media stream serial number, th......
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|