[Live-devel] Need advice on best way to proceed.

[Frederik De Ruyck]

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).

The test sets up everything required to be able to send and then plays a 
10 second audio file. This tool is almost mandatory if you plan on 
integrating a backchannel into your code. Not only because you can see 
which soap data is send to the camera but also because so many camera's 
don't work properly that you need to check support up front to be able 
to rule out glitches on the camera side.

On my 2 camera's, I can play backchannel audio with UDP but not with 
TCP, no audio is coming through the speaker even though it is send over 
the network. I wonder that if what you say is true, then why did they 
implement a TCP test for backchannel? You could say that when using UDP 
it's on a separate socket so that's different, but for TCP? Onvif is the 
standard, defining the soap messages etc, the protocol for communication 
is still RTSP.

Note that onvif backchannel uses the RTSP require tag to check for 
backchannel support on the camera side. Unfortunately, some camera's 
deny the require tag so you need a workaround for that too. Try sending 
require=someRandomString, if you get an Ok reply the camera is not 
checking the require field.


Op 02-Jun-16 om 11:45 PM schreef Ross Finlayson:
> There’s really nothing in the RTSP specification (note, btw, that ‘ONVIF’ is not the RTSP specification) that provides for a RTSP server receiving media at the same time that it sends it.  And as people have noted, there’s no support in our RTSP server implementation for this.  So I suggest that you don’t use RTSP (and/or our RTSP server or client implementation) at all.
>
> However, it’s possible (and quite easy) to use the “LIVE555 Streaming Media” code to implement ‘full-duplex’ media (and by ‘full-duplex’, I presume you mean using the same socket for both sending and receiving media).  To do this, just create a single “Groupsock” object for the socket, but use this *one* “Groupsock” object when creating both a “RTPSink” (subclass) object (for transmitting), and a “RTPSource” (subclass) object (for receiving).
>
> Similarly, for RTCP, you can either create a new socket (on even port #+1) and “Groupsock”, and create a single “RTCPInstance” for this, or else have this (single) “RTCPInstance” use the same socket and “Groupsock” that you used for RTP.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel