I agree with Cullen that the algorithm structure used in c= urrent JSEP is the better structure.

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

-Ekr

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

In general, I think it makes sense to put most the details in bundle and ov= erview 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.=C2=A0 I'd also like it be clear that MID takes priority over= PT.

I prefer the much more explicit algorithm particularly for the RTCP handlin= g as implementors have a hard time figuring out wha they need to do to proc= ess the RTCP.

> On Dec 8, 2016, at 3:54 AM, Colin Perkins <csp@csperkins.org> wrote:
>
> Hi,
>
> [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and= BUNDLE drafts]
>
> There=E2=80=99s been a lot of discussion on the lists, and at the meet= ing in Seoul, around how RTP streams are mapped onto higher-level, applicat= ion meaningful, semantic roles. In particular, around how RTP streams map o= nto 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=3D"Processing RTP/RTCP" anchor=3D"sec= .rtp.demux">
>=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550&= quot;/>, RTP packets are
>=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC76= 56"/>. Metadata
>=C2=A0 =C2=A0 about those streams, including source description informa= tion
>=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packet= s.
>=C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP pa= cket
>=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packe= t with
>=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to id= entify
>=C2=A0 =C2=A0 the RTP streams that the reports and metadata relate to.= =C2=A0 RTCP
>=C2=A0 =C2=A0 packets generally carry multiple SSRC values and report o= n, or
>=C2=A0 =C2=A0 deliver source description information relating to, sever= al RTP
>=C2=A0 =C2=A0 streams.</t>
>
>=C2=A0 =C2=A0 <t>Each incoming RTP stream, identified by its SSRC= , is mapped to
>=C2=A0 =C2=A0 an m=3D section in the SDP. The SDP m=3D sections then co= rrespond to
>=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be as= sociated
>=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP str= eam can
>=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This incl= udes using
>=C2=A0 =C2=A0 RID <xref target=3D"I-D.ietf-mmusic-rid"/>= ; to distinguish between
>=C2=A0 =C2=A0 multiple Encoded Streams, as well as determine which Sour= ce RTP
>=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP strea= m.</t>
>
>=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D sec= tions depends on
>=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE ext= ension
>=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections= based on
>=C2=A0 =C2=A0 the MID values as described in
>=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-n= egotiation"/>.=C2=A0 If the
>=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section cor= responds
>=C2=A0 =C2=A0 to a transport layer connection and the RTP streams recei= ved on
>=C2=A0 =C2=A0 that connection correspond to the m=3D section.</t>=
>
>=C2=A0 =C2=A0 <t>Incoming RTCP packets contain metadata including= reception
>=C2=A0 =C2=A0 quality feedback, source description information, and oth= er
>=C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are = parsed,
>=C2=A0 =C2=A0 the associated RTP streams are identified based on the in= cluded
>=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP strea= ms is
>=C2=A0 =C2=A0 updated (this might include updating the MID information,= used
>=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP B= UNDLE
>=C2=A0 =C2=A0 extension is in use). This updated metadata is available = to the
>=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.=
>=C2=A0 =C2=A0 </t>
> </section>
>
>
>
> # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-negotiation-36
>
>=C2=A0 =C2=A0 =C2=A0<section anchor=3D"sec-rtp-pt"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 title=3D"Associat= ing RTP Streams With Correct SDP Media Description"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default&qu= ot;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D&= quot;default" pageno=3D"false"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packe= ts are associated with RTP streams <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"= false" target=3D"RFC7656"/>. Each RTP stream is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP pa= cket carries an SSRC value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with th= e correct RTP stream. RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets also uses SSRCs to identify on which= RTP streams any report or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback relate to. Thus, an RTCP packet wil= l commonly carry multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providin= g feedback or report on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple RTP streams. </t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order to be able to process rece= ived RTP packets correctly it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0must be possible to associate an RTP stream = with the correct "m=3D"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0line, as the "m=3D" line and SDP a= ttributes associated with the "m=3D"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process t= he packets.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with = a BUNDLE group are part of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0same RTP session and using the same address:= port combination for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sending and receiving RTP/RTCP packets, the = local address:port
>=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an R= TP stream with the correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. In addition, multiple= RTP streams might be associated with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the same "m=3D" line.</t> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Also, as described in <xref form= at=3D"default" pageno=3D"false"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/>= ;, the same payload type value might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used by multiple RTP streams, in which case = the payload type value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be used to associate an RTP stream wi= th the correct "m=3D" line.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m= =3D" line has unique payload type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serv= e as hint to the relevant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;m=3D" line the RTP stream is associated with.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>An offerer and answerer can inform = each other which SSRC values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0they will use for an RTP stream by using the= SDP 'ssrc' attribute
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref format=3D"default" pageno= =3D"false" target=3D"RFC5576"/>. However, an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the = answerer will use until
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providin= g that information. Due to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the an= swer, the offerer will not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the = correct "m=3D" line using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP strea= m. In addition, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSR= C values mid-session,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP &= #39;ssrc' attribute.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answere= r to always be able to associate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D&qu= ot; line, the offerer and answerer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the = mechanism defined in <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"= false" target=3D"sec-receiver-id"/>, where the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identifica= tion-tag (provided by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D&q= uot; line in the RTP Streams and in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.<= ;/t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an iden= tification-tag is carried in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extension= s (<xref format=3D"default"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"se= c-receiver-id"/>). Since a compound RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packet= s, and each RTCP SDES
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP = packet can contain several
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The off= erer and answerer maintain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSR= C to "m=3D" lines identified
>=C2=A0 =C2=A0 =C2=A0 =C2=A0by the identification-tag.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When receiving an RTP packet carrying a MID = header extension
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP pack= et carrying one or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer= creates a mapping
>=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the i= dentification-tag,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associa= ted with that SSRC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line corresp= onding to the identification-tag.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an ide= ntification-tag might change
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a di= fferent identification-tag
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In tha= t case these tables are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet contain= ing a new mappings from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some= considerations for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Sectio= n 4.2.6 of <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which shou= ld be followed. </t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not a= ble to associate an RTP stream
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mec= hanisms described in this section, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., bas= ed on the payload type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D= " line), it MUST either drop the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, = or process them in an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream= specific processing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., related to congestion control) of the= RTP packets have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0occurred.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>When compound RTCP packets are rece= ived, they are split
>=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those = component RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP pa= cket type, in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the= compound RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are proces= sed based on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they ar= e received. Information
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or mor= e RTP streams.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Rec= eiver Report (RR)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that= indicates the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RT= CP packet, along
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report co= ntains data on the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, id= entified by SSRC,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP p= acket. Other RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet types similarly contain references to= the SSRC of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sender of the RTCP packet, and the RTP strea= ms to which it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0refers.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>It should always be possible to pro= cess RTCP packets, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data str= ucture associated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for = later access and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relati= ng to an SSRC can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to t= hat SSRC, so the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might ne= ed to be created
>=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is recei= ved.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to = an RTP stream might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it on= to an m=3D line is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packet= s relating to such
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or &qu= ot;m=3D" line dependent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated= with a particular
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information = to generate RTCP report blocks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or = reporting needs to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the= stream can be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>
>
>=C2=A0 =C2=A0 =C2=A0</section>
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a114dd36e43f10d05433ce25e-- From nobody Fri Dec 9 10:02:14 2016 Return-Path: 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 E3E5A12951B; Fri, 9 Dec 2016 10:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JJw7XLfYLhll; Fri, 9 Dec 2016 10:02:05 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 3222212947C; Fri, 9 Dec 2016 10:02:05 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 12so24820456uas.2; Fri, 09 Dec 2016 10:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TmHwm20IIQ0XkwsUwla7Ujh57yc/dXHMDR7Wan2kaJI=; b=hHpMHoNbJRIWAsc+L/nGXObOfaYsdV3+ExZHzjYyzJn86TApDpl78Eaa6ckax+0UaD v6JpaGr4wlzwkh02dxHMwmCEc7aeJKSlufJIf2+3FxdPNLHqGIVMEs+LTKwG1Ouzcr6h zNINUc8oiTz6jGta2LLFdCHKgT2KVFCa+4p42dpQb4SGWYkdKGLEa1nnhL/qVb9K1oo0 Zm17FVfbtEaL5uuZ1Znl7wnYkMsVLFPasqv0B9n6MdaA/mA/kEMGC32T2UubDXPVJRUO ZlGeLTwuJl5WpTGtpF1ppnh3Ra17awqA/agP/+SMNao80vy1hugC8ROAyWfkEaMN5s8S M/dg== 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=TmHwm20IIQ0XkwsUwla7Ujh57yc/dXHMDR7Wan2kaJI=; b=DJdH0U9FH5YaKhlpZwFRAeCclLzzh+BVRRvHuAkR6CqRPIs4GpD9Mb4nyAUJQFEhEm aHX4TF7orSRYKE+4ps1UJZo2+fG01nJGHHn58AzVmy4y3FimFMa16q26hsi4xbUIgfTe 7EqdAo7DKZWP1DLLDPMNngMYQWXDZyTqiGnxVXNoQWThHM1fxirYWYRDN2aFoKuR2pop YP1zit3fsdXdvyFAMrDp9l4Hr5nXau1sUQKPBRwFu8jez+B2R9KIK+dTVukE68BTXGJb QbMH9HyROlM+30V4UpJyddYusGWEQoDBLXBNprPSXCdOoJeDbolxjeECsC+TAC81tUbq js8A== X-Gm-Message-State: AKaTC02IDcOWniDHmc6iQUKdme1/jtzNO8V479RUBlGBtIkZI6qcYiGTMy/n6mPzTc4cI1PerkCoAfDiFS9v4g== X-Received: by 10.159.50.138 with SMTP id l10mr52620874uab.166.1481306524042; Fri, 09 Dec 2016 10:02:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.5 with HTTP; Fri, 9 Dec 2016 10:01:43 -0800 (PST) In-Reply-To: References:

From: Bernard Aboba Date: Fri, 9 Dec 2016 10:01:43 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=f403045ddf7a2b4dcf05433d8db0 Archived-At: Cc: "mmusic \(E-mail\)" , draft-ietf-rtcweb-jsep@tools.ietf.org, RTCWeb IETF , Colin Perkins , draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org Subject: Re: [rtcweb] [MMUSIC] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 18:02:10 -0000 --f403045ddf7a2b4dcf05433d8db0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Eric and Cullen that a more explicit algorithm is needed. The proposed text is not specific enough to resolve observed implementation differences. Cullen said: " I'd also like it be clear that MID takes priority over PT." [BA] Yes. This is something that multiple implementations appear to agree on. Also, Peter's suggestion that a MID mismatch result in a packet drop should be restored. "I believe we agreed that if the PT was unique, then it would be used for demux as well." [BA] That is my understanding as well. However, I'd also like to understand what happens if the PT is not unique. The proposed text does not provide enough detail and existing implementations differ in how they treat non-unique PTs. I am familiar with an implementation that declares SDP with non-unique PTs to be in error. Another implementation fills a Payload Type table with a single value, with the value selected depending on whether SSRCs are also specified (e.g. specification of SSRCs is taken as an indication that only SSRC matching is desired, and therefore that a Payload Type entry is not needed). The ORTC API spec says to latch the SSRC on a Payload Type match and then remove the Payload Type table entry, but some implementations have found this leads to problems so they have foresaken either the latching or the PT removal (or both). Cullen said: "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." [BA] I would also prefer that we have a more explicit algorithm here, because we have seen very substantial implementation differences. One implementation I'm familiar with sends the RTCP packets to all RtpSender and RtpReceiver objects. While this is inefficient, it does avoid sending RTCP packets to the wrong objects. Another implementation sorts the RTCP reports as indicated in the proposed text - but has found that the required handling is so message-dependent that it leads to bugs (e.g. FIR and APP messages have caused issues in particular). So this approach is more efficient, unless we are willing to get into detail on every RTCP message, it will fall short. On Fri, Dec 9, 2016 at 9:13 AM, Eric Rescorla wrote: > 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 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 th= is >> 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 wrote: >> > >> > Hi, >> > >> > [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and= BUNDLE >> drafts] >> > >> > There=E2=80=99s been a lot of discussion on the lists, and at the meet= ing in >> Seoul, around how RTP streams are mapped onto higher-level, application >> meaningful, semantic roles. In particular, around how RTP streams map on= to >> JSEP objects for WebRTC. Magnus Westerlund and I would like to propose t= he >> 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 >> > >> >

>> > As described in , RTP packets are >> > associated with RTP streams . 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. >> > >> > Each incoming RTP stream, identified by its SSRC, is mapped to >> > an m=3D section in the SDP. The SDP m=3D sections then correspond t= o >> > 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 to distinguish between >> > multiple Encoded Streams, as well as determine which Source RTP >> > stream should be repaired by a given Redundancy RTP stream. >> > >> > The process of mapping RTP streams onto m=3D sections depends on >> > whether streams are bundled or not. If the SDP BUNDLE extension >> > is in use, then RTP streams are mapped onto m=3D sections based on >> > the MID values as described in >> > . If the >> > SDP BUNDLE extension is not in use, each m=3D section corresponds >> > to a transport layer connection and the RTP streams received on >> > that connection correspond to the m=3D section. >> > >> > 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=3D sections, if the SDP BUNDLE >> > extension is in use). This updated metadata is available to the >> > RtpTransceiver objects associated with those RTP streams. >> > >> >

>> > >> > >> > >> > # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-n >> egotiation-36 >> > >> >

> > title=3D"Associating RTP Streams With Correct SDP Media >> Description" >> > toc=3D"default"> >> > As described in > > target=3D"RFC3550"/>, RTP packets are associated with RTP stream= s >> > > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each R= TP >> 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. >> > >> > In order to be able to process received RTP packets correctly >> it >> > must be possible to associate an RTP stream with the correct "m= =3D" >> > line, as the "m=3D" line and SDP attributes associated with the = "m=3D" >> > line contain information needed to process the packets. >> > >> > 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=3D" line. In addition, multiple RTP streams might be associat= ed >> with >> > the same "m=3D" line. >> > >> > Also, as described in > > target=3D"sec-rtp-sessions-pt"/>, the same payload type value >> might be >> > used by multiple RTP streams, in which case the payload type val= ue >> > cannot be used to associate an RTP stream with the correct "m=3D= " >> line. >> > However, there are cases where each "m=3D" line has unique paylo= ad >> type >> > values, and then the payload type could serve as hint to the >> relevant >> > "m=3D" line the RTP stream is associated with. >> > >> > An offerer and answerer can inform each other which SSRC valu= es >> > they will use for an RTP stream by using the SDP 'ssrc' attribut= e >> > . >> 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=3D" 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. >> > >> > In order for an offerer and answerer to always be able to >> associate >> > an RTP stream with the correct "m=3D" line, the offerer and answ= erer >> > using the BUNDLE extension MUST support the mechanism defined in >> > > format=3D"default" pageno=3D"false" target=3D"sec-receiver-id"/>= , where >> the >> > offerer and answerer includes the identification-tag (provided b= y >> the >> > remote peer) associated with an "m=3D" line in the RTP Streams a= nd >> in >> > RTCP SDES packets part of a BUNDLE group. >> > >> > The mapping from an SSRC to an identification-tag is carried = in >> > RTCP SDES packets or in RTP header extensions (> format=3D"default" >> > pageno=3D"false" target=3D"sec-receiver-id"/>). Since a compound= RTCP >> > packet can contain multiple RTCP SDES packets, and each RTCP SDE= S >> > 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=3D" 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=3D" line corresponding to the >> identification-tag. >> > >> > The mapping between the SSRC an identification-tag might chan= ge >> > 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 > > target=3D"RFC7941"/> which should be followed. >> > >> > If an offerer and answerer is not able to associate an RTP >> stream >> > with an "m=3D" line (using the mechanisms described in this >> section, or >> > using other appropriate mechanism, e.g., based on the payload ty= pe >> > value if it is unique to a single "m=3D" line), it MUST either d= rop >> the >> > RTP packets associated with the RTP stream, or process them in a= n >> > application specific manner, once non-stream specific processing >> > (e.g., related to congestion control) of the RTP packets have >> > occurred. >> > >> > 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. >> > >> > 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. >> > >> > Similarly, information relating to an RTP stream might be >> > received before the data needed to map it onto an m=3D line is >> > received. Information carried in RTCP packets relating to such >> > an RTP stream that is application and/or "m=3D" line dependent >> > MAY be dropped until the SSRCs is associated with a particular >> > "m=3D" 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. >> > >> >

>> > >> > >> > >> > >> > -- >> > Colin Perkins >> > https://csperkins.org/ >> > >> > >> > >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --f403045ddf7a2b4dcf05433d8db0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I agree with Eric and Cullen that a more explicit algorith= m is needed.=C2=A0 The proposed text is not specific enough to resolve obse= rved implementation differences.=C2=A0

Cullen said:=C2= =A0

"=C2=A0<= /span>I'd also like it be clear that M= ID takes priority over PT."

[BA] Yes.=C2= =A0 This is something that multiple implementations appear to agree on.=C2= =A0 Also, Peter's suggestion that a MID mismatch result in a packet dro= p should be restored.

"I believe we agreed that if the PT was unique, the= n it would be used for demux as well."

[BA] T= hat is my understanding as well. =C2=A0

However, I= 'd also like to understand what happens if the PT is not unique.=C2=A0 = The proposed text does not provide enough detail and existing implementatio= ns differ in how they treat non-unique PTs. I am familiar with an implement= ation that declares SDP with non-unique PTs to be in error.=C2=A0 Another i= mplementation fills a Payload Type table with a single value, with the valu= e selected depending on whether SSRCs are also specified (e.g. specificatio= n of SSRCs is taken as an indication that only SSRC matching is desired, an= d therefore that a Payload Type entry is not needed).=C2=A0 The ORTC API sp= ec says to latch the SSRC on a Payload Type match and then remove the Paylo= ad Type table entry, but some implementations have found this leads to prob= lems so they have foresaken either the latching or the PT removal (or both)= . =C2=A0

Cullen said:=C2=A0

&quo= t;I prefer the much more explicit algorith= m particularly for the RTCP handling as implementors have a hard time figur= ing out wha they need to do to process the RTCP."

[BA] I would also prefer that we have a more explicit algorithm= here, because we have seen very substantial implementation differences.=C2= =A0 One implementation I'm familiar with sends the RTCP packets to all = RtpSender and RtpReceiver objects.=C2=A0 While this is inefficient, it does= avoid sending RTCP packets to the wrong objects.=C2=A0 Another implementat= ion sorts the RTCP reports as indicated in the proposed text - but has foun= d that the required handling is so message-dependent that it leads to bugs = (e.g. FIR and APP messages have caused issues in particular).=C2=A0 So this= approach is more efficient, unless we are willing to get into detail on ev= ery RTCP message, it will fall short.=C2=A0

On Fri, Dec 9, 2016 at= 9:13 AM, Eric Rescorla <ekr@rtfm.com> wrote:

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

Magn= us, Colin, do you think you could rewrite your text in that structure?

-Ekr

<= div class=3D"h5">

= 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 ov= erview 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.=C2=A0 I'd also like it be clear that MID takes priority over= PT.

I prefer the much more explicit algorithm particularly for the RTCP handlin= g as implementors have a hard time figuring out wha they need to do to proc= ess the RTCP.

> On Dec 8, 2016, at 3:54 AM, Colin Perkins <csp@csperkins.org> wrote:
>
> Hi,
>
> [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and= BUNDLE drafts]
>
> There=E2=80=99s been a lot of discussion on the lists, and at the meet= ing in Seoul, around how RTP streams are mapped onto higher-level, applicat= ion meaningful, semantic roles. In particular, around how RTP streams map o= nto 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=3D"Processing RTP/RTCP" anchor=3D"sec= .rtp.demux">
>=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550&= quot;/>, RTP packets are
>=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC76= 56"/>. Metadata
>=C2=A0 =C2=A0 about those streams, including source description informa= tion
>=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packet= s.
>=C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP pa= cket
>=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packe= t with
>=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to id= entify
>=C2=A0 =C2=A0 the RTP streams that the reports and metadata relate to.= =C2=A0 RTCP
>=C2=A0 =C2=A0 packets generally carry multiple SSRC values and report o= n, or
>=C2=A0 =C2=A0 deliver source description information relating to, sever= al RTP
>=C2=A0 =C2=A0 streams.</t>
>
>=C2=A0 =C2=A0 <t>Each incoming RTP stream, identified by its SSRC= , is mapped to
>=C2=A0 =C2=A0 an m=3D section in the SDP. The SDP m=3D sections then co= rrespond to
>=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be as= sociated
>=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP str= eam can
>=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This incl= udes using
>=C2=A0 =C2=A0 RID <xref target=3D"I-D.ietf-mmusic-rid"/>= ; to distinguish between
>=C2=A0 =C2=A0 multiple Encoded Streams, as well as determine which Sour= ce RTP
>=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP strea= m.</t>
>
>=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D sec= tions depends on
>=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE ext= ension
>=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections= based on
>=C2=A0 =C2=A0 the MID values as described in
>=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-n= egotiation"/>.=C2=A0 If the
>=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section cor= responds
>=C2=A0 =C2=A0 to a transport layer connection and the RTP streams recei= ved on
>=C2=A0 =C2=A0 that connection correspond to the m=3D section.</t>=
>
>=C2=A0 =C2=A0 <t>Incoming RTCP packets contain metadata including= reception
>=C2=A0 =C2=A0 quality feedback, source description information, and oth= er
>=C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are = parsed,
>=C2=A0 =C2=A0 the associated RTP streams are identified based on the in= cluded
>=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP strea= ms is
>=C2=A0 =C2=A0 updated (this might include updating the MID information,= used
>=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP B= UNDLE
>=C2=A0 =C2=A0 extension is in use). This updated metadata is available = to the
>=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.=
>=C2=A0 =C2=A0 </t>
> </section>
>
>
>
> # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-n<= wbr>egotiation-36
>
>=C2=A0 =C2=A0 =C2=A0<section anchor=3D"sec-rtp-pt"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 title=3D"Associat= ing RTP Streams With Correct SDP Media Description"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default&qu= ot;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D&= quot;default" pageno=3D"false"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packe= ts are associated with RTP streams <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"= false" target=3D"RFC7656"/>. Each RTP stream is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP pa= cket carries an SSRC value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with th= e correct RTP stream. RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets also uses SSRCs to identify on which= RTP streams any report or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback relate to. Thus, an RTCP packet wil= l commonly carry multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providin= g feedback or report on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple RTP streams. </t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order to be able to process rece= ived RTP packets correctly it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0must be possible to associate an RTP stream = with the correct "m=3D"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0line, as the "m=3D" line and SDP a= ttributes associated with the "m=3D"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process t= he packets.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with = a BUNDLE group are part of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0same RTP session and using the same address:= port combination for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sending and receiving RTP/RTCP packets, the = local address:port
>=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an R= TP stream with the correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. In addition, multiple= RTP streams might be associated with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the same "m=3D" line.</t> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Also, as described in <xref form= at=3D"default" pageno=3D"false"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/>, the same payload type value might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used by multiple RTP streams, in which case = the payload type value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be used to associate an RTP stream wi= th the correct "m=3D" line.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m= =3D" line has unique payload type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serv= e as hint to the relevant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;m=3D" line the RTP stream is associated with.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>An offerer and answerer can inform = each other which SSRC values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0they will use for an RTP stream by using the= SDP 'ssrc' attribute
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref format=3D"default" pageno= =3D"false" target=3D"RFC5576"/>. However, an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the = answerer will use until
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providin= g that information. Due to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the an= swer, the offerer will not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the = correct "m=3D" line using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP strea= m. In addition, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSR= C values mid-session,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP &= #39;ssrc' attribute.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answere= r to always be able to associate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D&qu= ot; line, the offerer and answerer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the = mechanism defined in <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"= false" target=3D"sec-receiver-id"/>, where the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identifica= tion-tag (provided by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D&q= uot; line in the RTP Streams and in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.<= ;/t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an iden= tification-tag is carried in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extension= s (<xref format=3D"default"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"se= c-receiver-id"/>). Since a compound RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packet= s, and each RTCP SDES
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP = packet can contain several
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The off= erer and answerer maintain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSR= C to "m=3D" lines identified
>=C2=A0 =C2=A0 =C2=A0 =C2=A0by the identification-tag.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When receiving an RTP packet carrying a MID = header extension
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP pack= et carrying one or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer= creates a mapping
>=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the i= dentification-tag,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associa= ted with that SSRC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line corresp= onding to the identification-tag.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an ide= ntification-tag might change
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a di= fferent identification-tag
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In tha= t case these tables are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet contain= ing a new mappings from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some= considerations for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Sectio= n 4.2.6 of <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which shou= ld be followed. </t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not a= ble to associate an RTP stream
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mec= hanisms described in this section, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., bas= ed on the payload type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D= " line), it MUST either drop the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, = or process them in an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream= specific processing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., related to congestion control) of the= RTP packets have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0occurred.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>When compound RTCP packets are rece= ived, they are split
>=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those = component RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP pa= cket type, in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the= compound RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are proces= sed based on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they ar= e received. Information
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or mor= e RTP streams.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Rec= eiver Report (RR)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that= indicates the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RT= CP packet, along
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report co= ntains data on the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, id= entified by SSRC,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP p= acket. Other RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet types similarly contain references to= the SSRC of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sender of the RTCP packet, and the RTP strea= ms to which it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0refers.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>It should always be possible to pro= cess RTCP packets, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data str= ucture associated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for = later access and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relati= ng to an SSRC can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to t= hat SSRC, so the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might ne= ed to be created
>=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is recei= ved.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to = an RTP stream might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it on= to an m=3D line is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packet= s relating to such
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or &qu= ot;m=3D" line dependent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated= with a particular
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information = to generate RTCP report blocks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or = reporting needs to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the= stream can be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>
>
>=C2=A0 =C2=A0 =C2=A0</section>
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--f403045ddf7a2b4dcf05433d8db0-- From nobody Wed Dec 14 01:39:38 2016 Return-Path: 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 D8DD3129583 for ; Wed, 14 Dec 2016 01:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 icEnNasTEXJF for ; Wed, 14 Dec 2016 01:39:35 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A7F12956C for ; Wed, 14 Dec 2016 01:39:34 -0800 (PST) X-AuditID: c1b4fb30-c4bff700000054c8-4d-585113543aa7 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 0B.CD.21704.45311585; Wed, 14 Dec 2016 10:39:33 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 14 Dec 2016 10:39:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ItBYEylvcYeh8bAHi+AqyFHdvaQiOCsvk/UOxhT2UsA=; b=WId3SkJnDNpsqeED2t7Rf8OiTZsEuaP9KsLy8YHKCpKWp/CBSseKKPg51cAwftVcVkdLOiyEZkxBQzkJPq+W7r4Hyfl1v28mwxZakBlCcAR/we0CcivG4CzQGnNPyoEZX/CvEMNJ7Hz/VWl/du1PfUpOZQ/0671wcVBRZ0vkVew= Received: from VI1PR0701MB2733.eurprd07.prod.outlook.com (10.173.80.145) by VI1PR0701MB2734.eurprd07.prod.outlook.com (10.173.80.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Wed, 14 Dec 2016 09:39:30 +0000 Received: from VI1PR0701MB2733.eurprd07.prod.outlook.com ([10.173.80.145]) by VI1PR0701MB2733.eurprd07.prod.outlook.com ([10.173.80.145]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 09:39:31 +0000 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "rtcweb@ietf.org" , "sean+ietf@sn3rd.com" , "fluffy@iii.ca" , "ted.ietf@gmail.com" Thread-Topic: Review of W3C WebRTC Statistics API Thread-Index: AQHSVe33eeIRYxQP3EaFirYu7zz4Jg== Date: Wed, 14 Dec 2016 09:39:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stefan.lk.hakansson@ericsson.com; x-originating-ip: [192.176.1.95] x-ms-office365-filtering-correlation-id: 5710e685-6b8e-44d8-c8b6-08d424051adb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB2734; x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2734; 7:7eJERvEGkPhsSs0y6f6Yk/iutktuADSMfnLJTSsKfNXFL+WCRqVm+eaKEfJKGEUfkAZ0lX+WtRKll8mSWs6Y6eflDuvDIgvDeTD8YDJ9C6UOPCY5xxI7idZlP4YxK+XX1LIRJ4fjCN7ndNyv2CT11SbhL42X0dTPO9CNBC+SWeg7AQ9WzmXb0JPaeDS4YtB3oRpZmJ6fFi69V7XGq6kOT10SHVAHMJj0rUV3O+0ykRAlir6vVubO7jXJmqEP+ZlA/e1q+0NskRg0Jami+SjbwtHECTeCTFzl4ldbuO6iyBG8HKFGmVX9vXPCeXGgKUx6OTdkL9+K5jwiioDkfQ1E7NzeWcL+HirXoPI58a1OdrJpp0qYRjRHqg8jBNIWQ49aV34rg7R3swv6G+6MPkjmZgtEbnSnsfqmUDG8LlVAaGgGo0K5ssTBje+J1URMo1ijFoDxRxtGYdZmxAiAKvWp2Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:VI1PR0701MB2734; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2734; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39840400002)(39450400003)(39860400002)(39850400002)(39410400002)(199003)(189002)(7736002)(8676002)(5660300001)(2501003)(74316002)(106356001)(102836003)(7696004)(81156014)(3846002)(8936002)(81166006)(6436002)(6506006)(305945005)(76576001)(86362001)(39060400001)(77096006)(122556002)(5001770100001)(107886002)(2906002)(97736004)(38730400001)(3280700002)(54356999)(50986999)(101416001)(189998001)(105586002)(6116002)(33656002)(92566002)(66066001)(68736007)(9686002)(106116001)(2900100001)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2734; H:VI1PR0701MB2733.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 09:39:30.7428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2734 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUyM2K7jW6ocGCEwdd3fBYf1v9gtFj7r53d 4tKG1UwWjXPtHFg8ds66y+6xZMlPJo/L5z8yehw8yBjAEsVlk5Kak1mWWqRvl8CVcav/A2NB B0fF7ntT2RsY77N1MXJySAiYSPSsXcrSxcjFISSwjlHi1MZeRgjnBKPEys+7mUCqWAR6mSWW LZWDSMxkkujbvRCq6hSjxM7p11hBqtgEAiW27lsANldEYAmjxPepFSC2sICOxM4lq1gg4oYS s3+eY4ew9ST67x9mgdigKrGyvxPI5uDgFUiQ2LfRGyTMKCAm8f3UGrAjmAXEJW49mc8EcbaA xJI955khbFGJl4//sYK0MgokS0xvdYMIK0h0HngDVe4rMXHOJ0YI21/iy5MV7CDnSwj0sUi8 uHCfBSKRL3Hp2kYo21piQesmZqgiJon/X2ZDLZORmHlvHxNE4hCrxL7p68GeERJIlVi+tpUR 4mEpibtXOqFsGYkXd/ayQnygJ3Fj6hQ2CFtbYtnC18wTGNVnIXluFpKyWUjKQGxeAUGJkzOf sCxgZFnFKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJEZhaDm75bbCD8eVzx0OMAhyMSjy8Bq4B EUKsiWXFlbmHGCU4mJVEeCMFAiOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKa nZpakFoEk2Xi4JRqYMxI7Doke6rl7G9tk14vUea2PelWpY5bP3x9n74gvnNOwqLVc1b1PmNs mNh6wr+2pi/YpcKZLXaf7aEP/FNVT1y9evR8tZLXCpfpUd3Fbia/+X7sYZt/12tOtRWTjWAy d2j0p8tb8w6IpTc+2biiMJ/LucrToO6wVeeeDmvnrdoG65+9V1L2UWIpzkg01GIuKk4EAAXO 2RcpAwAA Archived-At: Subject: [rtcweb] Review of W3C WebRTC Statistics API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 09:39:37 -0000 Dear RTCWeb Working Group,=0A= =0A= The WebRTC Working Group is working toward publishing its WebRTC =0A= Statistics API to Candidate Recommendation and is thus seeking review =0A= from a variety of groups on the document:=0A= =0A= https://www.w3.org/TR/2016/WD-webrtc-stats-20161214/=0A= =0A= We are particularly interested to get feedback on whether the set of =0A= identified statics are sufficient and necessary to monitor a =0A= browser-based WebRTC service.=0A= =0A= We of course also welcome feedback on any other aspect of the specification= .=0A= =0A= We would appreciate to receive feedback before January 30, 2017. We hope = =0A= to transition request to Candidate Recommendation later in that quarter.=0A= =0A= If you have any comments, we prefer you submit them as Github issues:=0A= https://github.com/w3c/webrtc-stats/issues=0A= =0A= Alternatively, you can send your comments by email to public-webrtc@w3.org.= =0A= =0A= Thanks,=0A= =0A= For the WebRTC chairs,=0A= Stefan H=E5kansson=0A= From nobody Fri Dec 16 09:06:25 2016 Return-Path: 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 0C1381279EB for ; Fri, 16 Dec 2016 09:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 yzF9E_pd7D72 for ; Fri, 16 Dec 2016 09:06:20 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 0E706129AE9 for ; Fri, 16 Dec 2016 09:06:16 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id d128so40650763ybh.2 for ; Fri, 16 Dec 2016 09:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=D2zmDjMhGjHyH8GpyDq61sV2LVNyOFrU7pz/z/iFZPY=; b=08eT/sRZQDILPVtNG2moS+GNCLkrWDQGkkT2LhcavelSvPwEiX9u+hIu5hgW9hbFUx Gm1L98gQd/IWJpgmnT+Q0SEla5rhZo6YCFOqRQ5EdfXQFb7tWPGj/DXQSCnbQWZSahqH 6tAWjtX0fi14JzWd/EDrJeS4pyLi/vRxdzTJEvQvzL+tLVQy0BL0S1XujKEAcy0AMGnr U843/oMsR4hFm4r0lGzkw3c+i9D7nlB7kt64IP+BV0l8l5gPIsDyrrySJh4YtFzgMvLq 9y2/lJXVV6dsQIv4DXlykSC3I5rMcxzrV+lIWNnjxCQ0w72d5TM+um6jQXx8RJrRcPRv 0YJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=D2zmDjMhGjHyH8GpyDq61sV2LVNyOFrU7pz/z/iFZPY=; b=gF9ZGrg511RGj3XKUUJNGCX2NZLyhdFrjgMeY26aZryjajyFL2P+xeGP9nbxtVIIjE WMEe12V3EabL4VkbrCUs4Kv5jV1ylyk9A2618+NgTpKTD6fxFd5jfRSFLrBv7TCuG2si psj4t9bxJZmYRHmb7ssWzAe9wu/JIZXDJjlv7DSFEzY5kuBT+UYopMhxM87AiexNWTuf uhREkr0AQWitxW8myaJqZWbMACeTnm5R2TEOxXpqkl77gzxpGE+jGztyUpB8pO/jCaFd Of5wAedtCianRUe0kiRK8ff09LmJEDfYoxrZ2VS/yqQlRVm1PDvoywARtZzAUoJsNAb8 ePig== X-Gm-Message-State: AIkVDXJxrCXtEaIJpE2OtpbR14Gf7XQeCeTwUYPUQyNHvmYFj6hsvfGTNiULanoG+pMldQDEU2OGz420tZc6RQ== X-Received: by 10.37.160.41 with SMTP id x38mr3089084ybh.64.1481907975177; Fri, 16 Dec 2016 09:06:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Fri, 16 Dec 2016 09:05:34 -0800 (PST) From: Eric Rescorla Date: Fri, 16 Dec 2016 09:05:34 -0800 Message-ID: To: "rtcweb@ietf.org" , mmusic WG Content-Type: multipart/alternative; boundary=94eb2c1a06507380480543c9966c Archived-At: Subject: [rtcweb] JSEP Issue #394: What appears in m= lines. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 17:06:22 -0000 --94eb2c1a06507380480543c9966c Content-Type: text/plain; charset=UTF-8 https://github.com/rtcweb-wg/jsep/issues/394 Magnus writes: > > > For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ > > RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of > > these two profiles for each media m= line they produce in an offer. > > Do I understand this correct, we are requiring support for the > "TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports the > optional to support ICE TCP, they can indicate it, and any WebRTC endpoint > will accept it, even if that is just one option? I do know that different > profiles are a negotiation issue. But, wouldn't it be more reasonable in > this case to use UDP/TLS/RTP/SAVPF in all cases where one offer any > candidates that also use UDP? And only use TCP/DTLS/RTP/SAVPF in cases only > TCP candidates are signalled, thus not forcing TCP/DTLS/RTP/SAVPF onto > clients that doesn't support it?" We could certainly do this, but it seems to perpetuate the idea that the TCP/UDP distinction is meaningful here, which seems like the opposite direction from the one we are going in (see the mmusic minutes around the topic Non-Supported Transport in m- line). See also the note below in this paragraph about either profile being consistent with either transport. I think it would be fine to relax the requirement that implementations *support* both UDP and TCP, but requiring them to conditionally use one or the other depending on whether they have UDP candidates seems like it's really going to impose a lot of pain on implementors for no good reason, in part because you don't necessarily know at the time of offer generation what you will have. Consider the case where you are only offering relayed and srflx candidates. At the time of generation, you don't know if you will be able to get a UDP candidate, because you might be behind a firewall that blocks UDP and your TURN server might be down. If we make any change, I think it should just be to relax the requirement to support TCP and then tell people to ignore the first field here in favor of the candidate lines. -Ekr --94eb2c1a06507380480543c9966c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

h= ttps://github.com/rtcweb-wg/jsep/issues/394

Magnus w= rites:

> =C2=A0 =C2=A0<= span style=3D"color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemf= ont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji= ","segoe ui emoji","segoe ui symbol"">For media m= =3D sections, JSEP endpoints MUST support both the "UDP/TLS/
> =C2=A0 =C2=A0RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profi= les and MUST indicate one of
> =C2=A0 =C2=A0 these two profiles for e= ach media m=3D line they produce in an offer.

=C2=A0

Do I understand this = correct, we are requiring support for the "TCP/DTLS/RTP/SAVPF" pr= oto so that in cases an endpoint supports the optional to support ICE TCP, = they can indicate it, and any WebRTC endpoint will accept it, even if that = is just one option? I do know that different profiles are a negotiation iss= ue. But, wouldn't it be more reasonable in this case to use UDP/TLS/RTP= /SAVPF in all cases where one offer any candidates that also use UDP? And o= nly use TCP/DTLS/RTP/SAVPF in cases only TCP candidates are signalled, thus= not forcing TCP/DTLS/RTP/SAVPF onto clients that doesn't support it?&q= uot;

We could certainly do this, but it seems t= o perpetuate the idea that the TCP/UDP distinction is

meaningful here, which seems like the opposite direc= tion from the one we are going in (see

the mmusic minutes around the topic=C2=A0Non-Supported Transport in m- l= ine). See also the note below in this paragraph about either profile being = consistent with either transport.

I think it would= be fine to relax the requirement that implementations *support* both UDP a= nd TCP, but requiring them to conditionally use one or the other depending = on whether they have UDP candidates seems like it's really going to imp= ose a lot of pain on implementors for no good reason, in part because you d= on't necessarily know at the time of offer generation what you will hav= e. Consider the case where you are only offering relayed and srflx candidat= es. At the time of generation, you don't know if you will be able to ge= t a UDP candidate, because you might be behind a firewall that blocks UDP a= nd your TURN server might be down.

If we make a= ny change, I think it should just be to relax the requirement to support TC= P and then tell people to ignore the first field here in favor of the candi= date lines.

-Ekr

=C2=A0

<= br>

--94eb2c1a06507380480543c9966c-- From nobody Wed Dec 21 12:04:31 2016 Return-Path: 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 832E2129521 for ; Wed, 21 Dec 2016 12:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 C3r9aPxR5OYA for ; Wed, 21 Dec 2016 12:04:28 -0800 (PST) Received: from brc1.unina.it (antispam.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0937129430 for ; Wed, 21 Dec 2016 12:04:27 -0800 (PST) X-ASG-Debug-ID: 1482350663-05ce375ce7b70b30001-4f8tJD Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id 7jWCViz07j6iooCe (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 21 Dec 2016 21:04:24 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [192.168.1.66] (93-44-65-253.ip96.fastwebnet.it [93.44.65.253]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id uBLK4MKT002504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Dec 2016 21:04:23 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_5EAF2E2D-149F-4F5D-9DC2-D8B3907790A3" Message-Id: X-ASG-Orig-Subj: Call for papers on WebRTC standardization status Date: Wed, 21 Dec 2016 21:04:23 +0100 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1482350663 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35298 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [rtcweb] Call for papers on WebRTC standardization status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 20:04:30 -0000 --Apple-Mail=_5EAF2E2D-149F-4F5D-9DC2-D8B3907790A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello everybody, on behalf of the guest editors team, I would like to draw your attention = to this call for papers of the Communications Standards Magazine, which = is entirely dedicated to WebRTC. = http://www.comsoc.org/comstandardsmag/cfp/real-time-communications-web-cur= rent-achievements-future-perspectives = We never post CFPs on this mailing list; though, we thought this was a = worthwhile exception, given the topic and the specific type of magazine. Please bear with me if you believe this was not the case. Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_5EAF2E2D-149F-4F5D-9DC2-D8B3907790A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hello everybody,

on behalf of the guest editors team, I = would like to draw your attention to this call for papers of the = Communications Standards Magazine, which is entirely dedicated to = WebRTC.

http://www.comsoc.org/comstandardsmag/cfp/real-time-communicati= ons-web-current-achievements-future-perspectives

We never = post CFPs on this mailing list; though, we thought this was a worthwhile = exception, given the topic and the specific type of magazine.

Please bear with me if = you believe this was not the case.

Cheers,

Simon

= = _\\|//_

= = = ( O-O )

= ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

= = = Simon Pietro Romano

= Universita' di = Napoli Federico II

= Computer Engineering = Department

= Phone: +39 081 7683823 -- Fax: +39 081 7683816

= = e-mail: spromano@unina.it

<<Molti mi = dicono che lo scoraggiamento =C3=A8 l'alibi degli

= idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.

= = oooO

~~~~~~~~~~~~~~~~~~~~~~~( = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

= = \ ( ( = )

= = = \_) ) /

= = = = (_/

= --Apple-Mail=_5EAF2E2D-149F-4F5D-9DC2-D8B3907790A3-- From nobody Thu Dec 22 06:32:07 2016 Return-Path: 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 634B0129404 for ; Thu, 22 Dec 2016 06:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 56oez6wqK3pf for ; Thu, 22 Dec 2016 06:32:03 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6E6129483 for ; Thu, 22 Dec 2016 06:32:02 -0800 (PST) X-AuditID: c1b4fb3a-854f998000005d1c-f7-585be3e0cab4 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 3B.9F.23836.0E3EB585; Thu, 22 Dec 2016 15:32:00 +0100 (CET) Received: from ESESSMB309.ericsson.se ([169.254.9.154]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0319.002; Thu, 22 Dec 2016 15:32:26 +0100 From: Magnus Westerlund To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: Re: [rtcweb] WGLC: draft-ietf-rtcweb-overview Thread-Index: AdJcXz5Jo1NeLpwvQV2mLzJioZnkfA== Date: Thu, 22 Dec 2016 14:32:26 +0000 Message-ID: <52E4A8FC978E0241AE652516E24CAF001E483F59@ESESSMB309.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_52E4A8FC978E0241AE652516E24CAF001E483F59ESESSMB309erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7nO6Dx9ERBhcajS2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGV8u7CaveD2dMaKC835DYzbWxm7GDk5JARM JDrW3GfvYuTiEBJYxyhxYdYHRghnCaPEq/5zzCBVbAIWEjd/NLKB2CICwRK9z9+DdQsLmEl8 mXSVBSJuLTHhL0yNnsS+w5fBbBYBVYmjl1+wgti8Ar4Sj3auA+tlFJCVuP/9Hlgvs4C4xK0n 85kgLhKQWLLnPDOELSrx8vE/VghbUaL9aQMjRH2+xJYpp5ghZgpKnJz5hGUCo+AsJKNmISmb haQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PL Sy3ZxAiMiYNbflvtYDz43PEQowAHoxIP74cZURFCrIllxZW5hxglOJiVRHg334mOEOJNSays Si3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNTqoFR9Kb8jtfpC5k/KPkJ 3fGznMBj3SdmWPQ9QypZYrrOqaZqLYY7YRmFzqHHTghsex9nZCe5ZMMqz38pp9nqsi9x3/B6 K2z+en7mhHtG6zXD3Z5WbIrqOlG4g6GIo0v7sUOHc+7ubaxrDvyUV7518nHv0cZbu63UDLdH rT1imSj0ZdWRfIaABYFKLMUZiYZazEXFiQATvtP8hQIAAA== Archived-At: Subject: Re: [rtcweb] WGLC: draft-ietf-rtcweb-overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:32:05 -0000 --_000_52E4A8FC978E0241AE652516E24CAF001E483F59ESESSMB309erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Sorry in the delay in responding. Den 2016-12-09 kl. 16:31, skrev Harald Alvestrand: > Thank you for the review! > > Den 09. des. 2016 15:35, skrev Magnus Westerlund: >> Hi, >> >> I have reviewed the overview document and have the following comments: >> >> 1. Section 1: >> >> As the available bandwidth has increased, and as processors an other >> hardware has become ever faster, the barriers to participation have >> decreased, and it has become possible to deliver a satisfactory >> experience on commonly available computing hardware. >> >> >> "processors an other" i guess it should say "and" >> >> 2. Section 2.2: >> >> o A Javascript API specification, done in the W3C >> [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628] >> >> >> "A"? Shouldn't this say a "A set of Javascript API specifications, ..." >> as there are multiple APIs? I know such reformulation would impact the >> next couple of paragraphs at least. But, maybe some other way of >> acknowledging the fact that there are multiple API parts? > > Actually both the IETF effort and the W3C effort consists of lots of > moving parts. Would "A Javascript API, defined by a set of > specifications [cite]" scan better? Yes, that would at least not create a clash between citations and text. > >> >> 3. Section 2.2: >> >> "and the Javascript API defined above." >> >> I see a issue with pointing to the specific API specs above. This as if >> there are other API relatizations defined, even if compatible they are >> not considered WebRTC Browser. I would suggest, simply drop "defined >> above". > > > Right, that's what I intended to say, and what I think the WG wanted. > Unless we can point to a specific API, there's no way to differentiate > between a WebRTC browser and a WebRTC non-browser. > > For a currently interesting example - Edge implements the ORTC API, > which they believe is implementing the WebRTC protocols, and offering an > API to them. But it is not the WebRTC API. > > So at the moment, I'd want to claim that Edge is a WebRTC non-browser. > Edge with the 1.0 shim would be a WebRTC browser - and when Edge > implements the WebRTC 1.0 natively, Edge would turn into a WebRTC browser= . > > There are also lots of devices using a C++ API to WebRTC-implementing > libraries. These cannot make the API security guarantees that the > rtcweb-security drafts depend on for their design. So I consider it > appropriate to classify them as WebRTC non-browsers, too. > > If this isn't the consensus of the group, we can change it. But it is > what I intended to write. Okay, I understand your reasoning. I will not at all persist here. > >> >> 4. On the completeness of the specification >> >> Looking at the current set of RTCWeb WG documents, one sees that there >> are some that are not referenced: >> >> draft-ietf-rtcweb-alpn-04 >> draft-ietf-rtcweb-fec-04 >> draft-ietf-rtcweb-ip-handling-02 > > All of these are indirectly referenced. ALPN is referenced by > -transport-, and FEC is referenced by -rtp-usage. ip-handling is > referenced by -jsep-. > > Is it necessary to reference them directly? If so, where would you > suggest that the overview needs text that references them? > No, I think we are fine. I just looked at what was not included and then ca= tegorized them into the ones referenced somewhere, and the below that wasn'= t referenced at all. >> >> The above are referenced by mentioned documents >> >> draft-ietf-rtcweb-sdp-02 > > That document is only examples. I'm happy to have it only indirectly > referenced. Yes, and this appears to be an informative reference for JSEP isn't it? Merry Christmas and a Happy New Year Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_52E4A8FC978E0241AE652516E24CAF001E483F59ESESSMB309erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Sorry in the delay in respondin= g.

Den 2016-12-09 kl. 16:31, skrev Harald Alvestrand:

> Thank you for the review!<= o:p>

> Den 09. des. 2016 15:35, skrev Magnus Westerlun= d:

>> Hi,<= /p>

>> I have reviewed the ov= erview document and have the following comments:

>> 1. Section 1:

>> As t= he available bandwidth has increased, and as processors an other=

>> hard= ware has become ever faster, the barriers to participation have<= /span>

>> decr= eased, and it has become possible to deliver a satisfactory

>> expe= rience on commonly available computing hardware.

>> "processors an ot= her" i guess it should say "and"

>> 2. Section 2.2:

>> o&nb= sp; A Javascript API specification, done in the W3C

>> = ; [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628= ]

>> "A"? Shouldn= 't this say a "A set of Javascript API specifications, ..."<= /o:p>

>> as there are multiple = APIs? I know such reformulation would impact the

>> next couple of paragra= phs at least. But, maybe some other way of

>> acknowledging the fact= that there are multiple API parts?

> Actually both the IETF eff= ort and the W3C effort consists of lots of

> moving parts. Would "= A Javascript API, defined by a set of

> specifications [cite]"= ; scan better?

Yes, that would at least not cr= eate a clash between citations and text.

>> 3. Section 2.2:

>> "and the Javascri= pt API defined above."

>> I see a issue with poi= nting to the specific API specs above. This as if

>> there are other API re= latizations defined, even if compatible they are

>> not considered WebRTC = Browser. I would suggest, simply drop "defined

>> above".

> Right, that's what I inten= ded to say, and what I think the WG wanted.

> Unless we can point to a s= pecific API, there's no way to differentiate

> between a WebRTC browser a= nd a WebRTC non-browser.

> For a currently interestin= g example - Edge implements the ORTC API,

> which they believe is impl= ementing the WebRTC protocols, and offering an

> API to them. But it is not= the WebRTC API.

> So at the moment, I'd want= to claim that Edge is a WebRTC non-browser.

> Edge with the 1.0 shim wou= ld be a WebRTC browser - and when Edge

> implements the WebRTC 1.0 = natively, Edge would turn into a WebRTC browser.

> There are also lots of dev= ices using a C++ API to WebRTC-implementing

> libraries. These cannot ma= ke the API security guarantees that the

> rtcweb-security drafts dep= end on for their design. So I consider it

> appropriate to classify th= em as WebRTC non-browsers, too.

> If this isn't the consensu= s of the group, we can change it. But it is

> what I intended to write.<= o:p>

Okay, I understand your reasoni= ng. I will not at all persist here.

>> 4. On the completeness= of the specification

>> Looking at the current= set of RTCWeb WG documents, one sees that there

>> are some that are not = referenced:

>> draft-ietf-rtcweb-alpn= -04

>> draft-ietf-rtcweb-fec-= 04

>> draft-ietf-rtcweb-ip-handling-02=

> All of these are indirectl= y referenced. ALPN is referenced by

> -transport-, and FEC is re= ferenced by -rtp-usage. ip-handling is

> referenced by -jsep-.=

> Is it necessary to referen= ce them directly? If so, where would you

> suggest that the overview = needs text that references them?

No, I think we are fine. I just= looked at what was not included and then categorized them into the ones re= ferenced somewhere, and the below that wasn’t referenced at all.

>> The above are referenc= ed by mentioned documents

>> draft-ietf-rtcweb-sdp-= 02

> That document is only exam= ples. I'm happy to have it only indirectly

> referenced.

Yes, and this appears to be an = informative reference for JSEP isn’t it?

Merry Christmas and a Happy New= Year

Magnus Westerlund

-------------------------------= ---------------------------------------

Services, Media and Network fea= tures, Ericsson Research EAB/TXM

-------------------------------= ---------------------------------------

Ericsson AB &n= bsp; = ; | Phone +46 10 7148287

F=E4r=F6gatan 6 &nbs= p; &= nbsp; | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | m= ailto: magnus.westerlund@ericsson.com

----------------------------------------------------= ------------------

--_000_52E4A8FC978E0241AE652516E24CAF001E483F59ESESSMB309erics_-- From nobody Thu Dec 22 07:16:40 2016 Return-Path: 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 511FC12955B; Thu, 22 Dec 2016 07:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Nb7QmGQD7QkT; Thu, 22 Dec 2016 07:16:33 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CA512943B; Thu, 22 Dec 2016 07:16:32 -0800 (PST) X-AuditID: c1b4fb3a-45bff70000005d1c-c8-585bee4dd501 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id FF.A8.23836.D4EEB585; Thu, 22 Dec 2016 16:16:30 +0100 (CET) Received: from ESESSMB309.ericsson.se ([169.254.9.154]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Thu, 22 Dec 2016 16:15:28 +0100 From: Magnus Westerlund To: Eric Rescorla , "rtcweb@ietf.org" , "mmusic WG" Thread-Topic: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. Thread-Index: AdJcYFcrE3U1P1RsTNSE+iTBQB43vA== Date: Thu, 22 Dec 2016 15:15:53 +0000 Message-ID: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_52E4A8FC978E0241AE652516E24CAF001E483F95ESESSMB309erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2K7tK7fu+gIg+5eXYsVr8+xW0xd/pjF Yu2/dnYHZo8lS34yeUx+3MYcwBTFZZOSmpNZllqkb5fAlfFt/U+mglstjBX3u46yNDA+Kupi 5OSQEDCR+Ns+kRXEFhJYxyjxZwE3hL2EUWLOCj4Qm03AQuLmj0a2LkYODhGBNInrE21BwsIC DhLHdq5lgQi7SjyYwgkSFhHQk1h4+DgjiM0ioCrxaelJNhCbV8BX4vL5JUwgNqOArMT97/dY QGxmAXGJW0/mM0FcIyCxZM95ZghbVOLl43+sELaiRPvTBkaI+nyJpi29UDMFJU7OfMIygVFw FpJRs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZVzGKFqcWF+emGxnppRZl JhcX5+fp5aWWbGIERsXBLb+tdjAefO54iFGAg1GJh/fDjKgIIdbEsuLK3EOMEhzMSiK8L19F RwjxpiRWVqUW5ccXleakFh9ilOZgURLnNVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAWDp9Ae// NquCeb9lOLzm/glc+HYRw61WRY7ct8diejsdjvJv3qPsHBNbbekrO5s9lkHtW3GPUxuXcrez Rcb8jWFph13ZS87PDy9QO3POOa1QeemEPUfFb03i/Lzw6alThQxF/80/TnFmrbflrJmzbIZI SNG+59w/PGa+36J44sG3AuU62egaJZbijERDLeai4kQAaWbkWIYCAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 15:16:35 -0000 --_000_52E4A8FC978E0241AE652516E24CAF001E483F95ESESSMB309erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, See inline. Den 2016-12-16 kl. 18:05, skrev Eric Rescorla: > https://github.com/rtcweb-wg/jsep/issues/394 > > Magnus writes: > > > For media m=3D sections, JSEP endpoints MUST support both the > "UDP/TLS/ > > RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate > one of > > these two profiles for each media m=3D line they produce in an > offer. > > > > Do I understand this correct, we are requiring support for the > "TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports the > optional to support ICE TCP, they can indicate it, and any WebRTC > endpoint will accept it, even if that is just one option? I do know > that different profiles are a negotiation issue. But, wouldn't it be > more reasonable in this case to use UDP/TLS/RTP/SAVPF in all cases > where one offer any candidates that also use UDP? And only use > TCP/DTLS/RTP/SAVPF in cases only TCP candidates are signalled, thus > not forcing TCP/DTLS/RTP/SAVPF onto clients that doesn't support it?" > > > We could certainly do this, but it seems to perpetuate the idea that the > TCP/UDP distinction is > > meaningful here, which seems like the opposite direction from the one we > are going in (see > > the mmusic minutes around the topic Non-Supported Transport in m- line). > See also the note below in this paragraph about either profile being > consistent with either transport. > > > I think it would be fine to relax the requirement that implementations > *support* both UDP and TCP, but requiring them to conditionally use one > or the other depending on whether they have UDP candidates seems like > it's really going to impose a lot of pain on implementors for no good > reason, in part because you don't necessarily know at the time of offer > generation what you will have. Consider the case where you are only > offering relayed and srflx candidates. At the time of generation, you > don't know if you will be able to get a UDP candidate, because you might > be behind a firewall that blocks UDP and your TURN server might be down. > Okay, I agree that having any rules for what you should offer here based on= what the actual outcome is not the best idea here. I think the rules shoul= d be based on capability and intent. So if you only are going offer TCP can= didates, then you clearly should use TCP/..., If you have no implementation= for TCP candidates then you clearly offers UDP/.... If the implementations= intention is to offer both if they are determined, then one has a choice. = In the context of WebRTC to WebRTC this does would not matter, as long as t= he counter part has the rule to accept either. However if you support both,= if one you uses UDP, then it also doesn't matter for implementations suppo= rting only UDP, they will accept it. If the incoming offer is TCP/... then = with the clarifications you propose below a non TCP candidate supporting im= plementations answering can't fail immediately. It will have to wait to see= if there if there ever shows up any UDP candidates. Gateways to legacy devices will independently have issues, as what they nee= d to use will depend on the far sides capabilities and the actual set of ca= ndidates. > > If we make any change, I think it should just be to relax the > requirement to support TCP and then tell people to ignore the first > field here in favor of the candidate lines. > So, if I interpret the above, I would say: Set the PROTO to UDP/... and on = reception ignore the TCP/UDP part of the PROTO string, only looking at cand= idates. That is very close to my amended suggestion. The only addition I ha= ve, is that if an implementation will not include any UDP candidates, only = TCP one, then it shall use TCP. We should have defined ICE/DTLS/RTP/SAVPF to avoid this issue. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_52E4A8FC978E0241AE652516E24CAF001E483F95ESESSMB309erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

See inline.

Den 2016-12-16 kl. 18:05, skrev Eric Rescorla:<= /o:p>

> https://github.com/rtcweb-wg/jsep/issues/394

> Magnus writes:<= /span>

> &g= t; For media m=3D sections, JSEP endpoints MUST support b= oth the

> &q= uot;UDP/TLS/

> &g= t; RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" pro= files and MUST indicate

> on= e of

> &g= t; these two profiles for each media m=3D line they= produce in an

> of= fer.

> Do= I understand this correct, we are requiring support for the

> &q= uot;TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports th= e

> op= tional to support ICE TCP, they can indicate it, and any WebRTC<= /span>

> en= dpoint will accept it, even if that is just one option? I do know

> th= at different profiles are a negotiation issue. But, wouldn't it be

> mo= re reasonable in this case to use UDP/TLS/RTP/SAVPF in all cases=

> wh= ere one offer any candidates that also use UDP? And only use

> TC= P/DTLS/RTP/SAVPF in cases only TCP candidates are signalled, thus

> no= t forcing TCP/DTLS/RTP/SAVPF onto clients that doesn't support it?"

> We could certainly do this= , but it seems to perpetuate the idea that the

> TCP/UDP distinction is

> meaningful here, which see= ms like the opposite direction from the one we

> are going in (see

> the mmusic minutes around = the topic Non-Supported Transport in m- line).

> See also the note below in= this paragraph about either profile being

> consistent with either tra= nsport.

> I think it would be fine t= o relax the requirement that implementations

> *support* both UDP and TCP= , but requiring them to conditionally use one

> or the other depending on = whether they have UDP candidates seems like

> it's really going to impos= e a lot of pain on implementors for no good

> reason, in part because yo= u don't necessarily know at the time of offer

> generation what you will h= ave. Consider the case where you are only

> offering relayed and srflx= candidates. At the time of generation, you

> don't know if you will be = able to get a UDP candidate, because you might

> be behind a firewall that = blocks UDP and your TURN server might be down.

Okay, I agree that having any r= ules for what you should offer here based on what the actual outcome is not= the best idea here. I think the rules should be based on capability and in= tent. So if you only are going offer TCP candidates, then you clearly should use TCP/…, If you have no im= plementation for TCP candidates then you clearly offers UDP/…. If the= implementations intention is to offer both if they are determined, then on= e has a choice. In the context of WebRTC to WebRTC this does would not matter, as long as the counter part has the rul= e to accept either. However if you support both, if one you uses UDP, then = it also doesn’t matter for implementations supporting only UDP, they = will accept it. If the incoming offer is TCP/… then with the clarifications you propose below a non TCP ca= ndidate supporting implementations answering can’t fail immediately. = It will have to wait to see if there if there ever shows up any UDP candida= tes.

Gateways to legacy devices will= independently have issues, as what they need to use will depend on the far= sides capabilities and the actual set of candidates.

> If we make any change, I t= hink it should just be to relax the

> requirement to support TCP= and then tell people to ignore the first

> field here in favor of the= candidate lines.

So, if I interpret the above, I= would say: Set the PROTO to UDP/… and on reception ignore the TCP/UD= P part of the PROTO string, only looking at candidates. That is very close = to my amended suggestion. The only addition I have, is that if an implementation will not include any UDP candidates, = only TCP one, then it shall use TCP.

We should have defined ICE/DTLS= /RTP/SAVPF to avoid this issue.

Cheers

Magnus Westerlund

-------------------------------= ---------------------------------------

Services, Media and Network fea= tures, Ericsson Research EAB/TXM

-------------------------------= ---------------------------------------

Ericsson AB &n= bsp; = ; | Phone +46 10 7148287

F=E4r=F6gatan 6 &nbs= p; &= nbsp; | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | m= ailto: magnus.westerlund@ericsson.com

----------------------------------------------------= ------------------

--_000_52E4A8FC978E0241AE652516E24CAF001E483F95ESESSMB309erics_-- From nobody Thu Dec 22 09:31:38 2016 Return-Path: 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 14FF0129695 for ; Thu, 22 Dec 2016 09:31:32 -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 kBakRyehN594 for ; Thu, 22 Dec 2016 09:31:30 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 BF27812969B for ; Thu, 22 Dec 2016 09:31:29 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id a10so118513219ywa.3 for ; Thu, 22 Dec 2016 09:31:29 -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=q1FLDKS8Dvc9T1BKKvT8eB44QXVl/yhBQl3C2+yWHh4=; b=Vdgf0nGLdQB6riI1uHICu+c+7cvvyrp2MrSWDg+d5c3UqzAE7MaEqHulqIwujOWTuh S4ABeV7opEwwjDLxRGkXfLis5GDt5xv8V/OQ9K2VwlmjWI8OdEjl0BOZFfCZVuFewCrr thLZsMz84Vj5dblCr2uQH7VsmUFIe0y21HVKZD0+ezBq6tb3A84o80IXMC8jzNOrBqpM yMhW/XmqnagFgkPYpXPWrwTB93bfumjcCq2xZndD0saNbdATR9DIt6q9NTIscGrYnNSK pBDnkgseC7Pj5Zw/T4o6y8OlgNjYePBN83s+ljb1LWnQ9qcvWEXzwCAS7JcR+0O/69sU iiyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q1FLDKS8Dvc9T1BKKvT8eB44QXVl/yhBQl3C2+yWHh4=; b=ZoyZUneP8R3KHTArXBOgreqJGk0zUw+qsIDRBpbPg0qxtV/p006vWyRoS0Jl3AMPwD qtvjTTTPKo1KADxlegn2E4asV1+rTKtax2LGnqsvNFOH7f1cFi69VS0tdImqKmv96jl5 JCawXpSocQDpUwo0d6k52Gr7Ro3E7fx+8RPvVuFNi6tYEPDDHwhPmDF9cycHaFdheTyN HQv47cM2Ob6Xu97XZIi19zdHIuF2sDA8sPQDfWE2EchGYPPpG+OqoD8iyke6mORS/0/6 YIi7z9+kMOWxuHReF23iwmDNKXhmy+bSwHyEPQPKwYu6NgNaJwHlwNeIkbasldBRzBai 2PHg== X-Gm-Message-State: AIkVDXKvgpTLJ5rDM/lD6mVfWvWonIJ4gf1mWdtVL9BWde0bcOEWrKjmYthysj+4wkrJMLYsGvlsOiuvQrMGrQ== X-Received: by 10.129.125.215 with SMTP id y206mr8499840ywc.234.1482427888970; Thu, 22 Dec 2016 09:31:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Thu, 22 Dec 2016 09:30:48 -0800 (PST) In-Reply-To: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> From: Eric Rescorla Date: Thu, 22 Dec 2016 09:30:48 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11492dfaba7b15054442a35a Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 17:31:32 -0000 --001a11492dfaba7b15054442a35a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 22, 2016 at 7:15 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > > > See inline. > > > > Den 2016-12-16 kl. 18:05, skrev Eric Rescorla: > > > https://github.com/rtcweb-wg/jsep/issues/394 > > > > > > Magnus writes: > > > > > > > For media m=3D sections, JSEP endpoints MUST support both the > > > "UDP/TLS/ > > > > RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate > > > one of > > > > these two profiles for each media m=3D line they produce in a= n > > > offer. > > > > > > > > > > > > Do I understand this correct, we are requiring support for the > > > "TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports th= e > > > optional to support ICE TCP, they can indicate it, and any WebRTC > > > endpoint will accept it, even if that is just one option? I do know > > > that different profiles are a negotiation issue. But, wouldn't it b= e > > > more reasonable in this case to use UDP/TLS/RTP/SAVPF in all cases > > > where one offer any candidates that also use UDP? And only use > > > TCP/DTLS/RTP/SAVPF in cases only TCP candidates are signalled, thus > > > not forcing TCP/DTLS/RTP/SAVPF onto clients that doesn't support it= ?" > > > > > > > > > We could certainly do this, but it seems to perpetuate the idea that th= e > > > TCP/UDP distinction is > > > > > > meaningful here, which seems like the opposite direction from the one w= e > > > are going in (see > > > > > > the mmusic minutes around the topic Non-Supported Transport in m- line)= . > > > See also the note below in this paragraph about either profile being > > > consistent with either transport. > > > > > > > > > I think it would be fine to relax the requirement that implementations > > > *support* both UDP and TCP, but requiring them to conditionally use one > > > or the other depending on whether they have UDP candidates seems like > > > it's really going to impose a lot of pain on implementors for no good > > > reason, in part because you don't necessarily know at the time of offer > > > generation what you will have. Consider the case where you are only > > > offering relayed and srflx candidates. At the time of generation, you > > > don't know if you will be able to get a UDP candidate, because you migh= t > > > be behind a firewall that blocks UDP and your TURN server might be down= . > > > > > > > Okay, I agree that having any rules for what you should offer here based > on what the actual outcome is not the best idea here. I think the rules > should be based on capability and intent. So if you only are going offer > TCP candidates, then you clearly should use TCP/=E2=80=A6, > I'm going to push on this. If we've already agreed that mismatches are normal, why should we do that? Wouldn't it be better to just effectively deprecate this field? -Ekr If you have no implementation for TCP candidates then you clearly offers > UDP/=E2=80=A6. If the implementations intention is to offer both if they = are > determined, then one has a choice. In the context of WebRTC to WebRTC thi= s > does would not matter, as long as the counter part has the rule to accept > either. However if you support both, if one you uses UDP, then it also > doesn=E2=80=99t matter for implementations supporting only UDP, they will= accept > it. If the incoming offer is TCP/=E2=80=A6 then with the clarifications y= ou propose > below a non TCP candidate supporting implementations answering can=E2=80= =99t fail > immediately. It will have to wait to see if there if there ever shows up > any UDP candidates. > > > > Gateways to legacy devices will independently have issues, as what they > need to use will depend on the far sides capabilities and the actual set = of > candidates. > > > > > > > > If we make any change, I think it should just be to relax the > > > requirement to support TCP and then tell people to ignore the first > > > field here in favor of the candidate lines. > > > > > > > So, if I interpret the above, I would say: Set the PROTO to UDP/=E2=80=A6= and on > reception ignore the TCP/UDP part of the PROTO string, only looking at > candidates. That is very close to my amended suggestion. The only additio= n > I have, is that if an implementation will not include any UDP candidates, > only TCP one, then it shall use TCP. > > > > > > We should have defined ICE/DTLS/RTP/SAVPF to avoid this issue. > > > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > <+46%2010%20714%2082%2087> > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > <+46%2073%20094%2090%2079> > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > --001a11492dfaba7b15054442a35a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 22, 2016 at 7:15 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:

Hi,

=C2=A0

See inline.

=C2=A0

Den 2016-12-16 kl. 18:05, skrev Eric Rescorla:

> https://github.com/rtcweb-wg/jsep/issues/3= 94

>=C2=A0=

> Magnus writes:

>=C2=A0=

>=C2=A0=C2=A0=C2=A0=C2=A0 &g= t;=C2=A0=C2=A0=C2=A0 For media m=3D sections, JSEP endpoints MUST support b= oth the

>=C2=A0=C2=A0=C2=A0=C2=A0 &q= uot;UDP/TLS/

>=C2=A0=C2=A0=C2=A0=C2=A0 &g= t;=C2=A0=C2=A0=C2=A0 RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" pro= files and MUST indicate

>=C2=A0=C2=A0=C2=A0=C2=A0 on= e of

>=C2=A0=C2=A0=C2=A0=C2=A0 &g= t;=C2=A0=C2=A0=C2=A0=C2=A0 these two profiles for each media m=3D line they= produce in an

>=C2=A0=C2=A0=C2=A0=C2=A0 of= fer.

>=C2=A0=

>=C2=A0=

>=C2=A0=

>=C2=A0=C2=A0=C2=A0=C2=A0 Do= I understand this correct, we are requiring support for the<= /span>

>=C2=A0 =C2=A0=C2=A0=C2=A0&q= uot;TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports th= e

>=C2=A0=C2=A0=C2=A0=C2=A0 op= tional to support ICE TCP, they can indicate it, and any WebRTC

>=C2=A0=C2=A0=C2=A0=C2=A0 en= dpoint will accept it, even if that is just one option? I do know=

>=C2=A0=C2=A0=C2=A0=C2=A0 th= at different profiles are a negotiation issue. But, wouldn't it be

>=C2=A0=C2=A0=C2=A0=C2=A0 mo= re reasonable in this case to use UDP/TLS/RTP/SAVPF in all cases<= /u>

>=C2=A0=C2=A0=C2=A0=C2=A0 wh= ere one offer any candidates that also use UDP? And only use<= /span>

>=C2=A0=C2=A0=C2=A0=C2=A0 TC= P/DTLS/RTP/SAVPF in cases only TCP candidates are signalled, thus=

>=C2=A0 =C2=A0=C2=A0=C2=A0no= t forcing TCP/DTLS/RTP/SAVPF onto clients that doesn't support it?"= ;

>=C2=A0=

>=C2=A0=

> We could certainly do this= , but it seems to perpetuate the idea that the

> TCP/UDP distinction is<= /u>

>=C2=A0=

> meaningful here, which see= ms like the opposite direction from the one we

> are going in (see

>=C2=A0=

> the mmusic minutes around = the topic Non-Supported Transport in m- line).

> See also the note below in= this paragraph about either profile being

> consistent with either tra= nsport.

>=C2=A0=

>=C2=A0=

> I think it would be fine t= o relax the requirement that implementations

> *support* both UDP and TCP= , but requiring them to conditionally use one

> or the other depending on = whether they have UDP candidates seems like

> it's really going to i= mpose a lot of pain on implementors for no good

> reason, in part because yo= u don't necessarily know at the time of offer

> generation what you will h= ave. Consider the case where you are only

> offering relayed and srflx= candidates. At the time of generation, you

> don't know if you will= be able to get a UDP candidate, because you might

> be behind a firewall that = blocks UDP and your TURN server might be down.

>=C2=A0=

=C2=A0

Okay, I agree that = having any rules for what you should offer here based on what the actual ou= tcome is not the best idea here. I think the rules should be based on capab= ility and intent. So if you only are going offer TCP candidates, then you clearly should use TCP/=E2=80=A6,

I'm going to push on this. If = we've already agreed that mismatches are normal, why should we do that?= Wouldn't it be better to just effectively deprecate this field?

<= div>

-Ekr

=
If you have no implementation for TCP candidates then you clear= ly offers UDP/=E2=80=A6. If the implementations intention is to offer both = if they are determined, then one has a choice. In the context of WebRTC to WebRTC this does would not matter, as long as the counter part has the rul= e to accept either. However if you support both, if one you uses UDP, then = it also doesn=E2=80=99t matter for implementations supporting only UDP, the= y will accept it. If the incoming offer is TCP/=E2=80=A6 then with the clarifications you propose below a non TCP = candidate supporting implementations answering can=E2=80=99t fail immediate= ly. It will have to wait to see if there if there ever shows up any UDP can= didates.

=C2=A0

Gateways to legacy devices will= independently have issues, as what they need to use will depend on the far= sides capabilities and the actual set of candidates.

=C2=A0

>=C2=A0=

> If we make any change, I t= hink it should just be to relax the

> requirement to support TCP= and then tell people to ignore the first

> field here in favor of the= candidate lines.

>=C2=A0=

=C2=A0

So, if I interpret the a= bove, I would say: Set the PROTO to UDP/=E2=80=A6 and on reception ignore t= he TCP/UDP part of the PROTO string, only looking at candidates. That is ve= ry close to my amended suggestion. The only addition I have, is that if an implementation will not include any UDP candidates, = only TCP one, then it shall use TCP.

=C2=A0

=C2=A0

We should have defined ICE/DTLS= /RTP/SAVPF to avoid this issue. =C2=A0

=C2=A0

=C2=A0

Cheers
=C2=A0

Magnus Westerlund=

=C2=A0

------------------------------<= wbr>----------------------------------------

Services, Media and Network fea= tures, Ericsson Research EAB/TXM

------------------------------<= wbr>----------------------------------------

Ericsson AB=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | Phone=C2=A0 +46 10 7148287

F=C3=A4r=C3=B6gatan 6=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | m= ailto: = magnus.westerlund@ericsson.com

-----------------------------------------------= -----------------------

--001a11492dfaba7b15054442a35a--