Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Magnus Westerlund <[e-mail]>]

Hi,
(as individual)

Although this discussion really should be on MMUSIC, I am still
following up here. Anything we come to conclude here really need to go
to MMUSIC for confirmation.

Justin, I do agree that it appear unnecessarily of having to include an
RTCP transport in an OFFER when the offerer know the answerer is BUNDLE
capable. I am fine with that and think the rule needed here is something
along the line of the below:

A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is already
required). In any answer by a BUNDLE capable endpoint, it MUST NOT
change the usage of a=rtcp-mux. If it is present in the offer, it must
be confirmed to be used in the answer, and if not present in the offer,
it MUST NOT be added in the answer. An BUNDLE capable endpoint is
RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might not
be suitable include, lack RTP payload types, or cases when RTCP traffic
is needed to be on its own transport flow (5-tuple) to enable QoS or
other traffic handling functionalities.

The reason for writing the rule like the above, is that then an endpoint
can choose when creating an offer to renegotiate the use of a=rtcp-mux.
For example due to it running out of available PTs.

Feedback on this proposal?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------