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

[Christer Holmberg <[e-mail]>]

Hi,

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

As indicated, BUNDLE actually already DOES mandate a=rtcp-mux in the first offer, but it is optional for the answer, to the suggestion is to mandate it in the first answer.

Regards,

Christer