Subject: Re: [Ice] RTCP multiplexing clarification to ICE bis

From: Ari Keränen <[email-masked]>
Date: Wed, 4 Nov 2015 15:49:24 +0900

Thanks Christer! Looks good to me.

If no one objects, I'll change this to the next revision.

Cheers,
Ari

On 30/10/15 15:53, Christer Holmberg wrote:
> Hi,
>
> Here is some suggested text from myself:
>
> "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),
> 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."
>
> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: Ice [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 28 October 2015 15:30
> To: Ari Keränen <[email-masked]>; Jonathan Lennox <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Ice] RTCP multiplexing clarification to ICE bis
>
> Hi,
>
> ...
>
>> Here's a new paragraph based on your proposal, using the new terminology:
>>
>>     Each component has an ID assigned to it, called the component ID.
>>     For RTP-based media streams, unless it is known for sure that RTP and
>>     RTCP will be multiplexed on the same UDP port, the RTP itself has a
>>     component ID of 1, and RTCP a component ID of 2.  If an agent is
>>     using RTCP without multiplexing, it MUST obtain a candidate for it.
>>     If an agent is using separate candidate IDs for RTP and RTCP, it
>>     would end up with 2*K host candidates if an agent has K IP addresses.
>>     Note that if RTCP multiplexing is being used in a way that allows the
>>     Initiating Agent to fall back to a non-multiplexing mode, the
>>     Initiating Agent MUST gather candidates also for RTCP, but the
>>     Responding Agent need not to, if it wishes to use multiplexing; in
>>     this case, connectivity checks will not be done on the component ID 2
>>     candidates.
>>
>> Is that OK?
>
> I think the text is a little confusing. I'll try to come up with a suggestion in order to (hopefully) make it a little more clear.
>
> Regards,
>
> Christer
>
>
>
>>>> Thus, for proper fallback, an offerer needs to obtain candidates for
>>>> both components, but an answerer can obtain only component 1 if the
>>>> offerer offered multiplexing and it wants to use it.
>>>>
>>>> Thus, I think ice-sip-sdp needs to say that offers MUST obtain
>>>> candidates for both RTP and RTCP, for backward compatibility.
>>>> ICE-bis proper can make this conditional, though.
>>>
>>> Makes sense to me. This also relates to the discussion Christer
>>> started at the MMUSIC list.
>
> If the proposed text works for everyone, we'll make the change across the document and update sip-sdp draft too according to the proposal above.
>
>
> Cheers,
> Ari
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>