1、 Copyright 2014 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved May 13, 2014 Table of Contents Page Foreword . 2 Intellectual Property 2 1 Scope . 3 2 Conformance Notation . 3 3 Document Elements . 4 4 Normative References . 4
2、 5 Messaging Services . 5 6 MDCF Data and Operation Model . 5 6.1 Mapping the MDCF Data Model to WSDL . 5 6.2 Message Format and Structure . 6 7 Device and Service Web Services . 6 7.1 Device and Service Endpoints . 7 8 Map Data Type Representation . 7 9 Internet Protocol Considerations 7 9.1 Differ
3、entiated Services Field (DS Field) . 7 9.2 Explicit Congestion Notification (ECN). 7 Annex A Bibliography (Informative) . 8 Annex B Network Considerations (Informative) . 9 B.1 Differentiated Services Field (DS Field) . 9 B.2 Explicit Congestion Notification (ECN) . 9 Page 1 of 10 pages SMPTE ST 207
4、1-2:2014 Revision of SMPTE ST 2071-2:2013 SMPTE STANDARD Media Device Control Protocol (MDCP) SMPTE ST 2071-2:2014 Page 2 of 10 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorpor
5、ated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a
6、bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in of its Standards Operations Manual. SMPTE ST 2071-2 was prepared by Technology Committee
7、 34CS. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rig
8、hts. SMPTE shall not be held responsible for identifying any or all such patent rights. SMPTE ST 2071-2:2014 Page 3 of 10 pages 1 Scope The Media Device Control (MDC) specification defines a platform and protocol agnostic framework for the control of network-attached devices over Internet Protocol (
9、IP) networks. The framework, known as the Media Device Control Framework (MDCF) defined by SMPTE ST 2071-1, can be implemented with nearly any Internet Protocol based transport protocol; however, in order to support interoperability between implementations a single, minimal compliance, transport pro
10、tocol must be defined. This single, minimal compliance protocol is referred to as the Media Device Control Protocol (MDCP). The Media Device Control Protocol (MDCP) is based on existing industry standards, simplifying the implementation and reducing the cost to implement, while supporting the implem
11、entation of vendor specific APIs, third party APIs, protocol extensions and the implementation of many existing standards relating to the control of media devices. Additional protocols may be implemented, but all implementations must implement the Media Device Control Protocol (MDCP) as it is define
12、d within this document. These additional protocols should provide an additional means for controlling devices, but must not be required nor expose functionality that is not available via the Media Device Control Protocol (MDCP). 2 Conformance Notation Normative text is text that describes elements o
13、f the design that are indispensable or contains the conformance language keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative t
14、ext does not contain any conformance keywords. All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be fol
15、lowed in order to conform to the document and from which no deviation is permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred
16、 but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is n
17、ot defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one that includes all mandatory provi
18、sions (“shall“) and, if implemented, all recommended provisions (“should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. Unless otherwise specified, the order of precedence of the types of normative information in t
19、his document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; followed by formal languages; then figures; and then any other language forms. SMPTE ST 2071-2:2014 Page 4 of 10 pages 3 Document Elements The SMPTE 2071 suite is comprised of the following
20、 elements, which form an integral piece of this Standard. Additionally, the WSDL and schema files may be found at http:/smpte-ra.org/schemas/2071/2014/mdcf. 1. Prose ST2071-2.docx Normative 2. XML Schema st2071-2a.xsd http:/www.smpte-ra.org/schemas/st2071/2014/types Normative 3. XML Schema st2071-2b
21、.xsd http:/www.smpte-ra.org/schemas/st2071/2014/identity Normative 4. XML Schema st2071-2c.xsd http:/www.smpte-ra.org/schemas/st2071/2014/device Normative 5. XML Schema st2071-2d.xsd http:/www.smpte-ra.org/schemas/st2071/2014/session Normative 6. XML Schema st2071-2e.xsd http:/www.smpte-ra.org/schem
22、as/st2071/2014/event Normative 7. XML Schema st2071-2f.xsd http:/www.smpte-ra.org/schemas/st2071/2014/mode Normative 8. XML Schema st2071-2g.xsd http:/www.smpte-ra.org/schemas/st2071/2014/media Normative 9. XML Schema st2071-2h.xsd http:/www.smpte-ra.org/schemas/st2071/2014/query Normative 10. XML S
23、chema st2071-2i.xsd http:/www.smpte-ra.org/schemas/st2071/2014/security Normative 11. WSDL st2071-2j.wsdl http:/www.smpte-ra.org/schemas/st2071/2014/device Normative 12. WSDL st2071-2k.wsdl http:/www.smpte-ra.org/schemas/st2071/2014/session Normative 13. WSDL st2071-2l.wsdl http:/www.smpte-ra.org/sc
24、hemas/st2071/2014/event Normative 14. WSDL st2071-2m.wsdl http:/www.smpte-ra.org/schemas/st2071/2014/mode Normative 15. WSDL st2071-2n.wsdl http:/www.smpte-ra.org/schemas/st2071/2014/media Normative 16. WSDL st2071o.wsdl http:/www.smpte-ra.org/schemas/st2071/2014/query Normative 17. WSDL st2071p.wsd
25、l http:/www.smpte-ra.org/schemas/st2071/2014/security Normative 18. XML Schema st2071q.xsd http:/www.smpte-ra.org/schemas/st2071/2014/service Normative 19. WSDL st2071r.wsdl http:/www.smpte-ra.org/schemas/st2071/2014/service Normative 4 Normative References The following standards contain provisions
26、 that, through reference in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this recommended practice are encouraged to investigate the possibility
27、of applying the most recent edition of the standards indicated below. IETF RFC 4122, A Universally Unique Identifier (UUID) URN Namespace IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers SMPTE ST 2071-2:2014 Page 5 of 10 pages IETF RFC 3168, The
28、Addition of Explicit Congestion Notification (ECN) to IP IETF RFC 3246, An Expedited Forwarding PHB OASIS WS-I BP 1.2, Organization for the Advancement of Structured Information Standards (OASIS) Web Services Interoperability (WS-I) Basic Profile Version 1.2 SMPTE ST 2071-1:2014, Media Device Contro
29、l Framework (MDCF) 5 Messaging Services Messages are data packets exchanged between nodes for the purpose of executing operations, broadcasting notification events, and exchanging data. The Media Device Control specification defines this exchange of messages as the Media Device Control Protocol (MDC
30、P). The Media Device Control Protocol (MDCP) shall be implemented in accordance to the OASIS Basic Profile 1.2 (OASIS WS-I BP 1.2) web services specification, using the SOAP 1.1 HTTP protocol binding. Service definitions shall be represented using Web Service Definition Language version 1.1 (WSDL 1.
31、1) and may use WS-Addressing 1.0 for the addressing of request and/or response messages. 6 MDCF Data and Operation Model In compliance with the OASIS WS-I Basic Profile 1.2 the MDCF data and operation model shall be transposed to XML Schema 1.0 and WSDL 1.1. The WSDL and the corresponding SOAP envel
32、opes shall conform to the requirements outlined in the OASIS WS-I Basic Profile 1.2 and the SOAP 1.1 in HTTP protocol binding. 6.1 Mapping the MDCF Data Model to WSDL When transposing the MDCF data and operations model to XML 1.0 and WSDL 1.1 the following rules shall apply: 1. MDCF attributes shall
33、 be mapped to document-literal port type operations with an operation name equal to the word “get” prepended to the attribute name as it is defined in the MDCF data and operations model. For example, an attribute named “SomeAttribute” would transpose to a port type operation named “getSomeAttribute”
34、. The resulting operation shall accept no input parts and shall specify one output part matching the data type of the attribute. 2. MDCF operations shall be mapped to document-literal port type operations with an operation name equal to the name as it is assigned to the operation in the MDCF data an
35、d operations model. For example, an operation named “SomeOperation” would transpose to a port type operation named “SomeOperation”. The resulting operation shall accept only one input part, containing an XML document representing the input parameters of the operation and one output part matching the
36、 return type of the operation. 3. Port type operations shall define faults representative of the error conditions that may arise. Errors conditions that invalidate the state of the operation shall terminate the operation and raise the appropriate fault. 4. Each port type operation shall specify a un
37、ique WS-Addressing 1.0 compliant Action attribute for both the input and output message parts. SMPTE ST 2071-2:2014 Page 6 of 10 pages 6.2 Message Format and Structure 6.2.1 SOAP Envelope The standard SOAP 1.1 envelope shall be used. The SOAP 1.1 Binding for MTOM 1.0 may be used to transport binary
38、data or improve the performance of large result sets. 6.2.2 SOAP Headers The web services endpoint may require the support of WS-Addressing 1.0. 6.2.2.1 MessageID The MessageID header shall be specified if WS-Addressing 1.0 support is indicated. The MessageID shall be a UUID as defined by RFC 4122.
39、For example: urn:uuid:12345678-1234-1234-1234-123456789abc 6.2.2.2 To The To header may be specified if WS-Addressing 1.0 support is indicated. The To header shall contain the endpoint address of the SOAP receiver. 6.2.2.3 ReplyTo The ReplyTo header may be specified if WS-Addressing 1.0 support is i
40、ndicated. The ReplyTo header shall contain the endpoint address of the SOAP sender. 6.2.2.4 Action The Action header shall be specified if WS-Addressing 1.0 support is indicated. The Action header shall be derived from the Action attribute specified in the WSDL for the operation message part. If no
41、Action attribute is specified for the operation message part, the value of the Action header shall be derived implicitly from the WSDL. Refer to the WS-Addressing 1.0 documentation for specific details. 6.2.2.5 RelatesTo The RelatesTo header may be specified if WS-Addressing 1.0 support is indicated
42、. The RelatesTo header shall contain the MessageID of the corresponding request. 6.2.3 SOAP Body The SOAP Body shall be specified in accordance to the OASIS WS-I Basic Profile 1.2, containing only one child XML element. 7 Device and Service Web Services Devices and Services are aggregations of Capab
43、ilities, implementing more than one Capability Interface. In order to represent this relationship in WSDL, each Device or Service may be described as a WSDL service. If implemented, the WSDL service shall describe each exposed Capability Interface as a distinct web service endpoint and the URLs attr
44、ibute of the Device or Service Capability shall contain one or more URLs that facilitate the connection to that interface. SMPTE ST 2071-2:2014 Page 7 of 10 pages 7.1 Device and Service Endpoints Each Capability Interface shall be exposed as a unique web service endpoint. Each web service endpoint s
45、hall be defined as a unique WSDL port type and there shall be a one-to-one relationship between the Capability Interfaces exposed by a Device or Service and the web service endpoints exposed by that Device or Service. The URLs attribute of the Capability data structure shall contain one or more URLs
46、 that facilitate the connection to the web service endpoint represented by that Capability data structure. 8 Map Data Type Representation The Map data type defined within the MDCF requires a protocol specific binding for the conveyance of the data stored within the values of the Map entries. Therefo
47、re, MDCP implementations shall encode the Map entry values using the predefined XML base types. The values shall be stored within the Map entry XML elements encoded as prescribed within Table 1. Table 1 Map Entry Value Encoding Name Encoding BOOLEAN Shall be represented as an XML string type. TRUE =
48、 “TRUE”, FALSE = “FALSE”. STRING Shall be represented as an XML string type. INTEGER Shall be represented as an XML string type. FLOAT Shall be represented as an XML string type. DATE_TIME Shall be represented as an XML dateTime type. URI Shall be represented as an XML anyURI type. MAP Shall be repr
49、esented as an XML string type, with escaping of reserved characters. BLOB Shall be represented as an XML base64Binary type. 9 Internet Protocol Considerations 9.1 Differentiated Services Field (DS Field) The Differentiated Services Field (DS Field) RFC 2474 is an IP header field used to classify IP packets for Quality of Service (QoS) strategies. In order to specify that the MDCP IP packets require low delay, low jitter, and low loss, MDCP implementations should set the value of the DS
