From randell-ietf@jesup.org Fri Jul 1 20:52:26 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BDC21F8938 for ; Fri, 1 Jul 2011 20:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Meq3FB4ZfL3q for ; Fri, 1 Jul 2011 20:52:26 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id EA6F121F8947 for ; Fri, 1 Jul 2011 20:52:22 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QcrFl-0005s0-Eh for mmusic@ietf.org; Fri, 01 Jul 2011 22:52:21 -0500 Message-ID: <4E0E953C.3080908@jesup.org> Date: Fri, 01 Jul 2011 23:49:16 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] Revised ice-updated-offer draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 03:52:26 -0000 On 6/30/2011 3:51 AM, Elwell, John wrote: > I received no comments on -01. To prepare for a meaningful discussion in Quebec, it would be good to start that discussion now, on the list. In particular, the Conclusions section ends with the statement: > " According to discussions in section Section 4, it seems to be the > case that the updated offer is needed, in practice, in very few > environments, and therefore consideration should be given to relaxing > the requirement in [RFC5245]." > What would be people's reactions to updating RFC 5245 to relax this requirement? > > John > One comment on the draft: Switching codec or switching from audio to image requires an SDP offer-answer cycle. Maybe, yes, but switching codecs from compressed to uncompressed may or may not require a re-invite: I.e. with this re-invite isn't needed for the codec change: m=audio 3456 RTP/AVP 18 0 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 Of course, if you don't specify both (why not?), that won't work. (If you support both you should specify both and probably accept both, so this *should* be the norm for this usecase) Switching to image could be a re-invite to add m=image or to make it active (and make m=audio inactive or turn off audio via m=audio 0 RTP/AVP 0). In theory you could have both "active" but only send data on one, though that wouldn't be normal I believe. -- Randell Jesup randell-ietf@jesup.org From Martin.Stiemerling@neclab.eu Mon Jul 4 02:09:03 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9275E21F865D for ; Mon, 4 Jul 2011 02:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+u0cRu7f12d for ; Mon, 4 Jul 2011 02:09:02 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AF26621F8654 for ; Mon, 4 Jul 2011 02:09:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 35B7F28000229 for ; Mon, 4 Jul 2011 11:09:01 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0308v-Kjyw2O for ; Mon, 4 Jul 2011 11:09:01 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1756228000226 for ; Mon, 4 Jul 2011 11:08:56 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.22]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 4 Jul 2011 11:08:56 +0200 From: Martin Stiemerling To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-schmidt-mmusic-sdp-local-identifier-01.txt Thread-Index: AQHMIGGC3EGOgniU5UCWlDOIZpBu0pTcEnlA Date: Mon, 4 Jul 2011 09:08:55 +0000 Message-ID: References: <20110601133752.13657.90207.idtracker@ietfa.amsl.com> In-Reply-To: <20110601133752.13657.90207.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] FW: I-D Action: draft-schmidt-mmusic-sdp-local-identifier-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 09:09:03 -0000 Dear all, The draft below describes how dynamic Policy Controllers can identify media= receivers which are located behind a NAT/home gateway for the resource and= admission process.=20 We are looking forward to your comments Martin=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, June 01, 2011 3:38 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-schmidt-mmusic-sdp-local-identifier-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : SDP Local Identifier > Author(s) : Mischa Schmidt > Hans-Joerg Kolbe > Martin Stiemerling > Filename : draft-schmidt-mmusic-sdp-local-identifier-01.txt > Pages : 12 > Date : 2011-06-01 >=20 > Dynamic Policy Controllers like resource and admission control > systems need to be able to locate media receivers in each segment of > the network to determine the path of the media flows prior to > allowing or rejecting the session setup. This is fine as long as > this is handled within an operator's network but limited when > extending this to home network. Current definitions of SDP are not > clear about conveying a local identifier (e.g., a private IP address) > of the client that is destined to receive media streams after > successful SDP negotiation. In this draft we outline the need for > carrying such information over SDP and discuss a set of possible > solutions in a scenario with a home network and a operator network > domain. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-schmidt-mmusic-sdp-local- > identifier-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-schmidt-mmusic-sdp-local-identif= ier- > 01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ari.keranen@nomadiclab.com Mon Jul 4 09:24:21 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710159E8004 for ; Mon, 4 Jul 2011 09:24:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5ZQoOfVLyar for ; Mon, 4 Jul 2011 09:24:20 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 465159E800F for ; Mon, 4 Jul 2011 09:24:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E1AA34E6E8 for ; Mon, 4 Jul 2011 19:24:18 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe0Ac6cPYKMM for ; Mon, 4 Jul 2011 19:24:18 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 57E024E6E2 for ; Mon, 4 Jul 2011 19:24:18 +0300 (EEST) From: Ari Keranen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jul 2011 19:24:18 +0300 Message-Id: <859AD3AD-CA10-4AE4-9986-84CEE62777D7@nomadiclab.com> To: mmusic WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [MMUSIC] ICE TCP ice-options? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 16:24:21 -0000 Hi all, I have now updated the ICE TCP draft [1] according to the WGLC comments, = but noticed one more issue worth considering: Should we have ice-options tag for ICE TCP? The ICE RFC says [2]: Each extension or change to ICE is associated with a token. When an agent supporting such an extension or change generates an offer or an answer, it MUST include the token for that extension in this attribute. This allows each side to know what the other side is doing.=20 However, at least my impression is that TCP candidates are not an = extension in the sense described in the RFC. TCP candidates were even = originally part of the basic ICE. Also the RFC says [3]: If its peer is using ICE options (present in an ice-options attribute from the peer) that the agent does not understand, the agent MUST use a regular nomination algorithm. =20 So, having "tcp" ice-option would unnecessarily result in forcing = regular nomination even if not supporting the TCP candidates (or some = other transport protocol) would simply result in not pairing them with = any local candidate. Hence, I think we do not need "tcp" options tag (and can keep the draft = as it is). Opinions? Cheers, Ari [1] = http://users.piuha.net/akeranen/drafts/draft-ietf-mmusic-ice-tcp-14.txt [2] http://tools.ietf.org/html/rfc5245#section-14 [3] http://tools.ietf.org/html/rfc5245#section-8.1.1= From john.elwell@siemens-enterprise.com Mon Jul 4 09:33:15 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD1D11E8082 for ; Mon, 4 Jul 2011 09:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.874 X-Spam-Level: X-Spam-Status: No, score=-105.874 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7qEWYIUMPuv for ; Mon, 4 Jul 2011 09:33:14 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 2A3C511E8076 for ; Mon, 4 Jul 2011 09:33:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1309797192!10567332!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 7951 invoked from network); 4 Jul 2011 16:33:12 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-10.tower-182.messagelabs.com with SMTP; 4 Jul 2011 16:33:12 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 4AF811EB83ED; Mon, 4 Jul 2011 18:33:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 4 Jul 2011 18:33:12 +0200 From: "Elwell, John" To: Randell Jesup , "mmusic@ietf.org" Date: Mon, 4 Jul 2011 18:33:10 +0200 Thread-Topic: [MMUSIC] Revised ice-updated-offer draft Thread-Index: Acw4a5O0seSMVI3iSs+shqYaa6i4wAB+8aGg Message-ID: References: <4E0E953C.3080908@jesup.org> In-Reply-To: <4E0E953C.3080908@jesup.org> 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: Re: [MMUSIC] Revised ice-updated-offer draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 16:33:15 -0000 Randell, Yes, you are correct that if you specify two codecs to start with, as trans= mitter you can switch at will. However, if you want the peer endpoint also = to switch the codec it transmits, would you not need to do an updated offer= ? So endpoint A detects fax and switches from G.729 to G.711, but wants end= point B (which may not be in a position to detect the fax) also to switch f= rom G.729 to G.711. Anyway, certainly the draft could do with some clarification in this area. John =20 > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup > Sent: 02 July 2011 04:49 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Revised ice-updated-offer draft >=20 > On 6/30/2011 3:51 AM, Elwell, John wrote: > > I received no comments on -01. To prepare for a meaningful=20 > discussion in Quebec, it would be good to start that=20 > discussion now, on the list. In particular, the Conclusions=20 > section ends with the statement: > > " According to discussions in section Section 4, it seems to be the > > case that the updated offer is needed, in practice, in very few > > environments, and therefore consideration should be=20 > given to relaxing > > the requirement in [RFC5245]." > > What would be people's reactions to updating RFC 5245 to=20 > relax this requirement? > > > > John > > >=20 > One comment on the draft: >=20 > Switching codec or switching from audio to image=20 > requires an SDP offer-answer cycle. >=20 > Maybe, yes, but switching codecs from compressed to=20 > uncompressed may or may not > require a re-invite: >=20 > I.e. with this re-invite isn't needed for the codec change: >=20 > m=3Daudio 3456 RTP/AVP 18 0 > a=3Drtpmap:18 G729/8000 > a=3Dfmtp:18 annexb=3Dno > a=3Drtpmap:0 PCMU/8000 >=20 > Of course, if you don't specify both (why not?), that won't=20 > work. (If you support both > you should specify both and probably accept both, so this=20 > *should* be the norm for this usecase) >=20 > Switching to image could be a re-invite to add m=3Dimage or to=20 > make it active (and make m=3Daudio > inactive or turn off audio via m=3Daudio 0 RTP/AVP 0). In=20 > theory you could have both "active" > but only send data on one, though that wouldn't be normal I believe. >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From randell-ietf@jesup.org Mon Jul 4 20:27:20 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A002711E8072 for ; Mon, 4 Jul 2011 20:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2-dmxrwweiT for ; Mon, 4 Jul 2011 20:27:19 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id A38E811E8091 for ; Mon, 4 Jul 2011 20:27:19 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QdwIA-0002SH-RA for mmusic@ietf.org; Mon, 04 Jul 2011 22:27:18 -0500 Message-ID: <4E1283D6.4030401@jesup.org> Date: Mon, 04 Jul 2011 23:24:06 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic@ietf.org References: <4E0E953C.3080908@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] Revised ice-updated-offer draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 03:27:20 -0000 On 7/4/2011 12:33 PM, Elwell, John wrote: > Randell, > > Yes, you are correct that if you specify two codecs to start with, as transmitter you can switch at will. However, if you want the peer endpoint also to switch the codec it transmits, would you not need to do an updated offer? So endpoint A detects fax and switches from G.729 to G.711, but wants endpoint B (which may not be in a position to detect the fax) also to switch from G.729 to G.711. Ok, it's true that's undefined (though many endpoints will try to or must send the same codec they receive, and so would switch if you switch). The only way to force a codec is to offer only 1 - and that causes problems if the other side doesn't support it, plus it makes switching impossible or only by reinvite. That's a more general problem, however. If you assume a single codec or the need to force the other side to switch, then yes, a reinvite is needed. -- Randell Jesup randell-ietf@jesup.org From internet-drafts@ietf.org Tue Jul 5 00:26:14 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A5121F861F; Tue, 5 Jul 2011 00:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnbIv1N4rWgI; Tue, 5 Jul 2011 00:26:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC3421F85DB; Tue, 5 Jul 2011 00:26:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705072614.24483.97307.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 00:26:14 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 07:26:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based Media = Transport in the Session Description Protocol (SDP) Author(s) : Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-00.txt Pages : 10 Date : 2011-07-04 SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP' and = 9;SCTP/ DTLS' protocol identifiers for SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-00.txt From fandreas@cisco.com Tue Jul 5 16:59:49 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB121F887C for ; Tue, 5 Jul 2011 16:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8cxkh8-9DHv for ; Tue, 5 Jul 2011 16:59:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D1FA421F8867 for ; Tue, 5 Jul 2011 16:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=17563; q=dns/txt; s=iport; t=1309910388; x=1311119988; h=message-id:date:from:mime-version:to:cc:subject; bh=GmkEs789eBriiZ+o1R128iTS+dlLKXAgFm/Ic3ZtVMY=; b=NfPy+79P6zlS26eSAl2trwWuOkt9ntUlfbIr0+hsDg6nZYzbecl0T6H7 oqDKRhfaqZDturSExWY6TYu/ml618TK2M7Ly2YLyJaI1yQh9FAltF8QZX 2WEYhnVNiyF3PCrQyX7cdhUaQSd/c5sqY8ozJkH9lIirQ3VLlcc/pmRk2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAH+kE06tJV2Z/2dsb2JhbABTglGWBI85d65SnhOGNgSSNpBS X-IronPort-AV: E=Sophos;i="4.65,481,1304294400"; d="scan'208,217";a="326596" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 05 Jul 2011 23:59:47 +0000 Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p65Nxk88007847; Tue, 5 Jul 2011 23:59:46 GMT Message-ID: <4E13A55D.5050100@cisco.com> Date: Tue, 05 Jul 2011 19:59:25 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------090207040307060000050804" Cc: draft-ietf-mmusic-media-loopback@tools.ietf.org Subject: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 23:59:49 -0000 This is a multi-part message in MIME format. --------------090207040307060000050804 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi MMUSIC We haven't seen much list discussion on this one. It would be really useful if the WG participants could provide some feedback on the media loopback points raised below so we can determine the best way to proceed here. In particular, we would like to know if the WG believes that the alternative NAT traversal mechanism (latching) proposed in the draft is generally applicable outside of the media loopback use case, and/or if we in general need an alternative to ICE for NAT traversal. Please send your comments to the list. Thanks -- Flemming (as MMUSIC co-chair) -------- Original Message -------- Subject: RE: [MMUSIC] Media loopback revisited(draft-ietf-mmusic-media-loopback-15.txt) Date: Wed, 1 Jun 2011 07:02:45 -0500 From: Kaynam Hedayat To: Flemming Andreasen (fandreas) , CC: mmusic Flemming, Thank you for reviewing the new version of the draft. Some comments from the authors below. Regards, Kaynam *From:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Flemming Andreasen *Sent:* Thursday, May 12, 2011 8:06 PM *To:* draft-ietf-mmusic-media-loopback@tools.ietf.org *Cc:* mmusic *Subject:* [MMUSIC] Media loopback revisited(draft-ietf-mmusic-media-loopback-15.txt) Hi I have taken a look at the updated media-loopback draft http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-15.txt and I consider it to be a subtantial improvement over v14. I still have two signficant comments, both of which probably require discussion with our ADs and/or the Payload WG chairs, however it would be useful for the MMUSIC WG participants to give their view on these as well: 1) Alternative NAT traversal mechanism (Section 5.7) One general question/comment for the group and our ADs, and two technical comments as well 1a) The draft defines an alternative NAT traversal mechanism instead of ICE, and this mechanism will only work in certain deployment scenarios under certain assumptions. The draft does say that ICE is the preferred mechanism and the alternative specified here should only be used if ICE is not available and you fulfill the deployment scenario requirements. Considering the intended status of the document is Proposed Standard, is this acceptable ? */[KH] Looking forward to feedback from the group. Please note that there are implementations of this mechanism in existing products and in use by operators. All implementers are aware that ICE is the preferred mechanism and plan to use this mechanism only if ICE is NOT available./* 1b) The draft allows for the answerer to add this NAT traversal mechanism as a media format to the answer, even if the offer did not include it. The draft furthermore requires the offerer to accept use of this mechanism then. This breaks normal O/A behavior and I don't see any good reason to do so. If the offerer supports and is willing to use this mechanism, he should include it in the offer. */[KH] /**/The authors will remove the requirement for the offerer to accept the Loopback Pump media format if it did not include it in the offer. If the offerer does not have the Loopback Pump media format in the offer, the answerer may stay still include it in the response. But in this case the offerer is not obligated to accept the call./**//* 1c) The draft seems to assume what is commonly referred to as latching behavior by the loopback-source inasmuch as in order for the mechanism to work, the loopback-source must send packets to the observed source IP-address and port rather than what was negotiated in the SDP. This operation however is not explained in the draft, and it needs to be (with a MUST). */[KH] The authors will explain this behavior in the draft with a MUST./* 2) Definition of several new RTP payload formats (Sections 7, 8, and 14.2) The draft defines several new RTP payload formats, however, as far as I know, the draft has not been reviewed in the PAYLOAD WG (or AVT prior to that). Ideally, there would be two different drafts, with the RTP payload part handled in PAYLOAD, and the other part handled in MMUSIC, however I'm sympathetic to the fact that we are on v15 of this draft. */[KH] The authors prefer to keep one draft. Please advise on when is the right time to send for PAYLOAD WG review./* I have a few detailed comments as well that should be relatively easy to resolve, however I'll defer those until we figure out a path forward on the above. Thanks -- Flemming --------------090207040307060000050804 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi MMUSIC

We haven't seen much list discussion on this one. It would be really useful if the WG participants could provide some feedback on the media loopback points raised below so we can determine the best way to proceed here. In particular, we would like to know if the WG believes that the alternative NAT traversal mechanism (latching) proposed in the draft is generally applicable outside of the media loopback use case, and/or if we in general need an alternative to ICE for NAT traversal.

Please send your comments to the list.

Thanks

-- Flemming
(as MMUSIC co-chair)




-------- Original Message --------
Subject: RE: [MMUSIC] Media loopback revisited(draft-ietf-mmusic-media-loopback-15.txt)
Date: Wed, 1 Jun 2011 07:02:45 -0500
From: Kaynam Hedayat <kaynam.hedayat@exfo.com>
To: Flemming Andreasen (fandreas) <fandreas@cisco.com>, <draft-ietf-mmusic-media-loopback@tools.ietf.org>
CC: mmusic <mmusic@ietf.org>


Flemming,

 

Thank you for reviewing the new version of the draft. Some comments from the authors below.

 

Regards,

Kaynam

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Thursday, May 12, 2011 8:06 PM
To: draft-ietf-mmusic-media-loopback@tools.ietf.org
Cc: mmusic
Subject: [MMUSIC] Media loopback revisited(draft-ietf-mmusic-media-loopback-15.txt)

 

Hi

I have taken a look at the updated media-loopback draft
   
    http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-15.txt

and I consider it to be a subtantial improvement over v14. I still have two signficant comments, both of which probably require discussion with our ADs and/or the Payload WG chairs, however it would be useful for the MMUSIC WG participants to give their view on these as well:

1) Alternative NAT traversal mechanism (Section 5.7)
One general question/comment for the group and our ADs, and two technical comments as well
1a) The draft defines an alternative NAT traversal mechanism instead of ICE, and this mechanism will only work in certain deployment scenarios under certain assumptions. The draft does say that ICE is the preferred mechanism and the alternative specified here should only be used if ICE is not available and you fulfill the deployment scenario requirements.  Considering the intended status of the document is Proposed Standard, is this acceptable ?

[KH] Looking forward to feedback from the group. Please note that there are implementations of this mechanism in existing products and in use by operators. All implementers are aware that ICE is the preferred mechanism and plan to use this mechanism only if ICE is NOT available.



1b) The draft allows for the answerer to add this NAT traversal mechanism as a media format to the answer, even if the offer did not include it. The draft furthermore requires the offerer to accept use of this mechanism then. This breaks normal O/A behavior and I don't see any good reason to do so. If the offerer supports and is willing to use this mechanism, he should include it in the offer.

[KH] The authors will remove the requirement for the offerer to accept the Loopback Pump media format if it did not include it in the offer. If the offerer does not have the Loopback Pump media format in the offer, the answerer may stay still include it in the response. But in this case the offerer is not obligated to accept the call.



1c) The draft seems to assume what is commonly referred to as latching behavior by the loopback-source inasmuch as in order for the mechanism to work, the loopback-source must send packets to the observed source IP-address and port rather than what was negotiated in the SDP. This operation however is not explained in the draft, and it needs to be (with a MUST).

[KH] The authors will explain this behavior in the draft with a MUST.




2) Definition of several new RTP payload formats (Sections 7, 8, and 14.2)
The draft defines several new RTP payload formats, however, as far as I know, the draft has not been reviewed in the PAYLOAD WG (or AVT prior to that). Ideally, there would be two different drafts, with the RTP payload part handled in PAYLOAD, and the other part handled in MMUSIC, however I'm sympathetic to the fact that we are on v15 of this draft.

[KH] The authors prefer to keep one draft. Please advise on when is the right time to send for PAYLOAD WG review.




I have a few detailed comments as well that should be relatively easy to resolve, however I'll defer those until we figure out a path forward on the above.

Thanks

-- Flemming

--------------090207040307060000050804-- From olivier.crete@collabora.com Tue Jul 5 17:23:44 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCD321F88C9 for ; Tue, 5 Jul 2011 17:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qmSsbg5aCKx for ; Tue, 5 Jul 2011 17:23:43 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by ietfa.amsl.com (Postfix) with ESMTP id BFBBE21F888E for ; Tue, 5 Jul 2011 17:23:43 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tester) with ESMTPSA id 1363511A8266 From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: mmusic@ietf.org Date: Tue, 05 Jul 2011 20:23:39 -0400 In-Reply-To: <4E13A55D.5050100@cisco.com> References: <4E13A55D.5050100@cisco.com> Organization: Collabora Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-wv3R8U35kve17kMPVd8r" X-Mailer: Evolution 3.0.2 (3.0.2-3.fc15) Message-ID: <1309911822.4148.4.camel@TesterTop4> Mime-Version: 1.0 Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 00:23:44 -0000 --=-wv3R8U35kve17kMPVd8r Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2011-07-05 at 19:59 -0400, Flemming Andreasen wrote: > In particular, we would like to know if the WG believes that the > alternative NAT traversal mechanism (latching) proposed in the draft > is generally applicable outside of the media loopback use case, and/or > if we in general need an alternative to ICE for NAT traversal.=20 As someone who works on VoIP clients for use over the real Internet (not a closed network), I'm not so happy by any draft proposing workaround for people who are too lazy to implement ICE+TURN. Because everything else is annoyingly unreliable. The proposed latching mechanism will not work in every case and seems really a poor workaround for not having ICE. Since any client using media loopback will need both sides to be updated, there is no reason to not require ICE for any case where a NAT can exist, obviously ICE may not be needed in a purely client-server model or in a closed controlled network. --=20 Olivier Cr=C3=AAte olivier.crete@collabora.com --=-wv3R8U35kve17kMPVd8r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk4TqwsACgkQHTiOWk7Zort+NgCeNKwNL0MJAQtERjwrp6w2cGaN qMAAn2YvmrxF9kM1G3jg7A8jBUntmYVN =A11l -----END PGP SIGNATURE----- --=-wv3R8U35kve17kMPVd8r-- From emil@sip-communicator.org Wed Jul 6 10:36:32 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC6021F857E for ; Wed, 6 Jul 2011 10:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXx2SrbXDg6d for ; Wed, 6 Jul 2011 10:36:31 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 20DFA21F8594 for ; Wed, 6 Jul 2011 10:36:17 -0700 (PDT) Received: by fxe4 with SMTP id 4so423233fxe.27 for ; Wed, 06 Jul 2011 10:36:17 -0700 (PDT) Received: by 10.223.78.205 with SMTP id m13mr9460466fak.49.1309973777269; Wed, 06 Jul 2011 10:36:17 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id e16sm6162203fak.41.2011.07.06.10.36.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 10:36:16 -0700 (PDT) Message-ID: <4E149D0E.2040809@jitsi.org> Date: Wed, 06 Jul 2011 19:36:14 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?UTF-8?B?T2xpdmllciBDcsOqdGU=?= References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4> In-Reply-To: <1309911822.4148.4.camel@TesterTop4> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:36:32 -0000 =D0=9D=D0=B0 06.07.11 02:23, Olivier Cr=C3=AAte =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > On Tue, 2011-07-05 at 19:59 -0400, Flemming Andreasen wrote: >> In particular, we would like to know if the WG believes that the >> alternative NAT traversal mechanism (latching) proposed in the draft >> is generally applicable outside of the media loopback use case, and/or= >> if we in general need an alternative to ICE for NAT traversal.=20 >=20 > As someone who works on VoIP clients for use over the real Internet (no= t > a closed network), I'm not so happy by any draft proposing workaround > for people who are too lazy to implement ICE+TURN. Because everything > else is annoyingly unreliable. The proposed latching mechanism I don't see a proposed latching mechanism in the document. What I saw was a fallback mechanism in case ICE is killed by a proxy that does latching (which is what the overwhelming majority of the SIP proxies on the real Internet do). > will not > work in every case and seems really a poor workaround for not having > ICE. Sure, but if you can't use ICE because someone in the middle mangled your SDP, then I suppose a poor workaround is better than nothing. > Since any client using media loopback will need both sides to be > updated, The problem here does not come from the sides that need to support loopback. The issue is caused by middle boxes that are loopback agnostic. As much as I appreciate ICE and what it brings to RTC, and as much as I'd like to believe that everyone would end up adopting it, it simply sounds unreasonable to pretend that everyone is already using it. On a side note, "the chicken and egg" problem described in the draft is similar to what happens with unidirectional streams (e.g. where one side starts transmitting video while the other is in recvonly). The solution proposed in this draft would also be handy in such a situation so it would probably make sense to have it in a separate document. Of course such a document would have to be make it clear it only exists for backward compatibility and that it should only be used if ICE is blocked.= Emil -- http://jitsi.org From fandreas@cisco.com Wed Jul 6 13:44:43 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CAA21F8BD9 for ; Wed, 6 Jul 2011 13:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPhUbMifOYJQ for ; Wed, 6 Jul 2011 13:44:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 593D621F8BB1 for ; Wed, 6 Jul 2011 13:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=8114; q=dns/txt; s=iport; t=1309985079; x=1311194679; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=t8swfDIk08qbS3gmMyH+Q/uVsbKjU8Tjc3O6W/RzzVw=; b=Fc6kxIHm9/J45SDIwdo0PGyfxoF7FehIdpe2NO892F0ReRNkB3Pitean zq9zXGWc8WGvJ/fz8Jitwoazs9vVNJ3+xVE4aw7aK0RRt4qgDJS5ArW4h 1cTK/V1hZ98WCQoOBCFuiZB6JkHGbH9XWHK7wmUF6+6EJN7aE/puhrZMT A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADvIFE6tJXG9/2dsb2JhbABThEKjSHeIeqUCjRqQc4UqgQ0EkkGQWQ X-IronPort-AV: E=Sophos;i="4.65,488,1304294400"; d="scan'208,217";a="460522" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jul 2011 20:44:38 +0000 Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p66KiccV026868; Wed, 6 Jul 2011 20:44:38 GMT Message-ID: <4E14C91A.8080204@cisco.com> Date: Wed, 06 Jul 2011 16:44:10 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Emil Ivov References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4> <4E149D0E.2040809@jitsi.org> In-Reply-To: <4E149D0E.2040809@jitsi.org> Content-Type: multipart/alternative; boundary="------------060506060100060505010602" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:44:43 -0000 This is a multi-part message in MIME format. --------------060506060100060505010602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/6/11 1:36 PM, Emil Ivov wrote: > > На 06.07.11 02:23, Olivier Crête написа: > > On Tue, 2011-07-05 at 19:59 -0400, Flemming Andreasen wrote: > >> In particular, we would like to know if the WG believes that the > >> alternative NAT traversal mechanism (latching) proposed in the draft > >> is generally applicable outside of the media loopback use case, and/or > >> if we in general need an alternative to ICE for NAT traversal. > > > > As someone who works on VoIP clients for use over the real Internet (not > > a closed network), I'm not so happy by any draft proposing workaround > > for people who are too lazy to implement ICE+TURN. Because everything > > else is annoyingly unreliable. The proposed latching mechanism > > I don't see a proposed latching mechanism in the document. What I saw > was a fallback mechanism in case ICE is killed by a proxy that does > latching (which is what the overwhelming majority of the SIP proxies on > the real Internet do). > Please see Section 5.7 in the loopback draft, which defines a latching mechanism as an alternative to ICE, not a fallback if ICE is blocked/doesn't work. > > will not > > work in every case and seems really a poor workaround for not having > > ICE. > > Sure, but if you can't use ICE because someone in the middle mangled > your SDP, then I suppose a poor workaround is better than nothing. > The proposed latching mechanism depends on SDP extensions as well, so it would seem equally vulnerable to SDP mangling by an intermediary. > > Since any client using media loopback will need both sides to be > > updated, > > The problem here does not come from the sides that need to support > loopback. The issue is caused by middle boxes that are loopback > agnostic. As much as I appreciate ICE and what it brings to RTC, and as > much as I'd like to believe that everyone would end up adopting it, it > simply sounds unreasonable to pretend that everyone is already using it. > It's not a question of whether everybody is using it. It's a question of whether there is a problem with ICE and we need an alternative like this proposed latching mechanism. > On a side note, "the chicken and egg" problem described in the draft is > similar to what happens with unidirectional streams (e.g. where one side > starts transmitting video while the other is in recvonly). The solution > proposed in this draft would also be handy in such a situation so it > would probably make sense to have it in a separate document. Of course > such a document would have to be make it clear it only exists for > backward compatibility and that it should only be used if ICE is blocked. > If I read your comments right, the only issue you have with ICE is that it may be blocked whereas another solution (like latching) might not be. Is that an accurate summary ? Thanks -- Flemming > Emil > > -- > http://jitsi.org > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------060506060100060505010602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 7/6/11 1:36 PM, Emil Ivov wrote:
Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

На 06.07.11 02:23, Olivier Crête написа:
> On Tue, 2011-07-05 at 19:59 -0400, Flemming Andreasen wrote:
>> In particular, we would like to know if the WG believes that the
>> alternative NAT traversal mechanism (latching) proposed in the draft
>> is generally applicable outside of the media loopback use case, and/or
>> if we in general need an alternative to ICE for NAT traversal.
>
> As someone who works on VoIP clients for use over the real Internet (not
> a closed network), I'm not so happy by any draft proposing workaround
> for people who are too lazy to implement ICE+TURN. Because everything
> else is annoyingly unreliable. The proposed latching mechanism

I don't see a proposed latching mechanism in the document. What I saw
was a fallback mechanism in case ICE is killed by a proxy that does
latching (which is what the overwhelming majority of the SIP proxies on
the real Internet do).

Please see Section 5.7 in the loopback draft, which defines a latching mechanism as an alternative to ICE, not a fallback if ICE is blocked/doesn't work.

> will not
> work in every case and seems really a poor workaround for not having
> ICE.

Sure, but if you can't use ICE because someone in the middle mangled
your SDP, then I suppose a poor workaround is better than nothing.

The proposed latching mechanism depends on SDP extensions as well, so it would seem equally vulnerable to SDP mangling by an intermediary.


> Since any client using media loopback will need both sides to be
> updated,

The problem here does not come from the sides that need to support
loopback. The issue is caused by middle boxes that are loopback
agnostic. As much as I appreciate ICE and what it brings to RTC, and as
much as I'd like to believe that everyone would end up adopting it, it
simply sounds unreasonable to pretend that everyone is already using it.

It's not a question of whether everybody is using it. It's a question of whether there is a problem with ICE and we need an alternative like this proposed latching mechanism.


On a side note, "the chicken and egg" problem described in the draft is
similar to what happens with unidirectional streams (e.g. where one side
starts transmitting video while the other is in recvonly). The solution
proposed in this draft would also be handy in such a situation so it
would probably make sense to have it in a separate document. Of course
such a document would have to be make it clear it only exists for
backward compatibility and that it should only be used if ICE is blocked.

If I read your comments right, the only issue you have with ICE is that it may be blocked whereas another solution (like latching) might not be. Is that an accurate summary ?

Thanks

-- Flemming



Emil

--
http://jitsi.org


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

--------------060506060100060505010602-- From emil@sip-communicator.org Wed Jul 6 16:07:51 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159CB21F89B6 for ; Wed, 6 Jul 2011 16:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OorP5HFSluwP for ; Wed, 6 Jul 2011 16:07:50 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 047CC21F89D8 for ; Wed, 6 Jul 2011 16:07:49 -0700 (PDT) Received: by fxe4 with SMTP id 4so744107fxe.27 for ; Wed, 06 Jul 2011 16:07:49 -0700 (PDT) Received: by 10.223.24.134 with SMTP id v6mr143544fab.146.1309993668956; Wed, 06 Jul 2011 16:07:48 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id o23sm6334519faa.33.2011.07.06.16.07.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 16:07:48 -0700 (PDT) Message-ID: <4E14EAC1.4040203@jitsi.org> Date: Thu, 07 Jul 2011 01:07:45 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Flemming Andreasen References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4> <4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com> In-Reply-To: <4E14C91A.8080204@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 23:07:51 -0000 =D0=9D=D0=B0 06.07.11 22:44, Flemming Andreasen =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >> I don't see a proposed latching mechanism in the document. What I saw >> was a fallback mechanism in case ICE is killed by a proxy that does >> latching (which is what the overwhelming majority of the SIP proxies o= n >> the real Internet do). >> > Please see Section 5.7 in the loopback draft, which defines a latching > mechanism as an alternative to ICE, not a fallback if ICE is > blocked/doesn't work. I suppose I am missing something because in section 5 I read: ICE/STUN/TURN provide a general solution ... ... Loopback sessions ... SHOULD use these general solutions wherever possible ... In scenarios where ICE/STUN/TURN is not available [and C1] ... the following solution MAY be adapted. (I am not sure why C1, requiring that the loopback source has a public IP address, is necessary here but we can probably come back to this later= ). So, the way I understand this is that loopback clients need to have and use ICE. If ICE is not there they could try to compensate using the mechanism described in 5.7. As to the mechanism itself it basically says that mirrors shouldn't wait to hear from the source and that they should start streaming as soon as they are ready. To me this sounds quite reasonable. It's basic hole punching and, as I said in my previous mail, it could also be of use in other cases. So here's a scenario where I see this reasonable. S (source) supports ICE and calls M (mirror) which also supports ICE. They are both behind NATs and they are both connected to a common SIP server, say iptel.org. When S's INVITE goes through the iptel.org proxy it replaces the connection address in the SDP with that of its RTP proxy. This of course means that even though it would see the entire candidate list M would have to disable ICE. So in this case, which is not at all uncommon, the technique in 5.7 would be the only way to get media flowing both ways. Also, in this case, the only one doing latching is the iptel.org service (not the endpoints that do loopback) and the mechanism from 5.7 allows to work around it. >> > will not >> > work in every case and seems really a poor workaround for not having= >> > ICE. >> >> Sure, but if you can't use ICE because someone in the middle mangled >> your SDP, then I suppose a poor workaround is better than nothing. >> > The proposed latching mechanism depends on SDP extensions as well, so i= t > would seem equally vulnerable to SDP mangling by an intermediary. Well I guess I must be missing something because I only see regular SDP in this scenario and nothing that would be vulnerable to a middle box. >> On a side note, "the chicken and egg" problem described in the draft i= s >> similar to what happens with unidirectional streams (e.g. where one si= de >> starts transmitting video while the other is in recvonly). The solutio= n >> proposed in this draft would also be handy in such a situation so it >> would probably make sense to have it in a separate document. Of course= >> such a document would have to be make it clear it only exists for >> backward compatibility and that it should only be used if ICE is block= ed. >> > If I read your comments right, the only issue you have with ICE is that= > it may be blocked whereas another solution (like latching) might not be= =2E > Is that an accurate summary ? My point is that everyone is using latching and latching disables ICE and in such cases it would be nice for clients to have something to fall back to. I don't see anything in this document being an actual alternative to ICE.= Emil >=20 > -- Flemming >=20 >=20 >=20 >> Emil >> >> -- >> http://jitsi.org >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From fandreas@cisco.com Wed Jul 6 17:40:10 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5D621F899D for ; Wed, 6 Jul 2011 17:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82l6wIjWscwm for ; Wed, 6 Jul 2011 17:40:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5186A21F899E for ; Wed, 6 Jul 2011 17:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=13738; q=dns/txt; s=iport; t=1309999209; x=1311208809; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2hc82lo/hBeleKM7QmU985e/pnK7hp3YQvMGm7fIJx4=; b=mKVDeTbXLTcOjP7pKCNRg3grSh5RA7qnc3NRQYosK1dkHN0y/iKXD4o5 eDATll/qh/SlQFVxHy2C3AAboob+J5R0lJVOEHXB42oPnkwfv5oTHNoyl cRON4d0gvVdfVWFFwz2Is07OC4pzYvO8waD2Xyyl3vP62BVSdUC+SY3Pq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE//FE6tJV2a/2dsb2JhbABThEKjSXeIeqR7jRqQZ4UqgQ0EkkGQWQ X-IronPort-AV: E=Sophos;i="4.65,490,1304294400"; d="scan'208,217";a="487087" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 07 Jul 2011 00:40:09 +0000 Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p670e8al016753; Thu, 7 Jul 2011 00:40:08 GMT Message-ID: <4E15004B.70705@cisco.com> Date: Wed, 06 Jul 2011 20:39:39 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Emil Ivov References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4> <4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com> <4E14EAC1.4040203@jitsi.org> In-Reply-To: <4E14EAC1.4040203@jitsi.org> Content-Type: multipart/alternative; boundary="------------090601010200090703070205" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 00:40:10 -0000 This is a multi-part message in MIME format. --------------090601010200090703070205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/6/11 7:07 PM, Emil Ivov wrote: > > > На 06.07.11 22:44, Flemming Andreasen написа: > >> I don't see a proposed latching mechanism in the document. What I saw > >> was a fallback mechanism in case ICE is killed by a proxy that does > >> latching (which is what the overwhelming majority of the SIP proxies on > >> the real Internet do). > >> > > Please see Section 5.7 in the loopback draft, which defines a latching > > mechanism as an alternative to ICE, not a fallback if ICE is > > blocked/doesn't work. > > I suppose I am missing something because in section 5 I read: > > ICE/STUN/TURN provide a general solution ... > ... Loopback sessions ... SHOULD use these general solutions > wherever possible ... In scenarios where ICE/STUN/TURN is not > available [and C1] ... the following solution MAY be adapted. > > (I am not sure why C1, requiring that the loopback source has a public > IP address, is necessary here but we can probably come back to this > later). > > So, the way I understand this is that loopback clients need to have and > use ICE. If ICE is not there they could try to compensate using the > mechanism described in 5.7. > ICE is at SHOULD strength, not MUST, and there are no fallback procedures defined that says to use ICE first and if it fails, then use latching. The way it's written currently is basically an alternative to implementations without ICE. > > As to the mechanism itself it basically says that mirrors shouldn't wait > to hear from the source and that they should start streaming as soon as > they are ready. > No - that is not what the draft says. The draft defines a new payload type called "loopbkprimer" and associated procedures for using it to punch holes and associated latching operation on the RTP endpoint itself (latching details are not spelled out in detail in the draft currently). > To me this sounds quite reasonable. It's basic hole > punching and, as I said in my previous mail, it could also be of use in > other cases. > > So here's a scenario where I see this reasonable. S (source) supports > ICE and calls M (mirror) which also supports ICE. They are both behind > NATs and they are both connected to a common SIP server, say iptel.org. > When S's INVITE goes through the iptel.org proxy it replaces the > connection address in the SDP with that of its RTP proxy. This of course > means that even though it would see the entire candidate list M would > have to disable ICE. > - How does the iptel.org proxy know it needs to insert a RTP proxy ? - How would M know an RTP proxy was inserted and that M needs to disable ICE ? - Why does M need to disable ICE in this case rather than let it run its course - is there an assumption that this RTP proxy will not pass ICE packets through and trying to do ICE will somehow incur problems ? > So in this case, which is not at all uncommon, the > technique in 5.7 would be the only way to get media flowing both ways. > ICE enables two endpoints to be behind a NAT as well. It may require TURN instead of an RTP proxy as is suggested in this example. The advantage of a TURN based solution is that it will work for other types of media streams than RTP. > Also, in this case, the only one doing latching is the iptel.org service > (not the endpoints that do loopback) and the mechanism from 5.7 allows > to work around it. > That's not clear based on your description. The mechanism in section 5.7 would require both S and M to be loopback-mirrors and send the loopback primer packets to the RTP proxy, which in turn needs to be a loopback-source for both endpoints and at this point is no longer a proxy (nor is the iptel.org "proxy"). > >> > will not > >> > work in every case and seems really a poor workaround for not having > >> > ICE. > >> > >> Sure, but if you can't use ICE because someone in the middle mangled > >> your SDP, then I suppose a poor workaround is better than nothing. > >> > > The proposed latching mechanism depends on SDP extensions as well, so it > > would seem equally vulnerable to SDP mangling by an intermediary. > > Well I guess I must be missing something because I only see regular SDP > in this scenario and nothing that would be vulnerable to a middle box. > If you only see regular SDP, then you are not following the mechanism defined in the loopback draft (loopback, mirror and source SDP attributes and loopbkprimer payload format). > >> On a side note, "the chicken and egg" problem described in the draft is > >> similar to what happens with unidirectional streams (e.g. where one > side > >> starts transmitting video while the other is in recvonly). The solution > >> proposed in this draft would also be handy in such a situation so it > >> would probably make sense to have it in a separate document. Of course > >> such a document would have to be make it clear it only exists for > >> backward compatibility and that it should only be used if ICE is > blocked. > >> > > If I read your comments right, the only issue you have with ICE is that > > it may be blocked whereas another solution (like latching) might not be. > > Is that an accurate summary ? > > My point is that everyone is using latching and latching disables ICE > and in such cases it would be nice for clients to have something to fall > back to. > > I don't see anything in this document being an actual alternative to ICE. > It defines a NAT traversal solution different from ICE, and that will only work under certain assumptions. The question is whether the WG believes we need such a mechanism in general, and if so why. Thanks -- Flemming --------------090601010200090703070205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 7/6/11 7:07 PM, Emil Ivov wrote:
Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

На 06.07.11 22:44, Flemming Andreasen написа:
>> I don't see a proposed latching mechanism in the document. What I saw
>> was a fallback mechanism in case ICE is killed by a proxy that does
>> latching (which is what the overwhelming majority of the SIP proxies on
>> the real Internet do).
>>
> Please see Section 5.7 in the loopback draft, which defines a latching
> mechanism as an alternative to ICE, not a fallback if ICE is
> blocked/doesn't work.

I suppose I am missing something because in section 5 I read:

    ICE/STUN/TURN provide a general solution ...
    ... Loopback sessions ... SHOULD use these general solutions
    wherever possible ... In scenarios where ICE/STUN/TURN is not
    available [and C1] ... the following solution MAY be adapted.

(I am not sure why C1, requiring that the loopback source has a public
IP address, is necessary here but we can probably come back to this later).

So, the way I understand this is that loopback clients need to have and
use ICE. If ICE is not there they could try to compensate using the
mechanism described in 5.7.

ICE is at SHOULD strength, not MUST, and there are no fallback procedures defined that says to use ICE first and if it fails, then use latching. The way it's written currently is basically an alternative to implementations without ICE.


As to the mechanism itself it basically says that mirrors shouldn't wait
to hear from the source and that they should start streaming as soon as
they are ready.

No - that is not what the draft says. The draft defines a new payload type called "loopbkprimer" and associated procedures for using it to punch holes and associated latching operation on the RTP endpoint itself (latching details are not spelled out in detail in the draft currently).



To me this sounds quite reasonable. It's basic hole
punching and, as I said in my previous mail, it could also be of use in
other cases.

So here's a scenario where I see this reasonable. S (source) supports
ICE and calls M (mirror) which also supports ICE. They are both behind
NATs and they are both connected to a common SIP server, say iptel.org.
When S's INVITE goes through the iptel.org proxy it replaces the
connection address in the SDP with that of its RTP proxy. This of course
means that even though it would see the entire candidate list M would
have to disable ICE.

- How does the iptel.org proxy know it needs to insert a RTP proxy ?
- How would M know an RTP proxy was inserted and that M needs to disable ICE ?
- Why does M need to disable ICE in this case rather than let it run its course - is there an assumption that this RTP proxy will not pass ICE packets through and trying to do ICE will somehow incur problems ?



So in this case, which is not at all uncommon, the
technique in 5.7 would be the only way to get media flowing both ways.

ICE enables two endpoints to be behind a NAT as well. It may require TURN instead of an RTP proxy as is suggested in this example. The advantage of a TURN based solution is that it will work for other types of media streams than RTP.

Also, in this case, the only one doing latching is the iptel.org service
(not the endpoints that do loopback) and the mechanism from 5.7 allows
to work around it.

That's not clear based on your description. The mechanism in section 5.7 would require both S and M to be loopback-mirrors and send the loopback primer packets to the RTP proxy, which in turn needs to be a loopback-source for both endpoints and at this point is no longer a proxy (nor is the iptel.org "proxy").


>> > will not
>> > work in every case and seems really a poor workaround for not having
>> > ICE.
>>
>> Sure, but if you can't use ICE because someone in the middle mangled
>> your SDP, then I suppose a poor workaround is better than nothing.
>>
> The proposed latching mechanism depends on SDP extensions as well, so it
> would seem equally vulnerable to SDP mangling by an intermediary.

Well I guess I must be missing something because I only see regular SDP
in this scenario and nothing that would be vulnerable to a middle box.

If you only see regular SDP, then you are not following the mechanism defined in the loopback draft (loopback, mirror and source SDP attributes and loopbkprimer payload format).


>> On a side note, "the chicken and egg" problem described in the draft is
>> similar to what happens with unidirectional streams (e.g. where one side
>> starts transmitting video while the other is in recvonly). The solution
>> proposed in this draft would also be handy in such a situation so it
>> would probably make sense to have it in a separate document. Of course
>> such a document would have to be make it clear it only exists for
>> backward compatibility and that it should only be used if ICE is blocked.
>>
> If I read your comments right, the only issue you have with ICE is that
> it may be blocked whereas another solution (like latching) might not be.
> Is that an accurate summary ?

My point is that everyone is using latching and latching disables ICE
and in such cases it would be nice for clients to have something to fall
back to.

I don't see anything in this document being an actual alternative to ICE.

It defines a NAT traversal solution different from ICE, and that will only work under certain assumptions. The question is whether the WG believes we need such a mechanism in general, and if so why.

Thanks

-- Flemming


--------------090601010200090703070205-- From emil@sip-communicator.org Wed Jul 6 22:44:35 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8A21F885A for ; Wed, 6 Jul 2011 22:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, MANGLED_WATING=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSF8e3KvKQyD for ; Wed, 6 Jul 2011 22:44:34 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id ABDEF21F8862 for ; Wed, 6 Jul 2011 22:44:33 -0700 (PDT) Received: by fxe4 with SMTP id 4so972358fxe.27 for ; Wed, 06 Jul 2011 22:44:32 -0700 (PDT) Received: by 10.223.7.150 with SMTP id d22mr668982fad.17.1310017471901; Wed, 06 Jul 2011 22:44:31 -0700 (PDT) Received: from porcinet.local ([2a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id l26sm6479550fah.38.2011.07.06.22.44.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 22:44:30 -0700 (PDT) Message-ID: <4E1547BC.8030902@jitsi.org> Date: Thu, 07 Jul 2011 07:44:28 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Flemming Andreasen References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4> <4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com> <4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com> In-Reply-To: <4E15004B.70705@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 05:44:35 -0000 =D0=9D=D0=B0 07.07.11 02:39, Flemming Andreasen =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >> =D0=9D=D0=B0 06.07.11 22:44, Flemming Andreasen =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0: >> >> I don't see a proposed latching mechanism in the document. What I s= aw >> >> was a fallback mechanism in case ICE is killed by a proxy that does= >> >> latching (which is what the overwhelming majority of the SIP proxie= s on >> >> the real Internet do). >> >> >> > Please see Section 5.7 in the loopback draft, which defines a latchi= ng >> > mechanism as an alternative to ICE, not a fallback if ICE is >> > blocked/doesn't work. >> >> I suppose I am missing something because in section 5 I read: >> >> ICE/STUN/TURN provide a general solution ... >> ... Loopback sessions ... SHOULD use these general solutions >> wherever possible ... In scenarios where ICE/STUN/TURN is not >> available [and C1] ... the following solution MAY be adapted. >> >> (I am not sure why C1, requiring that the loopback source has a public= >> IP address, is necessary here but we can probably come back to this >> later). >> >> So, the way I understand this is that loopback clients need to have an= d >> use ICE. If ICE is not there they could try to compensate using the >> mechanism described in 5.7. >> > ICE is at SHOULD strength, not MUST, and there are no fallback > procedures defined that says to use ICE first and if it fails, then use= > latching. Definitely not. I never meant to imply there were. It is however a fallback in the case endpoints are prevented from even starting ICE. >> As to the mechanism itself it basically says that mirrors shouldn't wa= it >> to hear from the source and that they should start streaming as soon a= s >> they are ready. >> > No - that is not what the draft says. The draft defines a new payload > type called "loopbkprimer" and associated procedures for using it to > punch holes and associated latching operation on the RTP endpoint itsel= f > (latching details are not spelled out in detail in the draft currently)= =2E Indeed and this is exactly what I was referring to. The "loopbkprimer" is the payload type that mirrors "should start streaming as soon as they are ready" rather than "wait[ing] to hear from the source first". >> To me this sounds quite reasonable. It's basic hole >> punching and, as I said in my previous mail, it could also be of use i= n >> other cases. >> >> So here's a scenario where I see this reasonable. S (source) supports >> ICE and calls M (mirror) which also supports ICE. They are both behind= >> NATs and they are both connected to a common SIP server, say iptel.org= =2E >> When S's INVITE goes through the iptel.org proxy it replaces the >> connection address in the SDP with that of its RTP proxy. This of cour= se >> means that even though it would see the entire candidate list M would >> have to disable ICE. >> > - How does the iptel.org proxy know it needs to insert a RTP proxy ? It either does so unconditionally or it recognizes the addresses in the SDP as non-public so it replaces them. This how the overwhelming majority of the Internet VoIP providers out there handle NAT traversal. > - How would M know an RTP proxy was inserted and that M needs to disabl= e > ICE ? Because the default candidate (the one inserted by the proxy) is not in the candidate list. > - Why does M need to disable ICE in this case rather than let it run it= s > course=20 Because 5245 says so (Section 5.1): The agent will proceed with the ICE procedures defined in this specification if, for each media stream in the SDP it received, the default destination for each component of that media stream appears in a candidate attribute. ... If this condition is not met, the agent MUST process the SDP based on normal RFC 3264 procedures > is there an assumption that this RTP proxy will not pass ICE > packets through and trying to do ICE will somehow incur problems ? I suppose this would be one of the reasons yes. I didn't follow the discussions that led to this text back in the time but I'd guess the assumption was that if someone in the signalling path is taking control then it would be best not to get in the way. >> So in this case, which is not at all uncommon, the >> technique in 5.7 would be the only way to get media flowing both ways.= >> > ICE enables two endpoints to be behind a NAT as well. It may require > TURN instead of an RTP proxy as is suggested in this example. The > advantage of a TURN based solution is that it will work for other types= > of media streams than RTP. >=20 >> Also, in this case, the only one doing latching is the iptel.org servi= ce >> (not the endpoints that do loopback) and the mechanism from 5.7 allows= >> to work around it. >> > That's not clear based on your description. The mechanism in section 5.= 7 > would require both S and M to be loopback-mirrors and send the loopback= > primer packets to the RTP proxy, which in turn needs to be a > loopback-source for both endpoints and at this point is no longer a > proxy (nor is the iptel.org "proxy"). I am not following. Why would both S and M need to be mirrors? S would start streaming ... it has no reason not to. The RTP proxy in the middle however won't be able to relay its packets until it hears from M. Until then, it simply wouldn't know where to relay them to. >> >> > will not >> >> > work in every case and seems really a poor workaround for not hav= ing >> >> > ICE. >> >> >> >> Sure, but if you can't use ICE because someone in the middle mangle= d >> >> your SDP, then I suppose a poor workaround is better than nothing. >> >> >> > The proposed latching mechanism depends on SDP extensions as well, s= o it >> > would seem equally vulnerable to SDP mangling by an intermediary. >> >> Well I guess I must be missing something because I only see regular SD= P >> in this scenario and nothing that would be vulnerable to a middle box.= >> > If you only see regular SDP, then you are not following the mechanism > defined in the loopback draft (loopback, mirror and source SDP > attributes and loopbkprimer payload format). How are these "irregular" SDP and what reason would a middle box have to remove them? >> >> On a side note, "the chicken and egg" problem described in the draf= t is >> >> similar to what happens with unidirectional streams (e.g. where one= >> side >> >> starts transmitting video while the other is in recvonly). The solu= tion >> >> proposed in this draft would also be handy in such a situation so i= t >> >> would probably make sense to have it in a separate document. Of cou= rse >> >> such a document would have to be make it clear it only exists for >> >> backward compatibility and that it should only be used if ICE is >> blocked. >> >> >> > If I read your comments right, the only issue you have with ICE is t= hat >> > it may be blocked whereas another solution (like latching) might not= be. >> > Is that an accurate summary ? >> >> My point is that everyone is using latching and latching disables ICE >> and in such cases it would be nice for clients to have something to fa= ll >> back to. >> >> I don't see anything in this document being an actual alternative to I= CE. >> > It defines a NAT traversal solution different from ICE, and that will > only work under certain assumptions. The question is whether the WG > believes we need such a mechanism in general, and if so why. Well again, I don't see anything in this draft that would allow two clients, both of which are behind a NAT, to talk to each other. The relay in the middle does. In that respect I don't see how anyone can pretend that the loopback primer is an "alternative to ICE". It is not. It does not provide means for clients to discover a direct path to each other. It does not provide relaying. It only helps to resolve a starvation in the echo use case and in a scenario where a regular bi-directional voip call would have worked anyway because of the latching that middle boxes are doing. Emil -- http://jitsi.org From magnus.westerlund@ericsson.com Thu Jul 7 01:46:38 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A53221F8787 for ; Thu, 7 Jul 2011 01:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLuJNkBU5zay for ; Thu, 7 Jul 2011 01:46:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D7E9921F85C6 for ; Thu, 7 Jul 2011 01:46:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-66-4e15726b02f8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FC.10.20773.B62751E4; Thu, 7 Jul 2011 10:46:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 7 Jul 2011 10:46:34 +0200 Message-ID: <4E157269.1000200@ericsson.com> Date: Thu, 7 Jul 2011 10:46:33 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "Bo Burman \(KI/EAB\)" Subject: [MMUSIC] Issues with bandwidth modifiers in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 08:46:38 -0000 Hi, Bo Burman and I have written an I-D that discusses a number of issues around conferencing, including handling of multiple SSRCs in the same RTP session. This also has brought forward an issue with the current bandwidth modifiers. They are very ill suited when you have both asymmetric conditions based on which direction the flows goes and how to indicate individual streams versus limits for the whole aggregate. This include the issue of having payload specific per stream upper bounds. https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/ So please review this and comment on the list. We have requested agenda time but don't know if we will get any. So if you are interested in this topic, commenting on the list will increase our chances for face to face discussion of this i Quebec. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From miguel.a.garcia@ericsson.com Thu Jul 7 05:21:59 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1661921F8605 for ; Thu, 7 Jul 2011 05:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhssxgpNdsUw for ; Thu, 7 Jul 2011 05:21:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4F21F85BA for ; Thu, 7 Jul 2011 05:21:58 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-8e-4e15a4e509c1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 47.EA.09774.5E4A51E4; Thu, 7 Jul 2011 14:21:57 +0200 (CEST) Received: from [159.107.24.205] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 7 Jul 2011 14:21:57 +0200 Message-ID: <4E15A4E4.9060109@ericsson.com> Date: Thu, 7 Jul 2011 14:21:56 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic , Flemming Andreasen Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Draft agenda for MMUSIC at IETF 81 in Quebec X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:21:59 -0000 Hi, we have just uploaded a draft agenda for the MMUSIC meeting in Quebec. Available at: http://www.ietf.org/proceedings/81/agenda/mmusic.htm As usually, it is subject to suffer changes until the very last minute. BR, Miguel & Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From fandreas@cisco.com Thu Jul 7 07:50:30 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8635C21F861B for ; Thu, 7 Jul 2011 07:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIVsrrBTRiwH for ; Thu, 7 Jul 2011 07:50:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 200D621F8613 for ; Thu, 7 Jul 2011 07:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=14429; q=dns/txt; s=iport; t=1310050228; x=1311259828; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+mIxQMnJV3YskDMSvAupFxdPya9Tqg2Eb4RN7etTKms=; b=VqGrCKGvM6+INOW+IbLqsbAIicg3BrMEt5K0m4E+vjRWlqzyoVyH5mRw qfkUPAoiKwMQoLQ3B4BpIp5aJ4gnAl6i9uKXl0LvySqLzGhEK3DAAtNZE LwU/XCa5jaJgVZP3CDg7BliOwl1jO/+hUxhcpKoVbfQsnI2X/3LtO4XZG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJTGFU6tJV2c/2dsb2JhbABThEKjWXeIe6RvjRuQW4UrgQ0EkkaQXQ X-IronPort-AV: E=Sophos;i="4.65,493,1304294400"; d="scan'208,217";a="684836" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jul 2011 14:50:27 +0000 Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p67EoQEX015903; Thu, 7 Jul 2011 14:50:26 GMT Message-ID: <4E15C791.10600@cisco.com> Date: Thu, 07 Jul 2011 10:49:53 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Emil Ivov References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4> <4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com> <4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com> <4E1547BC.8030902@jitsi.org> In-Reply-To: <4E1547BC.8030902@jitsi.org> Content-Type: multipart/alternative; boundary="------------040909090702090605060107" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:50:30 -0000 This is a multi-part message in MIME format. --------------040909090702090605060107 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks - I now understand your point about ice-mismatch and how latching may be a fallback in that case (I'll note that this is not how the loopback draft currently describes it though). More below (snipped some stuff). On 7/7/11 1:44 AM, Emil Ivov wrote: > > На 07.07.11 02:39, Flemming Andreasen написа: > >> На 06.07.11 22:44, Flemming Andreasen написа: > > > >> So in this case, which is not at all uncommon, the > >> technique in 5.7 would be the only way to get media flowing both ways. > >> > > ICE enables two endpoints to be behind a NAT as well. It may require > > TURN instead of an RTP proxy as is suggested in this example. The > > advantage of a TURN based solution is that it will work for other types > > of media streams than RTP. > > > > > >> Also, in this case, the only one doing latching is the iptel.org > service > >> (not the endpoints that do loopback) and the mechanism from 5.7 allows > >> to work around it. > >> > > That's not clear based on your description. The mechanism in section 5.7 > > would require both S and M to be loopback-mirrors and send the loopback > > primer packets to the RTP proxy, which in turn needs to be a > > loopback-source for both endpoints and at this point is no longer a > > proxy (nor is the iptel.org "proxy"). > > I am not following. Why would both S and M need to be mirrors? S would > start streaming ... it has no reason not to. The RTP proxy in the middle > however won't be able to relay its packets until it hears from M. Until > then, it simply wouldn't know where to relay them to. > You're right. So: 1) M starts sending loopbkprimer packets to R (RTP Proxy), which has no idea where to send them yet (since S is behind a NAT). RTP proxy can however do latching operation for M at this point. 2) S starts sending loopback packets to R (RTP Proxy), which can forward them to M because of the latching operation done in step 1). 3) R can now also do latching operation for S and hence we have a two-way path between S and M via R 4) S receives loopback packet and stops sending loopback primer packets at this point 5) Loopback between S and M is verified (via R) > >> >> > will not > >> >> > work in every case and seems really a poor workaround for not > having > >> >> > ICE. > >> >> > >> >> Sure, but if you can't use ICE because someone in the middle mangled > >> >> your SDP, then I suppose a poor workaround is better than nothing. > >> >> > >> > The proposed latching mechanism depends on SDP extensions as > well, so it > >> > would seem equally vulnerable to SDP mangling by an intermediary. > >> > >> Well I guess I must be missing something because I only see regular SDP > >> in this scenario and nothing that would be vulnerable to a middle box. > >> > > If you only see regular SDP, then you are not following the mechanism > > defined in the loopback draft (loopback, mirror and source SDP > > attributes and loopbkprimer payload format). > > How are these "irregular" SDP and what reason would a middle box have to > remove them? > My point is that they are just as regular or irregular as any other SDP, including ICE. The one difference I do see at this point is that by the middle box changing address information in the SDP, it will effectively turn off ICE based on the ice-mismatch procedure you pointed out. The loopback mechanism will not suffer from this problem, as long as the middle box passes through the SDP with whatever parameters it contains (i.e. the middle box does not insist on understanding the SDP itself; if it did, it would have to support the loopback mechanism including its defined SDP extensions and loopback primer payload). > >> >> On a side note, "the chicken and egg" problem described in the > draft is > >> >> similar to what happens with unidirectional streams (e.g. where one > >> side > >> >> starts transmitting video while the other is in recvonly). The > solution > >> >> proposed in this draft would also be handy in such a situation so it > >> >> would probably make sense to have it in a separate document. Of > course > >> >> such a document would have to be make it clear it only exists for > >> >> backward compatibility and that it should only be used if ICE is > >> blocked. > >> >> > >> > If I read your comments right, the only issue you have with ICE > is that > >> > it may be blocked whereas another solution (like latching) might > not be. > >> > Is that an accurate summary ? > >> > >> My point is that everyone is using latching and latching disables ICE > >> and in such cases it would be nice for clients to have something to > fall > >> back to. > >> > >> I don't see anything in this document being an actual alternative > to ICE. > >> > > It defines a NAT traversal solution different from ICE, and that will > > only work under certain assumptions. The question is whether the WG > > believes we need such a mechanism in general, and if so why. > > Well again, I don't see anything in this draft that would allow two > clients, both of which are behind a NAT, to talk to each other. The > relay in the middle does. In that respect I don't see how anyone can > pretend that the loopback primer is an "alternative to ICE". It is not. > It does not provide means for clients to discover a direct path to each > other. It does not provide relaying. It only helps to resolve a > starvation in the echo use case and in a scenario where a regular > bi-directional voip call would have worked anyway because of the > latching that middle boxes are doing. > I agree with your point above, however it does also provide a limited alternative to ICE inasmuch as it defines an alternative NAT traversal mechanism that can be used in certain limited deployment scenarios (without relays), and the way the draft is written currently, that's the way this mechanim is positioned as well. Again, you are bringing up another real-life use case that has merit IMO. It would be good to know if there are others. Thanks -- Flemming --------------040909090702090605060107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Thanks - I now understand your point about ice-mismatch and how latching may be a fallback in that case (I'll note that this is not how the loopback draft currently describes it though). More below (snipped some stuff).



On 7/7/11 1:44 AM, Emil Ivov wrote:
Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

На 07.07.11 02:39, Flemming Andreasen написа:
>> На 06.07.11 22:44, Flemming Andreasen написа:

<snip>


>> So in this case, which is not at all uncommon, the
>> technique in 5.7 would be the only way to get media flowing both ways.
>>
> ICE enables two endpoints to be behind a NAT as well. It may require
> TURN instead of an RTP proxy as is suggested in this example. The
> advantage of a TURN based solution is that it will work for other types
> of media streams than RTP.


>
>> Also, in this case, the only one doing latching is the iptel.org service
>> (not the endpoints that do loopback) and the mechanism from 5.7 allows
>> to work around it.
>>
> That's not clear based on your description. The mechanism in section 5.7
> would require both S and M to be loopback-mirrors and send the loopback
> primer packets to the RTP proxy, which in turn needs to be a
> loopback-source for both endpoints and at this point is no longer a
> proxy (nor is the iptel.org "proxy").

I am not following. Why would both S and M need to be mirrors? S would
start streaming ... it has no reason not to. The RTP proxy in the middle
however won't be able to relay its packets until it hears from M. Until
then, it simply wouldn't know where to relay them to.

You're right. So:
1) M starts sending loopbkprimer packets to R (RTP Proxy), which has no idea where to send them yet (since S is behind a NAT). RTP proxy can however do latching operation for M at this point.
2) S starts sending loopback packets to R (RTP Proxy), which can forward them to M because of the latching operation done in step 1).
3) R can now also do latching operation for S and hence we have a two-way path between S and M via R
4) S receives loopback packet and stops sending loopback primer packets at this point
5) Loopback between S and M is verified (via R)



>> >> > will not
>> >> > work in every case and seems really a poor workaround for not having
>> >> > ICE.
>> >>
>> >> Sure, but if you can't use ICE because someone in the middle mangled
>> >> your SDP, then I suppose a poor workaround is better than nothing.
>> >>
>> > The proposed latching mechanism depends on SDP extensions as well, so it
>> > would seem equally vulnerable to SDP mangling by an intermediary.
>>
>> Well I guess I must be missing something because I only see regular SDP
>> in this scenario and nothing that would be vulnerable to a middle box.
>>
> If you only see regular SDP, then you are not following the mechanism
> defined in the loopback draft (loopback, mirror and source SDP
> attributes and loopbkprimer payload format).

How are these "irregular" SDP and what reason would a middle box have to
remove them?

My point is that they are just as regular or irregular as any other SDP, including ICE. The one difference I do see at this point is that by the middle box changing address information in the SDP, it will effectively turn off ICE based on the ice-mismatch procedure you pointed out. The loopback mechanism will not suffer from this problem, as long as the middle box passes through the SDP with whatever parameters it contains (i.e. the middle box does not insist on understanding the SDP itself; if it did, it would have to support the loopback mechanism including its defined SDP extensions and loopback primer payload).



>> >> On a side note, "the chicken and egg" problem described in the draft is
>> >> similar to what happens with unidirectional streams (e.g. where one
>> side
>> >> starts transmitting video while the other is in recvonly). The solution
>> >> proposed in this draft would also be handy in such a situation so it
>> >> would probably make sense to have it in a separate document. Of course
>> >> such a document would have to be make it clear it only exists for
>> >> backward compatibility and that it should only be used if ICE is
>> blocked.
>> >>
>> > If I read your comments right, the only issue you have with ICE is that
>> > it may be blocked whereas another solution (like latching) might not be.
>> > Is that an accurate summary ?
>>
>> My point is that everyone is using latching and latching disables ICE
>> and in such cases it would be nice for clients to have something to fall
>> back to.
>>
>> I don't see anything in this document being an actual alternative to ICE.
>>
> It defines a NAT traversal solution different from ICE, and that will
> only work under certain assumptions. The question is whether the WG
> believes we need such a mechanism in general, and if so why.

Well again, I don't see anything in this draft that would allow two
clients, both of which are behind a NAT, to talk to each other. The
relay in the middle does. In that respect I don't see how anyone can
pretend that the loopback primer is an "alternative to ICE". It is not.
 It does not provide means for clients to discover a direct path to each
other. It does not provide relaying. It only helps to resolve a
starvation in the echo use case and in a scenario where a regular
bi-directional voip call would have worked anyway because of the
latching that middle boxes are doing.

I agree with your point above, however it does also provide a limited alternative to ICE inasmuch as it defines an alternative NAT traversal mechanism that can be used in certain limited deployment scenarios (without relays), and the way the draft is written currently, that's the way this mechanim is positioned as well. Again, you are bringing up another real-life use case that has merit IMO. It would be good to know if there are others.

Thanks

-- Flemming


--------------040909090702090605060107-- From randell-ietf@jesup.org Thu Jul 7 08:17:19 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BC211E8080 for ; Thu, 7 Jul 2011 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yRIdhoyarXe for ; Thu, 7 Jul 2011 08:17:18 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3F711E807E for ; Thu, 7 Jul 2011 08:17:18 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QeqKL-0001ZK-Tk for mmusic@ietf.org; Thu, 07 Jul 2011 10:17:18 -0500 Message-ID: <4E15CD36.4050308@jesup.org> Date: Thu, 07 Jul 2011 11:13:58 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic@ietf.org References: <4E157269.1000200@ericsson.com> In-Reply-To: <4E157269.1000200@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] Issues with bandwidth modifiers in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:17:19 -0000 On 7/7/2011 4:46 AM, Magnus Westerlund wrote: > Hi, > > Bo Burman and I have written an I-D that discusses a number of issues > around conferencing, including handling of multiple SSRCs in the same > RTP session. This also has brought forward an issue with the current > bandwidth modifiers. They are very ill suited when you have both > asymmetric conditions based on which direction the flows goes and how to > indicate individual streams versus limits for the whole aggregate. This > include the issue of having payload specific per stream upper bounds. > > https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/ Up front: realize I'm commenting as I read, but that means that it's also an indication if something wasn't clear up-front without reading more of later parts of the spec. The purpose of the document is a little fuzzy - is it for simulcast (as stated and defined in the doc) or for both multiple-source and simulcast (as implied in the document and its title). It seems to be the former, but the title and some early statements imply it's both. Also it should be made clear (if it isn't; I'm reading fast) that these mixer cases specifically would include one-to-one communication through a server. Also: should this discuss non-mixer cases (point-to-point simulcast)? I think so. Thus there has been perceived little need for handling multiple SSRCs in implementations. This has resulted in an installed legacy base that isn't fully RTP specification compliant and will have different issues if they receive multiple SSRCs of media, either simultaneously or in sequence. These issues will manifest themselves in various ways, either by software crashes, or simply in limited functionality, like only decoding and playing back the first or latest SSRC received and discarding any other SSRCs. As an implementer of a point-to-point videophone, we handled SSRC changes, but only were set up to decode one stream at a time (especially of video). (A later phone could decode up to 3 and encode 1 when acting as a bridge for an ad-hoc video conference.) Our algorithm was to immediately react to an SSRC change, but then lock out changes for a (short) period because since we only played one stream at a time we didn't want to reset the codec on every other incoming packet. This also helped us with a few other usecases involving various B2BUA-ish servers and server-mediated call transfers, etc. Not truly compliant per-se, of course, but worked for the usecases we needed to deal with. Simulcasting has the benefit that it is conceptually simple. It enables use of any media codec that the participants agree on, allowing the mixer to be codec-agnostic. Considering today's video encoders, it is less bit-rate efficient in the path from the sending client to the mixer but more efficient in the mixer to receiver path compared to Scalable Video Coding. If you're targeting a single lower-bitrate encoding, yes. If the bandwidth down to each receiver is adaptive to their available bandwidth (think mobile reception, or WiFi) then giving the mixer the ability to subset differently for each receiver without having to re-encode. (And it avoids having to tell the sender to change bitrates if one of the receivers needs a lower rate than the sender is sending, and it avoids giving all the other recipients a lowest-common-denominator stream). Of course this is part of the entire value-proposition of SVC - that it enables this sort of optimized reception with a single encoding and a low-horsepower mixer. Yes, I realize I'm saying fairly obvious things here. If only resolution and temporal variations are needed, this can be implemented using H.264, as each simulcast version provides the different resolution, and each media stream within a simulcast encoding has temporal scalability using no- reference frames. Note that this implies that the mixer parses the H.264 to the point where it knows if the frame will be used as a reference frame. Not a problem, and probably doesn't require any change to the text. Even within SVC (and you may have stated or implied this) you could make multiple encodings with differently-targeted layers - for example a "low" set targeting bandwidths <500K, and a high set for 500K and up. This might help avoid the problem of too many layers degrading the bit-efficiency of the encoding. 3.2. Simulcasting to Consuming End-Point This section is clearly based on the assumption (up front) that the streams are in fact identical content with different encodings. Not a problem, especially if the target of the document is a little clearer. 3.3 and 3.4: These assume no mixer, right? 4.3: negotiation of transmission side - how does an endpoint indicate these are "equivalent" streams and not "alternative" streams (different camera/mic, etc). How are the differing encodings negotiated, or is that out of scope? (I'd think it would be in-scope, because the mixer is the one who knows who's connected to it and their capabilities.) 4.5: SDP signaling and bandwidth - b=AS could be used in theory for either direction, however the general offer/answer semantic is that you define what you're willing/ready to receive, not send, so b=AS would be the downstream direction, not the highest of upstream or downstream - I don't know of any that use it that way today. Some use upstream (perhaps most), some use downstream. Also there should be discussion of how RTCP TMMBR fits into this. nit in 6.2: When one have multiple actual media sources in a session, have->has 7.1.2: SSRC Multiplexing Note that "legacy" receivers will often be much happier with NO SSRC change when the mixer switches streams. While in theory they should handle them, not all do. And even if they do, they may cause glitches at the transition (decoder resets, etc). Yes, they shouldn't do that. NAT Traversal Failure Rate: Due to that one need more than a single flow to be established through the NAT there is some risk that one succeed in establishing the first flow but fails with one or more of the additional flows. The risk that this happens are hard to quantify. However, that risk should be fairly low as one has just prior successfully established one flow from the same interfaces. Thus only rare events as NAT resource overload, or selecting particular port numbers that are filtered etc, should be reasons for failure. As the number of flows increases, the odds of a lost packet (or congestion) increase. The pacing timer should help with this, but even so I believe the odds of problems will increase above a linear rate. However, this is an off-the-cuff assessment and I haven't followed the ICE discussions (N zillion MB of them...). :-) 8.2. Mixer Requests of Client streams I'd guess TMMBR of 0 may not go over well with some existing clients, or may be ignored. 8.4 Multiplexing sessions This touches on the discussions currently in rtcweb 8.5.1.2 Multiple sources (telepresence) Ok, this confuses me as the discussion I thought was of simultaneous encodings of the same data, not true different sources. At this point I'm afraid my eyes have glazed over reading the (very nicely detailed and explained) SDP examples. :-) -- Randell Jesup randell-ietf@jesup.org From emil@sip-communicator.org Thu Jul 7 09:31:21 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C0E21F855D for ; Thu, 7 Jul 2011 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzu9YcdNvVhB for ; Thu, 7 Jul 2011 09:31:21 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id C8C6321F85F2 for ; Thu, 7 Jul 2011 09:31:20 -0700 (PDT) Received: by fxe4 with SMTP id 4so1621281fxe.27 for ; Thu, 07 Jul 2011 09:31:19 -0700 (PDT) Received: by 10.223.17.68 with SMTP id r4mr1510274faa.62.1310056279725; Thu, 07 Jul 2011 09:31:19 -0700 (PDT) Received: from porcinet.local ([2a01:e35:8a55:abc0:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id m5sm6801871fai.1.2011.07.07.09.31.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 09:31:18 -0700 (PDT) Message-ID: <4E15DF54.2020504@jitsi.org> Date: Thu, 07 Jul 2011 18:31:16 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Flemming Andreasen References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4> <4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com> <4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com> <4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> In-Reply-To: <4E15C791.10600@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:31:22 -0000 Hey Flemming, =D0=9D=D0=B0 07.07.11 16:49, Flemming Andreasen =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >> How are these "irregular" SDP and what reason would a middle box have = to >> remove them? >> > My point is that they are just as regular or irregular as any other SDP= , > including ICE. The one difference I do see at this point is that by the= > middle box changing address information in the SDP, it will effectively= > turn off ICE based on the ice-mismatch procedure you pointed out. The > loopback mechanism will not suffer from this problem, as long as the > middle box passes through the SDP with whatever parameters it contains > (i.e. the middle box does not insist on understanding the SDP itself; i= f > it did, it would have to support the loopback mechanism including its > defined SDP extensions and loopback primer payload). Wel does it really need to support the payload or any loopback-specific mechanisms? I apologise if I am missing something but, as long as the middle box is not planning on absolutely decoding media, it should be OK. According to my experience, it is reasonable to expect that most SIP proxies would handle this properly. I am of course only talking about the NAT traversal/latching aspects of the draft. Obviously the echo-related params may be more exposed to pruning. >> Well again, I don't see anything in this draft that would allow two >> clients, both of which are behind a NAT, to talk to each other. The >> relay in the middle does. In that respect I don't see how anyone can >> pretend that the loopback primer is an "alternative to ICE". It is not= =2E >> It does not provide means for clients to discover a direct path to ea= ch >> other. It does not provide relaying. It only helps to resolve a >> starvation in the echo use case and in a scenario where a regular >> bi-directional voip call would have worked anyway because of the >> latching that middle boxes are doing. >> > I agree with your point above, however it does also provide a limited > alternative to ICE inasmuch as it defines an alternative NAT traversal > mechanism that can be used in certain limited deployment scenarios > (without relays), and the way the draft is written currently, that's th= e > way this mechanim is positioned as well. Again, you are bringing up > another real-life use case that has merit IMO. It would be good to know= > if there are others. Well, there's also the case of UDP-only SIP proxies. I have yet to see a real-life audio/video INVITE that can fit into a single ethernet MTU together with an ICE candidate lists. In such cases clients may again wish to fall back to an ICEless leap of faith and hope for latching. Of course, UDP-only proxies being prohibited by 3261, this case may be considered irrelevant. Still, I thought I' mention it anyway given that many providers out there choose not to enable TCP regardless of what 3261 says. Cheers, Emil --=20 http://jitsi.org From magnus.westerlund@ericsson.com Fri Jul 8 01:21:59 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160C021F85BD for ; Fri, 8 Jul 2011 01:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDLNK9GIVsF7 for ; Fri, 8 Jul 2011 01:21:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 64B6A21F85BC for ; Fri, 8 Jul 2011 01:21:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-4a-4e16be234ed7 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BE.35.09774.32EB61E4; Fri, 8 Jul 2011 10:21:56 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 8 Jul 2011 10:21:55 +0200 Message-ID: <4E16BE1F.6080807@ericsson.com> Date: Fri, 8 Jul 2011 10:21:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Randell Jesup References: <4E157269.1000200@ericsson.com> <4E15CD36.4050308@jesup.org> In-Reply-To: <4E15CD36.4050308@jesup.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Issues with bandwidth modifiers in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:21:59 -0000 Hi Randell, Thanks for the feedback. See inline for feedback on your comments. On 2011-07-07 17:13, Randell Jesup wrote: > On 7/7/2011 4:46 AM, Magnus Westerlund wrote: >> Hi, >> >> Bo Burman and I have written an I-D that discusses a number of issues >> around conferencing, including handling of multiple SSRCs in the same >> RTP session. This also has brought forward an issue with the current >> bandwidth modifiers. They are very ill suited when you have both >> asymmetric conditions based on which direction the flows goes and how to >> indicate individual streams versus limits for the whole aggregate. This >> include the issue of having payload specific per stream upper bounds. >> >> https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/ > > Up front: realize I'm commenting as I read, but that means that it's > also an indication if > something wasn't clear up-front without reading more of later parts of > the spec. > > > The purpose of the document is a little fuzzy - is it for simulcast (as > stated and defined > in the doc) or for both multiple-source and simulcast (as implied in the > document and its > title). It seems to be the former, but the title and some early > statements imply it's both. Yes, this is document that has grown while we wrote it. I actually expect that we start splitting up the different pieces into individual documents and tries to clarify what is applicable in what case. But our intention from the start is to address both cases. But yes we started with simulcast and for that we do need to resolve the multiple SSRC in RTP session problems. So simulcast requires multiple SSRCs, however multiple SSRC has many usages beyond simulcast. > > Also it should be made clear (if it isn't; I'm reading fast) that these > mixer cases specifically > would include one-to-one communication through a server. Also: should > this discuss > non-mixer cases (point-to-point simulcast)? I think so. We tried to be clear that our main focus for simulcast is the centralized case using a RTP mixer that selects which version to forward. But Section 3 does look at the other usages of simulcast, like point to point. > > Thus there has been perceived little need for > handling multiple SSRCs in implementations. This has resulted in an > installed legacy base that isn't fully RTP specification compliant > and will have different issues if they receive multiple SSRCs of > media, either simultaneously or in sequence. These issues will > manifest themselves in various ways, either by software crashes, or > simply in limited functionality, like only decoding and playing back > the first or latest SSRC received and discarding any other SSRCs. > > > As an implementer of a point-to-point videophone, we handled SSRC changes, > but only were set up to decode one stream at a time (especially of > video). (A later > phone could decode up to 3 and encode 1 when acting as a bridge for an > ad-hoc video conference.) > > Our algorithm was to immediately react to an SSRC change, but then lock > out changes > for a (short) period because since we only played one stream at a time > we didn't want to reset the > codec on every other incoming packet. This also helped us with a few > other usecases involving > various B2BUA-ish servers and server-mediated call transfers, etc. > > Not truly compliant per-se, of course, but worked for the usecases we > needed to deal with. Yes, and what you say is a confirmation of the claim we are making. There is a number of implementations that has limited support for multiple SSRCs but they don't express that in signalling. Therefore to make these multiple SSRC applications work well going forward we need explicit signalling of the number of simultanous SSRCs one support. > > Simulcasting has the benefit that it is conceptually simple. It > enables use of any media codec that the participants agree on, > allowing the mixer to be codec-agnostic. Considering today's video > encoders, it is less bit-rate efficient in the path from the sending > client to the mixer but more efficient in the mixer to receiver path > compared to Scalable Video Coding. > > > If you're targeting a single lower-bitrate encoding, yes. If the > bandwidth down to each receiver > is adaptive to their available bandwidth (think mobile reception, or > WiFi) then giving the mixer > the ability to subset differently for each receiver without having to > re-encode. (And it avoids > having to tell the sender to change bitrates if one of the receivers > needs a lower rate than the > sender is sending, and it avoids giving all the other recipients a > lowest-common-denominator > stream). Of course this is part of the entire value-proposition of SVC > - that it enables this sort of > optimized reception with a single encoding and a low-horsepower mixer. > Yes, I realize I'm saying > fairly obvious things here. Exactly, this is the whole point of simulcasting. And our research hows that this has some advantages over SVC. > > If only resolution and temporal variations > are needed, this can be implemented using H.264, as each simulcast > version provides the different resolution, and each media stream > within a simulcast encoding has temporal scalability using no- > reference frames. > > > Note that this implies that the mixer parses the H.264 to the point > where it knows if the frame > will be used as a reference frame. Not a problem, and probably doesn't > require any change to the text. Yes. you need to look at the NRI bits in the H.264 RTP payload header to make this determination. But you need to do similar operations in an SVC MANE if you single stream transport (SST) payload mode. So no real difference for the temporal scalability operation. > > Even within SVC (and you may have stated or implied this) you could make > multiple encodings > with differently-targeted layers - for example a "low" set targeting > bandwidths <500K, and a > high set for 500K and up. This might help avoid the problem of too many > layers degrading > the bit-efficiency of the encoding. I try to make clear that I see combining SVC for medium and fine-grained scalability while using different SVC encodings for the large steps and send them as simulcasts to improve the efficiency of the system as an option. > > 3.2. Simulcasting to Consuming End-Point > > > This section is clearly based on the assumption (up front) that the > streams are in fact identical > content with different encodings. Not a problem, especially if the > target of the document is > a little clearer. Yes, we always target simulcast where the original source of the content is the same, only the encoded representation is different. > > 3.3 and 3.4: These assume no mixer, right? Yes. > > 4.3: negotiation of transmission side - how does an endpoint indicate > these are "equivalent" > streams and not "alternative" streams (different camera/mic, etc). How > are the differing > encodings negotiated, or is that out of scope? (I'd think it would be > in-scope, because the mixer > is the one who knows who's connected to it and their capabilities.) I hope you got this explained when you read on. We have the SCS and SCR grouping semantics to indicate that media lines are simulcast alternatives to each other. The actual SSRCs in the different RTP sessions are paired as alternatives using the SRCNAME SDES item. In practice SRCNAME that are identical for media streams of the same media type are alternatives to each other. The negotiation of what alternative stream is done as regular offer/answer for each media line, thus allowing us to avoid re-inventing that mechanism. > > 4.5: SDP signaling and bandwidth - b=AS could be used in theory for > either direction, however > the general offer/answer semantic is that you define what you're > willing/ready to receive, not send, > so b=AS would be the downstream direction, not the highest of upstream > or downstream - I don't > know of any that use it that way today. Some use upstream (perhaps > most), some use downstream. Yes, I think there is great confusion around how the bandwidth modifier actually are used. Our examples in the end do use b=AS as receive direction only. The discussion in this section may not be as consistent. I think the main point from our side is that there is need for additional bandwidth signalling attributes to allow one to express assymetric capabilities vs desire and do O/A negotiation of it. And do that both for individual steams and encoding proposals and for the whole session aggregate. > Also there should be discussion of how RTCP TMMBR fits into this. Likely, from my perspective TMMBR has quite clear semantics as it applies to a particular SSRC. Thus the stream and direction for a given TMMBR limiation is clear. But, I guess it is good to understand what the upper limit for that stream may be. > > nit in 6.2: > > When one have multiple actual media sources in a session, > > have->has Ok > > 7.1.2: SSRC Multiplexing > > Note that "legacy" receivers will often be much happier with NO SSRC change when the > mixer switches streams. While in theory they should handle them, not all do. And even > if they do, they may cause glitches at the transition (decoder resets, etc). Yes, they > shouldn't do that. Full agree, and as this is an RTP mixer I assume that the mixer will have its own SSRC value that it uses to send what ever stream it mixes or selects from the incomming the content of the media, but sent as a consistent media stream from the mixers SSRC. Thus we don't have SSRC switching. The issue I bring up is that of the CSRC field. If one include CSRC then that changes. But, in fact I think this is mostly a mote argument. Also for Session multiplexing we likely will have this issue as using different SSRCs in the different RTP sessions have advantages. > > > NAT Traversal Failure Rate: Due to that one need more than a single > flow to be established through the NAT there is some risk that one > succeed in establishing the first flow but fails with one or more > of the additional flows. The risk that this happens are hard to > quantify. However, that risk should be fairly low as one has just > prior successfully established one flow from the same interfaces. > Thus only rare events as NAT resource overload, or selecting > particular port numbers that are filtered etc, should be reasons > for failure. > > As the number of flows increases, the odds of a lost packet (or congestion) > increase. The pacing timer should help with this, but even so I believe the > odds of problems will increase above a linear rate. However, this is an > off-the-cuff assessment and I haven't followed the ICE discussions (N zillion MB > of them...). :-) Maybe, and I would love to know how real the issue is. Also, to a certain degree this is an orthogonal problem if it is real. Because it will occur also for SSRC multiplexing as even that case has multiple underlying UDP flows, just a few less than Session multiplexed Simulcast. > > 8.2. Mixer Requests of Client streams > > I'd guess TMMBR of 0 may not go over well with some existing clients, or may be ignored. Very much possible. We plan to follow up on this topic in the future. > > 8.4 Multiplexing sessions > > This touches on the discussions currently in rtcweb Yes, it does. It has also been voiced in discussion around CLUE interest of multiplexing multiple sessions on top one underlying transport flow. My main point is that it is separate problem that needs to be addressed somehow. If you are interested in this problem I would recommend that one do read the next version of: https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ It will be out on Monday. Which tries to make clear the issues which the Rosenberg's proposal and discuss possible ways forward for that topic. https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/ > > 8.5.1.2 Multiple sources (telepresence) > > Ok, this confuses me as the discussion I thought was of simultaneous encodings > of the same data, not true different sources. Well, this is the case that tries to make it clear how you can combine multiple real media source, like several cameras in a telepresence room, with simulcast. > > At this point I'm afraid my eyes have glazed over reading the (very nicely detailed > and explained) SDP examples. :-) Yes, those examples are quite beefy. But, I do hope that they will help people understand, it also helped us making clear that we had a coherent story for many of the different usages we see for what we propose. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Mon Jul 11 07:04:00 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2593421F8BD3; Mon, 11 Jul 2011 07:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98ko5dOTO2IN; Mon, 11 Jul 2011 07:03:59 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id F2E2721F8BCD; Mon, 11 Jul 2011 07:03:57 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QgH5Y-0005dB-cW; Mon, 11 Jul 2011 14:03:56 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DF8B472.9090602@ericsson.com> Date: Mon, 11 Jul 2011 15:03:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <72ACD3ED-6D79-495E-ABD4-2F04A42F5035@csperkins.org> References: <4DF8B472.9090602@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: Gorry Fairhurst , Pasi Sarolahti , DCCP WG , "mmusic@ietf.org" Subject: Re: [MMUSIC] Reviewing draft-ietf-dccp-udpencap X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 14:04:00 -0000 On 15 Jun 2011, at 14:32, Miguel A. Garcia wrote: > A quick review of Section 5 of this document: >=20 > - I think it is a good idea to clearly indicate which SDP attributes = are newly created and which ones are reused from other RFCs. I therefore = recommend to add the following sentences somewhere to the corresponding = sections: >=20 > 5.3: > RFC 4145 [RFC4145] defines the "setup" attribute whose purpose is to = indcate which of the end points should initiate the connection = establishment. This document reuses the "setup" attribute to similarly = indicate which end point initiates the DCCP-UDP connection = establishment. >=20 > 5.4: > RFC 5245 [RFC5245] defines the "candidate" attribute whose purpose is = to provide one of many possible candidate addresses for communication. = This document reuses the "candidate" attribute to indicate native or = encapsulated candidate addresses Agree. These both seem good additions. > - In 5.2 last paragraph, I am missing some normative statements, for = example: >=20 > If RTCP is multiplexed with RTP, endpoints MUST encode the DCCP port = used for RTCP in the "rtcp" attribute specified in RFC 3605 [RFC3605]. = An SDP offerer MAY indicate its willingnes to multiplex RTP and RTCP = onto a single DCCP port by adding an "rtcp-mux" attribute as specified = in RFC 5761 [RFC5761]. If the answer also includes the "rtcp-mux" = attribute (as per RFC 5761 [RFC5761]), then RTP and RTCP are multiplexed = onto a single DCCP port, otherwise separate DCCP ports are used for RTP = and RTCP. In each case, only a single UDP port is used for the DCCP-UDP = encapsulation. Makes sense. > - I didn't find any description of the "dccp-service-code". However, = it is written in the examples in Section 5.5. Is this a leftover from a = previous version of the document? It's from RFC 5762. We should add a reference. > - I agree with your comment at the end of Section 5.5 indicating that = an example using ICE would be beneficial. Yep. > - Section 7.3. There are two references pointing to Section 5.1 in the = document, but they should actually point to Section 5.2 >=20 > - I think the following references should be made normative: ICE-TCP, = RFC3264, RFC 4566, RFC5245, RFC5761 I'm happy with all of these being made normative. Cheers, Colin > BR, >=20 > Miguel >=20 >=20 > On 15/06/2011 9:42, Pasi Sarolahti wrote: >> Hi, >>=20 >> In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram = Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal = (DCCP-UDP)"). This draft has parts related to the work done in MMUSIC = (especially Section 5), and it was presented in the MMUSIC meeting in = last IETF. The authors have modified the text based on the input = received, and we are now looking for volunteer(s) from MMUSIC to review = whether the new text (mostly in Section 5) looks ok, before moving = forward with the draft. >>=20 >> The draft can be found at = http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08 >>=20 >> - Pasi >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From fluffy@cisco.com Mon Jul 11 09:07:39 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD4521F8C8C for ; Mon, 11 Jul 2011 09:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.691 X-Spam-Level: X-Spam-Status: No, score=-104.691 tagged_above=-999 required=5 tests=[AWL=-2.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Awa6n+OEWhB for ; Mon, 11 Jul 2011 09:07:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 318D921F8665 for ; Mon, 11 Jul 2011 09:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2865; q=dns/txt; s=iport; t=1310400459; x=1311610059; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NxSmwQZuhCJ06sfbzxcq1XTJd47l0GCtJtRq4y43qMY=; b=bEUL3Z+KuH7O63g8PMJYzyZKwWqyUUH7yzdnx6zO345x+GHke2eGHrgQ YCEAygo5il6NFt8Cd9L0OR+3oNJB21xm8OizJF7p7jhtiMLayReO3LEVl sxd0XK0NQPmHGoC7or9keyX755XqPkBuCBtSY6T9I1/uBNDYZXYRuaOxU k=; X-IronPort-AV: E=Sophos;i="4.65,515,1304294400"; d="scan'208";a="1773898" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jul 2011 16:07:38 +0000 Received: from [10.21.75.103] ([10.21.75.103]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6BG7bGN019896; Mon, 11 Jul 2011 16:07:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <224F5CB1ECAB2C45BC64065AFD0339650406B5FD57@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 11 Jul 2011 08:23:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <224F5CB1ECAB2C45BC64065AFD0339650406B5FD57@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: mmusic Subject: Re: [MMUSIC] Comment on draft-jennings-mmusic-adjacent-grouping-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:07:39 -0000 On Mar 18, 2011, at 5:46 , Christer Holmberg wrote: >=20 > Hi Cullen/Ali, >=20 > There were some comments given on this draft in Beijing, but I am not = sure they have been addressed in the new version. >=20 > Q1: Declaration vs negotiation > ------------------------------ I've decided the work declarative in the context of SDP just creates = confusion. I removed all this and tried to make it clear what one can = and can not do with it.=20 >=20 > Q3: Audio/video association > ----------------------------- >=20 > The draft does not provide a mechanism to e.g. associate audio and = video streams. I GUESS that could be done by using the same mid value = for two streams (e.g. an audio and a video stream). IF that's the case, = I think it needs to be described. I don't really have any good use cases to drive this but imagine we had = a two screen video conferencing system where each screen had a camera = above it and had microphones on both sides of the screen. Roughly = speaking going from left to right we have Mic1 Cam1 Mic2 Mic3 Cam2 Mic4. = If theses were the mid labels I could imagine a few things one could do=20= 1) Create an ADJ group that had mixed audio and and video such as a=3Dgroup:ADJ Mic1 Cam1 Mic2 Mic3 Cam2 Mic4 2) Create two ADJ groups, one for the audio and one for the video=20 a=3Dgroup:ADJ Mic1 Mic2 Mic3 Mic4 a=3Dgroup:ADJ Cam1 Cam2 3) Probably a better solution than either of these is use ADJ for the = cameras then put the audio into some surround sound audio stream.=20 I'm not really two worked up about things like this as I have not seen = uses case for it.=20 >=20 > Q4: Telepresence > ------------------ >=20 > (Assuming this is intended to be used also for negotiation) >=20 > The draft also talks about telepresence, where I agree this kind of = feature very likely will be needed. But, my suggestion would be for CLUE = to agree on requirements before taking on this draft, to make sure that = it can be used to meet those requirements. >=20 > This was also mentioned in Beijing. >=20 > "Magnus Westerlund would like = to see where the telepresence work goes, but was concerned that > we not have two solutions to the same problem. Peter Musgrave = supported him,..." >=20 > "Mary Barnes asked if anyone else = supported the work. Why not wait for telepresence?" >=20 > So, again, it needs to be clarified what the scope of the propsed = mechanism is. I think the proposed mechanism is pretty clear about what it can and can = not do >=20 >=20 > Q5: Editorial > ------------- >=20 > The SDP example shows audio streams (m=3Daudio), but I assume it's = meant to be video (m=3Dvideo)? Fixed - thanks >=20 From fluffy@cisco.com Mon Jul 11 09:07:48 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA43221F8EA8 for ; Mon, 11 Jul 2011 09:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.628 X-Spam-Level: X-Spam-Status: No, score=-104.628 tagged_above=-999 required=5 tests=[AWL=-2.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrX2REJx1JCj for ; Mon, 11 Jul 2011 09:07:48 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6B21821F8665 for ; Mon, 11 Jul 2011 09:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=867; q=dns/txt; s=iport; t=1310400460; x=1311610060; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zeIE3GAFrSbc2omFgbO4sK968T2ZrVle5TUPE8/o67g=; b=Ds4zDiC6zsTEWe9cM1KmmgkTop8voBcY6Cg7fDnu43Byf/6yYydBTwS8 2wOR+LpPcVctZR2og2AbJ2rFg/qNUks4t2ZOIustlwkVUdQiNxzG2fK8J iFC8G6PKbFqWjSID2CnAmiApKw7w7O4oUowRtEdgR2JSWgnII4Hy0N+py E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABEfG06rRDoJ/2dsb2JhbABTpzp3iHqhM51xhVtfBIdOiwaEfotp X-IronPort-AV: E=Sophos;i="4.65,515,1304294400"; d="scan'208";a="1772238" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jul 2011 16:07:39 +0000 Received: from [10.21.75.103] ([10.21.75.103]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6BG7bGO019896; Mon, 11 Jul 2011 16:07:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 11 Jul 2011 08:24:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <376849D4-7F53-4532-AA82-DBC5D046681A@cisco.com> References: <4919E001-92CF-4546-B759-8E4118CEB73E@magorcorp.com> To: Stephen Botzko X-Mailer: Apple Mail (2.1084) Cc: mmusic Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:07:48 -0000 On Apr 1, 2011, at 24:43 , Stephen Botzko wrote: > I am wondering about the following: >=20 > Section 3.1 "This is a declarative SDP parameter and is not = negotiated." this whole topic of declarative has created tons of confusion. I just = removed this and tried to make is clear that this can be used SIP offer = / answer or in RTSP style SDP. However, the sender puts in how it thinks = the streams it is sending should be displayed and there is nothing the = receiver can do to change that - they can use it or ignore it.=20 >=20 >=20 > Also, I do not think the arrangement of audio streams in an MxN grid = is very compelling - do you have a good use case for this? =20 I agree - the only uses cases I have for a grid layout is video. The two = cases I am dealing with are layout of signage and layout of security = video cameras.=20= From fluffy@cisco.com Mon Jul 11 09:10:52 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B407F21F86A4 for ; Mon, 11 Jul 2011 09:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.512 X-Spam-Level: X-Spam-Status: No, score=-104.512 tagged_above=-999 required=5 tests=[AWL=-1.913, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t7Wg1vkQWTe for ; Mon, 11 Jul 2011 09:10:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EF41121F8665 for ; Mon, 11 Jul 2011 09:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1158; q=dns/txt; s=iport; t=1310400652; x=1311610252; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rW9ok33OTPgpDu0LTxxZdFoIeTXlWZiqE1fS7TubmF0=; b=H6ZplCbsfX8Fg6Np3hj1z62vYQ9u+Q80plLDq6b/VDAyZbssN+LVsILM bf59TpY/DwR5Cxzd5g+HoJ5zjSD+b+n2ytY96dSxvDhRRLoo4TxT6KBLp 7ZrHZ7uHLyFu40DTDN6ot2AxhI6Amgbp314nA2MC8dZ9OqKAG7UisUMk1 s=; X-IronPort-AV: E=Sophos;i="4.65,515,1304294400"; d="scan'208";a="1774825" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jul 2011 16:10:51 +0000 Received: from [10.21.75.103] ([10.21.75.103]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6BGAoYn010742; Mon, 11 Jul 2011 16:10:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D8AB3F5.7090902@cisco.com> Date: Mon, 11 Jul 2011 09:10:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D8AB3F5.7090902@cisco.com> To: IETF MMUSIC WG X-Mailer: Apple Mail (2.1084) Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:10:52 -0000 thanks - makes sense - I fixed up the latest version to support multiple = grids.=20 On Mar 23, 2011, at 20:01 , Paul Kyzivat wrote: > (Just catching up on my reading...) >=20 > One observation about this draft: >=20 > The grouping framework permits multiple groups to be formed with the = same semantics. (E.g. you could define two audio/video groups, each to = be lip synchronized.) >=20 > Analogously, one could presumably use the ADJ grouping semantic to = form two independent groups of video streams. >=20 > OTOH, you might want to form two different groupings of m-lines that = both map onto the same grid of devices. (For instance, a grouping of = video m-lines and a corresponding grouping of audio m-lines.) >=20 > But the a=3Dmedia-grid-dims attribute doesn't provide any way to = identify which group it applies to if there is more than one. >=20 > At the very least, the issue of what to do when there are multiple = adjacency groupings ought to be discussed. >=20 > Thanks, > Paul Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From internet-drafts@ietf.org Mon Jul 11 09:14:37 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CDA11E8079; Mon, 11 Jul 2011 09:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyoHm08JGPWc; Mon, 11 Jul 2011 09:14:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C6D11E8077; Mon, 11 Jul 2011 09:14:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711161430.10122.59643.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 09:14:30 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-tcp-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:14:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : TCP Candidates with Interactive Connectivity Establishme= nt (ICE) Author(s) : Jonathan Rosenberg Ari Keranen Bruce B. Lowekamp Adam Roach Filename : draft-ietf-mmusic-ice-tcp-14.txt Pages : 30 Date : 2011-07-11 Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-14.txt From fluffy@cisco.com Mon Jul 11 09:16:23 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8619811E80A4 for ; Mon, 11 Jul 2011 09:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.459 X-Spam-Level: X-Spam-Status: No, score=-104.459 tagged_above=-999 required=5 tests=[AWL=-1.860, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3pokj-no0st for ; Mon, 11 Jul 2011 09:16:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE111E8086 for ; Mon, 11 Jul 2011 09:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=952; q=dns/txt; s=iport; t=1310400969; x=1311610569; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6nSgqnEQmAvcwn5Fc5v3ANrxhhPfb+34zTVRaM9BO0E=; b=ZySTsCJ/4yjp3TVoxmZL5AjmkhHJi5MFcgjz+3YIbhhKV+d5g7gbVjjk WZhHzDDQrY5LjV2kfMZ4s7rUWT6HI8mPHFK8LCd4bnHkm7LCy52D0/SDY jVpA2jzAbQGnUUqQLwArwp32G+AXOlSQLWErSIOUTdkq/Mir4RaSyPQ22 w=; X-IronPort-AV: E=Sophos;i="4.65,515,1304294400"; d="scan'208";a="1776021" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 11 Jul 2011 16:16:08 +0000 Received: from [10.21.75.103] ([10.21.75.103]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6BGG7Ip031335; Mon, 11 Jul 2011 16:16:07 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <6CE189B7-0191-4ACD-A494-6E9871C4701F@cisco.com> Date: Mon, 11 Jul 2011 09:16:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69C44A47-0ED6-4A3C-9485-A9C1C3E1AE08@cisco.com> References: <4919E001-92CF-4546-B759-8E4118CEB73E@magorcorp.com> <6CE189B7-0191-4ACD-A494-6E9871C4701F@cisco.com> To: IETF MMUSIC WG , Peter Musgrave X-Mailer: Apple Mail (2.1084) Subject: Re: [MMUSIC] draft-jennings-mmusic-adjacent-grouping-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:16:23 -0000 On Jul 11, 2011, at 9:10 , Cullen Jennings wrote: >=20 > thanks >=20 > On Mar 31, 2011, at 23:20 , Peter Musgrave wrote: >=20 >> Hi Cullen/Ali,=20 >>=20 >> Overall, I think this is clean and usable. It solves enough useful = cases without trying to "solve world hunger".=20 >>=20 >> Is it worth having an example in which the video is SSRC muxed as = described in section 3.2? >=20 > added=20 >=20 >>=20 >> Also, I believe your example in 4.2 wants to have all the m lines be = video (they are audio in the sample).=20 >=20 > fixed - thanks and thanks to other people that caught this too >=20 >>=20 >> Thanks,=20 >>=20 >> Peter Musgrave >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From ari.keranen@nomadiclab.com Mon Jul 11 09:49:33 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FA121F8CF0 for ; Mon, 11 Jul 2011 09:49:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz0dBNhUQ7ey for ; Mon, 11 Jul 2011 09:49:33 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7421F8AFD for ; Mon, 11 Jul 2011 09:49:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 742E34E6DC for ; Mon, 11 Jul 2011 19:49:27 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCjQ2FrDXsN8 for ; Mon, 11 Jul 2011 19:49:26 +0300 (EEST) Received: from EV000C295089FF.lmf.ericsson.se (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 384BE4E6D1 for ; Mon, 11 Jul 2011 19:49:26 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ari Keranen In-Reply-To: <20110711161430.10122.59643.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 19:49:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110711161430.10122.59643.idtracker@ietfa.amsl.com> To: mmusic WG X-Mailer: Apple Mail (2.1084) Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-tcp-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:49:33 -0000 On Jul 11, 2011, at 7:14 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Multiparty Multimedia = Session Control Working Group of the IETF. >=20 > Title : TCP Candidates with Interactive Connectivity = Establishment (ICE) > Author(s) : Jonathan Rosenberg > Ari Keranen > Bruce B. Lowekamp > Adam Roach > Filename : draft-ietf-mmusic-ice-tcp-14.txt > Pages : 30 > Date : 2011-07-11 >=20 > Interactive Connectivity Establishment (ICE) defines a mechanism for > NAT traversal for multimedia communication protocols based on the > offer/answer model of session negotiation. ICE works by providing a > set of candidate transport addresses for each media stream, which = are > then validated with peer-to-peer connectivity checks based on = Session > Traversal Utilities for NAT (STUN). ICE provides a general = framework > for describing candidates, but only defines UDP-based transport > protocols. This specification extends ICE to TCP-based media, > including the ability to offer a mix of TCP and UDP-based candidates > for a single stream. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-14.txt This new revision addresses all the fixes and changes proposed during = the WGLC. This version is identical to the one posted earlier to the = list. Unless someone thinks we really need the TCP ice-option, I believe = we can move forward with this version. Cheers, Ari From simon.perreault@viagenie.ca Tue Jul 12 12:04:39 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4706B21F8D05 for ; Tue, 12 Jul 2011 12:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEcAWw4TVyJi for ; Tue, 12 Jul 2011 12:04:34 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 4C03B21F8BE4 for ; Tue, 12 Jul 2011 12:04:26 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d5c:a0:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 742D321F69 for ; Tue, 12 Jul 2011 15:04:25 -0400 (EDT) Message-ID: <4E1C9AB8.7050002@viagenie.ca> Date: Tue, 12 Jul 2011 15:04:24 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: mmusic@ietf.org References: <859AD3AD-CA10-4AE4-9986-84CEE62777D7@nomadiclab.com> In-Reply-To: <859AD3AD-CA10-4AE4-9986-84CEE62777D7@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] ICE TCP ice-options? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 19:04:39 -0000 Ari Keranen wrote, on 07/04/2011 12:24 PM: > Hence, I think we do not need "tcp" options tag (and can keep the draft as it is). Opinions? Makes sense. Seems in line with the spirit of ICE extensibility. +1 Go ahead and publish this RFC! :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From jmpolk@cisco.com Wed Jul 13 14:36:50 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9904A11E8120 for ; Wed, 13 Jul 2011 14:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.919 X-Spam-Level: X-Spam-Status: No, score=-104.919 tagged_above=-999 required=5 tests=[AWL=-2.320, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m738JPfcPzVn for ; Wed, 13 Jul 2011 14:36:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C097C11E816D for ; Wed, 13 Jul 2011 14:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1450; q=dns/txt; s=iport; t=1310593010; x=1311802610; h=message-id:date:to:from:subject:cc:mime-version; bh=kNlOZRJ3gAYa02+HPOsinaw68dJRFkd1yTAKasbjh5s=; b=EmUjDuV0ua0t6Qljqgi5UtlPTIc03alNt1Pedk78SsQ4IlCRiykr0x3a Hcll8P1I7LrjgcL+iET1eoVsTEbLw5U/PTEDhU4qASOhVwJKUFVbUrMTB jxteDzO6tmfVZU9xz50zKaTXuOT6p+KI/KloxH2FVcQZVdBJ6hLg/9Xg2 M=; X-IronPort-AV: E=Sophos;i="4.65,527,1304294400"; d="scan'208";a="2699210" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 13 Jul 2011 21:36:49 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6DLamPn002152; Wed, 13 Jul 2011 21:36:48 GMT Message-Id: <201107132136.p6DLamPn002152@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jul 2011 16:36:46 -0500 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Subha Dhesikan \(sdhesika\)" , Paul Jones Subject: [MMUSIC] New rev of the Traffic Class attribute draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 21:36:50 -0000 MMUSIC We have recently submitted the next version of the traffic class attribute, here http://www.ietf.org/internet-drafts/draft-polk-mmusic-traffic-class-for-sdp-02.txt Most of the work in this version has to do with a newly inserted Section 2 (i.e., the old section 2 is now section 3). This new section 2 creates and defines the framework for this attribute (something Christer mentioned he would like to see. Also, several mentioned they wanted to see term or string definitions we were proposing that the last version lacked. This is in the new version. With the addition to this new section, the biggest changes are as follows: - we changed the attribute string have this format parent.application(.adjective)(.adjective)(.admitted/non-admitted) (this isn't the exact ABNF, which is in Section 3 now) - We added that the parent and application components are a pairing. - we added that there can be zero or more adjective components describing the traffic class - we provide a list of each component for we review, i.e., separate lists of parent, application, adjective and cac-class components. Some of the application components are settle (i.e., we have one for Netflix type of traffic, but don't have an actual string picked yet). Most of the rest of the changes were minor nits or changes to the new attribute structure. Comments are really appreciated. James, Paul & Subha From Martin.Stiemerling@neclab.eu Thu Jul 14 02:31:45 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FDB21F877A for ; Thu, 14 Jul 2011 02:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.614 X-Spam-Level: X-Spam-Status: No, score=-98.614 tagged_above=-999 required=5 tests=[AWL=-3.508, BAYES_50=0.001, CN_BODY_35=0.339, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFXpmVs4M7wm for ; Thu, 14 Jul 2011 02:31:40 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3000721F8778 for ; Thu, 14 Jul 2011 02:31:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8B96628000327; Thu, 14 Jul 2011 11:31:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzFMhYKGBF+T; Thu, 14 Jul 2011 11:31:38 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D5FCE28000198; Thu, 14 Jul 2011 11:31:23 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.22]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 14 Jul 2011 11:31:23 +0200 From: Martin Stiemerling To: "Roy Yue(PeiYu)" , "mmusic@ietf.org" Thread-Topic: Review Report of RTSP 2.0 draft Thread-Index: AcwZ6O+T9jCll7vaQYC1JLTWCU/oVQoH4b+Q Date: Thu, 14 Jul 2011 09:31:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: multipart/mixed; boundary="_006_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 14 Jul 2011 03:34:03 -0700 Cc: Flemming Andreasen Subject: Re: [MMUSIC] Review Report of RTSP 2.0 draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 09:31:45 -0000 --_006_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_ Content-Type: multipart/related; boundary="_005_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_"; type="multipart/alternative" --_005_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_ Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_" --_000_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm95LA0KDQpUaGFua3MgZm9yIHlvdXIgdGhvcm91Z2ggcmV2aWV3IG9mIHRoZSBSVFNQIDIu MCBzcGVjLiBUaGUgZml4ZXMgaGF2ZSBiZWVuIGFwcGxpZWQsIGFzIG5vdGVkIGluIHRoZSBhdHRh Y2hlZCBleGNlbCBmaWxlLg0KDQpUaGVyZSB3aWxsIGJlIGFuIHVwZGF0ZSBvZiB0aGUgUlRTUCAy LjAgZHJhZnQgYXZhaWxhYmxlIGFzIHNvb24gYXMgdGhlIEktRCBzdWJtaXNzaW9uIGlzIG9wZW4g YWdhaW4uDQoNCiAgTWFydGluDQoNCg0KRnJvbTogbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJveSBZdWUoUGVpWXUp DQpTZW50OiBUdWVzZGF5LCBNYXkgMjQsIDIwMTEgMTA6MDMgQU0NClRvOiBtbXVzaWNAaWV0Zi5v cmcNCkNjOiBGbGVtbWluZyBBbmRyZWFzZW4NClN1YmplY3Q6IFtNTVVTSUNdIFJldmlldyBSZXBv cnQgb2YgUlRTUCAyLjAgZHJhZnQNCg0KSGVsbG8gTWlndWVsLCBGbGVtbWluZywgZXQgYWwsDQoN CkFzIHByb21pc2VkIGR1cmluZyBJRVRGICM4MCwgSSBoYXZlIGZpbmlzaGVkIHJldmlld2luZyB0 aGUgd2hvbGUgUlRTUCAyLjAgZHJhZnQgKGkuZS4gZHJhZnQtaWV0Zi1tbXVzaWMtcmZjMjMyNmJp cy0yNykuDQpFbmNsb3NlZCBpcyB0aGUgY29tbWVudCBhbmQgZWRpdG9yaWFsIHByb3Bvc2FsIEkg aGF2ZSwgaW4gYSBzaW1wbGUgZXhjZWwgc2hlZXQuDQpQUzogc2hvdWxkIEkgcHV0IGl0IGluIGFu eSBzcGVjaWZpYyBmb3JtYXQgaW5zdGVhZD8NCg0KQW1vbmcgdGhlIGNvbW1lbnRzLCB0eXBvcywg YnVncywgdGhlIGZpcnN0IDE0IGNvbW1lbnRzIGFyZSBtb3JlIHNpZ25pZmljYW50LCB3aGlsZSBv dGhlcnMgYXJlIG1vcmUgb2J2aW91cy4NCg0KQmVzdCByZWdhcmRzLA0KUm95KMDWxeDT8SkNCkh1 YXdlaSBTb2Z0d2FyZSBUZWNobm9sb2dpZXMgQ28uLCBMdGQgW2h1YXdlaV9sb2dvXQ0KDQpONSwg Tk8uIDEwMSwgSHVhd2VpIEJhc2UNClJ1YW5qaWFuIEF2LCBZdUh1YSBEaXN0DQpOYW5qaW5nLCAy MTAwMTIsIFAuUi5DDQpUZWw6ICs4Ni0yNS01NjYyMjA1OA0KRmF4OiArODYtMjUtNTY2MjQwODEN Ck1vYmlsZTogKzg2LTEzODA5MDMwNDAxDQpFbWFpbDogeXVlcGVpeXVAaHVhd2VpLmNvbTxtYWls dG86eXVlcGVpeXVAaHVhd2VpLmNvbT4NCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0Ksb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3 osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDO yr3KudPDo6iw/MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8 /tbQDQq1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqrei vP7Iy7Kiyb6z/bG+08q8/qOhDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRh aW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5k ZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQg YWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFu eSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpk aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3Ro ZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5 DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0K --_000_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Ro= y,

=  

Thank= s for your thorough review of the RTSP 2.0 spec. The fixes have been applie= d, as noted in the attached excel file.

=  

There= will be an update of the RTSP 2.0 draft available as soon as the I-D submi= ssion is open again.

=  

 = ; Martin

=  

=  

From: mmusic-bounces@ietf.org [mailto:mmusic-bou= nces@ietf.org] On Behalf Of Roy Yue(PeiYu)
Sent: Tuesday, May 24, 2011 10:03 AM
To: mmusic@ietf.org
Cc: Flemming Andreasen
Subject: [MMUSIC] Review Report of RTSP 2.0 draft<= /p>

 =

Hello Miguel, Flemming, et al,

 

As promised during IETF #80, I have finished reviewi= ng the whole RTSP 2.0 draft (i.e. draft-ietf-mmusic-rfc2326bis-27).

Enclosed is the comment and editorial proposal I hav= e, in a simple excel sheet.

PS: should I put it in any specific format instead?<= o:p>

 

Among the comments, typos, bugs, the first 14 commen= ts are more significant, while others are more obvious.

 

Best regards,

Roy(=C0=D6= =C5=E0=D3=F1)
Huaw= ei Software Technologies Co., Ltd 3D"huawei_logo"

=
N5, N= O. 101, Huawei Base
Ruanjian Av, YuHua Dist
Nanjing, 210012, P.R.C
Tel: +86-25-56622058
Fax: +86-25-56624081
Mobile: +86-13809030401
Email: yuepeiyu@huawei.com
http://www.huawei.com
---------------------------------------------------------------------------= ----------------------------------------------------------
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA= =B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB= =CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2= =C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

--_000_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_-- --_005_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=6737; creation-date="Thu, 14 Jul 2011 09:31:22 GMT"; modification-date="Thu, 14 Jul 2011 09:31:22 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_005_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_-- --_006_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Review of RTSP 2.0 from Roy YUE.xlsx" Content-Description: Review of RTSP 2.0 from Roy YUE.xlsx Content-Disposition: attachment; filename="Review of RTSP 2.0 from Roy YUE.xlsx"; size=29217; creation-date="Thu, 14 Jul 2011 09:31:07 GMT"; modification-date="Thu, 14 Jul 2011 09:28:11 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQB7ksghfAEAAIEFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lE1uwjAQhfeVeofI2yoxdFFVFYFFf5YtEvQAJp4kFolteQYKt+8kAVQhCopgkyi2533vOR6PJpu6 itYQ0DibimEyEBHYzGlji1R8zz/iZxEhKatV5SykYgsoJuP7u9F86wEjrraYipLIv0iJWQm1wsR5 sDyTu1Ar4s9QSK+ypSpAPg4GTzJzlsBSTI2GGI/eIFeriqL3DQ93ThbGiui1W9egUqG8r0ymiI3K tdVHkNjluclAu2xVs3SCPoDSWAJQXSU+GCaGGRBxMBTyJDNAhf2gu1QJV7bGsDQeHzj6P4Rm5v9U u7ov/h3BaIimKtCnqjm73FTyx4Xlwrllcl6k79a0W5TUyti97zP8djHK9jW8sZEmXyt8wQfxGQPZ Pq+30MpcACJtK8Abp+1EL5FLFUDPiE9vcXMDf7XP+eCWmgbnkbs2QP9d2LdIUx17FoJABg5Ncuqw HYjc8v2BRxcBNHeKBt2Xna2QXH01vpM5AZftBTr+BQAA//8DAFBLAwQUAAYACAAAACEAE16+ZQUB AADfAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz07DMAzG70i8Q5T76m4ghNDSXSak3RAqD2AS 94/axlGSQff2BCQElUa7A8fYnz///Cnb3Tj04o18aNkquc5yKchqNq2tlXwpH1f3UoSI1mDPlpQ8 UZC74vpq+0w9xjQUmtYFkVxsULKJ0T0ABN3QgCFjRzZ1KvYDxvT0NTjUHdYEmzy/A//bQxYTT3Ew SvqDuZGiPLm0edmbq6rVtGd9HMjGMyuAxkjWkFk5n9h8bNM1okRfU1TSsH5K5QDoXJawJZwn2lxO 9Pe1MFBEgxFBs6d5nk/FHND6cqDliKaKn3TGHt7Zd6/M3RzL7X+y6GOIPCyE86X5RoLJtyw+AAAA //8DAFBLAwQUAAYACAAAACEAgT6Ul/QAAAC6AgAAGgAIAXhsL19yZWxzL3dvcmtib29rLnhtbC5y ZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLPSsQwEMbvgu8Q5m7TriIi m+5FhL1qfYCQTJuybRIy45++vaGi24VlvfQS+GbI9/0yme3uaxzEBybqg1dQFSUI9CbY3ncK3prn mwcQxNpbPQSPCiYk2NXXV9sXHDTnS+T6SCK7eFLgmOOjlGQcjpqKENHnThvSqDnL1MmozUF3KDdl eS/T0gPqE0+xtwrS3t6CaKaYk//3Dm3bG3wK5n1Ez2ciJPE05AeIRqcOWcGPLjIjyPPxmzXjOY8F j+mzlPNZXWKo1mT4DOlADpGPHH8lknPnIszdmjDkdEL7yimv2/JbluXfyciTjau/AQAA//8DAFBL AwQUAAYACAAAACEAaVisFVMBAAAlAgAADwAAAHhsL3dvcmtib29rLnhtbIyRUU/CMBSF3038D819 l40JKISNxKiRF2MiwnNt71hD1y5tx+Dfe1cy8dGn3nvafr3ndLk61Zod0XllTQ7jUQoMjbBSmX0O X5vXu0dgPnAjubYGczijh1Vxe7PsrDt8W3tgBDA+hyqEZpEkXlRYcz+yDRraKa2reaDW7RPfOOTS V4ih1kmWprOk5srAhbBw/2HYslQCn61oazThAnGoeaDxfaUaD8WyVBq3F0eMN807r2nukwamuQ8v UgWUOUyptR1ehQkw1zZPrdK0O79PM0iKX5MfjhE1oPtw6sjFmZICJrHkrQ4bMjy8R3o2ybJZf7cP Z6uw81dM37LTThlpuxwo6vNQz6npor5TMlTEmVNAg/aGal8FEsezSdqzkz/wGCg9EldmotvPPmQa MWprMkS1Wygq3FqOI2G4JrgWZK9f4sFs+pBN44nhh4sfAAAA//8DAFBLAwQUAAYACAAAACEAJ88B GhU5AACEiQEAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s7H3rcttWsu7/VOUdVvHHiVVbokRdfFES TimyPPFsX1QSfbJnplK7IBKUsE0CDABaVn6dpzkPdp7kfF/3WiAogjIFUCSUksszkUUQWFir7/11 909/+zocmC9+nARR+HOj1dxpGD/sRr0gvPy58anzZutlwySpF/a8QRT6Pzdu/KTxt/b33/2UJKnB d8Pk58ZVmo4Ot7eT7pU/9JJmNPJDfNKP4qGX4p/x5XYyin2vl1z5fjocbO/u7DzfHnpB2DDdaBym Pzf2dw4aZhwGf4z9Y/3N7otWo/1TErR/Stun3qX/03ba/ml0hTWkQfc0Nv0oTN/2sOKGSW9GWFgY HUehfZHGdvunbX5Xvs9lHiYjr4ursI7Ej7/4jfZZ5/zUXHmJSa9i3zf9MV5x6IepNzAjL06TQ3Pu J9wVc4L3vxgEyRU/3jTv/V7gmdf+IMDTbgyemsbRYNNgj/A/439N/TAJLoJBkN6YYdTzB6bnJ904 uPB75sIfRNdNU/5tYmzIHS8kN97GRfx7iv9L/jRfvAH2qcVN6UaDKDbx5cXPjTf4s4M//HX8Bi+h 1x17g+AiDvjbvjcMBjf66z359pUXJ769sLW3z9/Joft60TAIo5i/3JZH4+DiKI3wzIVWlYJ6cEKy zm8vaLfMgoo37iGoYKE3Xtk5OJocKBt9iz7WdxKz25bGwWefdFZAx/dbZzkSdlsn7Dy7vMqrWiYd 3yVseOblxGe7cxUkJhn53aAfdL2UItEJtMQEoTkaQeD3gq/mtbmKrg1EtBknfmLOX5+af5+9Od4/ eP78dwjsWGQlZCiEJ+XhiLeSLS21MLzQHEm4vAXPHvi66ZHqBls4u7ACSlyZfDmlVoXqzA60vhLm NumV5ou7yA+7YbxB6schtuQLWMGLfZopYJ8BNOqFl8AUABsFoRpJZCkwEuSZWgZT27duiuvWkeLE jnscFKeyUoRdM2PbpUs834yiJCADwnI3ENg9yuHseaDW9ZuDFzcLred+an2ZCnSccPPIhmdeeOmb KzgtfmyenftdUXut5829lxu4wEtNMh6NIvgJJvHhB8Br6AX9vh9TvaXBEA6Fuj+H5gN/GJjTgXdj Ovwku91+82Bj05y/P+2cyCfwM4ajJP/5/oa6FRdJNBinkCG3vv98w/oSpcXYHBVq3qaQYElkRnH0 JQAJG88MvdGI+3Php9e+H5qzzqksyC6b/g+3zsoLXWsCiecr2S+Z5Je1woVIcmWadBCEBTb6ulWA nOJCG7UC3m1XlKJp+50PtvW/+sPRIOjfmOsgvTLpdQTKHQ6hiYfi4DOqAKof94JIeJBcEFWj5PVL YLz5D8nsQa6bvnggs6sqsGhXQF5zYgQVyKW8bG7vNg+aLdmZZUtPY/JG+6EpMBXWTRVHUK2pifr0 KBeijpVJ6Y8LLmh95ApnexjB6UhSBF6HCdS4eGhwO9JItfQgoKmC+KdHuTca+DAvVPL1fVxGba6W q4Qtb3BZ3ua2n43ELMJNen4fmiuLb04RV6ISVtYD0ymUCIE+Spcn7lHUh1+LUFzYG+A+8IYkQIuo LAww7/Iy9i89rJDGBaKtVVVAMZMf2YcieCGBX1jRsjlUCmLVfE1/NEFK67qLbU393iaMogBuiLy7 3TKs7wZvwO/IHv+QmNhHYDtJHybuu+xV14vVnmVu88ZCC1sfy8057QrSv+EJEzTKK4C03QC/kZMq 3WS/+aq5V2UVnSt4RuQb8SlwRkYYgnEPyHdGDfk75zkM4Sl1IQnggfXGsbhk1qMCP14ioGIFFWRa NI67/mH5pd0ZxVnWkmcJd92qlZs4u6oCg2tVKrVYIHOZYYFlUrDQFfB9W3XWNNWVZu/5lHem2mKx 917VAbWfLUQvqzgGF415sdCKVrZBdddPNE/O/GQUhYhO12vr6kdbL+u1QXWnrSEsZoA0Eib+oKM1 9jnJc1C5X/qhHwddqG651F0D9Y8Uodl9ubsryUL+oMnCNPbCBBFVMQAugEjB7Z/xTiPvZhB5sLD7 YjXYG25U9AmWJI/rJwBXsKJi7S0+5P0kzgrW2nbqYzEWX8GK5uzeX4Cn0jacU/8rshoDn+yKHILl fvDzDf0BbG+Gs8qlZhE/UOQQkiGvTy1rLzkEtpyl1UyT9qLumDC1hdTXCmi7arB+vlTuUBPAFgda cZq2tpS2QHiI6zN45MIvBkEx/sOaQO8/nXeQyzJJcBkiSYXY1Y2QYxB2B0gEqmvqOczK1js/vESe wKUEE2AGnSRBWrCFTNz33wEWSZgifQL+Ffzdml29YuHy7c2b7Bq4tNQW9QN/IIE8nIIG8yzz51KW 2S6tx6Mr3hxz5MSUkpIQyoePQixCHD0NUE62iJhKR1aBWiXTeClrqhBYGnTHAw/RWT+9inrmGeno vf78mjFUSeHncsCtvY0N5PJh+4QRU7KAjyIsDrgVErHT4rSi/ZO2f7uCsz19T4ro7JUlT5Z9vinM MlCukPdDUtyJ9R6iyTHgoMpVRCLYHehHfAMu/hlCvFHM6C4+AiN3/R5ZeeNBgjnferXasW2bmz27 qgI2WZl/G4QLrQfcviYY74pIs3TEZx7UwkTG/MuPI+onSZL8qrATYgESshkYq4swLnTVDBdJlvpQ nSuATDJoyXMAS2zWYfLLF81d/JpPyVlh2VdeNVsbP8oRL9nQMkt8wYVIcGUsocZAzVPX2QHnaeJp H1msMqduodgsyPaxkI1q5gfUjDLb2eZNpEx5Odp+g+TrOPa3Uu8SKSWkabR0yACiE6ZAqaOciZEo SXYjiU0DH7njvn5LMOtMiTWNgR2MgNXkNvwOU8+IwAe4bbZqWPj7LchOuKVfb7aKPt4jlE8/Pldk IG6V//4e2Y8x2E+hhQ7euuBgb8N5F2I6J2rQlRLGabuTQfdMEoHQL8dBzxNXKTTX1Ciw7JDDTqIQ tU3YAtjoE9uMF6O+CepHdlfSMNgteMySlEekD9CB5Coaw8APYZZeeczJEW8g+f3WjonGqVSN0dKz egggBBh7cgObYF/CLUU5ggLCH1I8Z8CcPBEO0Jb5B1HnuSvdciStCMyXJPJvf6HC1t/hsf4VjmRW cdTSwZ0ixtk1F9jRa7NbC1lFqHV23Wve63YRp82usk67WzO9rDIKcc9oSl7WfA/zsnShpa7MAod/ ZMN8/tcgSSnU84ul4J/6N/YdbpSEWURX2JifVVGTEEo9A1Oze79ugZBTrLOLq7kcWPfeWaK70xCp y6ZWjeOnbRSUnP/68dO71wLzCsIxIu9ZHLO1swO7zAbmWU9zYw7wMQBhPckRwUgDPDSGnZ8GAwvB xO+QQwJD8zZqwAYI5E/ug49o1tpt9mOam3KX4udqQJOBSKCOYiNRX7k18tnTNw4QfmUhLIQNH5CM u10EVChr+l4wgGPi4jRTYqWUIT/fmqzhfs4S65pZrNiR9xazCVZgELbzdD+7ewXyc2WK9VlSG8xJ +6E5s0Ik4iiMQCcxvOkEAo2hCIGmXHgDONuZNYIiuq+Ar2ya//d//q8c85JlwfQqakVIxSyI4MPs KtcsLOjczC6qgAdXIBiKd20x2qpAza2dh6DORxutW4gaViaRs7BiPqq4/6o2YnoOzZYIeVag4A8R Ar2AbnQkqvni0Pz9pPPfp0dnR+9POidnGvRkmSdMRlbvXIxTCWDSUEPAt9c0b2DFWcQSwrVoC8WG DWgOJQXgsC6le1Ts8nEX42CQ0gZluJRWo0LEmbxFWAdRxRs2k0JfKRiv1eK5v2AVUSwqBc2nTs6P z97+cjJl67J6AoVIxAjYZaibOwj+hK2KPcH31V7VqjpXGiahJlQ1uWovqCmpZAoSNOeKvUtn5hLa ifxj9mzeTl+X9jDsZj6E372BnIpG/Br0HoLLKD+z6UvvS4TAMo11BKCHweWVDR3D9B+jXUbP9ONo aFSjotg8jjxkaars23zzeQn7WS/xkOslstDC1qfFHjcdlhdOxQISfhysIf8r+itJ8oKsgbOBoNEi RGVLLbTEzqGlnqa2rgPwuT/J3mj5mfrDA9wLwmsQDAPeMxwPLyCb0CAEfemQ7IGk6AeX4G1yLP1r 3JOmayQNLMCe6jhbUYd/da+iCNxP7nyYGsbVbcJCvLEynR71F1rP+nh1mTRTnnPQgowMgb6NNi4j xQTM6XoZn0xyv8zgZsEkUC+u0QgNlLk5P+l8OnUxoU0ElAYM3XjTvycH8M7yQIt/40WOJ3PPghJE svE0GEm+tCe5YZT6Ji6VG/t9NoVRxU0wtI1Su1tRa6PH3OYDeYa13rhZ2l+7C7gYxm1l8sGb3aJa OaTLo/sKwqG119yv0iUjbZ987fqjVA1kVhrD8kTDAWhL2LDCoIA7XEsJMzWz1bQ2uCtyIQWwF/oV rQDw3YB2dpRDWWh/AI1iARWRXQq97/X+Z5yI3ledGw2g7wllsD0F7NMr4BGA640jvAdC2Wiw0PX/ JiRVNgBVC0y7Pa+a84aYuTWmprVynCZiRuiJ5txL4rTggRtU/V36yisj8CCoVr1XwcAThS91gQKT d4bqmWSCwFkpvqguqfXHb1C6gOIj/CeNRlUdyXb1Rc+S7Lo1HjyA2UVV1jGleu0W+0flDrkCcb/V RpxdNOkUR0wIUlCB+Z6A7BzuGRJX0EXwRMW6tufbQnCJP208lFG3+Apnj3bd9LaYRbM6A+shqH+Z LSkXpLDy9F7MddJCmXEJxEXRP554T5g0wHk6cW2NoH4Qw1yxafLTo0/nJxI8hJnEUqLQvzaU8c7f 0lBDkBCtmTXBpUk18hhdFAOqSoAhbYstWKFVzfyA4fJ2pH5MyTOaXVWBFlgZX56+O/rnQisC9dyj 3GiZesna//eg6fJM2s6LfATh6RYAQqOWERlI+VBVlS09RKxElBRaS09rKfVTGOP3GHd0CiwacYoD stjP/qU5pbI+wpw6p4d5hVkiedJwcX4Gh1d3DXcXCZbmmPly/LUv0wrgESMl5jqPUdy4iB0STz7m nEhH2ElPZ5qDDNMjfHcIVcgxMbEPudmF+IFyhMuf58kmaohnL4I+zVdS57RpAfvaSQtSWoEIY26X GEAQTgX2tXnZNOEo/Xn/YAtr+P47Y9w/n+9smib+GLMqxlunvrhbkpGM+HfeQJz7KZElmne5E9zi gV1fBd0r+BqCL5RqGmSHUsUigr4Q/9bk0G1Bf+FLuhVqHB50FoFKObhDSNvpqmf/RTPunxt4BP6r //qX9hi35IuQOjNC+OK1/JDhJ0FeAXLBMsCA9gKT5RMQz7J1BboCobs4VgG7EHoqsW69+P4jtF3f nDw6O9gnwf+4BD9OeOstJmA4wesacriGA5uZbi9FXeIMVGqfDNDyt+mQPTq/8R6VcjtzrKkjwCy8 NEUPc/HMeqgnGQsiGdYhElUQB0j0TtAokqQS98yJggAOGv66zrq9LLnljkFTaD2wH0SF9H5ALy7o uf3nO+bZxxBBtSP3ZfMRpX1qjB6xv4Pfw1wC5dBSRzdfe9/3tTMSqo+UWMweW5mntVhAZm0a0mhQ YcVUW9runMOtxrxGcPrQ7O6Zf4DrWq9evTCtg8O9g8PWC/P39x0h01KsIlIOFelV7gADMYt22qR3 iB7gsANQXIHAOfNhGH9AE4MfB11YJpquQq5KRyNCStiMNsKiWo4REBUNdJ18B84ovmI9T9g0jA6d nbx+e3Zy3MmiQ52To7PXH3/7gNJigtguZI6YiB/tJsOEP51d+6RmlXfu4D4W53coZrMxx1v/6zL9 8RyDH6cwg5jxwumW9uIm0IPb/eDPPwf+dj+KpLpse7e5Y+8B+xt/js/9Pw7N/m5r6refsHlbR6yd PjSnmGR5cyz9wbdbzd2p684V+XNoguBrZ3/vP991pz5WSnpPrN3OS/MevYR2d1Bx3do/3D843Nkn OU1df0yEQZhuaase0OCttdqP2UkEng2wCNsTyCJbWukryf9feLF8dojoHeJ+434/u+BcNu/4MNsQ s3/QMqcO/IgpOCkq39HuBwQV9abuWrxb39iFcwFn2I3Uf2Ajp1/tjp3aPzx4/s2dak3fzm1kuZ2q SqxjNtgkAPOsc3wKzW4bboLFnLsgHczUeCKrIjuBg4/hKYprCmio/lbLqqTBdojZpGBF8pRcO/BR yA8HIjs1PI4fduBvoDgLzof2ldgEC061PzvYrcCM87U9mfTe7y0bPeXxPTkGj8sxWD3dltf37dYB 0CfairqcAi9OwLA1CRSjLYm0lZPWM6Lhnm/hNM3fmFQsU1O8LyhGFBj89LUY4usBahoTiNZVbT2I NNqEoi+FYGscgqwP/zuG66//1cYfBHNbRCivYHe3YYRnCmIbwQeo6QeRBndvSf3YfjFDH1t4jwTG EmNPj4KEqjLmXoVcoO2ICNeWuOtMebK+F8Gy0M4EjKTsA+ULAZvcTj5gGYVqVfHCUdHMbAzgoBLR gjFsL3WmdAjLy1zB2Kb53PVifIElJOQw5/z0kJzBF8ehh4LjES1vPBCYGVh3AQZrZAUe8oRRhMTO zYMwonRTLL8t9ePUxXzg1bnkdZccoqDXT9YVhMOZ06xEjY1RoBQBfwaPExFuMZMl3kXe6yHonZrG QQO8bKPymgqC3TzRklCSFAMwxr1rVlK4miqyPKJmsKmhQsVU73oj4VtY1jkOynN5B0+197uH2tcM kceBw8hrWbtdA3YYC6uZYi3sApAVj8NypPDEg8s3hGnvUd6gRgRtW72QGS2Ip56g7CqKkHZ9t3pW EK0zhaX7POW4FCwHR7cmc+EOupzdyHW7XHWXoNMmOUIwzj1/aD6uIDPh6Rw0n8tZl/N0pIzntk8D OaNlq7d8Gq17u6DZdX3FzuwoUoOMdYP5QsSTkqzRIm0m6WqotaOIV6ZRN4JJRGE8uezC3kfFa1XB RoaY+zZPLAE5RZjCzw2YzlE+ADHH4Z1iiVWdfgV26FzF0fhS6rwlX464mlZAX4vXbP796381//k7 DfZcaa7ARvoaDXfjA3CZU9jdMYwFKN9fO51ThDNbZrqNvEzKed56rpNy8MPvFWg4hWbujUN0BQUn wQoSIEvTnKNaffJvOvWChoG5Y1/Q7DVbsCRGAI7BZHLFvNdXEYwlO32i0qqQc4WSo/0hYWtYZpQB MJ5ybeSnP0xQ6SpFNDaWeSTu0dZJaL8r7VSlpABYOLV6MgcqKwHMPsAwVC8MYLJBWnjmD8XEwaDa QUrz2dFk1OnUjryit5e7Fs41QqamQTE18daajQrIOvR0xbZIflUBITJLEUkSly/HD7aMkeIwq9N3 IgoOqZ1NoLMHIBw1V5udIa6UeYrc7AnyCZJXQ8Tg44CT7AknFGJRWxNDeiud97E/GMhIhJ7P1JL0 0VIx7n6h3QWQcMax0+3G2YCrGASD1Y5+AYK9cv64lESTYvTbGNB6o60WcQwsefZxH6St8CY2m3QR pSlyI373M7IaYe866GHMR6ZQsBVoNJbYNrlITEGhgBhALaR86S1IYsRMWo4QEZ+owm4wFN4uvSFP OufeOqfGBFReNRUrWMhVJGOPrVj9heUtdkRLNh5ay66IzDefzt6Szm9HmikZ7Khn23cTUjJAubO7 7zsbSsZ8D8pxGG0zn/DWuA9u7V0k0WAMPsSvNsjHFPz82MXIXKNO+cCGwSDGKI9w54LxIVWqB4T5 yu3SE+fdm/M0gZmbGKMDxOtMVeU5kkCyAqOmmMFoMzS0xUB607B2C7/tNLmq/ywZlHFYZvC8183V 8UWaslWOoZ1EeKcPURBuuWfcsrWYBSIDYqDV4ssmoMPFqZ0lDyaftn9crFuhpDbKpUJnOuKlbwqf Do2UcONckI5Cab91YJ7l2+i/93uBZzpAMFQdFXfHQT3xeFUefxSEXbtjLtbmYQEAej3hQozF1omu bu5enQRBBZH9K3CsCDhtGnZoQGqgKzWKQ5fpQ4PPyzES4hpjGkFi0XGnwIJ5cstsqgQAFrOk0mJq R9LtcHZJ6yHeYuaaSo27w6tASjIgEuGDzBSWqXmyByUjqUdIEaM3HhvrhQwxoP0swjZiFd+iPadD s2dbA929VqkFCE3etYbZ833KCGxL/dE8hPCUFLV2z7wzq0CKJyAbGF5/jNkLxnWGg/HFWB7sNTtI 6cJPr32UcPu82pp1CFoyKmJNMwrGoOk31awVIKsAHBiks7djgISuoTMLGbOxNp/ciWaoNfu0UFWj PshPMtaI7COCOLnviv0sD2oaeYs56+JrZA26rAnJZYR4pyj+jJY7PbxDlWYgafsXOL0cEytr5MLe d7xLI3OS6J3ixeUE9Q1n+/hRQ5i3/a33Xor9tQY6UJdpZaYslmfVl1s/fn7CbNwvvXIXuVWQJx84 thKwbjIrY6M+CrriLkKh1hIiCyiBVwyLFlN2/vGzNFpgU6wMxBMUjIVctw7EAS20STi0NYEMvkU+ FSj1SKP1imEVS+lzGF1rNMRWlJi3r92Qkg8fOwyCiHqb3+VOTP1JexPqx4iVce6btohhORzQPlro 8FZG4XU34iU5s/bjLk+xxRLPjOPBIYv6FY1m6TdFkmoooXMFpdH2msDTJpMdUas6Ke8g7A35ZmLM 0QtdktgMvrsCULFemA1mMFCD7r6xGUZnl/E58kXJfCFQx3XA02Gdpsw6Q1d0WZbc1LHFGe3PJN3i 04CQcwkHfK/DynNYQtoyPVvKSN1rRCSFBUr7LOW2dJbt1i3I5Whnl1Wg79YnypdKggu968okn1eg 22u197Xj2GVLwSPnOYoit0O7EIqDA0utDiCE73/eOk9vAJFXJLxNmlwCiwTIBEIm0NWJL53SRdAp ghfJTQ8RPvudqtnEYnEzZ+2zJL5uKfPkYt3PxXoI2ls246B5gxaAaoMX1HEh1EIl7Exgdq5k4Yni nrTkBFW9MqFDgFihJPUQzOmLEYCg92ffH215HIDiAqfM7vdcu0A0hMDdQ8DQgy9BKiP7vngsE5Pp AzChnTGhpgiNbgwuCNHZSFhiycp+WRtQP3ZNo9k1FWillWlJFHovtKA1miiroeDyPCyQv9v9xqmu Jv2NR+jUwLw6gIAu+WQDkdokSkPJIWbyXNsILlDT+OkiAvazQkxmXhy7I33SGQqCnBnHZHjtP2j5 3WTjq3ZbGy5MCqNfQYlwJgDsybpP4KVsuJYeSB+eCEWQdTgwYwkgTZuXYxue81M8Uwpx7LwhMYMg 2zAxKTpnuxyv+xmvjgIZ9gtjASzuJhk91PSk5hKA3lGFLWFWpFjls3QVO7L6XVmIAVcmER5FxGBh Enra2/vA++/mtwoiEjB6xC8GN4hgxGhfESeAKAMk9OGoA8YH02GSg5ciJied4ANAHhGbZooJV/f7 QZfpoj6EI0VBcoPJcLC6u0BGoxwON4OgwI0MylCY6mkiP4O/6dUYoRPell/ynIhyV3HKJ/5+/537 7+2gBnpNQrC5Nq09Wl+TZh0yJBTfFOoqbfu0H3hXnmj/PrT/TRJ62s77bKc1CSrx29OO32fHXUeW KeFUQWbDHIKbl8V5VVC/h1yU7AmEowawFDSroeWs9Se7kUl1HyU34tkPYrDNLHCWXtYenal9Mq/S gVagrtbLJnqqyYmVUqBaaSWQDheS2LIgDa2YAOuMMWrmNtIq9S43ba88oGkY/8YVjWjkIdvRsIAt fDXoeWkUVyRb8QwXWGL96LbuTsAUEKvEkVYl3Eoda97nsbhYvEpWxLxRuAeTtoEEHYeBZVSYbDZk CHKKmEImV7XdI5Gt8Mq7KP8LkqFA94FxKqB52q+Na9/73GyU5zlBFD786p/YoRKIHxR1+7QrkPvu LuR0JXJnI/Im0sdBFylx6GwMlS6sUaUszkJmDE3zixeIBpkIsTAbmUKBKKBMdOkQTpMY01T1NbPa uaJnlI1e2VGAqKzVoAE4hveOo6+AU1YQ8POiSBHS75gTDCfWTgdASMzWLU+i6HhVp7VQxStzub88 UEO2O9bzxGj3ZTSXBbnj/Krx2qtqvIYxE2CyD6JKzCn4x3SQKvr+uy66B37GJ586x+aYP9PyQXX1 998laE6OnrLm/P1p50SuRiHXcKTJ85KWGWVGRePuDF2eoAct11M0cE7VhygN+jeY38tib5v9EtAK pgb3OWubKnICpOFpgbk4/KPK+8wNF8O3mZI+4GmuGuEtsztxnOw6Rx7GcGkbY7Ak0N3SXxc/xikG hw8V9FdpwytJ6V8RloMtcfTLhzdaPazTGxGk457OZupDgo4kETD0fSC3G3rJlpjdW+iT18jdprzJ kbZJTLtVPIX5EX955/oJwaeU/v1S+g9IsxWEOSwdNJIkkEWlglRvUJCBnxBXyafPbLV+BWNELPMF nlg/YlfBzH3m39oN/7FZ26kTqkAUp+jejcOXrjBhJM1NkEpFNz9kMlTS2hb2Uu6NfmNId6D11lcD 5eZfImkyCFC7c4G0xmfp/E9zeIgOK65Pimp1SXnAvmSWRFoNipymHGdzIpjBUkiEjoJJVZuzvfAL zVLeOmEPdac6ZMuk4dpKTr8CPR9Vm+muYPlSRs98rY4pCO9nBh3s7uyYj/+ZG2lgBxrkfnMusIS7 phW8BpsdLlbTvbJ0fcG0EhkvsRC/QSTco4ZkiYM5p7Zdau8OTWt3b//g+YuXuc/OOM35UKblLfQ+ K9v1vZ2t57vosbbQqta2yxiNwemCTQfJr6+WdfNLFmbcgxyV/DUY9/nhTisbM1Tbk5ra9sfIuPvN gxfKuzsZ85ZSQGn7qFKsZk5UAQ0IRHn9dmj+ftIx2+m1RBSaSW+UdZzMHcKvGOpwaK6vr5u52Ue5 z4+kieKhtoLUgOQ2bmVHAv3m9KTtZbmDwUOqJyuBW7g1+7K7JXf2F594ZAKDkMpwFjEMZI6CRb6D 7T22tIzJgQmHweVVygGsaD2IS3S2nrsGoSHEKgR+KTHg3mH5xYmnlVtfRkSZ+7LunHPdc3cPdp4V 7NhfyhPEnDwAnHEAyARWz76t8PG6aDqDqhZm7LJms4i5aRddhAAnLeFdko/N7jmAGInoCjB7NKus JKjaR9PzaW01D7IzbATqAQ5yGTEh42Lj0rFUSx4VFcJBtHElgTLf2L9jm+vHmU+BvfsF9sqySWlB MJ/O7uSBJ0pr/5Sg0xEyAgj/zzYTb9d+vv39ZFhp+oJhxPSzM2mATtKeUCyMOGVFFWJ2SL65qq2u RAVf7sAm+/XPzQeSoMUreiLpx07S96CoCvR83GypH1XS0s965k3XBrEh+LWXVQDDbLK9WbWJFfFO 0tUPSA4B+iPYHQ1gTCHUwsh5H2O1MJYL87YJNQn+1A9Q4oShehWzLMVuW/YaT3zz+PlmUqL24GRY jfM0/FiK8+ZbOlIIQwwZPBULoHC1i0/E/diJW1LljTT67IcNGxFBFjAJOKUQ4hKIftdDpoPK1Pw4 4WmkiwrRCtR7B5VZEMrSVlmKPwgvBwPknXP8E1Olbd1Z7KfjONSWO7E/AmwX24cS1pPz47O3v5xk zjDLWENprtOPoyEjU1r8Kldr0fAmWxHa7hg98wVNshmN0xmvRddXUGBp+7XwcKktochY4q7UT5jU PXDGTkxLpqIKHPwauOAKCihtvyNsrD+OYbOhCMM1xwWX8T3JbIyg2TEXrOOgqQewBC+3YbRsNIWN M6EV9IDfBsoOzhL+fv9dBzfJppNDpnU/o30cYBW8uXeB6lE+KWR3XkAtUjzEA7r4T/A1/hBM8VBe V9WXrx/3PAW35kQ/ij2GyVyVZRBv/cih7sL0TmavJBYrFbW9gS3gmfPXp9p1I+tkr0SCbh3akCer S38o+cR11I+onmTM/WRMCTqqRPqVkr4nGGUcxT+IOgboh7neBJMbB9T7TJON0G4cDdEFuxjKdMWD g5d7v7NNA8JBPY52g2Jnh5m/CeWWMnLT9q9Vvpy1jcvm7zEzxjVt7zZ3bHs7aUpOsD1/v/W/7bxU pLfddQ8V6XXOxwKLe+L9x+7qf4u4KjD6P6qUY2jh9ofTji1BkokEFxxkoK35mR1H7QmwzrwmGxJA 3Dysf/0z5LQXtJAk77MLQQWX+K5AmC9LUEz17WU+MchjZ5CyZFaecYo9gSPz9ugDFYdi9TlmQ9gh Gxkr3eEsIpyAi3A8vGCHtD6ZIVdcoi6yHyCaNB6gtrUCZgRcobUY6wYzHc3y2TrrBo7q7tY8KCkt m/IZnJnuvm9SVA5ORC3wfCBqNgPTGYP4N0Z6SVEoGwSypylqadjTlLSvvdTd4GQNZ1dkgjvAXfdY +CwNr5utnhyp+zlSpQmvPMu0P8bBZRDCDiJPCAmV9GhO44ilXvCjKt7oQ/RAhhZisG4sPeOxgPaO u8ivYMlQhlrPDXVm3nLEH/YEbZFFHmCIE9r/fQlQGW6r5xxycqplBEQDZ0v1x6GNnsBNRLjXossG ABrcNNmYgh1HMSid95J6P6mAxqhztjSV3YuHRO/0JmuFUv6C4nLpkTzL5AWKCp7sQxfctIuG2lRe ym5ju/0TYBcxN0hAXq29ff7uLtxXsb2DjUeDm964C7tdzhQnrmeMTcakanr7wGmMQfnZcU6V2fNb NoKPLrlo+vh1ob1fWXGQX/fqwiQCUq9ee+aYE9o8RYRndnHr1pj5Bd7MLq9WDCae8kJrXBlPsJYj jFSNUSfWxsEIkvCHgmXV6jzR8gil2wgWbkofsCRlqxME8aIYGUtkRCNMdPMI4RDGlnTnZs34G+c/ S5Dr5unaa0rXdsDU7DSPhmxQR2Nmc/ZUa8U6RMFq/p82pt9HCY6kCdAlTCwHcywWHRMleplYluS1 mm351PJrvunZ5r6umRgqNkg1bkANNbuv6xZRQ++zNLtjz5jZ1dWK1TC5t2ADC5a4MqMDfVWkjWvd 7TXPCiOU082e8fop8FFsIpzC2b1bDvGV8n3bvz3UcpbYhuOKhdHokcmOdbPLXTflCQJ3Ojgwu8iC I75fkKXU6RYrkocjwVJn3rYZpAJvula7ls9oZSWfESOfaD6PwF0vSLpjgNTV5DS2+GeTUTk07MZM tE1c0u8DFgpnCCG5BElj1zkSMKYhmkZ+0UaSGr4sHZO9K1dM+yzqjtlr8tGGMPEOS4jNLcSjK7MB bkUK1UWeCuYosEDiAJy1e39Pe2KaQwlVcDjyZnPe7jO0rHI2QmbW4HEFMnIqQ1xrfgIU5Gak8+fK pjbcFGLCxQEPkW54HO6Ntgmu5UeWR0fYn7HlY/RWI5e+9pNuHGjjBRr//CzrHctGrejN+iFLtVsA psxOTgRfrlccIWtwifFFl2zywCR9HA2QlE+icdwFuByINbSsDfxYuKLUW86XOkj/zzLburX2aXYk s2srUDsrFAQK5EGyZqGFrc+KmKbk2cWu+4TJW7OrKjjb9W3hQstbGekB0rPQgta3XwghX7D0rzsY E25hJeXsotdNelZ2zy6sgPpWdrynEPcQ82JiLrSy9Z1zXufNLnXdp1uYJFjnydY+QQBKemibpbS3 pEBfCaXDR0vY3wqWsmdtNLGVCPa68NNron/5KnaKLjEW/KerlVXLDn4dUL9AY0RooyV+HYw2Ncuc vWWtQLHmRKJhfC6QkmoV2muzESPWWHsQSIvMOVnyq8/y6zpZo+4a7YHopBo3IGDhDTAfghDGL2ye RrcjqylnsWuPuMac0+ZUMYmVTkuuIL0C4d4BawRSTHBPjLZITAPM5iY6wzVm3xVj56xlQ6Jbz5t7 LzfAsvDAEkyuRl6as+qBzUIMZxKaYX8jSCvOHUkOZ4aUTGZOo0XnxubMQJL85/sbkrXL6n/lztly 9pvPN6rgPtN2q2ka1tTIu4kN7kjIYuEslYjDRI+ZaBBdAkOWNwTy33N1TDCxBEkGBFvqe0Q/uT/f f7eLR05cpwb2GLRhH4eNvAEWCkOF0LD9++/2muZoxuW0l4Z+l9PFcD2Qc40CL7ixfLIps1X33ysR f6Uc6JSDdpf/2ji7/IFjhg5B/DMaSvuUJjw/WongcBjbeWVndeJo4LNNpN9DA4g+58UL0lBiFBf4 F4BxnruHAqBzooCH7ZLb0nRymhYtXnLI4BaYFLBJMHU+oCGCKOpDwiBwMlVKZ1SDzoQ4Kmyng/5c ED1YoMKwNw+OkTzG1AQchvaBncIjVV7QEvMJ2r5giNCflcaUPZm9lHWLE3OJsjXBTGw70aG0nno6 ndn+hcXZHj2dBtgQMb+bhvBrA5hlGefWQMPXG/rUUOdqxqKw1XZIVd4pfUJpu3GuStbvUU94NHEh /oeB5EgqcGbattFyGSWM96K1HUcXqLYLoVUmE/Rk5lZwiZGVrLy4MT6GiN3IbJJnyQZes+vDvJER 7rzAnGEOF+629c42wNU2zQr/hTACw8fmGmP98ATb581a/ngrjDrRcX/wByZwYAnDGpgbFKSCCQ/J Ilgux2FCAcJKIVvYpVDEHp+9e2P6mMGV4imwU7S02L4Eb8MLKmzeE+Mszji6+QBe8iRkGA44BWIO bfs8/AQb0U1t1FLu0rziDqVIz6wsPtQR0qX2R0YgT6JbF1Hvhha+j3IG8IDnJATdW/4DDbhC+AzC btiXBNQKCZ+h5CVeJ4613NVarFvv/PAScy+dlZ74rLLS4kJY6i0Yxwu5kljSPfTwUtXeQutb1fkV S/9vH+rkNCHGSh2dDrK2wViJJljZZr2b2housITtSpXEhYA/fOxQIeaDzJMtAsFn5O50wNQUVVA4 CFIQAUF3PPCQ1/fTq6hnnpG+3+vPrwnwtGU7mTvY2tvYQG4e7jbNJ+lODpWMshEojIm2ICtO+KKk n/ERntrAGwn5lryFtUyr3OIDXrOP4ecIF4jHAbGzaWCXoLsGy+oBHI9RNyVIBdfgsYLeS9vauOOv detDieDtwoQYAYNCqT3wYA+5/XSeeRfz3GKg76Px5RX9uqEP35zWBs0WP0bbsvy84uGNulPSewjk lzdELvyKQymKxRRoQWzQjtQHvCiaXrXuqD/GnPz36dHZ0fuTzsmZ0H195dpCy1uVYmq7bpMLrWpt 6py8AjtcPG4kF7WGJYSMyoSPeQPxb8eCgGVQqTkAhGMC0rEeFMBeITXIxTgYSNWLDeWD6xg0IXI/ GkPCwyEB02I+LYJzdsJ3ZQNyncGKX8aXNQ9UiLCEVEtVq+DAeb6IWTNlQz0kVRWpyqBNFOozuBkR pyMk/MvJLRrJ2Tcl1SjNM5DcBQqopyarZHRBkU6D4j1pZ+sUJdJ+zMpDZzYHMBAwL0lhQbgJqpHd V1wsfqQRPReid0kuMUjEqXFW937z1YbwaKmXgQ+jqbSlvM9CsmJlEqzuWSRSyJ2Hv9B2rlH0al51 AdIsLSHn5JLeMhRj87k27oXsbMQmq7Cn0MbjRuxvjeDAGidziRyHqareMHsuBN0ghZTQcv/p7BNU BvuYTV8x8pBgMSPMI+KNER+CKLJRoulneGb/4IV59jZELXvQ0ztvGD+OcdvM3abkYhTJuiw5eTE3 D7b7Cqkno/PB6PapDwOXXVZDcpr6qogJ6WaV84y02e21FHnavDgyg9wgDL5HwOBcBkp1vRhZHt4x 99JV0l4uVrJGVVdsw1qXqMh2XU+0vn1N0hKXkvtPLyFzDIa+Fy4paLXGg2i7Pa+5fOP2S8sghgzR QSvCUbAkANakQNm0i7T8Rhjw9N3RP8XuZHDbGYx5joRxwtYivC+D4NLbg2KLAkt+q7bmGB+gBpuX Qa6wewiYHX+zZvoUG5qgY/IOIRwsTgwRyZVXDTQU84kkk3V65DnGGMurpsnocHs7Nxtyux/8+efA 3+5HkZSUsy9lbl4kxk+e+38cYg7k3v7Ur88VwlM4pheo98mgXrTl25r+JrNSuOOt53xCjH/r6BJb bEcuH8tsl+1Wc9dOpzTm3M2nZPBLOmi6+ZQucY7/zlnwaxhv9OLHm2Z2RvLOc45anV7mnS94/s3h 0FObsHvYenG422ruvdq/tRm+/3nrPL3hjnwA/GlqCagd2Hob9qPDcYwpWgBRzDk7b9wLopTNzBtT 33ebkiRx9+ed163dN5ipfJj4f/x88KK1+2OcAuyOkO6rvf3dnRevdlubhd/+xsO/ANP+zYe/ePnq 9RGebh/+/GA/e/ounrz/crf1am/q6QX0JZ//25kK4KE+QzDg9Gs0aRfFzBaQOomBxgStC9Ka+dm0 fs9oaHkMkZ85DNq8k14WYIjWgzPE9ILvZohXD84Qrw73dput/ZoyxN6rdTLEy30yRHkfcY4RbrV4 gmoWQJqorSzVTrxc+a2kRcFJNt8ERdYbSzIOcBXEa5ijsrrwb4JUEs8e8U3hOtz19VHnxN6SJWRS sOTutilPyOtYuQLfot3krsJQX/A2jODrGK0lmmz1ZTO06jCoB3DB+I7K1hduqHlpn7pYiT7r8H3o +LvMunOhxLhw6z3coHRSlsqrl4XspZW5162Dw72Dw53nC60K5LGefJ9KHjexY6G1rmwHjwCKik2r ZY3LmscrkFBoIgMB52Q3WzF5VwFnIxAvzC0JiOVGpPwVKf7VQlS0VorPVlhKgGGos4WwKQyJslSk FmR3KLHXGDH3hxl2+DZUH4v6xAJ1QgAWbXgnGhGnAyuRyoEfB134aEqB8LoQAw6SK/hEidpPiM9g 6dlmuCAEMFXBZ3+NCEG8XKBFm9/KRq1MFmFJRV201hMDKdae9IFDmOHZkDMNxTEQhzrZ2VMuWPuq tnPOCyy0xhUIjvbZyeu3ZyfHHZhIgp4znZOjs9cff/sAwwggBtpKiHUisAjWEhC6S1ZYxqoaY8gJ GNiONuexNVBsES3ErOUC+idxfCCkgW3b6RB4Cm/SGEyCfBxMNsDceaEA9kESzpwi3SCTjgiA9PlX k8tdxC/YTXhInILYyBZEKSlIxKqj0Y+6ZtSp/yikUUpaO6m2xoheMbk7JVIggAtYcwVkX7xM0XFI wDnpoqG0veYrdSVIjbb3RkWqr8FBZXxXF0k070g+RFpzIHgrZicaMm1ZEUYDyQRr7hVFEQ2Bulyj TCH2hwAf9XSQoWDaEAd5/KdWvEm1Yy80hxb5a8W5seLcM4gmhgla6NjfyExSFoq4HuRou09M6YWP 8BvEt716C5DWiIbe4894fOMAv//uAdixXFcnaOPf2Kwc0hhHwRLCSWHPrsT0nW1t8vZ2VjdCqx3K 2HShtW2CU+01jdQgXAzoIGx2O2YEnwXRmCVEanTA+sAjEROaGAD5Qldg+FMmQ9DARm2CIca4e4Bh 8JayUH4PCM60aUS1nqutKAGeyS17Eb4XIveOhdpKCpoBsnBdbVNQQ6BRebobpcuLQlQUR/Fn4/V6 sC+kgbt8Vx8kOgSIvosvfK2J5KmB6C+mwfqQHtyx0jABbK9FsUiaxxl0Ko6ymmzky9WkvUAkEIk4 eg12LhREDoo6NA44y4vrdhfD2SXVyYAyg+iaBQZwtVE6hJ8QSUXeMlv0Y7VqH42x1IFcmmMfZVXF 1z4krCvjBOWLHH0ybNEs/g2q33XqxDHgOhdx0IAo6nvDANggGUaxxOoT8y6KpOeuxQ198VT/2Ry6 zaWwgsz3hzgjXNb41DluuHwFJJfO5IJ2ZuZfSr3FPO4OImRs1QmmDoVSutFIGsKyrLr/4j9+O6pd f7QqvUlYAQ6RQZPYG+iRS4Kp4fLw8FoukHAKEU9tfEAXyf7NFhBYSRTaIvoqylDGq60xHvBoJGcD eAQcRIOgBhTZgm8ENDdPTj4DwGZ/D/0j3MnlmJEGMxxR2hzyfzmMT3XGm5OCPRokjH3jeaNc+sVi g7T54DN0n9/Q2AZA0x76m2KWA0CART15C4yK9QZMaVmffB2h6HkCnSZvAX+JppUobfyDg3wgpMfW eOsxTpkZHs7qLirQxK3Xk5C02G8mMAL0CQBAHEsGHDXQrrIU5hwoJdDRoJfeQKQje/n9d++/DVdS sFIrB31R/8dioPQfwEDlMVkLbdaqqKCtOe87cVULLXhtp5vb+2PtqrOFNqTAY9kCZML0tpPeqOA6 rawFlu1F/gTdXX4B8PDQFMC20muWQcTNvcvRdnbXhTZpVada7Hkax9l4433zD3Bz69WrF8ahCpi3 z97i0XoQj8ZegQoJYYloS1ng3LKk6lcPOPgl9P2Yo8EWlmp5wOi3pZrKkTx2RumqtX8LiXYH0C6j vrvUyJp5SJBPhyYcpT/v7Ww9391rtnaydT9xzYP5cYqLADrbpRHlIJyZNcVFAudncsIVfQli21VX wp1TXBzU/DlKQWxYU2oOwZONT+EgGAZAysFKpTXkHmnxa+RZbVn/Fwi3PA5hCQ9cgoUuhuIO8Nmx YKE3xHVHRJtQQ61SzGMZc9g/Lf5BygMt66R/ZUgrXgLHGVXkQshP3PzA3PxrB+O80GNBm4lOwwcK dSMbnYEKHITCtc94/PLXZRazN7lLA67R1D6XOhnxlP5mPgLcIW1ZbRK4otOt4wM2AR0epAEsoAwM YCM7sjeleDJtv393rlubBOhSh/+l7RBjhqXWCATVi70+ElghZHs2MoCwN9T/eANx3RtZX0/Gd9nq yM2wte0irDaY3N/qC3aOMA00sArhYrIUsXF7Ie/xEaQR3VN4olPtE6jeMMOC0D+soueNpN8g2+xi 4xsR4g0hB6vM3DL22X8L8UpXxzazutshM09CZeMR3HkF+kmHX2T/dJoaOQ4xAT5WmlCiCZiIZAVV N7XpF9wiHBpMWnbMYEo6CMcqaG3sVdJ9AiGbWY9+DUdx9ubY7D5vPWd3sgwXguRg8FUzSf/+tQmg yO+3NzF/mtTaeqK3rwpStG3jxzZRjv2W3Df0PXcWL+8p1enUEFSwSu+x27dpbVgTAHAtexgJYsEI krgc5bO3p+Y/UD4WpwCW725gFwG610fjE3dVCHqziUtn/bvEJ3YCJMOOq5arJoSFp/8gsecfcuQh T0F02kWeuX3Ir0p1Lt7y3O7lrrVVJ3frc2NnjsNy9CY2qo81Qkbf2oNiDzNE2b1E5CzRMugVJK78 /9ZDb92xzd0AcsGNENmeXI43lmXKS4a2nhjb+UOus+4PaKSKnrXxGAtgrBAbOIxQgyAThXjmoF6X 85aCK8meSfWTK1RWIif5wzVmi0zFyWECyMz+dMdgShYl8/ixkssIrYvkZUVaOCaY3z9UJpRbEUPC 5n2ufSTZMQ1d6Dc3zQTn98NpLtr4A4gFvWnG3auZdb0FckqEEw6ftyGQV/qv4Y3yjYK4Hbe/XHyk svFyL1kjt1aStrbBH95Z95aRXEBFWzsgPJUdtvkffo8N4uHaDyDhdQriDYaq6Js7UStrBOoQrRoG s1TDe8hyZI8Lvm2RBSJysTAwA8EsWNMOJasnPzjj8fbbt/ECP5BpMBRetVomePnOb9GP8fJqUtJy i3iL985wCai0gY+BLdA2KI4znJyhnMThzyyHMkYlvxCqUpQyq7DBvA9vLayd44gJpeIFY3/kE8eb ojAGR7Rl/ocVO6y77aIbV4Ao6O07vXEiuJHVw4OqbB5tRgV94IGPcWdbKY8NmJxyptVmHqLkRkAs ZTMixjNXSPAdd0v97lVIQkHSMPoMqaMNQMSmVEgJVbT3OTETRBpFynaSpO3/LwAAAAD//wMAUEsD BBQABgAIAAAAIQA7bTJLwQAAAEIBAAAjAAAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEueG1s LnJlbHOEj8GKwjAURfcD/kN4e5PWhQxDUzciuFXnA2L62gbbl5D3FP17sxxlwOXlcM/lNpv7PKkb Zg6RLNS6AoXkYxdosPB72i2/QbE46twUCS08kGHTLr6aA05OSonHkFgVC7GFUST9GMN+xNmxjgmp kD7m2UmJeTDJ+Ysb0Kyqam3yXwe0L0617yzkfVeDOj1SWf7sjn0fPG6jv85I8s+ESTmQYD6iSDnI Re3ygGJB63f2nmt9DgSmbczL8/YJAAD//wMAUEsDBBQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAA eGwvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvbSe2Gwd1itixm61NG8Ruhx5pmZZYU6JA 0kl9G9rjgAHDumGXAbvtMGwr0AK7dJ8mW4etA/oV9khKshjLS9IGG9bVh0Qif3z/3+MjdfXag4ih QyIk5XHbq12ueojEPh/TOGh7d4b9SxsekgrHY8x4TNrenEjv2tb7713FmyokEUGwPpabuO2FSiWb lYr0YRjLyzwhMcxNuIiwglcRVMYCHwHdiFXWqtVmJcI09lCMIyB7ezKhPkFDTdLbyoj3GLzGSuoB n4mBJk2cFQY7ntY0Qs5llwl0iFnbAz5jfjQkD5SHGJYKJtpe1fy8ytbVCt5MFzG1Ym1hXd/80nXp gvF0zfAUwShnWuvXW1d2cvoGwNQyrtfrdXu1nJ4BYN8HTa0sRZr1/katk9EsgOzjMu1utVGtu/gC /fUlmVudTqfRSmWxRA3IPtaX8BvVZn17zcEbkMU3lvD1zna323TwBmTxzSV8/0qrWXfxBhQyGk+X 0Nqh/X5KPYdMONsthW8AfKOawhcoiIY8ujSLCY/VqliL8H0u+gDQQIYVjZGaJ2SCfYjiLo5GgmLN AG8SXJixQ75cGtK8kPQFTVTb+zDBkBELeq+ef//q+VP06vmT44fPjh/+dPzo0fHDHy0tZ+EujoPi wpfffvbn1x+jP55+8/LxF+V4WcT/+sMnv/z8eTkQMmgh0Ysvn/z27MmLrz79/bvHJfBtgUdF+JBG RKJb5Agd8Ah0M4ZxJScjcb4VwxBTZwUOgXYJ6Z4KHeCtOWZluA5xjXdXQPEoA16f3XdkHYRipmgJ 5xth5AD3OGcdLkoNcEPzKlh4OIuDcuZiVsQdYHxYxruLY8e1vVkCVTMLSsf23ZA4Yu4zHCsckJgo pOf4lJAS7e5R6th1j/qCSz5R6B5FHUxLTTKkIyeQFot2aQR+mZfpDK52bLN3F3U4K9N6hxy6SEgI zEqEHxLmmPE6nikclZEc4ogVDX4Tq7BMyMFc+EVcTyrwdEAYR70xkbJszW0B+hacfgNDvSp1+x6b Ry5SKDoto3kTc15E7vBpN8RRUoYd0DgsYj+QUwhRjPa5KoPvcTdD9Dv4Accr3X2XEsfdpxeCOzRw RFoEiJ6ZiRJfXifcid/BnE0wMVUGSrpTqSMa/13ZZhTqtuXwrmy3vW3YxMqSZ/dEsV6F+w+W6B08 i/cJZMXyFvWuQr+r0N5bX6FX5fLF1+VFKYYqrRsS22ubzjta2XhPKGMDNWfkpjS9t4QNaNyHQb3O HDpJfhBLQnjUmQwMHFwgsFmDBFcfURUOQpxA317zNJFApqQDiRIu4bxohktpazz0/sqeNhv6HGIr h8Rqj4/t8Loezo4bORkjVWDOtBmjdU3grMzWr6REQbfXYVbTQp2ZW82IZoqiwy1XWZvYnMvB5Llq MJhbEzobBP0QWLkJx37NGs47mJGxtrv1UeYW44WLdJEM8ZikPtJ6L/uoZpyUxcqSIloPGwz67HiK 1QrcWprsG3A7i5OK7Oor2GXeexMvZRG88BJQO5mOLC4mJ4vRUdtrNdYaHvJx0vYmcFSGxygBr0vd TGIWwH2Tr4QN+1OT2WT5wputTDE3CWpw+2HtvqSwUwcSIdUOlqENDTOVhgCLNScr/1oDzHpRCpRU o7NJsb4BwfCvSQF2dF1LJhPiq6KzCyPadvY1LaV8pogYhOMjNGIzcYDB/TpUQZ8xlXDjYSqCfoHr OW1tM+UW5zTpipdiBmfHMUtCnJZbnaJZJlu4KUi5DOatIB7oViq7Ue78qpiUvyBVimH8P1NF7ydw BbE+1h7w4XZYYKQzpe1xoUIOVSgJqd8X0DiY2gHRAle8MA1BBXfU5r8gh/q/zTlLw6Q1nCTVAQ2Q oLAfqVAQsg9lyUTfKcRq6d5lSbKUkImogrgysWKPyCFhQ10Dm3pv91AIoW6qSVoGDO5k/LnvaQaN At3kFPPNqWT53mtz4J/ufGwyg1JuHTYNTWb/XMS8PVjsqna9WZ7tvUVF9MSizapnWQHMCltBK037 1xThnFutrVhLGq81MuHAi8saw2DeECVwkYT0H9j/qPCZ/eChN9QhP4DaiuD7hSYGYQNRfck2HkgX SDs4gsbJDtpg0qSsadPWSVst26wvuNPN+Z4wtpbsLP4+p7Hz5sxl5+TiRRo7tbBjazu20tTg2ZMp CkOT7CBjHGO+lBU/ZvHRfXD0Dnw2mDElTTDBpyqBoYcemDyA5LcczdKtvwAAAP//AwBQSwMEFAAG AAgAAAAhAKkRcketBAAAgh4AAA0AAAB4bC9zdHlsZXMueG1s1FlRj9o4EH4/6f5D5Hc2CRtYgghV WYpUqVdV2j2pr07igFUnzjlmD3rqf7+xk0CAhQTYdHd5gMTYM998M7Zn7NGHVcyMJyIyyhMP2TcW MkgS8JAmcw/9/TjrDJCRSZyEmPGEeGhNMvRh/Ocfo0yuGXlYECINEJFkHlpImQ5NMwsWJMbZDU9J Av9EXMRYwquYm1kqCA4zNShmZtey+maMaYJyCcM4aCIkxuLHMu0EPE6xpD5lVK61LGTEwfDzPOEC +wygrmwHB6Vs/XIgPqaB4BmP5A2IM3kU0YAconRN1wRJ41HEE5kZAV8m0kODomE8yn4aT5gBezYy x6OAMy4MCSQABt2S4JjkPe4xo76gqluEY8rWeXNXj1tgkQGbuahbR7VpLouxMQXLVKOpYORgtrpd 9c/vUFQ1Usx9D83gY8HnfQC4VTCDy6iWgv4gyivX+vsaEK+o26/a3tdEnh/rV9i+o//SuXaRfj3l MphzlLHNAtBTCwA0jEewEEkikhm8GMXz4zqF6Z/Amql4MvN+Nb3nAq/tbq/5gIwzGioU8/uqI/RU 9Is2moRkRUIP9fWKYlawNsW1r6aY9m53avXa1lWso7AtSapW3Y51Yzuu6w6cO8e6c3rdfldHwjnm am+AN30uQtj5ygXd7gKVedt4xEgkwXGCzhfqV/IUvn0uJewT41FI8ZwnmMGjWY4of9VI2DJhd/SQ XMDuVm4J+55QHQsNjfprLBpKo+4AuUTcqH9uXHPbYhLSZdyidTUK2ravZd+9M+tq4B7GZs2Atr1X o/6dz71zY7OGjUPvnVTQtu9OKv/9nqsh79x181zratRf77saBefaVyOu4r98X220ObUVcgBBE/iG oJR81PB4vd9PBuIprxcpD2RQAWHsQaU636NtGgUpwSoykmU8i+VnSDwhd1MVa/kISXLxmGdM+ct4 BKXxPIlJAhUwEZIGqqIO4JXkRe8qglyrqi/XXlEMieAlmo1VdAaEBpZ1kVG1bCPfwGnK1qpIUOcC jQw+V5sNxx2FNbva8reJTngv0+64z7pxx9gD9V+XsU/ETB8BKbUvDer50DqNqXTAPiX5+8cyCmtZ Mv4VOH0kKyhKdAViqgg95rAekFcEfg06mCn1TLWKVZH6HFawoa3gauDHflPtr8JNY3RXTftjUXSo /e1G0V1TP17F1LEYbqz9VaIIztqbzbBW0UE0lfP/trqVwcK1h+4lomzBBf0Jgirb/fEE4Njyegwy 4H9vkJ23C/nYpIL2PZaLHKfVMG2C5p8ll+SbIBFdHW6qL7XAgMe2+R5kSae42GZg53KjjhpPZRgV OnYA2TXeeQVEB2niS6VkJUe6ToDKoFKg7JQnmzLCUDdmHvqqElRW8Zy/pAzOm/O6QEndjACZ4Wpb 7Ojjb6nuG3UZtNECpIckwksmHzd/emj7/Jc+PIVgKXp9o09cahEe2j5/UafPtr5pgTzzSwbHxfBr LAX10H+fJnfu9NOs2xlYk0HHuSW9jtubTDs9534ync5cq2vd/wKb1OXsEK4/r7j81Je0kNzazjBj cEUqCmML8A/bNg9VXnL4+joDYAOLpRFmtrk8Hv8PAAD//wMAUEsDBBQABgAIAAAAIQA4Qfl4+RUA AJRsAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1slJ1bc9tIkoXfN2L/g0LvQxHg3WF7ogu3 7YjZiI3tmd1nWqZtRkuilqLb3fPrtwp5UJV5CmRj/CDbPAeJqg+ZhQQIke//+vvz091vh/Pb8fTy 4b6Yze/vDi+Pp8/Hl68f7v/x9/Yv2/u7t8v+5fP+6fRy+HD/x+Ht/q8f//3f3v84nX99+3Y4XO58 hJe3D/ffLpfXdw8Pb4/fDs/7t9np9fDilS+n8/P+4v97/vrw9no+7D/3Gz0/PZTz+frheX98uZcI 785TYpy+fDk+HurT4/fnw8tFgpwPT/uLH//bt+Pr2xDt+XFKuOf9+dfvr395PD2/+hCfjk/Hyx99 0Pu758d3P399OZ33n578vH8vlvvHIXb/nyz88/HxfHo7fbnMfLgHGWg+593D7sFH+vj+89HPIGC/ Ox++fLj/qXjX7db3Dx/f94D+53j48ab+fXfZf/rl8HR4vBw+++N0f3c5vf7t8OVSHZ6ewsb+uIUj 8ul0+jVs+rM3zf1O3vpNwk72j5fjbwexd8XCH9X/6/cb/u13+hD3qv89jKDtj+J/ne8+H77svz9d qtPT/x4/X759uN/dD6/99+nHfxyOX79d/PBWIeTj6clv73/ePR9Dbnmk+9/7v3/ItstZuV0Vq3W5 Cjn2R8DsTY/f3y6nZ4QvEEhClAjhR48Qq9l2tVqut5upIZYI4f8eQqz/1Rh+X/1M/N+IsdjNiuV8 +kTWiOD/Hkax+dcibBDB/40IZTnbFPPdYjIKX9lyQNaLbcLhD2g8FiEv5Cj22VHvL/uP78+nH3e+ VP2Renvdh8Iv3vlBhMNeFj7jHoP4U1C94g+Uf/3Nv/zbx2K7ev/wW4gIk4PJ7zua5tZSjViK3caa 6jHTdmFNzYipnK+tqYXJH9g4omK7tKYOJuUpl2X0PHg+EZJPWIa0XEVIQf1wvxY6MUAP0IlWikYT rrRYzghrLaqmSts34jCz3O3sAFrx+CMbSWytoxOHpxEd5SqNxXAIyw0li+IQ1IFDAikcRBMOJR2J SouLGW1ai6o5FJwUYtEg/FnJTrMVjwZR0Dg6sRgSy7QrQ8IPh0n4gh3KJqgDiRRASIgmJBY0gkqL q9l8Z/5Qltdi9j/TgZsTvEY8lgyNqBXPtl+iQ9V38oLlkEZqOPjIzEFlRFAHDimAcBBNOKwLe7Aq LfLRrkXU815QTjdi8T8TmoLQtOLRCVEWNI5OPJbEldrw5wAmUcxTSgR5QJEiCArRgIIKuBrENJUl bV+LRQMpC/I04rFEKKFa8ahEkBfs9NNGJhE8x2z6q9C69FP8KcjD9FMEmb5oMv0NJWc1iGn6anHq t6/Foqe/IoiNWOzsaTVtxaNmLy/Y2aeNzOxDd00L4zpNPqjD5FMAmbxoMvmiIDSVUdczglOLrGfO Z7lGLGbmJeVGKx41c3nBzjyVmJl56DOuzzyow8xTAJm5aNdmbtT1bD3Xf6hMazEbDjTHRiyWA9Fu xaM4yAuWQ0otwyF07gxCrYS9PJBIIYQERKAoaViVldczzpIaBj3/HS23DTwWACVjC5MigFcMglU6 tVoE3sUIim0qgyLoA4MiBQEEUQcINLQKG0P2EHa3EgJuQ4QiNvBYIpSkLUyaiIyz8GtjOrmsUkZa JKG5ovLQWSG9F1rHFANERJUpl3Mq/qoY5DSOoiRTDZMGUXD/1cBkSCzo+LQwaRIyAM9DgUgDsCBC b0UgVMPUX8jG1KAztYMKEJw5VZTTOIqSjnYNkwVBR7uByYKgw9LCpEGgcbQpkWZhSfghMAl1riiC HEkkmkgJUQcSaRe9XGFjf1ziESkWZKphMiQWNMkGJkuCRtPCpEnI+KalhA/OIBZqtQhyBEHLmfO3 JoIKEFnXEGUFYkNzrGEyIDZEq4HJgFhmtSGj0SDkFQsiTcJmRGizUm0MLVNYYfwUixTVDS/tYq9e 5S/V+UtN/lKLl8p5iGXHExqfNJ7+nkCxS61sIY0RVi060TqoviRiDi6yM5pEkKOXHRYRzWHZUjk3 2Is2lXMytTD5eHEoxZbG0sFkj1QyWTKhMSIyejmXvglgUgzUrqiYNOVZ5Q+zSmh7OVRD1LMlak3c Xs+V1rcWJg2ExtHBYnEksBZH6I8IR+ETKmaw9E/gkYKAh6jXeGi1nNF060JkQ2RLfVUzZtpRvrYw aSa+t7AHoIMp1ExMpXKV8BosnkCGRWVJL8eFLcUQKlBBhVbcyqg5FciaCkVoRizFjlK1hUkzSWtX P84OFpsnaWcWiHdxnmggQY5A6CA6fzcyFQbfC6iMWs78bR/9h5K7hlvzKXaUWk0MmQ51saXD1MKk CRU72l0H0zRGoZmiWtKMpNeSUiopPV0p6rWk0eqfMxK3ZZQObH/0G+zQmrIskkiaERVfhzjTCI20 kKpxKqUJAyE6qA7qNUKyrah/TkjcdvJUH03c4c0skkiaEEHsEGcaIT8kziHVUZVBHuqspGR1UEGI Fusqqmo6xLiGR3OhYm5GwpTzrLZknH6Fj2st9/wdAk3DEnoxKi117dG/bRWxUKY7qEgNOsqVUfNb 15A1kWJH021ijDTdESbST+pM4RuaHQJZJukI2CV5vOcspedEEdFsHVSwoEytjOrfE7Sn0BqyYUHL QRNDJBQjS6+M0aCgsXQIZFGkQ2tR+Ei30iPIMT1oxK4UVZDwNXNl1OWMiqqGrJGU6XhhpR12kJCU c6q8FoG8NVbMgnbWwTMNyUifqxcS3efy7SpX6k52kaD386mimoZa0FBreDSXIquaYS8qTn6WFpPm UhDgDjubxiV0nbSS6FOQNKWoHpqVK0VFqlBtVUb907d+4NaESkqKJkZMhEbWFRmUJsTdRYdAkwj5 LMkIqczp5VhMdEwdVBCiUquMusruhUM2SGgNamKIW0hgMkgoizt4DJJ16srM+rLwLk6aQr010uuR CaWng3qNSYg93AYZYSKyP3fEdaGcU+Y1cQ/aRPBbmAwUCtTBY6CsEjkLJfSGVEmq3V1I6yiVxMuq g3qNiWwr6mpGo6yxsckTmm0Td6CRULa2MBkkfB6CZxqS0AzeQCK9IpBQsbuFqEBCQ62MSutSDdEA IU8TA2gglKotTAYIjaSDZxoQPyQGom8vLII+FA7f5nRQkQbEqzJqMfdvJ5g/1LvArRFxUjYjnpLb 1hYmjYhvvXbwGETqDXJbRrdb24V0jciZVIr9qdhBBSFSK6N6QlkdSWzDJFtvxeMLUq0/WdqIyTCh wXQYjGWS9maZjLe2C93a8oMXDipY0HpQGdWzoPKooRsWxKuJMRKLvLeFybCgwXTwhPuWieo6EbMw vItrSF37LIIcS4j25KAKFLUH6eSMWuQXP9ANFDr2TYyhpjInUwuTni/fge/gMQly9dwTusIbC600 jSgaWtHdYug7w7NwazrIlVE9k3RUemY1dM1kSUtTE2PcZJJ3turhtX5nHQJNYzLS2erzse5s+dLC LXRnu6Ysqow6xkS21kxKvs/XxCAJykj1SCSdKGX+kJeYJlFZjnSzqt/v5Vg9dKpzUFE9lEeVUUeo QNdU1LNo/QFuYoxbUGDSUJaUth0805h4143qWQY5MqFSdlDBhIhVUU3zyZ51gsdwIbbNmIeW7BYe nwxxEV3SeDp4DBZV8mahXY40tP4qYXgrpJcHLLx6OaiChd+nrKKqhkpga3j8qTRORz2mgXQZGuPk yWsIgTQX9XCDLCzwGC7XFtvlSFerueiulpdC1288XN7kXIaeN81nmXERj06XVeobwCWPM8JFTLqM 1JTBRTzTuPgh3SqjIMd8oRG7pajIFzrJVFFNXLJn5uAx+UKrQjMSZ4SLDMXkC9Vjh0DTuIRukE7O Ol+kWZSTMy+Izp+xArVrXAb1Fhfx+EmlOqKlo4l7SZ4RLhLI5EtaX+zSYRtWvN++mYX7ufJbFPEX MtJ6ortZXs/dUlRw4BNyVNP48/yQCJpDmd2DQyBrogpsYUpPMXR4xb6ZqtoGC8cTvJUPQY51QjN1 S1GFwzbdn+nLtYpq4qCus3pPDY+e4pqqsRmJM5IPMhT/MyaWumGE9UM80+rkdhO71E3skgrSQQWX bP3QLa5vTWjrGlsbJhSjiXtI0x1hkjex6vQKJuKxTNKIbK6E1o7WDv0M9jLoMVmorB1UQKHFsDLq GBSJraGUfCe1QRBrov6/hclkCiV2B4+lko6BoeJvNWZUVBPbyxFKWqJ6/A4qoCTuvVpFNR3lNXlq ePSc14S+GYmTZwtMmkvJ72J2ME0D412cLtvNzF8eX112V2GTCIuWOgdVYPEzJJVRfQbR1jV0A4oO RzPiKfmZzxYmteLiFUslHSibLiONrLoSXEkTKSdgbjEdVBBICYl0GRrQ/vfIqMJqbGvmT4yaGD8l 3EiiyG50omxo7e8QyBJJ47VEQltHy4ouIOn6QISq2a1EBRE6nlVU03y4za3h0VyypxRH4oxwkaEY LmnKstwi0DQufki3uAR5qBVuut1KVOFSZA83R1mByRJGQvif8ZS6oYWyGYkzAkYCGTCpOgBGPNPA hN6PEmaXrgVX0hoiYegIOKhXwcjGkFfZbw1icwMlW24lhvaU/FB4i0AGCqVvB880KCNdrl5XdEO7 okPtVrqhLfgtrCrKKhNo6ajh0ZPmjrAZiTOSLTIWDWZLVd8h0DQwPhJniwYT5FhGlN9uJeqQLSRX VqacrqEaJNzcjnkoZVt49AlHhmXmrzoDu7yGDo+qRS+v0gCiWmgKbiUq5s9v7ldW9r8hTm/sQDcE aBdNjJGSayQpZBx+2nEt4meWOwQyUNQ9BAtlpJXVUHQnu6L6ditRAYUru7Ky/1UaOp41DIYKkWti kDThESoyEEOF6rJDoElUPIEsVfQ7gr0ea4WG7KAOWLhWrOyx0CJUw6CxcJPXxCC3sMCksfBTqB08 07B4F1eQumeyDnKkQvwd1IEKZX9l5UDl1hulcBtEvKLEiDcRyZgNIkrTDoGmIRrpajUi3dXydblb m76VH3iqrOwRbW49gwy3QUSp2MSINxHlbS4/yN0h0DREI22uRqTbXL5P4ta6zS34zfHKyusZX7PU MBgqVL9NDHKTSt7k8mcidAg0jYofkqqt4X7+Orw81BTfEXJQUVPZM3BW9jRopjUMmkbBH2jQxCg3 ccg4dR0V/Phgh0jTeIz0tqpbWevelt8ydlAHLtlaY3pb/+vOtHTU2N5yIVMTd3KTi+zKcskWGDFN 4zLS3qqef63bW77J5aCCC9/Oray8nvF97xoGy4VOX02MkriU2XvtMFkutDx1ME3j4kOp+ulvbutV JcixjmhHbi3qwCXLFyN7LrR9je0tF4rSxJ0kLnknA5PfYezvCv59sw6maVxud71r3fWqzrm/GHVQ By50Sq+s7LlQg1jDYLnQItTEKGrK2RO2MFkuNJ4OpmlcRhpfnS+68eX7iG5tGl9+M7CysudCU65h MFz4Ga4mRrnJJe98S362u0OkSVw2I62v7xGH81EvxzqieTmoyBd1zSH35ay8nvHNmhoGy4WueZsY 5RYXmEy+ZL/IANM0Lt7F64t6wGkT5MiFEtNBHbjQ8lFZeYyLRLdc6CzSxCg3uUgky4VW8A6RvDUu QqU6mOYCcnO74e3lgQvfHXVQBy60YlZWHuMiranlQnSbGEXNJjsfwWS50Hg6mKZxud3lbnSXy7di HVRw4eWninKaUZH9cgNMlg0VbDMWKVt7YbJsKMU7mKax8YPiWlK93SbIMWeo7XJQr7KRjX1ixNz1 V+50OwYxDJvs9xrijlSknI3szrDJ3ixCpGlsQi+Y7lLFdVdaRLk7xR9D4MJbSZ6YMMl++aKycpm9 0Qrd4sjKaNjHTRxisjiyMhLTNBwj7a5OFd3ubmgdcxtRgYWX/yrKakZ87qxhMmz4srOByc8rJl3J FxUtTOruJV6ZBsIzVXnB/e0myLFm6Ng5qFdByMamZvjJ5RoxLIjsHDQSKa8ZMfmfkVaxoCF32N00 NrbHjTWje9sNZaHbiDowoZlUVva/Ak+GGgbLg3bSxChqqjkPGYnlQa10h0jTeIz0trpodG+7oR25 je5ty+wmVJTVjPh5uhomyyY79ww7UpFyNmKybLJzj5gmsfGfE5XVkf7wqF6PhURjdlCRNBmcKKsp 8UOYNUwaTsnV1sBkVxSqkRYmtaLglWkkvItXFHUnYRvkCIKQO6gDCJKrKN8EIXuwILiCEMmCoJxt YdIgJLb/GdeYqy3sdqSF1Z9D0+sDCX4vz0G9SkJaVLO25ikhJj3Jgh+zb7AjbSr5AylbmDQJiT2N xEjTqlNCN638XqTbigoQ2c3IKKcjUmQ3mGDSKVHwbaoGJguCMrCFSYOQ8RkQ6orEXNWEDzjm2lB3 B3o5ZgR3qFAHEJTRVZQ1CCrtGiYLgiI1Y5GyFRQms4LyjZoOJsNGXXZYNh78LTZBjmzorOm2ooIN nziqKGs2tAjXMFk2dPybsUg5GxmNYcM3JTpEMmyuXQ1vR9pVnTe6XeWP0HT9xrGLV5/6I3dPoqzY 8INRNUyGDT9X34xFytnIWC0bOpwdIk1j40Pdypsgx7yhenBbUZE3/M5ZFeWbbCSGZUPXDM1YpJyN RPI/49ml4EebO0SaxsZ2sNzdb3Uny58s5qAObAhdFWU9WFpKapgsGzrNNmORcjYj3SzncodI09iE 7i5dEWdspPmTK2N+FsJtRb3KZpA1G1pKasQwbPiNySbuSEXK2cjuTN5wLneINImNPzlnbFSn38ux pmgddVAHNpQSVZTVjPidthomy4ZOiM1YpIwNTJYNVWcHk2GzTvMy56mdd3HeqDu2vRzZ0DF3UAc2 VAlVlDUbKrwaJsuGKDdjkXI2YSof7i0bGlOHSIbNtfPULjSFqaaGK+b+5YEJP3PioIIJ37SsoqyZ pGPTn8RqmCwTgt+MRcqZSF9rmKh2rt9dh0iGydV8GWl+1bl7p5tffozGQQWbLVVAFWXFhu/i1TAZ NnxPqxkxldxGtTBZNpSeHUyWTToUtpb8oFS+8Bq8C3LMG5q8gzqwoQqooqzZkKmGybKhCmjGIuV5 I2O1bChNO0QybK7W0u1+2H+gqWJDDZSDOrChGVVRvslG9mDZpAPZV0IzFilnI5H8WSr1NXzB2yHS NDaj/XD/qw+Xb8fHX93J7yh9DYz/QiPFihZ/B9V/VHh4rr/k0VdJV8Pn+3714NLjL/hitoHLrzGK BGVJO4SyLkr/8C1NYVJ6f/mtCPk+JfnGnOfD+Wv/zUtvd4+n7y8gFF8dvv9p/S58tm74UN0o+e9P ev3mv3frcnz0X7705fRyCV/sFPb8x6v/tqSXU3V6wZd3hQ1f918P/7k/fz2+vN09+S+H8t8BNfN1 cZZvZer/7b82qn/VJ8an08V/0dLwv2/+q7kO/ks85jO/Ln45nS7DfxD3l8Pl++vd6/71cP7l+E+/ c59Up/PRfwlX/91bH+5fT+fLeX+8+O8C8q//0491/1S/Hv31z9w3NX6UfhL6lfO7o5/L+efP/Xc8 PcTvE/v4/wIAAAD//wMAUEsDBBQABgAIAAAAIQB0RMwoiQEAABEDAAAQAAgBZG9jUHJvcHMvYXBw LnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySQW/bMAyF7wP2HwzdGzlt MQyBrGJIO/SwYQGStmdNpmOhsiSIrJHs14+2kcbZdtqN5Ht4+kRJ3R06X/SQ0cVQieWiFAUEG2sX 9pV42n29+iwKJBNq42OAShwBxZ3++EFtckyQyQEWHBGwEi1RWkmJtoXO4ILlwEoTc2eI27yXsWmc hfto3zoIJK/L8pOEA0Goob5K74FiSlz19L+hdbQDHz7vjomBtfqSknfWEN9Sf3c2R4wNFQ8HC17J uaiYbgv2LTs66lLJeau21nhYc7BujEdQ8jxQj2CGpW2My6hVT6seLMVcoPvFa7sWxU+DMOBUojfZ mUCMNdimZqx9Qsr6JeZXbAEIlWTDNBzLuXdeu1u9HA1cXBqHgAmEhUvEnSMP+KPZmEz/IF7OiUeG iXfC2Q5805lzvvHKfNIf2evYJROOLLxX31x4xae0i/eG4LTOy6HatiZDzS9w0s8D9cibzH4IWbcm 7KE+ef4Whsd/nn64Xt4uypuS33U2U/L8l/VvAAAA//8DAFBLAwQUAAYACAAAACEA2QgFp0EBAABR AgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAfJJfS8MwFMXfBb9DyXubZvPPFtoOVPbkQLCi+BaSuy7YpCGJdvv2pu1WOxg+3ntOfvfcS7LV XtXRD1gnG50jkqQoAs0bIXWVo7dyHS9Q5DzTgtWNhhwdwKFVcX2VcUN5Y+HFNgasl+CiQNKOcpOj nfeGYuz4DhRzSXDoIG4bq5gPpa2wYfyLVYBnaXqHFXgmmGe4A8ZmJKIjUvARab5t3QMEx1CDAu0d JgnBf14PVrmLD3pl4lTSH0zY6Rh3yhZ8EEf33snR2LZt0s77GCE/wR+b59d+1Vjq7lYcUJEJTrkF 5htbZHhahMPVzPlNuPFWgng4BP1CT/A+7gABEYUAdIh7Ut7nj0/lGhXdDeN0GZN5SQidEXpLPruR Z++7QENDHQf/SyQkTu9jclOmSzpbUDIlngBD7vNPUPwCAAD//wMAUEsDBBQABgAIAAAAIQDdolRM RgAAANwAAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmluYqAQMLIw sN0BmuH8v4GdkYGTYRa3CUcKAyMDP0MEExOQjmBiBso6MphQaA+ydkYoB0QzAbEIkPEfCJDVgNgA AAAA//8DAFBLAwQUAAYACAAAACEAR7wVrfUAAABsAQAAEwAIAWRvY1Byb3BzL2N1c3RvbS54bWwg ogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckMtugzAQRfeV+g+W946NEWmMDFEC ybqLtHvLGIKEH7IdWlT132uUPvZdztzRmTPD9+96ArPyYbSmgtmGQKCMtN1ohgq+XM5oB0GIwnRi skZVcFEB7uvHB/7srVM+jiqAhDChgtcYXYlxkFelRdik2KSkt16LmEo/YNv3o1StlTetTMSUkC2W txCtRu4XB++8co7/RXZWrnbh9bK4pFvzb/gCeh3HroIfbdG0bUEKRE+sQRnJjojl7AmRHSH0SJsz O5w+IXDrMIXACJ1OD/0khkSbYzm5txB9neVkSylhOeX4r8vxz76a41Xk/qb6CwAA//8DAFBLAQIt ABQABgAIAAAAIQB7ksghfAEAAIEFAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhABNevmUFAQAA3wIAAAsAAAAAAAAAAAAAAAAAtQMAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAIE+lJf0AAAAugIAABoAAAAAAAAAAAAAAAAA6wYAAHhsL19yZWxz L3dvcmtib29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGlYrBVTAQAAJQIAAA8AAAAAAAAAAAAA AAAAHwkAAHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQAnzwEaFTkAAISJAQAUAAAAAAAA AAAAAAAAAJ8KAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAAIQA7bTJLwQAAAEIB AAAjAAAAAAAAAAAAAAAAAOZDAAB4bC93b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc1BL AQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAAAOhEAAB4bC90aGVtZS90aGVt ZTEueG1sUEsBAi0AFAAGAAgAAAAhAKkRcketBAAAgh4AAA0AAAAAAAAAAAAAAAAArUsAAHhsL3N0 eWxlcy54bWxQSwECLQAUAAYACAAAACEAOEH5ePkVAACUbAAAGAAAAAAAAAAAAAAAAACFUAAAeGwv d29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhAHREzCiJAQAAEQMAABAAAAAAAAAA AAAAAAAAtGYAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEA2QgFp0EBAABRAgAAEQAA AAAAAAAAAAAAAABzaQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEA3aJUTEYAAADc AAAAJwAAAAAAAAAAAAAAAADrawAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEu YmluUEsBAi0AFAAGAAgAAAAhAEe8Fa31AAAAbAEAABMAAAAAAAAAAAAAAAAAdmwAAGRvY1Byb3Bz L2N1c3RvbS54bWxQSwUGAAAAAA0ADQBnAwAApG4AAAAA --_006_E84E7B8FF3F2314DA16E48EC89AB49F01CEE088FDAPHNISofficehd_-- From miguel.a.garcia@ericsson.com Mon Jul 18 05:39:18 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D96A21F8BA1 for ; Mon, 18 Jul 2011 05:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq60RkS6JxF5 for ; Mon, 18 Jul 2011 05:39:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 60B7A21F8B8D for ; Mon, 18 Jul 2011 05:39:17 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d3-4e2429746f95 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 58.A5.20773.479242E4; Mon, 18 Jul 2011 14:39:16 +0200 (CEST) Received: from [159.107.24.208] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 18 Jul 2011 14:39:16 +0200 Message-ID: <4E242972.7060007@ericsson.com> Date: Mon, 18 Jul 2011 14:39:14 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mmusic References: <4DF99E2B.6080202@ericsson.com> In-Reply-To: <4DF99E2B.6080202@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: Re: [MMUSIC] Unofficial WGLC for draft-salgueiro-mmusic-image-iana-registration-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 12:39:18 -0000 The 4-week unofficial WGLC period of this draft has ended. We will ask the author to proceed with the individual submission (AD-sponsored). /Miguel On 16/06/2011 8:09, Miguel A. Garcia wrote: > This is to start a 4-week unofficial WGLC of the IANA registration of the > image media type in SDP, > > http://datatracker.ietf.org/doc/draft-salgueiro-mmusic-image-iana-registration/ > > This document is going to proceed through the individually submitted, > AD-sponsored track. However, the draft came as a requirements of the > MMUSIC WG, has been substantially reviewed in MMUSIC, therefore the > chairs want to have a last review in the format of an unofficial WGLC. > > Please review the draft, and send comments to the authors and the list. > Even if you don't have comments because you are happy with the current > document, please say so. > > The deadline for receiving comments is July 14th. > > /Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From magnus.westerlund@ericsson.com Tue Jul 19 06:11:20 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0738221F855A for ; Tue, 19 Jul 2011 06:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ6D4peF-HSF for ; Tue, 19 Jul 2011 06:11:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A68A21F84DC for ; Tue, 19 Jul 2011 06:11:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-4c-4e25826df85d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 73.CE.09774.D62852E4; Tue, 19 Jul 2011 15:11:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 15:11:03 +0200 Message-ID: <4E258267.3070008@ericsson.com> Date: Tue, 19 Jul 2011 15:11:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20110718142840.23814.69863.idtracker@ietfa.amsl.com> In-Reply-To: <20110718142840.23814.69863.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 X-Forwarded-Message-Id: <20110718142840.23814.69863.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------070700000605010803050805" X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Fwd: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-westerlund-avtcore-multistream-and-simulcast-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:11:20 -0000 --------------070700000605010803050805 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit For your information Magnus Westerlund --------------070700000605010803050805 Content-Type: message/rfc822; name="IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-westerlund-avtcore-multistream-and-simulcast-00.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Sta"; filename*1="tement about IPR related to draft-westerlund-avtcore-multist"; filename*2="ream-and-simulcast-00.eml" Received: from mailgw7.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server id 8.3.137.0; Mon, 18 Jul 2011 16:28:57 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 50.D6.25859.823442E4; Mon, 18 Jul 2011 16:28:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCF21F8C44; Mon, 18 Jul 2011 07:28:45 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh41mPUGXuOB; Mon, 18 Jul 2011 07:28:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54021F8548; Mon, 18 Jul 2011 07:28:40 -0700 (PDT) From: IETF Secretariat To: Magnus Westerlund , Bo Burman CC: "housley@vigilsec.com" , "ipr-announce@ietf.org" Date: Mon, 18 Jul 2011 16:28:40 +0200 Subject: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-westerlund-avtcore-multistream-and-simulcast-00 Thread-Topic: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-westerlund-avtcore-multistream-and-simulcast-00 Thread-Index: AcxFVwdGM+uPOAAyQoKoTt7geqjnxA== Message-ID: <20110718142840.23814.69863.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0184.eemea.ericsson.se X-MS-Has-Attach: X-MS-TNEF-Correlator: x-auditid: c1b4fb30-b7ba2ae000006503-83-4e244328171e x-brightmail-tracker: AAAAAA== x-virus-scanned: amavisd-new at amsl.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 DQpEZWFyIE1hZ251cyBXZXN0ZXJsdW5kLCBCbyBCdXJtYW46DQoNCiBBbiBJUFIgZGlzY2xvc3Vy ZSB0aGF0IHBlcnRhaW5zIHRvIHlvdXIgSW50ZXJuZXQtRHJhZnQgZW50aXRsZWQgIlJUUCBNdWx0 aXBsZQ0KU3RyZWFtIFNlc3Npb25zIGFuZCBTaW11bGNhc3QiIChkcmFmdC13ZXN0ZXJsdW5kLWF2 dGNvcmUtbXVsdGlzdHJlYW0tYW5kLQ0Kc2ltdWxjYXN0KSB3YXMgc3VibWl0dGVkIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IG9uIDIwMTEtMDctMTggYW5kIGhhcyBiZWVuDQpwb3N0ZWQgb24gdGhl ICJJRVRGIFBhZ2Ugb2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBEaXNjbG9zdXJlcyIN CihodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xNTkyLykuIFRoZSB0aXRsZSBvZiB0 aGUgSVBSIGRpc2Nsb3N1cmUgaXMNCiJUZWxlZm9uYWt0aWVib2xhZ2V0IExNIEVyaWNzc29uIChw dWJsKSdzIFN0YXRlbWVudCBhYm91dCBJUFIgcmVsYXRlZCB0byBkcmFmdC0NCndlc3Rlcmx1bmQt YXZ0Y29yZS1tdWx0aXN0cmVhbS1hbmQtc2ltdWxjYXN0LTAwLiIiKTsNCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K --------------070700000605010803050805-- From wwwrun@rfc-editor.org Tue Jul 19 16:48:18 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A8611E80A3; Tue, 19 Jul 2011 16:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36oFDELUn1MX; Tue, 19 Jul 2011 16:48:17 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id F3D6B11E80A2; Tue, 19 Jul 2011 16:48:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E022A98C520; Tue, 19 Jul 2011 16:48:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110719234816.E022A98C520@rfc-editor.org> Date: Tue, 19 Jul 2011 16:48:16 -0700 (PDT) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 6336 on IANA Registry for Interactive Connectivity Establishment (ICE) Options X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 23:48:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6336 Title: IANA Registry for Interactive Connectivity Establishment (ICE) Options Author: M. Westerlund, C. Perkins Status: Standards Track Stream: IETF Date: July 2011 Mailbox: magnus.westerlund@ericsson.com, csp@csperkins.org Pages: 5 Characters: 8228 Updates: RFC5245 I-D Tag: draft-ietf-mmusic-ice-options-registry-02.txt URL: http://www.rfc-editor.org/rfc/rfc6336.txt It has been identified that "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245. [STANDARDS-TRACK] This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From fluffy@cisco.com Wed Jul 20 07:36:10 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2AE21F8541; Wed, 20 Jul 2011 07:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.886 X-Spam-Level: X-Spam-Status: No, score=-103.886 tagged_above=-999 required=5 tests=[AWL=-1.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61pykWuW9q07; Wed, 20 Jul 2011 07:36:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D369021F8888; Wed, 20 Jul 2011 07:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=420; q=dns/txt; s=iport; t=1311172566; x=1312382166; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=6Hktg16DgUdtBhLfKYXzFrIjSI+pUtjgjLNGUrEMljQ=; b=iBNhE0Y79PhUyN7n4cwjqr+K8PeCpjfKKLqxLrdTwLrOEs6GN04K/bZ/ H4nSXkPBbzVRUkfkCuzbNpErJMiVLLBzQOikpVHi/LKDhgEizs19PMf/W enuhYRLPpZsyD2m4M24FW+adapIgezM51x7I76yHijkBrvzkjyYeqys7c 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPjmJk6rRDoI/2dsb2JhbABTp2N3qnKeLoVeXwSHVYsZhQeLdg X-IronPort-AV: E=Sophos;i="4.67,235,1309737600"; d="scan'208";a="4737235" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 20 Jul 2011 14:36:05 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6KEa4Ye011316; Wed, 20 Jul 2011 14:36:04 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 07:36:04 -0700 Message-Id: To: IETF AVT WG , IETF MMUSIC WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [MMUSIC] Comment on draft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:36:10 -0000 In the case were we want to use SDP to indicate video streams are = simulcast of the same thing, I think it would be better to use the SDP = grouping framework instead of using SSRC to indicate this.=20 I also wonder, why not just use layered codecs, seems like outperform = the simulcast approach. I read section 3.1 but don't really find it = convincing that this simulcast is better than layered codecs.=20 From abegen@cisco.com Wed Jul 20 07:44:59 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6FC21F8777; Wed, 20 Jul 2011 07:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j81yzqnSAHw7; Wed, 20 Jul 2011 07:44:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A3CEB21F86D7; Wed, 20 Jul 2011 07:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1077; q=dns/txt; s=iport; t=1311173095; x=1312382695; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Szw8D/gPJd5z6/GcWqtPdutyLROmod2ZsmhfIg4rDc8=; b=jO7DZkI0dQ+RVRAo0VWfRZAOe1/KzvskzalutJK9tcfpGvCsHyqPimL4 4Gj3olXKM4spMR9AuXxqOUvQDAYnqui5wli01jNfF6sqlyt3pDuIccZmu KodNHFE1Vg2fXCH1DwLEkKf1TfGpGH5NgGpCajYA3AI4Kh4y18BEVltON w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8AAFjpJk6rRDoG/2dsb2JhbABTmBiPS3eIfKFgni6FXl8Eh1WQKYtt X-IronPort-AV: E=Sophos;i="4.67,235,1309737600"; d="scan'208";a="4743843" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2011 14:44:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6KEiriP008425; Wed, 20 Jul 2011 14:44:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 07:44:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 07:43:47 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F81022F@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Comment ondraft-westerlund-avtcore-multistream-and-simulcast Thread-Index: AcxG6mXqnDbDBtWaTPi+OMmdczGS3AAAOBCg References: From: "Ali C. Begen (abegen)" To: "Cullen Jennings (fluffy)" , "IETF AVT WG" , "IETF MMUSIC WG" X-OriginalArrivalTime: 20 Jul 2011 14:44:53.0984 (UTC) FILETIME=[964DC600:01CC46EB] Subject: Re: [MMUSIC] Comment ondraft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:44:59 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Cullen Jennings (fluffy) > Sent: Wednesday, July 20, 2011 4:36 PM > To: IETF AVT WG; IETF MMUSIC WG > Subject: [MMUSIC] Comment = ondraft-westerlund-avtcore-multistream-and-simulcast >=20 >=20 > In the case were we want to use SDP to indicate video streams are = simulcast of the same thing, I think it would be better to > use the SDP grouping framework instead of using SSRC to indicate this. As in: https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ = > I also wonder, why not just use layered codecs, seems like outperform = the simulcast approach. I read section 3.1 but don't > really find it convincing that this simulcast is better than layered = codecs. The draft above provides some motivation why people would wanna transmit = the same thing twice or more. =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From stewe@stewe.org Wed Jul 20 08:26:50 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07A421F85CA; Wed, 20 Jul 2011 08:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqaUo85LIsVX; Wed, 20 Jul 2011 08:26:49 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB621F85A7; Wed, 20 Jul 2011 08:26:46 -0700 (PDT) Received: from [172.20.140.16] (unverified [130.192.232.18]) by stewe.org (SurgeMail 3.9e) with ESMTP id 15323-1743317 for multiple; Wed, 20 Jul 2011 17:26:45 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 20 Jul 2011 08:26:38 -0700 From: Stephan Wenger To: Cullen Jennings , IETF AVT WG , IETF MMUSIC WG Message-ID: Thread-Topic: [AVTCORE] Comment on draft-westerlund-avtcore-multistream-and-simulcast In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393995204_1741896" X-Originating-IP: 130.192.232.18 X-Authenticated-User: stewe@stewe.org Subject: Re: [MMUSIC] [AVTCORE] Comment on draft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:26:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393995204_1741896 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 7.20.2011 07:36 , "Cullen Jennings" wrote: > > In the case were we want to use SDP to indicate video streams are simulcast of > the same thing, I think it would be better to use the SDP grouping framework > instead of using SSRC to indicate this. > > I also wonder, why not just use layered codecs, seems like outperform the > simulcast approach. I read section 3.1 but don't really find it convincing > that this simulcast is better than layered codecs. > I read the word "scalable" -- can't help to chip in... >From Magnus' draft, section 3.1, second-to-last paragraph characterizing scalable coding, with inline comments: > The scalable video encoding requires a more complex encoder compared > to non-scalable encoding. > This is true from an implementation complexity viewpoint. It is not necessarily true from a cycle viewpoint, at least not in the encoder. I would argue that, in most practical cases, highly optimized scalable and simulcast encoders require about the same number of cycles to code similar resolutions. Perhaps within a +/- 10% range. In the decoder, modern standards such as H.264 SVC allow for something called "single loop decoding", which keep the computational complexity at only marginally higher levels than for non-scalable decoding of the highest simulcasted solution. There are cases where layered decoding actually takes fewer cycles (at very high bitrates, where the overhead due to entropy decoding of the less efficient simulcasted stream outweighs the complexity through cross-layer prediction). > > Also, if the resolution difference is big, > the scalable codec may in fact be only marginally more bandwidth > efficient, between the encoding client and the mixer, than a > simulcast that sends the resolutions in separate streams, assuming > equivalent video quality. > This is correct, but it's only half of the story. One operation point for which most scalable codecs today are optimized is 2:1 spatial scalability, meaning that the base layer is half the resolution in both dimensions or 1/4 of the pixel count. Another one is (roughly) 1.5 scalability, with 720p to 1080p in mind. SVC works still reasonably well at 1:3, although this is not a common operation point. The second half of the story is that SVC (as well as previous layered coding standards) do allow for multilayer scalability. If you know how to implement this (it's not trivial), you get quite a bit of the gain, with the additional advantage of having intermediate operation points that you can use when video pictures are zoomed under user control. In either case, modern scalable video standards, well implemented, are always better than simulcast from a bandwidth viewpoint. And should be. That's information theory 101. > > At the same time, with scalable video > encoding, the transmission of all but the lowest resolution will > definitely consume more bandwidth from the mixer to the other > participants than a non-scalable encoding, again assuming equivalent > video quality. Again, this is correct. Once again, though, only part of the story. First, he overhead of scalable coding over non-scalable coding of the highest resolution has decreased to levels that may not quite be background noise, but not much higher either. You may wish to take a look at a document Alex Eleftheriadis and me wrote for rtcweb, http://tools.ietf.org/html/draft-wenger-rtcweb-layered-codec-00. It contains a reference to the characterization tests conducted by MPEG. Most tests performed in academia roughly mirror those results. Second, most of us sit behind highly asymmetric links, such as cable modem or DSL. In such environments, an overhead (even a large one) for the largest picture resolution is less penalizing than an overhead on the sending side. Sending bits are more expensive than receiving bits. What the draft has omitted are SVC's superior error resilience properties and congestion control options, when being used in an appropriately designed system environment. Some of that stems from temporal scalability (which modern non-scalable video coding standards include in an occasionally crippled form), but a lot more comes from spatial scalability. Alex and my draft cited above provides some input. Regards, Stephan > ___________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --B_3393995204_1741896 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
On 7.20.2011 07:36 , "Cullen= Jennings" <fluffy@cisco.com> wr= ote:


In the case were we want to use S= DP to indicate video streams are simulcast of the same thing, I think it wou= ld be better to use the SDP grouping framework instead of using SSRC to indi= cate this.

I also wonder, why not just use layered = codecs, seems like outperform the simulcast approach. I read section 3.1 but= don't really find it convincing that this simulcast is better than layered = codecs.


I read the word = "scalable" -- can't help to chip in...

From Magnus'= draft, section 3.1, second-to-last paragraph characterizing scalable coding= , with inline comments:

The scalable video encoding = requires a more complex encoder compared
to non-scalable encodi= ng. 

This is true from an impleme= ntation complexity viewpoint.  It is not necessarily true from a cycle = viewpoint, at least not in the encoder.  I would argue that, in most pr= actical cases, highly optimized scalable and simulcast encoders require abou= t the same number of cycles to code similar resolutions.  Perhaps withi= n a +/- 10% range.
In the decoder, modern standards such as H.264 = SVC allow for something called "single loop decoding", which keep the comput= ational complexity at only marginally higher levels than for non-scalable de= coding of the highest simulcasted solution.  There are cases where laye= red decoding actually takes fewer cycles (at very high bitrates, where the o= verhead due to entropy decoding of the less efficient simulcasted stream out= weighs the complexity through cross-layer prediction).

Also, i= f the resolution difference is big,
the scalable codec may in f= act be only marginally more bandwidth
efficient, between the en= coding client and the mixer, than a
simulcast that sends the re= solutions in separate streams, assuming
equivalent video qualit= y. 

This is correct, but it's onl= y half of the story.  One operation point for which most scalable codec= s today are optimized is 2:1 spatial scalability, meaning that the base laye= r is half the resolution in both dimensions or 1/4 of the pixel count.  = ;Another one is (roughly) 1.5 scalability, with 720p to 1080p in mind.  = ;SVC works still reasonably well at 1:3, although this is not a common opera= tion point.
The second half of the story is that SVC (as well as p= revious layered coding standards) do allow for multilayer scalability.  = ;If you know how to implement this (it's not trivial), you get quite a bit o= f the gain, with the additional advantage of having intermediate operation p= oints that you can use when video pictures are zoomed under user control.
In either case, modern scalable video standards, well implemented, a= re always better than simulcast from a bandwidth viewpoint.  And should= be.  That's information theory 101.


At th= e same time, with scalable video
encoding, the transmission of = all but the lowest resolution will
definitely consume more band= width from the mixer to the other
participants than a non-scala= ble encoding, again assuming equivalent
video quality.

Again, this is correct.  Once again, thou= gh, only part of the story.
First, he overhead of scalable coding = over non-scalable coding of the highest resolution has decreased to levels t= hat may not quite be background noise, but not much higher either.  You= may wish to take a look at a document Alex Eleftheriadis and me wrote for r= tcweb, http://tools.ietf.org/html/draft-wenger-rtcweb-layered-codec-00.=  It contains a reference to the characterization tests conducted by MP= EG.  Most tests performed in academia roughly mirror those results. &nb= sp;Second, most of us sit behind highly asymmetric links, such as cable mode= m or DSL.  In such environments, an overhead (even a large one) for the= largest picture resolution is less penalizing than an overhead on the sendi= ng side.  Sending bits are more expensive than receiving bits.

What the draft has omitted are SVC's superior error resilie= nce properties and congestion control options, when being used in an appropr= iately designed system environment.  Some of that stems from temporal s= calability (which modern non-scalable video coding standards include in an o= ccasionally crippled form), but a lot more comes from spatial scalability. &= nbsp;Alex and my draft cited above provides some input.

=
Regards,
Stephan
  

<= /div>



___________________________
Audio/= Video Transport Core Maintenance

--B_3393995204_1741896-- From magnus.westerlund@ericsson.com Thu Jul 21 02:24:48 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFDD21F8BAD; Thu, 21 Jul 2011 02:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m8z9XIzqsOa; Thu, 21 Jul 2011 02:24:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C036D21F8BA9; Thu, 21 Jul 2011 02:24:47 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e1-4e27f05e1da7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.DB.20773.E50F72E4; Thu, 21 Jul 2011 11:24:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 21 Jul 2011 11:24:45 +0200 Message-ID: <4E27F05C.9000503@ericsson.com> Date: Thu, 21 Jul 2011 11:24:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG , IETF MMUSIC WG Subject: Re: [MMUSIC] Comment on draft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 09:24:48 -0000 On 2011-07-20 16:36, Cullen Jennings wrote: > > In the case were we want to use SDP to indicate video streams are > simulcast of the same thing, I think it would be better to use the > SDP grouping framework instead of using SSRC to indicate this. Cullen, I recommend that you go read the draft again. We are proposing to use SDP grouping framework. We suggest that one defines two grouping semantics SCS and SCR. One for grouping media lines where one want to send different simulcast versions, another for indicating the willingness to receive simulcast over a group of media lines. This is to enable simulcast only in one direction and to ensure that we get offer/answer behavior. The grouping semantics is what is used to negotiate the actual usage of simulcast or not. We do have the SRCNAME but that is for actually indicating how different streams map to different sources. This becomes important when an end-point has more than one source of the same media type it want to simulcast, like for example multiple cameras in a telepresence room. The SRCNAME SDES item doesn't need to be in the SDP, it is only included in the examples to show that it is possible to have them to speed up acquisition of this information. > > I also wonder, why not just use layered codecs, seems like outperform > the simulcast approach. I read section 3.1 but don't really find it > convincing that this simulcast is better than layered codecs. Layered coding is less efficient to reach a particular quality level than a stream that is encoded for that particular level without any additional quality levels. This means that layered encoding is guaranteed to be less efficient in the leg from a central mixer to a receiver for selecting a given media quality. Layered encoding is however a bit more efficient in the leg from the media source to the mixer than simulcasting. The exact levels of gain varies with the target points, the number of qualities etc. We see that a clear use case for combining simulcast with codecs that has certain scalability features. For example using H.264/AVC or SVC to provide temporal scalability, but use simulcast for resolution changes. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stephen.botzko@gmail.com Thu Jul 21 04:12:46 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B450821F8AE9; Thu, 21 Jul 2011 04:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFD3vU7JVp4E; Thu, 21 Jul 2011 04:12:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A36F921F8AF1; Thu, 21 Jul 2011 04:12:45 -0700 (PDT) Received: by vxi40 with SMTP id 40so1003326vxi.31 for ; Thu, 21 Jul 2011 04:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gseKVESmGTl81sk35Qhy/Rz3Yv6gZJLarviHg5H+8pE=; b=nMT/BqFnxRiqOvWj5AvVlAot8CIt7A/WIFkAjl7EW19AOh9OcSgD+AAn/4ABFBQ96+ 9BHLbMfjAypriyAXLYQZuwty+hBqyhiRfKBGIsecnIhSB4deYSh6+/74gIXj8tf0HLiY 1Ih14PAYYAnoR/f+kNTtcvu+x4IgA5gENtfek= MIME-Version: 1.0 Received: by 10.52.117.234 with SMTP id kh10mr116575vdb.42.1311246764307; Thu, 21 Jul 2011 04:12:44 -0700 (PDT) Received: by 10.52.188.102 with HTTP; Thu, 21 Jul 2011 04:12:44 -0700 (PDT) In-Reply-To: <4E27F05C.9000503@ericsson.com> References: <4E27F05C.9000503@ericsson.com> Date: Thu, 21 Jul 2011 07:12:44 -0400 Message-ID: From: Stephen Botzko To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec548aa5799741904a8926dc6 Cc: Cullen Jennings , IETF AVT WG , IETF MMUSIC WG Subject: Re: [MMUSIC] [AVTCORE] Comment on draft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 11:12:46 -0000 --bcaec548aa5799741904a8926dc6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line Stephen Botzko On Thu, Jul 21, 2011 at 5:24 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2011-07-20 16:36, Cullen Jennings wrote: > > > > In the case were we want to use SDP to indicate video streams are > > simulcast of the same thing, I think it would be better to use the > > SDP grouping framework instead of using SSRC to indicate this. > > Cullen, I recommend that you go read the draft again. > > We are proposing to use SDP grouping framework. We suggest that one > defines two grouping semantics SCS and SCR. One for grouping media lines > where one want to send different simulcast versions, another for > indicating the willingness to receive simulcast over a group of media > lines. > > This is to enable simulcast only in one direction and to ensure that we > get offer/answer behavior. The grouping semantics is what is used to > negotiate the actual usage of simulcast or not. > > We do have the SRCNAME but that is for actually indicating how different > streams map to different sources. This becomes important when an > end-point has more than one source of the same media type it want to > simulcast, like for example multiple cameras in a telepresence room. > > The SRCNAME SDES item doesn't need to be in the SDP, it is only included > in the examples to show that it is possible to have them to speed up > acquisition of this information. > > > > > I also wonder, why not just use layered codecs, seems like outperform > > the simulcast approach. I read section 3.1 but don't really find it > > convincing that this simulcast is better than layered codecs. > > Layered coding is less efficient to reach a particular quality level > than a stream that is encoded for that particular level without any > additional quality levels. > > This means that layered encoding is guaranteed to be less efficient in > the leg from a central mixer to a receiver for selecting a given media > quality. > > Layered encoding is however a bit more efficient in the leg from the > media source to the mixer than simulcasting. > > The exact levels of gain varies with the target points, the number of > qualities etc. > > We see that a clear use case for combining simulcast with codecs that > has certain scalability features. For example using H.264/AVC or SVC to > provide temporal scalability, but use simulcast for resolution changes. > > I agree that simulcast is important, including the case where two differe= nt codecs are used. In that scenario, the resolution might be the same. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --bcaec548aa5799741904a8926dc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line
Stephen Botzko

On Thu, Jul 21,= 2011 at 5:24 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
On 2011-07-20 16:36, Cull= en Jennings wrote:
>
> In the case were we want to use SDP to indicate video streams are
> simulcast of the same thing, I think it would be better to use the
> SDP grouping framework instead of using SSRC to indicate this.

Cullen, I recommend that you go read the draft again.

We are proposing to use SDP grouping framework. We suggest that one
defines two grouping semantics SCS and SCR. One for grouping media lines where one want to send different simulcast versions, another for
indicating the willingness to receive simulcast over a group of media
lines.

This is to enable simulcast only in one direction and to ensure that we
get offer/answer behavior. The grouping semantics is what is used to
negotiate the actual usage of simulcast or not.

We do have the SRCNAME but that is for actually indicating how different streams map to different sources. This becomes important when an
end-point has more than one source of the same media type it want to
simulcast, like for example multiple cameras in a telepresence room.

The SRCNAME SDES item doesn't need to be in the SDP, it is only include= d
in the examples to show that it is possible to have them to speed up
acquisition of this information.

>
> I also wonder, why not just use layered codecs, seems like outperform<= br> > the simulcast approach. I read section 3.1 but don't really find i= t
> convincing that this simulcast is better than layered codecs.

Layered coding is less efficient to reach a particular quality level<= br> than a stream that is encoded for that particular level without any
additional quality levels.

This means that layered encoding is guaranteed to be less efficient in
the leg from a central mixer to a receiver for selecting a given media
quality.

Layered encoding is however a bit more efficient in the leg from the
media source to the mixer than simulcasting.

The exact levels of gain varies with the target points, the number of
qualities etc.

We see that a clear use case for combining simulcast with codecs that
has certain scalability features. For example using H.264/AVC or SVC to
provide temporal scalability, but use simulcast for resolution changes.

I agree that simulcast is important, including the ca= se where two different codecs are used.=A0 In that scenario, the resolution= might be the same.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--bcaec548aa5799741904a8926dc6-- From magnus.westerlund@ericsson.com Sat Jul 23 03:58:32 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8B21F86EA; Sat, 23 Jul 2011 03:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.034 X-Spam-Level: X-Spam-Status: No, score=-106.034 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93msG5jGEt7v; Sat, 23 Jul 2011 03:58:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3026E21F86C0; Sat, 23 Jul 2011 03:58:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f1-4e2aa9552167 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 26.CA.20773.559AA2E4; Sat, 23 Jul 2011 12:58:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sat, 23 Jul 2011 12:58:28 +0200 Message-ID: <4E296F64.70500@ericsson.com> Date: Fri, 22 Jul 2011 14:39:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "mmusic (E-mail)" , IETF AVTCore WG X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 10:58:32 -0000 Hi, (Primarily as individual, but the WG home question is as WG chair) I have reviewed this draft and some comments on it. 1. If this solution proposal is to be taken forward I think it needs to be discussed in AVTCORE. The reason is that it has several RTP details that needs to be figured out to make stream duplication issue free in a general usage. I will take up a few of these issues in the below comments. 2. One aspect this document has is a relation to what is discussed in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream duplication both results in a certain form of multi-stream and also has a similar but slightly different semantics to simulcast in that the streams are two representations of a single original media source. In this case they are clones, but not true duplicates due to that RTP doesn't handle try duplicates well. 3. Another issue that also the authors has identified is the question of what one do when one has multiple media streams from the same end-point. And in a general case one can't use the CNAME to separate the sources. The reason is that two media sources that has a common timing (synchronization) context do needs to indicate that by having the same CNAME. Thus there are need for some additional mechanism to ensure that SSRC carrying RTP media streams that are duplicates of each other do in fact be labeled explicitly. I also note that a SDP based solution is not sufficient to resolve this issue. I think we need something in RTP, so that SSRC collisions can be handled. 4. In addition there is a few questions how this duplication really should set some RTP fields. Is the duplication only working on Sequence number level? There seem to be additional questions, for example in the need to have RTP timestamp considerations between the streams. They need to point identically into the joint timeline. Otherwise outages, or receiver taking synch from one and not the other stream can end up with different synchronizations. Becomes especially interesting to discuss when the time shifted transmission. 5. The draft also discussed Payload Type differences and have them in the SDP examples. I don't see how that is appropriate. If the streams are true encoding duplicates then they should use the same payload type configuration, and thus a single payload type should be sufficient and in fact recommended, unless the source encoding truly changes. 6. I think it is worth discussing also the benefits of SSRC multiplexed versus the session multiplexed. In multicast context there is clear benefits from a control and congestion perspective to have session multiplexed versions and these mapped onto different multicast groups enabling a receiver to choose one or both streams. 7. Thus I think the signalling aspects of this is the minor part. Although there clearly are some aspects of this needing discussion. For example clearer offer/answer rules for handling these. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Sun Jul 24 20:22:08 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01A11E807F; Sun, 24 Jul 2011 20:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.585 X-Spam-Level: X-Spam-Status: No, score=-4.585 tagged_above=-999 required=5 tests=[AWL=-2.586, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RBHQ+sznnYt; Sun, 24 Jul 2011 20:22:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 496A511E8078; Sun, 24 Jul 2011 20:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=7862; q=dns/txt; s=iport; t=1311564127; x=1312773727; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ovuLLBYjLZVxbSfuCK+cA4vYw4xSdaEklznv4xQA5j8=; b=GBHXSj/Uf9Zd7585qzO7RZF7+gvU5tzgBoEmpfHWVOd0YlmUNP58/h/4 wnTlZINtS+RH6am4UxR5PjWB1AhTFS1sBeV/9UNdW5NJfTTvIG7p7PhzK PdOCMtjBKMBnOEESYBkfjAf8NURpGCBpVdflDFyWGYIjheHgX5UIY85SA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAH/gLE6rRDoG/2dsb2JhbAA0AQEBAQIBAQEBCgcBIT0LDAcDAgIBCREEAQELBgYdAQYBEwwMIw4IAQEFARYMFAeXWo9Td4h8BKIKnTYCgyGCPV8Eh1WQK4tw X-IronPort-AV: E=Sophos;i="4.67,258,1309737600"; d="scan'208";a="5978726" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2011 03:22:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6P3M46Z007822; Mon, 25 Jul 2011 03:22:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Jul 2011 20:21:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2011 20:21:58 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E296F64.70500@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 Thread-Index: AcxJJ3tw784Q3ueDTSOxilOeoyOOUwBArfdg References: <4E296F64.70500@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "mmusic (E-mail)" , "IETF AVTCore WG" X-OriginalArrivalTime: 25 Jul 2011 03:21:59.0846 (UTC) FILETIME=[03E13C60:01CC4A7A] Subject: Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 03:22:08 -0000 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: Friday, July 22, 2011 8:39 AM > To: mmusic (E-mail); IETF AVTCore WG > Subject: [AVTCORE] Comments on = draft-begen-mmusic-redundancy-grouping-01 >=20 > Hi, >=20 > (Primarily as individual, but the WG home question is as WG chair) >=20 > I have reviewed this draft and some comments on it. Thanks for the review. =20 > 1. If this solution proposal is to be taken forward I think it needs = to > be discussed in AVTCORE. The reason is that it has several RTP details > that needs to be figured out to make stream duplication issue free in = a > general usage. I will take up a few of these issues in the below = comments. That is why we asked for a slot in avtcore on wed. =20 > 2. One aspect this document has is a relation to what is discussed in > draft-westerlund-avtcore-multistream-and-simulcast-00. Stream > duplication both results in a certain form of multi-stream and also = has > a similar but slightly different semantics to simulcast in that the > streams are two representations of a single original media source. In > this case they are clones, but not true duplicates due to that RTP > doesn't handle try duplicates well. The data carried in the redundant streams are identical but the rtp = header differs due to the different SSRCs. That is all. SSRC muxing = nicely fits the use case we are tackling with. Simulcasting is quite = different from our use case because in simulcasting different RTP = streams most likely carry different data. =20 > 3. Another issue that also the authors has identified is the question = of > what one do when one has multiple media streams from the same = end-point. >From the same end-point (e.g., source) there could of course of multiple = media streams. You can use SSRC muxing for example to identify your = streams and use ssrc-group to group them if needed. The concern in that editorial note was what if there were multiple = streams in each m line but what if you wanted grouping/association among = only a subset. For example, m=3Dvideo 30000 RTP/AVP 101 102 .... m=3Dvideo 30000 RTP/AVP 103 104 I can easily associate 101 and 102 if I want to, but what if 101 and 103 = were associated with each other. Can I use a=3Dgroup line? Probably not. = But, I don't know why you would need that kind of relation in the first = place (even if you need, there are probably less messy ways to express = them). If that had been a very desirable feature, SDP and grouping = semantics along with RTP would not have defined in their current form I = guess. > And in a general case one can't use the CNAME to separate the sources. > The reason is that two media sources that has a common timing > (synchronization) context do needs to indicate that by having the same > CNAME. Thus there are need for some additional mechanism to ensure = that If 101 and 103 are associated, why can't I use the same CNAME for those = streams? If 102 and 104 are associated/related, I would use a common = CNAME for them, too (but theirs would be separate from 101 and 103's). > SSRC carrying RTP media streams that are duplicates of each other do = in > fact be labeled explicitly. I also note that a SDP based solution is = not > sufficient to resolve this issue. I think we need something in RTP, so > that SSRC collisions can be handled. I can't say I am following. > 4. In addition there is a few questions how this duplication really > should set some RTP fields. Is the duplication only working on = Sequence That is the easiest way for a middle box or endpoint doing the stream = merging (duplicate suppression). If seqnums are different, what would = one do? look into the payload? > number level? There seem to be additional questions, for example in = the > need to have RTP timestamp considerations between the streams. They = need > to point identically into the joint timeline. Otherwise outages, or > receiver taking synch from one and not the other stream can end up = with > different synchronizations. Becomes especially interesting to discuss > when the time shifted transmission. The duplicate streams are coming from the same source, so they have the = same timestamp as well as seqnums. It has to be this way because the = node merging the streams will not re-write anything at all. It is a = simple suppression operation. Beauty of it is that things stay pretty = simple to use and implement without any changes to RTP/RTCP plane at = all. As for the time-shifted transmission, I suppose you are referring to the = temporal diversity/delayed duplication = (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, = timestamps are still the same for the reasons above. Changing the = timestamps for the delayed packets does not bring any benefit (actually = it complicates things) since the ultimate RTP application will still = receive one and only one RTP stream. > 5. The draft also discussed Payload Type differences and have them in > the SDP examples. I don't see how that is appropriate. If the streams When you are doing SSRC muxing, you put multiple streams in the same m = line and they end up having different PT numbers. What is wrong with = that? If they are in separate m lines, they could have the same PT = number. > are true encoding duplicates then they should use the same payload = type > configuration, and thus a single payload type should be sufficient and > in fact recommended, unless the source encoding truly changes. See above. > 6. I think it is worth discussing also the benefits of SSRC = multiplexed > versus the session multiplexed. In multicast context there is clear > benefits from a control and congestion perspective to have session > multiplexed versions and these mapped onto different multicast groups > enabling a receiver to choose one or both streams. This is what we have in section 5.2. Different streams can be sent in = different multicast sessions but it does not mean that they are separate = RTP sessions. I discussed this in detail with Colin. Thanks to him for = trying to teach me over and over what an RTP session actually means. =20 > 7. Thus I think the signalling aspects of this is the minor part. > Although there clearly are some aspects of this needing discussion. = For > example clearer offer/answer rules for handling these. We have some text around O/A stuff. But frankly, I don=92t see any use = case where duplication will be used in a unicast application. I mean if = redundancy is needed, one should use FEC instead for unicast transport. = Duplication is a nice use case for multicast transport where the bw = overhead is easier to justify and the implementation is easier. And one = would naturally implement this spec in networks where he already knows = that the network elements support this spec. So, maybe we should remove = the whole O/A text anyway and write that this will only be used = declaratively. -acbegen =20 > Cheers >=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 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From magnus.westerlund@ericsson.com Mon Jul 25 04:54:35 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7AC21F8515; Mon, 25 Jul 2011 04:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7UAA+ff780K; Mon, 25 Jul 2011 04:54:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B32EE21F8BC5; Mon, 25 Jul 2011 03:54:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-50-4e2d4b5fc872 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B4.15.20773.F5B4D2E4; Mon, 25 Jul 2011 12:54:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 25 Jul 2011 12:54:21 +0200 Message-ID: <4E2D4B52.80900@ericsson.com> Date: Mon, 25 Jul 2011 06:54:10 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4E296F64.70500@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , IETF AVTCore WG Subject: Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 11:54:35 -0000 On 2011-07-24 23:21, Ali C. Begen (abegen) wrote: > > >> -----Original Message----- From: avt-bounces@ietf.org >> [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: >> Friday, July 22, 2011 8:39 AM To: mmusic (E-mail); IETF AVTCore WG >> Subject: [AVTCORE] Comments on >> draft-begen-mmusic-redundancy-grouping-01 >> >> Hi, >> >> (Primarily as individual, but the WG home question is as WG chair) >> >> I have reviewed this draft and some comments on it. > > Thanks for the review. > >> 1. If this solution proposal is to be taken forward I think it >> needs to be discussed in AVTCORE. The reason is that it has several >> RTP details that needs to be figured out to make stream duplication >> issue free in a general usage. I will take up a few of these issues >> in the below comments. > > That is why we asked for a slot in avtcore on wed. > >> 2. One aspect this document has is a relation to what is discussed >> in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream >> duplication both results in a certain form of multi-stream and also >> has a similar but slightly different semantics to simulcast in that >> the streams are two representations of a single original media >> source. In this case they are clones, but not true duplicates due >> to that RTP doesn't handle try duplicates well. > > The data carried in the redundant streams are identical but the rtp > header differs due to the different SSRCs. That is all. SSRC muxing > nicely fits the use case we are tackling with. Simulcasting is quite > different from our use case because in simulcasting different RTP > streams most likely carry different data. I agree that the purpose for multiple RTP streams from the same original media source are different from the primary case I set out to solve. But as Jonathan Lennox pointed out, redundancy and FEC have very similar behaviors to simulcast with different encodings of the same original source. Thus, I do see a need to discuss for example how you identify the streams that are a duplicate of each other. > >> 3. Another issue that also the authors has identified is the >> question of what one do when one has multiple media streams from >> the same end-point. > >> From the same end-point (e.g., source) there could of course of >> multiple media streams. You can use SSRC muxing for example to >> identify your streams and use ssrc-group to group them if needed. > > The concern in that editorial note was what if there were multiple > streams in each m line but what if you wanted grouping/association > among only a subset. > > For example, > > m=video 30000 RTP/AVP 101 102 .... m=video 30000 RTP/AVP 103 104 > > I can easily associate 101 and 102 if I want to, but what if 101 and > 103 were associated with each other. Can I use a=group line? Probably > not. But, I don't know why you would need that kind of relation in > the first place (even if you need, there are probably less messy ways > to express them). If that had been a very desirable feature, SDP and > grouping semantics along with RTP would not have defined in their > current form I guess. Yes, that is a very valid question also for simulcast. And I think we can provide a story for doing that. But I don't think it should be based on using the RTP payload type to identify either of the versions. > >> And in a general case one can't use the CNAME to separate the >> sources. The reason is that two media sources that has a common >> timing (synchronization) context do needs to indicate that by >> having the same CNAME. Thus there are need for some additional >> mechanism to ensure that > > If 101 and 103 are associated, why can't I use the same CNAME for > those streams? If 102 and 104 are associated/related, I would use a > common CNAME for them, too (but theirs would be separate from 101 and > 103's). If SSRC A has a duplciation in SSRC C and SSRC B has a duplication in SSRC D and both A and B comes from the same end-point and have a common synchronization context, then all of A-D needs to have the same CNAME. And I get the impression that you are using a payload type based association scheme here. And I think that is a bad idea. For example it can't support particular many streams. It also looks semantically wrong, as if Stream A uses PT 96, then SSRC C should use PT 96 also for the corresponding packet duplicates. And if A switches from one PT to another the other stream needs to follow. Thus I think a SDES item based approach for indicating that it is in fact A and C that are duplicates, rather than A and B or A and D. > >> SSRC carrying RTP media streams that are duplicates of each other >> do in fact be labeled explicitly. I also note that a SDP based >> solution is not sufficient to resolve this issue. I think we need >> something in RTP, so that SSRC collisions can be handled. > > I can't say I am following. I suggest that you use something like the SRCNAME SDES item extension I propose in my draft. > >> 4. In addition there is a few questions how this duplication >> really should set some RTP fields. Is the duplication only working >> on Sequence > > That is the easiest way for a middle box or endpoint doing the stream > merging (duplicate suppression). If seqnums are different, what would > one do? look into the payload? It was simply that you had not documented what needs to be the same. Sequence number being the same is likely the easiest, but one do have to raise some warning flags if one has processing that changes these streams. For example a translator modifying the packetization must do the exact same manipulation on the other stream. But, I don't think anything else really works. > >> number level? There seem to be additional questions, for example in >> the need to have RTP timestamp considerations between the streams. >> They need to point identically into the joint timeline. Otherwise >> outages, or receiver taking synch from one and not the other stream >> can end up with different synchronizations. Becomes especially >> interesting to discuss when the time shifted transmission. > > The duplicate streams are coming from the same source, so they have > the same timestamp as well as seqnums. It has to be this way because > the node merging the streams will not re-write anything at all. It is > a simple suppression operation. Beauty of it is that things stay > pretty simple to use and implement without any changes to RTP/RTCP > plane at all. Yes, but you hadn't made it clear, and you have both SSRC and implied change of PT. So I didn't want to assume anything. The timestamp field also have implcations due to its binding with RTCP SR information. > > As for the time-shifted transmission, I suppose you are referring to > the temporal diversity/delayed duplication > (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, > timestamps are still the same for the reasons above. Changing the > timestamps for the delayed packets does not bring any benefit > (actually it complicates things) since the ultimate RTP application > will still receive one and only one RTP stream. Ok, but you will need to make clear on how one should set the RTCP SR timestamp NTP mapping to be clear. And what that implies for the RTCP jitter calculation. > >> 5. The draft also discussed Payload Type differences and have them >> in the SDP examples. I don't see how that is appropriate. If the >> streams > > When you are doing SSRC muxing, you put multiple streams in the same > m line and they end up having different PT numbers. What is wrong > with that? If they are in separate m lines, they could have the same > PT number. I am still asking why, there is no reason to use different PTs, unless you are doing the association between the different streams by them having different PTs. Which I believe is a Bad Idea (TM). The encoding in the packet are the same, so why don't they have the same PT. > >> 6. I think it is worth discussing also the benefits of SSRC >> multiplexed versus the session multiplexed. In multicast context >> there is clear benefits from a control and congestion perspective >> to have session multiplexed versions and these mapped onto >> different multicast groups enabling a receiver to choose one or >> both streams. > > This is what we have in section 5.2. Different streams can be sent in > different multicast sessions but it does not mean that they are > separate RTP sessions. I discussed this in detail with Colin. Thanks > to him for trying to teach me over and over what an RTP session > actually means. Yes, you have an example, but not a discussion of why an implementor should choose Session multiplexing over SSRC. I think that should be included, or I think you can wait for the architectural document I think will result from my multi-stream and simulcast draft. > >> 7. Thus I think the signalling aspects of this is the minor part. >> Although there clearly are some aspects of this needing discussion. >> For example clearer offer/answer rules for handling these. > > We have some text around O/A stuff. But frankly, I dont see any use > case where duplication will be used in a unicast application. I mean > if redundancy is needed, one should use FEC instead for unicast > transport. Duplication is a nice use case for multicast transport > where the bw overhead is easier to justify and the implementation is > easier. And one would naturally implement this spec in networks where > he already knows that the network elements support this spec. So, > maybe we should remove the whole O/A text anyway and write that this > will only be used declaratively. Then, I think we should slap an application statement to the beginning of the draft to ensure that it may only be used in multicast. For example b=TIAS was only intended to used in declarative SDPs, but it has become common in O/A, but it doesn't have clear rules. So I think it imporant that one don't assume to much. Yes, it might not be the best idea for unicast, but that is not going to prevent it from being used. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From vsingh.ietf@gmail.com Mon Jul 25 05:26:23 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEDE21F85EE for ; Mon, 25 Jul 2011 05:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMxHi+lADXqJ for ; Mon, 25 Jul 2011 05:26:22 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6A321F8500 for ; Mon, 25 Jul 2011 05:26:08 -0700 (PDT) Received: by fxe4 with SMTP id 4so10135916fxe.27 for ; Mon, 25 Jul 2011 05:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:message-id:subject:x-mailer:mime-version:content-type :content-transfer-encoding:content-disposition; bh=X/6y0MhRVAjfswirawaEbbg59AmQc39Rv/TNE/8fb7c=; b=U66NOqxBoIFGMC1EWA/83nkmbwfzJCXUNqh2w8dWnuyzCtcAqlUjzv8pF//h7BBXsI GLW6OPIQgXVZ5UhlCTM9fR5ypXsLeKZIy0WDAG19oQC5UtCghCcJlprxGXvmqUTWRrfk HfVxwWGO2Bimt2JmbpZoQtgPg3avcYiZ/0Rjg= Received: by 10.223.76.137 with SMTP id c9mr6762500fak.62.1311596767126; Mon, 25 Jul 2011 05:26:07 -0700 (PDT) Received: from varun.local (dsl-hkibrasgw2-fededf00-108.dhcp.inet.fi [80.223.222.108]) by mx.google.com with ESMTPS id h20sm3761240fai.44.2011.07.25.05.26.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 05:26:06 -0700 (PDT) Date: Mon, 25 Jul 2011 15:26:05 +0300 From: Varun Singh To: IETF MMUSIC WG Message-ID: X-Mailer: sparrow 1.3.1 (build 814.15) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [MMUSIC] Multipath RTP (interface advertisement in SDP) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 12:26:23 -0000 Greetings, The draft is part of AVTCore but we have recently introduced an "interface" attribute in SDP, as an alternative to in-band interface advertisement. The draft also contains some O/A examples and these changes can be found in the SDP Considerations section. http://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-02.txt Comments and suggestions are welcome from MMUSIC. Regards, Varun Begin forwarded message: > > A new version of I-D, draft-singh-avtcore-mprtp-02.txt has been successfully submitted by Varun Singh and posted to the IETF repository. > > Filename: draft-singh-avtcore-mprtp > Revision: 02 > Title: Multipath RTP (MPRTP) > Creation date: 2011-07-08 > WG ID: Individual Submission > Number of pages: 34 > > Abstract: > The Real-time Transport Protocol (RTP) is used to deliver real-time > content and, along with the RTP Control Protocol (RTCP), forms the > control channel between the sender and receiver. However, RTP and > RTCP assume a single delivery path between the sender and receiver > and make decisions based on the measured characteristics of this > single path. Increasingly, endpoints are becoming multi-homed, which > means that they are connected via multiple Internet paths. Network > utilization can be improved when endpoints use multiple parallel > paths for communication. The resulting increase in reliability and > throughput can also enhance the user experience. This document > extends the Real-time Transport Protocol (RTP) so that a single > session can take advantage of the availability of multiple paths > between two endpoints. > > > > > The IETF Secretariat -- http://www.netlab.tkk.fi/~varun From oran@cisco.com Mon Jul 25 06:38:43 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FD421F871E; Mon, 25 Jul 2011 06:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.849 X-Spam-Level: X-Spam-Status: No, score=-101.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB-lX3WH8Wmu; Mon, 25 Jul 2011 06:38:42 -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 4D7F621F867E; Mon, 25 Jul 2011 06:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=oran@cisco.com; l=12055; q=dns/txt; s=iport; t=1311601122; x=1312810722; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=67XbD3/3HVgUmc+msP/Bwx5D/7cwLwWQDUWWeQLzjXg=; b=UktmtJn/9RMNPH1PSvXmkDTZrT7JfIZax0HOKF0GBmqHbh2GKQ7cF4iF 0km73oh3epG/zet20GPH1BmLWUYbq4wFMA7zMCLp3xbbih/lHzvlYoiUc 3f3glbWJYaAEDloXAoIR9Xbz520JHm9sc5WWT3IZ25Wvbg4IgD7hZHlDG 4=; X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6114470" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jul 2011 13:38:41 +0000 Received: from sjc-vpnasa-174.cisco.com (sjc-vpnasa-174.cisco.com [10.21.104.174]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6PDcexY015629; Mon, 25 Jul 2011 13:38:40 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: David R Oran In-Reply-To: <4E2D4B52.80900@ericsson.com> Date: Mon, 25 Jul 2011 09:38:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E296F64.70500@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> <4E2D4B52.80900@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1244.3) Cc: "mmusic \(E-mail\)" , IETF AVTCore WG Subject: Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:38:43 -0000 One small comment, basically agreeing with Magnus point about payload = types. Usually when people use payload identifiers to do demultiplexing they = later regret it. Payload identifiers (in RTP or any other protocol for = that matter) should only be used to decide which parser to hand the data = to, not which state variable to bind the data in the packet to.=20 (further aside: this is one of the few things the OSI guys actually got = right when they had both payload ids and SAPs at every layer). DaveO. On Jul 25, 2011, at 6:54 AM, Magnus Westerlund wrote: > On 2011-07-24 23:21, Ali C. Begen (abegen) wrote: >>=20 >>=20 >>> -----Original Message----- From: avt-bounces@ietf.org >>> [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: >>> Friday, July 22, 2011 8:39 AM To: mmusic (E-mail); IETF AVTCore WG=20= >>> Subject: [AVTCORE] Comments on >>> draft-begen-mmusic-redundancy-grouping-01 >>>=20 >>> Hi, >>>=20 >>> (Primarily as individual, but the WG home question is as WG chair) >>>=20 >>> I have reviewed this draft and some comments on it. >>=20 >> Thanks for the review. >>=20 >>> 1. If this solution proposal is to be taken forward I think it >>> needs to be discussed in AVTCORE. The reason is that it has several >>> RTP details that needs to be figured out to make stream duplication >>> issue free in a general usage. I will take up a few of these issues >>> in the below comments. >>=20 >> That is why we asked for a slot in avtcore on wed. >>=20 >>> 2. One aspect this document has is a relation to what is discussed >>> in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream=20 >>> duplication both results in a certain form of multi-stream and also >>> has a similar but slightly different semantics to simulcast in that >>> the streams are two representations of a single original media >>> source. In this case they are clones, but not true duplicates due >>> to that RTP doesn't handle try duplicates well. >>=20 >> The data carried in the redundant streams are identical but the rtp >> header differs due to the different SSRCs. That is all. SSRC muxing >> nicely fits the use case we are tackling with. Simulcasting is quite >> different from our use case because in simulcasting different RTP >> streams most likely carry different data. >=20 > I agree that the purpose for multiple RTP streams from the same = original > media source are different from the primary case I set out to solve. = But > as Jonathan Lennox pointed out, redundancy and FEC have very similar > behaviors to simulcast with different encodings of the same original > source. >=20 > Thus, I do see a need to discuss for example how you identify the > streams that are a duplicate of each other. >=20 >>=20 >>> 3. Another issue that also the authors has identified is the >>> question of what one do when one has multiple media streams from >>> the same end-point. >>=20 >>> =46rom the same end-point (e.g., source) there could of course of >>> multiple media streams. You can use SSRC muxing for example to >>> identify your streams and use ssrc-group to group them if needed. >>=20 >> The concern in that editorial note was what if there were multiple >> streams in each m line but what if you wanted grouping/association >> among only a subset. >>=20 >> For example, >>=20 >> m=3Dvideo 30000 RTP/AVP 101 102 .... m=3Dvideo 30000 RTP/AVP 103 104 >>=20 >> I can easily associate 101 and 102 if I want to, but what if 101 and >> 103 were associated with each other. Can I use a=3Dgroup line? = Probably >> not. But, I don't know why you would need that kind of relation in >> the first place (even if you need, there are probably less messy ways >> to express them). If that had been a very desirable feature, SDP and >> grouping semantics along with RTP would not have defined in their >> current form I guess. >=20 > Yes, that is a very valid question also for simulcast. >=20 > And I think we can provide a story for doing that. But I don't think = it > should be based on using the RTP payload type to identify either of = the > versions. >=20 >>=20 >>> And in a general case one can't use the CNAME to separate the >>> sources. The reason is that two media sources that has a common >>> timing (synchronization) context do needs to indicate that by >>> having the same CNAME. Thus there are need for some additional >>> mechanism to ensure that >>=20 >> If 101 and 103 are associated, why can't I use the same CNAME for >> those streams? If 102 and 104 are associated/related, I would use a >> common CNAME for them, too (but theirs would be separate from 101 and >> 103's). >=20 > If SSRC A has a duplciation in SSRC C and SSRC B has a duplication in > SSRC D and both A and B comes from the same end-point and have a = common > synchronization context, then all of A-D needs to have the same CNAME. >=20 > And I get the impression that you are using a payload type based > association scheme here. And I think that is a bad idea. For example = it > can't support particular many streams. It also looks semantically = wrong, > as if Stream A uses PT 96, then SSRC C should use PT 96 also for the > corresponding packet duplicates. And if A switches from one PT to > another the other stream needs to follow. >=20 > Thus I think a SDES item based approach for indicating that it is in > fact A and C that are duplicates, rather than A and B or A and D. >=20 >>=20 >>> SSRC carrying RTP media streams that are duplicates of each other >>> do in fact be labeled explicitly. I also note that a SDP based >>> solution is not sufficient to resolve this issue. I think we need >>> something in RTP, so that SSRC collisions can be handled. >>=20 >> I can't say I am following. >=20 > I suggest that you use something like the SRCNAME SDES item extension = I > propose in my draft. >=20 >>=20 >>> 4. In addition there is a few questions how this duplication >>> really should set some RTP fields. Is the duplication only working >>> on Sequence >>=20 >> That is the easiest way for a middle box or endpoint doing the stream >> merging (duplicate suppression). If seqnums are different, what would >> one do? look into the payload? >=20 > It was simply that you had not documented what needs to be the same. > Sequence number being the same is likely the easiest, but one do have = to > raise some warning flags if one has processing that changes these > streams. For example a translator modifying the packetization must do > the exact same manipulation on the other stream. >=20 > But, I don't think anything else really works. >=20 >>=20 >>> number level? There seem to be additional questions, for example in >>> the need to have RTP timestamp considerations between the streams. >>> They need to point identically into the joint timeline. Otherwise >>> outages, or receiver taking synch from one and not the other stream >>> can end up with different synchronizations. Becomes especially >>> interesting to discuss when the time shifted transmission. >>=20 >> The duplicate streams are coming from the same source, so they have >> the same timestamp as well as seqnums. It has to be this way because >> the node merging the streams will not re-write anything at all. It is >> a simple suppression operation. Beauty of it is that things stay >> pretty simple to use and implement without any changes to RTP/RTCP >> plane at all. >=20 > Yes, but you hadn't made it clear, and you have both SSRC and implied > change of PT. So I didn't want to assume anything. >=20 > The timestamp field also have implcations due to its binding with RTCP > SR information. >=20 >>=20 >> As for the time-shifted transmission, I suppose you are referring to >> the temporal diversity/delayed duplication >> (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, >> timestamps are still the same for the reasons above. Changing the >> timestamps for the delayed packets does not bring any benefit >> (actually it complicates things) since the ultimate RTP application >> will still receive one and only one RTP stream. >=20 > Ok, but you will need to make clear on how one should set the RTCP SR > timestamp NTP mapping to be clear. And what that implies for the RTCP > jitter calculation. >=20 >>=20 >>> 5. The draft also discussed Payload Type differences and have them >>> in the SDP examples. I don't see how that is appropriate. If the >>> streams >>=20 >> When you are doing SSRC muxing, you put multiple streams in the same >> m line and they end up having different PT numbers. What is wrong >> with that? If they are in separate m lines, they could have the same >> PT number. >=20 > I am still asking why, there is no reason to use different PTs, unless > you are doing the association between the different streams by them > having different PTs. Which I believe is a Bad Idea (TM). The encoding > in the packet are the same, so why don't they have the same PT. >=20 >=20 >>=20 >>> 6. I think it is worth discussing also the benefits of SSRC >>> multiplexed versus the session multiplexed. In multicast context >>> there is clear benefits from a control and congestion perspective >>> to have session multiplexed versions and these mapped onto >>> different multicast groups enabling a receiver to choose one or >>> both streams. >>=20 >> This is what we have in section 5.2. Different streams can be sent in >> different multicast sessions but it does not mean that they are >> separate RTP sessions. I discussed this in detail with Colin. Thanks >> to him for trying to teach me over and over what an RTP session >> actually means. >=20 > Yes, you have an example, but not a discussion of why an implementor > should choose Session multiplexing over SSRC. I think that should be > included, or I think you can wait for the architectural document I = think > will result from my multi-stream and simulcast draft. >=20 >>=20 >>> 7. Thus I think the signalling aspects of this is the minor part.=20 >>> Although there clearly are some aspects of this needing discussion. >>> For example clearer offer/answer rules for handling these. >>=20 >> We have some text around O/A stuff. But frankly, I don=92t see any = use >> case where duplication will be used in a unicast application. I mean >> if redundancy is needed, one should use FEC instead for unicast >> transport. Duplication is a nice use case for multicast transport >> where the bw overhead is easier to justify and the implementation is >> easier. And one would naturally implement this spec in networks where >> he already knows that the network elements support this spec. So, >> maybe we should remove the whole O/A text anyway and write that this >> will only be used declaratively. >=20 > Then, I think we should slap an application statement to the beginning > of the draft to ensure that it may only be used in multicast. For > example b=3DTIAS was only intended to used in declarative SDPs, but it = has > become common in O/A, but it doesn't have clear rules. >=20 > So I think it imporant that one don't assume to much. Yes, it might = not > be the best idea for unicast, but that is not going to prevent it from > being used. >=20 > Cheers >=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 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Mon Jul 25 09:05:34 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4283921F904C; Mon, 25 Jul 2011 09:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.962 X-Spam-Level: X-Spam-Status: No, score=-3.962 tagged_above=-999 required=5 tests=[AWL=-2.562, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNJPEWln6cQx; Mon, 25 Jul 2011 09:05:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1370621F8BCF; Mon, 25 Jul 2011 07:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=13705; q=dns/txt; s=iport; t=1311602918; x=1312812518; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4gDIcMINWlF/3I84Dx5mFXixsL9LpG9JIksSelxP8+0=; b=Ze3RDljiS1i5SpPrflcTbGmmF/XzUMKLUKpjG9mquTLfsMEcyeZGCSa7 fwVTi/flzulSX3fQKaqhyiCr3QBMfE0EqwwayhIEpqQwYiPWo496+0Q8u fxvu5dn0RhX3O/6EoWHX1TexbWShmnx62r+GZlfsy3JFNqVDQAW3ulqxW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAFF4LU6rRDoH/2dsb2JhbAA0AQEBAQIBDQcBIT0LBwUHAwICAQkRBAEBAQoGBh0BBgETDC8OCAEBBRcMFAeXW49Wd4h8olmddwKDIYI9XwSHVZAri3A X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6122678" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2011 14:08:37 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6PE8a3H010229; Mon, 25 Jul 2011 14:08:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 07:08:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 07:07:34 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F810C97@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E2D4B52.80900@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 Thread-Index: AcxKuTkhgw3QFwdMQfqcuyQoCT23dgAGJvmA References: <4E296F64.70500@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> <4E2D4B52.80900@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 25 Jul 2011 14:08:36.0794 (UTC) FILETIME=[58A9B1A0:01CC4AD4] Cc: "mmusic \(E-mail\)" , IETF AVTCore WG Subject: Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:05:34 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, July 25, 2011 6:54 AM > To: Ali C. Begen (abegen) > Cc: mmusic (E-mail); IETF AVTCore WG > Subject: Re: [AVTCORE] Comments on = draft-begen-mmusic-redundancy-grouping-01 >=20 > On 2011-07-24 23:21, Ali C. Begen (abegen) wrote: > > > > > >> -----Original Message----- From: avt-bounces@ietf.org > >> [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: > >> Friday, July 22, 2011 8:39 AM To: mmusic (E-mail); IETF AVTCore WG > >> Subject: [AVTCORE] Comments on > >> draft-begen-mmusic-redundancy-grouping-01 > >> > >> Hi, > >> > >> (Primarily as individual, but the WG home question is as WG chair) > >> > >> I have reviewed this draft and some comments on it. > > > > Thanks for the review. > > > >> 1. If this solution proposal is to be taken forward I think it > >> needs to be discussed in AVTCORE. The reason is that it has several > >> RTP details that needs to be figured out to make stream duplication > >> issue free in a general usage. I will take up a few of these issues > >> in the below comments. > > > > That is why we asked for a slot in avtcore on wed. > > > >> 2. One aspect this document has is a relation to what is discussed > >> in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream > >> duplication both results in a certain form of multi-stream and also > >> has a similar but slightly different semantics to simulcast in that > >> the streams are two representations of a single original media > >> source. In this case they are clones, but not true duplicates due > >> to that RTP doesn't handle try duplicates well. > > > > The data carried in the redundant streams are identical but the rtp > > header differs due to the different SSRCs. That is all. SSRC muxing > > nicely fits the use case we are tackling with. Simulcasting is quite > > different from our use case because in simulcasting different RTP > > streams most likely carry different data. >=20 > I agree that the purpose for multiple RTP streams from the same = original > media source are different from the primary case I set out to solve. = But > as Jonathan Lennox pointed out, redundancy and FEC have very similar > behaviors to simulcast with different encodings of the same original > source. >=20 > Thus, I do see a need to discuss for example how you identify the > streams that are a duplicate of each other. Ok, lets discuss it. My current proposal is to use different SSRCs. PTs = turn out to be different since I designate these streams in the same m = line. Unless I am mistakes, you cannot put two different streams with = the same PT in a single m line. Remember, we do not use PT to demux the = RTP streams, we use SSRC for that purpose. =20 > > > >> 3. Another issue that also the authors has identified is the > >> question of what one do when one has multiple media streams from > >> the same end-point. > > > >> From the same end-point (e.g., source) there could of course of > >> multiple media streams. You can use SSRC muxing for example to > >> identify your streams and use ssrc-group to group them if needed. > > > > The concern in that editorial note was what if there were multiple > > streams in each m line but what if you wanted grouping/association > > among only a subset. > > > > For example, > > > > m=3Dvideo 30000 RTP/AVP 101 102 .... m=3Dvideo 30000 RTP/AVP 103 104 > > > > I can easily associate 101 and 102 if I want to, but what if 101 and > > 103 were associated with each other. Can I use a=3Dgroup line? = Probably > > not. But, I don't know why you would need that kind of relation in > > the first place (even if you need, there are probably less messy = ways > > to express them). If that had been a very desirable feature, SDP and > > grouping semantics along with RTP would not have defined in their > > current form I guess. >=20 > Yes, that is a very valid question also for simulcast. >=20 > And I think we can provide a story for doing that. But I don't think = it > should be based on using the RTP payload type to identify either of = the > versions. >=20 > > > >> And in a general case one can't use the CNAME to separate the > >> sources. The reason is that two media sources that has a common > >> timing (synchronization) context do needs to indicate that by > >> having the same CNAME. Thus there are need for some additional > >> mechanism to ensure that > > > > If 101 and 103 are associated, why can't I use the same CNAME for > > those streams? If 102 and 104 are associated/related, I would use a > > common CNAME for them, too (but theirs would be separate from 101 = and > > 103's). >=20 > If SSRC A has a duplciation in SSRC C and SSRC B has a duplication in > SSRC D and both A and B comes from the same end-point and have a = common > synchronization context, then all of A-D needs to have the same CNAME. Well, above implies that all streams are coming from the same source and = yes, they will end up having the same CNAME since you required A will be = synched with B. But, still I think this is workable without any = additional mechanism. A and C would be in the same m line and B and D = would be in the same (but separate from the first) m line. That would = give me what I want. =20 > And I get the impression that you are using a payload type based > association scheme here. And I think that is a bad idea. For example = it > can't support particular many streams. It also looks semantically = wrong, > as if Stream A uses PT 96, then SSRC C should use PT 96 also for the > corresponding packet duplicates. And if A switches from one PT to > another the other stream needs to follow. No, I am not suggesting to use PT for demuxing. I use SSRC for that = purpose. As I asked above, if I can use the same PT for multiple streams = in the same m line, then I will. But I don=92t think I can. > Thus I think a SDES item based approach for indicating that it is in > fact A and C that are duplicates, rather than A and B or A and D. >=20 > > > >> SSRC carrying RTP media streams that are duplicates of each other > >> do in fact be labeled explicitly. I also note that a SDP based > >> solution is not sufficient to resolve this issue. I think we need > >> something in RTP, so that SSRC collisions can be handled. > > > > I can't say I am following. >=20 > I suggest that you use something like the SRCNAME SDES item extension = I > propose in my draft. >=20 > > > >> 4. In addition there is a few questions how this duplication > >> really should set some RTP fields. Is the duplication only working > >> on Sequence > > > > That is the easiest way for a middle box or endpoint doing the = stream > > merging (duplicate suppression). If seqnums are different, what = would > > one do? look into the payload? >=20 > It was simply that you had not documented what needs to be the same. I think I did, but I will check. > Sequence number being the same is likely the easiest, but one do have = to > raise some warning flags if one has processing that changes these > streams. For example a translator modifying the packetization must do > the exact same manipulation on the other stream. Yes, obviously. We can put this warning. =20 > But, I don't think anything else really works. Right, seqnum is the easiest and possibly the only way in practice. =20 > > > >> number level? There seem to be additional questions, for example in > >> the need to have RTP timestamp considerations between the streams. > >> They need to point identically into the joint timeline. Otherwise > >> outages, or receiver taking synch from one and not the other stream > >> can end up with different synchronizations. Becomes especially > >> interesting to discuss when the time shifted transmission. > > > > The duplicate streams are coming from the same source, so they have > > the same timestamp as well as seqnums. It has to be this way because > > the node merging the streams will not re-write anything at all. It = is > > a simple suppression operation. Beauty of it is that things stay > > pretty simple to use and implement without any changes to RTP/RTCP > > plane at all. >=20 > Yes, but you hadn't made it clear, and you have both SSRC and implied > change of PT. So I didn't want to assume anything. OK, will make this clear, as well. =20 > The timestamp field also have implcations due to its binding with RTCP > SR information. >=20 > > > > As for the time-shifted transmission, I suppose you are referring to > > the temporal diversity/delayed duplication > > (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, > > timestamps are still the same for the reasons above. Changing the > > timestamps for the delayed packets does not bring any benefit > > (actually it complicates things) since the ultimate RTP application > > will still receive one and only one RTP stream. >=20 > Ok, but you will need to make clear on how one should set the RTCP SR > timestamp NTP mapping to be clear. And what that implies for the RTCP > jitter calculation. The fact that you are using delayed duplication or spatial diversity = means that you will likely introduce some jitter into your stream unless = the node merging the streams smooths out that jitter in the first place. = There is not nothing special for the ultimate endpoint for preparing the = reports, it just does what it is supposed to do. In most systems, the = ultimate RTP receivers might not be even aware of the fact that they are = receiving a stream merged from two identical streams. That is a design = feature. > > > >> 5. The draft also discussed Payload Type differences and have them > >> in the SDP examples. I don't see how that is appropriate. If the > >> streams > > > > When you are doing SSRC muxing, you put multiple streams in the same > > m line and they end up having different PT numbers. What is wrong > > with that? If they are in separate m lines, they could have the same > > PT number. >=20 > I am still asking why, there is no reason to use different PTs, unless > you are doing the association between the different streams by them > having different PTs. Which I believe is a Bad Idea (TM). The encoding > in the packet are the same, so why don't they have the same PT. Well again, I am not using it for demuxing purposes. I just believe that = is how the m line works. Tell me otherwise and I will be happy to make = PTs the same. =20 >=20 > > > >> 6. I think it is worth discussing also the benefits of SSRC > >> multiplexed versus the session multiplexed. In multicast context > >> there is clear benefits from a control and congestion perspective > >> to have session multiplexed versions and these mapped onto > >> different multicast groups enabling a receiver to choose one or > >> both streams. > > > > This is what we have in section 5.2. Different streams can be sent = in > > different multicast sessions but it does not mean that they are > > separate RTP sessions. I discussed this in detail with Colin. Thanks > > to him for trying to teach me over and over what an RTP session > > actually means. >=20 > Yes, you have an example, but not a discussion of why an implementor > should choose Session multiplexing over SSRC. I think that should be > included, or I think you can wait for the architectural document I = think > will result from my multi-stream and simulcast draft. Lets discuss in the session. =20 > > > >> 7. Thus I think the signalling aspects of this is the minor part. > >> Although there clearly are some aspects of this needing discussion. > >> For example clearer offer/answer rules for handling these. > > > > We have some text around O/A stuff. But frankly, I don=92t see any = use > > case where duplication will be used in a unicast application. I mean > > if redundancy is needed, one should use FEC instead for unicast > > transport. Duplication is a nice use case for multicast transport > > where the bw overhead is easier to justify and the implementation is > > easier. And one would naturally implement this spec in networks = where > > he already knows that the network elements support this spec. So, > > maybe we should remove the whole O/A text anyway and write that this > > will only be used declaratively. >=20 > Then, I think we should slap an application statement to the beginning > of the draft to ensure that it may only be used in multicast. For Wfm. > example b=3DTIAS was only intended to used in declarative SDPs, but it = has > become common in O/A, but it doesn't have clear rules. >=20 > So I think it imporant that one don't assume to much. Yes, it might = not > be the best idea for unicast, but that is not going to prevent it from > being used. If one really uses this for unicast, let them deal with all the = potential O/A problems that might surface. It is more like they will = deserve it :) Cheers, -acbegen =20 > Cheers >=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 > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jul 25 09:12:36 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA411E817E; Mon, 25 Jul 2011 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.19 X-Spam-Level: X-Spam-Status: No, score=-106.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3f-KBiWGc4J; Mon, 25 Jul 2011 09:12:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6028021F8CA7; Mon, 25 Jul 2011 07:55:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-43-4e2d83e7cc96 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 36.C3.20773.7E38D2E4; Mon, 25 Jul 2011 16:55:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 25 Jul 2011 16:55:35 +0200 Message-ID: <4E2D83E5.4030100@ericsson.com> Date: Mon, 25 Jul 2011 10:55:33 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4E296F64.70500@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> <4E2D4B52.80900@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C97@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F810C97@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , IETF AVTCore WG Subject: Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:12:36 -0000 On 2011-07-25 10:07, Ali C. Begen (abegen) wrote: > Ok, lets discuss it. My current proposal is to use different SSRCs. PTs turn out to be different since I designate these streams in the same m line. Unless I am mistakes, you cannot put two different streams with the same PT in a single m line. Remember, we do not use PT to demux the RTP streams, we use SSRC for that purpose. No, that is wrong. The PT is completely unrelated to to which SSRC that use them. The set of configured PTs can be used by any of the sources that transmit in the direction for which they are configured. I do include the direction because of the O/A aspects of having different configurations for receving in different directions. >> If SSRC A has a duplciation in SSRC C and SSRC B has a duplication >> in SSRC D and both A and B comes from the same end-point and have a >> common synchronization context, then all of A-D needs to have the >> same CNAME. > > Well, above implies that all streams are coming from the same source > and yes, they will end up having the same CNAME since you required A > will be synched with B. But, still I think this is workable without > any additional mechanism. A and C would be in the same m line and B > and D would be in the same (but separate from the first) m line. That > would give me what I want. I am not agreeing that you would put A and B in different sessions. This doesn't make sense if you actually like to provide two related media streams of the same type, for example two cameras covering different parts of a telepresence room, or two different camera angels in a movie. What you are suggesting seems to be a hack to just get around the issue that if you have streams that are some form of alternatives of the actual same original source then you need to identify, like the SRCNAME proposal. > >> And I get the impression that you are using a payload type based >> association scheme here. And I think that is a bad idea. For >> example it can't support particular many streams. It also looks >> semantically wrong, as if Stream A uses PT 96, then SSRC C should >> use PT 96 also for the corresponding packet duplicates. And if A >> switches from one PT to another the other stream needs to follow. > > No, I am not suggesting to use PT for demuxing. I use SSRC for that > purpose. As I asked above, if I can use the same PT for multiple > streams in the same m line, then I will. But I dont think I can. > Yes, understand this is a different type of missunderstanding of RTP. >> >> Ok, but you will need to make clear on how one should set the RTCP >> SR timestamp NTP mapping to be clear. And what that implies for the >> RTCP jitter calculation. > > The fact that you are using delayed duplication or spatial diversity > means that you will likely introduce some jitter into your stream > unless the node merging the streams smooths out that jitter in the > first place. There is not nothing special for the ultimate endpoint > for preparing the reports, it just does what it is supposed to do. > In most systems, the ultimate RTP receivers might not be even aware > of the fact that they are receiving a stream merged from two > identical streams. That is a design feature. > When you talk about jitter here, you are talking about small transport level jitter, rather than jitter on the level of frame intervals. Sure, if you have a translator that merge these, then you clearly should be hidden to the end-point behind translator. >>>> 7. Thus I think the signalling aspects of this is the minor >>>> part. Although there clearly are some aspects of this needing >>>> discussion. For example clearer offer/answer rules for handling >>>> these. >>> >>> We have some text around O/A stuff. But frankly, I dont see any >>> use case where duplication will be used in a unicast application. >>> I mean if redundancy is needed, one should use FEC instead for >>> unicast transport. Duplication is a nice use case for multicast >>> transport where the bw overhead is easier to justify and the >>> implementation is easier. And one would naturally implement this >>> spec in networks where he already knows that the network elements >>> support this spec. So, maybe we should remove the whole O/A text >>> anyway and write that this will only be used declaratively. >> >> Then, I think we should slap an application statement to the >> beginning of the draft to ensure that it may only be used in >> multicast. For > > Wfm. > >> example b=TIAS was only intended to used in declarative SDPs, but >> it has become common in O/A, but it doesn't have clear rules. >> >> So I think it imporant that one don't assume to much. Yes, it might >> not be the best idea for unicast, but that is not going to prevent >> it from being used. > > If one really uses this for unicast, let them deal with all the > potential O/A problems that might surface. It is more like they will > deserve it :) > :-) Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From adam@nostrum.com Tue Jul 26 10:29:19 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D47811E80EC for ; Tue, 26 Jul 2011 10:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+sDL80D8SVs for ; Tue, 26 Jul 2011 10:29:18 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4860621F8BE4 for ; Tue, 26 Jul 2011 10:29:17 -0700 (PDT) Received: from dhcp-1418.meeting.ietf.org ([130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6QHSpNi024801 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 12:29:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E2EF952.10706@nostrum.com> Date: Tue, 26 Jul 2011 13:28:50 -0400 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: draft-ietf-mmusic-sctp-sdp@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism) Cc: "MMUSIC \(Multiparty Multimedia Session Control\) WG" Subject: [MMUSIC] SDP for SCTP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:29:19 -0000 I have a couple of comments on the SDP for SCTP draft. In looking through the current version of the document, it appears that datagram is being assumed (based on, for example, the mention of DTLS without TLS). Surely we want to consider using stream-oriented uses as well. You might consider that the earlier foray into this arena (draft-fairlie-mmusic-sdp-sctp) used different protocol identifiers for stream and datagram uses (SCTP and USCTP). Also, something that sticks out is that the current mechanism does not have any way to play nicely with middleboxes and multihomed connections. As the draft notes, existing middleboxes do not yet have support for SCTP. It would be nice if we gave them the tools to handle this properly (should they choose to do so) inside the SDP. Is there a reason we're not adding a new set of a= lines to indicate additional IP addresses associated with a connection? /a From dwing@cisco.com Tue Jul 26 13:20:59 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F2111E80A0 for ; Tue, 26 Jul 2011 13:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.07 X-Spam-Level: X-Spam-Status: No, score=-104.07 tagged_above=-999 required=5 tests=[AWL=-1.471, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7X3hjENIydr for ; Tue, 26 Jul 2011 13:20:58 -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 287E711E8099 for ; Tue, 26 Jul 2011 13:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2456; q=dns/txt; s=iport; t=1311711658; x=1312921258; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=+AxxK6mu7RfuAj90/erQbDhy1V3hnQRA5C8ISP3IhvQ=; b=AEqZh6Q62mDRs8qR7qr1rIRV3+ANka+SMdO0CdfoCaiqhY9/4aNZ6vnF 372Rfvpyd8/M05Gc2L/e2OJfWjujW6DbZc+cTw7rJlVyse4SoAXaNFUDW m1dPCbfBXP9bmo24jgpvqlTVZTSPRgg/trVOjYXbkdGON24R6z89RUV8+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAGMgL06rRDoH/2dsb2JhbAA1AQEBAQIBAQEBBQwBGxA6EAcBBAIKDgECBAEBIxEHFAYSFg0OCAEBBQEWBQoYl06Ba41wd4h8BKM9nlmDQ4J9BJxchxI X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6633214" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2011 20:20:57 +0000 Received: from dwingWS (sjc-vpn7-1517.cisco.com [10.21.149.237]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKKuAS026590; Tue, 26 Jul 2011 20:20:56 GMT From: "Dan Wing" To: "'Varun Singh'" , "'IETF MMUSIC WG'" References: In-Reply-To: Date: Tue, 26 Jul 2011 16:20:56 -0400 Message-ID: <020301cc4bd1$86fe69d0$94fb3d70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxKxhmTP8XW5uRlS52bwlGNnFObOwBCz6/Q Content-Language: en-us Subject: Re: [MMUSIC] Multipath RTP (interface advertisement in SDP) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:20:59 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Varun Singh > Sent: Monday, July 25, 2011 8:26 AM > To: IETF MMUSIC WG > Subject: [MMUSIC] Multipath RTP (interface advertisement in SDP) > > Greetings, > > The draft is part of AVTCore but we have recently introduced an > "interface" attribute in SDP, as an alternative to in-band interface > advertisement. The draft also contains some O/A examples and these > changes can be found in the SDP Considerations section. > http://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-02.txt > > Comments and suggestions are welcome from MMUSIC. ICE's STUN connectivity checks, which use the password exchanged in signaling as HMACs for the connectivity check, feel like a natural way to add new MPRTP addresses. Have you analyzed using such a technique and discarded the idea? -d > Regards, > Varun > > Begin forwarded message: > > > > A new version of I-D, draft-singh-avtcore-mprtp-02.txt has been > successfully submitted by Varun Singh and posted to the IETF > repository. > > > > Filename: draft-singh-avtcore-mprtp > > Revision: 02 > > Title: Multipath RTP (MPRTP) > > Creation date: 2011-07-08 > > WG ID: Individual Submission > > Number of pages: 34 > > > > Abstract: > > The Real-time Transport Protocol (RTP) is used to deliver real-time > > content and, along with the RTP Control Protocol (RTCP), forms the > > control channel between the sender and receiver. However, RTP and > > RTCP assume a single delivery path between the sender and receiver > > and make decisions based on the measured characteristics of this > > single path. Increasingly, endpoints are becoming multi-homed, which > > means that they are connected via multiple Internet paths. Network > > utilization can be improved when endpoints use multiple parallel > > paths for communication. The resulting increase in reliability and > > throughput can also enhance the user experience. This document > > extends the Real-time Transport Protocol (RTP) so that a single > > session can take advantage of the availability of multiple paths > > between two endpoints. > > > > > > > > > > The IETF Secretariat > -- > > http://www.netlab.tkk.fi/~varun > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From stewe@stewe.org Wed Jul 27 06:52:25 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0AB11E80BF; Wed, 27 Jul 2011 06:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRmsJSZPc741; Wed, 27 Jul 2011 06:52:24 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id B7DF711E807A; Wed, 27 Jul 2011 06:52:23 -0700 (PDT) Received: from [130.129.21.150] (unverified [130.129.21.150]) by stewe.org (SurgeMail 3.9e) with ESMTP id 18115-1743317 for multiple; Wed, 27 Jul 2011 15:52:22 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 27 Jul 2011 09:52:17 -0400 From: Stephan Wenger To: , , , Message-ID: Thread-Topic: Incoming liaison statement from MPEG Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3394605142_5344166" X-Originating-IP: 130.129.21.150 X-Authenticated-User: stewe@stewe.org Subject: [MMUSIC] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:52:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3394605142_5344166 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, We have received a liaison statement from the MPEG meeting that took place last week. No action is requested from us. They inform us that they have issued a second DIS of their HTTP streaming project known as "DASH", to be voted on according to ISO/IEC rules in the next couple of months. I heard that there was a hiccup during the first ballot. They must have addressed the ballot comments. That said, I'm not aware of earth-shattering changes between the new version and the previous one, but I'm not an insider in Dash. The liaison statement will shortly appear on the IETF's tracker. If you need a version urgently, please contact me in private. Thanks, Stephan --B_3394605142_5344166 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
We ha= ve received a liaison statement from the MPEG meeting that took place last w= eek.  No action is requested from us.
They inform us that the= y have issued a second DIS of their HTTP streaming project known as "DASH", = to be voted on according to ISO/IEC rules in the next couple of months. &nbs= p;I heard that there was a hiccup during the first ballot.  They must h= ave addressed the ballot comments.  That said, I'm not aware of earth-s= hattering changes between the new version and the previous one, but I'm not = an insider in Dash.  
The liaison statement will shortly appe= ar on the IETF's tracker.  If you need a version urgently, please conta= ct me in private.
Thanks,
Stephan
--B_3394605142_5344166-- From yuepeiyu@huawei.com Wed Jul 27 07:11:16 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB10921F8B66; Wed, 27 Jul 2011 07:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNqMXctXhckg; Wed, 27 Jul 2011 07:11:16 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C088121F86EC; Wed, 27 Jul 2011 07:11:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOZ00FS9WPS2W@szxga04-in.huawei.com>; Wed, 27 Jul 2011 22:10:40 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOZ00IRVWPSFQ@szxga04-in.huawei.com>; Wed, 27 Jul 2011 22:10:40 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACQ44889; Wed, 27 Jul 2011 22:10:40 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 22:10:34 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 22:10:40 +0800 Date: Wed, 27 Jul 2011 14:10:38 +0000 From: "Roy Yue(PeiYu)" In-reply-to: X-Originating-IP: [172.24.2.41] To: Stephan Wenger , "mmusic@ietf.org" , "avtcore@ietf.org" , "fecframe@ietf.org" , "rai@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_QBcnPUxs2/VU2v4DD02AbQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Incoming liaison statement from MPEG Thread-index: AQHMTGRwR5u0NRUi6kWWVP1ijt7FzpUAMqiE X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [MMUSIC] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:11:16 -0000 --Boundary_(ID_QBcnPUxs2/VU2v4DD02AbQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgYWxsLA0KDQoNCg0KSSB3YXMgaW4gdGhlIERBU0ggbWVldGluZyBsYXN0IHdlZWsuIEhlcmUg aXMgc29tZSBiYWNrZ3JvdWQgaW5mb3JtYXRpb24gRllJLg0KDQpUaGUgYmFsbG90IHJlc3VsdCBp cyBub3QgYXBwcm92YWwgYmVjYXVzZSBvZiB0aGUgbmV3IGJhbGxvdCBydWxlcyBkZWZpbmVkIGJ5 IElTTzogIGEgY291cGxlIG9mIG5hdGlvbmEgYm9kaWVzIHZvdGVkICJEaXNhcHByb3ZlIHdpdGgg Y29tbWVudHMgLi4uIiB3aGljaCB3YXMgbWVhbmluZyAiaWYgdGhlIGNvbW1lbnRzIGFyZSBhZGRy ZXNzZWQgdGhlbiBtYXkgY2hhbmdlIHRvIEFwcHJvdmUiLiBIb3dldmVyLCBhY2NvcmRpbmcgdG8g dGhlIG5ldyBydWxlLCAiRGlzYXBwcm92ZSB3aXRoIGNvbW1lbnRzIiBtZWFucyAiRGlzYXBwcm92 ZSIsIHdoYXRldmVyIHRoZSBjb21tZW50cyBhcmUgYWRkcmVzc2VkLiBUaGlzIGlzIHRoZSBmaXJz dCB0aW1lIHRoZSBuZXcgcnVsZSBhcHBsaWVzLg0KDQoNCg0KUmVnYXJkcywgUm95DQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBmZWNmcmFtZS1ib3VuY2Vz QGlldGYub3JnIFtmZWNmcmFtZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN0ZXBoYW4gV2VuZ2Vy IFtzdGV3ZUBzdGV3ZS5vcmddDQq3osvNyrG85DogMjAxMcTqN9TCMjfI1SAyMTo1Mg0Ktb06IG1t dXNpY0BpZXRmLm9yZzsgYXZ0Y29yZUBpZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmc7IHJhaUBp ZXRmLm9yZw0K1vfM4jogW0ZlY2ZyYW1lXSBJbmNvbWluZyBsaWFpc29uIHN0YXRlbWVudCBmcm9t IE1QRUcNCg0KSGkgYWxsLA0KV2UgaGF2ZSByZWNlaXZlZCBhIGxpYWlzb24gc3RhdGVtZW50IGZy b20gdGhlIE1QRUcgbWVldGluZyB0aGF0IHRvb2sgcGxhY2UgbGFzdCB3ZWVrLiAgTm8gYWN0aW9u IGlzIHJlcXVlc3RlZCBmcm9tIHVzLg0KVGhleSBpbmZvcm0gdXMgdGhhdCB0aGV5IGhhdmUgaXNz dWVkIGEgc2Vjb25kIERJUyBvZiB0aGVpciBIVFRQIHN0cmVhbWluZyBwcm9qZWN0IGtub3duIGFz ICJEQVNIIiwgdG8gYmUgdm90ZWQgb24gYWNjb3JkaW5nIHRvIElTTy9JRUMgcnVsZXMgaW4gdGhl IG5leHQgY291cGxlIG9mIG1vbnRocy4gIEkgaGVhcmQgdGhhdCB0aGVyZSB3YXMgYSBoaWNjdXAg ZHVyaW5nIHRoZSBmaXJzdCBiYWxsb3QuICBUaGV5IG11c3QgaGF2ZSBhZGRyZXNzZWQgdGhlIGJh bGxvdCBjb21tZW50cy4gIFRoYXQgc2FpZCwgSSdtIG5vdCBhd2FyZSBvZiBlYXJ0aC1zaGF0dGVy aW5nIGNoYW5nZXMgYmV0d2VlbiB0aGUgbmV3IHZlcnNpb24gYW5kIHRoZSBwcmV2aW91cyBvbmUs IGJ1dCBJJ20gbm90IGFuIGluc2lkZXIgaW4gRGFzaC4NClRoZSBsaWFpc29uIHN0YXRlbWVudCB3 aWxsIHNob3J0bHkgYXBwZWFyIG9uIHRoZSBJRVRGJ3MgdHJhY2tlci4gIElmIHlvdSBuZWVkIGEg dmVyc2lvbiB1cmdlbnRseSwgcGxlYXNlIGNvbnRhY3QgbWUgaW4gcHJpdmF0ZS4NClRoYW5rcywN ClN0ZXBoYW4NCg== --Boundary_(ID_QBcnPUxs2/VU2v4DD02AbQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi all,

 

I was in the DASH meeting last week. Here is some backgroud information = FYI.

The ballot result is not approval because of the new ballot rules define= d by ISO:  a couple of nationa bodies voted "Disapprove with comm= ents ..." which was meaning "if the comments are addressed then&n= bsp;may change to Approve". However, according to the new rule, "Disapprove with comments" means "Disapprove", w= hatever the comments are addressed. This is the first time the new rule app= lies.

 

Regards, Roy

 

=B7=A2=BC=FE=C8=CB: fecframe-bounces@ietf.= org [fecframe-bounces@ietf.org] =B4=FA=B1=ED Stephan Wenger [stewe@stewe.or= g]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 21:52
=B5=BD: mmusic@ietf.org; avtcore@ietf.org; fecframe@ietf.org; rai@ie= tf.org
=D6=F7=CC=E2: [Fecframe] Incoming liaison statement from MPEG

Hi all,
We have received a liaison statement from the MPEG meeting that took p= lace last week.  No action is requested from us.
They inform us that they have issued a second DIS of their HTTP stream= ing project known as "DASH", to be voted on according to ISO/IEC = rules in the next couple of months.  I heard that there was a hiccup d= uring the first ballot.  They must have addressed the ballot comments.  That said, I'm not aware of earth-shattering ch= anges between the new version and the previous one, but I'm not an insider = in Dash.  
The liaison statement will shortly appear on the IETF's tracker.  = ;If you need a version urgently, please contact me in private.
Thanks,
Stephan
--Boundary_(ID_QBcnPUxs2/VU2v4DD02AbQ)-- From aallen@rim.com Wed Jul 27 08:17:54 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543BA21F8A69 for ; Wed, 27 Jul 2011 08:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.174 X-Spam-Level: X-Spam-Status: No, score=-5.174 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-mmNkmDGgTw for ; Wed, 27 Jul 2011 08:17:50 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACFA21F8A64 for ; Wed, 27 Jul 2011 08:17:48 -0700 (PDT) X-AuditID: 0a412830-b7b59ae000003999-bd-4e302c1355bf Received: from XHT110CNC.rim.net (xht110cnc.rim.net [10.65.22.55]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 46.48.14745.31C203E4; Wed, 27 Jul 2011 15:17:39 +0000 (GMT) Received: from XCT105ADS.rim.net (10.67.111.46) by XHT110CNC.rim.net (10.65.22.55) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 27 Jul 2011 11:17:47 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 10:17:46 -0500 From: Andrew Allen To: "mmusic@ietf.org" Thread-Topic: resurecting the CCAP attribute Thread-Index: AcxMcFWSeEr66jGGTs2RSJrRuz2lcw== Date: Wed, 27 Jul 2011 15:17:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.254] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23017BFCXMB105ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsXC5ShmriusY+Bn8PyzuMXU5Y9ZHBg9liz5 yRTAGNXAaJOYl5dfkliSqpCSWpxsq+STmp6YoxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2Si pFCQk5icmpuaV2KrlFhQkJqXomTHpYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HSR QMI/7owHHWcZCybtYaw4+moqawPj5UWMXYycHBICJhL/WlZB2WISF+6tZwOxhQR6mCReH8jr YuQCspcySrS9m8YM4WxhlJh6qocdpIpNQFli+e8ZYN0iAuoSX/f2MIPYwkD2huu9zBBxHYkX 6/eyQdh6EpN3fACLswioSty40cMKYvMKuEl8mzcNbA4j0BXfT61hArGZBcQlbj2ZzwRxnYDE kj3nmSFsUYmXj/8B9XIA2YoSr0/XQZTnSuz/cJwNYqSgxMmZT1ggnpGW2HFyDeMERpFZSKbO QtIyC0kLRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UomJtRbGBmmJyXrFeUmauXl1qy iRGcLjQMdjBO2Kt1iFGAg1GJh/exvIGfEGtiWXFl7iFGCQ5mJRHeS3JAId6UxMqq1KL8+KLS nNTiQ4yuwACayCzFnZwPTGV5JfHGBga4OUrivGHSQEME0oFpLDs1tSC1CGYOEwenVAPjaflv j0r4fzyqTDxqZa+ncUPadLFYUPmmD16Jf47N3dC5su7n5uIVyZuCnwqasAs9fHxVbFXJlJ79 qYcEWFgPKE2oLVz6Jd6Y+w0/67KOilijSY/upIedm3c6IKuzvvFz42WrOXJxH/qa2vfE7OmV vnv5xJZnL9IXqt/OSG9/NWlTxLNLDK0rlFiKMxINtZiLihMBd3D8BD0DAAA= Subject: [MMUSIC] resurecting the CCAP attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:17:54 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD23017BFCXMB105ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Yesterday several MMUSIC participants including Jonathan Lennox and Miguel G= arcia got together to discuss what to do regarding the CCAP attribute which= is currently used in 3GPP specifications but was removed from the misc-cap= draft (which then became the sdp-icap-bcap draft without the CCAP attribute= ). The CCAP attribute was removed after earlier comments on the list from Jo= nathan regarding the possibility that CCAP might be used as an alternative t= o ICE for negotiating IP addresses for the C line (see email thread below).= 3GPP currently utilize the CCAP attribute with SDP-cap-neg for negotiation= of use of a circuit switched call for the audio media as an alternative to= an audio RTP stream over packet switched access. CCAP is used to offer the= PSTN net type and E.164 number used to set up that call. After a thorough discussion the conclusion of those involved in the discussi= on (including Jonathan) was that the best way forward given the constraints= of the 3GPP architecture is to resurrect the CCAP attribute but with some w= ording that places constraints on its usage so that it isn't used to negotia= te alternative addresses for a network type for which ICE can be used to neg= otiate addresses. This means that CCAP could be used to negotiate the possib= ility to use PSTN net type as an alternative to the IN net type but that usi= ng alternative IP address candidates within the IN net type would need to be= negotiated using ICE not using CCAP. Are the any concerns from other MMUSIC participants if CCAP is resurrected (= probably in an again renamed version of the sdp-icap-bcap draft that would a= gain include CCAP) with appropriate text to address the ICE issue along the= lines of above? Andrew * To: "Simo.Veikkolainen at nokia.com" >, "mmusic at ietf.org" > * Subject: Re: [MMUSIC] What to do with the ccap attribute? * From: Jonathan Lennox > * Date: Mon, 10 May 2010 11:24:36 -0400 * Accept-language: en-US * Acceptlanguage: en-US * Delivered-to: mmusic at core3.amsl.com * In-reply-to: > * List-archive: * List-help: * List-id: Multiparty Multimedia Session Control Working Group * List-post: * List-subscribe: , * List-unsubscribe: , * References:
------=_NextPart_000_0628_01CC4E5A.3276C750-- From miguel.a.garcia@ericsson.com Sun Jul 31 01:33:36 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7079A21F87FC; Sun, 31 Jul 2011 01:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMvag3NoOHpm; Sun, 31 Jul 2011 01:33:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 64F2521F8772; Sun, 31 Jul 2011 01:33:32 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-8e-4e35135d9b9b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5F.8A.20773.D53153E4; Sun, 31 Jul 2011 10:33:33 +0200 (CEST) Received: from [159.107.48.91] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Sun, 31 Jul 2011 10:33:33 +0200 Message-ID: <4E35135C.7010109@ericsson.com> Date: Sun, 31 Jul 2011 10:33:32 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <005001cc4d39$ef62b580$ce282080$@uni-tuebingen.de> <5F7BCCF5541B7444830A2288ABBEBC96215F769EF3@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC96215F769EF3@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "codec@ietf.org" , mmusic Subject: Re: [MMUSIC] [codec] SDP Support for Multiple Packetisation Periods X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 08:33:36 -0000 Yeap, I was also going to point to the (already expired) I-D on multiple packetization problem draft, http://tools.ietf.org/id/draft-garcia-mmusic-multiple-ptimes-problem-03.txt The authors didn't see much interest in solving this problem, so the draft was abandoned. If the community realizes that the problem still persists, we can easily resurrect it. /Miguel On 29/07/2011 11:31, Schwarz, Albrecht (Albrecht) wrote: > Paul, > > 1) SDP => IETF MMUSIC > > 2) ptime problem statement ("well known"), see > > Multiple Packetization Times in the Session Description Protocol (SDP): > Problem Statement, Requirements& Solution > draft-garcia-mmusic-multiple-ptimes-problem-03.txt > http://tools.ietf.org/html/draft-garcia-mmusic-multiple-ptimes-problem-03 > > 3) Solution: > = revised SDP Offer/Answer > see > a) SDP) Capability Negotiation RFC 5939 > http://tools.ietf.org/html/rfc5939 > b) SDP Media Mapabilities Negotiation > http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-capabilities/ > > Thus, revised SDP Offer/Answer must be used (instead of legacy SDP Offer/Answer RFC 3264). > > -Albrecht > > > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] >> On Behalf Of Paul Beaumont >> Sent: Donnerstag, 28. Juli 2011 19:31 >> To: codec@ietf.org >> Subject: [codec] SDP Support for Multiple Packetisation Periods >> >> All >> >> Apologies, being first time to IETF and its mailing lists, if >> this is not the right mailing list to post this request to. >> >> On initial inspection it looks like it is not possible to >> specify in SDP the specific packetisation period associated >> with a codec that is available through negotiation. Specific >> case I am concerned with is to support (1) G.711 @ PP=10ms >> and (2) G.711 @ PP=20ms; prioritised in that order. The ptime >> parameter would appear to apply to both. >> >> Please can you advise where I should submit this question or >> if this is the right frum then whether the above observation >> is correct and any supplemental information/comments you may have? >> >> Thanks >> Paul Beaumont >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain