Subject: Re: [MMUSIC] RTSP transport negotiation

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Dec 2003 09:51:32 +0100

Hi Geetha,

Here is my comments on your write-up. I think one should be clearer on 
separating the two cases where one can "negotiate" transport parameters:
1. Initially when a stream is setup
2. Changing transport parameters during a session.

See more inline. I have not removed any of Geetha's mail to make it easy 
to read her initial text in full, thus it is a bit long.

Geetha Srikantan wrote:

> 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
> 

You are missing a few and "url" is not a parameter.
  dest_addr
  src_addr
  append
  Transport protocol and Profile
  Lower layer transport

> 
> 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.

I think that this is a very fundamental parameter if also record is add 
again in the future.

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

I think the Request URL are somewhat out of scope for this discussion, 
as it actually provides the scope for the negotiation. The Request URL 
will indicate for the server if the client desires to do:

1. Setup up a new stream (only possible in "init" or "ready" state)
2. Change the transport parameters for a stream.

However in both cases the transport parameters can be "negotiated" so 
this applies for both of them. I just thinks that one must be clear 
about the different scopes. However in both cases one must include all 
the parameters one likes to have applied.

> 
>     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.
> 

I think that SSRC can if not negotiated, at least be changed by the 
server if deemed necessary, however this is probably not recommended.

Transport protocol and profile does seem to belong to this class of 
parameters that are established initially but then not intended to be 
changed during a session.

> 
> 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
> 

I think we should clarify client ip and port with destination 
address/port. I also think an important parameter to discuss in this 
context is the lower layer transport. I would think that the transport 
protocol and profile are not likely to change.

>  
> 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
> 
> 

I think one should clarify that in TCP->UDP changes one must now include 
(add) a destination port in the request.

> 
> 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
> 

There shall be a "c=" line somewhere. Then a question, how does the 
client learn that if this session is multicast that it really is? Is 
that totally dependent on that the "c=" address is of multicast type?

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

If one would like to have a good example of initial "negotiation" then 
the client should include multiple transport specs for the server to 
choose from.

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

In the setup response the server should include a "ssrc" parameter to 
indicate what SSRC it will use and for which the RTP-Info is valid.

> 
>      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
> 

SSRC again.

>      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
> 

The parameter is not "client_ip" it is either "destination" or "dest_addr".

As discussed previously the use of Range in the Request makes little sense.
			
>      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
> 

I also think one should point out why one includes Range here. In 
regards to the RTP-Info, I think that one should primarily indicate the 
RTP sequence number in RTP-Info. Using rtptime combined with "Range" 
might not be the best, because one would normally not intend to change 
anything in the npt <-> RTP TS binding, as it would cause real problems 
for a client during playback.

> 
>      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?

In my opinion they are actually fundamental and belong to the core 
specification as they represent the basic addressing requirements of 
allowing for any transport setup.

> 
>     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). 
> 

That is what dest_addr and src_addr are created to address as they allow 
for enumerating any number of address/port constellations in case of 
IP/port based transport.

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

Bad Idea from a backwards compatibility stand point. That is why I 
proposed the dest_addr parameter to take care of this and hopefully any 
future problems. However I perhaps should be consider to ensure that any 
type of address can be expressed in this, by doing class, and string 
definition.

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

the unshortend versions of "src_addr" and "dest_addr".

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

Done.

> 
> 
> 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. 

I also do not understand why you need a new parameter when you have 
destination or dest_addr to use.

> 
> 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.
> 

As pointed out I don't think changing client_port and server_port is the 
right way to go.

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]

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

---

From: Geetha Srikantan <[email-masked]>
Date: Tue, 02 Dec 2003 15:59:58 -0800

hi Magnus,

Thanks for the comments. I should have clarified that this
document was mainly intended to address transport negotiation
in play state. Your point is well taken, that we do need to specify
transport negotiation when a stream is setup too.

Also I'm ok with using dest_addr, src_addr, client_port, server_port
instead of the new parameters in my document.

Rest inline..

>   Transport protocol and Profile

Right..will add those.

> I think that this is a very fundamental parameter if also record is add 

I agree that mode is an important parameter, however I am wondering
if it would be reasonable to change from say mode=play to mode=record
during play state? 
I guess this would enable Tivo-like functionality on a playing session,
is that what you had in mind?
If that's the case, this switch in parameter should be allowed.

> the parameters one likes to have applied.

Right, will include that in the next revision.

> server if deemed necessary, however this is probably not recommended.

I'll add a note about this.

> changed during a session.

I agree the transport protocol and profile should not be allowed to
change.

> protocol and profile are not likely to change.

So we do not allow changing:
transport protocol and profile.

We allow changing:
client ip and port
lower layer transport
server port

Server port may change only as a result of client address/port change.
Since the RTP/RTCP client and server endpoints need to be unique.

> (add) a destination port in the request.
Will add that.

> that totally dependent on that the "c=" address is of multicast type?

Yes, the c= line is missing..thanks for pointing it out.
That's usually how the client determines if it's 
a multicast - by looking at the address type in the c= line.

> the client should include multiple transport specs for the server to 

That seems reasonable. What would be the preferred format for that.
Some thing like this:

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

> indicate what SSRC it will use and for which the RTP-Info is valid.

Right..I missed that earlier..will include it.

> The parameter is not "client_ip" it is either "destination" or "dest_addr".
I'm ok with using dest_addr. I was not sure if it's ok to re-use 
dest_addr, that's why I introduced client_ip (and client_port later).

> As discussed previously the use of Range in the Request makes little sense.

Right this will be taken out.

> for a client during playback.

I think the concern is that the client may need to re-sync after
transport negotiation. I didn't mean to imply that there would be 
a change in the NPT <-> timestamp correspondence. Including 
seq and rtptime in RTP-Info would make it easier for the client.
I can rephrase it to say that the server should not change the NPT <=>
timestamp correspondence during transport negotiation.

> allowing for any transport setup.

Sounds good?

> for enumerating any number of address/port constellations in case of 

Would you please give an example of what this looks like
for non-adjacent RTP and RTCP ports for a stream?
Since RFC 3550 allows non-adjacent ports, the BNF in the current draft 
would mean this is written as:

 C->S SETUP rtsp://example.com/foo/bar/bar.rm RTSP/1.0
 CSeq: 2
 Transport: RTP/AVP;unicast;client_port=4588-6129

if the RTP port is 4588 and RTCP port is 6129.

This should not be interpreted as a port range by the server.
That's the problem I was referring to.

> type of address can be expressed in this, by doing class, and string 

If the client_port and server_port is rephrased to have non-adjacent
ports, then there is no need for the change I suggest.

> destination or dest_addr to use.

see earlier comment..

> As pointed out I don't think changing client_port and server_port is the 

see earlier comment..

thanks
geetha

-- 
Geetha Srikantan <[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Dec 2003 11:19:01 +0100

Hi Geetha,

Comments inline. This mail has resulted in the opening of the following 
source forge issue has been created:

http://rtsp.org/bug853175
http://rtsp.org/bug853178
http://rtsp.org/bug853184

> transport negotiation when a stream is setup too.

Good, I think that there is need to also consider the differences 
between initial SETUP transport negotiation and changing in Play state.

> instead of the new parameters in my document.

I think you haven't really understood tat dest_addr, replaces the 
destination together with client_port, and src_addr, replaces source and 
server_port as dest_addr carries one ore more address+port.

> If that's the case, this switch in parameter should be allowed.

I think this is something we need to consider further. In the core 
specification we don't have any other mode than play defined so we can 
probably put it in the list of attributes that are not changed, and if 
other modes becomes available need to be defined.

In regards to TiVo sessions, you mean cases when such functionality 
would be done through a server, for example for a live session. This is 
quite a change in RTSP perspective for the session. From being sending 
media from a server local source to a client it shall instead save the 
stream that for the client looks like a local server resource. For 
sessions with multiple media streams the change should happen 
simultaneously for all streams which is difficult for RTSP.

> Since the RTP/RTCP client and server endpoints need to be unique.

I agree that the server ports need to be possible to change, otherwise 
we will create quite difficult problems for us in the future if RTSP 
servers becomes part of NATed end-points, where a change of destination 
would very likely result in a change of the visible address/port for the 
client.

> a multicast - by looking at the address type in the c= line.

As a related problem, how does a client learn that a session can be 
distributed as multicast, but no multicast address is pre-assigned to 
the session when the SDP is published. It seems that we can't quite 
express this case. Or does someone see a possibility? Another 
interesting use case is if a multicast conference invites a RTSP server 
into the session and the controlling entity request the server to play 
to the already used multicast addresses. Does the server needs to be 
able to announce this support, or is it something the client simply ask 
for and the server either succeeds or fails?

> 			   RTP/AVP/TCP;interleaved=0-1

You need a "unicast" in the RTP/AVP/TCP transport specification also. 
Otherwise you are defaulting to multicast over TCP which can be a bit 
difficult.

> dest_addr, that's why I introduced client_ip (and client_port later).

I don't see that there are any semantic difference between destination 
address the first time around (initial setup), and the second (changing 
the parameter). What we perhaps should consider is if the server is 
required to recheck the transport parameter source and redirect the 
stream to that destination when a setup request is received.

I also thing we must consider the security threats when one implements 
this behaviour. When one establish a session the right client will be at 
least be certain that the session goes to the intended address if the 
destination is included in the SETUP response. However when sending a 
SETUP request to change the parameter any being able to snoop the 
traffic can now simply hijack the established session, unless we require 
authentication within the session. Using TLS for the RTSP messages only 
provides the security that the randomness of the session ID provides.

I think we need to consider the security implications much more. Geetha, 
can you please start a security section in relation to this.

> timestamp correspondence during transport negotiation.

you would not need a re-sync unless you have changed the NPT <-> RTP TS 
relation. What does people think? are there situation where there is a 
clear need to perform re-synchronization.

> That's the problem I was referring to.

No, the intention of the new dest_addr and src_addr parameter is to 
replace the usage of client_port and server_port when you have 
non-adjacent ports. Instead you use in case of RTP dest_addr and 
provides addr1+port1 and addr2+port2 thus ensuring that also scenarios 
where you desire delivery of RTCP and RTP to different IP addresses, for 
example due to NATs doing stupid translation.

A new issue with these parameter I haven't thought about before is the 
need for always including a destination address in the parameter. Is 
this problematic, and would work better if we add a place holder for 
indicate: Use the same address as my RTSP message transport connection? 
I guess it probably makes sense in cases of realm specific IP addresses, 
and other translation techniques which does not remap the ports only the 
IP address.

> ports, then there is no need for the change I suggest.

To be clear, we are not rephrasing the client_port or server_port due to 
backwards compatibility. You will be required to support the new 
specification and indicate that to be able to use non-adjacent ports.

Cheers

Magnus Westerlund