Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

Whilst I agree that BUNDLE should not assume ICE is used as Christer stated we do need to show how it is used with ICE.

The interaction between ICE and Bundle is a potential problem and looks quite messy to me given the multitude of transport addresses that might be contained in the various candidates relating to the different candidate type, components, and rel-addr/port. The meaning/relevance of all these addresses when bundle is used needs to be explained.

My initial feeling was that we should include something in the candidate itself to make it clear what transport address is relevant if bundle is used but so far I have not had much feedback and I am not sure whether it makes things worse or better.

Regards
Andy

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Christer Holmberg
> Sent: 07 May 2013 20:23
> To: Paul Kyzivat; mmusic@ietf.org
> Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?
> 
> Hi,
> 
> >I'd just like to point out that AFAIK bundling doesn't *require* ICE.
> >So lets not make any assumptions that assume ICE is used.
> 
> Agree.
> 
> We do need to describe how ICE is used with BUNDLE, but BUNDLE can also
> be used without ICE.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> On 5/6/13 2:00 PM, Dale R. Worley wrote:
> >> From: Bernard Aboba <bernard_aboba@hotmail.com>
> >>
> >>> But it doesn't seem that there is much to gain by mandating rtcp-
> mux
> >>> in the first offer/answer, the one where actual bundling is not
> >>> being done.  All of the RTP/RTCP routing code that is active at
> that
> >>> point has to support non-rtcp-mux operation already.
> >>
> >> [BA]  Support for rtcp-mux in the first offer/answer is mandated by
> >> RFC 5761 Section 5.1.3:
> >>     The initial SDP offer MUST include this
> >>     attribute at the media level to request multiplexing of RTP and
> RTCP
> >>     on a single port.
> >
> > I don't see how 5761 mandates that a=rtcp-mux MUST be used in the
> > first offer of a bundle negotiation.  The context of your quote is:
> >
> >     5.1.3.  Interactions with ICE
> >     [...]
> >     If it is desired to use both ICE and multiplexed RTP and RTCP,
> the
> >     initial offer MUST contain an "a=rtcp-mux" attribute to indicate
> that
> >     RTP and RTCP multiplexing is desired and MUST contain
> "a=candidate:"
> >     lines for both RTP and RTCP along with an "a=rtcp:" line
> indicating a
> >     fallback port for RTCP in the case that the answerer does not
> support
> >     RTP and RTCP multiplexing.  This MUST be done for each media
> where
> >     RTP and RTCP multiplexing is desired.
> >
> > That is, if the device desires to use both ICE and multiplex, it has
> > to use a=rtcp-mux in the first offer of ICE's set of offers.  But
> > we're talking about bundling, which (in the current design) contains
> > *two* ICE cycles, since the second offer (in the bundle spec) is
> going
> > to restart ICE.  And the device need not "desire" to use "both ICE
> and
> > multiplexed RTP and RTCP" during the first of the ICE cycles.
> >
> > Dale
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic