HOME Cart(0) Quotation About-Us Policy PDFs Standard-List
www.ChineseStandard.net Database: 189760 (18 Oct 2025)

GY/T 322.3-2019 English PDF

US$529.00 · In stock
Delivery: <= 5 days. True-PDF full-copy in English will be manually translated and delivered via email.
GY/T 322.3-2019: Audio applications of networks-open control architecture - Part 3: Protocol for TCP/IP networks
Status: Valid

Standard ID	Contents [version]	USD	STEP2	[PDF] delivered in	Standard Title (Description)	Status	PDF
GY/T 322.3-2019	English	529	Add to Cart	5 days [Need to translate]	Audio applications of networks-open control architecture - Part 3: Protocol for TCP/IP networks	Valid	GY/T 322.3-2019

PDF similar to GY/T 322.3-2019

Standard similar to GY/T 322.3-2019

GY/T 268.1 GY/T 268.2 GY/T 220.2 GY/T 322.2 GY/T 321 GY/T 322.1

Basic data

Standard ID	GY/T 322.3-2019 (GY/T322.3-2019)
Description (Translated English)	Audio applications of networks-open control architecture - Part 3: Protocol for TCP/IP networks
Sector / Industry	Radio, Film & TV Industry Standard (Recommended)
Classification of Chinese Standard	M60
Word Count Estimation	23,275
Date of Issue	2019
Date of Implementation	2019-04-28
Issuing agency(ies)	State Administration of Radio and Television

GY/T 322.3-2019: Audio applications of networks-open control architecture - Part 3: Protocol for TCP/IP networks

---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
(Open control architecture for network audio applications-Part 3. Protocols for TCP/IP networks) GY Radio and Television Industry Standards of the People's Republic of China Open control architecture for network audio applications Part 3. Protocols for TCP/IP networks Audio applications of networks-open control architecture- Part 3. Protocol for TCP/IP networks 2019-04-28 released 2019-04-28 Implementation Published by the State Administration of Radio and Television

Foreword ... II Introduction ... III 0.1 Overview ... III 0.2 Document Conventions ... III 1 Scope ... 1 2 Normative references ... 1 3 Terms, definitions and abbreviations ... 1 3.1 Terms and definitions ... 1 3.2 Acronyms ... 1 4 Minimal implementation ... 1 5 Protocol details ... 1 5.1 Initialization ... 2 5.2 Device Discovery ... 2 5.3 Equipment supervision ... 3 5.4 Device reset ... 4 5.5 Conventions ... 4 5.6 Protocol data unit ... 5 5.7 Protocol-specific data types ... 15 Appendix A (Informative) Data Type Index ... 17 Appendix B (informative) UML description of the protocol data unit (PDU) ... 18 References ... 19

Foreword

GY/T 322 "Open Control Architecture for Network Audio Applications" is divided into the following three parts. -Part 1. Framework; -Part 2. Class structure; -Part 3. Protocols for TCP/IP networks. This part is the third part of GY/T 322. This section is drafted in accordance with the rules given in GB/T 1.1-2009. This section refers to AES70-3-2015 "Open Control Architecture for Network Audio Applications Part 3. Protocols for TCP/IP Networks Conference ". Please note that some elements of this document may involve patents. The issuer of this document is not responsible for identifying these patents. This section is under the jurisdiction of the National Radio, Film and Television Standardization Technical Committee (SAC/TC 239). Drafting units of this section. China Central Radio and TV Station, State Administration of Radio and Television, Academy of Radio and Television Science, and State Administration of Radio and Television Radio and Television Planning Institute, Jiangsu Provincial Radio and Television General Station, Zhejiang Radio and Television Group, Suzhou Fuchuan Technology Co., Ltd., Beijing YingfuMeidi Technology Co., Ltd., Beijing Zhonghechuan New Technology Co., Ltd., Hangzhou Union Technology Co., Ltd., Shanghai Baibei Technology Development Co., Ltd. Company, Beijing Jebsen Century Technology Co., Ltd., and Suzhou University. The main drafters of this section. Qian Yuelin, Zhu Feng, Luo Pan, Pan Yu, Zhang Lei, Wang Lanlan, Pang Chao, Tang Feng, Zhang Wei, Deng Xiangdong, Dong Sheng Lai, He Jing, Sun Yanjun, Li Weimin, Chen Wu, Dong Xiaopo, Chen Qin, Tang Weiping, Chen Lide, Zhao Chongfeng, Xiao Zhongxuan.

Introduction

0.1 Overview This section supports remote monitoring of media devices that conform to an open control architecture in a TCP/IP network. The first part of the open control architecture is based on AES70-1-2015 "Open control architecture for network audio applications Part 1. Framework" The second part of the open control architecture defines the class structure of the open control architecture for media network monitoring. Part 2 is a reference Prepared by AES70-2-2015 "Open Control Architecture for Network Audio Applications Part 2. Class Structure" The third part of the open control architecture is based on AES70-3-2015 "Open control architecture for network audio applications Part 3. For "TCP/IP Network Protocol", the original English text can be obtained from 0.2 Document Conventions The general data types involved in this section are applicable to all protocols that conform to the open control architecture, and specific data types are only applicable to this Part Minute. For easy differentiation, the names of common data types are prefixed with "Oca", while the names of specific data types are prefixed with "Ocp1". Open control architecture for network audio applications Part 3. Protocols for TCP/IP networks

1 Scope

This section of GY/T 322 specifies the protocols used for TCP/IP networks. This section applies to monitoring of network audio applications.

2 Normative references

The following documents are essential for the application of this document. For dated references, only the dated version applies to this document. For undated references, the latest version (including all amendments) applies to this document. GY/T 322.1-2019 Open Control Architecture for Network Audio Applications Part 1. Framework GY/T 322.2-2019 Open Control Architecture for Network Audio Applications Part 2. Class Structure IETF RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses IETF RFC 4862 IPv6 Stateless Address Autoconfiguration IETF RFC 6335 Internet Assigned Numbers Authority (IANA) Registry for Service Name and Transport Protocol Port Number Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) IETF RFC 6762 Multicast DNS IETF RFC 6763 DNS-Based Service Discovery 3 Terms, definitions and abbreviations 3.1 Terms and definitions The following terms and definitions apply to this document. 3.1.1 Open control protocol; OCP A network protocol defined according to an open control architecture. 3.2 Acronyms The following abbreviations apply to this document. PDU Protocol Data Unit

4 Minimal implementation

Every device that complies with an open control architecture shall implement all of this section. The specific options included in this section are described in Chapter 5.

5 Agreement details

5.1 Initialization 5.1.1 IP address initialization When the device initializes the OcaNetwork or OcaStreamNetwork object (see GY/T 322.2-2019), it should perform 5.1.2, 5.1.3, The initialization steps described in 5.1.4. The ControlProtocol property value of the above object should be "OCP01". 5.1.2 IP address allocation method Devices that conform to the open control architecture should implement at least IPv4 or IPv6 network addressing standards. In this section, the symbols that implement IPv4 network addressing Devices with an open control architecture are called IPv4 devices. Devices that conform to the open control architecture that implement IPv6 network addressing are called IPv6 devices. The device can implement both IPv4 and IPv6, that is, it can be both an IPv4 device and an IPv6 device. Each IPv4 device should implement a DHCP client and use a DHCP server. Each IPv6 device should implement a DHCPv6 client and use DHCPv6 server. In the following, these clients and servers will be collectively referred to as IP address clients and IP address servers, respectively. If the device belongs to multiple IP subnets, it should set up an IP address client for each subnet. When the device is connected to a subnet, the device should Start the corresponding IP address client. If the IP address client connects to the IP address server during the address allocation timeout period, the device shall use the address assigned by the server. When no IP address server is found or the device does not implement an IP address client within the address allocation timeout period. a) IPv4 equipment should use the IPv4 link-local address defined in IETF RFC 3927; b) IPv6 devices should use IPv6 link-local addresses automatically generated by IPv6 as defined in IETF RFC 4862. When the device does not implement a link-local address, the IP address should be set manually. 5.1.3 Sockets and Ports After obtaining the IP address, the device shall establish a TCP listening socket to receive insecure sessions that conform to this section, or a TCP listening socket Words receive secure conversations that fit this section, or both are open at the same time. The device shall use TCP port numbers within the standard IANA dynamic port range (49152 to 65535, see IETF RFC 6335). Within this range, The device can bind insecure listening sockets to any available TCP port, and secure listening sockets to other available TCP ports port. These ports shall be announced, see 5.2.2. 5.2 Device discovery 5.2.1 Overview Device discovery is a mechanism for devices connected to the network that conform to the open control architecture to be known to the public access directory service. Other devices on the network can use a directory service to find and address devices. The discovery process of devices that conform to the open control architecture should have a service discovery architecture, where devices that conform to the open control architecture should go to the network The network service directory registers itself, and network entities that need to know the IP address of the device can obtain it through this directory. Service discovery should be implemented through DNS-based service discovery (see IETF RFC 6763). Note. Another common use of the term "discovery" refers to the discovery of device capabilities. In an open control architecture, function discovery is performed by the root and internal blocks of the device (If any) enumeration method implementation. Such an enumeration is a command response sequence of a normal open control architecture and has no special dependency on the type of network. Therefore, they are outside the scope of this section. For more information, see the details of the OcaBlock class in GY/T 322.1-2019 and GY/T 322.2-2019 A detailed description. 5.2.2 Service Discovery If a device conforming to the Open Control Architecture opens a listening socket to establish an insecure connection in accordance with this section, it shall be registered Into the following service types. _oca._tcp If a device conforming to the open control architecture opens a listening socket to establish a secure connection in accordance with this section, it shall be registered as The following service types. _ocasec._tcp For secure and insecure services, the registered service name should be the same as the OcaNetwork or OcaStreamNetwork object used to connect The NameAdvertised property is the same. If the name changes, the device should unregister the old service and register the new service with the new name. Registration can be done in any desired domain, in most applications it is recommended to register in the local domain. Registration with the local domain should use the Multicast DNS (mDNS) protocol (see IETF RFC 6762). When registering in the local domain, service name conflicts are automatically resolved by the DNS multicast protocol. When changing service names via multicast DNS to avoid conflicts When the service name has changed, the device should automatically update the NameAdvertised property. Note. When registering in a non-local domain, name conflicts are not automatically resolved. Therefore, if devices that conform to the open control architecture may register in a non-local domain, Choose a unique default service name. The port registered for the service should match the port selected by the device in 5.1.3. Following the recommendations of the IETF RFC 6763 Chapter 6 Release Tag, TXT records for insecure and secure registrations should contain at least two key/value pairs. First A key/value corresponds to. txtvers = 1 [OCA service registration version] The second key/value pair contains the version of the open control architecture and should be in the following format. protovers = x x is the decimal number of the open control architecture version specified by the device OcaDeviceManager object (see GY/T 322.2-2019). TXT records can contain more data, as long as the records contain the two key/value pairs mentioned above, and the data conforms to IETF RFC 6763 clause 6 Chapter explains the rules. The start field of the TXT record is shown in Figure 1. If the decimal version of the open control architecture is greater than 9, the second length field shall be 0C16. 0916 txtvers = 1 0B16 protovers = x Figure 1 TXT record start field The controller can perform a DNS-SD service browsing in the required domain to discover devices in the network that conform to the open control architecture and find "_Oca._tcp" service or "_ocasec._tcp" service, or both. Browsing in the local domain should use multicast DNS (see IETF RFC 6762). 5.3 Equipment supervision 5.3.1 Overview Device governance means relatively continuous (usually periodic) verification of the availability of devices on the network. Designs that meet the definitions in this section The device can be used to supervise connected devices that comply with the open control architecture. 5.3.2 Specifications Every device that complies with the open control architecture should implement a supervision mechanism; the controller can enable or disable the mechanism according to application requirements. At any time after the device establishes a secure or insecure connection, the controller can send a KeepAlive message to the device (see 5.6.5) Start the device supervision process. From that moment until power is lost or the device is reset, the device and controller should use the value of HeartbeatTime to ensure that the device and The controller sends a message every heartbeat time. The message can be a KeepAlive message or other messages. The HeartbeatTime value should be specified in the KeepAlive message and can be changed at any time. Device should support different for different connections HeartBeatTime value. Once the supervisory process is initiated, the controller and the device shall record the time interval between the receipt of messages conforming to this section for the established connection. If the length of time that the controller or device has not received a message equals three times the HeartBeatTime value, the connection should be considered lost and the controller or device should shut down. Close the connection. Applications of key open control architectures should use the KeepAlive mechanism instead of relying on TCP/IP to detect connection loss. Example. If the HeartBeatTime value in the first KeepAlive message sent by the controller is 2 seconds, the controller and the device must send a message every two seconds. If 6 seconds If no message is received, the device and controller will consider the connection lost. Note. If the controller does not send a KeepAlive message after the connection is established, the connection does not start the device supervision mechanism. In this case, unless TCP is detected Keep the mechanism active, otherwise no connection loss detection will be performed on idle connections (that is, the connection has no control flow). TCP protection under typical parameter setting conditions The detection timeout with the activation mechanism is too long, which is unacceptable and often takes several hours. Also, not all TCP/IP protocol stacks work correctly Implement a keep-alive mechanism. When the connection is lost, the controller and device should perform appropriate termination processing if possible. Locks and subscriptions on the connection should be removed, and Clear the connection information. 5.4 Device reset 5.4.1 Overview Devices that conform to the open control architecture can implement a device reset mechanism. 5.4.2 Reset not implemented If the device does not implement the reset mechanism, it shall respond to the SetResetKey message in a NotImplemented state and perform no other operations. no Then, operate according to 5.4.3. 5.4.3 Resetting After power-on reset, the device should disable the reset mechanism. To enable the reset mechanism, the controller should first call the device's OcaDeviceManager to Like the SetResetKey method. When calling SetResetKey, the controller should pass the following parameters. ResetKey. a 128-bit device reset check code; ResetAddress. The device shall listen to the OcaNetworkAddress (see 5.7.2) of the DeviceReset message (see 5.6.6). The address Should include a UDP port number data type, and optionally an IPv4 or IPv6 multicast address. When receiving the message of SetResetKey, the device should configure the relevant mechanism to open a UDP socket on the port specified by the ResetAddress parameter. If the ResetAddress parameter also specifies a multicast address, the device should join the specified multicast group. If multiple SetResetKey messages are received, the parameters given in the latest SetResetKey message shall be used. Once the reset mechanism is configured, the device should listen for a UDP socket used to obtain a DeviceReset message containing the given device reset check code. word. If such a reset message is received, the device should perform a power-on reset. If the given ResetAddress does not contain a multicast address, The reset message will be sent directly to the device through the specified port. If ResetAddress contains a multicast address, the reset message will be sent directly Send to the specified port of the device or the specified port of the multicast group. If the DeviceReset message received contains a reset check code value other than the specified message, the message shall be ignored and no reset operation performed. After the device is reset or turned off, the device should release its reset mechanism. This mechanism can be reconfigured by the process described above. Note. If the device's reset check code is sent over an insecure Open Control Protocol (OCP) connection, it may be intercepted and used maliciously, resulting in a system damage. When it is necessary to use the device reset mechanism in a threatening environment, the SetResetKey message should only be sent over a secure OCP connection. Devices that implement the device reset mechanism should provide manual methods (such as switch, jumper, or panel commands) to disable the function. 5.5 Conventions 5.5.1 Byte Order For basic integer data types conforming to the open control architecture and floating-point data types with a word length of more than 1 byte, this section shall use the net. Network byte order (ie big-endian or high-end first). 5.5.2 Encapsulation Rules The OcaBoolean type should be encapsulated as a single byte, where the value 0 represents a Boolean value of false, and all other values represent a Boolean value of true. A single attribute of the composite data type defined in GY/T 322.2-2019 (that is, converted to a network byte stream) should use GY/T 322.2- Data type definitions in.2019 are encapsulated. The interface defined in GY/T 322.2-2019 is applicable to the following encapsulation rules. -The number of class method input parameters should pass the parameterCount property in the Ocp1Parameters structure in Ocp1Command Pass, see 5.6.2; --The input parameters of the method should be in the order specified in GY/T 322.2-2019, and encapsulated in Ocp1Parameters In the structure, see 5.6.2; -The number of class method output parameters should pass the parameterCount property in the Ocp1Parameters structure in Ocp1response Pass, see 5.6.3; --Method output parameters should be in the order specified in GY/T 322.2-2019 and encapsulated in Ocp1Parameters In the structure, see 5.6.3; -The number of event parameters should be added to the parameterCount attribute in the Ocp1ntfparams structure in Ocp1Notification; --The event parameters should be in the order specified in GY/T 322.2-2019, and encapsulated in Ocp1NtfParams For the Ocp1EventData structure in the structure, see 5.6.4. Note. See Appendix A for the index of data types used in this section. 5.5.3 Examples Consider the OcaClassIdentification composite data type, which is defined in OCC as follows. OcaClassIdentification = {OcaClassID ClassID, OcaClassVersionNumber ClassVersion} OcaClassID = {OcaUint16 FieldCount, OcaUint16 [] Fields} OcaClassVersionNumber = {OcaUint16 Value} Now consider a specific class identity instance with the following values. OcaClassIdentification classIdentification = { ClassID = {2, {1,3}}, ClassVersion = 1} Through the above encapsulation rules, the instance in the network will be represented as the following byte sequence (decimal value, sent first on the left). 0, 2, 0, 1, 0, 3, 0, 1 5.6 Protocol Data Unit 5.6.1 Message format 5.6.1.1 Overview Each message format conforming to this section is shown in Figure 2. Synchronization value Sync value Protocol header header data Data Protocol version ProtocolVersion Message size MessageSize Message type Message Type Message count MessageCount Figure 2 General message format The C language style of the message protocol data unit is defined as follows. struct { OcaUint8 syncVal; // message synchronization value Ocp1Header header; // OCP header OcaUint8 data []; // message data } Ocp1MessagePdu; See Table 1 for parameter definitions. Table 1 Message protocol data unit parameter definitions Parameter definition The syncVal message synchronization value indicates the start of a new message conforming to this section. Sync value should be constant 3B16 header This part of the header contains common message fields data An array of data holding the actual message data The receiver should always check every message that conforms to this section starting with a synchronization value. If the received message does not start with a standard synchronization value, The receiver should close the connection to the transmitter. Note. After the connection is disconnected, the controller involved can choose to restart the connection. The open control architecture does not define standard recovery procedures. The protocol data unit can be defined by the Universal Modeling Language (UML) in XML Metadata Interchange (XMI) 2.1 format defined in GB/T 28167-2011 Document definition. For access to related documents, see Appendix B. 5.6.1.2 Baotou The C language style definition for data structures that conform to this section is as follows. struct { OcaUint16 protocolVersion; // version number OcaUint32 pduSize; // PDU byte length OcaMessageType pduType; // PDU type OcaUint16 messageCount; // Number of messages } Ocp1Header; See Table 2 for parameter definitions. Table 2 Definition of header parameters Parameter definition protocolVersion (Length is 2 bytes) Protocol version number for this section. Open control architecture classes have their own version numbers, so only the sections in this section described in this section The protocol version is updated when the protocol is updated pduSize (Length is 4 bytes) Byte length of the complete PDU, including the header, but not including the synchronization value pduType (1 byte in length) Represents the type of PDU; that is, the type of PDU message contained. You should use one of the following message types (values between parentheses). OcaCmd (0) command-no response required OcaCmdRrq (1) command-response required OcaNtf (2) Notice OcaRsp (3) response (for command or notification) OcaKeepAlive (4) keep-alive messages for device supervision messageCount (Length is 2 bytes) Number of messages, showing how many messages are in the data field (type pduType). The number of this message should be at least 1. If pduType etc. For OcaKeepAlive, the number of messages should be 1 5.6.2 Command messages 5.6.2.1 Format The command message format is shown in Figure 3. Synchronization value Sync value Protocol header header Command 1 Command size CommandSize Command handle Handle Goal number Target ONo Method ID MethodID Command 2. Command < message count> Command \u003cMessage Count\u003e parameter Parameters Class tree hierarchy TreeLevel Method index MethodIndex Parameter count Parameter Count Parameter 1 Parameter 2 .. Parameter < parameter count> Parameter \u003cParameter Count\u003e Figure 3 Command message The C language style of the command message protocol data unit is defined as follows. struct { OcaUint8 syncVal; // message synchronization value Ocp1Header header; // OCP header Ocp1Command commands [messageCount]; // Command array } Ocp1CommandPdu; See Table 3 for parameter definitions. Table 3 Command message parameter definitions Parameter definition syncVal (1 byte in length) Message synchronization value (see 5.6.1.1) header (Length is 9 bytes) Common message fields. See the definition of Ocp1Header in 5.6.1.2. commands (Variable length) Command (messageCount) array. The command format is defined by the Ocp1Command type, see 5.6.2.2. 5.6.2.2 Ocp1Command The C language style definition of the Ocp1Command data structure is as follows. struct { OcaUint32 commandSize; // length of a single command OcaUint32 handle; // command handle OcaONo targetONo; // target object nu...

Tips & Frequently Asked Questions:

Question 1: How long will the true-PDF of GY/T 322.3-2019_English be delivered?

Answer: Upon your order, we will start to translate GY/T 322.3-2019_English as soon as possible, and keep you informed of the progress. The lead time is typically 3 ~ 5 working days. The lengthier the document the longer the lead time.

Question 2: Can I share the purchased PDF of GY/T 322.3-2019_English with my colleagues?

Answer: Yes. The purchased PDF of GY/T 322.3-2019_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet.

Question 3: Does the price include tax/VAT?

Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countries

Question 4: Do you accept my currency other than USD?

Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.