Re: [Dart] Commentary on draft-york-00

[Harald Alvestrand <[e-mail]>]

On 06/12/2014 04:25 PM, Ben Campbell wrote:
> Thanks Harald! I want to hit one particular comment:
>
> On Jun 12, 2014, at 7:49 AM, Harald Alvestrand <[e-mail]> wrote:
>
> [...]
>
>> "SCTP ... can be multiplexed with one or more RTP sessions". Actually we can only multiplex SCTP with a single RTP session. There have been proposals that would allow multiplexing of multiple RTP sessions (each containing multiple media flows) over a single 5-tuple, but these were not accepted.
>>
>>
> [...]
>
>> In bullet 2, only one RTP session can be multiplexed with another transport protocol (again).
> [...]
>
> Is this a matter of proper definitions of "RTP Session" vs "Media Flow"? (i.e. properly naming the thing that can be multiplexed?) Or is there a technical misunderstanding?
>
> Ben.
The word "session" is one of the most horrible words in the vocabulary.....

RTP packet streams that are in the same RTP session can be multiplexed 
over the same 5-tuple.
RTP packet streams that are from different RTP sessions cannot.

A media flow as you've defined it here (="packet stream" from 
-taxonomy-) is identified by its SSRC.

About "RTP Session", -taxonomy- has this definition:

  2.2.2.  RTP Session

    An RTP session is an association among a group of participants
    communicating with RTP.  It is a group communications channel which
    can potentially carry a number of Packet Streams.  Within an RTP
    session, every participant can find meta-data and control information
    (over RTCP) about all the Packet Streams in the RTP session.  The
    bandwidth of the RTCP control channel is shared between all
    participants within an RTP Session.

    Alternate usages:

    o  Within the context of SDP, a singe m=line can map to a single RTP
       Session or multiple m=lines can map to a single RTP Session. The
       latter is enabled via multiplexing schemes such as BUNDLE
       [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which
       allows mapping of multiple m=lines to a single RTP Session.

    Characteristics:

    o  Typically, an RTP Session can carry one ore more Packet Streams.

    o  An RTP Session shares a single SSRC space as defined in RFC3550
       [RFC3550].  That is, the End Points participating in an RTP
       Session can see an SSRC identifier transmitted by any of the other
       End Points.  An End Point can receive an SSRC either as SSRC or as
       a Contributing source (CSRC) in RTP and RTCP packets, as defined
       by the endpoints' network interconnection topology.

    o  An RTP Session uses at least two Media Transports
       (Section 2.1.13), one for sending and one for receiving.
       Commonly, the receiving one is the reverse direction of the same
       one as used for sending.  An RTP Session may use many Media
       Transports and these define the session's network interconnection
       topology.  A single Media Transport can normally not transport
       more than one RTP Session, unless a solution for multiplexing
       multiple RTP sessions over a single Media Transport is used. One
       example of such a scheme is Multiple RTP Sessions on a Single
       Lower-Layer Transport
       [I-D.westerlund-avtcore-transport-multiplexing].

    o  Multiple RTP Sessions can be related.

About the possibility of putting multiple sessions on a single media 
transport, -taxonomy- says:

3.4.  Multiple RTP Sessions over one Media Transport

    [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism
    that allow several RTP Sessions to be carried over a single
    underlying Media Transport.  The main reasons for doing this are
    related to the impact of using one or more Media Transports. Thus
    using a common network path or potentially have different ones.
    There is reduced need for NAT/FW traversal resources and no need for
    flow based QoS.

    However, Multiple RTP Sessions over one Media Transport makes it
    clear that a single Media Transport 5-tuple is not sufficient to
    express which RTP Session context a particular Packet Stream exists
    in.  Complexities in the relationship between Media Transports and
    RTP Session already exist as one RTP Session contains multiple Media
    Transports, e.g. even a Peer-to-Peer RTP Session with RTP/RTCP
    Multiplexing requires two Media Transports, one in each direction.
    The relationship between Media Transports and RTP Sessions as well as
    additional levels of identifiers need to be considered in both
    signaling design and when defining terminology.

This is, in my opinion, a very longwinded way of saying "this doesn't 
exist".

The -westerlund- draft expired this April. I have not heard of anyone 
pursuing it.