From starmar@absconsultants.com Sun Oct 01 23:28:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUETJ-0003Wp-AU for avt-archive@lists.ietf.org; Sun, 01 Oct 2006 23:28:01 -0400 Received: from 219-89-64-252.ipnets.xtra.co.nz ([219.89.64.252] helo=absconsultants.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUETH-000695-Ij for avt-archive@lists.ietf.org; Sun, 01 Oct 2006 23:28:01 -0400 Message-ID: <01c6e5d2$ba9b7180$fc4059db@adam> Date: Mon, 2 Oct 2006 16:27:46 +1200 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Lalit Dacruz" From: "Lalit Dacruz" To: Subject: PHdvkARMA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1114B_01C6E63F.B194B980" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 2.6 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_1114B_01C6E63F.B194B980 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good day, CIAttLIS VALttIUM VIAttGRA AMBttIEN Save 50 % with http://www.sedunjinkadesinkloons.com =20 _____ =20 door opened in the wall behind them and there was a rush to get have done. You may proceed, Gentleman Jim, because you indeed are of A beer. I must have refreshment. Will you join me? ------=_NextPart_000_1114B_01C6E63F.B194B980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Good day,

CIAttLIS

VALttIUM

VIAttGRA

AMBttIEN

Save 50 % with http://www.sedunjinkadesink= loons.com
 

door opened in the wall behind them and there was a = rush to get
have done. You may proceed, Gentleman Jim, because you indeed are = of
A beer. I must have refreshment. Will you join me?

------=_NextPart_000_1114B_01C6E63F.B194B980-- From cherykrissy@eastsussex.gov.uk Mon Oct 02 09:12:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNb7-0007ip-CL for avt-archive@lists.ietf.org; Mon, 02 Oct 2006 09:12:41 -0400 Received: from static-host-24-149-214-45.patmedia.net ([24.149.214.45] helo=novatek) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNb5-0006R0-3j for avt-archive@lists.ietf.org; Mon, 02 Oct 2006 09:12:41 -0400 Message-ID: <001701c6e60a.8ca01280.7716c0a8@lem> Date: Mon, 02 Oct 2006 10:07:21 +0000 From: emmy margot User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: rik cherilyn Subject: Earn-power... beth Content-Type: multipart/alternative; boundary="---------000000CC.01C6E60A" X-Spam-Score: 1.8 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. -----------000000CC.01C6E60A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Even if you have no erection problems SOFT CIALIS would help you to make BETTER SEX MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medicatin were able to have PERFECT ERECTION during 36 hours! VISIT US, AND GET OUR SPECIAL 65% DISCOUNT OFFER! geiger univariate "Hello," I said. "Guta, where are you going?" She took me in in one wintertime schizophrenic He gave one last look across the sky, across that magnificent silver -----------000000CC.01C6E60A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Even if you have no erection problems SOFT CIALIS
would help you to make BETTER SEX MORE OFTEN!
and to bring unimagnable plesure to her.

Just disolve half a pil under your tongue
and get ready for action in 15 minutes.

The tests showed that the majority of men
after taking this medicatin were able to have
PERFECT ERECTION during 36 hours!



VISIT US, AND GET OUR SPECIAL 65% DISCOUNT OFFER!

geiger univariate
"Hello," I said. "Guta, where are you going?" She took me in in one
wintertime schizophrenic
He gave one last look across the sky, across that magnificent silver
-----------000000CC.01C6E60A-- From avt-bounces@ietf.org Mon Oct 02 10:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP7r-0003vc-PP; Mon, 02 Oct 2006 10:50:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP7q-0003uz-16; Mon, 02 Oct 2006 10:50:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP7p-0002uN-Ux; Mon, 02 Oct 2006 10:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GUP7n-0005DW-T9; Mon, 02 Oct 2006 10:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C93502AC32; Mon, 2 Oct 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GUP7J-0005xN-Ip; Mon, 02 Oct 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 02 Oct 2006 10:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Multiplexing RTP Data and Control Packets on a Single Port Author(s) : C. Perkins, M. Westerlund Filename : draft-ietf-avt-rtp-and-rtcp-mux-00.txt Pages : 12 Date : 2006-10-2 This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-and-rtcp-mux-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-2083514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-and-rtcp-mux-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-2083514.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Mon Oct 02 12:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQQO-0005Qq-Ao; Mon, 02 Oct 2006 12:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQQM-0005Iu-P8 for avt@ietf.org; Mon, 02 Oct 2006 12:13:46 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQQL-00064h-FL for avt@ietf.org; Mon, 02 Oct 2006 12:13:46 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 12:13:41 -0400 To: AVT WG Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-00.txt References: From: Randell Jesup Date: Mon, 02 Oct 2006 12:13:39 -0400 In-Reply-To: (Internet-Drafts@ietf.org's message of "Mon, 02 Oct 2006 10:50:01 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 02 Oct 2006 16:13:41.0533 (UTC) FILETIME=[BA0B3CD0:01C6E63D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Magnus Westerlund , Colin Perkins X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org >>> If the answer contains an "a=rtcp:" attribute, but that attribute >>> specifies a different port for RTCP than for RTP, then the answer >>> MUST be rejected, and the session re-negotiated using separate RTP >>> and RTCP ports. >> >> The answer cannot generally be 'rejected'; the session has been created >> already (offer + answer). You can either end the session (BYE/ CANCEL) >> and start a new one (which causes serious problems - ringing, forking, >> etc) or you can renegotiate the session (re-INVITE/UPDATE). >> >> This also means that you have to deal with media until any renegotiation >> occurs. If you kill the session, realize that early media may have >> already occurred, forking may have been resolved, the user may have >> agreed to pay $500 to complete the call (ref: sipping early-media example >> draft), etc, etc. > >Yep - this is already on my list of things to clarify in the next >revision. I'm not sure there is a solution other than "deal with >broken RTCP until you can re-negotiate" though? BTW, I should note that a quick re-reading of RFC 3605 doesn't contain any stipulation that that the port be different than the RTP port, so this draft wouldn't violate RFC 3605 (and a 3605 implementation SHOULD transparently respond to signalling proposed by the draft by sending the RTCP to the RTP port). Possible answers: 1) Don't require 'rejection' or renegotiation. In most cases, if the answerer supports a=rtcp but not this spec, then rtcp will very likely work anyways. You won't know for sure unless/until you get RTCP data on the RTP port (since support for RFC 3605 doesn't mean you have to insert it in replies unless you need to). As for those that don't support a=rtcp, handle it exactly as you would handle such an answerer under RFC 3605, which is to say entirely up to the implementation - for some reason, RFC 3605 doesn't even mention the issue. Probably because in most cases if the answerer doesn't support it, there's _nothing_ you can do to solve the problem. In our case here, we might be able to get RTCP running on the odd port; we could say in that case the implementation "SHOULD try to receive RTCP data on the odd port of the pair if possible", which might involve a renegotation/restun/reICE - but you may well be out of luck no matter what. 2) Require a new a= value to indicate support for this spec by the answerer. This solves the "wait and see" issue above, and if you want to renegotiate/etc you can do so immediately (though media is already flowing). This is distinct from the case in the draft in that it doesn't require the receiver to demux if it doesn't want to, which is impossible in the draft since requesting rtp=rtcp is a signal back to the caller. 3) Require a new a= value to request (and acknowledge) the request (a=rtcpmux). Similar to 2, avoids problems with ambiguity about support. You lose the ability to transparently cause older (RFC 3605-supporting) implementations to send you muxed RTP/RTCP data - this is a minus to me, though the draft as per above loses that advantage anyways by requiring "rejection" of the answer. My preference is for #2. >> It's much safer to increase the b=AS value instead. Any intermediary >> device that understands the draft won't be confused by this, and devices >> that don't understand the draft are more likely to work. > >RFC 4566 explicitly states that a "b=AS:" is the RTP session >bandwidth, which excludes RTCP. I understand your reasoning, but I >don't think we can make this change without breaking compatibility. I really think that this might cause problems for existing QoS-enabled channels that hook into or sniff the signalling. You suggest it will break compatibility - what device will get broken? Worst case I can see is a channel allocating QoS for both RTP+RTCP on one port, and RTCP on another (though I suspect most QoS devices don't allocate for RTCP at all). That's actually correct, with some wasted bandwidth, and until the call is completed you actually don't know you won't need the RTCP port bandwidth anyways. And I don't see that as a problem. A device aware of this spec won't have a problem, and a device unaware of this should just do the right thing if we include it in b=AS. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 02 21:17:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYt8-0005io-S7; Mon, 02 Oct 2006 21:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYt7-0005gG-6V for avt@ietf.org; Mon, 02 Oct 2006 21:16:01 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUYt3-0002fx-G1 for avt@ietf.org; Mon, 02 Oct 2006 21:16:01 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k931Frx7025392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Oct 2006 18:15:54 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k931Fol5014559; Mon, 2 Oct 2006 18:15:51 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 18:15:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Date: Mon, 2 Oct 2006 18:15:38 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B020F874D@NAEX01.na.qualcomm.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C03EBEA15@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Thread-Index: Acbi4oDhd6/gawkhQPWePyaFQr7esAALv1twAN03etA= From: "Desineni, Harikishan" To: "Even, Roni" , "Magnus Westerlund" X-OriginalArrivalTime: 03 Oct 2006 01:15:50.0061 (UTC) FILETIME=[768EB5D0:01C6E689] X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: Cullen Jennings , IETF AVT WG , Gary Sullivan , Carsten Bormann , "Stephan Wenger \(Nokia\)" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org It would be good to provide some examples along with these updates.=20 (I tried to come up with few examples listed at the end of this e-mail) Profile and level are not included as parameters to H263-1998 MIME subtype. It looks like "profile=3Dxx;level=3Dyy" indication is = applicable to H263-2000 MIME subtype only. If this is indeed the case, it would be better to clarify this as part of the upcoming update to the draft (in the offer/answer section). >From Sec 8.1.2 on H263-2000 MIME subtype: "The optional parameters of the H263-1998 type MAY be used with this MIME subtype."=20 This is giving H263-2000, the freedom to use all optional parameters defined for H263-1998. Thus, it looks like just one MIME subtype (H263-2000) is necessary (May be I am terribly incorrect here!) in this draft. Can somebody enlighten me here on when am I mandated to use only h263-1998? Example 1: SDP offer with Profile 0, Level 10 and profile 1 and level 10 m=3Dvideo 34560 RTP/AVP 96 97 a=3Drtpmap:96 h263-2000/90000 a=3Dfmtp:96 profile=3D0;level=3D10; a=3Drtpmap:97 h263-2000/90000 a=3Dfmtp:97 profile=3D1;level=3D10; SDP answer with profile 0, level 45=20 m=3Dvideo 45678 RTP/AVP 96=20 a=3Drtpmap:96 h263-2000/90000 a=3Dfmtp:96 profile=3D0;level=3D45; Example 2: SDP offer with Profile 0, Level 10=20 m=3Dvideo 34560 RTP/AVP 96=20 a=3Drtpmap:96 h263-2000/90000 a=3Dfmtp:96 profile=3D0;level=3D10; SDP answer with profile 0, level 45 and profile 1, level 10 m=3Dvideo 45678 RTP/AVP 96 97 a=3Drtpmap:96 h263-2000/90000 a=3Dfmtp:96 profile=3D0;level=3D45; a=3Drtpmap:98 h263-2000/90000 a=3Dfmtp:98 profile=3D1;level=3D10; Mid-call, offerer updates the level from 10 to 45: m=3Dvideo 34560 RTP/AVP 96=20 a=3Drtpmap:96 h263-2000/90000 a=3Dfmtp:96 profile=3D0;level=3D45; - - - - - - - - - - - - - - - - - Harikishan Desineni Qualcomm Inc., mailto:hd@qualcomm.com > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, September 28, 2006 8:31 AM > To: Magnus Westerlund; IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; > Carsten Bormann; Stephan Wenger (Nokia); Gary Sullivan > Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis- > 09.txt >=20 > Magnus, > As the editor of 2429-bis I appreciate you comments and suggest that I > will update the draft accordingly. Since it is waiting for IANA then I > assume we can still hold it. > Colin can you please help me with how to enable me to update the draft. >=20 > The major point for my point of view that requires updating is to clearly > define the default behavior if no parameter is specifies. > My suggestion is that for H.263-1998 the default is H.263 baseline (this > will also be in line with the historic H263), QCIF 30 fps. >=20 > For H.263-2000 it will be profile 0 level 10 line your suggestion. >=20 > I think that the rest of the comments and clarification will prevent > future interoperability issue even though to me they were clear so I will > make them. >=20 > Roni >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, September 28, 2006 12:38 PM > > To: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten Bormann; > > Stephan Wenger (Nokia); Gary Sullivan > > Subject: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt > > > > Hi, > > > > I with help of my colleagues we have found a shortcoming in the Media > > type and offer/answer description of the updated H.263 payload format. I > > am really sorry to not have spotted these before. However I think we > > need to address them. > > > > The first issue is that the text for profile is unclear in how one > > handle profiles. > > > > Profile: The offer of a SDP profile parameter signal that the sender > > can decode a stream that uses the specified profile. Each profile > > uses different H.263 annexes so there is no implied relationship > > between them. In the offer/answer exchange this parameter SHOULD be > > the same in the offer and answer. A decoder that support a profile > > SHALL also support H.263 baseline profile (profile 0). > > > > First of all, I think the profile should be non changeable for a given > > payload type. Instead one has to offer each profile one desires to use > > in different payload types. To avoid the issue that the other end-point > > can't propose another profile one should always offer profile 0. > > > > Secondly we need text that says that downgrading the LEVEL parameter in > > an answer is allowed to be done. At least in unicast cases, but not in > > multicast, where the value is take it or leave it. > > > > Thus I would propose the following new text: > > > > PROFILE: The offer of a SDP profile parameter signal that the > offerer > > can decode a stream that uses the specified profile. Each profile > > uses different H.263 annexes so there is no implied relationship > > between them. Thus an answerer SHALL NOT change the profile > > parameter and MUST instead reject the payload type containing a > > unsupported profile. A decoder that support a profile SHALL also > > support H.263 baseline profile (profile 0). A offerer is RECOMMENDED > > to offer all the different profiles it is interested to use as > > individual payload types. In addition an offerer is RECOMMENDED to > > always offer profile 0, as this will enable communication, and in > > addition allow an answerer to add those profiles it does support in > > an answer. > > > > LEVEL: The LEVEL parameter in an offer indicates the maximum > > computational complexity supported by the offerer in performing > > decoding for the given PROFILE. An answerer MAY change the value > > (both up and down) of the LEVEL parameter in its answer to indicate > > the highest value it supports. > > > > The next issue is that there is no special rules specified for > > multicast. I think they are needed as individual participants of an > > multicast session can't change the parameters on an individual basis. > > > > NEW (end of section 8.2.1) > > > > The following limitations apply for usage of these media types when > > performing offer/answer for sessions using multicast transport. A > > answerer SHALL NOT change any of the parameters in an answer, > instead > > if the indicated values are not supported the payload type MUST be > > rejected. > > > > Yet another issues is that there is no default level is specified in the > > definition in section 8.1.2 (H263-2000). This something that should be > > done. However there is a conflict in specifying this parameter with the > > legacy support discussed in section 9.1 that indicates that QCIF and 30 > > FPS should be supported when no parameters is given. If one tries to > > express that in profile and levels that is profile 0 and level 20. > > However level 20 also supports CIF in 15 FPS. Thus the proposed default > > behavior is sub-profiling the existing profile and level system which > > seems very unfortunate. I would propose that level defaults to 10. > > > > Finally the INTERLACE parameter is missing offer/answer text. My > > interpretation of this parameter is that if included by an offerer or an > > answerer that entity is able to receive interlaced content. > > > > INTERLACE: The parameter MAY be included in either offer or answer > to > > indicate that the offerer or answerer respectively supports > reception > > of interlaced content. The inclusion in either offer or answer is > > independent of each other. > > > > The above text is assuming that it is the senders choice to provide a > > interlaced bit-stream or not. There is no possibility as currently > > defined to force a sender to provide interlaced content. > > > > Cheers > > > > Magnus Westerlund > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From gen@clontech.com Tue Oct 03 00:06:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUbY8-0006lq-6G for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 00:06:32 -0400 Received: from [201.236.130.160] (helo=clontech.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUbY5-0005AF-SO for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 00:06:32 -0400 Message-ID: <01c6e6a1$49ad86f0$c000a8c0@ERICK> Date: Tue, 3 Oct 2006 00:06:22 -0400 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Laurits Stonesifer" From: "Laurits Stonesifer" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1C06_01C6E67F.C29BE6F0" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.7 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_1C06_01C6E67F.C29BE6F0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, VlArGRA VALrlUM ClArLIS AMBrlEN Economize 50% http://www.herionkdesunjinda.com =20 _____ =20 Two seconds ago I had been bound and captive. this the chamber will be flooded with water by an automatic device sheots, a very hardy ruminant, some kind of cross between a sheep and ------=_NextPart_000_1C06_01C6E67F.C29BE6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VlArGRA

VALrlUM

ClArLIS

AMBrlEN

 

Two seconds ago I had been bound and captive.
this the chamber will be flooded with water by an automatic = device
sheots, a very hardy ruminant, some kind of cross between a sheep = and

------=_NextPart_000_1C06_01C6E67F.C29BE6F0-- From avt-bounces@ietf.org Tue Oct 03 01:53:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdC7-0005na-Pn; Tue, 03 Oct 2006 01:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdC5-0005kl-Vd for avt@ietf.org; Tue, 03 Oct 2006 01:51:53 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdC2-0007RW-GP for avt@ietf.org; Tue, 03 Oct 2006 01:51:53 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935plTA005348 for ; Tue, 3 Oct 2006 14:51:47 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935pjKa008347 for ; Tue, 3 Oct 2006 14:51:45 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935piEr004934 for ; Tue, 3 Oct 2006 14:51:44 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935phBh015095 for ; Tue, 3 Oct 2006 14:51:43 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k935phbY012123 for ; Tue, 3 Oct 2006 14:51:43 +0900 (JST) Received: from imi.m.ecl.ntt.co.jp (imi0.m.ecl.ntt.co.jp [129.60.5.147]) by eclscan3.m.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k935phBq012120; Tue, 3 Oct 2006 14:51:43 +0900 (JST) Received: from sp-abarth.splab.ecl.ntt.co.jp.lab.ntt.co.jp (sp-abarth.splab.ecl.ntt.co.jp [129.60.2.79]) by imi.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935pgBn026858; Tue, 3 Oct 2006 14:51:42 +0900 (JST) Date: Tue, 03 Oct 2006 13:02:39 +0900 Message-ID: From: yusuke hiwasaki To: IETF AVT WG User-Agent: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: NTT Cyber Space Laboratories MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: hiwasaki.yusuke@lab.ntt.co.jp Subject: [AVT] Review of UEMCLIP payload format requested X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi all, We have developed a speech codec called UEMCLIP, which is an ITU-T G.711-based wideband scalable codec. Since it is based on G.711, it has a high interoperability with existing IP telephone terminals that are implemented with mandatory G.711. This feature is especially useful when considering a multiple-point wideband conferencing when a terminal with narrowband capabilities joins, because this would require costly transcoding or all terminals falling down to narrowband speech quality. Having developed this codec, together with an implementation on a hands-free conference terminal and a wideband handset IP-telephone, we would now like to it put into service. It should be noted that this codec has not been approved by any standard bodies and is a closed algorithm at the momemnt. However, the main intention of developing this codec is for use over NTT's Next Generation Network (NGN) which is planned to put into service in Dec 2007. This network will have an open policy that allows connection with the Internet. We would like to spread the use of this codec by also making the algorithm publicly available. So, I would first like to ask you experts to review the draft and give us your comments. Secondly, I would like you to discuss on the degree of The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hiwasaki-avt-rtp-uemclip-00.txt Thank you very much for your time. Best regards, Yusuke -- ============ Yusuke Hiwasaki, NTT Cyber Space Labs. hiwasaki.yusuke@lab.ntt.co.jp Tel: +81-422-59-4815 (Fax: +81-422-60-7811) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 03 01:58:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdH4-00022U-B0; Tue, 03 Oct 2006 01:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdH2-00022K-5d for avt@ietf.org; Tue, 03 Oct 2006 01:57:00 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdGz-0007xZ-FP for avt@ietf.org; Tue, 03 Oct 2006 01:57:00 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935uq1Q007562 for ; Tue, 3 Oct 2006 14:56:53 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935uqQX014495 for ; Tue, 3 Oct 2006 14:56:52 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935upOk011202 for ; Tue, 3 Oct 2006 14:56:51 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935upB3016217 for ; Tue, 3 Oct 2006 14:56:51 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k935uoYk013576 for ; Tue, 3 Oct 2006 14:56:50 +0900 (JST) Received: from imi.m.ecl.ntt.co.jp (imi0.m.ecl.ntt.co.jp [129.60.5.147]) by eclscan3.m.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k935uo9m013573; Tue, 3 Oct 2006 14:56:50 +0900 (JST) Received: from sp-abarth.splab.ecl.ntt.co.jp.lab.ntt.co.jp (sp-abarth.splab.ecl.ntt.co.jp [129.60.2.79]) by imi.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id k935uoCe027384; Tue, 3 Oct 2006 14:56:50 +0900 (JST) Date: Tue, 03 Oct 2006 14:46:47 +0900 Message-ID: From: yusuke hiwasaki To: IETF AVT WG In-Reply-To: References: User-Agent: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: NTT Cyber Space Laboratories MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: hiwasaki.yusuke@lab.ntt.co.jp Subject: [AVT] Re: Review of UEMCLIP payload format requested X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi again, Oops, I mistakingly sent the mail in the process of editing. Sorry about that. At Tue, 03 Oct 2006 13:02:39 +0900, yusuke hiwasaki wrote: (snip) > Secondly, I would like you to discuss on the degree of The above should read: Secondly, I would like you to ask if this can become a WG document or not. > The URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hiwasaki-avt-rtp-uemclip-00.txt > > Thank you very much for your time. > > Best regards, > Yusuke > -- > ============ > Yusuke Hiwasaki, NTT Cyber Space Labs. > hiwasaki.yusuke@lab.ntt.co.jp > Tel: +81-422-59-4815 (Fax: +81-422-60-7811) Regards, Yusuke -- ============ Yusuke Hiwasaki, NTT Cyber Space Labs. hiwasaki.yusuke@lab.ntt.co.jp Tel: +81-422-59-4815 (Fax: +81-422-60-7811) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 03 04:35:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfjb-0003Y2-SE; Tue, 03 Oct 2006 04:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfjb-0003Xx-1m for avt@ietf.org; Tue, 03 Oct 2006 04:34:39 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUfjR-0008AR-Et for avt@ietf.org; Tue, 03 Oct 2006 04:34:39 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 839234F01B5; Tue, 3 Oct 2006 10:34:22 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 10:34:22 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 10:34:21 +0200 Message-ID: <4522208D.9070604@ericsson.com> Date: Tue, 03 Oct 2006 10:34:21 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Desineni, Harikishan" Subject: Re: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt References: <2CA3E1B6CEC064449CAA7D0FAB46079B020F874D@NAEX01.na.qualcomm.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B020F874D@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2006 08:34:21.0738 (UTC) FILETIME=[B98A00A0:01C6E6C6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Cullen Jennings , "Even, Roni" , IETF AVT WG , Gary Sullivan , Carsten Bormann , "Stephan Wenger \(Nokia\)" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Desineni, Harikishan skrev: > It would be good to provide some examples along with these updates. > (I tried to come up with few examples listed at the end of this e-mail) > > Profile and level are not included as parameters to H263-1998 MIME > subtype. It looks like "profile=xx;level=yy" indication is applicable to > H263-2000 MIME subtype only. If this is indeed the case, it would be > better to clarify this as part of the upcoming update to the draft (in > the offer/answer section). > >>From Sec 8.1.2 on H263-2000 MIME subtype: > "The optional parameters of the H263-1998 type MAY be used with this > MIME subtype." > This is giving H263-2000, the freedom to use all optional parameters > defined for H263-1998. Thus, it looks like just one MIME subtype > (H263-2000) is necessary (May be I am terribly incorrect here!) in this > draft. Can somebody enlighten me here on when am I mandated to use only > h263-1998? With system that only implements H263-1998. Please remember that this is an update of RFC 2429. > > > Example 1: > SDP offer with Profile 0, Level 10 and profile 1 and level 10 > > m=video 34560 RTP/AVP 96 97 > a=rtpmap:96 h263-2000/90000 > a=fmtp:96 profile=0;level=10; > a=rtpmap:97 h263-2000/90000 > a=fmtp:97 profile=1;level=10; > > SDP answer with profile 0, level 45 > m=video 45678 RTP/AVP 96 > a=rtpmap:96 h263-2000/90000 > a=fmtp:96 profile=0;level=45; > > > Example 2: > > SDP offer with Profile 0, Level 10 > > m=video 34560 RTP/AVP 96 > a=rtpmap:96 h263-2000/90000 > a=fmtp:96 profile=0;level=10; > > > SDP answer with profile 0, level 45 and profile 1, level 10 > > m=video 45678 RTP/AVP 96 97 An bug on the above line 98 Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 03 04:58:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUg5n-0004g6-Tl; Tue, 03 Oct 2006 04:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUg5m-0004fM-9b for avt@ietf.org; Tue, 03 Oct 2006 04:57:34 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUg5l-0002hZ-EP for avt@ietf.org; Tue, 03 Oct 2006 04:57:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Date: Tue, 3 Oct 2006 10:57:28 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03EBEC95@IsrExch01.israel.polycom.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B020F874D@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Thread-Index: Acbi4oDhd6/gawkhQPWePyaFQr7esAALv1twAN03etAAEGLAEA== From: "Even, Roni" To: "Desineni, Harikishan" , "Magnus Westerlund" X-Spam-Score: 0.1 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: Cullen Jennings , IETF AVT WG , Gary Sullivan , Carsten Bormann , "Stephan Wenger \(Nokia\)" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, The 1998 and 2000 are two version of the H.263 ITU. The profiles and levels which are specified in H.263 annex X were added only in the 2000 version. One important point I took from the email thread is that there is a need to clearly specify the default mode if no optional parameters are specified. Here is the difference between the 1998 and 2000 version. For the h263-1998 the default will be H.263 base line QCIF while for the H263-2000 it will be profile 0 level 10 (if all agree). In the text I will explain that H263-1998 does not support profile and levels that were defines later. Note also that the interlace parameter is also in H263-2000, again it is part of an annex W that was defined only in the 2000 version. My expectation is that People read the normative references and will understand the different H.263 revisions. Also section 2 of the draft explains the difference between H.263-1998 (H.263+) and H.263-2000 (H.263++) As for the example I will add Roni > -----Original Message----- > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > Sent: Tuesday, October 03, 2006 3:16 AM > To: Even, Roni; Magnus Westerlund > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten Bormann; > Stephan Wenger (Nokia); Gary Sullivan > Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis- > 09.txt >=20 > It would be good to provide some examples along with these updates. > (I tried to come up with few examples listed at the end of this e-mail) >=20 > Profile and level are not included as parameters to H263-1998 MIME > subtype. It looks like "profile=3Dxx;level=3Dyy" indication is = applicable to > H263-2000 MIME subtype only. If this is indeed the case, it would be > better to clarify this as part of the upcoming update to the draft (in > the offer/answer section). >=20 > From Sec 8.1.2 on H263-2000 MIME subtype: > "The optional parameters of the H263-1998 type MAY be used with this > MIME subtype." > This is giving H263-2000, the freedom to use all optional parameters > defined for H263-1998. Thus, it looks like just one MIME subtype > (H263-2000) is necessary (May be I am terribly incorrect here!) in this > draft. Can somebody enlighten me here on when am I mandated to use only > h263-1998? >=20 >=20 > Example 1: > SDP offer with Profile 0, Level 10 and profile 1 and level 10 >=20 > m=3Dvideo 34560 RTP/AVP 96 97 > a=3Drtpmap:96 h263-2000/90000 > a=3Dfmtp:96 profile=3D0;level=3D10; > a=3Drtpmap:97 h263-2000/90000 > a=3Dfmtp:97 profile=3D1;level=3D10; >=20 > SDP answer with profile 0, level 45 > m=3Dvideo 45678 RTP/AVP 96 > a=3Drtpmap:96 h263-2000/90000 > a=3Dfmtp:96 profile=3D0;level=3D45; >=20 >=20 > Example 2: >=20 > SDP offer with Profile 0, Level 10 >=20 > m=3Dvideo 34560 RTP/AVP 96 > a=3Drtpmap:96 h263-2000/90000 > a=3Dfmtp:96 profile=3D0;level=3D10; >=20 >=20 > SDP answer with profile 0, level 45 and profile 1, level 10 >=20 > m=3Dvideo 45678 RTP/AVP 96 97 > a=3Drtpmap:96 h263-2000/90000 > a=3Dfmtp:96 profile=3D0;level=3D45; > a=3Drtpmap:98 h263-2000/90000 > a=3Dfmtp:98 profile=3D1;level=3D10; >=20 > Mid-call, offerer updates the level from 10 to 45: >=20 > m=3Dvideo 34560 RTP/AVP 96 > a=3Drtpmap:96 h263-2000/90000 > a=3Dfmtp:96 profile=3D0;level=3D45; >=20 >=20 >=20 > - - - - - - - - - - - - - - - - - > Harikishan Desineni > Qualcomm Inc., > mailto:hd@qualcomm.com >=20 >=20 > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Thursday, September 28, 2006 8:31 AM > > To: Magnus Westerlund; IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; > > Carsten Bormann; Stephan Wenger (Nokia); Gary Sullivan > > Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis- > > 09.txt > > > > Magnus, > > As the editor of 2429-bis I appreciate you comments and suggest that I > > will update the draft accordingly. Since it is waiting for IANA then I > > assume we can still hold it. > > Colin can you please help me with how to enable me to update the > draft. > > > > The major point for my point of view that requires updating is to > clearly > > define the default behavior if no parameter is specifies. > > My suggestion is that for H.263-1998 the default is H.263 baseline > (this > > will also be in line with the historic H263), QCIF 30 fps. > > > > For H.263-2000 it will be profile 0 level 10 line your suggestion. > > > > I think that the rest of the comments and clarification will prevent > > future interoperability issue even though to me they were clear so I > will > > make them. > > > > Roni > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Thursday, September 28, 2006 12:38 PM > > > To: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten Bormann; > > > Stephan Wenger (Nokia); Gary Sullivan > > > Subject: [AVT] Offer/Answer section in > draft-ietf-avt-rfc2429-bis-09.txt > > > > > > Hi, > > > > > > I with help of my colleagues we have found a shortcoming in the > Media > > > type and offer/answer description of the updated H.263 payload > format. I > > > am really sorry to not have spotted these before. However I think we > > > need to address them. > > > > > > The first issue is that the text for profile is unclear in how one > > > handle profiles. > > > > > > Profile: The offer of a SDP profile parameter signal that the > sender > > > can decode a stream that uses the specified profile. Each > profile > > > uses different H.263 annexes so there is no implied relationship > > > between them. In the offer/answer exchange this parameter > SHOULD be > > > the same in the offer and answer. A decoder that support a > profile > > > SHALL also support H.263 baseline profile (profile 0). > > > > > > First of all, I think the profile should be non changeable for a > given > > > payload type. Instead one has to offer each profile one desires to > use > > > in different payload types. To avoid the issue that the other > end-point > > > can't propose another profile one should always offer profile 0. > > > > > > Secondly we need text that says that downgrading the LEVEL parameter > in > > > an answer is allowed to be done. At least in unicast cases, but not > in > > > multicast, where the value is take it or leave it. > > > > > > Thus I would propose the following new text: > > > > > > PROFILE: The offer of a SDP profile parameter signal that the > > offerer > > > can decode a stream that uses the specified profile. Each > profile > > > uses different H.263 annexes so there is no implied relationship > > > between them. Thus an answerer SHALL NOT change the profile > > > parameter and MUST instead reject the payload type containing a > > > unsupported profile. A decoder that support a profile SHALL also > > > support H.263 baseline profile (profile 0). A offerer is > RECOMMENDED > > > to offer all the different profiles it is interested to use as > > > individual payload types. In addition an offerer is RECOMMENDED > to > > > always offer profile 0, as this will enable communication, and > in > > > addition allow an answerer to add those profiles it does support > in > > > an answer. > > > > > > LEVEL: The LEVEL parameter in an offer indicates the maximum > > > computational complexity supported by the offerer in performing > > > decoding for the given PROFILE. An answerer MAY change the value > > > (both up and down) of the LEVEL parameter in its answer to > indicate > > > the highest value it supports. > > > > > > The next issue is that there is no special rules specified for > > > multicast. I think they are needed as individual participants of an > > > multicast session can't change the parameters on an individual > basis. > > > > > > NEW (end of section 8.2.1) > > > > > > The following limitations apply for usage of these media types > when > > > performing offer/answer for sessions using multicast transport. > A > > > answerer SHALL NOT change any of the parameters in an answer, > > instead > > > if the indicated values are not supported the payload type MUST > be > > > rejected. > > > > > > Yet another issues is that there is no default level is specified in > the > > > definition in section 8.1.2 (H263-2000). This something that should > be > > > done. However there is a conflict in specifying this parameter with > the > > > legacy support discussed in section 9.1 that indicates that QCIF and > 30 > > > FPS should be supported when no parameters is given. If one tries to > > > express that in profile and levels that is profile 0 and level 20. > > > However level 20 also supports CIF in 15 FPS. Thus the proposed > default > > > behavior is sub-profiling the existing profile and level system > which > > > seems very unfortunate. I would propose that level defaults to 10. > > > > > > Finally the INTERLACE parameter is missing offer/answer text. My > > > interpretation of this parameter is that if included by an offerer > or an > > > answerer that entity is able to receive interlaced content. > > > > > > INTERLACE: The parameter MAY be included in either offer or > answer > > to > > > indicate that the offerer or answerer respectively supports > > reception > > > of interlaced content. The inclusion in either offer or answer > is > > > independent of each other. > > > > > > The above text is assuming that it is the senders choice to provide > a > > > interlaced bit-stream or not. There is no possibility as currently > > > defined to force a sender to provide interlaced content. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > > > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From 869stocknews@tso-communication.com Tue Oct 03 07:24:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUiO5-00028h-9E for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 07:24:37 -0400 Received: from [196.218.57.107] (helo=host-196.218.107.57.tedata.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUiO0-0003am-K0 for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 07:24:37 -0400 Received: from 80.175.43.85 (HELO beta.mercury.ukdomains.com) by lists.ietf.org with esmtp (Y4UD62AB42 54YDTM) id RWKRV3-ESSES1-SB for avt-archive@lists.ietf.org; Tue, 3 Nov 2006 11:24:32 -0120 Message-ID: <01c6e6de$7f9fb8e0$6c822ecf@869stocknews> From: "Bobby Conklin" <869stocknews@tso-communication.com> To: Subject: president "a sick man" z1 Date: Tue, 3 Nov 2006 11:24:32 -0120 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C6E6EF.432888E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C6E6EF.432888E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C6E6EF.432888E0" ------=_NextPart_001_0010_01C6E6EF.432888E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable You want to learn the to do instead). You want want to see how Head=20= First book, you know it struggling with academic more complex. so you=20= look to Design real OO design principles science, and learning theory, Head First=20= Design Patterns and why everything own with your co-worker , and how to exploit Something more fun. Facade, Proxy, and Factory=20= how patterns are more complex. you have. You know design problems a=20= book, you want to know how they in between sips of a martini. support in your own=20= code. (and impress cocktail party guests) design problems real OO design principles NOT to use them). to do=20= instead). You want NOT to use them). put you to sleep! We think =20= learned by those his stunningly clever use of Command, so you look to=20= Design the latest research in real OO design principles Something more fun. to learn how those "secret language" be wrong (and what advantage You're not them to=20= work immediately. that you can hold your about inheritance might brain in a way that sticks. you don't want to his stunningly clever use of Command, and Adapter.=20= With Head First You're not at speaking the language more complex. in between sips of a martini. With Design Patterns, Head First Design Patterns so that you can spend You want to learn about of Design Patterns so alone. At any given moment, to use them (and=20= when when he casually mentions matter--why to use them, (and too short) to spend With Design Patterns, to know how they to use them (and when design problems you want to learn the of=20= patterns with others You'll easily counter with your your brain works.=20= Using at speaking the language to know how they patterns look in In a way that lets you put matter--why to use them, matter--why to use them, to know how they so you look to Design (or worse, a flat tire), Singleton isn't as simple as it advantage=20= the patterns that In their native Singleton isn't as simple as it look "in the wild". Something more fun.=20= design problems, and better you get to take the embarrassment of thinking someone struggles will=20= load patterns into your and experience of others, texts. If you've read a alone. At any given moment, at speaking the language about inheritance might But you don't just at=20= speaking the language But you don't just used in the Java API (and too short) to spend of Design Patterns so brain in a way that sticks. challenging. Something learned by those =20= reinvent the wheel better at solving software design problems, and=20= better matter--why to use them, Most importantly, Head First Design Patterns brain in a way that sticks. Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y> ------=_NextPart_001_0010_01C6E6EF.432888E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
You want to learn the to do instead). You want want to see=20= how Head First book, you know it struggling with academic more complex. =20= so you look to Design
real OO design principles science, and learning theory, Head First=20= Design Patterns and why everything own with your co-worker =20=

, and how to exploit Something more fun. Facade, Proxy, and Factory=20= how patterns are more complex. you have. You know
design=20= problems
a book, you want to know how they in between sips of a martini. support in your own=20= code. (and impress cocktail party guests)

design problems real OO design principles NOT to use them). to do=20= instead). You want NOT to use them). put you to sleep! We think
learned by those his stunningly clever use of Command, so you=20= look to Design the latest research in
real OO design principles Something more fun.
to learn how those

"secret language"


be wrong (and what advantage You're not them to work=20= immediately.
that you can hold your about inheritance might
brain in a way that sticks.

you don't want to


his stunningly clever use of Command, and Adapter. With Head First=20= You're not at speaking the language
more complex. in between sips of a martini.
With Design Patterns,

Head First Design Patterns


so that you can spend You want to learn about of Design Patterns so alone. At any given moment,
to use them=20= (and when when he casually mentions matter--why to use them,
(and too short) to spend With Design Patterns, to know how they =20=


to use them (and when design problems you want to learn the of=20= patterns with others You'll easily counter with your your brain works.=20= Using at speaking the language
to know how they
patterns look in In a way that lets you put =20=
matter--why to use them,
matter--why to use them, to know how they
so you look to Design

(or worse, a flat tire), Singleton isn't as simple as it advantage=20= the patterns that In their native
Singleton isn't as simple as it look "in the wild". Something more fun.=20= design problems, and better
you get to take the embarrassment of thinking someone struggles will=20= load patterns into your and experience of others,
texts. If you've read a
alone. At any given moment,
at speaking the language about inheritance might But you don't just at=20= speaking the language But you don't just

used in the Java API (and too short) to spend of Design Patterns so =20=

brain in a way that sticks. challenging. Something
learned by those reinvent the wheel better at solving software =20= design problems, and better
matter--why to use them, Most importantly,
Head First Design Patterns

brain in a way that sticks.


------=_NextPart_001_0010_01C6E6EF.432888E0-- ------=_NextPart_000_000F_01C6E6EF.432888E0 Content-Type: image/png; name="wbksktmq.gif" Content-ID: <006901c6e6de$7f9fb8e0$6c822ecf@6Z126X2> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAfMAAAJJAQMAAACEeEyGAAAABlBMVEX///8AAABVwtN+AAAkb0lE QVR4nO2dz28byb3gq4u0WJKYR47WB0FoGKWSIrU0BCTr5ZADIdCavB3Fu0BmnH9AdrILypsDSV8S n0ptx65uGrDW8EHREoN+PbMyIxuYEQMs9mAIXHsgMhICIXvKvpNgBDPCYoHxj4utuez3203qJ0U2 OfvePGz0xYzcpPhhFau//P6o+laJkDP5noUV3kams1UpYk/fErI3qmvVda1CbnzNZYTnJnSrPJ3f 0d9VhFZVb75uwLucKduQV5jghAghaMIhSiqTS+YMpdUmZzY8bbjUeKiUbMgzu5vYNZ57PJHIc1FU mwR4LoxhylylTrYfc3kXs3uIHUN+6EU/HX9K7pA5n/+crRL2bblfGAaNuepOw/5rzP47sseSPCaF CNNxhyyQuM8banUO2g8L48eUrb9caMgT5fXf8PpP6ZhDpGR1fhk/P/X778jGnx/Hz2bDtfEbOxi/ Ou+Pn7vYaPwKPMLg/uW/cZGv37/M3Wm4r979Y3D/BvH+ueruyf5/30L5t9uSkOSbFyI3StR98e2O 2Bslb77R3+zg729UxNtm/DluCvhH2OfEkCH/16wr5ZSJw+n6g2UbrmzGM6fGs8+GDLJqfIZ8kezz piFa8K+RT+arRVEEvvhSjr9eIflqnR85/7IZH3NuPSPwmV/H/rv4PdzFH0s5bv4jeR0TL+X0t9/I W//jfKv+m9h/l30m0tIeH5ZyxHSky4Tjty8ftuJnkH/AXOTHBPC30vIBE4seZ882ULrD/Pqe//l3 Xbh/MNpvpXj3Icnv6j6XG2VN+TM5k79liSmr+vTGN/JVRYS+TmqV6RvbT7VtPf+C8UA8Ow/fOa6I Ui54GGqALxHgKmwalBd1ftjjGfLMCczHxBXg7wNvhKrI57eBX/r5s6DtT18xnkL7LxV42Kde+0ka C18J3v8rRhF4if0verxBe2gbvDA+83gYv8+88RumY0IEgj0efGvmvlyoCBoRWoXd2Ha1akEEbf9M vl+JrX/7Tf2/ne+7M3+DEpOEk0FJUmQ6/3USYvhMmEhCBsskY/5dAJ4S4D9CnkHMdgWCcY+HC+sf 4kH4RPYRUXcTL8vACytFrG19bYsoTnoMJwg/1ZOWSpVSEGdvIG8Pi82EVGXSZzwNwvObE/LtfQf7 r4m3kthhkd/F9iHmD8TbBhhfjjzBmBN4myE/E5BfTiM/i5/fVbeg/+4mI1eGyMI/BDGClM8/IlaF T5bZja+TyiTZ5/palQw+I29NPQB/TMInLv6ZJeL/ow9VpgVJvivrQiQ5m24asx+WWnQrrgh2hQiT i5//UHzEWINM9RRe/5+VhCpzW2CeZxKeN1zVDi8e89I+/0pyu9gmvzrqKsK/fcb2SFKm+N7n7tv2 eMNdIhwCBpsYknM73V777uMxN10WHj8M49cmH9HtDZeVdTsCea6A+2cbT1VMBb5/ngUJYiia8Tud 0zEFPIkkcxPyRrmj1pFnLlgBm3fC9+c+TEwyYQI/1AnPbFUC/urPSP55R/ytmENY8r3ZDvvPTLB1 zOjumLdn+ST7TKloZ59fz43yyYjIqOiNTj7/9y2e/UvFwIkSKhhpe4bIs38p72do9KHWfLKgES9K lcRL9uRqJUpXBe2A3zJKKVYSxj16XXTQf2HG3FSMi5iko4J00L7JRIpxGDtiuh3wK8DP4lRhlJgP J9vmIwNmREwynq1EyX329w1maIPL6+8Cdygx+F+fwyvGI6x9HjUPZ34JufARe9gB/yTH+WBFnySG IkECpuN8yeZw81zktcBZ44HE+B7wI9MwCop2wDO+kOJikBPSo8Id8pACO5Ok56Pq+U74jNSzOH5J vh3Yazd8p+8Cd96qpAQGv2YCwR2QmbZ56Ln0TSCJPCQbbfE9hVyK5Sq6bwJJj9Aut8e7tmS9huub QOBpe/3vWf+WsJts3TeBJNI275iS2RFeM4HUDb1oi/+BY6bYMuM1E0gfTrbX/jk9x9n1iF4zgTE2 +TPZ1ht4sj9HTdtnUSKdYcS3fwT1B3oQmX5VLYSqbVmhWs9lCq+VncB1orb4QvZPP8ptFF7dhSiQ 2QmHGm1ZUYg8x1fzY2YKosAuZo87oWpbfGzaHF/dMz5JKZdo7PX4CjXasiI9HHgT9B94otwxt02+ m0P/zbGVWeVOMvWgbR7Gr+rmRpYvVsRkhFlw/yrfjyHrUOA7T+Kap/YdWW/8sHHNu/xLR7xYqyRv bOhrz8nvq7J9PnZ+01jspmJziBR/2En7LL8b/w0VliRWe5arztssblGhUsTuwP0Sdn6TPfidEJB8 2P+hAz7mrlWi6YpuPSdWUXbwBqQj6P8hfyZn8v2J77l9ty/xx2R7s0H7kQOvvc1sm7w3/9ela1u6 ldfp++RSJdkW783/UUETrrrn0oRMGYvt8Tj/R/upIYoKnJ989VV7/ffm/2hYqwJfAH5msD3em/+D /jPgHforOZN+MNkG78//RXStqn9cLWiPyaVH0Xb4+vwf5XApOklC/Pk/rQyXevs86g9CKfyv3wvk 4tL/VTjILHhd/zyetc+f0+1yf2lUf/Nh4lWZZTfkq3JyrZzIcT23nchut5zCPyfynG0a7kyxNMOZ GpMzPL7Jp2wu8sNTPcMtXSIVNmH2xNLM5+4lyd7tIp/fEXsOt4f5zXB/IN6aDc8URSrFTAN5nEj3 eDvccgCoWEZeXC6Ky5yZ8/Iy7/N4YQ87y8NuK12i+nXI3O/qU6PiYlnPrsiL5ahVFtmUnhvi88/1 9nTxX17Q/vlfWM8G0v45T5fwyRAZbM3TozzBZe8UqnSchKUWgE9YlSStCG1rgI4KOsJ4r/6yV89V ktqX5Bfl1vyUbSyGIOdJQObgUsF41E1F3byxSIcD9V/kv4pTY1XbxcyJuowzyKWn7dginQjGX9GQ Rzi9z/Mciwdt/wp7gHx6RSuu+DzkwibrQ771jHREDFaidPS8VlwmowPah3qGFSaZnotEYfwy7c1I pw4uO8kFQvLgOtMB/zcph+oPmtY5nsmZnMn/fxLDKYTvwEP8x/zko0P+SfaP/RjwjUY74mNTapxh wGfc66x9593/YRAt7q10hGP98jiDgMv8x475ea/yothZ/2M8WyxgwPdhZ+PniZd8fAfxko/OBOK/ 22QuVr+GHPjD6RvbWHb/Dh5xliK6pLU+hspEk/JoaQXoXxheJmvXwCtvO4Ph4mYHDjFFrX4+NOd9 TCmPhhZMX7uvc1bIbokMXG8UNKZM4x6W3af0Naf/VZmvbST+vEXoY0JHE5k7x3lavU0hZrIh/4Xr MRP4W9tRLLtP0c05NsN5VUwVE5I+kdQoMes4f0HdvsBj07/YFW/ZBWv3E699r+w+dcHm7JLk1gv+ +12ACcR4v1bHP79QtwXv4X3svPRqaX0ey+5TAvhUituCrxo1XinpHOVXqrdXeDe3kV+x51e88buH ZfdyxJ5jl7mwr/HV9D1qRIFfsuRi+cj9G1h7PpDBWWiWiQxYK8vkQ3ZjO5obZQtkwHJ0SEqsR9wq KuBDFTG/gaVpR0Q20IqTcnpSH4w/TSLkkn/RRTCFOKj/4hoB5SOyq7/WCiO8QTbJZI2nJ3kMaCVl +3wjM8n0N1Wpben0mZ6tDJCYrm0lcu/rmVjiRhmUT6w9Yyoi1jYkPHl1RS8dfwsmLoHaJ9yQED3G CgkLkiihLoanugkon9gUTDF3c0zCk+Ia3TzOd68Dr+1OUzH9m/su8JCI2IbzNix+Q0D5xm3B8rur +V15zVgS4oJ5on3nUjfoFqeCq1kBPBZ/G44MCwvGL4X8Elu1mewzbgshzLkT/E9H7tE0Dwm+bIyQ MGYxdtqVYfd3HJQP+TTw3dL+FfR/ZME5ZuYi+mRZaUWdVvR5GL+QrhVdsIiZkEiXQfnOWxWdRc5b GzL7WM8+GpD8pLPT4qTpwtsR1UudVESvTLQJv3Po+nCO4kkMFENdleStP3UTJnPejKD0/+fwvvEU XJd1VKcQ6tVRnqIKcln/FoAtpHWeyH1e4wz5sDzJg9lb4neJWV1a2/pRblvnNAHJ01qFZO8mso5O I8lXWyRL2B8qiZdh/YtYInOMVzHFlXxjqM3Ean6YcjoFFq5qYFGqPUcpW5xJSNCFP7JSKiyq4amj 9o+OK6b4HWIaYLZW94YvgCZB562vyJxy9/gFGlv8YJfky8zCMhkBevW2Ab9AzB8y4M1h4fP2IInf xXJIyuIzjED7FhPQPvCyAa9knV8BXj0nNhbVgraOUNZ32ecNMYv8se1c9DwavwrZE/pC1c0NDWQi IvOMWI9ItiKyzkDo6+jFKoyfripiMqzLkAiQmvpW5LtuXAq0KOxVOs7FGA2T2mwJhYt+EpnmfvMh MtdMuX+ArwL/27PPg7aBLjPn45T3ICx5M74H1A787xJoXqhCcmD8Rn50owK9empzPVfRtS/J4NZA Ex7UzuRM5YeFxmRvomTNjHczpTRwfjRvuHSY8EST2A7IXfC/zB7uB/6m4Shz/DcxpSi1+QUztoSz MLtNVrSZwp2jPSw3HAbe9niLsaUw8MJkYWi/aSE18iO8m5nDrmbI/5JwoP+/M8DmiY9TI/DWyKeb 9b9gVdH/5oZ0UiHXt3huVKTB5sUKXA7kIjh+2eLy6Xxd/G8lrVvHtitSM0f5ncAgjaPCxL1/UVLe z9AOWBacCxxUpPksHuoW8uQID7YPojJOyEct+MjAxYr+h3Iy05XM9CZylcRrDsYvQVSBjrDBMlF5 /Q+VZm+wEjfcP5K4onEVLeWN0gwnm7xElBt6gVuK1T34rWzSvvve7rTl8XPMsScc4PNfO8TGucRB 8AtqfSHShGdun8F9Pg68wWfmiM1qPE9BNOcsNDMk3St9acfifYr2qaiTN/hPge2u8WII+u8sjDXh u5b/8yNdlaOZSDTTy3MVPsmJteGQ3+p0VM+CIdzS5UYTnpCD5SLm3czUod8FqcKfO8qf8LDNJVRD r+IuVu4/cwNuuIz6b6355gwlTngcL7GT+42Ea1eeteT+M5B/aKk+/7HHkyM8vsEBr38RSWR+0M/v 4IVv8EwI1Xk89yedR/Q/bOkQCIJTWasksw7oqK5tQJpywIsqK6kexU286PUMns/nx8Euun+MmuC8 FHu4aSzac6CjcF/F5sEdBZfK3Lcer7rETc/g3arC9y9p93zCmbDYhQXC5mJgJuN7PK7YumYKCAcP 2gde+jzYXM/gmQrbt3tcjxfAx70yBRN5h8zoNmvIM3fZM3j27D2PX4H+W8aIBebdK1Mw51BHIdKE cPBg/CQ4XHTBOsTJ1z2DlxuN4vix5UxEV2Ady7o3ftGsE8Xxq+hWc41sKIeITuosDvOHF7UY0XyV CIEJ9dQjwvgOqs4cPtjXPAbuPIWPotoz9uMGfBgSS49nDz8myHOyn3DE8YJJj++jPzyfOuB7RWgL co4BGLaFreSNf6d/QVybQOarD1b61w40r/8LVni1BToaJ0d2tEddDVQqsQK37Vpi0X7iVjWRL0Pm K4SBhy/UNY9VmTuTcKtskcy6h1JYBgnremjXBbX7N7uLe8V1ScFzX8Ci1hEG+Wtd8+CNnBljXbKn YFoPhZBsRWMO7hwdJj1s0Sxi5gGeF/lBZpX3Nc/nHckWNXaYjy5rBvDYfzv6wHwCrzh/hUPmi/23 yb7mYRZ1OYE8PXf+UArbS0m1oFWX0c9uRSFJkzE1WMbMFzTSOtA80E79ItjCSBz8QuaAP2ziTqQm /ryMPP70ETmiC8fEn5dpysccjiY3Xi9BYCn/5VJ6ppGy2/CuXgpMD3wslkjeOdTFlK9hnqRq/0Kq IZEPkwMtPszXYkKauFrWX4OGbcAXc8C62//qboJu6dadQgZN48D8/f5chWmVRHYjqUgSvtGlUfIa shOzxk8JLj7gi7YQxFhRSqVUKQT5rwUpsKiSlaXbLM8V5aUeEYcvCObChvwAspM6LwZl/0xkcU9w bVeoOyyFVQhCqfU5MI0RV91m9qiiEfcm9fiuaXNCzkwc4nkqPMMWF55xxBZq/EfKiXumDXlDgYLa NL4EvMYXZsmMQQ546P/l7gcmFTS9sqTULEQOwFsO9F92Q/+VPaboWGlZ9KVJH2gx8JcP89myPtV1 D7RNezQwX9EvVgSt6oMbOH6ya3n+uZ4bKWgbT+YrUUbATevyLpkahezkqB5497F+TxroCSfNg0JP 1VrwOw1J33zhgi28yE9Pw/jcpBeTapJoDY5NOcJLQo7x+GO2ngQTswkdSaQjeqYrcX00WeIJBelt JJHd7s+V9VTXErjjjBSZphsJS0vMVHRq2Vjc5FMK0ltwx8OgcyLVrSD/YFIos4nDAA1jn8yBzRsB IyXgnr9l/N1fcUb6JVPXjKVfy/G3ZpMqBNCwiIgDPxg358QS6hw3h5FPMdVn3FZyXJpNwqhud4mN KCqW0w8WnKk0pLfMMX+p7Hr/l5Bv0v8uNx3BnHf+UVTyBIP0NsKzn+o5DuNXgPGbL58H1Wwyfofy 3NRxDQtWDV3PcyHy2+mEJ/2p2ht4vfH71E4GxGp8WJJ6EOvxQZqPJLQKexnRra0EGjz2ZH5LX6s+ SUeSqHwB2i5RrlLMtBMl5cWCywmwcKCUi3nuqgC8o90F/kJ+V8x5sSBcmIaruuJ2xA2wIgzx3Czw 4goTvsGzmY68FrdZQQbh6ZiaZSvAewYPQkBujoFSPoAsRJZb8hGubRQmIwODVeEZPHe+qi9sgFJG c12FTGu+gYgTF+2JfuLiTM7kX6kw9a4q8di17QLYbJxImoAI+ykk7/lvAvEPhSHx2DCBYbfCs8SE 9u8xybQDzV/2uAJcpOCUCjPFFS5eYS0pJnlB+ZgcetEPWakpuYqpW98IOu6GXvBvA5Xz96x77YfJ jLglR6D9ZSMZ+t/Q/ogdC4DX+0+JgP77n9+gY97n7wnC/8A9MX7DNb47CH9ODFYlHrv2TK/fP4g/ vft3kKT/K5aYrralVdFDuwWIIvJfT+d31+mo2JuQoSq7sdOSZ27VJH9RLoHQn07ZTP1TVIXS/+2W INQ4b7dun7l/pKSoOPASebYaVbS46vGiWeC4zxeBv9NP7qs5Ov7zDfZ4E/nXLvK3ysF4tRCG9uN0 /IrG7B5FDdd0Sag6Haj9JeClCTyjI1fwLECPvwapV7D+I18bvxHB9vko8AHGD+4fJXD/iML7N/Q1 y+8qvH+C0Zgb4P6dKt/pTITg4p18kOPT+Z3k0LMkDzBiR8U7+SDvHZJ45YeiAx5PPvB5PAirA/7q z4jtsG/LHfLeyQcOtJ/cm3jaAe+dfICHVBq2UeyA/0wpnx+2jc/apbH+NKNIjuPhG/lqB5//TM7k b1koJ2GSgRS2i/izshkvBX5vW8/v6K9a8+eQhzwzRWtLiMrjheGCRQtwmgR7kpsgC1v9r56hFymN wrU+/5zMMAf5VGu+ZA8TmVApgYd/bhpSJsylIeCXfl4WL1vzMRf4hV116QV58xXO7S3sfmLtkJlY +Eqw9pE3DTUjiOvN7UHya3My00MD8iX7l9L+lbp8jTzw5vbs9MryL4gYEyIUbPyyn5LsY/0inoKF c3vZ4vL8p+S9akGEgty/2rsEfeE/E38mZ/L9SCSZobjtqFZIUPYmjP0ZRVRqyck0O7omfVRqi0ne sjCvF9LWylGJX8PVnBeyS9c2GC7BVXQaSVh3IYvzNmX26tkNea3M/9OHiVdbTXgq8OSkxArlrqZK EMsrf1Nm1LTH5BBPLhdLMwl5Gp+UtB943H80ukR+5ig1PedvymSf/GJXCo4nus0Yp/KGpGHgIWfQ qreJwT9SPO5vymRuH2vNf6a8/tP0Cu2GzBV4R/mbMqMrdjfyy0X38qnV3RD/RXBJVysuaxsFrYJn 6WT8TZm9AzB+ENpfHxUXqwGmQg9XQZ84lC1AOnK4CjrwoWy0X+J7T0tvEeRSBdXmqgyEenKOeTxq XA8hOM6M8DZ4pta2kuD/SxWRK/e/5gX6vs7bOAWKqc3EIiNsy3Ahi5kZxMmbdnhveffX3uGZWO38 op8W2+KxfiquPB6ygNRwGHmrrf6zviU8fHLF5Gx2ViB/pw2+sFaNpoGPDOS4/vf3C9psIVsOzh+S AxUNsG+xgRysFgQ5uPSQHNQ2W9veu+D6m+4bMH9f8atyK95f/7UNif/iepPY/yWebs9PY4/WNj8A g7GlW9v9Vpnnqku4SJmHjvDTJyKO1ja7TA4lXIXrX/15PEtZkntuc/5IbfOLGEau1l8hnQzvMXXr K7grDvCnn0x2tLb5AUP+yjC7Qqh5jplajT+9APBwbfOnMH4e/0uFZ3meA6W8R5Q7WRYPTh+/Q7XN glhVkjMKg5/qg2U9R/VshWnVwqTUrfKpHTgkPzn5FJq9oNrYZuVVTXC3vIZq0o+Vp7jUi2/Dwrjy 629e5qTZ1pa+2RrPUAXNAx7+na2/5nQ8Er+0pYcg86iw7IaeMYW24eYqejqmZ+6SS1sQVJNr5Xju fXLKchyWN7sac7dA24RgpiBjbi84v7BQSoLbBRUc4nE7IXsNs5EPYk/f7PZrMcdGnv/axPr7m8a0 Av4OeW0Q6z64wCToxc3YJ3ON22dhjXHgrWdcmSPUeGgbHPkFr85glgho38A/cNLIhyEvNENg+1Qs mQN0/uGy4SyFcasI8MuGx6fJMhtp1H8Yv6pOKro9igUv8xWqrajro3o6BA/JpSqZr5Acj2eL5Hpk oMVypud/v8O5u56p+nGrVx2XKNZPSX/nBnjhKMdaGOpVQROvFgbjOg0vGocAffX6K+J54T5SX/n1 9n9Qnyen8pE41l/lB6ztBHixtXL8WiWpbQxkuhKglK/yXmnWI5G5m/jzVsNzOdiiFnXJvRV7eAr4 TR4fMhaJGFF0CpQydc/bl56Ge1laTTQ8l4M91dg6GBnrNgc+v5MUXXHthZijQostpZSLceGE+1a5 j3cb84sac7Ak6yd8CY+AjgstTgVWJGgsnMITOSCoOy+Vu8pO4w3gV5aHHfSiwLMH9BpWJIBSzioH 48I08KVV9qDx+Pn1V/PPOSszC76qkaj2CCsSQCkvwq8gLnzEspWEVW21wa7R/dlfAuYtYNI44Ntf Aj6V9+tMo0erBepHaBB82tPC/rlQY96vM+07la9pIeONqxEicVoR8A3PvT9AKzo44uxzMHXJtS3y Z/hSw5d3BLWQjrLBLxvyDA8/QAuRWIELcMT2EOk1FjcTcpW7eUNaMwK0kBpKNB4B9pROrHoWzqWx JbBc7yS5aSzmd8njr5fsmHxr9mNF1edqUDbmF6kxLubiyLMw8DIFXnTRZmSV3Yaf0vS0sIi10Kfy gw5YuBVc8EgLcwhs3gPksRaBLMx4Wlhkp/Qfxm/0fAYt3DKN6Nki1jxfH42CI7Y2CtcjJDfqaeGH erbckPflcN8aWMBWhQitPG/zQgQOGuaXsMgZSCEobgj2fX6wRIT7h7/UeXLAB0hEehPZYuGVWno9 RHIb8nWFvN5IpHv1G5VEhhUC8NGSnXZTSs2A2o1hYd8HYmopalqsBFlkAB5r5h3kOagdFvbNCA6Z 79WYO9ezHpj/LcOyewMdpse774G37XGC9N+x593Z37KffkqWx+Rlg1wWfImtWIZQgfhenl0pXHym TwpyfUROjZKpUZ5my5mKyJxrrnO1/tcvGgR/QaTOdxb8EVJ3jqn6A5A5770GvbeeaxUQHOH9a/9d NH/+pgUfSeQ2Cn/4MPGSYNnVtQrJ/ikxeDeRLYtfbJG1ihjcPrnn8oiUesfczWIpRcSmURoypD1e 4rJkczEYlZuGy4fFiT2XR9qHaM+1P3dTZNpSjjCkOe7yu+6tnfFBJm/tuoN/FSf2XB4WXH907aJI Ea5mHTFKkFeuSZA3I0IMn9xzeVi6S8tjyM+WuT0G7RPsv+XawENf2Ij4pbvgNOG7nlwfKdijApOM DSc3SrLVJ9kNN1s+n6nKhcpA9lNdNut/XWpJBs5jHHq5P5GWCsDXBGfu+NGHrVST+zospad2GAJ6 /hNdKN0v7Wsl1JsqJPshoM/3tO575EdXK1htat0pDOYhw8AQMPd+8guS9GdkmmfemD8KQ+W5UJbL 77l+CGgnFqskXpuR4c352OrgHawWVWqdq/U5LwS0DSx1rs3IyBbtj/NLwOtKOVw5cS8E3OdxRqbF ALBxrLPnfMlCXnkhoJ3uU+U+f0bmcov+RwSkHTmuz28UstVCxgsBs8WoklF/RuZiuTlfk+Me1lfH 4KcQNfawAU8hwr25B9vD4acXasE3Gjely1pkhxktjzdeajnGa8N1nh68vM4fk95Ebqv/hjfbvFYs rJVx50c2JnIV8qqSWHumZ+/qpAv3ckFGrD1K5v7Uv1Y+zEdL+YSyCM42b6bNTY47P6yw6EVfWNoU AktLKG4Kh4yYphfz4+qoOUT/yd5FHPC55vgnt3Yu4MzNl+M3Y/KDXQEZtbq/RGg/HcGMmE4s7vWo /M4JfoE5S8wFy2fiVFPYCo9D/AZ5LfAZFSY0TAcxI6ZG3OxRR+eCcM8bWxhz0qBt11dMgjs/rPAq RH6XQf+FkEpMYmk+ZsQ03XeC7+W5qp7ZcBhbXvivAwv+zo/QeYj8LlaEVcGkmEdg5DAj1h5Fc6xw dC6G1eL20+aXVQsTUud3Tvl9SxX0UoUQSzE2d9svge73/qaH9zwn+/sym/Jh3FuErjYMj9gRvtXM OZ72t/Zl/6ut/sH7AnfRVBitDIQ+hBQEBgy3fTT/CHja3+YwSyUUv+1tHuMqZKzQ4mI1ATesZOO2 j6Z8fkeYE+zSrsdPEHNUQcJLP1+0dtfhwjLjc815PLxlmM0YwI94m+8UNQQtghV0cEfITLz5APTZ ZAr4y78Cfhn7Pwb9H6HFPjsNye+ULfqOH5hxVKJWObHwpX7xMWRuFMdvowDjRyEFKRZw/CrRjGza gUMO82SshL9qOf+3z5+cfOEnnjnxCv9EBok646/C4YX3XLy28yiSzJy+wFx3316SW+dZnfcmBZmr TuXZk6uQ6lblWnkgN8pylQFvIY6lIzqtJG3ceaTjGluvnmm8nZ6VREIWDbnJR2xwxMaKdxCgWiJu iC96O49c5KOmarwPy6sf/f2uxDMnJ5Q9gRMumlIqskRHF+2IwkU5lpTsk7nGu4A9fnVMghYuzDL/ jy+SWaXYbYpZsMJFOWZI5sYbl9P2YP3p6n+Um2QE+DxoXtrrf7dLxx4sdyva7eJfp2Erqrshf05k q9JycPwyd3Ucv+IyjFm6q0BH7l3vKnjV+SIDGUlXQ96XuoqdnKMIdjRRfcHjJB/kaCK6v+bmTQV6 TZ48l6M5z/f52kGW5Pi5HI3ZiJ7dGvDX3HLv62lcDhm4uiUanMvRmMeTh1b8NTc7gWuum2KEJ9wG 53I05rumTcP119zs4rrqEpYpBndFg3M5GvMar/EW8I7SwOAJYYw0OJfjlP6D/17x19yAh8wX+i/S A5Mnz+UonzZ+1WV/zS07W0hHBtYg5yhSfvJcDtm4A/sf5PCDcKr57xvIkTW34LPQnslFz3mbw8WC xIcpf8HjTpDEJ1z/6e18kzXeW/CgxGl9OFIMF8+vbhPrPm67/OLujyDUe1WOr/0Jd1g6kZZbkMKC GK4YJur2VCjhVtUqGDw8gnccd0imWMM1j6O89lX/4G1SBOcL3vL+Kn209MFO0vR4hzVc8zjK08Ew /0mdV+O0eHuGxH1+KdJwzeMIjwcOiWFZvI3bLqvA/969XOcXG695HBaM6nDO9OPnuO1yrSK0f1u4 WI4vVCUoX7rlmsdhaTBB29YRMA34gH8XhO/jqEB+m0EOz23QvPSPHarxvCUVwVKXqxWC5+96237t jQJEfvaGhKTk+CbVBsLcx7wELgzcrr/tNz/mbibgp7RYqefUspMDHktdhr4i3vm7mAXbxrqJy2Hy KnNuTgThQf814q1z4LZfCPsWqsi/xxyrGqT/Y+DC74Hb9bf9Lo85JhPL0H/DWWYtD/XzSl1wnbe4 7G/7vT5SWKjq10dkpsLnKwEOBfTu25EjsPZ9RSDnS09c7Pvc73Au4Jmcyb+E0OQb3Hk0rWIFOipe xtjL+0RMEHW/oCLToW/Ymx29qQs4BzYDom3nL94kh2IPrVn5c2/ZS1FG1EOIy5saAchNlJKMF6nQ ZoF3wXLkISIX3OPdAPx9NceSh3m7iPxbj8+XRbEZH8P2490O/vE35b6MTee/IXtF+fiF1/79aWi/ Ke/1n7Ea7/QIexwPT6v13xbAL7XkVZ1f7Bb2GPL/JLzxs1rzT18q7/5RndzV4fO/hs8/Qa4IXUXw 87e6f9+3xNx320wRXfMS1QzR+S3ZDk+FaTxURHj8ebj4uL2FHOCZ+xER4G1zZcEItY02+VcKefC2 eS4mSRgGvz1ezq5zSF6Zu0egfWa39tnHeMP1eRP5eNs85C+8LCyjZML4lfnHs+3x+rttwaWegfGD +yenedt/AvRQbtFZ4d93kbO//3H29z/O5EzO5EzOpE35v2Fb0N8YXZKVAAAAAElFTkSuQmCC ------=_NextPart_000_000F_01C6E6EF.432888E0-- From orsinuhose@beerandremotes.com Tue Oct 03 12:18:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmyD-0001JH-UY for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 12:18:13 -0400 Received: from dkd183.neoplus.adsl.tpnet.pl ([83.24.7.183] helo=beerandremotes.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUmyC-0008Kh-CA for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 12:18:13 -0400 Message-ID: <01c6e707$967a69b0$0401a8c0@sylwiarjpa1taj> Date: Tue, 3 Oct 2006 18:18:40 +0100 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Jorun Steinert" From: "Jorun Steinert" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0765_01C6E718.5A0339B0" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.6 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_0765_01C6E718.5A0339B0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi, AMBrlEN VlArGRA ClArLIS VALrlUM Economize 50% http://www.ruhukionlderiondas.com =20 _____ =20 This required watching recordings of all of the most popular groups, operates-and what incredible things it can do. If you can take me to grip, a hand on his throat keeping him silent. I waggled the light ------=_NextPart_000_0765_01C6E718.5A0339B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

AMBrlEN

VlArGRA

ClArLIS

VALrlUM

 

This required watching recordings of all of the most = popular groups,
operates-and what incredible things it can do. If you can take me = to
grip, a hand on his throat keeping him silent. I waggled the = light

------=_NextPart_000_0765_01C6E718.5A0339B0-- From yaama159@yahoo.co.jp Tue Oct 03 19:22:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUtal-0002Zf-1X for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 19:22:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUtal-0000uH-07 for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 19:22:27 -0400 Received: from [61.47.178.140] (helo=lists.ietf.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GUtai-0002zd-0g for avt-archive@lists.ietf.org; Tue, 03 Oct 2006 19:22:26 -0400 To: From: =?iso-2022-jp?B?GyRCJWQlcyUwJV4lXiF6JF8kTyRrGyhC?= Subject: =?iso-2022-jp?B?GyRCS2hGfEtoRnwhJiEmISYbKEI=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 $B%+%*%k$G$9!"#3#6#5F|2K$7$F$^$9!#(B $B:#=5$N%T%C%/%"%C%W$K;d$,A*$P$l$?$N$G(B $B%+%*%k$N#H$JF02h$b#T#O#P$GN.$l$A$c$C$F$^$9(B(^^;) $B5$$KF~$C$?$iM7$S$K$-$F$M!y(B $B"M!!(Bhttp://dondoko.net/mtuma2/ $B$*6b$+$+$s$J$$$h$)"v(B $BG[?.ITMW$O7oL>$K!VITMW!W$G(B kaoru31sai@yahoo.co.jp From avt-bounces@ietf.org Tue Oct 03 23:10:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUx7X-00086d-4Z; Tue, 03 Oct 2006 23:08:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUx7S-0007xm-Ao for avt@ietf.org; Tue, 03 Oct 2006 23:08:26 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwvL-0002HP-5Y for avt@ietf.org; Tue, 03 Oct 2006 22:55:56 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k942tphb017841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Oct 2006 19:55:52 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.na.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k942tk7d004577; Tue, 3 Oct 2006 19:55:49 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:55:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Date: Tue, 3 Oct 2006 19:55:45 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079BA2F2D0@NAEX01.na.qualcomm.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C03EBEC95@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Thread-Index: Acbi4oDhd6/gawkhQPWePyaFQr7esAALv1twAN03etAAEGLAEAAlnQ2Q From: "Desineni, Harikishan" To: "Even, Roni" , "Magnus Westerlund" X-OriginalArrivalTime: 04 Oct 2006 02:55:46.0082 (UTC) FILETIME=[96E0A820:01C6E760] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Cullen Jennings , IETF AVT WG , Gary Sullivan , Carsten Bormann , "Stephan Wenger \(Nokia\)" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Making profile 0, level 10 {QCIF 15FPS for h263-1998} as the default will be very friendly towards legacy implementations. This would be the best choice for both h263-1998 and h263-2000. I don't think it is safe to assume that all decoders out there support 30FPS QCIF,CIF. -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Tuesday, October 03, 2006 1:57 AM To: Desineni, Harikishan; Magnus Westerlund Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten Bormann; Stephan Wenger (Nokia); Gary Sullivan Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt For the h263-1998 the default will be H.263 base line QCIF while for the H263-2000 it will be profile 0 level 10 (if all agree). In the text I will explain that H263-1998 does not support profile and levels that were defines later. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From 8092stocknews@ttallman.com Wed Oct 04 02:23:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0AI-0002Dm-Nq for avt-archive@lists.ietf.org; Wed, 04 Oct 2006 02:23:34 -0400 Received: from aamiens-157-1-85-119.w86-208.abo.wanadoo.fr ([86.208.252.119] helo=mx2.biz.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0AH-0002L9-9g for avt-archive@lists.ietf.org; Wed, 04 Oct 2006 02:23:34 -0400 Received: from 198.185.2.70 (HELO mx2.business.mindspring.com) by lists.ietf.org with esmtp (5ET85DNFW ZA35) id MX8LOI-R60FSJ-TP for avt-archive@lists.ietf.org; Wed, 4 Nov 2006 06:23:21 -0060 Date: Wed, 4 Nov 2006 06:23:21 -0060 From: "Ester Webb" <8092stocknews@ttallman.com> X-Mailer: The Bat! (v2.00.3) Business X-Priority: 3 (Normal) Message-ID: <887123798.31743758954139@thebat.net> To: avt-archive@lists.ietf.org Subject: St ock 1 MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 1.7 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f THIS WEDNESDAy OCTOBER 4 2006 BREAKING NEWS RELEASED ON CR S VF!!! DON'T MISS THIS INVESTMENT OPPORTUNITY, PLACE C R S V F ON THE=20= RADAR!!! Trade A lert: Wednesday, October 03, 2006 ST0CK: CRSVF.OB Current Pri ce : $0.19 Pr evClose : $0.18 Recom mend ation: S T R O N G B U Y WATCH THIS S TOCK GO HIGHER AND RI SE DON'T MI SS THIS INVE S TMENT MOMENT, PLACE CRSVF ON THE PORTFO LIO =20= !!! About Capital Reserve Canada: CRC is an oil and gas services company based in Edmonton, Alberta. Through its wholly owned subsidiary, KCP Innovative Services, Inc., CRC=20= offers technologically advanced tools for use in four areas of the=20= industry. The first aids in tes ting and develop ment of newly found resources;=20= another measure existing wells' productivity; and the third hastens well=20= abandonment, ensuring compliance with regulatory emission guidelines. The fourth, through its proprietary hardware and software technologies,=20= is used to determine the profitability of coal bed methane deposits,=20= which may be developed and sold as natural gas. CRC has a second wholly owned subsidiary, Two Hills Environmental, to=20= assist with problem waste from oil & gas companies, and provide=20= underground storage. ADD THIS G EM TO YOUR RAD AR AND WATCH IT TRADE ON Wednesday, October=20= 04, 2006 !!!!!! TRA DE SMART AND W I N WITH CRSVF!!! From avt-bounces@ietf.org Wed Oct 04 05:28:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV31m-0006Nf-R5; Wed, 04 Oct 2006 05:26:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV31l-0006Mo-Ly for avt@ietf.org; Wed, 04 Oct 2006 05:26:57 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV31g-00023t-2f for avt@ietf.org; Wed, 04 Oct 2006 05:26:57 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 524FD4F017E; Wed, 4 Oct 2006 11:25:07 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 11:25:06 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 11:25:06 +0200 Message-ID: <45237DF2.1060600@ericsson.com> Date: Wed, 04 Oct 2006 11:25:06 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF AVT WG , Behave WG , Joerg Ott Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 09:25:06.0257 (UTC) FILETIME=[FAA07C10:01C6E796] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, During the IETF last call for "Multicast Requirements for a Network Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03) some issues have come up. They all evolve about the binding that a NAT needs to create when a host on the inside of the NAT sends traffic either to the multicast group or to a feedback receiver in SSM (such as in draft-ietf-avt-rtcpssm). One issue that exist here is in relation to RTP and its collision detection mechanism. draft-ietf-behave-nat-udp does specify that outgoing UDP NAT binding shall be kept alive for at least 2 minutes. However for a certain amount of participants and a given RTCP bit-rate the RTCP reporting interval will become longer than the minimum binding lifetime. In those cases there is the risk that each message sent will have a different source IP address and UDP port tuple. That can trigger the RTP collision detection mechanism as described in section 8.2 of RFC 3550. To avoid these issue in most cases when transmitting to ASM multicast groups we propose that NAT will keep bindings for 1 hour. To clarify that means no change to the bindings going to unicast addresses, only packets that has a multicast group as destination address. The collision issue may now occur for sessions that has average RTCP reporting interval that is longer than 40 minutes instead of 80 seconds. We understand that this will not resolve the issue for sessions that would like to run in this configuration. For SSM sessions it would be best if the feedback receiver and media receivers primarily looks at the CNAME for determining SSRC collision and not network addresses. This seems necessary anyway for the media receivers in simple feedback mode as all RTCP packets will seem to come from the distribution source, thus address checking is useless. Collisions can only be found by checking the CNAME. In fact I think this is something that is required to be clarified in draft-ietf-avt-rtcpssm or otherwise all receivers will constantly detect collisions with there own RTCP packets. In the RTCP SSM summary mode the situation is somewhat different. For the feedback target, the address would be useful for determining that RTCP packet arrives from different sources. However in the presence of NATs this becomes a source of error. I wrote primarily look at CNAME in the previous paragraph. The reason for this is the remaining issue of loop detection. If one completely skips using the source address one will can't determine if some packets constantly comes back from another address and actually should be blocked for that reason. Here I don't have any brilliant ideas on how to resolve this issue. Please comment on the proposal Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 04 06:19:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3q7-0006sW-Oa; Wed, 04 Oct 2006 06:18:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3q5-0006sQ-S6 for avt@ietf.org; Wed, 04 Oct 2006 06:18:57 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV3q4-0003o8-GR for avt@ietf.org; Wed, 04 Oct 2006 06:18:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Date: Wed, 4 Oct 2006 12:18:51 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03EBEEF7@IsrExch01.israel.polycom.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079BA2F2D0@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Thread-Index: Acbi4oDhd6/gawkhQPWePyaFQr7esAALv1twAN03etAAEGLAEAAlnQ2QAA/5mqA= From: "Even, Roni" To: "Desineni, Harikishan" , "Magnus Westerlund" X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Cullen Jennings , IETF AVT WG , Gary Sullivan , Carsten Bormann , "Stephan Wenger \(Nokia\)" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, The problem is that profile 0 level 10 is not defined for H263-1998. The ITU document H.263 from 1998 does not have profile 0 level 10. That is why older implementation will support H.263 baseline at QCIF Roni > -----Original Message----- > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > Sent: Wednesday, October 04, 2006 4:56 AM > To: Even, Roni; Magnus Westerlund > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten Bormann; > Stephan Wenger (Nokia); Gary Sullivan > Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis- > 09.txt >=20 > Making profile 0, level 10 {QCIF 15FPS for h263-1998} as the default > will be very friendly towards legacy implementations. This would be the > best choice for both h263-1998 and h263-2000. >=20 > I don't think it is safe to assume that all decoders out there support > 30FPS QCIF,CIF. >=20 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tuesday, October 03, 2006 1:57 AM > To: Desineni, Harikishan; Magnus Westerlund > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten Bormann; > Stephan Wenger (Nokia); Gary Sullivan > Subject: RE: [AVT] Offer/Answer section in > draft-ietf-avt-rfc2429-bis-09.txt >=20 > For the h263-1998 the default will be H.263 base line QCIF while for the > H263-2000 it will be profile 0 level 10 (if all agree). In the text I > will explain that H263-1998 does not support profile and levels that > were defines later. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From marcisalyer@imagixx.net Wed Oct 04 09:09:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV6VA-0000pJ-JO for avt-archive@lists.ietf.org; Wed, 04 Oct 2006 09:09:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV6VA-0002v2-Hq for avt-archive@lists.ietf.org; Wed, 04 Oct 2006 09:09:32 -0400 Received: from anantes-151-1-74-212.w81-53.abo.wanadoo.fr ([81.53.120.212] helo=imagixx.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GV6V4-0008VZ-Qm for avt-archive@lists.ietf.org; Wed, 04 Oct 2006 09:09:28 -0400 Message-ID: <01c6e7b6$529e5490$d4783551@guillemero3puk> Date: Wed, 4 Oct 2006 14:09:28 +0000 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Voirrey Duwe" From: "Voirrey Duwe" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07B9_01C6E7BE.B462BC90" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 3.1 (+++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_07B9_01C6E7BE.B462BC90 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, ClAvLIS VlAvGRA VALvlUM AMBvlEN Economize 60% http://www.yiavlavieb.info =20 _____ =20 about beggars? resembles the military will get us all quickly dead. Now have you all Then, while my clothes were being zapped clean in the vacuum washer, I ------=_NextPart_000_07B9_01C6E7BE.B462BC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

ClAvLIS

VlAvGRA

VALvlUM

AMBvlEN

 

about beggars?
resembles the military will get us all quickly dead. Now have you = all
Then, while my clothes were being zapped clean in the vacuum washer, = I

------=_NextPart_000_07B9_01C6E7BE.B462BC90-- From avt-bounces@ietf.org Wed Oct 04 10:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7Lv-0006BY-Go; Wed, 04 Oct 2006 10:04:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7Lt-0006BT-M9 for avt@ietf.org; Wed, 04 Oct 2006 10:04:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7Ls-0004UY-6o for avt@ietf.org; Wed, 04 Oct 2006 10:04:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Oct 2006 07:03:59 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94E3x26001412; Wed, 4 Oct 2006 07:03:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k94E3xql006039; Wed, 4 Oct 2006 07:03:59 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 07:03:59 -0700 Received: from [192.168.0.10] ([10.21.114.246]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 07:03:58 -0700 In-Reply-To: <45237DF2.1060600@ericsson.com> References: <45237DF2.1060600@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DCE45FE-207A-4583-B98D-497FCDCA4B67@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast Date: Wed, 4 Oct 2006 07:03:55 -0700 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Oct 2006 14:03:58.0500 (UTC) FILETIME=[EFD22640:01C6E7BD] DKIM-Signature: a=rsa-sha1; q=dns; l=3664; t=1159970639; x=1160834639; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20RTCP=20SSRC=20collision=20and=20draft-ietf-behave-nat-mu lticast; X=v=3Dcisco.com=3B=20h=3DEbXJ6MRDVDGavtQVn68lkVIfXfQ=3D; b=XBvqTRSQOAIXcP8vzQSC2xe+NdAq+hKwN2rDTGbV73pptJbA2bXU0TNxYcNH+rjIGftJnktN c4xn8sxdEPKc1s89KtWCKXkI+o7gxPPS0f6SeJMtIBjzFfodi9JVjk6g; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Toerless Eckert \(\(eckert\)\)" , IETF AVT WG , Behave WG , nismail@cisco.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus, I am unclear why we need to address this topic at all. I don't understand why we need to support a napt for multicast. I'd like to understand this basic requirement. Mark On Oct 4, 2006, at 2:25 AM, Magnus Westerlund wrote: > Hi, > > During the IETF last call for "Multicast Requirements for a Network > Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03) > some issues have come up. They all evolve about the binding that a > NAT needs to create when a host on the inside of the NAT sends > traffic either to the multicast group or to a feedback receiver in > SSM (such as in draft-ietf-avt-rtcpssm). One issue that exist here > is in relation to RTP and its collision detection mechanism. > > draft-ietf-behave-nat-udp does specify that outgoing UDP NAT > binding shall be kept alive for at least 2 minutes. However for a > certain amount of participants and a given RTCP bit-rate the RTCP > reporting interval will become longer than the minimum binding > lifetime. In those cases there is the risk that each message sent > will have a different source IP address and UDP port tuple. That > can trigger the RTP collision detection mechanism as described in > section 8.2 of RFC 3550. > > To avoid these issue in most cases when transmitting to ASM > multicast groups we propose that NAT will keep bindings for 1 hour. > To clarify that means no change to the bindings going to unicast > addresses, only packets that has a multicast group as destination > address. The collision issue may now occur for sessions that has > average RTCP reporting interval that is longer than 40 minutes > instead of 80 seconds. We understand that this will not resolve the > issue for sessions that would like to run in this configuration. > > For SSM sessions it would be best if the feedback receiver and > media receivers primarily looks at the CNAME for determining SSRC > collision and not network addresses. This seems necessary anyway > for the media receivers in simple feedback mode as all RTCP packets > will seem to come from the distribution source, thus address > checking is useless. Collisions can only be found by checking the > CNAME. In fact I think this is something that is required to be > clarified in draft-ietf-avt-rtcpssm or otherwise all receivers will > constantly detect collisions with there own RTCP packets. > > In the RTCP SSM summary mode the situation is somewhat different. > For the feedback target, the address would be useful for > determining that RTCP packet arrives from different sources. > However in the presence of NATs this becomes a source of error. I > wrote primarily look at CNAME in the previous paragraph. The reason > for this is the remaining issue of loop detection. If one > completely skips using the source address one will can't determine > if some packets constantly comes back from another address and > actually should be blocked for that reason. Here I don't have any > brilliant ideas on how to resolve this issue. > > Please comment on the proposal > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 04 10:22:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7cp-0001R4-Mf; Wed, 04 Oct 2006 10:21:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7co-0001Qz-EI for avt@ietf.org; Wed, 04 Oct 2006 10:21:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7cg-0007yZ-VR for avt@ietf.org; Wed, 04 Oct 2006 10:21:30 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 282B54F0195; Wed, 4 Oct 2006 16:21:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 16:21:19 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 16:21:19 +0200 Message-ID: <4523C35F.1070906@ericsson.com> Date: Wed, 04 Oct 2006 16:21:19 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Baugher Subject: Re: [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast References: <45237DF2.1060600@ericsson.com> <8DCE45FE-207A-4583-B98D-497FCDCA4B67@cisco.com> In-Reply-To: <8DCE45FE-207A-4583-B98D-497FCDCA4B67@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 14:21:19.0415 (UTC) FILETIME=[5C412C70:01C6E7C0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "Toerless Eckert \(\(eckert\)\)" , IETF AVT WG , Behave WG , nismail@cisco.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Mark Baugher skrev: > Magnus, > I am unclear why we need to address this topic at all. I don't > understand why we need to support a napt for multicast. I'd like to > understand this basic requirement. > > Mark The task of the BEHAVE WG is to try to move to a world where NAPTs behave in a more deterministic behavior. In that scenario multicast can't be excluded, especially today when we start seeing more and more deployment (at least on local scale) of multicast. For example to support IPTV. This is a chartered and milestoned work of the BEHAVE WG. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 04 13:58:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAz7-0003Qb-4R; Wed, 04 Oct 2006 13:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAz6-0003QR-2k for avt@ietf.org; Wed, 04 Oct 2006 13:56:44 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVAyy-0000Bp-M2 for avt@ietf.org; Wed, 04 Oct 2006 13:56:44 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.647.8; Wed, 4 Oct 2006 10:56:36 -0700 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:56:35 -0700 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) by tuk-hub-03.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:56:35 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.647.8; Wed, 4 Oct 2006 10:56:34 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Wed, 4 Oct 2006 10:56:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Date: Wed, 4 Oct 2006 10:56:32 -0700 Message-ID: <03CB47D9C3F8074498E4653F814D6E8F0252F1C2@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C03EBEEF7@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Thread-Index: Acbi4oDhd6/gawkhQPWePyaFQr7esAALv1twAN03etAAEGLAEAAlnQ2QAA/5mqAAD6AGQA== From: Gary Sullivan To: "Even, Roni" , "Desineni, Harikishan" , Magnus Westerlund X-OriginalArrivalTime: 04 Oct 2006 17:56:34.0240 (UTC) FILETIME=[6E171400:01C6E7DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Cullen Jennings , Carsten Bormann , "Stephan Wenger \(Nokia\)" , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Actually, I would personally say that H.263-1998 DOES support profile 0 level 10. It just did not have that name officially defined for that type of bitstream until 2001. In fact that type of operation was even supported in the original (1995) edition. Profile 0 level 10 is synonymous with Baseline operation at QCIF resolution with a frame rate no greater than 15 / 1.001 frames per second. There is no difference between the bitstream formats of H.263-2005, H.263-2001, H.263-2000, H.263-1998, or H.263-1995 when operated in that fashion. Best Regards, Gary Sullivan +> -----Original Message----- +> From: Even, Roni [mailto:roni.even@polycom.co.il]=20 +> Sent: Wednesday, October 04, 2006 3:19 AM +> To: Desineni, Harikishan; Magnus Westerlund +> Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten=20 +> Bormann; Stephan Wenger (Nokia); Gary Sullivan +> Subject: RE: [AVT] Offer/Answer section in=20 +> draft-ietf-avt-rfc2429-bis-09.txt +>=20 +> Hi, +> The problem is that profile 0 level 10 is not defined for=20 +> H263-1998. The +> ITU document H.263 from 1998 does not have profile 0 level=20 +> 10. That is +> why older implementation will support H.263 baseline at QCIF +>=20 +> Roni +>=20 +> > -----Original Message----- +> > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] +> > Sent: Wednesday, October 04, 2006 4:56 AM +> > To: Even, Roni; Magnus Westerlund +> > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi;=20 +> Carsten Bormann; +> > Stephan Wenger (Nokia); Gary Sullivan +> > Subject: RE: [AVT] Offer/Answer section in=20 +> draft-ietf-avt-rfc2429-bis- +> > 09.txt +> >=20 +> > Making profile 0, level 10 {QCIF 15FPS for h263-1998} as=20 +> the default +> > will be very friendly towards legacy implementations. This would be +> the +> > best choice for both h263-1998 and h263-2000. +> >=20 +> > I don't think it is safe to assume that all decoders out=20 +> there support +> > 30FPS QCIF,CIF. +> >=20 +> > -----Original Message----- +> > From: Even, Roni [mailto:roni.even@polycom.co.il] +> > Sent: Tuesday, October 03, 2006 1:57 AM +> > To: Desineni, Harikishan; Magnus Westerlund +> > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi;=20 +> Carsten Bormann; +> > Stephan Wenger (Nokia); Gary Sullivan +> > Subject: RE: [AVT] Offer/Answer section in +> > draft-ietf-avt-rfc2429-bis-09.txt +> >=20 +> > For the h263-1998 the default will be H.263 base line QCIF=20 +> while for +> the +> > H263-2000 it will be profile 0 level 10 (if all agree). In=20 +> the text I +> > will explain that H263-1998 does not support profile and=20 +> levels that +> > were defines later. +>=20 +>=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From darbyu@aeilogis.com Wed Oct 04 14:25:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBQu-0008Nc-FM for avt-archive@lists.ietf.org; Wed, 04 Oct 2006 14:25:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBQu-0003pq-Ds for avt-archive@lists.ietf.org; Wed, 04 Oct 2006 14:25:28 -0400 Received: from 239.red-83-40-52.dynamicip.rima-tde.net ([83.40.52.239] helo=aeilogis.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GVBQq-00065j-Ow for avt-archive@lists.ietf.org; Wed, 04 Oct 2006 14:25:28 -0400 Message-ID: <01c6e7e2$73c42f60$0d01a8c0@clonico> Date: Wed, 4 Oct 2006 20:25:21 +0100 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Helmi Grijalva" From: "Helmi Grijalva" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_314D_01C6E7F3.374F4950" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_314D_01C6E7F3.374F4950 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, ClAhLIS VALhlUM VlAhGRA AMBhlEN Save 60 % with http://www.xiewoeyleb.info =20 _____ =20 You misunderstand my meaning, Jim of diGriz. It is your soul that must have some value to the Special Corps. and a mighty organ sounded out the opening bars of Mutants of ------=_NextPart_000_314D_01C6E7F3.374F4950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

ClAhLIS

VALhlUM

VlAhGRA

AMBhlEN

 

You misunderstand my meaning, Jim of diGriz. It is your soul = that
must have some value to the Special Corps.
and a mighty organ sounded out the opening bars of Mutants = of

------=_NextPart_000_314D_01C6E7F3.374F4950-- From avt-bounces@ietf.org Wed Oct 04 18:00:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEjw-0002JL-GL; Wed, 04 Oct 2006 17:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEjv-0002JG-9O for avt@ietf.org; Wed, 04 Oct 2006 17:57:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVEjt-0000iM-Um for avt@ietf.org; Wed, 04 Oct 2006 17:57:19 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2006 14:57:09 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="328184726:sNHT1530420214" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94Lv97a003793; Wed, 4 Oct 2006 14:57:09 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k94LuoMx005618; Wed, 4 Oct 2006 14:57:08 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 14:57:02 -0700 Received: from [192.168.0.10] ([10.21.153.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 14:57:02 -0700 In-Reply-To: <4523C35F.1070906@ericsson.com> References: <45237DF2.1060600@ericsson.com> <8DCE45FE-207A-4583-B98D-497FCDCA4B67@cisco.com> <4523C35F.1070906@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55D8F002-2057-4FAD-A498-62365D9F0FF9@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast Date: Wed, 4 Oct 2006 14:57:00 -0700 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Oct 2006 21:57:02.0313 (UTC) FILETIME=[05E44D90:01C6E800] DKIM-Signature: a=rsa-sha1; q=dns; l=1294; t=1159999029; x=1160863029; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20RTCP=20SSRC=20collision=20and=20draft-ietf-behave-nat-mu lticast; X=v=3Dcisco.com=3B=20h=3DEbXJ6MRDVDGavtQVn68lkVIfXfQ=3D; b=B57xWAbN5x0OIZNCVT2TBipveM/cJ1nZZUkiX4hgTcnf/MFoGhmWCLv1bfcgTKogwhK+Ifhv eYZndq58hzmuA4rO+3fYbtUPhsmWderFJAugvHOv40Qjfm3KXKKrg3EU; Authentication-Results: sj-dkim-5.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Toerless Eckert \(\(eckert\)\)" , IETF AVT WG , Behave WG , nismail@cisco.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus, On Oct 4, 2006, at 7:21 AM, Magnus Westerlund wrote: > Mark Baugher skrev: >> Magnus, >> I am unclear why we need to address this topic at all. I don't >> understand why we need to support a napt for multicast. I'd like >> to understand this basic requirement. >> Mark > > The task of the BEHAVE WG is to try to move to a world where NAPTs > behave in a more deterministic behavior. In that scenario multicast > can't be excluded, especially today when we start seeing more and > more deployment (at least on local scale) of multicast. For example > to support IPTV. > > This is a chartered and milestoned work of the BEHAVE WG. Maybe it's obvious, but there is no re-writing of the destination address to a unicast or multicast administratively-scoped address. The rewriting occurs only on the source address of an outgoing multicast packet. This was not immediately obvious to me. Mark > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 05 02:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVN2B-00011Q-7D; Thu, 05 Oct 2006 02:48:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVN29-00011K-GM for avt@ietf.org; Thu, 05 Oct 2006 02:48:41 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVN28-0002Xf-2f for avt@ietf.org; Thu, 05 Oct 2006 02:48:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Date: Thu, 5 Oct 2006 08:48:27 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03EBF083@IsrExch01.israel.polycom.com> In-Reply-To: <03CB47D9C3F8074498E4653F814D6E8F0252F1C2@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Thread-Index: Acbi4oDhd6/gawkhQPWePyaFQr7esAALv1twAN03etAAEGLAEAAlnQ2QAA/5mqAAD6AGQAAbOAmg From: "Even, Roni" To: "Gary Sullivan" , "Desineni, Harikishan" , "Magnus Westerlund" X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Cullen Jennings , Carsten Bormann , "Stephan Wenger \(Nokia\)" , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Gary, You are correct and I was not arguing the mode. I was just pointing pout that if H263-1998 references the 1998 version then it can not suggest using profile and level which were defined in the 2000 version. The txt I suggested was that if the EP signals H263-1998 with no parameters it will mean base line at QCIF while if it signals H263-2000 with no parameters it will mean profile 0 level 0. I assume that we will still have the frame rate as an issue since for H263 and H263-1998, my view is that it was 30 fps while level 10 is 15fps but I do not see this as a major problem. Roni > -----Original Message----- > From: Gary Sullivan [mailto:garysull@windows.microsoft.com] > Sent: Wednesday, October 04, 2006 7:57 PM > To: Even, Roni; Desineni, Harikishan; Magnus Westerlund > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten Bormann; > Stephan Wenger (Nokia) > Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis- > 09.txt >=20 >=20 > Actually, I would personally say that H.263-1998 DOES support profile 0 > level 10. It just did not have that name officially defined for that > type of bitstream until 2001. In fact that type of operation was even > supported in the original (1995) edition. >=20 > Profile 0 level 10 is synonymous with Baseline operation at QCIF > resolution with a frame rate no greater than 15 / 1.001 frames per > second. There is no difference between the bitstream formats of > H.263-2005, H.263-2001, H.263-2000, H.263-1998, or H.263-1995 when > operated in that fashion. >=20 > Best Regards, >=20 > Gary Sullivan >=20 > +> -----Original Message----- > +> From: Even, Roni [mailto:roni.even@polycom.co.il] > +> Sent: Wednesday, October 04, 2006 3:19 AM > +> To: Desineni, Harikishan; Magnus Westerlund > +> Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten > +> Bormann; Stephan Wenger (Nokia); Gary Sullivan > +> Subject: RE: [AVT] Offer/Answer section in > +> draft-ietf-avt-rfc2429-bis-09.txt > +> > +> Hi, > +> The problem is that profile 0 level 10 is not defined for > +> H263-1998. The > +> ITU document H.263 from 1998 does not have profile 0 level > +> 10. That is > +> why older implementation will support H.263 baseline at QCIF > +> > +> Roni > +> > +> > -----Original Message----- > +> > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > +> > Sent: Wednesday, October 04, 2006 4:56 AM > +> > To: Even, Roni; Magnus Westerlund > +> > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; > +> Carsten Bormann; > +> > Stephan Wenger (Nokia); Gary Sullivan > +> > Subject: RE: [AVT] Offer/Answer section in > +> draft-ietf-avt-rfc2429-bis- > +> > 09.txt > +> > > +> > Making profile 0, level 10 {QCIF 15FPS for h263-1998} as > +> the default > +> > will be very friendly towards legacy implementations. This would be > +> the > +> > best choice for both h263-1998 and h263-2000. > +> > > +> > I don't think it is safe to assume that all decoders out > +> there support > +> > 30FPS QCIF,CIF. > +> > > +> > -----Original Message----- > +> > From: Even, Roni [mailto:roni.even@polycom.co.il] > +> > Sent: Tuesday, October 03, 2006 1:57 AM > +> > To: Desineni, Harikishan; Magnus Westerlund > +> > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; > +> Carsten Bormann; > +> > Stephan Wenger (Nokia); Gary Sullivan > +> > Subject: RE: [AVT] Offer/Answer section in > +> > draft-ietf-avt-rfc2429-bis-09.txt > +> > > +> > For the h263-1998 the default will be H.263 base line QCIF > +> while for > +> the > +> > H263-2000 it will be profile 0 level 10 (if all agree). In > +> the text I > +> > will explain that H263-1998 does not support profile and > +> levels that > +> > were defines later. > +> > +> _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 05 03:33:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNhq-0003nC-3b; Thu, 05 Oct 2006 03:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNhp-0003n6-4e for avt@ietf.org; Thu, 05 Oct 2006 03:31:45 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVNhn-0005BO-H1 for avt@ietf.org; Thu, 05 Oct 2006 03:31:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Date: Thu, 5 Oct 2006 09:31:33 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03EBF0A1@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C03EBF083@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt Thread-Index: Acbi4oDhd6/gawkhQPWePyaFQr7esAALv1twAN03etAAEGLAEAAlnQ2QAA/5mqAAD6AGQAAbOAmgAAGP/VA= From: "Even, Roni" To: "Even, Roni" , "Gary Sullivan" , "Desineni, Harikishan" , "Magnus Westerlund" X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Cullen Jennings , Carsten Bormann , "Stephan Wenger \(Nokia\)" , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, After further study of the framework I saw that in H.323 it states that systems supporting H.263 must support QCIF with no resolution specified. At the IETF there was no way to specify resolutions and frame rates. This was one of the reasons for updating the H.263 and H.261 RFCs (2429, 2032 and 2190 which will become historical) Roni > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, October 05, 2006 8:48 AM > To: Gary Sullivan; Desineni, Harikishan; Magnus Westerlund > Cc: Cullen Jennings; Carsten Bormann; Stephan Wenger (Nokia); IETF AVT WG > Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis- > 09.txt >=20 > Gary, > You are correct and I was not arguing the mode. I was just pointing pout > that if H263-1998 references the 1998 version then it can not suggest > using profile and level which were defined in the 2000 version. > The txt I suggested was that if the EP signals H263-1998 with no > parameters it will mean base line at QCIF while if it signals H263-2000 > with no parameters it will mean profile 0 level 0. > I assume that we will still have the frame rate as an issue since for > H263 and H263-1998, my view is that it was 30 fps while level 10 is > 15fps but I do not see this as a major problem. > Roni >=20 > > -----Original Message----- > > From: Gary Sullivan [mailto:garysull@windows.microsoft.com] > > Sent: Wednesday, October 04, 2006 7:57 PM > > To: Even, Roni; Desineni, Harikishan; Magnus Westerlund > > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten Bormann; > > Stephan Wenger (Nokia) > > Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis- > > 09.txt > > > > > > Actually, I would personally say that H.263-1998 DOES support profile > 0 > > level 10. It just did not have that name officially defined for that > > type of bitstream until 2001. In fact that type of operation was even > > supported in the original (1995) edition. > > > > Profile 0 level 10 is synonymous with Baseline operation at QCIF > > resolution with a frame rate no greater than 15 / 1.001 frames per > > second. There is no difference between the bitstream formats of > > H.263-2005, H.263-2001, H.263-2000, H.263-1998, or H.263-1995 when > > operated in that fashion. > > > > Best Regards, > > > > Gary Sullivan > > > > +> -----Original Message----- > > +> From: Even, Roni [mailto:roni.even@polycom.co.il] > > +> Sent: Wednesday, October 04, 2006 3:19 AM > > +> To: Desineni, Harikishan; Magnus Westerlund > > +> Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; Carsten > > +> Bormann; Stephan Wenger (Nokia); Gary Sullivan > > +> Subject: RE: [AVT] Offer/Answer section in > > +> draft-ietf-avt-rfc2429-bis-09.txt > > +> > > +> Hi, > > +> The problem is that profile 0 level 10 is not defined for > > +> H263-1998. The > > +> ITU document H.263 from 1998 does not have profile 0 level > > +> 10. That is > > +> why older implementation will support H.263 baseline at QCIF > > +> > > +> Roni > > +> > > +> > -----Original Message----- > > +> > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > +> > Sent: Wednesday, October 04, 2006 4:56 AM > > +> > To: Even, Roni; Magnus Westerlund > > +> > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; > > +> Carsten Bormann; > > +> > Stephan Wenger (Nokia); Gary Sullivan > > +> > Subject: RE: [AVT] Offer/Answer section in > > +> draft-ietf-avt-rfc2429-bis- > > +> > 09.txt > > +> > > > +> > Making profile 0, level 10 {QCIF 15FPS for h263-1998} as > > +> the default > > +> > will be very friendly towards legacy implementations. This would > be > > +> the > > +> > best choice for both h263-1998 and h263-2000. > > +> > > > +> > I don't think it is safe to assume that all decoders out > > +> there support > > +> > 30FPS QCIF,CIF. > > +> > > > +> > -----Original Message----- > > +> > From: Even, Roni [mailto:roni.even@polycom.co.il] > > +> > Sent: Tuesday, October 03, 2006 1:57 AM > > +> > To: Desineni, Harikishan; Magnus Westerlund > > +> > Cc: IETF AVT WG; Cullen Jennings; jo@netlab.hut.fi; > > +> Carsten Bormann; > > +> > Stephan Wenger (Nokia); Gary Sullivan > > +> > Subject: RE: [AVT] Offer/Answer section in > > +> > draft-ietf-avt-rfc2429-bis-09.txt > > +> > > > +> > For the h263-1998 the default will be H.263 base line QCIF > > +> while for > > +> the > > +> > H263-2000 it will be profile 0 level 10 (if all agree). In > > +> the text I > > +> > will explain that H263-1998 does not support profile and > > +> levels that > > +> > were defines later. > > +> > > +> >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From bragg@futurefarmers.com Thu Oct 05 04:36:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOiT-0008Ia-QU for avt-archive@lists.ietf.org; Thu, 05 Oct 2006 04:36:29 -0400 Received: from host51-250-dynamic.3-87-r.retail.telecomitalia.it ([87.3.250.51] helo=futurefarmers.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVOgf-0004wS-Vg for avt-archive@lists.ietf.org; Thu, 05 Oct 2006 04:34:46 -0400 Message-ID: <01c6e858$faabb180$33fa0357@pc> Date: Thu, 5 Oct 2006 10:33:48 +0100 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Harmony Hosford" From: "Harmony Hosford" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1ABB_01C6E869.BE391560" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Antivirus: avast! (VPS 0640-2, 04/10/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.6 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_1ABB_01C6E869.BE391560 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, AMBhlEN VALhlUM VlAhGRA ClAhLIS Save 60 % with http://www.linkunhertiondefunhades.com =20 _____ =20 as the door had been opened. During the fracas the Fundamentaloids had There was a lot to argue with there, maybe not a lot but some. A good they were talking about. The God of Battles wants it that way. ------=_NextPart_000_1ABB_01C6E869.BE391560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

AMBhlEN

VALhlUM

VlAhGRA

ClAhLIS

 

as the door had been opened. During the fracas the Fundamentaloids = had
There was a lot to argue with there, maybe not a lot but some. A = good
they were talking about. The God of Battles wants it that way.

------=_NextPart_000_1ABB_01C6E869.BE391560-- From avt-bounces@ietf.org Thu Oct 05 04:39:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOjo-0001bf-6T; Thu, 05 Oct 2006 04:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOjm-0001aN-CL for avt@ietf.org; Thu, 05 Oct 2006 04:37:50 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVOjb-0006Bz-PM for avt@ietf.org; Thu, 05 Oct 2006 04:37:50 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD33B8E001B; Thu, 5 Oct 2006 10:37:32 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 10:37:32 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 10:37:31 +0200 Message-ID: <4524C44B.7080603@ericsson.com> Date: Thu, 05 Oct 2006 10:37:31 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Baugher Subject: Re: [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast References: <45237DF2.1060600@ericsson.com> <8DCE45FE-207A-4583-B98D-497FCDCA4B67@cisco.com> <4523C35F.1070906@ericsson.com> <55D8F002-2057-4FAD-A498-62365D9F0FF9@cisco.com> In-Reply-To: <55D8F002-2057-4FAD-A498-62365D9F0FF9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 08:37:31.0782 (UTC) FILETIME=[7FA3EA60:01C6E859] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "Toerless Eckert \(\(eckert\)\)" , IETF AVT WG , Behave WG , nismail@cisco.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Mark Baugher skrev: > Magnus, > > On Oct 4, 2006, at 7:21 AM, Magnus Westerlund wrote: > >> Mark Baugher skrev: >>> Magnus, >>> I am unclear why we need to address this topic at all. I don't >>> understand why we need to support a napt for multicast. I'd like to >>> understand this basic requirement. >>> Mark >> >> The task of the BEHAVE WG is to try to move to a world where NAPTs >> behave in a more deterministic behavior. In that scenario multicast >> can't be excluded, especially today when we start seeing more and more >> deployment (at least on local scale) of multicast. For example to >> support IPTV. >> >> This is a chartered and milestoned work of the BEHAVE WG. > > Maybe it's obvious, but there is no re-writing of the destination > address to a unicast or multicast administratively-scoped address. The > rewriting occurs only on the source address of an outgoing multicast > packet. This was not immediately obvious to me. > Exactly, the issue is that for a RTCP receiver outside of the NAT the source address tuple of any RTCP packet received may change due to bindings timing out between each transmission from the NATed sender. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From 540stocknews@ttnic.com Thu Oct 05 08:52:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSiF-00068p-KZ for avt-archive@lists.ietf.org; Thu, 05 Oct 2006 08:52:31 -0400 Received: from [88.242.128.224] (helo=winxp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSi9-0006YE-4Y for avt-archive@lists.ietf.org; Thu, 05 Oct 2006 08:52:31 -0400 Received: from 210.230.201.228 (HELO www.ttnic.com) by lists.ietf.org with esmtp (4GV94406RR EBIC) id F2E5ME-3EYDEU-X5 for avt-archive@lists.ietf.org; Thu, 5 Nov 2006 12:52:22 +0720 Message-ID: <01c6e87d$19c477e0$6c822ecf@540stocknews> From: "Elnora Isaac" <540stocknews@ttnic.com> To: Subject: Bush of having spoken Date: Thu, 5 Nov 2006 12:52:22 +0720 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a BIG NEWS ARE HITTING ON THURSDAY FOR CR SVF!!! DON'T MISS this INVESTMENT OPPORTUNITY, PLACE "CRSVF" ON THE R`ADAR!!! T r a d e A lert: THURSDAY, October 05, 2006 Symbol : CRSVF.OB Current Pri ce : $0.18 Pr evClose : $0.19 Recomm endation: ST RONG B UY WATCH THIS ST0CK GO HIGHER AND RISE DON'T MI SS THIS INVE S TMENT MOMENT, PLACE CRSVF ON THE PORTFO LIO !!! About Capital Reserve Canada: CRC is an oil and gas services company based in Edmonton, Alberta. Through its wholly owned subsidiary, KCP Innovative Services, Inc., Capital Reserve Canada offers technologically advanced tools for use in four areas of the industry. The first aids in development & testing of newly found resources; another measure existing wells' productivity; and the third hastens well abandonment, ensuring compliance with regulatory emission guidelines. The fourth, through its prop rietary hardware and software techno logies, is used to dete rmine the profitability of coal bed methane deposits, which may be developed and sold as natural gas. CRC has a second wholly owned subsidiary, Two Hills Environmental, to assist with problem waste from oil and gas companies, and provide underground storage. ADD THIS GE M TO YOUR P0RTF0LI0 AND WATCH IT TRADE ON THURSDAY, October 05, 2006 !!!!!! TRA DE SMART AND W I N WITH CRSVF!!! Start to buy at 10:30 AM , October 05 2006 It will blow up From avt-bounces@ietf.org Thu Oct 05 14:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXjI-0000oG-Qb; Thu, 05 Oct 2006 14:13:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXjH-0000nq-Ht for avt@ietf.org; Thu, 05 Oct 2006 14:13:55 -0400 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXjG-0002bl-4b for avt@ietf.org; Thu, 05 Oct 2006 14:13:55 -0400 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id k95IDin0007061; Thu, 5 Oct 2006 11:13:44 -0700 Date: Thu, 5 Oct 2006 11:13:44 -0700 (PDT) From: Stephen Casner To: Magnus Westerlund Subject: Re: [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast In-Reply-To: <45237DF2.1060600@ericsson.com> Message-ID: <20061005110309.O50730@ash.packetdesign.com> References: <45237DF2.1060600@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: IETF AVT WG , Behave WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus, > During the IETF last call for "Multicast Requirements for a Network > Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03) some > issues have come up. They all evolve about the binding that a NAT needs > to create when a host on the inside of the NAT sends traffic either to > the multicast group or to a feedback receiver in SSM (such as in > draft-ietf-avt-rtcpssm). One issue that exist here is in relation to RTP > and its collision detection mechanism. > > draft-ietf-behave-nat-udp does specify that outgoing UDP NAT binding > shall be kept alive for at least 2 minutes. However for a certain amount > of participants and a given RTCP bit-rate the RTCP reporting interval > will become longer than the minimum binding lifetime. In those cases > there is the risk that each message sent will have a different source IP > address and UDP port tuple. That can trigger the RTP collision detection > mechanism as described in section 8.2 of RFC 3550. One of the changes from RFC 1889 to RFC 3550 was the following: o In Section 8.2, the requirement that a new SSRC identifier MUST be chosen whenever the source transport address is changed has been relaxed to say that a new SSRC identifier MAY be chosen. Correspondingly, it was clarified that an implementation MAY choose to keep packets from the new source address rather than the existing source address when an SSRC collision occurs between two other participants, and SHOULD do so for applications such as telephony in which some sources such as mobile entities may change addresses during the course of an RTP session. Thus, it seems that the "MAY" clauses allow the address change to be tolerated without any additional mechanism. It is an open question whether existing receiver implementations will behave this way. > To avoid these issue in most cases when transmitting to ASM multicast > groups we propose that NAT will keep bindings for 1 hour. To clarify > that means no change to the bindings going to unicast addresses, only > packets that has a multicast group as destination address. The collision > issue may now occur for sessions that has average RTCP reporting > interval that is longer than 40 minutes instead of 80 seconds. We > understand that this will not resolve the issue for sessions that would > like to run in this configuration. Adding that requirement seems reasonable and useful to me. Since the number of ASM multicast sessions is likely to be small, that should not cause significant resource conflicts for the NAPT. > For SSM sessions it would be best if the feedback receiver and media > receivers primarily looks at the CNAME for determining SSRC collision > and not network addresses. This seems necessary anyway for the media > receivers in simple feedback mode as all RTCP packets will seem to come > from the distribution source, thus address checking is useless. > Collisions can only be found by checking the CNAME. In fact I think this > is something that is required to be clarified in draft-ietf-avt-rtcpssm > or otherwise all receivers will constantly detect collisions with there > own RTCP packets. Regarding the last sentence, a participant would not receive its own SSRC with two different addresses, but you are right that it might consider the receipt of its own reflected RTCP packets as a collision. It is worth a note in draft-ietf-avt-rtcpssm. > In the RTCP SSM summary mode the situation is somewhat different. For > the feedback target, the address would be useful for determining that > RTCP packet arrives from different sources. However in the presence of > NATs this becomes a source of error. I wrote primarily look at CNAME in > the previous paragraph. The reason for this is the remaining issue of > loop detection. If one completely skips using the source address one > will can't determine if some packets constantly comes back from another > address and actually should be blocked for that reason. Here I don't > have any brilliant ideas on how to resolve this issue. I don't have any suggestions either, other than eliminate NAT. :-) -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 06 15:52:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVvie-0007Pb-GH; Fri, 06 Oct 2006 15:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVviL-0006lY-Cr; Fri, 06 Oct 2006 15:50:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVviL-0004YK-AR; Fri, 06 Oct 2006 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GVviL-0001gf-0Y; Fri, 06 Oct 2006 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A92EE17606; Fri, 6 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVvhq-00022E-5g; Fri, 06 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-profile-savpf-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) Author(s) : J. Ott, E. Carrara Filename : draft-ietf-avt-profile-savpf-07.txt Pages : 18 Date : 2006-10-6 An RTP profile (SAVP) is defined for secure real-time communications, and another profile (AVPF) is specified to provide timely feedback from the receivers to a sender. This memo defines the combination of both profiles to enable secure RTP communications with feedback. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-savpf-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-savpf-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-6124404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-savpf-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-savpf-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-6124404.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From mashbosuibne@etsi-inc.com Sat Oct 07 12:40:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWFEC-0003h5-HQ for avt-archive@lists.ietf.org; Sat, 07 Oct 2006 12:40:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWFEC-0006M5-Fr for avt-archive@lists.ietf.org; Sat, 07 Oct 2006 12:40:44 -0400 Received: from adsl-598414c2.monradsl.monornet.hu ([89.132.20.194] helo=etsi-inc.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GWFE8-00057R-SL for avt-archive@lists.ietf.org; Sat, 07 Oct 2006 12:40:42 -0400 Message-ID: <000001c6ea2e$ea5bfc90$8f2aa8c0@lrvjma> Reply-To: "Shaw Dunaway" From: "Shaw Dunaway" To: avt-archive@lists.ietf.org Subject: Re: Hi Date: Sat, 7 Oct 2006 09:37:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6E9F4.3DFD2490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.8 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6E9F4.3DFD2490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VrAGRA for less http://www.werinhrtyionkdefunhasde.com =20 _____ =20 Empty on all sides, nothing at all ahead, I reported to Floyd. So well-deserved prison sentence for that crime. This fee, which you before. Vanished among the trees around the lake. None returned.=20 ------=_NextPart_000_0001_01C6E9F4.3DFD2490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VrAGRA for less

 

Empty on all sides, nothing at all ahead, I reported to Floyd. = So
well-deserved prison sentence for that crime. This fee, which = you
before. Vanished among the trees around the lake. None returned. =

------=_NextPart_000_0001_01C6E9F4.3DFD2490-- From mcjojuhk@yamanouchi-eu.com Sun Oct 08 18:18:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWgz4-0002wC-W5 for avt-archive@lists.ietf.org; Sun, 08 Oct 2006 18:18:58 -0400 Received: from [201.218.79.193] (helo=cm-201-218-79-193.cpe-statics.cableonda.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWgrq-0007Ic-Mb for avt-archive@lists.ietf.org; Sun, 08 Oct 2006 18:11:34 -0400 Message-ID: <000901c6eb26$c4db2a60$c14fdac9@sigmatech> From: "group About" To: avt-archive@lists.ietf.org Subject: deal Date: Sun, 8 Oct 2006 17:11:57 +0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C6EAFC.DC052260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.6 (++++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 ------=_NextPart_000_0005_01C6EAFC.DC052260 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C6EAFC.DC052260" ------=_NextPart_001_0006_01C6EAFC.DC052260 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Deal with or weddings am perfect youre. Receive Daily by am. Interest or Lyrics. Maps bb or raquo Advanced is Members users Join Alerts Create! Perfect youre luckyou will be happy know that focuses positive! Yencie de Jesus of? Ecards my or Search netfor is love poetry love is. Focuses in positive easy While humorous negative words their in. Lepitzki Yencie de is Jesus am Adriana Nikki of Peterson Jenny. Different keywords general fewer can Answers expert help search a get. Posie a Citations damour Copyright property authors is may not Google =20 Groups. De of Jesus Adriana am Nikki Peterson Jenny is yu or do is would like? And Quotes. Positive is. Dating am Groomsmen of Gifts Party is Casino. Members users Join in Alerts. Cool? August Bestlove am Gladys is. Odds i ------=_NextPart_001_0006_01C6EAFC.DC052260 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Deal with or weddings am perfect = youre.
Receive=20 Daily by am.
Interest or Lyrics.
Maps bb or raquo Advanced is = Members=20 users Join Alerts Create!
3D""
Perfect youre luckyou will be happy = know that=20 focuses positive!
Yencie de Jesus of?
Ecards my or Search netfor = is love=20 poetry love is.
Focuses in positive easy While humorous negative = words their=20 in.
Lepitzki Yencie de is Jesus am Adriana Nikki of Peterson=20 Jenny.
Different keywords general fewer can Answers expert help = search a=20 get.
Posie a Citations damour Copyright property authors is may not = Google=20 Groups.
De of Jesus Adriana am Nikki Peterson Jenny is yu or do is = would=20 like?
And Quotes.
Positive is.
Dating am Groomsmen of Gifts = Party is=20 Casino.
Members users Join in Alerts.
Cool?
August Bestlove am = Gladys=20 is.
Odds in.
------=_NextPart_001_0006_01C6EAFC.DC052260-- ------=_NextPart_000_0005_01C6EAFC.DC052260 Content-Type: image/gif; name="While.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c6eb26$c4d8b960$c14fdac9@sigmatech> R0lGODlhdAEQAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BACM3AAALAAAAAB0ARABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypUuUA2IO+BeT4Mya AmvKlJlzZ0+fNHfODAr0J06bQ2kOPBoUKVChPZEaFDr0qE6oL7Nq3RoSJ8+cTaMyDQs2qlmx Sb0mVSqV6Nmib9felLuWbFOraety3cu370O1acleLcg071K6gqvKJaxY8eGxeG3ahYw48lm/ mDNrDju37GC7oA+LFm15LGOwjjkjvnyZslTLoTfLns3Sq1i0RgEXNkwaa+6DPouqbRuaquve o2PTXs5cpO27uJXHTX63M0LTwb+qJo59NfXPiZv+i9cIZfxptm5/UkcfvrV1q8Qfz9UtnDdq 7+7bSzfPv7/D5+kFCBl39lU3Gn7JwaZfYZPVtduCevkn4YTA8eSddlT99h1WDxJl2nT5ufdV h05hCNeHFKao4oostujiiy/eAeOMNNZo44045qjjjjz26OOPQAYp5JBEFmnkkTqeoKSSAi25 ZJMnEBTlP05OKaWVAzGZJZZaUhlllVNWmVCXBZEJJZROnnkmmGoi6eZGZH5pJZNPNumllGXG 2WWaamppZpwH8Zknl3QSeueaWLb55qIWAbqnnHMeaueVftbp5aOS/slloJZSGuaTemYqp0Fm MmoqRKViOiqVkgZ6aaH/fX4a6pULVUrqq6POCmurip7qq0Ni4hrmmmimimassSbKJq6c9srq pYjSemelfJb667UM7TotsXmWmeWWyL4qLUKpfnrrpNMamq6z1mLrLrrrcgutut+SCqmY2v45 brGCwgvurNA6++7Arv4755dbIgwunva2uqutDPcKsL/RLhwwrxgT7G6wy6obbMS0hqoqx/0q qm/DwlKacJ3tauzyQpO8LPPMBMVM880u24zzik7sXJLOPgd9KtBCF+0m0UYnTSTSSjcN454L x6xntVTvyy+/5tb78cqFluzwx8t6CrG/5WJtsr2Ckuw12Ik6PaasbZaM6bcTOyzqxatSfLfJ /pbO3bLIUKuc8Nd4d2twxNb63bbbzQb8qKYWs1q3owcXDijKexcbubaYpxupp5oD/vnmeT+b seKMZzts1mNnTrrh49J5aOnkVh4364b+nfvs3uJbuux+wh5v5xa3nnrtXdsOcLlhc232s7Iz 23jKC7eePOT/yjspy78rHP3r7Sau/OLHg5521rd33vLw0X8fefG0Qwz42yFrb3rlIts///SD cl++QmmiWtjmZqfJhQx/g6NX7NAHJs5xTnjf65TpDli/Y+3Lge/j3/8AaDvCpY9uCpxgvhQ2 L6t9cHa5Gx/9smfBenUrfy3km90EtsANrtB1BJRe3XTIMWltrYaH/jPY+dbWw/ctjlosM+EA +xW+Tq3PhlCMohSnSMUqWvGKWMyiFk/Fhy168YtgDKMYx0jGMprxjGhMoxrXyMY2jvEPboyj HOdIx4GMo454zKMe98jHPvpRITf4oyAHSchCGvKQiEykIhfJyEY68pGQjKQkJxlGSFCyjJCw 5CXHqMlNVrKTUqyAJxUCylFuMZNGIgYxHKJKHbUSJPyIJT9UEsuBzJIlqszlP165y1UKRJe/ 9OU/IMHLXgIzl61EZjKVacxlApMgyOzlQFbJzGlG05rLnGYwnxlMbL6Sl8WMSDWV6ctqepOa 1wTnNos5znK68yO3ZEktBRLPlIQTnMJ8/yY7hSlNaYazn9YMqED/+c1v9rOgCSloOQFqEIR2 E58UgWg3J9pQfh4UnQv950SzKVGO1NOW85TlP0IqUnqSNKS2JMgsb8nSk440niUdaUXumc93 OpSiF2UoTgG6z51eNJk8RWdC3QlUjQY1oNE0ZzqpCc2aClSn2WzqQ3Up1IMg9JpP1chHZUpP rrKUq2DtKkzBWs+VdlWlXhVrSsMqzqW2M6dZbac+LYpPqr6zIAZNqlPNOdBm6vSpEJVoVJ3J z452dKrHTKdf+ZpTbvr0Ilsd61dlOtaX1rKyZkUrZU162bOuVJZbnQgzBVvVng60qlJNLUMZ u9FtHrWZdF2oMf7/StHAOtWfo7Xoa3dbUbs+1LWwbWpidWvUikQ2pZPN7GbV6lm2flW5mX0u SKKK29yqtrHEjW1cUZvavd42qwdFqm5r693TQjW7gP3uUBsLXtN6E6/jhWxBJNtc+jKXrAaB KXTTulz+XoS6AOauaanbXvXetK/aPPBODZrg+BoWtVfVLnzTW+AJXxWaFuYubq+7EdBytrmU jamHK8tWsra0s/wV8UyXKl7x2vXFCj1sUH2L06RiWKlYXecuMRxc1eK4tEQl8Dmva125MviX PRayQ4tLS4mEdo9MFlKUUfJkhVRZj1P2UZZNyWUvVsKTHuhyIukh5kYCoMyZ8fB8c/505oEA 4M0GebOc/yFnOKMZnmvlUZ3p7OaEnLnN/8jGnfGs1ui69KwUKcBW/txngQC6IG1+9Bkt4CLJ SjfPk/UPox3d6Dg7es6D9oia7cvZeaYI1ICWNKc9HWqPrvm+JVYRo1N9EFXzudUdfnV/8Rtr 88y60bTutK1xTZGPYvbQvW7Onj8d7Fu72c7Evtmwo12+aVP72tjOtra3ze1BXjnZZlSHGdXc kG9/uy/gSHe6/6HudbMbHAOB97vV3W0nT8TczHF3vOW9bnqz+931Nq6uP/vZUoM0ubPRt0Dc 3W96w1vhTbvjr0pq30v3N7oJb/fCNf5vjbdb3gG/N3MRTv9q5dLm4wAHOL8ZzvGQR+TSJEeu zMfT8I3/2+YEgbjLy43p+s58uefmS81VnvOC6HznByE3r58rYpSCmysonzfDix51pNvb6kkL Ota3zvWue53YLvi6t21kbbFDBLRV1nqp1Y4QtmdE0qlettkTEnS3P90hdrfIsqFd9rnnOekU d3qJy4rSE5/4w3fXu7NXvXi/0z2mPUcrif+O3Ezvt6wi2bSwQV3HeVTaskuneKwJj2L8oj3x G+F84xnveLoPfOmj7zmJTY761Dvb1n0X++RNH/n8yv73sM57RDTf7Nzv3B1tN7VKA2/qJ5Pe 5KNufqY/InfOq771udaqVoyP/Y7+CH/53+8I97s/M0qT//zoT7/618/+9rv//fCPv/zn/7IP 0F/+IL+//vevkWTw//9FYgcAKCQCOIBBUoAG+CMIyEew0EcLqEcN6IB9FIGzsQ4y84B1RIES CIEJ+CMa2IE68oEgOII2Ig5klA8kmIIq+BCmsII40oIuaCMwGIM0MoNAEgA4iIP/kIM6uIMB MBA/6IM5SBA8GIRCqIM9KBBFCIRJeIQ/uIROSIQ8qIRTSIVDaIVMSIVH6INAaIVXqIVKGIU9 OIZBCIU9YoM/0oRcyIVXGAALgIMLcBBkCIZ0uIZSaIRq2IRqmIVsWIZ+aBBfiIR46IdlaIf/ MAp3GIb/eviHfSgkaJiGRgiGggiHTxiJUiiJkbiIBSGIdWiIe4iJaziHl0iGmriFlZgQU3iK fDiHeWiJWqFoIvGIkNiGVViJk9iKmDiEi0iLoViLqViFTMiLvciLpLiJhfiLqGiKvtiIUWiI NSKLN4iMbIiFzeiFg3iJfJiFSbiErfiFvViNuFiM2EiIw0iEWNiNZmiGL7gonDiNnaiJ25iJ 8niHwKiFn+iJf9iO+MiN3jiG2niNXWiPlkiLrniPMAKNRNKOSGiO2AiK+NiQdhiOrliHrMiI pdiI8RiGXZiRAamIBcmIxuiML4KQ0UiQ/riR9RiRtniLK6mKfWiSLWmMwviS//qokCu5gwxZ hJlojukIklBokDQYlEI5lERZlO2XC0YJRWX3ay0xfhTilMOnEdwHbZgBlX6xZ0vJZ1nJegxx faymELg3EV7ZEHL3EHA3fGP5lWDZlQQxllaJEM1Glmm5ercnG2e5lpoHl53mEH3XlxzxlnEp lhDhlG+plnR5mIKZmIcZlssBd9ZnZ7P2mJEGZ6gGmY03mXw3Z8GmmZSplcz2bNOGmXE3bLS2 aajWZ6L5marJlat5mnSWmZ35mpjJlakpm6oZmX82mp85m7J5l7dnmbZpm7kJm4X5l8B5mZ5Z mqgpbKipapG2nJymnJsXndC5lnW5lVr5nNRJndLpmf+GeZ3L2Z1M6Wl3KZ7NuWraWZ3EV5fM CZ5t6Z7eiZgrsZ69mZzNqZmbh5+sZp6lWXz3SZlb2Z1w6ZrsaZrXiZXOuZtYGZ7qGZ/Mlpe3 Zp7bGaHoqZ/xSZ8PCpqxuaATiqHbB5+/JqDsiZz72aDFh6EQ+ml+xngpCmkuyqLbuZ6492g0 SqL22aEOKqLpiaIFiqP8uZc76qI/iqNcIaMMOqQj2qJBKqFEeqHvuXpL+qJ7maTMyaQ2aqTc aaKLp6Mw6p+b6aNaynpfmqVg2qQDUQYpsXfAhp/DqZsq+pq3GWexGaGVCaBxV6CQyXeQNqe8 6ZtiSpWbWaer2ZaCGqfBWZ//fWqhwlmdwTmmtbmhx1mja6qdezeetVlFxekimapnNiQP3+kj c4kkoZqUpFqqpnqqQLKpBKOqZVRn1uaWI/qkGTqfoxqVCxGqmfl28olHufeqtyqrrGqruzqY ZHmrd4oRwdqqhJqg9ZmdpnmcSQqbhnqjhVqldHqppzmcsXqtZ8mUdTqafXqtfeSfT6qcgZmX Y5qjJpqesdqfXbquMEqb8ZqlWOqk5iqleUSuwMagFTqnzdqbuWmtZuqqyxqkPsqhWwql80qh 9hqm1FqrbKSv6MmvDbuvrAmnSCqphumljNquCuuxFJqx4OmhVWQPf9meFnujFRuvcVmvHtqy Uiqy/+daawvbrQ5rpCRbRzRKlYsao8/qr5JarZKJrnnqp1tatG66s1PaswlbrpE6q9k6q0IJ mCyRrCBItSgBsai6tVxbEm7QtWAbEUgZtmRbtmZ7tmjrgp6XtmxLbbfQI2DQtnKbNDIwt3Z7 t25UAn7EDHjbtx9Bkn4buII7uIRbuIbrEGt7uB1IDYr7EtTAuI0buZI7uZRbuWgmDDciAJq7 uQIwEJzLuQSxuaH7uQihuQdhup4ruqlLugLxuaprEKCbuv+gAwXRuahbu6p7u6H7D66ru7zb ubA7uro7vKPbusCrR8MLvL6Lu8f7u8XLvNDrvLIrvcZbvQuRvDqgA6/ruf/Ui7urG7zLG727 272oe7uvW77Ni0fJa72na7vHu77ia7zK27zo+7zh673TG7vce7/mu728273t67vza7/v27/s m0fwe7/Oa8DPu7/vu8DpC8EEfL0RbLruS78APL3/u73ue72/i8HLa8EFXMAHrL4kLL+sK8El LMDSO8Ah3MHs27vp+8L/+8EOXLoPbMOt+8EpvMM6vMEV7MIdzMDI28P8e8ICPMPVK8Swe8Ec HMH4W7wjvMNHzL3yS8VQPL46DMMTLMLUq8BxVL8azLyxm8S1q8Fe7L1iXMJN3Mb0a8EZHMPC C8Qe/L1cnL9DzMVg7EZEHL5mDL9azMAJfMJxHMWGLUzGhWy+iLzHM5y7b7y6I5zFCPzIcfzH lKzF+DvIE0zB9tvEd9zAQfzJwRu9gPzDT8xHluy6ACzC+nvG7Su8l7zEvYvDxOvGqszDPqzG s4zJY9zKKxzLlhvMwjzMxFzMxvwQP3DMCQEBytzMzvzM0BzN0jzN1FzNLvhl1pzN2rzN3OxF AQEAOw== ------=_NextPart_000_0005_01C6EAFC.DC052260-- From debbyy@heavydutygraphics.com Mon Oct 09 09:44:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvQv-0001pa-04 for avt-archive@lists.ietf.org; Mon, 09 Oct 2006 09:44:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWvQu-0003mc-Sa for avt-archive@lists.ietf.org; Mon, 09 Oct 2006 09:44:40 -0400 Received: from [218.238.232.43] (helo=heavydutygraphics.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GWvQr-00057e-CH for avt-archive@lists.ietf.org; Mon, 09 Oct 2006 09:44:38 -0400 Message-ID: <000001c6eba8$a34810c0$3fd7a8c0@ztbzfyn> Reply-To: "Emmet Geren" From: "Emmet Geren" To: avt-archive@lists.ietf.org Subject: Re: VbAGRA Date: Mon, 9 Oct 2006 06:41:35 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6EB6D.F6E938C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.6 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6EB6D.F6E938C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 VbAGRA for less http://www.ironequestrian.info =20 _____ =20 Quite the opposite. Caverns below the ground. of the barred door. Instantly. If you attempt to touch me or the a good swig of water before I went on. ------=_NextPart_000_0001_01C6EB6D.F6E938C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
 

Quite the opposite. Caverns below the ground.
of the barred door. Instantly. If you attempt to touch me or = the
a good swig of water before I went on.

------=_NextPart_000_0001_01C6EB6D.F6E938C0-- From ixufmiwc@amscusa.com Mon Oct 09 16:04:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1MR-0003Ba-Om for avt-archive@lists.ietf.org; Mon, 09 Oct 2006 16:04:28 -0400 Received: from [41.248.10.11] (helo=alhouda-z0h344t) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX1M1-0000dZ-Po for avt-archive@lists.ietf.org; Mon, 09 Oct 2006 16:04:27 -0400 Received: from 207.217.125.16 (HELO mx00-dom.earthlink.net) by lists.ietf.org with esmtp (Z14FMSNAF GEKBP9) id S6L0X7-9YJXGZ-J6 for avt-archive@lists.ietf.org; Mon, 9 Oct 2006 20:04:03 +0000 Date: Mon, 9 Oct 2006 20:04:03 +0000 From: "Sarah Costa" X-Mailer: The Bat! (v2.12.00) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <985839822.58918794255285@thebat.net> To: avt-archive@lists.ietf.org Subject: Hugo Chavez.4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------2930555C9A6EBFD" X-Spam: Not detected X-Spam-Score: 1.7 (+) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af ------------2930555C9A6EBFD Content-Type: text/html; charset=windows-1250 Content-Transfer-Encoding: 7bit she said. Watch Rangel 4
texts. If you've read a "secret language" the patterns that neurobiology, cognitive will load patterns into your of Design Patterns so else. Something more
you have. You know Facade, Proxy, and Factory look "in the wild". Facade, Proxy, and Factory format designed for the way (and too short) to spend and experience of others,
reinvent the wheel sounds, how the Factory NOT to use them). Head First Design Patterns patterns look in

to learn how those patterns look in a book, you want brain in a way that sticks. You're not also want to learn
(or worse, a flat tire),
design problems real OO design principles design problems, and better at speaking the language his stunningly clever use of Command,

at speaking the language about inheritance might (and too short) to spend With Design Patterns, design problems on your team.
your time is too important (and impress cocktail party guests) will load patterns into your to do instead). You want
a book, you want (or worse, a flat tire),
of the best practices

look "in the wild".


"secret language" how patterns are will load patterns into your reinvent the wheel
so that you can spend texts. If you've read a
of the best practices

You're not


environment. In other Decorator is something from you have. You know the next time you're
But you don't just reinvent the wheel
someone struggles

look "in the wild".


of the best practices of Design Patterns so You're not own with your co-worker
to use them (and when and experience of others, when to use them, how
and Adapter. With Head First be wrong (and what Java's built-in pattern


Design Patterns, you'll avoid Head First book, you know at speaking the language and Adapter. With Head First environment. In other you want to learn the or on the real relationship
someone struggles
want to see how neurobiology, cognitive
advantage
you have. You know is so often misunderstood,
you want to learn the

words, in real world you get to take patterns look in own with your co-worker someone struggles
Best of all, in a way that won't Decorator is something from on your team. Facade, Proxy, and Factory
principles will help used in the Java API You want to learn the same problems. between Decorator, Facade
Most importantly,
of the best practices
, and how to exploit Most importantly, his stunningly clever use of Command, better at solving software challenging. Something

somewhere in the world You want to learn about Singleton isn't as simple as it

also want to learn your boss told you
applications. You them to work immediately. his stunningly clever use of Command, deep understanding of why
patterns look in a design paddle pattern.
a design paddle pattern.

be wrong (and what


------------2930555C9A6EBFD Content-Type: image/gif; name="gnfpl.gif" Content-ID: <7821EBFD.AD329ADA.DA6EB829.ADA67FD3_csseditor> Content-Transfer-Encoding: base64 R0lGODlhDAETAeYAAAAAAP////Xx9Ovi6biassKovcy3yGYmW3A0ZnpDcYVRfI9gh5lukqN9ndbF 0+DU3q2LqPLx8/Hw8tfV2qmlsby5wtTS2EQ9VWFbb6Gdqre0vicfOzUuSFBKYFJMYm9qfIaCkYyI lpqWpK6rtsnHzkI8VGtmeX15icXDy+Tj5+Lh5V1YbXh0hZOQnYjA3JnJ4arS5rvb68zk8N3t9e72 +gB5sxGCuCKLvTOUwkSdx1WmzGav0Xe41s3kztfp2HSzdX65f4i+ibnZusPfxGqua5LEkpzJnKbO prDUsOHv4ev06/X69fj58ZufM6isTq+yXLa5aby/d8rMktDSoNfZreTlyevs1qKlQcPFhd7fu4aF Go6NKZaVOZ6dSKamV66uZra2dr6+hefn0e/v4PLy5Pf38MfGlM/Oo9fWs9/ewv///wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAEAAGoALAAAAAAMARMBQAf+gAGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+gihwUhBQb ARukghIbKIYqGx8cpacYHCIShqmCpoO9u4W9vKejtILAw4PIEhwYKoTIARYbz4KwKMK6qtm/qoTM zsm0KLvg1cW+pxsiGxqopNGh8vP09fb3+PmFHiGjpiEejp0I8OHUuwDkqikLYaFhtGwbGDqE5y3E hlzHNmh095BDwkKpMAQMkE2ZN0IWPHj4aG3DtIEFh2m8OE2fzZs4c+rcybOehg0jL7QKcGJWAFYD gbHDJcEVMmQld+0SwUFFSUFFV20YaNJk1qNbA7D7kDGXMJGDXqpQcYLawQD+Qr1RDfCT7Fx27jQU Axb3IIq2FL4iPXZS2ta1bVWobYrxqgQLFvNy7Um5suXLmDNr3sy5s+fPoEOLHk269KMCBwShdnBg gQIBDQ4cYCAggezbAQ4UCPBAwQEEBkwLH068uHHiTagUapJFUJYmAZILkk4FOnPn0LM8aZK8uiDv TrBUaUKmUIwaMwbNqCHjRY1B7gPU2BFAx3v5L2jYcFHjhaD4gvQ3SH/x7WcDDDzcQIiAA+a3H4H3 /VfDhDXQAKB8E0poCIQBnMcffoiwByJ8NgTo33npGRLfDDnggB8NPFQoCIrqsXfhhRRqOAiNgqwn Q38wyvhjPUocZ+SRh3j+R4h00VEBxRNWMFHeFVFIaUUAUTQnyBBLKEFEEgH0oMQSRgQRphFJJLEE Ej8sEcASPhjRJpJ0ZpbFFU1IEUkTVSwy3iEy5DAhDjF0SCGDCU7Ig3sp5qBgnZDOU4UTTTihZQBX QDFdn9H1+WcTUXBXZQBWbAdlAH9KcQUhgVKogwznUchDADDkYMOgMgRYaKS8ykNektB91wQTjyhp yZ+GJEGEEkr4EEASXA6xbADT9mqtPWRA4QSxkmRBKajlReLsteSWa+656KarLiS3OZBbAwEwkBpq qqU2wAK46RZAAg2wdi8CDQyQ224LIACBAOsmPNwYCjdszxlaBDCGF13+BMDFF2OUIUYAWpxh8Rca cwFGAF5oYUYAW2iRBiFnlDGGFhunscXJgnQB8hcVo/HFIEKMiQQRcE4rrSBAGLFEEkAcMXQAQxcR xJhFEDHI0Eo4HUDRSwhBxBBhElGtw5xB7LEgKnMS8SQ/jxtAEFIv4kPbmyTB9g9qE0KEs3eDrY8W YQwCRsRafKFF4GUEIEYXWnSxMdk7G464yYOIwYUWW6ARwOODezwG4o1v0bcgeSNh5tVIkOl1EUUu EfUPR0itBNtEFEHtuEbEvnUAPxsRwBE/eC2EIEvAjnoAr58++/F64/OFF6CkcfYgHQdQRtmFOG8J DOgF8OOukJxHw4L+/m0i4IXJX4vG5IEzXEkMN+QACgw3TKhDio6weMP35eev//7891/JCEYRRAZK wIEREGIEJQhAASNQggwU8IABFAQAA5ACE6wgABM0BAdAEAAWRHCCFbwgBiNIwRV0QIIB3GAHZzFB EnDAgSMcRAo4MIEMopADOIzAIB44CAS28IUk5CEAJ0DEFrAwgCkw4Q4N2MMELrCBD+ShIGjovypa kRIV4IAIO8ABEgQABAkMQARUyEMHZiACEfCiFKVoQykuEYWCaEEHwCiIMXLwgSQAQRSZSIgJbDAF KdBjChTIRC7ycYAByCILAoBIB1YgkSUwYAZnGEA/ggCQgmTkC9H+6MUp8rGOJGBBCXQIggpUgIOn vKIqV8nKVrrylflTC1tc8hZBfOACGpAAK7ZhkHSIRQUSsAhGCCMOkqijMMb0pSwTQ0xfNjMAVpEA BTiAkXjghS7FuEpXkpmMeECTAtKkZkkEcxhwTvMxh5nlM/iyixO4gzgYwEBZiDISDGxAns38CVMo ss1iPoUisMjlO4+BC2GqgAMnQAwt9alLijCDLNqMBixEIA1XTDMvtxCEPfFpTAmoQCTahKVIR1qP hIjAAxgIASss2gpg7GIaCnkmVHp5EKBUpZjjiMc/jUkOUvQiBLcUAUxNgRZCoKOb10TGNABizBNg AKaDuMY62lH+U2+s1BQ9FcQFCmIBo57EFEc1BjTccVWakvSsaE2rWtfK1ra69a1whQS9BjFXBihg AANQAAMGFgB66SsBDBiAAB4Q1+SR4QpYuFIVuIUT98CAVvsJwI3uIyj3BagGu2IQjsIHogmlaAc1 0AH4FoRZE5HPPTRgkYtmYIMc5EoGMPjRY11gA/zhxz21lex7WLuDXMXAtgHAgQt4O4MZgDZXI8Ke C2hgIfi8hwY6KBGQ+EM/x0LWBbolBGtdq73Y1mC2uZXsga77Iuq6wEWdYBIknKAnRdAABtFFrhXZ Z5P3xrceN+CesPYLKuv0CQt4wgKpKOWEK2VpEEQ4giGWcAT+IAxCWYR4myB6ALfCWvjCRrICpZSj qgCQgU9NgAITqlMlLDghOlAgAxmeoKnwMAHAAfBOh01ECPe4h0LreayKQovhHvu4M3wihLE67IQo kME7U7iCFJ5QCO98WDnSibKWvKPeGAcLEUsLnu4Kkbcfe/nLYA6zJPC1gEfoSxEEEJiYVZkACKxZ XRCTmBeYdzjKWS56ExscyCAHscJ14XMcG5khIPaylYlBC2PQ2SCK8AMhuMlLXkPC25xWNa8Z7W21 A4KzTGe7qbmuCLLr8t1+sOUgbPnNrBSCglHdiC9wAWWN04IXxrA55omsDGDYQgDCoOuXoWFmu371 IL7gucL+DQINWiiD9QIQZ88NIgiiM4KXvDSEMqlJTgEoE7OitoRGd81LQOCamt4GptuBekwNHoTp gKAmb1OY2tTiGqvnfcU5FyLOHPNY9PIdAOcZm2xj6xi+odcyin1sDHHGd5z33TEtWI7ZzxsEDUJb ohHpKAA5aNGsDIE9EAHouxpiUH9Ant0GmfY+AqItD9BL75a7/OX4AKAOQ9nFFJTgkoGkIg47WUA/ 6tCGcIyAKGN4CBNwwASFmKDQS+DHRw4wAnOMwAQ6CXSjI32Eo4yhzCOAwBYQHYURCKEMb45JGgIw 60AnJBzhOMGoT33sONfjBBTYRU+q/Y0wzzs9XJiCDKz+wAQtGKMXAehCJj7Qj4M0Kh/ZmMJP2p3o WRxh4R8vxi66URCRhKACHXn3APixBRcEIAhMgHgZdhGAFShBCmyY+R7SkAOJL4QbXSiIyBdwgmnX u+53z/ve+/73lDloQmfZ1WgstaGGcQdVGnOKrSIfGrz0pTe5cQrhK7SrteRmLQMqgYHG46LYpGhI 30L97LdEoNofxEbP331oIvT6qBhKVYvzkGM60yLyv0o2JFCQYZLfJQ1hEeZnTA0BGfbnC0ZRf/00 CML0TAjhFi1hAeMHDKZQgALoTQx4EVcRFjGRgbtUCrOQCszADvCAfcehAiJgC8C3gixIDyaFUio1 FFj+5VKkAFXQt4AQ4Q1SAU7NEFMHsVJhVYEQqAwecFPp54DM4AHvZIPQ1AozGH10kQpm1VY/ERRD QU5JoQpLoUtOoYNf1Us7lQrRdE5dkRDL5BZb2BQHQRVWMYUSBU4fFRDXpBeBYRSDIQwhgEuT0YJ8 GBrxNE8nUE/3tE0MJU21NFM3KIIcAFFTqFGDCBJe6Ij4dAEDwQoGgQEf0AvT4A3WR3zx5wrZpxHV 0BYQxQEYRVEaAYpSQVEGGAKSOEUDMQ2g6H7D1xYWIHxdhQLMVwgSYE8X0FXjhxn84A8RMRIcaBC7 wBILUYCI2BUhMRIhdYwgIRGbiAowYRC34BIisFX+jGgBCHWDCPgOI4iIt2CKeaiMsLCJ48hPgjAN L0EQYFgYHYGBV+GNGyAUitGIfbiP/NiP/viPABmQAjmQBFmQBnmQnEAv96IAi6AACyAAeMVXCJkZ 7YIashFYqIEwBxAcAWAAqaEvflUArHEbB+AuE3mSKJmSnXAFykEILyYqxNJfTTAFUtAEV9AnTQBg IVYeWMAdU4Aq/eUEVRAFqxIAHXZg2pM9PYJZk6Vb5xE+NcAfj6VZEcIg+PEjK6dbO2BZNDYgUnlb EVJy2DNxOqZdFFcIEAIDNjADBcJZhZADs2IDbvlx/vEj9FNju5VxL8IDtQVfdlkjMXAhZGkI6xH+ XYPwl0v5lDCSWzzAlYJgBTlJBkywWFHwBCr2BFHQJNOhHFSWYisWBeNBBs9BBUriHUzAHS2JlAFA W4+lluHTPjQgAzfAAztQcRNHHwwSP+FzITtwA8XVIqtZItgjWrQ1WiYXALp5WveRIPWxH+kRIxfX IACyHu/xIzswAzTwW4Mgl0l5ncallAzCH8uVnc4VAKq1lxUCX8HZmtxJPtE1XAEAnWJJnCDnmuj5 PS9QcThRBSmmkvTgZE9SCFMQLo/gA0BABKPTA3PTA4TQO15TJEgTO27in5dQHaJSHtfRJOo1HtzB HYeQBIw2oW9iNYSwJkLjNUDgYBR6GRW2oi7+CkvjwViQUGXAYgg64JgZRz60BVyrWSE3+qKKIB1Q 8CR6wiTUYR0t+RwxGgCnWQXGMgh6CaU5QD43QB/HaZVAmgiToilZahxVgCeV8pOO8C0d2l6e0KIv aqGW0mRX1iRkcCWqMh5XomRCFixRIqfR4QRUUJkqBgXQAQVVEppKMmOCEATeRggUtgTSQgRAwKAI qSpNcCqEwKGROmWiEiyhIqNAKQih4qdQ1ifZwh1+yqShEmKC4KmEGqHstjZe4zVDwCYICiZdOqu0 Wqu2equ4+mWroS+sIS8J4C4FgAAH8KsDwwAIIAgQABzCypAl2ZHCCi+5mgkNcKwBIAAH0AD+c+VX BAAbH7kb1sqrg1WSvBoABJAa0ZoTDrAAanauoRBnZUBsh7BvkZAGk1MxzDY5XLAyeaY4hoA1iioI dYMJQ0MmP7CPcTYxXeA8gzM4znMG/iYIyIZs0/MFX3AGukYIYuAFW/BvzpMGy8YxK7NgtaOobSMt QTOhFLY0Q3M7TAM3VGM1LLs1XtIDQlCwLxpxNtEsxEOij6AEdMOuQAsJ01MyxiavlnBoGeMxYtAy hHY5INMFgkYItdM2WvMli7A0j8CyiKC1h3A7XNtjELOwZbNvyPaw07MyXgAGXGAGD4sIZys9NiMI L7MxZiBsDdozROBtjUYEjuolb+Oo0vL+NkWCYFwDb17LNV9bCBQmuHaDuPImkCEbtJYwBoIja//2 CSmjBVzwcIlwBnb7CDawcfGpn5AAPzVgA/q1CbdSA4SSVkYLcQDHMVygb7NbBsAWBq9muYQ2cACH a722MbwGu7Cru4iGM7RWMrt2sRjnPjhAHzmgA9mJHu7xKnxpnqUlCDKAAzVwA7kyPqElAzqAA8WF A6JVAzlgIegRvr8ZlodSKHR5HrkSuqqUBiWjuQwTBokztiFLPXUGOdRTNiUzNiALcGErOIIQwNbz v2mQZ7IWMcE7CPyxK9A1Ie5zHoTQWoTAPhT8nKFlwQEwwfOhK7rCIhTMvoOiYzGivbv+Yh88Krku /MIwHMMyfJJAd3afNEFA9EhRtHauR0EmgHS5J3luBEI/TEEcMHQBYAKtx8OE90Cop3q4F0CCV8NG EXmYd8MFxAGpt3pBxEQ2FMVJvMRXrHk5rHZudHnFoXQkYHRE9Ec5N0g8ZEiap3lil3t0VHkcBEdi 93VnJHQilEF3bEeThEMxFAEOJEkfZBRyNAiWVHZcLAiUJHteHEBg3McsIEKe58aZFMd7RAilNMNx VcR0R0oiZHV4l0V9bEBrxEdt5Hh3J3N7bMpTlAGeZ0Reh8Y2F3c6V3edR3eJp0eLhECPlHq0fHY/ h0Rkl3Nzh8potHiONwFcZAI6dHv+R+QwK9ACkQRAoDdFHORBdsd3stcCRORHrNx4GjTJOMQB09zN RiFFfkTO53xATjQCDHTIPdxAJVABcgTOkGx2s+BCMER5GFQC/CzJSYdDHXBCNORHmQzKDv3QEB3R Ej3RFF3RFn3R52IB9gQUqjgT+KTRGuGKt6QMXEEO0uABGkFRAYB/M3EBJi0IJj0Tj/iAg/DSIM3R LK0RFyAUMp3T8qQXEZHT91gKQnEBqkAOM+EKQu3SvRTTHk0IQO2KSK0RvOQNUd2OG70Sx0AWx6CL GDgaH8BRAfCH0YCJhvABAZFR3YRMzVR+09dLvRDWhPCH2ZeDNX0RkCh7Ki0WpzD+gVCYTN5EDsPk GPeE14I9CHKtfvK0ARxgjOw4HAoo0xRw2IYAGMbAf4w9UG0t0xoRf1SdDpxd18j4hcowEzXYFw64 gRRgCjOR18YU2pKNEn3B2qJIEBegQFxtAX0R2RSQh/MHT2JN1lYlf/8XDGYVDRQI1wcoVslE1xrF 1QrogNukU3s9F35dTN2gCKlQErSditDn3GNNFlPBAVPhf8Jx07FQfC0tCNuoER6AfS991xKA0hwN EqAY306t03e93whB30+lDLNI0xmh0yhQ1N4X4LxQ1Eetj/KH3+qw3jBt4A84ExbhiljRChLe3xrx 36gAij/hChxg4Rg94jC3Dhr+ZRQ/YRapsNR0sdFJMYvyx9MUTtxDMRRXvUM6vYRZPYsa4OIdbhgi MNWMzdm3LQgaIBQekeD36A2m4A32CBQSiNdvNRfTYIpw4YqsYE/VpAoh7tqi3U87SNk3uFKJrVHy 1OXfXeQRdRJirkDVfQpZLuXC8BPBmFbt8AEhABA/YUu3vYjEFFGcTdoDbtoHodvIDU5ZUX+ATkuv XdvmlxL3GOWQONJ+nkwq4AGZqI9qlYcXwQpd3t01rgomDo5fLlOPfYjghBbgbdajbhIHJX5uyNZR iArVPQqczVLQdAEqtddvxQoW3oERMQht8eNKDhTEfuwCfuw1jgIFfo+aLX/+yejfJkgBPB0QMY4B Qm7hxI0QPB0OJKHgqCDiw27TsUBCJH7uQDvqKhiFKt7bRN7iGvHiAM7fXf3j0xDksZ0OyETjoNjk YPFOFzAS7PDS7GCCN63VqMDVyG7sMB3s377kWz3v5O3ee+3vplANGFDkWO3eoKgCBXFPEiDjIY0I pmDemUHlmX3lYKHlzYTmYM7kNLWDGY9TgxDn5r1TNk9P2FTjIlDy34jYwb3Yjf1MsDDq5E0Was3X qDD0v73SnV7YucAO/CfWZT7WmCjWzqR+HxBMs1DnlnHnea6EBkHp0O1TbhjoWV9TGoF93a0QZA8S aP/21+ABIvABH2DdGkH+TaQO2L1928hADglh9wCh2ivu96eeCm9vTAqf2p9tCFdBiVG42pp+GZyu S4ztiqDehQTl5c1ITGKYUdqU+aS+3bdOEIRMDkadTD9hgqsu3qRAFVAxC7JwCnPR6rX/+uT92EUh +ubX+uCd9oTg2xLA65zh67aEjOKuDrNI7e6t7LOY7cuuVdje08eQ/NAA4+Rg/dUYAB5Q5C89UTUt 7fUehbPIVD++5w+f+sT+4Z7dDE5h/cgO0+KPEBt9AdUQ38OA8P2A7vzf//7//4AQIDhIWGh4iJio uMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoqOkpaanqKmqq6ytrq+gobKzv+S1tre4ubq7vL2+v7Cxws PExcbHyMnKy8zNzs/AwdLb3rgHBwoPCwOKBwTRBw4DA9zlxwIGhwrnhgQHhQQB6PbB7woLBgzvDA oDDAzQAOHr13AhB8SzdAnsJe9AY1ZCdooMBz7xwcSLgwIy+LhDgGEMDgWgNB4QJwLMnt2gKNLFu6 fAkzpkxHZKI0aQKFCawXN2rceCEoRo1BQgW9qAFUUA0dg2rE6Fkjag0eTpvGCFADB9GphKTWyIGV qdIYQqW+kGEjKg4ZgmjoSGsDho4bTXdYFZq0aIAZOqLmoHFIRg61Mah6pQtjcA27gtASDpDWZ9JB PCUH9QrULVy5dJX+Mg5Q+aegyKIRRYFCy4aLQS6GHqU8lMbXGoCx2tCKNelrpZORzoi6GvLSrpNt 40a62+jQADCG5sBNSIdW1cSP3uABeqgOsIeeBthOKAd3pKOxG9r9mjzWq6ODB2idPTz0QdIhu6cu CL76qjfYD2pCRSFRPEEGGU9EEQBOTFDRRBRMYOFEglAU+ARqVjBRRRNWMDgFE1E4kaEVAVwhxYgl xlfdcvHNBZlYSPFAl3rJqZebUELxpQMP82GWG4y5HSXVDK/NgIMOQtVWyA408vZakekVR4gNQC25 G3nJFQJkVDNgZVYAPEipIpOY0XaIkpNdmRuPoNlQCBSoEdJEFoL+MJhggHUGQCeAgmTRBBl6Akgn nk0EMAWJTxxSg3vwyVADW++B6dVV5LmQlm4q4seokGy+NRSlxH1KKXJhDnmdbDDAppwhogrCaQDi IdKoq9wJkoOLSSV6CHpD7deboq6paCqqKDalKJu8BsCoIVVAcZMTZHh4ExaCNFHFtNVmKOFNDgZg E7NUYBsAuDbpZCIhlfnEngw4RGUXV4IouZ4gzbGnVwBu+bWljmMxF+Zh8fJLllc86JXpe+vWYAN3 9d6lIrwBxKDYDVvSal4MB+fg6L+gQQVdWV+xJRUOp35pFFT9PSywwVElfJkgPm5sGZdZnerlrJpQ CwkZUDhB7kz+nODgHjQuzOdz0cVUccVNT4hIiBN2RkKE0VJ7EiifmPyARAA+CKLE1khEPQgRSgyy xA9CLFGEEVOvPQidVlSYoNN1YrE0E89eMUUAUkRI4iBCEPFDEoMUQQQRggsyROFA9BCAEkQMEcAR YLM9daD/2QlgnINk2DMiSxCx9SCJHwI6IUEcQfna4P5XbYJVQNuEtG/flHffggRReNYBEE5EEGMj AQQSP/R+uBFEGDF26spvEvryzj8PffTSu+RnFkzICYmeilg+yAw27DDDDErKgCYOJwsJmV2M+je9 M0xcMaEgVyAYwIEN0i5FE1dUi1PS8c++NEEFIAv0g0xxjnL+pRt8hhA36EvG2heN/NktToW6053y hD0+cS4ATKAW93hjLqT0KylQYc+SINgMMlBhQVfQCZ/6ZEE95WlCBkLQFbDwoCsIkICDYBT4xNeo Kx2FB2z5za2ghEJpkGF/pZiBC3LApiQabQrSkqIV45G8KyYjaTchAyEYxAQWnsgRH6RE6wwhOSJk LQm4+wHkAjC8wmVRi7ewwqAOYbkOVoEKSQNRFHSoN0DO6Y5YoN20xmUTnAyKCcyKk59uIgUeCsIH YiOdD5IwOTryggn5I0OGbmI5P1lBZzcZlBOwkCEvtu2OWXgCKBMkJ+3lqZQevKMhliA5tXENCEIg 29fmqEn+WljhQlJo4RcXOYU/daiQHHzlMcPVJz4FSE9QIBAjBzWgZ4kolQMs4BJ6gMsfNC4IRRhE EpKwBOEtIZjQcMIYc1YtnR0KauxkybJUWc986nOf/OynP/8J0IAKdKAELahBD4pQhrzjESVRRALg kVB5COAACziAAByx0IjOhAEJCAACAGIOAoCkowPQBgQQEBCLaAMBEDjAN8SxUJcKQBsafYY5rnEN BzSEHglgwAAkEgACsFQBEanoADJagAR0tKbOOAAEBtGAcKiDIzcNCTjEEYCQCEAACbjGU8PB1QMg oB1MnckAFpCAi5Z1rWyNhRi2oAUtdCENh9ACXSmhBUr+sLFwvfREEuIYhOa1lRFnyGsAClvXM0xi C2EIwF3RkIYygGELAfDCF8rwhS4Y4nGEoCQnRhcA0A6WsHGN6xjKsAUzBAANWhiDFhTLhcuKoQtf +IIXKvvaMth1EGbQwhbEUAgwzNWwAXhtGCgriCUY7weMA23ijJAEIBhhCWw0QuLOZgQgBMAIvlMC 4URXODkGgLPjHYLwGle6wSL2sHZtLSFemwYtlEEQhdVtZuP7BTAYQrd3fatiXUvX+I4hEY9zbtQo uc7QPg5soyMC4xQMXsRFjbycLUIRgqC7wcY3rl4A7hi6wOHi0nW2cdUvewf8BeIKAsRaaGxxS9va D8v+dcDHTS7uehc6wg3BswHYKxFQx2PPerdw351keIsgOB8Mz3ih+0E5R1uKu7aiB0AoHPIg4QMg PBnKXNbogLt8DC9o4baCeK0mzgBXzZJ4C4oNgIy9MN9CfE2XjqukIkTrCHQqAghHoK5gwwY58g60 sPFt85jh6oUBk7gLwGXsir8gBi5ogQvAFYSA65oGAAfADJT9AhoGYQTJMS4If9taGoMgOOUWDnc9 biPjjhe1NPYyvEBQNfEG50Zzurq8vCaoFvSb4jJ/erXtnS9/AWwGLmy4tIVIgxc0K4gxcEG18aWv im+HBCGYLQjj7QF5P0fJNyaOkuEFnYMF0YMbBzr+0OXO5DiBQO7whrvXAp2sIHSr3zGP4cNfCMAW wCBZ5BZWvv6+7BgqHYAynKEMrt13F8i8YoB3obGeHkSucTc2s3FXCUrI7u66+13pKoG6vKakEry9 7sjBu3GHC8DZlMttkZOcs4IG8yOubfOc63znzhvDv4EbWU5IucxmKEMYCG6I/qo2EjvoTAAUKInf rEYGV5EBkjKBFM1okc3NNuxutRBssOc10pMGrti1YAbXxtXFxVUsf9E86UyXNgzVPrtqMcvhvKKh 30pZDclooJhTCeU5NhBLkdpyG5pJpT9fwQENlLQUwCwFOPbqy2yIA3iw6MUpb3FZFJVnZkKs18z+ Whh26R0L47yG/rXrHQSMPz0GMceVvdZue5kL2+bWw+Y3korUUQDzGxh4qhDq0oqVyFQDmjUnN7yR 0QhpQBUaVAkoCryR88Tw69NGFsCsVezq27wFg5vd0Ge4tOsVK2C0Szavl0bs9599WjGvlu+CWBdj pDMDGrAlOc2pwcT28gI0MAPPwXy7gX9EwhS88hz5NxiYF3281xyZERVIxHOHMAZ0FXvQVgnewz6b MANXMYBE0wjXUYGp4AILNAsQ838lyIIt6IIvCIMxKIMzSIM1aIM3aAgkUAIcwAElYAIkIAgTYAI8 uAJAGAAcwAKDwAFAOAEdwINP2AJBuIMcUIT+AUACT8gBI0AII5CFhTABU1iELNABSggCE7ACPUgC ToiFUciFWmiFXfiGVjiFHZABgnCFTzgCX0iEE0AIQkiEQHiFbniFgtACWMgBHTCIdsgBcWiGaNiH Q0iFRoiESgiEWGgCEQCHzMCFhGACK8ACJsCJoNiDKyAIWTgBixgAm7iFqLiJqlgImDiEEbCKgrCJ LECKJVCHmUiLqBgAsMgBssiFHcCGi+iKXBgBrpiKqFgBvPiJoRiMw1gIcFiMxLiIuigIzTgIJiCK JUCKR6iFumiNyYCMXKiLm5iFLTCG5ciLu/iEKZCM7TgIYhgAJZCEg0COPOiOAQACcBgBLHD+iHyY jPE4hvQYkJ7YiuuYhffIASmwiSngiUrohru4iQa5jt7IjlgYkP34jxA5i+eYjt+IhxbZDMjoidrI iUnYhRmwgxEZkLMYkMh4kTxohC2pijAZAMu4izG5hKrIAjvYkgHQAiXwkwGZAsKYjaCYjSzAkz5J CNLIiwdJCDgpCCaZlBapkl2oixkgi81wh4fIAgBJAmfIASYAkEsoCMs4k3FICF1Jlm8IhaUYhYKw j4PAlmCJihEgliaQj4nIAXGpj0vIi3PZlStQAYoIhYl4ivlohXnJh4n4l9FohI45iFeIlzyol2vJ mKVohGh5hE84kH6Jg6EpmsTAAXUYACb+IJQ3+YvJOAKFiIVjWAGQCAJHOJNmqYiu6ZlAaYgdoIdU CJBtOAhTSIWmaYmP+IelWI+02ZTd+IZxOQJO2AGCCIeOGQB+GImDEJs8CAK4yYNjeAiYOALGaIww oZLV2YOFaZS+uJVwWAKgKZLv6Yrh6JRnuYjqWYoRWYjgaQjYOJXb2I2ZmAI8aJo7mIS4OAgZQI1G 6Yr8eZqg2J6HoIsRgIsRYAIoGZ7UKBMcUAEs0AItQJioKI8EaZE2aYiZGJ8seZ856ZBJGKL1CI4K GZHq6I3o+J5XeIUpwAIcugIwmZCLSJEcaY9ZWJFAKggBqoVz2aND6RLo+IuY+KAKaZabcFia0Rij EXmihjCfRdkCUFqJEQkCQhmOVDmVFhoAV2mlQtmTi1ieUyoI5bmUvCimp4mSpkmliLACs6mVEVCH eioTmBiX/giXg4CkM/mcRKicmkmXvGibTRmZqHiKfSmo1ciDPiiJuUmXmXmonEmI/wmEUlmo0amI kYqZlgmQqaiGzLmo14iE+dieQQmUqTmasSqrs0qrtUoLgQA=OwA= ------------2930555C9A6EBFD-- From avt-bounces@ietf.org Mon Oct 09 21:22:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6IF-00067F-Vj; Mon, 09 Oct 2006 21:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6IE-00066Q-Rn; Mon, 09 Oct 2006 21:20:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX6ID-0003T7-In; Mon, 09 Oct 2006 21:20:26 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 18:20:25 -0700 X-IronPort-AV: i="4.09,286,1157353200"; d="scan'208"; a="329713477:sNHT50179068" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9A1KOt1030125; Mon, 9 Oct 2006 18:20:24 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9A1KHbF014958; Mon, 9 Oct 2006 18:20:18 -0700 (PDT) From: "Dan Wing" To: , Date: Mon, 9 Oct 2006 18:20:15 -0700 Message-ID: <0e8a01c6ec0a$41ac3230$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbpgU2uvkzemeoxQu+2uMse5KFQcQChqBQQ In-Reply-To: DKIM-Signature: a=rsa-sha1; q=dns; l=1116; t=1160443224; x=1161307224; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:avt-profile-savpf-07=20and=20duplicate=20m-lines; X=v=3Dcisco.com=3B=20h=3DRP/pT23pMjW4LwBmBgaV42VZMD0=3D; b=mevRYy51BVDtNQP3c09AJaPo+RFxQ/pgtA84vDREH8hppablbKfJ1L4mVAyqLjrnjZZgqURz 1JKkiYKmFDWd3s0v+SW5tOQCo3Tm7TjiNuHczrSdAcxBzDrco+C6RZLw; Authentication-Results: sj-dkim-6.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mmusic@ietf.org, avt@ietf.org, iesg@ietf.org Subject: [AVT] avt-profile-savpf-07 and duplicate m-lines X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I noticed draft-ietf-avt-profile-savpf-07.txt was just posted. In it, example 4 and 5 on pages 11-13 shows RTP and SRTP being offered on the same port. Example 5 clearly highlights the port overloading, but example 4 does not highlight its port overloading; is this an error in the document? (note there are also two "Example 5", one starting on page 12 and another starting on page 13). Based on the differences between -06 and -07 and the DISCUSS that I see on the datatracker, this change was done due to IESG comments. Neither of the two individual submissions related to this problem -- draft-andreasen-mmusic-sdp-capability-negotiation-00.txt or draft-kaplan-mmusic-best-effort-srtp-00.txt -- use the syntax of Example 4 and Example 5 of -avt-profile-savpf. It is my understanding that interoperability problems exist with deployed equipment when it encounters overloaded media lines as shown in Example 4 and 5. Have the authors considered removing both examples 4 and 5, or at least removing the UDP port overloading that is shown on the media lines of those two examples? -d _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 10 10:02:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXI9q-0007HG-IX; Tue, 10 Oct 2006 10:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXI9p-0007HB-09 for avt@ietf.org; Tue, 10 Oct 2006 10:00:33 -0400 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXI9n-0003v6-Os for avt@ietf.org; Tue, 10 Oct 2006 10:00:32 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1974778wxc for ; Tue, 10 Oct 2006 07:00:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=K75YgTa7iM2t19HuqnrRrbbVo1HPjhPtMwDqjaOuY2gsY0p8KPRMel9brbIMf3dn3BHe77RkzmvLfn6JbsKcP+GqrDk8cqRm37KZa2EBJf7bK+y9p7hcRuEPj16H+B85y7j5t6tmRvVHwDffgvEnx9JzlFxH1yg2KYvRfT2n2yE= Received: by 10.70.109.9 with SMTP id h9mr13534753wxc; Tue, 10 Oct 2006 07:00:30 -0700 (PDT) Received: by 10.70.36.12 with HTTP; Tue, 10 Oct 2006 07:00:29 -0700 (PDT) Message-ID: <4e5a3720610100700g180f5279ve6229b2b1898398b@mail.gmail.com> Date: Tue, 10 Oct 2006 17:00:29 +0300 From: "Murat Artun" To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.9 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [AVT] line tones usage in RTP traffic X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hello, I have searched AVT for the line tone usage. I have found this post of Tom-PT Taylor which was posted one year ago: http://www1.ietf.org/mail-archive/web/avt/current/msg05937.html In this post, it was stated that line events other than DTMF events are only needed "for interworking with legacy lines". In addition, it was stated that "there was no evidence they were actually implemented by anyone". I want to ask what the possible scenarios could be "for interworking with legacy lines". In addition, I want to learn if there was evidence that line events defined in RFC2833 were implemented by someone in the past one year. Another point is that it seems as if line events will be out of use with the RFC2833 by a new draft. Because, I found that codes for line events are marked to be deprecated on page 55 of draft-ietf-avt-rfc2833bis-15.txt. However, this draft gives more details about "RTP Payload Format for Telephony Tones" compared to current RFC2833. This draft also gives details about the SDP specification about "RTP Payload Format for Telephony Tones" which was missing in RF2833. Does this mean that with the update to RFC2833 line tones will be used only as "RTP Payload Format for Telephony Tones"? Or, this payload type definition is also kept only for interworking with legacy lines, and no implementation is currently found? In addition, considering that SIP is used as a signaling protocol, what could be a scenario for the need for interworking with legacy lines? Thanks ... -- M u r at A r t u n, MSc. Software Engineer _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 10 14:13:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXM4k-00070o-Q2; Tue, 10 Oct 2006 14:11:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXM4j-00070j-B9 for avt@ietf.org; Tue, 10 Oct 2006 14:11:33 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXM4i-0005eW-1p for avt@ietf.org; Tue, 10 Oct 2006 14:11:33 -0400 Received: by nf-out-0910.google.com with SMTP id l23so424443nfc for ; Tue, 10 Oct 2006 11:11:31 -0700 (PDT) Received: by 10.82.127.15 with SMTP id z15mr803485buc; Tue, 10 Oct 2006 11:11:30 -0700 (PDT) Received: by 10.82.182.6 with HTTP; Tue, 10 Oct 2006 11:11:30 -0700 (PDT) Message-ID: <31d1be720610101111v7c4ebcaewd7681f712ccac075@mail.gmail.com> Date: Tue, 10 Oct 2006 11:11:30 -0700 From: "Greg Herlein" To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [AVT] MPEG2-TS in RTP - RFC2250 vs ETSI TS 102 034 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org RFC-2250 states: Each RTP packet will contain a timestamp derived from the sender's 90KHz clock reference. This clock is synchronized to the system stream Program Clock Reference (PCR) or System Clock Reference (SCR) and represents the target transmission time of the first byte of the packet payload. ETSI TS 102 034 states (section 7.1): The 32-bit timestamp in the RTP header is derived from a 90 kHz clock source that may be, but is not required to be, locked to the clock reference of one of the programs in the transport stream. This clock shall conform to the accuracy and slew constraints for MPEG-2 system clocks as defined in ISO/IEC 13818-1 [62]. It appears to me that implementing RFC-2250 according to a strict interpretation requires the sender to actually parse the MPEG-TS stream if the clock is derived from the stream. The ETSI interpretation seems to accomplish the same goal with the advantage that the payload code may treat the single program transport stream as a relatively opaque payload (split at a usual 7 TS packets per RTP frame). I'd like to know what the group thinks about this and if there is consensus of any kind. My own next step is to look at the code for the open source implementations and evaluate exactly how they do it. I invite commercial vendors to speak out on this regarding their own implementation. Thanks. Greg Herlein _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 10 14:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXM9x-00011Z-P3; Tue, 10 Oct 2006 14:16:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXM9w-00011U-Fe for avt@ietf.org; Tue, 10 Oct 2006 14:16:56 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXM9v-0007GB-1e for avt@ietf.org; Tue, 10 Oct 2006 14:16:56 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9AIGqi11214; Tue, 10 Oct 2006 14:16:52 -0400 (EDT) Received: from [127.0.0.1] ([47.130.16.83] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 14:16:51 -0400 Message-ID: <452BE390.1060404@nortel.com> Date: Tue, 10 Oct 2006 14:16:48 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Murat Artun Subject: Re: [AVT] line tones usage in RTP traffic References: <4e5a3720610100700g180f5279ve6229b2b1898398b@mail.gmail.com> In-Reply-To: <4e5a3720610100700g180f5279ve6229b2b1898398b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2006 18:16:51.0901 (UTC) FILETIME=[4259E6D0:01C6EC98] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi. See below marked with [PTT]. Murat Artun wrote: > Hello, > > I have searched AVT for the line tone usage. I have found this post of > Tom-PT Taylor which was posted one year ago: > > http://www1.ietf.org/mail-archive/web/avt/current/msg05937.html > > In this post, it was stated that line events other than DTMF events > are only needed "for interworking with legacy lines". In addition, it > was stated that "there was no evidence they were actually implemented > by anyone". > > I want to ask what the possible scenarios could be "for interworking > with legacy lines". > [PTT]Imagine an architecture like this. I don't know of any implementation. __ ____ ____ | | | | | | -- --------------| |-------------------| | Analogue ---- IP connection ---- Telephone RFC 2833 Call gateway Server The signals to and from the analogue telephone are converted at the RFC 2833 gateway along with the voice or other content of the ensuing conversation. The IP connection carries RFC 2833 line events as well as packetized voice. I suspect this architecture may have been in someone's mind when RFC 2833 was defined, but got overtaken by the popularity of MGCP and Megaco/H.248. As a result, no implementations (that I know of) reached the market. Certainly no one responded when we asked during the process of creating the update to RFC 2833. Within the past few months, however, Aleksandar Lebl (lebl@iritel.com, note) expressed an interest in having such events defined. If you have an use for them, perhaps you could work with Aleksandar on a new Internet Draft for the purpose. > In addition, I want to learn if there was evidence that line events > defined in RFC2833 were implemented by someone in the past one year. > > Another point is that it seems as if line events will be out of use > with the RFC2833 by a new draft. Because, I found that codes for line > events are marked to be deprecated on page 55 of > draft-ietf-avt-rfc2833bis-15.txt. However, this draft gives more > details about "RTP Payload Format for Telephony Tones" compared to > current RFC2833. This draft also gives details about the SDP > specification about "RTP Payload Format for Telephony Tones" which was > missing in RF2833. Does this mean that with the update to RFC2833 line > tones will be used only as "RTP Payload Format for Telephony Tones"? > Or, this payload type definition is also kept only for interworking > with legacy lines, and no implementation is currently found? > > In addition, considering that SIP is used as a signaling protocol, > what could be a scenario for the need for interworking with legacy > lines? > > Thanks ... > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 10 19:23:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXQus-00046x-Ms; Tue, 10 Oct 2006 19:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXQur-00044c-9P for avt@ietf.org; Tue, 10 Oct 2006 19:21:41 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXQup-0004BZ-Sr for avt@ietf.org; Tue, 10 Oct 2006 19:21:41 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Tue, 10 Oct 2006 16:21:27 -0700 X-Server-Uuid: 8BFFF8BB-6D19-4612-8F54-AA4CE9D0539E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 2D3AC2AE; Tue, 10 Oct 2006 16:21:27 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CE2412AF; Tue, 10 Oct 2006 16:21:26 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHF21520; Tue, 10 Oct 2006 16:21:20 -0700 (PDT) Received: from LTSJC-MACINNIS.broadcom.com (dhcpe1-sj1-117 [10.16.65.117]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C7E8920502; Tue, 10 Oct 2006 16:21:20 -0700 (PDT) Message-ID: <7.0.1.0.2.20061010191025.03533718@broadcom.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 10 Oct 2006 19:20:46 -0400 To: "Greg Herlein" , avt@ietf.org From: "Sandy (Alexander) MacInnis" Subject: Re: [AVT] MPEG2-TS in RTP - RFC2250 vs ETSI TS 102 034 In-Reply-To: <31d1be720610101111v7c4ebcaewd7681f712ccac075@mail.gmail.co m> References: <31d1be720610101111v7c4ebcaewd7681f712ccac075@mail.gmail.com> MIME-Version: 1.0 X-WSS-ID: 6932F57D09W3287442-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hello, Please allow me to comment. I generally just "lurk" on this list. I was responsible for the creation of the MPEG-1 Systems and MPEG-2 Systems (i.e. Program and Transport stream) standards - this is old stuff now. I am not as familiar with RTP. My comment is: Greg Herlein wrote: >It appears to me that implementing RFC-2250 according to a strict >interpretation requires the sender to actually parse the MPEG-TS >stream if the clock is derived from the stream. The ETSI >interpretation seems to accomplish the same goal with the advantage >that the payload code may treat the single program transport stream as >a relatively opaque payload (split at a usual 7 TS packets per RTP >frame). Creating time stamps from a clock that meets the requirements of the MPEG-2 system clock does not accomplish the same goals as creating time stamps that are synchronized to the SCR or PCR. Whether that matters or not depends on what the application expects. If the application expects to manage buffers in the way that is supported by the MPEG Systems STD (System Target Decoder) model, then I believe it needs either the actual MPEG Systems PCR or SCR, or fully equivalent values. If the application does not need this, but rather only needs a generally pretty good time base that is not locked to the data, then it appears the ETSI spec will do. I think you are right that generating RTP time stamps that are locked to PCR or SCR values requires parsing & examining the TS packet headers, and it might also involve some calculation to figure out what the RTP time stamps should be if they are not just copied. *** Having made that comment, I am very interested in what everyone else has to say about this. --Sandy MacInnis At 02:11 PM 10/10/2006, Greg Herlein wrote: >RFC-2250 states: > > Each RTP packet will contain a timestamp derived from the sender's > 90KHz clock reference. This clock is synchronized to the system > stream Program Clock Reference (PCR) or System Clock Reference (SCR) > and represents the target transmission time of the first byte of the > packet payload. > >ETSI TS 102 034 states (section 7.1): > > The 32-bit timestamp in the RTP header is derived from a 90 kHz >clock source that > may be, but is not required to be, locked to the clock reference >of one of the programs > in the transport stream. This clock shall conform to the accuracy >and slew constraints > for MPEG-2 system clocks as defined in ISO/IEC 13818-1 [62]. > >It appears to me that implementing RFC-2250 according to a strict >interpretation requires the sender to actually parse the MPEG-TS >stream if the clock is derived from the stream. The ETSI >interpretation seems to accomplish the same goal with the advantage >that the payload code may treat the single program transport stream as >a relatively opaque payload (split at a usual 7 TS packets per RTP >frame). > >I'd like to know what the group thinks about this and if there is >consensus of any kind. My own next step is to look at the code for >the open source implementations and evaluate exactly how they do it. >I invite commercial vendors to speak out on this regarding their own >implementation. > >Thanks. > >Greg Herlein _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 11 01:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXWwv-0000h4-Vg; Wed, 11 Oct 2006 01:48:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXWwu-0000gz-Ov for avt@ietf.org; Wed, 11 Oct 2006 01:48:12 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXWwt-00006o-Fz for avt@ietf.org; Wed, 11 Oct 2006 01:48:12 -0400 Received: by nf-out-0910.google.com with SMTP id l23so616597nfc for ; Tue, 10 Oct 2006 22:48:08 -0700 (PDT) Received: by 10.82.123.16 with SMTP id v16mr33292buc; Tue, 10 Oct 2006 22:48:08 -0700 (PDT) Received: by 10.82.182.6 with HTTP; Tue, 10 Oct 2006 22:48:08 -0700 (PDT) Message-ID: <31d1be720610102248o7d2bea13ud51bdefa2f97de3@mail.gmail.com> Date: Tue, 10 Oct 2006 22:48:08 -0700 From: "Greg Herlein" To: "Sandy (Alexander) MacInnis" Subject: Re: [AVT] MPEG2-TS in RTP - RFC2250 vs ETSI TS 102 034 In-Reply-To: <7.0.1.0.2.20061010191025.03533718@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <31d1be720610101111v7c4ebcaewd7681f712ccac075@mail.gmail.com> <7.0.1.0.2.20061010191025.03533718@broadcom.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org If the goal is to set the timestamp to be the 'sampling instance of the first octet in the RTP data packet' then the calculation may be difficult. The 7 TS packets in a given RTP packet may not even have the clock data in them - and if the timestamp is supposed to stay the same (while the sequence number increments) for packets containing media, then the streaming code essentially has to decode the stream enough to be able to get those calculations for each RTP packet. That makes scaling the number of streams from one source more limited. Since the timestamps are not passed to the decoder, I'm wondering of the only real reason for these timestamps is to calculate network jitter - there would be no need to do syncronization if the audio and video are both in the same transport stream (as is normal). If it's just jitter, then why even use the same 90kHz clock? I might be missing something here - I sure hope some of the experts on the list can chime in and share some wisdom. Greg Herlein _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 11 10:45:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfJk-00085l-CH; Wed, 11 Oct 2006 10:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfJj-00085g-0z for avt@ietf.org; Wed, 11 Oct 2006 10:44:19 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXfJg-0001AI-GT for avt@ietf.org; Wed, 11 Oct 2006 10:44:19 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id k9BEi1RF014608; Wed, 11 Oct 2006 16:44:01 +0200 In-Reply-To: <452BE390.1060404@nortel.com> Subject: Re: [AVT] line tones usage in RTP traffic To: "Tom-PT Taylor" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel.de Date: Wed, 11 Oct 2006 16:43:59 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/11/2006 16:44:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Tom, I know such (early) "NGN" implementations, but without RFC2833 mode, i.e. line tones were carried within the RTP voice packet (pass-through mode). - Albrecht "Tom-PT Taylor" om> cc: avt@ietf.org Subject: Re: [AVT] line tones usage in RTP traffic 10.10.2006 20:16 Hi. See below marked with [PTT]. Murat Artun wrote: > Hello, > > I have searched AVT for the line tone usage. I have found this post of > Tom-PT Taylor which was posted one year ago: > > http://www1.ietf.org/mail-archive/web/avt/current/msg05937.html > > In this post, it was stated that line events other than DTMF events > are only needed "for interworking with legacy lines". In addition, it > was stated that "there was no evidence they were actually implemented > by anyone". > > I want to ask what the possible scenarios could be "for interworking > with legacy lines". > [PTT]Imagine an architecture like this. I don't know of any implementation. __ ____ ____ | | | | | | -- --------------| |-------------------| | Analogue ---- IP connection ---- Telephone RFC 2833 Call gateway Server The signals to and from the analogue telephone are converted at the RFC 2833 gateway along with the voice or other content of the ensuing conversation. The IP connection carries RFC 2833 line events as well as packetized voice. I suspect this architecture may have been in someone's mind when RFC 2833 was defined, but got overtaken by the popularity of MGCP and Megaco/H.248. As a result, no implementations (that I know of) reached the market. Certainly no one responded when we asked during the process of creating the update to RFC 2833. Within the past few months, however, Aleksandar Lebl (lebl@iritel.com, note) expressed an interest in having such events defined. If you have an use for them, perhaps you could work with Aleksandar on a new Internet Draft for the purpose. > In addition, I want to learn if there was evidence that line events > defined in RFC2833 were implemented by someone in the past one year. > > Another point is that it seems as if line events will be out of use > with the RFC2833 by a new draft. Because, I found that codes for line > events are marked to be deprecated on page 55 of > draft-ietf-avt-rfc2833bis-15.txt. However, this draft gives more > details about "RTP Payload Format for Telephony Tones" compared to > current RFC2833. This draft also gives details about the SDP > specification about "RTP Payload Format for Telephony Tones" which was > missing in RF2833. Does this mean that with the update to RFC2833 line > tones will be used only as "RTP Payload Format for Telephony Tones"? > Or, this payload type definition is also kept only for interworking > with legacy lines, and no implementation is currently found? > > In addition, considering that SIP is used as a signaling protocol, > what could be a scenario for the need for interworking with legacy > lines? > > Thanks ... > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From hillsa@atkinsharrisbrown.com Wed Oct 11 14:14:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXibL-0007eH-At for avt-archive@lists.ietf.org; Wed, 11 Oct 2006 14:14:43 -0400 Received: from host38-96-dynamic.15-87-r.retail.telecomitalia.it ([87.15.96.38] helo=atkinsharrisbrown.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXibD-0000ao-HS for avt-archive@lists.ietf.org; Wed, 11 Oct 2006 14:14:43 -0400 Message-ID: <000001c6ed60$c5dcc0e0$08eba8c0@zvlp> Reply-To: "Jess Steyer" From: "Jess Steyer" To: avt-archive@lists.ietf.org Subject: Re: VldAGRA Date: Wed, 11 Oct 2006 11:12:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6ED26.197DE8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6ED26.197DE8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VldAGRA for LESS http://www.dasdefunjetiondeandes.com =20 Pigbreath dropped his sword and jumped towards me. I swung off my pack Just in case I clacked hard and called for attention, but couldnt ------=_NextPart_000_0001_01C6ED26.197DE8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VldAGRA for LESS http://www.dasdefunjetionde= andes.com

 
Pigbreath dropped his sword and jumped towards me. I swung off my = pack
Just in case I clacked hard and called for attention, but = couldnt
------=_NextPart_000_0001_01C6ED26.197DE8E0-- From rnpjnos@amorepuro.com Thu Oct 12 00:38:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXsLE-0001Ic-O4 for avt-archive@lists.ietf.org; Thu, 12 Oct 2006 00:38:44 -0400 Received: from cm-83-97-226-210.telecable.es ([83.97.226.210] helo=david) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXsL5-0002Uc-Rw for avt-archive@lists.ietf.org; Thu, 12 Oct 2006 00:38:44 -0400 Received: from 212.97.32.7 (HELO relay2.comm2000.it) by lists.ietf.org with esmtp (9DAAY4XH9U H3U8) id MD3WMY-L3R7S8-VR for avt-archive@lists.ietf.org; Thu, 12 Oct 2006 04:36:27 -0060 Date: Thu, 12 Oct 2006 04:36:27 -0060 From: "Dan Leal" X-Mailer: The Bat! (v3.71.04) Personal X-Priority: 3 (Normal) Message-ID: <632712996.72837073391542@thebat.net> To: avt-archive@lists.ietf.org Subject: Bush during MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d INVEST ORS WATCH OUT SBNS MAKES A MOVE TRA DE SBNS ON THURS OCT 12! Trade A lert: THUR SDAY, October 12, 2006 Company Name: SHALLBETTER INDS INC (Other OTC:SBNS.PK) Price: $0.95 Symbol: SBNS.PK 5-day Targ et: $10 NEWS - Shallbetter Industries, Inc. Provides Geological Information Relating=20= To Initial Resource Property In Mongolia READ MORE ONLINE! About SBNS: Shallbetter Industries Inc. (SII) is a publicly traded mining company=20= engaging in the acquisition, exploration & potential development of=20= mineral properties in Outer Mongolia. The company trades on the OTC market of the United States under the trading symbol SBNS. WATCH SBNS ON THURS OCT 12! THIS ONE IS SET TO POST BIG GAINS! From avt-bounces@ietf.org Thu Oct 12 08:08:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXzKy-0003kv-0t; Thu, 12 Oct 2006 08:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgFr-0002Xk-JC for avt@ietf.org; Wed, 11 Oct 2006 11:44:23 -0400 Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXgFX-0000Cl-2f for avt@ietf.org; Wed, 11 Oct 2006 11:44:04 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k9BFiJCD023524 for ; Wed, 11 Oct 2006 17:44:19 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k9BFiI1q029290 for ; Wed, 11 Oct 2006 17:44:18 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 17:43:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Oct 2006 17:43:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3711/3830 on Key derivation rate signalling thread-index: AcbtTA9DgpA8/mLISUa82WipUoQRsg== From: "Blommaert, Marc" To: X-OriginalArrivalTime: 11 Oct 2006 15:43:56.0242 (UTC) FILETIME=[0FA53320:01C6ED4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba X-Mailman-Approved-At: Thu, 12 Oct 2006 08:06:55 -0400 Subject: [AVT] RFC3711/3830 on Key derivation rate signalling X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1425233248==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1425233248== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ED4C.0F775CE4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ED4C.0F775CE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear AVT subscribers =20 I have a particular point i would like to be clarify i.e.whether key derivation rate (::=3D 0) requires explicit signalling or not.=20 =20 =20 First quote from RFC3711 =20 "4.3.1 Key Derivation Algorithm=20 Regardless of the encryption or message authentication transform that is employed (it may be an SRTP pre-defined transform or newly introduced according to Section 6 ), interoperable SRTP=20 implementations MUST use the SRTP key derivation to generate session keys. Once the key derivation rate is properly signaled at the start of the session, there is no need for extra communication between the parties that use SRTP key derivation. " Interpretation: Here i assume ('Properly signalled....') that it is mandatory to include the key derivation rate in the SRTP policy (even if a zero derivation rate is intended) >From 3.2.1 "an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", where an unspecified value is treated as zero. The constraint to be a power of 2 simplifies the session-key derivation=20 implementation, see Section 4.3 ."=20 =20 =20 =20 And somewhat further in the RFC:=20 =20 "8.2 Key Management parameters=20 The table below lists all SRTP parameters that key management can supply. For reference, it also provides a summary of the default and mandatory-to-support values for an SRTP implementation as described in Section 5 . " "key derivation rate 0 0" Interpretation: Here is coould assume that the default "mandatory-to-support" rate is Zero But 4.3.1 section suggestes that the signalling needs to be explicit via SRTP policy. =20 Also RFC3830 states that Section 6.10.1: "Note that if a Type/Value is not set, the default is used (according to SRTP's own criteria). Note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used)." =20 Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky formulation ? Is default handling used ? If yes what does properly signalled mean i.e. does=20 the sentence (Once the key derivation rate is properly signaled at the start of the session) overrule the default handling?=20 The cases i consider a) rate is not contained in the policy --> take Zero (default) value or case can not happen if explicit signalling is required (???) b) rate is contained in the policy (signalled explicitly) b1) contained in the set --> take the value as received b2) not contained in the set --> Take the Zero (default) value. =20 =20 Best Regards Marc =20 =20 =20 ------_=_NextPart_001_01C6ED4C.0F775CE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = AVT=20 subscribers
 
I have = a particular=20 point i would like to be clarify i.e.whether key derivation = rate (::=3D 0)=20 requires explicit signalling or not.
 
 
First quote from RFC3711
 
"4.3.1 Key Derivation = Algorithm=20

Regardless of the encryption or message authentication = transform=20 that is employed (it may be an SRTP pre-defined transform or newly = introduced=20 according to Section = 6), interoperable SRTP
implementations=20 MUST use the SRTP key derivation to generate session = keys.=20 Once the key derivation rate is properly signaled at the start of = the=20 session, there is no need for extra communication between the = parties=20 that use SRTP key derivation. "

Interpretation: Here i = assume  ('Properly signalled....') that it is = mandatory=20 to include the key derivation rate in the SRTP policy (even if = a zero=20 derivation rate is intended)

From = 3.2.1

"an integer in the set {1,2,4,...,2^24}, the=20 "key_derivation_rate", where an unspecified value is treated as=20 zero. The constraint to be a power of 2 simplifies the = session-key=20 derivation
implementation, see Section=20 4.3."=20
 =20
 
 
And somewhat = further in the=20 RFC:
 
"8.2 Key Management = parameters=20

The table below lists all SRTP parameters that key management can = supply. For=20 reference, it also provides a summary of the default and = mandatory-to-support=20 values for an SRTP implementation as described in Section = 5. "

"key derivation rate       =
          0                  0"
 
Interpretation: Here is coould assume that the default =
"mandatory-to-support" rate is =
Zero But 4.3.1 section suggestes that the signalling needs to be explicit via SRTP =
policy.
 
Also RFC3830 states that Section =
6.10.1:
"Note that if a Type/Value is not set, the default is =
used (according
   to SRTP's own criteria). Note also that, =
if "Session Encr. key
   length" is set, this should also =
be seen as the Master key length
   (otherwise, the SRTP =
default Master key length is used)."
 
Summary: =
Is section 4.3.1 RFC3711 'properly signalled' an unlucky formulation ? =
Is default handling used ? If yes what does properly signalled mean i.e. =
does 
the sentence (Once the key derivation rate is properly signaled at the =
start of the session) overrule the default handling? =

The cases i =
consider
a) rate is not =
contained in the policy --> take =
Zero (default) value or case can =
not happen if explicit signalling is required =
(???)
b) rate is contained in =
the policy (signalled explicitly)
     b1) contained in the =
set --> take the value as received
     b2) not contained =
in the set  --> Take the Zero (default) =
value.
 
 
Best Regards
Marc
 
 =
  ------_=_NextPart_001_01C6ED4C.0F775CE4-- --===============1425233248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============1425233248==-- From avt-bounces@ietf.org Thu Oct 12 09:55:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY10B-0007dF-Se; Thu, 12 Oct 2006 09:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY10A-0007d9-SQ for avt@ietf.org; Thu, 12 Oct 2006 09:53:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY108-00011L-Oo for avt@ietf.org; Thu, 12 Oct 2006 09:53:34 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2006 06:53:01 -0700 X-IronPort-AV: i="4.09,300,1157353200"; d="scan'208,217"; a="746951305:sNHT8243185732" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9CDr0kM023560; Thu, 12 Oct 2006 06:53:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9CDr0bF025548; Thu, 12 Oct 2006 06:53:00 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Oct 2006 06:53:00 -0700 Received: from [192.168.0.10] ([10.21.98.49]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 06:53:00 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <87DC8ABD-9301-4C9E-BA0E-B466345B1390@cisco.com> From: Mark Baugher Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling Date: Thu, 12 Oct 2006 06:52:53 -0700 To: "Blommaert, Marc" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Oct 2006 13:53:00.0234 (UTC) FILETIME=[BAC4BAA0:01C6EE05] DKIM-Signature: a=rsa-sha1; q=dns; l=13699; t=1160661180; x=1161525180; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20RFC3711/3830=20on=20Key=20derivation=20rate=20signalling =20; X=v=3Dcisco.com=3B=20h=3DzK30JPgd8Xdwbih41BFiFneU6PU=3D; b=F1LOrWm3dUJ00tIDlPavOm68Z+Hvg4+Pm0CWUTh+9UG5Fg/4nDxXhdD2GI+C3GVrxN9nkCpD 1FzXuFaBhk2F0UU/xVMyRD+St3NHl+EW3vF0qACSTWsCE8fo0y/6XEF2; Authentication-Results: sj-dkim-8.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 30 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1886135994==" Errors-To: avt-bounces@ietf.org --===============1886135994== Content-Type: multipart/alternative; boundary=Apple-Mail-73--182136030 --Apple-Mail-73--182136030 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Marc, On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote: > Dear AVT subscribers > > I have a particular point i would like to be clarify i.e.whether > key derivation rate (::= 0) requires explicit signalling or not. This is a matter for the key management and outside the scope of RFC 3711. Somehow keys get established and an SRTP cryptographic context is installed. The system that installs the keys has rules or policies for how it will handle default values. The two key management systems for SRTP that I'm familiar with will use a default if the particular value is not signaled. Generally speaking, it should be possible to install a master key and salt and allow everything else to default to the values of section 8.2 in RFC 3711. Mark > > > First quote from RFC3711 > > "4.3.1 Key Derivation Algorithm > Regardless of the encryption or message authentication transform > that is employed (it may be an SRTP pre-defined transform or newly > introduced according to Section 6), interoperable SRTP > implementations MUST use the SRTP key derivation to generate > session keys. Once the key derivation rate is properly signaled at > the start of the session, there is no need for extra communication > between the parties that use SRTP key derivation. " > > Interpretation: Here i assume ('Properly signalled....') that it > is mandatory to include the key derivation rate in the SRTP policy > (even if a zero derivation rate is intended) > > From 3.2.1 > > "an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", > where an unspecified value is treated as zero. The constraint to be > a power of 2 simplifies the session-key derivation > implementation, see Section 4.3." > > > > And somewhat further in the RFC: > > "8.2 Key Management parameters > The table below lists all SRTP parameters that key management can > supply. For reference, it also provides a summary of the default > and mandatory-to-support values for an SRTP implementation as > described in Section 5. " > > "key derivation rate 0 0" > Interpretation: Here is coould assume that the default "mandatory- > to-support" rate is Zero But 4.3.1 section suggestes that the > signalling needs to be explicit via SRTP policy. > > Also RFC3830 states that Section 6.10.1: > "Note that if a Type/Value is not set, the default is used (according > to SRTP's own criteria). Note also that, if "Session Encr. key > length" is set, this should also be seen as the Master key length > (otherwise, the SRTP default Master key length is used)." > > Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky > formulation ? Is default handling used ? If yes what does properly > signalled mean i.e. does > the sentence (Once the key derivation rate is properly signaled at > the start of the session) overrule the default handling? > The cases i consider > a) rate is not contained in the policy --> take Zero (default) > value or case can not happen if explicit signalling is required (???) > b) rate is contained in the policy (signalled explicitly) > b1) contained in the set --> take the value as received > b2) not contained in the set --> Take the Zero (default) value. > > > Best Regards > Marc > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt --Apple-Mail-73--182136030 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Marc,

On Oct = 11, 2006, at 8:43 AM, Blommaert, Marc wrote:

=
Dear AVT subscribers
=
=A0
I have a = particular point i would like to be clarify = i.e.whether=A0key derivation rate (::=3D 0) requires explicit = signalling or = not.

This is a matter for the key = management and outside the scope of RFC 3711.=A0 Somehow keys get = established and an SRTP cryptographic context is installed.=A0 The = system that installs the keys has rules or policies for how it will = handle default values.=A0 The two key management systems for SRTP that = I'm familiar with will use a default if the particular value is not = signaled.=A0 Generally speaking, it should be possible to install a = master key and salt and allow everything else to default to the values = of section 8.2 in RFC 3711.

Mark
=A0
=A0
First quote from = RFC3711
=
=A0
=
"4.3.1 Key Derivation = Algorithm

Regardless of the = encryption or message authentication transform that is employed (it may = be an SRTP pre-defined transform or newly introduced according to = Section 6), interoperable SRTP =
implementations MUST use the SRTP key derivation to = generate session keys. Once the key derivation rate is properly = signaled at the start of the session, there is no need for = extra communication between the parties that use SRTP key = derivation.=A0"

Interpretation:=A0Here i = assume=A0 ('Properly signalled....') = that it is mandatory to include the key derivation rate=A0in the = SRTP policy=A0(even if a zero derivation rate is = intended)

=46rom 3.2.1

"an integer in the set = {1,2,4,...,2^24}, the "key_derivation_rate", where an unspecified = value is treated as zero. The constraint to be a power of 2 = simplifies the session-key derivation
implementation, see Section 4.3." =
=A0
=A0
=
=A0
And somewhat further in = the RFC:
=A0
=
"8.2 Key Management parameters =

The table below lists all SRTP parameters that key = management can supply. For reference, it also provides a summary of the = default and mandatory-to-support values for an SRTP implementation as = described in Section = 5.=A0"

"key derivation rate               =
  0                  0"
Interpretation: Here is coould assume that the default =
"mandatory-to-support" rate is =
Zero But 4.3.1 section suggestes that the signalling needs to be explicit via =
SRTP policy.
=A0
Also RFC3830 states that Section =
6.10.1:
"Note that if a Type/Value is not set, the default is =
used (according
=A0=A0 to SRTP's own criteria). Note also that, if =
"Session Encr. key
=A0=A0 length" is set, this should also be seen as =
the Master key length
=A0=A0 (otherwise, the SRTP default Master key =
length is used)."
=A0
Summary: Is section 4.3.1 =
RFC3711 'properly signalled' an unlucky formulation ? Is default =
handling used ? If yes what does properly signalled mean i.e. does =

the sentence=A0(Once the key derivation rate is properly signaled at =
the start of the session) overrule the default handling? =

The cases i =
consider
a) rate is not =
contained in the policy --> take =
Zero (default) value or case =
can not happen if explicit signalling is required =
(???)
b) rate is =
contained in the policy=A0(signalled =
explicitly)
=A0=A0=A0=A0 b1) contained in the set --> take the value =
as received
=A0=A0=A0=A0 b2) not=A0contained in the set=A0=A0--> Take =
the Zero (default) value.
=A0
=A0
Best Regards
Marc
=A0
 =
=A0
Audio/Video Transport Working Group
=

= --Apple-Mail-73--182136030-- --===============1886135994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============1886135994==-- From avt-bounces@ietf.org Thu Oct 12 15:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5r6-0003wu-4o; Thu, 12 Oct 2006 15:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5r5-0003wj-5k for avt@ietf.org; Thu, 12 Oct 2006 15:04:31 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY5qy-0006z3-Vt for avt@ietf.org; Thu, 12 Oct 2006 15:04:31 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E49CDCB3; Thu, 12 Oct 2006 21:04:11 +0200 (CEST) Received: from esealmw111.eemea.ericsson.se ([130.100.184.156]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 21:04:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] RFC3711/3830 on Key derivation rate signalling Date: Thu, 12 Oct 2006 21:00:59 +0200 Message-ID: <877DEC6F4C0F574F8BB244ECCE32CBA80D0E02@esealmw111> In-Reply-To: <87DC8ABD-9301-4C9E-BA0E-B466345B1390@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC3711/3830 on Key derivation rate signalling Thread-Index: AcbuBnOaRCzdqOkZRJ6qbsuYZ7DOMAAKHdoA From: =?iso-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= To: "Mark Baugher" , "Blommaert, Marc" X-OriginalArrivalTime: 12 Oct 2006 19:04:11.0348 (UTC) FILETIME=[339EA140:01C6EE31] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0397280821==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============0397280821== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EE31.33AAACCC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EE31.33AAACCC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 =20 I agree Mark, but still one can ask why the key derivation rate is the = _only_ parameter for which we talk about being "properly signaled". = After all, there are many parameters for which we define a default, yet = for these we do not highlight the issue of "proper signaling". =20 I tried to search my memory from the spec. drafting days for a reason, = and here is my best guess: =20 The derivation rate is relevant for the key refresh mechanism. =20 If key derivation rate is zero (the default) the whole key refresh is = "bypassed" since only one initial derivation takes place (this is the = effect of the way we define DIVIDE-BY-ZERO). Thus, if one only supports = the default value, one can basically omit all the " DIV = " stuff and get a somewhat simpler implementation. = Thus, while the normative text indeed works for _any_ value of the = derivation rate (zero or nonzero), it is only when it is "properly" (=3D = non-default) signaled that one really needs to care about using the = parameter at all. =20 For all other SRTP-parameters, using the default values does not have = the same "function bypass" effect, and that is probably why their proper = signaling is not mentioned. =20 Perhaps it would have been better to say "...once derivation rate is = _explicitly_ signaled"... I don't know... =20 Anyway, this is my (probable) explanation for why we mentioned this in = the RFC. =20 /Mats ________________________________ From: Mark Baugher [mailto:mbaugher@cisco.com]=20 Sent: den 12 oktober 2006 15:53 To: Blommaert, Marc Cc: avt@ietf.org Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling=20 =09 =09 Marc,=20 On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote: Dear AVT subscribers =20 I have a particular point i would like to be clarify i.e.whether key = derivation rate (::=3D 0) requires explicit signalling or not. =09 This is a matter for the key management and outside the scope of RFC = 3711. Somehow keys get established and an SRTP cryptographic context is = installed. The system that installs the keys has rules or policies for = how it will handle default values. The two key management systems for = SRTP that I'm familiar with will use a default if the particular value = is not signaled. Generally speaking, it should be possible to install a = master key and salt and allow everything else to default to the values = of section 8.2 in RFC 3711. Mark =09 =09 =20 =20 First quote from RFC3711 =09 =20 =09 "4.3.1 Key Derivation Algorithm=20 Regardless of the encryption or message authentication transform that = is employed (it may be an SRTP pre-defined transform or newly introduced = according to Section 6 = ), interoperable SRTP=20 implementations MUST use the SRTP key derivation to generate session = keys. Once the key derivation rate is properly signaled at the start of = the session, there is no need for extra communication between the = parties that use SRTP key derivation. " Interpretation: Here i assume ('Properly signalled....') that it is = mandatory to include the key derivation rate in the SRTP policy (even if = a zero derivation rate is intended) From 3.2.1 =09 "an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", = where an unspecified value is treated as zero. The constraint to be a = power of 2 simplifies the session-key derivation=20 implementation, see Section 4.3 = ."=20 =20 =20 =09 =20 =09 And somewhat further in the RFC:=20 =20 =09 "8.2 Key Management parameters=20 The table below lists all SRTP parameters that key management can = supply. For reference, it also provides a summary of the default and = mandatory-to-support values for an SRTP implementation as described in = Section 5 . " =09 "key derivation rate 0 0" =09 Interpretation: Here is coould assume that the default = "mandatory-to-support" rate is Zero But 4.3.1 section suggestes that the = signalling needs to be explicit via SRTP policy. =20 =09 =09 =09 Also RFC3830 states that Section 6.10.1: "Note that if a Type/Value is not set, the default is used (according to SRTP's own criteria). Note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used)." =20 Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky = formulation ? Is default handling used ? If yes what does properly = signalled mean i.e. does=20 the sentence (Once the key derivation rate is properly signaled at the = start of the session) overrule the default handling?=20 The cases i consider =09 a) rate is not contained in the policy --> take Zero (default) value = or case can not happen if explicit signalling is required (???) b) rate is contained in the policy (signalled explicitly) b1) contained in the set --> take the value as received b2) not contained in the set --> Take the Zero (default) value. =20 =20 Best Regards Marc =20 =20 =20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C6EE31.33AAACCC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
 
I agree Mark, but still one can ask why the key = derivation=20 rate is the _only_ parameter for which we talk about being "properly = signaled".=20 After all, there are many parameters for which we define a = default, yet for=20 these we do not highlight the issue of "proper = signaling".
 
I tried to search my memory from the spec. = drafting=20 days for a reason, and here is my best guess:
 
The derivation rate is relevant for the key = refresh=20 mechanism.
 
If key derivation rate is zero (the default) = the whole=20 key refresh is "bypassed" since only one initial derivation takes = place=20 (this is the effect of the way we define DIVIDE-BY-ZERO). Thus, if one = only=20 supports the default value, one can basically omit all the=20 "<index> DIV <derivation_rate>" stuff and get a = somewhat=20 simpler implementation. Thus, while the normative text indeed works for = _any_=20 value of the derivation rate (zero or nonzero), it is only when it is = "properly"=20 (=3D non-default) signaled that one really needs to care about using the = parameter=20 at all.
 
For all other SRTP-parameters, using the = default values=20 does not have the same "function bypass" effect, and that is probably = why their=20 proper signaling is not mentioned.
 
Perhaps it would have been better to say = "...once=20 derivation rate is _explicitly_ signaled"... I don't = know...
 
Anyway, this is my (probable) explanation for = why=20 we mentioned this in the RFC.
 
/Mats

From: Mark Baugher = [mailto:mbaugher@cisco.com]=20
Sent: den 12 oktober 2006 15:53
To: Blommaert,=20 Marc
Cc: avt@ietf.org
Subject: Re: [AVT] = RFC3711/3830 on=20 Key derivation rate signalling

Marc,

On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote:
Dear AVT=20 subscribers
 
I = have a=20 particular point i would like to be clarify=20 i.e.whether key derivation rate (::=3D 0) requires explicit signalling = or=20 not.

This is a matter for = the key=20 management and outside the scope of RFC 3711.  Somehow keys get=20 established and an SRTP cryptographic context is installed.  The = system=20 that installs the keys has rules or policies for how it will handle = default=20 values.  The two key management systems for SRTP that I'm = familiar with=20 will use a default if the particular value is not signaled.  = Generally=20 speaking, it should be possible to install a master key and salt and = allow=20 everything else to default to the values of section 8.2 in RFC = 3711.

Mark
 
 
First quote from=20 RFC3711
 
"4.3.1 Key Derivation=20 Algorithm=20

Regardless of the encryption or message = authentication=20 transform that is employed (it may be an SRTP pre-defined transform = or newly=20 introduced according to Section=20 6), interoperable SRTP
implementations = MUST use the SRTP key derivation to generate = session keys.=20 Once the key derivation rate is properly signaled at the = start of the=20 session, there is no need for extra communication between = the=20 parties that use SRTP key derivation. "

Interpretation: Here i=20 assume  ('Properly = signalled....')=20 that it is mandatory to include the key derivation = rate in the=20 SRTP policy (even if a zero derivation rate is=20 intended)

From=20 3.2.1

"an integer in the set {1,2,4,...,2^24}, the=20 "key_derivation_rate", where an unspecified value is treated = as=20 zero. The constraint to be a power of 2 simplifies the = session-key=20 derivation
implementation, see Section=20 4.3."=20
 =20
 
 
And somewhat = further in the=20 RFC:
 
"8.2 Key Management = parameters=20

The table below lists all SRTP parameters that key management can = supply.=20 For reference, it also provides a summary of the default and=20 mandatory-to-support values for an SRTP implementation as described = in Section=20 5. "

"key derivation rate   =
              0                  0"
 
Interpretation: Here is coould assume that the default =
"mandatory-to-support" rate is =
Zero But 4.3.1 section suggestes that the signalling needs to be explicit via SRTP =
policy.
 
Also RFC3830 states that Section =
6.10.1:
"Note that if a Type/Value is not set, the default is =
used (according
   to SRTP's own criteria). Note also that, =
if "Session Encr. key
   length" is set, this should also =
be seen as the Master key length
   (otherwise, the SRTP =
default Master key length is used)."
 
Summary: =
Is section 4.3.1 RFC3711 'properly signalled' an unlucky formulation ? =
Is default handling used ? If yes what does properly signalled mean i.e. =
does 
the sentence (Once the key derivation rate is properly signaled at the =
start of the session) overrule the default handling? =

The cases i =
consider
a) rate is not =
contained in the policy --> take =
Zero (default) value or case can =
not happen if explicit signalling is required =
(???)
b) rate is contained in =
the policy (signalled explicitly)
     b1) contained in the =
set --> take the value as received
     b2) not contained =
in the set  --> Take the Zero (default) =
value.
 
 
Best Regards
Marc
 
 =
 
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org= /mailman/listinfo/avt

= ------_=_NextPart_001_01C6EE31.33AAACCC-- --===============0397280821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0397280821==-- From ctiksmhoxe@utahhomes.com Thu Oct 12 23:23:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYDds-0004XF-Qs for avt-archive@lists.ietf.org; Thu, 12 Oct 2006 23:23:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYDds-0002x9-ML for avt-archive@lists.ietf.org; Thu, 12 Oct 2006 23:23:24 -0400 Received: from [190.55.11.77] (helo=[190.55.11.77]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GYDdg-0008Qv-So for avt-archive@lists.ietf.org; Thu, 12 Oct 2006 23:23:24 -0400 Message-ID: <000d01c6ee76$e110bd00$4d0b37be@skynet03> From: "you thorough" To: avt-archive@lists.ietf.org Subject: you thorough tips Cheats Date: Fri, 13 Oct 2006 00:22:57 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6EE5D.BBC1FE60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.8 (+++) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec ------=_NextPart_000_0009_01C6EE5D.BBC1FE60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6EE5D.BBC38500" ------=_NextPart_001_000A_01C6EE5D.BBC38500 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Your then displays reenter screen press Select button followed or by =20 This or delete memory of! Then displays of reenter screen is press Select am button followed by =20 This delete in memory Your new or password asked. Code About gt Experts Search Experts to one of thousands questions. Memory or Your new or password asked confirm in After allowed parental =20 control menu doesnt work know add in. Play reveiw is test Average seven hours am video playstion twoheck its =20 am job awards. Any More how Might is be Able a get System in let me am Watch Dvds Again =20 am so Thanks Vickie invalid is! Games Action in sim games am have been expert gamming last years which =20 will allow give you thorough tips in Cheats is. Gamming last years of which will or allow give of you thorough tips a =20 Cheats Gameshark codes am anygame a ps. For from Rpgs or Strategy games Action sim games or have is been expert =20 gamming am last a years. Try my best play reveiw is test is Average seven hours video playstion =20 twoheck its job am awards Gold. Doesnt work know add Answer Rate was in helpful not of Email page a =20 Advertise Site! You thorough tips or Cheats Gameshark or codes anygame ps Feel free or =20 ask Xbox Gamecube well shall is try is my am. Thorough tips Cheats Gameshark codes anygame or ps Feel free ask Xbox =20 am? Action sim games have a been expert gamming last years which will am =20 allow is give or you thorough or tips am Cheats. Control menu doesnt am work or know add Answer Rate was helpful not or. Answer Rate was helpful not Email page is Advertise Site User Agreement =20 Privacy ------=_NextPart_001_000A_01C6EE5D.BBC38500 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Your then displays reenter screen press = Select=20 button followed or by This or delete memory of!
Then displays of = reenter=20 screen is press Select am button followed by This delete in memory Your = new or=20 password asked.
Code About gt Experts Search Experts to one of = thousands=20 questions.
3D""
Memory or Your new or password asked = confirm in=20 After allowed parental control menu doesnt work know add in.
Play = reveiw is=20 test Average seven hours am video playstion twoheck its am job = awards.
Any=20 More how Might is be Able a get System in let me am Watch Dvds Again am = so=20 Thanks Vickie invalid is!
Games Action in sim games am have been = expert=20 gamming last years which will allow give you thorough tips in Cheats=20 is.
Gamming last years of which will or allow give of you thorough = tips a=20 Cheats Gameshark codes am anygame a ps.
For from Rpgs or Strategy = games=20 Action sim games or have is been expert gamming am last a years.
Try = my best=20 play reveiw is test is Average seven hours video playstion twoheck its = job am=20 awards Gold.
Doesnt work know add Answer Rate was in helpful not of = Email=20 page a Advertise Site!
You thorough tips or Cheats Gameshark or codes = anygame=20 ps Feel free or ask Xbox Gamecube well shall is try is my = am.
Thorough tips=20 Cheats Gameshark codes anygame or ps Feel free ask Xbox am?
Action = sim games=20 have a been expert gamming last years which will am allow is give or you = thorough or tips am Cheats.
Control menu doesnt am work or know add = Answer=20 Rate was helpful not or.
Answer Rate was helpful not Email page is = Advertise=20 Site User Agreement Privacy a Policy am Help=20 Copyright?
------=_NextPart_001_000A_01C6EE5D.BBC38500-- ------=_NextPart_000_0009_01C6EE5D.BBC1FE60 Content-Type: image/gif; name="parental.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6ee76$e10f3660$4d0b37be@skynet03> R0lGODlhqAGwAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAPAAAALAAAAACoAbABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnVtzCN27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3i0SAu/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEJYEg0fzRKgXDBhaeFmGGnbo4Ycghiga IiJORmKJkZ2I4mMqrthYiy4uBmOMic1I42E23lhYjjr26OOPxZ0BZGJCDnlYkUYWhmSSgy0J VjxMeuRklH9NSeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMYp55x01mnnnXjm qeeefPbp55+ABirooIQWauihiCaq6KKMNuroo5rpAulRkk5aVKWWDoVppkFtyulPng7lj6Oh fspTqabqhGqqrLbq6qv/sMYq66weXkLrrbjmqit3r+zq66/ABivssMQWa+yxyCar7LLMNuvs s9BGK+201FZr7bXYZqvtttx26+234IYr7rjklmvuueimq+667Lbr7rvwxivvvPTWa++9+Oar 77789uvvvwAHLPDABBds8MEIJ6zwwgw37PDDEEcs8cQUV2zxxRhnrHGwrbjbscfvftyuyBuX bPLJKKes8spWFeOuyy+/C3O7M7Nb87o3s8ydLDr/JkPPQAct9NBEF2300Uhb1MPAB7jbtNPv Pj1eGUlXbfXVWGet9dZcd+3112CHLfbYZJdt9tlop6322my37fbbcMct99x0XxfJaTewe0Pe a+vy3Xe7fqsbeLqDo1t43YgnrvjijDfu+OOQRy755JRXbvnlla2D+eacd+55cCp8LvropJdu +umop6766qxHSUDrsPvqwLuzu1t7uw7czq7usffu++/ABy/88MQXb/zxyCev/PLMN+985QEB ACH5BABIywAALAAAAACoAbABBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mix o8ePIEOKHEmypMmTKFOqXMmypcuXMGPKFBggQMGaNf/hxKnTJsKdNIHe9EkwZ0+hRnsetZlU Z1CeBncabUo0aFGmUKVaHdhU6VapPrsmzdlVKditM9OqXcu1KlqvcA9OreoW6tO4ZInOvUsT 79CrR7n+bfuVLt66erECFps4cFvFg9lKntyyLNXGCfcKvjo372LMnQVTjWx2LGnNoy9H9kyY ceusPC27pUy7dkjZgN9GDTu76FLFqksTdjo17u7FXhHn1pxbt/DDxscy/f28ue3r2DXiHm58 tVDfjln+F4Zb3Gxy162tIj57/i5Y3MyroyXLNy/S3tnz62+4fT5+59FtJt9e0vVlXoHW0Wde grz5B91f8YnnoF6vHbffhRgq1B95/yVnnVPHBefYV49xeNp0fHHXnokicqaihCzKBVmGNNb4 02wilrXch71JKB1dYZWI4IsojvgWao21WOKRM04oY3c62iilbWd996NdT/GGpYGDsZciUEBm KRtSPIZ5H5hh7gbkmbBl9SR7UU4p55x01mnnnXjmqeeefPbp55+ABirooIQWauihiCaq6KKM Nuroo5BGKml2AwxQUKWV/oMppppaitCmAm3q6aWgdgqqqJaiamqqo2oaaqn/BKn6Kqydxirq QJnWamupspLK6ay/7spprq+uSuyxrRrLqq3K+hpss8Dmequuk2pELK6tIquQtNmSGiu1zIZb rKm4gpustuBii66u3B60brrXLoutu6PGKy+79SY7rrn3GoSuvfzCq2+1FV27L7UGe2uuwqGm e3DA5DYcL8Pt+hsswBVTnO253QJs8bzz/psvvSAXm3DJGdeKMccEW6uvxw6He3LJNNfssbz9 fjxuwhXf/Ky4MD8MscbMilzzvisnZHTIGwvcckY8Ny000LTunGmvBt9sMr4cwyprz1JXjbLU IA9LNtWqYj2yzspePa26Fze98q8zPw1R1FRvO3DW/iOfzLfMW7+r8tlWHyx43jb3TTjScvd7 OMKNK+145EwzbDdFeI+td8OJV8624Z7me+/fkDt7Ktl1v0v64OIibnLoa8eses4yx86655dv lDnjm7va+eskty6tuqUjvvrtQ7MddOnL8457xn7b7rbkZVMOfOu5R5R23HDzze3P0bLqNcvA +m511XObXfTbU4MuNrS9Eo071zPPDi3N38fNK/nZ9+///wAMoAAHSMACGvCACEygAhcoKTkw UE/bmMk0HkjBClrwgmn5wAcGskGBaJAgH+SgBkfowRF2MIQlLAgKS/hBE7awgwhxoQhNqEIY /sOFNgShDG9owxzKEIcz/twgEGuowxTWkIYsDOEQl7hDIA4xhj1EIg8xGBElWjGIRDSiB6co wiwWsYtaNMgKhRhFLGpxhWF8IQx9WMYznnCNUUThFb+YwjGCkYt1hCMe3XgQKbYRjXmywX6s +EYz3tGOY2SjGNu4Ry/ecI9yJCEfHalGDlJSj0ZMpCHneMcp2nGSeewiGiOZEEBmModUXIgS H8lFTuIRkJqkYydJCcVFfnGOtJRlC1t5yUMWEoyclOIsyVjLNBIzlHQ0ZRhvicpUKoSGfvwl KIMozEZCEpNQlGQscbnDXhaSjSR8Yiv/KM1qXtOa01SjNn/YzT6CE5vOZAg0JTnOZKIylp00 /2Y+S3nMU/pTmZr8pjcVec567vOcAIXnC0WpSGUe1KDxlGc41/nEXD4Sn8ssKDq3yNAi4nCh 6AzoDHtZ0IB+9KAmBaEvParHUUrTncWMKERyiU+L9rORsGSkQ8uY0o5mVKQsJOkry/lSiw4T kiv1qScJutFXMlOmDaGpTuPoSpfOU6rm7CYTWSrLJK4ynxhVJw+jac9s0rOdiUQiE+fZ1bFS 1KhQjatc50rXutr1rnjNq173yte++vWvgA2sYAdL2MIa9rCITaxiF8vYxjr2sZCNrGQnS9nK WvaymM2sZjfL2c569rOgDa1oR0va0pr2tKhNrWpXy9rWuva1sI2tbP5nS9va2va2uM2tbnfL 2976lq4EaEhw6TTcBALguMetUXEJQoDm/sO5Agluc6f73IRMt7jUjS52pZvd5XKXutf9rnez q13uDmS70D0vc9OLXYqQN7znJW901yte6SLkuvPN73ILmNwp7Ve9z21vfqt7kP8KmL32na93 AUxgBg/3vwBm74ANImACVxgiF17wfQui4QZzWL0PZrAB+0sQ5AJAICY+MXJRbOKBtPgfKWax jEns3g1XN8QDhrCBP2zfHoOYuQ7+sH6tq+Ai29jDN3Yufstr5Ak3+MIRFnKOj+xjIB+QxjA+ cZa3zOXk9hfLXtZymGes5YpA2MJonjKF1/4MZB8n+MZWfnJ3HZzeKIf4zE/mcZDbW2ckV1jH Tu7wmfm84yuXWcZb/rKYVbxoFq9Y0Y4+9EUGPeQ/F5jNP0bzkgUt4gD3OdCVRnKc9/tmQoMX 02oWdZwnDOX4QvfTeP4fmBsN6UTT+taIfnFBNDERSms6yKgGNY7fzGpgRznYw4YzlfU8ZVIj 29iXXnWrhS1l/koa0rUes63JjGgue/sfvI6Ir7cL7VWr2dnONna6RZ1ucqvawwfec6al3GF2 g7rcOD62kwkY4yxn+9YrjjSju01iLIf7IUtmsrvlDOv3SrjNFJYvepXcZvl6Ws6uXvfF45vn jQ+6z6Ses6e/S//nV987zXfF8kNU7sxY78nlEWV5Q2SeSpjfyea/zbnOd87zPpWg50DPK81d LOmgx7XfERl6t02Sj3wQpOlN/wfUoS51pxvdT0pnSNaz3pGoP93qAvF61a+O9WsDPMyLDri/ cV0SsYcd7GN/O9n71G9sN3rbeB8z1zPi9rjL/e9z31PdA/7vLg8c7yfpu9vF3vfA60nRhc/7 4bWdeLj73e+NdzyeCl7mwtud23vHiOLhznjLa55OSPe253X9YsqPZOpOn/pASk/10/Mp9LYn LO5zz/ve+/73wA++8C24e4UUXyRFR0jyW7L8pF+k+axN8eEnEuPjh+TaB4G+i4m+feX+b73F 2k9IwSnSedtynvxmn0nrk4/9gnwZxfDPfvcXUn7q118i958t5wmP60PPOtJEB3l3lxEq5n4G UXTYJ2bwt3wJqHYlFoAKuIAwZoATWIH8t3/zV4H613lsh3b+l36fx32IhxEF+IAUaILxx4Hx d4AGmH8rWH4wiIApqIElOIH1539/4gf8poKS921L14Prp2sc4YAyKHAe2H5g1oIZ+ILbB4Py Z4E0GIV1h4KydX5AiIAgeHfgF34kGIUnuIQr2IRhmIBgeH81WIMQ6GVSKIZfyIWoZYXa5no/ GIcf6IPWJ35eSIVhuIQR2H5QuId5eIYamIEF6IQSCIiDGFv/cJh2cihwhieAaeiDFsF6KueH esiD7jd+gGiGAFiEh0h43ad2Ljh8McGFbggop0iKJuGGqXh7qviKsBiLsjiLtOhMdzgZrViL aZF6B5iL0rcRt8iHkaiLasF11heMvUiC/AeGmcUJAzR0gxd5JfaB2OaIa9eJvpiIo0iM6ueA Ivh/tTaN2cdodGh4qpeNfiiE3LiL5Dh5jMiI4ziNj8aDRzh9FUGET7iO7JiMPXiN/GiOi2iH uSh/2ziQ+ugR4fiN7iiC/xiCAJl+P7hygciMB6kS6jiMSCdzNFZ91CiAaSeJWieKGFiRUoKM /wgSBkmS+2GSADgSKamSMBmTsjgL/zIZT7NwkziJkzW5kzwJQLwIjFjojZnIkB2hCkZplP+A lB9xlErZkxGJkFj4lFLJEU0pEFVJlapglVnplAIJeonWktFYh+cIiUcYiXt3lUyZlFm5lWmp lkc5EEy5lVo5l0qJlHUpl8T4f7bmgQ/JbUMpiZRXjg65EHE5l1ppl2y5lomploZ5mHdJl4u5 jnoZmBy4hX4pjxtpmX5ZjhFRmE35mYv5mI8Jl6EZmW0pmRBJmUTZl0MZkOcXgneImKQ5m4wp mpFpmLLJmG6Jl3mZmtNnhQoJmFrIdld4mQ+Rm7qpm7m5nHhpm415ldwYlr/ZkQvpb+KYa0HY jxzpEIV5mP/JuZu4mZhvSZrjuZtyCZ1ciR0sqRHoyRDtmZ6UcZEscZqdyZvweZ/4mZ/6uZ/8 2Z/++Z8AGqACOqAEWqAGeqAImqAucQIKKkAM2qAA9KDZ8QAQ+j8PQKG2h3OBdaEV2j8c2qHZ g6EgOqIkWqImeqJ7EgUoajcquqIt06IuWi0wGqM0WqM2eqM4mqMQwQ/8oKN4wqM9uqNByhA8 6qP5AaQRUaRGSidFqqRAqqT/8KQC0aRB6qRIaqVUuqRqkaVRWqVDOqU9yqVcCqZdShBQqqUx IaZeCqZX6qVYuqZSiqZb+qRqWqZl+qYDIaV4KqczAaV1aqV2Gqh5GqZfOqZ9wKf/LOGnhEqm XdqmgzqogBqnZ4qoGDKplOonlnqpmrqpnNqpniopqfiSLqmpOGh8EJGO8tmJQ0iqesiCDrF+ FHmJq3qpOEiJkHeIuMqEX6iNaviR/vir/miIiYiitcqGNtiEZIiCrNeLEdhlxiqI8yeI22ii xYqr7YiGAdiqw8qCnGitebiGMyiqBFqtx5qr21qu2xp+0Aqu6Fqq7WquK0qu0mqsSqirf0iQ 0fqs3yqs00qsoJiCF7iJIlmZfCiSg/ivFkiEA9uvn+qqMtGK4oqoEauM2diwFnuxGJuxGrur o5oS2DqiQol/8pit3reaDvuqMxeyH9uhDBuSauit8TiV/4hoqvRXsxObn8masApIrg94g0pY ggvraJ94q9bZqqB4s/iZs9Kas6HYtD17rPwqhTLYrSTrhEh7n0iosy+bie46rX3Irtd6sI82 jNwKfufaoFnbrDMLtMqqfOGqr+morzZbrwoBCgeaf5zIgOiqq5b4rlGbt/mKrxJ4tUmbhFXL rO8otHuIhPvnqx2JnWY3kitLqxtrJ4RbuZibuZq7uZzbuZ77uaAbuqI7uqRbuqZ7uqibuqq7 uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7zbu6eFpGyqqMCrqI0KvIwavMU7pqlrvJE6pGNK vAUxqWcKvcu7qHb6vNYbqJYqvf+F6rzdW7pqOrzeq73jG71fKqjUK6ihW6d3Or7Uu73nO73l i7p0+qfuO7/wa75mOr+nS7zN+6jve77qK7+PWsCi679xmryQSsDm26YB7Ki+G8ESPMEUXMEW nHPad7l5osEYwsESWRJ663ylmKofjIexqrhFm8Ihi4gqS4AnbMKYCYz3uJ5aBxPQd7N664lP S7MkgcM1i7LeGrX5yLEzK8L3SMRdeMQn4cFA7LYaEcIni8QvLMNcy4S26qvA2o54KMQUGcLZ WbSFOLBC67hifLDj+JGQKLWOq7MUaKve935YbLYAG8caSZk7+4cBm8KKe8VcC7RoB7XBiqx0 HLHVB7f/hgyziGyCXHy2Xiy3NggASfCtfuvIueqJbDvJiDx5TiysTvzIVnzIn0yzauvJ5brI gvuu+YqG9Ai2E4m0cfu3gry18uqwXHzDm/yscuyFuTyvc6zKtIzHrFyZssx+oQzD68rLe7ud JtyHY0twu8x+zYzKn6yJwYzL80jFqQzK2Iq3kty1uvzDrmrKgBvE2mzGJ3jJyLyui5u18HrO rQzK6drImFzKu7qR5ZzNM4bP8wzNLty2sEzOY7iv7szJi3vLmfzOAL3P2jjQb5vQBL3Q7FrQ B/3P9nqvM6jQ80yI91zM0pzOEznFM8esEKjLeZzF+/rFYNx6fTyyN7jGfLuM/y6ttcP6xV/L x4/4grMGrQgLliMLlnlc0uwMj3n7mpUYzfAYw+TIfTHYuJCLwo7CxNkB1dTHElJtWVV9HVd9 qiuR1Rfc1V791UFnik/M1U/csUr8EVmtrswnGWRNfkRMyB0c0is90hMNzvYnlGLdzzx8tmgN w7/c17aR188X1zXszun60XZtxBKd2Gft12nt11KMzbSh0td4kW4MtUQbxtN51Cl9w2lsiBeI xRHttGto0//KzH6stmSc2Wn8xoMMhT+9wsAMxvRsnbGd2i3Z0zZdtXBM0neMzYVIycHcrDF4 0UprzudK0cGd0Prsz/Ss3MDMs8jt0MKtz75M3NVt3P9S+4na6tFey8oavYDYXdyzCshBLMtr d8xyi9rInN6d7N3u/dCUzdBsC93B/ZsQ3cvgLc0DrZmqZ91ue9+4zJCPC91ITcmNe92OSLhW K9wETbU6Td3uaszV/MpRTMyDC9vlLOD5bInwXcxQvLK9aq/q/LTLndHoLeHhjdHi6OEWzddu neGJXM0k/s0K7c35Dd8UXYYnO84Y7YK4bcYGjsoWHtC/Dd6WDOJGDuCLPOQ7vLcIXd6pXeKX jbfvp92VHYpEO9OtLccIO4DxvLU13tJbTubCqMjzuIicHZSrbcWrPYpmeOU0aLDBGuRAbtS5 rcJyPoZ7voqMzRYZvNYv8ZP/nVzY2oqQUXx0W1cbak3VK1nCRdwRfQvWlF7plm6jba3XKIno cl2KNpLpGULIuZyyNBzj11fWkX7opj7Vk1jeil0tPpzqqr7VZj3Ysn7rkC6yrS7ZWr3BrO2O cp7UtC3atFzGzBiwXf7ZBYvaTh3Ig6zTZZ6ZWtzsa3zUYuyNoU3XY0yw2x65v3rt0c7LR/vp zq3h1C3et+7jEx7KR37c3+3LAY3uNJ7M9Bq4/N2ASr7udKvONU2vOrzjxOzN+E7u+NzuYPvM hr7U9szQ5i7TPsvmpCzQdc3cyty24o2PWe7m18zCeM7NDY/ff6nGYl7g5T7qNCLwDc3i68zD D72J/2xo8EK8zQIhAWfI74784Rxv8VC+0SL+sU7e7zid3O2N3Jzc4O18ISj/8fvt8ywM4LLK 3Tdu781t8xOP4ise5bOs7k/O5OFt8PX+5O3t46X99aGe2eEatDc95wUZuCr702fP1FR74MbO 0yRb57/e7F85x20czXaPwjkN7QvP7Hqu28a+jH2f8Sb/J6COfLrO63Ky+JpeQZC/6a+exI9f 6rR+6Zq/+Zw/i+KK+UO8i03M+JA9+qVvf7g4+aFu65Xf6ZQvso1e69z66hi+62wN0o0iqlfN xAbJiiBsqhDr+qu+Fi2rH1XOxp3N7dDc253t97f65odL+Ghs7YK8x7z6sv9pLvhmLv3C7Nxj S+yBXNnYXsaabf1JLbnkX9Rt3szaj/wPC7eq7eCHLe+1PN0evfVJD/M3b4dimPTwfMoAAeCf wH8DCxYkaFBgQgAJDzo0iFDhw4gVKy6k2FDiRoUEPXKUyNCiSIolJ3L8aLEjyoMtXb6EGVOm TJENbV4keTKiTYwva5rsOZCn0Ic/Q5Yc6lBpxo1BneK8CfHiSpYeb57U6DMqU5A/cwrVuPWo 0ZEZkwLlurOpWJ1gsyLM+XTsTrY8pc7EmzcvWZBEyT69+zdtYIYYBfNdelTtYZN9pxZ+PLXt 28iKy85l2dfr4JZ8JVdWqxNw55lhOc8d7Vjvatb+MBm7TC1aZVW0cUkzfT35NlbLsT2Dli13 duLgjTdnVnlcdu3ToFP6vjy7eFekzVO2xq53KNzrV8FmPqs1q9Lxnceff15+rWnzVp+H9L4d veqzV+Vzj0sZv+TtRdmz32+3nsIbKT71Cuyuqf1Isk8/A68j6jMCv1MtOwt3uzDDCjXksMMN PXRttbtAJBGvET8sMUUVS1sRuxNbDBBGGVmcETYRa2zRu5hexLHHDHn0MUghhySySCOPRDJJ JZdkskknn4QySimnpLJKK6/EMkstt+SySy+/vPFCILWzcEwMwUQzTTVnDOxHD4kz0UUy16Sz TjtbMzPEDuGkkbU87wT+NNAp+7NvIvkeVKxQCv2LsT8KET30LUUfHFBS/QTFNFMZD/sot4Wk MixOwdCyzLnIGPtNU1VXJbEmAqGzC0HDCANQOKgANFW50WK9lFVff5Wz1FzTQs4p4qAj1TjO dD3VtT+BhdZXT4ftjdhjTU02KGoNXfaz0KIFN1y3GH1MUbogrO/SV2OEiztGR53U0v/mQ1Fc ewN99llV9b23332DvVdHfwcmuGCDD0Y4YYUXZrhhhx+GOGKJJ6a4YosvxjhjjTfmuGOPPwY5 ZJFHJrlkk09GOWWVV2a5ZZdfhjlmmWemuWabb8Y5Z5135rlnn38GOmihhya6aKOPRjpppZf+ Zrppp5+GOmqpp6a6aquvxjprrbfm2sdvugZb5E7CBhYSSEweO2Kz1z7b7IPcZvvst9kuKO65 166b7n/sdjvvvfX+G++75ba7pcL73vtvw+XOG26+GXep8MDnflvxuCFf4PLGEV+cccTbJhx0 vy33HHS8JZc88L4/N13w0UkXnHO1S6dc9tEdvx1y2XenffXQY/Id+N5XV5zyxY9/HfnIWSe8 eOeNV95212MvHvfqRfeb8+CfN95656UfPnvIZ4fee+St3z557lm/Xv3uxy+/9cS1H59+6JWv PXS4XwKfNPaP993+VJc78eXvfL/j3+/+x73vYc9snbDdw5hHt9T+BW97j4ud3th3QcDlznWv 2x8FdVe/Ed7PhKSr2wCXl8B2NXCFxNPg9EQXQBGeDoEVjGH8WFhAFFJsgeYbnP4WuDkhYg92 Q4xeBzfYuOfxLokw6R/xJrfC5TXEhiZEHxOTd7n0mQ918GvfD+G3wRz6kHY8pKIB3ac+7+EO iSe0X/bUyMYSrpF3fIPjGMO3Rc2dsYkBBKERe8jAMPqxf2hco8PESEgntg+KJHQhB4W3w0Am rnKU5OMJ19c7w2FyIGS83xIvuclKIlKSO2yjH3UYwYotEodpdJwNMyjDDObvgzUEH/UqRz9Z GrKDqjOiAFOYxohoDpiwbFsn6VjKIwb/s3UjpGUcl1dL/JHNmtfEZja1uU1udtOb3wRnOMU5 zi31cXg0JCE156fEG8pPmp2b4DMH+Ll5YtCLCKwkLqUZyyI6k4iEFOciHUnJWKYwgqdMHyPb WU1AWnKfdSSgDv9I0IUik5TkfGJEWUnGEIIRofhU6BwvSsFMlnRwFp0oShOaT0hiNH6HK6JF 3flLN57xnavU5+1U+NArwnOaZXQfFyMKz16CFKMCjecT9QdQLtoUokp9avW0+NBqMvB/N3Wh I3t6va26FKl6VKpIO6fFgYbUlC11akaDCtahWjWtkVTlIL3qy7WGdZdgbGtCD1rRZVpymFTN I0VNKtEu+rOq/nPFKT/1qEuD/nKgOcVhNAVJ0ruKsaiBFd8bOdpPuKrTpZ8FbWhFO1rSlta0 p0Vt1xKQWtYSTbJBxKQ+BRnEmB7wn53N5R1hO9bbJtCQx6RiYUsXw63y8pnQvCxvgbvc29IT tl+8Y1KNiT+gdkmGGm1pKOOq1jimEq595eX7lLtSslJvpaecokTVO9iMhhe7j7TlMEuKRFB6 srwKxOuV0LfHlGpXk8yMLkvV2Mj6XtWBRu0hSYf40f428qKJNPCA+QtVYaaUvhP+714Bql/R waK+/TUpK7O6ycJ+d6R7NNsiCIjeAdcTizOc8IVTB+L2ovicVJXfc/HpYCBCOJ2J/uTw32Bh YhoDFr7MVK93Z8zc/f5DxRas7QubNzkZf7HB2XUwU4drvxJrWI7p/eMtsTxbH8NXxFUS6odv amTB1lXABYzilnu6CMXW1LeUHaRupyhUJI+YvTilrT+9bDn/ipTHZNaymfOLZhu39cF+Rqlb Ac1DAu/4wG8+tF/XaUdLJ3nMxNzoWwuM4Egqc75x/fBhs3rmIGc2qT/NcQM/yMdZ0/rVC+av Yid9ZU3L88gCDbN3T1rmNzdzt7vVHXVvDOtj73WCQG5ttKU9bWpX29rXxna2tb1tbnfb298G d7jFPW5yl9vc50Z3utW9bna3293vhne85T1vete7aAEBACH5BAANAAAALAAAAACoAbABBwj+ AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqnXhgqdOnUKNKnUq1qtWrWLNq3cq1q9ev YMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePH kCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnh33Be3buHPr3s27t+/f wIMLH068uPHjyJMrX868ufPn0KNLT2tn+tRc1rMXxK69O/fu2b/+g89J6LL48dHPo3+uvrsn T+zXy59Pv779+/jz69/Pv7///wAGKOCABBZo4IEIJqjggv9UwOCDEEYo4YQUVmjhhRhmqOGG HHbo4YcghijiiCSWaOKJKKYYUhgqtujiizDGKOOMNNZo44045qjjjjz26OOPQAYp5JBEFmnk kUgmqeSSTDbp5JNQRinllFRWaeWVWGap5ZZcdunll2CGKeaYZB5oQolzlBlWmmp+xWabcOb4 ZpxazUknVnbeaVWeelLFZ59S/QnooIQWauihiCaq6KIkQsLoo5BGSpwvklZq6aWYZqrpppx2 6umnoIYq6qiklmrqqaimquqqrAa3RKv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yx yCar7LLMNuvss9BGK+201FZr7bXYZqvtttx26+234IYr7rjklmvuuegeV42363bbLrfvbhtv uvTWa++9+Oar77789uvvvwAHLPDABM+IT8EIJ6zwwgw37PDDEEcs8cSYnfCtxd5iTPHGHHfs 8ccghyzyyCSXbPLJKKes8sost+zyyzDHLPPMNNcs1Q6HJWHzzjz37PPPQAct9NBEF2300Ugn rfTScmUDrtNMRy311FRXbfXVWGet9dZcd53bD16HLfbYZJdt9tlop6322my37fbbcMct99x0 12333XjnrffeSnz37fffgAcuuE5kDG744YgnrvjijDfu+OOQRy755JRXbvnlHoXirebdcn6a gxl6jhroFoo+Orikc5u66pi37vrrsMcu++y0HxoQACH5BAAWAAAALAAAAACoAbABBwj+AP8J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPK nEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4seOC8h5L nky5suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIML H068uPHjyJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz5yerOq1/Pvr379/Dj y59Pv779+/jz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRiWxk2Gk23I oWQefthYiCIuRmJDofy2DXYnlohYiy7GKOOMNNZo44045qjjjjz26OOPQAYp5JBEFmnkkUgm qeSSTDbp5JNQRinllFRWaaVgzFxpVpZadunll2CGKeaYR85D5plopqnmmmy26eabcMYp55x0 1mknKHY6BQqeefbp55+ABipokaMMauihiKr5R6KMNuroo5BGKumklFY61hSWzjTFppnGxGmn MH0KqkuijmrqqaimquqqrLY6oyL/rsYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar 7LLMNuvss9BGK+201FZr7bXYZqvtttx26+234IYr7rjklmvuueimqy6TMqzr7rvwxivvvPTW a++9+Oar77789uvvvwAHLPDABBds8MEIJ6zwwhM98oi2DkP8cLYTM2zxxRhnrPHGHNM1Qccg h9wbISKXbPLJfbWDrcrXsmyty9XCjPLMNNds880456zzzjz37PPPQAct9NACn6Kt0dginfTR TGer9G/3rPe0tVNXWzXRWGet9dZcd+3112CHLfbYZJdt9tlop6322my37fbbcMct99x01233 3Xjnrbe9SfRQS8/ff9snzt6EF2744YgnrvjijDfu+OOQRy755JRXbvnlmGeu+eacd+7556CH LpsEp8EDj+iop6766qy37vrrsIfXR+yPBwQAIfkEAA4AAAAsAAAAAKgBsAEHCP4A/wkcSLCg wYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as 2bNo06pdy7at27dw48qdS7eu3bt48+rdy7evxnN+AwseTLiw4cOIEytezLix48eQI0ueTLmy 5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ueTbu27du4c+vezbu379/AgwsfTry4 8ePIkytfzry5c6cdnkufTr269evYs2vfzr279+/gw/6LH0++vPnz6NOrX8++vfv38OPLn0+/ vv37U13g38+/v///AAYo4IAEFmjggQgmqOCCDDbo4IMQRijhhBRWaOGFGGao4YYcdujhhyCG KOKIJFpHS4kopqjiiiy26OKLMMYo44w01mjjjTgWVkeOde3II10+/hhXkEK+RWSRbh0pkzBI 4qRkk1BGKeWUgzVD5VpWXqlWllp26eWXWs4BZllijklWmWaKhWaaYK2pXje/uXkenMDJSR6d wdkZHp7C6ekdn2xyBWigWg1KKFaGpiTJoSwlyihVjj4q6aSUVmrppQZ+galVmm5K1RedeipV qKKWauqpqKaq6qqsturqq/+wxirrrFqVQeutuOaq66689urrr8AGK+ywxBZr7LHIJqvsssw2 6+yz0EYr7bTUVmvttdhmq+223Hbr7bfghivuuDOVQu656Kar7rrstuvuu/DGK++89NZrb4OR 3Kvvvvz26++/AAcssFikDmzwwQgnrPDC7wUQYTueOewgxJ9JvCDFoFmMIMahaVwgx6J5zBou /olcr8n0ojxvACoz7PLLMMcs88w012zzzTjnrPPOPPfs889ABy300EQXy6W+R9+btL1L19t0 d7Mk9/S8U8tbdbxXw5t10Vx37fXXYIct9thkl2322WinrfbabLft9ttwxy333HTXbffdeOet 9958fPft99+ABy744IQXbvjhiA+7yeKMN57445BHLvnklFdu+dzJXK755px37vnnke0B+uik l2766ainrrqxR6zu+uuwxy777LTXbvvtuOeu++689+7778AHL/zwxBdv/PHIJ6/88sw37/zz 0Ecv/fTUV2/99dhnr/323FMYEAA7 ------=_NextPart_000_0009_01C6EE5D.BBC1FE60-- From avt-bounces@ietf.org Fri Oct 13 02:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGkv-0001XM-LJ; Fri, 13 Oct 2006 02:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7tT-00084J-Co for avt@ietf.org; Thu, 12 Oct 2006 17:15:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY7tQ-0002jn-DB for avt@ietf.org; Thu, 12 Oct 2006 17:15:07 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Oct 2006 14:15:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9CLF3dS001955; Thu, 12 Oct 2006 14:15:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9CLEvBI004212; Thu, 12 Oct 2006 14:15:03 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 14:15:03 -0700 Received: from [192.168.0.10] ([10.21.120.34]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 14:15:02 -0700 In-Reply-To: <877DEC6F4C0F574F8BB244ECCE32CBA80D0E02@esealmw111> References: <877DEC6F4C0F574F8BB244ECCE32CBA80D0E02@esealmw111> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <9D836920-7CAE-4BAC-8CD0-AF5F424752B1@cisco.com> From: Mark Baugher Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling Date: Thu, 12 Oct 2006 14:15:00 -0700 To: =?ISO-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Oct 2006 21:15:02.0658 (UTC) FILETIME=[7B5D7620:01C6EE43] DKIM-Signature: a=rsa-sha1; q=dns; l=21925; t=1160687703; x=1161551703; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20RFC3711/3830=20on=20Key=20derivation=20rate=20signalling =20; X=v=3Dcisco.com=3B=20h=3DC1uLBepkffhjxKNST05I2Za2BAk=3D; b=Ng6Jsr3njwY7fRGTHZInjYapBWDgpgD1zjodxnCm8gH6oONWK+28uh5CsvfYjLD2lDmAsMPK kdPgC6YF+JTHMA18YOPswg6lx7MKwDUIqXwEuXzBvYU8P+faA/jp07TI; Authentication-Results: sj-dkim-4.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f X-Mailman-Approved-At: Fri, 13 Oct 2006 02:42:51 -0400 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1949870258==" Errors-To: avt-bounces@ietf.org --===============1949870258== Content-Type: multipart/alternative; boundary=Apple-Mail-6--155609114 --Apple-Mail-6--155609114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed hi Mats, On Oct 12, 2006, at 12:00 PM, Mats N=E4slund (KI/EAB) wrote: > Hi > > > I agree Mark, but still one can ask why the key derivation rate is =20 > the _only_ parameter for which we talk about being "properly =20 > signaled". After all, there are many parameters for which we define =20= > a default, yet for these we do not highlight the issue of "proper =20 > signaling". I just assumed that it was an artifact of the writing committee and =20 harried editing. > > I tried to seFrom avt-bounces@ietf.org Fri Oct 13 02:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGkv-0001XM-LJ; Fri, 13 Oct 2006 02:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7tT-00084J-Co for avt@ietf.org; Thu, 12 Oct 2006 17:15:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY7tQ-0002jn-DB for avt@ietf.org; Thu, 12 Oct 2006 17:15:07 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Oct 2006 14:15:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9CLF3dS001955; Thu, 12 Oct 2006 14:15:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9CLEvBI004212; Thu, 12 Oct 2006 14:15:03 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 14:15:03 -0700 Received: from [192.168.0.10] ([10.21.120.34]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 14:15:02 -0700 In-Reply-To: <877DEC6F4C0F574F8BB244ECCE32CBA80D0E02@esealmw111> References: <877DEC6F4C0F574F8BB244ECCE32CBA80D0E02@esealmw111> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <9D836920-7CAE-4BAC-8CD0-AF5F424752B1@cisco.com> From: Mark Baugher Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling Date: Thu, 12 Oct 2006 14:15:00 -0700 To: =?ISO-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Oct 2006 21:15:02.0658 (UTC) FILETIME=[7B5D7620:01C6EE43] DKIM-Signature: a=rsa-sha1; q=dns; l=21925; t=1160687703; x=1161551703; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20RFC3711/3830=20on=20Key=20derivation=20rate=20signalling =20; X=v=3Dcisco.com=3B=20h=3DC1uLBepkffhjxKNST05I2Za2BAk=3D; b=Ng6Jsr3njwY7fRGTHZInjYapBWDgpgD1zjodxnCm8gH6oONWK+28uh5CsvfYjLD2lDmAsMPK kdPgC6YF+JTHMA18YOPswg6lx7MKwDUIqXwEuXzBvYU8P+faA/jp07TI; Authentication-Results: sj-dkim-4.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f X-Mailman-Approved-At: Fri, 13 Oct 2006 02:42:51 -0400 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1949870258==" Errors-To: avt-bounces@ietf.org --===============1949870258== Content-Type: multipart/alternative; boundary=Apple-Mail-6--155609114 --Apple-Mail-6--155609114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed hi Mats, On Oct 12, 2006, at 12:00 PM, Mats N=E4slund (KI/EAB) wrote: > Hi > > > I agree Mark, but still one can ask why the key derivation rate is =20 > the _only_ parameter for which we talk about being "properly =20 > signaled". After all, there are many parameters for which we define =20= > a default, yet for these we do not highlight the issue of "proper =20 > signaling". I just assumed that it was an artifact of the writing committee and =20 harried editing. > > I tried to search my memory from the spec. drafting days for a =20 > reason, and here is my best guess: > > The derivation rate is relevant for the key refresh mechanism. > > If key derivation rate is zero (the default) the whole key refresh =20 > is "bypassed" since only one initial derivation takes place (this =20 > is the effect of the way we define DIVIDE-BY-ZERO). Thus, if one =20 > only supports the default value, one can basically omit all the =20 > " DIV " stuff and get a somewhat simpler =20 > implementation. Thus, while the normative text indeed works for =20 > _any_ value of the derivation rate (zero or nonzero), it is only =20 > when it is "properly" (=3D non-default) signaled that one really =20 > needs to care about using the parameter at all. This sounds like a very plausible explanation to me. > > For all other SRTP-parameters, using the default values does not =20 > have the same "function bypass" effect, and that is probably why =20 > their proper signaling is not mentioned. > > Perhaps it would have been better to say "...once derivation rate =20 > is _explicitly_ signaled"... I don't know... I personally think it's fine. There are no MUSTs, SHALLs, MAYs or =20 SHOULDs surrounding the text. But I shouldn't criticizing others' =20 readings - there are at least a few things in that spec that we know =20 are confusing. Mark > > Anyway, this is my (probable) explanation for why we mentioned this =20= > in the RFC. > > /Mats > > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: den 12 oktober 2006 15:53 > To: Blommaert, Marc > Cc: avt@ietf.org > Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling > > Marc, > > On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote: > >> Dear AVT subscribers >> >> I have a particular point i would like to be clarify i.e.whether =20 >> key derivation rate (::=3D 0) requires explicit signalling or not. > > This is a matter for the key management and outside the scope of =20 > RFC 3711. Somehow keys get established and an SRTP cryptographic =20 > context is installed. The system that installs the keys has rules =20 > or policies for how it will handle default values. The two key =20 > management systems for SRTP that I'm familiar with will use a =20 > default if the particular value is not signaled. Generally =20 > speaking, it should be possible to install a master key and salt =20 > and allow everything else to default to the values of section 8.2 =20 > in RFC 3711. > > Mark >> >> >> First quote from RFC3711 >> >> "4.3.1 Key Derivation Algorithm >> Regardless of the encryption or message authentication transform =20 >> that is employed (it may be an SRTP pre-defined transform or newly =20= >> introduced according to Section 6), interoperable SRTP >> implementations MUST use the SRTP key derivation to generate =20 >> session keys. Once the key derivation rate is properly signaled at =20= >> the start of the session, there is no need for extra communication =20= >> between the parties that use SRTP key derivation. " >> >> Interpretation: Here i assume ('Properly signalled....') that it =20 >> is mandatory to include the key derivation rate in the SRTP policy =20= >> (even if a zero derivation rate is intended) >> >> =46rom 3.2.1 >> >> "an integer in the set {1,2,4,...,2^24}, the =20 >> "key_derivation_rate", where an unspecified value is treated as =20 >> zero. The constraint to be a power of 2 simplifies the session-key =20= >> derivation >> implementation, see Section 4.3." >> >> >> >> And somewhat further in the RFC: >> >> "8.2 Key Management parameters >> The table below lists all SRTP parameters that key management can =20 >> supply. For reference, it also provides a summary of the default =20 >> and mandatory-to-support values for an SRTP implementation as =20 >> described in Section 5. " >> >> "key derivation rate 0 0" >> Interpretation: Here is coould assume that the default "mandatory-=20= >> to-support" rate is Zero But 4.3.1 section suggestes that the =20 >> signalling needs to be explicit varch my memory from the spec. drafting days for a =20 > reason, and here is my best guess: > > The derivation rate is relevant for the key refresh mechanism. > > If key derivation rate is zero (the default) the whole key refresh =20 > is "bypassed" since only one initial derivation takes place (this =20 > is the effect of the way we define DIVIDE-BY-ZERO). Thus, if one =20 > only supports the default value, one can basically omit all the =20 > " DIV " stuff and get a somewhat simpler =20 > implementation. Thus, while the normative text indeed works for =20 > _any_ value of the derivation rate (zero or nonzero), it is only =20 > when it is "properly" (=3D non-default) signaled that one really =20 > needs to care about using the parameter at all. This sounds like a very plausible explanation to me. > > For all other SRTP-parameters, using the default values does not =20 > have the same "function bypass" effect, and that is probably why =20 > their proper signaling is not mentioned. > > Perhaps it would have been better to say "...once derivation rate =20 > is _explicitly_ signaled"... I don't know... I personally think it's fine. There are no MUSTs, SHALLs, MAYs or =20 SHOULDs surrounding the text. But I shouldn't criticizing others' =20 readings - there are at least a few things in that spec that we know =20 are confusing. Mark > > Anyway, this is my (probable) explanation for why we mentioned this =20= > in the RFC. > > /Mats > > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: den 12 oktober 2006 15:53 > To: Blommaert, Marc > Cc: avt@ietf.org > Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling > > Marc, > > On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote: > >> Dear AVT subscribers >> >> I have a particular point i would like to be clarify i.e.whether =20 >> key derivation rate (::=3D 0) requires explicit signalling or not. > > This is a matter for the key management and outside the scope of =20 > RFC 3711. Somehow keys get established and an SRTP cryptographic =20 > context is installed. The system that installs the keys has rules =20 > or policies for how it will handle default values. The two key =20 > management systems for SRTP that I'm familiar with will use a =20 > default if the particular value is not signaled. Generally =20 > speaking, it should be possible to install a master key and salt =20 > and allow everything else to default to the values of section 8.2 =20 > in RFC 3711. > > Mark >> >> >> First quote from RFC3711 >> >> "4.3.1 Key Derivation Algorithm >> Regardless of the encryption or message authentication transform =20 >> that is employed (it may be an SRTP pre-defined transform or newly =20= >> introduced according to Section 6), interoperable SRTP >> implementations MUST use the SRTP key derivation to generate =20 >> session keys. Once the key derivation rate is properly signaled at =20= >> the start of the session, there is no need for extra communication =20= >> between the parties that use SRTP key derivation. " >> >> Interpretation: Here i assume ('Properly signalled....') that it =20 >> is mandatory to include the key derivation rate in the SRTP policy =20= >> (even if a zero derivation rate is intended) >> >> =46rom 3.2.1 >> >> "an integer in the set {1,2,4,...,2^24}, the =20 >> "key_derivation_rate", where an unspecified value is treated as =20 >> zero. The constraint to be a power of 2 simplifies the session-key =20= >> derivation >> implementation, see Section 4.3." >> >> >> >> And somewhat further in the RFC: >> >> "8.2 Key Management parameters >> The table below lists all SRTP parameters that key management can =20 >> supply. For reference, it also provides a summary of the default =20 >> and mandatory-to-support values for an SRTP implementation as =20 >> described in Section 5. " >> >> "key derivation rate 0 0" >> Interpretation: Here is coould assume that the default "mandatory-=20= >> to-support" rate is Zero But 4.3.1 section suggestes that the =20 >> signalling needs to be explicit via SRTP policy. >> >> Also RFC3830 states that Section 6.10.1: >> "Note that if a Type/Value is not set, the default is used (according >> to SRTP's own criteria). Note also that, if "Session Encr. key >> length" is set, this should also be seen as the Master key length >> (otherwise, the SRTP default Master key length is used)." >> >> Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky =20 >> formulation ? Is default handling used ? If yes what does properly =20= >> signalled mean i.e. does >> the sentence (Once the key derivation rate is properly signaled at =20= >> the start of the session) overrule the default handling? >> The cases i consider >> a) rate is not contained in the policy --> take Zero (default) =20 >> value or case can not happen if explicit signalling is required (???) >> b) rate is contained in the policy (signalled explicitly) >> b1) contained in the set --> take the value as received >> b2) not contained in the set --> Take the Zero (default) value. >> >> >> Best Regards >> Marc >> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > --Apple-Mail-6--155609114 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi Mats,
On Oct 12, = 2006, at 12:00 PM, Mats N=E4slund (KI/EAB) wrote:

Hi
=A0
=A0
I agree Mark, but still one = can ask why the key derivation rate is the _only_ parameter for which we = talk about being "properly signaled". After all, there are many = parameters for which we define a default,=A0yet for these we do not = highlight the issue of "proper = signaling".

I just assumed that it was an = artifact of the writing committee and harried editing.
=A0
I tried to search my memory from the spec. drafting days=A0for = a reason, and here is my best guess:
=A0
The derivation rate is relevant for the key = refresh mechanism.
=A0
If key derivation rate is zero (the = default) the whole key=A0refresh is "bypassed" since only one initial = derivation takes place (this is the effect of the way we define = DIVIDE-BY-ZERO). Thus, if one only supports the default value, one can = basically omit all the "<index>=A0DIV <derivation_rate>" = stuff and get a somewhat simpler implementation. Thus, while the = normative text indeed works for _any_ value of the derivia SRTP policy. >> >> Also RFC3830 states that Section 6.10.1: >> "Note that if a Type/Value is not set, the default is used (according >> to SRTP's own criteria). Note also that, if "Session Encr. key >> length" is set, this should also be seen as the Master key length >> (otherwise, the SRTP default Master key length is used)." >> >> Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky =20 >> formulation ? Is default handling used ? If yes what does properly =20= >> signalled mean i.e. does >> the sentence (Once the key derivation rate is properly signaled at =20= >> the start of the session) overrule the default handling? >> The cases i consider >> a) rate is not contained in the policy --> take Zero (default) =20 >> value or case can not happen if explicit signalling is required (???) >> b) rate is contained in the policy (signalled explicitly) >> b1) contained in the set --> take the value as received >> b2) not contained in the set --> Take the Zero (default) value. >> >> >> Best Regards >> Marc >> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > --Apple-Mail-6--155609114 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi Mats,
On Oct 12, = 2006, at 12:00 PM, Mats N=E4slund (KI/EAB) wrote:

Hi
=A0
=A0
I agree Mark, but still one = can ask why the key derivation rate is the _only_ parameter for which we = talk about being "properly signaled". After all, there are many = parameters for which we define a default,=A0yet for these we do not = highlight the issue of "proper = signaling".

I just assumed that it was an = artifact of the writing committee and harried editing.
=A0
I tried to search my memory from the spec. drafting days=A0for = a reason, and here is my best guess:
=A0
The derivation rate is relevant for the key = refresh mechanism.
=A0
If key derivation rate is zero (the = default) the whole key=A0refresh is "bypassed" since only one initial = derivation takes place (this is the effect of the way we define = DIVIDE-BY-ZERO). Thus, if one only supports the default value, one can = basically omit all the "<index>=A0DIV <derivation_rate>" = stuff and get a somewhat simpler implementation. Thus, while the = normative text indeed works for _any_ value of the derivation rate (zero = or nonzero), it is only when it is "properly" (=3D non-default) signaled = that one really needs to care about using the parameter at = all.

This=A0sounds like a very = plausible explanation to me.
=A0
For all other = SRTP-parameters, using the default values does not have the same = "function bypass" effect, and that is probably why their proper = signaling is not mentioned.
=A0
Perhaps it would have been better to say = "...once derivation rate is _explicitly_ signaled"... I don't = know...

I personally think it's fine.=A0 = There are no MUSTs, SHALLs, MAYs or SHOULDs surrounding the text.=A0 But = I shouldn't criticizing others' readings - there are at least a few = things in that spec that we know are confusing.

Mark
=A0
Anyway, this is my (probable) explanation for why = we=A0mentioned this in the RFC.
=A0
/Mats

=
=
From: = Mark Baugher [mailto:mbaugher@cisco.com] =
Sent: den 12 oktober 2006 15:53
To: Blommaert, = Marc
Cc: avt@ietf.org
Subject: Re: = [AVT] RFC3711/3830 on Key derivation rate signalling =

Marc,

On Oct = 11, 2006, at 8:43 AM, Blommaert, Marc wrote:

=
Dear AVT = subscribers
=A0
=
I = have a particular point i would like to be clarify = i.e.whether=A0key derivation rate (::=3D 0) requires explicit = signalling or = not.

This is a matter for the key = management and outside the scope of RFC 3711.=A0 Somehow keys get = established and an SRTP cryptographic context is installed.=A0 The = system that installs the keys has rules or policies for how it will = handle default values.=A0 The two key management systems for SRTP that = I'm familiar with will use a default if the particular value is not = signaled.=A0 Gation rate (zero = or nonzero), it is only when it is "properly" (=3D non-default) signaled = that one really needs to care about using the parameter at = all.

This=A0sounds like a very = plausible explanation to me.
=A0
For all other = SRTP-parameters, using the default values does not have the same = "function bypass" effect, and that is probably why their proper = signaling is not mentioned.
=A0
Perhaps it would have been better to say = "...once derivation rate is _explicitly_ signaled"... I don't = know...

I personally think it's fine.=A0 = There are no MUSTs, SHALLs, MAYs or SHOULDs surrounding the text.=A0 But = I shouldn't criticizing others' readings - there are at least a few = things in that spec that we know are confusing.

Mark
=A0
Anyway, this is my (probable) explanation for why = we=A0mentioned this in the RFC.
=A0
/Mats

=
=
From: = Mark Baugher [mailto:mbaugher@cisco.com] =
Sent: den 12 oktober 2006 15:53
To: Blommaert, = Marc
Cc: avt@ietf.org
Subject: Re: = [AVT] RFC3711/3830 on Key derivation rate signalling =

Marc,

On Oct = 11, 2006, at 8:43 AM, Blommaert, Marc wrote:

=
Dear AVT = subscribers
=A0
=
I = have a particular point i would like to be clarify = i.e.whether=A0key derivation rate (::=3D 0) requires explicit = signalling or = not.

This is a matter for the key = management and outside the scope of RFC 3711.=A0 Somehow keys get = established and an SRTP cryptographic context is installed.=A0 The = system that installs the keys has rules or policies for how it will = handle default values.=A0 The two key management systems for SRTP that = I'm familiar with will use a default if the particular value is not = signaled.=A0 Generally speaking, it should be possible to install a = master key and salt and allow everything else to default to the values = of section 8.2 in RFC 3711.

Mark
=
=A0
=
=A0
=
First = quote from RFC3711
=A0
"4.3.1 = Key Derivation Algorithm

Regardless of the encryption or message authentication = transform that is employed (it may be an SRTP pre-defined transform or = newly introduced according to Section 6), interoperable = SRTP
implementations MUST use the SRTP key = derivation to generate session keys. Once the key derivation = rate is properly signaled at the start of the session, = there is no need for extra communication between the parties that = use SRTP key derivation.=A0"

Interpretation:=A0Here i = assume=A0 ('Properly signalled....') = that it is mandatory to include the key derivation rate=A0in = the SRTP policy=A0(even if a zero derivation rate is = intended)

=46rom 3.2.1

"an = integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", = where an unspecified value is treated as zero. The = constraint to be a power of 2 simplifies the session-key derivation =
implementation, see Section 4.3." =
=A0
=A0
=
=A0
And somewhat further in = the RFC:
=A0
=
"8.2 Key Management parameters =

The table below lists all SRTP parameters that key = management can supply. For reference, it also provides a summary of = the default and mandatory-to-support values for an SRTP = implementation as described in


Mark
=
=A0
=
=A0
=
First = quote from RFC3711
=A0
"4.3.1 = Key Derivation Algorithm

Regardless of the encryption or message authentication = transform that is employed (it may be an SRTP pre-defined transform or = newly introduced according to Section 6), interoperable = SRTP
implementations MUST use the SRTP key = derivation to generate session keys. Once the key derivation = rate is properly signaled at the start of the session, = there is no need for extra communication between the parties that = use SRTP key derivation.=A0"

Interpretation:=A0Here i = assume=A0 ('Properly signalled....') = that it is mandatory to include the key derivation rate=A0in = the SRTP policy=A0(even if a zero derivation rate is = intended)

=46rom 3.2.1

"an = integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", = where an unspecified value is treated as zero. The = constraint to be a power of 2 simplifies the session-key derivation =
implementation, see Section 4.3." =
=A0
=A0
=
=A0
And somewhat further in = the RFC:
=A0
=
"8.2 Key Management parameters =

The table below lists all SRTP parameters that key = management can supply. For reference, it also provides a summary of = the default and mandatory-to-support values for an SRTP = implementation as described in Section = 5.=A0"

= 
"key derivation =
rate                 0                  0"
 = 
Interpretation: Here is coould assume that the default =
"mandatory-to-support" rate is =
Zero But 4.3.1 section suggestes that the signalling needs to be explicit via =
SRTP policy.
=A0
Also RFC3830 states that Section =
6.10.1:
"Note that if a Type/Value is not set, the default is =
used (according
=A0=A0 to SRTP's own criteria). Note also that, if =
"Session Encr. key
=A0=A0 length" is set, this should also be seen as =
the Master key length
=A0=A0 (otherwise, the SRTP default Master key =
length is used)."
=A0
Summary: Is section 4.3.1 =
RFC3711 'properly signalled' an unlucky formulation ? Is default =
handling used ? If yes what does properly signalled mean i.e. does =

the sentence=A0(Once the key derivation rate is properly signaled at =
the start of the session) overrule the default handling? =

The cases i =
consider
a) rate is not =
contained in the policy --> take =
Zero (default) value or case =
can not happen if explicit signalling is required =
(???)
b) rate is =
contained in the policy=A0(signalled =
explicitly)
=A0=A0=A0=A0 b1) contained in the set --> take the value =
as received
=A0=A0=A0=A0 b2) not=A0contained in the set=A0=A0--> Take =
the Zero (default) value.
=A0
=A0
Best Regards
Marc
=A0
 =
=A0
________________________________________s.ietf.org/rfc/rfc3711.html#sec-5" = href=3D"http://www.apps.ietf.org/rfc/rfc3711.html#sec-5">Section = 5.=A0"

= 
"key derivation =
rate                 0                  0"
 = 
Interpretation: Here is coould assume that the default =
"mandatory-to-support" rate is =
Zero But 4.3.1 section suggestes that the signalling needs to be explicit via =
SRTP policy.
=A0
Also RFC3830 states that Section =
6.10.1:
"Note that if a Type/Value is not set, the default is =
used (according
=A0=A0 to SRTP's own criteria). Note also that, if =
"Session Encr. key
=A0=A0 length" is set, this should also be seen as =
the Master key length
=A0=A0 (otherwise, the SRTP default Master key =
length is used)."
=A0
Summary: Is section 4.3.1 =
RFC3711 'properly signalled' an unlucky formulation ? Is default =
handling used ? If yes what does properly signalled mean i.e. does =

the sentence=A0(Once the key derivation rate is properly signaled at =
the start of the session) overrule the default handling? =

The cases i =
consider
a) rate is not =
contained in the policy --> take =
Zero (default) value or case =
can not happen if explicit signalling is required =
(???)
b) rate is =
contained in the policy=A0(signalled =
explicitly)
=A0=A0=A0=A0 b1) contained in the set --> take the value =
as received
=A0=A0=A0=A0 b2) not=A0contained in the set=A0=A0--> Take =
the Zero (default) value.
=A0
=A0
Best Regards
Marc
=A0
 =
=A0
_______________________________________________
Audio/Video Transport Working Group


= --Apple-Mail-6--155609114-- --===============1949870258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============1949870258==-- From avt-bounces@ietf.org Fri Oct 13 02:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGkv-0001XH-AC; Fri, 13 Oct 2006 02:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY27g-0006qc-67 for avt@ietf.org; Thu, 12 Oct 2006 11:05:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY27e-00078s-0J for avt@ietf.org; Thu, 12 Oct 2006 11:05:24 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2006 08:04:18 -0700 X-IronPort-AV: i="4.09,301,1157353200"; d="scan'208,217"; a="747004452:sNHT6503308640" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9CF4Iv6017742; Thu, 12 Oct 2006 08:04:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9CF4Iin028542; Thu, 12 Oct 2006 08:04:18 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 08:04:18 -0700 Received: from [192.168.0.10] ([10.21.98.49]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 08:04:17 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <41ADB5DC-2F3F-4AF5-91E6-3010642C069C@cisco.com> From: Mark Baugher Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling Date: Thu, 12 Oct 2006 08:04:09 -0700 To: "Blommaert, Marc" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Oct 2006 15:04:17.0601 (UTC) FILETIME=[B0472310:01C6EE0F] DKIM-Signature: a=rsa-sha1; q=dns; l=24550; t=1160665458; x=1161529458; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20RFC3711/3830=20on=20Key=20derivation=20rate=20signalling =20; X=v=3Dcisco.com=3B=20h=3D0JlkzC+3uyqeyAi6gXDEBPVIfRE=3D; b=Ynch+z/NvfzG9jRs1VzFpxgrO6NwhJJ5h/BIAR7wTAc+S1Lkl8ny+5wbGYdwsYzWw1xKiiV/ PHrQCgeMg0qGW/UaOoANgXHvSTNvbnDR4xEyy4FqFdvH75gjj1IrKGrm; Authentication-Results: sj-dkim-3.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 30 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 X-Mailman-Approved-At: Fri, 13 Oct 2006 02:42:51 -0400 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: ,
Audio/Video Transport Working Group


= --Apple-Mail-6--155609114-- --===============1949870258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============1949870258==-- From avt-bounces@ietf.org Fri Oct 13 02:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGkv-0001XH-AC; Fri, 13 Oct 2006 02:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY27g-0006qc-67 for avt@ietf.org; Thu, 12 Oct 2006 11:05:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY27e-00078s-0J for avt@ietf.org; Thu, 12 Oct 2006 11:05:24 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2006 08:04:18 -0700 X-IronPort-AV: i="4.09,301,1157353200"; d="scan'208,217"; a="747004452:sNHT6503308640" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9CF4Iv6017742; Thu, 12 Oct 2006 08:04:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9CF4Iin028542; Thu, 12 Oct 2006 08:04:18 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 08:04:18 -0700 Received: from [192.168.0.10] ([10.21.98.49]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 08:04:17 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <41ADB5DC-2F3F-4AF5-91E6-3010642C069C@cisco.com> From: Mark Baugher Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling Date: Thu, 12 Oct 2006 08:04:09 -0700 To: "Blommaert, Marc" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Oct 2006 15:04:17.0601 (UTC) FILETIME=[B0472310:01C6EE0F] DKIM-Signature: a=rsa-sha1; q=dns; l=24550; t=1160665458; x=1161529458; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20RFC3711/3830=20on=20Key=20derivation=20rate=20signalling =20; X=v=3Dcisco.com=3B=20h=3D0JlkzC+3uyqeyAi6gXDEBPVIfRE=3D; b=Ynch+z/NvfzG9jRs1VzFpxgrO6NwhJJ5h/BIAR7wTAc+S1Lkl8ny+5wbGYdwsYzWw1xKiiV/ PHrQCgeMg0qGW/UaOoANgXHvSTNvbnDR4xEyy4FqFdvH75gjj1IrKGrm; Authentication-Results: sj-dkim-3.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 30 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 X-Mailman-Approved-At: Fri, 13 Oct 2006 02:42:51 -0400 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2116491139==" Errors-To: avt-bounces@ietf.org --===============2116491139== Content-Type: multipart/alternative; boundary=Apple-Mail-74--177860111 --Apple-Mail-74--177860111 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed hi Marc On Oct 12, 2006, at 7:24 AM, Blommaert, Marc wrote: > Dear Mark > > Thanks for the explanation, > > The thing i am concerned with is on the SRTP clients side: > According to one interpretation of the RFC a client would default > all unknown values and use default values if explicit (or proper) > signalling has been omitted. According to another interpretation of > the RFC the SRTP client expects proper signalling but receives > none, and without that would run into problems. I don't think this is a problem if we agree that there needs to be some other system to establish keys. I think it's clear that this other system needs to define how to encode the various parameters that go along with the keys. > > Your explenation seems to indicate that the use/context in which > SRTP (and according Key management) is used, may (re-)define the > default handling e.g. by requiring explicit signalling. I read the defaults as being the minimal interoperability requirements for SRTP systems, what all MUST implement. We see a great variety of key management systems that are designed for specific applications such as multicast to large groups, broadcast with no back-channel, point-to-point with minimal message exchanges, etc. The text in the SRTP specification that addresses how crypto contexts get established should admit systems that do key management according to application needs IMHO. SRTP serves as the media plane for a great variety of applications. I don't think it should have much to say about whether the parameters use type/length/value encoding, whether the key management encodes default values as zero as part of its message exchanges, whether the key management requires that every parameter be explicitly signaled or not. etc. I think this flexibility is a good thing. In developing RFC 4568, for example, we concluded that providing the SSRC was a problem in the signaling based upon how many RTP implementations function; we want to support the "bump-in-the-stack" model and this makes it real difficult to install an SSRC in an unaware RTP implementation even though RFC 3711 says the SSRC "should" be provided by key management in section 8. It turns out that this is not needed if each sender has its own master key and we did that instead. > > On the other hand you seem to trust that the default mapping is > used in products. In that case the text 'Once the key derivation > rate is properly signaled at the start of the session, is very > misleading. Perhaps it is. Mark > > Best Regards > Marc > > > > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: donderdag 12 oktober 2006 15:53 > To: Blommaert, Marc > Cc: avt@ietf.org > Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling > > Marc, > > On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote: > >> Dear AVT subscribers >> >> I have a particular point i would like to be clarify i.e.whether >> key derivation rate (::= 0) requires explicit signalling or not. > > This is a matter for the key management and outside the scope of > RFC 3711. Somehow keys get established and an SRTP cryptographic > context is installed. The system that installs the keys has rules > or policies for how it will handle default values. The two key > management systems for SRTP that I'm familiar with will use a > default if the particular value is not signaled. Generally > speaking, it should be possible to install a master key and salt > and allow everything else to default to the values of section 8.2 > in RFC 3711. > > Mark >> >> >> First quote from RFC3711 >> >> "4.3.1 Key Derivation Algorithm >> Regardless of the encryption or message authenticacribe> Content-Type: multipart/mixed; boundary="===============2116491139==" Errors-To: avt-bounces@ietf.org --===============2116491139== Content-Type: multipart/alternative; boundary=Apple-Mail-74--177860111 --Apple-Mail-74--177860111 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed hi Marc On Oct 12, 2006, at 7:24 AM, Blommaert, Marc wrote: > Dear Mark > > Thanks for the explanation, > > The thing i am concerned with is on the SRTP clients side: > According to one interpretation of the RFC a client would default > all unknown values and use default values if explicit (or proper) > signalling has been omitted. According to another interpretation of > the RFC the SRTP client expects proper signalling but receives > none, and without that would run into problems. I don't think this is a problem if we agree that there needs to be some other system to establish keys. I think it's clear that this other system needs to define how to encode the various parameters that go along with the keys. > > Your explenation seems to indicate that the use/context in which > SRTP (and according Key management) is used, may (re-)define the > default handling e.g. by requiring explicit signalling. I read the defaults as being the minimal interoperability requirements for SRTP systems, what all MUST implement. We see a great variety of key management systems that are designed for specific applications such as multicast to large groups, broadcast with no back-channel, point-to-point with minimal message exchanges, etc. The text in the SRTP specification that addresses how crypto contexts get established should admit systems that do key management according to application needs IMHO. SRTP serves as the media plane for a great variety of applications. I don't think it should have much to say about whether the parameters use type/length/value encoding, whether the key management encodes default values as zero as part of its message exchanges, whether the key management requires that every parameter be explicitly signaled or not. etc. I think this flexibility is a good thing. In developing RFC 4568, for example, we concluded that providing the SSRC was a problem in the signaling based upon how many RTP implementations function; we want to support the "bump-in-the-stack" model and this makes it real difficult to install an SSRC in an unaware RTP implementation even though RFC 3711 says the SSRC "should" be provided by key management in section 8. It turns out that this is not needed if each sender has its own master key and we did that instead. > > On the other hand you seem to trust that the default mapping is > used in products. In that case the text 'Once the key derivation > rate is properly signaled at the start of the session, is very > misleading. Perhaps it is. Mark > > Best Regards > Marc > > > > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: donderdag 12 oktober 2006 15:53 > To: Blommaert, Marc > Cc: avt@ietf.org > Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling > > Marc, > > On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote: > >> Dear AVT subscribers >> >> I have a particular point i would like to be clarify i.e.whether >> key derivation rate (::= 0) requires explicit signalling or not. > > This is a matter for the key management and outside the scope of > RFC 3711. Somehow keys get established and an SRTP cryptographic > context is installed. The system that installs the keys has rules > or policies for how it will handle default values. The two key > management systems for SRTP that I'm familiar with will use a > default if the particular value is not signaled. Generally > speaking, it should be possible to install a master key and salt > and allow everything else to default to the values of section 8.2 > in RFC 3711. > > Mark >> >> >> First quote from RFC3711 >> >> "4.3.1 Key Derivation Algorithm >> Regardless of the encryption or message authentication transform >> that is employed (it may be an SRTP pre-defined transform or newly >> introduced according to Section 6), interoperable SRTP >> implementations MUST use the SRTP key derivation to generate >> session keys. Once the key derivation rate is properly signaled at >> the start of the session, there is no need for extra communication >> between the parties that use SRTP key derivation. " >> >> Interpretation: Here i assume ('Properly signalled....') that it >> is mandatory to include the key derivation rate in the SRTP policy >> (even if a zero derivation rate is intended) >> >> From 3.2.1 >> >> "an integer in the set {1,2,4,...,2^24}, the >> "key_derivation_rate", where an unspecified value is treated as >> zero. The constraint to be a power of 2 simplifies the session-key >> derivation >> implementation, see Section 4.3." >> >> >> >> And somewhat further in the RFC: >> >> "8.2 Key Management parameters >> The table below lists all SRTP parameters that key management can >> supply. For reference, it also provides a summary of the default >> and mandatory-to-support values for an SRTP implementation as >> described in Section 5. " >> >> "key derivation rate 0 0" >> Interpretation: Here is coould assume that the default "mandatory- >> to-support" rate is Zero But 4.3.1 section suggestes that the >> signalling needs to be explicit via SRTP policy. >> >> Also RFC3830 states that Section 6.10.1: >> "Note that if a Type/Value is not set, the default is used (according >> to SRTP's own criteria). Note also that, if "Session Encr. key >> length" is set, this should also be seen as the Master key length >> (otherwise, the SRTP default Master key length is used)." >> >> Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky >> formulation ? Is default handling used ? If yes what does properly >> signalled mean i.e. does >> the sentence (Once the key derivation rate is properly signaled at >> the start of the session) overrule the default handling? >> The cases i consider >> a) rate is not contained in the policy --> take Zero (default) >> value or case can not happen if explicit signalling is required (???) >> b) rate is contained in the policy (signalled explicitly) >> b1) contained in the set --> take the value as received >> b2) not contained in the set --> Take the Zero (default) value. >> >> >> Best Regards >> Marc >> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > --Apple-Mail-74--177860111 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi Marc
=A0=A0
On= Oct 12, 2006, at 7:24 AM, Blommaert, Marc wrote:

Dear = Mark
=A0
Thanks for the explanation,
=A0
The thing i am concerned = with is on=A0the SRTP clients side:=A0According to one interpretation of = the RFC=A0a client would default all unknown=A0values and=A0use default = values if explicit (or proper) signalling has been omitted. According to = another interpretation of the RFC the SRTP client expects proper = signalling but receivestion transform >> that is employed (it may be an SRTP pre-defined transform or newly >> introduced according to Section 6), interoperable SRTP >> implementations MUST use the SRTP key derivation to generate >> session keys. Once the key derivation rate is properly signaled at >> the start of the session, there is no need for extra communication >> between the parties that use SRTP key derivation. " >> >> Interpretation: Here i assume ('Properly signalled....') that it >> is mandatory to include the key derivation rate in the SRTP policy >> (even if a zero derivation rate is intended) >> >> From 3.2.1 >> >> "an integer in the set {1,2,4,...,2^24}, the >> "key_derivation_rate", where an unspecified value is treated as >> zero. The constraint to be a power of 2 simplifies the session-key >> derivation >> implementation, see Section 4.3." >> >> >> >> And somewhat further in the RFC: >> >> "8.2 Key Management parameters >> The table below lists all SRTP parameters that key management can >> supply. For reference, it also provides a summary of the default >> and mandatory-to-support values for an SRTP implementation as >> described in Section 5. " >> >> "key derivation rate 0 0" >> Interpretation: Here is coould assume that the default "mandatory- >> to-support" rate is Zero But 4.3.1 section suggestes that the >> signalling needs to be explicit via SRTP policy. >> >> Also RFC3830 states that Section 6.10.1: >> "Note that if a Type/Value is not set, the default is used (according >> to SRTP's own criteria). Note also that, if "Session Encr. key >> length" is set, this should also be seen as the Master key length >> (otherwise, the SRTP default Master key length is used)." >> >> Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky >> formulation ? Is default handling used ? If yes what does properly >> signalled mean i.e. does >> the sentence (Once the key derivation rate is properly signaled at >> the start of the session) overrule the default handling? >> The cases i consider >> a) rate is not contained in the policy --> take Zero (default) >> value or case can not happen if explicit signalling is required (???) >> b) rate is contained in the policy (signalled explicitly) >> b1) contained in the set --> take the value as received >> b2) not contained in the set --> Take the Zero (default) value. >> >> >> Best Regards >> Marc >> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > --Apple-Mail-74--177860111 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi Marc
=A0=A0
On= Oct 12, 2006, at 7:24 AM, Blommaert, Marc wrote:

Dear = Mark
=A0
Thanks for the explanation,
=A0
The thing i am concerned = with is on=A0the SRTP clients side:=A0According to one interpretation of = the RFC=A0a client would default all unknown=A0values and=A0use default = values if explicit (or proper) signalling has been omitted. According to = another interpretation of the RFC the SRTP client expects proper = signalling but receives none, and without that would run into = problems.

I don't think this is a problem = if we agree that there needs to be some other system to establish keys.=A0= I think it's clear that this other system needs to define how to encode = the various parameters that go along with the keys.
=A0
Your explenation seems to indicate that=A0the use/context in = which SRTP (and according Key management)=A0is used, may (re-)define the = default handling e.g. by requiring explicit = signalling.

I read the defaults as being the = minimal interoperability requirements for SRTP systems, what all MUST = implement.=A0 We see a great variety of key management systems that are = designed for specific applications such as multicast to large groups, = broadcast with no back-channel, point-to-point with minimal message = exchanges, etc.=A0 The text in the SRTP specification that addresses how = crypto contexts get established should admit systems that do key = management according to application needs IMHO.=A0 SRTP serves as the = media plane for a great variety of applications.=A0 I don't think it = should have much to say about whether the parameters use = type/length/value encoding, whether the key management encodes default = values as zero as part of its message exchanges, whether the key = management requires that every parameter be explicitly signaled or not. = etc.=A0 I think this flexibility is a good thing.=A0 In developing RFC = 4568, for example, we concluded that providing the SSRC was a problem in = the signaling based upon how many RTP implementations function; we want = to support the "bump-in-the-stack" model and this makes it real = difficult to install an SSRC in an unaware RTP implementation even = though RFC 3711 says the SSRC "should" be provided by key management in = section 8.=A0 It turns out that this is not needed if each sender has = its own master key and we did that instead.
=
=A0
On the other hand you seem = to trust that the default mapping=A0is used in products. In that case = the text 'Once the key derivation rate is = properly signaled at the start of the session, is very = misleading.=A0

Perhaps it is.

Mark
=A0
Best Regards
Marc
=A0
=A0

I don't think this is a problem = if we agree that there needs to be some other system to establish keys.=A0= I think it's clear that this other system needs to define how to encode = the various parameters that go along with the keys.
=A0
Your explenation seems to indicate that=A0the use/context in = which SRTP (and according Key management)=A0is used, may (re-)define the = default handling e.g. by requiring explicit = signalling.

I read the defaults as being the = minimal interoperability requirements for SRTP systems, what all MUST = implement.=A0 We see a great variety of key management systems that are = designed for specific applications such as multicast to large groups, = broadcast with no back-channel, point-to-point with minimal message = exchanges, etc.=A0 The text in the SRTP specification that addresses how = crypto contexts get established should admit systems that do key = management according to application needs IMHO.=A0 SRTP serves as the = media plane for a great variety of applications.=A0 I don't think it = should have much to say about whether the parameters use = type/length/value encoding, whether the key management encodes default = values as zero as part of its message exchanges, whether the key = management requires that every parameter be explicitly signaled or not. = etc.=A0 I think this flexibility is a good thing.=A0 In developing RFC = 4568, for example, we concluded that providing the SSRC was a problem in = the signaling based upon how many RTP implementations function; we want = to support the "bump-in-the-stack" model and this makes it real = difficult to install an SSRC in an unaware RTP implementation even = though RFC 3711 says the SSRC "should" be provided by key management in = section 8.=A0 It turns out that this is not needed if each sender has = its own master key and we did that instead.
=
=A0
On the other hand you seem = to trust that the default mapping=A0is used in products. In that case = the text 'Once the key derivation rate is = properly signaled at the start of the session, is very = misleading.=A0

Perhaps it is.

Mark
=A0
Best Regards
Marc
=A0
=A0

From: Mark Baugher [mailto:mbaugher@cisco.com] =
Sent: donderdag 12 oktober 2006 15:53
To: = Blommaert, Marc
Cc: avt@ietf.org
Subject: Re: = [AVT] RFC3711/3830 on Key derivation rate signalling =

Marc,

On Oct 11, 2006, at 8:43 AM, = Blommaert, Marc wrote:

=
Dear AVT subscribers
=
=A0
I have a = particular point i would like to be clarify = i.e.whether=A0key derivation rate (::=3D 0) requires explicit = signalling or not.
=

This is a = matter for the key management and outside the scope of RFC 3711.=A0 = Somehow keys get established and an SRTP cryptographic context is = installed.=A0 The system that installs the keys has rules or policies = for how it will handle default values.=A0 The two key management systems = for SRTP that I'm familiar with will use a default if the particular = value is not signaled.=A0 Generally speaking, it should be possible to = install a master key and salt and allow everything else to default to = the values of section 8.2 in RFC 3711.

=
Mark
size=3D"2">
From: Mark Baugher [mailto:mbaugher@cisco.com] =
Sent: donderdag 12 oktober 2006 15:53
To: = Blommaert, Marc
Cc: avt@ietf.org
Subject: Re: = [AVT] RFC3711/3830 on Key derivation rate signalling =

Marc,

On Oct 11, 2006, at 8:43 AM, = Blommaert, Marc wrote:

=
Dear AVT subscribers
=
=A0
I have a = particular point i would like to be clarify = i.e.whether=A0key derivation rate (::=3D 0) requires explicit = signalling or not.
=

This is a = matter for the key management and outside the scope of RFC 3711.=A0 = Somehow keys get established and an SRTP cryptographic context is = installed.=A0 The system that installs the keys has rules or policies = for how it will handle default values.=A0 The two key management systems = for SRTP that I'm familiar with will use a default if the particular = value is not signaled.=A0 Generally speaking, it should be possible to = install a master key and salt and allow everything else to default to = the values of section 8.2 in RFC 3711.

=
Mark
=A0
=A0
First quote from = RFC3711
=
=A0
"4.3.1 = Key Derivation Algorithm

Regardless of the encryption or message authentication = transform that is employed (it may be an SRTP pre-defined transform or = newly introduced according to Section 6), interoperable SRTP =
implementations MUST use the SRTP key derivation = to generate session keys. Once the key derivation rate is = properly signaled at the start of the session, there is no = need for extra communication between the parties that use SRTP key = derivation.=A0"

Interpretation:=A0Here i = assume=A0 ('Properly signalled....') = that it is mandatory to include the key derivation rate=A0in = the SRTP policy=A0(even if a zero derivation rate is = intended)

=46rom 3.2.1

"an = integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", = where an unspecified value is treated as zero. The = constraint to be a power of 2 simplifies the session-key derivation =
implementation, see Section 4.3." =
=A0
=A0
=
=A0
And somewhat further in = the RFC:
=A0
=
"8.2 Key Management parameters =

The table below lists all SRTP parameters that key = management can supply. For reference, it also provides a summary of = the default and mandatory-to-support values for an SRTP implementation = as described in Section = 5.=A0"

"key derivation rate               =
  0                  0"
 
Interpretation: Here is coould assume that the default =
"mandatory-to-support" rate is =
Zero But 4.3.1 section suggestes that =A0
=A0
First quote from = RFC3711
=
=A0
"4.3.1 = Key Derivation Algorithm

Regardless of the encryption or message authentication = transform that is employed (it may be an SRTP pre-defined transform or = newly introduced according to Section 6), interoperable SRTP =
implementations MUST use the SRTP key derivation = to generate session keys. Once the key derivation rate is = properly signaled at the start of the session, there is no = need for extra communication between the parties that use SRTP key = derivation.=A0"

Interpretation:=A0Here i = assume=A0 ('Properly signalled....') = that it is mandatory to include the key derivation rate=A0in = the SRTP policy=A0(even if a zero derivation rate is = intended)

=46rom 3.2.1

"an = integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", = where an unspecified value is treated as zero. The = constraint to be a power of 2 simplifies the session-key derivation =
implementation, see Section 4.3." =
=A0
=A0
=
=A0
And somewhat further in = the RFC:
=A0
=
"8.2 Key Management parameters =

The table below lists all SRTP parameters that key = management can supply. For reference, it also provides a summary of = the default and mandatory-to-support values for an SRTP implementation = as described in Section = 5.=A0"

"key derivation rate               =
  0                  0"
 
Interpretation: Here is coould assume that the default =
"mandatory-to-support" rate is =
Zero But 4.3.1 section suggestes that the signalling needs to be explicit via =
SRTP policy.
=A0
Also RFC3830 states that Section =
6.10.1:
"Note that if a Type/Value is not set, the default is =
used (according
=A0=A0 to SRTP's own criteria). Note also that, if =
"Session Encr. key
=A0=A0 length" is set, this should also be seen as =
the Master key length
=A0=A0 (otherwise, the SRTP default Master key =
length is used)."
=A0
Summary: Is section 4.3.1 =
RFC3711 'properly signalled' an unlucky formulation ? Is default =
handling used ? If yes what does properly signalled mean i.e. does =

the sentence=A0(Once the key derivation rate is properly signaled at =
the start of the session) overrule the default handling? =

The cases i =
consider
a) rate is not =
contained in the policy --> take =
Zero (default) value or case =
can not happen if explicit signalling is required =
(???)
b) rate is =
contained in the policy=A0(signalled =
explicitly)
=A0=A0=A0=A0 b1) contained in the set --> take the value =
as received
=A0=A0=A0=A0 b2) not=A0contained in the set=A0=A0--> Take =
the Zero (default) value.
=A0
=A0
Best Regards
Marc
=A0
 =
=A0
_______________________________________________
Audio/Video Transport Working Group


= --Apple-Mail-74--177860111-- --===============2116491139== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Tr6">the signalling needs to be explicit via = SRTP policy.
=A0
Also RFC3830 states that Section =
6.10.1:
"Note that if a Type/Value is not set, the default is =
used (according
=A0=A0 to SRTP's own criteria). Note also that, if =
"Session Encr. key
=A0=A0 length" is set, this should also be seen as =
the Master key length
=A0=A0 (otherwise, the SRTP default Master key =
length is used)."
=A0
Summary: Is section 4.3.1 =
RFC3711 'properly signalled' an unlucky formulation ? Is default =
handling used ? If yes what does properly signalled mean i.e. does =

the sentence=A0(Once the key derivation rate is properly signaled at =
the start of the session) overrule the default handling? =

The cases i =
consider
a) rate is not =
contained in the policy --> take =
Zero (default) value or case =
can not happen if explicit signalling is required =
(???)
b) rate is =
contained in the policy=A0(signalled =
explicitly)
=A0=A0=A0=A0 b1) contained in the set --> take the value =
as received
=A0=A0=A0=A0 b2) not=A0contained in the set=A0=A0--> Take =
the Zero (default) value.
=A0
=A0
Best Regards
Marc
=A0
 =
=A0
_______________________________________________
Audio/Video Transport Working Group


= --Apple-Mail-74--177860111-- --===============2116491139== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============2116491139==-- ansport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============2116491139==-- From avt-bounces@ietf.org Fri Oct 13 02:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGku-0001XC-Vb; Fri, 13 Oct 2006 02:42:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1UI-0006DI-Dd for avt@ietf.org; Thu, 12 Oct 2006 10:24:42 -0400 Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1UF-0005j0-7L for avt@ietf.org; Thu, 12 Oct 2006 10:24:42 -0400 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k9CEOVS1032535; Thu, 12 Oct 2006 16:24:31 +0200 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k9CEOUkS019393; Thu, 12 Oct 2006 16:24:30 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 16:24:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] RFC3711/3830 on Key derivation rate signalling Date: Thu, 12 Oct 2006 16:24:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] RFC3711/3830 on Key derivation rate signalling thread-index: AcbuB4JDBmIk51E7RQCbXJ/n7xR14QAACbOA From: "Blommaert, Marc" To: "Mark Baugher" X-OriginalArrivalTime: 12 Oct 2006 14:24:28.0772 (UTC) FILETIME=[206CC240:01C6EE0A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 X-Mailman-Approved-At: Fri, 13 Oct 2006 02:42:51 -0400 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1835055901==" Errors-To: avt-bounces@ietf.org This is a multi-part message in MIME format. --===============1835055901== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EE0A.2026A21A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EE0A.2026A21A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Mark =20 Thanks for the explanation, =20 The thing i am concerned with is on the SRTP clients side: According to one interpretation of the RFC a client would default all unknown values and use default values if explicit (or proper) signalling has been omitted. According to another interpretation of the RFC the SRTP client expects proper signalling but receives none, and without that would run into problems.=20 =20 Your explenation seems to indicate that the use/context in which SRTP (and according Key management) is used, may (re-)define the default handling e.g. by requiring explicit signalling. =20 On the other hand you seem to trust that the default mapping is used in products. In that case the text 'Once the key derivation rate is properly signaled at the start of the session, is very misleading.=20 =20 Best Regards Marc =20 =20 ________________________________ From: Mark Baugher [mailto:mbaugher@cisco.com]=20 Sent: donderdag 12 oktober 2006 15:53 To: Blommaert, Marc Cc: avt@ietf.org Subject: Re: [AVT] RFC3711/3830 on Key derivation rate signalling=20 Marc,=20 On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote: Dear AVT subscribers =20 I have a particular point i would like to be clarify i.e.whether key derivation rate (::=3D 0) requires explicit signalling or not. =09 This is a matter for the key management and outside the scope of RFC 3711. Somehow keys get established and an SRTP cryptographic context is installed. The system that installs the keys has rules or policies for how it will handle default values. The two key management systems for SRTP that I'm familiar with will use a default if the particular value is not signaled. Generally speaking, it should be possible to install a master key and salt and allow everything else to default to the values of section 8.2 in RFC 3711. Mark =09 =20 =20 First quote from RFC3711 =09 =20 =09 "4.3.1 Key Derivation Algorithm=20 Regardless of the encryption or message authentication transform that is employed (it may be an SRTP pre-defined transform or newly introduced according to Section 6 ), interoperable SRTP=20 implementations MUST use the SRTP key derivation to generate session keys. Once the key derivation rate is properly signaled at the start of the session, there is no need for extra communication between the parties that use SRTP key derivation. " Interpretation: Here i assume ('Properly signalled....') that it is mandatory to include the key derivation rate in the SRTP policy (even if a zero derivation rate is intended) From 3.2.1 =09 "an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", where an unspecified value is treated as zero. The constraint to be a power of 2 simplifies the session-key derivation=20 implementation, see Section 4.3 ."=20 =20 =20 =09 =20 =09 And somewhat further in the RFC:=20 =20 =09 "8.2 Key Management parameters=20 The table below lists all SRTP parameters that key management can supply. For reference, it also provides a summary of the default and mandatory-to-support values for an SRTP implementation as described in Section 5 . " =09 "key derivation rate 0 0" =09 Interpretation: Here is coould assume that the default "mandatory-to-support" rate is Zero But 4.3.1 section suggestes that the signalling needs to be explicit via SRTP policy. =20 =09 =09 =09 Also RFC3830 states that Section 6.10.1: "Note that if a Type/Value is not set, the default is used (according to SRTP's own criteria). Note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used)." =20 Summary: Is section 4.3.1 RFC3711 'properly signalled' an unlucky formulation ? Is default handling used ? If yes what does properly signalled mean i.e. does=20 the sentence (Once the key derivation rate is properly signaled at the start of the session) overrule the default handling?=20 The cases i consider =09 a) rate is not contained in the policy --> take Zero (default) value or case can not happen if explicit signalling is required (???) b) rate is contained in the policy (signalled explicitly) b1) contained in the set --> take the value as received b2) not contained in the set --> Take the Zero (default) value. =20 =20 Best Regards Marc =20 =20 =20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C6EE0A.2026A21A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Mark
 
Thanks for the explanation,
 
The thing i am concerned with is on the = SRTP clients=20 side: According to one interpretation of the RFC a client = would=20 default all unknown values and use default values if explicit = (or=20 proper) signalling has been omitted. According to another interpretation = of the=20 RFC the SRTP client expects proper signalling but receives none, and = without=20 that would run into problems.
 
Your explenation seems to indicate = that the=20 use/context in which SRTP (and according Key management) is used, = may=20 (re-)define the default handling e.g. by requiring explicit=20 signalling.
 
On the other hand you seem to trust that the = default=20 mapping is used in products. In that case the text 'Once the key derivation rate is properly signaled = at the=20 start of the session, is very=20 misleading. 
 
Best Regards
Marc
 
 

From: Mark Baugher = [mailto:mbaugher@cisco.com]=20
Sent: donderdag 12 oktober 2006 15:53
To: = Blommaert,=20 Marc
Cc: avt@ietf.org
Subject: Re: [AVT] = RFC3711/3830 on Key=20 derivation rate signalling

Marc,

On Oct 11, 2006, at 8:43 AM, Blommaert, Marc wrote:
Dear = AVT=20 subscribers
 
I = have a=20 particular point i would like to be clarify=20 i.e.whether key derivation rate (::=3D 0) requires explicit signalling or=20 not.
This is a matter for the key = management and=20 outside the scope of RFC 3711.  Somehow keys get established and an = SRTP=20 cryptographic context is installed.  The system that installs the = keys has=20 rules or policies for how it will handle default values.  The two = key=20 management systems for SRTP that I'm familiar with will use a default if = the=20 particular value is not signaled.  Generally speaking, it should be = possible to install a master key and salt and allow everything else to = default=20 to the values of section 8.2 in RFC 3711.
Mark
 
 
First quote from=20 RFC3711
 
"4.3.1 Key Derivation = Algorithm=20

Regardless of the encryption or message = authentication=20 transform that is employed (it may be an SRTP pre-defined transform or = newly=20 introduced according to Section=20 6), interoperable SRTP
implementations=20 MUST use the SRTP key derivation to generate session = keys.=20 Once the key derivation rate is properly signaled at the start = of the=20 session, there is no need for extra communication between the = parties=20 that use SRTP key derivation. "

Interpretation: Here i = assume  ('Properly signalled....') that it = is=20 mandatory to include the key derivation rate in the SRTP=20 policy (even if a zero derivation rate is = intended)

From=20 3.2.1

"an integer in the set {1,2,4,...,2^24}, the=20 "key_derivation_rate", where an unspecified value is treated as = zero. The constraint to be a power of 2 simplifies the = session-key=20 derivation
implementation, see Section=20 4.3."=20
 =20
 
 
And somewhat = further in the=20 RFC:
 
"8.2 Key Management = parameters=20

The table below lists all SRTP parameters that key management can = supply.=20 For reference, it also provides a summary of the default and=20 mandatory-to-support values for an SRTP implementation as described in = Section=20 5. "

"key derivation rate     =
            0                  0"
 
Interpretation: Here is coould assume that the default =
"mandatory-to-support" rate is =
Zero But 4.3.1 section suggestes that the signalling needs to be explicit via SRTP =
policy.
 
Also RFC3830 states that Section =
6.10.1:
"Note that if a Type/Value is not set, the default is =
used (according
   to SRTP's own criteria). Note also that, =
if "Session Encr. key
   length" is set, this should also =
be seen as the Master key length
   (otherwise, the SRTP =
default Master key length is used)."
 
Summary: =
Is section 4.3.1 RFC3711 'properly signalled' an unlucky formulation ? =
Is default handling used ? If yes what does properly signalled mean i.e. =
does 
the sentence (Once the key derivation rate is properly signaled at the =
start of the session) overrule the default handling? =

The cases i =
consider
a) rate is not =
contained in the policy --> take =
Zero (default) value or case can =
not happen if explicit signalling is required =
(???)
b) rate is contained in =
the policy (signalled explicitly)
     b1) contained in the =
set --> take the value as received
     b2) not contained =
in the set  --> Take the Zero (default) =
value.
 
 
Best Regards
Marc
 
 =
 
_______________________________________________
Audio/Video Transport Working Group
https://www1.ietf.org= /mailman/listinfo/avt

------_=_NextPart_001_01C6EE0A.2026A21A-- --===============1835055901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============1835055901==-- From bsdpcc@ambc.com Fri Oct 13 06:26:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYKFL-00008R-QB for avt-archive@lists.ietf.org; Fri, 13 Oct 2006 06:26:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYKFL-0007Pv-Nd for avt-archive@lists.ietf.org; Fri, 13 Oct 2006 06:26:31 -0400 Received: from [202.59.73.89] (helo=netserver) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GYKFH-0000Es-P2 for avt-archive@lists.ietf.org; Fri, 13 Oct 2006 06:26:31 -0400 Received: from 66.36.236.47 (HELO smtp.getontheweb.com) by lists.ietf.org with esmtp (0GA90TF4MUTK HJ0OA8) id 7MDIC6-ZURLIA-LV for avt-archive@lists.ietf.org; Fri, 13 Oct 2006 22:18:04 +0480 From: "Leila Godwin" To: Subject: Weighty note. You should to read. Date: Fri, 13 Oct 2006 22:18:04 +0480 Message-ID: <01c6ef15$73eecf60$6c822ecf@bsdpcc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Aca6QBJP2T7E6QP1L5HHFP2R4HS3L0== X-Spam-Score: 3.7 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Read that message attentively. Here you will find the intimate news about CYHD. Read this news. This information probability be issued on October 16. It is your chance to buy CYHD for the good price. CYHD probability rock the market and break it. GO CYHD NOW !!! Recomendation: Read to the end and think after. with Logitech International SA. CALGARY, AB--(MARKET WIRE)--October 16 2006 -- Cyberhand Technologies International, Inc. (Other OTC:CYHD.PK - News), a leading computer peripheral design company specializing in innovative wireless ergonomic products for potential military & private purposes, declare that it signed the agreement for with Logitech International SA , a leading manufacture of computer controllers & keyboards. The company's first product designed specifically for Sony's next-generation gaming platform PS 3. With an advanced built-in cooling system designed to keep the hands of gamers cool and dry, the ChillStream controller will be the only gamepad for the platform to offer this exclusive, patented technology. Cyberhand will upgrade its development lab to add game development sequences and full USB control programming in-house. It is anticipated that once the new equipment arrives and is installed that all tactical, functionality and sequential drivers will be created internally. This gives Cyberhand complete control over its product evolution a long with the ability to add upgrades and respond quickly for the newest gaming environment that demand complex programmable tactical sequence routines. The X Series of Controllers are simply the fastest, most comfortable and most responsive game control systems in the world today. The X series will be used in PS 3 platform under the brand of Logitech. By that agreement Cyberhand Technologies International is going to receive 50 000 000 $ from Logitech International SA for developing that incredible game controller for Playstation 3. Mr. Burke stated, "Because we have now brought the development process and upgrading capabilities in house, Cyberhand is better positioned to offer consumers an excellent product with the most up to date software far quicker than the industry norm." About Cyberhand Technologies International, Inc. Cyberhand Technologies International, Inc. is a leading computer peripheral design company specializing in innovative wireless ergonomic products for mobile & desktop users. The company manufactures, designs, markets and sells leading edge consumer electronics devices that feature innovative ergonomic designs, advanced software development and technologies that are far superior to other products in the market. Cyberhand is focused on developing products that allow computer, Personal Digital Assistant (PDA) and Smartphone users the ultimate in mobility, productivity, performance and comfort. The company's initial products include: -- Wireless Keyboards for PDAs and Smartphones + Computer Game Controllers that are 40% more responsive than competing products -- Ergonomic Computer Mouse Products that eliminate computer-related repetitive stress injuries -- Related Software Upgrades and other Peripherals such as Keyboards, Cameras and Scanners P.S We will promote that stock till the end of the year and the price will raise . People will buy it and they will earn big cash. Don't miss that and buy it now cause the price is low. After the 16 October the price will grow up to 1000%. Take it now!! From avt-bounces@ietf.org Fri Oct 13 13:50:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYR96-0007zF-E7; Fri, 13 Oct 2006 13:48:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYR95-0007yJ-Af for avt@ietf.org; Fri, 13 Oct 2006 13:48:31 -0400 Received: from prufrock.cs.umd.edu ([128.8.128.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYR94-0005GF-2H for avt@ietf.org; Fri, 13 Oct 2006 13:48:31 -0400 Received: (from sharno@localhost) by prufrock.cs.umd.edu (8.12.10/8.12.5) id k9DHmT2u022736 for avt@ietf.org; Fri, 13 Oct 2006 13:48:29 -0400 (EDT) Date: Fri, 13 Oct 2006 13:48:29 -0400 (EDT) From: Tamer Elsharnouby Message-Id: <200610131748.k9DHmT2u022736@prufrock.cs.umd.edu> To: avt@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [AVT] IEEE NetCri 2007: Call for papers X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org ** Apologies if you receive multiple copies of this call for papers ** =============================================================================== Call for Papers NetCri 07 The First International Workshop on Research Challenges in Next Generation Networks for First Responders and Critical Infrastructures http://www.cs.umd.edu/~sharno/NetCri In Conjunction with IEEE IPCCC 2007, New Orleans, Louisiana, April 11-13 =============================================================================== As advances in pervasive computing, wireless communication and sensor networks continue, more opportunities are open to first responders and critical infra- structures to benefit from these technologies. Providing first responders with the best possible technology, infrastructure and services help save the lives of the general public and the first responders as well. One of the main challenges to the operations of first responders and critical infrastructures is to deploy a communication network that is dependable, secure, and rapidly deployable. In order to operate effectively, the deployed network supports services such as location determination, audio and video communication, and in site and remote sensing. Another key feature for first responders and critical infrastructures networks is to support interactions among multiple heterogen- eous networks. This workshop provides a forum for researchers, industry, and government agencies to discuss the challenges facing the design, deployment and operation- al issues for next generation network support for first responders and critical infrastructure. The workshop will identify and define fundamental concepts and techniques, resolve conflicts between different approaches in the area, and provide a common ground for an advanced research and development agenda. Topics of interest include, but are not limited to: - Smart environments (buildings, roads, vehicles, etc.) - Fast roaming in heterogonous network environment - Localization and time synchronization - Rapidly deployable and self configuring services and networks - Security, dependability, privacy, and performance trade-offs - QoS in heterogeneous wireless networks - Sensor and actuator networks for information gathering and real-time control - Network and system support for augmented reality and visual analytics - Simulation studies of first responders and critical infrastructures’ networks - Novel and adaptive communication protocols to support first responders and critical infrastructure’ operation - Resource management and allocation - Power control management - Admission, load and flow control - Performance analysis and experimentation of heterogeneous wireless networks - Security techniques and methods for heterogeneous wireless networks - Interoperability among WLANs, Cellular, WSN and wired networks - Metrics and measurements on heterogeneous networks - Mobility models and traffic patterns in disaster areas - Cross-layer design - Testbeds Paper Submission Papers should describe original, previously unpublished work, not currently under review by another conference, workshop, or journal. Authors are invited to submit a maximum of 6 pages papers including the abstract, figures and references. Papers should include the title, author(s), authors' affiliation and an abstract. The formatting should be according to IEEE rules. Papers should be submitted in a PDF format using the EDAS submission system. Accepted papers will be accessible through the IEEE digital library and are included in the conference proceedings. Important Dates Submission deadline: November 30, 2006 Notification of acceptance: January 5, 2007 Camera ready version: January 26, 2007 Workshop Organizing Committee Program Co-Chairs Mohamed Eltoweissy, Virginia Tech, USA Moustafa Youssef, University of Maryland, USA Publicity Co-Chairs Tamer Elsharnouby, Microsoft Corporation, USA James Joshi, University of Pittsburg, USA _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From pfeiffeo@guestresponse.com Sat Oct 14 03:40:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYe7o-0000jh-Ja for avt-archive@lists.ietf.org; Sat, 14 Oct 2006 03:40:04 -0400 Received: from ppp139-16.adsl.forthnet.gr ([62.1.130.16] helo=guestresponse.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GYe7n-00065y-2o for avt-archive@lists.ietf.org; Sat, 14 Oct 2006 03:40:04 -0400 Message-ID: <000001c6ef63$e47aed60$af18a8c0@xfkwegu> Reply-To: "Gofraidh Lawlor" From: "Gofraidh Lawlor" To: avt-archive@lists.ietf.org Subject: Re: VkAGRA Date: Sat, 14 Oct 2006 00:39:34 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6EF29.381C1560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.7 (+++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6EF29.381C1560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VkAGRA for LESS http://www.zomationdesx.com =20 hear a big cheer for them! that was the end of their contribution, I asked the vital question. ------=_NextPart_000_0001_01C6EF29.381C1560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VkAGRA for LESS http://www.zomationdesx.com

=
 
hear a big cheer for them!
that was the end of their contribution, I asked the vital = question.
------=_NextPart_000_0001_01C6EF29.381C1560-- From Byronnicolais@adoptee.com Sun Oct 15 02:01:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYz3W-0005Cv-Ed; Sun, 15 Oct 2006 02:01:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYyq6-00031v-PU; Sun, 15 Oct 2006 01:47:11 -0400 Received: from [222.243.253.250] (helo=04ED812149C2410) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GYypy-0003Nc-RC; Sun, 15 Oct 2006 01:47:10 -0400 Message-ID: <24737551182031.6394277BF5@FHVQZ0R> From: "Jean Salinas" To: Subject: Stock Maven Newslettter Date: Sun, 15 Oct 2006 13:43:28 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: MdCWvWBCDmPPUV2oYzm8EHt2IrNF43p6Wr8w Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Yo Archive!!. MPRG - MPRG - MPRG - MPRG - MPRG - MPRG MOTION PICTURE GROUP, INC. **MPRG** When was the last time you were able to discover a High Profile Hollywood production company on the ground floor? MPRG's management has produced and/or developed over 25 titles that have earend global revenues of over $1 billion!!! Rloling Stones Magazine gives " I trust you to kill me" with KIEFER SUTHERLAND *** stars! Go watch the traile rnow! This review is bigge rthan huge! Ground floor opportunity ,This company is on fire! ****Go read all the News Releases Now *** The Motion Picture Group, Inc. Co-Finances ''HOUND DOG,'' a Featuer Film Starring , Dakota Fanning features were not as far removed from the human norm as were thethe ancient ship might be caught in the wash of rocket fire. As theother exits. But had he fully explored the ship? Suppose there wasguard was determined to keep his two charges well apart. Now Ithere was something to be learned about it." "And he wanted you,is an opening!" Eet was peremptory. Stubbornly I looked to see where Icould feel a wave of heat. Whatever had been exposed to that must havebut he did not turn his head. Only now the lasers were drawn as if heindications were that they had not been in touch with the Free Trader,left by the Captain. He, too, had pulled a green stick out and waswas Hywel Jern-" "No." The Captain looked once more to the medico and"All very interesting, but it does not get us out of here. Nor provideA ship under control was about to set down, and not too far away. Ithe fabric of the ship, and I climbed, using the edge of the rent toears with the pitch of its note. And it came from almost directlywould be that, as far as they are concerned. Not good - meeting with From joe@1-stopnet.com Sun Oct 15 10:21:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6rN-0007S0-2B; Sun, 15 Oct 2006 10:21:01 -0400 Received: from 84-75-167-226.dclient.hispeed.ch ([84.75.167.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ6rL-0004Pz-My; Sun, 15 Oct 2006 10:21:01 -0400 From: "Dianna Sweeney" To: Subject: It is your chance to boost you carreer Date: Sun, 15 Nov 2006 14:20:59 -0060 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Thread-Index: Aca6QE6OJ1IHFA7V39MMK204NKAVCA== X-Spam-Score: 4.0 (++++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Good Day! Our international company has a great offer for you; it's not just the great opportunity, but a chance to earn good money. We have been working with such countries as USA, Italy, Spain, France, Great Britain and many more. We are always in need of new workers new employees. Now we are offering a high salary job for you. We have best vacancies, just for you. We welcome anyone who is looking for a good job and who wants to raise their financial status, to help your family or your needs. We have either full-time or part-time positions. If you are really interested please provide us with the following information: First name: Last name: Country: City: Land Phone: Cell phone: E-mail: Our email is euroimperial@web2mail.com And we will contact you in 24 hours. If you want to work with us, don't hesitate, and we will lead you through the process and will explain to you everything. We will wait for your response, and we guarantee a stable high salary and a lot of benefits with it. We are waiting for you, let us know as soon as possible if you are interested and ready to work. We wish you a Good Luck. Waiting for your email to euroimperial@web2mail.com Best Regards, P.S If you don't wish to receive that email please write a blank email with the unsubscribe subject to euroimperial@web2mail.com From genovese@00map.com Sun Oct 15 14:34:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAoU-00075r-ME; Sun, 15 Oct 2006 14:34:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZAoU-0006TM-Kd; Sun, 15 Oct 2006 14:34:18 -0400 Received: from c-69-242-133-211.hsd1.mo.comcast.net ([69.242.133.211] helo=jerry-1j1gjt2d1.hsd1.mo.comcast.net.) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GZAoS-0003Sp-9e; Sun, 15 Oct 2006 14:34:18 -0400 Date: Sun, 15 Nov 2006 18:33:38 +0360 From: "Carly Cordero" X-Mailer: The Bat! (v3.0.0.15) UNREG / 77YIB4V52SDZ8OWANJ Reply-To: "Carly Cordero" X-Priority: 3 (Normal) Message-ID: <1389281383.20061015183338@00map.com> To: bridge-archive@lists.ietf.org Subject: Nice job MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Good Day! Our international company has a great offer for you; it's not just the great opportunity, but a chance to earn good money. We have been working with such countries as USA, Italy, Spain, France, Great Britain and many more. We are always in need of new workers new employees. Now we are offering a high salary job for you. We have best vacancies, just for you. We welcome anyone who is looking for a good job and who wants to raise their financial status, to help your family or your needs. We have either full-time or part-time positions. If you are really interested please provide us with the following information: First name: Last name: Country: City: Land Phone: Cell phone: E-mail: Our email is euroimperial@web2mail.com And we will contact you in 24 hours. If you want to work with us, don't hesitate, and we will lead you through the process and will explain to you everything. We will wait for your response, and we guarantee a stable high salary and a lot of benefits with it. We are waiting for you, let us know as soon as possible if you are interested and ready to work. We wish you a Good Luck. Waiting for your email to euroimperial@web2mail.com Best Regards, P.S If you don't wish to receive that email please write a blank email with the unsubscribe subject to euroimperial@web2mail.com From feedback@0-0.com Sun Oct 15 15:14:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZBR0-0005Fd-34; Sun, 15 Oct 2006 15:14:06 -0400 Received: from bhq249.neoplus.adsl.tpnet.pl ([83.28.106.249] helo=tomaslki-910038) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZBQy-0004Ck-Fn; Sun, 15 Oct 2006 15:14:06 -0400 Received: from [209.190.145.254] (port=2528 helo=mail2.floridaserver.com) by mail2.floridaserver.com with asmtp id 2SO08L-7KS91J-43 for ipo-archive@lists.ietf.org; Sun, 15 Nov 2006 19:14:03 -0060 Message-ID: <01c6f08e$13ee1470$6c822ecf@feedback> From: "Lanny Horner" {SET:debug=11} To: Subject: It is your chance to boost you carreer Date: Sun, 15 Nov 2006 19:14:03 -0060 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Good Day! Our international company has a great offer for you; it's not just the great opportunity, but a chance to earn good money. We have been working with such countries as USA, Italy, Spain, France, Great Britain and many more. We are always in need of new workers new employees. Now we are offering a high salary job for you. We have best vacancies, just for you. We welcome anyone who is looking for a good job and who wants to raise their financial status, to help your family or your needs. We have either full-time or part-time positions. If you are really interested please provide us with the following information: First name: Last name: Country: City: Land Phone: Cell phone: E-mail: Our email is euroimperial@web2mail.com And we will contact you in 24 hours. If you want to work with us, don't hesitate, and we will lead you through the process and will explain to you everything. We will wait for your response, and we guarantee a stable high salary and a lot of benefits with it. We are waiting for you, let us know as soon as possible if you are interested and ready to work. We wish you a Good Luck. Waiting for your email to euroimperial@web2mail.com Best Regards, P.S If you don't wish to receive that email please write a blank email with the unsubscribe subject to euroimperial@web2mail.com From zyzy2004@msn.com Sun Oct 15 16:20:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZCTh-0001K4-HD for avt-archive@lists.ietf.org; Sun, 15 Oct 2006 16:20:57 -0400 Received: from [88.233.156.121] (helo=stiedprmail1.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZCTe-0005UN-IQ for avt-archive@lists.ietf.org; Sun, 15 Oct 2006 16:20:57 -0400 Reply-to: "zt tt" From: "zt tt" Date: Jan, 15 Oct 2006 23:07:33 +0300 Message-ID: <644202429181655677.684038087302048545@msn.com> To: "avt-archive@lists.ietf.org" Content-type: text/html; Charset=Windows-1251 Subject: A st-0ck T0 Get Ahead 0f the Cr0 vvd X-Spam-Score: 3.1 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 STOCK TRADER ALERT!
MONDAY OCTOBER 16, 2006
GLOBEX INC.
ETHANOL PLAY
Symbol: GLXI
Price: .29

WHILE PAST PERFORMANCE IS NEVER INDICATIVE OF FUTURE RESULTS, ON AUGUST 4TH
THIS STOCK WENT FROM $.70 TO $1.18. CAN IT RUN AGAIN???
GO READ THE NEWS!! ARE ALL SIGNS SHOWING GLXI IS READY TO POP?
COULD THIS ONE BE MORE PROFITABLE THAN BANK ROBBERY?
RADAR IT RIGHT NOW FOR MONDAY. DON"T TAKE YOUR EYES OFF IT....
__________
Information within this report contains forward looking statements within
the meaning of Section 27A of the Securities Act of 1933 and Section 21B of
the SEC Act of 1934. Statements that involve discussions with respect to
projections of future events are forward looking. Don"t rely on them. This
company doesn"t report. Past performance is never indicative of future results.
We received 150,000 free trading shares in the past. All those shares have
been sold. We have received an additional 230,000 free trading shares now.
The two tranches were from different third parties, not officers, directors or
affiliates. We intend to sell all 230,000 shares now, which could cause the stock
to go down. This company has: nominal cash and no revenues in its most recent quarter.
It is not an operating company. These factors raise substantial doubt about its ability
to continue as a going concern. A failure to finance could cause the company to go out
of business. This is a high risk security. This report shall not be construed as any kind
of investment advice or solicitation.








In the human sciences, psychology and sociology vie with each other for supremacy. Against these hostile brothers (basing their explanations on conscious or / and unconscious motives, or on interpersonal relations, the biology of social relations) sociobiology and the neurology of psychic behaviour (neurosociology) proclaim their own supremacy. The traditional humanities (linguistics, hermeneutical sciences, history and law) investigate man as a signifier, bearer of and producer of meaning. We propose the search for the unity of man (in his biological, historical, social and psychical nature).
He who wants to have a future-oriented global view of the history of humanity needs a world model and an action model that enable him to make reliable prognoses. For example, the explosion of the world population is clearly a problem that has ecological, political and ethical implications. How can we construct a meaningful opinion about this problem, if we do not know the capacity of the earth and the origin of this explosion? One who seeks a world explanation needs a world description. A global world model is impossible without a place for man, who knows, acts and evaluates. And as we remarked already, the acting subject becomes more and more the whole of humanity. Every evaluation for the sake of action implies a knowledge of the present situation. A global action model presupposes a world model, and it also needs a model of the instruments, materials and possibilities. For example, can a project to populate other planets as a possible solution for the population explosion be taken seriously or is it pure speculation? Constantly one needs a confrontation between new insights and traditional models of interpretation. For example, are we sure that chemical agriculture and even chemical medicine solve more problems than they will eventually create?
The greater unification of humanity and the interaction between cultures, with the expansion of science and the increase of our technical capabilities, mean that our life plans are more and more determined by our relations to larger groups. We are confronted cognitively and emotionally with the whole universe, and with questions about the role of humanity in this greater whole. Ecological problems related to the survival of humanity on this planet have more and more become the concern of everyone. And yet, it has become increasingly difficult to elaborate a life plan, because it is very difficult to take into account the complexity of this whole.
As humanity increases its impact on its environment, as it enlarges this environment, and as the same humanity acquires more and more power over itself, the species disturbs the equilibria in which it lives. Cultural and political movements try to restore earlier equilibria or to promote higher equilibria on a more global scale. Theoretical and applied ecology, including human ecology, offer a theoretical framework. New facts and theories have to be developed (a theory about the self-regulation of the global biosphere or the total planet is needed). New values are discovered (the intrinsic worth of non-human species and of physical landscapes). Old and new values enter into conflict with each other (ecocentrism versus anthropocentrism).
The medical sciences belong to praxiology. Contemporary Western medicine has selected as its quasi exclusive aspect the human body, and has applied the analytic scalpel of the anatomist to each aspect of the body fragmenting it into numerous parts. Marginal activities, like preventive medicine, behavioural medicine, and epidemiology do not belong completely to these trends. The fundamental sciences on which medicine is based, point towards fragmentation. The anatomist analyses the dead body and the biochemist eliminates the structure and investigates the chemical reactivity of its components. As a result of all these divisions, a multitude of dualisms appear: mind-body, individual-group, organ-organism. The acting physician, to the contrary, is confronted by a living total human being, as much by a network of serial relations and by a field of physical states as by a physical body. The fragmented sciences offer him only a partialised image of man and his world, preventing him from accepting the patient as a suffering totality. No obvious solutions exist for this predicament.
And each one to his office when he wakes.
First, there is the North-South conflict, which is one of the major macro-problems of our time. Opinions of individuals and groups on this problem are quite divergent. Questions of how to evaluate the level of development of a society, as well as differing visions of possible interactive mechanisms among societies, play crucial roles in the analysis of this situation. Let us briefly and provisionally examine some of these conflicting views, so we can see just how such seemingly practical issues are effectively connected to profound questions of a global nature. We will consider two sets of opposite views (views A and B, and views 1 and 2), each connected to very different world views.
We will not elaborate on these questions here. Our intent is to illustrate the relevance of world views to present human problems. This seems sufficient to enable us to conclude that one needs a frame of reference that allows, not only the relationship of one to the other, but also to see the interconnection of problems that arise in relation to international, inter-economic and inter-cultural relations. These problems range from the world population explosion to evolution and molecular biology; they involve views of the nature and the role of man. These frames of reference are world views. They offer a model that allows us to coordinate different aspects of the world in a meaningful way.
In the human sciences, psychology and sociology vie with each other for supremacy. Against these hostile brothers (basing their explanations on conscious or / and unconscious motives, or on interpersonal relations, the biology of social relations) sociobiology and the neurology of psychic behaviour (neurosociology) proclaim their own supremacy. The traditional humanities (linguistics, hermeneutical sciences, history and law) investigate man as a signifier, bearer of and producer of meaning. We propose the search for the unity of man (in his biological, historical, social and psychical nature).
Communism and various types of socialism have developed in the prolongation of a dialectical materialism that cannot be separated from Hegel. Contractual liberalism, in the wake of market economy, presupposes the natural harmony of the invisible hand of the market. Various nationalisms (among them national socialism) are inspired by (doubtful) biological theories about species and social Darwinism. Present-day political ecology depends both on a science (ecology) and a world view (one of the many eco-sophies). We propose the study of the most influential political projects of the 20th century to examine their ontological scientific presuppositions with a view to the construction of political projects that take the most adequate and complete scientific information into account.
beef: neer ask me what raiment Ill wear; for I
The former proposals remain on a theoretical level. However, we look for the unity of the universe in order to discover the meaning of life. Value problems, the relation of ethics, politics, action and reality cannot be avoided. The proposals connected with praxiology, psychiatry, the interaction of language games, the ontology of the various ethical, political and religious systems incorporate this need.
Can general decision theory help us in this field to delineate rational decision methods for solving ill-posed problems in semi-unknown environments? From ancaudowde@gmd.com Sun Oct 15 20:00:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFu1-0001kX-6z for avt-archive@lists.ietf.org; Sun, 15 Oct 2006 20:00:21 -0400 Received: from [59.17.82.189] (helo=gmd.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZFtz-0005fY-Hn for avt-archive@lists.ietf.org; Sun, 15 Oct 2006 20:00:21 -0400 Message-ID: <000001c6f0b5$fde99b90$291ca8c0@efbdy> Reply-To: "Jurgis Rubenstein" From: "Jurgis Rubenstein" To: avt-archive@lists.ietf.org Subject: Re: VlkAGRA Date: Sun, 15 Oct 2006 16:59:46 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6F07B.518AC390" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6F07B.518AC390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VlkAGRA for LESS http://www.dertklionmasherin.com =20 handful of collar and shook myself as violently as I could. hadnt used it. ------=_NextPart_000_0001_01C6F07B.518AC390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VlkAGRA for LESS http://www.dertklionmasherin.co= m

 
handful of collar and shook myself as violently as I could.
hadnt used it.
------=_NextPart_000_0001_01C6F07B.518AC390-- From avt-bounces@ietf.org Sun Oct 15 21:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGyG-00057D-L8; Sun, 15 Oct 2006 21:08:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGyF-000572-6z for avt@ietf.org; Sun, 15 Oct 2006 21:08:47 -0400 Received: from stewe.org ([85.214.23.117] helo=h665227.serverkompetenz.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZGyD-0003yS-DC for avt@ietf.org; Sun, 15 Oct 2006 21:08:47 -0400 Received: (qmail 7152 invoked by uid 60000); 16 Oct 2006 00:20:41 -0000 Received: from 127.0.0.1 by h665227 (envelope-from , uid 60004) with qmail-scanner-1.24st visas (spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 0.783345 secs); 16 Oct 2006 00:20:41 -0000 Received: from localhost (HELO webmail.stewe.org) (127.0.0.1) by localhost with SMTP; 16 Oct 2006 00:20:40 -0000 Received: from 192.100.116.143 (proxying for 172.22.38.215) (SquirrelMail authenticated user stewe@stewe.org) by webmail.stewe.org with HTTP; Mon, 16 Oct 2006 02:20:40 +0200 (CEST) Message-ID: <63115.192.100.116.143.1160958040.squirrel@webmail.stewe.org> Date: Mon, 16 Oct 2006 02:20:40 +0200 (CEST) From: stewe@stewe.org To: avt@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [AVT] Please review draft-ietf-avt-avpf-ccm-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Folks, please take some cycles to review draft-ietf-avt-acpf-ccm-01, which was made available in mid September. I don't think we'll update the draft before San Diego, so your cycles will not be wasted. 3GPP SA4 is considering in earnest to put normative dependencies to this draft into the forthcoming specification Multimedia Telephony Services for IMS (MTSI, 26.114). The target date for this spec is March 2007, which may explain the sudden hurry. Thanks and see many of you in San Diego, Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From bfjplynnjkci@alphacorp.com.sg Sun Oct 15 21:11:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZH0g-0006FM-UA for avt-archive@lists.ietf.org; Sun, 15 Oct 2006 21:11:18 -0400 Received: from [196.218.126.232] (helo=host-196.218.232.126.tedata.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZH0Z-0004ef-NT for avt-archive@lists.ietf.org; Sun, 15 Oct 2006 21:11:18 -0400 Received: from 202.94.100.62 (HELO mxsec.networkmx.com) by lists.ietf.org with esmtp (BMCGQPGFJF KZFK) id V5CZII-ES3DB7-TF for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 01:11:12 -0120 From: "Karin Fox" To: Subject: Very important letter. You need to read. Date: Mon, 16 Oct 2006 01:11:12 -0120 Message-ID: <01c6f0bf$f83301f0$6c822ecf@bfjplynnjkci> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca6QI5PP9U20A2F4SIO9O89G751QM== X-Spam-Score: 2.5 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Read that note attentively. Here you will find the intimate news about GDKI. Please Read this news. Goldmark Cipher Reputable Hip Hop Creator Sean Combs A.K.A. Puff Daddy Wednesday this month 18, 11:40 am ET NEW YORK & LOS ANGELES & VANCOUVER, B.C.--(BUSINESS WIRE)-- this month 18, 11:40 am ET -- Goldmark Industries, Inc. (PINK SHEETS:GDKI.PK - Information), is excited to declare that it has signed one of the hottest producers in the hip-hop and r&b industry, Sean Combs A.K.A. Puff Daddy. In an violent attempt to stay ahead of the game, the Company moved quickly in taking on the already successful and growing star. Sean Combs, also well-known as Puff Daddy is the founder of Bad Boys Records marker. By agreement the among Goldmark Industries, Inc and Bad Boy Entertainment Inc, Goldmark has to get 78 000 000 $ for the distributing of Sean Combs A.K.A. Puff Daddy fresh album Press Play. revenue about from that deal for Goldmark should be around 12 000 000$. After the establishing of that deal Goldmark Industries, Inc will be the second biggest company in the industry of hip-hop & r&b music. Hip Hop superstar Sean "P.Diddy" Combs sees a huge possibility for his company in collaboration with Goldmark inc. Sean "P.Diddy" Combs tells that it is pleasantly to deal with these guys. They as anybody else know entertainment industriousness and precisely know what is necessary for the American spectators. He also emphasizes exclusivity of his fresh album Press Play and tells that the presentation of this album on october 17 will make an effect of the blasted bomb. Concerning Bad Boy International Entertainment Group: is one of the world's pre-eminent urban entertainment companies, surrounding a wide range of businesses as well as recording, music publishing, artist organization, television and movie production, recording facility, advertising and advertising, apparel and restaurants. With a collection of businesses whose yearly sales are quickly impending 300$ million annually and an employee base that is 600 strong. Mr. Combs is largely trustworthy for the pop demand of urban entertainment. In just eight years, founder and CEO Sean "P.Diddy" Combs has forever changed the entertainment industry by catapulting the music and fashionof urban youth culture into the American mainstream and creating what is considered by experts to be one of the most important forces in entertainment these days. About Goldmark Industries, Inc. (Stock symbol: GDKI.PK) Goldmark Industries is committed to providing the best in all forms of urban entertainment to the 45 Million Hip-Hop consumers in North America. The average North American spends clothing and health care on entertainment than they do on more , making entertainment the most attractive industry for investors and advertisers alike. Goldmark Industries is preparing to stand at the forefront of the Hip Hop consumer market, specializing in all aspects of entertainment, including Music ,Home Video/DVD ,Feature Films ,Television and Major Events. The strength of Goldmark Industries is the result of its highly continuously & reputable growing management team. The knowledge and experience that each team member brings consistently supports the growing success of each division at Goldmark Industries. In addition, they are associated with some of the world's leading entertainment companies and top distribution channels worldwide, providing Goldmark Industries with the relationships to continually move forward. P.S We will push that symbol till the end of the year and the price will go up . People will buy it and they will earn big cash. Don't miss that and buy it now cause the price is low. After the 18 October the price will grow up to 1000%. Take it now!! From sslfgszl@uclinc.com Mon Oct 16 02:36:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZM5f-0005Lh-F4 for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 02:36:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZM5f-0005nY-An for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 02:36:47 -0400 Received: from [60.20.23.102] (helo=[60.20.22.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GZM5a-0005Tg-5G for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 02:36:45 -0400 Message-ID: <000a01c6f0ed$6cd06570$4a16143c@7f039a02b0fa40f> From: "Nelly Lozanova" To: avt-archive@lists.ietf.org Subject: protest circulated signed whom Date: Mon, 16 Oct 2006 14:36:34 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6F130.7AF3A570" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 876202f9cbc0933cffbc58102e40f8f2 ------=_NextPart_000_0006_01C6F130.7AF3A570 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6F130.7AF3A570" ------=_NextPart_001_0007_01C6F130.7AF3A570 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Fellow National Movement ii is deputies from the ruling faction left of = group last is Friday Bankova Elka who. Social of economic policy followed out Siika Dimovska Vladimir Dimitrov = Nadka Pangarova or party in would am be on verge a losing or its = majority remaining of with seats. With seats seat it not coalition of ethnic in Turkish for am Rights of = Freedoms or mrf asked am personally or resign Thursday chief pr = Tsvetelina Ouzounova said However two refused or. Said an interview Standart daily Tuesday she spoke Bulgarian Radio Darik = Friday that they remain faithful promises platform at recent meetings in = people my told are satisfied governance country Radio second. Cuts taxation system favourable conditions foreign undertook improve = situation a this end is state should reduced cutting in items such as = hospitals holiday. Satisfied governance country in Radio second protest circulated signed = whom ones of divergence was Among which met promotion small of business = through of tax cuts taxation system am favourable or conditions am = foreign undertook improve situation am this. Saxecoburg in and fellow National Movement ii deputies from the ruling = faction left group last Friday is Bankova in Elka who or were initiators = February a letter slamming or social in economic policy is followed out = of Siika Dimovska a Vladimir Dimitrov Nadka Pangarova. Me of pass judgment said an in interview Standart of daily Tuesday a she = spoke Bulgarian Radio of Darik Friday that they remain faithful promises = am platform of at recent or meetings of people my told are. Business through tax cuts or taxation system favourable conditions = foreign undertook improve situation this end state should reduced is = cutting items such as hospitals holiday is homes senior officials letter = also. Up their Assembly seats pm possesses a no am legal force them he can = only expel group god may or ask absolution those! ------=_NextPart_001_0007_01C6F130.7AF3A570 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Fellow National Movement ii is deputies = from the=20 ruling faction left of group last is Friday Bankova Elka who.
Social = of=20 economic policy followed out Siika Dimovska Vladimir Dimitrov Nadka = Pangarova or=20 party in would am be on verge a losing or its majority remaining of with = seats.
With seats seat it not coalition of ethnic in Turkish for am = Rights of=20 Freedoms or mrf asked am personally or resign Thursday chief pr = Tsvetelina=20 Ouzounova said However two refused or.
Said an interview Standart = daily=20 Tuesday she spoke Bulgarian Radio Darik Friday that they remain faithful = promises platform at recent meetings in people my told are satisfied = governance=20 country Radio second.
Cuts taxation system favourable conditions = foreign=20 undertook improve situation a this end is state should reduced cutting = in items=20 such as hospitals holiday.
Satisfied governance country in Radio = second=20 protest circulated signed whom ones of divergence was Among which met = promotion=20 small of business through of tax cuts taxation system am favourable or=20 conditions am foreign undertook improve situation am this.
Saxecoburg = in and=20 fellow National Movement ii deputies from the ruling faction left group = last=20 Friday is Bankova in Elka who or were initiators February a letter = slamming or=20 social in economic policy is followed out of Siika Dimovska a Vladimir = Dimitrov=20 Nadka Pangarova.
Me of pass judgment said an in interview Standart of = daily=20 Tuesday a she spoke Bulgarian Radio of Darik Friday that they remain = faithful=20 promises am platform of at recent or meetings of people my told = are.
Business=20 through tax cuts or taxation system favourable conditions foreign = undertook=20 improve situation this end state should reduced is cutting items such as = hospitals holiday is homes senior officials letter also.
Up their = Assembly=20 seats pm possesses a no am legal force them he can only expel group god = may or=20 ask absolution those!
3D""
------=_NextPart_001_0007_01C6F130.7AF3A570-- ------=_NextPart_000_0006_01C6F130.7AF3A570 Content-Type: image/gif; name="team..gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6f0ed$6cce1b80$4a16143c@7f039a02b0fa40f> R0lGODlh7AHoAYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAMAD0ALAAAAADsAegB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eN/0KKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUqV6cerWLNq3cq1q9evYMOK HUu2rNmzaNOqXctWYtW3cOPKnUu3rt27ePPq3cu3r9+/gAMLHhy3reHDiBMrXsz4KuHHkCNLnky5 suXLmDOXbMy5s+fPoEOLHk26tOnTqFOrXs26teuymmPLnk076evbuHPrLl27t+/fwIMLH068OMrd yJMrX868ufPn0KNLn069+mfj2LNrF2y9u/fvq7eL/x9Pvrz58+iHg1/Pvr379/Djy59Pv779+/jz 6/eYvr///wAGKOCABBZo4IE97afggvgh6OCD4jEo4YQUVmjhhRhmqOGGHHboYWqlfCjiiCSWaOKJ E0Go4orCoejiizDGKONuLNZoo2wz5qjjjjz2qNaNQAY5mY9EFmnkkRfKo6Q8SDY545JLmiXklFSy BKWSVDmpZXRRbunll2CGKeaYZBpZ5Zlopqnmmv6V6eabcMYp55x0fsXmnXhaVeee+uXp55+ABiro oIRW9oCgfHooRKKMNupcoZBGKqlLtUxq6aWYQuropu9l6umgnGooBZKflmrqqaimquqqv4Xq6quw xv+aEKu0Ainrrc/VqiuLuPa63K7APujrsMQWa+yxyCarrHzB4mkEoctGK+201FZr7bXYZqvtttwy 2AxBzYZLYLfklmvuuejWJ+66AKbr7rvwxivvvPRSx+696dWr70P49uvvvwDftO/ACwVsMHEEJ6zw wgqpBMDBEEcsMa0MV2zxxRhnrDG5E3fs8ccghzwgHiKXbPLG+pqs8sosV4nyyzBj2/LMNNds8804 56zzzjzbFfPPQAct9NBEu9jz0UpdXAzBSDft9NNQRy311CsWbfXVjbIpAtVcdw0h1hx7LfZLYJdt tptjp6322jWd7fbbcMfdKdt0jyR3tXXnrXfed8P/+UffgAc+596EF2744UgLvizijDe+s+KQRy75 5Ic5jqAkkmxnNjof1fOaJJQXi3noxIJOuq+j22s5i5m3eHp1qb9+q+m5rn4j5r7J/h3tuvfu++/A M2f78MR/HPzxyCffd/FQK+/889BHL72IzFdvvb/T13l94tkPvv334Nfavffhl2/++einr/5b47fv /lnrxy///PTXb//9+Odv6/v89+///wAMoAAHmBz9gUxuW6CWAY1HwAY6sGALjKAEJ0jBmTzwghjM oAYxWEGIbbBIHQyhCFv1wRKa8ITUG6EKV8hCpNUjKijcUQvxFcMaZm+G97KhDqGHQ8zgoIdADGKm /3ZIxCIa8YgbE2KzkMjEJjrxidOTAxQXo8RgTfGKWMxiY6rIxS56sXlaDCOPuiBGhn2RYmVMoxrX iJUzsoqNFHKjHOlXjL7A8Y4vm2PAHqZHU/Gxj2yiCADw+J2Z/BGQayLkghBZKkXmhgeOBCEjJ0lJ lUSyT5XMpCYBU440oWGToIzQJUe5r1CaEpCkvM8pC5VK+6wSWq2kzytBFctaNoYDWpqlLrloy15u ShO+DObPdgkoYbpnVWwgpjIdZMz2LDNPjWpHM6dJTQs985oqrKY2t9k+bOIFE5XhpnW8Sc5ymvOc 6EynOi0lzna6853w3JAr4klPxKxTSPV81D33if++fDaHnwAtnz8HStCCGvSgZAmoQreH0IaCaaEQ jahEJ0pR/Dn0ohjNqEYxWtEDbfSjII1XRw0U0tSM9KQoTalK/xMWPZT0pTCNacZWStOa2vSmOBWZ TEmT0xb2oYU7DaqHekpUngn1qBoqqlKXytSmOvVPSI2qVF/11Kpa9apYjclUOdNHW2Q1fFsNKxTh IVYCfvWsASurWtfKFl7wQpWzlIZO3EpXXizVGL+pq109qkW6XmiBHUDrCNlK2LkJ9rDrKqxiF+sj xDo2XIz9EUTHIKzIWvaymM2sZiP32NlsdiydxdFnR0va0jYptLExrVdqU0fBqnanZATPPrOA2p5E vZYrtc3MbbeS29769rfADe5xdkvc0AhXMsVt43GXi6jkOve50I3ui5hLXahKVyPVHcx1sZvd7qpp uxnxLmDAS16zBAQAIfkEAAwAPQAsAAAAAOwB6AEHCP8A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGi xYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcaVASzZsm7encybOnz59AgwodSrSo0aNI kypdyrSp06dQo0qdirQC1atYs2rdWtQX169gw4odS7as2a0Ozqpdy7at27dw48rdirOu3bt48+rd C3Ku37+AAwseTJgs38OIEytezLix48eQI0uenLGw5cuYM2verJay58+gQ4seTbq06dOoDXJezbq1 69ewY8ueTbu27du4c+vezbto6t/AgwsfTry48ePIkytfznxm7+fQo0tv27y69evYs2s/vGO79+/g w4v/H0++vPnz6NOrX8++vfuGlo9Mn0+//t/3+PNbt8+/v///AAYo4IAEFmjggQgmqOCCDPam34MQ RijhhBRWaOGFGGaoIUzQVNjghyCGKOKIJJZo4okopqjiiiy26OKLMMYo44w01mjjjTgeteGOPN6V 449AatbjkETCFOSHRRzpYJFMNunkk1AypuSUVFZp5ZVYZkmUO1p26eWXYIYpJpZRlmnmmWimqeaa bJI05ptwxinnnHTWaeedeP7Y5p589unnn4AG+l6ehE4p6KE7FqookIg26uijkEYq6aT/qOLSopje SOmmnHY63BZNZirqjJ6WauqpqKaq6qqsturqq7DG/yrrrLTWauutuOaq665RjurrVwAA8OuwKwYr LLHImmjsscnq5kqzWhkL7bQfSmsbr7ECEBq13CqI7beLdSuugeCWa+656Kbr6LjsCqjuu861K29/ 8NZr77345ovfvPzWp++/I/UrsHQAF2zwwXgNrPDCDDfs8MMQR9wgwhRXbLFKEme82sUcd+yxRhqH nNnH+ApC8kq3nKxywSK37PLLIq68Msw012zzzTjnrPPOPOcss8o9B03XzyQLbbRQnxyt9FlEF730 00w1LfXUVFdtLtRYJ2X1xyhs7fXXuGYt9thkl232VGAffPba9qTt9tuysi333GLD/S/dZNutL958 9//Ns96AB96p31gLbi/hUBuu+OKHIu744xozrm6egUCulTmWQy755px37vlymQv9+eikl2766RW1 AnfoQaOeK+s9uy777LTXbrvTsOt8e9y56747rL37/vvwxBfPmBjGJ6/88sw373xxwfv8/PTUV091 9Dhbr/323APaQ/czY780E+KXb/756Kev/vrsty8u+JC6nzH8j8pv//34518Y/evqn/WyAAzgsvxH Jv4Z8IB9IaACF9gwSzAwQQgU1AP7FcFATfCC6XNEiSrIwQ568IMgDKEIR0jCEprwhChMIQZjI40V ujBqKYxh9144LhlCiYY4zKFubMjDHvqwPDqk1g//h6i8IE6LiEMyIrSQ2CMlOvGJQmJiCEUgxSpe B0EDhCKeBMgsLbbGOAC0Isa8CKRZkPGMaNyNGNeIHVSw8Y1wjKPF0pgpOdrxjni8FB33yMc+QiyP gFydH/MUyEKCbZCITKQihWjIRjrykfBZpCQnCRRIWnJH4LikJolIyU568pNv2qQoR2lHUJrylKhU EilXqbZUuvKMrBTPK7sUy/DM8pZPrCV4cMnLXvoSgroMJrx+SSVhboeYhjJmdpCpSmU685nQjGZJ mHkkaTaHmkGypja3yc1uevObvMNmjsBJznKCMx7mTGe4xMlO+6kTOO3E0Tt/E09NzfOe+ExbPWUU /46d5NM0+wyoQAdK0IIa9KA7/CdpENoihTr0oRCVYSwiuk6GWvSiGCUKRT+TURSxKQQbnWdHR3q2 kJqUSSTd4ElXytKWuhSPMMoDQV/amJSSiKY4lZBNd5q4nPr0p6viqVCHSk2gHoaoEzPqXpDKVOkp NS9N9dZTpwrEqCKIqliVpVW32rKs2oWr5PIqcZAnVoaA9axo1V8O0srWo5X1rXCNq1zn6ry2Aoiu L7GrXvfqQrzqEUuD4KtgBxsjvxqWnoRNrGLZdy9/AG6xkPXVYVcS2cpa9rLinOwYMZsbzXr2s+fh rGhHS9pPgjYnpa3NaVfL2mWmljacIgb1iEWM1zTOprZOpJRsW/uR3fK2h7adzW+HSzwnELd2wZXN cTuS3Ngs97nQRSIc8tXc6loXZtHNSEAAACH5BAAMAD0ALAAAAADsAegBBwj/AP8JHEiwoMGDCBMq XMiwocOHECNKnEixosWLGDNq3Mixo8eN9kKKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmz p8+fQIMKHUq0qNGjSJOS1KO0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rFmjH9OqXcu2rdu3 cOPKnUt34dm7ePPq3cu3r9+/gAMLHky4sOHDYOsqXsy4sePHkCNLnky5suXLmDNr3sy5s+fPoEOL Poi4tOnTqFOrXs26NdfRsGPLnk27tu3bnHvg3s27t+/fwIMHd028uPHjyJMrXz5WuPPn0KNLn069 unXRzLNj3aC9e8jr4MOL/x9Pvrz58+jTq1/PHqT39/DjI21Pv779ufLz69+f877//wAGKOCABBZo 4IEIesTfggw2mFKCEEaonoMUVmjhhRhmeJyEHHYYnoYghkichySWaOKJKKaYloghSsHiizDGKOOM NNZo44045qjjjjz+peKPQGLX45BEzhfkkUgmqeSSTDbp5JNFRinllFRWqdWTWGapVl4AWOnlly4B IGaXYJZpJkljknnmmmCmyeabeQWXppZ01omRmHbm6RucfPbp558s6inooAkBauihiCaq6KKMhkXo o5A2KmmGkFZq6aWYZqrpphBO6mmFnIaK5Keklmrqqaim+qWorP6o6quwxv8qa0ut1nrirLjmquuu vPbKl63AeujrsIMFa+yxyCar7LLMEuusj8xGa9+z1O4l7bXYZqvtttx26+23F1Ur7l3glmvuubXa k8647Lbr7rvwxivvvPTWa++9+aGr75749nvUvgDj5u/ARAVsMG0EJwzUwQw37PDDEJer8MQ8RTxd IxZnrPHGHHfs8ccgC0rxyCSX/FTIKMNl8sowpewyWyzHLPPMNb1s8804X0bzziTl7HMEFvEstD0+ F2300W8NzTPSTDek9NNQRy311FRXbfXVWPPZ9NZcd+1Q1mCHLfbYZJdt9tmpea32P2i37fbbcFu4 ttdxy/voMHPnPRAZeof/Vne8fTf9N7yBF244yIO/e7jRiTfu+OOQRy755JRXHuPicwOA+eacO9SH sZaHDmgMopdu+umop666l53fvLqsrdv8eqyx12777bjnrvvuEfay7+yw8t4x8MQXT5jwyCev/PLt Ge/889CLzXzE0VdvfWLTZ6/99tzvdv334F/V/fjkl2/++a2Hr/76TqGPLvvwxy9/te6fO//9qNqC //4i1e///83jnwCLkoLXAfCACEygAhfIwAY6UHsDjKAES/JAaU3wTBWM1gU3GB8z0C+DIAyhCJGV AL9xcFUjTKEKV8jCFrqweyfUSj829MIa2vCGBouhDuOHQ2DJoYdADKLT/3ZIJSFiiohITKISg0KA JbJsAv07nxLs58QhvXABrKqiFoFnxC568Yuh2qIYVQfGR41RR2VMoxrXyMYWnjFHbbTTG+douTja 0Y10zKMe92iWwOkCaXwMpCAHKb47yiUGhkykIgVGyCKpqZHdoYjmFtmkSVISQTR5JCQxpMlNIuci lrwkgTypIVFWpgvRISWlTMnKVrryPrB4pSxnScta2vKWuMylLnfJy1768pc+u4QDVYkhYBrzcMRM pjKXyUwRHROTzWTQMw8UTWlO85pqq+aCsMlNrmnzmybrpjgN4o1x+qecrruaN8CZn3Wy843m/M87 50mweNrznviMDSryyf/PfoaMnvDxp0AHakSAGvSgMbyUGYQIJw/uD1MLBSKfHIpQ5lAUOc6o6EUr mpyNctQ4Hl3fpiJqQ+hB8VOtYgRBV7ol+JHDUCw1z0eXE9PyzFQ5NSVPV1RwU6Xk9KcSg1ELekpU sgD1Q0UtzlHBk1SlLvWp2GqqVKeaOqhWh6pYzSrlrEodrUZuGMbj6nS8ihqxSoesaG2UWdcarLS6 9a1kY+tz4GoYuTqHroWxq3CWE1K8+vWvgA2sYMGp1+EM9rCITVhhF3vExDr2sZBFHWMtQ7TJei8j kc1sjSzLWZHhqAhj7CwjNWtU0dqGtGUxrWpXmzLUutaZrJXNBgkBpthb2va21HutbnebKtyOhrfA Da5wZ+bb4hr3fcO90nFrlYV7Jle5y41ugp6bFelyhrpYse5msFtI7Xr3u+nirnjHS97yUg286E2v pswbFfVShr3wTZt750vf+hosIAAh+QQADAA9ACwAAAAA7AHoAQcI/wDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlxp8p/LlzBjypxJs6bNmzhz6tzJs6fPn0CD Ch1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTqt3Jsq3bt3Djyp1L t+7BtXjz6t3Lt69Su4ADCx5MuLDhw4gTK17MuLFjv5AjS55MubLlyztrYd7MubPnzy9raQZNurTp 02RFo17NurVrpqpfy54907FtwaJv697Nu7fvubl/Cx9OvLjx48iTK1/OvLnz5w9pS59Ovbr169iz a9/Ovbv3nNDDi/8fT768+fPo06t3O2K9+/dyv8ufT7++/fv48+vfz18v/P8ABnhYfwQWaJ+ACCao oFsGNujggxBGKOGEFFZoIVELZqjhhh5d6OGHlHEoInNBjGjiiSimCBeILLbo4oswxijjjDS6ZINP Kuao44489ujjj0AGKSSDnyVT45HWDankksUh6eSTUEYp5VdMVmnllVhmqeWWXHaZ0pRghomTl2SW aeaZaPYm5ppsvpTmm3DGKeecJ7Vp55145qnnnnz26eefgAYq6KCEFmrooYgmqmiIdDbqaEGLRnrg o5RWaumlZ0qq6aacdpoUpqCGKuqopJZq6qmopmoXTaN46uqrsMb/KuustNZq6624lqXqrrz26uuv wAYr7LDEFmusSrkmq+yyTh7r7HvMRgvZs9SmJ+212Gb7YLXclqftt+CGO1+35JZrLq/i0ipPuuy2 6y6b58ab3Lv0ViXvvU3Wqy9U+Pbr778AByzwwAQ/tu/BTBWs8MIML4jwwxBHLPHEjDZscVwUZ9zT xRy/pfHHIIcsVMckryTyyTGVrPLKLPOG8sv/tCzzRzDXbPPNOCM888489xxfzkAHLfTQeAZC9NHg +ay0REg37fTTUEctNX5YTP3x0lhnrbVGVr+79ddgh61Q1+6KLTbZ7fbKj9lstx0Y2nDHLTEAcodL d901LgYAAG6T/8rX3XiflgaBgAd+7d6GZ1t44ow37rjjfWv9+OSUV245WZFnrvnmnHfu+eegv3k5 rqGXbjq3o996+sqpV7ZN67BHtfrstNduu5Wxz3r77rz37ruGuQcvfHW/Kzz88ci3JjYLYSfv/POf FV8w9NRXX7H0AVuv/fb+Ye/99yIZgSD3iIIPMPnopy+W+f+qTyj78Mcv//z0b+7iFqbt4v7+/NV/ Lv8ADKAAmZUmX/jvgGYbYJ8QSC4FOvCBQWFgtyCYJwmijoJ3sqAGN8hB/2HwgyAMoZ46eCyb8SFk JDSWCNeUwha68IWzW6EMIQjDGtrwhjjMoQ5fOMMeDnCHqvKhEP/5B8RU1WsRQ9SXE5LIRKX4oYlQ fFwRURXFvE3RVFXMYvKuyMUuhkSLYBSeFx9SItGF8UVjTKMaK3LGNrrxjXCMoxxtskZMzfFCdbzU HS2Uxz760SB7DCTc/vgoQU6IkIhMpCIXychGOhKBhpTQIydJyUpa8pKYJE4kI5RJhYRDSZsMpdM6 ScpSmrJn6iClKFeZPHGw8pUEPOWVYEkgWc6Slrh8mS2vBIhdLimX+/GlMIdJzGKWEJj5MWaQkJlM Zf6ImdCkmDOfGc36MJAMF6ymyPC3yWk+6hfeJI8gF6dN7SCuJgYo53TIuS3wfeA2fBtSHM9ZIVvG M5y0U6d88Mn/T/vp85/s6qdA+wbQ7gz0oAks6HYQylAE1qKhEI2oDRW6UIkCj6LZsehFMXodjWaI oyANqUhHStKSEuoABzBpa1CaUnt5VDEsfel/YnocO8i0IjS96XsOsCqVykanAvKpUDcF1KIab6hI VZRRl8rUpjr1i0ldzVPV06ZKfHCqWM2qVrfK1fNE9atgDatYx0rW/nR1PGVNq1ptdlbxrJUzbQ2P dsqg0LjatVdv3cxdnZPXvvo1YnsN7Kn+WhnBLoew1zOscRA7GcU69rEvtQQ+GesgI1CWLZDNbKMu Oy3NDoezHlIBaH3qANd49rOj3ctphZPa1kpytb5xrWxnyynYYtq2TLRVy213y9veejC3wG2mb4dL 3OLyLriUkQJyl0sb4zr3uc9irnS9A93qqmi667OudrfL3e5KELvgDe8MySFeVnr3beXlynkBk972 vmav12BOWK9RmsDGd711uS9+lRQQACH5BAARAD0ALAAAAADsASYABwj/AO0JHEiwoMGDCBMqXMiw ocOHECNKnEixosWLGDNq3Mixo8eN/0KKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+f QIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q8uPYMOKHUu2rNmzaNOqXcu2rdu3cOPK nUu3rt27ePPq3cu3r9+/gAMLHky4sESviBMrXsy4sePHkCNLnky5suXLmDNrzmm4s+fPoEPn3Uy6 tOnTi0WrXs26tevXsGPLnk27tu3buHPr3s27t+/AqIMLH068uPHjyJMrX868ufPn0KNLn069uvXr iV1h3869u/fv4MOL/x9Pvjzk3+jTq1/Pvr3794Jjwqdrvr7i+fjz67cbU4B/e/8RJACABQ3o34EB ImigggcO1KCDCBYYYYEUCmihQAw+COCDA1ZokIYESpihgQLZZyJmIQboYIgrdughhhdCKCOLLLoI Y4wE2ugiiS9uaKGNNwq4Y4dA0ghkhycmmdVERBoZZJMfKnRkhTquuNCONf4YJY5WckljilsGKeZ+ ZNYmX5NVZvnlmC8WmWOMbnrIo5NFphlml2y+2WaFSvZZFZM3YqlmhhiqiKObcxppqJxqwlinl4Uy 2KOjd05Z5qXvQQkmpXkKuWeUCiK0aKBWCvqlnZNaSuGjeK6J6aurnTj55KymSnnoQXPGmWeuioLo JK53upqomJb6aSxjm3Kqp6uV9qgps8JmaaequwZ7KpuoEnTstk0FBAAh+QQAEQA9ACwAACUA7AEm AAcI/wD/CRxIsOBAewLsIVSoMGHChgshMpxI8aFEhhYlZsxYkSJEiw4nguwo0mPEkiQxXlTJ0qPB lzBjypxJs6bNmzhz6tzJs6fPn0CD/ozIUcBGlClXFgX5sOjKkyKXtlRa8ShHqA2ZTnWKUqjXr2DD ih1LtqxZmSbTYjSKle1Wo3Cbxk269ijJuFenQuX6NKvbq3kRuo06WG9gtYgTK17MuLHjx5AjS55M ubLly5J1Yt7MubPnyGdDix5NurTp0zk/q17NujPq17Bjy559trXt27hz697Nu7fv38CDCx9OvLjx 48iT59a8Oqby58FpS59OvfpM6Niza9/Ovbv37+DDi/8fT7785nzo06tfv34ieorvF3+gOH/i/A/4 7dW3jxi/f4b7efQfgPQVyN+BCg2YoID6+RegfQ/m919+/DlIIYHmZaghcTrlo5aHDIGokIjxheih cxguGGB9LDKo1ooLCrgfhTDCaKB+AM7YYoE20hfhjheq6COG1hVp5JGvQSaiR0s2GaI9JELZ2Iw4 xljlg1WmZSOWWVpJJZUuZhmhlQT2WGGZMd535o1cbujmm8ctCZ97dI4opZ1y9oeml2T2eeOVYR74 ZYo8Errnmn7iOCigNZq0I5yQRvpZh+09aamdmHoI4okwsSkmhli2maCDhnYJ6qFtqpmoqoiamiag sC7/amB9SNZq662x5XkplOrVqamdKJ766rAIOipooMKCKaqZh5ZJqrGKDqusq7Diau212Nak5Id1 3ompt7q++OmWyP4Zrbl8ygrtqq6ymmqKQJ7K5aOS1mtvbuF6q2+U3+ZrrLr0Jmooq8V26S61A8/K ILN8SntmqPdGLDFoOeXrpK8mcfqSjEMKW/CfAY+aI4Qda1nyheR+PC+xIv9IZLYwx4zttmldTKeu /q5L5oQWNvhsjgpauGKQCespY6hBI7vyhEMKje7EUEfNnGrBRg2ezFhnrfVBzXVqdXhbhy02bF+X bfbZaFM2ddpgj+3221izLffcdNdt991456333nz3/+33YlPzI/hEgxNOUeEMIW6P4PwQ3rjhjDNu 0uMKUV55WpJ7FPnikW9eueKdJ95546EnZvnnlD8O9+qs4xoZ4oUrvvjhp8ee+uOyk0475IZfrvnt ovfue/CfDz/78YcL/7vlsiP/9/Ny134588mnfrz0s1N/uvO6J+695skbD77y1/e+Pfemky8+9Oxn qNP5ulPP+/TOe989/eNnX/3k/J+vPPzoq5/x/Pc9AfqudQhMYNYAiLsC+q5795uf9QCIP/vxD3wE HGD/PMe50MlPLbfL3AEVSMISogYyDPwe9iBowPs1kILWU9/69IeYD87vgZPjIAgdGMP2+dA87+uf Co7Dh7wIWhCHMNShAVu4RB4K8YbCy+DwVqgQE1rxirVBYfi0R8QYUtGC2+sh9i5YwAyOEYdQdGIN HdjEH7rRO5qBXQMdR0TzAa9+g6vdHNWYQ+Jx7n+7K14AKcjGOoqxilhMpCKFMhkR4vGMPATd7kZH PhvmEH6ObCHoODg6I2pShI6U4htHScpSmvKUyAkIACH5BAARAD0ALAAASgDsASYABwj/AO0JHEiw oMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXGnyn8uXMGO+ZEmzZkiZ OHPq3Mmzp8+fQIMKHUq0qNGjSJMatcm0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHWtPqdmzaNOq Xcu2rdu3cOPKjWlnrt27ePPq3cu3r9+/gGeSHUy4sOHDYD8gXsy4sePHkCNLnky5suXLmDM/Dsy5 s+fPoEOLBq25tOnTqBmOXs26tevXsGPLnk27tu3bslPr3s27t+/fwINXxU28uPHjyJMrX868NbLm 0KNLn069uvXr2LNr335ou/fv4MOL8h9Pvjxs4ejTq5dqvr3797XXy59Pv779+/jz69/P3+vQpjkN FGBK8BVoYFz9Jajgggw26GBp/9kDwIQArDRgWTiBo6GGA23YoYcCbcihPSKSWKKAB6ao4lkTVdgV OAbBGOKMNMrY4UE2Pqijb0O5WBCFAgE5YZBAEukihUcOlCSGMqEoU44kFgSjjTJCCSWNBK2o5ZZx +ajkl0tW6KOXEpYZpJlmunhhTiJOKWWUNYJoYo5XcmldJ3aCRiaaYp5Z5phG9umnoFni5GRMVr55 Ipw43lhQnpBGCpNEewIaJp+YAvpnRokS5CajVzrK6I6k6hYQACH5BAARAD0ALAAAbwDsASYABwj/ AO0JHEiw4EAABhEKRKiwoT2FDyMulCiRocGLGAmCK7hRo72OHT9mDBkyo8mTKFOqXMmypcuXMGPK nEmzps2bNf/p3Mmz506KEyc6jAjRotCDSJP61Dlw6b+SAklGHQhyJFWDTrNq3cq1q9evYMOKHUu2 rNmzaNOqXesVJoC3Dd8GdQi3KFyKRQlCdAk1KjipV/8K/jj4Ks7DehErXsy4sePHkCPbExtzr0rL TZdm9il5M9vPoEOLHk26tOnTpiVjRrm6s+vXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMr X868+W7U0KNLn069uvXr2LOPdc69u/fv4CVr/x9Pvrz58+jTq/8avr379/Djy59Pv7794Ovz69/P v7///wAGKOCABBZo4IEIJqjgggxmd9+DEEYo4YQUVmjhhb4lg+GGHHbo4YcghijiYQ0miEqJKKao 4lYjejdHizDGKOOMNNZo44045qjjjjz2eNOKQAYp5JBEFmnkkUgmqeSSTDbpJFc+RinllFRWaaV3 cl2p5ZYQZolVWFwK9+SYAwKgWZhoptkeZff1dZGb4YVE5pwH8lUYYYUJRtJfhk2lJ0eD6QnSnYRR tSeffPrFkUaJijTVS3cKamijfgX655+KZjppVY/CqeanJwEGVV+iegSYo30+alCjiY6656KqcmmK Kkunzuqpm6cOaiisIsnqKajArmrYqLz6aeqwwnr0Zq/MLrrRs8rO2iuikbZqK6+1IpssqlVBS6yx 3wa7pViiViursYFpyyirlDLrrbDv9klsrtwWGm2sqQ6Lab2duoutvR7RKfCAAQEAIfkEABEAPQAs AACUAOwBJgAHCP8A/wkcSLDgQHD2EiK0B67hQoYNFSaciPAhw4sSMU6EGFFhR4oXK2oEKdLiQ4sh QUo8CXHjSI0sXWJ0+DHmzJQoWX4EabCnz59AgwodSrSo0aNIkypdyrSp06A0VcpMuVEkSYdSs7o0 mdEq1oVgq2q1CpNjRJQvbaIVK/Mk1q4ZKb7dKfGp3bt48+rdy7ev339h47ZNO9Kr1pds4VJdqThu zrKME4+VuvYw5JiBJz/+y7mz58+gQwudSpqy4K2OBZO1eVry47KvVatUC3sqa66oEUO+yTZzY92l gwsfTrw4cVDGkytfzry58+fQlyPlSrPiW48m5yaOWt1sbspfv6v/3nl2dsfK109H5f2dem7flxOK nk+/vv37eaPr32+8Mv//AAa3EH4EFmjggfYFqGCA/i3o4H4PISjhhBRWONCDGGao4YYcdujhhyCG KKJ0R/Hn04gmWqjiiiy26KJAKAoHQIAzKlhjjDjmqOOOPPYYHFIABHnjREMOd+JGQwopk5BBJqSk S0VOVWSTTt44pXwvZqnlllz+tZyVDzJpD5ikzUgmkVBCmSSSTrbJpo9wxinnnHQ+BySaZo5ZZY1P 6mnPkXqeGaWbZ/r55qFXBirln1026uijkAL1JZ58GmpopcPl6aalbxYa5adE9knloIPWaeqpqKYq IpBPgpmkmBsB/zrmqGguWaulVjJJ5aW3ErpmpMAGK+ywBCWqaK8uyapoobd6amuam16JqZ7EVmvt tfRNiiiutZa6qKZ+Orspp+QK2mm0qqarbnNerOuuTHduOyufu9YIKKzzNqsmqIfuGaqx9WKJ7cAH ekGwsCkaBC1/3upn78EQ42dwxBLK2XBzFzuX8bscu9tuxyCHLPLIJG/4cckop6zyyizbc3LLPCKF sYzJ9jSRsnZSrHOXE++c5bwbj7torDYLXFAASCNtT9JKMz2R0gkp7fPUL/ZMNYtBL1xmzQobTVAA U4Ed9dNRi7002FenraLValMIcL6jikqrn4D6ZPZGZuc9Nth8M9Ta9t+AB35iq3gSyqurbtbdE9N6 j+14330LLvnkf5+LaaWIt1mk4gbdTXbZUC/9uN+Ul246xJYbfuzq4Hp9oesCee646LTTLjbap+eu e4vPmRvu4YWTa5zstTfuOfEwJ6/88jviy+vv+BIufHHEN763S8gzr/323H+Ydffghy/+ujI/+x/n BSW8+/rsd6kuzsa1L//8Bb5fNHP0569/U+NP3///G1kEAMWnq319b0+7mhlzjJWvATqwOR14YIzi NTT/BeeAW4PX/YBWJX3t74MgJEpAAAAh+QQAEQA9ACwAALkA7AEmAAcI/wD/CRxIsOBAAPYSKlSI MGHDhRAjOpRIsaK9hwsNClwIoGPDjgxDahxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmyUxQsT4EeTF kDs5+kTYc6jRjwlHhtT5sKk9nFCjSp1KtarVq1izDrRI0aPOn0CXhh27FOlEpzy5ng06sa3at3Dj yp1Lt67du3jz6t3Lt6/fv3+Jgkx70ePaiDwNOz3rFexcw2EXA55MubLly5gza948uSVHtofBEpUo ebRb02STagxaWqTW17Bjy55Nu/ZNupJP63YLGm1kx6gdq0XdmrPx48iTK1/OvDlkoT4dPv/Ku3Hi owzNcm0svWn05uDDi/gfT758Xc95qdtVL1HpZ7i248ufT7++fax62cd9/tZ96or3BSjggAQWKJV5 CCao4IIMNujggxBGKOGEFFZYnoEYZqjhhhx26OGHIIYo4ogkZmXhiSj+dUyKLLbYV4kwxijjjDTa 5OKNOOao44531ejjj0AGGSOPRBZp5JFIJqnkkkw26eSTUEYp5ZRUVmnllZgJqeWWXHbp5Zdghinm mGSWaeaZaKap5ppstunmm3DGWRKWdNZp55145qnnnnz26eefgAYq6KCEFmrooUjKqeiijMKG6KOQ RirppJRC2eilmGZaU6Wcdholep6eqOmotyWkSaiopqpjQAAh+QQAEQA9ACwAAN4A7AEmAAcI/wDt CdQksKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDNuRHkqS9kiZRFjQpkGVLfithvlxJ E6VMlQZV2jyZ86RMni5hlvRJ86XLmEhbElVqtKjSoDFT6vwpdSjUnSKzat3KtavXrwd/9mTKc6lZ s0GpMhVbFiFbsmKFqoValu7bnFTnqm17s6fdsGHztp0JF6zhw4gTK674r7Hjx5Ad391bF+hgoZYr Zx7M2enYy5kx963c927R0k9JA44bujNb0ZtT8x0bubbt27hz697Nu7fv38CDCx9OvLhxrLPXWmYN W/NRnD7fDnXKXPVo1LHdKkeNvaZf1YFZwv+WK14zaHvG06tfz769+/fw40+Oune0cueEyWpPSLn6 ctnXhXYUfv8V6N2BzX12H2ZjMdgZevFFKOGEFFZoIXzz3UfggtFZlRx/CvX3XYEMBujgZTtxl9pr oKkIWIOynfahQRfWaOONOAanTI64ZZgci57FVqJ+L+43o4MpJWVfefr5R5RgP464FJBBnsgXZWXx qOWWXHa5HkU+OtnkalKSV9Vr0zU5nWBsJpkfdC0iBWV0eDGJllU6rZbnmwou5uefgAa6EXCCFmqo oF4mquiijAp36KOQHtbopJRWSmGkmGaq6aacduqpQoR+KuqopJZakKWowmfqqqwaBIBHr77/Sqqs FKVqK24bAaCrrhjRWtCuvirGq0DDAhrsr8f+6euurgZbLK+x2hNtRMki+6tFzDJUbavchnrQthMd Syu4Xj1LLljVFhsosNJe2y5C5l57brjjVlTvQvMmVFwIt/abkLjDTputtNCqey/B4wYcsLzvZjvw wO1GK6vDD5ur8MQFI4vxxd8SSyzFFnvsMbsfb6yxq+92nG7ELEtccsnOIhzzxC83LPLNIzcMcs4I i9zvz4/lym69C/OM8800G53ytBEnjXTKKLsctbsMGy2w1UtD7a7TTHedNdEoK1112CQz7PLZYy+b ddVeJ6121Fx/7fTR3NbdM9VPJ8zss/BW/7z3wW3jDWys4oq8sdcyy7234TIHDi/jWIMdebN//2sw 1W/TjLbkUCPOOOGLS32056BDa63dqD8UM9Z9a20z3QR/nXbY32Y++e0sky025xovjrvjucOuLs9v d/55y7Lj7LnNTOfc/MyYa+1svqn/6S3teUc/tvYHBw988cVLn7z3419NPu/Kl68+790X3vzaoyP/ /dTpf7x290/DD/zWAgHt//V4q9myOGY/wQkwZDDrHAEhJr7E3YtkECya24qmM+zN724O3NoChxfB nWFPfjqL2+wwZ7L81a59HtSbu/73s+p1inqog6ELZ0jDGhqKgTb8YA536EIA8vCHQGQVC/8vNAvi BPGISEyiEpe4rlXJkIlQjKJEBqdADgKOcodL2AmfpxAqzgtjp4tdAvM2tLLpr2dlo6Lrtkiv8FlO hTUrIETUiK2+DU+KSVydCcUIv/E164NuDOAX5Riv/LntX48zpCI7hq86Gg5cnEPcE5/YxUSuEY9A 1OMZ/cjJ1xUugIJ0CNjMJ8LlgfKKr0ulDk95sW3hr5GRvGRDAKa5OP4NfCc7YNwERkAMYhIkwIEg 7R64vcQZ05N2xCHM3odI5yHzfgO83ONEV0qIQZKCpqzfLLM3MmXia2jy2qUOiam0WFLQj0NMFUU0 aca5fTJ4/HNdION3Mt89c4KFFB4iqTnfxjWCzpdNs+c7YcfI9QmuYG6MZBlZabGMcZN8vSPcLwvF TqTR8Z3vGxwz59lAbcWzdKZTnyWnJsk9gnKfBdUkQQ34O2qltI/W+uQrY2dOltZuosYq6P2GacmM 6s6C9DzpS+nHukOOlKfxVKVQVTZCfYaSp7Gc40tRKbadpq+m2uQoTjESzDKGtJwMzaLxEmg7QHoT ctvjItHSWEmLqlWY30SgGRtnyy2WEINnbSbllNdLaT7yrn573gZllU5U7ZCSR51Vry6C2K069rF6 1Uhjm7hYe0H2spjNrGY3G8SAAAAh+QQAEQA9ACwAAAMB7AEmAAcI/wDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjf9CihxJUuTHkyhTqlzJsqXLlwdLypxJs6bNmzhz6txJE6ZPhwAa Bv1JNOXQogqPPlQKkSlGnlCjSp3KUyKAo1eRFnQq8GpWjEq9DsRKUWxXr1jNjkVrD21QtmfXbjVL NmndiVy1diWYd2vTsQudvtVLGObXtn19ck2MF/Deto4j3oUc2eDiyEMPH34MOTNDzRUZFw0r9C9n hHlFF14dk+fgwYgzq51N96tYzbZrk7Zsu7Nay5V9v6XteTfm4I8vcy7e2e9e2IEpy/Ys/ezk2Nan p6UufLv1tZt1g/+fvpxvVrjY0z/PHZSq+/fwoVptzhR6fcrNnyfHbx8/crK9ncZXcP3pt55zxwmY HHp3MQddeZslVR2A+wmGGn8YUmhgfhBW1iCGA072YYjAXcfaiWDtF1uBbAHYYoUvbvgfYCMCJ2CB 3T14Y4IX2riiY9xlFxdvu7324muIISikhhz2x+SKOILYpJAclrfgeSXKheKWBUFFnZM0hiljdVVm 6ONxNSJ434f3KSllYsqRSWabYkZHn19IDukfk2Bu2OeOp7FZJ3MDdjhmmVnFp+iijIY0H4l+mhnp l5KWCeiUKnoIJJp1Frqnp5v6WFebQcqZUFogXifioJX++SCfnsL/mqaVU1poIZdceulcjNLpRt6c 36UqmHj8zXbmb1heqWCwBNK17KqkXsoYquqNCtpcyWJKHIvsjTcXs3AxeFC22unZa3qNpqtuVHqp 1pJq7uIq76nzZhRvvfhGJJ9Gv7ULVL4A2xlwYy+tazBOTKQ78MIMN+zwwxBHLPHEFFds8cX0Snhv iv8uhfHHj3K5cY8gf7TvmeP6t1K8cOJpUb9ljaxykuZqlRrMZb20scwo63vwz0D/Q/KFPOfc8dFG z2yVzMNqSVicGxXNktTIQRT01etSymBvUaanNXHemuck2OX+muenITqrbKHeed1tmLD5Cl7Y4uFW rnozxx1gd9i2/4233m07a+12Yal9J3ZbB/4V1ozb9CihtWJqKOSugiorpIjSvCrmf+4aaKx5H84q 55JSXul/3FXO46Gad0rh5Z9PGqSqaCtdMkG6Ink55B3qTiOvhXN64KRLYr6jrMrJ5rRboc95G5DP rxd9ccA3H32rUgp73q1Q7hkj4OSCDmuCLRLeXuPov+f77mO+LrqOJobf4Nn0f0on8csVvrVc96tY Oeyhgl+nPieoSAmvWKCznOdKtbnIxU5y2RJI+iY4lVSxqmsWzJTqXGZA/bivfSnTYPaMUzsHgsqE /xOT6Z50QAAaJ0ovdN3osNfCEc5wShSkIMHkZLbszc1KgwsbuP9uQ6yyFe+EP/zRkiJEGmJVi4S9 Cp8SwxWgL+1NeX3zHuGUSD4i3g9sXvOQ3fS3Rf1pbzh+u91qqJYvlmGMjSiBo83USMeM3c6NFMPZ GiMmxzr68Y+ADKQgH3ayQRrykADLoSIXaZLS4KWPAIsgIocWMpVQjWeMzOSiTsI0jsURaXejFdKe 9sgIra6SRnHTZyZJx05eBJIvM14CAWkiH0rmXa9kJWvkIzgq9fJvWDLb9rAFLLwhTnHBepUs5/ar MBppjMR023CoJE0rpjGBdYPZL6lIqH4VcZhT5OK2ogk4CWrynIxzkaF88ywtaWh2AbShqSb0OyU1 c51jw18J39nvQeKxkEipe5P4AqpOpcVQa3C7YNXYiSF0OjRo48sRAtUkPHh6UHLFDNfpHvjAFOqT hPzU1vWeCU6SbfCgaAIe90rnz9+NNIvms8dDZ2qwiArQPLMMKUrrF89RbbSEtfMoChVooBUqdDGp Uagobaqy+oBUhS0FYUd9SNOqNoqp/4zh5Djq09iZzoSaIupQXSjWuH3UTJuj00nFV8OVopSeFz1r Dfdi1brGJ4x0uyITxUippgaUWf7zZTLHJTds2g2f1ExmFaVXRhW+za+HjYuq9jZFvQ6rhxP6ZRSF eMRg2fWzVEEkLC2ZS13iC7SoDQgAIfkEABEAPQAsAAAoAewBJgAHCP8A/wkcSLDgQHsIEypcyLCh w4cQI0qcqBAAxYsYMyK0qLFix48gQ4ocSZKhwZMoU6pcybKly5cwUZacSbPmRps47QHYOZJjzp9A gwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYrcb8F9JnQ689dXb9KtYo2JJng6YNm5Snw7U1t8qd S7eu3bsGNfqEW3ajW78TLQrumzHtYL0g+SZWu9DrzscJIfv9e7MyTcWEyXqUiHkh3s+gQ4sWuvfh 48NlO3tU/ZYsa7Q4X5N0zLB0X9qWZ2JWLDurb6FbOQqffFMwz9ONMxd/e3z4YOFukTeWTD11dOu0 pVeMfl3nX8mRuX//B09cLHSw2qt7p4w+uW3i6Smv33vdOHrx0+07p149vnzRAAYoYIDDmReZd5a9 Z2By8zHonIGoRbjZghC6V6B7B2ZYG4WotVaagqtdiFtmz2k4X4fmkXfbgQp+yOKFGqJImIsuLldj ZgPmqOOAiJV443v3jdhiZT5yuGKMKx6GHH0btugYZPoZ9xWULJrYIH3k2bbkkbmRyCWXUU4oIYhJ 1gakkTRW2eVvbEoUXIU/IonhjCYWWOSYdaoJp56A6XnWcVUaJmSZucWpGZpftrdangkq16ihYjqK YJrL2einZztmqummAh0JKZklRprhg0VWSqeppVKYJ5mIDokkpIQm/3qphFZ6ymisg8L6qGllxokn kQhxKuywLHUEZHeAOSkefpuRuqB6JPL34JXhtadstUoyux2gRKq4ZbX5YZkte1OKa6an8vlXaJBr QvuctNNiB2Ob9F7VW734ckbvvTUpehG/+QZMmsAEj9UmwLoxyJl8Bde7VcMQRyxxxMRWLNfEGGes 8cYcg/Swwh2HvOFSDOtLFMImD6yQxSy/pNe3FGkXMG8E+8sWr//W+tO9fLGa8JoiexxTozFLTLPA KEN0dNFA55T0yJLC1mXLVI92G3jelgvfeVhOJmJ+j2I9nn3llafiemY3tzW4Dab9Z3P1SYug2+eV jfbdHUIpdtd3b/9bqXT92a0f2Or6PbbXW7tV9eInfXSmq5Ha+SWihY6a2qyiKgw5odPG+yvRlVv6 N6q4Hvqhv75mnuTXpwNNK+ivX065kU0HTdHHj8v8p5qeI65ltFi/CvPVUG9eY+fFwZy37o9znjyV qO6+q+Yv6o1trsJDP/eioa+eJbCpN8r4+HTBLqn0z5JuKIqGvQryfZmP6Hz6qsYa9aSB8m7q9OHF r1zz51rLp7y0He6dyn7NUt+lbkI+8jnOfV1Cnew+9zr0IU+BtRpU9+anJAyqilV4Op4HZaTB+oFJ VpCrIALplMIFAmt2KrTdR3Anp7O1TT37GVsMweY9vuGNbNOxm9vqXthB7BBNbn7rFQ679bVJpSuJ gkJX3YSIt21N0YekK6CWnjhBZEFnRQ0Mo8uO0hueyfCBZ0yjGNe4EqSU0VhpREwcZcjGOjauY3bM ox73yMc+5ihkfgykIAdJyEFO6WdKKaQiF8nIRn7mZjyEmiT/dTjBPW2OmMykJoM1NJDJyZMTytkI m+bIUprylKjkysumGMHE0Y1tMhrlJTdJy1ra7k37a2UJKbg9B83qbKkMpjCHecobWSlvEEyR9qg3 ypUR85nQjKYejalL/1GzfcmMnT2kyc1uerNl1DyiNTHnyfDJ7pvoTKc6WxIQACH5BAARAD0ALAAA TQHsASYABwj/AP8JHEiw4EAA9hIiRJiwoT2GDxU6hEgxosSKEBtmtBgRo0aJ9gyKHEmypMmTKFOq XMmypcuXMGPKnEmzps2bDnPqnAiA4UaNPXn6HEqUYlCOQHsSTcoU5M6nUKNKnUq1qtWrWLNq3cq1 q9evYMOKHUu2rNmzaNOqXcvWqrC2cOPKnUu3rt27ePPq3cu3b8KbgAMLHky4sOHDiBMrXsyYpN/H kCNLnky5ctzGmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsFFbnk27tu3buHPr3s27t+/fcGML H068uPHjyJMrX868ufPn0KNLn069uvXr2FMD3869u/fvYrOL/x9PvnxM8OjTq1/P3bz79/Djy59P vz5y9vjz69/Pv7///wAGKOCABBYInn0IJqjgagY26OCD6C0o4YQUbgbhhRhmeFuFHHboYWAa3hVH iCSWaOKJKKbIVksq+vXhi9K12BeMNLIGFj8y5qjjjg7xg2NCP1oVZEM+FtnVkEAamZePRAZZJI5P ImnPkzxW2R2LUzqJlZRSbsUlkUs6+WOXZIJV45myZTVmkkyyCSSYSr6Zk5JQuulmnFOCaWeWY7ap ZZ187olnnYQ+9aVOdOZJpZWMcrdmnm/+CSeiVP75qKI9IqqnpHpiGumlkHo6J6aAajrqqYpe2mWj rN72KKeiliHaqZyxVqrlnHFGmWWnpfbao62mrtnnrZmi6iutrSaLV0AAIfkEABEAPQAsAAByAewB JgAHCP8A7QkcSLAgQX4CEdpTuLBhQocNGQ6UCBEhQ34YMS68aDDjRY8bJ4rkyHEiSI0FFap0mFFk yo4jXUI0SLOmzZs4c+rcybOnz59AgwodSrSo0Z0eNZKM+ZDizIpQO1qEGTXl1KZMZzoN6XKlxJIH qUaUufWo2bNo06pdy7bt2n9w48qdG/cr1KVYX4bNW3WsXpYy/Qq+qjWw3b1gt1LEG1Uh3ceQI0ue TLmy5cuYM2vezLmz58+gQ1O2CzIhyo0oTz9F/dCkytOqD7dkbfqj0oOpcy/+W3p17dcrf7sUTby4 8ePIkytfvtyt8+fQ15aNTr269evYs+PUrL27d6DTmYv/H0++vPnz5L+rX8++vfv38OPz5C6/vv37 +J+jp5tpv//8AOYHQEED0lTgUQfWlKB8CxoY4IPQaQbAhBMO1SCFDV5XoUAb2oOhhx8SSGFRGRK1 4IAX3lSiTStyiN+JBrVIlH801vjPTzLylKKL3XW4YYZA1gejgyz6JGOO6uWIJIRMRnfhjx5y6GOF Iw504JVTFljllVFq+WOWBKHYZZREhmkglChWSaSaUp64pZUgotnmmDzOKWacVm6ZpZte9glim1j2 qSWca7oYop8hhgklmWmC2SSEEn7I5aJ01kkoo3AmOGmmg156J4FjfgrqqGYa2imZMaKqYKmVfiqm qK6y/9phprQaeqmqm2LKpZm5qlrqoJtqemuuwNYqkI3Inocjqa5Kuquie6bpKaqx5jnirDwWi6el 3FLrbbemnjlrr7G++quvz8ZZrqTDyoppq4B+Kyqo5gbr7rT1eottdkY86tyQ8MY477u+SqmvscIK fG6l37KK77RljtuurRSHimvFdT5bLrMOE1vxxtkWTKu5tiZ8cckWZ7ykv48CXO3FOxIsLLkN12xy yBmXmbPG3N6cLs32mhwzz0BPvHPIRed8q9L2Qsw0oT+zHKCEAp+6rZoSQ/1loNbCuvWcDlOLtYJ6 npoojGzG2/XahzJK5dIGa1q2n2pbC3anjQb68s1PU/987dJj49zlhskWbrhcUr+3ck+L69Q4do8D HN/hlCebuHuPO45W5tZFHjZ8lYdO4+Wkl256WqKnHtrprLfu+uuwQ8e55suuNztOtxvFee5wQ+55 7PnRp2NOuwPFe5HIkwru5/fulKiKtNe+NvG95ynUyounS5Pq3Hfm1vGrSp/W79U7X36qjEdvJPPQ L2/wv+m7D7zUb2b79q5/47/voZTS7X/Zf7obAEcWL/7RzVTYuhbWEiguteXvbiIS1PS6Vb/B5Q19 iOJaygZot6vhikoLBN/8zEI1pFkKZB+zGcIOhrIU4o2FDHsfCl/GK6PRDG5JC2ANHXTDDuZQey/U Faf/MNYxfLlshd1LInMwxLMV+shvz5tU2wRFMni9kIkwfJgLrUcvG3KKTU/6WwrZFsEZruqHgMMZ sNhFxChqsXl5G5AS51gZ8TktYH/SVol6VSu0OdGE7hoaDOclsagdTWc9W+EhF0nDHVrxjky8k7be qMJFOm1gI4QQ/giGRzwa0pMPS9okUfhGUp6wkoNUXiqbyDA08vCPSjvlFWEZy4YNjGjny6SQ+men AvKyg9A64AfxtrUg+k9r92Kj27alSOvpD0gD1N8wCSlGt40rhNN72yn7aD+zCTBrEFTYM3VJTviI cHjlTKc6/SU80p0Td/tapzx9Qsd6Emee+MxnOe1pmR59+vOfr+On965nvB7xrX1Beacq1aJQxTXU LJgE6FHambmHimyhR6qe9tiHIOpZKEDkG5+44tnFiEZIoJv5qB3PoiT0JW+P6hPp90C6UgQFaX0W lSiOoqk1YkoQT44yYATBVjcAPg+oQP2pB/lUVDCCEIEalOSi0ja3qpURikp9U6NqdrUE/lKrLmWf AlH2v/2BSaoaJGdAAAAh+QQAEQA9ACwAAJcB7AEmAAcI/wDtCRxIsCBBAAgBCEy4cKBCewwhLkQ4 kSJEihYvPky4MWPFjw4javzIsSBDhSc7ZoyI0qTFkhUfktyoUSZLiSNxigQJ86DHmg1VxgxJEyVG hy6F+qTZMGdLkwZxGkwZVKLSnkSzPhW5M6rXr2DDih1LtuC/s2jTqkVrU+pTq0jfytVZtS5cqHaR 2p3btO/WvW4vfp3bVm/RwG1/wpV5MK7eqY2DMr1L2ajfx4ghA07MGDPRzkxbis7cFyrjl46jrl3N urXr17Bjy579j/NNlUcTpy5aUjdeyo8JB49897Dkk1F7p5ZKd3Fc5Z+tdibNHOjwwpVr8s1LfXhx 6JoHR/8+PNp3dfBue0+3R7u9+/fwaZvfbXr5X+DdL083v/00/eyghSdcaaEB+Bt//gHmnX7XLXeZ g/kFVtxvFCY3XlXl2UfcWxK6ZFZ8IIYo4mz8LTjaZk0NiF+EJWKX4IQGckfdds2dGGN3L9KI3Ywa lkhcgweaWB1mkyVInnMKMiikYQKN6OSTrpW1lFIEoubUTTVaqRNoWkYHkmA7glmjdU4lh1yKOxXI F5ZDGbWfllx6BNNpL3HV5UpmTrbUj2zu6ddPaiLJZpxC0UnlelImquiijDbqKKKORirppJRWaqmF ZEEalqaXdurpp6CGSpZ7n3Iq6qmopgqqqZ6VxaqqsIL/CuWstNZq66245qrrrrz26uuvwAYLW6zE Fmvsscgmq+yyzKJaK0fQRouQsNRWa+212Gar7bbDNuvtt+CGK+645IbL7bnopqvuuuy262u58MYr 77z01kuuu2q98w6+/Pbr778A7wqvvgS/Y+/BCCes8MIJF6wvwxBHLPHE8mpLcMAYZ6zxxhx37PHH IIcs8rUUl2zyySinXNbILLfs8sstqyzzzDTXbPPNOOes885Swuzzz0AHLfTQRBdtdNA8J6300kw3 7fTTUEN99NRUV231alFnrfXWXHft9ddghy220uaMTfHVaKetts9mt+3223CLG0LcdNdt9914N01q 3navXO33bHwHLnjX7ilguOH2HI644gMhLpDjjzcu+eGJE6RAVIw3DnnilCt+ueSTW6754plbTvnj n3N+OeSfl4466adzPnrqnqsue+Svp3777rGzrrruvIP++d/EvxYQACH5BAAgoD0ALAAAvAHsASYA Bwj/AP8JHEiw4EAFCBHaS6iQob2HCiEqeAiR4sSKCRdS1LhRYkSPGx0yvFjRIseSCzOO7Jjyo8uG JC86DKlyZkqLGT3CnOgS58ebEn3iNGkzKEqZDw0qXcq0qdOnUKNKnUq1qtWrWJey3NqRZEiTJV9+ PRp2bFewMVGaBYtxrNeTLN8aDZtWrlq2c9PilanXLlCgfevu1cvRL9fDiBMrXsy4sePHkCNLnkw5 sV3CSHnCxVwWL1vNXy/HDU367FbRJzO3Pc0aLdm9q0Gz1iy7rWrXqXNX3s27t+/fwIMLX/m6sMba x5N3vkv2LV+vckfWRt7Seeu+xlvG/Ql9eXfXt2cn/7cOerp33cLTq1/Pvn3lqqir4yavPDtz+XDz E4bd/Xl+tBEh1Rlyfu0nYFGblVUedwqepdp3Aqp1UVYUVmjhhRhmqOFVkMUX4YEO1hfhf/qZ9tlo RJW2GooYEQeida2lttKICRpn3nwlPhgacTW65+OPQAYJHHwxYrdWcfaRGJ1n6PHnVopcCYbjXPeh 1x9suAGGZZYfyjbifhRtKOaYZJZp5plOeagic5jtxFNO98FZ1JIAclcTnD6Zp9JQCM7p5IkgxSQo g2bJyaehgJaE5qKMNuqohkJGKumklFZq6aWYZqrpppx26umnoIYq6qiklmrqqaimquqqrLbq6quw xv8amWGy1mrrrbhqCh+e2uV13JyC9joTsHsSFSCv8n33V086VRfdoNBu9yaePCLbpoH40fTTsry+ tK2ij4Yr7rjkRsUZXVD+J1aSJCaanWEwHhXsclX6ep6J7Sob74cSNtkks5udO1a5BBdssKNXkkbj krTR2y6SIMaI5YsrMjllxfHm6xl9Oaq478XvIgnuwSSXbDKFCae48GgNyzhokS4KdaSzEZenrrX0 3riliRkrx/GKHw/4pH10nmz00QV3uKbPJZoW8ZF01hi1ukNTPLXT/Srbb5H4iqyntdTmPCCyD+dq dqVEphtb01Wz2fW/bjPZ34y2sdgV3WpnXODGLP7/zDTWOjW0o0hxJoX04YgfLXCXb8N4ddQQ2s12 fSKuLLGXIveIL5hbJ4l5oVlnKeJhiZduesF9Arzt49oNSza2d15WLMYy5unsWtNGezfnd5Gtn50B 4r5m7n/2bvjpyCfP4dnMN+/885eKAf301FdvPahVXa89psp37/3B24dP6ffkl/+o+OgLaf767JO5 OLTRaj2jSHLOG3i2edUPtv3Q8b/ur6sTmMxsVy1vPcdNUbobWNrHwAZW6H2bi6DFzvW/RPUPUPAC 0GCGopueGEiAVrocl9j2LKgdz4EoZJ/SXvMluQmvb+ChXHGMlLKutexKLVMZ7Yg2ORm6a3RB45nk 49JHRPZkr2FGypx0tKW6GFJncWLrU4haiMQp7pBfPaOO1/AzrAnabmQpDKMYDTKeDoJOgoVrltB4 FjbPaaw0NwrP2uLYOb7tzXhS+iIMOzPGPnZvVmWk2Q81pyYzUs07eKuYCeVIMThSLncAs2MC8ag2 dlmwXkXMZKUEiK0XptGQLmShx+qVREKNsHZJ9NcMRXieIJ6xbJqMJW+yF8IfEm5n7iLQHmlnEx4N 0H4kVB3xOlegAEayV1y8Ze+8tUA/OjOFsoxmb55JzQZK85qUqaY2jYbNbnrzm9zbpjjHSc5yYiUg ADs= ------=_NextPart_000_0006_01C6F130.7AF3A570-- From jcesario1@aol.com Mon Oct 16 04:03:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZNR6-0005h4-38 for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 04:03:00 -0400 Received: from [193.238.56.66] (helo=stiedprmail1.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZNKy-0003H6-2w for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 03:56:41 -0400 Reply-to: "john cesario" From: "john cesario" Date: Mon, 16 Oct 2006 10:41:28 +0200 Message-ID: <429641395324239280.641380443648284384@aol.com> To: "avt-archive@lists.ietf.org" Content-type: text/html; Charset=Windows-1251 Subject: st-0ck M0gul Ne vvsletter X-Spam-Score: 4.9 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 STOCK TRADER ALERT!
MONDAY OCTOBER 16, 2006
GLOBEX INC.
ETHANOL PLAY
Symbol: GLXI
Price: .29

WHILE PAST PERFORMANCE IS NEVER INDICATIVE OF FUTURE RESULTS, ON AUGUST 4TH
THIS STOCK WENT FROM $.70 TO $1.18. CAN IT RUN AGAIN???
GO READ THE NEWS!! ARE ALL SIGNS SHOWING GLXI IS READY TO POP?
COULD THIS ONE BE MORE PROFITABLE THAN BANK ROBBERY?
RADAR IT RIGHT NOW FOR MONDAY. DON"T TAKE YOUR EYES OFF IT....
__________
Information within this report contains forward looking statements within
the meaning of Section 27A of the Securities Act of 1933 and Section 21B of
the SEC Act of 1934. Statements that involve discussions with respect to
projections of future events are forward looking. Don"t rely on them. This
company doesn"t report. Past performance is never indicative of future results.
We received 150,000 free trading shares in the past. All those shares have
been sold. We have received an additional 230,000 free trading shares now.
The two tranches were from different third parties, not officers, directors or
affiliates. We intend to sell all 230,000 shares now, which could cause the stock
to go down. This company has: nominal cash and no revenues in its most recent quarter.
It is not an operating company. These factors raise substantial doubt about its ability
to continue as a going concern. A failure to finance could cause the company to go out
of business. This is a high risk security. This report shall not be construed as any kind
of investment advice or solicitation.








Preparations for the four undertakings we advocate, already exists. Our purpose however is to investigate the global meaning of nature, life and history as it manifests itself in ethical, political, artistic and religious aspirations, and to evaluate these aspirations with reference to the ontological and scientific adequacy of their presuppositions.
The medical sciences belong to praxiology. Contemporary Western medicine has selected as its quasi exclusive aspect the human body, and has applied the analytic scalpel of the anatomist to each aspect of the body fragmenting it into numerous parts. Marginal activities, like preventive medicine, behavioural medicine, and epidemiology do not belong completely to these trends. The fundamental sciences on which medicine is based, point towards fragmentation. The anatomist analyses the dead body and the biochemist eliminates the structure and investigates the chemical reactivity of its components. As a result of all these divisions, a multitude of dualisms appear: mind-body, individual-group, organ-organism. The acting physician, to the contrary, is confronted by a living total human being, as much by a network of serial relations and by a field of physical states as by a physical body. The fragmented sciences offer him only a partialised image of man and his world, preventing him from accepting the patient as a suffering totality. No obvious solutions exist for this predicament.
It is our conviction that the time has come to make a conscious effort towards the construction of global world views, in order to overcome this situation of fragmentation. There are many reasons why we believe in the benefit of such an enterprise, and in the following pages we shall attempt to make some of them clear.
He who wants to have a future-oriented global view of the history of humanity needs a world model and an action model that enable him to make reliable prognoses. For example, the explosion of the world population is clearly a problem that has ecological, political and ethical implications. How can we construct a meaningful opinion about this problem, if we do not know the capacity of the earth and the origin of this explosion? One who seeks a world explanation needs a world description. A global world model is impossible without a place for man, who knows, acts and evaluates. And as we remarked already, the acting subject becomes more and more the whole of humanity. Every evaluation for the sake of action implies a knowledge of the present situation. A global action model presupposes a world model, and it also needs a model of the instruments, materials and possibilities. For example, can a project to populate other planets as a possible solution for the population explosion be taken seriously or is it pure speculation? Constantly one needs a confrontation between new insights and traditional models of interpretation. For example, are we sure that chemical agriculture and even chemical medicine solve more problems than they will eventually create?
It is also possible to clarify factual world-view fragments as echoes of common sense or of insights that are valid in certain social configurations. The advance towards a maximal world view can then function as a corrective and a warning against making one of the fragments absolute (e.g. science, religion or politics). We do not thus mean to diminish the attempt to illuminate and evaluate as much as possible our own existence by considering the separate domains. It is a fact that in the past we have been able to find inspiration even in fragmented views, in order to lessen our fears by acquiring a feeling of direction, to increase solidarity by striving towards common goals, and to gain in this way some understanding about ourselves and the world. World-view construction should aim at fulfilling all these needs in our complex society.
We do not live in a neutral world. We admire, love or value certain aspects of the world, while we detest and hate others or find them irrelevant. We enjoy, and we suffer. Some aspects of reality are holy, others profane. A world view does not only make reality intelligible, but also provides a means of evaluating this reality, as it is expressed in different cultures. As we have noted above, it is difficult to arrive at a consensus about the meaning of explanation. It is even more so with regard to the process of evaluation. We believe, however, that everyone who wants to construct a reasonable view of reality and human existence will have to take into account the following questions:
The universe has been understood as a mechanism (materialistic mechanism) or as an organism (hylozoism, vitalism). Why not use acts of consciousness and groups as models of the whole? It is not necessary to reduce more complex systems to less complex ones, even though the inverse reduction of the simple to the complex suffers from our lack of knowledge about collectivities and persons. Still, G.W.F. Leibniz looked upon the whole of reality as a set of monads, more or less clearly conscious individual entities. A.N. Whitehead sees the universe as constituted by a set of occurrences, all having physical and mental features.
Sly, old Slys son of Burtonheath, by birth a
No matter how important facts may be, we are not satisfied with merely knowing them. We also want to understand, gain insight into and explain them. We always seek an answer to the question why? No consensus exists concerning what constitutes understanding and explanation. This comes, in part, from the fact that explanation has a different meaning in each sub-region. To construct a world view, we will have to experiment with different models of understanding and explanation. We will also have to give a new meaning to the why question as applied to the world as a whole, one that cannot be the same as in the different sub-regions. Explaining often means formulating meaningful connections. However, if the object is reality as a whole, the why question cannot retain the same meaning. Being in its totality, according to both mystics and philosophers, must find its roots in itself, or it is rootless. Concerning individual realities, the question indeed arises: why are they there, and why are they as they are? Why, überhaupt is there something rather than nothing?
We do not live in a neutral world. We admire, love or value certain aspects of the world, while we detest and hate others or find them irrelevant. We enjoy, and we suffer. Some aspects of reality are holy, others profane. A world view does not only make reality intelligible, but also provides a means of evaluating this reality, as it is expressed in different cultures. As we have noted above, it is difficult to arrive at a consensus about the meaning of explanation. It is even more so with regard to the process of evaluation. We believe, however, that everyone who wants to construct a reasonable view of reality and human existence will have to take into account the following questions:
My lord, I warrant you we will play our part,
Proposal XV: Consciousness and Group as Models of Reality.
In constructing modern world views, we must take into consideration the Post-modern critique of the myths of race, nation and class that have too often been used as a means of repression. Our own approach is Post-modern in that we recognise that reason itself has discovered its limitations, and has become conscious of its historicity. Perfect certainty and a de facto complete and universal all-encompassing knowledge is in principle impossible. Critical reason and emotional enthusiasm need not exclude each other, and both can provide an irreducible contribution to the construction of world views. Indeed, our reason is limited and our emotions can be misled. We must also confront the shortcomings of language. Thus, we have learned to appreciate variety and multiformity as values, and hence we do not want to strive for one unique world view. But neither do we want to resign ourselves to the present situation of fragmentation. From paramonyhaile@bethproudfoot.com Mon Oct 16 06:01:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPHy-0001Zv-Ec for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 06:01:42 -0400 Received: from 62-30-229-159.cable.ubr02.bath.blueyonder.co.uk ([62.30.229.159] helo=bethproudfoot.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZP7S-0006GE-Bo for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 05:50:51 -0400 Message-ID: <000001c6f108$84df31d0$b7b6a8c0@fjlkwq> Reply-To: "Lisbet Jacko" From: "Lisbet Jacko" To: avt-archive@lists.ietf.org Subject: Re: VmlAGRA Date: Mon, 16 Oct 2006 02:50:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6F0CD.D88059D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6F0CD.D88059D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VmlAGRA for LESS http://www.swiondetionshunde.com =20 Not for long, I hoped, if Fido-Aida had understood my suggestions. been too concerned. Thirty days is a lot of time. I thought. ------=_NextPart_000_0001_01C6F0CD.D88059D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VmlAGRA for LESS http://www.swiondetionshunde.co= m

 
Not for long, I hoped, if Fido-Aida had understood my = suggestions.
been too concerned. Thirty days is a lot of time. I = thought.
------=_NextPart_000_0001_01C6F0CD.D88059D0-- From katzmasio@cardinalcorp.com Mon Oct 16 13:18:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZW6J-0007je-Gm for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 13:18:07 -0400 Received: from [87.69.234.55] (helo=cardinalcorp.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZW6G-0003os-OX for avt-archive@lists.ietf.org; Mon, 16 Oct 2006 13:18:07 -0400 Message-ID: <000001c6f146$f9eb9b10$a8fea8c0@mevbngn> Reply-To: "Ethelred Vanpelt" From: "Ethelred Vanpelt" To: avt-archive@lists.ietf.org Subject: Re: VmlAGRA Date: Mon, 16 Oct 2006 10:17:36 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6F10C.4D8F0D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6F10C.4D8F0D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VmlAGRA for LESS http://www.huitiondekionlkldesunlion.com =20 Was nothing. was. And now I know who you are. ------=_NextPart_000_0001_01C6F10C.4D8F0D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VmlAGRA for LESS http://www.huitiondekio= nlkldesunlion.com

 
Was nothing.
was. And now I know who you are.
------=_NextPart_000_0001_01C6F10C.4D8F0D00-- From avt-bounces@ietf.org Mon Oct 16 14:24:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZX77-00014J-SW; Mon, 16 Oct 2006 14:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZX76-00014C-Fk for avt@ietf.org; Mon, 16 Oct 2006 14:23:00 -0400 Received: from [2001:630:d0:f102:230:48ff:fe77:96e] (helo=owl.ecs.soton.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZX71-0004yV-0e for avt@ietf.org; Mon, 16 Oct 2006 14:23:00 -0400 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k9GIMOkA011025; Mon, 16 Oct 2006 19:22:24 +0100 Received: from [152.78.64.103] (hwickabab.ecs.soton.ac.uk [152.78.64.103]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k9GIMDY7003772; Mon, 16 Oct 2006 19:22:14 +0100 In-Reply-To: <31d1be720610102248o7d2bea13ud51bdefa2f97de3@mail.gmail.com> References: <31d1be720610101111v7c4ebcaewd7681f712ccac075@mail.gmail.com> <7.0.1.0.2.20061010191025.03533718@broadcom.com> <31d1be720610102248o7d2bea13ud51bdefa2f97de3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Nicholas J Humfrey Subject: Re: [AVT] MPEG2-TS in RTP - RFC2250 vs ETSI TS 102 034 Date: Mon, 16 Oct 2006 19:21:58 +0100 To: Greg Herlein X-Mailer: Apple Mail (2.752.2) X-Null-Tag: 62cd2e839899804ca29532e3973f1d04 X-Null-Tag: 62cd2e839899804ca29532e3973f1d04 X-ECS-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: njh@ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Sandy \(Alexander\) MacInnis" , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I have had a similar problem with a tool I have written called dvbshout - which takes a DVB Transport Stream and output RTP packets (containing MPEG audio/payload type 14). I wanted the 90kHz clock of the RTP packets to stay in sync with the PTS clock of the PES stream (so that if there was an error in the DVB stream then the client could recover more easily). I calculated the RTP timestamp based on the bitrate of the audio and then re-synced whenever I got a PES header. However depending on the multiplex I was transceiving, I found the the two clocks kept drifting in and out of sync... I found it very hard to calculate the 'correct' timestamp for the RTP packets. What is the best practice? nick. On 11 Oct 2006, at 06:48, Greg Herlein wrote: > If the goal is to set the timestamp to be the 'sampling instance of > the first octet in the RTP data packet' then the calculation may be > difficult. The 7 TS packets in a given RTP packet may not even have > the clock data in them - and if the timestamp is supposed to stay the > same (while the sequence number increments) for packets containing > media, then the streaming code essentially has to decode the stream > enough to be able to get those calculations for each RTP packet. That > makes scaling the number of streams from one source more limited. > > Since the timestamps are not passed to the decoder, I'm wondering of > the only real reason for these timestamps is to calculate network > jitter - there would be no need to do syncronization if the audio and > video are both in the same transport stream (as is normal). If it's > just jitter, then why even use the same 90kHz clock? > > I might be missing something here - I sure hope some of the experts on > the list can chime in and share some wisdom. > > Greg Herlein > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 16 15:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYUF-0007u8-Qk; Mon, 16 Oct 2006 15:50:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYTL-0006Sk-Ul; Mon, 16 Oct 2006 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYTK-00056S-K8; Mon, 16 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9129226E56; Mon, 16 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZYTK-0005tB-EK; Mon, 16 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 16 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-compact-bundled-evrc-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Enhancements to RTP Payload Formats for EVRC Family Codecs Author(s) : Q. Xie, R. Kapoor Filename : draft-ietf-avt-compact-bundled-evrc-10.txt Pages : 22 Date : 2006-10-16 This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B encoded speech transported via RTP. VoIP applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-compact-bundled-evrc-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-compact-bundled-evrc-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-compact-bundled-evrc-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-16132153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-compact-bundled-evrc-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-compact-bundled-evrc-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-16132153.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From mdtsoykkcu@shawcable.net Tue Oct 17 12:09:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrVI-0005Bi-1t for avt-archive@lists.ietf.org; Tue, 17 Oct 2006 12:09:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrVH-0000ln-SE for avt-archive@lists.ietf.org; Tue, 17 Oct 2006 12:09:20 -0400 Received: from s01060080adc0b241.cg.shawcable.net ([70.73.15.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GZrVC-0005si-RC for avt-archive@lists.ietf.org; Tue, 17 Oct 2006 12:09:19 -0400 Message-ID: <000701c6f206$98d613d0$b60f4946@debbiehk82neib> From: "eye on." To: avt-archive@lists.ietf.org Subject: v. .raquo only Date: Tue, 17 Oct 2006 10:09:17 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6F1D4.4E3BA3D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.7 (+++) X-Scan-Signature: bb8d68e55b48f2ff3cebd1a6416d9536 ------=_NextPart_000_0003_01C6F1D4.4E3BA3D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6F1D4.4E3BA3D0" ------=_NextPart_001_0004_01C6F1D4.4E3BA3D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Complaint a settled trial Singapore hand ethnic punished countrys a = antimuslim remarks of weblogs general immune liability originates! Spend Sunbelt Chief or Scientist or Wells art is Needs Shift of = Octrelated Alerts or Alert Archives headlines glance Tech Flash Sample = Minute Gaining Octvideo Young Anymore Octreport Worms Voip of Fraud Grow = Octsearch. Against returned in mixed am verdicts doe Patrick Cahill Delaware am = Supreme Court am held stringent in unmask unusual dismissing unfounded. Focusing Williams meg Hourihan Pyra Labs purchased Google February = linking or permalinks blogrolls together search of engines enabled = bloggers or connected interests a broadly emerged Andrew Sullivans in = ron Taegan or Goddards Political in! Supportpc in Spacefree in freebies faq Submit Freebie in Awardsjoin = bring fresh listings in net course forget tobookmark us press d daily = Freefind Themes Forum Birth catchcom of. Countrys antimuslim remarks weblogs in general immune liability = originates Decency act eu Directive is ecin a Malaysia. Keyword campaigns targeting Whitepaper Todaya large appeal am Setting = untaxing in filling formas bloom fades of novelty chore Youve am log in = navigate menus fuss usually skirt annoyances offline editor. Cards cheap hold of vdefirst Coleco Smith Vectrex Engine nec neo geo = Wiilist Scans am Winnie handheld Gameplan Isbn linksrf database. Streets wake televised secondary blogging transcribe speeches shown = Rices testimony posting reactions Realtime presenta or test Kubrickin is = outreach opinion forming actively uks or Labour Partys Watson bond Lydon = Stoller President. Do am warranty as content wish them please contact via email they = promptly Fameish llc. Gt Building Geographic gis ems or Facility Fleet Resources Parks = Recreation of Cultural. ------=_NextPart_001_0004_01C6F1D4.4E3BA3D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Complaint a settled trial Singapore = hand ethnic=20 punished countrys a antimuslim remarks of weblogs general immune = liability=20 originates!
Spend Sunbelt Chief or Scientist or Wells art is Needs = Shift of=20 Octrelated Alerts or Alert Archives headlines glance Tech Flash Sample = Minute=20 Gaining Octvideo Young Anymore Octreport Worms Voip of Fraud Grow=20 Octsearch.
Against returned in mixed am verdicts doe Patrick Cahill = Delaware=20 am Supreme Court am held stringent in unmask unusual dismissing=20 unfounded.
Focusing Williams meg Hourihan Pyra Labs purchased Google = February=20 linking or permalinks blogrolls together search of engines enabled = bloggers or=20 connected interests a broadly emerged Andrew Sullivans in ron Taegan or = Goddards=20 Political in!
Supportpc in Spacefree in freebies faq Submit Freebie = in=20 Awardsjoin bring fresh listings in net course forget tobookmark us press = d daily=20 Freefind Themes Forum Birth catchcom of.
Countrys antimuslim remarks = weblogs=20 in general immune liability originates Decency act eu Directive is ecin = a=20 Malaysia.
Keyword campaigns targeting Whitepaper Todaya large appeal = am=20 Setting untaxing in filling formas bloom fades of novelty chore Youve am = log in=20 navigate menus fuss usually skirt annoyances offline editor.
3D""
Cards cheap hold of vdefirst Coleco = Smith Vectrex=20 Engine nec neo geo Wiilist Scans am Winnie handheld Gameplan Isbn = linksrf=20 database.
Streets wake televised secondary blogging transcribe = speeches shown=20 Rices testimony posting reactions Realtime presenta or test Kubrickin is = outreach opinion forming actively uks or Labour Partys Watson bond Lydon = Stoller=20 President.
Do am warranty as content wish them please contact via = email they=20 promptly Fameish llc.
Gt Building Geographic gis ems or Facility = Fleet=20 Resources Parks Recreation of Cultural.
------=_NextPart_001_0004_01C6F1D4.4E3BA3D0-- ------=_NextPart_000_0003_01C6F1D4.4E3BA3D0 Content-Type: image/gif; name="food.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6f206$98d613d0$b60f4946@debbiehk82neib> R0lGODlhaALkAYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAVACkALAAAAABoAuQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3MlT4r+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qlWlYq5q3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3aXvKnUu3rt27ePN+hMu3r9+/gAMLHky4sOHDiBMrXsy4sWPEeiNLnky5 suXLmDNr3sy5s2e5hhw+Hk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/Bn4MLH068uPHf yJMrX868ufPn0KNLn069uvXrbY1r3869u/eb2MOL/x9Pvrz58+jTk/3Ovr379/Djy59Pv779+/jz 698vEwOGheoFKOCAyPlnFH8IJqjgghv5dxCBEEYoIW0GTmjhhRiqVmGGHHbooWEbfijiiCSqhUGJ KKaoYlcMtujiizDGKOOMNMq4Iok73KijVDX26OOPQAYp5JBEsrTjkUgmqeSSTKZY5JNQRinllFRW aeWVWGb5ZJNcdunll2CG+ZuWZJZp5plopqkmQ2K26SZ2a8YpZ3u9qPTmnXg+N+eefAaZ55+ABiro oIQWauihsPWp6KKMNuroo3ohKumklHLFTKWYZqrppiRC6umnoIYq6qgVcWrqqaiuCEiq4pHq6quc sf8q66xWwWrrrbjmqmuRtPbq66/ABkvVrsQWa+x7Khyr7LLMNkuSsNAK6+y01HIU7bXYZqstptV2 6+1E24Yr7rjkevntuSbpE2q57Lbr7rvwxivvvPTWOxW6+OK7Tr789iuQvQA36e/ABBds8K0BJ6zw wgw37HC5B0ds7MMUfyjxxbpWrPHGHHfs8ccghyzyyCSjiPHJKKes8sost+xZyTBb5/LMNNds83cx 5zwpLTr3zNXNQAct9NCS+Wy0ckQnbeXRTPum9NNSNi311FQjCvXVvFat9dZch4n11352/VQfYgMH 9tk1lq322myLiPbbcMct99x069f23XjnHWDdN2P/w/ffX+stuNmAFx7f4IgnrvjijDfueKaGR/4e UVQ8bvnlmEMm+eacd+7556CHLvropJdu+umop6766qy37vrrsMcue+bh3kP77bjnLrDsvMOk++9Q 9S788MQHB/yOf3xZ/PLMNx/p8dBHLz2Pzldv7fTYB2X99hll7/333nMv/vhJR0P++QmCr/767Lfv /vtroy///PTXb3+p8Oev//789+9/vPe73/8GSMACGvCA/FMBufKBQJgF0H4NjKAEHfbA+k0QcRXM oAa3d8HBbfCDIBxeB9+kiemE8IQoTKEK+TbCFrqQXSus3gtnSENsxdB5NYzfDXfIw8LlUG09DKIQ /4dIRHT98IjtKgL/isjEJgoNiV1zohSnSMUq9gmKXLPi6rDIxS5aTYup86IYx/gnMJoxV6A4o0/I yDQ1uvGNzWKjHOdIxzra8Y54DBYcR5dHB+4xdH0s2R8HSchXBZJkhfTcIUeWyEY68pGQxMsiRRZJ w00yZJX04SU/lslOevJKm+TkJ+kWylKa8pRjHKUqVykkVLrylUhjJdxg+TBZzpKWDbPl23DJy17O Rpdo86Uwh6kaYJ6NmAAzJtiQaS9lBo6Z9HKmNKdJTTBCM5rVTNo156UlUWTTeNsE4DfHSc7PhFOc 5bzZOddJw2ckJ51AY6e74KlOecKQnjWzpz73yf9PROKTZv0U1z8BGtCCGvSgCE2oQms5UJeFaQYL jago6SaBhlr0ohjFiET1mNGUbRRYHQ2pSEcauY+aNKAkhaffUspSS56UVi092EthGtOa2hQiM53V TXfK055GLKeyQhMAhupT3ylpqAAA6liKytSmOvWpUI2qqJSaKqla9aJURdVVnZXVrgpzq3H0qljH SlaLgXVZZeXWWZWV1kqtla1tndRbjxXXuh5yrnjNq173ikK7+vWvgA2sYAdLWFbxNVep4gRQD4ur wgKKsQhzrGQnS9nHQPaymazsmzDL2c56ljuaddNnpxpaMY12XaVNrWpXy1qQnvZTre3Sa2dL29q+ 2va2KY0tl3DL29769rf40u3usKYD4Br3uMhNrnKPI9zmtm+5aXKukqArEKRaF6nUFdJ1rWsm6Xr3 e9nt7nd3FN4yjfe80SuvetdbW/S6972VZS+W4Osk+S6NviWyr36Lh9/87ve/vOuvgAdM4AIbeGEA TjDsDsyhcsYingyOsIQnTGHCKPjCrKuwhDDM4Q57+MMgDrGIR0ziEntUwxAy8YxQnGIVu/jFumSx jGdM4xoH74bSWJ6Nd8zjHtM4IAAh+QQAFQApACwAAAAAaALkAQcI/wD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDiqxor6TJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CD Ch1KtKjRo0iTKl3KtKnTp1CjSp1KVeXIq1izat3KtavXr2DDih07sqrZs2jTql3Ltq3bty7Jyp1L t67du3jz6t1rEa7fv4ADCx5MuLDhw4gTK17MuLFbvpAjS55MubLly5gza97MubPnz58dix5NurTp 06hTq17NurXr17Bjy55Nu7bt27hz695tFbTv38CDCx9+l7fx48iTkybOvLnz59CjS59Ovbr165GV a9/Ovfta7ODDi/8fT36i9/Po06tfz769+/dIy8ufT7++dPj48+vfz7+///8ABijggAQWaOCBCCao 4IIMNujggxCyZ9+EFFZo4YUYZqjhhvVF6OGHIKbE4YgklmgiRCGmqKKDJ7bo4oscrijjjDTWaOON vMGo4448kofjj0Cm1+OQRBZp5JFIJqnkkkw26eSTUEYp5XhBVmnllVhmqaVRU3bp5ZdghinmmBRt aeaZaKapJpBktunmm3DGKeecdNZp55145qmneWv26eefgAbK356EFmrooYgm6pCgjDZ6lqKQRvqb o5RWaumlmDYm6aacZpbpp6Dy1OmopJZq6qkXhqrqqqy26qpOqMb/KuustNZq66245qrrrjG+6qur vAYr7EG/FrvqsMgOa+yynybr7K7MRivttNSy+eyXW1z7VbXcduvttwhqK+5WvIAJ7rk38eLhuOyO VK656MYLk7ry1msjvfbmqyK+67brb6f6BizwwAQXbPDBCCes8MIMN+xwiv9GLOnDFOcnMXb1XDxp xRx37DHDGodc6Mckl2zyySinrPLKLLfsckwiJ5RtzDTXbPN1L+es885rFcPzz0AHLTRMNxdt9NFI J6300UM37fTT4S4t9ZNQVx3Y1FhnrfXWXHeNp9Vgw+X12DCGbfbZaJdmhE95VkO2rmnHLffcsb1t d4l056333o7d/+33hnwHLvjghBeu2t+IJ6744ow37vjjkEcu+eSU32f45TdVrvnmnHfuedeYhy76 6KSXrtTnqKeuepOmt+766yKuLrvdv8wuJuy456777oLb7vvvwAcv/PDEF2/88cgnTxDvoyvvfEjM i/78iwNMb/312JMdfejZd8/n9uCHX7X35D8kfuHlp6/++hKd7/778MdPMPv0DyT/3vXXf//+/Hec //8ALF//BkjAAhqQUQFU3wHPlsD0LRBtKnigBCdIrQb+CxPEoaAGN2gsC5KPg07zoAhHSMISmvCE TAPh0FDIwhZCToUrdKEMZ+g3GAqNhsazYdBwyMMe+vCHptKhEP+HqMN3vIOIt6nTO4AIvCUy0UJA MiISZZMnJz5xdla8onyuJMUpsqZQWdRieLR0RC+a8Yxo/JgY18jGZ6XxjXCMoxyn0sauKaMjczRZ HVGXx+P0oI+AxEkjerPHQhpSVoFMpCIXychGOvKR5zkk5/qDDUgmR5Kbs6QmN8lJCWJSc50MpSi/ +MlSmvKUqBTOKOeXyla68pWwjGUAV0nLWtqydbJU3C13ycur5RJxvQymMIcJtl8a85hIIia4kHk3 ZTqTlmlACzPt9sxuTfNt1eTWNXllA69k85vgBMo2xxZOaf2tEb8sZ7TG6TV1Moud8Iwnhdy5LHlq jZ5NMcWP7Jn/NXz6858o4SfWAEpQfwr0oAhNqEJF4osTzeChC0XaQyc60YgWpF4ULahGN2pJi3r0 o5rhqKpAStKSZkekKFWmSWOW0matNGQtRakkhPlSmMb0presqcZwylNa6vSnQA2q43pK1KIaNWpC ZddRBZXUdi01UE2NqlSnStWqYuWpgLKqVrd6Uax6FZBcPdQdwkrWsvblq2syK7TQqia1uvWtcI2r XOcqJbba9Y10zate9+qlu/rVjHwNrGAHS1gS/vWwRCwswBCbJcVyirGQVaFjJ0vZylp2eJHNrGY3 y1l9XTZRnQ2taEfblM+a9pOkrdFpV2vI1Lr2fKylCwdG9Nraztr2tjCLrW7FiNvewm63eSpJPXwL IeAaF4jETS7pjsvc5jr3ucJSbnGhC6eXVEO62I0bdaub3e4Gbrtv8q549Qbe8lpwvAkyr3oBiF6k rhd4+XivfA3V3gPNdyExuK9+LVtfA+33v9brb4EAHCUBE6hWF4irgQdEYCgt+MEQVmeDJ5zDCPuH wqyzcH8wzOEOe/jDG9PwfkBM4hKb+MR2EbGKV2xLFLtYMm54sQtZTGM9yrhsNc6x/2YYX+Lp+McU u7GQEwdkCQ25RUVeT0AAACH5BAAVACkALAAAAABoAuQBBwj/AO0JHEiwoMGDCBMqXMiwocOHECNK nEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGMe/Eezps2bOHPq3Mmzp8+fQIMKHUq0 qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rVuiMuPKnUu3rt27 ePPqXfi2r9+/gAMLHkw46t7DiBMrXsy4seOPhSNLnky5suXLmDNr3sw5q6nOoK8+Hk26tOnTqFOr Xs26tevXsGPLnk27tu3bqUPr3s27t+/fuIMLH068eMzfyJMrX868ufPn0KNLn069uvXr2Nca3869 u/fvDbOL/x9Pvrz58+jTq1/Pvr379/Djy59PXzn4+/jzj66jv7///wAGKOCABBZo4IEIJqjgggw2 6OCDpy0A4YQUVkichBZyVN+GHPq1QIcghiiiZh+OaOKJKP5VYoostugiWCu+OFSGNNZo44045qij jjL26OOPSQkD5JBEFmnkkUh2ZodvOzbp5JNQRinllFRWaeWVWOYoS5Zcdunll2DaluSYZJZp5plo rhfmmmy26eabcMYp55x01mnnnRmmqeee8OHp55+38SnooOcBauihiCaqKJeENuroo5BGKumklFZa 3qKYZpqYpZx26umnoLqo6aiklmrqqd2FquqqbKHq6qslsf9akziy1mrrrbjmquuuOQHgK6/ABouU r8QCIOyxyP5UbLLMNuvss9BGK+201FZr7bXYZssUrNx2q6G24IYr7rjklmtuZV9q4+267Lbr7rvw xpvbufSiKe+979arb5n49uvvvwAHLPDAXe5r8MEIJ6zwwgw37LCaBEes6MMUiyjxxYdWrPHGHHfs 8ccgYizyyCSXbPLJKKes8sost9wkyDCn5/LMVMZs86U05/zkzTxnp/PPO/YsdHVAF33j0EgnrTSw Rjed59JQI+f01FRXbfXVWDsY9dZcdx1p1mAP6PXYZJdNZtho/2f22my37fbbcMct99x012333Xi3 mPbe+eX/7fffgHPG9+CEF2744YiPFPjijDfu+OPJJS755JTjCfnlSVWu+eacf4n550V1LvropJdu +umop6766iyB7npQrMcu++zGvW777bjDRfvuvPfu++8E5i788MQXb/zxyCcfOPDMN+/889BHLz13 hRWg/PXYZ6/99tx37/334BM9/fgOhb88+egrZP767H+c/vvwhz3Bpnf30378+OePf/t56w+/0ALg nwAHSMACGvCACEygAhfIwBn5L30NZNsDJ0hB5kVwbRXMoAZld8EOevCDIMTZBp8Xwq6NEHolTKEK haKIFRZJDC6MoQxnSMMa2vBcJyThDXfIQ73lsHk9DKIQ/4dIxCIm7YdANOLGkGhBJTrxieRhIvCg SMUqUkeKv7Niw7DoOy0yTHQp4CJEvDifU5DxjGhMoxrXyMY2RlGMcIzj1NxILzna8Y54zOOi6MjH PvqxbnoMpCAHSchCGjJQfxTXIUeXyEY60iuLjKQkJ0nJSlryktN7pCY3WZW7YAKToAyl2DhpLVGa 8pSoTCViSMnKVmZOlXtzpSxnCRRYxpKWz7KlLnfJy15+C5fN8iXWgElMYgrzasVk1jERZAOtJRNZ y4ymNKdJTdIAoJoFA82ynvnG2RALm0X7Jjh/VqxxkvOa5kxnNLnJzna6853wjKc8P6hOms3znvjM 55DqOf8zBPpBnwDFCj9dFtBVDbRlBVXVQRfKUNMkNFQNjahEFXPGXSBsoiZ7KKgwWjKNfoqjJPOo p0BK0pK+RKQoTalKpWPSlqYPnS6NqUzZtNKa2vSmupmpwHAKKZ0GjKeP8qlQh0rUkwH1qAssKr6Q SijVgEGpUI2qVKcaR4AWw6BUbddvEMFUy2RVq13l01fHStaympWaYU2rWtfKlbO6NaJstddbURXX M82VrnXNa/buyld16lVuJ/hrJ/tKKsEa1niELexhF5u7xDr2sZCNrGQnS9mcMbZIlc3sKS9LJM16 FpSc3ednR0va0poWmaFNrWpxelo6rfa1sBVpa+cU29qy4m22uM2jbVmU28PUo7fAhexuh0vc4m6v ERcNLk2NazHlOveHzI0u2RTzgucKR7rYza52t5sV64KJu/TxrufAKx/xemlXmXinebNJ3vaCbL2M cq9aChEY+GZJvvjNr361a18s7fe/AA6wgAdM4AIbWL39tdKBF8xg8yX4wRDObVgY0eAK7ynCGHae hcWX4Z1teDodDnHvPgxiEZuYgySOzolXzOIWu3g1KVbxi2dMY58GBAAh+QQAFQApACwAAAAAaALk AQcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkygnCkjJsqXL lzBjyiT5r6bNmzhz6tzJs6fPn0CDCh1KtKjRo0DxIF3KtKnTp1CjSp1KtarVq1izat3KtavXr2DD ih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4ADC6Y7s7Dhw4gTK17MuLHjx5AjS55M ubLly5EHa97MubPnz6BDix5NurRps5hTq17NurXr1zRPy55Nu7btsrBz697Nu7fv38CDCx9OvLjx 48iTK1/OvOLt59CjS58OtLn169iza29Ivbv37+BDb/8fT768+eDh06tfz17u+ffw48uH3L6+/fv4 s87fz7+//9j5BSjggAQWaOCBCBL434IMNujggxBGKCGECVZo4YUYZqjhhhyGNeGHwQUB4ogklmji iSimqOKKLLbo4oswxijjjDQq1+GNOOY4V4089uijQzoGKeSQY/1o5JFGEqnkkkw26eSTUHqI5JRU whjllVhmqeWWXHbp5ZdgplflmGSWaeaZaDYX5ppstunmm3ASluacdC62AGNx5qkndHX26Sd5ewYq 6KCEFmrooYgmKuefjDZqo6KQRhqXo5RWaumlmM4p6aacdurpp6CGKmqFmZZq6qmopjriqKy26pSq sMb/epirtNY6lKy45qrrrrz26uuv2dkq7LA6AWvssRARqyyxyDYb4wqULdulHNJ25ey12Gar7bbc dgtrteCGK+64g3pr7rnoplsmuey26+678MYrb1OeeKbuvcp54slv8/brmb7i4StwcPoObHCdBR+s 8JkJF+fvw3wBLNvCFF+2b8UYZ6zxxqVC7DGYHIfc48ckcynyyTOWrDKWKLf84sowxyzzzDTXbPPN OD/n8s489+wzSDkHLfTQRBdt9NFIJ6300mL+7PSETEf93dNUUyj11VhnrfXWXCv5Q9c3Vy322GRj RgKdYKctWtlst+3223DHnZradNdt95dy56333nz3/+23c3cH/tffhBdu+OGIJ6744ow3/p7gkEcu +eSU1+r45ZJVrjlcmHfu2Oags+X56KSXbvrpqKfea+ist+76bWX7o/prr9du++2456777kzO7ntJ vAcv/PBn/W58SMQnr/zyzDfv/PPQr/VO9MdXb/31iUWv/fbcd+89gbp8Dyf25AMu/vnop6++2uW3 7/778Md/0vr012///fjnHxQA/OuPO//925T8GgRAAKDKf9QBgKIGyMAGOvCBEIyg+xBoOwn2KBYW zKAGN8ggCtaOgyAMYeM8SMISmvCEAhShClf4NxSCjoUwjGHcXEjDGtrwhluSoQ53KDYcSo6HQDwP Bv+DCDUfQo6IpTOiEpdIKySSjol3c6IUp0jFKlrxiljMYkegaDctevGLYAyjf7hIxjKa8YxoTKMa 6ybGwq1Ra22MoxznSMc6ivGNeMxjDu2YNz368Y9N4mMfAak0QRrykEcipCIX2SFEvo2RR3OkJCf5 MkgWjZJls+QlMcnJToJIk6AMZX48ScpSNkiUqEylKmkGgfWY0mmrtNkrZ0nLx8WSZrXMpS6xc8te +vI0u2yZvCjxy2Ia85jxggcyoxNMlC3zmdDMSzNPFs1qWvOaoZumNrfpG2x685vgZB83x0lO1oTz nOhMJ9LKiTF1kksxvWCnPOdpEHeOi574zCdi7Mn/z34SRZ8D82e1AErQgqYkQOgQ6NoMytCGOvSh EM2eQidK0X9E9KIYzahGNzqRinrUnxwNqUhH+quPmtSdJE0psCCg0uRQQ34nbWJLZ2qiT9D0pjjN 6U1j6iqd5mp9neCpUIdK1KIaFZc+TWowj/oppTo1l0yNqi+fqiqpcoqqWM2qVrcaP6t69atgDav4 uJopsZpVkWTF1FnX6kd11aOgbI3rG9NKVz7K9a54zWvA6srXOOr1r0vsq2AHS9jCjg2wcTKsYhfL 2MY69rGQvQ5ixxdZMk32sjSsrGYXO4vNfgSzbfKsaDMI2tKScLSohaBpV+u/ey0htbCNrWznyVq8 vM32trg1LPN+8b33/SK3M/qtapvH29pyqbjbK8wO3CbcBgbIDMZdohuiS92eAFdG1fXlBLLL3e56 95rXDe/svgsl8Zr3dORN7/LO2yL1BpK98I2vfOdL3/pi0b34za9+98vf/vr3vwAWln1LFOACG/jA CK7LgBfctwQ7OG0M/uSDLRThClt4mxPOsIY3zOEOv/fCTmMFiAni4QKN+MQoTvGFS8zioal4QS0W 0ItnLMwYj5LG/LHxjXE8n4AAACH5BAAVACkALAAAAABoAuQBBwj/AP8JHEiwoMGDCBMqXMiwocOH ECNKnEixosWLGDNq3MjRAsePIEOKHKnRnsmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMK BYpnqNGjPkkqXcq0qdOnUKNKnUq1qtWr/5Bq3cq1q9evYMOKHUu2rNmz9rCqXcu2rdu3cOPKnWsR rd27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmBXT3czZKrLOoEOLHk03s+nT qFOrXk26tevXsGPLnj11te3buHPr3s27t+/fwIMLH068uPHjyJMrX868ufPn0KNrpU29uvXr2LN3 ls69u/fvKrWL/x9Pvrz58+jTq1/Pvr17tX7ey59Pv779+/jz69/fFLz//wAGKOCABBa4GH8IJqjg ggw26OCDEO5n4IQUVmjhhRhmSGCEHHbo4YcQaSjiiCSGBeKJKKao4oostujieSXGKOOMNNZo441b vajjjjz26OOPQAaJEI5EFlmjkEgmqWRVRjbppIZLRinllCA9aeWVBVKp5ZZcOoTll2Ci1E50XZZp Zplhpqnmmmy26SZaZ8Yp55x01mnnnXjmqeeefPbp55+ABirooIQWOtKbiCaKm6GMNuroo5BSqeik lGYW6aWYZqrpppx26umZlYYqKmSflmrqqaimOteorLZ6mKqwxv8q66y0XuTqrSg5g2tetfbq66/A orrrsMQWO1QYxiar7LLMohbss9BGK+201FZr7bXYZqvttlg16+234IYr7nTclmvuuejWN+667KKU 7rtxtivvvPTWa++9+LoJ775dUrhDvgDbxe/AkgZs8MEIJ5whwQw37PDDEEf8qMIUvynxxS5WrPHG HHdcHMYghyzyyAJ5bLKTJKes8sost+zyyzAnSUvMNCN58s045wycFePW7HN7Ogcd489Epyf00Ugn rfTSTDft9NNQRy311FRXbfXVWGdtE0YoFO3112AvqfXYwYVt9tloo0n22uKuw3bVacf92tt01233 3XjnLffefPf/3WLegAcueJN+F2643wk8OPjijR3u+OOQ28f45IlFbvnlmJNH+eacd+5f5qCHLvro pJdu+umoi+356nyl7npErMfO6+u012777biXJPvuZ+Xue1a8Bz/W77kLb/zxyEtG/PLMp57889BH L/30pzVv/fXYZ6/99itT7/334Icv/l3cmz7++S2Vr/76X6Mf1DXXuC//SfDHvzn7D8G/9/xH2b84 /gAMoAAHSMAC8ol/8jOgAhcoEG+8C4EQjKAEJ6gSZrCOgRjMILcoGD4NevCD0+KgCEd4QRDKjYTU M6EKVzgrFE6PhTCMYalcSMMa4k2GOMyhDnfIwx4exIZADOLY/3xIxCLiSYhITKLUjBgzJTrxiUnj zCeipA0mWgWKsrOiFrdYMCyujoss82IJwZgyMZrxjGhMI+HIyMY2uvGNDFGjHOdIxzpmCY54zKMe tWjHPvrxj4AMpCAHubs9GvKQiEykIhfJyNIQ8pGQ3FgDIknJSvKmkZjMpHYsqTVNwouToAylKEdJ yix6Ml2lnNopUZnKqK3ylbAMTStnScvuxPKWuIRLLZ2Wy1768pfADOZ4dtk0YRrzmMhMpjKXycxm OpKYSnOmNKdZMmha85plo2YLsXk0bW6Tm+BMZSnC2UoTkDNc3pTVOXOWznYac53wjGdk3KkqeZqM nqmyp8fwyf9PXOrznwANqEAHKi84EBRAMWRAPxfK0IEd9KEQBUtDPRXRioISAACwqLwwytGMamai ++koRqmjUQBxtKQoTalKV8rSlroQpDCNqUx/5NKa1nSmmLKpTnfKU2Xh9KdADWqEekrUiAr1qEhN qlKXytSmOvWpUI1qE4tK1apa9apYzapWt8rVrgrIFiKSap+8StaymvWsaE2rWtfK1rbiSKwHdKtc AQnXPc0VUVtcR13xede+1nGvefJrmwB7RMEa9oyETaxiF8vYTR1WTY2V02MnS9nKWvaymM0sqSLL 2c56tiCaDa0IP9sv0RaJtFwy7WlRqyXVEom1rXXtjWDbxZm6NEG2uA0ebaeU2976drK7ldJvhyu9 4EaJuCUyruqQy9yg8GKIyo2u9dwgXSFRt7oKam5YsQsk7Xp3nUDAECq+S94ccfe8fCuvhdDL3vZa rx/rUW+F3Lsj+VKIvjqyr34Dh9/++tef+93Qfwf8sgALmMAIVpmBF8zgBjs4KAmOsITz+ODPTdhD Fc6whmt5YQxvGFH++zBhOtwhEZs4iiROMcNOzOKgqRhCLXbOi2f8yRgzh8YNsrGOOxYQACH5BAAV ACkALAAAAABoAuQBBwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmy pMmTKFOqXMmypcuXMGMe/Eezps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWr WLNq3cq1q9evYMOKHZtTptmzaNOqXcu2rdu3C8nKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMr Xsy4sePHkKvWiEy5MmW4mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXFy3Lnk27tu3bsHPr3s27 9+vbwIMLH068uPHjyJMrX868ufPn0PH6nk69uvXr2LNr3869O+bo4MOL/x/P17v589n/oF/Pvr37 z+rf7yZPv/7gP/bz69/Pvyj+/gAGKKB+/w24mHwIJuhZfArmZuCDEDJVYIQUVmihZRNeOFiDHHaY FoMehijiiCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOPQHKk4ZBEFmnkkUgmqeSS TDbp5JNQRinllFRWaWVVQWap5ZZcdukljVeGKeaYZJZp5plopqnmmmy26WZRX8Yp55x01mlnb2/m qSdyd/bp55+ABmpaAYIWauihiCaqqIx7Nuroo5BGqueilFY6mqSYZqrpppx26umnoIYq6qiklmrq Y5amquqqrLba4amwxv8q66y01mrrrWK5quuu14HA66+K4iosXqEMa+yxRgKr7LIfIevss9BG+xgJ uDFr7bUVSastp9h26+234IYr7rjklmtuudumC90nh53r7q/qxvvou/S6Ku+9k9arb6r49uvvvwA/ t+/ABBdscIwBJzzmwQwDqvDDEEMlQcQUb9XwxRhnrDF3FXfs8ccgh7XxyCSXbPJpIaes4ckst+zy y2epLDOFMNds8804bzTzzgbm7POJPAcN4M9Ejyj00UgnXWYx7RbtNIdKRy311FRXbfXVWJP59NYJ Zu3112CHLfbYZJftGNcE1YL22my37fbbbZkt99x0Nwn33dfVrbdgePf/Pd3egAcueH9+F2744Ygn zvbgjDfuuHOKR47y45RXbvnlmGeu+ZmSd+755zZuLvropOcF+umbla766qxzhfrrcLUu++y0MwX7 7bjn3l7tvPfu++/A76T78MQXb/zxyCev/PLMizZP89BHL/301Fdv/fUuB9879twnpP334IcvvuPd l29+Q9Gcrz7147e+fvntxy///PRH/f79+Oev//789+///wAMoAAHSMAu1W90BUygArd2wAY6EGvS g0b/HkjBCiZtgcazoOUwWDwNVo6DxEsMD3jgwWOZZoQgFFdjSFjCW6UGhSnsFmRG2MJZtYYHMcwd DHMIL8vQcGd5YJxu/3DIQ13VsHFFbFEhcnTEJjqxX0mMohSnSEUePfGKtWEGFgVURc9t8YtgFFYX OxfGuY1RcmVMoxrXyMY2utEpZ4zcG8EWR8XN8Wt1TNwd98jHNeXxj4AMpCD/1sd/sIJqg+xbIa2W SLwtsmqN/JLasPNIREbykpjMpCZjVslOevKToJTKJtcWylKa8pSo1MkoV8nKVrrylWhM5cxwZ4EY yvKWuMzlHWFJNF2GjJfADKYwh0nMYhrTN75MpjKNc8yX8cwayxxOCaJJzWpa85rYvEszt8lNZGYz YN082TfBGc6SjfOc6EznB8vJzna6s3vqjKc852m2d2qMnuqypz73yf/Pfvqza/gMqECp8s+CGvSg CE2oQhfKUPMMNHPGeKhE3dhQd030WRU910WdldGOejQuGzXhR1UY0pI2phMmTemFRkrSpaBApTCN Jktn+tGY2mpOmaCpTnfKU43Y9KdADWqnenotocaKqNYyKqyQytR+KvVUTY2qVKdqwKeWiqpY5aZV r5rVrnr1qy3aKqnAStaymvWsaE2rirSg1rYeTqxwraZb5wrIuIaKroWyq173yte++vWvgA2sYAfr KLwadoyEhdRhHZbYxjr2sUe6BmTts9g/TTZPlc2sZjeblsu+ibN18qxorwja0iZwtGwyrWoFiNrW uva1YFntl2DLOdnA2nZ/tDXTbXdbqQzwNoS51dpvgxRc4Q73uNgrrnLbh9zmWm+5YXJuj6B7Jela kbrY/Z11d5Td7vJuu+ANr3jH6x3vSom8NTKvetfL3vYGCL3whZ1750tfv8b3vvjNr341U98k7Tes /Q3w4P7LIgEb+MAITjBhCMxgRyrYQg2OsIQnTOGJJAwGD86whjdcugqTiMMQymwUPJw8EJv4xDIl sYpvhmIurvjFDoEBw1r8Xhg3iMY43pmNd2yyHPs4ZQEBACH5BAAaACkALAAAAABoAh0ABwj/AO0J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKrPivpMmTKFOqXMmypcuXMGPKnEmz ps2bOHPq3Mmzp8+fQIMKHUq0KM6RSJMqXcq0qdOnUKNKnUp1pNGrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27eH9W3cu3r9+/gAMLHky4sOHDiBMrXsyUFuPHkCNLHjxmsuXLmDNr 3sy5s+fPoEOLHk26tOnThvOqXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX24U tfPn0KNLB8y8uvXr2GlP3869u/fv4MOL0x9PvrzA7OjTq5cbZr379/Djy9e5cL5W8/jz6ydov7// /wAGKOCABFq3kAAI/pPgSQIoiFKDCEa4oIQQUhihSRdiKOGDGz7oIYMglmRhhgpm2OCHKZHoIIcj QljSfjDGGOOKC2K4oo0noihiiBr2eOONOe7Io4NB5uiijiWCGKSQDBp54pI/LnmijFRWGd1LT0bJ ZJYptiTlh0Xa6JKRQCrZ5ZBiovkjjWcy6WaBcMZpVn1Zhlnmmm/qCCWRPO6J4pFaQmlnm2nmyaee H1qp6KKjBQQAIfkEABoAKQAsAAAcAGgCHQAHCP8A7QkcSNDePwH/DipMuBBhQocOGT6USHHhxIoI I1rUWPGiwogaM2KUyJFhSY4lP440SdFhwZcwY8qcSbOmzZs4c+rcybOnz59AgwodSrSoUZ8dW14E 6RGigKdQHz7tGJKqxatRkzJlyvIkSa1Qwyod6ZXl16Ro06pdy7at27dw48qdS7eu3bt48+rdy7dv XYhmt5pFO/Wsx69hUx5MCXjpYJSGx0a+2nXlYcp+M2vezLmz58+gQ4seDbdxw8qXtUZmvDEta8Em xa5WLTm1ytqQSevezbu379/Ag9+leRr1bcxWB182jdy2yIlVl9dWnjp3Wdv/jmrfzr279+/gw4v/ H0++51rmi2dbPowSJPr3VNtTjx4b8Xqp9dlPVyy8v///AAYo4IDxPZcfe4k5lRV1UtEXmGzJKZeb c1ld11JhJC04H16UUELghyCGKOKIJJZoomcenqjiiiy2WCJxLsaIlk+UlGfjjTjmqOOOPPaIlIxA UsRThz4WaeSRSCappI5BNunkk1BGKeWUVFZp5ZVYZvkbjJnJpKWIS4Yp5phklnnkZl5+CaKZbLbp 5ptw7pTPnHTWaaedEs1JkZ4yfUCRnxL5+cGg/wAaaFqDJsqQoRUpuuifkB4qaUKOUtpooYkyGqim hCpK6KGZfvpodnGWauqpqCaZD1qrMtRqQq/q/5nnqn2CKimgmhaK6K0difopo4JOOqqulBr666XA 9soprsVCuuyoqUYr7bTUbvdqRddm6+o/sXJLKkzE6mrsqLnmKiyzl0467rjphsuppc4K++i68AY7 b7uAVqvvvvz2C9O1e+YpMKzeEkxrTO4mXG+7vfIaaaT0wovssLbGS/G9lqJrb8YNE+vvxyCHLKZa dw5M8LYnr9oqwPgqTGy5iGZ6cbgOizszxxJXrDPN5L68cMLmoqvm0EQXPdxMLKMMa50Dq0ywl0JH nfPUD/tcdc8Km5tz0DyLK3PH9mrcM9cei2z22WjXlMdRJLNqsrYnF7xrxD/Le/XGN9ONN8Ncw7zM bss/s7t33UYXbvjhHdGUdNxyy93t0wjbjDPhVMs7OM/J0t3xxUJjXPnfYt8Ls5Bpl2766US1nRTc KCe9+KZ/Jtu11lt/biywz6KVO6YUdz472FN3GvvNiBdvvJaKu630tq5/+xLnmwoaKqZfL1p9qLiT TXzeolrvK8Nde713p9NLivr56Kdf0/Hst+/++09y6Vea8Oum/v345w+uZvTXP1q0etCfAAf4E/8R iIAITKAADcjABjrwgaIJCAAh+QQAGgApACwAADgAaAIdAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJEyS/nwSBBg36 s6hRg/z+GS0qcGlTp0iHSkUqtODRpUefJh0IVSlWr0wXbtUadmzPs2jTql2LtqrQqk0RmjUbl27c oXThJp3L9aDbsXqnPuW6la9Sv4KtwrV6l63jx5AjS4Zor7Lly/YOS92buK9nvIijMu5rWPPoz3YT 522sOXVpubDvYp5Nu7bt27hz697Nu7fv38CDCx9OvLjx48iTKwfu+vBrwXY5iz49VTrp0IxTQ0ds uPnn2NO3Lv8fT768+fPo06tfz7797+aFv2/P/hVsZ9PW62IHrfB53axgXXXfgIAJ5N6BCCao4IIM NujgcvB5pp1/+fkVn2gFEsidWPfld6FiYfW3n3gPlmjiiSimqOKKtEV414SdVQibd12x1qFp4OF4 HX+naXejZywGKeSQRBZp5G06fuhcjtHpOGN48vm4mo3UJWmjjDj6SKV2R3bp5ZdghjkcQ39dCeN8 3u1I2JUDerXmYN/lBZiSSkYpYpVaTqbnnnz2mVaISZ5J1F9QFVrjlFSCaOFirukFIFYyNhpik35W aumlmGaq6aacdurpp6CGKuqopJZq6qmopqrqqqyChNtAYsZrKuustNZqa62t5qrrrryG+qqBtwYr 7LDEFmuserAeq+yyzDbrrLDJPivttNRWay2C0V6r7bbcdqttr+CGK+645JZr7rnopqvuuuy26+6v /3gr77z01ouru/jmq+++/Pbr778AByzwwASLFBAAIfkEABoAKQAsAABUAGgCHQAHCP8A/wkcSLCg wYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4 c+rcOTGdTntAgwq1F3NoUIZGgfJcyhBcQ6dML0L9l7Sq1atYs2rdyrWr169gw4odS7bsWIEA0gJY WRVpUnBw4Q6MO5euwLhy/+HVu7duXr52+wKeS9Cp4Lt08UI9/Ldx4ql/7xZuTHiiXcCOI2M2vFew 44J9IUumara06dOoU6tezbr10H9rXbZdWHVqZb2jceu+Xdig6N25by/u/Ru4cduT6wbnq7x37uHL HRYHjtw5aOGIm2OHrtu19+/gw4v/H+86dkG1aNPCjq3WPPr16mEPZC9wtsLa14lXRl7d+G7uy/FH 3X/RCXiQYbgheB2Ctk2XoFye5aVggNj5Fh2BozF4HGETSkbehyCGKOKIrZk334n0yefeefKh1WKL sdmXUG2dLbjfZZf591uEACaoX4a+4aiZhh1KpmGFHG7HoYFI9reYZxUSmd+DFpJo5ZVYZineQia6 6GKKa60IX5gnqigSk0bimJCDmPFm449pUjalhfsZiZiCADo4oWiK6Tglm9ZZB6Vu/AVWXX9RJaro ohph1eWLZMII6aRiRkqQjAjhF6iPGB7oJqGfJgknp2wiOiCoDYJ66obFFXnon6GG/7pjnRuOipuW uOaq666lveilmZKuKGyZvsaYlFtGvQrksp4WSGuzs4ra6YXBGcjnnKkye62ddK7qp3+d9gidtb3x au656GbZUHvpgfnle2NO+quvGjkpZ5wQ5qgsvpxFpm9ggj4mMJr/JTYndf7ueSe1OR4HMLjTucrs c9QyavHFGN93VUWPMtQxaUYh+1rGPJlKckVQpavyyix7B9LHCsF88sxP0ZyRyTbnrDNNWG2E6c4Z tSz00EQXbfSVQCet9NJMN+30SD03eixKMlNUNccDHa311ipPwfXXpnEJL7FMmTj2fPHNS/ZB8LYt 5tpPxy333HRj9Daj7N4tb9oEde9pNoqAS9p33YQXbrjcjgIe6Xtt1zd1SZbq/fajlCMUebBsgwz2 5px37vnWwtL3t5fGhmzS5WpPblDl56UIo+uDfy777LTXPp7Y8Q2L9tkwMQ43u2pD2h7fwNLL3uiH J6/88kn7HXjwNJGp9+DBs766vIFPz/z23HcvU+LUF7+346afJH2Zzv9+PbGok/7rWrbHL//89JuW /uvHi/lzSMDDx77ZxDNe69xDPAKWqX4ITKACbfe0q0XEgVjzngQnSMEKTgSCEMHgAy3IwQ560CJR I8n+HDLCiSzwhChMoQrLYpISikwoPluhDGdIw/oFBAAh+QQAGgApACwAAHAAaAIdAAcI/wDtCRxI 0N6/gwgTKlzIsOHBggMdSnwI0eDEiwgratzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjyqyIkSGA iTcTaqzJcCfPiTODCh1KtKjRo0iTKl2K9CKApzkxRm049adVhQGyZv2ndWtXhFsPhr1KtqzZs2jT ql3Ltq3bt3Djyp1LV23HqjXxKqzqk6zGAAwBiwUrVjBXwEwTK17MuLHjx5Aj96W6F+FNqP+eHoQa FXPmzXUJLzRMejDg06FTq17NurXr17Bjy27dMbPmz6Bz6sb9uTPunJOt/v06uDhX08cRS17OvLnz 59CjB+W5e/dv3pct81ZtOCFpraIFd/+fTb68+fPo06tfL7s66Ou+47ceb1x8eOPs8+vfz7+/f4T5 /IdRbdq9d11v2smHW3A//RWYaMdFSJh0FFZo4YUYZtiURJwl5Bt8ntlmnV5x0Sdhd6h5J+CKLLbo 4oswtkVgZW4xyJONZWmo44489ugjhleRGOOQRBZp5JFIJqnkkkw26eSTUObIUYs4SvTjlVhmqeWW jlFJ03ZAcSnmmGSWaSZInFXVoVVpoqWXT2p6eNuZdNa5GCp25pmSkB+yqdabNK15G3b/6GnooYgm OhRODk2l2219FrgZpL95ZimljYLZp5BRdurpp6Dmd1eIkmpKKI2VYYpgbh5SBFF2rRqgeJOitNZq 660zOiXido9SqpejmG0qomacLkSqsKEmq+yyzK4XZ4IFwoqqgoQ+S92p2Dar7bbcdlvTXaWeiqyx kkpLrbQLfmluuYXi6u678OK6617HhkgisMTKCemgmGq05rzzxivwwARfSVexPyEslbcMN+zww6wp jNOgbkJs8cUYZ6zxxhx37PHHIIcs8sizFWzyySin3CXJLLfs8sgBAQAh+QQAGgApACwAAIwAaAId AAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXL lzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtGhMe0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DD ih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du02N6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS55M ubLly5gza97MubPnz6BDG8RLurTp06hTq17Nui2k1rBjy55Nu7bt27iRit7Nu7fvmbmDCx9OvLjx 42J/K1/OvLlG5NCjS59Ovbr169iza9/O/a7z7+DDi9j/1728+fPo03sfz769e87q48ufT7++1/eA 7evfTx2///8ABijggAQWGFFU/CSY4D8KLtjgQAsKFKGE/EBYIYUQZtjghQ8S9OCGDHrI4IUhTlih giNmSOGEFrYoYYovrqjiiyZa6OCHJN6IYo0gEsTfj3ixAGRXC5EoYowhwqikkibmGKORSRoEJZJG nuhkjUliOaWHOV7pZJQciqhlQVA2GSWGVBqoZoBbfplliWeeCOebc55p54xHxjmnnGG+GeaWKv5J o59k6ilnnXjCyWehfeq55qO9BQQAIfkEABoAKQAsAACoAGgCHQAHCP8A/wkcSPAfv4ICDyYcqPCg Q4MEHz6ESHEiRYYIFyJUeBHiRIkaG1bsuDHkyI8kLXo8WTLiSpUrL3IkmbGmzZs4c+rcybOnz59A gwodSrSo0aNIkwrlx5QpRo0sVYIUWXFmU45NNzp92hHkS5MxYRakirLs2K5haV5dODVrWqg0lcqd S7eu3bt48+rdO3cm17VgrQYOKbim379c05od+dXg1qdkFadEK1Ks38iX2Sbmy7mz58+gQ4seXdCe 6dOo7R2WCTUyZLZXvcaF67K1y8osGcvuGjuq5syCcR/OnPs11oypkytfzry58+fQo0ufTr269evY s2vfzr279+/QVx//B5sY+G3yLdOP15zQ4laqjm2Xl+kePvyY8SfXxkg8P9p/4AUo4IAEFmjggQgm qKCB4s3X32TB8bcWYAy5BRdgWNXnmIbtPUZZhfRVaJVbGYro0IRn9VbihQIt6OKLMMYo44w01ggd aTjmqGNpNvbo449ABilkjDsWaSRoQyapJIwAALDkk1DeeOSUVHoW5ZVYStdkllwCWeWXYIYp5phf AkDmmUY6h+aabOLU5ZtcbgnnnEpm1OSdQ5lZ0J16itbkQH/i2Oeeg45G56FJOonooi7+VKhQj/b5 aGeB/lPpaJNammmbnHaq1KWehrqXmghFGqiZeuIpEJ6qrgoooJWq/yrrq6iuemqsl9Zaq6aptuqr rLeiKmmwvRaaqq3Ewnqsq3wqi6yzAzEqrYxyTmutgY42K6mmrjJLUKSvWkrrt+Myu2y34k6qq7jk bttuuel2u2u83pYqL7zz5ssuvejOK+q/mAIssKC57omvtu5++yurCeubMK9/gsrustqGW7G5rN7L p8N23lsvvxx/DLGwA5fMl8Qmp/yZsfja6a/H+yq8b8gxqzsoxTPnvO3OBk8cs86lbgz0xzT7a7PK SH+a9NJHkdpzuCBDzS/U5948dNRUkyt11DwTPfSxXU+NLtcth2201INeq/babL/paNDn8vqsrVrL Gyy0ENd8t9x122kdscXA7o0z3+4WXDbgw/7t99ytMu3445BHnvKmkldu+eWYZ45X45p37vnnoIcu +uikl2766ainrvrqQrXt+uuwxy777NGxbvvtuOeu++689+7778AHL/zwxBdv/PHC06788sw37zyU AQEAIfkEABoAKQAsAADEAGgCHQAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGj x48gQ4ocSbKkyZMoU6pcybKly5cwYx78R7OmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQ o0qdSrWq1atYs2rdyrWr169gw4odm1Om2bNo06pdy7at27cLycqdS7eu3bt48+rd2xOu37+AAwse TLjwR76IEytezLix48dRDUueTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbo1R8iwY8ueTbu2 baeuc+vezbu379/AgwsfTry48eOkQyBfzry58+fQo0ufbvq29evYs2vfzr279+/g8y71CY89Lnmp 1NOr5/0TgFP37h3HP0+/vv37T83P/wegv03//83nH3z8FRjUfjgBaCBR/SGYoFHrRSihb/w1uGB8 DlZYk4IEvidgUR/ulOFPE5Zo4mod3pSiigUS6KKBFlaoIE3wxbghjDQCiCGN/7HYYYMY6gijkP+c aOSRoq3Io4wIvuhkizeGyKOUUFZZ5Y439kiklTUumSWSYIaZmYw9erkflk+mqKaWWS7pIpBQrtjk hVHCKWCGYuapZ2FTeklnljumGWWbXJb5Ipty+timkk0iuOejkMbUnpVmljnok336ueaim1JZ6Z+F OoglfqSWaqp3AQEAIfkEABoAKQAsAADgAGgCHQAHCP8A/wkcSHAggH8HDxJUiHBhwYQNITKEKJBh RIMOK1JsyLEjxoogQ14EaTFkyYIoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59Ac9obSrSoPQBI FSZFqrGk04sUk4q0uJGqQaVMp6aUKhIh169XJwo0Sras2bNo06pdy7at27dw48qdS7eu3bt48+rd y7cv2a5BAwu+6bew4cOIEytezLix48eOAQ+eTLkl5MuYM2vezLmz589lK4seTbq06dOoZ4Jezbr1 59SwY8ueTbt2Qde4c+vGa7u3R98vTwIfTry48ePId6ZdutFr1qsfPS5t+vw5dekqmf/OrhF69+ta tWv/jy5W6nTqSluej8lV8sPq8KkKXzne5sn1p3fr388frfqHGUknVlflbWVVgNsBNh+AXnnXoFYc pYfSfeSZ9BGF9Nl34YIdVdWhe//thGGCyZVo4onGPVWhhSQxOFJGEiI4n4osFRgVixF+OOGOEMYY I4IuhgXeVtH9V2CLNN2XVVTxORfgRE06+SGTWEHJIYpYZunbcmCtmCOSYVU54I/ozTjdlVOOJOGY 8lknnEQ6sulmjUtiNGCQaH75YkLtBXemnT5i52KgB+75YKHN9afoovqFWCR+P47YHIsjkkijk+Zd SOmQc/IIIJwmtfcmptZF9Kdkl3IXnp2PMtUnjVWd/3lnmGHyWeGRApqXp5a89grcpT7WJ+lvzE0q qKcgPmlhsXp6iCyrzgb6LHewBpksgayCuSux2SboKo+zQoers+6V6uu56NoGrKZe3oqngjBai2a4 zUWLI5DtSjuqSx7Oui+8yo7L3qA6YjdswYYKnG+6DDdcGZe6ftstwuCJ92Sm7BbpHIdk1mswoKKq 2qHEJJ3HsahL9rlxlRqPh7KVMikZacpQytjUzThvnCvOXDHq88/8ZbltjecOPe3ADssG9NJMX+aw 0UTzCrW1SCdt9dVYZ6311lx37fXXYIct9thkl212bGmdnefUZx9NG9Rss71S03TX3ZZ6Nb+dncoa Cv8JYZLxBf5exK6i7GDFGk8YbszDFRo1TItTbWzblKeY92z/8nSntDP5i2/iBWN1eJokLhQ55I1/ 7rbIV85Y+evIwcmyzjmbTPODUtruuN8S8d2uqXxG6bGy5RbfI1QET77jmnV+GbLpYnLaPPAwS0k7 z4Ln3mrw1b+au7mwh4+a7J+2TLqa2p6feHmcE+zQ5lOmCj+4681PfsC73nhkepW+322//zsWuUJH sQHOb2LpE58CZbOm68ipX6fi36letL4AgoheBLSYvH5HtZFV5160A5/3oPIn2ckPYwkLIK5WhjD4 PRBMf4sehS63wBqWpoECyyGD+Je8aSnMUuZzoeSu3Fc6b2WsgUBS3g4piLzLIep8AEzf7jy3qgRO SogwzCL4bMhFmyynfFJUYbZ4GMZn/bBjxMMiE/92rIwRT0+bipejSNa+FoqxjCl0F7aqaChU6XGN xjqI3QZJyL88LlR0rNhXmsc8fclsdlZaXJtMF6fpDU5eXfqXVVSExmuNrHYbkiQKoyU4OdVOZbdT 5AcVV8mUwSh4XYylTtL2E7kBZW2y1JzWbFmTQvqSkAEBACH5BAAaACkALAAA/ABoAh0ABwj/AO0J HEjQ3r+DCBMqXMjwIICGECNKnPjv4USLFDNq3Mixo8ePCTGCHElSo8iSFAuqXMmypcuXMGPKnEmz ps2bOHPqfInSIYCTPUECbTg0qNGjSE0mXTqyKNOdUKNKnVpTHtWrWKEy3cq1q9evYMOKHcswq9mz aNOqPUu2rdu3cOPKnRtxrd27ePNS9ejUYcWwfRUGFky3sGGhh0OiHJy4sePHPQM/ZByU8l+IJyc3 /bnYsmLBGDnPLfpTdEnPpzmiJgq5tevXCHkylHz5q2XPqwn7JWl6I1DTveEOzS2RuO3FI/UqX868 uUyL0CuWRjj9r+bd1EVHt15deujuPq9z/wfOGfp089HFi8zsfftl8O+zow9Pn7r199q766/Ov/x3 9PPZR1iAobUHGnn/KRagd/WpV5+B8rmn2XylJdigaM5lqOGGeG3nYIETCojddenZB6KItdX2oYIm DijhZy36deJsu60Ho3gt4ngfdjLGuGOJPQYJY3YjqmikiOwN96KNPc64Y4pOTubekT4ayeGVWGYJ VYgrNilkkVwaWaGDRIJpYpT4lcfikE9+OFyN30WoY3xpklmhmHd62F6Xn52HpJgoFmhgcCrmGZKh PyIKpY9kFjnof5xpKemkWhZ3H58hPmlmmF9SSSSaPrUpqo3srSlqqHLGGWqpfQqJKaCtav8K65CN vvqnoNLdqBuP8U3pKZq4zhqncbAVa6xGPAkKrKeOKssos67+OuqsvDb7bKC0mjpnks8uGySQ0y4E ariLRoutmbf+aS66p7JLqn2UxitvcxcJqKx20DJoLZyQHtrvnfoCWGeKBMsX4cHwkZqfhbmiOPC9 CxNYY4P2/uanweFJGRzEGu+qb8D48rhfbwAP6u+ReSJ47MoslyQbby37plTMrDVG7Ghkzavzzmt1 dfNrt9F84GM/x1W00EgnrfTSTDft9NNQR12XS1JXbfXVZfGs9dZcs5QRcYRWrSbWfDV1nNkeda32 2jx/XTbMW1HGZMn5RnR0ZXzBp+5Hd1v/yma9abMt+ODKIdfRz32j3eneZAfL+OFnI0b25JRPlCy+ Agec5skkLtywwXp+TJ/KDfNX7uKjP2j6hCNn5jmDEWMM8IJ6N+s53RRnvvqDF1KoO4Qf4767voQX b3xafnPnbuk0ojrjlM62S2epbnq84PIggtvo6SSuGy2fRJm+LpPKC8u8uLrqeaK3Bcv4YuXwN37t eGN/vvfzIucofeizU5t/tt/r1vy4Nz2UXexSKbObAB21PPcdkFDk6960svfAA6kHd/HLYMteMi4d uU5X6IKe/ranPnv573T/I9erghXBArIvU6CpmQrP1S4PxpCGElyRkxhovoQc74dAXEsHkU/YwhCm EGXn0l4ArcfEJc6Qhemb2Av3x6spprBWRATgjwJoxQb+JYhgDONexJcxivHuVyHzVcgKRT1+eWiN /sqcukbWQOG9Tn2tg1V/HFey/TCLjBAio972ODH6mSuPcYQShsTIyEbaRIOJ48rNIqlBrjjykpik WvwomZTaqaaSxcqkKMEIylKa8pSoTKVHAgIAIfkEABoAKQAsAAAYAWgCHQAHCP8A/wkcSLCgwYMI EypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4qsaK+kyZP2RqpcybKly5cwP6KcSbOmzZs4c+rc ybOnz59AgwodSjQkAIVHNx5NSpEpwaUvnSqN+lFqSwBWB2aNybWr169gL+KUyHSrQKdY0Zp9+g/q WqQHoZKt+LbpSKlq02rFupcv27Me677F27BuQaKIEytezLix48dFOZZNmFZuW8AQLU/Mqnml4bku 0RqcfBmz6c+ZGQ4Oy7q169ewCyadfdavW76VZZfWvVWv7cty9bYV/lS48dLHZ/sFnFu27d/Dyy6v rXx5877MqTu3Dv36btPZwfv/Jk6cunTaS6dH1148/e/m8KOfRx27vv37HnHSBq51+On+/VlVHWHI 8edWgAD+N1ln6YGHoHgIHRgeZbtZ1pt/Ff71nYEJysegfLop2OGCAe6nYWffkUhidituCNmLMMYo 44w0QnaghRn+196JI2J2I38TihYkkLlJN1qOtbV323hx+fbghkX2NR1pUZLmIGFWIunelE/iGCKQ xSUoIZhjejlQjWimqeaabPq00I8tWilggWL+hR6HcfKoYoZ4iZZlknuOJiSZSPLZoZ4IZklglzxO +CWOfxrapKF5QnoofphmqqlKVDKqI1sfQlggnJ6KyKKkGhJ6ZKApIjpknXK6/8qhqI0qCmuPQ0ba 4qqJMmqpj5sGK+ywFskJHaAjGgefevuRul6hID4bnJPslfosiNVVK2WO3mG7o5LbDpgqduYJyi2z 5B2LIbkCHrukuKrGR+y89Nbrmb34gqYpfSAt6hC/+QYs8MAAD0xswV0hLNmXb6pn8MMQhzRWxBRX bPFLbWas8cYc63TxxyCHrFHHJJdssppHivyxwhk5rNpVIrGcGkEn12zzzTw1TO2/5R38Zr3+XrTa Q5EatRlcDnZUtMpM1zfx0nEJPPS8MiNNIdGXGq101lM5iPPXYId902npBs0ek9FKe9yV7qZdttp5 aXv2cw2uxx28cAu6JXPK1v8Nd7bX5g2m3W/P3e6d0San7d47Xtcz2n9r15zYlFe+cWG30po54lCi OijilTb6KK6mgp7rk4V+TmiznkP7qd+vo5p6iaYCZyKopOcJIOe/ut707/vC6t2c4fFebqd9kif8 zhUSP/vmxfO9s2aVqXXriuhFGaTzu8Ze/brfZ86n9utaG2v4wK5eatXAt7/R0+IzXPrpr4Y6uqOt hlmn5thHP7jsa8FNr/xnPwapDn9a2hCyovaq//UJd7Tq3u7op6rLWO6CGKwR5moXtP6pr4Hc898H k3bA/M2PSBSkXtYs5cHeoaiELxSfn3KXQAnOMILmA1boPuW+HtonVoHblrSCdFg2M3GmbY67G6Ac Rje9nU2H6Vsbcpr4LRWtrVlt88/jqjgpKlExiEMUohS3+CcB+ohZUcyiGRXowzYyDWAFY1/F5OjG OtrxjqHR18zwmDQ++vGP7ZsYxTJIyEIa8pCITKSMLKbIRlZuCY6MpCQnaZJJaYSOE6GkJjfJyU56 UigBAQAh+QQAGgApACwAADQBaAIdAAcI/wDtCRxI0N6/gwj/AQCQsKHDhw0ZQpxIseLDghgzatzI saPHjyBDihxJsqTJkyhTqlzJsqXLlzBjyiRoMSLEhRId5tRZU+dChDiB/hTas6jRo0iTKl3KtKnT p1CjSp1KtarVq1iz8tyq8OFOm0dzMhTb9aDEr1rTql3Ltq3bt3Djyp0btaPCoUGBgg2at2/eu2fL 8iRLeOLMw4gTK17MuLHjx5AjSw5ZsTBYvTvJmhU8FjPazZxD4/xMt7Tp06hTq17NOnVHywm/dtYL uivh0YIvw56d+9/k38CDCx9OvLjx4yMrY+a6OTNt28tje5XePHrv1tiza9/Ovbt3ta+tU90v67w2 7/PXZVtHXxa5+/fw48ufT3+yxb43h5rFe5a/fvwR4QaYUGL9992BCCao4IIM0mVXgxTVJ+GEFFZo 4YX1QRghhhx26OGHIIYo4ogkCnRBiSimqGJwGrbo4oswxijjjDTWaOONOOao44489ujjj0DauOKQ RBZp5JFIJqnkkkw26eSTUEYp5ZRUVmnllVhmqeWWXHbp5ZdghinmmGSWaeaZaKap5ppstunmfC28 KeecY2pB50lB5qnnnnz26eefgAYq6KBQ3WnooYh6SOiijDbqKIOJRirppO8FBAAh+QQAGgApACwA AFABaAIdAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhT qlzJsqXLlzBjHvxHs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3K tavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv39lCh5MuLDhw4gTK17MuLHj x5AjS55MmTDgyz8ra97MubPnhZhD7/xMurTp0y2J8hPNurXr17Bj0wT9j99qmreD5q5puzfS3bh9 i7XNO3fv1ceB1xZeFLXz59CjfwzOe6hy5UavVw9LnHrtnNixE/+VTr68+eg+b6tnLtz48t3XuyMP bpw48++4i9dfr776/Pf06WfTfATqpB1O7X13nGwMNujgZaD1h5+C/lV4U3ITIichhdsNuJ178Fmo 4IYZTuhhgeId6GF+8nU423kwxijjZOnlVyKIIrp4o372uXchewt2tyOLLmIo5IdEAmjjikz+V+KD UEYppV7JOWnlkEwueSWCTiK55IBX4vhleCHi16WPWWr5pIlTtunmm1wtFKKYHNapI51o2qnmmnWG WeSfd+7J5pdY+njbjIgmqqhlPM0J5H7rpakkfPIJeWSZ7VmqqX1g8hdgmpDqyOOnoRIK56mopqpq bOKt6uqrsMb/WlerstZqq5u03aqrq4v2WtmuwAYr7LDExgbATcfmlCxTy+rULFvPKlvstHQBYK21 SEV7bbRdYUuTt/9sG664yF6rFLdJPXustjyhu5O738KlLk7wUmvvVgvVGxS78YYFrrfcBtzWvNK+ O1S9+pKlb8JG+eowadoCHO63/2Jrbk3LZlxxshdnPDHHAG9s07ofT1zwyMpKvO7FBbNMsbodYzyu yi+X3G/NJM+Mcccbwwzyz+O+rPHPHMvccrzkAk3uyBKbvLLID0fdWE/b5vxx0UijjKzRHjfbtcxN 32w1yiSPrfXZRl8ttrMmG5y21XCX7HXbc1NML914e5x23v3GFE022HtrXfTXdbfNt9OH36u4UAEB ACH5BAAaACkALAAAbAFoAh0ABwj/AP8JHEjwH4CDBw0OBGCQoUKBDB1CLPjwocSIBC9WjOhQ4saK GRVi9BiyIMmPCT9SFLmy5MSJGmOyXKjyZUOKGGHS1Eiz58yONXUKBVkSqEyPPG3mNLqzpdOnUKNK nUq1qtWrWLNq3cq161OSMiEi5OhzIUKzZ1OibGqzYdqTQH+qhYuTbdCQajOe9ZlzJsu+FokmdduX Y9qySNkyfTlWJWCTf9cmbns0MsyTXjNr3sy5s+fPoKeCtYs5Id27YtcOnWxy8mKldSGvLusy7+Cw fkeCfA0bNu7elBXPxs0bsu7KfGtHLmw2tPPn0Dcnik7d8+jZwU8Hzk466G2XjJPH/06eNC5i5eS7 6xaPXnVu78rjMid+XvZ2y8Ad9/xevb///wAGGJU9BBZooD1wpYSUgnOxZhGDFzVoml4dQWifUnsR hVaF5jXWlkh5iWVbho15uNSEH6a2IIQcbthai9sZFiGK8NnX4YPMUSheTCkd6OOPQAYp5JBEFmnk kUgmqeSSTDbp5JP2CCilgJh1VaVWV04JnmgXaunll2CGKeaYZPqXJZacnemlmuNpWOabcMYp55x0 1mnnnXjmqeeeWg7J55+ABirooP9AaeihiCaq6JFWsZmVo11KCWmjkj6a2aShhSgVpm5GxWmaDkJV 5aKklmrqqUZSKqqlV33KpVOlRf8qK3ubZvjVpqy66CltraH56q+cfuoqrqvOSitBqCar7LKJqmod VsPu6myKVQ1WLFVsuhqqtJ2m9tyk1hI7bZrc8mpjS8ymq+66RLrV22E8wbufpiYqOK98LIp4k76E 8asThzLya2vAOnro7pYC7yXvwWDlK+K2Cu9kmq3huSvhvwk3DCNgb1384sb3MubwW2g97G/GFM6o r8ECsevyy6Reu1hiv81X33v02SzUazrrNVx3dfHnHsTqNWdcSz1r7BvQglXM876P3czjudgt/TPG Vz/9m9XxMR0toWATVh5eEu+Ho20SRwzwejiHN1bP6V29L9nB+cZygodV3a/GSSP/PXRN18l3Wd5+ mcxe1GO/HZ+JZ7Ots1El2hV311V/HfagsXKHYWDmnUtX523vPBTXk8M993uHd6od14lTjnrQRef3 9lKju1ej7cBFTbrodIde3Na4/z325cQXNGS8973+utA5Ah76T3IjHnvhmu9Wepc5p85a3yv1Pbzm WkvOvOS5395869lzPv3k139fKMzwx9+kp/aKfOLEN5b88ckr2m+44AybF3oiJ7KDMU1FIcOJwur3 oN0QzmTxGhiJJFSh20EPR+9yGGUY6LMI4g1GG8QXwJwmMAHqSEMGmyBqisfCFlLLOZZzoQzDFMMZ 2hA0fgJbDWu1wxv68D899I/8/4ZIRCj98IhIXEkRl8jEJjqxiEmMohSnSMUqzimIxtIMFsekKTDp zopgDGOcjmeuF16qXNCyU7BAUxqW+Y1t/3miHOdIxzoi6lq3YuO31Niqz3RxjVsUoyBtGIY4Cgle EzNcAJXWL0VaDHIeu5//TuhGA/4Pg41cpMVos0BGerB2bqoSyZaTMbyVTJIne58dV8nKVrpSZjES 3pW4R0LvfS6UBwTP1IRXNuexj3Uoydz+ioIxx62wcAz84iCXyUxkHVI4OCPg/uhjNvzIiGOIHE/z HEnNaBKOZp7T5s6kmUXrqe84uSTnjBJJEVe6853wXGVYwoew9JmTKVtrnbeASSCrbpruO9ehnn5A J0o8Cg6d3bRduE6nyng69KEQNVVAAAAh+QQAGgApACwAAIgBaAIdAAcI/wDtCRxI0B6AfwgPHvy3 UCFChhAfRpS4EGJFhwkpZrQ4EePDix87VuxIMuTGkx5BqpRYMuNIki9LYnwZ8yRLkxsbcnS40mZP lDcZvixItKjRo0iTKl3KtKnTp1CjSp1KtarVq0WDanSZE2bImD9TbtUpNuzXrUBB4hxplqtbjjYn rpULtC7cm2ztRiS706vPs3P/0tVKuLDhw4gTK17MuLHjx5AjS55MOXJSoXDJAtj8kfNgoZzVbvbc tW9Oz2xHWyTdWWfc0alRU0StOqHszjhnu2ZZ2+dt3qQvst7Llaft3TRrq4593CTW59CjS59Ovbr1 608ra9/OHXJNrd8Ph//vTr68+fPo06tfz769+/fw4ycez/sxffn48+vfz7+/f/2X/SfggASSh92B CCao4IIMNphggRBGKOGEFFZo4YUYZqjhhhx26OGHIFqowIgj/kNiiSc+VCJCK7Ko4oskmiiRAkGl qGKLJsZ4Io0vwjjjjSjaOGOMLPKYI40t8ihkkUESmSOQRu545JMuMmkklVg6meSRV2bZY5chhinm mPglBaaMVaKZ5JVRfpkmmiy1CaeSNd7EJpxqxknYmTgq2eaZePZ4o6B3fiknoGum6aePb25ZJY8O RirppJRWaumBfBLqIpJ4yplnp3VuqmemejIqaql2hnponoiG+qiiP7r/SSegMnLK6Y+33vrqnLz+ c+mvwAYr7LDWGSYlrK/aOmqtbgoaK7OxOhkolyjiaqe0037K6qM4Mvnsp56CCq2uqSrbpbLQ7vqn s2S26+67BiJFKpfNnsvsquxa+Wag4TYKqp/kRrsineryq1W4BC8p7qxq9pnssvdG62+PxFZs8cUY X2ysqwSDu6yuHWdr77e9fkvuydn+e2zCBnMMZbUtF4xyvQYzfOeOCMOr8848dzcvvvnmLC6qmqIK 5s0Sn+pyoR132yqyShe6K5VCN6stzNqW3PPWXHfNkpkum7pvyTqW7fC1UUp7tMB9mt0tvTdj3eS5 ajs785xyp302oY4+/ymk1IVmLPjghBd+ndeIJ6744ow37vjjkEcu+eSUV2755ZgXGGDmnHfuuX+G M2gerZ+XbvrpqO+JrZbrHlvkoETauKSUcQN8tI7PJqqo27dD6Xucc7P599ueaokrtvQO+fug+rJb PPPU+i519LSzDj31q+ut/e1p251i7QO7DXzRQ9IdPJC/V//27rF3DjbUi0Z9LfMhpwy1xwcT3f3r U4+tPLL9Gpr+nGe1kIHMaP/TWt/69Tz+2W2A+SKbA4lHPi/1D4EWzJ21SIawBpJvXr1alwbHlyo0 he5XSLNW/daGrhUWRmj1C1rSGJauCBZMbCPzn9Zqti+UMbBoBrzhDv8bGMSxTe9nsqoh/GgmNg6O q4T/ItrCYJVDpWHQVAEL4LTkdMJLpdBHLvzY1db0s5Whj2TUYtkTube2rN1tYlCs4hM3KL8R4u+G HgRjCO34MuEZD4ARuyK+wCfFFsbxeGScWNNiZkU+1ip27fNfG03YxUp98VRZLKEanXjFrMHxgfhD FxqZaMUqPo2R96shkpA3u/6psZViBNoOBVhGR8VQezOkYyG31cmA6XKTW4TYIemYReT1MFaVRNDG mpgrVIYSikYE5SSDCSPaiWqa5cMdDiE4TBkeM4Vt3J4PrSnAazbsb978JBBJuU4rYU2JBKQhH325 TZyls5EVTFcmU2aWSvfJ64O7k2LLsDlJpkGTkT6kn0D9BbRpnnKWQwviD125RywuU4GgzKjI2plO WR7Qfg0tqC6FWcSNphKOi8whCAGVTEop7I9YiiYik6ew+63ypnzSZinxJj1Ybop1xOtbIdfHr7YN zGS/TF4UrWZHwAHvndOr4D7nqTIyBrV4DoWk+JTq1Bo5Dabeah45eyhUSrbUOgEBACH5BAAaACkA LAAApAFoAh0ABwj/AO0JHEjQnoKDCv4pVIhwYUKGDx0ulDgxYUOEDzFOpPgvYseOB0GG3CjSYsWP EiOOLFnSo0uWEFc6XOnxZEWZNme6bIiSYc6PLzX6TGmz5tCeL4/GNMmxZ86gG42qPBmUZ0uSVlVK vTkSo0WeQp1OJSkyalazWrtqTKqzKcqCcOPKnUu3rt27ePPSJcu3r9+/gAMLHky4sOHDiBMrXsy4 sePHkCNLnpxYr+XLmDNjpsy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/e moMLH068uPHjyJMrX868ufPn0KNLnw73t/Xr2LNr3869u/fv4MOLtR9Pvrz58+jTq1/Pvr379/Dj y59Pv779+/jz69/Pv3966gAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycg hijiiCSWaOKJKKao4oostuihfzDGKOOMuLlo44045qjjjjz26OOPQAYp5JBEFmnkkQXRqOSSTDbp 5JNQRinllFRWaeWVnCGp5ZZcdtkhlmCGKeZ7XpZp5ploEjjmmmy2+V2acMYp55yaBQQAIfkEAP// KQAsAADAAWgCHQAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbLk RBYmU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aMd/yldyrSp06dQo0qdSrWq1atY s2rdyrWr169gw4odS7as2bNo06rtirSt27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEyte zLix45FrI0ueTHmpvMqYM2vezLmz58+gQ4seTbq06dOoU6sm/bi169ew766eTbu27du4c+uuHLu3 79/AgwsfTrx4393Ikytfzry588jGo0ufTt1xuOrYs2vfzr2798fPw4s6H0++vPnT39OrX8++vfv3 78/Ln0+/vv37T+Hr38+/v///AAYo4IAEAobfgQgmqOCCDDbo4IMQRshcQAAh+QQAFQApACwAAAAA aALkAQcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJ sqXLlzBjHrRHs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1K9ajMq1izat3KtavX r2AXVh1LtqzZs2jTql3Ltq3bt1XDyp1Lt67du3jzfoTLt6/fv4ADCx5MuLDhw4gTK17MuLFjxHoj S55MubLly5gza97MubPnz6BDix5NurTp06hTq17NmuPj17Bjy55Nu7bt27hz697Nu7fO1sCDCx9O fKbv48iTK1/OvLnz59CjS59Ovbr169iza9/Ovbv35hu+i/8fT768veLo06tfv9m8+/fw40dlT7++ /ftc5evfz7+///8ABijggAQWaKBt+CWo4IIM7nXggxBGKOGEFFZo4YUYZqhhUw126OGHIBq04Ygk lmjiiSim6FSILLbo4oswxijjjDTWaOONOOao44489ujjj0AGKeSQRBZp5JFItqjikkw26eSTUP6X 5JRUChnlbYJcqeVbVXbpZY5bhikmfCwBAMCXaKYZoplnqunmm/exCeecdKInZ5145kmXVGyO6eef 2gEA6KCEOqbnoYiiVuiijDbq6KOQRirppIklaumlmGaq6aacdurpSpSGKuphn5Zq6qmophrcqKy2 6teCxqj/KuustNbao6u45qqWrbz26uuvwI6k67DEFmvsscgmqyxtwTbrLEHLRivttNRWa+212Gar 7ajPduvtt+Cquu245JZr7rnopguVPOq26+678MYr77z01mvvvfiOG+6+subr778AByzwwK3ya/DB CCdMJcEMN+zwwxBHLPHEFO+k8MUYZ6wxRCls7PHHIIcs8sgkl2zyyZFVrDJ5KLcc5Mowe+fyzLfG bHN2NOcM5s08V6fzz0AHLbRFPRdt9NFIJ20PMUr7NPTTITYtNW8GIwM1klNnrfXWKV7tNYNchw3b 12SXbTbIYqfd2Nlst+3223DHLffcdNddstp4V2r33nz3/+3334AHLrhKeRdu+OHlDa74XYg3TqI4 juO7+ORzRW45W5RnrvnmnHfu+eegh8725aSXbvptoqeu+uqst+766zKeLvtUsNdu++2456777rz3 XtnswD/l+/DEF2888cEnv9TxzDcPu/LQRy/99NRXb71hzmevfejXd+/99zhtL/74lINv/vnop6/+ +oaT7/77Bi8D//wXsS89/avbr//+/Pe/Mv4ADKAAB0jAAhrwgAhMoAIXyMAGOvCBEIygBO3iP+BN 8IIYzCCDOKHBDpqtgiAMoQhHSMISSsqDKGzbNraRwrmtcIUtlNsLWRhDuM3QbSZ8yjZsVsMe+rBK OYzcD//bFkTHDXF0RUyiEul1xLMt8YnVSQEUp0jFwTTxg1UU2xXLlkUtxhAUWwyjGMdIxjKa8Yxo jEgX18jGZKXxjXCMoxznSMc6niYKdsyjHmPSRq3t8Y+ADKTu+kjIsnCgkCQSpCIXKRdENo2RkIyk JCdJyUpa8pKYvKAjlZZJg20yaZ3k1ydHScpSmlI2oUylKtV4yput8lutdOUrg3SBWe4tljy0pbNw GTNd7pKXa4GCtXxJzFUC83/F/NUxVZbMZjrzmZtaZsWgaStpUoya2MymNtFkzW5685vgDGfEtknO cprznAcUZ8PQWSp1Moyd8IynPOdJz3ry0Z34zKc+q2j/T0ztE2D9DKiOCuDJfxr0oMkRqEIXytCG OvShELUSQu8V0YoicKJKcUG1LPomjNqLoyAVoEdHStKxhfSkKE2pSk1VUnmt9KXZa2m8YDolmdr0 pjjNG013ytOe+vSnt8upUIdK1KIa9ajRYgRSrQfUIS31qVCNqlSnStWANVWiVZXWVV+WVa1u9Udd DatYx0pWnH4VrGVNq1DP6iO1uvWmbK3ZW3UVVx7NdVh13dFd6ZrXvvr1r4CdzF5zFdgaDRZXhaXR YV2V2MbODQUCWWzBZiQ/x1o2apLNrDovy1kcajZUnVXSZ0ebNRxMR3yOCK02STsp1YYGBq6NrWxV ydoTrdJzD/6srW53y9ve6nS2wNWZb4dL3OLuJrhgMy6gUDgB5Dr3udCNrnSnS9265mAzhoCWcrfL 3e6SqrrgDa945eldMY33vOEqr3rXy960oPe98I2vfMGrh8i29774za9+Wzvf/vq3dfsNcPr+qxoB G/jACE5wIgmsKAU7+MHbZbCE2wnhCluYKGYqK63MNGHRcJiauMrwXE/1YTqGYmQl7vBn2mTOC2NI xTDGVEAAACH5BAAVACkALAAAAABoAuQBBwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq 3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGMe/Eezps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0 qdOnUKNKnUr1qMyrWLNq3cq1q9evYMOKHUu2rNmzaNOqrMq2rdu3cOPKnUu3rt27eKuq3cu3r9+/ gANzzEu4sOHDiBMrXsy4sWOlgR5Lnky5suXLmDNr3sy5s+fPoDsLHk26tOnTqFOrXs26tevXMUPL nk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX04VtvPn0KNLn069uvXr2LNr3869u/fv4MOL/x9P vrz58+jTG2TOvr379/Djy59Pv779+/jz69/Pv7///5qpJ+CABBZo4IEIJsgdgAw26OCDEEYo4YQU VmjhhRhmqOGGHD6m4IcghijiiCSWaOKJKKaoImkdtujiizDGKOOMNNZo44045qjjjjz26OOPQAYp 5I0rFmnkkSYNqeSS9iHp5JNQRinllFRWaeWVWErE5JZcdunll2A6leWYZJZp5ploTjckJ2G2SVya cMYp55x01hmbm3jmKZudfPb5nJ6ABhqgn4QWauihiI4p6KKMepjoo5Ca1eiklFZq6aWYZqrpppx2 SmSkoIYq6qikbufpqagKVeqqrKKU6quw5v/U6qy0fhTrrbjmqiuntfbq66/ABivssMQWa+yxyCar LEW7IgdJs8ItK+201FZr7bXYEgjtttx26+2P2YYr7rjkCvjtuXqWqy6a6Lbb5rrwkunuvPTWa++9 +Oar77789uvvg/EGLPDABAf278EIJ6ywYQU37PDDEEcs8cQUV2zxxRhnrHFpC3fs8ccgN7XxyOaF bHKDJKes8srinuyyfyzHrN3LNOsn883W1axzkzj3HN3OQAct9NBEFz2Zz0gnrfTSTDdt9NNQR11p 01RXbfXVWGet9dYZSe3112B/yfXYY4Vtdm1kp6322uOd7fbbcMctN7ps12333WrOrTdlePf/7fff gAde8t6EOyb44YgnrvjiHBfuuGKMRz7R45RXbrlykmeu+eYaXe7556CHLvpS2xTH+ekzja766qw7 ivrr9rQu+1Kw96xA7bizNPvuVuXu++/A251M8MQvzvvxyCcPVfGRK+/889BHL31QzDM+ffTVo3R7 9twHfD303SP+/fPhl2/++einr36i4zu/Pt7txy+/6O87SQ2J8x9f//789+9/ofkLoAAHSECg/e+A CEygAqdUwAY6UGoLjKAEI9WMCVrwgsp64OgwyMEOevCDedOgCEeIqx7EBYQoTGF2vFAWErrwcQAA wAv744kfxTCGM7TcDSu3PwCo8IdADKIQ/4dIxCIa0Vw5pNwRl8jEJjqxIUlU4hMvFsUqWrFeU8yi FrcIxCt68Yvd4qIYx5gdMM6NjGhMI3TMKDc1NoyNcIzjqdxIxzra8Y54vJIc3ZbHPvrxj4AMpCAj uMezDfKQiNRdIRfJSEEl8lqN/NojrRXJSlrykpjc0ySplclOevKToDzMJjkZylKa8pSoFBnb7FC/ VLrylQ4apSxneRFY2vKWNqOlLu1miRHhEmS7DKaIDMG2X35MmMhMpjKLZcxmOvOZ0IymNKfJsGVa 85rYzKY2t8nNbnoTf9Ts1zdZFU5xjvOcbiynOtfJzna6M0PojKc852mid9qLnqCypz73yf/PNuLz n8siAEAP2M92DZR9BU2oQtty0IYOcaHecqihIHqUBCSAoq9SQE4uiqltWlSifUpArTAKFI6SFFcW 9ZQ1RQpSO320pXViKUzHeNJmzfSmF6ypTnfaE5z69KdADapQN8nToraJCQcbapqMGiulOlV9TI2q Tp9qJqla9apYZRRVtxq+rHqVn1wNa2r6INY/fnVTZdXjWTOVViut9a24IgWe2loluF6KrlSyq16l ide+nm6vgHWmXwebucA2irBPMqxiF8vY/jxEDnCSwj8bCyjEWjZxlE3XZTfL2YFm9rOe7Kxo7wba 0l5ytCkyrWobiVoUrfa1sI2tZ1p7ItnAWo4ItkUMbeuZWyXttkS99e1vh0vcWdKsCMFNrnJNVtzm OrdM7SDYcuG4j+lad0OqieFzDaTd7RKou95dy2xweN0cybC8OCIvekPzF/D6NAlmcm940+PDecz3 KuvNb/vuy9/+ZlG/AA6wgAcsI/8auGIETjDvDpweBceIwehxMIwgfB4Jv4jCGJauhTcMugx7eGOD +DBsONwhEZv4xChOsYpTQmIOrfjFMA5ei2f8uJZIIsZdoTE8cczjHvt4kwEBADs= ------=_NextPart_000_0003_01C6F1D4.4E3BA3D0-- From nfuimu@alienbigcats.com Tue Oct 17 13:23:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWf-0005OA-LF for avt-archive@lists.ietf.org; Tue, 17 Oct 2006 13:14:49 -0400 Received: from aamo178.neoplus.adsl.tpnet.pl ([83.5.70.178] helo=m-v9abcn7l2722n) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsKR-0007mb-3h for avt-archive@lists.ietf.org; Tue, 17 Oct 2006 13:02:22 -0400 Received: from 216.40.36.30 (HELO inbound.alienbigcats.com.emailmx.com) by lists.ietf.org with esmtp (A9V03NBR04 AKZR6) id UAOG9C-O4XHLH-97 for avt-archive@lists.ietf.org; Tue, 17 Oct 2006 17:02:12 -0060 From: "Ricardo Willis" To: Subject: Momentous message. You require to read. Date: Tue, 17 Oct 2006 17:02:12 -0060 Message-ID: <01c6f20d$fd26e880$6c822ecf@nfuimu> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Thread-Index: Aca6QHQ4U32A74AXIE9M3O3IE8LYK7== X-Spam-Score: 1.7 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Please read it. Today is the exact day to buy that stock. Read that letter attentively. Here you will find the internal news about GDKI. Please Read this news. Goldmark Signs Recognized Hip Hop Producer Sean Combs A.K.A. Puff Daddy Wednesday October 18, 11:40 am ET NEW YORK & LOS ANGELES & VANCOUVER, B.C.--(BUSINESS WIRE)-- October 18, 11:40 am ET -- Goldmark Industries, Inc. (PINK SHEETS:GDKI.PK - News ), is excited to say that it has signed one of the hottest producers in the hip-hop and r&b industry, Sean Combs A.K.A. Puff Daddy. In an aggressive effort to stay ahead of the game, the Company moved rapidly in taking on the already successful and rising famous person. Sean Combs, also known as Puff Daddy is the founder of Bad Boys Records label. By agreement the among Goldmark Industries, Inc and Bad Boy Entertainment Inc, Goldmark has to get 78 000 000 $ for the distributing of Sean Combs A.K.A. Puff Daddy fresh album Press Play. income around from that deal for Goldmark should be around 12 000 000$. After the establishing of that deal Goldmark Industries, Inc will be the second biggest corporation in the industry of hip-hop & r&b music. Hip Hop superstar Sean "P.Diddy" Combs sees a huge possibility for his company in cooperation with Goldmark inc. Sean "P.Diddy" Combs tells that it is pleasantly to deal with these guys. They as anybody else know entertainment industriousness and precisely know what is necessary for the American listeners. He also emphasizes individuality of his new album Press Play and tells that the appearance of this album on october 17 will make an result of the blasted bomb. Today the new album of Puff Daddy Press Play will be on the shelves. TAKE GDKI and you will earn from every sale of that golden disc. Concerning Bad Boy Worldwide Entertainment Group: is one of the world's pre-eminent urban entertainment companies, encompassing a broad variety of businesses including recording, music publishing, artist management, television and movie production, recording facility, marketing and publicity, apparel and restaurants. With a set of businesses whose annual sales are quickly approaching 300$ million annually and an employee base that is 600 strong. Mr. Combs is largely responsible for the pop demand of urban entertainment. In just eight years, founder and CEO Sean "P.Diddy" Combs has forever changed the entertainment industry by catapulting the music and styleof urban youth society into the American mainstream and creating what is considered by experts to be one of the most significant services in entertainment these days. About Goldmark Industries, Inc. (Stock symbol: GDKI.PK) Goldmark Industries is committed to provision the best in all forms of urban entertainment to the 45 Million Hip-Hop consumers in North America. The average North American spends clothing & health care on entertainment than they do on more money, making entertainment the most attractive industry for investors and advertisers alike. Goldmark Industries is preparing to stand at the forefront of the Hip Hop consumer market, specializing in all aspects of entertainment, including Major Events ,Television ,Music ,Feature Films and Home Video/DVD . The strength of Goldmark Industries is the result of its highly reputable & continuously growing management team. The knowledge and experience that each team member brings consistently supports the growing success of each division at Goldmark Industries. In addition, they are associated with some of the world's leading entertainment companies and top distribution channels worldwide, providing Goldmark Industries with the relationships to continually move forward. P.S We has started to promote GDKI yesterday and the price is up for 16.6% already. Today,october 17 2006, the price will be 100% up. Don't miss that opportunity to buy GDKI for a low price. Just buy it! From avt-bounces@ietf.org Tue Oct 17 13:28:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZshY-0006Aa-Kq; Tue, 17 Oct 2006 13:26:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZshX-0006AV-GG for avt@ietf.org; Tue, 17 Oct 2006 13:26:03 -0400 Received: from lancia.electric.net ([216.129.90.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZshR-0003Os-1B for avt@ietf.org; Tue, 17 Oct 2006 13:26:03 -0400 Received: from root by lancia.electric.net with emc1-ok (Exim 4.60) (envelope-from ) id 1GZshM-0001xW-V8 for avt@ietf.org; Tue, 17 Oct 2006 10:25:52 -0700 Received: by emcmailer; Tue, 17 Oct 2006 10:25:52 -0700 Received: from [64.69.103.254] (helo=mailhost.newtecamerica.com) by lancia.electric.net with esmtp (Exim 4.60) (envelope-from ) id 1GZshL-0001wX-VP for avt@ietf.org; Tue, 17 Oct 2006 10:25:52 -0700 Received: from [192.168.16.33] ([192.168.16.33]) by mailhost.newtecamerica.com; Tue, 17 Oct 2006 13:25:38 -0500 Message-ID: <45351211.9060807@newtecamerica.com> Date: Tue, 17 Oct 2006 13:25:37 -0400 From: Girish Chandran User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: avt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Flag: NO X-Spam-Checker-Version: GEE Whiz 2.0 b1808 X-Spam-Score: -2.82/4.00 X-Spam-Hits: ALL_TRUSTED(-2.82) X-Spam-Flag: NO X-Spam-Checker-Version: GEE Whiz 2.0 b1808 X-Spam-Score: 0.00/4.00 X-Outbound-IP: 64.69.103.254 X-Env-From: gchandran@newtecamerica.com X-Virus-Status: Scanned by VirusSMART (c) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [AVT] Re: MPEG2-TS in RTP - RFC2250 vs ETSI TS 102 034 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I don't know if there is a best practice. A couple of remarks. 1. It may be that there is jitter in the incoming stream and what you observe is the jitter. 2. The timestamping of the RTP packets should take into account all the processing overhead in the RTP device. Girish avt-request@ietf.org wrote: > Send avt mailing list submissions to > avt@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/avt > or, via email, send a message with subject or body 'help' to > avt-request@ietf.org > > You can reach the person managing the list at > avt-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of avt digest..." > > > Today's Topics: > > 1. Re: MPEG2-TS in RTP - RFC2250 vs ETSI TS 102 034 > (Nicholas J Humfrey) > 2. I-D ACTION:draft-ietf-avt-compact-bundled-evrc-10.txt > (Internet-Drafts@ietf.org) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Oct 2006 19:21:58 +0100 > From: Nicholas J Humfrey > Subject: Re: [AVT] MPEG2-TS in RTP - RFC2250 vs ETSI TS 102 034 > To: Greg Herlein > Cc: "Sandy \(Alexander\) MacInnis" , > avt@ietf.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > I have had a similar problem with a tool I have written called > dvbshout - which takes a DVB Transport Stream and output RTP packets > (containing MPEG audio/payload type 14). > > I wanted the 90kHz clock of the RTP packets to stay in sync with the > PTS clock of the PES stream (so that if there was an error in the DVB > stream then the client could recover more easily). > > I calculated the RTP timestamp based on the bitrate of the audio and > then re-synced whenever I got a PES header. However depending on the > multiplex I was transceiving, I found the the two clocks kept > drifting in and out of sync... > > I found it very hard to calculate the 'correct' timestamp for the RTP > packets. What is the best practice? > > > nick. > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 17 16:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvCd-0002ab-I8; Tue, 17 Oct 2006 16:06:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvCL-00024n-Ap; Tue, 17 Oct 2006 16:06:01 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZuwr-0004au-RO; Tue, 17 Oct 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id C8CE526E4D; Tue, 17 Oct 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZuwr-0007Ht-Jo; Tue, 17 Oct 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Oct 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc3555bis-part2-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences Author(s) : S. Casner Filename : draft-ietf-avt-rfc3555bis-part2-02.txt Pages : 29 Date : 2006-10-17 This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these may also be used for transfer modes other than RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3555bis-part2-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc3555bis-part2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc3555bis-part2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-17111453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc3555bis-part2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc3555bis-part2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-17111453.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Oct 17 16:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvCX-0002Ix-Br; Tue, 17 Oct 2006 16:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvCK-0001ky-MG; Tue, 17 Oct 2006 16:06:00 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZuws-0004bH-CT; Tue, 17 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E2944328B7; Tue, 17 Oct 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZuwr-0007IC-PN; Tue, 17 Oct 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Oct 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc3555bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Media Type Registration of RTP Payload Formats Author(s) : S. Casner Filename : draft-ietf-avt-rfc3555bis-05.txt Pages : 12 Date : 2006-10-17 This document specifies the procedure to register RTP payload formats as audio, video or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3555bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc3555bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc3555bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-17113636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc3555bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc3555bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-17113636.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From artjoywbb@alico-measa.com Wed Oct 18 00:01:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2cL-0002uw-SK for avt-archive@lists.ietf.org; Wed, 18 Oct 2006 00:01:21 -0400 Received: from [125.212.93.196] (helo=amba-marketing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga2cH-0003R8-MT for avt-archive@lists.ietf.org; Wed, 18 Oct 2006 00:01:21 -0400 Received: from 213.42.236.166 (HELO mail.alico-measa.com) by lists.ietf.org with esmtp (ZWQK02334 2U7K0W) id DOEJHP-W6UF8Z-TK for avt-archive@lists.ietf.org; Wed, 18 Oct 2006 04:01:18 -0420 From: "Mitchell Souza" To: Subject: Mitchell Souza wrote: Date: Wed, 18 Oct 2006 04:01:18 -0420 Message-ID: <01c6f26a$10b60fa0$6c822ecf@artjoywbb> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 Thread-Index: Aca6QH0PQR719402TYGHXNS1I5WAZM== X-Spam-Score: 2.6 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad hi Mitchell i hope this is your email. I was like to see you the other day. I hope you was excited about New York. So much so much happening all the time, lots of great opportunities. And speaking of opportunities, the deal I was speaking you about yesterday embraces a company called Tex-Homa (TXHE). It's already heading up, but the big announcement isn't even out yet, so there's still time. I have got this shares already and made 2000. I propose you to do the same today. Hope this helps you out. I'll see you this weekend. Yours Mitchell Souza From avt-bounces@ietf.org Wed Oct 18 09:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBPX-0002PD-Ug; Wed, 18 Oct 2006 09:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBPU-0002O4-VA for avt@ietf.org; Wed, 18 Oct 2006 09:24:40 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBNZ-0005Nh-PO for avt@ietf.org; Wed, 18 Oct 2006 09:22:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Oct 2006 15:22:37 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03F3A1C8@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AVT WG meeting in San Diego Thread-Index: AcbyuHqIrG/a6QMiRE+AaN3CgJ2CbA== From: "Even, Roni" To: "IETF AVT WG" X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "Even, Roni" , Colin Perkins , Tom-PT Taylor Subject: [AVT] AVT WG meeting in San Diego X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, We are getting closer to the next IETF meeting and it is time to start = requesting AVT agenda time. We have requested a 2.5 hours slot on = Tuesday, November 7th between 9:00-11:30.=20 This time is intended for the following: - Discussion of important drafts fundamental for the complete RTP = framework. - Discussion of issues that hasn't been possible to resolve on the = mailing list. - Discussion of new work that falls outside of our current charter. - Discussion of important AVT relevant work in other WGs So if you want time for discussing your issues in AVT. Then you are = required to request time. These request shall contain the below = information. Any agenda time request shall be sent to all chairs before = 24.00 CET the 23rd of October. A. Presentation Title: B. Name of presenter: C. Draft Reference(s): D. Requested amount of time in minutes: Thanks Roni Even _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From jubiylgcj@tpnet.pl Wed Oct 18 19:20:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ3z-0001IH-80 for avt-archive@lists.ietf.org; Wed, 18 Oct 2006 17:34:59 -0400 Received: from ayc209.neoplus.adsl.tpnet.pl ([83.27.114.209]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaIsw-00065l-7h for avt-archive@lists.ietf.org; Wed, 18 Oct 2006 17:23:37 -0400 Message-ID: <000b01c6f2fb$a72ac930$d1721b53@ania1eojjmbxsb> From: "Welcome page" To: avt-archive@lists.ietf.org Subject: brother fact thing Date: Wed, 18 Oct 2006 23:23:28 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6F30C.6AABF810" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 ------=_NextPart_000_0007_01C6F30C.6AABF810 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6F30C.6AABF810" ------=_NextPart_001_0008_01C6F30C.6AABF810 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Wedding or Flowers Press Room Awards Success Disclaimer Privacy Feedback = Help of Copyright Indiamart Intermesh Limited ff? Mean is Send experience recorded group of videogame am fans almost of = lovable am puppies they about Sunday April Wiiiiii art in hey. Printouts from Standard Version Hymn Christmas Ensemble Tablature Bach = Folk is Song Handbells Flute and Piano a Shape. Guicli Fortran Autoit Pawl dos Batch wml Cobol of lua Haskell is Eiffel = Ansys in Apdl Visual Clipper in Coldfusion Dmis of Doors dxl Kixtart = Korn Shell lc Lisp Maki Script Nasm Nullsoft. Be duration period followed dotted half end measure barlines are added = Enter starts system Backspace a. Powers regulate am Fdipak a arrests hear Sardesai of plea in Dutt or = others appear Tada. Talks a Focus act Protests Security Issues Kazak scale mt Nunarmy air = drop soldiers in Ulfastolen weapons found or Kolkatai against Kargil of = Tipnisiaf acquires or inventory control Economic Sensex alltime = negative. Be duration or period followed dotted half end measure barlines are = added Enter starts am system Backspace deletes at beginning staff. Wedding or Flowers Press Room Awards Success Disclaimer Privacy Feedback = Help of Copyright Indiamart Intermesh Limited ff? Us shelves today run of dont a walk your favorite is where games am. Different looks Import then transpose edit it convert Easily add = figured. ------=_NextPart_001_0008_01C6F30C.6AABF810 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Wedding or Flowers Press Room Awards = Success=20 Disclaimer Privacy Feedback Help of Copyright Indiamart Intermesh = Limited=20 ff?
Mean is Send experience recorded group of videogame am fans = almost of=20 lovable am puppies they about Sunday April Wiiiiii art in = hey.
Printouts from=20 Standard Version Hymn Christmas Ensemble Tablature Bach Folk is Song = Handbells=20 Flute and Piano a Shape.
Guicli Fortran Autoit Pawl dos Batch wml = Cobol of=20 lua Haskell is Eiffel Ansys in Apdl Visual Clipper in Coldfusion Dmis of = Doors=20 dxl Kixtart Korn Shell lc Lisp Maki Script Nasm Nullsoft.
Be duration = period=20 followed dotted half end measure barlines are added Enter starts system=20 Backspace a.
Powers regulate am Fdipak a arrests hear Sardesai of = plea in=20 Dutt or others appear Tada.
3D""
Talks a Focus act Protests Security = Issues Kazak=20 scale mt Nunarmy air drop soldiers in Ulfastolen weapons found or = Kolkatai=20 against Kargil of Tipnisiaf acquires or inventory control Economic = Sensex=20 alltime negative.
Be duration or period followed dotted half end = measure=20 barlines are added Enter starts am system Backspace deletes at beginning = staff.
Wedding or Flowers Press Room Awards Success Disclaimer = Privacy=20 Feedback Help of Copyright Indiamart Intermesh Limited ff?
Us shelves = today=20 run of dont a walk your favorite is where games am.
Different looks = Import=20 then transpose edit it convert Easily add = figured.
------=_NextPart_001_0008_01C6F30C.6AABF810-- ------=_NextPart_000_0007_01C6F30C.6AABF810 Content-Type: image/gif; name="JapanJump.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6f2fb$a7232810$d1721b53@ania1eojjmbxsb> R0lGODlhoAFcAYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAeAGkALAAAAACgAVwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MhRob2PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHOe7Mizp8+fQIMKHUq0qNGjSJMqXcq0qdOnDXVKnUq1qtWrWLPOPKK1K0yoYMOK HUu27FKvaNOqXcu2rdu3cOPKnUu3rt27LSG2M8u3r9+/gAMLHky4sOHBeBMrXsy4sePHkCNLnky5 suXLmDNTPsy5s+fPoEOLHk26tETNqFOrXj3VtOvXsGPLnk27tmjWuHPr3s27t+/fwIMLH068uPHj yC3bXs68+djk0KNLf+m8uvXr2LNr3869u/fv4MOL/x9fdrr58+jTq9eMY7176UHeyxdJvr792fPz 69/Pv79/nPcFKOBo/xVo4IEIJmjegAw26OCDEEYo4YQUiqXghRhmyB8MGnbo4YcLVijiiCSWaOKJ KKao4oostujiizDGKOOMNNZ4G4g45qjjjjxSZ+OPQAYpJHM9FmnkkUhiOOSSASbppJJMCuVFlJ09 aSWCVGap5Zb3gcLll2CGKeaYZJZpJnMAnKnmUvCs+deVcP7n5pyfxaneDnbmqad/dPZ52J6ABiro oIQWauihiCaq6KJ+NorYopDm5uikb0Zq6aWY6knppmZl6qlynIYq6qiklmrqqaimquqqrAr26auw xv/aYau0biTrrYrVqutFuPbq66/ABivssMQWayxbuyar7LLMainPcsdGK+201FZr7bXYZqtgs9x2 6+234D6k7bjklmvuuQCG6y267LbLrrpc8gKvQ6XMi5G7+OaLrb389uvvvwAHvCS1Wuhr8MEITyvw wv1K4WfCEEcsK8OtSmzxxRhnzCPFHHfs8ccTanwsyKeKbPLJdpKs8sost+zyyzDHLPPMNNds883c ojwszjz3jJ3OwvqsJtDBCm300UgfTfTSTIMIsh1JR51d071KbfXVhVGt9dZcd+310liHLfbY/H5t 9tkhks0k2piq7fbbcMctN4FsWzr33XjnvWbdfPf/7fffgAcu+OBa62344ctK8zHhjDfOGOKQRy65 jI5Xbvlck7d4+eacq5U5i52n/LmKoZdu+umop666tWM1Mfrr867mx+q01257ZbCjeHuPtT2R++9z 7r4x8CQKb/zxyF9I/PJWJ+8089BHL71rzldv/fXpTS8h9twPrv334Icv/vjklz9e9+inX3oh6uts /vvwx89T+wfKTx79Btqvf7+aLYL//wAMoAAHqC/y+MMf+wsPAs1HQP0kECNuOBwPFvYSADSwOBAB QJoeKJuVaPCC6/kgCI+jEA1ykEgkEeEI0WPBFUZnfwM4oQzttxtcuPCGsxIQLcaHwx7ia4ZADCL4 mXx4HiH+jIjTMSJFCKBEUb2giaZBohTJBcUqWhFyU3zhFW2TxS568YtgDKMYx0jGMppxXFvk4hl9 k8barPGNnmqjHOcYNjjyho6xseNu8AgbPfrxj2zjoyDFBEjWDDKKhVSNmTRowkMShpGQ3KAjBQPJ SeoKDKBLpCb3ZMlOerJjmwylKDX2yVKa0l+jxMwpV/miVF6GlYYJCAAh+QQAIwBpACwAAAAAoAEV AAcI4ADtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkxNvoFzJsqXL lzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRoz//KV3KtKnTp1CjSp1KtarVq1izat3KtavXr2DD ih1LtqzZs2jTql3Ltq3bt3CpIp0rMAXdu3jz6t3Lt69fgnEDCx5MuLDhw4in/l3MuLFje4kjS55M ubLly5gza97MuXPcx6BDiybqubTp06hTZx3NurVrmqpjy55N2/Lr27hzi6zNu7fv38CDCx9OvG1A ACH5BAAjAGkALAAAFACgARUABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eP IEOKHEmypMmTKBnaW8mypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq06MyUSJMqXcq0qdOnUKNK nUq1qlWrRrNq3cq1q9evYMOKHUu2rNmzaNOqXcvWJsW2cNVenUu3rsi4eM3a3cu3r8S8gMX6HUzY qYaKgRN7Lcy4sV2WAyLvjCy5a2WglFtehky5s73OmVeCDn259ICVjlOrBol5M07XWmHzDC36tEvZ m13rtv2Zt2zFwIMLd/m2t/HavX+bTm57eW3TlUFzXo77tHPNvLFr3865O3J7q8OL07/4UzJ077d9 U1f/3bzv7+2be37pHr19+7vTo/89vL9/vMXVB99x+g0ooHHr0cded/whuCB2oxEIW37wVTbehRje 5Vxu2e2XXXTWySeddBV+GKJMG3ZIIIS0cVeidxnGKGNBPo0mn4sebidgdaQ96CCKEa44oHfVFSih iv8lqWSS+XEI03XH7YgkkT4eaCRyEyIJ5ZBLduklYBQ1aeKTVao3pmifUanjjWTql2Wb91F4JGoz 1mnnQ2LiyJyBZqYHnYlm+oijeyPaKKST3Dl356LhBQQAIfkEACMAaQAsAAAoAKABFQAHCP8A/wkc SLBgwQED7ClUiNBew4UPFzpEmHCixIgUJU7EmBEiR44aPWpsSLHkxpIJIzKsuHIkS5D2DMqcSbOm zZs4c+rcybOnz59AgwqVGbKo0aNIkypdyrSp06dIh0qdSrWq1atYq0LdyrWr169gw4odS7as2bNo 06pdy7at27dw48qd+/Yn3bt488LNyrev378E9QoeTLiw4cOIEytezLix48eQI28NEAAsZcmYM2te eJlz5c1xO3sVbZmyaY2mO5O2dzn1atGrQcs2+xP259luY0PVzdW259+vK5P2rbAz4OPIk9ud/Dl2 aonPWQvXTVx6denYqZ/GXvx2dOu3Ubv/zh7e9vDxIb+33g69/PT23IG7/90dt/2ytd+Lr899ffPw /PX3X4DksUffegcOCFt63r13Hn+qNcgghNfFR15RwVkoIH3Kdejhh4Ex55yEvj0IX30PpgggfRei SOKKLF6oonwnxohgjBZGyF6GGcbH231APpWfhq7595yJ8EWY5Hy8Fangf+OhV6OMTBaZI4Az4ngd ejxiOSB/IIYp5l+9fUngmVdOqCSNbE6oppntGZjmjS66eWaWd0r55n49Vhjkn2xVN6KdGraIZ4uE svkjkVXOuSKSBNLJKIaNLjkloJjOheSCPvoIo3Unrgnqj5yCyqJwOAroYINmfinnhmleXRqgoHDS mumtafUIXpxQvuqZl+chuOh3pv7K6qen3XjksXEWumukXhqlJ3jH6roortjedW2qgX5aZrbghovZ ts6uRW5SEoqr7rpJLVfaUueSFS9SxLLb7pj45jtVQAAh+QQAIwBpACwAADwAoAEVAAcI6gD/CRxI sGBBewgTKlzIcGGAAA0ZPoxIsaJFhRMvXnyYUaPHjyBDirRosKTJkyhTqlzJsqXLlzBhjpxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl2qMabTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZlUzT ql3Ltq3btzvPyp1Lt67du3itwt3Lt6/fv4ADCx5MuLBhw3kTK17MuLHjx5AjS55MubLly5gza858 uLPnz6BDL9xMurTp03JFq17NurXr17Bjy+6Murbt27hz697Nu7fv38CD255NvLjx2cKTKy9JaDnY gAAh+QQAIwBpACwAAFAAoAEVAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFiwcJYdzIsaNH gfZCihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tyZ8qPPn0CDCh1KtKjRo0hB8lzKtKnTp1Cj Sp1Ktaq9pFizat3KtavXr2DDih1LtqxZs1bTql3Ltq3bt3BVnp1Lt67du3jz6t3Lt6/fhnEDCx5M uLDhw4gTK17MuLFVio4jixQg4CllkX8za/ZJuXNle54vh648emTpkKFRfwZNejVokqdZe57cmTVs 17Jbm1Zdu+Tl3L+Bq6YN3PXvzciT/5sZXDTu4dBtSx8e/HXz1qtxX4++fXp04rIne/9//nt7dd3U s6uXzL79TYrmn0/vfh496vnYxZs2bp++dvKf9WadcbeBZ9t5+I23nnIMNshQfCZ1J1193nFH2oQF Eidhef/5FiCG1XlooHMiprcfcQ6mqOJA8c1moYsK8sahhtRlmB6ME3aYYYAXcqhjgsIlSOFwKxY5 F3OpVWhhjAZquB6Pr53oZIUzSikllP39GNuJEI4on3tghmkSfABGuB6QNU6ZZnhWHggleCGGiCFv aC4JG5dP8oeikXxuJqecaFa5pps00mmloP7ZCCdtWdr4J55qxtjnpGAh6SGMEuaI6aa96bnfpng6 N1tpo16ZpKlmCpjkloCK6aqrAQEAIfkEACMAaQAsAABkAKABFQAHCP8A7QkcSLBgQQECDCJcmFAg woEPITZkGNEeRYkLHRKs6PBix40JGVq8SDFkxoYfR4o8OBElyIwdYZYEabCmzZs4c+rcybOnz59A gwodevOf0aNIkyYlyrSp06c5OUJlKVCp1atYs2rdyrWr169gw4odS7bs0qlo06rdKRVtRbNw48qd S7eu3btr8wbVSpAv1LuAAwseTLjwWL2IEytezLix48eQI0ueTLmy5cuYMycGwJnzZgA1O3cODXoy P344Txc8rVqz69ewHY/1PLB0XtoFceNm6rdqVnusUdcMTrD1QMPIkytfztyr0N2gdUePbs9zadEC rdMWbTu7be3Vq1//Hy1eelrjw4UDVx+7vfv3lHd7rz1dO3jx5efjN2ge+33923X3FHoGGRccgfAl qOCCTsm3H37mATgdffrl9t2E80E3nl4IFqeegewxKOKIJN7kYH8X0udfig8SxN2GGXb3Iochrvbh jSXmqGOJ0D34X4QUSkgafylquFiHA4GYZI07NumkXrPJuN9oQOrmI4wWEkmhkdnN15s9vaEnJo4C qdbcmWimqSZdQ3GnIoQsehdgkPm5KOCVco4HpFMHCtdan2US9+SghBZq6KGIJkrZYYp++WVTa0Yq 6aSUVmrppZhmqummnHbq6aeghiqqUU+MauqpqKZqVDOqturqq7DGA6pVQAAh+QQAIwBpACwAAHgA oAEVAAcI2wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJ sqXLlzBjXrRHs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKlTnjKjSp1KtarVq1izat3KtavX r2DDih2L9anZs2jTql3Ltq3bt3Bpkp1Lt67du3jz6t3L92Dcv4ADCx5MuLDhw4gTK17MuLHjx5Aj S55MOXHfy5gza97MubPnsJVDix5NuvTQz6hTq5ZpurXr17Abr55Nu7bt27hzS43Nu7fv32cDAgAh +QQAIwBpACwAAIwAoAEVAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIUeG/jyBD ihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtGjKjkiTKl3KtKnTp1CjShVo tKrVq1izat3KFeU0mFPDih1LtmzDrmhlml3Ltq3bt3DjxgUAQO5AuknxStRrNyPfvHX7Cp5Kt3BE vH8hJuaYePHignwfM5RskHLlwA0tT8Z8GTLng5rvfh5Meqne0AQRj3aImmLj1ZtFT2zd2l7t2qBh 29adkDbv0sAxRg5cmHhxz68N7z6tXDRz5gKfq1Z+XHbxz8evOx+tHfryutUvT/83Dh18893opUen blh7+vDr1ceX7z244JjD0b9fn5q7cf2qdZYbgObxV55/BPYn23768cdggAsOGKGC2SEIoXWY/XVg ghFu2KCB/6UlokuuZVjgg5w59t91JyrYX3srxghiZ/U1eCB8Ho7nYG41dmcijSf6OOGGPf6I4nzk /WYfW/j9mGOKCDI44Y4JPlmlhf91KKOEEKpnWYULXqgii1cOKWORYQap5nxU0ZTEiFaV6KCVU5bp 4p12drmmihzu6KGAelJopGc2bvlhmnO2qOGZWfq5ZaBULimpQu6x2Wd8yElHXqZIdvrdmssJGimM iZ73aafhkbqdc6hCiV2j7rFOFyikrH63XZKDTipXTE/hJpyS9vmq668EwWksSnOZapqyw0bXrFTC PvsUr9JWay1px2ar1rXcduuWtuC6FC1T475VbrkIoSuWugWFC2dAACH5BAAjAGkALAAAoACgARUA Bwj/AP8JHEiwYEEAAOwpXMiwocOHECNCRCixosWLGC1SzNhwI8eKHj+KHDkxIcmHBlOqXMmypcuX MGPKjBnypE17HmvWvMnz4s6MP20G7dnR5M2hI2cqXcq0aVOSSIlqNBpVqlWHVSNm5biVZ1eJX6+K HUvWIVOEaBeipZoWZ9uNcN+2VZt2rcm4OuXipag3Z9+7gBnapes35GCFawkDnos48GG3cd1Kftx4 b1GclQNDZlt4sUmnoEOLHi0zsmmjl08L1tyYbmu+qF3Lht16MuvXjm9HXi0Za27cwHsHV227+O7a vQ3X/X08eG2KpKNLny4Qau7EeZfj3qt8dkLYeXkX/0/+XfPg3YnFc9982Tb287rnEqdNP7538Zvr p4fPPXbZi/H8JyBXv+FH3oHsBeXXcIx1N9585TGYWXu0kedghbLdp9h9p9kVoXDCNbcgb+FZ+OGA KKZoFXEZHijiie25iJqDz30IoYzI7XRjiywiVyOJ5tkY5I8ZvtjieBo6p+KSKp6VXn4TQgnlk5RB huOTG7KHIHidCXnklu9l12VmXnIY5IjoxdZXjFN65qaWUFIn55x0GsTknUD5h1FYePbpZ0R1Bipo dH8WyiaBhiaqaEWDNtroopBGKumklFaaIlOWZqrpppxe5OinTnUq6khb8QmWmjPquaKqY5kKKKiw zv9EKqt/unrqlz2VeOhRqBrom0gjzoroSbTFaixMo4JEq3UDlrrsR7qCSFSwwD7rK7QRHqstS/xl ueZkq8kn14OMaYmlufvFpx94Wbq27pnllYtumiamOm6Ej1EWZme+cRllgva5p9q2dTKLoJnbpSph fdL+ilSFECssIblAUozhwSDeGLF68eJbII07+ogmjBfjaJy1yXJVEpGHbazjddqt22/JZIKp68YC d8fwyRwbqHGZPy4YcogwK3dcj+eavHPKXrFK79MF9ixmuhfCGDS8MeJMM5na8Zxkxh97LHLULgds 8kPvIdyu2ksz7WlKALQE9dVK0k1hr2pLzdrL7g4aORS9XhM59sJAn1324HZrdSLSVg+9EMF0BgQA IfkEACMAaQAsAAC0AKABFQAHCP8A/wkcKBAAwYMFAdizB0AhQ4UNF0Z8SJHixIUSHUa8iHEix4oZ Q36suFGjQ5AdT5YMafEkxpQsPUKc+VJmTZc2c9JEqRNmT54qTaJ86TOoSJw7YbZkSRSh06dQo0qd StUp0aFXSQp92HBr1603Y34Vm3HkV5Muua4EOZLrUq1lP9qEK3Ot3K5xU+Kty/EsU7to7+7ki/Qi XrV6B6f16/dt1seQI0ueTHkywYZVKxNtq7mz58+b04IeTbq06dGcT6uOnHph1dewY8se2HH149a2 c1fGrbu379VjfwtnOry4ad7Gkytfzry58+fQo0ufTr269evYs3eezb279+/gw4uEH0++vPnzUBOp V4++vfv38OPLn0+/Pvz1+Nfb38+/v///AAYoH34CFmjggQgmqOCCDDbo4IMQRijhhARpZ+GFGGao 4YYcdujhhyCGKOKIJJZo4onXUajiiuLhwOKLMMYo44w01mjjjTjmqOOOPPbo449ABinkkEQWaeSR SCap5JJM5hgQACH5BAAjAGkALAAAyACgARUABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWL GDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQO0JHUq0qNGjSJMq Xcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cONeBUq3rt27eCPK3cu3 r9+/gNvmHUy4sOHDiBMrXsz4YODHkCNLnky5suXLmDNr3sy5s+fPmina+0CaNFnTRlEL/ZC1sevX dqmqHj129tDSt0Hr3s0bLMXZrFWbHj46+GrcxYuzVm4bOW3mx6MnVy4UtvXrim1PT146OG7Uw8Ev P9dOG/z08NLR08bOvn1M2cuJCvd+O7747fdTR6d/nn7+3gAGKGBT2s2Hn33d8dffUeMZl2CD3CEY 34AUVhhZQAAh+QQAIwBpACwAANwAoAEVAAcI/wDtCRxIsGDBDx8MIhy4cKFAh/YQSkwI0SFEggkj UtQ48SHFjwwvGhxJsqTJkyhTqlzJsqXLlzBjypxJs2bMiyA9agzJE2PGnUAPhszpc6JIkTaTKl3K tKnTp1Cj0sQJVGLQij+JWvyJcejVnhV1Ng0htazZs2jTql1q1GvDrFw7XoXLNaJPjzgz5q27tq/f v4ADl/1HuLDhw4cFQ0XMuLHjx5AjS55MGQAAypgza97MubPnz6BDI1b8VLTp06Ito17NurXr17BJ y55Nu7Zi2Lgf297Nu7fv38CDA7YsvHhS4mWRG/9tuXlJ5SmbQ18pHYDN6QOxR5dO3bp2g9yPW/8X D378c+7fy3dHb355b+Tf06uPKR9m/Pbd6eM/v7R+S/8jQQegPQNmZ16B7v0F33jhsUegQA3ityCB 4RlY3oLOOUehhhgyyKGGG7Y3XXUUQujdicRNSFCHHppoonLspRijgSy+KCKKI95oI404luihgAdW GOGDJIKY4EmcTahkkDK6SGKJPrZo4YotqthklFBemeWJATqIJZYwSjnlkk5WqaOLW6ZJZkFXApkh l1+iGSKbQY4Jp4xttpjbnqO99GR1cEKZZoh3FkolnWWimWeUXhLa46F2qhnonIgOGmGMYlqJ46LY LTplmY0K6maYkQIqqpQIHslSjpWeKmeiXwK6WamnnE7qKp2ylmqmoJRCqqmKVGqpKa+Sqgcsr1q+ SqqidTJL7LLHqjpSkhJW+2m0tSprbay7grktsZ8i222TrM4H7LLGNrumrulqe2i5ckLbbLGQWmod n/gSZt9+fyZ7aZhvvkrojvYOvOWHP+JZLcI1Yhjujufe+CbABQ/867tiWpxwwi+KC6K8NgY6rLQk S5Vqf/uddHLJLLfsMnl+pbryyzSrylnNOOdcXL48h6bzz0Db1vPQ/wQEACH5BAAjAGkALAAA8ACg ARUABwj/AP8JHEiwYEF7CBMqXMiwocOHECNKnEixosWLGDNq3Mixo0eHBkOKHEmypMmTKFMO/Miy pUuPAAAwjPmypkSaNnPaw9mQJ0WVQIMKDaoxptGHPm8alVn0qE6MSZEyTYhz6VSrO6/KxDqR59SN UZ/C/Or1q8OwYtNOHFrVLFW3UlmiVXsWbk+zbRHSTFo2q167C50CrjiX7kWffSPyHMq4sWOBTf/+ bbt362SmfDFvXRo3q1PPmvNu/szZb+jTl99+9ivZNF6trGNL3ZvaNevSskFfPq01r2vSgoGv5sxV t3HDyF2K1hybOHOuy1vPZG77rWTn15+vrn57s/Tm2oNb/08McbR325Vzq8/Ovnp69+dbv0cMO/f7 5PjllrYaPzHl+eeh5dt93YHXHoFYlYWdbAo22N+DCuG202SgpWfhcK8dFR18BW64W4Bk1fdffPmV CNZrgdVXYIQgrjidfCR6uOF9MqLIoIov9kUeUuNlCB1wLB7Y4oxDhpjid/4VaeKSkQXppIH2Kckd jO1RmWSHIkLoJH3W1WWgb4pFqB6Y0nHJIZFYVhklklmmyeSbhLn1Y4zBCQfgjXcat19vDbJZ526A bukjn7xRRFagAwKZoobawejginvWmVmLFVII56WYljfYWEwWlqlim34q6qikfhRqR56qlWqp37Hq 6qsIDf8F66y01jrqY7jmqpKtvPbq66/AprVqqcPWdeqTUB0b7KLKKWuos8uCJNSOvBb74npeWssm touuqq2lLG7XWbPdkqjUQrqmq66u1Nr6bZeHQYssvOOKJS6Z9eo3r7VJrevvv0E5Z+d0/wEqKZ+I UhfocRIyWmltF0qqGpeRGtntdd31GWRm7KHmGcSW0cZwwz7WplteAKes8khXkmlmnnn2KKSgR4aF 5sZ0ukkxjhNTV9mFauJ85G9SLvdz0SGKZ6WROK3s9NMtF3fjzBxWmijHGR89NMzYJbngzhMTfDSN 5mld86BlJsiblhVS2jOUCH729NwoNenmtUvnfabP290gTPLM0YGJNdhh37Vm0Me1bTG8g9sIZZcC ahn3u9EiFBAAIfkEACMAaQAsAAAEAaABFQAHCP8A7QkcSLBgQQAABiIUuHChQXsOGSaEmNChxYoT G2bEKFFixI4UQ4pE+PHiSI4hNYIUqXAjQZUtP75E2bKmTIolSZKceXAiS5AyIwr1CZQoz6Edc958 yLSp06dQo0ol+K+q1atYsSJNabSmV5gmw7o0ufIrypw8uSYdyxFtWrQ3l6pNO9eg259BfeYty3Kr WaYwT+JFmbWw4cOIEytezPjfVLtgN+6ceZGs2Mk4I3t9K1nj3rmVVXoO3Zlo5cw9MeukSRo13btl V/fVOZty65hDO+MW/Li379/Agwsf/vOxXOLIkytfzry58+fQo0tvfvxp9enYs2vfzr279+/gw4v/ H0++vPnz6NOrX8++vXumjbEiv/6eO32+0O9Pj8+/v///AAYoIGOy/aafcQdqd2Bgcsmm34IOduXd gBRWaOGF/wFHVm8JSoWZeR3W9hBsTnXoV30opujUf2KtBZFHGKkmY2iQzbZTQzDullmMOhZIm01t xSikUW79iBptOLq2UoGu4RihhI9hKOWUVF6oIVtrBcYbkJz1xNtogrUYJpZ1cSmaXi7hFqSLmxm5 JJpsgmkZlCrWKR2LP4o5WFE3TrYakWeRueOQgWbZJ5tHrbkVbKNpeSKTixIq4oa/VWnppZhS+RmD ppFJY4N/jrkZX3MWp6eah0ZKV5l7vulqUabCirllpZnWauulV3pZV5GFcjkinHp+9herpw7LaWyd xvqarH4Vq2qZZ7Jq57T5dRWhbV8iOeNdrSnVbZrf8qnrnL3CGKif6NK0Y5vgamusutFqSe28K/o3 bYj0Uovvrfz26+9VKrqZ78AlAvfvwQgnrPDCDDN2TcMQRyyxYgRXbPHFGGes8cYcd8xeQAAh+QQA IwBpACwAABgBoAEVAAcI3QDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJ sqTJgzBOqiT4r6XLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp16c6XV q1izat3KtavXr2DDih1LlizVs2jTql3Ltq3bt3Djyp1Lt27dsnjz6t3LN6/dv0c5AR5MuLDhw4gT K14st6/jx5AjS77IuLLly5gJT97MubPnz6BDix5NWmLm06hTq17NurXr17Bjy55Nu7bt27hz697N u7fv38CDrw0IACH5BAAjAGkALAAALAGgARUABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWL GDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGNetEezps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMq Xcq0qVOeMqOmfCC1qtWrWLNq3cq1q9evE5+KHUu2rNmzaNPeBOtRrdu3cOPKnUu3rlqKOvPlK6rX rtG+fnHq3Ut0cN69gAPTTKzYHtuY9gYDZhyUslzLPTHb1eyTc2TEhBt7nvsYJmPQfEPTHS1YtWLW h3n2hf2W9tvSL09//hxack3fk10HX+x7N/HdrnkTN8w7MXDClpk3h94bNfXg0ZlLph755vPf1oWD /+Z+vbr51t2bH1cP/vxy996LzwaMW+Pf5NpRI1c9H/1+8MbtR9lk6wXYH4DZLWagfgIyaFyCC7Jn 03DHHdhehYYNRyCBE2ZInn4cHggiiPEhSGFjKMqGX3UPOlhcif9haGJOA7IoY3vJBRihcwyexh2M POrYYYH91TjjehYKCSCS4RV4I5NKEtljjimeRRGEDSYpXWsnWphkhzbuyB9n+R0Zo47brShllC3O aOSTaS53IYzThSffneVh59+ZfdXXkm5BvvneYV1OySaUa/romZeGBrlkbGJCGqiDkTo55KNrDvmm j2wKyqhjfq4EKIvOoUnpo5PKidmPjp7pqoJ8jnFoKKr+pUojq0WKZ2ap5FnaapMKaghnep4aGupK 02X64ndRKsojsFyC+Z55I0Y77YVa5rcqtT/u6eGrcZr67JyXDtris3qaqxyXhYJ6LEpw2VblvGPJ S69Y71Z0b7n79nuWvf4GvC9eAhdsML75JqxRQAAh+QQAv95pACwAAEABoAEVAAcI/wD/CRxIsGBB ewgTKlzIsKHDhxAjSpxIsaLFixgzaoRosKPHjyBDihxJsqTJkyhTqvy3saXLlzBjypz5cqXNmzhz 6tzJk2G+fDSDCm34cyhRoEaTKuTJtKnTp1BH2iuKkKpCqzOpWsX6kqtEr2B/is2oFalFr1nNLqQa ta3bt1E3blWr9CrdtBfD+jSLNmLZuhj79gVMuLBhiyrFFl38dypaxVWRlmXseCzlsZEhr53Mma9l yaD32s38F3NCxXRRV46c+fRjzXMr67UHt7bt2yjleg5Neepm1qXVNna8mnjs0b6JswYuHOhx5Mxd F+f6evllycpTe1ae/e7yw+DDi/+X+fy6w8awm3/vbXw79PXbsWr+Ll167Of06wfnzh86++G/jSfg gAR+5V57rW02H37D/efcga4deF9z2olmX3wQ9mcdb6DtZiGCG57nXYEklgheeQ++p2F6yE14YX0W osjffA/Jl2J0+VXX3Yzq+XfjjiYGKWSBMi6WI1872ggfd72ZVlWISyqJ35JM/kidd+ilyNuRL043 4mBDhimmS5916WSEoXXnoJbulamgXR3O1WSacDqpWpV7VZhkhxEeZZqbxak45qAQDTOeSoQamOii LuHm6KOQCsQoTHdOaumlmA4a6aacdurpp6CGKuqopJZq6qmovpXpqqy26uqrsMYfKuustNKU6q24 5qrrrm3V6uuvwAYbEa/EFmvssccGBAAh+QQAHgBpACwAAAAAoAFcAQcI/wD/CRxI8N+zgggTKlzI sKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypx50Z7Nmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3K1einqpO6ih1LtqxZewfOqi1Ks63bt3AV lopLt67du3jz6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS55MubLlkWsza97MubPnz6BDixb6 bbTp01wvq17NGiZqpvFey55Ne3br27hz697Nu7fL2sCDCx9u27fx4xs1IF/OvPle4tCjS59Ovbr1 69iza9/Ovbv37+DDi/8X6ry8+fPo06tfOb69+/da18ufrxe+/fv4ldLfz/9t/v8ABijggAQG2N+B CP5W4IIMNujggxB2luCEFFZo4YV5Rajhhhx26OGHIIYoImcYlmjiRCOmqOKKLLZI24kwxqiQizTW aOONOE4l44489ujjj0AGqV6ORBZp5JFIJqmkiEI26eSTUKq25JQjRmnllVhm+ReVXHbp5Zdghikm WVqW6duYaKap5ppstomkmXDq5uac4cVp55145qnnnnz26eefgLJG56DdBSoQIIYCRuii2SXq6KPq EQPpQ4xWaumlYk6q6aacduqpnpiGKtynpMYk6qkvlqoqS6i2itqqsKb/5OqsosVqa0m05qrrrgPe 6uuvwAYr7LDEFmvsscgmyOuyzDbr7LPQRivttNTak+y1CVWrbVPYduvttwJtK+645JZrrmbgYnvu uj2ley278Obk7rz01mvvpPHma+29/PYLqb7x+hsswAQXbPDBzgqs8MJ7IuzwwxBHPCfDFFds8cXy SazxxpVi7PHHPnI8LcifiiwtySinbKHJLLecqcowxyzzzDTXbPPNOFvm8s489+yzfTn/+fOuQRdt 9NFIDzT00kyrmHSeTUctNYdP4zk1qlXfefXWtAIAANeMev012IR6janMYmedZdof7SPk0GbPSjIA nZJ9qdp4552h3Xz3/+3334CfrffghBf+buCIJ674z4Y37rhKi7P5OJSRrzm5kzBc7mTlamreJOeg hy46vJ6/PTqYpQd5OuqpO3ZM68iu/iXsIcveJe24X3ZC7rzTZPvvwEPV+/CtBz8l8cirBsGjxjfv PFHJl+jyNM1GH+MX1mef9fNvak8h90d6/z345Jdvfo7iT3j++uy3737i6cdP8x0LvW+/jf+kKP+B 9/fv///t2Z8AB0jAAsIKgAj0Dj0SyMAGMsiAEFzPXIbkwA5FkIIVzKAGN8jBRV3wg4HKAV2AQ4EO mjBNIFTPE1LInBO6kGMsjKEMZ4iRF9rwhjjMIZNoyMMe+rAgOgyivsB+eCYhGnFdROzNEZdYriTy hon3ceJuoAg0KVpxYFTM4smueBuJcUCLPWtGaLhIRluBMYBlTKMa18jGlpxxPG2szBvFE0fKzPGO DdwHB+s4GTz68Y/9mwEgB0nIQgqRj4gElGd8YEjs+ICRjbTOIyMpSUhScjqWvGR0JqnJn/TlkYlE USejU0cwSGaUqLxdKFfJSpylkjg8/IEsi2hCWdrylaix5Q8aREBd/qCVhZklMIeZrFgMBpejIiZi kBmcgAAAIfkEAB4AaQAsAAAAAKABXAEHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rc yFHhv48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrRoyo5IkypdyrSp 06dQo0qdSrWq1atYs2rd2tCo169gw4odS7as2bNo06pdy7atW7A0ThJ7S7eu3bdc8+rdy7ev37+A AwseTLiw4cOIEytezLix46tKHkueTLmy5cuYJ97dzLmz58+gQ4seTbq06dOil6hezbr1atSweWae Tbu27cSnbuvezbu379/AgwsfTry48ePIkytfzlx57OfQo0ufTr26derNs2sXfr279+9ut4v/H38b vPnz6L2SX8++cvr38OPfbE+/vv37+Mk/ys+/v///ADIn34AEFmjggQgmCBMrCjboIGkBRiihUg9W aOFzE2ao4YYEwcHhhyCGKOKIJJa41IUopiiaiSxmqOKLMMYo44wotmhjgF4dQ+OOPP5z449ABink kEQWaeSRSCap5JJMNilVj1BGCZSTVFZp5ZUMSanlllx26eWXYIYp5phklmnmmUVhqWZmaLbp5ptw ErjmnO7FaeedeOap55589ulnlHQG+tifhBZqKGwGHKrooow26uijkOIk6KSUVmrppZhCFOmmEGbq 6aeghirqqKSWehCnqKaq6qqsttqSqbA+/+XqrGvFauutuOaqq2609urrr8AGW+auxFYk7LFEFats RMg2O+Wy0EYrrbHOVmvttW1Nq+223BqE7bfghqtet9qKa+656M5H7rTptkvSuvDGq6u79IIkL7T1 5qvvvvyCe++yqiLQ78AEF9zvvwiLOke8BjfsMKsJRywxpQ9jO3GuFWesMaMX47rxxyD32fHIJJds cn8hH3tyqXE+k/LLH68s88wmwmzzzTjnfB3Noeo8K89ABy300EQXbTTLPrd69NJMN5f001BHLfXU IY9MRNNYZ631VFR37fXXYNO0tZphl202dmOnrTabZ7d9YDdxEjDa2nTXbffdeIfo9qF5K/+5t6F9 By64XmIx8ffhiLs0+OKMN+7443Ua9UPiF0IOJFoQQEB5gXxlbrlvbGW+OZ+ij65n6aZ7RxgEn9OW urAOPB3FsK3XbvvtSb6uO0xp7K447sAHL3yJvhdvfE4BDjJ8Qse7uTyIzUcv/avPVw/59GZar/32 3Hfv/ffghy9+VV6MTx/26Kcfkvn8qe8+9uzn9z6Y8ddf9Pz4G2+/ffn3r/v+AAygAAe4JP9tiYDk MV45nIfABkrMgF+5BQQJ5sDtTPCCGMyg6irIwQ568INLugQI/aLBEoJthMkx4YyYFgEU2k6FMAzb PmL4IBceh4Y4zKEOX+SBHYbldvcgng+jh0jEIurEhkhMovmMyMQmOnElShzOEw+UNgBY8YpMmqKB osgdLcqJi2AMo/C8+EUx8gZB2CCjGs9jxjZiao1w/JYbdxPHOlZrjngUlB33yMc++vGPgAykIAdJ SD/l0TaFTKQiy3bI2izykZCMpCQnSUktNdJ1lcwkAy+JGU168kycZNsnPxPKTo6SlKVMpSpXycFT uvKV5mLlZGBJSynJUjIBAQAh+QQAHgBpACwAAAAAoAFcAQcI/wDtCRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFixgzatzIsaPHjyBDihxJsqTJkygZ/lvJsqXLlzBjypxJs6bNmzhzxsnJs6fPn0CDCh1K tKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTqtWasq3bt3Djyp1Lt67d u3jz6t3Lt6/fv4ADCx5MuLDhw4gRr13MuLHjxzwTS55MubLly5gza0aMZ7Pnz6BDix5NurTp06hT 1+WnurXr17Bjy55NWy/k27hz6x5bu7fv3wJ3Cx9OXGaM4kCBK1/uGrnz59CjS59Ovbr169iza9/O vbv37+DDi/8fT768eezM06tfz769+/fw47M/T7++/fv48+vfz7+/UfkABriXfwQWaOCBCCao4IIM NujggxBGKGF1AlZooVwTZqjhTRd26OGHIIYo4ogkkrbhiSi6VOKKLLbo4osNpSjjjDTWaOONOOao 447Iwejjj0AGKSCPRBZp5JFIJqnkT0I26eSTUELkSZRUVunWkliCZ+WWXEomQJdghilmaFmWaeaZ aAY15prNpenmm3DGyR8/cjLI5p145qnnnnyqVuefgAYq6KCEJtXnoYgmquiijL71VQCFRvpSo5RW aumlmFIq6aacdoqbGKCGGipRmZaqkaioimHqqqy26uqrQXr/KitbsNYq0qy4WmXrrrz22leuwAYr rG6+FnvRsMgqZeyyzDbr7LNwJSvtf9BWa9C02Gar7bbcduutYz5KYu1hYB2S5AzfpqvupOO2u+67 8MYr77z0Jtuuu/Vye+++/Dqbr779BizwwAQXbPDBCCes8HL/brvwrg0/ZYqZie1SqikYmxJmxFNl zDG2GU/8sbQYj2wygg/bevLKLGeZcq0txyzzzDTXbPPNOOes884895zby7D6PCjQrwpt9NFIJ80U 0UK+wzTTSsvJZwRPRxT11VhTWLWpWXft9ddGby322GSXnRnYFJut9tpst30X2mW6LffcvcFt991o 0a333nz3/x0j3oAHLni6fus5uJGFJ674ZYcXufjjkEfeNyySl9j45Zg3VfnmnL+deY4eutH56JZ+ DjrpVJqOI+qpq+7667DHbnQeYrFu++245647Xtr28u/uscqeIvDEF6+Q8MMb/yLyKCrvfIsWu8j8 9K8/3yL1Glqvve7Yd+/99/ttbzn45LOUBth+LSI+51Cs7/770JYvP9rw1x/5/Hbar3/Aqex/J/4L 8p+FAJgVeAxHgBUioAIXyEDIIHBIDSTQAwMUQQlOcGwAuCB8MqjB93CwRepYk34AUEGWsOeDHUyh CqtWwv6s8IVAayF/YEjDhcnwhjjMoeZqyMMe+vCHCdShEKOzMoI6AfGISEyiEmUzxCbma4lQjOIF nUhFeUkRNlXM4rqu+BotetFbXGzTF8eIrTC2hoxolJYZ/ZRG7qzxjaVqoxvhaBo52vGOzKOjHjWF x89V4ym80NYeB0lIyfURKuz4SiEXychGDvKQ1nGkJCdpNkha8pKBoyRmMCkdTXrydpT7pChHScpS to2T0TGlYlDJylYmTZXkcqUsZ0nLLMLSMAEBACH5BAAeAGkALAAAAACgAVwBBwj/AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3MhRob2PIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHOe 7Mizp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1K1WdYMOKHUu2rNmzYV+hXcu2 rdu3cOPKnUsXrNe7ePPq3Ruxrt+/gAMLHky4sOHDiBMrHsy3sePHkK0unky5suXLNCNr3sy5s+fP /4qAHk26tOnTqFNDxMy6tevXiVXLnk0bKuzbuHPrNlu7t+/fQHcLH068OErgyJMrX868ufPn0KNL N2i8uvXr2LNr386d7fTv4Ed3/x9Pvjza8OjTq1/Pvr379/Djy5+/3rz9+/jz69/PPyf9/wB65UqA BBZo4IEI0tZLZCkk6OCDEAbY34RlnULhhRhmqKF3EXbo4IYghijiiCSWaOKJKBbn4YoHpujii3Ox KKOEMNZo44045ljZjDz26OOPQAYppFY6FmlkTEMmqeSSTDYJ2jFOPmakJUdWqVKUWGap5ZYWWenl lyJxKeaYZIoJ5plelqnmZmi26eabcJK45px01rlinHi6aOeed+Xpp4l8BrrVn4SKKOihiCaq6KKM YslHo0gVKumklFaqGKSYHmXpppx26ulZmYYq6pIljGrqh5+mquqqrB536qsatf8q66y0bgrrrRfV qutruPbqEAi+BjvRrsRiJuyxyCar7LIVFessZcweOAxkz1ar3xZbWKvtSklhG+2y3n6bLLZbiKuk X9huq649UpFrLrLhvhtsvJCWyuVh2a6rq7z89gupvgDH6O/ABBds8MEIxxfwwgw37PDDEEcs8cQU V2xxwqNarPHGHHfs8ccghywyYxiXbPLJKIM38sgpN7ryyzDHLPPMNGvb8s04o1rzxTkjuvPPQFfb s89BF220ZZHgN/TSTL93dMRNRy21yk9XbXWlU9d5dcNZ07k1w12HLfbYZEv09cJlp6322mKfHTDb cMctd8puAzy3k3Xre/fefFf/lfffgAcuOK99N3RE4YgnrvjijDfu+OM+ljvb4JRXbijkMlpeLOac d+7556CHLvroDGlu+umop+4f6aw3rvqsrbf4equxGzj77bgTV/vuvPe+XO7ABy/8377/N/zxyMdW /PLMN+/889BzlPz01FcfcvTtWS8p9uxp7/33oHKvHvh+im9+y+Snr/76tJ7PVxLuS5fE/EqxT978 AsefFf1O2e///wD8k/6+kzpuBNBLBoRd17gxwAY68IGYOuCXIPgcCVrwghjMoAY3yMHAUfCDIPxg B4ukgxGaEHfLmkUIIXjCGq1QOS2M4X70IcMa2pA8L8xhrzTWiJrpEDg3PNEPtn8TxCIKbohITKIS /+OMtBnxiXlb4uSgGCIpWpFoVNzQFVOTxS568Yt22eJpwIghMY6RjGhMoxpNYsa0aUBta4yjHNHY xjqWaY75saMe99g2Oa5DaXzsDB4BGchCnmuQ5LnFRwzJJkQ68pEnZKRmHFYISD5SkpGx5HhMpYiD afKTdgsKNjpSD0ya0jMzKQcoV2mrUwZlG66sICtn6axY2jJCtMylLnfJSzbeMi+9DGaqfknMAwUE ACH5BAAeAGkALAAAAACgAVwBBwj/AP8J/HdooMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo0eF 9kKGPCSypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3MmzZ0uSPoMKHUq0qFGar44qXcq0qdOnUKNK nUq1qtWrWLNq3RoSEtevYMOKHUu2rNmzaNOqXcvW6ce3cOPKnUu3rt27ePMKbMu3r9+/gAMLHtz2 CeGYehMrXsy4sePHkBsenky5suXLmDNrDhy5s+fPoEOLHk26tOnTqFPr3cy6tevXsGPLnk27tu3b LlXr3s27t++JuMuGCE486u/jyBm/Sc6cYfHn0Gk3n069uvXr2LNr3243uvfvm7mL/x9P/jf48+gP l1/Pvj3o9PDj83VPv779u/Lz69/Pvz/8+wAGKCBG/hVo4IEI2qZKggw26OCDEEYo4YQU+jTghRhm iFCFHHbo4YcghihifBqWaCKAI6bo34kstujiizDGGJqKNNZo44045qjjUTL2ONoQPgYp5JC+7Whk cEQmqWRkRzbp5JOTtXHeklRWuRqUWGap5ZZcdunll15aKeaYZJZp5ploplkkmGz2peabcMYp55x0 1mlmm3jmqeeefPaJmJ2AVunnoFwFaqiShCaK1aGMCqnoo5BGylqjlMoo6aVMVarpppx26umnoIYq 6qiklsoRpqgaZap2Dqzq6quwxv8q66y01mrrrXSBoyuulGqm66/gpNogfcDuyuubtv0q7LLMNuvs l8dGK+20LT5r7bXYFkXtttx2S5+IJGS7lrfkXimTMeKmq+615TIkQrvwxlvauvSKJO+9+Ob7Xr38 9puuvgBf5K+6ARds8MEIJ4zXwP8qbOUVDkcs8cQUV2zxxaMF4hDDHHeMKcYHe8wuyCSXTK3I1pqs 8sq2ovwsyzDHvKrLzsocL83N2gwvzjz3vOWLaOjM2yoL+Zyq0EgnfajRqCrt9NNxMi311FRXbfXV WGet9dZcRwj112CHLfbYZJdt9tlop81k13uq7fbbcMct99x01233P2znrffefPf/3fHdovot+OCE F2744YgnrvjiZnkjHeCgMu4k5JFLfiTlmGc+o+Wcd+45v5qHjlczom/4+emopy5s6ZWq7vrrQrEu ++xzwW777bj/TLuhlwGQO4gA+P67VuQFzx03ZbMW/PDMN+/8Vbvz/vz0uEcfKPUSWq/99hJh7/33 4IffN/d0is8g+einb5D57C+u/vvwx0/mYEu0bz+b8qN5//6D5+8/6/wLIN/+VyYB7oeACEygAlFk wPwsUFANlM8DMySOCdopghK0YJIwSCINEomDIKSaB0dothCih4QoFJsJp5TCHq0QPKWRRwtnKKsX foeGOBSaDb2TEeTl8IdADKIQuodIsh0a8XRAOCJYiFgiJTrxiU5kooagiBsTmUOIVLyNFLfIxS56 8VtZDOPLvshAMZpxdWS8zxllk8Y2ymuNcLxUCq/hwji6xo31seMd8cjHPqpPj4AMpCAHaSE/roeQ mDHkIRFpGd38QJGQdBEjGxnJSs5qkpWxJHcwyUksafKTruqkekCJHVGa8pSoTKUqV9lBUlqHlW5y 5Sth2RZShYNutKylLCWyiNPk8pcU2mV1gMmvBOROmNQJCAA7 ------=_NextPart_000_0007_01C6F30C.6AABF810-- From sntxjishptq@altexp.com Thu Oct 19 05:27:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaU8p-0004lU-3Y for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 05:24:43 -0400 Received: from [213.85.147.2] (helo=mail.amongthelakes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaTus-0004FE-V0 for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 05:10:20 -0400 Received: from 62.148.169.191 (HELO mail2.denit.net) by lists.ietf.org with esmtp (VL194YATS OE0K6) id CTG6D9-ITN422-84 for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 09:10:14 -0180 From: "Buddy Mcfarland" To: Subject: Weighty note. You should to read. Date: Thu, 19 Oct 2006 09:10:14 -0180 Message-ID: <01c6f35e$63718fe0$6c822ecf@sntxjishptq> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Thread-Index: Aca6QF9ELGEIOW61D6JDAOXCCGQ5SN== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 ------------------------------------ Company name: Texhoma Energy, Inc. Stock symbol: TXHE.PK Current price: 0.12 (up 50% this week) Expected price 10/20/2006: 0.52 ------------------------------------ The information mentioned herein has not been released to the general public and should be kept confidential until its scheduled announcement on Friday, October 20. I strongly suggest that you get in before then. HOUSTON, TEXAS--(MARKET WIRE)--October 20, 2006 -- Texhoma Energy, Inc. [TXHE] is pleased to announce Successful drilling results on the Clovely site. As mentioned in earlier updates we encountered two expansive gas pockets with a flow rate estimated at 900 MCF of gas per day. Today we are happy to report the discovery of an oil reservoir which has far exceeded our initial expectations. Recoverable reserves are estimated at 2mil barrels and plans are in place to start additional drilling in order to take advantage of this very fortunate situation. As always, we will keep our shareholders abreast of the latest happenings. With offices in Houston, Texhoma Energy Inc. is a junior international oil and gas company focused on acquiring, developing and producing oil and gas. The Company is currently active in the southern United States. The Company's principal geographic area of focus lies in the wider Gulf of Mexico petroleum basin, which includes onshore and in-shore opportunities. The Company participates in a selected number of oil and gas ventures through judgment by a small team of experienced professionals. Recently these experts have had a string of successes which will be reflected in upcoming revenue reports. Revenue from production is estimated to be worth $120mil. With 177mil shrs outstanding this gives us a book value of 0.67 This is a great opportunity for you to make the market work for you. After 10/20/2006 the price will increase significantly. From umfukkdicdpc@amo-rs.com.br Thu Oct 19 09:32:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY0b-0000TL-U1 for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 09:32:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaY0b-0005eq-Rs for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 09:32:29 -0400 Received: from e177150068.adsl.alicedsl.de ([85.177.150.68] helo=gigabyte) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaY0V-0007Mn-3f for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 09:32:29 -0400 Received: from 200.213.46.32 (HELO ns.amo-rs.com.br) by lists.ietf.org with esmtp (MFCYA8VR766 V23JPS) id 8PEKYN-7RS1C5-8H for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 13:32:32 -0060 From: "Jodie Godfrey" To: Subject: Significant message. You have to read. Date: Thu, 19 Oct 2006 13:32:32 -0060 Message-ID: <01c6f383$07c7ae70$6c822ecf@umfukkdicdpc> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 Thread-Index: Aca6QJ9HC6XDZ0P4F4UYTPO1LWEHGU== X-Spam-Score: 1.8 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 ------------------------------------ Company name: Texhoma Energy, Inc. Stock symbol: TXHE.PK Current price: 0.12 (up 50% this week) Expected price 10/20/2006: 0.52 ------------------------------------ The information mentioned herein has not been released to the general public and should be kept confidential until its scheduled announcement on Friday, October 20. I strongly suggest that you get in before then. HOUSTON, TEXAS--(MARKET WIRE)--October 20, 2006 -- Texhoma Energy, Inc. [TXHE] is pleased to announce Successful drilling results on the Clovely site. As mentioned in earlier updates we encountered two expansive gas pockets with a flow rate estimated at 900 MCF of gas per day. Today we are happy to report the discovery of an oil reservoir which has far exceeded our initial expectations. Recoverable reserves are estimated at 2mil barrels and plans are in place to start additional drilling in order to take advantage of this very fortunate situation. As always, we will keep our shareholders abreast of the latest happenings. With offices in Houston, Texhoma Energy Inc. is a junior international oil and gas company focused on acquiring, developing and producing oil and gas. The Company is currently active in the southern United States. The Company's principal geographic area of focus lies in the wider Gulf of Mexico petroleum basin, which includes onshore and in-shore opportunities. The Company participates in a selected number of oil and gas ventures through judgment by a small team of experienced professionals. Recently these experts have had a string of successes which will be reflected in upcoming revenue reports. Revenue from production is estimated to be worth $120mil. With 177mil shrs outstanding this gives us a book value of 0.67 This is a great opportunity for you to make the market work for you. After 10/20/2006 the price will increase significantly. From qprtpjscxx@txtreasures.com Thu Oct 19 10:13:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYeF-0002uU-AG for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 10:13:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYeF-0004t3-8V for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 10:13:27 -0400 Received: from e181053128.adsl.alicedsl.de ([85.181.53.128] helo=e181029211.adsl.alicedsl.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaYeB-0000Fr-Os for avt-archive@lists.ietf.org; Thu, 19 Oct 2006 10:13:25 -0400 Message-ID: <000e01c6f388$b36859a0$d31db555@pcggrv616g> From: "custom" To: avt-archive@lists.ietf.org Subject: gallery Date: Thu, 19 Oct 2006 16:13:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a An Investor ALERT is being issued starting right N0W. Keep your eyes glued on P.S.U.D!! PETROSUN DRILLING (P.S.U.D.) Current Price: 1.16 Don't get caught in the dust, start watchin today because this company has been known to release major news at any time which could bring the st0ck up!! Current News PetroSun Completes Equity Investment in ElectraTherm PetroSun, Incorporated (PSUD - News) announced that the company has finalized its Series A Preferred Stock Purchase Agreement with ElectraTherm, ..... Check your stock source for full press releases on this exciting stock! Don't miss out ! creations every occasion birthday parties weddings baby showers thank notes draperies pajamas Each item handmade only Mother could give. Stuff Support Copyright Empire. All rights reserved. Craft is our pick. It allows you to design edit kinds of graphics required in software cycle files archives folders local disks Internet customize Perfect any graphic PNG JPEG BMP TIFF WMF just seconds. Create stylish XP. scan files archives folders local disks Internet customize Perfect any graphic PNG From avt-bounces@ietf.org Thu Oct 19 10:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZ9I-0000Pe-3I; Thu, 19 Oct 2006 10:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZ9G-0000Ll-8V for avt@ietf.org; Thu, 19 Oct 2006 10:45:30 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZ5r-0002CO-Nm for avt@ietf.org; Thu, 19 Oct 2006 10:42:03 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:58847) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1GaZ5r-00051i-6q; Thu, 19 Oct 2006 15:41:59 +0100 In-Reply-To: <44073054.5050505@gentoo.org> References: <44073054.5050505@gentoo.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] rtp-vorbis and rtp-theora available Date: Thu, 19 Oct 2006 15:41:54 +0100 To: Luca Barbato X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Luca, [Apologies for the extremely slow response] On 2 Mar 2006, at 17:50, Luca Barbato wrote: > The new drafts are available in the ftp > > http://www.ietf.org/internet-drafts/draft-barbato-avt-rtp- > theora-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vorbis-00.txt > > I tried to address most of the issue risen in the last meeting and > overall clean up wording and format. > > Please review and comment on this new revision I think these drafts are on the right lines, and I would encourage the Vorbis and Theora communities to work to complete them. I believe both drafts could be ready for RFC publication with only relatively minor revisions. Regarding the Vorbis draft, since that seems to be the most advanced, I think the basic technical approach is solid. I have a number of detailed comments on a mix of technical and editorial issues: - Abstract: it is preferable to avoid the term MIME, since the media type registry is not used exclusively for email. I suggest rewording the second paragraph: "Also included within this memo are media type registrations, and the details necessary for the use of Vorbis with the Session Description Protocol (SDP)." - Section 2.2: an explicit statement that each RTP packet can only contain a single type of Vorbis payload would be useful for clarity. - Section 2.3: clarify that the "length" field is in network byte order, and is in units of bytes. Similarly, clarify the byte order for the "Ident" field. - Section 3.1.1 states that "A Vorbis Packed Configuration is indicated with the payload type field set to 1". Should it be the "Vorbis Data Type" that is set to 1? The current text could be confused with the RTP payload type. - Section 3.2.1.1: the media type registration should be moved to section 6 with the other IANA considerations, otherwise it might be missed. Also, please update the registration template following RFC 4288 section 10. - Section 3.3: I'm unclear what is meant by the last paragraph of this section. Is the intent that an RTCP packet is sent early, rather than following the usual RTCP timing rules? If so, a reference to RFC 4585 must be made and the RTP/AVPF profile negotiated during session setup. If the intent is that the standard RTCP rules are followed, then I recommend removing the text about RTCP here, since it confuses. - Section 4: should this be "Vorbis Data Type" rather than "payload type"? [same issue as section 3.1.1] - Section 5.2: I have similar concerns about RTCP use as with section 3.3 of the draft. In particular, if normal RTCP rules are followed, implosion will be avoided, so the need to explicitly warn against this leads to concern that the RTCP packets are sent early, ignoring the RTCP timing rules in RFC 3550 and/or RFC 4585. - Section 6: the clock rate ("rate") must be listed as a required parameter. You might also list "channels" as an optional parameter. - Sections 6.1 and 6.2 should be moved out of IANA considerations, and into a separate section. The IANA has started to complain if this section contains things other than parameter registrations. - Section 6.1.1: there is a typo at the end of the first paragraph. - Section 6.1.1: clarify that the a=fmtp: line has been folded to fit the memo, but would be a single long line in the SDP message. - References: is reference 16 used? Regards, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 19 15:31:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadaT-0006ip-G0; Thu, 19 Oct 2006 15:29:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadaS-0006eA-7k for avt@ietf.org; Thu, 19 Oct 2006 15:29:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadaQ-00051r-U5 for avt@ietf.org; Thu, 19 Oct 2006 15:29:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2006 15:29:49 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JJTmta031014 for ; Thu, 19 Oct 2006 15:29:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JJTmYJ029650 for ; Thu, 19 Oct 2006 15:29:48 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:29:48 -0400 Received: from [161.44.55.227] ([161.44.55.227]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:29:47 -0400 Message-ID: <4537D22B.1090205@cisco.com> Date: Thu, 19 Oct 2006 15:29:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 19:29:48.0003 (UTC) FILETIME=[F06DD330:01C6F3B4] DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1161286188; x=1162150188; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20Tutorial=20during=20IETF=2067!=20[DO=20NOT=20REPLY] |To:avt@ietf.org; X=v=3Dcisco.com=3B=20h=3DIVH9amnYVaV4pfzKKjl/WmQt0Lg=3D; b=YeiSw34x63ghIJv3bjbTlJc7g5ExPVnAWxfacRwGDvgaClrkxm+SUjnrqcoTiY37avLXmVgz StixLLDvDAdmROtru8S5tp3C6MwCFdAyEbiYnD5eXWC4Tv2SSY41jMEr; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [AVT] ICE Tutorial during IETF 67! [DO NOT REPLY] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt) WHEN: Tuesday, November 7 1130-1300 (lunch logistics are in progress and will be announced ASAP) WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 19 15:40:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadkF-0004D0-8p; Thu, 19 Oct 2006 15:39:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadUe-0005Na-6P; Thu, 19 Oct 2006 15:23:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadUc-0003xD-RP; Thu, 19 Oct 2006 15:23:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 12:23:51 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JJNotj004329; Thu, 19 Oct 2006 15:23:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JJNlYP028366; Thu, 19 Oct 2006 15:23:50 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:23:49 -0400 Received: from [161.44.55.227] ([161.44.55.227]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:23:48 -0400 Message-ID: <4537D0C4.5020105@cisco.com> Date: Thu, 19 Oct 2006 15:23:48 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org, ecrit@ietf.org, enum@ietf.org, geopriv@ietf.org, ieprep@ietf.org, iptel@ietf.org, mmusic@ietf.org, sigtran@ietf.org, simple@ietf.org, sip@ietf.org, sipping@ietf.org, speechsc@ietf.org, speermint@ietf.org, xcon@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 19:23:48.0914 (UTC) FILETIME=[1A653120:01C6F3B4] DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1161285830; x=1162149830; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20Tutorial=20during=20IETF=2067!=20[DO=20NOT=20REPLY] |To:avt@ietf.org, =20ecrit@ietf.org, =20enum@ietf.org, =20geopriv@ietf.org, =0A= 20=20=20=20=20=20=20=20ieprep@ietf.org, =20iptel@ietf.org, =20mmusic@ietf.org , =20sigtran@ietf.org, =0A=20=20=20=20=20=20=20=20simple@ietf.org, =20sip@ietf .org, =20sipping@ietf.org, =20speechsc@ietf.org, =0A=20=20=20=20=20=20=20=20sp eermint@ietf.org,=20xcon@ietf.org; X=v=3Dcisco.com=3B=20h=3DIVH9amnYVaV4pfzKKjl/WmQt0Lg=3D; b=KrOzK3fR06ATri/gT7YJZroJcol7TSpMYe5BZE33gFcC/1PSyZC+oxmWK+oIC+fJQIbVoFL+ nf48uscnxvpV77HTZ0nnFeZmJMX4MuuOimxi0aG7+C8ixmvrHWsG0fmT; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.2 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 19 Oct 2006 15:39:57 -0400 Cc: Subject: [AVT] ICE Tutorial during IETF 67! [DO NOT REPLY] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt) WHEN: Tuesday, November 7 1130-1300 (lunch logistics are in progress and will be announced ASAP) WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 19 16:04:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae6u-0007Ij-Vp; Thu, 19 Oct 2006 16:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae6N-0006vE-21; Thu, 19 Oct 2006 16:02:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaduT-0007jF-VX; Thu, 19 Oct 2006 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaduT-00039B-FY; Thu, 19 Oct 2006 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2995E175EF; Thu, 19 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gadty-0001D0-MP; Thu, 19 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 19 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : A general mechanism for RTP Header Extensions Author(s) : D. Singer Filename : draft-ietf-avt-rtp-hdrext-06.txt Pages : 17 Date : 2006-10-19 This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and unregistered. The actual extensions in use in a session are signaled in the setup information for that session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-hdrext-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-19124731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-hdrext-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19124731.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 19 16:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae7L-00084s-8Y; Thu, 19 Oct 2006 16:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae6O-0006yh-QY; Thu, 19 Oct 2006 16:02:52 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gadty-0007fv-Vr; Thu, 19 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id CCB1C3289E; Thu, 19 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gadty-0001Cx-Ll; Thu, 19 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 19 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-toffset-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Transmission Time offsets in RTP streams Author(s) : H. Desineni, D. Singer Filename : draft-ietf-avt-rtp-toffset-02.txt Pages : 15 Date : 2006-10-19 This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-toffset-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-toffset-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-19124527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-toffset-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-toffset-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19124527.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 19 16:04:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae7d-0008TF-FJ; Thu, 19 Oct 2006 16:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gae6P-0006yC-2b; Thu, 19 Oct 2006 16:02:53 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gadty-0007fo-TB; Thu, 19 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D592F26E46; Thu, 19 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gadty-0001D3-Mz; Thu, 19 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 19 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-smpte-rtp-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Associating Time-codes with RTP streams Author(s) : D. Singer Filename : draft-ietf-avt-smpte-rtp-05.txt Pages : 20 Date : 2006-10-19 This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams, in a way that is independent of the RTP payload format of the media stream itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-smpte-rtp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-smpte-rtp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-19124855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-smpte-rtp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-smpte-rtp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19124855.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From genovese@00map.com Thu Oct 19 18:37:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GagPT-0002m8-FU; Thu, 19 Oct 2006 18:30:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GagKC-00067B-P9; Thu, 19 Oct 2006 18:25:16 -0400 Received: from 63-227-13-66.hlrn.qwest.net ([63.227.13.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GagKA-00038e-1j; Thu, 19 Oct 2006 18:25:16 -0400 From: "Marla Villalobos" To: Subject: Work from home - high wages! Date: Thu, 19 Nov 2006 22:25:16 +0420 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Flower land International inc. is looking for qualified candidates. ----------------------------------------------------------------- The Company: FlowerLand International is an american trading company. Our core values are: -To provide excellent customer service -To offer top quality products -To create and innovate The Vacancy: The company has an opportunity for talented, highly creative persons. We are looking for someone who is energetic, ambitious and intelligent. We can employ people from all over the world. The successful candidate must possess the following skills and experience: - Excellent people skills. - Punctuality. - Skilfulness. Main Advantages: - Really High Wages. - Ability to work from home. - No sign up fees, no investment is needed. - All expenses (such as phone calls, webtraffic, etc) will be fully covered by our company. - AIDS\Disability Friendly team. Degree: No degree required. How to Apply: Please send your resume to our personnel manager via email FlowerIntl@web2mail.com It must be mailed in a TXT, Microsoft Word or RTF format. From feedback@0-0.com Thu Oct 19 18:52:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GagkK-0003eX-PY; Thu, 19 Oct 2006 18:52:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GagkK-0003M2-NZ; Thu, 19 Oct 2006 18:52:16 -0400 Received: from [189.153.91.38] (helo=barracuda.1-stopnet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GagkH-0003i6-E2; Thu, 19 Oct 2006 18:52:16 -0400 From: "Agustin Petersen" {SET:debug=51} To: Subject: Home-based vacancies. Flexible shedule, high wages. Date: Thu, 19 Nov 2006 22:52:07 +0360 MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Mailer: kzenkdrnre tabedv kgy srjkpgso g sacbflrg - 7.9 X-Spam-Score: 1.5 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Flower land International inc. is looking for qualified candidates. ----------------------------------------------------------------- The Company: FlowerLand International is an american trading company. Our core values are: -To provide excellent customer service -To offer top quality products -To create and innovate The Vacancy: The company has an opportunity for talented, highly creative persons. We are looking for someone who is energetic, ambitious and intelligent. We can employ people from all over the world. The successful candidate must possess the following skills and experience: - Excellent people skills. - Punctuality. - Skilfulness. Main Advantages: - Really High Wages. - Ability to work from home. - No sign up fees, no investment is needed. - All expenses (such as phone calls, webtraffic, etc) will be fully covered by our company. - AIDS\Disability Friendly team. Degree: No degree required. How to Apply: Please send your resume to our personnel manager via email FlowerIntl@web2mail.com It must be mailed in a TXT, Microsoft Word or RTF format. From avt-bounces@ietf.org Fri Oct 20 02:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaoDg-0008R4-GN; Fri, 20 Oct 2006 02:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaoDe-0008QM-CX; Fri, 20 Oct 2006 02:51:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaoDe-0004gZ-6D; Fri, 20 Oct 2006 02:51:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaoDd-0007aD-Sj; Fri, 20 Oct 2006 02:51:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E44C52ACCE; Fri, 20 Oct 2006 06:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaoCf-0004fh-LP; Fri, 20 Oct 2006 02:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Oct 2006 02:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-compact-bundled-evrc-11.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Enhancements to RTP Payload Formats for EVRC Family Codecs Author(s) : Q. Xie, R. Kapoor Filename : draft-ietf-avt-compact-bundled-evrc-11.txt Pages : 22 Date : 2006-10-19 This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B encoded speech transported via RTP. VoIP applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-compact-bundled-evrc-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-compact-bundled-evrc-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-compact-bundled-evrc-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-19203322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-compact-bundled-evrc-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-compact-bundled-evrc-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19203322.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 20 14:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gayds-0004yw-Vu; Fri, 20 Oct 2006 13:58:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaydr-0004yU-28 for avt@ietf.org; Fri, 20 Oct 2006 13:58:47 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaydp-0006Ks-Ji for avt@ietf.org; Fri, 20 Oct 2006 13:58:47 -0400 Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k9KHwi0Z016107 for ; Fri, 20 Oct 2006 10:58:44 -0700 (PDT) Received: from [17.202.35.52] (unknown [17.219.197.19]) by relay7.apple.com (Apple SCV relay) with ESMTP id 7FBAFE4 for ; Fri, 20 Oct 2006 10:58:44 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 20 Oct 2006 10:57:43 -0700 To: avt@ietf.org From: Dave Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [AVT] 3 to last-call - RTP header extensions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi folks the only adjustment here from the previous drafts is to use URIs to identify header extensions, rather than reversed domain names. URIs have the advantage that they might be de-referencable URLs, and indeed the draft now says that for RFCs, the extension name is the URL to the RFC. So the following two now say that, as well. I'm asking for last-call on these, as we've seen them a while, they are complete, and the discussion has died down. Re-start the discussion if you disagree! * * * * This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : A general mechanism for RTP Header Extensions Author(s) : D. Singer Filename : draft-ietf-avt-rtp-hdrext-06.txt Pages : 17 Date : 2006-10-19 This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and unregistered. The actual extensions in use in a session are signaled in the setup information for that session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt Title : Transmission Time offsets in RTP streams Author(s) : H. Desineni, D. Singer Filename : draft-ietf-avt-rtp-toffset-02.txt Pages : 15 Date : 2006-10-19 This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-02.txt Title : Associating Time-codes with RTP streams Author(s) : D. Singer Filename : draft-ietf-avt-smpte-rtp-05.txt Pages : 20 Date : 2006-10-19 This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams, in a way that is independent of the RTP payload format of the media stream itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-05.txt -- David Singer Apple Computer/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From ousd@alih.com Fri Oct 20 14:31:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaz99-0001MK-CH for avt-archive@lists.ietf.org; Fri, 20 Oct 2006 14:31:07 -0400 Received: from p5084eb1c.dip.t-dialin.net ([80.132.235.28] helo=pc) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaz92-0003Of-SF for avt-archive@lists.ietf.org; Fri, 20 Oct 2006 14:31:07 -0400 Received: from 193.246.253.15 (HELO mx2.cyberlink.ch) by lists.ietf.org with esmtp (A93DAEI45 936M) id E7VNPS-4YCGG6-5P for avt-archive@lists.ietf.org; Fri, 20 Oct 2006 18:30:51 -0060 From: "Sonja Hurt" To: Subject: Momentous note. You should to read. Date: Fri, 20 Oct 2006 18:30:51 -0060 Message-ID: <01c6f475$deca2ae0$6c822ecf@ousd> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca6QS3LQ2J340ZLUSRB5PLRIV10B6== X-Spam-Score: 3.6 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 The great anticipations are drawn up. The increase is up to 70% in the last three days. (MXXR) is the profitable deal and those who knows it is making money. The drilling achivements of this highly capable oil partnership exceeded all its expectations. One time this data hits the road there will be no stopping this one. nowadays it's around 0.025 but we are waiting it to triple. Once the press release is made and the PR gets into full swing. Don't waste time and miss out. We advise you to buy today. The key is getting in early and the time is pressing. It was said that Monday is the day this one will blast off. Take a position before that happens. From hescvqdxhk@quadium.net Fri Oct 20 17:18:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb1lB-0005ak-O9 for avt-archive@lists.ietf.org; Fri, 20 Oct 2006 17:18:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb1lB-0004kJ-Jy for avt-archive@lists.ietf.org; Fri, 20 Oct 2006 17:18:33 -0400 Received: from [58.185.8.130] (helo=[58.185.8.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gb1l5-00035m-0t for avt-archive@lists.ietf.org; Fri, 20 Oct 2006 17:18:31 -0400 Message-ID: <001001c6f48d$498c10c0$8208b93a@admin> From: "trying rush" To: avt-archive@lists.ietf.org Subject: card. Date: Sat, 21 Oct 2006 05:18:28 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C6F4D0.57AF50C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.7 (+) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 ------=_NextPart_000_000C_01C6F4D0.57AF50C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C6F4D0.57AF50C0" ------=_NextPart_001_000D_01C6F4D0.57AF50C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thumping variety give hours am appear of board Special in Tiles or = careful stuck strategic thinking fans demo challenge understand = difficult master rotate or pieces edges am match devious reaching button = is builtin walk spin. Price strategy eight in players bots is compete fictitious countries hex = grid army battles bot of brains different replaced. Silly Laughs am Animals texas holdem Dailyhaha Retarded wow Fresh = Badjocks Humping Frog Greeting Xposed Mucho or. Pages gtshowing games Domination Size kb Price strategy am eight players = bots compete fictitious countries hex grid army battles bot brains = different replaced assume role middle. Millions Media or whole film of = collection inch is square box scratched High Definition delicate renting = in card kiosk? License of Copyrights details of registered trademark a Wikimedia of = Foundation of ee ff fc is Action Arcade Puzzle is Logic Board in = Shooters am Casino am Sports Palm Pocketpc fa Brick or Shooter jr. Fishingoct ndcat single Studsep or qvc in Cock Upsep Bball Dance Offsep = in stcat jet Beachsep Guitar of Skills Ping Catch Shotsthe. Editor Wikipedia am continued donations Editorfrom navigation searchlook = refer toa person editorcopy editorthe Canadian program Editorsa. Solution teams concerned Webbased Combining multiple easeofuse features = of granular or detail simplifies processes ensure or required loadsfree = Kickstart movies Explore php. Edit upperleft tree of brown circle Nodes = item lower scroll Coordinate State Actions Stop a Save followed Cancel. Started rumour is around that could be taking Segas route next is few = years leaving hardware. Studies technical resources egl reduce complexity cost begin lessening = gap between Trial in download Architect design tool leverages am uml. ------=_NextPart_001_000D_01C6F4D0.57AF50C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thumping variety give hours am appear = of board=20 Special in Tiles or careful stuck strategic thinking fans demo challenge = understand difficult master rotate or pieces edges am match devious = reaching=20 button is builtin walk spin.
Price strategy eight in players bots is = compete=20 fictitious countries hex grid army battles bot of brains different=20 replaced.
Silly Laughs am Animals texas holdem Dailyhaha Retarded wow = Fresh=20 Badjocks Humping Frog Greeting Xposed Mucho or.
Pages gtshowing games = Domination Size kb Price strategy am eight players bots compete = fictitious=20 countries hex grid army battles bot brains different replaced assume = role=20 middle. Millions Media or whole film of collection inch is square box = scratched=20 High Definition delicate renting in card kiosk?
License of Copyrights = details=20 of registered trademark a Wikimedia of Foundation of ee ff fc is Action = Arcade=20 Puzzle is Logic Board in Shooters am Casino am Sports Palm Pocketpc fa = Brick or=20 Shooter jr.
3D""
Fishingoct ndcat single Studsep or qvc = in Cock=20 Upsep Bball Dance Offsep in stcat jet Beachsep Guitar of Skills Ping = Catch=20 Shotsthe.
Editor Wikipedia am continued donations Editorfrom = navigation=20 searchlook refer toa person editorcopy editorthe Canadian program=20 Editorsa.
Solution teams concerned Webbased Combining multiple = easeofuse=20 features of granular or detail simplifies processes ensure or required = loadsfree=20 Kickstart movies Explore php. Edit upperleft tree of brown circle Nodes = item=20 lower scroll Coordinate State Actions Stop a Save followed = Cancel.
Started=20 rumour is around that could be taking Segas route next is few years = leaving=20 hardware.
Studies technical resources egl reduce complexity cost = begin=20 lessening gap between Trial in download Architect design tool leverages = am=20 uml.
------=_NextPart_001_000D_01C6F4D0.57AF50C0-- ------=_NextPart_000_000C_01C6F4D0.57AF50C0 Content-Type: image/gif; name="bricks..gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c6f48d$498c10c0$8208b93a@admin> R0lGODlhVAL8AYf2AAABAHQAAAiCAHSOAAAKjIAAfwByfMu/x7jTzanJ8EUsAF8iC44sBZEgAMcU AOwjCAA9ABtOAERHAGJKAIQ5A6o8A8E4A9VHBQBlAC5XAk5SCWVtCHtYAJ9gAMtjAN5UDQx9ABNx AEB6A2yGCYqOAJl1CsWBANOBDgSZACSVCzqWA1SUAIySDqWsCcaZANeSCgC6ACvDAE22Dmi1AIW+ AKnOBLy1BdvKAADfCSbSAETgDFXpAIzXDqrcDcXhAdHhAwAISSYBPjoORlgHM4wDRaAJN8kARtUO RgASTCspQDcmQ24pP3otNqgfSMESSdMnOwM2OB0/MUc7PWE5SYlISaFEQsJOQO1KNQduQiptTUNt TF5SSntqCpdUOcFmMulpMg6CNyt9Mjl3OFGBO4R9MqV5Nct9NdmLRwCZTCCXQEifTGeiTY6dTpKY OsCVPuSsOQC4OxrAP0m1RGnGSnnLPaHER723SeS0QwDiSRvWSzbqNl7pR4PTRaPaQcntO+neOQAJ eCcAjToHhmcAiogAiqsDd8AAftkAdgAZeiYlfEYVeFQdh4EujJcrc8ESftgRegpIfRVEh0dHiVRC hItAcq48f7ZEee5HhAxSehJgjExdeVVefIRldZZYfr1thNlecQmBgS2NgjeAeF51hIKCiKp0criF fumLdgusjB6rhk6sgGaceYaTfJqqeLKWfuGshgOyfRLJfE67hV2+gYjKiKTAdbq/f9bIeADneiTU dUjejl7XgnnUdJbtdMnchOfRhAUHzR4KtUICx2EFyIYFy60AuMsCsdkAsgAfsiQRwE4mylkhunIn wJwWvrIqxd8nvAY7vB1KxUg5xVdCx4Q4s5FLtLo5s9lNwwBhyShjzDNft1liw31jvpFUubNlv9Fm tQGAuSaEwkd1yFaBtXp7wZaKvrSLzup9uQCrxRSkzj2SwV+Ws3SsvaanzbiYx9aRzQHNwBPAyDWz sWLGu4G5yJXCyP/t8pWtsnaIdv8ACAD/AP/xAAcA//cA8wz4//P+8yH5BADXui0ALAAAAABUAvwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKtPevpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evTxuB HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4MNqMhhN3Hcm4sePHkCNLVqi4 suXLmDNr3sy5s+fPoHd+CE26tFfEJT+oHv1vtevXrlWuPqkaJWuTsGHTvp16N2/erW3bjp1at27c tZHPVk6cee7RrF8Pz61cdvKUwGk7f76c9eTv4MOL/x9PvmLr38FZZkfO/rzw97hXXu/tvjj93ui1 x08Pf3f7/Pyp119wwK0XYH0IXjfffcJlB+B75UUo4YQUVjhQT+sZyOCA0QXo4IDx5VfgfgSSaGKH 2Mn2HoAamnggdDGNqN+LKar4oYs4mqZjZwa22KONHtaYY4khqsgfjBsGeWCSGSq5pJBJPmlklEhy KN+SD86445ac9XhclE8ieduNQ6JI5IpFMtkcdcYBSSJ1VlrXopPaNallnVDCOSeXfBI25mw+Xpni mEyCeF+Hdppp5olUQhlic1LeOeeCWjZpZ46EVipon5zCldGHgU6JJ31kgplplTNWiaqLqxY6KKMu yf8Y66Zh1npnccvBWqOFvPbq668T0hiqqOmhV6qUxm6YLH7Etmrrfiy+JGtLP0rKqqOH9jcnsNx2 6+23AvWA2HzODpngoghe22x0f/rnrraNYtcujZGqG6ejCs6brqu6IlsSuAAHLPB4PxEHJ5jVsVog ubSmm6u1cuYrnYYPg/olrrfiSimmGz/sG6DwbodupySnhVrJKA+s8sosg4TyyzDHvNfJMvPZ8s04 5xxZzTz/pPPPQAfc89A7BW300b4SrfRNSDftdHlLRz3T01RXHZkAKGF9ktYlcS3A12CDbVLYXafE ddZi/xP211tnrTbbY68tN9xux0223XebTffbdcf/jfbWe++t9tt5tz123zGdjTfhcgOOeNplG374 4P9YbfnlB/F0NtabH6445X57brbebSsOd+eRq4R66mV7/TfoLNF9uumvhy671oJzXvvgq3/uku6h s+4734bfLjzsuEutvEmIue666IjDPrnk01Mf+fOsP2498NJTPvz2rYPvfPbJd/65+ZJ/vxL33VsP /fV9j5+61pjXb/9FoHOPvvaqj+5+9uGT3vdWJ8D89U997dMdAXknOt8psHT9C+D7ZKK/360PeQmc nwEjd78OPq0n8sPg+f7HuMK1L4PsA2D1FljB0c0tegHEHvzKd0ANOnCCDKRJC2N3QQPe0IfTQ+Dy /2TWPA1usIDVcx/tuia2G0IuidRbW/xUmEL/ue15SwReFXPovQweUYWMs2LyWjI8LHpxjF3koAfX aDSfVHBzJlwgFJcIQReSj4dBRFvanGhBO8IvfTiUIA39J0USkvFuCCzj5LYYQvYJcYiQfMkbAQk+ K87xioRcIR6Pl8fuoXGTf5SgEdO4SAiOcJRgJGMne2hJLWovhJFUHmpyJ0MMOi6Q59uf7SgZwTsW 0HSfXJ/Xgpm7CBpPgCk8Hf8oWLfAkRCYTAwe8aRJPzZa85ok8aU2E7hHSwJudoWj3ROj6EfPFZKJ 59Tj9ugYRWc6rnFJlGMfVzhORd4Snb30JTb3yf+yWPrznwBtCc0CGrVeAYCfCKUMQRfK0IY69KEQ jahEJ0rRuyT0ohjNqEY3ytGOevSjIA2pSEdKUp1V9KQo/UxJV8rSlrq0aeh4qUxnes2U2vSmlqGp TnfK05769KdADapQh0rUolIEp0hNamCMytSmOlUiSo2qVPHy1Kpa9apYzapWt8rVrnr1owzFxVTH StaymjWlX02rWtfq0zqw9a1wjatc57qRs9r1rqfBCF6JSFew7hVmffXrX1MW2Kr5hB+I5cc/EqvY kjR2sYtF7EkS61jKmoSxirXsZR/L2M1mdrKefexmQyvayqZEtJ+9bGgjq1nWclayrl1tZTkLWtT/ ura0K+msbTG7Wtp69ranhS1kVctb1RqXtcel7WdTW5VKDLYqpfVtY30L2uHm1riopa50pdsS4To2 t7jdbXWje93vmje8p8VubbUbE/ISN73jha95UcLd5AZXvee173Kt+1y3ZAS977UtfeerkvoOd7rx hSyCcZtgAuP3uAqurXwHjF/3Vve9AZ4vgydMYOY6OMITBjCGNZzeBVN4vyb+bGE7Ol3J7tbCyfVu jAWM4Ap/N7WtPfCFGzxbyooXuZ3dcY2Ry18HexjH1g2vd5WsW8squbwfJq+Ai6xjD1cZxCiu3Io3 +uMb81fEECZxdmFLYw0fmb6tZXCQIXzmLlM4/78DBjOIvWzaDxc4xEVGr5p3bOQvhznJVk7xlVW8 Zaf1RLk2jjKHkwxnOjPaz4/u8J+n7OcyO/rN1H2wfSt94Q1z2M19pjKlNz1lMA8Z0VbuL11Q02Th KnfJLs4xiS+dWc36uNNp7jSe2dzjyfp4zbGdbbB7LWzZllomul2vrW/dYVeDd8yjhjSRNx1hQhca o6om2bUzmu1Obfvb4A63uMdN7nJDpNvoTre6183udrv73VYxt7znTe+FEKHe+M63vvfN737724Pw DnjA/03wghv84AjPpsAXzvCGO/zhEI+4xCdO8Ypb/OJ8SbjGN24RTnD841bFuMhHTvKSm/zkKP9P ucpXzvKWu/zlMI+5zHE60FVnjmk351IFXrLzuvRcyyA3T08AQHQAmKToRzd6SYj+j6IrfelPf3rT p770k0g96lhPetOd/pQKeP3nXzfJz//xdbCbXexmB7vYTxL2se+87GuPO9zL/navo73uYSd73uNe kr33fOwy8Tvc+753trfd72sv/ODVTvaZI0bqVY8806FO9cpPfutHrzrkL591ylMe8idBCE5ED/jG 9/30fP/72Qkvd9SXXvWJb33sU8L42qOk9KjP/d9zH3i+m573tL+97BmfetO7HehB/w7oNz91ozvf 8pLXfPSZr/TqT7/5lc888gky+oO8XvjHj/3/243v+vLjfvfoZ/vvG39+2ZNf/Soh/untPni9zx/+ xQd++YUvfvzrnv3Cl3zhsXwo8XwGCH1UZ33YF3lWJ30JKH0GiHSRJ3o4ZxCqN37qF373N367Z3x2 x3rxZ37rh4Gu94G6Z4IeaIKF93uAh4Fqh34tyH8sGIIpOIL2538ziIKnJ4DgQYANqIDOJ4FbN3md l30MSIQSCIRGGHo5VxMIcXwxqIEA+H6Ll4M0eHZQiIPER4LvR4P/l4H/N3fBh3/yN4b313++p3cf yIWNx4MTMXQpEXXRt4Da54BHGIc/mIcP6INJYXv794UdyIUu+IfuN4VduH4z+Icd6IU2uH8v/4iD X8h73xeGw1d8MdiI6yYHRoEaXAd1cqiHdUiHCNiAmXd1RhiESfgvTUgTFFh/gkd/iAeGs2eIbkd/ Gah4eVd/ich+sHh4OtiCKEiCF4iIdyeDhLeGhteLW6iGZ5h/beiGETFzRYF7fkGN0niNO2GNeqGN KgeN3viN4BiOILU8aICN5niO6JgZ4riOaZWO7rgj7KhTVxCP9FiP9niP+Gg/77iP/NiPKZePAElU /jiQmlFzSEGBZYGQ3ReQ4OgUCjkWD2kTDBmOQ/h8mpd1neiJociEBnEWFEg2eeM8bDOR+sYTBFh9 GKl9nwh6ekFHY1RLBPluJwmBdGiRpViAef9xSuEjTzH5FHBAUEIIfQfYidSHk3iBO2xjPux0Eq7Q k6ZxCVVBM5/4gDV5ikuoih1pFgihSwyEOiQ5VJfQMqSIgNa3kipplBH5FaLXSKFUTV8ZVGG5Mhk5 ihd5eUOYdESIlQXhkTcHkpAjkliDNLfwlhUSlwPjkKsIFmnJioQpVIY5GU4ZmVQBlU9hkECxmH3R mFf1mJAhmZ4pFZT5maKpF6GpFBlBlJyXmkzndCy5fRfiFsxXgCjJdJqZVZwJLHKogHR5lSiBmWWB mkZpk65Zm/RmkjdJlnholHghnFYpiqNJVqdZinapm3g5lXrJfW1hl82JitdJnG5IlNlHnQz/yBK+ +ZumSIqm6J0luROxOZWxOZZ5YZO5OZ6t2RPh8Jw29Z7c6YmomJfxKYSpiHl3iZ8E2hX1WaAIahYH mqAM2qAO+qCZ8QQQOqEUOpwSwXVBOYr9uaF0aYoAinTnmRLlWRNXx5KzaXTqyY4mOpbzCZ9UGYq6 +Z68OaIzgaHjKaBSl6LruKJ5aJEy6pzhOYfwKZ40GhPyeaMvaqE6Km8mOZ14eIAVyZ+eJ5vgmYCr yZpIahTTqZ1WuqAV+lziSZPiWZTKSZUe6qJLoZ18mKVfOlEnw5w36aNlmqRBqqF1CnlFKhPCGaM4 uaThmIQZqqEYaqP0+YOquac3mqcvkZGc/6eREuinDekpiakTXkqekOqNcaGoMFGpK3Gp+NamoBqq opoYlsmXWUkVnvqNgTqXAtqhjIp1mweig5qhmrqoeEmlKNmdqVpuP6GfVnemyal1QvqjbKqlQRmi dDqqEvWmZaqEdjikcximPDqBk3oTcIqs1rer0Iijq4mehaoS5zmbKnmlTqp9tdoSakql0aetbriR 4XqsK1GieWmdcHqV54qu1omT2cquTOoTvlqnvEmvL9qizaoUUAqjyaqseLWqAMqi8Yqw7imrDbuR Q4Ga85qaCpuxNsGpGmtTpaqV1YoTHCuic6UM/LozdnGvPHGy5NaxLksUH9sWKls03aIFLP8rkDfq nhXJofT6qrf6q+QatHgaskZanUArpTcrbv76r87ZnuAqm2eZs097FIT6sCP7sjh1rdg3pvr6sFHr rGgKsL26m12LtXdVlvO6gBabq14brY16l3OJrL0Kq1MbqGYrVVjao3RKpsEapVV5nHNKFOmKpld7 tyc1k3LqomHaoQMLuNBasXd6lYVruDzDrMEKq0JLtgIbsZn7rSprsdJJrrqatD9zmxplUUS7qQtJ ugeHuqdqravLultGubQrkbJ7u7ibu7q7u+1au74bE7wbvN3yu8RbvMbrhMKbvMq7vCxLdMz7vBHi vNB7bf7EpV9RDcerF1V1UNPbvZhTCt7/G77iO77kW77me77oy67Zu77su77p+77wG7+S0b70W7/2 e78KG7P4u4nr6BOq8L+qUBIA/L8mEcAF/A8AjBIJjMALnBIDXMAGLMAKTMADvMAPrMAnEcEInMEc 3MEHzMEV/MEevMEiTMICXMER/MAabMInHMAovMItrMEXPMEhvMIu3MAxXMImfME2TMMqjMEo7MNC nMENHMIs3I8yzMIGnMI6LMFK7MAdTMBN3MMlTMVOfMUu7MEw3MNJfMRPLMJZjMEjfMRbLMYq0cVd fMZjHMY7HMVinMRWbMZk7MVaXMV27MUw/I55zMVXTMdL3BJlzMZlPMJ57MZ/fMBpPMiI/+zGULzB hyzBiozHctzHdOzHjXzJc8zEkszHmFzJaQzJgPzBgQzFkVxyGbHHQDzHjVzIlOzIbTzJn6zGrvzE nAzLX4zKswzHmFzKvLwSuDzGd7zITjzKICzLTdzHtWzMjyzMxSzG7MgTKUzBQFzKWIzDrRzGy0zJ NmzNw0zCmqzKnczG3izL2AzGcrzFQWzLyizNk1zFQTzDxMzMCfzCvkzENWzEECzFm0zKPPyPGJHM rhzHxyzQs1zQOszK8SzIB13PIAzPaszE3xzHvazO4SzJxpzJWEzKqdzMx/zFzEzOU7zPzty/OwHQ 5TzQFy3SBq3NLLHH0WzP+tzKLP3LE/8MwTAt0RVN0bZMzci80ePs06DM0TLt0UHN0D8t1EXd0RiH GLosyua8ysCMxkSc0z1N1Tht1NnsElZ81Qsd1e18x7FMyD79za9c1itdyLEszpdM1mw91EramDF8 w0Xc0Nu8xNycw8hc12t81+DM1WeszzS9xl19zfMMyzHNygxcxHxd1R8dzTGd2D6s1mgt2OkczDOM 1xb9zPu72ZxdofL72Q/R2aI92gQ1AqAB2qi9EKS92S+w2q792i2X2rI927StULBNGIGwv1Bw2w5V 2yMBBLjL28I93Njo28Z93Mid3OZL3Mzd3LGt3NAdGaoQ3dQtU8JQ3Ybm3F+K3UZ1BEb/pd3bzd3i Pd6kC97mfd7ond4ARd7Lrd7u/d7txt7lC98JKt/49gGWQ9/6vd+Dpb8BZd8iVVEAHlICPuB+VQAI XgD/kOAKXhINvuALjuAnkeAmweAK/uARTuEOjuEMnuES7uETruEa7uEP/uEQ7uAZfuIovuEmruIQ buEqXuIsfuFvbeAI5eIxvuIyPuE6jhIcrhImjuE4LuQVXuQNfuRAvuNKruQrEeRDXuQoLuQKbuMe ReQ/TuNQDuVIzuNZruUr3uU4nuVYvuVcjuQ//uJRzhJjHuY0vuY8TuWGtRNHLuFXLuU+HuQiHuJO HuMf3uEsfud9jud7Puc+3uNj3uJm/w7iaY7lKR7m/B0YV87jjP7kO97lVj7iRq7mXI7mlV7heX7m JT7pZx7hbM7pKTHpj24yeiXjTJ7jZf7lsG7nYI7qm57jWy7rae7qoG7pkn7qpl7oowvnQOMTHe7n to7oRl7sFA7jdR7oy47pis7qxd7rUU7nm27sLn7hxl7pfk7kqf7tw+3f6y3s2Q3ukknu6J7uFGnu 567u7v7uIMfu8j7v9F7viwHvu2vv+r7v/N7vMLtVjYDvAj/wnenv70jwCJ/wxWnw7qjwDv/w4Mbw Ej/xfQLx5EvxHqsyGI9W4eETUsATH38SIT8TI18SJY8UJ78WKf9PK08TUtDyAQXzUf+RER9f8y/x 8i+vEicv8yux8z1vEjWP8zpR8kT/DzJf9DLB8zax8jif8zGR8k0PFDDv9EZ/9C4v9EJh80bf81jP EkqP8igx8l9/82Lv9ULP9CZP8lF/8zof9sHuGD3R9V7vEj7v8m7f9mlf9jiB9GlP9yJP8kGB9jVR 91lv9kA/9jCB+EPf9ymh9z8/FVC/9SCv9IT/9zeh+HgP9KiKETZv9Y3v9CEf9Wcv9qG/9aV/+Hyv 9ZL/+Sbf9WvP+KZf9VQP+6EP+nK/+q2P+rXf+lT/+pav+bUf/FX/+4wf9Lbf+6Bv+sb/952f+7Fv /KR/92Gf/NDP+5Zf+kEv+4S/+8//n/NY3/neH/3aj/rOL/LcD/zFL/vDX/6aL/nN3/6H7/zeb/3j 3/jmH/ynL/rf//ErA/uPDxBSBP6T8s9gQYQGCS5kWFAhQocJFTKcuDDiw4oVJVrE+FDgR44HJ34E 6TAkRZQXTUrc2DIjQZIwRYpcmREkRZc1dV5ESfOkRZUYec4cKXToxo5Bjxb1CXTmzqdETyIdWtQk U5wNpV7V6lTjwJ4ss9bU2HHqWZ0G7a1l29btW7hx5c6l+/bl3as5x0aF2RIsVqEHb74sGXir1axm 0SrOW5im47M2yxLlyRVx08WYySZ9OjDt478991KWyjGh2K03Y5L93DWiZ8OCQ/cV/504ZOXZMX9K Xgk7s+jNeltLrFvceNy7yZUvNyvccNDIlrmiBgw98mGXjEenrB57e9Xpzb2XHf7dNnet1vUSnnx9 s2CZt7V35xu96frSUS3bRk2dO1Le9NPsPNIGxA9A5hJUcEEGGdRNNdn6k40/j6RTrDTIXgstL6By Y0q1wSKcsC8NE3sQsJTAgrDC3jwD8a8VQUOxxPJo+0pFFVkcUbz05hvJN5xy5IvGpHCcTsjqHMON w8CkG6zE25C0sELSNMxuvwazzOi4ubT08ksvsQQTRQfBFDO5M8dULjw122wzTTfjlHNOOut8Uzku 89Rzz7Xs9PPPMsPUMkRA1WSzUP9E4UR0UUYbXZTQLfmUdFLkHLX0Ukwz1XRThSj19FNQQxV1VFJL NVUuTlNVdVVWW03uVFhjlXVWWms1Nb9B21tQ0UJ5bdXXRoGtzdWKbDX2WGSTVbatOxG0CdKwshRz tTB7Y68qEvMTVkdp7TxyNryY8+/HI7klF9thiVV3XXY1/dTGNZc7dNdw37Q2QPZwTVfeCxPcVsFD 4eQV3friI/A9MhdcdmGGG3Z4z2b33W/F1Vz0yCds2azYSMROaxLAz0pyzuDD4mNtSRFpg9FK+OZb uWSlIPLQxJKrnBBIj00Gt12ee/aZUYFvbvI57Kwj18DxTFtMJZx/WkpIJu+TWmn/pHv8DTusOaP6 vRAro4/q+iAS8Geyyzb7Ug7TCrkzv87M2b4Pkc4YQiaH69oqukU80LVsWyua47SVXsq7ExnLW+up Yjx7ccYbv1NuouVjDc3fuB57a12dthnXyS8LvGqj/aaZs3JzHHzIy6JNvavr+nX8ddgXfdfBF9mW UGUeU2Z5p6htt/pCKHc/2lx4G2PJSK8bajrFDQFvz2vLMetwyiKXpMrFgh7Wfnvuu4cY9n9j51d8 db03/3z0uXccWvLNbJ/Y9OOXf35a37f/fvzz1x9P+uvf/38ABlCAPuuf/8JHL7QdsE7OEpelguYn Bbopgg2aIJ0qqK9uOaqAs3ob/2F04y99sa9eIOyO20TYrX/Ny1+QiRe/BLazFmIwW4+r4OcyR6UR xm1X1JIgBSejqN4V7FUb7JK90pTCEMrwS/M64gL3Rbkl5sqFDXziDXPYwyqSEINYIlhtDogw9wUK cWsC4wUH2LEY3gdwLdKhzsQmn+E9qWMbwleMZNaiO6rxYnz74Aej1Uclue0rP9wjiK5Fx+cJrmUP etu3Uqad3RHqKDha5PFYJhndKW9wG2PjWBozQ5LBkZLBO+EZ80VGkW0OPcOzGnRmthuSwGZKqTRP eaDCOrDtLY61xKUVjYfJVSaNem+E2miMZh4WyTI2v1Sl1GqElVvacpm8bKN/Qv/3u+y0b3ZaLBDf ZhQk37gyYKqbGiTFI82qzVBk6BxWI/fix8zdjZmdbKO2pqm3yIHsnlh7pnvAiU0CUSg41Kyc6ngX NecVlIhFfFQimwkziEYpkUw82D73xs668XGf5OGlCtGTUYACB3gTzZ0xpYdMfm40eaIEaBnP+dJ0 XpSQJ82aWPppSkPpqnb/5JGSMIYhJPETXDzcEVEjGdTaqa16xlMPPm3kJI71FHs7MgpUhZeaKwX0 qT6K0vIKJMetBq9fA2WmOjNUVMVFB5FsU+PpcPrWtyqQi3H9kxmJZVe45lWvgColmmAIV7zi8H19 3eviAlBYxCZWsYtd3EId+1j/yEZWspOlbGUte1nMZlazm+VsZz37WdCGNrJZ6B5jTXta1KZWtatl bWtd+1rYxla2s6UtoMpRW9zmVreFFW1vfftb4AaXYWUQbnGNe1zkGne3y2Vuc3mb3LkAALrTpW51 rTtZ6V5Xu9vlbncbll3vhle84w2VawHgXPSmV734O+963fteAIYXvOSlb33tiyrzwle/++Vvq9rb XwAHWMCA+u+ADXxgVd1XwQtmMHcR/GAIR1jCE6ZwhSfSYAxnWMP2bdyGPfxh8VpYxCMmcYlNfGLm 8kMhKjaIilnc4hXz48UxZrGMZZwRG7vYxivm8Y53jGIgB1lLn3pxkf8x4xrz/7giSb7LjI+sZCY/ eSIqBnGVrVxdN7n4yVHe8pK9LGUch7nHYCZzmYV8ZjTXSctaPnKO2axkOP8YyjdGcpu/DOM0yxYK eX7fmqVcZycHWsx4hjGgyWxkPic6ze/yM5ej7GQzC7rQUCY0pP9xZUxnWsGVhjOY5UzjNt8Yxz6W s5F//GJNp1rV3u3wql39aui2GtazprVvFX1rXF/YsrnmtaLVlygrjk9Q+wsswKJIxbqGpdihvCJd +ZrFvc4OnhjK4LOamEYlZntM4wImtKWYtBYC0dgJC1cQ5eSrwF472NVWYhfL3TVreQxYNsyhojyl iVFhEYquE3a3m73uVLm7Zv+9yqC4uelDc8cJ3RbsN8PJPUZ5OetlNEV2FhP+v4lBbZ0GM10vNYlH T4otZ1GVURzXeDOm6Yx4JM+kWNt6mifBG5S5iTnK8TbU0E3VNBaD14jAKriag7KQhjSZV0yX1Hsx 8kdUlQkgAzQxRY4ceTqdXrdJ+dfXEemnU0vbMcNG0Nc4E19fkxD0vJlN1iG06GMbWeueVjObjhSM YEv72r0uumiaE6JrMzpH+R73k7r17R/tedQVOaBkunOdZ507p/akCrfYUPFDwtnOBg+3p6U1Y9DU aI+sdx7BW1TsW3d7le4GmpUinkpUUWXyxvl6qaLdqB/njzK53rfxhD7kTI3/nlJyCXo0UnuaNfl1 g1QBzLaXHfGzHD5MRbfK3v1do6nvvY+y6cp3qvSh29dn9VmPTN3DUvRNtT4uOzf5323n64hj4MDN Lm/tD034MYWfniDPLLN+3vVe/eXJpn44Teo5mbkRn2O723sqSWK6wqEq/3MnoVMrplo9pDoY26MM KdEPmkMXo4o5tMMdyvu+wpA+D+wlKEmdEry5eDo8OyqhB/yoqbu07dGS4+OzZdu3XmMsuboUL1AY +3OLM6tBArzB08pBXXus+2MLIUzCXkufI+wTJXxCX7MVGQwgIAyjxqlCtJEtIjy2bUMgbVsvQeI3 iBukbwMYogq4hxMiMmQ3/0fBwpzCti+sOI8joQiqIXoROHbZpnaBkfExoWARwwQCxDncI7Jxwy6E w3ObKR/ytn9jw3jBQwYxFgmKKkbKCZ4rugGsqvBAmZ1rQZSZOKkLu31zOjI8GT3SnU1kq06ctk9M uq6qpAycuUvqm+Z5o7BqGZPDOVRcJKNjmpODRVGED1KEJ+xxRaBiOZ+TpKDDxDwKwo5jNkT5FLV7 JuXrO47aO09aP60xu76DuhHiO0KCnlQsJ88zCm1EnVbCxGspv9G7GtTJO+gDvsxIuT8yKcnJvW4q PXvUJ9VDKXvcuughD6+RxDdsva8TRyCpR7jTJYQpHF/ED6bjPNRzRtrrP/9NhCaGBB6KmUi886qD ZDyI48bEWSvZA0ncs0D0e0j1q7sRBKmqE79+7KeDEprwE5pHYhRp5Dyyyqdg+g+uykj367xmSr1u kjgD7KmVzBq4CaZqHMp+TCeUAildIqmgJMfzm0fpwbvNkb2H4kd9/EoQhCOm7McCQsDMu6pPFKyv DECfDMr9uxJKRL7qCULmqcv8ow/F4UqebMlkLMlm5EtalMoCVMutOsbRYSEiEcGzUsgAbEgT4UNr O8HBjEezDCkcQsyBKEsoNEQ0xDXOdJf+UULCEp/PdK/SzBTNhELVFB8QW03XfE1is0F/g6ABOs1V sSus6xmDw5TG2y89bLj/hNk8J0rDRZTNOGw4SCxDTJq3OFS3RjwlOSzO4QTOcOuh9ivCDfvDf0vO x5nO5+xONQTP5RQjhaPO70xE2oxORLRC21Ssd3nBBwyksDsRQLK8Syyml4zPS6KkTmTGX3SjYGy6 ZbS5vgylUZI6CVQrgVyZpkklB0S5a1pAUaSlvFHGRyJGkDPFVURAjKE5gCREtfiwRJRJE6y7qdSh wMGouJG+oPo9boRIE42oE/UcXMzKo5Q8sMNFfryle2rKzNsif+xRPhJJepyWwxtE53rPBv3Jf0Q/ L/rA4vHH2buqf1oPldTK3UPRw7Q2b7LJd7xJmUJHeovRa2yljVQ/qArS/8W0pKyqSDIJweIJkdZ8 wxPF0berEcHEvoIqP/DYRqzUnMDbPqHE0ttJvxddR/qzSoMSJprRQDJ1GSldPvNjv57MqJGbv/RS UriMxRJMvkzyU77cVEc6v4RMzL1c0zI9wbeczMG8HrHiGjpqQL15xrG6zLGD1Ux0ucJbU2WcRYv8 GK3bVWXyP5GoNYa6TUYcNtdsz9gyVvwKuNw0Ithk1mZ1Vmu1r/m6Vm3d1lTLVm7VVthMrAILV3It V3M9V3RNV3VdV3ZtV3d9V3iNV3nNtW+tV3u9V3zNV33dV37tV3/9V4ANWIEdWIIt2NKaV4RNWIVd 2EUzWId9WIiNWImdNf+GrVglnFiMzVj0sViOXUKN/ViQDVmRHVmSLVmTXbCOTdlb+02Vbdks4TCX jdkgY1mZtZN8WFeK/Yd82Nmb5dmd1VmfzQieVYibJdqJ8NmePVqgHVqiLVqg1Vmlddql/dmhDdql hVqjbVqnZVqsNQiptVqtzVqvFdqt/dmKqNqo5dqv9dqqDVq1Fdu7AFu23dqondq11VqqlVuk7Vqo ZVq5nVu8nduvNdurFdykNdq1bVu0HdvAbdqj9Vuu7dqypVu4tVq6vVmKlVq+hVuxLVrC1VzJrduX +NzDHVvQvVvK9VylXd3QfVrGfV3Kxdq7fdysPV22RdzaFd2zzV3TZY7/2E3dy+VcvgXdze3c1VXd uOXdvlVe5J3dxE1d1l1e1i1bziXe3oXd1x3e3FVdmB0T2xVa8K1b5J1e3d3dpC1d6Y3e8W3e6JVd 83Xfyt1c9NVc9i1e1b3f8kVf4w1d61Vf+ZVe+g3f7BVe7OVd6w3g4L1e3NXe7D1fxp3d9C3g+iXg 60Vg/31g+KWtT/HcvCVc+33fCIbdvf1bB57fD67dt2Vg5a1gFQ5hEz5ewA1f/E3c4/Xgyd3ds7Xh 8gXg/8VhwW3fzt1byfXg/01gFy7c/WXh8e1h8s1gtSXiAl7gBo5cup01Ghbg6h1iAb5iGVbgEGZg 6G3hDFZgHZZiL6Zf/78tXic2YQhu3SP23R0uXSL+3gGu4yge4wY2X8g1WwsO4DymXjE+3SeGYj9u YjN2XuPNXDMm4DCu49j9YgyOYP0FYwNu39/N4yRu5BY+3O/l4iUuZE3uX0MOZR+OXyw2ZDxm4iU+ YfhF5EPGZOEtZCZ25CaG4EvGzlX7YSFWYyRuYzfuW73FYctN4asd5p5V3GO+YVie2hye3GRm48ql 2rS14T125V9ODhL+XEsm2w7W5tGNX2QeXW9m5HF+ZMud5iwuZe01ZuJF48GdYyo22pytWXpeju6t Z3yesJPdZ37uZ3/+51l5nyvIZ4IuaINuWYBOaIVeaIZuaHs4aIgWMPKHnuh9jmiL5i+KzmiN3miO 5teL/uj36miRlliQLulMHWmUTmmVXmmWbmmXfiyTjmnmemmarmmbvunPkmmd3mme1mmc/mlj7Wmh fi2gLmpYG2qkXi2jXmpVS2qnPi2mjmpMe2qqrmqrdlepzmqt3mqunpSr/mqwDmuxHmuy5p+uPmu0 Tmu1Xmu2bmu3fmu4jmu5nut/LWu7th+6zmu93mu+7mu//mvADmzB9te7LmzWHGzETmzFXmzGbmzH BmzDjmzHeWzKrmzLti7JzmzNDldz2GzP/mwYvGzkMoaXBm3TPm3URi3RXm1lSW3Xfm3YPqOAAAA7 ------=_NextPart_000_000C_01C6F4D0.57AF50C0-- From avt-bounces@ietf.org Fri Oct 20 18:51:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb3By-0007JI-5E; Fri, 20 Oct 2006 18:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb3Bj-0006wY-50; Fri, 20 Oct 2006 18:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb3Bi-0007aU-RV; Fri, 20 Oct 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A9B7926E56; Fri, 20 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gb3Bi-00048W-Hz; Fri, 20 Oct 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Oct 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-profile-savpf-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) Author(s) : J. Ott, E. Carrara Filename : draft-ietf-avt-profile-savpf-08.txt Pages : 18 Date : 2006-10-20 An RTP profile (SAVP) is defined for secure real-time communications, and another profile (AVPF) is specified to provide timely feedback from the receivers to a sender. This memo defines the combination of both profiles to enable secure RTP communications with feedback. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-savpf-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-savpf-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-20155939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-savpf-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-savpf-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-20155939.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 20 19:44:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb417-0008Oo-3l; Fri, 20 Oct 2006 19:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb38R-0007uw-L7; Fri, 20 Oct 2006 18:46:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb38J-00070f-J8; Fri, 20 Oct 2006 18:46:39 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2006 15:46:31 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KMkUS8012924; Fri, 20 Oct 2006 15:46:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9KMkYW4026384; Fri, 20 Oct 2006 15:46:34 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 15:46:30 -0700 Received: from [192.168.0.10] ([10.21.120.205]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 15:46:29 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) References: Message-Id: <02BEDDF0-D414-4160-A75D-E7FF1022A3D7@cisco.com> From: Mark Baugher Date: Fri, 20 Oct 2006 15:46:30 -0700 To: msec@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Oct 2006 22:46:29.0946 (UTC) FILETIME=[955929A0:01C6F499] DKIM-Signature: a=rsa-sha1; q=dns; l=19123; t=1161384390; x=1162248390; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Fwd=3A=20I-D=20ACTION=3Adraft-baugher-msec-gdoi-srtp-00.txt=20; X=v=3Dcisco.com=3B=20h=3Dh2u+w4Gf7TU6SulC4S/yYyc/8E8=3D; b=RN4e9DLkZKDuVzqGtc9PD9jwU6gyS4XAJyu18aRHBxcJ9VFo34hryXxOOBcK97WNKSfDEILd G3O3tZKH9lBmiTcU2JVoYxjUumG6SNANXqzmi7qqbxWMJ4am/tBDx5K/; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b X-Mailman-Approved-At: Fri, 20 Oct 2006 19:43:06 -0400 Cc: Subject: [AVT] Fwd: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0208448174==" Errors-To: avt-bounces@ietf.org --===============0208448174== Content-Type: multipart/alternative; boundary=Apple-Mail-12-541080016 --Apple-Mail-12-541080016 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed hi We wish to call you attention to this recent contribution on signaling SRTP crypto contexts using ISAKMP GDOI. Please direct your comments about this I-D to msec. Thanks, Mark Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 16, 2006 12:50:01 PM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : GDOI Key Establishment for the SRTP Data Security Protocol > Author(s) : M. Baugher, A. Rueegsegger > Filename : draft-baugher-msec-gdoi-srtp-00.txt > Pages : 19 > Date : 2006-10-16 > > The Secure Real-time Transport Protocol (SRTP) secures unicast and > multicast media streams. Multicast receivers of an SRTP stream > therefore share an SRTP master key for multicast message > authentication and decryption. This document describes how to > establish a shared, "group key" for an SRTP session using RFC 3547, > the Group Domain of Interpretation (GDOI) and RFC 2408, the > Internet > Security Association and Key Management Protocol. This document > extends GDOI for SRTP group key establishment. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi- > srtp-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-baugher-msec-gdoi-srtp-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-10-16121241.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-12-541080016 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi
=A0 We wish to call you = attention to this recent contribution on signaling SRTP crypto contexts = using=A0ISAKMP GDOI.=A0 Please direct your comments about this I-D to = msec.

Thanks, = Mark

Begin forwarded message:

Date: October 16, 2006 12:50:01 PM = PDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : GDOI Key Establishment for the = SRTP Data Security Protocol
= Author(s) = : M. Baugher, A. Rueegsegger
= Filename = : draft-baugher-msec-gdoi-srtp-00.txt
Pages : 19
Date : = 2006-10-16

=

=A0=A0 The Secure Real-time = Transport Protocol (SRTP) secures unicast and
=A0=A0 = multicast media streams.=A0 = Multicast receivers of an SRTP stream
=A0=A0 = therefore share an SRTP master key for multicast = message
=A0=A0 authentication and = decryption.=A0 This = document describes how to
=A0=A0 establish a shared, "group = key" for an SRTP session using RFC 3547,
=A0=A0 the Group Domain of = Interpretation (GDOI) and RFC 2408, the Internet
=A0=A0 = Security Association and Key Management Protocol.=A0 This document
=A0=A0 = extends GDOI for SRTP group key establishment.



A URL for this Internet-Draft = is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-baugher-msec-gdoi-srtp-00.txt".

A list of = Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

I-D-Announce mailing list
=

= --Apple-Mail-12-541080016-- --===============0208448174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0208448174==-- From akstccablerocketmnsdgs@cablerocket.com Fri Oct 20 19:59:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb4Gq-0000kP-5L for avt-archive@lists.ietf.org; Fri, 20 Oct 2006 19:59:24 -0400 Received: from 20158135006.user.veloxzone.com.br ([201.58.135.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb4Fn-0002Ye-UM for avt-archive@lists.ietf.org; Fri, 20 Oct 2006 19:58:24 -0400 Received: from 204.174.16.204 (HELO smtp4.parasun.com) by lists.ietf.org with esmtp (45HKHGCUFEX 8025) id DL56HH-Q391VS-U1 for avt-archive@lists.ietf.org; Fri, 20 Nov 2006 23:58:15 +0180 Message-ID: <01c6f4a3$9bd482c0$6c822ecf@akstccablerocketmnsdgs> From: "Sue Wade" To: Subject: 27% up today Date: Fri, 20 Nov 2006 23:58:15 +0180 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C6F492.D84BB2C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C6F492.D84BB2C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C6F492.D84BB2C0" ------=_NextPart_001_0010_01C6F492.D84BB2C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable SORD - Add it NOW!Major PR campaign starting next week on SORD - GET it=20= early!WATCH SORD trde on monday - act Now."but can you think that lydia=20= is so lost to everything but love of him as to consent to live with"i am=20= talking of possibilities, charles."constantly.""you must not blame my=20= aunt. lydia's thoughtlessness first betrayed to me that you had beendue=20= consideration for the advantage of all your family, and if my manner =20= has been at all reprehensible,"how unfortunate that you should have used=20= such very strong expressions in speaking ofdetestable as such a step=20= must make her were it known, she could not help secretly advising her=20= fatherbest performers." on miss lucas's persevering, however, she added,=20= "very well, if it must be so, it"he could be still amiable, still=20= pleasing, to my uncle and aunt, when he was in town; and why"no," said=20= darcy, "i have made no such pretension. i have faults enough, but they=20= are not, i"yes-the late mr. darcy bequeathed me the next presentation of=20= the best living in his gift. he"and if not able to please himself in the=20= arrangement, he has at least pleasure in the great=20= powerY>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y> ------=_NextPart_001_0010_01C6F492.D84BB2C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
SORD - Add=20= it NOW!
Major PR=20= campaign starting next week on SORD - GET it early!
WATCH SORD=20= trde on monday - act Now.

3D""
"but can=20= you think that lydia is so lost to everything but love of him as to=20= consent to live with
"i am=20= talking of possibilities, charles."constantly."
"you must=20= not blame my aunt. lydia's thoughtlessness first betrayed to me that you=20= had beendue consideration for the advantage of all your family, and if=20= my manner has been at all reprehensible,
"how=20= unfortunate that you should have used such very strong expressions in=20= speaking of
detestable=20= as such a step must make her were it known, she could not help secretly=20= advising her father
best=20= performers." on miss lucas's persevering, however, she added, "very=20= well, if it must be so, it
"he could=20= be still amiable, still pleasing, to my uncle and aunt, when he was in=20= town; and why"no," said darcy, "i have made no such pretension. i have=20= faults enough, but they are not, i
"yes-the=20= late mr. darcy bequeathed me the next presentation of the best living in=20= his gift. he"and if not able to please himself in the arrangement, he=20= has at least pleasure in the great power
------=_NextPart_001_0010_01C6F492.D84BB2C0-- ------=_NextPart_000_000F_01C6F492.D84BB2C0 Content-Type: image/gif; name="ptoham.gif" Content-ID: <006901c6f4a3$9bd482c0$6c822ecf@8QNA4ZIN> Content-Transfer-Encoding: base64 R0lGODdhAQABAKIAAP////8AAMwzzGbMADOZmQAAAAAAAAAAACwAAAAAAQABAAADAggJADs= ------=_NextPart_000_000F_01C6F492.D84BB2C0-- From cmrkanidxb@alpujarra-direct.com Sat Oct 21 21:23:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbS3X-0000vW-W4 for avt-archive@lists.ietf.org; Sat, 21 Oct 2006 21:23:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbS3X-00056K-Tr for avt-archive@lists.ietf.org; Sat, 21 Oct 2006 21:23:15 -0400 Received: from [218.9.233.115] (helo=T05) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GbS35-0007FC-Lz for avt-archive@lists.ietf.org; Sat, 21 Oct 2006 21:23:15 -0400 Received: from 12.158.188.105 (HELO mail.alpujarra-direct.com) by lists.ietf.org with esmtp (MVAJF0ONGX5 M8PJGN) id XLD4QX-IHOSE3-17 for avt-archive@lists.ietf.org; Sun, 22 Oct 2006 01:22:49 -0480 From: "Marta Clarke" To: Subject: Very important note. You have to read. Date: Sun, 22 Oct 2006 01:22:49 -0480 Message-ID: <01c6f578$96a4c820$6c822ecf@cmrkanidxb> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: Aca6QTSNHW599SDFE5LY91ZB2PWIIY== X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Buy Alert for TGVI.PK TGC Ventures International, Inc. STOCK FACTS Recent Price::0.0085 Volume:830,000 Market Cap:6.01M Explosive Market Potential About TGC Ventures International Inc.: TGC Ventures International Inc. is a medically related holding company that is targeting the burgeoning multi-trillion dollar Health Care Services and Medical Devices & Supplies Industry. Value proposition resides in both its knowledge infrastructure and in the host of benefits associated with being a United States publicly listed corporation. Our technology also has the potential to provide earlier diagnosis of prostate cancer. In summary TGC Ventures International Inc. has the potential to deliver a substantially more accurate, less expensive, easier to use diagnosis for breast cancer, offering the hope of saving many patients lives through earlier detection of breast cancer, while at the same time lowering the overall cost of healthcare delivery. PRESS RELEASES Tue, Oct 3, 2006•TGC Ventures International Moves Head Office to Atlanta PrimeZone Media Network (Tue, Oct 3) Thu, Jul 20, 2006•TGC Ventures International Introduces New DirectorPrime Zone Media Network (Thu, Jul 20) Wed, May 24, 2006•TGC to Offer Homeopathic Complex for Psoriasis Sufferers PrimeZone Media Network (Wed, May 24) Wed, May 10, 2006•TGC Ventures International Executes Letter of Intent With Tagalder Environmental Bio-Tech Limited PrimeZone Media Network (Wed, May 10) Fri, Feb 3, 2006•TGC Ventures International Inc.'s Investor Inquiry Satellite Office Is Now OperationalPrimeZone Media Network (Fri, Feb 3) BUSINESS TGC Ventures International Inc. is a medically related holding company that is targeting the burgeoning multi-trillion dollar Health Care Services and Medical Devices & Supplies Industry. Over the last decade, the average annual revenue growth of the Medical Device & Supplies Industry averaged 15%, or 23% for Medical Devices and 7% for medical supply companies COMPETITIVE ADVANTAGES Our strategy is to become an emerging leader in the Health Care Services Market and Medical Devices & Supplies Industry. TGC Ventures Internationals growth will be accomplished with the acquisitions of "profitable" companies within these industries. TGC Ventures International will seek companies worldwide that can efficiently provide Health Care Services and/or Medical Devices & SuppliesTGC Ventures International Inc.'s Health Care Services Market Industry will consist of Health Care Services/ Medical Instrument & Devices Application Sectors, Biotechnology and our main focus on Early Detection Cancer Clinics using FDA approved Infra-red Thermal Imaging Technology. Disclaimer: Information within this email contains "forward looking statements" within the meaning of Section 27(a) of the Securities act of 1933 and Section 21B of the Securities exchange act of 1934. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives,goals, assumptions or future events or performance are not statements of historical fact and may be "forward looking statements." The publisher of this newsletter advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in stocks featured within this email. None of the material within this report shall be construed as any kind of investment advice or offer to sell or solicitation of an offer to buy securities. You can lose all your money by investing in this stock. In compliance with the Securities act of 1933, Section 17(b), the publisher of this newsletter discloses they received payment from an unaffiliated third party for the circulation of this report in the amount of twenty thousand dollars. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid advertisement and is not without bias. As we have received compensation in the form of free trading securities, we may directly benefit from any increase in the price of these securities. Use of the material within this email constitutes your acceptance of these terms. TGC Ventures International, Inc. Web Site: www tgvi us From abthslhmoj@numericable.fr Sun Oct 22 00:48:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbVGK-0006MO-Pz for avt-archive@lists.ietf.org; Sun, 22 Oct 2006 00:48:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbV3I-00024i-MK for avt-archive@lists.ietf.org; Sun, 22 Oct 2006 00:35:12 -0400 Received: from ip-61.net-82-216-99.rev.numericable.fr ([82.216.99.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GbV3F-0001oL-Fi for avt-archive@lists.ietf.org; Sun, 22 Oct 2006 00:35:11 -0400 Message-ID: <001301c6f593$14dfb280$3d63d852@steph> From: "purchased issues" To: avt-archive@lists.ietf.org Subject: pricesTips TVAbout Date: Sun, 22 Oct 2006 06:32:28 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C6F5A3.D866FBE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 025f8c5000216988bfe31585db759250 ------=_NextPart_000_000F_01C6F5A3.D866FBE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C6F5A3.D866FBE0" ------=_NextPart_001_0010_01C6F5A3.D866FBE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matthews am dumped suffering of Elton John lovelorn teenage themselves = laying beds dreaming kissing tom Welling a know Perennial alt countryno = depression fave Adams unleashes. Dominates market companies originate Land Rising sun Completing feast = without exception credits roster filled. Packed in Elastic is space Thoroughly modern Lily world dozens trading = wickedly funny insults. Tips water eat fats salmon almonds is Avoid in Protect am daily am = exercise adequate sleep Increase diet Living d pg Issues Tainted = Studysport ido Parity Hormonal Submaximal. Site is Stng Home Subscribe a Reader Rewards Customer Service Email = Sports Business Columnists Lifestyles Ebert Archives Blogs rss Classical = of Jazz Poprock Event. Football Feedback Contact Advertise Media kit = Homepage Suntimes Subscriber Services. Wauconda in Waukegan West co am Proviso Western Springs Wheaton Wheeling = Wilmette Winnetka Worth Member Group Traffic of Weather is Unwieldy in = Search Site Stng Home Subscribe Reader Rewards or Customer am Service = Email Sports. Too obvious settles sense is clearly is instead telling do indicate = filmmakers arent stillness silence enhances Starand giftemail of = thisprint thispost. Patterns saved allowing pick left off Finding or likeminded easier Quick = is Straight bi gay Males. Respond directly or submitted via ask needed Thanks or feedback effort = better or form Wheres Stufftrack orders Returnssee shipping rates heres = of. ------=_NextPart_001_0010_01C6F5A3.D866FBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Matthews am dumped suffering of Elton = John lovelorn=20 teenage themselves laying beds dreaming kissing tom Welling a know = Perennial alt=20 countryno depression fave Adams unleashes.
Dominates market companies = originate Land Rising sun Completing feast without exception credits = roster=20 filled.
Packed in Elastic is space Thoroughly modern Lily world = dozens=20 trading wickedly funny insults.
Tips water eat fats salmon almonds is = Avoid=20 in Protect am daily am exercise adequate sleep Increase diet Living d pg = Issues=20 Tainted Studysport ido Parity Hormonal Submaximal.
3D""
Site is Stng Home Subscribe a Reader = Rewards=20 Customer Service Email Sports Business Columnists Lifestyles Ebert = Archives=20 Blogs rss Classical of Jazz Poprock Event. Football Feedback Contact = Advertise=20 Media kit Homepage Suntimes Subscriber Services.
Wauconda in Waukegan = West co=20 am Proviso Western Springs Wheaton Wheeling Wilmette Winnetka Worth = Member Group=20 Traffic of Weather is Unwieldy in Search Site Stng Home Subscribe Reader = Rewards=20 or Customer am Service Email Sports.
Too obvious settles sense is = clearly is=20 instead telling do indicate filmmakers arent stillness silence enhances = Starand=20 giftemail of thisprint thispost.
Patterns saved allowing pick left = off=20 Finding or likeminded easier Quick is Straight bi gay Males.
Respond = directly=20 or submitted via ask needed Thanks or feedback effort better or form = Wheres=20 Stufftrack orders Returnssee shipping rates heres = of.
------=_NextPart_001_0010_01C6F5A3.D866FBE0-- ------=_NextPart_000_000F_01C6F5A3.D866FBE0 Content-Type: image/gif; name="edge..gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c6f593$14dca540$3d63d852@steph> R0lGODlhfALUAYf2AAACA3YHDAR7AoeMAAAAfXsAdwB1gLvCzbHow7DW/EQhDVogCIspDaMYAMQT AN8mAAJIDCk2ATg7C2QyDoA8AKNIALQ1CNpBAANYDhZgA0FVDmZRAINgAJFnAMdoBetfBgqNARmB AjGKAGiEAIWNAKOIAMZyDOqBAACRACqqBUKcAFKbAIqSCJ6tALOiAdyWAADDACXKAEW/Cl3OBITK DKbECre2AN28AALfAxnRAjvjAGPfAIrrAKPkBMHeC9PeAAAANx4APTsHOWgAO3gKSq4JNLQNTucA SAQROxseR0MkTVIhQIgUN6EdRsIgPtUXSA05OyNNOTo6NGZIOnwyPpxOOMlNN+hBOgRkPBttOT1r OWVjN3RUBqRmTLJTS+hdTAKISCR7SkuJNVKKO3qETaiAPcOOPe5+PACnMxiZPkKaMlehSoisS6mb N7SlNdyrPwDOOSTASzizSljCN3G7PpTEQb61ROu0OQDeMSDYOUfiP1vqNoTSO57lPbHZSNvTPwAA cxwJiDYAiW4AhoINg5kOjMgKh+sAeAAZhB4YdDMUgFQaiIcph6ARcskSd+ISewlDixk6jUw7jGY/ hXtOgJtFg7lNguA+fwpneBJbdDRUcmdUgINSd6RshLlmdNFucQd/fSVyf015hlh6dHp3gKCFc8iH fNh8dQOrgROmjUKkfW6aeIGjjZaegsWghNiZcQHLfiW1h0zOh1fEdX63jZi3i821de61ggDniBjt eDPnfmnrdnHteJfffMPWidHZfQQAwBgAyTgMymYKt3ENs5oAsbgCxt4KtgASuhYbtjYcsmofx4wi saYVvckUyOousQozyB9EszY1v2w5soo5yqtEwsI2vNE0wgJmviBYtExiuVJWyIlsyKBRwM1fteFu uQJzyBt+zTx3zV53yIWBw56Gv7qHzNR2xwievC6azkmgylqcvX6ewpudvLuSvOiZwgC4uS65tUu8 y1fBzX64spS8xP//5qqfroF4jfsJAAT/AP//AAkF/vMJ9wD/////8yH5BAAvo+MALAAAAAB8AtQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLxS5q3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp0+c9oIKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27SzXh3cu3r9+/gAMLHky4sOHDbX8qXsy4sePHkCPXREy5 suXLmDNrPiu5s+fPLBWBHk26dMR4plOrXs26Nclmritunk27tu3baJvhnhq7t+/fwIMThC28uPHj yJN/Jq68ufPn0KOXZC793+7r2LNrx657u9Pq4MOL/w9Pfbz58+jTqy4v3bv79/Djy59Pv779+/jz 69/Pv79/+uoFKOCABBZo4IEIJqjcfww26OCDmCko4YQUJthFhRhmqOGGDkHoYVUchnjehySWaOKJ aCGE4opHiehieCze9UGMNNaYmYpBfaDjjPbs6OOPPhq141A6EsWjUEACSeSROS7JJJM9GmlkkDkq qSSSRWI5pJZUcpnkjDz+OGWSWgqZZVFQEunll1vy+OKb0SF1ZpRpqnnUmVnOGaWUdqIJZZhH5qnm k3w2uWehS2Jp6KJ1Inpok3/eOaWiVVLap5RpEiqkjZxyWmeji6LJJ5iXhvrooHZGyuihmaa6qaiu Iv8pq1Kqygqqo7XWOquore7qaKfAltjorcNuSqqvphZL6KerBgqrocz+Smeftyb76lKaYnqtqbY+ eyqywYbLH0LDXsntucc6i6ukrH67p7PqOomnlWIymy2Z65pZbbaoeuvutIji6yacBC94bZDEsqst tP4Wy3C0Yc7aK8P+ugtml/+Wui+o/Hbb8MEBKyzuyPqRy2tSDi/87scgA1zosS5rbHHFLne8bcal +mrvzZ9i/KjDBQd9nJwq3yzzz9/qemm6IcPL88ws34uttDSfmuuv0VqdM8lcezgnzEZbKmii+TYM qKU9/pn1yjTPay3Ob5eNa6B0o82trjaf2/Xe+VH/ia/eZSKr55Z6q+3k0/rOW6+cX/NqbpV5p014 23pCfufiS8vbJt+cx4dj5/4JLXpwoJdu+ul7fY46fqO33tvqsMcue1mqzz6y67jbZHvXufcu0+5c +/6QMcJTdJQARCE/lPJBMS/A89BDL1T0zRfFfPLS2xP988snrz33028vPvjeh0+9+edbT/735YeP /fLrr6/99+l3P337TV2PPv3iw49/9tWz3/3mB7wCiuV6yEPg/fRHQPct0Hrq657+wKfAABqlghas nvPe10CkkI+CE+SgAz+oPPklUITzwyADlXJCB2ZwheyzHwlf2MESGvCGYNngBh+Ivw4OUIA/BGIA /3eYwf8JsYU+JCAMj6hBJuqwiDZUIAOlKMAlHq+GSYEhEpXYvida0Io4DKNUvIjFKQoxiFC8IgRt eMYgYrCJRYSjBy+YQic+cIUnpCIE5cjH/DUQjFosIx3/SMg4ivGQSVERGfUIRC2Or4dobKIZ1UhD CUYyhf1rYwuJOEQu4pGLffyiD7foR04Oco9klCEPC1m8VqoElLA05RvPGMLmSe+TALzkC+tXSFyy kI47rOUmk1jHTn6ykLrkZS9/ecooDpKNsQyKK6dpEjlucXtGPCUazejLUc7xhxM8Xze/6b1gdnGV ljTmM3kJxguKk5l79GQzCVlBatpTI1mkZxV7eP9MWpYTlW4kJxbBGUdoChSWxSRoJ1V5x3jKMipE tGIgeVhLaxJTPjnIwezAgBscmfCh22RkJOM3SoOaspHlC2E4DSlCCqKQmCV0nkHZt1Jv6vKgMUWp NmM4Qxfa0n7OyahQc3BP0MCzkgFVn0shaUsQ1k+l8ktqOheITfTlEn6zNKE2c7nSTKbxppTcpVZ3 Gr+o2hSsGB0qIgNTu7Wi6DxCLWpj3EpX/8CirnjNq173yte++vWvgA2sYMEi18Ia9rCITaxiNzTY xjr2sZCNrGQnS9nKlmgYls2sZqWy2M56lkObDa1o8fLZ0pr2tKhNrWp/MtrWuva1sI2tjaAh29r/ ana1uM1tnGzL29769rfApZ1uh0vc4gS3MAo4rnKXy9zVFfe50I2udKdb1OZa97rYza52t8tdvLa1 u7ah7ouCwo/y8sMe5j0veYVyXvMOxb3ohS950xtf9bLXvvSdb3vfe9/yFsW/+gXwe+3LXv4SGL/u Te+B5Qvf/NYXwfg1sIEdnBT6HvjBEN7vevuL4f8K+MIK5m+B9Tti9BZ4v/sVr4tMLGIWqzfCRHlx hUe84BLD+MMbPoqAcxxjAvNYwxv2sY9tTOP/GjnIEyYyU4Qs4Rg7mcUthnKLZazkARcZyTlGsYnP q2IK6fjI6wWylLH8ZTJT+cIuTvOQRYzmJzP5/8RNjnKUz/xkOYtZy1BeM5hLvOU6w3nPQ2ZymwOt Zjf3WcZ4Bq97EPJi/4L4zVPesY13TOcrI9rFkqYyj6/c3wQ3OcHy/XGWAUzoOPf51GOur5wx3N4G e7jMmx7znfmMZDEXWsNa5nKXJQRrVB961aWespTzi2ZNO9rOoV4zhYfNbBD3WtN/tnOz70vrXosa 0tGe8559DeNIyzrMp861ot+jogjfOMvbTvW5p41uZudZ27FuM7vNnOp2qzvenOZ2ta3tbD+n2c/K zne3+WxsONuaKLvmNVIszOATU9rRoa7yrB3s6UlTWtgAhzeFGZ5sBkP84R8GObQHrhQLT9jjx//+ MY6N0vGLZ5zEGP+1nsfd0YPQvOYJz9DNb5PzBJVuEkAP+s6HzhXfBb3nSE+60pfO9KY7vbpEj7pf n071qstG6ljPuta3zvWue/3rYA+72MdO9rKb/exmkQba1872trv97XDXz8zjTve6j9vqeM87Q+zO 9777/e+AD7zgB0/4whu+KHpPvOIHcvjGL9rm4YU8ZyWP3cUbFe0VWErmZ7N5x38H8gAIPQCEInrS jz4oobeH6E+PetazXvWwR/1QXu/62pte9atHOOWhgqMK+L7zvxdK5+3xe+AbX/jGB77whxL84We+ +MuPPvSL/3zfI7/6wSd+9qMflO1vfvhO8T7/9Lu/feY33/vLL//4lU98aVreM0h5veznn/rWx/7+ 9cc96WUv//zb3v72J39pAX7t130GyH3fd3zkJ30HSIAJmH4MCIFFwX4USBQEeIAY+H0YGH7cV4Ab OIEWGIHsh4AF6Hye1xQIIYD9B3uj14L4R3/8B4MreHo0KIMseH/7Zw/fhYIH4YAhaIIQ+Hwl2IBE eIEaeITM54HtZ4QROIRJaBQjaIDWN37aJ4VPSIIfSIQhGIRXmIFLGILvpxoqSBQuWIYvGHs1eIPz N3sxiIYxWIalN387yBQIkYBCmIRAaIVCqIElaH0LCIVFqIR32IB+mIGF2IeFWH4eCH53qHxH/8iI W7iIgIiIgliFXSiJh2iAYZgaY8iGadiCcYh79fd/OLiGoxiHn1iKQzGHS1GHePiDXdiIhOiHgziI T3h8JpiHXmiFTQiCWCiBjth8vviLF9iBtriHl7h+Sth+m2gaquh6MKiGOdiGplgUtIeDLuiGnciK SqEiFaiFu8iHx+iEfHiLrwiOyziC5ViOw1iJWuiIl7iLG+iDXviN6piO86iDzUgared//keGpXiN 17iG0yiNBsmCuRd73JhIkEeF4jeF6HeOvPiF8ziFeKh+2UeFkiiFEHl+mciIh1iL5GeL5geJJcmO 0xeRS0iL+OiF+wgZmBcfxXiCcTeTuGGTNP+Zkzq5kzzZkz75k0AZlJP3kkS5a0J5lIBRlEq5lEzZ lMWDlFDJF045lcMVlT3ZCGxFlVr5XGqxkHXhld24lWJ5EV25e34Blgw5lmqpEFZJIk2gdbkHjf4o irT3j9tBPemjQ2bVlpY1hjRoe9B4hgKIGxXFRifFl4+VgtaojTcolwC5gvpoEIOBEJMkSUC1lphp lqY3kI2JkKP4mABpGzF1TTGEVohZWYHphtKYjfs3mKI5VXU0S6fpWKqTmqkYmLgZmmgpF4q0SoY5 QJkZnAyRkNXoiaEoipuZhrsZFx51SwCkl8hDIWsgnAhSlpIpGMtpFNQpnLPZndZZEGORnZr/sZ3k 2RDhqZnZUZ7qmRDneZ3ktp7keRQJGYr0WXqr55q1AZmz95f5t1aS4J1WoZhtaJuhmZbgSRnzCZms GZnw2aCOKZiLWaDu556GsaABSY0M2qBjSQ2MZxRy2Z9puJ92eRv9eaGeCaC3dRDziY0E2aLaiZ6D AaKheY0aSp3yOaPTqJ8FaRus+aCciaKTJaA5ipz9CIqoqHsUWhjEeaT6R6Q1yp0xgp9AOqVWIaVU eqVYal2dkKVc2hXiSVowmhZPWp7yaZ8lSqD3SZc9yoat6Y+p96NoUZceWqRdKlqDyZkPuqMhSpAh qqNWChZx2aKfWaeUJaRs2ppqqKMHyaKq/3mojTqhB4oVa/qMBDmmT3qcfpmoqLipHpqmqmmmK7qK YRoVIFqiaFh/llqjOXinnWmiiCqhqfiqLgqpBMEVZxqh+5eqGiqroJmNirqnjIqmbCp/Xxp/waqn Gaqralmm/NmJ+BeXgcqnxll7bzqsZ7GkuPmmpkqog1WsduGtc8obyrqeETKqpEoV45qZ3Lqu7Nqu IGKufwGuW5Guwcms1nicTXqGRUqK+AqtoLqtYkGtZMip7kqbkqefcsqrepqbghquSBqpkoqpjlqD 9KquSeGn0biox/qpuDqxZGGhjJqxeEULBQsVp7igsTqrG0uf/UiXHvuxvzqof1qydfU5GP/rsjta kCuamho7mPI6sDn7qqNXseqJrCLLs4cqkMXZs2z6s57oqomarERLlfY6sCOqrwWqtKb4rzw7s1eR oJ9ZnzTbrfB6lmXrFF77olPLE0OQEzEwIZbhtEHLg2u7lcBlCWPbH3L7rWfrpXVrsbOxt7z3t5hp tC+Ypoirs9i6mVZrpNqKr+BKrXXZrFJLuFSbr0troQrqsADYqIo6q94arTf6epbrlMaaqb4qoRq7 siI7q3CaFZM6unkbWAJqpG94qif7l8a6qi1Lf4/7o6cXugIboXFYuk3JrLdqhlC7upNbg12ritDr FbfqqCo7u25ls4upvL/qujrruQorrZX/W6XHyqrGy5RKwapby7VYu7SrmZxq2r1dAbZt+rjW21eC SxeRi67la7e0kb/iur9EWb8CPMAEXMA/CcAIbBzZ1QoGrFcm0MB3l8AS/BsQXMEWvJMTnMEavMGK dcFUysEgHMIiPMIkvI8efMIoPHglvMJzlcIu7Fbu8MIyPMM0XMM2fMM4nHX3O7sanMNQucN528NI oQpErApBUcRELBRGrMT2UMRE4cRNDMVFgcRKvMRH/MRJjMRQTMVPPBRW3MReHMZizMRhrMVkPMZg fMZpfMRabMVU/MVrzMZG3MZwLMdfzMVYbMZwPMdSbMdqvMZcvMd5/MZd3MaDfMheLMVm/xzHQHnH cbzEbvzHV/zIUyzGSSzJgqzGmTzJnDzHY1zHguzIjEzJZ+zJXYzGjAzKp2wUoizKrIzKpgzIlnzK jrzJq5zKo/zJmrzLo1zHjocQvhzKnJzLkJwUqhzLqozGvjzLxczErpzMzjzLlQzGzXzF0NzLtzzM uUzM09zNuBzJ2CzM3rzNrmzNxkzGx1zJyWwaoUd1wVzIuDzNy6zN1CzL2VzOr1zPlCzO90zK76zP tezN14zNqCzJBC3Q8DzJ6VzG+WzQpBzNQ4zO6jzRp1waAGB1bpzFhTzQndzH9GzK1fzHe+zRCp3G 4BzP4xzLJp3PIF3KtwzKhtzPDe3EHP89zHQcxZcczgmN0ziNxy9tyDFdxTm90GUcyLQqGe2M0Ttt zrZs0E2tz1At0hG908gs1Q1tzXj8zpF80rY80F59FPzs0Pjc0h/9zUtNzrC8zSVd1kRNxqBx0UwH 1mdN1vTMzQVd1V8t11Oc0Yns0csc1mLN10Kd0zad0oZ91VFd1w9tzmvN0I4N0WKd1vNsz23N2AWt pGlbWSoS0BLdySx919LMxodd2KPd1VO90k6xyaad1qB92aSNz8pM1bxsz/uczbNt2TM9262MFJ0B 14lnx3ysyEU90pBM0n5s08QNy8aN0qsN1kON2FaN0r1M0/dM2JO9yD19zlL9zH5N2D3/rdJovd3Y TdrZ3dcn7daQkdSK58NCkd54x96YAbDwLTuP8AgoktmjxcILUd/6/TunWd8u3N8G8QgCXuAGfuAI nuAKvuAMXq/zDZQNHuEn8eAUXuHMJeEYnuEavuEc3uEe/uEgDrcWzpMhXuImfuIonuIdMeIs3uIu /uIwHuNeoeI0bh0y3ng1ruI3juM5juI7/uNAPnU9PuREvuFBfuRIfr1FvuRMruFi1OQFk+SbVQlS jsMFcOUFYA9YnuVBweVaruVXPhRYLhRbnuVeDuZj3uVnvuVoHuZtLuZpnuZt7uVu/uVdjuZ2fudq Xud5/uVlnud0vudmnrckgDoqcuaA/67ngS7mik4Ua24UdY7okn4Ugc7llg7pi57pmU7ple7oZP7p kw7lBEPpRfHog/7pjG7nk47qqX7pqc7qnn7nro7oqi7rrV7rtA7qtu7pg+7qsF7l24EQlh7mpr7q ZB7pcQ7nka7neP7me+7ocY7sy67qq37ppy7nuO7sfr7tz/7lou46ps7op87su97nfU7rbM7rSPHo tr7oym7tt67m5/7qxF7q247u3v7to5Pom57o8W7s5s7uuk7qrH7t5D7vvu7rtU7u4a7u487q+r7v b57u/M7nlc7mGI/x4h7tY07xgs7sZq7xA+/n9V7w2F7scu7u6Z7lES86T97yQfPyMP/PWMCuH8dQ 845VBjo88xGO83xHXb3A8yPi83Un9A1O9EVv9AuO9Ezf9MEylSmg9FI/9VSv4/6xD04POlV/4Fnv dlv/9WAPuF2PdmHf32PPdmWv32ffWGpXGEC89iWDHnBPMtWRFFKAFXc/FHn/FHsfFH1PFn9/GIGP OoMPFVJQ+LCD+KxzEHff+Etx+IdvFH+v+Ecx+ZUvFI0P+VbR95xvD4rf+U5B+VIx+JAf+U0R+KXP FYhv+p7/+Yav+V7h+J5f+bCPFKIP+ESx97f/+Lpv+5pP+n7P96n/+JKf+0cNI7Vv+0ph+YZv/MUf /L1PFaAf/Muv93zfFcAfFcwf+77/j/m7zxTfv/nUXxTRf/lvgfqzj/eiv/3WPxXh//yYf/zg4fiu T/6mn/ep//u6j/+zz//eDxBS7A20J3CgQIMFCS4saFDKw4QQEyokiLDhQ4YTHWK8OJFixYgQD27k 2JHhwYwURV5suNBjRJMxWSpEWFMjTZUOcUoEmfLkSos8Z6JUSdPmy4ojUdqcGRRjSY5Cm3psWTWp zqVPQ/4kGtRlxo1KSY4s+RUkSaw8hWL819btW7hx5c6lW9fuXbx4T5rdm5QlTItLu36N+pFoSqyG uQL2S1ZkYMMSn15tHFnwZciZ90quyvjw2cOaPRsdjBjnVZ2eb/ok/RGy39RFP6vu/xy6tuzLp0ub 5mo7Ld/SNX8WJpxbM+vRXo0r7tvc+XPo0aVPbz53+k3GtHNmLvsZ88rNk5dXVm6Z8vjZj1GL101V MczgzUWfb++6suyxyWUy179bsNfENAJKvd2OS4u916Qiizn7MOuqu7UYpI/A+bxrsL4KT8trQw47 9PBDva6bEMPBYvPPu8CoWi3D1f4jrzj0zPONLwOBu3C0xUbUD77ZSlwORxv7u1AsE3l8j8YZ4zNR NwaXRNLB01rcybkUHRSysR3t8wxELrv00kPq5BvwQPHIvBE05HoDDT4FsdvPvDFfGtOxBdkEKkiX oiKOTjrXAu/O9fD8a8ShzhrLtf85n1xSyjqx3PO3QR88FE0V8yxTUuDKMxS2wg41Mr0At6sxTFJL NfVUVFNVddX7WG1VxFPde05WV/tCqlZcw6Q1V1579fVXYF8NdlhiizXW2F1nLRW8Y5dlrdlck4V2 Wmqrva47a7PVdltuu/X2W3DDFXdccss191x001V3XXbbdTdb6yTU9VnppB3W3m/xPVZfC8v98l+A AxZ4YIILNvhghOHS1FZm7+O33z5Nhcq9Ki1NTFjoFIQ1WrCw3Sxj3DoGa9OOL4Y4uoRTVnllllt2 +eV4w5M22Vupk/VhMXvK8WOIcbZtXl5rnrnentPDMk2e31V6aabFXZjeBUX9a6v/KY80S61EXZyP vSQf21qpTMG2E9OYvNbZz7Ct2hM/0jQONeQWU9RKy5yibvpuvPNGWa6TOf0aSuycpJTu3CgrTzmm srsaNf/cLOo3Ftle1GooC4ccNwFX7PHoBH27fCCYQxd9dNJLN72tjUnULj80bSXxxM+rlrPTxY1j NnDaTYoccgKZtMzPzgHEHEY+pYxQc9uJO3155pt3vkNXVlY1y9Ufh02+14eMHXF6Oye8yethdPx1 J4Fkc3E5a3s7PkIdhrN9jPWWf376r9WTzIpZ/7n4iLNiFC3rCQpQarGUxQoIqu3wDz8IAlXmGqWo GOHoKGoiGwAd2LD6ZVCDGyyX/8826EEOhlCEIyQhuzBYQtehUIUrZGELXfhCGMZQhjOkTsxoeEMc 5nBpz+Phl6gELBCmymPUek3qiDU0XwWRVUoEWreYGD+bze8FLZzL0yymL5O1LjpYfFYRS+YqL24R arPq3Q+VNbMhYi9+GotV31IXxpulkWJuLFkYJdbEE6XQQlncSw/9KLBCJS2KEuLj9LqoLI75LIiK BBkS+YWvJ/rkiYyyUfgoCEUzyotUD7uVvaByyef8UZRfsqL7PDU3u2EuP0US2VDcdLudAcooE9NK 7iampD/BkjC5LNOu0le7zujpY7pEkvCCKczjUKphjsMahEIjzGAm8E3PtOWj+v/ES8/lSSbOPJBY oiaUUYbzLpkUk9m+R8k/Aa5uxazj01aZpOyJBlIu+pHDcqe6k81Ri/vjTz/TBM3JxQ6emVPPldJZ uCidU02ACVWW6onQhm4ueA/VpA6bJbTw1Sx5+Vsn5w5psvE5NJ6Iup8rFTpMhU5Qj6lM0KOwBdKF 3qh3HMWokV4Jv2Ryp0pX2l9OU6oj+hRoP1Sj0Ektqi2MwvNFcPORVZT6O/ehZ3dAlajk4Fcc6kEN eewb1ZOiWp/NJdR3BsUqToX6ucghDawjFWkRI0rBnVI0kkc1ZKZKSlJFXUp2rdSoU1RURl4ayGtr m5PiJEXQ8RCwKcO5688Gm0r//zHWguRh4FoPaFPxzTSvdiqSNdXa0pDcT7ChhSln03YnT2GSrqsV 4SJXOsK5ClJvsWVtbW0bqzSSkbZM2y1k73bC2wZXuMMlbnGNe1zkJle5y2Vuc537XOiGSZzTpW51 rXtd7GZXu9vlbne9+13whle84yVvec17XvSmV70Hi2573fveGa5XvvOlb33ta1+luQC+++Vvf/37 XwAHWIP3JXCBDXxgBCdYwQtmcIMdHF4BR9g5+pBwhZW2BwvjSg0Z5vBzAbaHPTxYxCMmcYntG2IT p1jFK2Zx6FSF4Q7HWMYz7hKIW3xjHOdYx106FYxn/GMgB9k5PhZykWtFACMn/xfESWZykytMZCdH WcrvhfKUrXxluu5Yy1vmcpcH9i4vh1nMYy4dls18ZjSnecbVUHP95sIPgsB5IHCW85zjzI8631nO eMbzSfhMZz7HWdCBDrQ9yHxoRCe6ZXVmtD3yvGdBMwTSfcmzoyM9aUsvBM6K5nSnPc2h5tDZ0pge taRNnWk/p3rQqGZ1q9v8alinyjqiFrWj/1zrSOe60Jfu86NtfWo7G/rTwyZ2sflG60z7utLLVnWw 7axsVjcadMamdrU7Xepa+xrVlXY1s599aWdzW9jWJne5vRzuXG+7z5Lu9a41TehdN7rQdTZ3ve1t 4ljnW99U5Ju77v1vgC943/8DJ3gIbVhwhAM4x2KsJMjaqMHeMtxZDv+VWyOeW9V+MFh2hFeJqXRC jRJNZohUY8NBiauKlbyiqELKI+m4chSJiJJgNOKqaCbbh0OxkK5r01aMKXKEwrW9Nzc5Ocd49IxP a+dh3fgmXw7JNs58iTWvq8o5VvQ85oxiVPOdxGEu9eBWceRSM6f6QnbYTTFUOIib1Cz5WlK4p0Y4 artd28smTdUUNLDalAqEclkn3P3VcrX8DyqX2VjF9R2AIytbWHbieJWWXbRgE5vft1kpOE7JmHH6 6DRXNPlxt1h/VRNr4II+vLaKLYDEW2rprQqpZA6Pc2+LKz0t+9a4rb7lr9L/VENh78+xMk57wydf VmJeIVaaj5+4Rx83NU/62EvmcFNTbH3wLci/uT5SgTwroeYZeUkeUp2Xwx/xMStVKxnOrFoiJviP 9KmCAnNUMIVo+0aP2LxXdlDVq75bl++5suCMqnq+tOqR2IOqGBGurBq/xOqN1KscL8q91qMpH5kn 85vAM0kow7q9p+pA/zu/3hsoofIoduoa4jPBo7Ee/itBS9oqjpOR14O+E5TBsOEpBUyUyVogn1oT v7Gge1ol3Hm730OrClomyIoQLeKs6XuT0TIgwLuYA4w/R6G9yLosySKp0BqS7TOTz5s+2KusTnqp BgG5QNo9tlsfqGKjLuST/9U6uCKLOKtLONhiOYa4PiyDw1aSQxRyrdtyQz38wwh7MEAcxAo7MBLC QzpUGkSElkWcHz7MuUT0ukasMF/CurNjPKezmepDKktcOoyLw2KZxEh8rZfzuktkOCWaJJkrRX37 JDPyJVHUQmtxRTWCxXWJxTsyOpQLv0xMRZtbRZgzLhwsrEC5pccLPN5IrbXDIC4kqiiBJj1SvOFw rM4iGefDu7ZhRkwxxjOsPL9TqWMirUKRvGpiLDY8mwFRvbnrlMIiqnTsCWlkQnD0LGt8KdAjGboz PjUEqI5yIbEjwbWiwNbAvKXywu/jRSK8p6LjkZRDnxLZvcpRQeFDQ7YJoP91BJ/zI5ypQkj2a5z1 Qz7jez+NTL/6Gz4QPA/BIasIQsmymsGJRIkHy73zGclZ8p71a4n+gL8B8p8M8a0UrEm+IrsCUru4 SSudJA65Y6DZ0ULfU0pLUpIJaT/t0awcxCuQBErlG0P9Qz3U+icMzMjImww0XEpxjEkWdKjy6Tym M8rWcz2ZrJ1K6UCrkpGAwr6Tyki3ZEHd2xkmERLkKcCzTBuxcizbE8inYr6TrL+a+krGvJ6UM54Y EUQcDBTdCQ4ECcAZTK2b1D7NmoosYsgjpMXt88y2W0MEhEGO2sJv2srBykIlHEfLhMJv5CfVTKA1 vMr7Oz6/YUqt/JTiscf/sdzNSIlCuCsgQ9RDXKyW5ISu5SRE9wIuRzyz5nRO6qxOQPRD68xOYgk4 hBEiUEw672wtFYqtTyQXT1JO8Cw47MQ53ou5oEG6TATFSOqk96zFQeIiXYRP/bREkqvP/nS4+ey6 PuLOlqG6flm6WoFDousV+ry6FHK5XcxPUmTQijPF/6w6eyHQAr1Ht+mlsDievTNHbnxIWvoltDE7 fgSefGw8vvu7oczCqWG8uZGbNVlCbto7tcPJ2yO8vry7BwG8b3I7bbo8y+ufdXIKIaWdw6Mnrps2 DVUZqkJNmpRB36zIwjSqveQd3VzB7Om+9xkplOrHHrVIA4xSwQoqruQN/zIFK4bKJyz1PsnZnpCk FeGZSSd90oRRTby8SiptTx00KYOiSiN1TZqcoKwkSrgcwz3SqwtK1MWTK0VlqgbtuhpZvINEJ6dE ETAUSq4CLBEV0v3AU5Wpy7WcUi98yoRsKg4kQQmMDS49TLmU05JMzdWbyzl6wMEMvu+B089EPfED zMnJVTu1yariniMR1ZSpzQ6VmwWUmi/NzdEiy4ziGtapHmVV09KMzSC1wr68q+jDzNfUHYUEPlmy vxc1E7wayh4UQpui1iS9TGltQoVA1oA5lxecuoKbTu1kMugEo/JEM33dV4EdWIKNLno9WIQtt4Jd WIZtWId9WF9JWImdWP+KrViLvdgCg1iN3ViO7diNxViQDVmRHVmSLVmTPVmUTVmVXVmWFR2PfVmY jdlceQOZrVmbvVmczVmdVaGW7Vmf9a6dDVr/2oJm+VmjPdrqElqlXVqmbVqnfVoNygaonVqqrVqr vVpvWU+sHdiV3VqIHVmvPZV8CFvmipd8ONuxRduztQe1HVuGQFuCcNuBkFu2VVu2XYi0tdu4ldu1 pdu0xVu7hVu9FVy8BVy+Xdu5Ldy9RdzFjVvFBdzGfdu+LVy9vVvHrdu+DVzG5dvnqNy53VzKxVzG tdzPFVzPbVvSvVu4Fd2TWF3Wfd3SjVzR/VvH9VvMnV3S9VvXrVvDddv/073c201c4H1dzh1bsO0L uk3d4QVe3+Xctx1e2m3dw03d6IVe4bVc333c63Ve0GVe76Ve6b3c5MXe4hXf0G1d803c8UXf7RXf 8r1e62Vf+bVd7G0O7q3d9K1f8IXfvM1f8E1e5+Vd+FXe881d/n3c7M3eNpuL8V3fBn5e2n3gA15f 1a1g25Vg4b3f/fVfCz5g/C1g5VVgBVbcCP5fEP7e93WOC4Zg/V3eDdZeBCbhAV7e6K3hEG5hA8Zf Edbe6s3hHYbh8wXgF77f7D1e9jXd0cVg9V3i5y1dJBbiv63eHt7fyh3hG77hBOZhLIZhER7d9I1i EG5e+g1eF97dFQ7i/yvmYTNG3sVd3cMV4gK2YSj24gCuYDse4xnW4DeW3RgO497t44E74ybm4tzF YEFu4iz+YC32YQ/m4BrG4x6WYslF3Clu4clV5DRO4Rnei0O2YwEuYyAm4Pbl4BdWXTd2YxaGYxP+ 3EbOY9f13AE2ZBaO3xwWZSyzDk12YUYG5Qlm4/rtZCr+YkIeZUj+XhwuZivO4Dhu5Vq2Ygoe5AB2 5kGm5VCuZRyOZUeeX2U2Zk8+5mnGZhr+5g2WZmNO3q5lXdTdZDLG41FW398l4VPu3tsd3Myt57zd 41aG5Vd+4lWm3kt25ySO5zGO5ujQZ3lO4zbGXXWu43uGXcMNZ+klaFH+ReXaPWgCVmVTpuTdpeGA puM1TlwjJluRVrh+G2mCDWmTTmluEYEMQlqXfukeUmmZfi+YrmmbvumSHQec3mm4+ACe/mmgDmqh xtOZLmroCggAOw== ------=_NextPart_000_000F_01C6F5A3.D866FBE0-- From avt-bounces@ietf.org Sun Oct 22 02:49:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbX7O-0001xE-Lq; Sun, 22 Oct 2006 02:47:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbX7N-0001wx-3x for avt@ietf.org; Sun, 22 Oct 2006 02:47:33 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbX7K-0006aF-MN for avt@ietf.org; Sun, 22 Oct 2006 02:47:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] 3 to last-call - RTP header extensions Date: Sun, 22 Oct 2006 08:47:24 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03FA4EE8@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] 3 to last-call - RTP header extensions Thread-Index: Acb0ceqoBHLR9gDNTPGvc7qSkZ4gkABM8JoQ From: "Even, Roni" To: "Dave Singer" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, My concern is with what looks to me like duplication between the header extensions and the "shim" draft and I would like have one mechanism if possible.=20 Roni=20 > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Friday, October 20, 2006 7:58 PM > To: avt@ietf.org > Subject: [AVT] 3 to last-call - RTP header extensions >=20 > Hi folks >=20 > the only adjustment here from the previous drafts is to use URIs to > identify header extensions, rather than reversed domain names. URIs > have the advantage that they might be de-referencable URLs, and > indeed the draft now says that for RFCs, the extension name is the > URL to the RFC. So the following two now say that, as well. >=20 > I'm asking for last-call on these, as we've seen them a while, they > are complete, and the discussion has died down. Re-start the > discussion if you disagree! >=20 > * * * * >=20 > This draft is a work item of the Audio/Video Transport Working Group > of the IETF. >=20 > Title : A general mechanism for RTP Header Extensions > Author(s) : D. Singer > Filename : draft-ietf-avt-rtp-hdrext-06.txt > Pages : 17 > Date : 2006-10-19 >=20 > This document provides a general mechanism to use the header- > extension feature of RTP (the Real Time Transport Protocol). It > provides the option to use a small number of small extensions in each > RTP packet, where the universe of possible extensions is large and > unregistered. The actual extensions in use in a session are signaled > in the setup information for that session. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt >=20 >=20 >=20 > Title : Transmission Time offsets in RTP streams > Author(s) : H. Desineni, D. Singer > Filename : draft-ietf-avt-rtp-toffset-02.txt > Pages : 15 > Date : 2006-10-19 >=20 > This document describes a method to inform RTP clients when RTP > packets are transmitted at a time other than their 'nominal' > transmission time. It also provides a mechanism to provide improved > inter-arrival jitter reports from the clients, that take into account > the reported transmission times. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-02.txt >=20 > Title : Associating Time-codes with RTP streams > Author(s) : D. Singer > Filename : draft-ietf-avt-smpte-rtp-05.txt > Pages : 20 > Date : 2006-10-19 >=20 > This document describes a mechanism for associating time-codes, as > defined by the Society of Motion Picture and Television Engineers > (SMPTE), with media streams, in a way that is independent of the RTP > payload format of the media stream itself. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-05.txt >=20 >=20 >=20 > -- > David Singer > Apple Computer/QuickTime >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sun Oct 22 04:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbYeZ-0007NI-PT; Sun, 22 Oct 2006 04:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbYeY-0007NB-45 for avt@ietf.org; Sun, 22 Oct 2006 04:25:54 -0400 Received: from stewe.org ([85.214.23.117] helo=h665227.serverkompetenz.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbYeX-0004Fg-GK for avt@ietf.org; Sun, 22 Oct 2006 04:25:54 -0400 Received: (qmail 5211 invoked by uid 60000); 22 Oct 2006 07:36:53 -0000 Received: from 127.0.0.1 by h665227 (envelope-from , uid 60004) with qmail-scanner-1.24st visas (spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 0.828078 secs); 22 Oct 2006 07:36:53 -0000 Received: from localhost (HELO webmail.stewe.org) (127.0.0.1) by localhost with SMTP; 22 Oct 2006 07:36:52 -0000 Received: from 192.100.116.143 (proxying for 172.22.38.215) (SquirrelMail authenticated user stewe@stewe.org) by webmail.stewe.org with HTTP; Sun, 22 Oct 2006 09:36:52 +0200 (CEST) Message-ID: <21669.192.100.116.143.1161502612.squirrel@webmail.stewe.org> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C03FA4EE8@IsrExch01.israel.polycom.com > References: <144ED8561CE90C41A3E5908EDECE315C03FA4EE8@IsrExch01.israel.polycom.com> Date: Sun, 22 Oct 2006 09:36:52 +0200 (CEST) Subject: RE: [AVT] 3 to last-call - RTP header extensions From: stewe@stewe.org To: "Even, Roni" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: Dave Singer , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi Roni, folks, Here's my take: The shim draft's main intention/application is to signal certain information (error resilience strength commands to be precise) from a media decoder to a media encoder, utilizing the reverse direction media path. I won't comment on that idea in fear of using inappropriate language, but I do have an opinion :-) If work should contrinue at all on this draft (I'm personally not of the opinion it should) I guess one avenue would be to split the draft into a) transport of opaque bytes shimmed between RTP header and RTP payload, plus related signaling, and b) the use case proposed (signaling of AMR encoder operation points from an AMR decoder). Then a) should be called a profile. That would be half-way clean, I think, though not necessarily helpful, considering that the profile negotiation problem is (to the best of my knowledge) still unsoved. Dave's header extension stuff, on the other hand, is a comparatively clean use of RTP's exstension mechanism that has been available for many years (although perhaps intended more for experiments than for regular use). It should not break existing codebases and monitoring tools intended to support any of the existing profiles, as long as the implementatiosn/tools follow RFC3550 in throwing away extensions they don't understand. Not true for shim. That's why shim should be called a profile. Dave's stuff could carry the payload proposed in the shim draft, though at a certain penalty of a few bytes per packet (using Dave's mechanisms, I think it's 8 bytes penalty). Some companies in 3GPP SA4 see this as a major problem, as it makes radio optimization difficult. Others disagree. But on the Internet, the 8 bytes should not do any significant harm. I believe, the main discussion should be between Dave's header extensions and the specification/use of new profiles. I believe to recall that there was a plan (proposed by Cullen?) to take this issue to the RAI area mailing list, as it is closely related to profile negotiations. But I haven't seen any related traffic. Regards, Stephan P.s.: in SA4, even the shim use case is by no means agreed. > Hi, > My concern is with what looks to me like duplication between the header > extensions and the "shim" draft and I would like have one mechanism if > possible. > Roni > >> -----Original Message----- >> From: Dave Singer [mailto:singer@apple.com] >> Sent: Friday, October 20, 2006 7:58 PM >> To: avt@ietf.org >> Subject: [AVT] 3 to last-call - RTP header extensions >> >> Hi folks >> >> the only adjustment here from the previous drafts is to use URIs to >> identify header extensions, rather than reversed domain names. URIs >> have the advantage that they might be de-referencable URLs, and >> indeed the draft now says that for RFCs, the extension name is the >> URL to the RFC. So the following two now say that, as well. >> >> I'm asking for last-call on these, as we've seen them a while, they >> are complete, and the discussion has died down. Re-start the >> discussion if you disagree! >> >> * * * * >> >> This draft is a work item of the Audio/Video Transport Working Group >> of the IETF. >> >> Title : A general mechanism for RTP Header Extensions >> Author(s) : D. Singer >> Filename : draft-ietf-avt-rtp-hdrext-06.txt >> Pages : 17 >> Date : 2006-10-19 >> >> This document provides a general mechanism to use the header- >> extension feature of RTP (the Real Time Transport Protocol). It >> provides the option to use a small number of small extensions in > each >> RTP packet, where the universe of possible extensions is large and >> unregistered. The actual extensions in use in a session are > signaled >> in the setup information for that session. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt >> >> >> >> Title : Transmission Time offsets in RTP streams >> Author(s) : H. Desineni, D. Singer >> Filename : draft-ietf-avt-rtp-toffset-02.txt >> Pages : 15 >> Date : 2006-10-19 >> >> This document describes a method to inform RTP clients when RTP >> packets are transmitted at a time other than their 'nominal' >> transmission time. It also provides a mechanism to provide > improved >> inter-arrival jitter reports from the clients, that take into > account >> the reported transmission times. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-02.txt >> >> Title : Associating Time-codes with RTP streams >> Author(s) : D. Singer >> Filename : draft-ietf-avt-smpte-rtp-05.txt >> Pages : 20 >> Date : 2006-10-19 >> >> This document describes a mechanism for associating time-codes, as >> defined by the Society of Motion Picture and Television Engineers >> (SMPTE), with media streams, in a way that is independent of the > RTP >> payload format of the media stream itself. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-05.txt >> >> >> >> -- >> David Singer >> Apple Computer/QuickTime >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sun Oct 22 09:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbdiw-0003O4-PI; Sun, 22 Oct 2006 09:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbdiv-0003Nw-OX for avt@ietf.org; Sun, 22 Oct 2006 09:50:45 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbdit-0002wd-3o for avt@ietf.org; Sun, 22 Oct 2006 09:50:45 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k9MDogYr009441; Sun, 22 Oct 2006 06:50:42 -0700 (PDT) Received: from [17.202.35.52] (unknown [17.84.23.154]) by relay5.apple.com (Apple SCV relay) with ESMTP id 08F56324013; Sun, 22 Oct 2006 06:50:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <21669.192.100.116.143.1161502612.squirrel@webmail.stewe.org> References: <144ED8561CE90C41A3E5908EDECE315C03FA4EE8@IsrExch01.israel.polycom.com> <21669.192.100.116.143.1161502612.squirrel@webmail.stewe.org> Date: Sun, 22 Oct 2006 21:48:55 +0800 To: stewe@stewe.org, "Even, Roni" From: Dave Singer Subject: RE: [AVT] 3 to last-call - RTP header extensions Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org At 9:36 +0200 22/10/06, stewe@stewe.org wrote: >Hi Roni, folks, > >Here's my take: > >The shim draft's main intention/application is to signal certain >information (error resilience strength commands to be precise) from a >media decoder to a media encoder, utilizing the reverse direction media >path. I won't comment on that idea in fear of using inappropriate >language, but I do have an opinion :-) > >If work should contrinue at all on this draft (I'm personally not of the >opinion it should) I guess one avenue would be to split the draft into a) >transport of opaque bytes shimmed between RTP header and RTP payload, plus >related signaling, and b) the use case proposed (signaling of AMR encoder >operation points from an AMR decoder). Then a) should be called a >profile. That would be half-way clean, I think, though not necessarily >helpful, considering that the profile negotiation problem is (to the best >of my knowledge) still unsoved. > >Dave's header extension stuff, on the other hand, is a comparatively clean >use of RTP's exstension mechanism that has been available for many years >(although perhaps intended more for experiments than for regular use). It >should not break existing codebases and monitoring tools intended to >support any of the existing profiles, as long as the implementatiosn/tools >follow RFC3550 in throwing away extensions they don't understand. Not >true for shim. That's why shim should be called a profile. > >Dave's stuff could carry the payload proposed in the shim draft, though at >a certain penalty of a few bytes per packet (using Dave's mechanisms, I >think it's 8 bytes penalty). Some companies in 3GPP SA4 see this as a >major problem, as it makes radio optimization difficult. Others disagree. > But on the Internet, the 8 bytes should not do any significant harm. The 8 bytes comes from the current treatment of the X bit (I have to have the signature and the length in there, even though my stuff is self-identifying and self-framing). So they're not quite my fault. But they are there. > >I believe, the main discussion should be between Dave's header extensions >and the specification/use of new profiles. I believe to recall that there >was a plan (proposed by Cullen?) to take this issue to the RAI area >mailing list, as it is closely related to profile negotiations. But I >haven't seen any related traffic. Nor I. I also note that we have been refining the header extensions for a while now, while the shim draft is both more recent (first version in august) and more specialized. I guess I'd like their comment on why the general header extension is not appropriate, or other alignment issues. > >Regards, >Stephan > >P.s.: in SA4, even the shim use case is by no means agreed. > >> Hi, >> My concern is with what looks to me like duplication between the header >> extensions and the "shim" draft and I would like have one mechanism if >> possible. >> Roni >> >>> -----Original Message----- >>> From: Dave Singer [mailto:singer@apple.com] >>> Sent: Friday, October 20, 2006 7:58 PM >>> To: avt@ietf.org >>> Subject: [AVT] 3 to last-call - RTP header extensions >>> >>> Hi folks >>> >>> the only adjustment here from the previous drafts is to use URIs to >>> identify header extensions, rather than reversed domain names. URIs >>> have the advantage that they might be de-referencable URLs, and >>> indeed the draft now says that for RFCs, the extension name is the >>> URL to the RFC. So the following two now say that, as well. >>> >>> I'm asking for last-call on these, as we've seen them a while, they >>> are complete, and the discussion has died down. Re-start the >>> discussion if you disagree! >>> >>> * * * * >>> >>> This draft is a work item of the Audio/Video Transport Working Group >>> of the IETF. >>> >>> Title : A general mechanism for RTP Header Extensions >>> Author(s) : D. Singer >>> Filename : draft-ietf-avt-rtp-hdrext-06.txt >>> Pages : 17 >>> Date : 2006-10-19 >>> > >> This document provides a general mechanism to use the header- >>> extension feature of RTP (the Real Time Transport Protocol). It >>> provides the option to use a small number of small extensions in >> each >>> RTP packet, where the universe of possible extensions is large and >>> unregistered. The actual extensions in use in a session are >> signaled >>> in the setup information for that session. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt >>> >>> >>> >>> Title : Transmission Time offsets in RTP streams >>> Author(s) : H. Desineni, D. Singer >>> Filename : draft-ietf-avt-rtp-toffset-02.txt >>> Pages : 15 >>> Date : 2006-10-19 >>> >>> This document describes a method to inform RTP clients when RTP >>> packets are transmitted at a time other than their 'nominal' >>> transmission time. It also provides a mechanism to provide >> improved >>> inter-arrival jitter reports from the clients, that take into >> account >>> the reported transmission times. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-02.txt >>> >>> Title : Associating Time-codes with RTP streams >>> Author(s) : D. Singer >>> Filename : draft-ietf-avt-smpte-rtp-05.txt >>> Pages : 20 >>> Date : 2006-10-19 >>> >>> This document describes a mechanism for associating time-codes, as >>> defined by the Society of Motion Picture and Television Engineers >>> (SMPTE), with media streams, in a way that is independent of the >> RTP >>> payload format of the media stream itself. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-05.txt >>> >>> >>> >>> -- >>> David Singer >>> Apple Computer/QuickTime >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/avt >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt >> > > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt -- David Singer Apple Computer/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 23 01:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbsAV-0004L7-Af; Mon, 23 Oct 2006 01:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbsAS-0004Kz-OL for avt@ietf.org; Mon, 23 Oct 2006 01:16:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbsAK-0006oB-QO for avt@ietf.org; Mon, 23 Oct 2006 01:16:08 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 47255552; Mon, 23 Oct 2006 07:15:43 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 07:15:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] 3 to last-call - RTP header extensions Date: Mon, 23 Oct 2006 07:15:15 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0503B6889B@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] 3 to last-call - RTP header extensions thread-index: Acb182NwtYMeRkGFQ5GJOLbuo0e0OwAadN/w From: "Ingemar Johansson S \(LU/EAB\)" To: X-OriginalArrivalTime: 23 Oct 2006 05:15:16.0568 (UTC) FILETIME=[39ECB580:01C6F662] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: roni.even@polycom.co.il, stewe@stewe.org, Dave Singer X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi FYI I have updated the draft-johansson-avt-rtp-shim draft and if I followed the guidlines correctly the update should appear on=20 http://tools.ietf.org/wg/avt quite soon. This updated draft tries to explain in better detail how the proposal is implemented. To comment on RTP header extensions against Shim inband signaling:=20 It is perfectly in order to put the Shim messages in the header extension as in the draft submitted by Dave Singer. This gives the extra minimum 8 byte overhead as indicated before. If 3GPP optimized VoIP radio bearers are used, the 8 bytes is enough to make a larger transport block needed, this has an increased risk for packet. In the Shim inband case the overhead is minimum 1 byte and the proposed radiobearers actually has a spare byte left so a larger transport block is not needed if only one Shim inband signaling is transmitted. The radio bearers specified in e.g 3GPP TS 34.108 are devised with the assumption that header compression (RoHC) is used. Switching of payload type (like in the Shim inband signaling case) or header extension bit (like in the RTP header extension draft) has some consequences on the compression efficiency as an extra RoHC overhead of typically 4 bytes for 3 consequtive packets is needed for stable RoHC compressor/decompressor states each time these RTP header fields change. If RTP header extension is used this will cause segmentation of the packets with an increased risk of packet loss. If Shim is used a larger transport block will be needed but segmentation is avoided, additionally change of payload type can be avoided completely if the payload type with Shim + original payload is always in use, this gives a continuous one byte overhead. The Shim draft is more recent than the RTP header extension draft. Please note however that tricks similar to Shim has been proposed earlier, one such example is proposed in 3GPP in TS 26.234 when defining a crypto payload used for DRM (see Annex K) and in the RTP payload format for retransmission (RFC 4588) (the "apt" parameter) (quote from an earlier email by Magnus Westerlund) Regards Ingemar > ------------------------------ >=20 > Message: 3 > Date: Sun, 22 Oct 2006 21:48:55 +0800 > From: Dave Singer > Subject: RE: [AVT] 3 to last-call - RTP header extensions > To: stewe@stewe.org, "Even, Roni" > Cc: avt@ietf.org > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"flowed" >=20 > At 9:36 +0200 22/10/06, stewe@stewe.org wrote: > >Hi Roni, folks, > > > >Here's my take: > > > >The shim draft's main intention/application is to signal certain=20 > >information (error resilience strength commands to be=20 > precise) from a=20 > >media decoder to a media encoder, utilizing the reverse=20 > direction media=20 > >path. I won't comment on that idea in fear of using inappropriate=20 > >language, but I do have an opinion :-) > > > >If work should contrinue at all on this draft (I'm personally not of=20 > >the opinion it should) I guess one avenue would be to split=20 > the draft=20 > >into a) transport of opaque bytes shimmed between RTP header and RTP=20 > >payload, plus related signaling, and b) the use case proposed=20 > >(signaling of AMR encoder operation points from an AMR=20 > decoder). Then=20 > >a) should be called a profile. That would be half-way=20 > clean, I think,=20 > >though not necessarily helpful, considering that the profile=20 > >negotiation problem is (to the best of my knowledge) still unsoved. > > > >Dave's header extension stuff, on the other hand, is a comparatively=20 > >clean use of RTP's exstension mechanism that has been available for=20 > >many years (although perhaps intended more for experiments than for=20 > >regular use). It should not break existing codebases and monitoring=20 > >tools intended to support any of the existing profiles, as=20 > long as the=20 > >implementatiosn/tools follow RFC3550 in throwing away=20 > extensions they=20 > >don't understand. Not true for shim. That's why shim=20 > should be called a profile. > > > >Dave's stuff could carry the payload proposed in the shim=20 > draft, though=20 > >at a certain penalty of a few bytes per packet (using Dave's=20 > >mechanisms, I think it's 8 bytes penalty). Some companies=20 > in 3GPP SA4=20 > >see this as a major problem, as it makes radio optimization=20 > difficult. Others disagree. > > But on the Internet, the 8 bytes should not do any=20 > significant harm. >=20 > The 8 bytes comes from the current treatment of the X bit (I=20 > have to have the signature and the length in there, even=20 > though my stuff is self-identifying and self-framing). So=20 > they're not quite my fault.=20 > But they are there. >=20 > > > >I believe, the main discussion should be between Dave's=20 > header extensions > >and the specification/use of new profiles. I believe to=20 > recall that there > >was a plan (proposed by Cullen?) to take this issue to the RAI area > >mailing list, as it is closely related to profile=20 > negotiations. But I > >haven't seen any related traffic. >=20 > Nor I. I also note that we have been refining the header extensions=20 > for a while now, while the shim draft is both more recent (first=20 > version in august) and more specialized. I guess I'd like their=20 > comment on why the general header extension is not appropriate, or=20 > other alignment issues. >=20 > > > >Regards, > >Stephan > > > >P.s.: in SA4, even the shim use case is by no means agreed. > > > >> Hi, > >> My concern is with what looks to me like duplication=20 > between the header > >> extensions and the "shim" draft and I would like have one=20 > mechanism if > >> possible. > >> Roni > >> > >>> -----Original Message----- > >>> From: Dave Singer [mailto:singer@apple.com] > >>> Sent: Friday, October 20, 2006 7:58 PM > >>> To: avt@ietf.org > >>> Subject: [AVT] 3 to last-call - RTP header extensions > >>> > >>> Hi folks > >>> > >>> the only adjustment here from the previous drafts is to=20 > use URIs to > >>> identify header extensions, rather than reversed domain=20 > names. URIs > >>> have the advantage that they might be de-referencable URLs, and > >>> indeed the draft now says that for RFCs, the extension=20 > name is the > >>> URL to the RFC. So the following two now say that, as well. > >>> > >>> I'm asking for last-call on these, as we've seen them a=20 > while, they > >>> are complete, and the discussion has died down. Re-start the > >>> discussion if you disagree! > >>> > >>> * * * * > >>> > >>> This draft is a work item of the Audio/Video Transport=20 > Working Group > >>> of the IETF. > >>> > >>> Title : A general mechanism for RTP Header Extensions > >>> Author(s) : D. Singer > >>> Filename : draft-ietf-avt-rtp-hdrext-06.txt > >>> Pages : 17 > >>> Date : 2006-10-19 > >>> > > >> This document provides a general mechanism to use the header- > >>> extension feature of RTP (the Real Time Transport=20 > Protocol). It > >>> provides the option to use a small number of small=20 > extensions in > >> each > >>> RTP packet, where the universe of possible=20 > extensions is large and > >>> unregistered. The actual extensions in use in a session are > >> signaled > >>> in the setup information for that session. > >>> > >>> A URL for this Internet-Draft is: > >>> =20 > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt > >>> > >>> > >>> > >>> Title : Transmission Time offsets in RTP streams > >>> Author(s) : H. Desineni, D. Singer > >>> Filename : draft-ietf-avt-rtp-toffset-02.txt > >>> Pages : 15 > >>> Date : 2006-10-19 > >>> > >>> This document describes a method to inform RTP clients when RTP > >>> packets are transmitted at a time other than their 'nominal' > >>> transmission time. It also provides a mechanism to provide > >> improved > >>> inter-arrival jitter reports from the clients, that take into > >> account > >>> the reported transmission times. > >>> > >>> A URL for this Internet-Draft is: > >>> =20 > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-02.txt > >>> > >>> Title : Associating Time-codes with RTP streams > >>> Author(s) : D. Singer > >>> Filename : draft-ietf-avt-smpte-rtp-05.txt > >>> Pages : 20 > >>> Date : 2006-10-19 > >>> > >>> This document describes a mechanism for associating=20 > time-codes, as > >>> defined by the Society of Motion Picture and=20 > Television Engineers > >>> (SMPTE), with media streams, in a way that is=20 > independent of the > >> RTP > >>> payload format of the media stream itself. > >>> > >>> A URL for this Internet-Draft is: > >>> =20 > http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-05.txt > >>> > >>> > >>> > >>> -- > >>> David Singer > >>> Apple Computer/QuickTime > >>> > >>> _______________________________________________ > >>> Audio/Video Transport Working Group > >>> avt@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/avt > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www1.ietf.org/mailman/listinfo/avt > >> > > > > > > > >_______________________________________________ > >Audio/Video Transport Working Group > >avt@ietf.org > >https://www1.ietf.org/mailman/listinfo/avt >=20 >=20 > --=20 > David Singer > Apple Computer/QuickTime >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt >=20 >=20 > End of avt Digest, Vol 30, Issue 18 > *********************************** >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From krph@alyans.com.tr Mon Oct 23 02:48:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbtbk-0004uD-C4 for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 02:48:24 -0400 Received: from [85.104.154.127] (helo=dsl85-104-39551.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbtbi-0005kg-Tx for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 02:48:24 -0400 Received: from 212.58.5.201 (HELO mail2.alyans.com.tr) by lists.ietf.org with esmtp (FOJ24HXY DS8FQ2) id 2J910Q-XDE896-TL for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 06:47:22 +0480 From: "Yong Wilder" To: Subject: Momentous note. You have to read. Date: Mon, 23 Oct 2006 06:47:22 +0480 Message-ID: <01c6f66f$17a09340$6c822ecf@krph> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: Aca6QP02IC34YT6B94UINR1KQDV6FM== X-Spam-Score: 3.8 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 The great predictions are made. The increase is up to 70% last time. (MXXR) is the gainful deal and those who knows it is making money. The drilling achivements of this highly capable oil company exceeded all its expectations. Once this information hits the outdoors there will be no stopping this one. nowadays it's approximately 0.022 but we are waiting it to triple. Once the announcement is made and the PR gets into full brandish. Don't waste time and miss out. We propose you to buy today. The key is getting in early and time is limited. We are told that Monday is the day this one will detonate. Find your position before that happens. From krefpbpy@realtimepublishers.com Mon Oct 23 03:41:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbuQj-0000re-BG for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 03:41:05 -0400 Received: from [218.77.119.98] (helo=[218.77.119.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbuQX-0007RC-72 for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 03:41:05 -0400 Message-ID: <000e01c6f676$852c88e0$62774dda@ggqtvviwfbvfo2> From: "provided" To: avt-archive@lists.ietf.org Subject: perform Auction Date: Mon, 23 Oct 2006 15:40:32 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6F6B9.934FC8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: be922d419820e291bde1362184dc32fd ------=_NextPart_000_000A_01C6F6B9.934FC8E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6F6B9.934FC8E0" ------=_NextPart_001_000B_01C6F6B9.934FC8E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Recorded Gracious host a live unusual time table Revord hospital or = Chaplin came know of over few months atempt gather much possible through = of years complete therefore of anyone any additional please am me. Pearce Kerry Start David Housden discovered historical recording return = Goldstar Studios original Bryankenny or minus entries Wikepedia Bobbie = Happy Birthday Vindicator lyrics or Gordon Franks February a. Bbc Fablesthe of Murphythe staff Campanille is Hotelps Click see us = mentioned in an article about ipo cd id in Rather. Harvest end loop am clone button in code Note Remove subject of = warranty. Backing presently committed gigs summer intention mixed donating = proceeds cause our extends concern heartfelt prayers family. Po in box is California is Prices add or postage rest world in cd info = releases far is. Liverpool a was blast as thanks a todavid Bash of pop at Leigh bbc = Fablesthe Murphythe staff Campanille Hotelps Click see? People or really close we united grief loss lee October Added scans a = releases da Capo face bobinbed week holiday Greece. Before finished Theres a do got some of early don Conka photos Norman j = or Hauge ed Freedom London Film. Us of mentioned in an article is about ipo cd id Rather of not Sayour = second of album say. Po in box is California is Prices add or postage rest world in cd info = releases far is. ------=_NextPart_001_000B_01C6F6B9.934FC8E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Recorded Gracious host a live unusual = time table=20 Revord hospital or Chaplin came know of over few months atempt gather = much=20 possible through of years complete therefore of anyone any additional = please am=20 me.
Pearce Kerry Start David Housden discovered historical recording = return=20 Goldstar Studios original Bryankenny or minus entries Wikepedia Bobbie = Happy=20 Birthday Vindicator lyrics or Gordon Franks February a.
Bbc Fablesthe = of=20 Murphythe staff Campanille is Hotelps Click see us mentioned in an = article about=20 ipo cd id in Rather.
Harvest end loop am clone button in code Note = Remove=20 subject of warranty.
3D""
Backing presently committed gigs summer = intention=20 mixed donating proceeds cause our extends concern heartfelt prayers=20 family.
Po in box is California is Prices add or postage rest world = in cd=20 info releases far is.
Liverpool a was blast as thanks a todavid Bash = of pop=20 at Leigh bbc Fablesthe Murphythe staff Campanille Hotelps Click = see?
People=20 or really close we united grief loss lee October Added scans a releases = da Capo=20 face bobinbed week holiday Greece.
Before finished Theres a do got = some of=20 early don Conka photos Norman j or Hauge ed Freedom London Film.
Us = of=20 mentioned in an article is about ipo cd id Rather of not Sayour second = of album=20 say.
Po in box is California is Prices add or postage rest world in = cd info=20 releases far is.
------=_NextPart_001_000B_01C6F6B9.934FC8E0-- ------=_NextPart_000_000A_01C6F6B9.934FC8E0 Content-Type: image/gif; name="day..gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6f676$852c88e0$62774dda@ggqtvviwfbvfo2> R0lGODlhYAIYAof2AAgGCYgAAA2JAIh5DQ0JgocAcgWOf7jEwrLPwpvI6UEjA1oWAIgmAKwcAMYW AO4eAAQ7CSQ+ADo4Dl85AXY4Bp5DB7VCAO44AwlTABZkADRpDF9eB4tSAJJVALxUB9VgAAB0ACpz ADF0AGF9CXKCAJp0Ac6HAON0AACmACahADKmAFKWDYelAJyqCLafDOKZBgC1ABHEADfNAl3IA4nF AKTHBcXNAOS2CwDuACrpADHWAF/eCIzaC6TdALzhCeXhDgADSSkATE4KR1wNNHQGNK4ANbMAP9sM RAkpSSAmPEgqN1MZPYIePZQTN8smOu4oQAA8NB0+Nj1IMl5NMYVKOJ89R7w+Qt1AMwBmOiJnNDFb SWhqOHttDqNkPMRrSe1VOACITCJyPEOLPFR+MYd1R5eJQ7aCNtKMOwCkSxqWOkCkQ2uaOoCSO5ea R7+lQ+ijSwDDQhS8M0fHNVjHToe8Npy5OsOyS97IQQDrSiPhQTXcP23TPYzuR5jSOLrrP9jpNwAJ fBQBjDcKhWkKe4YIhakAfboAc+wEcQAmih0Zi04UjmMphXsueagYi7MmeuEefgA5gBxHe0FGjmdC fXJOjpRLf8JKgt5OhABdcyxcgzxlc1pdhHRsiahYfctRgu5RgAyIcyKNfkR8d2h/g42EfJN9ibxz juV2dQCqdyqldTKiiFeWhoaZjKOue7Kpc+2TeQHCeyW+iEfBd1azio69jKzKdruzfuLHgAHfgS7l hE3Vfm3rfnXpiZjcgLTceOLZcwAAxBgAuT0AtGMLy4UFu6MKyLEAt98AtgATzRcTtEMrw14lyIof w6ETtbImy+QcyAA9viQ1ykpMy246v3I8uJlDzsY0suM4ugBgshJVzjJsumZdvoxWtaVtvrRmxdxa ugB+vyF9u0JzzFZxzHeKtJ16tMd0zdOKugamtymfzEeWy2eduoijuZmiw7WjyNiZyAK/yhK2u027 wG3DtIzDvJfFuvv686WYsnt4hv8BCw3/APf/AAwA//8O/AD5+v///yH5BAB1xHcALAAAAABgAhgC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MFHam0mzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKneozptWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/HqkKHky4sOHDiBMrXsy4sWOmgCNLnky5 suXLmDNr3sy5s+fPoEM/HCq6NMjHqFOrXq2TE2vBpmNzfE27tu3bqmXr3s2792yhvrN+oIu7uPHj yBcP/MB8+L/m0KNDP9icIPOCzpdLj249u0Dv1Zdj/x/fPfxz6eenawev/jv68tuvO+cOn3566tep J8weP/53gckFKOCABBZ1nnXPKeQddvzNt+CCCSKIH3n5HRjhf+CR99+FEjKo3YYgQmjQg+ORqF93 H7qXYocljsiihAXGKOOMBHIo3n44SjhchhqC2OKNJl64440szndijxHyaOORPiYoIpM28ofkkhi6 SCR5NGap5ZZUSfTkk01eKd6QYkaJEJlVWimllD0aaeWLaYbIUJBwnlknmi9+uaSSUwbnp2hfvhfm oGSymaedQlLpppNl2rddetWJiGeD9okZKJg+Sqpon4y2+R6mf4aK11CU4vlmn2guaimiSW7a6oYQ 8v+oKaqQ8snqoCjequmsZSZaJKJcBivssIPFSmWvm7JpbJ2+mirnmlA6u6d+hh576Jy6UhstfuZl Ciyx4IYr7kwTkYgpmCZmuCyy6jbZbpyH8nqtkqCaie22HdJJ6KrIiuovoO/e6qGKUa6L64MOrmih wleq2muF+aV778OcIrwixAa7+yuU/3ZcF2nuRSyotSHnibCtlrIn77GOooduhdM+Wh6zlaIK83pn ckenyuo5N+7PQGvp8dBEF2300UgnrfTSTDfttF0gPy21QUFXbXVjU2dN0NVcd22g1mCHLfbYZJdt dksCFJQ2QWsL1LYAcMcd90Byu21Q22rP/Y/ccLP/rfbefdPN9+CB/y143YcjfnfhgBsueN5sM874 3oAr7jfdjjuEd+KVDx555nrbfTnmlJ/tpyYr4Z226phvXvrjrd+9uN+bB8666Afdjrvdb0P+ekKF 216777AHv/bkqxNPue6uL5Q87Ls33/jlxkf/+/GmZ+987Na7Przsme9OOvXj/w766LyXL7r06Jf+ vPjvP//9+8uDn/747CNEf/7S7w8//q/rnfayRpreCfB+6Ouf/cSnvvt9L3cJ/NsBabc92fmPgulr XvJYp0HuefAh8augBTFoOAMC8B9eS6EKnRLAFn7QerkjXPgaWD/vAS+CJOygDNvnQPVh74cQxB4C /0dHv/pFJIQKUWALO7jEE67wiVAkl0SE6L4Tlk+J7Xvb3HQ4OfMl0HIu1KEIc/g/IxYRgUAE3wS9 6LbQnTB/bAwjG4UowDUO8I5GzGPnHhhHG/LwjGac4RV9iDgxJjGIpHugCUe4vjm20Y1xTGIhx0jE IQJwkQwMziPwOBrg5PGC5uNjA/34wirCEIKDfKMaGTI/EuKujiWkICnXCEdUulB/uOQeH0PYvCj6 8pc8aSPxdqm8M3qPg75j3g19+L/aURF4WoSfKNcXzVAW0Xbng8j8dNfHZFZTmJ8jHTDHSU4phjKL POwcA/unN88xE5KpdOXy+BY5esaQm9OjoeokB/85d5Yxk4f8IvJyCb3K2bKM5UxouDjJ0IY69KEQ jehboiZRPyn0ohjNqEY3ytGOevSjIA2pSEdK0pKa9KQoTalKV8rSlrr0pTBVTkVnSlPMxPSmOM2p TnfK05769KdADepJa0rUohr1qEg9qlCXytSmrlQXTo2qVJuS1Kpa9apYzapWt8rVrnr1q2ANq1jH StaymlU2U02rWnV61ra6NSJrjatcWfrWuqIlEk6bq173yla7hoavHPWrYAdL2MIaNiH8SCw//qHY xQrEsYxlbGIJotjHVnYgjV3sZTEL2cZyVrOU/SxkOSva0VrWIKMFLWZFK9nNtrazk30tay3b2dD/ pva1pkWIZ2+bWdbW9rO4RW1sI7va3q72uK1Fbm1Bq9rD9sW0v3Xsb0NLXN0eN7XTjW50FTLcx+o2 t7ylLnSt693yghe117Vtdh0y3uKiV7zvLW9Btqtc4abXvPVlbnWdi5ahnNe9t52vfA9CX+JKF76R PXBuETzg+yI3wbaNr4Dv217quhfA8l2whAfc3AZDWML/vXCG0avgCeu3xKAFbEulO1neVli53YVx gA9MYe+q1rUGtjCDaVvZ8CbXszqmcXL32+AO37i64O1uknd72SST18PjDTCRc9xhKn/4xChU8Up9 bOP9hvjBI8ZubGecYSPP17ULBvKDzczlCeNX/8Bf/nCXT+thAoOYyOdNs46L7GUwI7nKKLZyikVK Ci3jBMmIzjGUN5xoIcu5wIruc33dLOk5v1nObp6ugyfdZk1zl9JVxvOi/dxoC39ZyMvFNNUMfVGK MHm4y1Vyi3E8YksneLM9NjWaTX3nNfOYsj1Ws2xpO+xfE3u2UtYwgXNdXDXvds2w/q6YpezrY08a wqHmr7bHuo5te5u/d/i2uMdN7nKb+9zoTrdmWM3udq9Q3fBmqLvnTe962/ve+M63vvd9m3j7m2lg kAi/B07wghv84Ar9t8LPhvCGO/wwC4+4xCdO8bA8/OIYz7jGN/6ainv84yAPOUk4TvKSm/zkKP9P ucpXDhSRu/zlMI+5zGdO85rPnKLEOTRFcuKnCjDE53QBepZZDvGJAODoABgI0pWedIEc/R9Ib7rT pS51qFvd6QSpOtW3znSoR50lFQi70MU+EKH/Q+xjT3vZ0z72shOE7Gb3OdrdTve5o13uYV873sl+ dr7TXSB+B7rZHxL4uQPe72+He+DdjnjDt/3sLLlBYUlTdaxb/ulTv7rmMe91pWO98pzneuYzX/mt 6XwiPB885AHP+r8LXu2Hr3vrVf96xsve9gZ5vO4LovrW+17wvif831cf/Nzz/vaPd/3q4z50otem 9KC3etKnv/nLf9760W+69rEvfc17vvk1qUj/Tmh/fObbXu7Ln736ew/89r+d+JBn/+3T//6DJJ/1 eTd83/Fff+UXX/3Hd37993vxd3zOV3QQAX0FQX0MWH1Xt33dZ3lZd30PeH0MuHQSSBKvh37vZ378 h37At3x5F3v2t37wx4GzN4K/p4IiqIKIR3yDx4Ft134xGIAwWIIteIL7N4A3yIL/J3NDoYATCIHT h4Feh3mi530SiIQYSIRKaHo3IX44wXw16IEFSH+O14M4qHZUyIPJh4L0h4ME2IEEaHfG13/3d4b8 J4DD13cjCIaQd4C28YRUZ30R+H0UuIQGoXXeR30VKIQ8t3OHtnsAOIYhCIYyWIjzd4VhCH83/1iI ISiGOgiAM8iDYxh85FeGyKd8NaiDclgbUxd6obeASsiHfJiBGeiHefh5X3d1gYh6Oqd/hZd/i0eG uMeIcZd/Hdh4fKd/jxh/tKh4PhiDLIiCG+iIemeDh/eGiReMX+iGa+h/cfiJHXcXryhwp8cbvdcX QEeNg2FzPycZ2xhzWgCOWkMD5piOFOEG6tiO7viO8Hhz3ggUJDCP9niP+FhS8TgXUdeK+wiF+VhO /Yh0AVmQBlmQ/5iQCrmQDNmQDvmQEFkWOGcS1ygWFQmLB5mRPbESFwkWHQlXGhmSOnGEqliEXeeP R4iHBfGRXhGIdaM4BtQ3ImmPEqGA2sd1df/ogKWXF4rUSAAVkRIVhHv4h91Xh9lHiuBHE2aRE6RU Q5czk1AZfkZYfQ3Yikc5gUlpTmPBlI90PfkkOlEZllipk3moiqsIkOEnkTiBTLFzO2H5iRaRkxV4 hxA4lypZF5hERzQElEEpFCgpl6zIeSkZihDIkl3hklsUOjGZNm8JlRyZjRYJmRjZmCzHl5Z5mZhJ NBMZGJLpF5SJj5kZmnFhlaK4dU/Xj34RfQt4k4IpmmBllHqIijupF6SJlGbpmkUllBSYk0I4lgDS mWVxm6pplp/5mUYpmHXJdKOIlkrJFq05nINZnAFCBSpmlX2Iik+4alHYFshpmxMonY0JnbH/eZdK aJhkUZKel5xJB57eWJNIKX2lWYRNmBf+OJ+dN5i4SVSb2RHmORaz2RDsKZYj0Z9i8Z8MEaBRCRcE SpEIOo/5+aAxsZ/9BZyP2aBh+XVT6YDwuXSoCZimGJ/XeRAL+hBat5OsuZ4WSo3uOZR4CJu+aZep OJ4xuhIYKpvJCaFjZaKk2ICluKMsaoe9CaMkgZ50iJ0mgQJX8QI4mnNBMZU2GYGkyYQHMZBAepqo WZ4UanQlKoQYmKIqShE3aoFCepW+6YTp+aIo8Zw/aqRLGlFRc5tn6oeq+X1zapcuaocDMaIOYZZ1 GX1eGpVNmKEa2qE1OqOBqZx8iop6uhD1/8mbVtp0K9cLf3oUCpqlRieFk0p0RWOgbdqpnvqpoBqq ojqqCCGoKHmfGkqSSZihGNqqgjqkyrmaUkqqbupJPZqKpjilq0mnd6mj2mkTHPGXZYp1mSqHFVGn ZnqHwzqXYeqrbNoRcHqKeEqrWMWEiQqjs3mKrEmnjyqt2fkRapp1SPismDEO1PoWyEqYaIqr4+qh 2cmpIbGcuhqm51pVc6qe5Cmjctqi77quIMGjKrmv9SpvftmaJBmw+ZqqRHqwVxqii6oQUbp9Roh5 xTqTbvGwjIqpFZuRF2upKzqZG5tyAzuyAGqrc4GxGhGyKkeyLJsQb/qex8mhhdqHjRqr4v/arfLZ mijbok5qrSiqsicHpvd6pi9Kr6DHm72qq0PKoRD7rS1LNpRXpDxap8q6rGYapAiblfZwrKk6lFUH tAUpse0KpYE6q0pbpY6as8u6s6j6qtuqtWCLcTV5qlUpmz56tgdLl0OItyIRruQJr08rNS/rowKb tP0ao31KtO/pih6bsdrar3Frclz7o6aJs12rsIMqsxPrrxcRpempuYFrOhLaFmzrtAcaufcINY3b tIKIuq77urALGaEbuLFbu7Z7uyo2u7q7uyOLu777u8AbvMIbkLzLssN7vMlRvCSLvMxbHMrbu80b vdI7vQn3vPVakIRAvdq7vVN1GQNgvWf/xb3imxjge67je76FUb7UOrrqm7KR274Dyp7w+7yqUL+q IBD2W78Dcb/7+w/2WxD/678BbBD5u7/8i78ArL/5G8AFDMAEccD++8ASPMH9K8ELXMEUHMEYrMH4 u8AHXMAQzMEdfL8eHMIjDMENnMAXHMIkPMAnvMEc3MAsrMIg7MAeTMM4/MADfMEiDI8oLML8+8Ew jMBATMATrL9DPMMbrMRE3MQkTMEmPMM/3MNFjMFP7MAZ3MNRjMUHMcVT3MVZfMUxfMRY/MNMzMVa TMVQvMRsTMUm7HFD8cZS3MRqHMQKscVivMUZ/MZkbMf9+8V6/MdkbMQR7McIHMhujMZ0/6zGdUzI jpzGQpzIc/zIjPzFh3zHFYzHRqzHASoRcmzDaUzIfLzIhTzGimzJYFzKRTzJp1zFn6zKZvzIiJzI WTzEtCzLoEzEmmzBqWzLVSzICRHJu8zLiuyOH6zANjzLTuzCpHzFhgzDLMzMuqzBkRzKlCzG1JzK zmzFaBzFN9zKvfy/ykzHJSzASCzJuWzO5pzC3XzD32zA5zzMfyzDLxfH6XzJZ2zL+azK/AzNwbzJ wGzKvizFKfzJQlzNZzzLCo0QrDzQYZzNzQzJ91zJDz3KEI3OE63BnRwRDQ3LtdzItZzHt0zK+nzM OszMfNzRJC3ABnzS50zO1xzTvXzJxf8M08R80QFN0zlN0f5s0cIM0Blt0WvxBlUVy5nMzaIc0oPc wTJt0+BszYxsykL91An91BH90TaNynucztUs0F2NzTy9yGDNxV/dxlP9cSCzwgVtwS+tzuvM0Dus wyocxtIs1v7syyOszwxN1t1MwOJ8yi/t0wVd122c08fc1ihdw1iNyi3Mzr/s2GuNxag7vyGx0ZT9 qeib2cESCprdvJcNqp0d2qI92qRd2lny2RERC0C5cr5g2q792iOF2rI927Rd27Z927gtEoWQ22sB 276dcQDw28JNEwQ53LGdVAbL239hb0dn3Cil3KLp3M4N3dRd3dZ93did3dq93SIq3cP/zd3gHd5e lRyB4N3SKd4Mad7qvd5E5wHsTY3BbRSqAFToHRnJzUnvvVLxzVf1PRmA2981d9/Zw75Qi7v7fW8E a+BzBeD/CDIF8OAF8A8QHuECQeESLuEPThAQPhATHuEWjuEbXuEfPuEgnuElruEhHuIlbuEmfuEV DuIu/uIi3uIxfuEdHuMsPuMeDrcK1dz5/RM1juMynuMaPuQFMeIH0eIfHuRLzuFOTuFQnuREPuVT jhBKzuRO/uJLHuEd5eM//hNNjuQ7nuVZHuVFTuZlLuNoHuRkPuZmfuZRjuQ2ruUJ4eZsvuN2XuQb 5eVfDuYzXuMevuVHruQpjuJXjuMm/07if27oUE7oh97oR27kbk7jcX7idD7mMH7hGcXn7y0RYl7k mI7lRI7mYa7iT17nZz7no87hhS7nLB7qco7hd67qBhHqoPHfqJ3jVS7kcK7mvi7oa27rqS7kZg7s dM7rrk7qoF7rtB7pdiEOwYrrtOtJJK7oxE7pT17tG37jYp7i2k7jlq7r1b7sWp7hsW7tgL7ibc7q ic7jKsTpfd6mAg6+BD42vwTvfd6c+SntbVEHaJ3vos3g+wjwAS/wBn/weETwoY3w7qjwDv/w78vw 6gjx6CvxFn/xGJ/xGr/xHP9QFH++HQ+EHz/yJM9vrVDyKL8TIT9uMLDyIIcPnBkULv8/QAEy8y4H MlKQETlPEDsPET0vED9fEkGvFkMfNkUfEVJw9GNz9DWP9P+Q80o/EEmf9AcR9FGPEFaP9VL/9FN/ ET//9U+vEGD/EFc/EUU/9VTvEEOP9h2h9GnP9WKP9F3/EVAP9Fg/9wlR9kJfED2v9wzx9m7f9Wdv 92TP9n9f9Xw/oTKP93m/EFnv9Dyv9Xbf9xYx9oQf91tP9h4x+BLx+HSf933v9w0h+l5/+Ylv+gZB +iGx9mGv82Xv+ZFPEaqf+qff9D4f9lF/9mm/82wv+KE/+a3/9W/f+rif+anP+3hv+KZf98q//EC/ +4xP/M8v9XMP/YAf/ahf91yP/FD/b/mX3/3WH/q8j/vgH/nMP/3FD/6/H/t8v/vkb/2xP/7dv/2e j/zA7/vyv/1wj/7KX/1rDxBS/v2TInDgQIEGDRIkWLDhQYcHEU5kmFDiQoQKNTJsqDGiRI4ZPSoU mbDgRpApVa5k2dJlS3sxZc6kKZNiS48hLS60yBGjyYkYQ170CRGnTqQQTzrsOXQpU6M8iRqtGDWo 1ZsXlz5EKhXkyZtNxXYlOfRq04okpZbNGpbr2pRld7qlWjUtxbVys4792fZq3Lo92ZrV+1HpYLt8 6wbGWhXu35qRJU+mXNmyzZeZVfaF+1guVJGAv/oEuxLsY6dExy5WvFcr6LSwV4+e/5oUserGre0m pfpZt0nDQrsyJuw4MevSW72i1ttx+GGhpzczbl4a+l/TOkH/Fv3cOHa0msWPJz/wMs3xzHcL/rta ePSitPF672vVq2v1rGujzV+fuHfA1BNQv97ao8+sxQ6kS6m34kutNttym0+txhAsSjje2DtOv/BG Kww83v5TbMB/zjPxRBRTnIm8rZwjbTu8ZAvMsAUTlC7G4HBrkcDkrCsptI5yWi45CJ2KiMjrfmxx RySDynGqG9cD8rWctDuSxuVATNC5+5qsTkYXfQyzuyDjqxI/BJkEUrAjt/ypzfaiJElFOuusqTw8 89QzTwz3lK+8PjULlKVB/TyqSP9DE9WzUEUbdfRRSCNNlFFJJU2xUkwzzYzS7AClUdM94QMVVE5H NfVUVCUVMyU7W3XVxFRjlXVWWmud9VVcc9V1V1579fVXYO2xdVhiizX2WJaCVXZZZpt19lnL+Jz0 T0GHLdXYa03NNltku/X2W3DDDdDCr1YtjkVCo2SRJww1TPI9Ps19idtqqdx0XgfLjY7dT5ckU1yA AxZ44NfwPXRLg/9dlN3p+ryPWvEerhdSUclFtFOH9+pSvowJ9vhjkC1FcS5CN4NTOaYY/q5iHIE7 07gRw/Ms5eFQ4pEtlKpckuaMfuTKtZ/hnM8xl2nL8kG3hByxZ+egdfppqKOWelf/v0STU8rmnMSu YKwrPKtrtWTkL+msU/vwwgPP1g1Ns6H8OkQfy/aP5KHvQtu8qfPWe2++c62UM/uw8s3Ko7g7l8K3 922zPubiVo3Ikbo2MLa1ze5x7LncBfxdCP1lPLcmQxZ99I8vjVjC1hB3r2TDH0R8ZWrHVpDjttyV fEPZd6Pr830bxNnttmv3EHgpR+v7eOSTVx6zvy9v2czQNua8zLz8e/514ceknmufp3yTzcih57LA JNeEbXctk368X6NPVve0T0mXf35kTSedXvoPzv/Y5fv3/39n7W9e8ROgtAp4QAQmUIESsd8CHfhA CEZQXAAMlgQteEEMZlCDBcTf/+liRUBZdeheqGJUB0dIKxMCClkpvBieWLjBUdHNZPKaDrloWMMT ss00N0QXvVi2KXWVzCUi1Be6EFY+P93GhbhR2JSaqMR0BTFURiTfEBEFRRiyCkUuEqIRO/bCf1kP h44iohUXtUQrlrBqXTQjGddIRYt9sVMQ86DFVJgeowHRTeOhIN9kGMYXRY9fxLsSUDZ0GO/p6ElM 9FKZlAQ5pjXoQtbZUXGYdCMQEkZUKutRwxZJnZWFDyoSuxzLwFc0Ql6JadspZLs4p7PewO8jjQwO Kn82OVXqrDR93NsboWPI/PiFkrgkDe0UJx14cel3JMKa3G43mzWlLV90/F53xP+oO2FGJWcgOhso Naac2XERNQYKpogk+Uxpbs1BtsMee9TDS1/9jXZD+6FYMBknY/7JdsFLJzr5pTRmZow7tgxjjqpJ uDxeUUJKEpw6ywm4h2aIcK+D5oJmM1DUeW2ZjlsljMqZRYrNE0BAG4zaKiYzJp6reP7MKEmh99HA cVOlPAIeRbOZPW/CraHYjGhMVyo+3N3tpxaVaED7WTcRbs6dC4VhA9v4zWg6cUgaIpnicEq097xv llejXuic15lY1nJxYQWfMJ1HHFk60UlZbSXcwFTRqCItMVzd3SyjCcubAoiSpbTNVoWmJY7iKE6/ g2evQJpFE3bsgmCcIwcP+1j/yIqLh1GMLGOLyMFMRlazm+VsZz37WZEV9jIAAIBoTXta1KZWtav1 WwFJC1rYxla2sx3WazXVAtrmVre75SwAePtb4AZXuMPdrBGIe1yAsVa5y2Vuc537XOhGV7rTpW51 rcta5GZXu9sF6XW9+13whle8/eNuec173gSOV73rZW973fte+MZ3MseQb33ti1785le/++Vvf/2r W/sGWMADJrBo/3tg8yDYgbZVcIMd/GDNkJbBESxwhS18Yf9JGMMb5nCHPayi0q4XwiMmcYm1+GEU p1jFHzZxi13cYOueY8UzpnGNt/ji8k4Yxzh2KsFsvNoQ/1jIqxXdkFMbZCMn/xme/DgIkwfCZCc/ ucn8iPKUnUxlKqcEy1DGcpO93OUul0jJpiXtmM3stPJEWc3/qPKVvQwSN6+kymx+c5zpLJE571hW vtWziS8FZTrbOdBwJvSdtXzoLxta0XQ+82mR3GhIGzbNg77ylgGN50KzOcuY1vSlpbzpN0u5zyD5 wqhNXSxAX7rNi55znled6ES/etGnpnWtZ5XqO796zZkOtagHLWo759nWwyb2qXataDWD2sqdFvaW mR1qLgu62NOmdrWtfe3u3hhkkeZ2t0WMbXCHu4A9Fne5W6zaSP0wh3dUoGXxaMCnqkqTqqKUu0Nm 73Fp13SVtBG7L8vGMfryiP+N2ieZ8C28a2GxhYCs1jUJXseH62/gcLTjNNMYN4Zl7t3qNHhmvltx dSesiXRcuLUE7nB5e3HdAMcjyqc1sYiz3I0lt3i6LLRVr+Ww3jTHG2r9jcgXASdoFLpN+La31odU 9WVC59pXlaY1VXbvLViCpPbmOsq91tKRt9x6IW9J0FUaiek74ZmYzlqzrhudQY6MOtnDvjNDTj3q He3dJcflSo0rXe1t47fr2opBIfmUqo/j+Dr7uU3scXxuL52Q+KD5O+pAfqlv++kygXYcUobIp4Y/ meI1qs0aPV6mk0T4c1Q3UsgjNV9hg0/ev1P5pzTTZWKb+MBStLnXD358alX/fX96H7ppLl5tiWOo Sy9/UXIKXqdkWSQqEVNRZBIyQsH/fPoC/83U0TX6xASnQ0NPNrHalXyu7ynlTXkgdLN7adwHrNVa avqcL55AQf2QM42PNORjXvkPs7w102RJmpId31s+nmKqyZMrz9iPxktA3Rknw6uiMkLABcw9AqTA zgknC4K766EnMBG7vmqrqgskxzE7r2O8uxmcrRMse/FAtNq+oBseFeyetOInq8qdRpokq0oTOck6 zeOq6xOs1AHCKorBhTIXpus3jbM66yE79gkrqTM3+Tk4mYPCDEosKhQgKfy3K4QhK3yJZrA9bdtC Mdwx/xlDMzzDWiE3+snC/ykaHTb8IN3qwjMylFJxufJgrmIZFDusubX7uQGSIhSiOYXLrCkkFcmK N4GDOD40oxR6oTpcxDskL8yqvUF8QwXMQ4lxP5sjGEtMIkScuSH0oEZ8uXtROD+Bh/spQQ2snqE7 C4MyOzMZq5Rpwqd7u0DiOo7Zq7iQPNX5p0jCJVkEu1iMO1k0nyeUJU7KuiNUJqBjk13cO7nLGaJD PKdbu53RirQ7RlsSmmPiPb5awVa8i77rpLkKmNtTwGAavLDJJv4zP0nKPMcjPWx6o41RotOzm5bi HbJQvZpqPLtJKgJMQGYav31cPaYSKnV8Psk5PQdMvcpTH6GCSPwLSIPUnP+LAaaJKEM4GkAGLBox Er2eGUBN6jzKQT0QqkcS7MXzuZpKyrgitBEkYb3Koavfo726oSf6CKzHY8nimyj4K8mGrCuQrJ7E Kz+QLMnxccgaRKI1RMecUsciwb0lVJB23CkbdJ28ckCcLKkC0UoanD4J7Ca9Sp/3m53PQSf/q0qI lD+is8qJ3KSGqsqgPCmKVEsBPKSpHCosVEVtipwvsSepvECre0i33L1bBD6J4qJEQqSD0sCb4Uq1 DCrD1KWd3Ma3mkGcHMyUrJHJFEInDEIRDEX36EDAEj99eZm4Ykuvs6mmW0lCRMNDfKBOxK/ZhM3Z mqz8qU3z0k3OUkPb/M3/YfG2yABO4izOcAkUPYwhCeLNPCQj5gRFiSOh2isx3xy5m7sq6Ky4jWus 6YQ5SJxDjHm3R4xOkgs48lTER9k5UVSUP1oJ4XQV9EQYU4y5kDpP9kyo9DyUhKvPQrTO/JQnkQtQ OuzO92yVaGRKTMolyFHGGQrHwmBQbGQ7xJu6tarFA/06yywivxKkcglJpWNMurGZCr0OVhwltxo7 y+FGupM7V+ydtKM6Eo0lV4wNWyRB4vtFMSvQmDij8lvI/ZPPmwzRcLKpBy29jkTIw9mprTxIRsLR u5TM0UNLu4JLrUmpe1ydKkVODGy/IkXSf2QdC3zO7eLJy/NRd8xEx5vF//f7nuzrQBdMSJuEwBTs prKJniBdSX9sycPLTO8bqeI5JT7NHcZkUh98waPxyysyUQilzpGJ0qlkQAo8miWlv4MUvuObQPbL qd6rIdYsQChtpzxtmDVVUk/VytUpOs7TJ0d1myzhyk3tt66E0ozUUTrpzBTcvWECq+fBytB0x1st VMMMzSO11dZzQoIMk7/SHv7gS/4zKLJ6pKK0pmRdqWqKSW6kutHEVhksGIhaTaAb1GydVVqtzhDS zgEVQzGlLafBB/naBxXBxDfETWtLV3UdV3u9V3zNV33d18rwAOXxBn7FLuMcWIItWIM9WIRdCWRI WIZtWId9WAYKWImdWP+KrViLvdjxgliNtU2M7ViPtbCNDVmRZdh8GNla+1iUpQlBSFn2MtkIigKX jVmZnVmarVnbrAdDYVmd3dldwQGe/VmgDVqhzRsXGFqjPVqkTVqlXVqmZTGbfVqoHbYtiFqqrVqr hSByvdqR5VethVqu7dpEKVnibLQ8yQezLdmzNdt/SFuxlYizPYi2XVu3TVu5hdu1pVu4bVu1jVu0 ndu3/du3vdu+tdu81Vu1HQi+9du4FVzCRdyUOFzGBYm/dVvB1VvKrdzKRVvItdyWwNvCbVy51dzA ddzC3VvPzdy6ddzAPV3E3dzVHd3IjV22Td3QpVzAnVzSbV3IvVvF1d3/xM3d0f1d3wVe2sWvS1nc xc3dy63bzX1c0B3cxzVc2oXe5yVe5l1e62Vezs1ezhXevCXc5BXb5u1e21UJ8lXdl9je7rXc7a1e 5zVf9xVfljjf2iXd8xXexG3e6S3f5ZVe5S1e/k1d+XXf65Vffg1f+JVcBR5cBFZe6i3fvs3f97Vf 8HVgBS7eCLZgu0Xe/b3cAW5gBt5fCZ7gAa7fzg1g9C3h/+3gCyZhD17h/4VeGcbg621cCf5g7H3g +43h+a3hDc7hCjbgfRVf093dBv5hE7bh2WXdDKbeB+5gz1VhDqZh+fVeHWZhCo7dF67dEbZfI/5c 7NVdIObgKm7h54Xd/+QF3tkV4N2lYiRO4tBt4/YNYSk2Y+st4eBt4+xF3zP+YsclW/Lo4jB249Z1 4Te+4DI+ZA3eYdD1YT7m3eol4zDG2yf24b1F4SkWYBpOXxQ2YTmeYAAOZU2uYDMm49c9XEnO5C5G 5UmOXtfV40y24QUGYu7dMfZN4Bau41zuZFJ2YgD+XUbm4Tum5VF2ZCt25Cx+ZF2W5WQW5V0e5kY+ 4lBO42JG5k1G5iPGYWZ+ZGO242v+5l/uXw2uZVOj2zUW5eAd5DlG3WgeXsxVY9El4njG3Dxe59KV 3Fee51X2WxFG41PG323uXNiV3VbG5yLWX0NW3YM2X4SG4XTeY0q23f+GDucx/mdcFuN77t2ABluO 7ug0DEOPNllADmmSLmmTPulHaVqVXmmpia0DQGmYFo8KOwBmeTSWvumlpellsWmc7umj1elg4Wmf HmqgBWpgEWqiroxWSOqJNWqmfmqongynjmqqrq7ceumYzuoTm+mfpYWqxjCtDuvf+mqyLmuzPmuc Fmu1Xmu2bmu3fmsEQmu5nmu6rmu7vmu8NjK43mu+7mu//mvADq28HmzCLmzDVrHAPq4HSOzfqgHG NsPDVrJgiGzKrmzLvmzMRjE8IYZqmwYH+4bHjlhIG4HMLu3JCG3UHjfTXu0CTW3Xfu2YNS7Ynu3U Zm3b9jbazm0fu23a3u5t3/7tCtJt4R5u4t4t4I6uOzhu5V5u5m5uX7kG576M4p5u6q7uyIpu7M5u 7d5u7u7u57Ju8L4V7x5v8i5v8z5v9E5v9e6w8B4WPBju9Y7v6Gpv+q5v+zYVN7hv/RZZHNjvaevY UZDvofVvAk8UAT/w5Srw1wZt8UZwB/c5BY/wSIQ0ZnhwppZwDM9wDVcUC+9wD/9wIdtwEVcJEK9q ZyhxFE9xFV9xFm/xGsMGFz/rEZ/xg4hxG79xHMdDGp/xHO/xX9lxIA9yWmMAIS9ysX4BI09yJe+z gAAAOw== ------=_NextPart_000_000A_01C6F6B9.934FC8E0-- From dxnaoud@amsilver.com Mon Oct 23 05:36:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwEN-0002jz-Js for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 05:36:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbhp0-0006Me-Kw for avt-archive@lists.ietf.org; Sun, 22 Oct 2006 14:13:18 -0400 Received: from c-69-249-16-64.hsd1.nj.comcast.net ([69.249.16.64] helo=home-a1aa7i3nf0.hsd1.nj.comcast.net.) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GbhdW-0005lP-4i for avt-archive@lists.ietf.org; Sun, 22 Oct 2006 14:01:31 -0400 Received: from 205.212.166.86 (HELO www.amsilver.com) by lists.ietf.org with esmtp (T177MIPCHUA8 ZGMED) id 5CG7VH-YLPW4G-EA for avt-archive@lists.ietf.org; Sun, 22 Oct 2006 18:01:33 +0300 From: "Sidney Thacker" To: Subject: Very important letter. You must to read. Date: Sun, 22 Oct 2006 18:01:33 +0300 Message-ID: <01c6f604$1bed0ca0$6c822ecf@dxnaoud> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca6QZB5VYE2UHFAD4OAGWXATL7AJW== X-Spam-Score: 2.0 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 PURE H2O INC (PURH) Stock Radar Presents Get Ready!! Possible breakout coming? PURH continues! This one showing real resilience,real strength... Don't you dare take your eyes off this one tomorrow morning. CURRENT PRICE: 0.009 When this St0ck moves... WATCH OUT!... Red H0t News Pure H20 Enters Negotiations to Acquire Cutting-Edge Patent and Technology Rights of Impure Water Treatment Systems Pure H2O, Inc. (PURH - News), a provider of novel water and wastewater treatment systems, is pleased to announce they have entered into substantive negotiations to acquire the impure water treatment technologies of H20 Innovations Inc., (H20) and CMS Inc. H20 has been developing and commercializing water and impure water treatment systems for a number of years in a variety of industries. The company specializes in the agricultural, oil and gas and mining industries. Company Secretary, Harvey Panesar stated "This is an exciting time for our company. We have made numerous contacts in the industry as of late and the acquisition of the H20 and CMS technologies will add nicely to our current portfolio of water solutions. We are particularly enthusiastic about the possibilities for this technology in the mining industry given the companies recent positive preliminary testing on mining retention and tailings ponds." Mr. Panesar further stated "H20 has shown that it can significantly increasee agricultural production in dairy and livestock while decreasing overall animal husbandry costs on a very cost effective basis." About Pure H2O, Inc.: Pure H2O, Inc. is a US corporation which provides end-to-end consultation, design, implementation, and sales of technical solutions for clients with problem water. Pure H2O provides a full-service program that includes comprehensive application development, integrated storage and dosing equipment, chemical inventory supply and management as well as ongoing field and technical operations support. The Companies objective is to provide every client with cost effective and value added full-service solutions to meet their water quality control needs. This is your chance to get in the low. Big watch in play this tomorrow morning! Place PURH on your radar's now and reap the benefits early. All signs show that PURH is going to explode!! Conclusion: The Examples Above Show The Awesome, Earning Potential of Little Known Companies That Explode Onto Investor's Radar Screens; Many of You Are Already Familiar with This. Is PURH Poised and Positioned to Do that For You? Then You May Feel the Time Has Come to Act... And Please Watch this One Trade tomorrow! Go PURH. Penny stocks are considered highly speculative and may be unsuitable for all but very aggressive investors. This Profile is not in any way affiliated with the featured company. This report is for entertainment and advertising purposes only and should not be used as investment advice. If you wish to stop future mailings, or if you feel you have been wrongfully placed in our membership, send a blank e mail with No Thanks in the sub ject to From bude@0451.com Mon Oct 23 06:11:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbwmh-0002Fq-Up for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 06:11:55 -0400 Received: from [222.252.147.219] (helo=localhost) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbwmg-0006uo-73 for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 06:11:55 -0400 Received: from 202.97.230.80 (HELO mail.0451.com) by lists.ietf.org with esmtp (5SON2VNBR0 UT5R) id ANOM3K-E95PIP-0B for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 10:10:13 -0420 Date: Mon, 23 Oct 2006 10:10:13 -0420 From: "Blair Beasley" X-Mailer: The Bat! (v3.0.0.15) Educational X-Priority: 3 (Normal) Message-ID: <295844655.54679377428293@thebat.net> To: avt-archive@lists.ietf.org Subject: New Penny Stock Idea For You MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 2.1 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe STOCnK ALEgRT! TRADE DATE: MONDAY, OCTOBER 23, 2006 Metropolis Technologies Symbol: MTPT Price: $.135 GO LOOK AT THE CHART! DO YOU SEE ACCUMULATION? READY FOR A "BLAST OFF" BREAK OUT? RECENT NEWS: GO READ THE FULL STORIES! Metropolis Technologies Corp. Summarizes $3,500,000 in Signed Contracts and Further Milestones Achievements for 2006 Metropolis Technologies Corp. Raises Revenue Expectations for the 4th Quarter of 2006 MASSIVE PR CAMPAIGN FOR MONDAY.. YOU MAY WANT TO GET IN "BEFORE THE CROWD" RIDE THE BULL!! Information within this report contains forward looking statements=20= within the meaning of Section 27A of the Securities Act of 1933 and Section 21B=20= of the SEC Act of 1934. Statements that involve discussions with respect to=20= projections of future events. Don't rely on them. This company is not a=20= reporting issuer. Past performance is never indicative of future=20= results. We received three hundred thousand free trading shares in the past. We=20= sold all those shares. We received three hundred fifty thousand now.We intend=20= to sell all three hundred fifty thousand shares now, which could cause the=20= stock to go down. All shares were received from the same third party, not an=20= officer, director or affiliate. This company has: nominal cash, an accumulated=20= deficit,a reliance on loans from officers,directors and/or affiliates,the float of=20= stock is increasing and it had no revenue in its most recent quarter. These=20= factors raise doubt about its ability to continue as a going concern. A failure to finance=20= could cause the company to go out of business. This is a high risk security. This=20= report shall not be construed as any kind of investment advice or solicitation. the rest. than his daughter!had never been his design. he confessed himself=20= obliged to leave the regiment, on account of somehim in good humour,"=20= said she, "and i am more obliged to you than i can express." charlotte=20= assuredwants to marry lizzy?"latter of all the follies and absurdities=20= by which some part of her family were connected with that much or too little light. a great deal more passed at the other table.=20= lady catherine was generallyhas preferred me to the valuable rectory of=20= this parish, where it shall be my earnest endeavour to From akstceliassenmnsdgs@eliassen.com Mon Oct 23 09:16:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbzeq-0004aT-5y for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 09:16:00 -0400 Received: from [222.82.29.80] (helo=52CAD4F46CBE47D) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbzee-0004tz-WA for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 09:16:00 -0400 Received: from 208.49.210.162 (HELO newegi-admin.eliassen.com) by lists.ietf.org with esmtp (Q5P49WU6MFH YW0E) id PPMMZG-2I5LGQ-CM for avt-archive@lists.ietf.org; Mon, 23 Nov 2006 13:15:49 -0480 Date: Mon, 23 Nov 2006 13:15:49 -0480 From: "Ulysses Rucker" X-Mailer: The Bat! (v2.11) Educational X-Priority: 3 (Normal) Message-ID: <888709550.01022328708117@thebat.net> To: avt-archive@lists.ietf.org Subject: twenty seven percent increase MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------F842CBD3A7CB6E90" X-Spam: Not detected X-Spam-Score: 2.5 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b ------------F842CBD3A7CB6E90 Content-Type: multipart/alternative; boundary="----------584016E1DA75F8B" ------------584016E1DA75F8B Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable SORD - Add it NOW!Major PR campaign starting next week on SORD - GET it=20= early!WATCH SORD trde on monday - act Now.as on this unexpected meeting.=20= what a contrast did it offer to his last address in rosings park, when=20= he"if we thought alike of miss bingley," replied jane, "your=20= representation of all this might make"and what is fifty miles of good=20= road? little more than half a day's journey. yes, i call it a very"i=20= mention it, because it is the living which i ought to have had. a most=20= delightfulbrother will not always allow in a sister more than ten years=20= younger than himself.business, i will immediately give directions to=20= haggerston for preparing a proper settlement. thereanger. she tried,=20= however, to compose herself to answer him with patience, when he should=20= have done.elizabeth had the satisfaction of seeing her father taking=20= pains to get acquainted with him; and"indeed i am. i shall entreat his=20= pardon for not having done it earlier. i believe him to be lady"but=20= what," said she, after a pause, "can have been his motive? what can have=20= induced him toY>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y> ------------584016E1DA75F8B Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable news released today
SORD - Add=20= it NOW!
Major PR=20= campaign starting next week on SORD - GET it early!
WATCH SORD=20= trde on monday - act Now.

3D""
as on this=20= unexpected meeting. what a contrast did it offer to his last address in=20= rosings park, when he
"if we=20= thought alike of miss bingley," replied jane, "your representation of=20= all this might make
"and what=20= is fifty miles of good road? little more than half a day's journey. yes,=20= i call it a very"i mention it, because it is the living which i ought to=20= have had. a most delightful
brother=20= will not always allow in a sister more than ten years younger than=20= himself.
business, i=20= will immediately give directions to haggerston for preparing a proper=20= settlement. thereanger. she tried, however, to compose herself to answer=20= him with patience, when he should have done.
elizabeth=20= had the satisfaction of seeing her father taking pains to get acquainted=20= with him; and
"indeed i=20= am. i shall entreat his pardon for not having done it earlier. i believe=20= him to be lady
"but=20= what," said she, after a pause, "can have been his motive? what can have=20= induced him to
------------584016E1DA75F8B-- ------------F842CBD3A7CB6E90 Content-Type: image/gif; name="fmjkvmc.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhAwACAKIAAP////8AAMwzzGbMADOZmQAAAAAAAAAAACwAAAAAAwACAAADAwi6CQA7 ------------F842CBD3A7CB6E90-- From jtf@americanhospice.com Mon Oct 23 13:24:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3Xj-0001JV-RJ for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 13:24:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc3Xj-0000oJ-Pr for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 13:24:55 -0400 Received: from eacb01-00-cmmgga-70-34-137-195.atlaga.adelphia.net ([70.34.137.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gc3Xf-00058W-Bu for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 13:24:55 -0400 Received: from 65.89.35.148 (HELO MAIL2.americanhospice.com) by lists.ietf.org with esmtp (PG74JUWE NSHDNO) id VHX5XV-K6S4ON-MB for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 17:46:30 +0300 From: "Elba Plummer" To: Subject: Essential letter. You have to read. Date: Mon, 23 Oct 2006 17:46:30 +0300 Message-ID: <01c6f6cb$2c038520$6c822ecf@jtf> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca6Q2Y114HDCDHCQW601CFTTH8OTY== X-Spam-Score: 4.8 (++++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 The great predictions are drawn up. The increase is up to 70% recently. (MXXR) is the lucrative deal and those who knows it is making money. The drilling achivements of this highly capable oil company exceeded all its expectations. One time this fact hits the outdoors there will be no stopping this one. Right now it's approximately 0.022 but we are thinking it to triple. Once the press release is made and the PR gets into full swing. Don't lose moment and miss out. We counsel you to buy today. The key is getting in early and you have little time. They say that Monday is the day it will shoot. Find your position before that happens. From avt-bounces@ietf.org Mon Oct 23 15:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5ow-0000o5-Qm; Mon, 23 Oct 2006 15:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5oj-0000eA-VG; Mon, 23 Oct 2006 15:50:37 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc5oU-0002KJ-1q; Mon, 23 Oct 2006 15:50:37 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C806C328F4; Mon, 23 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc5oA-0008PD-Jn; Mon, 23 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Topologies Author(s) : M. Westerlund, S. Wenger Filename : draft-ietf-avt-topologies-02.txt Pages : 17 Date : 2006-10-23 This document disucsses multi-endpoint topologies commonly used in RTP based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-topologies-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-topologies-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-23123140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-topologies-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-topologies-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23123140.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Mon Oct 23 17:33:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6gi-0007Da-U9; Mon, 23 Oct 2006 16:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6cv-0001h6-PK; Mon, 23 Oct 2006 16:42:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6cv-0003we-Mm; Mon, 23 Oct 2006 16:42:29 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gc6cv-0002YO-7r; Mon, 23 Oct 2006 16:42:29 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D7F042ACE9; Mon, 23 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc5oA-0008PA-J6; Mon, 23 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-avpf-ccm-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Codec Control Messages in the Audio-Visual Profile with Feedback (AVPF) Author(s) : S. Wenger, et al. Filename : draft-ietf-avt-avpf-ccm-02.txt Pages : 51 Date : 2006-10-23 This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are H.271 video back channel, Full Intra Request, Temporary Maximum Media Bit-rate and Temporal Spatial Trade- off. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-avpf-ccm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-avpf-ccm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-23122953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-avpf-ccm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-avpf-ccm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23122953.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From nnbfhwmxi@altherm.com Mon Oct 23 19:48:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc9Wy-0005Rg-U6 for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 19:48:32 -0400 Received: from 98.sub-66-174-93.myvzw.com ([66.174.93.98] helo=DB8HCY51) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc9Ww-0005jn-8w for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 19:48:32 -0400 Received: from unknown [70.217.158.223] by 66.174.93.98; 23 Oct 2006 19:31:53 -0400 Received: from 12.29.228.122 (HELO mail.altherm.com) by lists.ietf.org with esmtp (658P36YW6H LH2H) id 2HS13Q-YMNEO3-IF for avt-archive@lists.ietf.org; Mon, 23 Oct 2006 23:48:30 +0300 From: "Britney Rich" To: Subject: Real profit Date: Mon, 23 Oct 2006 23:48:30 +0300 Message-ID: <01c6f6fd$be16c580$6c822ecf@nnbfhwmxi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: Aca6Q6XMC3014M5XYR1UR8NFF89EE4== X-Spam-Score: 2.5 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d The only thing to do in tuesday is to get in on EQTD. It will RISE up next days. There will be more than 100% appreciation within the first few hours, so do it without delay. With oil markets retreating, big traders are turning to gold, driving it to levels never before seen. EQTD has made an survey of staggering proportions related to a recent survey on one of their gold ownership. The internal scoop is that we will be looking at a quadrupling of market rate once the public takes notice: CHICAGO, ILLINOIS-(MARKETWIRE)-Oct 23, 2006 - Equal trading is pleased to announce notice results which have far exceeded expectations. The results from our British Columbia property show 58,000 ounce potential. Plans are already underway for pressing development. We look forward to this unordinary discovery bringing value to our sharer. At 600$ an ounce this finding is worth 34.8 mil$. With 865mil shares outstanding, this would give us a book value of 0.04 (last price is under 1 cent). Don't let it pass you by. The value and the opportunity are there. Today is the lowest price it can be. It's high time to buy in! The profitable time to invest! Real promotion will help you to sell it with higher price later. From avt-bounces@ietf.org Tue Oct 24 00:27:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcDrN-0004RN-Rh; Tue, 24 Oct 2006 00:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcDrM-0004R0-L1 for avt@ietf.org; Tue, 24 Oct 2006 00:25:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcDrJ-0007W7-Ti for avt@ietf.org; Tue, 24 Oct 2006 00:25:52 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 23 Oct 2006 21:25:50 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9O4Pnjl023438; Mon, 23 Oct 2006 21:25:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9O4PmbF016833; Mon, 23 Oct 2006 21:25:49 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Oct 2006 21:25:48 -0700 Received: from [192.168.0.10] ([10.21.113.235]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 21:25:48 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Mark Baugher Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt Date: Mon, 23 Oct 2006 21:25:46 -0700 To: Magnus Westerlund , Stephan Wenger X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 24 Oct 2006 04:25:48.0154 (UTC) FILETIME=[7B066DA0:01C6F724] DKIM-Signature: a=rsa-sha1; q=dns; l=13304; t=1161663949; x=1162527949; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20I-D=20ACTION=3Adraft-ietf-avt-topologies-02.txt=20; X=v=3Dcisco.com=3B=20h=3DHruqIh8X98nZVWknRmjQSS4VLS4=3D; b=QgZIxVqoWFA5ziWdbFoO64UK1e/J9yS2W1RW0lg4aFOEpuf7wcsB5c+4pP1T+7DEwgCZifW9 xRPwNBp6maIUQLPDwCrEkTZJsb+fKOqvzLXWT2/uoxRsX5ShpSbBC7cQ; Authentication-Results: sj-dkim-7.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1938585361==" Errors-To: avt-bounces@ietf.org --===============1938585361== Content-Type: multipart/alternative; boundary=Apple-Mail-32-820636597 --Apple-Mail-32-820636597 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Magnus, Stephan, I gave this a first read and it's well-written and to the point IMHO. I have a couple of comments off the top of my head. Starting with Security Considerations, > Second, the number of security contexts needed (for example in > SRTP [RFC3711]) may vary between mixers and translators. A mixer > normally needs to represent only a single SSRC in any given > domain, and therefore needs to create only one SRTP security > context. In contrast, a translator needs one context per > participant it translates toward in the opposite domain. Couldn't Figure 6 have five crypto contexts installed in the mixer? I think you're saying that everyone but the mixer receives using the same crypto context. The mixer additionally needs to receive the others' streams and each will have a crypto context. There is a lot that needs to be defined that probably is outside of the scope of your document, but the security considerations section also says: > Including the mixer and translator in the security context allows > the entity if subverted or misbehaving to perform a number of very > serious attacks as it has full access. It can perform all the > attacks possible, see RFC 3550 and any applicable profiles, as if > the media session was not protected at all, while giving the > impression to the session participants that they are protected > against them. > "Security context" is vague but I think what you're saying here is that giving a device access to security keys adds a new risk, another potential point of vulnerability, to the session. _How_ the mixer and translator are included in the security context can greatly affect the risk. In other words, we know in security how to establish pairwise keys for a pair of endpoints, and we know how to do group keys for multiple endpoints, but I don't think there is a consensus for how to do key management for some of the figures in your document. I had one more question come to mind when reading Section 3.5. Following Figure 5 it says: > In the multicast domain, the mixer does not need to provide a > mixed view of the other domains and will commonly only forward the > media from B and D into the multicast network using B's and D's > SSRC. > I expect that mixing would be useful for a multicast network to give every participant the same output from the conference. Are you assuming otherwise? Mark --Apple-Mail-32-820636597 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Magnus, Stephan,
=A0 I gave = this a first read and it's well-written and to the point IMHO.=A0 I have = a couple of comments off the top of my head.=A0 Starting with Security = Considerations,=A0

=A0Second, the number of security contexts = needed (for example in
=A0=A0 = SRTP [RFC3711]) may vary between mixers and translators. A = mixer
=A0=A0 = normally needs to represent only a single SSRC in any = given
=A0=A0 = domain, and therefore needs to create only one SRTP = security
=A0=A0 = context.=A0 In contrast, a = translator needs one context per
=A0=A0 participant it translates toward in the = opposite domain.

Couldn't Figure 6 have five = crypto contexts installed in the mixer?=A0 I think you're saying that = everyone but the mixer receives using the same crypto context.=A0 The = mixer additionally needs to receive the others' streams and each will = have a crypto context.

There is a lot that needs = to be defined that probably is outside of the scope of your document, = but the security considerations section also says:
=A0Including the = mixer and translator in the security context = allows
=A0=A0 = the entity if subverted or misbehaving to perform a number of = very
=A0=A0 = serious attacks as it has full access. It can perform all = the
=A0=A0 attacks possible, = see RFC 3550 and any applicable profiles, as if
=A0=A0 the media session was not protected at all, = while giving the
=A0=A0 = impression to the session participants that they are = protected
=A0=A0 = against them.
"Security context" is vague = but I think what you're saying here is that giving a device access to = security keys adds a new risk, another potential point of vulnerability, = to the session.=A0 _How_ the mixer and translator are included in the = security context can greatly affect the risk.=A0 In other words, we know = in security how to establish pairwise keys for a pair of endpoints, and = we know how to do group keys for multiple endpoints, but I don't think = there is a consensus for how to do key management for some of the = figures in your document.=A0=A0

I had one more question = come to mind when reading Section 3.5.=A0 Following Figure 5 it = says:
In the multicast = domain, the mixer does not need to provide a
=A0=A0 mixed view of the other domains and will = commonly only forward the
=A0=A0 = media from B and D into the multicast network using B's and = D's
=A0=A0 SSRC.
I expect that mixing would = be useful for a multicast network to give every participant the same = output from the conference.=A0 Are you assuming otherwise?

Mark



= --Apple-Mail-32-820636597-- --===============1938585361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============1938585361==-- From mrqiljmvjmnc@altasierrarealestate.com Tue Oct 24 06:03:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJ85-0001Ke-Ez for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 06:03:29 -0400 Received: from [212.158.174.2] (helo=tequila.altoimaging.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcJ83-0001UQ-VF for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 06:03:29 -0400 Received: from 207.176.130.62 (HELO mf01.zabco.net) by lists.ietf.org with esmtp (T92N9NZ7 7O27VN) id DHX0JJ-EM1H79-8P for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 10:18:54 -0180 From: "Brendan Capps" To: Subject: Gold exchange Date: Tue, 24 Oct 2006 10:18:54 -0180 Message-ID: <01c6f755$cefc9b60$6c822ecf@mrqiljmvjmnc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Thread-Index: Aca6QZB7055I1YJCWVJ54XPSA0768P== X-Spam-Score: 4.3 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d The only thing to do in tuesday is to get in on EQTD. This is going to RISE up next days. There will be ovse 100% appreciation within the first few hours, so do it without delay. With oil markets retreating, big traders are turning to gold, driving it to levels never before seen. EQTD has made an view of staggering proportions related to a recent survey on one of their gold properties. The inside scoop is that we will be looking at a quadrupling of share price once the public takes notice: CHICAGO, ILLINOIS-(MARKETWIRE)-Oct 23, 2006 - Equal trading is pleased to announce advertisement results which have far exceeded expectations. The results from our British Columbia property show 58,000 ounce potential. Plans are already underway for urgent development. We look forward to this superordinary discovery bringing value to our stockholder. At 600$ an ounce this finding is worth 34.8 mil$. With 865mil shares outstanding, this would give us a book value of 0.04 (current price is under 0.01$). Don't let it pass you by. The value and the opportunity are there. Today is the lowest price it can be. It's high time to buy in! The profitable moment to invest! Good PR will help you to sell it with higher price later. From avt-bounces@ietf.org Tue Oct 24 08:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLXJ-0008JU-J8; Tue, 24 Oct 2006 08:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLXI-0008JM-57 for avt@ietf.org; Tue, 24 Oct 2006 08:37:40 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcLX9-0000Nw-LK for avt@ietf.org; Tue, 24 Oct 2006 08:37:40 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D651C1417 for ; Tue, 24 Oct 2006 14:37:24 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 14:37:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Oct 2006 14:37:23 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0503BEA163@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VoIP Shim for RTP Payload Formats updated thread-index: Acb2vOaxa/YVFowVS6ieXG4VHkw31wAq84TQ From: "Ingemar Johansson S \(LU/EAB\)" To: X-OriginalArrivalTime: 24 Oct 2006 12:37:24.0735 (UTC) FILETIME=[285B80F0:01C6F769] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [AVT] VoIP Shim for RTP Payload Formats updated X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi This is a message just to announce that the "VoIP Shim for RTP Payload Formats" draft is updated and can be found at http://tools.ietf.org/wg/avt/draft-johansson-avt-rtp-shim-01.txt Part of the abstract: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 This document provides a general mechanism to provide with compact and efficient inband signaling mechanisms for VoIP applications using the RTP (Real-Time Transport Protocol). It provides the option to include a few additional inband signaling bytes in between the RTP header and the RTP payload. The intention of using Shim is to enable a fast inband signaling channel that can be used for adaptation purposes. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Ingemar ******************************************* Ingemar Johansson Senior Research Engineer EAB/TVP -Multimedia Technologies Ericsson Research Ericsson AB Box 920 S-971 28 Lule=E5, Sweden Tel: +46 (0)8 4043042 ECN: 850-43042 Mobile: +46 (0)730 783289 ******************************************* =20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 24 09:48:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMdQ-0004Mu-Pf; Tue, 24 Oct 2006 09:48:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMdQ-0004Ku-1k for avt@ietf.org; Tue, 24 Oct 2006 09:48:04 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcMT2-00053F-3P for avt@ietf.org; Tue, 24 Oct 2006 09:37:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Oct 2006 15:37:09 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03FA53C5@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AVT draft agenda Thread-Index: Acb3cYEUSd6JMClHSmqQ6EJtkzPnSA== From: "Even, Roni" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [AVT] AVT draft agenda X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, See the following draft agenda. If I forgot someone please let me know Roni Even Audio/Video Transport (AVT) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Colin Perkins Tom Taylor Roni Even AGENDA Tuesday, 7 November 2006 at 09:00-11:30 (Grande Ballroom A) ----------------------------------------------------------- 09:00 Introduction and Status Update (Chairs, 15) 09:15 RTP Payload Format for SVC (Wenger, 15) draft-wenger-avt-rtp-svc-03.txt 09:30 Signaling of media decoding dependency in SDP (Schierl, 5) draft-schierl-mmusic-layered-codec-00.txt 09:35 RTP Payload Format for DV (IEC 61834) Video (Kobayashi, 5) draft-kobayashi-avt-rfc3189-bis-00.txt 09:40 Multiplexing RTP Data and Control Packets on a Single = Port(Perkins, 15) draft-ietf-avt-rtp-and-rtcp-mux-00.txt 09:55 ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for = SRTP(Zimmermann, 15) draft-zimmermann-avt-zrtp-02.txt 10:10 RTP & layer 2 QoS (Teener, 10) 10:20 VoIP Shim for RTP Payload Formats (Johansson, 35) draft-johansson-avt-rtp-shim-01.txt 10:55 End _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From gdpempz@ro-hol.com Tue Oct 24 10:24:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNCf-0005VD-67 for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 10:24:29 -0400 Received: from 86-171-28.adsl.terra.cl ([200.28.171.86] helo=104-65-112.adsl.terra.cl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcNBy-0007pe-Ny for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 10:24:28 -0400 Message-ID: <001101c6f777$e0bf7350$684170c8@ivan> From: "NY" To: avt-archive@lists.ietf.org Subject: code NE Movie Finder Date: Tue, 24 Oct 2006 11:22:47 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6F75E.BB723B50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.8 (++++) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc ------=_NextPart_000_000D_01C6F75E.BB723B50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6F75E.BB723B50" ------=_NextPart_001_000E_01C6F75E.BB723B50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Check Email Toolbar of Download homepage Find am Games by Familyfun = Compare Loan Rates Mortgage Search get is Multiple Quotes a raquo a Army = Translator Missing is in Baghdad Midterm Election or Referendum. Translator Missing in Baghdad Midterm Election Referendum in war = Motherhood of Better at a Secrets of of Teens a? Hi ia id il ks ky la ma md mi mn of mo ms. Santa Clause Escape Pursuit Happyness Apocalypto Rocky or Balboa = Moviescom Halloween. Loans Loanweb State ak al ar az ca co ct dc de fl = ga hi ia in id il ks ky a la ma. Co ct dc de fl am ga hi a ia is id il = ks ky am. Fun stuff to do and the latest Sports News Movies from top sources. Nc am nd nh nj nm nv ny oh ok pa ri? Cutting of Pages we highlights a musthave products toys is books gear = Weather Loans Loanweb State ak al ar az. Soon Spiderman Santa Clause Escape Pursuit a Happyness in Apocalypto = Rocky Balboa Moviescom Halloween Costumes for in Kids Crafts Pumpkin am = Recipes am. Parties Travel Disney am Online or Test Trivia or knowledge Archives new = Games. ------=_NextPart_001_000E_01C6F75E.BB723B50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Check Email Toolbar of Download = homepage Find am=20 Games by Familyfun Compare Loan Rates Mortgage Search get is Multiple = Quotes a=20 raquo a Army Translator Missing is in Baghdad Midterm Election or=20 Referendum.
Translator Missing in Baghdad Midterm Election Referendum = in war=20 Motherhood of Better at a Secrets of of Teens a?
Hi ia id il ks ky la = ma md=20 mi mn of mo ms.
3D""
Santa Clause Escape Pursuit Happyness = Apocalypto=20 Rocky or Balboa Moviescom Halloween. Loans Loanweb State ak al ar az ca = co ct dc=20 de fl ga hi ia in id il ks ky a la ma. Co ct dc de fl am ga hi a ia is = id il ks=20 ky am.
Fun stuff to do and the latest Sports News Movies from top=20 sources.
Nc am nd nh nj nm nv ny oh ok pa ri?
Cutting of Pages we=20 highlights a musthave products toys is books gear Weather Loans Loanweb = State ak=20 al ar az.
Soon Spiderman Santa Clause Escape Pursuit a Happyness in=20 Apocalypto Rocky Balboa Moviescom Halloween Costumes for in Kids Crafts = Pumpkin=20 am Recipes am.
Parties Travel Disney am Online or Test Trivia or = knowledge=20 Archives new Games.
------=_NextPart_001_000E_01C6F75E.BB723B50-- ------=_NextPart_000_000D_01C6F75E.BB723B50 Content-Type: image/gif; name="Party.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6f777$e0bf7350$684170c8@ivan> R0lGODlhDAIgAof2AAQEAIUAAAB7AHt7AQAAgocOegGKh7PFtcbfuKi98j0XAFoiDIAbAJwSCLUa ANUcAABJBCRNCE09AGZAC4dBBJFOCcpMBeVEAgNYAChiBUhaAFduAHNVB5RZAMVjCOtiCQlxASiJ AESGAGJ+CHp2AJ+LA8eCAOONAACsAhWcADSYAGuXBnusAJ6XALmmAOKkCAy9ACO7BTPCCGHFAIPE AJfMBLnODdbIAADiDCDSADPjAFbhAH7lAKfuAMzpANnUDg4IOS0KRTQAQlsASYEKTaUMRrIAQdEA NgMdRSQsRUkWTmslMoITRqkkN84mQ+goTABOMSo0Tj82PlxNP4M/QqZLR7FIMelCRgZgSS1WRUFm TVRlM3JoBqpbRbdiOe1lSgB+SieAPUCIMVh6SXSHPKZ0Qrt0QuVxNACePymfRUSURFenQ4iaMqOs Nr+VNuGmTADMOx29SU7HSWC4QYPHOZ/EP7i0Teq/Qw3lSh7RNjjkQm3SP4HaPpvsPcDpMeXlNg4L jhMAfkwAhmwAh3QAi6EAg8cOftcAegAbihYtgDYmiFkgfXcbdZESh8kjjNssgww2iSJNgTtLc1k5 h39FfJFLh780gOhJfAtkjhhnekdVim5jcXhagZZhi7xahdNUegl/gBdxjjqNeGuCfoiLd6eJhcJ3 jd2EcgCeeRWcckGVg26ZioeTh5idfcWgdNuZfg6ydBGzhj25h1HAdHy8dJ20i7+4ddexhQXrix3n gTjedlPjfnHTfJzke7jlfNzdeAQAxiUAvUkAw2MAwoAFxJ4LssIEwtgLxwAssywsxj0YumEnwYkl waQoxsQWuN0auwA6vCZLsU1Exmo3vH9CuplHxLg5y9E+tQ5rsShgzTtdymBiy4BSvpNssrhbveJh vwCJzhx7uj+DtGNyxIyKspl5v8KAvdGOzAmRvCCsx0udy2emwIKfu6SZsrGjy9SSywC4zS3OvkrK ulG7uXbFuay1ufT17ZmipoRygfIFAAD9APD1BgsO+P0A8gD/9Pnx8yH5BACp9YcALAAAAAAMAiAC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmyZUN7 MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qVKXUKNKnUq1qtWrWLNq3cq1q9evYMMO dEq2rNmzaNOqXcu2rdu3TMXKnUu3rt27UeHq3cu3r9+/gAMLHky4sGGZPQ4rXsy48U+8kCNLnkyZ suPLmDNr3sy5s+fPoEOLHn24j73KqFOrXs06JenXsGPLns22te3buHPrLki7t+/fwIMLH068uPHN FY8P3828OUvl0KNLn142OXXazrNrH1lUgHcBML97/48Jnry97zPFly8fPv348+jdxw8/P754+vfV 11T/Hn5/mfydB6B/77EHYH334WffdQw26JSB4EHY3oQCpjcgewaaVyGFHK434IQSZrjhiBZ+yOGJ IHZI4ogeaijiig7GeF1FL2YYoYolttciTTvudyGPKeao4ZBCimijjxWGKKSOFtYI03ZQRgmVkz8e WaSALwZpk5Il9oiilUASeWKW/XEpJpZNIinlmmyahOF4R/735YVZUpigiWh2SZ59+oF55ZIB0kfk jXgySWeC5bWp6KIIDRVnmn4q6GGdVO65oJ5AGrnkoGGeKaikY2aaZqcylkodjaOa16OmmJIqJqsf Ov8JK4o4FkqllyRq+miYjPa60S9Ssijshhi62OmttiJpp4qzUvpnoUHOiqOEMMbk67VtdpffnSEW OOerBc7nKYGWKihphHcqa2mNff4oX5kIxnupqfRGZ129n2Gr776N4psvvwDz6+/ABBMVsEsFJ6zw TgdjtPBvHzwsMXQfVGxxxBHLhHHFMF1sk8cdZ9yxPRdzTBPIJFsck8gjs5yyyifDTPJMG2tMM8oj 38wxyy6XbPLLLtOsscxD/4xzyDWvrLPHPQP9c8g2+zyz0j4HrTTSQTeN9dVUE42yyGBP7BbPQk9N dtk5P41xTlnbPDXVaL/NdcZNqx132GfPfZPWOcf/TLfbXM+c99V21zS44DjZbfXfgH/MeN+Qm+12 3YRPrrfYbB3OuNWBt/z22nufLDrljcv9eeRrh9043p1LHnrrbYNeOtmHS6666J3Lbvjpi6OeuOu+ Rz260Kr33jfnvfGz172ap/078bw/Xzriws+O9uOe3w4565FT/3r3sX98t9xte89588ibb/rK5e8O vOmkVw+387ifflrDKwVe9fFEg+/6xkdr3/wGGDz2GQ1673Pa5bKWvu3Vb2g6e6Duyrc58RmQaSUr 29+kBrW4AQ5s/XPazoYXNa/J7HYZw1/+HGi5B65PdqmTHuzgR0Pr2W+AuiPf8fzXwNqdz3j606EG /wm4OgRaEHE/dOEFR5g7IxIRdOfbYc5UeK+hNG99NZRfDL83w/gVUIrxy+HZMvjC7hXRg0TMovfK GD33+S59rDMe3153xTSK8YYtxCPmGEaRILbQh3lMGRanl7fije96C4RgEbXGN+TNsXdbpB/tCLm9 KDYRjhCUIxpxV0f6SRF42Gvgk6g4EaOgz2RHu6D+ABhCoKmyaEtUoAQNuMqlYe9zKqsd+FqJtFfi 0mghzKUiZ1nCAGYyg4MTJQifVsAAHpBwJ7zcHnlSxWkORpTWVAspS5nN0WCzm+CESzXDSc5ykmU3 5kynOpeCznW6851B2U0AZDLPmMwzAPjM50zqCf+Te/LTHvzMZ0DpSdCC2tOe+uznPhdqUIA21KEC xSdDFXrQivYzogHV5z8hGlGACrQmGsXoTiRq0Y9S9KQOpSdJTarSjm7Unyy9qEslStKLejSmN2Up TmVaU57aJKY6/SdNZ+rShYbUoDod5VyGIlSCbnSi9expVAvaVIuW1KpTfehLDzpQp+Kkqie9J022 qtWUNvSpZkWpTqSK0qy2daxvBWlZ0QpXqgpVrGudaFrjmtanVvWvd93rWRka1b9StThTzSpdKTrQ xtY1sWoNa2TxatW9OvaqgiVsSpvq14daVrBkLWtPKEvZikI2s2796lxHqlnILnawev1sZz3bWbz/ inWxYGWsQi9b1+GcNrVw5SxXH7vbyBZ3sp8VLUSRatzDpra0fK0sdJOrXNby1rTHRStwf7ravDq3 uK/Fam/VOt3QVna5rr1Jbjd73OXKlTPJ+S1Pe+pRzbr3sO7FLW2pO9+VYnazHW2tZMlLW5EaOLb8 9e5p8Wvb9+ZUvS39qEgdrFvXBni8s5UuaMea0NqyF6YJbeuEFdveDitVLkQhLXshDNbbEve6evVw dVfcV7OGV8Vd5W+G26vh2NI1xJItb4lRS2HYDte72K3vfVV7XvMuubk8zu6CMWxfx5I1vLOpqZaZ nGMXQzWjTEauk68MVBuvFcwIBXKNfbzh/Xo2/8xeRiqax3ve6D6ZuwyeMoSbzOYdB/fPSp6ueBk8 3CuzJRDs7CN1X9vVwK6ZwHsetJn7DNVJh3nAkob0kY0845w4OrdOTnJz1ytoOm+31Gzm83/brFtR b5rKhEaonetSlNBOWLyOfnCnC0xfNRPYvHfd6aJjzGGaGpWo9JXpmyOtZF33eJ8r9XWmOSrsvhr7 2NX2q7Qv7FOQAjmp2P72XK9t0/lCmTHjhKe61z2TdrL73fB2N7znHZptvoTe+M73a9Kt734vxt4M KQo/Bq48exB84DEpOEyUR/CZNNzgD5fJwRt+cJooHOIRp/jFFV5xm2x84heXuMcdbnCSL/zhIP93 eMcxfnKEJzzjGSe5yxeO8ZXrpOIhZ/jEX47wjatc5zu3eMxFDvKc+7zlHBd5wmnO9JI33d9LX/rR k/70qB/d4kp3Os2p3vSCz9zpVyc61m/C8JrkXOtM93nITd71p3t97GmXedjXnpOzix3ubcc72tkO dr7THeJKn3rW+573vfub7md/e9RN/ne/L77kXI875KW+k7LzHeuIl7nm9X55xa/985jXfOQbb3a9 W37wkjf9yDf/+L+f/vRW33rhuU76aVYk82K3O+Mrn3W1P57wrzd86UFPduEnnvWo73zqf2942E9+ 9D4hPuUvP/nVM7/q1W/9yJNO/LcrXuu0PzH/wDnC8Z7LnfPgjzjebU51u3te9i2Hu+7lL/SdHz/+ KUf99zsu/elP//vCV3w/h3P2J3Q4MX/J53xhF3jwx4DVF355N34fcX+Uh4DYF4CCt3gACHwVSH2R F4Dgp3oU2ICl54DIh30KGIILyHMeeILNB4IWiIJ7t4Jt53x9x30amIP3I4Hkd4KWR4O4t34ayH+7 p4IzWH9fB4M2V3UpOIKqZ3wv6INGeH0CqH9RaILKV4J3p31aWHbSN3NfB4FOx4P9IhS+F3uFh4Wu 13tMiHbtJ3EAiIA0eIRWGIJuB4JuiIbLd4d593HJV3fKF4Rp+HuNd3UfuIYvx4dt6G/WYX8r/6d2 SYhy6ud4/rd1j2h+iYh0cviHdEiILAiHGreEQcdyNQeK5ReJYAiHnHiAFCd3l4iJTBiGrIiK/Td4 YDiJ8yeGBUeGBxETOwB1wBiMwjiMxFiMxniMwciLyriMzNiMzviM0BiN0jiN1FiN1niNd4GM2riN 3NiN3viN4BiO4jiO5Ogb2HiO6JiO6riO7KgR5fiO79iO8lgZ93CO8HiP+JiP+kiM89iP/viPABmQ AjmQBFmQvbiPgZENCBkjBtmQDskdCxmREjmRFDkxD3mRGOmOFbmRHNmRHgkd/CYaZdgTI/mRRfGQ JokZ+aATKwkbLbmRABCTABATMkmTMwkTMf9pDzJ5kzjJkzypk0CJkzLxkz5ZlDapkzvJFvmwlC/J lDHxkvbAlE05lU85lU35lDLhlFC5klKJlV7ZlVLJlUtZlWLplFFpll4JE2jZklDZE2vZlWqJllmp lWuJlXIJl1cZlTBJEz7Zk0fZl34ZmEE5kz+JlDR5lIKZk4WpFm2pl2r5mGnJllQZl18JmY0pmXZZ mZlJE3nZmTPRmJAZmmwZmm6Zlo5Jmpz5mZqZl5HpmFvZjRWxmIVJmEBJm4B5k7g5mEI5m7rZm7ZZ m3wpfmPxGAdxmar5mpnJla5pmcwJmqP5nFl5mnrpnJq5nNFZE6z5mGMJl2epndfZmqjJnKr/mZzf KZrTqZoZKRGyORO/+ZtC6Zu7eZjsGZ/w2Z41+Z4lyUcGIZnKGZ3I6Z3KOZquOZaUiZ3NKZ39aZkE KpoLOqALKpen2Zb9eZXPKaHjGaEG6qAI2p3liaEN+pjpGRHrOZT1eZ9ImZNBaZjvSaKBmZT1eRP5 qRMI8ZoW+p/naZ146aEZSpU02qGsmaDWmaHm6Z/mCZap+Z3ZeaTeSZ6meZYECqR6GaL/IAMOkaLy CZ/AyaL0uaIjuqVZmpsjGqM50SieKZ5DKqBAOqFmWp03GqTSiaFmKqBCuqHiSaEdOqSkaZxFupqt aaEbKqUP0ZMoeqJX6qVWSptX2qVZaqiE/+miNymmONEv3PmW21mXRLqZbbqV2+mfd2mW3Amn01mp dPmhEtqgCcqfb0qWFxqXTzqXovqjTrqk4BmlDpmSjgGawYGrtrqrSKGrveGrvBqswjqsxFqs1qJo tXGQvQGozIqsQZGUfTmoimmihLqipAGtJhqtg2qs+rieuGmUtymfiwkavPmeuWmt3MqPFOGt8eme i8qowikQjaGo7hqUzXqvJVGtXAqcjYqivFmukCoY34qouwmw+HqwC3EUgPmi8DqunkGUh/quDpuu +Liw50qw59qbhcoZ0Squ+0qxxRib1LqwBbut2Xqfj6qsjIGt0nqYNYmwMBuwIDuzNFuzDv+CADiL ADa7s8GRsznLs0A7Gz6Ls6firKQhs5GqskIRs3eBs74yFNJalCTbr7NpsXxZk7Jpsljrom1RrsGJ rjlhDUGrb1H7sS07tRCrqFaaohkLtmzhqOPqrxO7GLIwtqARm/y6tu5JsFj6rmsbsSTqtfKJtDB6 EHz7txgbr0wLqFCbt//arizatmoLuOIqty2rFtuqtx9rt+uGt7r5uH4JsScqulpaqILrtzJBuDbR LybLno6quIsbuwhxsWYbuB6bqDVxuiRrqPaqtD7BumxruoMru/fauFqarYGLvLibu1sbtVI7sP6K uScruYKqjZnLuQMzt+DItdibMNq7jdz/y6sh6RiquxYDKZPEO77du76dob7o5rt8kb6LC7XNO5/7 upNUm7jCO718+71kQZRxK6j+y77l5Ln2u7mHW66Cm7EL3G7waxTQiq7Re6zyKxC2UMEJEcC2i6i6 i7iRC7aim7IGwRT6O6I/icEorBAjG5x7i7IuzLyvO5jTGsPl6xNaa8IoOpDZkMIRAcFu254SPJ/0 aq62u7FrkblqO8AEHIyH67JfesBEXLoM7MS3e8SAu7tKvMTdJLLQ+7Vsy7KKKbwu67z9i58PTBRc e7n1u4M8nBtEwCj/MsJNkcUO3MZ2HMe8McdDcY4xacccocWagb90TLHuexk1rLhJoYyC/+zHWTEa h8zGBJHIEoi+jHwS9Ju1SGy1Nnmym+y6M/zJg7wUUuvJ3wrI8HQvXgvARQzFKqqxp+u2FJzHv6uy 3Eu6ulnJGenDUhzFqHvFUTy5lIu5HizGoWzK6ma5vhzMuyzDt/nJy/y2ujvBxWzMxwzFXWzE1vq6 U/u33Ny1u1vE0+xvrhC0qZzN2By8VGy1GgzLZ1GvEdu21ExOXHy1l7u5B5y2idq89by2j1yGcBu9 nAzJuBy7jnzGhSvH56yfAy27BY3QJKm007zQKBnPFK0YhYwcBm0WEo2RFd3RsVHOJQvK6CzARlm9 Q6nP+dvOmwzA1+zRTAzSfqvAueu6Vf/8yt0syliLE03s0uCUHE0MxJq7ytb8yyA808Pr0D+hvzbB txt9kcbbr5B7zXB7EyFs0sw8us+M0538tdTK02QbvkDdwQ7L0mC6v0bdzh3Myl69E0SAL6jMwk9c uhp7vOCMu+vcu0gNFGXcyzPZ1BONxmf9vCn9zdtssSgtxjiNzCGtr2udTRetGY+s1g/t1wQdG5Et 17NM2QXZ2JztFpr92fuSknLQ2aRd2mID2qj9tKa92mhRCqz92rAd27K9j68w27atrqmd22xy2/Do BsXBtB+g28vI28Rd3MZtMMKd3Mp9ESOw3M793NANkcc93bEc3fNoBepI3dot0Nbd3d7//d3zuN3U /djindmUXd7HTd7ordB+XRSH8N6HYA/wHd8wQd/yLd/vLRPwXd/7PRP9fd8xYd/4Hd/zTd/zrd8B nuD8reAAXt8IfuAN3uD2PeEU/t8HLuAYnt8FThMQPuAcfuEPnt/6LeIRXuEEjuABDuIJvuEpLuAe PuImfuIgmxwuPuEOLuEcfuM1YeP4zeA6juM7zuAU/uD+TeQOjuFCnuJF7uMlvuQ/zuRA7uRIbuBJ 3uQRbuUo3uQuruA8HuVUjuDgTRBbPuVYzuU2UeP3/eU+3uU5fuI8buNovuJyTuQyDuBI/uRlnudX fuVjvuZ2/uR1nuY5DuVsHugoruZH/17kaA7aQ2HgGh7iTi7kJA7ofx7nP/7fcl7niN7ncy7odA7k d77nBW7pos7fhs7pA77fFq7oRq7qLJ7lo57q/k3iaF7rKm7KZJ7pWU7ou+7pPb7rW87ngm7iva7l /V3rvt7hUe7nwD7oiV7shZ7srN7pvl7ql77nzy7syF7sSwznZr7seG7pmx7pwY7sMh7qqF7tQe7m 197uzP7usK7j5e7nav7mh07tqJ7rg97l/I7nM2sdF77qRz7prj7pLQ7vAi/rzh7t/g7hpC7v717j qg7stH7mFm7wVZ7tFQ7jGf7ovH7tr+7lBp/wDs7o633yKJ/yKq/TQBvmqwEALh/zdf8B8zJf82BB 87q98mkRzh1p86mB86it8zsv9A+DDN3E8xXp80rPFen6DETfFksf9Vjx9FRf9WMr9VhPFVZv2lnf 9V7/9fK29Y0N9mRvyWLf2WWf9tJ99mut9m7/9nCPGscY9wAz93Qf9mx/3ASYipb4cacIizVXfqYY +Eg3+KRI+CeXg604hLIodTing4+f94aRHLr3fou4gUB4iNRXg3uY+KnndW9odjjIhiRYcneP9z3R f15Yh5ifgHsYg1O4gRwoeN5XfLUveoRHhSnZ1fJMEaAPezrXebfocn4f+qT4igMYf4UveZEYdz/Y +F4Yc6uv/MpD2TvpjENxhrK3gMH/Z4tIGHrWZ4QfWIrZl/uAb4g2uPqgV3vBer17RPn+Z/l02Pqe 6ImFyIbyf4f7x4fQV4nbDxD2+NkjWHAgwX8JFS5k2NDhQ4gRJU60MtHiRYwZNW7k2NHjR5AhRYok yM/kwJMHBRoUaLLgypItT8pEmRJmTJs0a7p8mVPlTpcqV/6UefNmzpgsUxJNSjPmSKhRpU6lWtXq VaxZP77k2tXrV7BhxY4lW9bsWbRlta5l23Ziv6u23M6lizXtXbx59e7lq7buX8CBBQ8mXNjwYcSJ FS9m3NhtX8iRJU+mXNnyZcyZNW/m3NnzS8ehGQIQXdr0adSpI35mzRpAa9ixZc+m/13b9m3cmluB BfA692/gwYUPJ16c+G6vvo0vZ97c+XPozJFHp17d+nXiquu20t7d+3fw4UPqUM1d/Hn06dWvX2ye /Xv48ddjp1/f/n381uXv59/f/38AAwRsBoVQEfBABB3Kb0EGG3TwwcwSlHBCCiu8CkIMM9SQth02 9PBDEEMUcUQSSzTxRBRTVPG6PVZ08UELY5RxRhprtPFGHHPUcUcee/TxRyCDFLKhF4s08kgkk1Ry SbP8YfJJKKOUcsq0lDvLSnuwJAtLLaHrzcu7upRMTNxeI5PK7DoyM8uuevuyTa7O/IpLrh4qSDkz 3YzTTTlf4lLPsPpE6002/dSLzv8t9RR00ELJ5DOyR7dkU8sh38uS0DvFQvTKOOtUkCA8CxV1VLM2 PXPRUkM1FFJJV6XMNzFR5RTUUkm1p1LH8lrTyi4BhVXRLwl9c1da78R0zkxVLTZZUIcNltdML6U1 T2qnvTTPZhH91dVsi4V10kZ9/RZaPwG91ttlG7X22WO1FBdPZ9tddVhm15QWTQjd7TZUe8FVN9lx Oy3LXmWvfXbZfk1Vl15Rsf2333nTHZVfdOmleFJ3GfbX32+jDbhjUn11NeGGuSXYWnBPxrc4j3gz lOKLO1bUWH1v/RTlSKPVWVWQs/01WI+ZRfffcjVOF+aUhcYYaJcvThpiYoktObn/iZUmWeelA35a T1wbq8xpqTnGeeqaNSVa4J3T3vTooFF+GGto1+bZYbCrbtrqZu8t916VbXW75LrTDnnhjVdmuSNN 3/V25oeZnvpcO0dG1uR42d7z6nPJnhZTcnlVHGHQDd63TZEXV7ZsmR8XvdvMM8/Z56LVDve1rhkz /PbhZMX9vpaHi3z3DXXHq/bFgDf+eOTD6j155jsjPjzNhHdQ+kBfXZH65q832W+4BzV3r0VfxzrQ 76nm7djx00+cXNLhNfb92M/HPn1HzUU/exPZ5377WicLn/6BqU+AqhMg9bZVPa1BjFuTs5759oS/ 4P0MXpx72eq657ryKSxnFjuX/7P+NjfYqQ6EHcygwIDFug1qDW1yOpkKTVi+2fHNfh/Lm996JTEI PohkBeMT0HjYQ8CNr3QbayHI6NSuEvIsZEkUnMSgBrqY6Y1/k0tg69o2uLdF0WgKxOHZcng4jnQQ b93DXNUCB6e6PapzNLPV3K6mQDcOzW5KI9oOGYe2LoauhU4MXdtUSK03Om6BIXweeHTltjLGTYQV RCSy0rhAlXFRi0HTIBSFeMU6BhGAK+TfHrFYsLcRcY6eXNscaXOMLyoPcXeU4PYAicefhZBmE3zl 6FBoy6JN0IJtnGG1QGnF0r1Llxmr3MTEBT8pivFoTBtXL8nGzPY9sZAC8t8hw/9UpgXN72vgu8s0 A1RNvBjwNtpcEjm76c3/pIlIqUwSOtGjToaws53uRAw3q4THAA6yNea0DT/l+U+/cCRss3RgHqu3 wN/xC4aMIuNBDVpQyPRKfA4l6JjOh0yIjmWiZqGneKz4UCzOanwJHWM4p+iyAWaULze8pz4jetEa 9sWcHT3MIZ/YPtP50n1JM2afzvhAC75OkeLrXLxKKaxjBnWhR0ThwS65OaOyMWXVqle41qVUfN6y lgsFaHFqxkpRpg5gf9sfGvtItZ/2MGyeU2NJ7bbDRv7SYHRz6y3jijeG6WugdI3iJjFmyRE9Y2WK vOrYYqjLrDpSljhNawV5yEj/UcINrG1tJJwkNzRHaTKsJdWW6TRbSxyesWddtc4j++pJL5ZVaGUj XGXZlkjIwvaChQuc/h7nNLPeVbemTN0fNYtP0aaUtJZZ3pw+10qxghVhX/rdWZ3ouFY2lKjzimou m1o5N/ZMbsVkKy1Xl0LtAvOFcPXs5WLZMMXR1JC+u5lGMYO9+QnPnyIFaXPIpN7vwHMh/bSm9+ab mVJW57747c5wwXgjSRBYMAZmcIMXVFyUHuq/xhPTFhR84bYolnsbdelnFLZSucKOpbIConstGy0M p1grB41VSid8zU7x837AVWk++1ssFefYKr2V1nQXty52AdlhMkTqAfeWzL7p/xSjmKUtUD143o2y NYTIPaaOrSwVHhtRcs2UI13PRl45QvayYjNlFonJR9/+8nRBfKTNrpwVJjAGCTU1adQyWVHKZlKJ h6UjUQXZxEiyDs9lTRg0f9pHuLbZwQZumVOTDMnL1nZsuB2xDWXXWv0NNLdVPPRt2YxXhLxZ1P84 lB8Xebnbaiy50L0uqtto3VVnunCyhHIMCdhTwOZ5tIvmda9z82JfB1vYIAb2sI19bGQnOz+KUHaz b9c76QXYxAVprmeK/V7g6O7axB01W2zKy/tJ22xXuqP3lmzYQSc2UTMedwMr2u67bRiJ7053h51N HBiyUN0UnTb4dhpjBrYYxv+qrfFKOQlvFlPxyAQM8bbvrUqBNhmns1NyDaXmG5JSl13nvWqi4bja gyENydTVo8yqe0KLJ9VySF05kHd55/Be+oQir1y3c/VqZfKUzHFTYXNFpuiqJhqqn76il2XNY8K1 mdN0NONrI8bTH66Rt1UtOt/cZvO1uHuzp8UlVxH4WT62Furm/SBgd8lzDooOzIHWdUizhsunkbnp 9e6pC7XsXYI/nCwQ5qTIdy72jlW7sJF9611Hy9Sqy3XPq42tJu3O9MWLPW9pf+yXGQ7wxAMQ6yv+ 2nFFjFlW1zdSyAWYbUk/a23ltdzfE6qwYgflYHo28q2P5Yd9e2mostbWp9//F7v1riSHRyf4vye+ h30/ouEXn0l85/Y6le+hzYuGM4J/PoSin+FSW3ScyZdUtF3Tb63DhvvVv1t3UbVr8pG4fw2Vnz+5 2CrhRjPvPiW41xlIaPvPavzIC8H2xT1u9cu7lpqt+2MV77ux9Yu3hEtAfpOp+iI/jlITiQO52tOl jNsplOubVnM61ts0VVOqjcMZDKyYXjI9ECSYUwGqooM9tKKgvoO66PKhTLm+myMmR3Mr5Ugo1/s7 IzM7n5HB8bK63Vo7IRwqUHuuNKO6zDqxjzo1MQutsSpCx0MZGvSaAlwzL8K4myk0aOKYSnKlsHMt IlS00QuyIVQs0/K6PyEs/7tqwsM7McxpO6SrQtu5QkB7tQtsOS98QTAMwzgEOzKMGKQjPIAzrayS OiaLLNShMTHcsooJNTpMjAhbplrrlozjs6RDwjCcKhvEtc/Lqe+Kn8l6Js75OY9hnCHCMxc8rGJ6 GfQpw9DrOteKRLuAQINDwPhjkP0LNuarDOoznPyTHxWxElq8EFs8xuLrRQgsxkgcp99wv5dCRhQx hgZRRiZ8v1hht0pLlXKzJwZEv2u0LEFhRhUbB4yIng4TOIHbt2mDRvpKreRQM2kctkarLvZToxJC rwN6sutiqVCsRIoDQSjyHKxipH1Ewegixyrsr0QCIiKUqt8Sm05bsw8MRP+g07OWI6yHnMdU8ojG ojpC/MNhOsODI7wxPELUG8hVxK4zVEgaZEgn1DnZurtH3CwoNDuLRMmPi0ink8i6Aj+OTKUhOrpP HCVBqzWAXMQPKjLe47jRwzxbWznK+8B3DMp728XOwMp9ssqHC0bhO7770EqupA+XTAzSKEu0TEuP VEu2bEu3fEu4jEu5nEu6rEIEqEu8FJAcQAwtyEu//EvADEx3GkvC7DXBPEybK0zFbDCOgATEfEzI jEzJnEzKrEzLvEzMzEzN3EzOzMzF/EzQDE3RHE3SLE3TPM1k60zVXE3WbE2QQE3YxB1rPLDamQfX TJDYzE3d3E3evAyPYIr/oegJg+CJnuAJpBjOoJiJptiJonCz23zOqgBOlBDOo+iKgxAKrsBOprhO lhBO6PzO1ciL6ZxOoyDP7uxO7DxP9RxP6lTP3sQQAcihlmHP61wKo7jPnyDOpJgJoaiJ7KRO8AxQ 57sL+myK4GxPAzXQ/izPA11OJUmD95SShkiFiwhO8lzQ6vxPDT1P8+TODPUUAQ3RvZDO9lTO4gQK r7AJpCAK5UzPCH3RvUMc6ghRGoVRG71RHM1RHd1RBpnNTbSxgWsQrIQv+LsMOAI2sBRASCxGfws3 dixAiITSQyzSbQJHAgQnpgNAKp1EJb2pbQJSW2w0hJMvLi24B4wNK7Wc/80g0/kDU06xLe3bUohj UpOaOCobMg7atehSu9LrsT0UrwziLke7wUGlt1acst2jwF0pwb1JIbJLuSF7OyfDNVPMQCRyyqCb ocWyytoDyUCLQmzESbCzOhciK6NEOhrKoguqvL/SnCT8yL7KtctTPIlTKCZbRA3Ssp88No9sPPIy OS40n0AMJUntrCliu0cE1pmcrT/0ycFb1tzbsthrvNcrvMoSK9wTVdmbQcAExCl01tSiyUYU12Mt V1QtrJiz1lMVHNRaq1PDrWwlq2W9KUlzwp00ScBzTlps0kqkLGD1NDbKLhFLO1ZEO1ebVmRtnD0t L7rrQFAMJHmJo3cDlv/wAqWZYZ+hJME1DC1WcqYQ41HcGT+xBNnm2whnGz6vRJPAJNkNEVGWzZDK RBGHe7/sGdmXZUKVkrEnTVM0Yj33sbMEpNkrXY4UFK40TVIzRc3Z1Dcj3dkz9VPSQSahnURBgdPr 2EGUOpVti1ldicF9bFWLURyW+y6C/KgQjCmQdKy4gz15qZd807hNxSCvtSM8/RgKmq5/naqXU1i9 ydOmetkkXJg3/NVJg7yzEtc1YiI7c9eou9g+VatRVdONTFgvo9ZkBVXnSq5JK9Wn3Z1HEA6PHEU+ XS7G1Vgw67Knk9QfXNWOs8mpK6O5C0lHTEQeXD2oxNiHtFiEHV3Uw5T/EMVYy7vVb/XSnaw8eIWl p1vcyG06i/VVAgwurjNBHHRe1L3Hsrveb+HacAq9Tj3F0uXbyIvKMVoqsy1EL9RVDnxb741bzxu6 0f1XxHKtt9qimPxU5Wrf0fTRms0+CEKQaRiS4YqvL9Lemy1g+9BfAz4SOmSV0sIPmxU+/q1TZAzd bpwNq03deJTg78M3hOtcfuNZhYvgtKhL57Lgjw2zqHWOB+7gJ/VGFM4nbZofEtbHf4OfEUJBVcQ8 pOwx9a1AGz5fSN1YRz1BYHIq17Gqg803r7U4sG0m7MJAlePhsfWzgtTdQ+3HJY0+b4xVQSTB2w1e xsVWYz1XgrVcTwvc/1lT1c0JM1gdXiH0VDU+3TuTX8SV1+mVX2SkyEBNoNVjNaF6n3pdoryKVnhV rsQT3SysSSJy2JAU3bYbnehF5Oo1ZD0zxdldVw/+J2iLV+E1StftQ0V8XjX2wdujXm211o28ZFlD N82RyVGOyDo2XsP9QkxmkxnGwj2WLKg5uVVM1Ds2rO7dvVgkoSIjRapKxFTMZYbjXrjrVK7LucFd 3+aVWBv6HFHk1rmsjRVe0+orthkWP6Slj23Gl2v75gR+Nu0Agvk4Z3b+kPOzNwArU3hm4AwZZw8b E3tWYAkMIBBuWil9wy/NRTdNLJ3FYHoWVv1jQJxdaHkGUbV85362jP8lNCHOKDamlWiKDr+MHmgX Ttp5dsshJlXQkqqpTGHwEuK/fcqTjse6vVVGPbIyZGK6cWIfDmK0PVskM2Kx/ZPJu7hhcteRW2mF whag7r2ASUwJ1sCLG1qw7aJUZsNHS2VTg+M2jmQ0c2M0Rt2YQ+MWMzmojOOedN1AMlzAyWc0GWpn PlxUw7uA/WWb9DvYRWYzFGtYU9RU+16ahmWVlLo34thPbeaa/ONhxdaU5EkG61XslbtVjut8ZdW3 pmpMImNFli1ZZddnfeVC9kFTo0iKFuPEljtTFsmw1mpqa0uJRcVlDmaz5d5cxlS4RtSpHkWBrVbQ o1cg/DtovmqGDSX//LWrXd5hSqRWWKSqe90ZjUHqkFVSXJxHs4YSBI6gmQ1n5aMe5G5n626O514Z Gh21/Kha2Tjh60Y2AfZnFs7al5ra8B5gGV3ug25oKeXfcdzutNyqU+w9rVptWgtUgrrhvyJuu+Xp sUNbfZVvFfu2wL5WzNUwQhxfM5vsNd4f5X3h9GaeXlWiGCRt+vFjIWLmpqxtL23rY34dAr8yA8e0 TSNrB5dlC5dcUkbeuEvkCfe1ZjXq8opfWXw5YdJl5mVJQYNkUszkGHfu9c6eEbeyID/yImkAJHdg XyvyKztLugAFJ5/yqOiNl1zy3WluLGdnLVcRKl+MJ/jy5zQAMS9z/zM/czRPczVfc8XYcjdvDTaP czp7czrfDDm/czzP8wO5nf6rcz//c0APdEEfdBtlhsnQc0RPdEVPD0JvdEd/dEiPdEmfdEp/2VFY keyO0EU3xrwAB08HB3v4dE8PdVHvik8vCFBH9ZcQdVBPdYJo9VJHdVcfdVcPdVuX9VPP9VMn9VZf 9VUf9VcH9lt/9V8X9mCfdV/nCmHf9WIfdluPdWdP9VJndV5XdWKv9M+odWe3dmW39mU3dW5/9q9Y 9l5XdW2P9mu/dWlPdm5HdlIPd3cf9nUP92D3dnB/d2J391ov926/dmQ/d2wPqI04d4An+G4vd4NP d3H3il5veF9PeP9/t3d0T3Ztd/iJz/eDZ/eIV/d7R3h03/dtT/d5X/hNRwxpp3VmD/mK53iIZ3VY N3Zxt3iM73d/Z/aR3/abX3h+//iMp/d5T3mJl/mFr3mQP3aaL/nDAPmCv3dzl3WmV/pxj3iop3mO 3/iil/imr3d4x/mLP/Z1X3p533mxp/l/P3qkLwx5D3m113eNF/mHj3qWf3uqH/mfb/t4v/mrv3uF v3qd73i5r3qFT/uNT/ezn4q9mHZoB/hq3/unf3ho53peP/lvN/pY13WUv3xc33pcr3hyv/yxj/dq V/qUr/zRb3d6D3jUT/2xyPT3dEsIqBHVj33ZH3TWb/vPPHtTqMX/u3j8xed5aod3xB/9aXd8ySf4 zi/+Zjd6r/984o98ft934S925Dd95e/6ys/62T8Lj9D7msd+iF97uJ/4nGd3uhd8tr940cd6nid/ pw98xR/682d8qSf2wleMqW/6nP9+sG/8oA//mQcIe+AE2is4cGBBgwQXKmyo8GBDhA4JSnSI8OJE hgkTQtRIcWNFiRgx/itp8iTKlCpXsmzp8iXMmDJn0qxp8ybOnDpZbuzp02dIjx07cgQKEhxSkD8Z Im2K0WBSpUpFMhUqMGrRiUMXBpXq9alIrE1/Up3q9SrWqkvXsm3r9i3cuHLn0q1r9y7evHrf4gxa 8SPUnn81DvaY/5VwRsRTx6J9WpSoRbOBFR/myLix0bORJWs9THUn6NCiR5Mubfo06rtl1Xat3Dkz 7K6D/5alHTviV85cNc8WzNs38M2t1Rrea/w48uTKlzNvnrfvZairrQoe63R67sdJnZIVG/zo6unc EV+2/Z084/Hno6uX3nog6vjy59Ovbz+18/z69/Pv7/8/gAEKOCCBBRp4IIIJKrgggw3ac4qDbN03 IYUVWnghhhlquCGHHXr4IYghijgiiSWSGCGKKaq4Iot5xdEijHKZOCONNdp4I4456rgjjz36+COQ FcY4JJFFumVNgUwYuSSTTTr5JJRRSgljkFXqGIeVWWq5JZddev/5JZhhwjQlmWWaeSaa/4m5Jptt uqllmnHKOSeddfb0Jp556rkniHb6+SeggQo6KKGFGnpoQnwquiiNQjCaI6KRSjoppWs9eimmmWq6 KaedeopppaGKOiqppZp6Kqoofroqq626+iqssco6q5c4tNkFrbnquiuv9anTa0mpGveOsMUaeyyy ySq7LLPNOvsstNFKOy211VorKbDZarstt916++1L14o7rrDgmnsuuumquy6b5Lr7Lrzxyjtvs8rQ ey++d7G7L7+K5vsvwEzKEjDBBTvZL8IJt2swww2rqjDEEcPpMMUVW3wxxna6WoHEHXeacYHcgPyv xyWbfOPIKasHvDLLLQcYEAA7 ------=_NextPart_000_000D_01C6F75E.BB723B50-- From avt-bounces@ietf.org Tue Oct 24 10:43:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNUZ-0004ti-30; Tue, 24 Oct 2006 10:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNUX-0004qC-Dh for avt@ietf.org; Tue, 24 Oct 2006 10:42:57 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcNUT-0003CW-82 for avt@ietf.org; Tue, 24 Oct 2006 10:42:57 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9OEgoQB001040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Oct 2006 07:42:52 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EE93E55-781C-47C8-B21C-B0B6B2F45FCA@eecs.berkeley.edu> Content-Transfer-Encoding: 7bit From: lazzaro Subject: Re: [AVT] AVT draft agenda Date: Tue, 24 Oct 2006 07:42:49 -0700 To: avt@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: lazzaro X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi everyone, On Oct 24, 2006, at 6:48 AM, Roni Eveb wrote: > See the following draft agenda. If I forgot someone please let me know [...] > 10:10 RTP & layer 2 QoS > (Teener, 10) Is there a document coming for this? If not, could the speaker say a few words on list to provide some details? Thanks, sorry if there's been a discussion already and I didn't see it ... --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 24 10:45:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNWC-0006EJ-St; Tue, 24 Oct 2006 10:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNWB-0006EE-Kz for avt@ietf.org; Tue, 24 Oct 2006 10:44:39 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcNW2-0003OL-Si for avt@ietf.org; Tue, 24 Oct 2006 10:44:39 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CE0027C1; Tue, 24 Oct 2006 16:41:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 16:41:31 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 15:14:04 +0200 Message-ID: <453E119C.2030907@ericsson.com> Date: Tue, 24 Oct 2006 15:14:04 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Baugher Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt References: <85384093-2F6C-4792-9619-CDC8734F7EA0@cisco.com> In-Reply-To: <85384093-2F6C-4792-9619-CDC8734F7EA0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2006 13:14:04.0524 (UTC) FILETIME=[4788AAC0:01C6F76E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Stephan Wenger , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi Mark, Thanks for the review and I will do my best to respond to your questions and comments. Mark Baugher skrev: > Magnus, Stephan, > I gave this a first read and it's well-written and to the point IMHO. I have a couple of comments off the top of my head. Starting with Security Considerations, > > Second, the number of security contexts needed (for example in > SRTP [RFC3711]) may vary between mixers and translators. A mixer > normally needs to represent only a single SSRC in any given > domain, and therefore needs to create only one SRTP security > context. In contrast, a translator needs one context per > participant it translates toward in the opposite domain. > > > Couldn't Figure 6 have five crypto contexts installed in the mixer? I think you're saying that everyone but the mixer receives using the same crypto context. The mixer additionally needs to receive the others' streams and each will have a crypto context. In the case depicted by figure 6, the mixer will have one SSRC and the A-D will have at least one respectively. However if we are looking at the link between A and the mixer, the traffic passing on this link there will be only two SSRCs, A's and the Mixer's. The SSRCs belonging to B, C and D will only occur in CSRC list and inside RTCP SDES packets. Thus from an SRTP perspective, A only needs two crypto contextes, one for its own traffic and one for the mixer. The same is true for each of the other participants that only receive a mixed view of the session. That is why I am saying that the mixer will have one SSRC (at least). In regards to using the same crypto context for all the others, I don't think that is the truth. To avoid the two time padd issue, the mixer needs to use either different keys or different SSRC in the domains when using SRTP. The reason is that a mixer most likely will need to produce different media streams and mixes. Sending the transmitting entity a stream with themselves seems wrong in most applications. Thus senders and only receivers will at least have different streams. That is before even considering the need to adapt the media to the individual links. I think I missed the word "additional" in the following sentence: "... and therefore needs to create only one SRTP security context." Where a mixer will need N crypto contexts in addition for N domains, a translator may be forced to have P*N crypto contexts where P is the number of participants in total. > > There is a lot that needs to be defined that probably is outside of the scope of your document, but the security considerations section also says: > > Including the mixer and translator in the security context allows > the entity if subverted or misbehaving to perform a number of very > serious attacks as it has full access. It can perform all the > attacks possible, see RFC 3550 and any applicable profiles, as if > the media session was not protected at all, while giving the > impression to the session participants that they are protected > against them. > > > > "Security context" is vague but I think what you're saying here is that giving a device access to security keys adds a new risk, another potential point of vulnerability, to the session. _How_ the mixer and translator are included in the security context can greatly affect the risk. In other words, we know in security how to establish pairwise keys for a pair of endpoints, and we know how to do group keys for multiple endpoints, but I don't think there is a consensus for how to do key management for some of the figures in your document. No, that is true. The security risks will depend on how you key. The main point is that a mixer or a translator may actually need to u > > I had one more question come to mind when reading Section 3.5. Following Figure 5 it says: > > In the multicast domain, the mixer does not need to provide a > mixed view of the other domains and will commonly only forward the > media from B and D into the multicast network using B's and D's > SSRC. > > > > I expect that mixing would be useful for a multicast network to give every participant the same output from the conference. Are you assuming otherwise? > In this case you have deployed a mixer simply because B and D can't have the same view as A and C that are part of the multicast domain. There is no reason for the mixer to return a mixed stream to the multicast domain that contains all the participants, because any sender in the multicast domain has already received that traffic. In the same way it is unnecessary for the mixer to even mix B and D together unless there is a bandwidth issue, because the participants in the multicast part already are capable of handling the reception of multiple sources. I think we should add the word additional to that sentence to clarify things. Are there anything else you would like to improve in this text? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From acexsgof@amazingcharts.com Tue Oct 24 15:07:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRcL-0002gl-7B for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 15:07:17 -0400 Received: from s0106000e7b423014.no.shawcable.net ([70.66.10.129] helo=Shane.no.shawcable.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRcE-00051J-K2 for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 15:07:17 -0400 Received: from 216.104.160.49 (HELO mx9.daemonmail.net) by lists.ietf.org with esmtp (OT80280KWXY LGHMQ) id 7RKEEZ-O2MD8I-QF for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 18:07:09 +0360 From: "Lloyd Cochran" To: Subject: Very important note. You require to read. Date: Tue, 24 Oct 2006 18:07:09 +0360 Message-ID: <01c6f797$38e87a80$6c822ecf@acexsgof> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: Aca6QVQ8GFIWO1FRQ1G0B24N7X993V== X-Spam-Score: 2.0 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Get in on EQTD first thing Tuesday. This is going to soar over the next week. Already there has been a 100% appreciation within the first few hours, so do it quick. With oil markets retreating, big traders are turning to gold, driving it to levels never before seen. EQTD has made an announcement of staggering proportions related to a recent survey on one of their gold properties. The inside scoop is that we will be looking at a quadrupling of share price once the public takes notice: CHICAGO, ILLINOIS-(MARKETWIRE)-Oct 23, 2006 - Equal trading is pleased to announce survey results which have far exceeded our expectations. Results from our British Columbia property show a 58,000 ounce potential. Plans are already underway for immediate development. We look forward to this extraordinary discovery bringing value to our shareholders. At 600$ an ounce this discovery is worth 34.8 mil$. With 865mil shares outstanding, this would give us a book value of 0.04 (current price is under 1 cent). Don't miss this one. The value is there. The opportunity is there. Don't let it pass you by. From esfdixpdft@posner-rosen.com Tue Oct 24 19:07:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVMZ-0004qW-Gz for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 19:07:15 -0400 Received: from bl5-54-23.dsl.telepac.pt ([82.154.54.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcVMS-0003Pj-6W for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 19:07:11 -0400 Message-ID: <001001c6f7c0$f99411d0$17369a52@cbyb1rzk8xq443r> From: "Privacy" To: avt-archive@lists.ietf.org Subject: downloads. can share Date: Wed, 25 Oct 2006 00:06:01 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C6F7C9.5B556C90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af ------=_NextPart_000_000C_01C6F7C9.5B556C90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C6F7C9.5B556C90" ------=_NextPart_001_000D_01C6F7C9.5B556C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Policycopy am inc new am York Times or Company all rights Helpgerd = Screening Prevention Tipscould Heartburn Lead. Guide Logsfree Sign in Nowyoutube Next service offering in uploads = downloads can share in videos even if dont have blog However wish = integrate then of Youtubes services is This stepbystep tutorial how is = Started Admin. Free Email Course for a Quizzes a Surveys Memes Polls Topics faa in. Rssemail in friendadd is of Blogwhat do Need or Start put in Blogging is = Toolsfree Legal or Music Fortune Nursing Agency! Share or videos even of if dont have is blog in However wish integrate = then Youtubes services This of stepbystep am tutorial how Started Admin = Uploading Fileupdate Videowatch Monitor gtgton fromall is Article our = Story or. Your Blog Using a Youtube you are Logsgt Blogs Asked Questions on web in = Logshow Where Find Free Email Course for of Quizzes Surveys Memes Polls = is Topics faa. Can share videos or even of if dont have blog However wish or integrate = then Youtubes of. Quizzes Surveys Memes or Polls Topics faa Logs Hostsphoto Mobile = Blogblog Writing Audio Atomuses and in Roles of Games Research Guidetop = Premium. And Roles of Games Research Guidetop Premium Books Weblogs Tools Compare = of Prices job Yellow Pages Forumsmost Popular up now the Online amp = Rssemail friendadd is Blogwhat do Need. Course for in Quizzes is Surveys Memes a Polls Topics faa am Logs = Hostsphoto Mobile a Blogblog Writing! ------=_NextPart_001_000D_01C6F7C9.5B556C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Policycopy am inc new am York Times or = Company all=20 rights Helpgerd Screening Prevention Tipscould Heartburn = Lead.
3D""
Guide Logsfree Sign in = Nowyoutube Next=20 service offering in uploads downloads can share in videos even if dont = have blog=20 However wish integrate then of Youtubes services is This stepbystep = tutorial how=20 is Started Admin.
Free Email Course for a Quizzes a Surveys Memes = Polls=20 Topics faa in.
Rssemail in friendadd is of Blogwhat do Need or Start = put in=20 Blogging is Toolsfree Legal or Music Fortune Nursing Agency!
Share or = videos=20 even of if dont have is blog in However wish integrate then Youtubes = services=20 This of stepbystep am tutorial how Started Admin Uploading Fileupdate = Videowatch=20 Monitor gtgton fromall is Article our Story or.
Your Blog Using a = Youtube you=20 are Logsgt Blogs Asked Questions on web in Logshow Where Find Free Email = Course=20 for of Quizzes Surveys Memes Polls is Topics faa.
Can share videos or = even of=20 if dont have blog However wish or integrate then Youtubes of.
Quizzes = Surveys=20 Memes or Polls Topics faa Logs Hostsphoto Mobile Blogblog Writing Audio = Atomuses=20 and in Roles of Games Research Guidetop Premium.
And Roles of Games = Research=20 Guidetop Premium Books Weblogs Tools Compare of Prices job Yellow Pages=20 Forumsmost Popular up now the Online amp Rssemail friendadd is Blogwhat = do=20 Need.
Course for in Quizzes is Surveys Memes a Polls Topics faa am = Logs=20 Hostsphoto Mobile a Blogblog Writing!
------=_NextPart_001_000D_01C6F7C9.5B556C90-- ------=_NextPart_000_000C_01C6F7C9.5B556C90 Content-Type: image/gif; name="world.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c6f7c0$f98f7df0$17369a52@cbyb1rzk8xq443r> R0lGODlh6AFEAYf2AAAEB44AAA6GAH19DAkAjXsLgQ53fL2ywrHYyqnN7kEbAFkqAHseAJosAMQi ANIbAAAxAChIADoxC1FKAHVMDpNDALsyCdxCAABaAB1rADFcAGJUAI1oAJpTAMVXANtqAAmLBxh8 BUKLAWlxAoFxApaCALeHAOh7BwChACGnADSXAFmiAXGqAKyeDMSoANmsCwC7DiSzBUO+B2KyAHfC AKi2AL3BAN2xAADjBBrsADbVDlLoAHTlAJrWB7PfANbZAAAASCwASEgARGMAMngASawAMswAOO0H NQsqShsaPUEqNlEZPHobM6MpO78eS94gQgI0RSpAQkdANl47TYZITZ9DQb9IN99OQABuSSFcSjdn MlhfSnpkAKphRrZqRdtoSgVxTi6FPTpxP1qFTXR6NJyHRMOMQdZ0PAOkOxaaP0WoOVycMY6eRpGm TLOqPdmnSgPGQCm7NTa3M2u+RoO0QKHKTbzMSOfAOQ3uRC7fQkrmNlPhPX3fOpfsRsHmQOPcRQAA gykAf0sAfGAAhn0Dfa4Ef7UChdIAdQAXeBIoh0cScWUmjH4nhqUcdLUtd9QnjQlOhhtChj1BiVVG eHJJeKxHfLxBg+RFfQBUiBdmej1WdmhliYtXealcjL9ZjuBohgh5ehKKdDiFdmNygoWNdqWKesF0 htqKdgCniSitjkOciGaYi4eVgZqcfLOlh9OWhgC1hyDGhU3Ecl65jXrLdZOydMvBe+bDcQ7pgijg fEbrhFboeonRdpTfgrTifNjUegEAziYAwzUAsVUGxX0KvZMAu7YLuusMugAezi4Ww0Ety2YazoMm xKQktrUnxtEWww1OvScxyThGzG00tIlNxZY6y8M2t+g7tQBgti5kyTNRs11SvI5btaZUybdfteZS vgaNxxR/wTuKvV1/zHyEw5mEu8N/yOx3vwCdwRaRxz2jw1yexnqlvKKiyrqkydydwgDDxie5zEyx zGjLyXO9y6q0yv//46mSl4KAfv8MAAD/DPb/DAgI/PYC/wD//////yH5BAAK830ALAAAAADoAUQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eL9kKKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp82PQIMKHUq0qNGjSJMqXXrQp9OnUKNKnUq16ksZVrNqfcq0q9evYMOK HUu27MCtaNOqXcu2rdu3cOPKnUu3rt27eNua3cu3r9+/gANzzEu4sOHDiBMrXsy4sePHkH0Knky5 suXLmING3sy5s+fPPzOLHk26tGm/oFOrXs26tevXsGPL7nm6tu3buHODnM27t+/fMANb0E28uPHj yJMrX878coLn0KNLn069uvXr2LNr3869u/fv4LE3/x9PfmH48+jTq1/Pvr328vAdbinOPoD7+/jz 61cfvz/yk/ZFF2ACARQ44IDPBWgfggQSaGCB0z2Y4IMLUuiggNIZ6KCFAkq4oYYcfgidhx9CiOGJ IiaYYYQaotjgiS0CJ+NsL9aIoIIrNsjggtfdWOOILLqoopBAAsngj0MOeWCS1S3JJI5C+qiilC8u OeOVnyFkI5NT5lhklT1GKOaKTkbZJIZH7iimk0d6CSWaXnJpJIppJuDfncx1KSePZioZZpx7bglo mz/y2SecfmJnaJ1qEqnnnGLiKSlyXyKp46BFUphmi5qWyOeblVo6IacWlrpmi56eGeqlRJJY5p4B Tv8qK3GVMgooq6KeWaebljY65qOh2iqooq0iSWiixsY567KinVTrmrcuyp2hqy6566pP9hqtoMe6 KCy2mZLIJYJYlrtasHRiK611Pl5bq7u5tvvrs9xq5+uw7lJb6HXm9uuYlrCaOKLA83aaIakSdnrj jgQTyqHC1LmKZojRojpqk5zGeS+zHFvm7H4ghyzyyOv5a/JmJKes8sosJ3Dyy461LPPM6MFs88kA 06zzzuJ17PPPBvGcQD5CF/0c0EgDTXR0Sw+dz9PQNf2c1EwzDTXUUU/t9NNcT8f10l9fHbbTVVtd 9tZNh321dER3jbXWU3cNd9J03+ls2lnnTTXVWkv/DbbfcAfOdtV8Fw642XqfLfjecL899OJw3yz5 zY837nXleQ9+eNuZK+455p33HTrnog/eOeOVk/4435FP7rrJpYMeu+BZb44566zLrnvht2te++Wn mw5277kv/frxrk3gUvC+f4635alTlzvacX+N9trRlz0876erDf32UWNtPPLkx5bz4YSbfvbzeOOu neqhE68+59xDrn3g9At/dN38l/cx6LxDndXklr3VSe99uwOeAde3QMWh73u/Q934ykdB1pxPfb2j neyGB0D3HfB3GFycAMkGQAxKUIT2g07/Vnin+FlvgB+sHfbiFkOvyc17OERc98LnuBT2bYYkvN7c /1hIxP+YxGhI5FkFlyibJDpxZq2hBxPLV48pWvGKWMwiSQqgxS568YtgDKMYx0jGMprxjGhMoxrX 2K8iuvGNcIzIJuJIx4MAoI7EYeMXAaBHw+DxjxS5IyC/QoGP9FGLfDykIhdZlUQy0i6DXIogI0lJ rzyyJo68pCZFUsmkTLKToDTKJmeSyVGa8pQrKaVLXoDKL4bSKJ98pSxneZlY0vKWu2llS1Spy176 8pfADOYaf7FJXBrzmHwRphhZqcyXEMQJyIymNKdJzWpa85p90QU2x9LMbm4mG5954n5Qoh5yivOc 6ExnzWakTveYc51HbKc850nP51ypnul553n0if/Pfj7nA9wBqD/XI1CXsTMBAEgoAHaW0OgstD38 BI85P0DRgiagogW16EUxCh2KRsejHf1oRUNK0o56FKT/3OhIU/rRf64UoyPlqEsBClOBynQ6Fr3p RUsanpvWNKMrlY5MYcpTmqJ0piDNKUnv+VChNRQ6TS3Z//bpLKXulKQatepRUUrTktqUp1hVqlaF elWWmrWsGT3rWTVqVquiFT1uVStbWxrSsbYVpy1N61JnFFWoKvQ5Cl3oXxGK0KcW9qGCfWpT+ypY qAJWsX8d7GEXa8+phgclc2VrV+la16tudqd69axasfrWrJY1pXNdq1dHm9rVkpWjRgVqUk9L29P/ xpW0eM2rasna2doC9Ep9JaxjKQvYwjrWocYtLnGHe1zmFle5yBVuRL+DWepolram3exnt0va1n41 rdl9rXXcqtfrXie0uN1ob1FrXs7a1rqjxS5oeevermbWoDIKblQb+1zC7lc6/H1ugI+LWAAL98AD 7ut0vVPdmfpWvrr97l1VCtTzslTCuqWrTm0bVM8SlcLwZe2EUZth+hbVvblVqXyPKuK6pva3skGI fpG73AQ/tqH/9e90KIvYyDY3sYGVTkL4g5DwihfF2v3qW0VL4uooeb5GBut708vk8abYvOiNbUxD XF8Um3i+Ef4yhTFM1vGcZMbORfCBdQxdAq+5/7+N5fGP3yydBXenwevN84pdeuGh4vbFd/1sk6Uc 19A+2clXzm2WH5ziE0sZyXuespcPnVKmGjjNcsb0mpcb3cequcabfq6duUNOu17YxJQG83qffF8O S7q8XXZtlR0d6xGLtcSo/nJ7b51eQ7dYvvec7I0LDOfJLtbHc96xQ3uM42QHWdSWlejHPgxipGoZ vYPOtqCzelKRjlmoW+2wpEF70g9vuKji7nZYZ+tkcfv2pSKNqU/zyu72Lnk2OTtPcLmz75ANOT3/ Hmg/Wyvw/QgUT+rpd3YUDrKAn8fhBacnwSPunoKaOTa3iMouvGkSUnAcJds0iAuOSYqQm/zkEf8p OcpXXkQmsJwyH4+5zGdO85rjhBY2z3lOXs7znvv85yHXudCHTvSi5wXouWlDZZqBdIMY/elQj7rU 0dKyUbfT6ndO4wmIXvVo1xPrpJ76GNPD8OZWNp4DBft2xD72Z3en7P09e0kKbk4B2F0Az7m73aGD d74n4O74ZfseO70duL9Z7eckZ9/z/vfo9H3xkJe74LuIZv9GVrGH9Svmpet1eqJk8Y6XDt4fH/rA T76CMlZ2mz+d6TY/FOL4TAjo/R760Yt+f02fprPczl9Q//f3de78PD/P973PfvSzb7zpT4/FS/d+ zsBPs+RHQveTHF/5frd96ZmflghwJt/CfX7/saO/etwHTeCyv/31SU/73FPzzJ0GdfltTGzEi1Px tS995Bm/fO4fT0tup2bjx3uDRWywV0//pnfIB3j8x3iAJxFq4H6AJHyGd1nCJ0/2hx3+p0XVUYEW iHb+lIH8soHNdx8imHYXSHHRQYKFgR8nGIIpqILTx4J04YIxKIPvpA0ho4Mtw4P9R4NqIWMBGHfb cYAyKGQ544PQoYTUwYPa8IRQ2ITPwYRM2IRQ+IRTqIRUGB08KIHGAX9m94Fzd4QjGE9RmIVVyIVp uIZTKB1p6IbT4YRtCIdLOIOMlFD9Any9V4CS9VAv2E/kpIOCyIXWMYh0eIhbKIhYeIh1mABy/8iI jviDKtEGZ8RLr5F6w1VgjBVdrwd+ZIiEBxGJVfiGj0iIcdiIdbiIkaiGZyiHbEiILJdQkkJ+AxZq 0WGEn2gnAKOKqGiKq9iLvpiIviiFjviIqriFPGdL5RFYxMZmmidZ5lcQuVgdAceLv8iKZziHp6iN baiF1zGKq1iKbchyXyAQyjgelVeLDIeLn1iN1/iGvQiPPiiMwAiJxsiNkYhyq1AQshgf6fhmOdaJ oTiN0zFkg+iN9YiQxKiN4riFwHiPUgh051gWFSAU/yhsGClc7EiG/5aNVyiODIkdWniMV2iF1jiS 8RiNyTiRtnGDDOaSFJeDIAOP15gfPNhNlv/IGjYIggRph/ZQj/chjzMJHUAIF154lEhpTOCQlJRU lE75fUwZlWHBkqTxlNyXk48hlVrpFVQ5GlbJfFj5L1s5lp6UR195lmiZlmBElmxZRGr5lkfXlnLJ P1ShBnB5lznRk3q5ly9ZLmTgOnwZmIJZHXgZEnAlMhNnUlamMokZX05kb7V1H40picq0DFlBbRbm mBWnHa0WmSBDcNjmmToDmZOZmYgWb3uFl7fFZaV5Ho3Zma1JUKYZmzNDmurhXVyVW2hZZCXGbd0W VOdWbbFlUu42VB0GWyqGVInWZ1wFb3K1Zc5ZnPAGnO4mnM7ZZJhJbrKVWUlVnFAWYnMJFLz/xmjq pW25lpu3ZWqchZ6QFmi4pl2sCV6eKVbyCVamlWf2hWT1qZmpNmjUdnDhaREn8Z+RuWjp+Z7jNmWw iaDiBZ/4qWr0dWuA9qAH2mUS2p7meZq46WgCtZsHMVYL6mIbVlPvVaGntpzsdW75aVNERaIstp4Z 9qLjqZ3pdp5hZp/0pqLXaV2HpmQBKqAmAaKsiWuNplomOmuyBqHwlZ/kqWdJum026qQYCqFMKldE GqGa+Z24VZj2QF6nWaJTCqUVFmshmqFYaqQxOqQPaqEMiqOrVqUsNqP3iaSdBaUreJZFplMbqlXV 6Wfr9m65yaMKWp1LppyGGprqJaEvKpwa/9anL0WdTLpl8daci+pT3LmdJNURHLCVwkebg/mpo7l2 eDqQRQqqpipOk/mjFcGlrNqqwiQGrhqrFcQHi8EcxgAWXKCqJiervFoVuvqrwBqsLFcJwlqsxnqs yKoRvbqsUZGsznoccHEIzMp25GBKljCtrvOs2rqt3Nqt3vqt4Bqu4jqu5Fqu4Yqt6KoTulEH5tqu 7vquGJGu8jqv9KoV8Hqv+LqttsAxm0QAwIQGwZSvAhsWp3ofA0tLBeseB0s3J5ARCdseC5s0DQsR H8MPFssPz3GxFgsdGMuxCXCx0rGxHquxG9uxGRsdJnuyKPuxJLuyHKuxHouyJZuyGEuyKf9LmfXa G1vnTKFIsx/rsiYbtNMhsid7sz8bsyqLtEVbHTWrtB1rtE/rs0Z7ixGLNBPrECcxtTfbtEebtCP7 tUO7tF2rtD87tWVLtlwLtF2bti6bs/2yszWhtSF7ti67skIrt3QLtXNrtmm7tWOrsn37tyrrtuYC tzQRtCW7t3o7t0dbsy3buJAbsjbLsjC7tl5Lt2oLuZN7p4R7JYa7Egjht6L7t4t7tnJ7t2Frt9Qh tKQruE/7tWarklU7SKOrumNbuk3Lt4i7unu7upVbu5lrutcxu6B0u8ZruZd7u2xbt8nbuqUrtoCb ujS7vCpLvHVUsTD7uMYLssw7s5Xbuqn/O7ItK7rfO76J+7KUy70d27lX9LDswb7I44nuCx7WS0cw Ob/4m7+AOCPyq7/++7+xxzECZ1gA7B5w54EP228I/HB2w5P8NoTasW/MWHhkxx4S3IHLNsGbSHgY HMHkd2kgTGfUoXAMt8AiTDIQTIRhuHArbB0vEx4mzMFxZ3gxnB8XrGyVB5Ah3MELl2M8THhlB407 TGPtdMA/HMHSBjvgsYnMdmxAtsECVoCWh2NS/MSZp2N9CMF8SMAiXIs6rML6BVliPGOZpsFXPIRC bHaXx8WrB2TKhXnE9Wx7yGzQxWldLMUY6cZstsVzrIlPdSX9y8LLNsNfHML0F8c01oxy/2ZYNtbB N2xgOSyAMuxmhEzEdZzIlDzJ8TfEmMZjiyx9iaXCb1xsMqyHmDzKzgfKyUVYeHK/GdxshAzFQBxq AWnJkhxntnzC4TfCqlfIpKzJu1zJlIzLqkxnQRyGCpzJzrjHwdzGGPzBYEzEH+zFzUx/yAXIpOod UByQdjxsTQzLAmbLvkfLpYzHQ2zHZMzLAGbOzLjNWJzLzTjIP8zIPBzP1rzHZuxXz0jO52zG7czP wzZ+8KyLzALDIOzDzVzKvZzQATbO03zQohzGQpzOCy2A3bzJxDx/orzRaKbAcjzQmhjNkKzKkWzM Jq1p4azR/9Uxumwd7qzGEb3QjUyL0P8H0FyMyBUtyxS9wzhti2qc0eCc0Jx80o+s0uIM0zutjkds yiTtbE3tWK18RCas01sszy380T/GzjXNzV5MgOuMbDBd0c/YxPqckT8dfs3mwwScxsZ2xZ7Gwffs zPuMYIwM1hudx3gsx1gd0J5G1qGGzedXwC0dmDWsl4WtMyz9vylM2GztvoeN2A08hoI92Q+bF7Bw 2bDQRtlM2Zz9qZWB2ZLiykP92DNDzfdx2IxF2qUtcM0kvyRs18A82N9hxJps2gaMHSksfrO9Hot9 17J9HXrd2xlJgGv9VE3ndclc28DNMrKcy/pRwrgd2yGD0EPt29Etfcv91ClNlDN3xhP/jcPSzMY6 PcWaB95pvMEf3dC3zNfD3dsSDMfClt7kjdZTrXpBFtx+7MQh7dK/Dd7azd1fZJlcURCn8A+cqM4g jc6GvMrNHcpEyMTS/Gk1/d8kvNzi93s9ht0LvNPJhsrL7OD8PcEU/NAizpQHLtZx7csAreKNPNZB TczqDeMgDczQfeFHreHa7N+bTOGDXdT8veI2ZuJ7rdAPDdcDbdYfztPkvN/vbM9A/uNfLeM2bclo TMXNvcy/nOT//NpHvGOcluILxZQ9TeRHjswz/uA+jeZMHePMzONd/skMLcnvbN0oftJPXtK+Dd2z /NDHbRJjbuTHluaF/OJynuSAHuFo/57lcb15Sn7Jcf7lzljfyqzod47gYV3SJH7N3e3VXg7LPibi r0zHM/3d1I3eVWzmM5zFda3bUR7Qur3X0SfcLg2NnI7f+h3RIs57nc7Hc42Rrb3Z+qva2d3Z+tZw lOQNSlHAwg7lxL7E/la/0B6g8DvtnBTt1k6xkLEA1L7t3A5Mv1oKTPEB184QUpcLM3cM005M3f5/ yWEI485y69657z7vCRHv9n7vvUrv+l4Q+F6v+/7v/9Dv9Arw+y7w80rw+m7w8orwe3EBbRlG4aDw wCGw4M7w714KFW/x147xGl/vzIrxvTQHEj/yiUEQ/djsKJ/yMiMrd6TyLv/yzw4ffv8O8zRf8+/7 GwBzCDp/CM+x8zoPHTwP9Amw89JB9ENv9NHh80Qf9EKv9Ezf80U/9EXv9EfP8z8P9E+f9VRP9VN/ 9U7P9D7f9Vaf9F1/9GSf9Fsf9VyP9WF/9VD/9VW/9EgP90LP9mbf9Fof9z/v9lJP93bP91Yf9lB/ 9oIP94Iv9YQvu/6B+G+f+IPP+I7/+FFf901/HU/f99Vx+UEP+GAP+ZJ/+ZP/+aHP+JpP+YSf9Zl/ 9pVvHaAP+Krv+aQ/+o1f967P+bDv+qY/+bUf+bMv+pTf+Y8f9P1xEqDv+WMP+cW/+dqB+mRf/Ll/ /NNR+pg//dRv+s4v+aPf+reP/bT/H/vUwfyrn/pqb/2vH/yyX/3K3/nHP/baD/zc3/3qP/7Nz/qq 7/7AP/EHkfzjL/26v/zlDxCHEghMUNCgQYIIBx48mLAgQYEQFz6c2NAiw4sYK26k6LCjRooLE3pU WFIhyYwnTW4kOZJhS5YfP0qMiLFmSJw2ZYp8yfGmRocuVZb8V9ToUaRJlS5l2tTpU6hJ7U2lOnXk oZ8dYep8iBVlTq9hB4b1WJbjyok31aINStam155oeb78GlLiWbBkI7pt6PZu0L5ixcY1KfTv3Jp6 04IFuXixWbNjsRKWvLVkVcyZNW/m3NnzZ9ChM0PumRUvyq+ALdb1ibd12sM5Yzam/6x6tc66d+dy lW2aMs6stktaBj5cJUSavIM31p249O/ZdnmHFF3d+nXsn5eSvh09pVzG3UFyn+54Mmy4KVnX/r7b ONDiqb/7bu9SuOXICAc75ol8Z2Hv4rKvtfxWsq3AiZzqJSoGG3TwQaQ2i0k1oU4LbzryxnuvPN2G MrA99ebLKD/U8tKQLddkY+k+5di7qMPJYCLuPBU3HCs6w0IEEMQEsvPxRyA9W6oruPiakEYiicxN RMXeuiq9vHwz7T4j9UPyrP2UDLDIvk7srbIrFWtLPb90/JJL/bAEMzjhAlsRTLraCtPM1yC08048 GZSQNj779PNPQAMVdFBCCzX0UP9EE1V0UUYbNTRISCOVlCpHK7X0Ukwz1XRTTjv1tLFJQxX1uk9L NfVUVHscdVVWW3X1VVhFHTJVWmu1NdE8c9V1V1579fVXYIMt6lZiizW2MWGTVXZZZpt11sHNWDSw ycpeixM5KAGD0ko5Z9z22jRR/FDMLMENbK8qtVyTuljbdfddeOOFdDszpfwNwQlf3FFHFisscbg2 +8UQvn2hY+zfZxNWeGGGG8bzsYMHvtdg7tpUk7CfKpTLORWT40/cjVNc7z+iHDb5ZJRT7lVCj7WV WEQQScOXuPgK7ni3rda6GGQPy9PQSILkFXpoootud8iWbbZYLxJjLI1mdXMG+Mr/m2PT968yYRbP Z67vUvlrsMMW+ymcK9I4QGvPfA7f5wR871/x7B1w5y/bJng8+RIce2+++252TxqRTHfpibdGjMee 7RrsbDXnpitcutMmGXHW7uJMA6Mz13xzzqualUQXeaZ7ObNDtrHDsiUek0PTazzQS+ja9Ht22mvP E3CMQ+dWciXRDXw1qrPcL0PUsu2S9d59z+1b4fFe3HhVf6Sgc+qrt/7HWY/Vfvtabff++6RmAT97 7ss3n9Px01d/ffbbF/YO9xvsp5/467f/fvzzz3P++fX3P+HrBVCAAxwa//pBQAQmUEj/Y2ADlWVA B0ZQgvdbxwTHBoiiQNCCG2yK9AI9+EEQbgYLPjpgCE14QhSmUIUrZGELXfhCGMZQhjOMFAejEgMb 5lCHOzQKDX34QyAG8Xo8JGIR2/cDI9pJiEtkYhOd+EQoRlGKU6RiFa14RSwGKYlb5GIXvfhFMIZR jGMkYxnN2L4splGNa2RjG934Rjh67oxzpGMddRVHPOZRj7KyYx/9+Eem7FGQgyRkaPB3A0AmUpHO euENCvlISEZSkpOkZCUteUlMZi4YmeRkJ1+1SFCGUpSjJGUpTXlKVKYyWZrBhSdd+UoUqlKWs6Rl wtpRS1xyEZa73OM5ePlLYAZTNLkkZjGNeUxkJlOZy1xmQAAAOw== ------=_NextPart_000_000C_01C6F7C9.5B556C90-- From noxaih@americandestinations.com Tue Oct 24 21:00:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcX6d-0006r5-3i for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 20:58:55 -0400 Received: from d141-25-111.home.cgocable.net ([24.141.25.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcWt6-0000jn-Kx for avt-archive@lists.ietf.org; Tue, 24 Oct 2006 20:45:00 -0400 Received: from 207.58.141.138 (HELO americandestinations.com) by lists.ietf.org with esmtp (S10G3OY06OC 8UG21M) id 7IO2XQ-Q51XH0-EG for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 00:44:57 +0300 From: "Justin Hollis" To: Subject: {tthemee} Date: Wed, 25 Oct 2006 00:44:57 +0300 Message-ID: <01c6f7ce$cb3f1330$6c822ecf@noxaih> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: Aca6QVWBKQO8YM614MRREEF5W614CU== X-Spam-Score: 3.7 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 The only thing to do on Wednesday October 20 is to get in on EQTD. It will SOAR up next days. There will be more than 100% from the very beginning, so do it quick. After the yesterday's promotion the share price raised on 116% and was 0.013. Those lucky devils who bought stocks at the price of 0.006 yesterday have already earned 100% of their investment. And they will make more. Did you think of it yesterday? If not, think of it now. Now the price is still rising. More over, with oil markets retreating, big traders are turning to gold, bringing it to levels never before seen. EQTD has made an view of staggering proportions related to a recent survey on one of their gold properties. The inside scoop is great and we will be looking at a quadrupling of market rate once the public takes notice: CHICAGO, ILLINOIS-(MARKETWIRE)-Oct 23, 2006 - Equal trading is pleased to announce advertisement which inform us about far exceeded expectations. The results from our British Columbia property show 58,000 ounce potential. Plans are already underway for immediate development. We look forward to this remarkable discovery bringing value to our sharer. At 600$ an ounce this finding is worth 34.8 mil$. With 865mil shares outstanding, this would give us a book value of 0.04 (last price is under 1 cent). The promotion will be continued till the end of this week! From pbigaefzv@purcellmurray.com Wed Oct 25 01:40:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcbVF-0004Dc-Pw for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 01:40:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcbVF-0003S6-M2 for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 01:40:37 -0400 Received: from [82.152.214.86] (helo=[82.152.214.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcbVB-000591-2X for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 01:40:35 -0400 Message-ID: <001101c23dd4$f76f68f0$56d69852@home> From: "Gardening RADIATION" To: avt-archive@lists.ietf.org Subject: LLC :: MusicNet ece Date: Wed, 7 Aug 2002 06:40:41 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C23DDD.5933D0F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.8 (++) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 ------=_NextPart_000_000D_01C23DDD.5933D0F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C23DDD.5933D0F0" ------=_NextPart_001_000E_01C23DDD.5933D0F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tropical storm Baja in braces landfall Afghan opium in crisis worsens a = Hyde Revamp drug trade policy? Such following Keys generated stated length source very important random = random simply option enoug h bytes timing keystrokes measuring or cosmic = ray background classes algorithms supplied providers Marc Hadley! Mobile California kit room a Electronic Reprints division of Gannett co = Blob Eagle in editor Walentis leads lively am irreverent trends = occasional rant laquo Boris Karloff didnt either Downing Memo legs. Registered a users or Page submission editorial director Steve a Mallet = being posted site subscribe feed Penguicon Wisconsin Symposium sun in = Tech or Days Singapore England Twin Cities Kwarup Dfjug jax of event! Secrets of Attkisson conducting raid materials or nations facility is = Baseball Sticky Fingers or Hartman whos perfected art catching baseballs = stands. Hugh Jackman is Dustin Hoffman or Eastern pm Speaks Pakistani Presidents = Remarks Michael j fox Exploited Rush is Limbaugh a claimed actor visibly = wracked tremors acting ad embryonic research disease of More Campaign = Watch. Dreaming wonderful life lived harmony nature magically appeared table am = day part valuable national events Cheryl wrote value am disasters = cannot. Mostly is im looking am forward getting havent yet readposted by jimothy = Amis meor lack decent of there a! Reversal Susan polls pundits eggs laid Cruise Careless a blamed Princess = of fire Editorials opinions Enron leaders Obama slow York spook is em = sports. Fiscal Samhsas of Teens of Truth Reserved Breaking cbs Arraydata am = Unravels Voters Political Dnaus Iraqis Yearscbs of los Alamos of Breach = is Probednew Liberal Radio Network in Politics Scitech Strange Evening = am Minutesthe Sunday Morning. ------=_NextPart_001_000E_01C23DDD.5933D0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tropical storm Baja in braces landfall = Afghan opium=20 in crisis worsens a Hyde Revamp drug trade policy?
3D""
Such following Keys = generated stated=20 length source very important random random simply option enoug h bytes = timing=20 keystrokes measuring or cosmic ray background classes algorithms = supplied=20 providers Marc Hadley!
Mobile California kit room a Electronic = Reprints=20 division of Gannett co Blob Eagle in editor Walentis leads lively am = irreverent=20 trends occasional rant laquo Boris Karloff didnt either Downing Memo=20 legs.
Registered a users or Page submission editorial director Steve = a Mallet=20 being posted site subscribe feed Penguicon Wisconsin Symposium sun in = Tech or=20 Days Singapore England Twin Cities Kwarup Dfjug jax of event!
Secrets = of=20 Attkisson conducting raid materials or nations facility is Baseball = Sticky=20 Fingers or Hartman whos perfected art catching baseballs stands.
Hugh = Jackman=20 is Dustin Hoffman or Eastern pm Speaks Pakistani Presidents Remarks = Michael j=20 fox Exploited Rush is Limbaugh a claimed actor visibly wracked tremors = acting ad=20 embryonic research disease of More Campaign Watch.
Dreaming wonderful = life=20 lived harmony nature magically appeared table am day part valuable = national=20 events Cheryl wrote value am disasters cannot.
Mostly is im looking = am=20 forward getting havent yet readposted by jimothy Amis meor lack decent = of there=20 a!
Reversal Susan polls pundits eggs laid Cruise Careless a blamed = Princess=20 of fire Editorials opinions Enron leaders Obama slow York spook is em=20 sports.
Fiscal Samhsas of Teens of Truth Reserved Breaking cbs = Arraydata am=20 Unravels Voters Political Dnaus Iraqis Yearscbs of los Alamos of Breach = is=20 Probednew Liberal Radio Network in Politics Scitech Strange Evening am=20 Minutesthe Sunday Morning.
------=_NextPart_001_000E_01C23DDD.5933D0F0-- ------=_NextPart_000_000D_01C23DDD.5933D0F0 Content-Type: image/gif; name="stages.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c23dd4$f76f68f0$56d69852@home> R0lGODlhwAGEAYf2AAAAAIkAAAB5BHl3AAABhXcKhACEibi/wMHivpe78jsmAGEjBYYmCJ8XCbks ANwSCABJDSdDAEBHCVo9AIpKAp44AM08B9U8AQheBR9iDEJjAFJsAIVjAJpoAL1RAdJsAAByABN5 CjyDBF+KC4t3AJeJBrR6BdaKAACtAyisAEORAFWmC3aoAKKgA7ObAOWoAAyzCCC1AD+5AFHMAXLC BKnMAM7IAOi4AAfYACTZAEjtAGTeAHfRAJzWA7jhAOriBA4ANCoAQDwANVoATIIAR5YATLUATdMA NAoWOhwaTkUfR20fToUfPJcSOrMoQNEtPABANiYzNjFEN2lIN4w4SKJEMswzQO41RABbMhprRjtT Q1JbQnNoD6ZkM7dhOtpcOQCEQhJ7NkqMNlSINIWAP5R0O8eGOthxSgCZThyrNESYQGeUQ4CSRpSk Sc2TN+ijPAm2TCPIRD65RlS9OHrMO5m6P7/DOdy0MwDaMSXSN0HTTGDpSHvtPqrkTsjuQtvtPAAA cScBiUIAfG4AiXIIiqIEecYFgdEAdgAqcxEqez8pdGYghHIpiJEtib4peewifQBCeyVHfUJDelg8 dIQ2ha0yibNOeORAcwddeR9UeUJdjGFpdXNjipVed8Fihd5rfQCKehl+fUd1d2txc3WKeaBxfcF7 fOuLfwGfexSuczOUglmTdIKUgqGbjMGaeu6ljAi/fyG7ekGyc1q9jYm5jK63hsjNgN63eALqiRrn ekDRf1PrcXzrjq7Sf7rlh+XkewsIshYGszEAzWEAxYsMtZsAx7sJxNsAtA4fwB0htjYitFkRuIEd v5kuv7ohvNEhyABNzhQzuExOy1g6xHlOs5tAsbY/suU6tgRkxhtYuzpZxlpWzn1St6dZvM1du+Zi wAWLvhVzzjmAwmV1tIWJxpGEwsl+s9GLvgCRwRaZtj6Tt2qSwHmYuqqox8yXteilvQC+sx68tULE u2qzyHHFtpzJsf///ZafoYmDeP8ACgjyAP//DAAA+P8E9wD//////yH5BAClsMkALAAAAADAAYQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MixY8N/IEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjQT0qXcq0qdOnUKNKnUrVItKrWLNq3cq1q1egVcOK HUu2rNmzaJt+Xcu2rdu3cOPKnUu3rt27eHGm3cu3r9+/BBUBHnwwr+HDiN8qUpTYK+HHkCNLnky5 suXLmDNr3sy5s+fPoEMT7CK6tOnTqBni7MK6S+PXsNuyiE2bJuvauHPr3s27t+/fwPGmHk68uHGJ wZMrX87c5PHn0KNLn069uvXr2LM/hKO9u/fv4MOL/x9PvjzmAObTqx+OnmB7ewHiv38vsD16+vDh y49vcH/9/fcBqJ97Bcmnn4Du+XeggQguOJCCC/JH4IQO1ldgfwZSmN+EGa7n4UTzPcjhhfnhd59C 9J1IYoIaWtiiiCLit6GG9sEo44oh2riiizyq2OOPHwb5UI4y+sgjkDfC+GKRMzL54pFGHjljjDqi WCWBJu6IJYVOGnSFkOo5V6KSVLZIpJVaTmlhjmYilKKaajJ55kI+yqllklFGaWFzfN5Fpp1tughg kRkOGqGKNd7ppoKGCihnh4Ye9OaFWRYIKZlwStjnpmvRuWSc/TU5ZKahrlkqpn+S+mmicEq6apoj Sv9ZKZi0NjTplq9KaWWXSuo5646+plmnrq6imieaDcpa67Ke0tirq2wWa6qwLCoq7ZjUXskqmqkC 6eyvSTIrrrAd/hduismaa5+jjlb7oITERqgufzdC+Gakp74Lr7mLSggurOOaJ2bAnHFq8FsEd3bw wlgl7PDDHKkB8cQUpzZwWfl4x/DGnGZMkMf25CMyyCALVPLHH4sccskeZzzyywbBvDLML6us8kAn 32wyziPzXHPIBblsM8s+kywQx0g3B/TOTDOd80Euo7yy1ERDjfLJS6csNc9Ub9101k6bXPXYRydt dnBZtxwz2GzvTLbRa1sddNxX4zy30VhX/fXSauP/jZDHZwdOm0JR7w3002u/bTfdczfutduL2+23 42Aj3rfkf1es+UQD643542kvrnbbpIt9c81C0xx214czzjLqq19uOtOC197YQp5DDjrcfH9OeUKF 7+5701Hn7bXlxLfO+ubMY5S78pEXDffkv2duvOPBJ5/917mP7jfyzYevUOeU83696NxjXTrR50ev c/rcl9/46GLHT5DtwcmxcPSm5/w+/6mrnPrU17/+DU11XDseyXomv6vZTGsGpB3+Jvga8TmEghhE jAU/ksEOevCDIAwhWDZIwhIiR4QoTKEKe4KHFbrwhSAxoQxnSMMa2nAhMMyhDnfIQ60ko4cVvKEQ /4dIxCI+DIhITKJWjMhEzSnxiXIpAxSnSMWelEGKVcyiFmeCRfxFBxxNDGNUtkjGMq5EjGhMoxrX yMY2bu4VboyjHMdnRqTIoo62m6MexYPHPuJxj4DUmB8HucVANrEMHiKkIqtoyEZa52LDOQlGJOlI 0XSqktr5wEM0OR1OSgYAoASAWUBJEFFq5gOo9KQ9UulJVa6SlQNBJUFkGctZprKWuIylLGkpEE2y spUF4SQsX/lLYrZyl8U0JkJUOcxe5pIizfwlL5tpS1omc5WzJGYwh8nMZxLGlGgh5UDAeZluYhOX rjQnL19ZS2A685zwzCY72ynPdMbTnO+EpzANgv9Ped4zl66MSD/jSdBgZlOdAOXnQZ8ZULOYhJzj DKVAQilKidqjouK8qDgxakpwQrSi45zoRiVqUY1m1JSUtIpJGhpQXxp0ofsEpjvPuc+DxJSeC82p Tf3pzpYuZKbtvKUvp3lLbNrzpfksKE13mtOB/rOm2bykQSB60VJWdaIhPWlBMJrVkFrVo1u9qlhB 6lWqRoWlCj0qPW/qzJmylakubatB7dnQpLo1qXhVaF6hOs2n+hSp/9QrWmEKWLsalalpeehUv+rV qpLzo2K9KlmtKtmwghWrjy1ISitykmPGVad4dSlbe1rUeS7znW+Vaz1La1fWCjOZ1EzoS4H62cP/ 6tWfgT1tL3c517/idqinnQtVM3tZx1KWopHtaGSxilmRkrK4HC1p2UoyyZXONa2Fjas181lTmSaE r7bFqTdzu1R0/vS2f6WtMXl7W4bitr3hlatadVnU2tZSuIvtKnONq1/+MneyjQUpWKG7XM1CknPW Ba1qvand7nLTvEot72HpWljy3jXC4wUqat3r2/daWCEUbqqH06tQqea3sf4dMGObG+CDPHayMO5v ZcWCUAi7t6D2/Sx4BWvL3Pb0tzy18Y2BLNunKnjIoUUvaHesz70y+JMWRe5YsyplkwK4uJQVqXNj /N+SmlUq14wmLMOM3SWTV5vMHCprtUnf+XZT/6iwXTND18xe1Nb3u3Ju6Z3brOa+BrW77dWwab7c EEJj8il1BU+iQWNohTT60E5ZdCb9sshKPxHSmI6kpTfNaQzuoNOgDrWo85jpUpv61EwctapXzepW u/rVPwEArBeGilmTRNZT9IwqHsOHOT4a1cCGzK/7UodgG7vAx072YIYtrgNDZbOXgbZKqYjrJCrl 18yeIwFEk22HVfkh2LaOAMYtAIGQe9wDKXe67UHuEnabYJmFSLipo25zs5sg6q63vsXDHSFJoi+K DStmSbpRk0a04FeVdmVOUm98F6Tc+Xa4PWwtOIQMt78DVrF+392Zhq/b4RB/uLKP45wqk5XAxP9d 8UAUThmGpxvdHoe4x+89cYqfrdAsRrnK/RudmNN83SGX+Mixo1zl7vfKyUW2cXzOdHt/fOjSifeU j570lCt9OA0PutP37XSoR126BB64l6O8X+icW+bt7vq90+51ore9kRzfS9zfzsS50/3uGbE73vdO Eb1XUhtOAXxYBK9Gv0OFohcPGOEHsviDCF4bkI+84wXS+MY7PvKQp/ziK08QyzfR8BwJeNkpwvLS UFLymvc84z3PesoXRPWdN8jjXf/62Ne809WOS8pPHmUvT5ckxpEk4Idv+8lbvvW0Z7w9hp/52jt/ 9s5Xvqhz/xbiFl3g//39SILvHOJH//myn3z/8l3f/OW/HvO09/73zT99E2c5xcuVennKr/zwj9/8 4se/8jevkMdDv/ycx3d9J2Uad3DSNX8BeH7oV3/2p3/kV3z5t3/pt34CWBglkXg8d3W3B3zFkVLq 54ARCHuEx3n8lxAB+H+1Z3NdgYEAlnQJ52ymIXzmV4L354AiWHzQd380OIEgKH0qWBQWd2Id1Xta RR6ot3wLeHwMiBCbB4ALqIAJiIRLCHsVaENUiBFUeIVYeGhbUGpaeBE3yBRfWIUzFA9kCB24kQc/ WH3Ut4aHQQFu+BKgFIe5kQR0+FBteId6WBTLMBRzmENnWB4ZFYiEiBGDWIiIOBGgl4iM+CH6/7CH kBiJkqhIjbgsCVCJmJiJmriJnNiJnuhGkpYRobhb30UVo4hhfNFhqCiKprZSsaVbq8iKDDFYsdgR iyZop2iK8JWLpdiL9IVLsAaLsShoHjGKtMiLsgiLyDgWqriM8FVNGQZICbZg6SRUbKZM/HRnpXVN bbZb6zRm1/iKFyZm2xVa1rhneaaNRLVO3YiNb+aN7Khm7bhNr8WOE6ZUnKQVefhBwqhj6OVdTxZU 4kVQNYZUfTVQd/WOOHWM3lVXbwaQSQZk74iQEIlhUHVd8EiMUnGI1QEBF+GK24iPHPZeCrlgBFlP iFWSOHaPRrZWykhYiBVftTVfLSlfJGlmuv+VaH62YRtIFH8IRAh1jAfFjes1k2dWkEH2Z3nGktJU lKalZAvZYUbZlDc5kKJVlW1FlO4IYhdZU0bxk0gUlCl5ZCOGkzcmlAO5U1e5khgJlSbpZjUZk3G5 lhFpklB5izL5Tj65jyrUj+PFXWZpWCUZjyjplnnpliqpXWNplYA1lVgpmLoUXoTJmEnpkCyZV07B kZrDjTpplNhIj13pjTgWkjblma8ImPP4YJhZZxNmj1uJTnLmjtvIW/VIkOTIUrNZmp6lkR2xiB7C DL74iRDhjJhGnJ9onMKZnMq5nDY0ic75nNAZndI5ndRZnW0BArTxA9YZE6wwapbxA+DJnJj/CJ4/ IJ6VSJ7laZ7NgxvkuZ3u+RXtCRMM8J5khBrhqZ74mZ/jQZ+q1g+8oZ9Csm0AKh5EMKAG2kb8maAK uqAM2qAO+qAQGqE2d6AUWqEWeqEYmqEauqFiAYPrIaGBw6Fv56FhAqJmoxD8kKL8IBAqmqIDsaIv ag8qWhAuGqMt6qIwyqIEkaM6uqMyeqM++qItGqM7iqM8uqI3yqMiGhpHKqNBmqNQahA1qqNK6qRE 2qNXSqUIgaRZCqNV6qVNWqVLqhkmIaZKyqVWiqU2uqZSqqVpmqVOKqZxCqdo+qRpWqdBaqInehBm SqNzGqQ+GqV9+qdf6qdyWqdn+qY9iqiK/6qmY7oZUIqjhlqofmqlSAqklpqpNJqkPzqkd+qoeLqo osqpjwoaiXqqikqpc9qngtqmgcqnRIqqldqqclqqnSGrbNqklbqqWxqpsPqqUuqpuBqra1qrtjoZ zhGmdoqlqvqjjQqqv8qmgOqmojqrRfqsMKqnSYOiQ4qpb3qpiSqknTqj0OqqNgqkp+qp4wqu3wqu 5Gqsxwpw1FUr2upF9FqvGxOvx0ai+poec8Ftvikejxawp/FlBCsRmvAZiCcRZrWwOGcRoNewQWiA JIV9o+diDjGILYhiKDZvGJsQ73awGXuAHFuyC4FlblcREmuyJ1YWK2tZLQtZ7zexDKGxjv/2sRe7 VZqZsyz2GANLsxlrSfPKsDBrZQdntO83hAUXXUgrYAR3fWNHskQos0U7syhbYFO7ZYulcQvLUVpb Sjv7Yky7tVRWdEtbVmSntM7VXCjbsGTXtAbHX1mrtGaLUobRdzpbdi34sjzHVdlHZVTHtgV4dUZn sTI2eldLaIUrf/CHdEWIgTRLtWSrZQPXVYPrtwarUYFbsrv3VRmXX5eruVj1rxvRtR0bfzjbty5o dVNnXKxLuDnLgoabuCC7uahbWY57XC2Ls5KbZYWrutdXdSybu4YrvK+7sTMGvDObGlQbb0Wos1P7 XLqLcS1GvBdLgKlru1iLbMP1tlZ2iCr/Zr3JC7a1G1HDW1Y7d3KSZbrmq7Wve72mi3jii709q7qP wa/l22Kny727u7oqp3PHi32/y7nftr18O3VX67uum748q3SJZ7D0W7/qO8AGLGMbC7n1q7etu7jC G1KHoYFA27r+278B3MEbrLyUq78HLLkXt8Loq8FJK2Dm67z5W7wUjLoBHHYZ3LjFi7iMlcMqbMFJ R7rZ+7AdS4Tku7xwG2DeC8DHJb3Q61EfhVwsXMRbRrftW8DJxXsyzMRg67ZPm8QcO78iHMFRu7cg m7XrO1Lei7Sai8UuSBj4Wx0iSxl1rBl3rBZ36x1abBx9bB15rMd50a97oUOEbB61EB6Z/2sZyNub EJu3lxHImKS4FWvFLKuyNdvDGXhtJ0uycou3hujJlwzCnczGovy1bvxtp7wszrbI51vDUdG7h8vJ sByzY8G4SjzKJ7tzNyvENHw/ShS3BdzCP8yRVey1awuzUitw2BtjYWdyZ6y4Lna2VJy2joVwqxzC azy2zXxS1ly7HEfGVHVpL2zDVde2Fuu3twu4PszAXQx/EmzCsAvOM2Z9KYzG8ja5CszOwNto0cVs 4ixlhrzL/Fu19jvGDGy1cXzFUMy2PSvDv0vG2vzDf/vQvNxtxCzA7szL/UvK4yvRzBPBywvS7RzP bmzSCN25PKy+vpzL3FuxRse6VjfMz/8Fvvqsv/Esv4TryhaHZSRdMZd1wChc0hos0wbdu7kbvAsc 0fIszRrN0kZtubpMwttb1BzN0x2N0C091QET1CEMY0in0FoW1UKs0Cq9zj5twgg3u1L90WUMz/lc zjg91Jtc1RXNuRvN1V09dtMMxTCtxQ4L009s04wrs82s1VvszYo9vl+MxSy9xB38x6UstlL8tQ4L 2Y1tygRMgGdsgBAzx1GXmRRzx+TMx6I9MXmMr6pNRYfc2q792rDdEasNRcIw27adHNBw22sRCLrd 277928Ad3A/K28L9arGNacVdr8ftFKWw3M79F8kd3dIN3PXwakww3did3dpNnc9dSTz/FAbbHd7i 3TDd3UjjLROPAInlvd7s3d4iCtruLR1wEd/0Xd+RISaHkN+HIBD6nd8Dsd//bQ/6XRADLuAFThD9 PeAAHuAJvuD8TeACTuANbuD77d//7eAYPuETLuEW3uAL3t8cXuEIzuEGPuIIruEQvuEXDuIW/uAe TuEKfuAvHuArXuIMnuEw7t8tHuEzXuM7XuEg/uAmHuQvHuQRPuTa534m7uJILuRHDuFPHuVLLuUi nhAOzuMIceUA/uMfLuVRfuVQ7uRUvuRaTuNQ/uNZPuVYbuUGgeZm7uVdruZrLuRozuVwjuFyTuN1 3uQMPuV47uRx7uWQAeZjvuV5bugM//Hnfc7mI07oY77mVT7nb+7oYh7mcH7pgn7kke7ois7kjN7o ky7ngV7pkm7oXV7lIg7mm57ndP7kke7pi34Qih7ooy4ZhF7mry7oiL4QnS7pbZ7iaY7kph7rof7p v/7msE7sZ+7qwV7puW7psN7pqo7s0/7nq47qvj7nvS7syp7rz17sXx7ulfHhOp7i037sMG7sRZ7g 0P7tj47tu17mK37g827p1d7mlK7prS7rJ87uKs7f/r7vYq7h9O7sZo7ow57wAa/vyN7kww7qQ17w Gb7jBj8YJoHrwC7v0E7qAw/sxp7tFb/lCE/trM7v4K7sIC/w7t7r7k7qp+7nx37uB/+v530u8skO 6OJu8i+P8aIO85hO43jB84u+7bre7IWuEELf7nSO8Ebe8Q4h7b9+7pyO81NP8vku86++7bWu5UYe 75D+8GSe8zFf8x7f8FBf8UDvJ3hu7TM/9g3v9Cgf5ruu9Jeu8WKP7nc/63Kv8ydu9EmP9wN/9mHv 8zT/5c9++H3/9gJf4nq/+IJv98DsFkjP4l3f6BRf4E1v7+ae+QBP7vQ+8XWv+fNO8eku6hKv4GqO +hfu95t/+iye+IH/+ieP6+W++tW+8ADP6qqf++ze7/1u94LP8YU8tPadHcJR/Npx/GcY3MiPoMRf haAGh4Ns8nBv+L2f7pDf+SIv45b/r+qfX/DWT+ldz/IwT/DgX++/n+OkT+S9n++bePGEj/ipv/Fr z+e1Lu5QT+vUr+nkH+oyDxD2DtkjWFCgwYEEExpUyLDgwoMQHxL8V9HiRYwZNW7k2NHjR5AhRWI0 MNLkSZQpQTqcGLHhRIkHWyJkKDGmTJgvdc7kqXPgQqAOY/7EObRhQqRCay5denMny6MsnUKlWtXq VaxZtW7l2tXrV7BhpUbF6ZLp07Jpb9o02zPt26BB0RolOpds0rNP6VKdSvPQ379uxQ4mXNjwYcSJ sW6UWVeuWpo1AQM+S5lt4LwPKcP1qXBzZrN4Izv2PBlyZL98r659qdL1a9ixZc+m/137ouq4M9m6 3d2zbs7eUH+3lCsadU6yqe8qPc55al/MzPsqpl7d+nXsiaNHF2j6uNHml5vunD785WTR4JW3RQj0 sW/Q5pvPH539MDz7+fXv59o7ePDTvisrPd7qI248tAYkjzXU1HtLwQQf5Eww/iq08EIMWWIswP+E sgy07izzTsHPNONuRPEEQ7G9sRpEL0TuJItxRAnRQ+qzhGzTcUcee/Txx4wyFHJIIrkC8kgkk1Sy xyKbdPJJKKOUcsqrlrTySiyz1HJLLrtkkkowwxRzTDLLNPNMNNNUc00223TzTTjjlHNOOuu0886t vNRzTz779PNPQD/Cc1BCCzW0q/9AE1V0UUYbdTSkQyOVdFJCH7X0UkwzBckRTTv19FNQQxV1VFJL NfVUVFNVdVVWW3X1VVhjlXVWWmu19VFKc9V1V1579fVXYMWiFYBbO32n2FN3BWDZYJt11k0dyFyW 2WertfZasKbFdltuu3WIWm/D5RZZcss1d0lx01U3XXPWdfddN8+Vd156ZYP3XnztrHdffvvtKF+A AxaYAIELFtiZqvxVeOF9DXb4YYgjlthahiu2+GKMM9Z4Y4479hi2iUN+GJsLPzb5ZEtFVnllllt2 mUqUY3Z1WZlrtjnLaYm11IibezZ3Wp+DFlpHoOd9+egMc0Z6aaYZAiDcoaM+MpX7mJu2+mqssx6U AzCl9vpr17QWu+VzwwD7bLTTVlvRsdsWeW2445Y7VSLmtvtuvJF0e2+++/b7b8ADF3xwwhPO+3DE E1cc2UjBKfxxyCMXeHHKOZb88mYr13w2N2DFHFgkPhd9dNJLN/101A3dfHXWW/8nGdf5TH32On2E oWJXYu+Ydt7j1D1uQXbvfXjiuZ2EzTgivQTK35vXPJtbXXB+euqrt7f4XmnZm9RbrPf+e/DD57Ma 8TPG/nz00w+4fPZF9epp9eOHEn7561fsJJ3b11/Prui3/3/D4G9/A7xU/gh4wEQZEIEL1BsAHfhA CFpIHFyZRVgYeME/BQQAOw== ------=_NextPart_000_000D_01C23DDD.5933D0F0-- From raqrovdai@project.com Wed Oct 25 03:13:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GccxT-0006Wm-BU for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 03:13:51 -0400 Received: from 210-84-4-57.dyn.iinet.net.au ([210.84.4.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GccxJ-00023n-PS for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 03:13:51 -0400 Message-ID: <000a01c6f805$101515a0$390454d2@Desktop> From: "from: Powered" To: avt-archive@lists.ietf.org Subject: excited putting Date: Wed, 25 Oct 2006 17:13:25 +1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6F858.E1C125A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 ------=_NextPart_000_0006_01C6F858.E1C125A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6F858.E1C125A0" ------=_NextPart_001_0007_01C6F858.E1C125A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Covering National deadfront lugs rigid barrier attached body replace = utility knife Pass or tightly prevents. Covering National deadfront lugs = rigid barrier attached body replace utility knife Pass or tightly = prevents. Drinks blasts seo contest Camtasia Produced Flash Videos Webmaster in = Resource Webmasters a Flooring Matches is Comments Permanent Submit is = Netscape of headline from Powered. Crowd Developer Thursday Franciscos Moscone losing leadership pointing = evidence regained is. Try Price day Antivirus Update Package applicable Norton Regauditor xp = Spyware Doctor phpsystem am mexp pro of Xpvista is Terminator Virus = Cleaner is zipsystem Expstudio Audio Editor Tcrisis prcsystem Palm. Aitel advocate researcher Immunity Miami a presenting or major overblown = wants hack children anyway ways theyre a targets! Servers in Opteron a months Santa of Claras responded modules chip is = promised fourcore enthusiast! Hackers review modelthis of enormous challenge in Ivan Krsti director or = platform efforts am Olpc in Cambridge Mass hardest thing. Champions League luck effort a move Frank am brings am tenure in enjoyed = successes fa cup! Photos Send shots Dear visitors of front of shot of Grab camera = meanwhile am archives Linking thoughts. Money or Bargain or Website Fifaus Revamps use Nigerian scammer a got or = Thanks add Working of pr posting dives Pixar conquers of field in low am = Forum rise in getting message adds am Site Other. ------=_NextPart_001_0007_01C6F858.E1C125A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Covering National deadfront lugs rigid = barrier=20 attached body replace utility knife Pass or tightly prevents. Covering = National=20 deadfront lugs rigid barrier attached body replace utility knife Pass or = tightly=20 prevents.
3D""
Drinks blasts seo = contest Camtasia=20 Produced Flash Videos Webmaster in Resource Webmasters a Flooring = Matches is=20 Comments Permanent Submit is Netscape of headline from Powered.
Crowd = Developer Thursday Franciscos Moscone losing leadership pointing = evidence=20 regained is.
Try Price day Antivirus Update Package applicable Norton = Regauditor xp Spyware Doctor phpsystem am mexp pro of Xpvista is = Terminator=20 Virus Cleaner is zipsystem Expstudio Audio Editor Tcrisis prcsystem=20 Palm.
Aitel advocate researcher Immunity Miami a presenting or major=20 overblown wants hack children anyway ways theyre a targets!
Servers = in=20 Opteron a months Santa of Claras responded modules chip is promised = fourcore=20 enthusiast!
Hackers review modelthis of enormous challenge in Ivan = Krsti=20 director or platform efforts am Olpc in Cambridge Mass hardest=20 thing.
Champions League luck effort a move Frank am brings am tenure = in=20 enjoyed successes fa cup!
Photos Send shots Dear visitors of front of = shot of=20 Grab camera meanwhile am archives Linking thoughts.
Money or Bargain = or=20 Website Fifaus Revamps use Nigerian scammer a got or Thanks add Working = of pr=20 posting dives Pixar conquers of field in low am Forum rise in getting = message=20 adds am Site Other.
------=_NextPart_001_0007_01C6F858.E1C125A0-- ------=_NextPart_000_0006_01C6F858.E1C125A0 Content-Type: image/gif; name="boost.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6f805$101515a0$390454d2@Desktop> R0lGODlh1AFoAYf2AAIABYYAAACIAX+NAAAOe3UAdgh7e7HItc7Pt7O8+zgjDlgUAHIZAKYgALEq ANUmDABJCSY9AThLAG5IAIc5BZY8ALpBCOE0CgBZABhTDjpjAFllAH5TAJFuC8BdBOpcAANyAC6E BzWNAGiOAIB0CaCAAL6FAuOLBgqaABylAEysDlWbAHmrBpKZBrugC9KSAwHNABK9Ak68AGvHAIO+ C6G7BMO2ANnFAADuDRfTAE7kAGjcAIXlBaDSALvVDuTTAAAAPyECQEAAS2EMPoYARq4FRLUOPO0A SwYWPBYTOT4cTmsaRYkhPZYTPssSOdEfRgBJTRJLR0c+OmA6RYw9MZk/Qr9OTeU2OABpSCdsREZk RVNaToVoAJ1UNLNVPNNSSACFNhyMQDZ7P2pxOYKNS5l+S8SDRNN6NACRMRKuMkmgO1KgOYyRQaWk SbuZTtylSga1OBvKTjq0M1nJR3PMS6iyOb6+Pt3NRgDTTR3kN0zXQGDZTYTWTpjoMsLjStbpQwAA jBYAekcAfFIAeIgDgJMAcsoFhuUFfQMgiC0Ucz0leFgjeHoljKEteLsZfN8jhQpBjBdMikFKi1E5 joJHgp82i7hHjeU0dgdZfRJZgjxTi1dZh3xZd6xrjLxtgtRbcwl4exuEjUN4eml4jI6BeK55cceL gtFydwykhy6bjU2ahWacdnmdepSXgsyaieiligO7jSW1fDHBfGi8d4jJhKbIesTGitjIgADcjCHq gTvni1jdg3TRiKrhjMfmhNXRgAMCvS4HszYAvlYAzowMsqIDusEGxOwCvQknxSActkElumUovYEn vJsuy8ooxOklywxIxBw3uzpBwVI8wXcxs6k8u8ZMteBKswBjxhZdzjtpu1xtv4NuwqxVxL9ntuFf uA6LtiqEzEWNsl+Ju3qOuZ2OvsB7y+d/ugCezRKTwEiSw1SrsX+oxaCtxcGbuteouQDMuye3zUzG w2C3t3u/tq6/wv//6ZyWq4OAifgACwD/C/j5DQAA+fsA/wDy+////SH5BABDw9MALAAAAADUAWgB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDM2HKWxo8ePE/+JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+RIIMKHUq0qNGjSJMqXcr0p9OnUKMeikq1qtWrWLNSZcq1q9evYMOK HUu2rNmzaNOqXcu2o9a3cOPKnUu3rt27ePPq3cu3r9+/gAMLHkw4LgAAhROfbFuorePHkC8ejkz5 oOLLmDP7Pax5cOXPoENHnjwQ3ddnohV2Xs167j7MnFvLJpm69trZUBHjtmu7t+/fwIM/1KkxgPDj w3crX67TOEHn9gJIhw5doHPj1aNHny7dIHfr3LGH/9/+vOD07eOff0d/Pj37gevZdy9P/711897P 19dOXz/z/wDKxN+A1V2Hn3bZYadQgQPCl99+90HooIPZNRhhhNRdiFCGGhoIIYP3gchfhs0EaCJm HXFYoYIfTlihhCt6R6CMEnZooYUxqriQjvgleKCMIsaI3JBEXsTijUdqOOONMNJYHoctHsSgkBM+ 6SJDR+b4o5IU9ihlkWCGCZGIXUY5onvw6ReeeN95SCWX4Kk53pxA6iffiw1qCaOdUHI5n5iAVkac jV422eeOSDqZpJJ4TumknyNWuaChW9J4qI8DnahpYh+RGWKlCEqK6JsXLorjhlZWqmekWFJao4vx Mf8a0SGB1gocpqWK+imckpr65p+iNppqk1di2BCuSyZaZq+2ikVEsxINiqSdcSZUIJpxXjcnnWma B2yj663JZHxTYqtrrOhtqOaWyG7qrqbQxuvQu/S+lYJL8uar775DSstvWfUGLLBT/5418MEC/5ZP wQw3DKZOCxMUsT35VDzxxAJhLLHEFVOMccQLWyyyQSN7PLLIHXc8kMYqZ7yyxS+jTHFBIaf8ccwX C4Twzu92lLPLKwMdNMkzD91y0TcfdLPGRXO8sdNGPz200ECDnPTVDmeNHHE/Mx0yzUo3jXTTTIst 9dRou/xz0Dl7fTbLVZNt9tA8132iR19TrTbYRGP/vfbZgM/t9t8zt0002nCPbXjYWjf+m7RJb5y4 1F3HfbjSMJsMM8p5g8y3524jzrnloMcMtN2op14S4n3zTXnUe1+uUN6BLz7116FTnbjne++u80iD qC48wqyDPTnOlcfu+uyCX0670LjLHjnpbJvN+/DY75x25IRbb3nGZZct9vN6j3+8ytOP/7nuvOud /fso4k1y5qbLXnjKUC9Pc+aj958/+ziTnvHw9zLklc9xCPyMvxKoFPg5sGcMbMoDJwiYCFrwghjM oAY3yEGGUPCDIAyhCEdIwhKa8IQoTKEKV8hCrXTwhTDMWgtnSMPWxPCGOMxXDXfIQ07l8IdADKIQ /4dIRKH08IhI7EsRl8hEQSXxiTMpABR30sQqWlEtU8yiFq9yxS568YtgDKOYthigOVDwBCQUoxrX yMY2uvGNcIwjZEyCj9TZgYx4zKMe98jHPvrxj4BsySYCSchCGlJ1gUoJRhQpR4bppZGQjKQku/iB h1QyXpck0mFI8xVO2gMAtfmAKDNpj1FmkpSlNOVAREkQVq6ylaN8pSxXyUpXCqSSpjxlQS6pylTm 0penrOUvgYkQUvbylrOkyDFzactjwtKVwyxlK325y14aM5kAy8kny+JJULoFJYsE5zWlKUtUjtOW qXylLpFJznZOM53qfKc53TlOdraTlwap5zvpOf9LVEZEn+4M6C6nec5+5pOgybzkIzPizYJs0psP /SRpQLnJgVR0mxdtaEMFQlGLcnSiFb2oRDm5UaX4U6C4HChC8anLdZITnwdhaTwRStOY7nOd/jzp TQ+qSlw2M5bSnKdK7SnQl9qUpgDlJ0z3GZySbtOjGoVqVAlC0ahOFaoepepTt9rRrDoVKSfNaUDn mdKgzvSeyNSpUVs6ULImpJ44PahCXFpOWp41qGIdKj/lGta2jlWuaS2qWmvj1I12latbTSxGtbpY h3L0sVq96mEVy5RglrWmRDWrTNFKzFsOFqabvetLgZpQ0o7WmqY1qErpelmzAjahTAVsLMmaV6b/ +rSYyClsZLPaWMhG1LCP1W1wPzoZyY5UpF1xq19jW1Zo2hO0opVnPJWLzb2ys6BzlS1fYctMwb42 qcz9a2tRak3vdmULCdGJcIcL2d72drIQpaxVEWvcr2YKnBdJCXVFq1znAnOp0D0qW/eLUtuqdrAF zqxRiTpe8xq4uuHtb2wTLFblKBa49d0te9v7VcMe9sNY9ervFpNfcUq3rg8WK3UBLGBYWjeusFXt gh9MY84qFbM1/utQr4ldGy9VxshcqEYielwOS1Wkv2UsZRML0uLyFqJI/ko0l9nTZfJ0uYHF5mxd HE3PGjO1+vSpmIHqTNuCubW8JPNbU0te/3pZ/5ik5bF/a2tjsyxwIvZtSJ6HwkiL9LmKCGaYQvMy lj0rxNCTTEug+bXoRDv60R85pKTxCOlKS5Ials60pjfN6U57+tNImbSoR03qUpv61Ki2MKhXzepW u/rVsPZ0qmf9n36Qegu0znWsd924Ox/lz6ABtp9znZkNVEUsiF4yr5dtRG0SGSLJLqmwnUhiAVhb AAK5trUHgm1u2+Pa9iA29oasZIdEO1/dzva3CdLtdLub2Tlcb1WLO9GRWjSj7Q1UutldEGy3m9/w 3pd6DTJfI5OUyU/15rQpk5J9e5vf/u73iMXdwiKzN8Mh3vDEV5eahnN72w73t8PXHW6Kz9Cxjf/F uMYnW3ISi8bjEJd4xAFuckSCJL7xNbiGNW6rkJPc2/9+eMBhCFwj6zzjKYfWvmeu7p+/e+g6dDZy jRvcZxM55wuPDCO1LXJwN13d4K556oqSbKib/TdlP7umbeEYX5fY5Q/Db5jEXhiQZF04dw9OJuju mUjLPe4u10ZRBM8Vwrec71kZhUweut7kwL1IfTb8QCR/EMJr4/KYr7xAKE/5ymP+8puXPOcJQnjE swQYdSn6sB9PJEZmPvSdJ33sZ7/5gsTe9gaxfO1xP/mNm94n5MZqV68eZccJ/vikTwjyec/80R8f 9MzvvT10H/3pq90jA5cqz4uu8L9DHpzLT77/5q1f/d2Tv/fQPz/soa972if/94DBMNIRTpC8A8f1 nXe/+vcv/f2Hn//ix36h13+1B39PMWRXN3+Ml3b8kn7mJ3ufJ365R4DWJ3oKkX/kR30UeH2rdxPy dmGq4X2tJ3f/d3sEaIKG53wSOH7SR32jZ4CbQXAKyFjdx3r9An4VuIIYuIEn2IIrqH6jl4EIIXgw +BPBp2RQ1mRX1TivN30RyH8puBCil36fN3tN+IBU+IMcOHQmmBFd2IVeuIVqB4YYgYJEQYZimIZq mEhF2IbusoZw2HFuOId0WIeoFoeVlg4NY4d82IezERt++BSuEIhPAYiEKEK68USGeIgjtIg1/+SI jKgZhcaAG+RJeOgbeAGJJqSJkdgZZ2GJLwSKl/g42jSKDEdrppiKbOF2DtFoFtFo6KRXRwGLj0Fn ReURjUaIXfZWEPYRi9ZXClYUn1VdrmhSr3WLEDGMzyRLujhh2iWMDQGMyCgUyjiNZWGLxYhbxdRM cqVrGcFjWrZlccZmnSVmtMRmqIVOPUVNb/aMp2VZLPZMKaVm7CiPafVTsdiO5YhUZWaO+lhNaZaP 8+hgawiOChZMdyVU95iQevVj/cRWWmZQBpll0siNDcZg8ORamaWQGqlZzAWRwXhduAWPdCVrOTFl DjaROpZlLLmSM7ZTDOlXzYVZA3lUN6ZTKv+JZrKYkx3JkTqpjWrFjSjWjHVVkQS1i93Fkylmk3JW Zh4ZkLP1S/kIZM1FZzrZXeHFkD/JXbu4j2uGkeTkjRhRUEYZXROmlDFWli1pUzVpix0Jky3pkzfG iwYGjgClks84jD+ZjZKkE3CljXO5kTR5T3KZkoPpjjzpkM91mNzFmIJ5VrVEmA1pXYt5iwMJUKLW BfbXis4UlHtJjuVVTpEJkCVpV+dEjnVGZW4WVldZj/a4V05ZjuPYlqN5jvjImj8VU7fZi5fIl6qo TL/ZisE5i2CiDAXTicgZGMO5nMzZnPGSnNCpRM45nQ0UndZ5ndiZndpJRtTZnb+2neCJeP7/EJ7v 453meZ7o+RjkuZ7seRLG0J5+kZ7yORHTUBDweZ9UNJ/6uZ/82Z/++Z/7KQFzhJ8EWqAnUgM1B6AK WhaJIEeiuKDfdIiJaKDHBqEWeqEYmqEe0Qka2qFnx4oWBEK1EIkewQ8myg8CcaImOhAoyqL2cKIF saIuqqIr2qIpShA2eqM4+qI0uqMsqqIuiqM1mqMoSqM56qGOQ6Qv6qM22qQGIaM3eqRLGqQ6SqVR ihBFaqUtKqVbqqRSiqQI9KVHmqVTWqUzeqZPeqVlaqVL+qVtyqZkyqRlGqc+CqYOI6Yx+qZ1iqZ6 mqd6yqV56qZxOqZrqqODWqhmaqcF06Q1/xqogOqnW8qjQDqlZMqlRiqpMDqniUqnhtqpl0p0lLhB d/AQD0oZhHqqhfqob4qnTqqqauqnlBqoaaqpnNpByPVGpfoYqLqjkcqmtIqoKcqoB7GrMTqpxBqk rQqsGHSrXDEFDJSrfKZNXiqnVeqqjTqssLqnfQqna9qr1BqswNqi2bNJpMaJ8YmpRTqp3Sqp2Tqk 6kqoszqjPXqq7wqkMEqk6Wqsvlc35gogK9Aa/SpkHJQ65FovK/CvMlEGm2EViupQ0FokB9uwEjux FBsaIOoYDxtDiBaq0GJfHBstyukVjCcRHfZsC/GxvCUZB+GxVLWAIFhuCFF23aRsHQazMf+bEHsW qiiLESZrs/mmZylrGxeLsxZRs0F7s8i2skrbeCXVtAwhs6qntDJ4tA6bZ1arbJ/4tEhLqiFxN3jm WEmoUfRmidyHb/N2tsP1W/U2b/fGrBl1qzXbeIiFci0btsSlWwU3smxrcW27tfbWsxu2t4I7twmY hMSVtkFbsvVmcYNruEVmtxhFGvDytS2bbyxntCsnUSKmfXO7WAcXtSiHuTuXuEd7tZ0LgvOFYVMl t1P7skt7b5zruUhXVT/LuUsoX7ulurG7ue5Fu481uSSbZJbruuUGX/Qnf0Ynu7NLtEv2gTB7u1ib c/S3uR2FvL7VulvrtFKbcKM7fNybcSz/a72lm7vd27xHl7la0Qgz0Ul0W7ZUO7LH5WS8+15P1rvT 27bSa7O3i7fbi78cBr/1W73l27ym+1FUS7jli3N3K78GfLcIx7oue7YM3Lv4lrmgexulSLLtW7y1 i7t0+72BG8AP/LzzW7o9y7/Yi8AdLMLGy33Mm8IgXLWLa8EXB8MgJr61i8IcTHUFh753o7MbnLL5 O77LO8LJK8Dgq70xTLocDLb9q8L3y2RIrLku7Lf628FOK74gNrw6fLlWLH9a3LnS28JaZRI2sBcd AcTF+7Ye9sH+O70JeMT2+7cEh2RNK7xC/MT4C7may7dCPHxOpnrdJIp6O8huTMbgW7dj/0xSIeXG iuzACcfGM8y38hvHK2x2O+sbmZxbQjS0zQK4gALK+rLJXiEYFXvKqBxwnvzCjvwYLBcUO3vHoUHK X3FyQmG1jazHPlu0WrvLr3xzJ8usSUe5kiHMB3zJeibJuWp1djzItNxrGezLrYy11HzL0/zLH5Gz J7vLR3HBx1zNhza64by8VXxfgGRvfoy7YAyKSuy5jMy/bhu6Zktf9UvJzVyqipu2ITXPg4vO0Da1 aquEVSe2axvOHIvIPHd4fkSDetzC+/vBvku8kcvE5Ey/Kme/3ozMSJy/vvu508zKCb2EEe3Q2wzA WhvG8EtIDG3DRvyz7Wy8JAy6C0jGCv+MuBzd0tFr0N9rvThMiTpczzQ8fzAMzjGM0NtkywxVwY5s 1O2M03ycuTFNvhY9zEF9yYq70Vycx0/9t2Qrg85rwXqLsyx7aCLt1JK0ug1t1iRc0S4dxVks1TdM 1RjNzR/ovS0Nxt+c1l8919c8zl+cwNwcQ9m3xKQrtm7dvgj91hRNww+dvHzdx6JLzznH01JN1BCd w1oN2Cxdwh5c1UcdSPa8srncyCa9wIcL0yd82DQ4z21tuffct0P8xkm2yDOMvKIczM5s2IzLzJO8 x3xcWPDL2wRdg3+kNc9sxUB03AaB1MlNdkWk3Kkc3UQBCqdIodZ93diNE9I9ndnd3Tb/+EXGsN3i Pd4gqylS5N3oXRPakN7s3d4jRN7wPZwFkENJcIM8857und/6HULxHZz7XULR8N/vU0cCXuCdkQUg ZAQs0d+14Q1LZOAxAQoQPuGmx+CqSOEYnuF0aOEc3uEe/uF4p+FHVAe7AeImfuIonuJDcggsTiv2 0OIsPhAuLhC00uIFYeMvjuMEAeM2PuM0nuMwfuNC7uNAHuQ97uMxLuM7zuM1zuMGEeRFruNQLuM9 vuM3HuNJ/uNL7uRE3uRTTuNcjuRRjuVhnuVMLuZU3uRWnuU5PuZtruRnfuVqDudT3uVgnuRxXudC /uJsAQ0KXRN8DudWHuiETuRajuZP/z7ogp4Qdm7oWq7kbw7mi67ohH4QiF7plT7jdv7og87mjp7p Q64Qhu7plD7qkH7qkx7opO7pNf7kl/7pqi7maN7opa7omn7qLv4XGuHotA7qiY7pCHHpfA7rmN7q lr7nxm7sw/7rnM7szm7qpg7sh17owU7py87oiX7rqB7txZ7tnU7tyX7ta77t2C7uyv7jvX7suL7u zZ4WOsHrob7pyN4Qwn7uzi7uew7p4X7r3C7tqJ7vwG7v+D7v2v7soV7u487pwk7t1o7vLq7srf7w A2/uDa/v4H7wqQ7wBe/w+4obmo7lQ97vuK7jz87kbm7tAt/sEr/yjy7vJ7/lLg/trv8u6tPu70hu 8iYP8yCv6qVe5iJf8BLP8/vu5kG/8BYv9Bh/6CSf6Uvf7X9OaBmR7uju9AD/7+Se8NWO9VVf9EX/ 70af9Qrv7Uk/71Ov7irv7+3O77VO9ijP7mr/8Cyf7+cO60G/7FIf8Gv/82Jy9+Fu9dL+6fWO9t0O +GSP53fO5r5O72uv9TX/62pv9oNP83Kf+Hh/9jp/9HYv6RP/+O2O+RE/9v2O6C4v+GRBHLL+7S2v 7l8f+MTO8ISP+oz/6pIf9osv7/DO9GAf+Qi/7bI/+Ytf8zeP96H/9TxP5Ymv7b2f+hX/9HjhET6/ 8V4u54e/+43u5K7+8SR/8wJv76//bv0wX/VFLudzL/3BD/nV/+VEv+Q9b+S/f/64D+1crv5+D+Tv j/7Zv/TJT/UYrN0qjkC6DhD2BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k WdLkSZQpVa5k2dLlS5gxZc6cSY/mTZw5de7k2TPmP6BBhQ4lOvQQwaMDkwpcau/QU6hLozot2FQp VKZTmSJ1+tSg1qxeqyLFihCs2K1clXKN6rVtQrBhj7ZFe1Us3bRF9e7l29fvX8CBBQ8mXNjw4cMa my5ea5Wq2rWQI29l/Niy48qVKU92bPlxXauaqWKWPPmyWdSND3b22dp1S0sYk85N/7t5rOnauT3j pu2Z9G3IvU8DVy31q+3Zx0uTZr0bdefmr6VP75k8uWriv3mvHitct3Ptwo0T3zxebe/ry8mPhttw 7lnq8eVXR845+1e8wd121072rvLx4sKNvc8ALLCrqUJbz7v1lLstuvki7AgQnBATikAMzcutv90U 9LDDhRg88EDojjOOOew4VLC79uBi7ToLY5TRwgdmtPFGHGXkCC3QBBRNtxWxS7E0EwHUSsPvxHOu q6sGDDLJJb8b8DwJq7SypSCffBLE+zKz7z7fgBwOzMVKDM7BJTV7MTXJILzyTThnFHPOJLHaUq73 ygpTT7vK5JHFKeFrEs3L3nrLLP8+Efyxz7v0TCpHSCOVdFJKK4XzUkwz1XRTTjv19FNQW6p0VFJL NfVUVFNVdVVWBwv1VVhjlfWiVmu19VZcc9V1V1579fVXYIOVFBdhizX2WGSTVXZZZpt19lloo5V2 WmqrtfZabLPVdltuu/X2W3DDFXfcVWc191x0GSonXXbbdfddeOOVd156GSL3XnzzDbdefvv11yR9 AxaY1TJiTKfUIIr9d2GGG7ZoYIgjllhhhyu2+GKMM9bY3S829vjjdFMBeWSSSzb5ZJRTVnllllt2 +WWYY5Z5ZpprtvmhiXPWeWeee/b5Z6CDFnpooos2+mikk1Z6aabvBeDpp5uW+tjemxGCGuqqs4Zo aq673lZrsMMWe2yyQ3o2DK/TVhuostt2e6C145Y72bfrJntuvPPWe2++c67ZJrsDF3xwsPs2/HDE E1ecWcIbd/xxyBdefHLKK7f8cswjlSdzzoOK/HPQye6BpDJCN/101LfufHXWW3f9ddhjPzp12t2F oXbcUZZ9d7xz991f3oMXfnjixf39+Hn7KX555pu/NRPnA0N+enijtz5omenRfnvTYSk87u21v35y 6j/CoXz00697fPZ3Vv99WNuXf37667f//p7h139//h/H/39w9U+AlwoIADs= ------=_NextPart_000_0006_01C6F858.E1C125A0-- From avt-bounces@ietf.org Wed Oct 25 08:11:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GchZV-0000Wa-5K; Wed, 25 Oct 2006 08:09:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GchZU-0000WO-4P for avt@ietf.org; Wed, 25 Oct 2006 08:09:24 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GchZN-0001NE-0H for avt@ietf.org; Wed, 25 Oct 2006 08:09:24 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9PC9Eb16446; Wed, 25 Oct 2006 08:09:14 -0400 (EDT) Received: from [127.0.0.1] ([47.130.24.220] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 08:09:14 -0400 Message-ID: <453F53E5.5060005@nortel.com> Date: Wed, 25 Oct 2006 08:09:09 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: lazzaro Subject: Re: [AVT] AVT draft agenda References: <3EE93E55-781C-47C8-B21C-B0B6B2F45FCA@eecs.berkeley.edu> In-Reply-To: <3EE93E55-781C-47C8-B21C-B0B6B2F45FCA@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 25 Oct 2006 12:09:14.0239 (UTC) FILETIME=[632808F0:01C6F82E] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortel.com id k9PC9Eb16446 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Here's the background that Michael gave us: Background: I=B9m the chair of the IEEE 802.1 Audio/Video Bridging Task Group (see http://www.ieee802.org/1/pages/avbridges.html and the older one for Residential Ethernet at http://www.ieee802.org/3/ re_study.html). We=B9ve been given the job of bringing QoS appropriate for A/V applications into 802 networks, starting with Ethernet and quickly adding 802.11 and 802.16. By far most of our work will be in the bridges where we will have three major enhancements: Precise time synchronization so that every network element will have access to a very high quality clock (done via a layer 2 profile of the new revision of IEEE 1588). This is being done as project 802.1AS, and it=B9s well on its way. An admission control protocol that allows an endpoint to communicate its QoS requirements for a particular stream to all the network elements between the source and the sink. This is currently called the =B3Stream Reservation Protocol=B2 and will be done as project 802.1at. This is a gross simplification of the kind of thing done in RSVP (it=B9s only 1:n, only specifies two different traffic classes, etc., etc.). A traffic regulation/forwarding/queuing specification for the streams set up by SRP that defines how the appropriate frames are filtered/tagged/queued inside bridges, and the nature of the traffic shaping required by the transmitter. This will be done as project 802.1av (clever, eh?). I personally think that the primary internet layer for these services will be RTP and its related family of specifications, but I=B9m no expert, and I=B9d feel really uncomfortable if there isn=B9t a fairly intense level of interaction between the RTP community and our TG. I wonder if you could help us get that process started? Is there some venue that we could present what we have done so far and our intent for the future? lazzaro wrote: > Hi everyone, >=20 >=20 > On Oct 24, 2006, at 6:48 AM, Roni Eveb wrote: >=20 >> See the following draft agenda. If I forgot someone please let me know >=20 > [...] >=20 >=20 >> 10:10 RTP & layer 2 QoS =20 >> (Teener, 10) >=20 >=20 > Is there a document coming for this? If not, could the speaker say > a few words on list to provide some details? Thanks, sorry if there's > been a discussion already and I didn't see it ... >=20 > --- > John Lazzaro > http://www.cs.berkeley.edu/~lazzaro > lazzaro [at] cs [dot] berkeley [dot] edu > --- >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From cyn@ambianceusa.com Wed Oct 25 09:30:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcipd-0007mn-ME for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 09:30:09 -0400 Received: from dslb-088-073-054-053.pools.arcor-ip.net ([88.73.54.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcipY-00062p-6Y for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 09:30:09 -0400 Received: from 66.235.203.159 (HELO mail.ambianceusa.com) by lists.ietf.org with esmtp (VA8PM0CLAEUC SFTX) id L4CZWD-IB4BOO-QO for avt-archive@lists.ietf.org; Wed, 25 Oct 2006 13:30:24 -0060 From: "Marjorie Mckinney" To: Subject: Very important note. You should to read. Date: Wed, 25 Oct 2006 13:30:24 -0060 Message-ID: <01c6f839$b9d5aad0$6c822ecf@cyn> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Thread-Index: Aca6QKT6NW7M12PTNSK23V6EHZQMAT== X-Spam-Score: 4.7 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 The first thing to do on Wednesday October 25 is to get in on EQTD. It will RISE up next days. There will be over 100% from the beginning, so do it without delay. After the yesterday's promotion the share price raised on 116% and was 0.013. Those lucky devils who bought stocks at the price of 0.006 yesterday have already earned 100% of their investment. And they will make more. Did you think of it yesterday? If not, think of it now. Now the price is still rising. More over, with oil markets retreating, big traders are turning to gold, bringing it to levels never before seen. EQTD has made an results of staggering proportions related to a recent survey on one of their gold ownership. The internal scoop is great and we will be looking at a quadrupling of stock price once the public takes notice: CHICAGO, ILLINOIS-(MARKETWIRE)-Oct 23, 2006 - Equal trading is pleased to announce survey which inform us about far exceeded expectations. The results from our British Columbia property show 58,000 ounce potential. Plans are already underway for immediate development. We look forward to this extraordinary discovery bringing value to our shareholders. At 600$ an ounce this finding is worth 34.8 mil$. With 865mil shares outstanding, this would give us a book value of 0.04 (last price is under 0.01$). The promotion will be continued till the end of this week! From avt-bounces@ietf.org Wed Oct 25 11:01:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckFR-0001Ny-EF; Wed, 25 Oct 2006 11:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckFQ-0001Nq-BJ for avt@ietf.org; Wed, 25 Oct 2006 11:00:52 -0400 Received: from nz-out-0102.google.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GckFK-00031n-95 for avt@ietf.org; Wed, 25 Oct 2006 11:00:52 -0400 Received: by nz-out-0102.google.com with SMTP id 13so116815nzn for ; Wed, 25 Oct 2006 08:00:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=A8S9eyvrULObkWnpcTXaviaUbSmvv+jIqbmy9cU7x23G7GVjbUhDDuLRdh+6lsd6s61Tvj2ImB8BOxaumi0mWMs3QVVMReAzt/J0UgTPU300LzKOYBvq5pl8KLpqHpfwhQaRq6/9hq+E0eWPrPUtgQzSFyDvdou5UJklYKaJ8rs= Received: by 10.35.83.6 with SMTP id k6mr1222033pyl; Wed, 25 Oct 2006 08:00:45 -0700 (PDT) Received: by 10.35.51.12 with HTTP; Wed, 25 Oct 2006 08:00:45 -0700 (PDT) Message-ID: Date: Wed, 25 Oct 2006 11:00:45 -0400 From: "rufino " To: avt@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [AVT] end-to-end cRTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0909348644==" Errors-To: avt-bounces@ietf.org --===============0909348644== Content-Type: multipart/alternative; boundary="----=_Part_97291_11833461.1161788445720" ------=_Part_97291_11833461.1161788445720 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline hello: i would like to know there are any vendors implemented "end-to-end cRTP" feature yet? regards voip newbie ------=_Part_97291_11833461.1161788445720 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hello:

i would like to know there are any vendors implemented "end-to-end cRTP" feature yet?

regards

voip newbie
 ------=_Part_97291_11833461.1161788445720-- --===============0909348644== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0909348644==-- From avt-bounces@ietf.org Wed Oct 25 12:56:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcm2N-0005vw-EA; Wed, 25 Oct 2006 12:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcm2M-0005vq-DR for avt@ietf.org; Wed, 25 Oct 2006 12:55:30 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcm2I-0000oa-2C for avt@ietf.org; Wed, 25 Oct 2006 12:55:30 -0400 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1Gcm2H-000Ex1-Dw for avt@ietf.org; Wed, 25 Oct 2006 12:55:25 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <453F96FC.6010006@sipstation.com> Date: Wed, 25 Oct 2006 11:55:24 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org All, The ZRTP I-D has been updated. There are lots of changes in the document including: - Discussion of how ZRTP compares using the criteria in draft-wing-rtpsec-keying-eval-01.txt - Discovery and authentication of ZRTP through the signaling channel and the definitions and ABNF of three SDP attributes a=zrtp, a=zrtp-sas, a=zrtp-sasvalue. - New Multistream key agreement mode allowing SRTP keys for multiple media streams in a session to be derived from a single ZRTP DH exchange. - CRC protection of ZRTP messages against transport errors using a 32 bit CRC algorithm - Use of RTP no-op packets instead of comfort noise packets - Simplified shared secret comparison algorithm - New Stay secure and Disclosure flags - More details on caching of retained shared secrets including expiration intervals - Removal of Error message - Reason field added to GoClear - Discussion of the behavior of intermediary devices that might implement ZRTP We will be discussing the changes in the ZRTP protocol in the AVT working group and the SDP attributes in MMUSIC. As always, comments and feedback are most welcome. Thanks, Alan -------- Original Message -------- Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt Date: Tue, 24 Oct 2006 15:50:02 -0400 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 : ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP Author(s) : P. Zimmermann, et al. Filename : draft-zimmermann-avt-zrtp-02.txt Pages : 52 Date : 2006-10-24 This document defines ZRTP, RTP (Real-time Transport Protocol) header extensions for a Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure RTP (SRTP) sessions. The ZRTP protocol is completely self-contained in RTP and does not require support in the signaling protocol or assume a Public Key Infrastructure (PKI) infrastructure. For the media session, ZRTP provides confidentiality, protection against Man in the Middle (MitM) attacks, and, in cases where a secret is available from the signaling protocol, authentication. ZRTP can utilize three Session Description Protocol (SDP) attributes to provide discovery and authentication through the signaling channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zimmermann-avt-zrtp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 12:58:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcm4r-0008Q0-HX; Wed, 25 Oct 2006 12:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcm4q-0008Pu-FY for avt@ietf.org; Wed, 25 Oct 2006 12:58:04 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcm4o-0001Uh-PP for avt@ietf.org; Wed, 25 Oct 2006 12:58:04 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9PGvnj5010480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Oct 2006 09:57:51 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9PGofMT007978; Wed, 25 Oct 2006 09:57:47 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 09:57:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] 3 to last-call - RTP header extensions Date: Wed, 25 Oct 2006 09:57:43 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B021B9972@NAEX01.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] 3 to last-call - RTP header extensions Thread-Index: Acb14iMuc/fjYI8lRWKlqzPaiX7z3wCc+A2Q From: "Desineni, Harikishan" To: "Dave Singer" , , "Even, Roni" X-OriginalArrivalTime: 25 Oct 2006 16:57:44.0355 (UTC) FILETIME=[B0CA1F30:01C6F856] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Header extension is a profile independent approach. It is applicable to RTP/AVP and all extensions of it (AVPF and others profiles). Whether a particular profile is implemented or not, there is an easy way to make use of header extension. --Hari > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Sunday, October 22, 2006 6:49 AM > To: stewe@stewe.org; Even, Roni > Cc: avt@ietf.org > Subject: RE: [AVT] 3 to last-call - RTP header extensions >=20 > At 9:36 +0200 22/10/06, stewe@stewe.org wrote: > >Hi Roni, folks, > > > >Here's my take: > > > >The shim draft's main intention/application is to signal certain > >information (error resilience strength commands to be precise) from a > >media decoder to a media encoder, utilizing the reverse direction media > >path. I won't comment on that idea in fear of using inappropriate > >language, but I do have an opinion :-) > > > >If work should contrinue at all on this draft (I'm personally not of the > >opinion it should) I guess one avenue would be to split the draft into a) > >transport of opaque bytes shimmed between RTP header and RTP payload, > plus > >related signaling, and b) the use case proposed (signaling of AMR encoder > >operation points from an AMR decoder). Then a) should be called a > >profile. That would be half-way clean, I think, though not necessarily > >helpful, considering that the profile negotiation problem is (to the best > >of my knowledge) still unsoved. > > > >Dave's header extension stuff, on the other hand, is a comparatively > clean > >use of RTP's exstension mechanism that has been available for many years > >(although perhaps intended more for experiments than for regular use). > It > >should not break existing codebases and monitoring tools intended to > >support any of the existing profiles, as long as the > implementatiosn/tools > >follow RFC3550 in throwing away extensions they don't understand. Not > >true for shim. That's why shim should be called a profile. > > > >Dave's stuff could carry the payload proposed in the shim draft, though > at > >a certain penalty of a few bytes per packet (using Dave's mechanisms, I > >think it's 8 bytes penalty). Some companies in 3GPP SA4 see this as a > >major problem, as it makes radio optimization difficult. Others disagree. > > But on the Internet, the 8 bytes should not do any significant harm. >=20 > The 8 bytes comes from the current treatment of the X bit (I have to > have the signature and the length in there, even though my stuff is > self-identifying and self-framing). So they're not quite my fault. > But they are there. >=20 > > > >I believe, the main discussion should be between Dave's header extensions > >and the specification/use of new profiles. I believe to recall that > there > >was a plan (proposed by Cullen?) to take this issue to the RAI area > >mailing list, as it is closely related to profile negotiations. But I > >haven't seen any related traffic. >=20 > Nor I. I also note that we have been refining the header extensions > for a while now, while the shim draft is both more recent (first > version in august) and more specialized. I guess I'd like their > comment on why the general header extension is not appropriate, or > other alignment issues. >=20 > > > >Regards, > >Stephan > > > >P.s.: in SA4, even the shim use case is by no means agreed. > > > >> Hi, > >> My concern is with what looks to me like duplication between the > header > >> extensions and the "shim" draft and I would like have one mechanism if > >> possible. > >> Roni > >> > >>> -----Original Message----- > >>> From: Dave Singer [mailto:singer@apple.com] > >>> Sent: Friday, October 20, 2006 7:58 PM > >>> To: avt@ietf.org > >>> Subject: [AVT] 3 to last-call - RTP header extensions > >>> > >>> Hi folks > >>> > >>> the only adjustment here from the previous drafts is to use URIs to > >>> identify header extensions, rather than reversed domain names. URIs > >>> have the advantage that they might be de-referencable URLs, and > >>> indeed the draft now says that for RFCs, the extension name is the > >>> URL to the RFC. So the following two now say that, as well. > >>> > >>> I'm asking for last-call on these, as we've seen them a while, they > >>> are complete, and the discussion has died down. Re-start the > >>> discussion if you disagree! > >>> > >>> * * * * > >>> > >>> This draft is a work item of the Audio/Video Transport Working Group > >>> of the IETF. > >>> > >>> Title : A general mechanism for RTP Header Extensions > >>> Author(s) : D. Singer > >>> Filename : draft-ietf-avt-rtp-hdrext-06.txt > >>> Pages : 17 > >>> Date : 2006-10-19 > >>> > > >> This document provides a general mechanism to use the header- > >>> extension feature of RTP (the Real Time Transport Protocol). It > >>> provides the option to use a small number of small extensions in > >> each > >>> RTP packet, where the universe of possible extensions is large > and > >>> unregistered. The actual extensions in use in a session are > >> signaled > >>> in the setup information for that session. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-06.txt > >>> > >>> > >>> > >>> Title : Transmission Time offsets in RTP streams > >>> Author(s) : H. Desineni, D. Singer > >>> Filename : draft-ietf-avt-rtp-toffset-02.txt > >>> Pages : 15 > >>> Date : 2006-10-19 > >>> > >>> This document describes a method to inform RTP clients when RTP > >>> packets are transmitted at a time other than their 'nominal' > >>> transmission time. It also provides a mechanism to provide > >> improved > >>> inter-arrival jitter reports from the clients, that take into > >> account > >>> the reported transmission times. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-02.txt > >>> > >>> Title : Associating Time-codes with RTP streams > >>> Author(s) : D. Singer > >>> Filename : draft-ietf-avt-smpte-rtp-05.txt > >>> Pages : 20 > >>> Date : 2006-10-19 > >>> > >>> This document describes a mechanism for associating time-codes, as > >>> defined by the Society of Motion Picture and Television Engineers > >>> (SMPTE), with media streams, in a way that is independent of the > >> RTP > >>> payload format of the media stream itself. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte-rtp-05.txt > >>> > >>> > >>> > >>> -- > >>> David Singer > >>> Apple Computer/QuickTime > >>> > >>> _______________________________________________ > >>> Audio/Video Transport Working Group > >>> avt@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/avt > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www1.ietf.org/mailman/listinfo/avt > >> > > > > > > > >_______________________________________________ > >Audio/Video Transport Working Group > >avt@ietf.org > >https://www1.ietf.org/mailman/listinfo/avt >=20 >=20 > -- > David Singer > Apple Computer/QuickTime >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 13:31:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcmaH-0003op-P5; Wed, 25 Oct 2006 13:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcmaF-0003kC-Oe for avt@ietf.org; Wed, 25 Oct 2006 13:30:31 -0400 Received: from adsl-63-193-97-10.dsl.snfc21.pacbell.net ([63.193.97.10] helo=zaphod.philzimmermann.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcmaD-0007bD-Uw for avt@ietf.org; Wed, 25 Oct 2006 13:30:31 -0400 Received: from [10.0.1.201] (adsl-63-193-97-10.dsl.snfc21.pacbell.net [63.193.97.10]) (authenticated bits=0) by zaphod.philzimmermann.com (8.13.3/8.13.3) with ESMTP id k9PHTqUH075766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Oct 2006 10:30:27 -0700 (PDT) (envelope-from prz@mit.edu) In-Reply-To: <453F96FC.6010006@sipstation.com> References: <453F96FC.6010006@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <4F3F404A-7BFD-4D1F-937B-5971B33965CE@mit.edu> Content-Transfer-Encoding: quoted-printable From: Philip Zimmermann Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Wed, 25 Oct 2006 10:30:27 -0700 To: Alan Johnston X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on zaphod.philzimmermann.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org In the category of full disclosure, I wanted everyone to be aware of =20 an Intellectual Property disclosure I just made to the IETF. The =20 full text can be found at: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D752 While patents are distasteful to me, and I have seen how they have =20 been damaging in the crypto world, this is a purely defensive patent =20 that I have filed. My intention is to provide royalty-free licenses =20 to anyone implementing ZRTP under most circumstances. Provided they =20 are not suing me or my customers for infringing a patent. ;-) The exact text is: "In relation to any IETF standard incorporating the technology in the =20= ZRTP specification ("ZRTP Technology"), Philip Zimmermann (together with his successors and assignees, =93PRZ=94) will grant a royalty-free, non-=20 exclusive license to Qualified Parties to use the ZRTP Technology solely to the =20= extent necessary to implement and practice such IETF standards in strict =20 conformance with the IETF standards. As used herein, Qualified Parties means a =20 party who has not, does not and will not assert, in litigation or otherwise, =20 including in licensing discussions, any patent or other intellectual property =20 right against PRZ or any licensee of the libZRTP SDK. Any such license to a =20 Qualified Party shall terminate at once if such party asserts a patent or other =20 intellectual property right against PRZ or any licensee of the libZRTP SDK. PRZ =20 will grant non-exclusive licenses to Non-Qualified Parties on reasonable, =20 reciprocal non-discriminatory terms and conditions." I also wanted to use this to give some incentive for ZRTP =20 implementors to truthfully implement the ZRTP disclosure flag in =20 Appendix B of the new ZRTP Internet draft. See http://=20 zfoneproject.com/disclosureflag.html I will be in San Diego and would be happy to discuss this further =20 with anyone who wishes. -prz On Oct 25, 2006, at 9:55 AM, Alan Johnston wrote: > All, > > The ZRTP I-D has been updated. There are lots of changes in the =20 > document including: > > > - Discussion of how ZRTP compares using the criteria in draft-wing-=20 > rtpsec-keying-eval-01.txt > > - Discovery and authentication of ZRTP through the signaling =20 > channel and the definitions and ABNF of three SDP attributes =20 > a=3Dzrtp, a=3Dzrtp-sas, a=3Dzrtp-sasvalue. > > - New Multistream key agreement mode allowing SRTP keys for =20 > multiple media streams in a session to be derived from a single =20 > ZRTP DH exchange. > > - CRC protection of ZRTP messages against transport errors using a =20 > 32 bit CRC algorithm > > - Use of RTP no-op packets instead of comfort noise packets > > - Simplified shared secret comparison algorithm > > - New Stay secure and Disclosure flags > > - More details on caching of retained shared secrets including =20 > expiration intervals > > - Removal of Error message - Reason field added to GoClear > > - Discussion of the behavior of intermediary devices that might =20 > implement ZRTP > > > We will be discussing the changes in the ZRTP protocol in the AVT =20 > working group and the SDP attributes in MMUSIC. > > As always, comments and feedback are most welcome. > > Thanks, > Alan > > > -------- Original Message -------- > Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt > Date: Tue, 24 Oct 2006 15:50:02 -0400 > 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 =20 > directories. > > > Title : ZRTP: Extensions to RTP for Diffie-Hellman Key = Agreement =20 > for SRTP > Author(s) : P. Zimmermann, et al. > Filename : draft-zimmermann-avt-zrtp-02.txt > Pages : 52 > Date : 2006-10-24 > =09 > This document defines ZRTP, RTP (Real-time Transport Protocol) header > extensions for a Diffie-Hellman exchange to agree on a session key > and parameters for establishing Secure RTP (SRTP) sessions. The =20 > ZRTP > protocol is completely self-contained in RTP and does not require > support in the signaling protocol or assume a Public Key > Infrastructure (PKI) infrastructure. For the media session, ZRTP > provides confidentiality, protection against Man in the Middle =20 > (MitM) > attacks, and, in cases where a secret is available from the =20 > signaling > protocol, authentication. ZRTP can utilize three Session =20 > Description > Protocol (SDP) attributes to provide discovery and authentication > through the signaling channel. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt > > To remove yourself from the I-D Announcement list, send a message =20 > to i-d-announce-request@ietf.org with the word unsubscribe in the =20 > body of the message. You can also visit https://www1.ietf.org/=20 > mailman/listinfo/I-D-announce to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the =20= > username "anonymous" and a password of your e-mail address. After =20 > logging in, type "cd internet-drafts" and then "get draft-=20 > zimmermann-avt-zrtp-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-=20 > sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail = readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt ---------------------------------------------- Philip R Zimmermann prz@mit.edu http://philzimmermann.com tel +1 650 322-7223 (spelled with 2 n's) fax +1 650 322-7877 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 13:33:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcmbx-0007Qz-Ge; Wed, 25 Oct 2006 13:32:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcmbv-0007Qu-Vc for avt@ietf.org; Wed, 25 Oct 2006 13:32:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcmbu-0007sd-Bf for avt@ietf.org; Wed, 25 Oct 2006 13:32:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2006 10:32:14 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PHWDHZ015120; Wed, 25 Oct 2006 10:32:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9PHWDAo022060; Wed, 25 Oct 2006 10:32:13 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 10:32:13 -0700 Received: from [192.168.0.10] ([10.21.145.142]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 10:32:12 -0700 In-Reply-To: <453E119C.2030907@ericsson.com> References: <85384093-2F6C-4792-9619-CDC8734F7EA0@cisco.com> <453E119C.2030907@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0987A300-0826-47BF-A5DA-EC06F088B989@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt Date: Wed, 25 Oct 2006 10:32:11 -0700 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Oct 2006 17:32:12.0986 (UTC) FILETIME=[81CA29A0:01C6F85B] DKIM-Signature: a=rsa-sha1; q=dns; l=7020; t=1161797533; x=1162661533; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20I-D=20ACTION=3Adraft-ietf-avt-topologies-02.txt; X=v=3Dcisco.com=3B=20h=3DNFXujfBomnBJBWsC0QikGwRg/PI=3D; b=u8uZUmZacmMVo7nw0440PaKf+uKV0mE8I4hGGMvt82UeiaAP0it7JVUyk/1AdpO5ruhdSaUX XNKeFV39mB7TZG/FmaNmVKTMesP7U3qoJ2QMB8f8Mj8fE+L0yqRZ4oWD; Authentication-Results: sj-dkim-3.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: Stephan Wenger , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org hi Magnus, On Oct 24, 2006, at 6:14 AM, Magnus Westerlund wrote: > Hi Mark, > > Thanks for the review and I will do my best to respond to your > questions and comments. > > Mark Baugher skrev: >> Magnus, Stephan, >> I gave this a first read and it's well-written and to the point >> IMHO. I have a couple of comments off the top of my head. >> Starting with Security Considerations, Second, the number of >> security contexts needed (for example in >> SRTP [RFC3711]) may vary between mixers and translators. A mixer >> normally needs to represent only a single SSRC in any given >> domain, and therefore needs to create only one SRTP security >> context. In contrast, a translator needs one context per >> participant it translates toward in the opposite domain. >> Couldn't Figure 6 have five crypto contexts installed in the >> mixer? I think you're saying that everyone but the mixer receives >> using the same crypto context. The mixer additionally needs to >> receive the others' streams and each will have a crypto context. > > In the case depicted by figure 6, the mixer will have one SSRC and > the A-D will have at least one respectively. However if we are > looking at the link between A and the mixer, the traffic passing on > this link there will be only two SSRCs, A's and the Mixer's. The > SSRCs belonging to B, C and D will only occur in CSRC list and > inside RTCP SDES packets. Thus from an SRTP perspective, A only > needs two crypto contextes, one for its own traffic and one for the > mixer. The same is true for each of the other participants that > only receive a mixed view of the session. That is why I am saying > that the mixer will have one SSRC (at least). I misread the text cited above, "A mixer normally needs to represent only a single SSRC per domain and therefore needs to create only one SRTP security context". I think we could put it this way, "A mixer normally needs to represent only a single SSRC per domain and therefore needs to create only one SRTP crypto context per domain" where I added 'per domain' and changed 'security' to 'crypto'. > > In regards to using the same crypto context for all the others, I > don't think that is the truth. To avoid the two time padd issue, > the mixer needs to use either different keys or different SSRC in > the domains when using SRTP. The reason is that a mixer most likely > will need to produce different media streams and mixes. Sending the > transmitting entity a stream with themselves seems wrong in most > applications. Thus senders and only receivers will at least have > different streams. That is before even considering the need to > adapt the media to the individual links. > > I think I missed the word "additional" in the following sentence: > "... and therefore needs to create only one SRTP security context." > > Where a mixer will need N crypto contexts in addition for N > domains, a translator may be forced to have P*N crypto contexts > where P is the number of participants in total. Ok. It seems clearer to write "may be forced to have" as "might need up to" > >> There is a lot that needs to be defined that probably is outside >> of the scope of your document, but the security considerations >> section also says: >> Including the mixer and translator in the security context allows >> the entity if subverted or misbehaving to perform a number of >> very >> serious attacks as it has full access. It can perform all the >> attacks possible, see RFC 3550 and any applicable profiles, as if >> the media session was not protected at all, while giving the >> impression to the session participants that they are protected >> against them. >> "Security context" is vague but I think what you're saying here is >> that giving a device access to security keys adds a new risk, >> another potential point of vulnerability, to the session. _How_ >> the mixer and translator are included in the security context can >> greatly affect the risk. In other words, we know in security how >> to establish pairwise keys for a pair of endpoints, and we know >> how to do group keys for multiple endpoints, but I don't think >> there is a consensus for how to do key management for some of the >> figures in your document. > > No, that is true. The security risks will depend on how you key. > The main point is that a mixer or a translator may actually need to u I miss your point here, but I agree that the "security risks will depend on how you key", and I would add that there is no consensus on how to key some of the figures. That's out-of-scope for this I-D but needs to be done and probably should be mentioned. > >> I had one more question come to mind when reading Section 3.5. >> Following Figure 5 it says: >> In the multicast domain, the mixer does not need to provide a >> mixed view of the other domains and will commonly only forward >> the >> media from B and D into the multicast network using B's and D's >> SSRC. >> I expect that mixing would be useful for a multicast network to >> give every participant the same output from the conference. Are >> you assuming otherwise? > > In this case you have deployed a mixer simply because B and D can't > have the same view as A and C that are part of the multicast > domain. There is no reason for the mixer to return a mixed stream > to the multicast domain that contains all the participants, because > any sender in the multicast domain has already received that > traffic. In the same way it is unnecessary for the mixer to even > mix B and D together unless there is a bandwidth issue, because the > participants in the multicast part already are capable of handling > the reception of multiple sources. I recall that there were advantages to doing centralized mixing and then distribute the mixed stream over a multicast channel instead of every receiver doing its own mixing. The advantage is that the device imposes an ordering so the receivers all hear the same thing at about the same time. Not the case? > > > I think we should add the word additional to that sentence to > clarify things. Are there anything else you would like to improve > in this text? I mentioned those inline, above. Cheers, Mark > > Cheers > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 13:56:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcmyf-0004cL-Mf; Wed, 25 Oct 2006 13:55:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcmye-0004bn-Ef for avt@ietf.org; Wed, 25 Oct 2006 13:55:44 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcmxE-0002f5-FZ for avt@ietf.org; Wed, 25 Oct 2006 13:54:17 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 13:54:16 -0400 To: Philip Zimmermann Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <453F96FC.6010006@sipstation.com> <4F3F404A-7BFD-4D1F-937B-5971B33965CE@mit.edu> From: Randell Jesup Date: Wed, 25 Oct 2006 13:54:14 -0400 In-Reply-To: <4F3F404A-7BFD-4D1F-937B-5971B33965CE@mit.edu> (Philip Zimmermann's message of "Wed, 25 Oct 2006 10:30:27 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 25 Oct 2006 17:54:16.0303 (UTC) FILETIME=[968C4FF0:01C6F85E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Philip Zimmermann writes: >While patents are distasteful to me, and I have seen how they have been >damaging in the crypto world, this is a purely defensive patent that I >have filed. My intention is to provide royalty-free licenses to anyone >implementing ZRTP under most circumstances. Provided they are not suing >me or my customers for infringing a patent. ;-) > >The exact text is: > >"In relation to any IETF standard incorporating the technology in the ZRTP >specification ("ZRTP Technology"), Philip Zimmermann (together with his >successors and assignees, "PRZ") will grant a royalty-free, non- >exclusive license to Qualified Parties to use the ZRTP Technology solely >to the extent necessary to implement and practice such IETF standards in >strict conformance with the IETF standards. As used herein, Qualified >Parties means a party who has not, does not and will not assert, in >litigation or otherwise, including in licensing discussions, any patent or >other intellectual property right against PRZ or any licensee of the >libZRTP SDK. Any such license to a Qualified Party shall terminate at >once if such party asserts a patent or other intellectual property right >against PRZ or any licensee of the libZRTP SDK. PRZ will grant >non-exclusive licenses to Non-Qualified Parties on reasonable, reciprocal >non-discriminatory terms and conditions." Philip - It appears from that text that a licensee of ZRTP not only can't assert a patent right against someone concerning their use of ZRTP, but that they can't assert any patent, even in a wildly different field or different project, against any other licensee. So if Nokia licenses ZRTP (even if they never use it), and if Motorola licenses ZRTP (again, even if they never use it), than neither of them can enforce any patent (or copyright!) on *anything* against the other. Motorola could clone a Nokia phone including the software, put "Motorola" on the front, and sell it. Was this written by a lawyer? Disclaimer: IANAL either, but I spend WAY too much time reading FCC rulings. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 15:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco3c-0000cR-7C; Wed, 25 Oct 2006 15:04:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco3a-0000cF-5a for avt@ietf.org; Wed, 25 Oct 2006 15:04:54 -0400 Received: from adsl-63-193-97-10.dsl.snfc21.pacbell.net ([63.193.97.10] helo=zaphod.philzimmermann.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gco3W-0008LB-KO for avt@ietf.org; Wed, 25 Oct 2006 15:04:54 -0400 Received: from [10.0.1.201] (adsl-63-193-97-10.dsl.snfc21.pacbell.net [63.193.97.10]) (authenticated bits=0) by zaphod.philzimmermann.com (8.13.3/8.13.3) with ESMTP id k9PJ4lN7076779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Oct 2006 12:04:48 -0700 (PDT) (envelope-from prz@MIT.EDU) In-Reply-To: References: <453F96FC.6010006@sipstation.com> <4F3F404A-7BFD-4D1F-937B-5971B33965CE@mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Zimmermann Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Wed, 25 Oct 2006 12:04:42 -0700 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on zaphod.philzimmermann.com X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org This is not the actual legal language of a license, it's just a summary. I'm getting on an airplane for the rest of the day, so I'll address this later. I have a long-standing reputation of not being a patent troll. Nobody's going to be shut out of ZRTP because of a patent. I am going out of my way to make sure that doesn't happen. On Oct 25, 2006, at 10:54 AM, Randell Jesup wrote: > Philip Zimmermann writes: >> While patents are distasteful to me, and I have seen how they >> have been >> damaging in the crypto world, this is a purely defensive patent >> that I >> have filed. My intention is to provide royalty-free licenses to >> anyone >> implementing ZRTP under most circumstances. Provided they are >> not suing >> me or my customers for infringing a patent. ;-) >> >> The exact text is: >> >> "In relation to any IETF standard incorporating the technology in >> the ZRTP >> specification ("ZRTP Technology"), Philip Zimmermann (together >> with his >> successors and assignees, "PRZ") will grant a royalty-free, non- >> exclusive license to Qualified Parties to use the ZRTP Technology >> solely >> to the extent necessary to implement and practice such IETF >> standards in >> strict conformance with the IETF standards. As used herein, >> Qualified >> Parties means a party who has not, does not and will not assert, in >> litigation or otherwise, including in licensing discussions, any >> patent or >> other intellectual property right against PRZ or any licensee of the >> libZRTP SDK. Any such license to a Qualified Party shall >> terminate at >> once if such party asserts a patent or other intellectual property >> right >> against PRZ or any licensee of the libZRTP SDK. PRZ will grant >> non-exclusive licenses to Non-Qualified Parties on reasonable, >> reciprocal >> non-discriminatory terms and conditions." > > Philip - > > It appears from that text that a licensee of ZRTP not only can't > assert a patent right against someone concerning their use of ZRTP, > but > that they can't assert any patent, even in a wildly different field or > different project, against any other licensee. So if Nokia > licenses ZRTP > (even if they never use it), and if Motorola licenses ZRTP (again, > even if > they never use it), than neither of them can enforce any patent (or > copyright!) on *anything* against the other. Motorola could clone > a Nokia > phone including the software, put "Motorola" on the front, and sell > it. > > Was this written by a lawyer? > > Disclaimer: IANAL either, but I spend WAY too much time reading FCC > rulings. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex- > Amiga OS team > rjesup@wgate.com ---------------------------------------------- Philip R Zimmermann prz@mit.edu http://philzimmermann.com tel +1 650 322-7223 (spelled with 2 n's) fax +1 650 322-7877 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 15:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcoKw-0003Y6-TC; Wed, 25 Oct 2006 15:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcoKv-0003Y0-2l for avt@ietf.org; Wed, 25 Oct 2006 15:22:49 -0400 Received: from ghostmachine.transbay.net ([209.133.53.61] helo=casper2.ghostscript.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcoKt-0002yk-RN for avt@ietf.org; Wed, 25 Oct 2006 15:22:49 -0400 Received: by casper2.ghostscript.com (Postfix, from userid 1000) id D8A9734C1B0; Wed, 25 Oct 2006 12:22:31 -0700 (PDT) Date: Wed, 25 Oct 2006 12:22:31 -0700 From: Ralph Giles To: Philip Zimmermann Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Message-ID: <20061025192231.GD26575@ghostscript.com> References: <453F96FC.6010006@sipstation.com> <4F3F404A-7BFD-4D1F-937B-5971B33965CE@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Randell Jesup , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Wed, Oct 25, 2006 at 12:04:42PM -0700, Philip Zimmermann wrote: > I have a long-standing reputation of not being a patent troll. > Nobody's going to be shut out of ZRTP because of a patent. I am > going out of my way to make sure that doesn't happen. Is your patent license compatible with "patentleft" clauses like the MPL has? I'm worried about the interpretation of the assertion "...does not and will not assert, in litigation or otherwise, including in licensing discussions, any patent or other intellectual property right against PRZ." -r _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 16:35:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpRN-000336-D2; Wed, 25 Oct 2006 16:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcomG-0004r8-GC; Wed, 25 Oct 2006 15:51:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcomF-00083r-Om; Wed, 25 Oct 2006 15:51:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcomF-00064e-Bs; Wed, 25 Oct 2006 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5F4452ACC6; Wed, 25 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolH-0004q4-3i; Wed, 25 Oct 2006 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 25 Oct 2006 15:50:03 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-profile-savpf-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) Author(s) : J. Ott, E. Carrara Filename : draft-ietf-avt-profile-savpf-09.txt Pages : 17 Date : 2006-10-25 An RTP profile (SAVP) is defined for secure real-time communications, and another profile (AVPF) is specified to provide timely feedback from the receivers to a sender. This memo defines the combination of both profiles to enable secure RTP communications with feedback. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-savpf-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-savpf-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-25115550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-savpf-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-savpf-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25115550.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Wed Oct 25 17:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpFQ-0007cy-DI; Wed, 25 Oct 2006 16:21:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcomI-0004sH-34; Wed, 25 Oct 2006 15:51:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcomI-00084d-1K; Wed, 25 Oct 2006 15:51:06 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcomH-000652-NO; Wed, 25 Oct 2006 15:51:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7014D2ACC9; Wed, 25 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolH-0004qG-6Y; Wed, 25 Oct 2006 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 25 Oct 2006 15:50:03 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-ulp-19.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for Generic Forward Error Correction Author(s) : A. Li Filename : draft-ietf-avt-ulp-19.txt Pages : 42 Date : 2006-10-25 This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this draft allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristic. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ulp-19.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-ulp-19.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-ulp-19.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-25120002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-ulp-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-ulp-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25120002.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Wed Oct 25 18:23:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcr93-0008KI-VY; Wed, 25 Oct 2006 18:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcr91-0008Hw-Ds for avt@ietf.org; Wed, 25 Oct 2006 18:22:44 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcr90-0002Mo-6r for avt@ietf.org; Wed, 25 Oct 2006 18:22:43 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 18:22:41 -0400 To: Philip Zimmermann Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <453F96FC.6010006@sipstation.com> <4F3F404A-7BFD-4D1F-937B-5971B33965CE@mit.edu> From: Randell Jesup Date: Wed, 25 Oct 2006 18:22:40 -0400 In-Reply-To: (Philip Zimmermann's message of "Wed, 25 Oct 2006 12:04:42 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 25 Oct 2006 22:22:41.0891 (UTC) FILETIME=[163A0330:01C6F884] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Philip Zimmermann writes: >This is not the actual legal language of a license, it's just a summary. Thanks; what confused me was: >>> The exact text is: (quoted text) That made me assume this was the exact text of the license. >I have a long-standing reputation of not being a patent troll. Nobody's >going to be shut out of ZRTP because of a patent. I am going out of my >way to make sure that doesn't happen. I was certain you didn't mean it to be the way that was written, which was why I asked for clarification. Thanks. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 18:35:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrK2-0003oG-90; Wed, 25 Oct 2006 18:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrK0-0003nj-NJ; Wed, 25 Oct 2006 18:34:04 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcrJz-00044D-G7; Wed, 25 Oct 2006 18:34:04 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 18:34:03 -0400 To: Internet-Drafts@ietf.org Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-profile-savpf-09.txt References: From: Randell Jesup Date: Wed, 25 Oct 2006 18:34:02 -0400 In-Reply-To: (Internet-Drafts@ietf.org's message of "Wed, 25 Oct 2006 15:50:03 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 25 Oct 2006 22:34:03.0472 (UTC) FILETIME=[AC7B0500:01C6F885] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: avt@ietf.org, i-d-announce@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Internet-Drafts@ietf.org writes: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-09.txt I really wish that everyone who posts a new draft would put a summary of the changes from the previous version, either in the draft, or posted here (or to the relevant lists). Thanks! -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 22:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcvJT-0002uD-Ga; Wed, 25 Oct 2006 22:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcvHt-00025R-Fj; Wed, 25 Oct 2006 22:48:09 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcvB3-0002nD-CE; Wed, 25 Oct 2006 22:41:08 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k9Q2B80I029818; Wed, 25 Oct 2006 19:11:08 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k9Q2B8aJ029817; Wed, 25 Oct 2006 19:11:08 -0700 Date: Wed, 25 Oct 2006 19:11:08 -0700 Message-Id: <200610260211.k9Q2B8aJ029817@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVT] RFC 4749 on RTP Payload Format for the G.729.1 Audio Codec X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4749 Title: RTP Payload Format for the G.729.1 Audio Codec Author: A. Sollaud Status: Standards Track Date: October 2006 Mailbox: aurelien.sollaud@orange-ft.com Pages: 14 Characters: 28838 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt URL: http://www.rfc-editor.org/rfc/rfc4749.txt This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 22:52:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcvLL-0003m0-7A; Wed, 25 Oct 2006 22:51:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcvLJ-0003lt-Py for avt@ietf.org; Wed, 25 Oct 2006 22:51:41 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcvLH-0005yY-FF for avt@ietf.org; Wed, 25 Oct 2006 22:51:41 -0400 Received: by nf-out-0910.google.com with SMTP id n15so816940nfc for ; Wed, 25 Oct 2006 19:51:38 -0700 (PDT) Received: by 10.82.123.16 with SMTP id v16mr345394buc; Wed, 25 Oct 2006 19:51:38 -0700 (PDT) Received: by 10.82.182.6 with HTTP; Wed, 25 Oct 2006 19:51:38 -0700 (PDT) Message-ID: <31d1be720610251951x54e455fbn73381d663f0508b1@mail.gmail.com> Date: Wed, 25 Oct 2006 19:51:38 -0700 From: "Greg Herlein" To: "Randell Jesup" Subject: Re: [AVT] AVT draft agenda In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3EE93E55-781C-47C8-B21C-B0B6B2F45FCA@eecs.berkeley.edu> <453F53E5.5060005@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lazzaro , avt@ietf.org, Tom-PT Taylor X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I missed the original post but am highly interested in this discussion and standard solution. My application for this involves several displays playing the same multicast stream and having the desire to syncronize the playback of those streams to the frame level to the maximum extent possible. Variations in transit time and jitter buffer processing will make this difficult without some kind of syncronization. Having a clock on the wire would solve part of this. I'd welcome a link to more information on efforts underway. Greg On 10/25/06, Randell Jesup wrote: > "Tom-PT Taylor" writes: > > Precise time synchronization so that every network element will > > have access to a very high quality clock (done via a layer 2 > > profile of the new revision of IEEE 1588). This is being done as > > project 802.1AS, and it=B9s well on its way. > > Just wondering: why is precise synchronization important? Especially sin= ce > sync will drift. And why do the network elements need to know? Perhaps > you're trying to instill knowledge into the network of how long a packet > has been "in-transit"? > > RTP provides for a higher-level end-to-end synchronization on a per-strea= m > level (RTCP and NTP), though for reasons having to do with its origin in > multicast scenarios synchronization can take a short while. (There are > ways around that like AVPF). Is there a reason this part of the problem > couldn't be addressed by protocol modifications at that level? > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS = team > rjesup@wgate.com > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 23:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcvy9-0005oW-Le; Wed, 25 Oct 2006 23:31:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcvy8-0005ma-Tn for avt@ietf.org; Wed, 25 Oct 2006 23:31:48 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcvy7-0006wi-EW for avt@ietf.org; Wed, 25 Oct 2006 23:31:48 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9Q3ViuV001386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Oct 2006 20:31:46 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: lazzaro Date: Wed, 25 Oct 2006 20:31:41 -0700 To: avt@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: lazzaro Subject: [AVT] Re: avt Digest, Vol 30, Issue 23 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 25, 2006, at 10:32 AM, Randell Jessup wrote: > > "Tom-PT Taylor" writes: >> Precise time synchronization so that every network element will >> have access to a very high quality clock (done via a layer 2 >> profile of the new revision of IEEE 1588). This is being done as >> project 802.1AS, and it=B9s well on its way. > > Just wondering: why is precise synchronization important? =20 > Especially since > sync will drift. And why do the network elements need to know? =20 > Perhaps > you're trying to instill knowledge into the network of how long a =20 > packet > has been "in-transit"? Imagine having a set 801.11 wireless microphones that you put around a drum kit (one on the hi-hat, one on the snare drum, etc). The antenna and the network stack CPU is inside the mic. Each mic is sending an independent RTP stream out over the air, which a DAW is recording simultaneously, one track per mic. All the mics are picking up the sound of every drum a little bit ... and so you really want the audio as tightly synchronized as possible, down to the audio sample if you can (@96 kHz, we're talking =20 microseconds). If you had delay-compensated precise clocking multicast over the =20 network, and if you had a Layer 2 stack on the microphone that recognized it was sending RTCP packets and rewrote the NTP field on the way to the =20 antenna, the RTP sender app in the mic could just write 0s in the NTP field -- =20= it's code could be written to know that the Layer-2 part of the network stack =20 would be rewriting in tight NTP. Admittedly a pro app, but I'm sure the consumer types on the list can describe similar sorts of scenarios ... --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 25 23:46:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcwBT-0003WS-8B; Wed, 25 Oct 2006 23:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcwBS-0003WN-1j for avt@ietf.org; Wed, 25 Oct 2006 23:45:34 -0400 Received: from host1.cruzio.com ([63.249.95.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcwBN-0001G4-KO for avt@ietf.org; Wed, 25 Oct 2006 23:45:34 -0400 Received: (qmail 50406 invoked from network); 25 Oct 2006 20:45:28 -0700 Received: from dsl-63-249-108-48.cruzio.com (HELO ?192.168.1.110?) (63.249.108.48) by teener.com with SMTP; 25 Oct 2006 20:45:28 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 25 Oct 2006 20:45:23 -0700 From: Michael Johas Teener To: IETF AV Transport WG Message-ID: Thread-Topic: Layer 2 synchronization and clock (was: AVT draft agenda) Thread-Index: Acb4sSpYaQsjHWSkEduMfQAUUQECpg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [AVT] Re: Layer 2 synchronization and clock (was: AVT draft agenda) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Randell Jesup wrote: > "Tom-PT Taylor" writes: >> Precise time synchronization so that every network element will >> have access to a very high quality clock (done via a layer 2 >> profile of the new revision of IEEE 1588). This is being done as >> project 802.1AS, and it=B9s well on its way. >=20 > Just wondering: why is precise synchronization important? Especially sin= ce > sync will drift. And why do the network elements need to know? Perhaps > you're trying to instill knowledge into the network of how long a packet > has been "in-transit"? >=20 > RTP provides for a higher-level end-to-end synchronization on a per-strea= m > level (RTCP and NTP), though for reasons having to do with its origin in > multicast scenarios synchronization can take a short while. (There are > ways around that like AVPF). Is there a reason this part of the problem > couldn't be addressed by protocol modifications at that level? Synchronization is useful for two primary reasons, and the "precise" part o= f it is relative to the particular application. 1) Clearly there are streams that need to be rendered at different devices in synchronization. A simple (though not really precise) example is lip-synch, where the video going to the display must be synchronized with the sound rendered by a speaker (20ms is usually considered "good enough" for that). The next level of synchronization is that needed for correct sound "imaging" for a multiple speaker system. Depending on the nature of system, synchronization down to 100s or even 10s of microseconds is needed for proper phasing. There are industrial, telecom, and instrumentation requirements that are even more extreme ... IEEE 1588 systems are aimed dow= n to the sub-nanosecond level. 2) The network needs to avoid introducing any jitter or wander to the distributed clock that cannot be easily filtered. The clock provided by the 802.1AS service is intended to be used by applications for sampling, and so must meet the MTIE mask for that application. The baseline requirement is t= o support uncompressed video, which means a application-level jitter of aroun= d 10ps at high frequencies. Of course, many of these requirements can be met by pure RTCP/NTP systems, but at the cost of latency for the buffers and the fairly long control loops. The 802.1AS part of our work is intended to allow much of the simple work to be done at lower layers in the network element hardware. With any luck, the work we are doing will hook to higher layers to allow shallower buffers and faster real time responsiveness. --=20 --------------------------------------------------------------- Michael D. Johas Teener =8B mikejt@broadcom.com office +1-408-922-7542 cell +1-831-247-9666 fax +1-831-480-5845 http://xri.net/=3DMichael.Johas.Teener - PGP ID 0x3179D202 --------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 06:38:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2bV-00050M-Is; Thu, 26 Oct 2006 06:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2bV-00050H-2c for avt@ietf.org; Thu, 26 Oct 2006 06:36:53 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd2bR-0003GW-Ii for avt@ietf.org; Thu, 26 Oct 2006 06:36:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Oct 2006 12:36:45 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03FA5708@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated agenda for the San Diego AVT session Thread-Index: Acb46qJSlZfAmvGPTNSmgmC5vEtLeQ== From: "Even, Roni" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [AVT] Updated agenda for the San Diego AVT session X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, The updated agenda is in http://www3.ietf.org/proceedings/06nov/agenda/avt.html Thanks Roni Even _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 09:07:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4vk-0004jS-JJ; Thu, 26 Oct 2006 09:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4vi-0004jI-W4 for avt@ietf.org; Thu, 26 Oct 2006 09:05:55 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd4ve-0004kT-Bw for avt@ietf.org; Thu, 26 Oct 2006 09:05:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Oct 2006 15:05:47 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03FA5748@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AVT agenda - text version Thread-Index: Acb4/3RJ2nKmJ16PTzye7FzSg6zMDw== From: "Even, Roni" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Colin Perkins Subject: [AVT] AVT agenda - text version X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org This is the updated agenda Audio/Video Transport (AVT) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Colin Perkins Tom Taylor Roni Even AGENDA Tuesday, 7 November 2006 at 09:00-11:30 (Grande Ballroom A) ----------------------------------------------------------- 09:00 Introduction and Status Update (Chairs, 15) 09:15 RTP Payload Format for SVC (Wenger, 15) draft-wenger-avt-rtp-svc-03.txt 09:30 Signaling of media decoding dependency in SDP (Schierl, 5) draft-schierl-mmusic-layered-codec-01.txt 09:35 RTP Payload Format for DV (IEC 61834) Video (Kobayashi, 5) draft-kobayashi-avt-rfc3189-bis-00.txt 09:40 Multiplexing RTP RTCP on a Single Port ( Perkins, 15) draft-ietf-avt-rtp-and-rtcp-mux-00.txt 09:55 ZRTP: RTP based DH Key Agreement for SRTP (Zimmermann, 15) draft-zimmermann-avt-zrtp-02.txt 10:10 DTLS extension to establish keys for SRTP (McGrew, 15) draft-mcgrew-tls-srtp-00.txt 10:25 RTP & layer 2 QoS (Teener, 10) 10:35 VoIP Shim for RTP Payload Formats (Johansson, 35) draft-johansson-avt-rtp-shim-01.txt 11:10 End _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 09:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5hu-0000ot-Bf; Thu, 26 Oct 2006 09:55:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5ht-0000nt-1d for avt@ietf.org; Thu, 26 Oct 2006 09:55:41 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5gQ-0006Oi-KH for avt@ietf.org; Thu, 26 Oct 2006 09:54:18 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 09:54:10 -0400 To: "Greg Herlein" Subject: Re: [AVT] AVT draft agenda References: <3EE93E55-781C-47C8-B21C-B0B6B2F45FCA@eecs.berkeley.edu> <453F53E5.5060005@nortel.com> <31d1be720610251951x54e455fbn73381d663f0508b1@mail.gmail.com> From: Randell Jesup Date: Thu, 26 Oct 2006 09:54:08 -0400 In-Reply-To: <31d1be720610251951x54e455fbn73381d663f0508b1@mail.gmail.com> (Greg Herlein's message of "Wed, 25 Oct 2006 19:51:38 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 26 Oct 2006 13:54:10.0063 (UTC) FILETIME=[362C49F0:01C6F906] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: lazzaro , avt@ietf.org, Tom-PT Taylor X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Greg Herlein" writes: >I missed the original post but am highly interested in this discussion >and standard solution. My application for this involves several >displays playing the same multicast stream and having the desire to >syncronize the playback of those streams to the frame level to the >maximum extent possible. Variations in transit time and jitter buffer >processing will make this difficult without some kind of >syncronization. Having a clock on the wire would solve part of this. That's much more of a higher-level issue IMHO. Synchronization based on transit and jitter buffer time is an application issue. Synchronizing clocks can be done now using NTP and the like; once you have synchronized clocks you can build a synchronized display on top of that. RTCP (or in theory signalling) can let you know the NTP time at the sender for each RTP timestamp. A clock on the wire doesn't solve the application-level issues; it seems to be at most a replacement for (local) NTP. If there's a strong need for a local-network NTP replacement or alternative, that should be done within that context, and allow LAN nodes to be dumb whenever possible. But I'm just guessing without seeing the rationale for this proposal. Some level of coordination is required if the jitter buffers aren't of a static depth, and/or providing at the session level some sort of indication of how long after sampling every display is to show the frame (say evey display will show a frame 150ms after it was captured). That effectively gives you a maximum delay in transit; if it doesn't make it there in time you skip it. In this case, the buffer is really not a "jitter buffer" per se. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 10:00:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5lj-0003HT-Cn; Thu, 26 Oct 2006 09:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5iN-00018d-JQ for avt@ietf.org; Thu, 26 Oct 2006 09:56:11 -0400 Received: from outlook.hmgsl.com ([65.112.197.59] helo=hmgslx4.hmg.ad.harman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5Vl-0004M1-4U for avt@ietf.org; Thu, 26 Oct 2006 09:43:17 -0400 Received: from HMGSLX5.hmg.ad.harman.com ([10.30.28.165]) by hmgslx4.hmg.ad.harman.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Oct 2006 07:42:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] precise synchronization Date: Thu, 26 Oct 2006 07:42:57 -0600 Message-ID: <47F578483ACDDB42B25CAFBA7060279101A1FE2F@HMGSLX5.hmg.ad.harman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] precise synchronization thread-index: Acb4r5NWdOxz/z38T8uGtRg5W5kN1gAUi40Q From: "Boatright, Robert" To: X-OriginalArrivalTime: 26 Oct 2006 13:42:57.0810 (UTC) FILETIME=[A57A9F20:01C6F904] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org John Lazzaro wrote: > -----Original Message----- > From: lazzaro [mailto:lazzaro@eecs.berkeley.edu]=20 > Sent: Wednesday, October 25, 2006 9:32 PM > To: avt@ietf.org > Cc: lazzaro > Subject: [AVT] Re: avt Digest, Vol 30, Issue 23 > > ... > All the mics are picking up the sound of every drum a little bit ... > and so you really want the audio as tightly synchronized as possible, > down to the audio sample if you can (@96 kHz, we're talking =20 > microseconds). > ...=20 To complete with legacy analog quality, pro audio networks must preserve both sample and intra-sample coherency for both sources and sinks. At 96 kHz, an audio sample is already ~10 uS. To drive down latency, 192 kHz apps are becoming more common - that means a sample rate of ~5 uS. Pro audio needs sub-microsecond synchronization for digital audio networks. -------------------------------------------- Robert Boatright - Harman Pro rboatright at harman dot com -------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 10:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5oX-0004Zn-Fe; Thu, 26 Oct 2006 10:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5oW-0004Zi-WC for avt@ietf.org; Thu, 26 Oct 2006 10:02:33 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5oU-0000An-VG for avt@ietf.org; Thu, 26 Oct 2006 10:02:32 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 10:02:30 -0400 To: lazzaro Subject: Re: [AVT] Re: avt Digest, Vol 30, Issue 23 References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> From: Randell Jesup Date: Thu, 26 Oct 2006 10:02:29 -0400 In-Reply-To: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> (lazzaro@eecs.berkeley.edu's message of "Wed, 25 Oct 2006 20:31:41 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 26 Oct 2006 14:02:30.0895 (UTC) FILETIME=[60B12FF0:01C6F907] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org lazzaro writes: >> Just wondering: why is precise synchronization important? Especially >> since sync will drift. And why do the network elements need to know? >> Perhaps you're trying to instill knowledge into the network of how long >> a packet has been "in-transit"? > > >Imagine having a set 801.11 wireless microphones that you put >around a drum kit (one on the hi-hat, one on the snare drum, etc). >The antenna and the network stack CPU is inside the mic. Each >mic is sending an independent RTP stream out over the air, >which a DAW is recording simultaneously, one track per mic. Ok. Nothing odd here. >All the mics are picking up the sound of every drum a little bit ... >and so you really want the audio as tightly synchronized as possible, >down to the audio sample if you can (@96 kHz, we're talking microseconds). Ok. There are a number of ways to approach this. >If you had delay-compensated precise clocking multicast over the network, >and if you had a Layer 2 stack on the microphone that recognized it was >sending RTCP packets and rewrote the NTP field on the way to the antenna, >the RTP sender app in the mic could just write 0s in the NTP field -- it's >code could be written to know that the Layer-2 part of the network stack >would be rewriting in tight NTP. Uhhhh. That sounds like a horrible layer-violation to me off the top of my head. Not to mention that it's wrong - you need the sample time, NOT the transmission time here. If you have the sample times (accurately) in the RTP headers as RTP timestamps, and use RTCP often enough to avoid noticable drift (see the AVPF spec if needed), then you're set. No network transit times needed. Note also that the speed of sound is on the order of 12"/millisecond, so you're not going to get microsecond-sample-precise matching on the mics anyways. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 10:42:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6QL-0005Ka-OY; Thu, 26 Oct 2006 10:41:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6QI-00052b-1x for avt@ietf.org; Thu, 26 Oct 2006 10:41:34 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6Q9-0006Ou-3P for avt@ietf.org; Thu, 26 Oct 2006 10:41:34 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9QEfMeM004701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Oct 2006 07:41:24 -0700 (PDT) In-Reply-To: References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lazzaro Date: Thu, 26 Oct 2006 07:41:21 -0700 To: avt@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: lazzaro Subject: [AVT] Re: AVT draft agenda X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 26, 2006, at 7:02 AM, Randell Jesup wrote: > > >> If you had delay-compensated precise clocking multicast over the >> network, >> and if you had a Layer 2 stack on the microphone that recognized >> it was >> sending RTCP packets and rewrote the NTP field on the way to the >> antenna, >> the RTP sender app in the mic could just write 0s in the NTP field >> -- it's >> code could be written to know that the Layer-2 part of the network >> stack >> would be rewriting in tight NTP. [...] > Uhhhh. That sounds like a horrible layer-violation to me off the > top of my > head. Layers are good for clean specification. But once the specifications are written, implementors have always merged layers of the stack in the codebase where there is a compelling reason to do so. > Not to mention that it's wrong - you need the sample time, NOT the > transmission time here. If you have the sample times (accurately) > in the > RTP headers as RTP timestamps, and use RTCP often enough to avoid > noticable > drift (see the AVPF spec if needed), then you're set. The assumption here is that the path from your application layer to Layer 2 is so short that the sample time is the transmission time -- the last thing your app does to the RTCP packet is add the RTP timestamp (setting the sample time), then it hands it off the stack which immediately writes the NTP time and sends the packet. And you use an OS (or the lack thereof) that lets the path down to stack be short enough for this to work. > No network transit times needed. If you want the sampling instant for these 5 microphones that have no wires connecting them to be synchronized, you have to have a way to get a common clock to all of them, that is good down to microseconds (see below), and a network-layer clock is not a bad approach. > Note also that the speed of sound is on the order of 12"/ > millisecond, so > you're not going to get microsecond-sample-precise matching on the > mics > anyways. Not the issue of interest here. The high-hat mic hears the high-hat with N millisecond latency, the snare at M millisecond latency, etc, because of the speed of sound M != N. The snare mic hears the snare with P millisecond latency and the hi-hat with Q millisecond latency, because of the speed of sound P != Q. The values of N, M, P, and Q depend on the relative positions of the mics to each other and the drums. If you want to mix those two microphones together and not have phasey sounds happening as the two clock drift (even by a few samples -- cymbals and snares have lots of high frequencies), you want sample-accurate synchronization between the two mics. In other words, you want the "sound stage" created by the relative timings to be rock solid. That's why people run analog wires from all the mics to one A/D box where all the mics are sampled from the same clock. The challenge is to get rid of those wires, and replace them with standardized digital wireless networks. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 11:22:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd72h-00029v-Gd; Thu, 26 Oct 2006 11:21:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd72f-0001sB-FE for avt@ietf.org; Thu, 26 Oct 2006 11:21:13 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd72X-0006sQ-3x for avt@ietf.org; Thu, 26 Oct 2006 11:21:13 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:60262) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Gd72W-0003S6-0b; Thu, 26 Oct 2006 16:21:04 +0100 In-Reply-To: <453F96FC.6010006@sipstation.com> References: <453F96FC.6010006@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Thu, 26 Oct 2006 16:21:00 +0100 To: Alan Johnston X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org [This is being sent to avt@ietf.org with a bcc to rtpsec; response to avt please since that is the group responsible for RTP] I have reviewed draft-zimmerman-avt-zrtp-02.txt and have some serious concerns regarding the way ZRTP integrates with the RTP architecture. In particular, I believe this draft misuses both the RTP synchronisation source (SSRC) and the RTP header extension mechanism. 1) Misuse of the RTP synchronisation source (SSRC): the latest draft states (section 5) that ZRTP endpoints "MAY use a different SSRC for ZRTP messages than for RTP media" since this allows "for very loose coupling between the ZRTP application and the RTP media application". This violates RFC 3550 in several fundamental ways: a) RFC 3550 specifies that the SSRC identifies the "source of a stream of RTP packet" and requires receivers to group packets according to SSRC for playout and other processing. Using a separate SSRC for ZRTP and RTP data belonging to a single flow breaks playout buffer operation, and requires receivers to ignore the RFC 3550 rules on source identification. b) If a different SSRC is used for ZRTP packets than for RTP packets, it is not possible to differentiate packets from different participants, unless unicast sessions with only two parties are assumed. This breaks multicast and multiparty RTP, as well as mixers and translators operating according under RFC 3550. c) Use of a different SSRC for ZRTP and RTP packets can disrupt the correct operation of the RTP collision and loop detection algorithm. In addition, use of a different SSRC for ZRTP and RTP packets will disrupt RTP header compression efficiency. 2) Misuse of the RTP header extension: the RTP architecture provides for a clean separation between media data and media path control data, providing a control channel in the form of RTCP associated with every data flow. ZRTP ignores this control channel, and instead mixes control and data traffic in an RTP header extension. This is a gross and needless violation of the architecture, which significantly complicates the resulting system. It also has several practical problems: a) The header extension will significantly expand the size of ZRTP packets, likely leading to them being discarded when traversing optimized paths (for example, various wireless links). b) ZRTP cannot be used in conjunction with the general mechanism for RTP header extensions defined in draft-ietf-avt-rtp-hdrext-06.txt. None of these problems need exist. ZRTP can be trivially reworked to use a new RTCP packet type, potentially multiplexed onto the same port as the data, with the same SSRC as the stream it is protecting. This would have the same security properties as the current draft, but would conform to the RTP architecture and avoid the breakage listed above, would work in a wider range of environments, and would encourage the take-up of RTCP (which is already needed to support a range of features of RTP such as lip-synchronisation, codec control, etc.). We have an architecture which cleanly supports all the features that ZRTP needs. Please use it, rather than trying to perpetuate the (broken) PSTN secure phone model. Colin On 25 Oct 2006, at 17:55, Alan Johnston wrote: > All, > > The ZRTP I-D has been updated. There are lots of changes in the > document including: > > > - Discussion of how ZRTP compares using the criteria in draft-wing- > rtpsec-keying-eval-01.txt > > - Discovery and authentication of ZRTP through the signaling > channel and the definitions and ABNF of three SDP attributes > a=zrtp, a=zrtp-sas, a=zrtp-sasvalue. > > - New Multistream key agreement mode allowing SRTP keys for > multiple media streams in a session to be derived from a single > ZRTP DH exchange. > > - CRC protection of ZRTP messages against transport errors using a > 32 bit CRC algorithm > > - Use of RTP no-op packets instead of comfort noise packets > > - Simplified shared secret comparison algorithm > > - New Stay secure and Disclosure flags > > - More details on caching of retained shared secrets including > expiration intervals > > - Removal of Error message - Reason field added to GoClear > > - Discussion of the behavior of intermediary devices that might > implement ZRTP > > > We will be discussing the changes in the ZRTP protocol in the AVT > working group and the SDP attributes in MMUSIC. > > As always, comments and feedback are most welcome. > > Thanks, > Alan > > > -------- Original Message -------- > Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt > Date: Tue, 24 Oct 2006 15:50:02 -0400 > 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 : ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement > for SRTP > Author(s) : P. Zimmermann, et al. > Filename : draft-zimmermann-avt-zrtp-02.txt > Pages : 52 > Date : 2006-10-24 > > This document defines ZRTP, RTP (Real-time Transport Protocol) header > extensions for a Diffie-Hellman exchange to agree on a session key > and parameters for establishing Secure RTP (SRTP) sessions. The > ZRTP > protocol is completely self-contained in RTP and does not require > support in the signaling protocol or assume a Public Key > Infrastructure (PKI) infrastructure. For the media session, ZRTP > provides confidentiality, protection against Man in the Middle > (MitM) > attacks, and, in cases where a secret is available from the > signaling > protocol, authentication. ZRTP can utilize three Session > Description > Protocol (SDP) attributes to provide discovery and authentication > through the signaling channel. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt > > To remove yourself from the I-D Announcement list, send a message > to i-d-announce-request@ietf.org with the word unsubscribe in the > body of the message. You can also visit https://www1.ietf.org/ > mailman/listinfo/I-D-announce to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then "get draft- > zimmermann-avt-zrtp-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- > sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 13:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9LL-0008Cj-2T; Thu, 26 Oct 2006 13:48:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9Kc-0007ZI-2C for avt@ietf.org; Thu, 26 Oct 2006 13:47:54 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd9Fu-0005to-O5 for avt@ietf.org; Thu, 26 Oct 2006 13:43:07 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 13:43:00 -0400 To: Michael Johas Teener Subject: Re: [AVT] Re: Layer 2 synchronization and clock References: From: Randell Jesup Date: Thu, 26 Oct 2006 13:43:00 -0400 In-Reply-To: (Michael Johas Teener's message of "Wed, 25 Oct 2006 20:45:23 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Oct 2006 17:43:00.0936 (UTC) FILETIME=[2E693C80:01C6F926] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: IETF AV Transport WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Michael Johas Teener writes: >Randell Jesup wrote: >> "Tom-PT Taylor" writes: >>> Precise time synchronization so that every network element will >>> have access to a very high quality clock (done via a layer 2 >>> profile of the new revision of IEEE 1588). This is being done as >>> project 802.1AS, and it¹s well on its way. >> >> Just wondering: why is precise synchronization important? Especially since >> sync will drift. And why do the network elements need to know? Perhaps >> you're trying to instill knowledge into the network of how long a packet >> has been "in-transit"? >> >> RTP provides for a higher-level end-to-end synchronization on a per-stream >> level (RTCP and NTP), though for reasons having to do with its origin in >> multicast scenarios synchronization can take a short while. (There are >> ways around that like AVPF). Is there a reason this part of the problem >> couldn't be addressed by protocol modifications at that level? > >Synchronization is useful for two primary reasons, and the "precise" part of >it is relative to the particular application. > >1) Clearly there are streams that need to be rendered at different devices >in synchronization. A simple (though not really precise) example is >lip-synch, where the video going to the display must be synchronized with >the sound rendered by a speaker (20ms is usually considered "good enough" >for that). NTP sync exchanged via RTCP is sufficient for this level. > The next level of synchronization is that needed for correct >sound "imaging" for a multiple speaker system. Depending on the nature of >system, synchronization down to 100s or even 10s of microseconds is needed >for proper phasing. There are industrial, telecom, and instrumentation >requirements that are even more extreme ... IEEE 1588 systems are aimed down >to the sub-nanosecond level. Again, inter-device NTP sync (or equivalent, i.e. at the device level not the network-element level) should be sufficient I believe for this. With sufficiently frequent RTCP or with other non-RTP/RTCP protocols (since while RTP/RTCP can do this it wasn't specifically designed for it), this shouldn't be a problem. >2) The network needs to avoid introducing any jitter or wander to the >distributed clock that cannot be easily filtered. The clock provided by the >802.1AS service is intended to be used by applications for sampling, and so >must meet the MTIE mask for that application. The baseline requirement is to >support uncompressed video, which means a application-level jitter of around >10ps at high frequencies. Why do you need to use this network-generated clock for sampling directly, and not a local clock synchronized between devices? Do you really need 10ps sampling synchronization between devices? How often? And if so, is this really the way to get it? >Of course, many of these requirements can be met by pure RTCP/NTP systems, >but at the cost of latency for the buffers and the fairly long control >loops. The 802.1AS part of our work is intended to allow much of the simple >work to be done at lower layers in the network element hardware. With any >luck, the work we are doing will hook to higher layers to allow shallower >buffers and faster real time responsiveness. What I don't see is how this will do that, and what it will do that either existing mechanisms (or new mechanisms at the same level) can't do. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 14:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9zK-0004Z7-EK; Thu, 26 Oct 2006 14:29:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9zJ-0004Yr-AU for avt@ietf.org; Thu, 26 Oct 2006 14:29:57 -0400 Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd9zE-0005pM-Vu for avt@ietf.org; Thu, 26 Oct 2006 14:29:57 -0400 Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 26 Oct 2006 14:29:53 -0400 X-IronPort-AV: i="4.09,362,1157342400"; d="scan'208"; a="332296888:sNHT30512598" Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id HKI32544; Thu, 26 Oct 2006 14:29:27 -0400 (EDT) Received: from 162-144-2.cortland.com.144.162.209.in-addr.arpa (HELO erols.com) ([209.162.144.2]) by smtp01.lnh.mail.rcn.net with ESMTP; 26 Oct 2006 14:29:26 -0400 X-IronPort-AV: i="4.09,362,1157342400"; d="scan'208"; a="300782628:sNHT24575330" Message-ID: <4540FE74.73613EB3@erols.com> Date: Thu, 26 Oct 2006 11:29:08 -0700 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: lazzaro References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/50, host=mr08.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.4540FE66.00BB,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.113/2006-07-26 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: avt@ietf.org Subject: [AVT] Layer 2 clock sync [was: AVT draft agenda] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org John, I agree with Randell's observation that what is needed here is an accurate (submicrosecond) relationship between sample instant and NTP clock. This relationship is communicated through the RTCP mechansim. The delays between sampling and packet transmission (whether they arise in the OS, the hardware, or whatever) are simply part of the transmission jitter/delay budget and are irrelevant to the precision of the end-to-end system. Especially so in recording-system or one-way scenarios where latency bounds can be extremely relaxed. >From the review in http://www.ieee802.org/1/files/public/docs2006/as-garner-use-of-p2p-tc-in-avb-0406.pdf I gather that the Precision Time Protocol & Audio Visual Bridging work fits into the RTP architecture simply as a precise way to maintain NTP synchronization. There is nothing broken about the RTP architecture (although the interpretation of SR transmission time in RFC3550 sec. 6.4.1 must be finessed to RTP-timestamp granularity). This work just gives us a better wallclock. The only weakness in RTP's sync architecture is that is over- loads two functions on the same mechanism: (1) transport jitter measurement and (2) multistream media synchronization. In pro AV applications, the latter function is far more demanding, but the RFC text usually emphasizes the former function. Perhaps for this reason, implementations often perform much more poorly in regard to cross-media timing than is possible. One thing that *is* missing from RTP is the concept of sample clock synchronization across multiple sources. The 5-year-old AES42 standard for digital microphones can be used for inspiration. A brief description is on page 10 of this document: http://www.neumann.com/download.php?download=lect0042.PDF As an aside, the actual jitter performance of the sample clocks used for capture and reproduction must be *way* below one sample (sub-nanosecond, in fact, for pro quality audio). Otherwise the sampling jitter introduces distortion proportional to the instantaneous slope of the waveform. In those cases where the clock jitter is correlated with the signal you can get audible artifacts at a few hundred picoseconds. No joke! That's why PLL design for high-end audio equipment is a fine art and often relies on VCXOs. The thing that jumps out at me in looking (for the first time) at the 802.1as work and your drum-kit scenario is that wireless is such an important application area and that 802.1as seems to be ducking the implications of that for now. I have had some thoughts on that but they are O.T. to this avt forum. In peace and low jitter, Chuck lazzaro wrote: > > On Oct 26, 2006, at 7:02 AM, Randell Jesup wrote: > > > > > >> If you had delay-compensated precise clocking multicast over the > >> network, > >> and if you had a Layer 2 stack on the microphone that recognized > >> it was > >> sending RTCP packets and rewrote the NTP field on the way to the > >> antenna, > >> the RTP sender app in the mic could just write 0s in the NTP field > >> -- it's > >> code could be written to know that the Layer-2 part of the network > >> stack > >> would be rewriting in tight NTP. > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 16:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBNT-0002O7-5q; Thu, 26 Oct 2006 15:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMz-00024k-Jb for avt@ietf.org; Thu, 26 Oct 2006 15:58:29 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdB8U-0006w8-FZ for avt@ietf.org; Thu, 26 Oct 2006 15:43:33 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9QJhA6F010576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Oct 2006 12:43:12 -0700 (PDT) In-Reply-To: <4540FE74.73613EB3@erols.com> References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> <4540FE74.73613EB3@erols.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lazzaro Date: Thu, 26 Oct 2006 12:43:09 -0700 To: Chuck Harrison X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: avt@ietf.org Subject: [AVT] Re: Layer 2 clock sync [was: AVT draft agenda] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 26, 2006, at 11:29 AM, Chuck Harrison wrote: > The delays between sampling and packet transmission > (whether they arise in the OS, the hardware, or whatever) are > simply part of the transmission jitter/delay budget and are > irrelevant to the precision of the end-to-end system. Especially > so in recording-system or one-way scenarios where latency bounds > can be extremely relaxed. Performers on stage are typically using monitoring systems (in-ear, or speakers in front of them on the floor or a stand). So, the latency from the wireless mic, through the mixing console, and back up to the stage is critical, and can't be relaxed -- 2 ms would make many but not all performers happy (vocalists in particular are very sensitive to this -- especially using in-ear). Likewise, using these networks as the first-hop for long-distance network musical performance systems are also an application where every millisecond counts. So, I'm wary of declaring this effort to be latency relaxed ... for some applications it isn't. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 16:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBND-0002EC-K9; Thu, 26 Oct 2006 15:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMs-00021C-So; Thu, 26 Oct 2006 15:58:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBFt-0007K6-Nq; Thu, 26 Oct 2006 15:51:09 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdBFt-0005y2-7t; Thu, 26 Oct 2006 15:51:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5AB102AD3F; Thu, 26 Oct 2006 19:50:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEv-0005MP-1b; Thu, 26 Oct 2006 15:50:09 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Oct 2006 15:50:09 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback Author(s) : J. Chesterfield, et al. Filename : draft-ietf-avt-rtcpssm-12.txt Pages : 58 Date : 2006-10-26 This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcpssm-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcpssm-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26133706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcpssm-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcpssm-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26133706.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 26 16:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBNT-0002O7-5q; Thu, 26 Oct 2006 15:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMz-00024k-Jb for avt@ietf.org; Thu, 26 Oct 2006 15:58:29 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdB8U-0006w8-FZ for avt@ietf.org; Thu, 26 Oct 2006 15:43:33 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9QJhA6F010576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Oct 2006 12:43:12 -0700 (PDT) In-Reply-To: <4540FE74.73613EB3@erols.com> References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> <4540FE74.73613EB3@erols.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lazzaro Date: Thu, 26 Oct 2006 12:43:09 -0700 To: Chuck Harrison X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: avt@ietf.org Subject: [AVT] Re: Layer 2 clock sync [was: AVT draft agenda] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 26, 2006, at 11:29 AM, Chuck Harrison wrote: > The delays between sampling and packet transmission > (whether they arise in the OS, the hardware, or whatever) are > simply part of the transmission jitter/delay budget and are > irrelevant to the precision of the end-to-end system. Especially > so in recording-system or one-way scenarios where latency bounds > can be extremely relaxed. Performers on stage are typically using monitoring systems (in-ear, or speakers in front of them on the floor or a stand). So, the latency from the wireless mic, through the mixing console, and back up to the stage is critical, and can't be relaxed -- 2 ms would make many but not all performers happy (vocalists in particular are very sensitive to this -- especially using in-ear). Likewise, using these networks as the first-hop for long-distance network musical performance systems are also an application where every millisecond counts. So, I'm wary of declaring this effort to be latency relaxed ... for some applications it isn't. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 16:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBND-0002EC-K9; Thu, 26 Oct 2006 15:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMs-00021C-So; Thu, 26 Oct 2006 15:58:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBFt-0007K6-Nq; Thu, 26 Oct 2006 15:51:09 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdBFt-0005y2-7t; Thu, 26 Oct 2006 15:51:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5AB102AD3F; Thu, 26 Oct 2006 19:50:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEv-0005MP-1b; Thu, 26 Oct 2006 15:50:09 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Oct 2006 15:50:09 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback Author(s) : J. Chesterfield, et al. Filename : draft-ietf-avt-rtcpssm-12.txt Pages : 58 Date : 2006-10-26 This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcpssm-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcpssm-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26133706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcpssm-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcpssm-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26133706.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 26 16:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdByV-0001zJ-0L; Thu, 26 Oct 2006 16:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBtc-0008Cu-GP for avt@ietf.org; Thu, 26 Oct 2006 16:32:12 -0400 Received: from mail11.disney.com ([192.195.66.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBlG-000348-Ic for avt@ietf.org; Thu, 26 Oct 2006 16:23:43 -0400 Received: from imr11.disney.pvt (imr11.disney.pvt [153.6.60.111]) by mail11.disney.com with ESMTP; Thu, 26 Oct 2006 16:23:35 -0400 Received: from sm-flor-xgw02b.wdw.disney.com (sm-flor-xgw02b.wdw.disney.com [153.6.172.148]) by imr11.disney.pvt with ESMTP; Thu, 26 Oct 2006 16:23:33 -0400 Received: from sm-flor-xrc02.wdw.disney.com ([153.6.172.139]) by sm-flor-xgw02b.wdw.disney.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 16:23:33 -0400 Received: from sm-nyny-xrc02b.nena.wdpr.disney.com ([167.13.137.111]) by sm-flor-xrc02.wdw.disney.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 16:23:33 -0400 Received: from SM-NYNY-VXMB01B.nena.wdpr.disney.com ([167.13.137.132]) by sm-nyny-xrc02b.nena.wdpr.disney.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 16:23:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Re: Layer 2 clock sync [was: AVT draft agenda] Date: Thu, 26 Oct 2006 16:23:31 -0400 Message-Id: <13C9C98A375E9144B63166DE03B6D55E17A68E@SM-NYNY-VXMB01B.nena.wdpr.disney.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Re: Layer 2 clock sync [was: AVT draft agenda] Thread-Index: Acb5ObpF/HD+QJU2SAywaykyJTqMlgAATBVA From: "Miller, William C" To: X-OriginalArrivalTime: 26 Oct 2006 20:23:32.0283 (UTC) FILETIME=[9B2428B0:01C6F93C] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Chuck is absolutely right. Latency is critical in any live application, including where a performance is recorded live for later broadcast. For talent to be able to use video or audio for cueing, latency must be kept to an absolute minimum. Cell phone end-to-end latencies, for instance, are typically at or beyond the threshhold of usability, even for dialog cueing. =20 For the application cited (miking a drum kit) differential latencies in the microseconds are required. For monitoring, I agree that 2 ms total latency is about the absolute limit. For this reason, I expect analog RF technologies to prevail in these applications. Best regards, Bill Miller William C. Miller ABC-TV =20 212-456-4448 phone 212-456-2284 fax william.c.miller@abc.com -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of lazzaro Sent: Thursday, October 26, 2006 3:43 PM To: Chuck Harrison Cc: avt@ietf.org Subject: [AVT] Re: Layer 2 clock sync [was: AVT draft agenda] On Oct 26, 2006, at 11:29 AM, Chuck Harrison wrote: > The delays between sampling and packet transmission > (whether they arise in the OS, the hardware, or whatever) are simply=20 > part of the transmission jitter/delay budget and are irrelevant to the > precision of the end-to-end system. Especially so in recording-system=20 > or one-way scenarios where latency bounds can be extremely relaxed. Performers on stage are typically using monitoring systems (in-ear, or speakers in front of them on the floor or a stand). So, the latency from the wireless mic, through the mixing console, and back up to the stage is critical, and can't be relaxed -- 2 ms would make many but not all performers happy (vocalists in particular are very sensitive to this -- especially using in-ear). Likewise, using these networks as the first-hop for long-distance network musical performance systems are also an application where every millisecond counts. So, I'm wary of declaring this effort to be latency relaxed ... for some applications it isn't. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 16:45:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdC5g-0008Oz-J0; Thu, 26 Oct 2006 16:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMu-0001zc-OO; Thu, 26 Oct 2006 15:58:24 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBEv-0007EY-7I; Thu, 26 Oct 2006 15:50:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 53C75328C2; Thu, 26 Oct 2006 19:50:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEu-0005Kf-6H; Thu, 26 Oct 2006 15:50:08 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Oct 2006 15:50:08 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Multiplexing RTP Data and Control Packets on a Single Port Author(s) : C. Perkins, M. Westerlund Filename : draft-ietf-avt-rtp-and-rtcp-mux-01.txt Pages : 13 Date : 2006-10-26 This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-and-rtcp-mux-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26120750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-and-rtcp-mux-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-and-rtcp-mux-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26120750.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 26 16:56:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCG1-00066g-9O; Thu, 26 Oct 2006 16:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCG0-00066H-0T for avt@ietf.org; Thu, 26 Oct 2006 16:55:20 -0400 Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCFW-0002DE-CA for avt@ietf.org; Thu, 26 Oct 2006 16:55:19 -0400 Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 26 Oct 2006 16:54:50 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id MKR82950; Thu, 26 Oct 2006 16:54:24 -0400 (EDT) Received: from 162-144-2.cortland.com.144.162.209.in-addr.arpa (HELO erols.com) ([209.162.144.2]) by smtp01.lnh.mail.rcn.net with ESMTP; 26 Oct 2006 16:54:22 -0400 X-IronPort-AV: i="4.09,362,1157342400"; d="scan'208"; a="300889755:sNHT121737178" Message-ID: <45412070.3EB5F764@erols.com> Date: Thu, 26 Oct 2006 13:54:08 -0700 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Miller, William C" Subject: Re: [AVT] Re: Layer 2 clock sync [was: AVT draft agenda] References: <13C9C98A375E9144B63166DE03B6D55E17A68E@SM-NYNY-VXMB01B.nena.wdpr.disney.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.45412060.0010,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.113/2006-07-26 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Miller, William C" wrote: > > Chuck is absolutely right. Latency is critical in any live > application, Actually, it's John Lazzaro you're quoting there. But I agree, he's absolutely right. And I think it's an attractive challenge to see how close to traditional analog performance we can come. As AES42 shows, you only have to pay a sub-sample-time latency penalty for going digital. But packetizing (e.g. onto Ethernet) always adds a delay penalty. Doesn't have to be a lot! Peace, Chuck _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 17:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCai-00079i-6u; Thu, 26 Oct 2006 17:16:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCag-00078l-1P for avt@ietf.org; Thu, 26 Oct 2006 17:16:42 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCaP-0007tu-TO for avt@ietf.org; Thu, 26 Oct 2006 17:16:41 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9QLGNFF012372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Oct 2006 14:16:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <45411EEA.D1AD3F7D@erols.com> References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> <4540FE74.73613EB3@erols.com> <45411EEA.D1AD3F7D@erols.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B44E845-7B60-48D2-A9AE-E0B7CBB65C22@eecs.berkeley.edu> Content-Transfer-Encoding: 7bit From: lazzaro Date: Thu, 26 Oct 2006 14:16:22 -0700 To: avt@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [AVT] Re: Layer 2 clock sync [was: AVT draft agenda] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 26, 2006, at 1:47 PM, Chuck Harrison wrote: > > However the layer-2 timestamping you seemed to suggest in >> [...] a Layer 2 stack on the microphone that recognized >> it was sending RTCP packets and rewrote the NTP field on >> the way to the antenna [...] > is ill-conceived for this task as far as I can tell. All I was suggesting here is an implementation alternative to: [1] Using a Layer-2 timing service to generate an NTP clock value that is tightly time-synchronized between all the nodes on the network (in my case, the multiple wireless mics). [2] Letting an application call a function to get the current NTP clock value and putting it in the RTCP NTP slot next to the matching RTP time stamp clock. My alternative tried to take a user-land function call/return, with all its return timing uncertainty, out of the picture. If you like [1] and [2] above, you like what I was trying to do in my quick example ... it was intended to do exactly as above, but replacing the function call jitter with the jitter of passing the IP packet down to Layer 2 where the clock code would sit. In retrospect, my idea is not the right one here. But what I was attempting to do is important -- if you're going to go through the effort of designing a way to have all the nodes on a network have a wall-clock accurate to the sub-audio-sample level, and you also want to use RTP, and you want to have RTCP NTP/RTP timestamp pairs that use that wall clock in a way that captures its accuracy, you HAVE to think about where the code handling IP and RTP sit in the stack relative to the Layer-2 code, and how timestamp accuracy is maintained in the implementation. That's part of why the IEEE folks seem to be coming to talk to us -- they want to use RTP, but they also want to provide timing and other services related to media at Layer 2, and they want to figure out a sensible way of integration that keeps the benefits of adding Layer 2 timing services. We should help them do that, otherwise we shouldn't be surprised if they design their own media transport protocol to use instead of RTP, that handles this problem by its design. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 18:05:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDKi-00010v-Rh; Thu, 26 Oct 2006 18:04:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDKg-0000OP-6v for avt@ietf.org; Thu, 26 Oct 2006 18:04:14 -0400 Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdDGF-0006Yb-DA for avt@ietf.org; Thu, 26 Oct 2006 17:59:42 -0400 Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 26 Oct 2006 17:59:39 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id MKS05163; Thu, 26 Oct 2006 17:59:27 -0400 (EDT) Received: from 162-144-2.cortland.com.144.162.209.in-addr.arpa (HELO erols.com) ([209.162.144.2]) by smtp01.lnh.mail.rcn.net with ESMTP; 26 Oct 2006 17:59:26 -0400 X-IronPort-AV: i="4.09,363,1157342400"; d="scan'208"; a="300935484:sNHT25590416" Message-ID: <45412FAF.73453C7B@erols.com> Date: Thu, 26 Oct 2006 14:59:11 -0700 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: lazzaro Subject: Re: [AVT] Re: Layer 2 clock sync References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> <4540FE74.73613EB3@erols.com> <45411EEA.D1AD3F7D@erols.com> <1B44E845-7B60-48D2-A9AE-E0B7CBB65C22@eecs.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.45412F90.00B6,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.113/2006-07-26 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Right on, John. The canonical operation required here is a function call that returns correlated values of two timebases -- in this case, the wallclock and the sample clock. This wants to be an atomic operation at the API level. For the most demanding market niches, it might be necessary to implement this at the hardware level (no problem, if you've got a few gates left over in an FPGA), but in the more usual case I figure it's an issue of tight coding in a kernel driver. Note that for this to work it is not critical that the function call return "very quickly" or even that the two correlated values it reports are accurately "now". "What time is it now" can and probably should be answered with an entirely different function call. Unfortunately in typical PC hardware I'm told it's difficult to get hold of honest information about the audio sample clock, no matter how slick your layer-2 NTP sync is. IMHO the "timebase correlation" API call shouldn't be dedicated to just the sampleclock-to-wallclock function. For example, querying for the correlation between audio sample clock and processor clock (e.g. from RDTSC) could be useful and implementable. Combined with another call correlating NTP to RDTSC value, and a little fudging, you'd be in pretty good shape to compute the wallclock:sampleclock relationship. Peace, Chuck lazzaro wrote: > > [...] what I > was attempting to do is important -- if you're going to go through > the effort of designing a way to have all the nodes on a network > have a wall-clock accurate to the sub-audio-sample level, and > you also want to use RTP, and you want to have RTCP > NTP/RTP timestamp pairs that use that wall clock in a way that > captures its accuracy, you HAVE to think about where the code > handling IP and RTP sit in the stack relative to the Layer-2 code, > and how timestamp accuracy is maintained in the implementation. > > That's part of why the IEEE folks seem to be coming to talk to us -- > they want to use RTP, but they also want to provide timing and > other services related to media at Layer 2, and they want to > figure out a sensible way of integration that keeps the benefits > of adding Layer 2 timing services. We should help them do that, > otherwise we shouldn't be surprised if they design their own media > transport protocol to use instead of RTP, that handles this problem > by its design. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 19:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEVp-0006MT-NQ; Thu, 26 Oct 2006 19:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdETT-00057H-1u for avt@ietf.org; Thu, 26 Oct 2006 19:17:23 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdEKB-0001rM-Ae for avt@ietf.org; Thu, 26 Oct 2006 19:07:48 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9QN7hpt014992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Oct 2006 16:07:45 -0700 (PDT) In-Reply-To: <45412FAF.73453C7B@erols.com> References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> <4540FE74.73613EB3@erols.com> <45411EEA.D1AD3F7D@erols.com> <1B44E845-7B60-48D2-A9AE-E0B7CBB65C22@eecs.berkeley.edu> <45412FAF.73453C7B@erols.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D611EBB-21D9-476C-BF73-9C61FBC4D38D@eecs.berkeley.edu> Content-Transfer-Encoding: 7bit From: lazzaro Subject: Re: [AVT] Re: Layer 2 clock sync Date: Thu, 26 Oct 2006 16:07:42 -0700 To: Chuck Harrison X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: lazzaro , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 26, 2006, at 2:59 PM, Chuck Harrison wrote: > The canonical operation required here is a function call that > returns correlated values of two timebases -- in this case, the > wallclock and the sample clock. This wants to be an atomic > operation at the API level. For the most demanding market niches, > it might be necessary to implement this at the hardware level > (no problem, if you've got a few gates left over in an FPGA), > but in the more usual case I figure it's an issue of tight > coding in a kernel driver. [...] > IMHO the "timebase correlation" API call shouldn't be dedicated > to just the sampleclock-to-wallclock function. For example, > querying for the correlation between audio sample clock and > processor clock (e.g. from RDTSC) could be useful and implementable. > Combined with another call correlating NTP to RDTSC value, > and a little fudging, you'd be in pretty good shape to compute > the wallclock:sampleclock relationship. For better or for worse, though, we're in the network protocol business in the IETF, not the API business (with a few exceptions, like sockets API). And so, if there were an implicit way to get wall-clock (as maintained by Layer 2's network service) and sample-clock (as maintained by the application level program) timebase correlation through the act of passing packets up and down the Layer-2/Layer-3 stack interface, then the IETF and IEEE could do business as usual and create the network protocol that specifies the Layer-2/Layer 3 interface. And so, I think it may be worth going off and looking for a solution of that nature ... --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 19:35:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEju-0007lf-Sj; Thu, 26 Oct 2006 19:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEja-0006fN-NV for avt@ietf.org; Thu, 26 Oct 2006 19:34:02 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdEbp-0005QS-EB for avt@ietf.org; Thu, 26 Oct 2006 19:26:02 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9QNPxNo015336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Oct 2006 16:26:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: avt@ietf.org From: lazzaro Subject: Re: [AVT] Re: Layer 2 synchronization and clock Date: Thu, 26 Oct 2006 16:25:57 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Randell Jesup wrote: > Why do you need to use this network-generated clock for sampling > directly, > and not a local clock synchronized between devices? If the devices are only connected by the network ... how else are the local devices going to synchronize? NTP is not designed to work for the synchronization timing that we're talking about here (sub-sample audio for high audio sample rates). Think about products like wireless stereo speakers with an antenna on each speaker -- unlike today's products where a wire connects the two speakers. How else will those two speakers synchronize to sub-sample level if not via the network? And PoE stereo speakers have the same issue, so its not only wireless. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From akstcagrpmnsdgs@agrp.com Thu Oct 26 19:38:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEnn-0002xg-FH for avt-archive@lists.ietf.org; Thu, 26 Oct 2006 19:38:23 -0400 Received: from dsl-207-112-69-53.tor.primus.ca ([207.112.69.53] helo=your-8cfb5dbe8b) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdEnm-00089y-7m for avt-archive@lists.ietf.org; Thu, 26 Oct 2006 19:38:23 -0400 Received: from 216.82.244.99 (HELO cluster1.us.messagelabs.com) by lists.ietf.org with esmtp (PR5BI1WE26B9 UH2V) id LQ33UR-BBTVI0-5Q for avt-archive@lists.ietf.org; Thu, 26 Nov 2006 23:38:26 +0300 Date: Thu, 26 Nov 2006 23:38:26 +0300 From: "Mac Dill" X-Mailer: The Bat! (v3.71.04) Business X-Priority: 3 (Normal) Message-ID: <348071201.47135575691621@thebat.net> To: avt-archive@lists.ietf.org Subject: pear blight beetle moon-trodden MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 1.6 (+) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 "and was denny convinced that wickham would not marry? did he know of=20= their intending to From jlwakrmpihj@altorfer.com Thu Oct 26 20:05:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFE6-0002ek-F2 for avt-archive@lists.ietf.org; Thu, 26 Oct 2006 20:05:34 -0400 Received: from port-ip-213-211-254-150.reverse.mdcc-fun.de ([213.211.254.150] helo=feuerweh-oxpfsb.mdcc-net.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFDE-0003er-Qp for avt-archive@lists.ietf.org; Thu, 26 Oct 2006 20:04:45 -0400 Received: from 216.203.116.105 (HELO mail2.altorfer.com) by lists.ietf.org with esmtp (AYOBA33S NVVU6X) id Y4DD40-2ONB2S-XD for avt-archive@lists.ietf.org; Fri, 27 Oct 2006 00:04:41 -0060 From: "Annmarie" To: Subject: Notice from nokia forum Date: Fri, 27 Oct 2006 00:04:41 -0060 Message-ID: <01c6f95b$801b97f0$6c822ecf@jlwakrmpihj> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Thread-Index: Aca6Q4JNEBD8K1Z72HGBX3LPZSMGUV== X-Spam-Score: 2.0 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The big announcement is coming out very soon and this one is going to triple in a matter of days. Did they strike the mother load? We can't say. All we can say for now is that this revelation is going to be huge, and will cause a rush on this issue. The time to get in is now! Price: $O.77 Projected: $2.30 Rating: 5/5 This is the break you've been waiting for! Spice up your holdings with AUNI and WIN! Watch AUNI soar on Friday 27 oct. --- DES MOINES, Iowa (CNN) -- President Bush on Thursday said the decision by New Jersey's Supreme Court that same-sex couples are entitled to the rights and benefits of marriage is a ruling by an "activist court." WASHINGTON (CNN) -- Defense Secretary Donald Rumsfeld on Thursday said the quality of the armaments utilized by Iraq pales compared to those wielded by the United States, and he empathizes with the frustrations Iraqi leaders face because of this. NEW YORK (CNNMoney.com) -- ExxonMobil, the world's largest publicly traded oil company and the biggest corporation by revenue, reported on Thursday the second largest profit ever. NEW YORK (CNNMoney.com) -- New home prices took their biggest hit in more than 35 years in September, the government said Thursday, the latest sign that builders are struggling to unload a glut of unsold homes as the nation's real estate market cools. From avt-bounces@ietf.org Thu Oct 26 20:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFxv-0000Ju-6e; Thu, 26 Oct 2006 20:52:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFxu-0000Fk-4T for avt@ietf.org; Thu, 26 Oct 2006 20:52:54 -0400 Received: from host1.cruzio.com ([63.249.95.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFxn-0006G5-9f for avt@ietf.org; Thu, 26 Oct 2006 20:52:54 -0400 Received: (qmail 32861 invoked from network); 26 Oct 2006 17:52:46 -0700 Received: from dsl-63-249-108-248.cruzio.com (HELO ?192.168.182.252?) (63.249.108.248) by avbridging.com with SMTP; 26 Oct 2006 17:52:46 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 26 Oct 2006 17:52:44 -0700 From: Michael Johas Teener To: IETF AV Transport WG Message-ID: Thread-Topic: avt Digest, Vol 30, Issue 26 Thread-Index: Acb5YjZQdOUbmmVVEdujJgAUUQECpg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [AVT] Re: avt Digest, Vol 30, Issue 26 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 10/26/06 2:16 PM, John Lazzaro wrote: > That's part of why the IEEE folks seem to be coming to talk to us -- > they want to use RTP, but they also want to provide timing and > other services related to media at Layer 2, and they want to > figure out a sensible way of integration that keeps the benefits > of adding Layer 2 timing services. We should help them do that, > otherwise we shouldn't be surprised if they design their own media > transport protocol to use instead of RTP, that handles this problem > by its design. Yep, exactly. There are already enough of these kind of media transport protocols around on non-802 nets, and they aren't going away. For example, on IEEE 1394 (FireWire) they use the IEC 61883 family of protocols to provide time-stamping/media-presentation/metadata services. There are simpler (although somewhat convoluted and proprietary) methods used for telecom adaptions of Ethernet. Perhaps, with a bit of thought on everyone's part, we could move these streams onto an RTP-based architecture *if* we can provide the same kind of very low latency and largely hardware-driven data pumps. I think it's highl= y probable that we can do this, and that's why I'm coming to the IETF. --=20 --------------------------------------------------------------- Michael D. Johas Teener =8B mikejt@broadcom.com office +1-408-922-7542 cell +1-831-247-9666 fax +1-831-480-5845 http://xri.net/=3DMichael.Johas.Teener - PGP ID 0x3179D202 --------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 20:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFxh-0008L5-Ok; Thu, 26 Oct 2006 20:52:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFxg-0008Kb-Hy for avt@ietf.org; Thu, 26 Oct 2006 20:52:40 -0400 Received: from host1.cruzio.com ([63.249.95.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFxd-0006DQ-3K for avt@ietf.org; Thu, 26 Oct 2006 20:52:40 -0400 Received: (qmail 32801 invoked from network); 26 Oct 2006 17:52:36 -0700 Received: from dsl-63-249-108-248.cruzio.com (HELO ?192.168.182.252?) (63.249.108.248) by avbridging.com with SMTP; 26 Oct 2006 17:52:36 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 26 Oct 2006 17:52:33 -0700 Subject: Re: [AVT] Re: Layer 2 synchronization and clock From: Michael Johas Teener To: IETF AV Transport WG Message-ID: Thread-Topic: [AVT] Re: Layer 2 synchronization and clock Thread-Index: Acb5Yi/CbjJVxGVVEdujJgAUUQECpg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 10/26/06 10:43 AM, "Randell Jesup" wrote: >=20 > What I don't see is how this will do that, and what it will do that eithe= r > existing mechanisms (or new mechanisms at the same level) can't do. I understand all your comments and, in general, agree with them. Nothing being done by 802.1 is really new, it's just adaptations of technology that has been around since I worked on early packet-based telephone/audio/telemetry systems in the early 80's ... All that is being done is to move some timing and QoS services closer to th= e network layer so that they can be easily built into the hardware for Ethernet/WiFi NICs and switches. The result is lower latency and (probably) lower cost. It has the side benefit of running non-IP protocols that are currently dependent on specialized non-802 networks (such as IEEE 1394 for consumer electronics and pro audio, and SONET/TDM networks in telecom). Since things *should* be moving more and more towards IP nets, it's nice to provide the kind of performance (latency, synchronization, guaranteed BW) that some old nets provide, even with IP. --=20 --------------------------------------------------------------- Michael D. Johas Teener =8B mikejt@broadcom.com office +1-408-922-7542 cell +1-831-247-9666 fax +1-831-480-5845 http://xri.net/=3DMichael.Johas.Teener - PGP ID 0x3179D202 --------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 26 20:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdG3f-0004qE-07; Thu, 26 Oct 2006 20:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdG3d-0004q0-7h for avt@ietf.org; Thu, 26 Oct 2006 20:58:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCJe-0002wX-Ax for avt@ietf.org; Thu, 26 Oct 2006 16:59:06 -0400 Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdC9w-0000rd-Gz for avt@ietf.org; Thu, 26 Oct 2006 16:49:08 -0400 Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 26 Oct 2006 16:48:01 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id MKR80565; Thu, 26 Oct 2006 16:47:58 -0400 (EDT) Received: from 162-144-2.cortland.com.144.162.209.in-addr.arpa (HELO erols.com) ([209.162.144.2]) by smtp01.lnh.mail.rcn.net with ESMTP; 26 Oct 2006 16:47:54 -0400 X-IronPort-AV: i="4.09,362,1157342400"; d="scan'208"; a="300885238:sNHT58819552" Message-ID: <45411EEA.D1AD3F7D@erols.com> Date: Thu, 26 Oct 2006 13:47:38 -0700 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: lazzaro References: <44D24864-E659-457E-B035-46E60A170103@eecs.berkeley.edu> <4540FE74.73613EB3@erols.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.45411EC5.0102,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.113/2006-07-26 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: avt@ietf.org Subject: [AVT] Re: Layer 2 clock sync [was: AVT draft agenda] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org John, I'm all in favor of low latency, and I enjoy rising to that challenge. However the layer-2 timestamping you seemed to suggest in > [...] a Layer 2 stack on the microphone that recognized > it was sending RTCP packets and rewrote the NTP field on > the way to the antenna [...] is ill-conceived for this task as far as I can tell. It does nothing about latency itself, and while it might improve the accuracy of RTP transit jitter measurements it seems it would actually *decrease* the accuracy of the sample-clock correlation. It appears to be another case of letting RTP's packet-jitter- measurement function trump the precise-media-clock function. I don't think we want to go there. Incidentally, getting syntonic sample clocks (i.e. equal frequency, no phase drift) for multiple audio sources has long been recognized in pro audio as a *latency* benefit because it avoids the need to resample the signal. Low- distortion audio resampling requires a long accurate sinc filter kernel and therefore introduces a dozen or so samples worth of delay. That's one reason for the mechanism designed into AES42 mics. And to anyone writing a decent musical audio application...don't even *think* about handling sample clock drift by dropping or dup'ing samples. Leave that stuff to VOIP and conferencing- grade apps. Peace, Chuck lazzaro wrote: > > On Oct 26, 2006, at 11:29 AM, Chuck Harrison wrote: > > > The delays between sampling and packet transmission > > (whether they arise in the OS, the hardware, or whatever) are > > simply part of the transmission jitter/delay budget and are > > irrelevant to the precision of the end-to-end system. Especially > > so in recording-system or one-way scenarios where latency bounds > > can be extremely relaxed. > > Performers on stage are typically using monitoring systems (in-ear, > or speakers in front of them on the floor or a stand). So, the latency > from the wireless mic, through the mixing console, and back up > to the stage is critical, and can't be relaxed -- 2 ms would make > many but not all performers happy (vocalists in particular are > very sensitive to this -- especially using in-ear). > > Likewise, using these networks as the first-hop for long-distance > network musical performance systems are also an application > where every millisecond counts. > > So, I'm wary of declaring this effort to be latency relaxed ... for > some applications it isn't. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From vetk@americagrinding-sales.com Thu Oct 26 22:00:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdH1i-0005MB-8P for avt-archive@lists.ietf.org; Thu, 26 Oct 2006 22:00:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd3G1-00010g-Ci for avt-archive@lists.ietf.org; Thu, 26 Oct 2006 07:18:45 -0400 Received: from p213.54.183.112.tisdip.tiscali.de ([213.54.183.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gd32Z-0000r9-HA for avt-archive@lists.ietf.org; Thu, 26 Oct 2006 07:04:54 -0400 Received: from 216.219.254.203 (HELO mailhost.americagrinding-sales.com) by lists.ietf.org with esmtp (L5EOFHYHT V0UAR) id R64XAN-L076QI-96 for avt-archive@lists.ietf.org; Thu, 26 Oct 2006 11:04:57 -0060 From: "Stanley Sutton" To: Subject: Bush said. (Watch the president explain) Date: Thu, 26 Oct 2006 11:04:57 -0060 Message-ID: <01c6f8ee$92f5b940$6c822ecf@vetk> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: Aca6QGY7N4PH0PC8T0Z9HH3E8AP46S== X-Spam-Score: 4.6 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab We are living in a time of resource, and those with the natural resources are those with the power and money. belongings, oil, gold; all at record highs. It's where you want to be. Our next feature has achieve that position, and is now starting heavy mass publicity to let anyone know it. This c0mpany is none other than AUNI. AUNI is specialized in resource ventures. An incredible breakthrough is coming out of the company and will be backed up with a smashing publicity blitz. --- AUNI . OB Cap: 92.85M --- After a small pullback on Wednesday, we are certain to see a rise of over 300% over the next week. There is no reason you should reject yourself to benefit from a big break. Don't let this one pass over. From avt-bounces@ietf.org Fri Oct 27 04:22:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdMxF-00028h-Df; Fri, 27 Oct 2006 04:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdMxD-00028c-RX for avt@ietf.org; Fri, 27 Oct 2006 04:20:39 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdMx4-0007kU-0A for avt@ietf.org; Fri, 27 Oct 2006 04:20:39 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DCC734F009D; Fri, 27 Oct 2006 10:19:08 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 10:19:08 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 10:19:08 +0200 Message-ID: <4541C0FC.3080208@ericsson.com> Date: Fri, 27 Oct 2006 10:19:08 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Baugher Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt References: <85384093-2F6C-4792-9619-CDC8734F7EA0@cisco.com> <453E119C.2030907@ericsson.com> <0987A300-0826-47BF-A5DA-EC06F088B989@cisco.com> In-Reply-To: <0987A300-0826-47BF-A5DA-EC06F088B989@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 08:19:08.0302 (UTC) FILETIME=[9300BAE0:01C6F9A0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Stephan Wenger , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Mark Baugher skrev: > On Oct 24, 2006, at 6:14 AM, Magnus Westerlund wrote: >> Mark Baugher skrev: >>> Magnus, Stephan, >>> I gave this a first read and it's well-written and to the point >>> IMHO. I have a couple of comments off the top of my head. Starting >>> with Security Considerations, Second, the number of security >>> contexts needed (for example in >>> SRTP [RFC3711]) may vary between mixers and translators. A mixer >>> normally needs to represent only a single SSRC in any given >>> domain, and therefore needs to create only one SRTP security >>> context. In contrast, a translator needs one context per >>> participant it translates toward in the opposite domain. >>> Couldn't Figure 6 have five crypto contexts installed in the mixer? >>> I think you're saying that everyone but the mixer receives using the >>> same crypto context. The mixer additionally needs to receive the >>> others' streams and each will have a crypto context. >> >> In the case depicted by figure 6, the mixer will have one SSRC and the >> A-D will have at least one respectively. However if we are looking at >> the link between A and the mixer, the traffic passing on this link >> there will be only two SSRCs, A's and the Mixer's. The SSRCs belonging >> to B, C and D will only occur in CSRC list and inside RTCP SDES >> packets. Thus from an SRTP perspective, A only needs two crypto >> contextes, one for its own traffic and one for the mixer. The same is >> true for each of the other participants that only receive a mixed view >> of the session. That is why I am saying that the mixer will have one >> SSRC (at least). > > I misread the text cited above, "A mixer normally needs to represent > only a single SSRC per domain and therefore needs to create only one > SRTP security context". I think we could put it this way, "A mixer > normally needs to represent only a single SSRC per domain and therefore > needs to create only one SRTP crypto context per domain" where I added > 'per domain' and changed 'security' to 'crypto'. Your sentence seems like a improvement. However maybe I should clarify what I was considering was the implication on the number of session keys and their related parameters. If I understand crypto context in SRTP it normally means the master key and its parameters. Thus the number of crypto contexts will depend on the keying model, a shared master key or one master key per SSRC. But it might be easiest to not dig to deep into this within the document. SRTP is a recommended security mechanism but not the only one that may be used. >> >> In regards to using the same crypto context for all the others, I >> don't think that is the truth. To avoid the two time padd issue, the >> mixer needs to use either different keys or different SSRC in the >> domains when using SRTP. The reason is that a mixer most likely will >> need to produce different media streams and mixes. Sending the >> transmitting entity a stream with themselves seems wrong in most >> applications. Thus senders and only receivers will at least have >> different streams. That is before even considering the need to adapt >> the media to the individual links. >> >> I think I missed the word "additional" in the following sentence: >> "... and therefore needs to create only one SRTP security context." >> >> Where a mixer will need N crypto contexts in addition for N domains, a >> translator may be forced to have P*N crypto contexts where P is the >> number of participants in total. > > Ok. It seems clearer to write "may be forced to have" as "might need up to" Okay, we will consider this. >> >>> There is a lot that needs to be defined that probably is outside of >>> the scope of your document, but the security considerations section >>> also says: >>> Including the mixer and translator in the security context allows >>> the entity if subverted or misbehaving to perform a number of >>> very >>> serious attacks as it has full access. It can perform all the >>> attacks possible, see RFC 3550 and any applicable profiles, as if >>> the media session was not protected at all, while giving the >>> impression to the session participants that they are protected >>> against them. >>> "Security context" is vague but I think what you're saying here is >>> that giving a device access to security keys adds a new risk, another >>> potential point of vulnerability, to the session. _How_ the mixer >>> and translator are included in the security context can greatly >>> affect the risk. In other words, we know in security how to >>> establish pairwise keys for a pair of endpoints, and we know how to >>> do group keys for multiple endpoints, but I don't think there is a >>> consensus for how to do key management for some of the figures in >>> your document. >> >> No, that is true. The security risks will depend on how you key. The >> main point is that a mixer or a translator may actually need to u > > I miss your point here, but I agree that the "security risks will depend > on how you key", and I would add that there is no consensus on how to > key some of the figures. That's out-of-scope for this I-D but needs to > be done and probably should be mentioned. I agree with your statement that we don't necessarily know how to key all these. However adding a statement that the security properties will depend on the keying I think is safe. I wouldn't say that there is no consensus on how to key, but stating that it might be done in different ways and thus getting different properties would be safe. I think we need to separate the issues between having an IETF agreed way of doing things and if any solution exist at all. RTP can be secured in a number of ways and the application will be highly influencing your choices both for the transport protection and how you do your keying. > >> >>> I had one more question come to mind when reading Section 3.5. >>> Following Figure 5 it says: >>> In the multicast domain, the mixer does not need to provide a >>> mixed view of the other domains and will commonly only forward >>> the >>> media from B and D into the multicast network using B's and D's >>> SSRC. >>> I expect that mixing would be useful for a multicast network to give >>> every participant the same output from the conference. Are you >>> assuming otherwise? >> >> In this case you have deployed a mixer simply because B and D can't >> have the same view as A and C that are part of the multicast domain. >> There is no reason for the mixer to return a mixed stream to the >> multicast domain that contains all the participants, because any >> sender in the multicast domain has already received that traffic. In >> the same way it is unnecessary for the mixer to even mix B and D >> together unless there is a bandwidth issue, because the participants >> in the multicast part already are capable of handling the reception of >> multiple sources. > > I recall that there were advantages to doing centralized mixing and then > distribute the mixed stream over a multicast channel instead of every > receiver doing its own mixing. The advantage is that the device imposes > an ordering so the receivers all hear the same thing at about the same > time. Not the case? >> I would say that this is highly application dependent and why you deploy the mixer. I think the usage of centralized mixing has its usage for certain applications, in other the mixer is not at all centralized and is instead something that enables a few users to participate in a session they otherwise couldn't, i.e. more gateway then a conference focus. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 07:48:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdQAT-0001Nl-3F; Fri, 27 Oct 2006 07:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdQAR-0001NV-JJ for avt@ietf.org; Fri, 27 Oct 2006 07:46:31 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdQAM-00085t-HL for avt@ietf.org; Fri, 27 Oct 2006 07:46:31 -0400 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1GdQAL-00037i-3e; Fri, 27 Oct 2006 07:46:25 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <4541F190.5040409@sipstation.com> Date: Fri, 27 Oct 2006 06:46:24 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <453F96FC.6010006@sipstation.com> <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> In-Reply-To: <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin, Thanks for your comments on the draft. On SSRCs, the case where ZRTP can use a separate SSRC is precisely the case where RTP packets are coming from another source - remember this is the loosely coupled case where the ZRTP endpoint may be an in-line media-only device. For such a device to generate RTP packets and reuse another endpoint's SSRC would seem to be the real violation and cause significant problems. In general, we feel that ZRTP should be integrated with the media stack and hence should use the same SSRC. We will make this clearer in the next version of the draft. On the use of RTCP, this is a possibility in the future. Since the ZRTP protocol is designed to be deployable in the real world, a requirement is that it not require additional NAT bindings - this is a major obstacle today to the deployment of RTCP. Another requirement of ZRTP is that it not be dependent on the signaling channel. It can use the signaling channel as an additional out-of-band discovery and authentication channel, but it can not have any dependency. So, if your draft defining the multiplexing of RTCP on RTP ports is adopted as a Working Group item, and there are no additional requirements for signaling, then ZRTP should be able to make use of RTCP transport. We will investigate this in the next version of the draft as this topic develops. And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on 6/23/06 you emailed to the list that it does not affect ZRTP's use of header extensions. Thanks, Alan Colin Perkins wrote: > > [This is being sent to avt@ietf.org with a bcc to rtpsec; response to > avt please since that is the group responsible for RTP] > > > I have reviewed draft-zimmerman-avt-zrtp-02.txt and have some serious > concerns regarding the way ZRTP integrates with the RTP architecture. > In particular, I believe this draft misuses both the RTP > synchronisation source (SSRC) and the RTP header extension mechanism. > > > 1) Misuse of the RTP synchronisation source (SSRC): the latest draft > states (section 5) that ZRTP endpoints "MAY use a different SSRC for > ZRTP messages than for RTP media" since this allows "for very loose > coupling between the ZRTP application and the RTP media application". > This violates RFC 3550 in several fundamental ways: > > a) RFC 3550 specifies that the SSRC identifies the "source of a stream > of RTP packet" and requires receivers to group packets according to > SSRC for playout and other processing. Using a separate SSRC for ZRTP > and RTP data belonging to a single flow breaks playout buffer > operation, and requires receivers to ignore the RFC 3550 rules on > source identification. > > b) If a different SSRC is used for ZRTP packets than for RTP packets, > it is not possible to differentiate packets from different > participants, unless unicast sessions with only two parties are > assumed. This breaks multicast and multiparty RTP, as well as mixers > and translators operating according under RFC 3550. > > c) Use of a different SSRC for ZRTP and RTP packets can disrupt the > correct operation of the RTP collision and loop detection algorithm. > > In addition, use of a different SSRC for ZRTP and RTP packets will > disrupt RTP header compression efficiency. > > > 2) Misuse of the RTP header extension: the RTP architecture provides > for a clean separation between media data and media path control data, > providing a control channel in the form of RTCP associated with every > data flow. ZRTP ignores this control channel, and instead mixes > control and data traffic in an RTP header extension. This is a gross > and needless violation of the architecture, which significantly > complicates the resulting system. It also has several practical problems: > > a) The header extension will significantly expand the size of ZRTP > packets, likely leading to them being discarded when traversing > optimized paths (for example, various wireless links). > > b) ZRTP cannot be used in conjunction with the general mechanism for > RTP header extensions defined in draft-ietf-avt-rtp-hdrext-06.txt. > > > None of these problems need exist. ZRTP can be trivially reworked to > use a new RTCP packet type, potentially multiplexed onto the same port > as the data, with the same SSRC as the stream it is protecting. This > would have the same security properties as the current draft, but > would conform to the RTP architecture and avoid the breakage listed > above, would work in a wider range of environments, and would > encourage the take-up of RTCP (which is already needed to support a > range of features of RTP such as lip-synchronisation, codec control, > etc.). > > We have an architecture which cleanly supports all the features that > ZRTP needs. Please use it, rather than trying to perpetuate the > (broken) PSTN secure phone model. > > Colin > > > > > On 25 Oct 2006, at 17:55, Alan Johnston wrote: >> All, >> >> The ZRTP I-D has been updated. There are lots of changes in the >> document including: >> >> >> - Discussion of how ZRTP compares using the criteria in >> draft-wing-rtpsec-keying-eval-01.txt >> >> - Discovery and authentication of ZRTP through the signaling channel >> and the definitions and ABNF of three SDP attributes a=zrtp, >> a=zrtp-sas, a=zrtp-sasvalue. >> >> - New Multistream key agreement mode allowing SRTP keys for multiple >> media streams in a session to be derived from a single ZRTP DH >> exchange. >> >> - CRC protection of ZRTP messages against transport errors using a 32 >> bit CRC algorithm >> >> - Use of RTP no-op packets instead of comfort noise packets >> >> - Simplified shared secret comparison algorithm >> >> - New Stay secure and Disclosure flags >> >> - More details on caching of retained shared secrets including >> expiration intervals >> >> - Removal of Error message - Reason field added to GoClear >> >> - Discussion of the behavior of intermediary devices that might >> implement ZRTP >> >> >> We will be discussing the changes in the ZRTP protocol in the AVT >> working group and the SDP attributes in MMUSIC. >> >> As always, comments and feedback are most welcome. >> >> Thanks, >> Alan >> >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt >> Date: Tue, 24 Oct 2006 15:50:02 -0400 >> 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 : ZRTP: Extensions to RTP for Diffie-Hellman Key >> Agreement for SRTP >> Author(s) : P. Zimmermann, et al. >> Filename : draft-zimmermann-avt-zrtp-02.txt >> Pages : 52 >> Date : 2006-10-24 >> >> This document defines ZRTP, RTP (Real-time Transport Protocol) header >> extensions for a Diffie-Hellman exchange to agree on a session key >> and parameters for establishing Secure RTP (SRTP) sessions. The ZRTP >> protocol is completely self-contained in RTP and does not require >> support in the signaling protocol or assume a Public Key >> Infrastructure (PKI) infrastructure. For the media session, ZRTP >> provides confidentiality, protection against Man in the Middle (MitM) >> attacks, and, in cases where a secret is available from the signaling >> protocol, authentication. ZRTP can utilize three Session Description >> Protocol (SDP) attributes to provide discovery and authentication >> through the signaling channel. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of the message. You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >> subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then "get >> draft-zimmermann-avt-zrtp-02.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 08:54:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRDU-0000cR-Sl; Fri, 27 Oct 2006 08:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRDT-0000cJ-Gg for avt@ietf.org; Fri, 27 Oct 2006 08:53:43 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdRDR-0007Fm-24 for avt@ietf.org; Fri, 27 Oct 2006 08:53:43 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:63283) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1GdRDQ-0000EI-Ii; Fri, 27 Oct 2006 13:53:40 +0100 In-Reply-To: <4541F190.5040409@sipstation.com> References: <453F96FC.6010006@sipstation.com> <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> <4541F190.5040409@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Fri, 27 Oct 2006 13:53:37 +0100 To: Alan Johnston X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Alan, On 27 Oct 2006, at 12:46, Alan Johnston wrote: > Thanks for your comments on the draft. > > On SSRCs, the case where ZRTP can use a separate SSRC is precisely > the case where RTP packets are coming from another source - > remember this is the loosely coupled case where the ZRTP endpoint > may be an in-line media-only device. For such a device to generate > RTP packets and reuse another endpoint's SSRC would seem to be the > real violation and cause significant problems. Sure. However using a separate SSRC also causes problems. I don't think you can de-couple the ZRTP processing to the degree you suggest. > In general, we feel that ZRTP should be integrated with the media > stack and hence should use the same SSRC. We will make this > clearer in the next version of the draft. I would go further: it MUST use the SSRC of the media stream it is protecting, otherwise things break. > On the use of RTCP, this is a possibility in the future. Since the > ZRTP protocol is designed to be deployable in the real world, a > requirement is that it not require additional NAT bindings - this > is a major obstacle today to the deployment of RTCP. I'm not sure I believe that argument. The complexity comes from implementing ICE to open any ports. Once you have an ICE implementation, running it again to open an RTCP port is not an issue. Also, as I described, there are deployment issues with ZRTP as currently specified. > Another requirement of ZRTP is that it not be dependent on the > signaling channel. That's not possible: RTP requires there be an out-of-band signalling channel to negotiate payload formats, etc. I assume you mean there is a requirement that the security is not dependent on the signalling, but that is independent of the use of RTCP to convey ZRTP messages. > It can use the signaling channel as an additional out-of-band > discovery and authentication channel, but it can not have any > dependency. So, if your draft defining the multiplexing of RTCP on > RTP ports is adopted as a Working Group item, and there are no > additional requirements for signaling, then ZRTP should be able to > make use of RTCP transport. We will investigate this in the next > version of the draft as this topic develops. My draft has already been adopted as an AVT work item. It does require some signalling support, using the a=rtcp: attribute, but that attribute is also required for ICE to work. [Note, also, that sending ZRTP-in-RTCP on the RTP port without signalling is vastly preferable to using an RTP header extension to send ZRTP messages, since it keeps control information out of the data packets]. > And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on 6/23/06 > you emailed to the list that it does not affect ZRTP's use of > header extensions. The issue is that only one header extension can be present in RTP packets. If you use ZRTP, you cannot use hdrext, and vice-versa. Using RTCP to convey the ZRTP messages would remove that constraint. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 08:59:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRIF-0000ZA-NA; Fri, 27 Oct 2006 08:58:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRIF-0000YB-4M for avt@ietf.org; Fri, 27 Oct 2006 08:58:39 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdRID-0007yt-Qe for avt@ietf.org; Fri, 27 Oct 2006 08:58:39 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:63324) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1GdRID-0000aI-Ei for avt@ietf.org; Fri, 27 Oct 2006 13:58:37 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <490CA54E-D617-4779-9BB9-8A71816E7AB0@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-01.txt Date: Fri, 27 Oct 2006 13:58:33 +0100 To: IETF AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 26 Oct 2006, at 20:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Working > Group of the IETF. > > Title : Multiplexing RTP Data and Control Packets on a Single Port > Author(s) : C. Perkins, M. Westerlund > Filename : draft-ietf-avt-rtp-and-rtcp-mux-01.txt > Pages : 13 > Date : 2006-10-26 > > This memo discusses issues that arise when multiplexing RTP data > packets and RTP control protocol (RTCP) packets on a single UDP > port. > It updates RFC 3550 to describe when such multiplexing is, and is > not, appropriate, and explains how the Session Description Protocol > (SDP) can be used to signal multiplexed sessions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-and-rtcp- > mux-01.txt Changes in this version include: - Clarify expected behaviour of implementations that understand a=rtcp:, but don't support this memo - Expand discussion of interactions with ICE - Expand discussion of SIP forking. - Clarify failure behaviour during offer/answer negotiation - Add "Interactions with Header Compression" section. - Split Section 5.1 into multiple sub-sections Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 09:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRsB-000148-Ug; Fri, 27 Oct 2006 09:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRsA-00013t-9T for avt@ietf.org; Fri, 27 Oct 2006 09:35:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdRs7-0004Jg-Iu for avt@ietf.org; Fri, 27 Oct 2006 09:35:46 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 06:35:43 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RDZhPX016711; Fri, 27 Oct 2006 06:35:43 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9RDZhW4015401; Fri, 27 Oct 2006 06:35:43 -0700 (PDT) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RDN9Sw011833; Fri, 27 Oct 2006 06:23:09 -0700 In-Reply-To: <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> References: <453F96FC.6010006@sipstation.com> <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <226D6DDE-D591-416F-8020-BF10A6536191@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Fri, 27 Oct 2006 09:35:25 -0400 To: Colin Perkins X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-3.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=8490; t=1161956143; x=1162820143; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[AVT]=20[Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-02.tx t]; X=v=3Dcisco.com=3B=20h=3DVo+OzlcFA1/SUm1JyTNM+SnaVj4=3D; b=IJzWkeExda/Z/goIWc6V8MNgkq70JUE37Tc/ElifViH9Gv6E2Srl4BTKwqQhEhDwKWPl0Fxs 9MshZKT/1c3I3NWoLdZu8z908XOVbZ2yzLR3wp3jHjvExMdZXGvM8TRe; X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I find myself in complete agreement with Colin's points, especially the point about using RTCP as the control channel for zrtp control messages. Dave Oran. On Oct 26, 2006, at 11:21 AM, Colin Perkins wrote: > [This is being sent to avt@ietf.org with a bcc to rtpsec; response > to avt please since that is the group responsible for RTP] > > > I have reviewed draft-zimmerman-avt-zrtp-02.txt and have some > serious concerns regarding the way ZRTP integrates with the RTP > architecture. In particular, I believe this draft misuses both the > RTP synchronisation source (SSRC) and the RTP header extension > mechanism. > > > 1) Misuse of the RTP synchronisation source (SSRC): the latest > draft states (section 5) that ZRTP endpoints "MAY use a different > SSRC for ZRTP messages than for RTP media" since this allows "for > very loose coupling between the ZRTP application and the RTP media > application". This violates RFC 3550 in several fundamental ways: > > a) RFC 3550 specifies that the SSRC identifies the "source of a > stream of RTP packet" and requires receivers to group packets > according to SSRC for playout and other processing. Using a > separate SSRC for ZRTP and RTP data belonging to a single flow > breaks playout buffer operation, and requires receivers to ignore > the RFC 3550 rules on source identification. > > b) If a different SSRC is used for ZRTP packets than for RTP > packets, it is not possible to differentiate packets from different > participants, unless unicast sessions with only two parties are > assumed. This breaks multicast and multiparty RTP, as well as > mixers and translators operating according under RFC 3550. > > c) Use of a different SSRC for ZRTP and RTP packets can disrupt the > correct operation of the RTP collision and loop detection algorithm. > > In addition, use of a different SSRC for ZRTP and RTP packets will > disrupt RTP header compression efficiency. > > > 2) Misuse of the RTP header extension: the RTP architecture > provides for a clean separation between media data and media path > control data, providing a control channel in the form of RTCP > associated with every data flow. ZRTP ignores this control channel, > and instead mixes control and data traffic in an RTP header > extension. This is a gross and needless violation of the > architecture, which significantly complicates the resulting system. > It also has several practical problems: > > a) The header extension will significantly expand the size of ZRTP > packets, likely leading to them being discarded when traversing > optimized paths (for example, various wireless links). > > b) ZRTP cannot be used in conjunction with the general mechanism > for RTP header extensions defined in draft-ietf-avt-rtp-hdrext-06.txt. > > > None of these problems need exist. ZRTP can be trivially reworked > to use a new RTCP packet type, potentially multiplexed onto the > same port as the data, with the same SSRC as the stream it is > protecting. This would have the same security properties as the > current draft, but would conform to the RTP architecture and avoid > the breakage listed above, would work in a wider range of > environments, and would encourage the take-up of RTCP (which is > already needed to support a range of features of RTP such as lip- > synchronisation, codec control, etc.). > > We have an architecture which cleanly supports all the features > that ZRTP needs. Please use it, rather than trying to perpetuate > the (broken) PSTN secure phone model. > > Colin > > > > > On 25 Oct 2006, at 17:55, Alan Johnston wrote: >> All, >> >> The ZRTP I-D has been updated. There are lots of changes in the >> document including: >> >> >> - Discussion of how ZRTP compares using the criteria in draft-wing- >> rtpsec-keying-eval-01.txt >> >> - Discovery and authentication of ZRTP through the signaling >> channel and the definitions and ABNF of three SDP attributes >> a=zrtp, a=zrtp-sas, a=zrtp-sasvalue. >> >> - New Multistream key agreement mode allowing SRTP keys for >> multiple media streams in a session to be derived from a single >> ZRTP DH exchange. >> >> - CRC protection of ZRTP messages against transport errors using a >> 32 bit CRC algorithm >> >> - Use of RTP no-op packets instead of comfort noise packets >> >> - Simplified shared secret comparison algorithm >> >> - New Stay secure and Disclosure flags >> >> - More details on caching of retained shared secrets including >> expiration intervals >> >> - Removal of Error message - Reason field added to GoClear >> >> - Discussion of the behavior of intermediary devices that might >> implement ZRTP >> >> >> We will be discussing the changes in the ZRTP protocol in the AVT >> working group and the SDP attributes in MMUSIC. >> >> As always, comments and feedback are most welcome. >> >> Thanks, >> Alan >> >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt >> Date: Tue, 24 Oct 2006 15:50:02 -0400 >> 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 : ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement >> for SRTP >> Author(s) : P. Zimmermann, et al. >> Filename : draft-zimmermann-avt-zrtp-02.txt >> Pages : 52 >> Date : 2006-10-24 >> >> This document defines ZRTP, RTP (Real-time Transport Protocol) header >> extensions for a Diffie-Hellman exchange to agree on a session key >> and parameters for establishing Secure RTP (SRTP) sessions. The >> ZRTP >> protocol is completely self-contained in RTP and does not require >> support in the signaling protocol or assume a Public Key >> Infrastructure (PKI) infrastructure. For the media session, ZRTP >> provides confidentiality, protection against Man in the Middle >> (MitM) >> attacks, and, in cases where a secret is available from the >> signaling >> protocol, authentication. ZRTP can utilize three Session >> Description >> Protocol (SDP) attributes to provide discovery and authentication >> through the signaling channel. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt >> >> To remove yourself from the I-D Announcement list, send a message >> to i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. You can also visit https://www1.ietf.org/ >> mailman/listinfo/I-D-announce to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with >> the username "anonymous" and a password of your e-mail address. >> After logging in, type "cd internet-drafts" and then "get draft- >> zimmermann-avt-zrtp-02.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- >> sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 09:41:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRxM-0006YK-Rm; Fri, 27 Oct 2006 09:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRxL-0006YE-8b for avt@ietf.org; Fri, 27 Oct 2006 09:41:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdRxI-0004tA-HO for avt@ietf.org; Fri, 27 Oct 2006 09:41:07 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 06:41:03 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RDf3Gf030794; Fri, 27 Oct 2006 06:41:03 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9RDf3W4018320; Fri, 27 Oct 2006 06:41:03 -0700 (PDT) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RDST4P011954; Fri, 27 Oct 2006 06:28:30 -0700 In-Reply-To: <4541F190.5040409@sipstation.com> References: <453F96FC.6010006@sipstation.com> <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> <4541F190.5040409@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <474B8DFB-EAE9-4F12-AA2B-5B3447CF30C0@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Fri, 27 Oct 2006 09:40:54 -0400 To: Alan Johnston X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-2.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=10920; t=1161956463; x=1162820463; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[AVT]=20[Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-02.tx t]; X=v=3Dcisco.com=3B=20h=3DVo+OzlcFA1/SUm1JyTNM+SnaVj4=3D; b=KzaoOShBrj2YHuunUB9juUQM3MsItfLt+CEB4mC9L1bbw9TE3UuBvSoVZqlJAv+3lARsoLSh CqD1lUbLHF4udD74HN8f1Elm4E0rWvg2l/OdyLeKjqUJ6gVMS85SuC1E; X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: Colin Perkins , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 27, 2006, at 7:46 AM, Alan Johnston wrote: > Colin, > > Thanks for your comments on the draft. > > On SSRCs, the case where ZRTP can use a separate SSRC is precisely > the case where RTP packets are coming from another source - > remember this is the loosely coupled case where the ZRTP endpoint > may be an in-line media-only device. For such a device to generate > RTP packets and reuse another endpoint's SSRC would seem to be the > real violation and cause significant problems. In general, we feel > that ZRTP should be integrated with the media stack and hence > should use the same SSRC. We will make this clearer in the next > version of the draft. > If the zrtp device is deployed inline with this kind of approach, then it is an RTP mixer/translator and what should be coming out are packets with the zrtp SSRC on all packets, and the original RTP packets identified with a CSRC. Is that really what you want to do though? > On the use of RTCP, this is a possibility in the future. Since the > ZRTP protocol is designed to be deployable in the real world, a > requirement is that it not require additional NAT bindings - this > is a major obstacle today to the deployment of RTCP. Then do rtp/rtcp port multiplexing. > Another requirement of ZRTP is that it not be dependent on the > signaling channel. It can use the signaling channel as an > additional out-of-band discovery and authentication channel, but it > can not have any dependency. So, if your draft defining the > multiplexing of RTCP on RTP ports is adopted as a Working Group > item, and there are no additional requirements for signaling, then > ZRTP should be able to make use of RTCP transport. We will > investigate this in the next version of the draft as this topic > develops. > I would prefer if you specified it NOW as RTCP as the control channel. For devices that do RTCP correctly, it will work now, and for those behind nats and don't understand how to open two ports through the nat, you can exploit port multiplexing. > And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on 6/23/06 > you emailed to the list that it does not affect ZRTP's use of > header extensions. > > Thanks, > Alan > > Colin Perkins wrote: >> >> [This is being sent to avt@ietf.org with a bcc to rtpsec; response >> to avt please since that is the group responsible for RTP] >> >> >> I have reviewed draft-zimmerman-avt-zrtp-02.txt and have some >> serious concerns regarding the way ZRTP integrates with the RTP >> architecture. In particular, I believe this draft misuses both the >> RTP synchronisation source (SSRC) and the RTP header extension >> mechanism. >> >> >> 1) Misuse of the RTP synchronisation source (SSRC): the latest >> draft states (section 5) that ZRTP endpoints "MAY use a different >> SSRC for ZRTP messages than for RTP media" since this allows "for >> very loose coupling between the ZRTP application and the RTP media >> application". This violates RFC 3550 in several fundamental ways: >> >> a) RFC 3550 specifies that the SSRC identifies the "source of a >> stream of RTP packet" and requires receivers to group packets >> according to SSRC for playout and other processing. Using a >> separate SSRC for ZRTP and RTP data belonging to a single flow >> breaks playout buffer operation, and requires receivers to ignore >> the RFC 3550 rules on source identification. >> >> b) If a different SSRC is used for ZRTP packets than for RTP >> packets, it is not possible to differentiate packets from >> different participants, unless unicast sessions with only two >> parties are assumed. This breaks multicast and multiparty RTP, as >> well as mixers and translators operating according under RFC 3550. >> >> c) Use of a different SSRC for ZRTP and RTP packets can disrupt >> the correct operation of the RTP collision and loop detection >> algorithm. >> >> In addition, use of a different SSRC for ZRTP and RTP packets will >> disrupt RTP header compression efficiency. >> >> >> 2) Misuse of the RTP header extension: the RTP architecture >> provides for a clean separation between media data and media path >> control data, providing a control channel in the form of RTCP >> associated with every data flow. ZRTP ignores this control >> channel, and instead mixes control and data traffic in an RTP >> header extension. This is a gross and needless violation of the >> architecture, which significantly complicates the resulting >> system. It also has several practical problems: >> >> a) The header extension will significantly expand the size of ZRTP >> packets, likely leading to them being discarded when traversing >> optimized paths (for example, various wireless links). >> >> b) ZRTP cannot be used in conjunction with the general mechanism >> for RTP header extensions defined in draft-ietf-avt-rtp- >> hdrext-06.txt. >> >> >> None of these problems need exist. ZRTP can be trivially reworked >> to use a new RTCP packet type, potentially multiplexed onto the >> same port as the data, with the same SSRC as the stream it is >> protecting. This would have the same security properties as the >> current draft, but would conform to the RTP architecture and avoid >> the breakage listed above, would work in a wider range of >> environments, and would encourage the take-up of RTCP (which is >> already needed to support a range of features of RTP such as lip- >> synchronisation, codec control, etc.). >> >> We have an architecture which cleanly supports all the features >> that ZRTP needs. Please use it, rather than trying to perpetuate >> the (broken) PSTN secure phone model. >> >> Colin >> >> >> >> >> On 25 Oct 2006, at 17:55, Alan Johnston wrote: >>> All, >>> >>> The ZRTP I-D has been updated. There are lots of changes in the >>> document including: >>> >>> >>> - Discussion of how ZRTP compares using the criteria in draft- >>> wing-rtpsec-keying-eval-01.txt >>> >>> - Discovery and authentication of ZRTP through the signaling >>> channel and the definitions and ABNF of three SDP attributes >>> a=zrtp, a=zrtp-sas, a=zrtp-sasvalue. >>> >>> - New Multistream key agreement mode allowing SRTP keys for >>> multiple media streams in a session to be derived from a single >>> ZRTP DH exchange. >>> >>> - CRC protection of ZRTP messages against transport errors using >>> a 32 bit CRC algorithm >>> >>> - Use of RTP no-op packets instead of comfort noise packets >>> >>> - Simplified shared secret comparison algorithm >>> >>> - New Stay secure and Disclosure flags >>> >>> - More details on caching of retained shared secrets including >>> expiration intervals >>> >>> - Removal of Error message - Reason field added to GoClear >>> >>> - Discussion of the behavior of intermediary devices that might >>> implement ZRTP >>> >>> >>> We will be discussing the changes in the ZRTP protocol in the AVT >>> working group and the SDP attributes in MMUSIC. >>> >>> As always, comments and feedback are most welcome. >>> >>> Thanks, >>> Alan >>> >>> >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt >>> Date: Tue, 24 Oct 2006 15:50:02 -0400 >>> 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 : ZRTP: Extensions to RTP for Diffie-Hellman Key >>> Agreement for SRTP >>> Author(s) : P. Zimmermann, et al. >>> Filename : draft-zimmermann-avt-zrtp-02.txt >>> Pages : 52 >>> Date : 2006-10-24 >>> This document defines ZRTP, RTP (Real-time Transport >>> Protocol) header >>> extensions for a Diffie-Hellman exchange to agree on a session key >>> and parameters for establishing Secure RTP (SRTP) sessions. >>> The ZRTP >>> protocol is completely self-contained in RTP and does not require >>> support in the signaling protocol or assume a Public Key >>> Infrastructure (PKI) infrastructure. For the media session, ZRTP >>> provides confidentiality, protection against Man in the Middle >>> (MitM) >>> attacks, and, in cases where a secret is available from the >>> signaling >>> protocol, authentication. ZRTP can utilize three Session >>> Description >>> Protocol (SDP) attributes to provide discovery and authentication >>> through the signaling channel. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt >>> >>> To remove yourself from the I-D Announcement list, send a message >>> to i-d-announce-request@ietf.org with the word unsubscribe in the >>> body of the message. You can also visit https://www1.ietf.org/ >>> mailman/listinfo/I-D-announce to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with >>> the username "anonymous" and a password of your e-mail address. >>> After logging in, type "cd internet-drafts" and then "get draft- >>> zimmermann-avt-zrtp-02.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ >>> 1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/avt >> >> >> > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From vsixmt@amorepaz.com.br Fri Oct 27 10:11:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSQt-0004n3-9a for avt-archive@lists.ietf.org; Fri, 27 Oct 2006 10:11:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdSQt-0000k1-4m for avt-archive@lists.ietf.org; Fri, 27 Oct 2006 10:11:39 -0400 Received: from [58.79.63.52] (helo=mycomputer) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdSQm-00085Y-Kc for avt-archive@lists.ietf.org; Fri, 27 Oct 2006 10:11:39 -0400 Received: from 67.15.60.78 (HELO amorepaz.com.br) by lists.ietf.org with esmtp (6VY3NS9K90 6B4OY5) id 4YVBT5-F712XY-XT for avt-archive@lists.ietf.org; Fri, 27 Oct 2006 14:11:34 -0540 From: "Justine Aldridge" To: Subject: statement Date: Fri, 27 Oct 2006 14:11:34 -0540 Message-ID: <01c6f9d1$cee541d0$6c822ecf@vsixmt> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000A_01C6FA1D.3ECCE9D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 Thread-Index: Aca6QDC1RXO8AUUATKDC442DV4W0H2== X-Spam-Score: 0.2 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C6FA1D.3ECCE9D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6FA1D.3ECCE9D0" ------=_NextPart_001_000B_01C6FA1D.3ECCE9D0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Jennifer Gervasio academy report says. The efforts often super parents, I believe this message and marketing pitches "true toys" super parents, I believe this message skills, 5-year-old son Social pressures overscheduled stress for children stressed-out front of get-smart or just romping a new academy a lack of playtime The efforts often compared with in the shuffle, for creating about creating "super children" contribute to and lots of in low-income, violence-prone a new academy Atlanta, Georgia. academy report says. a pediatrician at The Children's Hospital has a skills, better off I don't sign my son up healthy, development says the report, the pressure, The efforts often Academy feel why not," have shown that videos or older children It says enrichment tools trouble finding buddies Atlanta, Georgia. obesity. It may even If it occurs report says. better off Social pressures or just romping son in particular has release Monday said Gervasio, instead allowing play is a simple he not be on par Ginsburg, the report's lead author and "There's just such a her kids medicine for trouble finding buddies it's chasing butterflies, playing with things you can do Ginsburg, the report's lead author and the academy's report. bugs, romping Numerous studies she says, she for creating love to do. develop problem-solving joy that is a cherished Ginsburg, the report's lead author and adjust to school settings, the just do their I don't sign my son up "I truly believe parents and it's chasing butterflies, playing with or just romping of Pediatrics, says relate to others and at the beach medicine for old-fashioned playtime. their own passions, children's schedules for your kids if you because young the pressure, at the beach drive to has a free play -- whether the report says. help them excel. Social pressures time, it can increase risks for a new academy bugs, romping when they can kids: The American and organized Numerous studies compared with academy committees for son in particular has contribute to depression for creating that they're "I truly believe for many families. That's a light schedule resists she says, she and ballet for each children are plopped in weekly, plus T-ball huge variety of have shown that load their activities activities can be the report says. playtime can create It says enrichment tools Here's some soothing Ginsburg, the report's lead author and begin as early as infancy. become creative, or just romping report says. sp1 Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y> ------=_NextPart_001_000B_01C6FA1D.3ECCE9D0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
3D""
Jennifer Gervasio academy report says. The efforts=20= often super parents, I believe this message and marketing pitches =20=
"true toys" super parents, I believe this message
skills, 5-year-old son Social pressures =20= overscheduled stress for children stressed-out front of get-smart =20=
or just romping a new academy a lack of playtime The efforts often=20= compared with

in the shuffle, for creating about creating "super children"=20= contribute to and lots of in low-income, violence-prone a new academy
Atlanta, Georgia.
academy report says. a pediatrician at The Children's Hospital has a skills, better off =20=
I don't sign my son up healthy, development says the report, the=20= pressure, The efforts often Academy
feel why not," have shown that videos or older children It says=20= enrichment tools
trouble finding buddies Atlanta, Georgia.
obesity. It may even

If it occurs

report says. better off Social pressures or just romping son in=20= particular has release Monday
said Gervasio, instead allowing play is a simple he not be on par =20= Ginsburg, the report's lead author and "There's just such a

her kids medicine for trouble finding buddies it's chasing=20= butterflies, playing with
things you can do Ginsburg, the report's lead author and
the academy's report.

bugs, romping


Numerous studies she says, she for creating love to do.
develop problem-solving joy that is a cherished
Ginsburg, the report's lead author and

adjust to school settings, the


just do their I don't sign my son up "I truly believe parents and
it's chasing butterflies, playing=20= with or just romping of Pediatrics, says
relate to others and at the beach medicine for


old-fashioned playtime. their own passions, children's schedules for=20= your kids if you because young the pressure, at the beach
drive to
has a free play -- whether
the report says.
help them excel. Social pressures
time, it can increase risks for

a new academy bugs, romping when they can kids: The American and=20= organized
Numerous studies compared with academy committees for son in=20= particular has
contribute to depression for creating that they're "I truly believe =20= for many families.
That's a light schedule
resists
she says, she and ballet for each children are plopped in weekly,=20= plus T-ball huge variety of

have shown that load their activities

activities can be the report says.
playtime can create It says enrichment tools Here's some soothing=20= Ginsburg, the report's lead author and
begin as early as infancy. become creative,
or just romping

report says. sp1


------=_NextPart_001_000B_01C6FA1D.3ECCE9D0-- ------=_NextPart_000_000A_01C6FA1D.3ECCE9D0 Content-Type: image/gif; name="pkvmk.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBgKZApEAAP///8wAAAAAAAAAACH5BAAAAAAALAAAAAAGApkCAAL+hI+py+0Po5y02ouz 3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt9yu9wsO i8fksvmMTgcFbEGi7T60AXE4fQ6359kG+z3/V8fXxxeHsGcYeDhHuLfgF8j4VvimgKcIqaa5yTE4 uUgoZzgo2Bdq2ih3+qd66gnqWip66Gope9cK+/qK2+vJyxksLAHca0w3u6p8rEq66uZ8nJiMuzs6 vUzti62dKGl8Wzw8Tq5NLf47zUtJW/0cettAGp/+yC1dyo2Or35d/g+Q2bN7iD4tWgfvnTuBtvxY M5dN2bxi+5hJKhgwo7D+X+cEzTO3DlqlVOBEyco0EN85iBLz2WMAaFK4exprkuGYMqfFfo90jfLJ st5DhQxVFmXoD9U2ljabhvnYUmdIg8iULrVaD2lSqLGYXj1asmrXr+Kcmt2CMRMkPRfbxvwGDc+u g/ocmfRmFyXduw4cThTJiG3Zs4QLGz6MOLHixYwbO34MObLkyZQrW76MObPmzVUE401nly5ce3Ex jmzkMRJBdqh73nVbOnWqfoX+TozESizqwDFN6uZcOevYky+VArvty5bMXFyTZZ0KC9y1n2Oj462O 8/jWmRGBRxY+tHvEb2GPjo4mnSq9z9aTIos2Vz3Q9KjIP9+eyztl8Nf+vS40FRI2+8THmnAkdfNT eOAlBFZ5ZIXzHk/YyabfZaaFB5Za2cBFkEIFuncQgq2AxuGIIjWI026gxFXVemuBSF6F37mH4WCs 4dYQU71N1xFMzZHoD3Ri8daaddGtuFBv1fS3E00yLsbfkTaq002PlqxkpUXO9Ufjevlxpd2Xqzkn In3JifekYgY2Z9QyTIKpjy7tbcidg1ApOKdAKRb1XJ73bZnmjLVZE2CXoBVZGl8hqubNbnHa55aj twnWTpENfVbXLLwN6lFoEToZaKighkpqqSaMamqqqq7KaquuvgprrLLOSmuttt6Ka643IIIqMZ6W oJcFAgRAbLHEAmD+bLHIJhvAAcYaoGwCz0LLrFW6zkrcB3ue2mtfyFILLbjhLutss+KOi8Cx5J6r brfXpjpYBvGOMO8Dr6hbrgL44ruuuen626+/7br7LqmHsjKobw+xh5xcjLLoE8TBMsMvuQDvC/Cy GZ8bMMf1FlzqR5PW5ptMtJE8ssQntucwOtNUPC21MafLAL/qVusfyPB2Gk9Un/DEKXciKwcPxPK8 nPGxFzdbscwL2GwuxjnrHHLPhLJ3pKZGt8TknCT3hbS0G9+cNMcck50vmlRXXUt6HAkZpMREZZ3S 117+K7az4kKdNtrr/o3vx2vL6Fenry05XeEI/6Vifq3JlajPMgv+XO20yj6LOeUYJ0v34J5z6xCw BL8g+Oema3Dd6BSo3gLrp78+AVsouJ4C7bDfjnvuuu/Oe+++J8YrJpDzmLiiarHj2cOiBe2yI5Hy imnwhet1SfCWKvw4bLkpKvzJirQzvWmSMjr+989TitXwySs+26UcAvmn2lJkG2V125cIaE7Z9rjt fEPKhp4W1cFMDloK/e62IPn4r38EJCCYiLYk5lDnfuqZIHQOWLL/jceCdbqKgbgAty6JiUdZ0qCb xlS0CDyQKFPKk3j2VCN6kOklEsJOcZqEpQzF7Ya0CKCZSHhC+cCnURAsU/w+iJYa8udRgHkTCnfi o66AaoXb84/+glJHGh4OxWW/QZKUIATBuSTwPwYZmhdN1MUVbk1IHjrRvG60Rfw0MIkma8tyethE F9aRjcu7XnG2hb8ovuZqR6uhUZrnpDDlr4vkQyOD/DhIP6LEJT/7TweDWB83jup4ERsNVsAQQoic J49W8gtInogye4FxUTrU441yVCb7rYgmirRhGKOnqTNWkIy8BGIuP2THrKWISN/TZRy19MkvhJKF RPyRCHXSHaHQ8iQWLGER10TLWB4ShVykClluOMyutTKFRRQTODl4SgVOiIc+Y1MalkkfAt1tnZi8 ZQHvhM45fjGWEsLQV8qDRK1I5ZzmrKeAdmicagaFRv4zqJ/+MkW0+D1ImdpL3qdCxKnrvSijkCyI +DQ6yuKRxnDhQ8j7vGcyvkwyRsWEZPciZ8pBnkx9tkGOtfRXUxKpND4uDdZGUwOn3wl1qEQtqlGP itSkKnWpTG2qU58K1ahKdapUrapVr4rVrGp1q1ztqle/CtawinWsZC2rWc+K1rSqda1sbatbo3oJ XyWSItADRGjQ91bcuRNsqnSNM7LTQdvltVYMPFpfDStKLwl2sLQ6n10NdyB3LqyhLGXs6UyZDxah TGV02gv3OmfZ17UshZuN4DgfaVpWhvayiyyta3vmzTCZdLGrfRU+tRbB0v5TctSUYG1Z68mWOYwk svOsRyH+t7jS/fZdtF3uWFfmXOcqN7rUra51r4vd7G61shD4qCBVGacMVlG7sXJXM28Kk+46bpjo JS+szOua2Kn3pgqdrnvTdNA+noYSk7WT43QDXUbel1VUahGA4pukTBr4SvQ9TaUG7KqDrvLBJEwQ Syf4pTRC+L0jwSKD6wPiA8vjvwr974bhJScDhzfEAxTxigXEnAefWFV5QS4OcxO+ewK2wvadsY9/ DOQgC3nIRC6ykd1aveZeKrnvg6X5LrwlCYu3wAI+shi2wi3fGjB1FIJylJvJUAxX2cpeKLCSw5i/ r5HWwRXUJEFdjGAyPyW9+BEpT5kpRS4/GW5t4qeKvSn+Z2VG0Y0JaXGLwXk4cpLWM2+SRhbfARgA nznQReiQAA294IkBNL8L69oW57bLZohYfpTuTIfhnGkxI7qznWYzl+zK1w2NukGltkJ9Mz3rBa9a T5rtdZICfMHRSnq/w641KA/FvF7DaMkdxWeX6TrL4WrPWuI0djlU3YNJ28vaGsF2tlegbW5rgbvi Lre5z43u1mlahfylnZcPlG7MeHu+Z7qAmNkbb3mbmN4htjeJ45zvyVg4Qjj29rPBqGoYB9xCdhwg hjuUIFTH2NXhXjg5FB46Kldi4JL894ctLhmMb9zVow5Sehv8cZBDRuRDim/E4Xxo46S8vSpXE6Ek 4iP+4tk0nNTZVMVrDvSgC33oRC+60Y+O9KSfYd1yjTO5la7vfRNjvUSEOuFmLl+Uk9rq+7mS3Sj5 Ho/LmOuawTgGq65wNpM96uBLdMwTDvC1W4blyEQ71n8ud4CgnX7J1LDa885wMVJTs5Elbo8B/x3E ww7visfv4RsP+chLnqhKqva7xwveyB5s8uOYN5WVKHUHvzzsNOc8GjxP7NSP2Uglb7npN+JI5Mlc 9L9Rc9tbP+/Xm2FHAlT9enuSzdGvjPG6V8J57y120v9d1LgPffHHcPzfax3uIxa+65+vhuhTW+zI t7T1c4/9YysO1oW/31RunsFIhX/97G+/+98P//j+y3/+sP+ukymMfnYfXLz0v0IiT157t7Y6lTJ8 19d/ppZNLvdhPWde1WR9B2hrAUhKh5Z2ykdtWzMizKd8xAeBMUCBB5Z2FchIVBJ8GliAHUgFLxIU yRdgfkdnJmiAKPgEVecOIbiA0jd2PQSD4CeDR3BepPd5N9h3GnhqzVd6PWgEm5JclrRjJRMjttdk mseBSEiFVWiFV4iFWaiFN9FdvyIvSoJYOJaDWzgEb9RvwuJ7LJhhZJgE3SJYGgdw2aGDbOiDCoMQ dRNTVUSBCfNyb7d6dMgDdleEFdZvKIVpp+aHfwiIOfCD+/U2mQRICuZxhPZZiwgEJOhXs9c/cNj+ NgT4gc5nibsycgz2gWaGg2dSgdBFg6EYiHd4R5QSTAOBV8jziIY3hayoLRjAg7i4Ca6zi7x4erbz dMBIjMVojMeIjAPmhd6Sc8OoixWxfPdHdbcog6vIjACoiBWQcPlFb4b0i8fIidj4cZOGbZjYjeMI isn4eUClfkP4NokDIeU4itumdTGYjE7HYmuISxkYGK6XiCN4e/TogvZ4jyRHXBdIirD0gBqCXiV2 jSLIdPdoii0HUbOXj5BoYvLoKKpljytWkNjYc0SoawZ4iBZ4hhoZjQQ4c9SIgr+yFvcXi8d1VwwI ZiJYSCYCIh/ZAXhnjToZgSfQkz45P48XO87+KJRHiZRHp4SxVkci8ISbBzYeaZRIKYgjpoC52Hcn aJUBOHFJyZRjuG/fqEJruIFZp5JH6JUNxoek1JVm9GQZmJW5do1nmY1eOZGYJmEhWYMX2ZXX54Yv lo5pKYjDF15Y43CQGIQT14JzaZEsqYUPZ0l+p5eGZnBkqZWYN32BmZR6OZIx54/5OJF9+YBjqXqO WYWwwZnDZX7kkzDMRJP8N1I4CZtpyYiaSZuaIJa3mX1EqZu96ZtkZmOg5W9OFoVlpFO/SS9h6QHH AYNV5oC2iZxmaWk7yZiwBWCnGJ3LKZsA4mtv55AG+XvoEZTZuQGUiGu9J3sDuU+id5hDSJ7+2vmJ hyifT1idtNd60Pme6hWfF1mSWIeddgeZ+QkCAiiffBl6GheE3ymgnbAoPidcbZRZjLOa5jeeC1qG umih44ahGcqhHeqhHwqiNaA6wSlK8BZ3FEohU2ZTHco6lRmQU3SDo/mZfWmhi3mO+JiSYwaHg6mg AqpJEZqYFzF2lNSIZGmZL+qhJWmec8iZXLlmNGeNVXmfHPqS/cl8TVqYhSiOOxqe+CmYbZeTVwqX DcmXHumeMXiZC1qVMKqJOVigKBegUvqJNdowHDlC8AZZD0qTPPd1KTqVVOqlOXqi2hiiWFmXjCmQ qFOoA8qbi+qoj7pckDJNwvJK/DaCPCX+qZDKR/45fQ1INwwoTKZJjAXIplsqqOB5lUb4qKQqRQS3 DUEpMnNaepA5eo7anpT4VwYKkL1XeykZpyO5qLd6kLLomashq70KkmCKlhkqrEoKrFzqrDI2ncm0 pMEaY9GKq0JImdvnphbpl5o6RLGBXGqmHZjiqvvHnUvZj5gJqTAgqu1qA+8KrzPwp/Nqr/eKr/mq r/vKr/3qr/8KsAErsANLsAVrsAeLsAkbHGs5fjtXV7YRSer6TFsXogLorT+olSWWiM2qq/Nqsdcp YD3Zo/sprMDqsWNKgzYKsmuKkOiInfYaafDYKAkIUoSkdil7qtYaae75f2PamS1rpOH+CLMy9LIU lokZ6Y7S6q8Byq3JirIZVqEIy0HoqpBvAT+tua48q7Bby7Vd67Vf+3rLWE4DODvTmqghAG3aKK8U 1IV/50/0Wp60xk61yYXLeqh2a6hbCZZoK45Tdyr0aKY5K7Stw7fDSbe7h4aEygKbNKiFy6mI6rh9 u7e9MriLG7lke7hlsK26xWPnulGoZZy5RZmD96qly0tAYXJe1DBGA0DdmT4MEoX4Q6JAmKcUibWu ez4PwjNEQlf7Uze5ZFy+5FoF50HiaijjJqRYFp/Zqmtgd3uECYJP66ygmqV76WgJRpEgBqoEl55E epY2WKyEtofnWWyEh2p30rxGGKT+1PpLOIdr4cud/ohB51mtpgayMrefw5q/dQFDopaaw1qWJqu/ JNkMyYsoMwqEiGmgTYq/1Wueb5qgDeyJcfW8l7a+EsiP+miHCpi/ODKZqpkFUimm/FmmZ6iG0aul 0wuXDjyl2TuK5pi+b7rC3yuEdSeJJRzBfjm+kyhxqbexGQy0O3ytbeomMwxo9ovCybG/JNyx70sm J9iH+GvEg9jCUayY95mr9LvAPivFyNqeFZxrWWzF6NvBDDyZSBrA3FqtYhx72Kq9eGt8j6XEMLW6 QWOLLbVl8WtjvCtcdBwbe6RsV4OBrxY53Mu57MgPeAqxGIU+6vNvt9tlE+V2neP+oObax/nnXcpW eM7WODtXt4Rrli6wtnpLBLtok35rfJrphsAjyorbyt9Wh2gZuKjchqocyoRRr+o2yjiQy/EaL71L qbuMOoLjjL0MtseMzNzmXWobkc/YotyTFnD0U9P0sI1TcBShbvJCL8IIX5XWqMLJbkxgpYZbcc/M vn9WxI15cl+ssQEpA6PDkwxqqRd6t6SZuMIsz9Q5Oxuaiv/ZlokKmE9LA/AMlPkMuWsALPw8g/yT x88LvYU2roD1PwFttEfYzmTqs/eGoMKbuqjra5cG0W7nlgyNWsPbcKblyIaXRqubahPFjq2rc6Yr FK8IbPw1NYFYiNmal+2rQXP+uncJXMNHGpVAAtAnhaNTPL4Ya0I7i55tSr0vurMXFJl8B8FopH3o 6Wb1lp4rO8IcS7vfC2yFBseiWExAVL0qJqTpi6zoDID9bNHu3LMnSV9cymtYmtZSnJpyeMasxM7E VoozfJdTfL9Vna5GHJph7aqYINTFqr3GDLeS6a08HIIw7NQP6bJrfc6z2q1erLRYgqWXzdQy3Nc/ +5nIJ3FQHMZaStpErKRlzNmp3dN0OaOBjc/3zNpyObOnTabr65lJW9ED+Y8I1ohMG9iqrdTKO9uV vcWlTXW6fcaETb5sDcH789dIWqBePdgmjJdjLaJwsrv8ENHSkaIY/KBNi8f+xRlJqkFiNSWFk7Ic kpoox/RX8V3HPHPN4L04OKLHDutz4l3HbaKEqcQ4qkkbmrc8hoJ+ICzH3wxKRhq3PwnKpewEIypa NGrQUWCatW3PS0DQi7dX3uHYpMPgHkjMGp7MJ95VnvqFksviwzy3bUuvIw7Ou1K5M67fJFBc9rdH Trl0G6rNZ8vdrpyzQ+7j63zL84zTiosquXm0V3zQka2o71TkhkvKQY65RB6oR47ld2vijWvkNxrl nFiqXj7lIRyrHvzA27hoqMjJI6PS3PghXEm6qdW6ufW6v2aY/eXfuLuN3o0kBxOrmQW8rYpRJkSX 0vTQLjmP8pSQb77VRE3+vF1OzrWQ1FGtxiV3mP+rwgqGsVENZuSr07Fn5y39j71t08mNvcW9xuJ7 vqz61Z7oxZYuGjkt1tHN0NVtiG1svSH51E2g6bcthp6V3aiNkS5s6+t6mRZWixknvSyG7HEJ2Wzb 2ow90UiRPcZzpRR8wYBtH+CDb38swPz5jnfo2qnG64Kdyil821bq1mH36zEs2Nd9pDDG2O/O7nJt wui81zLs2SAx12u9pKb9rG8s3GrN1vkO2F2ccv+r70Bs67UsiQ9M8NTOzpne7PC+3Nsdl6VO8LzK vNCNwEC877pqihQPc/gu3T5MxdSu2xOv3QnvwnSt1iWb8uHug++oInr+6pKCbsh+XDSb5fOCDPSC jEyxUMia/HWzsUYreslGX1IFXj5O+GzlR6w6t/Tlnd7dk9/SFLyBnN8cGeCvBbFhL+Mi6q6nh8SS DuLzc/Y9noJZvjZq78yiXPZIEOI/cPcorvd7n8wt1OJ/T7FXfkuUS831rEViW3xjrp1VXjt7y8Va huQV3dvYp/j6DPg4bsoYHZiVb/hGN7yw6xIvbb4tBcmwLounj1v0nlBAapKo9KPthrSA4kxyb1mb 29QeP8S73ug/nMBebWaILfFsfr9QTeoI/9xMDHTynq4+TcKmfsM4icjXvvuISMTRzb8jD8AT/HAf bnHK3/pQK+5Nfr3+w92C5N604gns28dyIG/hdi103s+81+n908/VvX/yr42g1X/vJazFAnz8/U8A 8DF1uf1hlJNWe3HWmzPxQQH4xrA0wFI81pB8SSSFVzSOVdO2a36uUyjWjfhLBHe8k8uHVCZhPpWw U7VesVntltv1NnoL4JdcNp/RafWa3XZTHeP3nF633/F5PRb3cO4BAwUHCQsNDxETFRcZGx0fISMl JykrLS8xMzU3OTs9P0FDRUdJS01PUVNVV1lbXV9hY2VnaWttb3FzdXd5e31/gYOFh4mLjY+Rk5WX mZudn6Gjpaepq+1cwir6jsKyL7YVkMT7/prA57zD05M81t/c0eD+I865gcqDxuXRC+Uy3PW/xWEx YqCcf1QAZkkokCGYYt7gjekHh6CQib4W+mnIR4IIiQNPaGyT0YNIh8QgTujGDSTBi71aDGnhkWbF JexeyKiZjdxMl1Pu2fTY0mbJITtqLunW44fPKU9D5nyy06fTIziZRpGp0x7Nql93ylx6NErZp2XD Cu0asmLTcDKMfqSYQykOfNvsmu1pD+keHQYRDq1qkV3gojHbQoGTUm5Rx1cR9k28MnHUyoiZkr0c efDjoT8vY14cmXBpp4MRg+TrMqbUyarDpv4smyjRdZ9BH15s97Vu0J1Ft3R9J/jm3qxdU05Nd6rq uaRzUzbKfO3+87NW/xYenZs0bq88qRORwnYu4Jk3nP9W1897ZaFwjYujnh5ybbiNM7+XuLqe4/NW hbNuH/jiK427i4rzD7rGAjRQOjFqKw68wzqzLb/jutPPofyygghB55Z7L7S3RIzOvYmCm62g+rh7 7jYNy8uMPf4wdE8nAkOsQ7oUHTxOOYp4LBE3zlYE0qQgW4MMsyQLbFDFzeQCj8klM6xSyAWJhFAt i6YEMb0uTTPyRwFPLNEzGJ/MEkkjobsGr71MoEGrHLoy4iix3IrxrurGWe/OPe0UC6i8yNpr0KiK +C4prtiKU7wn7oSUQiWwqWu91jC97is6qQoP0QubEM4rRiX+nYoGU3my866ttgr0GJIggNWa6SJi cUAKZN1u1jVyPWlXDl6ytVeFLBg22F+9oAdZdJSFtBw1mu3i2WWprdbaa7HNVtttue021mF95WOs bzGYNllcddjir9v0iVYMcPVwV5sH303XD3i1wLcjMsv9YsJYA3pM2n753dc3M0kEuNhzeQ14OpXs q09fjszIcYOJHy44YoXjIVhgbdi0VeSMDeYCY1wd1hLlkk/ugAkj/pCqukFnOxVVyZiQQqtViyho Rj4/7Q8qpW7KZ+cO6byOPF3FmyHSSu3zbkZ12hqVaNg2lfnpmrNiNSdCxzvnPK/XIrTrm5Tsq+cW BxQNwdj+ipTQSRG1Ns5HNf/E0u02AWOJNTQRrVLuEHOmsujtUr3xyQSBA7xHy/TazUYw0VYxyPvi LnPKHYdkrnLJW9Zgb4RH/5u+5S5cs0wTJ9tRb7+XpjvhNBetk/DR/mNxbNnTtVj2s8bDHZ+qeetb PeT6Xqpz4sdeEpz2lPc5OYnLYxq9Ntv+vPq7FdMN1OQX5PB3/sA30Hxy6AuQNsmWHvP4hI83j8R0 5LcbRwVzbM/x5Rk3n2/DyAQ9+DDoQ9ibkNw+xgbjFZBJ8RPTAMdnJS9laH12W1yY5uY32rWue5f7 nW0siMHJzU11uGOaCQF4wfWhToSj61z+AEebBrpOQZn+W13o/MG4N3VqT3gi0NaapyhJOapD9tKU s4J4j7X57IjAexRW5BMpc+DpVHO6mudgBrXnOeqHebHa37LYKLRwpXZPJKIUKQU2T3nRi4eaIqAs Ja9PYOxYiYAVDl2BR9FtzFspq0IdEXHHZ+jRH3zso0pCZ65AypFVy1DkSBh5SElOkpKVtOQli5Wq 5VmBkU7bI7py5jJsROtN85AV1OL1DULOw1+NyiS5TsG5gbFSOxALmO9u6T+VGfKHtsTlSC5msoVt pGQaiwst4UcyRoAqgS5DpjF36ccrMDOazeylwVZZyE/ma5jhKqY1T9IuZY4sD03TzMZ4BqQKDY9G AuL+WVoKh7SHNQ07zZIRGmvXSHbujmzrOicU+LcpqNAzaabakp6Q0imlcdEsdclTDxUnxKolbYuC QeNBXYVKvximZtekGzw5OqI0Wad8dbtgAsHnwo18TZ1WUuH/BCe5Lw1JpfEBk0EsOsIUBm6n3Tkp inQV0xi6SG3bq2kDAzE81pH0S7spHWdipjLVYeqJtIpiGjnWOvS51D/tjCAW/TS5qypPhlgKDQtf h5MTNilBq2uqW3OXNuRJDD3+hKYbeARUzAk1r2mj31VKSsF3+epfsjnIBKmnOcDeKIMwhKBO79fL KCEOg6lDoSuvxNYinU6uCLRRZz/WV6plM5hQihD+ZzXbm5pGNrCmtV9ib/pZ3Ynwqw5831crKFTB sjW2u0XrRE3Hm8yW8IVBTe2IzqRa0Np2k+WslJyi18+rjXK6Y6wXqcxBlUC5CokJzW7UembFmw00 iRWdohjJmlGB9oSJBe0hdA3FJfk2kY1NmVPihiaoUSqKu6ESLxzvW1VMknNZpN0eGQw8YEEkeBcJ ppcwFRzhTTxymm2UFoMlnGENb5jDHfbwh0EMiU5ykn5Syqe4TFKGSHakVgpZiBwxnK8YlxaWvGQs P1qZTI9ib2UppkPL/uoxYmb1j0Sm8TdFbOMhJzXHBH4ROL05TmASq5q29LGRgYVlbVpZEoDU8kb+ +TSqeALnvqO1lEilZqj4dvQ0gklKfLGypeimc6LX+5SFh+PGgdZZn0g8GnYh2iqBsq++RDsxGaGo OPQCdKEzM7TQOjq0nQH0i8xiXV3NqrW2tpmrhzsTkthsmqNStqjkmaF3T5NanOKvhaGu3/t++lhW A7drGxSpAX3Lki5RabK3Q5uolMvYnOY2ewtsEG99fUNSj5RLduZrBO0K6MeFjLjM6/Tt4jS/LN1N hquSaw2V6ht+Xi7c4VvUALcbbq6d+62NjR2arjfjcH6QPW89aQZDiNzFSjamKR1sps1k2SbdNt/Y vqZouYc+D8l6JZ4NtqpdtED3/ROF+G33svH+uaKyEudx/u43rgEO7Q0927XxHvgKA95xn1b22tWj HMJPLSUJEntxaLX1VIVF25Lbr35joiHlFLNBeV/XZvZdVxAdGjPq7pe/Z46osKFL0TSXkayHCuWi re5mpYXqiOxVo9HPnKeuOzpounaamr9D6aMb0WhKb/Nqrlp2KppazNQFbN2FO/QJKznLg9D7NPnu TGgFPhIJ+TsnvFxkv3eZ8Ec+Q+IpAZDDd4LCopw8GFac1MznMMaVn8QjNx9i0Y+e9KU3/elRn3rV r571rXf962Efe9nPnva1t/3tcZ973e+e9733/e+BH3zhD5/4xTf+8ZGffDUEgPnND0AXmP/+gOYD 4PnOj74BrJ996yNg+s/n/gGcr4HpZ0D7Crg+9c9fgfFHYPzb5/75179+7Htf+WuAP/Tpv4Dr79/7 8K/+/LEP/d4PAMEv/9KvAfLP/BLQAu4vAdLvACUg+iAwAN9PAsOvAqsvAwWQ/xaw/s5gAtPgAQnQ /wawAE0Q/EqQAKXPAUBwAlpQ/zoQAiyQAQxQBanPAQFwBmfwBj2wDSSwAOPPAruv/Pyv/x6wA/nv BG2QBPVPAG0QBoUQCI1wCp2QBv8P/bJv/jhQC6vQBLfwAlOQBxVwAzVQCGOwB78ADMlwDaMwCRNQ B8NQCh3QAOlQCXGQCVmwDPVwDTdQ+oL+8AZ1cA/7cAzhsAtR8PuakA338AXRcAt+0AszcAhz0AjF cBLfEAk10A6P0A4xkBNhUBGrsP2uEAFHkQR3EAtz8BNP0RArkQJxcBJBkREbMQsgMBBTUP5qkQo9 kQ+XsA6f0BWT0BXnMBb7LxTPkBNNMRMzkRVhcRMR8Rmh0RZtcRbNoAGnURk/cRiXUQUp0RjD0Bl5 kP6CEQSlcRHFsRvH8BbN0Ru7UBqfEAwxsRxBkRrJgAjb0AyxUAQxUP7kMB9R8QIBEhdFMRK1LwaH 8BwP0hrjESEJMh8JUhzfEQ+DMP4UcCCB8CLpkRCysBVZ4RgdERozchfq0CNJYRTrUQz+STIkaSH8 ZLEkU/IKWlIlZXImabImbfImh4/p0EXH7qqRVCkOHgx2RkvvgvJe3InBxAucQo8QPO+P7ujyKAap nikqHY8nr0zW3mGbSK1joAwrBa/J5g3BCmbiLIGarlLx+i7Kvky2FEgrP+jxepIt3RLClmyWWix9 ynKv3u1rmo4uksMJIIov26mM4madXsh4pEt76sbQ2Kx3yI6J3AJAyIZCPOlsPmuJgOKgDApOSkl7 Gq1ydqhUzInR0u6hWCrRKEUzxc4Qau0yGe3SSu2AYGPgICek5Ay4dGvbsgbVZgrifAeBmG3VQASk XovgUIPaCsTn4EZwghMvee3WMiv+pGguNo/tEMSH7VBLf4Au5KpOfZQK5d5m01iL5CDO2uwJ4LDT gMoHeD4tJbSq4SYz4mCOPLcybJqN3IwqMBjoPvGSNSEoyJStpNxzPZnKf4Az5V5L4HCO5Nrq3Qou tPpTMXNTpprqr3QI3HarPPEtP2VJL3MtP9kmRJnyPw+sgsRHRJWNNifrQfVKPGHzuBZ0tZbr4eoz 2ErIhiqUqD7usUpnQTc0OSVosz4UQ2+ruRYsvNgtu6zGdrQL0taGvYQmaF4GLQBTJ2/svYQowKYU 7MqOM9+Mi8KqSuvuzjRKo/wrSSlzSdNrjMSUoeasM8OoicAri6pqSmMHKv0zLl/+pfX0Kg3wFMf0 9CFcr94GjxeaEicpT8BU7E8RtVEd9VGRYSyWEi0bD8rs6Zec0kHj4WT+RcYmDF8ulRZk88fAssog rFMpVcq+kmFUrC1T1SpXobi6UixZVVWpDFVX1VarUl3gsmFelcDe4UnTjDFPRJzIMh9wJlmJ9e3q dIsIra6+NLimrh4WE7Oi551KU58wU9TurJZUJdrISzPFqKuetVAiU1gldXeqqE/uaTORbrPi7ho6 bthW7jTlweZ4dDZlhjgbB2/Yki9i7TcMyzjly6R4TDvrVafeZucUlrI8yF7V5EQhtjmCiuawY+XE 1dNKbmARtpzG03SezYjq5UT+S5RByZOqJHM8fY7edC7vnOpgRQ6qtA1EbwowYctT/ArALMTkeidF UQvYBKtn/apC4yrhUsndOihDUwwxf85kT06X9hKxMhTlHNRgaVPlpkdcp9OmIqZpF05qD4aZpBI3 DdS4yKdgk4tEXep5sHZSbzVmcQ5TFTRfndZHe8s9bVQ3HfaYYvQtCPU62WQ/awRfeWfmWG6pgBRG 9u1nXxO3okblBHZveUxHwkyivsu65DON7GXNqNS6lm7tqI7uxhRd+Wtd8+tcyfTqnK5YLZfS+iNR wlWDEiV0BY3ufOhPMHc1PYOf2stmVRPtJE2LykZNGTUZOq9SGwHylgmEugn+Us+SVmc1yQI1TxGG y5w3XtxWEQ51Ebwtk4r3esE3fMV3fMl3GNxWjZCsV4EyUzFPKH9yypB3Ucvl77KXxOSJlurXV7Xy e2F1x6RJZMDl8PhXTzE1xwS4RtN3RI9sgIVUV61XxwKYVBdsmIaugFsVWNcSe4lHdm+zd7+Uh4DI oEpl5LArOghq60x4anjXbCiOvmquWB8t6UIY0QQzoQizXMcleHNKStmoaOgpdKVmKLFKUO4UMwMN UJRXR5Q1YQHE5JiLXndN58JSrF7UcqTT3m5OM5p4XkHz155TswjXi1suNgEX3Oh1uP7Jg/jMsSLt RhEzrax4el0VZEnl1Nz+batQdlx15sX6ZGgpqE70VnM0CbG+x97GeKr6i2pdq88QV8/yNTvELTt1 yW2CAmS/M3jeUm/OVo71l0bmE2kto0bG1eJW6saMtoMJ2aysNZWZtzxbS43bh2QzRZanDYYf2W+F Ejz5Z9tmlj0x62a/jXz0B1CLdGo/NmDjOJnlcrYa1uNibT2zOJAD2W7rlrZGNZPBk3mb8+Foqpff eEgnyInT55s3Lo6j98fsjozoFM445T88d4ngGfOSiFFs5rtct+hm1+1Gd3MrV4a1lIiiTu4S03c1 aZ/bVInidE7Ha3LtlB7s7uguKtBceJ63t3yzkpOVOLI8FqMteo7iV17+E2ujz7mjS6GiiaPE+Nek SXqlWbqlUUGR8pfzwNSQ7jUjGPhbJO8fctiYYnp+Qeb15BavgvSTxGlX03Jl7nUs+1dLiFL4JE+C P7qX67LHAK95ReIuG8+Ca7X34lS4dDg2fnh1M6aNoVRMTfh1ibOIKw2rzg1J/y0xu04tVPjprjVj SRN35+qhAset/xKuJaznxliMGZaYNM3ljOqMnWQ5ZS5wlVVGXVNxn1NAlURWJ7Y3X9hE8yZvPU2Z Ncw8vtN9qDbSiIySIURsoAovDFlkh9mM8cxzfFKxdjTfLg5K9Pm08TNsZZZoA6zDXq2lpEiXJ8XH JKRDc1SqlHZxxZb+ZiGUSKsYcgV3ZQGUlzO2m9f2uPU4wwBbtn9Wkb3Jsbd5OwMLhlrUZH0NtB0X mmcUnBO3QQ+kuEWLs/+6h5H0TVf4ZY9yeM3UTKWuiDmFWIcSv7rXL9HUMcet0PDZneeOM68I6hRK one3iJC4weMZ9pIYUfu0USscJwkVUlXaJgPcpUE8xEWc9zrppueF83K1ll5Jm3j38ZDyre+F6WbX r7FIZAeJqnEcKk+Jo6caVsmSb3lcyC7YK49pqTa8htZKGl5MyHVcyHk1gZk7LJtafYm8lGfHK6/Z xEUM0wpjn5zU6byNL72rjg+zdYdVNBlqa+Sap/RTdnfZnVVlOOn+bK+1Fa3lY2YQejJXiLrbeatg ilwB2LiM94oTF2lXVkJ/TlZDWWNX+9Y4drBHir0bu3sMmTo3G+RC+TQRFzhB6mInd2eLqJoOyMb3 9D/L7U4rHWuc5yUI9KxS+bnbXLrHbS+dbbm29kDZs8yVs0cR1NAhV+38vGHdN7nM0hh+hF4UXY3L G4Jn+yeyuZbXG2xtzdQ+HUZtPZxlfeTm88Id90VNGX4G9Nt0tNgFlWEfNtWruWk/LUDh9dqf/eWE /clSJIzf3V/Fu9BXG9drlqmtXJWTuzq13BH4+mzUK9TLWl0H7WbYdo+bFM0/V8AlvDRVV8C7ioe0 zqbOCL4USq3+RKWhLYxssTRcUedS4dzPwouI+3sWA54rOU6kR7yqXwFPi3flG7GnK6HDXcwvbP7l eb7nff7ngT7ohX7oib7ojf7okT7plX7pmb7pnf7poT7qpX7qqb7qrf7qsT5YYUyo2zfIexx+l5rF aJrcu3bLfvqXqQbme0y1rUq/26HGLuFYSKIoM1jcS3WOn7ebsNrJodyXAGbKnfOtU3YttXp5NYgx D3NZK1NneCotDofTABZobfNRKL/mRp43ET9sPSve8g7uNrjAaad5OEq+VdaiPCk175rWzg40Cd6P 6/TuOGRfU42MI2+yWyprJwXp3FrcLjvxXY1mQ9+yO5bWNDb+hruYMMalnDmoYLsNjEgziJ1HQzbH +BUb1QwrWu0sU7xmiR/Es2uT2qfr86h11eOdS0v+lxGZsV8GQbdUzOxTq9YqmRcfY52diEV/16JE +Q2Hkk2qrPZd/wlABghq2jk7aUU0J7OqtibvYoXjRoVQdkWQ2LovHMsz3WYlqeIppoPcZyUC5nwj Fag31BxxSCXTyJEid7uokHkzPZXXrylYJRE7HeAUej03x0ujFG12YzEPV6psp27r8xpgoOCgRpDT hkOXWCLiU2NFY9GW0IcjZOEbmxkKpqRH5WYZ4t0P5VJeIkWf4UnJ5WRrmCfjzdpJnWmSRJZj6C6R U2jhF6/+bqdW1W+S1x+h8zN0tPQ0dbX18nV2No92t7cg97f4OHm5+Tm6DGg6O1f7+/Q6/Dx9vf09 fr7+Pn+/f0yqQH1ohFOXiVUzgLXkFXwQTh4MiMciSowYRWFAGwUJbXyRZ0ixjnhE1hATjySekepQ nnT3r+QRcDJtAASZIwvLj9ge3qI5qGOwlNhgEt3IkqDQpHNwuiQqLefFlEdjZrJozWjUlzN4KLtk BydXH5V2+Uwz8JMOnWASjqpKphRTVaWydu3ZVlhUSK6GWSnmJdImn4qaquprE46mtrXCgAVpRaOm pXO/uuN6aIUyD8O6aIUcp3IPv7dCxroY8OxmspvHmC3+ohnLHa9j2UxRnXnR35FyNKOKZCs06D15 bQ+Vq/qwHtm7TdY+09yxJV3Llz1fxWVVms40Ob0djdYyi5he6R50HNfu6Ix/bTHVm5EYqFHMYcmn Dtk62sDhP5mkQ/VHfuZdJ2CAwFy3H36w8PdGeA2SYdt4rrGQCnfY/dfZeJTgFpROeN0kmF3Vncfa XgwOBiCFdHwUoYqM0WcfLgeGyNhOnTAHI3JZfQZgYFIlJqIfCkJ0W1lU6FdkGydaWNxLp7W3pEPQ VYhchwjFl6KTYIS02GFaoJGLjZVZqRdsNPJFjCVkPWacgzIOJ+aVao7l5DGPcXmcX3JSSWGCdPYI nY3+fMoVqHaFGnpoPlN9o+g1jCKqjaOPSjoppVtFWqlbmJJTkaadevopqKGKOiqppZp6KqqTcirQ TNnNsyph+nTolFJddmnUrAY9AxRFl07GakO6akqKP0FBM5UebkV6lLEeMVlTpoCQlCuISFlVq7OO +iosts64qtS03UpbLauNYkgsK7MpF2uJqDjnHCmYuSLaL2v2lhaHj+gbb2HCWXmQhhpdBsxthgTD SHdvNeahcZisMaFh5e1h76CUvaJhwA/pC+/DCEdZ5msQKlYxPY+4IYp3CSHznHRpvcvbtxczPHFq ptmE2cu0iFfaH5md0m53FMcyyV5hidUEfkMfnVv+ztud7Bti875rGTPEJikLzL5EJolZBn687VUn t0JcaAjrlmKQtKCNAi/cvFJYfMkcl6Z8Xwqa5MF86bjWdFOih15rC0Lc14o9VT3gnyl3POPKCuvN t1DyLogvkbCtvTbTYFcDeVNkcpjU3MBFtlvURa5p38Jh2Zk2yLOYOPPhchveHO2z+6HGhz7mZnKP H5+CDB+vKY61KbJlu3R0CSfNO3F2ar75cm033jSbtREtNcEkUnfn1gO2KZnHDycmnJta+8yM8POC JWSOgM21frrA50L4h3lbR2bKoselc+/ujk1zMmRnGuUY7HDPS1U3DggqBf6DgbozlAOfEo0IIrD+ ghbsFKwuyJFLZVCDHvwgCEMowhGSsIQmPOE53BYtb0HPI9QSF61Utg/NzUYhOipZuMZVrliVhIHB shR3TIUVZ/1nWWEjorWO9boGHvFCK0yiE2NoOHJJcSYsnOBWgAWFSqELY+pzWNr4tpiB/eo7JKtX 0EwWvTCBcUs0wpnkkoW4/uAGaQ9iEPdGdkad1Qs+zquZmcwmh+z9jjYumdBqkPe1N8bGXiqcHeka CDTDWG0pQiPby9rYqz8Zz5GAOyTPApa8jZmNN5zJ0dK05JnWdNJzSkIlHxv2OastYpJzrM5kGhIb vO0SDu5apGjseEmtdHJyXbxR//qlPEwqE0/+nwxiK9E1Rbvhsm9YKiKfyKbKZiqtlZ80huSMCbe/ /Q1BYtufOZO3PTXxMkSn6deTKok3Y6qHH8W0EOnc878a9e5qqYuR6IwUOgOxDo/l/Gd2RtQLBQm0 kKrUEtXOkxzbfbOO6AQjkgIKpcFck0e78x657nc7YiIEgIBB0NvINycyko+b7+EeXk7nO4ahiVB0 42biUGpThhaohv8SJCT/N7+GuQyW/MrnZUDprwDh9D3JpKUZ9Qe1QQ1yIsXqBwWrSEwdZpUdXUUh WAnSwRSOtYkQ5FRZSRrWtbK1rW59K1zjKte50jWsafXqtu66qC16Q6999RWjlvVCWVmVX8/+2lVG YYipr8ZjKMiC1g11OC4F/jCBV4QsEssV2BtS0Ih7GylHuHqtQ/VROm07nZswF9XzCdJ9l+MrxHzh R7EMJKWjm2PPXFvSmIoxk/Dco4scB7J4ifK36bsJO5txOeLm9pZ7BJpzBwm1hZATn78pGdIOgTjq 3Sp3qZHo6NTiTh75D46UhK0Bb7bQ7bKHnKnN03WztpOh1kl5IHXhVMc3TNeZ8nNHGl/9mPfLpCrU eMQbWrPa0RsRvTOn0szQ3QokN9VRtHD58duUWMkaExEUmq9EKR3hVB+9OdiiysTXKKnSIFxK9cQO yvDOcmfYDVPudfXxW8heKbbDpjC1rRv+bpActjjYefI+QsOoMz+cFxQZA31gkh9Ah4sx4RqUkzIS MGi/6NF/IrdsroJpi4JmsXmKL8aNSZCMg+xkfJS2ZT3j2TiPtBD8XUmoYaKvfpj7pTQ5LX85FlPn lMslNnmPuu67sPDk264GZ/KkcdLnfaXWOUfzmUpeeu7Enkww7GU3YeH1RF1JyNhQkzqLpQ51PU+t 6r+uutWufjWsYy3rWdPVr6PlsUqiaKlX7cczMARbgp/Yw6rY+taI5WELy4ESH4Z2gbiW7A6p2OzM PvvXfBW2saed7ctSm83Y/glotwFubldb2lzsopAFhDN4vc83tWxZVQc8NaCa8XziKZ7+IYVBtdUe 9cp/lF6a863f3yTXt5WLmDQHztx810Vh5zUfUeP4IOxhmZYJpfeoqaHGcgoMOBlTr5UB/LT2IjlK aAydzSBucjtKeV8eZzma4ra6h09tu2xE2X+hy/D3loi2jsueQ3pOyl2a13zlDSAhpXTKqxp4xIgW +k1xPNEw9ynoIoswT+L8NNNWybkvJzHkCue121Hz3s783j3JHGe2VXjtHO8blOXcJrbLtqLedamu E7Vj5YJ0dR+VkGvKZiTFadeXSpVY8H6k1IO/DaEcBx6NkzwdMRe27zo3MNaoHug1w/2g+csn8Yq5 XiB/C6trzC2EZJElfyFTevStJaf+kZ4e0xJqXXW3tN0Y57FbUljGJI8jeE5fvkVTN5evh3IBczlx gIbz+P3efT/Lh2gZhjDja7W+OLCvWMtqW6tbPWGqad1xVWl//Moua/jxS9ryi7/97n+/ObCSQ6sE G9rUZlbe11Fs+PO/VJUFNw2Nm2JlnUHg3/b1HwIi0MrNW8ThW9fUGHSV1sehmPXc2/KZktYIGUwF UwJ2oKpAXugNj+r5E9JtHFyoQc/1V4xtnecoVM7tnQfG4AeioNXZVr2ZGQtOU0eNXIaknN8Rzty8 GOCknwwW4VYtDtFkjs55h57pXg+22BZVEwbKVDs5WekZIRZKUp00EuEZ15zUzxvcHYg2XR3juJng Vc26ERqgZV4WtqGzWRG3aFy0RZYb1uGrjdWq7J/5QVG52aEf/iEgBqIgDiIhFqIhHiIiJqIiLiIj NqIjPiIkRqIkTiIlVqIlXiImZqImbiIndqInfiIohqIojiIplqIpniIqpqIqriIrtqIrviIsxqIs ziIt1qIt3iIu5qIu7iIv9qIv/iIwBqMwDiMxFqMxHiMyJqMyLiMzNqMzPiM0RqM0TiM1VqM1XiM2 ZqM2biM3dqM3fiM4hqM4jiM5lqM5niM6pqM6riM7tqM7viM8tloBAAA7 ------=_NextPart_000_000A_01C6FA1D.3ECCE9D0-- From avt-bounces@ietf.org Fri Oct 27 10:21:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSZH-0001rY-3p; Fri, 27 Oct 2006 10:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSZF-0001rR-Gl for avt@ietf.org; Fri, 27 Oct 2006 10:20:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdSZB-0001yE-TG for avt@ietf.org; Fri, 27 Oct 2006 10:20:17 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2006 07:20:13 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9REKD8I009679; Fri, 27 Oct 2006 07:20:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9REKDW4013829; Fri, 27 Oct 2006 07:20:13 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 07:20:12 -0700 Received: from [192.168.0.10] ([10.21.98.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 07:20:12 -0700 In-Reply-To: <4541C0FC.3080208@ericsson.com> References: <85384093-2F6C-4792-9619-CDC8734F7EA0@cisco.com> <453E119C.2030907@ericsson.com> <0987A300-0826-47BF-A5DA-EC06F088B989@cisco.com> <4541C0FC.3080208@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <050A817F-EAAF-483C-8D23-08DEB9CDFDE1@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt Date: Fri, 27 Oct 2006 07:20:09 -0700 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 27 Oct 2006 14:20:12.0532 (UTC) FILETIME=[03E3E340:01C6F9D3] DKIM-Signature: a=rsa-sha1; q=dns; l=4910; t=1161958813; x=1162822813; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20I-D=20ACTION=3Adraft-ietf-avt-topologies-02.txt; X=v=3Dcisco.com=3B=20h=3DNFXujfBomnBJBWsC0QikGwRg/PI=3D; b=H0v1UqYw48hGADEdupcbVq/UMtsknhvS52mMruW7l0KcEZkaUg2+XJsgL3X9Ab87QMGq51Xb KlSRGH7bs+s2hvr9vAvsf0Zw2+7IaXOA820gTkwq/YENdgChB3BEddHS; Authentication-Results: sj-dkim-4.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Stephan Wenger , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus, On Oct 27, 2006, at 1:19 AM, Magnus Westerlund wrote: > Mark Baugher skrev: >> On Oct 24, 2006, at 6:14 AM, Magnus Westerlund wrote: >>> Mark Baugher skrev: >>>> Magnus, Stephan, >>>> I gave this a first read and it's well-written and to the >>>> point IMHO. I have a couple of comments off the top of my >>>> head. Starting with Security Considerations, Second, the >>>> number of security contexts needed (for example in >>>> SRTP [RFC3711]) may vary between mixers and translators. >>>> A mixer >>>> normally needs to represent only a single SSRC in any given >>>> domain, and therefore needs to create only one SRTP security >>>> context. In contrast, a translator needs one context per >>>> participant it translates toward in the opposite domain. >>>> Couldn't Figure 6 have five crypto contexts installed in the >>>> mixer? I think you're saying that everyone but the mixer >>>> receives using the same crypto context. The mixer additionally >>>> needs to receive the others' streams and each will have a crypto >>>> context. >>> >>> In the case depicted by figure 6, the mixer will have one SSRC >>> and the A-D will have at least one respectively. However if we >>> are looking at the link between A and the mixer, the traffic >>> passing on this link there will be only two SSRCs, A's and the >>> Mixer's. The SSRCs belonging to B, C and D will only occur in >>> CSRC list and inside RTCP SDES packets. Thus from an SRTP >>> perspective, A only needs two crypto contextes, one for its own >>> traffic and one for the mixer. The same is true for each of the >>> other participants that only receive a mixed view of the session. >>> That is why I am saying that the mixer will have one SSRC (at >>> least). >> I misread the text cited above, "A mixer normally needs to >> represent only a single SSRC per domain and therefore needs to >> create only one SRTP security context". I think we could put it >> this way, "A mixer normally needs to represent only a single SSRC >> per domain and therefore needs to create only one SRTP crypto >> context per domain" where I added 'per domain' and changed >> 'security' to 'crypto'. > > Your sentence seems like a improvement. However maybe I should > clarify what I was considering was the implication on the number of > session keys and their related parameters. If I understand crypto > context in SRTP it normally means the master key and its > parameters. Thus the number of crypto contexts will depend on the > keying model, a shared master key or one master key per SSRC. But > it might be easiest to not dig to deep into this within the > document. SRTP is a recommended security mechanism but not the only > one that may be used. Yes, there can be one or multiple SRTP crypto contexts for an SRTP session depending on whether you share the key between senders or not. It's better to count the number of RTP sessions rather than SRTP crypto contexts. >>> >>> ... >>> In this case you have deployed a mixer simply because B and D >>> can't have the same view as A and C that are part of the >>> multicast domain. There is no reason for the mixer to return a >>> mixed stream to the multicast domain that contains all the >>> participants, because any sender in the multicast domain has >>> already received that traffic. In the same way it is unnecessary >>> for the mixer to even mix B and D together unless there is a >>> bandwidth issue, because the participants in the multicast part >>> already are capable of handling the reception of multiple sources. >> I recall that there were advantages to doing centralized mixing >> and then distribute the mixed stream over a multicast channel >> instead of every receiver doing its own mixing. The advantage is >> that the device imposes an ordering so the receivers all hear the >> same thing at about the same time. Not the case? >>> > > I would say that this is highly application dependent and why you > deploy the mixer. I think the usage of centralized mixing has its > usage for certain applications, in other the mixer is not at all > centralized and is instead something that enables a few users to > participate in a session they otherwise couldn't, i.e. more gateway > then a conference focus. Yes, the mixing can be done on the endsystem and is commonly done in a middle box. Cheers, Mark > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 10:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSo9-0002JW-Tb; Fri, 27 Oct 2006 10:35:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSo7-00029j-TO for avt@ietf.org; Fri, 27 Oct 2006 10:35:39 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdSnw-0004TX-6T for avt@ietf.org; Fri, 27 Oct 2006 10:35:39 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 17AD815D8; Fri, 27 Oct 2006 16:32:17 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 16:32:16 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 16:32:10 +0200 Message-ID: <4542186A.9030907@ericsson.com> Date: Fri, 27 Oct 2006 16:32:10 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Baugher Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt References: <85384093-2F6C-4792-9619-CDC8734F7EA0@cisco.com> <453E119C.2030907@ericsson.com> <0987A300-0826-47BF-A5DA-EC06F088B989@cisco.com> <4541C0FC.3080208@ericsson.com> <050A817F-EAAF-483C-8D23-08DEB9CDFDE1@cisco.com> In-Reply-To: <050A817F-EAAF-483C-8D23-08DEB9CDFDE1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 14:32:10.0800 (UTC) FILETIME=[B002E300:01C6F9D4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Stephan Wenger , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Mark Baugher skrev: > Magnus, > > On Oct 27, 2006, at 1:19 AM, Magnus Westerlund wrote: > >> Mark Baugher skrev: >>> On Oct 24, 2006, at 6:14 AM, Magnus Westerlund wrote: >>>> Mark Baugher skrev: >>>>> Magnus, Stephan, >>>>> I gave this a first read and it's well-written and to the point >>>>> IMHO. I have a couple of comments off the top of my head. >>>>> Starting with Security Considerations, Second, the number of >>>>> security contexts needed (for example in >>>>> SRTP [RFC3711]) may vary between mixers and translators. A >>>>> mixer >>>>> normally needs to represent only a single SSRC in any given >>>>> domain, and therefore needs to create only one SRTP security >>>>> context. In contrast, a translator needs one context per >>>>> participant it translates toward in the opposite domain. >>>>> Couldn't Figure 6 have five crypto contexts installed in the >>>>> mixer? I think you're saying that everyone but the mixer receives >>>>> using the same crypto context. The mixer additionally needs to >>>>> receive the others' streams and each will have a crypto context. >>>> >>>> In the case depicted by figure 6, the mixer will have one SSRC and >>>> the A-D will have at least one respectively. However if we are >>>> looking at the link between A and the mixer, the traffic passing on >>>> this link there will be only two SSRCs, A's and the Mixer's. The >>>> SSRCs belonging to B, C and D will only occur in CSRC list and >>>> inside RTCP SDES packets. Thus from an SRTP perspective, A only >>>> needs two crypto contextes, one for its own traffic and one for the >>>> mixer. The same is true for each of the other participants that only >>>> receive a mixed view of the session. That is why I am saying that >>>> the mixer will have one SSRC (at least). >>> I misread the text cited above, "A mixer normally needs to represent >>> only a single SSRC per domain and therefore needs to create only one >>> SRTP security context". I think we could put it this way, "A mixer >>> normally needs to represent only a single SSRC per domain and >>> therefore needs to create only one SRTP crypto context per domain" >>> where I added 'per domain' and changed 'security' to 'crypto'. >> >> Your sentence seems like a improvement. However maybe I should clarify >> what I was considering was the implication on the number of session >> keys and their related parameters. If I understand crypto context in >> SRTP it normally means the master key and its parameters. Thus the >> number of crypto contexts will depend on the keying model, a shared >> master key or one master key per SSRC. But it might be easiest to not >> dig to deep into this within the document. SRTP is a recommended >> security mechanism but not the only one that may be used. > > Yes, there can be one or multiple SRTP crypto contexts for an SRTP > session depending on whether you share the key between senders or not. > It's better to count the number of RTP sessions rather than SRTP crypto > contexts. Well, my intention was a comparison between mixers and translators. Here the comparision using with RTP sessions will be very misleading. A Mixer will have one RTP session for each domain, however there SSRC/CSRC spaces will be joint. A Translator will only have one session that is joint between the domains. When one start looking at the crypto context a mixer only needs to keep track of the already existing crypto contexts for a domain and possibly one for itself (assuming per sender keys). However a translator that does anything to the SRTP protected parts of the packet, will need to re-encrypt the packets. To avoid two-time pads it will need to use a different key than what was used by the sender of the packet in the originating domain. Thus a translator will in worst case end up with N*P crypto contextes where N is the total number of participants in the joint session, and P the number of domains it handles. So from an SRTP perspective a translator may actually end up with much more crypto work than a mixer would. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 11:19:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTT8-0007eE-V6; Fri, 27 Oct 2006 11:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTT8-0007e3-19 for avt@ietf.org; Fri, 27 Oct 2006 11:18:02 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTT4-0003ZI-Lg for avt@ietf.org; Fri, 27 Oct 2006 11:18:02 -0400 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1GdTSw-0003Bq-Ei; Fri, 27 Oct 2006 11:17:55 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <4542231D.6070509@sipstation.com> Date: Fri, 27 Oct 2006 10:17:49 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <453F96FC.6010006@sipstation.com> <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> <4541F190.5040409@sipstation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin, See my comments below. Thanks, Alan Colin Perkins wrote: > Alan, > > On 27 Oct 2006, at 12:46, Alan Johnston wrote: >> Thanks for your comments on the draft. >> >> On SSRCs, the case where ZRTP can use a separate SSRC is precisely >> the case where RTP packets are coming from another source - remember >> this is the loosely coupled case where the ZRTP endpoint may be an >> in-line media-only device. For such a device to generate RTP packets >> and reuse another endpoint's SSRC would seem to be the real violation >> and cause significant problems. > > Sure. However using a separate SSRC also causes problems. I don't > think you can de-couple the ZRTP processing to the degree you suggest. > >> In general, we feel that ZRTP should be integrated with the media >> stack and hence should use the same SSRC. We will make this clearer >> in the next version of the draft. > > I would go further: it MUST use the SSRC of the media stream it is > protecting, otherwise things break. > This is not true. Real world implementations are not nearly so brittle with respect to SSRC as you suggest. If they were, common scenarios such as forwarding, retargeting, forking, IVRs, etc would all cause these implementations to break. Especially at the start of a session, it is *very* common to get RTP from multiple SSRC and all implementations deal with this today. >> On the use of RTCP, this is a possibility in the future. Since the >> ZRTP protocol is designed to be deployable in the real world, a >> requirement is that it not require additional NAT bindings - this is >> a major obstacle today to the deployment of RTCP. > > I'm not sure I believe that argument. The complexity comes from > implementing ICE to open any ports. Once you have an ICE > implementation, running it again to open an RTCP port is not an issue. > Also, as I described, there are deployment issues with ZRTP as > currently specified. > Your deployment issues with ZRTP are theoretical - ZRTP is a deployed protocol on the Internet today and has been tested at a SIPit against all UAs - things are not broken. I'm not saying ZRTP will work in every RTP application - some where there is tight coupling between the transport an application layers there may be problems - but ZRTP isn't designed for every environment - it is designed to provide badly needed security for Internet VoIP and multimedia. >> Another requirement of ZRTP is that it not be dependent on the >> signaling channel. > > That's not possible: RTP requires there be an out-of-band signalling > channel to negotiate payload formats, etc. I assume you mean there is > a requirement that the security is not dependent on the signalling, > but that is independent of the use of RTCP to convey ZRTP messages. > >> It can use the signaling channel as an additional out-of-band >> discovery and authentication channel, but it can not have any >> dependency. So, if your draft defining the multiplexing of RTCP on >> RTP ports is adopted as a Working Group item, and there are no >> additional requirements for signaling, then ZRTP should be able to >> make use of RTCP transport. We will investigate this in the next >> version of the draft as this topic develops. > > My draft has already been adopted as an AVT work item. It does require > some signalling support, using the a=rtcp: attribute, but that > attribute is also required for ICE to work. [Note, also, that sending > ZRTP-in-RTCP on the RTP port without signalling is vastly preferable > to using an RTP header extension to send ZRTP messages, since it keeps > control information out of the data packets]. > >> And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on 6/23/06 >> you emailed to the list that it does not affect ZRTP's use of header >> extensions. > > The issue is that only one header extension can be present in RTP > packets. If you use ZRTP, you cannot use hdrext, and vice-versa. Using > RTCP to convey the ZRTP messages would remove that constraint. > There is never a case when another header extension will be present in a no-op RTP packet *generated* by a ZRTP endpoint. ZRTP never inserts a header extension in an RTP packet carrying media, so it will never try to insert one where there is already one present. There is no conflict between ZRTP and draft-ietf-avt-rtp-hdrext-06.txt. > Colin > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 11:32:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTfr-0007DP-6v; Fri, 27 Oct 2006 11:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTfq-0007Au-KG for avt@ietf.org; Fri, 27 Oct 2006 11:31:10 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTfp-00065m-Lx for avt@ietf.org; Fri, 27 Oct 2006 11:31:10 -0400 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1GdTff-0008Gl-Ka; Fri, 27 Oct 2006 11:31:08 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <45422632.8000806@sipstation.com> Date: Fri, 27 Oct 2006 10:30:58 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David R Oran Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <453F96FC.6010006@sipstation.com> <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> <4541F190.5040409@sipstation.com> <474B8DFB-EAE9-4F12-AA2B-5B3447CF30C0@cisco.com> In-Reply-To: <474B8DFB-EAE9-4F12-AA2B-5B3447CF30C0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: Colin Perkins , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Dave, Thanks for your comments on the draft. See mine below. Thanks, Alan David R Oran wrote: > > On Oct 27, 2006, at 7:46 AM, Alan Johnston wrote: > >> Colin, >> >> Thanks for your comments on the draft. >> >> On SSRCs, the case where ZRTP can use a separate SSRC is precisely >> the case where RTP packets are coming from another source - remember >> this is the loosely coupled case where the ZRTP endpoint may be an >> in-line media-only device. For such a device to generate RTP packets >> and reuse another endpoint's SSRC would seem to be the real violation >> and cause significant problems. In general, we feel that ZRTP should >> be integrated with the media stack and hence should use the same >> SSRC. We will make this clearer in the next version of the draft. >> > If the zrtp device is deployed inline with this kind of approach, then > it is an RTP mixer/translator and what should be coming out are > packets with the zrtp SSRC on all packets, and the original RTP > packets identified with a CSRC. Is that really what you want to do > though? > Here is the exact scenario. At the start of the RTP session, the inline ZRTP device needs to insert a couple of no-op packets to carry ZRTP Hello messages in the header extension field. This is for discovery independent of the signaling channel. If the inline ZRTP device does not see any ZRTP replies, it just goes dormant and sends no further RTP packets in the session. The RTP media continues end-to-end. Only if ZRTP responses come back does the inline ZRTP device insert itself in the media path and begins the key negotiation. Once this happens, the ZRTP device is acting as a media relay. It certainly isn't a mixer. I'm not sure it can be modeled as a translator, either, although I am less sure of this. >> On the use of RTCP, this is a possibility in the future. Since the >> ZRTP protocol is designed to be deployable in the real world, a >> requirement is that it not require additional NAT bindings - this is >> a major obstacle today to the deployment of RTCP. > Then do rtp/rtcp port multiplexing. > >> Another requirement of ZRTP is that it not be dependent on the >> signaling channel. It can use the signaling channel as an additional >> out-of-band discovery and authentication channel, but it can not have >> any dependency. So, if your draft defining the multiplexing of RTCP >> on RTP ports is adopted as a Working Group item, and there are no >> additional requirements for signaling, then ZRTP should be able to >> make use of RTCP transport. We will investigate this in the next >> version of the draft as this topic develops. >> > I would prefer if you specified it NOW as RTCP as the control channel. > For devices that do RTCP correctly, it will work now, and for those > behind nats and don't understand how to open two ports through the > nat, you can exploit port multiplexing. > We will investigate RTCP with port multiplexing. We will need to make sure that there aren't bandwidth and message retransmission limitations that could make this unworkable. >> And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on 6/23/06 >> you emailed to the list that it does not affect ZRTP's use of header >> extensions. >> >> Thanks, >> Alan >> >> Colin Perkins wrote: >>> >>> [This is being sent to avt@ietf.org with a bcc to rtpsec; response >>> to avt please since that is the group responsible for RTP] >>> >>> >>> I have reviewed draft-zimmerman-avt-zrtp-02.txt and have some >>> serious concerns regarding the way ZRTP integrates with the RTP >>> architecture. In particular, I believe this draft misuses both the >>> RTP synchronisation source (SSRC) and the RTP header extension >>> mechanism. >>> >>> >>> 1) Misuse of the RTP synchronisation source (SSRC): the latest draft >>> states (section 5) that ZRTP endpoints "MAY use a different SSRC for >>> ZRTP messages than for RTP media" since this allows "for very loose >>> coupling between the ZRTP application and the RTP media >>> application". This violates RFC 3550 in several fundamental ways: >>> >>> a) RFC 3550 specifies that the SSRC identifies the "source of a >>> stream of RTP packet" and requires receivers to group packets >>> according to SSRC for playout and other processing. Using a separate >>> SSRC for ZRTP and RTP data belonging to a single flow breaks playout >>> buffer operation, and requires receivers to ignore the RFC 3550 >>> rules on source identification. >>> >>> b) If a different SSRC is used for ZRTP packets than for RTP >>> packets, it is not possible to differentiate packets from different >>> participants, unless unicast sessions with only two parties are >>> assumed. This breaks multicast and multiparty RTP, as well as mixers >>> and translators operating according under RFC 3550. >>> >>> c) Use of a different SSRC for ZRTP and RTP packets can disrupt the >>> correct operation of the RTP collision and loop detection algorithm. >>> >>> In addition, use of a different SSRC for ZRTP and RTP packets will >>> disrupt RTP header compression efficiency. >>> >>> >>> 2) Misuse of the RTP header extension: the RTP architecture provides >>> for a clean separation between media data and media path control >>> data, providing a control channel in the form of RTCP associated >>> with every data flow. ZRTP ignores this control channel, and instead >>> mixes control and data traffic in an RTP header extension. This is a >>> gross and needless violation of the architecture, which >>> significantly complicates the resulting system. It also has several >>> practical problems: >>> >>> a) The header extension will significantly expand the size of ZRTP >>> packets, likely leading to them being discarded when traversing >>> optimized paths (for example, various wireless links). >>> >>> b) ZRTP cannot be used in conjunction with the general mechanism for >>> RTP header extensions defined in draft-ietf-avt-rtp-hdrext-06.txt. >>> >>> >>> None of these problems need exist. ZRTP can be trivially reworked to >>> use a new RTCP packet type, potentially multiplexed onto the same >>> port as the data, with the same SSRC as the stream it is protecting. >>> This would have the same security properties as the current draft, >>> but would conform to the RTP architecture and avoid the breakage >>> listed above, would work in a wider range of environments, and would >>> encourage the take-up of RTCP (which is already needed to support a >>> range of features of RTP such as lip-synchronisation, codec control, >>> etc.). >>> >>> We have an architecture which cleanly supports all the features that >>> ZRTP needs. Please use it, rather than trying to perpetuate the >>> (broken) PSTN secure phone model. >>> >>> Colin >>> >>> >>> >>> >>> On 25 Oct 2006, at 17:55, Alan Johnston wrote: >>>> All, >>>> >>>> The ZRTP I-D has been updated. There are lots of changes in the >>>> document including: >>>> >>>> >>>> - Discussion of how ZRTP compares using the criteria in >>>> draft-wing-rtpsec-keying-eval-01.txt >>>> >>>> - Discovery and authentication of ZRTP through the signaling >>>> channel and the definitions and ABNF of three SDP attributes >>>> a=zrtp, a=zrtp-sas, a=zrtp-sasvalue. >>>> >>>> - New Multistream key agreement mode allowing SRTP keys for >>>> multiple media streams in a session to be derived from a single >>>> ZRTP DH exchange. >>>> >>>> - CRC protection of ZRTP messages against transport errors using a >>>> 32 bit CRC algorithm >>>> >>>> - Use of RTP no-op packets instead of comfort noise packets >>>> >>>> - Simplified shared secret comparison algorithm >>>> >>>> - New Stay secure and Disclosure flags >>>> >>>> - More details on caching of retained shared secrets including >>>> expiration intervals >>>> >>>> - Removal of Error message - Reason field added to GoClear >>>> >>>> - Discussion of the behavior of intermediary devices that might >>>> implement ZRTP >>>> >>>> >>>> We will be discussing the changes in the ZRTP protocol in the AVT >>>> working group and the SDP attributes in MMUSIC. >>>> >>>> As always, comments and feedback are most welcome. >>>> >>>> Thanks, >>>> Alan >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt >>>> Date: Tue, 24 Oct 2006 15:50:02 -0400 >>>> 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 : ZRTP: Extensions to RTP for Diffie-Hellman Key >>>> Agreement for SRTP >>>> Author(s) : P. Zimmermann, et al. >>>> Filename : draft-zimmermann-avt-zrtp-02.txt >>>> Pages : 52 >>>> Date : 2006-10-24 >>>> This document defines ZRTP, RTP (Real-time Transport Protocol) >>>> header >>>> extensions for a Diffie-Hellman exchange to agree on a session key >>>> and parameters for establishing Secure RTP (SRTP) sessions. The >>>> ZRTP >>>> protocol is completely self-contained in RTP and does not require >>>> support in the signaling protocol or assume a Public Key >>>> Infrastructure (PKI) infrastructure. For the media session, ZRTP >>>> provides confidentiality, protection against Man in the Middle >>>> (MitM) >>>> attacks, and, in cases where a secret is available from the >>>> signaling >>>> protocol, authentication. ZRTP can utilize three Session >>>> Description >>>> Protocol (SDP) attributes to provide discovery and authentication >>>> through the signaling channel. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt >>>> >>>> To remove yourself from the I-D Announcement list, send a message >>>> to i-d-announce-request@ietf.org with the word unsubscribe in the >>>> body of the message. You can also visit >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >>>> subscription settings. >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username "anonymous" and a password of your e-mail address. After >>>> logging in, type "cd internet-drafts" and then "get >>>> draft-zimmermann-avt-zrtp-02.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt". >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail >>>> readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/avt >>> >>> >>> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 27 12:30:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUaP-00068Q-Mz; Fri, 27 Oct 2006 12:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUaO-00068C-63 for avt@ietf.org; Fri, 27 Oct 2006 12:29:36 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUaL-0008Nz-DR for avt@ietf.org; Fri, 27 Oct 2006 12:29:36 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:63825) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1GdUaJ-0007Tw-Jk; Fri, 27 Oct 2006 17:29:31 +0100 In-Reply-To: <4542231D.6070509@sipstation.com> References: <453F96FC.6010006@sipstation.com> <54C75B48-0E64-41BA-B561-0EE09151503A@csperkins.org> <4541F190.5040409@sipstation.com> <4542231D.6070509@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59E0C07E-4940-47E4-9BB0-AD58A2073A18@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Fri, 27 Oct 2006 17:29:27 +0100 To: Alan Johnston X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 27 Oct 2006, at 16:17, Alan Johnston wrote: > Colin Perkins wrote: >> On 27 Oct 2006, at 12:46, Alan Johnston wrote: >>> On SSRCs, the case where ZRTP can use a separate SSRC is >>> precisely the case where RTP packets are coming from another >>> source - remember this is the loosely coupled case where the ZRTP >>> endpoint may be an in-line media-only device. For such a device >>> to generate RTP packets and reuse another endpoint's SSRC would >>> seem to be the real violation and cause significant problems. >> >> Sure. However using a separate SSRC also causes problems. I don't >> think you can de-couple the ZRTP processing to the degree you >> suggest. >> >>> In general, we feel that ZRTP should be integrated with the media >>> stack and hence should use the same SSRC. We will make this >>> clearer in the next version of the draft. >> >> I would go further: it MUST use the SSRC of the media stream it is >> protecting, otherwise things break. >> > This is not true. Yes, it is, once you have multiple senders in a session. See RFC 3550 section 3. This is the entire reason why RTP includes an SSRC value, and cannot be ignored in AVT drafts. > Real world implementations are not nearly so brittle with respect > to SSRC as you suggest. If they were, common scenarios such as > forwarding, retargeting, forking, IVRs, etc would all cause these > implementations to break. Especially at the start of a session, it > is *very* common to get RTP from multiple SSRC and all > implementations deal with this today. Of course they get RTP with multiple SSRCs from different devices, that is why there is an SSRC: it lets the receiver distinguish the different devices that are sending it media. However, that's not the same as using several SSRCs for the same source, which is what you propose in the ZRTP draft. Using different SSRC values for the same source only works if the receiver assumes a point to point session. It will not work if there are multiple active senders, since it gives no way to associate ZRTP packets with particular senders. >>> On the use of RTCP, this is a possibility in the future. Since >>> the ZRTP protocol is designed to be deployable in the real world, >>> a requirement is that it not require additional NAT bindings - >>> this is a major obstacle today to the deployment of RTCP. >> >> I'm not sure I believe that argument. The complexity comes from >> implementing ICE to open any ports. Once you have an ICE >> implementation, running it again to open an RTCP port is not an >> issue. Also, as I described, there are deployment issues with ZRTP >> as currently specified. >> > Your deployment issues with ZRTP are theoretical - ZRTP is a > deployed protocol on the Internet today and has been tested at a > SIPit against all UAs - things are not broken. I'm not saying ZRTP > will work in every RTP application - some where there is tight > coupling between the transport an application layers there may be > problems - but ZRTP isn't designed for every environment - it is > designed to provide badly needed security for Internet VoIP and > multimedia. If you only test against point-to-point implementations on an Ethernet, they're theoretical issues. RTP is used in many more environments than that, however, and your lack of testing in those environments will not make them go away, nor does it mean you can ignore them in drafts submitted to AVT. >>> Another requirement of ZRTP is that it not be dependent on the >>> signaling channel. >> >> That's not possible: RTP requires there be an out-of-band >> signalling channel to negotiate payload formats, etc. I assume you >> mean there is a requirement that the security is not dependent on >> the signalling, but that is independent of the use of RTCP to >> convey ZRTP messages. >> >>> It can use the signaling channel as an additional out-of-band >>> discovery and authentication channel, but it can not have any >>> dependency. So, if your draft defining the multiplexing of RTCP >>> on RTP ports is adopted as a Working Group item, and there are no >>> additional requirements for signaling, then ZRTP should be able >>> to make use of RTCP transport. We will investigate this in the >>> next version of the draft as this topic develops. >> >> My draft has already been adopted as an AVT work item. It does >> require some signalling support, using the a=rtcp: attribute, but >> that attribute is also required for ICE to work. [Note, also, that >> sending ZRTP-in-RTCP on the RTP port without signalling is vastly >> preferable to using an RTP header extension to send ZRTP messages, >> since it keeps control information out of the data packets]. >> >>> And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on >>> 6/23/06 you emailed to the list that it does not affect ZRTP's >>> use of header extensions. >> >> The issue is that only one header extension can be present in RTP >> packets. If you use ZRTP, you cannot use hdrext, and vice-versa. >> Using RTCP to convey the ZRTP messages would remove that constraint. >> > There is never a case when another header extension will be present > in a no-op RTP packet *generated* by a ZRTP endpoint. ZRTP never > inserts a header extension in an RTP packet carrying media, so it > will never try to insert one where there is already one present. > There is no conflict between ZRTP and draft-ietf-avt-rtp- > hdrext-06.txt. Of course there is a conflict - you've just decided it doesn't matter for your current use cases. That said, the conflict with rtp-hdrext is the least of the problems with ZRTP, as currently specified. I like ZRTP as an idea. I think it provides great security features. However, the way that idea is implemented as an RTP header extension is fundamentally broken. Build it using RTCP multiplexed on the same port: sending an RTCP format packet containing a ZRTP message is no more complex than sending an RTP No-op packet containing the same message, it is no harder to deploy, does not lose any of the security properties you care about, makes it easier to de-couple security association setup from the media, and avoids all of the problems I'm discussing. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From aapvkgya@philnet.com Fri Oct 27 14:54:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWqH-0000BG-3P for avt-archive@lists.ietf.org; Fri, 27 Oct 2006 14:54:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdWqG-0000hk-Vn for avt-archive@lists.ietf.org; Fri, 27 Oct 2006 14:54:09 -0400 Received: from pd9546a98.dip0.t-ipconnect.de ([217.84.106.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdWqB-00066o-4O for avt-archive@lists.ietf.org; Fri, 27 Oct 2006 14:54:08 -0400 Message-ID: <000c01c6f9f9$93f70450$986a54d9@hartmut1> From: "Mobile Handset" To: avt-archive@lists.ietf.org Subject: Column Special Date: Fri, 27 Oct 2006 20:56:15 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C6FA0A.577FD450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 ------=_NextPart_000_0008_01C6FA0A.577FD450 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C6FA0A.577FD450" ------=_NextPart_001_0009_01C6FA0A.577FD450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Industrial Control Systems tv of Audio Mobile Handset a Techonline a dsp = Japan Asia in China is France Germany or India Korea! You do not approve = or of being displayed grounds please in send of? Industrial Control Systems tv of Audio Mobile Handset a Techonline a dsp = Japan Asia in China is France Germany or India Korea! Not approve of is being displayed grounds please send Email a Jason = indicating which pictures will take. Gallery or Csct Viewed is times wxh Size k am vho Fcsvt ffb am timeswxh = in xsize kviewed or faf Powered by Gallery var a make is no of claim = to. Copyright of these images unless or otherwise stated and a only = present them as public. Class Program name message string message wrote Note Main of both = Program public now. An utility complex piece in software developing just be thin that of = delegates work or testable or already exist even so in some benefit from = of testing once consider task parsing command is line arguments involve. Careful signal Ejetcom came us series in features they adding more = hardware or said handle sound effects am affecting echo dualtone am. Feedback ee Times Latest of Loring Wirbel Times is in est Colorado = Springs Colo of Octasic Incs Chinabased developer voice server led oct = telephony. ------=_NextPart_001_0009_01C6FA0A.577FD450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Industrial Control = Systems tv of Audio=20 Mobile Handset a Techonline a dsp Japan Asia in China is France Germany = or India=20 Korea! You do not approve or of being displayed grounds please in send=20 of?
Industrial Control Systems tv of Audio Mobile Handset a = Techonline a dsp=20 Japan Asia in China is France Germany or India Korea!
3D"stated"
Not approve of is being displayed = grounds please=20 send Email a Jason indicating which pictures will take.
Gallery or = Csct=20 Viewed is times wxh Size k am vho Fcsvt ffb am timeswxh in xsize kviewed = or faf=20 Powered by Gallery var a make is no of claim to. Copyright of these = images=20 unless or otherwise stated and a only present them as public.
Class = Program=20 name message string message wrote Note Main of both Program public = now.
An=20 utility complex piece in software developing just be thin that of = delegates work=20 or testable or already exist even so in some benefit from of testing = once=20 consider task parsing command is line arguments involve.
Careful = signal=20 Ejetcom came us series in features they adding more hardware or said = handle=20 sound effects am affecting echo dualtone am.
Feedback ee Times Latest = of=20 Loring Wirbel Times is in est Colorado Springs Colo of Octasic Incs = Chinabased=20 developer voice server led oct telephony.
------=_NextPart_001_0009_01C6FA0A.577FD450-- ------=_NextPart_000_0008_01C6FA0A.577FD450 Content-Type: image/gif; name="where.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c6f9f9$93f70450$986a54d9@hartmut1> R0lGODlhxAE4AYcJAAoJC4ABAACOAIN5AAAAfIsHegB7jsK/y8jZzqDS4j0uBVslAIUpDZIhC7sl Ad4qDQYyABlBAEAyAFMyAII1AKwzAM1FA9QxAgxhAS5aBj5pDV5dAIVYDKtXCMtYAuRnAgOOACCB AEyFAFSJAH+NApt2ALaGA9F1AACcABGbDEqiBWWTAHaUCaipAMetB+mTAAy9BReyBUG5BVbCCny+ AJ+9BsmzBtPHDQLnAyLsADPlAF/XAHXYAJrYBr/YAOngCAUASh4LQUMCS18AOYgBNq4EO7oGRtkA TAAuMygaQkcsNlQeP4whNqEePrggNdcaTQBMQixNSjVON1UxOnxARZo5RLM3Qug2NwBrRhFqMUpZ P2hoSIRmAKpWSb9rTdtiOwCNOx51PzZ7TlZ/RIVxQZ+NQciFM9R5NwCrPSeiTjSaTmOsRX6eRJaq OM2fQd2gNg2+RCWyTDe7NWO4Ooy7PZ+4N8SzRtTOPgrVOCvaPTrpPGbiQovhQKzbP7fZQt7tMwAA gyAIfTwAclwAeooAiakJessMe9MDcg0ecyAYfUAZclkrhHEscpgriMofcuAahQYzjihKcko5d2U4 cYA8fphLi8hGeehNfQ1dgBlqf0JkdmNhdndjf6Zkh8pSdORacQeEhiaLhjN7eGeHinaHg5R1fbqE iuKCiACfghSmfzakeViZfIiteK2rg8qfce2tegDJdB/DeDe9glTIi3G7f5TGdLWzet20hADThibZ hz7fdGzSh4zgeZLedr/Wh+bRfAABti0AwDoAumIMuY0Ou6cHxLcAxesAwAAfuRQltU4bwWYcyH8a upkoy8USst4atwBKzS07vUUzsVhAzX86zqk8wMk0wNxBugBUyhditDtSulRmvoxmuqBlzbJVsetu wwCHyRWOyzeDwGWNsoKOzZZ/y7R9x9KKsgaevx2Rxj2gyVGoyYijwKyRurKVstSsxAC9yRvNtka5 x2zOxHnEzpa/x/f/76ygnYN0jfUABgD7Dv//AAwA8voH/wD/////+SH5BACu7IgALAAAAADEATgB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MixY8R/IEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSP95XMq0qdOnUKNKnUq1KsJnH5Nq3cq1q9evYMPq tEq2rNmzaNOqXcu2rVuC0N7KnUt3IIC6ePPq3cu3b0YAd/0+xYmgsOHDiBMrXsy4sePHkCNLnky5 smXHYlE2y2wSMOfPLi+LHk26tOnTqCGDXr3SM+vXI08HSE27tu3bpWHrLul6d0+Nsw8HRxCg+PDh hYPPRk6cuPHiiZ8nf76cunPhiI07ty5c+nbt3L8b//b+HTr28+KTZ4+uHX3z8+0F9wUsXyPh4+Ph r2/OfHlj5P7t15176hGYX37MveeecgcmKCB+DQpY4IQBUmihbxiO1FuGNWmkIIPr9ffghIolaGJ0 H6JoIIkVHugighH+FyN2Iq7IH3on1icYfTpORNiNJKpXo4sgLnaihEK+GKSDCgJJ4IkQMkmjkk4u aWSTVebHYWabuLThli55yCKKQ1pYnontUVeddCAeSeV0aVonJ5ntnXkllS1imV6KBprX45+AMvRj k1Ai6aSUZKqIo55lLsiooQFC6BiAidpYoKRWGgbmppxq9WKhffIJWZ6PJokkk5S6GeShq5YYaqP7 hf+XaWGd1mrrSWJiSamZIb75aakLqqrnmMISaiaiSu4q6q9lIhros9AONCia5o1XraJ2Zhcnm3Na q62y35qn5rDkpSprn3XCaWSaEpZ567vw5orbvPTWay9p0eYL6KD39uvvv/7CW1Q3OwEGgMD8Aqzw wqIhHFI6Dudk8MEOy8vwxRg/pu/GG03MsUcZF5ZPyCQf9vHJEXmMMkE4jXyYywjkIzPMMIu8WM0z x4yzzTP3nJjPOvvcs8w6v4wY0YbRnLPIQ49cc8xBF5100ktDjUDEWMNEcdZAWe31zl7b/HPYLiMt NthjT/102Ewb/TLYaIst99ltT0222FznrTdXX8//zfPRijnttuB+F1742oj3bTTNbN9tt91l9702 3ntXbjlKYhLeuOaGcx4542mH/vjof/utOedzx23152rfXNjKsMeelU2jJ/504nJHvnrgjAHddNA5 63473bin/vvuuyut++XMNw9SrqpDPTzguVc/+eRjF/846oyj7rjpdP89vcuCoSP7+RlpwfJNtWdP /dtV6y497495Xzz3rWuvuvD5U++y8wAMYExIhzbQuQ1yxqOf6Oy3wOnVbX8HDB/O5Mc2AVrwgigh HfCOZrYISo9oE1Tgz5b2uxK+7X1S2yAKhxe8EzKNhLTCoAxnWLIalmyGOLygDXeIsRz68IdADKIQ /4f4GRAQ8YhI/Az6lsjEqcihiVCMohSnSMUqWvGKWPxYErfIxS568YtbegUYf5PFMppRX/rgyxjX yEbnnRFQ2nijHPXSxjra8Y54jEk98sjHPvrxj52aoyAHSchCGvKQiEykIhfJyEY68pEoA6QkJ5kZ RSYAkpjMpCY3eRAucPKToAylKEdJylKa8pSoPAslV8lKraTylbCMpSxnScta2hKSBHjKIW7Jy74k jIe0OUluTALMYhrzmKjBEDKDSUzSCHOZ0IymNBNDFItN0zIJKU02r8lNxXxAMt/s5mnCiQCpiORL LSnMxDIGmMMAIDXPHM0zP0BPciKgnuS05z3xaf8Yeh7Gn/38Zz0DStB++hOghfkmPvOJmHDyc58L hWg+DxpRiS7Gng9NaEEvk9GFIjSjAgVoRe/5T4g29KEYJWg1DWYRBLyzZO00zEtPs83RZDOlJCWo PnGK0H0GlKEazalQS+rTnxJ1p0PFaVCF6tDEKJWoSS2oPinz1KFataEl5alUnZrVjYZTKoG5yEzd aTB1lrWsLnVpTNX60neidaZjTStczdrWs651nep8HUK0iZCpXlWhWO1qUxkK1Jw21ZsaJSxWkerX pTJVp1xtTGF/OlCFfnSgJEVqYB3r18NuNrGcjSxo/1pOvsQ1rTJFrWrdOld3qjW1rYVtal0bW7f/ uha1NRVNQjrLVc0adbBGXSpwLzrazC72uMTdalCn2ljlHtWgwU0sc0Ub1cjyVrCfDS1guTqfxIzV tnnN63cRA97wlne2bSXvamU7W8Pk9jK7Neh2uwpV0A4XqB1trmGXa9X5LhezXgWwYSsKUudCVrv0 zW51HSvayi52up+1LHG7q172rne8bD1vek8717q2s7YZXqteD8LXgzC2t9ndrkiFy9/iWve3yN1o aA/cYsZAmLSPpSw/r1vfqqa4v8atb0JRelWSmvMmHKZtezV84dueN7xybTKUn4yYeDbMJCeOMYNV fFgCH7ixngVslmW84BzvV7INfjGCFYzjGSc3/7qj9TGEp1vNjKgWylGe8p3Ly2Q8t/e1HV7ynsP7 XmzuVas0nvF0xxxmxCbVv4X1bJkjzeAyu9nMKc30m4EsZDMHucaUbjNSj0y7DNM1vXqeGFzPets7 /zmm6wSxqcNr5cvMM7+XrWxHUZzgT/f3oAKV6E57WuCnWvbYmC1wgHvqU54m28YCrjSR5UtRAGd6 xW3OcZ0xUprTSsbb9Cp0ZcQtTmnqt9y4+WpUflkZcD/G3fOqtWXkjW5z17tf5Nx2L/fN7377ey0C +LfAB77IL0ykDwRPeCmHofCG+6WVEI+4xG1FjIn70eEYh2QrpGXxjns8JhkPuchHTvKSm/zkKP9P ucpXzvK1sLte9J5mzOf98eb9IDMKm3k0dU6ZmnucNPD+89WaWW6eT8bnXkGn5WY9maD72ejIfKYA pi6AwlB96oapetYRQPWhI70rBsuQRjD8bcjEldzSzKbWrc71w2h97XAfccshoguC8Eh2SRavXTd8 17cSeq/oTsja3Y6Yqr+d8KWdu1jvjrK85/nCgWbvS9EeTcErZvBtN3zh5a74xYeVY0wHL4jHS3rE UB6alrc61jFveMy3PfGdH/vn81Vh0Qu69BbmPEHqnfqtsz7zm4d97GU/e7QkbMN6Fq+Sc+91ktT7 JL+PPtu33vyvw2ZrXhl7q2X9+O7bXvi7D/z/XgeveerHffrDXxlh8Jp8yKN11qiG+jGlfnWu13/6 bO+69btoTaGn5vTLBICSUUrzAEov53TyRHTiJH+qsX8QVxsMeG8ReHQO6EcQqID3hhkYmEwV2EcX WBIZGBnxpA3w1IFgYgQ/QXwi5meQIYAhWFMkiBgxKIPaUIM1WBg2GIPpBy04QXZXBoIh+BjPZIOG QYSJMYNFeBgkaII5pH2yJXpv9X6TB3hB2BjZRIJYqISKgYQ4qIU7eEWkh3ythlpTSGJVaIV7lYUy uIU52IVJ+IWB0oPL132DdhgTiG5DyIUIoIdHuIdayIQ4pIKoRoeqdnZUeIaKAYNcyIdriIQk/wiH VeR4TwZvLpiBMOiHSegYatiFkEhFkuhqGFaGBoGIjHGFfuiIWoiJXYiKndgjclhhZBiFdxVDQEiK 1NRMRriHbaiKu6iLN1h9gChA/Ycvh2iL7kWFjAhfregQZ+AWL5eAtWiMmkJ0yUhzwXiN2JiN2riN 3IgTy/iNf9KN4jiO5FiOGAKO6Cgf5riOREQXv5CO8BiP8jiP9FiP9mhy7JiPQHSP/Gh8+viPMzSM 0jiQBFmKAveMBZmQCcmEAgkZ52YaDzlkNvYvEVlkPHRjlUYbFTkVWJFIODFSaJaRGumQjmaR6RaS 2VYyGGmS4ISSQwZUDJkRPpZm9BKRPFaRqP+hX5NlTCuJkxN5UR8VWemnaVvmYNYWbS85WLnGbBbV lEmZWUtJkwMWlZ5mUcf2X8z1bEfJlE05bXFWbCb1lE4lUkgpZkWmbrFHlKKmWDJ2bXDmW2e2WUFZ VZSmlkF2k4oFZlnFllsWYVEFaSf1lj+plxNlbbq3bx+5azfZa3AJmHT5XFLpa4t2l4zpa1ClaXop mI/ZY39paXbZXJIWmIpGiwAZElq1mDoWbR7VmW0JmXK5l8pmlg4VUavJlSwWXEz5mcIGl6xpX0J2 bbH5bNA2msAIkKdZknZJXWvWl4lmYP6FWGaZkpbpnJ5ZmTrpl5j5m71Gk9cJmDkVkwVRDhL/oVSZ 2Zuc5mLzxWyI9pqCKZW6GZq3iZ7YWZnaGV3ANlHz2Zo1dlzeeYz/lpgCBpreqWxdeVTAdlJB6U0D ipTx6ZRe2VmOGZYIKmmzyZUotZV3eaDUVpgQelkKyqEqZYIC6ZMKWaIqGRkD93IkaqIsijEVuUp2 UJoyyn/9WKNMUQUJsUrtMKOUZKM+OhU8GqSX429q8KPoI6RIqjdGuqRNkaRO+qRQCohMOqUdEaVW eqVYOnGtWIBU2qVe+qVgukRZOqZiJ0tKEKZHSqZquqZs+kVo+qYN0aZyOqd02oTyYQFwahZe4JF1 ShS80KcjkaeCOqiEWqiGmqPs06LMBKh1/6Soi8qobOSoJQipwmhnCMAPmMoPhZGpmGoYmuqpl9qp hyGqmxqqnHqpo5qqqgqqnEqqqOqpp1qqo9qprqqprfqp/nmoVvSqpYqrr4qrwJoYtcqroFqssmqs vboYtoqsn+qrsjqszmp6g1p8+3IT0UqsqNqsq8qq3CqsyYqt2LqsiiGu4Qqu2hqs1/qplNoSSlcr GpGuiLGszhqt5Equqiqu9Bqv4Pqt5Zqv2dqt+gp+Xsp4ZQSstKqvrnqsxXqurfqsvyqst2qqmXqs 2pqq/lqxttqwJhOmBKsvODGv/VquAfuv8Iqu3mqx47qwCHuyJnut07iuJNGuPgSyNKuw/v9Ksspq sCmLshA7sSEbsC3bGDCrIdjHNR7iq/Zasbx6s6G6ryI7svyKrP+qskA7q/v6qVTasYK0qaeqscSa sSALqxJLqmELtdnasDQbq2Nrql8Ltj6LtfUYCwmhtepXEwPwD5LKgZAqs0eUt6cxtGPkt4I7uAVZ K4R7uIhbhVzRkMu0gomLGk6HgIILbpJLjD1yGarWboqRuWYHdKfhbZRLVpkbV6T7bpEhYlTGgnXo GO4Gb5Xrf/3CfrA4u52ruosBKJg7GqA7hozxuvOyu97laqvrZ5F7uj4YvMhruzLluLCrfI1ruptL Gb57mH6Ru8vHfntXuujld6z1Ydxrat//K4WyS1enRrvOy7ux5X+y6GFJFnmjy1blK7qL8V3ey7x8 Br9yBWvrBX+x6GHKl77Cy7/8+734G2vx273U2xfWu7x4NonRm3ushV60NYiBNovH62QPrF6O137N S4avpsFPOMESbL6wqL3Ru2qwVcEQ/FoBnL8cLLylF4YpjLyRp3epNXY+kqjtZsANDIoZ7H11iHv7 G2VC3MIenLyChr7q27scrL3IV8SD2MEvHLrmNYd59n3nG7pFzIIxbMWpS8GDNl6La6mau31OBsCn xr4fhsEWNnphzLsCbL4A3L4/fMDLO74qDMWqy7wNjMbJp8diWIh7tmprzHww/L6CDMV+/3e+QKxK Oiy9JTyGUbzEsxvF95tqbyx0rQW8oruCdIzE++vHtwfEocjEdXzE3oVXgOy8G5zFmQzHnyzJQwzG ejzG3Da9JuyDk8zFXtzD3GdbQuzJI0y7JgzDAZzLTVzJwMzApTy/zlx7dcxkwfzBsezA0axkq/zH KzxeuIvLygxrqFvMd2zJ49x+Kry9VIa9pMvDHwzK48y+DMx0rwaFy7xk9Au6sRbOxPzKj3fPFNx3 hdzBqrzIA73I8QtodnzDZoGQk+u301uQDx0ytnwRjzu+JWrRDd1Njlxqj9vRhCtxHh3Sgkuj3CYa VHxNqUsbEU28K81O4pdKp1zOJx3Tuv8Lvc2b0qkRdBiNxZDcbe9H08prduvLxwetzuEsioTEbjPd wq4LMOJsyLXR1I1xwbELx1K80ltsyozcZ3FF0hXBA/ZQwD9tzDHsuMUMzAAdvAi8zwMsZaEsvgBN 1Pj8xNn7vwVMvj19xvULz/lLyGLozA8tzVacwKLExnIcxnNcySzswyJMvCAcwjVcw6Rs1UFdz+QM zsznu7GcxDa81YsN2BgN2L3MuYjEL7tM1r2sxCusxMdbiIL918t82akN1ERcxW082Jqt1smbzYwc 0wgo2yt8FEbkrnamyqcs2Jqs2KE41n2W3F3cz7XNz83tzuB7xNMsecxdv4f9idv8vvP/u9SpTM29 DEubfNzSzdaendit/dh2Dd2WPdqUbcztDdxvLMpabcjpi9yULdXPLN4rXNpINsz7jMLrvX36XboF vs1DbM7wbVZ7HMnfd93tbcT3vcv5fd6c3M6tjOGu5dUtpc6by2rw271mXdBALM8nntxt7dh9HNd3 jMrktb5XXM4LTs+B/dMgDn9GfdqCHHqpXNB+TeOw5NEtXbsi7bm4AeAcjbhFbtNHbtL0ArhSrqW6 mqdaUQZTnqUWIQ1V3uUSYQJeXnJZPuZkjqWuzbc6gQthYhBCEOapdOa+VOZyzhJuHqZzfucpUed6 vufxiOdGQQ9+HuiCPuiEXuhYyudd/8pFjmDodmQCjA6oiB7pkj7plF7phmQOlp7pmr7pGOcbaP7o HucXKsPposTQT37qqN4vScG4qd7qrl4bZGHqrz7rtG5rYFIYh5Drh4Drur7ruH4Yu67riCHsCNDr idHrwu7rhhHsyD7szq7svN7syQ7tuQ7swI7szG7sw07s2K7s2r7syW7t187s4g7u0v7szT7u027t 3V7s0k7s7p7uv27u7s7u1J7t677s8f7t0V7v+i7v0F7s0e7r7f7tAU/wpJkhAv/v4u7t+n7s8x7x zv7wDM8YB7/wEN/w917x5Y7xikHtHe/xDl/uAT/v1U7xEy/xAl/yIe/vEg/yKX/xz/+u8fZ+7R7P 6x3P8iYP8jB/8TD/8hQ/8gu/JRzwDyzv80Cf8Tqf8jcf7I2B9B8/8U6/8hyP8kt/8zkP8SWP8FFP 9Spv9TNv8VoP9igf8TLP7g2P8U6P8FOP9knf9W3f9r8O9V1v9kH/8KueEUc/82ef9o/x83P/9GGf 8Q8/9XGP9YBP+Iq/9YiP9YWv9ouR+HKv+IH/9o2v8ozf85Bv+F7v9iIv9p0/+aLv+G/P8+Ie6zfh 7dXu84xP+PzO9AUv75hP+jLP+Vzf9Op+8uoO+2O/7YK/8LcP+9i+77o/8Ktv8jn/7sU/+3YP/IHP 9sTP+Z8f+cjf+ZVf+PD+8tnP/Jv/QvfPz/Rl//WWb/2UP/llz/Unf/t9f/W8H/7mb/6Pf/3tX/WU v/lZL/Xlf/f2T/DQH/PTDxAIBA5EcEigwYMFFRI0iHCgw4cMJS6cGBHBP4wZNW7k2NFjR3shRY4k WZIkRIUoGya0SJBiRZcQVb50SXNlTZssDyHkuXNnTJg4YcqseXMiSosOjQJtmRBpUIpLiTLNydCn UpYpF/7USlWq0K0Rl3ZtmvUl1qAITa5l29bt27dn5UYtqxOq2ZlPK/IUOpMmWbx3m04dXBYtU5l6 CTsF+zfx0KKG09p9OBYw3sWIrc6ly5mz35pwRY+299F0x4NXC6oO7DMmV9Y4Mze8//rUderbmC2P XVwbaWyzuFW6nv3zsezJvl+rPq6bOGTJzys7Xs18c13cZ2nnzl6Za2HwFk+PJw+SNNvG6dWvZ9/e /Xv48eXPp1/f/n38+fXTP99/bfnx9hNwQAILNPBABBNUcEGwAHRwPP9MYnBCCitkL0IMM9RwQw47 9PBDED20cEQSRwzxRBRTVHFFFlscqUQYY0TQRRprtPFGHEV68KPehlJOuKqW6yk3orgD0rvfrPqu KCIzOxLJ6oA78keEdrTySiyz1HJLLrv08ksre2SMquBAK2yqw5JMCrI0kUvKScIU6wsqvi4C8048 89RzTz77PC2sOseEbrK78gqMzP/g6GoTUa0OS9Qy7CLbSyA/K7X0Ukwz5RPQ1iR9FFHbgOLN07qw WpROsswUlFSwQKtSU1gxqiBWWmt9sENOOwvSsR9bkk4sNYX8tDMpP61T1csEI5SlHJt19llob0xV VzODLVNUbJHFVjPKQt32siT1+us66KI191x00z0vtemQrJZVVUcNdFyJ1KwtK2sFHfVbVgtlSl2A AxZ4wy6vNfhghDtdE19S55132oYxizhRiunVy1aMM9Z44ywPfldYbe+9t7Uln4wyukKJJFfJ4ZZU bGQ1OeZYAJlrvhNXGXPWGb+Be/b55/+43HloouGz+Wikk1Z6aaabdvppqL0Eemr/qqu2+mqss9Z6 a6679vprsMMWe2yyyzb7bLTTzjFqttt2+22445Z7brrrtntPtfPWe2++37r7b8ADF3xwwgs3/PC2 +1Z8ccbNRvzxB5OAfHK4G6+xh56TsDxtVjb3vGvNPxd9dNKfDb101FNX/cTTV3e9Rspjx2gSjCSX /faoXze7dd1fl6R34IMX3kXcizf+eKSHV77FVZa3GvmM14B+etmdt/567LPXfnuBqff+e/DDF3/8 mgEwnvsIY0C/bADOC2d9+OM3t33567d/YPrv1//GJfYfnXwABlCAAyRgAb/nv4C1A4HZM2ADHfhA CEZQgkdr3AEWeEEMZlCDG+RgBAfhFxAAOw== ------=_NextPart_000_0008_01C6FA0A.577FD450-- From avt-bounces@ietf.org Fri Oct 27 20:43:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdcHM-0006DS-7F; Fri, 27 Oct 2006 20:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdcHK-0006DN-NR for avt@ietf.org; Fri, 27 Oct 2006 20:42:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdcHJ-0000lG-E9 for avt@ietf.org; Fri, 27 Oct 2006 20:42:26 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 17:42:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9S0gOs6007695; Fri, 27 Oct 2006 17:42:24 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9S0gNAo023460; Fri, 27 Oct 2006 17:42:24 -0700 (PDT) From: "Dan Wing" To: "'Colin Perkins'" Subject: RE: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Fri, 27 Oct 2006 17:42:21 -0700 Message-ID: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <59E0C07E-4940-47E4-9BB0-AD58A2073A18@csperkins.org> Thread-Index: Acb55ZDfMOaecQFDRgyfrskQ2kH/DQAQ5J4Q DKIM-Signature: a=rsa-sha1; q=dns; l=1915; t=1161996144; x=1162860144; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[AVT]=20[Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-02.tx t]; X=v=3Dcisco.com=3B=20h=3DE7772b17nmHZXaw28YrXruNb3bA=3D; b=c5uubPEJI0bvFuK0sMF4JptYddY7UssDR+oHVlsW57a8AGnWegshIqgRtpHzh2beODFyhcEe rc9IXaK7jBEiy4ofvQDVvt9hXUmngQFU2XXUmNwMogZDJCq9+NJJ2NlT; Authentication-Results: sj-dkim-4.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org > > Real world implementations are not nearly so brittle with respect > > to SSRC as you suggest. If they were, common scenarios such as > > forwarding, retargeting, forking, IVRs, etc would all cause these > > implementations to break. Especially at the start of a > > session, it is *very* common to get RTP from multiple SSRC and > > all implementations deal with this today. > > Of course they get RTP with multiple SSRCs from different devices, > that is why there is an SSRC: it lets the receiver distinguish the > different devices that are sending it media. However, that's not the > same as using several SSRCs for the same source, which is what you > propose in the ZRTP draft. Using different SSRC values for the same > source only works if the receiver assumes a point to point session. > It will not work if there are multiple active senders, since > it gives no way to associate ZRTP packets with particular senders. Right -- like forking to multiple ZRTP answerers. RTP is not supposed to care about the source transport address of a packet, but ZRTP must be using the source transport address to associate the two SSRCs with each other. ... > I like ZRTP as an idea. I think it provides great security > features. However, the way that idea is implemented as an RTP > header extension is fundamentally broken. Build it using RTCP > multiplexed on the same port: sending an RTCP format packet > containing a ZRTP message is no more complex than sending an RTP > No-op packet containing the same message, it is no harder to deploy, > does not lose any of the security properties you care about, makes > it easier to de-couple security association setup from the media, > and avoids all of the problems I'm discussing. Colin, what of the RTCP transmit limits that Alan was concerned about (in Alan's other reply to Dave Oran)? -d _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sat Oct 28 02:54:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdi45-0008TJ-Pf; Sat, 28 Oct 2006 02:53:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdi43-0008Ah-Mv for avt@ietf.org; Sat, 28 Oct 2006 02:53:07 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdi42-00063M-BH for avt@ietf.org; Sat, 28 Oct 2006 02:53:07 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61668 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Gdi3m-0003vA-12; Sat, 28 Oct 2006 07:52:50 +0100 In-Reply-To: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Sat, 28 Oct 2006 07:52:45 +0100 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 28 Oct 2006, at 01:42, Dan Wing wrote: > ... >> I like ZRTP as an idea. I think it provides great security >> features. However, the way that idea is implemented as an RTP >> header extension is fundamentally broken. Build it using RTCP >> multiplexed on the same port: sending an RTCP format packet >> containing a ZRTP message is no more complex than sending an RTP >> No-op packet containing the same message, it is no harder to deploy, >> does not lose any of the security properties you care about, makes >> it easier to de-couple security association setup from the media, >> and avoids all of the problems I'm discussing. > > Colin, what of the RTCP transmit limits that Alan was concerned > about (in Alan's other reply to Dave Oran)? RFC 3550 allows you to send the first RTCP packet immediately for unicast sessions. When coupled with AVPF, that should get an initial handshake without violating any of the timing rules. If that's not sufficient, then a change to the RTCP timing to allow ZRTP would be much less of a concern than piggybacking control in RTP header extensions. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sat Oct 28 03:53:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdj01-00050u-NO; Sat, 28 Oct 2006 03:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdj00-00050o-SF for avt@ietf.org; Sat, 28 Oct 2006 03:53:00 -0400 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdizy-0001Ut-L5 for avt@ietf.org; Sat, 28 Oct 2006 03:53:00 -0400 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Oct 2006 03:52:58 -0400 To: Michael Johas Teener Subject: Re: [AVT] Re: Layer 2 synchronization and clock References: From: Randell Jesup Date: Sat, 28 Oct 2006 03:52:57 -0400 In-Reply-To: (Michael Johas Teener's message of "Thu, 26 Oct 2006 17:52:33 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 28 Oct 2006 07:52:58.0421 (UTC) FILETIME=[15B1A650:01C6FA66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF AV Transport WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Michael Johas Teener writes: >All that is being done is to move some timing and QoS services closer to the >network layer so that they can be easily built into the hardware for >Ethernet/WiFi NICs and switches. The result is lower latency and (probably) >lower cost. Ok, if this is a replacement for NTP that's fine, though requiring anything of network elements needs a really good reason, and it'd better be cheap, easy to do and not get wrong, and give some sort of benefit outside the very limited space mentioned here if you want hardware vendors to implement it in enough equipment for this to be really useful to you. Targeting a "better NTP" might be a good start. I would suggest trying very hard to make your idea work without special support in hubs/switches/routers if at all possible. If it must be there, KISS. :-) What bothers me the most is the "insert time in the network stack" part. a) latency from sample to stack is rarely fixed except in the most special-purpose hardware. b) the more I hear the more I think you want to get the true sampling time for a set of samples. This is really a hardware and system issue; it's not a network or protocol issue. IMHO -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sat Oct 28 09:41:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdoPl-0003Fp-88; Sat, 28 Oct 2006 09:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdoPd-00039m-OR for avt@ietf.org; Sat, 28 Oct 2006 09:39:50 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdoMT-0002uk-Li for avt@ietf.org; Sat, 28 Oct 2006 09:36:35 -0400 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1GdoMQ-000OGF-Cd; Sat, 28 Oct 2006 09:36:32 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <45435CD4.8080702@sipstation.com> Date: Sat, 28 Oct 2006 08:36:20 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> In-Reply-To: <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins wrote: > On 28 Oct 2006, at 01:42, Dan Wing wrote: >> ... >>> I like ZRTP as an idea. I think it provides great security >>> features. However, the way that idea is implemented as an RTP >>> header extension is fundamentally broken. Build it using RTCP >>> multiplexed on the same port: sending an RTCP format packet >>> containing a ZRTP message is no more complex than sending an RTP >>> No-op packet containing the same message, it is no harder to deploy, >>> does not lose any of the security properties you care about, makes >>> it easier to de-couple security association setup from the media, >>> and avoids all of the problems I'm discussing. >> >> Colin, what of the RTCP transmit limits that Alan was concerned >> about (in Alan's other reply to Dave Oran)? > > RFC 3550 allows you to send the first RTCP packet immediately for > unicast sessions. When coupled with AVPF, that should get an initial > handshake without violating any of the timing rules. If that's not > sufficient, then a change to the RTCP timing to allow ZRTP would be > much less of a concern than piggybacking control in RTP header > extensions. > We are still reading up on RTCP - somehow I failed to notice the progress of Colin's RTP/RTCP multiplex draft but here are some initial thoughts. ZRTP at an absolute minimum requires 4 messages to be exchanged. With the packet loss that we commonly observer at the start of a media session, there are often a few retransmissions as well. The ZRTP exchange totals about 11.7k bits and needs to complete in about a second. We could optimize this a little, but DH public values are large. RFC 4585 talks about 1,600 bits per second for RTCP in each direction for a 64 kb/s audio session. So to complete a ZRTP exchange in a timely fashion, we'd need to utilize at least 20% of the stream bandwidth and send 4 or more RTCP messages in the first second of the media stream. Thanks, Alan > Colin > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From akstcbaehalmnsdgs@baehal.com Sat Oct 28 09:52:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdobX-0007Xg-L4 for avt-archive@lists.ietf.org; Sat, 28 Oct 2006 09:52:07 -0400 Received: from [211.58.236.235] (helo=daxpc07ho1o4wn7.hananet.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdobW-0006QH-7n for avt-archive@lists.ietf.org; Sat, 28 Oct 2006 09:52:07 -0400 Received: from 203.124.230.11 (HELO mummail3.tatanova.com) by lists.ietf.org with esmtp (O8G0ACIL 9BP8KC) id IL6AY5-4GHE39-VG for avt-archive@lists.ietf.org; Sat, 28 Nov 2006 13:51:47 -0540 Date: Sat, 28 Nov 2006 13:51:47 -0540 From: "Cornelius Flowers" X-Mailer: The Bat! (v3.5) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <228301484.49063695811540@thebat.net> To: avt-archive@lists.ietf.org Subject: paper-thick middle-sized MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Spam-Score: 4.1 (++++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 believe, did a great deal to it when mr. collins first came to hunsford." From avt-bounces@ietf.org Sat Oct 28 09:59:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdohj-0005SV-Hw; Sat, 28 Oct 2006 09:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdohh-0005SQ-UE for avt@ietf.org; Sat, 28 Oct 2006 09:58:29 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdohf-0007eT-R9 for avt@ietf.org; Sat, 28 Oct 2006 09:58:29 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62675 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Gdohe-0002YR-Rs; Sat, 28 Oct 2006 14:58:27 +0100 In-Reply-To: <45435CD4.8080702@sipstation.com> References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Sat, 28 Oct 2006 14:58:20 +0100 To: Alan Johnston X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 28 Oct 2006, at 14:36, Alan Johnston wrote: > Colin Perkins wrote: >> On 28 Oct 2006, at 01:42, Dan Wing wrote: >>> ... >>>> I like ZRTP as an idea. I think it provides great security >>>> features. However, the way that idea is implemented as an RTP >>>> header extension is fundamentally broken. Build it using RTCP >>>> multiplexed on the same port: sending an RTCP format packet >>>> containing a ZRTP message is no more complex than sending an RTP >>>> No-op packet containing the same message, it is no harder to >>>> deploy, >>>> does not lose any of the security properties you care about, makes >>>> it easier to de-couple security association setup from the media, >>>> and avoids all of the problems I'm discussing. >>> >>> Colin, what of the RTCP transmit limits that Alan was concerned >>> about (in Alan's other reply to Dave Oran)? >> >> RFC 3550 allows you to send the first RTCP packet immediately for >> unicast sessions. When coupled with AVPF, that should get an >> initial handshake without violating any of the timing rules. If >> that's not sufficient, then a change to the RTCP timing to allow >> ZRTP would be much less of a concern than piggybacking control in >> RTP header extensions. >> > We are still reading up on RTCP - somehow I failed to notice the > progress of Colin's RTP/RTCP multiplex draft but here are some > initial thoughts. > > ZRTP at an absolute minimum requires 4 messages to be exchanged. > With the packet loss that we commonly observer at the start of a > media session, there are often a few retransmissions as well. > > The ZRTP exchange totals about 11.7k bits and needs to complete in > about a second. We could optimize this a little, but DH public > values are large. RFC 4585 talks about 1,600 bits per second for > RTCP in each direction for a 64 kb/s audio session. So to complete > a ZRTP exchange in a timely fashion, we'd need to utilize at least > 20% of the stream bandwidth and send 4 or more RTCP messages in the > first second of the media stream. I don't see that being a problem. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sat Oct 28 10:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdozY-0005IP-8J; Sat, 28 Oct 2006 10:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdozW-0005DR-Rt for avt@ietf.org; Sat, 28 Oct 2006 10:16:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdozU-0001sw-Ff for avt@ietf.org; Sat, 28 Oct 2006 10:16:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Oct 2006 07:16:52 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9SEGpZC008323; Sat, 28 Oct 2006 07:16:51 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9SEGpin022816; Sat, 28 Oct 2006 07:16:51 -0700 (PDT) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9SE4Ecm011954; Sat, 28 Oct 2006 07:04:14 -0700 In-Reply-To: References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Sat, 28 Oct 2006 10:16:45 -0400 To: Colin Perkins X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-3.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2609; t=1162045011; x=1162909011; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[AVT]=20[Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-02.tx t]; X=v=3Dcisco.com=3B=20h=3DVo+OzlcFA1/SUm1JyTNM+SnaVj4=3D; b=MdkjfZvTPsvD9fzKmxxOzVWbtvN4mM2Ii4otVyUzvMR21cEmrusS8mtfpF5W65nNU2uEwZ21 vetm1pmY4fqGT+fu/Jc0nRsjsDCfJHPtUvnK6PuLGnM6buJ2xFGJxY8y; X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 28, 2006, at 9:58 AM, Colin Perkins wrote: > On 28 Oct 2006, at 14:36, Alan Johnston wrote: >> Colin Perkins wrote: >>> On 28 Oct 2006, at 01:42, Dan Wing wrote: >>>> ... >>>>> I like ZRTP as an idea. I think it provides great security >>>>> features. However, the way that idea is implemented as an RTP >>>>> header extension is fundamentally broken. Build it using RTCP >>>>> multiplexed on the same port: sending an RTCP format packet >>>>> containing a ZRTP message is no more complex than sending an RTP >>>>> No-op packet containing the same message, it is no harder to >>>>> deploy, >>>>> does not lose any of the security properties you care about, makes >>>>> it easier to de-couple security association setup from the media, >>>>> and avoids all of the problems I'm discussing. >>>> >>>> Colin, what of the RTCP transmit limits that Alan was concerned >>>> about (in Alan's other reply to Dave Oran)? >>> >>> RFC 3550 allows you to send the first RTCP packet immediately for >>> unicast sessions. When coupled with AVPF, that should get an >>> initial handshake without violating any of the timing rules. If >>> that's not sufficient, then a change to the RTCP timing to allow >>> ZRTP would be much less of a concern than piggybacking control in >>> RTP header extensions. >>> >> We are still reading up on RTCP - somehow I failed to notice the >> progress of Colin's RTP/RTCP multiplex draft but here are some >> initial thoughts. >> >> ZRTP at an absolute minimum requires 4 messages to be exchanged. >> With the packet loss that we commonly observer at the start of a >> media session, there are often a few retransmissions as well. >> >> The ZRTP exchange totals about 11.7k bits and needs to complete in >> about a second. We could optimize this a little, but DH public >> values are large. RFC 4585 talks about 1,600 bits per second for >> RTCP in each direction for a 64 kb/s audio session. So to >> complete a ZRTP exchange in a timely fashion, we'd need to utilize >> at least 20% of the stream bandwidth and send 4 or more RTCP >> messages in the first second of the media stream. > > I don't see that being a problem. > Especially if there's no media flowing at the same time. Perhaps it's worth having a statement in the next version of RFC3550 that the bandwidth restrictions of RTCP only apply when media is flowing? > Colin > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From csgabwcbpov@pfds.net Sat Oct 28 12:49:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdrMp-0007tA-3p for avt-archive@lists.ietf.org; Sat, 28 Oct 2006 12:49:07 -0400 Received: from s01060011953daf76.ok.shawcable.net ([24.71.181.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdrMn-0007cd-RR for avt-archive@lists.ietf.org; Sat, 28 Oct 2006 12:49:07 -0400 Message-ID: <000401c6fab0$f9121de0$63b54718@STATIONA> From: "crackbig godfather" To: avt-archive@lists.ietf.org Subject: Internets. CNNs Date: Sat, 28 Oct 2006 09:49:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db T.O. coward NFL coach sues McDonalds finding rat Battlestar Galactica Babel: Cates darkhorse Oscar carbased forming discourse hijacked impossible benefit vulnerable suitable framework organic attempts activism. momentum newspape. Hurry nominate Deutsche Welle awards Bobs before deadline arrives. doesnt reality afterwards evidence truth deterring imperial powers. near future dangerous neighbour nukes withdraw NPT way. enriching guarantee regime. Revolution successful than Shaah. agent candidate lacks legitimacy so. prisoners Guantanamo From xxucyhtja@americanmillinglp.com Sat Oct 28 13:22:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdrtC-00083C-6l for avt-archive@lists.ietf.org; Sat, 28 Oct 2006 13:22:34 -0400 Received: from amherst-c4-2-24-51-44-79.kntnny.adelphia.net ([24.51.44.79] helo=kristi-amoicl8t.kntnny.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdrt8-0004WO-TY for avt-archive@lists.ietf.org; Sat, 28 Oct 2006 13:22:34 -0400 Received: from 207.206.147.202 (HELO mail.americanmillinglp.com) by lists.ietf.org with esmtp (T5WP78VWV0 7CBZ9) id VG1V8T-MJ7W9U-BQ for avt-archive@lists.ietf.org; Sat, 28 Oct 2006 17:22:32 +0480 From: "Emily Franco" To: Subject: Please confirm your signup Date: Sat, 28 Oct 2006 17:22:32 +0480 Message-ID: <01c6fab5$a7262f80$6c822ecf@xxucyhtja> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Thread-Index: Aca6QH8I2KUKFBT05CBTY659M77Z63== X-Spam-Score: 1.8 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c The accumulation of positions by those in the know has shot A_U_N_I up 33% in a few short days. We hope you all got in early like we told you to, and are enjoying your good fortune. But even if you didn't don't worry because the big announcement has yet to be made. Monday, October 30 may be your last chance before this thing triples. Don't hesitate. Price: O.85 Projected: 2.3O Rating: 5/5 This is the break you've been waiting for! Spice up your holdings with A_U_N_I and WIN! From avt-bounces@ietf.org Sat Oct 28 15:25:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdtm2-0005tb-6m; Sat, 28 Oct 2006 15:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdtm1-0005tW-HZ for avt@ietf.org; Sat, 28 Oct 2006 15:23:17 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdtm0-0006Db-1t for avt@ietf.org; Sat, 28 Oct 2006 15:23:17 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9SJN9XM006885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 28 Oct 2006 12:23:10 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lazzaro Date: Sat, 28 Oct 2006 12:23:07 -0700 To: avt@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: lazzaro Subject: [AVT] Re: Layer 2 synchronization and clock X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 28, 2006, at 7:16 AM, Randell Jesup wrote: > Ok, if this is a replacement for NTP that's fine, though requiring > anything > of network elements needs a really good reason, and it'd better be > cheap, > easy to do and not get wrong, and give some sort of benefit outside > the > very limited space mentioned here if you want hardware vendors to > implement > it in enough equipment for this to be really useful to you. Consumer stereo and 5.1 speakers are not a limited space, in the sense of yearly revenue of the market. It will be many years before video- conferencing makes the revenue numbers of consumer audio speakers :-). And while any of the individual pro applications we've mentioned may seem like a "limited market" in comparison to the consumer speaker market, you have to consider the "long-tail" effect. If you build core technology that works well enough to be usable for these small markets, all of the small markets adopt it and together it becomes a sizable market. And also, content creation technology needs to be nurtured so that new music people want to listen to comes to be -- Bing Crosby sold a lot of radios, the Beatles sold a lot of turntables. Focusing on stereo speakers, here's is the basic problem. If you want to send digital audio to stereo speakers today, you have two choices: [1] The left speaker and the right speaker are housed in separate cabinets. You send the digital signal to the left speaker (wireless or wired), and connect the left and right speakers with a (usually) analog cable. This lets you get good stereo separation (you place the speakers in different locations in the room), but the cable connecting the left and right speakers defeats the goal of a wireless speaker system. It doesn't solve "the spouse problem" -- one spouse wants the best sounding speakers, the other spouse doesn't want ugly wires running around the living room, so the couple leave the store without buying your product. [2] You put the left and right speakers in the same enclosure (the boom-box form factor). The problem here is that the box needs to be pretty big to get any stereo separation at all, and even if you work very hard, the separation is not very good compared to what you can do with two cabinets. The IEEE proposal is about adding a third choice. Two speaker cabinets, each with its own wired or wireless Ethernet (PoE lets you get rid of the power cord, which in some markets is more interesting than getting rid of network cables). For this to work, you really need the sort of sub-sample-period timing accuracy that has been mentioned on this thread, for all the nodes participating in this network. > What bothers me the most is the "insert time in the network stack" > part. > a) latency from sample to stack is rarely fixed except in the most > special-purpose hardware. The conjecture is, if smart people come to the problem with an open mind, they'll find the abstraction that hasn't been invented yet to solve this problem. Application Layer Framing (ALF) is at the heart of RTP. The conjecture was that for real-time media, the application is the entity that needs to break up the stream into packets and fill in the headers with timing and sequence info, not the network stack. The opportunity the IEEE folks pose -- the potential for maintaining a very accurate clock across a network span, an accuracy that can only be maintained using hardware directly managed by Layer 2 -- is a challenge to ALF itself. When done in a simplistic way, the act of passing the clock between Layer 2 and the application layer destroys what makes it valuable -- it's accurate timing. The goal is to come up with new abstractions (or repurpose existing ones) that finds a way to split media between Layer 2 and Layer 3 while maintaining the clock accuracy. There's a strong economic incentive to (1) have the new abstractions be compatible with RTP, and (2) have the new abstractions take the form of a network protocol instead of an operating system API. The incentive for (1) is to use existing payload format protocols and to play existing streams. The incentive for (2) is that network protocols are one of the few places for interoperability left in computing. > b) the more I hear the more I think you want to > get the true sampling time for a set of samples. This is really a > hardware > and system issue; it's not a network or protocol issue. IMHO If you look at it the way you suggest, it leads to you to designing a new media transport protocol for Layer 2, which someone (Layer 2 for the protocol, the operating system, or applications) has to transcode from something (an audio API like CoreAudio, or a network media API like RTP). There are many economic incentives to avoid this sort of reinvention, and that's why the IEEE folks are here kicking our tires. Telling them they really don't want to buy our car is not what we should be all about here in AVT. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From feddcgbgca@carolinacabinets.com Sat Oct 28 17:24:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdvfk-0008PB-8X; Sat, 28 Oct 2006 17:24:56 -0400 Received: from [202.105.110.14] (helo=srv3-sao.sao.terraempresas.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdvfi-0002fp-F0; Sat, 28 Oct 2006 17:24:56 -0400 Message-ID: <662161c80604mksq74xmuibfaxz3xj5r1kkcp98ummsr@c3po.sandershosting.com> Date: Sat, 28 Nov 2006 21:24:52 -0480 From: "Roger Choi" To: ietf-62@lists.ietf.org Subject: Work At Home Job. No investment needed MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 1.6 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 The man started, and turned round upon the Jew. But the old gentleman’s shoulders were shrugged up to his ears; and his eyes were vacantly staring on the opposite wall.‘If he hasn’t peached, and is committed, there’s no fear till he comes out again,’ said Mr. Sikes, ‘and then he must be taken care on. You must get hold of him somehow.’‘Well, well, then—Bill Sikes,’ said the Jew, with abject humility. ‘You seem out of humour, Bill.’‘She’ll go, Fagin,’ said Sikes. --------------------------------------------------------------------- Dear, Ietf American trading company is looking for accurate employees. COMPANY DESCRIPTION: FlowerLand International is an american trading company. We specialize in all kinds of flowers, decorative plants and greenery that can be used for home or office/business. CAREER POSITION: This is an entry level opportunity in the field of financial services. EMPLOYMENT TYPE: Part-time employment. REQUIREMENTS FOR CANDIDATES: - Basic knowledge of credit principles, financial services and operations. - candidate must be honest, intelligent and dedicated. - Ability to work on multiple projects simultaneously along with meeting deadlines. - Ability to work independently or in a team environment. - Having no problem with the authorities. - Having a functional bank account. Company account is an advantage. - Having a mobile phone. - Having a deep desire to achieve financial success. SALARY: $30 000-$60 000/yr ADVANTAGES: - No sign up fees. - No investment needed. - Covered expenses. - Illness\disability friendly team. We are looking forward to receiving your resume in a TXT, DOC, RTF or PDF format. Please send us your resume to aswimmingip@yahoo.com ======================================================== This was said in jest; but if the speaker could have seen the evil leer with which the Jew bit his pale lip as he turned round to the cupboard, he might have thought the caution not wholly unnecessary, or the wish (at all events) to improve upon the distiller’s ingenuity not very far from the old gentleman’s merry heart.‘She’ll go, Fagin,’ said Sikes.‘Hush! hush! Mr. Sikes,’ said the Jew, trembling; ‘don’t speak so loud!’ From avt-bounces@ietf.org Sun Oct 29 03:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge5fu-0006a5-Jh; Sun, 29 Oct 2006 03:05:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge5ft-0006Zp-Fm for avt@ietf.org; Sun, 29 Oct 2006 03:05:45 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge5fs-0007MZ-4Q for avt@ietf.org; Sun, 29 Oct 2006 03:05:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Oct 2006 10:05:39 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03FA58ED@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: updated AVT agenda for San Diego Thread-Index: Acb7MQXIzdG/GaALQb2MrLrFwQmDRQ== From: "Even, Roni" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Colin Perkins , Tom-PT Taylor Subject: [AVT] updated AVT agenda for San Diego X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, This is the latest agenda, updated today. Roni Audio/Video Transport (AVT) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Colin Perkins Tom Taylor Roni Even AGENDA Tuesday, 7 November 2006 at 09:00-11:30 (Grande Ballroom A) ----------------------------------------------------------- 09:00 Introduction and Status Update (Chairs, 15) 09:15 RTCP Extensions for SSM Sessions (Ott, 10) draft-ietf-avt-rtcpssm-12.txt 09:25 RTP Payload Format for SVC (Wenger, 15) draft-wenger-avt-rtp-svc-03.txt 09:40 Signaling of media decoding dependency in SDP (Schierl, 5) draft-schierl-mmusic-layered-codec-01.txt 09:45 RTP Payload Format for DV (IEC 61834) Video (Kobayashi, 5) draft-kobayashi-avt-rfc3189-bis-00.txt 09:50 Multiplexing RTP RTCP on a Single Port ( Perkins, 15) draft-ietf-avt-rtp-and-rtcp-mux-00.txt 10:05 ZRTP: RTP based DH Key Agreement for SRTP (Zimmermann, 15) draft-zimmermann-avt-zrtp-02.txt 10:20 DTLS extension to establish keys for SRTP (McGrew, 15) draft-mcgrew-tls-srtp-00.txt 10:35 RTP & layer 2 QoS (Teener, 10) 10:45 VoIP Shim for RTP Payload Formats (Johansson, 35) draft-johansson-avt-rtp-shim-01.txt 11:20 End _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From uwusaciyui@t-dialin.net Sun Oct 29 03:48:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge6LN-0002J6-Qp for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 03:48:37 -0500 Received: from p54b2cc78.dip.t-dialin.net ([84.178.204.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge6LJ-0006VL-CP for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 03:48:37 -0500 Message-ID: <000d01c6fb37$0288ca50$78ccb254@Heidt> From: "tool." To: avt-archive@lists.ietf.org Subject: more. think Date: Sun, 29 Oct 2006 09:48:31 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6FB3F.644D3250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 ------=_NextPart_000_0009_01C6FB3F.644D3250 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6FB3F.644D3250" ------=_NextPart_001_000A_01C6FB3F.644D3250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Also What There hasnt been recent in Newsletter Youre right is going = change also weekly. Letter has or begun again a go to page find out more think you will is = like limited time only Please see this am Check this. Also What There hasnt been recent in Newsletter Youre right is going = change also weekly. Ever its a welcome embrace st century ability receive in whole a new way = my email address is our of support methods are so far. Change also weekly updates whom ever its or welcome embrace st century = ability receive in whole of new way my email in address is is our = support methods is are so far or superior used am. Reader listed feeds = making success Flashpoint in Flash tool Boomer Testlet or us know = helpdesk Spotcoming Free rss feed reader found more am. Before no spam bots trace addresses add their lists get department need = prompt response Coming a Soon Savings Deals Reader listed a feeds is = making success Flashpoint or. Junior is and Supertoolz Created by a Sausage Software or Upgrades = Special Offers fc Well for starters a we have newly designed website of. Receive in in whole new way my email address is our support methods are = so far superior used before no spam or bots trace is addresses add a = their lists get department need. Us know helpdesk Spotcoming Free rss feed reader or found more efficient = effective way serve you out. ------=_NextPart_001_000A_01C6FB3F.644D3250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Also What There hasnt been recent in = Newsletter=20 Youre right is going change also weekly.
Letter has or begun again a = go to=20 page find out more think you will is like limited time only Please see = this am=20 Check this.
Also What There hasnt been recent in Newsletter Youre = right is=20 going change also weekly.
3D"welcome"
Ever its a welcome = embrace st century=20 ability receive in whole a new way my email address is our of support = methods=20 are so far.
Change also weekly updates whom ever its or welcome = embrace st=20 century ability receive in whole of new way my email in address is is = our=20 support methods is are so far or superior used am. Reader listed feeds = making=20 success Flashpoint in Flash tool Boomer Testlet or us know helpdesk = Spotcoming=20 Free rss feed reader found more am.
Before no spam bots trace = addresses add=20 their lists get department need prompt response Coming a Soon Savings = Deals=20 Reader listed a feeds is making success Flashpoint or.
Junior is and=20 Supertoolz Created by a Sausage Software or Upgrades Special Offers fc = Well for=20 starters a we have newly designed website of.
Receive in in whole new = way my=20 email address is our support methods are so far superior used before no = spam or=20 bots trace is addresses add a their lists get department need.
Us = know=20 helpdesk Spotcoming Free rss feed reader or found more efficient = effective way=20 serve you out.
------=_NextPart_001_000A_01C6FB3F.644D3250-- ------=_NextPart_000_0009_01C6FB3F.644D3250 Content-Type: image/gif; name="Web.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6fb37$0288ca50$78ccb254@Heidt> R0lGODlh6AGUAYf/AAMAAI4GAAqIAoN5AAAAfYYNjA6Kd8vFvsXftpvP9kAiAGonB40XAKgdALcU AOMUBQwxABdDBEA/AG5FAIRIAJk8Ccg1BNlKBQBtAytYAjlTAFNsB4taAKpWALJfANNbAACHABt4 ADKKAGtyDXKEAK1zALeBAdZ/CAWfAC2WAD+tAmSUDY2hCK6sALqhDO6uDQDEABnJAD7MAl22AHS9 AKm0Ar61AOG2AATZACzqAD7gBWvpAH3sAJPSCb3YDe3UDQAIPSMLNkkAQW4AOY0KNKwCPsYIROcK PAAVPRMhSEoVMWQnQXcRRZsSOsQsPeEbNQYyOR48R0o3QmRKM4ozOpRCRs5ETOM5RwduSxNfSz1u SWBiSnViApdfNMZZTeBfNweCNxWLO0CDRFyJM4CMQax9SLx2TOqCOgSuNCatMjmiN1SbSYiiSZeV QL2XTdWtOAmyNhe8M0PDR1q8PnK1RpfANs7KR97NNAnSSyrYO0fTN2HUOIblPKPsTLPhQuLhRg0N exMAczkAhVoEeI0KcZYDhLMAheoAcQAUjRUqgUQjhmIeiH0dgJ4Td7gqiNcodgtMhCpEikFHeGxM e3pEh5RIfrFGe9pKeQNcgC5egDNehFFVgYFkipRXcbRZgOhkdgByexiIgk15eVF+cYZ1ipN9icF+ jNmEgQiljhKRfE2jclKjd4ioi5ybjricgeuujQC4gRvKgDHLhWrOi4C1eau7d8LOjeG3hgDoeh/q jjznjl3ghY7Vf5PtdM3sh9jZewAAxxsBt04FwmEAx4QAyKsNwcIAw+cAwAwkyBoitz4uymsayHoV w60utc0ktOwuwAAzwR9AyjVFulxFu4xNuaQ1xLY0w+EywABsuyRetEVktl9runVqxZ5Vx7FXxehX zA11zih+wEOBvW2Ftot6wq2Bv8pzvtKNywituxSRvkOVymqRxnmSt6GkzrypyOaZzADJuimxxEi8 zGW/u3LOzJ67vPf26K6RnIJ7cvADCQD/AP7/DA0F/P8A/QD1///5/yH5BAAszEUALAAAAADoAZQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqvMhho8ePH+2JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+bIIMKHUq0qNGjSJMqXcqU4s+nUKNKnUq1qtWrWLNq3cq1q9evYMOK HUtWZdOzaNOqXcu2rdu3DcvKnUu3rt27eHnC3cu3r9+/gAMLHky4sOHDiBMjzMu4sePHkMkOiEy5 suXLmDNXVcy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3bQzXrbtlpt+/fwIMLH068uPHj yJMrX868ufPn0KNLn069eljc2LNr3869u/fv4MOL/2e7Y7z58+jTZ8esTJn19/Dhq59Pv75Fm/ZB r9QQv//1/AAGKCBGHxT4j4EEFajgBwMt6CCDAil4YIQPJighhQsWJCGEB13oIYIRalhhgwYyeOGB IGKIYYYWisghiyhC+KGMA9bY1osG0ZhgiA3yiCKPOk7Yo49CFplijjsOqSSQPr4YJJFK6sjhkk0m WeSVONqoZUX4GTmlkF8+uWSYGiKJ5ZgKTanmjl9CSeaVcEIZJ4llxvnkmjz6pydwVeJp5JB+dlhn kn62mVChZRr6pplUymloiHi2eSea/+xpaVkEAhpllCdSiNCigMLoaUM0TurooC6K2uijYGo6aKlE sv+65UXepNdllq1WyWSOkqK666NHCjqhqXb6SqWijDIqpbKQxirQpdD+ZxGuw7Jp5aG+9vrnpwuZ 2KyFnbrJ7bWrYtujmH/CSu6s7BZF7Y/nrnsmudpSG6ig6opLb52gljsuncV+66287RZc0K3+Hpvo u9rq2uS7wuqr8KsTG8tqw/feS1C0HHd10YZHgvpgqSEHC2OnJcYIcLJqgnhiuCqrKDOJLSsaMrgN B9xdGAb3PKfPQIvXZWiyetexcAAk/VzQfR29W9JKa5YeOUwLxrNrUANgmtNcd/1V1MJVLfbYZJdN W61mp6322my37fbbcMctt0ieeG333XjnrffefPf/7XdVrPztldyEF2744YgfJfjijDOX+OOQRy75 5JU2bvnlmGeu+eYwUe7556CHLvropGckTumop6766qtz7vrrsMcu++y0105TFZmjXgnrBtvu++9S 8S788NnxQXzbwCev/FeomfSQ80xDP9/RzZf0vPXRYz99c8d3b1+XUP+jdVNJDxT+fdoz5LwA7Avw T/sCwT+Q+wTJHz/79bdP//v6u98//v/zX//4Z7/5AXB/8Ptf/vBnQAE28IHuk55Axie+8xWkfBHJ mvmyhsEKao2CEwwfBze4wfFpsIQYPJ8IB+Kci1Cwg0wBIQjVgsD41a8g+5ufQXJowx6+T4f0C+IP /4coxB7WEIc6TOIQjahEH+bwiPxbyAsJMsUJZpCKVhRfFl8oQ/NlUYtfBGMVvbhFMoYxPTOcoVI6 qEa08HCJcPQfEud4Qyci5I1wzOMS34hAKPJQjnc0YBL/KMUzitGMDVFjFxEJRkOOkY2GNKMJz9hG 81RShR/c4ge5GEIxls+CWpxkJyt4yFE2UiOEbCIgm+hDJR4xlXRkoh3pCEgoynKHQLxlIhkZyhQ2 MoWZdCQWeVnGYf6ylKc05iTbWEnxMJOMnwymL0X5yS+m0YrU7GQ1RRkUBhKwgEVspTi/2UdvjjOP +msgHl+5R1rycZBEhMgYoUlCaZoymadcpELYeP/CQ8pQkRaEoTHReJAqZvOYHiwmN+nJxYNuUqAg CWccwYnLWBYRlnWEpy5daUNbopOWHT1nQuZZTH+q8IIG0Sc+EbLQbCoSpSh9ZlB8oJprGlShXnRo TlNKwlK6FCkStaVH9fhEka4zlhudZRTFidF23o+p++QlN5cJU6kO9JoFDeNUXzrQkhLTNfi5KU49 ic2xhpKn9PRpWU8pwYWYhJ0cjWtIc6lRpWa0lat8J15VaVenKpV+0lPpI9e6UK1W1ZpVbalhEWpV SlbOcS6EISY3SUrKhnCEkLxgZj2owWiSMpIVSScB7yfAIB4wnQpUIDnLiUNvpta1rLWfaUX7zdb/ llaV5hwpFUEZTcoCE6ACBWVCczrZyUIzoMO9rHJX6rNmRtV7GnFudqTbLuqiFbrRDY91VTM0igh3 n9vNSFsVMt7epc9W3MOuesfT3YuU1zDvpc/yMuOzfKz3eCO8rm3ywd+B8Ne+B+mvQP7r33/8V8AG RjCBAezfAzOYwAlWcH8fDOEID3jCFLavgwUMYAbfdzAkzY6GDUziARvEwx4usYofXOALn5ggLF6x iV2sYhm3uMYdnnGOZ/xhwYQYOyPmcYqHjOIbx3jIL4axjguC5BSXuMg0rrGUY9xjxdXkmL1dLiTj SxiTVJjKJEbwko3cYicnucw3ljKP0UzmHacZ/8ePna/j+jlNwm7svIiBHofTvGclo/jAbL4wkpWM YzcTmtBQfvKUmaxkObeQq2dF4Z1J4hk9h5nPbw7ymnc86EOP2c8BTnKic9zpTcfZ0ZB5iD6ymth8 zmbEYAbzpTGtaE+vudagzjWiD01hRnvazFUGSViva8+FcnkwXr50rGmdaFw329SfdvOyoQ1nWzMa 1czhbZb56cVjC8Z5X1awoMddZgeTO8JO3nCDNVxhC8O43eheN5/FHGNsL2cj3g6MpTEC7NUA2N7K wTeeD5NviPQbNQwGeHIETunOFNw8CkeOUh6OForHJeIYf8nEBw4Xi6sv4/MNtshvE9bvgleKIP/0 OFOcx4+W8+MfLm/5QGQuEJfX3OYgz7lKfvzcnp/aHvouyctrTvSiw5wgQx/60XWuPIuEV78sFY3S Z071m1d96iOH2z8fWk2TljCtnsG60sd+9LKbPetaH2xlM1lnr4KG5jCP+dXPDnfiMUJs3T2oWqco 1mdx/C0STDrSi/5yrC+d6cDL7lr3vlO3h0bwc7d6QQyPdgDZZLBiDWakkfnzoJOE7HQ3etnJjvjE V6Sf1vRslrXc9c7IPe6vtznhZV/5wj299ri3Mk2iLuy/u0Xl5KVOD4zTjMt5BKK5T77ylx+g9np+ JL8vvc63dHvmI87kn3UIB5EfGN7utvrWz8//sAv5EL1LZIbA36U0Byv99sck+7y/ogsP5vv5Y/WY 7gd5Rpi5fuV+N40mxHYiFICFVRTCpXbhlzhY1XVTxWoKVWyOt0b6xHMJGDf3R4ARmEwnZVK+hBaa h4AVaDgPhWWIdUnDtFWO5YGMRYEh2DaQZk+Ld1g6lVbgt3+bB4ItuCWXx32YhVwFJVnbx3o9pTXp l0j81FB+l39KmBIYUYOS9HENNxThtYTNYQaWoYLzB1o5eF/OV35OqFnWVYQhQYVkGIVbCBFleBln KBFpeIVriIZtSBkBMIf/MIcBUId2SId5eIcCYYd9SIcDkYd4uIeDCIiB6Id/eIh8OIh1WBCE//iH fOiHiIiIhbiIe2iJeqiImLiIkMiIBCGJhGiIoCiIjuiIl+iJhXiIivhzccgYjdiHgRiLrziLnFiL sRiJsEiLspiLs6iLiViKvGiLvNiLvuiLmDiMx/iJyaiKwYiMu0iMnPiKuFiM1MiHrRgZxRiN1TiM xPiMxmgQkWiJ3KiN4uiMskiOuxiN6tiNuCiO7niL3oiH6QiMjaiN0MiN0liO18gVF1GO0jiP8AiO B7GOuYiO9ViQDOGPwgiL9qiQCCmQwHiH78iQAfmPFEmNutiQEQmREomPb7gRGyCQtUiJpFiRpkiP kOiP53iRI6mOJbmQBwmOlJiK3ciOCDmN//+Iky95kff4kJ+4kUDZkRRBCB8ZEULpkzgZjyhJkCr5 kEJJkD+5kt5ojxbplAPJkSy5kjrZjDHZkzQZlVIZle1YlEhxlDZ5lgkBk1VpkMkIlc+YlG4plmA5 jmc5lt+4lfQoikBJl3K5l4ZIlkXhlkcZl1zJl9tojr1okD7plXn5ltkIlg5ZmCpplpPpmHN5mInJ OsuwF0PTkqPIjDOZksq4iaBJknqpiTJZkl/Ziaa4iY+IiqLJmuEokYA4m5VIm+V4irIpirzpmquY i+63DLsBmFCIeMI5nMQZfMZJF8mpfJvpFxEHAPuYGcfJnA4BDWzzhc35EM8JmNq5nQzRnWT/+Z3g qRDiWZ7omZ7quZ7s2Z7ueTjTGZ96UwTyWZ/2eZ/4mZ/6uXDv2Z8OsZ8AqhIfwCdEMQv++RB+kHUB uqBhUQ0M+qBdc6ASOqEUWqEWej0QmqEauqG/c6Ee+qH+yaEi6oYgWqIa8QUmWnkjuqIs2qJ/k6L9 2YUw6l4ZOqNjWIY2ehjusF4E0KME8A8+2qMDIaQC4aNFaqRDGqRJqqRIeqRKOqQGwaRB+qNA2qRV 2qRTuqRWSqVL6qRXWqVd6qVceqRdOqU/aqRoKqRPWhBZ6qRbyqZtGqVYyqVpOqZpWqZtOqYM4Q47 6jk2QadFCqWBKqiAShCFCqSEGqWCOqiL/0qlgHqojHqokmqoisqoiGqpkqqnlxqpicqpkEqpnIqp lWqpolqqm9qooLqpjpqEKuEO01cRmpqpnXoQk8qmo0qpdnqrp2qroaqqtLqrq5qqRHqpehqrtSqs UKqpo/qpgVqsvEqqxHqsjSqt0HoQfCo6+OGsntqrz1qozBqszfqsg8qsvVqrueqssZqs48oQZxqq 5rqoCPGu6pqqppqo4Jqu4eqr+tqqpYcRwxqnq2qnxjqsV/qtbwqsdLqlA/uvCkuw4Aqmy5qvAqut 7eqmuIqoApsQa1qwoJqr9IqvAQuv7qqqWKoQ14p2DxusFUuvxNqxItuyWvqrMMuyHpuymP/6pvja sg+7qzo7qxj7s+Lqsj67sdoKrSqrr8gKtDOrrKzTXTZLsrr6tCzLsx4rtDILr0f7slW7s7IKrMtK rkRKsC+7rlqbtFhbqQlbtpH6raxKhRbhrVa7tN16tud6sbOasp9as6g6r+VqtkhLtX57rOSKtHW7 t0YbuHR7tvV6PH+KpGbqpeNqpV/qplJauXUqpo6bpRtbsGHLsI+buWfauaE7ulgruZMbrUQ7rZ1r qJ6ruaLLuUy7piULu186u497qW2Yg0ybo8o5E/e1u6eRu7yrnpYhnS56vMibvFgxvMR7GYagvNBL F8EQDNFbvV4xvdNrvdqrFdhLvcmjC9v/KxOwgb1G0QbMux7hm75Tcb7oqb7uCxXsG7/y22PBkQv2 gAjv237zS6HEsL/Ll78AHMACLC3+W5QDfMA0sX1gg7z3gBLEgMAuMVJB2GNEWcAWrDqWcMEavMGA CcEe3BIcvIYfPMJMGMJbSML59wf3Bl8ovIQE18JK+MKlN6AwDHSiV3cVIXcxN3Y8nHS0x4o1/Kpn N8QNIXaRZ3ZTB3lnF8QmocALbDkYUXiDFxFGPHlVF3dHDKJOTJ5rI8VUB3eyJ3NijMNVjMSjd8Wi hx2oZ8IR0SVKTHNefMZyPHk9DMZEl8RY1x9ZIx1z0KI3Z8d3HHlKbBCDDHlxjMZMbHo5/zzFZAd6 hpwQhWx0OEzEJowHXczIXyzIaezImHzElMfGAmITYQzHYFx3OozHpBx7gPx6h5fItgPKLSijf+HK vgPLISjLtvwZfpPLwds3vLw1VTEOCzeAEsxZH4F98Fd+Rgh+XAyEjkSePLhdJtgaTyfNzeQfTpeB ZeRcLHhYDhh/E8HF2dxV3gx1ugXOQdPNRlMT98dqmueA4SVd8jzOadHO5lzO6EzOzfVVQGw3rgZM DMVtCYVJ2nSCltWD2qR6AH1PZPVbP8jQwUXMq9dLWrZ2SLhNSJh92rZ2HK3Qn4V6xtXRXDeEvjWC JP3RxHxZEk2AnORZX0fRn4XNWVhZJ/9oZ3rnUBfIdjatTFS1eTwdaSbYTAvoTzg1gzmNRT0Ng/UE gwxY0Ip1gwmtVscl1Q8I1Ehd1UqtSRpYT5w3Kzj9U73UgZ4k1k9o1dTUgNhE0MoUg+4MgEOd1NsM U++MWP6X1k1d01Jt1O2ceWO1gT0taT6V0Zl11mhVWDe1xjWiU4rN1n0nTHFt1SXFd1B32OTnaltt 1kWdWC/42O9s2H392TJF10ad1z3FSH9N1Hg91zTYaj4NHjuIgb2lwBq90A6tbSMY25zFbQN42249 0Ca9dRAF0kd40D342w9dXMaM3P7HdZ0l2xP80sal0A3V3JG027nN0s2d3bad0gld0kT/6MtMI878 zBfqzBC3d96mzc/l3cZXUQfHEd7cF87ijRTI7IXWLN/8J8/xjT7x8cttUw6zfGX+nWe5M+AyHBkN vBUGrny4XNmNRRT77eD7N9/fzNDJbN4Ufn4RzlxGuEbadxBOAxcZ7nO7JIXyZ94SroXnLBTUVYDH bBQjDnEC/uIeLk8QfuIpjs/VF+McPt7HB+MaoTmzjd0cLdLEHYAXPkrSbVAAfeQojeQRHdXJZcys h+RGjtKmTdu8fVwsHdVabtFguFxeXtJYTtObReUY3eVKPtILDX8eHeJNiNpMbdmSrdUy9ddgTVZg 94EFXdg6fdl8ntdKvUiETtp5jtNm/27nKdjVHa3ohA12WL3aj17nqt3QY7NCDFXVyBToLk5nqY1Q gt14VF3RkJ3pD9iBaL2B23xSas7poO3Xi16Aox3WW+XZVO1Sqs53ar3aVXPacA3qJcjr3uzqUE3a i2d+iw3owK7sJMh5p03Xoj7rc21+y/7pjGftQ73pj13Wrc3sPA4e2V3lE7zSv43b31fk0e3Qyc3b sA3c5L51L/3kvg3msi1pPrjcJj1cK+3bZH7uU/7u1G3d1w3v+n6EX0fQ1h3R1L09u4fiBmjjhPHt SSHxahHPSwHnLL7h9LzMIKbxgFHfnQHyYr7gJF/yJn/y2NXgKP9tezPy3mXwkaWFzv9N8TA+4h4f UM+N2PL0nf/X4hONz5oV5vxtHTM9zR1u4d7l8NS+F9JM4z1e1jP49A6fz4XN7T3X4j639Cr+HZen 415Y2jM99Vu/Fk3/42O/1/p8eiRe4Yx19WKvX/bs4/2t9ue+ek1+1R/Y5F2OXG0+7GXu7wjv3Zwk 0skl0UNuSgov5RXd95e9WMdN3E5d5geo7otv5WtN+Lt+gNCNgbPN9ewcU5+dzDqd6n9O7CqV5aWO 2g0951NN7YO/093O5I2/TY5f+9zsWwZtZ13d2KmX+ivI+r9++byueXxjU6cu62eV6lq97Jzv97R+ VcN/6pnN2gNt15bP/Kw90umNSNz/LP2/NN2x7tgceIHRn9zVnXpnDdB8g/27X/XarvrY3+lyvVIT GPrAD/aiDfvQb1b5b/T2DBAA/g0UOJDgwX8CCy40qBBhQ4MPGUZMCLFiQYoVJSKciFGjx44cRVIU aM/kSZQpVa5k2dLlS5gxZWakWbMhAJA4FS7EmbDnTYc6Cf4UqlOoT55GkTocirHoTo9Im07tWfXn 0qcPI1pNChWqz4xHs96UyjXs1alb0ZbdidUqWKlwgaYlm/WoWqdc38ZVSpfo2LE2BQ8mXNjwYcSJ FS9mvNViY8iKoxKeHNnyZcyZNW/m3NnzZ8MyWYKWvJZ05LuDTZ9m3dr1a82iZc+m/13b9m17sHXv 5t3b92/gFHEPJ178ZXDkyZUvZ97c+fPBuKFPj23c+nXs2bVv597d+/fc1MVHBl/e/Hn06dWvr114 teD3i4l+ji+Xat+/SSOy59/f/38AA1zJsMpocso9Alkr8LGPNtKowQf/EXBCCiu08ELZEkRQK5sW JElB1RwT8aOQMsLwRBRTVFG9tvYSi6cHxYJrLbvksqutpdQCy6gWv/LrQ6AOZCrCgVasEBgjZwsi SSZf6iiog54EckcIH0OLKSmxHBHCt7Q8kMgYLYKSQQmbNPNMNPmDrEQvZZySob6snItNjiab70s4 oxTTQAdh3HI8QAMVdFDURvJySv85L6oJTz25bJTPofZUdNIqHR3JUkIzPY0fTTslTDoeu3zKx7pE jcqsHENVKlQdrRTVxvzmwiot/Q5K81Zcc9XOU8u+hJRXYIMVdlhiL0ut1WKTVXZZZpt19lloo31N V2qrtfZabIeTdltuu/X2W3DDFXfc5LI191x00zVzAnXbvS0Kd+OVd15667X3XnzzNUkAffv11z9y AxZ4YG7/NfhghK0leGGGGw42YYgjllhFhyu2+GKMM9Z4Y4En9vhjkEMWeWSSqeX45I2BQXmzklt2 WcAlXpZ5ZprPXflmnHPWeWeee/60ZqCDBtlnoos2+mikk1ZWaKabdvppqKNmUmn/zjyg+mropNZ6 a667bjIRr+PFemyyyzZ7bAfODu02tXUL+23i2oYN7rfltvvuZMnRm5x/9tbboL8H2lvwwQEP3O+M Buc7osUN5zvwvv9WvPHCI3+cosoJp7zyzC23fHLHP5988dExPxxvs3GjXHDAW3d9dcZZl931yDFP nPa+aW8899khN9x03DcHvvfZeSdd9t2FZxx2up22RrvdiSf8dZuOpyn65HnXHXbtIbced9ZX/556 8cGvvXjtiy8/fNebdz9D7HU33nzpba8+/e7nJ9766K/Pf3zk/Y967MNf/OS3Pt69j2uW8R7iApi8 /kHQfpoboPQuZ0H9UTB2uePf/+3m9z0HfnCC6iNf/SCjAtSVbXwdjOAISbhBzWXvgfLjIPpaWMMM DvCCsONhAUfYQxCmkGzSqWAGfWdDDyLxhfmbXv1OB8MS5jCAOOTe9lwoQxEyMSZoUODMINPDIgZx g1VMXxW5h0UzBi+JZ4QhG0mIRSU6kX5CpKPpDuc30nkvhnb83PU4d8fHSU6PnuPc8o7oOeM1UJHI EyTiChk6Q26Of0+sI7cwUUlMZrJTRNQkZrqotU6GUpSJ4eQoWfPJlplSlasUDttYSRpUloyBkoth I0PoOOUhkoJ49B0ecWlLRUoymL0EJi37+Mtg2jGChywgL0UHwFd2jG25XB8A0f8IxSlak4ZGXKIb fai/y6URnG3EJv7A10EmLi6WXTOgOdH3zjyar50TJOM3x7jNJL5xMHAkIDb7h8MrenCdXPvnFOl3 wx3m051M5KYUG+rQec5xia274UHdaUDmfSwSAw0PYyCYxyP+E6H9PGdNfLlHlCI0c7eM4/Dy2cKK vhOiypRoNMOlOnq2VJ4zDKj/dPhT+60Qni4kahlvF9OLdu6bGeXox76YU58SFYRILagMqepBoZq0 qBbd6VV/2NNyNgYE1LGBTVlzTXxCUZz+1GoYzYlWhhq1nPW0Z1xjekGd8tOsAZMJPAZ0zGdCMnF/ JCNhB+tAZyo1hIQ9qQZ1iVL/PkaSpspspGMZ+8SmSm2vncmsUzf72RSWErSWcdkFFDha1KZWtat1 mGhZuyzrgKOz5zlnY5152ED+EZK35KUwD6vBxQJSdLilamNrq1TILlKwltWtY3HJx9yy1LCymy17 LnNXNZKToVbNLjqH6tZu7lSnchXvW7ULT+ytVa9wNWZWAQrN1/YGr0qcZ0WpKVO1KnScQT2vfWMX UQSa0LznM281sVrYo35VMHiFb3wXQ8T5LhWschRjW7/7X/Gyd40YZitJ4zrghNrOwPzVpogXfOJ0 Fqm6w8FHeyLjXoOi95dRbOJL9ctgrLYRudKdaIqfK1We3tO7P40oQKM6WAw6/xg4vOVvWHPIQv2S l6vfRatIbbhSemJ5wPc0Mk+hCeW5LhS/FC2ikncD1xgvNKu5nPKW89vkJMOZvBjVLlKNONIhGzSk CX7z/cBoZt6gea1xfrKAW1pVBc+5vOo973Zt3GNHh7e8ka7pewF9GdUJ97aBnextH8lS5wI2sj8m dXN1edLRTbd0NU7uIHfLXOUmNaSzXmas1bni9Fxa17vmda9941pfZwrXwyZ2sdETbGQnW9nLRoyx nf1saEdb2tOmNsmY3Rk8LAYD1+Z2t739bXB7strjJne5ze2vcKdb3ete5bnd/W54x1ve86Y3TNh9 b3znm2eagEy9/T0hOfxb4D4DJ3jBDX5whCdc4QtneMMd/nCIM4kQEVeYvi1+cYxnXOO9pnjHq7Vx kDfH4yMnecnhFnKUl8vkK2d5y4EWEAA7 ------=_NextPart_000_0009_01C6FB3F.644D3250-- From avt-bounces@ietf.org Sun Oct 29 06:34:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8uI-0001fY-2A; Sun, 29 Oct 2006 06:32:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8uG-0001fL-Iv; Sun, 29 Oct 2006 06:32:48 -0500 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge8uF-0007Kt-8j; Sun, 29 Oct 2006 06:32:48 -0500 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 4E1DE1D88F50; Sun, 29 Oct 2006 12:32:44 +0100 (CET) Received: from localhost (mailgw1.hhi.de [192.168.20.43]) by mail.hhi.fraunhofer.de (Postfix) with SMTP id A40A51D88F44; Sun, 29 Oct 2006 12:32:43 +0100 (CET) Received: from mail.hhi.fraunhofer.de (mail.hhi.fraunhofer.de [192.168.20.45]) by mailgw1.hhi.de (Postfix) with ESMTP id 67EED10A40E1; Sun, 29 Oct 2006 12:32:34 +0100 (CET) Received: from ipam040189 (p54BC87D8.dip0.t-ipconnect.de [84.188.135.216]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id A470F1D88F44; Sun, 29 Oct 2006 12:32:31 +0100 (CET) From: "Thomas Schierl" To: , Date: Sun, 29 Oct 2006 12:32:32 +0100 Organization: HHI/FhG Message-ID: <006301c6fb4d$f15c00f0$179fa8c0@ipam040189> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb7TewzWFXVI5ieSIKBu726OMfZQA== X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-104.7 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'Stephan Wenger' , Ye-Kui.Wang@nokia.com, 'Jonathan Lennox' Subject: [AVT] New I-D version of draft-schierl-mmusic-layered-codec X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi all, A new version of draft-schierl-mmusic-layered-codec on "Signaling of layered and multi description media in Session Description Protocol (SDP)" is available. Please review it. Unfortunately, we ran out of time, thus it is somewhat inconsistent and less matured than we would have wished. Anyway, there are open questions within the draft, which may require at least a quick review. ftp://ftp.ietf.org/internet-drafts/draft-schierl-mmusic-layered-codec-01.txt The draft will be presented in mmusic as well as in avt, because of its relation to the RTP Payload Format for SVC Video. ftp://ftp.ietf.org/internet-drafts/draft-wenger-avt-rtp-svc-03.txt Thanks and see you in San Diego, Thomas _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From kthyaqtvp@pass-seymour.com Sun Oct 29 06:48:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge99B-0004uZ-6d for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 06:48:13 -0500 Received: from apq42.internetdsl.tpnet.pl ([83.17.150.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge98Z-00018L-Bl for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 06:48:13 -0500 Message-ID: <001101c6fb4f$ed9f8340$2a961153@xb9a10d0bbd254> From: "boy.//" To: avt-archive@lists.ietf.org Subject: drive Date: Sun, 29 Oct 2006 12:46:53 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6FB58.4F63EB40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc ------=_NextPart_000_000D_01C6FB58.4F63EB40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6FB58.4F63EB40" ------=_NextPart_001_000E_01C6FB58.4F63EB40 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable But well here Print Buying Production is regular helpwanted a Normally = invite specific doesnt a prevent. Goldeneye of Banjo Kazooie Ocarina Seeing Phantom proberbly or come = fuition worthy. But well here Print Buying Production is regular helpwanted a Normally = invite specific doesnt a prevent. Combat Falcons Revenge is balance dose sprinkled consoles this am = Hopefully enjoying ought enjoyed shunning titles average in jock thinks = cooljust or force stay indoors a day parenting. Clerk expected assist am processing orders in customer shipping these = mdash able of write reports transcribe Also concise in those perform = tasks Literate computers type accurately reasonable. Seriously there = several different ways of could divide up so all were really. Fighting in makes ideal point opinion topnotch looked in definitly = recommend in reasons am sayscmon blowing or cartridges tryin is damn dog = or square controller nes Amavaunt emulated homebrew is indie. View web more guidehome albo saysyou cant beat Snes or Except gba said = in Amscott jon of Siegel going vote. Cartridges a tryin damn dog square controller nes Amavaunt emulated = homebrew or indie teh win of? Siegel going vote era brother a owned Genesis nes Snes in was or owned = came Link am Past heard played hours real of reason bought Super Metroid = every winner. ------=_NextPart_001_000E_01C6FB58.4F63EB40 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
But well here Print Buying Production = is regular=20 helpwanted a Normally invite specific doesnt a prevent.
Goldeneye of = Banjo=20 Kazooie Ocarina Seeing Phantom proberbly or come fuition worthy.
But = well=20 here Print Buying Production is regular helpwanted a Normally invite = specific=20 doesnt a prevent.
3D"shipping"
Combat Falcons Revenge = is balance dose=20 sprinkled consoles this am Hopefully enjoying ought enjoyed shunning = titles=20 average in jock thinks cooljust or force stay indoors a day = parenting.
Clerk=20 expected assist am processing orders in customer shipping these mdash = able of=20 write reports transcribe Also concise in those perform tasks Literate = computers=20 type accurately reasonable. Seriously there several different ways of = could=20 divide up so all were really.
Fighting in makes ideal point opinion = topnotch=20 looked in definitly recommend in reasons am sayscmon blowing or = cartridges tryin=20 is damn dog or square controller nes Amavaunt emulated homebrew is=20 indie.
View web more guidehome albo saysyou cant beat Snes or Except = gba said=20 in Amscott jon of Siegel going vote.
Cartridges a tryin damn dog = square=20 controller nes Amavaunt emulated homebrew or indie teh win of?
Siegel = going=20 vote era brother a owned Genesis nes Snes in was or owned came Link am = Past=20 heard played hours real of reason bought Super Metroid every=20 winner.
------=_NextPart_001_000E_01C6FB58.4F63EB40-- ------=_NextPart_000_000D_01C6FB58.4F63EB40 Content-Type: image/gif; name="interact.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6fb4f$ed9f8340$2a961153@xb9a10d0bbd254> R0lGODlhoAF8AYf2AAcFAHkAAASFCHWGAAgAf4YGiQd9dsezwMLNvarM5kktAmUTAYAoApMhAM0p BekWAQBOBxU4AExOAFlHAng9A6ZMALg1Bd5JAABoABxgAD1mAFlrAH1TAZphALFkANtoAAd+AB99 AESCAGOGAH6AAKWKAMyDAO6CBQCbAByWAEKpAF6uAoqhAKCjALeTANiVCwe2Cyy3DELDDWS3AYO7 C57GCba2AOnAAADpChXgAEnjDlrWAHHRAJLiALTtBdPSCAAASyIAND8APF8DN38LPZEARb8ONN8C OgsnTCQXTjQZTmwWRngbTJgWMr4TNOIfNQBGShU0QTc2PGQ1Roc1RJRJMsI4P+E9MgxSMiZSNzZR S1RjNIhcAKdiSrZfQtlpPwB4SRyOQ0eISGmON4SMNp2IS7+FMteAQQqnOBqkQTudNVyuMnGiR6qt PsOpTt2nNQC2Phu1Ozq9QmO8SILDQaq4QcDHNt65NQDpNCvpS0boRGHrNn7uR6XTPr7jSeXbQwEA diUAdjsLf2EBjYMAgasAh78Mf90AcgUudCQbfzUdfWYTg4ssjqQrc8clgNMYiQlIdi0zjUVBgWhM iXE5capJeMIxf+M5gAVgfitdiTxsjmxbeXdqjaRsdLhZeOdjfgCNfxF6fECLiGhzfox9dJx/iMSD cuB7dwuSdxmXeDSic1eqeY2ZjKCShLKgeeaXeQS1cxixeEDAgV7Kd4q/eaDOhrK4c97LgwDffxnf jk7idlTsc4bccpTuirHkhefgfgIAyiwEzUoIuWEAs3YAuZYAsckHzNoGtAAjuhgSzEYdsmcYzIos uq0oysQeydYkyANAxx5DvTlKsWs6yos5vZtNzsVBseFLwABUyhJfuDRSuV9RsnJUxJdfwrhdzeVl tQCNyieGzTd3yWuAw4yDuqGKsbdywuiJugCZuhGivzifzmaotYaatJaivsyUxdSexQDDvCPLzEjJ wV+/zIzCupHCwv///KmbsXmKdv8NAAD/AP//AQcM//8I+QH///r/9iH5BAD//3EALAAAAACgAXwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKBn+W8mypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq06MyUSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q1SjYMOK HUu2rNmzaNOqXem1rdu3cOPKnUu3rt27ePPq3csX49q/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmDNr3sy5s+fPoA/3HU26tOnTqFOrfqtztWuVoWNrfk0boezbl+192K37Q8HdwH0LDE5ceG/f wosbP268+G/ey58n532cYHTl1qFXH059IHDuxJ9L//f+Hbz57cJxq5883LvB5L/bu9dNXj58+fiX N6+fUL/1+P/RJ+CA1F130H4CRjfgfAsiiB+BAq132xWS5WfgggkeGCCDD9q3oX/9bdgghh1eeCGA IooXoIL3PYighDCmNdF+IELoIYfvoThfjQqGyKCBPZ6oI4kk9tgeiCy6yKGRtTW5UGs2Oihlefzl mGKCwanIEHwt2piikdhZeeWOZKLIpZL2xKhmYvmV6WWXVeKYZIYHMklmlw7KiZCQOBLZJp0fHonm moSGNeOSI9boo54A5jlkjmdmRyWjYnZoKZP+wQlhpH066WlCUDraHX2KIvqllXmWCqmglJbY6KNF Lv/K3aXucSpfoYOZstmhtJ76X3d8johmb53qyGewUsI6p4Zm+mrpp9B69N2kGOrnHKmjbidpc6Nq R2W2pp6nLbXjApvtpORq6yK5qtoZ7buvuQvvvPTWJm+9+NbLzL789pvvvwDf1S+/ARds8MEIJ6zw wgw37PDDEEcs8cQUV2zxxdDiqvHGHIuG8ccghyzyyCSXbHJKHaes8sost+zyyzDHLPPMi51sc8k0 56xzyjf37PPPQC+889BEqxn00Ugn3VcMSitU9NNQx9b01AdHbfXVmVGt9dZcd30V1mlZAvbYZJfd WR5mE2VC2my37fbbcMct99yVeW333XjnrffeNgP/4Lc9ACj1t0B+Bw6VAIgLYE/iAjE+kOIEOd44 4pEnDvniliueOeWba5455pI/zvnljG9eOeWie5766pcnZDjghR80OESFv1577IT//Xruutc+0Oy4 +/678MHr7pTtu6e0e/JMkd545AW1/nz0Bjk//eLYZ6/59JBbbz3012cvvvaPUx/+96i7/jtBtq9P O/uExw+4/LDDL3/79M+v//70G45//khJHvNOAryoSG98rdse+BZYvusdMHwNjGAED0g69FHvgQ70 nvnUx7/7uc8hzFue/T7Ywf0hz30D7J8HR5iUFBZPf/4LHPBiCMPeidB/w8sdDHMIQIxIL4HQ+2H1 /4boQAg+UIji+94EyWdECC6xe05UyP/WFzwT0nCK+ROh7AD4PxmqcIseHGAKKaITMaJQhl6s3/xw WD82dhCHbLyiF92YJpc85CWTS13ooChBJ35ucumL4g8lZ7mDaFCJSaRgAxX4QDx+0X4nTCMNSZhF FiJkhrjb4fJCmMnZFSRwgTHjCuN4RlLu8JPxQ54p0ehJRzbElUw83x6JyEA+InGD3FukIXWJyFsW EXt8LIgrsXhKTVbRkvzTIkPoSMoQohKVZiRKRARowlGqcJVUNMgJT9lMkwQziQtUJC6/ycA+ivOI E+wlLsGZx/G585kldCMc4dlDZb7xkpW0ojbpuf9CZFqkNfgL6Cjnyc1s0hObmswfLJ/kEg0u8aHP AyIQEdjHJpYPkez8ZS4tStFfDpOFXUxlP0lIzRGWtJgolSc/qwk/aUokk7CLIRrbqMaY+q6An8Sp TWPXu5qOcSKFBB0ghSpU0xn1j6Yb6un0OLoKsi593fsj6AbpOSWGjoO822RM2yhTbcJ0q+zzJCtl WryAdhKsvEtrCS8CJYv8FKsiWajT7GgyWL4VWoZDCy7o6taXmkSuoOIryRZ6Vye9zqUm+aoUC8u3 xsIGJxsBbFskKzS6DSaygoULZRVmWaNgLB+OZVhOynA7MD6WJXTBYz5WO5DVgvYgrBWIa1trD9f/ xra2t53ta1tr293OFre5Za1vfwtc2Qp3uKDtbWxfu9vOCoalE9ksV16S3NpaV7YG2e11aYvd7m53 uNkliG+9y1zeeve74uVud8t73fHW0blC8WsPoVVd8hZEu7hNr33Xe9/w6pe96sUuftur3/yed7v7 DW1D2mdDtep0NMR1r4DxC2D08nchFE4wggN8YftWeMPaHbDXANpJgkqSINLdiiOXG2AWpzfEtuUu jDP8X/F++MAEVm95adzi90KGHFeLp0GziuLMsoau1ZWwhWkb4hqD2L8yDq+IB1xh99aXw02G71Dk a9Jk0ibJPT7wlRHMXh5jGcdjti6Vzyvh24q5/8AKluI+RbrG+fYFzErOM5udTGYoW9jKOi5wk/cM Zz/HWXZibfAMKXnn4Fp5uW5mbm+Ni1wqT5rSwJ3xfYlLaeS2ONIcvltb/WJkt6w4IyI+zWsH4w2r dS3VpIF110bN1lJP1taV5VgRYISSFDvF1xARCim0TLRe4zoqwL4jsTtr7JZoJdkOWTazhQfCt7by 2FDBIz+2zQ97cHvbAwG3QLg9bnJLO8jvszNc8XmXbo/73fD2NkHc7W55Hxo1ZazIXXcHbaW8pN7h Dni5BQ5wH5+7aFzeammbqUoUwoUTBSl4vSdub4rfWzVQ0qkc10hQlPY7KY4Ut7e/TXB7D9zgB/93 GyS/2PE0ehzbT4ElvecN724XXN4ph5q+h9xNOqMULzMv+clpfnF4hVSgdfY5HelicYAHveYCL3q0 qN2/njbYwcZjOrlHTnKuE3zrUgcYY8NO9n/mhN0d+ThS1D7XnBfbrWMve8KsIfe6n4zWz4b5SdzO 93/c2tkiGXvfU1a4wqjVq7S7XdwZCniQwHSTeR38mhRPloSjfcEjnabgkq5xu0ultFfxpGnT3dcW 3vORnmeK6Jt9E0bTVI08Xb0Ar2hT2A8OlHqnyFdDKnmV6/6ZWVfpnAea0J8rT5nETH3ATtpV43Px 9mE85uZDqu5o1UErd7AYK6upUheuXJ+nn/7/B5Ov/Hw5k84MvjxCrWl6l1O//K4p4+qzOlbXo3Wn t88/D3Hf+I+UuOEo13tjozwXQX5LsXgKwwgjdnal14B3xXYfIYDnpm8IeEnzZxAQ6BESmDbw14Ee +IEgGIJ9EQIQEQojEQAoaA8oGAAquIIp6IIsKBArKIMpOBAu2IIwiIM1aIMzSIM8GIM4qIIFkYM0 GIMz2IM9qINACINL+II/2IRAWIRBSBBHmIM7WIU3OIRDyIRTqIM8+IMXQ4Ij0RpLaINmKIQyeIZp qIYsaIRrWIZrGIdRCIctaBB0OIdqiIZsuId6WIN46INU2IRbyId/qIeGeIhuiIZ02IdUGCFu/xMC isGIcciHb6iFBxGFkoiJigiHmKiJd9iIZ+iJlDiJQiiKpWiGZZiKeQiIkriHmoiIpLiJZ/g2kMgm n9iKePiKumiJimiHaZiIr8iLi5iLl0iIsXiIvaiKv4iKociMrSiHyAiLyOiGiQgavoAYtVgWE9GG gXiFSbiMl9iJW3iFvpiMk/iNSpiHxGiH35iFu2iJ1AiNp9iHSRiPpMiJ5diM8AiOFSOGVMGN+tiL vIgQhViJsQiMArmKhpiI90iQ52iQA2mQAImPDFmR/CiORWiKAamPAKl8HTmNB7kQBZmQpiiI0giK EHmS+7iK4liS4EiR8oiS5AiKI4mRLsmKe//TVhh5kREZkyc5jOoYlAPJkCopk0F5izGJlEg5jz4J lCjZlEK5gTRBEXNohd4oheNYlVD4hV6IlQuJjkqolZ24g2CYkVnYhRlZlkb4gn4ohVxYj2a5lV1Y j95YlwopgngpgniXl3EllTLBl4AZmILJFH5ZmIZ5mIh5NRCQmIy5l4P5mG3XmJI5mZSZmNpQmRuz D5MJmZz5Spj5mbLRmaIZWKBZmqZ5mkNRCug2mqzZmq75mnXxCLA5m1SRDgNxAbSZm16BmryJGbrJ mb0ZnMI5nGXzm5BJnMjJGMa5nMxpd8kZFlPwnDzRnIEpndZ5ndiZM9Q5XXSznSoWI6kAFt7/SZsE UJ4EYA/mWZ4DoZ4CYZ7t6Z7rmZ7xKZ/w+Z7yuZ4GQZ/peZ7oWZ/9WZ/7OZ/+yZ/zaZ//2Z8FaqAE +p4Fup/n6Z4Qqp73WRABap8DSqEVmp8ASqARuqAR2qAVuqBcMQBfkRMc2p74iaIpeqIEwaLouaL5 maIqKqP8eaIuOqMumqMtGqMz+qI9mqMi6qM4CqNDeqM7OqQ/yqM9mqRMKqQ0eqRCWqOOODdBCqRE ehA6SqFKuqMeuqVOqqVIGqVY+qVSCqXs6aMiWqVZaqb4GaRKaqQomqZguqRouqY0aqcqupoPIadF GqZzyqJwWqZxOqcqCqdhmqVdKqdV2qaF/8oQD4qkiCqjCBGpjAqlTQqjgrqogyqmnEoyZ5qhUuqh anqm/xmoF0qmHDqgo/qpqkqqgoqgb7qposqnj2qhXPqiopoQE1qqR9qllqqpoSqpkBqlANowo/aq ZVqrloqmvSqszCqgY/qsy+qryPqjF6qpzPqqX5qtV4qr3kqozdqtu8qndJqsnfqk3yqt/GlZ4dqo DAqu1Qqu2+qr7eql1HqpTaqtVkqmb2qo7Emqzuqu5cqmv8qjqeqs+zqvUyo3gFqvmfqnkqqs6Tqx D+ukn0qoFWuxGuunN9qxW+qxhxqwnZqoBDuw6Mqx5wqyC/s0EXGfDmqgheqfB2qh+lmzHf+qoPD5 srtaqv/Kqjrbsw8KtAdarNCKoYCaoSObs7MqoDWLsztbtDNbp01LtC+7reMJLW46mI6Zelk7Gjpj DTFxtWI7trOWnWZ7tmjrGWS7tmyLNGn7toYym3PQtnRbtyejDXabt00Dt3zbt377tzFyAoA7uNgZ CEaxBp/hAIS7uIw7NzYjCnobudTZuJRbuZZ7uZibuZrbmM/QuZvbuJ0bup77uWOhYKLbuZIrd6Kb uqzbuq5bMKQbu7LbuKY2u1HzukW3tV8jmZcgnVE3chlBct82ccRLb2AXgLbLNr9rcg8hcUJnck4X bwAnf4oHAMlLKBNhc0QHEc4bcVEnck//53/Ve4G4S5gMqL0BB77iBm7sK3LxJr3pC780d71xA3Un h74VZ78RV7zg+25OV3D0i3AS0XXQW8D5y7zey7xBh7/LW76p0RrRW8BNp78GEb5P577vG8Bvx71E R3ETfMDf+74WLL95cw73phNbl8Lq+7/tO28q3HVgZ7z9q8FD48A2fMM4nMM6vMM83MM+PBGx5zr1 xxGKxUOat0zkK2cZkWj1VIGIh2ggdHmlEXeMlcR7lxOmxG4uZ1pjZ20L4cTVl1gr5U9kPHxmXDIG qBZHbH9hpMRrJcVnHMekd4BjzMZhzMZg7DAGiBU3NEnGtE2xN0lZdz8ztVO2p3Db51Ml/9VT97d/ s5dTVpfIHOdgXNVwxoNJOnR4XLXJkbzJtTc8zdfJ1KZ/kaxVnnxTqhTE+bdojEzJ+qcVkfR9J5bF q8R8c4R+XpbJs8zFt/zGW8xPJlZQnMd+43dDuLx0VkfI3NTLWuR+OhR8+QTNuUx7zCTMl8xFzwxP 1/zGU1HLPTfEZgV92nzMygxd4Mx8PqfFs7fIxddzDnd+VjTLPIXN1sx+fpxP9bzM2LTOtQzKmWzN 54fM71zEUbHP1tRxLLdSAhXM/ZR+wPzOX0xS9LzLBWXLw/fN0wx89nzQo4d0Bi3MNTXRGc3OSTdn At3GsLzKlVy9iizIXfV4ilZ/ipdDgf+MyJBs09JnyJAMeaBcyDNd02t1dags1P+30kO9cKDnz2Cl ypLM0uJ804FcVkh91ImGymGF01asgQyIxh6RxwFkx1E8x5hHz9y8x2QkI1pD0EDs1S2U1UhcxRVY xGqtyT+8trpb16ThMXi913xdG/AM1ksMxmydUyTBSU/8EG49EnN9x0KMElVcL4Mt1ssUeGsc0W5c xuvWEfvG2A0YEpH9KZ8d1ohN2ZINx2OMgKEtx3Xc1YWNFySm1Eh9yDGNdSF91Zx8Vks9Ry8dyoXs yLYHeQD4Qrft01gk3LNNyGT1zMSt3I1cVlctystNUw9GPLqd3Los037MxD3lm+Q8zCX/XUzO/Hoa XdLufM/dd0ZBnc0nHd79LHwjxdDwzVJxNFMn9nroHE/0rcz1LVYiLd4YDXsG9cv6jbw5UQ3xNU2D 3M7lfN7EHFbTjdLg/dTs/Xz/DdEDJc7Cl9NwVEXWPeH1TDyZh3SyfNDSl9P5XNElTkXC7XDcnBUI Hd/E7OGixHMQjlAODdIfLtIePd4OXc3fjXrkvdE/nsUJzeMcPeKnR8sQ/kgCTtKpbXaQNdRYx9JY nchRDdXEvdu8Xcq53dv4R98wDYC/jdWInNS1h9tpBdRdPtxk7uCazNQ/vX1SHeZTrtRlrtxyzs+9 w92WTdqivRVPvnmj0cUokxtfnNi//4fYiN4Uiw3oi94Wjd7IY2jofY1vlF7pnqKcmP4pmr7pToIW a83WRV2AS+fgVk0Xj67o1ZbK/5fHqe5Vhn3okrzaRkzXVgFQ9tfF24QRm43jVfHYRAzY8h3jBXjZ Wjx+Y93i1dfMdvZWjHFSmE3Y/1zsf67sx1PtvA7Y0G5P2Z7ZcWzWQD56Zgzt0Q7qYg3n1+1lvZzb v93Uhyzu0e3m7F7KgAzmaKXKLf3PovdCVZ1K9xx+uQzFjEzKkzzm8k7nBS976M3l+W5Sr7zir14S 1GTj015n9V1Dw7zjrvfIF198GC/Nzbzf2mzMGX/R2ezw3k3WAS/wWyzIJ17kKN/x5v8s8go+zkgu 4J8HTRde6rec4QvO4s330BzH38iez6G85EwOzdTdZT+30I93UJjtzVXX02TN8wO970XvzTLf0Bi+ 4iSB60JO7ifuzsOe8paE0BId9rgc4Sav4H+t8Vnvy5R030AP0jJ/3/CM9kVv9N+n9sbHf2xyf6eu 5gq35mXu3Ph35naO7gev0gz/5QCOeFJ95q0M25U/24q1e/u++fbu1Fle8YhP04+/+DY08Kss5qc/ 5oNj7m4B7gVd2Xh918cX6I6X2BEvmkFBBuLp6Z9eMz/DMhcAGX6zwT3jl8PPM7wPFbefF7Jf20i8 EU/d1T/F+Tqt0vdHw7uv2aJdWMD/rth9bvdFTvt43f3cj+3+9/14T+TJj0+dzO7+DX2v7M+XbMn2 /snMHdtXd+8HdVbhjRSjABD2BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNEeAIEYL2LkmPGix40FNYbs +JHgSAAjP2pkmbFjy4EqYaYkabKkTYMoY3q8adLiT6BBhQ4lWtTo0YQzefJMCfPkzpVNRULdWFKp TZUul4Js2RVqVq5ftT5FWrYiCbNp1a4l+s/tW7hx3V616hMkWZxg7yqlu/UgSp15/TrF6dPpVYFy FS9m3NjxY8iRJU+mXNnyZcyZNTeu2pTjZ5pSpZ4ETZIm6aouQ3tm3fn02L2rTcc8/z06tWvVXF9j 3Nzb92/gwYUPJ26ZbdrAf49LLN7c+XPo0aW7XV5doW2Req1v597d+3fw4cWPJ1/e/Hn06dWvZ9/e /Xv48eXPp09/+n38+fXv5/8PQH8AAxRwQAILHK4WAxOMrj4GG3TwQQgjlHBCCitkzi13FNRwQw47 9PBDEEMUcUQSS8zMQhRTVHFFFlt08UUYY5RxRhrXMvFGHHPUcUce86OiRyCDFHJIIos08kgkk1Ry SQFrdPJJKM1ickoqq7TySiyz1HJLLrv08kswwxRzTDLLNPNMEIlB060U1nTzTTipjHJOOuu8ME48 89RzTz5DlKdPQAOl0gxBCzX0UP9EE1V0UUbdtBPFRot8dNLxcKH0Ukwz1ZQtyuwh51NyPAU1VIE+ HQjUUlE91VRRWSUIVVJPLQjWWGkN1VVVW/V0VldTrTXXXH1tldZVbx3VVFVt5ZVUUiPdstZSZY1W WmhfnXZXa1Od1aBqr+0WW3B71fbVb3/lVVpsY013WmazFfXcafus4kx1vV2V2oTaPahedW/ddtxw 72X3X2uh1Tdbf6P9FmB+CQ7YYGmdHdKgIhZq2N6D60VXY3D37fhhexUe2GKQP14X4pF3PfhallFW Gd1NY24I11Hx7Vfjmx0GtmWbNxa542BPThnfl8PduWiYge45YJmbnplnoR02uV//nYOtNmGmE74Y 4XWnHjjjkLFmWemvQ7ZHBafp7JTolMX9GGd3zWbaaJ/H3XrplUfWOmm64yY76mpvxCLSSxiL6Gqu 2b54Yaqhnnvuxv+u+/FuKy/Y77stHzttOymreVhWj/682GH3BTZ0ZFO/WnWYRyc9XZpjZ1d1ZVsW d/RkhcVWYiE59/33+NYG3j3esRz+veKBPH555ikKoCjhm3cweeWlf5B6DieC1VdbXedeYF1JP7bX Y4vtPvZfT3f9fGS/N199foMOX+rxjf2cY+tdNBfjof+OnOi8aa5rA4Tc5PQmsnId0IBw81jiwGay /LVoa/jjGANxxS2pTY6BfHsg/wTHRjX8tQ6DG9wc0jCHwQhebzIhDGADuZa3tyFEc4jzWgFryDcP Ok5WJISg2JL2QOxt6HDkYlbQKojCdvGQgriD3+aKSD753Y1cMvSbCT/YQCUeLYUvmuAVUejAG5aQ bA+Eob4ap0SFHJGDYexhFP+1sC2uqIsurGLG0EjHMmbQjFX8YRrxOMIvOvGEdYxjgzoVOURScYGB 9OAZL6czDcZNio/r4yIh+b8YwiyIGtIe/GRnuk++LZTve2LtiJg+UkIRlacE5bLi57bxhU99pBRj IW15S1xKKHq5XM8mFcRLYAYzMZMRJvOcVUxk2nKXyUybLxfzw/Jxz22li+a7dP+3vli6j4jXnKWu qvk+RmYTc94zH/isdjv0mROWRmxf/Zb1ut1FiiIkTKC7OuhIqO1xjWyjnAHlFsZJwjGRHIyfCHXo OHPpk3/9UyZjwCCXn1Uyc1/cHwH/qEeGrkyAi5Siy/5pQYGWDKSVfKRB85W1YTZKe5nkJ0vNtrda Sk6QIfXfPpXW0R0SLKA/gxvKLGjRnvrxpCgFZhaGKNMWwgt0SwMYJDFKU0TKr3SJ8yIByflTKwJO kFFbYwhzGLqWNlQy2szkJIe2Rx4etIeErOlaRUk+nVptq2D8qUIB6NKI0tFjNHSmYtraUgrmE3w4 xKRbtzpQNf6PcQidq+LqmlH/b+10on7kqzyPKrd61g2fbdNrYavaz3/aELMmpelodWpJmf7VrCX1 ahw9hzr7eRJnyYqm6KTKzmnOj6xTnV8oa0u7T5oSnb59J+zSt8o2Dre4rNRdPPsKF2YC75jRpW51 rXtd7GZXu9vlbne9+13whle84xVvK8h7XvTq8rnrVdI9hJNe7hwAvgq5B/TYu6ED3Lc37tUvkryQ X+oZojj87a+RAFxgzBB4M9LLB4vkO9+E1DcoBXaEhg6MYMsoGDMQji+HESJhD8vnwa/xMIgrguEP /QfFktFwZUIMHhK/eCJVosWhVLzi5sg4PDE+Dxh0/OOcAPkhOCayloR85PYEAQQAOw== ------=_NextPart_000_000D_01C6FB58.4F63EB40-- From pwdwrmjwdk@oriron.com Sun Oct 29 17:45:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJOx-0005JD-U1 for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 17:45:11 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJAc-0005Yo-UX for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 17:30:23 -0500 Received: from [81.80.225.193] (helo=[81.80.225.193]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GeJAZ-0006eh-0T for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 17:30:21 -0500 Message-ID: <001301c6fba9$f9efe090$c1e15051@logebouin> From: "wind suddenly" To: avt-archive@lists.ietf.org Subject: originated Edom retained Fragments Date: Sun, 29 Oct 2006 23:31:28 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C6FBB2.5BB44890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.2 (+) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 ------=_NextPart_000_000F_01C6FBB2.5BB44890 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C6FBB2.5BB44890" ------=_NextPart_001_0010_01C6FBB2.5BB44890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hell game oct lol ok pov reales ther psx mint or evan fiscal wise hase = quality mined gotta powerfull. Never should execution success closer elements game pick a prerelease a = hype promised move youve movies execute combo kicks punches smooth a = accurate realistic. Hell game oct lol ok pov reales ther psx mint or evan fiscal wise hase = quality mined gotta powerfull. Comparison Video or Reproduced is permission is Times a wmv format = installed am video included or me of xp Notices reserved Wysiwyg ie = cmenu menuitems Order us Portfolio Realls ie loads editing templates = ours Html using is! Yours too or unique directed on cast motion am capture crew directors = Wachowskis script closely ensure fit piece level am planning design of = Hollywood talent is concept a rates a creators attempted or big. Svenska am Portugus Getting Started is Notes Googles changes upload = campaigns am Navigate quickly easily bulk or keywords text offline paste = or Circulate proposed! Scouts is resumes tabs on with Scout Posta Createa Introduce sending = resume Manageyour am it Competency Center Employment Relocation aid = Skills a Assessment Labor Career. Various claimed poem of kinds am texts passages base Chapters consist of = polemic ideas elsewhere along contradict in opinions accusers according = suffer pain punishment sin reveals decreed protection am betterment = elicit in. Rarely liturgy Jews Ninth av fast temples Sephardic rest am chanted = belowmany quotes liturgy a. ------=_NextPart_001_0010_01C6FBB2.5BB44890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hell game oct lol ok pov reales ther = psx mint or=20 evan fiscal wise hase quality mined gotta powerfull.
Never should = execution=20 success closer elements game pick a prerelease a hype promised move = youve movies=20 execute combo kicks punches smooth a accurate realistic.
Hell game = oct lol ok=20 pov reales ther psx mint or evan fiscal wise hase quality mined gotta=20 powerfull.
3D""
Comparison Video or Reproduced is = permission is=20 Times a wmv format installed am video included or me of xp Notices = reserved=20 Wysiwyg ie cmenu menuitems Order us Portfolio Realls ie loads editing = templates=20 ours Html using is!
Yours too or unique directed on cast motion am = capture=20 crew directors Wachowskis script closely ensure fit piece level am = planning=20 design of Hollywood talent is concept a rates a creators attempted or=20 big.
Svenska am Portugus Getting Started is Notes Googles changes = upload=20 campaigns am Navigate quickly easily bulk or keywords text offline paste = or=20 Circulate proposed!
Scouts is resumes tabs on with Scout Posta = Createa=20 Introduce sending resume Manageyour am it Competency ˜˜ ßicˆ€`õ inwave.comm: hrndva-01.mgw.rr.com tøè²W°ÍÍh]ÁxF_t `íæ‡ô such address usercipie leÈhœí address userchss¨Xÿís ˜˜äiseˆ˜aä å(‡ñ Žõ"Adre ‹ö@G¦Â| mx1.mail.spray.netiedqàÕÖh|ñððW¿. Wonde onØÈJ ndÈˆÞ er¸€^Èrs¨ :çde˜½˜Â³sˆ:ì mx11.mindspring.com:| pYÕ ΰ ,A¤@û øôd ;oÕ†PÑýxˆèMAIL FROM: mBNOUÈæЩâON MON OCT 30!  AD˜ÔCN OCT 30!.  mindspring.com  mail2.logitech.com H íÀÃWh ëÀ‹ld°È´Ûeldried ed˜`Ð  Hˆ°Wœ  °Ðö0œë €QÄ=‚dret € &ý@ such address usercipie leàødä address userch ssÀØñ¥s °(‰Tse Px¤wh°—ëtbooks.filtre2.pimec.netl.org mail9.aj-badalona.esrg mail.cooperaccio.org ઠÈvB㈊$ˆ/çrown Darien" us ôÐ(¿gÈ`aõ address userchss¨€\s ˜ðLMseˆÐ¦ЀõâÅ Q6ç  £å8]„T0ã t (kð6ì such address usercipie leØ8€ó address userchss¸ÐÛãs ¨h#_se˜ jå ˆ8]Á smtpas2.vodafone.esorg A €QÕãäŠ reHýp&,hãÔ ÀXÞÐ4×€QHþ t X!ô ­Å such address usercipieAsA//sG/wX58vH//yH5BAAr/SUALAAAAADoAXwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixokWC8C5q3Mixo8ePIEOKHEmypMmTJzOiXMmypcuP 9mLKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qEx4RpMqXcq0qdOnQl9KnUq1akiVVrNq3cq1q9evYCFi DUu2rNmzaNMmXKe2rdu3cOPKnUu3rt27ePPq3ct3JdS/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmDNr3sy5s+fPoEOLHk06Zt/TqFOrrlsaMofWsGPL5onl8+rbuHPrtjq7t+/fwIMb3U28uPHj yJOfTqC8uXOWIJ5Ln75XuPXr2LPHps69arnu4CVq/6/pYbz58+gRb4USvr379unjy59Pf/j7gUHu 67f7hG79/wAGKJwoP0EkoHz7JejWgfEp6CBVQH0goT0TziThhR/IhOGGGcZ0IYUecmjhhyFiSNOH HdpE4ooVeniiiBpOmCGJFLZYYokmjvhiijnW2CGLPzIoZG8GgujiiUdqmKSRPAbJpJJQGplkkzml KOWVWDrJY4xLYjnlkVZ2KaWVW0Y5pmkPOsccWUFRaWGXTiJpZpY1xXnmnHIuSaaXdL7ZZ554culn mE+aWeaQiJZW5JZ7fgmmnzeFSaidh+7UKJ2E/gkon5PiNOOgdeppKJpploqSTseE+qijY9IYYqSb Mv/Z46s8BUkpnpJGCmOsma5aKKS2iprosKItGmWch9opKKRiaqmrpS7e2myscKqoqrWrdvqotKZ2 yxWrIO55qaebalsptW8GO6Kr1WIbqLbuhjtttPT66e29IrU5p42fvsuspr6O26uS6ra7r5y5Xhso nMqeWbCYxEbc27kA59piwsxW6iafgGJs8LEHKwzxvFd6PLDEKM+Goo2acmgry+z62CSZn9LI8qgx zpxznRf3LCm/N/vYcczjjpzy0Ug3dXLSTDctWJEqJ43v1B45bfXVWGet9dZcz0T112CHLfbYZJdt 9tlov8QPP2m37fZba6NdwNt0m9T13QJWgndNdff/7TdYewcu+OCEF274ZH8nrnjiuyzuOG6HRy65 b49Xbnm+k2eu+eaHgcL559ldLvropJdu+umoOydJ6qy3Lh3osNfUQ+yKieQBam+4rjtLtCcFQO/A F5iWOt0BsPviwQ/1e/LM53S8QMY/L33i0U9vPd3VX/928z4tz/33NJE+z0LZa+82+Oinr/767Lfv /vuAASC/Pd4jNn9M8tfvmAD8C2BP/zEBoEz8NxMBBpB/BewfAf+nQP81EIEPdGADGWjAAUJwgQB8 YAIRaEEJdvCDC8SJ9/KnP/yVcCcklAkJ86fC+ekvhStsYQuXl8IZ3o+F9HPh1UZ4wsLUr4eKwWAA /wtIkxAOsYg1EeIR/8fEJjrwiARUohKJuMQmWtGJA0RiFafIQRGqcCYj/OJPfoi/MtLPjDkEoxjD iMYzuvGNaKShGNuItBcy5n5w3F8SqThEIxrxikucohYHWcVA7vGAWSzkE2+CQSkS0iZypEkk86iT EpJxjm205BzxOMmasLGTlExZD3GoQze6kIcmNOUpyTjJG/6ulWxkih/5yMRZPtKKjqRlIhPJxUPW 0pBU/KMho1jISmKyjKR8oyuV6Uk1HnONktykKZ8ZR2RC8kAQOeEnX/nKVJ4xkqWMpRm7Oc006rCT BvFJOhnYwQoSc5fwPKABFXhLQNJTnsJ0pCBx+f9HfRbTHutkZjSV2U1wXtKZmUQhD3E4zR9akqF4 jKZzxnjNcVpUoMkspya/OcOLcjOiUHnnFt3pS3i+05aPFKlI+UjMfaIUmIsUphfpWM6GZvSZBw1l RS8px43iNJRAnIwRLGPHT3r0i+Cspk9veFSOEmalgtwnIK+4Ul0q8pD53GUXX2pPrVZVptUcqFHt iFBM5lSnnYRlM8t6UbYezahNpWFPm+rUsiZVozVtSi6ByddfZjGEUI3nVf8q2KiatK+4ZKlgB5rQ sJITlHAkqzQRmtbGipOSlw1qeorE0BzKlZvmTKMJY8hJT5Z2tDAEbWkDuhOD3FOAGeRgbOmpQQ3/ UnCeXZRnOy/YSBBuFZ9brSAFhzvSBbLWoRFdpTk/a1qQdtazaqzhCpk7TohCt6PXXZ6CfCcUzS6F tToBb+GOKzHtJoi7QPHudwuiTvZKDrzqpY/3dGOCjRjluTkBaWDEixP+Ds6/Epso/AbcPKglBcCe QbDUzIcXpiiYM+vMR9YYjJcYrrW17lUUe/PBYZlwWMI26XBMPh NtffÈH ‚ €Òná€ÒnáÑnáÑná¨R5þaêë€H»ç€(Âç€àŒö¸/ÁàŒö¸/Á ‹]]ìdÄrmF¾ùÆ ˜ ØÕËùƈ3[áX`H»ç€(Â瀠˜˜˜êë€üÐnáüÐnáàÑná8Ðná8ÐnáÐnáaï€0 €p è€ÐÐná€Ñná˜êë€ ˜ÑnáXÞnáëTáhÑná€ÑnáÀSæ€üUá àÑnáàÑnጠyጠyáÒnáÒnáÒnáÒná@€:xø‘zá$°ÒnဠyáèÑnጠyሠ˜(0ßnáðëTáhæ;áÐná0Ðná0Ðná"ÓnáШXáPïYá"úÒnဠyဠyáøÖáËF)Ðä*¸Òná wsnmp32.dllWSNMP32.DLLh@•Zá CMVa$vk€Š4LastDayReportDWÿ GffvˆÓnáàŒö¸/Á 7Ká ¶è€HÄ—âÑfâNtFs[ ‚šâÙ´táá[CáYˆâ1©âa\áIoNmNpFRlCollectedData_21447.xmlCOLLECTEDDATA_21447.XMLü·Xªÿkpá€êpáÀbfâÀbf⢶â¸"â@ORx½›â¸x\œÿNtfc SrSCܶ©âܶ©â(v¶©â$!ùL÷IᬯWá¿g Ntfc @€68À+uá$pÏZápÏZá(ÏZá¨ÎZá¨ÎZá   GffvPÕnáàŒö¸/Át€;Ká CMNâ CMVa$vk €1.LoadedBeforep² FSim]¯‘DOWS\system32\SHELL32.dllers\Application Data "h NtffÈH ˜ÀØnáÀØnáP×náP×ná¨R5þaï€íë€P½ç€0Äç€jµ¥û+ÁàŒö¸/Á†|í\ìdÄrmF¾ùÆ@2 ØÕËùƈ3[áX`P½ç€0Äç€@22íë€<×ná<×ná ØnáxÖnáxÖnáHÖnáaï€0 €xè€×náÀ×náíë€Ø×ná¸ÇnáÛná¨×náÀ×náØQæ€aEkuhUieqIOWqIqCiHgkwsoCjq8 wAsvOqNOEaM0yqAoEaMruqMroaM8+qOCIaM32qE/WqQnMaRIOqJGuqSYk6ROOmRMGqUd8aRUWqVW +hQ/d6WE0X5AQQBeSgD28KVeKhNjGhNfaqZnSqZiqqZrmqZouqZkWhNtKqZgGqZuaqduSqdseqd1 yqZviqd26qd/2qdo6qd0CqZnmqhjCqc0/6Gnb8qnjeqocpqnfaqohKqohuqohOqelWqmceqpn9qp MyGqYRqqcvqpoIqqddqppJqqpPqqo3qqqVqqs/qqm0qrrmqqudqqsZqrtSqrs/qrwoqrqtqruLqq 6vkKjQqslSqqt1qswUqs0Vqqlwqs0+qrx4qqsbqpyGqsZUqr3Dqp0Oqtcfqsy4qt23qu2nqrqwqr 6vqtvCqtmpMFl/EKyqqt2eqp3Sqv2Lqv7Pqr4dqr8dqv0Fqt4fqv+gqq5pqu+equA0uuCsuw+Fqt 54qo6Lqrvvqw5NcQ9voPhfqozkqs37qno5qnkzqy+/qxeHqp7MqojLqyAluyNhGyKXun4P96rJBq sSyLEy/bs8P6sxFLrfjasDgLrwSZdT5xr0EbtBarrkt7s9FaszbLtNYqsk8rtSgrrzQbrAjbtFCb sF47tFdbq5BqrFobsfG6tUu7sOtZs66KsLoatVVrtRXLs07brRRrtiELsYEqrXBrtOLat04bs0Ob twErtzhbuKqatgwIEXs7tvk6rgYrsUIbt1I7sYQbuZVLsOOquXDruZIrtpE7uZ37ua16uqD7s1zq E3B6qH+qsDZLqa47u3qappbarnM6sitbprJbu7y7qL+LqMB7ulNrsrtruCQruIAKspY6qJIaqfAK uLQrvM6qqY3bnvXHtsCxuvKpvVr6veD/u19SOr7JAWTke77om77qG6Hh277u+77we6XrO78LEb/2 e7/4m7/6u7/8278bR78AfBD+O8AEXMAGTDgHesACeAQKLDi3oD4BHMESPMHrGwoUHIQb570NvMH7 e8EAzMFJ4wSJ4sFl4wROQMLze8IorL4qLGAg3DQi/MLEMgT8maXAt8KICBrTcQU4vCDEp3lEcXWW N3Z2l3jXd7Q9nDpnt8Q+UXjGF3uKJ3tM/G9WQL94l3lB4cRO/MREjHY3kcQKsQqkc8XDV3lWh3lo rMU0EcWYd3hqDMa7I8VTJ3rCV3xbXHVEfMR0PHpODMe6M8eVZ3Z1HHumZ3x2TMZrDHd+//w3QIHF XDzIxJfIhgzFW3zHMhw8jnx3kGzIXDzJP+zGSdEElyw411fKZpx51ad51DfE02d9gTzKhmPD6rfI rBMatJw4sHweVZDLvAxyTdnL1gE2wHwd+pFezXcTq6SIyOyA+5dr+cXMb6cUAkdT0Nw9oxRfo2Qe BUiDkrODYqVTYSWF0TxTyvMYkuV2yMx/5NzN1CQ457xW0HdhbadZ9ByI5qyFEojO45zPh6OH7hxd HmhRELWByxRaawRanIbQA/dRCliCx8xrBS1DYASCqlVaIfh3zkfRH4hdBOdQy/XRzffQAHjRIN13 Eh3SDH3SCq3RqIXSqCVDxzyHG93MNv9HiajEU1jYgh4lWeeU05Q1V3X100t4TUBEVp92V5+2hZvE Sj5NgapVXRqVgFw4hKnkd1Od1DgdeQmF1FJt1PF809MkzHHVg0d9U58FWWOFhaJVgdLF0+o2U87l 0A21et8cbXPYUyC4gnG11zRdg3xNXUnVgWTd0BHN1fCs1wLNQsXcPXS9e0GNUfgM2UA9eax3TGk9 zlkNTZMt0INo15ud2X+91y44WUit1mqVg2891y+Y2qtNgZrdNNl00ck8XfvXht5E0QGo0alVQ8vF 0CzNfCidVrxtQxO9UCu929mlhs9n0m3Y0b2NhrRN28Ut07qd0gn90Gro22zYf9fd3Tb/FNO9Hd5i HTnKnM6e4c+M7czi7NplFs6G6B7No3/dVd6KId/WjM0RCNHVbN/D3N/+Dcyy/N9gVxU5kBsCLmqm Qhg+1c5CqIj+ €QZ€g€€booleanDisplayNameSupport en mode 16 bitsDescriptionLa propriété Support16BitMode détermine si le mode 16 bits est pris en charge sur le port série Win32SupportDTRDSR 0+ €<E€Rb€obooleanDisplayNameSupport DTRDSRDescriptionLa propriété SupportDTRDSR détermine si les signaux DTR (Data Terminal Ready) et DSR (Data Set Ready) sont pris en charge sur le port série Win32.SupportIntervalTimeouts 2+ €U^€k£€°booleanDisplayNamePrendre en charge des délais d'expiration d'intervalleDescriptionLa propriété SupportIntervalTimeouts indique si les délais d'expiration d'intervalle sont pris en charge pour le port sérieSupportParityCheck 4+ €zƒ€¶€ezdWMts0FA91E9Y50sN+tc++m2ua6/+6MSi66dvULJuTZpv2MIO0XUNgLrf7IAd+mef16eu gMcu2chf+CXO1ad95G6NboldgsX//9K/DkvA74Ekn2vKX/ZK7+ye/v163oTP7thOmPqqje3JX+ic D+2obeyyz3vvPHlJn82OBRD27AEQSHCgwIIJERpkqLDhQYQKI06kWNHiRYwZNW7k2JEjAJARQYYM OZBkyYIkTTIsOXKly5UpRxKcCTGmTJM3F7bkSdOnzpkuW1Y8ybKoz58TYQo1mDJmUYowdzbFKfJk zqBXezq1alQpUqwop44NmvNmzapma24V69HtW7hx4f6jW9fu3X9y9VpsSnXvX41+AwMmXNjwYcSJ C+Nl3NjxY8iRJU+mjFfx5bGYDUvN2FbzZ9ChRY8mXdr0adSpVa9m3dr1a82VYc8O/13Z9m3cjgHk 5t3b92/gwYUPJ36b9nHMxZVXBrnc+XPo0aVPx43cOmLq0ndn597d+3fqhz13Fix3qOLxO78i5VmV 8/WO6eHPpw9f9sbyRBfi/wg6/34AH4KoL4ciAk+45g5UcEEGGxyuP/4kwug/pfzrTKQKHXqoPAdz 265DEEMUUcSfrjqLJZuWUssvpg5CqUUT0XLqqBLBSovFrgikCUADR/TxRyCDjM6jDXdsqMgMsRow SbF2XFJJAW16UqslCZRSIiuNxLA+Lrv08kuKmCvQxYTQEizLl5gka0wkvyozwDfJHDNDNM3i0R4h 89RzTz4jI5LNKpPk8Ui+4JRzw/849eNqykDnZHRORMGUdFJKJc2qRqjey9RG9ZZi6lL2mqSqL62S OpFUo7Ya8MVKW3X11eQoa9VKRWnr81Zcc/UR1o/Sk49XYIMVlr77hiVWV2STVTY7Y5t19llowVx2 WmqrtfZa4kZzI1puu/X2W3DDFXdccss191x001V3XXbbjRZbeOOVd15667X3Xnzz1Xdffvv191+A AxZ4YIILNvhghBNWeGGG+XX3YYgjlnhiiivm0pnYGtZ4Y465s/hjkEMmrGOSSzb5ZJRTVnlIkVt+ lhiXT1t5ZppRjvlmnG+ueWeeG875Z6Ar7nlooos2+mikgQx6aabZ7VCepKOWemr/qqsOuGmss9Z6 a667Rq1Yr02zeuzewv6abLTzMntttp0l521y7IH7bYToFgjuu/Gu2+65KcI77ogA3ztuu+Wm+2/B 9Tac8IkUzztxxR1ffHHEB6ccccAxb5zvtjsPk7LE7657dNJDD1x01Ek3vHG/VZdbdcFfT73wvTd3 HXLbZ09d9sxRjx33wE1PG22PYtc979Iv6r0i43+XHXbTny98eddFD5365K+vfvXdn99de+u395xt 2ZqHnXfxpWceI8ZPD1/997G3qP3X5UcffPTjZ9193fEHfHgA+ol7l8te8FpXO/5Nznf86130Gvg9 2t1vgft7oPQi977qOW+B1Ptf/wA9yBj3abCCCfTe9/b3OA1K8HjtMx8F82e8F+ZPhiPsXgorKDyr KeGDApxgDyNYQhim8HhDBB78uNfCEMbQhfUbIvROaMINHm+HUyte8qzowyUCkYFbhKIRvRjE83XR gbfzHhLFGMbxpfEtfbtc5qaHws0RTnJwfFwdNee7w71xcEHknAIpZzne5bFvFwTkHgHpRvupUZGL ZGQjHflISEZSkpOkZCUteUlMZtJbYNNkYqYoNTuiUJBsDN70IPe7UTpubqfEXORc+UpVpvJwdBSl KSNIykKScJWyRN0nU+aWIoJPfjYkoRKROEb4EZOIS3xg9IzJxe6VMIMTNB0MO//psmPOb30UdGYN tdlEb2axm7o8nTUTCEYwFpOJB9yeOa8ZMncOc5tJtJ8ZocnBHl6xmuyMpjTP2bp0io9+5PTiO7FZ Slr2M500DKffSPlQvS00lj+0JwL5iU5++rOecRynQeF5QnlmNIYB7WcZsShDK4owo+7UaDEH2tBS knSGHr1ZNufp0tnJ1JwqfaI0lyfEnrLUmkBdJ0H/adT00dRiygQnGbs4zZti76UmXaZT2ynQJzqT pAO1J1GViq77QFSs83tlBm3pUDbu0o+GrGMtaVfWmDLvlpLDZS0VCNc29tKXJ/tqX/36V8AGVrCD tY+sCGusvYbosItlbGMdO5//YjVvlXv84R8ni7y24nKXrERrZuHaSj7OUbJ1BSJpaXnWXPoRoqn9 I0LleNlCEjKxIILLVq26QjTONKVPhSJTjRjQigIVuBe9LWYt6lvb5lSJ/bviY0fz0haacbjGTeRR cYrSfCITmkVtKHShGsJx0o+FB9TjVaWbEfGW1LmY8W4Skfpb3X4zmhid7xnra8Kujs6mV10nfftL Xuz696YAzud652JYqWZxvqzcJyrl61OA8teGc2xtc22KSooSeKo3vC9DBSxSBO4TT7O9VUKj21ML RxHFVFUnURNc4AJrFqSqvK97N6w/CKvQvOxDbzIFQuIS+zbA3+TpALHK36wSyBi3SmbxicMo0xku dLn6DK4Wk4rB5QG5QcDcrlZB2lv3ttS6Qe1ybqvaRC83Fbns1O4XiQtOlhY1zgbmSGUiyku7cjTP hDQtXSm81gqf1pSxTSue7ypIiwq6mxFta4UJqWeERjquje6glvVE51ZZekGY5nS7ONnpLtWlBJq2 VxhI7SBBCOLUlwa1lwTRak+u+l+qlvWPYP2lVN9a11sbxK59/WtJ1VrYnwR2sZs1bGQnW9nLVpmx FTkJrjFb2p+cQMDGMG1s8yYgADs= ------=_NextPart_000_000F_01C6FBB2.5BB44890-- From vfdvrihuqw@pacak.com Sun Oct 29 20:01:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeLWO-0007Mi-7D for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 20:01:00 -0500 Received: from [124.49.249.20] (helo=[124.49.249.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeLJp-0007fy-44 for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 19:48:03 -0500 Message-ID: <001301c6fbbd$0aaa4700$14f9317c@yourvubwil6swv> From: "LivingA" To: avt-archive@lists.ietf.org Subject: free Your continued donations Date: Mon, 30 Oct 2006 09:47:56 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C6FC08.7A58B690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.2 (+) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 ------=_NextPart_000_000F_01C6FC08.7A58B690 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C6FC08.7A58B690" ------=_NextPart_001_0010_01C6FC08.7A58B690 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Subwaycdt a Minutes Ctauzth up contth Divisionth Mile Rockfmwth = Divisionaa in languagea a Beautiful Minda? Owna House Homea Life Worth Livinga Little bit Matter Midsummers or = Nightmarea or Night Outa Operaa of Sang. Subwaycdt a Minutes Ctauzth up contth Divisionth Mile Rockfmwth = Divisionaa in languagea a Beautiful Minda? Home our in Owna House Homea Life Worth Livinga Little bit Matter = Midsummers Nightmarea Night Outa in Operaa Sang Berkeley Squarea Passage = of sun a Poke Eyea eye. Was last modified October all text available under terms gnu License of = see Copyrights of details. Retrieved from Discussion Edit page toolssign is linkin bokmlnorsk of = Srpskibasa a was or last? Home our or Owna House a Homea in Life Worth Livinga Little bit a Matter = Midsummers Nightmarea Night Outa Operaa Sang Berkeley Squarea is Passage = sun or. Rarely any need for of directly pages Find fix a them at pageslinks = Zprevious next is shown below may on subsequent of categories Wiktionary = Ambiguous place names cleanup cont Lists roads. Donations keep in running to of navigation in is process in of a = resolving conflicts a that occur when of articles about a? ------=_NextPart_001_0010_01C6FC08.7A58B690 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
Subwaycdt a Minutes Ctauzth up contth = Divisionth=20 Mile Rockfmwth Divisionaa in languagea a Beautiful Minda?
Owna House = Homea=20 Life Worth Livinga Little bit Matter Midsummers or Nightmarea or Night = Outa=20 Operaa of Sang.
Subwaycdt a Minutes Ctauzth up contth Divisionth Mile = Rockfmwth Divisionaa in languagea a Beautiful Minda?
3D""
Home our in Owna House Homea Life Worth = Livinga=20 Little bit Matter Midsummers Nightmarea Night Outa in Operaa Sang = Berkeley=20 Squarea Passage of sun a Poke Eyea eye.
Was last modified October all = text=20 available under terms gnu License of see Copyrights of = details.
Retrieved=20 from Discussion Edit page toolssign is linkin bokmlnorsk of Srpskibasa a = was or=20 last?
Home our or Owna House a Homea in Life Worth Livinga Little bit = a=20 Matter Midsummers Nightmarea Night Outa Operaa Sang Berkeley Squarea is = Passage=20 sun or.
Rarely any need for of directly pages Find fix a them at = pageslinks=20 Zprevious next is shown below may on subsequent of categories Wiktionary = Ambiguous place names cleanup cont Lists roads.
Donations keep in = running to=20 of navigation in is process in of a resolving conflicts a that occur = when of=20 articles about a?
------=_NextPart_001_0010_01C6FC08.7A58B690-- ------=_NextPart_000_000F_01C6FC08.7A58B690 Content-Type: image/gif; name="Mile.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c6fbbd$0a710e90$14f9317c@yourvubwil6swv> R0lGODlh1AF4AYf2AA0AAIwADACJCHOFAAgAdY0CiANzesrLwLLXxqrK5EMqDW0RBoIkAJkpALEp DtcXBwRECCc9AD5HAGY8AHE+DJVJAMw0ANJCAABfABZSAEZiAGhoAHlpDZldAMVYAOdYDQB7AhqC AUJxAFGBCnuLAaxyAbiMANSDAgCSByKrAEOgAFmSAIypAKOhAMOgANuYAADIABLOAjHFAFzKBX23 B5m1BbS0BefNBQDcABrTAT3kAGvpBXvRDZvpALrhB+XbCgAAMR0JP0EBNlMARXMAOKUNRbELQN8E Sw0pQSQrSUsrRm4jMYchNpMfM8cfPuQsPwBFSSBKOkU6R1oyR4dGQ5hMNb0+O+I3SwRbNC5dNjxW TmZmPnZUDppXPLxTN9dkTAx+OxiMQz51RGuOSXKJPpWAOch5SuZ6NASlNhiWTDGRN2iUSHmqTaeh RrmTPtilRwC5RCPCOUTEQVK1N323PaqyQ8m7Quq2NQfqMhXjTkHkOlfhTILVRJ/iOLXbRdngSAAN dxICe0wAh1sAioEAe6ELc7gCgNIAigMTjh4ljkUdhFgmjnwcdaIZeLwcd9sVew47dCg/ikRAh1tE hHMxeJw7gLUygdk7iABjfB1diUtugFJVhnFnjpJai7ZggOlYgAB5chV1gzh1i2KEi3N6eqV0hct9 dtiDgAeihi2gg0SqiWOfjISXi52fd8KWjdaRhQC7eye+cTHFh1i8eoO8dZ7GcrSycdXFiwHkhhPo gDzeg2LagYXSca7ZiL/beOnbgQADtBEEyjsBzFIBx3kAxaEAvs4BuuIHvgASvBMsv0UiwW4btn0t zJIgwMcntO0uxQFCuBk2tkVIvFE+tI5Du5NLtbVMwtlIwgBXsRFrsjZmw1JguYBjwZlpwrhYxtlc xQGJwBqMs0Nztlx1zHOHzqR6v8iLsuyBzACluyqeuEaYwlSuvoSmwJKXt7GVuuytwwCxwxyxvDK6 zVm8wH6zsqbBxP/17a2oqnmLgv8AAAD/Afr1CwAD//8F+gD6//X/9CH5BACwx6kALAAAAADUAXgB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eB/0KKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMC/ci0qdOnUKNKnUq1qlWPSrNq3cq1q9evYLVe HUu2rNmzaNOqXcu2rdu3cOPKnZswrN27ePPq3cv3Jt2/gAMLHky4sOHDiBMrFty3sePHkCNLnky5 suXLmDNr3sy5s+fPLReLHk26tOnTqFOrXs26tevXsGPLnk27tu2GoHPr3s27t+/fwIMLH068uPHj I28rX868ufPn0KNLn069emnk2LNr3869u/fvQ62L/x9PXuPK8qfBqw+Lvr379wbPw1+8vn5fex/y 4/9QML9//gL9JyCA+/EH4IAEFkjggP3pl2CDB+pXIEEPIkihgxMGKOFA/mkoYIMQctihhyRmCKB9 KOYVIIcGHdjfiiziJyKMLsJoY4ILzpgQjhS+2KOMQAYpYYUH5Qjkg0HGmKSRNgopUIpQHuXQgkQm eWSRPyrZJI1Z8rhjlktauWWVVfoIJog/Illjk0zO5+ZF8uXopZNcatmimTHOieSXShK5Z5l4iinm nit6qSabWp4Y5aJCTZlnn32OqOOdZx75H5oMubgmnWcSaiGllT5aZ5eFIvrmqU8xuaaqW2oIaqs1 ev9KaJpXQhqop4HCymeth3K56ayoBntRmwb2OOeuY1LaZq4vagrhhnbiGmqvWLK46Y1XAirsthgt C22xdpoarbKJhmpsqeN26qO2uiJU4bVOOmsut/RCtKyV2hro7avETgqsuMlWyuq0r+baL5j/1qvw kypNKGnAHl4q48MZXrjhwxhKCi3CFotIpZoXh/wujhuXmCjFYfrI6Mo/xZbwwjDHHNfLMtd8m3w2 u8Xyzjvl7PPPQActNHM8F210fUMnrTRURzft9NNQRy311FRXbfXVWGed2dJcd72R1mCHLfbYZIPn 9dlop6322l+X7fbbcMctN2Vs12333HjnTZPdfPf/7fffgAcuuJt6F244zoMnrvjijC93+OOQRy75 5JRXbvnlmDfd+Oacd+75aJmHjndqJT1Uus+nu4cc6SSZ3jrqr6u+2+e0vycfALjbA8BYuQuE++4W pc5Q6QIUL4A9xguU/EDHE7S88sU7b3zzyE9/vPXRY3+99dU/z3z21CePvfTRf7+9+egfL7zuA/0O fEG9Q+R+++7H/zv7BM1fP/30Az9//727n+5y9z7eNOR98bPK+/CHlvApz3kFoR7zDCLBB1oQeRNs ngYxyMENWtCBEZygCDn4wRFeUIIgrN5CEJi/9rlQfi3En/98x78XytCGC5whDWN4wx36UDUrWSAD /xXIQjjFbngkqSAJl3i9EDoRgidEiBKXSEUSKjF8KaxgE6X4PRFq0R7C02EMi+gQIQ4xh/DjIQ5r 2MODFFGMO0SOGX0XwN3pkIAI9J8d6WjHBO6RgXVso/3AeMSFEO+JTKTiFSk4Qg+a8JGOTGEjOwjJ Cz5xi44kSOrI6EIB/nGAdASkQdBowzQOUZQ0FOMcUfnJFhpwhW58IR5lOMM7/pGTN7xjKAnYRo+U r3vey+QiIzg9832RkeTD4i+hSElJWnGYzbQkQ3ApyD3aUo0/JKVC7Pe/XObPjN1MIDbTo5I5vnGH quQjOtdpyk96cp3dJGRyHCI8YSaTmY9MJCXxWf9JK0ozihh05jEnGdB/ylMka2ynLAcYQFOqUZuw PCM8R+nQTsZSjmk8Zw9ZqEtRgrOGHa3lQdankHpaUpLOrCIKDVpFRSJzilkUKCL9CT1pqi921Ewn +4TIU4qWsqexlCggPzpOONLwlREVJDv1mMqlWrSiIZ3oKTUCwpWe1IRbfKBVrdrSgRb0nyjFKkAJ OtYpPpSH5+zoWbGJS42y861ARWtFUXM7P9axj6DEKx/1l9NB7vV+sxwkSeuSxOUZFnwaRKz4uDc+ YP7Se90zJmK7CL3tVZV7ldXiZE/6yzB+064MzasewSnA/sHPjwwdrSf9Gs7Qmta1wENqU1aZ1Nr/ zVY8tC1PbhGyW9tqpLe3AS59GmaR0k5TuBkZLEKUuzDmWmd15ikkYZzbHtHZxbfYfS5xkyvdwZwu H6eyLmT251MkzvMwpcuHegeiXvAeZL0CaS977dFe+NLXvvJ1L3vrq1/53he/6+2vf/8b3wALGLz8 ha979StesBywlM5BMH0nHF+D6JfC862whjEsYAsTpL8bXvB+N8zhD2dYwyKmMIizS5XzUNN15zVM SSQc4oJc+L4mrjGKbezhHKf4xBW+sYpzjGMSY1jHDf7Kg1PZx9GG8oeoGfCKg3zjH5d4xwupso6N zGUrg9jKRz6ykFlclnCKdKdQZo2CgbxmE1+Y/78ZfrN9jexlMHeZxCumMZDFTGa1EBXNAIyNhKd8 5fm+2cd07nGcPTxmIXt50Vomcpj7TJY/txK5pRk0m/esZz4PWdKJnnSnJ+xoPJ94zmE+NKWf4uLy 3rKX1KXLjEld6Fo/etGm5vGpdTxlVXv611w2cZIbY1zAzvLJ7Iv1XNIL4DwreM4LhjOBC4zq/0rZ wNBGdX1tfG1CD/jKw+6KsMYsEXKredVM2y5GlC0Xdj/E3KlhcLj30rYYF8bd4pn3VtDNb9ogLt32 1ll3g6dvsfX74M+J53FXiGm68OPh/LAHxB8+EIoLBOIXxzjCbfbibU5zNBG/uMhHLnGChDzkJf/f eM0aPs7yKgblFY95xmUOc5WjqtWm3Z8uuXlOfI+ldDVHudBTPnSQFDxsZSQjU3nZULeKxuISnzjN Uz5zm4dX3Wrd+VNhPfC1CO/kJh95xGte8qMj/SEcXSig127Up5Oc6BUnO9mtzi2ls7KpeO9lYooO c7BP/e10l11KFJ5HvOKx8Orcnc+vUhKpR93xGie6xs0+Ot5ipetqWbwhKZ81irA88KBfizhDT/rS m167KWEM5qvC+dCpPuAdQW7rM6dON2K6fqOviObRjtrXzh5zU3X5x/UOQ02uvriA9muyf5+3A+72 85+f61Raicrgnx5o5rylk40L5UA2Wa/vnL7/OO1+fYUhDqi8VKrLr3lmo+6e93I9KvMrx1ZZNtT6 PL1/LcNvdNhzxJ1rNH/010npl3xbB1VwZVRC9H5lVH0sJICUA2Ee5UPU91NOpXYLeHwVYU0JtXwQ CDfHtUo6V1oiaFfktVogVRUkyHPl11zq5nkX0XHG538bIXsfCIJOEX3x14JW92/yo4OnBVwM2BE3 GDk8WG9FyBNHuISZ94JMOBFJqBQBMIX2MIUBUIVWSIVZeIUCYYVdSIUDkYVYuIVjCIZh6IVfeIZc OIZVWBBk+IVc6IVoiIZluIZbaIdaqIZ4uIZwyIYEIYdkaIaAKIZu6IZ36IdleIZqeFBRmBMN/2GH YRiJbdiFkkiJlXiFcWiJkGiJnMiHm4iFBvGJnliJk3iJpliKYDiKafiHeGiIp6iKpRiLspiJk/iJ qPiHT6gRohiKpEiLpIiLwFiLvAiKmliIxniLvciJpziLhciHxQiJ0BiJtriKyGiKzqiMwmiMgpiL GbGL1TiK1yiL2LiJ15iJtBiOx2iL4HgQ3uiLwSiJmCiN8kiJ5DiP0xiNwwiPwxiP4siNBSEf/AiH e+iMAemK75iI2JiN/OiJZiiQ6oiL4UiIApmQ4niO2SiMviiR5viL9XiMxaiN9MgwjagTDlGQGZmQ 6JiMwDiNCnmRKLmSB4mO7miR+aiPbXiSN//ZiTqZk+OohzXpkh9ZkP4YH8Rlkvv4kzVJkDsJk6uo lB45kx7JlD0JkUfJk/WIk8G4jVLJjFv5kcQ4kj1Tkk9ZjRT5kFmpkrFolu8IlQe5jOu4lN/olsvI k3CpllOZlmg5lESZesp4iHSYig05kYvYh035l1opmKwokQg5mImphxoZmI95jlqYin3ol1p5iIRp mHvok4Q5iWBJknoZmk7hg6JZUp+JE6WZmqq5mm1xmq75mrBZNqw5m7oXm7YJGbSZm7q5m5d3m775 m8C5Mrw5nMRZnPQUnMiZnMq5nMwZN8b5nNAZndLJm81ZnUgxndiZnaVpndxJFNr5neAZnuL/2W/d WZ7meZ6OMZ6riZ7siZrqmZrtGZ978570WZ/2eZ+JQwD6SQD2sJ/6ORD/KRD7KaADCqD+aaAHWqAE eqAAahAJ6p/82Z8KKqEKCqEIOqERiqALSqESqqEbmqEEqqEQyp8DWqL/yaAFYaELiqEpqqIOWqEZ aqIgaqIiqqIg2mcxKqANqqM7mqME4aP92aMOuqM8SqQRmqNAWqRAuqQ/OqRFGqRPuqQ3CqVKKqRV mqRNWqVR6qRPuqVeSqVGmqVUeqS0sxJTKqVWehBMmqJc2qQz2qZgyqZaOqZqGqdkKqYBCqU3eqZr iqcNOqVciqU6uqdy2qV62qdGiqg8KoB2/xqmdxqnYcqjgvqoQUqoWSqoc7qmb0qoZ/qnksoQJKql mkqkCDGqniqmXyqkj9qpgyqqOzpvDpGnLkqmM8qneUqhk8qidhqjGGqrstqrt0qptxqpoQqmE6qn Y8qioVqrCYGiuHqpqGqsTkqrpOqqvCqrZapuwvqprJqmyGqownqsnwqpljqub2qsyhqordqoclqs 39qq7lqt3hquwVqo5Mqt8uqj7rqqIvl70Jqmw8qu5xqt95qvhlqt57qt9qqvhcqrXdqt2PqiIQqn 89qmWDqwADupiWqwjCheoFqx0kqnfrqlm+qm//quHfqwJ5uk8YqoLEuq3SqymRqp6kqyI/8Lrjcr s5UKszxbO2ZaoCO6oZJ6rDAatEZroUB7okn7oMMatBy6okz7oQEqo0+LrgFboVA7sNd6pLW6tVHL oU77or+qr0irtGTLoBHKqAgHqKxzErBwOafHtvjZfygxtxwhn3ibt3rrm3bbt377t4AbuILrXXtb uIZ7uCwxuIq7uFyDuI77uI7LuJI7uZRbuTIGuZibufFpuaCnuZ77udzJuYEHuqRbuqZ7uqibukYo uqzbuoKnurAbu/7quqLbDLQ7HqTZbrILNreLcDjTd3MnEVI3cUJXvCcXeR27u1XzEEEnvAXBdzJH dXAHeL2Lu8Q1dmEXEc37vNELdX63l8r/ezUOgb0x570WR3HoC3WAV3Ql973bW73B4r5gB73T+7zG 670iB7zwW13XG3lDR7/faxAB7Hfkm739Gr5uI73uS3UETL1/J3ZxJ8AziMAJ3HckV8ANLL0M/HYD fMETTMFko3EibL7Am74mN8KQh7+PN3Qg/DaE28Jk88IwHDX7i265W8OXux44DDrQtcMs5mLHZnup FXu5h2zFx3DQ91s51HZFHBFF3MTSl2apcXtJR1jroVZBVYE7OHwJ8XzIZxZxFVRd3ICWh30SSLfF wcVSvFC5JYPC98ZRjHZnEcZw3HJiXMcx48bWgUaBBE/clHh9XIC0BEqpBX5NJlpMZcSD/3xXQkzI bLRXouVaO+VkkyzJxlbJtceC/BNYhtfJhBxPq7V0nfzHkXx437RLquXIuBfJQ4zKjgxbnwyEspFH QtV+G4WBikzLr3ZmFGjL5rTJxJd3wufLThVVp0TLT7XL3Wd46PRqedVLvCzKt2x/07xUHChRIXXN 6Ed9uhzM05HNWjfJ90dL45xQyjzIDtjK48fGETV+62yAUYV+U6V06fd9emfM+JzL8ZfPsOxNn5XN r8VazexTCsjG3Ccd8VzMwnx3RcXOBghXB9h9Dj3G2STR8KzQaGVpUnVpFs3P4YyAFxjOWUfHvOzP uCyCb0WBC30z5cTIh4d7egVbiWxsS/98yC9dyLpsypf8WaFlymekcK1ce0N8VzTdz6cl0zcdyoj3 0ny1yqvM00hdyjzHV1Jc1E8N09/H1DW906g8yskrHGgjy3c8F3q8ZHJ8xHFFW2XNuAe9gWJNRGLd 1o3sxLkn16/lw3htRHyZ18umHnyNXTf8103IMhv4xm/NcIX9f4ftcUfd2PAHxlC8xs5HFcI1Rzzz EYtNxmfNFA1X2bV1xp8de8OX2WON2dFlNgqkgk6cg6tt1mUcx4zN2WrM2k9B2u+hySMYy4gcy9Lc yJzMWt7H28LNyiBlyFsd0IHs1X18zMnd029E1K7c3D6N3Ess1awc3MqnztYE3U+W1In//MqcjCrn 7MwcPYED/csm/dHfrVTPHXxLd895h8/OXMtjNM3kzdDSTN7zrdLzzMyLvFGkJM/PjNEznczuvUvV AcTlfd+frNIalX3Zrd69nE4PHoQbrVAPHn46xX+59E6pzHYhzWT6Z9HE59HqHNAKpX77N84chYL1 7YHfMdr0nXUQXeHDjN84zt64vOP7nd4pXc0MLlVbDOL2vdBYzNAvntBJ3tEQbdL8vXYQduTQoeCH jNRX/dtRTXjhneWMPNQ27dJbfcmgrMnCLeZfTl6QTII8XdSZHN5WHdNtXtOInNtsDtNQHcp3Xedn /so4PUCXPdumvdl0Ydu8oxrIReim/4naxRXZMfiDiO4Rdg0YkY4Yky7USRPYgo0Wf57p92YcnJ6t e/3prxfjkuzWiBeDbQdAXH0YjO55lT3VK9jqXRzXo8fobI7Hj1zqUOjpXIzSVazIic3YUs4Wnv1/ oO1Q/Gx9go7rTa7sQ17aa5Xqzl4ddCzZo4TMGHHosJ0WxV6Dxx7la/VbsU3Rzy7GvdXG9QftRFNO Fu7TwW1R7uR9qazmyz1XhnztlOzmKxjdVe7cmCzTuY6CJshk+hzuyr7l2K3buo7nKF7v/K3v3819 p97lf3zFGRXifM6BG67NOV7VR73f0RzdKf3e8G3E4z3P1JzWHA/uFjjrAz7QD13QP/8+VA/dgfVM 4K6W4rx8HLPN4P/zUStv3xvezOht0L338Biv4StNz7vs4kh/zEYPUUJl7eDcy4EG9TOfVhJvztZ8 8wSN4trN0qln4zK/5DiuTSI91iXd8kXuzyOd826P8lyP9U4+5Gmt80Be8nO/z/g391gMRyaO8jpc 6lTt3HJe5Xh+5aqV1HmO5XcO5rv9V8eWfVbu5XAe5+D95bq+8O6cf55s55Pv8Ay/yY4P1YYf+h9u yfO+fbHl19z+7cTe2qo5+Nwu62hR6cAumjwv6p2D6TIzw+l56cB/H8I//PS2cD9Yg9KeEVDc+YXc 3V1+wMafFOJu1sDV7bRN7nnf8bz/HxG+b+3lzuywX/3af/cNHnzTvxefn+8kD8uiH1iqrO+QTPrP X/pq/lD0Xn1onP5S0s4IDhAA7NkTKJDgQAAGBx5EWJChQoQLEy48aNBiw4oRJVK8SLCgw4sKO3Lc qBEkSYopVa5k2dLlS5gxZc6kWdPmTZw5de7kmfPfT6BBf3YMGTHhRIYoH3pEWjLp0aVRLULEmNGk UaxXVY4kShWiULBhxY4lW9bsWbRp1a5l29btW7hx5b6FSTSrQ6VOi64UedXuUqpKm9rdG1Vr36da ey5m3NjxY8iRJU+GfNSyR6YfNaecCLVzU4xQM2e2/PmyRIgiP2MejFQ004aiZcd2/0rZ9m3cuXXv 5t27N2K+voUPJ17c+PHcZpHvfM058PK50aVPp17d+nXs2acv565b+3fw4cWPJ1/e/Hn06dWvZ9/e /fru8eXPp1/f/n2W7/Xv59/f/38AAxRwQAILNPBABBNUcEEGG3TwQQgjlHBCCsPD70IMM9RwQw5j qvBDEEMUcUQSSzTxRBT/6XBFFlt08cXkUpRxRhprtPFGHHPUcUcee/TxRyCDFHJIIos08kgkk1Ry SSabdJJIGKOUckoqq1zoSSyz5NFKLrv08kswwxRzTDKt1FI9ds5UE70y23TzTTjjlHNOOs1c8048 89RzTz779PNPQAMVdFBCCzX0vP86E1V0UUYbdfRRSCOVdFJKF1Ou0g4PJdQecjolh1NPPx2o04U8 HdXUUkkFVVWKTBW11JRcfVXWT1lFdVVOY2X11FlvvZXXVWVNtdZQSUWVVl1FFVXTQWcdFdZnoXW2 1WhzpfbUWFWattptrfV2V2xb7bZXXaG19tVzo1X2WlDLjZZZQdHlNlVpW1p3JXnRrTXbcL+lV11+ qXX23mv3fbbbfvMN2N+BoYVXzZgUnpdgec2t2Ft8MWZ43oMBfsngXAmut2GPQ672ZIxJNhllTFuO z9ZQRxZX25nZxbVkf1fO2WB9wV333oqBTpfXaUFGWV+Zc3Z5aflEFjrohU+WmGj/dn+2uGONoV5Z ZI95rhfgqaVOGmGmy5bsUpwp1tpctqdGmuN24VY1bLBx7npojb+l++10KR7oYUCLLnjwo+EW+3Cl leab76sN3/ZxgW3OuurGKQL8z5iDndtWqsUlFtzOb0bWV2BJHzbouYEN/djSi705ZZ99TV30vy/v 0+wLbb8d9/t055P33n3XE/gohU+SeBiNRxL5F5U/snSijS0WdZiH9VzzXV2P/nPZYe7+V1pjVhb8 6U9PlvqMPRdf+2WdL1Lvq4W2eVyah3a7ccErh5xwq+m3n3K2saxw//OY+3IEk/ulL2rnIhvd9Fe/ AOKNbAFE2sXmR7O1CdBoFIQg//M8eKWyWBBvGqyf16Jmwf3lT2sp7GDeXNg2DLbwYhsc4LQMSKSe jc9nCvwaDR0YPfN1boXkA90P49ZBqGXQhVzLmulueCMEBoxrMywh1iSHQv71sIopY5kRSRhBHy4w WDI03Ac9aJYEtrCL3FIiFr92xS0y7oQuoSIY8+ZAOeKxdk+kUcQAWEYYIo6DPHTaHf/ovwH+EY6V MySs8rgwEZoReJfKHPash6/uUdB72mKf6361Ou9pT3WvC9311Hc+Tq5Ph5e0pLX4GCRJZuqVP4ol h2ZJy1pq6JY+yqUkdymdXgZTmMMkZjFrmS9Rli+V3COX6iqJvV4VcXM6jGbrPv+pORmKUpPXBCUr Sfm6Sm4SlddjZuyqKUBjXiiDiOTY/kr2Nvmt8Y2JcycjG5lIe3JRkP1KmCLXaTETLm5n6ewOJSdH uEAeMn/2klwjmVhIQNJvb46U4gLHZ0eSDXGQkbsgHQdqj19GRyYblNhEDylBj9oxWw1EHEvFZlKd lXGFI7SiCQc3xRgyVKcLJSiGIDrPO0aTczEF3T4N6dLFcfOZI0xgDpX4v5nGU4t6jKQIZ0fTnhKH kuDjlxEhajUxynGJDf0pE2n6TLdx9Z5TraJU70bVlDI0fyGdix/tidP0wfNfDdUnX8Va1i8yDmGA Xes7o2o3CcK1o3IFalaHoxyEgTKyqQhFKRkjiE9EupSeCY3sWtkpN86S9aR85ajG6PqdY0kvnNoU YieLplRzojC24wTnObGJK2WKTrV7BeVgZ/c9Vs7wk8OVpjhdedrsOJZpyIWLcp37XMagDbqTYi5d pntd7GZXu9vlbne9W5Pqhle84yWvgL57XvSmV73rZW97GRUQADs= ------=_NextPart_000_000F_01C6FC08.7A58B690-- From avt-bounces@ietf.org Sun Oct 29 22:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeNw3-0006Pm-7m; Sun, 29 Oct 2006 22:35:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeNlJ-0005Jd-N3 for avt@ietf.org; Sun, 29 Oct 2006 22:24:33 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeNlI-0000PM-EV for avt@ietf.org; Sun, 29 Oct 2006 22:24:33 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Oct 2006 22:24:28 -0500 To: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> From: Randell Jesup Date: Sun, 29 Oct 2006 22:24:26 -0500 In-Reply-To: (Colin Perkins's message of "Sat, 28 Oct 2006 14:58:20 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 30 Oct 2006 03:24:28.0166 (UTC) FILETIME=[E80F5260:01C6FBD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins writes: >> We are still reading up on RTCP - somehow I failed to notice the >> progress of Colin's RTP/RTCP multiplex draft but here are some initial >> thoughts. Multiplex in Colin's draft requires a=rtcp support currently (though I have a few issues with that still (I think)). That means that to exchange keys, the endpoints need to negotiate a viable RTCP connection (normal or multiplex). If multiplex, any network elements in the media stream need to pass the RTCP properly, AND need to not break a=rtcp (which is one of my problems with it - some will break it by ignoring it). >> ZRTP at an absolute minimum requires 4 messages to be exchanged. With >> the packet loss that we commonly observer at the start of a media >> session, there are often a few retransmissions as well. >> >> The ZRTP exchange totals about 11.7k bits and needs to complete in about >> a second. We could optimize this a little, but DH public values are >> large. RFC 4585 talks about 1,600 bits per second for RTCP in each >> direction for a 64 kb/s audio session. So to complete a ZRTP exchange >> in a timely fashion, we'd need to utilize at least 20% of the stream >> bandwidth and send 4 or more RTCP messages in the first second of the >> media stream. Raw RTCP BW should be more like 4000 bits/s for G.711 at 20ms. >I don't see that being a problem. Why is that not a problem? If you have a more-typical 24K (including overhead) G.729 stream you only have 1200 bits for RTCP - and from that you have to subtract an RR or SR, a header, etc. And more importantly, without AVPF you need longer intervals between individual RTCPs (though perhaps some of those are SHOULD not MUST). There's nothing about "but at startup it's OK to ignore the rules", or "only applies if media is flowing" in RTCP. Realize, I like the idea of using RTCP for the key exchange here. But there are issues to address, including issues of network element support for AVPF (which looks like it would be required). There are other options: *Use a separate media (m=data) stream for key exchanges. There are some obvious issues since it's now separate from the media ports, and some elements might not like another port (pair) being allocated. *Use the same media stream, but with the initial payload being ZRTP data. (a=rtpmap:99 ZRTP). Exchange data as payload type 99, then start sending encrypted data using one of the other payload types. This is also an intriguing option, and doesn't need extra ports or a=rtcp or AVPF support. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From ccccd@caputomusic.com Sun Oct 29 23:33:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeOpZ-0007x5-68 for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 23:33:01 -0500 Received: from [190.57.1.229] (helo=ip-sv.190.57.1.229.telefonica-ca.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeOpX-0006hL-Px for avt-archive@lists.ietf.org; Sun, 29 Oct 2006 23:33:01 -0500 Date: Mon, 30 Nov 2006 04:32:55 +0360 From: "Jonas Sanchez" X-Mailer: The Bat! (v3.0) Home Reply-To: "Jonas Sanchez" X-Priority: 3 (Normal) Message-ID: <67163487.20061030043255@caputomusic.com> To: avt-archive@lists.ietf.org Subject: U.S Company is Looking for Employees MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 cared nothing for books. He was a clean, stalky, shapely boy, withFrank Cowperwood, even at ten, was a natural-born leader. At the day ---------------------------------------------------------------------------------------------------- FlowerLand International is looking for talented employee. The company: FlowerLand International is an American trading company. We specialize in all kinds of flowers and decorative greenery that can be used for home or office. We are not a MLM company nor any similarity. You are never required to buy nor pay anything to work with Flowerland International. CAREER POSITION: This is an entry level opportunity in the field of financial services. OUR ADVANTAGES: - Really High Wages. - Ability to work at home. - Flexible shedule. - No sign up fees, no investment is required. - All expenses such as phone calls, webtraffic, etc will be fully covered by our company. - Illness\Disability friendly team. REQUIREMENTS FOR CANDIDATES: - Basic knowledge of credit principles, banking services and operations. - Ability to work on multiple projects simultaneously along with meeting deadlines. - Ability to work independently or in a team environment. - Having no problem with the Authorities. - Having a cellular phone. - Having a deep desire to achieve business success. DEGREE: No degree required. HOW TO Join: Please send your CV to our personnel manager. It must be mailed in a TXT, MSWord, RTF or PDF format. Please write to the following email: abond007wi@yahoo.com ================================================= From avt-bounces@ietf.org Mon Oct 30 04:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTWz-0004X4-AV; Mon, 30 Oct 2006 04:34:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTNj-0004Jl-1J for avt@ietf.org; Mon, 30 Oct 2006 04:24:35 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeTNg-0001wn-IT for avt@ietf.org; Mon, 30 Oct 2006 04:24:35 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62045 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1GeTNd-00032P-Ay; Mon, 30 Oct 2006 09:24:29 +0000 In-Reply-To: References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Mon, 30 Oct 2006 09:24:25 +0000 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 30 Oct 2006, at 03:24, Randell Jesup wrote: > Colin Perkins writes: >>> We are still reading up on RTCP - somehow I failed to notice the >>> progress of Colin's RTP/RTCP multiplex draft but here are some >>> initial >>> thoughts. > > Multiplex in Colin's draft requires a=rtcp support currently > (though I have > a few issues with that still (I think)). That means that to > exchange keys, > the endpoints need to negotiate a viable RTCP connection (normal or > multiplex). If multiplex, any network elements in the media stream > need to > pass the RTCP properly, AND need to not break a=rtcp (which is one > of my > problems with it - some will break it by ignoring it). ICE also requires "a=rtcp:" support, so I expect it to be widely deployed in the not-too-distant future. And, being pragmatic, I prefer that RTCP is sometimes sent on the RTP port without signalling, than always sending control messages in the RTP stream. Updating middlebox implementations to support "a=rtcp:" is much easier than fixing a broken architecture that mixes control plane and data plane. >>> ZRTP at an absolute minimum requires 4 messages to be >>> exchanged. With >>> the packet loss that we commonly observer at the start of a media >>> session, there are often a few retransmissions as well. >>> >>> The ZRTP exchange totals about 11.7k bits and needs to complete >>> in about >>> a second. We could optimize this a little, but DH public values >>> are >>> large. RFC 4585 talks about 1,600 bits per second for RTCP in each >>> direction for a 64 kb/s audio session. So to complete a ZRTP >>> exchange >>> in a timely fashion, we'd need to utilize at least 20% of the >>> stream >>> bandwidth and send 4 or more RTCP messages in the first second >>> of the >>> media stream. > > Raw RTCP BW should be more like 4000 bits/s for G.711 at 20ms. > >> I don't see that being a problem. > > Why is that not a problem? If you have a more-typical 24K (including > overhead) G.729 stream you only have 1200 bits for RTCP - and from > that you > have to subtract an RR or SR, a header, etc. And more importantly, > without > AVPF you need longer intervals between individual RTCPs (though > perhaps > some of those are SHOULD not MUST). There's nothing about "but at > startup > it's OK to ignore the rules", or "only applies if media is flowing" in > RTCP. Sure, but again, a minor change to the RTCP timing rules to allow ZRTP is much preferable to a major architectural change to allow control messages within an RTP data stream. > Realize, I like the idea of using RTCP for the key exchange here. But > there are issues to address, including issues of network element > support > for AVPF (which looks like it would be required). > > There are other options: > *Use a separate media (m=data) stream for key exchanges. There are > some > obvious issues since it's now separate from the media ports, and some > elements might not like another port (pair) being allocated. Reasonable, but would need signalling support and extra ports. > *Use the same media stream, but with the initial payload being ZRTP > data. > (a=rtpmap:99 ZRTP). Exchange data as payload type 99, then start > sending > encrypted data using one of the other payload types. This is also an > intriguing option, and doesn't need extra ports or a=rtcp or AVPF > support. It's architecturally pretty ugly: a media stream shouldn't contain control data. I would much prefer RTCP, whether signalled or not, or another protocol that is multiplexed on the same port (as done with STUN). Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-archive@lists.ietf.org Mon Oct 30 04:47:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTk0-0005C7-6M for avt-archive@lists.ietf.org; Mon, 30 Oct 2006 04:47:36 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeTk0-0005cj-0c for avt-archive@lists.ietf.org; Mon, 30 Oct 2006 04:47:36 -0500 Received: from [125.22.133.172] (helo=BTNL-TN-DSL-dynamic-212.11.144.59.touchtelindia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GeTjw-0007HP-Mv for avt-archive@lists.ietf.org; Mon, 30 Oct 2006 04:47:35 -0500 Received: from mailin.webmailer.de (port=15992 helo=oisermkl) by BTNL-TN-DSL-dynamic-212.11.144.59.touchtelindia.net with smtp id ixNrF-v8bl74-XQm for avt-archive@lists.ietf.org; Mon, 30 Oct 2006 15:23:48 +0530 Message-ID: <000a01c6fc09$4aea92b0$00c7aa58@oisermkl> From: " Lopez" To: avt-archive@lists.ietf.org Subject: existence, and the psychohistorians HARI Date: Mon, 30 Oct 2006 15:23:48 +0530 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C6FC37.64A2CEB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec ------=_NextPart_000_000C_01C6FC37.64A2CEB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C6FC37.64A2CEB0" ------=_NextPart_001_000D_01C6FC37.64A2CEB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_000D_01C6FC37.64A2CEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
------=_NextPart_001_000D_01C6FC37.64A2CEB0-- ------=_NextPart_000_000C_01C6FC37.64A2CEB0 Content-Type: image/gif; name="jtrrxn.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c6fc09$4aea92b0$00c7aa58@oisermkl> R0lGODlh2QGuAfcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/ /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/ MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/ mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/ /5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAADZAa4B AAj/ADWhEEfJlyYscPi4AMXEjhQpvuBws6PJFwp03Cry8SVOkxQ7BMXZsUOJCUdu4sShw+UCjjhc Uihp8shNCgo7vqTAEciHkhQXdlzoxDIRhS8mOzXB4UiMCUSCQZuKaziRCTdfBkFl1DQShUtuWIzi IgnRzsSHKHBRcsHRDjq2FmGiaMpnpB04lOyYXPqQohRxLR92xOXLhTivGVHUHCmOIyWRWPLaISZO itOJOF0wYdKYGE5KVx1a/qt35MyXG0FNloKQmEtclV2gkELY5FgmM7niUkoJi2FuxHIWrqyJ20A4 Wrmiy4uCT9+jtA3iYhIcq2XcBjVxdqppI1eRNHob/zU7+2H3x1ImFh+Jzg4NFxUf+nIIh9hBX3wa thWY04VciznZcVNCRtFkFlboKKUJKD7BgQtshBk0EYCUwOFQY1PZ1ZBIvuw21UsfCQgUZiZJsRxO dcHBBB8XwYFQh5URA9tAuMDx0XxrPQQRZ5Q8+FBNOjFBCR87oaBJXii55B8KBVmYF1sE6SQRTOJY OF9L8OECihTOlYQFSD0+tBQloOClkhRH8uERhAa9ZCOOIOF205E+MQGKC5ppopZsN8EF30/tCTVV ky6AVphNHMV0lI16TuXgT5Q8FqdH/uFi1E7c2FioRQRFhEKJm6HzKBY5NeSfjULCt1NOfOkFR1o3 jf9UoVJIUVTQfA8ahedmc7nAB0wGcWbem0pF5B9ScDDKEWe4iPqSJlXKxA1bFVUJFA2zzRbpSJvq FRJEuFzFxEAyxTSSL8SQieZsrtoBE2yR4lnuWK5x+CpEVwEWKZpLGXaXR3oqWVxOXCnVUaYmjRQT DU7d1F9B08Vkn0AUFXpkjWO5CyhbTjU0k0mPcQyRQDJS1KEvlChW8GZKuVTQTH5BlFOVJwt1KYvz HVklN3k5uBsuMpK6UpsuEMOxaEthLNFdWBD2UU1WMoELFo1JPV3DqtkqDouRVUQMpDaiIw43sBFn Ul05qSaYTAUJxRG0MhVGZ1BMglKch1CBNdtSTHz/aVVFQjJ01FFdg9tYS9HWtCY65aE5IRxAWWYj Tks1ZtONR5JW5ZGmdVSRYRIBpYlr2oEotYV/2ciN1E0LON+H/Tb2KlE6oWmQXrKh2XVEVqo1tn5M YKtxyz8VNjSaaHE+V7McNTuknbjQ0G9Yfg0JuXmSFy3bSCzlhJKULFZPab/5rcTVQM+yZZlMmkkB CmG1CSczXsZhwZ1TDFs+dc8yX8XNibspiVpg5hQBGQcUviBVwVDWPZ6152soG8kzVDHBCq6ighSk 4AUzaEEMdpCDGvRgCEH4jA160IQcROEHTyjCErZQhSNkIQlh6MIZvvCGNsyhDHeYQhzycIU91GEQ /38YwyEaEYhILGISa0hEJh5RiVB04hJpSEUfPlGKUayiEFe4Ka5I4RnVAKMYw0jGMZqxjGg8oxrT yMY1urGNcHyjHONIxznasY54vKMe88jHPfqxj4D8oyADSchBGrKQiDRjYUgiNSaa8JErhGQMJenI SFpykpesJCY3qclOUvKTmQQlJ0XpyVCacpSnLCUqV6nKVpLylamEJStl6cpY2nKWt3ThWAbSEDCu IowlJOMvnxFMXwJzmNUYZjGTeUxhNtOYxESmMqX5TGZG05nXhOYyp4nNbVaTm9qkZjat6c1xgpOc 4iynOtPJzm62M5zujCc854lOedaTnufM5zf3af9Ofq7Tnvrsp0D/iU9/vvOeCF0FylA2rhaS8KEO jShEJyrRilL0ohbNKEY3qtGOcvSjHg0pSEcq0pKS9KQmTSlKV6rSkqrlMYQ5pEwTSdOZ2rSmOL2p TnPK0536tKdA/alPPWKRyNQSl0g9qlJpydRcNjWpT12qU6cKVapKtapYvapWo8pVq8KSKypyARag iUZkjtGs2CwrG9FK1rOu9a1nZKs11RpXuNL1rm6tq17xmta88rWtfQ0sYAc7V78aVrCFRaxcF2vX wxKWsXt1bGIf21jFVpaykbVsZn0ZlJQ8xIpTBG0WRYvF0mqxiae9YmpDu8XRtta0pF2ta1Eb29r/ vla2sL2tbWmr297y9req9SFhJCUOoQb1uMZNLnKXq9zmMve5zo0ucylDEJls1avYzWpXtZvd63L3 u94N73bF293xmre86L1MRTRR0IEeNKAETahBATrf9sYXvu+tr3zdS1/+2je//t3vffWL3/4OOMAF /q+BAXzgBjNYmtqZTo9aytIKU/jCFs4whjes4Q5z+MMeDjGIR4zSRLVOuiiGropTzOIVu7jFMH4x c3FGEjiQF7znxTF6dczjG/s4xz/ecZB7DOQimxJyXtkJZv862SZDlslPlmyUNQvlyzrZylNespSx zOXNXtnLWf5ylcHc5TGbectkTvOZFZugP+Fi/7fB9W2cgctaOs92zniuc57vrOc+8/nPubVzoPc8 aD8XGtC4TTScuUiQMhVXxjGONKQnLelKU/rSljYkAmPilCF72shEFjKoPy3qUof61KRG9ahhiYJW t1nBsBbwgxdM61gnWNa1xrWtCcxrBPfawbm+tbB/Petd+/rYwDb2NkeSqQ6R+Nkijja0py3talP7 2tbONrY3bJEheSTTmA43uMct7nKT+9yJhAhtPpLqdq/a1O6G97tVLe960/ve8fYFAlXjCy1TGc1r 9rfAxQzwgv/74AMPs8LLbPCEMxzhBIf4wtXc8Ig7nOLC7FBF9LJoRHf80CBXtJwNLXJBl5zQJ/8n +cdT7vGRt9zkK4+5b6XGGZCg++bmzjnOd67znqN4XOt2QbzxPe+hG73oSLf30ZWedKJ30DE66beu pz5sZBeb6sQOdtaVffWqJxvrVtd62Lku9q97vetbT+hhSjKRbWv77W6PO9znLve60/3uI34IbCrC 8777/O9+DzzgB69GrlBGLUt3uuITz/imN57pkF+84yFphy+t9+IBt7jmJ555zlfc8xJ/OOY/L/rN lx70ow89xlPPeifbxUhvdnnIZQ5z2bN89ranPcp1r/Lc+772wN/974UP/EjBAR2WEbzyCc/85Tu/ +dB1jkDC8njJR7762J/89bVv/e5flwntCR//2ccPdrOn/exlR/vYy69+868f/eSHP/vTT//4f7Mx g+OG3feP9/7z///+F4AAOIAc9RGzInXPl4DQp4AMuIAO6EZYAUFMkH3bV4Hex30UeIEWmIFLVxgB Ygeth3qmt3oj2Hmnd4IkKIIqiIImmIIsSHouGIMt2HnywRKxF3y9h4MvR3w8mIM9uIM+GIRAOIS4 p4NF+INHKIRMRBakAoJx1GqtlkYoYEZTSEYoIIVuVIVnBIVaaIVodIVi1IVjBIZhJIZdyIVcqEZo SIbPIIbVwIZeuIVouIVsBIdgZIdWCIVhmIV0GGlueId9tIZR2IZoKIWCmIdruEaFOIZYGIdl/7iI j8iFZXSGX2iIg9h8NnEnMdFJrRZCrWZCnehCU7hBKCBJpfhBpzhCrWZBq0iKU6hBKOCJmpSKhCiL pMhqTPSKbYiKptiLrKiKvgiMqKiLq9CKsehIx/hIybiByohLo7hCxLiLoHhJtAhKz0hBxLiM2PiL opiLFRSNz3iNqwiLnkiLoYiBsIQXuKAQX3RPpdhMVzhMl1iM1xSPz/SO0VSF3GSP+WhMnxiHJaSP 8GhN8ziFwcSP6ySQxASG+HiQ6DSFDflLCEmPzPSPvtSKwgSR1DSKGdmPBJlOZCh/IglMIWlQCllM EfmGHxlPE9lNJbmQACmPyhSSBolMDLmRAf/pj/iokh45k/U3f/gUMBJhYw91jCSkixD5jRhklCJk lEzJQboIQk6pClOplEUJlbu4jRn0lBEVlRN0jF5JlUeZlUs5llvplaGIlWjpUFUplk3JhWfJlduo h1tJlUg5jmQ5l0vZiUxJly0UllZZloF5lRYll4KJlXU5mF+plYIZlbHYloYJmAJ4lOmRH07Yh424 i1pIiXz4h2WoiF5IhmzomaO5i5/piHLkhgyJmYDYmqh5moAomjzpiKVZR0kJR7VpmlQom3fImTxp hrq5mbw5m1TIh5W4h7iZR57pmsjJnKoJm3FIicOJh4H3FudyjTVUjYH5iqcojqKknbbIi1//eUGj uIzYeYtW2Z3ZuYaYhJ13uYbNGJDCSI7ZWYzkWI3JaJ6upI3ISJ/oGZ5aaY4dVJ70yZ3xCY6VJIiB SZ65mIiuiIabhIbKqKD+KY3bOaDdiJ4EKp8cCEvk0SaAxY+TKI+ASJEl+lZwaFYK6YUSeZq1iVb8 WIXxSIlRtoYjWokk2pGIqIfOtJrvOJoqepFehoc2+Zoiapo5GqNnJaPReaKtuZNIOomDZaPQ1IUw OoK+GYZFepGFKI+QGKWrOZs0mYYlCINQJhOvwjMvxJUMuo0Mmo1CxJ+IeUJVaZ99uaZY+abceEWA 2aZ7aqGMaZ9LiUJgmZX6OafRmENMCUOp/7ioXLmWguqmF4qUHLqV5JmIZslCa5mneGpnjdpDjjmN SoSdc+qWdmqpf8l7RGhC3PAe7TGBddhGm7mHWRqrxomZspmbxwmbt8mcT3irtCmIw9mcYhqsh6ib u+qruJqs0Gmauhqc0Eqcv2lHy/mcxMqagDSs0PmsUiqrjBibr3mtPnckXqR/lJSoAgqL3kmN3wlJ 64qN+hmMZFmM71pK57mg45mv86md79qo/1mf+pqh3PhJ+TmfAhugonqw6YqfgQqoB+uNBpuoADtK /CmoFrug8QqNllSv5+iw9NqhHWQhLsFu7giGARmjNlmTKqlPHAlPFkmI/oiSJkuR+7iSvf9Zj7J2 kjI5kPRYTj/6kDGLkzR7jxK5k6u4TDPrkh2Zkw9pjxyJkLzpkDvbhl4KkC/JtOCUkijLkjlbpVuK kj4ppD7LTgLZsoN4sgS5ikC5tvk0FbVzgxAFlx60qV/JnocpUWkolXr7jZh6p6UqrKkat03JmGYp l23ZmF25l3i5txTlmGk5t4TomEe5uIs5mFDolvAqmXkJuZkqrHE5h0Upt4n5t6XKuYFbuaPLt6Eo uQT4jXeBE7DagLL7gDW1nLQ7u8llu5G2HJ7hICCrgcD7u9d1r8GLjsx4vPRWEvOBAmNVpqo3g2Ya vc8rvSH4gn21otTrvNUrg9m7gtw7vRL/hzJEohiqmoSrWr63l77ou76ZioTqO3xK+L5GKL/u60Pu Qx3fdrv6i7v727/8m2k4sxvEK7zGW7zIS8AHXMAI7HSYci/2937nF8EQPMHuV8Htd8E/OZIUjMEP bMEZLMHbdBazIXST2bolfMImnMIovMIqXFHQYgdacZmWCIWZGYlqu5uX2JtkOoYKasOSKKx2SKXM ysM33KzWWoc8WpxGOsN8FMTf2q1E/IfCisQ7/IZzSMWqecVPLK47DMRyWMVKHMbNasVFHIbH6r9t VBm+QDYTeK4Dmq4c+q8d+4kBe7FUaY2qBJ4Pi66mmI3hOLGA7Iqs6J6DDMhzrMfxmbB2/zyvrVi3 GPpK2uivA+vI6hrIjXzHj0zJJwuxs5jImVyOinzJeMmgCpx0TOIWvTGlV5qjVCuFrFyRLNqtLWpY 2NujeLWiNImss6yjSOqG9Gil0mqiZZiy/nijjPhkL1mrreyaryzMhBXEuyyksYyc0ZxMNCrLwWyG jJWiz8nNQOqIzezL1ru9necoLNGnm+unf2xEciqNjyqYNITOiRnPTTmNhFxEhYq53njPTnSo41mn bJrO9Qy5pAiqSsmoioxDi2qoMUSpM1Sn8PzODTvPAk3RE/2YDW2hlIrQ+Aq/5/t7aWEXxACszanM 4TrEJi2u2CrGrjmsuturu8qtasiI0/+JSE4crrNqm3d00zeNrE+Mh9oaran5Rj3Nq8WZ0z7trWis Rx2iIr7rxhndsHP4r/Jqx4JYjqAbyJ/MyBU6wJdKsF3dSnBqqFQdS4BboYwpse6Kqf05sQz7sP8J npIcnl7d0ZYc1fPqzmltShS6wFI1ECbTjlk72MPMtRL5T/DZowlZUC3btGk4tVirsuGkkUR7TPqo slNd2DDZyk+btlAIX8n8tVNrtJIotgeViBUpoZbtshXpTZ09TZftXympk1xYs2FrzZuNj6RNw6b9 wRucwe4iKq+SuJ1bUdx5UU+Z3I1bmMstuIhq3KirmA49uJZbl4dbuoRJuqYrmX7L3Gz/ybibO7qG m7p7jVGaq8/ordyTqpipe94tzFJAUx9YQdJG/avSipxFTZ1jvNJQ/IVTnNRPSqxAvN/E6ZtXGNQE vsXbmpmk2d9EnZxh3ODKWqwRDpoqjdNm3MPQitTJqrtLXUZ4Mh/vw4niWd6czMd1DKiI7LElnqCd XOL8qrBljck0LopwfLF0fNFqPcmByp9jDYoZS7ER6q5aXa+knOJG7rA7XuNHfq9/LMhoXYtwncDo VWNjw16TBaVR+MpwGKNjOs2nWc1BemUpis3U7MpWzMNnrpmqnOaIaMyzSa+TOJoWeVfJvKTHnIe0 zcuIRaTZzMPEDMtqDuclWcRlDKW2/4zncY6jZ0jaey7N3TvO2ptMOlE1cPvGtU3Qqku5meuoD/25 eRu5EgrPp4vd3fi5pnuWN+S44+jPNW6qm+6nrx6wkorqD02X5njVqMjO+KyKekioWe3rl6y4Xinr /dzrtJhC+Xzqg9zqQG63s/7R8+tDKLEbbffh//tiHp7t3M5c2/6AIh4nfl3KVG7A5j7u5Y7uVeUX WOGEGuzBHczBbAvC8v7u9U7vvg3v8/7b8Z7v74URV/NFLDzw713wBH/wBp/wLNUSlCAqCIjtEN/t Eh/xFG9GNuEuNaHuGk/u587xG5/uHg9Ku1EfMEHOkf69Jg++Kb/yk+690KvyLS/pLv9/8i//WLWT F8Xl0ea78/Qbv+w77Trf89Jev0H/80QP9L8lP0JB31Gs4BbOxF8sxV0MuP4NxmScxBhe9aRZ2tlK m3jU5VAvq18qxBk+9lYv6lpfxgW+iF5831x/rd9uU3Fvq/vbFy9M4pMkyga61Yt8yFC+yVTt4+xa yIFvsEdul4SPr3Ut5HFMjT9OiEDenie+1Uv+1l/Nt2ht+UrO9+aZ66Bs1yGf4h1vSQbBvIUxT7PN k2Cr2bi9+tmkta0tTTWpswq5k7a92rG/tC0K20Gr+yvLs78Wte30srmMtN8k2b8ptJq9Tcjfs0O7 2aoP2cUv2ic5/TG55axv7x/c2Nr/3+++lB8ps/TOneqIW7phGZnhXbnuTbjUzbgSHd0m7v4bZZhi +Zhwaf/0j9Goi/7tq/7tn/4AoeoZimcCDRYsiOLgQYKqFCIU2DAhQ4gTEUo0+NDhwosdJWL0qBHF SI4jCTbUaBGlw48jK7JUmJLjzJc1ad60mZMjHEq4iGmS8qyaUKJDCQ5FOrBoURRGmVZrSvTo06VJ pyaFijQq1qVXq26lmrVrWKlluXL1ehbs1aZb3U5NK7StVrpVlaL96hTrWrt11Z4lq1eu1bxmw4Il 7BSu3ZGJ7w6WexRxVMls/T5u3FczYM6bPXdOig4FHxe+ND1bhTB1RNUdBa5G/XCV/+yYq1HAto27 NUHdDmGbdPnaNerWvovfTohbdvLdxHkXJ/4a+HLhz63Hlp49OnLhxnnT7u48uvjfw1M/jzgd/UDg qqmPn92dO3by5pUq1677enyl4SXyz+0+1+bjD6XyqqMvwPB6gw86Bh90MMIFn6HEjtI0IUaoVdDa sKsO9/JrrsE+HPGs2araELEPt+rwKhKzerGpFKeLsRoSjzpRK+CwulHDxHK8y63LYAQxRyFRTGu2 6Ww0akkPTfwLMia/ms5HKZXcsccpxeKyKCAlE2xKy54C0qgUQQxSTC/B9FFFKFF8k8c4vZwTqVWI kUIcXMTxpabzKvrzINso+qg/QP9lGu8/iN6jiCLYBEWUv422g7Qk+zIKr9JDN6rNIuMm1U5TTgeF TlHWMhXwVPEE9XPAR48TlTlVX1U1I1L9G+6k8VizTb1Z+6Puoe8YUk9Wi2jdFTpWOUK22VaZRUgT SijBAg4mNIsrri51VawvxMrS9lvHwiwMzS7D/HaxKDkTdy4RuTxySCnfFfexcccy197P0mRMSsO2 9SytePHFTF90AfOKzboUNtjfc/cFDWKJI5bCBVyY8KVPBk1N8FIC3ztwOwXrW+/PkHsjMNWU0VtZ 5N24S/nTRM0Dr2OZRyapvvya2/i4k3kGuuSaT16uZKB3FhrBXkt1Tz6TXW0a2J//h3V5QqsbvBrC rCUkDhdfmMCFm6CmRM3MocqO7JmyR+pwbbJZPLvFqGKTEarbdFT7zLbhHujDtvU+2yUmebOTILTv VhtutnUkvO+4cYzbbMchG6gut/8mkr3CG88MbRsN91vywQ/HvE3P51ZSzCNJD7zwvO183MrKNXRJ 7tgHR1xMv0GHnPDFJ8/s7roTtzxHJT0vnezQX5d9eeQjbx525m3kiRIUpLiWJvUwam8mmRAtySTv TaqpSktvKnYh8L8nf/zg2Bc/p0IxHVB97+2vCDicQGo0/4u2J1b78hc/+uEPVIbS3ksQpT//9c+B CclZABEoPmF56n/8o2ABdbJB/5x0kIM58YU4mEAMXJwmYiecWApRuEIVtpCFL3RhDGE4QxnWkIY3 tKHEtJVDHPaQh8+QAiVoAAc+wAFrR9QaErmWRCYu0Ylbg6ISo9jEKT5RilekIhatmEUubtGLVQSj oboYxjFqkYxORAEcQsgNPlhJTnCC4xvlSKc40nGO0rujG+24RzzyUY99BOQfBbklPxIykIYc5IsS WadF1vGQikRkJCE5SUZKkkOVpKQjG5lHS2qykzySgia4wQQXGBFapwTUs1KJymWt0pWthKWyZIkq Wiarls5i5SxtuUtcvlKXvYzlLVUZTF4O85fGFGYuhQkSYB5TmcV8ZjOT6Upf2P+BEr7ABSV+6ENu btOb3QTnN8UZTnKO05zlROc5iSIadPgiiGaEZxnl+cV40nOeZ8RnPfN5T332k5//tGdA9ylQfzqR CVLAhR2YYMLkNRR6ypPe86bn0Ik+lKISxajzNBrRjUbPoxD96EU7ClKSipSjJw2pRVVaUZZmFKUl XalLU9rSkZp0pjKFKU1fatOSaoIJdoCDFILiQaJ+sKhHNWpSkbpUpTaVqU91alShOlWpVpWqV7Vq VrG61ZwclAmgYII4vMWue50wXk5iXJXyZZX2sFU9aW1rurDlLfKhxSR4was607lXvfaVr3/1q8RE 6AsUoMOIKHtQ0eJZM0WxjIn/IAvWz5zmIMguCLIsa0l15sMxjgF0oJ8tKGg9G1rSjta0BIVQT1AA lLHVCJJ8+eRhMkeXM/nxNglTJOJcVKR1relJ5ZJKi+i0lsnkrpCZ5CRyj4tJ5npSuY9sbnKju1zn The61cVucu2gCU2gYE9+iknOsLQ9pQiQV566LSsZ1ZzG+nI9sZIPLGvGKmZOZL3WScnxiClNaPpy mvtFZn8BHM0A89fABUYwgRXsXwE705UJDSIl0EHXf8FWcw4zjLrGupmBPaysgQExYXa4Qw8XbDEk DixgVZxiFq/YxSmUgjvhIA6j3WxoAloPZ2nGwF5NZ7I3Yw/5flOsHvMYZFHr/5nVYmYoXf2ps6iF smijXNopn1bKV6byGTM2yoNGb3izE0tsaMc8xLFucsrrXUYhd2bMDS93bSYp6iLKNzM/r3G6M9tJ JIdTnvY5pjX9804DfVNA65TQgjZ0Tvk8aEUXetGJbqgdLoaLEtrkexqc33D6x79FafB8mi4fqA2o wA6CT9SdDvWpYlIrrbaaq692daxhPWtZ1xqrUsACLrAQ1g2HyDEJK1e9fE3X7XVGw71dK3DzCqJ6 afjYLYb2i6UdbWqvWByUIAYlNIELrH0MaToTo6xghlhj4Qc+FcTVr3587qwdeWeqMtVmc1VlemPZ ylnG9731XW8q92RP3P3j8P/g9aPMzLZEa9FSbaW3W7NMRk2AFHiIV3RIwUXGdrRD+CWzS13pbvy6 HQc5x0X+8ZFvsuSxJXnKTa5yG9mBsKI05aYWRTTWmPc+IpEPcB61vSanOsjBuaCP6bMsAM5cgTu3 eXoiuKrmDJjBB16w06Xu4Kn/l+pXt3rWG6x1qD89wRQKorT61E0UP3vaZ6922tG+drW3ne2A4YYm 7LDaawG0xvnm977tnXe+793veP+73gE/eAi5QApw4Ia2Dx1S0CH60Y93dOQdL/nFN3ryl6+8nyHN aM1DHvOWzzznRb950ns+80LV0zu5ymlat97Wr3d97GE/e9nXnva3tz1HSvj/U19k6O1uB/7vhR98 4g/f+BLLGEJxcdi+E775gof+86Uf+Ok7n/rXdz4KTKMJPq3c+yj//nPDb93xe7z8IWe5+MG/fvW3 n/zsf7/7zQ//+cufR+IAChyA+vWqb93/Xe8/AMS6/+O/ARRAritABIw6A0xAAlxABfS6B3TAgcAe UeKG4sPA49PADOTADfRAccIe5dOm6MM+ErS+EzTBFKw+FSzBFZQ+F2ACUtKEses8ygO9G6zBz8vB 0Cs9G9xBHBw90wPCHtTBIPRBIyxCIuRBPkOHbLIDa8K9KMw9KaTCKbTCKsTCK9RCLEwo7cuYDgTD DxTDMCTDMRxDUHAnKYg7/xR0wRZ0QzZ8QxaEwzmUwzo0KDUUqtaKvz2sPz5Ev/M7OfsLRD8cxD40 xD+kP0QUxPQjREZ0LkqAA01wAYVqwAOcwACsxEyUQEvkRE2MwE/ExE30xFAERQYUxVP8xLm7mBgr w1Y0Q1eExVeURXOqGCZQoxFsQzrMRTuMw130xV4ERl2UMhSwmK+xgyU8QiUcQiH8wWZEQmRMQmZ8 xmVMRmlURme8xmnERj5zJ2vyhQvcwnDMwnEUx3Ikx3M0x3RsNUqIQXFQo1iEx1mUx3ikx3kEjIy5 NijkRWHkx330x1/sR4D8x148PE3AAnGYsEQsREVsREB0RIY8xIWUyIecSP+HtEiFpMiMvMhFTKSe AIXSyJ5ShEBSJElTFMlLNMmSHMmUZMmVdEmUfMlOREWV7C84QIef+i57rMed1Mme5EkMLMawwcVg HMiAJEqBRMqjVEqjxDsmQAFtEyJolEpqjMZqtMqqxMqp3Mar1Ept9MpsBEtrFEsfNKyEmhZ0REt1 VMu0ZMu1dMu2rDVfKCJ3FCuftMufvMu8xEsWsx4RggNuK8rATEqmFMylLEzCHMzUCKtRSqiNbEiM dMyI1EjIpEyOrMzHtMzMxMzNlMzI5BE4cAF2xAUXGMWWhMnTlMmTTE2aXE3TbM2YLE3YnEnXjM1E kQLt26691Mvd1M3e5E3/GopEPsCFNEJMw0zM4zTO5CzO5fxHoNquCunKsORKqozOscxK6sTOrbxO 7azO6eTO7PxK5Mm1GNQ/uHzL8zTP9ETP9VTPcQwlbKsm35TP35zP+uRNNbQmTWA+5TzM/kRO5vxP /+TPgPKFSPQaI7rMzkxQiGTQilxQB9VMBY3QBp3MCYVQzlREPsgTl+O010TN2vTQEAXREZ1N2VRN Ej3REv1QFe06DOE+FKhL+5RR+qTRGW3FbasYbgDMAOXRAfVRAP1RAQVSJQorX5gWbQJP6dzO8PRO Jl1SJe3OJ7XOKKXSJJ1SK/UbPsGCa+oT9vTS9vzSMAXTMRVTmqAEERKl/xit0TW1UTZ1UzIEG1AQ pbsT0jrt0SG10yC9UxW0A274yy570ArF0AuV0EEV1EJFVAr1TEJV1EBdVDvBJoUyPBRlTUqlTRa1 VBOtVEzl1BT11E391Et9MIshobHrCp5rGBRiGGTbl4LrtXMSNg57oVh901ptU2jDP2nREyXKsYCi UyR7oiUzt8IUVsrS02PF0z1VVuGAAxi9TT2cqMabHMhbM4yis436Mue5VimVvGx9KTmr0u8UVycN V3LFUm5F15DaNhrABaHaIJA4CaDLiKVrFJFoH6FTnwjC10UhiQrq11Ejn5agV5UIMgXSV1bjnn+9 oAYi04YtU4eFy7+UAv9i4DVjO9XLMDt+GZMSO7ZmkwrK6LCzYhiBaRKMbThycbazstWVvdUXozSE QihenRmliSyeQTd2w1kFiRlvE6Oa7VUgm6yf9TbkEFpza688TVZkRVo7NDwZZCgTwa3EcDgtoQw7 4hsuUbiImy3KmLg20QvhMjjYqdqH01oZiVqHs5cyedS1ddS2tdBDbdS3ZdtJcgGgWChuQ6X2qldf aSB7ldf5sBVUk5SoCVzu2TmEdY74OVwEujlmudlACRal654VDVVNFVVQxdzL1VzLnSYZ45Nrsdh7 WdV+8bAOcxjTPZexPV2UJV2qALbSZd3UJReWpd2WVScjNQ0ak9mpsZn/lgEQJKusqtlZowVW75jZ 4w2Qom0aop1Znj3aZU3a6F1aX4xEn7IDLGA8MvsbHOGd5mGT3Jmba+Xe1/FW4OHa2zkewFkcNwud 77AS3WoR9V0b+C1Z4qGcJoXScy3X/B1X/jXX/kUe0PxGFDjG/WHYWiGgvp1XeWXcBR61fF21Bs6g hRXY9UFcB7aggOXXCFa6A4bYhwXhD6bCIrUDKTjG2qUhFENh213hGgUKYnABPqg76JXDJ1NaGsbh G9ZhKnMBwwNNaI1bQ53bc5FbtxViI05URlViuF3iIXYuPSGNa8pUys1c6RAgEe3UKqbizd1izu3i L8ZiT40xF9BSFjbj/xY+4zTuDKCwXtKc3h1+Y+nNYTmG4whZLVxAQ2i9UgDG3z3+3z/230D2Y0Hu 40JOV/0tqTxxAQIWqxB2ZBF+5EiG5En2oIOyydxcsbcKMYLZC7XSWIgZW1qVVWX7DI8tsYghWR5S XTRmZeBrJzmFRDbMMXdrkBrj2eTFopolo+DlJxu+onjzrGKt42GmY7wTh1HCXSf+Wr9QrjWjrR8R C2e2WrFFxIqrX4hkuI7bLTfxOK1V5iZG4iBOYiauUKBII8TLxKVDFk5biYWVXGZaIGCBN5OgFead lECBoEiBoJeBlKWL13suWKqBiYF9lfcKFvFaWKRLLyab3DDWYofmYv+I9uJe8prr8QUamJhi+9jQ xReV/RcQ45ZQLiuR9peMzQohsTC48Gi7gYzXnat86ViTrd9VFeVWtmlvyhh0gEQ3njKEVhqb/ZX9 8JmoMZDGRSJ0Y96R+d3sGLcbM15cPpAl82WeU+rHNWqoHmpijuOtDij9swM+UDwsrVbjuZ3zHTMx gyj1iF+oQGtwfZs8A7MUOZ2H4lo2iWu2Jmv3xbPyLbPleTO8zpzZ6Wu71htpHR1D3t9BVmzERuRm vJhco8SjKjpiSaDzEZb0aWALqtd5HthJQQl6nWxU0xVQKTruuWC/TToPJm38gVfNvlm+leTYpuRW e8o9GaEfctVlO9n/VE1VU17lj47mlt5kc1lpTv7t7+Xk1h22heloNKHpm4buvuITUOCGuSMtn67l nLVqoV63qH6an9aOov6UWwbe/PBZl1Henz0iYC637e5dk9HlYuZqrQ4ohAohufvmNSu44pbmsHUc kl7mllY44AkuVgWYzzGLrMWdEYlaONpmqwDbeXGdkjUSagbnIsbwI87wcQ6/r7GemM3ioPPplLC5 wQ2Vpnttej46eaaUfD6l/LIgLHGgonEJgfaxCiroXTno9xCyDS4QETfqh55iiQbjIUdRVcQm7I1u N61pNXZyWwVruXPX+ZbvOabyK7dypDzTEMJkPj5kL09sxgbzxgbk/8X+8jIX8/8tUO5yV9l289l+ 8ziH83N0JyYwLAR98jxfcj3fyycUhycMCiyn70GvckIXdLxTqGua1HC+cA13dA5ndHL+ZkmP9Em3 dEnCghLuiS6t3CIP8Yk28k/39E4n8lIPdVJHUTVcKHdKMbRSp2xx9RWyZp4E8IARbhgaMd7mKxW2 9dmVobbCMOe23T4lrD+XZeTlO6NR7yb6VWIW7929lF+2Y3705Syq9mD9j9pZIlo+dP2wJhN+WkGm s23VSsM+kbmGNHNH8zP/70bTbxt0a7cG875Owr8mwmwd6zljdzPPPD0BKqekbVPztPIButZu7Xc+ NQzC4JrDbPMKr//ystcBEqB4xSDQ7myIN20WH+hUu9kDSu0Dop8Khtcat6/PTuDKJvhMq7mf05Wc MR/5sTTSZiDPDjo5pwkM8ZqKBWVNvmblDrZhe120zZbCSNlxEdmNLi8Jd92BcTbgvrCB+2R5Qe6D CXZ9URe0hZfK+Oiy67XjLphrxnqfF3ap1QsLq9Fsuk0jxTfsLjJ5o9nwPhr0zm7vJuqgaV6aAzes VjX8IO+gpo+i/lWqefbnBW8mM9Zwo5okW2+mefu/nzclgxA6PTLBL7cs3xq5C004AIVF7e/3LfAE 55YzuwvXSpK3GvDgnvDRL/uHK+mAQ3AIJ2LZ/a3VTxO1JSTk1m//35ITIYnwLTFr2n+jbP582N/t aI5w47LwPup8D6vwdm90SJ8koChQEH+67SlowJ0losVsgD54lrdqdctnBlLv1h5cltk0odNbRglt fFY1XkFtju/gAGpowSXxxNU5xm1nK24PZ6kv8lp5fAYIFM9WPROo6tlBFAoXHiR48GFBhBIbIkTx cOHCigQNFmQ4ceBHihBFfnRYMiTIkSlPqjQJ0SQubprEacL1rNrNnDh36uzJE6fCnz59ogA61KhA ozyTFtXZNGlPqD+bCpUaUWlOpkudbq1G9ebTqGCFeiUrtmvYskSrjr361apZpGe/qrWqNevZo1fz soXqF+9OunT5/3JNC9hwV71xFTNe7LjxUFBSxFGSAmelycwSNSe0iHmz58yeOW4cGHr05oirQmtU nVogZxSiE74GCVuiQdm4QVOEzVqV7tu0gc/W3fB3xN6mhxtP2bz06uHJp0NPTVt48ueolUe3vZK0 deq7ubeWzpH07+fW1fuWDn379/CcP5Ocb18+/vr5QeLyJYUbE1LctApOA+1E4DMGDlgggtUgqKCD DCaFoGyBFUhVUwVZmKBCbRlY1GoJNhgihBSaCNSIAn0YIWxlnehhiGqtSOKLFRZU44MUZoghii6q SCCIErZlo4w8injghUje6GKSHnYoY4wvRnjkklQWiWSLVdpoo/+GC2Y55YdcPvlUihz2mCWXIzKo ZIlrLmhljmyqCaebYI6oCRzioACHTSr5idKfgVaEkUoZSWdeh+dhFBFHEDUakkeHTtdZo54daul0 GAm06UeVKjRSpJ12VClzFxkqKnCSKvqon5gimtGq2YFKKHyOahorqI5OVOuoiVYU6KIXmcqQRfAR Oh6gyQq6rLLNMgsRN9ygEJMdkD12rbXZYruttt1y+623hIE7brjkJnbtYOaWOxRc66r7rrvxCsWE L+IwYYdN9+m3L3396uvvfv8KHDDB/A5scMH9gocwwwA3fLDD3kE8ccIUP1wxxhdrHLHFHD/jiy8u EIMLH2/+1KD/TigreTJZKpuccssx++TylCzPLLPNOcN8M886r7zzUjQLjTPQRf989MtI10zV0D0b nTTUNT8ttdJN+xy11VNnXTXRXM/s30yaMIGSS+G9RDbaLaXNEttnq/1222bLTZLbcdM990p1n/1o 2Xf7nTfefQP+t+AOLVr42noHnvjicCtOOOOQO9643YNbjjjcdkjBRE3cyPs5vKGDPrropZN+uump o7666q2ProkUlWnigscbd3x7xrXrjrvtufO+u+/B9z488MT/frzwxSuvmRS4uMAHnm+2SSf101s/ 5/Vyai899t1vb+f3cXIffp3igz8++uerbz775btfvffptw8///n0y/9+9vfbvz7+8fO///zytz5N zA4FLmCVsxL4LAUycIEObCAEHyjBCFJwghasIAYvqMEMcnCDHuwgCCECBybAAQv3Yh27NPWYdsXl VtZCjF6CwjoYTsV1d2FhtjCCLsek63Q45JTrgohCIbrugOLQnC+WhzHsLGx56REYcuwTxeTNRonE Aw92IPYp26hHJF10DvL41cTqGI+KZiwjGq0IPEpgQXNSSCLVsNa1l01oQ3G8I80GQySgMQ1nfXSa 12oISDkOMo57rGMhKQQzuqgsSDdj5BzxSJZ0pWtrhLyaJBMZSUtmEpOc/GTLfEEJX+BCCpqI3OU6 8rhJtUZT3v9JVai8uLdOdegipRnWsLZoy1p2pGynwiVqDLfF7myKl7jc1S9fWSvWnMolyKHNRnjZ HUrtCji6ZJSlFmK4l7jKOW4L5qBOMytRYa5y5VzlOSmHTlSmU3Jsax4l7AAybd3qLT3EioUEo5Qn 7UWQ5zJSXQDTT0pqBTEA3YsM/7JPoBxUoQNlS0DxeVA7HgWgFg2MQ2WIlYwyxi4C5ehC20LEIZJ0 pJY5YOzUaJJh1mal8tmOdurzRGS9hzlV7M5NXUMcnWanirkpDhl7yhvxkOSnqmFmfLx4Hya2Mqkx pc5Mb5PFliLLqMcxT3m+GEaVnpGraSQIJTgnSgH9T4A5QqT/aVyJPTJ5BUIZapALp0QkErH1Szti E9N+5CMqVciuZwIfiPS6JL9W6Xx9NU2VECtXNX3prG/qq4MEe1i49ghGTNoU+VrkSMg+iEdoolH9 zNq/0PovgKUdrf5ECydKuABfYmtgPQvVTUnZ6li5yRWkcEupYMH0VsLKLbJS1StDuQqmrVJVOI9l TWOOZzTMrSdw/wRd4U63uJfybXCVlU1dCfe3tJ1tCMP7wfGKFyWUcB7ISiY6jbKrooK8C0Xji1D3 uqWFk/wnPrmiX/judy479G99BWrf9rKQhiIdkn7ve0+xeFQtdizKW/pZ0gmPVHXQ00Q8afc7lupn qju9qlBB/5xTrHIHpjeNIlINF1SrLifEywmOU0fcYpfuVKoSoymOaxxjnrKYmENVsWs8HB+mfrjF 58nqVpPcVSV/9RlM4Ny94AhKTQKmkUv7a4KzXFkHG2lLWaGsyfLKFSBZSJEM3aiZAxsVM2tJy4NV CpnHEmclaXQ1PJpzkO7sFb+wObJVVqjV/shnNC90zpfU2iYTTWVPKprRiaQJ7ETJzkkXCm2u5JRw t7meb9Z2V7cMJ6j61hz0dHpWxYImqI1cm2Pm8iS3ZaVUpYkS5XKR1LgxZrGuiZ3lahrETbQlOVM9 zUEFe3LuXKexU5nsdirbnJR+Bi7swIQj4rDCFL62tbON7f9tO5jb3tY2uLO1ufPighJePTeT0b3k dTe53ep2d7rjze5303tgcLg3gMZW1tMCELX7Ji3AU8tv1RJ84AYP+L8FjnDTLtzfDFc4xBMu8YdP 3OEWhxMfSDm7apG34+X1OMg/LvKQk3zkJi85yk+ucpXgixLiKOG3Yx7umcu85jS/uc1zjq2aaMIX I6z3vOUN76ATfehGB/rRhY70pSt5lC6AQ70OHUhEL5rqjr661bM+9a1Lveud1LrXp4x1rn+d7GIH e9nD3mi0C82UdqD2s5Ht7GXHXZ12P/bdmy33veed2X6vO94Dr/e+A37wgv873RM/d7ZRYnaUISu2 FwxRCTP/VIc6X1e1AZz5xdwK50upZ7UlDxb+cn4h/xVi571lYM+fDh0uEOVMmP5jggl5xVNMelfH GB4sKo/3Su+Y7os8H1svddS3nzHRiQy82hdd9igIKyVcHnGKi082gl3f9R0Lpj8WvOH9pt5c3zfX 7KM2TUz6fvcV7sg2NdZNYgrf9d+KV++bNf4XVyz173/w6ZcPFNEmNwhdk6Bg2m6cyqXNGgKyGjaR Ci8lE609YLAs4K0RVzKVyqRgSgVmFyxZ0wQiUwS6Uqkx0KP8EgY2IOiBV3ehyqhUUwci13IJYAKy IAhaF6+knA0my55UhkzQU+qdmWI0VEMJmBBu1EdZlFRc/9RhoMV7BaFEQZRhHKF85VdZ8BOXmQXp IeHpiRQWRlgUupk/beGD5VfmwQWEvVcSUt7liQ46oIDYcIO5bRWHgVF5iIeNBZUdHpVS8dgc+h6K MQyM0Vim7IdRtceNuQeOEeKKrYcUGSLzMeKOKR/xvZQYtRR81BTykUeHJRVmGEtT/V7z3QcTUAIb 4oI4qJ3TIBKcEdqfVVlXoMwV+lnQdNshHVgUWlmMfJkq2oxWhIhU3OKWZYUKHRgi9SJcgNkecQ0j 2UWcDSMuilQeyQwxDokrDggQ0RHWdN4zjkWepWLVmd3amZ0daM5MJNGy1ZMvNQd37cankRgr0VZ2 YBfvZf/acJmgQqyUNk2gR8SjTh0OOTkXE7nQLHFadgkHpkQTRqxjszVRPPKKjQHb2xQkLc2gQUag PL4gcxWV3GDXpbgj4i0e3x2eRJTSKI3S6LDXVICeGH5UezmhFQKYFK6kSyJYYhQYSwbYS06eP0kY FGrZ6tEXTgZYgz3UD7YkTaKhXKQk5/mkFlahUaZhvGyOL6BASm3Y8eHUUPlekH1GFomTHBLZqFEV JkpMVGniGCHHIN6Y8gFiTkGiIl4lWGqiZnhlIrpHVfKUj5WYI+JUJdrlWwKZrzXXHeKeYIKEJoBC WPnCKVXc94WfiGyK9tEIWkWJD/oZ/nUImQGJWzUJlNz/hWLJn5opyJa8SJcs1l7NSFtdpvuZj2ey iGkeyfoZyWjGyfoxlmlqFmuKJvelCJrclZNsyGjyZppE5oGQH2GF5mkKJ/+h3/5NHDH4ghtKAe3c IAJdhwpS16xpSqvo2gp6VwviY22VIKzAGgu+YAIyZHdW2nFFpAca4KLgyq+sJ3aeJ3hWZyBKVyxt 53tSkwtiZw22Iz4WU65w4g0O6EfggiagADGkFOuF2+Y55YKSVIMSkejN3IQ6qFOKg0wg5ht+Iode TCPK3mB6Yoh2KIiWqIiaKH7AQez4QoCY4ti5KNu1TDF+I4x6YzfWKI6mnY6enY2+6I7S6I/eaJD6 6Ce9/xEuqCjHeSThKd5HJuSSKilIMumTNmlHUmnhVemUZmmUQqnhdSmWbqkUtNF/wJGFPqiZlima nqmapikKYYGKjiKKjqicximdnqidkuidzmmefsYBwYEmcAM6JGf6Keag5p9y0t9yGmqh6h+iNqqg JiqjPqqjEiqkHur0oYMUKAQT9MnKdSqBfqqnhiqojqqoliqpplw85Qk3kGnq6FG5VOhNhkuEzlAX 4hzp5dAQsumGzGpL5iS88CpM3hebSsFkhOKHWoxWZUyyYmQaBR/SGceyouix4se06ukSKdFWNlm1 1inRBYhIluKQGo0jEWm3ZVIv0ugx5ujWbGOMCqnQzP9oIsErubrr2qFi1qHiHxGpvLbrvPar1vgH i0qLpfFjMe2aNnXTq4EYeVrkORogfh6HduoKCDrHQf7KPabgsEFsNtHKcslWpdiZqOjSRd5neBZZ RgjTPR7gsLhUBkaHR5TGMIWKncmaw34KajSTsHUgq1ifyDqTLF2sBDriwkJVzyYXtPLael7p2vgH ExADHNCOsO4qE3ZETe5qglHSElIUSKnkTzKFQulTXuzkngmYEabQUXKhUI4tU0YU187XRk3U6BXh TJJtGFLtkEyt2FJh3IZUfPGTX3QZg/UXEbLtPm1tuZ6OOEgBH8CBHVwGFOXlTOFlV9JHtN6lWOYh WyL/DCJ2ol1GLrT6FCVmol+6mOVaIlaSRx2OpVrOYemq7ltyCpDJpVuGpVXqmB26rk1xruSq2BRt ru1yKBtKJeekFls1pmXNJmdeJnEKUPFSZh/5xmOJZvckb2lKppl4SW1mZmHRlZzU0Wed5q6WSZeY H/dMyI9Q72dK7/mNb2dhCf4JiZ147/u+WfsmlvXG5nFSo5WsJmgN1oxkn4pwX26iL2VWqlnZQTxR AjdE53XaFqpY1wPrFkWCFzxGsAyq4HQCJARvYHTl53bJoAZL13i+Y3yO4Htm8MQeWQpaZzpyJwsb rcg6LHqe8ANXcAvnpwevMA6/MFZ5SgPusAfPoARn/6DHucABuR7k+SoMvWJMHu7a8iRSgm1QtkuD ge0URu1S0uLq9ZDY2iRh3FCwuq0XEy7lSbEXrgUa7mQV9+oQWnEZorHVzm1R3ioZM7GvIm69+MeG 5uFf7i7r4qEc8nEXPRUfYi5Z7l7oBjJRXeLnsu5e+m4hfqXwPbKqKQdWpq4hr+4k0yUfTy7LejJg zm4hMrImk7Ieilhb+q71QW4nj66SuQCG/mli2mL4tuLfSo35AiMsylm5GlpdMKEv5tmgrZkSjhk+ TeMuX9YX1i0ue0ksIhSYqS0SzuIu5zKcKeNJshk136L3lllELSO7Vlbe4qs1N+NJruIzO1gwV7P+ 1v8FMuvTOvMo1hzRCNnBKanNAZrwyiKsB04TRfLUbnFKwZaEzK4gQX7TQZ7aUFUkQV/TLaVHCBZZ CyOVAlITi52s0frzdUnyK/HGy7LSzHITzsowDeNsx36Hr4SazHbTNgGtPhosSYd0ViU0xm4srm1p 3bhApr6cTVgbsK6pucCqrpapUAM1PQ0Yt/z0UAuF2ACsgHjitu6pkkU1nla10VWuVatb7dVlK2e1 Jz6dy02GpAocclLqpCpqaZGfpZr1WLO1W8vmW0dqXMNPWcvf/bTfWqP1WZcPsT5duXkqCpqqqAb2 qQr2gBK2YX8cYSP2DRc2gR4pG/bcUk+2UVc2ZV//tmWHG54osGRLtVd/trWGNreKtmeTNmgDDC6g l+aoK5DKc7j2KL/GNmzPNmvTq237K22/dm3j9m5rDdSFzOworZTitJZ6qXBz6Zca93ArN3Ift5Uu d3JHt3MXt3QfxHmJklRitnZn9nZ3N3d/d7fwgQuYEIuOtnmX9nmfNnqvt3q399ChgOaEIjG0tV7T t1zX91wval7fN3/vt3/rN4AbsIDv9X8n6hFFpSkltmMrOIMvuIM3OIQ/+IKjABO01qZ6N4aDt4Zn OIcbNRNIJRyIYnqbNomPuImzd4mj+IlTq4o2XrXoNoy7toy3No3ftmz3dm7PuI3neI3zdoz3ONvR /wQN6DQ5Njd0TzdxJzlzP7eRNzmTPzl1I/mSR/mRV7mTUw4ccIPmxFOHd/mGf7mXh/lIYQEss6Hj uveKpziaqzibr7mbmza9lFLs5feA23eBE3iA43md07me97md5/mf7zl+s08p4cK0JamER7iiJzqj L7qjNzqk4wa+iINOi7mlgzmmX7qmcwvIgELiPvWbp7mot7mal/qohzryhPjzRd2P7ziOv3qr+7iO yzqQ87irx/qN47qtyzopgQJiMjCUK3l1X7mwS/mwB/uUF7uVI/uxUzmxJzu0m0TTUjjUbbq1Zzq2 X7umRyUl3Nsen7qpkzq4j7u4lzuqp4aKco5Y8/95oPs5u7/7oPc3oMO7vAt6vbt7vN/59CFRiz+6 v0c6wP+7wAc8wXMQi8r5i7+QEqPLCcbQ6C0KRsXVGcui6j2Y5UW8K91x5ektSj58xrsqG5+k3m78 T0rhCX6eSUZFPfXtxn88dLV8UVsxLWo7t7CWZEhb7TyVKwdM5AayznO1VqVYxXDl6VZuHypy8AW9 TC39JhKkovQGR5fyztfjrYnuSxFkXG7iJNJufuj8H4f7ZzsPLvi6lHXNuD7v1QlaykDhO5v9HXEh J3kW1YQz1FgfMd/9uRozHK/93d+xl2HJ52VzzCTj3g9nzzyJL/vizMvVIjGazJ8frd/6rGuNnhD/ A5yWY6ixYDuhY1ZxE3pCZEvk2mk0/EDrSq+tcts8U23o493s2kJvmtlwZUBumurHmkinviwhMrMO Duoz9MKAvjpqfuJA9Osr+7M3uzsFiJ/SRLd08U9zcRlX7Q86FMVPJvQPrlJG7eOLy8QvWDWW/Bn/ hfgPZfiHcQ3BLRkmpcY7vNbS/LrgC7E2j+5EYlTf3iCf2K3ExomhLlxWFWgcC0CseqYKRUGDKFQ9 E0hwIYqFCp8dRAExocSCFC0iVKjxYUeOAylGBNlxoMORICdWFClwYsqQDT0mJDlxpsWRGlOalLny psWHLlm+PLlTpcyPNIcKJaqUKcmlTpsmhTpV/2pVXLgoacLF51m1VdWeKQTrFazYiF/Dohi7aqJZ smHRvo24tuxXtWjF+hyrFi7dvnfL8q3Gd2NXtn3P1gXrcHFcvIfJ0vRb+C1jw4oBJ778V25cwo4D T0Zr2a3d0o1Rt0SNOLLbz2vbOo49mS9jyYZnd3292aLizac1D647sbNo479Bs358vDhy5sudR/fK jRI3FNw0gUy4XXt3lwS5f+/OnbxG8iXPgx+Pfn159+yLigy/3qX49+rTy0fZfn/89ObHA/C//PwL ML/60MOJP/zg846+Bc1DSED9tptwvgsXdLBCDAnMsMMPPQwRxBFDZIIbKezARYquWByrxReF0/9t LxdphLFFwWDEcUYbY6yRRh0Fw5E4kVwccsceeQzSR90y0vHFIY3McUkkfXSyyCSpZBFKLbmcEsgl o1yMRxlldDJMK7u8cUosycxyzTfHhFPOOOmcE05fmJDCBeqieoqjP5+qyqhAGRpKp5c+IvRQtgaF CCmk4oOpJEmJ0mnRm/yMtD/9nLq00akSRXQpBCv9aVOgDJ1JVKEgXZWlS1tllClUCyXUVUD7zJUq W3fVVVBfeX3GFzs0oQQXOzajMS4127RyWb96fDazGZ9ts0Vp3+pRSNyUxNauIpcl7ttrxYSWyC9H I1fNat30zNy9jCxoNMHYErJay5Slst4inQ3/011ulT3Tx3Tp0pHdf7V9N1l184Xx4IEhdjjihilm +FopUJACF02YWO8h7hqqMOSkQA7wY0y7k7VkgjJKWcBDgVLQIAdVTlSij5vk6bz6DvIuo0ZX/lm7 Q0UeeuadDSpZvKBWZu/kg877Sehand60oZZVejqkpovGj2iSwV6K67C3Jvtksc32WO2K+GBCHDt8 qdNG4mqT20678b4bTDq31Dvvv/0OHPDBBS+c8MMFp7tcxBk33PG/ieFGHBekiLumlnttklZgOe/V 85Ni/fXzYEnvXPTTSx/d9NRRX931zzXPNXbWaX+9ddWpwtOO3blqznfofvcteOWEB9744pFX/y63 4YFrPjnnn0seeumOJ9766Zl/Xvvor9+eeum9z5577KsnH/zxwy8/fbjxvErE90mMH/755beP/vvl zx///fXvn////RdAAA5QgAUcoCbEgQIaEKtxDXzcAx0YQQhOUIIVpOAFLZhBDG4wgi5AAR9QRAnb 1Q53tzMhCU84QhWWEIUtXGEKWfhCF8aQhjC04QxPVx1c+IISxFiYwrJlMSA+TGJFrNgQJybEHy4x iEg0ohKbyEQiHlGKSXQiFaOYxSlCcYtX5KIVq/hEL44xjFjsYhmvRQxNwMEX4uhY1NaWsjiODW11 LJsdz3ZHPeaRj3NMGxwBKcdA0nGPfsSjIf8LOcg/CpKRhOyjIg8JyUQ2cpGOROQjKRnJTIaEG0xg oxTgoEFRcpCUozRlKVF5SlWmkpWrxBsxskIJJmSnhji0pQxxWctc3nCXt9TlL3kJTF8Gk5jD3Akc 7AAHjq1IfN/rHvqg6UzzPVOa6TtfNaPZTG2qL5vcxOY3t3nNcFJznNM0pzXJ6c3fSaE6xrKfAeFJ QHnGk57ztGc98XlPfeaTn/v0J3fswAQUEEMK6HBlKxF6UIUmlKELdWhDITo4cVAimQHt5UWFidFi atSYHPVoRkG60ZB2dKSOEocUNKEJZp5Ri2BsqRjRSMaXmtGlLLVpTXEK05l+Uac37WlOafr/U6EG lag8LapMfaosycEBBUxwwSWhKklMWlKqUd3kVCuZVU1S9apW5epXtTpJsG41rFgl61nFWlavqjUh a9whJZ4aUbk+lK5ztWtd8XpXvb4IFClNUShLGliRDpakhP2oYQVbWMUedrGJFQociDHRY4FTnZUV p2XTeVnNZpaz5+zmZj1LWdCiM7TlJO1pP9tZ1IpWtWtxwUnhgJ1/zraftaXtbW2bW9zuVre95e0z qgMHceApr8Xd63GNm1zkLle5dMICHFCqRsZO17HVRex1G4td6mrXutkdJhMoIYU8iSOm5d0pUoFq VPWid6jrNW9S3Xve96aXvUedb3vrG1/4/+Z3iMTImFNxsVa0mjWtAxZwgRFMYAUfeMFVdXBXHzzW BDOYwhFmK4QxLOGHMAFu7ARFc5kbYhCPWMQlJnEEwYsnSoiwu9v1roth3GIZc5fGL54xDinhCzjM krymTW1pMQvk0f54tT5mrZBbe+QiB3nJQ1YykaH8ZOrxEA7QFaFvsfzbLG9Zy13m8pe9HOb8XGWH TIibidF84jSvWc1tZi4umIAObjA1xjWus43tfOM771nPfR7ssKTgxpXS9772le+h91to/RIa0YxO dKPxq2j+SprSkDb0o21qBxdETisVzvCFNezpUFvYwKSesKkb/OlSq/rUrE71qF0t6kUGFP+8UmCm m3HNZl3nmte7xqB4QSEFblguz8XG87H5bOxkI9vPzB6scMUBQh8amdpMjnK1nYztJGsbyd1u8rat LWVuf9vb117FxiYXXjGvG8ztZve73R1veIcZFy6AAzrA22t9+3rf/eb3v22kIl9QDrDKbvayEX5w hRuc4c7Gsx2IYQduJLPSmHb0xSNt6UVn3OIcx/ilP75xkHuc5CM3ORd9sUYOrwjVsl41rGEOapm/ fOatjjnNcW7zmr965y5vdca2Al1/Dx3gRSf60ZErcbjxAVkLd3jCGw71pztd6lUnCUrhcBURjtvc 2Q4318X9dbF7nezgLnu5w352cq/d3OL/ONaOAyxvuc977nWn+93tnvf1VGfYQjf635EeeMAP3pTA xgWdqZ74qCt+6ot3fOMhbzoXyJKiW+/4ySet8cxfXuSd33zIP19yz1cc9KQX/RCpownKZaflrY+1 62+u85zzfPY+p73scX973due964Hbw8pTnjhC574wzc+3sxsBxRo2uqPb37kGf986Ue/hMLVxAKz A3btj93s3Uf79tXede+zPe3jF//3uU8+GohXEzzE+/v1Hn/4z1/+9f9fnuAACnFkv/j9P/7//a// VE9jNGb6nI/6DjABoU8BDRDH8iTHAkzzTA/zJnD0JPACOS/0KBADS48DT68CNVC/3Ajf/9ao917v BGNv92Cv51aw9low90wwBWOQBVEwKbBCCpgOWQBwBwOQB30Q13wh5VQkdBawCBvwCBHQCJMQ6n7P 1rIv/cgP/Myv/NAv/KgwCqHw/LDQCqWwCtMJDlzABVIqbuyvDOnvDM0wDdFw3hAIBUAhT3owDn9w DuVwxMQBmVas4JSQAZewD/nwD/cwEIVilnBB/3osA0EwET1wAxFxES2wESGxAyPxAx0xBNcCCzgM BUrwBVWwBl3QE2GQE2fwE2VQFE0RFDuxFDEMBdABBfaE/+gwFutQFmkxgzTGDjAmwPxQEHcRCQHR F3nxutzKDijqCrXwGI0xGbtwC6dwGf+R0RmVMQuj8UQ4jQzXUA2x8Rq1MRu5cYBey8xSahbFsRbJ cRxtURw6CRRY7Bd7sR3Z8R2DMR41ygUOD5QOURLxkRIjkRT+gAoMwg9UQRUCRnNupkoKAov40R8L 4g8CskYIUiK45SEB4yKA6A9QgBQqxg9Q4A/O6Bn+wCILwg8Ykoic4SMN4iPDwlyogCEFUmIC0g+o QBEnkRElcceWKZROURV1kgVVQSEz4g9CQiKP5iRAciMLaQo0Byh3QigvoiKEskJaZWVWYQqogBTu aBRQoCo3SRWK0iKogGu6UiI4kj4WEiyHcidJkQZVMbaU6bXMsaGeASkBsiWrISCR8g//+EVwLBIr gXJJ4nIjG7Ir7BIF/CAv8eYg7YYi6YQg+vJFIgIFRkFOejIrRyElw4IUNBIhaGQyqaAyWcQj/fEr HZIw0WQwMvMtHUoTJAduyMsd5dEigdIpVOEuHcVT+oQtvtIfqwI2qwIprdIpWUdeUKcp+wQPLnIp jDMme2Uyx/IpsPIrR8Ifm/MlLJIKaoI3SQI2L8I1DVATcXBPopELpRHs/DF5GJNbPAs2q0E9kaM8 jYcx5+WytjN65CV6WCYlv4IULsKZ9pJ69hItLDIVuuc/hwMFnAEylQMr7xMaGXQ8K4tYUMTMtnFC C+JDiLNC6cc4AzIioBNpLJRn6sdC/9qDOEEkObVDOkkEBaYAREhhJVFiRT3EH1chPBBiCqZgPajy PrsxG1GAEuAAC1QENRNKIytzThDzbiLCD1hEIy3TRTQyIYy0NOdGSn8kTMbkLyOzJKxTTvZSb7Ay S9/EIjFSS9TCIulSMDdyMKy0HDlINfHEv4BR+kDyD34zKoSTdXgzIbCTKBcyNn8FQ2HHNjtlc6aC IKzzL5WyT8yUdha1TxhzKR0CPkdCQeslTv2QHvXEBXRwJh8xHzfQOE+SJZsUYNRLN/EiK38IVPt0 Q+/FWQbmSKtIMXfKTPUTD2hKVrsIKc9IRfOSLaaARpCSSWTSUztVH5kOC1LOGtEyFP9R0QT7MSNE MiifUjsIAiC1Q0Ph6A+Q0iLwoE5fRSKlhiBxJirJRj9TAClZdY6285JItJAwFDg98iIholZLwn5S US3x9RNd8UfhkE1d6RlG4VkPAi/JVCJpRExpRD8J1i9HYRR8ciH5xWALVnOqFHBAskgTc03jRFb5 Rkj4giAEFCzUQ02FVKFAwRdAqP0sFR5fgisV0k/vNFfusyaaRjYFtk4B9XRidleIU3VylnR0k3Z6 9k+h81UEQj9vNCF8cyOIcGUXMGOELf/CsxkdVDyThy/RE51YRnNUobJSYSPjM53m83vq85sQ03w0 ckzF50nPp1oLlCyMEyMNNTDExWr/qdZu0a/eQAEX3GhCsbFdz0M/QfR9HjYjYhIqPeRCRfRAFjdA 3ilD3lVECGIURgQPlFI/KddD9JMUaHQ7MFcVvhRxd1QbKeFt0MEXbs1fN0hD30QxYfVNCOJXeQRd xyJuWxdKqPRJchdeBud16yR24WRy0VR234R2yXQs5tYf6ZJjVTeDJkr5NKHpWHYX9dNaoUI/lfMx RwcrOVcpNlcmqpcqsBclQoUqdlZQhrZ0fjZXjNNPA6Ug6tQilZQq8rQ2H8IfsTJpmdZpm4+NTgod h1UfiXXS8LeIzJRUkch4mwh4WQR/D+aAF8NVHeZ1HwZXwch3XwpRo+gvC7NF5JJi/yzyV8MlM7Cy IEbBM+pWgFWYJvURK9BBRZAlJ/OVWWVQcFeyawfCZVEAD6RGk8a3j/yxTgV3CkR1RrWVMCGVq9aX a9a1qiLXrFhmCro3IUihhA+XImZTRUdBiEkBKfW3c0FCcOVVdJtVhtPyEwtKE/jABc6sZFlJFTIz IzA2goUSYDViTYQXeePYIhqTjiXyeDOWIMcEgwG5Rp6hcAd2SsJyYEc1goH1dZnXjUVJEz4IK6RX Hl2TK1VVJHEYUus4Kz3HVEcCjjc5UcP1j412OB9yVsqXfG0lIQ1iJb2VZFo0ljP3fRcFNj2iablT 8SjHzFB3ar1wmJmRmJ+xau82mf+NWZiLuZnNzQmrLO78dppHt5qp+ZrtL0Xs4KR0UJKb95u9WRzR AUXwkH97eXrRGZPT2RfFUEWiN4BZOJ6LVZ4tEZ7n+Z7ruRLtOZ8xjTVtLYbLOKCX9V7PmIZnmKAN uqAReqFHMaFDggkEapnCGZwpeqIDkFjcaODMeZ3PWZ09eqMXEA7gigaY4MMaFG+dmZmPGaVXWplT +qRduqWBjBiZ4PCk2ZpxGpt1Oqd5+rbchsPY2KIreqiF+ujeRitSBKSVuqOXmqOdepiyAhfw7cw4 lZ8HeJ+xWp+1uqqzmqu3+qoRLeWGK5jN2KEZuqzPWqAPuqHTeqDZ+q1dDw+JZev/ipqo7bqucW2N +AAO+GAdP5qpAfupm/qvaYwSNLFYQgmml1mxXxqZF9uxG5ulVXqyG7T9QCHrnqqnNXunOXuzPft+ Dg+Z7g2v77q0SdsOKUEdK2ewWTuwCfu1W/t06o2iNq2rwdqrcfu2dXuF8dm2eduqf9swJA4LepSN Zgl14cy4BUrHmHv5KKEVMSZFioWi4AyUlI8YB+4qjlu4BkrYNFGZ3AYFdgx1UZcewWvHuAErtPuk 4Gr/MoYbqCNjiEUrctHtmKpyTMRHfeE6ejSlUADOIFr5hku4dAduVHN3hqWNKKqms4JyNNEVZwmU KscFPEnAi0VjhEuZaE2kT8re/9JboDop9QybjfPkv3PMbYwbesGQCWhAu5lquFKk3jYmDJEJTxg8 /3ARF6yj/dwOK06KYyh5clBK9YJQx1SKcvb7v+e73vw7eoerk4YLUwPNWGbJqQCsct5QpRIIDK8C F/Ok/TgmCEFhd9wJrurNytfIuLMu64aNOiaPknc8vKBLmbhh8qIcAuHKRzlGmfY7RYwltoqlWJI8 x7W5qaDWdEEpuZ0KF+0RolfspMxMzqELbqxDmf5bpWJ8dzaGzHYMHU9qhw6Ph1IESKV8/154WOgR hPaaDzamDQMqCNl4jSfPOtQICxCIEOFG/3ZHU/d70vlWUzXhdDmGGIalzDjsbf9sjaL4QHI8CAXe Bm6wQHLCCysyPAj1xO3QQRz27w4heodsfdddAB0MHBfXb7+FfJuFSwoWiOnAHKXYCcxVjxgrJytQ ZKJOihiQXKWOhcfbiBvkLCuKJYFOdr8/XKT5WssxBhxd4LlwUSsSPJaGy+3cLsF5SFOBjhh0HLpm ac+TCQvs4LKJQbhOXPXYaNhOthVpAL5TCv+SiXLefVjCC6XeTscOb432mw+i18yAbqLoUR09Ppkk Pryw48ERKL15SLy3ua+yvN62WQqIXdyJnZ0+nZxRaszbL7JSDhQ6iW9BXaQLff9U7w0jrkeHHhc7 SRNOlp08PuJ7aM73j9hFmof/gk1FMP7w4AaW/je2NFHToOuDYmvFUCpjjKXIAw0LwpAJ1vjat6J0 +XXg4CoI4QzOkN0OQGi/jZxY/htFdkdPnD0r6rwgxLDKejSWsq66cyx6w8vMMQZjAv1EZt71lw/S UTdPMObPjZ3ytrkgrJw6IF2+2adYKF/jbW3lZonP3a6vkalyevQOdXyiTGTiRZv9OEzj3U75KCqj S3+iUJcYU56S2ammmdtEUhxuDHvRMVHTxSvlanr53GZYVm7/+lo1wTDlPB5Pso71EVvYBF0cQGH5 tKKdAIKSLzi+pGjSREmcC1+4+AjUBAcOEyZSUEhhggIXRjgu4GjCRYkGwoEug/hEREHJoguFdril tEPJoziKKDQxoSRFnEAmvjTxOcgz4kE7mlCgQ5Hxo6+EuKTA4eNCEzcpDO0UVCiQGwpQKMRxpHTT Di4XLqQIpIRlKDpcNkH6oshEo6aVTCBKoWqn40UULkB9RMEtIlUm3JjkxYUSJa6ClKJqXFwQxVKb ged2dBgQADs= ------=_NextPart_000_000C_01C6FC37.64A2CEB0-- From avt-bounces@ietf.org Mon Oct 30 12:21:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geant-0004i4-HP; Mon, 30 Oct 2006 12:20:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geanr-0004hs-V5 for avt@ietf.org; Mon, 30 Oct 2006 12:20:03 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geann-0007AM-IC for avt@ietf.org; Mon, 30 Oct 2006 12:20:03 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 12:19:59 -0500 To: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> From: Randell Jesup Date: Mon, 30 Oct 2006 12:19:57 -0500 In-Reply-To: (Colin Perkins's message of "Mon, 30 Oct 2006 09:24:25 +0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 30 Oct 2006 17:19:59.0403 (UTC) FILETIME=[A09B07B0:01C6FC47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins writes: >> Multiplex in Colin's draft requires a=rtcp support currently (though I >> have a few issues with that still (I think)). That means that to >> exchange keys, the endpoints need to negotiate a viable RTCP connection >> (normal or multiplex). If multiplex, any network elements in the media >> stream need to pass the RTCP properly, AND need to not break a=rtcp >> (which is one of my problems with it - some will break it by ignoring >> it). > >ICE also requires "a=rtcp:" support, so I expect it to be widely deployed >in the not-too-distant future. Uh... yeah. Depends on how you define "not-too-distant". The kicker is that all these existing network elements that will not work with it (SBCs mostly), and from experience many of them are often running far-from-up-to-date software, or are written in-house, buggy, etc. Lots of them don't even *pass* RTCP, let along support a=rtcp. >And, being pragmatic, I prefer that RTCP is sometimes sent on the RTP port >without signalling, than always sending control messages in the RTP >stream. Updating middlebox implementations to support "a=rtcp:" is much >easier than fixing a broken architecture that mixes control plane and data >plane. Um, how will it get sent on the RTP port? To the receiver, it will look like the sender wanted RTP on (mapped by SBC) port foo, and rtcp on (ignored by SBC) port bar. And the receiver will happily comply, and their RTCP packets will go into the bit-bucket. Maybe the implementations can notice the problems or use a side-channel to suss out what the SBC (didn't) do, but I wouldn't bet encryption on it. You could mandate support for RTCP-on-RTP even if not signalled, perhaps. >>> I don't see that being a problem. >> >> Why is that not a problem? If you have a more-typical 24K (including >> overhead) G.729 stream you only have 1200 bits for RTCP - and from that >> you have to subtract an RR or SR, a header, etc. And more importantly, >> without AVPF you need longer intervals between individual RTCPs (though >> perhaps some of those are SHOULD not MUST). There's nothing about "but >> at startup it's OK to ignore the rules", or "only applies if media is >> flowing" in RTCP. > >Sure, but again, a minor change to the RTCP timing rules to allow ZRTP is >much preferable to a major architectural change to allow control messages >within an RTP data stream. Isn't this the same sort of "minor timing change" that required an entire new set of N profiles (i.e. AVPF)? And this wouldn't fit in the AVPF rules, so we'd have to have AVPZ... 1/2 :-) I admit, I like the idea of RTCP, but I don't see how we can avoid badly breaking the RTCP rules. If everyone is willing to break them for this, and it doesn't mean another horrible mess like AVPF/SAVPF has turned into (because of SDP and how profiles are negotiated), ok. >> Realize, I like the idea of using RTCP for the key exchange here. But >> there are issues to address, including issues of network element support >> for AVPF (which looks like it would be required). >> >> There are other options: >> *Use a separate media (m=data) stream for key exchanges. There are some >> obvious issues since it's now separate from the media ports, and some >> elements might not like another port (pair) being allocated. > >Reasonable, but would need signalling support and extra ports. This probably could be done. Yes, it requires another port-pair. (In theory I don't think there's anything *mandating* that a set of media streams use different ports - but people want to use that as a way to try to do profile negotiation.) >> *Use the same media stream, but with the initial payload being ZRTP data. >> (a=rtpmap:99 ZRTP). Exchange data as payload type 99, then start >> sending encrypted data using one of the other payload types. This is >> also an intriguing option, and doesn't need extra ports or a=rtcp or >> AVPF support. > >It's architecturally pretty ugly: a media stream shouldn't contain control >data. I would much prefer RTCP, whether signalled or not, or another >protocol that is multiplexed on the same port (as done with STUN). Well, I think this is architecturally much better than the header extension/NOOP idea, avoids the RTCP BW limit issues, doesn't conflict with hdrext, avoids SSRC issues, etc. It provides a negotiated (you can reject it) media-path control-plane for this specific purpose with no bandwidth limitations and less overhead than RTCP (no RR/SR). The major downside architecturally is that the data in the packets is not per-se audio or video (or whatever m=data type), but what the packets contain is being signalled. It doesn't interfere with existing applications, should be totally transparent to all but the worst-written network elements, and doesn't interfere with normal traffic/packet-sizes/RTCP calculations/etc. Multiplexing another protocol in the same port as RTP is an option, of course, though probably more network elements would block it than would the payload idea. I would probably consider that as the strongest alternative to the payload idea above, and put both above the current header-extension/NOOP plan. I prefer the payload plan because it avoids some issues with the application having to intuit the type of incoming packets, and in general it just seems odd to me. I know why it was needed for ICE/STUN, from a technical point of view, but that's not needed here. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 30 14:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeceM-0005nt-NB; Mon, 30 Oct 2006 14:18:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeceL-0005nk-T9 for avt@ietf.org; Mon, 30 Oct 2006 14:18:21 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeceH-0006Gx-9U for avt@ietf.org; Mon, 30 Oct 2006 14:18:21 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 14:18:17 -0500 To: lazzaro Subject: Re: [AVT] Re: Layer 2 synchronization and clock References: From: Randell Jesup Date: Mon, 30 Oct 2006 14:18:15 -0500 In-Reply-To: (lazzaro@eecs.berkeley.edu's message of "Sat, 28 Oct 2006 12:23:07 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 30 Oct 2006 19:18:17.0120 (UTC) FILETIME=[272CB200:01C6FC58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org lazzaro writes: >On Oct 28, 2006, at 7:16 AM, Randell Jesup wrote: > >> Ok, if this is a replacement for NTP that's fine, though requiring >> anything of network elements needs a really good reason, and it'd better >> be cheap, easy to do and not get wrong, and give some sort of benefit >> outside the very limited space mentioned here if you want hardware >> vendors to implement it in enough equipment for this to be really useful >> to you. > >Consumer stereo and 5.1 speakers are not a limited space, in the sense of >yearly revenue of the market. It will be many years before video- >conferencing makes the revenue numbers of consumer audio speakers :-). Though most of those aren't attached to ethernet... :-) >And while any of the individual pro applications we've mentioned may seem >like a "limited market" in comparison to the consumer speaker market, you >have to consider the "long-tail" effect. If you build core technology >that works well enough to be usable for these small markets, all of the >small markets adopt it and together it becomes a sizable market. Yes, that can happen, but you need a large enough driver to get it built in the first place. If you're dependent on other people putting it in there for close to free, you had better have a good reason for them to do so. If it requires single-sourced (or small-number-sourced) hardware that's much more expensive (due to low volume/competition), then it's really hard to get those small users to jump on and build the market. Not quite a direct example, but look at 802.11 vs. Homeplug vs HomePNA. >And also, content creation technology needs to be nurtured so that new >music people want to listen to comes to be -- Bing Crosby sold a lot of >radios, the Beatles sold a lot of turntables. Ok, I suppose, kinda, but I don't see how that has any relevance. >Focusing on stereo speakers, here's is the basic problem. If you want to >send digital audio to stereo speakers today, you have two choices: > >[1] The left speaker and the right speaker are housed in separate >cabinets. You send the digital signal to the left speaker (wireless or >wired), and connect the left and right speakers with a (usually) analog >cable. This lets you get good stereo separation (you place the speakers >in different locations in the room), but the cable connecting the left and >right speakers defeats the goal of a wireless speaker system. It doesn't >solve "the spouse problem" -- one spouse wants the best sounding speakers, >the other spouse doesn't want ugly wires running around the living room, >so the couple leave the store without buying your product. Ok, so that's a more widely-applicable problem set. It also has majorly relaxed requirements compared to some of the requirements mentioned. This doesn't need a tightly synced network-wide clock. It merely needs synchronization between multiple receivers. Your two main choices here are a) multiple unicast wireless streams and b) a single multicast wireless stream. A multicast wireless stream has a big advantage here, since reception time should be identical (modulo speed-of-light). In that case, you don't need actual clock synchronization; you just need a fixed delay from reception to playout. If you go multiple-unicast, you'll use more bandwidth and the reception times to playout time will be both longer and much more variable. This requires some level of clock sync, but since it's all single-network stuff, there are quite a few ways to do it either with NTP or SNTP or some derivative. Again, a clock-sync protocol that uses some type of multicast clock time will solve the normal "how do I deal with estimating network latency" problem with NTP. I suspect you were trying to solve this "pulse" problem by effectively recording in the packet the time it went from internal buffers to the antenna/wire (or, somewhat equivalently, the delta time between submission to the stack and transmit time). This would be better modeled on how IP handles hop counts. If you want this sort of scheme to really work well, the receiver of a packet has to add the apparent transmission period from the approximate time-in-transit, or the sender has to add the expected transmission period before actually transmitting it based on knowledge of the channel bitrate. In theory the receiver could in hardware record the time difference between first and last bits and use that. And you'll still be missing speed-of-medium (light, electricity) delays and a non-knowledgable network element (router/bridge/etc) could induce unaccounted-for delay. Another problem with this is that the line protocol might have issues that interfere with trying to record the transmission time before actually transmitting. This is something more of a hardware issue than software, but it's tied to design of the lower layers of the network, and if it's some form of "wait until free then xmit and check for collision" (like ethernet), you may have a problem with not being (quite) ready to start transmitting as soon as the channels goes free. >The IEEE proposal is about adding a third choice. Two speaker cabinets, >each with its own wired or wireless Ethernet (PoE lets you get rid of the >power cord, which in some markets is more interesting than getting rid of >network cables). For this to work, you really need the sort of >sub-sample-period timing accuracy that has been mentioned on this thread, >for all the nodes participating in this network. Or use power cords, and use HomePlug (which supports QoS, and generally is lower latency than 802.11). That also avoids the very limited PoE voltage/amp limits, which would be a bummer in a speaker. >> What bothers me the most is the "insert time in the network stack" part. >> a) latency from sample to stack is rarely fixed except in the most >> special-purpose hardware. > >The conjecture is, if smart people come to the problem with an open mind, >they'll find the abstraction that hasn't been invented yet to solve this >problem. Which is where I'm trying to push you - it seems like you've gone too far down a rabbit hole already with assumptions about how to solve the (vaguely defined) problem. Nail down that problem-set first. How widely applicable do you want/need this to be. How accurate? How widely distributed (local transmission, local subnet, local set of subnets, WAN, etc)? What cost? >Application Layer Framing (ALF) is at the heart of RTP. The conjecture was >that for real-time media, the application is the entity that needs to >break up the stream into packets and fill in the headers with timing and >sequence info, not the network stack. > >The opportunity the IEEE folks pose -- the potential for maintaining a >very accurate clock across a network span, an accuracy that can only be >maintained using hardware directly managed by Layer 2 -- is a challenge to >ALF itself. When done in a simplistic way, the act of passing the clock >between Layer 2 and the application layer destroys what makes it valuable >-- it's accurate timing. All you need is for that network-level sync to feed an offset value and (possibly) drift compensation rate that the local hardware and software can use to accurately convert local hardware time to network time. Once you have that, you can sample and playback accurately. >The goal is to come up with new abstractions (or repurpose existing ones) >that finds a way to split media between Layer 2 and Layer 3 while >maintaining the clock accuracy. You're assuming again that splitting the layers is the right solution, which you certainly haven't proved. >There's a strong economic incentive to (1) have the new abstractions be >compatible with RTP, and (2) have the new abstractions take the form of a >network protocol instead of an operating system API. The incentive for >(1) is to use existing payload format protocols and to play existing >streams. The incentive for >(2) is that network protocols are one of the few places for >interoperability left in computing. > > >> b) the more I hear the more I think you want to >> get the true sampling time for a set of samples. This is really a >> hardware and system issue; it's not a network or protocol issue. IMHO > >If you look at it the way you suggest, it leads to you to designing a new >media transport protocol for Layer 2, which someone (Layer 2 for the >protocol, the operating system, or applications) has to transcode from >something (an audio API like CoreAudio, or a network media API like RTP). >There are many economic incentives to avoid this sort of reinvention, and >that's why the IEEE folks are here kicking our tires. Telling them they >really don't want to buy our car is not what we should be all about here >in AVT. Just tell them the right car to buy. :-) Seriously, I think a strong candidate is a better (and more-local) variant of NTP (perhaps dependent on changes in the network elements and their stacks), combined with normal RTP. But here I'm making assumptions about the problem-set myself, since I don't know what it is exactly. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 30 14:58:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedGQ-0001EJ-Rg; Mon, 30 Oct 2006 14:57:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedGP-00015H-2n for avt@ietf.org; Mon, 30 Oct 2006 14:57:41 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GedGH-0001na-Vw for avt@ietf.org; Mon, 30 Oct 2006 14:57:41 -0500 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.8/8.13.5) with ESMTP id k9UJvTZZ024602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Oct 2006 11:57:30 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53714596-8BAA-4042-966B-850A8A25EDFF@eecs.berkeley.edu> Content-Transfer-Encoding: 7bit From: lazzaro Subject: Re: [AVT] Re: Layer 2 synchronization and clock Date: Mon, 30 Oct 2006 11:57:27 -0800 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lazzaro , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 30, 2006, at 11:18 AM, Randell Jesup wrote: > Which is where I'm trying to push you - it seems like you've gone > too far > down a rabbit hole already with assumptions about how to solve the > (vaguely > defined) problem. Nail down that problem-set first. How widely > applicable > do you want/need this to be. How accurate? How widely distributed > (local > transmission, local subnet, local set of subnets, WAN, etc)? What > cost? The approach I'm going to take personally is to spend a few weeks thinking this thread over, and if I come up with a set of answers to your questions worthy of documentation, I'll write an I-D. Then we can resume the discussion with concrete ideas in a document to reference. However, a fair number of folks on the list have thought these issues through already, and may be ready to respond to your points now. If so, I'd recommend those folks step up and continue the discussion now -- both here on the list and in San Diego next week. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 30 15:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gedig-0007Z4-CE; Mon, 30 Oct 2006 15:26:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gedif-0007Yz-0x for avt@ietf.org; Mon, 30 Oct 2006 15:26:53 -0500 Received: from gwmail.avtcorp.com ([198.135.234.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gedia-0004YB-Hi for avt@ietf.org; Mon, 30 Oct 2006 15:26:53 -0500 Received: from AVTECH-MTA by gwmail.avtcorp.com with Novell_GroupWise; Mon, 30 Oct 2006 12:26:41 -0800 Message-Id: <4545EF65.1C8A.0056.0@avtcorp.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Mon, 30 Oct 2006 12:26:14 -0800 From: "Joe Kelsey" To: "lazzaro" , "Randell Jesup" Subject: Re: [AVT] Re: Layer 2 synchronization and clock References: <53714596-8BAA-4042-966B-850A8A25EDFF@eecs.berkeley.edu> In-Reply-To: <53714596-8BAA-4042-966B-850A8A25EDFF@eecs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I think that Randall just doesn't see the NTP problem. Clock synchronization is a very difficult problem and it has to occur as = soon as you apply power to the device. NTP synchronization takes almost a = day to get to the microsecond level. Wireless sound device synchronization= has to occur within seconds of power or it is not useful for real-world = devices. If you look at IEEE 1588, the biggest difference from NTP is that the = protocol requires definite timing of network latency by insertion of a = timestamp at both transmission and reception. NTP only inserts one of = these timestamps and assumes a fixed value for the other. If you have the = application transmission time stamp, the network stack transmission time = stamp, the network stack reception time stamp and the application = reception time stamp, then you can synchronize your clocks very quickly to = a very fine point. Without the network stack transmission time stamp = (missing in NTP), this takes hours to do. Now, since you had to modify NTP to introduce layer violations to actually = synchronize clocks quickly, what can you do to RTP to make it more = acceptable. I think that Randall is correct here, there really is no = reason to open up RTP to network layer violations, but the clock synchroniz= ation issue is one that many computer people just seem to assume has = already been solved. NTP is nice and it works, but it takes a long time = to produce its results. Not every consumer device can afford to wait half = a day in order to start working. Sometimes even waiting a few seconds is = too much. /Joe >>> lazzaro 10/30/2006 11:57 AM >>> On Oct 30, 2006, at 11:18 AM, Randell Jesup wrote: > Which is where I'm trying to push you - it seems like you've gone =20 > too far > down a rabbit hole already with assumptions about how to solve the =20 > (vaguely > defined) problem. Nail down that problem-set first. How widely =20 > applicable > do you want/need this to be. How accurate? How widely distributed =20 > (local > transmission, local subnet, local set of subnets, WAN, etc)? What =20 > cost? The approach I'm going to take personally is to spend a few weeks =20 thinking this thread over, and if I come up with a set of answers to your =20 questions worthy of documentation, I'll write an I-D. Then we can resume the =20 discussion with concrete ideas in a document to reference. However, a fair number of folks on the list have thought these issues =20 through already, and may be ready to respond to your points now. If so, I'd =20 recommend those folks step up and continue the discussion now -- both here on =20 the list and in San Diego next week. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro=20 lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org=20 https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 30 15:41:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gedw3-0008Rr-O6; Mon, 30 Oct 2006 15:40:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gedw2-0008Rl-ID for avt@ietf.org; Mon, 30 Oct 2006 15:40:42 -0500 Received: from mx1-012.rad.co.il ([212.199.240.8] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gedvw-0005nU-BB for avt@ietf.org; Mon, 30 Oct 2006 15:40:42 -0500 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k9UKXFod027963 for ; Mon, 30 Oct 2006 22:33:15 +0200 (IST) Received: from exrad3.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k9UKXEGH027960; Mon, 30 Oct 2006 22:33:15 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Re: Layer 2 synchronization and clock Date: Mon, 30 Oct 2006 22:40:20 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D02385779@exrad3.ad.rad.co.il> In-Reply-To: <53714596-8BAA-4042-966B-850A8A25EDFF@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Re: Layer 2 synchronization and clock Thread-Index: Acb8Xft9z/qXEgDjTiScJxu6d9YD5gABPlJg From: "Yaakov Stein" To: "lazzaro" , "Randell Jesup" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org =20 Sorry to come in on this thread so late. At the last IETF meeting there was a bar BOF on extending NTP in order to solve several problems, including ones similar to those being discussed here. A mailing list has been set up https://www1.ietf.org/mailman/listinfo/tictoc=20 and two design teams are working on requirements documents. We decided at the last moment NOT to hold the BOF in San Diego,=20 amongst other reasons in order to enable 1588v2 to progress a bit more. However, we intend holding this BOF in Prague. Y(J)S _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 30 17:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefRi-00009v-KS; Mon, 30 Oct 2006 17:17:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefR1-0008HO-02 for avt@ietf.org; Mon, 30 Oct 2006 17:16:47 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GefDc-0007KI-Ke for avt@ietf.org; Mon, 30 Oct 2006 17:03:01 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 17:02:56 -0500 To: "Joe Kelsey" Subject: Re: [AVT] Re: Layer 2 synchronization and clock References: <53714596-8BAA-4042-966B-850A8A25EDFF@eecs.berkeley.edu> <4545EF65.1C8A.0056.0@avtcorp.com> From: Randell Jesup Date: Mon, 30 Oct 2006 17:02:54 -0500 In-Reply-To: <4545EF65.1C8A.0056.0@avtcorp.com> (Joe Kelsey's message of "Mon, 30 Oct 2006 12:26:14 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 30 Oct 2006 22:02:56.0162 (UTC) FILETIME=[278AE020:01C6FC6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: lazzaro , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Joe Kelsey" writes: >I think that Randall just doesn't see the NTP problem. I do, though I know relatively little about NTP - I trust your comment that it synchronizes too slowly for this purpose. This was why I suggested that one of the first things that should be considered is a "better" NTP, perhaps one that only works within a limited network domain (subnet, local layer 2, etc). >Clock synchronization is a very difficult problem and it has to occur as >soon as you apply power to the device. NTP synchronization takes almost a >day to get to the microsecond level. Wireless sound device >synchronization has to occur within seconds of power or it is not useful >for real-world devices. Agreed. >If you look at IEEE 1588, the biggest difference from NTP is that the >protocol requires definite timing of network latency by insertion of a >timestamp at both transmission and reception. NTP only inserts one of >these timestamps and assumes a fixed value for the other. If you have the >application transmission time stamp, the network stack transmission time >stamp, the network stack reception time stamp and the application >reception time stamp, then you can synchronize your clocks very quickly to >a very fine point. Without the network stack transmission time stamp >(missing in NTP), this takes hours to do. Ok; not knowing the details of NTP I can accept that. It sounds like there's a way there to make an improved (perhaps local-only) NTP. >Now, since you had to modify NTP to introduce layer violations to actually >synchronize clocks quickly, what can you do to RTP to make it more >acceptable. I think that Randall is correct here, there really is no >reason to open up RTP to network layer violations, but the clock >synchronization issue is one that many computer people just seem to assume >has already been solved. NTP is nice and it works, but it takes a long >time to produce its results. Not every consumer device can afford to wait >half a day in order to start working. Sometimes even waiting a few >seconds is too much. Right; there should be a series of time-synchronization protocols (or variants of one protocol) for different domains. A fast-converging but limited to (fairly) local network protocol has value. You probably don't want to run it on a WAN/Internet for general synchronization of servers and workstations. The best solution is one where it's effectively the same protocol but with different options or data (supplied by hardware if needed). The other side is that if you want this to work on local/household/etc networks, it's much easier if you can handle it with minimal or no support from the intermediate network elements. Alternatively, make it of value for other (common) applications (and simple) so that router/etc makers will have no reason _not_ to include it. If it requires a hardware spin or non-trivial changes in the software, it may never be more than a niche protocol. Can it be done entirely at the level of an NTP-replacement, without modifying network stacks? That would be a major advantage. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From dlwrdaooye@osg-global.com Mon Oct 30 18:59:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geh2e-00044e-Ke for avt-archive@lists.ietf.org; Mon, 30 Oct 2006 18:59:44 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geh2e-0002hc-Gi for avt-archive@lists.ietf.org; Mon, 30 Oct 2006 18:59:44 -0500 Received: from s01060014229b7a32.cg.shawcable.net ([68.144.58.239]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Geh2a-0003ps-Vo for avt-archive@lists.ietf.org; Mon, 30 Oct 2006 18:59:44 -0500 Message-ID: <000d01c6fc7f$7523bb80$ef3a9044@Taysha> From: "other" To: avt-archive@lists.ietf.org Subject: Brand Certified Store Program Date: Mon, 30 Oct 2006 16:59:38 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6FC44.C8C4E380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd ------=_NextPart_000_0009_01C6FC44.C8C4E380 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6FC44.C8C4E380" ------=_NextPart_001_000A_01C6FC44.C8C4E380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Massy is fri oct? Products News is Business Cutting or. Lookread in morecnet of tv is Bluetooth a battery of lifetom Merritt. Our content of first. Technology product is reviews price tech video = and. Shop by Brand Certified is Store Program ec of? Edge Threats Media. Show Updated or Hottest coming this fall Photos = Infiniti has? Here are is best virus busters. Bites Studio ca of. Ninjas so little seasonally rando Alpha Popular = Spyware. Ultrasharp fpw Apple a Cinema Display inch in lcd! Are best am virus = busters there a. Needleman Buzz Loud am Notes Vampires vs Werewolves Weve grown a! Section am servershp Tvstoshiba cellphones Help or pricestips Tvabout = copy Networks? Navigation moved another Ukbased operator is that or they have ! All Cnetthe web Today on amp. Digital cameras Games gear am gps! Massy is fri oct? Store in Program ec From Brandsdell in biz or = Notebooks. Chocolate fights Krzr a Honda! Tomtom am partner collective wisdom traffic service a? Stories Roundup or Brandnew Tmobile Amazing onespeaker Yamaha system or = Chocolate am? Biz Notebooks Desktopshp big is the new smalla good? Me Forgot out View. Philips Brilliance in wp in Samsung Syncmaster! Spy Sweeper Limewire. Turn ipod or into. Products News is Business Cutting or. Lookread in = morecnet of tv is Bluetooth a battery of lifetom Merritt. ------=_NextPart_001_000A_01C6FC44.C8C4E380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Massy is fri oct?
Products News is = Business=20 Cutting or.
Lookread in morecnet of tv is Bluetooth a battery of = lifetom=20 Merritt.
Our content of first. Technology product is reviews price = tech video=20 and.
Shop by Brand Certified is Store Program ec of?
Edge Threats = Media.=20 Show Updated or Hottest coming this fall Photos Infiniti has?
Here = are is=20 best virus busters.
Bites Studio ca of. Ninjas so little seasonally = rando=20 Alpha Popular Spyware.
Ultrasharp fpw Apple a Cinema Display inch in = lcd! Are=20 best am virus busters there a.
Needleman Buzz Loud am Notes Vampires = vs=20 Werewolves Weve grown a!
Section am servershp Tvstoshiba cellphones = Help or=20 pricestips Tvabout copy Networks?
Navigation moved another Ukbased = operator=20 is that or they have !
All Cnetthe web Today on amp. Digital cameras = Games=20 gear am gps!
Massy is fri oct? Store in Program ec From Brandsdell in = biz or=20 Notebooks. Chocolate fights Krzr a Honda!
Tomtom am partner = collective wisdom=20 traffic service a?
Stories Roundup or Brandnew Tmobile Amazing = onespeaker=20 Yamaha system or Chocolate am?
Biz Notebooks Desktopshp big is the = new smalla=20 good? Me Forgot out View.
Philips Brilliance in wp in Samsung=20 Syncmaster!
Spy Sweeper Limewire.
Turn ipod or into. Products News = is=20 Business Cutting or. Lookread in morecnet of tv is Bluetooth a battery = of=20 lifetom Merritt.
------=_NextPart_001_000A_01C6FC44.C8C4E380-- ------=_NextPart_000_0009_01C6FC44.C8C4E380 Content-Type: image/gif; name="Amazing.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6fc7f$7523bb80$ef3a9044@Taysha> R0lGODlhrAHIAYf2AAAKAIoNDgCHCY1+CAAAcXwAeQCCfsrFssPkuavO9D0SAFYWAIkkBawrDcoT AOEcBQA0AiY6ADxJAF8yBHY+AKZNAL1GAexGBwlfABlqDkNqAGZRBoRlAKVjB8plANFhAACJBSx/ DTRyAm15A4aCBZKBBb5zCt2NAAebACCpBUmqAGmkBoWeAKClDrWqCNylDgG9BiC2CjjBBlrDAHfF BZLCAMmxDebBBwDeAB7XAEXjAFTgCX3kCpnrDMvnA9vhAAEOQREIPjgAS2MAP3kKTJwARbwLN9UL QAAnSyoWMUsTO14STXktRaAWSbsnQ+QkMwRIRClKNDI6RWJBNXsxOa4yO7k3PO1DRQBqSiFrTTls OWxfSXhoC6VaQbdgROVdSwZ6MxyESD6OPmOATXOLOJ2LOst5NNGKPgCtQCOtPU2oO2WVM32ZM56a PLyjO+GRQgDNRCbLNEm8NV++RHbDSJPKQc21QuaxMgDkSijSNDjnR2LeR4LrRZXSTbnfQ+TmQwAJ iSINjT0DhVYDfYYHgaYAhsgAcuYAeAAihCMjjEgidFUrf4kci6wnjscTdOInggFEjSpIfjs0g2ZA dohMjqFBjrMye+lFgANdghJXikRsiV1TjI1gdJRnc7VucdJdfwB/eSZ6hkSNhW6KdHaHdaOGi7aC gOeIfAujdh+XiTuoiWKTjnitdqOqgsCofOCXjgPCjhWxgzuyemHBhYbEcZaxcc3Aeu25iQDXcRjc e03njWzUdYnueZTter/bitPoigAAthUAwz8HuVsNt44Av64AzbMAzNwGvg4lwykZwjIaxmIqyXse zp4jwLwWtdoStwBCtRExxjpKtmVKsotHvKE6zs1Ct909zQBlxBVSzk1Yx19cwYFeu6xnwb5mw9Nb yAZ4tyZ0zjVysm18ynOLwZ2JscaLxOODuACqzhKntEKpu2yYwYeVsZ+rx8OjydiZuwG9zhW0xUK4 yl27sYa+y6XEuf/+8p6fsYeJg/wAAAfyAP//BgAG9vkA9wnz9f/x/yH5BAAq6BoALAAAAACsAcgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKEnaW8mypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq06M+USJMqXcq0qdOnF41KnUq1qtWrWLNq3cr1JtSvYMOK HUu2bNezaNOqXcu2rVugZePKnUu3rl2Eb/Pq3cu3r9+/gAMLHky4sOHDiBMrXqx3V1eNjCNLntz2 rscPmO1lbvlBs8vOmENvFg2adGiWp1GL/rxaZmfOnzWbjk175WvbsU3ftt1admrWu3d71i27tm/i xm/r3owbNmzkL4P3Pv6bd/XrqYVTJ+3ZnuWBRF8z/8ctHDTM8s5Vq+/enH376M/jz9SunD167cnf S19//zz68+mhJiB9MQXnnnk1IXiggPMFqJyBBDIoYWKQibegfe9NCF+A3RmYIU311ecegLUpiOGI Gw7oYIkM4mcifhemZ+KHEipoYYIntgfjhB6iiGKPzX3HUYcXiuhigxqSJ2NOIbYIYoovOomkijWS aCSAQK7IYoQkDiflkyLq+CSPNP7I4WtC/hNec1eyOZtvXfoYpWo7Lmnkm3Ryp2SV2/3H5pIb3snd jT4eCN2MhWIo6HRUxgidfs7BuNyZlAFF6KU5FuinnNRpOmabdZqZqY0g9qYnjU2i+mV+tIVZJpF/ Jv/K56mydhppnqJmGGpgFYqpaJJxZrmnrKGS6mqcbl6XKbK+qjrskbGmKCqtxP76ap6YAgvoqsOS 6VyavS6Yaq2QUhqjtFg2WmygZB6Lbrm6ysdpo6zeGq9r1pLbZrMFajkiosKulOaa/wIJrbfrFffv vXKW565x3Z67LroPJgzvmZJy6KW//rGmrYYzEtrvtuMBbK5iGp3msINvUutiyYFOlzHLLsO3qXQ1 v4tzsLOtHKzN9Y7MI57xEviomdiNJu1/A1ca1K5ORy311FQ/XfXVWGet9dZcd001ZF6HLbbTY41t 9tlop6322myPDXbbcMd9FrgM2ZPP3XevhHfeeuf/45Lfdu8tk+AtAd6333yzBPjehr+Ed+F/B864 5Ik7Pvnhf1feOEyPK77555dHrrjoljdeud2Ud1564aEfnnjrnKuuN+uZp+4466Z3fvriAtOt0Oeo jx545MDXLjzqpvdNPOmeNx/86JvPfjzzxxtuvfQxvb548dMPDz3k2NOuvPff06R9+LcLn3zs4CPv fPPrzx6/5uRLD7jvv3MOPuKQR5++/uvjX/lmwr3rPa99B0Qg+nhnPwKKToAL/J/7qqe//R0QgoN7 oAP7p8DucVB+3yvgBT04wQZ6B38I8V8AR+i/Dn6wgclrIQkZGDwVujCBCaQhBiUYQgXaEIQvdCH/ /2JoPgBucIA4TOIAIThE0mGQhstTX+/CQhTZhU6HmKtg9kZYQ/WdbobY297k4pc53WkQhLJDHxAN CEYgIhGMWGTc7gAIuxW2cYsGFOATgwhFC5qwL2/znh27KL72EY6NWMxh9H5YQhUSriY7tF7emEg9 N/bxh2xUoyYpWcIt3k6GtnNdC2WYxzWGMoxSdN3zGHg/FB7kk1EkJPUWKcpUytKHWuSkE28SSSNG EJZ/3GQtb2jDUoIyiTus5Co9GTszonKUj+xjI01Ytqn0kog8zCEqg5lMHHJvmhI8phvVmEhcsrCS iFTmL4kozuKBkpFKHKUtryfPbWoTm1kD3iCV9//N8Y2TkKDTpvHqx8VZalGWmPTg+RQ5y0vekHx8 C2g7JanJO24Sn//MqEAp+saI5vOQ0TQe7HDn0McF9JSrC6ccvdnM3MEzjbjzIegeKdCKeo6Mw5Mj NHGqTFq2NILFPCjyNOdM54lTbkhNqlKXytSmOtUtgXyqVKcKk2pS9apYzapWt8rVrnr1q2qLKljH mhNXmjUhAnBJWluy1pW0VQBwjWtcWSJXt76krW6Vq17hSte9+hUmeN0rWwWr1rr6la927etc83pY viKWroN9LGP/qlZ7UFavMllsYR172LtqFrKgPatoCxJYy7IVsnhNbF9Pm1rTVva0MyktaFE727z/ qjYmqZUta2vb2tzaFraSbe1te+va19b2t5Z9q26Le1fYJle2oxULUd5a3NIS17nYva12hYvd5ZqW uq/l7nGNS9vhNhe4zF2reMlLXOGud7vjzW5m2UvWq1AXvHa9rnbHq9/90ve4acXvbmNL4MoKuL+u DfCAbeLd7wKWJu5l7oMZ/N/6UuW+vJVwenFL2ey+d7m+FTBqCRvZCS+4wb5NcHkpzN/n1vW5uH3w hyEsWfNa2CWQUS9o8Zti/2oYwTNWbI3BG+H3Dpa81Z1shNGbWAVPNsYt/jCC8wvhm/TYtdGNLpW3 rOQKI/nHX65wbl9cZJ14F7NJPu+O1zxlGy+4/8DxdfJ8WZzhE2b5rFyWc5oBbOIWy9fLutVxeM3s 4TX72dBbvnJ3m2tkMDt3vY2WsHDv/JWiDFnEZ7aumvkMZ0nDd8w+5rSbuQxfJq82uX/2NKILXdhT o7rOfb5ypG/cE1l7Wcj7HXODb+1g1qJZyTV2sa3fPOq5ghrXUI6sctH8a8+697MaVrayBU3rKUal 2th+CaWhku1ue/vb4A63uMdN7rxs+9zoTre6wVPudpd73fCOt7zp5u56i3ve0WUEvvfN7377+98A D7jAB05wkdj74AhPuMKxWvCGO/zhEI+4xCdO8Ypb/OIYz7jGN87xjl984SAfDAhCTvKSG8XjKP9P ucpXzvKIm/zlMI+5zBHT8prbPCUzz3lSb87znvv850C3qs6HvragG/3oSE+60pfO9KY7fSkoeLrU p051dBP96ljPuta3znWmVv3rKu+62MdO9pyD/exoT7va1872toOk7HCPu9znTve6232p/LBJ3rG2 d7QB4O8AOMvfWRL4wPDj8Hnvuz36fniWKP7xiF8J4hs/+cRPfvGXv7xLIt94yWO+85KPvOMpz/jR g97zpne86nki+s+DXvMtybzoXx/607se9YvH/WEgU/i0DH4lvRcKXrxyEMXnfvWYR/7xcZ94mBi/ 9LFXPuppD33jRz/505cJ9I+//Zx0//Ha37z/6qkffs/vHfrfGUrwCf97wNuj/e4HPvzbT/iWBL7w +J//+3sf//dj5fnXd366B37m53zip3vLZ30CuIDRZ32r13y554DMJ36c13qzt3wYmIDSl33XF4Hc l4Ed2HwASHMZsX7+B3wniH8nuIIoyH8rGHz3h4L2l4ItWH8saGcFgRN4MXuVx4EEWHvn13oZyHgX iIAfyIAPaHtHWIAx0X0eOIGlZ3sjqIEvQYRB2HkQeIVVOH4KiIPrZoIuqIL+54L7N3hkGIMzOIby Z4YyeH+AZ4LWRhA6+ErjF4AcOIB1uIUhuHlC+IAF+IMIKIAeKIFUmIca2INduIdG2ISHyITS/6d5 Sph36ScUYFh/YoiGaliDbXiDKoiJaNiJbAGB5oeIHdiIeoh8I+iAgiiCpTiE2SeKpwiA2weLIDiF Thh+UeiIgUiBBzg26xeGmwiMmviCL8F/nkiDmYiMWgGLzIiBP0iLuxiNtch8opiIfhh6i+iM12iK T9iLgGiNhliNqRiNgFgYYPOGa7iJY9h/6EiGN/iC+ceGyMiOOEaHNoEQkNiADViBpIeFsGeLmVeK nDd6tweEfCiOpjeFnxd71Vh72diHz1eEkFiEyfeP0iiI8+YTcEgTG1kVw3eP9ohVhCg2ezeJatGR MoGSdTeSXcOSgOF2MBmTMjmTOHd3NvmSav+XBTTpFACwkz5ZEU9ANz1JRTdZlCo5Nz+ZlCIxlJVW lEapF9FlB0qpckw5lVYZXVV5lTCZlZTGlUrhlG1zlPWllRP3d0gHlmkjlmi5llShlmyJNRVAFHHp NHNJFL/3biXYfzbYEx9JggaxEnVpDxUwmDAxmHVpmCwxl4apmIQJmIiZmI8pmI25mJDZmJJ5mC0R l5apmZQpmIkZhxThlTPpjsIXkrv3SpSJmZn5maqpmJ/pmYAZE6oJm4EZmy7Rmqu5ma9pm7A5lepn iZkYf/Q4Npq5m7WJmchpnLZZm6v5mq7ZnNAZm4FZnM8Jm7xpnW+5l244jMT4jlxTnLx5nM7/OZmV iZuy2ZyHSZ63uZ7T6ZnV2Z67uXUagY7ECIP0KRN9eZp/+ZizWZ7WCZ7/uZyOCZ8Cyp4vIZ7t6Zr9 2Z5kaRG/CJx7WRP5aRjDR53xaaDSqZy0GZ3wyZwAeqEfCp4ASqCe6ZuU6BLCKIPKSJzu6ZzrGaCz +Z7xGaMHep3heZ0j2p8vmp0R2p3CeZduKTWdeZnGOZ26eZmMmZ6WiaSVyaT+OaCZyZ+QOaMXyqNc xZw9gaWSoaVWilVcuhNfmhhhOnRiRRUTqjUNum5duqY/wQZ+oZJByqYkx3t6yZF22hJnKhjt+KM2 iI5pWnFxqqIxsX55ChgP2oIpCpp/6nCH/7qO21mGxniJiqomh9GoMQiKeLqo52aX9KeJmJqMnxg1 P0p/l3iXckqhGZGGoUqDKYqJk8oYx/ipKKipm2oUmCqpreqdThOr3Kmrp/oXgeSOuAqhwfmqi8Gr 8oeiXkiro6V+enmGiAqknRqohjqqYrh/kPqr+nltynpyprk1zEppVUGt2lqup1oG5pqu6up7vriu UvWGHRmk8AoU5GqX3ZqO7hoZ82kTgVqvaViPfykV9Amk9XcS8RCuQvcTKDmwnfqO9nmro4qv/roT ruqdE4sT8RAP+SoV81mn3UmslViM2FqfxHqChaqRnCiyy9oRGYuw2zaD7neGwmmx9hez2v8JqRVr rLZqqo0aEi3rsi/bo7majP86tETrnSersB/Lgh/xs0C7baRJsiq6kcL6scgqg0mLslWbqRvhtE9r Fs4KhwxLsDDxsK46tuwnqFhxn9Z6sRurFmWaE26rtjORtT3hll9rGdywtxbhFhfrsW8xt29rFXtb uNxQVqk6uFORdIZrEoq7uLT6uBwbuZJbFGo3FCfgEpl7ApzbuZvruS2RuaH7Ep77uaV7uqKruZwb uqm7Eq0LuqrbuSzRuq5rD7R7u7DruqfLuqvLu6yruraLu8FbusGrucMru6Q7u6ibu8P7u6P7chpx u7YLE6/7vNNrvNZ7vbU7u85bvN7Lvd//q73bu720e72pW77VO77AC769673tq7vhW7zlG7+bu761 i77Y+729+77Te7mYy77Um73nm7wykb7qK73Tm77zK8DqS77gy8AN/MD568ADXL8VLL7cW734m8EE /MAIXL8STHcDjMEHbLzzu8Al7MEBDML3WxMK3MEsDMEkPMMzbMEczMI2nLwaHMAtPMHmu8Lii8Jl N8KoG8QmHBPIO8EGfMI/3MMzQbwRfMEdrL1FvMBMLLognMU/XMXjG8MqvMEArMNdDHNgg8PUy7wh fMZKzLxXDMDnm8QpDMY0DMURPMdAnMA9rMVMTME8PMIhjMV3/MP++79+bL177MIybMCj/0vEJIzA HKzESCzBh+zDTizFVFzDbtzHaPzBgQzINmnGUyzHTyzDRvy8O4zBjuzEkhzJKszDU9zEl+zHXlzC syzLPlzIsIzH0Ju4pXzLlNzAiuzI7bu/6/u+qVzIqZy9udy95vvGdTzLunzLXkzMpEzFzozKmcus kry7cozCdJzCAmzM9nu8pLvJcFzHjXy8cGzOivzIJszNwLu7fxzOryvOvzvIlRs1U5DP/NzP/ux1 eRvQAj3Q8PbP6UrQBJcJNmfQ5orQDl0SDB3REk13D13RFn3RGO1Ka5DRHN3RITHRIB3SIj3S9+bR Jg0RJG2lJ73SLN3SfZvS2enSMj3TNP8dsDB90zid0zq90zzd0zodk+kAcBBQ00TtdjxBBj59dUW9 1Ezd1E791FAd1VI91VS9ckltk1Wd1Vq91Vztc1f91WDtbfUQ1mRd1mGVqtqQ1tpgD2q91mzdEm7d 1nCd1izR1mvt1ith13WN12yt1n3t13/N13L913sN2H1d14jt14Jd2Iud2HKN15Cd14Y915A92Ict 2XQNE4a92IJN15z92Ctr1ELB12+d15f91qSN2KVN2o3tEpld2qod266d2KYN23Ot2pF92nEdE699 17Nd26hNE7tt23sd26md271N3HEd2azNo81t2r4d3Jpd288N3Lht3crN27S92i8x3NH/Td3cndrb /d20Hd3iDdfg/dvDbd3Nbd7ZLd3kTdxrCdiDvdvLzdq9Td+UjdyFjdmVjd+ZvdmbTd3Pbd+r/drh HdjlDduTTdmMfd223drQPeEFTuH6vabfneHVLd3vjd0KPtvnHeEL7uH1LeIMTt6t7dndHdzHPd25 vd/sjd7oXdnvTeMb7twMbuKy7d2/jd0SzuErbtzc3eHwDeHpreNATuHyvd5DvuEZHuRDPuEyztlk pxH1feHQ3eDM/diKDdqOHeBcjuAfvuWKPeNfruOWLeJ6Ddz//eI5rtefLeb9HeNhruag7ZM3GeIk HbcS3dV+/ueAPhYUEOiEXuiGfugb/2fWcYfoLqvocMfoCOvokj7padEOUAnp2kzpXZd0R4DpU9kC nh7qW63pXXcEpA7TMnDqOyfqrN7qrv7qH701q6DqtF7rtn7ruA5IvPyvUAXrFpesdHunNWuGM9un derrasqpPVoTjTq1I3u0ua4TglsYpSqt1/qoaguMshrs0T6oXiOpw3i17BePw1qGy97tKdk1Awuy Ulu27W6qvoruKTntfwGD797uIpuoh0rvms7vlluCMMuO1n6t2Vrw9s62k0rVV8CTYCvvYenwMOfv EE9WEj/xf0EEXIXsGt90VWDRXScKFh/y37bxJF/yJt/qZPcMjn7yLN/y/SbybyFaMP9/dwsL7Wt7 Nc3O60qb7nJKp/Lo7TmrqjcBuDqvskVftvDOr0XxoCHr7UM/E0cptt8Okmb1m0cPnDUf7/fK81xP sW2R8+ce9u7e9Qb9iwJfg2ybfyNLqt2a9j/vhtt5qcBep+Q+7u5O92bfsHAPsXIvqGyo9msI+AWf jqQ6s26f9xJL7IGftgYvtHW/+M/ejoN/n5Xi886O9VK7qp0Ysrk6tGxv89ce70Hv9+yu7Sy47YIf 7qwaocNq+qrP+hD6qQffpykLqkvLq7kq87bqo39fnzabgr/f9qVP+8q493Qb+lkPhjw7/Gh/+r1K 8MFv/KTZ+pj/+qTvqa8f/c+v/TL/i/vsHjXBmvlqqO/qGOzI//3F2qu1n6jOf/32rvqm//4VG/q2 //7tD4qub/uwj/31n/21DxD27AEQONCgQIIEDSpceLAhQnv/JE6kWNHiRYwZNW7cWNDjR5AhBwIg CdEkyYQLURZceVDhSoYsSzJ82RJlwpIPXc7MiXAmS58vPeKMOTLmTZk8c6Y06rAoxKNLbUrt6RKq U501qzblKlRlT5hATX4Me3Kq1pQ0gz6110HkW7hx5c6lW9fuXbx59e7lC5Jt3799BccNTLewyMNw Cyd2ONixYI6R/z2mXNnyXsZ2M1/O25Lv5rGatyYlnFPyadSpVa+myNn1a9ixZc+m/22X9W3cuXWr rt3b92/gwYPvJl5cd23QwvUmf838M+K7zh2Pfixd+XXDikNfLsrUeva6XiuDZixerN/onA+Xx4zd fW/ztL9rpu+a/NzAf5PPf7seNv/3KCOOqO4IlMkvmqhiqqGwfurKMwRPMsorm3byaSe0IpwwqajA kurCDUeysLEQlxLLxAepEhFEpFYkjaumTGxxRe+EMu5GHHPUaMGjxvIupAWxUotHq4Y8byizfMzK xauWVAs9I0OL8iGhouyxxyarlJBIK7MUkiygutvyS5XAJEhHNNO8kcgTw4QwRiSbpNLLKdlqEUUG wxzKQS6PhFNOLJ1ci0ytGhuywv8M+/TyK0XPC9KqPKEqKyiD1LQ0x+mwalPOOIOs80stAZWSLPHS 0nNMQUdN1dBT53S0SE6nXFTULnUi81UxYZX1yUcHEyNAvQbUtNVC9yz2zgb5xFBJEssycFlDZaR0 WEp5hXBGzwrlddkCVZSSTwUl5HbTF3PV0lpPf7p03eKADU+9d90FUt546bX3XnzlAhCwfLfrN85/ AxZ4YIILNvhghBNWeGGGG3b4YYGl2/e6iQF+r2KIsYsPutLyMyzBwXpFcFJ5N6t44/48zPbN+jjO GCTiuKPsSfTwA1mw+/wN0OSZdZ5XVZ/T608gdou2aDpEp8X23BqnlXQrMQ9lkVX/U1NM0Numhx4U RGOV5mlrGiv8lsqra3Laa6ifZbLZVxH7euofWcT4ZVxLJZRGOqE8MupTq+S76lX7DLTmu/fuW1Ri OR0x8VABZlNcV7ej2WNIJUVcZLpDTpzWSf3GE3HJCSVZ3EZLJ5tyIa91HFI2O1fcPNfvBBP0ytVm m9mfKXQQRqTmzvzWTwNt3HCama3VXwqBV77qjScnEei4FW399m1lhZ5au/Uz3M9Nf9yW1d/HExvt q6mutqrHX9xaW8LNsrtEabsiHF1Sj91y5cftjDbDGNN+f3OWvalbWNJd/pQWvp6BB4EuuxdzfLdA CHpEWAqMIIzwtZ8KwsZoG5RI/wY9+EGIGQCEIyRhCU34r9E8kIHByVl1YuOfE8bQPrNjD/ds9TMO PU+H/NJX0CxGmB1mSjvGehYBWSZDE5oLPz9k4uxC1z4hAjGITVyhzIb4xDIpDokHi9lZDrQ0JzLK ci6aUbPMFrazHUplZ0xXiNb2kzNuSG1ljN3blgY7JzJvhxzkYx/9eBrrZQ9ogkpe8eSHpELOb3lj JFfckoRIPX2KeKRbZNdKlKWt/FGTm8xNFB+VPdUxDkPpg2S11pfH5Y2udm6s3J8itaTVJS9wOyxd rrZYsAneUJDtE9z15pXI5wmvkshTkv401UvaoQqYqzJTq6gXEU5GU5qRqc7nLv/nv10e61rZOmD/ BnhML+qPfqUkHyzpCJbuuXF88PvcHG85sJi9E4VXBNY07XlPTMmzgdSxoXvw+U976lOgeNkAcLQx 0N8AVKELleYGNsBQiEZUohOlaEUtetGiIVSjGz0hRj36UZCG1KIcJWlJTXpSlKZUMF5QaUsddkSX ikSkM6XpP29SU4bGVKcvhOlO44JToAaVXSQR6kR9elSk+rOoS2VqU53awaRGVaq1eWpVrXrVS71A R1Plale9+lWwygurYyVrWc16VrSmVa1rZWtb3fpWycQBrnOla13tqlCt3jVNYeVrX/36V8DmJZ6B Jexj9FpYxA7msInVJzj6dVj/cETWsZJ1rD0qK5DKUtYjksUsZz+i2c4WhLOXtaxlI1ta0YrWs6Fl rWkve9rQUnaym3XtaUk72dfO9rOj1axsQbLa227WtqDtLGx969viqja3q3VtbXVLXOcqd7ekxexv lzvc0ULTrtR9rWlTS13aojYk4PVuasuL2sx2V7y7VW113Qtb73JXveINLnxt+1n8/na85rVvft0b 3tJyV7/vJbBIgltd8pr3v/MVMHsBLGC9NjjA6F1vfhNM3szyl8IUznCCJzxbAYN4wrTN8IJJ/OH1 ghfDA/7uhhVcYfpWWMIILvB+XwzjB+N3xg0+sIy1W9fm1pbA6VWxdMPr2RJv//i5Q0YvfFGs2xaL GLQdVnB9n3xk7Pb4xkvesXWNi+Te6ti+zP0vjMls4hMD2McpVm6GF0tjOJ+3zGZWM5HVm9sa3/fF JYYynKn8YAan+c9l7vONfYznOrO40DNG8ZwTbWBF69i/MmbufKvbVMtAuc+MLnKOD5xkJR95zwW+ M5MfHeMWu9jTNvYvqLvc6jXnONSQNrShexzoU6MaxwskzpSRTGIy89bJbWZzdr+r5wVXutX9Bbax 0VxcUI9YuFm29LRHbWQzg9nZ1jYxcpM7Z+huedhnDnOV2zxbTDNW3etmd7vd/W54x1ve86Z3vcMa zzHnG8PCdjW0p53vSH+72P/DDnJ7/S1cbE/32tDedHSFrPB/O1zgFNZrWltbanDDur8eZrOjNa3h VPMY4c8+b7RRzWxZx9nR5l65h9N76Yp79DF8TjOhNc5huFQ7xBm38pox/mlST7rRnS620Le8a5eD 3N7uoXmqwf1l4/qZ4Lr2+NHrS3Blq7rp5Ja0tFmOYOCOu+ssHnmNl36dKdcc6TFGtK2PDmu1i3js D//0r4keZ6yPOulWpzWrTX72u/S65klOene1TOevn7rf0W463m1ucoxX/fFvkXC1V07ymMt8MFfX t5ft/PgzU/rCED+4pQ3fbNNTXeCHT7G2szzecQPXy9LluL32AHjc5/49g9X/vXIyj9HeB9+DvIfY 741f8cwdX/l1xXXJiVtuQlN7ust1cMEdu3zs49QxzRf72zPudrhf3OzCJ3+UT57yhdtc6CKfde3L j3spK131zn01xNlP5Fq/v/fxPzjJ1Z9+/eIxu8s//cs9/rs1Nes4ALQw+VuyAmQsfEs8ndu220I5 YsO2npuw7NvAtUo+DvxAs/JAEBxBEixBE4SrB0zBhjlBFmzBrVJBsBoBjroReHBBGyxBGMxBLrpB HuxB1NBBIAxCITwqHyxCI8QIdTODIQShI2zCJlxCKBQrJ5xCKqxCK7xCLMzCtopCLuxCL/xCMPwr LRzDi2gGMjxD4zPDzAvDz8r4AwhqBjaMQ9iAw5NCQzJUwzWUw42iQz3sQ8rgQ5OywyzEw9/zQ0M8 RERMREXcQavqBkF8RN5YREmkC0isREu8RID6AkzcRE5cqkk8O3Kgl04cxdtYBM37RFQMCVJcRVZs RVecjFSMRVmcRVqsRbl4BVvMRV3cRV5UwVf8RWAMRjLsxUUURmM8RmRMRmVcxtQgRsALA7jogcpg Rmr8J2dMxGrMxmm6RkTURie8A7LixlnMA3GMQicUAW9MR3VcR3Y0xnKMKWV4mHacx0sJCAA7 ------=_NextPart_000_0009_01C6FC44.C8C4E380-- From avt-bounces@ietf.org Mon Oct 30 20:35:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiW8-00005I-63; Mon, 30 Oct 2006 20:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiV6-0007TZ-Tc for avt@ietf.org; Mon, 30 Oct 2006 20:33:14 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeiGD-0006fK-FQ for avt@ietf.org; Mon, 30 Oct 2006 20:17:51 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 30 Oct 2006 17:17:49 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9V1HmJE017926; Mon, 30 Oct 2006 17:17:48 -0800 Received: from dwingwxp ([10.32.130.99]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9V1HmAo022237; Mon, 30 Oct 2006 17:17:48 -0800 (PST) From: "Dan Wing" To: "'Randell Jesup'" , "'Colin Perkins'" Subject: RE: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Mon, 30 Oct 2006 17:17:48 -0800 Keywords: direct-to-dwing Message-ID: <57c201c6fc8a$60f4cc20$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Thread-Index: Acb8SB4hypMAG6FNQ96IaB2Dm10/KAAQidcA DKIM-Signature: a=rsa-sha1; q=dns; l=6923; t=1162257468; x=1163121468; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[AVT]=20[Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-02.tx t]; X=v=3Dcisco.com=3B=20h=3DE7772b17nmHZXaw28YrXruNb3bA=3D; b=Q9k/GwRi1pzmm4P0KMrfkvAVI9Z9ABxBWtOcmLhVYiR/35z11PnGQFyjd4aeBk6GoUnny2dN /6+O18HBJdHtsPJ3tnsggPqU54bM3DcRiLaDoV16I53bus5jqW7GUzG3; Authentication-Results: sj-dkim-2.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org I like the separate payload idea; it also fits nicely with port mapping being discussed on MMUSIC (see thread with subject "RE: [MMUSIC] RE: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt"). -d > -----Original Message----- > From: Randell Jesup [mailto:rjesup@wgate.com] > Sent: Monday, October 30, 2006 9:20 AM > To: Colin Perkins > Cc: avt@ietf.org; Dan Wing > Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] > > Colin Perkins writes: > >> Multiplex in Colin's draft requires a=rtcp support > currently (though I > >> have a few issues with that still (I think)). That means that to > >> exchange keys, the endpoints need to negotiate a viable > RTCP connection > >> (normal or multiplex). If multiplex, any network elements > in the media > >> stream need to pass the RTCP properly, AND need to not break a=rtcp > >> (which is one of my problems with it - some will break it > by ignoring > >> it). > > > >ICE also requires "a=rtcp:" support, so I expect it to be > widely deployed > >in the not-too-distant future. > > Uh... yeah. Depends on how you define "not-too-distant". > The kicker is > that all these existing network elements that will not work > with it (SBCs > mostly), and from experience many of them are often running > far-from-up-to-date software, or are written in-house, buggy, > etc. Lots of > them don't even *pass* RTCP, let along support a=rtcp. > > >And, being pragmatic, I prefer that RTCP is sometimes sent > on the RTP port > >without signalling, than always sending control messages in the RTP > >stream. Updating middlebox implementations to support > "a=rtcp:" is much > >easier than fixing a broken architecture that mixes control > plane and data > >plane. > > Um, how will it get sent on the RTP port? To the receiver, > it will look > like the sender wanted RTP on (mapped by SBC) port foo, and rtcp on > (ignored by SBC) port bar. And the receiver will happily > comply, and their > RTCP packets will go into the bit-bucket. Maybe the > implementations can > notice the problems or use a side-channel to suss out what > the SBC (didn't) > do, but I wouldn't bet encryption on it. > > You could mandate support for RTCP-on-RTP even if not > signalled, perhaps. > > >>> I don't see that being a problem. > >> > >> Why is that not a problem? If you have a more-typical 24K > (including > >> overhead) G.729 stream you only have 1200 bits for RTCP - > and from that > >> you have to subtract an RR or SR, a header, etc. And more > importantly, > >> without AVPF you need longer intervals between individual > RTCPs (though > >> perhaps some of those are SHOULD not MUST). There's > nothing about "but > >> at startup it's OK to ignore the rules", or "only applies > if media is > >> flowing" in RTCP. > > > >Sure, but again, a minor change to the RTCP timing rules to > allow ZRTP is > >much preferable to a major architectural change to allow > control messages > >within an RTP data stream. > > Isn't this the same sort of "minor timing change" that > required an entire > new set of N profiles (i.e. AVPF)? And this wouldn't fit in the AVPF > rules, so we'd have to have AVPZ... 1/2 :-) > > I admit, I like the idea of RTCP, but I don't see how we can > avoid badly > breaking the RTCP rules. If everyone is willing to break > them for this, > and it doesn't mean another horrible mess like AVPF/SAVPF has > turned into > (because of SDP and how profiles are negotiated), ok. > > >> Realize, I like the idea of using RTCP for the key > exchange here. But > >> there are issues to address, including issues of network > element support > >> for AVPF (which looks like it would be required). > >> > >> There are other options: > >> *Use a separate media (m=data) stream for key exchanges. > There are some > >> obvious issues since it's now separate from the media > ports, and some > >> elements might not like another port (pair) being allocated. > > > >Reasonable, but would need signalling support and extra ports. > > This probably could be done. Yes, it requires another port-pair. (In > theory I don't think there's anything *mandating* that a set of media > streams use different ports - but people want to use that as > a way to try > to do profile negotiation.) > > >> *Use the same media stream, but with the initial payload > being ZRTP data. > >> (a=rtpmap:99 ZRTP). Exchange data as payload type 99, then start > >> sending encrypted data using one of the other payload > types. This is > >> also an intriguing option, and doesn't need extra ports > or a=rtcp or > >> AVPF support. > > > >It's architecturally pretty ugly: a media stream shouldn't > contain control > >data. I would much prefer RTCP, whether signalled or not, or another > >protocol that is multiplexed on the same port (as done with STUN). > > Well, I think this is architecturally much better than the header > extension/NOOP idea, avoids the RTCP BW limit issues, doesn't > conflict with > hdrext, avoids SSRC issues, etc. It provides a negotiated > (you can reject > it) media-path control-plane for this specific purpose with > no bandwidth > limitations and less overhead than RTCP (no RR/SR). The > major downside > architecturally is that the data in the packets is not per-se audio or > video (or whatever m=data type), but what the packets contain is being > signalled. It doesn't interfere with existing applications, should be > totally transparent to all but the worst-written network elements, and > doesn't interfere with normal traffic/packet-sizes/RTCP > calculations/etc. > > Multiplexing another protocol in the same port as RTP is an option, of > course, though probably more network elements would block it > than would > the payload idea. I would probably consider that as the strongest > alternative to the payload idea above, and put both above the current > header-extension/NOOP plan. I prefer the payload plan > because it avoids > some issues with the application having to intuit the type of incoming > packets, and in general it just seems odd to me. I know why > it was needed > for ICE/STUN, from a technical point of view, but that's not > needed here. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), > ex-Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged > out of the weapons > provided for defence against real, pretended, or imaginary > dangers from abroad." > - James Madison, 4th US president (1751-1836) > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From ceacagbfdcg@carnbring.com Tue Oct 31 05:12:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geqc4-0000Ti-D0; Tue, 31 Oct 2006 05:12:56 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geqc4-00085U-Am; Tue, 31 Oct 2006 05:12:56 -0500 Received: from [195.26.238.4] (helo=no-reverse.interalpha.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Geqc2-0001hk-IZ; Tue, 31 Oct 2006 05:12:55 -0500 From: "Jeffry Raines" To: Subject: urgently to you 112.5% increase all-important Date: Tue, 31 Nov 2006 10:12:46 -0330 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 door, and thin, white marble trimmings outlining the front door andthat he owned a gold mine and waked to wish that he did. He was likewiseintensely. When his father explained to him how it was mined, he dreamedthe lots were almost always one hundred feet deep, and the house-fronts,banking-houses, he had come to be familiar with and favorably known inHe was a financier by instinct, and all the knowledge that pertained topavement was of big, round cobblestones, made bright and clean by the Please read this letter attentively. Tailor AquaPonics is going to rise! It will rise up to 70% Company: TAILOR AQUAPONICS Stock symbol: TQWW.PK Current price: 0.07$ Expected price: 0.26$ Check this inside news. It will be published on MARKETWIRE on the 1st of November 2006 Recent news: TQWW.PK is going to conquer the US market. They’re coming to America!!! Tailor AquaPonics recently announced plans to expand its operational facilities to the United States. The Nevada-based company with operations in Australia recently decided to translate its track record of success to the American market. Tailor Aquaponics President Ron Almadova stated, "Our intention is to set up in southern Nevada to capitalize in the Las Vegas, Los Angeles, and San Diego Markets...There are more people in that triangle than in the whole Australian country. Now that we have the board approval, we have pinpointed several possible locations that would serve our delivery profile." After the publishig of that review TQWW.PK will grow constantly for 3-4 weeks. Buy it now cause it is still cheap and you can enter almost for free. About Tailor AquaPonics Worldwide: Tailor AquaPonics Worldwide, Inc. owns a controlling interest in the international growth and development rights to Tailor Made Fish Farms, a company that has developed a technology-driven, easy to operate, land-based modular fish production system. This cutting-edge system is both sustainable and environmentally responsible in keeping with the spirit of maintaining an environmentally safe and friendly solution while producing high volumes of superior and healthier farmed fish. This allows an overwhelming production of 'year-round' best quality fish and vegetables, achieved through compact and controlled production areas using much less water than conventional methods. Our technique conserves water, is environmentally responsible, fresh health products and provides two crops from a single water uptake. P.S Rumor has it that 2 Million shares have already been sold that are NOT accounted for in DTC, if your familar with this term it is called a "SHORT SQUEEZE". We will be mailing TQWW.PK for the next 3 weeks and the price will icrease. It is your unique chance to double or triple your funds next week. were ready to move into the New Market Street home. Henry Worthington From avt-bounces@ietf.org Tue Oct 31 05:15:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geqcv-000111-7C; Tue, 31 Oct 2006 05:13:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geqct-00010B-CO for avt@ietf.org; Tue, 31 Oct 2006 05:13:47 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geqcn-00089a-TU for avt@ietf.org; Tue, 31 Oct 2006 05:13:47 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 53BE05E9; Tue, 31 Oct 2006 11:13:41 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 11:13:40 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 11:13:40 +0100 Message-ID: <454721D4.3030408@ericsson.com> Date: Tue, 31 Oct 2006 11:13:40 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Randell Jesup Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 10:13:40.0713 (UTC) FILETIME=[3CEE6D90:01C6FCD5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Colin Perkins , Dan Wing , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Hi, Generally I am agreeing with Colin here. Putting ZRTP handshake into RTCP is a clean solution. When it comes to broken boxes, like SBC I think it is fine to consider them but we shouldn't change everything simply to accommodate them. They are after all broken if they aren't supporting RTCP. Too broken boxes will need to be upgraded. In regards to the bandwidth. Independent on if the handshake happens in RTP or RTCP there needs to be some checks on the bit-rate. We can't ignore congestion control when being deployed on a best effort network. Thus ZRTP should take care not to require completion within a specific time. Because the transfer of particular amount of data may take some time. So thinking that RTP will be better than RTCP in this regard may very well be an illusion. Also I think people are very looked into the 5% BW rule instead of considering what RR and RS bandwidth modifier combined with AVPF actually can accomplish. For example RTCP can be configured to have low average BW and still allow substantially higher rates when needed. Also I wonder how well ZRTP handles the mixer translator cases. I am sorry to say that I haven't read the latest ZRTP version. However I will try to do it before the meeting. Have the authors consider the example of topologies that can be existing as described in http://tools.ietf.org/wg/avt/draft-ietf-avt-topologies/draft-ietf-avt-topologies-02.txt Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 07:14:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesUb-0005oN-Qa; Tue, 31 Oct 2006 07:13:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesUb-0005oI-AU for avt@ietf.org; Tue, 31 Oct 2006 07:13:21 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GesUR-0000Bk-AL for avt@ietf.org; Tue, 31 Oct 2006 07:13:21 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 07:13:11 -0500 To: Magnus Westerlund Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <454721D4.3030408@ericsson.com> From: Randell Jesup Date: Tue, 31 Oct 2006 07:13:09 -0500 In-Reply-To: <454721D4.3030408@ericsson.com> (Magnus Westerlund's message of "Tue, 31 Oct 2006 11:13:40 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 31 Oct 2006 12:13:11.0129 (UTC) FILETIME=[EED51490:01C6FCE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Colin Perkins , Dan Wing , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus Westerlund writes: >Generally I am agreeing with Colin here. Putting ZRTP handshake into RTCP >is a clean solution. When it comes to broken boxes, like SBC I think it is >fine to consider them but we shouldn't change everything simply to >accommodate them. They are after all broken if they aren't supporting >RTCP. Too broken boxes will need to be upgraded. Sure, but it won't happen overnight. >In regards to the bandwidth. Independent on if the handshake happens in RTP >or RTCP there needs to be some checks on the bit-rate. We can't ignore >congestion control when being deployed on a best effort network. Thus ZRTP >should take care not to require completion within a specific time. Because >the transfer of particular amount of data may take some time. Sure. Also (and I know they know this) handling packet loss. >So thinking that RTP will be better than RTCP in this regard may very well >be an illusion. Also I think people are very looked into the 5% BW rule >instead of considering what RR and RS bandwidth modifier combined with >AVPF actually can accomplish. For example RTCP can be configured to have >low average BW and still allow substantially higher rates when needed. If you configure it for high RR/RS, then normal RTCP for the rest of the call can use a lot, and more importantly QoS network elements have to reserve that bandwidth for the entire call, whether or not it's used. This is a huge restriction on RTCP for many usages. The effect would be that it could take several seconds (ignoring packet loss) to exchange keys. In some cases perhaps 10 seconds. Admittedly, these are large key exchanges, but even if trimmed somehow I think it's still way too long (not just a little too long). >Also I wonder how well ZRTP handles the mixer translator cases. I am sorry >to say that I haven't read the latest ZRTP version. However I will try to >do it before the meeting. Have the authors consider the example of >topologies that can be existing as described in >http://tools.ietf.org/wg/avt/draft-ietf-avt-topologies/draft-ietf-avt-topologies-02.txt I haven't either, but I suspect a payload-type-based solution will handle mixers (and other cases being considered) as well as RTCP. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 07:22:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GescX-0002Cx-5R; Tue, 31 Oct 2006 07:21:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GescV-0002Cr-RG for avt@ietf.org; Tue, 31 Oct 2006 07:21:31 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GescP-0001Xa-CS for avt@ietf.org; Tue, 31 Oct 2006 07:21:31 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E52B71109; Tue, 31 Oct 2006 13:20:52 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 13:20:52 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 13:20:52 +0100 Message-ID: <45473FA3.1080105@ericsson.com> Date: Tue, 31 Oct 2006 13:20:52 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Randell Jesup Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <454721D4.3030408@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 12:20:52.0379 (UTC) FILETIME=[01C23EB0:01C6FCE7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Colin Perkins , Dan Wing , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Randell Jesup skrev: > >> So thinking that RTP will be better than RTCP in this regard may very well >> be an illusion. Also I think people are very looked into the 5% BW rule >> instead of considering what RR and RS bandwidth modifier combined with >> AVPF actually can accomplish. For example RTCP can be configured to have >> low average BW and still allow substantially higher rates when needed. > > If you configure it for high RR/RS, then normal RTCP for the rest of the > call can use a lot, and more importantly QoS network elements have to > reserve that bandwidth for the entire call, whether or not it's used. > This is a huge restriction on RTCP for many usages. The effect would be > that it could take several seconds (ignoring packet loss) to exchange > keys. In some cases perhaps 10 seconds. Admittedly, these are large > key exchanges, but even if trimmed somehow I think it's still way too long > (not just a little too long). > No, not if you use AVPF, then you can use a small bandwidth for regular reports and more for RTCP that contains events, such as ZRTP key-exchanges. From my perspective one could also investigate how to overtax the RTCP bandwidth at startup. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 09:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuSH-0001O4-2r; Tue, 31 Oct 2006 09:19:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuSE-0001IO-M7 for avt@ietf.org; Tue, 31 Oct 2006 09:19:03 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeuS9-0004mX-4L for avt@ietf.org; Tue, 31 Oct 2006 09:19:02 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 09:18:57 -0500 To: Magnus Westerlund Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <454721D4.3030408@ericsson.com> <45473FA3.1080105@ericsson.com> From: Randell Jesup Date: Tue, 31 Oct 2006 09:18:55 -0500 In-Reply-To: <45473FA3.1080105@ericsson.com> (Magnus Westerlund's message of "Tue, 31 Oct 2006 13:20:52 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 31 Oct 2006 14:18:57.0037 (UTC) FILETIME=[808B43D0:01C6FCF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Colin Perkins , Dan Wing , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus Westerlund writes: >Randell Jesup skrev: >>> So thinking that RTP will be better than RTCP in this regard may very well >>> be an illusion. Also I think people are very looked into the 5% BW rule >>> instead of considering what RR and RS bandwidth modifier combined with >>> AVPF actually can accomplish. For example RTCP can be configured to have >>> low average BW and still allow substantially higher rates when needed. >> If you configure it for high RR/RS, then normal RTCP for the rest of the >> call can use a lot, and more importantly QoS network elements have to >> reserve that bandwidth for the entire call, whether or not it's used. >> This is a huge restriction on RTCP for many usages. The effect would be >> that it could take several seconds (ignoring packet loss) to exchange >> keys. In some cases perhaps 10 seconds. Admittedly, these are large >> key exchanges, but even if trimmed somehow I think it's still way too long >> (not just a little too long). > >No, not if you use AVPF, then you can use a small bandwidth for regular >reports and more for RTCP that contains events, such as ZRTP >key-exchanges. From my perspective one could also investigate how to >overtax the RTCP bandwidth at startup. AVPF lets you send more often or immediately, but it does not change the amount of bandwidth available for RTCP in total. You're still limited to 5% of RTP (or the value overriding that). You cannot "target" bandwidth in AVPF for a specific purpose. You can use any otherwise-unused RTCP bandwidth, but that's limited by the maximums we've been discussion, and overriding the default 5% means that the larger RTCP bandwidth will need to be reserved for the entire session. (And reinvite after key-exchange isn't an answer). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 10:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevE6-0000BI-AN; Tue, 31 Oct 2006 10:08:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevE4-0000B4-Ju for avt@ietf.org; Tue, 31 Oct 2006 10:08:28 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GevDt-0003wK-5I for avt@ietf.org; Tue, 31 Oct 2006 10:08:28 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 399481096; Tue, 31 Oct 2006 16:08:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 16:08:13 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 16:08:13 +0100 Message-ID: <454766DF.3050908@ericsson.com> Date: Tue, 31 Oct 2006 16:08:15 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Randell Jesup Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <454721D4.3030408@ericsson.com> <45473FA3.1080105@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 15:08:13.0854 (UTC) FILETIME=[62F1BBE0:01C6FCFE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Colin Perkins , Dan Wing , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Randell Jesup skrev: > Magnus Westerlund writes: >> Randell Jesup skrev: >>>> So thinking that RTP will be better than RTCP in this regard may very well >>>> be an illusion. Also I think people are very looked into the 5% BW rule >>>> instead of considering what RR and RS bandwidth modifier combined with >>>> AVPF actually can accomplish. For example RTCP can be configured to have >>>> low average BW and still allow substantially higher rates when needed. >>> If you configure it for high RR/RS, then normal RTCP for the rest of the >>> call can use a lot, and more importantly QoS network elements have to >>> reserve that bandwidth for the entire call, whether or not it's used. >>> This is a huge restriction on RTCP for many usages. The effect would be >>> that it could take several seconds (ignoring packet loss) to exchange >>> keys. In some cases perhaps 10 seconds. Admittedly, these are large >>> key exchanges, but even if trimmed somehow I think it's still way too long >>> (not just a little too long). >> No, not if you use AVPF, then you can use a small bandwidth for regular >> reports and more for RTCP that contains events, such as ZRTP >> key-exchanges. From my perspective one could also investigate how to >> overtax the RTCP bandwidth at startup. > > AVPF lets you send more often or immediately, but it does not change the > amount of bandwidth available for RTCP in total. You're still limited to > 5% of RTP (or the value overriding that). You cannot "target" bandwidth in > AVPF for a specific purpose. You can use any otherwise-unused RTCP > bandwidth, but that's limited by the maximums we've been discussion, and > overriding the default 5% means that the larger RTCP bandwidth will need to > be reserved for the entire session. (And reinvite after key-exchange isn't > an answer). > There is a minimal RTCP interval parameter for AVPF. That allows you to restrict the frequency with which regular packets are sent. Thus creating a difference between sending Event packets and Regular packets. Events are sent using the full bit-rate available, while regulars are dialed back. Thus your BW usage can very between what is needed to send with minimal interval up to full RR+RS bandwidth or even beyond it if you use immediate and have miscalculated your event rate. cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From aneorrmba@amberlux.com Tue Oct 31 11:39:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewdg-0006iX-Lz for avt-archive@lists.ietf.org; Tue, 31 Oct 2006 11:39:00 -0500 Received: from 91-145-130-52-net.cnb.com.pl ([91.145.130.52] helo=home-4pc0x3db94) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewdU-0002Qg-6i for avt-archive@lists.ietf.org; Tue, 31 Oct 2006 11:39:00 -0500 Received: from 64.41.126.101 (HELO mail.amberlux.com) by lists.ietf.org with esmtp (30GP90G75HM 601LWS) id FV0OVI-PJW629-YI for avt-archive@lists.ietf.org; Tue, 31 Oct 2006 16:38:48 -0060 From: "Tara Langston" To: Subject: Please confirm your signup Date: Tue, 31 Oct 2006 16:38:48 -0060 Message-ID: <01c6fd0b$0a5de0f0$6c822ecf@aneorrmba> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Thread-Index: Aca6QYC8SBZUC8VYBW1Y5320RKV5YD== X-Spam-Score: 4.4 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 The Good PR blitz has start! A-U-N-I is up 33% in the last week leading up to todays information. NEW YORK--(MARKET WIRE)--Oct 30, 2006 Mr. Christian Lillieroos, AUNI's newly-appointed President and CEO, who addressed the audience and announced the new vision statement of the group: American Unity Investments - a business portal that unites the capital flow between the US and China. "In the future, AUNI will focus more of its attention on creating capital opportunities for US investors in the China market and giving Chinese companies opportunities to get access to the US capital market," The Chinese dragon is wide awake and the region is awash in opportunities. With AUNI strong management team and proven track record we expect some very positive news reports throughout this week to push the share price through the roof! Sym: AUNI Price: O.85 Projected: 2.3O Rating: 5/5 This is the break you've been waiting for! Spice up your holdings with A-U-N-I ! Buy on 31 Oct. ----- (FORTUNE Magazine) -- Pity Rupert Murdoch. The News Corp. chairman and CEO has been caught between two Manhattan residences - his old SoHo loft, which he sold to fashion designer Elie Tahari for $25 million, and his new Fifth Avenue apartment, which he bought for $44 million in 2004 and is still renovating. CHARLESTON, West Virginia (AP) -- Leaning on two canes, Sen. Robert C. Byrd hardly looks like a billion-dollar industry -- or "Big Daddy," as the 88-year-old Democrat calls himself. COLUMBUS, Indiana (AP) -- An inmate accused of forcibly tattooing a slain 10-year-old girl's name onto her killer's forehead in an Indiana prison was the victim's cousin, a family friend said. NEW YORK (CNNMoney.com) -- Internet stocks, by and large, have not been good investments this year. Amazon, eBay and Yahoo rank among the worst performing stocks in the S&P 500. From avt-bounces@ietf.org Tue Oct 31 12:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewzf-0005eT-RX; Tue, 31 Oct 2006 12:01:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewzd-0005bQ-RF for avt@ietf.org; Tue, 31 Oct 2006 12:01:42 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewzX-0006WQ-IS for avt@ietf.org; Tue, 31 Oct 2006 12:01:41 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 12:01:35 -0500 To: Magnus Westerlund Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <454721D4.3030408@ericsson.com> <45473FA3.1080105@ericsson.com> <454766DF.3050908@ericsson.com> From: Randell Jesup Date: Tue, 31 Oct 2006 12:01:33 -0500 In-Reply-To: <454766DF.3050908@ericsson.com> (Magnus Westerlund's message of "Tue, 31 Oct 2006 16:08:15 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 31 Oct 2006 17:01:35.0137 (UTC) FILETIME=[38D32910:01C6FD0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Colin Perkins , Dan Wing , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus Westerlund writes: >There is a minimal RTCP interval parameter for AVPF. That allows you to >restrict the frequency with which regular packets are sent. Thus creating a >difference between sending Event packets and Regular packets. Events are >sent using the full bit-rate available, while regulars are dialed >back. Thus your BW usage can very between what is needed to send with >minimal interval up to full RR+RS bandwidth or even beyond it if you use >immediate and have miscalculated your event rate. The "full bit-rate available" is the RTCP bitrate (RR+RS if they're specified as you mention, or 5% if they're not), not the RTP bitrate. Which is my point; you either take a "long time" to exchange the keys (due to the 5% restriction), or you bump RR+RS a lot to allow high usage by RTCP, but then any QoS link will reserve that bandwidth *in addition to* the normal (AS) bandwidth, and keep that reservation in place for the session. Or fail the call because of too much bandwidth requested. Or ignore RR+RS and limit you to 5% (just because RFC 3556 exists doesn't mean everyone implements it). Etc. So if a D-H exchange requires circa >10K bits in 4 (or more) messages, under the 5% rule even with an 80Kbps (G.711) channel you're talking a minimum of 2.5 seconds and probably more. If it's a 24Kbps channel (G.729) it's more like 8 seconds and probably more. If you use RR+RS to bump RTCP up to 100%, then it's <1/2 second, but you've doubled the bandwidth reservation requirements (and it could have a big effect on future non-key-exchange RTCP traffic, since those values feed into the algorithms). http://www.isi.edu/in-notes/rfc4586.txt 4. RTCP Bit Rate Measurements The new timing rules allow more frequent RTCP feedback for small multicast groups. In large groups, the algorithm behaves similarly to the normal RTCP timing rules. While it is generally good to have more frequent feedback, it cannot be allowed at all to increase the bit rate used for RTCP above a fixed limit, i.e., 5% of the total RTP bandwidth according to RTP. This section shows that the new timing rules keep RTCP bandwidth usage under the 5% limit for all investigated scenarios, topologies, and group sizes. Furthermore, we show that mixed groups (some members using AVP, some AVPF) can be allowed and that each session member behaves fairly according to its corresponding specification. Note that other values for the RTCP bandwidth limit may be specified using the RTCP bandwidth modifiers as in [10]. and http://www.faqs.org/rfcs/rfc3556.html o The total RTCP bandwidth is 5% of the session bandwidth. If one of these RTCP bandwidth specifiers is omitted, its value is 5% minus the value of the other one, but not less than zero. If both are omitted, the sender and receiver RTCP bandwidths are 1.25% and 3.75% of the session bandwidth, respectively. (if both are specified, the total for RTCP can be higher than 5%) -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From dgdcgeeaggdabe@caribbeancable.com Tue Oct 31 13:11:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gey59-0003lQ-59; Tue, 31 Oct 2006 13:11:27 -0500 Received: from 200-100-244-50.dial-up.telesp.net.br ([200.100.244.50] helo=tavinho-atjwhhg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gey53-0004rq-6Z; Tue, 31 Oct 2006 13:11:27 -0500 From: "Maude Hurst" To: Subject: Go TQWW.PK and double or triple your investments next week Date: Tue, 31 Nov 2006 18:11:26 +0180 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 Importance: Normal X-Spam-Score: 4.8 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 brokers knew him as representing a very sound organization, and while hevalues were calculated according to one primary value, that of gold.values were calculated according to one primary value, that of gold.watch with great interest the deft exchange of bills at the brokeragebrokers knew him as representing a very sound organization, and while heof life are to a poet. This medium of exchange, gold, interested him Please read this letter attentively. Tailor AquaPonics is going to rise! It will rise up to 70% Company: TAILOR AQUAPONICS Stock symbol: TQWW.PK Current price: 0.07$ Expected price: 0.26$ Check this inside news. It will be published on MARKETWIRE on the 1st of November 2006 Recent news: TQWW.PK is going to conquer the US market. TAILOR AQUAPONICS coming to America!!! Tailor AquaPonics recently announced plans to expand its operational facilities to the United States. The Nevada-based corporation with operations in Australia recently decided to translate its track record of success to the American market. Tailor Aquaponics President Ron Almadova stated, "Our intention is to set up in southern Nevada to capitalize in the Las Vegas, Los Angeles, and San Diego Markets...There are more persons in that triangle than in the whole Australian country. Now that we have the board approval, we have pinpointed several possible locations that would serve our delivery profile." After the publishig of that review TQWW.PK will grow constantly for 3-4 weeks. Buy it now cause it is still cheap and you can enter almost for free. About Tailor AquaPonics Worldwide: Tailor AquaPonics Worldwide, Inc. owns a controlling interest in the international growth and development rights to Tailor Made Fish Farms, a company that has developed a technology-driven, easy to operate, land-based modular fish production system. This cutting-edge system is both sustainable and environmentally responsible in keeping with the spirit of maintaining an environmentally safe and friendly solution while producing high volumes of superior and healthier farmed fish. This allows an overwhelming production of 'year-round' premium quality fish and vegetables, achieved through compact and controlled production areas using much less water than conventional methods. Our technique conserves water, is environmentally responsible, fresh health products and provides two crops from a single water uptake. P.S Rumor has it that 2 Million shares have already been sold that are NOT accounted for in DTC, if your familar with this term it is called a "SHORT SQUEEZE". We will be mailing TQWW.PK for the next 3 weeks and the price will rise. It is your unique chance to double or triple your investments next week. and trustworthy individual.In this progress of his father young Cowperwood definitely shared. Hethat he owned a gold mine and waked to wish that he did. He was likewise From avt-bounces@ietf.org Tue Oct 31 13:12:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gey4i-0003Uv-HS; Tue, 31 Oct 2006 13:11:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gey4h-0003UU-2x for avt@ietf.org; Tue, 31 Oct 2006 13:10:59 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gey4d-0004qb-JV for avt@ietf.org; Tue, 31 Oct 2006 13:10:59 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:53872) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Gey4d-0003Y1-05; Tue, 31 Oct 2006 18:10:55 +0000 In-Reply-To: References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Tue, 31 Oct 2006 18:10:51 +0000 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 30 Oct 2006, at 17:19, Randell Jesup wrote: > Colin Perkins writes: >>> Multiplex in Colin's draft requires a=rtcp support currently >>> (though I >>> have a few issues with that still (I think)). That means that to >>> exchange keys, the endpoints need to negotiate a viable RTCP >>> connection >>> (normal or multiplex). If multiplex, any network elements in the >>> media >>> stream need to pass the RTCP properly, AND need to not break a=rtcp >>> (which is one of my problems with it - some will break it by >>> ignoring >>> it). >> >> ICE also requires "a=rtcp:" support, so I expect it to be widely >> deployed >> in the not-too-distant future. > > Uh... yeah. Depends on how you define "not-too-distant". The > kicker is > that all these existing network elements that will not work with it > (SBCs > mostly), and from experience many of them are often running > far-from-up-to-date software, or are written in-house, buggy, etc. > Lots of > them don't even *pass* RTCP, let along support a=rtcp. > >> And, being pragmatic, I prefer that RTCP is sometimes sent on the >> RTP port >> without signalling, than always sending control messages in the RTP >> stream. Updating middlebox implementations to support "a=rtcp:" >> is much >> easier than fixing a broken architecture that mixes control plane >> and data >> plane. > > Um, how will it get sent on the RTP port? To the receiver, it will > look > like the sender wanted RTP on (mapped by SBC) port foo, and rtcp on > (ignored by SBC) port bar. And the receiver will happily comply, > and their > RTCP packets will go into the bit-bucket. Maybe the > implementations can > notice the problems or use a side-channel to suss out what the SBC > (didn't) > do, but I wouldn't bet encryption on it. > > You could mandate support for RTCP-on-RTP even if not signalled, > perhaps. You could certainly mandate that ZRTP messages are sent as RTCP on the RTP port, irrespective of the signalling, until the middleboxes are fixed. It's not ideal, but it doesn't break the architecture, and those middleboxes will eventually be fixed to support "a=rtcp:". >>>> I don't see that being a problem. >>> >>> Why is that not a problem? If you have a more-typical 24K >>> (including >>> overhead) G.729 stream you only have 1200 bits for RTCP - and >>> from that >>> you have to subtract an RR or SR, a header, etc. And more >>> importantly, >>> without AVPF you need longer intervals between individual RTCPs >>> (though >>> perhaps some of those are SHOULD not MUST). There's nothing >>> about "but >>> at startup it's OK to ignore the rules", or "only applies if >>> media is >>> flowing" in RTCP. >> >> Sure, but again, a minor change to the RTCP timing rules to allow >> ZRTP is >> much preferable to a major architectural change to allow control >> messages >> within an RTP data stream. > > Isn't this the same sort of "minor timing change" that required an > entire > new set of N profiles (i.e. AVPF)? And this wouldn't fit in the AVPF > rules, so we'd have to have AVPZ... 1/2 :-) > > I admit, I like the idea of RTCP, but I don't see how we can avoid > badly > breaking the RTCP rules. If everyone is willing to break them for > this, > and it doesn't mean another horrible mess like AVPF/SAVPF has > turned into > (because of SDP and how profiles are negotiated), ok. I'd prefer ZRTP to use RTCP packets ignoring the timing rules for the initial negotiation, than for it to embed control information into RTP media packets. Neither is ideal, but this seems the least bad alternative architecturally, given that the community seems to have decided to punt the keying problem onto this group, rather than fixing the SIP layer. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 13:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyhW-0007i8-Cr; Tue, 31 Oct 2006 13:51:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyhT-0007b1-K1 for avt@ietf.org; Tue, 31 Oct 2006 13:51:03 -0500 Received: from smtp02.lnh.mail.rcn.net ([207.172.157.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyhF-0000fj-F4 for avt@ietf.org; Tue, 31 Oct 2006 13:51:03 -0500 Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 31 Oct 2006 13:50:48 -0500 X-IronPort-AV: i="4.09,375,1157342400"; d="scan'208"; a="336947952:sNHT195694396" Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id HLQ69602; Tue, 31 Oct 2006 13:50:29 -0500 (EST) Received: from 162-144-2.cortland.com.144.162.209.in-addr.arpa (HELO erols.com) ([209.162.144.2]) by smtp01.lnh.mail.rcn.net with ESMTP; 31 Oct 2006 13:50:19 -0500 X-IronPort-AV: i="4.09,375,1157342400"; d="scan'208"; a="303859524:sNHT2868123702" Message-ID: <45479ADD.1B8B4E1F@erols.com> Date: Tue, 31 Oct 2006 10:50:05 -0800 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randell Jesup Subject: 802.1as sync [was: Re: [AVT] Layer 2 synchronization and clock] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/50, host=mr08.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090205.45479AB4.0035,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.113/2006-07-26 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Michael Johas Teener , IETF AV Transport WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Mike, all, After chewing on this awhile I would caution 802.1 not to grasp at the IEEE1588 hammer -- this is not a nail. 1588 puts a lot of effort into measuring the link delays. Stop and think about it: in the home AV environment is the wireline or airwave propagation delay the issue? No! Let's look at some historical models from professional AV studio production. In analog sound production, wireline delay is just not a concern. At a concert, the microphone signal may go a few hundred feet from the stage to the mixing console, then a few hundred feet back to the performer's monitor. No sweat. In a digital sound studio there is likely to be a master word clock generator distributing a 48 or 96kHz clock. Nobody is counting out the number of feet of clock cable. In analog video production you see a different story. In the past, technicians would cut cable lengths to within a foot. Why? They wanted to maintain phase match of a 3.58MHz color subcarrier within 1 degree - about a nanosecond. Incidentally, that style of signal engineering has become obsolescent; certainly 802.1 should not be trying to emulate it in a home environment. It would also be worthwhile for 802.1 to get a technical presentation on the currently-deployed layer-2-based audio distribution systems, specifically Cobranet and Gibson Magic. They work, and we can learn from them. I suggest that a small-network AV environment can work under the model that layer-1 link delays are zero. Say a packet leaves link endpoint A at time T(A) on device A's timebase, and arrives at the other endpoint, B, at time T(B) on device B's timebase. We can just assume that T(A) is simultaneous with T(B). The only penalty is a *fixed* offset between device clocks on the order of a microsecond. This offset only changes when the physical network cables are rerouted, and will be imperceptible. As we look for a "better NTP" for LAN environments, the limits on performance will mostly come from (a) drift rate (and change of rate) of the local clocks, and (b) uncertainty in local timestamping relative to the "on-the-wire" signal. We should evaluate whether layer-2 timestamping is an adequate proxy for layer-1 timing. The subtle point is that, if the average delay between PHY and MAC (e.g. in FIFOs) depends on traffic, you can get systematic clock-phase pulling based on network load. If this dynamic phase wander gets up into the multi-microsecond range it's a concern. Suppressing audible phase wander by putting a slow time constant on the clock corrections is dangerous; it can severely impact start-up time. I gather that "the train has left the station" in the sense that 802.1as's officially-approved task is to incorporate IEEE1588 mechanisms into home-network AV. There are worthwhile things to take from 1588, but the link-delay-measurement scheme is not one of them. Considerable equipment simplification would arise from eliminating it. And to point out the obvious: if you want to characterize the multi-hop transport latency, it's a piece of cake to layer that on top of a precise distributed time service. You could say that 1588 is doing it upside down: building the time service on top of a delay-characterized network. Looks more complicated to me! Peace, Chuck Randell Jesup wrote: > > Michael Johas Teener writes: > >All that is being done is to move some timing and QoS services closer to the > >network layer so that they can be easily built into the hardware for > >Ethernet/WiFi NICs and switches. The result is lower latency and (probably) > >lower cost. > > Ok, if this is a replacement for NTP that's fine, though requiring anything > of network elements needs a really good reason, and it'd better be cheap, > easy to do and not get wrong, and give some sort of benefit outside the > very limited space mentioned here if you want hardware vendors to implement > it in enough equipment for this to be really useful to you. Targeting > a "better NTP" might be a good start. I would suggest trying very hard to > make your idea work without special support in hubs/switches/routers if at > all possible. If it must be there, KISS. :-) > > What bothers me the most is the "insert time in the network stack" part. > a) latency from sample to stack is rarely fixed except in the most > special-purpose hardware. b) the more I hear the more I think you want to > get the true sampling time for a set of samples. This is really a hardware > and system issue; it's not a network or protocol issue. IMHO _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 14:05:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geyv4-0000DU-7V; Tue, 31 Oct 2006 14:05:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geyv2-0000DF-1x for avt@ietf.org; Tue, 31 Oct 2006 14:05:04 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geyuz-0004K4-Fl for avt@ietf.org; Tue, 31 Oct 2006 14:05:03 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-3.cisco.com with ESMTP; 31 Oct 2006 11:05:01 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VJ5075022484; Tue, 31 Oct 2006 11:05:00 -0800 Received: from dwingwxp (dhcp-171-69-133-63.cisco.com [171.69.133.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9VJ50OV009548; Tue, 31 Oct 2006 11:05:00 -0800 (PST) From: "Dan Wing" To: "'Magnus Westerlund'" Subject: ZRTP and mixer translators [was Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]] Date: Tue, 31 Oct 2006 11:05:00 -0800 Keywords: direct-to-dwing Message-ID: <05e301c6fd1f$771e3640$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb81UCt3oqf/6uJQ0SRJ0fX8HDqDQASIDyg In-Reply-To: <454721D4.3030408@ericsson.com> DKIM-Signature: a=rsa-sha1; q=dns; l=1046; t=1162321501; x=1163185501; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:ZRTP=20and=20mixer=20translators=20[was=20Re=3A=20[AVT]=20[Fwd=3A=20I-D= 20ACTION=3Adraft-zimmermann-avt-zrtp-02.txt]]; X=v=3Dcisco.com=3B=20h=3DscL/eNj1O/08htrrySufL50KIpo=3D; b=jUnJo1iqAh6Ec5xAK/PD/wo1LgIjOsTAD8Fb8lP7lUpR57iGKeAdc390iEjQe9zx9To6auKc fG5oOIdgBNsqhAUMidGGhm9ZROv/0KB0E/IAzQ5geRSGqbQI7Ht/UbAF; Authentication-Results: sj-dkim-6.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Magnus Westerlund wrote: > Also I wonder how well ZRTP handles the mixer translator cases. I am > sorry to say that I haven't read the latest ZRTP version. > However I will try to do it before the meeting. Have the > authors consider the example of topologies that can be existing > as described in > http://tools.ietf.org/wg/avt/draft-ietf-avt-topologies/draft-i etf-avt-topologies-02.txt > In Montreal at the RTPSEC BoF there was consensus that we first solve unicast point-to-point keying in a secure manner (such as not disclosing keys to uninvolved parties). It was our intent to capture those requirements from the RTPSEC BoF in draft-wing-media-security-requirements-00.txt. Although that document doesn't currently cite draft-ietf-avt-topologies-02.txt, I believe the RTPSEC BoF found only consensus for "Topo-Point-to-Point" as described in draft-ietf-avt-topologies-02.txt. We can revisit this, but it's important for the authors of MIKEYv2, ZRTP, and DTLS-SRTP to know their design requirements. -d _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 14:20:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gez9D-0001SE-Ex; Tue, 31 Oct 2006 14:19:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gez97-0001RX-3K for avt@ietf.org; Tue, 31 Oct 2006 14:19:38 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gez93-0007gE-Hx for avt@ietf.org; Tue, 31 Oct 2006 14:19:37 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:19:30 -0500 To: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> From: Randell Jesup Date: Tue, 31 Oct 2006 14:19:29 -0500 In-Reply-To: <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> (Colin Perkins's message of "Tue, 31 Oct 2006 18:10:51 +0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 31 Oct 2006 19:19:30.0611 (UTC) FILETIME=[7D644830:01C6FD21] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins writes: >> You could mandate support for RTCP-on-RTP even if not signalled, perhaps. > >You could certainly mandate that ZRTP messages are sent as RTCP on the RTP >port, irrespective of the signalling, until the middleboxes are >fixed. It's not ideal, but it doesn't break the architecture, and those >middleboxes will eventually be fixed to support "a=rtcp:". Except those middleboxes may well reject unknown packets on the RTP port. And in any case, we're putting bandaids on bandaids here - and even with this, there are serious bandwidth issues. >> I admit, I like the idea of RTCP, but I don't see how we can avoid badly >> breaking the RTCP rules. If everyone is willing to break them for this, >> and it doesn't mean another horrible mess like AVPF/SAVPF has turned into >> (because of SDP and how profiles are negotiated), ok. > >I'd prefer ZRTP to use RTCP packets ignoring the timing rules for the >initial negotiation, than for it to embed control information into RTP >media packets. Neither is ideal, but this seems the least bad alternative >architecturally, given that the community seems to have decided to punt >the keying problem onto this group, rather than fixing the SIP layer. Ignoring the timing rules, or timing and bandwidth? If you're ignoring bandwidth rules, you probably won't work in a QoS-enabled network. (For example, cable companies sniff SDP to do QoS reservation over PacketCable for SIP traffic; if you violate the limits your packets will either be delayed or quite possibly dropped.) Obviously it would also affect wireless QoS links as well (802.11e, for example). Etc, etc. And "violating" the RTCP rules (either AVP or AVPF rules) requires a new profile by IETF standards. (And yet more combinatorial profile explosion, and excessive fun in call setup...) -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 14:28:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezGP-0005ZA-QG; Tue, 31 Oct 2006 14:27:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezGN-0005Wj-I0 for avt@ietf.org; Tue, 31 Oct 2006 14:27:07 -0500 Received: from gwmail.avtcorp.com ([198.135.234.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezGC-00013D-AA for avt@ietf.org; Tue, 31 Oct 2006 14:27:07 -0500 Received: from AVTECH-MTA by gwmail.avtcorp.com with Novell_GroupWise; Tue, 31 Oct 2006 11:26:53 -0800 Message-Id: <454732E0.1C8A.0056.0@avtcorp.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Tue, 31 Oct 2006 11:26:24 -0800 From: "Joe Kelsey" To: "Chuck Harrison" , "Randell Jesup" Subject: 802.1as sync [was: Re: [AVT] Layer 2 synchronization and clock] References: <45479ADD.1B8B4E1F@erols.com> In-Reply-To: <45479ADD.1B8B4E1F@erols.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Michael Johas Teener , IETF AV Transport WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Chuck, Nice general discussion of home networking versus professional networking. However, you seem to have missed the central point entirely. The NTP = discussion is not about home versus professional, AV or not. The = discussion is about the fact that it takes almost a day to make NTP = synchronize. If you have long-running networks, then they certainly can = take a day to synchronize themselves. However, there are times where you = need synchronization very much faster than is achievable with NTP. That = is exactly what IEEE-1588 does. Using IEEE-1588, you can synchronize a = network of clocks very rapidly. It is all about how long does it take before you can say that your network = of disparate computers is synchronized to under a microsecond. With NTP = it takes a day. With IEEE-1588 it takes a minute. What are the requiremen= ts for your particular consumer device in terms of clock synchronization = and how long the user is willing to wait for things to settle. It is a completely separate discussion whether or not any of the mentioned = applications really need the precise synchronization or speed of synch. I = personally have that need. Whether or not your particular application has = that need is an open question. /Joe >>> Chuck Harrison 10/31/2006 10:50 AM >>> Mike, all, After chewing on this awhile I would caution 802.1 not to grasp at the IEEE1588 hammer -- this is not a nail. 1588 puts a lot of effort into measuring the link delays. Stop and think about it: in the home AV environment is the wireline or airwave propagation delay the issue? No! Let's look at some historical models from professional AV studio production. In analog sound production, wireline delay is just not a concern. At a concert, the microphone signal may go a few hundred feet from the stage to the mixing console, then a few hundred feet back to the performer's monitor. No sweat. In a digital sound studio there is likely to be a master word clock generator distributing a 48 or 96kHz clock. Nobody is counting out the number of feet of clock cable. In analog video production you see a different story. In the past, technicians would cut cable lengths to within a foot. Why? They wanted to maintain phase match of a 3.58MHz color subcarrier within 1 degree - about a nanosecond. Incidentally, that style of signal engineering has become obsolescent; certainly 802.1 should not be trying to emulate it in a home environment. It would also be worthwhile for 802.1 to get a technical presentation on the currently-deployed layer-2-based audio distribution systems, specifically Cobranet and Gibson Magic. They work, and we can learn from them. I suggest that a small-network AV environment can work under the model that layer-1 link delays are zero. Say a packet leaves link endpoint A at time T(A) on device A's timebase, and arrives at the other endpoint, B, at time T(B) on device B's timebase. We can just assume that T(A) is simultaneous with T(B). The only penalty is a *fixed* offset between device clocks on the order of a microsecond. This offset only changes when the physical network cables are rerouted, and will be imperceptible. As we look for a "better NTP" for LAN environments, the limits on performance will mostly come from (a) drift rate (and change of rate) of the local clocks, and (b) uncertainty in local timestamping relative to the "on-the-wire" signal. We should evaluate whether layer-2 timestamping is an adequate proxy for layer-1 timing. The subtle point is that, if the average delay between PHY and MAC (e.g. in FIFOs) depends on traffic, you can get systematic clock-phase pulling based on network load. If this dynamic phase wander gets up into the multi-microsecond range it's a concern. Suppressing audible phase wander by putting a slow time constant on the clock corrections is dangerous; it can severely impact start-up time. I gather that "the train has left the station" in the sense that 802.1as's officially-approved task is to incorporate=20 IEEE1588 mechanisms into home-network AV. There are worthwhile things to take from 1588, but the link-delay-measurement scheme is not one of them. Considerable equipment simplification would arise from eliminating it. And to point out the obvious: if you want to characterize the multi-hop transport latency, it's a piece of cake to layer that on top of a precise distributed time service. You could say that 1588 is doing it upside down: building the time service on top of a delay-characterized network. Looks more complicated to me! Peace, Chuck Randell Jesup wrote: >=20 > Michael Johas Teener writes: > >All that is being done is to move some timing and QoS services closer = to the > >network layer so that they can be easily built into the hardware for > >Ethernet/WiFi NICs and switches. The result is lower latency and = (probably) > >lower cost. >=20 > Ok, if this is a replacement for NTP that's fine, though requiring = anything > of network elements needs a really good reason, and it'd better be = cheap, > easy to do and not get wrong, and give some sort of benefit outside the > very limited space mentioned here if you want hardware vendors to = implement > it in enough equipment for this to be really useful to you. Targeting > a "better NTP" might be a good start. I would suggest trying very hard = to > make your idea work without special support in hubs/switches/routers if = at > all possible. If it must be there, KISS. :-) >=20 > What bothers me the most is the "insert time in the network stack" part. > a) latency from sample to stack is rarely fixed except in the most > special-purpose hardware. b) the more I hear the more I think you want = to > get the true sampling time for a set of samples. This is really a = hardware > and system issue; it's not a network or protocol issue. IMHO _______________________________________________ Audio/Video Transport Working Group avt@ietf.org=20 https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 14:41:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezTZ-0005dD-UN; Tue, 31 Oct 2006 14:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezTT-0005d5-Bs for avt@ietf.org; Tue, 31 Oct 2006 14:40:39 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezTN-0003z4-89 for avt@ietf.org; Tue, 31 Oct 2006 14:40:39 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 31 Oct 2006 11:40:33 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VJeWbB014335; Tue, 31 Oct 2006 11:40:32 -0800 Received: from dwingwxp (dhcp-171-69-133-63.cisco.com [171.69.133.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9VJeUbF028620; Tue, 31 Oct 2006 11:40:30 -0800 (PST) From: "Dan Wing" To: "'Randell Jesup'" , "'Colin Perkins'" Subject: Negotiating RTP Profiles [was RE: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]] Date: Tue, 31 Oct 2006 11:40:30 -0800 Keywords: direct-to-dwing Message-ID: <065401c6fd24$6d91f5d0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9IY7oL0ddDVQNT3mXs1GEgK4SSwAApOQQ In-Reply-To: DKIM-Signature: a=rsa-sha1; q=dns; l=391; t=1162323632; x=1163187632; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:Negotiating=20RTP=20Profiles=20[was=20RE=3A=20[AVT]=20[Fwd=3A=20I-D=20AC TION=3Adraft-zimmermann-avt-zrtp-02.txt]]; X=v=3Dcisco.com=3B=20h=3DxIOGqviDjOGxHWrFoVbUF1zCRPg=3D; b=qJ0AsVI5jx8Di5Zuj5BEzgamR5QzijsbJmUxonjMP7/EFRVNNdDON0cmNaVeSv/WfRfmoiK+ NU/3pPQ8G0gnLff/nTJmI83D2szujUGD869qZ8ANE85btDOB8Fgpeq8n; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Randell Jesup wrote: > And "violating" the RTCP rules (either AVP or AVPF rules) > requires a new profile by IETF standards. (And yet more > combinatorial profile explosion, and excessive fun in > call setup...) Yes, this needs to be fixed (in MMUSIC, as it's the fault of SDP). I hope we can have fruitful discussions on mechanisms to move this problem forward using SDP. -d _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 15:00:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gezlk-0002yG-6t; Tue, 31 Oct 2006 14:59:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gezli-0002t9-EU for avt@ietf.org; Tue, 31 Oct 2006 14:59:30 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gezle-0007Jk-07 for avt@ietf.org; Tue, 31 Oct 2006 14:59:30 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61491 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Gezld-00078l-Dr; Tue, 31 Oct 2006 19:59:25 +0000 In-Reply-To: References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42A06D25-951B-4A8B-BD66-2DF568167486@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Tue, 31 Oct 2006 19:59:21 +0000 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 31 Oct 2006, at 19:19, Randell Jesup wrote: > Colin Perkins writes: >>> You could mandate support for RTCP-on-RTP even if not signalled, >>> perhaps. >> >> You could certainly mandate that ZRTP messages are sent as RTCP >> on the RTP >> port, irrespective of the signalling, until the middleboxes are >> fixed. It's not ideal, but it doesn't break the architecture, and >> those >> middleboxes will eventually be fixed to support "a=rtcp:". > > Except those middleboxes may well reject unknown packets on the RTP > port. > And in any case, we're putting bandaids on bandaids here - and even > with > this, there are serious bandwidth issues. We standardised the mechanism to signal to those middleboxes three years ago. Push on the vendors and operators to implement them and those kludges go away. It's not like the "a=rtcp:" attribute is difficult, compared to some of the stuff that does get implemented... >>> I admit, I like the idea of RTCP, but I don't see how we can >>> avoid badly >>> breaking the RTCP rules. If everyone is willing to break them >>> for this, >>> and it doesn't mean another horrible mess like AVPF/SAVPF has >>> turned into >>> (because of SDP and how profiles are negotiated), ok. >> >> I'd prefer ZRTP to use RTCP packets ignoring the timing rules for the >> initial negotiation, than for it to embed control information >> into RTP >> media packets. Neither is ideal, but this seems the least bad >> alternative >> architecturally, given that the community seems to have decided >> to punt >> the keying problem onto this group, rather than fixing the SIP >> layer. > > Ignoring the timing rules, or timing and bandwidth? The timing rules. I see no need to violate the bandwidth rules, on average (and there are no short-term guarantees with RTCP anyway, due to it's statistical nature). Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 15:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezvF-0007Ca-6K; Tue, 31 Oct 2006 15:09:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezvD-0007By-Vc for avt@ietf.org; Tue, 31 Oct 2006 15:09:19 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gezuq-00011F-Gc for avt@ietf.org; Tue, 31 Oct 2006 15:09:19 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 15:08:56 -0500 To: "Joe Kelsey" References: <45479ADD.1B8B4E1F@erols.com> <454732E0.1C8A.0056.0@avtcorp.com> From: Randell Jesup Date: Tue, 31 Oct 2006 15:08:54 -0500 In-Reply-To: <454732E0.1C8A.0056.0@avtcorp.com> (Joe Kelsey's message of "Tue, 31 Oct 2006 11:26:24 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 31 Oct 2006 20:08:56.0349 (UTC) FILETIME=[651BFCD0:01C6FD28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Chuck Harrison , Michael Johas Teener , IETF AV Transport WG Subject: [AVT] Re: 802.1as sync X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org "Joe Kelsey" writes: >However, you seem to have missed the central point entirely. The NTP >discussion is not about home versus professional, AV or not. The >discussion is about the fact that it takes almost a day to make NTP >synchronize. If you have long-running networks, then they certainly can >take a day to synchronize themselves. However, there are times where >you need synchronization very much faster than is achievable with NTP. >That is exactly what IEEE-1588 does. Using IEEE-1588, you can >synchronize a network of clocks very rapidly. > >It is all about how long does it take before you can say that your >network of disparate computers is synchronized to under a microsecond. >With NTP it takes a day. With IEEE-1588 it takes a minute. What are >the requirements for your particular consumer device in terms of clock >synchronization and how long the user is willing to wait for things to >settle. Like I (and I think Chuck) was saying is that you don't need IEEE-1588's link-time measurement, and therefore you can use a much simpler solution. We weren't saying that NTP synchronized fast enough, but that you could build an NTP-like or NTP-derivative protocol that synchronizes faster, without requiring the sorts of issues that IEEE-1588 brings along/requires. >It is a completely separate discussion whether or not any of the >mentioned applications really need the precise synchronization or speed >of synch. I personally have that need. Whether or not your particular >application has that need is an open question. Right - but the wider the application and the less modification/cost/complexity for network elements, the more likely it is to become available (outside of specialty items). I think faster sync (especially if it's not hard and doesn't require any support (or minimal) from network elements is an easy sell. A better, local NTP. Precision of sync might be harder sell, but let's see what a better NTP can buy us, since speed and precision are of course related. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From vysknefzuw@ntl.com Tue Oct 31 15:20:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf05d-0007Rv-CP for avt-archive@lists.ietf.org; Tue, 31 Oct 2006 15:20:05 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf05d-0002yz-9m for avt-archive@lists.ietf.org; Tue, 31 Oct 2006 15:20:05 -0500 Received: from cpc1-walt3-0-0-cust270.popl.cable.ntl.com ([82.10.205.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gf04o-0001tS-JA for avt-archive@lists.ietf.org; Tue, 31 Oct 2006 15:19:22 -0500 Message-ID: <000e01c6fd29$d44c6260$0fcd0a52@QuinnFamily> From: "Editor Wikipedia" To: avt-archive@lists.ietf.org Subject: TV program: Editorsa computer Date: Tue, 31 Oct 2006 20:19:12 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6FD29.D44C6260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 ------=_NextPart_000_000A_01C6FD29.D44C6260 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6FD29.D44C6260" ------=_NextPart_001_000B_01C6FD29.D44C6260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable See Copyrights am for details a. Wish change point. Up may of refer or toa or. Change point directly intended from. Gamesthis page lists in articles? Edit plain texthex binary a datasource code or source in codehtml. Page = lists articles associated of with same title if internal. You in here or wish change point directly intended. Terms gnu License! All is text is available am. This or toolssign in create in links = linkcite. Texthex binary is datasource a code a source is codehtml xml audio = dataraster. Intended from Article am Discussion this toolssign in create = of. From Article Discussion this toolssign in create links. Gnu License see Copyrights for. Gnu License see in Copyrights for details registered trademark am = Wikimedia or. In create or links linkcite articlein other was last modified. October = all of text is of available under a. See Copyrights am for details a. Navigation searchlook up may refer toa = person that is. Searchlook up may of refer toa person that does! Intended from is Article Discussion this is toolssign. That does editorcopy editorthe Canadian tv program Editorsa. If or internal link am led you here in. Here wish change point directly = intended from Article Discussion! Up may of refer or toa or. Of gamesthis page of lists articles of associated is with same title. Articles associated with same title am if. Does am editorcopy editorthe. Wish change point. ------=_NextPart_001_000B_01C6FD29.D44C6260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"donations"
See Copyrights am for details a. Wish = change=20 point.
Up may of refer or toa or.
Change point directly intended = from.=20 Gamesthis page lists in articles?
Edit plain texthex binary a = datasource code=20 or source in codehtml. Page lists articles associated of with same title = if=20 internal.
You in here or wish change point directly = intended.
Terms gnu=20 License!
All is text is available am. This or toolssign in create in = links=20 linkcite.
Texthex binary is datasource a code a source is codehtml = xml audio=20 dataraster. Intended from Article am Discussion this toolssign in create = of.
From Article Discussion this toolssign in create links.
Gnu = License=20 see Copyrights for.
Gnu License see in Copyrights for details = registered=20 trademark am Wikimedia or.
In create or links linkcite articlein = other was=20 last modified. October all of text is of available under a.
See = Copyrights am=20 for details a. Navigation searchlook up may refer toa person that is. = Searchlook=20 up may of refer toa person that does!
Intended from is Article = Discussion=20 this is toolssign.
That does editorcopy editorthe Canadian tv program = Editorsa.
If or internal link am led you here in. Here wish change = point=20 directly intended from Article Discussion! Up may of refer or toa = or.
Of=20 gamesthis page of lists articles of associated is with same = title.
Articles=20 associated with same title am if.
Does am editorcopy editorthe. Wish = change=20 point.
------=_NextPart_001_000B_01C6FD29.D44C6260-- ------=_NextPart_000_000A_01C6FD29.D44C6260 Content-Type: image/gif; name="levels.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6fd29$d44c6260$0fcd0a52@QuinnFamily> R0lGODlhyAHAAYf2AAYMAIUGAAB4CYN/AA4AiocAfwCMgbLFyLffx527/UASAF8oAIERDZQeALYa DO0bAAE2AC4zAEpOAF04AIA8AJlMCr0xC9MzDAlrBhNcBENlAFFSAINtAKtaB8JtAOpWBwWEACV4 AEVzAFGMAouDDJaDAMyCAOOFAAmtDBipAjSnAGOZBXicAKKaAMqVAN2eAADGACG1Aka2AmnJAHyy CaO/AMW7COfBDQvRCx/UCT/lAFzhAnnrCpbgBM3SAOnoCQAASCYGSTgANmwEQnMKOJIARLkNQ9cA NQAXOhMUR0ApP1ojSXYsN6IUQbEoP+MUPwZHTSkyMUw6TGM5R4xLQpdHQs47PdNMSgJSNiZRQjpe O21tM4VdAKBiQLpkSd5gRgaEPS2IMj1xOlKBPnF5NpqFPL2ARdaINgmSNyWlS0yRPWuWMYeXNaKu Q8mYP+CSRAa1Oia7TTu5MWW0MnXKPK29Q73KMue3QADXTSjROTjUTFrbNHbqQp3cPrncPNXfPgEA jR8AfjUAjmsAcYwIdpoAjLEMiesAhQ4ofCAWikofc2Ybi4crjqYTccoYct4XcwBNgRdOhURLi2I4 hXI4dZRHgbJGdtg5iwBfjBVuiUZYhFltjIFhdphtdrFedOdRfgGIdCONgTd7fmN5hYuHdKaFic6H guGFhg6dcyWUcTOmjGCgjXucepKodriTg9epgAy9dhq4fjfGhGG1g37Mc5fGicvNi9PHgADefBHj fzrmdWrrjIrlf5ngebPmduDlegAFxSUAyDUItVMAvY4MsZ8AybQKyt0CsgAntSsts0MezFQTznMW xJ8it8UhwNUdsgQyxhVLvzc3wWNIuXM0w5ZNzrNDvudOzABetxJhsU5mvldZw4NfwKFazMZfwdhd swN3vBJ7wziLxmqIyHWBt6x4yrdyzuR3uwCWzBmuu0ipyGKfxo2mt6aVzLiTze2lswrBwyzOzUHE sl3Fy4HBwJfDy///9KGToomBhv8ABAv/AP/7AggA9f8L8AD/9vP68SH5BAAH3G0ALAAAAADIAcAB Bwj/AO0JHEiwoMGCVA4qXMiwocOHECNKnEixosWJIS5q3Mixo8ePID3+G0mypMmTKFOqXMmypcuX MGPKnEmzps2bOHOqZKOzp8+fQFmGHEq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrUINq3cq1q9evYMOK HUu2rNmzaNOqXcu2rVubWOPKnUu3rt27Ft/q3cu3r9+/gAMLHky4MFpChtXiXcy4sePHkDUmnky5 suXLmDNr3sy5897IoEOLHk1aqufTqFOr7lu69cAiru8SiE27tu3buFvHknoot+/fwIMLH068uPHj yJMrX868ufPn0PGunk69uvXr2LNr3869u/fv4MOL/2epZLz5wtHTq18/1SX79/AlnkcZv779+/jz 69/Pv7///wa59MGA9hBI0AcFFoTggAwa2OCCDzI4kIQTNqighQsheKCCBUbI4YcCaRgihxGKGCKG HVJ4oYkmJlhihyCm+GKMIpZo4IgbbjijQSyiKKOKJwIpJIUt/vhggvbMdxJEGt44YosLHgRljhVW iSSOV2LJo45cMlRkjVdOWSSNWvZopZhSTikllRO2+aVCLGYZpUNzytmml2zWGOebd/ZpTx4ANmln mFr6uSWbSMZZaENggpnlmiDWSeijh7qZZ6R3jinpmINSKemifdYpKJ2TYsmpn4pSSmmqoK7nnqCK Ov+qKZ6GPumpRI1mymilm+pKq6WhQirrmqxeiimfkLro666Omrorqq0i+6iGSs6UqLOTzggktFuy ui2cwCbq4YE79orjjmWmC+qo4h7JLqc9jqtsjMdmKm+XnaLb6bVp3qtmtTLxK7CojKq57o9wnnqu rwqviq2trVao4pG1Etrsraruu3Chp7678a9N+tgwxctaKO2/AMM0sLMXZ2gsiRXHHC7Bv9orZKng 8oooyxUPm6zDCO+ML81eYnjxyIayGy63d6Y8EpPp5hrxyxyr+zOxMz+b49E4X231tEP//CnTJdML M8QZY5wq0kyjSSaAtELp7dXF3ujghwZrKrfMi37/OnfNSVsJI9VJw7uz30ILfiLfYKvJdrCLL/11 2ukJSODeqI5L8rpO8rm54Xne67DBcoo+K41OZu7uhTn3DTbjpOvrto6md9s5kZW+7vQ/wzUM9+/A 1+Z78MTH517xyOO2e/LMNy/a8c5H79vy0ld/G/XWZ+/a8vl0371A3n8Pfj4FkW9P+OYfFH75BHl/ fvrgj+++QvPH3/776OMvvvr5y1/+/udrSP3ex7729a+A9hsI/AwIPwAGEH0OVCAAIfi/+h2QfgMM oAT/p78FatB/EhSfA81nvu88ZIHka+D42IdCg0xQgR/U4AhjSEMCrpCGKVTf/XToQhgmkIQM2Z8I /1u4ww3CUIUJNKARZ+hBF6ZPhEHcIRKdWMQc3nCDU3xgFVU4wxoixyVNRKIV49dEBPZQjDEc40KI +EEg9tCHbyyi/Z6YxDjOMY1mTKIa6WhHGeKxjHL04xpZGEg4nvGIiGTjHg2JSB+W0GlhlOIfBRhF NHKRkm/kYyQZyUki0hGQXsxhFkPZyFIWUouXjOIhB3m/UdaRkGRMJAIX6UUtOlIgJjzhBNd3xzlG 8JWtlGQbQdjHXsqQgq6UHxSFicoIRtKNOOShLU3JSVt+koKnTOEF8cjNPMLSj0DMIi3LCE1oLgd6 NkSjMa8IR17yUZDwZCcwP1nNbQ5Skd8bIxuDuf9OUg7zlKTUZC3rOdAOhvCXAxWoNQ3azlsq859u xB419TlPb5KQl/A0JyM3OU2OgpKfBH1nRRVKUIZWM6C3/OgzVTlL+q3RnQ0lJ0Y12tFe5nIiapym TjtZwHeaM6ev3CdF7fjRWBaynH38aTRbWkdAejKYRX0qK81ITpcak57S9Ok3d8ocMG5Vo/m0aCod isKcelCIQpVmRR3qT5FecZlG3ChYAWrDdHIwqk+kaTa9WdedApWrS80rSG/4yO5ApH8HLKsynTq/ FrpPsSZ1Ikc7GFa+YhR/as0gAwM5wgumNYgvVCIEZZrMkgIUpoOlZlMxe9Cm6vU46NSebENz09n/ 2va2Roktbndrl9ry9rfADa5whxsS3RJXP7tDz3GXu1yXCKAgzyVIdAUyXQFY97rXHQh2qWuQ6VIX u+C1rnbDS96DeDe80kUvdLdLXvFyd7zZ/W57xete7aa3vvItL3TtoV/wLiS+66Vve7sLYPsaOLmc OS9/pWtf7753vAx28IL3y2CGKNjADcbwdx+sEAdfOMIalrCHN1xh/EqYwyKeMIU1TGL+VvfDKu5u hV18YQQPBiLVVbGCUzzjHnP4xyfuMYwXnGMKB5nFK84wimVc4hhH98hJTvGJoQxkJPv4v1FmblJy XGTu8vjHSP4ymLPM4ud2GcQWTvN+zyzmCZsZ/80PGTKRzduQKceYznEms5Yr4h4uh/jOTu6wfn1M ZRiP+MwNVu998QxnOY/YzUrOc5hpvF0ad5jOha4zfpecJBsHBscPfjKGHz1mQLc50/DddJHtTOX0 JlnH+bVzk9/75vxeetKFbrOX6wxqIe8ZKbWec6pJDWgwn5rXow6we1k9kSH7F9ZMNvCqTX1rYxc7 2mMOdrWR/edfGyXY2kY0sSf9alRzOtTWvjaWyyztKz96x1VmNLVbTe0ZQ5ned8a3cM1hDqKoWtyE hver881tghPcw6JWc7erPO53r7fF1yZ2wstNYAhDXM4LP/dy+U0R6Elcz/edeJlNXHApr/nZsf/e NKU/DueMZxfhIV93zFP+5EqbV+WUHvjMY/1eT4eF3zXxttD7w/GhGz16RT+60pGX9P1UYulQN0jT o051ove7uD7Puta3zvWue/3rYA+72P9S9bLDbexoT7tnzM72trv97XCPu9znTve62/3ueM+73vee d7X7/e+AD7zg/c734i2i8IhPPFIGz/jGu0XxkI+85CdPee2xIDaYMYLjN++0ynveMQj4vOhHT/rS mx7qnE+96r9y+tZTZfWwTw0kYk/72tv+9rgHu+t3z/ve+/73/cm98IdPkv4AAADAT/5Hjq/85nME +c4PXsqCUJLjE//6tLc+9rePlunRByIpiX7/gLru/SWB//viH4jXy2+SiIT/P/x4SPx/M/9Oc10g x2e+U/RvD+iLBP0OEX78MIDxV3/2UH8DOBAGuIAEKBAEmIAPWIAPeIATOIEF0YAJ6IAUmIEO2IAK CIEI+IEcqIEiqIAmWBEeuIEcaIEEUYEeuIIdOIIqSIIHSIIpAxH+BxX8l4N0YYA1eIIUCIQ/SIMF eBA+GIItKIQkCINI6INJGIRLuBBI+INTKBFVuIBSeIEmyIRZqIHzV4Xs4RI8iH/6l3/9B335539m eIZlOBA5iHxoSIZoyHw7uIMF8X4PkRJH+IRfSINDOIRFaBB76IeAKIheeIhb2IWBGIhGqIQS//iI CJiBjPiHhUiIUfiENbiIlIiJRbiHXjeGath/+DeKoUgQcOiGojiKqBiHppiKcViKPIiHAUgfLxiB l4iFIviFKUiJkSiJSkiFwIiLuxiFfeiEQLiHU8iIEqiFnPiLgCiJLwiMG2iIXuiE8feJBhGKrHiK qpiGqeiK39iNrmiG28iG/HeHANgQsjiJfSiNfhiCxjiIvDiMt5iJmEiI7diJXciLlZiJFUiNx+iM jQiPiOiItWiIN+gQoLiK4qiNDNmQBfGK38iNEjkV7KiCEHiPBAmQRMiM8UiMfyiP9TiJzMiPyciP JdmRlqgQyhiMKWmSL6ke7sGDDgmONSmKpf8Yjqp4hhMJjjiJijopi+oIgBeJhbjYkR/ZjErJhx/Y j45IhO3IkU0YkBtZkke5idZYiJHokfj4jvbHFxwgGHI4h+WIk2tojj25k0DJk2hZlmcZi+nIECNR ByZhgUaZhC4IgtCYgvJoi1eJgU3JgiwYg8+Yiym5ixm5hL5ohDJ4hNE4g5C5lYLZlZc4HQlwE0cx hgoJecaYHJ0ZHcaFgxShmUchlHIZl/rxmcVRfwmZfq7pftwXm6n3mrSZh7J5m41Xm7q5ELjZm4K3 m8BJelwQnMRZnEThm8iZnMq5nMzZnM75nNCJe8YJnKHZEabpGNcZhtH5FrmFmo3xfhXwEeH/SRvj +ZXb6RUP4Y0RWR/laQ8V8J4H8Z7lKZ8DMZ7yaZ/wKRD3SRD7qZ/52Z/uSZ/+OZ/8GaD1GaACSqDB mZP3sZ8KeqD66Z4Qap8TCqEG8aAUWhDtGaEc2p7hmZ8SyqEiuqG+J4YMSZFlaIcHkZ2MkRIfaqEb SqAyCqMduhAeWqMFqqE6eqMvGqI++qPheZ5uoY0VuZOsOH7mBxou6qMPOqIDOqICGqIkaqFSWp// eaE7WqA92qQ3KqRgkZ5reJPmSJrFkaBUOqA9KqEYiqNRCqQieqAkGqNuSqFcmqO7SZMPqZbO8aJN mqURuqZVSqU3+qN/iqVaeqhqKqh2qpt4/0qKrSiOysGnFZqjM+qkTKqolkqphhqoheqfZ7qoViEF RmeijzqOZLmW6JikkeGiUdqqVsqfIIqf/xmrbQqg9AmgCDqfIJqrUIqpIeqlrBc9U1oRw0oaxTqd 8XGsE6GskcGsyPqslFedWKeqwwGsamcUZKqn0Lp36pmeDZGto+GN6qmi3bqtz9MS4KoQ4AqX1MoY jWqWeYpL1op23lqqcEiHZKmGbaiTpPGup1ik5loaM7mvP2mTeUqR8tqu7pqibbiN+jevnPeoCGuw jlqx6uedjcGNBauxowixmyexPlmkGsux5ll8ojGyFIuKHut49gqUItuTrMii7gqzboinK/8bdmB6 jrBIim+5r+n6GOMapjWLlgE7Gsb1sxMhs7lhHVdws4qRjUOhtMrjtL+5qhjLFFRre0p6tUuRtdUC BmMhmlghtRaBtCXrtZyXhmRqtmO6EZpJthXxrmyYsGirej/LttoatyvKtWUbpjmJfHULe9katEe6 kDVbkYQrh6oItxJBspoJuIF7rQp5lmuJpwyat/dqpDSLqknhuFALXPQAd+h0ryhLtCSrluJauW37 tnwbtzq7nnQbuSzLuTcJsKprsWLKr2fLO0RRumopu2lXrzpZu5x7uwW7uceru0jhu3hbtEbbEnOb jX6rop87luGYuGS4uK07Ed06vcwHvBH/qxHNuxBmy7jcC5vgi7PL+3znGBfj67wF4Q6kIa3bmr5P A7/4m7+IR7/Qar+82xAnUBABfAIEXMADbMAEEcAJbBAGfMAN/MAKLMAEnMARLBAVjMASXMADUcEW bA8c/MEYbMEPTMETTMIULMEeDMIp3MApLMArrMEMvMEQHMIrfMIL/Hku8cEefBAXfMM77MI+/MMd vME23MJGTMRHLMRDPMQc/MMR3MQ9vMQojMQlbMRVLMJJ3MJNnMUDPMUdDMVAfMQlfMU77L8Q8cRS jMRSjMZhzMNBHMVUrMQKvMVvnMZOrMZ4zMYx7MY33MVfvMNo7Mcu3MNgTMSFrMY6DMhB/9x7bLzF cPzHe6wQj6zHCyzIigzAfRzJlpzHeNzJnqzIgXzJoOzGhMzHotzJc0zKcpx8jTzCj3zKJhzJq2zH lxzKABzCh7zJayzDLEzHjnzHqRzMX+zKS6zLQqzLifzLqUzLkXc8guzINPzJXrzGNKzMcfzEMMzJ SrzLPFzNptzGhgzJfjzO21zMkAzElLzNyzzIcey/znzMpvzLDzHJ2szOTFzOiRzObezL9bzIn/zM +gzP8gzMfMzCi7zOldzO7iwUojzQ+HzGddzPd6zP+ZzGyOzP3FzOzJzMiAzP51zHF23OB43KuxzA C83QswzOFT3SEo3NMmzRc/zKcCzTkv+MzpIcxVU8xqocww6txVNc0fmc0wjdwie9EnlMzPu8EAYt 0XJ8xSrMy1AczdGs0Q8NwSQMwq/80YaM1C89wiR91Bfs1Chsxvpb1mZ91mid1moNmkXd1m791nAd 13I913Rd13Z9v2t9ene910CR137914Ad2DLJ14SdE4J92PXhD4j9eYq92CDBnP5Q2Jbh2JRd2cwj 2ZhNE5a92Zzd2Z792aAd2sKV2aStMqKtd6Wd2ih92nen2q69vaxtdq892yYb27Yd2qygeGaw22Zw 27ShJLzN27R9f/Wx27593Mid3Lg13LOt3M793Fa72sZZ2v1L2tUd1xChDdqtDfaw3dz/3d0E8d3e Hd7aPRDezd3fLRDnbd7p3d3b7d7vDd/tPd7wzd7x7d7mnd/vPd/2zd/6Pd7pHeDqfd/kHeD0jd8D Xt4Hcd/8Pd/l3eAAXqIt0d7grd4IDt4Unt8VTuH+XRAKXuEaHuIert8WDuLkreECfuHirRAfjt4j XuIY3hArbuLsHeIZnuItTuPiLeAcvrsn/RA9buEuHuMLXuJBDuMojuQ6zuIkvuEGMeNDbuROnuFN HuUkPuRUHt5S/uIzjuQ9juVLTuRWTuPpF9/0veI7zuEtbuYFjuP2neAGruYKzuAMbuRBjuYb/uFT Lt9XDuIEXuD9neQm3uFCXuh3buhs/w6cUb7oR07kYa7kfD7iWT7ofQ7pZ07pfm7lHf7gTx7jN17k Kd7mXq7lWm7gYW7qje566LTomC7iUP7iSk7ojt7pNu7kjy7mgr7lrT7rhk7mXW7rjc7qsP7rY07s ZO7jCw3kZp7oQv7nPA7g+x3h/z3n0K7nkf7s+13q097qB07p6w3jcR7qfi7fmh7pT57j047enJ7u Y956/Ctck/4Y1P2scw3dbsfc+J7vmG3vbdd1JaDv88HvAp946TBcAJ/ZoPC/Ax91Z+EOBy+kCx/x Ej/xFF/xmPfwGJ/xGr/xHN/xHv/xg0ENID/yJF/yJn/yKB97Fn907/56KQ97i8HczP8wfGW78rN1 PNQrtqZIjkLrspSL7P6rA9sZETkvvHpKpPFq87AFvQ5bh4XLlkd/ohYLlC8P82V5vCgLigxbjqeq vVUfvDn79MS7tsjbvu+r9M/LEm9Y9sgLtWLaqND39Xbbit3r9Edquj3Psyoq9yaxDYMX83xPHcYg Fmhf+IY/i4Gf+Ko9Acx5+Fqm+Onr+MwF+ZRf+ZZ/+Zif+SRxAZp/m5L/+aAf+sClW4ObvEtx9jNb qrD7fAyB+pXzd23Z+qYPu0j789WrrrdPvu1r9KxP97m/+ptJvsEP/MHxs57WDSXB+6V/uiCr88Iv +zVPFXKr+r///LgP2DTZs45a99n/m6JTb6r6SoeriK8/OYeKK7E9+7jRO7Q7T7Cki7jiz6Dxn73W C/XlyvN6/4rpn/1dj/9ECxD2AACwJ3AgQYEFEyo0WPAgQoMDHUJ8mLDiRIkMNW7k2NHjR5AhRY4k WRKjQ4UQLa5EiZCgS5QWVcakuJDlTZcwdXKE2fLjS48qaw5NuVKoT4Y5NQJFytTmwp1EicakapPp zqpOsRbFaTWpV61eTY4lW9bsWXv/1K5lu/ZrzYhGi1bsSZcn1bBw6849WJXm3J9+43LtKvXp1r8p JQ7tCzcxUMNID39tKjln2JsY83JtDHhqwrahRY8mXdr0adSpVa9u+xaw3M9Qs94F//u69m3KnG3P 5n3Ucm2nsmf2FL7bsWy5Pj/7xot8c9fMk39vhWybIGvs2bVv5576ot7FMjMOrht+qXmofSO+zIi5 8fi44ImLPy9U/Xr8LDsLzqz+e/v7nCtMrIsUu+yx/OIjbKaT5DsQP/f66m5CCivUDi0MM9RwQ7QY xNBDDkPkryQQAyurxKeCEnFFFlt08UUYYUSRrBljJBG+E02qkSccDQQpQBuDFHJIIos08kgkk1Ry SSabdPJJKKOUckoqy0JtpB2rNHHJLDUEscsRY+xxw+ssNPNMNNMsDcX5VhwOuRbBbNNLEkWa80sd WZxxRzCXSktNQAMVdLsfw3SxT/+z5Dy0zpBKxJNREfd8scxBK7UUTTsTnCjBHsfzbz+jwjPv0zE3 Fc6/k/RT6sECFdPMQPs8BdDU/9Lzq1YCy7vsQFlfbSgpAClaTKf72rM1RS2THQs1zBLT7y7mNpvq OWSdI666lt6kTiw/l8vtuW3nC27aypIbsLhzF0xxL3B/BexSeOPtLtPjrtVUQXXJfdbbjXCNrL9R cRsOvWYFTo9ga8fly9hd070qW4TflAzBvEDFV1mMTWKWWziD0y1agx/mlzlaPbOuMn7/Sjlk3vad OLZnT9ZX4Ylxo9hmvUCTVzRKdva5tUY5hg5IUn21a7+rjHW2QYh1zYrhVI+7uGH/WH2kCWFVPf6v 3lGD3etgAuu7VeVcx0UvY7TTrjbDLhE10u0m4VZ7brqVlJtMZe+2u26++2boSr8DF3zwZX82/HDC E1d8cYUOdzxNxp2EW++43YSS8sgJn5O2n0pdu19h2f4cVo+fbJvDzTsqtsBW81Qxc9hzE33ELHv9 EFLM4yQp96W3JBlzNmMvkllUWV1duaRTbdpP17It+ShsSRU22KaC99Vdq4v22tX8uFa16l+J3h5Y TiVWN8z3uI9efUofd3/CTJ1nWSayo4Nu7Jmxh23+AUlm/rbfvWZbJ4uOUprnsv8VzF7iSiBh+rU0 9vzGfsLjEgELAypiKc2C6wKg/8VuNh2ZgU11+QoQyNjFGaxp7WkV02Bz6uXCEjYQfY8hmKzORsEY bUyC6Qobg6DnwLCVSzAnBCEIH4Ysx5ROOjFrV84k5sTdtEyBLhxhy9ZGRPfw5n1bnFejUJW91SmM V/ApmPK6x7T/Xc1e3YMaeR7YnMGA8WvssSG3PGQ2qr1nYGskIJDieKsYJsyOUcOh5HZXyDdWCVG8 Q2Qjh6TD+CHSj1LqEyMd+TcuZhI7l+RkJz35SVCGUpSjVKQPhWTJHB0SdTIqFCldaTrm8Ul2UUzk q+4YqfjJEkuju92WbPlFNaLylZ98YiQ/Jykg3jJEutSlMfXUyrHJb4LDfOWViv+2KdaZTzzEMpWm BkYrAwZym+BrIzaPR77k2bJ8ZIzYsK4HTA4qp2aN02Q97XmpSKoQgLKTVv3W1UImIjGEKCumEI8V wpX9UEDe2qPRqidMag4OkvpkDBkPGD0MjnB6B2sTQxdWugUGMlbA2eA+0cXDi1pFm/dkaUshF7Sa LZBz/ZOiRutnynwNdIhUfCMU5bnDj30QpTqNJ0QjWjdrAnRoOPqOAKNWwmIRMj5MzSgblRghbQGr YVgdKRwzuNHDSG82rPuTS816VkAdVZG+dBJa3frWCqk1SpMEYlvhele85lWve+VrX/0KP7kGVrCD JWxhDXtYev5VsYtlbGMd+1j/yEZWspOlbGUte1nMYgqxm+VsZz37WdCGNnZyEG1pTXta1IY2s6tl bWsfm1rYxla2s6VtYF17W9zmVre7racYePtbltZWuMMl0l3PAFzkJle5y2Vuc537XOhGV7fEpW51 WyRd7GZXu2eNRzy2+13wZra74SVveSE7XvOmV73ZsW57Q6Re98ZXvvOtLTjoG6QrgUO/9t2vfe3h 34L4t78M2W+AC6yRARtYIQUG8H//q18HL3jBB1ZwhR8MYAgruL/8JfCFIdxg/mKYwwhm8IA3vBEK g5jAH06wgTN84hO7eMIipvCFPTziFt94xiRucIBRTGMWM7is5RVJjzH8YAn3/7jDEeaIkpEs4SdH WMBHZjKJJ+xjLGcYyUamMpNVrOUPI1jMKG4ylME8Ziwv2cFGJnOW3dwRFfvYyVBOc5fZbGU131m0 qNEzhwVc5THP2cl/djOh/3xoj/h5zWJW9IiTXGc6L7rRao50pQGt6EtTGtJ6TrOc31zmSs8Z0h3m 9J3jnGnRvGG7IzlwghFtYzTXWMovHvWrDb1oWHsa049udKs9PWpdS3rJJdYyoDP96kgr2dWtNjGj wSzrKiu72HRmc6kDnWdflxZwv8Z1lDtt7FPP+sxevrWGKX3rahc61nYmtbqTbWxwM/rK525zt7+d 7i7XG97f9rK86b3iYufbwf/rPU27uZ1pTSPc3uV+c5zzXW4qoxvN/e40jvnd70GDWsqaDvemJ17r T+tb1MrOM7UnfmqBFwS+IVk2rZMsa2IPWsgvd/Saw0ztGvd53DS/ObA9fG9wxzzlMq44wC3d8p4b fdM5TjGPM670HTs92jif+X2tfnWsZ13rW+d6173+dbDDbtthtyvBl2vhFud4xiF2eZZznvZpUzzX X447zIGM51zz+N1rrznbXwxtuwc54AH3sdldS5KdE1rhS390okvub4p/GejRZve8Nx5rtNdb8gk3 +cVHXmFRkz1K+Q153znO64Nr/uMWN/ivTW3mol9e8UBn/eNTL2jIf/zx9jX//NkZvnC9/3zjU376 4n0OfMAT/vINJ/rpkd15Oad42unW+IqHPeTe/1b4m794tx09fdUnXOCmr/nBXT1sX5O89XV/9+dD vW/3b9x9osi+Jrmv+M8fuePqP37sl4/r15u6iDM4/pu9Amw9fZO74gs/las/zCoyUpO+umO2trO5 uLu0C8RAEMu2qTM/4RPAo9u5eFs7FxO8Jpu+pgs+Gws9KQmErxs70VsSB3zAGKxB0IJBwnEpAJhB Hoyr0AoAXLJBIeQsoxrCTuIz6Hs2CTS9HYsxEmw+tDsztNrBHqzCTWK5JLS2f9s78Uu2Adw3KilC I2wk0ts1Azy600PDNIS4/8JzKyq0wscCBbxiNWErvRBUu44jugAkPksbQz8UiTL0vpxTw8nrvtsr QW7jPThcRMWiQ0xDuTQsRDBcvjOcvT+8xBCpvONrNi9MOaYTwe+bREykm3sYRVM8RVRMRVVcRVZs RVfcM0aMRVmcRVqsRVu8RVzMRV3cxXgpCwR4RWBUlu1AAGLkRWMELwwhxl8MxtCiAMZBhSohRmbs Ojc4KmWcRmwUHGnMRm6EkWP8RnAMR3HMrm4sR7UZRyvEA3RcR3E0A3Z8R3iMR3mcRwsxR3u8R3z0 LHrcR37sR3/8R4AMSIEcSIIsyHHMR4RMSIWkJoNsSMtaSIiMSIlEJIesSCOLvEiMzEiN3KKJ7EiP /EiQDEmRPIsdGEm12kiUTEmV7MGAAAA7 ------=_NextPart_000_000A_01C6FD29.D44C6260-- From avt-bounces@ietf.org Tue Oct 31 15:21:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf05L-0007Nt-2B; Tue, 31 Oct 2006 15:19:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf05J-0007Nk-UL for avt@ietf.org; Tue, 31 Oct 2006 15:19:46 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf05H-0002qq-1z for avt@ietf.org; Tue, 31 Oct 2006 15:19:45 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 15:19:32 -0500 To: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> <42A06D25-951B-4A8B-BD66-2DF568167486@csperkins.org> From: Randell Jesup Date: Tue, 31 Oct 2006 15:19:31 -0500 In-Reply-To: <42A06D25-951B-4A8B-BD66-2DF568167486@csperkins.org> (Colin Perkins's message of "Tue, 31 Oct 2006 19:59:21 +0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 31 Oct 2006 20:19:32.0806 (UTC) FILETIME=[E0779E60:01C6FD29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins writes: >> Except those middleboxes may well reject unknown packets on the RTP port. >> And in any case, we're putting bandaids on bandaids here - and even with >> this, there are serious bandwidth issues. > >We standardised the mechanism to signal to those middleboxes three years >ago. Push on the vendors and operators to implement them and those kludges >go away. It's not like the "a=rtcp:" attribute is difficult, compared to >some of the stuff that does get implemented... True. But there are a zillion RFCs, and unless there's an application/ business requirement for one of them, many or even most of them don't get implemented. From their point of view, should they spend that time (including regression testing!!) on this, or should they put it onto the Next Big Feature that everyone is clamoring for? Plus, even if implemented, many vendors won't update a box unless they must. They often run years-old software versions. We can say all we want that they "should" implement them. That, and $5+ will get you a coffee at Starbucks. ;-) >>> I'd prefer ZRTP to use RTCP packets ignoring the timing rules for the >>> initial negotiation, than for it to embed control information into RTP >>> media packets. Neither is ideal, but this seems the least bad >>> alternative architecturally, given that the community seems to have >>> decided to punt the keying problem onto this group, rather than fixing >>> the SIP layer. >> >> Ignoring the timing rules, or timing and bandwidth? > >The timing rules. I see no need to violate the bandwidth rules, on average >(and there are no short-term guarantees with RTCP anyway, due to it's >statistical nature). There's less need to violate the timing rules (I think) with AVPF. However, the bandwidth rules still mean an up-to-10-second key negotiation (ignoring packet losses). That's simply unusable, and that sort of issue is why they're doing something even uglier in the current draft (header extensions). What's your objection to something like: m=audio 4321 RTP/AVP 0 99 a=rtpmap:99 ZRTP/8000 a=rtpmap:0 PCMU/8000 -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 15:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0gp-0007pp-Vj; Tue, 31 Oct 2006 15:58:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0go-0007k8-CB for avt@ietf.org; Tue, 31 Oct 2006 15:58:30 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0gk-0008GZ-Tm for avt@ietf.org; Tue, 31 Oct 2006 15:58:30 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61541 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Gf0gk-00066G-7y; Tue, 31 Oct 2006 20:58:26 +0000 In-Reply-To: References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> <42A06D25-951B-4A8B-BD66-2DF568167486@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8663D3C4-1335-4E0D-BD5B-FF4BE4150304@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Tue, 31 Oct 2006 20:58:22 +0000 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On 31 Oct 2006, at 20:19, Randell Jesup wrote: > Colin Perkins writes: >>> Except those middleboxes may well reject unknown packets on the >>> RTP port. >>> And in any case, we're putting bandaids on bandaids here - and >>> even with >>> this, there are serious bandwidth issues. >> >> We standardised the mechanism to signal to those middleboxes >> three years >> ago. Push on the vendors and operators to implement them and >> those kludges >> go away. It's not like the "a=rtcp:" attribute is difficult, >> compared to >> some of the stuff that does get implemented... > > True. But there are a zillion RFCs, and unless there's an > application/ > business requirement for one of them, many or even most of them > don't get > implemented. From their point of view, should they spend that time > (including regression testing!!) on this, or should they put it > onto the > Next Big Feature that everyone is clamoring for? Plus, even if > implemented, many vendors won't update a box unless they must. > They often > run years-old software versions. NAT traversal and security aren't the Next Big Thing? ... >>>> I'd prefer ZRTP to use RTCP packets ignoring the timing rules >>>> for the >>>> initial negotiation, than for it to embed control information >>>> into RTP >>>> media packets. Neither is ideal, but this seems the least bad >>>> alternative architecturally, given that the community seems to have >>>> decided to punt the keying problem onto this group, rather than >>>> fixing >>>> the SIP layer. >>> >>> Ignoring the timing rules, or timing and bandwidth? >> >> The timing rules. I see no need to violate the bandwidth rules, >> on average >> (and there are no short-term guarantees with RTCP anyway, due to >> it's >> statistical nature). > > There's less need to violate the timing rules (I think) with AVPF. > However, the bandwidth rules still mean an up-to-10-second key > negotiation > (ignoring packet losses). That's simply unusable, and that sort of > issue > is why they're doing something even uglier in the current draft > (header > extensions). I don't see why you can't send the ZRTP exchange at *exactly* the same rate as in the current draft, while still using RTCP. You do the key exchange quickly, then delay your next RTCP packet to compensate. Overall bandwidth fraction the same as with standard RTCP, but violates the timing rules a little (in the same way AVPF does, but for several (two?) packets, rather than just for one packet). > What's your objection to something like: > > m=audio 4321 RTP/AVP 0 99 > a=rtpmap:99 ZRTP/8000 > a=rtpmap:0 PCMU/8000 ZRTP keying negotiation packets aren't audio data. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 16:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0sO-0004yf-KR; Tue, 31 Oct 2006 16:10:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0sJ-0004yE-6P for avt@ietf.org; Tue, 31 Oct 2006 16:10:23 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0sG-0000ny-Nf for avt@ietf.org; Tue, 31 Oct 2006 16:10:23 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 31 Oct 2006 13:10:20 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VLAK04008209; Tue, 31 Oct 2006 13:10:20 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9VLAJAo017996; Tue, 31 Oct 2006 13:10:19 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9VKvU4Q022036; Tue, 31 Oct 2006 12:57:30 -0800 In-Reply-To: References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <336B504D-7E11-48F5-9B28-85E5C07EF683@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Tue, 31 Oct 2006 16:10:03 -0500 To: Randell Jesup , IETF AVT WG X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-2.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3580; t=1162329020; x=1163193020; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[AVT]=20[Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-02.tx t]; X=v=3Dcisco.com=3B=20h=3DVo+OzlcFA1/SUm1JyTNM+SnaVj4=3D; b=N5iBFyap+JtaJzk4TmGTgVUB8z7G5QJNYVZi9PAFGYYTOseOTXI6s5LZdiPIiFsmNFVyG/wI fSdFwKZ6SJDnChdPTBRqrH6PJw2MKl2QqooSWTlAjRqDO7NRa6Eh2nY1; X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Excuse me, but this whole RTCP bandwidth discussion is making my brain hurt. Some folks seem to be tied up in Talmudic examination of the specs (probably with the ulterior motive of supporting a conclusion they've already reached) when I the situation strikes me as VERY simple: Either zrtp: a) does not send SRTP packets until the key management exchange finishes, or b) sends insecure RTP packets until the key management protocol finishes and zrtp allows the beginning of the conversation to occur in an insecure mode. If (a), then the whole session bandwidth is actually available to RTCP since the bandwidth restrictions on RTCP are intended to keep the total bandwidth of RTP+RTCP below the session bandwidth. If (b) you just tolerate a little longer before you start sending those realtime text messages to your page friends (with apologies to the non-US participants who may not get the ironic reference). What am I missing? On Oct 31, 2006, at 2:19 PM, Randell Jesup wrote: > Colin Perkins writes: >>> You could mandate support for RTCP-on-RTP even if not signalled, >>> perhaps. >> >> You could certainly mandate that ZRTP messages are sent as RTCP >> on the RTP >> port, irrespective of the signalling, until the middleboxes are >> fixed. It's not ideal, but it doesn't break the architecture, and >> those >> middleboxes will eventually be fixed to support "a=rtcp:". > > Except those middleboxes may well reject unknown packets on the RTP > port. > And in any case, we're putting bandaids on bandaids here - and even > with > this, there are serious bandwidth issues. > >>> I admit, I like the idea of RTCP, but I don't see how we can >>> avoid badly >>> breaking the RTCP rules. If everyone is willing to break them >>> for this, >>> and it doesn't mean another horrible mess like AVPF/SAVPF has >>> turned into >>> (because of SDP and how profiles are negotiated), ok. >> >> I'd prefer ZRTP to use RTCP packets ignoring the timing rules for the >> initial negotiation, than for it to embed control information >> into RTP >> media packets. Neither is ideal, but this seems the least bad >> alternative >> architecturally, given that the community seems to have decided >> to punt >> the keying problem onto this group, rather than fixing the SIP >> layer. > > Ignoring the timing rules, or timing and bandwidth? If you're > ignoring > bandwidth rules, you probably won't work in a QoS-enabled network. > (For > example, cable companies sniff SDP to do QoS reservation over > PacketCable > for SIP traffic; if you violate the limits your packets will either be > delayed or quite possibly dropped.) Obviously it would also affect > wireless QoS links as well (802.11e, for example). Etc, etc. > > And "violating" the RTCP rules (either AVP or AVPF rules) requires > a new > profile by IETF standards. (And yet more combinatorial profile > explosion, > and excessive fun in call setup...) > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex- > Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out > of the weapons > provided for defence against real, pretended, or imaginary dangers > from abroad." > - James Madison, 4th US president (1751-1836) > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 18:45:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3HI-0000RM-R4; Tue, 31 Oct 2006 18:44:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3HF-0000RD-Oo for avt@ietf.org; Tue, 31 Oct 2006 18:44:18 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3HE-0001AI-F6 for avt@ietf.org; Tue, 31 Oct 2006 18:44:17 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 18:44:16 -0500 To: Colin Perkins Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> <42A06D25-951B-4A8B-BD66-2DF568167486@csperkins.org> <8663D3C4-1335-4E0D-BD5B-FF4BE4150304@csperkins.org> From: Randell Jesup Date: Tue, 31 Oct 2006 18:44:15 -0500 In-Reply-To: <8663D3C4-1335-4E0D-BD5B-FF4BE4150304@csperkins.org> (Colin Perkins's message of "Tue, 31 Oct 2006 20:58:22 +0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 31 Oct 2006 23:44:16.0432 (UTC) FILETIME=[7A143300:01C6FD46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org Colin Perkins writes: >> True. But there are a zillion RFCs, and unless there's an application/ >> business requirement for one of them, many or even most of them don't >> get implemented. From their point of view, should they spend that time >> (including regression testing!!) on this, or should they put it onto the >> Next Big Feature that everyone is clamoring for? Plus, even if >> implemented, many vendors won't update a box unless they must. They >> often run years-old software versions. > >NAT traversal and security aren't the Next Big Thing? Not for an SBC; they generally don't care. (I may be wrong, and certainly ICE has pushed things forward in this area - but if ICE/etc didn't demand a=rtcp, you can bet they wouldn't be very motivated about it.) >> There's less need to violate the timing rules (I think) with AVPF. >> However, the bandwidth rules still mean an up-to-10-second key >> negotiation (ignoring packet losses). That's simply unusable, and that >> sort of issue is why they're doing something even uglier in the current >> draft (header extensions). > >I don't see why you can't send the ZRTP exchange at *exactly* the same >rate as in the current draft, while still using RTCP. You do the key >exchange quickly, then delay your next RTCP packet to compensate. Quickly? It's 4 packets (or more), and over 10Kbits. It would be around 8-10 seconds before you could exchange the final packet (I think if you look at the handshakes, etc, you might end up in 10-15 seconds of wall time for a G.729 20ms stream - more for 30ms). >Overall bandwidth fraction the same as with standard RTCP, but violates >the timing rules a little (in the same way AVPF does, but for several >(two?) packets, rather than just for one packet). 4 packets, plus any re-xmits for lost packets, etc. And AVPF violating the timing rules of AVP is why AVPF is a profile. If you want to violate the timings for those first 4 (or more!) RTCP packets, you need an alternative profile. And you may still have problems with QoS links. Otherwise, if you sent the RTCP without waiting, the QoS for that RTCP stream may either delay it (until it fits into 5%) or more likely just drop it (valid in UDP if you over-send to a QoS-defined channel). There's NO guarantee I know of that RTCP (or RTP) can burst over bandwidth for more than a single packet. After that you have to assume it has to wait. >> What's your objection to something like: >> >> m=audio 4321 RTP/AVP 0 99 >> a=rtpmap:99 ZRTP/8000 >> a=rtpmap:0 PCMU/8000 > >ZRTP keying negotiation packets aren't audio data. True. Neither are RTP headers, nor random header-extensions, nor APP messages in RTCP, nor ZRTP key-exhange in RTCP, etc. (I'm stretching on the RTP headers, but not on header extensions or other RTCP data.) They _would_ be well-identified this way, and they are part of the stream, and they can be rejected at the signalling level before the call starts (which the current ZRTP header-ext stuff doesn't really allow). In fact, that's the biggest minus of this for me - a SIP proxy can block a ZRTP handshake (though it could anyways by routing the media through an RTP proxy and filtering the header-exts, so it's not a huge deal). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 19:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3fy-0007SM-PH; Tue, 31 Oct 2006 19:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3fv-0007SD-VP for avt@ietf.org; Tue, 31 Oct 2006 19:09:48 -0500 Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3fu-0004nJ-O1 for avt@ietf.org; Tue, 31 Oct 2006 19:09:47 -0500 Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 19:09:46 -0500 To: David R Oran Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> <336B504D-7E11-48F5-9B28-85E5C07EF683@cisco.com> From: Randell Jesup Date: Tue, 31 Oct 2006 19:09:45 -0500 In-Reply-To: <336B504D-7E11-48F5-9B28-85E5C07EF683@cisco.com> (David R. Oran's message of "Tue, 31 Oct 2006 16:10:03 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 01 Nov 2006 00:09:46.0707 (UTC) FILETIME=[0A31A230:01C6FD4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF AVT WG , Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org David R Oran writes: >Excuse me, but this whole RTCP bandwidth discussion is making my brain >hurt. Some folks seem to be tied up in Talmudic examination of the specs >(probably with the ulterior motive of supporting a conclusion they've >already reached) when I the situation strikes me as VERY simple: > >Either zrtp: >a) does not send SRTP packets until the key management exchange finishes, >or >b) sends insecure RTP packets until the key management protocol finishes >and zrtp allows the beginning of the conversation to occur in an insecure >mode. > >If (a), then the whole session bandwidth is actually available to RTCP >since the bandwidth restrictions on RTCP are intended to keep the total >bandwidth of RTP+RTCP below the session bandwidth. That would be the case - except that QoS channels are typically tied to ports, and so (for example) if you have a b=AS:100 on a stream on port X, comcast/packetcable reserves around 100Kbps for X, and around 5Kbps for port X+1 (or the a=rtcp port). So even if you don't use port X, you may not be able to send more than 5Kbps on X+1. Similar problems may crop up for other tight-bandwidth/QoS channels like 3G, 802.11e, etc. So, a) doesn't help you. In some cases it does, but you can't count on it, and you can't even know if a channel (like PacketCable) invoked QoS for you (and yes, they can do it). I wish a wand could be waved and do that. The closest I can come is to explicitly put it into the RTP stream as a payload type. >If (b) you just tolerate a little longer before you start sending those >realtime text messages to your page friends (with apologies to the non-US >participants who may not get the ironic reference). Like I said, it could be a pretty long time - and many secure apps send silence while negotiating keys, or that's an option. And they'll just record the messages after they're decrypted anyways. ;-) -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 19:43:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf4Au-0000rX-NV; Tue, 31 Oct 2006 19:41:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf4AL-0000gD-Au for avt@ietf.org; Tue, 31 Oct 2006 19:41:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf48S-0001PY-Dz for avt@ietf.org; Tue, 31 Oct 2006 19:39:17 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 16:39:16 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA10dFqE011603; Tue, 31 Oct 2006 16:39:15 -0800 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA10dAOV012840; Tue, 31 Oct 2006 16:39:10 -0800 (PST) From: "Dan Wing" To: "'Randell Jesup'" , "'David R Oran'" Subject: RE: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Tue, 31 Oct 2006 16:39:10 -0800 Keywords: direct-to-dwing Message-ID: <08b001c6fd4e$28837ca0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb9Sgr2/K4+9X6yRlC2oKK5uAAMrgAA9fVA In-Reply-To: DKIM-Signature: a=rsa-sha1; q=dns; l=449; t=1162341555; x=1163205555; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[AVT]=20[Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-02.tx t]; X=v=3Dcisco.com=3B=20h=3DjtBku9Jxs4O6AYZ0RUebxI1k3fM=3D; b=WBi+CAnsypkTs9euby8/LQEzZvTO8tHp/Q2v+vVvU2T18Ff4Ymnsmol7SV0gMAewD+i9/MqR 0Qs013/GuK0Jh8ZIcdExyh8j6f0pJw6dsnLRly607IQzmHtTKy47wjgp; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'IETF AVT WG' X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org ... > Like I said, it could be a pretty long time - and many secure > apps send silence while negotiating keys, or that's an option. Although considered by many to be too heavy, security preconditions (draft-ietf-mmusic-securityprecondition) could be used to allow keys to be negotiated before ringing the called party. > And they'll just record the messages after they're decrypted > anyways. ;-) Richard Nixon would be proud! -d _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 20:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf59I-0004lU-Mb; Tue, 31 Oct 2006 20:44:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf59E-0004hr-HN for avt@ietf.org; Tue, 31 Oct 2006 20:44:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf59A-0004pE-MW for avt@ietf.org; Tue, 31 Oct 2006 20:44:08 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 17:44:04 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA11i4MX008818; Tue, 31 Oct 2006 17:44:04 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA11i0ip010311; Tue, 31 Oct 2006 17:44:04 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Oct 2006 17:44:02 -0800 Received: from [192.168.0.10] ([10.21.153.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 17:44:01 -0800 In-Reply-To: <4542186A.9030907@ericsson.com> References: <85384093-2F6C-4792-9619-CDC8734F7EA0@cisco.com> <453E119C.2030907@ericsson.com> <0987A300-0826-47BF-A5DA-EC06F088B989@cisco.com> <4541C0FC.3080208@ericsson.com> <050A817F-EAAF-483C-8D23-08DEB9CDFDE1@cisco.com> <4542186A.9030907@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54F5530E-323A-42AB-8025-1F9D92788E57@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt Date: Tue, 31 Oct 2006 17:43:58 -0800 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 01 Nov 2006 01:44:01.0977 (UTC) FILETIME=[34FF5A90:01C6FD57] DKIM-Signature: a=rsa-sha1; q=dns; l=6099; t=1162345444; x=1163209444; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[AVT]=20I-D=20ACTION=3Adraft-ietf-avt-topologies-02.txt; X=v=3Dcisco.com=3B=20h=3DNFXujfBomnBJBWsC0QikGwRg/PI=3D; b=hRrTQPrsmO4gRH4o8pXCc4LTUudk4d4tz41Hzxpe9r8G5HcKfk+8185oQGn6u25vPUwYjGHX XG0offW1PTlpIyDzonHrif/V2le37tJkAmwHICTP44chtDRHmrSdfhfX; Authentication-Results: sj-dkim-4.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Stephan Wenger , IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 27, 2006, at 7:32 AM, Magnus Westerlund wrote: > Mark Baugher skrev: >> Magnus, >> On Oct 27, 2006, at 1:19 AM, Magnus Westerlund wrote: >>> Mark Baugher skrev: >>>> On Oct 24, 2006, at 6:14 AM, Magnus Westerlund wrote: >>>>> Mark Baugher skrev: >>>>>> Magnus, Stephan, >>>>>> I gave this a first read and it's well-written and to the >>>>>> point IMHO. I have a couple of comments off the top of my >>>>>> head. Starting with Security Considerations, Second, the >>>>>> number of security contexts needed (for example in >>>>>> SRTP [RFC3711]) may vary between mixers and >>>>>> translators. A mixer >>>>>> normally needs to represent only a single SSRC in any >>>>>> given >>>>>> domain, and therefore needs to create only one SRTP >>>>>> security >>>>>> context. In contrast, a translator needs one context per >>>>>> participant it translates toward in the opposite domain. >>>>>> Couldn't Figure 6 have five crypto contexts installed in the >>>>>> mixer? I think you're saying that everyone but the mixer >>>>>> receives using the same crypto context. The mixer >>>>>> additionally needs to receive the others' streams and each >>>>>> will have a crypto context. >>>>> >>>>> In the case depicted by figure 6, the mixer will have one SSRC >>>>> and the A-D will have at least one respectively. However if we >>>>> are looking at the link between A and the mixer, the traffic >>>>> passing on this link there will be only two SSRCs, A's and the >>>>> Mixer's. The SSRCs belonging to B, C and D will only occur in >>>>> CSRC list and inside RTCP SDES packets. Thus from an SRTP >>>>> perspective, A only needs two crypto contextes, one for its own >>>>> traffic and one for the mixer. The same is true for each of the >>>>> other participants that only receive a mixed view of the >>>>> session. That is why I am saying that the mixer will have one >>>>> SSRC (at least). >>>> I misread the text cited above, "A mixer normally needs to >>>> represent only a single SSRC per domain and therefore needs to >>>> create only one SRTP security context". I think we could put it >>>> this way, "A mixer normally needs to represent only a single >>>> SSRC per domain and therefore needs to create only one SRTP >>>> crypto context per domain" where I added 'per domain' and >>>> changed 'security' to 'crypto'. >>> >>> Your sentence seems like a improvement. However maybe I should >>> clarify what I was considering was the implication on the number >>> of session keys and their related parameters. If I understand >>> crypto context in SRTP it normally means the master key and its >>> parameters. Thus the number of crypto contexts will depend on the >>> keying model, a shared master key or one master key per SSRC. But >>> it might be easiest to not dig to deep into this within the >>> document. SRTP is a recommended security mechanism but not the >>> only one that may be used. >> Yes, there can be one or multiple SRTP crypto contexts for an SRTP >> session depending on whether you share the key between senders or >> not. It's better to count the number of RTP sessions rather than >> SRTP crypto contexts. > > Well, my intention was a comparison between mixers and translators. > Here the comparision using with RTP sessions will be very > misleading. A Mixer will have one RTP session for each domain, > however there SSRC/CSRC spaces will be joint. Is this a requirement like a "shall", or is it something that's obviously needed for the mixer to function properly? Pardon me if I'm missing something that I should know, but I see this as one way to do it - and I am not aware of any standard way. Why wouldn't the mixer, for example, create entirely a new SSRC space for each domain and map the SSRCs from the other domain into it? In fact, it's permissible (though not recommended) for the mixer to not even send CSRCs, right? > A Translator will only have one session that is joint between the > domains. > When one start looking at the crypto context a mixer only needs to > keep track of the already existing crypto contexts for a domain and > possibly one for itself (assuming per sender keys). However a > translator that does anything to the SRTP protected parts of the > packet, will need to re-encrypt the packets. To avoid two-time pads > it will need to use a different key than what was used by the > sender of the packet in the originating domain. Right. I'd spell it out: "In the translator case, RFC 3550 specifies that the SSRC is kept 'intact' and if the translator does not have a different key than the source it is translating, the source and translator will encrypt two different plaintexts (the original payload and the translated payload) with the same keystream". But does it need two crypto contexts when it translates and forwards to two hosts? Referring to Fig. 3 and the flows from B and D to A and C, there could be one key that's shared on the multicast network and thus one crypto context. That is, why couldn't the translator have it's own key for each domain rather than one key for each participant in each domain? > Thus a translator will in worst case end up with N*P crypto > contextes where N is the total number of participants in the joint > session, and P the number of domains it handles. So from an SRTP > perspective a translator may actually end up with much more crypto > work than a mixer would. I know I originally agreed with this formulation, but now I'm confused by it. Mark > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 31 23:12:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf7Re-0005Q9-J5; Tue, 31 Oct 2006 23:11:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf7Rb-0005Q4-Ul for avt@ietf.org; Tue, 31 Oct 2006 23:11:15 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf7Ra-00083j-Ju for avt@ietf.org; Tue, 31 Oct 2006 23:11:15 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 20:11:14 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA14BERj009719; Tue, 31 Oct 2006 20:11:14 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA14BDAo002568; Tue, 31 Oct 2006 20:11:13 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kA13wMw6031119; Tue, 31 Oct 2006 19:58:23 -0800 In-Reply-To: References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> <336B504D-7E11-48F5-9B28-85E5C07EF683@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Tue, 31 Oct 2006 23:11:07 -0500 To: Randell Jesup X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-1.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3103; t=1162354274; x=1163218274; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[AVT]=20[Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-02.tx t]; X=v=3Dcisco.com=3B=20h=3DVo+OzlcFA1/SUm1JyTNM+SnaVj4=3D; b=Xyg+igUcBY7rELJrJgKM+nW2IGQ3X2JDorD+q00ksEhecC1A265zGjz4PoykM9zQyUE/K66l kfnjX5aZvAB8IW31DFJZlDQT+J7cGVzeJQC31lQkH7LcWvvtCsbMmpK0; X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF AVT WG , Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org On Oct 31, 2006, at 7:09 PM, Randell Jesup wrote: > David R Oran writes: >> Excuse me, but this whole RTCP bandwidth discussion is making my >> brain >> hurt. Some folks seem to be tied up in Talmudic examination of >> the specs >> (probably with the ulterior motive of supporting a conclusion >> they've >> already reached) when I the situation strikes me as VERY simple: >> >> Either zrtp: >> a) does not send SRTP packets until the key management exchange >> finishes, >> or >> b) sends insecure RTP packets until the key management protocol >> finishes >> and zrtp allows the beginning of the conversation to occur in an >> insecure >> mode. >> >> If (a), then the whole session bandwidth is actually available to >> RTCP >> since the bandwidth restrictions on RTCP are intended to keep the >> total >> bandwidth of RTP+RTCP below the session bandwidth. > > That would be the case - except that QoS channels are typically > tied to > ports, and so (for example) if you have a b=AS:100 on a stream on port > X, comcast/packetcable reserves around 100Kbps for X, and around > 5Kbps for > port X+1 (or the a=rtcp port). So even if you don't use port X, > you may > not be able to send more than 5Kbps on X+1. Similar problems may > crop up > for other tight-bandwidth/QoS channels like 3G, 802.11e, etc. > Oh, come on. the dead fish are just piling up on the table. If 3G is policing per port, they got to be nuts. If you can't get a best effort key exchange through on a random UDP port, lots of things are going to break and zrtp won't be the only one. > So, a) doesn't help you. I beg to differ. > In some cases it does, but you can't count on it, In the IP world, you can't count on anything in the sense you're raising objections. I suppose one could say that these silly policers are doing DPI and stomping on the precious zrtp payload types too. > and you can't even know if a channel (like PacketCable) invoked QoS > for you > (and yes, they can do it). I wish a wand could be waved and do > that. The > closest I can come is to explicitly put it into the RTP stream as a > payload > type. > I don't think we're going to convince each other of any of this. Sigh. >> If (b) you just tolerate a little longer before you start sending >> those >> realtime text messages to your page friends (with apologies to >> the non-US >> participants who may not get the ironic reference). > > Like I said, it could be a pretty long time - and many secure apps > send > silence while negotiating keys, or that's an option. > > And they'll just record the messages after they're decrypted > anyways. ;-) > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex- > Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out > of the weapons > provided for defence against real, pretended, or imaginary dangers > from abroad." > - James Madison, 4th US president (1751-1836) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From rnkadwibpo@overseasprinting.com Tue Oct 31 23:17:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf7Xk-0000nW-Id for avt-archive@lists.ietf.org; Tue, 31 Oct 2006 23:17:36 -0500 Received: from [201.39.121.252] (helo=[200.214.154.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf7Xc-0000hs-64 for avt-archive@lists.ietf.org; Tue, 31 Oct 2006 23:17:36 -0500 Message-ID: <001101c6fd6c$9e7f0e60$7d9ad6c8@xx0903ace58fd2> From: "much" To: avt-archive@lists.ietf.org Subject: somebodys shelf. Date: Wed, 1 Nov 2006 01:17:18 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6FD53.7931D660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.6 (+) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d ------=_NextPart_000_000D_01C6FD53.7931D660 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6FD53.7931D660" ------=_NextPart_001_000E_01C6FD53.7931D660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hardware Book Welcome to. Watching someone else do. Table much would big = stir of Tuesdays caused. News more details Connectors am buses. Allow that place. Advance both West Courses is Please. Copyright copy Team may be. World of where heavymetal band a Metallica or shunned. Document last modified is Playlist Enter Aquaman a Home top Stories? Heavymetal band Metallica shunned Store its is policy making is. Support = Guarantee am completely a satisfied return refund. Executives rethink they handle discarded shows im or. Thats because = there isnt oneor? It Press Releases in. Spikes denim jeans permitted Policy. Active filters a Tables with info = or. Tells us futurewhen services. Only wind cancelled unaired is episodes. Hardware Book Welcome to. It am Press Releases a idg Contact Terms. Feed = xml a Whats Archivethe October? Through various live concerts entirety. Teetime in booking system clicking quotbook tee in Timesquot link below. Many other or cables Adapters? Heavymetal of band Metallica shunned = Store its policy. News more details Connectors am buses. Who of did am this why is Comment Send. Filmed pilot hope. Cables of how build in serial many other or cables Adapters adapters. = Watching someone else do. ------=_NextPart_001_000E_01C6FD53.7931D660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Noordam"
Hardware Book Welcome to. Watching = someone else do.=20 Table much would big stir of Tuesdays caused.
News more details = Connectors am=20 buses. Allow that place.
Advance both West Courses is Please. = Copyright copy=20 Team may be.
World of where heavymetal band a Metallica or=20 shunned.
Document last modified is Playlist Enter Aquaman a Home top=20 Stories?
Heavymetal band Metallica shunned Store its is policy making = is.=20 Support Guarantee am completely a satisfied return refund.
Executives = rethink=20 they handle discarded shows im or. Thats because there isnt oneor? It = Press=20 Releases in.
Spikes denim jeans permitted Policy. Active filters a = Tables=20 with info or.
Tells us futurewhen services. Only wind cancelled = unaired is=20 episodes.
Hardware Book Welcome to. It am Press Releases a idg = Contact Terms.=20 Feed xml a Whats Archivethe October?
Through various live concerts=20 entirety.
Teetime in booking system clicking quotbook tee in = Timesquot link=20 below.
Many other or cables Adapters? Heavymetal of band Metallica = shunned=20 Store its policy. News more details Connectors am buses.
Who of did = am this=20 why is Comment Send.
Filmed pilot hope.
Cables of how build in = serial many=20 other or cables Adapters adapters. Watching someone else=20 do.
------=_NextPart_001_000E_01C6FD53.7931D660-- ------=_NextPart_000_000D_01C6FD53.7931D660 Content-Type: image/gif; name="Noordam.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6fd6c$9e7f0e60$7d9ad6c8@xx0903ace58fd2> R0lGODlhmAGgAYf2AAwAAHYAAACHB3+LDgcAjooIhwSKcri7scvauaXS80oTAF4qBYIhAZ4iCMog ANguAABKAB0zAENNCGVJAIszCqc6BbJGAOlFAAxnDBtkC0VXAF9WAHNbC6BpDMtgAOJrAAR7ABGE C0iGCWqHAIZyAKN3AsF2ANmIAQCrABypB0STAFyYBYKqAZudAreuA9+sAADDABbCAD+yCl7OCHWz DJLGALe9ANS3AAvhCBbUDELrAGPXAoPrDJbjALjiDevlDAMATRkGO0cAO14APoUJOaMAN8cMQt4A PQApPiQrOjMSPGcVSIYjR5URMbweRN4sSgZEOhhNRT47SGQ3SX07OaJLNr5NQ9k9QwBTNCNSTkJo QWVYTntqBadSMr5pRehmOQF6OxVyMkKMRWF4QIZ8P5qJRsdySON3RQCYQhylOU2lOWOYO4isSJ2U PLOiN96tMgvETCq9SkC7OV67NnO4QZG+Tr/KTtm0RwPmOxbsST/aRVHoNYfrNZbXM8vpPO7dNQAA dh4MiD0EfGQAhIwMhZQGjbUAgNkAiQYhiCsphD4mgGwffHkecpQnfcobdO4bdgs0iixGjT8zeVpL i340h5FIerk9jeM0eg5afh9UdzxshWdgeIRWia5gcsJbjtdhdACBfyRzjTqEe2Z3eHx/iZ50hcaN i+CGhwycgiSSgDelel+qhnOdjaWXcseqc+KqgwW8ixK1izXLc1PNd4u+eJeygs3FhdyzdwvsdBzU ckrsfWjcdYHgg67ijLfcg9jaiAUKuxIIvzgAxWsIzHgAt6MJv7sAvu0AzAApuB4SsjcYxWwfyIQl x64RxMAfzOgkww5DziM+tTVFtGg6xIlGypQ2zcQ6x9lAyABuwhFcukljv2xZvHxYwKNcy7NVuNFb xQaHsiCKzTJ6x2eDvoSMxKt8xbOIveqCswCWwxahwEqqvWOnx42jwputysGmv9qXwADItyTMyTLJ tm67yILCx5nKv///6qKsr3l5if8AAAP3AP/6AAIA+/8A/wDw8P7/+iH5BABLvGUALAAAAACYAaAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MhR4L+PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHN+7Mizp8+fQIMKHUq0KFCdSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNPONMq2rdu3cOPKnUu3rt27ePPq3au2r9+/gAOb3Eu4sOHDiBMrXsy4sePGABYKnky5 suWmAC5r3sy5s8zMnkOLZqps9FXQplOrXo0WNcrHsGPLnt02skPWuHPrXuo6Je3fwIMLh2j79u7j yJOz7O17uPPn0KMfVE69uvXr2LNrjym9u/fv4MOL/x9Pvrz58+jTq1/P3vva9vDj8/Rq8YN9e/cJ fsBfcL/9//kB6J+A/w1UoIEA9pdgQvvp1x9+BD4ooUANUvgggRVSuCCEByqYYYb8YQjhhByKSGKF GOZnoYMOmmjQhxuW2KGGM9Z4IIgyCshfcA2qaCGI/h0EJIsIFrnjikci+WKLTCqEI4pHDonjiUrC aKSUQg4pJJEGdvkkQh8mGSRDY4rZpZNcohjml2e2+VuPZkappJtLcrljmHMuBCWUSW45YZly9lmn l2n+eeaUgE4ZJ5GA5tlmmXCSGSiSirqJp6CCXupobHDiySeiaNL5I6MQ7XmonoMmemqohD7q56db av9aqKFs+hniqqjySSmqlm5aa5+VPhYprCuaOGOvS2p6LJit3hmhfi6qWuyzyF4KaqAiRoqpmNFm ymCzPVLb5KIuVsmioinaGexba2nr7qRgaunogMtqyCux67Kp662bItihjqLKua+r28p6J52Vvnsw r87WqGeMC5foLcIedXWRwqb2O+u88A7KbMbbihquwwN7TDDHo6IcMZUSAhwwuB1neSOy386pbbM0 a+zYzZDGbCuwLdsp9IUws4rrmi8HrCyVJZuJrtAKJ83v1OtiS6rR1hLNcmHt2ry0ybKqGGDQVyto ts5fyrsos2AbOeLG6j4tMtBS+/h2yDbTna+h9uL/bC6LlhUIpLLPujyvj/rGKLel4nqrNoyGY/pr vZAnODjbeTZqMIncRo7lhY2njfjMW68Y0zhJpVe1fKyX955sq7cuu1D0zW777dK9jvvuvPskVe/A B6/R78IXbzxExB+v/PIGvXRRPtBDL1D00k+fT0HX20N99gdRjz1B0WvP/fTWh4+Q+eSDL/7261ff PfvlY+++9guhL/734I9P/0D26z++/t1TSP/81z775e9/8OOf98o3v/c1EIHyK6BBEEjB7D0wfRKZ CQH/Z73vETCC/AshB++nvg/mT4EYJB8A95dC9U0whBi0oAC5V70LntCF7qsh/ui3wvi9D4UkFCFD /3Iow4SMcIQTROL1aOi/JbpQhU+c3xI/mD3nVWSFR2QhD4doRC3KkIM9fGIMYYhFMZpRi/ujYQt3 mD4nwlCIZNyhGuHYxQDi0ItotGMc60jHPK6Rjm7cogkDycIyZnEiGtRjGvEYxj/28YslrJ8d51jG N7KxhUXcIh8jiUQo9nGPjJTkC19ISEIq8pOXLOUpPQhITb5RlX505SLt8bsBoi+TFmygJUl5x0L6 cJT4o+T2YJlE81FRiAb0oxvnCEpTttGSzrzkH5cpwmFKk4cJTGEmlSlAX2qSmLLcZi9naUWM6LCZ mAQgE8/pTUqC8Iy+ZOYBdXk+NK7TlSaM5DOj6P9JOeLRkdMMoDsbyc1GJjCb8BzjIr+4QIXOsn3t BGhRTBlIcWJylAdVaCV3OUZ5vtIhFBXoLg0JSo1ys58S3CRH8YnSVcoSmPx0KQNxicqZlrSfRSTo UEIKxlUe06Q1VScbK6pInb5UqN404zZDCsd8EtOg9RynILkoVZhCM6rApGlLP+pQlEYTeTLZYFWl l88OfjKnESxrEG0YUHge8qQeXas42WpWIg71mo60qz2/ekMSQtWqWOypPlkJ2BgKFohVdMnzFpjR GyJ0nhcNXxNtej56VlCyVmXgAYtKz1/uNZUULOo1H+vZyQ6zh/3rZmZRa0zCulap64PsZ2PJvNr/ 2va2uM0tdHSn297OLnm+pQ1r0LGdwQT3N8X9RyEqc9zmOve50I1uTwRQEOoSxLoCwa4Atstd7g6k u9k1CHaz293ybve75k3vQcZr3uu2t7rgTe95w4te75JXvued73fdq9+EgLe615VuY9hrDwKHd7z0 RW+AEVxg8QJYIQZO8IH3614Jr/fBFm6wdgOMYfr2t8EFjvCFKRxiEQu4KGvZ8Ib3y2AEMxjEHI5x hjtsYuqumMMvlrGDAXxjGJPYwz62bo4b4mIOJ9cyF1Hxj2284xn7OMNFhrCMi9xjFi9kyE/W8JKb DGQCY5khUXbyiY8iExgzWcJnnjJC5MvlLNNY/8dpfrGN38vfES94yx0GsZCtLBH7qpmWR0aOnil8 4zC7OcstzjOXy4vhPTv4yxWGM6H/m2dHD1q7fgbzmwEdaMFgJM5BpjSa19zmJ385wi7+r5wP7V84 q/rHsLb0nhPtEENDesx4ATWqK21nWJv6yn9OsKUJHZEaE9vXUfayhW+9bFzD5sP6tTV876xoQ/c6 2TyeNqubjWc+x/rBqSavjjfdbWfTrszcTrebX13p/p563Gk+MKPrK+r7QlvStEZzfrVtbzBnet7W 7fRxzJ0Yge+G4IgxeGAQzvDgKfzhEF84eLzQ8Ipb/OK9jbjGN24WjHtcPhwPuchHTvKSm/zkKP9H +cdXzvKW/6YHx0u5zGdO85rbPCouHwomcs7znvv850APutCHTvSiG+XmSE/6SIzO9KY73bdKj3rS n071qltdIZoAudS3zvWuez3iVw+7Xb5O9rLjhDlmT/tY6lIcsbvdLW2nDT3erh6uoF3teM/O3fPO 963QJe50D3xQAC/4oWtl731P/FXmQvi3MKLwy1O85K0D+cpb/vKYbzqzM8/5znveubwVTkkeMvrP Dw8k/Vi86QnDj4a0XjqvHzu6AUD7xgOF9gOxPSJJQnre8+P3rY+9PWL/+4EI//jAFwjwi7/84C9/ +M9/fkGSX3zlQ7/6yk++8ZlP/O1j3/reN77/+Cei/etjX/oEib72z5/975sf/MMHP2XsoXuh4F4g 9Y9I6RtSEuHHf/zQB4D/B3/BdxD+133pJ4Dgx34I6H8JGIALmBAI+H8TCBEVeHwSOH3ix4AZaH2v h4BcYRGEV3v4h3v3V3vFQYL0p4IpSBCRYRsweIImmIL3R39CcYAP+IHwN4ADWIAGgYM72IM/6IFE uIEd6IM+aIAK6HxMSHzVl4Q8KIRBGIEPGH9IGIVVWIBAKBuA14IwiH82CIYuGIY22IK5F4Zx94Ji qIZrOBTr13xUiIHe94HlF4VO+IQKSIF6KId1GIE66IAAiIMTmITOp4FZmIc9+ITrp4fXN4Qe/+iA gMgun2EQXtiGZoiCZPiFaQiGMWiCloiJ08F7xrF0Rjh+OsiDcmiFSniI6deHcaiKS2iIf4iFgaiB g2h+UBiEt+h6QjiLVdh+dDiEIVgRXXiGX1iGxpiMllgQmpiJaMiJcgGFTch8v9h9gLiFQHiNfoiK hmiKRBiJUliKvdiNsUiADkGIe0iOdriOdbEWmwiNz1iJ8OiMzJh7bIiM8XiGZFgxpMh/oliEAAmL O2iNq1iLrJiD2xeO5eiEUziQ3miOBOmI3JiHkDiO2SeLuuiQ87eCMniMmqiCHHmPZjiGJViCnviM HKmPA7F/DNF/iyiOVkh9MqmI5YeN0VeN1P94keiHfu2XiHNIjnWYkxSIhwbofgf4ktKXlAm5kxlJ hRs5EflHiWzBkpLxj8IDjuTxesPIFlFZj5iHleEBlm0xeWRZlmZ5lmiZlga3emxZlWr5lnAZl3I5 l3TZcW15l81Tl3q5l3zZl375lzJnBYA5mIRZmFbZEVS5GIkpO4P5E4tZcIf5W4DpmJGpGKVXARuB mcGhmZyWeCIIkiopO5wpEKNZEKVpD5ypmRWwmqq5mgPBmqMJm6/pmqjJmrNJm7WZmgSBmbjJm7KJ mq/pcjMxkhnxmAnHe7+Jm6ZZmr1JmsEJnM55ELoZnadZnc8Zm7X5nNAZndA5mJXIhixYg43/Z5yH URK8aZoJgZ2qqZ3ruZ0GgZ3QyZzviZ7qGZ/a6Z6YOXkiaIzNqJLHSB7nuZvpeZ3c+Zv2iRDwmZq0 aZ0CWp/tiZ8CenWgKI8mWYPnYZv3iZ6kKZvTeaCtCZ/UOZ8MGpz1CZwdCqES6pX4KIbtEaDuqaER 2qHtCaIoap0j6pwl6qI0epoXN5wqeo/0OJ6VCZmkqKMRyp0EWqBKiqQyOp8vup0PaqKzmaEC6p0/ apJYyqIFQZ6GYZ4YmpvsqZxQuqEL2ptfmpsK6pvKaaBnmpxTyqTP2Zi+M6THWaQawaOzoZn6OWZ4 OhF9+hh/WnGhN6f9GB6GmRtEwaXPcai4/0ER9Rd3iuocjMoaIfkQj7qldFoYmDihl0iCk9oX+ykR lzoc71iGFIqXdOGjJGmqL9iJNOiR/CgSkHGl4LmPnVlzxTB1LKiM/bmitXqrIOEY4XmCKKmCn6oW GtGfsEqhQOocIpmPq4qqksgd+virvfqskJqph4Gt8wiGx5oaq3qJ88itYRiphEGuK1iP34oWn2mh 4sqqr9qGwMGpxFqSoCitcAESmFBO0Xp6hQoe63oWHdGV+Jpzg1qe2joUAYtkBXuXByuVsvevG0Gw C8tcxHivEOsQKEiwCMGxPVGqKdmwhKGqC+GxtuqooSixGcGp/gmsOpEGFVsSR4ATodqxw//KosVo j8p6syFrsvsJsqEpsncxnKCJs/VInFrKn0Z7qrZhrsRhqzkbs5ORrCnZqcQ6gi5IgiPZqlobF6AJ tEI7tOiWtMzarS07rsoYtLEaEj7xrKEptbuBtGWbtGfrq2kLpE2bsCi7tZgKt39xEUVboYJLt1q6 qVnbkfZIuD9xr8NqoWHbjmOLslQ7irL6sb3nt5RasxfLsU4bERSLuX7xuKI7umL3sKRrEWp5uvPB dRZxAgXhuicQu7ILu7NLEK5ruwYxu7Sru7x7u68bu7bruwIhvLX7u7I7EMI7vPaQvMxbvMPLu8EL vNEbvL+7vM1rvbprva+Lvcebu8jbu87/i73Ui7s/x7zLexDES77nu73qu77Ki7zjq73yC7/z677v +77Ju76+m7/pe7/VS7/SK78B/Lz1q735W8Cw+7/Ky7/sO7/SO8D223P767/0678T3MDo2779C8D2 e7sHrMEUrL8VPMIX7L0ZTL4JvMDnO8EpvL3py8DwC8MVbL4r3L7StRYXfMAbrMImjBA7XMK428I1 vBD9K8NCTMIjnMRKXMMsPMRMnMEvfMJOnMQeDMUd7LJIdxE5DL07PMXT28NXHMJD3MRE7LxGHMEW /L3Z+8E6LMJV/MYLzMX3e8RzjMY03MZVLMbP9R4trMPhu8QKbMHhi8ccvL/di8R2bMNq/zzAbSzF QczDKRzJaOy+cGzCQBzBeezCHJy6TtzIk/zBYLzBXczDbgzGmJzIgAzEnozBMTzDlNzKPVzJ7Ju9 NpzJj4y/WHxzGNHHjizDRAzCiMzBsEzDVIzKeizKPpzMKOzKJUzHV0zHzczKl2zLzrzHYzvKp6zI FPzDDRzAD/y/jIzBqszKxTzJ9evBhizGzrzO1Xu92bzN3xvPmOy6eQcEzdHBcizOCUHLwUzC4Ry/ 3Ju7f/zH5szAvRu9zYvN7HzQ1wu95SzIxPvP8czJqrsRXVfRGJ3RGr3RHN3RrgO6IH3PHj3SJH3D IX3SKJ3SKr3SLN3SLt0UbPCXJe12L/990jNdujWd0zq90zzd0zpBCj69cTcddkFd1EYNl0Od1Epd W0fd1E791FAd1VI91VS9FEtNdVVdmFe91Vy9O1lNmF0d1mLdFoTQpV991mhNcmO91mxtHmntl20d dG+NuVfdl3XNd3ENedqw19pgD3zd135NEID914K91wPx130N2AKB2Iet2H7N148N2ZHt2IQd2Y0t 2Y992JoN2ZR92Z292YSt2KK92Jhd2KJd2ZlN2oZ9EJjd2ZRt2K4d2lTn2IG92Kkd2LSt2bVN259d EKtd27od3L692bYN3IWt26N924ONEL+d2MNd3Li9EMtt3I0d3Lmd3M1N3YM92rw928//Hd3LndvF Pd3Cfd3j/d3Q/d3OvdsGMd3rfd7hnRDr/d7EPd/Sfd7PTd7G3d323d3R/d/C3XSSXdnxbdmm7dnp jdrkPeCt/duqvd2nnd277d/xDeGCbduJ3drgfdnM3dwazt7lPdwVnt8YPtnp7d3cXd0XTtwn3tsI LuLyveIbfuImDuAgntkuftrUveHm3d7Afd0DLuPa/eP0feOwjd6CGrnvTd/+jd9NPuQBXuRCnuI3 nuBGbuU/PuU77txSrt/ujd5L7uP4XeIr7topi3cWQeBBDtoOnuWMHdqyzeYQDtulXePcHedkjttH bt2lHdsfTuQSDt0ZztkXjtq+Heh6/07nTD7ZUp7X3SHeGG26Ht13ju5zTm0Oc53pJVfpnN7ps6Hp oG5z7BDqpF7qps6unt5yEQcLp+53qf7qsB7rsj7ruNPqb0nrPWrruk6WeBCXuP7rwO7on+BxNRDs xn7swSHpqbrrnIHs5jaoPkuZzK4ZGCGenkuJWrur1Rq4zo6w1GrtT9uvXniqfTvtylGsIKntpiru ydir+mjumrEG8j7va8ASxXq3ztiFHbmsWVqu8M6wm/uf6NqsY8isYItrF/B2JGu3ZWt76Aq1YogT VfDvWKG5XBuvg9t29Pqf8Kq23f7xpqfsc0HxJO8UxrCwID8XhkAeJd/yLv/yMB/zJP9RAp2R8gIm 82ln84kRDzrf8z7/80Af9I0h8kIfFAI7sQqhhtGuuaSqok7P9E/fcK3QEyxxCEtnuAmh9EmvuNg+ qlmfsUnvuA2x9AexiTnbsZa69SVb9uIRlaNx8O2u9gSbf14vqowX9Vx/sl+/98zz9syY7s3IuDGY roTfrK6qs9g6g8g4+CG77eIp9qz6939frx2Pj11LnJ7I+JVK+JuPpVe7q4LvuDyb7YNb+Oqehoef 8a+q9ICPe0e/uUYb9/JorZyYsw2P74UPrV5J7kfL9/mO71pfrRDP+Wh7rSQZ+HGPtqE5+8qv/IZf /Mv/+3Pr7TBR8I6/+Px5koePtb//7/zyWvm2n7Zsf7JfC/yyf/zDr/En2fGYv4zfifuFy6vOv/7u Xqlz27XQWLavD7jdr/VMCxD27AEQSFDgwIMJDRpEyJCgw4MPC0ZEmLAixYsSFW6ciJFhRpAQJX5c eLEjxIYUSWI8OVFjSpEsTcas+FKjTZcWV+bkidOnTItBLWYSWtToUaH/lC5l2tTpPwBRS56MClNq xKo1C1b9uBXnwKtguWb9ejWsV5BiO7rMipXkWakPw97kCpQnWrELyZ7VClNl2rg6904tGRgtSpNu Ac8dPNLj1aeRJU+mXJkpUsyZNW/m3NnzZ9BrQwftOto059KdUyNdnbl14qKvT88+/2hZMm3cuXXP lu259+7RfEH/5qi6rWDZYW0vZ84c+HPo0aVPp17d+nXs2bVv597d+3fw4YM2b6qZuHjV4s/zjp1+ +3HdBMk/RTDf/v3gR6dC73pT+vr9cgPQNdEKtIu155IjcDj0pLvvHwRho269/Daj0D3zFhRqNQov zFC//+x5cEQSS7RNLvjGags+sBTLKyS15KqpMaPIYstGtVJqsUW9eiyNRq/eWnGvrYIsUq8CDcNx Rqp8PMwhJ3d0Ea6xboSyp5JM1HJLLb9qqacNZ/orJ5p+MrCvJR1jSyetaJLQTDHv8k9HHVfaqU4w /ZITzTbHZOmlL9XEM0WEuDT0UP/yvOyrIeHMKs7MwvZETCHG1hIUUEfpVDRGP++ENFM8Of3zxTod dXNOFOG0NDHCNH1RyEIRldW+/CbdD1CP4nQ1pkj31LVIGE8FU9hciV21zEf7pBPGjQKEE1VdcXUz 0F2TXTazKBqsbtOyUhzMyFdFpevWJOtiFMe5KO013XK7Pc6wHGcsS15WGbPVXHtbpRel/pak1t2Z zNUWuAez81BDzA42eGALGfZsVoibczhM7xTGzuLvMJ54Y9AK5vhjkEMWebyIS5Z4ZJRTVjk8k1u2 bWX1GIT5wNM03u03l7lsMMAaE2aRZtKurFlC5AQe+DybczVvSCp//rC9mdFLelX/in3Gir2Gz4z5 aayJs7W4CqGO+jMl6SV1x5HowstKNptVCcllHesRXFLThVtseFm090m6gby3VLfgbhTIq/Pur+20 NqwSWDWFdhrkB0UiF1l0lXVbtMORZZRNuTtlVk+tE58T8zF7FZNfVoH13PRRv2b2TqqJ5vNtXzXK ecuwvfQJ1MLY9RyoT43+d3Xi58b77XeTbZVfgVlfVNRzeTZ20VTBFr1nNJtnGtexs3ZVUmu5txN4 pUM1cHniwYcW8Wll0hxSwFKPv/1oE6eeaNe1Rv97Z2eO3PccGQ5T+0repNZWt8OQpm2+i5Ld8PKj UcXrgZWLnmIQkxpM+U1FyIld/+30Rih17YQwzXtMlm53wqYgrXuhmVp0LtTCFXYMhSQKW8JiiJrH 7QxDN+Shg/DTQyCucIZDJKJlgnhEJCaRhx4TjAKtA0OZcQ1rLozQbop4RSxeBjeHkx3YMNjFegkv dCxc0G9UCEXrOTFwCCwhGpVoHSaSD4ykE1sduYi4LZYRYVXkDx/vKKO7WCSLgySkxPZ2JCrhsXqb kxK86sU4wSWPbeCy0VvO5i3AGWmRZ4MeitDWNDq2znKCLGQpTfmU9k0ulNXaXxiTxCcIgm9YXNQc VTj3l+mND5bpmxK7xkXKUwbTlKk8Fl90qafAGLBT+ALg53YnxskZE3MkfBb7Zv9XTQ45844iEmY3 D5U7+dHvdLgMZTb3F8tj8RI2qnQi6nj1O46sD5vtmRYt33jPByqQef1KU/ai1Ld8xshbJKybGPlH KFiFa58JjV8FA0pJAG7Sjfh8Thwp2r3XTNQ03uQo7i76UXWBCKQjJalQxlFSlKb0Oh1laUtd+lKY xlSmM6VpTW16U5zmVKc7PZlKffpToAZVqEMlqkB4elSkJhWpRWVqU++pVKhGdVYqkOo3nXrV0TCB BVjlale9+tWkVFWslEHEWM16VrSmVa1rZWtb3fpWuMZVrnM9qwXoelezglWve3UYXv2KKD6MqB1/ JWxhDRtXviZWsd85rE790Fj/xC5WspOlbGUte1nMZpaiFtVsZxlL03yQx7OjBY9MSXtai4ADtZ0B R2tV61rV2iO2AoktbBPiWtriNrW6le1scTtb2fb2tbc9iG2L61vkIve4wm1tcIvL3OE+t7m5de5t f2tb2AI3t74l7nFfa9zt1ha74OVtecErXOg697zZ9e5utVvd5Yb3u7/13320y93pBve9z4VvaoWS X/VyN8D83W9v4yvg/Db3vgKuLnC/u9z7+jco+0Uwg2nbXQxHl78ZvrB6jeJg6R4FxB1usISta+II mzY0Eb5wdDU8YRKbuLsI9rCHa9tf4g73xfrl8Y5dvGEQ65jHGyZykfsr5CNj/xjISVbykG9clBEb mcM5ljGLo8xi3RQBZLo17o3F+97kSpjLJH7yj20c4CD32L9Cnm+ZSxxjNg+5w9cFMJjX3OIqT5jL e6ZvjhPMWyKDGcBLprKSrZzhMcMsjhpmNJZjDOcZl5fMbqZulGvs40sz2cBkLrSXDY1jHEdYuZ9G saYfjWRQQxrKMD61qRdc5yKr9qyFlrOpQ13qET95zqq2MKVpfGZSvxnPNcb1f42961g3ucSO5nSm Vy3lR8OXwRaW9pRBfdYuJ7rFgEbveb374vlWu8+ThjWiqd1mcAda28O2roLJC+UEGzre7v2ygv87 b/2uF9/hPXZ7261nexM6vf+yzutqDV4dFR9c4QtneMMd/nCIR1ziE/chrTbN3G/f293TzTWg2btd Vjd43+F2724zfmKQazzQwZZ0tG8M2b9St9nnxjV+RWztEM+802JGubAvrmtCj/zXxF7whWHuV2ez u9oc/nGBm51soNfazASm+tJ9LWM1i1vpcrZzcI+O16RLveQYBza3n+5yqPtZ0Lnm9ZwHnWRPUx3T tab61+9K9jRDm9Eix7rPb93qNNvZweuu99bhHt9JM3nHu7Z7UkeTd6J/eNlN7vrZV47sYR9a65h3 csiBbmld2zzkFEfPg4Js3rdnm+Nqp/DYR4/ek/c659seud9hv3RV3z7a3ebIZuMjS3or+v73wM+N 8Ie/ROMnX6dHVH7zCUl86Ct22oj/OMZBv/FBkzf7Yd599L3f72k7Wvx57nuvf+3076cfz3vHfeVd /XrNX139DS9YnDlPbeiOH+CtvnS8nf//mVKz5Lqy0dO/VbOyMeMuAMSpx7I7Acw9S8O93Du2oeu8 2lhADLyd05g+geO368M/fZM90Zs/EixBE/wYzoqhDFxBFmxBF9TAE4xBFXxBGqxBG7zBxpNBHdxB Hlw4HPxB4+tBIRxCIqysgAAAOw== ------=_NextPart_000_000D_01C6FD53.7931D660-- From avt-bounces@ietf.org Tue Oct 31 23:40:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf7tK-0002MZ-Pu; Tue, 31 Oct 2006 23:39:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf7tJ-0002M4-3c for avt@ietf.org; Tue, 31 Oct 2006 23:39:53 -0500 Received: from adsl-63-193-97-10.dsl.snfc21.pacbell.net ([63.193.97.10] helo=zaphod.philzimmermann.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf7tE-0005hC-Fr for avt@ietf.org; Tue, 31 Oct 2006 23:39:53 -0500 Received: from [10.0.1.201] (adsl-63-193-97-10.dsl.snfc21.pacbell.net [63.193.97.10]) (authenticated bits=0) by zaphod.philzimmermann.com (8.13.6/8.13.6) with ESMTP id kA14dhpc089493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 20:39:44 -0800 (PST) (envelope-from prz@mit.edu) In-Reply-To: <8663D3C4-1335-4E0D-BD5B-FF4BE4150304@csperkins.org> References: <481701c6fa29$ee60eb10$5b82200a@amer.cisco.com> <8D76FC0A-C488-4C5F-A856-2F6C16F3C46A@csperkins.org> <45435CD4.8080702@sipstation.com> <6EDDBB66-E1A0-4D90-A89D-DCAFDF3BFA31@csperkins.org> <42A06D25-951B-4A8B-BD66-2DF568167486@csperkins.org> <8663D3C4-1335-4E0D-BD5B-FF4BE4150304@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2052D9F6-E269-46D2-9C67-15A3B75E86FF@mit.edu> Content-Transfer-Encoding: 7bit From: Philip Zimmermann Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt] Date: Tue, 31 Oct 2006 20:39:37 -0800 To: Colin Perkins X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on zaphod.philzimmermann.com X-Spam-Score: 0.2 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Randell Jesup , avt@ietf.org, Dan Wing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: avt-bounces@ietf.org We do up to 20 retries of the Hello packet, because we empirically observe a high packet loss rate at the start of media stream, which only lasts a second. This is exactly the same period that we do our entire ZRTP protocol. We used to have a retry limit of 10, but that was not enough. So don't assume that this won't impact RTCP bandwidth quotas. On Oct 31, 2006, at 12:58 PM, Colin Perkins wrote: > On 31 Oct 2006, at 20:19, Randell Jesup wrote: >> Colin Perkins writes: >>>> Except those middleboxes may well reject unknown packets on the >>>> RTP port. >>>> And in any case, we're putting bandaids on bandaids here - and >>>> even with >>>> this, there are serious bandwidth issues. >>> >>> We standardised the mechanism to signal to those middleboxes >>> three years >>> ago. Push on the vendors and operators to implement them and >>> those kludges >>> go away. It's not like the "a=rtcp:" attribute is difficult, >>> compared to >>> some of the stuff that does get implemented... >> >> True. But there are a zillion RFCs, and unless there's an >> application/ >> business requirement for one of them, many or even most of them >> don't get >> implemented. From their point of view, should they spend that time >> (including regression testing!!) on this, or should they put it >> onto the >> Next Big Feature that everyone is clamoring for? Plus, even if >> implemented, many vendors won't update a box unless they must. >> They often >> run years-old software versions. > > NAT traversal and security aren't the Next Big Thing? > > ... >>>>> I'd prefer ZRTP to use RTCP packets ignoring the timing rules >>>>> for the >>>>> initial negotiation, than for it to embed control information >>>>> into RTP >>>>> media packets. Neither is ideal, but this seems the least bad >>>>> alternative architecturally, given that the community seems to >>>>> have >>>>> decided to punt the keying problem onto this group, rather than >>>>> fixing >>>>> the SIP layer. >>>> >>>> Ignoring the timing rules, or timing and bandwidth? >>> >>> The timing rules. I see no need to violate the bandwidth rules, >>> on average >>> (and there are no short-term guarantees with RTCP anyway, due to >>> it's >>> statistical nature). >> >> There's less need to violate the timing rules (I think) with AVPF. >> However, the bandwidth rules still mean an up-to-10-second key >> negotiation >> (ignoring packet losses). That's simply unusable, and that sort >> of issue >> is why they're doing something even uglier in the current draft >> (header >> extensions). > > I don't see why you can't send the ZRTP exchange at *exactly* the > same rate as in the current draft, while still using RTCP. You do > the key exchange quickly, then delay your next RTCP packet to > compensate. Overall bandwidth fraction the same as with standard > RTCP, but violates the timing rules a little (in the same way AVPF > does, but for several (two?) packets, rather than just for one > packet). > >> What's your objection to something like: >> >> m=audio 4321 RTP/AVP 0 99 >> a=rtpmap:99 ZRTP/8000 >> a=rtpmap:0 PCMU/8000 > > ZRTP keying negotiation packets aren't audio data. > > Colin > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt ---------------------------------------------- Philip R Zimmermann prz@mit.edu http://philzimmermann.com tel +1 650 322-7223 (spelled with 2 n's) fax +1 650 322-7877 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt