From nobody Thu Sep 1 08:59:42 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E320012DA83 for ; Thu, 1 Sep 2016 08:59:40 -0700 (PDT) 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 X1je6sO8IHYZ for ; Thu, 1 Sep 2016 08:59:38 -0700 (PDT) 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 35E7012DA48 for ; Thu, 1 Sep 2016 08:59:32 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id d130so25168704ywc.3 for ; Thu, 01 Sep 2016 08:59:32 -0700 (PDT) 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=gGKF9qkIdp+epVZF3GupkHNDrdAYjSP02UGM9FLfuIk=; b=M5xR23lsb9BX0ZBL5XUf2tCdaYdBDAImR8HxZTn1K+8ypW5z7B+2A3uLVVKbV0zCKB gH3pr+Dp/BbktKX1lCT/jJrmtiBukTxmZc/Po+pxEmtzjDqIC5wfRBwUB0lFphITx0u0 nZRfSaXcCxd76bb+fSmoNIDfYJ7qzY0QCpJ4UsFifTAqqk5OKVHOlYL8PGk/OoEeRVEj Hl9d7450kb/ZGuAHTTgubjIuKfPgKXsZ6WE+IIhdoR8jsuhNTgjMO+weairK3AS0MR34 5L0iF/7nhqk6QnqvY+99i0tfq+NyG59P0kYv67LCXUytYa17xZQQ4U3TK8Ae9I2cDINE wuAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gGKF9qkIdp+epVZF3GupkHNDrdAYjSP02UGM9FLfuIk=; b=TWGhg4RtZ4usafWC1lA2BlbEnpsZo08YNWPtIGcNCbVEyjd2cLJ4DxaafM2H+wVO4y 0bofotjGFkeMpRLJZdANOzsBRCsxvDJqPxThUoj0Oflr/iMSB63KsRHGYbbyhrCAQiCW VJyREWft/NzL9aXIBf4XHJUAnGmg46P7WNV3ZoktHkV0yDy49s6hBnWubLz9t45hIidA tNFEuauyH6YREBXIULhXyYX4UdWfAWcuZY2MW4R1DjP2HTwL77V9630cDn2vbbAWFo8R 5hYG8tgaPmJJ+OW6ZKNFLnj4l/tNmr4a89rzkfPaB3Guu68/2lVZgUGZ5pazyX1CVEgS RZ0A== X-Gm-Message-State: AE9vXwPPBusuPM6Za8AUmETnKGFRzkRU6pRL20g2fpjrffcanczxSahXo0XILJWXxDwoiHDwJ2PAAPQl/CrbtQ== X-Received: by 10.129.161.129 with SMTP id y123mr15497788ywg.214.1472745571490; Thu, 01 Sep 2016 08:59:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Thu, 1 Sep 2016 08:58:51 -0700 (PDT) In-Reply-To: <6975D517-BB5A-4209-BAE2-5CCAB683D321@iii.ca> References: <2AF34981-F961-40FE-83B7-CE0EC64AEBEC@iii.ca> <6975D517-BB5A-4209-BAE2-5CCAB683D321@iii.ca> From: Eric Rescorla Date: Thu, 1 Sep 2016 08:58:51 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a114f8db2a260b8053b744c99 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch and crypto agility 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, 01 Sep 2016 15:59:41 -0000 --001a114f8db2a260b8053b744c99 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 31, 2016 at 3:52 PM, Cullen Jennings wrote: > > > On Aug 31, 2016, at 2:15 PM, Eric Rescorla wrote: > > > > On Wed, Aug 31, 2016 at 10:51 AM, Cullen Jennings wrote: > > The security arch only requires one cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA > with the the P-256 curve. Only having one seems like a bad idea of a crypto > agility point of view. Lets say it turns out there is a problem with that > curve or with EC in general, deployments will not have anything they can > switch to. > > > > Having just one MTI cipher suite is pretty much SOP (this is what TLS > 1.2 does, for instance). > > I wouldn't be opposed to requiring another group, presumably either > X25519 or FFDH2048. > > (Yes, I am aware that these are at opposite ends of the spectrum). > > > > > > I'd like to keep one of the RSA based ciphers as also MTI. > > > > The RSA ciphers do not provide PFS, so I do not think this is a good plan > > > > I was assuming some sort of DH combined with RSA. I do know we want to > stick with PFS schemes. > OK, so in that case it seems like you want TLS_DHE_RSA_WITH_AES_128_CBC_SHA With that said, I think the ship has already sailed on this. Chrome is removing finite field DH from HTTPS and I'm sure they will remove it from WebRTC sooon if it's there at all. Firefox strongly favors the EC suites too. -Ekr --001a114f8db2a260b8053b744c99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 31, 2016 at 3:52 PM, Cullen Jennings <= fluffy@iii.ca> wrote:

> On Aug 31, 2016, at 2:15 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Wed, Aug 31, 2016 at 10:51 AM, Cullen Jennings <fluffy@iii.ca> wrote:
> The security arch only requires one cipher TLS_ECDHE_ECDSA_WITH_AES_12= 8_CBC_SHA with the the P-256 curve. Only having one seems like a bad i= dea of a crypto agility point of view. Lets say it turns out there is a pro= blem with that curve or with EC in general, deployments will not have anyth= ing they can switch to.
>
> Having just one MTI cipher suite is pretty much SOP (this is what TLS = 1.2 does, for instance).
> I wouldn't be opposed to requiring another group, presumably eithe= r X25519 or FFDH2048.
> (Yes, I am aware that these are at opposite ends of the spectrum).
>
>
> I'd like to keep one of the RSA based ciphers as also MTI.
>
> The RSA ciphers do not provide PFS, so I do not think this is a good p= lan
>

I was assuming some sort of DH combined with RSA. I do know we want = to stick with PFS schemes.

OK, so in th= at case it seems like you want=C2=A0

TLS_DHE_RSA_WITH_AES_128_CBC_SHA
With that said, I thin=
k the ship has already sailed on this. Chrome is removing finite field DH f=
rom HTTPS and I'm sure they will remove it from WebRTC sooon if it'=
s there at all. Firefox strongly favors the EC suites too.
-Ekr



--001a114f8db2a260b8053b744c99-- From nobody Sun Sep 4 23:14:18 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF56F12B0BA; Sun, 4 Sep 2016 23:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 vAwtg3rmipTs; Sun, 4 Sep 2016 23:14:09 -0700 (PDT) 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 F11D712B074; Sun, 4 Sep 2016 23:14:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0C0867C94C5; Mon, 5 Sep 2016 08:14:06 +0200 (CEST) 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 K4Z8wbwmXewc; Mon, 5 Sep 2016 08:14:04 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:12:fca1:5183:a845:860a]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2A0DA7C94C4; Mon, 5 Sep 2016 08:14:04 +0200 (CEST) To: Michael Welzl , "Black, David" References: <23F7C863-72FC-47B7-A749-AB6A3B9EBF32@ifi.uio.no> From: Harald Alvestrand Message-ID: <0642b17d-277e-d9ea-665d-ffecc49cd734@alvestrand.no> Date: Mon, 5 Sep 2016 08:14:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <23F7C863-72FC-47B7-A749-AB6A3B9EBF32@ifi.uio.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos - Proposed text 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, 05 Sep 2016 06:14:12 -0000 On 08/31/2016 02:00 PM, Michael Welzl wrote: > Hi all, > > A small follow-up on this: > > given that this paper of ours at ANRW has started this whole discussion= on DSCP blackholing: > https://irtf.org/anrw/2016/anrw16-final17.pdf > > ... I think it would be appropriate for draft-ietf-rtcweb-transports to= cite this paper in the text discussing it. Can you give me the XML blob to insert? It's not unreasonable to cite it as a reference for "there might be a problem", but I'm not going to spend much time constructing the reference= =2E > > Cheers, > Michael > > > >> On 05 Aug 2016, at 23:27, Black, David wrote: >> >> The -15 version of the rtcweb-transports draft has now been posted, an= d the new text on non-zero DSCPs black-holing traffic is in Section 4.2 (= https://tools.ietf.org/html/draft-ietf-rtcweb-transports-15#section-4.2).= Many thanks to Harald for adding this text. >> =20 >> The tsvwg-rtcweb-qos draft needs to note this issue and point to that = section of the rtcweb-transports draft. Here=E2=80=99s proposed text to = do that, which I suggest inserting as a new paragraph in Section 5 immedi= ately before Figure 1 (https://tools.ietf.org/html/draft-ietf-tsvwg-rtcwe= b-qos-17#section-5): >> =20 >> WebRTC use of multiple DSCP values may encounter network blocking o= f packets >> with certain DSCP values. See section 4.2 of [I-D.ietf-rtcweb-tra= nsports] for >> further discussion, including how WebRTC implementations establish = and >> maintain connectivity when such blocking is encountered. >> =20 >> I hope something this short and simple will suffice. >> =20 >> Thanks, --David >> =20 >> From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]=20 >> Sent: Tuesday, August 02, 2016 1:29 PM >> To: Black, David >> Cc: Alissa Cooper; RTCWeb IETF; tsvwg@ietf.org >> Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-= rtcweb-qos ? >> =20 >> Hi, Alissa and David, >> =20 >> Thanks to both of you. I didn't see the minutes on the Proceedings pag= e but didn't think to look for draft minutes on the mailing list. >> =20 >> Very helpful. >> =20 >> Spencer >> =20 >> On Mon, Aug 1, 2016 at 5:12 PM, Black, David wro= te: >>> The -rtcweb-transports author Harald Alvestrand took on the action it= em and will work with Justin Uberti to send a text proposal to the list. >> And when that text appears, we can figure out the wording (probably a = short sentence) to add to the tsvwg-rtcweb-qos draft to point to it over = in the rtcweb-transports draft. >> =20 >> Thanks, --David >> =20 >> From: Alissa Cooper [mailto:alissa@cooperw.in]=20 >> Sent: Monday, August 01, 2016 4:46 PM >> To: Spencer Dawkins at IETF >> Cc: Black, David; RTCWeb IETF; tsvwg@ietf.org >> Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-= rtcweb-qos ? >> =20 >> Hi Spencer, >> =20 >> On Aug 1, 2016, at 6:56 AM, Spencer Dawkins at IETF wrote: >> =20 >> Hi, all, >> =20 >> On Thu, Jul 14, 2016 at 4:13 PM, Black, David wr= ote: >> Magnus, >> >> I think that's a fine suggestion. I think the next step is: >> >>> 3. The natural place to indicate the need/recommendation for >>> implementing this functionality would be in draft-ietf-rtcweb-transpo= rts >>> (Currently in IETF LC). However, here I think we need to have a >>> discussion if RTCWEB WG wants to only place a suitable warning about = the >>> need, and indicate future forthcoming specification or if we hold thi= s >>> document up until this solution is available? >> I'll attend the Thu RTCWEB session in Berlin to see how this comes out= , >> after which it should be straightforward for the draft authors and you= rs >> truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos wi= ll >> need. >> =20 >> I'm just following up on this because we have draft-ietf-rtcweb-transp= orts on the telechat agenda this week, and I didn't see a discussion on t= his topic in the RTCWeb agenda (or in poking around for minutes, jabber, = etherpad, etc).=20 >> =20 >> Here is the relevant bit from the RTCWEB minutes: >> =20 >> DSCP Black-holing Issue >> >> David Black (TSVWG co-chair) presented the DSCP black-hole issue with = -rtcweb-transports draft that was recently discussed on the list. This is= sue needs to be solved and described, even though both -rtcweb-transports= and the referenced draft-ietf-tsvwg-rtcweb-qos has gone through IESG rev= iew. Magnus Westerlund has suggested a solution to the list, but what sho= uld the -rtcweb-transports draft say about DSCP black-holing and the poss= ibility to use ICE to avoid it? >> The WG discussed this and concluded that the issue should be described= by the -rtcweb-transports draft. Ted Hardie summarized the discussion by= suggesting a text formulation for a resolution that seemed acceptable to= the WG: =E2=80=9CWe will treat DSCP-induced path failure parallel with o= ther types of path failures and resolve it by using ICE restart. Note: Th= ere is a problem with multiple DSCP codepoints on a single transport, whe= re one might be blocked and other might get through. In this case, the IC= E probes, using one DSCP codepoint, may succeed while others fail. This i= s complex and should be warned about. A likely viable solution is ICE res= tart with DSCP markings turned off, but detection requires watching the m= ultiple-DCSP-codepoint-using channels for differential failures=E2=80=9D.= If there are other proposals for resolution, please contact Harald. Cull= en Jennings asked David if this solution was acceptable, but David wanted= to see the text proposal. The -rtcweb-transports author Harald Alvestran= d took on the action item and will work with Justin Uberti to send a text= proposal to the list. >> =20 >> Harald has been on holidays since the IETF meeting but will aim to get= to this before the telechat. >> =20 >> Best, >> Alissa >> =20 >> >> =20 >> Did it happen? Was there a resolution? >> =20 >> Thanks, >> =20 >> Spencer >> =20 >> Thanks, --David >> >>> -----Original Message----- >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>> Sent: Thursday, July 14, 2016 4:53 AM >>> To: Cullen Jennings (fluffy); Black, David >>> Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org >>> Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in draft-ietf-tsvwg= -rtcweb-qos ? >>> >>> Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): >>>> short answer here but as David suggested =E2=80=A6 some implementat= ion use >>>> the STUN packets in ICE or just in WebRTC style liveness tests to >>>> do the tests of if a given DSCP works or not. In general ICE is a >>>> good tool to take a bunch of possible paths, test which work, and >>>> select the best. >>> I do agree that how you do the path checks when setting DSCP values != =3D 0 >>> is dependent on the context. For the WebRTC I do agree doing checks >>> using ICE is quite reasonable. >>> >>> We already have similar path testing usages of ICE in the ECN for RTP= >>> specification (RFC6679), see Section 7.2.1. I will note that taking t= his >>> as blueprint for DSCP testing, what is needed clearly requires a new >>> separate specification. The components needs are: 1) A new STUN >>> parameter to request the ICE peer to echo the DSCP field value receiv= ed. >>> 2) A ICE capability parameter to be used in signalling negotiations t= o >>> determine capability for this feature. 3) Behaviour specification on = how >>> to test values and interpret responses. This include things like if o= ne >>> should actually establish multiple candidate pairs one with DSCP test= ing >>> and one without? >>> >>> So the question here is how to proceed with this issue. So I would >>> suggest the following way forward. >>> >>> 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends th= e >>> user to apply path verification methods but don't specify them. >>> >>> 2. Someone takes on the task to write a DSCP path verification extens= ion >>> to ICE. >>> >>> 3. The natural place to indicate the need/recommendation for >>> implementing this functionality would be in draft-ietf-rtcweb-transpo= rts >>> (Currently in IETF LC). However, here I think we need to have a >>> discussion if RTCWEB WG wants to only place a suitable warning about = the >>> need, and indicate future forthcoming specification or if we hold thi= s >>> document up until this solution is available? >>> >>> >>> 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 >> =20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Sep 5 02:00:49 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A9112B353; Mon, 5 Sep 2016 02:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 odona9I8GgAZ; Mon, 5 Sep 2016 02:00:40 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 9DB5612B346; Mon, 5 Sep 2016 02:00:40 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bgplb-0000um-S5; Mon, 05 Sep 2016 11:00:35 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bgplb-0006xQ-05; Mon, 05 Sep 2016 11:00:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <0642b17d-277e-d9ea-665d-ffecc49cd734@alvestrand.no> Date: Mon, 5 Sep 2016 11:00:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23F7C863-72FC-47B7-A749-AB6A3B9EBF32@ifi.uio.no> <0642b17d-277e-d9ea-665d-ffecc49cd734@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 14 sum msgs/h 4 total rcpts 45952 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.152, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 86435CE3E05C4ED9FF4AC662E4F2556EE9C9600D X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 11040 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: RTCWeb IETF , "Black, David" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos - Proposed text 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, 05 Sep 2016 09:00:44 -0000 > On 05 Sep 2016, at 08:14, Harald Alvestrand = wrote: >=20 > On 08/31/2016 02:00 PM, Michael Welzl wrote: >> Hi all, >>=20 >> A small follow-up on this: >>=20 >> given that this paper of ours at ANRW has started this whole = discussion on DSCP blackholing: >> https://irtf.org/anrw/2016/anrw16-final17.pdf >>=20 >> ... I think it would be appropriate for draft-ietf-rtcweb-transports = to cite this paper in the text discussing it. >=20 > Can you give me the XML blob to insert? How to say that you're special: Can we use bits in = the IPv4 header? Cheers, Michael >=20 > It's not unreasonable to cite it as a reference for "there might be a > problem", but I'm not going to spend much time constructing the = reference. >=20 >>=20 >> Cheers, >> Michael >>=20 >>=20 >>=20 >>> On 05 Aug 2016, at 23:27, Black, David wrote: >>>=20 >>> The -15 version of the rtcweb-transports draft has now been posted, = and the new text on non-zero DSCPs black-holing traffic is in Section = 4.2 = (https://tools.ietf.org/html/draft-ietf-rtcweb-transports-15#section-4.2).= Many thanks to Harald for adding this text. >>>=20 >>> The tsvwg-rtcweb-qos draft needs to note this issue and point to = that section of the rtcweb-transports draft. Here=E2=80=99s proposed = text to do that, which I suggest inserting as a new paragraph in Section = 5 immediately before Figure 1 = (https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-17#section-5): >>>=20 >>> WebRTC use of multiple DSCP values may encounter network blocking = of packets >>> with certain DSCP values. See section 4.2 of = [I-D.ietf-rtcweb-transports] for >>> further discussion, including how WebRTC implementations establish = and >>> maintain connectivity when such blocking is encountered. >>>=20 >>> I hope something this short and simple will suffice. >>>=20 >>> Thanks, --David >>>=20 >>> From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]=20= >>> Sent: Tuesday, August 02, 2016 1:29 PM >>> To: Black, David >>> Cc: Alissa Cooper; RTCWeb IETF; tsvwg@ietf.org >>> Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in = draft-ietf-tsvwg-rtcweb-qos ? >>>=20 >>> Hi, Alissa and David, >>>=20 >>> Thanks to both of you. I didn't see the minutes on the Proceedings = page but didn't think to look for draft minutes on the mailing list. >>>=20 >>> Very helpful. >>>=20 >>> Spencer >>>=20 >>> On Mon, Aug 1, 2016 at 5:12 PM, Black, David = wrote: >>>> The -rtcweb-transports author Harald Alvestrand took on the action = item and will work with Justin Uberti to send a text proposal to the = list. >>> And when that text appears, we can figure out the wording (probably = a short sentence) to add to the tsvwg-rtcweb-qos draft to point to it = over in the rtcweb-transports draft. >>>=20 >>> Thanks, --David >>>=20 >>> From: Alissa Cooper [mailto:alissa@cooperw.in]=20 >>> Sent: Monday, August 01, 2016 4:46 PM >>> To: Spencer Dawkins at IETF >>> Cc: Black, David; RTCWeb IETF; tsvwg@ietf.org >>> Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in = draft-ietf-tsvwg-rtcweb-qos ? >>>=20 >>> Hi Spencer, >>>=20 >>> On Aug 1, 2016, at 6:56 AM, Spencer Dawkins at IETF = wrote: >>>=20 >>> Hi, all, >>>=20 >>> On Thu, Jul 14, 2016 at 4:13 PM, Black, David = wrote: >>> Magnus, >>>=20 >>> I think that's a fine suggestion. I think the next step is: >>>=20 >>>> 3. The natural place to indicate the need/recommendation for >>>> implementing this functionality would be in = draft-ietf-rtcweb-transports >>>> (Currently in IETF LC). However, here I think we need to have a >>>> discussion if RTCWEB WG wants to only place a suitable warning = about the >>>> need, and indicate future forthcoming specification or if we hold = this >>>> document up until this solution is available? >>> I'll attend the Thu RTCWEB session in Berlin to see how this comes = out, >>> after which it should be straightforward for the draft authors and = yours >>> truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos = will >>> need. >>>=20 >>> I'm just following up on this because we have = draft-ietf-rtcweb-transports on the telechat agenda this week, and I = didn't see a discussion on this topic in the RTCWeb agenda (or in poking = around for minutes, jabber, etherpad, etc).=20 >>>=20 >>> Here is the relevant bit from the RTCWEB minutes: >>>=20 >>> DSCP Black-holing Issue >>>=20 >>> David Black (TSVWG co-chair) presented the DSCP black-hole issue = with -rtcweb-transports draft that was recently discussed on the list. = This issue needs to be solved and described, even though both = -rtcweb-transports and the referenced draft-ietf-tsvwg-rtcweb-qos has = gone through IESG review. Magnus Westerlund has suggested a solution to = the list, but what should the -rtcweb-transports draft say about DSCP = black-holing and the possibility to use ICE to avoid it? >>> The WG discussed this and concluded that the issue should be = described by the -rtcweb-transports draft. Ted Hardie summarized the = discussion by suggesting a text formulation for a resolution that seemed = acceptable to the WG: =E2=80=9CWe will treat DSCP-induced path failure = parallel with other types of path failures and resolve it by using ICE = restart. Note: There is a problem with multiple DSCP codepoints on a = single transport, where one might be blocked and other might get = through. In this case, the ICE probes, using one DSCP codepoint, may = succeed while others fail. This is complex and should be warned about. A = likely viable solution is ICE restart with DSCP markings turned off, but = detection requires watching the multiple-DCSP-codepoint-using channels = for differential failures=E2=80=9D. If there are other proposals for = resolution, please contact Harald. Cullen Jennings asked David if this = solution was acceptable, but David wanted to see the text proposal. The = -rtcweb-transports author Harald Alvestrand took on the action item and = will work with Justin Uberti to send a text proposal to the list. >>>=20 >>> Harald has been on holidays since the IETF meeting but will aim to = get to this before the telechat. >>>=20 >>> Best, >>> Alissa >>>=20 >>>=20 >>>=20 >>> Did it happen? Was there a resolution? >>>=20 >>> Thanks, >>>=20 >>> Spencer >>>=20 >>> Thanks, --David >>>=20 >>>> -----Original Message----- >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>>> Sent: Thursday, July 14, 2016 4:53 AM >>>> To: Cullen Jennings (fluffy); Black, David >>>> Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org >>>> Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in = draft-ietf-tsvwg-rtcweb-qos ? >>>>=20 >>>> Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): >>>>> short answer here but as David suggested =E2=80=A6 some = implementation use >>>>> the STUN packets in ICE or just in WebRTC style liveness tests = to >>>>> do the tests of if a given DSCP works or not. In general ICE is a >>>>> good tool to take a bunch of possible paths, test which work, and >>>>> select the best. >>>> I do agree that how you do the path checks when setting DSCP values = !=3D 0 >>>> is dependent on the context. For the WebRTC I do agree doing checks >>>> using ICE is quite reasonable. >>>>=20 >>>> We already have similar path testing usages of ICE in the ECN for = RTP >>>> specification (RFC6679), see Section 7.2.1. I will note that taking = this >>>> as blueprint for DSCP testing, what is needed clearly requires a = new >>>> separate specification. The components needs are: 1) A new STUN >>>> parameter to request the ICE peer to echo the DSCP field value = received. >>>> 2) A ICE capability parameter to be used in signalling negotiations = to >>>> determine capability for this feature. 3) Behaviour specification = on how >>>> to test values and interpret responses. This include things like if = one >>>> should actually establish multiple candidate pairs one with DSCP = testing >>>> and one without? >>>>=20 >>>> So the question here is how to proceed with this issue. So I would >>>> suggest the following way forward. >>>>=20 >>>> 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends = the >>>> user to apply path verification methods but don't specify them. >>>>=20 >>>> 2. Someone takes on the task to write a DSCP path verification = extension >>>> to ICE. >>>>=20 >>>> 3. The natural place to indicate the need/recommendation for >>>> implementing this functionality would be in = draft-ietf-rtcweb-transports >>>> (Currently in IETF LC). However, here I think we need to have a >>>> discussion if RTCWEB WG wants to only place a suitable warning = about the >>>> need, and indicate future forthcoming specification or if we hold = this >>>> document up until this solution is available? >>>>=20 >>>>=20 >>>> Cheers >>>>=20 >>>> Magnus Westerlund >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> 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 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 >=20 From nobody Thu Sep 8 03:36:53 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B30B12B228 for ; Thu, 8 Sep 2016 03:36:52 -0700 (PDT) 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 z9Lca7rwTUFh for ; Thu, 8 Sep 2016 03:36:50 -0700 (PDT) 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 2D1B112B0F2 for ; Thu, 8 Sep 2016 03:36:49 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id w12so27456487wmf.0 for ; Thu, 08 Sep 2016 03:36:49 -0700 (PDT) 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=g3xf2B7karqGgObCuInt2vk2uJe87Y8c//oQktMDSLA=; b=sbreneRIci/fNFSHEf0WakMu04OmARbYjEGGxgfyhh5rx0Rc/ZuhGds2UxTo0812pH a9LyTZ+keQbXj+MYLWIEjuLyZKPJVqxNqz+Z7DR8v1AXL613KCOx6Lj0oM9+K2AlWeTN TAYMMLdzKtX2BzJ46vYNy6+TtXOpxO7hIVsPlkd51N9hjgsz1nOB4oBHpmQsvzfgTA9p m4d1hvMp6sIoTKcasuyZoHpbbHR9OIcr2/sT78VTjktdHcW6vJQfDciJRW1QYf+zpNBX WA27WFf2XSHfQPvEnz4P7fnZT6b/DTuxHMzNde2tRSRa18GcPZv9+NPC7r6UzihFWC61 vOiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=g3xf2B7karqGgObCuInt2vk2uJe87Y8c//oQktMDSLA=; b=Nr11E6v3q70wqAFW1BHTptyTNi/9ycsaZQl1RdIJ0TAeBmXY2ZPgMi4Dwi1yDsEI40 c2zTFgHvtl6a0vZ8utsOPxrfJJfK4vqOOkfaSAZkuupWT3AxQEjUcc7IoMib49qJkyff 6oDrzLnj7zm/voZ9xN6Ds02UE4ZZMyM6wj8LYrvBFnckcTFalb1J52Km1rOlI6ZVZHM8 m+0hwkp+50N7jqryX63TXiXk6liR4kV1+v28SyXaPc1yXSXmQJtpBczik7iuzXBcN9Xd dQZa6Ztg2M7MsJSdpuST7rubAOtORg+UjI3p+7kYzFa1gcEWRKK/kULC8oefuWjNpQOG 0nJg== X-Gm-Message-State: AE9vXwO0NoOkRJGvh/fQyEcL8pbhkazsnegylQiWQ0wQNg/5oTqj0qxWkUwhxWDEuBjukZiDhYXGGqZXC7eitw== X-Received: by 10.194.81.106 with SMTP id z10mr8679758wjx.140.1473331008303; Thu, 08 Sep 2016 03:36:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.171.226 with HTTP; Thu, 8 Sep 2016 03:36:27 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 8 Sep 2016 12:36:27 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Codec PT mismatch during renegotiation, valid or not? 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, 08 Sep 2016 10:36:52 -0000 Hi, The following scenario causes setLocalDescription() to fail after renegotiation because the re-offerer (Firefox) introduces new codec PT in the same m=3D line): 1) Chrome calls to Firefox with an audio track. SDP offer (simplified): m=3Daudio 58234 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126 a=3Dsetup:actpass a=3Dmid:audio a=3Dsendrecv a=3Drtcp-mux a=3Drtpmap:111 opus/48000/2 a=3Drtcp-fb:111 transport-cc a=3Dfmtp:111 minptime=3D10;useinbandfec=3D1 a=3Drtpmap:103 ISAC/16000 a=3Drtpmap:104 ISAC/32000 a=3Drtpmap:9 G722/8000 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:106 CN/32000 a=3Drtpmap:105 CN/16000 a=3Drtpmap:13 CN/8000 a=3Drtpmap:126 telephone-event/8000 2) Firefox SDP answer: m=3Daudio 65515 UDP/TLS/RTP/SAVPF 111 a=3Drecvonly a=3Dfmtp:111 maxplaybackrate=3D48000;stereo=3D1 a=3Dmid:audio a=3Drtcp-mux a=3Drtpmap:111 opus/48000/2 a=3Dsetup:active Firefox has chosen PT 111 (opus). Fine. 3) Firefox re-offers with its own audio track. SDP re-offer: m=3Daudio 65515 UDP/TLS/RTP/SAVPF 109 9 0 8 111 a=3Dsendrecv a=3Dfmtp:111 maxplaybackrate=3D48000;stereo=3D1 a=3Dmid:audio a=3Drtcp-mux a=3Drtpmap:109 opus/48000/2 a=3Drtpmap:9 G722/8000/1 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:111 opus/48000/2 a=3Dsetup:actpass Here Firefox has introduced a new PT value: 109 (also opus). Note that PT 111 (opus) is still present. 4) Chrome gets the SDP re-offer, calls setRemoteDescription() (success) and calls createAnswer(), which produces the following SDP answer: m=3Daudio 58234 UDP/TLS/RTP/SAVPF 109 9 0 8 a=3Dsetup:passive a=3Dmid:audio a=3Dsendrecv a=3Drtcp-mux a=3Drtpmap:109 opus/48000/2 a=3Dfmtp:109 minptime=3D10;useinbandfec=3D1 a=3Drtpmap:9 G722/8000 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 Note that Chrome has chosen PT 109 (opus) instead of the previously used PT 111 (opus). 5) Then Chrome calls to setLocalDescription() with such an answer, which produces this error: > Uncaught OperationError: Failed to set local answer sdp: Session error co= de: ERROR_CONTENT. Session error description: Failed to set local audio des= cription recv parameters. So my main question is: can an endpoint perform a PeerConnection renegotiation and introduce new PT values within an existing m=3D line? AFAIR this is NOT valid. - If valid, then this is a Chrome bug. - If invalid, then this is a Firefox bug. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Thu Sep 8 03:42:18 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB4512B2BE for ; Thu, 8 Sep 2016 03:42:16 -0700 (PDT) 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 HXglzhCcpSHI for ; Thu, 8 Sep 2016 03:42:14 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 6031612B0CF for ; Thu, 8 Sep 2016 03:42:14 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id w12so80973848wmf.0 for ; Thu, 08 Sep 2016 03:42:14 -0700 (PDT) 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 :content-transfer-encoding; bh=+s+5P8Bk90f7ZpbVwQbbXyMiGhNBRbvSxPhVN4MHOKs=; b=kkbxu6p5+2eapYDwuO43YxIG/A7wwdNiWjsFLfOTNA9r70OyFSQ0DB2CuFA8F/QO2m HQW+3kbA3ToWEKidblm28SNhJWltwkmQkBBoBE1ShEJ9ljru6SP/bPiQJgF1YB16Layd LvSB64BUXJIqTXP2pSUcSJK3M4y/QbMqYaPYtUKQaJH6auDi9dZ0lwKJs1fymByGM84u 5RtGSEiOe6JKePefpFpSjRAgX/xfB7JETJg1Q/mwjxdMV5cw4ojxr60+gz1egKQVvMEW uQB8h5FiVVHBeGIeuGtMdX6fWlnbM1Ap2y6SHgjXAmjLtf0pwvuVSPCtpYgICvnncftx cRNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=+s+5P8Bk90f7ZpbVwQbbXyMiGhNBRbvSxPhVN4MHOKs=; b=BbkGED4I8Q5yrSiSsLJHz5IuVxFAyGLCUh9nHjyq7VwWRYxY/REcQ07sMdN2yelIdY NawxsU4TpEb7ZY1KOI1oBQ5wyH/1jXGwyGSUkV6XjYTZ/Xj32vP2npPHTuI2R5qOkcxs 6GqmP3AJUv6QUkkgG7pOYhhHhaQC6l7D9vV1mRDYNqDwVG8FXJlHE0bLnHK03hk8NhES AGNSflBE+GJ8/HtfqrWZJZ8Rmm6PMlaskOkm61TmOustoGvBCwzKC0ssRwPFcsFkxz63 Ft/bu9yIib/uA5zM5A3Oy+9U03OFaY5yYwhv/xEPCcGCp9qjPqyREohK2dw7I4LbJ9P7 bkGA== X-Gm-Message-State: AE9vXwN2hSYZlWl3Espfzyx39h+HMkp+p2ASVKv+9Zy/6/4HAy1g3E+qzoVAOVGtnvLq5neLubjrAZV0Ts+rvw== X-Received: by 10.28.14.20 with SMTP id 20mr8632185wmo.6.1473331332612; Thu, 08 Sep 2016 03:42:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.171.226 with HTTP; Thu, 8 Sep 2016 03:41:52 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 8 Sep 2016 12:41:52 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Codec PT mismatch during renegotiation, valid or not? 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, 08 Sep 2016 10:42:17 -0000 2016-09-08 12:36 GMT+02:00 I=C3=B1aki Baz Castillo : > So my main question is: can an endpoint perform a PeerConnection > renegotiation and introduce new PT values within an existing m=3D line? > AFAIR this is NOT valid. Related issue in rtcweb-wg: https://github.com/rtcweb-wg/jsep/issues/266 --=20 I=C3=B1aki Baz Castillo From nobody Thu Sep 8 03:48:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB69312B181 for ; Thu, 8 Sep 2016 03:48:32 -0700 (PDT) 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 d3JP_qP-LZKB for ; Thu, 8 Sep 2016 03:48:31 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F7612B00E for ; Thu, 8 Sep 2016 03:48:31 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id w12so81256450wmf.0 for ; Thu, 08 Sep 2016 03:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=OV/HhHh1CBDLOv29QZeOasWg8mxsVVW/Q/B8tPXQ2Ls=; b=QTml2JuU1a91U0YEiPgcDu+VvJ9bt4VtadugKoOeBCaCWVmj+4PrqddnYTtb3UHI7Y 8FYZTupj5QV7vuh90DjVSUSF1ytiprtDv/gAI7lZ0ZUS3++RiJzpjzhXNRyHriZrcGXH rX86UbZQwZc+LdPjKzUzxFgeoyK5WjXN/1hy5KHZxDO6DyGRhjh3PpoOr2EDsAbTKjFH tEayDgH2Pl6XZWLxo7K+pgsg9R2stCRqOk8S7/OYh4K8MWopSFRBSdmrKB0c17BI3/T1 i5nsfqaSYUoWLC8wYn+dvIOugl7J/ABPEo2p3n/xgMqayclNzE0AMhBbVP6EGRSgV2yN N5kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=OV/HhHh1CBDLOv29QZeOasWg8mxsVVW/Q/B8tPXQ2Ls=; b=mTzyq6MIbwVs0j66qmECSaBYAK994zEpRm9eAi2nf6xGGA9L4Of5yMcgXijYV7CDhM b+D8le8NmbMWvh0rFje3n7p+j3bWAyUy/YtFy4Y+xzzAd9hZ0mf/qUN69M0uV1KZo0bk 08k3MjuuxiMp6nJrk0uvfvG2DcGKG1b2AhokH4QyvUwJ/LGIaRrvf8Vy+oZW74AMdkGN jvozOjZJqfW0vsS5R1kIdtdlmsAuG0jfP/fLYSuWhzruCDPHcQ2gmMeOePtzun/+RUKX q++MFlYaROM79ESUnuLbWHOtbEavhOdAMXYv0lh46L9zG+DOhO6BYlcNxIzXeg8y3Vse ldxQ== X-Gm-Message-State: AE9vXwPh4ynvxOX3UOqu3pEkFcV/CMHE8PvTMkj7dphD31D6EO+sfMXZADSCymThK9nHhg== X-Received: by 10.28.96.65 with SMTP id u62mr8929704wmb.106.1473331709369; Thu, 08 Sep 2016 03:48:29 -0700 (PDT) Received: from [192.168.1.37] (50.red-88-6-120.staticip.rima-tde.net. [88.6.120.50]) by smtp.googlemail.com with ESMTPSA id h7sm43703246wjd.17.2016.09.08.03.48.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 03:48:28 -0700 (PDT) To: rtcweb@ietf.org References: From: Sergio Garcia Murillo Message-ID: Date: Thu, 8 Sep 2016 12:48:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------76C94DED41B268389A6EA50A" Archived-At: Subject: Re: [rtcweb] Codec PT mismatch during renegotiation, valid or not? 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, 08 Sep 2016 10:48:33 -0000 This is a multi-part message in MIME format. --------------76C94DED41B268389A6EA50A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 08/09/2016 12:36, Iñaki Baz Castillo wrote: > So my main question is: can an endpoint perform a PeerConnection > renegotiation and introduce new PT values within an existing m= line? > AFAIR this is NOT valid. > > - If valid, then this is a Chrome bug. > - If invalid, then this is a Firefox bug. Seems valid according to rfc3264: 8.3.2 Changing the Set of Media Formats The list of media formats used in the session MAY be changed. To do this, the offerer creates a new media description, with the list of media formats in the "m=" line different from the corresponding media stream in the previous SDP. This list MAY include new formats, and MAY remove formats present from the previous SDP. However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session. However, it is acceptable for multiple payload type numbers to be mapped to the same codec, so that an updated offer could also use payload type number 72 for G.711. Best regards Sergio --------------76C94DED41B268389A6EA50A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 08/09/2016 12:36, Iñaki Baz Castillo wrote:
So my main question is: can an endpoint perform a PeerConnection
renegotiation and introduce new PT values within an existing m= line?
AFAIR this is NOT valid.

- If valid, then this is a Chrome bug.
- If invalid, then this is a Firefox bug.
Seems valid according to rfc3264:

8.3.2 Changing the Set of Media Formats

   The list of media formats used in the session MAY be changed.  To do
   this, the offerer creates a new media description, with the list of
   media formats in the "m=" line different from the corresponding media
   stream in the previous SDP.  This list MAY include new formats, and
   MAY remove formats present from the previous SDP.  However, in the
   case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session.  For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session.  However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.


Best regards
Sergio
--------------76C94DED41B268389A6EA50A-- From nobody Thu Sep 8 03:54:35 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E7C12B057 for ; Thu, 8 Sep 2016 03:54:33 -0700 (PDT) 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 x0xvx5Ia0NgC for ; Thu, 8 Sep 2016 03:54:32 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 C9E4412B02B for ; Thu, 8 Sep 2016 03:54:27 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id w12so28226229wmf.0 for ; Thu, 08 Sep 2016 03:54:27 -0700 (PDT) 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=uKC+Eg0tW+bjTeUb5V65Jikh+xxexVc2/Ile+jpf0gc=; b=PU6wDNVlnqhxD4sHVvKNp8W5JblxGFHKIpj/SQNyxpNajJkqx3NFkdSI7yeH0UjM16 vAmWbs75VZTIkVOMgsCKoaS9K6e0uLVDnXyhvVBMK8A1PRl1LBFTUtfbmWD7qCj0rR79 2FUU9qHf6xI3dDXML0M+oLaIirhnERJifL2P3uFrKls2IaPM5J6Xmj8t5g4QxJjLj7Er 1xg+LsvxbyxlZEYAtGP/8FQA/0667iU8ykUUeSxxtfcAEW3gGAAJBPFFPt0L8ToMTCCy n+QhBY4GUv0OUiSEjXEbLPo+Cw1vZuLJn/2dlSKyOKa2pqPIM245iIXHEuUCVnqa7FOP wV+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uKC+Eg0tW+bjTeUb5V65Jikh+xxexVc2/Ile+jpf0gc=; b=lLwdj1jERe3NSpTpl8tFQnotX50rE3z4IZT7SQ7sQ65n6DuW+EryaKD9Qg0rNuwGUg 7klLHPLBVEfQkK0zvkcNFfZC1scWMehNBJhS2dASmld8Jm/OIoO2+nLXlcvBUHV4Io1B juz6idMAo9qp/BMp77pFIKjG3xtIK5GDOQJoS4gfRW6IhLh5YX09RU9T1tbkIkqNKqmc uN29guXeCHnXASBoH536OZnihAKxMwMQi39H2SwCVrnlVWytkHQnRWPfPB94QkThQZ58 UPWF9RKG79WtusAHCG7JaFnIPxMhnc3LXWnsPCB9dECwWObBqnJh3WPTSjWoRKD9ZTZy 3sVQ== X-Gm-Message-State: AE9vXwMt6YSvRiVqfw2Zln48vZYS80UiR7XfNpj15ONfzhpJljrI8kNGjz83opGvqVbuVbZeURBO6PQgeqFjFA== X-Received: by 10.194.81.106 with SMTP id z10mr8749703wjx.140.1473332066238; Thu, 08 Sep 2016 03:54:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.171.226 with HTTP; Thu, 8 Sep 2016 03:54:05 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 8 Sep 2016 12:54:05 +0200 Message-ID: To: Sergio Garcia Murillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec PT mismatch during renegotiation, valid or not? 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, 08 Sep 2016 10:54:34 -0000 2016-09-08 12:48 GMT+02:00 Sergio Garcia Murillo : > On 08/09/2016 12:36, I=C3=B1aki Baz Castillo wrote: > > So my main question is: can an endpoint perform a PeerConnection > renegotiation and introduce new PT values within an existing m=3D line? > AFAIR this is NOT valid. > > - If valid, then this is a Chrome bug. > - If invalid, then this is a Firefox bug. > > Seems valid according to rfc3264: > > 8.3.2 Changing the Set of Media Formats > > The list of media formats used in the session MAY be changed. To do > this, the offerer creates a new media description, with the list of > media formats in the "m=3D" line different from the corresponding medi= a > stream in the previous SDP. This list MAY include new formats, and > MAY remove formats present from the previous SDP. However, in the > case of RTP, the mapping from a particular dynamic payload type > number to a particular codec within that media stream MUST NOT change > for the duration of a session. For example, if A generates an offer > with G.711 assigned to dynamic payload type number 46, payload type > number 46 MUST refer to G.711 from that point forward in any offers > or answers for that media stream within the session. However, it is > acceptable for multiple payload type numbers to be mapped to the same > codec, so that an updated offer could also use payload type number 72 > for G.711. Sure. The problem is that such a requirement/feature seems a bit "constrained" in WebRTC, at least according to the discussion in: https://github.com/rtcweb-wg/jsep/issues/266 In that discussion new rules are proposed, so I just don't believe that current browsers respect the 8.3.2 section above... --=20 I=C3=B1aki Baz Castillo From nobody Thu Sep 8 04:07:32 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6A012B0E1 for ; Thu, 8 Sep 2016 04:07:31 -0700 (PDT) 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 PZ1YHW-xIRER for ; Thu, 8 Sep 2016 04:07:27 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 B84E312B0B0 for ; Thu, 8 Sep 2016 04:07:26 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w12so82137501wmf.0 for ; Thu, 08 Sep 2016 04:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=dBeyJipb0drARBhYS1WaWnnS/AOOyfo0mUEO/fYq9GA=; b=OT9JwsJJZRgKvQ0kcSmttxWQsOetKw7isCF05XlVG8pzjJ9CtNF6SyZY1B7oZU7vd5 8lFEZ8q6kdGzxR8JletRleEwL8V2+ZzMgq9MB5R/Q2Jn8sDQmANO58VpWfQyMxOoLbHq wIuNf87b7AY2zYGGOaYEAJrvPIdfaFLsvLoriO6QNyHTqmyistf/Z92woikBBg31NLAP rYmV3tfQQ+LZTHMTcgEWBEHgtzHS/SvtsfCl3SfZ1fgT34TYuQymVeTmEqsrYip8oHs1 IUP4KKo8/Qsac41kK32VSpOjf/k8ejPEQyrOV9ry+r5DUl1ooRCIE4CpHiUjw0HMxgCS raCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=dBeyJipb0drARBhYS1WaWnnS/AOOyfo0mUEO/fYq9GA=; b=Ww7wNo96mb1fKn115blXAa0kPpz1T31/2aeVv3SyKteSpcwYsniLtgHeeAAyuky101 j6AidOvngmHyP6Ai40Sah+32q+TnwQn5so1tBYTzLLmA5cfLRcJxOrfrtgJa47Z9STMn in5DxlSOtl2mtCJYnsF+koUn6eg8EMfwhJgLJFTzFi/+oCOSIgESufsVW8tfHob9HVxQ 4P+YI41mY8s0zmA5HMNXPcA3EnU5PiWoQ/jWfKcPL2/SIOs/Zl8gHx3tF9HuMiEN3+hl GBv7VVSbMkV4Uj3Be6T/FvMTKWv34HbDJPl70PB3JMBNF/KgkxDNa4UiXCHIB84AZEf3 gCyw== X-Gm-Message-State: AE9vXwPEc02GpXlRcRBCTUgkUKEwFw3Tike5xp+dGda4jcCxALm4ZMQgelSIB/66R17QuQ== X-Received: by 10.194.83.193 with SMTP id s1mr15820645wjy.186.1473332845060; Thu, 08 Sep 2016 04:07:25 -0700 (PDT) Received: from [192.168.1.37] (50.red-88-6-120.staticip.rima-tde.net. [88.6.120.50]) by smtp.googlemail.com with ESMTPSA id 12sm20261954wjx.42.2016.09.08.04.07.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 04:07:24 -0700 (PDT) To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= References: From: Sergio Garcia Murillo Message-ID: <622b914f-6fcc-56b4-b444-70d7622ac2a5@gmail.com> Date: Thu, 8 Sep 2016 13:07:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FB160B4CF3B8FEC06086B38E" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec PT mismatch during renegotiation, valid or not? 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, 08 Sep 2016 11:07:31 -0000 This is a multi-part message in MIME format. --------------FB160B4CF3B8FEC06086B38E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 08/09/2016 12:54, Iñaki Baz Castillo wrote: > 2016-09-08 12:48 GMT+02:00 Sergio Garcia Murillo > : >> On 08/09/2016 12:36, Iñaki Baz Castillo wrote: >> >> So my main question is: can an endpoint perform a PeerConnection >> renegotiation and introduce new PT values within an existing m= line? >> AFAIR this is NOT valid. >> >> - If valid, then this is a Chrome bug. >> - If invalid, then this is a Firefox bug. >> >> Seems valid according to rfc3264: >> >> 8.3.2 Changing the Set of Media Formats >> >> The list of media formats used in the session MAY be changed. To do >> this, the offerer creates a new media description, with the list of >> media formats in the "m=" line different from the corresponding media >> stream in the previous SDP. This list MAY include new formats, and >> MAY remove formats present from the previous SDP. However, in the >> case of RTP, the mapping from a particular dynamic payload type >> number to a particular codec within that media stream MUST NOT change >> for the duration of a session. For example, if A generates an offer >> with G.711 assigned to dynamic payload type number 46, payload type >> number 46 MUST refer to G.711 from that point forward in any offers >> or answers for that media stream within the session. However, it is >> acceptable for multiple payload type numbers to be mapped to the same >> codec, so that an updated offer could also use payload type number 72 >> for G.711. > Sure. The problem is that such a requirement/feature seems a bit > "constrained" in WebRTC, at least according to the discussion in: > > https://github.com/rtcweb-wg/jsep/issues/266 > > In that discussion new rules are proposed, so I just don't believe > that current browsers respect the 8.3.2 section above... > It should be still valid based on current jsep draft: 5.2.2. Subsequent Offers o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include codecs present in the most recent answer. Except if it is a typo and it was meant to read "payload types" and not "codecs". Best regards Sergio --------------FB160B4CF3B8FEC06086B38E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 08/09/2016 12:54, Iñaki Baz Castillo wrote:
2016-09-08 12:48 GMT+02:00 Sergio Garcia Murillo
<sergio.garcia.murillo@gmail.com>:

On 08/09/2016 12:36, Iñaki Baz Castillo wrote:

So my main question is: can an endpoint perform a PeerConnection
renegotiation and introduce new PT values within an existing m= line?
AFAIR this is NOT valid.

- If valid, then this is a Chrome bug.
- If invalid, then this is a Firefox bug.

Seems valid according to rfc3264:

8.3.2 Changing the Set of Media Formats

   The list of media formats used in the session MAY be changed.  To do
   this, the offerer creates a new media description, with the list of
   media formats in the "m=" line different from the corresponding media
   stream in the previous SDP.  This list MAY include new formats, and
   MAY remove formats present from the previous SDP.  However, in the
   case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session.  For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session.  However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.

Sure. The problem is that such a requirement/feature seems a bit
"constrained" in WebRTC, at least according to the discussion in:

https://github.com/rtcweb-wg/jsep/issues/266

In that discussion new rules are proposed, so I just don't believe
that current browsers respect the 8.3.2 section above...

It should be still valid based on current jsep draft:

5.2.2.  Subsequent Offers 
   o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
      only include codecs present in the most recent answer.

Except if it is a typo and it was meant to read "payload types" and not "codecs".

Best regards

Sergio
--------------FB160B4CF3B8FEC06086B38E-- From nobody Thu Sep 8 04:13:27 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480C112B275 for ; Thu, 8 Sep 2016 04:13:25 -0700 (PDT) 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 sjB7PmGzAjWc for ; Thu, 8 Sep 2016 04:13:22 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 1FD9712B28D for ; Thu, 8 Sep 2016 04:13:20 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 1so82171089wmz.1 for ; Thu, 08 Sep 2016 04:13:20 -0700 (PDT) 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=ZL5GXzGeY4QvBVizXyFx0YMl34Vwg6EjUOzYWxjO9Dg=; b=c5t/v8LcT5Ku8+d0kZ8lFaUc76UtPxPV7wMufkF3aiC1X5N4T8VhCDq70m/Uy7yPFq IFyzh18bx13x19f1RM0UdCUT86+wLUVaepUROpqhvNgqEscmlDaj1NqZMS8NBAFpJbWx x2Z1ESYv1/ukVPVNP0mKVP1+Z/2x5zu5ipxV7UUY9fnUx8qeFmym85HRAtYRP3to0s85 iwqtHosxUsXehbihNpUMwJ9+LIpja6K7SR6BGm0h2ItC9bfAWJuYq/HKJCNThcjpvgqg SiFMKE8P/qZ58YYcaLGcHQ46lW9FvqDngA/A+ISXSPMciDfqUfxUUoDtq4Baa3qJKDmY 7gdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZL5GXzGeY4QvBVizXyFx0YMl34Vwg6EjUOzYWxjO9Dg=; b=RgMSxEnY6C4n7yiP32zGO3iyY0o9xaSYVYOAI/ab3xWVXgg7N8T4yJPtmgtmMlu2gB 4ErlyOUNTrArPM23mrN5XN9HLLGT3I1apvdolgMkefYI3LmJblABu4GH3Gq1ewdQvbyQ Ba99SAGw4s5tATM9gwjxQSbQRLIInh5gyCI0S1TCTLjAiu86Jdx/2jhzJba9pWiVBQmx 9If2Tl3ECorgBPBiLLItIrEJzFXAbDaK24qYofskm0yvEo/uaGkVvnMw8Lq0WPcPCeDo RfKrVmFYMxQgy1Bumc2xqh7COz+1IGfeSkxRUz17m6daCwWux+LzQYfgraZNWIeHdPyo eztQ== X-Gm-Message-State: AE9vXwOXHIgIMY7h+3FAp9KhN08qrFGlkmu5pv41e0ry7of/qdCBvvaf6ZgyAB0yFnp/Yy8K4MEMTnEnhQQocQ== X-Received: by 10.28.9.7 with SMTP id 7mr8690542wmj.95.1473333199176; Thu, 08 Sep 2016 04:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.171.226 with HTTP; Thu, 8 Sep 2016 04:12:58 -0700 (PDT) In-Reply-To: <622b914f-6fcc-56b4-b444-70d7622ac2a5@gmail.com> References: <622b914f-6fcc-56b4-b444-70d7622ac2a5@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 8 Sep 2016 13:12:58 +0200 Message-ID: To: Sergio Garcia Murillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec PT mismatch during renegotiation, valid or not? 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, 08 Sep 2016 11:13:25 -0000 2016-09-08 13:07 GMT+02:00 Sergio Garcia Murillo : > It should be still valid based on current jsep draft: > > 5.2.2. Subsequent Offers > o The m=3D line and corresponding "a=3Drtpmap" and "a=3Dfmtp" lines M= UST > only include codecs present in the most recent answer. > > Except if it is a typo and it was meant to read "payload types" and not > "codecs". IMHO that's the point: - What do authors mean with "codec"? - What do browser implementors understand? BTW issue open in Chrome project because setLocalDescription() MUST always work after a successful createAnswer(): https://bugs.chromium.org/p/chromium/issues/detail?id=3D645062 --=20 I=C3=B1aki Baz Castillo From nobody Thu Sep 8 05:53:48 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09C412B14F for ; Thu, 8 Sep 2016 05:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 1Yt6KZCicdwZ for ; Thu, 8 Sep 2016 05:53:42 -0700 (PDT) Received: from nov-007-i607.relay.mailchannels.net (nov-007-i607.relay.mailchannels.net [46.232.183.161]) (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 0B91A12B27D for ; Thu, 8 Sep 2016 05:31:52 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1A7671BCCB9 for ; Thu, 8 Sep 2016 12:31:47 +0000 (UTC) Received: from rcentral501.webserversystems.com (ip-10-120-4-226.us-west-2.compute.internal [10.120.4.226]) by relay.mailchannels.net (Postfix) with ESMTPA id 695C01BD53B for ; Thu, 8 Sep 2016 12:31:46 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from rcentral501.webserversystems.com ([TEMPUNAVAIL]. [10.28.138.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.7.8); Thu, 08 Sep 2016 12:31:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1473337906634:1751339331 X-MC-Ingress-Time: 1473337906634 Received: from pool-108-16-238-163.phlapa.fios.verizon.net ([108.16.238.163]:63253 helo=[192.168.1.12]) by rcentral501.webserversystems.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bhyVQ-0000A4-7C for rtcweb@ietf.org; Thu, 08 Sep 2016 08:32:36 -0400 References: <622b914f-6fcc-56b4-b444-70d7622ac2a5@gmail.com> To: rtcweb@ietf.org From: Randell Jesup Message-ID: Date: Thu, 8 Sep 2016 08:30:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Codec PT mismatch during renegotiation, valid or not? 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, 08 Sep 2016 12:53:47 -0000 On 9/8/2016 7:12 AM, I=C3=B1aki Baz Castillo wrote: > 2016-09-08 13:07 GMT+02:00 Sergio Garcia Murillo > : >> It should be still valid based on current jsep draft: >> >> 5.2.2. Subsequent Offers >> o The m=3D line and corresponding "a=3Drtpmap" and "a=3Dfmtp" lin= es MUST >> only include codecs present in the most recent answer. >> >> Except if it is a typo and it was meant to read "payload types" and no= t >> "codecs". > IMHO that's the point: > > - What do authors mean with "codec"? > - What do browser implementors understand? 'codec' means the codec specified in the rtpmap. It does not refer to=20 the configuration of the codec as specified for a specific payload=20 type. You can have N payload types for the same codec, each with=20 different (or even the same) configuration (typically in a=3Dfmtp lines,=20 though some others can affect it IIRC). In this case, it's an innocuous bug in Firefox that it offers two=20 payloads for the same codec/configuration in this situation. There's a=20 real bug (as you note) in Chrome with not accepting their own Answer SDP. > BTW issue open in Chrome project because setLocalDescription() MUST > always work after a successful createAnswer(): > > https://bugs.chromium.org/p/chromium/issues/detail?id=3D645062 --=20 Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much sp= am From nobody Thu Sep 8 07:26:43 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AB312B1A6 for ; Thu, 8 Sep 2016 07:26:42 -0700 (PDT) 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 8eKYvztiSP4B for ; Thu, 8 Sep 2016 07:26:38 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53ED412B049 for ; Thu, 8 Sep 2016 07:26:38 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id b187so172268849wme.1 for ; Thu, 08 Sep 2016 07:26:38 -0700 (PDT) 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=mNZqmnTXsX4bafH8sAL3AMIWbm/wvPtIFGwiULAYjVA=; b=RLD+Yi6cOmgHmii5p4ZKOc7fjH9g8SGZEyvP+WmpPNy5A4BzyyfpAnzIf+BzNCyJE5 tn7bwyXcXhP3ylsXPQO5dWKe7Voeygon2SLeqNTTI8J9C8Nj7OOe9i5ITfOHyqwTgPG2 GXSvzYJBTmneEFwuViMGYtWl+Q0C/3uJFpikEBV5sI3jyYQZx/xUFRC+/NZEU7+9+fyt 4UsBfJAC5Ms286dyxXYk/i1h0eIE6OMTcFCcEdo0NqflLjMp/xoTC3QmtcQ+fGVu4qjn jOgTwPC09WOdPzxl5qhHLV3rNX33mX66rti1GzyjyuKWSFpLmJnShZF8R0uNtKy3n3xs LOrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mNZqmnTXsX4bafH8sAL3AMIWbm/wvPtIFGwiULAYjVA=; b=bnLezWmd883yvsN83DGGe/zuVCz/UWX2oKolRBLFyH599QF2rUIjcDaohitzqUx0L+ yE+wMpd09NdfXGrGpwJCRQ/a6sC/VyXY8YXG+zpaGu0N56toMxMP/WnzLq40Va5DqcSe agz3VtCwCDxCDo36GbxjxWFOEjlHvsR5QMwzpOfr8fEKoA8OO6lJ2rbfmwqQLXhvYy79 GxgX8zQqZQp1MuL+3A/7EOTB3DiKNPoD55VissMsDl5UIlQkE5OHXvRelihhXPfYxIo+ 1BmW0Nix3DjQzg9/yKEvkNsuwuDzUj8MItcPwjbm5QUYG3VoyVmGakl8Y4LY6Ul0rsPL U+uQ== X-Gm-Message-State: AE9vXwMZyky5HQ+aq55G0eFr65V7oWhBMI8WRJqg06+a0jMM4E/lftP9rO9uPXQEqlV3GFG5rywgzAqqbwhJbg== X-Received: by 10.194.110.229 with SMTP id id5mr45692980wjb.23.1473344796777; Thu, 08 Sep 2016 07:26:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.171.226 with HTTP; Thu, 8 Sep 2016 07:26:16 -0700 (PDT) In-Reply-To: References: <622b914f-6fcc-56b4-b444-70d7622ac2a5@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 8 Sep 2016 16:26:16 +0200 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec PT mismatch during renegotiation, valid or not? 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, 08 Sep 2016 14:26:42 -0000 2016-09-08 14:30 GMT+02:00 Randell Jesup : > 'codec' means the codec specified in the rtpmap. It does not refer to th= e > configuration of the codec as specified for a specific payload type. You > can have N payload types for the same codec, each with different (or even > the same) configuration (typically in a=3Dfmtp lines, though some others = can > affect it IIRC). Thanks, clarified. > In this case, it's an innocuous bug in Firefox that it offers two payload= s > for the same codec/configuration in this situation. There's a real bug (as > you note) in Chrome with not accepting their own Answer SDP. Note that they are not the "same codec configurations" (although AFAIK those are informative OPUS parameters): m=3Daudio 65515 UDP/TLS/RTP/SAVPF 109 9 0 8 111 a=3Dfmtp:111 maxplaybackrate=3D48000;stereo=3D1 a=3Drtpmap:109 opus/48000/2 a=3Drtpmap:111 opus/48000/2 Regarding the Firefox issue, my guess is the following: - When Firefox receives the initial SDP offer it places PT 111 as a receiving opus codec. - Later when Firefox adds its own audio track and renegotiates, it adds a *new* PT (109) for its new audio track. - Probably, if the initial SDP used 109 for opus (rather than 111) Firefox would not duplicate the codec payload in its re-offer. --=20 I=C3=B1aki Baz Castillo From nobody Wed Sep 14 10:49:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC62B12B3E4 for ; Wed, 14 Sep 2016 10:49:32 -0700 (PDT) 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 2BFLf7u31rTH for ; Wed, 14 Sep 2016 10:49:31 -0700 (PDT) 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 CDDDC12B3F0 for ; Wed, 14 Sep 2016 10:49:30 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id i129so33567238ywb.0 for ; Wed, 14 Sep 2016 10:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=810hlTcnbp1pJ6p9DW6rh0vvfsi/8ZzuKe7WdhrJ5pQ=; b=NQ4+Q0r16Cpkm5RUwMNrpzE6vRSyJn2mlBH91HGc+ep34eWIu7fOmUJIDYm2tNMIJR pwr+eViOUw1eTmnA3uhg9PBR59MBNEgQaQczk3+wIGi6lye0iw+peUCoQCB3iggdVcCY KjPffnJNWW/gdDh/SsqOe6rAQ+Hn8UD8LAx0kyp89TyJYoDGFROyGT87EhKHS6RFkRsi qNUxGDXBFHkD5/N70AkEx0jiU2PWEPuGbK6zXWjSRESN3tgAyF6NONUK3dAMCtrBNuaN 54AIUauEsAx9rcgqV7R26EsySqax9SFTPWVthrwY2icQYrF+ipd8ieMQR1nRPXuuG3M+ o6iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=810hlTcnbp1pJ6p9DW6rh0vvfsi/8ZzuKe7WdhrJ5pQ=; b=Xy1AoBPt1h2OB4jxgpSIyUjnlcZyaRasEeKg5pa7Z963lm78Z5oQSQGAe2Vhvw52C0 QOIjhfWtVC2+CW5ZiDvM9xCZsP8VUAP7qzx8ei+3C6PbeZTMe8gtTHZPaSV/IH4s7vuv P2qaniPFWXtRuRWugeXkiy7pFxrQjYF+m5t5WIO/iML9mSSvfDKHjlNpLY9Rd/r35DMJ k+BCza64llJrJ3ud2pQXzZUEv4q5mw26jEw7rM6q53MufaAKz4TiioE2y2VZYq6b1WV7 PuKt8a+S6MW5RAALSSphgv/lXhLjk8lh4OvkxyWDKvSwJKBbSn3+sgp94Mgt86TcUP6q mkkg== X-Gm-Message-State: AE9vXwMYclwXil7dyIT3+qwY7AAOMgcH21xtIoJZ9FqmYKNULbWbleMbBnTr0e5x5AECV3QepbmH/o6JjicPaw== X-Received: by 10.129.27.10 with SMTP id b10mr4097728ywb.316.1473875370113; Wed, 14 Sep 2016 10:49:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.105 with HTTP; Wed, 14 Sep 2016 10:49:09 -0700 (PDT) From: Bernard Aboba Date: Wed, 14 Sep 2016 10:49:09 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1142928ae106b8053c7b5908 Archived-At: Cc: Robin R Subject: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:49:33 -0000 --001a1142928ae106b8053c7b5908 Content-Type: text/plain; charset=UTF-8 There is now a JSEP PR relating to RTP demux algorithms: https://github.com/rtcweb-wg/jsep/pull/320 Rather than commenting in detail on that PR in this post, I would like to prove some thoughts on how we evaluate proposed RTP demux algorithms. The goal of an RTP demux algorithm is to determine whether an incoming RTP packet received on a DtlsTransport can be forwarded to one of the RtpReceivers attached to that DtlsTransport. If none of the RtpReceivers qualify, then the packet is either dropped (WebRTC 1.0) or generates an RTP unhandled event (ORTC). In principle, RTP demux algorithms do not seem complicated, since they often can be expressed in less than half a dozen steps, typically with less than a page of text. However, in practice the difficulty has turned out to be not in stating an algorithm, but in evaluating whether it is correct. This challenges include: 1. Agreement on a set of use cases and desired outcomes that a proposed algorithm must satisfy. Think of this as a set of regression tests that insure that a proposed algorithm behaves as we expect, as well as ensuring that changes to that algorithm do not result in unintended consequences. 2. Agreement on all the inputs that the algorithm takes into account. This includes fields within the RTP packet (e.g. SSRC, PT, RID, MID, etc.) as well as methods within the API (e.g. setLocalDescription, setRemoteDescription, setParameters, etc.). With respect to Issue #1, some of the trickiest use cases involve both PT and SSRC signaling, SSRC "latching" and handling FEC and RTX. Examples include: a. Change of SSRCs (e.g. due to conflict). b. Codec switching (e.g. changing PT but same SSRC, or changing both PT and SSRC). c. Use of both FEC and RTX (and perhaps RTX of FEC). IMHO it would be useful to come up a few (less than half a dozen) use cases with agreed-upon outcomes. With respect to Issue #2, the proposed algorithms so far look at the SSRC & PT fields in the RTP header as well as the MID RTP extension. However, I have not seen algorithms which take into account the role of the RID RTP extension. So agreement on whether the RID needs to be considered or not would be helpful. Also, for WebRTC 1.0 it would appear to me that the algorithm will depend on the inputs to the setLocalDescription/setRemoteDescription methods, so that there is a potential dependency on the signaling state of the PeerConnection. Overall, I believe that the discussion of RTP demux algorithms is likely to go more smoothly (and conclude more quickly) if we get agreement on these meta-issues upfront. --001a1142928ae106b8053c7b5908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is now a JSEP PR relating to RTP demux algorithms:= =C2=A0

Rather t= han commenting in detail on that PR in this post, I would like to prove som= e thoughts on how we evaluate proposed RTP demux algorithms.=C2=A0

The goal of an RTP demux algorithm is to determine whether= an incoming RTP packet received on a DtlsTransport can be forwarded to one= of the RtpReceivers attached to that DtlsTransport.=C2=A0 If none of the R= tpReceivers qualify, then the packet is either dropped (WebRTC 1.0) or gene= rates an RTP unhandled event (ORTC).=C2=A0

In prin= ciple, RTP demux algorithms do not seem complicated, since they often can b= e expressed in less than half a dozen steps, typically with less than a pag= e of text.=C2=A0

However, in practice the difficul= ty has turned out to be not in stating an algorithm, but in evaluating whet= her it is correct. This challenges include:=C2=A0

= 1. Agreement on a set of use cases and desired outcomes that a proposed alg= orithm must satisfy.=C2=A0 Think of this as a set of regression tests that = insure that a proposed algorithm behaves as we expect, as well as ensuring = that changes to that algorithm do not result in unintended consequences.=C2= =A0

2. Agreement on all the inputs that the algori= thm takes into account.=C2=A0 This includes fields within the RTP packet (e= .g. SSRC, PT, RID, MID, etc.) as well as methods within the API (e.g. setLo= calDescription, setRemoteDescription, setParameters, etc.).=C2=A0

With respect to Issue #1, some of the trickiest use cases i= nvolve both PT and SSRC signaling, SSRC "latching" and handling F= EC and RTX.=C2=A0 Examples include:=C2=A0
=C2=A0 =C2=A0 a. Change= of SSRCs (e.g. due to conflict).=C2=A0
=C2=A0 =C2=A0 b. Codec sw= itching (e.g. changing PT but same SSRC, or changing both PT and SSRC).
=C2=A0 =C2=A0 c. Use of both FEC and RTX (and perhaps RTX of FEC).

IMHO it would be useful to come up a few (less than= half a dozen) use cases with agreed-upon outcomes.

With respect to Issue #2, the proposed algorithms so far look at the SSRC= & PT fields in the RTP header as well as the MID RTP extension.=C2=A0 = However, I have not seen algorithms which take into account the role of the= RID RTP extension.=C2=A0 So agreement on whether the RID needs to be consi= dered or not would be helpful.=C2=A0

Also, for Web= RTC 1.0 it would appear to me that the algorithm will depend on the inputs = to the setLocalDescription/setRemoteDescription methods, so that there is a= potential dependency on the signaling state of the PeerConnection.

Overall, I believe that the discussion of RTP demux algor= ithms is likely to go more smoothly (and conclude more quickly) if we get a= greement on these meta-issues upfront.=C2=A0


<= /div>





<= /div>





<= /div>
--001a1142928ae106b8053c7b5908-- From nobody Wed Sep 14 11:31:29 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10AE12B3F5 for ; Wed, 14 Sep 2016 11:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] 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 pvImkkcj99so for ; Wed, 14 Sep 2016 11:31:25 -0700 (PDT) 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 8CE4112B004 for ; Wed, 14 Sep 2016 11:31:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B48367C8AD9; Wed, 14 Sep 2016 20:31:23 +0200 (CEST) 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 z4W0HDVyiRfk; Wed, 14 Sep 2016 20:31:22 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:989c:ea03:641b:d87] (unknown [IPv6:2001:470:de0a:1:989c:ea03:641b:d87]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7F0E07C8507; Wed, 14 Sep 2016 20:31:22 +0200 (CEST) To: Cullen Jennings , Christer Holmberg References: <1F054785-35C3-4C78-BA68-9C1FA8C06633@iii.ca> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <54db5214-75b8-939b-d1f7-9512bd40554a@alvestrand.no> Date: Wed, 14 Sep 2016 20:31:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1F054785-35C3-4C78-BA68-9C1FA8C06633@iii.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 18:31:28 -0000 Den 25. aug. 2016 17:04, skrev Cullen Jennings: > > The JSEP authors have typically tried to have JSEP ref everything that implementers need to know just to make it easier for them to find it. I will add a ref to draft-ietf-mmusic-4572-update to JSEP. Given it is an "update" it technical is a dependency either way. Speaking in terms of standards theory (and not referencing the particular issue): If a conformant implementation of X can be made based on only the information in 4572, it is OK to reference 4572 in the specification for X. Any clarifications in -bis drafts can be considered "advice for the implementor", it doesn't change validity. If a conformant implementation has to do something that is illegal according to 4572, but legal according to 4572-bis, the spec *has* to reference 4572-bis normatively. A reference to 4572 in addition is not needed. Note that this blocks publication until 4572-bis is published. Note that this applies to optional features too; if an optional feature can't be implemented without reading 4572-bis, it's a normative dependency. Back to discussing the subject line.. From nobody Wed Sep 14 11:50:26 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB4412B447 for ; Wed, 14 Sep 2016 11:50:24 -0700 (PDT) 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 tsEnl2gCjgkF for ; Wed, 14 Sep 2016 11:50:22 -0700 (PDT) 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 704B212B43F for ; Wed, 14 Sep 2016 11:50:22 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-d9-57d99be95a58 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 36.C0.06563.9EB99D75; Wed, 14 Sep 2016 20:50:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Wed, 14 Sep 2016 20:50:17 +0200 From: Christer Holmberg To: Harald Alvestrand , Cullen Jennings Thread-Topic: [rtcweb] JSEP: multiple fingerprints for a certificate Thread-Index: AQHR/k1N4obaEB6UGkSI2f8MWO5rr6BZQxsA///eOwCAADWZAIAATs8AgB+ogYCAACUc4A== Date: Wed, 14 Sep 2016 18:50:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BCA17F6@ESESSMB209.ericsson.se> References: <1F054785-35C3-4C78-BA68-9C1FA8C06633@iii.ca> <54db5214-75b8-939b-d1f7-9512bd40554a@alvestrand.no> In-Reply-To: <54db5214-75b8-939b-d1f7-9512bd40554a@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbHdVffN7JvhBg+ui1t8WP+D0eJYXxeb xdp/7ewOzB5XJlxh9Viy5CeTx+XzHxkDmKO4bFJSczLLUov07RK4MvZ9n8da8Juv4m33RfYG xjk8XYycHBICJhJzN3xk7mLk4hASWM8ocWTNPEYIZwmjxK7bzWxdjBwcbAIWEt3/tEEaRAR8 JSZObGYEsZkFFCW+LJ/PBmILCzhLTNn7jQWixkXi5ewDTCCtIgJhEvuehYGYLAKqElfWFYJU 8AJN6Zj9lwli0wMmiUsPHjCD1HAKOErcmyEMUsMoICbx/dQaJohN4hK3nsxngjhZQGLJnvPM ELaoxMvH/1ghbCWJxiVPWCHqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUha ZiFpWcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMG4Obvmtu4Nx9WvHQ4wCHIxKPLwP wm+GC7EmlhVX5h5ilOBgVhLhPTcVKMSbklhZlVqUH19UmpNafIhRmoNFSZz339nr4UIC6Ykl qdmpqQWpRTBZJg5OqQZGj7prHj7/fbc4B1gcmS2VWM61MWPzvSRFFYG8FVdTshymhJtcFSj5 mdXtvu7gF9FK/baLtwuUr7p8zWnfulDjjReblOa3Y4wP3gs/LDO/nr1rJav28wfvkoSlJjPM /pBW/8S+tqK7wG/jrQf7DsY1XGuyYk970HPTsd2wyzCjfI1XsNCvTdxKLMUZiYZazEXFiQB5 4PQLlwIAAA== Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 18:50:25 -0000 Hi, Just a minor correction: there is no 4572-bis. draft-4572-update updates/cl= arifies parts of RFC 4572. 4572-update does not fix anything that is "illegal" in RFC 4572. However, 4= 572-update is also a little more than "advice for the implementer". So, I definitely think we should normatively reference 4572-update in JSEP.= RTCWEB is what triggered 4572-update to begin with... Regards, Christer -----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: 14 September 2016 21:31 To: Cullen Jennings ; Christer Holmberg Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate Den 25. aug. 2016 17:04, skrev Cullen Jennings: >=20 > The JSEP authors have typically tried to have JSEP ref everything that im= plementers need to know just to make it easier for them to find it. I will = add a ref to draft-ietf-mmusic-4572-update to JSEP. Given it is an "update= " it technical is a dependency either way.=20 Speaking in terms of standards theory (and not referencing the particular i= ssue): If a conformant implementation of X can be made based on only the informati= on in 4572, it is OK to reference 4572 in the specification for X. Any clar= ifications in -bis drafts can be considered "advice for the implementor", i= t doesn't change validity. If a conformant implementation has to do something that is illegal accordin= g to 4572, but legal according to 4572-bis, the spec *has* to reference 457= 2-bis normatively. A reference to 4572 in addition is not needed. Note that= this blocks publication until 4572-bis is published. Note that this applies to optional features too; if an optional feature can= 't be implemented without reading 4572-bis, it's a normative dependency. Back to discussing the subject line.. From nobody Thu Sep 15 10:57:43 2016 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 D4FC812B18F; Thu, 15 Sep 2016 10:57:41 -0700 (PDT) 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.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147396226183.26947.7848644496937518303.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2016 10:57:41 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] rtcweb - New Meeting Session Request for IETF 97 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, 15 Sep 2016 17:57:42 -0000 A new meeting session request has just been submitted by Ted Hardie, 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: Ted Hardie Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 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 ianaplan dane opsawg Special Requests: --------------------------------------------------------- From nobody Thu Sep 15 15:18:25 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7512B098 for ; Thu, 15 Sep 2016 15:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 sbMKRXp-XPo5 for ; Thu, 15 Sep 2016 15:18:21 -0700 (PDT) Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (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 12AE312B075 for ; Thu, 15 Sep 2016 15:18:20 -0700 (PDT) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4FFDCC028E; Thu, 15 Sep 2016 18:18:15 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp8.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B6C4BC01B6; Thu, 15 Sep 2016 18:18:14 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.92.108.80] (184-23-135-130.dedicated.static.sonic.net [184.23.135.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Thu, 15 Sep 2016 18:18:15 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_4DCE91DB-1CF8-4A67-8B23-E1393AC8B764" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Thu, 15 Sep 2016 15:18:13 -0700 Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF , Robin Raymond Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 15 Sep 2016 22:18:24 -0000 --Apple-Mail=_4DCE91DB-1CF8-4A67-8B23-E1393AC8B764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To propose a few use case=E2=80=A6. =E2=80=9CWhiskey & Soda Example=E2=80=9D The PT are all the same. Early packets, and any packets after a SSRC = change, contain a MID. If the packet has MID, it goes to the place that = matches that MID *and* it latches that SSRC so any future SSRC that = don=E2=80=99t have a MID go the to the same place.=20 =E2=80=9CCoke Classic Example=E2=80=9D=20 The PT are all unique. The SSRC change. There is no RID, MID, FEC, or = RTX. The packets get delivered to the thing with the matching PT.=20 =E2=80=9CBloddy Mary Example=E2=80=9D=20 The PT are the same. The SSRC do not changed and are signalled in SDP. = There is no MID, RID, etc in the RTP. The packets go to the thing the = SSRC signalling would have indicated.=20 =E2=80=9CDiet Coke Example=E2=80=9D The PT are all unique. The packet has a MID. The MID corresponds to a an = m-line that does not have PT associated with it that match the PT. (the = PT is from a different m-line). The packets gets dropped (or cause event = in ORTC). [ Note I think of this that the MID sends it to the right = m-line aka Receiver, but then that does not have a codec for that PT so = it gets dropped. ] =E2=80=9CDiet Pepsi Example=E2=80=9D The PT are all unique. The packet has a SSRC. The SSRC does not = correspond to any SSRC that were signalled for the m-line that the PT is = on. The packet goes to the thing associated with that PT ignoring any = SSRC.=20 =E2=80=9CRed Bull Example=E2=80=9D The packet has a MID that does not match any MID in the signalling. The = packets gets dropped (or event in ORTC). > On Sep 14, 2016, at 10:49 AM, Bernard Aboba = wrote: >=20 > There is now a JSEP PR relating to RTP demux algorithms:=20 > https://github.com/rtcweb-wg/jsep/pull/320 = >=20 > Rather than commenting in detail on that PR in this post, I would like = to prove some thoughts on how we evaluate proposed RTP demux algorithms.=20= >=20 > The goal of an RTP demux algorithm is to determine whether an incoming = RTP packet received on a DtlsTransport can be forwarded to one of the = RtpReceivers attached to that DtlsTransport. If none of the = RtpReceivers qualify, then the packet is either dropped (WebRTC 1.0) or = generates an RTP unhandled event (ORTC).=20 >=20 > In principle, RTP demux algorithms do not seem complicated, since they = often can be expressed in less than half a dozen steps, typically with = less than a page of text.=20 >=20 > However, in practice the difficulty has turned out to be not in = stating an algorithm, but in evaluating whether it is correct. This = challenges include:=20 >=20 > 1. Agreement on a set of use cases and desired outcomes that a = proposed algorithm must satisfy. Think of this as a set of regression = tests that insure that a proposed algorithm behaves as we expect, as = well as ensuring that changes to that algorithm do not result in = unintended consequences.=20 >=20 > 2. Agreement on all the inputs that the algorithm takes into account. = This includes fields within the RTP packet (e.g. SSRC, PT, RID, MID, = etc.) as well as methods within the API (e.g. setLocalDescription, = setRemoteDescription, setParameters, etc.).=20 >=20 > With respect to Issue #1, some of the trickiest use cases involve both = PT and SSRC signaling, SSRC "latching" and handling FEC and RTX. = Examples include:=20 > a. Change of SSRCs (e.g. due to conflict).=20 > b. Codec switching (e.g. changing PT but same SSRC, or changing = both PT and SSRC). > c. Use of both FEC and RTX (and perhaps RTX of FEC). >=20 > IMHO it would be useful to come up a few (less than half a dozen) use = cases with agreed-upon outcomes. >=20 > With respect to Issue #2, the proposed algorithms so far look at the = SSRC & PT fields in the RTP header as well as the MID RTP extension. = However, I have not seen algorithms which take into account the role of = the RID RTP extension. So agreement on whether the RID needs to be = considered or not would be helpful.=20 >=20 > Also, for WebRTC 1.0 it would appear to me that the algorithm will = depend on the inputs to the setLocalDescription/setRemoteDescription = methods, so that there is a potential dependency on the signaling state = of the PeerConnection. >=20 > Overall, I believe that the discussion of RTP demux algorithms is = likely to go more smoothly (and conclude more quickly) if we get = agreement on these meta-issues upfront.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_4DCE91DB-1CF8-4A67-8B23-E1393AC8B764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

To propose a few use = case=E2=80=A6.

=E2=80=9CWhiskey & Soda Example=E2=80=9D
The PT are all the same. Early packets, and any packets after = a SSRC change, contain a MID. If the packet has  MID, it goes to = the place that matches that MID *and* it latches that SSRC so any future = SSRC that don=E2=80=99t have a MID go the to the same = place. 

=E2=80=9CCoke Classic Example=E2=80=9D 
The PT are all unique. The SSRC change. There is no RID, MID, = FEC, or RTX. The packets get delivered to the thing with the matching = PT. 

=E2=80=9CBlo= ddy Mary Example=E2=80=9D 
The PT are the = same. The SSRC do not changed and are signalled in SDP. There is no MID, = RID, etc in the RTP.  The packets go to the thing the SSRC = signalling would have indicated. 

=E2=80=9CDiet Coke Example=E2=80=9D
=
The PT are all unique. The packet has a MID. The MID = corresponds to a an m-line that does not have PT associated with it that = match the PT. (the PT is from a different m-line). The packets gets = dropped (or cause event in ORTC). [ Note I think of this that the MID = sends it to the right m-line aka Receiver, but then that does not have a = codec for that PT so it gets dropped. ]

=E2=80=9CDiet Pepsi = Example=E2=80=9D
The PT are all unique. The packet = has a SSRC. The SSRC does not correspond to any SSRC that were signalled = for the m-line that the PT is on. The packet goes to the thing = associated with that PT ignoring any SSRC. 

=E2=80=9CRed Bull Example=E2=80=9D
<= div class=3D"">The packet has a MID that does not match any MID in the = signalling. The packets gets dropped (or event in ORTC).






On = Sep 14, 2016, at 10:49 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

There is now a JSEP PR relating to RTP demux = algorithms: 
https://github.com/rtcweb-wg/jsep/pull/320

Rather than commenting in detail on that PR in this post, I = would like to prove some thoughts on how we evaluate proposed RTP demux = algorithms. 

The goal of an RTP demux algorithm is to determine whether an = incoming RTP packet received on a DtlsTransport can be forwarded to one = of the RtpReceivers attached to that DtlsTransport.  If none of the = RtpReceivers qualify, then the packet is either dropped (WebRTC 1.0) or = generates an RTP unhandled event (ORTC). 

In principle, RTP demux algorithms do = not seem complicated, since they often can be expressed in less than = half a dozen steps, typically with less than a page of = text. 

However, in practice the difficulty has turned out to be not = in stating an algorithm, but in evaluating whether it is correct. This = challenges include: 

1. Agreement on a set of use cases and desired outcomes that = a proposed algorithm must satisfy.  Think of this as a set of = regression tests that insure that a proposed algorithm behaves as we = expect, as well as ensuring that changes to that algorithm do not result = in unintended consequences. 

2. Agreement on all the inputs that the = algorithm takes into account.  This includes fields within the RTP = packet (e.g. SSRC, PT, RID, MID, etc.) as well as methods within the API = (e.g. setLocalDescription, setRemoteDescription, setParameters, = etc.). 

With respect to Issue #1, some of the trickiest use cases = involve both PT and SSRC signaling, SSRC "latching" and handling FEC and = RTX.  Examples include: 
    a. = Change of SSRCs (e.g. due to conflict). 
  =   b. Codec switching (e.g. changing PT but same SSRC, or changing = both PT and SSRC).
    c. Use of both FEC = and RTX (and perhaps RTX of FEC).

IMHO it would be useful to come up a = few (less than half a dozen) use cases with agreed-upon = outcomes.

With = respect to Issue #2, the proposed algorithms so far look at the SSRC = & PT fields in the RTP header as well as the MID RTP = extension.  However, I have not seen algorithms which take into = account the role of the RID RTP extension.  So agreement on whether = the RID needs to be considered or not would be helpful. 

Also, for WebRTC 1.0 it = would appear to me that the algorithm will depend on the inputs to the = setLocalDescription/setRemoteDescription methods, so that there is a = potential dependency on the signaling state of the = PeerConnection.

Overall, I believe that the discussion of RTP demux = algorithms is likely to go more smoothly (and conclude more quickly) if = we get agreement on these meta-issues upfront. 












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

= --Apple-Mail=_4DCE91DB-1CF8-4A67-8B23-E1393AC8B764-- From nobody Thu Sep 15 17:52:29 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EAB12B0F5 for ; Thu, 15 Sep 2016 17:52:28 -0700 (PDT) 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 ZETztRefKpV8 for ; Thu, 15 Sep 2016 17:52:25 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 C8E0112B0D2 for ; Thu, 15 Sep 2016 17:52:24 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id 192so5039023vkl.0 for ; Thu, 15 Sep 2016 17:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6y6SGV49mEKMaQZMRRkVVFpaFV4lONpB+C+8J1672MI=; b=RcVIpILlAuE5obtSukmQ11+7D/2Hi4IKII5lJJ3/+xKgaJJOcDMzx33eEBwegARRHr fm2vmWzn+KEoYfjQCr4y3sE2eRyBCX5tb0Ila5G/evrVRWePDoZ2TRqmO0EE9plz/8uR SLWisPsksPpISIRAXLS3iaMaPNpyQM5vWybNHT145XNz5ZmfOAFIhar/9GWeTBGBkWEI 2XxicBTf+JNI51bSlTdNFpAC3LKKk4/d68/EuSdKqm50MMFX5gPQxeaIjl8/Fq2m0y7T IHsOTR8GAZRa9M6gK7lRF4IJMHbzxOMAPiTiRmy0ui0PjRSUhDKh2vDwMeCQEwW/5psI gFBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6y6SGV49mEKMaQZMRRkVVFpaFV4lONpB+C+8J1672MI=; b=Oh8qI7bKR1IXZvh8x8ORSGg8B9Ds0Mwhkh6k34P91hX0LzPkGhpOx3cun6PoOvM8A/ YxGexVpMeEA9d4SK7Xr+MbjqHPh+xuAxK7XPznvlA6DYF7tCAqsswftOhP5EYI1USPU7 k8fROf/Zr+mbTywE23QLjGtG9K4iuvVamtN4iRd2WYQvikyTXkGwYOLhsfSxVZ0YkI4x 6Up6vv1bieIXhhbxpWEDsY5hHXT2oODnGo3EughTsRnO+1PkQzhY+qj74yqC3xBpSaN6 E19E9xFDidjOKqx8KxA1TLZwb4Sm1b3LikFHyx8NTzgo4VUQi0lwrg5WruqfIX/gz3N/ zMjw== X-Gm-Message-State: AE9vXwO7833dEUccpp1lY6HpV8TMuxqLVjoB3xQwrK7eQ3DFrCT0Uv+Dz3tr3leE2mEqm1GxhampHKKUtsQFfQ== X-Received: by 10.31.171.147 with SMTP id u141mr891869vke.57.1473987143825; Thu, 15 Sep 2016 17:52:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.105 with HTTP; Thu, 15 Sep 2016 17:52:03 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 15 Sep 2016 17:52:03 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a114408bc1c7ef8053c9560ef Archived-At: Cc: RTCWeb IETF , Robin Raymond Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 00:52:28 -0000 --001a114408bc1c7ef8053c9560ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Cullen. Those all look like good test cases. Here are a few more: Codec change, case 1: The PTs are all unique, and no SSRCs were signaled in SDP There is no RID, MID, FEC, or RTX. Sender switches codecs, and the PT changes (but SSRC stays the same). The packet goes to the receiver that matches the new PT. Codec change, case 2: The PTs are all unique and SSRCs are signaled in SDP. There is no RID, MID, FEC or RTX. Sender switches codecs and the PT changes (but SSRC stays the same). SSRC does not match any signaled ones. The packet goes to the receiver that matches the new PT. These use cases relate to the following Issue (filed by Inaki): https://github.com/w3c/ortc/issues/547 There are also some trickier use cases that derive from draft-ietf-mmusic-bundle-negotiation Section 10.2 (which discusses PT overlap): PT overlap: The PTs are not unique. Some SSRCs are signaled in SDP. There is no RID, MID, FEC or RTX. Packet arrives with SSRC that does not match any signaled in the SDP, but matches PTs specified in multiple m-lines. Is the packet delivered or dropped, and if delivered, to which receiver? Some potential answers: a. Behavior is not defined. If reliable behavior is desired, signal the SSRC or use MID (support for which is mandated by BUNDLE). b. Deliver the packet to an m-line that signals the PT but that: 1. Doesn't provide SSRCs for each encoding (e.g. encodings[i].ssrc is not set for all i) OR 2. Doesn't provide SSRC for each RTX entry (e.g. encodings[i].rtx.ssrc is not set for all i) OR 3. Doesn't provide SSRCs for each FEC entry (e.g. encodings[i].fec.ssrc is not set for all i) See the following Issue: https://github.com/w3c/ortc/issues/546 draft-ietf-mmusic-bundle-negotiation Section 10.2: 10.2 . Associating RTP/RTCP Packets With Correct SDP Media Description There are multiple mechanisms that can be used by an endpoint in order to associate received RTP/RTCP packets with a bundled "m=3D" line. Such mechanisms include using the payload type value carried inside the RTP packets, the SSRC values carried inside the RTP packets, and other "m=3D" line specific information carried inside the RTP packets. As all RTP/RTCP packets associated with a BUNDLE group are received (and sent) using single address:port combinations, the local address:port combination cannot be used to associate received RTP packets with the correct "m=3D" line. As described in [Section 10.1.1 ], the same payload type value might be used inside RTP packets described by multiple "m=3D" lines. In such cases, the payload type value cannot be used to associate received RTP packets with the correct "m=3D" line. An offerer and answerer can inform each other which SSRC values they will use for RTP and RTCP by using the SDP 'ssrc' attribute [RFC5576 ]. To allow for proper association with this mechanism, the 'ssrc' attribute needs to be associated with each "m=3D" line that shares a payload type with any other "m=3D" line in the same bundle. As the SSRC values will be carried inside the RTP/RTCP packets, the offerer and answerer can then use that information to associate received RTP packets with the correct "m=3D" line. However, an offerer will not know which SSRC values the answerer will use until it 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 received RTP/RTCP packets with the correct "m=3D" line using the SSRC values. In order for an offerer and answerer to always be able to associate received RTP and RTCP packets with the correct "m=3D" line, an offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 14 , where the remote endpoint inserts the identification-tag associated with an "m=3D" line in RTP and RTCP packets associated with that "m=3D" line. On Thu, Sep 15, 2016 at 3:18 PM, Cullen Jennings wrote: > > To propose a few use case=E2=80=A6. > > =E2=80=9CWhiskey & Soda Example=E2=80=9D > The PT are all the same. Early packets, and any packets after a SSRC > change, contain a MID. If the packet has MID, it goes to the place that > matches that MID *and* it latches that SSRC so any future SSRC that don= =E2=80=99t > have a MID go the to the same place. > > =E2=80=9CCoke Classic Example=E2=80=9D > The PT are all unique. The SSRC change. There is no RID, MID, FEC, or RTX= . > The packets get delivered to the thing with the matching PT. > > =E2=80=9CBloddy Mary Example=E2=80=9D > The PT are the same. The SSRC do not changed and are signalled in SDP. > There is no MID, RID, etc in the RTP. The packets go to the thing the SS= RC > signalling would have indicated. > > =E2=80=9CDiet Coke Example=E2=80=9D > The PT are all unique. The packet has a MID. The MID corresponds to a an > m-line that does not have PT associated with it that match the PT. (the P= T > is from a different m-line). The packets gets dropped (or cause event in > ORTC). [ Note I think of this that the MID sends it to the right m-line a= ka > Receiver, but then that does not have a codec for that PT so it gets > dropped. ] > > =E2=80=9CDiet Pepsi Example=E2=80=9D > The PT are all unique. The packet has a SSRC. The SSRC does not correspon= d > to any SSRC that were signalled for the m-line that the PT is on. The > packet goes to the thing associated with that PT ignoring any SSRC. > > =E2=80=9CRed Bull Example=E2=80=9D > The packet has a MID that does not match any MID in the signalling. The > packets gets dropped (or event in ORTC). > > > > > > > On Sep 14, 2016, at 10:49 AM, Bernard Aboba > wrote: > > There is now a JSEP PR relating to RTP demux algorithms: > https://github.com/rtcweb-wg/jsep/pull/320 > > Rather than commenting in detail on that PR in this post, I would like to > prove some thoughts on how we evaluate proposed RTP demux algorithms. > > The goal of an RTP demux algorithm is to determine whether an incoming RT= P > packet received on a DtlsTransport can be forwarded to one of the > RtpReceivers attached to that DtlsTransport. If none of the RtpReceivers > qualify, then the packet is either dropped (WebRTC 1.0) or generates an R= TP > unhandled event (ORTC). > > In principle, RTP demux algorithms do not seem complicated, since they > often can be expressed in less than half a dozen steps, typically with le= ss > than a page of text. > > However, in practice the difficulty has turned out to be not in stating a= n > algorithm, but in evaluating whether it is correct. This challenges > include: > > 1. Agreement on a set of use cases and desired outcomes that a proposed > algorithm must satisfy. Think of this as a set of regression tests that > insure that a proposed algorithm behaves as we expect, as well as ensurin= g > that changes to that algorithm do not result in unintended consequences. > > 2. Agreement on all the inputs that the algorithm takes into account. > This includes fields within the RTP packet (e.g. SSRC, PT, RID, MID, etc.= ) > as well as methods within the API (e.g. setLocalDescription, > setRemoteDescription, setParameters, etc.). > > With respect to Issue #1, some of the trickiest use cases involve both PT > and SSRC signaling, SSRC "latching" and handling FEC and RTX. Examples > include: > a. Change of SSRCs (e.g. due to conflict). > b. Codec switching (e.g. changing PT but same SSRC, or changing both > PT and SSRC). > c. Use of both FEC and RTX (and perhaps RTX of FEC). > > IMHO it would be useful to come up a few (less than half a dozen) use > cases with agreed-upon outcomes. > > With respect to Issue #2, the proposed algorithms so far look at the SSRC > & PT fields in the RTP header as well as the MID RTP extension. However,= I > have not seen algorithms which take into account the role of the RID RTP > extension. So agreement on whether the RID needs to be considered or not > would be helpful. > > Also, for WebRTC 1.0 it would appear to me that the algorithm will depend > on the inputs to the setLocalDescription/setRemoteDescription methods, so > that there is a potential dependency on the signaling state of the > PeerConnection. > > Overall, I believe that the discussion of RTP demux algorithms is likely > to go more smoothly (and conclude more quickly) if we get agreement on > these meta-issues upfront. > > > > > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --001a114408bc1c7ef8053c9560ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Cullen.=C2=A0 Those all look like good test cases.=

Here are a few more:=C2=A0

Codec change, case 1: The PTs are all unique, and no SSRCs were signaled i= n SDP =C2=A0There is no RID, MID, FEC, or = RTX. Sender switches codecs, and the PT changes (but SSRC stays the = same).=C2=A0 The packet goes to the receiver that matches the new PT.=C2=A0=

Codec change, case 2: =C2=A0The PTs are all uniqu= e and SSRCs are signaled in SDP.=C2=A0 There is no RID, MID, FEC or RTX. Se= nder switches codecs and the PT changes (but SSRC stays the same).=C2=A0 SS= RC does not match any signaled ones.=C2=A0 The packet goes to the receiver = that matches the new PT.=C2=A0

These use cases rel= ate to the following Issue (filed by Inaki):=C2=A0https://github.com/w3c/ortc/issues/547
<= div>
There are also some trickier use cases that derive from = draft-ietf-mmusic-bundle-negotiation Section 10.2 (which discusses PT overl= ap): =C2=A0

PT overlap: =C2= =A0The PTs are not unique.=C2=A0 Some SSRCs are signaled in SDP.=C2=A0 Ther= e is no RID, MID, FEC or RTX. Packet arrives with SSRC that does not match = any signaled in the SDP, but matches PTs specified in multiple m-lines.=C2= =A0 Is the packet delivered or dropped, and if delivered, to which receiver= ?=C2=A0 Some potential answers:=C2=A0

a. Behav= ior is not defined.=C2=A0 If reliable behavior is desired, signal the SSRC = or use MID (support for which is mandated by BUNDLE).=C2=A0

<= /div>
b. Deliver the packet to an m-line that signals the PT but that:= =C2=A0
=C2=A0 =C2=A01. Doesn't provide SSRCs for each encodin= g (e.g. encodings[i].ssrc is not set for all i) OR
=C2=A0 =C2=A02= . Doesn't provide SSRC for each RTX entry (e.g. encodings[i].rtx.ssrc i= s not set for all i) OR
=C2=A0 =C2=A03. Doesn't provide SSRCs= for each FEC entry (e.g. encodings[i].fec.ssrc is not set for all i)
=

See the following Issue:=C2=A0https://github.com/w3c/ortc/issues/546
<= div>

draft-ietf-mmusic-bundle-negotiation Sect= ion 10.2:=C2=A0

10.2.  Associating RTP/R=
TCP Packets With Correct SDP Media Description


   There are multiple mechanisms that can be used by an endpoint in
   order to associate received RTP/RTCP packets with a bundled "m=3D&q=
uot;
   line.  Such mechanisms include using the payload type value carried
   inside the RTP packets, the SSRC values carried inside the RTP
   packets, and other "m=3D" line specific information carried in=
side the
   RTP packets.

   As all RTP/RTCP packets associated with a BUNDLE group are received
   (and sent) using single address:port combinations, the local
   address:port combination cannot be used to associate received RTP
   packets with the correct "m=3D" line.

   As described in [Section 10.1.1], the same p=
ayload type value might
   be used inside RTP packets described by multiple "m=3D" lines.=
  In such
   cases, the payload type value cannot be used to associate received
   RTP packets with the correct "m=3D" line.

   An offerer and answerer can inform each other which SSRC values they
   will use for RTP and RTCP by using the SDP 'ssrc' attribute
   [R=
FC5576].  To allow for proper association with this mechanism, the
   'ssrc' attribute needs to be associated with each "m=3D&quo=
t; line that
   shares a payload type with any other "m=3D" line in the same b=
undle.
   As the SSRC values will be carried inside the RTP/RTCP packets, the
   offerer and answerer can then use that information to associate
   received RTP packets with the correct "m=3D" line.  However, a=
n offerer
   will not know which SSRC values the answerer will use until it 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 received RTP/RTCP packets with the correct "m=3D" li=
ne using
   the SSRC values.

   In order for an offerer and answerer to always be able to associate
   received RTP and RTCP packets with the correct "m=3D" line, an=
 offerer
   and answerer using the BUNDLE extension MUST support the mechanism
   defined in Section 14, where the remote endpoint=
 inserts the
   identification-tag associated with an "m=3D" line in RTP and R=
TCP
   packets associated with that "m=3D" line.





On Thu, Sep 15= , 2016 at 3:18 PM, Cullen Jennings <fluffy@iii.ca> wrote:

To propose a few use case=E2=80=A6.

=E2=80=9CWhiskey= & Soda Example=E2=80=9D
The PT are all the same. Early packe= ts, and any packets after a SSRC change, contain a MID. If the packet has = =C2=A0MID, it goes to the place that matches that MID *and* it latches that= SSRC so any future SSRC that don=E2=80=99t have a MID go the to the same p= lace.=C2=A0

=E2=80=9CCoke Classic Example=E2=80=9D= =C2=A0
The PT are all unique. The SSRC change. There is no RID, M= ID, FEC, or RTX. The packets get delivered to the thing with the matching P= T.=C2=A0

=E2=80=9CBloddy Mary Example=E2=80=9D=C2=A0
The PT are the same. The SSRC do not changed and are signalled in SD= P. There is no MID, RID, etc in the RTP.=C2=A0 The packets go to the thing = the SSRC signalling would have indicated.=C2=A0

= =E2=80=9CDiet Coke Example=E2=80=9D
The PT are all unique. The pa= cket has a MID. The MID corresponds to a an m-line that does not have PT as= sociated with it that match the PT. (the PT is from a different m-line). Th= e packets gets dropped (or cause event in ORTC). [ Note I think of this tha= t the MID sends it to the right m-line aka Receiver, but then that does not= have a codec for that PT so it gets dropped. ]

= =E2=80=9CDiet Pepsi Example=E2=80=9D
The PT are all unique. The p= acket has a SSRC. The SSRC does not correspond to any SSRC that were signal= led for the m-line that the PT is on. The packet goes to the thing associat= ed with that PT ignoring any SSRC.=C2=A0

=E2=80=9C= Red Bull Example=E2=80=9D
The packet has a MID that does not matc= h any MID in the signalling. The packets gets dropped (or event in ORTC).






On = Sep 14, 2016, at 10:49 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
=
There is now a= JSEP PR relating to RTP demux algorithms:=C2=A0

Rather than commen= ting in detail on that PR in this post, I would like to prove some thoughts= on how we evaluate proposed RTP demux algorithms.=C2=A0

The goal of an RTP demux algorithm is to determine whether an incomi= ng RTP packet received on a DtlsTransport can be forwarded to one of the Rt= pReceivers attached to that DtlsTransport.=C2=A0 If none of the RtpReceiver= s qualify, then the packet is either dropped (WebRTC 1.0) or generates an R= TP unhandled event (ORTC).=C2=A0

In principle, RTP= demux algorithms do not seem complicated, since they often can be expresse= d in less than half a dozen steps, typically with less than a page of text.= =C2=A0

However, in practice the difficulty has tur= ned out to be not in stating an algorithm, but in evaluating whether it is = correct. This challenges include:=C2=A0

1. Agreeme= nt on a set of use cases and desired outcomes that a proposed algorithm mus= t satisfy.=C2=A0 Think of this as a set of regression tests that insure tha= t a proposed algorithm behaves as we expect, as well as ensuring that chang= es to that algorithm do not result in unintended consequences.=C2=A0
<= div>
2. Agreement on all the inputs that the algorithm takes = into account.=C2=A0 This includes fields within the RTP packet (e.g. SSRC, = PT, RID, MID, etc.) as well as methods within the API (e.g. setLocalDescrip= tion, setRemoteDescription, setParameters, etc.).=C2=A0

With respect to Issue #1, some of the trickiest use cases involve bot= h PT and SSRC signaling, SSRC "latching" and handling FEC and RTX= .=C2=A0 Examples include:=C2=A0
=C2=A0 =C2=A0 a. Change of SSRCs = (e.g. due to conflict).=C2=A0
=C2=A0 =C2=A0 b. Codec switching (e= .g. changing PT but same SSRC, or changing both PT and SSRC).
=C2= =A0 =C2=A0 c. Use of both FEC and RTX (and perhaps RTX of FEC).
<= br>
IMHO it would be useful to come up a few (less than half a do= zen) use cases with agreed-upon outcomes.

With res= pect to Issue #2, the proposed algorithms so far look at the SSRC & PT = fields in the RTP header as well as the MID RTP extension.=C2=A0 However, I= have not seen algorithms which take into account the role of the RID RTP e= xtension.=C2=A0 So agreement on whether the RID needs to be considered or n= ot would be helpful.=C2=A0

Also, for WebRTC 1.0 it= would appear to me that the algorithm will depend on the inputs to the set= LocalDescription/setRemoteDescription methods, so that there is a pote= ntial dependency on the signaling state of the PeerConnection.
Overall, I believe that the discussion of RTP demux algorithms= is likely to go more smoothly (and conclude more quickly) if we get agreem= ent on these meta-issues upfront.=C2=A0


=





=





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


--001a114408bc1c7ef8053c9560ef-- From nobody Fri Sep 16 08:53:47 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA14F12B172 for ; Fri, 16 Sep 2016 08:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 pTxRjyTz12-o for ; Fri, 16 Sep 2016 08:53:42 -0700 (PDT) Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (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 9168D12B296 for ; Fri, 16 Sep 2016 08:53:42 -0700 (PDT) Received: from smtp7.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 99DFB4045C; Fri, 16 Sep 2016 11:53:39 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 144404047E; Fri, 16 Sep 2016 11:53:38 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.17.99] ([UNAVAILABLE]. [128.107.241.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Fri, 16 Sep 2016 11:53:39 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D9D5EB4A-3686-4E54-B026-DA06C023FDA2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 16 Sep 2016 08:53:36 -0700 Message-Id: References: To: Bernard Aboba , RTCWeb IETF X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Robin Raymond Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 15:53:45 -0000 --Apple-Mail=_D9D5EB4A-3686-4E54-B026-DA06C023FDA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And to add some RID based one =E2=80=A6=20 =E2=80=9CDouble Expresso=E2=80=9D The PT are all the same. There are MIDs. There are RIDs. When a packet = with a MID and RID drives, the MID is used to find the correct m-line, = then if and only if there is a RID in that m-line that matches, the = packet is delivered to the place associated with that a=3Drid line. Any = future packet with the same SSRC but no RID or MID would go the same = place.=20 =E2=80=9CCapuchino=E2=80=9D All the PT are unique. There is no MID or RID in the RTP packet but the = SDP has unique PT in every RID line in every =E2=80=9Ca=3Drid=E2=80=9D = line. The packet is sent to the stuff associated with that a=3Drid line.=20= =E2=80=9CDecaf Carmel Non-Fat Latte=E2=80=9D Packets is discard (or even in ORTC) for any of the following cases: (Decaf) There is a MID but the PT does match a PT for that m-line. = (Carmel) There is a MID and RID but the RID does not exist in that = m-line. (Non-fat) There is RID and PT but the PT does not match the set = of PT allowed for that RID.=20 > On Sep 15, 2016, at 3:18 PM, Cullen Jennings wrote: >=20 >=20 > To propose a few use case=E2=80=A6. >=20 > =E2=80=9CWhiskey & Soda Example=E2=80=9D > The PT are all the same. Early packets, and any packets after a SSRC = change, contain a MID. If the packet has MID, it goes to the place that = matches that MID *and* it latches that SSRC so any future SSRC that = don=E2=80=99t have a MID go the to the same place.=20 >=20 > =E2=80=9CCoke Classic Example=E2=80=9D=20 > The PT are all unique. The SSRC change. There is no RID, MID, FEC, or = RTX. The packets get delivered to the thing with the matching PT.=20 >=20 > =E2=80=9CBloddy Mary Example=E2=80=9D=20 > The PT are the same. The SSRC do not changed and are signalled in SDP. = There is no MID, RID, etc in the RTP. The packets go to the thing the = SSRC signalling would have indicated.=20 >=20 > =E2=80=9CDiet Coke Example=E2=80=9D > The PT are all unique. The packet has a MID. The MID corresponds to a = an m-line that does not have PT associated with it that match the PT. = (the PT is from a different m-line). The packets gets dropped (or cause = event in ORTC). [ Note I think of this that the MID sends it to the = right m-line aka Receiver, but then that does not have a codec for that = PT so it gets dropped. ] >=20 > =E2=80=9CDiet Pepsi Example=E2=80=9D > The PT are all unique. The packet has a SSRC. The SSRC does not = correspond to any SSRC that were signalled for the m-line that the PT is = on. The packet goes to the thing associated with that PT ignoring any = SSRC.=20 >=20 > =E2=80=9CRed Bull Example=E2=80=9D > The packet has a MID that does not match any MID in the signalling. = The packets gets dropped (or event in ORTC). >=20 >=20 >=20 >=20 >=20 >=20 >> On Sep 14, 2016, at 10:49 AM, Bernard Aboba > wrote: >>=20 >> There is now a JSEP PR relating to RTP demux algorithms:=20 >> https://github.com/rtcweb-wg/jsep/pull/320 = >>=20 >> Rather than commenting in detail on that PR in this post, I would = like to prove some thoughts on how we evaluate proposed RTP demux = algorithms.=20 >>=20 >> The goal of an RTP demux algorithm is to determine whether an = incoming RTP packet received on a DtlsTransport can be forwarded to one = of the RtpReceivers attached to that DtlsTransport. If none of the = RtpReceivers qualify, then the packet is either dropped (WebRTC 1.0) or = generates an RTP unhandled event (ORTC).=20 >>=20 >> In principle, RTP demux algorithms do not seem complicated, since = they often can be expressed in less than half a dozen steps, typically = with less than a page of text.=20 >>=20 >> However, in practice the difficulty has turned out to be not in = stating an algorithm, but in evaluating whether it is correct. This = challenges include:=20 >>=20 >> 1. Agreement on a set of use cases and desired outcomes that a = proposed algorithm must satisfy. Think of this as a set of regression = tests that insure that a proposed algorithm behaves as we expect, as = well as ensuring that changes to that algorithm do not result in = unintended consequences.=20 >>=20 >> 2. Agreement on all the inputs that the algorithm takes into account. = This includes fields within the RTP packet (e.g. SSRC, PT, RID, MID, = etc.) as well as methods within the API (e.g. setLocalDescription, = setRemoteDescription, setParameters, etc.).=20 >>=20 >> With respect to Issue #1, some of the trickiest use cases involve = both PT and SSRC signaling, SSRC "latching" and handling FEC and RTX. = Examples include:=20 >> a. Change of SSRCs (e.g. due to conflict).=20 >> b. Codec switching (e.g. changing PT but same SSRC, or changing = both PT and SSRC). >> c. Use of both FEC and RTX (and perhaps RTX of FEC). >>=20 >> IMHO it would be useful to come up a few (less than half a dozen) use = cases with agreed-upon outcomes. >>=20 >> With respect to Issue #2, the proposed algorithms so far look at the = SSRC & PT fields in the RTP header as well as the MID RTP extension. = However, I have not seen algorithms which take into account the role of = the RID RTP extension. So agreement on whether the RID needs to be = considered or not would be helpful.=20 >>=20 >> Also, for WebRTC 1.0 it would appear to me that the algorithm will = depend on the inputs to the setLocalDescription/setRemoteDescription = methods, so that there is a potential dependency on the signaling state = of the PeerConnection. >>=20 >> Overall, I believe that the discussion of RTP demux algorithms is = likely to go more smoothly (and conclude more quickly) if we get = agreement on these meta-issues upfront.=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail=_D9D5EB4A-3686-4E54-B026-DA06C023FDA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And to add some RID based one =E2=80=A6 

=E2=80=9CDouble = Expresso=E2=80=9D
The PT are all the same. There = are MIDs. There are RIDs. When a packet with a MID and RID drives, the = MID is used to find the correct m-line, then if and only if there is a = RID in that m-line that matches, the packet is delivered to the place = associated with that a=3Drid line. Any future packet with the same SSRC = but no RID or MID would go the same place. 

=E2=80=9CCapuchino=E2=80=9D
All the PT are unique. There is no MID or RID in the RTP = packet but the SDP has unique PT in every RID line in every =E2=80=9Ca=3Dr= id=E2=80=9D line. The packet is sent to the stuff associated with that = a=3Drid line. 

=E2=80=9CDecaf Carmel Non-Fat Latte=E2=80=9D
Packets is discard (or even in ORTC) for any of the following = cases:
(Decaf) There is a MID but the PT does match = a PT for that m-line. (Carmel) There is a MID and RID but the RID does = not exist in that m-line. (Non-fat) There is RID and PT but the PT does = not match the set of PT allowed for that RID. 


On = Sep 15, 2016, at 3:18 PM, Cullen Jennings <fluffy@iii.ca> = wrote:


To propose a few use case=E2=80=A6.

=E2=80=9CWhiskey & = Soda Example=E2=80=9D
The PT are all the same. = Early packets, and any packets after a SSRC change, contain a MID. If = the packet has  MID, it goes to the place that matches that MID = *and* it latches that SSRC so any future SSRC that don=E2=80=99t have a = MID go the to the same place. 

=E2=80=9CCoke Classic = Example=E2=80=9D 
The PT are all unique. The = SSRC change. There is no RID, MID, FEC, or RTX. The packets get = delivered to the thing with the matching PT. 

=E2=80=9CBloddy Mary = Example=E2=80=9D 
The PT are the same. The = SSRC do not changed and are signalled in SDP. There is no MID, RID, etc = in the RTP.  The packets go to the thing the SSRC signalling would = have indicated. 

=E2=80=9CDiet Coke Example=E2=80=9D
The = PT are all unique. The packet has a MID. The MID corresponds to a an = m-line that does not have PT associated with it that match the PT. (the = PT is from a different m-line). The packets gets dropped (or cause event = in ORTC). [ Note I think of this that the MID sends it to the right = m-line aka Receiver, but then that does not have a codec for that PT so = it gets dropped. ]

=E2=80=9CDiet Pepsi Example=E2=80=9D
The = PT are all unique. The packet has a SSRC. The SSRC does not correspond = to any SSRC that were signalled for the m-line that the PT is on. The = packet goes to the thing associated with that PT ignoring any = SSRC. 

=E2=80=9CRed Bull Example=E2=80=9D
The = packet has a MID that does not match any MID in the signalling. The = packets gets dropped (or event in ORTC).






On Sep = 14, 2016, at 10:49 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

There is now a JSEP PR relating to RTP demux = algorithms: 
https://github.com/rtcweb-wg/jsep/pull/320

Rather than commenting in detail on that PR in this post, I = would like to prove some thoughts on how we evaluate proposed RTP demux = algorithms. 

The goal of an RTP demux algorithm is to determine whether an = incoming RTP packet received on a DtlsTransport can be forwarded to one = of the RtpReceivers attached to that DtlsTransport.  If none of the = RtpReceivers qualify, then the packet is either dropped (WebRTC 1.0) or = generates an RTP unhandled event (ORTC). 

In principle, RTP demux algorithms do = not seem complicated, since they often can be expressed in less than = half a dozen steps, typically with less than a page of = text. 

However, in practice the difficulty has turned out to be not = in stating an algorithm, but in evaluating whether it is correct. This = challenges include: 

1. Agreement on a set of use cases and desired outcomes that = a proposed algorithm must satisfy.  Think of this as a set of = regression tests that insure that a proposed algorithm behaves as we = expect, as well as ensuring that changes to that algorithm do not result = in unintended consequences. 

2. Agreement on all the inputs that the = algorithm takes into account.  This includes fields within the RTP = packet (e.g. SSRC, PT, RID, MID, etc.) as well as methods within the API = (e.g. setLocalDescription, setRemoteDescription, setParameters, = etc.). 

With respect to Issue #1, some of the trickiest use cases = involve both PT and SSRC signaling, SSRC "latching" and handling FEC and = RTX.  Examples include: 
    a. = Change of SSRCs (e.g. due to conflict). 
  =   b. Codec switching (e.g. changing PT but same SSRC, or changing = both PT and SSRC).
    c. Use of both FEC = and RTX (and perhaps RTX of FEC).

IMHO it would be useful to come up a = few (less than half a dozen) use cases with agreed-upon = outcomes.

With = respect to Issue #2, the proposed algorithms so far look at the SSRC = & PT fields in the RTP header as well as the MID RTP = extension.  However, I have not seen algorithms which take into = account the role of the RID RTP extension.  So agreement on whether = the RID needs to be considered or not would be helpful. 

Also, for WebRTC 1.0 it = would appear to me that the algorithm will depend on the inputs to the = setLocalDescription/setRemoteDescription methods, so that there is a = potential dependency on the signaling state of the = PeerConnection.

Overall, I believe that the discussion of RTP demux = algorithms is likely to go more smoothly (and conclude more quickly) if = we get agreement on these meta-issues upfront. 












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


= --Apple-Mail=_D9D5EB4A-3686-4E54-B026-DA06C023FDA2-- From nobody Fri Sep 16 09:49:39 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFB212B2BB for ; Fri, 16 Sep 2016 09:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 P65ybRtwaPS4 for ; Fri, 16 Sep 2016 09:49:36 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) (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 6948A12B02C for ; Fri, 16 Sep 2016 09:49:36 -0700 (PDT) Received: from smtp23.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id C608BE00E2; Fri, 16 Sep 2016 12:49:35 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6A7F5E0112; Fri, 16 Sep 2016 12:49:35 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.17.99] ([UNAVAILABLE]. [128.107.241.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Fri, 16 Sep 2016 12:49:35 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_7BDC03E4-E861-449C-8472-62F4BEFF5E16" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 16 Sep 2016 09:49:34 -0700 Message-Id: <37535980-4C92-4ADA-BC19-294D3B072600@iii.ca> References: To: Bernard Aboba X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF , Robin Raymond Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 16:49:38 -0000 --Apple-Mail=_7BDC03E4-E861-449C-8472-62F4BEFF5E16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 15, 2016, at 5:52 PM, Bernard Aboba = wrote: >=20 > Thanks, Cullen. Those all look like good test cases. >=20 > Here are a few more:=20 >=20 > Codec change, case 1: The PTs are all unique, and no SSRCs were = signaled in SDP There is no RID, MID, FEC, or RTX. Sender switches = codecs, and the PT changes (but SSRC stays the same). The packet goes = to the receiver that matches the new PT.=20 agree >=20 > Codec change, case 2: The PTs are all unique and SSRCs are signaled = in SDP. There is no RID, MID, FEC or RTX. Sender switches codecs and = the PT changes (but SSRC stays the same). SSRC does not match any = signaled ones. The packet goes to the receiver that matches the new PT.=20= agree >=20 > These use cases relate to the following Issue (filed by Inaki): = https://github.com/w3c/ortc/issues/547 = >=20 > There are also some trickier use cases that derive from = draft-ietf-mmusic-bundle-negotiation Section 10.2 (which discusses PT = overlap): =20 >=20 > PT overlap: The PTs are not unique. Some SSRCs are signaled in SDP. = There is no RID, MID, FEC or RTX. Packet arrives with SSRC that does not = match any signaled in the SDP, but matches PTs specified in multiple = m-lines. Is the packet delivered or dropped, and if delivered, to which = receiver? Some potential answers:=20 >=20 > a. Behavior is not defined. If reliable behavior is desired, signal = the SSRC or use MID (support for which is mandated by BUNDLE).=20 I could live with this but prefer (a) but I think this is basically an = error and would prefer that the general strategy be it is is ambiguous = where to send a packet, then the packet is dropped (or event in ORTC).=20= >=20 > b. Deliver the packet to an m-line that signals the PT but that:=20 > 1. Doesn't provide SSRCs for each encoding (e.g. encodings[i].ssrc = is not set for all i) OR > 2. Doesn't provide SSRC for each RTX entry (e.g. = encodings[i].rtx.ssrc is not set for all i) OR > 3. Doesn't provide SSRCs for each FEC entry (e.g. = encodings[i].fec.ssrc is not set for all i) >=20 --Apple-Mail=_7BDC03E4-E861-449C-8472-62F4BEFF5E16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sep 15, 2016, at 5:52 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Thanks, Cullen.  Those all look like good test = cases.

Here are a = few more: 

Codec change, case 1: The PTs are all = unique, and no SSRCs were signaled in SDP  There is no RID, MID, FEC, or RTX. = Sender switches codecs, and the PT changes (but SSRC stays the = same).  The packet goes to the receiver that matches the new = PT. 
agree


Codec change, case 2:  The PTs are all unique and SSRCs = are signaled in SDP.  There is no RID, MID, FEC or RTX. Sender = switches codecs and the PT changes (but SSRC stays the same).  SSRC = does not match any signaled ones.  The packet goes to the receiver = that matches the new = PT. 
agree


These use cases relate to the following Issue (filed by = Inaki): https://github.com/w3c/ortc/issues/547

There are also some = trickier use cases that derive from draft-ietf-mmusic-bundle-negotiation = Section 10.2 (which discusses PT overlap):  

PT overlap: =  The PTs are not unique.  Some SSRCs are signaled in = SDP.  There is no RID, MID, FEC or RTX. Packet arrives with SSRC = that does not match any signaled in the SDP, but matches PTs specified = in multiple m-lines.  Is the packet delivered or dropped, and if = delivered, to which receiver?  Some potential answers: 

a. = Behavior is not defined.  If reliable behavior is desired, signal = the SSRC or use MID (support for which is mandated by = BUNDLE). 

I could live with this but prefer (a) but I think = this is basically an error and would prefer that the general strategy be = it is is ambiguous where to send a packet, then the packet is dropped = (or event in ORTC). 

b. Deliver the packet to an m-line = that signals the PT but that: 
   1. = Doesn't provide SSRCs for each encoding (e.g. encodings[i].ssrc is not = set for all i) OR
   2. Doesn't provide = SSRC for each RTX entry (e.g. encodings[i].rtx.ssrc is not set for all = i) OR
   3. Doesn't provide SSRCs for = each FEC entry (e.g. encodings[i].fec.ssrc is not set for all = i)


= --Apple-Mail=_7BDC03E4-E861-449C-8472-62F4BEFF5E16-- From nobody Fri Sep 16 11:46:20 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7E12B293 for ; Fri, 16 Sep 2016 11:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 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=-1.508, 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 azPYpNQXzusF for ; Fri, 16 Sep 2016 11:46:15 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 D33CB12B28B for ; Fri, 16 Sep 2016 11:46:14 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id b133so38551069vka.2 for ; Fri, 16 Sep 2016 11:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=95tdBSXa4eDUEf87zVdzIfQp9hKhexNJLwPqxTuv5xM=; b=AxX+HDVBgnLcQRviOszetTLm7BnmrfaOC+QzRe7utxAkTXD31Fz8WRPaADA9PB4TJs 47JQXNGzIQz8CuiX16lP0PHgx7jpzc+Zt8e/0cvLcK3170nZL66hCHg26PKX32l6V2PJ mcYJr0n0160yDu7h2Db6wDHj/zlqakCMLfUg9PwPm5k5/Cztlyhfma8QKEcEfLC9gDfY JlWEFKFAO/Ngo+5GPcHDCUhB9sO0XXkVHtfG7BrlTOLi+fnvpsPrfgoYsz2cf7Z6pxcb u3dXRjq+vP23X/mfUXl3e2fZIKZgEI4ZQEZR5KvRb1Hv5BqaHnVWLQAbrUzSjGnPPjDF QFxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=95tdBSXa4eDUEf87zVdzIfQp9hKhexNJLwPqxTuv5xM=; b=ZMNikXqXujG/Od1K5f6JxQY0pKlgegWT8WkQCL70KA9QwJaP5J/FxuUXC1tKqCz0yL CaHA872N4XHQd4CuM4Dg+pHuHT3Md1wFobdvpfrQci9R1DKCQfuV8GJFBibI0mMJ6B6p ZUEsZhaIZxitgXLu/B4BJix9zFQXHGGUC85nnI92PSZFB35+kkq9k/im7huXD4bfuQKC e/Ka5aXIJFU5Eyh1NZuqNxHrElNxuIKGZsYm8S5a6YCsCXJyb0FK1k+be2wIuXCUOjtB SdMaoH0FzQmXYOphLO7r0R4UzS4R2UzttBn/8Djx/GOJt4Cv0GnRVX8g4eiU2pheD56N zIlQ== X-Gm-Message-State: AE9vXwNYOMfsoS+0fz1JqGo2cqVj3JYCzMZblLOGNYUhMLq6H/4TZIHsO8Fdsn/Iu8XsrBNACIeE11S9ZJlxEUBE X-Received: by 10.31.238.9 with SMTP id m9mr4899480vkh.18.1474051573859; Fri, 16 Sep 2016 11:46:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.34.196 with HTTP; Fri, 16 Sep 2016 11:45:33 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Fri, 16 Sep 2016 11:45:33 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=94eb2c14997a712334053ca4607c Archived-At: Cc: "rtcweb@ietf.org" , Robin R Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 18:46:19 -0000 --94eb2c14997a712334053ca4607c Content-Type: text/plain; charset=UTF-8 I agree 100% that having a set of unit tests for the demux alogirthm. I found it very difficult to write the algorithm in a way that covered all the known cases by just keeping all the cases in my head. Any tweak (like swapping step 2 and step 3) can break something that you forget about. Having a set of unit tests would help a lot. I think we would need to formulate a unit test like this. Each test is a series of 3 operations: 1. Add an RtpReceiver with MID A, SSRCs 1, 2, 3, and PTs 4, 5, 6. 2. Route a packet with MID X (or unset), SSRC 1, PT 2. 3. Remove an RtpReceiver Then we have tests like: 1. Add X 2. Add Y 3. Route Z Or: 1. Add X 2. Route Y 3. Add Y 4. Remove X 4. Route Z Then I could write a little python to check these things. On Wed, Sep 14, 2016 at 10:49 AM, Bernard Aboba wrote: > There is now a JSEP PR relating to RTP demux algorithms: > https://github.com/rtcweb-wg/jsep/pull/320 > > Rather than commenting in detail on that PR in this post, I would like to > prove some thoughts on how we evaluate proposed RTP demux algorithms. > > The goal of an RTP demux algorithm is to determine whether an incoming RTP > packet received on a DtlsTransport can be forwarded to one of the > RtpReceivers attached to that DtlsTransport. If none of the RtpReceivers > qualify, then the packet is either dropped (WebRTC 1.0) or generates an RTP > unhandled event (ORTC). > > In principle, RTP demux algorithms do not seem complicated, since they > often can be expressed in less than half a dozen steps, typically with less > than a page of text. > > However, in practice the difficulty has turned out to be not in stating an > algorithm, but in evaluating whether it is correct. This challenges > include: > > 1. Agreement on a set of use cases and desired outcomes that a proposed > algorithm must satisfy. Think of this as a set of regression tests that > insure that a proposed algorithm behaves as we expect, as well as ensuring > that changes to that algorithm do not result in unintended consequences. > > 2. Agreement on all the inputs that the algorithm takes into account. > This includes fields within the RTP packet (e.g. SSRC, PT, RID, MID, etc.) > as well as methods within the API (e.g. setLocalDescription, > setRemoteDescription, setParameters, etc.). > > With respect to Issue #1, some of the trickiest use cases involve both PT > and SSRC signaling, SSRC "latching" and handling FEC and RTX. Examples > include: > a. Change of SSRCs (e.g. due to conflict). > b. Codec switching (e.g. changing PT but same SSRC, or changing both > PT and SSRC). > c. Use of both FEC and RTX (and perhaps RTX of FEC). > > IMHO it would be useful to come up a few (less than half a dozen) use > cases with agreed-upon outcomes. > > With respect to Issue #2, the proposed algorithms so far look at the SSRC > & PT fields in the RTP header as well as the MID RTP extension. However, I > have not seen algorithms which take into account the role of the RID RTP > extension. So agreement on whether the RID needs to be considered or not > would be helpful. > > Also, for WebRTC 1.0 it would appear to me that the algorithm will depend > on the inputs to the setLocalDescription/setRemoteDescription methods, so > that there is a potential dependency on the signaling state of the > PeerConnection. > > Overall, I believe that the discussion of RTP demux algorithms is likely > to go more smoothly (and conclude more quickly) if we get agreement on > these meta-issues upfront. > > > > > > > > > > > > > --94eb2c14997a712334053ca4607c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree 100% that having a set of unit tests for the de= mux alogirthm.=C2=A0 I found it very difficult to write the algorithm in a = way that covered all the known cases by just keeping all the cases in my he= ad.=C2=A0 Any tweak (like swapping step 2 and step 3) can break something t= hat you forget about.=C2=A0 Having a set of unit tests would help a lot.

I think we would need to formulate a unit test like this= .=C2=A0 Each test is a series of 3 operations:

1.=C2= =A0 Add an RtpReceiver with MID A, SSRCs 1, 2, 3, and PTs 4, 5, 6. =C2=A0
2.=C2=A0 Route a packet with MID X (or unset), SSRC 1, PT 2.
3.=C2=A0 Remove an RtpReceiver


Then we= have tests like:

1.=C2=A0 Add X
2.=C2=A0 Add = Y
3.=C2=A0 Route Z

Or:

1.= =C2=A0 Add X
2.=C2=A0 Route Y
3.=C2=A0 Add Y
4.=C2= =A0 Remove X
4.=C2=A0 Route Z


The= n I could write a little python to check these things.



= On Wed, Sep 14, 2016 at 10:49 AM, Bernard Aboba <bernard.aboba@gmail= .com> wrote:
There is now a JSEP PR relating to RTP demux algorithms:=C2=A0

R= ather than commenting in detail on that PR in this post, I would like to pr= ove some thoughts on how we evaluate proposed RTP demux algorithms.=C2=A0

The goal of an RTP demux algorithm is to determine = whether an incoming RTP packet received on a DtlsTransport can be forwarded= to one of the RtpReceivers attached to that DtlsTransport.=C2=A0 If none o= f the RtpReceivers qualify, then the packet is either dropped (WebRTC 1.0) = or generates an RTP unhandled event (ORTC).=C2=A0

= In principle, RTP demux algorithms do not seem complicated, since they ofte= n can be expressed in less than half a dozen steps, typically with less tha= n a page of text.=C2=A0

However, in practice the d= ifficulty has turned out to be not in stating an algorithm, but in evaluati= ng whether it is correct. This challenges include:=C2=A0

1. Agreement on a set of use cases and desired outcomes that a propo= sed algorithm must satisfy.=C2=A0 Think of this as a set of regression test= s that insure that a proposed algorithm behaves as we expect, as well as en= suring that changes to that algorithm do not result in unintended consequen= ces.=C2=A0

2. Agreement on all the inputs that the= algorithm takes into account.=C2=A0 This includes fields within the RTP pa= cket (e.g. SSRC, PT, RID, MID, etc.) as well as methods within the API (e.g= . setLocalDescription, setRemoteDescription, setParameters, etc.).=C2=A0

With respect to Issue #1, some of the trickiest use = cases involve both PT and SSRC signaling, SSRC "latching" and han= dling FEC and RTX.=C2=A0 Examples include:=C2=A0
=C2=A0 =C2=A0 a.= Change of SSRCs (e.g. due to conflict).=C2=A0
=C2=A0 =C2=A0 b. C= odec switching (e.g. changing PT but same SSRC, or changing both PT and SSR= C).
=C2=A0 =C2=A0 c. Use of both FEC and RTX (and perhaps RTX of = FEC).

IMHO it would be useful to come up a few (le= ss than half a dozen) use cases with agreed-upon outcomes.

With respect to Issue #2, the proposed algorithms so far look at t= he SSRC & PT fields in the RTP header as well as the MID RTP extension.= =C2=A0 However, I have not seen algorithms which take into account the role= of the RID RTP extension.=C2=A0 So agreement on whether the RID needs to b= e considered or not would be helpful.=C2=A0

Also, = for WebRTC 1.0 it would appear to me that the algorithm will depend on the = inputs to the setLocalDescription/setRemoteDescription methods, so tha= t there is a potential dependency on the signaling state of the PeerConnect= ion.

Overall, I believe that the discussion of RTP= demux algorithms is likely to go more smoothly (and conclude more quickly)= if we get agreement on these meta-issues upfront.=C2=A0













--94eb2c14997a712334053ca4607c-- From nobody Fri Sep 16 11:48:18 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B0512B2D4 for ; Fri, 16 Sep 2016 11:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 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=-1.508, 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 IhJAbd2zFF6p for ; Fri, 16 Sep 2016 11:48:15 -0700 (PDT) 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 393FA12B2D1 for ; Fri, 16 Sep 2016 11:48:15 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id b133so38627343vka.2 for ; Fri, 16 Sep 2016 11:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iE6r/YlnaweQWrlyxluu9tGUd6KMyJb0eQ39uSeBs0k=; b=E7Kld2eWpD/YFU3kICZkFjviyQRJCAPj9H6cgXgmwdA7lOIFHOd0TF+NVIKyg1PCi5 vDrhVohY4mbu1Lojn/7CBpsBe1KQc7LQTDGsMbNGsif9I46eSqdwGEmyD1u4UgJSVsBr 4B9fRdiSqeBm19zrp/qJD4CQwOGYWBhft05as3Jc+cRe8FE26Z1UH5xchI63ktoTsI0v PktfgVfZ/1JofcxjPLsSD+wFcVmdCMr8yOUDfnXC2TVUJXKIxINNXAJnhCc6cnRbbANT ndEO8+LX++ZgudRRWKyvG/hkXg51mDA/9lBAwlyDolRQl+gO5ISe+Y6fyP5Ig1hAzIC6 iBfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iE6r/YlnaweQWrlyxluu9tGUd6KMyJb0eQ39uSeBs0k=; b=E9881yUBl8LdLLBXtOJ6a/nzWrIC+kIG6ttvuCGU/8XbxyBFFZobdDopi/LPKNmHVo E7YBqD5WfHa8uvoK2AF4S8Ne63ofo1z4KmUQmCYU6q1DshTFfDSKrxlyzGt06MPnvgMP 1wCz2v1A8BuKxl6oIHumZCtduXZMP/L+BX0V8vx/RbE87mWnqGNOLP8AWuVdZH0Wmt7l PSX6jc56BcJ3aLKT77KJcTnNnKWWGoj+CixTA9WiB2fwtYbGKlSodUGDCFXxMrtZGzQd h42mJ6MIUvQQcW81tAB0QcXVzoWTNbKz/yPj8prAhvou3dLyV7F63eenBFcdbmDXG3y3 SjJw== X-Gm-Message-State: AE9vXwP2YkfzpXOpBr7rT7FvKSIAldOrSEh06oKg+zChWuK589WP4ZeXpyCeHuVQ+c2IQ8p+UD3lv52D1qC1i4/V X-Received: by 10.31.152.194 with SMTP id a185mr5061931vke.59.1474051694290; Fri, 16 Sep 2016 11:48:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.34.196 with HTTP; Fri, 16 Sep 2016 11:47:33 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Fri, 16 Sep 2016 11:47:33 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a1141d9c49eae8a053ca467a2 Archived-At: Cc: "rtcweb@ietf.org" , Robin R Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 18:48:17 -0000 --001a1141d9c49eae8a053ca467a2 Content-Type: text/plain; charset=UTF-8 By the way, as I mentioned elsewhere, I think we should not use RIDs for demux between RtpReceivers, and only use them within an RtpReceiver. Demux between RtpReceivers should be done with MID. On Fri, Sep 16, 2016 at 11:45 AM, Peter Thatcher wrote: > I agree 100% that having a set of unit tests for the demux alogirthm. I > found it very difficult to write the algorithm in a way that covered all > the known cases by just keeping all the cases in my head. Any tweak (like > swapping step 2 and step 3) can break something that you forget about. > Having a set of unit tests would help a lot. > > I think we would need to formulate a unit test like this. Each test is a > series of 3 operations: > > 1. Add an RtpReceiver with MID A, SSRCs 1, 2, 3, and PTs 4, 5, 6. > 2. Route a packet with MID X (or unset), SSRC 1, PT 2. > 3. Remove an RtpReceiver > > > Then we have tests like: > > 1. Add X > 2. Add Y > 3. Route Z > > Or: > > 1. Add X > 2. Route Y > 3. Add Y > 4. Remove X > 4. Route Z > > > Then I could write a little python to check these things. > > > > On Wed, Sep 14, 2016 at 10:49 AM, Bernard Aboba > wrote: > >> There is now a JSEP PR relating to RTP demux algorithms: >> https://github.com/rtcweb-wg/jsep/pull/320 >> >> Rather than commenting in detail on that PR in this post, I would like to >> prove some thoughts on how we evaluate proposed RTP demux algorithms. >> >> The goal of an RTP demux algorithm is to determine whether an incoming >> RTP packet received on a DtlsTransport can be forwarded to one of the >> RtpReceivers attached to that DtlsTransport. If none of the RtpReceivers >> qualify, then the packet is either dropped (WebRTC 1.0) or generates an RTP >> unhandled event (ORTC). >> >> In principle, RTP demux algorithms do not seem complicated, since they >> often can be expressed in less than half a dozen steps, typically with less >> than a page of text. >> >> However, in practice the difficulty has turned out to be not in stating >> an algorithm, but in evaluating whether it is correct. This challenges >> include: >> >> 1. Agreement on a set of use cases and desired outcomes that a proposed >> algorithm must satisfy. Think of this as a set of regression tests that >> insure that a proposed algorithm behaves as we expect, as well as ensuring >> that changes to that algorithm do not result in unintended consequences. >> >> 2. Agreement on all the inputs that the algorithm takes into account. >> This includes fields within the RTP packet (e.g. SSRC, PT, RID, MID, etc.) >> as well as methods within the API (e.g. setLocalDescription, >> setRemoteDescription, setParameters, etc.). >> >> With respect to Issue #1, some of the trickiest use cases involve both PT >> and SSRC signaling, SSRC "latching" and handling FEC and RTX. Examples >> include: >> a. Change of SSRCs (e.g. due to conflict). >> b. Codec switching (e.g. changing PT but same SSRC, or changing both >> PT and SSRC). >> c. Use of both FEC and RTX (and perhaps RTX of FEC). >> >> IMHO it would be useful to come up a few (less than half a dozen) use >> cases with agreed-upon outcomes. >> >> With respect to Issue #2, the proposed algorithms so far look at the SSRC >> & PT fields in the RTP header as well as the MID RTP extension. However, I >> have not seen algorithms which take into account the role of the RID RTP >> extension. So agreement on whether the RID needs to be considered or not >> would be helpful. >> >> Also, for WebRTC 1.0 it would appear to me that the algorithm will depend >> on the inputs to the setLocalDescription/setRemoteDescription methods, >> so that there is a potential dependency on the signaling state of the >> PeerConnection. >> >> Overall, I believe that the discussion of RTP demux algorithms is likely >> to go more smoothly (and conclude more quickly) if we get agreement on >> these meta-issues upfront. >> >> >> >> >> >> >> >> >> >> >> >> >> > --001a1141d9c49eae8a053ca467a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By the way, as I mentioned elsewhere, I think we should= not use RIDs for demux between RtpReceivers, and only use them within an R= tpReceiver.=C2=A0 Demux between RtpReceivers should be done with MID.
=

On Fri, Sep= 16, 2016 at 11:45 AM, Peter Thatcher <pthatcher@google.com> wrote:
I agree 10= 0% that having a set of unit tests for the demux alogirthm.=C2=A0 I found i= t very difficult to write the algorithm in a way that covered all the known= cases by just keeping all the cases in my head.=C2=A0 Any tweak (like swap= ping step 2 and step 3) can break something that you forget about.=C2=A0 Ha= ving a set of unit tests would help a lot.

I think we = would need to formulate a unit test like this.=C2=A0 Each test is a series = of 3 operations:

1.=C2=A0 Add an RtpReceiver with MID = A, SSRCs 1, 2, 3, and PTs 4, 5, 6. =C2=A0
2.=C2=A0 Route a packet w= ith MID X (or unset), SSRC 1, PT 2.
3.=C2=A0 Remove an RtpReceiver<= /div>


Then we have tests like:

1.=C2=A0 Add X
2.=C2=A0 Add Y
3.=C2=A0 Route Z
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">
Or:

1.=C2=A0 Add X
2.=C2=A0 Rou= te Y
3.=C2=A0 Add Y
4.=C2=A0 Remove X
4.=C2=A0 Rout= e Z


Then I could write a little python to= check these things.



On Wed, Sep 14, 2016 at 10:49 AM, Bernard Aboba &= lt;bernard.abo= ba@gmail.com> wrote:
There is now a JSEP PR relating to RTP demux algorithms:=C2=A0https://github.com/rtcweb-wg/jsep/pull/320

Rather than commenting in detail on that PR in this post, I would li= ke to prove some thoughts on how we evaluate proposed RTP demux algorithms.= =C2=A0

The goal of an RTP demux algorithm is to de= termine whether an incoming RTP packet received on a DtlsTransport can be f= orwarded to one of the RtpReceivers attached to that DtlsTransport.=C2=A0 I= f none of the RtpReceivers qualify, then the packet is either dropped (WebR= TC 1.0) or generates an RTP unhandled event (ORTC).=C2=A0

In principle, RTP demux algorithms do not seem complicated, since t= hey often can be expressed in less than half a dozen steps, typically with = less than a page of text.=C2=A0

However, in practi= ce the difficulty has turned out to be not in stating an algorithm, but in = evaluating whether it is correct. This challenges include:=C2=A0
=
1. Agreement on a set of use cases and desired outcomes that= a proposed algorithm must satisfy.=C2=A0 Think of this as a set of regress= ion tests that insure that a proposed algorithm behaves as we expect, as we= ll as ensuring that changes to that algorithm do not result in unintended c= onsequences.=C2=A0

2. Agreement on all the inputs = that the algorithm takes into account.=C2=A0 This includes fields within th= e RTP packet (e.g. SSRC, PT, RID, MID, etc.) as well as methods within the = API (e.g. setLocalDescription, setRemoteDescription, setParameters, etc.).= =C2=A0

With respect to Issue #1, some of the trick= iest use cases involve both PT and SSRC signaling, SSRC "latching"= ; and handling FEC and RTX.=C2=A0 Examples include:=C2=A0
=C2=A0 = =C2=A0 a. Change of SSRCs (e.g. due to conflict).=C2=A0
=C2=A0 = =C2=A0 b. Codec switching (e.g. changing PT but same SSRC, or changing both= PT and SSRC).
=C2=A0 =C2=A0 c. Use of both FEC and RTX (and perh= aps RTX of FEC).

IMHO it would be useful to come u= p a few (less than half a dozen) use cases with agreed-upon outcomes.
=

With respect to Issue #2, the proposed algorithms so fa= r look at the SSRC & PT fields in the RTP header as well as the MID RTP= extension.=C2=A0 However, I have not seen algorithms which take into accou= nt the role of the RID RTP extension.=C2=A0 So agreement on whether the RID= needs to be considered or not would be helpful.=C2=A0

=
Also, for WebRTC 1.0 it would appear to me that the algorithm will dep= end on the inputs to the setLocalDescription/setRemoteDescription meth= ods, so that there is a potential dependency on the signaling state of the = PeerConnection.

Overall, I believe that the discus= sion of RTP demux algorithms is likely to go more smoothly (and conclude mo= re quickly) if we get agreement on these meta-issues upfront.=C2=A0














--001a1141d9c49eae8a053ca467a2-- From nobody Fri Sep 16 11:59:42 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994D212B2EE for ; Fri, 16 Sep 2016 11:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 oXKU32s-HbuV for ; Fri, 16 Sep 2016 11:59:39 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 1A5DF12B293 for ; Fri, 16 Sep 2016 11:59:39 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8GIxYdE010955; Fri, 16 Sep 2016 14:59:36 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 25ccx4x7p3-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Sep 2016 14:59:36 -0400 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; Fri, 16 Sep 2016 13:59:36 -0500 From: Jonathan Lennox To: Cullen Jennings Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSEEqiRc9bJSa2qkmm5GrI8oyLzKB8zCkA Date: Fri, 16 Sep 2016 18:59:34 +0000 Message-ID: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> References: In-Reply-To: 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: multipart/alternative; boundary="_000_66CB8C7B56D14AC9B0F84F1689E2CA89vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-16_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609160240 Archived-At: Cc: "rtcweb@ietf.org" , Robin Raymond Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 18:59:41 -0000 --_000_66CB8C7B56D14AC9B0F84F1689E2CA89vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGdvaW5nIHRvIGNvbWUgdXAgd2l0aCBiZXZlcmFnZSBuYW1lcyBmb3IgbXkgZXhh bXBsZXMsIGJ1dCBmZWVsIGZyZWUgdG8gbWFrZSB1cCB5b3VyIG93bi4NCg0KMS4gVGhlIFBUIGFy ZSBhbGwgdGhlIHNhbWUuICBBbiBSVENQIHNvdXJjZSBkZXNjcmlwdGlvbiBmb3IgYW4gU1NSQyBj b250YWlucyBhIE1JRC4gIFRoaXMgbGF0Y2hlcyB0aGUgTUlELiAgTGF0ZXIsIFJUUCBwYWNrZXRz IHdpdGggdGhpcyBTU1JDIGFycml2ZSB3aXRob3V0IGEgTUlELiBUaGV5IGdvIHRvIHRoZSBwbGFj ZSBtYXRjaGluZyB0aGUgTUlEIHRoYXQgd2FzIGluIFJUQ1AuDQoNCjIuIFRoZSBQVCBhcmUgYWxs IHRoZSBzYW1lLiAgQSBwYWNrZXQgY29udGFpbnMgTUlEMS4gIEl0IGdvZXMgdG8gdGhlIHBsYWNl IHRoYXQgbWF0Y2hlcyBNSUQxLCBsYXRjaGluZyB0aGUgU1NSQyB0byBNSUQxLiAgTGF0ZXIsIGEg cGFja2V0IHdpdGggdGhlIHNhbWUgU1NSQyBjb250YWlucyBNSUQyLiBUaGlzIG1vdmVzIHRoZSBs YXRjaGluZywgc28gdGhlIFNTUkMgaXMgbm93IGxhdGNoZWQgdG8gTUlEMi4NCg0KDQpPbiBTZXAg MTUsIDIwMTYsIGF0IDY6MTggUE0sIEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYTxtYWls dG86Zmx1ZmZ5QGlpaS5jYT4+IHdyb3RlOg0KDQoNClRvIHByb3Bvc2UgYSBmZXcgdXNlIGNhc2Xi gKYuDQoNCuKAnFdoaXNrZXkgJiBTb2RhIEV4YW1wbGXigJ0NClRoZSBQVCBhcmUgYWxsIHRoZSBz YW1lLiBFYXJseSBwYWNrZXRzLCBhbmQgYW55IHBhY2tldHMgYWZ0ZXIgYSBTU1JDIGNoYW5nZSwg Y29udGFpbiBhIE1JRC4gSWYgdGhlIHBhY2tldCBoYXMgIE1JRCwgaXQgZ29lcyB0byB0aGUgcGxh Y2UgdGhhdCBtYXRjaGVzIHRoYXQgTUlEICphbmQqIGl0IGxhdGNoZXMgdGhhdCBTU1JDIHNvIGFu eSBmdXR1cmUgU1NSQyB0aGF0IGRvbuKAmXQgaGF2ZSBhIE1JRCBnbyB0aGUgdG8gdGhlIHNhbWUg cGxhY2UuDQoNCuKAnENva2UgQ2xhc3NpYyBFeGFtcGxl4oCdDQpUaGUgUFQgYXJlIGFsbCB1bmlx dWUuIFRoZSBTU1JDIGNoYW5nZS4gVGhlcmUgaXMgbm8gUklELCBNSUQsIEZFQywgb3IgUlRYLiBU aGUgcGFja2V0cyBnZXQgZGVsaXZlcmVkIHRvIHRoZSB0aGluZyB3aXRoIHRoZSBtYXRjaGluZyBQ VC4NCg0K4oCcQmxvZGR5IE1hcnkgRXhhbXBsZeKAnQ0KVGhlIFBUIGFyZSB0aGUgc2FtZS4gVGhl IFNTUkMgZG8gbm90IGNoYW5nZWQgYW5kIGFyZSBzaWduYWxsZWQgaW4gU0RQLiBUaGVyZSBpcyBu byBNSUQsIFJJRCwgZXRjIGluIHRoZSBSVFAuICBUaGUgcGFja2V0cyBnbyB0byB0aGUgdGhpbmcg dGhlIFNTUkMgc2lnbmFsbGluZyB3b3VsZCBoYXZlIGluZGljYXRlZC4NCg0K4oCcRGlldCBDb2tl IEV4YW1wbGXigJ0NClRoZSBQVCBhcmUgYWxsIHVuaXF1ZS4gVGhlIHBhY2tldCBoYXMgYSBNSUQu IFRoZSBNSUQgY29ycmVzcG9uZHMgdG8gYSBhbiBtLWxpbmUgdGhhdCBkb2VzIG5vdCBoYXZlIFBU IGFzc29jaWF0ZWQgd2l0aCBpdCB0aGF0IG1hdGNoIHRoZSBQVC4gKHRoZSBQVCBpcyBmcm9tIGEg ZGlmZmVyZW50IG0tbGluZSkuIFRoZSBwYWNrZXRzIGdldHMgZHJvcHBlZCAob3IgY2F1c2UgZXZl bnQgaW4gT1JUQykuIFsgTm90ZSBJIHRoaW5rIG9mIHRoaXMgdGhhdCB0aGUgTUlEIHNlbmRzIGl0 IHRvIHRoZSByaWdodCBtLWxpbmUgYWthIFJlY2VpdmVyLCBidXQgdGhlbiB0aGF0IGRvZXMgbm90 IGhhdmUgYSBjb2RlYyBmb3IgdGhhdCBQVCBzbyBpdCBnZXRzIGRyb3BwZWQuIF0NCg0K4oCcRGll dCBQZXBzaSBFeGFtcGxl4oCdDQpUaGUgUFQgYXJlIGFsbCB1bmlxdWUuIFRoZSBwYWNrZXQgaGFz IGEgU1NSQy4gVGhlIFNTUkMgZG9lcyBub3QgY29ycmVzcG9uZCB0byBhbnkgU1NSQyB0aGF0IHdl cmUgc2lnbmFsbGVkIGZvciB0aGUgbS1saW5lIHRoYXQgdGhlIFBUIGlzIG9uLiBUaGUgcGFja2V0 IGdvZXMgdG8gdGhlIHRoaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGF0IFBUIGlnbm9yaW5nIGFueSBT U1JDLg0KDQrigJxSZWQgQnVsbCBFeGFtcGxl4oCdDQpUaGUgcGFja2V0IGhhcyBhIE1JRCB0aGF0 IGRvZXMgbm90IG1hdGNoIGFueSBNSUQgaW4gdGhlIHNpZ25hbGxpbmcuIFRoZSBwYWNrZXRzIGdl dHMgZHJvcHBlZCAob3IgZXZlbnQgaW4gT1JUQykuDQoNCg0KDQoNCg0KDQpPbiBTZXAgMTQsIDIw MTYsIGF0IDEwOjQ5IEFNLCBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxt YWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KVGhlcmUgaXMgbm93IGEg SlNFUCBQUiByZWxhdGluZyB0byBSVFAgZGVtdXggYWxnb3JpdGhtczoNCmh0dHBzOi8vZ2l0aHVi LmNvbS9ydGN3ZWItd2cvanNlcC9wdWxsLzMyMA0KDQpSYXRoZXIgdGhhbiBjb21tZW50aW5nIGlu IGRldGFpbCBvbiB0aGF0IFBSIGluIHRoaXMgcG9zdCwgSSB3b3VsZCBsaWtlIHRvIHByb3ZlIHNv bWUgdGhvdWdodHMgb24gaG93IHdlIGV2YWx1YXRlIHByb3Bvc2VkIFJUUCBkZW11eCBhbGdvcml0 aG1zLg0KDQpUaGUgZ29hbCBvZiBhbiBSVFAgZGVtdXggYWxnb3JpdGhtIGlzIHRvIGRldGVybWlu ZSB3aGV0aGVyIGFuIGluY29taW5nIFJUUCBwYWNrZXQgcmVjZWl2ZWQgb24gYSBEdGxzVHJhbnNw b3J0IGNhbiBiZSBmb3J3YXJkZWQgdG8gb25lIG9mIHRoZSBSdHBSZWNlaXZlcnMgYXR0YWNoZWQg dG8gdGhhdCBEdGxzVHJhbnNwb3J0LiAgSWYgbm9uZSBvZiB0aGUgUnRwUmVjZWl2ZXJzIHF1YWxp ZnksIHRoZW4gdGhlIHBhY2tldCBpcyBlaXRoZXIgZHJvcHBlZCAoV2ViUlRDIDEuMCkgb3IgZ2Vu ZXJhdGVzIGFuIFJUUCB1bmhhbmRsZWQgZXZlbnQgKE9SVEMpLg0KDQpJbiBwcmluY2lwbGUsIFJU UCBkZW11eCBhbGdvcml0aG1zIGRvIG5vdCBzZWVtIGNvbXBsaWNhdGVkLCBzaW5jZSB0aGV5IG9m dGVuIGNhbiBiZSBleHByZXNzZWQgaW4gbGVzcyB0aGFuIGhhbGYgYSBkb3plbiBzdGVwcywgdHlw aWNhbGx5IHdpdGggbGVzcyB0aGFuIGEgcGFnZSBvZiB0ZXh0Lg0KDQpIb3dldmVyLCBpbiBwcmFj dGljZSB0aGUgZGlmZmljdWx0eSBoYXMgdHVybmVkIG91dCB0byBiZSBub3QgaW4gc3RhdGluZyBh biBhbGdvcml0aG0sIGJ1dCBpbiBldmFsdWF0aW5nIHdoZXRoZXIgaXQgaXMgY29ycmVjdC4gVGhp cyBjaGFsbGVuZ2VzIGluY2x1ZGU6DQoNCjEuIEFncmVlbWVudCBvbiBhIHNldCBvZiB1c2UgY2Fz ZXMgYW5kIGRlc2lyZWQgb3V0Y29tZXMgdGhhdCBhIHByb3Bvc2VkIGFsZ29yaXRobSBtdXN0IHNh dGlzZnkuICBUaGluayBvZiB0aGlzIGFzIGEgc2V0IG9mIHJlZ3Jlc3Npb24gdGVzdHMgdGhhdCBp bnN1cmUgdGhhdCBhIHByb3Bvc2VkIGFsZ29yaXRobSBiZWhhdmVzIGFzIHdlIGV4cGVjdCwgYXMg d2VsbCBhcyBlbnN1cmluZyB0aGF0IGNoYW5nZXMgdG8gdGhhdCBhbGdvcml0aG0gZG8gbm90IHJl c3VsdCBpbiB1bmludGVuZGVkIGNvbnNlcXVlbmNlcy4NCg0KMi4gQWdyZWVtZW50IG9uIGFsbCB0 aGUgaW5wdXRzIHRoYXQgdGhlIGFsZ29yaXRobSB0YWtlcyBpbnRvIGFjY291bnQuICBUaGlzIGlu Y2x1ZGVzIGZpZWxkcyB3aXRoaW4gdGhlIFJUUCBwYWNrZXQgKGUuZy4gU1NSQywgUFQsIFJJRCwg TUlELCBldGMuKSBhcyB3ZWxsIGFzIG1ldGhvZHMgd2l0aGluIHRoZSBBUEkgKGUuZy4gc2V0TG9j YWxEZXNjcmlwdGlvbiwgc2V0UmVtb3RlRGVzY3JpcHRpb24sIHNldFBhcmFtZXRlcnMsIGV0Yy4p Lg0KDQpXaXRoIHJlc3BlY3QgdG8gSXNzdWUgIzEsIHNvbWUgb2YgdGhlIHRyaWNraWVzdCB1c2Ug Y2FzZXMgaW52b2x2ZSBib3RoIFBUIGFuZCBTU1JDIHNpZ25hbGluZywgU1NSQyAibGF0Y2hpbmci IGFuZCBoYW5kbGluZyBGRUMgYW5kIFJUWC4gIEV4YW1wbGVzIGluY2x1ZGU6DQogICAgYS4gQ2hh bmdlIG9mIFNTUkNzIChlLmcuIGR1ZSB0byBjb25mbGljdCkuDQogICAgYi4gQ29kZWMgc3dpdGNo aW5nIChlLmcuIGNoYW5naW5nIFBUIGJ1dCBzYW1lIFNTUkMsIG9yIGNoYW5naW5nIGJvdGggUFQg YW5kIFNTUkMpLg0KICAgIGMuIFVzZSBvZiBib3RoIEZFQyBhbmQgUlRYIChhbmQgcGVyaGFwcyBS VFggb2YgRkVDKS4NCg0KSU1ITyBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gY29tZSB1cCBhIGZldyAo bGVzcyB0aGFuIGhhbGYgYSBkb3plbikgdXNlIGNhc2VzIHdpdGggYWdyZWVkLXVwb24gb3V0Y29t ZXMuDQoNCldpdGggcmVzcGVjdCB0byBJc3N1ZSAjMiwgdGhlIHByb3Bvc2VkIGFsZ29yaXRobXMg c28gZmFyIGxvb2sgYXQgdGhlIFNTUkMgJiBQVCBmaWVsZHMgaW4gdGhlIFJUUCBoZWFkZXIgYXMg d2VsbCBhcyB0aGUgTUlEIFJUUCBleHRlbnNpb24uICBIb3dldmVyLCBJIGhhdmUgbm90IHNlZW4g YWxnb3JpdGhtcyB3aGljaCB0YWtlIGludG8gYWNjb3VudCB0aGUgcm9sZSBvZiB0aGUgUklEIFJU UCBleHRlbnNpb24uICBTbyBhZ3JlZW1lbnQgb24gd2hldGhlciB0aGUgUklEIG5lZWRzIHRvIGJl IGNvbnNpZGVyZWQgb3Igbm90IHdvdWxkIGJlIGhlbHBmdWwuDQoNCkFsc28sIGZvciBXZWJSVEMg MS4wIGl0IHdvdWxkIGFwcGVhciB0byBtZSB0aGF0IHRoZSBhbGdvcml0aG0gd2lsbCBkZXBlbmQg b24gdGhlIGlucHV0cyB0byB0aGUgc2V0TG9jYWxEZXNjcmlwdGlvbi9zZXRSZW1vdGVEZXNjcmlw dGlvbiBtZXRob2RzLCBzbyB0aGF0IHRoZXJlIGlzIGEgcG90ZW50aWFsIGRlcGVuZGVuY3kgb24g dGhlIHNpZ25hbGluZyBzdGF0ZSBvZiB0aGUgUGVlckNvbm5lY3Rpb24uDQoNCk92ZXJhbGwsIEkg YmVsaWV2ZSB0aGF0IHRoZSBkaXNjdXNzaW9uIG9mIFJUUCBkZW11eCBhbGdvcml0aG1zIGlzIGxp a2VseSB0byBnbyBtb3JlIHNtb290aGx5IChhbmQgY29uY2x1ZGUgbW9yZSBxdWlja2x5KSBpZiB3 ZSBnZXQgYWdyZWVtZW50IG9uIHRoZXNlIG1ldGEtaXNzdWVzIHVwZnJvbnQuDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2Vi IG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_66CB8C7B56D14AC9B0F84F1689E2CA89vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5J4oCZbSBu b3QgZ29pbmcgdG8gY29tZSB1cCB3aXRoIGJldmVyYWdlIG5hbWVzIGZvciBteSBleGFtcGxlcywg YnV0IGZlZWwgZnJlZSB0byBtYWtlIHVwIHlvdXIgb3duLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4gVGhlIFBUIGFyZSBhbGwgdGhl IHNhbWUuICZuYnNwO0FuIFJUQ1Agc291cmNlIGRlc2NyaXB0aW9uIGZvciBhbiBTU1JDIGNvbnRh aW5zIGEgTUlELiAmbmJzcDtUaGlzIGxhdGNoZXMgdGhlIE1JRC4gJm5ic3A7TGF0ZXIsIFJUUCBw YWNrZXRzIHdpdGggdGhpcyBTU1JDIGFycml2ZSB3aXRob3V0IGEgTUlELiBUaGV5IGdvIHRvIHRo ZSBwbGFjZSBtYXRjaGluZyB0aGUgTUlEIHRoYXQgd2FzIGluIFJUQ1AuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4yLiBUaGUgUFQgYXJl IGFsbCB0aGUgc2FtZS4gJm5ic3A7QSBwYWNrZXQgY29udGFpbnMgTUlEMS4gJm5ic3A7SXQgZ29l cyB0byB0aGUgcGxhY2UgdGhhdCBtYXRjaGVzIE1JRDEsIGxhdGNoaW5nIHRoZSBTU1JDIHRvIE1J RDEuICZuYnNwO0xhdGVyLCBhIHBhY2tldCB3aXRoIHRoZSBzYW1lIFNTUkMgY29udGFpbnMgTUlE Mi4gVGhpcyBtb3ZlcyB0aGUgbGF0Y2hpbmcsIHNvIHRoZSBTU1JDIGlzIG5vdyBsYXRjaGVkIHRv IE1JRDIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P biBTZXAgMTUsIDIwMTYsIGF0IDY6MTggUE0sIEN1bGxlbiBKZW5uaW5ncyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmZsdWZmeUBpaWkuY2EiIGNsYXNzPSIiPmZsdWZmeUBpaWkuY2E8L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpUbyBwcm9wb3NlIGEg ZmV3IHVzZSBjYXNl4oCmLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCcV2hpc2tleSAmYW1wOyBTb2RhIEV4YW1wbGXigJ08L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+VGhlIFBUIGFyZSBhbGwgdGhlIHNhbWUuIEVhcmx5IHBhY2tldHMsIGFuZCBhbnkg cGFja2V0cyBhZnRlciBhIFNTUkMgY2hhbmdlLCBjb250YWluIGEgTUlELiBJZiB0aGUgcGFja2V0 IGhhcyAmbmJzcDtNSUQsIGl0IGdvZXMgdG8gdGhlIHBsYWNlIHRoYXQgbWF0Y2hlcyB0aGF0IE1J RCAqYW5kKiBpdCBsYXRjaGVzIHRoYXQgU1NSQyBzbyBhbnkgZnV0dXJlIFNTUkMgdGhhdCBkb27i gJl0IGhhdmUgYSBNSUQgZ28gdGhlIHRvIHRoZSBzYW1lDQogcGxhY2UuJm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJxDb2tl IENsYXNzaWMgRXhhbXBsZeKAnSZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgUFQgYXJl IGFsbCB1bmlxdWUuIFRoZSBTU1JDIGNoYW5nZS4gVGhlcmUgaXMgbm8gUklELCBNSUQsIEZFQywg b3IgUlRYLiBUaGUgcGFja2V0cyBnZXQgZGVsaXZlcmVkIHRvIHRoZSB0aGluZyB3aXRoIHRoZSBt YXRjaGluZyBQVC4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPuKAnEJsb2RkeSBNYXJ5IEV4YW1wbGXigJ0mbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+VGhlIFBUIGFyZSB0aGUgc2FtZS4gVGhlIFNTUkMgZG8gbm90IGNoYW5nZWQgYW5k IGFyZSBzaWduYWxsZWQgaW4gU0RQLiBUaGVyZSBpcyBubyBNSUQsIFJJRCwgZXRjIGluIHRoZSBS VFAuICZuYnNwO1RoZSBwYWNrZXRzIGdvIHRvIHRoZSB0aGluZyB0aGUgU1NSQyBzaWduYWxsaW5n IHdvdWxkIGhhdmUgaW5kaWNhdGVkLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCcRGlldCBDb2tlIEV4YW1wbGXigJ08L2Rp dj4NCjxkaXYgY2xhc3M9IiI+VGhlIFBUIGFyZSBhbGwgdW5pcXVlLiBUaGUgcGFja2V0IGhhcyBh IE1JRC4gVGhlIE1JRCBjb3JyZXNwb25kcyB0byBhIGFuIG0tbGluZSB0aGF0IGRvZXMgbm90IGhh dmUgUFQgYXNzb2NpYXRlZCB3aXRoIGl0IHRoYXQgbWF0Y2ggdGhlIFBULiAodGhlIFBUIGlzIGZy b20gYSBkaWZmZXJlbnQgbS1saW5lKS4gVGhlIHBhY2tldHMgZ2V0cyBkcm9wcGVkIChvciBjYXVz ZSBldmVudCBpbiBPUlRDKS4gWyBOb3RlIEkgdGhpbmsNCiBvZiB0aGlzIHRoYXQgdGhlIE1JRCBz ZW5kcyBpdCB0byB0aGUgcmlnaHQgbS1saW5lIGFrYSBSZWNlaXZlciwgYnV0IHRoZW4gdGhhdCBk b2VzIG5vdCBoYXZlIGEgY29kZWMgZm9yIHRoYXQgUFQgc28gaXQgZ2V0cyBkcm9wcGVkLiBdPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7i gJxEaWV0IFBlcHNpIEV4YW1wbGXigJ08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIFBUIGFyZSBh bGwgdW5pcXVlLiBUaGUgcGFja2V0IGhhcyBhIFNTUkMuIFRoZSBTU1JDIGRvZXMgbm90IGNvcnJl c3BvbmQgdG8gYW55IFNTUkMgdGhhdCB3ZXJlIHNpZ25hbGxlZCBmb3IgdGhlIG0tbGluZSB0aGF0 IHRoZSBQVCBpcyBvbi4gVGhlIHBhY2tldCBnb2VzIHRvIHRoZSB0aGluZyBhc3NvY2lhdGVkIHdp dGggdGhhdCBQVCBpZ25vcmluZyBhbnkgU1NSQy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAnFJlZCBCdWxsIEV4YW1wbGXi gJ08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIHBhY2tldCBoYXMgYSBNSUQgdGhhdCBkb2VzIG5v dCBtYXRjaCBhbnkgTUlEIGluIHRoZSBzaWduYWxsaW5nLiBUaGUgcGFja2V0cyBnZXRzIGRyb3Bw ZWQgKG9yIGV2ZW50IGluIE9SVEMpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2VwIDE0LCAyMDE2LCBhdCAxMDo0OSBBTSwgQmVy bmFyZCBBYm9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiBj bGFzcz0iIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj5UaGVyZSBpcyBub3cgYSBKU0VQIFBSIHJlbGF0aW5nIHRvIFJU UCBkZW11eCBhbGdvcml0aG1zOiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczov L2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvcHVsbC8zMjAiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0 aHViLmNvbS9ydGN3ZWItd2cvanNlcC9wdWxsLzMyMDwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJhdGhl ciB0aGFuIGNvbW1lbnRpbmcgaW4gZGV0YWlsIG9uIHRoYXQgUFIgaW4gdGhpcyBwb3N0LCBJIHdv dWxkIGxpa2UgdG8gcHJvdmUgc29tZSB0aG91Z2h0cyBvbiBob3cgd2UgZXZhbHVhdGUgcHJvcG9z ZWQgUlRQIGRlbXV4IGFsZ29yaXRobXMuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgZ29hbCBvZiBhbiBSVFAgZGVtdXgg YWxnb3JpdGhtIGlzIHRvIGRldGVybWluZSB3aGV0aGVyIGFuIGluY29taW5nIFJUUCBwYWNrZXQg cmVjZWl2ZWQgb24gYSBEdGxzVHJhbnNwb3J0IGNhbiBiZSBmb3J3YXJkZWQgdG8gb25lIG9mIHRo ZSBSdHBSZWNlaXZlcnMgYXR0YWNoZWQgdG8gdGhhdCBEdGxzVHJhbnNwb3J0LiZuYnNwOyBJZiBu b25lIG9mIHRoZSBSdHBSZWNlaXZlcnMgcXVhbGlmeSwgdGhlbiB0aGUgcGFja2V0IGlzDQogZWl0 aGVyIGRyb3BwZWQgKFdlYlJUQyAxLjApIG9yIGdlbmVyYXRlcyBhbiBSVFAgdW5oYW5kbGVkIGV2 ZW50IChPUlRDKS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkluIHByaW5jaXBsZSwgUlRQIGRlbXV4IGFsZ29yaXRobXMgZG8g bm90IHNlZW0gY29tcGxpY2F0ZWQsIHNpbmNlIHRoZXkgb2Z0ZW4gY2FuIGJlIGV4cHJlc3NlZCBp biBsZXNzIHRoYW4gaGFsZiBhIGRvemVuIHN0ZXBzLCB0eXBpY2FsbHkgd2l0aCBsZXNzIHRoYW4g YSBwYWdlIG9mIHRleHQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ib3dldmVyLCBpbiBwcmFjdGljZSB0aGUgZGlmZmljdWx0 eSBoYXMgdHVybmVkIG91dCB0byBiZSBub3QgaW4gc3RhdGluZyBhbiBhbGdvcml0aG0sIGJ1dCBp biBldmFsdWF0aW5nIHdoZXRoZXIgaXQgaXMgY29ycmVjdC4gVGhpcyBjaGFsbGVuZ2VzIGluY2x1 ZGU6Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4xLiBBZ3JlZW1lbnQgb24gYSBzZXQgb2YgdXNlIGNhc2VzIGFuZCBkZXNpcmVk IG91dGNvbWVzIHRoYXQgYSBwcm9wb3NlZCBhbGdvcml0aG0gbXVzdCBzYXRpc2Z5LiZuYnNwOyBU aGluayBvZiB0aGlzIGFzIGEgc2V0IG9mIHJlZ3Jlc3Npb24gdGVzdHMgdGhhdCBpbnN1cmUgdGhh dCBhIHByb3Bvc2VkIGFsZ29yaXRobSBiZWhhdmVzIGFzIHdlIGV4cGVjdCwgYXMgd2VsbCBhcyBl bnN1cmluZyB0aGF0IGNoYW5nZXMgdG8gdGhhdCBhbGdvcml0aG0NCiBkbyBub3QgcmVzdWx0IGlu IHVuaW50ZW5kZWQgY29uc2VxdWVuY2VzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Mi4gQWdyZWVtZW50IG9uIGFsbCB0aGUg aW5wdXRzIHRoYXQgdGhlIGFsZ29yaXRobSB0YWtlcyBpbnRvIGFjY291bnQuJm5ic3A7IFRoaXMg aW5jbHVkZXMgZmllbGRzIHdpdGhpbiB0aGUgUlRQIHBhY2tldCAoZS5nLiBTU1JDLCBQVCwgUklE LCBNSUQsIGV0Yy4pIGFzIHdlbGwgYXMgbWV0aG9kcyB3aXRoaW4gdGhlIEFQSSAoZS5nLiBzZXRM b2NhbERlc2NyaXB0aW9uLCBzZXRSZW1vdGVEZXNjcmlwdGlvbiwgc2V0UGFyYW1ldGVycywNCiBl dGMuKS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPldpdGggcmVzcGVjdCB0byBJc3N1ZSAjMSwgc29tZSBvZiB0aGUgdHJpY2tp ZXN0IHVzZSBjYXNlcyBpbnZvbHZlIGJvdGggUFQgYW5kIFNTUkMgc2lnbmFsaW5nLCBTU1JDICZx dW90O2xhdGNoaW5nJnF1b3Q7IGFuZCBoYW5kbGluZyBGRUMgYW5kIFJUWC4mbmJzcDsgRXhhbXBs ZXMgaW5jbHVkZTombmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyBhLiBD aGFuZ2Ugb2YgU1NSQ3MgKGUuZy4gZHVlIHRvIGNvbmZsaWN0KS4mbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyBiLiBDb2RlYyBzd2l0Y2hpbmcgKGUuZy4gY2hhbmdpbmcg UFQgYnV0IHNhbWUgU1NSQywgb3IgY2hhbmdpbmcgYm90aCBQVCBhbmQgU1NSQykuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgYy4gVXNlIG9mIGJvdGggRkVDIGFuZCBSVFggKGFu ZCBwZXJoYXBzIFJUWCBvZiBGRUMpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SU1ITyBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gY29tZSB1 cCBhIGZldyAobGVzcyB0aGFuIGhhbGYgYSBkb3plbikgdXNlIGNhc2VzIHdpdGggYWdyZWVkLXVw b24gb3V0Y29tZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5XaXRoIHJlc3BlY3QgdG8gSXNzdWUgIzIsIHRoZSBwcm9wb3NlZCBhbGdv cml0aG1zIHNvIGZhciBsb29rIGF0IHRoZSBTU1JDICZhbXA7IFBUIGZpZWxkcyBpbiB0aGUgUlRQ IGhlYWRlciBhcyB3ZWxsIGFzIHRoZSBNSUQgUlRQIGV4dGVuc2lvbi4mbmJzcDsgSG93ZXZlciwg SSBoYXZlIG5vdCBzZWVuIGFsZ29yaXRobXMgd2hpY2ggdGFrZSBpbnRvIGFjY291bnQgdGhlIHJv bGUgb2YgdGhlIFJJRCBSVFAgZXh0ZW5zaW9uLiZuYnNwOyBTbyBhZ3JlZW1lbnQNCiBvbiB3aGV0 aGVyIHRoZSBSSUQgbmVlZHMgdG8gYmUgY29uc2lkZXJlZCBvciBub3Qgd291bGQgYmUgaGVscGZ1 bC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkFsc28sIGZvciBXZWJSVEMgMS4wIGl0IHdvdWxkIGFwcGVhciB0byBtZSB0aGF0 IHRoZSBhbGdvcml0aG0gd2lsbCBkZXBlbmQgb24gdGhlIGlucHV0cyB0byB0aGUgc2V0TG9jYWxE ZXNjcmlwdGlvbi9zZXRSZW1vdGVEZXNjcmlwdGlvbiBtZXRob2RzLCBzbyB0aGF0IHRoZXJlIGlz IGEgcG90ZW50aWFsIGRlcGVuZGVuY3kgb24gdGhlIHNpZ25hbGluZyBzdGF0ZSBvZiB0aGUgUGVl ckNvbm5lY3Rpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5PdmVyYWxsLCBJIGJlbGlldmUgdGhhdCB0aGUgZGlzY3Vzc2lvbiBvZiBS VFAgZGVtdXggYWxnb3JpdGhtcyBpcyBsaWtlbHkgdG8gZ28gbW9yZSBzbW9vdGhseSAoYW5kIGNv bmNsdWRlIG1vcmUgcXVpY2tseSkgaWYgd2UgZ2V0IGFncmVlbWVudCBvbiB0aGVzZSBtZXRhLWlz c3VlcyB1cGZyb250LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiBjbGFzcz0iIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWIiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnJ0 Y3dlYiBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIiBjbGFzcz0iIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_66CB8C7B56D14AC9B0F84F1689E2CA89vidyocom_-- From nobody Fri Sep 16 12:32:17 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF93112B1EE for ; Fri, 16 Sep 2016 12:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 VO8Ug58ae98n for ; Fri, 16 Sep 2016 12:32:14 -0700 (PDT) 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 24DCA12B2EE for ; Fri, 16 Sep 2016 12:32:07 -0700 (PDT) Received: from smtp18.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp18.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0863EA0199; Fri, 16 Sep 2016 15:32:04 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp18.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A4947A016C; Fri, 16 Sep 2016 15:32:03 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.17.99] ([UNAVAILABLE]. [128.107.241.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Fri, 16 Sep 2016 15:32:04 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D2D082DE-275F-4965-81F0-70071736C73E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> Date: Fri, 16 Sep 2016 12:32:02 -0700 Message-Id: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 19:32:16 -0000 --Apple-Mail=_D2D082DE-275F-4965-81F0-70071736C73E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agree with both of these. I think they are both the same as =E2=80=9CWhis= key & Soda Example=E2=80=9D - or am I missing something about theses?=20 > On Sep 16, 2016, at 11:59 AM, Jonathan Lennox = wrote: >=20 > I=E2=80=99m not going to come up with beverage names for my examples, = but feel free to make up your own. >=20 > 1. The PT are all the same. An RTCP source description for an SSRC = contains a MID. This latches the MID. Later, RTP packets with this = SSRC arrive without a MID. They go to the place matching the MID that = was in RTCP. >=20 > 2. The PT are all the same. A packet contains MID1. It goes to the = place that matches MID1, latching the SSRC to MID1. Later, a packet = with the same SSRC contains MID2. This moves the latching, so the SSRC = is now latched to MID2. > =20 >=20 >> On Sep 15, 2016, at 6:18 PM, Cullen Jennings > wrote: >>=20 >>=20 >> To propose a few use case=E2=80=A6. >>=20 >> =E2=80=9CWhiskey & Soda Example=E2=80=9D >> The PT are all the same. Early packets, and any packets after a SSRC = change, contain a MID. If the packet has MID, it goes to the place that = matches that MID *and* it latches that SSRC so any future SSRC that = don=E2=80=99t have a MID go the to the same place.=20 --Apple-Mail=_D2D082DE-275F-4965-81F0-70071736C73E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Agree with both of = these.  I think they are both the same as =E2=80=9CWhiskey & = Soda Example=E2=80=9D - or am I missing something about = theses? 

On Sep 16, 2016, at 11:59 AM, Jonathan = Lennox <jonathan@vidyo.com> wrote:

I=E2=80=99m not going to come up with beverage names for = my examples, but feel free to make up your own.

1. The PT are all the same.  An RTCP source = description for an SSRC contains a MID.  This latches the MID. =  Later, RTP packets with this SSRC arrive without a MID. They go to = the place matching the MID that was in RTCP.

2. The PT are all the same.  A packet contains = MID1.  It goes to the place that matches MID1, latching the SSRC to = MID1.  Later, a packet with the same SSRC contains MID2. This moves = the latching, so the SSRC is now latched to MID2.
 

On Sep 15, 2016, at 6:18 PM, Cullen Jennings <fluffy@iii.ca> = wrote:


To propose a few use case=E2=80=A6.

=E2=80=9CWhiskey & Soda Example=E2=80=9D
The PT are all the same. Early packets, and any packets = after a SSRC change, contain a MID. If the packet has  MID, it goes = to the place that matches that MID *and* it latches that SSRC so any = future SSRC that don=E2=80=99t have a MID go the to the same place. 

= --Apple-Mail=_D2D082DE-275F-4965-81F0-70071736C73E-- From nobody Fri Sep 16 12:33:32 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA8F12B2CE for ; Fri, 16 Sep 2016 12:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 ri7QkZUZFfEk for ; Fri, 16 Sep 2016 12:33:30 -0700 (PDT) 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 3BBF412B1EE for ; Fri, 16 Sep 2016 12:33:30 -0700 (PDT) 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 u8GJTbuM014652; Fri, 16 Sep 2016 15:33:29 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 25cb9jedbd-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Sep 2016 15:33:29 -0400 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; Fri, 16 Sep 2016 14:33:29 -0500 From: Jonathan Lennox To: Cullen Jennings Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSEEqiRc9bJSa2qkmm5GrI8oyLzKB8zCkAgAAJEgCAAABnAA== Date: Fri, 16 Sep 2016 19:33:28 +0000 Message-ID: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> In-Reply-To: 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: multipart/alternative; boundary="_000_A52D1EFE6A7D418FA77B176E184EBAB9vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-16_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609160246 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 19:33:31 -0000 --_000_A52D1EFE6A7D418FA77B176E184EBAB9vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCB0aGF0IFJUQ1AgY291bnRzIGZvciBsYXRjaGluZywgYW5kIHRoYXQgU1NSQ3PigJkgTUlE cyBjYW4gY2hhbmdlLg0KDQpBZ3JlZSB3aXRoIGJvdGggb2YgdGhlc2UuICBJIHRoaW5rIHRoZXkg YXJlIGJvdGggdGhlIHNhbWUgYXMg4oCcV2hpc2tleSAmIFNvZGEgRXhhbXBsZeKAnSAtIG9yIGFt IEkgbWlzc2luZyBzb21ldGhpbmcgYWJvdXQgdGhlc2VzPw0KDQpPbiBTZXAgMTYsIDIwMTYsIGF0 IDExOjU5IEFNLCBKb25hdGhhbiBMZW5ub3ggPGpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9u YXRoYW5AdmlkeW8uY29tPj4gd3JvdGU6DQoNCknigJltIG5vdCBnb2luZyB0byBjb21lIHVwIHdp dGggYmV2ZXJhZ2UgbmFtZXMgZm9yIG15IGV4YW1wbGVzLCBidXQgZmVlbCBmcmVlIHRvIG1ha2Ug dXAgeW91ciBvd24uDQoNCjEuIFRoZSBQVCBhcmUgYWxsIHRoZSBzYW1lLiAgQW4gUlRDUCBzb3Vy Y2UgZGVzY3JpcHRpb24gZm9yIGFuIFNTUkMgY29udGFpbnMgYSBNSUQuICBUaGlzIGxhdGNoZXMg dGhlIE1JRC4gIExhdGVyLCBSVFAgcGFja2V0cyB3aXRoIHRoaXMgU1NSQyBhcnJpdmUgd2l0aG91 dCBhIE1JRC4gVGhleSBnbyB0byB0aGUgcGxhY2UgbWF0Y2hpbmcgdGhlIE1JRCB0aGF0IHdhcyBp biBSVENQLg0KDQoyLiBUaGUgUFQgYXJlIGFsbCB0aGUgc2FtZS4gIEEgcGFja2V0IGNvbnRhaW5z IE1JRDEuICBJdCBnb2VzIHRvIHRoZSBwbGFjZSB0aGF0IG1hdGNoZXMgTUlEMSwgbGF0Y2hpbmcg dGhlIFNTUkMgdG8gTUlEMS4gIExhdGVyLCBhIHBhY2tldCB3aXRoIHRoZSBzYW1lIFNTUkMgY29u dGFpbnMgTUlEMi4gVGhpcyBtb3ZlcyB0aGUgbGF0Y2hpbmcsIHNvIHRoZSBTU1JDIGlzIG5vdyBs YXRjaGVkIHRvIE1JRDIuDQoNCg0KT24gU2VwIDE1LCAyMDE2LCBhdCA2OjE4IFBNLCBDdWxsZW4g SmVubmluZ3MgPGZsdWZmeUBpaWkuY2E8bWFpbHRvOmZsdWZmeUBpaWkuY2E+PiB3cm90ZToNCg0K DQpUbyBwcm9wb3NlIGEgZmV3IHVzZSBjYXNl4oCmLg0KDQrigJxXaGlza2V5ICYgU29kYSBFeGFt cGxl4oCdDQpUaGUgUFQgYXJlIGFsbCB0aGUgc2FtZS4gRWFybHkgcGFja2V0cywgYW5kIGFueSBw YWNrZXRzIGFmdGVyIGEgU1NSQyBjaGFuZ2UsIGNvbnRhaW4gYSBNSUQuIElmIHRoZSBwYWNrZXQg aGFzICBNSUQsIGl0IGdvZXMgdG8gdGhlIHBsYWNlIHRoYXQgbWF0Y2hlcyB0aGF0IE1JRCAqYW5k KiBpdCBsYXRjaGVzIHRoYXQgU1NSQyBzbyBhbnkgZnV0dXJlIFNTUkMgdGhhdCBkb27igJl0IGhh dmUgYSBNSUQgZ28gdGhlIHRvIHRoZSBzYW1lIHBsYWNlLg0KDQoNCg== --_000_A52D1EFE6A7D418FA77B176E184EBAB9vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj5KdXN0IHRoYXQgUlRDUCBj b3VudHMgZm9yIGxhdGNoaW5nLCBhbmQgdGhhdCBTU1JDc+KAmSBNSURzIGNhbiBjaGFuZ2UuPC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+DQpBZ3JlZSB3aXRoIGJvdGggb2YgdGhlc2UuICZuYnNwO0kgdGhpbmsg dGhleSBhcmUgYm90aCB0aGUgc2FtZSBhcyDigJxXaGlza2V5ICZhbXA7IFNvZGEgRXhhbXBsZeKA nSAtIG9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmcgYWJvdXQgdGhlc2VzPyZuYnNwOw0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFNlcCAxNiwgMjAxNiwgYXQgMTE6NTkg QU0sIEpvbmF0aGFuIExlbm5veCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNv bSIgY2xhc3M9IiI+am9uYXRoYW5AdmlkeW8uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPknigJltIG5vdCBnb2luZyB0byBjb21lIHVwIHdpdGggYmV2ZXJhZ2UgbmFtZXMgZm9y IG15IGV4YW1wbGVzLCBidXQgZmVlbCBmcmVlIHRvIG1ha2UgdXAgeW91ciBvd24uPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4xLiBUaGUg UFQgYXJlIGFsbCB0aGUgc2FtZS4gJm5ic3A7QW4gUlRDUCBzb3VyY2UgZGVzY3JpcHRpb24gZm9y IGFuIFNTUkMgY29udGFpbnMgYSBNSUQuICZuYnNwO1RoaXMgbGF0Y2hlcyB0aGUgTUlELiAmbmJz cDtMYXRlciwgUlRQIHBhY2tldHMgd2l0aCB0aGlzIFNTUkMgYXJyaXZlIHdpdGhvdXQgYSBNSUQu IFRoZXkgZ28gdG8gdGhlIHBsYWNlIG1hdGNoaW5nIHRoZSBNSUQgdGhhdCB3YXMgaW4gUlRDUC48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjIuIFRoZSBQVCBhcmUgYWxsIHRoZSBzYW1lLiAmbmJzcDtBIHBhY2tldCBjb250YWlucyBNSUQx LiAmbmJzcDtJdCBnb2VzIHRvIHRoZSBwbGFjZSB0aGF0IG1hdGNoZXMgTUlEMSwgbGF0Y2hpbmcg dGhlIFNTUkMgdG8gTUlEMS4gJm5ic3A7TGF0ZXIsIGEgcGFja2V0IHdpdGggdGhlIHNhbWUgU1NS QyBjb250YWlucyBNSUQyLiBUaGlzIG1vdmVzIHRoZSBsYXRjaGluZywgc28gdGhlIFNTUkMgaXMg bm93IGxhdGNoZWQgdG8gTUlEMi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFNlcCAxNSwgMjAxNiwgYXQgNjoxOCBQTSwgQ3VsbGVu IEplbm5pbmdzICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGlpaS5jYSIgY2xhc3M9IiI+Zmx1 ZmZ5QGlpaS5jYTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NClRvIHByb3Bvc2UgYSBmZXcgdXNlIGNhc2XigKYuDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJxXaGlza2V5ICZhbXA7IFNvZGEg RXhhbXBsZeKAnTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgUFQgYXJlIGFsbCB0aGUgc2FtZS4g RWFybHkgcGFja2V0cywgYW5kIGFueSBwYWNrZXRzIGFmdGVyIGEgU1NSQyBjaGFuZ2UsIGNvbnRh aW4gYSBNSUQuIElmIHRoZSBwYWNrZXQgaGFzICZuYnNwO01JRCwgaXQgZ29lcyB0byB0aGUgcGxh Y2UgdGhhdCBtYXRjaGVzIHRoYXQgTUlEICphbmQqIGl0IGxhdGNoZXMgdGhhdCBTU1JDIHNvIGFu eSBmdXR1cmUgU1NSQyB0aGF0IGRvbuKAmXQgaGF2ZSBhIE1JRCBnbyB0aGUgdG8gdGhlIHNhbWUN CiBwbGFjZS4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A52D1EFE6A7D418FA77B176E184EBAB9vidyocom_-- From nobody Tue Sep 20 11:23:05 2016 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 0DD5912B116; Tue, 20 Sep 2016 11:22:59 -0700 (PDT) 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.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147439577905.29097.16611752479251544159.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 11:22:59 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-16.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, 20 Sep 2016 18:22:59 -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-16.txt Pages : 92 Date : 2016-09-20 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-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-16 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 Sep 20 11:42:51 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E2212B449 for ; Tue, 20 Sep 2016 11:42:49 -0700 (PDT) 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 slvkp906286b for ; Tue, 20 Sep 2016 11:42:48 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 A07BB12B430 for ; Tue, 20 Sep 2016 11:42:47 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id r126so32867533oib.0 for ; Tue, 20 Sep 2016 11:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=mnB/apjTUtMOlTxy9wRpSpoPQ9CL+EG6HmAiIuPZGN0=; b=RUYjGMMM6ITadU4JLF356tUwSdeH9jfvCQ7hPOEN2iwYECrQVqGLkASxYCkUbbMA4b gTJvc/RJYE15VjwPKtri2v347eAlsuC8d7HbPoYHLNtB0OrY2PIWgb36pYABr64gmvr5 8FsHF0CXeBlj0+Ps0f+BhACvfzkSXertMhIPkSa/qoKdZBYa3O0VSbDyZ70c+hdJeciK RFF5ZNQ2xMneyw3+sFmF7mUm1uqYcUcmkCyG67wstnl4elL/eShQjXyR2zc6BGas1odY zFx4pKTa1G0brYTgfI9V3R2zNKyOVXNz6b203NCmXeEabKTjy+FpaC+I4ecHA5guPURw URVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mnB/apjTUtMOlTxy9wRpSpoPQ9CL+EG6HmAiIuPZGN0=; b=CIn4GrQVY57OUZmEeNxP82/mOmqK6M8DjAjKYajMU7qIqVR6Evg6zC1mJB3LTHcpCi iJNUrLR57UzTb3Z7X7H4itCfqjj35Wozgt59DWZfZ3rw75xJYms9PdeXCVBcf2TKO4HA jE8YwQ13Xhu5rNa9qfHM35sQ1K4fGlD7OSrc2CTkbJhUQ1Xl5nxs3AvzPkiIxdn/bs6b sMDk3kPgdFdPrKDaTkfcX7e+3AUkqUAScFQSU3haB1hy5EtBeSyWzofQn0tODbZZbdJY JwHETxw0DJ+ZnrRtSs2kTUYqDm9TzipfKQqH04uimIJSDwxZj7ZjZzp2CJxNVZrkH2Zg c9KA== X-Gm-Message-State: AE9vXwO9l0EixCoB8f7kIPdlMsIl5j/HUt8sA/Y/QsDKGG3nHt4gxmVQc1BS4SLBZfLyZ70HfejPOhEw3eScKA== X-Received: by 10.202.102.89 with SMTP id a86mr39430186oic.154.1474396966926; Tue, 20 Sep 2016 11:42:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.85.72 with HTTP; Tue, 20 Sep 2016 11:42:16 -0700 (PDT) From: Ted Hardie Date: Tue, 20 Sep 2016 11:42:16 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1140f74078c1f9053cf4cb3d Archived-At: Subject: [rtcweb] JSEP update 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, 20 Sep 2016 18:42:50 -0000 --001a1140f74078c1f9053cf4cb3d Content-Type: text/plain; charset=UTF-8 In case your id-actions are sent to a different folder, let me call your attention to the new version of JSEP. As usual, there is a diff available from the tools site: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-rtcweb-jsep-16.txt There are is a new sections on simulcast, and many, many updated passages. Please review as soon as possible. Though there are a very small number of todos left, we are getting close to a WGLC on this document; identifying issues now will help make sure they get addressed. thanks, Ted --001a1140f74078c1f9053cf4cb3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In case your id-actions are sent to a diffe= rent folder, let me call your attention to the new version of JSEP.=C2=A0 A= s usual, there is a diff available from the tools site:

https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url= 2=3Ddraft-ietf-rtcweb-jsep-16.txt

There are is a new secti= ons on simulcast, and many, many updated passages.=C2=A0 Please review as s= oon as possible.=C2=A0 Though there are a very small number of todos left, = we are getting close to a WGLC on this document; identifying issues now wil= l help make sure they get addressed.

thanks,

Ted<= br>
--001a1140f74078c1f9053cf4cb3d-- From nobody Fri Sep 23 01:57:29 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3373A12D74D for ; Fri, 23 Sep 2016 01:57:27 -0700 (PDT) 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 6fSX6eVjobP7 for ; Fri, 23 Sep 2016 01:57:24 -0700 (PDT) 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 2FA2C12D799 for ; Fri, 23 Sep 2016 01:57:23 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-b2-57e4ee72373a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 45.2A.03250.27EE4E75; Fri, 23 Sep 2016 10:57:22 +0200 (CEST) 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.301.0; Fri, 23 Sep 2016 10:56:39 +0200 To: Jonathan Lennox , Cullen Jennings References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> From: Magnus Westerlund Message-ID: <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> Date: Fri, 23 Sep 2016 10:56:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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+NgFtrDLMWRmVeSWpSXmKPExsUyM2K7k27RuyfhBg+uiVl8WP+D0WL/4vPM Fmv/tbM7MHssWfKTyePy+Y+MHm3P7rAHMEdx2aSk5mSWpRbp2yVwZZx6u4i14KxMxdrn01kb GC+IdTFyckgImEh8abjB2sXIxSEksJ5R4tyf8ywQznJGiTdHVrOBVAkLGEgsbPvKDmKLCHhK XLi0ihXEFhKYxiRxZmINiM0soC5xZ/E5sBo2AQuJmz8awXp5Bewlfh7+CFbPIqAqceHFSqA4 B4eoQIzE+r4EiBJBiZMzn7CA2JwCthJ3ri5hAilhBmp9sLUMYrq8RPPW2cwQW7UlGpo6WCcw CsxC0j0LoWMWko4FjMyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQLD9OCW3wY7GF8+dzzE KMDBqMTD++Dx43Ah1sSy4srcQ4wSHMxKIrz/Xz0JF+JNSaysSi3Kjy8qzUktPsQozcGiJM5r tvJ+uJBAemJJanZqakFqEUyWiYNTqoFR6lkqC5PKQq0nX72mXr3+bGXislXL3cTmLpkzS3Xl icwSbe/P/QW2GU8ffer1vMdZejfXo20ig97cU7GflLQleLvMDR5+LjOTe+mxffGFAp5lAa9f yuskmgRyuytNWHBcsXKC2R2BuB83lyVZf7Zpjf608bn6jKk134NSPt1aZVaiZf+h8NwvJZbi jERDLeai4kQAvN2JNk8CAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 23 Sep 2016 08:57:27 -0000 Hi, I think the use cases looks fairly covering. I want to add an alternative way of thinking on how the SDES item (MID, RID) related demultiplexing part is handled. So the RID and MID in RTP header extensions or in RTSP SDES packets results in these values being bound to the SSRC until further notice. So packets arriving without actual RTP header extensions can still be handled according to the SSRCs associated SDES items. From my perspective all the cases with MID and RID can be handled on a per packet basis rules without latching the SSRC to a specific receiver. Instead what is "latched" is the SDES values to the SSRC. Still at the point of change there needs to take the combination of SSRC and Seq into account to avoid miss routing packets. So my general handling algorithm would be this sequence: 1. Check if RTP header extensions update any SDES item for the SSRC. a. If they do, mark the Sequence number and keep the old SDES item as valid prior to this extended sequence number. 2. Determine the set of relevant SDES items that applies for this packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and RID. 3. Perform the demuxing algorithm On another part, I find Jonathan's use case for setting the MID or RID using RTCP an interesting one. This put some light on the question that in a session where MID and RIDs are configured, if one receive packets with an SSRC that lacks these SDES items, what do you do, buffer or discard? Cheers Magnus Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox: > Just that RTCP counts for latching, and that SSRCs’ MIDs can change. > >> Agree with both of these. I think they are both the same as “Whiskey >> & Soda Example” - or am I missing something about theses? >> >>> On Sep 16, 2016, at 11:59 AM, Jonathan Lennox >> > wrote: >>> >>> I’m not going to come up with beverage names for my examples, but >>> feel free to make up your own. >>> >>> 1. The PT are all the same. An RTCP source description for an SSRC >>> contains a MID. This latches the MID. Later, RTP packets with this >>> SSRC arrive without a MID. They go to the place matching the MID that >>> was in RTCP. >>> >>> 2. The PT are all the same. A packet contains MID1. It goes to the >>> place that matches MID1, latching the SSRC to MID1. Later, a packet >>> with the same SSRC contains MID2. This moves the latching, so the >>> SSRC is now latched to MID2. >>> >>> >>>> On Sep 15, 2016, at 6:18 PM, Cullen Jennings >>> > wrote: >>>> >>>> >>>> To propose a few use case…. >>>> >>>> “Whiskey & Soda Example” >>>> The PT are all the same. Early packets, and any packets after a SSRC >>>> change, contain a MID. If the packet has MID, it goes to the place >>>> that matches that MID *and* it latches that SSRC so any future SSRC >>>> that don’t have a MID go the to the same place. >> > > > > _______________________________________________ > 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 Fri Sep 23 02:03:11 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ED112B041 for ; Fri, 23 Sep 2016 02:03:09 -0700 (PDT) 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 Gs7edPPF48uX for ; Fri, 23 Sep 2016 02:03:05 -0700 (PDT) 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 1231B12B3DC for ; Fri, 23 Sep 2016 02:03:04 -0700 (PDT) X-AuditID: c1b4fb2d-1dbff700000009f7-05-57e4efc676dc Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 21.54.02551.6CFE4E75; Fri, 23 Sep 2016 11:03:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Fri, 23 Sep 2016 11:03:02 +0200 From: Christer Holmberg To: Magnus Westerlund , Jonathan Lennox , Cullen Jennings Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSDrBduC6LB65/lE2Mthgf5jiIWqB6/zGAgAFa1ACAAAkSAIAAAGcAgApOYwCAADWtAA== Date: Fri, 23 Sep 2016 09:03:01 +0000 Message-ID: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> In-Reply-To: <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="Windows-1252" Content-ID: <679F8A4B9BE8C142A4C63EACEC918464@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7q+7x90/CDX49krP4sP4Ho8X+xeeZ Ldb+a2d3YPZYsuQnk8fl8x8ZPdqe3WEPYI7isklJzcksSy3St0vgylj1vYm1oEuxomHrI+YG xtNSXYycHBICJhJtOx6xdDFycQgJrGeUWDmpiRXCWcwocfzkXqYuRg4ONgELie5/2iANIgL1 Em+3TGAEsZkF1CXuLD7HDmILCxhILGz7yg5SLiJgKNHVJw9RHiYxeWc/M0iYRUBV4vjPOpAw r4CVxOMJb5ggNp1hkpjUsJwVJMEp4CAx5/MnFhCbUUBM4vupNUwQq8Qlbj2ZzwRxs4DEkj3n mSFsUYmXj/+B9YoK6El8/zobKq4k8WPDJRaIXgOJ9+fmM0PY1hK97StYIWxtiWULXzNDHCQo cXLmE5YJjOKzkKybhaR9FpL2WUjaZyFpX8DIuopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMj MAIPbvmtu4Nx9WvHQ4wCHIxKPLwPHj8OF2JNLCuuzD3EKMHBrCTC+//Vk3Ah3pTEyqrUovz4 otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGFe952XYv7LDcbXT3T57W4fl ZuKbv24VXyk2l+mBcqGGrKde1o32AovH50xvLZ/cdMDge+WslKWLebnSD891LU/XEzi9qMvs 4cfghSp1/om3s/fE2c1xOBZkltiUl3ng2vzNn/9F3FxsWRxoGjr1r/4D/ufpZjwKDdwLOJPm hs3X+vbD+N3zDiWW4oxEQy3mouJEALpDFCe8AgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 23 Sep 2016 09:03:09 -0000 Hi, If we define the RTP mux procedures in BUNDLE, do we need to define the RTP demux algorithms in JSEP to begin with? Is there something JSEP specific? Regards, Christer On 23/09/16 11:56, "rtcweb on behalf of Magnus Westerlund" wrote: >Hi, > >I think the use cases looks fairly covering. > >I want to add an alternative way of thinking on how the SDES item (MID, >RID) related demultiplexing part is handled. So the RID and MID in RTP >header extensions or in RTSP SDES packets results in these values being >bound to the SSRC until further notice. So packets arriving without >actual RTP header extensions can still be handled according to the SSRCs >associated SDES items. From my perspective all the cases with MID and >RID can be handled on a per packet basis rules without latching the SSRC >to a specific receiver. Instead what is "latched" is the SDES values to >the SSRC. Still at the point of change there needs to take the >combination of SSRC and Seq into account to avoid miss routing packets. > >So my general handling algorithm would be this sequence: > >1. Check if RTP header extensions update any SDES item for the SSRC. > a. If they do, mark the Sequence number and keep the old SDES item >as valid prior to this extended sequence number. > >2. Determine the set of relevant SDES items that applies for this >packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and >RID. > >3. Perform the demuxing algorithm > > >On another part, I find Jonathan's use case for setting the MID or RID >using RTCP an interesting one. This put some light on the question that >in a session where MID and RIDs are configured, if one receive packets >with an SSRC that lacks these SDES items, what do you do, buffer or >discard? > >Cheers > >Magnus > >Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox: >> Just that RTCP counts for latching, and that SSRCs=B9 MIDs can change. >> >>> Agree with both of these. I think they are both the same as =B3Whiskey >>> & Soda Example=B2 - or am I missing something about theses? >>> >>>> On Sep 16, 2016, at 11:59 AM, Jonathan Lennox >>> > wrote: >>>> >>>> I=B9m not going to come up with beverage names for my examples, but >>>> feel free to make up your own. >>>> >>>> 1. The PT are all the same. An RTCP source description for an SSRC >>>> contains a MID. This latches the MID. Later, RTP packets with this >>>> SSRC arrive without a MID. They go to the place matching the MID that >>>> was in RTCP. >>>> >>>> 2. The PT are all the same. A packet contains MID1. It goes to the >>>> place that matches MID1, latching the SSRC to MID1. Later, a packet >>>> with the same SSRC contains MID2. This moves the latching, so the >>>> SSRC is now latched to MID2. >>>> >>>> >>>>> On Sep 15, 2016, at 6:18 PM, Cullen Jennings >>>> > wrote: >>>>> >>>>> >>>>> To propose a few use case=8A. >>>>> >>>>> =B3Whiskey & Soda Example=B2 >>>>> The PT are all the same. Early packets, and any packets after a SSRC >>>>> change, contain a MID. If the packet has MID, it goes to the place >>>>> that matches that MID *and* it latches that SSRC so any future SSRC >>>>> that don=B9t have a MID go the to the same place. >>> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > >--=20 > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Sep 23 02:11:18 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7842E12B7C9 for ; Fri, 23 Sep 2016 02:11:17 -0700 (PDT) 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 57NnCQUsPfnJ for ; Fri, 23 Sep 2016 02:11:15 -0700 (PDT) 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 2D96512B71F for ; Fri, 23 Sep 2016 02:11:15 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-fc-57e4f1b1fd74 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 00.61.31035.1B1F4E75; Fri, 23 Sep 2016 11:11:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.301.0; Fri, 23 Sep 2016 11:10:55 +0200 To: Christer Holmberg , Jonathan Lennox , Cullen Jennings References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> From: Magnus Westerlund Message-ID: <679543be-e619-48f4-6f2e-1eda900d9e73@ericsson.com> Date: Fri, 23 Sep 2016 11:10:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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+NgFtrJLMWRmVeSWpSXmKPExsUyM2J7iO7Gj0/CDeavkrT4sP4Ho8X+xeeZ Ldb+a2d3YPZYsuQnk8fl8x8ZPdqe3WEPYI7isklJzcksSy3St0vgyjh2TbFgm27F4yf3mRoY l6h0MXJySAiYSBx9eoQRxBYSWM8ocft/CoS9nFHi5XJTEFtYwEBiYdtXdhBbRKBe4szWK1D1 f5kk3t8JA7GZBdQl7iw+B1bDJmAhcfNHIxuIzStgL7Hz8zswm0VAVWLSt+tANRwcogIxEuv7 EiBKBCVOznzCAmJzClhLLH7XxQJSwgzU+mBrGcR0eYnmrbOZIbZqSzQ0dbBOYBSYhaR7FkLH LCQdCxiZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEBujBLb9VdzBefuN4iFGAg1GJh/fB 48fhQqyJZcWVuYcYJTiYlUR4/796Ei7Em5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTE ktTs1NSC1CKYLBMHp1QDo55V/Y3gtzNqWdO5y0OOBv5n70t/3Lta7Kv+/Baf23O9FDwtgyx/ cbTK8m6dcWm/9VS2g/FOLsXGkc0HFmc8mfPGbqOI34Gj4SohQoFLBK6bdzDZ3JzjO/twyGpr Y6uyXqW5a1QmPpoeEaKtt3pW/fH3f+SXBJ+ysD/1tHfbH95rD9fMXGZlo8RSnJFoqMVcVJwI ACER+SlMAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 23 Sep 2016 09:11:17 -0000 Den 2016-09-23 kl. 11:03, skrev Christer Holmberg: > > Hi, > > If we define the RTP mux procedures in BUNDLE, do we need to define the > RTP demux algorithms in JSEP to begin with? I think BUNDLE can take care of the BUNDLE level stuff. Then we come to the next level which is Simulcast and RID usage. Here I think it is obvious that the Simulcast needs more discussion of the RTP issues. In Berlin we had a discussion on what behaviours a RTP receiver can expect to see from a middlebox selecting from simulcast streams. Those details needs to be written up, and that include if RID should be maintained in the RTP stream between the last RTP middlebox and the receiving client. > > Is there something JSEP specific? I am not certain but I don't want to answer this question yet. Not until we actually written up the BUNDLE part and the Simulcast one. Then still remains the question if there are legacy or combination considerations that is not well enough handled. But, I think we should try to push as much of this as far down into the source specs as possible. /Magnus > > Regards, > > Christer > > > > On 23/09/16 11:56, "rtcweb on behalf of Magnus Westerlund" > > wrote: > >> Hi, >> >> I think the use cases looks fairly covering. >> >> I want to add an alternative way of thinking on how the SDES item (MID, >> RID) related demultiplexing part is handled. So the RID and MID in RTP >> header extensions or in RTSP SDES packets results in these values being >> bound to the SSRC until further notice. So packets arriving without >> actual RTP header extensions can still be handled according to the SSRCs >> associated SDES items. From my perspective all the cases with MID and >> RID can be handled on a per packet basis rules without latching the SSRC >> to a specific receiver. Instead what is "latched" is the SDES values to >> the SSRC. Still at the point of change there needs to take the >> combination of SSRC and Seq into account to avoid miss routing packets. >> >> So my general handling algorithm would be this sequence: >> >> 1. Check if RTP header extensions update any SDES item for the SSRC. >> a. If they do, mark the Sequence number and keep the old SDES item >> as valid prior to this extended sequence number. >> >> 2. Determine the set of relevant SDES items that applies for this >> packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and >> RID. >> >> 3. Perform the demuxing algorithm >> >> >> On another part, I find Jonathan's use case for setting the MID or RID >> using RTCP an interesting one. This put some light on the question that >> in a session where MID and RIDs are configured, if one receive packets >> with an SSRC that lacks these SDES items, what do you do, buffer or >> discard? >> >> Cheers >> >> Magnus >> >> Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox: >>> Just that RTCP counts for latching, and that SSRCs¹ MIDs can change. >>> >>>> Agree with both of these. I think they are both the same as ³Whiskey >>>> & Soda Example² - or am I missing something about theses? >>>> >>>>> On Sep 16, 2016, at 11:59 AM, Jonathan Lennox >>>> > wrote: >>>>> >>>>> I¹m not going to come up with beverage names for my examples, but >>>>> feel free to make up your own. >>>>> >>>>> 1. The PT are all the same. An RTCP source description for an SSRC >>>>> contains a MID. This latches the MID. Later, RTP packets with this >>>>> SSRC arrive without a MID. They go to the place matching the MID that >>>>> was in RTCP. >>>>> >>>>> 2. The PT are all the same. A packet contains MID1. It goes to the >>>>> place that matches MID1, latching the SSRC to MID1. Later, a packet >>>>> with the same SSRC contains MID2. This moves the latching, so the >>>>> SSRC is now latched to MID2. >>>>> >>>>> >>>>>> On Sep 15, 2016, at 6:18 PM, Cullen Jennings >>>>> > wrote: >>>>>> >>>>>> >>>>>> To propose a few use caseŠ. >>>>>> >>>>>> ³Whiskey & Soda Example² >>>>>> The PT are all the same. Early packets, and any packets after a SSRC >>>>>> change, contain a MID. If the packet has MID, it goes to the place >>>>>> that matches that MID *and* it latches that SSRC so any future SSRC >>>>>> that don¹t have a MID go the to the same place. >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> 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 Fri Sep 23 02:13:10 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E744212B1D7 for ; Fri, 23 Sep 2016 02:13:08 -0700 (PDT) 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 e34l8nB7LfJv for ; Fri, 23 Sep 2016 02:13:06 -0700 (PDT) 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 165B512B746 for ; Fri, 23 Sep 2016 02:13:06 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 15so30503209uai.3 for ; Fri, 23 Sep 2016 02:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qckelqtrgf3wa/SL95uNLQNAKPpk/BDlQSzWDRRgbBM=; b=DqVHyaF1Rp+UHvF3YXr/hNqrFXYUdZeMa6Kb/qVN8WxaO4Jk7iRK19CQJSnTf2V6uq pXkJ4eH6KID8ZPJuw5erAtidGY4CtJO7uSiCgrTn/TS2PVextBurzw60k6bK4Erk4rzY Pz/vDFZbAxqdeTUO4kYePcYQtsAHtLdB0OooPelNR+pLAI6fX69K+BkdlRvEG+t1XsyX ZVEgmMQ6C+GK2yT7EN3wzxTI4UxFfNXb6Pukfsxzra96d9Ujux1UAjApegTDjW2WNQOW GoGtL7keAQ0nknouA3JjwQh5eIwKv/dnmaYsQ7/eBN4kYXafRQT756hqXaOYKMvY+lBr X/OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qckelqtrgf3wa/SL95uNLQNAKPpk/BDlQSzWDRRgbBM=; b=AgVXagUBEJpSjfS/ebIpS7BT/tXl1ZvEye02P5Lsovan6L71X+s6jP1cw8lUTxWatu hQ5je3fJIs/lXXIAPdtwrVVBG+FpiOSikQ0Gm/qMPUasju8jLV9FlDLNBWqPxMF8ftBN korf5EBfTlPPIU4xURdxvdUM7RiuwMbC+ZSrYPJOBYLqhubpQVUS3Z3x3xJpa/bqjceg 87/UftrNp5SBlPElIeR3EDB1YX5li0mJmygXkVPMck+gA2drUQt1c7jV8yqq8q7EIDBV Hgr84TBP0bjmAqnUCqbMDm2GHB/mznG/5yDRSePVlHiFxT1Q5Ay6m405qlC3xEXWWLKv L/ew== X-Gm-Message-State: AA6/9Rn9ykR3UEvQph3/FshcF9GB6JP0EhFk5bSsAyTwS5DKCr+GUQBIO9iP1ismtZLSfNU1do1ujiElBxYXQA== X-Received: by 10.159.38.117 with SMTP id 108mr3643193uag.169.1474621984941; Fri, 23 Sep 2016 02:13:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.198 with HTTP; Fri, 23 Sep 2016 02:12:44 -0700 (PDT) In-Reply-To: <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> From: Bernard Aboba Date: Fri, 23 Sep 2016 10:12:44 +0100 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a113cf902972d5c053d292f2e Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 23 Sep 2016 09:13:09 -0000 --001a113cf902972d5c053d292f2e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Magnus said: " in a session where MID and RIDs are configured, if one receive packets with an SSRC that lacks these SDES items, what do you do, buffer or discard= ? " [BA] Assuming that the SSRC does not match any signaled SSRC (nor any PT), then in WebRTC 1.0, the packet would be discarded. In ORTC, there is a moderate buffer along with an unhandledrtp event. On Fri, Sep 23, 2016 at 9:56 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I think the use cases looks fairly covering. > > I want to add an alternative way of thinking on how the SDES item (MID, > RID) related demultiplexing part is handled. So the RID and MID in RTP > header extensions or in RTSP SDES packets results in these values being > bound to the SSRC until further notice. So packets arriving without actua= l > RTP header extensions can still be handled according to the SSRCs > associated SDES items. From my perspective all the cases with MID and RID > can be handled on a per packet basis rules without latching the SSRC to a > specific receiver. Instead what is "latched" is the SDES values to the > SSRC. Still at the point of change there needs to take the combination of > SSRC and Seq into account to avoid miss routing packets. > > So my general handling algorithm would be this sequence: > > 1. Check if RTP header extensions update any SDES item for the SSRC. > a. If they do, mark the Sequence number and keep the old SDES item as > valid prior to this extended sequence number. > > 2. Determine the set of relevant SDES items that applies for this packet, > i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and RID. > > 3. Perform the demuxing algorithm > > > On another part, I find Jonathan's use case for setting the MID or RID > using RTCP an interesting one. This put some light on the question that i= n > a session where MID and RIDs are configured, if one receive packets with = an > SSRC that lacks these SDES items, what do you do, buffer or discard? > > Cheers > > Magnus > > Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox: > >> Just that RTCP counts for latching, and that SSRCs=E2=80=99 MIDs can cha= nge. >> >> Agree with both of these. I think they are both the same as =E2=80=9CWh= iskey >>> & Soda Example=E2=80=9D - or am I missing something about theses? >>> >>> On Sep 16, 2016, at 11:59 AM, Jonathan Lennox >>> > wrote: >>>> >>>> I=E2=80=99m not going to come up with beverage names for my examples, = but >>>> feel free to make up your own. >>>> >>>> 1. The PT are all the same. An RTCP source description for an SSRC >>>> contains a MID. This latches the MID. Later, RTP packets with this >>>> SSRC arrive without a MID. They go to the place matching the MID that >>>> was in RTCP. >>>> >>>> 2. The PT are all the same. A packet contains MID1. It goes to the >>>> place that matches MID1, latching the SSRC to MID1. Later, a packet >>>> with the same SSRC contains MID2. This moves the latching, so the >>>> SSRC is now latched to MID2. >>>> >>>> >>>> On Sep 15, 2016, at 6:18 PM, Cullen Jennings >>>> > wrote: >>>>> >>>>> >>>>> To propose a few use case=E2=80=A6. >>>>> >>>>> =E2=80=9CWhiskey & Soda Example=E2=80=9D >>>>> The PT are all the same. Early packets, and any packets after a SSRC >>>>> change, contain a MID. If the packet has MID, it goes to the place >>>>> that matches that MID *and* it latches that SSRC so any future SSRC >>>>> that don=E2=80=99t have a MID go the to the same place. >>>>> >>>> >>> >> >> >> _______________________________________________ >> 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 > ---------------------------------------------------------------------- > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113cf902972d5c053d292f2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Magnus said:=C2=A0

"=C2=A0in a sessi= on where MID and RIDs are configured, if one receive packets with an SSRC t= hat lacks these SDES items, what do you do, buffer or discard?
=
"

[BA] Assuming that the SSRC does not m= atch any signaled SSRC (nor any PT), then in WebRTC 1.0, the packet would b= e discarded.=C2=A0 In ORTC, there is a moderate buffer along with an unhand= ledrtp event.

On Fri, Sep 23, 2016 at 9:56 AM, Magnus Westerlund <m= agnus.westerlund@ericsson.com> wrote:
Hi,

I think the use cases looks fairly covering.

I want to add an alternative way of thinking on how the SDES item (MID, RID= ) related demultiplexing part is handled. So the RID and MID in RTP header = extensions or in RTSP SDES packets results in these values being bound to t= he SSRC until further notice. So packets arriving without actual RTP header= extensions can still be handled according to the SSRCs associated SDES ite= ms. From my perspective all the cases with MID and RID can be handled on a = per packet basis rules without latching the SSRC to a specific receiver. In= stead what is "latched" is the SDES values to the SSRC. Still at = the point of change there needs to take the combination of SSRC and Seq int= o account to avoid miss routing packets.

So my general handling algorithm would be this sequence:

1. Check if RTP header extensions update any SDES item for the SSRC.
=C2=A0 =C2=A0a. If they do, mark the Sequence number and keep the old SDES = item as valid prior to this extended sequence number.

2. Determine the set of relevant SDES items that applies for this packet, i= .e. use SSRC + RTP seq to look up the SDES items, e.g. MID and RID.

3. Perform the demuxing algorithm


On another part, I find Jonathan's use case for setting the MID or RID = using RTCP an interesting one. This put some light on the question that in = a session where MID and RIDs are configured, if one receive packets with an= SSRC that lacks these SDES items, what do you do, buffer or discard?

Cheers

Magnus

Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox:
Just that RTCP counts for latching, and that SSRCs=E2=80=99 MIDs can change= .

Agree with both of these.=C2=A0 I think they are both the same as =E2=80=9C= Whiskey
& Soda Example=E2=80=9D - or am I missing something about theses?

On Sep 16, 2016, at 11:59 AM, Jonathan Lennox <jonathan@vidyo.com
 <mailto:jonathan= @vidyo.com>> wrote:

I=E2=80=99m not going to come up with beverage names for my examples, but feel free to make up your own.

1. The PT are all the same.=C2=A0 An RTCP source description for an SSRC contains a MID.=C2=A0 This latches the MID.=C2=A0 Later, RTP packets with t= his
SSRC arrive without a MID. They go to the place matching the MID that
was in RTCP.

2. The PT are all the same.=C2=A0 A packet contains MID1.=C2=A0 It goes to = the
place that matches MID1, latching the SSRC to MID1.=C2=A0 Later, a packet with the same SSRC contains MID2. This moves the latching, so the
SSRC is now latched to MID2.


On Sep 15, 2016, at 6:18 PM, Cullen Jennings <fluffy@iii.ca
 <mailto:fluffy@iii.ca= >> wrote:


To propose a few use case=E2=80=A6.

=E2=80=9CWhiskey & Soda Example=E2=80=9D
The PT are all the same. Early packets, and any packets after a SSRC
change, contain a MID. If the packet has=C2=A0 MID, it goes to the place that matches that MID *and* it latches that SSRC so any future SSRC
that don=E2=80=99t have a MID go the to the same place.




_______________________________________________
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
-----------------------------------------------------------------= -----


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

--001a113cf902972d5c053d292f2e-- From nobody Fri Sep 23 02:28:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A6D12C05C for ; Fri, 23 Sep 2016 02:28:28 -0700 (PDT) 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 hVD_VoQJsYy1 for ; Fri, 23 Sep 2016 02:28:21 -0700 (PDT) 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 8630212B281 for ; Fri, 23 Sep 2016 02:28:21 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id u68so31175406uau.0 for ; Fri, 23 Sep 2016 02:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9JnJdgSkKaELOnFKvO2nP9yFWWJKANHqbQbi2VOmAzo=; b=mQ/FKcyqn7BtVDTV8oIbxQOiONp6dDXQNr63Ci5zqmJwZjJ10udssGl1bylwHN5TvN 43iN/nofcWerf2apFkVYCmjH0SGKOOLNU6oQDp0njskc+ZkLxWIONtHRJHRA1EBLJJUl BbbygjcsPmnYQvICNwrh47TQQ1B4a5Is6tMTYdo7j6+q5Ln1HBzhJ+pXCN4F56WYgoIx VweAO3QYA1wH9ofp5ksd5UdJpn5jOOCDXozYWnGoILOOdJ0oybIC62zHmv+i6VY1GlPZ l3a81zU2togS+O1xMR1uYkQ9qGtpkL82KkzYo7Fzg2JZz5vBB/W020Tw87Hx2GWSKPwd X/5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9JnJdgSkKaELOnFKvO2nP9yFWWJKANHqbQbi2VOmAzo=; b=YfL7IKvdbyj2LvSG+Saj62Oc5zMCVJuhI6f2DqIWP5nSi7GpMAJEDFS0P29uq+9yX0 swBf3J2U4VR/tx/TC8EKuSrabLDjPXZlEdWyv4EEEY6omA4pM/eZhmtWjBCjXwZUPNCS q5d26Ob3ShLQonJMm9P+7fqfzPRape8aIm2ihFE0KWF/+PFG7O90+J8C3A+OA4P09b7D 1QUzYjo/rTHDaQQA/oM9VBHKuhXEW/UIJUx6f23+vumhJdXi1AJVlm5wvlm388OJ2MPr e0PDljjKgBORwbSktdiJDavzrYhzxmDua9qyoQ4pjffYFdUhJUqk+daxCtCjfod8A3MB ERjg== X-Gm-Message-State: AE9vXwOlURo2jRVXYoOQJzLmeXfVWRuWYcBtGjBbwIwITXP6X9c63ZzDrU64yQjxSt8gra+VVyX4t5p2/V8/WA== X-Received: by 10.176.6.170 with SMTP id g39mr2862522uag.72.1474622900640; Fri, 23 Sep 2016 02:28:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.198 with HTTP; Fri, 23 Sep 2016 02:28:00 -0700 (PDT) In-Reply-To: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> From: Bernard Aboba Date: Fri, 23 Sep 2016 10:28:00 +0100 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c0458a82ba157053d296688 Archived-At: Cc: "rtcweb@ietf.org" , Jonathan Lennox Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 23 Sep 2016 09:28:28 -0000 --94eb2c0458a82ba157053d296688 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer said: "If we define the RTP mux procedures in BUNDLE, do we need to define the RTP demux algorithms in JSEP to begin with?" [BA] I'd suggest that BUNDLE needs to lay out principles for RTP mux procedures, but it does not need to get into the details (which can be left to JSEP). In particular, some of the most difficult use cases involve situations in which the PTs are not unique. IMHO, BUNDLE Section 10.2 does not provide clear guidelines for how implementations should behave (and as a result BUNDLE implementations currently are inconsistent in their behavior). Some comments on Section 10.2 below: As described in [Section 10.1.1], the same payload type value might be used inside RTP packets described by multiple "m=3D" lines. In such cases, the payload type value cannot be used to associate received RTP packets with the correct "m=3D" line. An offerer and answerer can inform each other which SSRC values they will use for RTP and RTCP by using the SDP 'ssrc' attribute [RFC5576]. To allow for proper association with this mechanism, the 'ssrc' attribute needs to be associated with each "m=3D" line that shares a payload type with any other "m=3D" line in the same bundle. As the SSRC values will be carried inside the RTP/RTCP packets, the offerer and answerer can then use that information to associate received RTP packets with the correct "m=3D" line. However, an offerer will not know which SSRC values the answerer will use until it 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 received RTP/RTCP packets with the correct "m=3D" line using the SSRC values. [BA] One area of confusion relates to the meaning of the SSRCs provided in the Answer when PTs are not unique. Is the implication that the SSRCs in the Answer (and ONLY those SSRCs) will match the m-line? In order for an offerer and answerer to always be able to associate received RTP and RTCP packets with the correct "m=3D" line, an offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 14, where the remote endpoint inserts the identification-tag associated with an "m=3D" line in RTP and RTCP packets associated with that "m=3D" line. [BA] Is this only MUST support, or MUST use? If MIDs might not be used in a situation where PTs are not unique, then this section needs to describe what happens if there is no SSRC match. Do RTP packets get routed to the first m-line with a matching PT? Can a PT-match only occur when there are no SSRCs specified (either for codecs or for RTX/FEC)? So far, I have seen at least 3 BUNDLE implementations with different interpretations of this section. On Fri, Sep 23, 2016 at 10:03 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > If we define the RTP mux procedures in BUNDLE, do we need to define the > RTP demux algorithms in JSEP to begin with? > > Is there something JSEP specific? > > Regards, > > Christer > > > > On 23/09/16 11:56, "rtcweb on behalf of Magnus Westerlund" > > wrote: > > >Hi, > > > >I think the use cases looks fairly covering. > > > >I want to add an alternative way of thinking on how the SDES item (MID, > >RID) related demultiplexing part is handled. So the RID and MID in RTP > >header extensions or in RTSP SDES packets results in these values being > >bound to the SSRC until further notice. So packets arriving without > >actual RTP header extensions can still be handled according to the SSRCs > >associated SDES items. From my perspective all the cases with MID and > >RID can be handled on a per packet basis rules without latching the SSRC > >to a specific receiver. Instead what is "latched" is the SDES values to > >the SSRC. Still at the point of change there needs to take the > >combination of SSRC and Seq into account to avoid miss routing packets. > > > >So my general handling algorithm would be this sequence: > > > >1. Check if RTP header extensions update any SDES item for the SSRC. > > a. If they do, mark the Sequence number and keep the old SDES item > >as valid prior to this extended sequence number. > > > >2. Determine the set of relevant SDES items that applies for this > >packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and > >RID. > > > >3. Perform the demuxing algorithm > > > > > >On another part, I find Jonathan's use case for setting the MID or RID > >using RTCP an interesting one. This put some light on the question that > >in a session where MID and RIDs are configured, if one receive packets > >with an SSRC that lacks these SDES items, what do you do, buffer or > >discard? > > > >Cheers > > > >Magnus > > > >Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox: > >> Just that RTCP counts for latching, and that SSRCs=C2=B9 MIDs can chan= ge. > >> > >>> Agree with both of these. I think they are both the same as =C2=B3Wh= iskey > >>> & Soda Example=C2=B2 - or am I missing something about theses? > >>> > >>>> On Sep 16, 2016, at 11:59 AM, Jonathan Lennox >>>> > wrote: > >>>> > >>>> I=C2=B9m not going to come up with beverage names for my examples, b= ut > >>>> feel free to make up your own. > >>>> > >>>> 1. The PT are all the same. An RTCP source description for an SSRC > >>>> contains a MID. This latches the MID. Later, RTP packets with this > >>>> SSRC arrive without a MID. They go to the place matching the MID tha= t > >>>> was in RTCP. > >>>> > >>>> 2. The PT are all the same. A packet contains MID1. It goes to the > >>>> place that matches MID1, latching the SSRC to MID1. Later, a packet > >>>> with the same SSRC contains MID2. This moves the latching, so the > >>>> SSRC is now latched to MID2. > >>>> > >>>> > >>>>> On Sep 15, 2016, at 6:18 PM, Cullen Jennings >>>>> > wrote: > >>>>> > >>>>> > >>>>> To propose a few use case=C5=A0. > >>>>> > >>>>> =C2=B3Whiskey & Soda Example=C2=B2 > >>>>> The PT are all the same. Early packets, and any packets after a SSR= C > >>>>> change, contain a MID. If the packet has MID, it goes to the place > >>>>> that matches that MID *and* it latches that SSRC so any future SSRC > >>>>> that don=C2=B9t have a MID go the to the same place. > >>> > >> > >> > >> > >> _______________________________________________ > >> 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 > >---------------------------------------------------------------------- > > > >_______________________________________________ > >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 > --94eb2c0458a82ba157053d296688 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer said:=C2=A0

"If we define the RTP mux procedures in BUNDLE, do we = need to define the
RTP de= mux algorithms in JSEP to begin with?"

[BA] I'd suggest that BUNDLE needs to lay out principles for RTP mux p= rocedures, but it
does not need to get into the details (which ca= n be left to JSEP). =C2=A0

In particular, some of = the most difficult use cases involve situations in which the PTs are not un= ique.=C2=A0 IMHO, BUNDLE Section 10.2 does not provide clear guidelines for= how implementations should behave (and as a result BUNDLE implementations = currently are inconsistent in their behavior).=C2=A0

Some comments on Section 10.2 below:=C2=A0

As described in [Section 10.1.1], the same payload t= ype value might be used inside RTP packets described by multiple "m=3D" lines.= In such cases, the payload type value cannot be used to associate received RTP packets with the correct "m=3D" line. An offerer and answerer can inform each other which SSRC values they will use for RTP and RTCP by using the SDP 'ssrc' attribute [RFC5576]. To allow for proper association with this mechanism, the 'ssrc' attribute needs to be associated with each "m=3D&quo= t; line that shares a payload type with any other "m=3D" line in the same b= undle. As the SSRC values will be carried inside the RTP/RTCP packets, the offerer and answerer can then use that information to associate received RTP packets with the correct "m=3D" line. However, a= n offerer will not know which SSRC values the answerer will use until it 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 received RTP/RTCP packets with the correct "m=3D" li= ne using the SSRC values.
[BA] One area of confus=
ion relates to the meaning of the SSRCs provided in the Answer when PTs are=
 not unique. Is the implication that the SSRCs in the Answer (and ONLY thos=
e SSRCs) will match the m-line?
   In order=
 for an offerer and answerer to always be able to associate
   received RTP and RTCP packets with the correct "m=3D" line, an=
 offerer
   and answerer using the BUNDLE extension MUST support the mechanism
   defined in Section 14, where the remote endpoint inserts the
   identification-tag associated with an "m=3D" line in RTP and R=
TCP
   packets associated with that "m=3D" line.
[BA] Is this only MUST support, or MUST use?  If MIDs might not=
 be used in a situation where PTs are not unique, then this section needs t=
o describe what happens if there is no SSRC match. Do RTP packets get route=
d to the first m-line with a matching PT? Can a PT-match only occur when th=
ere are no SSRCs specified (either for codecs or for RTX/FEC)? So far, I ha=
ve seen at least 3 BUNDLE implementations with different interpretations of=
 this section.



On Fri, Sep 23, 2016 at 10:03 = AM, Christer Holmberg <christer.holmberg@ericsson.com>= wrote:

Hi,

If we define the RTP mux procedures in BUNDLE, do we need to define the
RTP demux algorithms in JSEP to begin with?

Is there something JSEP specific?

Regards,

Christer



On 23/09/16 11:56, "rtcweb on behalf of Magnus Westerlund"
<rtcweb-bounces@ietf.org = on behalf of magnus.weste= rlund@ericsson.com>
wrote:

>Hi,
>
>I think the use cases looks fairly covering.
>
>I want to add an alternative way of thinking on how the SDES item (MID,=
>RID) related demultiplexing part is handled. So the RID and MID in RTP<= br> >header extensions or in RTSP SDES packets results in these values being=
>bound to the SSRC until further notice. So packets arriving without
>actual RTP header extensions can still be handled according to the SSRC= s
>associated SDES items. From my perspective all the cases with MID and >RID can be handled on a per packet basis rules without latching the SSR= C
>to a specific receiver. Instead what is "latched" is the SDES= values to
>the SSRC. Still at the point of change there needs to take the
>combination of SSRC and Seq into account to avoid miss routing packets.=
>
>So my general handling algorithm would be this sequence:
>
>1. Check if RTP header extensions update any SDES item for the SSRC. >=C2=A0 =C2=A0 a. If they do, mark the Sequence number and keep the old = SDES item
>as valid prior to this extended sequence number.
>
>2. Determine the set of relevant SDES items that applies for this
>packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and=
>RID.
>
>3. Perform the demuxing algorithm
>
>
>On another part, I find Jonathan's use case for setting the MID or = RID
>using RTCP an interesting one. This put some light on the question that=
>in a session where MID and RIDs are configured, if one receive packets<= br> >with an SSRC that lacks these SDES items, what do you do, buffer or
>discard?
>
>Cheers
>
>Magnus
>
>Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox:
>> Just that RTCP counts for latching, and that SSRCs=C2=B9 MIDs can = change.
>>
>>> Agree with both of these.=C2=A0 I think they are both the same= as =C2=B3Whiskey
>>> & Soda Example=C2=B2 - or am I missing something about the= ses?
>>>
>>>> On Sep 16, 2016, at 11:59 AM, Jonathan Lennox <jonathan@vidyo.com
>>>> <mailto:jonathan@= vidyo.com>> wrote:
>>>>
>>>> I=C2=B9m not going to come up with beverage names for my e= xamples, but
>>>> feel free to make up your own.
>>>>
>>>> 1. The PT are all the same.=C2=A0 An RTCP source descripti= on for an SSRC
>>>> contains a MID.=C2=A0 This latches the MID.=C2=A0 Later, R= TP packets with this
>>>> SSRC arrive without a MID. They go to the place matching t= he MID that
>>>> was in RTCP.
>>>>
>>>> 2. The PT are all the same.=C2=A0 A packet contains MID1.= =C2=A0 It goes to the
>>>> place that matches MID1, latching the SSRC to MID1.=C2=A0 = Later, a packet
>>>> with the same SSRC contains MID2. This moves the latching,= so the
>>>> SSRC is now latched to MID2.
>>>>
>>>>
>>>>> On Sep 15, 2016, at 6:18 PM, Cullen Jennings <fluffy@iii.ca
>>>>> <mailto:fluffy@iii= .ca>> wrote:
>>>>>
>>>>>
>>>>> To propose a few use case=C5=A0.
>>>>>
>>>>> =C2=B3Whiskey & Soda Example=C2=B2
>>>>> The PT are all= the same. Early packets, and any packets after a SSRC
>>>>> change, contain a MID. If the packet has=C2=A0 MID, it= goes to the place
>>>>> that matches that MID *and* it latches that SSRC so an= y future SSRC
>>>>> that don=C2=B9t have a MID go the to the same place. >>>
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>>
>
>
>--
>
>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

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

--94eb2c0458a82ba157053d296688-- From nobody Fri Sep 23 02:43:00 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC7A12B30F for ; Fri, 23 Sep 2016 02:42:58 -0700 (PDT) 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 DGZinw7BYzVW for ; Fri, 23 Sep 2016 02:42:54 -0700 (PDT) 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 2CA3312C00A for ; Fri, 23 Sep 2016 02:42:54 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-36-57e4f91a13cc Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id FF.C8.31035.A19F4E75; Fri, 23 Sep 2016 11:42:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Fri, 23 Sep 2016 11:42:50 +0200 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [rtcweb] JSEP: RTP demux algorithms Thread-Index: AQHSDrBduC6LB65/lE2Mthgf5jiIWqB6/zGAgAFa1ACAAAkSAIAAAGcAgApOYwCAADWtAP//0xcAgAA4BwA= Date: Fri, 23 Sep 2016 09:42:50 +0000 Message-ID: References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@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.6.5.160527 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D40AD47AFB4Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM2K7qK7MzyfhBjfeiFls2Pef2eLD+h+M FvsXn2e2WPuvnd2BxWPnrLvsHkuW/GTyuHz+I6NH27M77AEsUVw2Kak5mWWpRfp2CVwZ97c0 sBRsfMdYMf3da9YGxq4XjF2MnBwSAiYSx8/0sXQxcnEICaxnlDj+qIcJwlnMKDFv83e2LkYO DjYBC4nuf9ogDSIC2hJ93/aB1TALLGOU2HGplRUkISxgILGw7Ss7SL2IgKFEV588RH2SxKxJ f8BKWARUJSZdeAFm8wpYSfSvXcMCYgsJHGGWeN+pA2JzCgRKLNl6jBnEZhQQk/h+ag0TiM0s IC5x68l8JoijBSSW7DnPDGGLSrx8/A9spqiAnsT3r7Oh4ooS7U8bGCF64yWOPFvGArFXUOLk zCcsExhFZyEZOwtJ2SwkZbOAvmEW0JRYv0sfokRRYkr3Q3YIW0Oidc5cKNtaonXmCnZkNQsY OVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbswS2/VXcwXn7jeIhRgINRiYf3wePH4UKs iWXFlbmHGCU4mJVEeP+/ehIuxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTU gtQimCwTB6dUA2PDlvgPm5vjj5XrNJ1lqtMIn7r+ydYfbfJp0ouFZTqjOf89ZM/lCF9Yu+OW EJ8nZ26aSe3aE4onV1Z0qvY75m2dvaLh36Vt07Zv8VqRtDC2xdfC+PevX4Zqj7MEe6p8PZw2 7z/oaRPp+ULe4PCEleW8Lvmx6kICU/60/d+fmbhw1XNRLbYZMkosxRmJhlrMRcWJANb7s6XU AgAA Archived-At: Cc: "rtcweb@ietf.org" , Jonathan Lennox Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 23 Sep 2016 09:42:58 -0000 --_000_D40AD47AFB4Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkluIG15IG9waW5pb24sIGFsbCBCVU5ETEUgdXNhZ2VzIHNob3VsZCBwZXJmb3JtIHRo ZSBiYXNpYyBkZW11eGluZyBpbiB0aGUgc2FtZSB3YXksIGFuZCBKU0VQIHNob3VsZCByZWZlcmVu Y2UgdGhhdC4NCg0KVGhlbiwgb25seSBKU0VQIHNwZWNpZmljIHByb2NlZHVyZXMgc2hhbGwgYmUg ZG9jdW1lbnRlZCBpbiBKU0VQLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBCZXJu YXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb20+Pg0KRGF0ZTogRnJpZGF5IDIzIFNlcHRlbWJlciAyMDE2IGF0IDEyOjI4DQpUbzog Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkNjOiBNYWdudXMgV2VzdGVybHVuZCA8 bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20+PiwgSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRv OmpvbmF0aGFuQHZpZHlvLmNvbT4+LCBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E8bWFp bHRvOmZsdWZmeUBpaWkuY2E+PiwgInJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYu b3JnPiIgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBKU0VQOiBSVFAgZGVtdXggYWxnb3JpdGhtcw0KDQpDaHJpc3RlciBzYWlk Og0KDQoiSWYgd2UgZGVmaW5lIHRoZSBSVFAgbXV4IHByb2NlZHVyZXMgaW4gQlVORExFLCBkbyB3 ZSBuZWVkIHRvIGRlZmluZSB0aGUNClJUUCBkZW11eCBhbGdvcml0aG1zIGluIEpTRVAgdG8gYmVn aW4gd2l0aD8iDQoNCltCQV0gSSdkIHN1Z2dlc3QgdGhhdCBCVU5ETEUgbmVlZHMgdG8gbGF5IG91 dCBwcmluY2lwbGVzIGZvciBSVFAgbXV4IHByb2NlZHVyZXMsIGJ1dCBpdA0KZG9lcyBub3QgbmVl ZCB0byBnZXQgaW50byB0aGUgZGV0YWlscyAod2hpY2ggY2FuIGJlIGxlZnQgdG8gSlNFUCkuDQoN CkluIHBhcnRpY3VsYXIsIHNvbWUgb2YgdGhlIG1vc3QgZGlmZmljdWx0IHVzZSBjYXNlcyBpbnZv bHZlIHNpdHVhdGlvbnMgaW4gd2hpY2ggdGhlIFBUcyBhcmUgbm90IHVuaXF1ZS4gIElNSE8sIEJV TkRMRSBTZWN0aW9uIDEwLjIgZG9lcyBub3QgcHJvdmlkZSBjbGVhciBndWlkZWxpbmVzIGZvciBo b3cgaW1wbGVtZW50YXRpb25zIHNob3VsZCBiZWhhdmUgKGFuZCBhcyBhIHJlc3VsdCBCVU5ETEUg aW1wbGVtZW50YXRpb25zIGN1cnJlbnRseSBhcmUgaW5jb25zaXN0ZW50IGluIHRoZWlyIGJlaGF2 aW9yKS4NCg0KU29tZSBjb21tZW50cyBvbiBTZWN0aW9uIDEwLjIgYmVsb3c6DQoNCg0KQXMgZGVz Y3JpYmVkIGluIFtTZWN0aW9uIDEwLjEuMV0sIHRoZSBzYW1lIHBheWxvYWQgdHlwZSB2YWx1ZSBt aWdodA0KICAgYmUgdXNlZCBpbnNpZGUgUlRQIHBhY2tldHMgZGVzY3JpYmVkIGJ5IG11bHRpcGxl ICJtPSIgbGluZXMuICBJbiBzdWNoDQogICBjYXNlcywgdGhlIHBheWxvYWQgdHlwZSB2YWx1ZSBj YW5ub3QgYmUgdXNlZCB0byBhc3NvY2lhdGUgcmVjZWl2ZWQNCiAgIFJUUCBwYWNrZXRzIHdpdGgg dGhlIGNvcnJlY3QgIm09IiBsaW5lLg0KDQogICBBbiBvZmZlcmVyIGFuZCBhbnN3ZXJlciBjYW4g aW5mb3JtIGVhY2ggb3RoZXIgd2hpY2ggU1NSQyB2YWx1ZXMgdGhleQ0KICAgd2lsbCB1c2UgZm9y IFJUUCBhbmQgUlRDUCBieSB1c2luZyB0aGUgU0RQICdzc3JjJyBhdHRyaWJ1dGUNCiAgIFtSRkM1 NTc2XS4gIFRvIGFsbG93IGZvciBwcm9wZXIgYXNzb2NpYXRpb24gd2l0aCB0aGlzIG1lY2hhbmlz bSwgdGhlDQogICAnc3NyYycgYXR0cmlidXRlIG5lZWRzIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBl YWNoICJtPSIgbGluZSB0aGF0DQogICBzaGFyZXMgYSBwYXlsb2FkIHR5cGUgd2l0aCBhbnkgb3Ro ZXIgIm09IiBsaW5lIGluIHRoZSBzYW1lIGJ1bmRsZS4NCiAgIEFzIHRoZSBTU1JDIHZhbHVlcyB3 aWxsIGJlIGNhcnJpZWQgaW5zaWRlIHRoZSBSVFAvUlRDUCBwYWNrZXRzLCB0aGUNCiAgIG9mZmVy ZXIgYW5kIGFuc3dlcmVyIGNhbiB0aGVuIHVzZSB0aGF0IGluZm9ybWF0aW9uIHRvIGFzc29jaWF0 ZQ0KICAgcmVjZWl2ZWQgUlRQIHBhY2tldHMgd2l0aCB0aGUgY29ycmVjdCAibT0iIGxpbmUuICBI b3dldmVyLCBhbiBvZmZlcmVyDQogICB3aWxsIG5vdCBrbm93IHdoaWNoIFNTUkMgdmFsdWVzIHRo ZSBhbnN3ZXJlciB3aWxsIHVzZSB1bnRpbCBpdCBoYXMNCiAgIHJlY2VpdmVkIHRoZSBhbnN3ZXIg cHJvdmlkaW5nIHRoYXQgaW5mb3JtYXRpb24uICBEdWUgdG8gdGhpcywgYmVmb3JlDQogICB0aGUg b2ZmZXJlciBoYXMgcmVjZWl2ZWQgdGhlIGFuc3dlciwgdGhlIG9mZmVyZXIgd2lsbCBub3QgYmUg YWJsZSB0bw0KICAgYXNzb2NpYXRlIHJlY2VpdmVkIFJUUC9SVENQIHBhY2tldHMgd2l0aCB0aGUg Y29ycmVjdCAibT0iIGxpbmUgdXNpbmcNCiAgIHRoZSBTU1JDIHZhbHVlcy4NCg0KW0JBXSBPbmUg YXJlYSBvZiBjb25mdXNpb24gcmVsYXRlcyB0byB0aGUgbWVhbmluZyBvZiB0aGUgU1NSQ3MgcHJv dmlkZWQgaW4gdGhlIEFuc3dlciB3aGVuIFBUcyBhcmUgbm90IHVuaXF1ZS4gSXMgdGhlIGltcGxp Y2F0aW9uIHRoYXQgdGhlIFNTUkNzIGluIHRoZSBBbnN3ZXIgKGFuZCBPTkxZIHRob3NlIFNTUkNz KSB3aWxsIG1hdGNoIHRoZSBtLWxpbmU/DQoNCiAgIEluIG9yZGVyIGZvciBhbiBvZmZlcmVyIGFu ZCBhbnN3ZXJlciB0byBhbHdheXMgYmUgYWJsZSB0byBhc3NvY2lhdGUNCiAgIHJlY2VpdmVkIFJU UCBhbmQgUlRDUCBwYWNrZXRzIHdpdGggdGhlIGNvcnJlY3QgIm09IiBsaW5lLCBhbiBvZmZlcmVy DQogICBhbmQgYW5zd2VyZXIgdXNpbmcgdGhlIEJVTkRMRSBleHRlbnNpb24gTVVTVCBzdXBwb3J0 IHRoZSBtZWNoYW5pc20NCiAgIGRlZmluZWQgaW4gU2VjdGlvbiAxNCwgd2hlcmUgdGhlIHJlbW90 ZSBlbmRwb2ludCBpbnNlcnRzIHRoZQ0KICAgaWRlbnRpZmljYXRpb24tdGFnIGFzc29jaWF0ZWQg d2l0aCBhbiAibT0iIGxpbmUgaW4gUlRQIGFuZCBSVENQDQogICBwYWNrZXRzIGFzc29jaWF0ZWQg d2l0aCB0aGF0ICJtPSIgbGluZS4NCg0KW0JBXSBJcyB0aGlzIG9ubHkgTVVTVCBzdXBwb3J0LCBv ciBNVVNUIHVzZT8gIElmIE1JRHMgbWlnaHQgbm90IGJlIHVzZWQgaW4gYSBzaXR1YXRpb24gd2hl cmUgUFRzIGFyZSBub3QgdW5pcXVlLCB0aGVuIHRoaXMgc2VjdGlvbiBuZWVkcyB0byBkZXNjcmli ZSB3aGF0IGhhcHBlbnMgaWYgdGhlcmUgaXMgbm8gU1NSQyBtYXRjaC4gRG8gUlRQIHBhY2tldHMg Z2V0IHJvdXRlZCB0byB0aGUgZmlyc3QgbS1saW5lIHdpdGggYSBtYXRjaGluZyBQVD8gQ2FuIGEg UFQtbWF0Y2ggb25seSBvY2N1ciB3aGVuIHRoZXJlIGFyZSBubyBTU1JDcyBzcGVjaWZpZWQgKGVp dGhlciBmb3IgY29kZWNzIG9yIGZvciBSVFgvRkVDKT8gU28gZmFyLCBJIGhhdmUgc2VlbiBhdCBs ZWFzdCAzIEJVTkRMRSBpbXBsZW1lbnRhdGlvbnMgd2l0aCBkaWZmZXJlbnQgaW50ZXJwcmV0YXRp b25zIG9mIHRoaXMgc2VjdGlvbi4NCg0KDQoNCk9uIEZyaSwgU2VwIDIzLCAyMDE2IGF0IDEwOjAz IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGksDQoNCklm IHdlIGRlZmluZSB0aGUgUlRQIG11eCBwcm9jZWR1cmVzIGluIEJVTkRMRSwgZG8gd2UgbmVlZCB0 byBkZWZpbmUgdGhlDQpSVFAgZGVtdXggYWxnb3JpdGhtcyBpbiBKU0VQIHRvIGJlZ2luIHdpdGg/ DQoNCklzIHRoZXJlIHNvbWV0aGluZyBKU0VQIHNwZWNpZmljPw0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQoNCg0KT24gMjMvMDkvMTYgMTE6NTYsICJydGN3ZWIgb24gYmVoYWxmIG9mIE1hZ251 cyBXZXN0ZXJsdW5kIg0KPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bTxtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPj4NCndyb3RlOg0KDQo+SGks DQo+DQo+SSB0aGluayB0aGUgdXNlIGNhc2VzIGxvb2tzIGZhaXJseSBjb3ZlcmluZy4NCj4NCj5J IHdhbnQgdG8gYWRkIGFuIGFsdGVybmF0aXZlIHdheSBvZiB0aGlua2luZyBvbiBob3cgdGhlIFNE RVMgaXRlbSAoTUlELA0KPlJJRCkgcmVsYXRlZCBkZW11bHRpcGxleGluZyBwYXJ0IGlzIGhhbmRs ZWQuIFNvIHRoZSBSSUQgYW5kIE1JRCBpbiBSVFANCj5oZWFkZXIgZXh0ZW5zaW9ucyBvciBpbiBS VFNQIFNERVMgcGFja2V0cyByZXN1bHRzIGluIHRoZXNlIHZhbHVlcyBiZWluZw0KPmJvdW5kIHRv IHRoZSBTU1JDIHVudGlsIGZ1cnRoZXIgbm90aWNlLiBTbyBwYWNrZXRzIGFycml2aW5nIHdpdGhv dXQNCj5hY3R1YWwgUlRQIGhlYWRlciBleHRlbnNpb25zIGNhbiBzdGlsbCBiZSBoYW5kbGVkIGFj Y29yZGluZyB0byB0aGUgU1NSQ3MNCj5hc3NvY2lhdGVkIFNERVMgaXRlbXMuIEZyb20gbXkgcGVy c3BlY3RpdmUgYWxsIHRoZSBjYXNlcyB3aXRoIE1JRCBhbmQNCj5SSUQgY2FuIGJlIGhhbmRsZWQg b24gYSBwZXIgcGFja2V0IGJhc2lzIHJ1bGVzIHdpdGhvdXQgbGF0Y2hpbmcgdGhlIFNTUkMNCj50 byBhIHNwZWNpZmljIHJlY2VpdmVyLiBJbnN0ZWFkIHdoYXQgaXMgImxhdGNoZWQiIGlzIHRoZSBT REVTIHZhbHVlcyB0bw0KPnRoZSBTU1JDLiBTdGlsbCBhdCB0aGUgcG9pbnQgb2YgY2hhbmdlIHRo ZXJlIG5lZWRzIHRvIHRha2UgdGhlDQo+Y29tYmluYXRpb24gb2YgU1NSQyBhbmQgU2VxIGludG8g YWNjb3VudCB0byBhdm9pZCBtaXNzIHJvdXRpbmcgcGFja2V0cy4NCj4NCj5TbyBteSBnZW5lcmFs IGhhbmRsaW5nIGFsZ29yaXRobSB3b3VsZCBiZSB0aGlzIHNlcXVlbmNlOg0KPg0KPjEuIENoZWNr IGlmIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyB1cGRhdGUgYW55IFNERVMgaXRlbSBmb3IgdGhlIFNT UkMuDQo+ICAgIGEuIElmIHRoZXkgZG8sIG1hcmsgdGhlIFNlcXVlbmNlIG51bWJlciBhbmQga2Vl cCB0aGUgb2xkIFNERVMgaXRlbQ0KPmFzIHZhbGlkIHByaW9yIHRvIHRoaXMgZXh0ZW5kZWQgc2Vx dWVuY2UgbnVtYmVyLg0KPg0KPjIuIERldGVybWluZSB0aGUgc2V0IG9mIHJlbGV2YW50IFNERVMg aXRlbXMgdGhhdCBhcHBsaWVzIGZvciB0aGlzDQo+cGFja2V0LCBpLmUuIHVzZSBTU1JDICsgUlRQ IHNlcSB0byBsb29rIHVwIHRoZSBTREVTIGl0ZW1zLCBlLmcuIE1JRCBhbmQNCj5SSUQuDQo+DQo+ My4gUGVyZm9ybSB0aGUgZGVtdXhpbmcgYWxnb3JpdGhtDQo+DQo+DQo+T24gYW5vdGhlciBwYXJ0 LCBJIGZpbmQgSm9uYXRoYW4ncyB1c2UgY2FzZSBmb3Igc2V0dGluZyB0aGUgTUlEIG9yIFJJRA0K PnVzaW5nIFJUQ1AgYW4gaW50ZXJlc3Rpbmcgb25lLiBUaGlzIHB1dCBzb21lIGxpZ2h0IG9uIHRo ZSBxdWVzdGlvbiB0aGF0DQo+aW4gYSBzZXNzaW9uIHdoZXJlIE1JRCBhbmQgUklEcyBhcmUgY29u ZmlndXJlZCwgaWYgb25lIHJlY2VpdmUgcGFja2V0cw0KPndpdGggYW4gU1NSQyB0aGF0IGxhY2tz IHRoZXNlIFNERVMgaXRlbXMsIHdoYXQgZG8geW91IGRvLCBidWZmZXIgb3INCj5kaXNjYXJkPw0K Pg0KPkNoZWVycw0KPg0KPk1hZ251cw0KPg0KPkRlbiAyMDE2LTA5LTE2IGtsLiAyMTozMywgc2ty ZXYgSm9uYXRoYW4gTGVubm94Og0KPj4gSnVzdCB0aGF0IFJUQ1AgY291bnRzIGZvciBsYXRjaGlu ZywgYW5kIHRoYXQgU1NSQ3PCuSBNSURzIGNhbiBjaGFuZ2UuDQo+Pg0KPj4+IEFncmVlIHdpdGgg Ym90aCBvZiB0aGVzZS4gIEkgdGhpbmsgdGhleSBhcmUgYm90aCB0aGUgc2FtZSBhcyDCs1doaXNr ZXkNCj4+PiAmIFNvZGEgRXhhbXBsZcKyIC0gb3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZyBhYm91 dCB0aGVzZXM/DQo+Pj4NCj4+Pj4gT24gU2VwIDE2LCAyMDE2LCBhdCAxMTo1OSBBTSwgSm9uYXRo YW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT4N Cj4+Pj4gPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNv bT4+PiB3cm90ZToNCj4+Pj4NCj4+Pj4gScK5bSBub3QgZ29pbmcgdG8gY29tZSB1cCB3aXRoIGJl dmVyYWdlIG5hbWVzIGZvciBteSBleGFtcGxlcywgYnV0DQo+Pj4+IGZlZWwgZnJlZSB0byBtYWtl IHVwIHlvdXIgb3duLg0KPj4+Pg0KPj4+PiAxLiBUaGUgUFQgYXJlIGFsbCB0aGUgc2FtZS4gIEFu IFJUQ1Agc291cmNlIGRlc2NyaXB0aW9uIGZvciBhbiBTU1JDDQo+Pj4+IGNvbnRhaW5zIGEgTUlE LiAgVGhpcyBsYXRjaGVzIHRoZSBNSUQuICBMYXRlciwgUlRQIHBhY2tldHMgd2l0aCB0aGlzDQo+ Pj4+IFNTUkMgYXJyaXZlIHdpdGhvdXQgYSBNSUQuIFRoZXkgZ28gdG8gdGhlIHBsYWNlIG1hdGNo aW5nIHRoZSBNSUQgdGhhdA0KPj4+PiB3YXMgaW4gUlRDUC4NCj4+Pj4NCj4+Pj4gMi4gVGhlIFBU IGFyZSBhbGwgdGhlIHNhbWUuICBBIHBhY2tldCBjb250YWlucyBNSUQxLiAgSXQgZ29lcyB0byB0 aGUNCj4+Pj4gcGxhY2UgdGhhdCBtYXRjaGVzIE1JRDEsIGxhdGNoaW5nIHRoZSBTU1JDIHRvIE1J RDEuICBMYXRlciwgYSBwYWNrZXQNCj4+Pj4gd2l0aCB0aGUgc2FtZSBTU1JDIGNvbnRhaW5zIE1J RDIuIFRoaXMgbW92ZXMgdGhlIGxhdGNoaW5nLCBzbyB0aGUNCj4+Pj4gU1NSQyBpcyBub3cgbGF0 Y2hlZCB0byBNSUQyLg0KPj4+Pg0KPj4+Pg0KPj4+Pj4gT24gU2VwIDE1LCAyMDE2LCBhdCA2OjE4 IFBNLCBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E8bWFpbHRvOmZsdWZmeUBpaWkuY2E+ DQo+Pj4+PiA8bWFpbHRvOmZsdWZmeUBpaWkuY2E8bWFpbHRvOmZsdWZmeUBpaWkuY2E+Pj4gd3Jv dGU6DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRvIHByb3Bvc2UgYSBmZXcgdXNlIGNhc2XFoC4NCj4+ Pj4+DQo+Pj4+PiDCs1doaXNrZXkgJiBTb2RhIEV4YW1wbGXCsg0KPj4+Pj4gVGhlIFBUIGFyZSBh bGwgdGhlIHNhbWUuIEVhcmx5IHBhY2tldHMsIGFuZCBhbnkgcGFja2V0cyBhZnRlciBhIFNTUkMN Cj4+Pj4+IGNoYW5nZSwgY29udGFpbiBhIE1JRC4gSWYgdGhlIHBhY2tldCBoYXMgIE1JRCwgaXQg Z29lcyB0byB0aGUgcGxhY2UNCj4+Pj4+IHRoYXQgbWF0Y2hlcyB0aGF0IE1JRCAqYW5kKiBpdCBs YXRjaGVzIHRoYXQgU1NSQyBzbyBhbnkgZnV0dXJlIFNTUkMNCj4+Pj4+IHRoYXQgZG9uwrl0IGhh dmUgYSBNSUQgZ28gdGhlIHRvIHRoZSBzYW1lIHBsYWNlLg0KPj4+DQo+Pg0KPj4NCj4+DQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcnRjd2Vi IG1haWxpbmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+ DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4NCj4N Cj4NCj4tLQ0KPg0KPk1hZ251cyBXZXN0ZXJsdW5kDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPlNlcnZp Y2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RY TQ0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj5Fcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9uZSAg KzQ2IDEwIDcxNDgyODc8dGVsOiUyQjQ2JTIwMTAlMjA3MTQ4Mjg3Pg0KPkbDpHLDtmdhdGFuIDYg ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5PHRlbDolMkI0NiUyMDczJTIw MDk0OTA3OT4NCj5TRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTxtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24u Y29tPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj5ydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl Yg0KDQo= --_000_D40AD47AFB4Dchristerholmbergericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSw8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIG15IG9waW5pb24sIGFsbCBCVU5ETEUgdXNhZ2Vz IHNob3VsZCBwZXJmb3JtIHRoZSBiYXNpYyBkZW11eGluZyBpbiB0aGUgc2FtZSB3YXksIGFuZCBK U0VQIHNob3VsZCByZWZlcmVuY2UgdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlRoZW4sIG9ubHkgSlNFUCBzcGVjaWZpYyBwcm9jZWR1cmVzIHNoYWxsIGJlIGRvY3VtZW50ZWQg aW4gSlNFUC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaHJpc3RlcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsg Qk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsg Qk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206 IDwvc3Bhbj5CZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb20iPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSAyMyBTZXB0ZW1iZXIgMjAx NiBhdCAxMjoyODxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFu PkNocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPk1hZ251cyBXZXN0ZXJs dW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIj5t YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+Jmd0OywgSm9uYXRoYW4gTGVubm94ICZs dDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208 L2E+Jmd0OywgQ3VsbGVuIEplbm5pbmdzICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGlpaS5j YSI+Zmx1ZmZ5QGlpaS5jYTwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpy dGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3J0Y3dlYl0gSlNFUDogUlRQ IGRlbXV4IGFsZ29yaXRobXM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgZGlyPSJsdHIiPkNocmlzdGVyIHNhaWQ6Jm5ic3A7DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4mcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjhweCI+SWYgd2UgZGVm aW5lIHRoZSBSVFAgbXV4IHByb2NlZHVyZXMgaW4gQlVORExFLCBkbyB3ZSBuZWVkIHRvIGRlZmlu ZSB0aGU8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4Ij5S VFAgZGVtdXggYWxnb3JpdGhtcyBpbiBKU0VQIHRvIGJlZ2luIHdpdGg/PC9zcGFuPiZxdW90Ozwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W0JBXSBJJ2Qgc3VnZ2VzdCB0aGF0IEJVTkRM RSBuZWVkcyB0byBsYXkgb3V0IHByaW5jaXBsZXMgZm9yIFJUUCBtdXggcHJvY2VkdXJlcywgYnV0 IGl0PC9kaXY+DQo8ZGl2PmRvZXMgbm90IG5lZWQgdG8gZ2V0IGludG8gdGhlIGRldGFpbHMgKHdo aWNoIGNhbiBiZSBsZWZ0IHRvIEpTRVApLiAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkluIHBhcnRpY3VsYXIsIHNvbWUgb2YgdGhlIG1vc3QgZGlmZmljdWx0IHVzZSBjYXNl cyBpbnZvbHZlIHNpdHVhdGlvbnMgaW4gd2hpY2ggdGhlIFBUcyBhcmUgbm90IHVuaXF1ZS4mbmJz cDsgSU1ITywgQlVORExFIFNlY3Rpb24gMTAuMiBkb2VzIG5vdCBwcm92aWRlIGNsZWFyIGd1aWRl bGluZXMgZm9yIGhvdyBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGJlaGF2ZSAoYW5kIGFzIGEgcmVz dWx0IEJVTkRMRSBpbXBsZW1lbnRhdGlvbnMgY3VycmVudGx5DQogYXJlIGluY29uc2lzdGVudCBp biB0aGVpciBiZWhhdmlvcikuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5T b21lIGNvbW1lbnRzIG9uIFNlY3Rpb24gMTAuMiBiZWxvdzombmJzcDs8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYm94LXNpemluZzpib3JkZXItYm94O292ZXJm bG93OmF1dG87Zm9udC1mYW1pbHk6JnF1b3Q7cHQgbW9ubyZxdW90Oyxtb25hY28sbW9ub3NwYWNl O2ZvbnQtc2l6ZToxNHB4O3BhZGRpbmc6MTBweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9t OjEwLjVweDtsaW5lLWhlaWdodDoxLjIxNDtjb2xvcjpyZ2IoMCwwLDApO3dvcmQtYnJlYWs6YnJl YWstYWxsO3dvcmQtd3JhcDpicmVhay13b3JkO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTMs MjQ1KTtib3JkZXI6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLXJhZGl1czo0cHgi PkFzIGRlc2NyaWJlZCBpbiBbU2VjdGlvbiAxMC4xLjFdLCB0aGUgc2FtZSBwYXlsb2FkIHR5cGUg dmFsdWUgbWlnaHQNCiAgIGJlIHVzZWQgaW5zaWRlIFJUUCBwYWNrZXRzIGRlc2NyaWJlZCBieSBt dWx0aXBsZSAmcXVvdDttPSZxdW90OyBsaW5lcy4gIEluIHN1Y2gNCiAgIGNhc2VzLCB0aGUgcGF5 bG9hZCB0eXBlIHZhbHVlIGNhbm5vdCBiZSB1c2VkIHRvIGFzc29jaWF0ZSByZWNlaXZlZA0KICAg UlRQIHBhY2tldHMgd2l0aCB0aGUgY29ycmVjdCAmcXVvdDttPSZxdW90OyBsaW5lLg0KDQogICBB biBvZmZlcmVyIGFuZCBhbnN3ZXJlciBjYW4gaW5mb3JtIGVhY2ggb3RoZXIgd2hpY2ggU1NSQyB2 YWx1ZXMgdGhleQ0KICAgd2lsbCB1c2UgZm9yIFJUUCBhbmQgUlRDUCBieSB1c2luZyB0aGUgU0RQ ICdzc3JjJyBhdHRyaWJ1dGUNCiAgIFtSRkM1NTc2XS4gIFRvIGFsbG93IGZvciBwcm9wZXIgYXNz b2NpYXRpb24gd2l0aCB0aGlzIG1lY2hhbmlzbSwgdGhlDQogICAnc3NyYycgYXR0cmlidXRlIG5l ZWRzIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBlYWNoICZxdW90O209JnF1b3Q7IGxpbmUgdGhhdA0K ICAgc2hhcmVzIGEgcGF5bG9hZCB0eXBlIHdpdGggYW55IG90aGVyICZxdW90O209JnF1b3Q7IGxp bmUgaW4gdGhlIHNhbWUgYnVuZGxlLg0KICAgQXMgdGhlIFNTUkMgdmFsdWVzIHdpbGwgYmUgY2Fy cmllZCBpbnNpZGUgdGhlIFJUUC9SVENQIHBhY2tldHMsIHRoZQ0KICAgb2ZmZXJlciBhbmQgYW5z d2VyZXIgY2FuIHRoZW4gdXNlIHRoYXQgaW5mb3JtYXRpb24gdG8gYXNzb2NpYXRlDQogICByZWNl aXZlZCBSVFAgcGFja2V0cyB3aXRoIHRoZSBjb3JyZWN0ICZxdW90O209JnF1b3Q7IGxpbmUuICBI b3dldmVyLCBhbiBvZmZlcmVyDQogICB3aWxsIG5vdCBrbm93IHdoaWNoIFNTUkMgdmFsdWVzIHRo ZSBhbnN3ZXJlciB3aWxsIHVzZSB1bnRpbCBpdCBoYXMNCiAgIHJlY2VpdmVkIHRoZSBhbnN3ZXIg cHJvdmlkaW5nIHRoYXQgaW5mb3JtYXRpb24uICBEdWUgdG8gdGhpcywgYmVmb3JlDQogICB0aGUg b2ZmZXJlciBoYXMgcmVjZWl2ZWQgdGhlIGFuc3dlciwgdGhlIG9mZmVyZXIgd2lsbCBub3QgYmUg YWJsZSB0bw0KICAgYXNzb2NpYXRlIHJlY2VpdmVkIFJUUC9SVENQIHBhY2tldHMgd2l0aCB0aGUg Y29ycmVjdCAmcXVvdDttPSZxdW90OyBsaW5lIHVzaW5nDQogICB0aGUgU1NSQyB2YWx1ZXMuPC9w cmU+DQo8cHJlIHN0eWxlPSJib3gtc2l6aW5nOmJvcmRlci1ib3g7b3ZlcmZsb3c6YXV0bztmb250 LWZhbWlseTomcXVvdDtwdCBtb25vJnF1b3Q7LG1vbmFjbyxtb25vc3BhY2U7Zm9udC1zaXplOjE0 cHg7cGFkZGluZzoxMHB4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MTAuNXB4O2xpbmUt aGVpZ2h0OjEuMjE0O2NvbG9yOnJnYigwLDAsMCk7d29yZC1icmVhazpicmVhay1hbGw7d29yZC13 cmFwOmJyZWFrLXdvcmQ7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1MywyNDUpO2JvcmRlcjox cHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtib3JkZXItcmFkaXVzOjRweCI+W0JBXSBPbmUgYXJl YSBvZiBjb25mdXNpb24gcmVsYXRlcyB0byB0aGUgbWVhbmluZyBvZiB0aGUgU1NSQ3MgcHJvdmlk ZWQgaW4gdGhlIEFuc3dlciB3aGVuIFBUcyBhcmUgbm90IHVuaXF1ZS4gSXMgdGhlIGltcGxpY2F0 aW9uIHRoYXQgdGhlIFNTUkNzIGluIHRoZSBBbnN3ZXIgKGFuZCBPTkxZIHRob3NlIFNTUkNzKSB3 aWxsIG1hdGNoIHRoZSBtLWxpbmU/PC9wcmU+DQo8cHJlIHN0eWxlPSJib3gtc2l6aW5nOmJvcmRl ci1ib3g7b3ZlcmZsb3c6YXV0bztmb250LWZhbWlseTomcXVvdDtwdCBtb25vJnF1b3Q7LG1vbmFj byxtb25vc3BhY2U7Zm9udC1zaXplOjE0cHg7cGFkZGluZzoxMHB4O21hcmdpbi10b3A6MHB4O21h cmdpbi1ib3R0b206MTAuNXB4O2xpbmUtaGVpZ2h0OjEuMjE0O2NvbG9yOnJnYigwLDAsMCk7d29y ZC1icmVhazpicmVhay1hbGw7d29yZC13cmFwOmJyZWFrLXdvcmQ7YmFja2dyb3VuZC1jb2xvcjpy Z2IoMjU1LDI1MywyNDUpO2JvcmRlcjoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtib3JkZXIt cmFkaXVzOjRweCI+ICAgSW4gb3JkZXIgZm9yIGFuIG9mZmVyZXIgYW5kIGFuc3dlcmVyIHRvIGFs d2F5cyBiZSBhYmxlIHRvIGFzc29jaWF0ZQ0KICAgcmVjZWl2ZWQgUlRQIGFuZCBSVENQIHBhY2tl dHMgd2l0aCB0aGUgY29ycmVjdCAmcXVvdDttPSZxdW90OyBsaW5lLCBhbiBvZmZlcmVyDQogICBh bmQgYW5zd2VyZXIgdXNpbmcgdGhlIEJVTkRMRSBleHRlbnNpb24gTVVTVCBzdXBwb3J0IHRoZSBt ZWNoYW5pc20NCiAgIGRlZmluZWQgaW4gU2VjdGlvbiAxNCwgd2hlcmUgdGhlIHJlbW90ZSBlbmRw b2ludCBpbnNlcnRzIHRoZQ0KICAgaWRlbnRpZmljYXRpb24tdGFnIGFzc29jaWF0ZWQgd2l0aCBh biAmcXVvdDttPSZxdW90OyBsaW5lIGluIFJUUCBhbmQgUlRDUA0KICAgcGFja2V0cyBhc3NvY2lh dGVkIHdpdGggdGhhdCAmcXVvdDttPSZxdW90OyBsaW5lLjwvcHJlPg0KPHByZSBzdHlsZT0iYm94 LXNpemluZzpib3JkZXItYm94O292ZXJmbG93OmF1dG87Zm9udC1mYW1pbHk6JnF1b3Q7cHQgbW9u byZxdW90Oyxtb25hY28sbW9ub3NwYWNlO2ZvbnQtc2l6ZToxNHB4O3BhZGRpbmc6MTBweDttYXJn aW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjEwLjVweDtsaW5lLWhlaWdodDoxLjIxNDtjb2xvcjpy Z2IoMCwwLDApO3dvcmQtYnJlYWs6YnJlYWstYWxsO3dvcmQtd3JhcDpicmVhay13b3JkO2JhY2tn cm91bmQtY29sb3I6cmdiKDI1NSwyNTMsMjQ1KTtib3JkZXI6MXB4IHNvbGlkIHJnYigyMDQsMjA0 LDIwNCk7Ym9yZGVyLXJhZGl1czo0cHgiPltCQV0gSXMgdGhpcyBvbmx5IE1VU1Qgc3VwcG9ydCwg b3IgTVVTVCB1c2U/ICBJZiBNSURzIG1pZ2h0IG5vdCBiZSB1c2VkIGluIGEgc2l0dWF0aW9uIHdo ZXJlIFBUcyBhcmUgbm90IHVuaXF1ZSwgdGhlbiB0aGlzIHNlY3Rpb24gbmVlZHMgdG8gZGVzY3Jp YmUgd2hhdCBoYXBwZW5zIGlmIHRoZXJlIGlzIG5vIFNTUkMgbWF0Y2guIERvIFJUUCBwYWNrZXRz IGdldCByb3V0ZWQgdG8gdGhlIGZpcnN0IG0tbGluZSB3aXRoIGEgbWF0Y2hpbmcgUFQ/IENhbiBh IFBULW1hdGNoIG9ubHkgb2NjdXIgd2hlbiB0aGVyZSBhcmUgbm8gU1NSQ3Mgc3BlY2lmaWVkIChl aXRoZXIgZm9yIGNvZGVjcyBvciBmb3IgUlRYL0ZFQyk/IFNvIGZhciwgSSBoYXZlIHNlZW4gYXQg bGVhc3QgMyBCVU5ETEUgaW1wbGVtZW50YXRpb25zIHdpdGggZGlmZmVyZW50IGludGVycHJldGF0 aW9ucyBvZiB0aGlzIHNlY3Rpb24uPC9wcmU+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgU2VwIDIzLCAyMDE2IGF0IDEwOjAzIEFN LCBDaHJpc3RlciBIb2xtYmVyZyA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxicj4NCkhpLDxicj4NCjxi cj4NCklmIHdlIGRlZmluZSB0aGUgUlRQIG11eCBwcm9jZWR1cmVzIGluIEJVTkRMRSwgZG8gd2Ug bmVlZCB0byBkZWZpbmUgdGhlPGJyPg0KUlRQIGRlbXV4IGFsZ29yaXRobXMgaW4gSlNFUCB0byBi ZWdpbiB3aXRoPzxicj4NCjxicj4NCklzIHRoZXJlIHNvbWV0aGluZyBKU0VQIHNwZWNpZmljPzxi cj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQpPbiAyMy8wOS8xNiAxMTo1NiwgJnF1b3Q7cnRjd2ViIG9uIGJlaGFsZiBvZiBNYWdudXMg V2VzdGVybHVuZCZxdW90Ozxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmciPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhy ZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iPm1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbTwvYT48d2JyPiZndDs8YnI+DQp3cm90ZTo8YnI+DQo8ZGl2Pg0KPGRp diBjbGFzcz0iaDUiPjxicj4NCiZndDtIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0O0kgdGhpbmsgdGhl IHVzZSBjYXNlcyBsb29rcyBmYWlybHkgY292ZXJpbmcuPGJyPg0KJmd0Ozxicj4NCiZndDtJIHdh bnQgdG8gYWRkIGFuIGFsdGVybmF0aXZlIHdheSBvZiB0aGlua2luZyBvbiBob3cgdGhlIFNERVMg aXRlbSAoTUlELDxicj4NCiZndDtSSUQpIHJlbGF0ZWQgZGVtdWx0aXBsZXhpbmcgcGFydCBpcyBo YW5kbGVkLiBTbyB0aGUgUklEIGFuZCBNSUQgaW4gUlRQPGJyPg0KJmd0O2hlYWRlciBleHRlbnNp b25zIG9yIGluIFJUU1AgU0RFUyBwYWNrZXRzIHJlc3VsdHMgaW4gdGhlc2UgdmFsdWVzIGJlaW5n PGJyPg0KJmd0O2JvdW5kIHRvIHRoZSBTU1JDIHVudGlsIGZ1cnRoZXIgbm90aWNlLiBTbyBwYWNr ZXRzIGFycml2aW5nIHdpdGhvdXQ8YnI+DQomZ3Q7YWN0dWFsIFJUUCBoZWFkZXIgZXh0ZW5zaW9u cyBjYW4gc3RpbGwgYmUgaGFuZGxlZCBhY2NvcmRpbmcgdG8gdGhlIFNTUkNzPGJyPg0KJmd0O2Fz c29jaWF0ZWQgU0RFUyBpdGVtcy4gRnJvbSBteSBwZXJzcGVjdGl2ZSBhbGwgdGhlIGNhc2VzIHdp dGggTUlEIGFuZDxicj4NCiZndDtSSUQgY2FuIGJlIGhhbmRsZWQgb24gYSBwZXIgcGFja2V0IGJh c2lzIHJ1bGVzIHdpdGhvdXQgbGF0Y2hpbmcgdGhlIFNTUkM8YnI+DQomZ3Q7dG8gYSBzcGVjaWZp YyByZWNlaXZlci4gSW5zdGVhZCB3aGF0IGlzICZxdW90O2xhdGNoZWQmcXVvdDsgaXMgdGhlIFNE RVMgdmFsdWVzIHRvPGJyPg0KJmd0O3RoZSBTU1JDLiBTdGlsbCBhdCB0aGUgcG9pbnQgb2YgY2hh bmdlIHRoZXJlIG5lZWRzIHRvIHRha2UgdGhlPGJyPg0KJmd0O2NvbWJpbmF0aW9uIG9mIFNTUkMg YW5kIFNlcSBpbnRvIGFjY291bnQgdG8gYXZvaWQgbWlzcyByb3V0aW5nIHBhY2tldHMuPGJyPg0K Jmd0Ozxicj4NCiZndDtTbyBteSBnZW5lcmFsIGhhbmRsaW5nIGFsZ29yaXRobSB3b3VsZCBiZSB0 aGlzIHNlcXVlbmNlOjxicj4NCiZndDs8YnI+DQomZ3Q7MS4gQ2hlY2sgaWYgUlRQIGhlYWRlciBl eHRlbnNpb25zIHVwZGF0ZSBhbnkgU0RFUyBpdGVtIGZvciB0aGUgU1NSQy48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyBhLiBJZiB0aGV5IGRvLCBtYXJrIHRoZSBTZXF1ZW5jZSBudW1iZXIgYW5kIGtl ZXAgdGhlIG9sZCBTREVTIGl0ZW08YnI+DQomZ3Q7YXMgdmFsaWQgcHJpb3IgdG8gdGhpcyBleHRl bmRlZCBzZXF1ZW5jZSBudW1iZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsyLiBEZXRlcm1pbmUgdGhl IHNldCBvZiByZWxldmFudCBTREVTIGl0ZW1zIHRoYXQgYXBwbGllcyBmb3IgdGhpczxicj4NCiZn dDtwYWNrZXQsIGkuZS4gdXNlIFNTUkMgJiM0MzsgUlRQIHNlcSB0byBsb29rIHVwIHRoZSBTREVT IGl0ZW1zLCBlLmcuIE1JRCBhbmQ8YnI+DQomZ3Q7UklELjxicj4NCiZndDs8YnI+DQomZ3Q7My4g UGVyZm9ybSB0aGUgZGVtdXhpbmcgYWxnb3JpdGhtPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7T24gYW5vdGhlciBwYXJ0LCBJIGZpbmQgSm9uYXRoYW4ncyB1c2UgY2FzZSBmb3Igc2V0dGlu ZyB0aGUgTUlEIG9yIFJJRDxicj4NCiZndDt1c2luZyBSVENQIGFuIGludGVyZXN0aW5nIG9uZS4g VGhpcyBwdXQgc29tZSBsaWdodCBvbiB0aGUgcXVlc3Rpb24gdGhhdDxicj4NCiZndDtpbiBhIHNl c3Npb24gd2hlcmUgTUlEIGFuZCBSSURzIGFyZSBjb25maWd1cmVkLCBpZiBvbmUgcmVjZWl2ZSBw YWNrZXRzPGJyPg0KJmd0O3dpdGggYW4gU1NSQyB0aGF0IGxhY2tzIHRoZXNlIFNERVMgaXRlbXMs IHdoYXQgZG8geW91IGRvLCBidWZmZXIgb3I8YnI+DQomZ3Q7ZGlzY2FyZD88YnI+DQomZ3Q7PGJy Pg0KJmd0O0NoZWVyczxicj4NCiZndDs8YnI+DQomZ3Q7TWFnbnVzPGJyPg0KJmd0Ozxicj4NCiZn dDtEZW4gMjAxNi0wOS0xNiBrbC4gMjE6MzMsIHNrcmV2IEpvbmF0aGFuIExlbm5veDo8YnI+DQom Z3Q7Jmd0OyBKdXN0IHRoYXQgUlRDUCBjb3VudHMgZm9yIGxhdGNoaW5nLCBhbmQgdGhhdCBTU1JD c8K5IE1JRHMgY2FuIGNoYW5nZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBZ3Jl ZSB3aXRoIGJvdGggb2YgdGhlc2UuJm5ic3A7IEkgdGhpbmsgdGhleSBhcmUgYm90aCB0aGUgc2Ft ZSBhcyDCs1doaXNrZXk8YnI+DQomZ3Q7Jmd0OyZndDsgJmFtcDsgU29kYSBFeGFtcGxlwrIgLSBv ciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nIGFib3V0IHRoZXNlcz88YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uIFNlcCAxNiwgMjAxNiwgYXQgMTE6NTkgQU0sIEpvbmF0 aGFuIExlbm5veCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSI+am9uYXRo YW5AdmlkeW8uY29tPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0OyZn dDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgScK5 bSBub3QgZ29pbmcgdG8gY29tZSB1cCB3aXRoIGJldmVyYWdlIG5hbWVzIGZvciBteSBleGFtcGxl cywgYnV0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBmZWVsIGZyZWUgdG8gbWFrZSB1cCB5b3VyIG93 bi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAxLiBUaGUgUFQg YXJlIGFsbCB0aGUgc2FtZS4mbmJzcDsgQW4gUlRDUCBzb3VyY2UgZGVzY3JpcHRpb24gZm9yIGFu IFNTUkM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnRhaW5zIGEgTUlELiZuYnNwOyBUaGlzIGxh dGNoZXMgdGhlIE1JRC4mbmJzcDsgTGF0ZXIsIFJUUCBwYWNrZXRzIHdpdGggdGhpczxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgU1NSQyBhcnJpdmUgd2l0aG91dCBhIE1JRC4gVGhleSBnbyB0byB0aGUg cGxhY2UgbWF0Y2hpbmcgdGhlIE1JRCB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB3YXMgaW4g UlRDUC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAyLiBUaGUg UFQgYXJlIGFsbCB0aGUgc2FtZS4mbmJzcDsgQSBwYWNrZXQgY29udGFpbnMgTUlEMS4mbmJzcDsg SXQgZ29lcyB0byB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHBsYWNlIHRoYXQgbWF0Y2hlcyBN SUQxLCBsYXRjaGluZyB0aGUgU1NSQyB0byBNSUQxLiZuYnNwOyBMYXRlciwgYSBwYWNrZXQ8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IHdpdGggdGhlIHNhbWUgU1NSQyBjb250YWlucyBNSUQyLiBUaGlz IG1vdmVzIHRoZSBsYXRjaGluZywgc28gdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBTU1JDIGlz IG5vdyBsYXRjaGVkIHRvIE1JRDIuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBTZXAgMTUsIDIwMTYsIGF0IDY6 MTggUE0sIEN1bGxlbiBKZW5uaW5ncyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZsdWZmeUBpaWkuY2Ei PmZsdWZmeUBpaWkuY2E8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGlpaS5jYSI+Zmx1ZmZ5QGlpaS5jYTwvYT4mZ3Q7Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvIHByb3Bvc2UgYSBm ZXcgdXNlIGNhc2XFoC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IMKzV2hpc2tleSAmYW1wOyBTb2RhIEV4YW1wbGXCsjxicj4NCjxkaXYgY2xhc3M9 IkhPRW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIFBUIGFy ZSBhbGwgdGhlIHNhbWUuIEVhcmx5IHBhY2tldHMsIGFuZCBhbnkgcGFja2V0cyBhZnRlciBhIFNT UkM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFuZ2UsIGNvbnRhaW4gYSBNSUQuIElmIHRo ZSBwYWNrZXQgaGFzJm5ic3A7IE1JRCwgaXQgZ29lcyB0byB0aGUgcGxhY2U8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aGF0IG1hdGNoZXMgdGhhdCBNSUQgKmFuZCogaXQgbGF0Y2hlcyB0aGF0 IFNTUkMgc28gYW55IGZ1dHVyZSBTU1JDPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBk b27CuXQgaGF2ZSBhIE1JRCBnbyB0aGUgdG8gdGhlIHNhbWUgcGxhY2UuPGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsmZ3Q7IHJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHJl bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi88d2JyPmxpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Oy0tPGJyPg0KJmd0Ozxicj4NCiZndDtNYWdudXMgV2VzdGVybHVuZDxi cj4NCiZndDs8YnI+DQomZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS08YnI+DQomZ3Q7U2Vydmlj ZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhN PGJyPg0KJmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tPGJyPg0KJmd0O0VyaWNzc29uIEFCJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8IFBob25lJm5ic3A7IDxhIGhyZWY9InRlbDolMkI0NiUyMDEwJTIwNzE0ODI4NyIgdmFsdWU9 IiYjNDM7NDYxMDcxNDgyODciPg0KJiM0Mzs0NiAxMCA3MTQ4Mjg3PC9hPjxicj4NCiZndDtGw6Ry w7ZnYXRhbiA2Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8IE1vYmlsZSA8YSBocmVmPSJ0ZWw6JTJCNDYlMjA3MyUyMDA5NDkwNzki IHZhbHVlPSImIzQzOzQ2NzMwOTQ5MDc5Ij4NCiYjNDM7NDYgNzMgMDk0OTA3OTwvYT48YnI+DQom Z3Q7U0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiA8YSBocmVmPSJtYWlsdG86 bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIj4NCm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNz c29uLmNvbTwvYT48YnI+DQomZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJy Pg0KJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7cnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCiZndDs8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OzxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiByZWw9Im5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlz dGluZm8vcnRjd2ViPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu Lzx3YnI+bGlzdGluZm8vcnRjd2ViPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_D40AD47AFB4Dchristerholmbergericssoncom_-- From nobody Mon Sep 26 01:48:45 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E9312B0BF for ; Mon, 26 Sep 2016 01:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 GOqverEb3Qy1 for ; Mon, 26 Sep 2016 01:48:40 -0700 (PDT) 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 5B71912B0B8 for ; Mon, 26 Sep 2016 01:48:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 335A87CABFE for ; Mon, 26 Sep 2016 10:48:38 +0200 (CEST) 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 8PQc2iqnVXud for ; Mon, 26 Sep 2016 10:48:36 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:41d2:e07c:b0d5:11f3] (unknown [IPv6:2001:470:de0a:1:41d2:e07c:b0d5:11f3]) by mork.alvestrand.no (Postfix) with ESMTPSA id 40D157CABFC for ; Mon, 26 Sep 2016 10:48:36 +0200 (CEST) To: rtcweb@ietf.org References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> From: Harald Alvestrand Message-ID: <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> Date: Mon, 26 Sep 2016 10:48:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 26 Sep 2016 08:48:43 -0000 Den 23. sep. 2016 10:56, skrev Magnus Westerlund: > Hi, > > I think the use cases looks fairly covering. > > I want to add an alternative way of thinking on how the SDES item (MID, > RID) related demultiplexing part is handled. So the RID and MID in RTP > header extensions or in RTSP SDES packets results in these values being > bound to the SSRC until further notice. So packets arriving without > actual RTP header extensions can still be handled according to the SSRCs > associated SDES items. From my perspective all the cases with MID and > RID can be handled on a per packet basis rules without latching the SSRC > to a specific receiver. Instead what is "latched" is the SDES values to > the SSRC. Still at the point of change there needs to take the > combination of SSRC and Seq into account to avoid miss routing packets. > > So my general handling algorithm would be this sequence: > > 1. Check if RTP header extensions update any SDES item for the SSRC. > a. If they do, mark the Sequence number and keep the old SDES item as > valid prior to this extended sequence number. > > 2. Determine the set of relevant SDES items that applies for this > packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and > RID. > > 3. Perform the demuxing algorithm I don't understand this as written. When an RTP packet arrives before the RTCP packet containing SDES, we can't latch to the content of the RTCP packet; we haven't seen it yet. You can, in theory, latch RID and MID for the SSRC to the values in the SDES packet you haven't seen yet, but that seems somewhat backwards. The problematic sequence is: 1) RTP packet(s) with header extensions 2) RTP packet(s) without header extensions 3) SDES RTCP packet (I'm assuming that we require consistency between SDES and RTP header extensions. What do we do if they're inconsistent?) > On another part, I find Jonathan's use case for setting the MID or RID > using RTCP an interesting one. This put some light on the question that > in a session where MID and RIDs are configured, if one receive packets > with an SSRC that lacks these SDES items, what do you do, buffer or > discard? > > Cheers > > Magnus > > Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox: >> Just that RTCP counts for latching, and that SSRCs’ MIDs can change. >> >>> Agree with both of these. I think they are both the same as “Whiskey >>> & Soda Example” - or am I missing something about theses? >>> >>>> On Sep 16, 2016, at 11:59 AM, Jonathan Lennox >>> > wrote: >>>> >>>> I’m not going to come up with beverage names for my examples, but >>>> feel free to make up your own. >>>> >>>> 1. The PT are all the same. An RTCP source description for an SSRC >>>> contains a MID. This latches the MID. Later, RTP packets with this >>>> SSRC arrive without a MID. They go to the place matching the MID that >>>> was in RTCP. >>>> >>>> 2. The PT are all the same. A packet contains MID1. It goes to the >>>> place that matches MID1, latching the SSRC to MID1. Later, a packet >>>> with the same SSRC contains MID2. This moves the latching, so the >>>> SSRC is now latched to MID2. >>>> >>>> >>>>> On Sep 15, 2016, at 6:18 PM, Cullen Jennings >>>> > wrote: >>>>> >>>>> >>>>> To propose a few use case…. >>>>> >>>>> “Whiskey & Soda Example” >>>>> The PT are all the same. Early packets, and any packets after a SSRC >>>>> change, contain a MID. If the packet has MID, it goes to the place >>>>> that matches that MID *and* it latches that SSRC so any future SSRC >>>>> that don’t have a MID go the to the same place. >>> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > From nobody Mon Sep 26 02:15:04 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80212B0C5 for ; Mon, 26 Sep 2016 02:15:02 -0700 (PDT) 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 iwfOwJJzGg2a for ; Mon, 26 Sep 2016 02:15:00 -0700 (PDT) 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 4FA4712B0A3 for ; Mon, 26 Sep 2016 02:15:00 -0700 (PDT) X-AuditID: c1b4fb30-b73ff70000000cb2-0f-57e8e712af72 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 2E.77.03250.217E8E75; Mon, 26 Sep 2016 11:14:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.301.0; Mon, 26 Sep 2016 11:14:57 +0200 To: Harald Alvestrand , References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> From: Magnus Westerlund Message-ID: <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> Date: Mon, 26 Sep 2016 11:14:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7h67Q8xfhBtsuaFgc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4ufssa0GXVMWMpqAGxhsiXYycHBICJhJX dyxm7WLk4hASWM8o8WbiBnaQhJDAckaJOd9DQWxhAQOJhW1fweIiAvYSF+e8ZIFoaGaWeHN4 ChNIgk3AQuLmj0Y2EJsXqGjLhs/MIDaLgKrEnSv/WUFsUYEYif2zZjJD1AhKnJz5hAXE5hRw lHh7/ClQLwcHM1Dvg61lIGFmAXmJ5q2zmSHu0ZZoaOpgncDIPwtJ9yyEjllIOhYwMq9iFC1O LU7KTTcy0kstykwuLs7P08tLLdnECAy9g1t+G+xgfPnc8RCjAAejEg9vwo3n4UKsiWXFlbmH GCU4mJVEeKfdfBEuxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwT B6dUA6PepLi3qp9sJVlmn82cbaY6eXfhjRV+jGZGZUyLH3171Dn9KCfXcYXQ8yU/C/bPXKnd XW6h6RSmmMT7g+9Sz3S7/BUX2j8+4y5f2fQlaYPhg7uqWf963IulE3TOHz1UbyvYFl+grJ1S LrTNiZef5c7DqtqD+/euXitswBhgbPMsdPl/b8WFCkosxRmJhlrMRcWJABGM1M85AgAA Archived-At: Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 26 Sep 2016 09:15:02 -0000 Den 2016-09-26 kl. 10:48, skrev Harald Alvestrand: > Den 23. sep. 2016 10:56, skrev Magnus Westerlund: >> Hi, >> >> I think the use cases looks fairly covering. >> >> I want to add an alternative way of thinking on how the SDES item (MID, >> RID) related demultiplexing part is handled. So the RID and MID in RTP >> header extensions or in RTSP SDES packets results in these values being >> bound to the SSRC until further notice. So packets arriving without >> actual RTP header extensions can still be handled according to the SSRCs >> associated SDES items. From my perspective all the cases with MID and >> RID can be handled on a per packet basis rules without latching the SSRC >> to a specific receiver. Instead what is "latched" is the SDES values to >> the SSRC. Still at the point of change there needs to take the >> combination of SSRC and Seq into account to avoid miss routing packets. >> >> So my general handling algorithm would be this sequence: >> >> 1. Check if RTP header extensions update any SDES item for the SSRC. >> a. If they do, mark the Sequence number and keep the old SDES item as >> valid prior to this extended sequence number. >> >> 2. Determine the set of relevant SDES items that applies for this >> packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and >> RID. >> >> 3. Perform the demuxing algorithm > > I don't understand this as written. > When an RTP packet arrives before the RTCP packet containing SDES, we > can't latch to the content of the RTCP packet; we haven't seen it yet. So if neither RTP header extension nor RTCP SDES item with RID/MID for that SSRC has been received, then you don't have that information and you will have to either queue or drop that packet if the relation isn't otherwise clear through PT or SSRC signalling in SDP. > > You can, in theory, latch RID and MID for the SSRC to the values in the > SDES packet you haven't seen yet, but that seems somewhat backwards. > > The problematic sequence is: > > 1) RTP packet(s) with header extensions > 2) RTP packet(s) without header extensions > 3) SDES RTCP packet I don't see why the above is problematic. Step one gives you the SDES item for that SSRC. Thus in step 2 one knows that the SSRC has the MID/RID value that you need. I don't understand why you are not binding the SDES info from the RTP header extension to the SSRC. > > (I'm assuming that we require consistency between SDES and RTP header > extensions. > What do we do if they're inconsistent?) So, the RTP header extension is the SDES item also. So if one gets another SDES item value, then one should update, however one needs to prevent flapping so one needs to figure out which of the RTCP and RTP header extension was sent last. See Section 4.2.6 in RFC 7941. 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 Sep 26 02:35:07 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7757D12B0CC for ; Mon, 26 Sep 2016 02:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 aiCE72fIjjYC for ; Mon, 26 Sep 2016 02:35:04 -0700 (PDT) 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 D672B12B0C9 for ; Mon, 26 Sep 2016 02:35:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 497627CABFF; Mon, 26 Sep 2016 11:35:02 +0200 (CEST) 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 XmmpzrUOZuSv; Mon, 26 Sep 2016 11:35:01 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:41d2:e07c:b0d5:11f3] (unknown [IPv6:2001:470:de0a:1:41d2:e07c:b0d5:11f3]) by mork.alvestrand.no (Postfix) with ESMTPSA id 013CC7CABFE; Mon, 26 Sep 2016 11:35:00 +0200 (CEST) To: Magnus Westerlund , rtcweb@ietf.org References: <66CB8C7B-56D1-4AC9-B0F8-4F1689E2CA89@vidyo.com> <07afeaa4-06fb-b6a9-b2d7-f944b471fde1@ericsson.com> <949bdcde-b24d-f2d4-e855-91424b2be30a@alvestrand.no> <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> From: Harald Alvestrand Message-ID: <2a67053c-bd75-cc85-eeba-e57f64667ab1@alvestrand.no> Date: Mon, 26 Sep 2016 11:35:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <4837a71e-0e54-29d0-0a96-75f3fdbc7e1b@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 26 Sep 2016 09:35:06 -0000 Den 26. sep. 2016 11:14, skrev Magnus Westerlund: > Den 2016-09-26 kl. 10:48, skrev Harald Alvestrand: >> Den 23. sep. 2016 10:56, skrev Magnus Westerlund: >>> Hi, >>> >>> I think the use cases looks fairly covering. >>> >>> I want to add an alternative way of thinking on how the SDES item (MID, >>> RID) related demultiplexing part is handled. So the RID and MID in RTP >>> header extensions or in RTSP SDES packets results in these values being >>> bound to the SSRC until further notice. So packets arriving without >>> actual RTP header extensions can still be handled according to the SSRCs >>> associated SDES items. From my perspective all the cases with MID and >>> RID can be handled on a per packet basis rules without latching the SSRC >>> to a specific receiver. Instead what is "latched" is the SDES values to >>> the SSRC. Still at the point of change there needs to take the >>> combination of SSRC and Seq into account to avoid miss routing packets. >>> >>> So my general handling algorithm would be this sequence: >>> >>> 1. Check if RTP header extensions update any SDES item for the SSRC. >>> a. If they do, mark the Sequence number and keep the old SDES item as >>> valid prior to this extended sequence number. >>> >>> 2. Determine the set of relevant SDES items that applies for this >>> packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and >>> RID. >>> >>> 3. Perform the demuxing algorithm >> >> I don't understand this as written. >> When an RTP packet arrives before the RTCP packet containing SDES, we >> can't latch to the content of the RTCP packet; we haven't seen it yet. > > So if neither RTP header extension nor RTCP SDES item with RID/MID for > that SSRC has been received, then you don't have that information and > you will have to either queue or drop that packet if the relation isn't > otherwise clear through PT or SSRC signalling in SDP. > >> >> You can, in theory, latch RID and MID for the SSRC to the values in the >> SDES packet you haven't seen yet, but that seems somewhat backwards. >> >> The problematic sequence is: >> >> 1) RTP packet(s) with header extensions >> 2) RTP packet(s) without header extensions >> 3) SDES RTCP packet > > I don't see why the above is problematic. Step one gives you the SDES > item for that SSRC. Thus in step 2 one knows that the SSRC has the > MID/RID value that you need. > > I don't understand why you are not binding the SDES info from the RTP > header extension to the SSRC. OK, I had missed the change of the RID header extension from being its own header extension to being a component of the SDES header extension only. Then it all makes sense! Thanks! > >> >> (I'm assuming that we require consistency between SDES and RTP header >> extensions. >> What do we do if they're inconsistent?) > > So, the RTP header extension is the SDES item also. So if one gets > another SDES item value, then one should update, however one needs to > prevent flapping so one needs to figure out which of the RTCP and RTP > header extension was sent last. See Section 4.2.6 in RFC 7941. > > 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 Sep 26 08:01:06 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3CA12B2CA for ; Mon, 26 Sep 2016 08:01:04 -0700 (PDT) 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 FBDgVU9lngBv for ; Mon, 26 Sep 2016 08:01:00 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 710A512B2B4 for ; Mon, 26 Sep 2016 08:00:39 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w84so156634895wmg.1 for ; Mon, 26 Sep 2016 08:00:39 -0700 (PDT) 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=lfbV7gaOpDJIT0YPyWoE4sQ9awyZ0jJW3SiK0zIWUGI=; b=bAmaQ1q53sCMJzPhOFuW5EgRcpvjHztfU/9eXZAr30tESPGfIDkQsN3i1Wta8tYCdR yjOvZgrPQ/Xov9UE2Bvx1V924Z5+ikbRqyhbRShl9X5EDpac5AdkEJYjW1+kCWvB8T0q 5TPbcVX+jnISnqIqt51ukF4FvumKgMJd8WGyWLKVM4Ns5I7wqa6AxWi8RXxbjAyaVxUB imPboK7rS7SbN6+iwPQ59lJ1Rp59FUDJMII+UmfNd5EE9oRPfEmhsozghNRUHbMTWhfh sk3p2jWRhbyw1L74O5umx9bQzgasNtqq3sWc447RrYMZ3BeouXTk0heAHAThRkVBOsqy dGhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lfbV7gaOpDJIT0YPyWoE4sQ9awyZ0jJW3SiK0zIWUGI=; b=BKHHFJALDSDiDH27oMyHb/qC0EywvJt2aLpNZkA90IwVwojQDTYqwsHMGXCd7S84Zo wUCG+wbIcSoRVNgnJRfIbKMw60j+aQpb95w8wPN+5GCuRKi9kZGUZhgd5FzyA3Ovu86F LpSV3G8apFQ9BgmABWcr2sPpX9bUqPFcCc3sGXmucC7urtYcOh8ztCwW5mwwWA7j523f cOwx7lBJFIuQE5q+9T6GS7z9Xiei2YVSFt41u582rlaTvtK5aSTOuqK4GlKdoUmMzCbj l5jvUCuj7UaoGx6a5nbaN1PngPqbsu5EZNbFEi8GPJge50wFRzUdfn+WGl1RQRGxbLYE 4XQQ== X-Gm-Message-State: AE9vXwPcjt9fQ5sV2KMPfrPAKSqeslLCgCFuEjIhlzDFCF/sKB0j43gFGTNW30yI2WJO9ZmiSh6y8lXm5X8bxw== X-Received: by 10.194.148.145 with SMTP id ts17mr18609756wjb.91.1474902037989; Mon, 26 Sep 2016 08:00:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.146.78 with HTTP; Mon, 26 Sep 2016 08:00:17 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 26 Sep 2016 17:00:17 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: RTCWeb IETF , Robin Raymond Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 26 Sep 2016 15:01:05 -0000 Hi, sorry for the late response. All my concerns will be focused on the SFU scenario in which a peer/client receives multiple streams/tracks from many participants over a single DTLS transport. 2016-09-16 0:18 GMT+02:00 Cullen Jennings : > =E2=80=9CCoke Classic Example=E2=80=9D > The PT are all unique. The SSRC change. There is no RID, MID, FEC, or RTX= . > The packets get delivered to the thing with the matching PT. If multiple RtpReceivers are receiving audio tracks with same PT over the same transport (SFU scenario) this algorithm will fail since, most probably, all those RtpReceivers expect the same PT value for the same codec. SSRC or MID is required here. --=20 I=C3=B1aki Baz Castillo From nobody Mon Sep 26 09:24:04 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC8512B237 for ; Mon, 26 Sep 2016 09:24:03 -0700 (PDT) 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 jJHxIr8uvFnC for ; Mon, 26 Sep 2016 09:24:02 -0700 (PDT) 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 DC32B12B226 for ; Mon, 26 Sep 2016 09:24:01 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id z126so63223841vkd.0 for ; Mon, 26 Sep 2016 09:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+N/ZJz4DSfhGmX/MT2l6JSlxC+/HzI5vZsZxC9UBWDI=; b=Y7YbQRTSQE8X4vHYKsIqgMwfhavavR7OGRlYFKc3MaeErukShaXjY9cj+ZbTsQEFza 0rt35cLZiP4XLGKKdyyKBIK7pj7r1pnANNOxav5PmlShImHysdhkA7PPwWWkHvR7c8AF Ub0E4CddYdURvZq6bQPkDC7/k5Xdz5eDvFPJ/DqOfBi8hYbvxfjduZTHbPgI/aW451FU J6cdXCR65tm2ak4RQvPK5jqkg0pEED0yo8vHhkQRrYjy0DwQ6xQvAMhgHD+O7syaH3GS dKV6mJO6+Z0yz2qKbVPMIvmpFJb7vb95xkWLYKlMBcudLiS4qMH+s0fxcEOmaet7I1dc KbRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+N/ZJz4DSfhGmX/MT2l6JSlxC+/HzI5vZsZxC9UBWDI=; b=V4gsWdxJ8+XUGKT5iHm8CA02wdgc5XCeHB9zJKjfU+hBRkyzH+811HmLk5iikmxRYX bu8yGuxVqv3GFQCyId8KKWalq3oE3iLiHasnIIS9IsSU/0EXwynISNDm/d1Eg2QPYO/Q JZpdIhcs9rUIPs2r1Y+PyWfk4I1MLMKldTMidHbCXuPubeCDJ45Trq6/X+009YQtPLk4 o0vo4PI34Zm0UCGdFdyMJOs5C8efApNP200AaChDc9oehFpeEYG9ohHvkf2wYrNB7oX+ VpTg/Q8ifp8mR889X4+qYbw0xDHaaKNKYXU2c+ZDWCEbci+g0UYeKL6DfyYalvaWYFIU 20oQ== X-Gm-Message-State: AA6/9Rl+yqvygvhwOMlOfi3vSxuBH4cENaSRUFDRpvHTqYVbQp6qmowrslbkiaONaYaWu3xaeooko9yFzB43UA== X-Received: by 10.31.220.68 with SMTP id t65mr9613582vkg.143.1474907039317; Mon, 26 Sep 2016 09:23:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.198 with HTTP; Mon, 26 Sep 2016 09:23:38 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Mon, 26 Sep 2016 12:23:38 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=94eb2c07bb1827c5ef053d6b8efc Archived-At: Cc: RTCWeb IETF , Robin Raymond Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 26 Sep 2016 16:24:04 -0000 --94eb2c07bb1827c5ef053d6b8efc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inaki said: "If multiple RtpReceivers are receiving audio tracks with same PT over the same transport (SFU scenario) this algorithm will fail since, most probably, all those RtpReceivers expect the same PT value for the same codec. SSRC or MID is required here." [BA] The above case corresponds to a separate test case. The difficult part of developing the routing rules is figuring out all the test cases as well as being able to easily run them against a proposed algorithm (to avoid regressions when making changes). Is there any code in your SFU project that might help us with that? On Mon, Sep 26, 2016 at 11:00 AM, I=C3=B1aki Baz Castillo w= rote: > Hi, sorry for the late response. All my concerns will be focused on > the SFU scenario in which a peer/client receives multiple > streams/tracks from many participants over a single DTLS transport. > > > 2016-09-16 0:18 GMT+02:00 Cullen Jennings : > > =E2=80=9CCoke Classic Example=E2=80=9D > > The PT are all unique. The SSRC change. There is no RID, MID, FEC, or > RTX. > > The packets get delivered to the thing with the matching PT. > > If multiple RtpReceivers are receiving audio tracks with same PT over > the same transport (SFU scenario) this algorithm will fail since, most > probably, all those RtpReceivers expect the same PT value for the same > codec. SSRC or MID is required here. > > > -- > I=C3=B1aki Baz Castillo > > --94eb2c07bb1827c5ef053d6b8efc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inaki said:=C2=A0

"If multiple RtpReceivers are receiving audio tracks with = same PT over
the same transpor= t (SFU scenario) this algorithm will fail since, most
probably, all those RtpRec= eivers expect the same PT value for the same
codec. SSRC or MID is required= here."

[BA] The above case correspond= s to a separate test case.=C2=A0 The difficult part of developing the routi= ng rules is figuring out all the test cases as well as being able to easily= run them against a proposed algorithm (to avoid regressions when making ch= anges).=C2=A0

Is there any code in your SFU projec= t that might help us with that?




On Mon, Sep 26, 2016 at 11:00 AM, I=C3=B1aki Baz Castillo <ibc@alia= x.net> wrote:
Hi, sorry for= the late response. All my concerns will be focused on
the SFU scenario in which a peer/client receives multiple
streams/tracks from many participants over a single DTLS transport.


2016-09-16 0:18 GMT+02:00 Cullen Jennings <fluffy@iii.ca>:
> =E2=80=9CCoke Classic Example=E2=80=9D
> The PT are all unique. The SSRC change. There is no RID, MID, FEC, or = RTX.
> The packets get delivered to the thing with the matching PT.

If multiple RtpReceivers are receiving audio tracks with same PT ove= r
the same transport (SFU scenario) this algorithm will fail since, most
probably, all those RtpReceivers expect the same PT value for the same
codec. SSRC or MID is required here.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

--94eb2c07bb1827c5ef053d6b8efc-- From nobody Mon Sep 26 17:34:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108B912B35B for ; Mon, 26 Sep 2016 17:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 sHVe3D-bTpkv for ; Mon, 26 Sep 2016 17:34:56 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 3D00D12B357 for ; Mon, 26 Sep 2016 17:34:56 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id 93so91992289qtg.2 for ; Mon, 26 Sep 2016 17:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=5789/hnShw+do19q/VBIvuXeU+zO0ncLdv2uVl3Bt5Q=; b=Brr4WsfqFAUZK4nAlNIGrqrSx3/t2lQJwBhP/lg6caATNFyq3u91CykdN92b8KUdHo fKPBWTOD+FM9K3BOs/vkBZqlt4618RDVjh4Xt5AARWaM4PVHyBW1Pugr0vJD3FCSyaZK XVTK98suEdtsmDzcQBL5sbR9udAum7rHX3Ijc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=5789/hnShw+do19q/VBIvuXeU+zO0ncLdv2uVl3Bt5Q=; b=PhSbADK4vLpgOSQJdM4j1ShBW93iTKJ5h9ILJiaGR9neMpRx0NcJTFR0aQrsS4HKIy 4ujibEcCR0cbWUdxqX30SZyGOqUww0zTHlzGiIj8eLo8gmC4VyP7ThfuEJEgPuPeFGA4 tKAcycKbXZX/Ph31CMJp6NUipKK+BnMGvf15WMOCK9SvqBKTdZNDK4bRlEGw/gTpTvwP fE8GY7v/JLp3DWeQYL8Nviu14gtQi2EnFQkq/fIAy41MpePBeLGN22fc+2t+FfDCgVbs 0qDnRWxi0wnvx1LvRBVtkHD3KmUVhvUtXV7z+iIfpEFZKCD9zFgxuwDZIg+GIiBzdBHW U96w== X-Gm-Message-State: AA6/9RmWjcj9dFsWwnstuuLlTuFPC1Gbils0rvFDAvWBQsbta4+yvMQo8IrSYMMLY6CA0Q== X-Received: by 10.237.56.170 with SMTP id k39mr24346923qte.138.1474936494656; Mon, 26 Sep 2016 17:34:54 -0700 (PDT) Received: from [172.16.0.112] ([96.231.223.33]) by smtp.gmail.com with ESMTPSA id j67sm13002566qkf.41.2016.09.26.17.34.51 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 17:34:52 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2E487D60-FDB8-4FAC-8E4B-A254C9DBE628@sn3rd.com> Date: Mon, 26 Sep 2016 20:34:48 -0400 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] JSEP! JSEP! Read All About It! 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, 27 Sep 2016 00:34:58 -0000 The authors have done one heck of a job to get us JSEP -16: = https://github.com/rtcweb-wg/jsep. Looking at the repo=E2=80=99s pulse, = they merged 20 PRs and closed 21 issues in the last month: = https://github.com/rtcweb-wg/jsep/pulse/monthly. Gents, thanks for = doing your part. So, now that everybody is back from TPAC it=E2=80=99s time for everybody = else to get their reviews in. Comments and PRs welcome! Thanks! spt From nobody Tue Sep 27 08:03:35 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BF012B243 for ; Tue, 27 Sep 2016 08:03:33 -0700 (PDT) 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 HWPzVsqBhXo5 for ; Tue, 27 Sep 2016 08:03:29 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 31D9C12B262 for ; Tue, 27 Sep 2016 08:03:00 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id d66so29070508wmf.0 for ; Tue, 27 Sep 2016 08:03:00 -0700 (PDT) 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=uuXrPN4NmmRMD49CBTQlE6GOpsIJ9WK/m3cn3LB3CdQ=; b=gPu6XrzezhgIpwIWQxY8UO9egxzxcQpicLY7gVJ47KRj16bBQBJ+HKMTumDDT/1FSc tzux8kyn6unbiDIbhH4dgPBd0Pngb+Ef58RxLK51utWbHPtGSKfhJIs7ZXEaiDRGIMnv hQJBRoaZ6fY2X8tH5r+L+CIa6wxXT4haLH5xZD/CDL3JWcAyaEXpcg8mx22kehOaABW7 9ulkmcC6hI4bnAu+gVFcCMQuTJmIikn36n+win6pccMzdJMEHsUU36/RPC342zCrn7jT Rs0kgaKxlssGkbw9CVFe6e0mdgtS20R6t5BbXYcZ9l4zXmRGS0PZGM3VPmw2ubLCv1QA uW5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uuXrPN4NmmRMD49CBTQlE6GOpsIJ9WK/m3cn3LB3CdQ=; b=P3ws7Toabb4N8mVh6kp8L1BMhY7hU7agTBmkfYZZt5wiK2pGSKY/vjsmsetowKSixw 4PO/jUzkhDOVy0r0yeNEh1rwyvohtYhiosnkS51E/VF9yRuhznEHrWsUudUOZx6F4brz 48ZQd3P6VfbXPe7iBh3u9Jhn57YVLnXLoKzZWe+JpC5NVrRPxuMoKkLlQP3WjS0EQ+71 G6s1WCoH9se5nvf2wIokiAMPig6/mJvAelp9var0dW10U+nFBdSovdb6Um8rmCzpr8Jz nUEEHJKzU165p4hX98mLaD6AZs22rQY9kI7SPRaXQuFdWzFwZqCzEdHgbre/pqU7dqE/ MGSQ== X-Gm-Message-State: AA6/9RlZWHZRpUdWKm/6Ofdt6sRnPyHF0p0T1Oa7z5UMP8ja2C4TIygYsVvmbGTOfeD1puamWG9wrRymSUdrUQ== X-Received: by 10.28.211.10 with SMTP id k10mr3588611wmg.16.1474988578696; Tue, 27 Sep 2016 08:02:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.146.78 with HTTP; Tue, 27 Sep 2016 08:02:38 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 27 Sep 2016 17:02:38 +0200 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: RTCWeb IETF , Robin Raymond Subject: Re: [rtcweb] JSEP: RTP demux algorithms 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, 27 Sep 2016 15:03:34 -0000 2016-09-26 18:23 GMT+02:00 Bernard Aboba : > Is there any code in your SFU project that might help us with that? Currently it just routes based on SSRC and PT values (as signaled in the SDP or ORTC receive() method). In fact I'm waiting for all this stuff to be clarified and normalized in order to implement it :) --=20 I=C3=B1aki Baz Castillo From nobody Wed Sep 28 00:35:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F6E12B08D; Wed, 28 Sep 2016 00:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 cbrfL-r56hDs; Wed, 28 Sep 2016 00:35:47 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 7EE8312B076; Wed, 28 Sep 2016 00:35:44 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bp9P4-0005YI-3y; Wed, 28 Sep 2016 09:35:42 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bp9P3-00036a-Gq; Wed, 28 Sep 2016 09:35:42 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 09:35:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 46759 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.2, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.203, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8B053BA0AEB87CE0663F46E8EE81A067AF9CCD7A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -61 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 11221 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: RTCWeb IETF , The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-rtcweb-transports-15=3A_=28with_COMMENT=29?= 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, 28 Sep 2016 07:35:50 -0000 Dear all, Sorry for re-opening this discussion at such a late stage, but, by way = of agreeing with Mirja's comment below that the document should say more = about congestion control, I still find it very strange that the text = does not cite draft-ietf-rmcat-coupled-cc. Mirja mentions draft-ietf-rmcat-cc-requirements-09, and I agree that = this should be cited, but this requirements document is also generic and = does not provide much concrete guidance on how to implement things - so = I'd say it's not enough. draft-ietf-rmcat-coupled-cc-03 is now in WGLC and has so far only = received editorial comments. We have lots of proof that this mechanism = works very well; whenever it's known that flows share a bottleneck (as = is the case for all rtcweb streams between the same hosts), this allows = to precisely divide bandwidth among flows based on priorities, and it = yields overall lower latency due to reduced on-the-wire competition = (well in line with the first requirement laid out in = draft-ietf-rmcat-cc-requirements-09). Using the DSCP may protect against = other traffic but it's also just hoping for routers to do the right = thing. I think that possibilities should be laid out to people intending = to implement rtcweb. Maybe the goal was to avoid a dependency on specific RMCAT congestion = controls; I can understand that, but the algorithm in = draft-ietf-rmcat-coupled-cc, while containing sections explaining how to = apply it to NADA and GCC, is pretty generic and can be quite easily = adapted for other controls (as we've successfully done). Accordingly, = the draft presents the algorithm as the generic thing that it is. I brought this missing citation issue up in the past, and it was = addressed, but IMO very weakly: *** > The issue is addressed, but not as you suggested - after taking advice > from the chairs, I did not reference "coupled" directly, instead > choosing to reference RFC 7657 and mentioning that it contained advice > on congestion control. >=20 > I also changed one occurence of "the same congestion controller" to = "the > same congstion control regime", so that this document was neutral = about > whether there was one or multiple congestion controllers. >=20 > Details at https://github.com/rtcweb-wg/rtcweb-transport/issues/16 *** Specifically, let us consider this statement at this URL: *** @fluffy I regard the mention of coupled CC as mostly "pointless but = harmless". The initial decision to mention a single controller was to = mention only the most restricted case; if the chairs think extending = this to coupled CC is OK, I don't have any strong reason to push back = against it. The extensive use of "common (coupled)" in RFC 7657 is (in my opinion) a = mistake; these two are not the same thing, and I can't see that RFC 7657 = is really clear about the difference. *** Why is it pointless to tell folks who implement rtcweb protocols that = this is a possible mechanism to use, and point them directly at it? I also don't understand the "mistake" about the extensive use of "common = (coupled)" in RFC 7657: the outcome is almost identical (again, we have = lots of graphs using various congestion controls to prove my point), so = what's the problem? To me, it's very strange and inconsistent that = draft-ietf-rtcweb-transports-15 points at draft-ietf-tsvwg-rtcweb-qos = for concrete implementation guidance, but doesn't point at = draft-ietf-rmcat-coupled-cc for the same; it talks about the possibility = of having "multiple streams that are congestion-controlled under the = same congestion control regime" but it doesn't give any hint about how = to do that (which is what a pointer to draft-ietf-rmcat-coupled-cc would = achieve). Cheers, Michael > On 04 Aug 2016, at 15:58, Mirja Kuehlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-rtcweb-transports-15: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for updating! >=20 > Leaving it to this comment: > Based on the TSV review I agree that this document (named "Transports = for > WebRTC") should say more about congestion control. The TSV reviewer > (Thanks Allison!) proposes to refer > draft-ietf-avtcore-rtp-circuit-breakers-17 and > draft-ietf-rmcat-cc-requirements-09. I would even appreciate to have a=20= > sentence that says that congestion control and a circuit breaker is > mandated in draft-ietf-rtcweb-rtp-usage-26. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Sep 30 02:42:05 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C261F12B08E; Fri, 30 Sep 2016 02:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 gjX9wFoIJ--9; Fri, 30 Sep 2016 02:41:53 -0700 (PDT) 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 8A7E512B13E; Fri, 30 Sep 2016 02:41:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0B2B67CACEB; Fri, 30 Sep 2016 11:41:52 +0200 (CEST) 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 LCU544sON7GU; Fri, 30 Sep 2016 11:41:49 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:642c:3408:9593:3581] (unknown [IPv6:2001:470:de0a:1:642c:3408:9593:3581]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9112B7CACDE; Fri, 30 Sep 2016 11:41:49 +0200 (CEST) To: Michael Welzl , Mirja Kuehlewind References: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> From: Harald Alvestrand Message-ID: Date: Fri, 30 Sep 2016 11:41:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: RTCWeb IETF , The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-rtcweb-transports-15=3A_=28with_COMMENT=29?= 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, 30 Sep 2016 09:41:57 -0000 Wanting to ask .... do you have commitment from some of the browser vendors that they intend to add -coupled to their congestion control code? That would go a long way towards allaying my fear that this would be another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement. Den 28. sep. 2016 09:35, skrev Michael Welzl: > Dear all, > > Sorry for re-opening this discussion at such a late stage, but, by way of agreeing with Mirja's comment below that the document should say more about congestion control, I still find it very strange that the text does not cite draft-ietf-rmcat-coupled-cc. > > Mirja mentions draft-ietf-rmcat-cc-requirements-09, and I agree that this should be cited, but this requirements document is also generic and does not provide much concrete guidance on how to implement things - so I'd say it's not enough. > > draft-ietf-rmcat-coupled-cc-03 is now in WGLC and has so far only received editorial comments. We have lots of proof that this mechanism works very well; whenever it's known that flows share a bottleneck (as is the case for all rtcweb streams between the same hosts), this allows to precisely divide bandwidth among flows based on priorities, and it yields overall lower latency due to reduced on-the-wire competition (well in line with the first requirement laid out in draft-ietf-rmcat-cc-requirements-09). Using the DSCP may protect against other traffic but it's also just hoping for routers to do the right thing. I think that possibilities should be laid out to people intending to implement rtcweb. > > Maybe the goal was to avoid a dependency on specific RMCAT congestion controls; I can understand that, but the algorithm in draft-ietf-rmcat-coupled-cc, while containing sections explaining how to apply it to NADA and GCC, is pretty generic and can be quite easily adapted for other controls (as we've successfully done). Accordingly, the draft presents the algorithm as the generic thing that it is. > > I brought this missing citation issue up in the past, and it was addressed, but IMO very weakly: > > *** >> The issue is addressed, but not as you suggested - after taking advice >> from the chairs, I did not reference "coupled" directly, instead >> choosing to reference RFC 7657 and mentioning that it contained advice >> on congestion control. >> >> I also changed one occurence of "the same congestion controller" to "the >> same congstion control regime", so that this document was neutral about >> whether there was one or multiple congestion controllers. >> >> Details at https://github.com/rtcweb-wg/rtcweb-transport/issues/16 > *** > > Specifically, let us consider this statement at this URL: > > *** > @fluffy I regard the mention of coupled CC as mostly "pointless but harmless". The initial decision to mention a single controller was to mention only the most restricted case; if the chairs think extending this to coupled CC is OK, I don't have any strong reason to push back against it. > > The extensive use of "common (coupled)" in RFC 7657 is (in my opinion) a mistake; these two are not the same thing, and I can't see that RFC 7657 is really clear about the difference. > *** > > Why is it pointless to tell folks who implement rtcweb protocols that this is a possible mechanism to use, and point them directly at it? > I also don't understand the "mistake" about the extensive use of "common (coupled)" in RFC 7657: the outcome is almost identical (again, we have lots of graphs using various congestion controls to prove my point), so what's the problem? > > To me, it's very strange and inconsistent that draft-ietf-rtcweb-transports-15 points at draft-ietf-tsvwg-rtcweb-qos for concrete implementation guidance, but doesn't point at draft-ietf-rmcat-coupled-cc for the same; it talks about the possibility of having "multiple streams that are congestion-controlled under the same congestion control regime" but it doesn't give any hint about how to do that (which is what a pointer to draft-ietf-rmcat-coupled-cc would achieve). > > Cheers, > Michael > > > >> On 04 Aug 2016, at 15:58, Mirja Kuehlewind wrote: >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-rtcweb-transports-15: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for updating! >> >> Leaving it to this comment: >> Based on the TSV review I agree that this document (named "Transports for >> WebRTC") should say more about congestion control. The TSV reviewer >> (Thanks Allison!) proposes to refer >> draft-ietf-avtcore-rtp-circuit-breakers-17 and >> draft-ietf-rmcat-cc-requirements-09. I would even appreciate to have a >> sentence that says that congestion control and a circuit breaker is >> mandated in draft-ietf-rtcweb-rtp-usage-26. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Sep 30 03:31:31 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6239C12B25E; Fri, 30 Sep 2016 03:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] 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 JyZQrVAhh_nM; Fri, 30 Sep 2016 03:31:27 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 BCE1E12B261; Fri, 30 Sep 2016 03:31:26 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bpv6C-0007yw-Fo; Fri, 30 Sep 2016 12:31:24 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.12]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bpv6B-0006hh-La; Fri, 30 Sep 2016 12:31:24 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Fri, 30 Sep 2016 12:31:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <247D0AC1-B726-4C65-868F-66C920C4A55A@ifi.uio.no> References: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 46843 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 485FEAE330B43A673117B7A3E6EE2876C66713B8 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 203 max/h 9 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: RTCWeb IETF , Mirja Kuehlewind , The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-rtcweb-transports-15=3A_=28with_COMMENT=29?= 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, 30 Sep 2016 10:31:30 -0000 > On 30. sep. 2016, at 11.41, Harald Alvestrand = wrote: >=20 > Wanting to ask .... >=20 > do you have commitment from some of the browser vendors that they = intend > to add -coupled to their congestion control code? No committment, but I did have some hope that you guys at Google would = be interested? Stefan was interested in coupling the data channel with the media = channel, which is probably a straightforward way of adapting our = coupling algorithm. We=E2=80=99re going to work on this code ourselves; we already have = preliminary code on coupling + shared bottleneck detection in Chromium, = but this is work in progress that was interrupted for a year due to a = contract that let us focus on coupling TCP for a while (which also works = very well, BTW; we=E2=80=99ll provide an update at ICCRG in Seoul). So = we=E2=80=99re (well: Safiqul is) just about to get back to it. > That would go a long way towards allaying my fear that this would be > another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement. I think what I=E2=80=99m asking for is a far cry from a MUST. It=E2=80=99s merely about putting a reference there such that = implementers see both possibilities (coupling and/or dscp), not only one = (dscp). Cheers, Michael >=20 >=20 > Den 28. sep. 2016 09:35, skrev Michael Welzl: >> Dear all, >>=20 >> Sorry for re-opening this discussion at such a late stage, but, by = way of agreeing with Mirja's comment below that the document should say = more about congestion control, I still find it very strange that the = text does not cite draft-ietf-rmcat-coupled-cc. >>=20 >> Mirja mentions draft-ietf-rmcat-cc-requirements-09, and I agree that = this should be cited, but this requirements document is also generic and = does not provide much concrete guidance on how to implement things - so = I'd say it's not enough. >>=20 >> draft-ietf-rmcat-coupled-cc-03 is now in WGLC and has so far only = received editorial comments. We have lots of proof that this mechanism = works very well; whenever it's known that flows share a bottleneck (as = is the case for all rtcweb streams between the same hosts), this allows = to precisely divide bandwidth among flows based on priorities, and it = yields overall lower latency due to reduced on-the-wire competition = (well in line with the first requirement laid out in = draft-ietf-rmcat-cc-requirements-09). Using the DSCP may protect against = other traffic but it's also just hoping for routers to do the right = thing. I think that possibilities should be laid out to people intending = to implement rtcweb. >>=20 >> Maybe the goal was to avoid a dependency on specific RMCAT congestion = controls; I can understand that, but the algorithm in = draft-ietf-rmcat-coupled-cc, while containing sections explaining how to = apply it to NADA and GCC, is pretty generic and can be quite easily = adapted for other controls (as we've successfully done). Accordingly, = the draft presents the algorithm as the generic thing that it is. >>=20 >> I brought this missing citation issue up in the past, and it was = addressed, but IMO very weakly: >>=20 >> *** >>> The issue is addressed, but not as you suggested - after taking = advice >>> from the chairs, I did not reference "coupled" directly, instead >>> choosing to reference RFC 7657 and mentioning that it contained = advice >>> on congestion control. >>>=20 >>> I also changed one occurence of "the same congestion controller" to = "the >>> same congstion control regime", so that this document was neutral = about >>> whether there was one or multiple congestion controllers. >>>=20 >>> Details at https://github.com/rtcweb-wg/rtcweb-transport/issues/16 >> *** >>=20 >> Specifically, let us consider this statement at this URL: >>=20 >> *** >> @fluffy I regard the mention of coupled CC as mostly "pointless but = harmless". The initial decision to mention a single controller was to = mention only the most restricted case; if the chairs think extending = this to coupled CC is OK, I don't have any strong reason to push back = against it. >>=20 >> The extensive use of "common (coupled)" in RFC 7657 is (in my = opinion) a mistake; these two are not the same thing, and I can't see = that RFC 7657 is really clear about the difference. >> *** >>=20 >> Why is it pointless to tell folks who implement rtcweb protocols that = this is a possible mechanism to use, and point them directly at it? >> I also don't understand the "mistake" about the extensive use of = "common (coupled)" in RFC 7657: the outcome is almost identical (again, = we have lots of graphs using various congestion controls to prove my = point), so what's the problem? >>=20 >> To me, it's very strange and inconsistent that = draft-ietf-rtcweb-transports-15 points at draft-ietf-tsvwg-rtcweb-qos = for concrete implementation guidance, but doesn't point at = draft-ietf-rmcat-coupled-cc for the same; it talks about the possibility = of having "multiple streams that are congestion-controlled under the = same congestion control regime" but it doesn't give any hint about how = to do that (which is what a pointer to draft-ietf-rmcat-coupled-cc would = achieve). >>=20 >> Cheers, >> Michael >>=20 >>=20 >>=20 >>> On 04 Aug 2016, at 15:58, Mirja Kuehlewind = wrote: >>>=20 >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-rtcweb-transports-15: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Thanks for updating! >>>=20 >>> Leaving it to this comment: >>> Based on the TSV review I agree that this document (named = "Transports for >>> WebRTC") should say more about congestion control. The TSV reviewer >>> (Thanks Allison!) proposes to refer >>> draft-ietf-avtcore-rtp-circuit-breakers-17 and >>> draft-ietf-rmcat-cc-requirements-09. I would even appreciate to have = a=20 >>> sentence that says that congestion control and a circuit breaker is >>> mandated in draft-ietf-rtcweb-rtp-usage-26. >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 From nobody Fri Sep 30 03:50:27 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE41A12B0B5 for ; Fri, 30 Sep 2016 03:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 g-AUYFZiI29X for ; Fri, 30 Sep 2016 03:50:23 -0700 (PDT) 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 AE19D12B28D for ; Fri, 30 Sep 2016 03:50:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D295C7CACF3 for ; Fri, 30 Sep 2016 12:50:20 +0200 (CEST) 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 1jh3M1d_Ruxf for ; Fri, 30 Sep 2016 12:50:19 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:642c:3408:9593:3581] (unknown [IPv6:2001:470:de0a:1:642c:3408:9593:3581]) by mork.alvestrand.no (Postfix) with ESMTPSA id BA9467CACEE for ; Fri, 30 Sep 2016 12:50:19 +0200 (CEST) To: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: Date: Fri, 30 Sep 2016 12:50:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Post-IESG fixes to -transport 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, 30 Sep 2016 10:50:26 -0000 I now (finally!) have a PR ready for fixing the still-open issues post-IESG. Here it is: https://github.com/rtcweb-wg/rtcweb-transport/pull/45 I'm holding off on submitting the draft until the chairs have had a day to consider Michael's note about -coupled-cc. Harald From nobody Fri Sep 30 04:00:18 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39FD12B2B5; Fri, 30 Sep 2016 04:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] 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 Bw0HtT2cJmut; Fri, 30 Sep 2016 04:00:14 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A09112B2AE; Fri, 30 Sep 2016 04:00:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4B7C27CACF3; Fri, 30 Sep 2016 13:00:12 +0200 (CEST) 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 Ez0k37C0Ahj4; Fri, 30 Sep 2016 12:59:52 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:642c:3408:9593:3581] (unknown [IPv6:2001:470:de0a:1:642c:3408:9593:3581]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8FE387CACEE; Fri, 30 Sep 2016 12:59:52 +0200 (CEST) To: Michael Welzl References: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> <247D0AC1-B726-4C65-868F-66C920C4A55A@ifi.uio.no> From: Harald Alvestrand Message-ID: <8995aea4-7016-bc93-e58c-c3a4d778c91d@alvestrand.no> Date: Fri, 30 Sep 2016 12:59:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <247D0AC1-B726-4C65-868F-66C920C4A55A@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: RTCWeb IETF , Mirja Kuehlewind , The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-rtcweb-transports-15=3A_=28with_COMMENT=29?= 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, 30 Sep 2016 11:00:17 -0000 Den 30. sep. 2016 12:31, skrev Michael Welzl: > >> On 30. sep. 2016, at 11.41, Harald Alvestrand wrote: >> >> Wanting to ask .... >> >> do you have commitment from some of the browser vendors that they intend >> to add -coupled to their congestion control code? > > No committment, but I did have some hope that you guys at Google would be interested? > Stefan was interested in coupling the data channel with the media channel, which is probably a straightforward way of adapting our coupling algorithm. > > We’re going to work on this code ourselves; we already have preliminary code on coupling + shared bottleneck detection in Chromium, but this is work in progress that was interrupted for a year due to a contract that let us focus on coupling TCP for a while (which also works very well, BTW; we’ll provide an update at ICCRG in Seoul). So we’re (well: Safiqul is) just about to get back to it. > > >> That would go a long way towards allaying my fear that this would be >> another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement. > > I think what I’m asking for is a far cry from a MUST. > It’s merely about putting a reference there such that implementers see both possibilities (coupling and/or dscp), not only one (dscp). > The DSCP section would be the wrong section for it anyway. References to -coupled should be in the "local prioritization" section (4.1). My worry about -coupled in the previous round is that it's a *specific* instance of coupled congestion controllers (and experimental-track). We don't yet know if it's *the* way. That said, I personally wouldn't worry too much about mentioning it, but it's a post-IESG change without IESG buy-in, so I'll want more authorization to do that. Harald From nobody Fri Sep 30 05:28:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B5E12B355; Fri, 30 Sep 2016 05:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] 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 hwIzAHkrSMJ1; Fri, 30 Sep 2016 05:28:23 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 811D612B341; Fri, 30 Sep 2016 05:28:23 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bpwvN-00048a-KB; Fri, 30 Sep 2016 14:28:21 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.12]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bpwvM-0007jF-Ry; Fri, 30 Sep 2016 14:28:21 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <8995aea4-7016-bc93-e58c-c3a4d778c91d@alvestrand.no> Date: Fri, 30 Sep 2016 14:28:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> <247D0AC1-B726-4C65-868F-66C920C4A55A@ifi.uio.no> <8995aea4-7016-bc93-e58c-c3a4d778c91d@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 10 sum msgs/h 2 total rcpts 46856 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 36A7E9F5CB191F20504B246BD479B5E4B71E0283 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 207 max/h 9 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: RTCWeb IETF , Mirja Kuehlewind , The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] =?windows-1252?q?Mirja_K=FChlewind=27s_No_Objection_on_d?= =?windows-1252?q?raft-ietf-rtcweb-transports-15=3A_=28with_COMMENT=29?= 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, 30 Sep 2016 12:28:26 -0000 > On 30. sep. 2016, at 12.59, Harald Alvestrand = wrote: >=20 > Den 30. sep. 2016 12:31, skrev Michael Welzl: >>=20 >>> On 30. sep. 2016, at 11.41, Harald Alvestrand = wrote: >>>=20 >>> Wanting to ask .... >>>=20 >>> do you have commitment from some of the browser vendors that they = intend >>> to add -coupled to their congestion control code? >>=20 >> No committment, but I did have some hope that you guys at Google = would be interested? >> Stefan was interested in coupling the data channel with the media = channel, which is probably a straightforward way of adapting our = coupling algorithm. >>=20 >> We=92re going to work on this code ourselves; we already have = preliminary code on coupling + shared bottleneck detection in Chromium, = but this is work in progress that was interrupted for a year due to a = contract that let us focus on coupling TCP for a while (which also works = very well, BTW; we=92ll provide an update at ICCRG in Seoul). So we=92re = (well: Safiqul is) just about to get back to it. >>=20 >>=20 >>> That would go a long way towards allaying my fear that this would be >>> another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement. >>=20 >> I think what I=92m asking for is a far cry from a MUST. >> It=92s merely about putting a reference there such that implementers = see both possibilities (coupling and/or dscp), not only one (dscp). >>=20 >=20 > The DSCP section would be the wrong section for it anyway. >=20 > References to -coupled should be in the "local prioritization" section > (4.1). I agree. I didn=92t mean for this to be in the same section. > My worry about -coupled in the previous round is that it's a = *specific* > instance of coupled congestion controllers (and experimental-track). >=20 > We don't yet know if it's *the* way. Understood - but: 1) draft-ietf-rmcat-coupled-cc doesn=92t say that the algorithm in it is = *the* way. I believe it correctly acknowledges that you could e.g. also = have a single congestion control instance for everything ("congestion = manager=94 style coupling). Both implementations have their pro=92s and = con=92s - our algorithm is easier in some ways, e.g. for turning on and = off (which is useful when coupling flows to multiple destinations). 2) as I said, we have lots of indications that this algorithm works for = *many* controllers with only minimal changes. Some details: We successfully used it with NADA and GCC ( = http://heim.ifi.uio.no/michawe/research/publications/noms2016.pdf ), but = also TFRC and RAP ( = http://heim.ifi.uio.no/michawe/research/publications/csws14.pdf ), = LEDBAT ( slide 31: = http://heim.ifi.uio.no/michawe/research/publications/caia2014.pdf ), = also LEDBAT combined with another congestion control (don=92t remember = which, maybe RAP), and most recently TCP. TCP is perhaps an extreme case = because it has so many states. If you ignore all this and just blindly = apply our algorithm, you get pretty much the behavior of E-TCP, which = isn=92t bad ( = http://www.isi.edu/div7/publication_files/effects_of_ensemble.pdf ). We = have improved on it by correctly incorporating the states - this makes = things better, but note that all of this is better than simply leaving = flows as they are and let them compete against each other, in particular = when the goal is to minimize latency. I=92d find it pretty strange if this isn=92t enough reason to justify a = mention of this possibility and a reference. > That said, I personally wouldn't worry too much about mentioning it, = but > it's a post-IESG change without IESG buy-in, so I'll want more > authorization to do that. Sure cheers, Michael From nobody Fri Sep 30 15:06:49 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FD012B004 for ; Fri, 30 Sep 2016 15:06:47 -0700 (PDT) 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 xP4-O8EbXJNB for ; Fri, 30 Sep 2016 15:06:45 -0700 (PDT) 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 A6ABA126B6D for ; Fri, 30 Sep 2016 15:06:45 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id n13so106216574uaa.3 for ; Fri, 30 Sep 2016 15:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=t0J6Yu2pBBvR+tBjgxe8xs1nJLc0vo/a2WPYZ4SeKuQ=; b=k2REDG1y3VDaTiqeAv366a66O03Pfp6efkXMtEnWiFrBSFA/BGuZB7mnbCGGzX6rbO +XVB8qznvcpvwkG1kmienwRl7y0WwkXpAVVpZF61Mn0zB/G4t3wcx7yAeSOuHzINfSsN PNOPL0ibxzBbJVgGIq8V+tjuzI66RUL0OLIt8KeeOFzhrkKcdg4xzKLT8en6U3mitDs9 GVctJxHDUY3M1Jd3KmQWWsizxMr7mSxFKlrNtIbhnGRTZPNJoRcwr2yzlLCdtx0nxAPm Ga3TUe/8o2h7c8HsixucVABKKuKDJJ+ygGvtjUnYRFJJio1PWRkNGfVNGG/2NGx494ym DRYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=t0J6Yu2pBBvR+tBjgxe8xs1nJLc0vo/a2WPYZ4SeKuQ=; b=XjS/AGtFsRn9CRFoxg0Pw6mv4NNRP9g1d7HlYy0fmbNui+2ehTPLfYFyuVfKqV6OGC zMvvVDnMhdPb88gngf5ZS7Zd4ENTSvxSW5cRoJVSzf6UPWttM1WqvkCKcSYXG7BIizHN tceF+O7FOtbYKY1PpNTH3hQAM2AH5i7pELrJamgzBfcMTE9DD2PhTgmE+ae2o23WcHlX BXAmTGMhguZu+9uJJLTE49jtnEecU/k8xvRPYoM5jP3wpe37OJZjVe+lu1nT7bnQOFEd CHN1B8HMwCa0vq6LLCNtUneQZglx41j/5JVfb0sLAvNj6i6Zdm0/kP3XktiUPotMiNFu Tl0Q== X-Gm-Message-State: AA6/9RlSPMtz6RBIvQuPA2E3aOxPIPR/tlS0w3mPkfGavBikWQPbLXd5XRijqH4uzfaWo/rAmMhlYTMSv92xCw== X-Received: by 10.176.81.56 with SMTP id e53mr5000686uaa.160.1475273204381; Fri, 30 Sep 2016 15:06:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.101 with HTTP; Fri, 30 Sep 2016 15:06:23 -0700 (PDT) From: Bernard Aboba Date: Fri, 30 Sep 2016 15:06:23 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c190c544b3f93053dc0cfcb Archived-At: Subject: [rtcweb] Thoughts on JSEP Section 7 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, 30 Sep 2016 22:06:48 -0000 --94eb2c190c544b3f93053dc0cfcb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMHO, the RTP routing rules in JSEP Section 7 are a good start. Aside from addressing Jonathan's comments about handling of RTCP SDES packets (which can set MID mappings), here are some thoughts on how the rules handle the use cases we have been discussing: Here is how the rules proposed in JSEP Section 7 appear to stack up against the basic proposed use cases. Overall, I think a bit more detail is needed with respect to matching of PT values, but the rules seem to be OK. =E2=80=9CWhiskey & Soda Example=E2=80=9D The PT are all the same. Early packets, and any packets after a SSRC change, contain a MID. If the packet has MID, it goes to the place that matches that MID *and* it latches that SSRC so any future SSRC that don=E2= =80=99t have a MID go the to the same place. [BA] I believe that the proposed rules handle this use case. The early packets with a MID will match the configured MID and will latch an entry into the SSRC_table so that future packets without a MID will be routed to the same RtpReceiver. =E2=80=9CCoke Classic Example=E2=80=9D The PT are all unique. The SSRC changes. There is no RID, MID, FEC, or RTX. The packets get delivered to the thing with the matching PT. [BA] I believe that the proposed rules handle this use case. If there is no SSRC match, the PT_Table is consulted and since the PT are all unique, a match will be found there. =E2=80=9CBloody Mary Example=E2=80=9D The PT are the same. The SSRC do not change and are signaled in SDP. There is no MID, RID, etc in the RTP. The packets go to the thing the SSRC signaling would have indicated. [BA] I believe that the proposed rules handle this use case. The SSRC table is consulted first, and as long as a match is found, the packet will be routed to the matching RtpReceiver. =E2=80=9CDiet Coke Example=E2=80=9D The PT are all unique. The packet has a MID. The MID corresponds to an m-line that does not have PT associated with it that matches the PT in the packet. (the PT is from a different m-line). The packets gets dropped (or causes an event in ORTC). Note: I think of this that the MID sends it to the right m-line aka Receiver, but then that does not have a codec for that PT so it gets dropped. [BA] The proposed rules as written do not handle this use case. Here the proposed rules will route the packet to an RtpReceiver based on MID. The rules do not describe what happens next, but presumably the RtpReceiver will check the PT field against the PTs configured for that RtpReceiver and will drop the packet. So some additional text may be needed in the JSEP Section 7 rules. =E2=80=9CDiet Pepsi Example=E2=80=9D The PT are all unique. The packet has a SSRC. The SSRC does not correspond to any SSRC that were signaled for the m-line that the PT is on. The packet goes to the thing associated with that PT ignoring any SSRC. [BA] The proposed rules handle this use case. There is no SSRC match, so the PT_Table is consulted and a match is found. =E2=80=9CRed Bull Example=E2=80=9D The packet has a MID that does not match any MID in the signaling. The packets gets dropped (or event in ORTC). [BA] The proposed rules handle this use case, since a MID mismatch results in a packet drop (SSRC and PT tables are not consulted). Codec change, case 1: The PTs are all unique, and no SSRCs were signaled in SDP There is no RID, MID, FEC or RTX. Sender switches codecs, and the PT changes (but SSRC stays the same). The packet goes to the receiver that matches the new PT. [BA] The proposed rules handle this use case. Since the proposed rules do not have SSRC latching based on PT matches, as long as the new PT is in the PT_Table there will be a match. Codec change, case 2: The PTs are all unique and SSRCs are signaled in SDP. There is no RID, MID, FEC or RTX. Sender switches codecs and the PT changes (but SSRC stays the same). SSRC does not match any signaled ones. The packet goes to the receiver that matches the new PT. [BA] The proposed rules handle this use case. Since there is no SSRC match and no PT latching, as long as the new PT is in the PT_Table there will be a match. Where the rules perhaps have some gaps is in use cases with conflicting PTs. This isn't really due to a deficiency in the rules, but rather due to gaps in the BUNDLE document. If BUNDLE described what should happen in these cases, the rules in JSEP Section 7 could be updated to support that guidance. But with no guidance, it's hard to write proposed rules. A conflicting PT example: Conflict, case 1: The PTs are all the same and SSRCs are signaled in SDP. There is no RID, MID, FEC or RTX. SSRC changes from one that was signaled in the SDP to one that is not signaled (could be due to SSRC conflict). [BA] The proposed rules do not define the behavior for this case. If there had been a MID, the packet would be routed to the RtpReceiver matching that MID and the SSRC would latch so that future packets would be directed to that RtpReceiver. Without a MID or a matching SSRC we need to decide whether this packet should be dropped (and if so, whether it would generate an unhandledrtp event) or whether it should be routed to the first matching PT entry. My personal take is that the packet should be dropped. --94eb2c190c544b3f93053dc0cfcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMHO, the RTP routing rules in JSEP Section 7 are a good s= tart.=C2=A0 Aside from addressing Jonathan's comments about handling of= RTCP SDES packets (which can set MID mappings), here are some thoughts on = how the rules handle the use cases we have been discussing:=C2=A0

<= /div>

Here is how the rules proposed in JSEP Sec= tion 7 appear to stack up against the basic proposed use cases. Overall, I think a bit more detail= is needed with respect to matching of PT values, but the rules seem to be = OK.=C2=A0


=C2=A0

=E2=80=9CWhiskey & Soda Example= =E2=80=9D

The PT are all the same. Early packe= ts, and any packets after a SSRC change, contain a MID. If the packet has =C2=A0MID, it goes to the pla= ce that matches that MID *and* it latches that SSRC so any future SSRC that do= n=E2=80=99t have a MID go the to the same place.=C2=A0

=C2=A0

[BA] I believe that the proposed rul= es handle this use case. The early packets with a MID will match the configured MID and will latch an en= try into the SSRC_table so that future packets without a MID will be routed to = the same RtpReceiver.

=C2=A0

=E2=80=9CCoke Classic Example=E2=80= =9D=C2=A0

The PT are all unique. The SSRC chan= ges. There is no RID, MID, FEC, or RTX. The packets get delivered to the thing with the matching PT.= =C2=A0

=C2=A0

[BA] I believe that the proposed rul= es handle this use case.=C2=A0 If there is no SSRC match, the PT_Table is consulted and since the PT are all unique, a match will be found there.

=C2=A0

=E2=80=9CBloody Mary Example=E2=80= =9D=C2=A0

The PT are the same. The SSRC do not= change and are signaled in SDP. There is no MID, RID, etc in the RTP.=C2=A0 The packets go to the thin= g the SSRC signaling would have indicated.=C2=A0

=C2=A0

[BA] I believe that the proposed rul= es handle this use case.=C2=A0 The SSRC table is consulted first, and as lo= ng as a match is found, the packet will be routed to the matching RtpReceiver.=

=C2=A0

=E2=80=9CDiet Coke Example=E2=80=9D<= span>

The PT are all unique. The packet ha= s a MID. The MID corresponds to an m-line that does not have PT associated with it that matches the PT i= n the packet. (the PT is from a different m-line). The packets gets dropped (= or causes an event in ORTC). Note: I think of this that the MID sends it to th= e right m-line aka Receiver, but then that does not have a codec for that PT = so it gets dropped.

=C2=A0

[BA] The proposed rules as written d= o not handle this use case.=C2=A0 Here the proposed rules will route the packet to an RtpReceiver based on MID.=C2=A0 The rules do not describe what happens next, but presumably the RtpReceiver will check the PT field against the PTs configured for that RtpReceiver and will drop the packet.=C2=A0 So some additional text may be needed in the JSEP Section 7 rules. =C2=A0

=C2=A0

=E2=80=9CDiet Pepsi Example=E2=80=9D=

The PT are all unique. The packet ha= s a SSRC. The SSRC does not correspond to any SSRC that were signaled for the m-line that the PT is on.= The packet goes to the thing associated with that PT ignoring any SSRC.=C2=A0

=C2=A0

[BA] The proposed rules handle this = use case.=C2=A0 There is no SSRC match, so the PT_Table is consulted and a match is found.

=C2=A0

=E2=80=9CRed Bull Example=E2=80=9D

The packet has a MID that does not m= atch any MID in the signaling. The packets gets dropped (or event in ORTC).

=C2=A0

[BA] The proposed rules handle this = use case, since a MID mismatch results in a packet drop (SSRC and PT tables are not consulted).=C2=A0

=C2=A0

Codec change, case 1: The PTs are al= l unique, and no SSRCs were signaled in SDP =C2=A0There is no RID, MID, FEC or RTX. Sender switches cod= ecs, and the PT changes (but SSRC stays the same).=C2=A0 The packet goes to the receiver that matches the new PT.=C2=A0

=C2=A0

[BA] The proposed rules handle this = use case. Since the proposed rules do not have SSRC latching based on PT matches, as long as the new PT = is in the PT_Table there will be a match. =C2=A0

=C2=A0

Codec change, case 2: =C2=A0The PTs = are all unique and SSRCs are signaled in SDP.=C2=A0 There is no RID, MID, FEC or RTX. Sender switches co= decs and the PT changes (but SSRC stays the same).=C2=A0 SSRC does not match any signaled ones.=C2=A0 The packet goes to the receiver that matches the new PT.=C2=A0

=C2=A0

[BA] The proposed rules handle this = use case. Since there is no SSRC match and no PT latching, as long as the new PT is in the PT_Table the= re will be a match.

=C2=A0

Where the rules perhaps have some ga= ps is in use cases with conflicting PTs. This isn't really due to a def= iciency in the rules, but rather due to gaps in the BUNDLE document.=C2=A0 = If BUNDLE described what should happen in these cases, the rules in JSEP Se= ction 7 could be updated to support that guidance. But with no guidance, it= 's hard to write proposed rules.=C2=A0


A co= nflicting PT example:=C2=A0

=C2=A0

Conflict, case 1:=C2=A0 The PTs are all the same and SSRCs are signaled in SDP.=C2=A0 There is no RID, MID, FEC or RTX.=C2=A0 SSRC changes from one that was signaled in the SDP to one that is not signaled (could be due to SSRC conflict).

=C2=A0

[BA] The proposed rules do not defin= e the behavior for this case. If there had been a MID, the packet would be routed to the RtpReceiver matc= hing that MID and the SSRC would latch so that future packets would be directed = to that RtpReceiver.=C2=A0 Without a MID or a matching SSRC we need to decide whether this packet should be dropped (and = if so, whether it would generate an unhandledrtp event) or whether it should b= e routed to the first matching PT entry.=C2=A0 My personal take is that the packet should be dropped.=C2=A0

--94eb2c190c544b3f93053dc0cfcb--