Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Justin Uberti <[e-mail]>]

On Mon, Mar 17, 2014 at 6:23 AM, Magnus Westerlund <
[e-mail]> wrote:

> On 2014-03-14 17:26, Justin Uberti wrote:
> >
> >
> >
> > On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund
> > <[e-mail] <mailto:[e-mail]>>
> > wrote:
> >
> >     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?
> >
> >
> > I am not OK with this. It just gets too complicated to deal with all the
> > cases, especially if with the provision that rtcp-mux can change during
> > the session.
>
> (still as individual)
>
> Lets be clear what we are discussing here. I don't think this is lot of
> cases. And if you don't want to implement this in your code generating
> offer, that is fine. What this describes is that your code handling
> reception of offers and generating answers must be able to handle the
> lack of a=rtcp-mux in any offer, rather than just the initial one.
>
> I would question if even that assumption holds considering what happens
> if people start implementing session resumption or session mobility
> between devices using rehydration style establishment procedures. What
> one sides consider an initial offer might not be the state the answering
> party is in. Thus, I am worried about cases that are first offer/answer
> exchange related.
>
> To my understanding you will have code to handle the following cases
> when offers contains:
>
> 1) No bundle, no a=rtcp-mux
> 2) No bundle, with a=rtcp-mux
> 3) Bundle, with a=rtcp-mux
>
> Considering that you support bundle, and you support usage or not of
> a=rtcp-mux. Then I don't see how the code handling the SDP logic for
> Bundle, without a=rtcp-mux is that significant.
>

It is significant because you always know you can rtcp-mux. And you always
know you can BUNDLE when rtcp-muxing. But I think trying to BUNDLE a
no-rtcp-mux m= line into a rtcp-mux m= line is asking for problems.

>
> First of all, to be robust, you have to be capable of handling
> significant reconfigurations of the Peer Connection session in an Offer.
> If someone moves the peer of one peer connection to another device
> anything can happen, and everything can change.
>
> Secondly, to be able to turn off a=rtcp-mux is one method which can free
> up PTs if one run out. The other would be first unbundle the media
> types, then to completely unbundle the media sources. The later would be
> far worse when it comes to requiring providing ICE candidates and
> dealing with new transports. I however think unbundling the media types
> is likely to resolve many of the PT shortage situations.
>
> Just to confirm, you are also against allowing any initial offer request
> with bundle but without a=rtcp-mux within that bundle-group?
>

I am against _any_ offer request with bundle and without a=rtcp-mux (as
indicated in the current bundle draft).

>
> This, I would question, as it prevents anyone from treating the RTCP
> packets differently from the RTP packets within one RTP session. I know
> that this has been done in some cases, including IMS.
>
> From a principal point of view I think this should be either be use of
> BUNDLE groups results in MUST use a=rtcp-mux with RTP or that any offer
> may change the usage of a=rtcp-mux. Anything else depending on initial
> offer appears very messy and prone to errors.
>
> I would appreciate if someone else would provide their input and views
> here!
>
> First on the question if they need to separate the RTP and RTCP at all
> within a BUNDLE group?
>
> Secondly if they see that splitting a bundle group into different groups
> if one runs into issue is a sufficient and more preferred method for
> dealing with any PT exhaustion issue?
>
>
> 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]
> ----------------------------------------------------------------------
>
>