Subject: Re: [MMUSIC] Reg. RTSP SETUP request

From: "Joseph Pallas" <[email-masked]>
Date: Sun, 20 May 2007 11:42:48 -0700

Maruthi asked about how a firewall/ALG might tell the difference
between in-session SETUP for aggregation and in-session SETUP for new
transport parameters:

> From my understanding of the RFC I see that NAT device has to remember the URL to differentiate these two cases.

How to distinguish between these two cases invites a more basic
question:  Does any implementation actually support changing the
transport stream parameters in mid-session?  And is SETUP really the
best way to do that?

I'm frankly skeptical about changing transports without a new session.
 What are the benefits of including that in the protocol?

joe

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 May 2007 11:27:26 +0200

Joseph Pallas skrev:
>> From my understanding of the RFC I see that NAT device has to remember 
>> the URL to differentiate these two cases.
> 

Hi Joe,

This is an interesting question. Lets start with the motivation as I see 
it. There are a few different cases when changing the transport 
parameters makes sense.

1. Session portability. Looking at the home environment use cases of 
RTSP today, there are people proposing/using RTSP to move a session from 
the living room "TV" to the bedroom "TV". I haven't looked at how DLNA 
does this, but I wouldn't be surprised if they use RTSP.

2. Session survivability. If a client experience either some mobility 
event or other change of network attachment that affects what IP address 
it is using, SETUP can be used to move the session to new address.

3. NAT Traversal. There is one part which is very similar to 2. In case 
the NAT bindings are lost, there is likely need for updating your 
transport parameters to get the session working again. However, looking 
at the proposals on how to do standardized NAT traversal for RTSP using 
ICE. In this there is likely a need to promote a candidate to primary 
address usage after having found it.

But as you say these things could be accomplished creating a new 
session. However the issues here I think are three:

A. The churn on the media servers to setup new back end readers for the 
files and position things correctly.

B. The impression in the client's state regarding playout information.

C. The need to do a complete rebuffer and resynchronization for the 
media streams instead of simply continue with the available state.

If these are strong enough arguments for including the mechanism is to 
me the real question. To me it appears that the functionality has been 
little used prior but starts to see more use as usage of RTSP evolves 
into more advanced usages.

The reason the SETUP is used for changing these parameters is to not 
require ALGs, Proxies etc to read other methods that affect parameters 
that the SETUP has created the initial values for. This motivation is 
documented in RFC 2326. Can you please provide any arguments why it is a 
bad idea?

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Joseph Pallas" <[email-masked]>
Date: Mon, 21 May 2007 18:38:38 -0700

I'll jump to the end ...

> documented in RFC 2326. Can you please provide any arguments why it is a

I'm not honestly certain that it is a bad idea.  But the case that was
raised here suggests that there may be something wrong: the motivation
is to make life easier for ALGs and proxies, but the chosen approach
also makes life harder for ALGs and proxies.

With regard to the three issues you raised (media server churn, client
playout state, and rebuffering/resynchronization), I'm not sure they
are all valid.  I will accept that a media server might use fewer
resources to redirect an existing session than to tear down and
reestablish.  But I think that changing the destination address will
likely require rebuffering/resynchronization, unless the client is
receiving on both addresses at once.  Client playout state would fall
into two cases: streams that support user-specified starting points
and streams that don't (live only).  Live-only streams won't have any
client playout state associated with a session; random-access ones can
easily issue a PAUSE to learn the current playout point.

But if we believe that changing transports in mid-stream is sometimes
desirable, maybe overloading SETUP is not the best way to do it, since
SETUP is already overloaded for initial session creation and
aggregation.  Client-to-server REDIRECT might be an alternative.

joe