Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

[Paul Kyzivat <[e-mail]>]

On 1/24/16 4:58 PM, Suhas Nandakumar wrote:
>
>
> On Sun, Jan 24, 2016 at 12:21 PM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 1/24/16 2:36 PM, Suhas Nandakumar wrote:
>
>
>
>         On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat
>         <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>>
>         wrote:
>
>              On 1/24/16 4:41 AM, Suhas Nandakumar wrote:
>
>                  I might be repeating some discussions already made. So
>         please
>                  forgive me
>                  if all of the below suggestions is beaten to death
>
>                  *Use-case: Explicitly indicate RTCP Muxing and possibly
>         backward
>                  compatibility*
>
>                  I support a new attribute along with some rules for
>         existing
>                  attributes
>                  which allows backward compatibility (Strong goal of
>         SDP) and also
>                  exclusiveness of RTCP multiplexing
>
>                  Define a new attribute *"a=rtcp-mux-only" , which *in a
>         offer
>                  indicates
>                  that the end-point can't receive rtcp on separate port
>         than rtp.
>
>
>              It is *essential* to indicate the answerer behavior too.
>         For this to
>              provide backward support, the answerer who supports must also
>              include this attribute in the answer. If it isn't present
>         in the
>              answer, then the offerer knows that it hasn't been supported. I
>              think, in that case it must reoffer and either provide a
>         port pair,
>              or else drop the media stream, to prevent RTCP from going to an
>              uncontrolled port.
>
>
>         [Suhas] - Agreed Paul. I see backward compatibility in 2 ways.
>         One where
>         the agent understands a=rtcp-mux but not the a=rtcp-mux-only and
>         second
>         where the agent doesn't understand either. Let's think the answerer
>         behavior in both the cases
>
>         Case 1: Agent supports RFC5761 but not mux-only
>              In this scenario we mandate that the offer includes RFC5761
>         a=rtcp-mux as well whenever he offers with mux-only. Thus the
>         answerer
>         will still MUX the RTCP to RTP port following RFC5761 rules.
>
>         Case 2: Agent doesn't support RFC5761 and mux-only as well
>         This is  the case where the answerer can process just the
>         RFC3605 a=rtcp
>         attribute and can either :
>                  2a) send the rtcp to the port indicated in a=rtcp
>         attribute ,
>         thus effectively muxing
>                  2b) will think rtcp port specified as being error since it
>         matches the RTP port and reject the m=line. [[ note: this isn't
>         defined
>         as an error in RFC3605 ]]
>
>         Case 3: Answerer supports RFC5761, Mux-exclusive
>              In this successful scenario, the answerer can just include
>         a=rtcp-mux and a=rtcp-mux-exclusive in its answer and that is good
>         enough for the Offerer to know that Answerer is able to mux the rtcp
>         traffic towards the offerer and also wishes to receive muxed (no
>         fallback) rtcp traffic from the offerer
>
>         These seems to convert most of all the cases right
>
>
>     Agree.
>
>              I think this ought to be viewed as an update to 3605.
>
>
>     Maybe that isn't quite right, but it ought to be an update to
>     *something*.
>
>
> [Suhas] .. If i am not wrong, the above proposal doesn't need updates to
> RFC3605 and when used in combination with a=rtcp-mux-only the intent is
> clear.

My point is that introducing a new replacement for a=rtcp solves the 
problem that rtcp-mux-only solves, but also solves other problems.

	Thanks,
	Paul

>     It is mostly a=rtcp that is broken, because it isn't acknowledged.
>     Any plausible use of it ends up being broken if the answerer doesn't
>     support it, but the offerer has no way of telling that.
>
>     a=rtcp-mux is negotiated. So the offerer can tell when the answerer
>     doesn't support it. In that case it can take remedial action. There
>     may be some stray rtcp packets until that happens. So
>     a=rtcp-mux-only isn't really *needed*. What it does is prevent those
>     few stray packets.
>
>     But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because
>     it doesn't solve cases when the offerer wants separate rtcp, but not
>     on port+1, and the answerer doesn't support that.
>
>     Perhaps the right solution is to introduce a new attribute to
>     *replace* a=rtcp. It would have similar semantics, but require
>     negotiation. It could in principle also replace a=rtcp-mux, since if
>     you use the same address/port for both rtp and rtcp you are
>     obviously requesting mux. You could still use a=rtcp and/or
>     a=rtcp-mux for backward compatibility, but if you need rtcp-mux-only
>     semantics, then you could just use this new attribute. If it isn't
>     ack'ed, then take remedial action.
>
>     This new attribute would have same syntax as a=rtcp, except for the
>     name. New rules for it would be:
>
>     - if in offer, must also be in answer. The answer gives the port(/addr)
>        for the answerer. If the answerer wants port+1 it needs to compute
>        what that is and put it in.
>     - if it is *not* in the offer, it can't be used in the answer. If the
>        answerer can't do rtcp on port+1 then it needs to refuse the media
>        stream. It could try sending a subsequent offer for what it can do.
>
>     - we *could* explicitly allow the port to be set to zero, and/or the
>        address to be set to 0.0.0.0, to indicate that rtcp is not desired.
>        (Don't know if it is a good idea.)
>
>              Thanks,
>              Paul
>
>