Subject: [MMUSIC] RTSP: Proposal for RTP and RTCP multiplexing negotiation

From: Magnus Westerlund <[email-masked]>
Date: Mon, 09 Mar 2009 11:27:40 +0100

Hi,

Here is a proposal for how to do RTP and RTCP multiplexing
(draft-ietf-avt-rtp-and-rtcp-mux) negotiation with RTSP 2.0.

In Transport header section, RTP specifics:

  RTCP-mux:  Use to negotiate the usage of RTP and RTCP multiplexing
         [I-D.ietf-avt-rtp-and-rtcp-mux] on a single underlying
         transport stream.  The presence of this parameter in a SETUP
         request indicates the clients support and desire to use RTP and
         RTCP multiplexing.  The client MAY still include two transport
         streams in the Transport header specification to handle cases
         if RTP and RTCP multiplexing is not supporte dy the server.  If
         the server supports the usage of RTP and RTCP MUX it SHALL
         include this parameter in the response and strip down the
         transport address negotiation to a single src_addr and
         dest_addr.  If the server does not supprt RTP and RTCP
         multiplexing is removes this parameter from the transport
         specification in response and treat the specification as if the
         parameter was not included.

Syntax for Parameter:

tr-parameter        = (SEMI ( "unicast" / "multicast" ))
                    / (SEMI "interleaved" EQUAL channel [ "-" channel ])
                    / (SEMI "ttl" EQUAL ttl)
                    / (SEMI "layers" EQUAL 1*DIGIT)
                    / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
                    / (SEMI "mode" EQUAL mode-spec)
                    / (SEMI "dest_addr" EQUAL addr-list)
                    / (SEMI "src_addr" EQUAL addr-list)
                    / (SEMI trn-param-ext)
                    / (SEMI "setup" EQUAL contrans-setup)
                    / (SEMI "connection" EQUAL contrans-con)
                    / (SEMI "RTCP-mux")

C.1.6.4.  RTP and RTCP Multiplexing

   RTSP can be used to negotiate the usge of RTP and RTCP multiplexing
   as described in [I-D.ietf-avt-rtp-and-rtcp-mux].  This allows servers
   and client to reduce the amount of resources required for the session
   by only requiring one underlying transport stream per media stream
   instead of two when using RTP and RTCP.  This lessens the server port
   consumption and also the necessary state and keep-alive work when
   operating across Network and Address Translators [RFC2663].

   Content must be prepared with some consideration for RTP and RTCP
   multiplexing, mainly ensuring that the RTP payload types used does
   not collide with the ones used for RTCP packet types this option
   likely needs explicit support from the content unless the RTP payload
   types can be remapped by the server and that is correctly reflected
   in the session description.  Beyond that support of this feature
   should come at little cost and much gain.

   It is recommended that if the content and server supports RTP and
   RTCP multiplexing that this is indicated in the session description,
   for example using the SDP attribute "a=rtcp-mux".  If indicate or
   otherwise desired by the client it can include the Transport
   parameter "RTCP-mux" in any transport specification where it desires
   to use RTCP-mux.  The server will indicate if it supports RTCP-mux.
   Server and Client SHOULD support RTP and RTCP multiplexing.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 09 Mar 2009 14:01:25 +0100

Rémi Denis-Courmont skrev:
> On Mon, 09 Mar 2009 11:27:40 +0100, Magnus Westerlund
> <[email-masked]> wrote:
> What happens if the server does not support RTCP-mux and the client
> specified only one transport stream?

That would be interpreted as only want to have RTP, not RTCP, according
to the existing rules. That is what intended with the second half of the
text.

> Should the client only be allowed if it knows that the server supports
> RTCP-mux (e.g. a=rtcp-mux was present in SDP)?

No, that is specified in C.1.6.4:

If indicate or
   to use RTCP-mux.

> Conversely, can the client assume that RTCP-mux is supported if the SDP
> contained a=rtcp-mux?

That I would say yes to. I can clarify that.
> 
> Otherwise, I think this is a good idea.
> 

Yes.

Magnus Westerlund