Hi Nermeen,

My comment was that this = should be discussed in the use case section (section 5). The = proposed topology should be clear (similar to how a topology is = described in the topologies drafts in term of RTP and RTCP behavior). = Looking at PM-07 it is a very general requirement and is about security = context but what it means depends on the topology in = mind.

The topology should be very clear to allow = people to offer solutions and to verify the solution against the = topology.

Roni Even

As = individual.

From:= = Nermeen Ismail (nermeen) [mailto:nermeen@cisco.com]
Sent: 11 = November, 2014 10:35 PM
To: Roni Even; = avt@ietf.org
Subject: Re: [AVTCORE] comment on = draft-jones-avtcore-private-media-reqts-00

PM-07 = attempts to capture ,among other things, the sequence number gap = requirement during a switch from one media source to another. In order = to synchronize the SRTP context either the receiver need to be aware of = the source switch and the sequence number associated with the new source = need to be updated or the server needs to shield the receiver from such = sequence number gaps. In either case the receiver will not be perceiving = packet losses during the = switch.

Do you think we need to = explicitly mention the packet loss issue during a media source switch or = do you think that the synchronization of the SRTP context capture it = albeit in an implicit way?

nermeen

From: = Roni Even <ron.even.tlv@gmail.com>
= Date: Saturday, November 8, 2014 11:51 PM
To: "avt@ietf.org" <avt@ietf.org>
Subject: = [AVTCORE] comment on = draft-jones-avtcore-private-media-reqts-00

Hi = guys,

I read the document and was wondering which of the = topologies in draft-ietf-avtcore-rtp-topologies-update-04 is used here = (figure 3). Is it the selective forward middlebox. It will be good to = either use the same terminology or if it is a different topology define = it in the topology draft.

As for the sequence number, when using example in = figure 3 , each RTP stream received (from the same SSRC) may have a gap = in the sequence number or the receiver may report a loss for a stream = switched out by the midlebox? Any requirement here?

Thanks

Roni Even

------=_NextPart_000_01B2_01CFFE04.2C4000B0-- From nobody Tue Nov 11 14:48:03 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E5B1A1BB4 for ; Tue, 11 Nov 2014 14:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcvPC4RC50gx for ; Tue, 11 Nov 2014 14:47:57 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55331A6EDA for ; Tue, 11 Nov 2014 14:47:53 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) with Microsoft SMTP Server (TLS) id 15.1.16.15; Tue, 11 Nov 2014 22:47:51 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0016.006; Tue, 11 Nov 2014 22:47:51 +0000 From: Stephan Wenger To: "avt@ietf.org" Thread-Topic: Topologies-update, paragraph covering relationship of RTP header extensions and RTCP Thread-Index: AQHP/gGF2NuGLYH3kkGZiVbnWApzSA== Date: Tue, 11 Nov 2014 22:47:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.137.107] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(479174003)(164054003)(53754006)(122556002)(229853001)(2501002)(101416001)(40100003)(31966008)(92726001)(2351001)(107046002)(16236675004)(110136001)(92566001)(2656002)(97736003)(36756003)(87936001)(21056001)(86362001)(20776003)(64706001)(77096003)(77156002)(62966003)(106356001)(66066001)(4396001)(120916001)(106116001)(50986999)(99396003)(95666004)(54356999)(46102003)(99286002)(105586002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1275; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_D087B5F04AEFCstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/avt/N4nQwgxLAeHK4t7tc4rtjMeaK8M Cc: Jonathan Lennox , Colin Perkins Subject: [AVTCORE] Topologies-update, paragraph covering relationship of RTP header extensions and RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:48:00 -0000 --_000_D087B5F04AEFCstewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, In yesterday's AVTCORE session, we decided to include a paragraph into the = draft that addresses Roni's concerns as expressed in his email dated 9/26/2= 014 and discussed in the session. Attached the proposed paragraph, as work= ed out between Roni, Jonathan Lennox, Colin Perkins, and myself. It will b= e placed in a slightly restructured section 4. I'll wait for comments on the list for a day or two, and then spin version = 05 of topologies-update covering this and also fixes of the nits mention by= Bo Burman. I understand that this updated draft will be subject to anothe= r short WGLC. Of course, comments now would make my life easier, so please= do so if you can. Thanks, Stephan Some RTP header extensions have relevance not only end-to-end, but also hop= -to-hop, meaning at least some of the middleboxes in the path are aware of = their potential presence through signaling, intercept and interpret such he= ader extensions and potentially also rewrite or generate them. Modern head= er extensions generally follow [RFC5285] which allows for all of the above.= Examples for such header extensions include the mid (media ID) in [draft-i= etf-mmusic-sdp-bundle-negotiation-12]. There is also a generalization of m= apping RTCP SDES into an RTP header extension [draft-westerlund-avtext-sdes= -hdr-ext-02]. When such header extensions are in use, any middle box that understands it = must ensure consistency between the extensions it sees and/or generates, an= d the RTCP it receives and generates. For example, the mid of bundle is se= nt in an RTP header extension and also in an RTCP SDES message. This appar= ent redundancy was introduced as unaware middleboxes may choose to discard = RTP header extensions. Obviously, inconsistency between the media ID sent = in the RTP header extension and in the RTSP SDES message could lead to unde= sirable results, and, therefore, consistency is needed. Middleboxes unawar= e of the nature of a header extension, as specified in [RFC5285], are free = to forward or discard header extensions. --_000_D087B5F04AEFCstewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2A923A7C8CE83A4F95E6CA35B1E09FEC@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi all,

In ye= sterday’s AVTCORE session, we decided to include a paragraph into the draft tha= t addresses Roni’s concerns as expressed in his email dated 9/26/2014= and discussed in the session. Attached the proposed paragraph, as wo= rked out between Roni, Jonathan Lennox, Colin Perkins, and myself. It will be placed in a slightly restructured section 4.<= /span>

I’ll w= ait for comments on the list for a day or two, and then spin version 05 of = topologies-update covering this and also fixes of the nits mention by Bo Burman. I understand that this u= pdated draft will be subject to another short WGLC. Of course, commen= ts now would make my life easier, so please do so if you can.=

Thanks,

Stephan

Some RTP header ext= ensions have relevance not only end-to-end, but also hop-to-hop, meaning&nb= sp;at = least some of the middleboxes in the path are aware of their potential presence through signaling, intercept and i= nterpret such header extensions and potentially also rewrite or generate th= em. Modern header extensions generally follow [RFC5285] which allows for all of the above. Examples for such header extensions include the mid (media ID) in [draft-ietf-mmusi= c-sdp-bundle-negotiation-12]. There is also a generalization of mappi= ng RTCP SDES into an RTP header extension [draft-westerlund-avtext-sdes-hdr= -ext-02].

When such header extensions are in use, any middle box&nb= sp;that understands it must ensure consistency between the extensions it sees= and/or generates, and the RTCP it receives and generates. For exampl= e, the mid of bundle is sent in an RTP header extension and also in an RTCP= SDES message. This apparent redundancy was introduced as unaware middleboxes may choose to discard RTP header extensi= ons. Obviously, inconsistency between the media ID sent in the RTP he= ader extension and in the RTSP SDES message could lead to undesirable resul= ts, and, therefore, consistency is needed. Middleboxes unaware of the nature of a header extension, as specifie= d in [RFC5285], are free to forward or discard header extensions.

--_000_D087B5F04AEFCstewesteweorg_-- From nobody Tue Nov 11 15:28:51 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643851A6FE7 for ; Tue, 11 Nov 2014 15:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9sAhDaTPuRw for ; Tue, 11 Nov 2014 15:28:40 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52431A6FD8 for ; Tue, 11 Nov 2014 15:28:39 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id v10so11021005pde.32 for ; Tue, 11 Nov 2014 15:28:39 -0800 (PST) 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=0eOZ4Eh4MParIA9ngnjqY2BU4mS7FuwVGCzsYsSBh+k=; b=mavwM4nd1vkqvcIJo8XvvWo0zEs08RVGAOpp56tcFOmq3U0gGSuYeaOYNhrodoeSHj UDoGcUzsofrplEDLkGsYSVvsAiOAUCfrgu4G6vO5jYnvxhbJEhPb+8X3jImbAuprF2Zt uM/zJ9q3Z9J2lTpZ4/OhIVO/To+ndwXmLZ8auNRop/xc8Tq0YzoWPSicDb9KrkWd2zWC qRSC6ghpXGAhZaXXBjKGMS/KdSdkiarJRMnUVTbQEjw6y1VURr7dgijCypU1uhkj5pNT 6T5KbdjDSX7jDxIst36N+2Ho1bBQE+6vpYlSalJQ2M+TuaN20M1x7+jxMWgV6dC7lbOu x72A== MIME-Version: 1.0 X-Received: by 10.68.102.195 with SMTP id fq3mr42709962pbb.7.1415748519167; Tue, 11 Nov 2014 15:28:39 -0800 (PST) Received: by 10.70.60.201 with HTTP; Tue, 11 Nov 2014 15:28:39 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 13:28:39 -1000 Message-ID: From: Suhas Nandakumar To: Stephan Wenger Content-Type: multipart/alternative; boundary=047d7b673a06938bdf05079da3be Archived-At: http://mailarchive.ietf.org/arch/msg/avt/WpId8paT4_CpoWtwzNXFSLeUpJk Cc: Jonathan Lennox , "avt@ietf.org" , Colin Perkins Subject: Re: [AVTCORE] Topologies-update, paragraph covering relationship of RTP header extensions and RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 23:28:47 -0000 --047d7b673a06938bdf05079da3be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks Good Stephan except for one typo (RTSP --> RTCP) As long as the middle box that is aware of the RTP Header Extension behaves in a way consistent with the requirements of such an extension within the context of RTP and RTCP , we should be good with the text. Thanks Suhas On Tue, Nov 11, 2014 at 12:47 PM, Stephan Wenger wrote: > Hi all, > > In yesterday=E2=80=99s AVTCORE session, we decided to include a paragraph= into > the draft that addresses Roni=E2=80=99s concerns as expressed in his emai= l dated > 9/26/2014 and discussed in the session. Attached the proposed paragraph, > as worked out between Roni, Jonathan Lennox, Colin Perkins, and myself. = It > will be placed in a slightly restructured section 4. > > I=E2=80=99ll wait for comments on the list for a day or two, and then spi= n > version 05 of topologies-update covering this and also fixes of the > nits mention by Bo Burman. I understand that this updated draft will be > subject to another short WGLC. Of course, comments now would make my lif= e > easier, so please do so if you can. > > Thanks, > > Stephan > > > > > > Some RTP header extensions have relevance not only end-to-end, but also > hop-to-hop, meaning at least some of the middleboxes in the path are > aware of their potential presence through signaling, intercept and > interpret such header extensions and potentially also rewrite or generate > them. Modern header extensions generally follow [RFC5285] which allows > for all of the above. Examples for such header extensions include the mid > (media ID) in [draft-ietf-mmusic-sdp-bundle-negotiation-12]. There is al= so > a generalization of mapping RTCP SDES into an RTP header extension > [draft-westerlund-avtext-sdes-hdr-ext-02]. > > > > When such header extensions are in use, any middle box that understands > it must ensure consistency between the extensions it sees and/or generate= s, > and the RTCP it receives and generates. For example, the mid of bundle i= s > sent in an RTP header extension and also in an RTCP SDES message. This > apparent redundancy was introduced as unaware middleboxes may choose to > discard RTP header extensions. Obviously, inconsistency between the medi= a > ID sent in the RTP header extension and in the RTSP SDES message could le= ad > to undesirable results, and, therefore, consistency is needed. Middlebox= es > unaware of the nature of a header extension, as specified in [RFC5285], a= re > free to forward or discard header extensions. > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > --047d7b673a06938bdf05079da3be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Looks Good Stephan except for one typo (RTSP --> RTCP)<= div>

As long as the middle box that is aware of the RTP Heade= r Extension behaves in a way consistent with the requirements of such an ex= tension within the context of RTP and RTCP , we should be good with the tex= t.

Thanks

Suhas

A New Internet-Dra= ft is available from the on-line Internet-Drafts directories.

This draft is a wo= rk item of the Audio/Video Transport Core Maintenance Working Group of the = IETF.

= Title &nbs= p; : RTP Topologies

= Authors &n= bsp; : Magnus Westerlund

= &nb= sp; Stephan Weng= er

Filename &= nbsp; : draft-ietf-avtcore-rtp-topologies-update-05.= txt

Pages &nbs= p; : 46

Date = ; : 2014-11-12

Abstract:

This = document discusses point to point and multi-endpoint topologies

used = in Real-time Transport Protocol (RTP)-based environments. In

parti= cular, centralized topologies commonly employed in the video

confe= rencing industry are mapped to the RTP terminology.

This = document is updated with additional topologies and is intended

to re= place RFC 5117.

The IETF datatrack= er status page for this draft is:

https:= //datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update/

There's also a htm= lized version available at:

http://too= ls.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-05

A diff from the pr= evious version is available at:

ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-topologies-update-0= 5

Please note that i= t may take a couple of minutes from the time of submission

until the htmlized= version and diff are available at tools.ietf.org.

Internet-Drafts ar= e also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

--_000_D088E2FD4B03Estewesteweorg_-- From nobody Thu Nov 13 15:28:48 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9213A1AE1B8 for ; Thu, 13 Nov 2014 15:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-FGTFteuUbk for ; Thu, 13 Nov 2014 15:28:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2D31AE1BF for ; Thu, 13 Nov 2014 15:28:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113232843.27024.30850.idtracker@ietfa.amsl.com> Date: Thu, 13 Nov 2014 15:28:43 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/avt/7NWF5XCPmvi4EzKXcszFtBihoJw Subject: [AVTCORE] Milestones changed for avtcore WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:28:45 -0000 Changed milestone "Multiplexing Scheme Updates for SRTP for DTLS", set state to active from review, accepting new milestone, set description to "Submit Multiplexing Scheme Updates for SRTP for DTLS as Proposed Standard". Changed milestone "Submit Multipath RTP as experimental RFC ", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/avtcore/charter/ From nobody Fri Nov 14 09:36:18 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7C51A1B22; Fri, 14 Nov 2014 09:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjWwrsA2d4Ov; Fri, 14 Nov 2014 09:36:10 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B6A1A1B14; Fri, 14 Nov 2014 09:36:10 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9F109F68A2C77; Fri, 14 Nov 2014 17:36:05 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sAEHa86J013836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 18:36:08 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 18:36:08 +0100 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" , "mmusic@ietf.org" , CLUE , "avt@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Thread-Index: AQHQAAM2TU9IvAskwUumiAHVoVNISJxgYKPwgAABkqA= Date: Fri, 14 Nov 2014 17:36:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B27B43B@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 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/6XZ8ZQ25NkF_OdMNDTeE5yRsjEU Subject: [AVTCORE] FW: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:36:12 -0000 This is to bring your attention to the following WGLC, in which your workin= g group may have some interest. Please send your comments to avtext@ietf.org If you are not a member of that list, then please still use that address, a= nd we will release it from the moderator queue when we receive notification= . Regards Keith=20 -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of DRAGE, Keith (Ke= ith) Sent: 14 November 2014 17:32 To: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.tx= t (As WG cochair)=20 This is to start a working group last call on draft-ietf-avtext-rtp-groupin= g-taxonomy-03. To cater for the end of the IETF meeting, and for various national holidays= , this working group last call will last three weeks. Therefore please comment on this document by Friday 5th December 2014. Please send comments to the working group list. It is helpful to give some assessment of the nature of your comment, as to = whether you regard it as editorial, minor technical, or a rather more major= flaw. Regards Keith -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 14 November 2014 12:05 To: i-d-announce@ietf.org Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Working = Group of the IETF. Title : A Taxonomy of Grouping Semantics and Mechanisms f= or Real-Time Transport Protocol (RTP) Sources Authors : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Pages : 42 Date : 2014-11-14 Abstract: The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxonomy-= 03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Nov 14 19:03:13 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3707C1A19F1 for ; Fri, 14 Nov 2014 19:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4IOwLLDwG8f for ; Fri, 14 Nov 2014 19:03:09 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11281A038A for ; Fri, 14 Nov 2014 19:03:08 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so1134383wiw.8 for ; Fri, 14 Nov 2014 19:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=71bh7XGcy3kN5dcbwM0x9HkctAsykFxUDNWz3GVD4EY=; b=QQWeLyF1TiY/8QrOArmYnEkVKp2ed7U3I5yzjl0Ia5j/H2zuT53QiR1Fy5psnFpnc4 IHZRiy87LAeV7pyIuFRWzZDsIghbOMDICvYk+SJW2U3VzODKc31Iyd3dEqM2iKZfQ9q2 kLOhaHrUFvpsnuQjejMYUjlsqixyAbWf+6rcjoVqzaEeJO2nTNXm0pmmrUUWqKHI/j93 WycBiVjPxEVLaidSTNTCpbgxwsTKAxFZ+PTVz/zwtpyT2BLouhUiyCfIE6rGdveI1zHf ZcSKoYFNVqsSI7XvdzigagEATdpeiBS3KhUMMd02nqkYFgKol4rUpSeP3SQnwAoO0u7e 1E5A== X-Received: by 10.180.81.134 with SMTP id a6mr12402061wiy.11.1416020587646; Fri, 14 Nov 2014 19:03:07 -0800 (PST) Received: from RoniE (t2001067c037001361cc884d799a338ea.hotel-wireless.v6.meeting.ietf.org. [2001:67c:370:136:1cc8:84d7:99a3:38ea]) by mx.google.com with ESMTPSA id ht9sm5558469wib.8.2014.11.14.19.03.04 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 14 Nov 2014 19:03:06 -0800 (PST) From: "Roni Even" To: Date: Sat, 15 Nov 2014 05:02:55 +0200 Message-ID: <03bc01d00080$ac035da0$040a18e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03BD_01D00091.6F8CF0F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAAf+w7rF5uvW48SeKsnHwwMmbr2A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/avt/muB5kZM4rLmdzZXUeuicLY9k31g Cc: Magnus Westerlund Subject: [AVTCORE] Call for adopting draft-singh-avtcore-mprtp-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 03:03:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03BD_01D00091.6F8CF0F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is a call to adopt draft-singh-avtcore-mprtp-10 to address the new milestone Nov 2015 - Submit Multipath RTP as experimental RFC There was already support to adopt it but this email is to verify the support Please provide any view to the list by November 25th Thanks Roni Even AVTcore co-chair ------=_NextPart_000_03BD_01D00091.6F8CF0F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is a =
call to adopt draft-singh-avtcore-mprtp-10 =
to address the new milestone

Nov 2015 - Submit Multipath RTP as = experimental RFC

There was already = support to adopt it but this email is to verify the = support

Please provide = any view to the list by November 25^th

Thanks

Roni Even =

AVTcore = co-chair

------=_NextPart_000_03BD_01D00091.6F8CF0F0-- From nobody Thu Nov 20 01:07:15 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22EA1A0105 for ; Thu, 20 Nov 2014 01:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d9JkUWbz7sp for ; Thu, 20 Nov 2014 01:07:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5771A00BD for ; Thu, 20 Nov 2014 01:07:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLV49335; Thu, 20 Nov 2014 09:07:08 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Nov 2014 09:07:07 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.103]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 20 Nov 2014 17:07:03 +0800 From: "Liuyan (Scarlett)" To: Stephan Wenger Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-05.txt Thread-Index: AQHP/rRmT/XaQwoQ5EK1er2glpnZUZxpROTw Date: Thu, 20 Nov 2014 09:07:03 +0000 Message-ID: References: <20141112200649.2023.29088.idtracker@ietfa.amsl.com> In-Reply-To: <20141112200649.2023.29088.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.147.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/avt/jr98h-nz8bU3TXkPuqht3n46lC4 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 09:07:14 -0000 Hi Stephan, I have already the latest version and have a question. The section 4.5 says: The RTP protocol includes functionality to identify the session participan= ts through the use of the SSRC and CSRC fields. And the section 4.5 continues to say: RTP includes explicit specification text for Translators and Mixers, and f= or SFMs the required functionality can be derived from that text.=20 At last the section says: The topologies that create independent RTP sessions per End point or pair = of End points, like back-to-back RTP session, MESH with independent RTP ses= sions, and the RTCP terminating MCU RTCP terminating MCU do not support RTP= based identification of session participants. It seems to inconsistent on SFMs. Based on the section 3.7, SFM: all potential RTP sources into a per-endpoin= t, independent RTP session.=20 I think that SFMs have a similar behavior with MESH with independent RTP se= ssions, and then do not support RTP based identification of session partici= pants. Therefore, the sentence "for SFMs the required functionality can be derived= from that text. " should be removed or modified.=20 Thanks. Best Regards, Scarlett > -----Original Message----- > From: avt [mailto:avt-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, November 13, 2014 4:07 AM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-0= 5.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Core Maintenance > Working Group of the IETF. >=20 > Title : RTP Topologies > Authors : Magnus Westerlund > Stephan Wenger > Filename : draft-ietf-avtcore-rtp-topologies-update-05.txt > Pages : 46 > Date : 2014-11-12 >=20 > Abstract: > This document discusses point to point and multi-endpoint topologies > used in Real-time Transport Protocol (RTP)-based environments. In > particular, centralized topologies commonly employed in the video > conferencing industry are mapped to the RTP terminology. >=20 > This document is updated with additional topologies and is intended > to replace RFC 5117. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update= / >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-topologies-upda= te-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From nobody Tue Nov 25 02:22:58 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364351A00A9 for ; Tue, 25 Nov 2014 02:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq7iBaJcR-hY for ; Tue, 25 Nov 2014 02:22:52 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6335F1A0092 for ; Tue, 25 Nov 2014 02:22:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,455,1413237600"; d="scan'208,217";a="5636299" Received: from exc-cashub01.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 25 Nov 2014 11:22:50 +0100 Received: from EXC-MBX01.tsn.tno.nl ([fe80::fd60:358a:bfaf:ca7c]) by EXC-CASHUB01.tsn.tno.nl ([fe80::b855:be6:1aa8:4d0f%13]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 11:22:50 +0100 From: "Stokking, H.M. (Hans)" To: "avt@ietf.org" Thread-Topic: test e-mail Thread-Index: AdAImaf2+U3WfyymSWK/jTMe8ShcDQ== Date: Tue, 25 Nov 2014 10:22:49 +0000 Message-ID: <7F110B3ECC623C4EADDEB82154F2693D1350CFE0@EXC-MBX01.tsn.tno.nl> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_7F110B3ECC623C4EADDEB82154F2693D1350CFE0EXCMBX01tsntnon_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/OlA-FoR1pYajI94QbSdL41QMY8k Subject: [AVTCORE] test e-mail X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 10:22:55 -0000 --_000_7F110B3ECC623C4EADDEB82154F2693D1350CFE0EXCMBX01tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, This is just a test e-mail, to see if it gets through again, as I was havin= g trouble reaching the mailing list previously. Cheers, Hans This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_7F110B3ECC623C4EADDEB82154F2693D1350CFE0EXCMBX01tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi all,

This is just a test e-mail, to see if it gets throug= h again, as I was having trouble reaching the mailing list previously.=

Cheers, Hans

To: "avt@ietf.org" Thread-Topic: another test e-mail Thread-Index: AdAIqLOCWQgy/BxfSFKY3II1uj/WfA== Date: Tue, 25 Nov 2014 12:10:38 +0000 Message-ID: <7F110B3ECC623C4EADDEB82154F2693D1350E1B5@EXC-MBX01.tsn.tno.nl> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_7F110B3ECC623C4EADDEB82154F2693D1350E1B5EXCMBX01tsntnon_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/Xo_8Qgzt3MUJRyWUJTaDeq5Se8c Subject: [AVTCORE] another test e-mail X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 12:10:42 -0000 --_000_7F110B3ECC623C4EADDEB82154F2693D1350E1B5EXCMBX01tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sorry guys about this, I'm running into the same filter again with another mail message to this li= st, testing again to see if this e-mail will reach the list. Cheers, Hans This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_7F110B3ECC623C4EADDEB82154F2693D1350E1B5EXCMBX01tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Sorry guys about this,<= /span>

I’m running into the same filter again with an= other mail message to this list, testing again to see if this e-mail will r= each the list.

Cheers, Hans

To: "avt@ietf.org" Thread-Topic: new draft on IDMS in IPTV Thread-Index: AdAIsDZAvD4snw5HR8OowfTvlUUL5w== Date: Tue, 25 Nov 2014 13:07:53 +0000 Message-ID: <7F110B3ECC623C4EADDEB82154F2693D1350E2B3@EXC-MBX01.tsn.tno.nl> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_7F110B3ECC623C4EADDEB82154F2693D1350E2B3EXCMBX01tsntnon_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/EOtG2RNMgUn0Mj_oTaJb0cb8GK0 Subject: [AVTCORE] new draft on IDMS in IPTV X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 13:08:11 -0000 --_000_7F110B3ECC623C4EADDEB82154F2693D1350E2B3EXCMBX01tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Dear AVTCORE, As presented by my colleague Bastiaan Wissingh during the IETF 91 AVTCORE s= ession, we have submitted an I-D on IDMS in IPTV environments. For those willing, can you please provide us with a review of / comments on= this I-D? See the link at the bottom of the avtcore I-D list. (I don't inc= lude the actual link since I think this is running into the filter rule) http://datatracker.ietf.org/wg/avtcore/documents/ In IPTV environments, there are some typical situations that are a problem = for IDMS. First, in a typical SSM environment we have to deal with a potent= ially large number of messages, as described in RFC 5760. Also, different g= roups of viewers may view content together, so one broadcast may have many = small groups of receivers to be synchronised. Synchronising every receiver = involved may lead to very large buffering times for some receivers. To coun= ter this, the I-D describes the alternative of performing IDMS separately f= or each sub-group. This I-D extends the current RFC 7272 with the ability t= o use a feedback target for collecting and summarizing IDMS reports, accord= ing to the framework from RFC 5760. For this, it defines 2 new sub-report b= locks. Furthermore, in IPTV environments the same content may be distributed in va= rious versions (HD, SD, mobile). RTP timestamps of the various streams will= not match, and thus synchronisation is no longer possible. The I-D gives 2= alternative solutions for this problem, for further discussion. Please note, this draft involves IPR. Cheers, Hans This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_7F110B3ECC623C4EADDEB82154F2693D1350E2B3EXCMBX01tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Dear AVTCORE,

As presented by my colleague Bastiaan Wissingh durin= g the IETF 91 AVTCORE session, we have submitted an I-D on IDMS in IPTV env= ironments.

For those willing, can you please provide us with a = review of / comments on this I-D? See the link at the bottom of the avtcore= I-D list. (I don’t include the actual link since I think this is run= ning into the filter rule)

http://datatracker.ietf.or= g/wg/avtcore/documents/

In IPTV environments, there are some typical situati= ons that are a problem for IDMS. First, in a typical SSM environment we hav= e to deal with a potentially large number of messages, as described in RFC = 5760. Also, different groups of viewers may view content together, so one broadcast may have many small groups of = receivers to be synchronised. Synchronising every receiver involved may lea= d to very large buffering times for some receivers. To counter this, the I-= D describes the alternative of performing IDMS separately for each sub-group. This I-D extends the current RFC 7272 = with the ability to use a feedback target for collecting and summarizing ID= MS reports, according to the framework from RFC 5760. For this, it defines = 2 new sub-report blocks.

Furthermore, in IPTV environments the same content m= ay be distributed in various versions (HD, SD, mobile). RTP timestamps of t= he various streams will not match, and thus synchronisation is no longer po= ssible. The I-D gives 2 alternative solutions for this problem, for further discussion.

Please note, this draft involves IPR.

Cheers, Hans

This is a call to adopt draft-singh-avtcore-mprtp-10 to address the new = milestone

Nov 2015 - Submit Multipath = RTP as experimental RFC

There = was already support to adopt it but this email is to verify the = support

Please provide any view to = the list by November 25^th

Thanks

Roni = Even

AVTcore co-chair

________________________________= _______________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

I read the document and was wondering which of the topologies in = draft-ietf-avtcore-rtp-topologies-update-04 is used = here (figure 3). Is it the selective forward middlebox. It will be good = to either use the same terminology or if it is a different topology = define it in the topology draft.

As for the sequence number, when using example in = figure 3 , each RTP stream received (from the same SSRC) may have a gap = in the sequence number or the receiver may report a loss for a stream = switched out by the midlebox? Any requirement = here?

Thanks

Roni Even

I read the document and was wondering which of the topologies = in dr= aft-ietf-avtcore-rtp-topologies-update-04 is used here (figure 3). Is it the selective forward middlebox. It will be= good to either use the same terminology or if it is a different topology d= efine it in the topology draft.

As for the sequence number, when using example in figure 3 , e= ach RTP stream received (from the same SSRC) may have a gap in the sequence= number or the receiver may report a loss for a stream switched out by the midlebox? Any requirement here?

Thanks

Roni Even

I read the document and= was wondering which of the topologies in draft-ietf-avtcore-rtp-topologies-update= -04 is used here (figure 3). Is it the selective forward middlebox. It will= be good to either use the same terminology or if it is a different topology define it in the topology draft.

As for th= e sequence number, when using example in figure 3 , each RTP stream receive= d (from the same SSRC) may have a gap in the sequence number or the receiver may report a loss for a stream swit= ched out by the midlebox? Any requirement here?

&nbs= p;

Thanks

Roni Even=

I read the document and was wondering which of the = topologies in draft-ietf-avtcore-rtp-topologies-update-04 is used here = (figure 3). Is it the selective forward middlebox. It will be good to = either use the same terminology or if it is a different topology define = it in the topology draft.

As for the sequence number, when using example in = figure 3 , each RTP stream received (from the same SSRC) may have a gap = in the sequence number or the receiver may report a loss for a stream = switched out by the midlebox? Any requirement here?

Thanks

Roni Even