Subject: [Ice] RTCP multiplexing clarification to ICE bis

From: Ari Keränen <[email-masked]>
Date: Tue, 20 Oct 2015 15:19:32 +0300

Hi all,

Currently the ICE-bis spec says about RTCP and components following [1]:

    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.

However, if implementation is multiplexing both RTP and RTCP in the same 
port -- which seems to be more and more common practice today -- this 
"MUST" obviously isn't true. And in general we are now recommending to 
not use multiple candidates. Therefore, I'd suggest clarifying this with 
something like:

    For RTP-based media streams, unless both RTP and RTCP are multiplexed
    in 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 both RTP and RTCP in separate components, it would end up with
    2*K host candidates if an agent has K IP addresses.

And also make similar changes to other places where separate component 
IDs are discussed.

Does that sound OK?

Cheers,
Ari (as ICE-bis editor)

[1] https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-00#section-4.1.1.1

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 20 Oct 2015 13:55:31 +0000

> On Oct 20, 2015, at 8:19 AM, Ari Keränen <[email-masked]> wrote:
> 
> Hi all,
> 
> However, if implementation is multiplexing both RTP and RTCP in the same port -- which seems to be more and more common practice today -- this "MUST" obviously isn't true. And in general we are now recommending to not use multiple candidates. Therefore, I'd suggest clarifying this with something like:
> 
> And also make similar changes to other places where separate component IDs are discussed.

I think “using” multiplexing is vague — if you’re prepared to fall back to non-multiplexed, you need to obtain candidates for both components, even if you’d prefer multiplexed.

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.

---

From: Ari Keränen <[email-masked]>
Date: Tue, 20 Oct 2015 17:22:55 +0300

On 20/10/15 16:55, Jonathan Lennox wrote:
>> 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.
>>
>>
>> However, if implementation is multiplexing both RTP and RTCP in the
>> same port -- which seems to be more and more common practice today
>> -- this "MUST" obviously isn't true. And in general we are now
>> recommending to not use multiple candidates. Therefore, I'd suggest
>> clarifying this with something like:
>>
>> For RTP-based media streams, unless both RTP and RTCP are
>> multiplexed in 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 both RTP and RTCP in separate components, it would
>> end up with 2*K host candidates if an agent has K IP addresses.
>>
>>
> I think “using” multiplexing is vague — if you’re prepared to fall
> back to non-multiplexed, you need to obtain candidates for both
> components, even if you’d prefer multiplexed.

Thanks Jonathan!

What would be a better word(ing) for this in the ICE bis context? The 
proper fallback text can then be included in the SDP draft.

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

Cheers,
Ari

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 20 Oct 2015 20:38:47 +0000

> On Oct 20, 2015, at 10:22 AM, Ari Keränen <[email-masked]> wrote:
> 
> What would be a better word(ing) for this in the ICE bis context? The proper fallback text can then be included in the SDP draft.

Maybe something like, “for RTP-based media streams, unless both RTP and RTCP will definitely be multiplexed on the same UDP port”, with a note to the effect of “Note that if RTCP multiplexing is being offered in a way that allows fallback to a non-multiplexing mode, the offerer MUST gather candidates with a component ID of 2, but the answerer need not, if it wishes to use multiplexing; in this case, connectivity checks will not be done on the component 2 candidates."

> Makes sense to me. This also relates to the discussion Christer started at the MMUSIC list.
> 
> 
> Cheers,
> Ari
> 
>

---

From: Ari Keränen <[email-masked]>
Date: Wed, 28 Oct 2015 22:21:52 +0900

On 21/10/15 05:38, Jonathan Lennox wrote:
>>>> 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.
>>>>
>>>>
>>>> However, if implementation is multiplexing both RTP and RTCP in
>>>> the same port -- which seems to be more and more common
>>>> practice today -- this "MUST" obviously isn't true. And in
>>>> general we are now recommending to not use multiple candidates.
>>>> Therefore, I'd suggest clarifying this with something like:
>>>>
>>>> multiplexed in 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 both RTP and RTCP in separate
>>>> components, it would end up with 2*K host candidates if an
>>>> agent has K IP addresses.
>>>>
>>>>
>>> I think “using” multiplexing is vague — if you’re prepared to
>>> fall back to non-multiplexed, you need to obtain candidates for
>>> both components, even if you’d prefer multiplexed.
>>
>> Thanks Jonathan!
>>
>> What would be a better word(ing) for this in the ICE bis context?
>> The proper fallback text can then be included in the SDP draft.
>
> Maybe something like, “for RTP-based media streams, unless both RTP
> and RTCP will definitely be multiplexed on the same UDP port”, with a
> note to the effect of “Note that if RTCP multiplexing is being
> offered in a way that allows fallback to a non-multiplexing mode, the
> offerer MUST gather candidates with a component ID of 2, but the
> answerer need not, if it wishes to use multiplexing; in this case,
> connectivity checks will not be done on the component 2 candidates."

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?

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Oct 2015 13:29:42 +0000

Hi,

...

>    this case, connectivity checks will not be done on the component ID 2

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Oct 2015 06:53:35 +0000

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,

...

Regards,

Christer

Cheers,
Ari