Subject: [MMUSIC] RTSP questions in regards to the control channel socket

From: Craig Matsuura <[email-masked]>
Date: Thu, 13 Mar 2014 17:22:18 -0600

Hi this is my first time posting here.  I have a basic question about 
how a RTSP server should handled a connect and disconnect for what I am 
calling the control channel (connection or transport). The control 
channel (please correct me) is what sends the DESCRIBE, SETUP, OPTIONS, 
PLAY commands to the RTSP SERVER.

Should a server treat the first DESCRIBE connection as its session. So 
in the case where a socket connects to a RTSP server and sends a 
DESCRIBE, is disconnected either by the client or some failure on the 
server should the following SETUP succeed?

Also if using a RTSP Proxy and in the same scenario, but after the 
DESCRIBE and closing of the socket a new socket is open to send an 
OPTIONS (for keepalive) should the following SETUP succeed?

 From what I understood from the RFC2326 Section 1.7 RTSP State, it 
should not matter how many connections are used to control the RTSP Stream.

1. Control Socket is not prevent a client from connecting and 
disconnecting to send Transport commands.
2. The keep-alive for a session should not start until a SETUP command, 
which can optional report the timeout for the session.

Thanks,
Craig

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Mar 2014 11:17:45 +0100

> server should the following SETUP succeed?

No, DESCRIBE is a state less operation. If one needs a linkage between
the Describe response body and the setup, then one should use etags and
conditional requests to ensure that one is establishing the session with
a relevant session description.

> OPTIONS (for keepalive) should the following SETUP succeed?

Yes the SETUP should succeed if otherwise valid.

> disconnecting to send Transport commands.

I am uncertain what you mean with the Control socket, if you means the
Socket the server listens to incoming TCP connection establishments and
their data, it needs to be accepting those comming and going.

> which can optional report the timeout for the session.

Exact, the keep-alive is associated with the RTSP session, not the
signalling connection used to send RTSP requests and response between
the server and client.

You might find RTSP 2.0's text on this being clearer:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Craig Matsuura <[email-masked]>
Date: Sat, 15 Mar 2014 11:41:12 -0600

Hi Magnus,

Thanks for your response, to be clear when I was referring to a Control 
Socket I mean the connection that sends commands such as the DESCRIBE, 
OPTIONS, SETUP.  So to restate, it should not matter if a connection for 
the transports comes or goes to server.  For example if a server flow to 
a client is:

C->S - Send DESCRIBE Command, C gets 200 response from S.
Close connection and start new connection
C->S - Send OPTIONS command, C gets 200 response from S.
Close connection and start new connection
C->S - Send SETUP command, C gets ??? response from S.

So at the SETUP the response should be 200? or fail (400)?  I'm trying 
to clear up an issue I have with a vendors RTSP Server implementation 
and would like to know if the sequence above should work to a RTSP 
Server.  Based on the Section 1.1 and 1.7 seems the above should work.  
The only issue would be after the SETUP the session id needs to 
accompany commands that follow?

Thanks,
Craig

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Mar 2014 14:03:08 +0100

> accompany commands that follow?

Yes, according to my interpretation of RFC 2326 that should be
completely valid and the SETUP request result in a 200 OK with a session
ID that is later used to reference that session.

/Magnus

-- 

Magnus Westerlund