Re: [MMUSIC] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solution for indicating exclusive support of RTP/RTCP-mux.

[Christer Holmberg <[e-mail]>]

Any comments on this?

From: Ice [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: 16 November 2015 01:58
To: [e-mail]; [e-mail]
Cc: Ari Keränen <[e-mail]>
Subject: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solution for indicating exclusive support of RTP/RTCP-mux.


Hi,

I went through draft-ietf-mmusic-rfc5245bis-05, and identified the following paragraphs that need to be modified in order to support the ICE solution for exclusive support of RTP/RTCP-mux.

Also, I assume the discussion regarding the ICE solution should move to the ICE WG, while the discussion on the mux-exclusive draft will stay in MMUSIC.


Section 3:
-------------

OLD TEXT:


Component:  A component is a piece of a media stream requiring a

      single transport address; a media stream may require multiple

      components, each of which has to work for the media stream as a

      whole to work.  For media streams based on RTP, there are two

      components per media stream -- one for RTP, and one for RTCP.


NEW TEXT:


Component:  A component is a piece of a media stream requiring a

      single transport address; a media stream may require multiple

      components, each of which has to work for the media stream as a

      whole to work.  For media streams based on RTP, <new>unless RTP and RTCP

are multiplexed on the same port,</new> there are two

      components per media stream -- one for RTP, and one for RTCP.

Section 4.1.1.1:
--------------------

OLD TEXT:


   Each component has an ID assigned to it, called the component ID.

   For RTP-based media streams, the RTP itself has a component ID of 1,

   and RTCP a component ID of 2.  If an agent is using RTCP, it MUST

   obtain a candidate for it.  If an agent is using both RTP and RTCP,

   it would end up with 2*K host candidates if an agent has K IP

   addresses.


NEW TEXT (based on e-mail discussion):


Each component has an ID assigned to it, called the component ID.

For RTP-based media streams, unless RTP and RTCP are multiplexed on

the same port (RTP/RTCP multiplexing), the RTP has a component ID of 1

and RTCP a component ID of 2. In case of RTP/RTCP multiplexing, a

component ID of 1 is used for both RTP and RTCP.



When candidates are obtained, unless the agent knows for sure that

RTP/RTCP multiplexing will be used (i.e. the agent knows that the

other agent also supports, and is willing to use, RTP/RTCP multiplexing),

or unless the agent only supports RTP/RTCP multiplexing,

the agent MUST obtain a separate candidate for RTCP. If an agent has

obtained a candidate for RTCP, and end up using RTP/RTCP multiplexing,

the agent does not need to perform connectivity checks on the RTCP candidate.



If an agent is using separate candidates for RTP and RTCP, it will end up

with 2*K host candidates if the agent has K IP addresses.



NOTE: The responding agent, when obtaining its candidates, will typically know

whether the other agent supports RTP/RTCP multiplexing, in which case it will

not need to obtain a separate candidate for RTCP.





Section 4.2:
---------------

OLD TEXT:


Each component has an ID assigned to it, called the component ID.

      For RTP-based media streams, the RTP itself has a component ID of 1,

      and RTCP a component ID of 2.  If an agent is using RTCP, it MUST

      obtain candidates for it.

NEW TEXT:


Each component has an ID assigned to it, called the component ID.

      For RTP-based media streams, the RTP itself has a component ID of 1,

      and RTCP a component ID of 2.  If an agent is using RTCP, it MUST

      obtain candidates for it<new>, unless the agent only supports multiplexing

      of RTP and RTCP on the same port</new>.



Section 5.6.1:
-----------------

OLD TEXT:


   In the case of RTP, this would happen when one agent provides

   candidates for RTCP, and the other does not.  As another example, the

   offerer can multiplex RTP and RTCP on the same port and signals that

   it can do that in the SDP through an SDP attribute [RFC5761].

   However, since the offerer doesn't know if the answerer can perform

   such multiplexing, the offerer includes candidates for RTP and RTCP

   on separate ports, so that the offer has two components per media

   stream.  If the answerer can perform such multiplexing, it would

   include just a single component for each candidate -- for the

   combined RTP/RTCP mux.  ICE would end up acting as if there was just

   a single component for this candidate.


NEW TEXT:


   In the case of RTP, this would happen when one agent provides

   candidates for RTCP, and the other does not.  As another example, the

   offerer can multiplex RTP and RTCP on the same port and signals that

   it can do that in the SDP through an SDP attribute [RFC5761].

   However, since the offerer doesn't know if the answerer can perform

   such multiplexing, <new>and unless the offerer only supports multiplexing

   of RTP and RTCP on the same port,</new> the offerer includes candidates for RTP and RTCP

   on separate ports, so that the offer has two components per media

   stream.  If the answerer can perform such multiplexing, it would

   include just a single component for each candidate -- for the

   combined RTP/RTCP mux.  ICE would end up acting as if there was just

   a single component for this candidate.<new>If the offerer only supports

   multiplexing of RTP and RTCP on the same port, the offerer only includes

   candidates for RTP.</new>


Regards,

Christer