From ietf@meetecho.com Thu Aug 1 02:07:51 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4608D21F9BF1 for ; Thu, 1 Aug 2013 02:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T+0XXP9TbEh for ; Thu, 1 Aug 2013 02:07:43 -0700 (PDT) Received: from smtpdg6.aruba.it (smtpdg224.aruba.it [62.149.158.224]) by ietfa.amsl.com (Postfix) with ESMTP id CADCD21F9ED9 for ; Thu, 1 Aug 2013 02:06:59 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6y1m01L0EaGCq01M6zeu; Thu, 01 Aug 2013 11:06:59 +0200 Date: Thu, 1 Aug 2013 11:06:57 +0200 (CEST) From: Meetecho Team To: avtext@ietf.org Message-ID: <339730661.41.1375348017113.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_40_1594246040.1375348017112" X-Mailman-Approved-At: Thu, 01 Aug 2013 02:08:44 -0700 Subject: [avtext] AVTEXT session recording available X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:07:51 -0000 ------=_Part_40_1594246040.1375348017112 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the AVTEXT WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#AVTEXT For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_40_1594246040.1375348017112-- From keith.drage@alcatel-lucent.com Thu Aug 1 05:46:57 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F021E8118 for ; Thu, 1 Aug 2013 05:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.639 X-Spam-Level: X-Spam-Status: No, score=-110.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+QBBhnVvHYO for ; Thu, 1 Aug 2013 05:46:51 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63D21E80F6 for ; Thu, 1 Aug 2013 05:46:34 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r71CkR25023228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 1 Aug 2013 07:46:28 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r71CkQ7d027891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 14:46:27 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 1 Aug 2013 14:46:26 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: New work to implement unified plan Thread-Index: Ac6OtF/SNgi7LDTJSNKv/QdjIvIFog== Date: Thu, 1 Aug 2013 12:46:26 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07A0DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [avtext] New work to implement unified plan X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:46:57 -0000 (As WG cochair) The MMUSIC WG agreed to adopt the unified plan as defined in=20 https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/ for RTCWEB usage.=20 How many of the resultant deliverables will be generally applicable rather = than specific to RTCWEB usage is up to the individual working groups. At RTCWEB, Adam had a slide that identified the following as being pointed = in the direction of AVTEXT: "Harmonize AppID handling with early media correlation token" In order to charter new work, we need to persuade the working group, and th= e AD to accept the new work. For that we need some definition of what the w= ork is about. To be reasonably quick about this we need to do this via the = list rather than wait for Vancouver. It would be nice if we could use the list to generate a scope or abstract o= f the suggested deliverable, for what we think AVTEXT should be doing based= on the above. Adam, Roni or Jonathan, can you provide some input. Regards Keith From jonathan@vidyo.com Thu Aug 1 07:43:51 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC711E810F for ; Thu, 1 Aug 2013 07:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufeoed1b9fLh for ; Thu, 1 Aug 2013 07:43:45 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 716C211E8166 for ; Thu, 1 Aug 2013 07:43:10 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BE3177AB7C0; Thu, 1 Aug 2013 10:37:46 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 553867AB78D; Thu, 1 Aug 2013 10:37:46 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 1 Aug 2013 10:42:13 -0400 From: Jonathan Lennox To: "DRAGE, Keith (Keith)" Date: Thu, 1 Aug 2013 10:43:06 -0400 Thread-Topic: [avtext] New work to implement unified plan Thread-Index: Ac6OxU6nweK8LiocSHa6nacylqvdGg== Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B07A0DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07A0DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] New work to implement unified plan X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:43:51 -0000 [As co-author of the AppID individual draft; this is my personal opinion.] The purpose of this work is to create RTP/RTCP mechanisms by which RTP stre= ams can be corrolated to external signaling information, in particular (for= the Unified plan) to correlate them with the constituent m-line sections o= f an SDP BUNDLE group. The current proposals envision using an RTP header extension, as well as (i= n the AppID proposal) an RTCP SDES item. This correlation needs to be done in terms other than the streams' SSRC val= ues, both for reasons of dynamicity (as the stream that satisfies a particu= lar application usage can change, potentially quickly and frequently) and a= lso due to race conditions involving early media in an SDP offer/answer (as= RTP traffic can out-race an answer). The solution needs to be designed to handle the details of the Unified plan= , in particular how Unified describes and negotiates scenarios where multip= le RTP streams jointly encode a single media source, such as RTX, FEC, MST = layering, and simulcast.=20 The solution shouldn't be exclusive to the Unified plan, however; in partic= ular, there's a desire that it be useful for the CLUE working group as well= . On Aug 1, 2013, at 2:46 PM, "DRAGE, Keith (Keith)" wrote: > (As WG cochair) >=20 > The MMUSIC WG agreed to adopt the unified plan as defined in=20 >=20 > https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/ >=20 > for RTCWEB usage.=20 >=20 > How many of the resultant deliverables will be generally applicable rathe= r than specific to RTCWEB usage is up to the individual working groups. >=20 > At RTCWEB, Adam had a slide that identified the following as being pointe= d in the direction of AVTEXT: >=20 > "Harmonize AppID handling with early media correlation token" >=20 > In order to charter new work, we need to persuade the working group, and = the AD to accept the new work. For that we need some definition of what the= work is about. To be reasonably quick about this we need to do this via th= e list rather than wait for Vancouver. >=20 > It would be nice if we could use the list to generate a scope or abstract= of the suggested deliverable, for what we think AVTEXT should be doing bas= ed on the above. >=20 > Adam, Roni or Jonathan, can you provide some input. >=20 > Regards >=20 > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext >=20 -- Jonathan Lennox jonathan@vidyo.com From suhasietf@gmail.com Fri Aug 2 00:36:34 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3D21E809A for ; Fri, 2 Aug 2013 00:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfI65s+fpYUf for ; Fri, 2 Aug 2013 00:36:33 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 323C211E8286 for ; Fri, 2 Aug 2013 00:36:13 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so229946wes.16 for ; Fri, 02 Aug 2013 00:36: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:date:message-id:subject:from:to :cc:content-type; bh=P1MBTH1wagV8eK/IU3HWmZB7mqVkDPVHuXRt9EtmgiY=; b=m0cRhUqScqEnecuzdTMO3uTfftntapzXKXysGlQSE0riAjGSrZymZixtloJ1TXvp4z TLB8J725/kXL5beog1sn67DJg9h+nXpLWIf1PABnYgxjfqSvJhcCYdTtj4BoWDot7Z9C 4lOsMPAXSKfu6+NLW8MSaqhpysvuWebr9n+BQyP1iluGB1K5BEeeCa9AW8YjEPZGR+3r b8AxKCzhe0aNkoyDtNIA5CKRvl9ZKlFuniiSGPH5A2cOmyLLW2TtCpSgv6B7E09qfBbF G0QKBt8LndqQoC6oCoSD17tAf/6dyR9CiJ13gzD4vxxfScNx+joiiZciU1WxJ0WmKVRI d77w== MIME-Version: 1.0 X-Received: by 10.194.242.69 with SMTP id wo5mr3995315wjc.30.1375428961411; Fri, 02 Aug 2013 00:36:01 -0700 (PDT) Received: by 10.194.9.9 with HTTP; Fri, 2 Aug 2013 00:36:01 -0700 (PDT) In-Reply-To: References: <949EF20990823C4C85C18D59AA11AD8B07A0DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Fri, 2 Aug 2013 09:36:01 +0200 Message-ID: From: Suhas Nandakumar To: Jonathan Lennox Content-Type: multipart/alternative; boundary=089e0122f0fea8a97c04e2f2028f Cc: "avtext@ietf.org" Subject: Re: [avtext] New work to implement unified plan X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:36:34 -0000 --089e0122f0fea8a97c04e2f2028f Content-Type: text/plain; charset=ISO-8859-1 My understanding was AppID is sender based and the correlator is receiver driven. Both solve correlation of the incoming packet to a particular m=line but the latter also solves early media clipping scenarios We need a combination of both if i am not wrong Cheers Suhas On Thu, Aug 1, 2013 at 4:43 PM, Jonathan Lennox wrote: > [As co-author of the AppID individual draft; this is my personal opinion.] > > The purpose of this work is to create RTP/RTCP mechanisms by which RTP > streams can be corrolated to external signaling information, in particular > (for the Unified plan) to correlate them with the constituent m-line > sections of an SDP BUNDLE group. > > The current proposals envision using an RTP header extension, as well as > (in the AppID proposal) an RTCP SDES item. > > This correlation needs to be done in terms other than the streams' SSRC > values, both for reasons of dynamicity (as the stream that satisfies a > particular application usage can change, potentially quickly and > frequently) and also due to race conditions involving early media in an SDP > offer/answer (as RTP traffic can out-race an answer). > > The solution needs to be designed to handle the details of the Unified > plan, in particular how Unified describes and negotiates scenarios where > multiple RTP streams jointly encode a single media source, such as RTX, > FEC, MST layering, and simulcast. > > The solution shouldn't be exclusive to the Unified plan, however; in > particular, there's a desire that it be useful for the CLUE working group > as well. > > On Aug 1, 2013, at 2:46 PM, "DRAGE, Keith (Keith)" < > keith.drage@alcatel-lucent.com> wrote: > > > (As WG cochair) > > > > The MMUSIC WG agreed to adopt the unified plan as defined in > > > > https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/ > > > > for RTCWEB usage. > > > > How many of the resultant deliverables will be generally applicable > rather than specific to RTCWEB usage is up to the individual working groups. > > > > At RTCWEB, Adam had a slide that identified the following as being > pointed in the direction of AVTEXT: > > > > "Harmonize AppID handling with early media correlation token" > > > > In order to charter new work, we need to persuade the working group, and > the AD to accept the new work. For that we need some definition of what the > work is about. To be reasonably quick about this we need to do this via the > list rather than wait for Vancouver. > > > > It would be nice if we could use the list to generate a scope or > abstract of the suggested deliverable, for what we think AVTEXT should be > doing based on the above. > > > > Adam, Roni or Jonathan, can you provide some input. > > > > Regards > > > > Keith > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > > > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --089e0122f0fea8a97c04e2f2028f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My understanding was AppID is sender based and the correlator is receiver d= riven. Both solve correlation of the incoming packet to a particular m=3Dli= ne but the latter also solves early media clipping scenarios

We need a combination of both if i am not wrong

Cheers
Suhas
=A0

O= n Thu, Aug 1, 2013 at 4:43 PM, Jonathan Lennox <jonathan@vidyo.com>= ; wrote:
[As co-author of the AppID individual draft;= this is my personal opinion.]

The purpose of this work is to create RTP/RTCP mechanisms by which RTP stre= ams can be corrolated to external signaling information, in particular (for= the Unified plan) to correlate them with the constituent m-line sections o= f an SDP BUNDLE group.

The current proposals envision using an RTP header extension, as well as (i= n the AppID proposal) an RTCP SDES item.

This correlation needs to be done in terms other than the streams' SSRC= values, both for reasons of dynamicity (as the stream that satisfies a par= ticular application usage can change, potentially quickly and frequently) a= nd also due to race conditions involving early media in an SDP offer/answer= (as RTP traffic can out-race an answer).

The solution needs to be designed to handle the details of the Unified plan= , in particular how Unified describes and negotiates scenarios where multip= le RTP streams jointly encode a single media source, such as RTX, FEC, MST = layering, and simulcast.

The solution shouldn't be exclusive to the Unified plan, however; in pa= rticular, there's a desire that it be useful for the CLUE working group= as well.

On Aug 1, 2013, at 2:46 PM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com&= gt; wrote:

> (As WG cochair)
>
> The MMUSIC WG agreed to adopt the unified plan as defined in
>
> https://datatracker.ietf.org/doc/draft-roach-mmus= ic-unified-plan/
>
> for RTCWEB usage.
>
> How many of the resultant deliverables will be generally applicable ra= ther than specific to RTCWEB usage is up to the individual working groups.<= br> >
> At RTCWEB, Adam had a slide that identified the following as being poi= nted in the direction of AVTEXT:
>
> "Harmonize AppID handling with early media correlation token"= ;
>
> In order to charter new work, we need to persuade the working group, a= nd the AD to accept the new work. For that we need some definition of what = the work is about. To be reasonably quick about this we need to do this via= the list rather than wait for Vancouver.
>
> It would be nice if we could use the list to generate a scope or abstr= act of the suggested deliverable, for what we think AVTEXT should be doing = based on the above.
>
> Adam, Roni or Jonathan, can you provide some input.
>
> Regards
>
> Keith
> _______________________________________________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext
>

--
Jonathan Lennox
jonathan@vidyo.com


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

--089e0122f0fea8a97c04e2f2028f-- From ron.even.tlv@gmail.com Fri Aug 2 01:37:04 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE8C11E82CF for ; Fri, 2 Aug 2013 01:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfPrM1xKTbiN for ; Fri, 2 Aug 2013 01:37:02 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 173DB11E82D5 for ; Fri, 2 Aug 2013 01:32:57 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so416130pdi.13 for ; Fri, 02 Aug 2013 01:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=egKAD/p7ohjUR8Xxb2+XOT8662BbquN8g1wyCagdBpg=; b=Xzfy7j76hoCG4r3v0/tu3LWxiySbgYuVutndsM11LUJqOvLPgeYDUuUeMQ8YJDE6ce DKxuqVfXrnDI+f37goUNDr/DLODabbs9zYZx8Gx9mR/qryeaqc9VU3TUBAQZ3VTpXhYk xKpPUoy7cdSGocqrMWk2G0p465KX6b3mnaXqgnY+5kR9lp5Z6XxsLtUeGBLznPWsJ7Q+ r5qfOuRa/jgOBXRTimBN3TyWId64CrUYnLAaQ6KDR5aGfTbPDFlPWYslJEHyFKqrDbhg uhqOuUyJYMuIt9KjjsmJ8d5TEBH8prPe+q+deuHTLnh6cSLWtN9vmoj1ZqCJKr0H1zNe v5xw== X-Received: by 10.67.23.36 with SMTP id hx4mr9230387pad.54.1375432365600; Fri, 02 Aug 2013 01:32:45 -0700 (PDT) Received: from RoniE ([2001:df8:0:64:7004:d79:14e3:a91a]) by mx.google.com with ESMTPSA id bg3sm8045812pbb.44.2013.08.02.01.32.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 02 Aug 2013 01:32:44 -0700 (PDT) From: "Roni Even" To: "'Suhas Nandakumar'" , "'Jonathan Lennox'" References: <949EF20990823C4C85C18D59AA11AD8B07A0DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Date: Fri, 2 Aug 2013 11:30:41 +0300 Message-ID: <02ef01ce8f5a$95666f30$c0334d90$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F0_01CE8F73.BAB4DFB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBgjK4MVBzPhoGV31ynD+JAgl1bwHpXOcYAZ2y8NuZ/3Yc4A== Content-Language: en-us Cc: avtext@ietf.org Subject: Re: [avtext] New work to implement unified plan X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:37:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02F0_01CE8F73.BAB4DFB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We mentioned this as an open issue in our presentation in MMUSIC. At first look it seems we can use receiver driven correlator (appId) in SDP offer answer and it will work for RTCweba and CLUE, but we need to look carefully at FEC, RTX, MST layering and simulcast support to verify that using receiver driven assignment works. Roni From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Suhas Nandakumar Sent: 02 August, 2013 10:36 AM To: Jonathan Lennox Cc: avtext@ietf.org Subject: Re: [avtext] New work to implement unified plan My understanding was AppID is sender based and the correlator is receiver driven. Both solve correlation of the incoming packet to a particular m=line but the latter also solves early media clipping scenarios We need a combination of both if i am not wrong Cheers Suhas On Thu, Aug 1, 2013 at 4:43 PM, Jonathan Lennox wrote: [As co-author of the AppID individual draft; this is my personal opinion.] The purpose of this work is to create RTP/RTCP mechanisms by which RTP streams can be corrolated to external signaling information, in particular (for the Unified plan) to correlate them with the constituent m-line sections of an SDP BUNDLE group. The current proposals envision using an RTP header extension, as well as (in the AppID proposal) an RTCP SDES item. This correlation needs to be done in terms other than the streams' SSRC values, both for reasons of dynamicity (as the stream that satisfies a particular application usage can change, potentially quickly and frequently) and also due to race conditions involving early media in an SDP offer/answer (as RTP traffic can out-race an answer). The solution needs to be designed to handle the details of the Unified plan, in particular how Unified describes and negotiates scenarios where multiple RTP streams jointly encode a single media source, such as RTX, FEC, MST layering, and simulcast. The solution shouldn't be exclusive to the Unified plan, however; in particular, there's a desire that it be useful for the CLUE working group as well. On Aug 1, 2013, at 2:46 PM, "DRAGE, Keith (Keith)" wrote: > (As WG cochair) > > The MMUSIC WG agreed to adopt the unified plan as defined in > > https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/ > > for RTCWEB usage. > > How many of the resultant deliverables will be generally applicable rather than specific to RTCWEB usage is up to the individual working groups. > > At RTCWEB, Adam had a slide that identified the following as being pointed in the direction of AVTEXT: > > "Harmonize AppID handling with early media correlation token" > > In order to charter new work, we need to persuade the working group, and the AD to accept the new work. For that we need some definition of what the work is about. To be reasonably quick about this we need to do this via the list rather than wait for Vancouver. > > It would be nice if we could use the list to generate a scope or abstract of the suggested deliverable, for what we think AVTEXT should be doing based on the above. > > Adam, Roni or Jonathan, can you provide some input. > > Regards > > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Jonathan Lennox jonathan@vidyo.com _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext ------=_NextPart_000_02F0_01CE8F73.BAB4DFB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We mentioned this as an open issue in our presentation in MMUSIC. =

At first look it seems we can use receiver driven correlator (appId) = in SDP offer answer and it will work for RTCweba and CLUE, but we need = to look carefully at FEC, RTX, MST layering and simulcast support =  to verify that using receiver driven assignment works. =

 

Roni

 

From:= = avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of = Suhas Nandakumar
Sent: 02 August, 2013 10:36 = AM
To: Jonathan Lennox
Cc: = avtext@ietf.org
Subject: Re: [avtext] New work to implement = unified plan

 

My = understanding was AppID is sender based and the correlator is receiver = driven. Both solve correlation of the incoming packet to a particular = m=3Dline but the latter also solves early media clipping = scenarios

 

We need a combination of both if i am not = wrong

 

Cheers

Suhas

 

On Thu, Aug 1, 2013 at 4:43 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

[As co-author of the AppID individual draft; this is = my personal opinion.]

The purpose of this work is to create = RTP/RTCP mechanisms by which RTP streams can be corrolated to external = signaling information, in particular (for the Unified plan) to correlate = them with the constituent m-line sections of an SDP BUNDLE = group.

The current proposals envision using an RTP header = extension, as well as (in the AppID proposal) an RTCP SDES = item.

This correlation needs to be done in terms other than the = streams' SSRC values, both for reasons of dynamicity (as the stream that = satisfies a particular application usage can change, potentially quickly = and frequently) and also due to race conditions involving early media in = an SDP offer/answer (as RTP traffic can out-race an answer).

The = solution needs to be designed to handle the details of the Unified plan, = in particular how Unified describes and negotiates scenarios where = multiple RTP streams jointly encode a single media source, such as RTX, = FEC, MST layering, and simulcast.

The solution shouldn't be = exclusive to the Unified plan, however; in particular, there's a desire = that it be useful for the CLUE working group as = well.


On Aug 1, 2013, at 2:46 PM, = "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent= .com> wrote:

> (As WG cochair)
>
> The = MMUSIC WG agreed to adopt the unified plan as defined in
>
> = https://datatracker.ietf.org/doc/draft-roach-mmusic-uni= fied-plan/
>
> for RTCWEB usage.
>
> How = many of the resultant deliverables will be generally applicable rather = than specific to RTCWEB usage is up to the individual working = groups.
>
> At RTCWEB, Adam had a slide that identified the = following as being pointed in the direction of AVTEXT:
>
> = "Harmonize AppID handling with early media correlation = token"
>
> In order to charter new work, we need to = persuade the working group, and the AD to accept the new work. For that = we need some definition of what the work is about. To be reasonably = quick about this we need to do this via the list rather than wait for = Vancouver.
>
> It would be nice if we could use the list to = generate a scope or abstract of the suggested deliverable, for what we = think AVTEXT should be doing based on the above.
>
> Adam, = Roni or Jonathan, can you provide some input.
>
> = Regards
>
> Keith
> = _______________________________________________
> avtext mailing = list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext
>= ;

--
Jonathan = Lennox
jonathan@vidyo.com

<= div>



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

 

------=_NextPart_000_02F0_01CE8F73.BAB4DFB0-- From jonathan@vidyo.com Fri Aug 2 01:52:19 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AB521F9D7B for ; Fri, 2 Aug 2013 01:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N+aUlJcUINB for ; Fri, 2 Aug 2013 01:52:07 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id B7CD611E82B3 for ; Fri, 2 Aug 2013 01:48:22 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 108CD554EBB for ; Fri, 2 Aug 2013 04:46:26 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2521A554C0B for ; Fri, 2 Aug 2013 04:46:22 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Fri, 2 Aug 2013 04:47:20 -0400 From: Jonathan Lennox To: Roni Even Date: Fri, 2 Aug 2013 04:48:15 -0400 Thread-Topic: [avtext] New work to implement unified plan Thread-Index: Ac6PXOYPofl/up2BTG6uEOeC0NRr9g== Message-ID: <959E57F2-4EAB-4687-B6D7-D01E1C1A552F@vidyo.com> References: <949EF20990823C4C85C18D59AA11AD8B07A0DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <02ef01ce8f5a$95666f30$c0334d90$@gmail.com> In-Reply-To: <02ef01ce8f5a$95666f30$c0334d90$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_959E57F24EAB4687B6D7D01E1C1A552Fvidyocom_" MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] New work to implement unified plan X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:52:20 -0000 --_000_959E57F24EAB4687B6D7D01E1C1A552Fvidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The specific requirement, as I understand it, is that when a new sendrecv o= r recvonly m-line section is offered (either in an initial offer, or when a= new m-line is added), the receiver needs to specify sufficient information= for correlation so it can correctly map the media for that m-line if it ou= traces the answer. This doesn't necessarily imply that all app-ids must always and only be set= by a receiver. But of course, simplicity is a virtue, so it's better to p= refer a simpler rule if possible. On Aug 2, 2013, at 10:30 AM, Roni Even > wrote: Hi, We mentioned this as an open issue in our presentation in MMUSIC. At first look it seems we can use receiver driven correlator (appId) in SDP= offer answer and it will work for RTCweba and CLUE, but we need to look ca= refully at FEC, RTX, MST layering and simulcast support to verify that usi= ng receiver driven assignment works. Roni From: avtext-bounces@ietf.org [mailto:avtex= t-bounces@ietf.org] On Behalf Of Suhas Nandakumar Sent: 02 August, 2013 10:36 AM To: Jonathan Lennox Cc: avtext@ietf.org Subject: Re: [avtext] New work to implement unified plan My understanding was AppID is sender based and the correlator is receiver d= riven. Both solve correlation of the incoming packet to a particular m=3Dli= ne but the latter also solves early media clipping scenarios We need a combination of both if i am not wrong Cheers Suhas On Thu, Aug 1, 2013 at 4:43 PM, Jonathan Lennox > wrote: [As co-author of the AppID individual draft; this is my personal opinion.] The purpose of this work is to create RTP/RTCP mechanisms by which RTP stre= ams can be corrolated to external signaling information, in particular (for= the Unified plan) to correlate them with the constituent m-line sections o= f an SDP BUNDLE group. The current proposals envision using an RTP header extension, as well as (i= n the AppID proposal) an RTCP SDES item. This correlation needs to be done in terms other than the streams' SSRC val= ues, both for reasons of dynamicity (as the stream that satisfies a particu= lar application usage can change, potentially quickly and frequently) and a= lso due to race conditions involving early media in an SDP offer/answer (as= RTP traffic can out-race an answer). The solution needs to be designed to handle the details of the Unified plan= , in particular how Unified describes and negotiates scenarios where multip= le RTP streams jointly encode a single media source, such as RTX, FEC, MST = layering, and simulcast. The solution shouldn't be exclusive to the Unified plan, however; in partic= ular, there's a desire that it be useful for the CLUE working group as well= . On Aug 1, 2013, at 2:46 PM, "DRAGE, Keith (Keith)" > wrote: > (As WG cochair) > > The MMUSIC WG agreed to adopt the unified plan as defined in > > https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/ > > for RTCWEB usage. > > How many of the resultant deliverables will be generally applicable rathe= r than specific to RTCWEB usage is up to the individual working groups. > > At RTCWEB, Adam had a slide that identified the following as being pointe= d in the direction of AVTEXT: > > "Harmonize AppID handling with early media correlation token" > > In order to charter new work, we need to persuade the working group, and = the AD to accept the new work. For that we need some definition of what the= work is about. To be reasonably quick about this we need to do this via th= e list rather than wait for Vancouver. > > It would be nice if we could use the list to generate a scope or abstract= of the suggested deliverable, for what we think AVTEXT should be doing bas= ed on the above. > > Adam, Roni or Jonathan, can you provide some input. > > Regards > > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Jonathan Lennox jonathan@vidyo.com _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext -- Jonathan Lennox jonathan@vidyo.com --_000_959E57F24EAB4687B6D7D01E1C1A552Fvidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ron.even.tlv@gmail.com>= wrote:
Hi,<= /span>
We mentioned this as a= n open issue in our presentation in MMUSIC.
At first look it seems we can use receiver= driven correlator (appId) in SDP offer answer and it will work for RTCweba= and CLUE, but we need to look carefully at FEC, RTX, MST layering and simu= lcast support  to verify that using receiver driven assignment works.<= o:p>
 
Roni
 
From: avtext-bounces@ietf.o= rg [mailto:avtext-bounces@ietf.org]&nbs= p;On Behalf Of = Suhas Nandakumar
Sent:&= nbsp;02 August, 2013 10:36 AM
To: Jonathan Lennox
Cc: avtext@ie= tf.org
Subject: Re: [avtext] New work to implement unified plan
 
My understanding was AppID is sender based and the correlator is rec= eiver driven. Both solve correlation of the incoming packet to a particular= m=3Dline but the latter also solves early media clipping scenarios
 
We need a combination of both if i am not wrong
 
Cheers
Suhas

 

On Thu, Aug 1, 2013 at 4:= 43 PM, Jonathan Lennox <jonathan@vidy= o.com> wrote:
[As co-author o= f the AppID individual draft; this is my personal opinion.]

The purp= ose of this work is to create RTP/RTCP mechanisms by which RTP streams can = be corrolated to external signaling information, in particular (for the Uni= fied plan) to correlate them with the constituent m-line sections of an SDP= BUNDLE group.

The current proposals envision using an RTP header ex= tension, as well as (in the AppID proposal) an RTCP SDES item.

This = correlation needs to be done in terms other than the streams' SSRC values, = both for reasons of dynamicity (as the stream that satisfies a particular a= pplication usage can change, potentially quickly and frequently) and also d= ue to race conditions involving early media in an SDP offer/answer (as RTP = traffic can out-race an answer).

The solution needs to be designed t= o handle the details of the Unified plan, in particular how Unified describ= es and negotiates scenarios where multiple RTP streams jointly encode a sin= gle media source, such as RTX, FEC, MST layering, and simulcast.

The= solution shouldn't be exclusive to the Unified plan, however; in particula= r, there's a desire that it be useful for the CLUE working group as well.


On Aug 1, 2013= , at 2:46 PM, "DRAGE, Keith (Keith)" <keith= .drage@alcatel-lucent.com> wrote:

> (As WG cochair)
>= ;
> The MMUSIC WG agreed to adopt the unified plan as defined in
&= gt;
> https://datat= racker.ietf.org/doc/draft-roach-mmusic-unified-plan/
>
> fo= r RTCWEB usage.
>
> How many of the resultant deliverables will= be generally applicable rather than specific to RTCWEB usage is up to the = individual working groups.
>
> At RTCWEB, Adam had a slide that= identified the following as being pointed in the direction of AVTEXT:
&= gt;
> "Harmonize AppID handling with early media correlation token">
> In order to charter new work, we need to persuade the workin= g group, and the AD to accept the new work. For that we need some definitio= n of what the work is about. To be reasonably quick about this we need to d= o this via the list rather than wait for Vancouver.
>
> It woul= d be nice if we could use the list to generate a scope or abstract of the s= uggested deliverable, for what we think AVTEXT should be doing based on the= above.
>
> Adam, Roni or Jonathan, can you provide some input.=
>
> Regards
>
> Keith
> ____________________= ___________________________
> avtext mailing list
> avtext@ietf.org> https://www.ietf.org/mailman/listinfo/a= vtext
>

--
Jonathan= Lennox
jonathan@vidyo.com


_______________________________________________=
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/lis= tinfo/avtext
&n= bsp;

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_959E57F24EAB4687B6D7D01E1C1A552Fvidyocom_-- From bernard_aboba@hotmail.com Fri Aug 2 02:02:57 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB411E831E for ; Fri, 2 Aug 2013 02:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn+55u3xpuxm for ; Fri, 2 Aug 2013 02:02:46 -0700 (PDT) Received: from blu0-omc2-s23.blu0.hotmail.com (blu0-omc2-s23.blu0.hotmail.com [65.55.111.98]) by ietfa.amsl.com (Postfix) with ESMTP id 37EDC11E82FD for ; Fri, 2 Aug 2013 01:56:24 -0700 (PDT) Received: from BLU169-W109 ([65.55.111.72]) by blu0-omc2-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Aug 2013 01:56:23 -0700 X-TMN: [qhx7m24f141xN9bWuv2A2b7rcatQHxEQ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_4b5907bc-02bd-4e0b-bc51-ebceab986288_" From: Bernard Aboba To: Roni Even , 'Suhas Nandakumar' , 'Jonathan Lennox' Date: Fri, 2 Aug 2013 01:56:23 -0700 Importance: Normal In-Reply-To: <02ef01ce8f5a$95666f30$c0334d90$@gmail.com> References: <949EF20990823C4C85C18D59AA11AD8B07A0DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> , , <02ef01ce8f5a$95666f30$c0334d90$@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 02 Aug 2013 08:56:23.0997 (UTC) FILETIME=[2A50F6D0:01CE8F5E] Cc: "avtext@ietf.org" Subject: Re: [avtext] New work to implement unified plan X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:02:58 -0000 --_4b5907bc-02bd-4e0b-bc51-ebceab986288_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Roni that an examination of FEC=2C RTX=2C SST/MST layering and= simulcast layering will be necessary to understand app-id usage scenarios = (and implications for a MANE).=20 As an example=2C if the app-id is chosen by each receiver in a conference i= ndependently=2C then a MANE may need to rewrite the app-id before sending t= he media (as it may do with the SSRC). =20 From: ron.even.tlv@gmail.com To: suhasietf@gmail.com=3B jonathan@vidyo.com Date: Fri=2C 2 Aug 2013 11:30:41 +0300 CC: avtext@ietf.org Subject: Re: [avtext] New work to implement unified plan Hi=2CWe mentioned this as an open issue in our presentation in MMUSIC. At f= irst look it seems we can use receiver driven correlator (appId) in SDP off= er answer and it will work for RTCweba and CLUE=2C but we need to look care= fully at FEC=2C RTX=2C MST layering and simulcast support to verify that u= sing receiver driven assignment works. Roni From: avtext-bounces@ietf.org= [mailto:avtext-bounces@ietf.org] On Behalf Of Suhas Nandakumar Sent: 02 August=2C 2013 10:36 AM To: Jonathan Lennox Cc: avtext@ietf.org Subject: Re: [avtext] New work to implement unified plan My understanding w= as AppID is sender based and the correlator is receiver driven. Both solve = correlation of the incoming packet to a particular m=3Dline but the latter = also solves early media clipping scenarios We need a combination of both if= i am not wrong CheersSuhas On Thu=2C Aug 1=2C 2013 at 4:43 PM=2C Jonathan = Lennox wrote:[As co-author of the AppID individual dra= ft=3B this is my personal opinion.] The purpose of this work is to create RTP/RTCP mechanisms by which RTP stre= ams can be corrolated to external signaling information=2C in particular (f= or the Unified plan) to correlate them with the constituent m-line sections= of an SDP BUNDLE group. The current proposals envision using an RTP header extension=2C as well as = (in the AppID proposal) an RTCP SDES item. This correlation needs to be done in terms other than the streams' SSRC val= ues=2C both for reasons of dynamicity (as the stream that satisfies a parti= cular application usage can change=2C potentially quickly and frequently) a= nd also due to race conditions involving early media in an SDP offer/answer= (as RTP traffic can out-race an answer). The solution needs to be designed to handle the details of the Unified plan= =2C in particular how Unified describes and negotiates scenarios where mult= iple RTP streams jointly encode a single media source=2C such as RTX=2C FEC= =2C MST layering=2C and simulcast. The solution shouldn't be exclusive to the Unified plan=2C however=3B in pa= rticular=2C there's a desire that it be useful for the CLUE working group a= s well. On Aug 1=2C 2013=2C at 2:46 PM=2C "DRAGE=2C Keith (Keith)" wrote: > (As WG cochair) > > The MMUSIC WG agreed to adopt the unified plan as defined in > > https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/ > > for RTCWEB usage. > > How many of the resultant deliverables will be generally applicable rathe= r than specific to RTCWEB usage is up to the individual working groups. > > At RTCWEB=2C Adam had a slide that identified the following as being poin= ted in the direction of AVTEXT: > > "Harmonize AppID handling with early media correlation token" > > In order to charter new work=2C we need to persuade the working group=2C = and the AD to accept the new work. For that we need some definition of what= the work is about. To be reasonably quick about this we need to do this vi= a the list rather than wait for Vancouver. > > It would be nice if we could use the list to generate a scope or abstract= of the suggested deliverable=2C for what we think AVTEXT should be doing b= ased on the above. > > Adam=2C Roni or Jonathan=2C can you provide some input. > > Regards > > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext >-- Jonathan Lennox jonathan@vidyo.com _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext=20 _______________________________________________=0A= avtext mailing list=0A= avtext@ietf.org=0A= https://www.ietf.org/mailman/listinfo/avtext = --_4b5907bc-02bd-4e0b-bc51-ebceab986288_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with Roni that an examin= ation of FEC=2C RTX=2C SST/MST layering and simulcast layering will be nece= ssary to understand app-id usage scenarios (and implications for a MANE).&n= bsp=3B

As an example=2C if the app-id is chosen by each = receiver in a conference independently=2C then a MANE may need to rewrite t= he app-id before sending the media (as it may do with the SSRC).  =3B

From: ron.even.tlv@gmail.com
To:= suhasietf@gmail.com=3B jonathan@vidyo.com
Date: Fri=2C 2 Aug 2013 11:30= :41 +0300
CC: avtext@ietf.org
Subject: Re: [avtext] New work to imple= ment unified plan

Hi=2C

We mentioned this as an o= pen issue in our presentation in MMUSIC.

At first look it seems we ca= n use receiver driven correlator (appId) in SDP offer answer and it will wo= rk for RTCweba and CLUE=2C but we need to look carefully at FEC=2C RTX=2C M= ST layering and simulcast support  =3Bto verify that using receiver dri= ven assignment works.

 =3B

Roni

 =3B

From: avtext-bounces@= ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Suhas Nandaku= mar
Sent: 02 August=2C 2013 10:36 AM
To: Jonathan Lenno= x
Cc: avtext@ietf.org
Subject: Re: [avtext] New work to= implement unified plan

&nb= sp=3B

My understanding was AppID is sender bas= ed and the correlator is receiver driven. Both solve correlation of the inc= oming packet to a particular m=3Dline but the latter also solves early medi= a clipping scenarios

 =3B

We need a combination of both if i am not wron= g

 =3B

Cheers

Suhas

<= /div>

 =3B

On Thu=2C Aug 1=2C 2013 at 4:43 PM=2C Jonathan Lennox <=3B= jonathan@vidyo.com<= /a>>=3B wrote:

[As co-author of the AppID in= dividual draft=3B this is my personal opinion.]

The purpose of this = work is to create RTP/RTCP mechanisms by which RTP streams can be corrolate= d to external signaling information=2C in particular (for the Unified plan)= to correlate them with the constituent m-line sections of an SDP BUNDLE gr= oup.

The current proposals envision using an RTP header extension=2C= as well as (in the AppID proposal) an RTCP SDES item.

This correlat= ion needs to be done in terms other than the streams' SSRC values=2C both f= or reasons of dynamicity (as the stream that satisfies a particular applica= tion usage can change=2C potentially quickly and frequently) and also due t= o race conditions involving early media in an SDP offer/answer (as RTP traf= fic can out-race an answer).

The solution needs to be designed to ha= ndle the details of the Unified plan=2C in particular how Unified describes= and negotiates scenarios where multiple RTP streams jointly encode a singl= e media source=2C such as RTX=2C FEC=2C MST layering=2C and simulcast.
<= br>The solution shouldn't be exclusive to the Unified plan=2C however=3B in= particular=2C there's a desire that it be useful for the CLUE working grou= p as well.


On Aug 1= =2C 2013=2C at 2:46 PM=2C "DRAGE=2C Keith (Keith)" <=3Bkeith.drage@alcatel-lucent.com>=3B wr= ote:

>=3B (As WG cochair)
>=3B
>=3B The MMUSIC WG agreed= to adopt the unified plan as defined in
>=3B
>=3B https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/
>=3B
>=3B for RTCWEB usage.
>=3B
>=3B How many of the= resultant deliverables will be generally applicable rather than specific t= o RTCWEB usage is up to the individual working groups.
>=3B
>=3B = At RTCWEB=2C Adam had a slide that identified the following as being pointe= d in the direction of AVTEXT:
>=3B
>=3B "Harmonize AppID handling= with early media correlation token"
>=3B
>=3B In order to charte= r new work=2C we need to persuade the working group=2C and the AD to accept= the new work. For that we need some definition of what the work is about. = To be reasonably quick about this we need to do this via the list rather th= an wait for Vancouver.
>=3B
>=3B It would be nice if we could use= the list to generate a scope or abstract of the suggested deliverable=2C f= or what we think AVTEXT should be doing based on the above.
>=3B
&g= t=3B Adam=2C Roni or Jonathan=2C can you provide some input.
>=3B
&= gt=3B Regards
>=3B
>=3B Keith
>=3B _________________________= ______________________
>=3B avtext mailing list
>=3B avtext@ietf.org
>=3B https://www.ietf.org/m= ailman/listinfo/avtext
>=3B

--
Jonathan Lennox
jonathan@= vidyo.com



______________= _________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/lis= tinfo/avtext

 =3B


_______________________________________________=0A= avtext mailing list=0A= avtext@ietf.org=0A= https://www.ietf.org/mailman/listinfo/avtext
<= /div> = --_4b5907bc-02bd-4e0b-bc51-ebceab986288_-- From jonathan@vidyo.com Tue Aug 13 09:14:12 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7A821F9EE0 for ; Tue, 13 Aug 2013 09:14:12 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ocmw2sDyWHm for ; Tue, 13 Aug 2013 09:14:08 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id D504D21E808A for ; Tue, 13 Aug 2013 09:14:05 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 04364555CE8 for ; Tue, 13 Aug 2013 12:13:55 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 850F255564B for ; Tue, 13 Aug 2013 12:13:54 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 13 Aug 2013 12:13:42 -0400 From: Jonathan Lennox To: "avtext@ietf.org" Date: Tue, 13 Aug 2013 12:14:04 -0400 Thread-Topic: WGLC for draft-ietf-avtext-rtp-duplication-02 Thread-Index: Ac6YP/xaTdbp+FggTYiP2CNM2hwwiw== Message-ID: <8DB3E9B2-31D2-4817-9A62-EBB044D72B30@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:14:13 -0000 (As WG cochair) This is to announce a working group last call for draft-ietf-avtext-rtp-dup= lication-02: http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/?include_= text=3D1 Please respond to the list by Tuesday, September 3, 2013 (i.e. 3 weeks time= ) with any comments. This is intended as a standards track RFC. It is helpful to attempt to categorise the type of your comment (including = severity) and also to assist to provide any replacement text you feel is ne= cessary. If you review the document and have no comments, please tell the chairs tha= t you have reviewed it. This is always useful information in assessing the = degree of WG review and consensus behind the document. -- Jonathan Lennox jonathan@vidyo.com From stewe@stewe.org Tue Aug 13 09:28:04 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFA621F9C37 for ; Tue, 13 Aug 2013 09:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtYNw0VVZWdL for ; Tue, 13 Aug 2013 09:27:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 535AF11E81AC for ; Tue, 13 Aug 2013 09:26:07 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB190.namprd07.prod.outlook.com (10.242.167.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 16:25:55 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.108]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.108]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 16:25:54 +0000 From: Stephan Wenger To: "avtext@ietf.org" Thread-Topic: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 Thread-Index: Ac6YP/xaTdbp+FggTYiP2CNM2hwwiwAEos+A Date: Tue, 13 Aug 2013 16:25:54 +0000 Message-ID: In-Reply-To: <8DB3E9B2-31D2-4817-9A62-EBB044D72B30@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 0937FB07C5 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(51704005)(199002)(16406001)(80976001)(4396001)(47976001)(31966008)(76176001)(81542001)(83072001)(47446002)(81342001)(74502001)(81686001)(46102001)(54356001)(47736001)(51856001)(66066001)(79102001)(69226001)(76482001)(74366001)(76786001)(50986001)(74706001)(74662001)(77096001)(53806001)(83322001)(59766001)(19580405001)(80022001)(56816003)(63696002)(36756003)(19580395003)(74876001)(77982001)(49866001)(54316002)(76796001)(65816001)(56776001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB190; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <8AADBC79E88B9E4E82EFA1FB17C2ACDF@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:28:04 -0000 Hi, no congestion control section in something like this? I would have expected a big red warning label "don't do this unless you have no other choice. In most cases, doing something like this is a bad idea". Especially with respect to singe pass. Confused, Stephan On 8.13.2013 18:14 , "Jonathan Lennox" wrote: >(As WG cochair) > >This is to announce a working group last call for >draft-ietf-avtext-rtp-duplication-02: > >http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/?include >_text=3D1 > >Please respond to the list by Tuesday, September 3, 2013 (i.e. 3 weeks >time) with any comments. > >This is intended as a standards track RFC. > >It is helpful to attempt to categorise the type of your comment >(including severity) and also to assist to provide any replacement text >you feel is necessary. > >If you review the document and have no comments, please tell the chairs >that you have reviewed it. This is always useful information in assessing >the degree of WG review and consensus behind the document. > > >-- >Jonathan Lennox >jonathan@vidyo.com > > >_______________________________________________ >avtext mailing list >avtext@ietf.org >https://www.ietf.org/mailman/listinfo/avtext From abegen@cisco.com Wed Aug 14 05:34:20 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2DE21F96EF for ; Wed, 14 Aug 2013 05:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMo6ayug0ga3 for ; Wed, 14 Aug 2013 05:34:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 451A421F92CD for ; Wed, 14 Aug 2013 05:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2213; q=dns/txt; s=iport; t=1376483653; x=1377693253; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xTagQt8cMDbnoNjhr5ulGfQEBAtZR+ak7E7hh5dQ+Oc=; b=AGcUoFihQNkPupKXzsENow2DcZERFhvKwkguyL/9H/kBsdBEuJDdXFEp DhRVUR/RvFoaI/PtVulBF6LHH6tr6K1y/LBY9+ojJ08bElouGhULBWbyt ZAtxrgqA1u9ySBL8EewoMwI8DEyhbFd5Y5ojoAQEAA4YIyLHjF79PKBxk I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAMd4C1KtJV2c/2dsb2JhbABbgmUhNVC+ZoEjFnSCJAEBAQMBAQEBGh00CwULAgEIDgoKFBAnCyUBAQQOBQiIAgYBC7hvkB0CMQeDG3cDmRGQJYMbgio X-IronPort-AV: E=Sophos;i="4.89,876,1367971200"; d="scan'208";a="247268360" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 14 Aug 2013 12:34:06 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7ECY5CT027639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 12:34:05 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 07:34:05 -0500 From: "Ali C. Begen (abegen)" To: Stephan Wenger Thread-Topic: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 Thread-Index: Ac6YP/xaTdbp+FggTYiP2CNM2hwwiwAEos+AADB8hQA= Date: Wed, 14 Aug 2013 12:33:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.111.88] Content-Type: text/plain; charset="us-ascii" Content-ID: <51E24AE4B4128548BB51AA18ABCA3BFB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 12:34:21 -0000 On Aug 13, 2013, at 7:25 PM, Stephan Wenger wrote: > Hi, > no congestion control section in something like this? =20 Last paragraph of section 1 has a text, which summarizes the issue well eno= ugh IMO. One can certainly write a lot more detailed guidelines, but we wil= l never be able to cover all the use or corner cases. The use of duplicatio= n has a lot of dependency on how the routing works and how the network topo= logy is structured.=20 > I would have > expected a big red warning label "don't do this unless you have no other > choice. In most cases, doing something like this is a bad idea". That is a strong statement and I dont agree with. Duplication methods are s= uccessfully deployed in many places today and it is not because we did not = have another choice, but because it made a lot more sense in such environme= nts. > Especially with respect to singe pass. > Confused, > Stephan >=20 >=20 >=20 > On 8.13.2013 18:14 , "Jonathan Lennox" wrote: >=20 >> (As WG cochair) >>=20 >> This is to announce a working group last call for >> draft-ietf-avtext-rtp-duplication-02: >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/?inclu= de >> _text=3D1 >>=20 >> Please respond to the list by Tuesday, September 3, 2013 (i.e. 3 weeks >> time) with any comments. >>=20 >> This is intended as a standards track RFC. >>=20 >> It is helpful to attempt to categorise the type of your comment >> (including severity) and also to assist to provide any replacement text >> you feel is necessary. >>=20 >> If you review the document and have no comments, please tell the chairs >> that you have reviewed it. This is always useful information in assessin= g >> the degree of WG review and consensus behind the document. >>=20 >>=20 >> -- >> Jonathan Lennox >> jonathan@vidyo.com >>=20 >>=20 >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From magnus.westerlund@ericsson.com Tue Aug 20 01:09:33 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701D911E81EB for ; Tue, 20 Aug 2013 01:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.602 X-Spam-Level: X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO6sJSq4az6e for ; Tue, 20 Aug 2013 01:09:28 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E63F311E81A3 for ; Tue, 20 Aug 2013 01:09:22 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-c0-521324312981 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F7.7D.25272.13423125; Tue, 20 Aug 2013 10:09:21 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Tue, 20 Aug 2013 10:09:20 +0200 Message-ID: <5213244D.8020207@ericsson.com> Date: Tue, 20 Aug 2013 10:09:49 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jonathan Lennox References: <8DB3E9B2-31D2-4817-9A62-EBB044D72B30@vidyo.com> In-Reply-To: <8DB3E9B2-31D2-4817-9A62-EBB044D72B30@vidyo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvja6hinCQwfunmhYf791gtbjb1MVu sX/xeWYHZo8lS34yeXy5/JnNo+3ZHfYA5igum5TUnMyy1CJ9uwSujKnrH7EVTDarOL3vKnMD Y79OFyMnh4SAicT1f3tYIWwxiQv31rOB2EICRxklnlwp6GLkArKXM0r8unmOESTBK6At8Xn/ aTCbRUBVYvPl4+wgNpuAhcTNH41gzaICwRLt27+yQdQLSpyc+YQFxBYR0JC4+OwDG8hQZoFJ jBL3NnWDJYQFnCWan70DSnAAbbORmHsI7DhOAVuJPx87mSCOk5TYtugY2C5mAT2JKVdbGCFs eYnmrbOZIY7Wlmho6mCdwCg0C8nqWUhaZiFpWcDIvIqRozi1OCk33chgEyMwgA9u+W2xg/Hy X5tDjNIcLErivFv0zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYBS7pZWR/WyRoIDCFHUd BTF2g+kb+zIl0vaJrL76YnfY4wcXjj1J7V627/Lh2BK9/FgRiyyJ6cLPTR/Pfz+L+8YZrsY3 T8yd2QqFJ26YYqJ3YkeB1MHQ1g+sPhnvLYvd1Z9H/DrwLel+39brK6ZM+CdbLfVtO5/Mno/9 Xd9DVD1ZfgpKyCXG1SmxFGckGmoxFxUnAgBuUV6xLgIAAA== Cc: "avtext@ietf.org" , "draft-ietf-avtext-rtp-duplication@tools.ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 08:09:33 -0000 Hi, I have reivewed this draft and have a few comments. 1. Section 5. Source and duplicate association. Where the single RTP session association at least have one safe but signalling support dependent solution (using SDP and ssrc-group) the spatial separated one only has half a solution. As the source and duplication goes in different RTP sessions, in cases where each session contains multiple SSRCs that has the same SDES CNAME then explicit association is not provided. Instead heuristics needs to be applied. My understanding is that these heuristics will look something like this. Look at RTP packets Seq and TS field and match those between the two RTP sessions. I agree this will work in the majority of the cases, but it is not fail-safe. If one starts two audio streams with the same codec and packetization parameters using a common starting point and the same TS and Seq they will not be possible to correctly separate. Having multiple audio streams may actually be common in environments where multiple audio tracks are provided. Having the same Seq and TS is unlikely in cases of good implementation, but can occur when randomization of Seq and TS start is not implemented. First of all, if heuristics are expected to be used, I think some basic heuristics and its failure cases should be described in this document. The SDP grouping mechanism as currently defined is not sufficient for this. The issue is that you want to group one SSRC in one RTP session with another SSRC in another RTP session. That is not supported by grouping framework that groups RTP sessions (m= blocks) and SSRC-grouping that groups SSRCs within the same RTP session (m= block). I think the best solution for this problem would be to have a RTCP SDES item that identifies identical streams. However, we have clearly not yet reached a consensus for how the different type of grouping identifiers need is supposed to work. Should they be hierarchical or purpose specific. This is the discussion around SRCNAME. https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/ It may not be necessary to have this document hold up for a solution be finished here. I think one or more will become available. However, I think it is essential that the issue, when it can arise and the requirement on a solution to be documented. 2. Congestion Considerations I think this document do need a congestion consideration section. Yes, it can double or triple the bandwidth requirement and that is worth a bit more discussion. However the bigger issue is that spatial vs single RTP session usage has different ways a congestion control needs to act. That is definitely needing a discussion. So lets consider the single RTP session duplication. As the duplicate stream has the same five tuple, and only SSRC differs it can be expected to share UDP flow and path through the network. Thus in this case the original and the duplicate must be expected to share bottlenecks. Thus any congestion control needs to operate on the aggregate of the two streams. Due to the tight coupling, even if only the source stream is congestion controlled end-to-end there will be reaction to a congestion situation in the shared bottleneck. However, if not taking the duplication into account the reaction will be less than for a single non duplicated stream with double the bandwidth from the original. In spatial separation cases, the congestion control may not know if the congested part is a shared bottleneck or not. Thus independent congestion control loops are needed for the original and the duplicate. Then as they are tightly couple the actual used bandwidth needs to be the lower common denominator between the independent controllers. Otherwise if the bottleneck is not shared and on the duplicate path, then the original will go through fine, but not the duplicate. Thirdly, the congestion state with end-to-end vs between the duplication point and re-assembly point needs to be discussed. This is the same issue that using FEC below the RTP stack has. As the end-receiver are not seeing the losses, except for losses in both streams, the receiver sees a more ideal path than reality. Thus injected RTCP reports from the re-assembly point or even congestion control messages to the media source from re-assembly needs to be considered to make the system work. These issues I do expect to see discussed in a congestion control considerations section. 3. Section 7. I think the end-to-end usage of SRTP encryption and authentication with on the path duplication and de-duplication needs to be a bit more explicit about that this can be done, as long as the RTP headers entering the duplication node is identical after de-duplication. If not the end-receiver can not decrypt or authenticate the packets successfully. Then the next issue is the protection of any such duplication system. The basic threat I see is that if I know a duplication service is running in a network and know which 5-tuple filters it is using, I could use that node to amplify my DDOS attack. Thus letting the target networks services be used against itself. If one believe this is a threat then one needs to authenticate the incomming traffic prior to duplication as being the traffic authorized for duplication. I think several solutions exist to that problem. Cheers Magnus On 2013-08-13 18:14, Jonathan Lennox wrote: > (As WG cochair) > > This is to announce a working group last call for draft-ietf-avtext-rtp-duplication-02: > > http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/?include_text=1 > > Please respond to the list by Tuesday, September 3, 2013 (i.e. 3 weeks time) with any comments. > > This is intended as a standards track RFC. > > It is helpful to attempt to categorise the type of your comment (including severity) and also to assist to provide any replacement text you feel is necessary. > > If you review the document and have no comments, please tell the chairs that you have reviewed it. This is always useful information in assessing the degree of WG review and consensus behind the document. > > > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 abegen@cisco.com Tue Aug 20 04:12:14 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618B311E820B for ; Tue, 20 Aug 2013 04:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p-PDASTyGWT for ; Tue, 20 Aug 2013 04:12:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDFE11E820A for ; Tue, 20 Aug 2013 04:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10033; q=dns/txt; s=iport; t=1376997129; x=1378206729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+zykuDWWFWrdFEITnbUvUOaEaIk4rKP+2SoZmbcvI/Y=; b=dvLIu9u3Zmd3SrT0k2IsvhdtzfNyGLw2AZ2OETULjIf8FxHqfPKCEWpn WKjE2DRqNA1bWFCI8QNbNTOMeXIW1+d8bzqV2ktg5dqaB3iYW8WFHkfpT ksobxVrZeQUCic3Xj9ephkOdm2d1jeYXVBuYi1yJVimlooVS71A7stHsT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAB9OE1KtJV2b/2dsb2JhbABagmQhNVG/U4EjFnSCJAEBAQMBAQEBCRFKBwsFCQICAQgYCgsSBxsMCxQRAQEEDgUIE4dvBgELrDMEjw+BFgIxBwqDEXcDiHWQHJAogxyBcTk X-IronPort-AV: E=Sophos;i="4.89,919,1367971200"; d="scan'208";a="249385522" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 20 Aug 2013 11:12:03 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7KBC3Fb006114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 11:12:03 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 06:12:02 -0500 From: "Ali C. Begen (abegen)" To: Magnus Westerlund Thread-Topic: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 Thread-Index: Ac6YP/xaTdbp+FggTYiP2CNM2hwwiwFZpBKAAAZdcQA= Date: Tue, 20 Aug 2013 11:12:02 +0000 Message-ID: References: <8DB3E9B2-31D2-4817-9A62-EBB044D72B30@vidyo.com> <5213244D.8020207@ericsson.com> In-Reply-To: <5213244D.8020207@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.96.43] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 11:12:14 -0000 Thanks for the review. On Aug 20, 2013, at 11:09 AM, Magnus Westerlund wrote: > Hi, >=20 > I have reivewed this draft and have a few comments. >=20 > 1. Section 5. Source and duplicate association. >=20 > Where the single RTP session association at least have one safe but > signalling support dependent solution (using SDP and ssrc-group) the > spatial separated one only has half a solution. As the source and > duplication goes in different RTP sessions, in cases where each session > contains multiple SSRCs that has the same SDES CNAME then explicit > association is not provided. Instead heuristics needs to be applied. We discussed this months ago. See my email dated march 19th summarizing the= motivation for the current text. >=20 > My understanding is that these heuristics will look something like this. > Look at RTP packets Seq and TS field and match those between the two RTP > sessions. I agree this will work in the majority of the cases, but it is > not fail-safe. If one starts two audio streams with the same codec and > packetization parameters using a common starting point and the same TS > and Seq they will not be possible to correctly separate. Having multiple > audio streams may actually be common in environments where multiple > audio tracks are provided. Having the same Seq and TS is unlikely in > cases of good implementation, but can occur when randomization of Seq > and TS start is not implemented. >=20 > First of all, if heuristics are expected to be used, I think some basic > heuristics and its failure cases should be described in this document. The current draft intends to address the foremost important use cases. Thos= e use cases are already in deployment not like the ones that might get depl= oyed in some future. >=20 > The SDP grouping mechanism as currently defined is not sufficient for > this. The issue is that you want to group one SSRC in one RTP session > with another SSRC in another RTP session. That is not supported by > grouping framework that groups RTP sessions (m=3D blocks) and > SSRC-grouping that groups SSRCs within the same RTP session (m=3D block). We want two basic things and that is what the draft supports: 1) grouping the original and the dup stream in separate m lines (there woul= d not be other streams in these m lines) 2) grouping two ssrc's carried in the same m line (there could be other ssr= c's in the same m line) >=20 > I think the best solution for this problem would be to have a RTCP SDES > item that identifies identical streams. However, we have clearly not yet > reached a consensus for how the different type of grouping identifiers > need is supposed to work. Should they be hierarchical or purpose > specific. This is the discussion around SRCNAME. > https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcnam= e/ Unfortunately the above draft or other similar ideas have not progressed. W= e have been holding our draft to wait for this discussion to get into a sha= pe but really it has already been a year and an immediate solution is not i= n the horizon. So, that's why in March, I wrote that email to the group and= we moved forward. Lets not restart those discussions again. >=20 > It may not be necessary to have this document hold up for a solution be > finished here. I think one or more will become available. However, I > think it is essential that the issue, when it can arise and the > requirement on a solution to be documented. When/if a solution is agreed, we can always revise whatever has been specif= ied in the current rtp dup draft. I strongly object to holding our draft an= y longer as I explained to the avtext and mmusic chairs a while ago. >=20 > 2. Congestion Considerations >=20 > I think this document do need a congestion consideration section. Yes, > it can double or triple the bandwidth requirement and that is worth a > bit more discussion. However the bigger issue is that spatial vs single > RTP session usage has different ways a congestion control needs to act. > That is definitely needing a discussion. >=20 > So lets consider the single RTP session duplication. As the duplicate > stream has the same five tuple, and only SSRC differs it can be expected > to share UDP flow and path through the network. Thus in this case the > original and the duplicate must be expected to share bottlenecks. Thus > any congestion control needs to operate on the aggregate of the two > streams. Due to the tight coupling, even if only the source stream is > congestion controlled end-to-end there will be reaction to a congestion > situation in the shared bottleneck. However, if not taking the > duplication into account the reaction will be less than for a single non > duplicated stream with double the bandwidth from the original. I am not disagreeing with what you said above. But, what is there to specif= y or discuss in the document? If the streams are going thru the same route,= duping will double your bw. this may or may not be a problem from a conges= tion viewpoint. Actually, it should not be for the cases this draft is supp= osed to be used. Remember duping is not a good idea when you are fighting w= ith the congestion related losses. It is only useful when you are dealing w= ith outage like problems. IOW, if someone is duping and that is causing con= gestion, it is a bad implementation. That is not how/when RTP duping is sup= posed to be used. >=20 > In spatial separation cases, the congestion control may not know if the > congested part is a shared bottleneck or not. Thus independent > congestion control loops are needed for the original and the duplicate. > Then as they are tightly couple the actual used bandwidth needs to be > the lower common denominator between the independent controllers. > Otherwise if the bottleneck is not shared and on the duplicate path, > then the original will go through fine, but not the duplicate. >=20 > Thirdly, the congestion state with end-to-end vs between the duplication > point and re-assembly point needs to be discussed. This is the same > issue that using FEC below the RTP stack has. As the end-receiver are > not seeing the losses, except for losses in both streams, the receiver > sees a more ideal path than reality. Thus injected RTCP reports from the > re-assembly point or even congestion control messages to the media > source from re-assembly needs to be considered to make the system work. If the reassembly point is not the ultimate receiver (which is true most of= the time), you are right. This does not have any relevance to the congesti= on control, however. The reassembly point's RTCP reports will be relevant t= o the sender in terms of adjusting the duplication interval, etc. the ultim= ate endpoint's RTCP reports are only relevant to determine the loss beyond = the reassembly point.=20 >=20 > These issues I do expect to see discussed in a congestion control > considerations section. >=20 > 3. Section 7. >=20 > I think the end-to-end usage of SRTP encryption and authentication with > on the path duplication and de-duplication needs to be a bit more > explicit about that this can be done, as long as the RTP headers > entering the duplication node is identical after de-duplication. If not > the end-receiver can not decrypt or authenticate the packets successfully= . That is my understanding, too. I will let SRTP folks to comment on this and= I will be happy to add/change text if necessary. >=20 > Then the next issue is the protection of any such duplication system. > The basic threat I see is that if I know a duplication service is > running in a network and know which 5-tuple filters it is using, I could > use that node to amplify my DDOS attack. Thus letting the target > networks services be used against itself. If one believe this is a > threat then one needs to authenticate the incomming traffic prior to > duplication as being the traffic authorized for duplication. I think > several solutions exist to that problem. The stream properties defined in the SDP need to match to the stream(s) ing= ested by the attacker, right? So, if you know your SDP is not hacked into,= is there still a problem? >=20 >=20 > Cheers >=20 > Magnus >=20 >=20 >=20 >=20 >=20 > On 2013-08-13 18:14, Jonathan Lennox wrote: >> (As WG cochair) >>=20 >> This is to announce a working group last call for draft-ietf-avtext-rtp-= duplication-02: >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/?inclu= de_text=3D1 >>=20 >> Please respond to the list by Tuesday, September 3, 2013 (i.e. 3 weeks t= ime) with any comments. >>=20 >> This is intended as a standards track RFC. >>=20 >> It is helpful to attempt to categorise the type of your comment (includi= ng severity) and also to assist to provide any replacement text you feel is= necessary. >>=20 >> If you review the document and have no comments, please tell the chairs = that you have reviewed it. This is always useful information in assessing t= he degree of WG review and consensus behind the document. >>=20 >>=20 >> -- >> Jonathan Lennox >> jonathan@vidyo.com >>=20 >>=20 >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From magnus.westerlund@ericsson.com Tue Aug 20 06:42:29 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DDC11E80D9 for ; Tue, 20 Aug 2013 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.53 X-Spam-Level: X-Spam-Status: No, score=-103.53 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLsFgoVIQD1c for ; Tue, 20 Aug 2013 06:42:13 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3DD11E80F1 for ; Tue, 20 Aug 2013 06:42:12 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-b9-5213723375a9 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6B.42.25272.33273125; Tue, 20 Aug 2013 15:42:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Tue, 20 Aug 2013 15:42:10 +0200 Message-ID: <52137259.8090702@ericsson.com> Date: Tue, 20 Aug 2013 15:42:49 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <8DB3E9B2-31D2-4817-9A62-EBB044D72B30@vidyo.com> <5213244D.8020207@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvja5xkXCQweUjshYPts9ltPh47war xf7F55kdmD2m/N7I6rFkyU8mj7Znd9gDmKO4bFJSczLLUov07RK4Mja/+s5WsC6sYt66VSwN jG2uXYycHBICJhLHn+1hh7DFJC7cW8/WxcjFISRwlFGiafEcZghnOaPEr96pYFW8AtoSZ76d ZQaxWQRUJTZdfQYWZxOwkLj5o5ENxBYVCJZo3/6VDaJeUOLkzCcsILaIgJ7E/o5pjCA2s4Cv xLGTy8BqhAWcJZqfvQOzhQTmMko0Xi8EsTmBal4tPswCcZ2kxLZFx9ghevUkplxtgZojL9G8 dTYzRK+2RENTB+sERqFZSFbPQtIyC0nLAkbmVYwcxanFSbnpRgabGIEhfHDLb4sdjJf/2hxi lOZgURLn3aJ3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4/rThg8nd5o1hqv27jGp8mQ9 k1hxTnnu/oOrlDeHyu03CfpTLPnI2TPz9DLJq3Yv5vYqBG+fdPii0uFgI2erNXlJtyWls0tV VgVtSrVQ2M0XoRt5NvUtr3iNReRTqw26J//Ha8ZdZvt2oyMx77d5yQQjuclJnvO2/1bT+dYS aRofYdYfob9XiaU4I9FQi7moOBEALq9HpC8CAAA= Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 13:42:29 -0000 On 2013-08-20 13:12, Ali C. Begen (abegen) wrote: > Thanks for the review. > > On Aug 20, 2013, at 11:09 AM, Magnus Westerlund > wrote: > >> Hi, >> >> I have reivewed this draft and have a few comments. >> >> 1. Section 5. Source and duplicate association. >> >> Where the single RTP session association at least have one safe >> but signalling support dependent solution (using SDP and >> ssrc-group) the spatial separated one only has half a solution. As >> the source and duplication goes in different RTP sessions, in cases >> where each session contains multiple SSRCs that has the same SDES >> CNAME then explicit association is not provided. Instead heuristics >> needs to be applied. > > We discussed this months ago. See my email dated march 19th > summarizing the motivation for the current text. > >> >> My understanding is that these heuristics will look something like >> this. Look at RTP packets Seq and TS field and match those between >> the two RTP sessions. I agree this will work in the majority of the >> cases, but it is not fail-safe. If one starts two audio streams >> with the same codec and packetization parameters using a common >> starting point and the same TS and Seq they will not be possible to >> correctly separate. Having multiple audio streams may actually be >> common in environments where multiple audio tracks are provided. >> Having the same Seq and TS is unlikely in cases of good >> implementation, but can occur when randomization of Seq and TS >> start is not implemented. >> >> First of all, if heuristics are expected to be used, I think some >> basic heuristics and its failure cases should be described in this >> document. > > The current draft intends to address the foremost important use > cases. Those use cases are already in deployment not like the ones > that might get deployed in some future. Yes, my complaint is that you are not explicit enough on how you expect the heuristics to work and what its limitations are. > >> >> The SDP grouping mechanism as currently defined is not sufficient >> for this. The issue is that you want to group one SSRC in one RTP >> session with another SSRC in another RTP session. That is not >> supported by grouping framework that groups RTP sessions (m= >> blocks) and SSRC-grouping that groups SSRCs within the same RTP >> session (m= block). > > We want two basic things and that is what the draft supports: > > 1) grouping the original and the dup stream in separate m lines > (there would not be other streams in these m lines) 2) grouping two > ssrc's carried in the same m line (there could be other ssrc's in the > same m line) I understand that the common deployment for 1) is that there is only a single stream. I just want the document to be clear that in cases where there are multiple ones. Which they can be from a standards perspective even if not commonly done today. > >> >> I think the best solution for this problem would be to have a RTCP >> SDES item that identifies identical streams. However, we have >> clearly not yet reached a consensus for how the different type of >> grouping identifiers need is supposed to work. Should they be >> hierarchical or purpose specific. This is the discussion around >> SRCNAME. >> https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/ > >> > Unfortunately the above draft or other similar ideas have not > progressed. We have been holding our draft to wait for this > discussion to get into a shape but really it has already been a year > and an immediate solution is not in the horizon. So, that's why in > March, I wrote that email to the group and we moved forward. Lets not > restart those discussions again. I have no issue with this draft moving forward without any clear reference to a solution today. What I am asking is for the draft to acknowledge the shortcomming and be clear on what its requirements are. > >> >> It may not be necessary to have this document hold up for a >> solution be finished here. I think one or more will become >> available. However, I think it is essential that the issue, when it >> can arise and the requirement on a solution to be documented. > > When/if a solution is agreed, we can always revise whatever has been > specified in the current rtp dup draft. I strongly object to holding > our draft any longer as I explained to the avtext and mmusic chairs a > while ago. Yes, and I have no wish to hold it up any longer either. I just want you to document the short commings of the current solution and warn any users of it where the issues will arise. > >> >> 2. Congestion Considerations >> >> I think this document do need a congestion consideration section. >> Yes, it can double or triple the bandwidth requirement and that is >> worth a bit more discussion. However the bigger issue is that >> spatial vs single RTP session usage has different ways a congestion >> control needs to act. That is definitely needing a discussion. >> >> So lets consider the single RTP session duplication. As the >> duplicate stream has the same five tuple, and only SSRC differs it >> can be expected to share UDP flow and path through the network. >> Thus in this case the original and the duplicate must be expected >> to share bottlenecks. Thus any congestion control needs to operate >> on the aggregate of the two streams. Due to the tight coupling, >> even if only the source stream is congestion controlled end-to-end >> there will be reaction to a congestion situation in the shared >> bottleneck. However, if not taking the duplication into account the >> reaction will be less than for a single non duplicated stream with >> double the bandwidth from the original. > > I am not disagreeing with what you said above. But, what is there to > specify or discuss in the document? If the streams are going thru the > same route, duping will double your bw. this may or may not be a > problem from a congestion viewpoint. Actually, it should not be for > the cases this draft is supposed to be used. Remember duping is not a > good idea when you are fighting with the congestion related losses. > It is only useful when you are dealing with outage like problems. > IOW, if someone is duping and that is causing congestion, it is a bad > implementation. That is not how/when RTP duping is supposed to be > used. >> >> In spatial separation cases, the congestion control may not know if >> the congested part is a shared bottleneck or not. Thus independent >> congestion control loops are needed for the original and the >> duplicate. Then as they are tightly couple the actual used >> bandwidth needs to be the lower common denominator between the >> independent controllers. Otherwise if the bottleneck is not shared >> and on the duplicate path, then the original will go through fine, >> but not the duplicate. >> >> Thirdly, the congestion state with end-to-end vs between the >> duplication point and re-assembly point needs to be discussed. This >> is the same issue that using FEC below the RTP stack has. As the >> end-receiver are not seeing the losses, except for losses in both >> streams, the receiver sees a more ideal path than reality. Thus >> injected RTCP reports from the re-assembly point or even congestion >> control messages to the media source from re-assembly needs to be >> considered to make the system work. > > If the reassembly point is not the ultimate receiver (which is true > most of the time), you are right. This does not have any relevance to > the congestion control, however. The reassembly point's RTCP reports > will be relevant to the sender in terms of adjusting the duplication > interval, etc. the ultimate endpoint's RTCP reports are only relevant > to determine the loss beyond the reassembly point. Yes, the issue I see is that people insert these in the middle of a path, and thus prevent the congestion control to work. However, having these node send RTCP to the original sender is not likely, especially from a security perspective, thus some warning of the impact and the responsibility of then the duplication. >From my perspective if the duplication mechanism is injected in the middle of e2e path and then improves the performance of that without making the end nodes aware of its existence, then it the duplication that are responsible for the congestion response and thus needs to have a mechanism to detect and act on congestion in its paths. This is clearly an issue with spatial duplication where one path can get congested to hell and the other works fine and e2e it is fine. Only the duplciation adder can really respond to dealing with the congestion on that path. > >> >> These issues I do expect to see discussed in a congestion control >> considerations section. >> >> 3. Section 7. >> >> I think the end-to-end usage of SRTP encryption and authentication >> with on the path duplication and de-duplication needs to be a bit >> more explicit about that this can be done, as long as the RTP >> headers entering the duplication node is identical after >> de-duplication. If not the end-receiver can not decrypt or >> authenticate the packets successfully. > > That is my understanding, too. I will let SRTP folks to comment on > this and I will be happy to add/change text if necessary. > >> >> Then the next issue is the protection of any such duplication >> system. The basic threat I see is that if I know a duplication >> service is running in a network and know which 5-tuple filters it >> is using, I could use that node to amplify my DDOS attack. Thus >> letting the target networks services be used against itself. If one >> believe this is a threat then one needs to authenticate the >> incomming traffic prior to duplication as being the traffic >> authorized for duplication. I think several solutions exist to that >> problem. > > The stream properties defined in the SDP need to match to the > stream(s) ingested by the attacker, right? So, if you know your SDP > is not hacked into, is there still a problem? Yes, if the attacker also have the SDP. And the network is not source address validating at its boundaries, then I can potentially inject packets from the outside, that will then be duplicated. For multicast cases it will be highly dependent on how the multicast routing is set up. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 bernard_aboba@hotmail.com Thu Aug 22 16:12:41 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957C321F9950 for ; Thu, 22 Aug 2013 16:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOXm8reVq6w3 for ; Thu, 22 Aug 2013 16:12:36 -0700 (PDT) Received: from blu0-omc1-s6.blu0.hotmail.com (blu0-omc1-s6.blu0.hotmail.com [65.55.116.17]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6821F9298 for ; Thu, 22 Aug 2013 16:12:36 -0700 (PDT) Received: from BLU169-W131 ([65.55.116.8]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Aug 2013 16:12:36 -0700 X-TMN: [ErelZW7Xj/zPyIRElhmSriynSxgXE2SsSovXnb9hgCM=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_6740c6be-8992-48bf-83fe-ed517917ada4_" From: Bernard Aboba To: Jonathan Lennox , Adam Fineberg , "avtext@ietf.org" Date: Thu, 22 Aug 2013 16:12:35 -0700 Importance: Normal In-Reply-To: References: <20130709170205.4276.31863.idtracker@ietfa.amsl.com>, <51E71C82.7090608@vline.me>, MIME-Version: 1.0 X-OriginalArrivalTime: 22 Aug 2013 23:12:36.0220 (UTC) FILETIME=[16CF1BC0:01CE9F8D] Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 23:12:41 -0000 --_6740c6be-8992-48bf-83fe-ed517917ada4_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IEpvbmF0aGFuIHNhaWQ6IA0KIA0KIlVuZm9ydHVuYXRlbHksIFJUUCBkb2VzbuKAmXQgcmVhbGx5 IGxldCB5b3UgZG8gdGhpcy4gIFRoZSBwcm9ibGVtIGlzIHRoYXQgYnkganVzdCBkcm9wcGluZyBw YWNrZXRzIHdpdGhvdXQgcmV3cml0aW5nIFJUUCBzZXF1ZW5jZSBudW1iZXJzIG9yIFJUQ1Agc2Vu ZGVyIHJlcG9ydHMsIHRoaXMgaXMgZ29pbmcgdG8gbG9vayBsaWtlIGVub3Jtb3VzIHBhY2tldCBs b3NzIHRvIFJUUCAod2hpY2gsIGluIGEgc2Vuc2UsIGl0IGlzKS4gIEEgbWlkZGxlYm94IGxpa2Ug dGhpcyDigJMgd2hpY2ggaXMgYWN0aW5nIGFzIGEgbWVkaWEtbW9kaWZ5aW5nIFJUUCB0cmFuc2xh dG9yLCBpbiBSVFAgdGVybWlub2xvZ3kg4oCTIG5lZWRzIHRvIHJld3JpdGUgUlRQIGhlYWRlcnMg YW5kIFJUQ1Agc2VuZGVyIHJlcG9ydHMgaW4gb3JkZXIgdG8ga2VlcCB0aGUgc3RyZWFtIGFuZCBp dHMgbWV0YWRhdGEgY29uc2lzdGVudCBhbmQgdmFsaWQuIElzIHRoZXJlIHNvbWV0aGluZyBJ4oCZ bSBtaXNzaW5nIGhlcmU/IiBbQkFdIFlvdXIgc3RhdGVtZW50IGFzc3VtZXMgdGhhdCBhbGwgdGhl IGxheWVycyBhcmUgc2VudCBvbiB0aGUgc2FtZSBTU1JDLiAod2hpY2ggaXMgaG93IEkgYmVsaWV2 ZSBWUDggZG9lcyBpdCkuICAgIElmIHRoZSBsYXllcnMgYXJlIHNlbnQgb24gaW5kaXZpZHVhbCBT U1JDcyAoYXMgY2FuIGJlIGRvbmUgd2l0aCBILjI2NC9TVkMpLCB0aGVuIHJld3JpdGluZyBvZiBz ZXF1ZW5jZSBudW1iZXJzIG9yIFJUQ1Agc2VuZGVyIHJlcG9ydHMgY2FuIGJlIGF2b2lkZWQuICAg VGhlcmUgYXJlIHNvbWUgY2F2ZWF0cyB0aG91Z2guICBUeXBpY2FsbHkgdGhlcmUgaXMgc3RpbGwg YSBuZWVkIHRvIGluZGljYXRlIHRoYXQgbGF5ZXJzIGFyZSBiZWluZyBkcm9wcGVkOyBpZiB0aGlz IGlzIGhhbmRsZWQgaW4gUlRQLCB0aGVuIGFuIFNFSSBtZXNzYWdlIG5lZWRzIHRvIGJlIGluc2Vy dGVkLCBzbyB0aGVyZSB3aWxsIHN0aWxsIGJlIHNvbWUgZW5jcnlwdC9kZWNyeXB0IG9wZXJhdGlv bnMuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGcm9tOiBBZGFtIEZpbmViZXJnIFttYWlsdG86Zmlu ZWJlcmdAdmxpbmUubWVdIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDEzIDY6MzcgUE0N ClRvOiBhdnRleHRAaWV0Zi5vcmcNClN1YmplY3Q6IFthdnRleHRdIEZ3ZDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1maW5lYmVyZy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0 LTAwLnR4dCBIaSwNCg0KSSdtIHdvcmtpbmcgb24gV2ViUlRDIHNlcnZpY2VzIGFuZCBoYXZlIGZv dW5kIHRoYXQgd2hpbGUgZGV2ZWxvcGluZyBzZXJ2aWNlcyB0aGF0IGZvcndhcmQgVlA4IHZpZGVv IHN0cmVhbXMgaWYgd2Ugd2FudCB0byB0YWtlIGFkdmFudGFnZSBvZiB0aGUgVlA4IHRlbXBvcmFs IHNjYWxpbmcgd2UgbXVzdCBnZXQgdGhlIHRlbXBvcmFsIGxheWVyIGluZm9ybWF0aW9uIGZyb20g dGhlIFJUUCBoZWFkZXIgd2hpY2ggcmVxdWlyZXMgdXMgdG8gZGVjcnlwdCB0aGUgU1JUUCBwYWNr ZXRzLu+/vcKB77+9IFRoaXMgaXMgdW5kZXNpcmFibGUgYm90aCBiZWNhdXNlIHRoZSBtaWRkbGVi b3ggbmVlZHMgdG8gaGF2ZSBhY2Vzc3MgdG8gdGhlIGtleXMgYXMgd2VsbCBhcyB0aGUgYmVjYXVz ZSBvZiB0aGUgYWRkZWQgb3ZlcmhlYWQgb2YgdGhlIGRlY3J5cHQvZW5jcnlwdCBjeWNsZS7vv73C ge+/vSBUaGlzIGRyYWZ0IHByb3Bvc2VzIGFuIFJUUCBoZWFkZXIgZXh0ZW5zaW9uIHRoYXQgd2ls bCBhbGxvdyB1cyB0byB1c2UgdGhlIFZQOCB0ZW1wb3JhbCBsYXllciBpbmZvcm1hdGlvbiBpbmNs dWRlZCBpbiB0aGUgaGVhZGVyIGV4dGVuc2lvbiBhbmQgdGhlcmVmb3JlIGRvIGZvcndhcmRpbmcg d2l0aG91dCBTUlRQIGRlY3J5cHRpb24u77+9woHvv70gQ29tbWVudHMgd2VsY29tZS4NCg0KUmVn YXJkcywNCkFkYW0gRmluZWJlcmdmaW5lYmVyZ0B2bGluZS5jb20NCg0KLS0tLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLS0tLSBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQtMDAudHh0RGF0ZTogVHVl LCAwOSBKdWwgMjAxMyAxMDowMjowNSAtMDcwMEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z1RvOiBBZGFtIEZpbmViZXJnIDxmaW5lYmVyZ0B2bGluZS5jb20+IEEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1maW5lYmVyZy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0LTAwLnR4dGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRhbSBGaW5lYmVyZyBhbmQgcG9zdGVkIHRv IHRoZUlFVEYgcmVwb3NpdG9yeS4gRmlsZW5hbWU6ICAgICAgIGRyYWZ0LWZpbmViZXJnLWF2dGV4 dC10ZW1wb3JhbC1sYXllci1leHRSZXZpc2lvbjogICAgICAgMDBUaXRsZTogICAgICAgICAgQSBS ZWFsLVRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChSVFApIEhlYWRlciBFeHRlbnNpb24gZm9yIFZQ OCBUZW1wb3JhbCBMYXllciBJbmZvcm1hdGlvbkNyZWF0aW9uIGRhdGU6ICAyMDEzLTA3LTA4R3Jv dXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbk51bWJlciBvZiBwYWdlczogNlVSTDog ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZmlu ZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dC0wMC50eHRTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBv cmFsLWxheWVyLWV4dEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dC0wMCAgQWJzdHJhY3Q6ICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIHBhY2tldHMgb2YgUmVh bC1UaW1lICAgVHJhbnBvcnQgUHJvdG9jb2wgKFJUUCkgdmlkZW8gc3RyZWFtcyBlbmNvZGVkIHdp dGggdGhlIFZQOCBjb2RlYyBjYW4gICBpbmRpY2F0ZSwgaW4gYW4gUlRQIGhlYWRlciBleHRlbnNp b24sIHRoZSB0ZW1wb3JhbCBsYXllciBpbmZvcm1hdGlvbiAgIGFib3V0IHRoZSBmcmFtZSBlbmNv ZGVkIGluIHRoZSBSVFAgcGFja2V0LiAgVGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUgICB1c2VkIGlu IGEgbWlkZGxlYm94IHBlcmZvcm1pbmcgYmFuZHdpZHRoIG1hbmFnZW1lbnQgb2Ygc3RyZWFtcyAg IHdpdGhvdXQgcmVxdWlyaW5nIGl0IHRvIGRlY3J5cHQgdGhlIHN0cmVhbXMuICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0ICANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnJ0Y3dlYiBtYWlsaW5nIGxpc3QKcnRjd2Vi QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIAkJ IAkgICAJCSAg --_6740c6be-8992-48bf-83fe-ed517917ada4_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+Jm5ic3A7Sm9uYXRoYW4gc2FpZDogPEJSPiZuYnNwOzxC Uj48ZGl2PjxkaXYgY2xhc3M9ImVjeFdvcmRTZWN0aW9uMSI+PHAgY2xhc3M9ImVjeE1zb05vcm1h bCI+PHNwYW4gc3R5bGU9J2NvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogIkNh bGlicmkiLCJzYW5zLXNlcmlmIjsgZm9udC1zaXplOiAxMXB0Oyc+IlVuZm9ydHVuYXRlbHksIFJU UCBkb2VzbuKAmXQgcmVhbGx5IGxldCB5b3UgZG8gdGhpcy4mbmJzcDsgVGhlIHByb2JsZW0gaXMg dGhhdCBieSBqdXN0IGRyb3BwaW5nIHBhY2tldHMgd2l0aG91dCByZXdyaXRpbmcgUlRQIHNlcXVl bmNlIG51bWJlcnMgb3IgUlRDUCBzZW5kZXIgcmVwb3J0cywgdGhpcyBpcyBnb2luZyB0byBsb29r IGxpa2UgZW5vcm1vdXMgcGFja2V0IGxvc3MgdG8gUlRQICh3aGljaCwgaW4gYSBzZW5zZSwgaXQg aXMpLiZuYnNwOyBBIG1pZGRsZWJveCBsaWtlIHRoaXMg4oCTIHdoaWNoIGlzIGFjdGluZyBhcyBh IG1lZGlhLW1vZGlmeWluZyBSVFAgdHJhbnNsYXRvciwgaW4gUlRQIHRlcm1pbm9sb2d5IOKAkyBu ZWVkcyB0byByZXdyaXRlIFJUUCBoZWFkZXJzIGFuZCBSVENQIHNlbmRlciByZXBvcnRzIGluIG9y ZGVyIHRvIGtlZXAgdGhlIHN0cmVhbSBhbmQgaXRzIG1ldGFkYXRhIGNvbnNpc3RlbnQgYW5kIHZh bGlkLjwvc3Bhbj48L3A+PHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9J2NvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsg Zm9udC1zaXplOiAxMXB0Oyc+PC9zcGFuPiZuYnNwOzwvcD48cCBjbGFzcz0iZWN4TXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0nY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDExcHQ7Jz5JcyB0aGVyZSBzb21ldGhpbmcg SeKAmW0gbWlzc2luZyBoZXJlPyI8L3NwYW4+PC9wPjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSdjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7IGZvbnQtc2l6ZTogMTFwdDsnPjwvc3Bhbj4mbmJzcDs8L3A+PHAgY2xh c3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9J2NvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgZm9udC1zaXplOiAxMXB0Oyc+W0JB XSBZb3VyIDxzcGFuIHN0eWxlPSdjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6 ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IGZvbnQtc2l6ZTogMTFwdDsnPnN0YXRlbWVudCBhc3N1 bWVzIHRoYXQgYWxsIHRoZSBsYXllcnMgYXJlIHNlbnQgb24gdGhlIHNhbWUgU1NSQy4gKHdoaWNo IGlzIGhvdyBJIGJlbGlldmUgVlA4IGRvZXMgaXQpLiZuYnNwOyAmbmJzcDsgSWYgdGhlIGxheWVy cyBhcmUgc2VudCBvbiBpbmRpdmlkdWFsIFNTUkNzIChhcyBjYW4gYmUgZG9uZSB3aXRoIEguMjY0 L1NWQyksIHRoZW4gcmV3cml0aW5nIG9mIHNlcXVlbmNlIG51bWJlcnMgb3IgUlRDUCBzZW5kZXIg cmVwb3J0cyBjYW4gYmUgYXZvaWRlZC4mbmJzcDsmbmJzcDsgVGhlcmUgYXJlIHNvbWUmbmJzcDtj YXZlYXRzIHRob3VnaC4mbmJzcDsgVHlwaWNhbGx5IHRoZXJlIGlzIHN0aWxsIGEgbmVlZCB0byBp bmRpY2F0ZSB0aGF0IGxheWVycyBhcmUgYmVpbmcgZHJvcHBlZDsgaWYgdGhpcyBpcyBoYW5kbGVk IGluIFJUUCwgdGhlbiBhbiBTRUkgbWVzc2FnZSBuZWVkcyB0byBiZSBpbnNlcnRlZCwgc28gdGhl cmUgd2lsbCBzdGlsbCBiZSBzb21lIGVuY3J5cHQvZGVjcnlwdCBvcGVyYXRpb25zLiZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwvcD48cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0nY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYi OyBmb250LXNpemU6IDExcHQ7Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9ImJv cmRlci13aWR0aDogMXB0IG1lZGl1bSBtZWRpdW07IGJvcmRlci1zdHlsZTogc29saWQgbm9uZSBu b25lOyBib3JkZXItY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKSBjdXJyZW50Q29sb3IgY3VycmVu dENvbG9yOyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiPjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSdjb2xvcjogd2luZG93dGV4dDsgZm9udC1mYW1pbHk6ICJUYWhvbWEiLCJz YW5zLXNlcmlmIjsgZm9udC1zaXplOiAxMHB0Oyc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdjb2xvcjogd2luZG93dGV4dDsgZm9udC1mYW1pbHk6ICJUYWhvbWEiLCJzYW5zLXNlcmlmIjsg Zm9udC1zaXplOiAxMHB0Oyc+IEFkYW0gRmluZWJlcmcgW21haWx0bzpmaW5lYmVyZ0B2bGluZS5t ZV0gPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgNjozNyBQTTxicj48 Yj5Ubzo8L2I+IGF2dGV4dEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gW2F2dGV4dF0gRndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1w b3JhbC1sYXllci1leHQtMDAudHh0PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz0iZWN4 TXNvTm9ybWFsIj4mbmJzcDs8L3A+PHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+SGksPGJyPjxicj5J J20gd29ya2luZyBvbiBXZWJSVEMgc2VydmljZXMgYW5kIGhhdmUgZm91bmQgdGhhdCB3aGlsZSBk ZXZlbG9waW5nIHNlcnZpY2VzIHRoYXQgZm9yd2FyZCBWUDggdmlkZW8gc3RyZWFtcyBpZiB3ZSB3 YW50IHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSBWUDggdGVtcG9yYWwgc2NhbGluZyB3ZSBtdXN0 IGdldCB0aGUgdGVtcG9yYWwgbGF5ZXIgaW5mb3JtYXRpb24gZnJvbSB0aGUgUlRQIGhlYWRlciB3 aGljaCByZXF1aXJlcyB1cyB0byBkZWNyeXB0IHRoZSBTUlRQIHBhY2tldHMuPHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiAiVGFob21hIiwic2Fucy1zZXJpZiI7Jz7vv708L3NwYW4+woE8c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6ICJUYWhvbWEiLCJzYW5zLXNlcmlmIjsnPu+/vTwvc3Bhbj4gVGhp cyBpcyB1bmRlc2lyYWJsZSBib3RoIGJlY2F1c2UgdGhlIG1pZGRsZWJveCBuZWVkcyB0byBoYXZl IGFjZXNzcyB0byB0aGUga2V5cyBhcyB3ZWxsIGFzIHRoZSBiZWNhdXNlIG9mIHRoZSBhZGRlZCBv dmVyaGVhZCBvZiB0aGUgZGVjcnlwdC9lbmNyeXB0IGN5Y2xlLjxzcGFuIHN0eWxlPSdmb250LWZh bWlseTogIlRhaG9tYSIsInNhbnMtc2VyaWYiOyc+77+9PC9zcGFuPsKBPHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiAiVGFob21hIiwic2Fucy1zZXJpZiI7Jz7vv708L3NwYW4+IFRoaXMgZHJhZnQg cHJvcG9zZXMgYW4gUlRQIGhlYWRlciBleHRlbnNpb24gdGhhdCB3aWxsIGFsbG93IHVzIHRvIHVz ZSB0aGUgVlA4IHRlbXBvcmFsIGxheWVyIGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIHRoZSBoZWFk ZXIgZXh0ZW5zaW9uIGFuZCB0aGVyZWZvcmUgZG8gZm9yd2FyZGluZyB3aXRob3V0IFNSVFAgZGVj cnlwdGlvbi48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6ICJUYWhvbWEiLCJzYW5zLXNlcmlmIjsn Pu+/vTwvc3Bhbj7CgTxzcGFuIHN0eWxlPSdmb250LWZhbWlseTogIlRhaG9tYSIsInNhbnMtc2Vy aWYiOyc+77+9PC9zcGFuPiBDb21tZW50cyB3ZWxjb21lLjxicj48YnI+UmVnYXJkcyw8YnI+QWRh bSBGaW5lYmVyZzwvcD48ZGl2PjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0 bzpmaW5lYmVyZ0B2bGluZS5jb20iPmZpbmViZXJnQHZsaW5lLmNvbTwvYT48YnI+PGJyPi0tLS0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0gPC9wPjx0YWJsZSBjbGFzcz0iZWN4TXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj48dGJv ZHk+PHRyPjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOiAwaW47Ij48 cCBhbGlnbj0icmlnaHQiIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOiBy aWdodDsiPjxiPlN1YmplY3Q6IDwvYj48L3A+PC90ZD48dGQgc3R5bGU9InBhZGRpbmc6IDBpbjsi PjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dC0wMC50eHQ8L3A+PC90ZD48L3Ry Pjx0cj48dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzogMGluOyI+PHAg YWxpZ249InJpZ2h0IiBjbGFzcz0iZWN4TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjogcmln aHQ7Ij48Yj5EYXRlOiA8L2I+PC9wPjwvdGQ+PHRkIHN0eWxlPSJwYWRkaW5nOiAwaW47Ij48cCBj bGFzcz0iZWN4TXNvTm9ybWFsIj5UdWUsIDA5IEp1bCAyMDEzIDEwOjAyOjA1IC0wNzAwPC9wPjwv dGQ+PC90cj48dHI+PHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6IDBp bjsiPjxwIGFsaWduPSJyaWdodCIgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246IHJpZ2h0OyI+PGI+RnJvbTogPC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0icGFkZGluZzogMGlu OyI+PHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvcD48L3RkPjwvdHI+PHRy Pjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOiAwaW47Ij48cCBhbGln bj0icmlnaHQiIGNsYXNzPSJlY3hNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOiByaWdodDsi PjxiPlRvOiA8L2I+PC9wPjwvdGQ+PHRkIHN0eWxlPSJwYWRkaW5nOiAwaW47Ij48cCBjbGFzcz0i ZWN4TXNvTm9ybWFsIj5BZGFtIEZpbmViZXJnIDxhIGhyZWY9Im1haWx0bzpmaW5lYmVyZ0B2bGlu ZS5jb20iPiZsdDtmaW5lYmVyZ0B2bGluZS5jb20mZ3Q7PC9hPjwvcD48L3RkPjwvdHI+PC90Ym9k eT48L3RhYmxlPjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiZuYnNwOzwvcD48cHJlPkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1maW5lYmVyZy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0LTAw LnR4dDwvcHJlPjxwcmU+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBZGFtIEZp bmViZXJnIGFuZCBwb3N0ZWQgdG8gdGhlPC9wcmU+PHByZT5JRVRGIHJlcG9zaXRvcnkuPC9wcmU+ PHByZT4mbmJzcDs8L3ByZT48cHJlPkZpbGVuYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dDwvcHJlPjxwcmU+ UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICAwMDwvcHJlPjxwcmU+VGl0 bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICBBIFJl YWwtVGltZSBUcmFuc3BvcnQgUHJvdG9jb2wgKFJUUCkgSGVhZGVyIEV4dGVuc2lvbiBmb3IgVlA4 IFRlbXBvcmFsIExheWVyIEluZm9ybWF0aW9uPC9wcmU+PHByZT5DcmVhdGlvbiBkYXRlOiAgMjAx My0wNy0wODwvcHJlPjxwcmU+R3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICBJbmRpdmlkdWFsIFN1Ym1pc3Npb248L3ByZT48cHJlPk51bWJlciBv ZiBwYWdlczogNjwvcHJlPjxwcmU+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maW5lYmVyZy1hdnRleHQtdGVtcG9y YWwtbGF5ZXItZXh0LTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQt MDAudHh0PC9hPjwvcHJlPjxwcmU+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQiIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbmViZXJn LWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQ8L2E+PC9wcmU+PHByZT5IdG1saXplZDombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dC0w MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbmVi ZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQtMDA8L2E+PC9wcmU+PHByZT4mbmJzcDs8L3By ZT48cHJlPiZuYnNwOzwvcHJlPjxwcmU+QWJzdHJhY3Q6PC9wcmU+PHByZT4mbmJzcDsmbmJzcDsg VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIHBhY2tldHMgb2YgUmVh bC1UaW1lPC9wcmU+PHByZT4mbmJzcDsmbmJzcDsgVHJhbnBvcnQgUHJvdG9jb2wgKFJUUCkgdmlk ZW8gc3RyZWFtcyBlbmNvZGVkIHdpdGggdGhlIFZQOCBjb2RlYyBjYW48L3ByZT48cHJlPiZuYnNw OyZuYnNwOyBpbmRpY2F0ZSwgaW4gYW4gUlRQIGhlYWRlciBleHRlbnNpb24sIHRoZSB0ZW1wb3Jh bCBsYXllciBpbmZvcm1hdGlvbjwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7IGFib3V0IHRoZSBmcmFt ZSBlbmNvZGVkIGluIHRoZSBSVFAgcGFja2V0LiZuYnNwOyBUaGlzIGluZm9ybWF0aW9uIGNhbiBi ZTwvcHJlPjxwcmU+Jm5ic3A7Jm5ic3A7IHVzZWQgaW4gYSBtaWRkbGVib3ggcGVyZm9ybWluZyBi YW5kd2lkdGggbWFuYWdlbWVudCBvZiBzdHJlYW1zPC9wcmU+PHByZT4mbmJzcDsmbmJzcDsgd2l0 aG91dCByZXF1aXJpbmcgaXQgdG8gZGVjcnlwdCB0aGUgc3RyZWFtcy48L3ByZT48cHJlPiZuYnNw OzwvcHJlPjxwcmU+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvcHJlPjxwcmU+Jm5i c3A7PC9wcmU+PHByZT4mbmJzcDs8L3ByZT48cHJlPlRoZSBJRVRGIFNlY3JldGFyaWF0PC9wcmU+ PHByZT4mbmJzcDs8L3ByZT48L2Rpdj48cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4mbmJzcDs8L3A+ PC9kaXY+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CnJ0Y3dlYiBtYWlsaW5nIGxpc3QKcnRjd2ViQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9kaXY+IAkJIAkgICAJCSAgPC9kaXY+PC9ib2R5Pg0K PC9odG1sPg== --_6740c6be-8992-48bf-83fe-ed517917ada4_-- From jonathan@vidyo.com Fri Aug 23 14:52:50 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A360321F9E45 for ; Fri, 23 Aug 2013 14:52:50 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNSjveVzmtM5 for ; Fri, 23 Aug 2013 14:52:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB1821F9D9B for ; Fri, 23 Aug 2013 14:52:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id F0FF3552CC7 for ; Fri, 23 Aug 2013 17:52:45 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7F54D5571AD for ; Fri, 23 Aug 2013 17:52:45 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Fri, 23 Aug 2013 17:50:17 -0400 From: Jonathan Lennox To: "avtext@ietf.org" Date: Fri, 23 Aug 2013 17:52:43 -0400 Thread-Topic: AVTEXT IETF87 meeting minutes Thread-Index: Ac6gSrnIoUEkoSsrR8ypOHuAOg2R4g== Message-ID: <8D49D42A-C40D-4CE2-9890-F39279D4FF79@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [avtext] AVTEXT IETF87 meeting minutes X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 21:52:50 -0000 Hi all, I have posted the draft AVTEXT meeting minutes to the proceedings page. Se= e http://www.ietf.org/proceedings/87/minutes/minutes-87-avtext . Let the chairs know (at avtext-chairs@tools.ietf.org) if you have any amend= ments or corrections, and of course, please continue discussions of substan= tive issues from the meeting here on the list. -- Jonathan Lennox jonathan@vidyo.com From magnus.westerlund@ericsson.com Mon Aug 26 00:42:13 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFEE11E8170 for ; Mon, 26 Aug 2013 00:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.545 X-Spam-Level: X-Spam-Status: No, score=-105.545 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J1kL48uXyCf for ; Mon, 26 Aug 2013 00:42:06 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CF2D311E8135 for ; Mon, 26 Aug 2013 00:42:04 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-ce-521b06cb2c16 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0E.E8.22048.BC60B125; Mon, 26 Aug 2013 09:42:03 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Mon, 26 Aug 2013 09:42:02 +0200 Message-ID: <521B0711.50207@ericsson.com> Date: Mon, 26 Aug 2013 09:43:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Bernard Aboba References: <20130709170205.4276.31863.idtracker@ietfa.amsl.com>, <51E71C82.7090608@vline.me>, In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvje5pNukggx3NUhYf791gtdi/5DKz xZ03f4GsxeeZHVg8HvecYfNYsuQnk0fbszvsHru+/mUOYInisklJzcksSy3St0vgyuhdf5Gl 4K9AxclzR9gbGA/ydjFyckgImEhcmbqADcIWk7hwbz2QzcUhJHCYUeLJ/H5WCGc5o8TmafNY QKp4BTQlJt99wghiswioSnx9/oYVxGYTsJC4+aMRbJKoQLBE+/avbBD1ghInZz4B6uXgEBHQ lfjbZQQSZhYokrjX+5cZxBYWKJC4e/ozI8Suk4wSvxd8YQJJcApYS5y8fI8V4jpJiW2LjrFD NBtIHFk0hxXClpdo3jobbJCQgLZEQ1MH6wRGoVlIVs9C0jILScsCRuZVjOy5iZk56eXmmxiB QX1wy2+DHYyb7osdYpTmYFES592sdyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6Oc5iNP z8pTzOvDJ2/ctdjR1m1p6oyePtu1vV89uttvmi/5ffHPryM+i7KvSiyYnl7rXv5yz9fT70N9 RcPa7jVuO/KFWS72wcLr/p//O+28x/zD8EG18FEGsady3zZHHW82ONd1dUXpm++FbkGMm/pv qza3Lq8SzAwotnUJu3Tg2VPP4zv/K65WYinOSDTUYi4qTgQAMi8T4DgCAAA= Cc: Jonathan Lennox , "avtext@ietf.org" Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 07:42:13 -0000 On 2013-08-23 01:12, Bernard Aboba wrote: > Jonathan said: > > > "Unfortunately, RTP doesn’t really let you do this. The problem is that > by just dropping packets without rewriting RTP sequence numbers or RTCP > sender reports, this is going to look like enormous packet loss to RTP > (which, in a sense, it is). A middlebox like this – which is acting as > a media-modifying RTP translator, in RTP terminology – needs to rewrite > RTP headers and RTCP sender reports in order to keep the stream and its > metadata consistent and valid. > > > > Is there something I’m missing here?" > > > > [BA] Your statement assumes that all the layers are sent on the same > SSRC. (which is how I believe VP8 does it). If the layers are sent on > individual SSRCs (as can be done with H.264/SVC), then rewriting of > sequence numbers or RTCP sender reports can be avoided. There are > some caveats though. Typically there is still a need to indicate that > layers are being dropped; if this is handled in RTP, then an SEI message > needs to be inserted, so there will still be some encrypt/decrypt > operations. > Using SVC MST with multiple SSRCs and having the layer on and off happening at a middlebox without RTP re-writing will still be strange to the receiver. Turning off one stream is fine, it is turning it on again that looks strange to the receiver unless these on and off events are known to the receiver. Thus also in this case I think rewriting the RTP headers and ensure RTCP is matching what is actually needed. Having receiver initiated leaving and joining of layers mitigates this as it is that entity that performs the actions. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------