Re: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example

[Paul Kyzivat <[e-mail]>]

On 4/29/13 2:13 PM, Martin Thomson wrote:
> On 29 April 2013 10:05, Paul Kyzivat <[e-mail]> wrote:
>> On 4/29/13 10:41 AM, Christer Holmberg wrote:
>>> In your example there is only one SCTP m- line, and in WebRTC I guess it
>>> will also be the case, but SDP doesn't prevent you from using multiple SCTP
>>> m- lines - unless BUNDLE explicitly forbids it, that is.
>>
>> I agree. If we want to support that, then the obvious way (for DTLS/SCTP) is
>> via SCTP port. That depends on there being a way to specify the SCTP with
>> DTLS/SCTP. That has come and gone from the SDP proposal for SCTP.
>
> I don't care whether SDP supports it or not, I care whether it makes
> sense to do it at all.
>
> There's a reason why you might not want to mux SCTP - it's a protocol
> with multiplexing support.  Multiplexing outside of it is at best a
> crude thing to do and at worst a way to dilute congestion signals.
>
> I can understand how you can conceive of scenarios where different
> application layer protocols don't play well together enough that you
> want more aggressive separation.  I don't see significant value in
> supporting those scenarios.
>
> That doesn't completely preclude the future use of SCTP port for
> demux, but it does constrain complexity.

I agree with you that there doesn't seem to be any obvious need for 
this, at least not now. I don't think we need to expend effort 
specifying how to do this sort of multiplexing now. For example, it may 
be sufficient to register a default sctp port for data channel over 
sctp, and assume that any other uses of DTLS/SCTP will either have to 
register their own default port or else specify a way of explicitly 
signaling the port.

My point was only to indicate another reason to design in a flexible 
mechanism for signaling the multiplexing mechanism(s).

	Thanks,
	Paul