Subject: [MMUSIC] simultaneous RTSP sessions over the same TCP connection?

From: "Patankar, Sujay" <[email-masked]>
Date: Fri, 20 Jan 2006 10:03:27 +0530

Hi,
I had a couple of questions about RTSP. I'll be greatly thankful to
anyone who answers them.

1:  Can there be more than one RTSP session-ids in simultaneous use over
a single TCP connection between a client and a server? (I mean over the
same {src IP, src port} and {dst IP, dst port} pair) If I receive, for
example, a request or response w/o a session ID, can I safely assume
that it belongs the same session id as that was present in other RTSP
messages seen on this TCP connection?

2: The RTSP RFC (2326) states that the session id is required in all
requests as well as responses except the OPTIONS and SETUP requests.
However, I have seen a RealPlayer receiving a 200 reply to a PLAY. The
200 OK reply didn't contain any session id. (it had the matching CSeq
though) I was under the impression that every reply MUST contain a
session id.

3: If multiple session ids can be in use on the same TCP connection at
the same time, what happens when one of the sessions does a TEARDOWN?
Will the TCP connection be torn down? What will the other sessions do in
such case? Does an RTSP TEARDOWN always involve a TCP connection
teardown?

Thanks in advance for any help,
Sujay.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Robert Hagens" <[email-masked]>
Date: Fri, 20 Jan 2006 08:27:35 -0700

Hello,

Regarding (1), I interpret section 9.2 of the 2.0 draft
	"A persistent connection MAY be used for all
	transactions between the server and client, including messages to
multiple RTSP sessions"
to mean that you can run multiple sessions on the same transport. The
comment in section 9.3 regarding closing connections I think should answer
your third question as well ("The server, however, SHOULD NOT close a
connection until all RTSP sessions being managed through the 	connection
have been timed out")

Hope this helps,

Rob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Patankar, Sujay
Sent: Thursday, January 19, 2006 9:33 PM
To: [email-masked]
Subject: [MMUSIC] simultaneous RTSP sessions over the same TCP connection?

Hi,

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Jan 2006 16:34:34 +0100

> messages seen on this TCP connection?

One may send more control traffic for more than one session over the
same TCP connection. Some RTSP 1.0 servers may not like it, but the
specification allows for it. You can not assume that any request
received over the TCP connection is for a already established
connection. If they are related or not is indicated in each request by
the inclusion of the session header. For example A SETUP request without
a session header creates a new session, while one with binds that media
into the aggregated session identified.

It is the recommend procedure for a proxy that connects several clients
to the same server in RTSP 2.0. B

> though) I was under the impression that every reply MUST contain a

Then they are breaking the following normative statement in section
12.37 of RFC 2326:

Once a client receives a Session
    identifier, it MUST return it for any request related to that
    session.

> such case? Does an RTSP TEARDOWN always involve a TCP connection

If I remember correctly this is a bit unclear. However an TEARDOWN must
indicate which session and resource the TEARDOWN is for. An TEARDOWN
with a media URI indicates that only the media should be removed from
the session, not the complete session. If the session URI is used, then
the whole session identified is removed.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Rishi Mathew <[email-masked]>
Date: Fri, 20 Jan 2006 09:18:52 -0800

>Then they are breaking the following normative statement in section

Not true! Atul's statement is that "I have seen a RealPlayer receiving a 
200 reply to a PLAY. The 200 OK reply didn't contain any session id." Which 
means that he is seeing the absence of a session-id in the 
response(generated by the server) not the request.  In any case, the 
session-id is not a necessity in the PLAY response.

-Rishi.

>Multimedia Technologies, Ericsson Research EAB/TVA/A

Rishi Mathew
Software Development Engineer
Helix Community
RealNetworks, Inc.
[email-masked]
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Jan 2006 09:43:26 +0100

Rishi Mathew wrote:
> 200 reply to a PLAY. The 200 OK reply didn't contain any session id." 
> Which means that he is seeing the absence of a session-id in the 
Hi Rishi,

Sorry my misstake. You are correct that statment I quoted applies to the 
client, not the server. And as long as any proxy or client is correctly 
made there exist a way of correctly binding the response to the request 
and thus determining which session ID it belongs to. I would however say 
that it is recommended to include the Session header in any response 
that relates to a session.

In RTSP 2.0 as currently proposed it will be required to include the 
session ID in response for SETUP, PLAY, and PAUSE.

Cheers

Magnus Westerlund