Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

As the offerer is the one who wants RTP/RTCP mux and might have to deal with legacy endpoints, it has two simple options of dealing with this: 
 1) Avoid allocating the RTP+1 port and/or leave it unused
 2) Not worry about it and rely on the spurious RTCP packets arriving on the wrong port being discarded by the RTP stack because they 
   a) don't match the SSRC (and one would have to be really unlucky to get an SSRC collisions),
   b) would come from a different peer address/port than the legitimate stream, and
   c) if SRTP is used would fail authentication

The offerer thus does not have to re-invite if it sees that the answerer neither understands "a=rtcp-mux" nor "a=rtcp".  It won't get the RTCP packets for that stream, but that's no different than legacy equipment that doesn't even support RTCP--and that's not uncommon.  Now, it probably MUST NOT send RTCP in that case to avoid confusing the legacy equipment with RTCP packets on the RTP port.

So IMHO Christer's proposal is an elegant way of keeping the implementation of new equipment simpler (i.e. not having to support a separate RTCP port) while maintaining sufficient interoperability with legacy equipment. 

Thanks,
--Felix

> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Thursday, November 05, 2015 10:31
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-
> mmusic-mux-exlusive-00.txt
> 
> Christer,
> 
> While I appreciate the effort, I don't see how this solves the problem.
> Instead, it just moves it.
> 
> If the answerer doesn't support a=rtcp-mux, then what makes us think that
> he will support a=rtcp?
> 
> Since the offerer can't even depend on that, to be safe he really needs to
> allocate port+1, or at least ensure that rtcp sent to that port won't do harm.
> This was an intrinsic flaw in RFC3605.
> 
> The only reliable solution I can think of, if you can't support rtcp on
> port+1, is to initially offer the media with c=0, and with a=rtcp-mux.
> Then, if you get a=rtcp-mux back, you can reoffer with a valid address.
> If you don't get a=rtcp-mux back, then you just can't use the media.
> 
> I realize this isn't very appealing, but it is a consequence of having not made
> rtcp-mux the default.
> 
> Your proposal may increase the *odds* of success, but it is no guarantee.
> 
> 	Thanks,
> 	Paul
> 
> 	Thanks,
> 	Paul
> 
> On 11/5/15 1:03 AM, Christer Holmberg wrote:
> > Hi,
> >
> > I've submitted a draft which defines how the SDP rtcp-mux and rtcp
> attributes can be used to indicate exclusive support of RTP/RTCP mux (i.e.
> when the endpoint does not support non-mux). It is based on the suggestion
> I posted a few days ago.
> >
> > RTCWEB have decided that support of non-mux is optional, so there needs
> to be a way in SDP to indicate that. My suggestion is to, instead of only
> defining something JSEP-specific, specify a generic SDP mechanism. The draft
> suggests such mechanism.
> >
> > If we agree this is the right approach, the draft would become a
> dependency on rtcweb-jsep and mmusic-bundle, so I hope we can make a
> decision on whether to move forward (and WG adopt the draft) as soon as
> possible.
> >
> > Thanks!
> >
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: 05 November 2015 07:56
> > To: Christer Holmberg <christer.holmberg@ericsson.com>
> > Subject: New Version Notification for
> > draft-holmberg-mmusic-mux-exlusive-00.txt
> >
> >
> > A new version of I-D, draft-holmberg-mmusic-mux-exlusive-00.txt
> > has been successfully submitted by Christer Holmberg and posted to the
> IETF repository.
> >
> > Name:		draft-holmberg-mmusic-mux-exlusive
> > Revision:	00
> > Title:		Indicating Exclusive Support of RTP/RTCP Multiplexing using
> SDP
> > Document date:	2015-11-04
> > Group:		Individual Submission
> > Pages:		5
> > URL:            https://www.ietf.org/internet-drafts/draft-holmberg-mmusic-
> mux-exlusive-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-holmberg-mmusic-mux-
> exlusive/
> > Htmlized:       https://tools.ietf.org/html/draft-holmberg-mmusic-mux-
> exlusive-00
> >
> >
> > Abstract:
> >     This document defines how an endpoint can indicate exclusive support
> >     of RTP/RTCP multiplexing using the Session Description Protocol
> >     (SDP).
> >
> >     The document updates RFC 5761, by defining how the SDP 'rtcp'
> >     attribute is used, together with the SDP 'rtcp-mux' attribute, to
> >     indicate exclusive support of RTP/RTCP multiplexing.
> >
> >     Editor's note: 'exclusive' is probably not the best terminology, so
> >     feel free to suggest something more appropriate.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic