I have a simple application in c# that opens an RTSP session and sends the appropriate commands like DESCRIBE, SETUP, etc to control an RTP data stream.
My questions is this: does the TCP session (for the RTSP communication) have to stay open while streaming the data over RTP? Without going into details as to why, I'd like to be able to close the RTSP session after the RTP streaming is setup.
RFC 7826 Real-Time Streaming Protocol Version 2.0
A persistent connection is RECOMMENDED to be used for all
transactions between the server and client, including messages for
multiple RTSP sessions. However, a persistent connection MAY be
closed after a few message exchanges. For example, a client may use
a persistent connection for the initial SETUP and PLAY message
exchanges in a session and then close the connection. Later, when
the client wishes to send a new request, such as a PAUSE for the
session, a new connection would be opened. This connection may be
either transient or persistent.
So no, it is not required to be open while streaming data.
The short answer is yes you must keep the rtsp socket open.
If the stream is over TCP the RTP packet travels over the socket of the RTSP session. If the stream is over UDP the socket is used by the server to know if it should keep sending packet to the client because the UDP packet transmission does not have any feedback if the client is still alive.
Edited:
I think the answer marked correct is actually incorrect. In general, the cameras implement the RTSP protocol version 1 not version 2. In the 10 years that I have of experience in video surveillance systems I have found that several models of cameras stop sending RTP packets after closing the RTSP session socket .
Related
I have to create a service which captures the audio from the PC microphone and to broadcast it as UDP packets. I am on a Debian platform and I have to use Python (3.7).
I would like to use PyAV because I have to link this broadcasting system to a local custom WebRTC service using aiortc, which relies on PyAV.
I have to do this because I cannot access the same audio source (ALSA) from several processes (RTC peers), so I was thinking to create a UDP broacasting system in a localhost environment. Is this the best practice? Have you any other idea?
I have noticed here that with the call: av.open("udp://xxx:nnn", format="alsa") I should be able to receive audio UDP packets, but I am not sure how to generate a UDP server which captures from the mic and sends the UDP packets, so, how to create the server side of this implementation? In particular, I managed to capture the audio with: av.open("hw:0", format="alsa"), how can I send the captured buffer over UDP sockets?
I'm implementing a solution for listening to on-going calls inside a LAN network.
Is there a way to provide WebRTC the ip address and port as to where an RTP stream is coming? All I want to do is to get that RTP stream directly streamed to the possible listeners of the call through WebRTC.
I'm not sure if it's feasible but I think it is given how WebRTC has evolved since the past months.
I've been looking around but I've got no luck on this.
The WebRTC RTP stream is encrypted with keys that are exchanged through DTLS. You cannot get the raw RTP stream from a WebRTC peer or even feed it a raw stream without some mediary system to handle the webrtc peerconnection, certificate exchange, and rtp encryption.
The only way to do what you want is to have a breaker or a gateway. An example of such a gateway is the janus-gateway though it is definitely not your only option.
I have been using UDP sockets to send and receive voice through RTP packetization. It is pretty straightforward. I just send my mic voice signals ( that are encoded ) over IP using User Datagram socket , and on the other end i receive the UDP-RTP packets and decode them to be able to play them on my speakers.
I have been searching on internet for a while to find a way to start up a session using UDP sockets. What i want to to is to a Handshake-like process between two ends of my conversation and after the requests were acknowledged the media layer ( which i described in first paragraph ) would fire and start sending voice.
I have not been able to find any tutorials on session request using UDP sockets but i suppose it shouldnt be impossible.( one user sends a request to build a session and if the other user confirms media layer starts)
Has anyone done something like this before? any info is welcome.
Firstly, UDP is a connectionless, unreliable protocol, you won't find anything like handshaking for negotiating connection i.e no session management. But, to transport RTP packets it's not a good idea to use tcp, it lacks realtime feature, so you have to stick with UDP. Now, to overcome the signaling problem you can use protocols like. SIP. It's standard signaling protocol used in VOIP. SIP initiates a connection before sending RTP packets. To properly use SIP and RTP you might have to take help of another protocol called SDP, which tells which port to use for transmitting RTP and other various info. You can get more info about these techniques here. Hope this will helps!
We are trying to build a SIP2RTSP gateway for one of our solutions, Where in one of SIP invite is converted to RTSP SETUP request to wowza media Server and then a PlayBack is played from the mediaServer to SipClient.
But when the setup request is sent the wowza is always binding to rtsp client address even though the destination is set in transport of SETUP request header. Here we want to tell the wowza rtsp server to bind to sip UA IP and not the rtsp client ip for the flow of RTP traffic.
RFC 2326 says
destination:
The address to which a stream will be sent. The client may
specify the multicast address with the destination parameter.
To avoid becoming the unwitting perpetrator of a remote-
controlled denial-of-service attack, a server SHOULD
authenticate the client and SHOULD log such attempts before
allowing the client to direct a media stream to an address not
chosen by the server. This is particularly important if RTSP
commands are issued via UDP, but implementations cannot rely
on TCP as reliable means of client identification by itself. A
server SHOULD not allow a client to direct media streams to an
address that differs from the address commands are coming
from.
here it also tells A
server SHOULD not allow a client to direct media streams to an
address that differs from the address commands are coming
from.
What is the use of destination field and how we can direct the media streams other than the RTSP client?
The point is that client MAY request the stream to be sent at client-chosen location. Still server should be doing this carefully, and take decision whether to allow an address which is different from RTSP client address or not using security consideration such as authentication availability etc. Because sending stream blindly to any given address, esp. via UDP, is unsafe: a malicious client might easily bring server down.
All in all, destination is where to send stream to. Servers do not guarantee that streams will be sent to locations other than RTSP client's.
I have a simple Rtsp Client...The client send Rtsp Commands to Rtsp Server and get RTP packets from server.
The problem is that after a time( about 3-4 minute) my 3rd party RTSP
Server drop connection with my RTSP Client.
I have not implemented RTCP...I take rtp packets from rtsp server but does not send any RTCP PACKET...
I make simple search and find that some guys use some RTSP commands[ like OPTIONS, SET PARAMETER-GET PARAMETER ] too keep alive Connections between RTSP Server and Client...
But in my case that does not work...
Here is my questions:
What is the best way to keep alive connection with RTSP server?
Do i have to implement RTCP [ send RTCP packets to server]? May the connection drop because i do not send RTCP packets to server?
What is the value of timeout you receive in SETUP response? Are you using this value for implementing keep alive functionality?
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds
]
Generally RTSP is based on TCP and RTP is based on UDP. So ideally both the channels require keep alive functionality. If RTP session is closed that does not mean that RTSP connection should also be teardown whereas RTP channels must be closed on RTSP channel teardown.
1) What is the best way to keep alive connection with RTSP server? --> Send any RTSP request periodically (OPTIONS, SET_PARAMETER or GET_PARAMETER) before timeout value received in SETUP response.
2) Do i have to implement RTCP [ send RTCP packets to server]? May the connection drop because i do not send RTCP packets to server? --> RFC (RTSP or RTP) does not mandate requirement of RTCP to keep RTP channels alive.
Sending an OPTIONS request didn't work for me.
The only RTSP command that I could send to keep the connection alive was GET_PARAMETER
My timeout is 60s and I send a GET_PARAMETER request every 40s
Works like a charm!
(No, you do not have to RTCP packets to the server)