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

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Nov 2015 06:03:01 +0000

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: [email-masked] [mailto:[email-masked]] 
Sent: 05 November 2015 07:56
To: Christer Holmberg <[email-masked]>
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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Nov 2015 15:24:34 +0900

n.b., The name is missing a 'c'.

On 5 November 2015 at 15:03, Christer Holmberg
<[email-masked]> wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Nov 2015 06:29:52 +0000

That will be fixed in draft-ietf-mmusic-00 :)

Thanks!

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 05 November 2015 08:25
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

On 5 November 2015 at 15:03, Christer Holmberg <[email-masked]> wrote:
> Subject: New Version Notification for 
> draft-holmberg-mmusic-mux-exlusive-00.txt
>
>

---

From: "Wyss, Felix" <[email-masked]>
Date: Thu, 5 Nov 2015 11:55:11 +0000

Hi Christer,

Thank you for writing the draft.  The way the NEW TEXT is written implies that the example following the text shows that the offerer is using "a=rtcp" to signal mux-only.   However, the sample in RFC#5761-5.1.1 does not include an "a=rtcp" attribute.  I wonder whether it would be better to include a new paragraph after the second paragraph in that section ("This offer denotes a unicast...") that discusses the RTP/RTCP mux-only offer and provides an SDP example with the "a=rtcp" attribute.

--Felix

> From: mmusic [mailto:[email-masked]] On Behalf Of Christer
> Holmberg
> Sent: Thursday, November 05, 2015 01:03
> To: [email-masked]
> Subject: [MMUSIC] FW: New Version Notification for draft-holmberg-
> mmusic-mux-exlusive-00.txt
> 
> 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
> 
> 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
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Nov 2015 13:24:17 +0000

Hi Felix,

Thanks for your comments!

I agree with you, we most likely will need more "new text" - to cover the example, and the open issues.

But, at this point I think the main question is whether people agree with the principle in general.

Regards,

Christer

-----Original Message-----
From: Wyss, Felix [mailto:[email-masked]] 
Sent: 05 November 2015 13:55
To: Christer Holmberg <[email-masked]>; [email-masked]
Subject: RE: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

Hi Christer,

--Felix

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

---

From: "Wyss, Felix" <[email-masked]>
Date: Thu, 5 Nov 2015 14:48:14 +0000

Just to be on the record in case it wasn't clear from my post last month: I wholeheartedly support this!  Anything that promotes RTP/RTCP multiplexing is a good thing.  To me, RTCP on a different port is an unfortunate anachronism that can't die fast enough.

--Felix

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, November 05, 2015 08:24
> To: Wyss, Felix <[email-masked]>; [email-masked]
> Thank you for writing the draft.  The way the NEW TEXT is written implies
> that the example following the text shows that the offerer is using
> "a=rtcp" to signal mux-only.   However, the sample in RFC#5761-5.1.1 does
> not include an "a=rtcp" attribute.  I wonder whether it would be better to
> include a new paragraph after the second paragraph in that section ("This
> offer denotes a unicast...") that discusses the RTP/RTCP mux-only offer
> and provides an SDP example with the "a=rtcp" attribute.
> 
> --Felix
> 
> > Title:		Indicating Exclusive Support of RTP/RTCP Multiplexing
> using
> > SDP
> > 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/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Nov 2015 10:31:25 -0500

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Nov 2015 20:21:57 +0000

Hi Paul,

Thanks for the comments!

I really doubt that mux-only entities (e.g. browsers) want to do 2 O/A transactions just because of this.

And, doesn't an offerer using the rtcp attribute already today have to make sure  that receiving RTCP on "port+1" won't do harm, in case the answerer doesn't support the attribute? In NAT cases, I guess the RTCP wouldn't even reach the offerer.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎06/‎11/‎2015 00:34
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

Christer,

        Thanks,
        Paul

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Nov 2015 17:18:32 -0500

> transactions just because of this.

I agree that they won't *want* to!

> And, doesn't an offerer using the rtcp attribute already today have to
> make sure  that receiving RTCP on "port+1" won't do harm, in case the
> answerer doesn't support the attribute?

Yes, they should.

> In NAT cases, I guess the RTCP
> wouldn't even reach the offerer.

Maybe not. But it still may reach *someone*. Do you want your offer 
resulting in somebody else being spammed?

I recognize that this is not an ideal solution. I just don't see a 
better one.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Subject: Re: [MMUSIC] FW: New Version Notification for
>> 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:

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Nov 2015 01:10:50 +0000

Hi Paul,

I agree the solution is not ideal, but the problem is not this draft - it is the rtcp attribute in general.

And, as non-mux is now optional in JSEP/WebRTC, having no way of indicating it in SDP would be a much worse solution.

(For SIP, we could of course also define an option-tag, to ensure that the remote peer supports a feature, but that would be a separate task)

And, if you don't agree with the RTCWEB decision to begin with, that discussion belongs to RTCWEB :)

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎06/‎11/‎2015 07:18
To: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

Yes, they should.

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Nov 2015 20:34:17 -0500

> it is the rtcp attribute in general.

Yes. But the attribute can't be fixed. The best we can do is be careful 
if/how it is used.

> And, as non-mux is now optional in JSEP/WebRTC, having no way of
> indicating it in SDP would be a much worse solution.

The bottom line is: what do you expect should happen in the case that 
the answerer doesn't support either a=rtcp or a=rtcp-mux?

> (For SIP, we could of course also define an option-tag, to ensure that
> the remote peer supports a feature, but that would be a separate task)
>

As long as people understand the consequences of the decision I am ok 
with it.

I don't think it is appropriate to say: if the answerer doesn't support 
either rtcp or rtcp-mux then things just break in a bad way, by spamming 
somebody else with your rtcp.

	Thanks,
	Paul

> To: Christer Holmberg <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>

---

From: "Wyss, Felix" <[email-masked]>
Date: Fri, 6 Nov 2015 03:11:13 +0000

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

> From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, November 05, 2015 10:31
> To: [email-masked]
> 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.
> 
> I realize this isn't very appealing, but it is a consequence of having not made
> rtcp-mux the default.
> 
> > 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.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Nov 2015 22:50:51 -0500

Felix,

You miss my point. The problem is that the clueless answerer *is* 
sending rtcp *somewhere* (to port+1). Certainly the offerer can 
understand what has happened. And it can cope with not getting rtcp. But 
*somebody* probably has that port allocated for something. In the case 
of a NAT, the NAT has probably allocated it to somebody else, or even to 
the same application but for some other local port. At the least, the 
recipient of that traffic will be bothered.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Nov 2015 23:40:50 -0500

Another solution is to require ICE. It is already requirement for
WebRTC.  Unless ICE check completes for an address/port, nothing will be
sent there.

Furthermore, end point can put IP4 0.0.0.0 in c= line and and not specify
the candidates for RTCP components. If not RTCP components are specified
and rtcp-mux is not used, there is not going to be a destination to send
RTCP. Alternatively offerer can specify the same IP and port in candidates
for both RTP and RTCP components. Offerer should already select safe
payload types for rtcp-mux and answerer will send both RTP and RTCP packets
to the same port.

SDP rtcp attribute is broken since there is no way to determine if it was
understood by the remote party. It would be better if it was retired
instead of finding new ways to use it.

Finally any deployments on open networks which do not require consent to
send data are dangerous and should be discouraged. So, I strongly suggest
that anything new should be built around ICE. This is why ICE is required
for WebRTC. Anything else is already built assuming some sort of
pre-negotiation is already in place and it is typically already known if
remote party supports rtcp-mux or rtcp attribute.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Nov 2015 07:31:12 +0000

Hi.

One option could perhaps be to use ICE if supported, but the rtcp attribute, with it's shortcomings, would be a fallback mechanism.

Because, the more mandatory dependencies we add, the more difficult it will be to deploy (mandating ICE for mux would also indirectly mandate ICE for BUNDLE) and I am pretty sure non-mux is something that also non-WebRTC folks want.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎06/‎11/‎2015 12:40
To: Paul Kyzivat<mailto:[email-masked]>; Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

Another solution is to require ICE. It is already requirement for WebRTC.  Unless ICE check completes for an address/port, nothing will be sent there.

Furthermore, end point can put IP4 0.0.0.0 in c= line and and not specify the candidates for RTCP components. If not RTCP components are specified and rtcp-mux is not used, there is not going to be a destination to send RTCP. Alternatively offerer can specify the same IP and port in candidates for both RTP and RTCP components. Offerer should already select safe payload types for rtcp-mux and answerer will send both RTP and RTCP packets to the same port.

SDP rtcp attribute is broken since there is no way to determine if it was understood by the remote party. It would be better if it was retired instead of finding new ways to use it.

Finally any deployments on open networks which do not require consent to send data are dangerous and should be discouraged. So, I strongly suggest that anything new should be built around ICE. This is why ICE is required for WebRTC. Anything else is already built assuming some sort of pre-negotiation is already in place and it is typically already known if remote party supports rtcp-mux or rtcp attribute.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 6 Nov 2015 17:04:11 -0500

On Fri, Nov 6, 2015 at 2:31 AM, Christer Holmberg <
[email-masked]> wrote:

> One option could perhaps be to use ICE if supported, but the rtcp
> attribute, with it's shortcomings, would be a fallback mechanism.
>
> Because, the more mandatory dependencies we add, the more difficult it
> will be to deploy (mandating ICE for mux would also indirectly mandate ICE
> for BUNDLE) and I am pretty sure non-mux is something that also non-WebRTC
> folks want.
>
>
I would be fine if draft described the ICE only solution together with no
ICE or ICE with fallback for legacy solution. This way we do not mandate
mechanisms that are completely unnecessary in the modern networks, such as
WebRTC.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Nov 2015 22:14:48 +0000

Hi,

>> Because, the more mandatory dependencies we add, the more difficult it will be to deploy (mandating ICE for mux 
>> would also indirectly mandate ICE for BUNDLE) and I am pretty sure non-mux is something that also non-WebRTC folks want.
>
> I would be fine if draft described the ICE only solution together with no ICE or ICE with fallback for legacy solution. This 
> way we do not mandate mechanisms that are completely unnecessary in the modern networks, such as WebRTC.

However, when the offerer sends the initial offer, it doesn't know whether the answerer supports ICE, so I think it would need to include the rtcp attribute in the offer just in case.

The second question is whether the mux-exclusive should define the ICE mechanism. Couldn't we in the ICE spec simply say that if an endpoint only supports mux then it only includes RTP candidates (component ID value 1). Then, in the mux-exclusive draft we would only say something like:

	"As defined in ICE, if an endpoint only supports RTP/RTCP mux, the endpoint will only include RTP candidates in the offer".

In the ICE WG, we have drafted text saying that an offerer can include only RTP candidates if it knows that the remote endpoint supports RTP/RTCP mux. We could simply extend that text, and include the case where the endpoint only supports RTP/RTCP mux.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 13 Nov 2015 18:09:24 -0500

On Fri, Nov 13, 2015 at 5:14 PM, Christer Holmberg <
[email-masked]> wrote:

> However, when the offerer sends the initial offer, it doesn't know whether
> the answerer supports ICE, so I think it would need to include the rtcp
> attribute in the offer just in case.
>

It can, however send an offer which will only work if remote side supports
ICE, i.e. put c=0.0.0.0 line and put actual IP addresses in candidates
only. What I do not want, is require support for rtcp attribute if end
point never intends to work without ICE.

> The second question is whether the mux-exclusive should define the ICE
> mechanism. Couldn't we in the ICE spec simply say that if an endpoint only
> supports mux then it only includes RTP candidates (component ID value 1).
> Then, in the mux-exclusive draft we would only say something like:
>
>         "As defined in ICE, if an endpoint only supports RTP/RTCP mux, the
> endpoint will only include RTP candidates in the offer".
>
> In the ICE WG, we have drafted text saying that an offerer can include
> only RTP candidates if it knows that the remote endpoint supports RTP/RTCP
> mux. We could simply extend that text, and include the case where the
> endpoint only supports RTP/RTCP mux.
>

This would be fine with me, as long as, rtcp attribute would not be
required when ICE is used and no legacy interop is expected.

So, if legacy interop is required, rtcp attribute set to the same value as
c= line address and m= line port would indicate rtcp-mux only. If ICE is
used without legacy interop, endpoint will only include RTP candidates and
no rtcp attribute.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Nov 2015 08:07:18 +0000

Hi,

>It can, however send an offer which will only work if remote side supports ICE, i.e. put c=0.0.0.0 line and put actual IP addresses in 
>candidates only. What I do not want, is require support for rtcp attribute if end point never intends to work without ICE.
 
Is the usage of c=0.0.0.0 for basic ICE something we have actually agreed upon and documented?

>>The second question is whether the mux-exclusive should define the ICE mechanism. Couldn't we in the ICE spec simply 
>>say that if an endpoint only supports mux then it only includes RTP candidates (component ID value 1). Then, in 
>>the mux-exclusive draft we would only say something like:
>>
>>In the ICE WG, we have drafted text saying that an offerer can include only RTP candidates if it knows that the remote endpoint 
>>supports RTP/RTCP mux. We could simply extend that text, and include 
>>the case where the endpoint only supports RTP/RTCP mux.
>
>This would be fine with me, as long as, rtcp attribute would not be required when ICE is used and no legacy interop is expected.

But, does it hurt to include it? If the answerer supports ICE, it could simply ignore it.

>So, if legacy interop is required, rtcp attribute set to the same value as c= line address and m= line port would
> indicate rtcp-mux only.

Keep in mind that the rtcp attribute does not contain an address, only port.

>If ICE is used without legacy interop, endpoint will only include RTP candidates and no rtcp attribute.

See above.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 Nov 2015 12:31:20 -0500

> Keep in mind that the rtcp attribute does not contain an address, only port.

We only give examples like that, but if you look at RFC3605 you will see 
that an address may optionally be included as well.

(I was surprised to discover this.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Nov 2015 19:48:30 +0000

You are right, Paul. Thanks!

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎14/‎11/‎2015 09:31
To: Christer Holmberg<mailto:[email-masked]>; Roman Shpount<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

        Thanks,
        Paul