Re: [rtcweb] RTP demux in JSEP and BUNDLE

Eric Rescorla <ekr@rtfm.com> Fri, 09 December 2016 17:14 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2C1298D0 for <rtcweb@ietfa.amsl.com>; Fri, 9 Dec 2016 09:14:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 QVUKR4_OmMqA for <rtcweb@ietfa.amsl.com>; Fri, 9 Dec 2016 09:14:21 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4C11296AB for <rtcweb@ietf.org>; Fri, 9 Dec 2016 09:14:17 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id r204so19438550ywb.0 for <rtcweb@ietf.org>; Fri, 09 Dec 2016 09:14:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wb84CtaI+b+emMxGZtxwcdBYj77OPyho87g0ubEwXs0=; b=nt7jo/2A6rlvUc5qN2Bw8iSNpwdkeez/qj3T0vCMCRBXAnc+bAA9feh7GKhq5D1j8F 9ScFi1a0XCVBGsl9hZpRUNgbXJ32xDRPI61yFwLBsMsuoACrh9rsKiHc4haBgPelMktu 0dEdq5gcCSnl86isN5QeYjpgFcPGB8n0ZYexsQ1Mko4V5gQeaJzntICQkBCpp0zSqokO JpY2FiUT63UJbXr1AOF444w1M8uGModgHRMUfM/DjDGZxxw+nujcCdKC/dUfEyeM2UcQ rsfD8dgW0NZmAjiBQ09C18tZ982e3XX2FVG6V34NtDkfUmWNNgZ9fNzmDkHIZxLkCIxH 8pFw==
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; bh=wb84CtaI+b+emMxGZtxwcdBYj77OPyho87g0ubEwXs0=; b=Q9oLAqCMsL4wQ2zndRnC4VCrqmRLP+jSQ3sXlhodPBw61UXFK4OW1V0fc4ScQtR4El r8Wdy0cm1scCBsoSbORoaoGXULSJK+A/qm/M/spYKshKo1f7eST4tT6qTcBAfdrRybUF USgdmovCvc12b+0i5yoGqBdIFYQMhUBD2BcWFmO432c9P6eGMvrhewWEmIE2J2LYsUgS 6fYn7Le/Do+3qtCXmh3W7ps3qEc00FlI9DTP+V1OSkgRbCQabC1turuuaRloeTC2Ee5N FQTKxmnood48bIEPCxa6FlyTOPfz+bzV30dbf8x0IAx3tibg4aySnaGYUs2+6S8G+hNr fvUQ==
X-Gm-Message-State: AKaTC03inzBTl16QZS1WANQ4WCmE9sFwqQmgQ/ZCIP+n4P6N33geeoya+VvzWRbA/3RKbrbFZ0RsfhppH3B7/w==
X-Received: by 10.129.108.216 with SMTP id h207mr75473944ywc.52.1481303656743; Fri, 09 Dec 2016 09:14:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.164.210 with HTTP; Fri, 9 Dec 2016 09:13:36 -0800 (PST)
In-Reply-To: <BED69D59-AA4E-4CC5-B58E-28C77B50B044@iii.ca>
References: <CC36EBFF-A877-433E-B590-1DFC2F1293B1@csperkins.org> <BED69D59-AA4E-4CC5-B58E-28C77B50B044@iii.ca>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 09 Dec 2016 07:13:36 -1000
Message-ID: <CABcZeBPNhAhTx0ynV+RY7kbJiQAVM7DW9kr0YtjusyCfK_9uwA@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary="001a114dd36e43f10d05433ce25e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/cdUXRY33R47lWjSyEjjNlBjlGFM>
Cc: draft-ietf-rtcweb-jsep@tools.ietf.org, RTCWeb IETF <rtcweb@ietf.org>, Colin Perkins <csp@csperkins.org>, draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org, "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [rtcweb] RTP demux in JSEP and BUNDLE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 17:14:25 -0000

I agree with Cullen that the algorithm structure used in current JSEP is
the better structure.

Magnus, Colin, do you think you could rewrite your text in that structure?

-Ekr


On Fri, Dec 9, 2016 at 7:10 AM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> In general, I think it makes sense to put most the details in bundle and
> overview in jsep as you have proposed here.
>
> I believe we agreed that if the PT was unique, then that would be used for
> the demux as well. I'd like to see that explicitly spelled out in this text
> instead of just left as an option allowed but not really specified by this
> text.  I'd also like it be clear that MID takes priority over PT.
>
> I prefer the much more explicit algorithm particularly for the RTCP
> handling as implementors have a hard time figuring out wha they need to do
> to process the RTCP.
>
>
>
> > On Dec 8, 2016, at 3:54 AM, Colin Perkins <csp@csperkins.org> wrote:
> >
> > Hi,
> >
> > [cc’ing RTCWEB and MMUSIC, since this relates to both JSEP and BUNDLE
> drafts]
> >
> > There’s been a lot of discussion on the lists, and at the meeting in
> Seoul, around how RTP streams are mapped onto higher-level, application
> meaningful, semantic roles. In particular, around how RTP streams map onto
> JSEP objects for WebRTC. Magnus Westerlund and I would like to propose the
> following updates to JSEP and BUNDLE to try to clarify the behaviour.
> >
> > Comments and feedback very welcome.
> >
> > Cheers,
> > Colin
> >
> >
> >
> > # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17
> >
> > <section title="Processing RTP/RTCP" anchor="sec.rtp.demux">
> >    <t>As described in <xref target="RFC3550"/>, RTP packets are
> >    associated with RTP streams <xref target="RFC7656"/>. Metadata
> >    about those streams, including source description information
> >    and reception quality feedback is conveyed in RTCP packets.
> >    Each RTP stream is identified by an SSRC, and each RTP packet
> >    carries an SSRC value that is used to associate the packet with
> >    the correct RTP stream. RTCP packets also use SSRCs to identify
> >    the RTP streams that the reports and metadata relate to.  RTCP
> >    packets generally carry multiple SSRC values and report on, or
> >    deliver source description information relating to, several RTP
> >    streams.</t>
> >
> >    <t>Each incoming RTP stream, identified by its SSRC, is mapped to
> >    an m= section in the SDP. The SDP m= sections then correspond to
> >    RtpReceiver objects. This allows each RTP stream to be associated
> >    with an RtpTransceiver. Further processing of the RTP stream can
> >    then be done at the RtpTransceiver level.  This includes using
> >    RID <xref target="I-D.ietf-mmusic-rid"/> to distinguish between
> >    multiple Encoded Streams, as well as determine which Source RTP
> >    stream should be repaired by a given Redundancy RTP stream.</t>
> >
> >    <t>The process of mapping RTP streams onto m= sections depends on
> >    whether streams are bundled or not. If the SDP BUNDLE extension
> >    is in use, then RTP streams are mapped onto m= sections based on
> >    the MID values as described in
> >    <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>.  If the
> >    SDP BUNDLE extension is not in use, each m= section corresponds
> >    to a transport layer connection and the RTP streams received on
> >    that connection correspond to the m= section.</t>
> >
> >    <t>Incoming RTCP packets contain metadata including reception
> >    quality feedback, source description information, and other
> >    signalling relating to RTP streams. The RTCP packets are parsed,
> >    the associated RTP streams are identified based on the included
> >    SSRC values, and the metadata relating to those RTP streams is
> >    updated (this might include updating the MID information, used
> >    to associate RTP streams with m= sections, if the SDP BUNDLE
> >    extension is in use). This updated metadata is available to the
> >    RtpTransceiver objects associated with those RTP streams.
> >    </t>
> > </section>
> >
> >
> >
> > # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-
> negotiation-36
> >
> >     <section anchor="sec-rtp-pt"
> >              title="Associating RTP Streams With Correct SDP Media
> Description"
> >              toc="default">
> >       <t>As described in <xref format="default" pageno="false"
> >       target="RFC3550"/>, RTP packets are associated with RTP streams
> <xref
> >       format="default" pageno="false" target="RFC7656"/>. Each RTP
> stream is
> >       identified by an SSRC value, and each RTP packet carries an SSRC
> value
> >       that is used to associate the packet with the correct RTP stream.
> RTCP
> >       packets also uses SSRCs to identify on which RTP streams any
> report or
> >       feedback relate to. Thus, an RTCP packet will commonly carry
> multiple
> >       SSRC values, and might therefore be providing feedback or report on
> >       multiple RTP streams. </t>
> >
> >       <t>In order to be able to process received RTP packets correctly it
> >       must be possible to associate an RTP stream with the correct "m="
> >       line, as the "m=" line and SDP attributes associated with the "m="
> >       line contain information needed to process the packets.</t>
> >
> >       <t>As all RTP streams associated with a BUNDLE group are part of
> the
> >       same RTP session and using the same address:port combination for
> >       sending and receiving RTP/RTCP packets, the local address:port
> >       combination cannot be used to associate an RTP stream with the
> correct
> >       "m=" line. In addition, multiple RTP streams might be associated
> with
> >       the same "m=" line.</t>
> >
> >       <t>Also, as described in <xref format="default" pageno="false"
> >       target="sec-rtp-sessions-pt"/>, the same payload type value might
> be
> >       used by multiple RTP streams, in which case the payload type value
> >       cannot be used to associate an RTP stream with the correct "m="
> line.
> >       However, there are cases where each "m=" line has unique payload
> type
> >       values, and then the payload type could serve as hint to the
> relevant
> >                   "m=" line the RTP stream is associated with.</t>
> >
> >       <t>An offerer and answerer can inform each other which SSRC values
> >       they will use for an RTP stream by using the SDP 'ssrc' attribute
> >       <xref format="default" pageno="false" target="RFC5576"/>. However,
> an
> >       offerer will not know which SSRC values the answerer will use until
> >       the offerer has received the answer providing that information.
> Due to
> >       this, before the offerer has received the answer, the offerer will
> not
> >       be able to associate an RTP stream with the correct "m=" line using
> >       the SSRC value associated with the RTP stream. In addition, the
> >       offerer and answerer may start using new SSRC values mid-session,
> >       without informing each other using the SDP 'ssrc' attribute.</t>
> >
> >       <t>In order for an offerer and answerer to always be able to
> associate
> >       an RTP stream with the correct "m=" line, the offerer and answerer
> >       using the BUNDLE extension MUST support the mechanism defined in
> <xref
> >       format="default" pageno="false" target="sec-receiver-id"/>, where
> the
> >       offerer and answerer includes the identification-tag (provided by
> the
> >       remote peer) associated with an "m=" line in the RTP Streams and in
> >       RTCP SDES packets part of a BUNDLE group.</t>
> >
> >       <t>The mapping from an SSRC to an identification-tag is carried in
> >       RTCP SDES packets or in RTP header extensions (<xref
> format="default"
> >       pageno="false" target="sec-receiver-id"/>). Since a compound RTCP
> >       packet can contain multiple RTCP SDES packets, and each RTCP SDES
> >       packet can contain multiple chunks, an RTCP packet can contain
> several
> >       SSRC to identification-tag mappings. The offerer and answerer
> maintain
> >       tables mapping RTP streams identified by SSRC to "m=" lines
> identified
> >       by the identification-tag.
> >       When receiving an RTP packet carrying a MID header extension
> >       with the identification-tag, or an RTCP packet carrying one or
> >       more SDES MID items, the offerer or answerer creates a mapping
> >       table entry between the SSRC value and the identification-tag,
> >       in order to associate the RTP stream associated with that SSRC
> >       value with the "m=" line corresponding to the
> identification-tag.</t>
> >
> >       <t>The mapping between the SSRC an identification-tag might change
> >       mid-session if, for a given SSRC value, a different
> identification-tag
> >       is provided in an RTP or RTCP packet. In that case these tables are
> >       updated each time an RTP/RTCP packet containing a new mappings from
> >       SSRC to identification-tag is received. Some considerations for
> >       avoiding update flaps are provided in Section 4.2.6 of <xref
> >       target="RFC7941"/> which should be followed. </t>
> >
> >       <t>If an offerer and answerer is not able to associate an RTP
> stream
> >       with an "m=" line (using the mechanisms described in this section,
> or
> >       using other appropriate mechanism, e.g., based on the payload type
> >       value if it is unique to a single "m=" line), it MUST either drop
> the
> >       RTP packets associated with the RTP stream, or process them in an
> >       application specific manner, once non-stream specific processing
> >       (e.g., related to congestion control) of the RTP packets have
> >       occurred.</t>
> >
> >       <t>When compound RTCP packets are received, they are split
> >       into their component RTCP packets and those component RTCP
> >       packets are processed based on their RTCP packet type, in
> >       the order in which they were placed into the compound RTCP
> >       packet. Non-compound RTCP packets are processed based on
> >       their RTCP packet type, in the order they are received. Information
> >       in each RTCP packet can relate to one or more RTP streams.
> >       For example, RTCP Sender Report (SR) and Receiver Report (RR)
> >       packets include an SSRC of sender field that indicates the
> >       identity of the participant that sent the RTCP packet, along
> >       with a list of Report Blocks. Each report contains data on the
> >       reception quality of a single RTP stream, identified by SSRC,
> >       as received by the SSRC that sent the RTCP packet. Other RTCP
> >       packet types similarly contain references to the SSRC of the
> >       sender of the RTCP packet, and the RTP streams to which it
> >       refers.</t>
> >
> >       <t>It should always be possible to process RTCP packets, and
> >       store the received information in a data structure associated
> >       with an RTP stream, identified by SSRC, for later access and
> >       use. It is possible that RTCP packets relating to an SSRC can
> >       be received before RTP packets relating to that SSRC, so the
> >       data structures relating to an SSRC might need to be created
> >       before the corresponding RTP stream is received.</t>
> >
> >       <t>Similarly, information relating to an RTP stream might be
> >       received before the data needed to map it onto an m= line is
> >       received. Information carried in RTCP packets relating to such
> >       an RTP stream that is application and/or "m=" line dependent
> >       MAY be dropped until the SSRCs is associated with a particular
> >       "m=" line. However, information to generate RTCP report blocks
> >       and other basic transport level feedback or reporting needs to
> >       be retained, so RTCP reports relating to the stream can be
> >       generated.</t>
> >
> >     </section>
> >
> >
> >
> >
> > --
> > Colin Perkins
> > https://csperkins.org/
> >
> >
> >
> >
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>