Subject: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt

From: Flemming Andreasen <[email-masked]>
Date: Thu, 18 Feb 2016 16:47:20 -0500

Greetings MMUSIC

This is to announce a 2 week WGLC on the  draft:

      https://www.ietf.org/id/draft-ietf-mmusic-mux-exclusive-03.txt

as Proposed Standard. Please review and provide any comments you may 
have on the document by Thursday, March 3, 2016. Comments should be sent 
to the document authors and the MMUSIC WG list. If you review the 
document but do not have any comments, please send a note to that effect 
as well.

Thanks

-- Flemming (MMUSIC co-chair)

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Feb 2016 22:01:11 +1100

>      https://www.ietf.org/id/draft-ietf-mmusic-mux-exclusive-03.txt

I've read it, but I've not followed the list discussion much.

This document needs to more clearly articulate the reason for the
attribute.  An implementation that fails to generate unique RTCP port
numbers (on a=rtcp or a=candidate lines) AND checks for a=rtcp-mux
attributes will produce the same effect as with this attribute.

Can we mandate either mandatory inclusion of a=rtcp with matching
transport parameters, or mandatory omission of a=rtcp?  If there is a
reason to allow this choice, it might be wise to document it.  Since
we're exclusive, I see no reason to waste bytes and cycles on a=rtcp;
I'd prefer to have it omitted.  We're highly unlikely to be compatible
with anyone expecting to rely on a=rtcp in any case.

Editorial:

Rather than:

   The RTCWEB WG has defined that support of the fallback mentioned
   above is optional.  Therefore, there is a need for a mechanism that
   allows an endpoint to indicate exclusive support of RTP/RTCP
   multiplexing, meaning that endpoint only supports RTP/RTCP
   multiplexing and is not able to fallback to usage of separate ports
   for RTP and RTCP.

Say:

   Some newer applications that do not require backward compatibility
with peers that cannot multiplex RTCP might choose to not implement
separation of RTP and RTCP.  For those applications, this document
defines an SDP attribute to signal intent to require multiplexing.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Feb 2016 08:12:03 +0000

Hi Martin,

Thanks for your comments! See inline.

> This document needs to more clearly articulate the reason for the attribute.  An implementation that fails to generate 
> unique RTCP port numbers (on a=rtcp or a=candidate lines) AND checks for a=rtcp-mux attributes will produce the same effect as with this attribute.

Perhaps, but there are at least a couple of semantical issues with that:

FIRST, section 5.1.3 of RFC 5761 says:

   "If it is desired to use both ICE and multiplexed RTP and RTCP, the
   initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
   RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
   lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
   fallback port for RTCP in the case that the answerer does not support
   RTP and RTCP multiplexing.  This MUST be done for each media where
   RTP and RTCP multiplexing is desired."

SECOND, draft-ietf-mmusic-ice-sip-sdp mandates it. Now, that if obviously something we can change, but my understanding was that people didn't want to update 5761.

THIRD, if ICE is not used to begin with, there will be no candidates, so a=rtcp-mux will obviously not produce the same result :)

> Can we mandate either mandatory inclusion of a=rtcp with matching transport parameters, or mandatory omission of a=rtcp?  If 
> there is a reason to allow this choice, it might be wise to document it.  Since we're exclusive, I see no reason to waste bytes and 
> cycles on a=rtcp; I'd prefer to have it omitted.  We're highly unlikely to be compatible with anyone expecting to rely on a=rtcp in any case.

The only reason is if the mux-exclusive mechanism is used together with some other mechanism that requires usage of a=rtcp. As mentioned earlier, draft-ietf-mmusic-ice-sip-sdp currently requires usage of a=rtcp with RTCP.

We could of course say that one must not include a=rtcp, unless used together with a mechanism that requires it, and then we stop defining future mechanisms that use a=rtcp.

-------------------

>   Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose to not 
>   implement separation of RTP and RTCP.  For those applications, this document defines an SDP attribute to signal intent to require multiplexing.

Looks good.

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Feb 2016 08:36:02 +0000

FOURTH, and perhaps this is more theoretical, if you use trickle then a=rtcp-mux does not indicate whether RTCP candidates will come later or not.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 29. helmikuuta 2016 10:12
To: Martin Thomson; Flemming Andreasen
Cc: mmusic; [email-masked]
Subject: RE: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt

Hi Martin,

> attribute.  An implementation that fails to generate unique RTCP port numbers (on a=rtcp or a=candidate lines) AND checks for a=rtcp-mux attributes will produce the same effect as with this attribute.

> reason to allow this choice, it might be wise to document it.  Since we're exclusive, I see no reason to waste bytes and cycles on a=rtcp; I'd prefer to have it omitted.  We're highly unlikely to be compatible with anyone expecting to rely on a=rtcp in any case.

-------------------

Looks good.

Thanks!

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Mar 2016 12:03:43 +1100

>    RTP and RTCP multiplexing is desired."

If you think that you can do this without updating RFC 5761, I'm
surprised.  RFC 5761 envisages a world where mux-exclusive is an
impossibility; clearly this is no longer the case.

You describe a cage that we built for ourselves.  We are perfectly
able to use the same power that built that cage to dismantle it.  In
the end, it's just words.

> SECOND, draft-ietf-mmusic-ice-sip-sdp mandates it. Now, that if obviously something we can change, but my understanding was that people didn't want to update 5761.

Fixing ice-sip-sdp seems reasonable.  Since the patient is still on
the table, we have some time to retrieve the missing forceps.

> THIRD, if ICE is not used to begin with, there will be no candidates, so a=rtcp-mux will obviously not produce the same result :)

By which you mean you get RTP_port+1 for RTCP?  This isn't strong
motivation, since you will tear down a session immediately after
discovering that they don't want mux and don't understand
mux-exclusive.

> FOURTH, and perhaps this is more theoretical, if you use trickle then a=rtcp-mux does not indicate whether RTCP candidates will come later or not.

Yes, this is the one that I thought of.  This is actually the best
motivation to my mind, though again somewhat weak.  Again, you only
have a problem with a peer that doesn't want mux AND doesn't
understand this spec.

> We could of course say that one must not include a=rtcp, unless used together with a mechanism that requires it, and then we stop defining future mechanisms that use a=rtcp.

I think that would be a fine thing to do.  Again, since ice-sip-sdp is
still in the working group, we should fix that while we are at it (add
an exclusion for exclusive).

Note that again, this is a box of our own design, we can decide to
update those documents here.  "The a=rtcp attribute MUST NOT be
included unless other documents (other than RFC 5761) mandate its
inclusion.  If present, a=rtcp MUST include a port number of 9."  Or
something along those lines.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Mar 2016 07:52:12 +0000

Hi,

> If you think that you can do this without updating RFC 5761, I'm surprised.  RFC 5761 envisages a world where mux-exclusive is an impossibility; clearly this is no longer the case.
>
> You describe a cage that we built for ourselves.  We are perfectly able to use the same power that built that cage to dismantle it.  In the end, it's just words.

We agreed earlier to not update existing mechanisms. I think we should keep 5761 it as it is, for backward compatibility, because there are deployments that use it.

> Fixing ice-sip-sdp seems reasonable.  Since the patient is still on the table, we have some time to retrieve the missing forceps.

Agree. 

>> THIRD, if ICE is not used to begin with, there will be no candidates, 
>> so a=rtcp-mux will obviously not produce the same result :)
>
> By which you mean you get RTP_port+1 for RTCP?  This isn't strong motivation, since you will tear down a session immediately after discovering that they don't want mux and don't understand mux-exclusive.

People did not want a solution where one starts sending stuff and then realize it doesn't work.

Also, intermediaries will may still reserve resources for RTCP, as they don't know whether it will be used or not.

> Yes, this is the one that I thought of.  This is actually the best motivation to my mind, though again somewhat weak.  Again, you only have a problem with a peer that doesn't want mux AND doesn't understand this spec.

I think you would have problem with any peer, because they don't know if the RTCP candidate will come later (in case of trickle) or if it won't come at all (in case of exclusive-mux).

> I think that would be a fine thing to do.  Again, since ice-sip-sdp is still in the working group, we should fix that while we are at it (add an exclusion for exclusive).

Agree. That we should do no matter how we indicate mux-exclusive.

> Note that again, this is a box of our own design, we can decide to update those documents here.  "The a=rtcp attribute MUST NOT be included 
>unless other documents (other than RFC 5761) mandate its inclusion.  If present, a=rtcp MUST include a port number of 9."  Or something along those lines.

Sure, I can add text like that to the draft, and we can update ice-sip-sdp.

But, again, it was earlier agreed to not update existing mechanisms (RFC 5761 etc), and I really would not like to change that decision at this point. The new attribute provides an explicit indicator, and is not dependent on ice candidates etc. Also, it's just an SDP attribute, so it's not a major thing to implement.

Regards,

Christer