From albrecht.schwarz@alcatel-lucent.com Wed Aug 3 06:54:11 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC821F8B5D for ; Wed, 3 Aug 2011 06:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.864 X-Spam-Level: X-Spam-Status: No, score=-4.864 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, FRT_SOMA2=2.199, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CM7yJxqocwu for ; Wed, 3 Aug 2011 06:54:10 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id E681721F8B78 for ; Wed, 3 Aug 2011 06:54:09 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p73DsIIn019586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Aug 2011 15:54:19 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 3 Aug 2011 15:54:18 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Javi , "megaco@ietf.org" Date: Wed, 3 Aug 2011 15:54:16 +0200 Thread-Topic: [Megaco] Media flow managed by 2 terminations Thread-Index: AcxN5TN7v6cit1iYSKuoFDVL1YdVaQD/seDg Message-ID: <5F7BCCF5541B7444830A2288ABBEBC96215F76A386@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <4E1DBB54.1060303@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC96215F6E9827@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4E305282.2050202@trajano.us.es> <5F7BCCF5541B7444830A2288ABBEBC96215F6EA63F@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4E329D75.1060801@trajano.us.es> In-Reply-To: <4E329D75.1060801@trajano.us.es> 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.64 on 155.132.188.83 Subject: Re: [Megaco] Media flow managed by 2 terminations X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:54:11 -0000 Thanks Javi for sharing that detailed background! Indeed, option 3 would be not possible, I quite agree. Option 3 did suppose= a single "media flow" component, but not two as in your considered use cas= e. I could imagine that single-stream-per-termination structures, i.e., dedica= ted H.248 IP terminations for PH and FH traffic, might be beneficial, e.g.= from perspective of "unsuccessful call handling" like for instance - H.248.40 for monitoring activity of the media flows on IP side, - H.248.36 for detection of hanging IP terminations, - etc. -Albrecht =20 > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Javi > Sent: Freitag, 29. Juli 2011 13:46 > To: megaco@ietf.org > Subject: Re: [Megaco] Media flow managed by 2 terminations >=20 > Albrecht, >=20 > The entire network picture is similar to "ETSI_ARGW[TS 183=20 > 002 v3.3.1]/Clause 7.3.2" or "draft-bouwen-megaco-isdn-data-00": >=20 > ISDN TE <-> AGW (MG) <-> PH or FH <-> PSPDN >=20 > where PH "Packet Handler" and FH "Frame Handler" are=20 > different equipments (I propose a descomposal architecture=20 > for PH: "MGC-PH <-> > AGW-PH(SG/MG-PH) <-> PSPDN"; and similar for FH) >=20 > So, AGW/MG terminates ISDN D-channel, and p-,f- LAPD frames=20 > would be sent to PH/FH. The IP termination may be: RawFR,=20 > IUA, XOT or PWs (HDLCPW, FRPW, TDMPW). >=20 > A D-channel packet mode outgoing call may start with a LAPD=20 > p-frame (PLP > Restart) from ISDN TE, without previous Q.931 signalling. So,=20 > a D-channel physical termination is necessary in MG (MG=20 > detects that p-frame and sends a MeGaCo notify to MGC; then,=20 > MGC sends a SIP INVITE message to PH, signalling the call). >=20 > So, the D-channel physical termination would be neccessary.=20 > The doubt would be: two single-stream-per-terminations (an=20 > ephemeral termination per packet or frame connection, apart=20 > from the D-channel physical > termination) versus one dual-stream-per-termination (only the=20 > D-channel physical termination with two StreamIDs). >=20 > PH and FH are different equipments, and D-channel supports=20 > simultaneous packet and frame connections. So, I don't=20 > understand alternative "3". >=20 > Javi >=20 >=20 >=20 > El 28/07/2011 10:43, Schwarz, Albrecht (Albrecht) escribi=F3: > > Javi, > > I was hesitating to reply because I was wondering myself,=20 > whether I firstly got to know the entire network picture. So=20 > far we did consider just a "half-call" model by looking at=20 > one termination of the context only. > > However, I don't guess that the H.248 MG would be the=20 > termination point of the D-channel traffic, right? > > > > What would be the 2nd termination? > > Guess this information could clarify the intended function=20 > of the H.248 MG, e.g., by just "transparent forwarding" of=20 > D-channel frames, or any interworking (?), or ...? > > > > That information may provides answers > > to (3): > > E.g., the termination is initially configured for "TDM=20 > awareness", but "unawareness concerning D-channel traffic=20 > type". After detection the termination may become "aware of=20 > specific D-channel type frames" ... (but again, would be=20 > dependent on your aimed network use case). > > [Note: sth similar to IP-IP border gateways, initially=20 > configured in=20 > > media-agnostic mode, possibly later modified to media aware modes,=20 > > dependent on ...] > > > > to (a,b): > > The question concerning the alternatives of two=20 > > single-stream-per-terminations versus one=20 > dual-stream-per-termination=20 > > structure could dependent again on your network use case. (E.g., do=20 > > you consider a physical or ephemeral termination; any common=20 > > properties on termination level?) > > > > Just some thoughts, Albrecht > > > > > > > > =20 > >> -----Original Message----- > >> From: Javi [mailto:javi@trajano.us.es] > >> Sent: Mittwoch, 27. Juli 2011 20:02 > >> To:megaco@ietf.org > >> Cc: Schwarz, Albrecht (Albrecht) > >> Subject: Re: [Megaco] Media flow managed by 2 terminations > >> > >> Thanks Albrecht. > >> > >> I don't undesrtand your alternative "3)". May you clarify it? > >> > >> Also, if the D-channel carries p- or/and f-type frames, what is=20 > >> preferable?: > >> > >> a) An ephemeral termination for each one (at least, for p- anf=20 > >> f-frames). > >> > >> b) An streamID for each one (alternative "2"). > >> > >> Thanks, > >> > >> Javi > >> > >> > >> > >> > >> > >> El 15/07/2011 13:24, Schwarz, Albrecht (Albrecht) escribi=F3: > >> =20 > >>>> Does H.248.1 allow this? > >>>> > >>>> =20 > >>> I think so. > >>> Guess that following aspect might be also relevant: > >>> > >>> Does the D-channel carry > >>> a) just a single type of frames (e.g. exclusively X.25=20 > traffic); or > >>> b) a multiplex of s-, p- or/and f-type frames (e.g., a mix > >>> =20 > >> of Q.921 signalling, X.25 packet and frame relay traffic). > >> =20 > >>> Possible alternatives to the considered ephemeral > >>> =20 > >> termination for the "X.25/D-channel/{16|64}TDM bearer": > >> =20 > >>> 1) static configuration, i.e., without any H.248 context, > >>> =20 > >> see ETSI TS > >> =20 > >>> 183002, =A7 7.3.2.2 > >>> -> using an X.25-over-SCTP bearer > >>> -> 7.3.2.4.2 IUA/SCTP for X.25 or frame relay traffic > >>> > >>> 2) H.248 Mux termination > >>> use case here: Figure 9 (ex 6)/H.248.1 - Multiplexed termination=20 > >>> scenario - Single-to-multiple terminations > >>> -> Circuit 1 =3D D-channel > >>> -> StreamID =3D x: p-type (X.25) frames > >>> > >>> 3) SDP for TDM (old proposal: draft-taylor-mmusic-sdp-tdm-01.txt) > >>> -> single physical termination > >>> -> initially 'TDM' > >>> -> after detection modified to 'PKT/TDM' > >>> > >>> The attributes > >>> a=3Dnetprof: > >>> a=3De2eprof: > >>> could be used to "profile the D-channel" for the specific > >>> =20 > >> type frames > >> =20 > >>> Just some thoughts, > >>> Albrecht > >>> > >>> > >>> > >>> > >>> =20 > >>>> -----Original Message----- > >>>> From:megaco-bounces@ietf.org > >>>> [mailto:megaco-bounces@ietf.org] On Behalf Of Javi > >>>> Sent: Mittwoch, 13. Juli 2011 17:36 To:megaco@ietf.org > >>>> Subject: [Megaco] Media flow managed by 2 terminations > >>>> > >>>> Is it possible to manage a same flow by 2 termination (one > >>>> =20 > >> physical > >> =20 > >>>> and another ephymeral)? > >>>> > >>>> > >>>> Specifically, I need to manage the packet flows (SAPI 16) in a=20 > >>>> D-channel ISDN. My proposal is to use: > >>>> > >>>> + A physical termination to manage the overall=20 > D-channel. When that > >>>> termination detects a packet flow (SAPI 16/TEI x), it=20 > would send a=20 > >>>> notify to the MGC. > >>>> > >>>> + MGC would create an ephemeral termination to manage that > >>>> packet flow > >>>> (SAPI 16/TEI x) and the physical termination should continue to=20 > >>>> manage the rest of packet flows (with different TEI) in that=20 > >>>> D-channel. > >>>> > >>>> Does H.248.1 allow this? > >>>> > >>>> > >>>> _______________________________________________ > >>>> Megaco mailing list > >>>> Megaco@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/megaco > >>>> > >>>> > >>>> =20 > >>> =20 > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org > >> https://www.ietf.org/mailman/listinfo/megaco > >> > >> > >> =20 > > =20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > = From akashclose2u@gmail.com Wed Aug 17 06:34:44 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0A121F8B39 for ; Wed, 17 Aug 2011 06:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 n9YZIWGubXeZ for ; Wed, 17 Aug 2011 06:34:44 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 182D521F8B63 for ; Wed, 17 Aug 2011 06:34:44 -0700 (PDT) Received: by yie12 with SMTP id 12so804054yie.31 for ; Wed, 17 Aug 2011 06:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=QwYoWi1UWgqH17nDpDGpq5ZevO4+zcDTIkaFmJGxOMA=; b=T1r9scT3i92zsVSiUaXuvDu/O7rRH8mXE4+L/IpzD3lhxstJKrmeHHyLZ33NSh3LGX 0OXsPYF4d01pkQxKIgpa6mkeasXAQxVJ7RGTqa8lwiFrvYI66vo7Il6Gjm7q4kTRkFyf f6Zruw4AE6btE5w4XgJWKe+a+hBizsIHIu6FE= Received: by 10.236.191.2 with SMTP id f2mr3223133yhn.233.1313588135066; Wed, 17 Aug 2011 06:35:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.109.13 with HTTP; Wed, 17 Aug 2011 06:35:15 -0700 (PDT) From: "Cool..AkaSh" Date: Wed, 17 Aug 2011 19:05:15 +0530 Message-ID: To: Megaco@ietf.org Content-Type: multipart/alternative; boundary=20cf305b13ec2bfd2b04aab392c9 Subject: [Megaco] Query about LATCH Vs RELATCH X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 17:17:36 -0000 --20cf305b13ec2bfd2b04aab392c9 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a query about the difference between Latch and Relatch. I am testing BGF, and in my scenario when Latch is followed by Relatch then it is working fine i.e. first it learn the packets from the source IP (except remote descriptor IP) and when did RELATCH then learned the packets from new source IP and drops the packets from the previous IP. Now when I am doing a scenario Latch followed by Latch then also first it learns the packets from the source IP and when did LATCH then it learn the packet from new source IP and drops the packets from previous IP. Here I am not able to figure out what is the difference between Latch and Relatch because in the above scenario I can see LATCH is doing the same thing which RELATCH does. Why RELATCH comes into the picture? Please help me to figure out this, so that can proceed. Your help would be appreciable. --- Thanks & Regards, Akash Gupta --20cf305b13ec2bfd2b04aab392c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

I have a query about the difference between Latch an= d Relatch. I am testing BGF, and in my scenario when Latch is followed by Rel= atch then it is working fine i.e. first it learn the packets from the source IP = (except remote descriptor IP) and when did RELATCH then learned the packets from ne= w source IP and drops the packets from the previous IP.

Now when I am doing a scenario Latch followed by Lat= ch then also first it learns the packets from the source IP and when did LATCH then= it learn the packet from new source IP and drops the packets from previous IP.=

=A0

Here I am not able to figure out what is the differe= nce between Latch and Relatch because in the above scenario I can see LATCH is doing th= e same thing which RELATCH does. Why RELATCH comes into the picture?

=A0

Please help me to figure out this, so that can proce= ed. Your help would be appreciable.

=A0

=A0=

=A0<= /p>

---<= /p>

Thanks & Regar= ds,

Akash Gupta=






--20cf305b13ec2bfd2b04aab392c9-- From Raju.Makaraju@alcatel-lucent.com Wed Aug 17 12:34:41 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D878121F8B9C for ; Wed, 17 Aug 2011 12:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 0HhYOrU9MmqA for ; Wed, 17 Aug 2011 12:34:41 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 256DB21F8B78 for ; Wed, 17 Aug 2011 12:34:40 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7HJZV7h023050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Aug 2011 14:35:31 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7HJZV1P016346 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Aug 2011 14:35:31 -0500 Received: from USNAVSXCHMBSD3.ndc.alcatel-lucent.com ([135.3.39.155]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 17 Aug 2011 14:35:31 -0500 From: "Makaraju, Maridi Raju (Raju)" To: "'akashclose2u@gmail.com'" , "'Megaco@ietf.org'" Date: Wed, 17 Aug 2011 14:35:29 -0500 Thread-Topic: [Megaco] Query about LATCH Vs RELATCH Thread-Index: AcxdAbETaeECui99Q5abIb1Km8QWcwAEyFYx Message-ID: <31939CE9629A7F46885A9F97CEA9BF577B4F709B@USNAVSXCHMBSD3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [Megaco] Query about LATCH Vs RELATCH X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 19:34:42 -0000 QWthc2gsCgpMYXRjaCBjb21wbGV0ZXMgd2hlbiB2ZXJ5IG5leHQgcGt0IGFycml2ZXMgaXJyZXNw ZWN0aXZlIG9mIHRoZSBzcmMgaXMgbmV3IG9yIHNhbWUgYXMgYmVmb3JlLgpXaGVyZWFzIHJlbGF0 Y2ggY29tcGxldGVzIG9ubHkgd2hlbiBwa3QgZnJvbSBuZXcgc3JjIGFycml2ZXMuCkluIG9uZSBz Y2VuYXJpbyBpdCBtYXkgc28gaGFwcGVuIHRoYXQgdGhlIG5leHQgcGt0IGFycml2ZXMgZnJvbSBu ZXcgc3JjLiBJbiBzdWNoIGNhc2UgZWl0aGV0IGEgbGF0Y2ggb3IgcmVsYXRjaCBjYW4gYmUgY29t cGxldGVkIHdpdGggdGhlIHNhbWUgZWZmZWN0LgoKVGhhbmtzClJhanUNCg0KIC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAJQ29vbC4uQWthU2ggW21haWx0bzpha2FzaGNsb3NlMnVA Z21haWwuY29tXQ0KU2VudDoJV2VkbmVzZGF5LCBBdWd1c3QgMTcsIDIwMTEgMTI6MTggUE0gQ2Vu dHJhbCBTdGFuZGFyZCBUaW1lDQpUbzoJTWVnYWNvQGlldGYub3JnDQpTdWJqZWN0OglbTWVnYWNv XSBRdWVyeSBhYm91dCBMQVRDSCBWcyBSRUxBVENIDQoNCkhpLA0KDQogDQoNCkkgaGF2ZSBhIHF1 ZXJ5IGFib3V0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gTGF0Y2ggYW5kIFJlbGF0Y2guIEkgYW0g dGVzdGluZyBCR0YsIGFuZCBpbiBteSBzY2VuYXJpbyB3aGVuIExhdGNoIGlzIGZvbGxvd2VkIGJ5 IFJlbGF0Y2ggdGhlbiBpdCBpcyB3b3JraW5nIGZpbmUgaS5lLiBmaXJzdCBpdCBsZWFybiB0aGUg cGFja2V0cyBmcm9tIHRoZSBzb3VyY2UgSVAgKGV4Y2VwdCByZW1vdGUgZGVzY3JpcHRvciBJUCkg YW5kIHdoZW4gZGlkIFJFTEFUQ0ggdGhlbiBsZWFybmVkIHRoZSBwYWNrZXRzIGZyb20gbmV3IHNv dXJjZSBJUCBhbmQgZHJvcHMgdGhlIHBhY2tldHMgZnJvbSB0aGUgcHJldmlvdXMgSVAuDQoNCk5v dyB3aGVuIEkgYW0gZG9pbmcgYSBzY2VuYXJpbyBMYXRjaCBmb2xsb3dlZCBieSBMYXRjaCB0aGVu IGFsc28gZmlyc3QgaXQgbGVhcm5zIHRoZSBwYWNrZXRzIGZyb20gdGhlIHNvdXJjZSBJUCBhbmQg d2hlbiBkaWQgTEFUQ0ggdGhlbiBpdCBsZWFybiB0aGUgcGFja2V0IGZyb20gbmV3IHNvdXJjZSBJ UCBhbmQgZHJvcHMgdGhlIHBhY2tldHMgZnJvbSBwcmV2aW91cyBJUC4NCg0KIA0KDQpIZXJlIEkg YW0gbm90IGFibGUgdG8gZmlndXJlIG91dCB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g TGF0Y2ggYW5kIFJlbGF0Y2ggYmVjYXVzZSBpbiB0aGUgYWJvdmUgc2NlbmFyaW8gSSBjYW4gc2Vl IExBVENIIGlzIGRvaW5nIHRoZSBzYW1lIHRoaW5nIHdoaWNoIFJFTEFUQ0ggZG9lcy4gV2h5IFJF TEFUQ0ggY29tZXMgaW50byB0aGUgcGljdHVyZT8gDQoNCiANCg0KUGxlYXNlIGhlbHAgbWUgdG8g ZmlndXJlIG91dCB0aGlzLCBzbyB0aGF0IGNhbiBwcm9jZWVkLiBZb3VyIGhlbHAgd291bGQgYmUg YXBwcmVjaWFibGUuDQoNCiANCg0KIA0KDQogDQoNCi0tLQ0KDQpUaGFua3MgJiBSZWdhcmRzLA0K DQpBa2FzaCBHdXB0YQ0KDQoNCg0KDQoNCg0K