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

[Magnus Westerlund <[e-mail]>]

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

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------