From nobody Tue Jan 3 14:04:38 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E789E1299B6; Tue, 3 Jan 2017 14:04:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148348107694.27954.8880554217696760307.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 14:04:36 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 03 Jan 2017 22:04:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : SDP for the WebRTC Authors : Suhas Nandakumar Cullen Jennings Filename : draft-ietf-rtcweb-sdp-03.txt Pages : 107 Date : 2017-01-03 Abstract: The Web Real-Time Communication [WebRTC] working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism described in [RFC3264]. This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common WebRTC use-cases. This SDP examples provided in this document is still a work in progress, but it aims to align closest to the evolving standards work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 3 14:05:56 2017 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 64E3B1299B6 for ; Tue, 3 Jan 2017 14:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 1sSPUdn4FbSl for ; Tue, 3 Jan 2017 14:05:52 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 2CC201297B8 for ; Tue, 3 Jan 2017 14:05:52 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id c47so475462872qtc.2 for ; Tue, 03 Jan 2017 14:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Cjxy0/DZ6DQUwhJ67HS+BFyULiijKjX3YMfqPE1N0Nc=; b=DjMBbw5uI2WpEoIhZuzhSfDQ8ewoc7yOJOl4DfhpKRSl3KgzQlx3mrjDhfCaGFLzn1 ysDUNZS2ViyNuwOF+kJ8gvrQDEEOZCZq1Y3USr6E66S+ACx5SvMZpVih8VEFv4VNy6YE pmW6BWj3XhQP7P1s7xNaepImfxpRoogTllxztaIZbTL15DObvK36A6kc/R5Uq1PTu6zT pjy2o3jHy5FDy9FC1t5EfnpB6niMEBRzri3YHmOEXmVX0OHy0s8P0ro/e1FGzq8/Y1lL L2tphYqbULsU0jSvsVoVoFpmTmNsk1xGGsybcx5x7M9MEsuIZUQ2W3VW2yCDmbq+3FwH FVRA== 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; bh=Cjxy0/DZ6DQUwhJ67HS+BFyULiijKjX3YMfqPE1N0Nc=; b=Nmcthc02NRvhWk4eIeA2hQK2z0yJf3S6F3UOcSgCj1o6Y8vQfDi4kkYZNC33CvG0bf eNIW9zM202clUS8ZxUWd/7KOUoJtoCjCvu/qnQeNQZ8+dB1ZutEQkoMnwq9bXLthK/N+ QTk92weEU+RjJtUzfP7/3XTGEFg96/98vpkglxvG6trzy+AVtD3kFe51qZI+DPtcZMgU Jrr7SWi5G86NG03jRAPpoeg8UiWIS6vsYC1IYJ/GemadIeSfO116Ik3YeewDZMPHjovv /PQiiWBZwnjHNYJR5zzr5ShcV71FmgGogW16dGDkhUYcYIr8WyABkLsr74AJljZu68xW LM2A== X-Gm-Message-State: AIkVDXIUg5rC7lqTtaKTzkazBCWPDJdr93Sc3FPtKGumm60NGVKRvsLeM3AMYRX8tHtBxPyg3UsqQyGDxQv8YA== X-Received: by 10.237.58.138 with SMTP id o10mr58718839qte.76.1483481151216; Tue, 03 Jan 2017 14:05:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.50.36 with HTTP; Tue, 3 Jan 2017 14:05:50 -0800 (PST) In-Reply-To: <148348107694.27954.8880554217696760307.idtracker@ietfa.amsl.com> References: <148348107694.27954.8880554217696760307.idtracker@ietfa.amsl.com> From: Suhas Nandakumar Date: Tue, 3 Jan 2017 14:05:50 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a114114bc0ca7d9054537df1d Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-03.txt 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: Tue, 03 Jan 2017 22:05:54 -0000 --001a114114bc0ca7d9054537df1d Content-Type: text/plain; charset=UTF-8 Version -03 to avoid the draft from expiry while I am the middle of updates. I will follow with Version -04 once the updates are in. Thanks Suhas On Tue, Jan 3, 2017 at 2:04 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > of the IETF. > > Title : SDP for the WebRTC > Authors : Suhas Nandakumar > Cullen Jennings > Filename : draft-ietf-rtcweb-sdp-03.txt > Pages : 107 > Date : 2017-01-03 > > Abstract: > The Web Real-Time Communication [WebRTC] working group is charged to > provide protocol support for direct interactive rich communication > using audio, video and data between two peers' web browsers. With in > the WebRTC framework, Session Description protocol (SDP) [RFC4566] is > used for negotiating session capabilities between the peers. Such a > negotiation happens based on the SDP Offer/Answer exchange mechanism > described in [RFC3264]. > > This document provides an informational reference in describing the > role of SDP and the Offer/Answer exchange mechanism for the most > common WebRTC use-cases. > > This SDP examples provided in this document is still a work in > progress, but it aims to align closest to the evolving standards > work. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114114bc0ca7d9054537df1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Version -03 to avoid the draft from expiry while I am the = middle of updates. I will follow with Version -04 once the updates are in.<= div>
Thanks
Suhas

On Tue, Jan 3, 2017 at 2:04 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= SDP for the WebRTC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Suha= s Nandakumar
=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 Cullen Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-sdp-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 107
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-03

Abstract:
=C2=A0 =C2=A0The Web Real-Time Communication [WebRTC] working group is char= ged to
=C2=A0 =C2=A0provide protocol support for direct interactive rich communica= tion
=C2=A0 =C2=A0using audio, video and data between two peers' web browser= s.=C2=A0 With in
=C2=A0 =C2=A0the WebRTC framework, Session Description protocol (SDP) [RFC4= 566] is
=C2=A0 =C2=A0used for negotiating session capabilities between the peers.= =C2=A0 Such a
=C2=A0 =C2=A0negotiation happens based on the SDP Offer/Answer exchange mec= hanism
=C2=A0 =C2=A0described in [RFC3264].

=C2=A0 =C2=A0This document provides an informational reference in describin= g the
=C2=A0 =C2=A0role of SDP and the Offer/Answer exchange mechanism for the mo= st
=C2=A0 =C2=A0common WebRTC use-cases.

=C2=A0 =C2=A0This SDP examples provided in this document is still a work in=
=C2=A0 =C2=A0progress, but it aims to align closest to the evolving standar= ds
=C2=A0 =C2=A0work.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-rtcweb-sdp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcw= eb-sdp-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-rtcweb-sdp-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--001a114114bc0ca7d9054537df1d-- From nobody Wed Jan 4 10:59:29 2017 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 D9E62129991; Wed, 4 Jan 2017 10:59:28 -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 OJhFauav46Rl; Wed, 4 Jan 2017 10:59:25 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 0151B1296D6; Wed, 4 Jan 2017 10:59:24 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id i68so253966131uad.0; Wed, 04 Jan 2017 10:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LT9ahLTOpdZ4GEbZNpkoSGSzvKpEZb+A1ABnrwb7RPo=; b=DHY7jdKjgLJBUm19xK7dBSDREKsvTqUNRxq5CnH4KJ53Fsp4s/YnTO1lX1NGGitr+q kXVa3RVHHD5ziafuwV1iESx7YaFyOPKGa6G6p3ZzF3Pmz+lRT8N9i6v712AS/FVzM8FS DbCsSLoQ4euccYvH3Balm1g82yQA7E5xrQi/y9V83F+ZACxBS6rhK6g+etGz2xKIToLJ i1XGO3Ksal5ogZe2maXA+ugDOC8QpwIvZcyILMVh22yUjCakTSsDdqZGYqMXTLqgbcbw 7ViMMLYL1bl5y3PNHWy0nnpP3dAA0mps4LAWZZNr73zUjURpsfJghZdyBZrsv4NLeL34 mXGg== 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=LT9ahLTOpdZ4GEbZNpkoSGSzvKpEZb+A1ABnrwb7RPo=; b=hbCFZLMCidMh7MkCUdVD3X49nDPMqv03ddC9Xi+l5BZmZshhhdRsOmM2IN8cnLiM6o S7T/37Pqq7k863SJ2+oMMrRbgc/lKSasODrszKgBBK2SWUEWRrxc9X8ZhQaX/tvdNKXe mBFlGLK7kbCTQ2QTclHpHTVxcHoBfkXvKVdaVCt8rOv/YKg/zKgH5OSR4gMBz6WFcBM5 QafI1nBTwvz4hkus020Np4ZbV+AieCNug2Xt41TJcdRqFyn3tZxXbZ0OaRMqmcbp3VeT Or6zuqBj9QYQ39LBNaotzcTojvOFxzySALQeDtlvoicmr7Fzv/kQuXlanTX+KfXfXeM+ QLsQ== X-Gm-Message-State: AIkVDXL8FH7N5e4yWpljLisIOfoEjp9VKQZXffnVlwKbTW62OdAoPVFrNN8ccTNTmAlr9EXpMuaKjTOfC9yqkQ== X-Received: by 10.176.2.210 with SMTP id 76mr49993674uah.117.1483556363765; Wed, 04 Jan 2017 10:59:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.5 with HTTP; Wed, 4 Jan 2017 10:59:03 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 4 Jan 2017 10:59:03 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113dc310112fd105454962ed Archived-At: Cc: "mmusic \(E-mail\)" , Robin Raymond , 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: Wed, 04 Jan 2017 18:59:29 -0000 --001a113dc310112fd105454962ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would like to emphasize the importance of standardizing "routing rule" behavior at an appropriate level of detail. Developers are encountering interoperability problems and are filing bugs against implementations. To address the issues we are seeing, it is necessary to get to the level of detail in the JSEP-17 Section 6 text. On Fri, Dec 9, 2016 at 10:01 AM, Bernard Aboba wrote: > I agree with Eric and Cullen that a more explicit algorithm is needed. > The proposed text is not specific enough to resolve observed implementati= on > 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 agre= e > 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 wi= th > an implementation that declares SDP with non-unique PTs to be in error. > Another implementation fills a Payload Type table with a single value, wi= th > 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 ORT= C > API spec says to latch the SSRC on a Payload Type match and then remove t= he > 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 d= o > 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 sendin= g > RTCP packets to the wrong objects. Another implementation sorts the RTCP > reports as indicated in the proposed text - but has found that the requir= ed > 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 structur= e? >> >> -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 an= d >>> 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 t= his >>> 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 an= d BUNDLE >>> drafts] >>> > >>> > There=E2=80=99s been a lot of discussion on the lists, and at the mee= ting in >>> Seoul, around how RTP streams are mapped onto higher-level, application >>> 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 >>> > >>> >
>>> > 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 = to >>> > RtpReceiver objects. This allows each RTP stream to be associated >>> > with an RtpTransceiver. Further processing of the RTP stream can >>> > then be done at the RtpTransceiver level. This includes using >>> > RID 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 o= n >>> > 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 strea= ms >>> >> > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each = RTP >>> stream is >>> > identified by an SSRC value, and each RTP packet carries an SSR= C >>> 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 repor= t >>> on >>> > multiple RTP streams. >>> > >>> > In order to be able to process received RTP packets correctl= y >>> 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 o= f >>> the >>> > same RTP session and using the same address:port combination fo= r >>> > 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 associa= ted >>> 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 >>> value >>> > 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 payl= oad >>> 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 >>> values >>> > they will use for an RTP stream by using the SDP 'ssrc' attribu= te >>> > . >>> 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-sessio= n, >>> > 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 >>> answerer >>> > using the BUNDLE extension MUST support the mechanism defined i= n >>> >> > format=3D"default" pageno=3D"false" target=3D"sec-receiver-id"/= >, >>> where the >>> > offerer and answerer includes the identification-tag (provided >>> by the >>> > remote peer) associated with an "m=3D" line in the RTP Streams = and >>> 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 compoun= d RTCP >>> > packet can contain multiple RTCP SDES packets, and each RTCP SD= ES >>> > 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 >>> change >>> > mid-session if, for a given SSRC value, a different >>> identification-tag >>> > is provided in an RTP or RTCP packet. In that case these tables >>> are >>> > updated each time an RTP/RTCP packet containing a new mappings >>> from >>> > SSRC to identification-tag is received. Some considerations for >>> > avoiding update flaps are provided in Section 4.2.6 of >> > 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 >>> type >>> > value if it is unique to a single "m=3D" line), it MUST either >>> drop the >>> > RTP packets associated with the RTP stream, or process them in = an >>> > application specific manner, once non-stream specific processin= g >>> > (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 block= s >>> > 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 >> >> > --001a113dc310112fd105454962ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to emphasize the importance of standardizing = "routing rule" behavior at an appropriate level of detail.=C2=A0<= div>
Developers are encountering interoperability problems an= d are filing bugs against implementations.

To addr= ess the issues we are seeing, it is necessary to get to the level of detail= in the JSEP-17 Section 6 text.=C2=A0

On Fri, Dec 9, 2016 at 10:01 AM, Bernard Ab= oba <bernard.aboba@gmail.com> wrote:
I agree with Eric and Cullen that a more = explicit algorithm is needed.=C2=A0 The proposed text is not specific enoug= h to resolve observed implementation differences.=C2=A0
Cullen said:=C2=A0

"=C2=A0I= 9;d also like it be clear that MID 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 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. =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 e= nough detail and existing implementations differ in how they treat non-uniq= ue PTs. I am familiar with an implementation that declares SDP with non-uni= que PTs to be in error.=C2=A0 Another implementation fills a Payload Type t= able with a single value, with the value selected depending on whether SSRC= s 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 entr= y is not needed).=C2=A0 The ORTC API spec says to latch the SSRC on a Paylo= ad Type match and then remove the Payload Type table entry, but some implem= entations have found this leads to problems so they have foresaken either t= he latching or the PT removal (or both). =C2=A0
<= div id=3D"m_-6603285502549914630gmail-q_158e4a627b100c1c_1" class=3D"m_-660= 3285502549914630gmail-ajR m_-6603285502549914630gmail-h4">

Cullen said:=C2=A0

"I prefer the much more explicit algorithm part= icularly for the RTCP handling as implementors have a hard time figuring ou= t wha they need to do to process the RTCP."

[BA] I would also prefer that we have a more explicit algorith= m here, because we have seen very substantial implementation differences.= =C2=A0 One implementation I'm familiar with sends the RTCP packets to a= ll RtpSender and RtpReceiver objects.=C2=A0 While this is inefficient, it d= oes avoid sending RTCP packets to the wrong objects.=C2=A0 Another implemen= tation sorts the RTCP reports as indicated in the proposed text - but has f= ound that the required handling is so message-dependent that it leads to bu= gs (e.g. FIR and APP messages have caused issues in particular).=C2=A0 So t= his approach is more efficient, unless we are willing to get into detail on= every 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 structure used in = current JSEP is the better structure.

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

-Ekr

<= br>
On Fri, Dec 9, 2016 at 7:10 AM, Cullen Jennin= gs <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


--001a113dc310112fd105454962ed-- From nobody Thu Jan 5 10:57:22 2017 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 F2B49129624 for ; Thu, 5 Jan 2017 10:57:17 -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 VMlMnrvlOmpB for ; Thu, 5 Jan 2017 10:57:14 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 7093512960F for ; Thu, 5 Jan 2017 10:57:14 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id v81so248614512ywb.2 for ; Thu, 05 Jan 2017 10:57:14 -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=xEOJ78duhkQssgamMmKsIUFfi7KLFl19A8XRzvzH59w=; b=2JMebF7l91kddNMw/C6/n+k1OBXKp33/Qx8niCymZTE0CDMp/U7x/KL6kH4TQuX9RW RuZ+lPde2zKobIiqhEwWbGA49p/JrLkmRAKS14N8MTDzQ5TqJ7up+IE3/rSe88TNa0bI uLFBH2LAYQbK8Elv2hw0lPSZLCl2h3rW+2GIZmI886pchfbQ78gj2JG7Y6jqinHe/mqE 8VKe+L2X8WqjzpL3VWYM+G7Xhi2rrAcEKZiLykYvc/3ynrxjCv63U4Aao83kJWoDmLps MJ37so9zIR4ZsaQvs9RHSdw1i0GQ77+4pzZxncgbXXdhS4TVuwTwrLbcZasTmSRFdSdS q4Yg== 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=xEOJ78duhkQssgamMmKsIUFfi7KLFl19A8XRzvzH59w=; b=Zvx/HJWZycaduU1o2+ks9XpGEvcVQGmUMVDXAM8TCuLVV9TF1po5f9sHNxb57KnUpk ny8oWJohH/kjaiBlIFGD/ScP3SW7iTFOM+zRNY1E8ImGaZnN+1imxISnz3Y37MOvt8Hd E6GqAx6V8+uLFqS6JEm/yoyWuszCK0wxrnTN2I/ynHz1/rHpm/cXCgA+moUt611sKi77 CQuGCgeDLgTrYKWlVWNgmqKdSNYPt68OIJAB9kPowFq9mm1gSsduCXxboFoNzI99YqXR 3MuE6gk9aMynI4VWBkDjSimWwbjNX2VmCTby+XZDzlxL6w1DrmtdmkCKC2eQGwk+IAAY DRHA== X-Gm-Message-State: AIkVDXLGKQtNcFd/CjMt5cd6+POG9l2WbsGMfo1X/uq+KlLkNT6AIYz2RDX0zG7fGj9q1gkllbm7VVdlgg3i8g== X-Received: by 10.13.221.71 with SMTP id g68mr913668ywe.21.1483642633613; Thu, 05 Jan 2017 10:57:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Thu, 5 Jan 2017 10:56:33 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 5 Jan 2017 10:56:33 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=94eb2c075f7c26a5cb05455d78bf Archived-At: Cc: "mmusic \(E-mail\)" , Robin Raymond , 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: Thu, 05 Jan 2017 18:57:18 -0000 --94eb2c075f7c26a5cb05455d78bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This discussion seems to have stalled. I think it's clear that: - There's a strong (though not necessarily unanimous) feeling on the JSEP side that we need to specify an actual algorithm in the way that JSEP did. - Magnus and Colin feel like the algorithm in JSEP isn't adequate. Given that, I think the best way to proceed is to schedule a virtual interim to jointly produce text in algorithmic form that addresses Colin and Magnus's concerns. This approach worked well the last time we had some contentious wordsmithing (the rules around IP address handling). Chairs, do you think you could arrange this sometime soon so it doesn't hold up JSEP. -Ekr On Wed, Jan 4, 2017 at 10:59 AM, Bernard Aboba wrote: > I would like to emphasize the importance of standardizing "routing rule" > behavior at an appropriate level of detail. > > Developers are encountering interoperability problems and are filing bugs > against implementations. > > To address the issues we are seeing, it is necessary to get to the level > of detail in the JSEP-17 Section 6 text. > > On Fri, Dec 9, 2016 at 10:01 AM, Bernard Aboba > wrote: > >> I agree with Eric and Cullen that a more explicit algorithm is needed. >> The proposed text is not specific enough to resolve observed implementat= ion >> 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 pack= et >> drop should be restored. >> >> "I believe we agreed that if the PT was unique, then it would be used fo= r >> 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 w= ith >> an implementation that declares SDP with non-unique PTs to be in error. >> Another implementation fills a Payload Type table with a single value, w= ith >> 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 OR= TC >> 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 (o= r >> 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 sendi= ng >> RTCP packets to the wrong objects. Another implementation sorts the RTC= P >> reports as indicated in the proposed text - but has found that the requi= red >> 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 messag= e, >> 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 i= s >>> 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 = this >>>> text instead of just left as an option allowed but not really specifie= d 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 t= o 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 a= nd BUNDLE >>>> drafts] >>>> > >>>> > There=E2=80=99s been a lot of discussion on the lists, and at the me= eting in >>>> Seoul, around how RTP streams are mapped onto higher-level, applicatio= n >>>> meaningful, semantic roles. In particular, around how RTP streams map = onto >>>> JSEP objects for WebRTC. Magnus Westerlund and I would like to propose= the >>>> following updates to JSEP and BUNDLE to try to clarify the behaviour. >>>> > >>>> > Comments and feedback very welcome. >>>> > >>>> > Cheers, >>>> > Colin >>>> > >>>> > >>>> > >>>> > # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17 >>>> > >>>> >
>>>> > 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= to >>>> > RtpReceiver objects. This allows each RTP stream to be associated >>>> > with an RtpTransceiver. Further processing of the RTP stream can >>>> > then be done at the RtpTransceiver level. This includes using >>>> > RID 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 o= n >>>> > the MID values as described in >>>> > . If th= e >>>> > 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 stre= ams >>>> >>> > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each= RTP >>>> stream is >>>> > identified by an SSRC value, and each RTP packet carries an >>>> SSRC value >>>> > that is used to associate the packet with the correct RTP >>>> stream. RTCP >>>> > packets also uses SSRCs to identify on which RTP streams any >>>> report or >>>> > feedback relate to. Thus, an RTCP packet will commonly carry >>>> multiple >>>> > SSRC values, and might therefore be providing feedback or >>>> report on >>>> > multiple RTP streams. >>>> > >>>> > 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 th= e >>>> "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 f= or >>>> > 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 >>>> associated 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 >>>> value >>>> > 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 >>>> payload 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 >>>> values >>>> > they will use for an RTP stream by using the SDP 'ssrc' >>>> attribute >>>> > = . >>>> 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" lin= e >>>> using >>>> > the SSRC value associated with the RTP stream. In addition, th= e >>>> > 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 >>>> answerer >>>> > 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 >>>> by the >>>> > remote peer) associated with an "m=3D" line in the RTP Streams >>>> and in >>>> > RTCP SDES packets part of a BUNDLE group. >>>> > >>>> > The mapping from an SSRC to an identification-tag is carrie= d >>>> in >>>> > RTCP SDES packets or in RTP header extensions (>>> format=3D"default" >>>> > pageno=3D"false" target=3D"sec-receiver-id"/>). Since a compou= nd >>>> RTCP >>>> > packet can contain multiple RTCP SDES packets, and each RTCP >>>> SDES >>>> > packet can contain multiple chunks, an RTCP packet can contain >>>> several >>>> > SSRC to identification-tag mappings. The offerer and answerer >>>> maintain >>>> > tables mapping RTP streams identified by SSRC to "m=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 >>>> change >>>> > mid-session if, for a given SSRC value, a different >>>> identification-tag >>>> > is provided in an RTP or RTCP packet. In that case these table= s >>>> are >>>> > updated each time an RTP/RTCP packet containing a new mappings >>>> from >>>> > SSRC to identification-tag is received. Some considerations fo= r >>>> > 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 >>>> type >>>> > value if it is unique to a single "m=3D" line), it MUST either >>>> drop the >>>> > RTP packets associated with the RTP stream, or process them in >>>> an >>>> > application specific manner, once non-stream specific processi= ng >>>> > (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 bloc= ks >>>> > 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 >>> >>> >> > --94eb2c075f7c26a5cb05455d78bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This discussion seems to have stalled. I think it's cl= ear that:

- There's a strong (though not necessarily= unanimous) feeling on the JSEP side that we need to specify an actual algo= rithm in the way that JSEP did.
- Magnus and Colin feel like the = algorithm in JSEP isn't adequate.

Given that, = I think the best way to proceed is to schedule a virtual interim to jointly= produce text in algorithmic form that addresses Colin and Magnus's con= cerns. This approach worked well the last time we had some contentious word= smithing (the rules around IP address handling). Chairs, do you think you c= ould arrange this sometime soon so it doesn't hold up JSEP.
<= br>
-Ekr



<= /div>

On Wed= , Jan 4, 2017 at 10:59 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
I wo= uld like to emphasize the importance of standardizing "routing rule&qu= ot; behavior at an appropriate level of detail.=C2=A0

De= velopers are encountering interoperability problems and are filing bugs aga= inst implementations.

To address the issues we are= seeing, it is necessary to get to the level of detail in the JSEP-17 Secti= on 6 text.=C2=A0

On Fri, Dec 9, 2016 at 1= 0:01 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote= :
I agree with Eric and = Cullen that a more explicit algorithm is needed.=C2=A0 The proposed text is= not specific enough to resolve observed implementation differences.=C2=A0<= span>

Cullen said:=C2=A0

"= =C2=A0I'd also like it be clear that MID takes priority over PT."

[BA] Yes.=C2=A0 This is something that m= ultiple implementations appear to agree on.=C2=A0 Also, Peter's suggest= ion that a MID mismatch result in a packet drop should be restored.<= /div>

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

[BA] That is my understanding as we= ll. =C2=A0

However, I'd also like to understan= d what happens if the PT is not unique.=C2=A0 The proposed text does not pr= ovide enough detail and existing implementations differ in how they treat n= on-unique PTs. I am familiar with an implementation that declares SDP with = non-unique PTs to be in error.=C2=A0 Another implementation fills a Payload= Type table with a single value, with the value selected depending on wheth= er SSRCs are also specified (e.g. specification of SSRCs is taken as an ind= ication that only SSRC matching is desired, and therefore that a Payload Ty= pe entry is not needed).=C2=A0 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 e= ither the latching or the PT removal (or both). =C2=A0
=

Cullen said:=C2=A0

"= ;I prefer the much more explicit algorithm= particularly for the RTCP handling as implementors have a hard time figuri= ng out wha they need to do to process the RTCP."

=
[BA] I would also prefer that we have a more explicit alg= orithm here, because we have seen very substantial implementation differenc= es.=C2=A0 One implementation I'm familiar with sends the RTCP packets t= o all RtpSender and RtpReceiver objects.=C2=A0 While this is inefficient, i= t does avoid sending RTCP packets to the wrong objects.=C2=A0 Another imple= mentation sorts the RTCP reports as indicated in the proposed text - but ha= s 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).=C2=A0 S= o this approach is more efficient, unless we are willing to get into detail= on every 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 wit= h Cullen that the algorithm structure used in current JSEP is the better st= ructure.

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

-Ekr

<= div class=3D"m_7291791861056250763m_-6603285502549914630h5">

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



--94eb2c075f7c26a5cb05455d78bf-- From nobody Fri Jan 6 11:24:06 2017 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 20E31129DE2 for ; Fri, 6 Jan 2017 11:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 74cjN2KgF6bY for ; Fri, 6 Jan 2017 11:24:03 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 D117E129DE1 for ; Fri, 6 Jan 2017 11:24:02 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id 192so22758471itl.0 for ; Fri, 06 Jan 2017 11:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e8/h0v9mjwFAffJdCTIqV6uE+Ke7qSKN64UiLhrK4l8=; b=KUHuuLl34V1DS5GHHx3u3jvy/OishxXkU2kJuxX7uck9ObYHHWjj020g2uwbqIMTfN KTDXzj+dMCZBlzDdReRmm+eEDhJd59PqdO0fW57l8pojDknbersNnYFDoxbyI6unfzyn KvX0Q/LDPyPpq0toqxY/DKHnlkuTxNILcKyh3YBpyfmG/xQWWeaiJFvnOXiAlFE6yiLF NJ5gIkN23OWuUY6+t4E0G+S3mzQzNHhhWjugUpYirBKNsuTpKUBvW0KQM3iDJxMoilRK WwVBAWaI9qnxXv0B5weDjD8E1pE39OxX6FRZiXq+GpLZckiiQVotTrElTL6gYURpT/oF 48Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e8/h0v9mjwFAffJdCTIqV6uE+Ke7qSKN64UiLhrK4l8=; b=qjwToVHOElNKGqjjt66+hhv49+voeKpGOnJi3oS8n4um4dboRlHwJ9BPwYecn+speT gpu7MHwc4KVUovHXkbyQXE4ZHnbI9N1ZikGI7ff+ls98zX5BmC/edx8tZCoLQ1B2EsKg 4kborQuIPMS55/b6UNjxgyvDS5W61Rs6k2mqCw0vZj0xcOu4AaQkp68Zrp7Bl1yzYo4O lqExnEeS/RdjtbA1DoHfcO6HiuZHkeIldAGUxt9WfmvDdAsOl4x4voF8ywXQoR3nQZOb iRTlf3eqmjL6UJAcBRCtep6Tfq7Nj57HsuJQqxBHObkX+6M4WQcDEjfpx34hjACx8New 47Hg== X-Gm-Message-State: AIkVDXJPjzAQVr7Gd9fjvlK651FXf63jUvIC8xxX7VX29o8YhuwJG0k0uz/c4PcdmL3RTu+VtaVwfW5YNeWarhug X-Received: by 10.36.129.2 with SMTP id q2mr205972itd.26.1483730641605; Fri, 06 Jan 2017 11:24:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Fri, 06 Jan 2017 19:23:50 +0000 Message-ID: To: Colin Perkins , "mmusic (E-mail)" , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=94eb2c08da88d6256d054571f51e Archived-At: Cc: draft-ietf-rtcweb-jsep@tools.ietf.org, 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, 06 Jan 2017 19:24:05 -0000 --94eb2c08da88d6256d054571f51e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When I read your text, I get the impression that you want to simplify the algorithm to only supporting MIDs for demux with SSRC latching. No PT demux. No SSRC demux (except for ones latched by MID). In other words, if you want to use BUNDLE, you must use MID and only MID. But it's not clear if that's the case. Perhaps I missed something. I agree with others that a more explicit algorithm would make your intention clear. To help, here is my interpretation of your text as an algorithm. Please let me know if it's a correct interpretation:
To prepare for demultiplexing RTP packets to the correct "m=3D" line, the following steps MUST be followed for each BUNDLE group. Construct a table mapping MID to "m=3D" line for each "m=3D" line in this BUNDLE group. Construct an empty table mapping incoming SSRC to "m=3D" line. As "m=3D" lines are added or removed from the BUNDLE groups, or their configurations are changed, the tables above must also be updated. For each RTP packet received, the following steps MUST be followed to route the packet to the correct "m=3D" section within a BUNDLE group: If the packet has a MID and that MID is not in the table mapping MID to "m=3D" line, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID to "m=3D" line, update the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the "m=3D" line for that MID. If the packet's SSRC is in the incoming SSRC mapping table, route the packet to the associated "m=3D" line and stop. Otherwise, drop the packet. ... similar for RTCP ...
On Thu, Dec 8, 2016, 2:55 AM Colin Perkins wrote: Hi, [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BUND= LE drafts] There=E2=80=99s been a lot of discussion on the lists, and at the meeting i= n Seoul, around how RTP streams are mapped onto higher-level, application meaningful, semantic roles. In particular, around how RTP streams map onto JSEP objects for WebRTC. Magnus Westerlund and I would like to propose the following updates to JSEP and BUNDLE to try to clarify the behaviour. Comments and feedback very welcome. Cheers, Colin # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17
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 to RtpReceiver objects. This allows each RTP stream to be associated with an RtpTransceiver. Further processing of the RTP stream can then be done at the RtpTransceiver level. This includes using RID 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-negotiation-36
As described in , RTP packets are associated with RTP streams . Each RTP s= tream 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 multipl= e 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 associated w= ith the same "m=3D" line. Also, as described in , the same payload type value might = be used by multiple RTP streams, in which case the payload type value cannot be used to associate an RTP stream with the correct "m=3D" li= ne. However, there are cases where each "m=3D" line has unique payload t= ype values, and then the payload type could serve as hint to the relevan= t "m=3D" line the RTP stream is associated with. An offerer and answerer can inform each other which SSRC values they will use for an RTP stream by using the SDP 'ssrc' attribute . Howe= ver, 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 usin= g 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 answerer using the BUNDLE extension MUST support the mechanism defined in , wh= ere the offerer and answerer includes the identification-tag (provided by th= e remote peer) associated with an "m=3D" line in the RTP Streams and i= n 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 (). Since a compound RTC= P packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, an RTCP packet can contain several SSRC to identification-tag mappings. The offerer and answerer maintain tables mapping RTP streams identified by SSRC to "m=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.<= /t> The mapping between the SSRC an identification-tag might change mid-session if, for a given SSRC value, a different identification-tag is provided in an RTP or RTCP packet. In that case these tables are updated each time an RTP/RTCP packet containing a new mappings from SSRC to identification-tag is received. Some considerations for avoiding update flaps are provided in Section 4.2.6 of 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 type value if it is unique to a single "m=3D" line), it MUST either drop = the RTP packets associated with the RTP stream, or process them in an application specific manner, once non-stream specific processing (e.g., related to congestion control) of the RTP packets have occurred. 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/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --94eb2c08da88d6256d054571f51e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When I read your text, I get the impression that you want = to simplify the algorithm to only supporting MIDs for demux with SSRC latch= ing.=C2=A0 No PT demux. =C2=A0 No SSRC demux (except for ones latched by MI= D). =C2=A0 In other words, if you want to use BUNDLE, you must use MID and = only MID.

But it's not clear if that's the case.= =C2=A0 Perhaps I missed something.=C2=A0 I agree with others that a more ex= plicit algorithm would make your intention clear.

To hel= p, here is my interpretation of your text as an algorithm.=C2=A0 Please let= me know if it's a correct interpretation:

=C2=A0 =C2=A0 <section title=3D"Appendix B" anchor=3D"s= ec.appendix-b">
=C2=A0 =C2=A0 =C2=A0 <t>To prepare = for demultiplexing RTP packets to the correct "m=3D"
= =C2=A0 =C2=A0 =C2=A0 line, the following steps MUST be followed for each BU= NDLE
=C2=A0 =C2=A0 =C2=A0 group.</t>

=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <= ;list>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>Construct a= table mapping MID to "m=3D" line for each "m=3D"
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 line in this BUNDLE group.</t>= ;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>Cons= truct an empty table mapping incoming SSRC to "m=3D" line. </t= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 = =C2=A0 =C2=A0 </t>

=C2=A0 =C2=A0 =C2=A0 <= t>As "m=3D" lines are added or removed from the BUNDLE groups,= or
=C2=A0 =C2=A0 =C2=A0 their configurations are changed, the ta= bles above must also be
=C2=A0 =C2=A0 =C2=A0 updated.</t>

=C2=A0 =C2=A0 =C2=A0 <t>For each RTP packet r= eceived, the following steps MUST be
=C2=A0 =C2=A0 =C2=A0 followe= d to route the packet to the correct "m=3D" section within
<= div>=C2=A0 =C2=A0 =C2=A0 a BUNDLE group:</t>

=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <l= ist>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>If the packet= has a MID and that MID is not in the table
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 mapping MID to "m=3D" line, drop the packet and sto= p.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &l= t;t>If the packet has a MID and that MID is in the table
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID to "m=3D" line, updat= e the incoming SSRC mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ta= ble to include an entry that maps the packet's SSRC to the
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "m=3D" line for that MID.</= t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>= If the packet's SSRC is in the incoming SSRC mapping
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 table, route the packet to the associated "= ;m=3D" line and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stop.<= /t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>= ;Otherwise, drop the packet.</t>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 </list>
=C2=A0 =C2=A0 =C2=A0 </t>

<= /div>
... similar for RTCP ...
=C2=A0 =C2=A0 </section>=





On Thu, Dec= 8, 2016, 2:55 AM Colin Perkins <csp@csperkins.org> wrote:
Hi,

[cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BUND= LE drafts]

There=E2=80=99s been a lot of discussion on the lists, and at the meeting i= n Seoul, around how RTP streams are mapped onto higher-level, application m= eaningful, semantic roles. In particular, around how RTP streams map onto J= SEP objects for WebRTC. Magnus Westerlund and I would like to propose the f= ollowing 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

=C2=A0<section title=3D"Processing RTP/RTCP" anchor=3D"se= c.rtp.demux">
=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550"= ;/>, RTP packets are
=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC7656&q= uot;/>. Metadata
=C2=A0 =C2=A0 about those streams, including source description information=
=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packets. =C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP packet=
=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packet wi= th
=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to identi= fy
=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 on, o= r
=C2=A0 =C2=A0 deliver source description information relating to, several R= TP
=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 corres= pond to
=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be associ= ated
=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP stream = can
=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This includes= 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 Source R= TP
=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP stream.&l= t;/t>

=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D section= s depends on
=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE extensi= on
=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections bas= ed on
=C2=A0 =C2=A0 the MID values as described in
=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-negotiatio= n"/>.=C2=A0 If the
=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section corresp= onds
=C2=A0 =C2=A0 to a transport layer connection and the RTP streams received = 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 rec= eption
=C2=A0 =C2=A0 quality feedback, source description information, and other =C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are pars= ed,
=C2=A0 =C2=A0 the associated RTP streams are identified based on the includ= ed
=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP streams i= s
=C2=A0 =C2=A0 updated (this might include updating the MID information, use= d
=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP BUNDL= E
=C2=A0 =C2=A0 extension is in use). This updated metadata is available to t= he
=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.
=C2=A0 =C2=A0 </t>
=C2=A0</section>



# Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-negotia= tion-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"Associating = RTP Streams With Correct SDP Media Description"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default"&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D"= ;default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packets a= re associated with RTP streams <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"RFC7656"/>. Each RTP stream is
=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP packet= carries an SSRC value
=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with the co= rrect 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 will co= mmonly carry multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providing fe= edback 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 received= 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 attri= butes associated with the "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process the p= ackets.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with a BU= NDLE 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 loca= l address:port
=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an RTP s= tream 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 format= =3D"default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/>, t= he 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 with t= he correct "m=3D" line.
=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m=3D&q= uot; line has unique payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serve 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 "= ;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&= quot;false" target=3D"RFC5576"/>. However, an
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the answ= erer will use until
=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providing th= at information. Due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the answer= , the offerer will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the corr= ect "m=3D" line using
=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP stream. I= n addition, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSRC va= lues mid-session,
=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP '= ssrc' attribute.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answerer to= always be able to associate
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D" = line, the offerer and answerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the mech= anism defined in <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"sec-receiver-id"/>, where the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identification= -tag (provided by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D"= line in the RTP Streams and in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.</t&= gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an identifi= cation-tag is carried in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extensions (&= lt;xref format=3D"default"
=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"sec-re= ceiver-id"/>). Since a compound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packets, a= nd each RTCP SDES
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP pack= et can contain several
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The offerer= and answerer maintain
=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSRC 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 head= er extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP packet c= arrying one or
=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer cre= ates a mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the ident= ification-tag,
=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associated = with that SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line correspondi= ng to the identification-tag.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an identif= ication-tag might change
=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a differ= ent identification-tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In that ca= se these tables are
=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet containing = a new mappings from
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some con= siderations for
=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Section 4.= 2.6 of <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which should b= e followed. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not able = to associate an RTP stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mechani= sms described in this section, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., based o= n the payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D&quo= t; line), it MUST either drop the
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, or p= rocess them in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream spe= cific 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 received= , they are split
=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those comp= onent RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP packet= type, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the com= pound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are processed = based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they are re= ceived. Information
=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or more RT= P streams.
=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Receive= r Report (RR)
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that ind= icates the
=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RTCP p= acket, along
=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report contai= ns data on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, identi= fied by SSRC,
=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP packe= t. 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 streams t= o 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 process= RTCP packets, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data structu= re associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for late= r access and
=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relating t= o an SSRC can
=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to that = SSRC, so the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might need t= o be created
=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is received.= </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to an R= TP stream might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it onto a= n m=3D line is
=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packets re= lating to such
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or "m= =3D" line dependent
=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated wit= h a particular
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information to g= enerate RTCP report blocks
=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or repo= rting needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the str= eam can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>

=C2=A0 =C2=A0 =C2=A0</section>




--
Colin Perkins
https://csperkins.org/




_______________________________________________
mmusic mailing list
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic
--94eb2c08da88d6256d054571f51e-- From nobody Fri Jan 6 14:49:39 2017 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 D2740129637 for ; Fri, 6 Jan 2017 14:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2WAs3sQK6ci8 for ; Fri, 6 Jan 2017 14:49:30 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 293871295E6 for ; Fri, 6 Jan 2017 14:49:26 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id k201so8793179ioe.2 for ; Fri, 06 Jan 2017 14:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:from:date:message-id:subject:to:cc; bh=HSgpm+itc6g0YvgszBcSpWsSWbt38F6Rij0s7/VVbdI=; b=erxzEZIydr9mBbJlBp7Xd0IjpCbBzeD1IWVtez0dJWqKmNCey/Fwz4BgTLINarnW28 PqAbyDSS8uwCkN8gIIm9+T+6xrau1e9orq07vrcGNpY/uvsBPPG6eW0m772Q93HiPmZd 113C6FxmVWnc0I0PKG55qTEDubOaDKH/kuUrr9VL7RSWRp+vj4bmyuk0vtWcaGcsYVhc dSOdM2UZ/kRC3Ek0dcCPK1S5tISm2H0f4CPxvwqkq4XSxWra29RP7u67iniOUyeXVhvQ hdkQVMtkPboacOWDaz4AkC3MQ9Otj5eocSE9BBObV24rCdUeuHrZYT4iFWoz8wSWSPNJ 5Wiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc; bh=HSgpm+itc6g0YvgszBcSpWsSWbt38F6Rij0s7/VVbdI=; b=JMsd4SEhJIMI7QIqMD9rTe9s2WIQZFaZpTza7yTSEwZqyrBBTE9XuZXw5vmqD+XNpM Psjgx1od0mUmqRep/GjI/InxD0FtLgm8iD1gGU9J83Hg8xnDr49OHIY56qYAyjqC6+oA n33f8UsxLFSx7UzGyz9bbDvZ82FnqrZy1oQHkf7PDCRXjqaZLbYGgfPfpKuj6VpRisEZ S4ZELsfugQ1ziKD+K4KZm2r/k/OVhLxoyvgBprcLqs3ay75DzSSBgeFscT0/difB4vqA CHFfdgsITrD5FIVoi+csmzI2SBVkQydshABRJN4K28vx3r8Edli8KWmaz3S4TywZ5GKp IWZQ== X-Gm-Message-State: AIkVDXLdSeOYU8P5ubfCGD9TDZlXCLDd6UGvLjDUehFMrFwIfrZXkaOVIxajt8xjsKEkHHxLPtj3Lg0IUahiXYmQ X-Received: by 10.107.19.78 with SMTP id b75mr34565165ioj.111.1483742965259; Fri, 06 Jan 2017 14:49:25 -0800 (PST) MIME-Version: 1.0 References: From: Peter Thatcher Date: Fri, 06 Jan 2017 22:49:14 +0000 Message-ID: To: Colin Perkins , "mmusic (E-mail)" , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001a113f26fc621bbc054574d43b Archived-At: Cc: draft-ietf-rtcweb-jsep@tools.ietf.org, 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, 06 Jan 2017 22:49:34 -0000 --001a113f26fc621bbc054574d43b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I made a PR for JSEP that incorporates your text *and* adds a more specific algorithm which only uses MID and SSRC latching (my interpretation of your text, which I'm still not sure is correct): https://github.com/rtcweb-wg/jsep/pull/489 In practice, I think this is mostly word smithing and doesn't require a virtual interim. The big questions, which perhaps to require a virtual interim, are: 1. Do we want to include PT demux in the algorithm (when neither SSRC nor MID match)? 2. Do we want to include signaled SSRCs in the demux algorithm (the SSRC table is loaded with signaled SSRCs)? The question to both of those is "yes" in PR 411 and "no" in PR 489. On Fri, Jan 6, 2017 at 11:23 AM Peter Thatcher wrote= : > When I read your text, I get the impression that you want to simplify the > algorithm to only supporting MIDs for demux with SSRC latching. No PT > demux. No SSRC demux (except for ones latched by MID). In other words= , > if you want to use BUNDLE, you must use MID and only MID. > > But it's not clear if that's the case. Perhaps I missed something. I > agree with others that a more explicit algorithm would make your intentio= n > clear. > > To help, here is my interpretation of your text as an algorithm. Please > let me know if it's a correct interpretation: > >
> To prepare for demultiplexing RTP packets to the correct "m=3D" > line, the following steps MUST be followed for each BUNDLE > group. > > > > Construct a table mapping MID to "m=3D" line for each "m=3D" > line in this BUNDLE group. > > Construct an empty table mapping incoming SSRC to "m=3D" lin= e. > > > > > As "m=3D" lines are added or removed from the BUNDLE groups, or > their configurations are changed, the tables above must also be > updated. > > For each RTP packet received, the following steps MUST be > followed to route the packet to the correct "m=3D" section within > a BUNDLE group: > > > > If the packet has a MID and that MID is not in the table > mapping MID to "m=3D" line, drop the packet and stop. > > If the packet has a MID and that MID is in the table > mapping MID to "m=3D" line, update the incoming SSRC mapping > table to include an entry that maps the packet's SSRC to the > "m=3D" line for that MID. > > If the packet's SSRC is in the incoming SSRC mapping > table, route the packet to the associated "m=3D" line and > stop. > > Otherwise, drop the packet. > > > > ... similar for RTCP ... >
> > > > > > On Thu, Dec 8, 2016, 2:55 AM Colin Perkins wrote: > > Hi, > > [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BU= NDLE > drafts] > > There=E2=80=99s been a lot of discussion on the lists, and at the meeting= in > Seoul, around how RTP streams are mapped onto higher-level, application > meaningful, semantic roles. In particular, around how RTP streams map ont= o > JSEP objects for WebRTC. Magnus Westerlund and I would like to propose th= e > 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 to > RtpReceiver objects. This allows each RTP stream to be associated > with an RtpTransceiver. Further processing of the RTP stream can > then be done at the RtpTransceiver level. This includes using > RID 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-negotiation-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 streams > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each RTP= stream > is > identified by an SSRC value, and each RTP packet carries an SSRC > value > that is used to associate the packet with the correct RTP stream. > RTCP > packets also uses SSRCs to identify on which RTP streams any repor= t > or > feedback relate to. Thus, an RTCP packet will commonly carry > multiple > SSRC values, and might therefore be providing feedback or report o= n > multiple RTP streams. > > In order to be able to process received RTP packets correctly i= t > 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 t= he > 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 associated > with > the same "m=3D" line. > > Also, as described in target=3D"sec-rtp-sessions-pt"/>, the same payload type value migh= t be > used by multiple RTP streams, in which case the payload type value > cannot be used to associate an RTP stream with the correct "m=3D" > line. > However, there are cases where each "m=3D" line has unique payload > 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 values > they will use for an RTP stream by using the SDP 'ssrc' attribute > . Ho= wever, > an > offerer will not know which SSRC values the answerer will use unti= l > the offerer has received the answer providing that information. Du= e > 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 us= ing > 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 answer= er > 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 by > the > remote peer) associated with an "m=3D" line in the RTP Streams and= 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 R= TCP > packet can contain multiple RTCP SDES packets, and each RTCP SDES > packet can contain multiple chunks, an RTCP packet can contain > several > SSRC to identification-tag mappings. The offerer and answerer > maintain > tables mapping RTP streams identified by SSRC to "m=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 change > mid-session if, for a given SSRC value, a different > identification-tag > is provided in an RTP or RTCP packet. In that case these tables ar= e > updated each time an RTP/RTCP packet containing a new mappings fro= m > 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 stre= am > with an "m=3D" line (using the mechanisms described in this sectio= n, > or > using other appropriate mechanism, e.g., based on the payload type > value if it is unique to a single "m=3D" line), it MUST either dro= p > the > RTP packets associated with the RTP stream, or process them in an > application specific manner, once non-stream specific processing > (e.g., related to congestion control) of the RTP packets have > occurred. > > 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. Informatio= n > 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/ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a113f26fc621bbc054574d43b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I made a PR for JSEP that incorporates your text *and* add= s a more specific algorithm which only uses MID and SSRC latching (my inter= pretation of your text, which I'm still not sure is correct):

<= /div>


In practice, I think this is mostly word smithing and doesn't req= uire a virtual interim.=C2=A0 The big questions, which perhaps to require a= virtual interim, are:

1.=C2=A0 Do we want to incl= ude PT demux in the algorithm (when neither SSRC nor MID match)? =C2=A0
2.=C2=A0 Do we want to include signaled SSRCs in the demux algorithm= (the SSRC table is loaded with signaled SSRCs)?

T= he question to both of those is "yes" in PR 411 and "no"= ; in PR 489.

On = Fri, Jan 6, 2017 at 11:23 AM Peter Thatcher <pthatcher@google.com> wrote:
When I read your text, I get the impression = that you want to simplify the algorithm to only supporting MIDs for demux w= ith SSRC latching.=C2=A0 No PT demux. =C2=A0 No SSRC demux (except for ones= latched by MID). =C2=A0 In other words, if you want to use BUNDLE, you mus= t use MID and only MID.

But it's not clear if that&#= 39;s the case.=C2=A0 Perhaps I missed something.=C2=A0 I agree with others = that a more explicit algorithm would make your intention clear.

To help, here is my interpretation of your text as an algorithm.=C2= =A0 Please let me know if it's a correct interpretation:

=
=C2=A0 =C2=A0 <section title=3D"Appendix B" an= chor=3D"sec.appendix-b">
=C2=A0 =C2=A0 =C2=A0 <t&= gt;To prepare for demultiplexing RTP packets to the correct "m=3D"= ;
=C2=A0 =C2=A0 =C2=A0 line, the following steps MUST be followed= for each BUNDLE
=C2=A0 =C2=A0 =C2=A0 group.</t>
=
=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 <list>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t&= gt;Construct a table mapping MID to "m=3D" line for each "m= =3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 line in this BUNDLE = group.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <t>Construct an empty table mapping incoming SSRC to "m=3D&q= uot; line. </t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 =C2=A0 =C2=A0 </t>

=C2=A0 = =C2=A0 =C2=A0 <t>As "m=3D" lines are added or removed from = the BUNDLE groups, or
=C2=A0 =C2=A0 =C2=A0 their configurations a= re changed, the tables above must also be
=C2=A0 =C2=A0 =C2=A0 up= dated.</t>

=C2=A0 =C2=A0 =C2=A0 <t>For= each RTP packet received, the following steps MUST be
=C2=A0 =C2= =A0 =C2=A0 followed to route the packet to the correct "m=3D" sec= tion within
=C2=A0 =C2=A0 =C2=A0 a BUNDLE group:</t>
<= div>
=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 <list>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= ;t>If the packet has a MID and that MID is not in the table
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID to "m=3D" line, dr= op the packet and stop.</t>

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <t>If the packet has a MID and that MID is in th= e table
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID to "m= =3D" line, update the incoming SSRC mapping
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 table to include an entry that maps the packet's S= SRC to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "m=3D" li= ne for that MID.</t>

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <t>If the packet's SSRC is in the incoming SSRC map= ping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 table, route the packet t= o the associated "m=3D" line and
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 stop.</t>

=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 <t>Otherwise, drop the packet.</t>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 =C2=A0 =C2=A0 </= t>

... similar for RTCP ...
=C2=A0 = =C2=A0 </section>



<= div dir=3D"auto" class=3D"gmail_msg">

On Thu, Dec 8, 2016, 2:55 AM Colin Perkins <csp@csperkins.org> wrote:
Hi,

[cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BUND= LE drafts]

There=E2=80=99s been a lot of discussion on the lists, and at the meeting i= n Seoul, around how RTP streams are mapped onto higher-level, application m= eaningful, semantic roles. In particular, around how RTP streams map onto J= SEP objects for WebRTC. Magnus Westerlund and I would like to propose the f= ollowing 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

=C2=A0<section title=3D"Processing RTP/RTCP" anchor=3D"se= c.rtp.demux">
=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550"= ;/>, RTP packets are
=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC7656&q= uot;/>. Metadata
=C2=A0 =C2=A0 about those streams, including source description information=
=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packets. =C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP packet=
=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packet wi= th
=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to identi= fy
=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 on, o= r
=C2=A0 =C2=A0 deliver source description information relating to, several R= TP
=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 corres= pond to
=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be associ= ated
=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP stream = can
=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This includes= 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 Source R= TP
=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP stream.&l= t;/t>

=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D section= s depends on
=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE extensi= on
=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections bas= ed on
=C2=A0 =C2=A0 the MID values as described in
=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-negotiatio= n"/>.=C2=A0 If the
=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section corresp= onds
=C2=A0 =C2=A0 to a transport layer connection and the RTP streams received = 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 rec= eption
=C2=A0 =C2=A0 quality feedback, source description information, and other =C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are pars= ed,
=C2=A0 =C2=A0 the associated RTP streams are identified based on the includ= ed
=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP streams i= s
=C2=A0 =C2=A0 updated (this might include updating the MID information, use= d
=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP BUNDL= E
=C2=A0 =C2=A0 extension is in use). This updated metadata is available to t= he
=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.
=C2=A0 =C2=A0 </t>
=C2=A0</section>



# Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-negotia= tion-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"Associating = RTP Streams With Correct SDP Media Description"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default"&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D"= ;default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packets a= re associated with RTP streams <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"RFC7656"/>. Each RTP stream is
=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP packet= carries an SSRC value
=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with the co= rrect 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 will co= mmonly carry multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providing fe= edback 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 received= 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 attri= butes associated with the "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process the p= ackets.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with a BU= NDLE 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 loca= l address:port
=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an RTP s= tream 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 format= =3D"default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/>, t= he 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 with t= he correct "m=3D" line.
=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m=3D&q= uot; line has unique payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serve 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 "= ;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&= quot;false" target=3D"RFC5576"/>. However, an
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the answ= erer will use until
=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providing th= at information. Due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the answer= , the offerer will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the corr= ect "m=3D" line using
=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP stream. I= n addition, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSRC va= lues mid-session,
=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP '= ssrc' attribute.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answerer to= always be able to associate
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D" = line, the offerer and answerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the mech= anism defined in <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"sec-receiver-id"/>, where the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identification= -tag (provided by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D"= line in the RTP Streams and in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.</t&= gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an identifi= cation-tag is carried in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extensions (&= lt;xref format=3D"default"
=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"sec-re= ceiver-id"/>). Since a compound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packets, a= nd each RTCP SDES
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP pack= et can contain several
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The offerer= and answerer maintain
=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSRC 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 head= er extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP packet c= arrying one or
=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer cre= ates a mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the ident= ification-tag,
=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associated = with that SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line correspondi= ng to the identification-tag.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an identif= ication-tag might change
=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a differ= ent identification-tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In that ca= se these tables are
=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet containing = a new mappings from
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some con= siderations for
=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Section 4.= 2.6 of <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which should b= e followed. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not able = to associate an RTP stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mechani= sms described in this section, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., based o= n the payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D&quo= t; line), it MUST either drop the
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, or p= rocess them in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream spe= cific 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 received= , they are split
=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those comp= onent RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP packet= type, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the com= pound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are processed = based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they are re= ceived. Information
=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or more RT= P streams.
=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Receive= r Report (RR)
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that ind= icates the
=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RTCP p= acket, along
=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report contai= ns data on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, identi= fied by SSRC,
=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP packe= t. 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 streams t= o 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 process= RTCP packets, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data structu= re associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for late= r access and
=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relating t= o an SSRC can
=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to that = SSRC, so the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might need t= o be created
=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is received.= </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to an R= TP stream might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it onto a= n m=3D line is
=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packets re= lating to such
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or "m= =3D" line dependent
=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated wit= h a particular
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information to g= enerate RTCP report blocks
=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or repo= rting needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the str= eam can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>

=C2=A0 =C2=A0 =C2=A0</section>




--
Colin Perkins
https://csperkins.org/




_______________________________________________
mmusic mailing list
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic
<= /div> --001a113f26fc621bbc054574d43b-- From nobody Fri Jan 6 16:48:32 2017 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 9CDCE1296D6; Fri, 6 Jan 2017 16:48:27 -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 wrLO2EuHVU6T; Fri, 6 Jan 2017 16:48:24 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 1309B12966F; Fri, 6 Jan 2017 16:48:24 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id i68so316174363uad.0; Fri, 06 Jan 2017 16:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=edd4bW3v15+fZqChu6iZBDAfDphbZKnXuv4wIj0fSuo=; b=T0RKUeB3CY8T3HO+36OHy+vpwwkFqJ0CG860PoTlSMOFZt0XiKQ52GVU//NkblU8E4 96cCXlGWjF8rQ5rbi1RDnm7uxS2kt2l6RbQDvJxpBvvhdq+q3Dq9aLCxfjQaBFSTNv2q NvSsyzk0b0sfJbpmBqem2WdQ0FjLi1KTR9ULWo0qUeClmDZ9c6H7Z0tWsn455+IaHfLI PLBOGM31pPzNIcy7ysji7zHsIL6HSTjMc7lAe2YDi08IjheuyL5hXvviDfz3OJWo939t GwvH+t8QDuOUCMv3bRgQuy8tn/R+qV+ZRhKMUKFxWQH9pGyVfNKMNfliVa6lbOL42VwL pSiQ== 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=edd4bW3v15+fZqChu6iZBDAfDphbZKnXuv4wIj0fSuo=; b=WfZaIm5uRJBzttriWRmnk7KcY4SiJ65ozuOCcqDnvzOkjn2eXvzzDZA1zBB/C+xcHv x1GuYxSLY5OU9xIn0YROax1eE8UpBOXPOTQCAkENmj6YCmqPzvY+x91CT6JMZPZTEZmN zqdQ9Q59D5REl27edxUkkUxVSwG7Q6RwolvMqJqxjPLLZ9vB4BLWfrfhn6PVlQGDIStE rQgrCY9xuA3UTg0DlqlvjZcK7VNVsTI2AxtP0ZObp+w4l+z3Z0DE0RmcbZPDPv1SR1Va GBIXkSewoFqjqc5NAs20nTPLjv6/kiPLQUtvxU3RX3aQxHhNlFJcrn9Zw5Lyf2G0A+Xp p/sA== X-Gm-Message-State: AIkVDXIv7ORLdYVylX2Lil0o6CMOgP1XRc0xOZ5dX1zDMWsH++DeekS0R1PmonrVacAbmb8Pcr3O9mZnzotjjw== X-Received: by 10.159.50.138 with SMTP id l10mr49935579uab.166.1483750102763; Fri, 06 Jan 2017 16:48:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.37 with HTTP; Fri, 6 Jan 2017 16:48:02 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Fri, 6 Jan 2017 16:48:02 -0800 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=f403045ddf7acf8ed60545767d23 Archived-At: Cc: "mmusic \(E-mail\)" , draft-ietf-rtcweb-jsep@tools.ietf.org, "rtcweb@ietf.org" , 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: Sat, 07 Jan 2017 00:48:27 -0000 --f403045ddf7acf8ed60545767d23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter said: " In practice, I think this is mostly word smithing and doesn't require a virtual interim. The big questions, which perhaps to require a virtual interim, are: 1. Do we want to include PT demux in the algorithm (when neither SSRC nor MID match)? 2. Do we want to include signaled SSRCs in the demux algorithm (the SSRC table is loaded with signaled SSRCs)? " [BA] I believe that we need to cover both #1 and #2. 1. There have been bugs filed against implementations that relate to PT demux (e.g. SSRC change scenario). So IMHO covering PT demux is necessary. JSEP-17 was pretty close, but tere are a few issues that still need to be discussed: a. SSRC latching on a PT match. If the PT can change without SSRC changing (e.g. in a video scenario where all codecs have the same clockrate), it seems that latching could result in mis-routing. b. Whether the PT_table is filled if SSRCs are signaled in codecs and/or RTX/FEC. Implementations are doing different things here, and that is going to cause problems. 2. Including signaled SSRCs in the demux algorithm is a practical requirement because SSRC signaling is widely implemented and MID isn't yet. Also, when discussing RTCP segment routing, doesn't the SSRC_table come into play (e.g. in deciding which receiver to route a Sender Report to)? On Fri, Jan 6, 2017 at 2:49 PM, Peter Thatcher wrote= : > I made a PR for JSEP that incorporates your text *and* adds a more > specific algorithm which only uses MID and SSRC latching (my interpretati= on > of your text, which I'm still not sure is correct): > > https://github.com/rtcweb-wg/jsep/pull/489 > > > In practice, I think this is mostly word smithing and doesn't require a > virtual interim. The big questions, which perhaps to require a virtual > interim, are: > > 1. Do we want to include PT demux in the algorithm (when neither SSRC no= r > MID match)? > 2. Do we want to include signaled SSRCs in the demux algorithm (the SSRC > table is loaded with signaled SSRCs)? > > The question to both of those is "yes" in PR 411 and "no" in PR 489. > > On Fri, Jan 6, 2017 at 11:23 AM Peter Thatcher > wrote: > >> When I read your text, I get the impression that you want to simplify th= e >> algorithm to only supporting MIDs for demux with SSRC latching. No PT >> demux. No SSRC demux (except for ones latched by MID). In other word= s, >> if you want to use BUNDLE, you must use MID and only MID. >> >> But it's not clear if that's the case. Perhaps I missed something. I >> agree with others that a more explicit algorithm would make your intenti= on >> clear. >> >> To help, here is my interpretation of your text as an algorithm. Please >> let me know if it's a correct interpretation: >> >>
>> To prepare for demultiplexing RTP packets to the correct "m=3D" >> line, the following steps MUST be followed for each BUNDLE >> group. >> >> >> >> Construct a table mapping MID to "m=3D" line for each "m=3D= " >> line in this BUNDLE group. >> >> Construct an empty table mapping incoming SSRC to "m=3D" li= ne. >> >> >> >> >> As "m=3D" lines are added or removed from the BUNDLE groups, or >> their configurations are changed, the tables above must also be >> updated. >> >> For each RTP packet received, the following steps MUST be >> followed to route the packet to the correct "m=3D" section within >> a BUNDLE group: >> >> >> >> If the packet has a MID and that MID is not in the table >> mapping MID to "m=3D" line, drop the packet and stop. >> >> If the packet has a MID and that MID is in the table >> mapping MID to "m=3D" line, update the incoming SSRC mapping >> table to include an entry that maps the packet's SSRC to the >> "m=3D" line for that MID. >> >> If the packet's SSRC is in the incoming SSRC mapping >> table, route the packet to the associated "m=3D" line and >> stop. >> >> Otherwise, drop the packet. >> >> >> >> ... similar for RTCP ... >>
>> >> >> >> >> >> On Thu, Dec 8, 2016, 2:55 AM Colin Perkins wrote: >> >> Hi, >> >> [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and B= UNDLE >> drafts] >> >> There=E2=80=99s been a lot of discussion on the lists, and at the meetin= g 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 to >> RtpReceiver objects. This allows each RTP stream to be associated >> with an RtpTransceiver. Further processing of the RTP stream can >> then be done at the RtpTransceiver level. This includes using >> RID 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- >> negotiation-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 streams >> > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each RT= P >> 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 associate= d >> with >> the same "m=3D" line. >> >> Also, as described in > target=3D"sec-rtp-sessions-pt"/>, the same payload type value mig= ht >> be >> used by multiple RTP streams, in which case the payload type valu= e >> 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 payloa= d >> 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 value= s >> they will use for an RTP stream by using the SDP 'ssrc' attribute >> . H= owever, >> an >> offerer will not know which SSRC values the answerer will use unt= il >> the offerer has received the answer providing that information. >> Due to >> this, before the offerer has received the answer, the offerer wil= l >> not >> be able to associate an RTP stream with the correct "m=3D" line u= sing >> 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 answe= rer >> 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 by >> the >> remote peer) associated with an "m=3D" line in the RTP Streams an= d in >> RTCP SDES packets part of a BUNDLE group. >> >> The mapping from an SSRC to an identification-tag is carried i= n >> 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 SDES >> packet can contain multiple chunks, an RTCP packet can contain >> several >> SSRC to identification-tag mappings. The offerer and answerer >> maintain >> tables mapping RTP streams identified by SSRC to "m=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 chang= e >> 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 a= re >> updated each time an RTP/RTCP packet containing a new mappings fr= om >> 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 secti= on, >> or >> using other appropriate mechanism, e.g., based on the payload typ= e >> value if it is unique to a single "m=3D" line), it MUST either dr= op >> the >> RTP packets associated with the RTP stream, or process them in an >> application specific manner, once non-stream specific processing >> (e.g., related to congestion control) of the RTP packets have >> occurred. >> >> 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. Informati= on >> 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/ >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --f403045ddf7acf8ed60545767d23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter said:=C2=A0

"
In practice, I think this is mostly word smithing an= d doesn't require a virtual interim.=C2=A0 The big questions, which per= haps to require a virtual interim, are:

1.=C2=A0 Do we want to include = PT demux in the algorithm (when neither SSRC nor MID match)? =C2=A0
2.=C2=A0 Do we want to include signaled SSRCs= in the demux algorithm (the SSRC table is loaded with signaled SSRCs)?
"

[BA] =C2=A0I believe that we need to= cover both #1 and #2.=C2=A0

1. There have been bu= gs filed against implementations that relate to PT demux (e.g. SSRC change = scenario).=C2=A0 So IMHO covering PT demux is necessary.=C2=A0 JSEP-17 was = pretty close, but tere are a few issues that still need to be discussed:
=C2=A0 =C2=A0 =C2=A0a.=C2=A0 SSRC latching on a PT match.=C2=A0 If = the PT can change without SSRC changing (e.g. in a video scenario where all= codecs have the same clockrate), it seems that latching could result in mi= s-routing.=C2=A0
=C2=A0 =C2=A0 =C2=A0b. Whether the PT_table is f= illed if SSRCs are signaled in codecs and/or RTX/FEC.=C2=A0 Implementations= are doing different things here, and that is going to cause problems. =C2= =A0

2. Including signaled SSRCs in the demux algor= ithm is a practical requirement because SSRC signaling is widely implemente= d and MID isn't yet.=C2=A0 Also, when discussing RTCP segment routing, = doesn't the SSRC_table come into play (e.g. in deciding which receiver = to route a Sender Report to)?=C2=A0
<= br>
On Fri, Jan 6, 2017 at 2:49 PM, Peter Thatche= r <pthatcher@google.com> wrote:
I made a PR for JSEP that incorporates your text = *and* adds a more specific algorithm which only uses MID and SSRC latching = (my interpretation of your text, which I'm still not sure is correct):<= div>
https://github.com/rtcweb-wg/jsep/pull/489


In practice, I think this is mostly w= ord smithing and doesn't require a virtual interim.=C2=A0 The big quest= ions, which perhaps to require a virtual interim, are:

=
1.=C2=A0 Do we want to include PT demux in the algorithm (when neither= SSRC nor MID match)? =C2=A0
2.=C2=A0 Do we want to include signa= led SSRCs in the demux algorithm (the SSRC table is loaded with signaled SS= RCs)?

The question to both of those is "yes&q= uot; in PR 411 and "no" in PR 489.

On Fri= , Jan 6, 2017 at 11:23 AM Peter Thatcher <pthatcher@google.com> wrote:
When I read your text, I get = the impression that you want to simplify the algorithm to only supporting M= IDs for demux with SSRC latching.=C2=A0 No PT demux. =C2=A0 No SSRC demux (= except for ones latched by MID). =C2=A0 In other words, if you want to use = BUNDLE, you must use MID and only MID.

But it's not = clear if that's the case.=C2=A0 Perhaps I missed something.=C2=A0 I agr= ee with others that a more explicit algorithm would make your intention cle= ar.

To help, here is my interpretation of your text as a= n algorithm.=C2=A0 Please let me know if it's a correct interpretation:=

=C2=A0 =C2=A0 <section title=3D"Appe= ndix B" anchor=3D"sec.appendix-b">
=C2=A0 =C2= =A0 =C2=A0 <t>To prepare for demultiplexing RTP packets to the correc= t "m=3D"
=C2=A0 =C2=A0 =C2=A0 line, the following steps= MUST be followed for each BUNDLE
=C2=A0 =C2=A0 =C2=A0 group.<= /t>

=C2=A0 =C2=A0 =C2=A0 <t>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 <list>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <t>Construct a table mapping MID to "m=3D" line = for each "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 line= in this BUNDLE group.</t>

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <t>Construct an empty table mapping incoming SSRC t= o "m=3D" line. </t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &= lt;/list>
=C2=A0 =C2=A0 =C2=A0 </t>

=
=C2=A0 =C2=A0 =C2=A0 <t>As "m=3D" lines are added or r= emoved from the BUNDLE groups, or
=C2=A0 =C2=A0 =C2=A0 their conf= igurations are changed, the tables above must also be
=C2=A0 =C2= =A0 =C2=A0 updated.</t>

=C2=A0 =C2=A0 =C2=A0= <t>For each RTP packet received, the following steps MUST be
=C2=A0 =C2=A0 =C2=A0 followed to route the packet to the correct "m= =3D" section within
=C2=A0 =C2=A0 =C2=A0 a BUNDLE group:<= /t>

=C2=A0 =C2=A0 =C2=A0 <t>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 <list>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <t>If the packet has a MID and that MID is not in the tabl= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID to "m=3D&qu= ot; line, drop the packet and stop.</t>

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>If the packet has a MID and that M= ID is in the table
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID= to "m=3D" line, update the incoming SSRC mapping
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 table to include an entry that maps the pac= ket's SSRC to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "m= =3D" line for that MID.</t>

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <t>If the packet's SSRC is in the incomi= ng SSRC mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 table, route t= he packet to the associated "m=3D" line and
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 stop.</t>

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>Otherwise, drop the packet.</t><= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 =C2=A0= =C2=A0 </t>

... similar for RTCP ...
<= div>=C2=A0 =C2=A0 </section>

<= div dir=3D"auto" class=3D"m_-8552972565696268422gmail_msg">



On Thu, Dec 8, 2016, 2:55 AM Colin Per= kins <csp@csperkins.org> wrote:
Hi,

[cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BUND= LE drafts]

There=E2=80=99s been a lot of discussion on the lists, and at the meeting i= n Seoul, around how RTP streams are mapped onto higher-level, application m= eaningful, semantic roles. In particular, around how RTP streams map onto J= SEP objects for WebRTC. Magnus Westerlund and I would like to propose the f= ollowing 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

=C2=A0<section title=3D"Processing RTP/RTCP" anchor=3D"se= c.rtp.demux">
=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550"= ;/>, RTP packets are
=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC7656&q= uot;/>. Metadata
=C2=A0 =C2=A0 about those streams, including source description information=
=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packets. =C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP packet=
=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packet wi= th
=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to identi= fy
=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 on, o= r
=C2=A0 =C2=A0 deliver source description information relating to, several R= TP
=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 corres= pond to
=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be associ= ated
=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP stream = can
=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This includes= 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 Source R= TP
=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP stream.&l= t;/t>

=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D section= s depends on
=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE extensi= on
=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections bas= ed on
=C2=A0 =C2=A0 the MID values as described in
=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-negot= iation"/>.=C2=A0 If the
=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section corresp= onds
=C2=A0 =C2=A0 to a transport layer connection and the RTP streams received = 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 rec= eption
=C2=A0 =C2=A0 quality feedback, source description information, and other =C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are pars= ed,
=C2=A0 =C2=A0 the associated RTP streams are identified based on the includ= ed
=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP streams i= s
=C2=A0 =C2=A0 updated (this might include updating the MID information, use= d
=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP BUNDL= E
=C2=A0 =C2=A0 extension is in use). This updated metadata is available to t= he
=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.
=C2=A0 =C2=A0 </t>
=C2=A0</section>



# Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-ne= gotiation-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"Associating = RTP Streams With Correct SDP Media Description"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default"&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D"= ;default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packets a= re associated with RTP streams <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"RFC7656"/>. Each RTP stream is
=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP packet= carries an SSRC value
=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with the co= rrect 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 will co= mmonly carry multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providing fe= edback 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 received= 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 attri= butes associated with the "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process the p= ackets.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with a BU= NDLE 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 loca= l address:port
=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an RTP s= tream 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 format= =3D"default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/&g= t;, 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 with t= he correct "m=3D" line.
=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m=3D&q= uot; line has unique payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serve 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 "= ;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&= quot;false" target=3D"RFC5576"/>. However, an
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the answ= erer will use until
=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providing th= at information. Due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the answer= , the offerer will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the corr= ect "m=3D" line using
=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP stream. I= n addition, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSRC va= lues mid-session,
=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP '= ssrc' attribute.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answerer to= always be able to associate
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D" = line, the offerer and answerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the mech= anism defined in <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"sec-receiver-id"/>, where the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identification= -tag (provided by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D"= line in the RTP Streams and in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.</t&= gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an identifi= cation-tag is carried in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extensions (&= lt;xref format=3D"default"
=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"sec-re= ceiver-id"/>). Since a compound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packets, a= nd each RTCP SDES
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP pack= et can contain several
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The offerer= and answerer maintain
=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSRC 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 head= er extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP packet c= arrying one or
=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer cre= ates a mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the ident= ification-tag,
=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associated = with that SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line correspondi= ng to the identification-tag.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an identif= ication-tag might change
=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a differ= ent identification-tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In that ca= se these tables are
=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet containing = a new mappings from
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some con= siderations for
=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Section 4.= 2.6 of <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which should b= e followed. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not able = to associate an RTP stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mechani= sms described in this section, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., based o= n the payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D&quo= t; line), it MUST either drop the
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, or p= rocess them in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream spe= cific 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 received= , they are split
=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those comp= onent RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP packet= type, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the com= pound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are processed = based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they are re= ceived. Information
=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or more RT= P streams.
=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Receive= r Report (RR)
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that ind= icates the
=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RTCP p= acket, along
=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report contai= ns data on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, identi= fied by SSRC,
=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP packe= t. 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 streams t= o 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 process= RTCP packets, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data structu= re associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for late= r access and
=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relating t= o an SSRC can
=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to that = SSRC, so the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might need t= o be created
=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is received.= </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to an R= TP stream might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it onto a= n m=3D line is
=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packets re= lating to such
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or "m= =3D" line dependent
=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated wit= h a particular
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information to g= enerate RTCP report blocks
=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or repo= rting needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the str= eam can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>

=C2=A0 =C2=A0 =C2=A0</section>




--
Colin Perkins
https://csperkins.org/




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ie= tf.org/mailman/listinfo/mmusic
<= /div>

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

--f403045ddf7acf8ed60545767d23-- From nobody Tue Jan 10 07:13:34 2017 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 F41C112A00E; Tue, 10 Jan 2017 07:13:28 -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, 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 HPygr5SU44ID; Tue, 10 Jan 2017 07:13:27 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5E3FD12951F; Tue, 10 Jan 2017 07:13:26 -0800 (PST) X-AuditID: c1b4fb2d-26a859800000561e-d6-5874fa15cc8c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id B5.9E.22046.51AF4785; Tue, 10 Jan 2017 16:13:25 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.319.2; Tue, 10 Jan 2017 16:13:23 +0100 To: Eric Rescorla References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> From: Magnus Westerlund Message-ID: <9717b211-9dbc-8d50-dece-6dc17e921711@ericsson.com> Date: Tue, 10 Jan 2017 16:13:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7q67or5IIg5tnBC1WvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8aNZTcYC77zVjQuXMXcwNjA3cXI ySEhYCIx9/lFti5GLg4hgXWMEtvm9TBBOMsZJT60TmIEqRIWcJA4tnMtC4gtIqAg8evPCTBb SGAKo8SEVwEgNrOAi8SFqY+ZQGw2AQuJmz8a2UBsXgF7iXXPJoLVswioSkybeRwsLioQI/F2 /XJ2iBpBiZMznwDVsHNwCgRK7MiFmGghMXP+eUYIW16ieetsZoit2hINTR2sExgFZiFpnoWk ZRaSlgWMzKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAsPz4JbfujsYV792PMQowMGoxMP7 4VtJhBBrYllxZe4hRgkOZiUR3u9fgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8s Sc1OTS1ILYLJMnFwSjUw+mn7P1LbKe70kS2t+5BYq9Wk439j+ye8UPty84qQTjfnUt0fsyfM dVlv2rwsRNXf99GfhFu77wr+mGN7Isp8regj5r+128ouy5+Z013+SKWv2ctjr8Gx09UFxR68 7juTdixWm7QzoGJiCKPXkfSN9pW/v2r33P5qeXjL+RlS6y958STKPi/LVmIpzkg01GIuKk4E AJEvzr9LAgAA 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: Tue, 10 Jan 2017 15:13:29 -0000 Den 2016-12-22 kl. 18:30, skrev Eric Rescorla: > > > On Thu, Dec 22, 2016 at 7:15 AM, Magnus Westerlund > > 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/…, > > > 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? > So, my main argument for including any rules for how to set it, would be that the this part of the PROTO field still has meaning outside of WebRTC context. There one may actually have it to match what is goind to be used. Thus, it can provide some guidance to gateways on what to expect. It might be that we should actually set it to UDP for those not supporting ICE/TCP, and to TCP for the ones that supports both UDP and TCP. That would still provide information to the gateway. I think simple rules based on implementation capabilities for how to set it are better than no rules. Especially as it would carry some information, not zero, which is the result of no rules. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jan 10 09:49:27 2017 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 0A15E129D5B; Tue, 10 Jan 2017 09:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no 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 KVpCm8pIkZAN; Tue, 10 Jan 2017 09:49:21 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 661B9129D5D; Tue, 10 Jan 2017 09:49:11 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0AHibJg011298; Tue, 10 Jan 2017 12:49:08 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 27ttaqhsnr-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Jan 2017 12:49:08 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 10 Jan 2017 11:49:07 -0600 From: Jonathan Lennox To: Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] JSEP Issue #394: What appears in m= lines. Thread-Index: AQHSa2LFsapXFV8lFEKmmkXm5smJ5qEyYYCA Date: Tue, 10 Jan 2017 17:49:06 +0000 Message-ID: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9717b211-9dbc-8d50-dece-6dc17e921711@ericsson.com> In-Reply-To: <9717b211-9dbc-8d50-dece-6dc17e921711@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <3C24D80C3F29D841961DF47FF611A815@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-10_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701100245 Archived-At: Cc: "rtcweb@ietf.org" , mmusic 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: Tue, 10 Jan 2017 17:49:22 -0000 DQo+IE9uIEphbiAxMCwgMjAxNywgYXQgMTA6MTMgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gRGVuIDIwMTYtMTItMjIg a2wuIDE4OjMwLCBza3JldiBFcmljIFJlc2NvcmxhOg0KPj4gDQo+PiANCj4+IE9uIFRodSwgRGVj IDIyLCAyMDE2IGF0IDc6MTUgQU0sIE1hZ251cyBXZXN0ZXJsdW5kDQo+PiANCj4+ICAgIE9rYXks IEkgYWdyZWUgdGhhdCBoYXZpbmcgYW55IHJ1bGVzIGZvciB3aGF0IHlvdSBzaG91bGQgb2ZmZXIg aGVyZQ0KPj4gICAgYmFzZWQgb24gd2hhdCB0aGUgYWN0dWFsIG91dGNvbWUgaXMgbm90IHRoZSBi ZXN0IGlkZWEgaGVyZS4gSSB0aGluaw0KPj4gICAgdGhlIHJ1bGVzIHNob3VsZCBiZSBiYXNlZCBv biBjYXBhYmlsaXR5IGFuZCBpbnRlbnQuIFNvIGlmIHlvdSBvbmx5DQo+PiAgICBhcmUgZ29pbmcg b2ZmZXIgVENQIGNhbmRpZGF0ZXMsIHRoZW4geW91IGNsZWFybHkgc2hvdWxkIHVzZSBUQ1Av4oCm LA0KPj4gDQo+PiANCj4+IEknbSBnb2luZyB0byBwdXNoIG9uIHRoaXMuIElmIHdlJ3ZlIGFscmVh ZHkgYWdyZWVkIHRoYXQgbWlzbWF0Y2hlcyBhcmUNCj4+IG5vcm1hbCwgd2h5IHNob3VsZCB3ZSBk byB0aGF0PyBXb3VsZG4ndCBpdCBiZSBiZXR0ZXIgdG8ganVzdCBlZmZlY3RpdmVseQ0KPj4gZGVw cmVjYXRlIHRoaXMgZmllbGQ/DQo+PiANCj4gDQo+IFNvLCBteSBtYWluIGFyZ3VtZW50IGZvciBp bmNsdWRpbmcgYW55IHJ1bGVzIGZvciBob3cgdG8gc2V0IGl0LCB3b3VsZCBiZSB0aGF0IHRoZSB0 aGlzIHBhcnQgb2YgdGhlIFBST1RPIGZpZWxkIHN0aWxsIGhhcyBtZWFuaW5nIG91dHNpZGUgb2Yg V2ViUlRDIGNvbnRleHQuIFRoZXJlIG9uZSBtYXkgYWN0dWFsbHkgaGF2ZSBpdCB0byBtYXRjaCB3 aGF0IGlzIGdvaW5kIHRvIGJlIHVzZWQuIFRodXMsIGl0IGNhbiBwcm92aWRlIHNvbWUgZ3VpZGFu Y2UgdG8gZ2F0ZXdheXMgb24gd2hhdCB0byBleHBlY3QuIEl0IG1pZ2h0IGJlIHRoYXQgd2Ugc2hv dWxkIGFjdHVhbGx5IHNldCBpdCB0byBVRFAgZm9yIHRob3NlIG5vdCBzdXBwb3J0aW5nIElDRS9U Q1AsIGFuZCB0byBUQ1AgZm9yIHRoZSBvbmVzIHRoYXQgc3VwcG9ydHMgYm90aCBVRFAgYW5kIFRD UC4gVGhhdCB3b3VsZCBzdGlsbCBwcm92aWRlIGluZm9ybWF0aW9uIHRvIHRoZSBnYXRld2F5Lg0K DQpJZiB5b3XigJlyZSB1c2luZyBJQ0UsIGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZXJlIGFyZSBv bmx5IHR3byBjYXNlcyB3aGVyZSB0aGUgdHJhbnNwb3J0IHBhcnRzIG9mIHRoZSBQUk9UTyBmaWVs ZCAoYW5kIHRoZSBtL2MgdHJhbnNwb3J0IHZhbHVlcykgYXJlIHN0aWxsIHJlbGV2YW50Og0KDQox LiBJZiB5b3XigJlyZSB0YWxraW5nIHRvIGFuIGVuZHBvaW50IHRoYXQgZG9lc27igJl0IGRvIElD RSwgaXQgdGVsbHMgdGhlIHBlZXIgd2hhdCB0aGUgZmFsbGJhY2sgcHJvdG9jb2wgc2hvdWxkIGJl LiAgVGhpcyBpc27igJl0IHJlbGV2YW50IGZvciBXZWJSVEMsIGJ1dCBzdGlsbCBpcyBmb3IgZ2Vu ZXJhbCBNTVVTSUMgY2FzZXMuDQoNCjIuIElmIHlvdSBoYXZlIGFuIFNEUC1pbnNwZWN0aW5nIG1p ZGRsZWJveCwgaXQgdGVsbHMgaXQgd2hhdCBtZWRpYSBwcm90b2NvbCB0byBsb29rIGZvciAoZm9y IGxhdGNoaW5nIGFuZCB0aGUgbGlrZSkuICBUaGlzIG1vc3RseSBpc27igJl0IG1lYW5pbmdmdWwg YmVmb3JlIElDRSBoYXMgY29uY2x1ZGVkLCBidXQgaXQgaXMgYWZ0ZXJ3YXJkLg0KDQpNeSBzdWdn ZXN0aW9uIHdvdWxkIGJlIHRoYXQgdGhlIFBST1RPIE1VU1QgbWF0Y2ggdGhlIGFjdGl2ZSBjYW5k aWRhdGUsIGlmIHlvdSBoYXZlIG9uZTsgb3RoZXJ3aXNlLCBpdCBNVVNUIG1hdGNoIHRoZSAoZm9y IFdlYlJUQywgZ2VuZXJhbGx5IGFyYml0cmFyaWx5LWNob3NlbikgZGVmYXVsdCBjYW5kaWRhdGUs IGlmIHlvdSBoYXZlIG9uZTsgb3RoZXJ3aXNlICh0aGUgaW5pdGlhbCBzdGF0ZSBvZiB0cmlja2xl KSBpdCBNVVNUIG1hdGNoIG9uZSBvZiB0aGUgcHJvdG9jb2xzIG9mIHRoZSBjYW5kaWRhdGVzIHlv deKAmXJlIGV4cGVjdGluZyB0byBnYXRoZXIgKGlkZWFsbHksIHRoZSBvbmUgdGhhdCB5b3XigJls bCBjaG9vc2UgYXMgdGhlIGRlZmF1bHQpLg0KDQpUaGlzIGJhc2ljYWxseSBtYXRjaGVzIHRoZSBy dWxlcyBmb3IgbS9jIHRyYW5zcG9ydCB2YWx1ZXMgYWxyZWFkeSBpbiBKU0VQLCBJIGJlbGlldmUu DQoNCk5vdywgdGhlIHRyaWNreSB0aGluZyBpcyBvZiBjb3Vyc2Ugd2hldGhlciB0aGlzIHdvcmtz IGZvciBhbnN3ZXJzIOKAlCB3aGV0aGVyIHRoZSBQUk9UTyBmb3IgdGhlIGFuc3dlciBoYXMgdG8g bWF0Y2ggdGhlIG9mZmVyLiAgQSBwcm9ibGVtIG9jY3VycyB3aGVuIHRoZSBhbnN3ZXJlciBpc27i gJl0IGV4cGVjdGluZyB0byBnYXRoZXIgYW55IGNhbmRpZGF0ZXMgdGhhdCB1c2UgdGhlIHByb3Rv Y29sIHVzZWQgYnkgdGhlIG9mZmVyZXLigJlzIGRlZmF1bHQgY2FuZGlkYXRlLg0KDQpNeSBzdWdn ZXN0aW9uIHdvdWxkIGJlIHRoYXQgdGhlIHJ1bGVzIEnigJl2ZSBzcGVjaWZpZWQgYXBwbHkgYW55 d2F5LCBhbmQgdGhhdCB0aGUgYW5zd2VyIFBST1RPIGRvZXNu4oCZdCBoYXZlIHRvIG1hdGNoIHRo ZSBvZmZlciBQUk9UTy4gIFRoaXMgd2lsbCBvbmx5IGNvbmZ1c2UgYW55IGluc3BlY3RpbmcgbWlk ZGxlYm94ZXMgdW50aWwgdGhlIG5leHQgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIG9jY3Vycy4= From nobody Sat Jan 14 11:46:20 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C1129D5B; Sat, 14 Jan 2017 11:46:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148442317450.24137.2927767705905134224.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 11:46:14 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 14 Jan 2017 19:46:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : WebRTC IP Address Handling Requirements Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-03.txt Pages : 8 Date : 2017-01-14 Abstract: This document provides information and requirements for how IP addresses should be handled by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 14 11:48:58 2017 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 46A0D129421 for ; Sat, 14 Jan 2017 11:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CSuPmlgzbisy for ; Sat, 14 Jan 2017 11:48:54 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 471111293DC for ; Sat, 14 Jan 2017 11:48:54 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id d9so14411123itc.0 for ; Sat, 14 Jan 2017 11:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DwgxKH75EZOR//YywyhiXPQ3j3lW8eZ7g3/iyJl1bz8=; b=ZEB9svy9QhmASlVoRA2UDTn/fTA8X3W853WKyYFGvgGHIOJc0ynAGSvhj4/Nm1UAkN YIulAnYD5aAZkI4DKfNOXFR9VLRZ4z1o0CmwLl5HjDzl9DYIJoVFzrCmhYcMrOF+U1wS K7TmkpyBAUmwBVl2kuQIXgZGjBzvyg9Wbz1Y4NhTeUd3oQfdhVWTgwy8itmNAEPjmprs kJhQ1igtNg6drL/aD+rTk5pgItOK3JfQPpuvzCJ86x608XglL4aiQGdpIe63x3CTPKlq 0JrT/QQ2qwQhA/5T7G54WBKFAmmIBQqVlQbJ/hhUKTZhwIuIwfZ6Q6ftkloBzDh1m4+B qzmA== 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=DwgxKH75EZOR//YywyhiXPQ3j3lW8eZ7g3/iyJl1bz8=; b=OKa1MICW1cs9tcPNm/ZPTm6EmRq0Ei0ILOEsr0BZdPOAubIVmSi+i+q3sK8q1kdCdg B7cP7eRFg7JYdKDfBfQxvHzHsSmPVfpeATWZ6J7o5wMt6FrELkkuMiN3YpCY5qHg3ZQ1 f3L8ZG9m5zgpil4lFgxMTCGXoowXZoe8gT1zsbCR8Tu8hifvqMlaYPT2KVwbHndAXEfV uhTOldLIsPmBAySK0R+e7bQWaigmntl9QJKtH6NQuQ9D1yBt0S+6bIF8s5626aBTeLBO 6a3tcqheRJtFlEukwKkkAIQAkY5JakBXINddXWoGulMTDsckeoSZxZ4ACE5VD9/Wc1MQ gsvg== X-Gm-Message-State: AIkVDXJ/3dUw4rmhzXxdz9XNTRaIhxm+qWGzcPIky/BjLPP3ICiTTrfH5bRydjppP1BN3TSM03+7qdhGVzrlRh6h X-Received: by 10.36.147.6 with SMTP id y6mr9102180itd.98.1484423333393; Sat, 14 Jan 2017 11:48:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.7.207 with HTTP; Sat, 14 Jan 2017 11:48:32 -0800 (PST) In-Reply-To: <148442317450.24137.2927767705905134224.idtracker@ietfa.amsl.com> References: <148442317450.24137.2927767705905134224.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Sat, 14 Jan 2017 11:48:32 -0800 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=94eb2c088f127c00f10546133ddb Archived-At: Cc: "rtcweb@ietf.org" , i-d-announce@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-03.txt 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: Sat, 14 Jan 2017 19:48:56 -0000 --94eb2c088f127c00f10546133ddb Content-Type: text/plain; charset=UTF-8 This document incorporates the feedback received at IETF 97, and closes all outstanding issues. As such, I believe it is ready for WGLC. On Sat, Jan 14, 2017 at 11:46 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > of the IETF. > > Title : WebRTC IP Address Handling Requirements > Authors : Justin Uberti > Guo-wei Shieh > Filename : draft-ietf-rtcweb-ip-handling-03.txt > Pages : 8 > Date : 2017-01-14 > > Abstract: > This document provides information and requirements for how IP > addresses should be handled by WebRTC applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c088f127c00f10546133ddb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This document incorporates the feedback received at IETF 9= 7, and closes all outstanding issues.

As such, I believe= it is ready for WGLC.

On Sat, Jan 14, 2017 at 11:46 AM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC IP Address Handling Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=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 Guo-wei Shieh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-ip-handling-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-14

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how IP=
=C2=A0 =C2=A0addresses should be handled by WebRTC applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-rtcweb-ip-handling/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-rtcweb-ip-handling-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--94eb2c088f127c00f10546133ddb-- From nobody Sun Jan 15 07:13:23 2017 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 B173F1295A5 for ; Sun, 15 Jan 2017 07:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 iVX2DLp2FBJQ for ; Sun, 15 Jan 2017 07:13:21 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 AE7FF12959E for ; Sun, 15 Jan 2017 07:13:20 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id r144so139838851wme.1 for ; Sun, 15 Jan 2017 07:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=Ly9a/lyzcXyNuDxUrpBLsiQ/ewX3ek3Ov9kybIS/69c=; b=QHYZudvZvhopDnIWPmewcl+CYq8iONZOBeT6PU6Y9d1Pb99Y86Z4TVdJ2Tp4FzUhqL 8BbxiOmwL8GIxfA1DFyEUr9sdF4Rq5g9vbWxIdEiumKnIRrUDIQflhVg9HSwStxDixA0 iKIEX7kT2AGpgFqS3V9Jr4TzM4uvryM7YTjM+vS6d9QGQrqnFsznod1Mk1n/gQd0/T+r MH/UfZVPrcwDp2s7amHEF+fpVdOwOTd9YpyyrjYa+8/9uAci8TTUp2FEF8Aa5QPTv0yL wkUqAFxmFnj+4xXVoozDmwDq8jRUcs+ut+aPC4LHlJFXZmsR5xXa8GB7zVb2lKNaS6CK oqBw== 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 :content-transfer-encoding; bh=Ly9a/lyzcXyNuDxUrpBLsiQ/ewX3ek3Ov9kybIS/69c=; b=ni5OBDa6yxzHpaAlqCiFaSJ5aWeQ7kZcNq5Y2jzS2DzSCzt5CSvvkO6a7gH5t2tnfQ w1wm0aq2IIz0GWFROTUmNXzOIwsVMD9gQop/upr/tfYBnrCPaKFAISALipVmGNjxaHh6 7kx+cMuJvDojAH4OhfpH4KGs6KwuPLt+VtX6uDLVPd5lJ0E7GasMaRQeYvHWHVDOVLNo kXMKlcWEr0wV0TPGv56ILuXE4pNVCM1ntLu3Qny5jBFeAl68dvBNi+lYqvx6MhgCn7Jf 7FNeKoFoBZBomY0blnUTH/4lMaLq0THPqvW7HURjW5FnBbFOrGfV5NwR4Iz14ECmPAsp UbYg== X-Gm-Message-State: AIkVDXIlQPC3VK7jCBkoSdMr1Pp+3deXaYwPJTjZCQyPPepITgsnrmGmdyfWazj0ihDr7/mZs/H12fEsECnx/w== X-Received: by 10.223.160.43 with SMTP id k40mr4685661wrk.24.1484493199128; Sun, 15 Jan 2017 07:13:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Sun, 15 Jan 2017 07:12:58 -0800 (PST) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 15 Jan 2017 16:12:58 +0100 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] RTP Two-Byte Header usage in WebRTC 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: Sun, 15 Jan 2017 15:13:23 -0000 Hi, is there any RTP header extension defined for WebRTC that requires usage of the Two-Byte Header format defined in RFC 5285? AFAIS current WebRTC implementations always use the One-Byte Header format. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Mon Jan 16 01:17:13 2017 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 8980E129431 for ; Mon, 16 Jan 2017 01:17:11 -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, 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 Q7Fwr6xxCcmX for ; Mon, 16 Jan 2017 01:17:10 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 2BD44129521 for ; Mon, 16 Jan 2017 01:17:09 -0800 (PST) X-AuditID: c1b4fb2d-cb3ff7000000029b-13-587c8f93f5cb Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id B0.04.00667.39F8C785; Mon, 16 Jan 2017 10:17:08 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.319.2; Mon, 16 Jan 2017 10:16:06 +0100 To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , "rtcweb@ietf.org" References: From: Magnus Westerlund Message-ID: <48fb6fbd-cdb8-8ef3-934c-8b6ff8a274b2@ericsson.com> Date: Mon, 16 Jan 2017 10:16:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM2K7pe6U/poIg2sPuC2m77OxWPuvnd2B yeNcw3t2jyVLfjIFMEVx2aSk5mSWpRbp2yVwZVw+foW5oJ2v4vT8k0wNjGu4uxg5OSQETCR+ HFjEDmILCaxjlDjWAGRzAdnLGSXuf7/BApIQFrCUaF6wB6xIRCBOYtvNTiaIhgCJthW/weJs AhYSN380soHYvAL2Eq0X3oHFWQRUJfY9/AA2R1QgRuLt+uXsEDWCEidnPgGLcwoESuxtmwvW yww0Z+b884wQtrxE89bZzBC7tCUamjpYJzDyz0LSPgtJyywkLQsYmVcxihanFhfnphsZ66UW ZSYXF+fn6eWllmxiBAbfwS2/dXcwrn7teIhRgINRiYd3w7HqCCHWxLLiytxDjBIczEoivFWt NRFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MFasUr6W lfu/KGVXiU/ovZ7tvSYx8tbONmKHPC6/Lai3nPPwVM+z5I9XVk0+/jXt0qcay29Ck53sqk/c a9pqvuWZt+rX3abXVuSWqbfkOr6e2bPgRsi29Uwzr3p8FrYQ+dZ49yPj+tufJidqV39hNL3L uLdrnkDpgtqg1qMPxI8LXvp2W+z4mwlKLMUZiYZazEXFiQASP1wDOgIAAA== Archived-At: Subject: Re: [rtcweb] RTP Two-Byte Header usage in WebRTC 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: Mon, 16 Jan 2017 09:17:11 -0000 Den 2017-01-15 kl. 16:12, skrev Iñaki Baz Castillo: > Hi, is there any RTP header extension defined for WebRTC that requires > usage of the Two-Byte Header format defined in RFC 5285? AFAIS current > WebRTC implementations always use the One-Byte Header format. > Hi, You will have to support two-byte header extension formats, even if one-byte will be almost always used. The reason for this is that the SDES RTP header extensions can't guarantee that the value they carry is no more than 16 bytes. SDES items can be up to 255 bytes. So the MID is recommended to be short (few bytes), but mandated to be support (WebRTC endpoints) in RTCWEB through the support of BUNDLE. But, so far no requirement to not use longer than 16 bytes I would also expect CNAME RTP header extension to show up, especially in combination with the rapid synchronization RTP header extension. The current CNAME generation recommendation RTP Usage -> RFC7022 does not restrict the CNAME length to no longer than 16 bytes, in fact it only specifies a minimal length of 16 bytes (Due to 96 bits + base64 encoding). Thus, also CNAMEs could result in two-byte headers. I also don't see how we can mandate in RTCWeb context to not use fields that results in only one-byte header extensions. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jan 16 02:46:33 2017 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 421D6126FDC for ; Mon, 16 Jan 2017 02:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 1Zs3B4Rif0DE for ; Mon, 16 Jan 2017 02:46:31 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 8B76F126B6D for ; Mon, 16 Jan 2017 02:46:31 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id c85so153064002wmi.1 for ; Mon, 16 Jan 2017 02:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4p1jkCLqu+88Drsty3oESoTlJkHPwmtQZVwNxpn1Jy4=; b=GppdF407ocaWdlNBB6Ij6noIbvERJCelmDCrFk9K4rCjq5cr+E4oPHwnhd3T9XCJXX WyBU/UaTbUKcnqQedIfzMQm9tQTDbrOFUS4J6oqIPk/LzwcI+jtsPGjgYcHgzZklAZt4 2tgltRtyU6Qmd+en6VJ7LIRVCSlL3yURhsnFKdfI/ZfKGFwFbWrgTxWc1oGUudtETytE PIOdveqU77ua2NmGjP91wxpHVnkyNPpT2LqBAK0f5IcwvPVQfOA50YVYXr7mfau0IDRY u/eFVMOQCW/hY3QEI9ikh0pwMofsTazc1Rp7rxvbWMotgnd0bReBpF5j1KJTi4xYVvBA QsIw== 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:content-transfer-encoding; bh=4p1jkCLqu+88Drsty3oESoTlJkHPwmtQZVwNxpn1Jy4=; b=lOB3/R7ygHhU95BhmOE0qRiP3eqygSvRU05RXrRp2oJSrWWYjzsNcc40nDYvkJ5BW6 2jOAeX64HgQR++uKJbSbmYnO/styFHS2yxVP505CiSq5do6qkGw2eZXrOm4EL8VxaWqh i7Gk0/hYUV4bJuOmJptxn5xWsTlYaDSsnr1mPC8B7oHaQXlJUB4mxc9I3hlFk+K85S21 XAhQCtS5VY821MBHKyGzNjx/yoo8d3T0g7OOdeB/CbaxFqHsfvGMKhJ7ddAPQrG2INbp 7EeawxyLIbx58jL+fJNEyxRe1VDKyj4pRrzwvu5qtr8oBYvmZAj+ZHKobymukp3IIdLU V7vA== X-Gm-Message-State: AIkVDXK4yLJ6J6W4CJnxDunX2HqWxiHlcaVHfnch8gLg8TQDUDE0MLMnOLnq1jPOpvIsgabDc7nj4ArW6ixOfQ== X-Received: by 10.28.25.70 with SMTP id 67mr1394780wmz.125.1484563589173; Mon, 16 Jan 2017 02:46:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Mon, 16 Jan 2017 02:46:08 -0800 (PST) In-Reply-To: <48fb6fbd-cdb8-8ef3-934c-8b6ff8a274b2@ericsson.com> References: <48fb6fbd-cdb8-8ef3-934c-8b6ff8a274b2@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 16 Jan 2017 11:46:08 +0100 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTP Two-Byte Header usage in WebRTC 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: Mon, 16 Jan 2017 10:46:33 -0000 2017-01-16 10:16 GMT+01:00 Magnus Westerlund : > Hi, > > You will have to support two-byte header extension formats, even if one-b= yte > will be almost always used. The reason for this is that the SDES RTP head= er > extensions can't guarantee that the value they carry is no more than 16 > bytes. SDES items can be up to 255 bytes. > > So the MID is recommended to be short (few bytes), but mandated to be > support (WebRTC endpoints) in RTCWEB through the support of BUNDLE. But, = so > far no requirement to not use longer than 16 bytes > > I would also expect CNAME RTP header extension to show up, especially in > combination with the rapid synchronization RTP header extension. The curr= ent > CNAME generation recommendation RTP Usage -> RFC7022 does not restrict th= e > CNAME length to no longer than 16 bytes, in fact it only specifies a mini= mal > length of 16 bytes (Due to 96 bits + base64 encoding). Thus, also CNAMEs > could result in two-byte headers. > > I also don't see how we can mandate in RTCWeb context to not use fields t= hat > results in only one-byte header extensions. Clear, so now I should realize of whether Chrome and Firefox understand Two-Bytes header extensions or not. AFAIS (by taking traces) they just generate One-Byte extensions. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Mon Jan 16 04:19:53 2017 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 DD22312945A for ; Mon, 16 Jan 2017 04:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 uNvTDA_Tw0UC for ; Mon, 16 Jan 2017 04:19:49 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FADE129452 for ; Mon, 16 Jan 2017 04:19:48 -0800 (PST) X-ASG-Debug-ID: 1484569186-05f27556ca37a4d0001-4f8tJD Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id 3cAHx0XBSIGpx54p (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jan 2017 13:19:46 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v0GCJjRP024626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jan 2017 13:19:46 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_8333A98B-74AE-4D34-80F0-A5A1370B635F" Message-Id: <0058ED62-68E1-4B4A-A254-FAD8EC951503@unina.it> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Mon, 16 Jan 2017 13:19:45 +0100 X-ASG-Orig-Subj: Re: Call for papers on WebRTC standardization status References: To: rtcweb@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1484569186 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42: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.35833 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [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: Mon, 16 Jan 2017 12:19:52 -0000 --Apple-Mail=_8333A98B-74AE-4D34-80F0-A5A1370B635F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello guys, just a quick note to inform you that, given the significant number of = requests, we extended the deadline until next Sunday (January 22nd). 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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 21 Dec 2016, at 21:04, Simon Pietro Romano = wrote: >=20 > Hello everybody, >=20 > 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. >=20 > = http://www.comsoc.org/comstandardsmag/cfp/real-time-communications-web-cur= rent-achievements-future-perspectives = >=20 > 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. >=20 > Please bear with me if you believe this was not the case. >=20 > Cheers, >=20 > 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 = >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( = ( ) > \_) ) = / > = (_/ >=20 >=20 >=20 --Apple-Mail=_8333A98B-74AE-4D34-80F0-A5A1370B635F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello guys,

just a quick note to inform you that, given the significant = number of requests, we extended the deadline until next Sunday (January = 22nd).

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~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/



On 21 Dec 2016, at 21:04, Simon Pietro Romano <spromano@unina.it> = wrote:

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=_8333A98B-74AE-4D34-80F0-A5A1370B635F-- From nobody Mon Jan 16 16:08:13 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9865126579; Mon, 16 Jan 2017 16:08:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148461169195.22494.17363997058807705095.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 16:08:11 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-18.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 17 Jan 2017 00:08:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-18.txt Pages : 99 Date : 2017-01-16 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 17 13:50:11 2017 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 8DA7B1294A5 for ; Tue, 17 Jan 2017 13:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 J_8Odlb1zIJQ for ; Tue, 17 Jan 2017 13:50:08 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F5A129495 for ; Tue, 17 Jan 2017 13:50:07 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id l7so182941138qtd.1 for ; Tue, 17 Jan 2017 13:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OeR86ZkdKiFlFfQLcCB7B+6IFUnxL7cQXqM4C4k2S8w=; b=G4emDZvzR6WM+iZwsrG0WpH7d/UHjyTgtlgvOqYVMZO9p6hZ6HbIdglL407EUq4ine JDhcZ1cZSzBIdpuP2DNT7A4jCrt66EZKj7QkwYS2K/C8Q5U1Rt/Gg4fFc+ocpP9assCa UApaUe+XqNWeQ1Eb+g48dWweOgHhoZVq1xYPV/XX38eXOZJkwx1Xvn57zkiyTAQK0TkZ 7bWK5xU+Hj9Nxwv3mlsJstvnxWHvKfyUmFEMoHcmlABXUHNT/3UF5HUcshCVIcI0D5lj QQC/BWpBxg0rNKndl0Qs+2YktJOFOPtokLhH/m5u8fz/0SAK46QLnpjLQV7TILxW2xrL Y9pw== 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=OeR86ZkdKiFlFfQLcCB7B+6IFUnxL7cQXqM4C4k2S8w=; b=lDvcgAmsPXQ27AOYSbEVqHm7/7cF4opLDZ0IgZnzFAFo3ctR+BiQVuZhpTJGibHhI1 m8zqIJXPgSlcRpQoRxfGfYC+jy+OrEO9GUcNCji5dfc/r8QcEXv3/aDoRcxS2Snyjmz0 NX2vGqDVRzzs2Jg7K0oAZAYJpeuXg/RBaFeeMwgIQR+nKfVghwUAIfo/poKFAIcHXLzu 7wFBR3FqcK/KrLP/PmMn3pefVe/bx9t+yIeU8BdOS0e5IlMYj/Yx3GfXWRl6vQOCyouE Nu4QVZRwa/lqDynRuMUsW+QVwCiI5TFEHz2bFPyn0yjVQGaucanelHTmfylaupfM8Hqh ezug== X-Gm-Message-State: AIkVDXLlDRy2QOR4Z4ni6Qr3zRZoOxskQiKcjcRCbqqgSXjA9Vt5F/jPMtqQguSAIooRBtC5P2n53quZne1Kkw== X-Received: by 10.55.8.20 with SMTP id 20mr36777493qki.49.1484689806844; Tue, 17 Jan 2017 13:50:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.226 with HTTP; Tue, 17 Jan 2017 13:49:36 -0800 (PST) From: Ted Hardie Date: Tue, 17 Jan 2017 13:49:36 -0800 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a114c9d608a0a48054651487b Archived-At: Subject: [rtcweb] Working group last call resolutions/Consensus call 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: Tue, 17 Jan 2017 21:50:09 -0000 --001a114c9d608a0a48054651487b Content-Type: text/plain; charset=UTF-8 Howdy, As you can see below, there is a new version of JSEP, which responds to many of the matters raised during Working Group Last Call. Please review it carefully, noting particularly the change log in Appendix C. If you raised an issue, please confirm that you believe it has been addressed or explain why it has not been. The chairs do not plan on issuing individual consensus calls on most issues, but will instead issue a new working group last call after the next update, which will address the issues remaining in the github repo (https://github.com/rtcweb-wg/jsep/issues). The one exception to this is Appendix B. The chairs are hereby issuing a two week consensus call on the algorithm contained in Appendix B, so that this working group can positively affirm that it meets the needs of the WebRTC development community when it is considered by MMUSIC or the wider IETF community. If you do not believe it meets the needs of the WebRTC community, the chairs ask that you respond by explicitly indicating what changes to the algorithm are required or what replacement algorithm you propose. Responses that do not indicate clearly what the algorithm should be will be weighted accordingly. Thanks, and happy reading, Ted, Cullen, and Sean ---------- Forwarded message ---------- From: Date: Mon, Jan 16, 2017 at 4:08 PM Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-18.txt To: i-d-announce@ietf.org Cc: rtcweb@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-18.txt Pages : 99 Date : 2017-01-16 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --001a114c9d608a0a48054651487b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

As you can see below, there is a n= ew=20 version of JSEP, which responds to many of the matters raised during=20 Working Group Last Call.=C2=A0 Please review it carefully, noting=20 particularly the change log in Appendix C.=C2=A0 If you raised an issue,=20 please confirm that you believe it has been addressed or explain why it=20 has not been.=C2=A0 The chairs do not plan on issuing individual consensus= =20 calls on most issues, but will instead issue a new working group last call= =20 after the next update, which will address the issues remaining in the githu= b repo (https://github= .com/rtcweb-wg/jsep/issues).

The one exception to this is=20 Appendix B.=C2=A0 The chairs are hereby issuing a two week consensus call o= n=20 the algorithm contained in Appendix B, so that this working group can=20 positively affirm that it meets the needs of the WebRTC development=20 community when it is considered by MMUSIC or the wider IETF community.=C2= =A0=20

If you do not believe it meets the needs of the WebRTC community, t= he=20 chairs ask that you respond by explicitly indicating=C2=A0 what=20 changes to the algorithm are required or what replacement algorithm you=20 propose.=C2=A0 Responses that do not indicate clearly what the algorithm sh= ould be will be weighted accordingly.

Thanks, and happy readin= g,

Ted, Cullen, and Sean



---------= - Forwarded message ----------
From: = <internet-= drafts@ietf.org>
Date: Mon, Jan 16, 2017 at 4:08 PM
Sub= ject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-18.txt
To: i-d-announce@ietf.org
Cc: rtcweb@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Javascript Session Establishment Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=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 Cullen Jennings
=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 Eric Rescorla
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-jsep-18.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 99
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-16

Abstract:
=C2=A0 =C2=A0This document describes the mechanisms for allowing a Javascri= pt
=C2=A0 =C2=A0application to control the signaling plane of a multimedia ses= sion
=C2=A0 =C2=A0via the interface specified in the W3C RTCPeerConnection API, = and
=C2=A0 =C2=A0discusses how this relates to existing signaling protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-rtcweb-jsep/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtc= web-jsep-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-rtcweb-jsep-18


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--001a114c9d608a0a48054651487b-- From nobody Wed Jan 18 02:01:16 2017 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 7F0CD129430 for ; Wed, 18 Jan 2017 02:01:15 -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, 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 lDvF-Sgr-9Qv for ; Wed, 18 Jan 2017 02:01:14 -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 12E621289C4 for ; Wed, 18 Jan 2017 02:01:13 -0800 (PST) X-AuditID: c1b4fb30-f2fff70000003c8a-7a-587f3ce74ecf Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 01.F9.15498.7EC3F785; Wed, 18 Jan 2017 11:01:12 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.319.2; Wed, 18 Jan 2017 11:02:02 +0100 To: Ted Hardie , "rtcweb@ietf.org" , Cullen Jennings , Sean Turner References: From: Magnus Westerlund Message-ID: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> Date: Wed, 18 Jan 2017 11:01:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7k+4Lm/oIgynPJS06JrNZrP3Xzm5x ZVUjs0XjXDsHFo8pvzeyeuycdZfdY8mSn0weBw8yBrBEcdmkpOZklqUW6dslcGXs/nqZseC7 UcXRn0eYGhjPq3UxcnJICJhItJ79xNLFyMUhJLCOUWLr60PMEM5yRonmH+tZQaqEBcIkWjcc ZwJJiAj0MEo03m5g7GLkAKoKkFiyoxqkhk3AQuLmj0Y2EJtXwF7iYl8rI4jNIqAq8fTpbyYQ W1QgRuLt+uXsEDWCEidnPmEBsTkFAiW+fIYYyQzU+2BrGUiYWUBeonnrbGYQW0hAW6KhqYN1 AiP/LCTdsxA6ZiHpWMDIvIpRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMDwPbvltsIPx5XPH Q4wCHIxKPLwFhnURQqyJZcWVuYcYJTiYlUR431jURwjxpiRWVqUW5ccXleakFh9ilOZgURLn NVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAOFGHyYQtpD6zYO/MqzJzPsapZt+0FIvp4p/m9/Xd wtzzGr7PL284FmvwV6PWSsOoUHrezYu7fxpc67f+bclVm7u27dWr6cuz1VzSDd2qs6yqjsb+ 6FSRkLw4OepYMMvfZbU/gk3jD6UsPlhg8fTAvO/HAm7NkuFxuqectnHhxWWO6ZZ77rcIK7EU ZyQaajEXFScCAJOcpxFLAgAA Archived-At: Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 18 Jan 2017 10:01:15 -0000 Den 2017-01-17 kl. 22:49, skrev Ted Hardie: > The one exception to this is Appendix B. The chairs are hereby issuing > a two week consensus call on the algorithm contained in Appendix B, so > that this working group can positively affirm that it meets the needs of > the WebRTC development community when it is considered by MMUSIC or the > wider IETF community. > Hi, Here is my feedback on Appendix B. I am sorry that sickness, holiday vacations has prevented me to be more proactive on this subject. There was feedback on the proposal Colin Perkins and I put together, which we failed to respond to yet. I have reviewed the emails before responding now. I will attempt to respond to what I consider the high level issues and my views that was brought up in those emails. Regarding PT based routing: RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of packets are not required for any WebRTC endpoint. PT based routing works only in some constrained usages, thus my view is that it needs to remain a hint, and an optional hint at most. It must be clear that it is not something that is reliable. I also struggle to see in what non-WebRTC interop use cases this arises. The non-WebRTC endpoint needs to be capable of multi media source, and multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggregating gateway, that is to lazy to add MIDs? On the packet level routing description: The issue I have had previously and to some degree also with the current appendix B is that it is described in a fashion that appears to match a particular RTP stack implementation. And I have to note that it is not like the two RTP stack implementations I have been involved designing. Thus, the description at its level of specificity does not fit what I would do. It also does not let the RTP concepts work for you, instead this is injected in the bottom of the stack. The text I talk about is the following: For each RTP packet received, the following steps MUST be followed to route the packet to the correct "m=" section within a BUNDLE group. Note that the phrase 'deliver a packet to the "m=" line' means to further process the packet as would normally happen with RTP/RTCP, if it were received on a transport associated with that "m=" line outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd), including dropping an RTP packet if the packet's PT does not match any PT in the "m=" line. If the packet has a MID and that MID is not in the table mapping MID to "m=" line, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID to "m=" line, update the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the "m=" line for that MID. If the packet's SSRC is in the incoming SSRC mapping table, route the packet to the associated "m=" line and stop. If the packet's payload type is in the payload type table, update the the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the "m=" line for that payload type. In addition, route the packet to the associated "m=" line and stop. Otherwise, drop the packet. If I would write this packet level routing it would work with the concepts of the RTP protocol: This the bullet list would look like this instead: 1. Reception of an RTP packet for a SSRC with an existing association to an m= line, with a MID RTP header extension, the MID value is checked. If it matches the existing association, then the processing continues in that m= line context. If the value is a new value, then the association to the m= line is updated, and then the packet is processed in the new m= line context. 2. Reception of an RTP packet with an SSRC that has an existing mapping to an m= line is processed in that m= line context. 3. Reception of an RTP packet with a previously unknown SSRC that contains an MID RTP header extension, will result in that SSRC be associated with the corresponding m= line. The packet is then processed in this m= line context. 4. Reception of an RTP packet with an SSRC that has no association to any m= line is processed by the RTP protocol implementation for statistics, etc. but is then dropped. I would not route on PT, but in this style of description the PT routing would look like the below bullet, but I would prefer to skip it. It should be inserted second to last of the bullets, i.e. between 3 and 4. 3.5 Reception of a previously unknown SSRC that contains an PT value that exists in the payload type mapping table, will result in that SSRC be associated with the corresponding m= line. However, the above is not sufficient, it also needs an amendment to bullet 2, where if the PT value does not match the m= line context the association needs to be updated. For the RTCP part the appendix B description is even more foreign to my implementations. As the implementations will process the information of the incoming RTCP compound packet and then provide API that notifies the higher layer of the changes of interest. Like for example the reception of a Feedback Request, or the change to a SDES item for a particular SSRC. Thus the actions related to RTCP becomes even more abstract. Where the description says "deliver a copy of the RTCP packet to the "m=" line associated with that SSRC" I would say "Process the information in the context of the m= line that is associated with the SSRC". So my conclusion is that the current issue is how we find a specific enough description that at the same time does not restrict how you implement your RTP stack. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jan 18 02:07:44 2017 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 029911294FE for ; Wed, 18 Jan 2017 02:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 9_6i2Pz1RAx0 for ; Wed, 18 Jan 2017 02:07:40 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 436001293FB for ; Wed, 18 Jan 2017 02:07:40 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id c85so237547824wmi.1 for ; Wed, 18 Jan 2017 02:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iAgZHLmI0CGpcySo4OK8MfSSvIQbjYk39oeprkkwums=; b=l1NN1InVbtTKMcCJj5MTqZ51eHdg13dsFGQzhKKSkaevK8g10E3KXILYmLVm619dEY 6HG6+ccsjpEn/w/GBkax67YrSy+Ktvt6Hpoivv3KY/52Kkw6s4tP2IOXs7ADjbVAPQ/J /nTOuDziEqMhYpDCwHzGI8vQ+QtseibJaN2soH5UO+kI2yQOZebb/NsIlZDJZQrJZvMO zkES0JJdi/LAIdQy8Rz1zqbTSvze+VxMCy8Hpgrfto/aaUNXsGOyMXkgBKHue0tfaPF+ rIwTYm8aQEvM2EhkFFipTgiuwyJ70OmwE0heVm7qvAaFbu4wWHKOzl6YPY4ThO2fg2O4 1Kxg== 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:content-transfer-encoding; bh=iAgZHLmI0CGpcySo4OK8MfSSvIQbjYk39oeprkkwums=; b=PO92/uJ2fdQoxbFhDhfEqIoCs/Ie+iGQk6nOx/Q2subdUo2MPg/mCsWy2HNdcPe3kj Myi3p+byG75PdXiCXNbu/TWia+76cmWJzvCBymJLAUYABKHpR3oyDI2ekqiLpZ3EjF9m iLShUY+wC0tWUyAmbJGoAErg7TTixZttXbzJ1cLHkDxrz2JaQLwiEbyX4B/dtc3SFV8Y TCSlRxcpBlWQpdbo0Fb+OkTp9Uko/PQvX+Zb7nGtyVnFFsSSopyMed66T2MYUCKq0Pn7 biQbDTvWYuTxS7ANgAk7yDbtGPF2qnAcMS/RxRbeOQDXvb8iKa4PkZ5dJuda+MK9cMr7 Jpxg== X-Gm-Message-State: AIkVDXLkuo0ZN/ilaBYpjN+CjhEk7YR1ShxU2xiyej4T1QZh33fEDto41Jr0wfOXNBMcOH/7LwEPWszZnL8NzA== X-Received: by 10.223.133.226 with SMTP id 31mr1977010wru.137.1484734058671; Wed, 18 Jan 2017 02:07:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Wed, 18 Jan 2017 02:07:18 -0800 (PST) In-Reply-To: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Jan 2017 11:07:18 +0100 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 18 Jan 2017 10:07:42 -0000 2017-01-18 11:01 GMT+01:00 Magnus Westerlund : > PT based routing works only in some constrained usages, thus my view is t= hat > it needs to remain a hint, and an optional hint at most. Fully agreed. It has no value other than receiving stream(s) from a single remote media source per RTP session (transport). --=20 I=C3=B1aki Baz Castillo From nobody Wed Jan 18 06:52:58 2017 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 42BA7129861 for ; Wed, 18 Jan 2017 06:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lvZv9KA-qAOl for ; Wed, 18 Jan 2017 06:52:51 -0800 (PST) Received: from smtp129.dfw.emailsrvr.com (smtp129.dfw.emailsrvr.com [67.192.241.129]) (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 9BB1512985F for ; Wed, 18 Jan 2017 06:52:51 -0800 (PST) Received: from smtp29.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 276FA406A5; Wed, 18 Jan 2017 09:52:51 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B85C140574; Wed, 18 Jan 2017 09:52:50 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 18 Jan 2017 09:52:51 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> Date: Wed, 18 Jan 2017 07:52:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3259) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 18 Jan 2017 14:52:53 -0000 > On Jan 18, 2017, at 3:01 AM, Magnus Westerlund = wrote: >=20 >=20 > Regarding PT based routing: >=20 > RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of = packets are not required for any WebRTC endpoint. Look, I don't see it this way and I suspect you are going to agree with = what I say next.... WebRTC browsers are required to interoperate with = "legacy" things that don't do bundle and things that may do bundle but = try not to use MIDs in cases where they are a gratuitous waste of = bandwidth.=20 > PT based routing works only in some constrained usages, thus my view = is that it needs to remain a hint, and an optional hint at most. > It must be clear that it is not something that is reliable. You keep asserting this but I'm not convinced you are are correct so = perhaps you could explain the where they don't work. I seen lots of = projects ship this and work fine. The algorithm in appendix B make it = clear PT are only used if they are unique across all the m-lines. So = clearly it can not be used if you need more PT than are available in the = PT space. A huge percentage of of real world use cases for SDP easily = fit inside the current PT space. One of the cases I care about if a low = peak bandwidth phone (not average) for places like parts of Africa that = uses a 700 bps codec. Most single stream of audio and video "video phone = call" type cases also easily work. Yes, I understand one could construct = some single audio/video where enough things were the SDP offer needs = more PTs than there was space for but if you look at the SDP from just = about every major manufacture of VoIP audio phones, you see what they = are currently doing can easily be done with unique PT values. Anyway, = for these case where you don't run out of PT, please please explain why = PT routing is so broken that is should be an optional hint. In practice = it seems to work fine.=20 Anyways, I'm just not seeing what you think the problem is here. I don't = see a problem so I feel pretty strongly that the algorithm in Appendix B = is fine. Convince me on why is "not reliable" and and "only in some = constrained usages" > I also struggle to see in what non-WebRTC interop use cases this = arises. The non-WebRTC endpoint needs to be capable of multi media = source, and multi stream (SSRC) RTP sessions, but not implement BUNDLE. = Or is it a aggregating gateway, that is to lazy to add MIDs? >=20 People want to avoid the media gateway between WebRTC and and an SIP = endpoint where they can. The media gateway adds latency - huge amounts = in the case where both endpoints require a satellite hop to get to the = gateway - and it add the bandwidth expenses of running gateway.=20 On all of this, I want to be clear, for people that want to do something = where the PT space is not large enough, obviously they can use MID, I'm = just saying that for things that don't use MID, and can fit in the PT = space, it should be an option to use PT and know it will work.=20 From nobody Wed Jan 18 06:57:40 2017 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 E5A4D127076 for ; Wed, 18 Jan 2017 06:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 Teby929oEfbO for ; Wed, 18 Jan 2017 06:57:37 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 23BBE1293E1 for ; Wed, 18 Jan 2017 06:57:37 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id c85so247694697wmi.1 for ; Wed, 18 Jan 2017 06:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Mh0Lkh3obZeoL79vwJtbkFk6cPwcXmyyRttGWOPskgA=; b=atxEKgYH3LGWhDM8NLqgM70hE+BMPHkyuaM07oBLKFNbk4QTf8ZwPg9yuIiV7WeGri oqTGSgNzc5XjQKkpdSfpdHxDmojGApbpysDoNLbHT4IceGZiDh8Cw4rMioIgAYIcPHNV cphzvBYsB63sPGi/YKzf5nXpCQTLXe7A1kYjfWPSMBGoLaIqPQGebHZyPHVi0JvdZeJs aAmBwsHpbDy5sl6SBkMi3pZrpiV6ra+rnGpuXdLbZojs5T40pp2CYl+sxbXs3hKLlImb WHU+WH1dPjamNDchQRN67+kP1CRWmzF/kkxw8SqLkRkNE5qR0fCObvQyny7e3jgt9nIK qJVA== 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:content-transfer-encoding; bh=Mh0Lkh3obZeoL79vwJtbkFk6cPwcXmyyRttGWOPskgA=; b=RXvr5kKDldokUv3Vaha2myng+uDQNETH6f/85F8nS4LeuG5jnDA29spZKsWo8X6TRm Xb+WpKfKNRJM9apT0k5b+TPviFIn9Ph3WH569Pd7zU2dcynxbqNa15aEdYAxshTwFHRQ gFO3KQiol8FgyDb/Pp/qYkK4Fzjo2N4UBrZiGBrZfJ3ZDi0nSvO7kHjQcJPdMP2zm16J r1UdavsIkQSrj9Av13tpToA9q7VTlfHbROhe3XggRDswOYFVVSGsf9oUB/TYNPZx0Hhr nSZm40mDmUYRKFLcia7/7kJhGkX+Pp/wrQWt95yCiNKZ5LjlW+oazIcY+6uqLd4GitrG ZhVw== X-Gm-Message-State: AIkVDXLzUZgbgj8Ru0B5qeUM8tdayYKRp5ADXVy24NH24t8LynX5Q5yX3GvxvWbs05Pt5nVe1fdOqG0Nl538Hg== X-Received: by 10.223.133.226 with SMTP id 31mr3082063wru.137.1484751455545; Wed, 18 Jan 2017 06:57:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Wed, 18 Jan 2017 06:57:15 -0800 (PST) In-Reply-To: References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Jan 2017 15:57:15 +0100 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 18 Jan 2017 14:57:39 -0000 2017-01-18 15:52 GMT+01:00 Cullen Jennings : > please please explain why PT routing is so broken that is should be an op= tional hint. In practice it seems to work fine. Multi-stream. --=20 I=C3=B1aki Baz Castillo From nobody Wed Jan 18 07:45:31 2017 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 CD42B12943D for ; Wed, 18 Jan 2017 07:45:30 -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 dAne_8MMmQ32 for ; Wed, 18 Jan 2017 07:45:28 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 3C615127076 for ; Wed, 18 Jan 2017 07:45:28 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id 35so12174807uak.1 for ; Wed, 18 Jan 2017 07:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xYJx5c4S6FNyvKrjpD5UxuHtaAWAuQVgrzohu7/viTk=; b=Si0GKkpqXO5ERU/38G/cgcsoEwovPFOA3lChmlvvlaXhi0jnt6Xp+nA/Bgkl/CZUjO 5YpfrWZ+gEbWBP9so5GLPYjmB59iB6dAfXUfBNAfSFj8COzkW2He4iaShlQaArS/BrCI Bl4DiDrxwT9vQEHTdmL7E/AtDZwFhdDosWAB9eGx+aKgYQ0+AE4xp93ufqYgVf4rahQq bGrob+RH9ASahq8SHT+OljnT06JmS3lpR+nA3/4sxIFKAbDHfZm94IdHAO/sa6J6txs9 VnuBCvas71IqSUVX2MyY6uCLaZTZTJ6EJU/K8r8p8o+SmBUUUnKfj+0t9UI3ACiDX92C dvqg== 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=xYJx5c4S6FNyvKrjpD5UxuHtaAWAuQVgrzohu7/viTk=; b=VbapAXK8OwlkIpij5m2x0p1qo4F+mDDOxvjrHS45ovR5fcZ9JG5/FqpKkCda4LGy4N 262UF7B11hyi49hiUni7LJU7wbznPv/punXHBV/u7XX2TC0mHAyhRBcicT7kDjiGEgsX 68KMdcf8my2dQpCCL+pdmzn5BRhLauFMmoQMShggei70nRGi/aYd/AKd1HpJJIb6ffVG ot/qxptxX2vUczZV6S8dQFL6gZbPwWUwSxvusWXDPe97LkTjDqRGtPYO6vS54NSCCUlF NtHRn9bWrNxJTH9HmtfwJbrxJbTKxA2mSG5/J/h3xud0/NYv6QnRpxH5D+Oagjn6kD8c Upfw== X-Gm-Message-State: AIkVDXKx+sl1SDNjDB1wenHD00TQQyb9d3Ox2u6uN8AS6KzdAmv4SkGVed5sHXsM7oVXvznkG0dOAN3vJ37vLA== X-Received: by 10.176.16.236 with SMTP id x44mr1812375uab.162.1484754327086; Wed, 18 Jan 2017 07:45:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.37 with HTTP; Wed, 18 Jan 2017 07:45:06 -0800 (PST) In-Reply-To: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: Bernard Aboba Date: Wed, 18 Jan 2017 07:45:06 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c1cfa083ee4400546604e76 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 18 Jan 2017 15:45:31 -0000 --94eb2c1cfa083ee4400546604e76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Magnus said: "RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of packets are not required for any WebRTC endpoint." [BA] BUNDLE (and RTP/RTCP mux) is very popular in WebRTC applications. But apparently so is PT-based routing. Bugs are showing up even in basic audio/video applications (where the PT is unique). Since MID is not yet implemented, no existing applications support it. Since many mobile application developers sync infrequently to updated source bases, once MID is implemented it may take several years for applications to incorporate it. It would not even surprise me if some very popular mobile applications currently using PT-based routing do not transition to MID. "PT based routing works only in some constrained usages, thus my view is that it needs to remain a hint, and an optional hint at most. It must be clear that it is not something that is reliable." [BA] While it's not necessary to handle every conceivable scenario, defining the behavior in the "constrained usages" would help. "I also struggle to see in what non-WebRTC interop use cases this arises. The non-WebRTC endpoint needs to be capable of multi media source, and multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggregating gateway, that is to lazy to add MIDs?" [BA] There are basic scenarios where an audio and a video stream are BUNDLEd which do not behave consistently today. Looking at the bug reports, it would appear to me that the problems originated in inconsistent implementation of basic RFCs such as 3264 and 5576. On Wed, Jan 18, 2017 at 2:01 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2017-01-17 kl. 22:49, skrev Ted Hardie: > >> The one exception to this is Appendix B. The chairs are hereby issuing >> a two week consensus call on the algorithm contained in Appendix B, so >> that this working group can positively affirm that it meets the needs of >> the WebRTC development community when it is considered by MMUSIC or the >> wider IETF community. >> >> > Hi, > > Here is my feedback on Appendix B. I am sorry that sickness, > holiday vacations has prevented me to be more proactive on this subject. > > There was feedback on the proposal Colin Perkins and I put together, whic= h > we failed to respond to yet. I have reviewed the emails before responding > now. I will attempt to respond to what I consider the high level issues a= nd > my views that was brought up in those emails. > > Regarding PT based routing: > > RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of > packets are not required for any WebRTC endpoint. PT based routing works > only in some constrained usages, thus my view is that it needs to remain = a > hint, and an optional hint at most. It must be clear that it is not > something that is reliable. I also struggle to see in what non-WebRTC > interop use cases this arises. The non-WebRTC endpoint needs to be capabl= e > of multi media source, and multi stream (SSRC) RTP sessions, but not > implement BUNDLE. Or is it a aggregating gateway, that is to lazy to add > MIDs? > > > On the packet level routing description: The issue I have had previously > and to some degree also with the current appendix B is that it is describ= ed > in a fashion that appears to match a particular RTP stack implementation. > And I have to note that it is not like the two RTP stack implementations = I > have been involved designing. Thus, the description at its level of > specificity does not fit what I would do. It also does not let the RTP > concepts work for you, instead this is injected in the bottom of the stac= k. > > The text I talk about is the following: > > For each RTP packet received, the following steps MUST be followed to > route the packet to the correct "m=3D" section within a BUNDLE group. > Note that the phrase 'deliver a packet to the "m=3D" line' means to > further process the packet as would normally happen with RTP/RTCP, if > it were received on a transport associated with that "m=3D" line > outside of a BUNDLE group (i.e., if the "m=3D" line were not BUNDLEd), > including dropping an RTP packet if the packet's PT does not match > any PT in the "m=3D" line. > > If the packet has a MID and that MID is not in the table mapping > MID to "m=3D" line, drop the packet and stop. > > If the packet has a MID and that MID is in the table mapping MID > to "m=3D" line, update the incoming SSRC mapping table to include a= n > entry that maps the packet's SSRC to the "m=3D" line for that MID. > > If the packet's SSRC is in the incoming SSRC mapping table, route > the packet to the associated "m=3D" line and stop. > > If the packet's payload type is in the payload type table, update > the the incoming SSRC mapping table to include an entry that maps > the packet's SSRC to the "m=3D" line for that payload type. In > addition, route the packet to the associated "m=3D" line and stop. > > Otherwise, drop the packet. > > If I would write this packet level routing it would work with the concept= s > of the RTP protocol: > > This the bullet list would look like this instead: > > 1. Reception of an RTP packet for a SSRC with an existing > association to an m=3D line, with a MID RTP header extension, the > MID value is checked. If it matches the existing association, > then the processing continues in that m=3D line context. If > the value is a new value, then the association to the m=3D line > is updated, and then the packet is processed in the new m=3D line > context. > > 2. Reception of an RTP packet with an SSRC that has > an existing mapping to an m=3D line is processed in that > m=3D line context. > > 3. Reception of an RTP packet with a previously unknown SSRC that > contains an MID RTP header extension, will result in that SSRC > be associated with the corresponding m=3D line. The packet is > then processed in this m=3D line context. > > 4. Reception of an RTP packet with an SSRC that has no association > to any m=3D line is processed by the RTP protocol implementation > for statistics, etc. but is then dropped. > > I would not route on PT, but in this style of description the PT routing > would look like the below bullet, but I would prefer to skip it. It shoul= d > be inserted second to last of the bullets, i.e. between 3 and 4. > > 3.5 Reception of a previously unknown SSRC that > contains an PT value that exists in the payload type mapping > table, will result in that SSRC be associated with the > corresponding m=3D line. > > However, the above is not sufficient, it also needs an amendment to bulle= t > 2, where if the PT value does not match the m=3D line context the associa= tion > needs to be updated. > > For the RTCP part the appendix B description is even more foreign to my > implementations. As the implementations will process the information of t= he > incoming RTCP compound packet and then provide API that notifies the high= er > layer of the changes of interest. Like for example the reception of a > Feedback Request, or the change to a SDES item for a particular SSRC. Thu= s > the actions related to RTCP becomes even more abstract. Where the > description says "deliver a copy of the RTCP packet to the "m=3D" line > associated with that SSRC" I would say "Process the information in the > context of the m=3D line that is associated with the SSRC". > > So my conclusion is that the current issue is how we find a specific > enough description that at the same time does not restrict how you > implement your RTP stack. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c1cfa083ee4400546604e76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Magnus said:=C2=A0

"RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT ba= sed routing of packets are not required for any WebRTC endpoint."

[BA] BUNDLE (and RTP/RTCP mux) is very popular = in WebRTC applications.=C2=A0 But apparently so is PT-based routing.=C2=A0 = Bugs are showing up even in basic audio/video applications (where the PT is= unique).=C2=A0

Since MID is not yet implemented, = no existing applications support it.=C2=A0 Since many mobile application de= velopers sync infrequently to updated source bases, once MID is implemented= it may take several years for applications to incorporate it.=C2=A0 It wou= ld not even surprise me if some very popular mobile applications currently = using PT-based routing do not transition to MID.=C2=A0

=
"PT based routing works only in = some constrained usages, thus my view is that it needs to remain a hint, an= d an optional hint at most. It must be clear that it is not something that = is reliable."

[BA] While it's not ne= cessary to handle every conceivable scenario, defining the behavior in the = "constrained usages" would help. =C2=A0

"I also struggle to see in what non-WebRTC interop use cases this= arises. The non-WebRTC endpoint needs to be capable of multi media source,= and multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a= aggregating gateway, that is to lazy to add MIDs?"

[BA] There are basic scenarios where an audio and a video= stream are BUNDLEd which do not behave consistently today.=C2=A0 Looking a= t the bug reports, it would appear to me that the problems originated in in= consistent implementation of basic RFCs such as 3264 and 5576. =C2=A0
=

On Wed, Jan= 18, 2017 at 2:01 AM, Magnus Westerlund <magnus.westerlund@er= icsson.com> wrote:
Den 2017= -01-17 kl. 22:49, skrev Ted Hardie:
The one exception to this is Appendix B.=C2=A0 The chairs are hereby issuin= g
a two week consensus call on the algorithm contained in Appendix B, so
that this working group can positively affirm that it meets the needs of the WebRTC development community when it is considered by MMUSIC or the
wider IETF community.


Hi,

Here is my feedback on Appendix B. I am sorry that sickness,
holiday vacations has prevented me to be more proactive on this subject.
There was feedback on the proposal Colin Perkins and I put together, which = we failed to respond to yet. I have reviewed the emails before responding n= ow. I will attempt to respond to what I consider the high level issues and = my views that was brought up in those emails.

Regarding PT based routing:

RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of pack= ets are not required for any WebRTC endpoint. PT based routing works only i= n some constrained usages, thus my view is that it needs to remain a hint, = and an optional hint at most. It must be clear that it is not something tha= t is reliable. I also struggle to see in what non-WebRTC interop use cases = this arises. The non-WebRTC endpoint needs to be capable of multi media sou= rce, and multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is = it a aggregating gateway, that is to lazy to add MIDs?


On the packet level routing description: The issue I have had previously an= d to some degree also with the current appendix B is that it is described i= n a fashion that appears to match a particular RTP stack implementation. An= d I have to note that it is not like the two RTP stack implementations I ha= ve been involved designing. Thus, the description at its level of specifici= ty does not fit what I would do. It also does not let the RTP concepts work= for you, instead this is injected in the bottom of the stack.

The text I talk about is the following:

=C2=A0 For each RTP packet received, the following steps MUST be followed t= o
=C2=A0 =C2=A0route the packet to the correct "m=3D" section withi= n a BUNDLE group.
=C2=A0 =C2=A0Note that the phrase 'deliver a packet to the "m=3D&q= uot; line' means to
=C2=A0 =C2=A0further process the packet as would normally happen with RTP/R= TCP, if
=C2=A0 =C2=A0it were received on a transport associated with that "m= =3D" line
=C2=A0 =C2=A0outside of a BUNDLE group (i.e., if the "m=3D" line = were not BUNDLEd),
=C2=A0 =C2=A0including dropping an RTP packet if the packet's PT does n= ot match
=C2=A0 =C2=A0any PT in the "m=3D" line.

=C2=A0 =C2=A0 =C2=A0 If the packet has a MID and that MID is not in the tab= le mapping
=C2=A0 =C2=A0 =C2=A0 MID to "m=3D" line, drop the packet and stop= .

=C2=A0 =C2=A0 =C2=A0 If the packet has a MID and that MID is in the table m= apping MID
=C2=A0 =C2=A0 =C2=A0 to "m=3D" line, update the incoming SSRC map= ping table to include an
=C2=A0 =C2=A0 =C2=A0 entry that maps the packet's SSRC to the "m= =3D" line for that MID.

=C2=A0 =C2=A0 =C2=A0 If the packet's SSRC is in the incoming SSRC mappi= ng table, route
=C2=A0 =C2=A0 =C2=A0 the packet to the associated "m=3D" line and= stop.

=C2=A0 =C2=A0 =C2=A0 If the packet's payload type is in the payload typ= e table, update
=C2=A0 =C2=A0 =C2=A0 the the incoming SSRC mapping table to include an entr= y that maps
=C2=A0 =C2=A0 =C2=A0 the packet's SSRC to the "m=3D" line for= that payload type.=C2=A0 In
=C2=A0 =C2=A0 =C2=A0 addition, route the packet to the associated "m= =3D" line and stop.

=C2=A0 =C2=A0 =C2=A0 Otherwise, drop the packet.

If I would write this packet level routing it would work with the concepts = of the RTP protocol:

This the bullet list would look like this instead:

=C2=A0 =C2=A0 =C2=A01. Reception of an RTP packet for a SSRC with an existi= ng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 association to an m=3D line, with a MID RTP hea= der extension, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MID value is checked. If it matches the existin= g association,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 then the processing continues in that m=3D line= context. If
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the value is a new value, then the association = to the m=3D line
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is updated, and then the packet is processed in= the new m=3D line
=C2=A0 =C2=A0 =C2=A0 =C2=A0 context.

=C2=A0 =C2=A0 =C2=A02. Reception of an RTP packet with an SSRC that has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 an existing mapping to an m=3D line is processe= d in that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 m=3D line context.

=C2=A0 =C2=A0 =C2=A03. Reception of an RTP packet with a previously unknown= SSRC that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 contains an MID RTP header extension, will resu= lt in that SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be associated with the corresponding m=3D line.= The packet is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 then processed in this m=3D line context.
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A04. Reception of an RTP packet with an SSRC that has no = association
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to any m=3D line is processed by the RTP protoc= ol implementation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for statistics, etc. but is then dropped.

I would not route on PT, but in this style of description the PT routing wo= uld look like the below bullet, but I would prefer to skip it. It should be= inserted second to last of the bullets, i.e. between 3 and 4.

=C2=A0 =C2=A0 =C2=A0 3.5 Reception of a previously unknown SSRC that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 contains an PT value that exists in the payload= type mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 table, will result in that SSRC be associated w= ith the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 corresponding m=3D line.

However, the above is not sufficient, it also needs an amendment to bullet = 2, where if the PT value does not match the m=3D line context the associati= on needs to be updated.

For the RTCP part the appendix B description is even more foreign to my imp= lementations. As the implementations will process the information of the in= coming RTCP compound packet and then provide API that notifies the higher l= ayer of the changes of interest. Like for example the reception of a Feedba= ck Request, or the change to a SDES item for a particular SSRC. Thus the ac= tions related to RTCP becomes even more abstract. Where the description say= s "deliver a copy of the RTCP packet to the "m=3D" line asso= ciated with that SSRC" I would say "Process the information in th= e context of the m=3D line that is associated with the SSRC".

So my conclusion is that the current issue is how we find a specific enough= description that at the same time does not restrict how you implement your= RTP stack.

Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=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| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----

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

--94eb2c1cfa083ee4400546604e76-- From nobody Wed Jan 18 09:34:34 2017 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 E7BFE129512 for ; Wed, 18 Jan 2017 09:34:32 -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 mloDbbvbuMt3 for ; Wed, 18 Jan 2017 09:34:30 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 3CBDE1294A9 for ; Wed, 18 Jan 2017 09:34:30 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id y9so14769864uae.2 for ; Wed, 18 Jan 2017 09:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GmRUTJ5xOb9PHwa3OuHW1rmjtM51uBuxKdiDOOK4jv0=; b=IIJ/A1IIVbYP4bvel+bhWdnpmlKufklahl5O7a3Io31LgHc6Hvx7ofKGF2DRfiEopV 1tLyKn2px0Hk+iqwB5fmrWD07vEK0Z965WO22pkY62M91obEV0kfHrGFg/3jAUbYm/ZL jVCr8Lw6BS5UuvrbSqB5AWISJ+J39PnqJ7KHXKmp2QUbmt7S1fk7k8z6/g72BVbPaGFk D2oN2GYEvQBWUrQMYAgKiFf3cN4CVdmcHwW34CifmaRFgj0qZ42pz9z4hNKOMbZe1W7n phtmvABOdFLRHmF5Aem0OzHWrkGG3MP7XaC1rXyGtALvPZRW1ytYnr4kEVGnXzm2j6vS 7O6w== 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=GmRUTJ5xOb9PHwa3OuHW1rmjtM51uBuxKdiDOOK4jv0=; b=i/LOfog8w/yVSs2Td+yZLPZxJ6FFmG4BmaUvL/PEoqdij2zQKECo/LH4D5We0wXON/ WWAV/c9mTq00j9PNOA9AU7tP98Tf84/AjPL+AYB9R4xRKfmJtwAugLTMOoHewpZha7e5 bXjB/ckw4ffkvud2o50Ls9shn1BKUOADXr5wUcJ5HbQ6XP6MWiheN1d1oGKn0W3cklvt qrx1IOYRMwP4aMVzJMpGOQ69pBfvUVVBnE6nn96Uf6eG0KhDrf56Z+7sjEugloPEslf0 VOO1gzYJB+BlwwIHFGlL3GR/DUv8xMa53BPl9bVU8xDL/hKip+5Uin+WD+UrqntXlNDL DZaw== X-Gm-Message-State: AIkVDXIXpOxIljhvwyyJl7bbJVOe6JafpXX71Wb47jsVsduTsU5DzeD1Dkqoj6GShHKwzx9xXJ/HckXVomYqLQ== X-Received: by 10.176.3.196 with SMTP id 62mr2425646uau.120.1484760869162; Wed, 18 Jan 2017 09:34:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.3.163 with HTTP; Wed, 18 Jan 2017 09:34:07 -0800 (PST) In-Reply-To: References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: Bernard Aboba Date: Wed, 18 Jan 2017 09:34:07 -0800 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a11487a0e2ed543054661d450 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 18 Jan 2017 17:34:33 -0000 --001a11487a0e2ed543054661d450 Content-Type: text/plain; charset=UTF-8 Cullen said: "Look, I don't see it this way and I suspect you are going to agree with what I say next.... WebRTC browsers are required to interoperate with "legacy" things that don't do bundle and things that may do bundle but try not to use MIDs in cases where they are a gratuitous waste of bandwidth." [BA] +1. There is definitely an expectation on the part of developers that WebRTC will behave like the "legacy" SDP they are used to - even if they are not interoperating with legacy applications. Since those applications worked without MIDs, developers will expect them to continue to work when MID support is introduced in future. "I seen lots of projects ship this and work fine. The algorithm in appendix B make it clear PT are only used if they are unique across all the m-lines. So clearly it can not be used if you need more PT than are available in the PT space. A huge percentage of of real world use cases for SDP easily fit inside the current PT space." [BA] +1. My experience is that *most* of the developers shipping WebRTC applications that run on multiple browsers are using PT-based routing, so they'd be very surprised to learn that it isn't supported (and they would probably push back vigorously at such a notion). "Anyways, I'm just not seeing what you think the problem is here. I don't see a problem so I feel pretty strongly that the algorithm in Appendix B is fine." [BA] The algorithm in Appendix B includes PT routing and I'd like it to continue to cover that. The algorithm appears to resolve a number of bugs filed by both WebRTC and ORTC developers. It will take a bit more review to confirm that it doesn't cause any regressions. On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings wrote: > > > On Jan 18, 2017, at 3:01 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > > > > > Regarding PT based routing: > > > > RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of > packets are not required for any WebRTC endpoint. > > Look, I don't see it this way and I suspect you are going to agree with > what I say next.... WebRTC browsers are required to interoperate with > "legacy" things that don't do bundle and things that may do bundle but try > not to use MIDs in cases where they are a gratuitous waste of bandwidth. > > > PT based routing works only in some constrained usages, thus my view is > that it needs to remain a hint, and an optional hint at most. > > It must be clear that it is not something that is reliable. > > You keep asserting this but I'm not convinced you are are correct so > perhaps you could explain the where they don't work. I seen lots of > projects ship this and work fine. The algorithm in appendix B make it clear > PT are only used if they are unique across all the m-lines. So clearly it > can not be used if you need more PT than are available in the PT space. A > huge percentage of of real world use cases for SDP easily fit inside the > current PT space. One of the cases I care about if a low peak bandwidth > phone (not average) for places like parts of Africa that uses a 700 bps > codec. Most single stream of audio and video "video phone call" type cases > also easily work. Yes, I understand one could construct some single > audio/video where enough things were the SDP offer needs more PTs than > there was space for but if you look at the SDP from just about every major > manufacture of VoIP audio phones, you see what they are currently doing can > easily be done with unique PT values. Anyway, for these > case where you don't run out of PT, please please explain why PT routing > is so broken that is should be an optional hint. In practice it seems to > work fine. > > Anyways, I'm just not seeing what you think the problem is here. I don't > see a problem so I feel pretty strongly that the algorithm in Appendix B is > fine. Convince me on why is "not reliable" and and "only in some > constrained usages" > > > I also struggle to see in what non-WebRTC interop use cases this arises. > The non-WebRTC endpoint needs to be capable of multi media source, and > multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a > aggregating gateway, that is to lazy to add MIDs? > > > > > People want to avoid the media gateway between WebRTC and and an SIP > endpoint where they can. The media gateway adds latency - huge amounts in > the case where both endpoints require a satellite hop to get to the gateway > - and it add the bandwidth expenses of running gateway. > > > > On all of this, I want to be clear, for people that want to do something > where the PT space is not large enough, obviously they can use MID, I'm > just saying that for things that don't use MID, and can fit in the PT > space, it should be an option to use PT and know it will work. > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11487a0e2ed543054661d450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cullen said:=C2=A0

"Look, I don't see it this way and I suspect you are = going to agree with what I say next.... WebRTC browsers are required to int= eroperate with "legacy" things that don't do bundle and thing= s that may do bundle but try not to use MIDs in cases where they are a grat= uitous waste of bandwidth."

[BA] +1. = =C2=A0 There is definitely an expectation on the part of developers that We= bRTC will behave like the "legacy" SDP they are used to - even if= they are not interoperating with legacy applications.=C2=A0 Since those ap= plications worked without MIDs, developers will expect them to continue to = work when MID support is introduced in future.=C2=A0

"I seen lots of projects ship this= and work fine. The algorithm in appendix B make it clear PT are only used = if they are unique across all the m-lines. So clearly it can not be used if= you need more PT than are available in the PT space. A huge percentage of = of real world use cases for SDP easily fit inside the current PT space.&quo= t;

= [BA] +1.=C2=A0 My experience is that *most= * of the developers shipping WebRTC applications that run on multiple brows= ers are using PT-based routing, so they'd be very surprised to learn th= at it isn't supported (and they would probably push back vigorously at = such a notion).=C2=A0
"Anyways, I'm just not seeing what you think the = problem is here. I don't see a problem so I feel pretty strongly that t= he algorithm in Appendix B is fine.= "

<= div>[BA] The algorithm in Appendix B inclu= des PT routing and I'd like it to continue to cover that.=C2=A0 The alg= orithm appears to resolve a number of bugs filed by both WebRTC and ORTC de= velopers. It will take a bit more review to confirm that it doesn't cau= se any regressions.=C2=A0

=
On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings= <f= luffy@iii.ca> wrote:

> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> = wrote:
>
>
> Regarding PT based routing:
>
> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of= packets are not required for any WebRTC endpoint.

Look, I don't see it this way and I suspect you are going to agr= ee with what I say next.... WebRTC browsers are required to interoperate wi= th "legacy" things that don't do bundle and things that may d= o bundle but try not to use MIDs in cases where they are a gratuitous waste= of bandwidth.

> PT based routing works only in some constrained usages, thus my view i= s that it needs to remain a hint, and an optional hint at most.
> It must be clear that it is not something that is reliable.

You keep asserting this but I'm not convinced you are are correc= t so perhaps you could explain the where they don't work. I seen lots o= f projects ship this and work fine. The algorithm in appendix B make it cle= ar PT are only used if they are unique across all the m-lines. So clearly i= t can not be used if you need more PT than are available in the PT space. A= huge percentage of of real world use cases for SDP easily fit inside the c= urrent PT space. One of the cases I care about if a low peak bandwidth phon= e (not average) for places like parts of Africa that uses a 700 bps codec. = Most single stream of audio and video "video phone call" type cas= es also easily work. Yes, I understand one could construct some single audi= o/video where enough things were the SDP offer needs more PTs than there wa= s space for but if you look at the SDP from just about every major manufact= ure of VoIP audio phones, you see what they are currently doing can easily = be done with unique PT values. Anyway, for these
=C2=A0 case where you don't run out of PT, please please explain why PT= routing is so broken that is should be an optional hint. In practice it se= ems to work fine.

Anyways, I'm just not seeing what you think the problem is here. I don&= #39;t see a problem so I feel pretty strongly that the algorithm in Appendi= x B is fine. Convince me on why is "not reliable" and and "o= nly in some constrained usages"

> I also struggle to see in what non-WebRTC interop use cases this arise= s. The non-WebRTC endpoint needs to be capable of multi media source, and m= ulti stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggre= gating gateway, that is to lazy to add MIDs?
>


People want to avoid the media gateway between WebRTC and and an SIP= endpoint where they can. The media gateway adds latency - huge amounts in = the case where both endpoints require a satellite hop to get to the gateway= - and it add the bandwidth expenses of running gateway.



On all of this, I want to be clear, for people that want to do something wh= ere the PT space is not large enough, obviously they can use MID, I'm j= ust saying that for things that don't use MID, and can fit in the PT sp= ace, it should be an option to use PT and know it will work.






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

--001a11487a0e2ed543054661d450-- From nobody Wed Jan 18 12:53:41 2017 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 A4E04129468 for ; Wed, 18 Jan 2017 12:53:39 -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 q4IScoyy5Geo for ; Wed, 18 Jan 2017 12:53:37 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 488BB127077 for ; Wed, 18 Jan 2017 12:53:37 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id i68so18817267uad.0 for ; Wed, 18 Jan 2017 12:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=WGF6JE41g1Pca6Op68TjWoSNHcTLgcNjjKLDYIfxcoo=; b=S4fod16fra5xdjokJV2xG7NxcSOU705L3QQ2ht03VyJLbhOTHp44EqX2lUGb7NDETc jmKP/DGonQqHRzWqwOZ8iicr1La43f35qRd9AhXPZm2UzrHx+1MGItagaekffVecadxA 4glVle6l7teCcG1gRgFW9NKVvHPYWq6d33tkJLbYTMTQbmucDH4ER5Anmx0rWYF5m4K3 1W3jMmWOIrYkezEBqnMFoPPfUk8y75SeKO7LtxMMAwh7C0DoABB3n13U92dy5LNeyEWr MvrLcBymbKvuA3n+Vy43L9b6QdYCZh2IYp80qIAGJqWSzrx0GXihJNCkOyTvWcUOtor7 1ggQ== 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; bh=WGF6JE41g1Pca6Op68TjWoSNHcTLgcNjjKLDYIfxcoo=; b=slEFrghajS3NxXS3guDJ2sOxrxbxdxCpmWzGXXSwAQb3KSRnBUTGZXU7t50jI4mMgS 9nsy7hU2Z/wFF3luCIHyB/7gITOK5EEAd6W7FeAX7K8/+l6H1LqS+wm+J/9OMFqkC7hS T1lJGdikBZtZ7b3dG8zykM+YX3YQ/qvV1kcTggd7LSlKBceT2xehkX1BFZS81642LnSo F1ddnu7Iby2duabjYt6Sv+hkn/qe6ttUSQhCmheyddW/7WrhErUKOBPjFfEjel3KiLWI dZ8qKBGUwOu5xIZG049pp+GgoD6CGxJt0XLR0mlSN+E8nXooGeC1nncRiPUAl19piYxC yJWw== X-Gm-Message-State: AIkVDXJBgEKQbhWT42HNGSROadDywdZaON3dv5cQFKBjvzX4TlpFk+YUUoVtgCMXNl4CNEVoZtFPIJqKwslpbg== X-Received: by 10.176.82.156 with SMTP id v28mr2884683uav.123.1484772816100; Wed, 18 Jan 2017 12:53:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.37 with HTTP; Wed, 18 Jan 2017 12:53:15 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 18 Jan 2017 12:53:15 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c18e65446a5490546649ca4 Archived-At: Subject: Re: [rtcweb] Working group last call resolutions/Consensus call 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, 18 Jan 2017 20:53:39 -0000 --94eb2c18e65446a5490546649ca4 Content-Type: text/plain; charset=UTF-8 A comment on the RTP matching rules: " If the packet's SSRC is in the incoming SSRC mapping table, route the packet to the associated "m=" line and stop." [BA] In the situation where the packet's Payload Type does not match any PTs for the "m=" line, the packet should be dropped. I have submitted PR https://github.com/rtcweb-wg/jsep/pull/511 to fix this. A comment on the RTCP matching rules: If the packet is of type RTPFB or PSFB, as defined in [RFC4585 ], and the media source SSRC for the packet is found in the outgoing SSRC table, deliver the packet to the "m=" line associated with that SSRC. [BA] This does not handle APP, FIR or LRR packets. Some suggested edits are provided here: https://github.com/rtcweb-wg/jsep/pull/512 On Tue, Jan 17, 2017 at 1:49 PM, Ted Hardie wrote: > Howdy, > > As you can see below, there is a new version of JSEP, which responds to > many of the matters raised during Working Group Last Call. Please review > it carefully, noting particularly the change log in Appendix C. If you > raised an issue, please confirm that you believe it has been addressed or > explain why it has not been. The chairs do not plan on issuing individual > consensus calls on most issues, but will instead issue a new working group > last call after the next update, which will address the issues remaining in > the github repo (https://github.com/rtcweb-wg/jsep/issues). > > The one exception to this is Appendix B. The chairs are hereby issuing a > two week consensus call on the algorithm contained in Appendix B, so that > this working group can positively affirm that it meets the needs of the > WebRTC development community when it is considered by MMUSIC or the wider > IETF community. > > If you do not believe it meets the needs of the WebRTC community, the > chairs ask that you respond by explicitly indicating what changes to the > algorithm are required or what replacement algorithm you propose. > Responses that do not indicate clearly what the algorithm should be will be > weighted accordingly. > > Thanks, and happy reading, > > Ted, Cullen, and Sean > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jan 16, 2017 at 4:08 PM > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-18.txt > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > of the IETF. > > Title : Javascript Session Establishment Protocol > Authors : Justin Uberti > Cullen Jennings > Eric Rescorla > Filename : draft-ietf-rtcweb-jsep-18.txt > Pages : 99 > Date : 2017-01-16 > > Abstract: > This document describes the mechanisms for allowing a Javascript > application to control the signaling plane of a multimedia session > via the interface specified in the W3C RTCPeerConnection API, and > discusses how this relates to existing signaling protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-18 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-18 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --94eb2c18e65446a5490546649ca4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A comment on the RTP matching rules:=C2=A0

<= div>" If the= packet's SSRC is in the incoming SSRC mapping table, route=C2=A0the packet to the ass= ociated "m=3D" line and stop."

[BA] In the = situation where the packet's Payload Type does not match any PTs for th= e "m=3D" line, the packet should be dropped. =C2=A0=

I have submitted PR=C2=A0https://github.com/rtcweb-wg/jsep/pull/511 to = fix this.=C2=A0

A comment on the RTCP matchi= ng rules:=C2=A0

=
      If the packet is of type RTPFB or PSFB, as defined in [RFC4585],
      and the media source SSRC for the packet is found in the outgoing
      SSRC table, deliver the packet to the "m=3D" line associate=
d with
      that SSRC.

[BA] This does not handle APP, FIR or LRR packets.=
 

Some suggested edits are provided here:
https://github.com/rtcweb-wg/jsep/pull/512
<=
/font>


On Tue, Jan 17, 2017 at = 1:49 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Howdy,

As you can = see below, there is a new=20 version of JSEP, which responds to many of the matters raised during=20 Working Group Last Call.=C2=A0 Please review it carefully, noting=20 particularly the change log in Appendix C.=C2=A0 If you raised an issue,=20 please confirm that you believe it has been addressed or explain why it=20 has not been.=C2=A0 The chairs do not plan on issuing individual consensus= =20 calls on most issues, but will instead issue a new working group last call= =20 after the next update, which will address the issues remaining in the githu= b repo (https://github.com/rtcweb-wg/jsep/issues).

The one exce= ption to this is=20 Appendix B.=C2=A0 The chairs are hereby issuing a two week consensus call o= n=20 the algorithm contained in Appendix B, so that this working group can=20 positively affirm that it meets the needs of the WebRTC development=20 community when it is considered by MMUSIC or the wider IETF community.=C2= =A0=20

If you do not believe it meets the needs of the WebRTC community, t= he=20 chairs ask that you respond by explicitly indicating=C2=A0 what=20 changes to the algorithm are required or what replacement algorithm you=20 propose.=C2=A0 Responses that do not indicate clearly what the algorithm sh= ould be will be weighted accordingly.

Thanks, and happy readin= g,

Ted, Cullen, and Sean



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mo= n, Jan 16, 2017 at 4:08 PM
Subject: [rtcweb] I-D Action: draft-ietf-rtcw= eb-jsep-18.txt
To: i-d-announce@ietf.org
Cc: rtcweb@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Javascript Session Establishment Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=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 Cullen Jennings
=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 Eric Rescorla
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-jsep-18.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 99
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-16

Abstract:
=C2=A0 =C2=A0This document describes the mechanisms for allowing a Javascri= pt
=C2=A0 =C2=A0application to control the signaling plane of a multimedia ses= sion
=C2=A0 =C2=A0via the interface specified in the W3C RTCPeerConnection API, = and
=C2=A0 =C2=A0discusses how this relates to existing signaling protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-rtcweb-jsep/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtc= web-jsep-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-rtcweb-jsep-18


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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

--94eb2c18e65446a5490546649ca4-- From nobody Wed Jan 18 14:22:19 2017 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 329D6129502 for ; Wed, 18 Jan 2017 14:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 LLOiEEyXNHBB for ; Wed, 18 Jan 2017 14:22:17 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE86129485 for ; Wed, 18 Jan 2017 14:22:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9428C7C510F for ; Wed, 18 Jan 2017 23:22:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEEKtnVKraSF for ; Wed, 18 Jan 2017 23:22:15 +0100 (CET) Received: from [192.168.0.10] (c80-216-85-0.bredband.comhem.se [80.216.85.0]) by mork.alvestrand.no (Postfix) with ESMTPSA id DE84B7C510E for ; Wed, 18 Jan 2017 23:22:14 +0100 (CET) To: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> Date: Wed, 18 Jan 2017 23:22:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Modifying an approved document: MSID 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, 18 Jan 2017 22:22:18 -0000 When reviewing the implications of the PeerConnection API change to support AddTrack rather than AddStream, I found an issue. This issue concerns draft-ietf-rtcweb-msid, which is currently in REF-WAIT state (I believe). The issue is that it is possible to add a track without specifying a stream. Since the track's ID needs to be carried, we have to send an "a=msid" line, but the track's ID is the *second* field on that line, with the first being the stream's ID. This creates a problem. Suggested fix: Insert two lines in the document: 1) On SDP generation: "If there is no stream associated with the track, use the reserved ID value '-'" 2) On SDP parsing "If the stream ID is the reserved value '-', the track is not associated with a stream, and no stream is signalled or created." If this is OK with the community, I'll issue an updated draft with this change. -- Surveillance is pervasive. Go Dark. From nobody Wed Jan 18 14:30:58 2017 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 E1D441295BC for ; Wed, 18 Jan 2017 14:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 YAgpGK5xBiGH for ; Wed, 18 Jan 2017 14:30:55 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 D3E981295B4 for ; Wed, 18 Jan 2017 14:30:54 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id v23so35334742qtb.0 for ; Wed, 18 Jan 2017 14:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dwoet6WWVv63COGmo/R6k3Z2QZVjO0KGWMFFlEmopq8=; b=vBX1hNMBg5gxAVZuZ/XS/LNC3VxCITl3vwaDk65PV1eQH14uC4lKhNz3c7344fRpT2 ztJwfkyDK28OiXIGVGe86GG2gtaFsfKg3uuHX4kpRsmp8ODrPOUGTHhjP8WBsAQIZxXy Mhoc+Q4S/TV2OUsIBAq9tgLiAZhGe4VzTSdnzn5lLnXwDd4cWxnr9r5rraUqGGM6OWWA pbBTbAkp3DBaVeJaBMf+7OD1EUKsn8xdOS9StMcxermEIHqgE2xR5j66O3ZqzCHaGz/0 NRDDRH2MpBY6/58ZS8oiAbEWtDrB7Eh4SDn5hTi4WlBTcTgM0uGj/TBOJ9yLvB+v2Dmt IlSg== 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=dwoet6WWVv63COGmo/R6k3Z2QZVjO0KGWMFFlEmopq8=; b=Itbax6clElcl+5ij9bOCheIXhi/oz5QL0ww/KBBfeN6nIpfKa+Yl1Ly08wNejRuw43 wrnq6OCd922IwpEncKaI/w+wODmmurXSwqyXE6EqcE+kyo6Vv9RYcAnnGWCWNja/7Z8O kTbcwiNrTDeQtb2qALt2AK3O/vUEXrpTWRaj7S1zuJI6FVTUyb/vYuPFone/w8W3RqDu BzXHIX57Qzyxqk6RqB/Zas8w4t21x7Q02nGwr7UHBP3dbSmI6Tkel9FB01kGXS5vhMov uyfezcNnSNbCp8P9pm7xd5HsZsatdggUN7tXOEZn5X8VSOSItGBbF+OT55lsBSf3P3a1 CPlQ== X-Gm-Message-State: AIkVDXIqw/2PGG6zccaRcpLaFXzwt3iQg9BKYRddnEs0uJjiXhMH63ZAV1mlASb2yVonj/2BE4fNOLnYO1KIGA== X-Received: by 10.55.8.20 with SMTP id 20mr5166279qki.49.1484778653860; Wed, 18 Jan 2017 14:30:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.226 with HTTP; Wed, 18 Jan 2017 14:30:23 -0800 (PST) In-Reply-To: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> From: Ted Hardie Date: Wed, 18 Jan 2017 14:30:23 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114c9d603be4e3054665f80d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Modifying an approved document: MSID 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, 18 Jan 2017 22:30:57 -0000 --001a114c9d603be4e3054665f80d Content-Type: text/plain; charset=UTF-8 Howdy, On Wed, Jan 18, 2017 at 2:22 PM, Harald Alvestrand wrote: > When reviewing the implications of the PeerConnection API change to > support AddTrack rather than AddStream, I found an issue. > > This issue concerns draft-ietf-rtcweb-msid, which is currently in > REF-WAIT state (I believe). > > I think you mean: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ which is in the RFC Editor queue in misref ( https://www.rfc-editor.org/current_queue.php) The issue is that it is possible to add a track without specifying a > stream. Since the track's ID needs to be carried, we have to send an > "a=msid" line, but the track's ID is the *second* field on that line, > with the first being the stream's ID. > > This creates a problem. > > Suggested fix: Insert two lines in the document: > > 1) On SDP generation: > > "If there is no stream associated with the track, use the reserved ID > value '-'" > > 2) On SDP parsing > > "If the stream ID is the reserved value '-', the track is not associated > with a stream, and no stream is signalled or created." > > If this is OK with the community, I'll issue an updated draft with this > change. > > Given the draft string, I believe you have to confirm this way forward with MMUSIC. regards, Ted > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114c9d603be4e3054665f80d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

On Wed, Jan 18, 2017 at 2:22 PM, Harald Alvestrand <ha= rald@alvestrand.no> wrote:
When reviewing the implications of the PeerConnection AP= I change to
support AddTrack rather than AddStream, I found an issue.

This issue concerns draft-ietf-rtcweb-msid, which is currently in
REF-WAIT state (I believe).


which is in the = RFC Editor queue in misref (https://www.rfc-editor.org/current_queue.php)
<= br>
The issue is that it is possible to add a track without specifying a
stream. Since the track's ID needs to be carried, we have to send an "a=3Dmsid" line, but the track's ID is the *second* field on = that line,
with the first being the stream's ID.

This creates a problem.

Suggested fix: Insert two lines in the document:

1) On SDP generation:

"If there is no stream associated with the track, use the reserved ID<= br> value '-'"

2) On SDP parsing

"If the stream ID is the reserved value '-', the track is not = associated
with a stream, and no stream is signalled or created."

If this is OK with the community, I'll issue an updated draft with this=
change.


Given the draft string, I believe you have to = confirm this way forward with MMUSIC.

regards,

Ted

=C2=A0

--
Surveillance is pervasive. Go Dark.

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

--001a114c9d603be4e3054665f80d-- From nobody Thu Jan 19 06:38:43 2017 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 61A8F1294B8 for ; Thu, 19 Jan 2017 06:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, 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 fuhqwMCdXsRu for ; Thu, 19 Jan 2017 06:38:35 -0800 (PST) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (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 924401295F5 for ; Thu, 19 Jan 2017 06:38:35 -0800 (PST) Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D71C324E8C; Thu, 19 Jan 2017 09:38:34 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8AF4324D1F; Thu, 19 Jan 2017 09:38:34 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 19 Jan 2017 09:38:34 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> Date: Thu, 19 Jan 2017 07:38:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3259) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Modifying an approved document: MSID 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, 19 Jan 2017 14:38:40 -0000 > On Jan 18, 2017, at 3:22 PM, Harald Alvestrand = wrote: >=20 > When reviewing the implications of the PeerConnection API change to > support AddTrack rather than AddStream, I found an issue. >=20 > This issue concerns draft-ietf-rtcweb-msid, which is currently in > REF-WAIT state (I believe). >=20 > The issue is that it is possible to add a track without specifying a > stream. Since the track's ID needs to be carried, we have to send an > "a=3Dmsid" line, but the track's ID is the *second* field on that = line, > with the first being the stream's ID. >=20 > This creates a problem. >=20 > Suggested fix: Insert two lines in the document: >=20 > 1) On SDP generation: >=20 > "If there is no stream associated with the track, use the reserved ID > value '-'" >=20 > 2) On SDP parsing >=20 > "If the stream ID is the reserved value '-', the track is not = associated > with a stream, and no stream is signalled or created." >=20 > If this is OK with the community, I'll issue an updated draft with = this > change. Sounds good to me.=20 From nobody Thu Jan 19 06:50:14 2017 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 C922712960A for ; Thu, 19 Jan 2017 06:50:12 -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 Ng8BpxPivT_P for ; Thu, 19 Jan 2017 06:50:10 -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 5375B1295F5 for ; Thu, 19 Jan 2017 06:50:10 -0800 (PST) X-AuditID: c1b4fb30-3136f98000003c8a-96-5880d220022e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 4B.E0.15498.022D0885; Thu, 19 Jan 2017 15:50:08 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 19 Jan 2017 15:50:04 +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=8BzLAMcFXWPP9hdfswsBYQ4nGYCr49obCth4G9NTjo4=; b=Q881sCffZL/RCA9xjQmYvAEDh+oS6Cs4Me5UOxiiC+KagVsNxkY83gpHX4KpwhZrC6h/2DzoirYFzUEgPYzMqcFrce98eLniaIME4urjcK8NS9HFp+JqUJaK+9xVC/C1Mq9hR9vh8t02MlnfJqjdbp0GzD4U1nwC+ccR5YpCFPM= Received: from VI1PR0701MB2733.eurprd07.prod.outlook.com (10.173.80.145) by VI1PR0701MB2735.eurprd07.prod.outlook.com (10.173.80.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Thu, 19 Jan 2017 14:50:03 +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.0860.012; Thu, 19 Jan 2017 14:50:03 +0000 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Cullen Jennings , Harald Alvestrand Thread-Topic: [rtcweb] Modifying an approved document: MSID Thread-Index: AQHScdllbZaXpHoPdEqvSxjZb4aoHg== Date: Thu, 19 Jan 2017 14:50:03 +0000 Message-ID: References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> 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.84] x-ms-office365-filtering-correlation-id: e383ca9b-0c47-400c-e2b8-08d4407a7385 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB2735; x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2735; 7:xIv/pvw1LK7J2Ccfr+3goyQndi5p4C/qAjQjzlKAinevwjSqDhlP8MlmkQhIThzRxTHmlk+pbit4MfmqNN561dPzP4NFsSbhAtSqqNBm+VNsNUrw13oX9+7nbJCM9xCRjBdH5i2CETK/EAB3lIXLEI3eiEnOEBgeARflY39gGhR/voMW5QyR9/5L7TWSzEtQXRQ35O5I7XPugJ3TVUBDTsOvPfLxBuHJ/5+b9GxuqFl2h+U2J+54hPV2q2VU9jFAH0u2QfEuRmEWITQOP+PstL31SjaUbEGHM9bBDSREO1UguZRHeaeptH4+4dh+FoyX/bRXp39lbK6s0qPTAELHzUL7iPTZ205D+TqihZrW6D7dOag3QD3MonwudDTYDGVTFvSceg3jaCs/At+qRx1SFI23+HmdhBcborgxFfgs/FgS4fXzra/05We6mXGZQm9yNX3MJSJbdfNrmLmXnUCnxA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:VI1PR0701MB2735; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2735; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(377454003)(24454002)(77096006)(122556002)(68736007)(74316002)(6506006)(3846002)(5660300001)(5001770100001)(92566002)(86362001)(33656002)(189998001)(9686003)(229853002)(2900100001)(6116002)(99286003)(55016002)(97736004)(102836003)(38730400001)(101416001)(4326007)(3280700002)(6306002)(66066001)(81166006)(53936002)(3660700001)(50986999)(54356999)(81156014)(8936002)(105586002)(6436002)(7736002)(305945005)(7696004)(106356001)(2906002)(76176999)(8676002)(25786008)(106116001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2735; 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: 19 Jan 2017 14:50:03.1952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2735 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGee/HvJqztzXzZAY2qGitZRIiLqUoTALLIGgFkUtvKuqU3TVS wpYl+YGi4Efah4qrlaWhWa0oxTnMlmaYklmiouTHNBUETUvy7i7ov995nuc9h3N4GVKST/sy CVo9q9NqkmQiD6pc/VK+x7/HqA6oHtkZPPd0CQW3F+SKgutWb7odJCN6C3vpCJPpFxHxuXse RZFnPQ7EskkJBla3NyzaI37uz6gotdLz8ky+lTKi3+65yJ0BvB8cyy1ULvJgJLgeweO712ih 6ECQ83PEWVA4n4SStg6XU05A7Y87SCjsCOydTwi+mQifhOfNVSKepTgSuvKn3Xgm8TZYMFc6 9Y04BAbKLZSQUUFPqW2tEbPGSrjzheZlCm+H8RcOZ0SMo+G2rceNj0hwKkx0buVlhDfBol2Y SmIfGBirJIR1MJjedJMCe8Pk6CrNP0U4BsqywgXZH6byjCKBI6G9eR4JfAJezTiclwBcQMGn xVGXkQK22SFaYDlk2yoIV4iAxsFhV8gPikryXKF3NHy9p+BZglkw12UhYXVfGOzNcbEfTHx/ SxeiXRX/7SCwEvpLikUC74YH1Q6ywnmKDfC+fIyqQlQt8uZY7kJyXGCgktUlxHBcilapZfWN aO2TtDatBFjQ5PghK8IMknmK5zKvqiW0xsClJVsRMKRMKm7oMqol4lhNWjqrSzmvu5TEcla0 haFkPuKgR0OnJThOo2cTWTaV1f1zCcbd14jCp24cMyxQEnNQKNF3S3rKqyiqZX2/irUbepfk quNNiuL42tWyh8/UZ8z27PsrYV6NZU1lnkdMPuc6WkNnCUvbSn1GSYYFf0vUhxM1keLMj8PL h9NsPdNXLjpCidcrH8Ks69oUitjArs2FBjKkVDrbINqRroKjYzZVzfW+SBnFxWv2yUkdp/kL QX86SCADAAA= Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Modifying an approved document: MSID 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, 19 Jan 2017 14:50:13 -0000 On 19/01/17 15:39, Cullen Jennings wrote:=0A= >=0A= >> On Jan 18, 2017, at 3:22 PM, Harald Alvestrand wr= ote:=0A= >>=0A= >> When reviewing the implications of the PeerConnection API change to=0A= >> support AddTrack rather than AddStream, I found an issue.=0A= >>=0A= >> This issue concerns draft-ietf-rtcweb-msid, which is currently in=0A= >> REF-WAIT state (I believe).=0A= >>=0A= >> The issue is that it is possible to add a track without specifying a=0A= >> stream. Since the track's ID needs to be carried, we have to send an=0A= >> "a=3Dmsid" line, but the track's ID is the *second* field on that line,= =0A= >> with the first being the stream's ID.=0A= >>=0A= >> This creates a problem.=0A= >>=0A= >> Suggested fix: Insert two lines in the document:=0A= >>=0A= >> 1) On SDP generation:=0A= >>=0A= >> "If there is no stream associated with the track, use the reserved ID=0A= >> value '-'"=0A= >>=0A= >> 2) On SDP parsing=0A= >>=0A= >> "If the stream ID is the reserved value '-', the track is not associated= =0A= >> with a stream, and no stream is signalled or created."=0A= >>=0A= >> If this is OK with the community, I'll issue an updated draft with this= =0A= >> change.=0A= >=0A= > Sounds good to me.=0A= =0A= +1 (though as Ted pointed out it is probably a MMUSIC question rather =0A= than a rtcweb one)=0A= =0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From nobody Thu Jan 19 10:54:26 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C808D129512; Thu, 19 Jan 2017 10:54:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148485206477.10449.1267827264961829565.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 10:54:24 -0800 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] rtcweb - New Meeting Session Request for IETF 98 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jan 2017 18:54:25 -0000 A new meeting session request has just been submitted by Cullen Jennings, a Chair of the rtcweb working group. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Cullen Jennings Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 70 Conflicts to Avoid: First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir acme mmusic payload sipcore perc Second Priority: dprive tcpinc straw tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen dane opsawg Special Requests: --------------------------------------------------------- From nobody Fri Jan 20 02:03:12 2017 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 51773129722 for ; Fri, 20 Jan 2017 02:03:11 -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, 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 AjJVdbkjHIBb for ; Fri, 20 Jan 2017 02:03:10 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 A71CA1296C4 for ; Fri, 20 Jan 2017 02:03:09 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-98-5881e05b3973 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 64.50.25710.B50E1885; Fri, 20 Jan 2017 11:03:07 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.319.2; Fri, 20 Jan 2017 11:02:15 +0100 To: Cullen Jennings References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: Magnus Westerlund Message-ID: Date: Fri, 20 Jan 2017 11:01:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7vW70g8YIg0OnDC0+rP/BaLH2Xzu7 A5PHkiU/mTwun//IGMAUxWWTkpqTWZZapG+XwJVxe/NjloLtshXrV79ga2BcL97FyMkhIWAi 0X61kRXEFhJYxygxrTuwi5ELyF7OKNH+6zkjSEJYIEyidcNxJhBbREBZ4tyOu8wQRdsYJXYf XAKWYBZQlPiyfD4biM0mYCFx80cjmM0rYC/RtfMGM4jNIqAq8ezAQ7C4qECMxNv1y9khagQl Ts58wgJicwpYSSzo+gK0mANopr3Eg61lEOPlJZq3zmaGOFRboqGpg3UCo8AsJN2zEDpmIelY wMi8ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwKA9u+a27g3H1a8dDjAIcjEo8vAVXGiKE WBPLiitzDzFKcDArifDOvdcYIcSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU 1ILUIpgsEwenVANj3mOFPYXuFfdkZP2P+gkptdswJ+vd2fJ+3wOf/S/O6hs+79Dd+n19y+XM Dcfelvb5r1ItWbDn7If1iu0T5n79k5VizZPtyDIpNJvr68mrOjvPf2JJmW4fZnNskdWNjR4P Ir5+ehos7L3v0fTFi6yCpnoIB9/l3HI3Sejv6188OUWVsrZv053tlFiKMxINtZiLihMBq9y4 M0YCAAA= Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 20 Jan 2017 10:03:11 -0000 Den 2017-01-18 kl. 15:52, skrev Cullen Jennings: > >> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund >> wrote: >> >> >> Regarding PT based routing: >> >> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing >> of packets are not required for any WebRTC endpoint. > > Look, I don't see it this way and I suspect you are going to agree > with what I say next.... WebRTC browsers are required to interoperate > with "legacy" things that don't do bundle and things that may do > bundle but try not to use MIDs in cases where they are a gratuitous > waste of bandwidth. > >> PT based routing works only in some constrained usages, thus my >> view is that it needs to remain a hint, and an optional hint at >> most. It must be clear that it is not something that is reliable. > > You keep asserting this but I'm not convinced you are are correct so > perhaps you could explain the where they don't work. I seen lots of > projects ship this and work fine. The algorithm in appendix B make it > clear PT are only used if they are unique across all the m-lines. So > clearly it can not be used if you need more PT than are available in > the PT space. A huge percentage of of real world use cases for SDP > easily fit inside the current PT space. One of the cases I care about > if a low peak bandwidth phone (not average) for places like parts of > Africa that uses a 700 bps codec. Most single stream of audio and > video "video phone call" type cases also easily work. Yes, I > understand one could construct some single audio/video where enough > things were the SDP offer needs more PTs than there was space for but > if you look at the SDP from just about every major manufacture of > VoIP audio phones, you see what they are currently doing can easily > be done with unique PT values. Anyway, for these case where you don't > run out of PT, please please explain why PT routing is so broken that > is should be an optional hint. In practice it seems to work fine. I will not contest that it does work as long as you ensure that PT values are unique across all m= lines in one RTP session. My objection is on an architectural level here. As the PT requirement is not unique one needs to implement a=MIDs. Thus, the PT routing rules becomes a crutch that gets embedded into also the standards implementation not only the legacy and carried forward. What I fail to understand is what this legacy is that does multiple m= lines within a single RTP session is. For how many deployed devices are we ensuring interop with? > > Anyways, I'm just not seeing what you think the problem is here. I > don't see a problem so I feel pretty strongly that the algorithm in > Appendix B is fine. Convince me on why is "not reliable" and and > "only in some constrained usages" I accept that the PT association rules needs to stay in. And this is a diversion from the part that I have real issue with. The style of the rules that places the routing below the RTP stack, rather than above it. And you may note that I did explain how my proposed description format would take PTs into account. My question is would you and others have objections with rules as I wrote them? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jan 20 03:33:55 2017 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 4A0EA129B2A for ; Fri, 20 Jan 2017 03:33:53 -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 O-KFXidYVKVd for ; Fri, 20 Jan 2017 03:33:50 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 2981012983F for ; Fri, 20 Jan 2017 03:33:50 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-a1-5881f59c5b1d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 88.AB.25710.995F1885; Fri, 20 Jan 2017 12:33:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Fri, 20 Jan 2017 12:33:21 +0100 From: Christer Holmberg To: Bernard Aboba , Cullen Jennings Thread-Topic: [rtcweb] Working group last call resolutions/Consensus call: Appendix B Thread-Index: AQHScXHRfPdpg2TYPU+10qpCTZWsc6E+QWwAgAAtEICAAuHCgA== Date: Fri, 20 Jan 2017 11:33:21 +0000 Message-ID: References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D4A7C06E160C5christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7q+6cr40RBitvyVts2Pef2eLD+h+M Fmv/tbM7MHvsnHWX3WPJkp9MHpfPf2QMYI7isklJzcksSy3St0vgymh+vpO14EJlxeS+ogbG 78ldjBwcEgImEn8eKnUxcnEICaxjlOjesIoJwlnCKDFx/SEWkCI2AQuJ7n/aXYycHCICPhI7 5y5mAbGZBRQlviyfzwZiCwuESbRuOM4EUi4iEC6xcLkKRLmTxMMLzUwgNouAqsTTebNYQUp4 BawlFhyH2vSXUWLLvCVgIzkFAiW+7moDsxkFxCS+n1rDBLFKXOLWk/lgtoSAgMSSPeeZIWxR iZeP/7GC2KICehLLn69hhnhLSWLa1jSI1gSJ88t3gZXwCghKnJz5hGUCo+gsJFNnISmbhaQM Im4g8f7cfGYIW1ti2cLXULa+xMYvZxkhbGuJ2zsbWJHVLGDkWMUoWpxaXJybbmSsl1qUmVxc nJ+nl5dasokRGJMHt/zW3cG4+rXjIUYBDkYlHt6CKw0RQqyJZcWVuYcYJTiYlUR4N79pjBDi TUmsrEotyo8vKs1JLT7EKM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qBcYG6/m+Dk4fv NUda+PPfiquTkkxWnrfgg5Kk8sOnM21177/rKJjJ8sHq5omrU2epvSzV9/w5/1VK2D3eir+y S07LLOkX2c9/1IBVa9fKzbOW7OT3yXo4743dV/dl7W9FNCLUjblPvVx8XaKrNttT1T9u+n3b jMrkWReW636UmKp1ednZJwtEOpVYijMSDbWYi4oTAdB1pofFAgAA Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 20 Jan 2017 11:33:53 -0000 --_000_D4A7C06E160C5christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, If things work fine using PT, why do we mandate MID in the first place? Why= would people implement MID in the future if PT works? Unless I remember wrong, Adam is the one who said that the PT space is not = big enough, and that we therefor need something else =96 which made us mand= ate SSRC, specify the tools for MID transport, etc. Also, I am not sure what is meant by a =93hint=94. If there are application= s that don=92t support MID, and need to use PT, then it has to be more than= a =93hint=94. It must be a testable rule. Regards, Christer From: rtcweb > on b= ehalf of Bernard Aboba > Date: Wednesday 18 January 2017 at 19:34 To: Cullen Jennings > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: A= ppendix B Cullen said: "Look, I don't see it this way and I suspect you are going to agree with wh= at I say next.... WebRTC browsers are required to interoperate with "legacy= " things that don't do bundle and things that may do bundle but try not to = use MIDs in cases where they are a gratuitous waste of bandwidth." [BA] +1. There is definitely an expectation on the part of developers tha= t WebRTC will behave like the "legacy" SDP they are used to - even if they = are not interoperating with legacy applications. Since those applications = worked without MIDs, developers will expect them to continue to work when M= ID support is introduced in future. "I seen lots of projects ship this and work fine. The algorithm in appendix= B make it clear PT are only used if they are unique across all the m-lines= . So clearly it can not be used if you need more PT than are available in t= he PT space. A huge percentage of of real world use cases for SDP easily fi= t inside the current PT space." [BA] +1. My experience is that *most* of the developers shipping WebRTC ap= plications that run on multiple browsers are using PT-based routing, so the= y'd be very surprised to learn that it isn't supported (and they would prob= ably push back vigorously at such a notion). "Anyways, I'm just not seeing what you think the problem is here. I don't s= ee a problem so I feel pretty strongly that the algorithm in Appendix B is = fine." [BA] The algorithm in Appendix B includes PT routing and I'd like it to con= tinue to cover that. The algorithm appears to resolve a number of bugs fil= ed by both WebRTC and ORTC developers. It will take a bit more review to co= nfirm that it doesn't cause any regressions. On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings > wrote: > On Jan 18, 2017, at 3:01 AM, Magnus Westerlund > wrote: > > > Regarding PT based routing: > > RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of pa= ckets are not required for any WebRTC endpoint. Look, I don't see it this way and I suspect you are going to agree with wha= t I say next.... WebRTC browsers are required to interoperate with "legacy"= things that don't do bundle and things that may do bundle but try not to u= se MIDs in cases where they are a gratuitous waste of bandwidth. > PT based routing works only in some constrained usages, thus my view is t= hat it needs to remain a hint, and an optional hint at most. > It must be clear that it is not something that is reliable. You keep asserting this but I'm not convinced you are are correct so perhap= s you could explain the where they don't work. I seen lots of projects ship= this and work fine. The algorithm in appendix B make it clear PT are only = used if they are unique across all the m-lines. So clearly it can not be us= ed if you need more PT than are available in the PT space. A huge percentag= e of of real world use cases for SDP easily fit inside the current PT space= . One of the cases I care about if a low peak bandwidth phone (not average)= for places like parts of Africa that uses a 700 bps codec. Most single str= eam of audio and video "video phone call" type cases also easily work. Yes,= I understand one could construct some single audio/video where enough thin= gs were the SDP offer needs more PTs than there was space for but if you lo= ok at the SDP from just about every major manufacture of VoIP audio phones,= you see what they are currently doing can easily be done with unique PT va= lues. Anyway, for these case where you don't run out of PT, please please explain why PT routing = is so broken that is should be an optional hint. In practice it seems to wo= rk fine. Anyways, I'm just not seeing what you think the problem is here. I don't se= e a problem so I feel pretty strongly that the algorithm in Appendix B is f= ine. Convince me on why is "not reliable" and and "only in some constrained= usages" > I also struggle to see in what non-WebRTC interop use cases this arises. = The non-WebRTC endpoint needs to be capable of multi media source, and mult= i stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggregat= ing gateway, that is to lazy to add MIDs? > People want to avoid the media gateway between WebRTC and and an SIP endpoi= nt where they can. The media gateway adds latency - huge amounts in the cas= e where both endpoints require a satellite hop to get to the gateway - and = it add the bandwidth expenses of running gateway. On all of this, I want to be clear, for people that want to do something wh= ere the PT space is not large enough, obviously they can use MID, I'm just = saying that for things that don't use MID, and can fit in the PT space, it = should be an option to use PT and know it will work. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_D4A7C06E160C5christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

If things work fine using PT, why do we mandate MID in the first place= ? Why would people implement MID in the future if PT works?

Unless I remember wrong, Adam is the one who said that the PT space is= not big enough, and that we therefor need something else =96 which made us= mandate SSRC, specify the tools for MID transport, etc.

Also, I am not sure what is meant by a =93hint=94. If there are applic= ations that don=92t support MID, and need to use PT, then it has to be more= than a =93hint=94. It must be a testable rule.

Regards,

Christer





From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Berna= rd Aboba <bernard.aboba@gmail= .com>
Date: Wednesday 18 January 2017 at = 19:34
To: Cullen Jennings <fluffy@iii.ca>
Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: Re: [rtcweb] Working group= last call resolutions/Consensus call: Appendix B

Cullen said: 

"Look, I don't see it this way a= nd I suspect you are going to agree with what I say next.... WebRTC browser= s are required to interoperate with "legacy" things that don't do= bundle and things that may do bundle but try not to use MIDs in cases where they are a gratuitous waste of bandwidth."

[BA] +1.   There is definitely an expectation on the part of = developers that WebRTC will behave like the "legacy" SDP they are= used to - even if they are not interoperating with legacy applications.&nb= sp; Since those applications worked without MIDs, developers will expect them to continue to work when MID support is introduced in fut= ure. 

"I seen lots of projects ship th= is and work fine. The algorithm in appendix B make it clear PT are only use= d if they are unique across all the m-lines. So clearly it can not be used = if you need more PT than are available in the PT space. A huge percentage of of real world use cases for SDP easi= ly fit inside the current PT space."

[BA] +1.  My experience is t= hat *most* of the developers shipping WebRTC applications that run on multi= ple browsers are using PT-based routing, so they'd be very surprised to lea= rn that it isn't supported (and they would probably push back vigorously at such a notion). 

"Anyways, I'm just not seeing what you think the problem is here. I= don't see a problem so I feel pretty strongly that the algorithm in Append= ix B is fine."

[BA] The algorithm in Appendix B incl= udes PT routing and I'd like it to continue to cover that.  The algori= thm appears to resolve a number of bugs filed by both WebRTC and ORTC devel= opers. It will take a bit more review to confirm that it doesn't cause any regressions. 

On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings= <fluffy@iii.ca>= ; wrote:

> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> = wrote:
>
>
> Regarding PT based routing:
>
> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of= packets are not required for any WebRTC endpoint.

Look, I don't see it this way and I suspect you are going to agree w= ith what I say next.... WebRTC browsers are required to interoperate with &= quot;legacy" things that don't do bundle and things that may do bundle= but try not to use MIDs in cases where they are a gratuitous waste of bandwidth.

> PT based routing works only in some constrained usages, thus my view i= s that it needs to remain a hint, and an optional hint at most.
> It must be clear that it is not something that is reliable.

You keep asserting this but I'm not convinced you are are correct so= perhaps you could explain the where they don't work. I seen lots of projec= ts ship this and work fine. The algorithm in appendix B make it clear PT ar= e only used if they are unique across all the m-lines. So clearly it can not be used if you need more PT than ar= e available in the PT space. A huge percentage of of real world use cases f= or SDP easily fit inside the current PT space. One of the cases I care abou= t if a low peak bandwidth phone (not average) for places like parts of Africa that uses a 700 bps codec. M= ost single stream of audio and video "video phone call" type case= s also easily work. Yes, I understand one could construct some single audio= /video where enough things were the SDP offer needs more PTs than there was space for but if you look at the SDP from ju= st about every major manufacture of VoIP audio phones, you see what they ar= e currently doing can easily be done with unique PT values. Anyway, for the= se
  case where you don't run out of PT, please please explain why PT rou= ting is so broken that is should be an optional hint. In practice it seems = to work fine.

Anyways, I'm just not seeing what you think the problem is here. I don't se= e a problem so I feel pretty strongly that the algorithm in Appendix B is f= ine. Convince me on why is "not reliable" and and "only in s= ome constrained usages"

> I also struggle to see in what non-WebRTC interop use cases this arise= s. The non-WebRTC endpoint needs to be capable of multi media source, and m= ulti stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggre= gating gateway, that is to lazy to add MIDs?
>


People want to avoid the media gateway between WebRTC and and an SIP= endpoint where they can. The media gateway adds latency - huge amounts in = the case where both endpoints require a satellite hop to get to the gateway= - and it add the bandwidth expenses of running gateway.



On all of this, I want to be clear, for people that want to do something wh= ere the PT space is not large enough, obviously they can use MID, I'm just = saying that for things that don't use MID, and can fit in the PT space, it = should be an option to use PT and know it will work.






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

--_000_D4A7C06E160C5christerholmbergericssoncom_-- From nobody Fri Jan 20 14:20:24 2017 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 C69841294D1 for ; Fri, 20 Jan 2017 14:20: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=ham 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 pc6l2TlyLOYq for ; Fri, 20 Jan 2017 14:20:20 -0800 (PST) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 5D8FD1294C5 for ; Fri, 20 Jan 2017 14:20:20 -0800 (PST) Received: by mail-yb0-x230.google.com with SMTP id l23so71849349ybj.2 for ; Fri, 20 Jan 2017 14:20:20 -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=dfBSwfVePO2/lK1ykEqOPvP55oV+dcQfjkRoCrLPpnY=; b=LociWiTuesTzGH5BDOZf/qQLGVo03kYJHDwdmUmrPaa7Rjl8GHcDdL7T3qqdvBvoaa qDkTjk0SXYUcHG8kNJe6s7g9brjcZGJD4cesr0wpY64SZ1jO6hRdA9pGN5sq9RLqtFQx 3Ed9uUhCcdEjVcmB0xwv/1vsjkvL6mZFJtIjakTp0lubbRIRqPXUGFvuOrbUQOW64sHt DudXJ5sIIuXfExWTBFmpwQoe7ADxW/NZ/c6z5jL/AhfQ45Rrt6ft9T2IKzR2aVqO1WqZ xAgFylhV3IH3FtrUAO8jJzRl5cpoqqQGBKIb/NJHoZ72IrkBrHvr36QABJaH8wRUX41d L0HQ== 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=dfBSwfVePO2/lK1ykEqOPvP55oV+dcQfjkRoCrLPpnY=; b=DxN8Xr3hj+/RsZqEVnKs6VC8ZoTh3VugyN7hikwrLQ3HKYVtLpqG86GHxR1FHJ1tix d7H7eqsv+GhxH0X8ceOTkj77/CbFqGkrFnR1UHp2fi5J4xh4V4l/BHhUb6DbOyPIAGGl 7llPh3ORIk6jXc6wmMzu1PDQ8m1buUkCLshQmI2wdkd/zegIAJQKgCku9Gb26/KbzSZP fMRFY6zCRwRIZM6I7EBxR+0ygMf+RtwW7tA/yh6S87LwRP8Pdaajfz+I1C+xyLuQf0YL AzM2cw668NcJ9sva0UQY0gxtIC+PsP/PArqXHnV32FObCpcaQkzP3HS2JN3nQN67RAG9 wjQQ== X-Gm-Message-State: AIkVDXJNgwPw2yXVLtB5pkeBn5mXpswSiY/NjgtRtmUUMJnGLR8Ws5fbpZi1y9tmoWL+pefU8JKuwZ+LlFRf+w== X-Received: by 10.37.246.10 with SMTP id t10mr13701853ybd.107.1484950819615; Fri, 20 Jan 2017 14:20:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 20 Jan 2017 14:19:39 -0800 (PST) In-Reply-To: References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: Eric Rescorla Date: Fri, 20 Jan 2017 14:19:39 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=f403045dc8581d02c505468e0e5f Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 20 Jan 2017 22:20:22 -0000 --f403045dc8581d02c505468e0e5f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's not big enough for every use case but it's in use for certain limited use cases now. Hence the need to support PT now and MID in the future -Ekr On Fri, Jan 20, 2017 at 3:33 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > If things work fine using PT, why do we mandate MID in the first place? > Why would people implement MID in the future if PT works? > > Unless I remember wrong, Adam is the one who said that the PT space is no= t > big enough, and that we therefor need something else =E2=80=93 which made= us > mandate SSRC, specify the tools for MID transport, etc. > > Also, I am not sure what is meant by a =E2=80=9Chint=E2=80=9D. If there a= re applications > that don=E2=80=99t support MID, and need to use PT, then it has to be mor= e than a > =E2=80=9Chint=E2=80=9D. It must be a testable rule. > > Regards, > > Christer > > > > > > From: rtcweb on behalf of Bernard Aboba < > bernard.aboba@gmail.com> > Date: Wednesday 18 January 2017 at 19:34 > To: Cullen Jennings > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: > Appendix B > > Cullen said: > > "Look, I don't see it this way and I suspect you are going to agree with > what I say next.... WebRTC browsers are required to interoperate with > "legacy" things that don't do bundle and things that may do bundle but tr= y > not to use MIDs in cases where they are a gratuitous waste of bandwidth." > > [BA] +1. There is definitely an expectation on the part of developers > that WebRTC will behave like the "legacy" SDP they are used to - even if > they are not interoperating with legacy applications. Since those > applications worked without MIDs, developers will expect them to continue > to work when MID support is introduced in future. > > "I seen lots of projects ship this and work fine. The algorithm in > appendix B make it clear PT are only used if they are unique across all t= he > m-lines. So clearly it can not be used if you need more PT than are > available in the PT space. A huge percentage of of real world use cases f= or > SDP easily fit inside the current PT space." > > [BA] +1. My experience is that *most* of the developers shipping WebRTC > applications that run on multiple browsers are using PT-based routing, so > they'd be very surprised to learn that it isn't supported (and they would > probably push back vigorously at such a notion). > > "Anyways, I'm just not seeing what you think the problem is here. I don't > see a problem so I feel pretty strongly that the algorithm in Appendix B = is > fine." > > [BA] The algorithm in Appendix B includes PT routing and I'd like it to > continue to cover that. The algorithm appears to resolve a number of bug= s > filed by both WebRTC and ORTC developers. It will take a bit more review = to > confirm that it doesn't cause any regressions. > > On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings wrote: > >> >> > On Jan 18, 2017, at 3:01 AM, Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> > >> > >> > Regarding PT based routing: >> > >> > RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of >> packets are not required for any WebRTC endpoint. >> >> Look, I don't see it this way and I suspect you are going to agree with >> what I say next.... WebRTC browsers are required to interoperate with >> "legacy" things that don't do bundle and things that may do bundle but t= ry >> not to use MIDs in cases where they are a gratuitous waste of bandwidth. >> >> > PT based routing works only in some constrained usages, thus my view i= s >> that it needs to remain a hint, and an optional hint at most. >> > It must be clear that it is not something that is reliable. >> >> You keep asserting this but I'm not convinced you are are correct so >> perhaps you could explain the where they don't work. I seen lots of >> projects ship this and work fine. The algorithm in appendix B make it cl= ear >> PT are only used if they are unique across all the m-lines. So clearly i= t >> can not be used if you need more PT than are available in the PT space. = A >> huge percentage of of real world use cases for SDP easily fit inside the >> current PT space. One of the cases I care about if a low peak bandwidth >> phone (not average) for places like parts of Africa that uses a 700 bps >> codec. Most single stream of audio and video "video phone call" type cas= es >> also easily work. Yes, I understand one could construct some single >> audio/video where enough things were the SDP offer needs more PTs than >> there was space for but if you look at the SDP from just about every maj= or >> manufacture of VoIP audio phones, you see what they are currently doing = can >> easily be done with unique PT values. Anyway, for these >> case where you don't run out of PT, please please explain why PT >> routing is so broken that is should be an optional hint. In practice it >> seems to work fine. >> >> Anyways, I'm just not seeing what you think the problem is here. I don't >> see a problem so I feel pretty strongly that the algorithm in Appendix B= is >> fine. Convince me on why is "not reliable" and and "only in some >> constrained usages" >> >> > I also struggle to see in what non-WebRTC interop use cases this >> arises. The non-WebRTC endpoint needs to be capable of multi media sourc= e, >> and multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it= a >> aggregating gateway, that is to lazy to add MIDs? >> > >> >> >> People want to avoid the media gateway between WebRTC and and an SIP >> endpoint where they can. The media gateway adds latency - huge amounts i= n >> the case where both endpoints require a satellite hop to get to the gate= way >> - and it add the bandwidth expenses of running gateway. >> >> >> >> On all of this, I want to be clear, for people that want to do something >> where the PT space is not large enough, obviously they can use MID, I'm >> just saying that for things that don't use MID, and can fit in the PT >> space, it should be an option to use PT and know it will work. >> >> >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f403045dc8581d02c505468e0e5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's not big enough for every use case but it's in= use for certain limited use cases now. Hence the need to support PT now an= d MID in the future

-Ekr


On Fri, Jan 20, 2017 at 3:33 AM, C= hrister Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

If things work fine using PT, why do we mandate MID in the first place= ? Why would people implement MID in the future if PT works?

Unless I remember wrong, Adam is the one who said that the PT space is= not big enough, and that we therefor need something else =E2=80=93 which m= ade us mandate SSRC, specify the tools for MID transport, etc.

Also, I am not sure what is meant by a =E2=80=9Chint=E2=80=9D. If ther= e are applications that don=E2=80=99t support MID, and need to use PT, then= it has to be more than a =E2=80=9Chint=E2=80=9D. It must be a testable rul= e.

Regards,

Christer





From: rtcweb <rtcweb-bounces@ietf.org> = on behalf of Bernard Aboba <bernard.aboba@gmail.com>
Date: Wednesday 18 January 2017 at = 19:34
To: Cullen Jennings <fluffy@iii.ca>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working group= last call resolutions/Consensus call: Appendix B

Cullen said:=C2=A0

"Look, I don't see it this w= ay and I suspect you are going to agree with what I say next.... WebRTC bro= wsers are required to interoperate with "legacy" things that don&= #39;t do bundle and things that may do bundle but try not to use MIDs in cases where they are a gratuitous waste of bandwidth."

[BA] +1. =C2=A0 There is definitely an expectation on the part of deve= lopers that WebRTC will behave like the "legacy" SDP they are use= d to - even if they are not interoperating with legacy applications.=C2=A0 = Since those applications worked without MIDs, developers will expect them to continue to work when MID support is introduced in fut= ure.=C2=A0

"I seen lots of projects ship th= is and work fine. The algorithm in appendix B make it clear PT are only use= d if they are unique across all the m-lines. So clearly it can not be used = if you need more PT than are available in the PT space. A huge percentage of of real world use cases for SDP easi= ly fit inside the current PT space."

[BA] +1.=C2=A0 My experience is that = *most* of the developers shipping WebRTC applications that run on multiple = browsers are using PT-based routing, so they'd be very surprised to lea= rn that it isn't supported (and they would probably push back vigorously at such a notion).=C2=A0

"Anyways, I'm just not seeing what you think the problem is her= e. I don't see a problem so I feel pretty strongly that the algorithm i= n Appendix B is fine."<= /div>

[BA] The algorithm in Appendix B incl= udes PT routing and I'd like it to continue to cover that.=C2=A0 The al= gorithm appears to resolve a number of bugs filed by both WebRTC and ORTC d= evelopers. It will take a bit more review to confirm that it doesn't cause any regressions.=C2=A0

On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings= <fluffy@iii.ca>= ; wrote:

> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund <magnus.westerlund@ericsson= .com> wrote:
>
>
> Regarding PT based routing:
>
> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of= packets are not required for any WebRTC endpoint.

Look, I don't see it this way and I suspect you are going to agr= ee with what I say next.... WebRTC browsers are required to interoperate wi= th "legacy" things that don't do bundle and things that may d= o bundle but try not to use MIDs in cases where they are a gratuitous waste of bandwidth.

> PT based routing works only in some constrained usages, thus my view i= s that it needs to remain a hint, and an optional hint at most.
> It must be clear that it is not something that is reliable.

You keep asserting this but I'm not convinced you are are correc= t so perhaps you could explain the where they don't work. I seen lots o= f projects ship this and work fine. The algorithm in appendix B make it cle= ar PT are only used if they are unique across all the m-lines. So clearly it can not be used if you need more PT than ar= e available in the PT space. A huge percentage of of real world use cases f= or SDP easily fit inside the current PT space. One of the cases I care abou= t if a low peak bandwidth phone (not average) for places like parts of Africa that uses a 700 bps codec. M= ost single stream of audio and video "video phone call" type case= s also easily work. Yes, I understand one could construct some single audio= /video where enough things were the SDP offer needs more PTs than there was space for but if you look at the SDP from ju= st about every major manufacture of VoIP audio phones, you see what they ar= e currently doing can easily be done with unique PT values. Anyway, for the= se
=C2=A0 case where you don't run out of PT, please please explain why PT= routing is so broken that is should be an optional hint. In practice it se= ems to work fine.

Anyways, I'm just not seeing what you think the problem is here. I don&= #39;t see a problem so I feel pretty strongly that the algorithm in Appendi= x B is fine. Convince me on why is "not reliable" and and "o= nly in some constrained usages"

> I also struggle to see in what non-WebRTC interop use cases this arise= s. The non-WebRTC endpoint needs to be capable of multi media source, and m= ulti stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggre= gating gateway, that is to lazy to add MIDs?
>


People want to avoid the media gateway between WebRTC and and an SIP= endpoint where they can. The media gateway adds latency - huge amounts in = the case where both endpoints require a satellite hop to get to the gateway= - and it add the bandwidth expenses of running gateway.



On all of this, I want to be clear, for people that want to do something wh= ere the PT space is not large enough, obviously they can use MID, I'm j= ust saying that for things that don't use MID, and can fit in the PT sp= ace, it should be an option to use PT and know it will work.






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


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

--f403045dc8581d02c505468e0e5f-- From nobody Fri Jan 20 14:26:27 2017 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 8F1511294DF for ; Fri, 20 Jan 2017 14:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 zY-SfM0Wj5wb for ; Fri, 20 Jan 2017 14:26:23 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 81B3B1294DD for ; Fri, 20 Jan 2017 14:26:23 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id u68so65793945ywg.0 for ; Fri, 20 Jan 2017 14:26:23 -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=aO8e/V+l9VluAU3ZRC/HvfTYfD5nptVKBpmY4GxZCzw=; b=F9YYB4TjYhEiwTtWx+5TT1857aRDimqhjm+rpZOKhXNQ07xhVXC9qFtXhUVsOyGVFH 59nWGV2y213zL3xO8TbTD9vIQM81sUlj5bN1sXlDOj4GXptsumdbVRmZrOB1zixVWxDD qiM/RS+T+hdTz+GI8HJ9aZUFsXhT89x7XdnVMOf5t1ulFIDfM/oVw6LykBioQACt0ssL JJS1z12lCplxVCnAJAYL29YL9wBeW6K+NEB1neNov/eZLyTxA0xBBSz96/yI4Cy2JQRP eecEezIAEatuMLYw6FFW96uNjSA0X3hC6MOQpsxuMF7rER4JVX5r3d2WC2/r2GIYTzDy dZ9g== 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=aO8e/V+l9VluAU3ZRC/HvfTYfD5nptVKBpmY4GxZCzw=; b=JZme6r6IQ8lcVXWlgY0hu5LMDtpyPCWbE8v5DVUQ3OPwO952d7LaALEv7Qv78aYIFF l3eDexy8Qs5V4usfYUzDyDFQSp5nv+y4ilqnC0HJFsPQF1u6UyKfhGPR/Jie7QfSyCzR WXSI9hAgGRsOtWHnM2sqfgqV79hWOWcgk53I5F5biJZdgVy34ma3Z70rGz7M68vX8cvc BYBD02OFh/ebz0unc3hitN154MXxvW4UV5j/FdW4db4RZ1zCAUfRdrSGD881BLsZ5OLB hGIJiS3I27gtXVHypOLciMb6pEB+fmI3oOtVjBjqxji9zJVhIzQcNDEhfUsnxzLtmHax LWlg== X-Gm-Message-State: AIkVDXJcbpb5THTL++et82A9+Saii0OkBHJ+83E3Yq7dhej+b394Hu/T4p9TSdfI/qtJ6CJ0315wGS5C00TuKA== X-Received: by 10.13.250.3 with SMTP id k3mr15184948ywf.276.1484951182676; Fri, 20 Jan 2017 14:26:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 20 Jan 2017 14:25:42 -0800 (PST) In-Reply-To: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: Eric Rescorla Date: Fri, 20 Jan 2017 14:25:42 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c07f76cc10a5f05468e2315 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 20 Jan 2017 22:26:25 -0000 --94eb2c07f76cc10a5f05468e2315 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 18, 2017 at 2:01 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2017-01-17 kl. 22:49, skrev Ted Hardie: > >> The one exception to this is Appendix B. The chairs are hereby issuing >> a two week consensus call on the algorithm contained in Appendix B, so >> that this working group can positively affirm that it meets the needs of >> the WebRTC development community when it is considered by MMUSIC or the >> wider IETF community. >> >> > Hi, > > Here is my feedback on Appendix B. I am sorry that sickness, > holiday vacations has prevented me to be more proactive on this subject. > > There was feedback on the proposal Colin Perkins and I put together, whic= h > we failed to respond to yet. I have reviewed the emails before responding > now. I will attempt to respond to what I consider the high level issues a= nd > my views that was brought up in those emails. > > Regarding PT based routing: > > RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of > packets are not required for any WebRTC endpoint. PT based routing works > only in some constrained usages, thus my view is that it needs to remain = a > hint, and an optional hint at most. It must be clear that it is not > something that is reliable. I also struggle to see in what non-WebRTC > interop use cases this arises. The non-WebRTC endpoint needs to be capabl= e > of multi media source, and multi stream (SSRC) RTP sessions, but not > implement BUNDLE. Or is it a aggregating gateway, that is to lazy to add > MIDs? > > > On the packet level routing description: The issue I have had previously > and to some degree also with the current appendix B is that it is describ= ed > in a fashion that appears to match a particular RTP stack implementation. > And I have to note that it is not like the two RTP stack implementations = I > have been involved designing. Thus, the description at its level of > specificity does not fit what I would do. It also does not let the RTP > concepts work for you, instead this is injected in the bottom of the stac= k. > > The text I talk about is the following: > > For each RTP packet received, the following steps MUST be followed to > route the packet to the correct "m=3D" section within a BUNDLE group. > Note that the phrase 'deliver a packet to the "m=3D" line' means to > further process the packet as would normally happen with RTP/RTCP, if > it were received on a transport associated with that "m=3D" line > outside of a BUNDLE group (i.e., if the "m=3D" line were not BUNDLEd), > including dropping an RTP packet if the packet's PT does not match > any PT in the "m=3D" line. > > If the packet has a MID and that MID is not in the table mapping > MID to "m=3D" line, drop the packet and stop. > > If the packet has a MID and that MID is in the table mapping MID > to "m=3D" line, update the incoming SSRC mapping table to include a= n > entry that maps the packet's SSRC to the "m=3D" line for that MID. > > If the packet's SSRC is in the incoming SSRC mapping table, route > the packet to the associated "m=3D" line and stop. > > If the packet's payload type is in the payload type table, update > the the incoming SSRC mapping table to include an entry that maps > the packet's SSRC to the "m=3D" line for that payload type. In > addition, route the packet to the associated "m=3D" line and stop. > > Otherwise, drop the packet. > > If I would write this packet level routing it would work with the concept= s > of the RTP protocol: > > This the bullet list would look like this instead: > > 1. Reception of an RTP packet for a SSRC with an existing > association to an m=3D line, with a MID RTP header extension, the > MID value is checked. If it matches the existing association, > then the processing continues in that m=3D line context. If > the value is a new value, then the association to the m=3D line > is updated, and then the packet is processed in the new m=3D line > context. > I don't understand how this point is different from points #1 and #2 above. Is your problem with the talk of a table versus an association? Routing to an m=3D line versus "processed in the m=3D line context"? Can you help m= e understand how these are semantically different? Specifically what implementation technique would be allowed by your text that is not allowed by the existing text (and that couldn't be solved by requiring implementations to have the same external behavior). -Ekr > > 2. Reception of an RTP packet with an SSRC that has > an existing mapping to an m=3D line is processed in that > m=3D line context. > > 3. Reception of an RTP packet with a previously unknown SSRC that > contains an MID RTP header extension, will result in that SSRC > be associated with the corresponding m=3D line. The packet is > then processed in this m=3D line context. > > 4. Reception of an RTP packet with an SSRC that has no association > to any m=3D line is processed by the RTP protocol implementation > for statistics, etc. but is then dropped. > > I would not route on PT, but in this style of description the PT routing > would look like the below bullet, but I would prefer to skip it. It shoul= d > be inserted second to last of the bullets, i.e. between 3 and 4. > > 3.5 Reception of a previously unknown SSRC that > contains an PT value that exists in the payload type mapping > table, will result in that SSRC be associated with the > corresponding m=3D line. > > However, the above is not sufficient, it also needs an amendment to bulle= t > 2, where if the PT value does not match the m=3D line context the associa= tion > needs to be updated. > > For the RTCP part the appendix B description is even more foreign to my > implementations. As the implementations will process the information of t= he > incoming RTCP compound packet and then provide API that notifies the high= er > layer of the changes of interest. Like for example the reception of a > Feedback Request, or the change to a SDES item for a particular SSRC. Thu= s > the actions related to RTCP becomes even more abstract. Where the > description says "deliver a copy of the RTCP packet to the "m=3D" line > associated with that SSRC" I would say "Process the information in the > context of the m=3D line that is associated with the SSRC". > > So my conclusion is that the current issue is how we find a specific > enough description that at the same time does not restrict how you > implement your RTP stack. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c07f76cc10a5f05468e2315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 18, 2017 at 2:01 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Den 2017-01-17 kl. 22:49, skrev Ted Hardie:
The one exception to this is Appendix B.=C2=A0 The chairs are hereby issuin= g
a two week consensus call on the algorithm contained in Appendix B, so
that this working group can positively affirm that it meets the needs of the WebRTC development community when it is considered by MMUSIC or the
wider IETF community.


Hi,

Here is my feedback on Appendix B. I am sorry that sickness,
holiday vacations has prevented me to be more proactive on this subject.
There was feedback on the proposal Colin Perkins and I put together, which = we failed to respond to yet. I have reviewed the emails before responding n= ow. I will attempt to respond to what I consider the high level issues and = my views that was brought up in those emails.

Regarding PT based routing:

RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of pack= ets are not required for any WebRTC endpoint. PT based routing works only i= n some constrained usages, thus my view is that it needs to remain a hint, = and an optional hint at most. It must be clear that it is not something tha= t is reliable. I also struggle to see in what non-WebRTC interop use cases = this arises. The non-WebRTC endpoint needs to be capable of multi media sou= rce, and multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is = it a aggregating gateway, that is to lazy to add MIDs?


On the packet level routing description: The issue I have had previously an= d to some degree also with the current appendix B is that it is described i= n a fashion that appears to match a particular RTP stack implementation. An= d I have to note that it is not like the two RTP stack implementations I ha= ve been involved designing. Thus, the description at its level of specifici= ty does not fit what I would do. It also does not let the RTP concepts work= for you, instead this is injected in the bottom of the stack.

The text I talk about is the following:

=C2=A0 For each RTP packet received, the following steps MUST be followed t= o
=C2=A0 =C2=A0route the packet to the correct "m=3D" section withi= n a BUNDLE group.
=C2=A0 =C2=A0Note that the phrase 'deliver a packet to the "m=3D&q= uot; line' means to
=C2=A0 =C2=A0further process the packet as would normally happen with RTP/R= TCP, if
=C2=A0 =C2=A0it were received on a transport associated with that "m= =3D" line
=C2=A0 =C2=A0outside of a BUNDLE group (i.e., if the "m=3D" line = were not BUNDLEd),
=C2=A0 =C2=A0including dropping an RTP packet if the packet's PT does n= ot match
=C2=A0 =C2=A0any PT in the "m=3D" line.

=C2=A0 =C2=A0 =C2=A0 If the packet has a MID and that MID is not in the tab= le mapping
=C2=A0 =C2=A0 =C2=A0 MID to "m=3D" line, drop the packet and stop= .

=C2=A0 =C2=A0 =C2=A0 If the packet has a MID and that MID is in the table m= apping MID
=C2=A0 =C2=A0 =C2=A0 to "m=3D" line, update the incoming SSRC map= ping table to include an
=C2=A0 =C2=A0 =C2=A0 entry that maps the packet's SSRC to the "m= =3D" line for that MID.

=C2=A0 =C2=A0 =C2=A0 If the packet's SSRC is in the incoming SSRC mappi= ng table, route
=C2=A0 =C2=A0 =C2=A0 the packet to the associated "m=3D" line and= stop.

=C2=A0 =C2=A0 =C2=A0 If the packet's payload type is in the payload typ= e table, update
=C2=A0 =C2=A0 =C2=A0 the the incoming SSRC mapping table to include an entr= y that maps
=C2=A0 =C2=A0 =C2=A0 the packet's SSRC to the "m=3D" line for= that payload type.=C2=A0 In
=C2=A0 =C2=A0 =C2=A0 addition, route the packet to the associated "m= =3D" line and stop.

=C2=A0 =C2=A0 =C2=A0 Otherwise, drop the packet.

If I would write this packet level routing it would work with the concepts = of the RTP protocol:

This the bullet list would look like this instead:

=C2=A0 =C2=A0 =C2=A01. Reception of an RTP packet for a SSRC with an existi= ng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 association to an m=3D line, with a MID RTP hea= der extension, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MID value is checked. If it matches the existin= g association,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 then the processing continues in that m=3D line= context. If
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the value is a new value, then the association = to the m=3D line
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is updated, and then the packet is processed in= the new m=3D line
=C2=A0 =C2=A0 =C2=A0 =C2=A0 context.

I = don't understand how this point is different from points #1 and #2 abov= e.

Is your problem with the talk of a table versus= an association? Routing
to an m=3D line versus "processed i= n the m=3D line context"? Can you help me understand
how the= se are semantically different? Specifically what implementation technique w= ould
be allowed by your text that is not allowed by the existing = text (and that couldn't be
solved by requiring implementation= s to have the same external behavior).

-Ekr
<= div>
=C2=A0


=C2=A0

=C2=A0 =C2=A0 =C2=A02. Reception of an RTP packet with an SSRC that has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 an existing mapping to an m=3D line is processe= d in that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 m=3D line context.

=C2=A0 =C2=A0 =C2=A03. Reception of an RTP packet with a previously unknown= SSRC that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 contains an MID RTP header extension, will resu= lt in that SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be associated with the corresponding m=3D line.= The packet is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 then processed in this m=3D line context.
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A04. Reception of an RTP packet with an SSRC that has no = association
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to any m=3D line is processed by the RTP protoc= ol implementation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for statistics, etc. but is then dropped.

I would not route on PT, but in this style of description the PT routing wo= uld look like the below bullet, but I would prefer to skip it. It should be= inserted second to last of the bullets, i.e. between 3 and 4.

=C2=A0 =C2=A0 =C2=A0 3.5 Reception of a previously unknown SSRC that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 contains an PT value that exists in the payload= type mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 table, will result in that SSRC be associated w= ith the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 corresponding m=3D line.

However, the above is not sufficient, it also needs an amendment to bullet = 2, where if the PT value does not match the m=3D line context the associati= on needs to be updated.

For the RTCP part the appendix B description is even more foreign to my imp= lementations. As the implementations will process the information of the in= coming RTCP compound packet and then provide API that notifies the higher l= ayer of the changes of interest. Like for example the reception of a Feedba= ck Request, or the change to a SDES item for a particular SSRC. Thus the ac= tions related to RTCP becomes even more abstract. Where the description say= s "deliver a copy of the RTCP packet to the "m=3D" line asso= ciated with that SSRC" I would say "Process the information in th= e context of the m=3D line that is associated with the SSRC".

So my conclusion is that the current issue is how we find a specific enough= description that at the same time does not restrict how you implement your= RTP stack.

Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=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| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----

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

--94eb2c07f76cc10a5f05468e2315-- From nobody Fri Jan 20 15:06:57 2017 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 5487312954C for ; Fri, 20 Jan 2017 15:06:56 -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, 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 OvXdR2muOc1a for ; Fri, 20 Jan 2017 15:06:54 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 7CF0312953F for ; Fri, 20 Jan 2017 15:06:54 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id y9so74340918uae.2 for ; Fri, 20 Jan 2017 15:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nKost+5jFf3ccVMCRTRC1iPXk2mpebK0Rw7W+h79zII=; b=DGNYv/45P1XSAgV3+Ig+gnCFzIsgcsh7ZH0jky4DbJImPYYJPKRGjqkwPxqtwrOeDv xRWIkDcMoSX9gtEfdcd8KJ28EmUbURmFHStMGoCWSHsvCLCLLJx9skDORNtDqUXTKDJ5 7J+bBXOVg592KGXGw+EkjPhNB/ygTzzaixejM4jz5YRKELzuz1CGsgCo9N3JVWEMGweE fAKQ0qoB8s9p2Mrm2J/KTETZJl2Xl+l1UYfoLLBx9rK4o6uFGZwD0HJHzuW4+HorL412 YpoqiST93aNqvn9OZXrjeYcbH0WF4nUNkTp99vgA/UjQGJKzpZyuchBdbsPHygVI+Hdp IA7w== 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=nKost+5jFf3ccVMCRTRC1iPXk2mpebK0Rw7W+h79zII=; b=DpTNp9wlnK2ULdg6oRu7b+5mTAQQ9IDUYDq1UYCNTzAbvjvg/2D+briKJHsxL+cZ6d IBEKmPJvKfnTgF6w6YUMh+h3PtcHn3EFNxvOPNUbmiM+8UKHtm/EnPaJEXgxl7L6NHHj DEesqs5nJp8HVL06SLRCtHhUOyYs6aM87EDb8btdeGvvkmsHkM19INjqLduVCndQJrqh +R6W/tr0AXh4kA0yj7HMqo3wWaIhQOxc2CWiNPU/MT4sBdrAaGKnnOy5kxJk0DSgMs1d /ftsSRNQCzI7aYeIOCMgeS7tg/FhSf0VlUXGlSWfwiWcE/7CBHCq+twhL+Gnd28Jihp1 AWTA== X-Gm-Message-State: AIkVDXIbSwHk1HqSNylT4p3KkKbELasrg2VbiiEeICzEeeSU6btPKry/GQy3oitgOEDWWSCWWZLelusNDtmQlg== X-Received: by 10.176.22.158 with SMTP id e30mr8111886uaf.33.1484953613447; Fri, 20 Jan 2017 15:06:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.37 with HTTP; Fri, 20 Jan 2017 15:06:32 -0800 (PST) In-Reply-To: References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: Bernard Aboba Date: Fri, 20 Jan 2017 15:06:32 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f403045f6be4a337b005468eb4a2 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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, 20 Jan 2017 23:06:56 -0000 --f403045f6be4a337b005468eb4a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Magnus said: "What I fail to understand is what this legacy is that does multiple m=3D lines within a single RTP session is. For how many deployed devices are we ensuring interop with?" [BA] Here is an example of a scenario which utilizes PT routing rules. This is not theoretical - it arises from a bug report that landed on my desk. The bug is showing up in a basic application which appears to be using both RTP/RTCP mux and BUNDLE (as the vast majority of WebRTC applications do). I don't know if this application is using SIP signaling or not, or trying to interop with a legacy (non-WebRTC) implementation, but since PT-routing seems to be implemented so widely by developers, the bug could easily show up in a new application that had no legacy-interop requirements. The application is not signaling SSRCs or MIDs, just PTs. When the SSRC changes (PT remains the same), the developer is expecting the RTP packets to be routed to the same receiver based on a PT match, without having to signal the new SSRC. The JSEP Appendix B routing rules will produce this behavior. Chrome also apparently exhibits this behavior and the developer filing the bug expects all WebRTC browsers to behave the same way. On Fri, Jan 20, 2017 at 2:01 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2017-01-18 kl. 15:52, skrev Cullen Jennings: > >> >> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund >>> wrote: >>> >>> >>> Regarding PT based routing: >>> >>> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing >>> of packets are not required for any WebRTC endpoint. >>> >> >> Look, I don't see it this way and I suspect you are going to agree >> with what I say next.... WebRTC browsers are required to interoperate >> with "legacy" things that don't do bundle and things that may do >> bundle but try not to use MIDs in cases where they are a gratuitous >> waste of bandwidth. >> >> PT based routing works only in some constrained usages, thus my >>> view is that it needs to remain a hint, and an optional hint at >>> most. It must be clear that it is not something that is reliable. >>> >> >> You keep asserting this but I'm not convinced you are are correct so >> perhaps you could explain the where they don't work. I seen lots of >> projects ship this and work fine. The algorithm in appendix B make it >> clear PT are only used if they are unique across all the m-lines. So >> clearly it can not be used if you need more PT than are available in >> the PT space. A huge percentage of of real world use cases for SDP >> easily fit inside the current PT space. One of the cases I care about >> if a low peak bandwidth phone (not average) for places like parts of >> Africa that uses a 700 bps codec. Most single stream of audio and >> video "video phone call" type cases also easily work. Yes, I >> understand one could construct some single audio/video where enough >> things were the SDP offer needs more PTs than there was space for but >> if you look at the SDP from just about every major manufacture of >> VoIP audio phones, you see what they are currently doing can easily >> be done with unique PT values. Anyway, for these case where you don't >> run out of PT, please please explain why PT routing is so broken that >> is should be an optional hint. In practice it seems to work fine. >> > > I will not contest that it does work as long as you ensure that PT values > are unique across all m=3D lines in one RTP session. My objection is on a= n > architectural level here. As the PT requirement is not unique one needs t= o > implement a=3DMIDs. Thus, the PT routing rules becomes a crutch that gets > embedded into also the standards implementation not only the legacy and > carried forward. What I fail to understand is what this legacy is that do= es > multiple m=3D lines within a single RTP session is. For how many deployed > devices are we ensuring interop with? > > >> Anyways, I'm just not seeing what you think the problem is here. I >> don't see a problem so I feel pretty strongly that the algorithm in >> Appendix B is fine. Convince me on why is "not reliable" and and >> "only in some constrained usages" >> > > I accept that the PT association rules needs to stay in. And this is a > diversion from the part that I have real issue with. The style of the rul= es > that places the routing below the RTP stack, rather than above it. And yo= u > may note that I did explain how my proposed description format would take > PTs into account. My question is would you and others have objections wit= h > rules as I wrote them? > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f403045f6be4a337b005468eb4a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Magnus said:=C2=A0

"What I fail to understand is what this legacy is that do= es multiple m=3D lines within a single RTP session is. For how many deploye= d devices are we ensuring interop with?"

[BA] Here is an example of a scenario which utilizes PT routing rules.= =C2=A0 This is not theoretical - it arises from a bug report that landed on= my desk.=C2=A0

The bug is showing up in a basic a= pplication which appears to be using both RTP/RTCP mux and BUNDLE (as the v= ast majority of WebRTC applications do).=C2=A0 I don't know if this app= lication is using SIP signaling or not, or trying to interop with a legacy = (non-WebRTC) implementation, but since PT-routing seems to be implemented s= o widely by developers, the bug could easily show up in a new application t= hat had no legacy-interop requirements.

The applic= ation is not signaling SSRCs or MIDs, just PTs.=C2=A0 When the SSRC changes= (PT remains the same), the developer is expecting the RTP packets to be ro= uted to the same receiver based on a PT match, without having to signal the= new SSRC.=C2=A0

The JSEP Appendix B routing rules= will produce this behavior.=C2=A0 Chrome also apparently exhibits this beh= avior and the developer filing the bug expects all WebRTC browsers to behav= e the same way.=C2=A0

On Fri, Jan 20, 2017 at 2:01 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Den 2017-01-18 = kl. 15:52, skrev Cullen Jennings:

On Jan 18, 2017, at 3:01 AM, Magnus Westerlund
<mag= nus.westerlund@ericsson.com> wrote:


Regarding PT based routing:

RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing
of packets are not required for any WebRTC endpoint.

Look, I don't see it this way and I suspect you are going to agree
with what I say next.... WebRTC browsers are required to interoperate
with "legacy" things that don't do bundle and things that may= do
bundle but try not to use MIDs in cases where they are a gratuitous
waste of bandwidth.

PT based routing works only in some constrained usages, thus my
view is that it needs to remain a hint, and an optional hint at
most. It must be clear that it is not something that is reliable.

You keep asserting this but I'm not convinced you are are correct so perhaps you could explain the where they don't work. I seen lots of
projects ship this and work fine. The algorithm in appendix B make it
clear PT are only used if they are unique across all the m-lines. So
clearly it can not be used if you need more PT than are available in
the PT space. A huge percentage of of real world use cases for SDP
easily fit inside the current PT space. One of the cases I care about
if a low peak bandwidth phone (not average) for places like parts of
Africa that uses a 700 bps codec. Most single stream of audio and
video "video phone call" type cases also easily work. Yes, I
understand one could construct some single audio/video where enough
things were the SDP offer needs more PTs than there was space for but
if you look at the SDP from just about every major manufacture of
VoIP audio phones, you see what they are currently doing can easily
be done with unique PT values. Anyway, for these case where you don't run out of PT, please please explain why PT routing is so broken that
is should be an optional hint. In practice it seems to work fine.

I will not contest that it does work as long as you ensure that PT values a= re unique across all m=3D lines in one RTP session. My objection is on an a= rchitectural level here. As the PT requirement is not unique one needs to i= mplement a=3DMIDs. Thus, the PT routing rules becomes a crutch that gets em= bedded into also the standards implementation not only the legacy and carri= ed forward. What I fail to understand is what this legacy is that does mult= iple m=3D lines within a single RTP session is. For how many deployed devic= es are we ensuring interop with?


Anyways, I'm just not seeing what you think the problem is here. I
don't see a problem so I feel pretty strongly that the algorithm in
Appendix B is fine. Convince me on why is "not reliable" and and<= br> "only in some constrained usages"

 I accept that the PT association rules needs to stay in. And this is a dive= rsion from the part that I have real issue with. The style of the rules tha= t places the routing below the RTP stack, rather than above it. And you may= note that I did explain how my proposed description format would take PTs = into account. My question is would you and others have objections with rule= s as I wrote them?

Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=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| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----

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

--f403045f6be4a337b005468eb4a2-- From nobody Fri Jan 20 16:21:29 2017 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 4A801129613 for ; Fri, 20 Jan 2017 16:21:28 -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 dSs0JrlguifC for ; Fri, 20 Jan 2017 16:21:26 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 7EF891295EE for ; Fri, 20 Jan 2017 16:21:26 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id y9so75222481uae.2 for ; Fri, 20 Jan 2017 16:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=vnIFsWwWRmPt6Rmxv0QKyDlAJnZxbfPCmWjWqJ3sB/Q=; b=la+amwuqypT3Rp9ZYl4MNmoSiG6nkQGCooUpEbEq2brX+xMzt9Jdsjq3gY+Mo0kHvD 7FDsQam1Vy/3aCCbnRJwV6apgu/sgr9oGBq0CZNSky/w9n9UbmKyZG6OTGIR81MWEsVf KBXZbiGgki2MdbtliRua8/DJkmiNQlKw78nqS8fn050fdcH+G/PEM42YhSnAcGMYuzzh LNClfYOX/1Npt5pKIkov4s2wseBUnw1nyVtNxe1DZOcB0MEzxuMt0jFwBMQzv++/L89L Deygj2Tna8XbXy03mB7X1TWuZHoR+XhBuse62JVYDB/j33TNEN4VskuSqh5I8VbB1nzj L6fQ== 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:cc; bh=vnIFsWwWRmPt6Rmxv0QKyDlAJnZxbfPCmWjWqJ3sB/Q=; b=B6UDneCsy+QCIMnjoTX6zPV5GLzVvLRX62BEEPrD+qk9+H986hFjR3p+M6bJ4hIjpg MZyT8KdYTA+oFZhD7ur3TIivCmcY56NthRyMaK9gKP8MADDgFnRgjI4GuqhuRkqFntOl Wb2Awxava2XMb8gs5cscEtWSPP3i92/yppLkriA/iOx5PqjHQyri1mcqxt+rL7zU0Ku/ QBMIATKTya+Oi7GKzM7uryx1998QWzPKx8pZXNfBfSPWMaAdslmZPD6MRw9iz0EMzsD0 LEzU/fIgeMH/0GVAK4q1iPXIA96fezI/iFLRUs0oNv013HG/I0FZQQo41cJFA6ItOKrK jbZw== X-Gm-Message-State: AIkVDXK6Qer04QC4LGYm/3UHw5bG3t87wKUaUeS2lFGT94igd6NUGOQ1ZQPzY1BxU/utWkO0H1/9PaQbYb9AOQ== X-Received: by 10.176.3.196 with SMTP id 62mr9608322uau.120.1484958085477; Fri, 20 Jan 2017 16:21:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.37 with HTTP; Fri, 20 Jan 2017 16:21:05 -0800 (PST) From: Bernard Aboba Date: Fri, 20 Jan 2017 16:21:05 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11487a0e30fc7005468fbf8d Archived-At: Subject: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets 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: Sat, 21 Jan 2017 00:21:28 -0000 --001a11487a0e30fc7005468fbf8d Content-Type: text/plain; charset=UTF-8 It has been pointed out to me that the text in JSEP Appendix B does not include text relating to the routing of RTCP XR packets, described in RFC 3611. Since RTCP XR packets include report blocks with different formats coming up with appropriate text is challenging. For example, the following text covers Loss RLE Report Blocks (Section 4.1), Duplicate RLE Report Blocks (Section 4.2), Packet Receipt Times Report Blocks (Section 4.3), Statistics Summary Report Blocks (Section 4.6) and VoIP Metric Report Blocks (Section 4.7): If the packet is of type XR with a BT of 1 (Loss RLE Report Block), 2 (Duplicate RLE Report Block), 3 (Packet Receipt Times Report Block), 6 (Statistics Summary Report Block), 7 (VoIP Metric Report Block), for each report block in the packet whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the "m=" line associated with that SSRC. However, RFC 3611 also includes the Receiver Reference Report Block (Section 4.4) whose format looks like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=4 | reserved | block length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should this be forwarded to the RtpSender whose outgoing SSRC table that matches the "SSRC" field in the RTCP XR packet? There is also is the DLRR Report Block (Section 4.5) whose format looks like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=5 | reserved | block length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ For this one, I'm assuming that the SSRC of Nth receiver field is matched against the ssrc_table to determine the appropriate RtpReceivers to receive a copy of the RTCP packet. There are of course other RTCP XR RFCs. I have not reviewed those yet. But before doing that, I'd like to get some feedback on whether the general approach outlined above is sane (or whether parsing individual RTCP XR report blocks is a bad idea to begin with). --001a11487a0e30fc7005468fbf8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It has been pointed out to me that the text in JSEP Append= ix B does not include text relating to the routing of RTCP XR packets, desc= ribed in RFC 3611.=C2=A0

Since RTCP XR packets include r= eport blocks with different formats coming up with appropriate text is chal= lenging.=C2=A0

For example, the following text cov= ers Loss RLE Report Blocks (Section 4.1), Duplicate RLE Report Blocks (Sect= ion 4.2), Packet Receipt Times Report Blocks (Section 4.3), Statistics Summ= ary Report Blocks (Section 4.6) and VoIP Metric Report Blocks (Section 4.7)= :

=C2=A0 =C2=A0If the packet is of type XR with a = BT of 1 (Loss RLE Report Block), 2 (Duplicate RLE Report
=C2=A0 = =C2=A0Block), =C2=A03 (Packet Receipt Times Report Block), 6 (Statistics Su= mmary Report Block),=C2=A0
=C2=A0 7 (VoIP Metric Report Block), f= or each report block in the packet whose "SSRC of source"
=C2=A0 =C2=A0is found in the outgoing SSRC table, deliver a copy of the = RTCP packet to the
=C2=A0 =C2=A0"m=3D" line associated = with that SSRC.

However, RFC 3611 also includes th= e Receiver Reference Report Block (Section 4.4) whose format looks like thi= s:=C2=A0

    0  =
                 1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=3D4      |   reserved    |       block length =3D 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NTP timestamp, most significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             NTP timestamp, least significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= /div>


Should this be forwarded to the Rtp= Sender whose outgoing SSRC table that matches the
"SSRC"= ; field in the RTCP XR packet?=C2=A0


There is also is the DLRR Report Block (Section 4.5) whose format looks l= ike this:=C2=A0

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=3D5      |   reserved    |         block length          |
 +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+
 |                 SSRC_1 (SSRC of first receiver)               | sub-
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
 |                         last RR (LRR)                         |   1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   delay since last RR (DLRR)                  |
 +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+
 |                 SSRC_2 (SSRC of second receiver)              | sub-
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
 :                               ...                             :   2
 +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

For this one, I'm assuming that t= he SSRC of Nth receiver field is matched against the
= ssrc_table to determine the appropriate RtpReceivers to receive a copy of t= he RTCP packet.=C2=A0

There are of course other RT= CP XR RFCs.=C2=A0 I have not reviewed those yet.=C2=A0 But before doing tha= t, I'd like to get some feedback on whether the general approach outlin= ed above is sane (or whether parsing individual RTCP XR report blocks is a = bad idea to begin with).=C2=A0
--001a11487a0e30fc7005468fbf8d-- From nobody Sat Jan 21 05:34:05 2017 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 1001F129A59 for ; Sat, 21 Jan 2017 05:34:04 -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 ERleiiIPfypd for ; Sat, 21 Jan 2017 05:34:01 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 F31E4129A64 for ; Sat, 21 Jan 2017 05:34:00 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-17-58836346c0f4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 7F.ED.25710.64363885; Sat, 21 Jan 2017 14:33:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Sat, 21 Jan 2017 14:32:05 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [rtcweb] Working group last call resolutions/Consensus call: Appendix B Thread-Index: AQHScXHRfPdpg2TYPU+10qpCTZWsc6E+QWwAgAAtEICAAuHCgIAAkq+AgAEPWQA= Date: Sat, 21 Jan 2017 13:32:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF941B1@ESESSMB209.ericsson.se> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BF941B1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7tK5bcnOEwcUjlhYb9v1ntljx+hy7 xYf1Pxgt1v5rZ3dg8dg56y67x5IlP5k8Lp//yOgx+XEbcwBLFJdNSmpOZllqkb5dAlfGhCly BZsamSo6Ts1ibmC88Iuxi5GDQ0LARGLPyrouRi4OIYF1jBJzPnxi72LkBHIWM0r0t5mC1LAJ WEh0/9MGCYsIKEj8+nOCBSTMLJArMeOgI0hYWCBM4t2/P2BhEYFwiYXLVSCq/SQWLjrHCGKz CKhKfL6zngXE5hXwlZi9fBcjxNZvTBJnd75jAunlFAiUuPskA6SGUUBM4vupNUwgNrOAuMSt J/PBbAkBAYkle84zQ9iiEi8f/2OFsJUkFt3+DFWfL7Fg/h9WiF2CEidnPmGZwCgyC8moWUjK ZiEpmwX2mKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+n l5dasokRGHcHt/zW3cG4+rXjIUYBDkYlHl6DuKYIIdbEsuLK3EOMEhzMSiK8HQnNEUK8KYmV ValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwLsv5HbvlpnP+RNd3 62oeV73/qr1X99Kufb6OGS/vLJ8dGyB9Z4vWijdnVzD/Y193+uDmMxqiNrsbgjeX/BEU18i5 5X3Ic2KlfujMXHcjp3Uuaa9YTu0oCTpYGbTOZa/QfImyU/Guf5LSlufbuX7JfFKfX1o+cfLT DaXcjC/9pS+aTNMNfH06UYmlOCPRUIu5qDgRAD1+rLO3AgAA Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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: Sat, 21 Jan 2017 13:34:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BF941B1ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JdCdzIG5vdCBiaWcgZW5vdWdoIGZvciBldmVyeSB1c2UgY2FzZSBidXQgaXQncyBp biB1c2UgZm9yIGNlcnRhaW4gbGltaXRlZCB1c2UgY2FzZXMgPm5vdy4gSGVuY2UgdGhlIG5lZWQg dG8gc3VwcG9ydCBQVCBub3cgYW5kIE1JRCBpbiB0aGUgZnV0dXJlDQoNCkluIHRoYXQgY2FzZSB0 aGVyZSBzaG91bGQgYmUgYSBjbGVhciBydWxlIHNheWluZyB0aGF0LCBpZiB0aGUgUFRzIGFyZSB1 bmlxdWUsIHRoZXkgY2FuIGJlIHVzZWQuIE5vIOKAnGhpbnRz4oCdIDopDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCg0KDQpPbiBGcmksIEphbiAyMCwgMjAxNyBhdCAzOjMzIEFNLCBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGksDQoNCklmIHRoaW5ncyB3b3Jr IGZpbmUgdXNpbmcgUFQsIHdoeSBkbyB3ZSBtYW5kYXRlIE1JRCBpbiB0aGUgZmlyc3QgcGxhY2U/ IFdoeSB3b3VsZCBwZW9wbGUgaW1wbGVtZW50IE1JRCBpbiB0aGUgZnV0dXJlIGlmIFBUIHdvcmtz Pw0KDQpVbmxlc3MgSSByZW1lbWJlciB3cm9uZywgQWRhbSBpcyB0aGUgb25lIHdobyBzYWlkIHRo YXQgdGhlIFBUIHNwYWNlIGlzIG5vdCBiaWcgZW5vdWdoLCBhbmQgdGhhdCB3ZSB0aGVyZWZvciBu ZWVkIHNvbWV0aGluZyBlbHNlIOKAkyB3aGljaCBtYWRlIHVzIG1hbmRhdGUgU1NSQywgc3BlY2lm eSB0aGUgdG9vbHMgZm9yIE1JRCB0cmFuc3BvcnQsIGV0Yy4NCg0KQWxzbywgSSBhbSBub3Qgc3Vy ZSB3aGF0IGlzIG1lYW50IGJ5IGEg4oCcaGludOKAnS4gSWYgdGhlcmUgYXJlIGFwcGxpY2F0aW9u cyB0aGF0IGRvbuKAmXQgc3VwcG9ydCBNSUQsIGFuZCBuZWVkIHRvIHVzZSBQVCwgdGhlbiBpdCBo YXMgdG8gYmUgbW9yZSB0aGFuIGEg4oCcaGludOKAnS4gSXQgbXVzdCBiZSBhIHRlc3RhYmxlIHJ1 bGUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KRnJvbTogcnRjd2ViIDxydGN3 ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJl cm5hcmQuYWJvYmFAZ21haWwuY29tPj4NCkRhdGU6IFdlZG5lc2RheSAxOCBKYW51YXJ5IDIwMTcg YXQgMTk6MzQNClRvOiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E8bWFpbHRvOmZsdWZm eUBpaWkuY2E+Pg0KQ2M6ICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4i IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTog W3J0Y3dlYl0gV29ya2luZyBncm91cCBsYXN0IGNhbGwgcmVzb2x1dGlvbnMvQ29uc2Vuc3VzIGNh bGw6IEFwcGVuZGl4IEINCg0KQ3VsbGVuIHNhaWQ6DQoNCiJMb29rLCBJIGRvbid0IHNlZSBpdCB0 aGlzIHdheSBhbmQgSSBzdXNwZWN0IHlvdSBhcmUgZ29pbmcgdG8gYWdyZWUgd2l0aCB3aGF0IEkg c2F5IG5leHQuLi4uIFdlYlJUQyBicm93c2VycyBhcmUgcmVxdWlyZWQgdG8gaW50ZXJvcGVyYXRl IHdpdGggImxlZ2FjeSIgdGhpbmdzIHRoYXQgZG9uJ3QgZG8gYnVuZGxlIGFuZCB0aGluZ3MgdGhh dCBtYXkgZG8gYnVuZGxlIGJ1dCB0cnkgbm90IHRvIHVzZSBNSURzIGluIGNhc2VzIHdoZXJlIHRo ZXkgYXJlIGEgZ3JhdHVpdG91cyB3YXN0ZSBvZiBiYW5kd2lkdGguIg0KDQpbQkFdICsxLiAgIFRo ZXJlIGlzIGRlZmluaXRlbHkgYW4gZXhwZWN0YXRpb24gb24gdGhlIHBhcnQgb2YgZGV2ZWxvcGVy cyB0aGF0IFdlYlJUQyB3aWxsIGJlaGF2ZSBsaWtlIHRoZSAibGVnYWN5IiBTRFAgdGhleSBhcmUg dXNlZCB0byAtIGV2ZW4gaWYgdGhleSBhcmUgbm90IGludGVyb3BlcmF0aW5nIHdpdGggbGVnYWN5 IGFwcGxpY2F0aW9ucy4gIFNpbmNlIHRob3NlIGFwcGxpY2F0aW9ucyB3b3JrZWQgd2l0aG91dCBN SURzLCBkZXZlbG9wZXJzIHdpbGwgZXhwZWN0IHRoZW0gdG8gY29udGludWUgdG8gd29yayB3aGVu IE1JRCBzdXBwb3J0IGlzIGludHJvZHVjZWQgaW4gZnV0dXJlLg0KDQoiSSBzZWVuIGxvdHMgb2Yg cHJvamVjdHMgc2hpcCB0aGlzIGFuZCB3b3JrIGZpbmUuIFRoZSBhbGdvcml0aG0gaW4gYXBwZW5k aXggQiBtYWtlIGl0IGNsZWFyIFBUIGFyZSBvbmx5IHVzZWQgaWYgdGhleSBhcmUgdW5pcXVlIGFj cm9zcyBhbGwgdGhlIG0tbGluZXMuIFNvIGNsZWFybHkgaXQgY2FuIG5vdCBiZSB1c2VkIGlmIHlv dSBuZWVkIG1vcmUgUFQgdGhhbiBhcmUgYXZhaWxhYmxlIGluIHRoZSBQVCBzcGFjZS4gQSBodWdl IHBlcmNlbnRhZ2Ugb2Ygb2YgcmVhbCB3b3JsZCB1c2UgY2FzZXMgZm9yIFNEUCBlYXNpbHkgZml0 IGluc2lkZSB0aGUgY3VycmVudCBQVCBzcGFjZS4iDQoNCltCQV0gKzEuICBNeSBleHBlcmllbmNl IGlzIHRoYXQgKm1vc3QqIG9mIHRoZSBkZXZlbG9wZXJzIHNoaXBwaW5nIFdlYlJUQyBhcHBsaWNh dGlvbnMgdGhhdCBydW4gb24gbXVsdGlwbGUgYnJvd3NlcnMgYXJlIHVzaW5nIFBULWJhc2VkIHJv dXRpbmcsIHNvIHRoZXknZCBiZSB2ZXJ5IHN1cnByaXNlZCB0byBsZWFybiB0aGF0IGl0IGlzbid0 IHN1cHBvcnRlZCAoYW5kIHRoZXkgd291bGQgcHJvYmFibHkgcHVzaCBiYWNrIHZpZ29yb3VzbHkg YXQgc3VjaCBhIG5vdGlvbikuDQoNCiJBbnl3YXlzLCBJJ20ganVzdCBub3Qgc2VlaW5nIHdoYXQg eW91IHRoaW5rIHRoZSBwcm9ibGVtIGlzIGhlcmUuIEkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSBzbyBJ IGZlZWwgcHJldHR5IHN0cm9uZ2x5IHRoYXQgdGhlIGFsZ29yaXRobSBpbiBBcHBlbmRpeCBCIGlz IGZpbmUuIg0KDQpbQkFdIFRoZSBhbGdvcml0aG0gaW4gQXBwZW5kaXggQiBpbmNsdWRlcyBQVCBy b3V0aW5nIGFuZCBJJ2QgbGlrZSBpdCB0byBjb250aW51ZSB0byBjb3ZlciB0aGF0LiAgVGhlIGFs Z29yaXRobSBhcHBlYXJzIHRvIHJlc29sdmUgYSBudW1iZXIgb2YgYnVncyBmaWxlZCBieSBib3Ro IFdlYlJUQyBhbmQgT1JUQyBkZXZlbG9wZXJzLiBJdCB3aWxsIHRha2UgYSBiaXQgbW9yZSByZXZp ZXcgdG8gY29uZmlybSB0aGF0IGl0IGRvZXNuJ3QgY2F1c2UgYW55IHJlZ3Jlc3Npb25zLg0KDQpP biBXZWQsIEphbiAxOCwgMjAxNyBhdCA2OjUyIEFNLCBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBp aWkuY2E8bWFpbHRvOmZsdWZmeUBpaWkuY2E+PiB3cm90ZToNCg0KPiBPbiBKYW4gMTgsIDIwMTcs IGF0IDM6MDEgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPg0K Pg0KPiBSZWdhcmRpbmcgUFQgYmFzZWQgcm91dGluZzoNCj4NCj4gUlRDV2ViIHJlcXVpcmVzIEJV TkRMRSwgQlVORExFIHJlcXVpcmVzIE1JRHMsIHRodXMgUFQgYmFzZWQgcm91dGluZyBvZiBwYWNr ZXRzIGFyZSBub3QgcmVxdWlyZWQgZm9yIGFueSBXZWJSVEMgZW5kcG9pbnQuDQoNCkxvb2ssIEkg ZG9uJ3Qgc2VlIGl0IHRoaXMgd2F5IGFuZCBJIHN1c3BlY3QgeW91IGFyZSBnb2luZyB0byBhZ3Jl ZSB3aXRoIHdoYXQgSSBzYXkgbmV4dC4uLi4gV2ViUlRDIGJyb3dzZXJzIGFyZSByZXF1aXJlZCB0 byBpbnRlcm9wZXJhdGUgd2l0aCAibGVnYWN5IiB0aGluZ3MgdGhhdCBkb24ndCBkbyBidW5kbGUg YW5kIHRoaW5ncyB0aGF0IG1heSBkbyBidW5kbGUgYnV0IHRyeSBub3QgdG8gdXNlIE1JRHMgaW4g Y2FzZXMgd2hlcmUgdGhleSBhcmUgYSBncmF0dWl0b3VzIHdhc3RlIG9mIGJhbmR3aWR0aC4NCg0K PiBQVCBiYXNlZCByb3V0aW5nIHdvcmtzIG9ubHkgaW4gc29tZSBjb25zdHJhaW5lZCB1c2FnZXMs IHRodXMgbXkgdmlldyBpcyB0aGF0IGl0IG5lZWRzIHRvIHJlbWFpbiBhIGhpbnQsIGFuZCBhbiBv cHRpb25hbCBoaW50IGF0IG1vc3QuDQo+IEl0IG11c3QgYmUgY2xlYXIgdGhhdCBpdCBpcyBub3Qg c29tZXRoaW5nIHRoYXQgaXMgcmVsaWFibGUuDQoNCllvdSBrZWVwIGFzc2VydGluZyB0aGlzIGJ1 dCBJJ20gbm90IGNvbnZpbmNlZCB5b3UgYXJlIGFyZSBjb3JyZWN0IHNvIHBlcmhhcHMgeW91IGNv dWxkIGV4cGxhaW4gdGhlIHdoZXJlIHRoZXkgZG9uJ3Qgd29yay4gSSBzZWVuIGxvdHMgb2YgcHJv amVjdHMgc2hpcCB0aGlzIGFuZCB3b3JrIGZpbmUuIFRoZSBhbGdvcml0aG0gaW4gYXBwZW5kaXgg QiBtYWtlIGl0IGNsZWFyIFBUIGFyZSBvbmx5IHVzZWQgaWYgdGhleSBhcmUgdW5pcXVlIGFjcm9z cyBhbGwgdGhlIG0tbGluZXMuIFNvIGNsZWFybHkgaXQgY2FuIG5vdCBiZSB1c2VkIGlmIHlvdSBu ZWVkIG1vcmUgUFQgdGhhbiBhcmUgYXZhaWxhYmxlIGluIHRoZSBQVCBzcGFjZS4gQSBodWdlIHBl cmNlbnRhZ2Ugb2Ygb2YgcmVhbCB3b3JsZCB1c2UgY2FzZXMgZm9yIFNEUCBlYXNpbHkgZml0IGlu c2lkZSB0aGUgY3VycmVudCBQVCBzcGFjZS4gT25lIG9mIHRoZSBjYXNlcyBJIGNhcmUgYWJvdXQg aWYgYSBsb3cgcGVhayBiYW5kd2lkdGggcGhvbmUgKG5vdCBhdmVyYWdlKSBmb3IgcGxhY2VzIGxp a2UgcGFydHMgb2YgQWZyaWNhIHRoYXQgdXNlcyBhIDcwMCBicHMgY29kZWMuIE1vc3Qgc2luZ2xl IHN0cmVhbSBvZiBhdWRpbyBhbmQgdmlkZW8gInZpZGVvIHBob25lIGNhbGwiIHR5cGUgY2FzZXMg YWxzbyBlYXNpbHkgd29yay4gWWVzLCBJIHVuZGVyc3RhbmQgb25lIGNvdWxkIGNvbnN0cnVjdCBz b21lIHNpbmdsZSBhdWRpby92aWRlbyB3aGVyZSBlbm91Z2ggdGhpbmdzIHdlcmUgdGhlIFNEUCBv ZmZlciBuZWVkcyBtb3JlIFBUcyB0aGFuIHRoZXJlIHdhcyBzcGFjZSBmb3IgYnV0IGlmIHlvdSBs b29rIGF0IHRoZSBTRFAgZnJvbSBqdXN0IGFib3V0IGV2ZXJ5IG1ham9yIG1hbnVmYWN0dXJlIG9m IFZvSVAgYXVkaW8gcGhvbmVzLCB5b3Ugc2VlIHdoYXQgdGhleSBhcmUgY3VycmVudGx5IGRvaW5n IGNhbiBlYXNpbHkgYmUgZG9uZSB3aXRoIHVuaXF1ZSBQVCB2YWx1ZXMuIEFueXdheSwgZm9yIHRo ZXNlDQogIGNhc2Ugd2hlcmUgeW91IGRvbid0IHJ1biBvdXQgb2YgUFQsIHBsZWFzZSBwbGVhc2Ug ZXhwbGFpbiB3aHkgUFQgcm91dGluZyBpcyBzbyBicm9rZW4gdGhhdCBpcyBzaG91bGQgYmUgYW4g b3B0aW9uYWwgaGludC4gSW4gcHJhY3RpY2UgaXQgc2VlbXMgdG8gd29yayBmaW5lLg0KDQpBbnl3 YXlzLCBJJ20ganVzdCBub3Qgc2VlaW5nIHdoYXQgeW91IHRoaW5rIHRoZSBwcm9ibGVtIGlzIGhl cmUuIEkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSBzbyBJIGZlZWwgcHJldHR5IHN0cm9uZ2x5IHRoYXQg dGhlIGFsZ29yaXRobSBpbiBBcHBlbmRpeCBCIGlzIGZpbmUuIENvbnZpbmNlIG1lIG9uIHdoeSBp cyAibm90IHJlbGlhYmxlIiBhbmQgYW5kICJvbmx5IGluIHNvbWUgY29uc3RyYWluZWQgdXNhZ2Vz Ig0KDQo+IEkgYWxzbyBzdHJ1Z2dsZSB0byBzZWUgaW4gd2hhdCBub24tV2ViUlRDIGludGVyb3Ag dXNlIGNhc2VzIHRoaXMgYXJpc2VzLiBUaGUgbm9uLVdlYlJUQyBlbmRwb2ludCBuZWVkcyB0byBi ZSBjYXBhYmxlIG9mIG11bHRpIG1lZGlhIHNvdXJjZSwgYW5kIG11bHRpIHN0cmVhbSAoU1NSQykg UlRQIHNlc3Npb25zLCBidXQgbm90IGltcGxlbWVudCBCVU5ETEUuIE9yIGlzIGl0IGEgYWdncmVn YXRpbmcgZ2F0ZXdheSwgdGhhdCBpcyB0byBsYXp5IHRvIGFkZCBNSURzPw0KPg0KDQoNClBlb3Bs ZSB3YW50IHRvIGF2b2lkIHRoZSBtZWRpYSBnYXRld2F5IGJldHdlZW4gV2ViUlRDIGFuZCBhbmQg YW4gU0lQIGVuZHBvaW50IHdoZXJlIHRoZXkgY2FuLiBUaGUgbWVkaWEgZ2F0ZXdheSBhZGRzIGxh dGVuY3kgLSBodWdlIGFtb3VudHMgaW4gdGhlIGNhc2Ugd2hlcmUgYm90aCBlbmRwb2ludHMgcmVx dWlyZSBhIHNhdGVsbGl0ZSBob3AgdG8gZ2V0IHRvIHRoZSBnYXRld2F5IC0gYW5kIGl0IGFkZCB0 aGUgYmFuZHdpZHRoIGV4cGVuc2VzIG9mIHJ1bm5pbmcgZ2F0ZXdheS4NCg0KDQoNCk9uIGFsbCBv ZiB0aGlzLCBJIHdhbnQgdG8gYmUgY2xlYXIsIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRvIHNv bWV0aGluZyB3aGVyZSB0aGUgUFQgc3BhY2UgaXMgbm90IGxhcmdlIGVub3VnaCwgb2J2aW91c2x5 IHRoZXkgY2FuIHVzZSBNSUQsIEknbSBqdXN0IHNheWluZyB0aGF0IGZvciB0aGluZ3MgdGhhdCBk b24ndCB1c2UgTUlELCBhbmQgY2FuIGZpdCBpbiB0aGUgUFQgc3BhY2UsIGl0IHNob3VsZCBiZSBh biBvcHRpb24gdG8gdXNlIFBUIGFuZCBrbm93IGl0IHdpbGwgd29yay4NCg0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFp bGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QN CnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BF941B1ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwv c3Bhbj5JdCdzIG5vdCBiaWcgZW5vdWdoIGZvciBldmVyeSB1c2UgY2FzZSBidXQgaXQncyBpbiB1 c2UgZm9yIGNlcnRhaW4gbGltaXRlZCB1c2UgY2FzZXMNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mZ3Q7PC9zcGFuPm5vdy4gSGVuY2UgdGhlIG5lZWQgdG8gc3VwcG9ydCBQVCBub3cgYW5k IE1JRCBpbiB0aGUgZnV0dXJlPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JbiB0aGF0IGNhc2UgdGhlcmUgc2hvdWxkIGJlIGEgY2xlYXIgcnVsZSBzYXlpbmcgdGhhdCwg aWYgdGhlIFBUcyBhcmUgdW5pcXVlLCB0aGV5IGNhbiBiZSB1c2VkLiBObyDigJxoaW50c+KAnSA6 KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgSmFuIDIwLCAyMDE3IGF0IDM6MzMgQU0sIENocmlzdGVyIEhvbG1iZXJn ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIHRoaW5ncyB3b3JrIGZpbmUgdXNp bmcgUFQsIHdoeSBkbyB3ZSBtYW5kYXRlIE1JRCBpbiB0aGUgZmlyc3QgcGxhY2U/IFdoeSB3b3Vs ZCBwZW9wbGUgaW1wbGVtZW50IE1JRCBpbiB0aGUgZnV0dXJlIGlmIFBUIHdvcmtzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5Vbmxlc3MgSSByZW1lbWJlciB3cm9uZywgQWRhbSBpcyB0aGUgb25lIHdobyBzYWlkIHRo YXQgdGhlIFBUIHNwYWNlIGlzIG5vdCBiaWcgZW5vdWdoLCBhbmQgdGhhdCB3ZSB0aGVyZWZvciBu ZWVkIHNvbWV0aGluZyBlbHNlIOKAkyB3aGljaCBtYWRlIHVzIG1hbmRhdGUgU1NSQywgc3BlY2lm eQ0KIHRoZSB0b29scyBmb3IgTUlEIHRyYW5zcG9ydCwgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BbHNvLCBJ IGFtIG5vdCBzdXJlIHdoYXQgaXMgbWVhbnQgYnkgYSDigJxoaW504oCdLiBJZiB0aGVyZSBhcmUg YXBwbGljYXRpb25zIHRoYXQgZG9u4oCZdCBzdXBwb3J0IE1JRCwgYW5kIG5lZWQgdG8gdXNlIFBU LCB0aGVuIGl0IGhhcyB0byBiZSBtb3JlIHRoYW4gYSDigJxoaW504oCdLiBJdCBtdXN0DQogYmUg YSB0ZXN0YWJsZSBydWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5DaHJpc3Rl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5ydGN3ZWIgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVo YWxmIG9mIEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5IDE4IEphbnVhcnkgMjAxNyBhdCAxOTozNDxicj4N CjxiPlRvOiA8L2I+Q3VsbGVuIEplbm5pbmdzICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGlp aS5jYSIgdGFyZ2V0PSJfYmxhbmsiPmZsdWZmeUBpaWkuY2E8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8 L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnJ0Y3dlYkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogW3J0Y3dlYl0gV29ya2luZyBncm91cCBsYXN0IGNhbGwgcmVzb2x1dGlv bnMvQ29uc2Vuc3VzIGNhbGw6IEFwcGVuZGl4IEI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPkN1bGxlbiBzYWlkOiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mcXVvdDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkxvb2ssIEkgZG9uJ3Qgc2VlIGl0IHRoaXMgd2F5IGFuZCBJ IHN1c3BlY3QgeW91IGFyZSBnb2luZyB0byBhZ3JlZSB3aXRoIHdoYXQNCiBJIHNheSBuZXh0Li4u LiBXZWJSVEMgYnJvd3NlcnMgYXJlIHJlcXVpcmVkIHRvIGludGVyb3BlcmF0ZSB3aXRoICZxdW90 O2xlZ2FjeSZxdW90OyB0aGluZ3MgdGhhdCBkb24ndCBkbyBidW5kbGUgYW5kIHRoaW5ncyB0aGF0 IG1heSBkbyBidW5kbGUgYnV0IHRyeSBub3QgdG8gdXNlIE1JRHMgaW4gY2FzZXMgd2hlcmUgdGhl eSBhcmUgYSBncmF0dWl0b3VzIHdhc3RlIG9mIGJhbmR3aWR0aC48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+W0JBXSAmIzQzOzEuICZuYnNwOyBU aGVyZSBpcyBkZWZpbml0ZWx5IGFuIGV4cGVjdGF0aW9uIG9uIHRoZSBwYXJ0IG9mIGRldmVsb3Bl cnMgdGhhdCBXZWJSVEMgd2lsbCBiZWhhdmUgbGlrZSB0aGUgJnF1b3Q7bGVnYWN5JnF1b3Q7IFNE UCB0aGV5IGFyZSB1c2VkIHRvIC0gZXZlbiBpZiB0aGV5IGFyZSBub3QgaW50ZXJvcGVyYXRpbmcN CiB3aXRoIGxlZ2FjeSBhcHBsaWNhdGlvbnMuJm5ic3A7IFNpbmNlIHRob3NlIGFwcGxpY2F0aW9u cyB3b3JrZWQgd2l0aG91dCBNSURzLCBkZXZlbG9wZXJzIHdpbGwgZXhwZWN0IHRoZW0gdG8gY29u dGludWUgdG8gd29yayB3aGVuIE1JRCBzdXBwb3J0IGlzIGludHJvZHVjZWQgaW4gZnV0dXJlLiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pkkgc2VlbiBsb3RzIG9mIHByb2plY3RzIHNoaXAgdGhpcyBhbmQgd29yayBmaW5lLiBUaGUgYWxn b3JpdGhtIGluIGFwcGVuZGl4IEINCiBtYWtlIGl0IGNsZWFyIFBUIGFyZSBvbmx5IHVzZWQgaWYg dGhleSBhcmUgdW5pcXVlIGFjcm9zcyBhbGwgdGhlIG0tbGluZXMuIFNvIGNsZWFybHkgaXQgY2Fu IG5vdCBiZSB1c2VkIGlmIHlvdSBuZWVkIG1vcmUgUFQgdGhhbiBhcmUgYXZhaWxhYmxlIGluIHRo ZSBQVCBzcGFjZS4gQSBodWdlIHBlcmNlbnRhZ2Ugb2Ygb2YgcmVhbCB3b3JsZCB1c2UgY2FzZXMg Zm9yIFNEUCBlYXNpbHkgZml0IGluc2lkZSB0aGUgY3VycmVudCBQVCBzcGFjZS4mcXVvdDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5bQkFdICYjNDM7MS4m bmJzcDsgTXkgZXhwZXJpZW5jZSBpcyB0aGF0ICptb3N0KiBvZiB0aGUgZGV2ZWxvcGVycyBzaGlw cGluZyBXZWJSVEMgYXBwbGljYXRpb25zIHRoYXQgcnVuIG9uIG11bHRpcGxlIGJyb3dzZXJzIGFy ZSB1c2luZyBQVC1iYXNlZCByb3V0aW5nLCBzbyB0aGV5J2QgYmUgdmVyeQ0KIHN1cnByaXNlZCB0 byBsZWFybiB0aGF0IGl0IGlzbid0IHN1cHBvcnRlZCAoYW5kIHRoZXkgd291bGQgcHJvYmFibHkg cHVzaCBiYWNrIHZpZ29yb3VzbHkgYXQgc3VjaCBhIG5vdGlvbikuJm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+JnF1b3Q7QW55d2F5cywgSSdtIGp1 c3Qgbm90IHNlZWluZyB3aGF0IHlvdSB0aGluayB0aGUgcHJvYmxlbSBpcyBoZXJlLiBJIGRvbid0 IHNlZSBhIHByb2JsZW0gc28gSSBmZWVsIHByZXR0eSBzdHJvbmdseSB0aGF0IHRoZSBhbGdvcml0 aG0gaW4gQXBwZW5kaXggQiBpcyBmaW5lLiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPltCQV0gVGhlIGFsZ29yaXRobSBpbiBBcHBlbmRpeCBCIGlu Y2x1ZGVzIFBUIHJvdXRpbmcgYW5kIEknZCBsaWtlIGl0IHRvIGNvbnRpbnVlIHRvIGNvdmVyIHRo YXQuJm5ic3A7IFRoZSBhbGdvcml0aG0gYXBwZWFycyB0byByZXNvbHZlIGEgbnVtYmVyIG9mIGJ1 Z3MgZmlsZWQgYnkgYm90aA0KIFdlYlJUQyBhbmQgT1JUQyBkZXZlbG9wZXJzLiBJdCB3aWxsIHRh a2UgYSBiaXQgbW9yZSByZXZpZXcgdG8gY29uZmlybSB0aGF0IGl0IGRvZXNuJ3QgY2F1c2UgYW55 IHJlZ3Jlc3Npb25zLiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5PbiBXZWQsIEphbiAxOCwgMjAxNyBhdCA2OjUyIEFNLCBDdWxsZW4gSmVubmlu Z3MgJmx0OzxhIGhyZWY9Im1haWx0bzpmbHVmZnlAaWlpLmNhIiB0YXJnZXQ9Il9ibGFuayI+Zmx1 ZmZ5QGlpaS5jYTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxi cj4NCiZndDsgT24gSmFuIDE4LCAyMDE3LCBhdCAzOjAxIEFNLCBNYWdudXMgV2VzdGVybHVuZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRpbmcgUFQgYmFzZWQgcm91dGluZzo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBSVENXZWIgcmVxdWlyZXMgQlVORExFLCBCVU5ETEUgcmVxdWly ZXMgTUlEcywgdGh1cyBQVCBiYXNlZCByb3V0aW5nIG9mIHBhY2tldHMgYXJlIG5vdCByZXF1aXJl ZCBmb3IgYW55IFdlYlJUQyBlbmRwb2ludC48YnI+DQo8YnI+DQpMb29rLCBJIGRvbid0IHNlZSBp dCB0aGlzIHdheSBhbmQgSSBzdXNwZWN0IHlvdSBhcmUgZ29pbmcgdG8gYWdyZWUgd2l0aCB3aGF0 IEkgc2F5IG5leHQuLi4uIFdlYlJUQyBicm93c2VycyBhcmUgcmVxdWlyZWQgdG8gaW50ZXJvcGVy YXRlIHdpdGggJnF1b3Q7bGVnYWN5JnF1b3Q7IHRoaW5ncyB0aGF0IGRvbid0IGRvIGJ1bmRsZSBh bmQgdGhpbmdzIHRoYXQgbWF5IGRvIGJ1bmRsZSBidXQgdHJ5IG5vdCB0byB1c2UgTUlEcyBpbiBj YXNlcyB3aGVyZSB0aGV5IGFyZQ0KIGEgZ3JhdHVpdG91cyB3YXN0ZSBvZiBiYW5kd2lkdGguPGJy Pg0KPGJyPg0KJmd0OyBQVCBiYXNlZCByb3V0aW5nIHdvcmtzIG9ubHkgaW4gc29tZSBjb25zdHJh aW5lZCB1c2FnZXMsIHRodXMgbXkgdmlldyBpcyB0aGF0IGl0IG5lZWRzIHRvIHJlbWFpbiBhIGhp bnQsIGFuZCBhbiBvcHRpb25hbCBoaW50IGF0IG1vc3QuPGJyPg0KJmd0OyBJdCBtdXN0IGJlIGNs ZWFyIHRoYXQgaXQgaXMgbm90IHNvbWV0aGluZyB0aGF0IGlzIHJlbGlhYmxlLjxicj4NCjxicj4N CllvdSBrZWVwIGFzc2VydGluZyB0aGlzIGJ1dCBJJ20gbm90IGNvbnZpbmNlZCB5b3UgYXJlIGFy ZSBjb3JyZWN0IHNvIHBlcmhhcHMgeW91IGNvdWxkIGV4cGxhaW4gdGhlIHdoZXJlIHRoZXkgZG9u J3Qgd29yay4gSSBzZWVuIGxvdHMgb2YgcHJvamVjdHMgc2hpcCB0aGlzIGFuZCB3b3JrIGZpbmUu IFRoZSBhbGdvcml0aG0gaW4gYXBwZW5kaXggQiBtYWtlIGl0IGNsZWFyIFBUIGFyZSBvbmx5IHVz ZWQgaWYgdGhleSBhcmUgdW5pcXVlIGFjcm9zcyBhbGwNCiB0aGUgbS1saW5lcy4gU28gY2xlYXJs eSBpdCBjYW4gbm90IGJlIHVzZWQgaWYgeW91IG5lZWQgbW9yZSBQVCB0aGFuIGFyZSBhdmFpbGFi bGUgaW4gdGhlIFBUIHNwYWNlLiBBIGh1Z2UgcGVyY2VudGFnZSBvZiBvZiByZWFsIHdvcmxkIHVz ZSBjYXNlcyBmb3IgU0RQIGVhc2lseSBmaXQgaW5zaWRlIHRoZSBjdXJyZW50IFBUIHNwYWNlLiBP bmUgb2YgdGhlIGNhc2VzIEkgY2FyZSBhYm91dCBpZiBhIGxvdyBwZWFrIGJhbmR3aWR0aCBwaG9u ZSAobm90DQogYXZlcmFnZSkgZm9yIHBsYWNlcyBsaWtlIHBhcnRzIG9mIEFmcmljYSB0aGF0IHVz ZXMgYSA3MDAgYnBzIGNvZGVjLiBNb3N0IHNpbmdsZSBzdHJlYW0gb2YgYXVkaW8gYW5kIHZpZGVv ICZxdW90O3ZpZGVvIHBob25lIGNhbGwmcXVvdDsgdHlwZSBjYXNlcyBhbHNvIGVhc2lseSB3b3Jr LiBZZXMsIEkgdW5kZXJzdGFuZCBvbmUgY291bGQgY29uc3RydWN0IHNvbWUgc2luZ2xlIGF1ZGlv L3ZpZGVvIHdoZXJlIGVub3VnaCB0aGluZ3Mgd2VyZSB0aGUgU0RQIG9mZmVyIG5lZWRzDQogbW9y ZSBQVHMgdGhhbiB0aGVyZSB3YXMgc3BhY2UgZm9yIGJ1dCBpZiB5b3UgbG9vayBhdCB0aGUgU0RQ IGZyb20ganVzdCBhYm91dCBldmVyeSBtYWpvciBtYW51ZmFjdHVyZSBvZiBWb0lQIGF1ZGlvIHBo b25lcywgeW91IHNlZSB3aGF0IHRoZXkgYXJlIGN1cnJlbnRseSBkb2luZyBjYW4gZWFzaWx5IGJl IGRvbmUgd2l0aCB1bmlxdWUgUFQgdmFsdWVzLiBBbnl3YXksIGZvciB0aGVzZTxicj4NCiZuYnNw OyBjYXNlIHdoZXJlIHlvdSBkb24ndCBydW4gb3V0IG9mIFBULCBwbGVhc2UgcGxlYXNlIGV4cGxh aW4gd2h5IFBUIHJvdXRpbmcgaXMgc28gYnJva2VuIHRoYXQgaXMgc2hvdWxkIGJlIGFuIG9wdGlv bmFsIGhpbnQuIEluIHByYWN0aWNlIGl0IHNlZW1zIHRvIHdvcmsgZmluZS48YnI+DQo8YnI+DQpB bnl3YXlzLCBJJ20ganVzdCBub3Qgc2VlaW5nIHdoYXQgeW91IHRoaW5rIHRoZSBwcm9ibGVtIGlz IGhlcmUuIEkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSBzbyBJIGZlZWwgcHJldHR5IHN0cm9uZ2x5IHRo YXQgdGhlIGFsZ29yaXRobSBpbiBBcHBlbmRpeCBCIGlzIGZpbmUuIENvbnZpbmNlIG1lIG9uIHdo eSBpcyAmcXVvdDtub3QgcmVsaWFibGUmcXVvdDsgYW5kIGFuZCAmcXVvdDtvbmx5IGluIHNvbWUg Y29uc3RyYWluZWQgdXNhZ2VzJnF1b3Q7PGJyPg0KPGJyPg0KJmd0OyBJIGFsc28gc3RydWdnbGUg dG8gc2VlIGluIHdoYXQgbm9uLVdlYlJUQyBpbnRlcm9wIHVzZSBjYXNlcyB0aGlzIGFyaXNlcy4g VGhlIG5vbi1XZWJSVEMgZW5kcG9pbnQgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBtdWx0aSBtZWRp YSBzb3VyY2UsIGFuZCBtdWx0aSBzdHJlYW0gKFNTUkMpIFJUUCBzZXNzaW9ucywgYnV0IG5vdCBp bXBsZW1lbnQgQlVORExFLiBPciBpcyBpdCBhIGFnZ3JlZ2F0aW5nIGdhdGV3YXksIHRoYXQgaXMg dG8gbGF6eSB0bw0KIGFkZCBNSURzPzxicj4NCiZndDs8YnI+DQo8YnI+DQo8YnI+DQpQZW9wbGUg d2FudCB0byBhdm9pZCB0aGUgbWVkaWEgZ2F0ZXdheSBiZXR3ZWVuIFdlYlJUQyBhbmQgYW5kIGFu IFNJUCBlbmRwb2ludCB3aGVyZSB0aGV5IGNhbi4gVGhlIG1lZGlhIGdhdGV3YXkgYWRkcyBsYXRl bmN5IC0gaHVnZSBhbW91bnRzIGluIHRoZSBjYXNlIHdoZXJlIGJvdGggZW5kcG9pbnRzIHJlcXVp cmUgYSBzYXRlbGxpdGUgaG9wIHRvIGdldCB0byB0aGUgZ2F0ZXdheSAtIGFuZCBpdCBhZGQgdGhl IGJhbmR3aWR0aCBleHBlbnNlcyBvZg0KIHJ1bm5pbmcgZ2F0ZXdheS48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQpPbiBhbGwgb2YgdGhpcywgSSB3YW50IHRvIGJlIGNsZWFyLCBmb3IgcGVvcGxlIHRo YXQgd2FudCB0byBkbyBzb21ldGhpbmcgd2hlcmUgdGhlIFBUIHNwYWNlIGlzIG5vdCBsYXJnZSBl bm91Z2gsIG9idmlvdXNseSB0aGV5IGNhbiB1c2UgTUlELCBJJ20ganVzdCBzYXlpbmcgdGhhdCBm b3IgdGhpbmdzIHRoYXQgZG9uJ3QgdXNlIE1JRCwgYW5kIGNhbiBmaXQgaW4gdGhlIFBUIHNwYWNl LCBpdCBzaG91bGQgYmUgYW4gb3B0aW9uIHRvIHVzZSBQVCBhbmQNCiBrbm93IGl0IHdpbGwgd29y ay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRj d2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BF941B1ESESSMB209erics_-- From nobody Sat Jan 21 09:31:46 2017 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 11624129B47 for ; Sat, 21 Jan 2017 09:31:45 -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=ham 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 32v6i7PNkIQZ for ; Sat, 21 Jan 2017 09:31:43 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 D6B9F129AD5 for ; Sat, 21 Jan 2017 09:31:42 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id w75so113887072ywg.1 for ; Sat, 21 Jan 2017 09:31:42 -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=WrzG2GIzfZ41ymmub3VGlh67FZo/3m+QHUntNlEYOrs=; b=tdgjTUSPHKo+UKDQUxBQ+jjpC25GKHTsLEvm2tY78sj4Lkwe3rynN1bE/I8d4WikB8 vrAxUVDVSz1ExdV9LYrS81bnUEBd4SQ2GvfiEYfiSCgVF6rDfcIbO7bKpH5L8JM+eOwI 4C5lNZ31KMzS3uauZLcQEONUWflpY6qUcVixNLLq0t7La5YV+MYlk880SJIhNL4K42mN 1FkbgOiV37kvcBygBS/nx6eAnZCFid0/uZC//L+2GxzE2bksHb1f2Cy1I0Yx5+dhNzAi MW8eJAD3QfpQR5XY8q7/qeKvks+AGA/A/Gx9mAu8DmeiD+PmQcDvABStCtyL60zWPAh/ Z40Q== 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=WrzG2GIzfZ41ymmub3VGlh67FZo/3m+QHUntNlEYOrs=; b=rSJQ0z4qn5bPBU52zm/XcBsPLNAAOWqJYzZinLEwKXXnbvp/WQojbV4rwxjKNky/Iq xJRljUcvoO0a0FD11Lg2pJOI9b8RbwZWofy+cmoJz/z+DtNjEIo0lPFAFVYm16q5EySb cHJMRWAW1sHFjEc8dSnZfoAHh6K/OqRp3K8Et6zjuGVdGtDCR8JjLDmbPtyDNVTpezxU aNd5mh3M2ZyPQWlTM8NB+JDYj6XqBZbkdeUJOkAn0URX+twivuB6/6kGF5AZ6KjVVwkT 4ZsUBYPqzW++ZsOKCo7QuHuT2UgjJvb8I394Dv92I4EQ6Cyi6aFhmPZC7TuAMiEF+M+H s65Q== X-Gm-Message-State: AIkVDXLsArpNwIC2SJCywaEXbMMXC7Rw/yTtSoNBdvQWf47ybyNRkwFyfHLrHgOfIFv1LSnxPt1x3eG3P73YJg== X-Received: by 10.13.250.3 with SMTP id k3mr18210014ywf.276.1485019902103; Sat, 21 Jan 2017 09:31:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Sat, 21 Jan 2017 09:31:01 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF941B1@ESESSMB209.ericsson.se> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF941B1@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Sat, 21 Jan 2017 09:31:01 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c07f76cc0075505469e236d Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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: Sat, 21 Jan 2017 17:31:45 -0000 --94eb2c07f76cc0075505469e236d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I agree. And I think that's what appendix B currently says. -Ekr On Sat, Jan 21, 2017 at 5:32 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >It's not big enough for every use case but it's in use for certain > limited use cases >now. Hence the need to support PT now and MID in the > future > > > > In that case there should be a clear rule saying that, if the PTs are > unique, they can be used. No =E2=80=9Chints=E2=80=9D :) > > > > Regards, > > > > Christer > > > > > > > > On Fri, Jan 20, 2017 at 3:33 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi, > > > > If things work fine using PT, why do we mandate MID in the first place? > Why would people implement MID in the future if PT works? > > > > Unless I remember wrong, Adam is the one who said that the PT space is no= t > big enough, and that we therefor need something else =E2=80=93 which made= us > mandate SSRC, specify the tools for MID transport, etc. > > > > Also, I am not sure what is meant by a =E2=80=9Chint=E2=80=9D. If there a= re applications > that don=E2=80=99t support MID, and need to use PT, then it has to be mor= e than a > =E2=80=9Chint=E2=80=9D. It must be a testable rule. > > > > Regards, > > > > Christer > > > > > > > > > > > > *From: *rtcweb on behalf of Bernard Aboba < > bernard.aboba@gmail.com> > *Date: *Wednesday 18 January 2017 at 19:34 > *To: *Cullen Jennings > *Cc: *"rtcweb@ietf.org" > *Subject: *Re: [rtcweb] Working group last call resolutions/Consensus > call: Appendix B > > > > Cullen said: > > > > "Look, I don't see it this way and I suspect you are going to agree with > what I say next.... WebRTC browsers are required to interoperate with > "legacy" things that don't do bundle and things that may do bundle but tr= y > not to use MIDs in cases where they are a gratuitous waste of bandwidth." > > > > [BA] +1. There is definitely an expectation on the part of developers > that WebRTC will behave like the "legacy" SDP they are used to - even if > they are not interoperating with legacy applications. Since those > applications worked without MIDs, developers will expect them to continue > to work when MID support is introduced in future. > > > > "I seen lots of projects ship this and work fine. The algorithm in > appendix B make it clear PT are only used if they are unique across all t= he > m-lines. So clearly it can not be used if you need more PT than are > available in the PT space. A huge percentage of of real world use cases f= or > SDP easily fit inside the current PT space." > > > > [BA] +1. My experience is that *most* of the developers shipping WebRTC > applications that run on multiple browsers are using PT-based routing, so > they'd be very surprised to learn that it isn't supported (and they would > probably push back vigorously at such a notion). > > > > "Anyways, I'm just not seeing what you think the problem is here. I don't > see a problem so I feel pretty strongly that the algorithm in Appendix B = is > fine." > > > > [BA] The algorithm in Appendix B includes PT routing and I'd like it to > continue to cover that. The algorithm appears to resolve a number of bug= s > filed by both WebRTC and ORTC developers. It will take a bit more review = to > confirm that it doesn't cause any regressions. > > > > On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings wrote: > > > > On Jan 18, 2017, at 3:01 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > > > > > Regarding PT based routing: > > > > RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of > packets are not required for any WebRTC endpoint. > > Look, I don't see it this way and I suspect you are going to agree with > what I say next.... WebRTC browsers are required to interoperate with > "legacy" things that don't do bundle and things that may do bundle but tr= y > not to use MIDs in cases where they are a gratuitous waste of bandwidth. > > > PT based routing works only in some constrained usages, thus my view is > that it needs to remain a hint, and an optional hint at most. > > It must be clear that it is not something that is reliable. > > You keep asserting this but I'm not convinced you are are correct so > perhaps you could explain the where they don't work. I seen lots of > projects ship this and work fine. The algorithm in appendix B make it cle= ar > PT are only used if they are unique across all the m-lines. So clearly it > can not be used if you need more PT than are available in the PT space. A > huge percentage of of real world use cases for SDP easily fit inside the > current PT space. One of the cases I care about if a low peak bandwidth > phone (not average) for places like parts of Africa that uses a 700 bps > codec. Most single stream of audio and video "video phone call" type case= s > also easily work. Yes, I understand one could construct some single > audio/video where enough things were the SDP offer needs more PTs than > there was space for but if you look at the SDP from just about every majo= r > manufacture of VoIP audio phones, you see what they are currently doing c= an > easily be done with unique PT values. Anyway, for these > case where you don't run out of PT, please please explain why PT routin= g > is so broken that is should be an optional hint. In practice it seems to > work fine. > > Anyways, I'm just not seeing what you think the problem is here. I don't > see a problem so I feel pretty strongly that the algorithm in Appendix B = is > fine. Convince me on why is "not reliable" and and "only in some > constrained usages" > > > I also struggle to see in what non-WebRTC interop use cases this arises= . > The non-WebRTC endpoint needs to be capable of multi media source, and > multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a > aggregating gateway, that is to lazy to add MIDs? > > > > > People want to avoid the media gateway between WebRTC and and an SIP > endpoint where they can. The media gateway adds latency - huge amounts in > the case where both endpoints require a satellite hop to get to the gatew= ay > - and it add the bandwidth expenses of running gateway. > > > > On all of this, I want to be clear, for people that want to do something > where the PT space is not large enough, obviously they can use MID, I'm > just saying that for things that don't use MID, and can fit in the PT > space, it should be an option to use PT and know it will work. > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --94eb2c07f76cc0075505469e236d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I agree. And I think that's what appendix B curre= ntly says.

-Ekr


On Sat, Jan 21, 2017 at 5:32 AM= , Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>It's no= t big enough for every use case but it's in use for certain limited use= cases >now. Hence the need to support PT = now and MID in the future

=C2=A0

In that case there should be a clear = rule saying that, if the PTs are unique, they can be used. No =E2=80=9Chint= s=E2=80=9D :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 20, 2017 at 3:33 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

=C2=A0

Hi,

=C2=A0

If things work fine using PT, why do we= mandate MID in the first place? Why would people implement MID in the futu= re if PT works?

=C2=A0

Unless I remember wrong, Adam is the on= e who said that the PT space is not big enough, and that we therefor need s= omething else =E2=80=93 which made us mandate SSRC, specify the tools for MID transport, etc.

=C2=A0

Also, I am not sure what is meant by a = =E2=80=9Chint=E2=80=9D. If there are applications that don=E2=80=99t suppor= t MID, and need to use PT, then it has to be more than a =E2=80=9Chint=E2= =80=9D. It must be a testable rule.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Bernard A= boba <berna= rd.aboba@gmail.com>
Date: Wednesday 18 January 2017 at 19:34
To: Cullen Jennings <fluffy@iii.ca>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working group last call resolutions/Consensus = call: Appendix B

=C2=A0

Cullen said:=C2=A0

=C2=A0

"Look, I don= 9;t see it this way and I suspect you are going to agree with what I say next.... WebRTC browsers are required to interoperate with "leg= acy" things that don't do bundle and things that may do bundle but= try not to use MIDs in cases where they are a gratuitous waste of bandwidt= h."

=C2=A0

[BA] +1. =C2=A0 There is definitely an = expectation on the part of developers that WebRTC will behave like the &quo= t;legacy" SDP they are used to - even if they are not interoperating with legacy applications.=C2=A0 Since those applications worked without MI= Ds, developers will expect them to continue to work when MID support is int= roduced in future.=C2=A0

=C2=A0

"I seen lots of= projects ship this and work fine. The algorithm in appendix B make it clear PT are only used if they are unique across all the m-lines. = So clearly it can not be used if you need more PT than are available in the= PT space. A huge percentage of of real world use cases for SDP easily fit = inside the current PT space."=

=C2=A0

[BA] +1.=C2=A0 My experience is that *mo= st* of the developers shipping WebRTC applications that run on multiple bro= wsers are using PT-based routing, so they'd be very surprised to learn that it isn't supported (and they would probably pu= sh back vigorously at such a notion).=C2=A0

=C2=A0

"Anyways, I'm just not seeing w= hat you think the problem is here. I don't see a problem so I feel pret= ty strongly that the algorithm in Appendix B is fine."

=C2=A0

[BA] The algorithm in Appendix B include= s PT routing and I'd like it to continue to cover that.=C2=A0 The algor= ithm appears to resolve a number of bugs filed by both WebRTC and ORTC developers. It will take a bit more review to confirm that= it doesn't cause any regressions.=C2=A0<= /u>

=C2=A0

On Wed, Jan 18, 2017 at 6:52 AM, Cullen= Jennings <fluffy@iii= .ca> wrote:


> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund <magnus.westerlund@ericsson= .com> wrote:
>
>
> Regarding PT based routing:
>
> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of= packets are not required for any WebRTC endpoint.

Look, I don't see it this way and I suspect you are going to agree with= what I say next.... WebRTC browsers are required to interoperate with &quo= t;legacy" things that don't do bundle and things that may do bundl= e but try not to use MIDs in cases where they are a gratuitous waste of bandwidth.

> PT based routing works only in some constrained usages, thus my view i= s that it needs to remain a hint, and an optional hint at most.
> It must be clear that it is not something that is reliable.

You keep asserting this but I'm not convinced you are are correct so pe= rhaps you could explain the where they don't work. I seen lots of proje= cts ship this and work fine. The algorithm in appendix B make it clear PT a= re only used if they are unique across all the m-lines. So clearly it can not be used if you need more PT than are av= ailable in the PT space. A huge percentage of of real world use cases for S= DP easily fit inside the current PT space. One of the cases I care about if= a low peak bandwidth phone (not average) for places like parts of Africa that uses a 700 bps codec. Most s= ingle stream of audio and video "video phone call" type cases als= o easily work. Yes, I understand one could construct some single audio/vide= o where enough things were the SDP offer needs more PTs than there was space for but if you look at the SDP from just abo= ut every major manufacture of VoIP audio phones, you see what they are curr= ently doing can easily be done with unique PT values. Anyway, for these
=C2=A0 case where you don't run out of PT, please please explain why PT= routing is so broken that is should be an optional hint. In practice it se= ems to work fine.

Anyways, I'm just not seeing what you think the problem is here. I don&= #39;t see a problem so I feel pretty strongly that the algorithm in Appendi= x B is fine. Convince me on why is "not reliable" and and "o= nly in some constrained usages"

> I also struggle to see in what non-WebRTC interop use cases this arise= s. The non-WebRTC endpoint needs to be capable of multi media source, and m= ulti stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggre= gating gateway, that is to lazy to add MIDs?
>


People want to avoid the media gateway between WebRTC and and an SIP endpoi= nt where they can. The media gateway adds latency - huge amounts in the cas= e where both endpoints require a satellite hop to get to the gateway - and = it add the bandwidth expenses of running gateway.



On all of this, I want to be clear, for people that want to do something wh= ere the PT space is not large enough, obviously they can use MID, I'm j= ust saying that for things that don't use MID, and can fit in the PT sp= ace, it should be an option to use PT and know it will work.







_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb<= /p>

=C2=A0


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

=C2=A0


--94eb2c07f76cc0075505469e236d-- From nobody Sat Jan 21 11:54:00 2017 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 62485129C50 for ; Sat, 21 Jan 2017 11:53:57 -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 2oBBNE0DuwAV for ; Sat, 21 Jan 2017 11:53:55 -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 48FBA129C4D for ; Sat, 21 Jan 2017 11:53:54 -0800 (PST) X-AuditID: c1b4fb3a-d001d98000007c71-6a-5883bc50efb3 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 1E.40.31857.D4CB3885; Sat, 21 Jan 2017 20:53:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Sat, 21 Jan 2017 20:46:56 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [rtcweb] Working group last call resolutions/Consensus call: Appendix B Thread-Index: AQHScXHRfPdpg2TYPU+10qpCTZWsc6E+QWwAgAAtEICAAuHCgIAAkq+AgAEPWQCAADJXgIAANdKg Date: Sat, 21 Jan 2017 19:46:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF997A1@ESESSMB209.ericsson.se> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF941B1@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BF997A1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7tG7AnuYIgwU7lCw27PvPbLHi9Tl2 iw/rfzBarP3Xzu7A4rFz1l12jyVLfjJ5XD7/kdFj8uM25gCWKC6blNSczLLUIn27BK6MGbd3 shTsOMRU0fjgD2MDY8Mupi5GTg4JAROJ4/8XsXYxcnEICaxjlPi5/xwbSEJIYDGQ02HTxcjB wSZgIdH9TxskLCKgIPHrzwkWkDCzQK7EjIOOIGFhgTCJd//+gIVFBMIlFi5XgTCjJI59VQUx WQRUJV58sgAp5hXwlfjx6QYzxM5GFompFzcxgiQ4BQIlps7fBbafUUBM4vupNWBHMguIS9x6 Mh/qYAGJJXvOM0PYohIvH/9jhbCVJFZsv8QIUZ8vsfbkZUaIZYISJ2c+YZnAKDILyahZSMpm ISmbBfaXpsT6XfoQJYoSU7ofskPYGhKtc+ayI4svYGRfxShanFpcnJtuZKSXWpSZXFycn6eX l1qyiREYeQe3/LbawXjwueMhRgEORiUeXoO4pggh1sSy4srcQ4wSHMxKIrx2W5sjhHhTEiur Uovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamAU8LHVVHT1vr7UX853 56OTCYLpbyVtHOR22cu8uHptfxWz1QH/MK0JudUP5Pc/vnQvIiTpmPLVYsE9ekvWpt/lt6l+ +1n27JupX8OuTlfXK9rsumlZ9qcdwZ6MepO7jwsUHXZxKE65r3pJaXH+jK2ff1pVu7JdDi+q mcS0aFXNi4KmxbMn8mkqsRRnJBpqMRcVJwIAZ8/Yu7gCAAA= Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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: Sat, 21 Jan 2017 19:53:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BF997A1ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5ZZXMsIEkgYWdyZWUuIEFuZCBJIHRoaW5rIHRoYXQncyB3aGF0IGFwcGVuZGl4IEIg Y3VycmVudGx5IHNheXMuDQoNCk15IGNvbW1lbnQgd2FzIG1vcmUgb24gd2hhdCBoYXMgYmVlbiBk aXNjdXNzZWQgb24gdGhpcyBsaXN0Lg0KDQpSZWdhcmRpbmcgQXBwZW5kaXggQiBpbiBnZW5lcmFs OiBpZiB0aGUgaWRlYSBpcyB0byBldmVudHVhbGx5IHBsYWNlIHRoZSB0ZXh0IGluIGRyYWZ0LWJ1 bmRsZSwgSSB0aGluayB3ZSBzaG91bGQgbW92ZSBpdCB0aGVyZSBCRUZPUkUgdGhlIHB1YmxpY2F0 aW9uIHJlcXVlc3QgZm9yIGRyYWZ0LWpzZXAgaXMgZG9uZS4gSSBzZWUgbm8gcmVhc29uIHRvIGhh dmUgdGhlIHRleHQgaW4gdHdvIHBsYWNlcy4gUGVyaGFwcyB0aGF04oCZcyB0aGUgaW50ZW50aW9u LCBidXQgaXTigJlzIG5vdCBjbGVhciB3aGVuIHJlYWRpbmcgdGhlIGRyYWZ04oCmDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpPbiBTYXQsIEphbiAyMSwgMjAxNyBhdCA1OjMyIEFNLCBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQo+SXQncyBub3Qg YmlnIGVub3VnaCBmb3IgZXZlcnkgdXNlIGNhc2UgYnV0IGl0J3MgaW4gdXNlIGZvciBjZXJ0YWlu IGxpbWl0ZWQgdXNlIGNhc2VzID5ub3cuIEhlbmNlIHRoZSBuZWVkIHRvIHN1cHBvcnQgUFQgbm93 IGFuZCBNSUQgaW4gdGhlIGZ1dHVyZQ0KDQpJbiB0aGF0IGNhc2UgdGhlcmUgc2hvdWxkIGJlIGEg Y2xlYXIgcnVsZSBzYXlpbmcgdGhhdCwgaWYgdGhlIFBUcyBhcmUgdW5pcXVlLCB0aGV5IGNhbiBi ZSB1c2VkLiBObyDigJxoaW50c+KAnSA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0K T24gRnJpLCBKYW4gMjAsIDIwMTcgYXQgMzozMyBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpJZiB0aGluZ3Mgd29yayBmaW5lIHVzaW5nIFBULCB3 aHkgZG8gd2UgbWFuZGF0ZSBNSUQgaW4gdGhlIGZpcnN0IHBsYWNlPyBXaHkgd291bGQgcGVvcGxl IGltcGxlbWVudCBNSUQgaW4gdGhlIGZ1dHVyZSBpZiBQVCB3b3Jrcz8NCg0KVW5sZXNzIEkgcmVt ZW1iZXIgd3JvbmcsIEFkYW0gaXMgdGhlIG9uZSB3aG8gc2FpZCB0aGF0IHRoZSBQVCBzcGFjZSBp cyBub3QgYmlnIGVub3VnaCwgYW5kIHRoYXQgd2UgdGhlcmVmb3IgbmVlZCBzb21ldGhpbmcgZWxz ZSDigJMgd2hpY2ggbWFkZSB1cyBtYW5kYXRlIFNTUkMsIHNwZWNpZnkgdGhlIHRvb2xzIGZvciBN SUQgdHJhbnNwb3J0LCBldGMuDQoNCkFsc28sIEkgYW0gbm90IHN1cmUgd2hhdCBpcyBtZWFudCBi eSBhIOKAnGhpbnTigJ0uIElmIHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhhdCBkb27igJl0IHN1 cHBvcnQgTUlELCBhbmQgbmVlZCB0byB1c2UgUFQsIHRoZW4gaXQgaGFzIHRvIGJlIG1vcmUgdGhh biBhIOKAnGhpbnTigJ0uIEl0IG11c3QgYmUgYSB0ZXN0YWJsZSBydWxlLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQoNCg0KDQoNCkZyb206IHJ0Y3dlYiA8cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEJlcm5hcmQg QWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWls LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXkgMTggSmFudWFyeSAyMDE3IGF0IDE5OjM0DQpUbzogQ3Vs bGVuIEplbm5pbmdzIDxmbHVmZnlAaWlpLmNhPG1haWx0bzpmbHVmZnlAaWlpLmNhPj4NCkNjOiAi cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+IiA8cnRjd2ViQGlldGYub3Jn PG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIHJlc29sdXRpb25zL0NvbnNlbnN1cyBjYWxsOiBBcHBlbmRpeCBCDQoN CkN1bGxlbiBzYWlkOg0KDQoiTG9vaywgSSBkb24ndCBzZWUgaXQgdGhpcyB3YXkgYW5kIEkgc3Vz cGVjdCB5b3UgYXJlIGdvaW5nIHRvIGFncmVlIHdpdGggd2hhdCBJIHNheSBuZXh0Li4uLiBXZWJS VEMgYnJvd3NlcnMgYXJlIHJlcXVpcmVkIHRvIGludGVyb3BlcmF0ZSB3aXRoICJsZWdhY3kiIHRo aW5ncyB0aGF0IGRvbid0IGRvIGJ1bmRsZSBhbmQgdGhpbmdzIHRoYXQgbWF5IGRvIGJ1bmRsZSBi dXQgdHJ5IG5vdCB0byB1c2UgTUlEcyBpbiBjYXNlcyB3aGVyZSB0aGV5IGFyZSBhIGdyYXR1aXRv dXMgd2FzdGUgb2YgYmFuZHdpZHRoLiINCg0KW0JBXSArMS4gICBUaGVyZSBpcyBkZWZpbml0ZWx5 IGFuIGV4cGVjdGF0aW9uIG9uIHRoZSBwYXJ0IG9mIGRldmVsb3BlcnMgdGhhdCBXZWJSVEMgd2ls bCBiZWhhdmUgbGlrZSB0aGUgImxlZ2FjeSIgU0RQIHRoZXkgYXJlIHVzZWQgdG8gLSBldmVuIGlm IHRoZXkgYXJlIG5vdCBpbnRlcm9wZXJhdGluZyB3aXRoIGxlZ2FjeSBhcHBsaWNhdGlvbnMuICBT aW5jZSB0aG9zZSBhcHBsaWNhdGlvbnMgd29ya2VkIHdpdGhvdXQgTUlEcywgZGV2ZWxvcGVycyB3 aWxsIGV4cGVjdCB0aGVtIHRvIGNvbnRpbnVlIHRvIHdvcmsgd2hlbiBNSUQgc3VwcG9ydCBpcyBp bnRyb2R1Y2VkIGluIGZ1dHVyZS4NCg0KIkkgc2VlbiBsb3RzIG9mIHByb2plY3RzIHNoaXAgdGhp cyBhbmQgd29yayBmaW5lLiBUaGUgYWxnb3JpdGhtIGluIGFwcGVuZGl4IEIgbWFrZSBpdCBjbGVh ciBQVCBhcmUgb25seSB1c2VkIGlmIHRoZXkgYXJlIHVuaXF1ZSBhY3Jvc3MgYWxsIHRoZSBtLWxp bmVzLiBTbyBjbGVhcmx5IGl0IGNhbiBub3QgYmUgdXNlZCBpZiB5b3UgbmVlZCBtb3JlIFBUIHRo YW4gYXJlIGF2YWlsYWJsZSBpbiB0aGUgUFQgc3BhY2UuIEEgaHVnZSBwZXJjZW50YWdlIG9mIG9m IHJlYWwgd29ybGQgdXNlIGNhc2VzIGZvciBTRFAgZWFzaWx5IGZpdCBpbnNpZGUgdGhlIGN1cnJl bnQgUFQgc3BhY2UuIg0KDQpbQkFdICsxLiAgTXkgZXhwZXJpZW5jZSBpcyB0aGF0ICptb3N0KiBv ZiB0aGUgZGV2ZWxvcGVycyBzaGlwcGluZyBXZWJSVEMgYXBwbGljYXRpb25zIHRoYXQgcnVuIG9u IG11bHRpcGxlIGJyb3dzZXJzIGFyZSB1c2luZyBQVC1iYXNlZCByb3V0aW5nLCBzbyB0aGV5J2Qg YmUgdmVyeSBzdXJwcmlzZWQgdG8gbGVhcm4gdGhhdCBpdCBpc24ndCBzdXBwb3J0ZWQgKGFuZCB0 aGV5IHdvdWxkIHByb2JhYmx5IHB1c2ggYmFjayB2aWdvcm91c2x5IGF0IHN1Y2ggYSBub3Rpb24p Lg0KDQoiQW55d2F5cywgSSdtIGp1c3Qgbm90IHNlZWluZyB3aGF0IHlvdSB0aGluayB0aGUgcHJv YmxlbSBpcyBoZXJlLiBJIGRvbid0IHNlZSBhIHByb2JsZW0gc28gSSBmZWVsIHByZXR0eSBzdHJv bmdseSB0aGF0IHRoZSBhbGdvcml0aG0gaW4gQXBwZW5kaXggQiBpcyBmaW5lLiINCg0KW0JBXSBU aGUgYWxnb3JpdGhtIGluIEFwcGVuZGl4IEIgaW5jbHVkZXMgUFQgcm91dGluZyBhbmQgSSdkIGxp a2UgaXQgdG8gY29udGludWUgdG8gY292ZXIgdGhhdC4gIFRoZSBhbGdvcml0aG0gYXBwZWFycyB0 byByZXNvbHZlIGEgbnVtYmVyIG9mIGJ1Z3MgZmlsZWQgYnkgYm90aCBXZWJSVEMgYW5kIE9SVEMg ZGV2ZWxvcGVycy4gSXQgd2lsbCB0YWtlIGEgYml0IG1vcmUgcmV2aWV3IHRvIGNvbmZpcm0gdGhh dCBpdCBkb2Vzbid0IGNhdXNlIGFueSByZWdyZXNzaW9ucy4NCg0KT24gV2VkLCBKYW4gMTgsIDIw MTcgYXQgNjo1MiBBTSwgQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAaWlpLmNhPG1haWx0bzpmbHVm ZnlAaWlpLmNhPj4gd3JvdGU6DQoNCj4gT24gSmFuIDE4LCAyMDE3LCBhdCAzOjAxIEFNLCBNYWdu dXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4NCj4NCj4gUmVnYXJkaW5nIFBU IGJhc2VkIHJvdXRpbmc6DQo+DQo+IFJUQ1dlYiByZXF1aXJlcyBCVU5ETEUsIEJVTkRMRSByZXF1 aXJlcyBNSURzLCB0aHVzIFBUIGJhc2VkIHJvdXRpbmcgb2YgcGFja2V0cyBhcmUgbm90IHJlcXVp cmVkIGZvciBhbnkgV2ViUlRDIGVuZHBvaW50Lg0KDQpMb29rLCBJIGRvbid0IHNlZSBpdCB0aGlz IHdheSBhbmQgSSBzdXNwZWN0IHlvdSBhcmUgZ29pbmcgdG8gYWdyZWUgd2l0aCB3aGF0IEkgc2F5 IG5leHQuLi4uIFdlYlJUQyBicm93c2VycyBhcmUgcmVxdWlyZWQgdG8gaW50ZXJvcGVyYXRlIHdp dGggImxlZ2FjeSIgdGhpbmdzIHRoYXQgZG9uJ3QgZG8gYnVuZGxlIGFuZCB0aGluZ3MgdGhhdCBt YXkgZG8gYnVuZGxlIGJ1dCB0cnkgbm90IHRvIHVzZSBNSURzIGluIGNhc2VzIHdoZXJlIHRoZXkg YXJlIGEgZ3JhdHVpdG91cyB3YXN0ZSBvZiBiYW5kd2lkdGguDQoNCj4gUFQgYmFzZWQgcm91dGlu ZyB3b3JrcyBvbmx5IGluIHNvbWUgY29uc3RyYWluZWQgdXNhZ2VzLCB0aHVzIG15IHZpZXcgaXMg dGhhdCBpdCBuZWVkcyB0byByZW1haW4gYSBoaW50LCBhbmQgYW4gb3B0aW9uYWwgaGludCBhdCBt b3N0Lg0KPiBJdCBtdXN0IGJlIGNsZWFyIHRoYXQgaXQgaXMgbm90IHNvbWV0aGluZyB0aGF0IGlz IHJlbGlhYmxlLg0KDQpZb3Uga2VlcCBhc3NlcnRpbmcgdGhpcyBidXQgSSdtIG5vdCBjb252aW5j ZWQgeW91IGFyZSBhcmUgY29ycmVjdCBzbyBwZXJoYXBzIHlvdSBjb3VsZCBleHBsYWluIHRoZSB3 aGVyZSB0aGV5IGRvbid0IHdvcmsuIEkgc2VlbiBsb3RzIG9mIHByb2plY3RzIHNoaXAgdGhpcyBh bmQgd29yayBmaW5lLiBUaGUgYWxnb3JpdGhtIGluIGFwcGVuZGl4IEIgbWFrZSBpdCBjbGVhciBQ VCBhcmUgb25seSB1c2VkIGlmIHRoZXkgYXJlIHVuaXF1ZSBhY3Jvc3MgYWxsIHRoZSBtLWxpbmVz LiBTbyBjbGVhcmx5IGl0IGNhbiBub3QgYmUgdXNlZCBpZiB5b3UgbmVlZCBtb3JlIFBUIHRoYW4g YXJlIGF2YWlsYWJsZSBpbiB0aGUgUFQgc3BhY2UuIEEgaHVnZSBwZXJjZW50YWdlIG9mIG9mIHJl YWwgd29ybGQgdXNlIGNhc2VzIGZvciBTRFAgZWFzaWx5IGZpdCBpbnNpZGUgdGhlIGN1cnJlbnQg UFQgc3BhY2UuIE9uZSBvZiB0aGUgY2FzZXMgSSBjYXJlIGFib3V0IGlmIGEgbG93IHBlYWsgYmFu ZHdpZHRoIHBob25lIChub3QgYXZlcmFnZSkgZm9yIHBsYWNlcyBsaWtlIHBhcnRzIG9mIEFmcmlj YSB0aGF0IHVzZXMgYSA3MDAgYnBzIGNvZGVjLiBNb3N0IHNpbmdsZSBzdHJlYW0gb2YgYXVkaW8g YW5kIHZpZGVvICJ2aWRlbyBwaG9uZSBjYWxsIiB0eXBlIGNhc2VzIGFsc28gZWFzaWx5IHdvcmsu IFllcywgSSB1bmRlcnN0YW5kIG9uZSBjb3VsZCBjb25zdHJ1Y3Qgc29tZSBzaW5nbGUgYXVkaW8v dmlkZW8gd2hlcmUgZW5vdWdoIHRoaW5ncyB3ZXJlIHRoZSBTRFAgb2ZmZXIgbmVlZHMgbW9yZSBQ VHMgdGhhbiB0aGVyZSB3YXMgc3BhY2UgZm9yIGJ1dCBpZiB5b3UgbG9vayBhdCB0aGUgU0RQIGZy b20ganVzdCBhYm91dCBldmVyeSBtYWpvciBtYW51ZmFjdHVyZSBvZiBWb0lQIGF1ZGlvIHBob25l cywgeW91IHNlZSB3aGF0IHRoZXkgYXJlIGN1cnJlbnRseSBkb2luZyBjYW4gZWFzaWx5IGJlIGRv bmUgd2l0aCB1bmlxdWUgUFQgdmFsdWVzLiBBbnl3YXksIGZvciB0aGVzZQ0KICBjYXNlIHdoZXJl IHlvdSBkb24ndCBydW4gb3V0IG9mIFBULCBwbGVhc2UgcGxlYXNlIGV4cGxhaW4gd2h5IFBUIHJv dXRpbmcgaXMgc28gYnJva2VuIHRoYXQgaXMgc2hvdWxkIGJlIGFuIG9wdGlvbmFsIGhpbnQuIElu IHByYWN0aWNlIGl0IHNlZW1zIHRvIHdvcmsgZmluZS4NCg0KQW55d2F5cywgSSdtIGp1c3Qgbm90 IHNlZWluZyB3aGF0IHlvdSB0aGluayB0aGUgcHJvYmxlbSBpcyBoZXJlLiBJIGRvbid0IHNlZSBh IHByb2JsZW0gc28gSSBmZWVsIHByZXR0eSBzdHJvbmdseSB0aGF0IHRoZSBhbGdvcml0aG0gaW4g QXBwZW5kaXggQiBpcyBmaW5lLiBDb252aW5jZSBtZSBvbiB3aHkgaXMgIm5vdCByZWxpYWJsZSIg YW5kIGFuZCAib25seSBpbiBzb21lIGNvbnN0cmFpbmVkIHVzYWdlcyINCg0KPiBJIGFsc28gc3Ry dWdnbGUgdG8gc2VlIGluIHdoYXQgbm9uLVdlYlJUQyBpbnRlcm9wIHVzZSBjYXNlcyB0aGlzIGFy aXNlcy4gVGhlIG5vbi1XZWJSVEMgZW5kcG9pbnQgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBtdWx0 aSBtZWRpYSBzb3VyY2UsIGFuZCBtdWx0aSBzdHJlYW0gKFNTUkMpIFJUUCBzZXNzaW9ucywgYnV0 IG5vdCBpbXBsZW1lbnQgQlVORExFLiBPciBpcyBpdCBhIGFnZ3JlZ2F0aW5nIGdhdGV3YXksIHRo YXQgaXMgdG8gbGF6eSB0byBhZGQgTUlEcz8NCj4NCg0KDQpQZW9wbGUgd2FudCB0byBhdm9pZCB0 aGUgbWVkaWEgZ2F0ZXdheSBiZXR3ZWVuIFdlYlJUQyBhbmQgYW5kIGFuIFNJUCBlbmRwb2ludCB3 aGVyZSB0aGV5IGNhbi4gVGhlIG1lZGlhIGdhdGV3YXkgYWRkcyBsYXRlbmN5IC0gaHVnZSBhbW91 bnRzIGluIHRoZSBjYXNlIHdoZXJlIGJvdGggZW5kcG9pbnRzIHJlcXVpcmUgYSBzYXRlbGxpdGUg aG9wIHRvIGdldCB0byB0aGUgZ2F0ZXdheSAtIGFuZCBpdCBhZGQgdGhlIGJhbmR3aWR0aCBleHBl bnNlcyBvZiBydW5uaW5nIGdhdGV3YXkuDQoNCg0KDQpPbiBhbGwgb2YgdGhpcywgSSB3YW50IHRv IGJlIGNsZWFyLCBmb3IgcGVvcGxlIHRoYXQgd2FudCB0byBkbyBzb21ldGhpbmcgd2hlcmUgdGhl IFBUIHNwYWNlIGlzIG5vdCBsYXJnZSBlbm91Z2gsIG9idmlvdXNseSB0aGV5IGNhbiB1c2UgTUlE LCBJJ20ganVzdCBzYXlpbmcgdGhhdCBmb3IgdGhpbmdzIHRoYXQgZG9uJ3QgdXNlIE1JRCwgYW5k IGNhbiBmaXQgaW4gdGhlIFBUIHNwYWNlLCBpdCBzaG91bGQgYmUgYW4gb3B0aW9uIHRvIHVzZSBQ VCBhbmQga25vdyBpdCB3aWxsIHdvcmsuDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2Vi QGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BF997A1ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+WWVzLCBJIGFncmVl LiBBbmQgSSB0aGluayB0aGF0J3Mgd2hhdCBhcHBlbmRpeCBCIGN1cnJlbnRseSBzYXlzLjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPk15IGNvbW1lbnQgd2FzIG1vcmUgb24gd2hhdCBoYXMgYmVlbiBkaXNjdXNzZWQg b24gdGhpcyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ UmVnYXJkaW5nIEFwcGVuZGl4IEIgaW4gZ2VuZXJhbDogaWYgdGhlIGlkZWEgaXMgdG8gZXZlbnR1 YWxseSBwbGFjZSB0aGUgdGV4dCBpbiBkcmFmdC1idW5kbGUsIEkgdGhpbmsgd2Ugc2hvdWxkIG1v dmUgaXQgdGhlcmUgQkVGT1JFIHRoZSBwdWJsaWNhdGlvbiByZXF1ZXN0IGZvcg0KIGRyYWZ0LWpz ZXAgaXMgZG9uZS4gSSBzZWUgbm8gcmVhc29uIHRvIGhhdmUgdGhlIHRleHQgaW4gdHdvIHBsYWNl cy4gUGVyaGFwcyB0aGF04oCZcyB0aGUgaW50ZW50aW9uLCBidXQgaXTigJlzIG5vdCBjbGVhciB3 aGVuIHJlYWRpbmcgdGhlIGRyYWZ04oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEphbiAyMSwgMjAx NyBhdCA1OjMyIEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPkl0J3Mgbm90IGJpZyBl bm91Z2ggZm9yIGV2ZXJ5IHVzZSBjYXNlIGJ1dCBpdCdzIGluIHVzZSBmb3IgY2VydGFpbiBsaW1p dGVkIHVzZSBjYXNlcw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+bm93 LiBIZW5jZSB0aGUgbmVlZCB0byBzdXBwb3J0IFBUIG5vdyBhbmQgTUlEIGluIHRoZSBmdXR1cmU8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiB0aGF0IGNhc2Ug dGhlcmUgc2hvdWxkIGJlIGEgY2xlYXIgcnVsZSBzYXlpbmcgdGhhdCwgaWYgdGhlIFBUcyBhcmUg dW5pcXVlLCB0aGV5IGNhbiBiZSB1c2VkLiBObw0KIOKAnGhpbnRz4oCdIDopPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T24gRnJpLCBKYW4gMjAsIDIwMTcgYXQgMzozMyBBTSwgQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWYgdGhpbmdzIHdvcmsgZmluZSB1c2luZyBQ VCwgd2h5IGRvIHdlIG1hbmRhdGUgTUlEIGluIHRoZSBmaXJzdCBwbGFjZT8gV2h5IHdvdWxkIHBl b3BsZSBpbXBsZW1lbnQgTUlEDQogaW4gdGhlIGZ1dHVyZSBpZiBQVCB3b3Jrcz88L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlVubGVzcyBJIHJlbWVtYmVyIHdyb25nLCBBZGFtIGlzIHRoZSBvbmUgd2hvIHNhaWQg dGhhdCB0aGUgUFQgc3BhY2UgaXMgbm90IGJpZyBlbm91Z2gsIGFuZCB0aGF0IHdlIHRoZXJlZm9y DQogbmVlZCBzb21ldGhpbmcgZWxzZSDigJMgd2hpY2ggbWFkZSB1cyBtYW5kYXRlIFNTUkMsIHNw ZWNpZnkgdGhlIHRvb2xzIGZvciBNSUQgdHJhbnNwb3J0LCBldGMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5B bHNvLCBJIGFtIG5vdCBzdXJlIHdoYXQgaXMgbWVhbnQgYnkgYSDigJxoaW504oCdLiBJZiB0aGVy ZSBhcmUgYXBwbGljYXRpb25zIHRoYXQgZG9u4oCZdCBzdXBwb3J0IE1JRCwgYW5kDQogbmVlZCB0 byB1c2UgUFQsIHRoZW4gaXQgaGFzIHRvIGJlIG1vcmUgdGhhbiBhIOKAnGhpbnTigJ0uIEl0IG11 c3QgYmUgYSB0ZXN0YWJsZSBydWxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnJ0Y3dlYiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQmVybmFyZCBBYm9iYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmVybmFy ZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXkgMTgg SmFudWFyeSAyMDE3IGF0IDE5OjM0PGJyPg0KPGI+VG86IDwvYj5DdWxsZW4gSmVubmluZ3MgJmx0 OzxhIGhyZWY9Im1haWx0bzpmbHVmZnlAaWlpLmNhIiB0YXJnZXQ9Il9ibGFuayI+Zmx1ZmZ5QGlp aS5jYTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbcnRjd2ViXSBXb3JraW5n IGdyb3VwIGxhc3QgY2FsbCByZXNvbHV0aW9ucy9Db25zZW5zdXMgY2FsbDogQXBwZW5kaXggQjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkN1bGxlbiBzYWlkOiZu YnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5M b29rLCBJIGRvbid0IHNlZQ0KIGl0IHRoaXMgd2F5IGFuZCBJIHN1c3BlY3QgeW91IGFyZSBnb2lu ZyB0byBhZ3JlZSB3aXRoIHdoYXQgSSBzYXkgbmV4dC4uLi4gV2ViUlRDIGJyb3dzZXJzIGFyZSBy ZXF1aXJlZCB0byBpbnRlcm9wZXJhdGUgd2l0aCAmcXVvdDtsZWdhY3kmcXVvdDsgdGhpbmdzIHRo YXQgZG9uJ3QgZG8gYnVuZGxlIGFuZCB0aGluZ3MgdGhhdCBtYXkgZG8gYnVuZGxlIGJ1dCB0cnkg bm90IHRvIHVzZSBNSURzIGluIGNhc2VzIHdoZXJlIHRoZXkgYXJlIGEgZ3JhdHVpdG91cyB3YXN0 ZQ0KIG9mIGJhbmR3aWR0aC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mcXVv dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPltCQV0gJiM0MzsxLiAmbmJzcDsgVGhlcmUgaXMgZGVmaW5pdGVs eSBhbiBleHBlY3RhdGlvbiBvbiB0aGUgcGFydCBvZiBkZXZlbG9wZXJzIHRoYXQgV2ViUlRDIHdp bGwgYmVoYXZlIGxpa2UNCiB0aGUgJnF1b3Q7bGVnYWN5JnF1b3Q7IFNEUCB0aGV5IGFyZSB1c2Vk IHRvIC0gZXZlbiBpZiB0aGV5IGFyZSBub3QgaW50ZXJvcGVyYXRpbmcgd2l0aCBsZWdhY3kgYXBw bGljYXRpb25zLiZuYnNwOyBTaW5jZSB0aG9zZSBhcHBsaWNhdGlvbnMgd29ya2VkIHdpdGhvdXQg TUlEcywgZGV2ZWxvcGVycyB3aWxsIGV4cGVjdCB0aGVtIHRvIGNvbnRpbnVlIHRvIHdvcmsgd2hl biBNSUQgc3VwcG9ydCBpcyBpbnRyb2R1Y2VkIGluIGZ1dHVyZS4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBzZWVuIGxvdHMg b2YgcHJvamVjdHMNCiBzaGlwIHRoaXMgYW5kIHdvcmsgZmluZS4gVGhlIGFsZ29yaXRobSBpbiBh cHBlbmRpeCBCIG1ha2UgaXQgY2xlYXIgUFQgYXJlIG9ubHkgdXNlZCBpZiB0aGV5IGFyZSB1bmlx dWUgYWNyb3NzIGFsbCB0aGUgbS1saW5lcy4gU28gY2xlYXJseSBpdCBjYW4gbm90IGJlIHVzZWQg aWYgeW91IG5lZWQgbW9yZSBQVCB0aGFuIGFyZSBhdmFpbGFibGUgaW4gdGhlIFBUIHNwYWNlLiBB IGh1Z2UgcGVyY2VudGFnZSBvZiBvZiByZWFsIHdvcmxkIHVzZSBjYXNlcw0KIGZvciBTRFAgZWFz aWx5IGZpdCBpbnNpZGUgdGhlIGN1cnJlbnQgUFQgc3BhY2UuJnF1b3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PltCQV0gJiM0MzsxLiZuYnNwOyBNeSBleHBlcmllbmNlIGlzIHRoYXQgKm1vc3QqIG9mIHRoZSBk ZXZlbG9wZXJzIHNoaXBwaW5nIFdlYlJUQyBhcHBsaWNhdGlvbnMgdGhhdCBydW4gb24gbXVsdGlw bGUNCiBicm93c2VycyBhcmUgdXNpbmcgUFQtYmFzZWQgcm91dGluZywgc28gdGhleSdkIGJlIHZl cnkgc3VycHJpc2VkIHRvIGxlYXJuIHRoYXQgaXQgaXNuJ3Qgc3VwcG9ydGVkIChhbmQgdGhleSB3 b3VsZCBwcm9iYWJseSBwdXNoIGJhY2sgdmlnb3JvdXNseSBhdCBzdWNoIGEgbm90aW9uKS4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+JnF1b3Q7QW55d2F5cywgSSdtIGp1c3Qgbm90IHNlZWluZyB3aGF0 IHlvdSB0aGluayB0aGUgcHJvYmxlbSBpcyBoZXJlLiBJIGRvbid0IHNlZSBhIHByb2JsZW0gc28g SSBmZWVsIHByZXR0eQ0KIHN0cm9uZ2x5IHRoYXQgdGhlIGFsZ29yaXRobSBpbiBBcHBlbmRpeCBC IGlzIGZpbmUuJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltCQV0gVGhlIGFsZ29yaXRobSBpbiBBcHBl bmRpeCBCIGluY2x1ZGVzIFBUIHJvdXRpbmcgYW5kIEknZCBsaWtlIGl0IHRvIGNvbnRpbnVlIHRv IGNvdmVyIHRoYXQuJm5ic3A7IFRoZSBhbGdvcml0aG0NCiBhcHBlYXJzIHRvIHJlc29sdmUgYSBu dW1iZXIgb2YgYnVncyBmaWxlZCBieSBib3RoIFdlYlJUQyBhbmQgT1JUQyBkZXZlbG9wZXJzLiBJ dCB3aWxsIHRha2UgYSBiaXQgbW9yZSByZXZpZXcgdG8gY29uZmlybSB0aGF0IGl0IGRvZXNuJ3Qg Y2F1c2UgYW55IHJlZ3Jlc3Npb25zLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24gV2VkLCBKYW4g MTgsIDIwMTcgYXQgNjo1MiBBTSwgQ3VsbGVuIEplbm5pbmdzICZsdDs8YSBocmVmPSJtYWlsdG86 Zmx1ZmZ5QGlpaS5jYSIgdGFyZ2V0PSJfYmxhbmsiPmZsdWZmeUBpaWkuY2E8L2E+Jmd0Ow0KIHdy b3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxicj4NCiZndDsgT24gSmFuIDE4LCAyMDE3LCBhdCAzOjAxIEFNLCBN YWdudXMgV2VzdGVybHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVy aWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRpbmcg UFQgYmFzZWQgcm91dGluZzo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBSVENXZWIgcmVxdWlyZXMgQlVO RExFLCBCVU5ETEUgcmVxdWlyZXMgTUlEcywgdGh1cyBQVCBiYXNlZCByb3V0aW5nIG9mIHBhY2tl dHMgYXJlIG5vdCByZXF1aXJlZCBmb3IgYW55IFdlYlJUQyBlbmRwb2ludC48YnI+DQo8YnI+DQpM b29rLCBJIGRvbid0IHNlZSBpdCB0aGlzIHdheSBhbmQgSSBzdXNwZWN0IHlvdSBhcmUgZ29pbmcg dG8gYWdyZWUgd2l0aCB3aGF0IEkgc2F5IG5leHQuLi4uIFdlYlJUQyBicm93c2VycyBhcmUgcmVx dWlyZWQgdG8gaW50ZXJvcGVyYXRlIHdpdGggJnF1b3Q7bGVnYWN5JnF1b3Q7IHRoaW5ncyB0aGF0 IGRvbid0IGRvIGJ1bmRsZSBhbmQgdGhpbmdzIHRoYXQgbWF5IGRvIGJ1bmRsZSBidXQgdHJ5IG5v dCB0byB1c2UgTUlEcyBpbiBjYXNlcyB3aGVyZSB0aGV5IGFyZQ0KIGEgZ3JhdHVpdG91cyB3YXN0 ZSBvZiBiYW5kd2lkdGguPGJyPg0KPGJyPg0KJmd0OyBQVCBiYXNlZCByb3V0aW5nIHdvcmtzIG9u bHkgaW4gc29tZSBjb25zdHJhaW5lZCB1c2FnZXMsIHRodXMgbXkgdmlldyBpcyB0aGF0IGl0IG5l ZWRzIHRvIHJlbWFpbiBhIGhpbnQsIGFuZCBhbiBvcHRpb25hbCBoaW50IGF0IG1vc3QuPGJyPg0K Jmd0OyBJdCBtdXN0IGJlIGNsZWFyIHRoYXQgaXQgaXMgbm90IHNvbWV0aGluZyB0aGF0IGlzIHJl bGlhYmxlLjxicj4NCjxicj4NCllvdSBrZWVwIGFzc2VydGluZyB0aGlzIGJ1dCBJJ20gbm90IGNv bnZpbmNlZCB5b3UgYXJlIGFyZSBjb3JyZWN0IHNvIHBlcmhhcHMgeW91IGNvdWxkIGV4cGxhaW4g dGhlIHdoZXJlIHRoZXkgZG9uJ3Qgd29yay4gSSBzZWVuIGxvdHMgb2YgcHJvamVjdHMgc2hpcCB0 aGlzIGFuZCB3b3JrIGZpbmUuIFRoZSBhbGdvcml0aG0gaW4gYXBwZW5kaXggQiBtYWtlIGl0IGNs ZWFyIFBUIGFyZSBvbmx5IHVzZWQgaWYgdGhleSBhcmUgdW5pcXVlIGFjcm9zcyBhbGwNCiB0aGUg bS1saW5lcy4gU28gY2xlYXJseSBpdCBjYW4gbm90IGJlIHVzZWQgaWYgeW91IG5lZWQgbW9yZSBQ VCB0aGFuIGFyZSBhdmFpbGFibGUgaW4gdGhlIFBUIHNwYWNlLiBBIGh1Z2UgcGVyY2VudGFnZSBv ZiBvZiByZWFsIHdvcmxkIHVzZSBjYXNlcyBmb3IgU0RQIGVhc2lseSBmaXQgaW5zaWRlIHRoZSBj dXJyZW50IFBUIHNwYWNlLiBPbmUgb2YgdGhlIGNhc2VzIEkgY2FyZSBhYm91dCBpZiBhIGxvdyBw ZWFrIGJhbmR3aWR0aCBwaG9uZSAobm90DQogYXZlcmFnZSkgZm9yIHBsYWNlcyBsaWtlIHBhcnRz IG9mIEFmcmljYSB0aGF0IHVzZXMgYSA3MDAgYnBzIGNvZGVjLiBNb3N0IHNpbmdsZSBzdHJlYW0g b2YgYXVkaW8gYW5kIHZpZGVvICZxdW90O3ZpZGVvIHBob25lIGNhbGwmcXVvdDsgdHlwZSBjYXNl cyBhbHNvIGVhc2lseSB3b3JrLiBZZXMsIEkgdW5kZXJzdGFuZCBvbmUgY291bGQgY29uc3RydWN0 IHNvbWUgc2luZ2xlIGF1ZGlvL3ZpZGVvIHdoZXJlIGVub3VnaCB0aGluZ3Mgd2VyZSB0aGUgU0RQ IG9mZmVyIG5lZWRzDQogbW9yZSBQVHMgdGhhbiB0aGVyZSB3YXMgc3BhY2UgZm9yIGJ1dCBpZiB5 b3UgbG9vayBhdCB0aGUgU0RQIGZyb20ganVzdCBhYm91dCBldmVyeSBtYWpvciBtYW51ZmFjdHVy ZSBvZiBWb0lQIGF1ZGlvIHBob25lcywgeW91IHNlZSB3aGF0IHRoZXkgYXJlIGN1cnJlbnRseSBk b2luZyBjYW4gZWFzaWx5IGJlIGRvbmUgd2l0aCB1bmlxdWUgUFQgdmFsdWVzLiBBbnl3YXksIGZv ciB0aGVzZTxicj4NCiZuYnNwOyBjYXNlIHdoZXJlIHlvdSBkb24ndCBydW4gb3V0IG9mIFBULCBw bGVhc2UgcGxlYXNlIGV4cGxhaW4gd2h5IFBUIHJvdXRpbmcgaXMgc28gYnJva2VuIHRoYXQgaXMg c2hvdWxkIGJlIGFuIG9wdGlvbmFsIGhpbnQuIEluIHByYWN0aWNlIGl0IHNlZW1zIHRvIHdvcmsg ZmluZS48YnI+DQo8YnI+DQpBbnl3YXlzLCBJJ20ganVzdCBub3Qgc2VlaW5nIHdoYXQgeW91IHRo aW5rIHRoZSBwcm9ibGVtIGlzIGhlcmUuIEkgZG9uJ3Qgc2VlIGEgcHJvYmxlbSBzbyBJIGZlZWwg cHJldHR5IHN0cm9uZ2x5IHRoYXQgdGhlIGFsZ29yaXRobSBpbiBBcHBlbmRpeCBCIGlzIGZpbmUu IENvbnZpbmNlIG1lIG9uIHdoeSBpcyAmcXVvdDtub3QgcmVsaWFibGUmcXVvdDsgYW5kIGFuZCAm cXVvdDtvbmx5IGluIHNvbWUgY29uc3RyYWluZWQgdXNhZ2VzJnF1b3Q7PGJyPg0KPGJyPg0KJmd0 OyBJIGFsc28gc3RydWdnbGUgdG8gc2VlIGluIHdoYXQgbm9uLVdlYlJUQyBpbnRlcm9wIHVzZSBj YXNlcyB0aGlzIGFyaXNlcy4gVGhlIG5vbi1XZWJSVEMgZW5kcG9pbnQgbmVlZHMgdG8gYmUgY2Fw YWJsZSBvZiBtdWx0aSBtZWRpYSBzb3VyY2UsIGFuZCBtdWx0aSBzdHJlYW0gKFNTUkMpIFJUUCBz ZXNzaW9ucywgYnV0IG5vdCBpbXBsZW1lbnQgQlVORExFLiBPciBpcyBpdCBhIGFnZ3JlZ2F0aW5n IGdhdGV3YXksIHRoYXQgaXMgdG8gbGF6eSB0bw0KIGFkZCBNSURzPzxicj4NCiZndDs8YnI+DQo8 YnI+DQo8YnI+DQpQZW9wbGUgd2FudCB0byBhdm9pZCB0aGUgbWVkaWEgZ2F0ZXdheSBiZXR3ZWVu IFdlYlJUQyBhbmQgYW5kIGFuIFNJUCBlbmRwb2ludCB3aGVyZSB0aGV5IGNhbi4gVGhlIG1lZGlh IGdhdGV3YXkgYWRkcyBsYXRlbmN5IC0gaHVnZSBhbW91bnRzIGluIHRoZSBjYXNlIHdoZXJlIGJv dGggZW5kcG9pbnRzIHJlcXVpcmUgYSBzYXRlbGxpdGUgaG9wIHRvIGdldCB0byB0aGUgZ2F0ZXdh eSAtIGFuZCBpdCBhZGQgdGhlIGJhbmR3aWR0aCBleHBlbnNlcyBvZg0KIHJ1bm5pbmcgZ2F0ZXdh eS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiBhbGwgb2YgdGhpcywgSSB3YW50IHRvIGJlIGNs ZWFyLCBmb3IgcGVvcGxlIHRoYXQgd2FudCB0byBkbyBzb21ldGhpbmcgd2hlcmUgdGhlIFBUIHNw YWNlIGlzIG5vdCBsYXJnZSBlbm91Z2gsIG9idmlvdXNseSB0aGV5IGNhbiB1c2UgTUlELCBJJ20g anVzdCBzYXlpbmcgdGhhdCBmb3IgdGhpbmdzIHRoYXQgZG9uJ3QgdXNlIE1JRCwgYW5kIGNhbiBm aXQgaW4gdGhlIFBUIHNwYWNlLCBpdCBzaG91bGQgYmUgYW4gb3B0aW9uIHRvIHVzZSBQVCBhbmQN CiBrbm93IGl0IHdpbGwgd29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BF997A1ESESSMB209erics_-- From nobody Sat Jan 21 12:13:13 2017 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 03EA7129C80 for ; Sat, 21 Jan 2017 12:13:12 -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=ham 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 dcNg_st4t-e3 for ; Sat, 21 Jan 2017 12:13:09 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 98CC4129C7E for ; Sat, 21 Jan 2017 12:13:09 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id v200so114963103ywc.3 for ; Sat, 21 Jan 2017 12:13:09 -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=qtA2gnBYsN7kVzUt33cu7siHmnlrhTA1D+QM7cvJaPk=; b=RVD8lHNA9LnvuRBihF6FZoCcxMjMnS3U7vpUPLA7JS1Qsn46u0XKM70aicUooJwsOT nraYNYp20hT+GzPX3+V8bduSMbyNz2rvB9jxg6+EWhx46lsQV9Ig9B2MJDb4DdceXGur /EmmSGkPbIZMKP5w9wDIx7ld+snfSx9I7Ay1C7EdC6/fa05NpoJKqORHW/wgQUmHqs8n VY3XkLQTxkv2nU9bjt2QEQQyRUy2Yr5CgstdCeUJzxab1SAMyLQsF/txZUhYd5nTcMzR d1Xi/USsmaCEKt0xmPWdgge5x3V4iyktIiUYJBZoaHzbATjR1xPMb66P9NV/OLAxKlqX g73Q== 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=qtA2gnBYsN7kVzUt33cu7siHmnlrhTA1D+QM7cvJaPk=; b=SyNNmeRXR4LdEwLfK9GOCs1UWTbmsqmu0O7G81+JwTbw6qdZu7Du7sRIOE+ZihSC08 W3PiAFKxmmux5o2FSiZ50vYX6IlkhCYwMX5/AW4WjNtfSV6YPj7MqWspCfrtJ0CZkL6p Gtw+XFQ9gAuj0G1joSDg+8hhqPSg7qwfbwtXCHujqoM/AVL4TqncsrEEaN8seCDt7Q1R bk9wwADfPXC8/d1WsS4DQN700BDM4g8HS2Xgs5mE6ssfH5YmgGrHWCnDTwU5V7LWqfhJ KF9TsTx3DicdoBip5YJZ+d5rHtVimZNnWqcYeAd+ABo+qiM9Io9zWsT6PfpUpKef1VkB uagQ== X-Gm-Message-State: AIkVDXKqYU12IOf5/sWA+Bi8t4Zza8KmeGzpcaXRL3y/7gKg1TIEUCqSRDpUNxBm1zSGYlBJLtIddhb6bLbGjg== X-Received: by 10.129.137.129 with SMTP id z123mr14118128ywf.327.1485029588814; Sat, 21 Jan 2017 12:13:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Sat, 21 Jan 2017 12:12:28 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF997A1@ESESSMB209.ericsson.se> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF941B1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF997A1@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Sat, 21 Jan 2017 12:12:28 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c06bf381f9b750546a065c4 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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: Sat, 21 Jan 2017 20:13:12 -0000 --94eb2c06bf381f9b750546a065c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jan 21, 2017 at 11:46 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >Yes, I agree. And I think that's what appendix B currently says. > > > > My comment was more on what has been discussed on this list. > > > > Regarding Appendix B in general: if the idea is to eventually place the > text in draft-bundle, I think we should move it there BEFORE the > publication request for draft-jsep is done. I see no reason to have the > text in two places. Perhaps that=E2=80=99s the intention, but it=E2=80=99= s not clear when > reading the draft=E2=80=A6 > This seems like a question for the chairs. -Ekr > > > Regards, > > > > Christer > > > > > > > > On Sat, Jan 21, 2017 at 5:32 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > >It's not big enough for every use case but it's in use for certain > limited use cases >now. Hence the need to support PT now and MID in the > future > > > > In that case there should be a clear rule saying that, if the PTs are > unique, they can be used. No =E2=80=9Chints=E2=80=9D :) > > > > Regards, > > > > Christer > > > > > > > > On Fri, Jan 20, 2017 at 3:33 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi, > > > > If things work fine using PT, why do we mandate MID in the first place? > Why would people implement MID in the future if PT works? > > > > Unless I remember wrong, Adam is the one who said that the PT space is no= t > big enough, and that we therefor need something else =E2=80=93 which made= us > mandate SSRC, specify the tools for MID transport, etc. > > > > Also, I am not sure what is meant by a =E2=80=9Chint=E2=80=9D. If there a= re applications > that don=E2=80=99t support MID, and need to use PT, then it has to be mor= e than a > =E2=80=9Chint=E2=80=9D. It must be a testable rule. > > > > Regards, > > > > Christer > > > > > > > > > > > > *From: *rtcweb on behalf of Bernard Aboba < > bernard.aboba@gmail.com> > *Date: *Wednesday 18 January 2017 at 19:34 > *To: *Cullen Jennings > *Cc: *"rtcweb@ietf.org" > *Subject: *Re: [rtcweb] Working group last call resolutions/Consensus > call: Appendix B > > > > Cullen said: > > > > "Look, I don't see it this way and I suspect you are going to agree with > what I say next.... WebRTC browsers are required to interoperate with > "legacy" things that don't do bundle and things that may do bundle but tr= y > not to use MIDs in cases where they are a gratuitous waste of bandwidth." > > > > [BA] +1. There is definitely an expectation on the part of developers > that WebRTC will behave like the "legacy" SDP they are used to - even if > they are not interoperating with legacy applications. Since those > applications worked without MIDs, developers will expect them to continue > to work when MID support is introduced in future. > > > > "I seen lots of projects ship this and work fine. The algorithm in > appendix B make it clear PT are only used if they are unique across all t= he > m-lines. So clearly it can not be used if you need more PT than are > available in the PT space. A huge percentage of of real world use cases f= or > SDP easily fit inside the current PT space." > > > > [BA] +1. My experience is that *most* of the developers shipping WebRTC > applications that run on multiple browsers are using PT-based routing, so > they'd be very surprised to learn that it isn't supported (and they would > probably push back vigorously at such a notion). > > > > "Anyways, I'm just not seeing what you think the problem is here. I don't > see a problem so I feel pretty strongly that the algorithm in Appendix B = is > fine." > > > > [BA] The algorithm in Appendix B includes PT routing and I'd like it to > continue to cover that. The algorithm appears to resolve a number of bug= s > filed by both WebRTC and ORTC developers. It will take a bit more review = to > confirm that it doesn't cause any regressions. > > > > On Wed, Jan 18, 2017 at 6:52 AM, Cullen Jennings wrote: > > > > On Jan 18, 2017, at 3:01 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > > > > > Regarding PT based routing: > > > > RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of > packets are not required for any WebRTC endpoint. > > Look, I don't see it this way and I suspect you are going to agree with > what I say next.... WebRTC browsers are required to interoperate with > "legacy" things that don't do bundle and things that may do bundle but tr= y > not to use MIDs in cases where they are a gratuitous waste of bandwidth. > > > PT based routing works only in some constrained usages, thus my view is > that it needs to remain a hint, and an optional hint at most. > > It must be clear that it is not something that is reliable. > > You keep asserting this but I'm not convinced you are are correct so > perhaps you could explain the where they don't work. I seen lots of > projects ship this and work fine. The algorithm in appendix B make it cle= ar > PT are only used if they are unique across all the m-lines. So clearly it > can not be used if you need more PT than are available in the PT space. A > huge percentage of of real world use cases for SDP easily fit inside the > current PT space. One of the cases I care about if a low peak bandwidth > phone (not average) for places like parts of Africa that uses a 700 bps > codec. Most single stream of audio and video "video phone call" type case= s > also easily work. Yes, I understand one could construct some single > audio/video where enough things were the SDP offer needs more PTs than > there was space for but if you look at the SDP from just about every majo= r > manufacture of VoIP audio phones, you see what they are currently doing c= an > easily be done with unique PT values. Anyway, for these > case where you don't run out of PT, please please explain why PT routin= g > is so broken that is should be an optional hint. In practice it seems to > work fine. > > Anyways, I'm just not seeing what you think the problem is here. I don't > see a problem so I feel pretty strongly that the algorithm in Appendix B = is > fine. Convince me on why is "not reliable" and and "only in some > constrained usages" > > > I also struggle to see in what non-WebRTC interop use cases this arises= . > The non-WebRTC endpoint needs to be capable of multi media source, and > multi stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a > aggregating gateway, that is to lazy to add MIDs? > > > > > People want to avoid the media gateway between WebRTC and and an SIP > endpoint where they can. The media gateway adds latency - huge amounts in > the case where both endpoints require a satellite hop to get to the gatew= ay > - and it add the bandwidth expenses of running gateway. > > > > On all of this, I want to be clear, for people that want to do something > where the PT space is not large enough, obviously they can use MID, I'm > just saying that for things that don't use MID, and can fit in the PT > space, it should be an option to use PT and know it will work. > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > --94eb2c06bf381f9b750546a065c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jan 21, 2017 at 11:46 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>Yes, I agre= e. And I think that's what appendix B currently says.

=C2=A0

My comment was more on what ha= s been discussed on this list.

=C2=A0

Regarding Appendix B in general: if t= he idea is to eventually place the text in draft-bundle, I think we should = move it there BEFORE the publication request for draft-jsep is done. I see no reason to have the text in two places. Perhap= s that=E2=80=99s the intention, but it=E2=80=99s not clear when reading the= draft=E2=80=A6


This seems like a question for the chairs.

-Ekr<= /div>
=C2=A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Sat, Jan 21, 2017 at 5:32 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>It's no= t big enough for every use case but it's in use for certain limited use= cases >now. Hence the need to support PT = now and MID in the future

=C2=A0

In that case there should be a clear = rule saying that, if the PTs are unique, they can be used. No =E2=80=9Chints=E2=80=9D :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 20, 2017 at 3:33 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

=C2=A0

Hi,

=C2=A0

If things work fine using PT, why do we= mandate MID in the first place? Why would people implement MID in the future if PT works?

=C2=A0

Unless I remember wrong, Adam is the on= e who said that the PT space is not big enough, and that we therefor need something else =E2=80=93 which made us mandate SSRC, specify the tool= s for MID transport, etc.

=C2=A0

Also, I am not sure what is meant by a = =E2=80=9Chint=E2=80=9D. If there are applications that don=E2=80=99t suppor= t MID, and need to use PT, then it has to be more than a =E2=80=9Chint=E2=80=9D. It m= ust be a testable rule.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Bernard A= boba <berna= rd.aboba@gmail.com>
Date: Wednesday 18 January 2017 at 19:34
To: Cullen Jennings <fluffy@iii.ca>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working group last call resolutions/Consensus = call: Appendix B

=C2=A0

Cullen said:=C2=A0

=C2=A0

"Look, I don= 9;t see it this way and I suspect you are going to agree with what I say next.... = WebRTC browsers are required to interoperate with "legacy" things= that don't do bundle and things that may do bundle but try not to use = MIDs in cases where they are a gratuitous waste of bandwidth."

=C2=A0

[BA] +1. =C2=A0 There is definitely an = expectation on the part of developers that WebRTC will behave like the "legacy" SDP they are used to - even if they are not interop= erating with legacy applications.=C2=A0 Since those applications worked wit= hout MIDs, developers will expect them to continue to work when MID support= is introduced in future.=C2=A0

=C2=A0

"I seen lots of= projects ship this and work fine. The algorithm in appendix B make it clear PT are = only used if they are unique across all the m-lines. So clearly it can not = be used if you need more PT than are available in the PT space. A huge perc= entage of of real world use cases for SDP easily fit inside the current PT space."=

=C2=A0

[BA] +1.=C2=A0 My experience is that *mo= st* of the developers shipping WebRTC applications that run on multiple browsers are using PT-based routing, so they'd be very surprised to le= arn that it isn't supported (and they would probably push back vigorous= ly at such a notion).=C2=A0

=C2=A0

"Anyways, I'm just not seeing w= hat you think the problem is here. I don't see a problem so I feel pret= ty strongly that the algorithm in Appendix B is fine."<= /u>

=C2=A0

[BA] The algorithm in Appendix B include= s PT routing and I'd like it to continue to cover that.=C2=A0 The algor= ithm appears to resolve a number of bugs filed by both WebRTC and ORTC develope= rs. It will take a bit more review to confirm that it doesn't cause any= regressions.=C2=A0

=C2=A0

On Wed, Jan 18, 2017 at 6:52 AM, Cullen= Jennings <fluffy@iii= .ca> wrote:


> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund <magnus.westerlund@ericsson= .com> wrote:
>
>
> Regarding PT based routing:
>
> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing of= packets are not required for any WebRTC endpoint.

Look, I don't see it this way and I suspect you are going to agree with= what I say next.... WebRTC browsers are required to interoperate with &quo= t;legacy" things that don't do bundle and things that may do bundl= e but try not to use MIDs in cases where they are a gratuitous waste of bandwidth.

> PT based routing works only in some constrained usages, thus my view i= s that it needs to remain a hint, and an optional hint at most.
> It must be clear that it is not something that is reliable.

You keep asserting this but I'm not convinced you are are correct so pe= rhaps you could explain the where they don't work. I seen lots of proje= cts ship this and work fine. The algorithm in appendix B make it clear PT a= re only used if they are unique across all the m-lines. So clearly it can not be used if you need more PT than are av= ailable in the PT space. A huge percentage of of real world use cases for S= DP easily fit inside the current PT space. One of the cases I care about if= a low peak bandwidth phone (not average) for places like parts of Africa that uses a 700 bps codec. Most s= ingle stream of audio and video "video phone call" type cases als= o easily work. Yes, I understand one could construct some single audio/vide= o where enough things were the SDP offer needs more PTs than there was space for but if you look at the SDP from just abo= ut every major manufacture of VoIP audio phones, you see what they are curr= ently doing can easily be done with unique PT values. Anyway, for these
=C2=A0 case where you don't run out of PT, please please explain why PT= routing is so broken that is should be an optional hint. In practice it se= ems to work fine.

Anyways, I'm just not seeing what you think the problem is here. I don&= #39;t see a problem so I feel pretty strongly that the algorithm in Appendi= x B is fine. Convince me on why is "not reliable" and and "o= nly in some constrained usages"

> I also struggle to see in what non-WebRTC interop use cases this arise= s. The non-WebRTC endpoint needs to be capable of multi media source, and m= ulti stream (SSRC) RTP sessions, but not implement BUNDLE. Or is it a aggre= gating gateway, that is to lazy to add MIDs?
>


People want to avoid the media gateway between WebRTC and and an SIP endpoi= nt where they can. The media gateway adds latency - huge amounts in the cas= e where both endpoints require a satellite hop to get to the gateway - and = it add the bandwidth expenses of running gateway.



On all of this, I want to be clear, for people that want to do something wh= ere the PT space is not large enough, obviously they can use MID, I'm j= ust saying that for things that don't use MID, and can fit in the PT sp= ace, it should be an option to use PT and know it will work.







_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb<= /p>

=C2=A0


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

=C2=A0

=C2=A0


--94eb2c06bf381f9b750546a065c4-- From nobody Sat Jan 21 17:44:02 2017 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 81BC6129564 for ; Sat, 21 Jan 2017 17:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0PMOogVZ65S2 for ; Sat, 21 Jan 2017 17:44:00 -0800 (PST) Received: from smtp129.dfw.emailsrvr.com (smtp129.dfw.emailsrvr.com [67.192.241.129]) (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 2511D12954B for ; Sat, 21 Jan 2017 17:44:00 -0800 (PST) Received: from smtp29.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 3B83A4014D; Sat, 21 Jan 2017 20:43:59 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 95AE34014B; Sat, 21 Jan 2017 20:43:58 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 21 Jan 2017 20:43:59 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Sat, 21 Jan 2017 18:43:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A373D6B-0E4F-4944-A062-48A221BFB6D7@iii.ca> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3259) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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: Sun, 22 Jan 2017 01:44:01 -0000 > On Jan 20, 2017, at 3:01 AM, Magnus Westerlund = wrote: >=20 > Den 2017-01-18 kl. 15:52, skrev Cullen Jennings: >>=20 >>> On Jan 18, 2017, at 3:01 AM, Magnus Westerlund >>> wrote: >>>=20 >>>=20 >>> Regarding PT based routing: >>>=20 >>> RTCWeb requires BUNDLE, BUNDLE requires MIDs, thus PT based routing >>> of packets are not required for any WebRTC endpoint. >>=20 >> Look, I don't see it this way and I suspect you are going to agree >> with what I say next.... WebRTC browsers are required to interoperate >> with "legacy" things that don't do bundle and things that may do >> bundle but try not to use MIDs in cases where they are a gratuitous >> waste of bandwidth. >>=20 >>> PT based routing works only in some constrained usages, thus my >>> view is that it needs to remain a hint, and an optional hint at >>> most. It must be clear that it is not something that is reliable. >>=20 >> You keep asserting this but I'm not convinced you are are correct so >> perhaps you could explain the where they don't work. I seen lots of >> projects ship this and work fine. The algorithm in appendix B make it >> clear PT are only used if they are unique across all the m-lines. So >> clearly it can not be used if you need more PT than are available in >> the PT space. A huge percentage of of real world use cases for SDP >> easily fit inside the current PT space. One of the cases I care about >> if a low peak bandwidth phone (not average) for places like parts of >> Africa that uses a 700 bps codec. Most single stream of audio and >> video "video phone call" type cases also easily work. Yes, I >> understand one could construct some single audio/video where enough >> things were the SDP offer needs more PTs than there was space for but >> if you look at the SDP from just about every major manufacture of >> VoIP audio phones, you see what they are currently doing can easily >> be done with unique PT values. Anyway, for these case where you don't >> run out of PT, please please explain why PT routing is so broken that >> is should be an optional hint. In practice it seems to work fine. >=20 > I will not contest that it does work as long as you ensure that PT = values are unique across all m=3D lines in one RTP session. My objection = is on an architectural level here. As the PT requirement is not unique = one needs to implement a=3DMIDs. Thus, the PT routing rules becomes a = crutch that gets embedded into also the standards implementation not = only the legacy and carried forward. What I fail to understand is what = this legacy is that does multiple m=3D lines within a single RTP session = is. For how many deployed devices are we ensuring interop with? >=20 So I agree with you that this is not likely to go away and thus why = "legacy" may be a somewhat misleading way of labeling it. Consider a = simple audio call that has the ability to turn on video at any point = that is running with low bit rate codecs over a satellite connection = that reserves the bandwidth for the audio portion (but not the video). = That works today and when you go to those people and tell them they need = to increase the reservation size to support MID but it it will have some = benefit of speeding up call set up, they say "no thanks". However, I = view this architecturally as simply when you use cases can not fit in = the "legacy" address space of PT, then use MID to get an expanded = address space. Even if we mandated everything do MID, it's not like we = could remove the PT from the packet or from the code. So much stuff is = built at this point which does this that I think we are really in the = document how it works stage.=20 >>=20 >> Anyways, I'm just not seeing what you think the problem is here. I >> don't see a problem so I feel pretty strongly that the algorithm in >> Appendix B is fine. Convince me on why is "not reliable" and and >> "only in some constrained usages" >=20 > I accept that the PT association rules needs to stay in. And this is a = diversion from the part that I have real issue with. The style of the = rules that places the routing below the RTP stack, rather than above it. = And you may note that I did explain how my proposed description format = would take PTs into account. My question is would you and others have = objections with rules as I wrote them? If we have two descriptions of this packet demux stuff and they both = result in implementors needing to write the same code, then I have no = strong opinions about which one we use. Not 100% sure but I think I = understand what you are suggesting and I think that is the case we are = in here. At that point I tend to favor the one that has the best odds = that when implementors read it, that they will write interoperable code. = I think others feel strong than me about how it is described but I = mostly just care what algorithm I can count on the person I am sending = packets to implementing.=20 From nobody Mon Jan 23 01:54:48 2017 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 49820129B0A for ; Mon, 23 Jan 2017 01:54:47 -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, 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 qSQh9ISWGgzg for ; Mon, 23 Jan 2017 01:54:45 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 74883129AE4 for ; Mon, 23 Jan 2017 01:54:45 -0800 (PST) X-AuditID: c1b4fb25-4ccfd980000066fb-2b-5885d2e34345 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id AE.31.26363.3E2D5885; Mon, 23 Jan 2017 10:54:43 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.319.2; Mon, 23 Jan 2017 10:51:51 +0100 To: Eric Rescorla References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: Magnus Westerlund Message-ID: Date: Mon, 23 Jan 2017 10:51:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM2K7pe7jS60RBmc36lmseH2O3aJjMpvF 2n/t7BZXVjUyWzTOtXNg9ZjyeyOrx85Zd9k9liz5yeQx+XEbs8fBg4wBrFFcNimpOZllqUX6 dglcGUsWRBasj6xoff2WqYHxpWMXIyeHhICJxMqld9lBbCGBdYwStz9JQtjLGSVWb3YHsYUF wiRaNxxnArFFBBQkfv05wdLFyAVUc5ZR4s3+LawgDrNAD6PExqUnWEGq2AQsJG7+aGQDsXkF 7CVu3rzDAmKzCKhKNL7fAVYjKhAj8Xb9cnaIGkGJkzOfgNVwCgRKnDyyH6yGGWjOzPnnGSFs eYnmrbOZIa7Tlmho6mCdwCgwC0n7LCQts5C0LGBkXsUoWpxanJSbbmSsl1qUmVxcnJ+nl5da sokRGMwHt/xW3cF4+Y3jIUYBDkYlHl4DxtYIIdbEsuLK3EOMEhzMSiK8Jw8ChXhTEiurUovy 44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamBk/lJx+GWer/7flUKdEg2S MxoPqPV/3CDd2pJQvGX6Al9l+6CSaxcnnnOuPsye1NJk1WWmz2HSuejY2rr7SvNc1kS/LJmi b5J9g6PQN6ns//1U93o13iSzPZe77f4/mCJzQvJEoL1DaaOed/KWzFrxz+Gfps4Xe8qZwxr5 dM6K+e7MJyes267EUpyRaKjFXFScCABTA+wZYgIAAA== Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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: Mon, 23 Jan 2017 09:54:47 -0000 Hi, See inline below. Den 2017-01-20 kl. 23:25, skrev Eric Rescorla: > The text I talk about is the following: > > For each RTP packet received, the following steps MUST be followed to > route the packet to the correct "m=" section within a BUNDLE group. > Note that the phrase 'deliver a packet to the "m=" line' means to > further process the packet as would normally happen with RTP/RTCP, if > it were received on a transport associated with that "m=" line > outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd), > including dropping an RTP packet if the packet's PT does not match > any PT in the "m=" line. > > If the packet has a MID and that MID is not in the table mapping > MID to "m=" line, drop the packet and stop. > > If the packet has a MID and that MID is in the table mapping MID > to "m=" line, update the incoming SSRC mapping table to include an > entry that maps the packet's SSRC to the "m=" line for that MID. > > If the packet's SSRC is in the incoming SSRC mapping table, route > the packet to the associated "m=" line and stop. > > If the packet's payload type is in the payload type table, update > the the incoming SSRC mapping table to include an entry that maps > the packet's SSRC to the "m=" line for that payload type. In > addition, route the packet to the associated "m=" line and stop. > > Otherwise, drop the packet. > > If I would write this packet level routing it would work with the > concepts of the RTP protocol: > > This the bullet list would look like this instead: > > 1. Reception of an RTP packet for a SSRC with an existing > association to an m= line, with a MID RTP header extension, the > MID value is checked. If it matches the existing association, > then the processing continues in that m= line context. If > the value is a new value, then the association to the m= line > is updated, and then the packet is processed in the new m= line > context. > > > I don't understand how this point is different from points #1 and #2 above. > > Is your problem with the talk of a table versus an association? Routing > to an m= line versus "processed in the m= line context"? Can you help me > understand > how these are semantically different? Specifically what implementation > technique would > be allowed by your text that is not allowed by the existing text (and > that couldn't be > solved by requiring implementations to have the same external behavior). > So the issue I have is that it describes the processing like this routing needs to occur in the bottom of the RTP protocol implementation. If I would utilize any of my implementations for WebRTC that would not work. Because I do the association on the upper API of the RTP implementation. So it becomes a question of knowing where the RTP stream, i.e. the RTP packets with a particular SSRC should be delivered to. Thus, see a need for generalized formulation that doesn't dictates how one implements one RTP stack in relation to the routing. I have continued working on a proposal for this text to something that I think covers all the cases of the current -18 appendix B text for RTP. I am still working on the RTCP text. I would also like to note that this text is intended for BUNDLE. I think there are still need for some text for JSEP. Especially if we want to include anything about on the various different RTCP extensions in use. Because, I think it doesn't make sense for BUNDLE to dive into all of the various RTCP feedback formats etc that RTCWeb includes, some examples of the principle should be sufficient. Then JSEP could select to expand on that. 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description As described in [RFC3550], RTP packets are associated with RTP streams [RFC7656]. Each RTP stream is identified by an SSRC value, and each RTP packet carries an SSRC value that is used to associate the packet with the correct RTP stream. RTCP packets also uses SSRCs to identify on which RTP streams any report or feedback relate to. Thus, an RTCP packet will commonly carry multiple SSRC values, and might therefore be providing feedback or report on multiple RTP streams. In order to be able to process received RTP/RTCP packets correctly it must be possible to associate an RTP stream with the correct "m=" line, as the "m=" line and SDP attributes associated with the "m=" line contain information needed to process the packets. As all RTP streams associated with a BUNDLE group are part of the same RTP session and using the same address:port combination for sending and receiving RTP/RTCP packets, the local address:port combination cannot be used to associate an RTP stream with the correct "m=" line. In addition, multiple RTP streams might be associated with the same "m=" line. Also, as described in Section 10.1.1, the same payload type value might be used by multiple RTP streams, in which case the payload type value cannot be used to associate an RTP stream with the correct "m=" line. However, there are cases where each "m=" line has unique payload type values, and then the payload type could serve as indicator to the relevant "m=" line the RTP stream is associated with. An offerer and answerer can inform each other which SSRC values they will use for an RTP stream by using the SDP 'ssrc' attribute [RFC5576]. However, an offerer will not know which SSRC values the answerer will use until the offerer has received the answer providing that information. Due to this, before the offerer has received the answer, the offerer will not be able to associate an RTP stream with the correct "m=" line using the SSRC value associated with the RTP stream. In addition, the offerer and answerer may start using new SSRC values mid-session, without informing each other using the SDP 'ssrc' attribute. In order for an offerer and answerer to always be able to associate an RTP stream with the correct "m=" line, the offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 14, where the offerer and answerer includes the identification-tag (provided by the remote peer) associated with an "m=" line in the RTP Streams and in RTCP SDES packets part of a BUNDLE group. The mapping from an SSRC to an identification-tag is carried in RTCP SDES packets or in RTP header extensions (Section 14). Since a compound RTCP packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, an RTCP packet can contain several SSRC to identification-tag mappings. The offerer and answerer maintain tables mapping RTP streams identified by SSRC to "m=" lines identified by the identification-tag. These tables are updated each time new information that affects how packets should be processed and routed are received. To prepare for demultiplexing RTP streams to the correct "m=" line, the following steps MUST be followed for each BUNDLE group based on the SDP signalling information. Construct a table mapping MID to "m=" line for each "m=" line in this BUNDLE group. Note that an "m=" line may only have one MID. Construct a table mapping incoming RTP streams (SSRCs) to their "m=" line for each "m=" line in this BUNDLE group and for each RTP stream explicitly signalled for receiving in that "m=" line. Construct a table mapping payload types to "m=" line for each "m=" line in the BUNDLE group and for each payload type configured for receiving in that "m=" line. If any payload type is configured for receiving in more than one "m=" line in the BUNDLE group, do not it include it in the table. Note that for each of these tables, there can only be one mapping for any given key (MID, SSRC, or PT). In other words, the tables are not multimaps. As "m=" lines are added or removed from the BUNDLE groups, or their configurations are changed, the tables above MUST also be updated. Received RTP packets that are syntactically correct are processed by the RTP/RTCP protocol implementation for statistics etc. After this processing they need to be routed to the higher layer context associated with the "m=" line within the BUNDLE group. Somewhere in the process where an received RTP packet is processed to be delivered to the higher layer by RTP the matching step below MUST be performed: 1. Reception of an RTP packet for an RTP stream that has an existing mapping in the RTP stream to m= line table. Before proceeding in delivering the packet to the higher layer context according to the RTP stream to "m=" line mapping table the following checks MUST be performed: A. If the packet carries an RTP header extension with a SDES MID value that is not in the table mapping MID to "m=" line, then do not deliver the RTP packet to higher layers. B. If the packet carries an RTP header extension with a SDES MID value that is in the table mapping MID to "m=" line, and the value indicates a different "m=" line than the current RTP stream to "m=" line mapping table, then update the RTP stream to "m=" line mapping. 2. Reception of an RTP packet for an RTP stream that has no existing mapping to an m= line. In this case the following actions MUST be performed: A. If the packet carries an RTP header extension with a SDES MID value that is in the table mapping MID to "m=" line, then create an entry in the RTP stream to "m=" line mapping table for this RTP stream (SSRC). Then deliver the RTP packet to the "m=" line context of the created mapping and stop. B. If the packet carries a Payload Type that is in the payload type table, then create an entry in the RTP stream to "m=" line mapping table for this RTP stream (SSRC). Then deliver the RTP packet to the "m=" line context of the created mapping and stop. C. Otherwise do not deliver the RTP packet to higher layers. Note, this includes unknown MID values. [Here the RTCP part will be added later] Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jan 23 05:02:33 2017 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 6F95B1295EE for ; Mon, 23 Jan 2017 05:02:32 -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, 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 bsq15Cg_aEJz for ; Mon, 23 Jan 2017 05:02:26 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 45C59129B4A for ; Mon, 23 Jan 2017 05:02:26 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-02-5885fee0a8ef Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 0B.6E.25710.0EEF5885; Mon, 23 Jan 2017 14:02:24 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.319.2; Mon, 23 Jan 2017 13:57:14 +0100 To: Bernard Aboba , "rtcweb@ietf.org" References: From: Magnus Westerlund Message-ID: <4dd0c2a6-d668-8383-416a-c76034f1ad5b@ericsson.com> Date: Mon, 23 Jan 2017 13:57:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM2K7k+6Df60RBou/C1ts2Pef2WLtv3Z2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSuj9ZdDwV3DihWNCg2M/apdjJwcEgImErO2 3mPqYuTiEBJYxyjR+3sHM4SznFHizNavbCBVwgKOEt/aZjGD2CICQRJtXQsZQWwhgQCJqzvu gcXZBCwkbv5oBKvnFbCX+DttH1icRUBV4vPX3ywgtqhAjMTb9cvZIWoEJU7OfAIU5+DgFAiU +LTYBcRkBmp9sLUMpIJZQF6ieetsZohN2hINTR2sExj5ZyFpnoXQMQtJxwJG5lWMosWpxcW5 6UbGeqlFmcnFxfl5enmpJZsYgWF3cMtv3R2Mq187HmIU4GBU4uE1YGyNEGJNLCuuzD3EKMHB rCTC+/IdUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQZG t8q1N2w1NRyST8zPtKi8sOaj6ZKHqxRD1tzz2/7mo8WS9gSHhvatuS8qPv5et/3RNyZLd61k 2zjtmJTuT9O+hWophrnsCI496PZM8p6+oTkDS3297Z/KmRa2G6ujrEui0kKtrzP57Upznr9l uZYl+6aTDxv3Xf56ojbuXty5v9zWp57NnSCmxFKckWioxVxUnAgAaJGlNDcCAAA= Archived-At: Subject: Re: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets 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: Mon, 23 Jan 2017 13:02:32 -0000 Hi Bernard, I think one important aspect here is that it doesn't make sense to put all possible RTCP formats into BUNDLES text on demultiplexing RTCP. I think what is needed in BUNDLE is the general principle and some examples. To my understanding we have a couple of different principles in RTCP when it comes to SSRCs. 1. Statements. The sourcing endpoint simply states that this applies for the following SSSRC. This is true for SDES, RTCP SR (sender report part). And this applies to RTP streams being received by the endpoint. 2. Reporting: Report Blocks in SR or RR which states. I am X and here is my report on Y. Where each block has an SSRC. This is also true for the Feedback format. Which is either single target, i.e. FB formats SSRCS are both valid, from who and who the target for the feedback is. Multi FCI where the Target SSRC is at the FCI level is a variant more similar to the report block. So what is of interest is first of all any feedback or reporting on the RTP streams the endpoint sends. Thus, the outgoing SSRCs for a media description is what is of primary interest. Then there could exist secondary interest for feedback other provides, i.e. that the target SSRC is for other endpoints RTP Streams. This should normally only occur in RTP sessions for some specific topologies, like multicast based or interconnects to such where the RTP middlebox doesn't filter away such messages. 3. Unspecified receiver. The APP packet is one of those that only have a source, and thus who is the consumer on the endpoint is not clear without looking into the information on a deeper level. I would also note that implementation variations and how the API between the higher layers and the RTP/RTCP protocol implementation will highly affect how one interacts. I have done implementation which has both poll and rule based subscription to information updates or feedback events. There is also the question of how one on the RTCP side best expresses the mapping between the RTPTranscivers and the BUNDLE media description. Cheers Magnus Den 2017-01-21 kl. 01:21, skrev Bernard Aboba: > It has been pointed out to me that the text in JSEP Appendix B does not > include text relating to the routing of RTCP XR packets, described in > RFC 3611. > > Since RTCP XR packets include report blocks with different formats > coming up with appropriate text is challenging. > > For example, the following text covers Loss RLE Report Blocks (Section > 4.1), Duplicate RLE Report Blocks (Section 4.2), Packet Receipt Times > Report Blocks (Section 4.3), Statistics Summary Report Blocks (Section > 4.6) and VoIP Metric Report Blocks (Section 4.7): > > If the packet is of type XR with a BT of 1 (Loss RLE Report Block), 2 > (Duplicate RLE Report > Block), 3 (Packet Receipt Times Report Block), 6 (Statistics Summary > Report Block), > 7 (VoIP Metric Report Block), for each report block in the packet > whose "SSRC of source" > is found in the outgoing SSRC table, deliver a copy of the RTCP > packet to the > "m=" line associated with that SSRC. > > However, RFC 3611 also includes the Receiver Reference Report Block > (Section 4.4) whose format looks like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=4 | reserved | block length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NTP timestamp, most significant word | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NTP timestamp, least significant word | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Should this be forwarded to the RtpSender whose outgoing SSRC table that > matches the > "SSRC" field in the RTCP XR packet? > > > There is also is the DLRR Report Block (Section 4.5) whose format looks > like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=5 | reserved | block length | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | SSRC_1 (SSRC of first receiver) | sub- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block > | last RR (LRR) | 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | delay since last RR (DLRR) | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | SSRC_2 (SSRC of second receiver) | sub- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block > : ... : 2 > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > > > For this one, I'm assuming that the SSRC of Nth receiver field is > matched against the > ssrc_table to determine the appropriate RtpReceivers to receive a copy > of the RTCP packet. > > There are of course other RTCP XR RFCs. I have not reviewed those yet. > But before doing that, I'd like to get some feedback on whether the > general approach outlined above is sane (or whether parsing individual > RTCP XR report blocks is a bad idea to begin with). > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jan 23 05:41:51 2017 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 6F99B129602 for ; Mon, 23 Jan 2017 05:41:49 -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, 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 Zukre16nsII2 for ; Mon, 23 Jan 2017 05:41:48 -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 337C41295F9 for ; Mon, 23 Jan 2017 05:41:48 -0800 (PST) X-AuditID: c1b4fb3a-d001d98000007c71-fe-5886081adc6f Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id FD.88.31857.A1806885; Mon, 23 Jan 2017 14:41:46 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.319.2; Mon, 23 Jan 2017 14:38:09 +0100 To: Eric Rescorla , Christer Holmberg References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> From: Magnus Westerlund Message-ID: <75948684-0632-9a98-86a1-3d0b5b6b5119@ericsson.com> Date: Mon, 23 Jan 2017 14:38:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM2J7lK4UR1uEwYtdkhYrXp9jt1j7r53d gcljyZKfTB6TH7cxBzBFcdmkpOZklqUW6dslcGW0HNrDWrCIq2L2J9sGxiUcXYwcHBICJhKn j1Z0MXJxCAmsY5SYd+w0O4SznFFi89Y9LF2MnBzCAmESrRuOM4E0iADZa8/yQ9R8Y5I4u/Md E0gNs4CixJfl89lAbDYBC4mbPxrBbF4Be4kJj/4ygtgsAqoSZ15eA5spKhAj8Xb9cnaIGkGJ kzOfsIDM5xQIlLj7JAPEZAZqfbC1DGK6vETz1tnMILaQgLZEQ1MH6wRGgVlImmchdMxC0rGA kXkVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmA4Htzy22oH48HnjocYBTgYlXh4DRhbI4RY E8uKK3MPMUpwMCuJ8CoxtkUI8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1OzW1 ILUIJsvEwSnVwBhdbfzo0LNF3+/fqzyreOpWWZLr1oQ33N/mtkg4+d3pfmkvKDqrkydj2/Ju S5ZUybfzuU/+qzRjfFfSp/vy0sRZE0vOptuH7/QwteGrYVAQFfAW2DrLLH97UqpejkzkuaL2 443yBzalr2Pht7J2mxlpLmSV5i2iWjB/NY+xdwl79auZC26+VWIpzkg01GIuKk4EAC48JTJD AgAA Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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: Mon, 23 Jan 2017 13:41:49 -0000 Den 2017-01-20 kl. 23:19, skrev Eric Rescorla: > It's not big enough for every use case but it's in use for certain > limited use cases now. Hence the need to support PT now and MID in the > future Hi, I get worried by this text. I have accepted that PT mapping is a necessary function to deal with interop of non-WebRTC endpoints. However, I don't think MID is something a WebRTC endpoint can wait with implementing. BUNDLE mandates MID support, and if one doesn't implement it another WebRTC endpoint could attempt to use MIDs and don't provide different PTs for two bundled m= audio lines with PT reuse. So I hope that RTCWEB WG has no intention of softening the need for MID support? I think that would invite additional interoperability issues and hamper the evolution and usage of WebRTC. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jan 23 07:18:20 2017 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 1B72C12961E; Mon, 23 Jan 2017 07:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 Dek9RT9NV20f; Mon, 23 Jan 2017 07:18:13 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA003129615; Mon, 23 Jan 2017 07:18:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B25B27C51BC; Mon, 23 Jan 2017 16:18:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-h6vtJKTqvE; Mon, 23 Jan 2017 16:18:08 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4C42F7C51B9; Mon, 23 Jan 2017 16:18:08 +0100 (CET) To: mmusic@ietf.org References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> From: Harald Alvestrand Message-ID: <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> Date: Mon, 23 Jan 2017 16:18:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Modifying an approved document: MSID 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: Mon, 23 Jan 2017 15:18:15 -0000 Den 19. jan. 2017 13:31, skrev Harald Alvestrand: > Ted pointed out to me that I sent this to the wrong group. > > Chairs and members, please advise. My proposed change is here: https://github.com/alvestrand/rtcweb-msid/pull/16 The filed issue is here: https://github.com/alvestrand/rtcweb-msid/issues/15 (CCing RTCWEB - please keep discussion, if any, on mmusic) > > > > -------- Forwarded Message -------- > Subject: [rtcweb] Modifying an approved document: MSID > Date: Wed, 18 Jan 2017 23:22:14 +0100 > From: Harald Alvestrand > To: rtcweb@ietf.org > > > > When reviewing the implications of the PeerConnection API change to > support AddTrack rather than AddStream, I found an issue. > > This issue concerns draft-ietf-rtcweb-msid, which is currently in > REF-WAIT state (I believe). > > The issue is that it is possible to add a track without specifying a > stream. Since the track's ID needs to be carried, we have to send an > "a=msid" line, but the track's ID is the *second* field on that line, > with the first being the stream's ID. > > This creates a problem. > > Suggested fix: Insert two lines in the document: > > 1) On SDP generation: > > "If there is no stream associated with the track, use the reserved ID > value '-'" > > 2) On SDP parsing > > "If the stream ID is the reserved value '-', the track is not associated > with a stream, and no stream is signalled or created." > > If this is OK with the community, I'll issue an updated draft with this > change. > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > 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 > From nobody Mon Jan 23 15:24:56 2017 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 B387D129415 for ; Mon, 23 Jan 2017 15:24:53 -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=ham 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 6w3ii1jesAxW for ; Mon, 23 Jan 2017 15:24:52 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 1E2F4129409 for ; Mon, 23 Jan 2017 15:24:52 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id 123so92234546ybe.3 for ; Mon, 23 Jan 2017 15:24:52 -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=ebMIw2Th9DAmWMI+RhiNEvH+ZjXeVlj0ypFE3s7eMuk=; b=ppIEH5erQ3bgclhWDW+e39eUD5EbR6R/5G5sDVav+uSrxQVVnzyh5yH3V0n9zggnSd Fk5Bd8w56l6Pwde2b5HmiCDyb1uBBA2QfsOxiJ11ZvvmtJPHv4n2hkIIbDwI0u7YhpM1 qwjn152KYls5cxlkTZT5GEVAUzif8Fp8yhjAcaz+DMOGfDMZNWYWs+BNGYKeT6VRH5rX tZrVN08nhWSD1awCZyyIq7s5WpZiE7YudejTfOG2jnqGw4A/fyHjjJYujAcbJeQO4mGM EvpVXic7Sm1/AGTmg8p93Bun2r+4e4v02CrTbXo+jxV+zxupui1xyxDWRKFEjyYgH/84 TTeQ== 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=ebMIw2Th9DAmWMI+RhiNEvH+ZjXeVlj0ypFE3s7eMuk=; b=H7v6Nl7Fo75PYZOkw3k/bPIZuKGqnJqdGkmPVCf1svAX8PoE9+SanHXv75LWHD9sAJ iXo4JENfdSQltrPzdOcSA3vglTsExmJUHwmyrhbeXuXeue8M1mCD0eblDb0LmFkFgz/l KEsNBOAnGgXG4kFz5qfK6M/pcpThIRXtC3BhRog3Qv+y725gM//rTBAKrQsZbKrWNrYn oiTIvvzscmHpwNHuGClKX1JOgJb6V1e8w94ssMJkmTADDS/EhgKe/J18d7JK/rX668ub TwLAE8FXVmwiOQ2OIRQFP7JHupbPNHLCunxL5/w+QksWy9Z7dE7buf3P85cHP3g6y9mu yqfQ== X-Gm-Message-State: AIkVDXKDvNIIwXFGX+UIs2J1NXpWJ9PIT/aQwTUPuZDcXn1r9oOf1XAZA9jPcxNgh24RFWekvic/1bJ/Z+LulA== X-Received: by 10.37.201.196 with SMTP id z187mr23546512ybf.161.1485213891245; Mon, 23 Jan 2017 15:24:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 23 Jan 2017 15:24:10 -0800 (PST) In-Reply-To: <75948684-0632-9a98-86a1-3d0b5b6b5119@ericsson.com> References: <734d7532-d795-5be6-3bdd-bdc45ef8525b@ericsson.com> <75948684-0632-9a98-86a1-3d0b5b6b5119@ericsson.com> From: Eric Rescorla Date: Mon, 23 Jan 2017 15:24:10 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a114d88ea67ed9c0546cb4e69 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] Working group last call resolutions/Consensus call: Appendix B 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: Mon, 23 Jan 2017 23:24:54 -0000 --001a114d88ea67ed9c0546cb4e69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 23, 2017 at 5:38 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2017-01-20 kl. 23:19, skrev Eric Rescorla: > >> It's not big enough for every use case but it's in use for certain >> limited use cases now. Hence the need to support PT now and MID in the >> future >> > > Hi, > > I get worried by this text. I have accepted that PT mapping is a necessar= y > function to deal with interop of non-WebRTC endpoints. However, I don't > think MID is something a WebRTC endpoint can wait with implementing. BUND= LE > mandates MID support, and if one doesn't implement it another WebRTC > endpoint could attempt to use MIDs and don't provide different PTs for tw= o > bundled m=3D audio lines with PT reuse. > > So I hope that RTCWEB WG has no intention of softening the need for MID > support? I think that would invite additional interoperability issues and > hamper the evolution and usage of WebRTC. That's not what I'm saying. I'm simply saying that we are not in a world where it is going to MID only and will not be for quite some time. -Ekr > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a114d88ea67ed9c0546cb4e69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 23, 2017 at 5:38 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Den 2017-01-20 kl. 23:19, skrev Eric Rescorla:
It's not big enough for every use case but it's in use for certain<= br> limited use cases now. Hence the need to support PT now and MID in the
future

 Hi,

I get worried by this text. I have accepted that PT mapping is a necessary = function to deal with interop of non-WebRTC endpoints. However, I don't= think MID is something a WebRTC endpoint can wait with implementing. BUNDL= E mandates MID support, and if one doesn't implement it another WebRTC = endpoint could attempt to use MIDs and don't provide different PTs for = two bundled m=3D audio lines with PT reuse.

So I hope that RTCWEB WG has no intention of softening the need for MID sup= port? I think that would invite additional interoperability issues and hamp= er the evolution and usage of WebRTC.

That&= #39;s not what I'm saying. I'm simply saying that we are not in a w= orld where it is going to MID only and will not be for quite some time.

-Ekr
=C2=A0


Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=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| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----


--001a114d88ea67ed9c0546cb4e69-- From nobody Tue Jan 24 16:49:53 2017 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 C7CA51295D8 for ; Tue, 24 Jan 2017 16:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 UDt0rjx2Ka8F for ; Tue, 24 Jan 2017 16:49:45 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 302261295DA for ; Tue, 24 Jan 2017 16:49:44 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id x75so124353139vke.2 for ; Tue, 24 Jan 2017 16:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GImZhNLhVF7uUmeFlDglMWH7m9vTxWGjaY4JiAkxgfI=; b=CfbTy/ibrGGH65t70tulpgWfgA7DQhIJEky3E1Xo7uokpguPVxXdUdjwr5DncNod/Y uEYCeWxbqM8Y1LquivY9q7uIK+LorTe4+MX9FzU9Wt7jKx1tQ/DhWP+OsMwAX1B6247h 81UgelRJKRcNdlLkK5NLdmJDnUh8nCovcdWEumuLynVt6T+tg3EcOP1qXZPIhXl4cPv/ enX8hjQGIKo4FYT8UZLtrqrsNMAGxcawNqktAHXtj/sY/rlXLvGUIWlhks1q2BKJ7gJv KWgFp43eMng6vx2f5XmxziD16Y0OkSvwqeQghFVa6boDAZbCzr63RnLTnsEM9foPsq+L l6Fw== 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=GImZhNLhVF7uUmeFlDglMWH7m9vTxWGjaY4JiAkxgfI=; b=A7BBkBtVpwlRLElFPlQrO+uaNvNZHdGvHg7zhi0qdAKQV1uRsxVPWz4xka4LPicsMs /SdD/0A9qrDHrJqf/fGLd35U/JLxRd5KbmBwQuZOvDkUAR4uda4k32+jmiaHrde3JPWh xGlKqskigeUwAGEJe8R28jIBT7ASlHAhXJB48UkipfJS94ZqVOIHH/hjQmPiT55jFVCD 4kSmHPnkwOm8ZoVCsc3efkpLGe8ySQ+/va+SA7pJ+NW8X7aO+rDQAjvZpBPIJGEdPiFZ Nqavv6YfhOuyANcpM/tUwRMXei3vKfO3n1L295Z47NFs67lySR+LAw9wwuJUGVq0FTlh P+qA== X-Gm-Message-State: AIkVDXJkpAuu7v6VquO9fYoH/QbxCjAg4pFZU9sOJFAHdEDebRdUjIs/5vKvpJAsscoUbaIwQWj0qgoBq6my7A== X-Received: by 10.31.134.200 with SMTP id i191mr18068484vkd.57.1485305383144; Tue, 24 Jan 2017 16:49:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.37 with HTTP; Tue, 24 Jan 2017 16:49:22 -0800 (PST) In-Reply-To: <4dd0c2a6-d668-8383-416a-c76034f1ad5b@ericsson.com> References: <4dd0c2a6-d668-8383-416a-c76034f1ad5b@ericsson.com> From: Bernard Aboba Date: Tue, 24 Jan 2017 16:49:22 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a114395babed9a60546e09b07 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets 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, 25 Jan 2017 00:49:47 -0000 --001a114395babed9a60546e09b07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Magnus said: "we have a couple of different principles in RTCP when it comes to SSRCs...= " Thanks. I tried to encapsulate this in the following PR: https://github.com/rtcweb-wg/jsep/pull/530 On Mon, Jan 23, 2017 at 4:57 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi Bernard, > > I think one important aspect here is that it doesn't make sense to put al= l > possible RTCP formats into BUNDLES text on demultiplexing RTCP. I think > what is needed in BUNDLE is the general principle and some examples. > > To my understanding we have a couple of different principles in RTCP when > it comes to SSRCs. > > 1. Statements. The sourcing endpoint simply states that this applies for > the following SSSRC. This is true for SDES, RTCP SR (sender report part). > And this applies to RTP streams being received by the endpoint. > > 2. Reporting: Report Blocks in SR or RR which states. I am X and here is > my report on Y. Where each block has an SSRC. This is also true for the > Feedback format. Which is either single target, i.e. FB formats SSRCS are > both valid, from who and who the target for the feedback is. Multi FCI > where the Target SSRC is at the FCI level is a variant more similar to th= e > report block. So what is of interest is first of all any feedback or > reporting on the RTP streams the endpoint sends. Thus, the outgoing SSRCs > for a media description is what is of primary interest. Then there could > exist secondary interest for feedback other provides, i.e. that the targe= t > SSRC is for other endpoints RTP Streams. This should normally only occur = in > RTP sessions for some specific topologies, like multicast based or > interconnects to such where the RTP middlebox doesn't filter away such > messages. > > 3. Unspecified receiver. The APP packet is one of those that only have a > source, and thus who is the consumer on the endpoint is not clear without > looking into the information on a deeper level. > > > I would also note that implementation variations and how the API between > the higher layers and the RTP/RTCP protocol implementation will highly > affect how one interacts. I have done implementation which has both poll > and rule based subscription to information updates or feedback events. > > There is also the question of how one on the RTCP side best expresses the > mapping between the RTPTranscivers and the BUNDLE media description. > > Cheers > > Magnus > > > > Den 2017-01-21 kl. 01:21, skrev Bernard Aboba: > >> It has been pointed out to me that the text in JSEP Appendix B does not >> include text relating to the routing of RTCP XR packets, described in >> RFC 3611. >> >> Since RTCP XR packets include report blocks with different formats >> coming up with appropriate text is challenging. >> >> For example, the following text covers Loss RLE Report Blocks (Section >> 4.1), Duplicate RLE Report Blocks (Section 4.2), Packet Receipt Times >> Report Blocks (Section 4.3), Statistics Summary Report Blocks (Section >> 4.6) and VoIP Metric Report Blocks (Section 4.7): >> >> If the packet is of type XR with a BT of 1 (Loss RLE Report Block), 2 >> (Duplicate RLE Report >> Block), 3 (Packet Receipt Times Report Block), 6 (Statistics Summary >> Report Block), >> 7 (VoIP Metric Report Block), for each report block in the packet >> whose "SSRC of source" >> is found in the outgoing SSRC table, deliver a copy of the RTCP >> packet to the >> "m=3D" line associated with that SSRC. >> >> However, RFC 3611 also includes the Receiver Reference Report Block >> (Section 4.4) whose format looks like this: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | BT=3D4 | reserved | block length =3D 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | NTP timestamp, most significant word | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | NTP timestamp, least significant word | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Should this be forwarded to the RtpSender whose outgoing SSRC table that >> matches the >> "SSRC" field in the RTCP XR packet? >> >> >> There is also is the DLRR Report Block (Section 4.5) whose format looks >> like this: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | BT=3D5 | reserved | block length | >> +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ >> | SSRC_1 (SSRC of first receiver) | sub- >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block >> | last RR (LRR) | 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | delay since last RR (DLRR) | >> +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ >> | SSRC_2 (SSRC of second receiver) | sub- >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block >> : ... : 2 >> +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ >> >> >> >> For this one, I'm assuming that the SSRC of Nth receiver field is >> matched against the >> ssrc_table to determine the appropriate RtpReceivers to receive a copy >> of the RTCP packet. >> >> There are of course other RTCP XR RFCs. I have not reviewed those yet. >> But before doing that, I'd like to get some feedback on whether the >> general approach outlined above is sane (or whether parsing individual >> RTCP XR report blocks is a bad idea to begin with). >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a114395babed9a60546e09b07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Magnus said:=C2=A0

"we have a coup= le of different principles in RTCP when it comes to SSRCs..."

Thanks. I tried to encapsulate this in the following PR:= =C2=A0

<= div class=3D"gmail_extra">
On Mon, Jan 23, 20= 17 at 4:57 AM, Magnus Westerlund <magnus.westerlund@ericsson.= com> wrote:
Hi Bernard,

I think one important aspect here is that it doesn't make sense to put = all possible RTCP formats into BUNDLES text on demultiplexing RTCP. I think= what is needed in BUNDLE is the general principle and some examples.

To my understanding we have a couple of different principles in RTCP when i= t comes to SSRCs.

1. Statements. The sourcing endpoint simply states that this applies for th= e following SSSRC. This is true for SDES, RTCP SR (sender report part). And= this applies to RTP streams being received by the endpoint.

2. Reporting: Report Blocks in SR or RR which states. I am X and here is my= report on Y. Where each block has an SSRC. This is also true for the Feedb= ack format. Which is either single target, i.e. FB formats SSRCS are both v= alid, from who and who the target for the feedback is. Multi FCI where the = Target SSRC is at the FCI level is a variant more similar to the report blo= ck. So what is of interest is first of all any feedback or reporting on the= RTP streams the endpoint sends. Thus, the outgoing SSRCs for a media descr= iption is what is of primary interest. Then there could exist secondary int= erest for feedback other provides, i.e. that the target SSRC is for other e= ndpoints RTP Streams. This should normally only occur in RTP sessions for s= ome specific topologies, like multicast based or interconnects to such wher= e the RTP middlebox doesn't filter away such messages.

3. Unspecified receiver. The APP packet is one of those that only have a so= urce, and thus who is the consumer on the endpoint is not clear without loo= king into the information on a deeper level.


I would also note that implementation variations and how the API between th= e higher layers and the RTP/RTCP protocol implementation will highly affect= how one interacts. I have done implementation which has both poll and rule= based subscription to information updates or feedback events.

There is also the question of how one on the RTCP side best expresses the m= apping between the RTPTranscivers and the BUNDLE media description.

Cheers

Magnus



Den 2017-01-21 kl. 01:21, skrev Bernard Aboba:
It has been pointed out to me that the text in JSEP Appendix B does not
include text relating to the routing of RTCP XR packets, described in
RFC 3611.

Since RTCP XR packets include report blocks with different formats
coming up with appropriate text is challenging.

For example, the following text covers Loss RLE Report Blocks (Section
4.1), Duplicate RLE Report Blocks (Section 4.2), Packet Receipt Times
Report Blocks (Section 4.3), Statistics Summary Report Blocks (Section
4.6) and VoIP Metric Report Blocks (Section 4.7):

=C2=A0 =C2=A0If the packet is of type XR with a BT of 1 (Loss RLE Report Bl= ock), 2
(Duplicate RLE Report
=C2=A0 =C2=A0Block),=C2=A0 3 (Packet Receipt Times Report Block), 6 (Statis= tics Summary
Report Block),
=C2=A0 7 (VoIP Metric Report Block), for each report block in the packet whose "SSRC of source"
=C2=A0 =C2=A0is found in the outgoing SSRC table, deliver a copy of the RTC= P
packet to the
=C2=A0 =C2=A0"m=3D" line associated with that SSRC.

However, RFC 3611 also includes the Receiver Reference Report Block
(Section 4.4) whose format looks like this:

=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A03
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0BT=3D4=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= reserved=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0block length =3D 2=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 NTP timestam= p, most significant word=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 =C2=A0 =C2=A0NTP timestamp= , least significant word=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+



Should this be forwarded to the RtpSender whose outgoing SSRC table that matches the
"SSRC" field in the RTCP XR packet?


There is also is the DLRR Report Block (Section 4.5) whose format looks
like this:

=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
=C2=A0|=C2=A0 =C2=A0 =C2=A0BT=3D5=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0reserve= d=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0block length=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC_1= (SSRC of first receiver)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| sub-
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+ block
=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=A0last RR (LRR)=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=A01
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0delay since last RR (DLRR)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+
=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC_2= (SSRC of second receiver)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = | sub-
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+ block
=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 =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:=C2=A0 =C2=A02
=C2=A0+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+



For this one, I'm assuming that the SSRC of Nth receiver field is
matched against the
ssrc_table to determine the appropriate RtpReceivers to receive a copy
of the RTCP packet.

There are of course other RTCP XR RFCs.=C2=A0 I have not reviewed those yet= .
But before doing that, I'd like to get some feedback on whether the
general approach outlined above is sane (or whether parsing individual
RTCP XR report blocks is a bad idea to begin with).


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


--

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=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| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----


--001a114395babed9a60546e09b07-- From nobody Wed Jan 25 02:06:42 2017 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 C8355129863 for ; Wed, 25 Jan 2017 02:06:41 -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, 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 pe6mhuv7-DVW for ; Wed, 25 Jan 2017 02:06:40 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 13BC212988F for ; Wed, 25 Jan 2017 02:06:39 -0800 (PST) X-AuditID: c1b4fb2d-a87ff70000007e3d-85-588878add884 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 4D.C1.32317.DA878885; Wed, 25 Jan 2017 11:06:38 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.319.2; Wed, 25 Jan 2017 11:06:37 +0100 To: Bernard Aboba References: <4dd0c2a6-d668-8383-416a-c76034f1ad5b@ericsson.com> From: Magnus Westerlund Message-ID: Date: Wed, 25 Jan 2017 11:06:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7tO66io4Ig92v+S027PvPbLH2Xzu7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXRP2UJc8GUmIoVW0IaGGc4dTFyckgImEjs WtTKDGILCaxjlJi8Tb+LkQvIXs4o8WvhbxaQhLCAo8S3tllgRSIC2hJ93/YxQRSdZZS4+f8R I0iCWUBd4s7ic+wgNpuAhcTNH41sXYwcHLwC9hLnrmuDhFkEVCV+HFoNNkdUIEbi7frlYOW8 AoISJ2c+AdvFKRAo8f1HMwvESAuJmfPPQ42Xl2jeOhvqUG2JhqYO1gmMArOQtM9C0jILScsC RuZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIFBeXDLb90djKtfOx5iFOBgVOLh/ZDdHiHE mlhWXJl7iFGCg1lJhNcxtyNCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2amp BalFMFkmDk6pBsYpK0wTq5KPmyjVih3nv7t51tSl179V3S7bfWL1uV3Pg9d9+R7DdqJLW1r1 pYT9wXLGS94xe6X5ixkmH7ggz7Wj08BqyoYYH+4pzzb8MbTucfyq+3YGr4Djs90J1xnOPxe+ rr9P7U5wrmRVz0zZ1kOP8hbIHUsM+fbW22npxhUvtPa86vXemT5fiaU4I9FQi7moOBEAJCsS dEYCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets 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, 25 Jan 2017 10:06:41 -0000 Den 2017-01-25 kl. 01:49, skrev Bernard Aboba: > Magnus said: > > "we have a couple of different principles in RTCP when it comes to SSRCs..." > > Thanks. I tried to encapsulate this in the following PR: > > https://github.com/rtcweb-wg/jsep/pull/530 I looked at the PR. So on the very basic level this would clearly be sufficient. However, it might have significant duplication of the processing for the higher layer due to the this sentence "sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the packet to the "m=" line associated with that SSRC." The above will result in that each RTCP XR will be first forward in its entirety to the "m=" line that receives the SSRC that the peer endpoint uses for reporting. Then for all RTCP XR report blocks that contains SSRC of source or corresponding and has a SSRC value corresponding to a by this endpoint sent RTP stream, the individual report block will be delivered to that RTP streams "m=" line. There exist a possibility that one receives report block reporting on RTP streams sent by other endpoints, i.e. RTP streams that are part of the incoming RTP stream to m= line mapping table. These third party report may be useful to confirm that also others see issues with delivery etc of an incoming stream. However, but any differences in report may be due to the difference in path between the RTP stream source and the endpoint sending this report, and the path the local endpoint sees. Also for SFM and RTP mixers, these third party reports normally makes no sense as the RTP streams received by the different participants from the same media source are not the same due to per endpoint specific forwarding of RTP stream decisions. Thus they need to be suppressed by the RTP middlebox. To me it appears reasonable that third party reports are processed in the same context that considers the local statistics for the corresponding incoming RTP stream when they occur, which should be rarely. Thus, the need for the above quoted rule is dependent on if there exist RTCP XR report blocks that is not tightly couple to an RTP stream and thus can't be processed in the m= line context that originates or receives the RTP stream? In RFC 3611 the ones that has this aspect is the Receiver Reference Time Report Block (Section 4.4). However, at the same time I see very little meaning of forwarding this to the higher layers. This report block combined with DLRR (Section 4.5) is a mechanism that is either turned on in the RTP session or not. It is the RTP stack that must do the processing of any incoming RRT to enable the sending of the DLRR for that SSRC. And if the local endpoint originates RTT, then the interesting outcome is the resulting RTT measurement between this local endpoint and the peer. I have not looked at all the report blocks in the registry: http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xhtml#rtcp-xr-block-types-1 BT's XQN (RFC5093) lacks SSRC field, but that is likely a bug as it talks about sequence numbers, and thus need to reference an RTP Stream. There might be some additional, some random sampling indicated that most are after all reporting on a RTP stream in some sense. The example that doesn't it is not obvious that it is appropriate to route it to the higher layer of the m= line. Thus I wonder if this description will result in the duplication on the common case, and still not be the appropriate response for the few odd RTCP XR report blocks. I don't have an text change proposal at this point. Cheers Magnus > > On Mon, Jan 23, 2017 at 4:57 AM, Magnus Westerlund > > > wrote: > > Hi Bernard, > > I think one important aspect here is that it doesn't make sense to > put all possible RTCP formats into BUNDLES text on demultiplexing > RTCP. I think what is needed in BUNDLE is the general principle and > some examples. > > To my understanding we have a couple of different principles in RTCP > when it comes to SSRCs. > > 1. Statements. The sourcing endpoint simply states that this applies > for the following SSSRC. This is true for SDES, RTCP SR (sender > report part). And this applies to RTP streams being received by the > endpoint. > > 2. Reporting: Report Blocks in SR or RR which states. I am X and > here is my report on Y. Where each block has an SSRC. This is also > true for the Feedback format. Which is either single target, i.e. FB > formats SSRCS are both valid, from who and who the target for the > feedback is. Multi FCI where the Target SSRC is at the FCI level is > a variant more similar to the report block. So what is of interest > is first of all any feedback or reporting on the RTP streams the > endpoint sends. Thus, the outgoing SSRCs for a media description is > what is of primary interest. Then there could exist secondary > interest for feedback other provides, i.e. that the target SSRC is > for other endpoints RTP Streams. This should normally only occur in > RTP sessions for some specific topologies, like multicast based or > interconnects to such where the RTP middlebox doesn't filter away > such messages. > > 3. Unspecified receiver. The APP packet is one of those that only > have a source, and thus who is the consumer on the endpoint is not > clear without looking into the information on a deeper level. > > > I would also note that implementation variations and how the API > between the higher layers and the RTP/RTCP protocol implementation > will highly affect how one interacts. I have done implementation > which has both poll and rule based subscription to information > updates or feedback events. > > There is also the question of how one on the RTCP side best > expresses the mapping between the RTPTranscivers and the BUNDLE > media description. > > Cheers > > Magnus > > > > Den 2017-01-21 kl. 01:21, skrev Bernard Aboba: > > It has been pointed out to me that the text in JSEP Appendix B > does not > include text relating to the routing of RTCP XR packets, > described in > RFC 3611. > > Since RTCP XR packets include report blocks with different formats > coming up with appropriate text is challenging. > > For example, the following text covers Loss RLE Report Blocks > (Section > 4.1), Duplicate RLE Report Blocks (Section 4.2), Packet Receipt > Times > Report Blocks (Section 4.3), Statistics Summary Report Blocks > (Section > 4.6) and VoIP Metric Report Blocks (Section 4.7): > > If the packet is of type XR with a BT of 1 (Loss RLE Report > Block), 2 > (Duplicate RLE Report > Block), 3 (Packet Receipt Times Report Block), 6 (Statistics > Summary > Report Block), > 7 (VoIP Metric Report Block), for each report block in the packet > whose "SSRC of source" > is found in the outgoing SSRC table, deliver a copy of the RTCP > packet to the > "m=" line associated with that SSRC. > > However, RFC 3611 also includes the Receiver Reference Report Block > (Section 4.4) whose format looks like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=4 | reserved | block length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NTP timestamp, most significant word | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NTP timestamp, least significant word | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Should this be forwarded to the RtpSender whose outgoing SSRC > table that > matches the > "SSRC" field in the RTCP XR packet? > > > There is also is the DLRR Report Block (Section 4.5) whose > format looks > like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BT=5 | reserved | block length | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | SSRC_1 (SSRC of first receiver) > | sub- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > block > | last RR (LRR) > | 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | delay since last RR (DLRR) | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | SSRC_2 (SSRC of second receiver) > | sub- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > block > : ... > : 2 > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > > > For this one, I'm assuming that the SSRC of Nth receiver field is > matched against the > ssrc_table to determine the appropriate RtpReceivers to receive > a copy > of the RTCP packet. > > There are of course other RTCP XR RFCs. I have not reviewed > those yet. > But before doing that, I'd like to get some feedback on whether the > general approach outlined above is sane (or whether parsing > individual > RTCP XR report blocks is a bad idea to begin with). > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jan 26 05:54:19 2017 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 A1EB91295D8; Thu, 26 Jan 2017 05:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KdYejVclr4LF; Thu, 26 Jan 2017 05:54:12 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4908B1295D6; Thu, 26 Jan 2017 05:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2652; q=dns/txt; s=iport; t=1485438852; x=1486648452; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zOhJrrsxlHPExdvQUfJD3l1gW4WHyrUK8yCzW5qMmW4=; b=diszZyy/EnkSvJSqlnBmAJGahE1bkxgWFxhgC3a36HXJQvk3z5PVLJOW mPWWb9qlaKNzyUB4zV5e3k48Qbcw//tnFkXXRcI07G4lM2I/FQAgE3e6V keIrvJqZdOAS/WIVQK+ejV79DKLS8T7cjEcWoEGxfkueZkPX/PJUxr7F2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgAS/4lY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAR9hgQmfYJc7HwuFLkoCghxCFQECAQEBAQEBAWIohGk?= =?us-ascii?q?BAQEDAQEBNi8HCwULHAMBAgEuJygDBQYBDAYCAQEQiUAFCA6wNIpyAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWGS4IFjHkfBZAtiyOGZYsRgXeFEoMqhj6IJIpXNSK?= =?us-ascii?q?BLh0VO4Q8HIF/IjWIeQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,289,1477958400"; d="scan'208";a="375686560" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2017 13:54:11 +0000 Received: from [10.98.149.200] (bxb-fandreas-8817.cisco.com [10.98.149.200]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v0QDsAti025458; Thu, 26 Jan 2017 13:54:11 GMT To: Harald Alvestrand , mmusic@ietf.org References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Flemming Andreasen Message-ID: Date: Thu, 26 Jan 2017 08:54:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: [rtcweb] Change Alert [Re: [MMUSIC] Modifying an approved document: MSID] 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, 26 Jan 2017 13:54:13 -0000 Hi Harald Since the document is not yet in Auth48 and the change is relatively minor, it is possible to update it during Auth48. However, from an MMUSIC chair point of view, I would like to get positive confirmation from some of the stakeholders that this change is indeed desired. Similarly, if anybody has any concerns with the suggested change, please send an e-mail to that effect. Thanks -- Flemming (as MMUSIC co-chair) On 1/23/17 10:18 AM, Harald Alvestrand wrote: > Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >> Ted pointed out to me that I sent this to the wrong group. >> >> Chairs and members, please advise. > My proposed change is here: > > https://github.com/alvestrand/rtcweb-msid/pull/16 > > The filed issue is here: > > https://github.com/alvestrand/rtcweb-msid/issues/15 > > (CCing RTCWEB - please keep discussion, if any, on mmusic) > >> >> >> -------- Forwarded Message -------- >> Subject: [rtcweb] Modifying an approved document: MSID >> Date: Wed, 18 Jan 2017 23:22:14 +0100 >> From: Harald Alvestrand >> To: rtcweb@ietf.org >> >> >> >> When reviewing the implications of the PeerConnection API change to >> support AddTrack rather than AddStream, I found an issue. >> >> This issue concerns draft-ietf-rtcweb-msid, which is currently in >> REF-WAIT state (I believe). >> >> The issue is that it is possible to add a track without specifying a >> stream. Since the track's ID needs to be carried, we have to send an >> "a=msid" line, but the track's ID is the *second* field on that line, >> with the first being the stream's ID. >> >> This creates a problem. >> >> Suggested fix: Insert two lines in the document: >> >> 1) On SDP generation: >> >> "If there is no stream associated with the track, use the reserved ID >> value '-'" >> >> 2) On SDP parsing >> >> "If the stream ID is the reserved value '-', the track is not associated >> with a stream, and no stream is signalled or created." >> >> If this is OK with the community, I'll issue an updated draft with this >> change. >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> 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 >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Thu Jan 26 14:21:22 2017 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 0362A129C1A for ; Thu, 26 Jan 2017 14:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 ioe3H88D8K9r for ; Thu, 26 Jan 2017 14:21:19 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 BD0BE129C18 for ; Thu, 26 Jan 2017 14:21:18 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id x75so164530652vke.2 for ; Thu, 26 Jan 2017 14:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=4n4P0ynr43qF6OO9Ol6kYWR6lK4rJLRg5yDcFj9IsfE=; b=a46r9TLwJLPhSyU4niVwIUadalctDQel48b+DIB4NSdV961QxUzhI6dYnVNnpCgBwC upMzMgP1T0lT2V8NIc/721tVjejvZcZqjLsgSnCvM9dnyC7MnuJnpEiLFb1SWamq7+6S wwXOpJNlJ4DOT1Ek3V3AvruS9oSYp5kSleRmVJKrGcnZiT6bABUFsgkOtLYUrZ29P0zs M8z1GkSvcUM2cZKnVCqJ7tHvp/vwztBBz7hTYa0+9Dwa+4VcEWBE48Ldd9nyvUd21cWD F9AJPVE9hXxvncj8TElZIDGDiqlt2DVkoTHUVw3ogDO+IyMLRpSqUqVJzg3iIHQdmqmq RgUg== 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:cc; bh=4n4P0ynr43qF6OO9Ol6kYWR6lK4rJLRg5yDcFj9IsfE=; b=QhxpebRx3W4Q0ACPHtRhMXUxfTugp7zIznnyo0uMq/EFUBa/nFZ/iBJsBtnfphIHsf tE9/WEr5bIxEkO+QnW6KWRXlWSZp7nJBcWFVQOhSryIXl1ILYZF14q5Qrbp3a+DbXq4O s8z/sZEiw2UJbOX/8SpoDvF7pZPLl0RPKKKnzDaOOp+QBv4TBTsACJOsnIbAPChGfNZb 3iXHCznNAt0ZCSkf1yv3k7pYhdKB3FBgkordQlzmT0q+Z/jZa2qSKgdBtBf2GH067JEq tQaYpPKA6iiheCLGcbhBhyBxh7UnSf/DU0o7q79MoT+8uDXjDpHukmKa2r1GaCB7PJD+ MEtg== X-Gm-Message-State: AIkVDXLiU1GNmOoxrnRf2EBb7UYFpOt6yuhf0cTU4iVIrdgUDm4dA2YNkdra9RaHhlq6nKLPyhXDpN4O7mf/nw== X-Received: by 10.31.227.193 with SMTP id a184mr2683808vkh.106.1485469277772; Thu, 26 Jan 2017 14:21:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Thu, 26 Jan 2017 14:20:57 -0800 (PST) From: Bernard Aboba Date: Thu, 26 Jan 2017 14:20:57 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a114df80aa06303054706c402 Archived-At: Cc: "hta@google.com" Subject: [rtcweb] JSEP Section 5.4 Question 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, 26 Jan 2017 22:21:21 -0000 --001a114df80aa06303054706c402 Content-Type: text/plain; charset=UTF-8 In Section 5.4, JSEP says: " The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription." [BA] Does this mean that *any* change to description.sdp is unacceptable (e.g. byte for byte identical)? Or is the text trying to say that the parsed representation must be the same (e.g. "a=" lines appearing in a different order shouldn't matter)? This has come up in updating the WebRTC 1.0 API to make it compatible with the new JSEP text. --001a114df80aa06303054706c402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In Section 5.4, JSEP says:=C2=A0

"= The SDP returned fr= om createOffer or createAnswer MUST NOT be changed
=C2=A0 =C2=A0before passing i= t to setLocalDescription."

[BA] Does t= his mean that *any* change to description.sdp is unacceptable (e.g. byte fo= r byte identical)?=C2=A0

Or is the text trying to say that=C2= =A0the parsed representation must be the same (e.g. "a= =3D" lines appearing in a different order shouldn't matter)?

This has come up in updating the = WebRTC 1.0 API to make it compatible with the new JSEP text.
--001a114df80aa06303054706c402-- From nobody Thu Jan 26 14:40:45 2017 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 EF8B5129C1F for ; Thu, 26 Jan 2017 14:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7byUQ45mr9yR for ; Thu, 26 Jan 2017 14:40:42 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 8549A129C1C for ; Thu, 26 Jan 2017 14:40:42 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id x49so101348591qtc.2 for ; Thu, 26 Jan 2017 14:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YcoJUkESpLoyHXwU9PUz+dY1/r6MlQmEzb1fj6VdGnw=; b=Ns+I9w18GYkOath1kM6FcGMMbNYYhVa3/WgnzM/uTQZguvWd3RlwD96Lf0snLddeKO vA6Z6VdVRhDpJ7xZe+9q+Yd2H5KFXK8T9YstZlKhQo9V3pvWQASa5odrQuloj3Lo2Xby 3t1bwB2x1aPv+RDcYvNgUdgHdKG8a9FgD2ZaJ0HytLeJ4JVSs8flXoClcTe8VtMF57AC +u5BvggFanUtwAnvH+qdp5AKudcqxYr0OcYThKvCCThF4zYiSmE25kuayAhM5To7B77D vOtpYr5/+NKvikojAOpkLqOBydO53aMQWadH1jEq3QEGP8mKxVBfc45/xzsBzyko6pRY bFBA== 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=YcoJUkESpLoyHXwU9PUz+dY1/r6MlQmEzb1fj6VdGnw=; b=lJ4uVkQVfu2vjn4SVYOSFx1ivID6oHJ6OxIh7l3MnT1f5P1prx8YIkH9dJlFQm5RhN os5et3b4i7DRHkq+RXzD72SMyX/mLiYJI3smS2CPamCk9RzRF8i40jTZihkM1ZqWLKtL 0ep+OMwCOUmNMAsIrf2/hA2WYDjcV75nB32Uqmjuudxkdrg7zL57u1KOYsUUtxVBXojg j3YgfCfhvPb3Zd7hDsvdQVk3Veb1UFcQ/QnfH+K+iLTSO46KYoDPGQHlx5qOHubMi+kE NqdlAc5TA8ZHJJ3ZGvVdrK3376gD5gCnGhnE0Qj9rPPWmYh/ceL/Nh2C+iHZ83+w3/n6 02Xw== X-Gm-Message-State: AIkVDXKvYsr+hcwK9YJoYsO7FB/NkkJhHjbl8FmnpXi9O09RifxMrrxAzg5h651rO/3TGJ5wDt5S3MaxF0Z4zzcw X-Received: by 10.237.53.56 with SMTP id a53mr5415978qte.78.1485470441574; Thu, 26 Jan 2017 14:40:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.188 with HTTP; Thu, 26 Jan 2017 14:40:41 -0800 (PST) In-Reply-To: References: From: Taylor Brandstetter Date: Thu, 26 Jan 2017 14:40:41 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11c0302afee3a70547070901 Archived-At: Cc: "hta@google.com" , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Section 5.4 Question 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, 26 Jan 2017 22:40:44 -0000 --001a11c0302afee3a70547070901 Content-Type: text/plain; charset=UTF-8 By the way, Section 5.8 currently says: First, the parsed parameters are checked to ensure that they are > identical to those generated in the last call to createOffer/ > createAnswer, and thus have not been altered, as discussed in > Section 5.4; otherwise, processing MUST stop and an error MUST be > returned. > > So there seems to be a slight disconnect between 5.4 and 5.8. On Thu, Jan 26, 2017 at 2:20 PM, Bernard Aboba wrote: > In Section 5.4, JSEP says: > > " The SDP returned from createOffer or createAnswer MUST NOT be changed > before passing it to setLocalDescription." > > [BA] Does this mean that *any* change to description.sdp is unacceptable > (e.g. byte for byte identical)? > > Or is the text trying to say that the parsed representation must be the > same (e.g. "a=" lines appearing in a different order shouldn't matter)? > > This has come up in updating the WebRTC 1.0 API to make it compatible with > the new JSEP text. > --001a11c0302afee3a70547070901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By the way, Section 5.8 currently says:

  =
 First, the parsed parameters are checked to ensure that they are
   identical to those generated in the last call to createOffer/
   createAnswer, and thus have not been altered, as discussed in
   Section 5.4; otherwise, processing MUST stop and an error MUST be
   returned.
So there seems to be a slight disconnec= t between 5.4 and 5.8.

On Thu, Jan 26, 2017 at 2:20 PM, Bernard Aboba <b= ernard.aboba@gmail.com> wrote:
In Section 5.4, JSEP says:=C2=A0

&q= uot; The SDP returne= d from createOffer or createAnswer MUST NOT be changed
=C2=A0 =C2=A0before passi= ng it to setLocalDescription."

[BA] Do= es this mean that *any* change to description.sdp is unacceptable (e.g. byt= e for byte identical)?=C2=A0

Or is the text trying to say tha= t=C2=A0the parsed representation must be the same (e.g. &quo= t;a=3D" lines appearing in a different order shouldn't matter)?

This has come up in updating t= he WebRTC 1.0 API to make it compatible with the new JSEP text.

--001a11c0302afee3a70547070901-- From nobody Fri Jan 27 08:43:42 2017 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 DD70612953E; Fri, 27 Jan 2017 08:43: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, FILL_THIS_FORM=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 Zd5ODwIiCxGm; Fri, 27 Jan 2017 08:43:33 -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 8EEAE129525; Fri, 27 Jan 2017 08:43:32 -0800 (PST) X-AuditID: c1b4fb30-d53ff70000007085-4b-588b78b1a874 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id C2.8A.28805.1B87B885; Fri, 27 Jan 2017 17:43:30 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.319.2; Fri, 27 Jan 2017 17:44:29 +0100 From: Magnus Westerlund To: "mmusic (E-mail)" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" , Message-ID: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Date: Fri, 27 Jan 2017 17:43:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM2K7t+6miu4IgzXrTS2mz3rHZjG/Yx2b xdTlj1ks1v5rZ3dg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mt52H2EpaK+rOHH2DXMD 4/OoLkZODgkBE4n73z4ydzFycQgJrGOU6LtwiA0kISSwnFFi9hQOEJtNwELi5o9GNpAiEYEn jBL9Cx6zgCSEBVIl9u6YwQhi8wrYS7zetxBoEgcHi4CqxOMf/iBhUYEYibfrl7NDlAhKnJz5 hAWkhBmo/MHWMpAws4C8RPPW2cwQa7UlGpo6WCcw8s5C0jELoWMWko4FjMyrGEWLU4uTctON jPRSizKTi4vz8/TyUks2MQLD6+CW3wY7GF8+dzzEKMDBqMTDa+DeFSHEmlhWXJl7iFGCg1lJ hLc+vztCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6pBsa4 UrHXy5kXNrA8dn5qFWTklsDaf/XDlrDbV894c+Q83xm3X8DYa9q1+/NKelsmbdWtE2i4Hj7t 2OHlNXxLbz8Le3/tQ9Tqz23bdRM64xjkKrfNMWF1m2Do/Kr9/M3uCSonluffL3yUxFV+1XxV S7Xi9y/NF9uNI1sljL32MLHp8TB9N8+X+KTEUpyRaKjFXFScCAA/RaaoKwIAAA== Archived-At: Subject: [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description 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, 27 Jan 2017 16:43:36 -0000 MMUSIC and RTCWEB, Here is now a more complete text proposal that also considers the RTCP. It also goes further than what Appendix B defines in one aspect, namely explicitly considering third party RTCP reporting and what to do with it. Feedback is much appreciated. I plan to put this into a PR towards JSEP APPENDIX B on monday. If only to get the JSEP authors attention ;-). However, the text is really intended for the next version of BUNDLE. X. Associating RTP/RTCP With Correct SDP Media Description As described in [RFC3550], RTP packets are associated with RTP streams [RFC7656]. Each RTP stream is identified by an SSRC value, and each RTP packet carries an SSRC value that is used to associate the packet with the correct RTP stream. RTCP packets also uses SSRCs to identify on which RTP streams any report or feedback relate to. Thus, an RTCP packet will commonly carry multiple SSRC values, and might therefore be providing feedback or report on multiple RTP streams. In order to be able to process received RTP/RTCP packets correctly it must be possible to associate an RTP stream with the correct "m=" line, as the "m=" line and SDP attributes associated with the "m=" line contain information needed to process the packets. As all RTP streams associated with a BUNDLE group are part of the same RTP session and using the same address:port combination for sending and receiving RTP/RTCP packets, the local address:port combination cannot be used to associate an RTP stream with the correct "m=" line. In addition, multiple RTP streams might be associated with the same "m=" line. Also, as described in Section 10.1.1, the same payload type value might be used by multiple RTP streams, in which case the payload type value cannot be used to associate an RTP stream with the correct "m=" line. However, there are cases where each "m=" line has unique payload type values, and then the payload type could serve as indicator to the relevant "m=" line the RTP stream is associated with. An offerer and answerer can inform each other which SSRC values they will use for an RTP stream by using the SDP 'ssrc' attribute [RFC5576]. However, an offerer will not know which SSRC values the answerer will use until the offerer has received the answer providing Name Expires July 31, 2017 [Page 2] Internet-Draft Abbreviated-Title January 2017 that information. Due to this, before the offerer has received the answer, the offerer will not be able to associate an RTP stream with the correct "m=" line using the SSRC value associated with the RTP stream. In addition, the offerer and answerer may start using new SSRC values mid-session, without informing each other using the SDP 'ssrc' attribute. In order for an offerer and answerer to always be able to associate an RTP stream with the correct "m=" line, the offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 14, where the offerer and answerer includes the identification-tag (provided by the remote peer) associated with an "m=" line in the RTP Streams and in RTCP SDES packets part of a BUNDLE group. The mapping from an SSRC to an identification-tag is carried in RTCP SDES packets or in RTP header extensions (Section 14). Since a compound RTCP packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, an RTCP packet can contain several SSRC to identification-tag mappings. The offerer and answerer maintain tables mapping RTP streams identified by SSRC to "m=" lines identified by the identification-tag. These tables are updated each time new information that affects how packets should be processed and routed are received. To prepare for demultiplexing RTP streams to the correct "m=" line, the following steps MUST be followed for each BUNDLE group based on the SDP signalling information. Construct a table mapping MID to "m=" line for each "m=" line in this BUNDLE group. Note that an "m=" line may only have one MID. Construct a table mapping incoming RTP streams (SSRCs) to their "m=" line for each "m=" line in this BUNDLE group and for each RTP stream explicitly signalled for receiving in that "m=" line. Construct a table mapping payload types to "m=" line for each "m=" line in the BUNDLE group and for each payload type configured for receiving in that "m=" line. If any payload type is configured for receiving in more than one "m=" line in the BUNDLE group, do not it include it in the table. Note that for each of these tables, there can only be one mapping for any given key (MID, SSRC, or PT). In other words, the tables are not multimaps. As "m=" lines are added or removed from the BUNDLE groups, or their configurations are changed, the tables above MUST also be updated. Name Expires July 31, 2017 [Page 3] Internet-Draft Abbreviated-Title January 2017 Received RTP packets that are syntactically correct are processed by the RTP/RTCP protocol implementation for statistics etc. After this processing they need to be routed to the higher layer context associated with the "m=" line within the BUNDLE group. Somewhere in the process where an received RTP packet is processed to be delivered to the higher layer by RTP the matching step below MUST be performed: 1. Reception of an RTP packet for an RTP stream that has an existing mapping in the RTP stream to m= line table. Before proceeding in delivering the packet to the higher layer context according to the RTP stream to "m=" line mapping table the following checks MUST be performed: A. If the packet carries an RTP header extension with a SDES MID value that is not in the table mapping MID to "m=" line, then do not deliver the RTP packet to higher layers. B. If the packet carries an RTP header extension with a SDES MID value that is in the table mapping MID to "m=" line, and the value indicates a different "m=" line than the current RTP stream to "m=" line mapping table, then update the RTP stream to "m=" line mapping. 2. Reception of an RTP packet for an RTP stream that has no existing mapping to an m= line. In this case the following actions MUST be performed: A. If the packet carries an RTP header extension with a SDES MID value that is in the table mapping MID to "m=" line, then create an entry in the RTP stream to "m=" line mapping table for this RTP stream (SSRC). Then deliver the RTP packet to the "m=" line context of the created mapping and stop. B. If the packet carries a Payload Type that is in the payload type table, then create an entry in the RTP stream to "m=" line mapping table for this RTP stream (SSRC). Then deliver the RTP packet to the "m=" line context of the created mapping and stop. C. Otherwise do not deliver the RTP packet to higher layers. Note, this includes unknown MID values. For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the RTCP packet needs to be processed by the RTP/RTCP implementation and relevant information and data from the RTCP packets needs to be routed to the appropriate handler for the related RTP streams. The appropriate handler is determined by using the RTP stream to "m=" line mapping table. Name Expires July 31, 2017 [Page 4] Internet-Draft Abbreviated-Title January 2017 On reception of any compound RTCP packet prior to dispatching the received information and data, if there is an RTCP SDES packet included that SHOULD be processed first. If that SDES packet contains SDES MID entries, this can results in updates and additions to the RTP stream to "m=" line mapping table. Thus each of the SDES MID items are processed and the current table entries are checked if the corresponding MID value matches the current RTP stream to "m=" line mapping, else the entry is updated. If there is no RTP stream to "m=" line table mapping entry for the received SDES item's SSRC, such an entry is created. Note, that in the process of updating the table entries, update flap suppression as discussed in Section 4.2.6 of [RFC7941] should be considered. The various different RTCP packets as well as their various sub parts, such as the various RTCP Feedback message types, relates to the RTP streams in a couple of different ways. The currently known patterns are the following: Reports on outgoing RTP streams: For all RTP streams that this endpoint is the source of, it can expect to receive report blocks of several types identified as relating to an outgoing stream. The basic pattern for these blocks are that the RTCP packet header identifies the source of the reports, as identified by an SSRC, and containing one or more report blocks, where each report block identifies the RTP stream, using the SSRC, the report relates to. For this pattern the relevant report information is provided to the higher layer associated with the "m=" line the RTP Stream to "m=" line table identifies. The source SSRC as identifier of the endpoint that the report originates are relevant for interpreting the information, but not necessarily for routing. Example of this is pattern are: Sender Report (SR) and Receiver Report (RR) The basic receiver report blocks from RFC3550 start with the SSRC of the RTP stream they report on. Extended Reports (XR): RFC3611 is a framework that enables a large number of different reports. However, a large number of these report formats are reporting on specific RTP streams and thus each individual report of these types contains a SSRC field to identify the RTP stream. RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP feedback messages allow for a number of different type of feedback messages. However, the RTCP feedback message header contains the SSRC identifying the source of the feedback messages as well as the actual type of the feedback. Some of the feedback messages also uses the target SSRC field in the header to identify which Name Expires July 31, 2017 [Page 5] Internet-Draft Abbreviated-Title January 2017 RTP stream the feedback is related to. For these types all the FCI entries, if multiple ones are forwarded to the identified handler. Examples of this pattern are: Picture Loss Indication (PLI): RFC 4585 (PT=PSFB, FMT=1). Slice Loss Indication (SLI): RFC 4585 (PT=PSFB, FMT=2). Reference Picture Selection Indication (RPSI): RFC 4585 (PT=PSFB, FMT=3). Generic NACK: [RFC4585] (PT=RTPFB and FMT=1). Other feedback messages includes the target SSRC in the Feedback Control Information (FCI). Here each FCI needs to be processed and the SSRC field identified. And the individual FCI combined with the RTCP packet header context needs to be forwarded to the identified handler. Example of this pattern are: Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, FMT=5). Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] defined message (PT=PSFB, FMT=5) is actually a notifciation in response to a TSTR this endpoint sent using the SSRC the FCI identifies as source. H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, FMT=7). Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, FMT=TBD). Descriptive or Notifications for an incoming RTP stream: There exist some RTCP packet types that provides additional information or notifies about events related to the RTP stream identified. In these cases the RTP stream is identified using the SSRC field value, and the information is provided to the higher layer associated with the "m=" line for the incoming RTP stream as identified by the current RTP stream to "m=" line table. For this type of pattern it is common that the RTCP packets and information is repeated, either periodically (e.g. SDES items), or for a duration (e.g. BYE), thus suppression of repetitions can be considered. Examples of these are: Name Expires July 31, 2017 [Page 6] Internet-Draft Abbreviated-Title January 2017 Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol [RFC3550] defines SDES RTCP packets as a way of providing per source (SSRC) specific information about the source. An SDES packet contains zero or more chunks, where a chunk contains the SSRC for the source being described by the one or more items included in the chunk. Forward the SDES items in each chunk to the RTP stream's handler. Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] mechanism indicates that a particular RTP stream is leaving the RTP session. Thus, a most relevant event to inform the handler for this RTP steam of. Third Party Targeted Reports or Feedback: There exist some multiparty RTP Topologies that results in that an endpoint receives third party reports (SR [RFC3550], RR [RFC3550] or XR [RFC3611]) as well as Feedback Messages [RFC4585] that relates to or targets an SSRC that originates from another endpoint, and where the source of the RTCP packet is also another endpoint. This type of packets should be forwarded to the higher layer function dealing with the third party reporting. And if none exist then they can be suppressed. As the third party handler can be focused on determining the conditions for the source of the reports and feedback, or focused on how the RTP stream source progresses, or both recommendations can't be made. APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that enables experimentation. The APP packet only specifies the source of the packet. Thus this information can be related to any of the "m=" lines, thus deliver a copy of the packet to each "m=" line or an APP specific handler. -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jan 27 09:15:03 2017 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 5038112969F; Fri, 27 Jan 2017 09:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 1hbo5CZD6nkE; Fri, 27 Jan 2017 09:14:59 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE66A12969C; Fri, 27 Jan 2017 09:14:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7F2D97C5256; Fri, 27 Jan 2017 18:14:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFgXdJ7IafPg; Fri, 27 Jan 2017 18:14:33 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:c145:37:d66e:9253] (unknown [IPv6:2001:470:de0a:1:c145:37:d66e:9253]) by mork.alvestrand.no (Postfix) with ESMTPSA id 228507C5255; Fri, 27 Jan 2017 18:14:32 +0100 (CET) To: Flemming Andreasen , mmusic@ietf.org References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Harald Alvestrand Message-ID: <1df9ff00-e8e3-661a-9646-a4a8a6d8b3f8@alvestrand.no> Date: Fri, 27 Jan 2017 18:14:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Change Alert [Re: [MMUSIC] Modifying an approved document: MSID] 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, 27 Jan 2017 17:15:01 -0000 On 01/26/2017 02:54 PM, Flemming Andreasen wrote: > Hi Harald > > Since the document is not yet in Auth48 and the change is relatively > minor, it is possible to update it during Auth48. Would it also be OK to submit an updated draft, so that the RFC Editor doesn't have to waste time incorporating the changes? > > However, from an MMUSIC chair point of view, I would like to get > positive confirmation from some of the stakeholders that this change > is indeed desired. Similarly, if anybody has any concerns with the > suggested change, please send an e-mail to that effect. I have poked a few people to give their opinion. Will poke again. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > On 1/23/17 10:18 AM, Harald Alvestrand wrote: >> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >>> Ted pointed out to me that I sent this to the wrong group. >>> >>> Chairs and members, please advise. >> My proposed change is here: >> >> https://github.com/alvestrand/rtcweb-msid/pull/16 >> >> The filed issue is here: >> >> https://github.com/alvestrand/rtcweb-msid/issues/15 >> >> (CCing RTCWEB - please keep discussion, if any, on mmusic) >> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: [rtcweb] Modifying an approved document: MSID >>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>> From: Harald Alvestrand >>> To: rtcweb@ietf.org >>> >>> >>> >>> When reviewing the implications of the PeerConnection API change to >>> support AddTrack rather than AddStream, I found an issue. >>> >>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>> REF-WAIT state (I believe). >>> >>> The issue is that it is possible to add a track without specifying a >>> stream. Since the track's ID needs to be carried, we have to send an >>> "a=msid" line, but the track's ID is the *second* field on that line, >>> with the first being the stream's ID. >>> >>> This creates a problem. >>> >>> Suggested fix: Insert two lines in the document: >>> >>> 1) On SDP generation: >>> >>> "If there is no stream associated with the track, use the reserved ID >>> value '-'" >>> >>> 2) On SDP parsing >>> >>> "If the stream ID is the reserved value '-', the track is not >>> associated >>> with a stream, and no stream is signalled or created." >>> >>> If this is OK with the community, I'll issue an updated draft with this >>> change. >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > -- Surveillance is pervasive. Go Dark. From nobody Fri Jan 27 10:20:40 2017 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 052D91296C1; Fri, 27 Jan 2017 10:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 AoPP6NJCFXIz; Fri, 27 Jan 2017 10:20:34 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 D7DFD1296C8; Fri, 27 Jan 2017 10:20:29 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id x75so180669954vke.2; Fri, 27 Jan 2017 10:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1ByUom2aAVza8IazdbFUD09On3hOjueBvpgX56bvwEo=; b=PYkc17HRU7Q/uVwMeDTn4lhwai77+2gu8VvZ+dcyZJKJFFxs3WwJIH+oQmKDZQjhRW /r+5gy2b8Pi7koEaqGTvzjBfsIrRqljPJPa3sim3tD9SaaqaWyrp2iJokRcg04GAFkAi cV0v+PXEp6ysW+kSXzV7x+cGERR0ZOopAwbOBlbZAHbn1u8mW54ZCsBvvwCOGUXfoARR CpGkKaStFgbRapr+/DbWHhKqfTUMj7HnRrqRo4vqhKJIkcSfLd1z3RQorfQ+5AbrVHBM CqWZcDpbEjNJE/AOwuwvONyM9JIleqQgGe+RYhaqO6rleS5g76efHztictAcZRIVVltT 0aqw== 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=1ByUom2aAVza8IazdbFUD09On3hOjueBvpgX56bvwEo=; b=GwikaBUphgdU+o0mLlAUIL2ixpWMgKuFlRRNzdj515/AulIBrBNU1IRYe9K+Hmb5xS kdloIjZB9UjgIO3czBd54vs6h2ed+JDTwhhi4bUoVoVWVvU10C0xJkzDzK79XtJXIVNh ObuTYzaVZV2dP2aS6LK0Bcn6GXM5pyZaHpV5XHTW78n8TlgshmEMpMogzWc3S0KLpLw5 IZv9tA1X63X5vdPNj2Z8TuN4CivkJYXM1+mIlQrolWuh1Ap81hwYd2qXYrwa0kpbcCfd WwkB1UKyGLOQ14+13plFjiBCOlbYzs//icWltpTyuRDtNuaifizGnNZwiCUQD5q2n9LB a0Eg== X-Gm-Message-State: AIkVDXKuGjDCm2lgYEnOql2vUTCFn0BEtunVFz1qv+vh9mPeVUtDxwUB6NwJWNQC/QVh6iFE4hjyJwb3QfpjQg== X-Received: by 10.31.98.196 with SMTP id w187mr4009274vkb.169.1485541228892; Fri, 27 Jan 2017 10:20:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Fri, 27 Jan 2017 10:20:08 -0800 (PST) In-Reply-To: References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Bernard Aboba Date: Fri, 27 Jan 2017 10:20:08 -0800 Message-ID: To: Flemming Andreasen Content-Type: multipart/alternative; boundary=94eb2c07b57a3f5ccb0547178534 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] 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, 27 Jan 2017 18:20:36 -0000 --94eb2c07b57a3f5ccb0547178534 Content-Type: text/plain; charset=UTF-8 I am in favor of the change. On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen wrote: > Hi Harald > > Since the document is not yet in Auth48 and the change is relatively > minor, it is possible to update it during Auth48. > > However, from an MMUSIC chair point of view, I would like to get positive > confirmation from some of the stakeholders that this change is indeed > desired. Similarly, if anybody has any concerns with the suggested change, > please send an e-mail to that effect. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > On 1/23/17 10:18 AM, Harald Alvestrand wrote: > >> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >> >>> Ted pointed out to me that I sent this to the wrong group. >>> >>> Chairs and members, please advise. >>> >> My proposed change is here: >> >> https://github.com/alvestrand/rtcweb-msid/pull/16 >> >> The filed issue is here: >> >> https://github.com/alvestrand/rtcweb-msid/issues/15 >> >> (CCing RTCWEB - please keep discussion, if any, on mmusic) >> >> >>> >>> -------- Forwarded Message -------- >>> Subject: [rtcweb] Modifying an approved document: MSID >>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>> From: Harald Alvestrand >>> To: rtcweb@ietf.org >>> >>> >>> >>> When reviewing the implications of the PeerConnection API change to >>> support AddTrack rather than AddStream, I found an issue. >>> >>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>> REF-WAIT state (I believe). >>> >>> The issue is that it is possible to add a track without specifying a >>> stream. Since the track's ID needs to be carried, we have to send an >>> "a=msid" line, but the track's ID is the *second* field on that line, >>> with the first being the stream's ID. >>> >>> This creates a problem. >>> >>> Suggested fix: Insert two lines in the document: >>> >>> 1) On SDP generation: >>> >>> "If there is no stream associated with the track, use the reserved ID >>> value '-'" >>> >>> 2) On SDP parsing >>> >>> "If the stream ID is the reserved value '-', the track is not associated >>> with a stream, and no stream is signalled or created." >>> >>> If this is OK with the community, I'll issue an updated draft with this >>> change. >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> _______________________________________________ >>> 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 >>> >>> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c07b57a3f5ccb0547178534 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in favor of the change.

On Thu, Jan 26, 2017 at 5:54 AM, Flemming= Andreasen <fandreas@cisco.com> wrote:
Hi Harald

Since the document is not yet in Auth48 and the change is relatively minor,= it is possible to update it during Auth48.

However, from an MMUSIC chair point of view, I would like to get positive c= onfirmation from some of the stakeholders that this change is indeed desire= d. Similarly, if anybody has any concerns with the suggested change, please= send an e-mail to that effect.

Thanks

-- Flemming (as MMUSIC co-chair)



On 1/23/17 10:18 AM, Harald Alvestrand wrote:
Den 19. jan. 2017 13:31, skrev Harald Alvestrand:
Ted pointed out to me that I sent this to the wrong group.

Chairs and members, please advise.
My proposed change is here:

https://github.com/alvestrand/rtcweb-msid/pull= /16

The filed issue is here:

https://github.com/alvestrand/rtcweb-msid/is= sues/15

(CCing RTCWEB - please keep discussion, if any, on mmusic)



-------- Forwarded Message --------
Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 [rtcweb] Modifying an approved document= : MSID
Date:=C2=A0 =C2=A0Wed, 18 Jan 2017 23:22:14 +0100
From:=C2=A0 =C2=A0Harald Alvestrand <harald@alvestrand.no>
To:=C2=A0 =C2=A0 =C2=A0rtcweb@ietf.org <rtcweb@ietf.org>



When reviewing the implications of the PeerConnection API change to
support AddTrack rather than AddStream, I found an issue.

This issue concerns draft-ietf-rtcweb-msid, which is currently in
REF-WAIT state (I believe).

The issue is that it is possible to add a track without specifying a
stream. Since the track's ID needs to be carried, we have to send an "a=3Dmsid" line, but the track's ID is the *second* field on = that line,
with the first being the stream's ID.

This creates a problem.

Suggested fix: Insert two lines in the document:

1) On SDP generation:

"If there is no stream associated with the track, use the reserved ID<= br> value '-'"

2) On SDP parsing

"If the stream ID is the reserved value '-', the track is not = associated
with a stream, and no stream is signalled or created."

If this is OK with the community, I'll issue an updated draft with this=
change.


--
Surveillance is pervasive. Go Dark.

_______________________________________________
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
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic .


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

--94eb2c07b57a3f5ccb0547178534-- From nobody Fri Jan 27 19:46:44 2017 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 BAFAE129B84; Fri, 27 Jan 2017 19:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Mh1KJLIxq9uw; Fri, 27 Jan 2017 19:46:42 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 BA695129B82; Fri, 27 Jan 2017 19:46:41 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id u25so81949610qki.2; Fri, 27 Jan 2017 19:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DFHFd6DZ9jAxdCCXPx83hThZFSdrasoOx+ssji+2ugo=; b=CjYtGkM2fUyH8ZSd8mEoluaP4SDHVc2WCzeSdNiEQs/zYZ+uuR/Cp8woxuc+ArWEzC VpCtQ9R9AcUf3sXoXN2IUwS0I4CpsX+crWDSO1YN8vhuQVFlDaOlNrPP6R7jCjUBhBj4 DjDIKtQPTQKGemRwFTTozx4Op7oCl34/eMUDdiySGS2WHF2xS5ncJrXp5LWC2DxgnaWr mRdYpu+9+UytBuhBNDk5PDNyQBoRD8bQ8o4qc6z01RL20WVeN8q71plO9amN2aQOKUec 2Lsd/MVTvj7m0hsI9qN+i3Twh5xNJ/gqVjMy77clW7GDmTNszEFcl5HWCyaznEFlt4Ri JXCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DFHFd6DZ9jAxdCCXPx83hThZFSdrasoOx+ssji+2ugo=; b=OHjs3uSTfmzpKpLmuR99d3ZpKdiOF6TL7NaGS8K74gzLUajD9W0VlOrpCb0MuwnzSn GojcM+9mWGqZWMf3R9SWp52UGpcAlDUJQQULIEQVe5+c9+Te4CvlmE4LdHrzfBFI6tf8 mpyw8CHo4glgAPPQF/5s1+iPJcb7ZTtmur2DEwKuC9JvyWxdTk0yO6YhsU3zuj+Q8OYj 2oKRFJNQQJKwZKu2MAcAEgQ/5xOavatpijn/kAFYeaLbhYdj7ohsp4AKG5jrgRcO4Yoc LITR1ITVoKgt5ZW0UJUjGz9X7aGyEU8hDnJev6I/LJTpuTsXybfdA+9LpC7oORxEEd1E 9wZA== X-Gm-Message-State: AIkVDXKT2OdrHwNI1JFC4KNqKiUHvxfrKz1wLaI2dHGsgMIemC/wcHrmueH/Njq8Nas4J1SiiPB58cacxYjn/g== X-Received: by 10.55.21.84 with SMTP id f81mr11540349qkh.5.1485575200762; Fri, 27 Jan 2017 19:46:40 -0800 (PST) MIME-Version: 1.0 References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> In-Reply-To: From: Suhas Nandakumar Date: Sat, 28 Jan 2017 03:46:30 +0000 Message-ID: To: Bernard Aboba , Flemming Andreasen Content-Type: multipart/alternative; boundary=001a1147b90420ef1205471f6ede Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] 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: Sat, 28 Jan 2017 03:46:44 -0000 --001a1147b90420ef1205471f6ede Content-Type: text/plain; charset=UTF-8 +1 On Fri, Jan 27, 2017 at 10:20 AM Bernard Aboba wrote: > I am in favor of the change. > > On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen > wrote: > > Hi Harald > > > > > > Since the document is not yet in Auth48 and the change is relatively > minor, it is possible to update it during Auth48. > > > > > > However, from an MMUSIC chair point of view, I would like to get positive > confirmation from some of the stakeholders that this change is indeed > desired. Similarly, if anybody has any concerns with the suggested change, > please send an e-mail to that effect. > > > > > > Thanks > > > > > > -- Flemming (as MMUSIC co-chair) > > > > > > > > > > > > On 1/23/17 10:18 AM, Harald Alvestrand wrote: > > > > > Den 19. jan. 2017 13:31, skrev Harald Alvestrand: > > > > > Ted pointed out to me that I sent this to the wrong group. > > > > > > Chairs and members, please advise. > > > > > My proposed change is here: > > > > > > https://github.com/alvestrand/rtcweb-msid/pull/16 > > > > > > The filed issue is here: > > > > > > https://github.com/alvestrand/rtcweb-msid/issues/15 > > > > > > (CCing RTCWEB - please keep discussion, if any, on mmusic) > > > > > > > > > > > > > > -------- Forwarded Message -------- > > > Subject: [rtcweb] Modifying an approved document: MSID > > > Date: Wed, 18 Jan 2017 23:22:14 +0100 > > > From: Harald Alvestrand > > > To: rtcweb@ietf.org > > > > > > > > > > > > When reviewing the implications of the PeerConnection API change to > > > support AddTrack rather than AddStream, I found an issue. > > > > > > This issue concerns draft-ietf-rtcweb-msid, which is currently in > > > REF-WAIT state (I believe). > > > > > > The issue is that it is possible to add a track without specifying a > > > stream. Since the track's ID needs to be carried, we have to send an > > > "a=msid" line, but the track's ID is the *second* field on that line, > > > with the first being the stream's ID. > > > > > > This creates a problem. > > > > > > Suggested fix: Insert two lines in the document: > > > > > > 1) On SDP generation: > > > > > > "If there is no stream associated with the track, use the reserved ID > > > value '-'" > > > > > > 2) On SDP parsing > > > > > > "If the stream ID is the reserved value '-', the track is not associated > > > with a stream, and no stream is signalled or created." > > > > > > If this is OK with the community, I'll issue an updated draft with this > > > change. > > > > > > > > > -- > > > Surveillance is pervasive. Go Dark. > > > > > > _______________________________________________ > > > 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 > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > . > > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1147b90420ef1205471f6ede Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1=C2=A0
On Fri, Jan 27, 2017 at 10= :20 AM Bernard Aboba <bernard= .aboba@gmail.com> wrote:
I am in favor of the change.

On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen <fandreas@cisco.com> wrote:
Hi Harald
=




Since the document is not yet in Au= th48 and the change is relatively minor, it is possible to update it during= Auth48.





How= ever, from an MMUSIC chair point of view, I would like to get positive conf= irmation from some of the stakeholders that this change is indeed desired. = Similarly, if anybody has any concerns with the suggested change, please se= nd an e-mail to that effect.





Thanks





-- Flemming (as MMUSIC co-chair)










On 1/23/17 10:18 AM, Harald Alvestrand wrote:




= Den 19. jan. 2017 13:31, skrev Harald Alvestrand:



Ted pointed out to m= e that I sent this to the wrong group.





Chairs and members, please advise.




My proposed change is here:





https://github.com/alvestrand/rtcweb-msid/pull/16





The filed= issue is here:




=
https://github.com/alvest= rand/rtcweb-msid/issues/15





(CCing RTCWEB - please keep discussion, if any, on mmusi= c)












-------- Forwarded Message --------


Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 [rtcweb] Modifyi= ng an approved document: MSID


Date:=C2=A0 = =C2=A0Wed, 18 Jan 2017 23:22:14 +0100


From:= =C2=A0 =C2=A0Harald Alvestrand <harald@alvestrand.no>


To:=C2=A0 =C2=A0 =C2=A0rtcweb@ietf.org <rtcweb@ie= tf.org>




<= br>





When rev= iewing the implications of the PeerConnection API change to


support AddTrack rather than AddStream, I found an issue.




This issue co= ncerns draft-ietf-rtcweb-msid, which is currently in


REF-WAIT state (I believe).





The issue is that it is possible to add a track wi= thout specifying a


stream. Since the track&#= 39;s ID needs to be carried, we have to send an

=
"a=3Dmsid" line, but the track's ID is the *second* field= on that line,


with the first being the stre= am's ID.




This creates a problem.





Suggested fix: Insert two lines in the document:





1) On SDP generation:





"If there = is no stream associated with the track, use the reserved ID


value '-'"





2) On SDP parsing




"If the stream ID is the reserved va= lue '-', the track is not associated

with a stream, and no stream is signalled or created."





If this is OK with the com= munity, I'll issue an updated draft with this

change.







--


Survei= llance is pervasive. Go Dark.





_______________________________________________


rtcweb mailing list


<= a href=3D"mailto:rtcweb@ietf.org" class=3D"gmail_msg" target=3D"_blank">rtc= web@ietf.org


https://www.ietf.org/mailman/listinfo/rtcweb










_____________________________________= __________


mmusic mailing list


mmusic@ietf.org


https://www.ietf.org/mailman/listinfo/mmus= ic







_______________________________________________


mmusic mailing list


mmusic= @ietf.org


https://www.ietf.org/mailman/listinfo/mmusic


.




=





__________________= _____________________________


mmusic mailing= list


mmusic@ietf.org


https://www.ietf.org/mail= man/listinfo/mmusic


<= br class=3D"gmail_msg">


______________________________________= _________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic

--001a1147b90420ef1205471f6ede-- From nobody Mon Jan 30 03:55:35 2017 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 CF65C129465 for ; Mon, 30 Jan 2017 03:55:33 -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, 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, URIBL_BLOCKED=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 LuXSlvrKuJS0 for ; Mon, 30 Jan 2017 03:55:32 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 ECE35129464 for ; Mon, 30 Jan 2017 03:55:31 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-fd-588f29b2dde2 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 8E.E7.32317.2B92F885; Mon, 30 Jan 2017 12:55:30 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 30 Jan 2017 12:55:29 +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=hRlelDGR/3LCREyEzFUcyDakeSUvyFFU4Ynb4H61sb8=; b=i5VZ/26W6wT842FcaUkzoiEIVJDHs/EhmlV/plpt8WmoMNm42dg9C+7hPT82TUSFMKd2hdUNics+ix6AO3E7DJHaCxv8gqFoW81Ea5aIa/8jELptXegXu0x5ZBCUoYI3ozsJRlK5GLSxblEy57ZOZ3nwTOlAIY1pAzdIdYCaMmY= Received: from VI1PR0701MB2733.eurprd07.prod.outlook.com (10.173.80.145) by VI1PR0701MB2735.eurprd07.prod.outlook.com (10.173.80.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 30 Jan 2017 11:55:26 +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.0888.015; Mon, 30 Jan 2017 11:55:26 +0000 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "rtcweb@ietf.org" Thread-Topic: Identity in the SDP Thread-Index: AQHSeu++bgSyAg4nvES2/SnCcYPTCA== Date: Mon, 30 Jan 2017 11:55:26 +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.84] x-ms-office365-filtering-correlation-id: bf18991c-2f59-40a8-bbee-08d44906e17a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB2735; x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2735; 7:bzWtPbHuLMurJDIGHBBMXAN2KoXL/hWI/KdIQMx06jJY2HCIDUc8TbuO9YnnCLbHeZYXv1SSR+FF9kHgNCvK1pGBnTwAz0hvdvDq73ZMFIdCgQn3jJqExqK9lCzs6wDePe94FJxNZGinN/UPbNRPnoAteUGxrN5R1hs8q9X4JALftv0Er1yydNmB8Y2UJhnwKYeJRowMtsXtTxwzHnF4JvzfUFaj1yukPnYonwBZvBLU7Vw/FOXfkI2CKaE6ACjQUn/daAdOB+I9WqyeZ2WJ8kdlcIjs+oWVenXFZfvBOchtK+UNJmSsNPtXkLoOi1frOzshFgeojFOTzkEZLlXCr8oP/+AfrEY+1iDC0/Gy5mOJwLyRsAL9c1/i06NL7i3FxIh+udTN8itsFNQgxMHHYapWelHICIqm2rEUEZIhtUqAlNDm7Xot+UycCe3QlzWrd1/tI+tlsE7B+9EeUshhmQ== 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)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:VI1PR0701MB2735; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2735; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(53754006)(54356999)(50986999)(3660700001)(305945005)(66066001)(9686003)(97736004)(6916009)(189998001)(105586002)(8676002)(2900100001)(3280700002)(7736002)(101416001)(53936002)(8936002)(81166006)(1730700003)(81156014)(92566002)(33656002)(106356001)(106116001)(74316002)(3480700004)(2351001)(55016002)(6506006)(122556002)(86362001)(110136003)(5660300001)(38730400001)(25786008)(6116002)(107886002)(6306002)(5640700003)(3846002)(450100001)(2501003)(2906002)(102836003)(77096006)(7696004)(68736007)(6436002)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2735; 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: 30 Jan 2017 11:55:26.5018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2735 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUyM2K7lu4mzf4Ig4dPRC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqq9axkLvrJWtC+/wNjA+IGli5GTQ0LARGL3wVXsXYxcHEIC 6xglHj6cyQbhnGCUWD/tOROIwyLQyyzR8f0UVNlMJokT104yQjinGCU+7TjCCjKMTSBQYuu+ BWwgtoiAusTlhxfYQWxhARmJC49OQcUVJe48ec4IYetJ/F0/HayGRUBVYv/fZrAaXoEEiQur VoDVMAqISXw/tYYJxGYWEJe49WQ+E8ThAhJL9pxnhrBFJV4+/gd0AwdQfbLE9FY3iLCCxKvu BjYI21fi+qKlUD/7S+x8+xrK7mOReNZXCWHnS5w9egiq3lpiQesmqPF9TBL3NlpB2DIS0951 gENFQuA9q8Szz2vBGoQEUiWWr21lhPhXSuLulU5GmN9f3NnLCnG/nsSNqVPYIGxtiWULXzNP YFSfheS1WUjKZiEpmwUOFkGJkzOfsCxgZFnFKFqcWlycm25krJdalJlcXJyfp5eXWrKJEZgi Dm75rbuDcfVrx0OMAhyMSjy8G6z7IoRYE8uKK3MPMUpwMCuJ8J5U7Y8Q4k1JrKxKLcqPLyrN SS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgTFROMDCTGjl7qc3rJIeydjN1tpx TaSv4lvgn5/Od9ecMmXM4p/34OzWwFP3krT/hS294vf6yyGT0ym1O8qtNxZ+lNDoEalYfuV2 ImPDwliDs0LdLx3Z984KCO5tCjPeoXnxTbBtsbaR6gzx0CM3T1ucOLX0xbaE7eLxtckTJtnt mnFi7s/EV+eUWIozEg21mIuKEwHCcrH6DQMAAA== Archived-At: Subject: [rtcweb] Identity in the SDP 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: Mon, 30 Jan 2017 11:55:34 -0000 Hi all,=0A= =0A= this relates to identity when webrtc is used with an IdentityProvider (IdP)= .=0A= =0A= I've been browsing the specs, and to me it seems that the only place =0A= where we describe how the SDP is affected is in -security-arch [1].=0A= =0A= Is this right? And is that the way it is supposed to be?=0A= =0A= (Asking since in a discussion in W3C WebRTC [2] =0A= draft-ietf-stir-rfc4474bis is mentioned; is that out of scope or in scope?)= .=0A= =0A= Also, I think adding identity to the JSEP and SDP (i.e. =0A= draft-ietf-rtcweb-sdp) specs would be a good thing.=0A= =0A= Stefan=0A= =0A= =0A= [1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12=0A= [2] https://github.com/w3c/webrtc-pc/issues/964=0A= =0A= From nobody Mon Jan 30 05:19:00 2017 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 77CA412949E; Mon, 30 Jan 2017 05:18:59 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 UHMLn-JW5-hp; Mon, 30 Jan 2017 05:18:57 -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 98FB8129499; Mon, 30 Jan 2017 05:18:56 -0800 (PST) X-AuditID: c1b4fb3a-d5ffb70000004068-23-588f3d3dc143 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id B3.FF.16488.D3D3F885; Mon, 30 Jan 2017 14:18:54 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.319.2; Mon, 30 Jan 2017 14:18:53 +0100 To: "mmusic (E-mail)" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" , References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> From: Magnus Westerlund Message-ID: <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> Date: Mon, 30 Jan 2017 14:18:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM2K7va6dbX+Ewdp75hbTZ71js5jfsY7N YuryxywWa/+1szuweCxZ8pPJ48vlz2wBTFFcNimpOZllqUX6dglcGdM77zAWzG9irOiYe5Ct gXFfXBcjJ4eEgInExRfd7F2MXBxCAusYJVY17GEBSQgJLGeUuP2lDMQWFiiSOPCyjRmkSETg CaNE/4LHQEXsQEX2Eo+FQErYBCwkbv5oZAOxeYGiC9c2gdksAqoSs++uARspKhAj8Xb9cnaI GkGJkzOfgMU5BRwklnZOY+1i5OBgBup9sBVsK7OAvETz1tnMENdoSzQ0dbBOYOSfhaR7FkLH LCQdCxiZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIEhuPBLb+tdjAefO54iFGAg1GJh3eD dV+EEGtiWXFl7iFGCQ5mJRHeSRb9EUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8s Sc1OTS1ILYLJMnFwSjUwVl9ZZyXGZhK3ry8xYSZ72/4n31runLhvIrQlTmW226bZ85q2LC5b vT7U6KHA1bkCq59e4GtPUzyl+PwJY8xf/yJ9gfvrdp/WTj3T4RRffqhVxm2So4XG7KMyC+t7 TL+1LnqTyiu26dcttYeZ/1f7hLpmzH3+nvNbnJTbZ/bty+6ymp6r8Vc8rMRSnJFoqMVcVJwI AF2C9uFDAgAA Archived-At: Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description 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: Mon, 30 Jan 2017 13:18:59 -0000 Hi, I have now generated a pull request for this text, with some very minor changes. https://github.com/rtcweb-wg/jsep/pull/538 Cheers Magnus Den 2017-01-27 kl. 17:43, skrev Magnus Westerlund: > MMUSIC and RTCWEB, > > Here is now a more complete text proposal that also considers the RTCP. > It also goes further than what Appendix B defines in one aspect, namely > explicitly considering third party RTCP reporting and what to do with it. > > Feedback is much appreciated. I plan to put this into a PR towards JSEP > APPENDIX B on monday. If only to get the JSEP authors attention ;-). > However, the text is really intended for the next version of BUNDLE. > > > X. Associating RTP/RTCP With Correct SDP Media Description > > As described in [RFC3550], RTP packets are associated with RTP > streams [RFC7656]. Each RTP stream is identified by an SSRC value, > and each RTP packet carries an SSRC value that is used to associate > the packet with the correct RTP stream. RTCP packets also uses SSRCs > to identify on which RTP streams any report or feedback relate to. > Thus, an RTCP packet will commonly carry multiple SSRC values, and > might therefore be providing feedback or report on multiple RTP > streams. > > In order to be able to process received RTP/RTCP packets correctly it > must be possible to associate an RTP stream with the correct "m=" > line, as the "m=" line and SDP attributes associated with the "m=" > line contain information needed to process the packets. > > As all RTP streams associated with a BUNDLE group are part of the > same RTP session and using the same address:port combination for > sending and receiving RTP/RTCP packets, the local address:port > combination cannot be used to associate an RTP stream with the > correct "m=" line. In addition, multiple RTP streams might be > associated with the same "m=" line. > > Also, as described in Section 10.1.1, the same payload type value > might be used by multiple RTP streams, in which case the payload type > value cannot be used to associate an RTP stream with the correct "m=" > line. However, there are cases where each "m=" line has unique > payload type values, and then the payload type could serve as > indicator to the relevant "m=" line the RTP stream is associated > with. > > An offerer and answerer can inform each other which SSRC values they > will use for an RTP stream by using the SDP 'ssrc' attribute > [RFC5576]. However, an offerer will not know which SSRC values the > answerer will use until the offerer has received the answer providing > > > > Name Expires July 31, 2017 [Page 2] > > Internet-Draft Abbreviated-Title January 2017 > > > that information. Due to this, before the offerer has received the > answer, the offerer will not be able to associate an RTP stream with > the correct "m=" line using the SSRC value associated with the RTP > stream. In addition, the offerer and answerer may start using new > SSRC values mid-session, without informing each other using the SDP > 'ssrc' attribute. > > In order for an offerer and answerer to always be able to associate > an RTP stream with the correct "m=" line, the offerer and answerer > using the BUNDLE extension MUST support the mechanism defined in > Section 14, where the offerer and answerer includes the > identification-tag (provided by the remote peer) associated with an > "m=" line in the RTP Streams and in RTCP SDES packets part of a > BUNDLE group. > > The mapping from an SSRC to an identification-tag is carried in RTCP > SDES packets or in RTP header extensions (Section 14). Since a > compound RTCP packet can contain multiple RTCP SDES packets, and each > RTCP SDES packet can contain multiple chunks, an RTCP packet can > contain several SSRC to identification-tag mappings. The offerer and > answerer maintain tables mapping RTP streams identified by SSRC to > "m=" lines identified by the identification-tag. These tables are > updated each time new information that affects how packets should be > processed and routed are received. > > To prepare for demultiplexing RTP streams to the correct "m=" line, > the following steps MUST be followed for each BUNDLE group based on > the SDP signalling information. > > Construct a table mapping MID to "m=" line for each "m=" line in > this BUNDLE group. Note that an "m=" line may only have one MID. > > Construct a table mapping incoming RTP streams (SSRCs) to their > "m=" line for each "m=" line in this BUNDLE group and for each RTP > stream explicitly signalled for receiving in that "m=" line. > > Construct a table mapping payload types to "m=" line for each "m=" > line in the BUNDLE group and for each payload type configured for > receiving in that "m=" line. If any payload type is configured > for receiving in more than one "m=" line in the BUNDLE group, do > not it include it in the table. > > Note that for each of these tables, there can only be one mapping for > any given key (MID, SSRC, or PT). In other words, the tables are not > multimaps. > > As "m=" lines are added or removed from the BUNDLE groups, or their > configurations are changed, the tables above MUST also be updated. > > > > Name Expires July 31, 2017 [Page 3] > > Internet-Draft Abbreviated-Title January 2017 > > > Received RTP packets that are syntactically correct are processed by > the RTP/RTCP protocol implementation for statistics etc. After this > processing they need to be routed to the higher layer context > associated with the "m=" line within the BUNDLE group. Somewhere in > the process where an received RTP packet is processed to be delivered > to the higher layer by RTP the matching step below MUST be performed: > > 1. Reception of an RTP packet for an RTP stream that has an existing > mapping in the RTP stream to m= line table. Before proceeding in > delivering the packet to the higher layer context according to > the RTP stream to "m=" line mapping table the following checks > MUST be performed: > > A. If the packet carries an RTP header extension with a SDES MID > value that is not in the table mapping MID to "m=" line, then > do not deliver the RTP packet to higher layers. > > B. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=" line, and the > value indicates a different "m=" line than the current RTP > stream to "m=" line mapping table, then update the RTP stream > to "m=" line mapping. > > 2. Reception of an RTP packet for an RTP stream that has no existing > mapping to an m= line. In this case the following actions MUST > be performed: > > A. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=" line, then > create an entry in the RTP stream to "m=" line mapping table > for this RTP stream (SSRC). Then deliver the RTP packet to > the "m=" line context of the created mapping and stop. > > B. If the packet carries a Payload Type that is in the payload > type table, then create an entry in the RTP stream to "m=" > line mapping table for this RTP stream (SSRC). Then deliver > the RTP packet to the "m=" line context of the created > mapping and stop. > > C. Otherwise do not deliver the RTP packet to higher layers. > Note, this includes unknown MID values. > > For each RTCP packet received (including each RTCP packet that is > part of a compound RTCP packet), the RTCP packet needs to be > processed by the RTP/RTCP implementation and relevant information and > data from the RTCP packets needs to be routed to the appropriate > handler for the related RTP streams. The appropriate handler is > determined by using the RTP stream to "m=" line mapping table. > > > > Name Expires July 31, 2017 [Page 4] > > Internet-Draft Abbreviated-Title January 2017 > > > On reception of any compound RTCP packet prior to dispatching the > received information and data, if there is an RTCP SDES packet > included that SHOULD be processed first. If that SDES packet > contains SDES MID entries, this can results in updates and additions > to the RTP stream to "m=" line mapping table. Thus each of the SDES > MID items are processed and the current table entries are checked if > the corresponding MID value matches the current RTP stream to "m=" > line mapping, else the entry is updated. If there is no RTP stream > to "m=" line table mapping entry for the received SDES item's SSRC, > such an entry is created. Note, that in the process of updating the > table entries, update flap suppression as discussed in Section 4.2.6 > of [RFC7941] should be considered. > > The various different RTCP packets as well as their various sub > parts, such as the various RTCP Feedback message types, relates to > the RTP streams in a couple of different ways. The currently known > patterns are the following: > > Reports on outgoing RTP streams: For all RTP streams that this > endpoint is the source of, it can expect to receive report blocks > of several types identified as relating to an outgoing stream. > The basic pattern for these blocks are that the RTCP packet header > identifies the source of the reports, as identified by an SSRC, > and containing one or more report blocks, where each report block > identifies the RTP stream, using the SSRC, the report relates to. > For this pattern the relevant report information is provided to > the higher layer associated with the "m=" line the RTP Stream to > "m=" line table identifies. The source SSRC as identifier of the > endpoint that the report originates are relevant for interpreting > the information, but not necessarily for routing. Example of this > is pattern are: > > Sender Report (SR) and Receiver Report (RR) The basic receiver > report blocks from RFC3550 start with the SSRC of the RTP > stream they report on. > > Extended Reports (XR): RFC3611 is a framework that enables a > large number of different reports. However, a large number of > these report formats are reporting on specific RTP streams and > thus each individual report of these types contains a SSRC > field to identify the RTP stream. > > RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP > feedback messages allow for a number of different type of feedback > messages. However, the RTCP feedback message header contains the > SSRC identifying the source of the feedback messages as well as > the actual type of the feedback. Some of the feedback messages > also uses the target SSRC field in the header to identify which > > > > Name Expires July 31, 2017 [Page 5] > > Internet-Draft Abbreviated-Title January 2017 > > > RTP stream the feedback is related to. For these types all the > FCI entries, if multiple ones are forwarded to the identified > handler. Examples of this pattern are: > > Picture Loss Indication (PLI): RFC 4585 (PT=PSFB, FMT=1). > > Slice Loss Indication (SLI): RFC 4585 (PT=PSFB, FMT=2). > > Reference Picture Selection Indication (RPSI): RFC 4585 (PT=PSFB, > FMT=3). > > Generic NACK: [RFC4585] (PT=RTPFB and FMT=1). > > Other feedback messages includes the target SSRC in the Feedback > Control Information (FCI). Here each FCI needs to be processed > and the SSRC field identified. And the individual FCI combined > with the RTCP packet header context needs to be forwarded to the > identified handler. Example of this pattern are: > > Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). > > Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, > FMT=5). > > Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] > defined message (PT=PSFB, FMT=5) is actually a notifciation in > response to a TSTR this endpoint sent using the SSRC the FCI > identifies as source. > > H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, > FMT=7). > > Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, > FMT=TBD). > > Descriptive or Notifications for an incoming RTP stream: There exist > some RTCP packet types that provides additional information or > notifies about events related to the RTP stream identified. In > these cases the RTP stream is identified using the SSRC field > value, and the information is provided to the higher layer > associated with the "m=" line for the incoming RTP stream as > identified by the current RTP stream to "m=" line table. For this > type of pattern it is common that the RTCP packets and information > is repeated, either periodically (e.g. SDES items), or for a > duration (e.g. BYE), thus suppression of repetitions can be > considered. Examples of these are: > > > > > > Name Expires July 31, 2017 [Page 6] > > Internet-Draft Abbreviated-Title January 2017 > > > Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol > [RFC3550] defines SDES RTCP packets as a way of providing per > source (SSRC) specific information about the source. An SDES > packet contains zero or more chunks, where a chunk contains the > SSRC for the source being described by the one or more items > included in the chunk. Forward the SDES items in each chunk to > the RTP stream's handler. > > Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] > mechanism indicates that a particular RTP stream is leaving the > RTP session. Thus, a most relevant event to inform the handler > for this RTP steam of. > > Third Party Targeted Reports or Feedback: There exist some > multiparty RTP Topologies that results in that an endpoint > receives third party reports (SR [RFC3550], RR [RFC3550] or XR > [RFC3611]) as well as Feedback Messages [RFC4585] that relates to > or targets an SSRC that originates from another endpoint, and > where the source of the RTCP packet is also another endpoint. > This type of packets should be forwarded to the higher layer > function dealing with the third party reporting. And if none > exist then they can be suppressed. As the third party handler can > be focused on determining the conditions for the source of the > reports and feedback, or focused on how the RTP stream source > progresses, or both recommendations can't be made. > > APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that > enables experimentation. The APP packet only specifies the source > of the packet. Thus this information can be related to any of the > "m=" lines, thus deliver a copy of the packet to each "m=" line or > an APP specific handler. > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jan 30 05:29:00 2017 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 BB51412945D; Mon, 30 Jan 2017 05:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 mk-TdxHXH1pR; Mon, 30 Jan 2017 05:28:56 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 7A25812941A; Mon, 30 Jan 2017 05:28:56 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id c85so214601500wmi.1; Mon, 30 Jan 2017 05:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WCyemRK+F02X54eqUnDCZACYAffLtYoODkVIJbvR5sU=; b=VB76go4mAOHi8sOUkXq4pSCF5OzdBSZVsw0uPA9+O4chNL6VxZrCBKC47gXhAF7cDp jjtW0fJ6oYStMKJhuqvc78dXnQSmmjjroC2QVZjUIlWNVVhxoQcjkFsGx0JN+5nJAMdT yw1l1PK9w+QUA5SEatm9ZCvrM3FIeKawgm7nmldJZlmJH+NvXTwim3r8U5ikLhCTIHZI yYBSs9g1yC0kKyEMfclQY1xmA61ci2E5lz5gYc7DlPkwYWeVyfcabD0CIe3NGGewEKD7 L6OEQNUCPL1JxQyJg/1j14C1Afy1piu4B7jUQFPTwB+XOxrvQWbuoqZ3zYjVCE4ZuK5u gJBw== 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:content-transfer-encoding; bh=WCyemRK+F02X54eqUnDCZACYAffLtYoODkVIJbvR5sU=; b=ixNfUMg5omvXLx9McikDcNZqGWKHk1rkMuw3X3XJquAv5a8J5PXV5FyO+qIlK77AFz 44Tt4XajTCTwN6NpTAInTBSDjB+G9f422YeCEDMXYeAF0b6AurlOjcBbzbZbOcM9jZHY o21lTwy955ofMaum56AFebMRdF4R781FFL2tp7KjtN1P1o2UG9fYAjRe0eNXXIzfrT1f nDsdWj++2phi4DiovcFv/XMpPo9nGKBs0uqrWZQS0rfdyNa3Qf77+ZFNbLqPYROuE43F PxZXpId5xa+t7IEQ+PvuVPpYgXu0oEmjPeA3m88cHERvBCd7/iuQ1fQDRPGsT+hQm1F1 Qg3A== X-Gm-Message-State: AIkVDXK8vcFUQXHbt1LkiKR08x3VCsUdW6vOVrDHHnU2zZ/VDXY9oskFz//fFRbVZJkFQExSAnWXnviPotpndA== X-Received: by 10.28.131.132 with SMTP id f126mr15327539wmd.61.1485782934868; Mon, 30 Jan 2017 05:28:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.145.237 with HTTP; Mon, 30 Jan 2017 05:28:54 -0800 (PST) In-Reply-To: References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Victor Pascual Avila Date: Mon, 30 Jan 2017 14:28:54 +0100 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] 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: Mon, 30 Jan 2017 13:28:59 -0000 fine with me On Fri, Jan 27, 2017 at 7:20 PM, Bernard Aboba wr= ote: > I am in favor of the change. > > On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen > wrote: >> >> Hi Harald >> >> Since the document is not yet in Auth48 and the change is relatively >> minor, it is possible to update it during Auth48. >> >> However, from an MMUSIC chair point of view, I would like to get positiv= e >> confirmation from some of the stakeholders that this change is indeed >> desired. Similarly, if anybody has any concerns with the suggested chang= e, >> please send an e-mail to that effect. >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> >> On 1/23/17 10:18 AM, Harald Alvestrand wrote: >>> >>> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >>>> >>>> Ted pointed out to me that I sent this to the wrong group. >>>> >>>> Chairs and members, please advise. >>> >>> My proposed change is here: >>> >>> https://github.com/alvestrand/rtcweb-msid/pull/16 >>> >>> The filed issue is here: >>> >>> https://github.com/alvestrand/rtcweb-msid/issues/15 >>> >>> (CCing RTCWEB - please keep discussion, if any, on mmusic) >>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: [rtcweb] Modifying an approved document: MSID >>>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>>> From: Harald Alvestrand >>>> To: rtcweb@ietf.org >>>> >>>> >>>> >>>> When reviewing the implications of the PeerConnection API change to >>>> support AddTrack rather than AddStream, I found an issue. >>>> >>>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>>> REF-WAIT state (I believe). >>>> >>>> The issue is that it is possible to add a track without specifying a >>>> stream. Since the track's ID needs to be carried, we have to send an >>>> "a=3Dmsid" line, but the track's ID is the *second* field on that line= , >>>> with the first being the stream's ID. >>>> >>>> This creates a problem. >>>> >>>> Suggested fix: Insert two lines in the document: >>>> >>>> 1) On SDP generation: >>>> >>>> "If there is no stream associated with the track, use the reserved ID >>>> value '-'" >>>> >>>> 2) On SDP parsing >>>> >>>> "If the stream ID is the reserved value '-', the track is not associat= ed >>>> with a stream, and no stream is signalled or created." >>>> >>>> If this is OK with the community, I'll issue an updated draft with thi= s >>>> change. >>>> >>>> >>>> -- >>>> Surveillance is pervasive. Go Dark. >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> . >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --=20 Victor Pascual =C3=81vila From nobody Tue Jan 31 00:29:56 2017 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 A954C129444; Tue, 31 Jan 2017 00:29:51 -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, 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 6lK1BrJj936R; Tue, 31 Jan 2017 00:29:49 -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 4800C129430; Tue, 31 Jan 2017 00:29:48 -0800 (PST) X-AuditID: c1b4fb3a-d4bff70000004068-39-58904af91fa5 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id F8.D6.16488.9FA40985; Tue, 31 Jan 2017 09:29:46 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 09:29:35 +0100 To: "mmusic (E-mail)" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" , References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> From: Magnus Westerlund Message-ID: <40af9040-0cd9-0c0c-b10d-ea3256491117@ericsson.com> Date: Tue, 31 Jan 2017 09:29:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7n+4vrwkRBk0HlCymz3rHZjG/Yx2b xdTlj1ks1v5rZ3dg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mu78vs5WML2TseLWgols DYx7U7oYOTkkBEwkFq++wdTFyMUhJLCOUeLa8gZmCGc5o8Tj3W9YQaqEBaolNsz+CVYlIvCE UaJ/wWMWkISQQKnE+4lXwWw2AQuJmz8a2UBsXgF7iSULfjGD2CwCqhI7Hl1iB7FFBWIk3q5f zg5RIyhxcuYTsF5OAQeJh50LgZZxcDAD9T7YWgYSZhaQl2jeOpsZYpW2RENTB+sERv5ZSLpn IXTMQtKxgJF5FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgUB7c8ttqB+PB546HGAU4GJV4 eA16+yOEWBPLiitzDzFKcDArifCqO0+IEOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBA emJJanZqakFqEUyWiYNTqoGRd/nVr7+83yelb8s82xS2nC/mn0uj4SSpEwl638PZG9wmad5a VG3uWCPg5qDzMjFA+Oe57u2p36JOzUvdv2Ra7bN5jieXnnCMVNnSfHmFXt6HPd+N1Lc5aLeG a0yN/id969Htr3K3Ys6KMLkskbsjzvR61fPqaSqza68dC65dEOvU1Gv8fHeZEktxRqKhFnNR cSIAdk9LjEYCAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description 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: Tue, 31 Jan 2017 08:29:52 -0000 Hi, There was a request for a readable diff on github, so I have produced one: http://www.denstore.se/IETF/Diff-jsep-18-part.html However, I will note that it is likely only relevant to see the changes up until the received RTP packet routing steps. Then the changes are so massive due to restructuring that the diff is not particularly useful. I will also note that the text on github has been improved with some language corrections proposed by Bernard Aboba. Cheers Magnus Den 2017-01-30 kl. 14:18, skrev Magnus Westerlund: > Hi, > > I have now generated a pull request for this text, with some very minor > changes. > > https://github.com/rtcweb-wg/jsep/pull/538 > > Cheers > > Magnus > > Den 2017-01-27 kl. 17:43, skrev Magnus Westerlund: >> MMUSIC and RTCWEB, >> >> Here is now a more complete text proposal that also considers the RTCP. >> It also goes further than what Appendix B defines in one aspect, namely >> explicitly considering third party RTCP reporting and what to do with it. >> >> Feedback is much appreciated. I plan to put this into a PR towards JSEP >> APPENDIX B on monday. If only to get the JSEP authors attention ;-). >> However, the text is really intended for the next version of BUNDLE. >> >> >> X. Associating RTP/RTCP With Correct SDP Media Description >> >> As described in [RFC3550], RTP packets are associated with RTP >> streams [RFC7656]. Each RTP stream is identified by an SSRC value, >> and each RTP packet carries an SSRC value that is used to associate >> the packet with the correct RTP stream. RTCP packets also uses SSRCs >> to identify on which RTP streams any report or feedback relate to. >> Thus, an RTCP packet will commonly carry multiple SSRC values, and >> might therefore be providing feedback or report on multiple RTP >> streams. >> >> In order to be able to process received RTP/RTCP packets correctly it >> must be possible to associate an RTP stream with the correct "m=" >> line, as the "m=" line and SDP attributes associated with the "m=" >> line contain information needed to process the packets. >> >> As all RTP streams associated with a BUNDLE group are part of the >> same RTP session and using the same address:port combination for >> sending and receiving RTP/RTCP packets, the local address:port >> combination cannot be used to associate an RTP stream with the >> correct "m=" line. In addition, multiple RTP streams might be >> associated with the same "m=" line. >> >> Also, as described in Section 10.1.1, the same payload type value >> might be used by multiple RTP streams, in which case the payload type >> value cannot be used to associate an RTP stream with the correct "m=" >> line. However, there are cases where each "m=" line has unique >> payload type values, and then the payload type could serve as >> indicator to the relevant "m=" line the RTP stream is associated >> with. >> >> An offerer and answerer can inform each other which SSRC values they >> will use for an RTP stream by using the SDP 'ssrc' attribute >> [RFC5576]. However, an offerer will not know which SSRC values the >> answerer will use until the offerer has received the answer providing >> >> >> >> Name Expires July 31, 2017 [Page 2] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> that information. Due to this, before the offerer has received the >> answer, the offerer will not be able to associate an RTP stream with >> the correct "m=" line using the SSRC value associated with the RTP >> stream. In addition, the offerer and answerer may start using new >> SSRC values mid-session, without informing each other using the SDP >> 'ssrc' attribute. >> >> In order for an offerer and answerer to always be able to associate >> an RTP stream with the correct "m=" line, the offerer and answerer >> using the BUNDLE extension MUST support the mechanism defined in >> Section 14, where the offerer and answerer includes the >> identification-tag (provided by the remote peer) associated with an >> "m=" line in the RTP Streams and in RTCP SDES packets part of a >> BUNDLE group. >> >> The mapping from an SSRC to an identification-tag is carried in RTCP >> SDES packets or in RTP header extensions (Section 14). Since a >> compound RTCP packet can contain multiple RTCP SDES packets, and each >> RTCP SDES packet can contain multiple chunks, an RTCP packet can >> contain several SSRC to identification-tag mappings. The offerer and >> answerer maintain tables mapping RTP streams identified by SSRC to >> "m=" lines identified by the identification-tag. These tables are >> updated each time new information that affects how packets should be >> processed and routed are received. >> >> To prepare for demultiplexing RTP streams to the correct "m=" line, >> the following steps MUST be followed for each BUNDLE group based on >> the SDP signalling information. >> >> Construct a table mapping MID to "m=" line for each "m=" line in >> this BUNDLE group. Note that an "m=" line may only have one MID. >> >> Construct a table mapping incoming RTP streams (SSRCs) to their >> "m=" line for each "m=" line in this BUNDLE group and for each RTP >> stream explicitly signalled for receiving in that "m=" line. >> >> Construct a table mapping payload types to "m=" line for each "m=" >> line in the BUNDLE group and for each payload type configured for >> receiving in that "m=" line. If any payload type is configured >> for receiving in more than one "m=" line in the BUNDLE group, do >> not it include it in the table. >> >> Note that for each of these tables, there can only be one mapping for >> any given key (MID, SSRC, or PT). In other words, the tables are not >> multimaps. >> >> As "m=" lines are added or removed from the BUNDLE groups, or their >> configurations are changed, the tables above MUST also be updated. >> >> >> >> Name Expires July 31, 2017 [Page 3] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> Received RTP packets that are syntactically correct are processed by >> the RTP/RTCP protocol implementation for statistics etc. After this >> processing they need to be routed to the higher layer context >> associated with the "m=" line within the BUNDLE group. Somewhere in >> the process where an received RTP packet is processed to be delivered >> to the higher layer by RTP the matching step below MUST be performed: >> >> 1. Reception of an RTP packet for an RTP stream that has an existing >> mapping in the RTP stream to m= line table. Before proceeding in >> delivering the packet to the higher layer context according to >> the RTP stream to "m=" line mapping table the following checks >> MUST be performed: >> >> A. If the packet carries an RTP header extension with a SDES MID >> value that is not in the table mapping MID to "m=" line, then >> do not deliver the RTP packet to higher layers. >> >> B. If the packet carries an RTP header extension with a SDES MID >> value that is in the table mapping MID to "m=" line, and the >> value indicates a different "m=" line than the current RTP >> stream to "m=" line mapping table, then update the RTP stream >> to "m=" line mapping. >> >> 2. Reception of an RTP packet for an RTP stream that has no existing >> mapping to an m= line. In this case the following actions MUST >> be performed: >> >> A. If the packet carries an RTP header extension with a SDES MID >> value that is in the table mapping MID to "m=" line, then >> create an entry in the RTP stream to "m=" line mapping table >> for this RTP stream (SSRC). Then deliver the RTP packet to >> the "m=" line context of the created mapping and stop. >> >> B. If the packet carries a Payload Type that is in the payload >> type table, then create an entry in the RTP stream to "m=" >> line mapping table for this RTP stream (SSRC). Then deliver >> the RTP packet to the "m=" line context of the created >> mapping and stop. >> >> C. Otherwise do not deliver the RTP packet to higher layers. >> Note, this includes unknown MID values. >> >> For each RTCP packet received (including each RTCP packet that is >> part of a compound RTCP packet), the RTCP packet needs to be >> processed by the RTP/RTCP implementation and relevant information and >> data from the RTCP packets needs to be routed to the appropriate >> handler for the related RTP streams. The appropriate handler is >> determined by using the RTP stream to "m=" line mapping table. >> >> >> >> Name Expires July 31, 2017 [Page 4] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> On reception of any compound RTCP packet prior to dispatching the >> received information and data, if there is an RTCP SDES packet >> included that SHOULD be processed first. If that SDES packet >> contains SDES MID entries, this can results in updates and additions >> to the RTP stream to "m=" line mapping table. Thus each of the SDES >> MID items are processed and the current table entries are checked if >> the corresponding MID value matches the current RTP stream to "m=" >> line mapping, else the entry is updated. If there is no RTP stream >> to "m=" line table mapping entry for the received SDES item's SSRC, >> such an entry is created. Note, that in the process of updating the >> table entries, update flap suppression as discussed in Section 4.2.6 >> of [RFC7941] should be considered. >> >> The various different RTCP packets as well as their various sub >> parts, such as the various RTCP Feedback message types, relates to >> the RTP streams in a couple of different ways. The currently known >> patterns are the following: >> >> Reports on outgoing RTP streams: For all RTP streams that this >> endpoint is the source of, it can expect to receive report blocks >> of several types identified as relating to an outgoing stream. >> The basic pattern for these blocks are that the RTCP packet header >> identifies the source of the reports, as identified by an SSRC, >> and containing one or more report blocks, where each report block >> identifies the RTP stream, using the SSRC, the report relates to. >> For this pattern the relevant report information is provided to >> the higher layer associated with the "m=" line the RTP Stream to >> "m=" line table identifies. The source SSRC as identifier of the >> endpoint that the report originates are relevant for interpreting >> the information, but not necessarily for routing. Example of this >> is pattern are: >> >> Sender Report (SR) and Receiver Report (RR) The basic receiver >> report blocks from RFC3550 start with the SSRC of the RTP >> stream they report on. >> >> Extended Reports (XR): RFC3611 is a framework that enables a >> large number of different reports. However, a large number of >> these report formats are reporting on specific RTP streams and >> thus each individual report of these types contains a SSRC >> field to identify the RTP stream. >> >> RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP >> feedback messages allow for a number of different type of feedback >> messages. However, the RTCP feedback message header contains the >> SSRC identifying the source of the feedback messages as well as >> the actual type of the feedback. Some of the feedback messages >> also uses the target SSRC field in the header to identify which >> >> >> >> Name Expires July 31, 2017 [Page 5] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> RTP stream the feedback is related to. For these types all the >> FCI entries, if multiple ones are forwarded to the identified >> handler. Examples of this pattern are: >> >> Picture Loss Indication (PLI): RFC 4585 (PT=PSFB, FMT=1). >> >> Slice Loss Indication (SLI): RFC 4585 (PT=PSFB, FMT=2). >> >> Reference Picture Selection Indication (RPSI): RFC 4585 (PT=PSFB, >> FMT=3). >> >> Generic NACK: [RFC4585] (PT=RTPFB and FMT=1). >> >> Other feedback messages includes the target SSRC in the Feedback >> Control Information (FCI). Here each FCI needs to be processed >> and the SSRC field identified. And the individual FCI combined >> with the RTCP packet header context needs to be forwarded to the >> identified handler. Example of this pattern are: >> >> Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). >> >> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, >> FMT=5). >> >> Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] >> defined message (PT=PSFB, FMT=5) is actually a notifciation in >> response to a TSTR this endpoint sent using the SSRC the FCI >> identifies as source. >> >> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, >> FMT=7). >> >> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, >> FMT=TBD). >> >> Descriptive or Notifications for an incoming RTP stream: There exist >> some RTCP packet types that provides additional information or >> notifies about events related to the RTP stream identified. In >> these cases the RTP stream is identified using the SSRC field >> value, and the information is provided to the higher layer >> associated with the "m=" line for the incoming RTP stream as >> identified by the current RTP stream to "m=" line table. For this >> type of pattern it is common that the RTCP packets and information >> is repeated, either periodically (e.g. SDES items), or for a >> duration (e.g. BYE), thus suppression of repetitions can be >> considered. Examples of these are: >> >> >> >> >> >> Name Expires July 31, 2017 [Page 6] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol >> [RFC3550] defines SDES RTCP packets as a way of providing per >> source (SSRC) specific information about the source. An SDES >> packet contains zero or more chunks, where a chunk contains the >> SSRC for the source being described by the one or more items >> included in the chunk. Forward the SDES items in each chunk to >> the RTP stream's handler. >> >> Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] >> mechanism indicates that a particular RTP stream is leaving the >> RTP session. Thus, a most relevant event to inform the handler >> for this RTP steam of. >> >> Third Party Targeted Reports or Feedback: There exist some >> multiparty RTP Topologies that results in that an endpoint >> receives third party reports (SR [RFC3550], RR [RFC3550] or XR >> [RFC3611]) as well as Feedback Messages [RFC4585] that relates to >> or targets an SSRC that originates from another endpoint, and >> where the source of the RTCP packet is also another endpoint. >> This type of packets should be forwarded to the higher layer >> function dealing with the third party reporting. And if none >> exist then they can be suppressed. As the third party handler can >> be focused on determining the conditions for the source of the >> reports and feedback, or focused on how the RTP stream source >> progresses, or both recommendations can't be made. >> >> APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that >> enables experimentation. The APP packet only specifies the source >> of the packet. Thus this information can be related to any of the >> "m=" lines, thus deliver a copy of the packet to each "m=" line or >> an APP specific handler. >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jan 31 09:43:36 2017 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 339F412955B; Tue, 31 Jan 2017 09:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no 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 hTXeXrp945tB; Tue, 31 Jan 2017 09:43:29 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 2EF6A129557; Tue, 31 Jan 2017 09:43:29 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0VHYpOi006529; Tue, 31 Jan 2017 12:43:26 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 288n9q9vu7-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Jan 2017 12:43:26 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 31 Jan 2017 11:43:25 -0600 From: Jonathan Lennox To: Magnus Westerlund Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSe+hqNyVXjtU64EysMGTN3ByD2aFTP9MA Date: Tue, 31 Jan 2017 17:43:25 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> In-Reply-To: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701310149 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description 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: Tue, 31 Jan 2017 17:43:31 -0000 In general, this looks good. I have one question, however. What should happen if an RTP packet (without= a MID) is received for a stream that has an existing mapping to an m=3D li= ne, but whose PT is not valid for that m=3D line? Should it 1. Cause the stream=92s mapping to be moved to another m=3D line, if the re= ceived PT is in the payload type table for some other m=3D line? or=20 2. Be an error? In other words, should it be possible for PT-mapping to cause streams to ch= ange their mappings? (Should this decision depend on what caused the stream to be mapped to its = current m=3D line?) > On Jan 27, 2017, at 11:43 AM, Magnus Westerlund wrote: >=20 > MMUSIC and RTCWEB, >=20 > Here is now a more complete text proposal that also considers the RTCP. I= t also goes further than what Appendix B defines in one aspect, namely expl= icitly considering third party RTCP reporting and what to do with it. >=20 > Feedback is much appreciated. I plan to put this into a PR towards JSEP A= PPENDIX B on monday. If only to get the JSEP authors attention ;-). However= , the text is really intended for the next version of BUNDLE. >=20 >=20 > X. Associating RTP/RTCP With Correct SDP Media Description >=20 > As described in [RFC3550], RTP packets are associated with RTP > streams [RFC7656]. Each RTP stream is identified by an SSRC value, > and each RTP packet carries an SSRC value that is used to associate > the packet with the correct RTP stream. RTCP packets also uses SSRCs > to identify on which RTP streams any report or feedback relate to. > Thus, an RTCP packet will commonly carry multiple SSRC values, and > might therefore be providing feedback or report on multiple RTP > streams. >=20 > In order to be able to process received RTP/RTCP 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. >=20 > 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 > associated with the same "m=3D" line. >=20 > Also, as described in Section 10.1.1, the same payload type value > might be used by multiple RTP streams, in which case the payload type > value cannot be used to associate an RTP stream with the correct "m=3D" > line. However, there are cases where each "m=3D" line has unique > payload type values, and then the payload type could serve as > indicator to the relevant "m=3D" line the RTP stream is associated > with. >=20 > An offerer and answerer can inform each other which SSRC values they > will use for an RTP stream by using the SDP 'ssrc' attribute > [RFC5576]. However, an offerer will not know which SSRC values the > answerer will use until the offerer has received the answer providing >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 2] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > 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. >=20 > 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 answerer > using the BUNDLE extension MUST support the mechanism defined in > Section 14, where the offerer and answerer includes the > identification-tag (provided by the remote peer) associated with an > "m=3D" line in the RTP Streams and in RTCP SDES packets part of a > BUNDLE group. >=20 > The mapping from an SSRC to an identification-tag is carried in RTCP > SDES packets or in RTP header extensions (Section 14). Since a > compound RTCP packet can contain multiple RTCP SDES packets, and each > RTCP SDES packet can contain multiple chunks, an RTCP packet can > contain several SSRC to identification-tag mappings. The offerer and > answerer maintain tables mapping RTP streams identified by SSRC to > "m=3D" lines identified by the identification-tag. These tables are > updated each time new information that affects how packets should be > processed and routed are received. >=20 > To prepare for demultiplexing RTP streams to the correct "m=3D" line, > the following steps MUST be followed for each BUNDLE group based on > the SDP signalling information. >=20 > Construct a table mapping MID to "m=3D" line for each "m=3D" line in > this BUNDLE group. Note that an "m=3D" line may only have one MID. >=20 > Construct a table mapping incoming RTP streams (SSRCs) to their > "m=3D" line for each "m=3D" line in this BUNDLE group and for each R= TP > stream explicitly signalled for receiving in that "m=3D" line. >=20 > Construct a table mapping payload types to "m=3D" line for each "m= =3D" > line in the BUNDLE group and for each payload type configured for > receiving in that "m=3D" line. If any payload type is configured > for receiving in more than one "m=3D" line in the BUNDLE group, do > not it include it in the table. >=20 > Note that for each of these tables, there can only be one mapping for > any given key (MID, SSRC, or PT). In other words, the tables are not > multimaps. >=20 > As "m=3D" lines are added or removed from the BUNDLE groups, or their > configurations are changed, the tables above MUST also be updated. >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 3] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > Received RTP packets that are syntactically correct are processed by > the RTP/RTCP protocol implementation for statistics etc. After this > processing they need to be routed to the higher layer context > associated with the "m=3D" line within the BUNDLE group. Somewhere in > the process where an received RTP packet is processed to be delivered > to the higher layer by RTP the matching step below MUST be performed: >=20 > 1. Reception of an RTP packet for an RTP stream that has an existing > mapping in the RTP stream to m=3D line table. Before proceeding in > delivering the packet to the higher layer context according to > the RTP stream to "m=3D" line mapping table the following checks > MUST be performed: >=20 > A. If the packet carries an RTP header extension with a SDES MID > value that is not in the table mapping MID to "m=3D" line, then > do not deliver the RTP packet to higher layers. >=20 > B. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=3D" line, and the > value indicates a different "m=3D" line than the current RTP > stream to "m=3D" line mapping table, then update the RTP stream > to "m=3D" line mapping. >=20 > 2. Reception of an RTP packet for an RTP stream that has no existing > mapping to an m=3D line. In this case the following actions MUST > be performed: >=20 > A. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=3D" line, then > create an entry in the RTP stream to "m=3D" line mapping table > for this RTP stream (SSRC). Then deliver the RTP packet to > the "m=3D" line context of the created mapping and stop. >=20 > B. If the packet carries a Payload Type that is in the payload > type table, then create an entry in the RTP stream to "m=3D" > line mapping table for this RTP stream (SSRC). Then deliver > the RTP packet to the "m=3D" line context of the created > mapping and stop. >=20 > C. Otherwise do not deliver the RTP packet to higher layers. > Note, this includes unknown MID values. >=20 > For each RTCP packet received (including each RTCP packet that is > part of a compound RTCP packet), the RTCP packet needs to be > processed by the RTP/RTCP implementation and relevant information and > data from the RTCP packets needs to be routed to the appropriate > handler for the related RTP streams. The appropriate handler is > determined by using the RTP stream to "m=3D" line mapping table. >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 4] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > On reception of any compound RTCP packet prior to dispatching the > received information and data, if there is an RTCP SDES packet > included that SHOULD be processed first. If that SDES packet > contains SDES MID entries, this can results in updates and additions > to the RTP stream to "m=3D" line mapping table. Thus each of the SDES > MID items are processed and the current table entries are checked if > the corresponding MID value matches the current RTP stream to "m=3D" > line mapping, else the entry is updated. If there is no RTP stream > to "m=3D" line table mapping entry for the received SDES item's SSRC, > such an entry is created. Note, that in the process of updating the > table entries, update flap suppression as discussed in Section 4.2.6 > of [RFC7941] should be considered. >=20 > The various different RTCP packets as well as their various sub > parts, such as the various RTCP Feedback message types, relates to > the RTP streams in a couple of different ways. The currently known > patterns are the following: >=20 > Reports on outgoing RTP streams: For all RTP streams that this > endpoint is the source of, it can expect to receive report blocks > of several types identified as relating to an outgoing stream. > The basic pattern for these blocks are that the RTCP packet header > identifies the source of the reports, as identified by an SSRC, > and containing one or more report blocks, where each report block > identifies the RTP stream, using the SSRC, the report relates to. > For this pattern the relevant report information is provided to > the higher layer associated with the "m=3D" line the RTP Stream to > "m=3D" line table identifies. The source SSRC as identifier of the > endpoint that the report originates are relevant for interpreting > the information, but not necessarily for routing. Example of this > is pattern are: >=20 > Sender Report (SR) and Receiver Report (RR) The basic receiver > report blocks from RFC3550 start with the SSRC of the RTP > stream they report on. >=20 > Extended Reports (XR): RFC3611 is a framework that enables a > large number of different reports. However, a large number of > these report formats are reporting on specific RTP streams and > thus each individual report of these types contains a SSRC > field to identify the RTP stream. >=20 > RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP > feedback messages allow for a number of different type of feedback > messages. However, the RTCP feedback message header contains the > SSRC identifying the source of the feedback messages as well as > the actual type of the feedback. Some of the feedback messages > also uses the target SSRC field in the header to identify which >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 5] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > RTP stream the feedback is related to. For these types all the > FCI entries, if multiple ones are forwarded to the identified > handler. Examples of this pattern are: >=20 > Picture Loss Indication (PLI): RFC 4585 (PT=3DPSFB, FMT=3D1). >=20 > Slice Loss Indication (SLI): RFC 4585 (PT=3DPSFB, FMT=3D2). >=20 > Reference Picture Selection Indication (RPSI): RFC 4585 (PT=3DPSFB, > FMT=3D3). >=20 > Generic NACK: [RFC4585] (PT=3DRTPFB and FMT=3D1). >=20 > Other feedback messages includes the target SSRC in the Feedback > Control Information (FCI). Here each FCI needs to be processed > and the SSRC field identified. And the individual FCI combined > with the RTCP packet header context needs to be forwarded to the > identified handler. Example of this pattern are: >=20 > Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >=20 > Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, > FMT=3D5). >=20 > Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] > defined message (PT=3DPSFB, FMT=3D5) is actually a notifciation i= n > response to a TSTR this endpoint sent using the SSRC the FCI > identifies as source. >=20 > H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, > FMT=3D7). >=20 > Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, > FMT=3DTBD). >=20 > Descriptive or Notifications for an incoming RTP stream: There exist > some RTCP packet types that provides additional information or > notifies about events related to the RTP stream identified. In > these cases the RTP stream is identified using the SSRC field > value, and the information is provided to the higher layer > associated with the "m=3D" line for the incoming RTP stream as > identified by the current RTP stream to "m=3D" line table. For this > type of pattern it is common that the RTCP packets and information > is repeated, either periodically (e.g. SDES items), or for a > duration (e.g. BYE), thus suppression of repetitions can be > considered. Examples of these are: >=20 >=20 >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 6] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol > [RFC3550] defines SDES RTCP packets as a way of providing per > source (SSRC) specific information about the source. An SDES > packet contains zero or more chunks, where a chunk contains the > SSRC for the source being described by the one or more items > included in the chunk. Forward the SDES items in each chunk to > the RTP stream's handler. >=20 > Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] > mechanism indicates that a particular RTP stream is leaving the > RTP session. Thus, a most relevant event to inform the handler > for this RTP steam of. >=20 > Third Party Targeted Reports or Feedback: There exist some > multiparty RTP Topologies that results in that an endpoint > receives third party reports (SR [RFC3550], RR [RFC3550] or XR > [RFC3611]) as well as Feedback Messages [RFC4585] that relates to > or targets an SSRC that originates from another endpoint, and > where the source of the RTCP packet is also another endpoint. > This type of packets should be forwarded to the higher layer > function dealing with the third party reporting. And if none > exist then they can be suppressed. As the third party handler can > be focused on determining the conditions for the source of the > reports and feedback, or focused on how the RTP stream source > progresses, or both recommendations can't be made. >=20 > APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that > enables experimentation. The APP packet only specifies the source > of the packet. Thus this information can be related to any of the > "m=3D" lines, thus deliver a copy of the packet to each "m=3D" line = or > an APP specific handler. >=20 > --=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 From nobody Tue Jan 31 09:57:40 2017 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 E8BD8129524; Tue, 31 Jan 2017 09:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no 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 1B6mGbD-Qu6B; Tue, 31 Jan 2017 09:57:30 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 491211294A5; Tue, 31 Jan 2017 09:57:30 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0VHroDp021261; Tue, 31 Jan 2017 12:57:27 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 288n9q9xad-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Jan 2017 12:57:27 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 31 Jan 2017 11:57:25 -0600 From: Jonathan Lennox To: Magnus Westerlund Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSe+hqNyVXjtU64EysMGTN3ByD2aFTQ7wA Date: Tue, 31 Jan 2017 17:57:25 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> In-Reply-To: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701310151 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description 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: Tue, 31 Jan 2017 17:57:32 -0000 And one more question. This one has significant interop issues, I think. Should decoding contexts be assumed to be associated with streams independe= nt of m=3D lines, or with streams within m=3D lines? Specifically, if a sender moves a video stream from one m=3D line to anothe= r (maintaining its PT), must it send a fresh I-frame (keyframe) at the time= of the move, or can it continue sending inter frames? > On Jan 27, 2017, at 11:43 AM, Magnus Westerlund wrote: >=20 > MMUSIC and RTCWEB, >=20 > Here is now a more complete text proposal that also considers the RTCP. I= t also goes further than what Appendix B defines in one aspect, namely expl= icitly considering third party RTCP reporting and what to do with it. >=20 > Feedback is much appreciated. I plan to put this into a PR towards JSEP A= PPENDIX B on monday. If only to get the JSEP authors attention ;-). However= , the text is really intended for the next version of BUNDLE. >=20 >=20 > X. Associating RTP/RTCP With Correct SDP Media Description >=20 > As described in [RFC3550], RTP packets are associated with RTP > streams [RFC7656]. Each RTP stream is identified by an SSRC value, > and each RTP packet carries an SSRC value that is used to associate > the packet with the correct RTP stream. RTCP packets also uses SSRCs > to identify on which RTP streams any report or feedback relate to. > Thus, an RTCP packet will commonly carry multiple SSRC values, and > might therefore be providing feedback or report on multiple RTP > streams. >=20 > In order to be able to process received RTP/RTCP 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. >=20 > 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 > associated with the same "m=3D" line. >=20 > Also, as described in Section 10.1.1, the same payload type value > might be used by multiple RTP streams, in which case the payload type > value cannot be used to associate an RTP stream with the correct "m=3D" > line. However, there are cases where each "m=3D" line has unique > payload type values, and then the payload type could serve as > indicator to the relevant "m=3D" line the RTP stream is associated > with. >=20 > An offerer and answerer can inform each other which SSRC values they > will use for an RTP stream by using the SDP 'ssrc' attribute > [RFC5576]. However, an offerer will not know which SSRC values the > answerer will use until the offerer has received the answer providing >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 2] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > 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. >=20 > 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 answerer > using the BUNDLE extension MUST support the mechanism defined in > Section 14, where the offerer and answerer includes the > identification-tag (provided by the remote peer) associated with an > "m=3D" line in the RTP Streams and in RTCP SDES packets part of a > BUNDLE group. >=20 > The mapping from an SSRC to an identification-tag is carried in RTCP > SDES packets or in RTP header extensions (Section 14). Since a > compound RTCP packet can contain multiple RTCP SDES packets, and each > RTCP SDES packet can contain multiple chunks, an RTCP packet can > contain several SSRC to identification-tag mappings. The offerer and > answerer maintain tables mapping RTP streams identified by SSRC to > "m=3D" lines identified by the identification-tag. These tables are > updated each time new information that affects how packets should be > processed and routed are received. >=20 > To prepare for demultiplexing RTP streams to the correct "m=3D" line, > the following steps MUST be followed for each BUNDLE group based on > the SDP signalling information. >=20 > Construct a table mapping MID to "m=3D" line for each "m=3D" line in > this BUNDLE group. Note that an "m=3D" line may only have one MID. >=20 > Construct a table mapping incoming RTP streams (SSRCs) to their > "m=3D" line for each "m=3D" line in this BUNDLE group and for each R= TP > stream explicitly signalled for receiving in that "m=3D" line. >=20 > Construct a table mapping payload types to "m=3D" line for each "m= =3D" > line in the BUNDLE group and for each payload type configured for > receiving in that "m=3D" line. If any payload type is configured > for receiving in more than one "m=3D" line in the BUNDLE group, do > not it include it in the table. >=20 > Note that for each of these tables, there can only be one mapping for > any given key (MID, SSRC, or PT). In other words, the tables are not > multimaps. >=20 > As "m=3D" lines are added or removed from the BUNDLE groups, or their > configurations are changed, the tables above MUST also be updated. >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 3] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > Received RTP packets that are syntactically correct are processed by > the RTP/RTCP protocol implementation for statistics etc. After this > processing they need to be routed to the higher layer context > associated with the "m=3D" line within the BUNDLE group. Somewhere in > the process where an received RTP packet is processed to be delivered > to the higher layer by RTP the matching step below MUST be performed: >=20 > 1. Reception of an RTP packet for an RTP stream that has an existing > mapping in the RTP stream to m=3D line table. Before proceeding in > delivering the packet to the higher layer context according to > the RTP stream to "m=3D" line mapping table the following checks > MUST be performed: >=20 > A. If the packet carries an RTP header extension with a SDES MID > value that is not in the table mapping MID to "m=3D" line, then > do not deliver the RTP packet to higher layers. >=20 > B. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=3D" line, and the > value indicates a different "m=3D" line than the current RTP > stream to "m=3D" line mapping table, then update the RTP stream > to "m=3D" line mapping. >=20 > 2. Reception of an RTP packet for an RTP stream that has no existing > mapping to an m=3D line. In this case the following actions MUST > be performed: >=20 > A. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=3D" line, then > create an entry in the RTP stream to "m=3D" line mapping table > for this RTP stream (SSRC). Then deliver the RTP packet to > the "m=3D" line context of the created mapping and stop. >=20 > B. If the packet carries a Payload Type that is in the payload > type table, then create an entry in the RTP stream to "m=3D" > line mapping table for this RTP stream (SSRC). Then deliver > the RTP packet to the "m=3D" line context of the created > mapping and stop. >=20 > C. Otherwise do not deliver the RTP packet to higher layers. > Note, this includes unknown MID values. >=20 > For each RTCP packet received (including each RTCP packet that is > part of a compound RTCP packet), the RTCP packet needs to be > processed by the RTP/RTCP implementation and relevant information and > data from the RTCP packets needs to be routed to the appropriate > handler for the related RTP streams. The appropriate handler is > determined by using the RTP stream to "m=3D" line mapping table. >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 4] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > On reception of any compound RTCP packet prior to dispatching the > received information and data, if there is an RTCP SDES packet > included that SHOULD be processed first. If that SDES packet > contains SDES MID entries, this can results in updates and additions > to the RTP stream to "m=3D" line mapping table. Thus each of the SDES > MID items are processed and the current table entries are checked if > the corresponding MID value matches the current RTP stream to "m=3D" > line mapping, else the entry is updated. If there is no RTP stream > to "m=3D" line table mapping entry for the received SDES item's SSRC, > such an entry is created. Note, that in the process of updating the > table entries, update flap suppression as discussed in Section 4.2.6 > of [RFC7941] should be considered. >=20 > The various different RTCP packets as well as their various sub > parts, such as the various RTCP Feedback message types, relates to > the RTP streams in a couple of different ways. The currently known > patterns are the following: >=20 > Reports on outgoing RTP streams: For all RTP streams that this > endpoint is the source of, it can expect to receive report blocks > of several types identified as relating to an outgoing stream. > The basic pattern for these blocks are that the RTCP packet header > identifies the source of the reports, as identified by an SSRC, > and containing one or more report blocks, where each report block > identifies the RTP stream, using the SSRC, the report relates to. > For this pattern the relevant report information is provided to > the higher layer associated with the "m=3D" line the RTP Stream to > "m=3D" line table identifies. The source SSRC as identifier of the > endpoint that the report originates are relevant for interpreting > the information, but not necessarily for routing. Example of this > is pattern are: >=20 > Sender Report (SR) and Receiver Report (RR) The basic receiver > report blocks from RFC3550 start with the SSRC of the RTP > stream they report on. >=20 > Extended Reports (XR): RFC3611 is a framework that enables a > large number of different reports. However, a large number of > these report formats are reporting on specific RTP streams and > thus each individual report of these types contains a SSRC > field to identify the RTP stream. >=20 > RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP > feedback messages allow for a number of different type of feedback > messages. However, the RTCP feedback message header contains the > SSRC identifying the source of the feedback messages as well as > the actual type of the feedback. Some of the feedback messages > also uses the target SSRC field in the header to identify which >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 5] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > RTP stream the feedback is related to. For these types all the > FCI entries, if multiple ones are forwarded to the identified > handler. Examples of this pattern are: >=20 > Picture Loss Indication (PLI): RFC 4585 (PT=3DPSFB, FMT=3D1). >=20 > Slice Loss Indication (SLI): RFC 4585 (PT=3DPSFB, FMT=3D2). >=20 > Reference Picture Selection Indication (RPSI): RFC 4585 (PT=3DPSFB, > FMT=3D3). >=20 > Generic NACK: [RFC4585] (PT=3DRTPFB and FMT=3D1). >=20 > Other feedback messages includes the target SSRC in the Feedback > Control Information (FCI). Here each FCI needs to be processed > and the SSRC field identified. And the individual FCI combined > with the RTCP packet header context needs to be forwarded to the > identified handler. Example of this pattern are: >=20 > Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >=20 > Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, > FMT=3D5). >=20 > Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] > defined message (PT=3DPSFB, FMT=3D5) is actually a notifciation i= n > response to a TSTR this endpoint sent using the SSRC the FCI > identifies as source. >=20 > H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, > FMT=3D7). >=20 > Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, > FMT=3DTBD). >=20 > Descriptive or Notifications for an incoming RTP stream: There exist > some RTCP packet types that provides additional information or > notifies about events related to the RTP stream identified. In > these cases the RTP stream is identified using the SSRC field > value, and the information is provided to the higher layer > associated with the "m=3D" line for the incoming RTP stream as > identified by the current RTP stream to "m=3D" line table. For this > type of pattern it is common that the RTCP packets and information > is repeated, either periodically (e.g. SDES items), or for a > duration (e.g. BYE), thus suppression of repetitions can be > considered. Examples of these are: >=20 >=20 >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 6] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol > [RFC3550] defines SDES RTCP packets as a way of providing per > source (SSRC) specific information about the source. An SDES > packet contains zero or more chunks, where a chunk contains the > SSRC for the source being described by the one or more items > included in the chunk. Forward the SDES items in each chunk to > the RTP stream's handler. >=20 > Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] > mechanism indicates that a particular RTP stream is leaving the > RTP session. Thus, a most relevant event to inform the handler > for this RTP steam of. >=20 > Third Party Targeted Reports or Feedback: There exist some > multiparty RTP Topologies that results in that an endpoint > receives third party reports (SR [RFC3550], RR [RFC3550] or XR > [RFC3611]) as well as Feedback Messages [RFC4585] that relates to > or targets an SSRC that originates from another endpoint, and > where the source of the RTCP packet is also another endpoint. > This type of packets should be forwarded to the higher layer > function dealing with the third party reporting. And if none > exist then they can be suppressed. As the third party handler can > be focused on determining the conditions for the source of the > reports and feedback, or focused on how the RTP stream source > progresses, or both recommendations can't be made. >=20 > APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that > enables experimentation. The APP packet only specifies the source > of the packet. Thus this information can be related to any of the > "m=3D" lines, thus deliver a copy of the packet to each "m=3D" line = or > an APP specific handler. >=20 > --=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20