Re: [Dart] multiplexing different media types

Eric Rescorla <ekr@rtfm.com> Sun, 15 June 2014 15:41 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4926C1B287D for <dart@ietfa.amsl.com>; Sun, 15 Jun 2014 08:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR23YABTQ6DL for <dart@ietfa.amsl.com>; Sun, 15 Jun 2014 08:41:51 -0700 (PDT)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB771B287E for <dart@ietf.org>; Sun, 15 Jun 2014 08:41:50 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id q59so4556518wes.26 for <dart@ietf.org>; Sun, 15 Jun 2014 08:41:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W2rchFOq1+KofU6iY2jeyO+9JpkUfS9CBDQw0qecioU=; b=U6hQgk9RjqL3WTkJsRWlawVICFUPhD/pMJmf3o7yqNrVyRArmreC4zWQxJ68ca3YEq usQm+YDeXTFpmuPjCS20AOe51VC1F9i58UebWilMMR2n+xWWr/6IN0TLhISRU+xKMEUC 6Ume3VIOhLvv5uWwx72KoW9AQ/f0FY4TL7g1d73/GR4jjEjvgikzm2WqFNGi3QAj/0dU Wt63UMri7uTHBemIKxeQUw6yPOCxdPMCxAo5Vivu0/fXqL3+sYsX2ESGhmvKEmG76+6Q 5uXXlNIPGPBdSvudrql0m56wCOLQDm1DsT67+CGRDhwiCzH/r5Iy52qceo6QAcbysM0a YwTw==
X-Gm-Message-State: ALoCoQmUqJl6n44Q/9/wXcur94v5ZALGcIOC4cYiVWUl4xtbyC8IZhg5b7+WNkoefk1JtttC7mRV
X-Received: by 10.194.10.130 with SMTP id i2mr20370383wjb.70.1402846909209; Sun, 15 Jun 2014 08:41:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Sun, 15 Jun 2014 08:41:09 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <c0795e25-7f1b-436f-8bf9-7da2914c4357@email.android.com>
References: <emcef68d3e-8260-40c5-9b7d-c6838a595d8b@sydney> <539D48B1.80003@alvestrand.no> <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com> <539DAF41.50500@alvestrand.no> <c0795e25-7f1b-436f-8bf9-7da2914c4357@email.android.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 15 Jun 2014 08:41:09 -0700
Message-ID: <CABcZeBMVzCzCUKLwu7yWqWha+TGr7cz-sv_oRMpBsHV3iAb1rw@mail.gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: multipart/alternative; boundary="047d7b450586b2c82004fbe1bfae"
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/nPMoQnPBCQ-3_DhbRLo0euenqB4
X-Mailman-Approved-At: Mon, 16 Jun 2014 10:37:48 -0700
Cc: Harald Alvestrand <harald@alvestrand.no>, dart@ietf.org
Subject: Re: [Dart] multiplexing different media types
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jun 2014 15:41:53 -0000

On Sun, Jun 15, 2014 at 8:30 AM, Paul E. Jones <paulej@packetizer.com>
wrote:

> Harald,
>
> I think we're saying the same thing. The multiplexing point is the SSRC,
> correct?
>
> I said two media sources cannot use the same PT. Effectively, all PT
> values used by an endpoint sending media are distinct. Is that correct?
>

No. Two media sources that are sending the same type of media
(e.g., two streams of VP8) from the same endpoint can use the same
PT as long as the SSRCs are different. See:

http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.2.1.2


-Ekr

My last question below is trying to understand why its not allowed for
> SSRC1 and SSRC2, perhaps one being an audio source and one being a video
> source, to use PT 97, for example. I think that's presently not allowed,
> but not sure why since demux occurs on the SSRC.
>
> Paul
>
>
> ------------------------------
> *From:* Harald Alvestrand <harald@alvestrand.no>
> *Sent:* June 15, 2014 10:35:45 AM EDT
>
> *To:* "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric
> Rescorla <ekr@rtfm.com>
> *Subject:* Re: multiplexing different media types
>
> On 06/15/2014 04:24 PM, Paul E. Jones wrote:
>
> Harald,
>
> Thanks for the clarification. If you'll indulge, allow me to ask one more
> basic question...
>
> In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to
> explain that multiplexing is on the SSRC. It also says no two media sources
> shall use the same PT value.
>
>
> No, it does not say that - in fact, it says exactly the opposite.
>
> It says that it cannot use the same SSRC for two different media streams
> and depend on PT to distinguish between them. PT is not a multiplexing
> point.
>
> The PT value is a single byte, and is sometimes used for other purposes
> (with RTP/RTCP multiplexing, for example, some numbers are unusable because
> RTCP uses the same field for operation codes). Trying to use it to
> distinguish between streams would reduce the max number of possible streams
> to a seriously ridiculously low number.
>
> Can you point me at the language you interpreted that way? If it can be
> read that way, it *must* be changed.
>
>  Thus, a payload type could be used when demultiplexing, though the text
> says otherwise. Perhaps this language exists to support multipoint?  Thus,
> a receiver first looks at the SSRC to identify the source, then the PT to
> determine what the packet contains? Is SSRC demuxing there only for
> multipoint?
>
>
> No. The PT tells the receiver what format the packet contains. The SSRC
> tells you which RTP packet flow it belongs to. In some cases one RTP packet
> flow will switch between different payload types (audio, DTMF and comfort
> noise being the most common examples), while still representing only one
> media flow.
>
>
>  Why not allow the PT number space to be distinct per SSRC?
>
>
> I have problems parsing this question into the context above. What are you
> asking?
>
>  Paul
>
>
>  ------------------------------
> *From:* Harald Alvestrand <harald@alvestrand.no> <harald@alvestrand.no>
> *Sent:* June 15, 2014 3:18:09 AM EDT
> *To:* "Paul E. Jones" <paulej@packetizer.com> <paulej@packetizer.com>,
> dart@ietf.org, Eric Rescorla <ekr@rtfm.com> <ekr@rtfm.com>
> *Subject:* Re: multiplexing different media types
>
> (Adding EKR to thread to get a definitive DTLS answer)
>
> On 06/15/2014 06:52 AM, Paul E. Jones wrote:
>>
>>  Harald,
>>
>>
>>>
>>>  "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.
>>
>>
>>  Your draft (draft-ietf-rtcweb-transports) says:
>>
>>      RTCWEB implementations MUST support multiplexing of DTLS and RTP over
>>      the same port pair, as described in the DTLS_SRTP specification
>>      [RFC5764], section 5.1.2. A!
>>  ll
>> application layer protocol payloads
>>      over this DTLS connection are SCTP packets.
>>
>>  I had a question about this as we discussed the DART draft.  I assumed
>>  the only DTLS connection would be one used for key negotiation for
>>  SRTP.  Is that not the case? Would there be multiple DTLS connections
>>  multiplexed?  If so, how would one be differentiated from another?
>
>
> EKR is the expert here.
>
> As I understand it, the key material for DTLS-SRTP is derived from the
> session keys from the DTLS session. This does not in any way affect the
> usage of the same DTLS session for passing DTLS data.
>
>>
>>
>>  As for RTP Session multiplexing, it's interesting to hear that
>>  proposals are dead.  Is there a proposal for multiplexing different
>>  media types (e.g., audio and video) within the sa!
>>  me RTP
>> Session,
>>  then?  RFC 3550 discourages that, but it was my understanding that
>>  browser makers wanted to multiplex the different media types somehow.
>>  What's the plan?
>
>
> draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
> draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.
>
> The only thing in RTP itself that prevents such multiplexing is the
> words in RFC 3550; technically there is no barrier at the RTP level.
>
> At the SDP level things are a bit more complex, which is why -bundle-
> isn't an RFC yet.
>
>>
>>
>>  Paul
>
>
>
>