Re: [MMUSIC] BUNDLE: RTP only?

Dale,

I had assumed that the layering diagram looked as follows:

     SCTP
     DTLS    SRT(C)P       STUN
               UDP

This means that the demux problem becomes something like

- If packet is STUN, forward to ICE stack.
- If packet is SRT(C)P:
  + Primary demux on payload type
  + Secondary demux on SSRC
- If packet is DTLS
  + Demux SCTP associations by port number
    . SCTP streams are demuxed by stream ID

1. The first level of demux is described in RFC 5764 S 5.1.2.
2. The SRT(C)P demux appears to be specified in:
   http://tools.ietf.org/html/draft-ietf-avtcore-multi-media-rtp-session-01
3. SCTP over DTLS encapsulation (and the elevant muxing) appears to
   be specified in:
   http://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-dtls-encaps-01.txt
   and since the port is part of SCTP, this seems straightforward
   if we wish to allow it.

Obviously, one could, as you suggest, tunnel everything over SCTP,
but this seems like it would be less efficient in terms of bandwidth
(since you would add a bunch of headers to the RTP) and would also
be less compatible with existing SRTP endpoints.

Best,
-Ekr

On Fri, Feb 15, 2013 at 2:22 PM, Dale R. Worley <worley@ariadne.com> wrote:

> The problem is divisible into two parts.  One part is just clarifying
> what needs to be supported.  The second, harder part is specifying all
> the mechanisms.
>
> When multiplexing, we have to establish:
>
> 1. What is the nature of the constituent data streams that can be
>    multiplexed?
>
> 2. What method is used to multiplex the constituents?  Does there need
>    to be an encapsulation protocol?
>
> 3. What method is used to demultiplex the incoming PDUs of the
>    multiplexed data?
>
> 4. What carrier protocol is used to carry the multiplexed data?
>
> 5. How will we signal whatever information is needed to control the
>    demultiplexing process?  (This is affected by any need to
>    interoperate with existing systems.)
>
> 6. Where in the stack of protocols do we apply encryption, and what is
>    its nature?
>
> Items 1 and 3 are the ones that are most constrained by the
> requirements of the situation.
>
> As far as I can tell from what I've seen, the nature of the
> constituent data streams is:
>
> - the RTP or SRTP traffic arising from zero or more SDP media
>   descriptions (Here we assume that it is important when
>   demultiplexing RTP that it is important to identify the correct
>   constituent media description for each incoming RTP packet; that RTP
>   cannot be interpreted except in the context of the correct media
>   description.)
>
> - the corresponding RTCP or Secure RTCP traffic (assuming we want to
>   have RTP/RTCP multiplexing)
>
> - the data carried over a single SCTP connection (which includes a
>   number of SCTP streams), or possibly more than one SCTP connection
>   if that is to be supported (It is not clear if the multiplexing
>   process has access to the data in the individual SCTP streams, or
>   whether the constituent data stream is the packets generated by
>   SCTP's multiplexing process, or whether it must handle the packets
>   generated by DTLS encrypting the SCTP packets.)
>
> The carrier protocol seems to be assumed to be UDP supplemented by the
> STUN and ICE traffic needed to support a UDP association with the
> far-end.  However there may be value in using SCTP-over-DTLS-over-UDP
> as the carrier protocol.
>
> In regard to encryption, it would be more efficient to apply
> encryption only to the multiplexed data.  That suggests that the
> constituent data is unencrypted: RTP instead of SRTP, SCTP instead of
> DTLS/SCTP.
>
> There tends to be an assumption that the demultiplexing process is
> trivial, that all incoming PDUs can be identified and routed to their
> correct destinations without any additional encapsulation
> information.  We might be lucky enough that that is true, but it is
> not the common case.
>
> Dale
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>