From mohamed.boucadair@orange.com Thu Dec 1 06:05: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 B311311E8147 for ; Thu, 1 Dec 2011 06:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcod1dM53nM1 for ; Thu, 1 Dec 2011 06:05:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E6A4511E8130 for ; Thu, 1 Dec 2011 06:05:17 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id AF25622C31E; Thu, 1 Dec 2011 15:05:16 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9738635C058; Thu, 1 Dec 2011 15:05:16 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 1 Dec 2011 15:05:16 +0100 From: To: Flemming Andreasen , mmusic Date: Thu, 1 Dec 2011 15:05:14 +0100 Thread-Topic: [MMUSIC] Do We Need an ICE Alternative ? Thread-Index: AcyjlPoFBdR8xZfjSjyyj5ySeEMK+QMnMjYw Message-ID: <94C682931C08B048B7A8645303FDC9F35A8D05163C@PUEXCB1B.nanterre.francetelecom.fr> References: <4EC25FCC.6030702@cisco.com> In-Reply-To: <4EC25FCC.6030702@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.1.124521 Subject: Re: [MMUSIC] Do We Need an 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, 01 Dec 2011 14:05:18 -0000 Dear Flemming, all, As an input to this discussion, I just submitted an I-D identifying some IP= v6 use cases which motivate the need to define a new SDP attribute. These u= se cases cover both multicast and unicast. The I-D is available at: http://tools.ietf.org/html/draft-boucadair-mmusic-= ipv6-use-cases-00. Comments and questions are welcome. Cheers, Med =20 > -----Message d'origine----- > De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 > De la part de Flemming Andreasen > Envoy=E9 : mardi 15 novembre 2011 13:49 > =C0 : mmusic > Objet : [MMUSIC] Do We Need an ICE Alternative ? >=20 > Greetings >=20 > Over the past several years, the MMUSIC WG has developed and=20 > standardized ICE (RFC 5245) as the mechanism to enable NAT=20 > traversal and=20 > IPv4/IPv6 transition for Offer/Answer based protocols (such as SIP).=20 > Alternative NAT traversal mechanisms exist, and others have been=20 > proposed, however they have either been limited to specific=20 > deployment=20 > topologies (e.g. symmetric RTP or STUN by itself) or required=20 > some level=20 > of network support (e.g. an ALG of some sort). Similarly, for=20 > IPv4/IPv6=20 > transition, RFC 4091/4092 (ANAT) defined an alternative solution that=20 > was deprecated following MMUSIC and SIPPING WG discssion and=20 > consensus=20 > at IETF68 (in 2007): >=20 > http://www.ietf.org/proceedings/68/minutes/mmusic.txt > http://www.ietf.org/proceedings/68/minutes/sipping.txt >=20 > Several years have passed and we have been getting more=20 > implementation=20 > and deployment experience with ICE. However, we have also seen=20 > suggestions for alternative solutions, with recent examples including=20 > the ALTC draft for IPv4/IPv6 transition and the latching=20 > mechanism for=20 > NAT traversal: >=20 > Link to ALTC draft: > https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/ >=20 > Link to latching mechanism (Section 5.7 in old version=20 > of loopback=20 > draft): > http://tools.ietf.org/id/draft-ietf-mmusic-media-loopback-15.txt >=20 >=20 > Alternatives, that generally have a more limited scope than ICE, keep=20 > popping up every now and then, and it seems that at least some set of=20 > people are not happy with the current ICE solution. So, we=20 > would like to=20 > understand from the working group if there are issues with=20 > ICE and if we=20 > need to explore alternative solutions for NAT traversal and/or for=20 > IPv4/IPv6 transition. >=20 > Our goal as a standards organization is to enable interoperable=20 > products, and having multiple different standards for the=20 > same problem=20 > or multiple different standards for specific instances of a general=20 > problem is not conducive to that. If we have to revisit one of the=20 > standards for a given problem space, we ought to be careful and=20 > understand what are the issues that we have with that standard.=20 > Furthermore, if we are to come with alternative solutions for that=20 > problem space, we have to ensure a clear understanding of what has=20 > changed since the last time we created the standard, what are the new=20 > set of requirements to satisfy, and which of the old requirements no=20 > longer apply. >=20 > So, we would like to sense the WG for opinions in this matter >=20 > Thanks >=20 > Flemming and Miguel (MMUSIC chairs) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From miguel.a.garcia@ericsson.com Thu Dec 1 10:01:53 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 7CC4211E827E for ; Thu, 1 Dec 2011 10:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUGRCQIIZeUy for ; Thu, 1 Dec 2011 10:01:52 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5194111E8269 for ; Thu, 1 Dec 2011 10:01:49 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-78-4ed7c10c03e1 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AB.35.23425.B01C7DE4; Thu, 1 Dec 2011 19:01:48 +0100 (CET) Received: from [159.107.51.81] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Dec 2011 19:01:47 +0100 Message-ID: <4ED7C10A.3090906@ericsson.com> Date: Thu, 1 Dec 2011 19:01:46 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: OKUMURA Shinji References: <20111024175730.13367.80904.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-04.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: Thu, 01 Dec 2011 18:01:53 -0000 Hi Shinji, my replies (as an individual). I am also copying Ali, since he is editing the draft. On 30/11/2011 10:34, OKUMURA Shinji wrote: > Hi, > > I have some questions concerning draft-ietf-mmusic-rfc4566bis-04. > > [Page 25] > "If the sub-field is "udp" the sub-fields MUST > reference a media type describing the format under the "audio", > "video", "text", "application", or "message" top-level media > types. The media type registration SHOULD define the packet > format for use with UDP transport." > > Q1. In this document, there are some "media type", > "top-level media content types", "top-level content type" > and "top-level media types". > > Which do these mean "MIME media type" or "SDP media type"? > Or do the both of two have the same meaning? > I think these are ambiguous expressions. I think in the past the original term was MIME type, but since it was not only used for e-mail, that old term has been nowadays being replaced by "media types". A media type is composed of a "top-level media type", such as "audio", or "video", and a "subtype", such as "G729" or "iLBC". Sometimes, the "top-level media type" is also known as "Content type", or more simply, "type". I agree with you that the draft should be coherent with the terminology. I suggest to avoid the word "MIME". And I suggest to pick one term for the "top-level media type", I don't have a strong preference for one. > > Q2. As for the "audio", "video", "text", "application", or "message" > top-level media types, where is the definition of the packet > format for use with UDP transport? > Why is it necessary for new media types? I believe "audio" and "video" usually use the RTP/AVP as the transport protocol. So, these days we don't send "audio" or "video" directly over UDP, something that will imply to define the packet format. Instead, we send audio and video over RTP, following the audio video profile defined in RFC 3551. Other media types, such as "message", may use other transport protocols. This is the case when MSRP is used as a transport protocol. This is necessary for any media type, it is not enough to say that you are going to send the media over UDP, but you also need to define the packet format. > > [Page 36] > 8.2.3. Media Formats ("fmt") > "For the "udp" protocol, new formats SHOULD be registered. Use of an > existing media subtype for the format is encouraged. If no media > subtype exists, it is RECOMMENDED that a suitable one be registered > through the IETF process [RFC4288] by production of, or reference to, > a standards-track RFC that defines the transport protocol for the > format." > > Q3. When a new media format(such as t38) is registered, > why should we define a new format for "udp" protocol? > IMHO all media format don't need the "udp" protocol. I understand the sentence a bit different. I think the sentence wants to say that if you are going to write "udp" in the field of the "m=" line, then you need to register the format, it is hasn't been done it yet. So, it does not say that every format should use UDP, but the other way round. BR, Miguel > > Regards, > Shinji > > internet-drafts@ietf.org > Mon, 24 Oct 2011 10:57:30 -0700 >> 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. >> >> Title : SDP: Session Description Protocol >> Author(s) : Mark Handley >> Van Jacobson >> Colin Perkins >> Ali Begen >> Filename : draft-ietf-mmusic-rfc4566bis-04.txt >> Pages : 49 >> Date : 2011-10-24 >> >> This memo defines the Session Description Protocol (SDP). SDP is >> intended for describing multimedia sessions for the purposes of >> session announcement, session invitation, and other forms of >> multimedia session initiation. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-04.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-rfc4566bis-04.txt > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From simon.perreault@viagenie.ca Thu Dec 1 10:18: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 CC04A21F91B3 for ; Thu, 1 Dec 2011 10:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPulNy6PD5es for ; Thu, 1 Dec 2011 10:18:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 258C421F91AD for ; Thu, 1 Dec 2011 10:18:33 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 633E820D0B; Thu, 1 Dec 2011 13:18:02 -0500 (EST) Message-ID: <4ED7C4D9.2050303@viagenie.ca> Date: Thu, 01 Dec 2011 13:18:01 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <4EC25FCC.6030702@cisco.com> <94C682931C08B048B7A8645303FDC9F35A8D05163C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F35A8D05163C@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Do We Need an 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, 01 Dec 2011 18:18:33 -0000 On 2011-12-01 09:05, mohamed.boucadair@orange.com wrote: > As an input to this discussion, I just submitted an I-D identifying some IPv6 > use cases which motivate the need to define a new SDP attribute. These use > cases cover both multicast and unicast. > > The I-D is available at: > http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases-00. VERY interesting read, thank you. I think one important thing missing is one small paragraph for each use case starting with "ICE(-lite) does not solve the problem because ..." This information is necessary to conclude that an ICE alternative would be needed. Thanks, 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 iesg-secretary@ietf.org Thu Dec 1 10:33: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 5307E1F0C6D; Thu, 1 Dec 2011 10:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuUfoYZtOGRP; Thu, 1 Dec 2011 10:33:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9522D1F0C76; Thu, 1 Dec 2011 10:33:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111201183337.22171.12298.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2011 10:33:37 -0800 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'TCP Candidates with Interactive Connectivity Establishment (ICE)' to Proposed Standard (draft-ietf-mmusic-ice-tcp-16.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: Thu, 01 Dec 2011 18:33:38 -0000 The IESG has approved the following document: - 'TCP Candidates with Interactive Connectivity Establishment (ICE)' (draft-ietf-mmusic-ice-tcp-16.txt) as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-tcp/ Technical Summary 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. Working Group Summary This document is a product of the MMUSIC WG. The document has been in progress for a while with significant Working Group interest, contribution and review. There are no controversial issues. Document Quality The document has received significant review and the quality is good. The chairs are aware of multiple implementations of the mechanism. Personnel Flemming Andreasen is the document's shepherd. Gonzalo Camarillo is the responsible AD. From mohamed.boucadair@orange.com Thu Dec 1 11:00: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 5F91F1F0C54 for ; Thu, 1 Dec 2011 11:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7lkZT1mq7H4 for ; Thu, 1 Dec 2011 11:00:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB131F0C4A for ; Thu, 1 Dec 2011 11:00:14 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2A0DF22C406; Thu, 1 Dec 2011 20:00:12 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 108CF35C045; Thu, 1 Dec 2011 20:00:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 1 Dec 2011 20:00:11 +0100 From: To: Simon Perreault Date: Thu, 1 Dec 2011 20:00:11 +0100 Thread-Topic: [MMUSIC] Do We Need an ICE Alternative ? Thread-Index: AcywVZM3+9lA9IHRRa+w3ceZ2S3ozAABNO7q Message-ID: <94C682931C08B048B7A8645303FDC9F35A8D127D23@PUEXCB1B.nanterre.francetelecom.fr> References: <4EC25FCC.6030702@cisco.com> <94C682931C08B048B7A8645303FDC9F35A8D05163C@PUEXCB1B.nanterre.francetelecom.fr>, <4ED7C4D9.2050303@viagenie.ca> In-Reply-To: <4ED7C4D9.2050303@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.1.173314 Cc: Flemming Andreasen , mmusic Subject: [MMUSIC] RE : Do We Need an 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, 01 Dec 2011 19:00:15 -0000 Hi Simon, Thank you for reading the draft. For sure, I can add some text for that purpose: the main argument is ICE-li= te MUST respond to STUN messages. Would it be sufficient to add a pointer = to http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02 which exp= lains why a lite "ICE-lite" is needed?=20 I will need then to add some text to explain why micro-lite is not sufficie= nt: * There is no need to adopt the ICE synthax since there is no plan to have = ICE in those deployments * micro -lite uses some dummy values ufrag and password but this is not com= pliant with RFC5245 (The ice-ufrag and ice-pwd attributes MUST be chosen ra= ndomly) * the SDP offer is lengthy: risk for fragmented SIP packets Cheers, Med ________________________________________ De : Simon Perreault [simon.perreault@viagenie.ca] Date d'envoi : jeudi 1 d=E9cembre 2011 19:18 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Flemming Andreasen; mmusic Objet : Re: [MMUSIC] Do We Need an ICE Alternative ? On 2011-12-01 09:05, mohamed.boucadair@orange.com wrote: > As an input to this discussion, I just submitted an I-D identifying some = IPv6 > use cases which motivate the need to define a new SDP attribute. These us= e > cases cover both multicast and unicast. > > The I-D is available at: > http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases-00. VERY interesting read, thank you. I think one important thing missing is one small paragraph for each use cas= e starting with "ICE(-lite) does not solve the problem because ..." This information is necessary to conclude that an ICE alternative would be = needed. Thanks, 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 simon.perreault@viagenie.ca Thu Dec 1 11:15:31 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 8C86421F90EB for ; Thu, 1 Dec 2011 11:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2e+w8sNyBNt for ; Thu, 1 Dec 2011 11:15:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id AC23A21F90D0 for ; Thu, 1 Dec 2011 11:15:30 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 133D320D0B; Thu, 1 Dec 2011 14:15:00 -0500 (EST) Message-ID: <4ED7D233.9030205@viagenie.ca> Date: Thu, 01 Dec 2011 14:14:59 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <4EC25FCC.6030702@cisco.com> <94C682931C08B048B7A8645303FDC9F35A8D05163C@PUEXCB1B.nanterre.francetelecom.fr>, <4ED7C4D9.2050303@viagenie.ca> <94C682931C08B048B7A8645303FDC9F35A8D127D23@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F35A8D127D23@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] RE : Do We Need an 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, 01 Dec 2011 19:15:31 -0000 On 2011-12-01 14:00, mohamed.boucadair@orange.com wrote: > the main argument is ICE-lite > MUST respond to STUN messages. Right, this is what I expected. Why is it a problem that ICE-lite MUST respond to STUN messages? It has been stated before that the SHA-1 computation is too heavy. Is this the problem you're facing? > Would it be sufficient to add a pointer to > http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02 which explains > why a lite "ICE-lite" is needed? Well, it doesn't exactly answer the question. It says: However support for ICE or ICE- Lite, which is a subset of ICE, is over complex for scenarios in which a transition mechanism is needed without the need to use ICE for NAT traversal and connectivity checking. ICE-Lite too complex? Really? What part is complex? ICE-Lite is basically ANAT++ bundled with a STUN server. 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 mohamed.boucadair@orange.com Fri Dec 2 00:13:07 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 ADE2A11E807F for ; Fri, 2 Dec 2011 00:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkQ-KDAboIPE for ; Fri, 2 Dec 2011 00:13:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3B36011E80A6 for ; Fri, 2 Dec 2011 00:13:03 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id CED3F324A68; Fri, 2 Dec 2011 09:13:01 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B5B4735C045; Fri, 2 Dec 2011 09:13:01 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 2 Dec 2011 09:13:01 +0100 From: To: Simon Perreault Date: Fri, 2 Dec 2011 09:13:01 +0100 Thread-Topic: RE : [MMUSIC] Do We Need an ICE Alternative ? Thread-Index: AcywXjl3ecU80CSDSRmw9qlcJgEb5gAaOvjA Message-ID: <94C682931C08B048B7A8645303FDC9F35A8D051811@PUEXCB1B.nanterre.francetelecom.fr> References: <4EC25FCC.6030702@cisco.com> <94C682931C08B048B7A8645303FDC9F35A8D05163C@PUEXCB1B.nanterre.francetelecom.fr>, <4ED7C4D9.2050303@viagenie.ca> <94C682931C08B048B7A8645303FDC9F35A8D127D23@PUEXCB1B.nanterre.francetelecom.fr> <4ED7D233.9030205@viagenie.ca> In-Reply-To: <4ED7D233.9030205@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.2.65414 Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] RE : Do We Need an 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: Fri, 02 Dec 2011 08:13:07 -0000 Re-, What is needed for the use cases described in the I-D is an ANAT++ which is= simple, backward compatible, does not increase the length of SDP bodies an= d does not require connectivity checks at all (some implementers already re= ported performance issues related to SHA-1 computation, issues with timers,= issue with some services such as Fax, interaction between RTP and ICE, etc= .). This mechanism must avoid session failure when legacy service elements = are involved. BTW, for the multicast case, if more than one receiver are ICE-enabled, wha= t would be their behaviour? Cheers, Med=20 > -----Message d'origine----- > De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 > Envoy=E9 : jeudi 1 d=E9cembre 2011 20:15 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : Flemming Andreasen; mmusic > Objet : Re: RE : [MMUSIC] Do We Need an ICE Alternative ? >=20 > On 2011-12-01 14:00, mohamed.boucadair@orange.com wrote: > > the main argument is ICE-lite > > MUST respond to STUN messages. >=20 > Right, this is what I expected. >=20 > Why is it a problem that ICE-lite MUST respond to STUN messages? >=20 > It has been stated before that the SHA-1 computation is too=20 > heavy. Is this the=20 > problem you're facing? >=20 > > Would it be sufficient to add a pointer to > >=20 > http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02 > which explains > > why a lite "ICE-lite" is needed? >=20 > Well, it doesn't exactly answer the question. It says: >=20 > However support for ICE or ICE- > Lite, which is a subset of ICE, is over complex for scenarios in > which a transition mechanism is needed without the need to use ICE > for NAT traversal and connectivity checking. >=20 > ICE-Lite too complex? Really? What part is complex? >=20 > ICE-Lite is basically ANAT++ bundled with a STUN server. >=20 > Simon > --=20 > 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 shinji.okumura@softfront.jp Fri Dec 2 02:10:17 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 445C521F9918 for ; Fri, 2 Dec 2011 02:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.268 X-Spam-Level: X-Spam-Status: No, score=-99.268 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_64=0.6, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V54c5U5+o8x for ; Fri, 2 Dec 2011 02:10:16 -0800 (PST) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by ietfa.amsl.com (Postfix) with ESMTP id 544F321F9917 for ; Fri, 2 Dec 2011 02:10:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 339AF42803E; Fri, 2 Dec 2011 19:10:09 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkhZPR7Dm9T4; Fri, 2 Dec 2011 19:10:09 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 10BA942803D; Fri, 2 Dec 2011 19:10:08 +0900 (JST) From: OKUMURA Shinji To: "Miguel A. Garcia" Date: Fri, 02 Dec 2011 19:10:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.70 (WinNT,502) In-Reply-To: <4ED7C10A.3090906@ericsson.com> References: <20111024175730.13367.80904.idtracker@ietfa.amsl.com> <4ED7C10A.3090906@ericsson.com> Message-Id: <11CCB0DA91FA7Eshinji.okumura@softfront.jp> Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-04.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: Fri, 02 Dec 2011 10:10:17 -0000 Hi Miguel, thank you so much for your reply. "Miguel A. Garcia" Thu, 1 Dec 2011 19:01:46 +0100 >Hi Shinji, > >my replies (as an individual). I am also copying Ali, since he is editing >the draft. > >On 30/11/2011 10:34, OKUMURA Shinji wrote: >> Hi, >> >> I have some questions concerning draft-ietf-mmusic-rfc4566bis-04. >> >> [Page 25] >> "If the sub-field is "udp" the sub-fields MUST >> reference a media type describing the format under the "audio", >> "video", "text", "application", or "message" top-level media >> types. The media type registration SHOULD define the packet >> format for use with UDP transport." >> >> Q1. In this document, there are some "media type", >> "top-level media content types", "top-level content type" >> and "top-level media types". >> >> Which do these mean "MIME media type" or "SDP media type"? >> Or do the both of two have the same meaning? >> I think these are ambiguous expressions. > > >I think in the past the original term was MIME type, but since it was not >only used for e-mail, that old term has been nowadays being replaced by >"media types". > >A media type is composed of a "top-level media type", such as "audio", or >"video", and a "subtype", such as "G729" or "iLBC". Sometimes, the >"top-level media type" is also known as "Content type", or more simply, >"type". > >I agree with you that the draft should be coherent with the terminology. >I suggest to avoid the word "MIME". And I suggest to pick one term for >the "top-level media type", I don't have a strong preference for one. I think it may not be necessary to avoid the word "MIME". IIUC some of "media type" in this draft mean top-level "MIME" media type that is registered with IANA. >> Q2. As for the "audio", "video", "text", "application", or "message" >> top-level media types, where is the definition of the packet >> format for use with UDP transport? >> Why is it necessary for new media types? > >I believe "audio" and "video" usually use the RTP/AVP as the transport >protocol. So, these days we don't send "audio" or "video" directly over >UDP, something that will imply to define the packet format. Instead, we >send audio and video over RTP, following the audio video profile defined >in RFC 3551. > >Other media types, such as "message", may use other transport protocols. >This is the case when MSRP is used as a transport protocol. therefore, as for the "audio", "video", "text", "application", or "message", the packet format for the sub-field "udp" is not defined. As a consequence I think the 1st sentence is needless. >This is necessary for any media type, it is not enough to say that you >are going to send the media over UDP, but you also need to define the >packet format. When we register new sub-fields for the sub-field "udp", it is necessary to define the packet format. But, when we register only SDP media type without "proto" nor "fmt", it is meaningless and impossible to define the packet format for use with "udp". As a consequence I think the 2nd sentence is needless. Basically the packet format depends on both of and . And there is no reason for giving special treatment only to "udp". >> [Page 36] >> 8.2.3. Media Formats ("fmt") >> "For the "udp" protocol, new formats SHOULD be registered. Use of an >> existing media subtype for the format is encouraged. If no media >> subtype exists, it is RECOMMENDED that a suitable one be registered >> through the IETF process [RFC4288] by production of, or reference to, >> a standards-track RFC that defines the transport protocol for the >> format." >> >> Q3. When a new media format(such as t38) is registered, >> why should we define a new format for "udp" protocol? >> IMHO all media format don't need the "udp" protocol. > >I understand the sentence a bit different. I think the sentence wants to >say that if you are going to write "udp" in the field of the "m=" >line, then you need to register the format, it is hasn't been done it >yet. So, it does not say that every format should use UDP, but the other >way round. When new media format is used over the field "udp", it is necessary. I see. Regards, Shinji >BR, > > Miguel >> >> internet-drafts@ietf.org >> Mon, 24 Oct 2011 10:57:30 -0700 >>> 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. >>> >>> Title : SDP: Session Description Protocol >>> Author(s) : Mark Handley >>> Van Jacobson >>> Colin Perkins >>> Ali Begen >>> Filename : draft-ietf-mmusic-rfc4566bis-04.txt >>> Pages : 49 >>> Date : 2011-10-24 >>> >>> This memo defines the Session Description Protocol (SDP). SDP is >>> intended for describing multimedia sessions for the purposes of >>> session announcement, session invitation, and other forms of >>> multimedia session initiation. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-04.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-rfc4566bis-04.txt >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > >-- >Miguel A. Garcia >+34-91-339-3608 >Ericsson Spain From gsalguei@cisco.com Sun Dec 4 17:26: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 76B3B21F8AE1 for ; Sun, 4 Dec 2011 17:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0198r1d2nD6L for ; Sun, 4 Dec 2011 17:26:20 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id E021E21F8AD3 for ; Sun, 4 Dec 2011 17:26:19 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB51QIYb025702 for ; Sun, 4 Dec 2011 20:26:18 -0500 (EST) Received: from rtp-gsalguei-8712.cisco.com (rtp-gsalguei-8712.cisco.com [10.116.61.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB51QHFX018646; Sun, 4 Dec 2011 20:26:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--1003689832 From: Gonzalo Salgueiro In-Reply-To: <1D062974A4845E4D8A343C65380492020513F329@XMB-BGL-414.cisco.com> Date: Sun, 4 Dec 2011 20:26:17 -0500 Message-Id: References: <1D062974A4845E4D8A343C65380492020513F329@XMB-BGL-414.cisco.com> To: Muthu ArulMozhi Perumal (mperumal) X-Mailer: Apple Mail (2.1084) Cc: mmusic Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-media-path-middleboxes-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, 05 Dec 2011 01:26:20 -0000 --Apple-Mail-2--1003689832 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Muthu -=20 Please forgive the delayed response, but I have been buried under work = with some of my new responsibilities at work. I am getting ready to = release the new version of this draft and had a quick question about = your one major comment. On Mar 29, 2011, at 9:21 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > Overall this draft looks to be in a good shape. > =20 > I've one major comment. Similar to REC #2 in section 7, it would be = desirable to have a recommendation that the middlebox present on the = media path allow at least a nominal amount of traffic to be exchanged = between endpoints for a small duration of time (say, one RTT) after the = middlebox receives a message from theMIDCOM agent that indicates the = media session being terminated. This will ensure that any transit = signaling packets on the media path exchanged during the session = termination, like RTCP Bye packets, pass through the middle box. > =20 I think I understand the intent of this recommendation and think it = might be useful to address specifically. Where did you think this text = should be added ? Regards, Gonzalo --Apple-Mail-2--1003689832 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Muthu - 

Please forgive the = delayed response, but I have been buried under work with some of my new = responsibilities at work.  I am getting ready to release the new = version of this draft and had a quick question about your one major = comment.


On Mar 29, 2011, at 9:21 = AM, Muthu ArulMozhi Perumal (mperumal) wrote:

Overall this draft looks to be in a good = shape.
 
I've one major comment. Similar to REC #2 in section 7, it would = be desirable to have a recommendation that the middlebox present on the media path = allow at least a nominal amount of traffic to be exchanged between = endpoints for a small duration of time (say, one RTT) after the middlebox receives a message from = theMIDCOM agent that indicates the = media session being terminated. This will ensure that any transit = signaling packets on the media path exchanged during the session = termination, like RTCP Bye packets, pass through = the middle box.
In-Reply-To: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues Thread-Index: Acyvc2RtwWVYX+hjQRKCp5qjF7/iQQEC5eoQ References: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> From: "Charles Eckel (eckelcu)" To: "Jochen Issing" , , X-OriginalArrivalTime: 05 Dec 2011 19:02:33.0894 (UTC) FILETIME=[72225460:01CCB380] Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues 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, 05 Dec 2011 19:02:37 -0000 Hi Jochen, I am not that familiar with the details of the variation modes. If you want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. and HE-AACv2, it seems you could include multiple payload types in the m-line, and then specify the corresponding fmtp parameters for each. Is there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2 within a single payload type? Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Jochen Issing > Sent: Wednesday, November 30, 2011 7:18 AM > To: payload@ietf.org; mmusic@ietf.org > Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues >=20 > Dear experts, >=20 > I need to double-apologize before posting our findings: > 1) for cross-posting, as I do not know, where this issue has its exact home, which is hopefully not a > response killer. > 2) for the long mail, even though I tried to keep it short. >=20 > Now, here's the actual request: >=20 > We are referring to RFC3640 SDP fields only, as this is most often the stumbling block. Let's use the > following example: >=20 > m=3Daudio 49170 RTP/AVP 96 > a=3Drtpmap:96 mpeg4-generic/48000/2 > a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; config=3D1190; sizeLength=3D13; > indexLength=3D3; indexDeltaLength=3D3; constantDuration=3D1024 >=20 > The fields of interest are in the fmtp line: 'profile-level-id' and 'config'. > In contrast to other codecs, e.g. G.XXX, AAC integrates many different types of sub codecs, which are > identified using the Audio Object Type (AOT). The AOT and some additional (codec internal) information > is stored in the Audio Specific Config (ASC), which is conveyed in the 'config' field. > The 'profile-level-id' points to a profile with a certain level. The profile comprises a set of one or > more AOTs and the level restricts the stream to a maximum sample rate and/or number channels. The > profile-level-ids, as specified in ISO 14496-3, are partly hierarchical and most often ambiguous. >=20 > Suppose the classic SIP use case that two clients want to exchange their codec capabilities. > The first client specifies some payload types in the SDP part of SIP INVITE which can differ in their > profile-level-id and/or config. > For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To signal these codecs/AOTs he could > either indicate all formats with the same profile-level-id (e.g., 48), which includes all these AOTs > or he could specify profile-level-ids, that are most 'narrow' to the actual specified AOT or he could > even mix this principle. > On the other hand, the ASC might use implicit signaling, explicit backwards-compatible, or explicit > non-backwards-compatible. > Bobs main problem would be to determine, whether the profile-level-id was chosen to really identify > the necessary (and applied) AAC AOTs or if he could rely on the ASC or if the profile-level-id was > just brawling about the encoders feature. >=20 > To clean up this mess of opportunities, we would like to specify a non-ambiguous way to utilize the > profile-level-id and config fields appropriately and provide a guide on how to accomplish clean and > easier signalization and thus improve interoperability. >=20 >=20 > But first of all we would like to make sure, that you agree to this problem statement or do we miss > something here? > Comments are as always highly appreciated. >=20 > Best Regards, > -- > jochen >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From gunnar.hellstrom@omnitor.se Mon Dec 5 13:19:09 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 272A41F0C9B for ; Mon, 5 Dec 2011 13:19:09 -0800 (PST) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzrxnnI6gly1 for ; Mon, 5 Dec 2011 13:19:08 -0800 (PST) Received: from vsp-outgoing3.binero.net (vsp-outgoing3.binero.net [193.17.218.162]) by ietfa.amsl.com (Postfix) with SMTP id 1C61D1F0C88 for ; Mon, 5 Dec 2011 13:19:06 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing3.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 5 Dec 2011 22:18:57 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 4F44E3A137 for ; Mon, 5 Dec 2011 22:18:57 +0100 (CET) Message-ID: <4EDD3549.7060908@omnitor.se> Date: Mon, 05 Dec 2011 22:19:05 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> <4EAA080D.8070801@cisco.com> <945EE41C-0068-4CBE-8797-1DF8C7F2BDC0@acmepacket.com> <4EAEF66D.3030007@cisco.com> <4EAF8E01.4010807@omnitor.se> <4EB1ADFD.4030501@cisco.com> In-Reply-To: <4EB1ADFD.4030501@cisco.com> Content-Type: multipart/alternative; boundary="------------060106060604000609090004" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 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, 05 Dec 2011 21:19:09 -0000 This is a multi-part message in MIME format. --------------060106060604000609090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I rechecked the proposal to use RFC 6263 to create and maintain NAT bindings for loopback if ICE is not used. It is apparent from the introduction of RFC 6263 that it is intended to both create initial NAT mapping and maintain it. Here is a sentence about the intention of RFC 6263: ".....This introduces a derived requirement for applications engaged in a multimedia session involving NAT traversal: they need to generate a minimum of flow activity in order to create NAT mappings and maintain them. When applied to applications using the Real-time Transport Protocol (RTP) [RFC3550 <./rfc3550>], the RTP media stream packets themselves normally fulfill this requirement. However, there exist some cases where RTP does not generate the minimum required flow activity. " The text continues indicating that RFC 6263 solves these situations. So I think a reference to RFC 6263 would safely resolve the issue about the missing "priming" mechanism raisede by Hadriel on 5, October. Gunnar -------------------------------------------------------------------------- Flemming Andreasen skrev 2011-11-02 21:54: > That might be another option (multiplex RTP and RTCP with RTCP as the > keep-alive mechanism), however I think you still have the issue of > sending the intial packets to punch a hole. > > -- Flemming > > On 11/1/11 2:13 AM, Gunnar Hellström wrote: >> Can rfc6263 RTP Keep-alive be referenced for the non-ICE case? >> >> /Gunnar >> >> >> Flemming Andreasen skrev 2011-10-31 20:26: >>> >>> >>> On 10/27/11 11:36 PM, Hadriel Kaplan wrote: >>>> On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote: >>>> >>>>>> As I understand it, your concern is we (1) don't have an RFC >>>>>> defining how NAT traversal works if not with ICE, (2) don't want >>>>>> to define a "primer" thingy just for this one loopback draft, and >>>>>> (3) are dizzy from of going around in circles. :) >>>>>> >>>>> Right, and >>>>> (4) If we are not happy with ICE as our IETF NAT traversal >>>>> mechanism, for whatever reason, then we as WG need to be explicit >>>>> about that and figure out a way of addressing it in general - not >>>>> just in the form of and as part of some loopback specific >>>>> discussion (or we'll have another one of these threads when the >>>>> next draft comes along that needs to work behind NATs, but doesn't >>>>> really want to do ICE). >>>> While I and some others have noted on multiple occasions that ICE >>>> isn't the utopian solution it's cracked up to be, it appears so far >>>> we're still in the minority in the WG. >>>> >>>> I did put in text in: >>>> http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00 >>>> in Appendix A.2, of an example why ICE can't be used for some >>>> people - but that's sort of an obscure reference because the point >>>> of the draft is about IPv4/v6 not NATs. >>> Would it make sense to include this as part of John Elwells ICE draft ? >>> >>>> There're other ICE-problem examples too, like in the Enterprise >>>> market where the IT guys want to force the media to go through >>>> their VPNs or stay inside and never reach the public Internet. >>>> >>>> But essentially media-loopback is the only case I've seen where >>>> there's a NAT problem to solve that isn't auto-handled by just >>>> normal RTP behavior and latching. The IPv4/v6 case isn't a NAT >>>> traversal problem per se, nor a latching one, but more of a need to >>>> indicate multiple address families in SDP, competing with the >>>> desire by some others in the WG that a connectivity check type >>>> thing happens because IPv6 isn't stable. >>>> >>>> >>>>>> My point in all this is to propose the following high-level >>>>>> straw-man: >>>>>> >>>>>> 1) We use the STUN Binding Indications as our primer packet >>>>>> format, by referencing STUN RFC. >>>>>> >>>>> Any reason we can't reference the ICE RFC and make it a "SHOULD" >>>>> implement ? >>>> How about this: "A UAC compliant with this document SHOULD >>>> implement [RFC5245], but MAY only implement section 10 of [RFC5245] >>>> with the additional rules noted in section X of this document if it >>>> does not use ICE for normal media sessions." >>>> >>>> And section X would have something like this: >>>> When a UAS loopback mirror receives an SDP Offer with >>>> media-loopback, if the UAS implements [RFC5245] then it follows ICE >>>> procedures, including fallback to just sending STUN Binding >>>> Indications per Section 10 of ICE if the received Offer did not >>>> indicate ICE or there is an ICE mismatch condition. If the UAS >>>> does not implement [RFC5245], then it MUST at least follow the >>>> procedures of Section 10 of [RFC5245] and send STUN Binding >>>> Indications. In all cases, even if ICE is not actively used, the >>>> existence of the media-loopback indication in SDP indicates the >>>> far-end is capable of receiving and ignoring STUN Binding >>>> Indications, and the local UAS MUST send such as per Section 10 of >>>> [RFC5245] as if the SDP contained a candidate line. This is to >>>> ensure some initial packets gets sent to the loopback source, to >>>> create NAT bindings or open Firewall pinholes along the path, since >>>> RTP is not generated by the loopback mirror until RTP is received. >>>> >>> >>> I'd like to hear more people commenting on this. My understanding of >>> ICE Section 5.1/10 in this case is that it's for keep-alives and >>> hence you wouldn't send these messages initially (which is not to >>> say that couldn't be changed when used with loopback - the question >>> is how it differs from "real" ICE then). >>> >>>>>> 3) We specify that the media-loopback indication in SDP means the >>>>>> loopback-source supports receiving and ignoring STUN Binding >>>>>> Indications, so that following Section 10 of RFC 5245 the mirror >>>>>> MUST send STUN not no-op or comfort noise. >>>>>> 4) We put some text in the loopback-source about sources MUST >>>>>> support ignoring received STUN Binding Indications, not depend on >>>>>> getting them, etc. >>>>>> >>>>> This seems like a way forward that would keep us consistent with >>>>> current ICE procedures. We probably need to explore it in more >>>>> detail (and I'd welcome more comments on this as well), but it >>>>> seems promising. One question is the frequency with which these >>>>> STUN Binding Requests would be sent ? >>>> The frequency is in section 10, but I assume you mean when >>>> "inactive" mode is used in media-loopback? That's a tough one. In >>>> a normal call there would be no RTP in that mode, and since the >>>> tester may want to test that mode to see if it is causing problems >>>> then I think the mirror shouldn't send STUN even then. :( >>> I believe Section 10 would only apply to keep-alives in the scenario >>> being considered here (and hence inactive mode is fine). The issue, >>> I believe, is that you need these STUN binding packets sent >>> initially to punch a hole through the NAT, and I don't believe the >>> current RFC 5245 by itself will give you that. >>> >>> -- Flemming >>> >>> >>>> -hadriel >>>> >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------060106060604000609090004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I rechecked the proposal to use RFC 6263 to create and maintain NAT bindings for loopback if ICE is not used.

It is apparent from the introduction of RFC 6263 that it is intended to both create initial NAT mapping and maintain it.

Here is a sentence about the intention of RFC 6263:
".....This introduces a derived requirement for applications engaged in a multimedia session involving NAT traversal: they need to generate a minimum of flow activity in order to create NAT mappings and maintain them. When applied to applications using the Real-time Transport Protocol (RTP) [RFC3550], the RTP media stream packets themselves normally fulfill this requirement. However, there exist some cases where RTP does not generate the minimum required flow activity. "

The text continues indicating that RFC 6263 solves these situations.

So I think a reference to RFC 6263 would safely resolve the issue about the missing "priming" mechanism raisede by Hadriel on 5, October.


Gunnar
--------------------------------------------------------------------------

Flemming Andreasen skrev 2011-11-02 21:54:
That might be another option (multiplex RTP and RTCP with RTCP as the keep-alive mechanism), however I think you still have the issue of sending the intial packets to punch a hole.

-- Flemming

On 11/1/11 2:13 AM, Gunnar Hellström wrote:
Can rfc6263   RTP Keep-alive be referenced for the non-ICE case?

/Gunnar


Flemming Andreasen skrev 2011-10-31 20:26:


On 10/27/11 11:36 PM, Hadriel Kaplan wrote:
On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote:

As I understand it, your concern is we (1) don't have an RFC defining how NAT traversal works if not with ICE, (2) don't want to define a "primer" thingy just for this one loopback draft, and (3) are dizzy from of going around in circles. :)

Right, and
(4) If we are not happy with ICE as our IETF NAT traversal mechanism, for whatever reason, then we as WG need to be explicit about that and figure out a way of addressing it in general - not just in the form of and as part of some loopback specific discussion (or we'll have another one of these threads when the next draft comes along that needs to work behind NATs, but doesn't really want to do ICE).
While I and some others have noted on multiple occasions that ICE isn't the utopian solution it's cracked up to be, it appears so far we're still in the minority in the WG.

I did put in text in:
http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00
in Appendix A.2, of an example why ICE can't be used for some people - but that's sort of an obscure reference because the point of the draft is about IPv4/v6 not NATs.
Would it make sense to include this as part of John Elwells ICE draft ?

  There're other ICE-problem examples too, like in the Enterprise market where the IT guys want to force the media to go through their VPNs or stay inside and never reach the public Internet.

But essentially media-loopback is the only case I've seen where there's a NAT problem to solve that isn't auto-handled by just normal RTP behavior and latching.  The IPv4/v6 case isn't a NAT traversal problem per se, nor a latching one, but more of a need to indicate multiple address families in SDP, competing with the desire by some others in the WG that a connectivity check type thing happens because IPv6 isn't stable.


My point in all this is to propose the following high-level straw-man:

1) We use the STUN Binding Indications as our primer packet format, by referencing STUN RFC.

Any reason we can't reference the ICE RFC and make it a "SHOULD" implement ?
How about this: "A UAC compliant with this document SHOULD implement [RFC5245], but MAY only implement section 10 of [RFC5245] with the additional rules noted in section X of this document if it does not use ICE for normal media sessions."

And section X would have something like this:
When a UAS loopback mirror receives an SDP Offer with media-loopback, if the UAS implements [RFC5245] then it follows ICE procedures, including fallback to just sending STUN Binding Indications per Section 10 of ICE if the received Offer did not indicate ICE or there is an ICE mismatch condition.  If the UAS does not implement [RFC5245], then it MUST at least follow the procedures of Section 10 of [RFC5245] and send STUN Binding Indications.  In all cases, even if ICE is not actively used, the existence of the media-loopback indication in SDP indicates the far-end is capable of receiving and ignoring STUN Binding Indications, and the local UAS MUST send such as per Section 10 of [RFC5245] as if the SDP contained a candidate line.  This is to ensure some initial packets gets sent to the loopback source, to create NAT bindings or open Firewall pinholes along the path, since RTP is not generated by the loopback mirror until RTP is received.


I'd like to hear more people commenting on this. My understanding of ICE Section 5.1/10 in this case is that it's for keep-alives and hence you wouldn't send these messages initially (which is not to say that couldn't be changed when used with loopback - the question is how it differs from "real" ICE then).

3) We specify that the media-loopback indication in SDP means the loopback-source supports receiving and ignoring STUN Binding Indications, so that following Section 10 of RFC 5245 the mirror MUST send STUN not no-op or comfort noise.
4) We put some text in the loopback-source about sources MUST support ignoring received STUN Binding Indications, not depend on getting them, etc.

This seems like a way forward that would keep us consistent with current ICE procedures. We probably need to explore it in more detail (and I'd welcome more comments on this as well), but it seems promising. One question is the frequency with which these STUN Binding Requests would be sent ?
The frequency is in section 10, but I assume you mean when "inactive" mode is used in media-loopback?  That's a tough one.  In a normal call there would be no RTP in that mode, and since the tester may want to test that mode to see if it is causing problems then I think the mirror shouldn't send STUN even then.  :(
I believe Section 10 would only apply to keep-alives in the scenario being considered here (and hence inactive mode is fine). The issue, I believe, is that you need these STUN binding packets sent initially to punch a hole through the NAT, and I don't believe the current RFC 5245 by itself will give you that.

-- Flemming


-hadriel



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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
--------------060106060604000609090004-- From iss@IEEE.ORG Mon Dec 5 14:50:55 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 C24AD21F86A0; Mon, 5 Dec 2011 14:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX3UbzsqNgz4; Mon, 5 Dec 2011 14:50:55 -0800 (PST) Received: from nesono.com (nesono.com [85.214.71.234]) by ietfa.amsl.com (Postfix) with ESMTP id D6E5B21F85F1; Mon, 5 Dec 2011 14:50:54 -0800 (PST) Received: from [192.168.178.27] (188-195-158-30-dynip.superkabel.de [188.195.158.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iss@nesono.com) by nesono.com (Postfix) with ESMTPSA id 7BC112B8022; Mon, 5 Dec 2011 23:50:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jochen Issing In-Reply-To: Date: Mon, 5 Dec 2011 23:50:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> To: "Charles Eckel (eckelcu)" X-Mailer: Apple Mail (2.1251.1) Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues 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, 05 Dec 2011 22:50:55 -0000 Hi Charles, thanks for your response! However, the issue we identified is somewhat = different: The problem already takes place with a single fmtp line: For example, one client indicates that it can (decode and) encode an AAC = stream using the config field in fmtp. The other side, receiving this information, = then must check its decoder, if it can decode the ASC and needs to setup its = encoder, so that it uses the very same ASC. The problem occurs at the encoder of the caller (the receiver of the = first SDP): It might not be possible with reasonable effort to get an encoder = creating the same ASC as given in SDP (encoders are in general not initialized using = an ASC). I hope, this explained our problem much clearer. Best, jochen On 05.12.2011, at 20:02, Charles Eckel (eckelcu) wrote: > Hi Jochen, >=20 > I am not that familiar with the details of the variation modes. If you > want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. = and > HE-AACv2, it seems you could include multiple payload types in the > m-line, and then specify the corresponding fmtp parameters for each. = Is > there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2 > within a single payload type? >=20 > Charles >=20 >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Jochen Issing >> Sent: Wednesday, November 30, 2011 7:18 AM >> To: payload@ietf.org; mmusic@ietf.org >> Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues >>=20 >> Dear experts, >>=20 >> I need to double-apologize before posting our findings: >> 1) for cross-posting, as I do not know, where this issue has its = exact > home, which is hopefully not a >> response killer. >> 2) for the long mail, even though I tried to keep it short. >>=20 >> Now, here's the actual request: >>=20 >> We are referring to RFC3640 SDP fields only, as this is most often = the > stumbling block. Let's use the >> following example: >>=20 >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 mpeg4-generic/48000/2 >> a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; > config=3D1190; sizeLength=3D13; >> indexLength=3D3; indexDeltaLength=3D3; constantDuration=3D1024 >>=20 >> The fields of interest are in the fmtp line: 'profile-level-id' and > 'config'. >> In contrast to other codecs, e.g. G.XXX, AAC integrates many = different > types of sub codecs, which are >> identified using the Audio Object Type (AOT). The AOT and some > additional (codec internal) information >> is stored in the Audio Specific Config (ASC), which is conveyed in = the > 'config' field. >> The 'profile-level-id' points to a profile with a certain level. The > profile comprises a set of one or >> more AOTs and the level restricts the stream to a maximum sample rate > and/or number channels. The >> profile-level-ids, as specified in ISO 14496-3, are partly > hierarchical and most often ambiguous. >>=20 >> Suppose the classic SIP use case that two clients want to exchange > their codec capabilities. >> The first client specifies some payload types in the SDP part of SIP > INVITE which can differ in their >> profile-level-id and/or config. >> For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To > signal these codecs/AOTs he could >> either indicate all formats with the same profile-level-id (e.g., = 48), > which includes all these AOTs >> or he could specify profile-level-ids, that are most 'narrow' to the > actual specified AOT or he could >> even mix this principle. >> On the other hand, the ASC might use implicit signaling, explicit > backwards-compatible, or explicit >> non-backwards-compatible. >> Bobs main problem would be to determine, whether the profile-level-id > was chosen to really identify >> the necessary (and applied) AAC AOTs or if he could rely on the ASC = or > if the profile-level-id was >> just brawling about the encoders feature. >>=20 >> To clean up this mess of opportunities, we would like to specify a > non-ambiguous way to utilize the >> profile-level-id and config fields appropriately and provide a guide > on how to accomplish clean and >> easier signalization and thus improve interoperability. >>=20 >>=20 >> But first of all we would like to make sure, that you agree to this > problem statement or do we miss >> something here? >> Comments are as always highly appreciated. >>=20 >> Best Regards, >> -- >> jochen >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic --=20 jochen From mike.severa@alcatel-lucent.com Mon Dec 5 15:28:40 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 4E3A61F0C35; Mon, 5 Dec 2011 15:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFX6O4ULIjy8; Mon, 5 Dec 2011 15:28:39 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6B21F8AB8; Mon, 5 Dec 2011 15:28:39 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pB5NSZVI025954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Dec 2011 17:28:36 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB5NSAHN014387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Dec 2011 17:28:35 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 5 Dec 2011 17:28:13 -0600 From: "Severa, Michael J (Mike)" To: Jochen Issing , "Charles Eckel (eckelcu)" Date: Mon, 5 Dec 2011 17:28:12 -0600 Thread-Topic: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues Thread-Index: AcyzoFuYc4j93X9LSH28/0OYEAD6/gAAh68u Message-ID: References: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> , In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "mmusic@ietf.org" , "payload@ietf.org" Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues 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, 05 Dec 2011 23:28:40 -0000 My personal feeling is that the ASC need not be identical in syntax, just i= n semantics (one of the unfortunate aspects of AAC-related signaling is tha= t there are a number of ways to signal the same bitstream). Another unfortu= nate aspect is that one of the options is to signal implicitly, which essen= tially means dont signal at all, rather 'detect' at decode time. That is ob= viously not useful for a capabilities exchange step.=20 I think there might also be other open questions surrounding ambiguities in= signaling AAC-LC/HE-AAC that should be worked through to generate a best o= r acceptable practices approach.=20 Two of the ones that jump out at me are: - the question of what timescale from the rtpmap line means when you intend= to be using HE-AAC in a 3640 environment (3GPP has explicitly indicated th= is should be sampling frequency of the underlying, 'core' AAC-LC portion of= an HE-AAC stream. I assume this is the same semantic in 3640 (though I did= nt notice it specified explicitly)). This question is probably only relevan= t in cases where the goal is to assume HE-AAC (something the multiple fmtp = line suggestion might be implying).=20 - how HE-AAC can be detected in implicit mode during negotiation (again, 3G= PP added an SBR-Enabled flag to the SDP to allow HE-AAC to be detected ahea= d of time even with implicit signaling, im not sure there is an analogous s= olution for 3640).=20 Both of these questions are probably irrelevant if implicit signaling is di= sallowed for HE-AAC (though in the first case that would require parsing th= e ASC during negotiation). Using multiple fmtp lines might be one way to 'd= isable' the implicit signaling requirement (since the backwards compatibili= ty concern associated with implicit signaling can be dealt with by an expli= cit AAC-LC-only ftmp (and rtpmap)line).=20 Sorry if that's a tangent.=20 thanks,=20 Mike ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Jochen= Issing [iss@IEEE.ORG] Sent: Monday, December 05, 2011 2:50 PM To: Charles Eckel (eckelcu) Cc: mmusic@ietf.org; payload@ietf.org Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues Hi Charles, thanks for your response! However, the issue we identified is somewhat diff= erent: The problem already takes place with a single fmtp line: For example, one client indicates that it can (decode and) encode an AAC st= ream using the config field in fmtp. The other side, receiving this information, then = must check its decoder, if it can decode the ASC and needs to setup its encoder, so that it uses the very same ASC. The problem occurs at the encoder of the caller (the receiver of the first = SDP): It might not be possible with reasonable effort to get an encoder creating = the same ASC as given in SDP (encoders are in general not initialized using an = ASC). I hope, this explained our problem much clearer. Best, jochen On 05.12.2011, at 20:02, Charles Eckel (eckelcu) wrote: > Hi Jochen, > > I am not that familiar with the details of the variation modes. If you > want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. and > HE-AACv2, it seems you could include multiple payload types in the > m-line, and then specify the corresponding fmtp parameters for each. Is > there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2 > within a single payload type? > > Charles > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Jochen Issing >> Sent: Wednesday, November 30, 2011 7:18 AM >> To: payload@ietf.org; mmusic@ietf.org >> Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues >> >> Dear experts, >> >> I need to double-apologize before posting our findings: >> 1) for cross-posting, as I do not know, where this issue has its exact > home, which is hopefully not a >> response killer. >> 2) for the long mail, even though I tried to keep it short. >> >> Now, here's the actual request: >> >> We are referring to RFC3640 SDP fields only, as this is most often the > stumbling block. Let's use the >> following example: >> >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 mpeg4-generic/48000/2 >> a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; > config=3D1190; sizeLength=3D13; >> indexLength=3D3; indexDeltaLength=3D3; constantDuration=3D1024 >> >> The fields of interest are in the fmtp line: 'profile-level-id' and > 'config'. >> In contrast to other codecs, e.g. G.XXX, AAC integrates many different > types of sub codecs, which are >> identified using the Audio Object Type (AOT). The AOT and some > additional (codec internal) information >> is stored in the Audio Specific Config (ASC), which is conveyed in the > 'config' field. >> The 'profile-level-id' points to a profile with a certain level. The > profile comprises a set of one or >> more AOTs and the level restricts the stream to a maximum sample rate > and/or number channels. The >> profile-level-ids, as specified in ISO 14496-3, are partly > hierarchical and most often ambiguous. >> >> Suppose the classic SIP use case that two clients want to exchange > their codec capabilities. >> The first client specifies some payload types in the SDP part of SIP > INVITE which can differ in their >> profile-level-id and/or config. >> For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To > signal these codecs/AOTs he could >> either indicate all formats with the same profile-level-id (e.g., 48), > which includes all these AOTs >> or he could specify profile-level-ids, that are most 'narrow' to the > actual specified AOT or he could >> even mix this principle. >> On the other hand, the ASC might use implicit signaling, explicit > backwards-compatible, or explicit >> non-backwards-compatible. >> Bobs main problem would be to determine, whether the profile-level-id > was chosen to really identify >> the necessary (and applied) AAC AOTs or if he could rely on the ASC or > if the profile-level-id was >> just brawling about the encoders feature. >> >> To clean up this mess of opportunities, we would like to specify a > non-ambiguous way to utilize the >> profile-level-id and config fields appropriately and provide a guide > on how to accomplish clean and >> easier signalization and thus improve interoperability. >> >> >> But first of all we would like to make sure, that you agree to this > problem statement or do we miss >> something here? >> Comments are as always highly appreciated. >> >> Best Regards, >> -- >> jochen >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic -- jochen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From iss@ieee.org Mon Dec 5 15:50: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 1FF961F0C38; Mon, 5 Dec 2011 15:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBgXtKExat2a; Mon, 5 Dec 2011 15:50:13 -0800 (PST) Received: from nesono.com (nesono.com [85.214.71.234]) by ietfa.amsl.com (Postfix) with ESMTP id BD76021F8AB9; Mon, 5 Dec 2011 15:50:10 -0800 (PST) Received: from macpro01.fritz.box (188-195-158-30-dynip.superkabel.de [188.195.158.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: iss@nesono.com) by nesono.com (Postfix) with ESMTPSA id F0E9A2B8022; Tue, 6 Dec 2011 00:49:43 +0100 (CET) Message-ID: <4EDD5894.9020100@ieee.org> Date: Tue, 06 Dec 2011 00:49:40 +0100 From: Jochen Issing User-Agent: Postbox 3.0.2 (Macintosh/20111203) MIME-Version: 1.0 To: "Severa, Michael J (Mike)" References: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "payload@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues 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, 05 Dec 2011 23:50:14 -0000 Hi Mike, as far as I understand the AAC codecs, ASCs of the same AOT (and channels and sample rate) are not necessarily 'compatible' to each other, especially when it comes to more recent codecs, like AAC-ELD, where critical information might be included in the ASC. Thus, for a uniform usage of ASCs, it should be bit-exact. I'm afraid the caller needs to add a payload type if he does not manage to reproduce the ASC indicated by the callee, which would be then used in one direction only. Regarding the signalization of SBR and PS (HE-AAC/HE-AACv2) you are right, that's another issue. However, with presence of SIP/SDP and offer/answer functionality, implicit and backwards-compatible signalization do not make sense at all IMHO. The legacy receiver can simply disregard the unsupported codecs. Anyhow, this is neither stated anywhere. Best, jochen Severa, Michael J (Mike) wrote: > My personal feeling is that the ASC need not be identical in syntax, just in semantics (one of the unfortunate aspects of AAC-related signaling is that there are a number of ways to signal the same bitstream). Another unfortunate aspect is that one of the options is to signal implicitly, which essentially means dont signal at all, rather 'detect' at decode time. That is obviously not useful for a capabilities exchange step. > > I think there might also be other open questions surrounding ambiguities in signaling AAC-LC/HE-AAC that should be worked through to generate a best or acceptable practices approach. > > Two of the ones that jump out at me are: > - the question of what timescale from the rtpmap line means when you intend to be using HE-AAC in a 3640 environment (3GPP has explicitly indicated this should be sampling frequency of the underlying, 'core' AAC-LC portion of an HE-AAC stream. I assume this is the same semantic in 3640 (though I didnt notice it specified explicitly)). This question is probably only relevant in cases where the goal is to assume HE-AAC (something the multiple fmtp line suggestion might be implying). > - how HE-AAC can be detected in implicit mode during negotiation (again, 3GPP added an SBR-Enabled flag to the SDP to allow HE-AAC to be detected ahead of time even with implicit signaling, im not sure there is an analogous solution for 3640). > > Both of these questions are probably irrelevant if implicit signaling is disallowed for HE-AAC (though in the first case that would require parsing the ASC during negotiation). Using multiple fmtp lines might be one way to 'disable' the implicit signaling requirement (since the backwards compatibility concern associated with implicit signaling can be dealt with by an explicit AAC-LC-only ftmp (and rtpmap)line). > > Sorry if that's a tangent. > > thanks, > > Mike > > ________________________________________ > From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Jochen Issing [iss@IEEE.ORG] > Sent: Monday, December 05, 2011 2:50 PM > To: Charles Eckel (eckelcu) > Cc: mmusic@ietf.org; payload@ietf.org > Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues > > Hi Charles, > > thanks for your response! However, the issue we identified is somewhat different: > > The problem already takes place with a single fmtp line: > For example, one client indicates that it can (decode and) encode an AAC stream using > the config field in fmtp. The other side, receiving this information, then must > check its decoder, if it can decode the ASC and needs to setup its encoder, > so that it uses the very same ASC. > > The problem occurs at the encoder of the caller (the receiver of the first SDP): > It might not be possible with reasonable effort to get an encoder creating the > same ASC as given in SDP (encoders are in general not initialized using an ASC). > > I hope, this explained our problem much clearer. > Best, > > jochen > > On 05.12.2011, at 20:02, Charles Eckel (eckelcu) wrote: > >> Hi Jochen, >> >> I am not that familiar with the details of the variation modes. If you >> want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. and >> HE-AACv2, it seems you could include multiple payload types in the >> m-line, and then specify the corresponding fmtp parameters for each. Is >> there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2 >> within a single payload type? >> >> Charles >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Jochen Issing >>> Sent: Wednesday, November 30, 2011 7:18 AM >>> To: payload@ietf.org; mmusic@ietf.org >>> Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues >>> >>> Dear experts, >>> >>> I need to double-apologize before posting our findings: >>> 1) for cross-posting, as I do not know, where this issue has its exact >> home, which is hopefully not a >>> response killer. >>> 2) for the long mail, even though I tried to keep it short. >>> >>> Now, here's the actual request: >>> >>> We are referring to RFC3640 SDP fields only, as this is most often the >> stumbling block. Let's use the >>> following example: >>> >>> m=audio 49170 RTP/AVP 96 >>> a=rtpmap:96 mpeg4-generic/48000/2 >>> a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; >> config=1190; sizeLength=13; >>> indexLength=3; indexDeltaLength=3; constantDuration=1024 >>> >>> The fields of interest are in the fmtp line: 'profile-level-id' and >> 'config'. >>> In contrast to other codecs, e.g. G.XXX, AAC integrates many different >> types of sub codecs, which are >>> identified using the Audio Object Type (AOT). The AOT and some >> additional (codec internal) information >>> is stored in the Audio Specific Config (ASC), which is conveyed in the >> 'config' field. >>> The 'profile-level-id' points to a profile with a certain level. The >> profile comprises a set of one or >>> more AOTs and the level restricts the stream to a maximum sample rate >> and/or number channels. The >>> profile-level-ids, as specified in ISO 14496-3, are partly >> hierarchical and most often ambiguous. >>> Suppose the classic SIP use case that two clients want to exchange >> their codec capabilities. >>> The first client specifies some payload types in the SDP part of SIP >> INVITE which can differ in their >>> profile-level-id and/or config. >>> For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To >> signal these codecs/AOTs he could >>> either indicate all formats with the same profile-level-id (e.g., 48), >> which includes all these AOTs >>> or he could specify profile-level-ids, that are most 'narrow' to the >> actual specified AOT or he could >>> even mix this principle. >>> On the other hand, the ASC might use implicit signaling, explicit >> backwards-compatible, or explicit >>> non-backwards-compatible. >>> Bobs main problem would be to determine, whether the profile-level-id >> was chosen to really identify >>> the necessary (and applied) AAC AOTs or if he could rely on the ASC or >> if the profile-level-id was >>> just brawling about the encoders feature. >>> >>> To clean up this mess of opportunities, we would like to specify a >> non-ambiguous way to utilize the >>> profile-level-id and config fields appropriately and provide a guide >> on how to accomplish clean and >>> easier signalization and thus improve interoperability. >>> >>> >>> But first of all we would like to make sure, that you agree to this >> problem statement or do we miss >>> something here? >>> Comments are as always highly appreciated. >>> >>> Best Regards, >>> -- >>> jochen >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic > > -- > jochen > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- jochen From ramesh3184@gmail.com Tue Dec 6 05:35:42 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 DADB621F8B21 for ; Tue, 6 Dec 2011 05:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSCHW7UEouUk for ; Tue, 6 Dec 2011 05:35:42 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42221F8B20 for ; Tue, 6 Dec 2011 05:35:41 -0800 (PST) Received: by qcsf15 with SMTP id f15so2633293qcs.31 for ; Tue, 06 Dec 2011 05:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=E69NOj19URm23W2Jgoy0upB5E/RxAplAX4y/TZ9+Wmk=; b=HvwfsX7vRqZzfrVOLxm8IrIZu0KG0LZvbHe3L65QR0aNdxutcOXg/BpX3a24MJp3uB +ydRh7cWMXzTbobruj4uJi3Z3CAp+VLMHE/C1XLN0COjHAmThPq7TInFPs26OqQWCAL+ sFTc2LCpoZ4p9UYwwaj6sqmXRsUKJQVa1oPzU= MIME-Version: 1.0 Received: by 10.50.15.134 with SMTP id x6mr2669182igc.51.1323177314600; Tue, 06 Dec 2011 05:15:14 -0800 (PST) Received: by 10.50.100.233 with HTTP; Tue, 6 Dec 2011 05:15:14 -0800 (PST) Date: Tue, 6 Dec 2011 18:45:14 +0530 Message-ID: From: ramesh kumar To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=14dae9340c47cfc64404b36c394e X-Mailman-Approved-At: Tue, 06 Dec 2011 13:03:42 -0800 Subject: [MMUSIC] Please help me on solving following Issues related to RTP based IMS VOIP Session. 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, 06 Dec 2011 13:35:43 -0000 --14dae9340c47cfc64404b36c394e Content-Type: text/plain; charset=ISO-8859-1 Hi, I am facing following Issues in RTP based IMS VOIP Session: a) Previous VT/VOIP Call Media Session RTP packets flowing into current VT/VOIP Call Media Session due to Network Congestion/Delay. b) Media Packets received have unknown SSRC than the other Media packets due to eavesdropper in the network. How to ignore Unknown SSRC Packets/Previous Call Media Packets from playing? -- *Thanks & Regards, R.Ramesh Kumar * --14dae9340c47cfc64404b36c394e Content-Type: text/html; charset=ISO-8859-1

Hi,

I am facing following Issues in RTP based IMS VOIP Session:

a) Previous VT/VOIP Call Media Session RTP packets flowing into current VT/VOIP Call Media Session due to Network Congestion/Delay.

b) Media Packets received have unknown SSRC than the other Media packets due to eavesdropper in the network.

How to ignore Unknown SSRC Packets/Previous Call Media Packets from playing?

--
Thanks & Regards,
R.Ramesh Kumar

--14dae9340c47cfc64404b36c394e-- From ciphor@starv.tv Tue Dec 6 22:54:57 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 37EDC11E808B for ; Tue, 6 Dec 2011 22:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joyNVDs16Gu6 for ; Tue, 6 Dec 2011 22:54:56 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D14411E809F for ; Tue, 6 Dec 2011 22:54:55 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so178790vcb.31 for ; Tue, 06 Dec 2011 22:54:54 -0800 (PST) Received: by 10.52.182.103 with SMTP id ed7mr10086124vdc.54.1323240893135; Tue, 06 Dec 2011 22:54:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.32.195 with HTTP; Tue, 6 Dec 2011 22:54:32 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?6IyD5pmo?= Date: Wed, 7 Dec 2011 14:54:32 +0800 Message-ID: To: ramesh kumar Content-Type: multipart/alternative; boundary=bcaec548a063633bb904b37b070f Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Please help me on solving following Issues related to RTP based IMS VOIP Session. 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, 07 Dec 2011 06:54:57 -0000 --bcaec548a063633bb904b37b070f Content-Type: text/plain; charset=ISO-8859-1 Just drop the packets with unknown SSRC before the audio/video decoder. 2011/12/6 ramesh kumar > Hi, > > I am facing following Issues in RTP based IMS VOIP Session: > > a) Previous VT/VOIP Call Media Session RTP packets flowing into current > VT/VOIP Call Media Session due to Network Congestion/Delay. > > b) Media Packets received have unknown SSRC than the other Media packets > due to eavesdropper in the network. > > How to ignore Unknown SSRC Packets/Previous Call Media Packets from > playing? > > -- > *Thanks & Regards, > R.Ramesh Kumar > * > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --bcaec548a063633bb904b37b070f Content-Type: text/html; charset=ISO-8859-1 Just drop the packets with unknown SSRC before the audio/video decoder.

2011/12/6 ramesh kumar <ramesh3184@gmail.com>

Hi,

I am facing following Issues in RTP based IMS VOIP Session:

a) Previous VT/VOIP Call Media Session RTP packets flowing into current VT/VOIP Call Media Session due to Network Congestion/Delay.

b) Media Packets received have unknown SSRC than the other Media packets due to eavesdropper in the network.

How to ignore Unknown SSRC Packets/Previous Call Media Packets from playing?

--
Thanks & Regards,
R.Ramesh Kumar


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


--bcaec548a063633bb904b37b070f-- From stewe@stewe.org Wed Dec 7 08:09:11 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 A68F021F8B24; Wed, 7 Dec 2011 08:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j27XmSQaNnJY; Wed, 7 Dec 2011 08:09:11 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 458C121F858C; Wed, 7 Dec 2011 08:09:09 -0800 (PST) Received: from [192.168.1.58] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4446-1743317 for multiple; Wed, 07 Dec 2011 17:09:07 +0100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 07 Dec 2011 08:08:40 -0800 From: Stephan Wenger To: Message-ID: Thread-Topic: Incoming liaison statement from MMUSIC Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3406090145_2752175" X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Cc: avtext@ietf.org, avt@ietf.org, payload@ietf.org, xrblock@ietf.org Subject: [MMUSIC] Incoming liaison statement from MMUSIC 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, 07 Dec 2011 16:09:11 -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_3406090145_2752175 Content-type: multipart/alternative; boundary="B_3406090145_2760267" --B_3406090145_2760267 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, mmusic has received an incoming liaison from MPEG, indicating that they have started on "codec independent media description code points". My understanding of this work is that these code points may be represented in SDP. My personal viewpoint is that this may well be sound architectural work, but it may be better conducted here in mmusic, at least when it comes to SDP representations and the related IANA work. However, I know nothing about this work beyond what's written in the statement, which is why I used "soft" language. Perhaps some of you can shed light into what's really going on. The assorted avt WGs are probably also affected, as some of the proposed code points sound like they are being described in payload formats, RTP extensions and perhaps even in xrblock. Let me suggest to use only the music list for discussions, as only mmusic is being addressed in the statement. As it is short, I have attached the statement in word format to this email. It will also appear shortly in the IETF liaison database. Regards, Stephan --B_3406090145_2760267 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
mmusic has= received an incoming liaison from MPEG, indicating that they have started o= n "codec independent media description code points".  My understanding = of this work is that these code points may be represented in SDP.
= My personal viewpoint is that this may well be sound architectural work, but= it may be better conducted here in mmusic, at least when it comes to SDP re= presentations and the related IANA work.  However, I know nothing = about this work beyond what's written in the statement, which is why I used = "soft" language.  Perhaps some of you can shed light into what's really= going on.
The assorted avt WGs are probably also affected, as som= e of the proposed code points sound like they are being described in payload= formats, RTP extensions and perhaps even in xrblock.  Let me suggest t= o use only the music list for discussions, as only mmusic is being addressed= in the statement.
As it is short, I have attached the statement i= n word format to this email.  It will also appear shortly in the IETF l= iaison database.
Regards,
Stephan
--B_3406090145_2760267-- --B_3406090145_2752175 Content-type: application/msword; name="29n124561.doc" Content-disposition: attachment; filename="29n124561.doc" Content-transfer-encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOAAAAAAA AAAAEAAAOgAAAAEAAAD+////AAAAADcAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAJ2AJBAAA8FK/AAAAAAAAEAAAAAAABgAA 7Q4AAA4AYmpiakxVTFUAAAAAAAAAAAAAAAAAAAAAAAARBBYAOB4AAC4/AQAuPwEA3wYAAAAA AAANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAEAFAAAAAAAAQAUAAEAFAAAAAAAAQAUAAAAAAABABQAA AAAAAEAFAAAAAAAAQAUAABQAAAAAAAAAAAAAAFQFAAAAAAAAOAsAAAAAAAA4CwAAAAAAADgL AAA4AAAAcAsAABQAAACECwAAJAAAAFQFAAAAAAAAkhgAAAICAAC0CwAAAAAAALQLAAAAAAAA tAsAAAAAAAC0CwAAAAAAALQLAAAAAAAACA0AAAAAAAAIDQAAAAAAAAgNAAAAAAAAERgAAAIA AAATGAAAAAAAABMYAAAAAAAAExgAAAAAAAATGAAAAAAAABMYAAAAAAAAExgAACQAAACUGgAA aAIAAPwcAACsAAAANxgAABUAAAAAAAAAAAAAAAAAAAAAAAAAQAUAAAAAAABxDwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIDQAAAAAAAAgNAAAAAAAAcQ8AAAAAAABxDwAAAAAAADcYAAAAAAAA AAAAAAAAAABABQAAAAAAAEAFAAAAAAAAtAsAAAAAAAAAAAAAAAAAALQLAABUAQAATBgAABYA AAAZEQAAAAAAABkRAAAAAAAAGREAAAAAAABxDwAAjgAAAEAFAAAAAAAAtAsAAAAAAABABQAA AAAAALQLAAAAAAAAERgAAAAAAAAAAAAAAAAAABkRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQ8AAAAAAAARGAAAAAAAAAAAAAAAAAAA GREAAAAAAAAZEQAAOgAAAC0WAAAsAAAAQAUAAAAAAABABQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkRYAAAAAAAC0CwAA AAAAAKgLAAAMAAAAwMI0ZN+zzAEAAAAAAAAAADgLAAAAAAAA/w8AAFIAAABZFgAACgAAAAAA AAAAAAAApRcAAGwAAABiGAAAMAAAAJIYAAAAAAAAYxYAAC4AAACoHQAAAAAAAFEQAAB2AAAA qB0AABQAAACRFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgdAAAAAAAAAAAAAAAAAABABQAA AAAAAJEWAAAUAQAACA0AAGgAAABwDQAASgAAABkRAAAAAAAAug0AADwAAAD2DQAAewEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA0AAAAAAAAIDQAAAAAAAAgNAAAAAAAA NxgAAAAAAAA3GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxxAAAFIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgNAAAAAAAACA0AAAAAAAAIDQAA AAAAAJIYAAAAAAAAcQ8AAAAAAABxDwAAAAAAAHEPAAAAAAAAcQ8AAAAAAAAAAAAAAAAAAFQF AAAAAAAAVAUAAAAAAABUBQAA5AUAADgLAAAAAAAAVAUAAAAAAABUBQAAAAAAAFQFAAAAAAAA OAsAAAAAAABUBQAAAAAAAFQFAAAAAAAAVAUAAAAAAABABQAAAAAAAEAFAAAAAAAAQAUAAAAA AABABQAAAAAAAEAFAAAAAAAAQAUAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAElOVEVSTkFUSU9OQUwgT1JHQU5JU0FUSU9OIEZPUiBT VEFOREFSRElTQVRJT04NT1JHQU5JU0FUSU9OIElOVEVSTkFUSU9OQUxFIERFIE5PUk1BTElT QVRJT04NSVNPL0lFQyBKVEMxL1NDMjkvV0cxMQ1DT0RJTkcgT0YgTU9WSU5HIFBJQ1RVUkVT IEFORCBBVURJTw0NSVNPL0lFQyBKVEMxL1NDMjkvV0cxMSBOMTI0NDgNRGVjZW1iZXIgMjAx MSwgR2VuZXZhLCBTd2l0emVybGFuZA0NDVNvdXJjZQdDb252ZW5vcgcHVGl0bGUHTGlhaXNv biBzdGF0ZW1lbnQgdGVtcGxhdGUgb24gY29kZWMgaW5kZXBlbmRlbnQgbWVkaWEgZGVzY3Jp cHRpb24gY29kZXBvaW50cwcHVG8HBwcNIA1JU08vSUVDIEpUQyAxL1NDIDI5L1dHIDExIChN UEVHKSBoYXZlIG9ic2VydmVkIHRoYXQgd2UgaGF2ZSBhIG51bWJlciBvZiBjb2RlIHBvaW50 cyB0byBkZXNjcmliZSBtZWRpYSB0aGF0IGFyZSB1c2VkIGluIHNldmVyYWwgc3BlY2lmaWNh dGlvbnMsIG9mdGVuIGR1cGxpY2F0aW5nIHRleHQ7IHRoZXNlIGNvZGUgcG9pbnRzIGRvY3Vt ZW50IGFzcGVjdHMgb2YgbWVkaWEgc3RyZWFtcyB0aGF0IGFyZSBpbmRlcGVuZGVudCBvZiB0 aGUgY29tcHJlc3Npb24gZm9ybWF0IHVzZWQuIA0NV2UgaGF2ZSBkZWNpZGVkIHRvIG1ha2Ug YSBzaW5nbGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGRlZmluaXRpb24gb2YgdGhlc2UgY29k ZSBwb2ludHMsIGVuYWJsaW5nIG90aGVyIHNwZWNpZmljYXRpb25zIHRvIHJlZmVyIHRvIHRo aXMuICBXZSBiZWxpZXZlIHRoYXQgdGhpcyBzaG91bGQgaGVscCBub3Qgb25seSBpbiBwcm92 aWRpbmcgYSBjb25zaXN0ZW50IHNldCBvZiB2YWx1ZXMgZm9yIHRoZXNlIChtYW55IG9mIHdo aWNoIGFyZSBlbnVtZXJhdGlvbnMpIGJ1dCBhbHNvIGNvbnNpc3RlbnQgc2VtYW50aWNzLCBl bmFibGluZyB0aGVpciBjYXJyaWFnZSBhbmQgY29tcGFyaXNvbiBhY3Jvc3MgYW5kIGJldHdl ZW4gbXVsdGlwbGUgZm9ybWF0cyBhbmQgc3RyZWFtcy4NDVRoZSBpbml0aWFsIHdvcmtpbmcg ZHJhZnQgY29udGFpbnMgaW5pdGlhbCBjb2RlIHBvaW50cyBmb3IgdGhlIGZvbGxvd2luZyBt ZWRpYSBkZXNjcmlwdGlvbnM6DVZpZGVvIENvbG91ciBQcmltYXJpZXMNVmlkZW8gQ29sb3Vy IFRyYW5zZmVyIENoYXJhY3RlcmlzdGljcw1WaWRlbyBNYXRyaXggQ29sb3VyIENvZWZmaWNp ZW50cw1TdGVyZW8gVmlkZW8gRnJhbWUgUGFja2luZw1TdGVyZW8gVmlkZW8gVmlldyBBc3Np Z25tZW50DUF1ZGlvIENoYW5uZWwgQ29uZmlndXJhdGlvbg1BdWRpbyBDaGFubmVsIEFzc2ln bm1lbnQNQXVkaW8gRGlhbG9nIExldmVsDUF1ZGlvIER5bmFtaWMgUmFuZ2UNDVdlIGFyZSBh bHNvIGNvbnNpZGVyaW5nIHRoZSBhZGRpdGlvbiBvZiBjb2RlIHBvaW50cyBmb3IgY29kZWMg bmFtZXMsIGJ1dCBoYXZlIG5vdCByZWFjaGVkIGNvbmNsdXNpb24geWV0IGlmIHRoaXMgd2ls bCBiZSBzdWl0YWJsZS4NDVlvdXIgY29tbWVudHMgb24gdGhpcyBhcHByb2FjaCBhcmUgd2Vs Y29tZSwgYW5kIHdlIHdvdWxkIGFsc28gd2VsY29tZSBzdWdnZXN0aW9ucyBmb3IgY29kZSBw b2ludHMgZm9yIG1lZGlhIGRlc2NyaXB0aW9ucyB5b3UgZmVlbCBzaG91bGQgYmUgY29uc2lk ZXJlZCBmb3IgaW5jbHVzaW9uIGluIHN1Y2ggYSBzcGVjaWZpY2F0aW9uLCBpZGVhbGx5IHdp dGggYSBzdWdnZXN0aW9uIGZvciB0aGUgaW5pdGlhbCBkZWZpbml0aW9uIG9yIHBvaW50ZXIg dG8gc3BlY2lmaWNhdGlvbiB3aGVyZSBzdWNoIGNvZGUgcG9pbnRzIGFyZSBkZWZpbmVkLg0D DQ0EDQ0DDQ0EDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAYAAC8IAACWCAAArggAAK8IAACwCAAAtQgAALYIAAC+CAAA wQgAAMMIAADFCAAA2AgAANkIAADaCAAA2wgAAOIIAADqCAAA8ggAAD4JAABACQAAQgkAAEMJ AABECQAARQkAAEYJAADz7Ofi07+vqp+WjqqEjn11cHVodWN1WExIAAAAAAAAAAAAAAAAAAAA BhZo5TqxAAAXFWjhHqoAFmjhHqoAbkgRBG8oAXRIEQQUFWjhHqoAFmjhHqoAbkgRBHRIEQQA CRZolTFDADUIgQ8VaPFs3gAWaPFs3gA1CIEJFmjiVDkANQiBDxVomWNwABZo4R6qADUIgQwV aLIF3gAWaO5pbwAAEhVoKl2BABZo7mlvADUIgW8oAQAPFWgqXYEAFmjuaW8ANQiBERZoFCtl ADUIgW5IEQR0SBEEFBZo9kkXADUIgW5IEQRvKAF0SBEEAAkWaBQrZQA1CIEeFWjQJQ0AFmju aW8ANQiBUEoDAG5IEgRvKAF0SBIEACcVaNAlDQAWaPFs3gA1CIFCKgZQSgMAbkgSBG8oAXBo /wAAAHRIEgQdFmj2SRcANQiBQioGbkgRBG8oAXBo/wAAAHRIEQQJFmjhHqoANQiBCRZo7mlv ADUIgQ0WaO5pbwA1CIFDShwAFxVoixjAABZo7mlvADUIgUNKHABhShwAABkABgAALwgAAFwI AABzCAAAlwgAAJgIAAC2CAAA2QgAANoIAADbCAAA4ggAAOsIAADsCAAA9wAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADg AAAAAAAAAAAAAAAA2AAAAAAAAAAAAAAAANgAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAwgAA AAAAAAAAAAAAAMIAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAAAAAAAAAAFYAAGtkAAAAABYk ARckAUlmAQAAAAKWbAAI1jAAApT/zAP3JAAGOAQAAAAAAAAAAAAAAAAAAAAAAAYrIQAAAAAA AAAAAAAAAAAAAAAKdAAA4AEU9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8A AAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAeXSZY3AA AA0AAAMkAxYkASokAUlmAQAAAGEkA2dkmWNwAAAHAAASZBD/AABnZO5pbwAABwAAAyQCYSQC Z2QqXYEAAAcAAAMkAmEkAmdk4R6qAAAOAAADJAENxgUAAQsVABJkEP8AAGEkAWdk7mlvAAAH AAADJAFhJAFnZO5pbwAADAAGAADfDgAA7A4AAP39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQEC7AgAAPIIAAA/CQAA QAkAAEMJAABECQAA8QAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAAgwAA AAAAAAAAAAAAAHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkFCtlAAkAABYkAUlmAQAAAGdk4R6qAABW AABrZGUAAAAWJAEXJAFJZgEAAAAClmwACNYwAAKU/8wD9yQABjgEAAAAAAAAAAAAAAAAAAAA AAAGKyEAAAAAAAAAAAAAAAAAAAAACnQAAOABFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAA AP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh 9gMAAHl0mWNwAAANAAADJAMWJAEqJAFJZgEAAABhJANnZJUxQwAADQAAAyQDFiQBKiQBSWYB AAAAYSQDZ2SZY3AAAAVECQAARQkAAEYJAABICQAAWQoAAFoKAADXCwAA2AsAADUMAABMDAAA cgwAAJMMAACuDAAAywwAAOcMAAAADQAAEw0AACcNAACoAAAAAAAAAAAAAAAApgAAAAAAAAAA AAAAAKAAAAAAAAAAAAAAAACbAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAJsAAAAAAAAAAAAA AACbAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAA kwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAJMA AAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAAAIAAAKJgALRgIAZ2TiVDkA AAQAAGdkzXH1AAYAAEAmAGdksgXeAAABAAAAVgAAa2TKAAAAFiQBFyQBSWYBAAAAApZsAAjW MAAClP/MA/ckAAY4BAAAAAAAAAAAAAAAAAAAAAAABishAAAAAAAAAAAAAAAAAAAAAAp0AADg ART2AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3W CAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAB5dJljcAAAEUYJAABHCQAASAkAAFMJ AABUCQAAWAkAAFkJAABeCQAAXwkAAGkJAACcCQAAsgkAANcLAAD7CwAAAgwAACcNAAAoDQAA rA0AAA4OAAAlDgAAfw4AAN4OAADfDgAA4A4AAOIOAADjDgAA5Q4AAOYOAADoDgAA6Q4AAOwO AADtDgAA9uni2eLZ4tni1dHV0c3R1dHV0dXRycG9wb3BvcG9yQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYWaLh1/AAADwNqAAAA ABZouHX8AFUIAQYWaLIF3gAABhZoxVOhAAAGFmjiVDkAAAYWaM1x9QAAERZo2T5hAG5IEQRv KAF0SBEEDBVolTFDABZolTFDAAAYFWiyBd4AFmiyBd4AQ0oWAG1IBwRzSAcEABIWaLIF3gBD ShYAbUgHBHNIBwQfJw0AACgNAACrDQAArA0AAN8OAADhDgAA4g4AAOQOAADlDgAA5w4AAOgO AADqDgAA6w4AAOwOAADtDgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAGdk8WzeAAABAAAABAAAZ2TNcfUAAA42ACZQCQAxkGgBOnDZPmEA H7CDLiCwyEEhsG4EIrBuBCOQbgQkkIoFJbAAABewxQIYsMUCDJDQAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGMAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABAzgENdYFAQIDKyEjdgAB OAQjdgECKyE6VgsAApZsAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQM4BDXWBQECAysheXSZ Y3AAYwAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDOAQ11gUBAgMrISN2AAE4BCN2AQIr ITpWCwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABAzgENdYFAQIDKyF5dJljcABjABYk ARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQM4BDXWBQECAyshI3YAATgEI3YBAishOlYLAAKW bAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDOAQ11gUBAgMrIXl0mWNwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACGAhYAEgABAJwADwAEAAAABAAAAAAABAAIAAAACAAAAA4AAAAOAAAADgAAAA4AAAAOAAAA DgAAAA4AAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA4AABA8f8CADgADBAAAO5pbwAAAAIAGWqWbgAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNI CQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAAJABBAPL/oQAkAAwBAAAAAAAAAAAGALVrPYTVMKkw 8zDIMAAAAABCAGlA8/+zAEIADAEAAAAAAAAAAAQAGWqWbm4waIgAABwAF/YDAAA01gYAAQoD bAA01gYAAQUDAABh9gMAAAIACwAAACQAawD0/8EAJAAAAQAAAAAAAAAABQDqMLkwyDBqMFcw AAACAAwAAAAAAGIAmgCzAPMAYgAMBAAA4R6qAAAABgBoiCAAKAA8aFBbKQAAADcAOlYPABPW MAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8A AAA8AJlAAQACATwADAQRAIUx/AAAAAQAOVRNMPpRVzAAAAIAEAAYAENKEgBPSgUAUUoFAGFK EgBtSAAAc0gAAEYA/k/y/xEBRgAMABAAhTH8AAAACwAgACgAh2VXWykAIAAoAIdlV1spADIA AAAYAENKEgBPSgUAUUoFAF5KBQBhShIAdEgJBDoAH0ABACIBOgAMBBMA8WzeAAAABADYMMMw wDD8MAAAEAASAA3GCAACoRFCIwECRyQACABtSAAAc0gAADoA/k/y/zEBOgAMABIA8WzeAAAA CwAgACgAh2VXWykAIAAoAIdlV1spADEAAAAMAENKGABhShgAdEgJBDoAIEABAEIBOgAMBBUA 8WzeAAAABADVMMMwvzD8MAAAEAAUAA3GCAACoRFCIwECRyQACABtSAAAc0gAADgA/k/y/1EB OAAMABQA8WzeAAAACgAgACgAh2VXWykAIAAoAIdlV1spAAAADABDShgAYUoYAHRICQQAAAAA 7QYAAAUAAB4AAAAA/////wAAAAAvAAAAXAAAAHMAAACXAAAAmAAAALYAAADZAAAA2gAAANsA AADiAAAA6wAAAOwAAADyAAAAPwEAAEABAABDAQAARAEAAEUBAABGAQAASAEAAFkCAABaAgAA 1wMAANgDAAA1BAAATAQAAHIEAACTBAAArgQAAMsEAADnBAAAAAUAABMFAAAnBQAAKAUAAKsF AACsBQAA3wYAAOEGAADiBgAA5AYAAOUGAADnBgAA6AYAAOoGAADrBgAA7gYAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACA AQAA1AAAAAAgAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAAIAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAIgADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAACIAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAiAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAIgADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAACIAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAIg ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAACIAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAA AABEB6iRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAARAeo0QAwADAAAAAAAAABAAAAAAAAAAAA AAAAAEQHqJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAABEB6jRADAAMAAAAAAAAAEAAAAAAAAA AAAAAAAARAeokQAwADAAAAAAAAABAAAAAAAAAAAAAAAAAEQHqNEAMAAwAAAAAAAAAQAAAAAA AAAAAAAAAABEB6iRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAARAeokQAwADAAAAAAAAABAAAA AAAAAAAAAABcMEQHAAAAAAMAAAAGAAAABgAAAAkAAAAMAAAADAAAAAwAAAAMAAAADAAAAAwA AAAMAAAADAAAAA8AAAAABgAARgkAAO0OAAAIAAAADQAAAAAGAADsCAAARAkAACcNAADtDgAA CQAAAAsAAAAMAAAADgAAAAAGAADsDgAACgAAAA8AAPBgAAAAAAAG8CAAAAACDAAAAwAAAAIA AAACAAAAAQAAAAIAAAACAAAAAQAAAEMAC/AYAAAAgQA3IgEAggC6IgAAgwA3IgEAhAC6IgAA QAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAQ8AAvBIAAAAIAAI8AgAAAABAAAAAAgAAA8AA/Aw AAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAAAA8A AvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4A AAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAD//wcAAAAGAD2d SQEQAAEA3Ap6CQYAPp1JAREAAQBcCnoJBgA/nUkBEQABAJwLegkGAECdSQEQAAEAJJ2ICQYA QZ1JAREAAQBknYgJBgBCnUkBEQABAKSdiAkGAEOdSQERAAEA5J2ICcUAAADFAAAAzQAAABMF AAATBQAAGQUAACEFAADuBgAAAQAAAAIAAAAAAAIAAgAAAAIABQAAAAIAAwAAAAIABAAAAAIA BgAAAAIAywAAANgAAADYAAAAGAUAACAFAAAmBQAAJgUAAO4GAAABAAEAAAAAAAIAAAAEAAEA BQABAAMAAAAGAAAABQAAAD0AAAABAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpzbWFydHRhZ3MJgFBsYWNlVHlwZQCAPQAAAAMAAAAqgHVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwmAUGxhY2VOYW1lAIBCAAAABQAAACqAdXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzDoBjb3VudHJ5LXJlZ2lvbgCA OAAAAAYAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwSA Q2l0eQCAOQAAAAcAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0 dGFncwWAcGxhY2UAgAwAAAGU3W0DAAAAAAcAAAAAAAYAAAAAAAUAAAAAAAcAAAAAAAMAAAAA AAMAAAAAAAEAAAAAAAAAAADiAAAA6gAAADQBAAA+AQAAOwQAAEEEAABSBAAAWAQAAH8EAACF BAAA3wYAAN8GAADhBgAA4QYAAOIGAADiBgAA5AYAAOUGAADnBgAA6AYAAOoGAADrBgAA7gYA AAcAHAAHABwABwAcAAcAHAAHABwABwAEAAcABAACAAQABwAEAAcABAAHAAQAAgAAAAAA3wYA AN8GAADhBgAA4QYAAOIGAADiBgAA5AYAAOUGAADnBgAA6AYAAOoGAADrBgAA7gYAAAcABAAH AAQAAgAEAAcABAAHAAQABwAEAAIAAAAAALYAAADyAAAAQAEAAEMBAAA1BAAAKAUAAN8GAADf BgAA4QYAAOEGAADiBgAA4gYAAOQGAADlBgAA5wYAAOgGAADqBgAA6wYAAO4GAAAHAAUABwAF AAcABQAHAAQABwAEAAIABAAHAAQABwAEAAcABAACAAAAAADfBgAA3wYAAOEGAADhBgAA4gYA AOIGAADkBgAA5QYAAOcGAADoBgAA6gYAAOsGAADuBgAABwAEAAcABAACAAQABwAEAAcABAAH AAQAAgACAB3///8cuPYB/w//D/8P/w//D/8P/w//D/8PAAB/T9M7oESa9P8P/w//D/8P/w// D/8P/w//DxAAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EAAARhAAAFcYFAAEAAAZe hAAAYIQAAE9KAQBRSgEAbygAAAABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Q4BBGE mP4VxgUAAdACBl6EOARghJj+T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAADxgAAA+ECAcRhJj+FcYFAAGgBQZehAgHYISY/k9KBgBRSgYAXkoGAG8oAAEAbwABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TYCRGEmP4VxgUAAXAIBl6E2AlghJj+T0oHAFFK BwBvKAABAKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EqAwRhJj+FcYFAAFACwZe hKgMYISY/k9KBwBRSgcAbygAAQD68AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHgP EYSY/hXGBQABEA4GXoR4D2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4RIEhGEmP4VxgUAAeAQBl6ESBJghJj+T0oGAFFKBgBeSgYAbygAAQBvAAEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBgVEYSY/hXGBQABsBMGXoQYFWCEmP5PSgcA UUoHAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4ToFxGEmP4VxgUAAYAW Bl6E6BdghJj+T0oHAFFKBwBvKAABAPrwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+E 0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAAGRAAAA+EoAURhJj+XoSgBWCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACISAAA AQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhHAIEYSY/l6EcAhghJj+T0oHAFFK BwBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhEALEYSY /l6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAA AAAAABkQAAAPhBAOEYSY/l6EEA5ghJj+T0oGAFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwAB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9KBwBRSgcAbygA h2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGEmP5ehLAT YISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZ EAAAD4SAFhGEmP5ehIAWYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EUBkRhJj+XoRQGWCEmP5PSgcAUUoHAG8oAIdoAAAA AIhIAAABAKfwAgAAAB3///8AAAAAAAAAAAAAAAB/T9M7AAAAAAAAAAAAAAAA//////////// /wIAAAAAAAAA//8CAAAAAAASAAEABwQDAAcEBQAHBAEABwQDAAcEBQAHBAEABwQDAAcEBQAH BD8AAAAEAAAACAAAAOUAAAAAAAAAPgAAAAx1AABpZwUA0CUNAPZJFwAAZxcAlAMlALBfJwDX TioAHTAsACAQMwByLDkA4lQ5ANQ7PgCVMUMAzGJSAAJSVwDYUFsA2T5hAJB3ZAAUK2UAYEBt AO5pbwCZY3AA0DdxAAp9cwC3OHQAmSx2AFYkeQDhKXkAtwp9ACpdgQB0YYEAqQ6EABAYjgAp EpQAzGOXAKd7mQASG5oAX2icAMVToQDdMqQAQlekAOEeqgDlOrEAYnq3AFQkugD7Bb0AeQ29 AIhOvQBcE74AnCDHAGV2zQBYKNoAcX3dALIF3gDxbN4AzXH1ANlQ+AC8RfsAhTH8ALh1/ABX O/0A2kP/AAAAAADaAAAA2wAAAOIAAADrAAAA7AAAAPIAAAA/AQAAQAEAAEMBAABEAQAARQEA AN4GAADuBgAAAAAAAHmANQAIAAAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACW AQAAAQAAAP9AAYABADECAAAxAgAAHExtAwEAAQAxAgAAAAAAADECAACU/8B7AhAAAAAAAAAA 7QYAAFAAABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEA AAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAgAAABHFpABAAACAgYDBQQFAgME7zoA4EF4 AMAJAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpAB AgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpAB AAACCwYEAgICAgIE/zoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAQyaQAYEA AgsFAwIAAAIABK8CAJD7fNcJEgAAAAAAAAABAAgAAAAAAE0AYQBsAGcAdQBuACAARwBvAHQA aABpAGMAAABHFZABgAYCAgYJBAIFCAME/wIA4Pv9x2oSAAAAAAAAAJ8AAgAAAAAALf8z/yAA DmYdZwAATQBTACAATQBpAG4AYwBoAG8AAABDBpABAAACCwYABAUCAgIE7woA4f+hAFAAAAAA AAAAAL8BAAAAAAAATAB1AGMAaQBkAGEAIABHAHIAYQBuAGQAZQAAAD81kAEAAAIHAwkCAgUC BAT/OgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7BpAB AgAFAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMA AAAiAAQAMQiIGADw0AIAAGgBAAAAALoT/KbWM/xGAAAAAAQABAAAAAYBAADZBQAAAQADAAAA BAADEAwAAAAGAQAA2QUAAAEAAwAAAAwAAAAAAAAAwQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbgRuBHgAtACCghI0AAAAAAAAAAAAAAAAAADcBgAA 3AYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAIAAAAAAAAAAAAMMoNxAPAQAAgA//0BAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEhYAAAAAAnw/w8BAAE/AACkAwAA////f////3////9/////f////3////9/////f+U6 sQAABAAAMgAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAAC4ASQBOAFQARQBSAE4AQQBUAEkA TwBOAEEATAAgAE8AUgBHAEEATgBJAFMAQQBUAEkATwBOACAARgBPAFIAIABTAFQAQQBOAEQA QQBSAEQASQBTAEEAVABJAE8ATgAAAAAAAAAFAG8AZwB1AHIAYQAOAFkAbwBrAG8AIABIAGkA ZwBhAHMAaABpAGQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAGAAAAAgAAAAAADAABAAwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABgACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgA Kyez2TAAAACMAQAAEAAAAAEAAACIAAAAAgAAAJAAAAADAAAAyAAAAAQAAADUAAAABQAAAOQA AAAHAAAA8AAAAAgAAAAEAQAACQAAABwBAAASAAAAKAEAAAoAAABIAQAADAAAAFQBAAANAAAA YAEAAA4AAABsAQAADwAAAHQBAAAQAAAAfAEAABMAAACEAQAAAgAAAKQDAAAeAAAAMAAAAElO VEVSTkFUSU9OQUwgT1JHQU5JU0FUSU9OIEZPUiBTVEFOREFSRElTQVRJT04AAB4AAAAEAAAA AAAAAB4AAAAIAAAAb2d1cmEAAAAeAAAABAAAAAAAAAAeAAAADAAAAE5vcm1hbC5kb3QAAB4A AAAQAAAAWW9rbyBIaWdhc2hpZGEAAB4AAAAEAAAANAAAAB4AAAAYAAAATWljcm9zb2Z0IE9m ZmljZSBXb3JkAAAAQAAAAAAYDY8AAAAAQAAAAADkqli3sMwBQAAAAAB0oFzfs8wBAwAAAAEA AAADAAAABgEAAAMAAADZBQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAYAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA HAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIAAAAAGAAAAiAAAABEAAACQAAAAFwAAAJgA AAALAAAAoAAAABAAAACoAAAAEwAAALAAAAAWAAAAuAAAAA0AAADAAAAADAAAAPsAAAACAAAA pAMAAB4AAAAIAAAASVRTQ0oAAAADAAAADAAAAAMAAAADAAAAAwAAANwGAAADAAAADycLAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAvAAAASU5URVJOQVRJT05B TCBPUkdBTklTQVRJT04gRk9SIFNUQU5EQVJESVNBVElPTgAMEAAAAgAAAB4AAAAGAAAAVGl0 bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA DwAAAP7///8RAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA/v///xkAAAAaAAAAGwAAABwA AAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAA/v///ygAAAApAAAA KgAAACsAAAAsAAAALQAAAC4AAAD+////MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAAP7/ ///9////OQAAAP7////+/////v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAsAw3ZN+zzAE7AAAAgAAAAAAAAABEAGEAdABhAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAA AAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGAAAALwdAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOB4AAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACcAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQD+/wMK AAD/////BgkCAAAAAADAAAAAAAAARhsAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQglbaPkQAK AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= --B_3406090145_2752175-- From singer@apple.com Wed Dec 7 09:29:28 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 6BF0321F85CE; Wed, 7 Dec 2011 09:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9mihU3M89XP; Wed, 7 Dec 2011 09:29:27 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 047EA21F8BB1; Wed, 7 Dec 2011 09:29:22 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CtRC7gm2oU3HeqUBm5UV3A)" Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LVU002JJGKBECE0@mail-out.apple.com>; Wed, 07 Dec 2011 09:29:20 -0800 (PST) X-AuditID: 11807112-b7b54ae000001626-1a-4edfa270b729 Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay17.apple.com (Apple SCV relay) with SMTP id D0.06.05670.072AFDE4; Wed, 07 Dec 2011 09:29:20 -0800 (PST) From: David Singer In-reply-to: Date: Wed, 07 Dec 2011 09:29:20 -0800 Message-id: References: To: Stephan Wenger X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUieFSBW7dg0X0/g+Z7qhYve1ayW3y8d4PV YuryxywWly6eZbK43riJ3WLKhUcsDmweS5b8ZPJYvP49YwBTFJdNSmpOZllqkb5dAlfG/O2l Bat8Kv5Mns/YwLjIoYuRk0NCwETiyIYFbBC2mMSFe+uBbC4OIYHNjBJfOv+CJYQFbCUeNPxl BLF5BYwl1tx6xwJiMwskSLx4cwjMZhNQlXgw5xhYDaeArsTsA8/BbBYBFYmTB7qYIerjJN7e WskGMcdG4vDUPWC2kICOxOKD+1lBbBGg+kM3f7BAHCQv0fL1DtsERr5ZSFbPQrIawtaWWLbw NfMsRg4gW0di8kJGVGEI++P5I0wLGNlWMQoWpeYkVhqa6yUWFOSk6iXn525iBIVyQ6HQDsb7 u/QOMQpwMCrx8G5wuOcnxJpYVlyZe4hRgoNZSYT3y6z7fkK8KYmVValF+fFFpTmpxYcYpTlY lMR5j2y77ickkJ5YkpqdmlqQWgSTZeLglGpg9E0tV7C3zCux2+fy4H9ibt6Xp6oV56ImPV7O zBG15q9QXsfN+24Mbzv63a5XqauyZs1MDgjbzpO1QiGvKfX6qpklu4pjNhcWX3H5Z3h58TJW bsnX/rmT5xSxLXKca5u1+uMDO8sNGctDr7bo+1x8dMTbQeb1wtsrnqbGrvK14nHqNXPcLn9X iaU4I9FQi7moOBEAaZVXV2ECAAA= Cc: avtext@ietf.org, xrblock@ietf.org, mmusic@ietf.org, payload@ietf.org, avt@ietf.org Subject: Re: [MMUSIC] [AVTCORE] Incoming liaison statement from MMUSIC 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, 07 Dec 2011 17:29:28 -0000 --Boundary_(ID_CtRC7gm2oU3HeqUBm5UV3A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Stephan I can explain a bit. We noticed in systems work at MPEG two things a) we wanted to say something about the signal that was being compressed (audio or video) that was nothing to do with the compression, and we ended up having to 'pick' a codec document and point at it, because the codes we wanted were always documented with codecs. b) the codes are also copied from spec. to spec. in many cases (so they happen to have values having the same meanings); in a few cases, each codec has 'invented its own' and the codes needlessly differ from spec. to spec. Examples: the 'classic three' values used to describe video color: color_primaries, transfer_characteristics, matrix_coefficients. These are copied from spec. to spec., with the more recent specs having more values. Recently there was a mistake noticed in an equation, and I think it had to be corrected in several places. Another example is 'frame packing' (stereo packed into a mono video stream); the specs actually don't always align on the definitions here. The variation of semantics for some points could be a problem; different values for the same semantics is a nuisance, e.g. when wanting to be codec-independent or when transcoding. Different numbers of values for the same code in different specs is a nuisance, and raises questions, and so on. The basic idea is to collect a whole bunch of these, document them in one place, and remove the definitions from a whole bunch of specs. So, for example, in a video spec. one might be able to say "this 8-bit field carries a color_primaries value as defined in [[this new spec]]; if absent, the default value is 23". Correspondingly, in say SDP, one might be able to say "if this field is 0, the video is mono; otherwise, it carries a frame_packing values as defined in [[this new spec]]". Makes sense? On Dec 7, 2011, at 8:08 , Stephan Wenger wrote: > Hi all, > mmusic has received an incoming liaison from MPEG, indicating that they have started on "codec independent media description code points". My understanding of this work is that these code points may be represented in SDP. > My personal viewpoint is that this may well be sound architectural work, but it may be better conducted here in mmusic, at least when it comes to SDP representations and the related IANA work. However, I know nothing about this work beyond what's written in the statement, which is why I used "soft" language. Perhaps some of you can shed light into what's really going on. > The assorted avt WGs are probably also affected, as some of the proposed code points sound like they are being described in payload formats, RTP extensions and perhaps even in xrblock. Let me suggest to use only the music list for discussions, as only mmusic is being addressed in the statement. > As it is short, I have attached the statement in word format to this email. It will also appear shortly in the IETF liaison database. > Regards, > Stephan > <29n124561.doc>_______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt David Singer Multimedia and Software Standards, Apple Inc. --Boundary_(ID_CtRC7gm2oU3HeqUBm5UV3A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = Stephan

I can explain a bit.  We noticed in = systems work at MPEG two things
a) we wanted to say something = about the signal that was being compressed (audio or video) that was = nothing to do with the compression, and we ended up having to 'pick' a = codec document and point at it, because the codes we wanted were always = documented with codecs.
b) the codes are also copied from = spec. to spec. in many cases (so they happen to have values having the = same meanings); in a few cases, each codec has 'invented its own' and = the codes needlessly differ from spec. to = spec.

Examples: the 'classic three' values used = to describe video color: color_primaries, transfer_characteristics, = matrix_coefficients.  These are copied from spec. to spec., with = the more recent specs having more values. Recently there was a mistake = noticed in an equation, and I think it had to be corrected in several = places.  Another example is 'frame packing' (stereo packed into a = mono video stream); the specs actually don't always align on the = definitions here.

The variation of semantics = for some points could be a problem; different values for the same = semantics is a nuisance, e.g. when wanting to be codec-independent or = when transcoding. Different numbers of values for the same code in = different specs is a nuisance, and raises questions, and so = on.

The basic idea is to collect a whole bunch = of these, document them in one place, and remove the definitions from a = whole bunch of specs.  So, for example, in a video spec. one might = be able to say "this 8-bit field carries a color_primaries value as = defined in [[this new spec]]; if absent, the default value is 23". =  Correspondingly, in say SDP, one might be able to say "if this = field is 0, the video is mono; otherwise, it carries a frame_packing = values as defined in [[this new spec]]".

Makes = sense?


On Dec 7, 2011, at 8:08 , = Stephan Wenger wrote:

Hi all,
mmusic = has received an incoming liaison from MPEG, indicating that they have = started on "codec independent media description code points".  My = understanding of this work is that these code points may be represented = in SDP.
My personal viewpoint is that this may well be sound = architectural work, but it may be better conducted here in mmusic, at = least when it comes to SDP representations and the related IANA work. =  However, I know nothing about this work beyond what's written = in the statement, which is why I used "soft" language.  Perhaps = some of you can shed light into what's really going on.
The = assorted avt WGs are probably also affected, as some of the proposed = code points sound like they are being described in payload formats, RTP = extensions and perhaps even in xrblock.  Let me suggest to use only = the music list for discussions, as only mmusic is being addressed in the = statement.
As it is short, I have attached the statement in = word format to this email.  It will also appear shortly in the IETF = liaison database.
Regards,
Stephan
= <29n124561.doc>________________________________________= _______
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mail= man/listinfo/avt

David Singer
Multimedia and = Software Standards, Apple = Inc.

= --Boundary_(ID_CtRC7gm2oU3HeqUBm5UV3A)-- From ciphor@starv.tv Wed Dec 7 18:55: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 2F43E11E80B6 for ; Wed, 7 Dec 2011 18:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usxwg77Ua+Af for ; Wed, 7 Dec 2011 18:55:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4671D11E8095 for ; Wed, 7 Dec 2011 18:55:01 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1148137vbb.31 for ; Wed, 07 Dec 2011 18:55:01 -0800 (PST) Received: by 10.52.182.103 with SMTP id ed7mr633479vdc.54.1323312901115; Wed, 07 Dec 2011 18:55:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.32.195 with HTTP; Wed, 7 Dec 2011 18:54:40 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?6IyD5pmo?= Date: Thu, 8 Dec 2011 10:54:40 +0800 Message-ID: To: ramesh kumar Content-Type: multipart/alternative; boundary=bcaec548a06365ceeb04b38bcbed Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Please help me on solving following Issues related to RTP based IMS VOIP Session. 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, 08 Dec 2011 02:55:03 -0000 --bcaec548a06365ceeb04b38bcbed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The "Transport" header in the SETUP response may have "ssrc=3D" parameter. You can use that parameter to detect unknown ssrc. regards Chen 2011/12/7 ramesh kumar > Hi, > How can we detect UnKnown SSRC to drop it? > > Thanks & Regards, > Ramesh. > On 7 December 2011 12:24, =E8=8C=83=E6=99=A8 wrote: > >> Just drop the packets with unknown SSRC before the audio/video decoder. >> >> 2011/12/6 ramesh kumar >> >>> Hi, >>> >>> I am facing following Issues in RTP based IMS VOIP Session: >>> >>> a) Previous VT/VOIP Call Media Session RTP packets flowing into current >>> VT/VOIP Call Media Session due to Network Congestion/Delay. >>> >>> b) Media Packets received have unknown SSRC than the other Media packet= s >>> due to eavesdropper in the network. >>> >>> How to ignore Unknown SSRC Packets/Previous Call Media Packets from >>> playing? >>> >>> -- >>> *Thanks & Regards, >>> R.Ramesh Kumar >>> * >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >> > > > -- > *Thanks & Regards, > R.Ramesh Kumar > * > --bcaec548a06365ceeb04b38bcbed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The "Transport" header in the SETUP response may have "ssrc= =3D" parameter.
You can use that parameter to detect unknown ssrc.=

regards
Chen

2011/12/7 ramesh kumar <ramesh3184@gmail.com>
Hi,
How can we detect UnKnown SSRC to drop it?
=C2=A0
Thanks & Regards,
Ramesh.
On 7 December 2011 12:24, =E8=8C=83=E6=99=A8 <cip= hor@starv.tv> wrote:
Just drop the packets with unknown SS= RC before the audio/video decoder.

2011/12/6 ramesh kumar <ramesh3184@gmail.com= >

Hi,

I am facing following Issues in RTP based IMS VOIP Session:

a) Previous VT/VOIP Call Media Session RTP packets flowing into current = VT/VOIP Call Media Session due to Network Congestion/Delay.

b) Media Packets received have unknown SSRC than the other Media packets= due to eavesdropper in the network.

How to ignore Unknown SSRC Packets/Previous Call Media Packets from play= ing?

--
Thanks & Regards,
R.Ram= esh Kumar


________________________________= _______________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/lis= tinfo/mmusic





-- =
Thanks &= amp; Regards,
R.Ramesh Kumar


--bcaec548a06365ceeb04b38bcbed-- From miguel.a.garcia@ericsson.com Sun Dec 11 23:50:47 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 D839421F8564 for ; Sun, 11 Dec 2011 23:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.716 X-Spam-Level: X-Spam-Status: No, score=-6.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvwpHLbOrhCf for ; Sun, 11 Dec 2011 23:50:47 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 181B721F84DD for ; Sun, 11 Dec 2011 23:50:46 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-e4-4ee5b255a4cb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 24.C4.23425.552B5EE4; Mon, 12 Dec 2011 08:50:45 +0100 (CET) Received: from [159.107.24.205] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Dec 2011 08:50:45 +0100 Message-ID: <4EE5B254.5080307@ericsson.com> Date: Mon, 12 Dec 2011 08:50:44 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] IETF 82 minutes posted 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, 12 Dec 2011 07:50:48 -0000 The minutes of the IETF 82 MMUSIC meeting are now available at: http://www.ietf.org/proceedings/82/minutes/mmusic.htm Please read them, and if you have comments, questions, or changes to be made, let the chairs know it. /Flemming and Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ramesh3184@gmail.com Wed Dec 14 02:22: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 546B921F8B36 for ; Wed, 14 Dec 2011 02:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RTHGqLRInOp for ; Wed, 14 Dec 2011 02:22:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA7AE21F8B33 for ; Wed, 14 Dec 2011 02:22:33 -0800 (PST) Received: by iaek3 with SMTP id k3so1233952iae.31 for ; Wed, 14 Dec 2011 02:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=pnV+NWDdb6qcEfylQCCiNkYizkaPgRWaLaJbFXJ0bbw=; b=kLo5hSyoMKe5yMkswZfgQF7vYB3Hkz2sYEYNCqmgQcwJlR/TQ6zkcXberNpVgHESWs ylVPei7fzZ/yC4alws8ZNUoXZNlIMLdy1S2nfLvo8Ov0c4qsdD+tYU6vYXNfctgBbjRe +8zVBP5fsc+C0F25d1xrLxxxy1TCn6Y6WM7kE= MIME-Version: 1.0 Received: by 10.50.173.74 with SMTP id bi10mr23826288igc.4.1323858153459; Wed, 14 Dec 2011 02:22:33 -0800 (PST) Received: by 10.50.100.233 with HTTP; Wed, 14 Dec 2011 02:22:33 -0800 (PST) Date: Wed, 14 Dec 2011 15:52:33 +0530 Message-ID: From: ramesh kumar To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=e89a8f83a0e1f851c704b40abe81 X-Mailman-Approved-At: Wed, 14 Dec 2011 06:39:30 -0800 Subject: [MMUSIC] Need clarification on SSRC usage in Consecutive RTP Sessions 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, 14 Dec 2011 10:22:34 -0000 --e89a8f83a0e1f851c704b40abe81 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I have a question on SSRC usage in RTP: As per RFC 3550, The SSRC identifier is a randomly chosen value meant to be globally unique within a particular RTP session. A participant need not use the same SSRC identifier for all the RTP sessions in a multimedia session. Question: Is there any possibility of SSRC Identifier be same across consecutive RTP Sessions ? Does Standard emphasis on this ? -- *Thanks & Regards, R.Ramesh Kumar * --e89a8f83a0e1f851c704b40abe81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0
I have a question on SSRC usage in RTP:
=A0
As per RFC 3550,
=A0
=A0The SSRC identifier is a
=A0=A0=A0=A0=A0 randomly chosen value m= eant to be globally unique within a
=A0=A0=A0=A0=A0 particular RTP sessi= on.=A0 A participant need not
=A0=A0=A0=A0=A0 use the same SSRC identifi= er for all the RTP sessions in a
=A0=A0=A0=A0=A0 multimedia session.
=A0
Question:=A0=A0Is there any possibility of=A0SSRC Identifier be same a= cross consecutive RTP Sessions ? Does Standard emphasis on this ?

--
Thanks & Regards,
R.Ramesh Kumar

--e89a8f83a0e1f851c704b40abe81-- From miguel.a.garcia@ericsson.com Mon Dec 19 23:51: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 9023111E80D8 for ; Mon, 19 Dec 2011 23:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXEM-H0W0PUs for ; Mon, 19 Dec 2011 23:51:16 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B953711E80A2 for ; Mon, 19 Dec 2011 23:51:15 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-fd-4ef03e726ffd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.ED.23425.27E30FE4; Tue, 20 Dec 2011 08:51:14 +0100 (CET) Received: from [159.107.25.6] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Dec 2011 08:51:14 +0100 Message-ID: <4EF03E71.1010705@ericsson.com> Date: Tue, 20 Dec 2011 08:51:13 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic References: <20111219161915.1742E72E002@rfc-editor.org> In-Reply-To: <20111219161915.1742E72E002@rfc-editor.org> X-Forwarded-Message-Id: <20111219161915.1742E72E002@rfc-editor.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Fwd: RFC 6466 on IANA Registration of the 'image' Media Type for the Session Description Protocol (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, 20 Dec 2011 07:51:16 -0000 FYI -------- Original Message -------- Subject: RFC 6466 on IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) Date: Mon, 19 Dec 2011 17:19:14 +0100 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org , rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6466 Title: IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) Author: G. Salgueiro Status: Standards Track Stream: IETF Date: December 2011 Mailbox: gsalguei@cisco.com Pages: 6 Characters: 11660 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-salgueiro-mmusic-image-iana-registration-09.txt URL: http://www.rfc-editor.org/rfc/rfc6466.txt This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. [STANDARDS-TRACK] 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From petithug@acm.org Tue Dec 20 09:16:55 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 8C72521F88B7 for ; Tue, 20 Dec 2011 09:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.8 X-Spam-Level: X-Spam-Status: No, score=-100.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfw3ZPTlrzrk for ; Tue, 20 Dec 2011 09:16:55 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CE76B21F85DB for ; Tue, 20 Dec 2011 09:16:54 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 81DD720444 for ; Tue, 20 Dec 2011 17:04:55 +0000 (UTC) Message-ID: <4EF0C302.4090908@acm.org> Date: Tue, 20 Dec 2011 09:16:50 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: "mmusic@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Error in RFC 3407? 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, 20 Dec 2011 17:16:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The example at the bottom of page 5 looks incorrect: "v=0 o=- 25678 753849 IN IP4 128.96.41.1 s= c=IN IP4 128.96.41.1 t=0 0 m=audio 3456 RTP/AVP 18 96 a=rtpmap:96 telephone-event a=fmtp:96 0-15,32-35 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 0 18 96 a=cpar: a=fmtp:96 0-16,32-35 a=cdsc: 4 image udptl t38 a=cdsc: 5 image tcp t38" AFAIK the clock rate is mandatory, so the a=rtpmap line should be: a=rtpmap:96 telephone-event/1000 If I do not receive emails stating that I am wrong in the next few days, I will fill an errata. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO8ML5AAoJECnERZXWan7E/nEP/2Bg12DvPQcFrh3QdiSTZ9qT miLRM48XZ6LHwR+WubsGkSOesPtrwtfd7zgqHwt+lh415izps58gYtHD9yt9ozMx cFoWAZpFMcOd5lVlSDSU+83l9I5TSAO/+W+HFFlNIwa9/VKJnVvBRjVolHxPj1Yb DYSwkzp4X73z6j/bHElH4pjVBXnlXPAwvqH1buRVn9h3BKQA9v3/1PN7nMO+ERpY z382+a8VwDUmv3aWAmpVmX3jjMhAr1/pngiCvEV0i7zGbMtYjGt8uiAQiyTBCgRa 8Oc4DkMfdLDDyUta0eTlBO/6+p5AZ+9ulEl4crn/gtwqjUUEoNOhHoNOJhMa+GlM FJ6D9f5NMxaBysC1xY7RmwmrERMBuKhL/tTRvxg/D+7T0zj8SHK8XS4Cdd95qV6t AsARa42AXgap/w5t0GGoBYBNjEo9TtlhsGvJKgepxEYMaf5hRCs5TadrMrEUCK3G fg2CdH/5X/s1BBNmRBmRCzAKGsD9N6qqwZARzzfBj+Ee2jRwh6VVyXQlJZ7BQ1i9 e2bFLEwWII0hMVc/RKWA4lrQqWzwpvZ/dv35F5NtVX/GbOFuS9ItQ0J1X0gISxEO yTt/kY+ei8aNdoRnbmFC/OGgHYtEMy1UApYUCef9uUrNYURl4YpaUOvvYgoiELXX 0J9YY4iGmjTcYm0C9gqF =dpRU -----END PGP SIGNATURE----- From albrecht.schwarz@alcatel-lucent.com Tue Dec 20 09:50:27 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 0D7F021F87D3 for ; Tue, 20 Dec 2011 09:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2xYcqs7gsFa for ; Tue, 20 Dec 2011 09:50:25 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 80B9021F877F for ; Tue, 20 Dec 2011 09:50:22 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pBKHoI0Q030861 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Dec 2011 18:50:18 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 20 Dec 2011 18:50:18 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Marc Petit-Huguenin , "mmusic@ietf.org" Date: Tue, 20 Dec 2011 18:50:16 +0100 Thread-Topic: [MMUSIC] Error in RFC 3407? Thread-Index: Acy/OzC4ilzikxMBT867Prj6RHQqQQAA//gg Message-ID: <5F7BCCF5541B7444830A2288ABBEBC962162344DEF@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <4EF0C302.4090908@acm.org> In-Reply-To: <4EF0C302.4090908@acm.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [MMUSIC] Error in RFC 3407? 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, 20 Dec 2011 17:50:27 -0000 The rate parameter for telephone events is OPTIONAL (RFC 4733, ex 2833). See =A7 7.1.2/RFC 4733. The concept as such, as well as the default value, makes perfectly sense (e= .g., also from an historical point of narrowband voice codecs). Thus, RFC 4733/2833 takes precedence over RFC 4566/2327. If you want to enhance the RFCs, then that relation could be added. -Albrecht ALCATEL-LUCENT =20 > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin > Sent: Dienstag, 20. Dezember 2011 18:17 > To: mmusic@ietf.org > Subject: [MMUSIC] Error in RFC 3407? >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > The example at the bottom of page 5 looks incorrect: >=20 > "v=3D0 > o=3D- 25678 753849 IN IP4 128.96.41.1 > s=3D > c=3DIN IP4 128.96.41.1 > t=3D0 0 > m=3Daudio 3456 RTP/AVP 18 96 > a=3Drtpmap:96 telephone-event > a=3Dfmtp:96 0-15,32-35 > a=3Dsqn: 0 > a=3Dcdsc: 1 audio RTP/AVP 0 18 96 > a=3Dcpar: a=3Dfmtp:96 0-16,32-35 > a=3Dcdsc: 4 image udptl t38 > a=3Dcdsc: 5 image tcp t38" >=20 > AFAIK the clock rate is mandatory, so the a=3Drtpmap line should be: >=20 > a=3Drtpmap:96 telephone-event/1000 >=20 > If I do not receive emails stating that I am wrong in the=20 > next few days, I will fill an errata. >=20 > Thanks. >=20 > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJO8ML5AAoJECnERZXWan7E/nEP/2Bg12DvPQcFrh3QdiSTZ9qT > miLRM48XZ6LHwR+WubsGkSOesPtrwtfd7zgqHwt+lh415izps58gYtHD9yt9ozMx > cFoWAZpFMcOd5lVlSDSU+83l9I5TSAO/+W+HFFlNIwa9/VKJnVvBRjVolHxPj1Yb > DYSwkzp4X73z6j/bHElH4pjVBXnlXPAwvqH1buRVn9h3BKQA9v3/1PN7nMO+ERpY > z382+a8VwDUmv3aWAmpVmX3jjMhAr1/pngiCvEV0i7zGbMtYjGt8uiAQiyTBCgRa > 8Oc4DkMfdLDDyUta0eTlBO/6+p5AZ+9ulEl4crn/gtwqjUUEoNOhHoNOJhMa+GlM > FJ6D9f5NMxaBysC1xY7RmwmrERMBuKhL/tTRvxg/D+7T0zj8SHK8XS4Cdd95qV6t > AsARa42AXgap/w5t0GGoBYBNjEo9TtlhsGvJKgepxEYMaf5hRCs5TadrMrEUCK3G > fg2CdH/5X/s1BBNmRBmRCzAKGsD9N6qqwZARzzfBj+Ee2jRwh6VVyXQlJZ7BQ1i9 > e2bFLEwWII0hMVc/RKWA4lrQqWzwpvZ/dv35F5NtVX/GbOFuS9ItQ0J1X0gISxEO > yTt/kY+ei8aNdoRnbmFC/OGgHYtEMy1UApYUCef9uUrNYURl4YpaUOvvYgoiELXX > 0J9YY4iGmjTcYm0C9gqF > =3DdpRU > -----END PGP SIGNATURE----- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From petithug@acm.org Tue Dec 20 09:58:28 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 0F93021F8AB9 for ; Tue, 20 Dec 2011 09:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.8 X-Spam-Level: X-Spam-Status: No, score=-100.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eJXdVpEteqP for ; Tue, 20 Dec 2011 09:58:27 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 5165521F85A7 for ; Tue, 20 Dec 2011 09:58:27 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6A53C20444; Tue, 20 Dec 2011 17:46:28 +0000 (UTC) Message-ID: <4EF0CCBF.2030604@acm.org> Date: Tue, 20 Dec 2011 09:58:23 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <4EF0C302.4090908@acm.org> <5F7BCCF5541B7444830A2288ABBEBC962162344DEF@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC962162344DEF@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Error in RFC 3407? 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, 20 Dec 2011 17:58:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/20/2011 09:50 AM, Schwarz, Albrecht (Albrecht) wrote: > The rate parameter for telephone events is OPTIONAL (RFC 4733, ex 2833). In the MIME type it is optional with adefault value of 8000, but the rate parameter in rtpmap is not optional (section 6 of RFC 4566): "a=rtpmap: / [/]" > See § 7.1.2/RFC 4733. > The concept as such, as well as the default value, makes perfectly sense (e.g., also from an historical point of narrowband voice codecs). > > Thus, RFC 4733/2833 takes precedence over RFC 4566/2327. > > If you want to enhance the RFCs, then that relation could be added. > > -Albrecht > ALCATEL-LUCENT > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin >> Sent: Dienstag, 20. Dezember 2011 18:17 >> To: mmusic@ietf.org >> Subject: [MMUSIC] Error in RFC 3407? >> > The example at the bottom of page 5 looks incorrect: > > "v=0 > o=- 25678 753849 IN IP4 128.96.41.1 > s= > c=IN IP4 128.96.41.1 > t=0 0 > m=audio 3456 RTP/AVP 18 96 > a=rtpmap:96 telephone-event > a=fmtp:96 0-15,32-35 > a=sqn: 0 > a=cdsc: 1 audio RTP/AVP 0 18 96 > a=cpar: a=fmtp:96 0-16,32-35 > a=cdsc: 4 image udptl t38 > a=cdsc: 5 image tcp t38" > > AFAIK the clock rate is mandatory, so the a=rtpmap line should be: > > a=rtpmap:96 telephone-event/1000 > > If I do not receive emails stating that I am wrong in the > next few days, I will fill an errata. > > Thanks. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO8My9AAoJECnERZXWan7E2BgQAJhM6ihOIw3NhfVCbRrFAUi2 dCMunZuJJHOxn7j4jlStxQ9eMZI6AoLncfSQZ48fL2Yts1mZOsFvxnCtqMIWmwzA jOpdv1kwinWHMBqZfruPXbcmWOcJmWxQx5L8yMnr8mImgLftVqczCj9XQXmjIiqX i7N2IGEhacstyepA/LG1nCUUBKKngIy9B/i8z4zEYGFT0z8Tv4eTzqh+a/ZKRXp3 pRjMI03RhUthYQOJs/JKUS5gmVYmSqVlu0ZwMo0zEUm91q2YEKAZgP45NviKh1vB ADUyOxsiemHMfTP9lMaIcBjmd8PM4mhtOBQFTGpc6XUDsPh6PJZz+VgV7eb1j0mN XZy7NXmEtFxs7vta0L7NEDV7CeP39nliHxjrzml6i6CrghSNeR2I3yYoPs0nXnVo z8dRTeldpBIoUJ2BrtGcjH7fDIhVbQR7ZJfER0ciPEla0YCWW9IP1X9CnIYV42Z9 1plaUKjb+O/OQvidnouxmqrtwn3R1PQAshpOgG16OrpDkAGmZEyXCeqkreQKOmSJ bIzqHsaEzbIlCBOWfHHSCg8B9dsNVaZrCeQRsHzKaPQlfBCMlctzLcNj92FpWNwh I/tMW7HwA1li3SscjkVx0o0gMqwdMC12Dz8jk/m3RItlIc6VDqNNG1fFnwJFb7L3 yMVmPvaKMORQcFjUUymb =eH8i -----END PGP SIGNATURE----- From petithug@acm.org Tue Dec 20 16:33:47 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 4452921F84BB for ; Tue, 20 Dec 2011 16:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YsM8e-QXH7B for ; Tue, 20 Dec 2011 16:33:46 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 864D421F84BA for ; Tue, 20 Dec 2011 16:33:46 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 7B78B20444 for ; Wed, 21 Dec 2011 00:21:46 +0000 (UTC) Message-ID: <4EF12965.8030709@acm.org> Date: Tue, 20 Dec 2011 16:33:41 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: "mmusic@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Error in RFC 5245 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, 21 Dec 2011 00:33:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Section 15.3 states that: '"ice-mismatch" is a media-level attribute only.[...]' But section 21.1.4 (and IANA) declares this attribute as a session level attribute. It seems logical to have ice-mismatch as a media level attribute, but I guess that something more than an errata is needed to fix the wrong IANA declaration. What is the process in this case? Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO8SlkAAoJECnERZXWan7EtB4P/2FYooLdQYaNT297tBFTgoJk k8DWm79c+8NCm6WtlHwuisqWfTry9zRUS+Lr9ViCpid5hC1tv2l0cFP5tbR+jXsB 0+9zlaorZ6AgbNZucGxOcV0tnVVfQN8pH7V74rSbChknEVL4buybLED2OGrJe1n8 Q+0wHeT31J1Csc8s/wwzlePFl/J8FpRPAd9DIzSYvHlpCUpbnVuasEpvYwC4+XXp XlR2HxtXw7D19sE9dz1xl1kAdYMlkyioaxZy8C3mNbM6BJxzTMB2FOjrb11M/ykV zakIYGfX6HbzmyRf7Tu5s5XZY6Tv92R31RkcEOQbPrwycZtPJkn+iGHxd7ab5E0S vPDxuu5LzoFcv9PSuYMIw7cWOXrbd/VLnXJErluU8GdhDBCVAvbckw9Wrm5COhlU 52rRphlmlBq9dpcvNdsbiAzuT4PcKCBugiOrOX70QTOy4DnWDXTDeInuXqHE296/ ztn7+iX0nLBqwyVLvTX6TwxusKs3lrj11g6y+6dfoqPS5hRjyq59VChYQm79qNd3 P8hXdvLWx9yRKWg30k1DBsnb6cz7zWnDUaN2Ks6OOkN+nC1MKdV/m89qkCJ0eI28 fV3Lb7Lb4A2pJ3sZq8MYu+0qV/LdcJeYdb/PIJk+Jm+Icj0dHU0EU86i0Wq9VcEL pXAEb2PJntrS6oAv4YC+ =bJdZ -----END PGP SIGNATURE----- From petithug@acm.org Tue Dec 20 17:00: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 BDF201F0C40 for ; Tue, 20 Dec 2011 17:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k29RVHB5925Z for ; Tue, 20 Dec 2011 17:00:26 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E09081F0C38 for ; Tue, 20 Dec 2011 17:00:25 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 22E3320444 for ; Wed, 21 Dec 2011 00:48:26 +0000 (UTC) Message-ID: <4EF12FA7.5080608@acm.org> Date: Tue, 20 Dec 2011 17:00:23 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: "mmusic@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Fwd: I-D Action: draft-petithuguenin-mmusic-ice-attributes-level-02.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: Wed, 21 Dec 2011 01:00:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This document was not presented in Taipei for lack of time, but it was discussed in the Quebec City meeting. As the minutes show, at the time there was discussions about the problem been perhaps larger than just for ICE. I did an analysis of all the session level only attributes currently registered by IANA and my conclusion is that only ICE has this problem. The analysis for each attribute was added in the document as an appendix. Also, as explained in my previous email, it seems that ice-mismatch was incorrectly registered as a session level attribute. This document could be a good place to fix this if a standard track document is needed for that. Changelog: o Added reference to RFC 5245 in the abstract (idnits). o Changed author affiliation. o Added analysis of all IANA registered session level only attributes. o Added sections for ice-lite and ice-mismatch. [1] http://www.ietf.org/proceedings/81/minutes/mmusic.txt - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-mmusic-ice-attributes-level-02.txt Date: Tue, 20 Dec 2011 16:48:19 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Media level ice-options SDP attribute Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-mmusic-ice-attributes-level-02.txt Pages : 14 Date : 2011-12-20 This document normatively updates RFC 5245 by redefining the ice- options SDP attribute as a session-level and media-level attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-mmusic-ice-attributes-level-02.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-petithuguenin-mmusic-ice-attributes-level-02.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO8S+jAAoJECnERZXWan7EP0EP/RW7pw8nG6WDX9EKt/tFYuqz uVx0pBx7oUV45c2/JgyjCnMe9DGXU2QQU3Kc6m7LhEgqdkKIOnOYJjB2atZNgA2Y cT3ph+qKAGMhADEsfKbtGq1jSqfWDlhoDaxy2u9y+oGv4Hn6nHCI2Ppe2J2W+5oc IXaKT6XD8KAyG4UmehgX72mvmT8l07LFwRLINiw+DdYsC17OB5hKAnyjz2LTD3ed ui3e6gYK8jPl1Qv0jmVTU3cbRfehb3x1dMXl0N7Un7qxU0Oxzcau17hh2D7n/64E hjHaNY3DgyCtiAHe8Ppq2R6ag2ee4nzM5GYfRQvNRTUOId4WkZAo/drdVdIVqxXM SQxeaNKkJ8VKz0fmj5OnnUlUWSnaTFbJdkJKxBtuo/7ZL4MiPPgSOyDeruhiZK1w CgcCDH6+WNlgkT1O3WUOc7zCcyDkABa994qzc27O4kn32YKcaD0u113BGc+2TIaP SYiVIWpVkQjdXHqyr40baMuVEJLGYI09RW2L9ygsaDPwK8x5/exedfDPSD2oCzf3 E1EeDAcur9TmmQSgXn5bdTX/F32zhlpAQxtRsNyYLxESZKkFx0/86zin0GWl2kbE y6BmxKnpqGvBGG79soWgXB3bY9pTVrKs10mesJ9aJkXyMiIg6FdXIKMklRbW48lJ ipIpGKC8Oa0nXA6bpTb9 =UGsd -----END PGP SIGNATURE----- From amostafa@avaya.com Fri Dec 23 14:43:24 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 14A3121F8557 for ; Fri, 23 Dec 2011 14:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[AWL=-2.904, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_27=0.6, MANGLED_SAVELE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjsUiW2DxrWx for ; Fri, 23 Dec 2011 14:43:22 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8721F8512 for ; Fri, 23 Dec 2011 14:43:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE8C9U7GmAcF/2dsb2JhbABAAQKsOYEFgWkQEhUGOQIfBAELAQkhGhQcJgEEEwgGDQeHYJg8hBObGwSIbAELAoIuYwSIN4VvjEuMYw X-IronPort-AV: E=Sophos;i="4.71,401,1320642000"; d="txt'?scan'208,217";a="223797266" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Dec 2011 17:43:20 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Dec 2011 17:40:02 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Fri, 23 Dec 2011 17:43:20 -0500 From: "Mostafa, Adel (Adel)" To: "mmusic@ietf.org" Date: Fri, 23 Dec 2011 17:43:18 -0500 Thread-Topic: draft-mostafa-mmusic-sip-cp-00 Thread-Index: AczBxEQ++goa8w0HSpKyk8ThhHP8Cg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_E151F470685C15418AEA609E825A171022D3594094DCUS1MBEX4glo_" MIME-Version: 1.0 Subject: [MMUSIC] draft-mostafa-mmusic-sip-cp-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: Fri, 23 Dec 2011 22:43:24 -0000 --_004_E151F470685C15418AEA609E825A171022D3594094DCUS1MBEX4glo_ Content-Type: multipart/alternative; boundary="_000_E151F470685C15418AEA609E825A171022D3594094DCUS1MBEX4glo_" --_000_E151F470685C15418AEA609E825A171022D3594094DCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First draft for negotiating multi-stream Continuous Presence Video in SIP, = please let me know if any comments. Regards, Adel Mostafa|Unified Communications Architect, P.Eng.|Avaya R&D|Canada|Offi= ce: +1.613.967.5514 --_000_E151F470685C15418AEA609E825A171022D3594094DCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
First draft for negotiating multi-stream Continuous Presence Video in = SIP, please let me know if any comments.
 
Regards,
Adel Mostafa|Unified Communicatio= ns Architect, P.Eng.|Avaya R&D|Canada|Office: +1.613.967.5514  
 
 
 
 --_000_E151F470685C15418AEA609E825A171022D3594094DCUS1MBEX4glo_-- --_004_E151F470685C15418AEA609E825A171022D3594094DCUS1MBEX4glo_ Content-Type: text/plain; name="draft-mostafa-mmusic-sip-cp-00.txt" Content-Description: draft-mostafa-mmusic-sip-cp-00.txt Content-Disposition: attachment; filename="draft-mostafa-mmusic-sip-cp-00.txt"; size=21073; creation-date="Fri, 22 Jul 2011 15:54:52 GMT"; modification-date="Fri, 23 Dec 2011 17:36:20 GMT" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQS4gTW9zdGFmYSwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdmF5YQpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjMsIDIwMTEKRXhwaXJl czogSnVuZSAyNSwgMjAxMgoKCiBBIE1lY2hhbmlzbSBmb3IgTmVnb3RpYXRpbmcgTXVsdGktU3Ry ZWFtIENvbnRpbnVvdXMgUHJlc2VuY2UgVmlkZW8gaW4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFNJUAogICAgICAgICAgICAgICAgICAgICBkcmFmdC1tb3N0YWZhLW1tdXNpYy1z aXAtY3AtMDAKCkFic3RyYWN0CgogICBUaGUgTmV4dEdlbiB2aWRlbyBjb25mZXJlbmNpbmcgY2xp ZW50cyByZXF1aXJlIG11bHRpcGxlIGNvbmN1cnJlbnQKICAgdmlkZW8gc3RyZWFtcyB0byBwcm92 aWRlIGEgVXNlciBlWHBlcmllbmNlIChVWCkgaW4gd2hpY2ggbXVsdGlwbGUKICAgcGFydGljaXBh bnRzIGNhbiBiZSB2aWV3ZWQgYXQgdGhlIHNhbWUgdGltZSwgdGhpcyB1c2VyIGV4cGVyaWVuY2Ug aXMKICAgY2FsbGVkIENvbnRpbnVvdXMgUHJlc2VuY2UgKENQKSB2aWRlby4gIFRoZSBtdWx0aS1z dHJlYW0gQ1AgdmlkZW8KICAgcHJvdmlkZXMgbW9yZSBjbGllbnQgY29udHJvbCBvZiB0aGUgVVgg YW5kIGxlc3MgcHJvY2Vzc2luZyBvbiB0aGUKICAgY29uZmVyZW5jZSBzZXJ2ZXIgc2luY2UgdGhl IHZpZGVvIHN0cmVhbXMgYXJlIHJlbGF5ZWQgYnkgdGhlIHNlcnZlcgogICByYXRoZXIgdGhhbiBt aXhlZCB0byBjb21wb3NlIGEgQ1AgdmlkZW8gc3RyZWFtLiAgVGhlIGNsaWVudCBDUAogICBsYXlv dXQsIHByb2Nlc3NpbmcgcG93ZXIgYW5kIGJhbmR3aWR0aCBsaW1pdGF0aW9ucyByZXF1aXJlIGEg cGVyCiAgIHN0cmVhbSBiYW5kd2lkdGggYW5kIHJlc29sdXRpb24gdG8gYmUgbmVndGlhdGVkIGlu IHRoZSBTSVAgT2ZmZXIvCiAgIEFuc3dlciB3aXRoIHRoZSBjb25mZXJlbmNlIHNlcnZlci4gIFN0 YW5kYXJkIG1ldGhvZHMgYXJlIHVzZWQgdG8KICAgYWNoaWV2ZSB0aGlzIG5lZ290aWF0aW9uIGlu IGFkZGl0aW9uIHRvIGEgbmV3IFNEUCBwYXJhbWV0ZXIuICBUaGlzCiAgIGRvY3VtZW50IGV4cGxh aW5zIHRoZSBtZXRob2RvbG9neSBhbmQgc29sdXRpb24gdG8gYWNoaWV2ZSB0aGlzIGluIFNJUAog ICBhbmQgU0RQLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBp cyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9m IEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBO b3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0K ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVu dC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwg b3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdW5lIDI1LCAyMDEyLgoKQ29weXJpZ2h0 IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25z IGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2Vy dmVkLgoKCgoKTW9zdGFmYSAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjUsIDIwMTIg ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU0lQIE11 bHRpLVN0cmVhbSBDUCBWaWRlbyAgICAgICAgICBEZWNlbWJlciAyMDExCgoKICAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNh dGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAg Y2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMg d2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFj dGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVn YWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVz Y3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKClRhYmxlIG9mIENvbnRlbnRz CgogICAxLiAgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDMKICAgMi4gIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgICAgMi4xLiAgS2V5IFdvcmRzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDIu Mi4gIEFiYnJldmlhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDMKICAgICAyLjMuICBWb2ljZSBBY3RpdmF0ZWQgU3dpdGNoaW5nICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgICAgMi40LiAgQ29udGludW91cyBQcmVzZW5jZSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDIuNS4gIFZpZGVv IFNodWZmbGluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMK ICAgMy4gIE11bHRpLVN0cmVhbSBDb250aW51b3VzIFByZXNlbmNlIFZpZGVvIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA0CiAgIDQuICBNdWx0aS1TdHJlYW0gQ29udGludW91cyBQcmVzZW5jZSB2 aWRlbyBTSVAgYW5kIFNEUAogICAgICAgbmVnb3RpYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICA0LjEuICBCYXNpYyBTSVAgYW5k IFNEUCBuZWdvdGlhdGlvbiBhbmQgZmxvd3MgZm9yCiAgICAgICAgICAgbXVsdGktc3RyZWFtIENQ IFZpZGVvICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgICAgNC4x LjEuICBDbGllbnQgSW5ib3VuZCBDUCBWaWRlbyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDUKICAgICAgIDQuMS4yLiAgQ2xpZW50IE91dGJvdW5kIFZpZGVvICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgICA0LjEuMy4gIEF1ZGlvICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDQuMi4gIEFkdmFuY2Vk IFNJUCBhbmQgU0RQIG5lZ290aWF0aW9uIGFuZCBmbG93cyBmb3IKICAgICAgICAgICBtdWx0aS1z dHJlYW0gQ1AgVmlkZW8gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAg ICAgICA0LjIuMS4gIFNEUCBjb250ZW50IGF0dHJpYnV0ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNQogICAgICAgNC4yLjIuICBWQVMgUmFuayAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgNS4gIEFjdGl2ZSBUYWxrZXIgSW5kaWNh dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgIDYuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOQogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgOC4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgIDkuICBSZWZlcmVuY2VzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAg IDkuMS4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDkKICAgICA5LjIuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgIEF1dGhvcidzIEFkZHJlc3MgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAoKCgoKCgoKCgoKCk1v c3RhZmEgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDI1LCAyMDEyICAgICAgICAgICAg ICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNJUCBNdWx0aS1TdHJlYW0g Q1AgVmlkZW8gICAgICAgICAgRGVjZW1iZXIgMjAxMQoKCjEuICBPdmVydmlldwoKICAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgdGhlIFNJUCBhbmQgU0RQIG5lZ290aWF0aW9uIHJlcXVpcmVkIGZv ciB0aGUKICAgbXVsdGktc3RyZWFtIENQIHZpZGVvIHVzaW5nIHZpZGVvIGNvZGVjcyBzdWNoIGFz IEguMjY0IFNWQyBhbmQgQVZDCiAgIChTVkM6IFNjYWxhYmxlIFZpZGVvIENvZGluZywgQVZDOiBB ZHZhbmNlZCBWaWRlbyBDb2RpbmcpLiAgSXQgY292ZXJzCiAgIHRoZSBDUCBsYXlvdXQgdXNlIGNh c2VzLCBncm91cGluZywgc2h1ZmZsaW5nIGFuZCBiYW5kd2lkdGggc2NhbGluZwogICBmb3IgdGhl IENQIHN0cmVhbXMuCgoKMi4gIFRlcm1pbm9sb2d5CgoyLjEuICBLZXkgV29yZHMKCiAgIFRoZSBr ZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwg Tk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFu ZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IGRlc2NyaWJlZCBpbiBCQ1AgMTQsIFJGQwogICAyMTE5W1JGQzIxMTldLgoKMi4yLiAgQWJicmV2 aWF0aW9ucwoKICAgVkFTOiBWb2ljZSBBY3RpdmF0ZWQgU3dpdGNoaW5nCiAgIENQOiBDb250aW51 b3VzIFByZXNlbmNlCiAgIFVYOiBVc2VyIGVYcGVyaWVuY2UKICAgQlc6IEJhbmR3aWR0aAogICBI LjI2NCBTVkM6IEguMjY0IFNjYWxhYmxlIFZpZGVvIENvZGluZwogICBILjI2NCBBVkM6IEguMjY0 IEFkdmFuY2VkIFZpZGVvIENvZGluZwoKMi4zLiAgVm9pY2UgQWN0aXZhdGVkIFN3aXRjaGluZwoK ICAgVm9pY2UgQWN0aXZhdGVkIFN3aXRjaGluZyBpbiB2aWRlbyBkZWxpdmVycyB0aGUgdmlkZW8g b2Ygc2luZ2xlIHVzZXIKICAgaW4gYSBjb25mZXJlbmNlIHRvIGEgcGFydGljaXBhbnQsIHRoaXMg dXNlciBpcyB0aGUgY3VycmVudCBvciBtb3N0CiAgIHJlY2VudCBhY3RpdmUgc3BlYWtlci4gIEZv ciBleGFtcGxlIEFsaWNlLCBCb2IsIENhcm9sLCBEYXZlIGFuZCBKb2huCiAgIGFyZSB2aWRlbyBw YXJ0aWNwYW50cyBpbiBhIGNvbmZlcmVuY2UsIEFsaWNlIGlzIHRhbGtpbmcsIEpvaG4gd291bGQK ICAgc2VlIEFsaWNlJ3MgdmlkZW8sIHdoZW4gQm9iIHN0YXJ0cyB0YWxraW5nIEpvaG4gc2VlcyBC b2IncyB2aWRlby4KCjIuNC4gIENvbnRpbnVvdXMgUHJlc2VuY2UKCiAgIENvbnRpbnVvdXMgUHJl c2VuY2UgaW4gdmlkZW8gZGVsaXZlcnMgdGhlIHZpZGVvIG9mIG11bHRpcGxlIHVzZXJzIGluCiAg IGEgY29uZmVyZW5jZSB0byBhIHBhcnRpY2lwYW50LiAgRm9yIGV4YW1wbGUgQWxpY2UsIEJvYiwg Q2Fyb2wsIERhdmUKICAgYW5kIEpvaG4gYXJlIHZpZGVvIHBhcnRpY3BhbnRzIGluIGEgY29uZmVy ZW5jZSwgSm9obiBjYW4gc2VlIGEKICAgQ29udGludW91cyBQcmVzZW5jZSB2aWRlbyB0aGF0IHNo b3dzIEFsaWNlLCBCb2IsIENhcm9sIGFuZCBEYXZlIGF0CiAgIHRoZSBzYW1lIHRpbWUgb24gaGlz IHZpZGVvIGNsaWVudCwgdHlwaWNhbGx5IHRoZSB2aWRlbyBvZiB0aGUgbW9zdAogICByZWNlbnQg YWN0aXZlIHNwZWFrZXJzLgoKMi41LiAgVmlkZW8gU2h1ZmZsaW5nCgogICBWaWRlbyBzaHVmZmxp bmcgaXMgdXNlZCBpbiBDb250aW51b3VzIFByZXNlbmNlIHVzZSBjYXNlcy4gIEZvcgogICBleGFt cGxlIEFsaWNlLCBCb2IsIENhcm9sLCBEYXZlLCBNaWtlIGFuZCBKb2huIGFyZSB2aWRlbyBwYXJ0 aWNwYW50cwoKCgpNb3N0YWZhICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyNSwgMjAx MiAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTSVAg TXVsdGktU3RyZWFtIENQIFZpZGVvICAgICAgICAgIERlY2VtYmVyIDIwMTEKCgogICBpbiBhIGNv bmZlcmVuY2UsIEpvaG4gY2FuIHNlZSBhIGZvdXIgd2luZG93cyBDb250aW51b3VzIFByZXNlbmNl CiAgIHZpZGVvIHRoYXQgaGFzIEFsaWNlLCBCb2IsIENhcm9sIGFuZCBEYXZlIG9uIGhpcyBjbGll bnQgYXMgdGhlIG1vc3QKICAgcmVjZW50IGFjdGl2ZSBzcGVha2Vycywgd2hlbiBNaWtlIHN0YXJ0 cyB0YWxraW5nIGhlIGJlY29tZXMgdGhlIG1vc3QKICAgcmVjZW50IGFjdGl2ZSBzcGVha2VyLCB0 aGUgY29uZmVyZW5jZSBzZXJ2ZXIgc2h1ZmZsZXMgTWlrZSwgQWxpY2UsCiAgIEJvYiBhbmQgQ2Fy b2wgc3RyZWFtcyBpbiBwbGFjZSBvZiBwcmV2aW91cyBBbGljZSwgQm9iLCBDYXJvbCBhbmQgRGF2 ZQogICBzdHJlYW1zLCB0aGlzIHJlc3VsdHMgaW4gc2h1ZmZsaW5nIG9mIHBhcnRpY3BhbnRzIGlu IHRoZSBmb3VyIHdpbmRvd3MKICAgQ1AgdmlldyBvbiBjbGllbnQuCgoKMy4gIE11bHRpLVN0cmVh bSBDb250aW51b3VzIFByZXNlbmNlIFZpZGVvCgogICBUaGUgTXVsdGktU3RyZWFtIENvbnRpbnVv dXMgUHJlc2VuY2UgdmlkZW8gZGVsaXZlcnMgbXVsdGktc3RyZWFtCiAgIHZpZGVvIChlLmcuICBI LjI2NCBTVkMgb3IgQVZDKSB0byB0aGUgY2xpZW50IGZyb20gYSBjb25mZXJlbmNlIHNlcnZlcgog ICBmb3IgdGhlIGNsaWVudCB0byBkZWNvZGUgYW5kIHJlbmRlciB0byB0aGUgdXNlci4gIENvbnRp bnVvdXMgUHJlc2VuY2UKICAgdmlkZW8gZGlzcGxheXMgbXVsdGlwbGUgcGFydGljaXBhbnRzJyB3 aW5kb3dzIG9uIHRoZSBjbGllbnQncwogICBkaXNwbGF5LCB1c3VhbGx5IGZvciB0aGUgbW9zdCBy ZWNlbnQgYWN0aXZlIHNwZWFrZXJzLiAgVGhlIG11bHRpLQogICBzdHJlYW0gdmlkZW8gc3RyZWFt cyBhcmUgbmVnb3RpYXRlZCB1c2luZyAobikgdmlkZW8gbSBsaW5lcyBpbiB0aGUKICAgU0RQIHdo ZXJlIG4gPiAxLiBleGFtcGxlIGlzIG49NCB3aGVyZSB0aGUgQ1AgdmlkZW8gY29udGFpbnMgNAog ICBwYXJ0aWNpcGFudHMvc3RyZWFtcy4gIEEgc2luZ2xlIHZpZGVvIG0gbGluZSAobj0xKSBtZWFu cyBubyBDUCBhbmQKICAgdHlwaWNhbGx5IGRpc3BsYXkgdGhlIG1vc3QgcmVjZW50IGFjdGl2ZSBz cGVha2VyLiAgQ3VycmVudCB2aWRlbyBTRFAKICAgbmVnb3RpYXRpb24gY292ZXJzIG9ubHkgdGhl IGNvZGVjcyB1c2VkIChlLmcuICBILjI2NCBTVkMgYW5kIEFWQyksCiAgIGJpdCByYXRlLCBudW1i ZXIgb2YgbGF5ZXJzIHVzZWQgKGluIFNWQyBwZXJbUkZDNjE5MF0pIGFuZCBkaXJlY3Rpb24KICAg KHJlY3Zvbmx5LCBzZW5kcmN2LCBzZW5kb25seSkgYnV0IGRvZXNuJ3QgYWRkcmVzcyB0aGUgdmFy aW91cyBhc3BlY3RzCiAgIG9mIHRoZSBCVyBvcHRpbWl6YXRpb24sIHRoZSBzaHVmZmxpbmcgbWVj aGFuaXNtLCBncm91cGluZyBhbmQgbGF5b3V0CiAgIG9mIHRoZSBDUCB3aW5kb3dzLgoKCjQuICBN dWx0aS1TdHJlYW0gQ29udGludW91cyBQcmVzZW5jZSB2aWRlbyBTSVAgYW5kIFNEUCBuZWdvdGlh dGlvbgoKICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgU0lQIGFuZCBTRFAgbmVnb3RpYXRp b24gcmVxdWlyZWQgZm9yIHRoZQogICBtdWx0aS1zdHJlYW0gQ1AgdmlkZW8sIHNvbWUgdXNlIGNh c2VzLCBmbG93cyBhbmQgZXhhbXBsZXMuCgoKCiAgICAgICAgQXVkaW8vVmlkZW8gKy0tLS0tLS0t LS0tLSsgTXVsdGlzdHJlYW0gQ1AgdmlkZW8gICstLS0tLS0tLS0tKwpBbGljZSAgLS0tLS0tLS0t LS0tPnwgICAgICAgICAgICB8LS0tLS0tLS0tQWxpY2UtLS0tLS0tLT58ICAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgfC0tLS0tLS0tLUJvYi0tIC0tLS0tLS0+fCAg ICAgICAgICB8CkJvYiAgICAtLS0tLS0tLS0tLS0+fCAgICAgICAgICAgIHwtLS0tLS0tLS1EYXZl LS0tLS0tLS0tPnwgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8 LS0tLS0tLS0tTWlrZS0tLS0tLS0tLT58ICAgICAgICAgIHwKQ2Fyb2wgIC0tLS0tLS0tLS0tLT58 ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8CiAgICAgICAg ICAgICAgICAgICAgfCBDb25mZXJlbmNlIHwgICAgICAgICAgICAgICAgICAgICAgIHwgIENsaWVu dCAgfApEYXZlICAgLS0tLS0tLS0tLS0tPnwgICBTZXJ2ZXIgICB8LS0tLS0tTWl4ZWQgQXVkaW8t LS0tLT58ICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgfDwtLS0t LS0tLUF1ZGlvLS0tLS0tLS0tfCAgICAgICAgICB8CkpvaG4gICAtLS0tLS0tLS0tLS0+fCAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwK TWlrZSAgIC0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgfDwtLS0tLS0tLVZpZGVvLS0tLS0tLS0t fCAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxIC0g TXVsdGlwbGUgVmlkZW8gU3RyZWFtcyBDb250aW51b3VzIFByZXNlbmNlCgoKCk1vc3RhZmEgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDI1LCAyMDEyICAgICAgICAgICAgICAgICBbUGFn ZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNJUCBNdWx0aS1TdHJlYW0gQ1AgVmlkZW8g ICAgICAgICAgRGVjZW1iZXIgMjAxMQoKCjQuMS4gIEJhc2ljIFNJUCBhbmQgU0RQIG5lZ290aWF0 aW9uIGFuZCBmbG93cyBmb3IgbXVsdGktc3RyZWFtIENQIFZpZGVvCgogICBNdWx0aS1zdHJlYW0g Q1AgYmFzaWMgbmVnb3RpYXRpb24gaXMgaW5pdGlhdGVkIG9yIGVzY2FsYXRlZCBieQogICBjbGll bnRzIHdoZXJlIGEgY2xpZW50IG5lZ290aWF0ZXMgbXVsdGlwbGUgdmlkZW8gbSBsaW5lcyB0byBy ZWNlaXZlCiAgIHRoZSBDUCB2aWRlbywgdGhpcyBjb3VsZCBiZSBkb25lIGluIHRoZSBpbml0aWFs IG9mZmVyIGZyb20gY2xpZW50IHRvCiAgIGNvbmZlcmVuY2Ugc2VydmVyIG9yIGluIGEgcmUtSU5W SVRFLgoKNC4xLjEuICBDbGllbnQgSW5ib3VuZCBDUCBWaWRlbwoKICAgQ29uZmVyZW5jZSBzZXJ2 ZXIgTUFZIGFjY2VwdCBhbGwgdmlkZW8gbSBsaW5lcywgc29tZSwgb25lIG9yIG5vbmUKICAgKGF1 ZGlvIG9ubHkgY2FsbCkgZGVwZW5kaW5nIG9uIGNvbmZlcmVuY2Ugc2VydmVyIGNhcGFiaWxpdGll cyBhbmQKICAgcG9saWNpZXMuICBUaGUgY29uZmVyZW5jZSBzZXZlciBzaG91bGQgdXNlIG09MCBp biB0aGUgYW5zd2VyIGZvciB0aGUKICAgbSBsaW5lcyB0aGF0IGl0IHdvdWxkIGxpa2UgdG8gcmVq ZWN0LiAgQ29uZmVyZW5jZSBzZXJ2ZXIgY2FuIHJlLQogICBJbnZpdGUgdG8gZXNjYWxhdGUvZGUt ZXNjYWxhdGUgdGhlIG51bWJlciBvZiB2aWRlbyBzdHJlYW1zICh3aXRoIG0KICAgIT0wKSBhcyBw YXJ0aWNpcGFudHMgam9pbi9sZWF2ZS4gIFRoZSBzZXJ2ZXIgU0hPVUxEIE5PVCBhZGQgYW55IGV4 dHJhCiAgIHZpZGVvIG0gbGluZXMgaW4gdGhlIGFuc3dlciB0aGFuIHRoZSBvbmVzIG9yaWdpbmFs eSBvZmZlcmVkIGJ5CiAgIGNsaWVudC4KCjQuMS4yLiAgQ2xpZW50IE91dGJvdW5kIFZpZGVvCgog ICBUaGUgQ29uZmVyZW5jZSBzZXJ2ZXIgU0hPVUxEIE5PVCB1c2UgbW9yZSB0aGFuIG9uZSB2aWRl byBtIGxpbmUgaW4KICAgdGhlIG91dGRpYWwgdG8gY2xpZW50IHVzZSBjYXNlcywgdGhpcyBpcyB0 byBhY2hpZXZlIGJldHRlciBiYWNrd2FyZAogICBjb21wYXRpYmlsdHkgd2l0aCBvbGRlciB2aWRl byBjbGllbnRzIHRoYXQgZG9uJ3Qgc3VwcG9ydCBtdWx0aS1zdHJlYW0KICAgdmlkZW8uICBPbmx5 IHRoZSBjbGllbnQgY2FuIGVzY2FsYXRlIHRoZSBudW1iZXIgb2YgdmlkZW8gbSBsaW5lcyBpdAog ICBjYW4gcmVjZWl2ZSB1c2luZyBhIHJlLUlOVklURS4gIEEgc2VwYXJhdGUgbSBsaW5lIGZvciBv dXRib3VuZCB2aWRlbwogICBNQVkgYmUgbmVnb3RpYXRlZCwgdGhlIG91dGJvdW5kIHZpZGVvIE1B WSBhbHNvIGJlIG5lZ290aWF0ZWQgaW4gb25lCiAgIG9mIHRoZSBDUCBpbmJvdW5kIG0gbGluZXMg KHNlbmRyZWN2KS4KCjQuMS4zLiAgQXVkaW8KCiAgIEEgc2luZ2xlIGF1ZGlvIHN0cmVhbSBpcyBu ZWdvdGlhdGVkIGJ5IGEgc2VwYXJhdGUgYXVkaW8gbSBsaW5lLCB0aGUKICAgaW5ib3VuZCBhdWRp byB0byBjbGllbnQgaXMgbWl4ZWQgYnkgdGhlIGNvbmZlcmVuY2Ugc2VydmVyLgoKNC4yLiAgQWR2 YW5jZWQgU0lQIGFuZCBTRFAgbmVnb3RpYXRpb24gYW5kIGZsb3dzIGZvciBtdWx0aS1zdHJlYW0g Q1AKICAgICAgVmlkZW8KCiAgIEEgbmV3IFNEUCBhdHRyaWJ1dGUgaXMgZGlzY3Vzc2VkIGluIHRo aXMgc2VjdGlvbi4gIFRoaXMgYXR0cmlidXRlCiAgIGNvbW11bmljYXRlcyB0aGUgY2xpZW50IHBy ZWZlcmVuY2VzIGZvciB0aGUgQ1Agc3RyZWFtcy4KCjQuMi4xLiAgU0RQIGNvbnRlbnQgYXR0cmli dXRlCgogICBBIG5ldyBjb250ZW50IGF0dHJpYnV0ZSBpcyBuZWdvdGlhdGVkIGluIGVhY2ggbSBs aW5lIGJ5IHRoZSBjbGllbnQsCiAgIHRoaXMgYXR0cmlidXRlIGlzIHNlbnQgYnkgY2xpZW50IGlu IHRoZSB2aWRlbyBtIGxpbmVzIG5lZ290aWF0ZWQgaW4KICAgdGhlIFNEUCBvZmZlci9hbnN3ZXIg Zm9yIENQIHZpZGVvLCBmb2xsb3dzIHRoZSBzdGFuZGFyZFtSRkMzMjYxXSBhbmQKICAgW1JGQzMy NjRdLgoKICAgYT1jb250ZW50OiB3aW5kb3ctaWQsIGdyb3VwIG51bWJlciwgYncgcmVkdWN0aW9u IGxpbWl0LCBWQVMgUmFuawoKCgoKTW9zdGFmYSAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1 bmUgMjUsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgU0lQIE11bHRpLVN0cmVhbSBDUCBWaWRlbyAgICAgICAgICBEZWNlbWJlciAyMDExCgoK ICAgd2luZG93LWlkID0gMSBkaWdpdDsgd2luZG93MSwgd2luZG93Miwgd2luZG93MywgLi4KCiAg IGdyb3VwIG51bWJlciA9IDEtMiBkaWdpdHMgO3JhbmdlIDEtOTksIGxvd2VyIG51bWJlciA9IGhp Z2hlciBwcmlvcml0eQoKICAgYmFuZHdpZHRoIHJlZHVjdGlvbiBsaW1pdCA9IDEtMyBkaWdpdHMg OyByYW5nZSAwLTEwMDsKICAgMCA9IG5vIHJlZHVjdGlvbiBhbGxvd2VkLCAxMDAgPSBmdWxsIHJl ZHVjdGlvbiBpcyBhbGxvd2VkLgoKICAgVkFTIFJhbmsgPSAxIGRpZ2l0IDsgcmFuZ2UgMC05Cgog ICBUaGUgbmV3IGNvbnRlbnQgYXR0cmlidXRlIGlzIG5lZ290aWF0ZWQgYnkgdGhlIGNsaWVudCB0 byBjb21tdW5pY2F0ZQogICB0aGUgY2xpZW50IENQIHN0cmVhbXMgZ3JvdXBpbmcsIEJXIG9wdGlt aXphdGlvbiBhbmQgdmlkZW8gc2h1ZmZsaW5nCiAgIG1lY2hhbmlzbS4gIFRoZXJlIGlzIG5vIGFu c3dlciBmb3IgdGhpcyBhdHRyaWJ1dGUgaW4gdGhlIHJlc3BvbnNlCiAgIGZyb20gdGhlIHNlcnZl ciwgdGhlIGFuc3dlciBpcyByZWZsZWN0ZWQgaW4gdGhlIHJlc3BvbnNlIG0gbGluZXMgYW5kCiAg IHRoZSBzaHVmZmxpbmcgb2YgdGhlIHZpZGVvIFJUUC4gIENvbmZlcmVuY2Ugc2VydmVycyB0aGF0 IGRvbid0CiAgIHN1cHBvcnQgdGhpcyBhdHRyaWJ1dGUgd2lsbCBpZ25vcmUgaXQgYW5kIHdpbGwg cHJvY2VzcyB0aGUgb2ZmZXIKICAgdmlkZW8gbSBsaW5lcyBhY2NvcmRpbmcgdG8gaXRzIG93biBh bGdvcml0aG1zL3ByZWZlcmVuY2VzLiAgVGhlIGdyb3VwCiAgIG51bWJlciBzcGVjaWZpZXMgdGhl IGdyb3VwIHRoYXQgdGhlIHN0cmVhbSBiZWxvbmdzIHRvLiAgQWxsIHN0cmVhbXMKICAgKFVJIHdp bmRvd3MpIGluIHNhbWUgZ3JvdXAgaGF2ZSBzYW1lIHJlc29sdXRpb24vc2l6ZS4gIEEgZ3JvdXAg d2l0aAogICBsb3dlciBudW1iZXIgaGFzIGhpZ2hlciBwcmlvcml0eSB0aGFuIGhpZ2hlciBncm91 cCBudW1iZXIuICBUaGUgQ1AKICAgc3RyZWFtcy93aW5kb3dzIGFyZSBncm91cGVkIHdpdGhpbiBh IGxheW91dCwgZ3JvdXBpbmcgYWxsb3dzIHRoZQogICBjb25mZXJlbmNlIHNlcnZlciB0byBzY2Fs ZSBkb3duIGFsbCB3aW5kb3dzIGluIHNhbWUgZ3JvdXAgZm9yIEJXCiAgIG9wdGltaXphdGlvbiBh bmQgdG8gZGVsaXZlciBhIHVuaWZvcm0gdXNlciBleHBlcmllbmNlIGFjcm9zcyB0aG9zZQogICB3 aW5kb3dzLiAgVGhlIGNvbmZlcmVuY2Ugc2VydmVyIHNob3VsZCBzY2FsZSBkb3duIHRoZSBoaWdo IGdyb3VwCiAgIG51bWJlciBmaXJzdCBiZWZvcmUgc2NhbGluZyBkb3duIHRoZSBuZXh0IGdyb3Vw LCBleDogZ3JvdXAyIGZpcnN0IGFuZAogICB0aGVuIGdyb3VwMS4gIFRoZSBiYW5kd2lkdGggcmVk dWN0aW9uIGxpbWl0IHNldHMgdGhlIG1heGltdW0KICAgcGVyY2VudGFnZSBvZiB0aGUgb3JpZ2lu YWwgYmFuZHdpZHRoIHRoYXQgdGhlIGNvbmZlcmVuY2Ugc2VydmVyIGNhbgogICByZWR1Y2UgdG8g c2F0aXNmeSB0aGUgYmFuZHdpZHRoIGNvbnN0cmFpbnRzLgoKICAgQ2xpZW50IE9mZmVyIFNEUCBl eGFtcGxlLiAgRm9yIHNpbXBsaWNpdHksIGF1ZGlvIGFuZCBzcHJvcC1vcGVyYXRpb24tCiAgIHBv aW50LWluZm8gZGV0YWlscyBhcmUgbm90IHNob3duOgoKICAgdj0wCiAgIG89c3Zjc3J2IDI4OTA4 MzEyNCAyODkwODMxMjQgSU4gSVA0IDE5Mi4wLjIuMgogICBzPWNvbmZlcmVuY2UKICAgdD0wIDAK ICAgYj1USUFTOjgxMjAwMAoKICAgbT12aWRlbyAzMDAwMCBSVFAvQVZQIDk4IDk3IDk2CiAgIGM9 SU4gSVA0IDE5Mi4wLjIuMgogICBhPWNvbnRlbnQ6d2luZG93MSwxLDI1LDEKICAgYj1USUFTOjUx MjAwMAogICBhPXJ0cG1hcDo5NiBIMjY0LzkwMDAwCiAgIGE9Zm10cDo5NiBwcm9maWxlLWxldmVs LWlkPTQyNDAxZQogICBhPXJ0cG1hcDo5NyBIMjY0LVNWQy85MDAwMAogICBhPWZtdHA6OTcgcHJv ZmlsZS1sZXZlbC1pZD01MzAwMTY7IHNwcm9wLW9wZXJhdGlvbi1wb2ludC0KICAgaW5mby4uKFZH QS8zMCkKICAgYT1ydHBtYXA6OTggSDI2NC1TVkMvOTAwMDAKICAgYT1mbXRwOjk4IHByb2ZpbGUt bGV2ZWwtaWQ9NTMwMDFlOyBzcHJvcC1vcGVyYXRpb24tcG9pbnQtCgoKCk1vc3RhZmEgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDI1LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA2 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNJUCBNdWx0aS1TdHJlYW0gQ1AgVmlkZW8gICAg ICAgICAgRGVjZW1iZXIgMjAxMQoKCiAgIGluZm8uLig3MjBwLzMwKQogICBhPXNlbmRyZWN2Cgog ICBtPXZpZGVvIDQwMDAwIFJUUC9BVlAgMTAxIDEwMCA5OQogICBjPUlOIElQNCAxOTIuMC4yLjIK ICAgYT1jb250ZW50OndpbmRvdzIsMiw1MCwxCiAgIGI9VElBUzozMDAwMDAKICAgYT1ydHBtYXA6 OTkgSDI2NC85MDAwMAogICBhPWZtdHA6OTkgcHJvZmlsZS1sZXZlbC1pZD00MjQwMWUKICAgYT1y dHBtYXA6MTAwIEgyNjQtU1ZDLzkwMDAwCiAgIGE9Zm10cDoxMDAgcHJvZmlsZS1sZXZlbC1pZD01 MzAwMTM7IHNwcm9wLW9wZXJhdGlvbi1wb2ludC0KICAgaW5mby4uKFZHQS8zMCkKICAgYT1ydHBt YXA6MTAxIEgyNjQtU1ZDLzkwMDAwCiAgIGE9Zm10cDoxMDEgcHJvZmlsZS1sZXZlbC1pZD01MzAw MTY7IHNwcm9wLW9wZXJhdGlvbi1wb2ludC0KICAgaW5mby4uKDM2MC8zMCkKICAgYT1yZWN2b25s eQoKNC4yLjIuICBWQVMgUmFuawoKICAgUnVsZXM6IElmIGNsaWVudCB3YW50cyB0aGUgdmlkZW8g c3RyZWFtL3dpbmRvdyBmcm9tIGNvbmZlcmVuY2Ugc2VydmVyCiAgIHRvIGJlIHN3aXRjaGVkIGJ5 IGFjdGl2ZSBzcGVha2VyIGFjdGl2aXR5LCB0aGVuIGl0IGhhcyB0byBhc3NpZ24gYQogICB2YXNy YW5rIHRvIHRoZSB3aW5kb3cuICBUaGUgY29uZmVyZW5jZSBzZXJ2ZXIgd2lsbCBhc3NpZ24gdGhl IHdpbmRvdwogICBiYXNlZCBvbiB0aGUgYWN0aXZlIHNwZWFrZXIgaGlzdG9yeSBhbmQgcmFuay4g IFJhbmsgMSBnZXRzIHRoZSBtb3N0CiAgIHJlY2VudCBzcGVha2VyLCByYW5rIDIgdGhlIG5leHQg bW9zdCByZWNlbnQsIGV0Yy4gIFlvdSBjYW4gaGF2ZQogICBtdWx0aXBsZSB3aW5kb3dzIHBlciBy YW5rLiAgVGhpcyBhbGxvd3MgdXMgdG8gbWluaW1pemUgdGhlIHNodWZmbGluZwogICB0aGF0IHRh a2VzIHBsYWNlIHdoZW4gdGhlIHNwZWFrZXJzIHN3aXRjaCBpbiBhbmQgb3V0LiAgSWYgbm90CiAg IHNwZWNpZmllZCwgZGVmYXVsdCB2YWx1ZSBpcyAxIGZvciBhbGwgd2luZG93cyAobWluaW11bSBz aHVmZmxpbmcpLgoKICAgRXhhbXBsZSAoMSkgb2Ygc2h1ZmZsaW5nIGluIGEgMngyIG9yIDF4NCBs YXlvdXQgKDQgZXF1YWwgc2l6ZWQKICAgd2luZG93cyk6CiAgIGE9Y29udGVudDogd2luZG93MSwx LDEwMCwgMSAodGhlIG1vc3QgcmVjZW50IHNwZWFrZXIpCiAgIGE9Y29udGVudDogd2luZG93Miwx LDEwMCwgMiAoMm5kIG1vc3QgcmVjZW50KQogICBhPWNvbnRlbnQ6IHdpbmRvdzMsMSwxMDAsIDMg KDNyZCBtb3N0IHJlY2VudCkKICAgYT1jb250ZW50OiB3aW5kb3c0LDEsMTAwLCA0ICg0dGggbW9z dCByZWNlbnQpCgogICBJbiB0aGlzIGV4YW1wbGUgdGhlIGNsaWVudCdzIG9mZmVyIHRvIHRoZSBj b25mZXJlbmNlIHNlcnZlciBoYXMgNAogICB2aWRlbyBTRFAgbSBsaW5lcywgYT1jb250ZW50IChz ZWNvbmQgcGFyYW1ldGVyKSBpcyB0aGUgc2FtZSBmb3IgdGhlCiAgIGZvdXIgbSBsaW5lcywgaW5k aWNhdGluZyBzYW1lIHByaW9yaXR5IGFuZCA0IGVxdWFsIHNpemVkIHdpbmRvd3MuCiAgIFRoZSBw YT1jb250ZW50IGZvciBlYWNoIGhhcyBhIGRpZmZlcmVudCB2YXMgcmFuayB2YWx1ZSAobGFzdAog ICBwYXJhbWV0ZXIgaW4gdGhlIGV4YW1wbGVzIGFib3ZlKS4gIFRoaXMgbWVhbnMgdGhhdCB0aGUg Y2xpZW50IGlzCiAgIHJlcXVlc3RpbmcgdGhlIGNvbmZlcmVuY2Ugc2VydmVyIHRvIGFsd2F5cyBz ZW5kIHRoZSBtb3N0IHJlY2VudAogICBhY3RpdmUgc3BlYWtlciBvbiBmaXJzdCB2aWRlbyBzdHJl YW0gbmVnb3RpYXRlZCBpbiB0aGlzIGV4YW1wbGUgYnkKICAgZmlyc3QgdmlkZW8gbSBsaW5lLCBz ZWNvbmQgbW9zdCBhY3RpdmUgc3BlYWtlciBvbiBzZWNvbmQgdmlkZW8KICAgc3RyZWFtLCB0aGly ZCBtb3N0IGFjdGl2ZSBzcGVha2VyIG9uIHRoaXJkIHZpZGVvIHN0cmVhbSBhbmQgZm91cnRoCiAg IG1vc3QgcmVjZW50IGFjdGl2ZSBzcGVha2VyIG9uIGZvdXJ0aCB2aWRlbyBzdHJlYW0uCgogICBF eGFtcGxlICgyKSBvZiBzaHVmZmxpbmcgaW4gYSAyeDIgb3IgMXg0IGxheW91dCAoNCBlcXVhbCBz aXplZAogICB3aW5kb3dzKToKCgoKTW9zdGFmYSAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1 bmUgMjUsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgU0lQIE11bHRpLVN0cmVhbSBDUCBWaWRlbyAgICAgICAgICBEZWNlbWJlciAyMDExCgoK ICAgYT1jb250ZW50OiB3aW5kb3cxLDEsMTAwLCAxCiAgIGE9Y29udGVudDogd2luZG93MiwxLDEw MCwgMQogICBhPWNvbnRlbnQ6IHdpbmRvdzMsMSwxMDAsIDEKICAgYT1jb250ZW50OiB3aW5kb3c0 LDEsMTAwLCAxCiAgIEFsbCBmb3VyIHdpbmRvd3Mgd2lsbCBnZXQgc3dpdGNoZWQgd2l0aCBhY3Rp dmUgc3BlYWtlciBzdHJlYW1zLiAgVGhlCiAgIG9yZGVyIHdpbGwgYmUgZGV0ZXJtaW5lZCBieSBj b25mZXJlbmNlIHNlcnZlciB0byBtaW5pbWl6ZSBzaHVmZmxpbmcuCgogICBJbiB0aGlzIGV4YW1w bGUgdGhlIGNsaWVudCdzIG9mZmVyIHRvIHRoZSBjb25mZXJlbmNlIHNlcnZlciBoYXMgNAogICB2 aWRlbyBTRFAgbSBsaW5lcywgYT1jb250ZW50IGZvciBlYWNoIGhhcyBhIHNhbWUgdmFzIHJhbmsg dmFsdWUgKGxhc3QKICAgcGFyYW1ldGVyIGluIHRoZSBleGFtcGxlcyBhYm92ZSkuICBUaGlzIG1l YW5zIHRoYXQgdGhlIGNsaWVudCBpcwogICByZXF1ZXN0aW5nIHRoZSBjb25mZXJlbmNlIHNlcnZl ciB0byBhbHdheXMgbWluaW1pemUgc2h1ZmZsaW5nIG9mCiAgIHNwZWFrZXJzIG9uIHZpZGVvIHN0 cmVhbXMgc2VudCB0byBjbGllbnQsIGkuZS4gaWYgbW9zdCByZWNlbnQgYWN0aXZlCiAgIHNwZWFr ZXIgY2hhbmdlcywgc2VuZCBoaXMvaGVyIHZpZGVvIG9uIGZvdXJ0aCBzdHJlYW0gcmVwbGFjaW5n IHRoZQogICBsZWFzdCByZWNlbnQgYWN0aXZlIHNwZWFrZXIsIGxlYXZlIG90aGVyIHRocmVlIHN0 cmVhbXMgdW5jaGFuZ2VkLgoKICAgRXhhbXBsZSAoMykgb2Ygc2h1ZmZsaW5nIGluIGEgMSszIGxh eW91dCAoMSBiaWcgKyAzIHNtYWxsIHdpbmRvd3MpOgogICBhPWNvbnRlbnQ6IHdpbmRvdzEsMSwx MDAsIDEgKHRoZSBtb3N0IHJlY2VudCBzcGVha2VyKQogICBhPWNvbnRlbnQ6IHdpbmRvdzIsMiwx MDAsIDIgKDJuZCBtb3N0IHJlY2VudCkKICAgYT1jb250ZW50OiB3aW5kb3czLDIsMTAwLCAzICgz cmQgbW9zdCByZWNlbnQpCiAgIGE9Y29udGVudDogd2luZG93NCwyLDEwMCwgNCAoNHRoIG1vc3Qg cmVjZW50KQoKICAgSW4gdGhpcyBleGFtcGxlIHRoZSBjbGllbnQncyBvZmZlciB0byB0aGUgY29u ZmVyZW5jZSBzZXJ2ZXIgaGFzIDQKICAgdmlkZW8gU0RQIG0gbGluZXMsIGE9Y29udGVudCAoc2Vj b25kIHBhcmFtZXRlcikgaW5kaWNhdGVzIHR3bwogICBwcmlvcml0aWVzIGFuZCAxKzMgbGF5b3V0 LiAgVGhlIGE9Y29udGVudCBmb3IgZWFjaCBoYXMgYSBkaWZmZXJlbnQKICAgdmFzIHJhbmsgdmFs dWUgKGxhc3QgcGFyYW1ldGVyIGluIHRoZSBleGFtcGxlcyBhYm92ZSkuICBUaGlzIG1lYW5zCiAg IHRoYXQgdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIHRoZSBjb25mZXJlbmNlIHNlcnZlciB0byBh bHdheXMgc2VuZAogICB0aGUgbW9zdCByZWNlbnQgYWN0aXZlIHNwZWFrZXIgb24gZmlyc3Qgdmlk ZW8gc3RyZWFtIG5lZ290aWF0ZWQgaW4KICAgdGhpcyBleGFtcGxlIGJ5IGZpcnN0IHZpZGVvIG0g bGluZSwgc2Vjb25kIG1vc3QgYWN0aXZlIHNwZWFrZXIgb24KICAgc2Vjb25kIHZpZGVvIHN0cmVh bSwgdGhpcmQgbW9zdCBhY3RpdmUgc3BlYWtlciBvbiB0aGlyZCB2aWRlbyBzdHJlYW0KICAgYW5k IGZvdXJ0aCBtb3N0IHJlY2VudCBhY3RpdmUgc3BlYWtlciBvbiBmb3VydGggdmlkZW8gc3RyZWFt LgoKICAgRXhhbXBsZSAoNCkgb2Ygc2hmZmxpbmcgaW4gYSAxKzMgbGF5b3V0ICgxIGJpZyArIDMg c21hbGwgd2luZG93cyk6CiAgIGE9Y29udGVudDogd2luZG93MSwxLDEwMCwgMQogICBhPWNvbnRl bnQ6IHdpbmRvdzIsMiwxMDAsIDIKICAgYT1jb250ZW50OiB3aW5kb3czLDIsMTAwLCAyCiAgIGE9 Y29udGVudDogd2luZG93NCwyLDEwMCwgMgoKICAgVGhlIGJpZyB3aW5kb3cgd2lsbCBhbHdheXMg Z2V0IHRoZSBtb3N0IHJlY2VudCBhY3RpdmUgc3BlYWtlci4gIFRoZSAzCiAgIHNtYWxsIHdpbmRv d3Mgd2lsbCBnZXQgdGhlIG5leHQgMyBtb3N0IHJlY2VudCBhY3RpdmUgc3BlYWtlci4gIFRoZQog ICBvcmRlciBmb3IgdGhlc2UgdGhyZWUgc21hbGwgd2luZG93cyB3aWxsIGJlIGRldGVybWluZWQg YnkgdGhlIHNlcnZlcgogICB0byBtaW5pbWl6ZSBzaHVmZmxpbmcuCgogICBFeGFtcGxlICg1KSBv ZiBzaHVmZmxpbmcgaW4gYSAxKzMgbGF5b3V0IHdpdGggcGlubmVkIHZpZGVvICgxIGJpZyArIDMK ICAgc21hbGwgd2luZG93cyk6CiAgIGE9Y29udGVudDogd2luZG93MSwxLDEwMCwgMSAodGhlIG1v c3QgcmVjZW50IHNwZWFrZXIpCiAgIGE9Y29udGVudDogd2luZG93MiwyLDEwMCwgMiAoMm5kIG9y IDNyZCBtb3N0IHJlY2VudCkKICAgYT1jb250ZW50OiB3aW5kb3czLDIsMTAwLCAyICgybmQgb3Ig M3JkIG1vc3QgcmVjZW50KQogICBhPWNvbnRlbnQ6IHdpbmRvdzQsMiwxMDAsIDAgKHBpbm5lZCAv IG5vdCBzd2l0Y2hlZCBiYXNlZCBvbiBzcGVha2VyCgoKCk1vc3RhZmEgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBKdW5lIDI1LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgIFNJUCBNdWx0aS1TdHJlYW0gQ1AgVmlkZW8gICAgICAgICAgRGVj ZW1iZXIgMjAxMQoKCiAgIGFjdGl2aXR5KSkKCiAgIEluIHRoaXMgZXhhbXBsZSB0aGUgZm91cnRo IG0gbGluZSBoYXMgdmFzIHJhbmsgb2YgMCwgd2hpY2ggbWVhbnMgdGhpcwogICB2aWRlbyBzdHJl YW0gd2lsbCBub3QgYmUgc3dpdGNoZWQgYW5kIGlzIHBpbm5lZCB0byBhIGNlcnRhaW4gdXNlcgog ICByZWdhcmRsZXMgb2YgaGlzL2hlciB2b2ljZSBhY3Rpdml0eS4KCgo1LiAgQWN0aXZlIFRhbGtl ciBJbmRpY2F0aW9uCgogICBUaGUgYXVkaW8gYW5kIHZpZGVvIGFjdGl2ZSB0YWxrZXIgaW5kaWNh dGlvbnMgdXNlIHRoZSBSVFAgQ1NSQyBpbiB0aGUKICAgYXVkaW8gYW5kIHZpZGVvIFJUUCBbUkZD MzU1MF0uICBUaGUgU1NSQydzIGluIHRoZSBSVFAgQ1NSQyBsaXN0IGlzCiAgIG1hcHBlZCB0byB1 c2VyaWQvdXNlciBuYW1lIHVzaW5nIHRoZSBSRkM0NTc1IG5vdGlmaWNhdGlvbnMuICBPbmx5IG9u ZQogICBTU1JDIGlzIHNlbnQgaW4gdGhlIHZpZGVvIFJUUCBDU1JDIGxpc3QsIGNsaWVudCBjYW4g dXNlIHRoaXMgdG8KICAgZGlzcGxheSB0aGUgdXNlciBuYW1lIG9uIGVhY2ggQ1AgdmlkZW8gd2lu ZG93LgoKCjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIG11bHRpLXN0cmVhbSBD UCB2aWRlbyB1c2VzIHRoZSBUTFMgYW5kIHNSVFAgc3RhbmRhcmRzIGZvciBTSVAKICAgc2lnbmFs aW5nIGFuZCBtZWRpYSBzZWN1cnRpeS4KCgo3LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhp cyBkb2N1bWVudCBoYXMgbm8gYWN0aW9ucyBmb3IgSUFOQS4KCgo4LiAgQWNrbm93bGVkZ2VtZW50 cwoKICAgVGhhbmtzIHRvIEFsYW4gSm9obnN0b24sIERhbiBSb21hc2NhbnUsIFBldGVyIE11c2dy YXZlIGFuZCBSaWZhYXQKICAgU2hla2gtWXVzZWYgZm9yIHRoZWlyIHJldmlldyBvZiB0aGUgZG9j dW1lbnQgYW5kIGNvbW1lbnRzLgoKCjkuICBSZWZlcmVuY2VzCgo5LjEuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzCgogICBbUkZDMzU1MF0gIFNjaHVsenJpbm5lLCBILiwgQ2FzbmVyLCBTLiwgRnJl ZGVyaWNrLCBSLiwgYW5kIFYuCiAgICAgICAgICAgICAgSmFjb2Jzb24sICJSVFA6IEEgVHJhbnNw b3J0IFByb3RvY29sIGZvciBSZWFsLVRpbWUKICAgICAgICAgICAgICBBcHBsaWNhdGlvbnMiLCBT VEQgNjQsIFJGQyAzNTUwLCBKdWx5IDIwMDMuCgogICBbUkZDNjE5MF0gIFdlbmdlciwgUy4sIFdh bmcsIFkuLCBTY2hpZXJsLCBULiwgYW5kIEEuIEVsZWZ0aGVyaWFkaXMsCiAgICAgICAgICAgICAg IlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgU2NhbGFibGUgVmlkZW8gQ29kaW5nIiwgUkZDIDYxOTAs CiAgICAgICAgICAgICAgTWF5IDIwMTEuCgoKCgoKCgpNb3N0YWZhICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgSnVuZSAyNSwgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICBTSVAgTXVsdGktU3RyZWFtIENQIFZpZGVvICAgICAgICAgIERlY2Vt YmVyIDIwMTEKCgo5LjIuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzIxMTldICBCcmFk bmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoK ICAgW1JGQzMyNjFdICBSb3NlbmJlcmcsIEouLCBTY2h1bHpyaW5uZSwgSC4sIENhbWFyaWxsbywg Ry4sIEpvaG5zdG9uLAogICAgICAgICAgICAgIEEuLCBQZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4s IEhhbmRsZXksIE0uLCBhbmQgRS4KICAgICAgICAgICAgICBTY2hvb2xlciwgIlNJUDogU2Vzc2lv biBJbml0aWF0aW9uIFByb3RvY29sIiwgUkZDIDMyNjEsCiAgICAgICAgICAgICAgSnVuZSAyMDAy LgoKICAgW1JGQzMyNjRdICBSb3NlbmJlcmcsIEouIGFuZCBILiBTY2h1bHpyaW5uZSwgIkFuIE9m ZmVyL0Fuc3dlciBNb2RlbAogICAgICAgICAgICAgIHdpdGggU2Vzc2lvbiBEZXNjcmlwdGlvbiBQ cm90b2NvbCAoU0RQKSIsIFJGQyAzMjY0LAogICAgICAgICAgICAgIEp1bmUgMjAwMi4KCgpBdXRo b3IncyBBZGRyZXNzCgogICBBZGVsIE1vc3RhZmEgKGVkaXRvcikKICAgQXZheWEKICAgVG9yb250 bywgT250YXJpbwogICBDYW5hZGEKCiAgIEVtYWlsOiBhbW9zdGFmYUBhdmF5YS5jb20KCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCk1vc3RhZmEgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBK dW5lIDI1LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCg== --_004_E151F470685C15418AEA609E825A171022D3594094DCUS1MBEX4glo_--