Re: [MMUSIC] BUNDLE and DATA CHANNEL

[Paul Kyzivat <[e-mail]>]

On 4/25/13 10:19 AM, Christer Holmberg wrote:
> [Was: [MMUSIC] Comment on Payload type restriction in draft-ietf-mmusic-sdp-bundle-negotiation-03]
>
> Hi,
>
>> - the draft doesn't currently talk at all about including the
>>    m-line for the SCTP association for data channels in the bundle,
>>    but people expect it. There is a special mechanism for demuxing
>>    those packets from RTP. But that mechanism is limited to SCTP
>>    over DTLS. And it is limited to a single SCTP association in the
>>    bundle.
>
> That is for sure text that needs to be added - assuming we have a WG decision that we are going to do it. Or, does someone think we only need to care about RTP (as far as BUNDLE is concerned) at this point?
>
>> ISTM that there must be specification of:
>> - the demux mechanisms that are available,
>> - how they work,
>> - how they do or don't coexist with one another,
>> - and how they are signaled in SDP.
>>
>> The list of available demux mechanisms may need to be extensible.
>> And the bundle mechanism should be designed to accommodate that.
>
> Yes. Whenever someone wants to add a new transport to BUNDLE, he/she needs to describe how the multiplexing with other transports is done, i.e. fill out the bullet list above.
>
> BUT, does that mean that we need a signalling mechanism where a BUNDLE client inform which demux mechanisms it supports?
>
>          	Example: a=mux_transports: RTP, DTLS-SCTP
>
> In future, someone may specify how to add MSRP to BUNDLE, and how to mux it with DTLS-SCRTP and RTP:
>
> 	Example: a=mux_transports: RTP, DTLS-SCTP, MSRP

Yes - we need a way to signal the demux mechanism to be used.
(Unless there is only one possibility. And we have already disproved that.)

ISTM that there will need to be a spec (maybe just a small one) for each 
mechanism, that describes how it works and also how it is signaled.
How that is denoted isn't yet apparent to me. Its not even clear to me 
*where* in the SDP it needs to go. *Perhaps* it can be per-m-line, as 
long as there are clear rules for how the rules for different m-lines 
are coordinated in a bundle.

	Thanks,
	Paul