Subject: [MMUSIC] RTSP transport negotiation

From: Geetha Srikantan <[email-masked]>
Date: Tue, 21 Oct 2003 22:25:53 -0700

Hello everyone,

Here is the promised write-up on RTSP transport negotiation..sorry for
the delay. If there is agreement on the content of this note, I can
write up text for the RTSP draft.

thanks
geetha

Topic: RTSP Transport negotiation using SETUP during play state.

Introduction

The RTSP specification allows for negotiation of transport parameters
via the SETUP method, while the RTSP session is in play state. The
transport parameters that can be negotiated and the exact form of this
negotiation is under-specified in the RTSP documents. This note is an
attempt to clarify some of the issues around transport negotiation for
inclusion in the ongoing revision of RTSP.

The recent interest in mobility for RTSP implementations also impacts
transport parameters used by the session. For instance, a wireless
RTSP client could be assigned a new IP address, or may experience
change of network characteristics, while it is in the midst of a RTSP
session. These issues are also addressed in this note.

Outline:

1. Objective
2. Enumeration of all Transport Parameters
3. Transport Parameters Excluded from Negotiation
4. Negotiable Transport Parameters
5. Impact of Transport Negotiation
6. Examples
	6.1 Client IP Address Changes
	6.2 UDP -> TCP
	6.3 TCP -> UDP
7. Other transport related changes to RTSP draft
8. Summary

1. Objective: 

The main goals of this document are to
	* Provide an enumeration of transport parameters.
	* Identify transport parameters that cannot be negotiated
	  with minimal impact on other sessions.
	* Propose transport parameters that can be negotiated during
	  play state.
	* Determine implications of changing these parameters via a
	  SETUP request while the session is in play state.
	* Provide examples demonstrating transport negotiation.

2. Enumeration of all Transport Parameters

   The following is a list of all transport parameters in the current
   RTSP draft.

	unicast/multicast
	destination
	source
	mode (=PLAY)
	interleaved
	layers (for multicast)
	ttl (for multicast
	port (for multicast)
	client_port (for RTP)
	server_port (for RTP)
	ssrc (for RTP)
	url

3. Transport Parameters Excluded from Negotiation

   It is recommended that the following parameters be excluded from the
   negotiation process.

	mode
	url
	unicast/multicast
	layers
	ttl
	ssrc
	destination
	source

    As the "mode" parameter is restricted to a single value in the
current draft, it can be excluded.

    As per the recent proposal to not support addition of urls via SETUP
during play state, the "url" parameter can be excluded. 

    Changing from multicast to unicast based on a single RTSP session's
SETUP, would impact all the other clients accessing the multicast
session. 
Several issues need to be considered in this case, including transport
negotiation. Similarly, changing from unicast to multicast also has
implications beyond a single RTSP session. Changes to other
multicast-related parameters, "layers", "ssrc", "ttl" most likely
requires specification beyond transport negotiation.
The recommendation is to *not* specify changing the transport from
"unicast" to "multicast" or vice versa, and also not specify changes
to the "layers" and "ttl" parameters, in this draft. It is recommedned 
that negotiation of multicast-related transport parameters should be
deferred to an RTSP-extension document. 

    Once an RTSP session has been initiated and the "destination" and
"source" have been established - i.e. a multicast "destination" has
been identified, and the stream "source" has been identified, there
should be no need to change these parameters.  It is recommended that
the "destination" and "source" parameters not be negotiated when the
session is in play state.  The case of the client IP address change is
signaled in a different manner, outlined in the next section.

4. Negotiable Transport Parameters

   Hence there are three main conditions that require transport
negotiation for unicast:

	* client IP address changes
	* client wants to switch transport from UDP -> TCP 
	* client wants to switch transport from TCP -> UDP

   Changes in the client IP address can be indicated using a new
"client_ip" parameter. Hence the parameters that are impacted by
transport negotiation are:

	client_ip
	interleaved
	client_port
	server_port

5. Impact of Transport Negotiation

   The first column describes the primary change, the second and third
columns describe any secondary transport parameters that MUST or 
MAY change as a result of the primary change.

Changed			MUST			MAY	
-------			----			---
	
Client IP address	client_ip		client_port
						server_port

UDP -> TCP		interleaved		Server may change
			Drop client_port	interleaved channel ids
			Drop server_port	in response.

TCP -> UDP		client_port in request	client_ip
			server_port in response client_port in response	
			Drop interleaved

6. Examples

6.1 Client IP Address Changes

     C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1
	   CSeq: 1

     S->C: RTSP/1.0 200 OK
	   CSeq: 1
           Content-Type: application/sdp
	   Content-Length: 164

	   v=0
           o=- 2890844256 2890842807 IN IP4 172.16.2.93
           s=RTSP Session
           i=An Example of RTSP Session Usage
           a=control:rtsp://foo/twister
           t=0 0
           m=audio 0 RTP/AVP 0
           a=control:rtsp://foo/twister/audio
           m=video 0 RTP/AVP 26
           a=control:rtsp://foo/twister/video

     C->S: SETUP rtsp://foo/twister/audio RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;unicast;client_port=8000-8001

     S->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;unicast;client_port=8000-8001;
                      server_port=9000-9001
           Session: 12345678

     C->S: SETUP rtsp://foo/twister/video RTSP/1.0
           CSeq: 3
           Transport: RTP/AVP;unicast;client_port=8002-8003
           Session: 12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 3
           Transport: RTP/AVP;unicast;client_port=8002-8003;
                      server_port=9004-9005
           Session: 12345678

     C->S: PLAY rtsp://foo/twister RTSP/1.0
           CSeq: 4
           Range: npt=0-
           Session: 12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 4
           Session: 12345678
           RTP-Info: url=rtsp://foo/twister/video;
             seq=9810092;rtptime=3450012,
	   url=rtsp://foo/twister/audio;seq=5923;rtptime=22234432
	   Range: npt=0-30.76

... now change client IP address ....

     C->S: SETUP rtsp://foo/twister/video RTSP/1.0
           CSeq: 5
	   Transport: RTP/AVP;unicast;client_ip=<new IP address;
	              client_port=8002-8003;server_port=9004-9005
	   Range: npt=5-
           Session: 12345678
			
     S->C: RTSP/1.0 200 OK
           CSeq: 5
	   Transport: RTP/AVP;unicast;client_ip=<new IP address>;
		      client_port=8002-8003;server_port=9004-9005
	   RTP-Info: url=rtsp://foo/twister/video;
		    seq=<new>;rtptime=<new>,
	   Range: npt=5-30.76
	   Session: 12345678

     C->S: SETUP rtsp://foo/twister/audio RTSP/1.0
           CSeq: 6
	   Transport:RTP/AVP;unicast;client_ip=<new IP address>;
		     client_port=8000-8001;server_port=9000-9001
	   Range: npt=5-
           Session: 12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 6
	   Transport: RTP/AVP;unicast;client_ip=<new IP address>;
		      client_port=8000-8001;server_port=9000-9001
	   RTP-Info:url=rtsp://foo/twister/audio;
		    seq=<new>;rtptime=<new>
	   Range: npt=5-30.76	
	   Session: 12345678

6.2 UDP -> TCP

     C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0
	   CSeq: 1

     S->C: RTSP/1.0 200 OK
	   Content-Base: rtsp://foo/twister/
	   Content-Length: 230
	   Content-Type: application/sdp
	   Cseq: 1

	   v=0
	   o=- 3262117360 3262117360 IN IP4 0.0.0.0
	   s=RTSP Session
	   c=IN IP4 0.0.0.0
	   t=0 0
	   a=control:*
	   a=range:npt=0-10.566000
	   m=video 0 RTP/AVP 26
	   a=control:rtsp://foo/twister/video
	   m=audio 0 RTP/AVP 0
	   a=control:rtsp://foo/twister/audio

     C->S: SETUP rtsp://foo/twister/audio RTSP/1.0
	   CSeq: 2
	   Transport: RTP/AVP/UDP;unicast;client_port=8000-8001

     S->C: RTSP/1.0 200 OK
	   CSeq: 2
	   Session: 12345678
	   Transport: RTP/ACP/UDP;unicast;client_port=8000-8001;
		      server_port=9000-9001

     C->S: PLAY rtsp://foo/twister RTSP/1.0
	   CSeq: 3
	   Session: 12345678

     S->C: RTSP/1.0 200 OK
	   Content-Base: rtsp://foo/twister/
	   CSeq: 3
	   RTP-Info: url=rtsp://foo/twister/audio;seq=7028;rtptime=1339949552
	   Range: npt=0-
	   Session: 12345678

... now request TCP ...

     C->S: SETUP rtsp://foo/twister/audio RTSP/1.0
	   CSeq: 4
	   Transport: RTP/AVP/TCP;interleaved=0-1

     S->C: RTSP/1.0 200 OK
	   Cseq: 4
	   Transport: RTP/AVP/TCP;unicast;
		      client_ip=<client IP>;interleaved=0-1
	   RTP-Info: url=rtsp://foo/twister/audio;seq=<new>;rtptime=<new>
	   Range: npt=0-10.56600
	   Session: 12345678

6.3 TCP -> UDP

     C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0
	   CSeq: 1

     S->C: RTSP/1.0 200 OK
	   Content-Base: rtsp://foo/twister/
	   Content-Length: 230
	   Content-Type: application/sdp
	   Cseq: 1

	   v=0
	   o=- 3262117360 3262117360 IN IP4 0.0.0.0
	   s=RTSP Session
	   c=IN IP4 0.0.0.0
	   t=0 0
	   a=control:*
	   a=range:npt=0-10.566000
	   m=video 0 RTP/AVP 26
	   a=control:rtsp://foo/twister/video
	   m=audio 0 RTP/AVP 0
	   a=control:rtsp://foo/twister/audio

     C->S: SETUP rtsp://foo/twister/audio RTSP/1.0
	   CSeq: 2
	   Transport: RTP/AVP/TCP;interleaved=0-1

     S->C: RTSP/1.0 200 OK
	   Cseq: 2
	   Session: 12345678
	   Transport: RTP/AVP/TCP;unicast;client_ip=<client IP>;interleaved=0-1

     C->S: PLAY rtsp://foo/twister RTSP/1.0
	   CSeq: 3
	   Session: 12345678

     S->C: RTSP/1.0 200 OK
	   Content-Base: rtsp://foo/twister/
	   Cseq: 3
	   RTP-Info: url=rtsp://foo/twister/audio;seq=7028;rtptime=1339949552
	   Range: npt=0-
	   Session: 12345678

... now request UDP ...

     C->S: SETUP rtsp://foo/twister/audio RTSP/1.0
	   CSeq: 4
	   Transport: RTP/AVP/UDP;unicast;client_port=8000-8001
	   Range: npt=0-

     S->C: RTSP/1.0 200 OK
	   CSeq: 4
	   Transport: RTP/ACP/UDP;unicast;client_port=8000-8001;
		      server_port=9000-9001
	   RTP-Info: url=rtsp://foo/twister/audio;seq=<new>;rtptime=<new>
	   Range: npt=0-10.56600
	   Session: 12345678

7. Other transport related changes to RTSP draft

A few comments on draft-ietf-mmusic-rfc2326bis-04.txt relating to
transport parameters.

(a) Section 13.40:
    Page 81: Are "src_addr" and "dest_addr" parameters
    going away? If these are relevant for NAT, perhaps they belong in
    the NAT document?

    Page 83-83: BNF indicates "client_port" and
    "server_port" will be indicated as 'port1-port2'. This doesn't seem
    adequate for the case where the RTP and RTCP ports are non-adjacent
    (per the new RTP spec rfc 3550). 

    Proposal:
	client_port: rtp=<port>, rtcp=<port>
	server_port: rtp=<port>, rtcp=<port>

(b) Appendix B, B.1.1
    Page 115: Mentions "src_addresses" and
    "dest_addresses" - what are these?

    Page 116: "non-continuous" ports - might want to rephrase to
    "non-adjacent" (or "non-continguous") ports?

8. Summary

This note recommends negotiation of a few transport parameters and
specifies mechanisms to do so. One new transport parameter "client_ip" 
is recommended for use in cases where the client's IP address changes
during the session. 

It is also recommended that the client_port and server_port parameters
be specified further with the use of tags "rtp_port" and "rtcp_port"
to handle the case where these ports are non-contiguous.

-- 
Geetha Srikantan <[email-masked]>

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