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

[Suhas Nandakumar <[e-mail]>]

On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat <[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



> I think this ought to be viewed as an update to 3605.
>

[Suhas] Paul, why do you think it needs an update to RFC3605 ?


>
>         Thanks,
>         Paul
>
> Also  include a=rtcp attribute with*RTP port *as defined the
>> mux-exclusive draft todau.
>> That way even if the answerer who doesn't understand a=rtcp-mux-only,
>> will still send RTCP to RTP port (as needed for this use-case). The
>> answerer can do the same or include a=rtcp-mux based on its requirements
>>
>>
>> When ICE is in usage and the Offer want to support a=rtcp-mux-only, it
>> does the following
>> a) include a=rtcp-mux-only
>> b) include a=rtcp <rtp-port> <-- RTP port
>> c) include RTCP candidate with port information that matches RTP. No
>> need to do new turn allocation for RTCP either.
>>
>> If the answerer doesn't understand a=rtcp-mux-only, it will still
>> multiplex RTP and RTCP based on the candidate information.
>>
>>
>> Not sure if i missed all the corner scenarios. Please let me know your
>> thoughts
>>
>> Cheers
>> Suhas
>>
>>
>>
>> On Sat, Jan 23, 2016 at 8:59 AM, Roman Shpount <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg
>>     <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         > I always wondered what intermediary we are talking about which
>> is supposed to know where to forward media. If
>>         > we are talking about firewalls which dynamically open ports,
>> then, most of the time it has no access to signaling information
>>         > due to use of secure channels. If we are talking about
>> something that does something to the media and forwards it (rtp proxy
>>         > in combination with sip proxy), then we actually want such
>> proxy to support rtcp mux exclusive or fail the connection for
>>         > the same reason we want regular end points to fail during
>> connection setup -- to prevent RTCP from being sent to
>>         > unexpected destination.
>>
>>         If such proxy only forwards what it receives, it doesn't need to
>>         support mux-exclusive. It only forwards what it gets. However,
>>         if it sees an m- line with port 0, it may not forward anything.
>>
>>
>>     Can you give me an example of the product you are referring to? I
>>     was thinking about http://ag-projects.com/mediaproxy/ and
>>     http://www.rtpproxy.org/ which both generate RTCP.
>>
>>     We are dealing with trade of between not sending unexpected traffic
>>     and backwards compatibility. I do not think there is a way to
>>     prevent unexpected traffic and still work with all the legacy end
>>     points. I would argue that RTCP mux required is not backwards
>>     compatible change and should not work unless it is supported
>>     end-to-end. Only backwards compatibility required should be ability
>>     to detect end points that do not support rtcp mux and not to set the
>>     media session with them.
>>
>>     Regards,
>>     _____________
>>     Roman Shpount
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>