Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex?

[Paul Kyzivat <[e-mail]>]

Commenting on one specific point...

On 1/11/13 12:51 AM, Dan Wing wrote:

>>> We need a way for SDP to signal:
>>>     1. the UDP port for SCTP.  This feels like an SDP media ("m") line
>> to me.
>>>     2. SCTP native (native SCTP over IPv6 should be tenable, whereas
>>> native SCTP over IPv4 is pretty much untenable),
>>>     3. the data carried over each SCTP port (e.g., port NNN for XMPP,
>>> port NNNN for file sharing, port NNNNN for screen sharing, and so on).
>>> This feels like an SDP media ("m") line to me.
>>
>> I don't disagree with any of your points, but you have missed the point
>> I was making.
>>
>> Everything you list applies for SCTP on its own 5-tuple. But then there
>> is the question of how to describe how this shares a 5-tuple with some
>> audio and video streams.
>
> (1), from my list, is the UDP port.  This could be the same UDP port
> as the audio/video media.

Yes. But SDP doesn't permit two m-lines with the same address and port. 
Bundle has been proposed to work around that. But currently bundle 
requires all the bundled m-lines to have the same <proto>. And that 
won't work for bundling SCTP and RTP.

The restriction to the same <proto> is dictated by the need for a way to 
demux. Bundle specifies rules for multiple RTP m-lines that ensures they 
can be demuxed. The demuxing of RTP from SCTP on the same UDP port uses 
a different mechanism. So for this to work bundle needs:

- more elaborate rules for what <proto> values may be bundled,
   and which may not

- explicit specification for the demuxing of each of the different
   m-lines that have been bundled.

This is not rocket science. Once you think about it a bit it is fairly 
evident which combinations work, and how to demux them. But it needs to 
be written down, directly or by reference.

	Thanks,
	Paul