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

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 1 Mar 2016 06:23:50 -0800

On Mon, Feb 29, 2016 at 11:52 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >> 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."
> >
> > 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.
>
> >> 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.
>
> 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.
>
> >> 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.
>
> 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).
>
> >> 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).
>
> 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.
>
>
[Suhas] .. What are the specific updates for ice-sip-sdp. Sorry if i have
missed the context. I am happy to consider the inputs for these updates if
I get to know the concrete updates.

> 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
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 13:10:36 +1100

On 1 March 2016 at 18:52, Christer Holmberg
<[email-masked]> wrote:
> 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.

5761 creates a bind: it expressly prohibits the thing that this draft
sets out to do.  I don't see any harm in updating it, it's not like it
will suddenly affect 5761 implementations that rely on backwards
compatibility.

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

This *IS* that solution.  An answerer that doesn't understand this new
attribute and doesn't want to multiplex will send stuff to the wrong
place if we omit a=rtcp.  Nothing to be done about that other than
what is already in the draft.

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

That is also a good argument for the attribute.  That sounds like a
good thing to add to the draft.

> 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.

I apologize if I'm going back on established consensus, but I think
that is a mistake.  The magnitude of the update is small.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Mar 2016 08:45:47 +0000

Hi,

> 5761 creates a bind: it expressly prohibits the thing that this draft sets out to do.  I don't see any harm in updating it, it's not like 
> it will suddenly affect 5761 implementations that rely on backwards compatibility.
> requirement.
>
> This *IS* that solution.  An answerer that doesn't understand this new attribute and doesn't want to multiplex will send stuff to the wrong place
> if we omit a=rtcp.  Nothing to be done about that other than what is already in the draft.

That is true, but at least we would have a mechanism (that also works without ICE, and with trickle ICE) to indicate that you can only do mux. Then it's up to people to implement it.

Also, previously I did suggest using a=rtcp:9 0.0.0.0 with mux-exclusive, for preventing endpoints that don't support mux-exclusive (but do support a=rtcp) from sending RTCP to the wrong place.

> That is also a good argument for the attribute.  That sounds like a good thing to add to the draft.

I can that. 

> I apologize if I'm going back on established consensus, but I think that is a mistake.  The magnitude of the update is small.

So, what exactly do you want to update?

You don't want to use the new attribute, but rather update 5761 in  a way so that a=rtcp-mux can be used to indicate mux-exclusive?

OR, you are ok using the new attribute (you seemed to agree that the intermediary was a valid case for a new attribute), but you want some 5761 update in addition to that?

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 10 Mar 2016 11:42:18 -0500

The WGLC on this document has ended and based on the (still ongoing) 
discussions, the document is clearly not ready to move forward.

Thanks for all the comments received so far and please continue the 
discussion.

-- Flemming (as MMUSIC co-chair)

On 2/18/16 4:47 PM, Flemming Andreasen wrote:
> 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)
>
> .