Subject: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jul 2012 00:09:13 +0200

Hi,

A question related to RTP/RTCP multiplexing with BUNDLE.

BUNDLE allows the usage of identical port numbers for multiple m- lines. It also
expects a remote endpoint that does not support BUNDLE to send media associated
with multiple m- lines to that single port, even if the remote endpoint itself will use
different ports for each m- line.

In addition, the BUNDLE client can also multiplex RTP and RTCP, using the a=rtcp-mux attribute.

However, RFC 5761 says that one must be able to receive RTCP on the default RTCP port,
if the remote endpoint does not support a=rtcp-mux attribute.

But, even if the remote endpoint does not support RTCP/RTP muxing, the question is whether
the local endpoint could still use the same port for RTCP/RTP - and expect the remote endpoint
to send both RTP and RTCP to that single port (even if the remote endpoint itself uses different
ports for RTP and RTCP). In addition to the a=rtcp-mux attribute, the local endpoint
would use the a=rtcp attribute, containing the RTP port value.

That would also, when ICE is used, prevent the local endpoint from having to reserve
RTCP specific candidate ports.

Regards,

Christer

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 5 Jul 2012 19:14:41 +0000

Hi Christer,

I think the question boils down to whether the fallback port for RTCP described in section 5.1.3 of RFC5761 could be the same as the RTP port. This looks fine from a pragmatic point of view. However, the following statements from RFC5761 seem to forbid it:

   On receipt of the answer, the offerer looks for the presence of the
   "a=rtcp-mux" line for each media where multiplexing was offered.  If
   this is present, then connectivity checks proceed as if only a single
   candidate (for RTP) were offered, and multiplexing is used once the
   session is established.  If the "a=rtcp-mux" line is not present, the
   session proceeds with connectivity checks using both RTP and RTCP
   candidates, eventually leading to a session being established with
   RTP and RTCP on separate ports (as signalled by the "a=rtcp:"
   attribute).

Not sure if the statement "eventually leading to a session being established with RTP and RTCP on separate ports" was intentional. If not, it needs to be fixed.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
|Sent: Thursday, July 05, 2012 3:39 AM
|To: [email-masked]
|Subject: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used
|
|Hi,
|
|A question related to RTP/RTCP multiplexing with BUNDLE.
|
|BUNDLE allows the usage of identical port numbers for multiple m- lines. It also
|expects a remote endpoint that does not support BUNDLE to send media associated
|with multiple m- lines to that single port, even if the remote endpoint itself will use
|different ports for each m- line.
|
|In addition, the BUNDLE client can also multiplex RTP and RTCP, using the a=rtcp-mux attribute.
|
|However, RFC 5761 says that one must be able to receive RTCP on the default RTCP port,
|if the remote endpoint does not support a=rtcp-mux attribute.
|
|But, even if the remote endpoint does not support RTCP/RTP muxing, the question is whether
|the local endpoint could still use the same port for RTCP/RTP - and expect the remote endpoint
|to send both RTP and RTCP to that single port (even if the remote endpoint itself uses different
|ports for RTP and RTCP). In addition to the a=rtcp-mux attribute, the local endpoint
|would use the a=rtcp attribute, containing the RTP port value.
|
|That would also, when ICE is used, prevent the local endpoint from having to reserve
|RTCP specific candidate ports.
|
|Regards,
|
|Christer
|_______________________________________________
|mmusic mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 Jul 2012 09:00:43 +0200

On 2012-07-05 21:14, Muthu Arul Mozhi Perumal (mperumal) wrote:
> Hi Christer,
> 
> I think the question boils down to whether the fallback port for RTCP
> described in section 5.1.3 of RFC5761 could be the same as the RTP
> port. This looks fine from a pragmatic point of view. However, the
> following statements from RFC5761 seem to forbid it:
> 
> this is present, then connectivity checks proceed as if only a
> single candidate (for RTP) were offered, and multiplexing is used
> once the session is established.  If the "a=rtcp-mux" line is not
> present, the session proceeds with connectivity checks using both RTP
> and RTCP candidates, eventually leading to a session being
> established with RTP and RTCP on separate ports (as signalled by the
> "a=rtcp:" attribute).
> 
> Not sure if the statement "eventually leading to a session being
> established with RTP and RTCP on separate ports" was intentional. If
> not, it needs to be fixed.
> 

As co-author of RFC5761 I think that sentence reflects how we perceived
it would be used. In other words we only thought of the current legacy,
not what could happen when someone made additional proposals that
interacts with the RTP and RTCP port multiplexing. And based on that you
would fall back to having different ports.

However, I think I have found an issue that prevents one from using the
same port for RTP and RTCP on one side. What I can figure out there
exist nothing in a STUN binding request that are different between a
binding request targeted to the ICE candidate for component ID=0 and
component ID=1. If those two ICE candidates are co-located on the same
port then you don't know which component the binding request is targeted
for. It appears that the only thing keeping those separate is that the
different components would not be present at the same base address+port.

I think this identifies another requirement on bundle as the same is
true between ICE media streams, i.e. m=lines. To ensure that different
m=lines and their candidates can be correctly associated an OFFER with
bundle MUST contain different ufrag per m= block. That way the offerer
can use the security mechanism to verify that this STUN binding request
is intended for m= context X and not any of the others. This is not the
prettiest, but at least possible.

I hope someone can poke a hole in my reasoning and show some way this
can be avoided.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
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: Fri, 6 Jul 2012 11:25:22 +0200

> different components would not be present at the same base address+port.

I forgot one thing when writing this. When the offerer gets the SDP
answer and the candidates it contains it will know the source
address+port for any candidate that matches the ones the answerer
provided. Thus most of the answers binding requests will be correctly
determined and bound to the right component. Unfortunately there exist
peer-reflexive candidates and those can't be correctly bound at this stage.

Cheers

Magnus Westerlund