實現client發送語音到相機，需要實現ONVIF的“Back Channel Connection”規範。詳見文檔《ONVIF-Streaming-Spec-v210.pdf》的“5.3 Back Channel Connection”小節。
以下是原文摘錄。
5.3 Back Channel Connection
This section describes how a bidirectional connection can be established between a client and a server. The backchannel connection handling is done using RTSP [RFC 2326]. Therefore a mechanism is introduced which indicates that a client wants to built up a backchannel connection. RTSP provides feature-tags to deal with such functionality additions.
A device that supports bi-directional connections (e.g audio or metadata connections) shall support the introduced RTSP extensions.
When the backchannel data stream is sent via RTSP/HTTP/TCP, a client shall use HTTP GET connection which is defined for sending the data stream without base64 encoding (see 5.1.1.4).
5.3.1 RTSP Require- Tag
The RTSP standard [RFC 2326] can be extended by using additional headers objects. For that purpose a Require tag is introduced to handle special functionality additions (see [RFC 2326], 1.5 Extending Rtsp and 12.32 Require).
The Require-tag is used to determine the support of this feature. This header shall be included in any request where the server is required to understand that feature to correctly perform the request.
A device that supports backchannel shall understand the backchannel tag:
- www.onvif.org/ver20/backchannel
An RTSP client that wants to built up an RTSP connection with a data backchannel shall include the Require header in its requests.
5.3.2 Connection setup for a bi- directional connection
A client shall include the feature tag in it’s DESCRIBE request to indicate that a bidirectional data connection shall be established.
A server that understands this Require tag shall include an additional media stream in its SDP file as configured in its Media Profile.
An RTSP server that does not understand the backchannel feature tag or does not support bidirectional data connections shall respond with an error code 551 Option not supported according to the RTSP standard. The client can then try to establish an RTSP connection without backchannel.
A SDP file is used to describe the session. The server shall include the a=sendonly or the a=recvonly attributes in each media section of the SDP file to indicate the direction the media data will be send.
The server shall list all supported decoding codecs as own media section and the client chooses which one is used.
5.3.2.1 Example 1: Server without backchannel support:
Client – Server:DESCRIBE rtsp://192.168.0.1 RTSP/1.0
CSeq: 1
User-Agent: ONVIF Rtsp client
Accept: application/sdp
Require: www.onvif.org/ver20/backchannel
Server – Client:RTSP/1.0 551 Option not supported
CSeq: 1
Unsupported: www.onvif.org/ver20/backchannel
5.3.2.2 Example 2: Server with Onvif backchannel support:
Client – Server:DESCRIBE rtsp://192.168.0.1 RTSP/1.0
CSeq: 1
User-Agent: ONVIF Rtsp client
Accept: application/sdp
Require: www.onvif.org/ver20/backchannel
Server – Client:RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: xxx
v=0
o= 2890842807 IN IP4 192.168.0.1
s=RTSP Session with audiobackchannel
m=video 0 RTP/AVP 26
a=control:rtsp://192.168.0.1/video
a=recvonly
m=audio 0 RTP/AVP 0
a=control:rtsp://192.168.0.1/audio
a=recvonly
m=audio 0 RTP/AVP 0
a=control:rtsp://192.168.0.1/audioback
a=rtpmap:0 PCMU/8000
a=sendonly
This SDP file completely describes the RTSP session. The Server gives the client its control URLs to setup the streams.
In the next step the client can setup the sessions:
Client – Server:SETUP rtsp://192.168.0.1/video RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=4588-4589
Server – Client:RTSP/1.0 200 OK
CSeq: 2
Session: 123124;timeout=60
Transport:RTP/AVP;unicast;client_port=4588-4589; server_port=6256-6257
Client – Server:SETUP rtsp://192.168.0.1/audio RTSP/1.0
CSeq: 3
Session: 123124
Transport: RTP/AVP;unicast;client_port=4578-4579
Server – Client:RTSP/1.0 200 OK
CSeq: 3
Session: 123124;timeout=60
Transport:RTP/AVP;unicast;client_port=4578-4579; server_port=6276-6277
Client – Server:SETUP rtsp://192.168.0.1/audioback RTSP/1.0
CSeq: 4
Session: 123124
Transport: RTP/AVP;unicast;client_port=6296-6297
Require: www.onvif.org/ver20/backchannel
Server – Client:RTSP/1.0 200 OK
CSeq: 4
Session: 123124;timeout=60
Transport:RTP/AVP;unicast;client_port=6296-6297; server_port=2346-2347
The third setup request establishes the audio backchannel connection.
In the next step the client starts the session by sending a PLAY request.
Client – Server:PLAY rtsp://192.168.0.1 RTSP/1.0
CSeq: 5
Session: 123124
Require: www.onvif.org/ver20/backchannel
Server – Client:RTSP/1.0 200 OK
CSeq: 5
Session: 123124;timeout=60
After receiving the OK response to the PLAY request the client MAY start sending audio data to the server. It shall not start sending data to the server before it has received the response.
The Require-header indicates that a special interpretation of the PLAY command is necessary. The command covers both starting of the video and audio stream from NVT to the client and starting the audio connection from client to server.
To terminate the session the client sends a TEARDOWN request.
Client – NVT:TEARDOWN rtsp://192.168.0.1 RTSP/1.0
CSeq: 6
Session: 123124
Require: www.onvif.org/ver20/backchannel
NVT – Client:RTSP/1.0 200 OK
CSeq: 6
Session: 123124
附錄：
1.一些非常有用的參考：
（1）https://albert-oma.blogspot.com/2014/07/live555.html
（2）http://lists.live555.com/pipermail/live-devel/2016-June/020094.html
原文摘錄：
If you look at the ONVIF Device Test Tool (which you can only acquire if your company has a paying Onvif membership) there is a test for backchannel using rtp/rtsp/tcp and udp. You can find it under diagnostics tab > real time streaming > audio backchannel > unicast > backchannel - g711 (rtp/rtsp/tcp ||udp).