Subject: [MMUSIC] RTSP session identifiers

From: "Mark Crosland" <[email-masked]>
Date: Fri, 12 Nov 2004 16:47:22 -0800

Hello,

I have a question regarding RTSP session IDs that perhaps someone would
answer.

RFC 2326 indicates that an RTSP session identifier is not tied to a
single TCP connection or some well-defined set

of UDP packets (1.1, 1.7, 12.37, 16 session hijacking).

I am curious as to what a use-case or two might be where a session ID
spans multiple TCP connections to the server? I'm guessing here, but
would they revolve around conferencing?

For the generic video/audio user on the internet I assume that when they
exit out of something like real player or windows media player, that the
server stops streaming data to them, and the chances of them
reconnecting to the server and resuming where they left off are slim.
But perhaps that is only because the clients don't support that mode of
operation, i.e., saving RTSP session IDs, reconnecting to a server and
resuming the data stream.

Do most media clients and servers out there support session management
across multiple control channels?

Thanks,

Mark Crosland

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Nov 2004 16:13:53 +0100

Hi Mark,

Sorry for not responding before, see below for my comments.

Mark Crosland wrote:

> spans multiple TCP connections to the server? I’m guessing here, but 

The reasons that RTSP has session ID is not tied to a specific transport 
is many:
- Support of UDP / non-connection oriented transport
- The possibility to have one transport connection that controls 
multiple sessions.
- Fault tolerance, against the loss of a transport connection when in a 
session.

There are also has been considered to use the session ID as a 
possibility to pass the control between multiple users in a conference 
that share the streaming servers output.
> But perhaps that is only because the clients don’t support that mode of 

A session and its ID is not a long lived entity normally, the default 
session timeout is 60 seconds. Thus it can't normally be used to save 
the state and later return to the session. What has been discussed has 
been application layer mobility, where after a change of IP address the 
client reconnects to the session and do a new SETUP to move to streams 
to the new address. Another case has been to move the session between 
devices, for example between the living room and the bedroom displays.

> across multiple control channels?

There are some servers that support it, some other that do not. In the 
discussion on the topic the conclusion is to mandate servers to shall be 
required to support non-permanent transport connection. The main 
motivation being fault tolerance.

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]