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

"Black, David" <> Thu, 12 June 2014 15:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 57CA71B2AA4 for <>; Thu, 12 Jun 2014 08:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.152
X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o5hOyJ7ZlbJB for <>; Thu, 12 Jun 2014 08:57:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E4D01B2A70 for <>; Thu, 12 Jun 2014 08:57:46 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5CFvdAi006504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 11:57:43 -0400
X-DKIM: OpenDKIM Filter v2.4.3 s5CFvdAi006504
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1402588663; bh=WuV0oqAR9zIdA5Sme8cVejvw49Q=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=U/ljZHQ0e5dyIaUe1vN4XWhwnOHB9sqlDmLTXE4zSAOaN/7+gLUldzMSo0pkF8Rul XJigpKHN45GkB3Ha8fefJUIO0HKpixholsssfmDX0dH9Ap6HCEeM+4pv8kHIQtyPsC 5+FmQarx/fHyc7blaejTEyvQ+XWAxeqXRijpYWUg=
X-DKIM: OpenDKIM Filter v2.4.3 s5CFvdAi006504
Received: from ( []) by (RSA Interceptor); Thu, 12 Jun 2014 08:57:21 -0700
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5CFvHvw020136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 11:57:20 -0400
Received: from ([]) by ([]) with mapi; Thu, 12 Jun 2014 11:57:17 -0400
From: "Black, David" <>
To: Harald Alvestrand <>, Ben Campbell <>
Date: Thu, 12 Jun 2014 11:57:16 -0400
Thread-Topic: [Dart] Commentary on draft-york-00
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Classifications: public
Cc: "" <>
Subject: Re: [Dart] Commentary on draft-york-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jun 2014 15:57:49 -0000


This explanation helps (thank you):

> 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.

[... snip ...]

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

I believe that the westerlund-avtcore draft was the indirect source of
draft-york's assertion that multiple RTP sessions could be mixed on a
single 5-tuple.  In correcting that statement to say that RTP sessions
cannot be mixed on a UDP 5-tuple, would it be reasonable to make note
of that expired draft's proposal, possibly via a reference to the
avtext-taxonomy draft?


> -----Original Message-----
> From: Dart [] On Behalf Of Harald Alvestrand
> Sent: Thursday, June 12, 2014 10:39 AM
> To: Ben Campbell
> Cc:
> Subject: Re: [Dart] Commentary on draft-york-00
> 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 <> 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.
> _______________________________________________
> Dart mailing list