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

[Ari Keränen <[e-mail]>]

Hi,

These changes look good to me. If no one objects, I'll make the changes for the next revision.


Thanks,
Ari

> On 02 Dec 2015, at 16:12, Christer Holmberg <[e-mail]> wrote:
> 
> 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