Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Justin Uberti <[e-mail]>]

On Wed, Mar 12, 2014 at 1:16 AM, Magnus Westerlund <
[e-mail]> wrote:

> On 2014-03-10 21:09, Christer Holmberg wrote:
> > Hi,
> >
> >>>>>>> Before I comment on your proposal, let's take a few steps
> >>>>>>> back (maybe it can even solve your issue).
> >>>>>>>
> >>>>>>> BUNDLE currently mandates the usage of both the SDP
> >>>>>>> rtcp-mux and rtcp attributes. I remember we had
> >>>>>>> discussions about that, but I don't remember the
> >>>>>>> justification at the moment. But, I wonder whether that
> >>>>>>> text is from before we made a decision that, unless both
> >>>>>>> endpoints support BUNDLE, no endpoint will use a single
> >>>>>>> address:port.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> So, the question is: do we really need the SDP rtcp
> >>>>>>> attribute?
> >>>>>>
> >>>>>> I think it is a question of how you want the fallback to
> >>>>>> work. In the case of bundle only lines, a non  bundle
> >>>>>> supporting peer will reject them, thus no issues with what
> >>>>>> is written around RTCP-mux and a=rtcp in those m= blocks.
> >>>>>> However, the first one if you want that to support fallback
> >>>>>> that makes sense then you will need both a=rtcp-mux and an
> >>>>>> a=rtcp (with a different port) to handle that with optimal
> >>>>>> backwards compatibility.
> >>>>>>
> >>>>>> Regarding the motivation for a=rtcp-mux and a=rtcp, I think
> >>>>>> it is reasonably straight forward. We want a=rtcp-mux to
> >>>>>> minimize port usage, i.e. ports=1. Not supporting
> >>>>>> a=rtcp-mux with bundle that would mean two ports (RTP and
> >>>>>> RTCP) for the bundle group. To get the backwards
> >>>>>> compatibility the usage of a=rtcp would be required.
> >>>>>
> >>>>> Keep in mind that the offerer must always be prepared that
> >>>>> the answerer does not support the rtcp-mux attribute (or the
> >>>>> rtcp attribute).
> >>>>
> >>>> Yes, that was what I meant with fallback in the above text.
> >>>> What you do in case the peer doesn't support bundle.
> >>>>
> >>>>> So, at least my understanding is: no matter whether BUNDLE is
> >>>>> used or not, if the answer does not contain a rtcp-mux (e.g.
> >>>>> in case of fallback) attribute, the offerer must use the
> >>>>> default "rtp+1" port.
> >>>>
> >>>> I have a tendency to agree, which means that the first m= block
> >>>> in a bunde-only group will be required to contain a=rtcp and if
> >>>> RTCP mux is desired also that attribute.
> >>>>
> >>>> I think a=rtcp could be skipped for a bound-only m= block due
> >>>> to the requirement on supporting a=rtcp-mux if you do bundle.
> >>>
> >>> For bundle-only, I actually think BOTH can be skipped, because
> >>> bundle-only will by default use whatever address:port is
> >>> negotiated - both for RTP and RTCP.
> >>
> >> No, I see a path of grief to not explicitly signal things when you
> >> use them.
> >
> > But, the whole idea of using port zero in bundle-only was that, if
> > the answerer supports BUNDLE, port zero will be replaced with the
> > negotiated address:port.
> >
> > When you send the offer, you don't yet know which address:port will
> > be selected, so there is no idea to insert a=rtcp. Inserting
> > a=rtcp-mux probably doesn't harm, though, so I won't argue about it
> > :)
>
> Well, if you can't insert the port, the same applies to a=rtcp as to the
> port in the m= line.
>
> Because in the bundle-only case we are assuming and that assumption
> needs to apply also for a=rtcp. And for a bundle-only case I think the
> appropriate thing is to assume that a=rtcp-mux will be honored. To have
> it being honored you need explicit signal it. The a=rtcp can be
> considered redundant in this case, but I am sensitive to removing it as
> that would create a special case for a=bundle-only lines. I think it is
> better to simply include it, even if it will say a=rtcp:0
>
> >
> >> I also thought the a=rtcp-mux is a MUST to implement, not a MUST
> >> use.
> >
> > Currently the draft says MUST use. But, that may be a mistake, or a
> > leftover from previous procedures. I agree that one should be able to
> > use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports
> > for the RTP traffic and the RTCP traffic).
>
> I hope if people disagree that they shout now.
>

I think rtcp-mux has to be a MUST use when BUNDLE is used between the two
endpoints. (If the endpoint doesn't support BUNDLE, rtcp-mux is not
required.)

Otherwise, you get into weird edge cases, such as where you have a data
channel (no RTCP component), and then want to add audio (with RTP and RTCP
components). You could bundle the audio RTP over the existing data channel
transport, but it's not clear what you should do with the RTCP component.
Mandating rtcp-mux avoids this issue completely.

>
> >
> >>> But, for non-bundle-only, I still ask whether we really need
> >>> a=rtcp. Isn't a=rtcp-mux enough? If the answerer supports it, you
> >>> will use it, otherwise you will use rtp+1.
> >>
> >> My understanding is that a=rtcp has been required in any
> >> non-private network deployments due to >NATs for the last 10 years.
> >> Thus, I don't see how you can remove them and expect it to work,
> >> unless >you are doing a=rtcp-mux. Thus, my view would be that you
> >> can remove a=rtcp if you know that the >peer supprots a=rtcp-mux.
> >
> > Are you saying that we should use a=rtcp ONLY to indicate the RTP
> > port, in case the answerer does not support a=rtcp-mux?
>
> It has its normal usage, i.e. RTCP port in cases when a=rtcp-mux is not
> agreed on. In a bundle-only offer, I think the only reasonable approach
> is to handle it identically to the m= line port number.
>
> >
> >>> Otherwise, assume that the answerer supports BOTH a=rtcp and
> >>> a=rtcp-mux. Which has higher "priority"? How does the answerer
> >>> knows whether the offerer wants to use rtcp-mux, or whether it
> >>> wants to use whatever port is indicated in a=rtcp?
> >>
> >> That is a=rtcp-mux per RFC 5761 that has higher priority, please
> >> see Section 5.1.1.
> >
> > You are right - my mistake.
> >
> > But, never the less, if the offerer sends both a=rtcp-mux and a=rtcp,
> > unless a=rtcp points to the rtp port, the offerer needs to be
> > prepared to use 3 different ports for RTCP (rtp+1 port, rtp port and
> > rtp+<a=rtcp value>), because it does not know which attribute (if
> > any) the answerer supports, and which (if any) the answerer is
> > willing to use.
>
> This is actually not necessary, if one can get the rtp+1 port for RTCP,
> then include that in the a=rtcp line and everything is fine.
>
> I was under the impression that almost all SIP SDP O/A was using a=rtcp.
> But if that is a misunderstanding from my perspective, I still think the
> rules will hold. If you don't include the a=rtcp attribute, then the
> rtp+1 port is the equivalent of the a=rtcp value.
>
> From a bundle perspective, I think what needs to be considered is the
> actual or implied values on the m= blocks for the rtcp port when using
> bundle-only as well as the other case.
>
> Cheers
>
> Magnus Westerlund
> (As individual)
>
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
>
>