Subject: [MMUSIC] RTSP notes on ad-hoc meetings at IETF 56

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Mar 2003 19:54:18 +0100

Hi,

Below is RTSP meeting notes from the sunday and monday. This is my 
interpretation of what was discussed. Please comment if something is 
missing or something is in error.

Best Regards

Magnus

---------------------

Minutes of meetings for the two RTSP discussion meeting during IETF 56.

First meeting Sunday 21.00-23.15 16th April 2003

Participants

Sean Sheedy
Rob Lanphier
Tom Marshall
Andrea Basso
Anders Klements
Henning Schulzrinne
Colin Perkins
Joerg Ott
Thomas Zheng

Started with looking at the proposed presentation slides for the MMUSIC 
WG meeting presentation.

- Some short clarification on the usage of relative URL's for RTP-Info 
and having the Request URL as base for the this relative URL.

- A note that although we need support for Non-persistent connections a 
client is RECOMMENDED to keep the connection until it has finished all 
its sessions and signaling. The slides may not look like that they argue 
for persistent connection, but only as above. We need the 
non-persistentency to handle sessions in a reliable way.

Offer-Answer
------------

We discussed on how one could, and why one, would include a Offer Answer 
model into RTSP.

Use cases that where discussed were:

- Stream switching, one way of deciding which alternatives that can be 
used in switching would to use Offer-Answer to negotiate accepted 
alternatives.

- Capability exchange to determine if the a client can handle a stream 
and enable the server to tailor a presentation to fit the client.

A Important note in RTSP is that the capabilities are often restricted 
and can't be freely negotiated. For any on-demand multi-media 
presentation the capabilities are always dependent on the content 
creation step. Only what is available can be tailored. Content may also 
be restricted in what ways it can be adapted by the content creator. A 
possible way of having more latitude of capabilities are usage of 
transcoding functionality in servers.

It is also important to remember that RTSP uses session description in a 
uni-directional way which is different from normal SIP usage where the 
offer and answer is bi-directional.

Possible solutions.

A. Server if offerer and offers all that is available in regards to a 
stream. This could be done in DESCRIBE responses. The client is the 
Answerer and MAY then reduce the set of offered alternatives into an 
answer. A response could be included in the SETUP request. However this 
has some implications about binding answer to session and the SETUP 
requests. You can either send the answer in the first SETUP request and 
all future SETUP into that session uses the applied Answer. This has the 
implications that a aggregated session is much easier and does not 
require multiple sending of an Answer. Another alternative is to split 
an answer into answers for individual media streams.

The answer could also be done by a new method to establish State in the 
server that the SETUP can then bind to.

We will need a mechanism that could actually allow one to do multiple 
rounds of offer answer if the answer is not acceptable. However in most 
cases it seems possible that offer-answer should resolve in a single 
exchange.

B. Another scenario is that the client is the offerer. It sends the 
server its capabilities. Then the server would send an answer containing 
a matched presentation for the requested resource. A method would be 
DESCRIBE or similar. Then one must simply bind the offer answer 
agreement to a session. This is similar to what 3GPP PSS has available 
when one uses UAProf.

C. A half way case. A client retrieves a session description. The client 
creates an offer on what it can accept of this. The server would then 
answer with if this is suitable.

Considerations for selecting a possible solution is:

- What type of states must reside on the which sides?
- The amount of bandwidth that will be used by the offers and answers.

Resolution:
It seems interested and has some good use cases. However no one 
committed to create some ground breaking work in this area in form of 
use case and requirements draft.

RTSP IANA registration requirements
-----------------------------------

We discussed this a long time but could actually not come to any general 
conclusions.

- The was proposal that we could have permanent registrations that must 
be stable specifications. While proprietary registrations could be bound 
in time and if not renewed they would be removed from registry. However 
the problems are: The reclaiming mechanism. And what happens when a 
registered value are in wide use but the owner are no longer active in 
the are.

- It might be hard to swear to long from what they have defined in SIP & 
HTTP without having a good use case.

- The registration rules can be really customized and allows us to write 
rules for what a registration requires.

- Remember the x- problem that it might be better to allow for good 
names from the beginning. Vendor tree of registration would basically 
have the x- problem.

- Most of the registries are in fact unlimited. All having free width 
text fields has no limit. 

- Feature tags seems one that will be used in proprietary ways. However 
the question is if there is need for interoperability and collision 
avoidance that the registry supplies. Some discussion around having 
First come first served and a one paragraph description of the feature 
tag as minimum rules.

- Most agree that IETF standard tracks operation is suitable for 
Methods. Some voiced that restricting it to much would result in 
divergence. However this strictness may result in that all functionality 
is moved to SET_PARAMETER and headers.

- For headers there where discussion on splitting this into, a Vendor 
tree with tags that allow vendor registration, and a IETF tree which 
requires IETF standards track. However there was also other 
considerations that Public specification might be enough. Or even a 
lower level as there exist proprietary headers.

- The Transport header repositories for Protocol/profile/lower-transport 
to had as an triplet in a common registry. Public specification was 
agreed on. This can be defined by other standards body to allow them to 
adapt RTSP for there transport techniques.

Second meeting Monday 13.00-15.00 17 April 2003

Second meeting participants:
Magnus Westerlund
Rob Lanphier
Tom Marshall
Phillipe Gentric
Sean Sheedy
Anders Klemets
Thomas Zheng
Andrea Basso

* Stream-switching discussion

   We started by discussing around stream switching. Comments raised was:
   - We need to find good terminology. Stream switching are not really 
what we are talking about.
   - The goal is to have switching between considerable different streams.
   - We should consider the extreme cases to handle all normal cases.
   - An offer answer model could be used to select what alternative that 
are desired.
   - We have problem with caching proxies when we performs switches 
between different alternatives.  There was some discussion on different 
possibilities to mark packets on what alternative they belong to.
   -
  
   RESOLUTION: Phillipe Gentric writes a requirement draft with use cases.
  
* Ways to allow usage of Destination parameter
  The goal would be to find ways that give good enough security that a 
server can be allowed to send media traffic to a media receiver.
  - The easiest way of ensuring that a receiver accepts the media 
traffic is to ask it. Therefore the server could send a message to ask 
the receiver if it accepts to receive the traffic. The receiver 
responds. When the server receives a response it knows if it is allowed 
or not.
  - We could use the fallback rule that all client requesting media to 
the same address as there RTSP message connection comes from does not 
need to use this mechanism but MAY be used. => Gives backwards 
compatibility and makes it possible to deploy.
  - A server should or shall not send media until media acceptance 
challenge is responded.
  - A short term solution would be to require RTCP messages from other 
end-point to be able to send media.
  - RTCP RR are rather simple to spoof as the start RTP sequence number 
is known.
  - However it would still lower the force multiplier a RTSP server 
would give for performing a DOS attack. What I mean with force 
multiplier is the amount of work a attacker needs to do get a certain 
amount of affect at the target.
  - To get a guaranteed secure mechanism we would need to have way of 
source authenticating the media receiver target.
  - How do we handle multicast receiver addresses?
  - Should ask security expert for suggestions when we have described 
the problem well.
  - Write a problem description draft.
  - We should also look at having a general mechanism as this seem to be 
a problem all media transport can end up in. This is probably something 
that SIP has been ignoring and has not considered.
 
RESOLUTION: Phillipe Gentric will write a basic problem description draft.

* RTSP & NAT problems

Some minor discussion. Important comments:

TURN will not work unless we allow different IP address as the TCP RTSP 
will be directly from client while all media destinations will be the 
TURN servers IP.

The STUN vs. Symmetric RTP discussion.

- The port usage of symmetric RTP is a reality problem for large 
servers. May need to consider a solution that allows a trade off between 
port usage and security.

- Even if we haven't seen any actual case of multiple IP address NATs, 
it seems probable that wireless operators will deploy large scale NATs 
that will be simple and will result in one client streams end up on 
different IP addresses.

- We should include NAT implementor recommendations/requirements telling 
that a NAT should for any client only give a single IP on the public 
address.

- We discussed the need for ALG implementations recommendations. 
Especially the need for avoiding messing up the other methods. The 
recommendation would that any request containing a destination address 
shall not be touched by the ALG. This also effects the client behavior.

- Firewalls where discussed. It seems that there exist three basic types.
  1. A simple home NAT & FW box that simple opens ports and maps them to 
the machine that punched open the whole in the wall. This makes this 
equivalent with a Cone NAT.
  2. A UNIX/Linux software FW that actually are more restricted and 
looks at the source IP and decide if the private side has pounced a hole 
towards this address or not. Makes the FW equivalent to a symmetric NAT.
  3. Corporate FW. This ones is really paranoid and will block all 
unknown and not allowed traffic. Often make statefull inspection. To get 
RTSP and media transport on UDP through this types requires a policy 
allowing RTSP and requires ALG functionality to allow for UDP media traffic.
 
* Allowing for multiple SSRC in RTSP.

- The problem is that any media stream having multiple SSRCs can't be 
initially synchronized with RTP-Info. Fortunately RTCP SR provides a 
fall back for this. RTSP has SSRC issues in two places: 1. Transport 
header, 2. RTP-Info where RTP sequence number and RTP timestamp are 
related to a SSRC but not explicit present.
- The transport header may not need that the server informs the client 
on what SSRC it will use.
- The right thing would to redefine the RTP-Info header to allow for 
multiple SSRCs and their sequence number and timestamp.
- Will not be backwards compatible. This has implications on how it can 
be handled. Either simply redefine in the updated and forcing one to 
keep track of updated or not implementations. The other would be to 
ignore this problem.
- As fallback for old implementations is to use RTCP for this 
synchronization.

* Removal of Timed request

- Consensus to disallow if for now. The syntax may be left in for 
backwards completeness.

* How to distinguish the updated specification.

- Due to multiple SSRC discussion we revisited mechanisms to distinguish 
a updated server. One possible solution would to upgrade the version to 
1.1. We should consider this more in the future when we comes closer to 
a finished specification.
- Should look into more detail how this should work and if we adapt HTTP 
model?

* Warning header

- Could be good to provide more information about what happens in 
certain cases and for debugging.
- Needs to look into HTTP and SIP for more consideration how to use it.
- Any addition should be considered if this will delay the new updated 
draft.
- Needs more consideration.

-- 

Magnus Westerlund 

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

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