Re: [Dart] multiplexing different media types

Eric Rescorla <ekr@rtfm.com> Sun, 15 June 2014 17:02 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 F11C31B2BAB for <dart@ietfa.amsl.com>; Sun, 15 Jun 2014 10:02:13 -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 cwGIQ7oWZ6KR for <dart@ietfa.amsl.com>; Sun, 15 Jun 2014 10:02:11 -0700 (PDT)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9DF1B2B66 for <dart@ietf.org>; Sun, 15 Jun 2014 10:02:10 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id hi2so4251384wib.0 for <dart@ietf.org>; Sun, 15 Jun 2014 10:02:09 -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=J5j7+aIWurfuEzjHCyy2yfhJA41eNorB0DckdPw+FVU=; b=aG54POuGydpIKFyb2Oa3hOFquW4YzH/rbV0dJSxJBflvrvBz6g0v7TsG3KyeTkyFcb rYzSdI4PixqRaBCX5XuG2xX4lu/i/O+xWLRCPUZqV5V2Uvq45K6qIYSHTGjzDNyusU+S 4MI5CyJ3PdMZDFYgtTTu8ovebvjDaWyBdk9HaXpEwSvselviCAS+Hsn8H5oJUasUDFjX Zy0V/p33NEh6E5ylpiQNiDUIAPArZRSymjJ4Nty20LJFMj/uG1K5V3yObuaxa4yJ1w+F gpmpdLTbyJmHjx5NiexsQwaHdlecH2tqUPvuQWkzjEY1ZPL6UZEljFRrR7jgpxn0IgGZ Aw2Q==
X-Gm-Message-State: ALoCoQnGR3DQmRzS1ezf2zwK+5yTdsDCArwhx4JWAudAglrjdp8Ygg5dvT5qrhzCXSfdiNTaftmS
X-Received: by 10.195.13.79 with SMTP id ew15mr20913281wjd.19.1402851729136; Sun, 15 Jun 2014 10:02:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Sun, 15 Jun 2014 10:01:29 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <cdad7f28-10cf-4301-9b32-be603203932e@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> <CABcZeBMVzCzCUKLwu7yWqWha+TGr7cz-sv_oRMpBsHV3iAb1rw@mail.gmail.com> <cdad7f28-10cf-4301-9b32-be603203932e@email.android.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 15 Jun 2014 10:01:29 -0700
Message-ID: <CABcZeBPMbjU=_toSQK=jShpTrvwcSYFrpghct=cNY5KYpFsW0g@mail.gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: multipart/alternative; boundary=047d7bfd093afcfb4104fbe2dec2
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/z22cSKFwLCgB1O5uz6Wjk0Fb8GQ
X-Mailman-Approved-At: Mon, 16 Jun 2014 10:37:50 -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 17:02:14 -0000

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

> Eric,
>
> Sorry, I should have been clearer in preparing the question. When I was
> referring to media sources, I had completely different types in mind (e.g.,
> audio and video).
>
> What I am trying to understand is why there is this statement in the
> guidelines draft:
>
> "The payload type is scoped by sending endpoint within an RTP Session. All
> synchronisation sources sent from an single endpoint share the same payload
> types definitions."
>
> Clearly, that is legal. But, I'm curious why we maintain this
> restriction.  Since a receiver will demux incoming packets via the SSRC, it
> seems the PT values associated with a given SSRC could be distinct from
> another SSRC.
>
> Presently for a given sender, there is a "global" definition of PT values
> (96 for some specific audio format, 97 for some specific video format, ...)
> and those can be used by multiple SSRCs.  So I'm asking why we don't allow
> {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each 96 could be different
> formats.
>
What would be the virtue of doing that?

-Ekr


> Paul
>
>
> ------------------------------
> *From:* Eric Rescorla <ekr@rtfm.com>
> *Sent:* June 15, 2014 11:41:09 AM EDT
>
> *To:* "Paul E. Jones" <paulej@packetizer.com>
> *Cc:* Harald Alvestrand <harald@alvestrand.no>, dart@ietf.org
>
> *Subject:* Re: multiplexing different media types
>
>
>
>
> 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
>>
>>
>>
>>
>