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

[Paul Kyzivat <[e-mail]>]

On 11/5/15 8:10 PM, Christer Holmberg wrote:
> Hi Paul,
>
> I agree the solution is not ideal, but the problem is not this draft -
> 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)
>
> And, if you don't agree with the RTCWEB decision to begin with, that
> discussion belongs to RTCWEB :)

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

> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[e-mail]>
> Sent: ‎06/‎11/‎2015 07:18
> To: Christer Holmberg <mailto:[e-mail]>;
> [e-mail] <mailto:[e-mail]>
> Subject: Re: [MMUSIC] FW: New Version Notification for
> draft-holmberg-mmusic-mux-exlusive-00.txt
>
> On 11/5/15 3:21 PM, Christer Holmberg wrote:
>> 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.
>
> 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
>
>> Regards,
>>
>> Christer
>>
>> Sent from my Windows Phone
>> ------------------------------------------------------------------------
>> From: Paul Kyzivat <mailto:[e-mail]>
>> Sent: ‎06/‎11/‎2015 00:34
>> To: [e-mail] <mailto:[e-mail]>
>> 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: [e-mail] [mailto:[e-mail]]
>>> Sent: 05 November 2015 07:56
>>> To: Christer Holmberg <[e-mail]>
>>> 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
>>> [e-mail]
>>>https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>>https://www.ietf.org/mailman/listinfo/mmusic
>