Subject: RE: [MMUSIC] RTSP transport negotiation

From: "Enrico Balatti" <[email-masked]>
Date: Tue, 4 Nov 2003 13:57:20 +0100

Hi Geetha,

recently I've implemented the solution a) that you mentioned using well know
open source RTSP client and server implementation.
I noticed that sending the SETUP during the play state (to change the "destination" of RTP packets)
and then send the PLAY with the Range header doesn't work very well due to syncronization problems.
The only working solution I found, was to send the PAUSE method before the SETUP
and the PLAY. I think this behaviour is due to the RTSP client-server implementation that
I've used and maybe it doesn't happen with other implementation.

Anyway, I think that (in the case of client mobility) the best solution should be that the client sends only the SETUP request with the new "client_ip" without any other RTSP message (PAUSE and PLAY).

Regards,
Enrico

------------------------------------------------------------------
Ing Enrico M. Balatti
CEFRIEL - Politecnico di Milano
ICT Center of Excellence For Research, Innovation,
Education & industrial Labs partnership
via Fucini 2, 20133 Milano (ITALY)
voice: +39 0223954327 fax: +39 0223954527
e-mail: [email-masked] <mailto:[email-masked]>   www.cefriel.it <http://www.cefriel.it> 
------------------------------------------------------------------

-----Original Message-----
From: Geetha Srikantan [mailto:[email-masked]]
Sent: venerdì 31 ottobre 2003 19.44
To: Enrico Balatti
Cc: [email-masked]
Subject: RE: [MMUSIC] RTSP transport negotiation

hi Enrico,

Thanks for the comments..

That's true - per the current spec we cannot have a Range header in the
SETUP request.
However, if there were no Range header in the SETUP request during play
state, the client would have to either 
(a) send a PLAY request with a Range header and use the PLAY response 
    for synchronization, or,
(b) live with the range selected by the server when it receives a SETUP 
    during play state.

With (a) there is the issue of an extra PLAY request-response. It might
just be better for the client to issue a PAUSE from the old transport
setting, send a SETUP request to modify transport and PLAY to resume
playing from the Range of the client's choosing. Here the transport
negotiation happens in Ready state not Play state.

With (b) there is a high likelihood of synchronization problems when
transport parameters change - RTP packets would get delivered to the old
transport, and discarded; the server has no way of knowing the gap in
time between when it processes the SETUP during play and when the
packets it already sent didn't actually get used by the player. This
implies media glitches at the client are a real possibility.

My inclination is to go with either specifying a Range header in the
SETUP request during play state or send the SETUP request without Range,
follow it up with a PLAY request with Range header. In the latter case
we'd be violating another restriction in the spec about issuing PLAY
requests during Play state, I believe. So this implies the spec would
have to modify restrictions on either the SETUP request or the PLAY
request.

It would be good to get more comments on this, especially from the
authors.

thanks
geetha

On Wed, 2003-10-29 at 06:02, Enrico Balatti wrote:
> Dear Geetha,
> 
> >... 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
> 
> 
> I'm not sure the Range field can be aplicated to the SETUP request.
> From the specification it seems the Range is applicable on the SETUP response
> but not in the SETUP request.
> 
>    Header              Where  Proxy DES OPT SETUP PLAY PAUSE TRD  
> 
>    Range                 R           -   -    -    o     o   -
>    Range                 r           -   -    c    m*   m*   -
> 
> 
> Best Regards,
> Enrico
> 
> 
> 
> 
> ------------------------------------------------------------------
> Ing Enrico M. Balatti
> CEFRIEL - Politecnico di Milano
> ICT Center of Excellence For Research, Innovation,
> Education & industrial Labs partnership
> via Fucini 2, 20133 Milano (ITALY)
> voice: +39 0223954327 fax: +39 0223954527
> e-mail: [email-masked] <mailto:[email-masked]>   www.cefriel.it <http://www.cefriel.it> 
> ------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From: Geetha Srikantan [mailto:[email-masked]]
> Sent: mercoledì 22 ottobre 2003 7.26
> To: [email-masked]
> Subject: [MMUSIC] RTSP transport negotiation
> 
> 
> 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

---

From: Geetha Srikantan <[email-masked]>
Date: Tue, 04 Nov 2003 10:16:47 -0800

hi Enrico,

Thanks for sharing your experience with implementing this.

I wouldn't mind dropping the Range header from SETUP, as long as
we also specify (please see my reply to Magnus on the topic):

(a) To support transport negotiation in play state, the client may issue
    SETUP to change transport *before* switching to the new transport,
    and,
(b) the client will switch to the new transport before buffers overrun
    at the new transport. 

If transport negotiation is required in play state and (a) and (b)
cannot be assumed, the client should issue a PAUSE, SETUP(*) and PLAY
- this implies that transport negotiation occurs in ready state and not
in play state.

Does that sound reasonable?

geetha