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

From: Stefan Hakansson LK <[email-masked]>
Date: Tue, 10 Jul 2012 14:21:02 +0200

On 07/10/2012 02:18 PM, Stefan Håkansson LK wrote:
> On 2012-07-06 09:00, Magnus Westerlund wrote:
>   > 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 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.

So, now I am confused. Are we OK as is, or should the Bundle draft be 
updated, or something else? (To me it sound like the Bundle draft should 
be updated.)

Stefan

>
> 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: magnus.westerlund at ericsson.com
> ----------------------------------------------------------------------
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Jul 2012 14:31:21 +0200

> updated, or something else? (To me it sound like the Bundle draft should 

Yes, I think there is need for an update. But there is actually two
issues here.

One is the question of how a bundle implementation sending an offer to a
non-bundle capable answerer deals with determining which m= lines
particular received binding requests are related to in the case of
peer-reflexive candidates. This appears to be possible to resolve by
having different ufrags per m=line in the offer.

The second question is how to handle RTP-RTCP mux fallback. This does
not appear to be able to be resolved by using the ufrag as that is
either per session level or media level. Thus some other solution is
needed. One is to simply have to allocate and gather candidates for two
local ports even when supporting bundle. It is at least better than 2*N
where N is the number of bundled m= lines.

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden| mailto: [email-masked]