Audio profile: DTT Issue Clarifications (#710)

* Audio profile: Issue Clarifications

* fix for issue #707

Author: sujithhanwha

doc/Streaming.xml

@@ -2132,6 +2132,29 @@ Sec-WebSocket-Protocol: rtsp.onvif.org
       </mediaobject>
     </figure>
   </chapter>
+  <appendix>
+    <title>SRTP (Informative)</title>
+    <para>When implementing SRTP functionality, implementers should be aware of specific library requirements that may affect packet data handling.</para>
+    <section>
+      <title>libsrtp Implementation Considerations</title>
+      <para>If libsrtp is used for SRTP implementation, proper alignment is required for packet data. The libsrtp library documentation specifies the following alignment assumptions:</para>
+      <itemizedlist>
+        <listitem>
+          <para>The <code>srtp_protect</code> method assumes that the RTP packet is aligned on a 32-bit boundary.</para>
+        </listitem>
+        <listitem>
+          <para>The <code>srtp_protect_rtcp</code> method assumes that the RTCP packet is aligned on a 32-bit boundary.</para>
+        </listitem>
+        <listitem>
+          <para>The <code>srtp_unprotect</code> method assumes that the SRTP packet is aligned on a 32-bit boundary.</para>
+        </listitem>
+        <listitem>
+          <para>The <code>srtp_unprotect_rtcp</code> method assumes that the SRTCP packet is aligned on a 32-bit boundary.</para>
+        </listitem>
+      </itemizedlist>
+      <para>Implementers should ensure that packet buffers are properly aligned on 32-bit boundaries before passing them to libsrtp functions. Failure to maintain proper alignment may result in performance degradation or runtime errors on some platforms. It is recommended to consult the libsrtp documentation for specific alignment requirements of the version being used.</para>
+    </section>
+  </appendix>
   <appendix role="revhistory">
     <title>Revision History</title>
     <para/>

wsdl/ver10/schema/onvif.xsd

@@ -1019,6 +1019,14 @@ IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FO
 	<!--===============================-->
 	<!--   VideoEncoder2Configuration   -->
 	<!--===============================-->
+	<xs:simpleType name="SrtpSecurityAlgorithms">
+		<xs:restriction base="xs:string">
+			<xs:enumeration value="NONE"/>
+			<xs:enumeration value="AES_CM_128_HMAC_SHA1_80"/>
+			<xs:enumeration value="AEAD_AES_128_GCM"/>
+			<xs:enumeration value="AEAD_AES_256_GCM"/>
+		</xs:restriction>
+	</xs:simpleType>
 	<xs:simpleType name="VideoEncodingMimeNames">
 		<xs:annotation>
 			<xs:documentation>Video Media Subtypes as referenced by IANA (without the leading "video/" Video Media Type).  See also <a href="https://www.iana.org/assignments/media-types/media-types.xhtml#video"> IANA Media Types</a>.</xs:documentation>
@@ -2153,11 +2161,11 @@ decoding .A decoder shall decode every data it receives (according to its capabi
 			<xs:element name="SRTPPSK" type="xs:string">
 			<xs:annotation>
 				<xs:documentation>
-				An optional SRTP Pre-Shared Key (PSK) represented as a hexadecimal string.
+				SRTP Pre-Shared Key (PSK) represented as a hexadecimal string.
 				This includes both the SRTP master key, followed by the master salt.
-				The sizes of the key and salt depend on the specified SRTPCryptoPolicy.
-				When this element is specified, RTP packets shall be encrypted.
-				The SRTPPSK shall never be returned on a get method.
+				The sizes of the key and salt depend on the specified SecureStreamingProtocolAlgorithm.
+				When this element contains a non-empty value, RTP packets shall be encrypted.
+				The SRTPPSK shall be returned as an empty string on a get method.
 				</xs:documentation>
 			</xs:annotation>
 			</xs:element>