Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Magnus Westerlund <[e-mail]>]

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.

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?

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